On Tue, Nov 21, 2023, 2:45 PM Templin (US), Fred L <Fred.L.Templin= 40boeing....@dmarc.ietf.org> wrote:
> Tom, I am going to circle back again to where this all started many draft > versions ago. Based on > > my read of RFC6564 and how that was then taken up in RFC8200, it looks > like the barrier would > > be very high to specify any new extension header that does not begin with > the two 1-octet > > fields “Next Header” and “Hdr Ext Len”. The reason for that specification > is to ensure backwards > > compatibility for widely-deployed hardware in the rare event that a new > extension header would > > be defined. So, going back to what I said in earlier draft versions, > wouldn’t it be better if we just > > put the Identification extension in a Hop-by-Hop option instead of > defining a new Fragment > > Header type? > Fred, The bar for creating any new EH is high. If the data needs to be read or modified by routers then Hop-by-Hop Options is appropriate, if it's only read at the end host or intermediate nodes then Destination Options should be used. Tom > > Fred > > > > *From:* Int-area <int-area-boun...@ietf.org> *On Behalf Of *Templin (US), > Fred L > *Sent:* Tuesday, November 21, 2023 1:30 PM > *To:* Tom Herbert <tom=40herbertland....@dmarc.ietf.org> > *Cc:* int-area <int-area@ietf.org> > *Subject:* Re: [Int-area] [EXTERNAL] Re: "Identification Extension for > the Internet Protocol" question > > > > Tom, > > > > 4 bytes per packet worth of wasted transmission is a pain point > experienced by all nodes on > > the local (shared) transmission media as well as along the networked path > – not just for the > > original source and final destination. Conversely, an odd-sized roadblock > in the middle of a > > path of otherwise 8-octet-aligned stepping stones is a processing anomaly > experienced only > > by the forwarding nodes and end systems on the path. And, how bad would > that be, really? > > There is currently no hardware logic that recognizes the IPv6 Extended > Fragment Header > > (since it does not yet exist) and software logic can easily be made to > step around an 8-octet > > alignment anomaly until ASICs begin to emerge that can do it more > efficiently. > > > > So, I say we bend the rules and make the IPv6 Extended Fragment Header as > the sole > > exception IPv6 extension header that does not support 8-octet alignment. > All it would > > take is an update to RFC8200, but we already have to do that in order to > define a new > > extension header type. > > > > Fred > > > > *From:* Tom Herbert <tom=40herbertland....@dmarc.ietf.org> > *Sent:* Tuesday, November 21, 2023 1:11 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, 12:15 PM Templin (US), Fred L <Fred.L.Templin= > 40boeing....@dmarc.ietf.org> wrote: > > 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. > > Fred, > > > > The problem isn't with the new header, it's the effects on existing > extension headers that might follow it. > > > > > > 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. > > > > 4 bytes is 0.3% of minimum 1280 bytes MTU. I don't believe that is > significant enough savings to diverge from the long established > requirements of the standard. > > > > Tom > > > > 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> 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 > https://www.ietf.org/mailman/listinfo/int-area > >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
