Tom, I do not want to add a new type of Fragment Header for either IPv6 or IPv4; I like the existing IPv6 Fragment Header the way it is. And for IPv6, I want intermediate nodes to have an early "DF" indication without first having to parse deeply into the packet to see if a Fragment Header is present.
For IPv4, I want to continue to use the 16-bit Identification the way it has always been used, but then also include a 2-octet or 6-octet extension. The way to do that is with an IPv4 option. Fred > On Fri, Sep 1, 2023 at 8:51 AM Templin (US), Fred L > <fred.l.temp...@boeing.com> wrote: > > > > Tom, > > > > > Fred, > > > > > > I'm still not seeing it. If an extended ID is used then AFAIK this > > > would mean that in order for a receiver to correctly reassemble the > > > packet it MUST process the extended ID. > > > > There is a test that the sender uses to determine whether the receiver > > recognizes > > the option. > > That's not sufficiently robust. The ping test creates a quasi flow > state that isn't reliable. Obviously it doesn't support multicast, but > can even fail for unicast if the destination happens to be an anycast > address or the destination host to reboot with a different image that > no longer recognizes the option. And if a receiver were to ever ignore > the extended ID, then that potentially could lead to data corruption > which is very bad. > > > > > > This means that the option cannot be ignored by the receiver. > > > > Receivers that ignore the HBH option will be identified by the test and > > will not be subject to Identification Extension. > > > > > If this is the case, then for a > > > Hop-by-Hop Option the higher order type bits cannot be 00 (not ignore > > > unrecognized type). However, if the high order bits are not 00 for a > > > Hop-by-Hop Option then any intermediate node in the path could drop > > > the packet if it doesn't recognize the option which would effectively > > > render the solution undeployable. > > > > I want for the high order bits to be 00. > > > > > I would suggest that instead of trying to use either a Hop-by-Hop or > > > Destination Option for the extended ID, create a new type of > > > Fragmentation Extension Header for this purpose. This could be a > > > sixteen byte EH that could contain up to a 96 bit identifier. > > > > It is an idea I had considered, but then asking intermediate IPv6 nodes to > > check for an extended Fragment Header would really be no different than > > asking the intermediate nodes to check for a HBH option. I think the HBH > > option is better because it is the first thing the intermediate nodes will > > see. > > > > Why do intermediate nodes need to check for a Fragment Header? At > best, an intermediate node might try to parse over the extension > headers to find the transport layer for filtering, but for a fragment > they can't parse past the Fragment Header. Adding a new type of > Fragment Header would equally prevent intermediate nodes from parsing > past the Fragment Header (except maybe in the case that the node wants > to parse the first fragment). > > > > For IPv4, I'm not sure given the current state of IP Options support > > > in routers that it's feasible to add a new IP option for this. As an > > > alternative I'd suggest to use the Fragment Header defined in RFC8200 > > > in IPv4. This is discussed in section 2.1.2 of draft-herbert-ipv4-eh. > > > > I have thought many times about adopting IPv6 extension headers in > > IPv4 packets and have proposed it several times with no uptake. An IPv4 > > option seems like a cleaner uptake for the IPv4 architecture. > > It's likely a case where real world considerations trump aspirations > of architectural purity. > > Tom > > > > > Fred > > > > > Tom > > > > > > > > > > > Fred > > > > > > > > > -----Original Message----- > > > > > From: Templin (US), Fred L > > > > > Sent: Friday, September 01, 2023 8:11 AM > > > > > To: 'Tom Herbert' <tom=40herbertland....@dmarc.ietf.org>; Templin > > > > > (US), Fred L > <Fred.L.Templin=40boeing....@dmarc.ietf.org> > > > > > Cc: int-area@ietf.org; i...@ietf.org > > > > > Subject: Re: [IPv6] [Int-area] FW: I-D Action: > > > > > draft-templin-intarea-ipid-ext-04.txt > > > > > > > > > > Tom, see below: > > > > > > > > > > > Hi Fred, > > > > > > > > > > > > I don't see how the Hop-by-Hop Option can work. In IPv6, > > > > > > fragmentation > > > > > > is always end to end so a Hop-by-Hop Option really isn't > > > > > > appropriate. > > > > > > It should be a Destination Option, but then we'd have to have > > > > > > DestOps > > > > > > before the Frag header but after any Routing Header which would > > > > > > diverge from the recommended EH ordering in section 4.1 of RFC8200. > > > > > > Also, it seems the high order bits of the option type can't be 00 > > > > > > (presumably the option must be processed in order to correctly > > > > > > perform > > > > > > reassembly), if this is done in a Hop-by-Hop Options then an > > > > > > intermediate node may drop the packet even though it doesn't care > > > > > > about fragmentation. > > > > > > > > > > This started out as a destination option *after* the Fragment header > > > > > but *before* > > > > > the Routing header according to the order stipulated in RFC8200. But, > > > > > then I > > > > > realized that I wanted to enable network fragmentation for IPv6 and > > > > > for that > > > > > I needed a hop-by-hop option to tell intermediate IPv6 hops that > > > > > recognize > > > > > the option that fragmentation is permitted. This document updates > > > > > RFC8200. > > > > > > > > > > Fred > > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > > > The IETF datatracker status page for this Internet-Draft is: > > > > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/ > > > > > > > > > > > > > > There is also an HTMLized version available at: > > > > > > > https://datatracker.ietf.org/doc/html/draft-templin-intarea-ipid-ext-04 > > > > > > > > > > > > > > A diff from the previous version is available at: > > > > > > > https://author-tools.ietf.org/iddiff?url2=draft-templin-intarea-ipid-ext-04 > > > > > > > > > > > > > > Internet-Drafts are also available by rsync at: > > > > > > > rsync.ietf.org::internet-drafts > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > I-D-Announce mailing list > > > > > > > i-d-annou...@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Int-area mailing list > > > > > > > Int-area@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/int-area > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > IETF IPv6 working group mailing list > > > > > > i...@ietf.org > > > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > -------------------------------------------------------------------- > > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
