Summary

  • TCP uses Data Offset to locate the payload, while End of Option List can stop meaningful option parsing earlier inside that declared header.
  • No-Operation can align a following option, but receivers must still parse options that begin on any octet boundary.

A short walk through a variable header

Imagine a TCP receiver moving byte by byte through the option area. It sees Kind 1. That byte is a No-Operation, so there is no length field to consult and the parser advances by one octet. Next comes an option whose kind is followed by a length. The parser can use that length to skip the complete option, whether or not it implements the option's meaning. Then it reaches Kind 0, End of Option List. Meaningful options have ended, even though the Data Offset field says that several header octets remain before application data begins. Those remaining octets are zero padding.

That small scene contains four distinct pieces of control. Data Offset fixes the physical boundary between the TCP header and payload. The kind octet identifies how the next part must be parsed. A normal option's length provides the distance to the following option. EOL terminates the logical list when that list is shorter than the available header space. None of those jobs can safely be inferred from the others.

The arrangement was already present in RFC 793 in 1981. RFC 9293 retained it in the current TCP specification and expressed several receiver obligations more sharply. The continuity matters because option extensibility depends less on recognizing every future meaning than on knowing how to move past what is not recognized.

Two one-byte exceptions

TCP's base grammar permits two shapes. Most options begin with a kind and a length, followed by whatever data the length covers. The length counts the kind and length bytes themselves. EOL and NOP are the exceptions: each consists of one kind byte and has no length field.

The exceptions are not interchangeable. EOL, Kind 0, says that the entire list has ended. It is not a separator after each option. It need not appear when the final option naturally reaches the header boundary declared by Data Offset. When it does appear early, it changes what the receiver should interpret, not where payload begins.

NOP, Kind 1, carries no termination meaning. A sender may place it between options, commonly to move the beginning of a later option to a preferred word boundary. The parser consumes one byte and continues. An isolated layout instruction can therefore change position without inventing a fake length-bearing option or changing the semantics of its neighbors.

Alignment was a sender convenience, not a wire requirement

The word “alignment” can suggest a stronger promise than TCP makes. RFC 793 said there was no guarantee that senders would use NOP and that receivers had to be ready for options that did not begin on a word boundary. RFC 9293 preserves that rule as an explicit requirement.

This asymmetry is important. A sender may arrange bytes for its own implementation convenience. It cannot turn that preference into a condition of interoperability. A receiver that assumes every multi-byte option starts at a word boundary would reject or misread a segment that the protocol allows. NOP expands a sender's layout choices while leaving the receiver's parser general.

Nor does the specification promise that NOP makes processing faster on every machine. Its protocol role is narrower: it consumes one octet and can be used to alter the placement of the next option. Hardware costs, memory-access penalties and implementation strategies sit outside that guaranteed meaning.

The end of meaning and the end of bytes

EOL exists because meaningful options and reserved header space can have different lengths. TCP headers are measured in 32-bit words by Data Offset, but options themselves may have lengths that do not exhaust the available area. EOL allows a sender to state that interpretation stops here. RFC 9293 requires the remaining header bytes to be zero padding.

The distinction prevents two dangerous shortcuts. First, a receiver must not treat EOL as if payload starts immediately after it; payload still begins at the Data Offset boundary. Second, it must not treat the padding as a sequence of additional options. EOL closes the logical list, and the fixed header boundary remains authoritative for locating data.

Zero padding makes the unused remainder predictable. It does not carry an option meaning, and it does not alter the declared TCP header length. This is a modest form of protocol discipline: unused space is bounded and has a prescribed representation rather than becoming an ambiguous extension channel.

Length fields make unfamiliar options traversable

The larger extensibility mechanism appears in the rule surrounding these two exceptions. Every option other than EOL and NOP must carry a length field, including future options. RFC 9293 also requires implementations to ignore unsupported options without error when a length field is present.

That does not require an old receiver to understand a new option. It requires the receiver to understand enough grammar to find the next byte that matters. The length is therefore structural evidence: it describes the option's extent, not whether the option is trustworthy, useful or supported.

This design also explains why illegal lengths are serious. A zero length on a format that is supposed to advance the parser can trap a naïve loop at the same position. A length shorter than the fixed kind-and-length prefix is equally incoherent. RFC 9293 requires implementations to handle illegal option lengths and suggests resetting the connection and recording the cause. Extensibility works only when unknown meanings remain safely bounded.

What stayed stable from 1981 to the current standard

RFC 793 described variable options, the two format cases, EOL, NOP, zero padding, and the receiver's need to tolerate unaligned options. RFC 9293 did not replace that grammar with a new mechanism. It consolidated TCP's current requirements: EOL, NOP and MSS form the mandatory option set; options can occur in any segment; unsupported length-bearing options are ignored; future options need length fields; and receivers must cope with illegal lengths.

The historical lesson is not that Kind 0 or Kind 1 was individually sophisticated. It is that small syntactic rules protected different boundaries. One field marks the physical end of the header. One code can mark the logical end of the list. One code can occupy a byte without adding semantics. Length-bearing options remain skippable even when their meaning is unknown.

Sources