4

In rfc793 : page 17 in explaining the No-Operation TCP header option, it is cited:

This option code may be used between options, for example, to align the beginning of a subsequent option on a word boundary. There is no guarantee that senders will use this option, so receivers must be prepared to process options even if they do not begin on a word boundary.

  • What is the meaning of word boundary in this context?

  • Since the implementation of this option (No-Operation) in the TCP header depends on the type of OS and varies between different platforms, -please correct me if I'm wrong!-, does the notion of word boundary have something to do with the actual CPU word size?

2 Answers 2

2

This is a 16-bit boundary. A byte is 8 bits, a word is 16 bits, a double-word is 32 bits, and a quad-word is 64 bits.

Edit:

Network protocols must be processor and OS independent. You could not have a definition of word which varies on each side of a network conversation. How would a 16-bit PC deal with IP packets from a 32-bit PC if the 16-bit PC is expecting 16-bit words, but the 32-bit PC is aligning on 32-bit words? The whole Internet would be broken.

7
  • So the appearance of this option is totally independent from OS and the platform in use. Am I right?
    – Kobayashi
    Jan 12, 2016 at 21:03
  • 1
    Possibly, but my answer gives the common usage. Also, you have to remember that at the time RFC 793 was published (September 1981), 16-bit computers were top of the line computers.
    – Ron Maupin
    Jan 12, 2016 at 21:07
  • This makes total sense, Since analyzing a SYN package (for example with wireshark) shows that the NOP option is there to fill the empty spaces between other valid options on a 16-bit boundary.
    – Kobayashi
    Jan 12, 2016 at 21:12
  • These definitions are not correct - such absolute definitions do not exist. Even the size of a byte is not absolutely 8 bits - it is architecture dependent - and the rest of these are even less standard. RFC 793 knew this, which is why it makes sure you know you have to handle these things even if they are not on word boundaries for your system. Jan 12, 2016 at 22:31
  • 1
    @RonMaupin: that is true, although not all architectures follow that standard. No RFC defines these sizes, because they were architecture dependent - the TCP RFC itself, on the same page, refers to "word" as both 16-bits and 32-bits. Jan 13, 2016 at 0:11
1

In computing the term "word" generally refers to the "natural" unit of data processing of a system. The size of this varies but is usually either 2 or 4 bytes. A byte in turn is normally 8 bits (internet standards are very much built around the assumption of an 8 bit byte).

Reading the rest of the RFC there are references to both "16 bit words" and "32-bit words". I believe that if the authors had intended to mean alignment on a 2-octect (16 bit) boundary they would have said so explicitly.

So I believe that the RFC authors intended the term "word" in it's general meaning. That a system could use the NOP option to align options on a boundary that was convenient for processing, whatever multiple of octets that boundary happened to be.

This is not an issue for interoperability as all receivers are required to handle unaligned options.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.