Regarding Pasi's comment on TCP header flags: > - Appendix A.2, "Verify TCP": the bits that are currently reserved > might get allocated in the future (and half of the bits that were > reserved in RFC 793 have been since allocated -- so it's not very > clear exactly what "TCP.reserved_bits" means).
Please note that the second diagram at <http://www.iana.org/assignments/tcp-header-flags> does not represent the current state of assignments. It is drawn from RFC 3168 and does not depict the assignment performed for RFC 3540. The effective current state is shown in the diagram below. (However, note that there are already proposals floating around to make use of the remaining available flags, e.g. for PCN signalling, IIRC.) Generally, 'mbz' fields should never be checked by destination systems or intermediate systems that don't support functionality related to such bits specified in more recent documents -- otherwise transparency and protocol extensibility would be impacted substantially. RFC 2780 simply says: |9.2 Reserved Bits in TCP Header | | The reserved bits in the TCP header are assigned following a | Standards Action process. ... and RFC 4717 says: |7.2. Reserved Bits in TCP Header | | There are not enough reserved bits to allocate any for | experimentation. The TCP section of RFC 1812 refers to the IP sections of that document for generally applicable rules, and there it states: [...] A router MUST NOT set either of these bits to one in datagrams originated by the router. A router MUST NOT drop (refuse to receive or forward) a packet merely because one or more of these reserved bits has a non-zero value; i.e., the router MUST NOT check the values of thes bits. and later: [...] Routers MUST NOT drop packets merely because one or more of these reserved bits has a non-zero value. The aforementioned IANA registry should say (a request for correction has been stalled long ago; at some point in time, I ran out of energy to insist on action and follow up) -- change bars mark modified lines: --------snip-------- The Transmission Control Protocol (TCP) included a 6-bit Reserved field defined in RFC 793, reserved for future use, in bytes 13 and 14 of the TCP header, as illustrated below. The other six Control bits are defined separately by RFC 793. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | U | A | P | R | S | F | | Header Length | Reserved | R | C | S | S | Y | I | | | | G | K | H | T | N | N | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |RFC 3168 defines two of the six bits from the RFC 793 Reserved field |to be used for ECN, and RFC 3540 added another bit, as follows: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | N | C | E | U | A | P | R | S | F | | | Header Length | Reserved | S | W | C | R | C | S | S | Y | I | | | | | | R | E | G | K | H | T | N | N | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ --------snip-------- Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +------------------------+--------------------------------------------+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
