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

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 '16 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 '16 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 '16 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. – Nick Bastin Jan 12 '16 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. – Nick Bastin Jan 13 '16 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, privacy policy and cookie policy

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