Tom, >The text you quoted says why we can't do that. If a frag header length is not >a multiple of eight bytes then the alignment requirements for all subsequent >extension headers and the payload are not met. >This potentially breaks a >receiving implementation that relies on alignment.
I both do and don’t understand why this limitation applies here. Currently, no IP protocol number exists for the IPv6 Extended Fragment Header, so currently no receiving implementations recognize it. So, why can’t we define one special-case IPv6 extension header that bends the rules? As implementations are deployed to recognize it, they will naturally accommodate the discontinuity in 8-octet aligned extension headers. With modern architectures, I would think that saving the network transmission overhead of 4 wasted octets per message would outweigh the processing drawbacks in having a discontinuity in 8-octet alignment. Especially since no implementations currently exist. Fred From: Tom Herbert <tom=40herbertland....@dmarc.ietf.org> Sent: Tuesday, November 21, 2023 12:04 PM To: Templin (US), Fred L <fred.l.temp...@boeing.com> Cc: int-area <int-area@ietf.org> Subject: [EXTERNAL] Re: [Int-area] "Identification Extension for the Internet Protocol" question EXT email: be mindful of links/attachments. On Tue, Nov 21, 2023, 11:44 AM Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org<mailto:40boeing....@dmarc.ietf.org>> wrote: Section 8 of "Identification Extension for the Internet Protocol" proposes a new IPv6 extension header called the "Extended Fragment Header" that includes a 96-bit (12 octet) Identification field making the total length of the extension header 128-bits (16 octets): https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/ However, the only reason for the 96-bit Identification field was to make the whole extension header be an integral multiple of 8 octets - what would be preferable would be to have only a 64-bit Identification field and limit the Extended Fragment Header as a whole to 96-bits (12 octets) which is not a multiple of 8 octets. The IPv6 Fragment Header is unique among IPv6 extension headers in that it does not include a "Hdr Ext Len" field that tells the length of the header in 8-octet units. This means that implementations must be able to determine its length (8 octets) solely based on the IP protocol number "44". The proposed IPv6 Extended Fragment Header would likewise not include a "Hdr Ext Len" field and would use a new IP protocol number to be assigned by IANA, with the IP protocol number determining the extension header length. RFC8200, Section 4 states: "Each extension header is an integer multiple of 8 octets long, in order to retain 8-octet alignment for subsequent headers." But, can an exception be made for the proposed IPv6 Extended Fragment Header with a 64-bit Identification field, making the total extension header length 12 octets which is not a integer multiple of 8? Hi Fred, The text you quoted says why we can't do that. If a frag header length is not a multiple of eight bytes then the alignment requirements for all subsequent extension headers and the payload are not met. This potentially breaks a receiving implementation that relies on alignment. Tom Thank you - Fred _______________________________________________ Int-area mailing list Int-area@ietf.org<mailto:Int-area@ietf.org> https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
