Hi Tom, > -----Original Message----- > From: Tom Herbert <t...@herbertland.com> > Sent: Saturday, November 25, 2023 8:50 AM > To: Eric Vyncke (evyncke) <evyncke=40cisco....@dmarc.ietf.org> > Cc: Templin (US), Fred L <fred.l.temp...@boeing.com>; 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 Sat, Nov 25, 2023 at 12:07 AM Eric Vyncke (evyncke) > Eric Vyncke (evyncke) <evyn...@cisco.com> > wrote: > > > > Fred, > > > > > > > > Without any hat, I agree with Tom: any new protocol should be able to work > > with legacy (== current) devices including routers on the > path. > > > > > > > > Tom, rather than HbH (that would be processed by every router on the path > > and whose fate is not too positive), I would rather suggest > Dest Options as the fragmentation is basically processed by the source and > the final destination.
Eric, thank you for these insights. > Eric, > > Yes, if the option isn't processed by routers then Destination Options > would be appropriate, but I believe Fred's intent is to allow > fragmentation to happen inflight like with IPv4. > > In either cases of HBH or DestOpts, there is a risk of > misinterpretation of the bits following the EH when the fragment > option is used. For instance, if the NextHeader in DestOps is 6 and > the fragment option is present then a router doing port filtering > might skip over the DestOpts and incorrectly interpret the fragment as > being a TCP header. I think a solution to that may be to have the > reassembled Next Header in the fragment options and to set the NetxHdr > in the EH to 59 (No Next Header). This would also ensure that the > packet isn't misinterpreted at the receiving host if for some reason > it doesn't process the fragment option. Tom, seeing your message now, it looks like you are suggesting a "full service" HBH option that includes both an extended Identification and fragmentation control field. It also looks like you see a way clear to make it work, modulo the answers to my questions in the previous message. Do I have that right now? Thank you - Fred > > Tom > > > > > > > > > Regards > > > > > > > > -éric > > > > > > > > From: Int-area <int-area-boun...@ietf.org> on behalf of Tom Herbert > > <tom=40herbertland....@dmarc.ietf.org> > > Date: Friday, 24 November 2023 at 20:33 > > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > > Cc: int-area <int-area@ietf.org> > > Subject: Re: [Int-area] "Identification Extension for the Internet > > Protocol" question > > > > On Wed, Nov 22, 2023 at 10:57 AM Templin (US), Fred L > > <fred.l.temp...@boeing.com> wrote: > > > > > > Tom, please have another look at the draft – it gets the job done without > > > requiring any new kinds of IPv6 extension headers, HBH > options, etc,: > > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/ > > > > Hi Fred, > > > > >From the draft: "For an advanced Identification, this specification > > permits the source to include a second Fragment Header immediately > > following the first such that the two are bonded together to create a > > conceptual IPv6"-- How would this be processed for a legacy receiver > > that doesn't understand these headers are to be bonded? > > > > >From the draft: "For the second Fragment Header, only the Next Header > > field is interpreted as a control field that MUST encode the value N > > corresponding to the next header to follow while the remaining 7 > > octets are interpreted as an Identification Extension."-- This is > > repurposing fields in a standard protocol header. Even if it > > functionally works, this can break diagnostics and debugging tools in > > deployment. > > > > IMO, defining a new Hop-by-Hop option for fragmentation still seems > > more palatable. > > > > General comments: > > > > Defining a new Hop-by-Hop option for fragmentation still seems more > > palatable to me. > > > > IMO, it would be better to discuss IPv4 and IPv6 in separate drafts. > > For instance, the changes you're suggesting for IPv6 would be under > > the auspices of 6man. IPv4 changes I suppose fall under int-area. I > > also suspect it's more likely that an extended ID would be accepted > > into IPv6 than IPv4. > > > > Also, I would suggest just focusing on what's needed for a larger > > Fragment Identification to IP; I think there might be an argument to > > be made for that. In particular, I suggest removing discussions or > > references to IP Parcels or OMNI as they don't seem essential to the > > goal of a larger fragment identifier. > > > > Tom > > > > > > > > > > > > > > Thank you – Fred > > > > > > > > > > > > > > > > > > From: Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org> > > > Sent: Tuesday, November 21, 2023 7:14 PM > > > To: Tom Herbert <t...@herbertland.com>; Templin (US), Fred L > > > <fred.l.temp...@boeing.com> > > > Cc: int-area <int-area@ietf.org> > > > Subject: RE: [EXTERNAL] Re: "Identification Extension for the Internet > > > Protocol" question > > > > > > > > > > > > Tom, > > > > > > > > > > > > >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. > > > > > > > > > > > > The Identification needs to be included in the Per-Fragment headers, so I > > > guess that means it needs to be “Hop-by-Hop Option”, right? > > > > > > > > > > > > Thanks - Fred > > > > > > > > > > > > From: Tom Herbert <t...@herbertland.com> > > > Sent: Tuesday, November 21, 2023 4:22 PM > > > To: Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org> > > > Cc: Templin (US), Fred L <fred.l.temp...@boeing.com>; int-area > > > <int-area@ietf.org> > > > Subject: [EXTERNAL] Re: "Identification Extension for the Internet > > > Protocol" question > > > > > > > > > > > > EXT email: be mindful of links/attachments. > > > > > > > > > > > > > > > > > > > > > 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 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
