Summary

  • TCP Data Offset counts the entire header in 32-bit words and therefore supplies the authoritative location of the first data octet.
  • End of Option List stops option interpretation, while any remaining header octets are zero padding; neither EOL nor padding is application data.
  • NOP can help alignment, but receivers must parse options on any octet boundary and cannot assume every sender aligned them.

The smallest TCP header occupies five 32-bit words. Its ports, sequence and acknowledgment numbers, flags, window, checksum and urgent pointer fill twenty octets. Options make that header variable. Once they exist, a receiver needs an outer boundary that remains unambiguous even when it does not understand every feature inside the option area.

RFC 793 assigned four bits to that job. Data Offset is not a byte position and does not count only the options. It states the number of 32-bit words in the whole TCP header. Multiply the value by four and the result is the octet at which data begins. A value of five describes the base twenty-octet header. Larger values include options and any padding needed to finish a complete 32-bit word.

The unit was a compact bargain. Four bits can represent up to fifteen words, so the directly described header can reach sixty octets. The field consumes little space, while its word-based meaning guarantees that the data boundary remains aligned to the header format. The receiver does not have to add the lengths of options to discover where payload starts.

That separation matters because the option list has its own ending. End of Option List is a one-octet option that says no more options follow. It need not coincide with the end of the header reported by Data Offset. If space remains, RFC 9293 requires the octets after EOL to be zero header padding. Data starts only at the Data Offset boundary, not immediately after the EOL byte.

No-Operation answers a different parsing need. It is also one octet and can appear between options, for example to align a later option on a word boundary. But the alignment is a convenience, not a promise. Options may begin on any octet boundary, and receivers must be prepared to process them there. A parser that skips forward on the assumption of alignment is reading a convention that the protocol never guaranteed.

Most other options carry both a kind and a length. The length counts the kind byte, the length byte and the option data. That self-description lets a receiver step over an option it does not implement, provided the length is legal. RFC 9293 requires support for receiving options in any segment and requires unknown, well-formed options to be ignored without error. Extensibility depends on preserving syntax even when semantics are unfamiliar.

Data Offset supplies the ceiling for that walk. RFC 9293 expresses the option area as (DOffset-5)*32 bits when DOffset exceeds five, and explicitly says the figure includes trailing padding. An option length cannot legitimately grant permission to read beyond that outer boundary. Conversely, EOL can stop option interpretation before the boundary while leaving bytes that remain part of the header.

All those header octets, including options and padding, participate in the TCP checksum. Padding is therefore not invisible filler, but it is still not application data. This distinction protects both parsing and integrity: a receiver knows which octets belong to the header calculation and which begin the byte stream delivered above TCP.

The design also divides error handling. An unsupported option with a valid length can be skipped. An illegal length threatens the parser's ability to advance safely; RFC 9293 requires implementations to handle it and offers resetting the connection and logging the cause as a suggested procedure. The standard preserves the requirement while leaving room for implementation choices around the exact response.

Data Offset's lasting role is modest but foundational. It does not negotiate an option, describe an application record or say which feature matters. It gives every implementation the same outer boundary. Within it, option kinds and lengths support evolution; after it, the application byte stream begins. TCP could therefore add meaning to its header without losing the ability to locate data.

Sources