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
