On Sat, Nov 25, 2023 at 12:07 AM Eric Vyncke (evyncke) <evyncke=40cisco....@dmarc.ietf.org> 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, 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 > > > > 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
