Re: [Int-area] [EXTERNAL] Re: "Identification Extension for the Internet Protocol" question

[Tom Herbert <[e-mail]>]

On Mon, Nov 27, 2023 at 12:42 PM Templin (US), Fred L
<[e-mail]> wrote:
>
> Tom,
>
> > > I think the best way forward would be to simply define a HBH option
> > > that includes an Identification extension to the standard Fragment
> > > Header, as per my draft -05:
> > >
> > Hi Frad,
> >
> > The problem with that is that the correct processing of the Fragment
> > Header would depend on a HBH option, so that HBH can't be ignored by
> > the receiving host lest the fragment header is incorrectly processed.
> > So the HBH option high order bits can't be 00 (skip when unknown).
>
> If the source has some sort of operational assurance that the destination will
> recognize the HBH option, then it should be OK to include the option even if
> the high order bits are 00. And, that is plenty good enough for me.

Fred,

Unfortunately, that probably wouldn't be good enough for IETF. IP is
an inherently stateless protocol and receiver processing must be
correctly done just based on a packet's contents; we can never assume
that there is external context needed to correctly process IP packets.
Introducing statefulness into IP makes it a best effort protocol (this
is the first time someone's suggested this) that might work almost all
the time-- like maybe 99.999%. But, 99.999% isn't 100% and that is
enough to say the protocol isn't robust. In practice, at full Internet
scale, someone, somewhere will inevitably see that some operation
assurance fails-- when that happens it cannot lead to detrimental
behaviors. If you can account for all possible behaviors and show that
there are no detrimental behaviors in the edge condition, then the
protocol might be considered robust.

Tom

>
> Thanks - Fred
>
> > -----Original Message-----
> > From: Tom Herbert <[e-mail]>
> > Sent: Monday, November 27, 2023 11:31 AM
> > To: Templin (US), Fred L <[e-mail]>
> > Cc: int-area <[e-mail]>
> > Subject: [EXTERNAL] Re: "Identification Extension for the Internet Protocol" question
> >
> > EXT email: be mindful of links/attachments.
> >
> >
> >
> > On Mon, Nov 27, 2023 at 9:24 AM Templin (US), Fred L
> > <[e-mail]> wrote:
> > >
> > > Hi Tom,
> > >
> > > > -----Original Message-----
> > > > From: Tom Herbert <[e-mail]>
> > > > Sent: Monday, November 27, 2023 9:00 AM
> > > > To: Templin (US), Fred L <[e-mail]>
> > > > Cc: int-area <[e-mail]>
> > > > Subject: Re: "Identification Extension for the Internet Protocol" question
> > > >
> > > > On Mon, Nov 27, 2023 at 8:01 AM Templin (US), Fred L
> > > > <[e-mail]> wrote:
> > > > >
> > > > > Hi Tom,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Tom Herbert <[e-mail]>
> > > > > > Sent: Friday, November 24, 2023 11:33 AM
> > > > > > To: Templin (US), Fred L <[e-mail]>
> > > > > > Cc: int-area <[e-mail]>
> > > > > > Subject: Re: "Identification Extension for the Internet Protocol" question
> > > > > >
> > > > > > On Wed, Nov 22, 2023 at 10:57 AM Templin (US), Fred L
> > > > > > <[e-mail]> 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.
> > > > >
> > > > > How would it be if instead of repurposing the fragmentation control fields
> > > > > in the second Fragment Header we instead make them to be identical copies
> > > > > of the same fields that occurred in the first Fragment Header? Then, the
> > > > > Identification field in the first FH would contain the low-order 4 octets
> > > > > while the Identification field in the second FH would contain the
> > > > > high-order 4 octets of an 8-octet (64-bit) extended Identification,
> > > > > while the fragmentation control fields are identical? I would ideally
> > > > > like to be able to support Identification extension all the way out to
> > > > > 128bits, but I would be happy with 64bits for now.
> > > >
> > > > Hi Fred,
> > > >
> > > > I think the question to be asked is what happens if we send two
> > > > Fragment Headers to a host that is conformant with RFC8200 but unaware
> > > > of the proposed semantics. I don't believe this would "just work" and
> > > > probably a receiver would re-assemble the based on the first header
> > > > resulting in an ill-formed fragment which I suppose would most likely
> > > > timeout since reassembly wouldn't complete.  Is the behavior
> > > > deterministic? Are there security ramifications? etc.
> > >
> > > OK, I am willing to let this go. It might be worth adding something to an
> > > "EH limits" draft saying what should be done with IPv6 packets that contain
> > > more than one Fragment Header - should they simply be dropped, for instance?
> > >
> > > > > > IMO, defining a new Hop-by-Hop option for fragmentation still seems
> > > > > > more palatable.
> > > > >
> > > > > This kind of comes back full circle to where this began, where in draft versions
> > > > > -05 and before my original proposal was to use a HBH option for Identification
> > > > > extension maintained separately from the Fragment Header:
> > > > >
> > > > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/05/
> > > > >
> > > > > Are you suggesting to go back to that approach?
> > > > >
> > > > > > General comments:
> > > > > >
> > > > > > Defining a new Hop-by-Hop option for fragmentation still seems more
> > > > > > palatable to me.
> > > > >
> > > > > Oh, so maybe what you are suggesting is a "full service" HBH option that
> > > > > includes not only the (extended) Identification but also the same type of
> > > > > fragmentation control fields that occur in the Fragment Header? So, in
> > > > > other words, to support the fragmentation operation one would use this
> > > > > new HBH option instead of (and not in addition to) the standard FH? If
> > > > > so, I get the picture but I wonder how it would work. IPv6 extension
> > > > > header order is:
> > > > >
> > > > >       IPv6 header
> > > > >       Hop-by-Hop Options header
> > > > >       Destination Options header (note 1)
> > > > >       Routing header
> > > > >       Fragment header
> > > > >       Authentication header (note 2)
> > > > >       Encapsulating Security Payload header (note 2)
> > > > >       Destination Options header (note 3)
> > > > >       Upper-Layer header
> > > > >
> > > > > So, if fragmentation controls occurred in the HBH header, wouldn't it
> > > > > foul up any intermediate destinations that may be named in a Routing
> > > > > Header that follows? Even if we made it as a Destination Option and
> > > > > not a HBH, the Routing Header still occurs internally to each fragment,
> > > > > right? Can you picture a way to orchestrate the fragmentation and
> > > > > reassembly processes at the HBH level that would not impede
> > > > > Routing Header processing? Or, maybe as long as the headers
> > > > > still appear in the same order as above everything just works out?
> > > > >
> > > >
> > > > Yes, you are correct. Fragmentation in HBH with a Routing Header
> > > > wouldn't work. Destination options might be the only robust way.
> > >
> > > There are two places where Destination Options can occur - immediately
> > > before the Routing Header (note 1 above) or immediately before the
> > > Upper-Layer header (note 3 above). The first alternative runs into the
> > > same problem as for HBH, and the second alternative both requires
> > > altering Next Header field contents and also occurs after any security
> > > headers whereas fragmentation should occur before the security
> > > headers.
> > >
> > > I think the best way forward would be to simply define a HBH option
> > > that includes an Identification extension to the standard Fragment
> > > Header, as per my draft -05:
> > >
> > Hi Frad,
> >
> > The problem with that is that the correct processing of the Fragment
> > Header would depend on a HBH option, so that HBH can't be ignored by
> > the receiving host lest the fragment header is incorrectly processed.
> > So the HBH option high order bits can't be 00 (skip when unknown). We
> > could make the HBH option type 01 to ensure the destination host knows
> > about the new semantics of the Frag header or drops the packet. The
> > problem with that is that any router in the path that doesn't
> > understand the new option could potentially drop the packet. This
> > doesn't work in Destination Options before the routing header either,
> > if we set the type to 01 then in DestOpts before the routing header
> > then intermediate nodes may drop the packet.
> >
> > I believe the best chance to add an alternative fragmentation in the
> > IP layer is to define a new Destination option (not before the routing
> > header), high order bits 01, contain the real NextHeader value, and
> > set the DestOpts NextHeader to 47. If the destination host doesn't
> > recognize the option then it will drop the packet, and if the option
> > is supported by the destination host then reassembly can occur and the
> > next header in the reassembled packet following the Destination
> > Options is from the NextHeader field of the option (in the first
> > fragment). If any routers in the path attempt to skip over the
> > Destination options header looking for the transport layer, like they
> > might do for port filtering, then they won't be able to do anything
> > with data after the DestOpts since its type is "no next header" (47).
> >
> > One problem with this approach is that Auth and ESP header come before
> > Destination Options in RFC8200 ordering recommendation, we'd really
> > want the DestOps containing a fragment option to come before them
> > (like at the same position in recommended ordering as Frag Header). I
> > don't believe this is a show stopper because the ordering and number
> > of occurrences of EH are only recommendations in RFC8200,  but there
> > should be some thought into any potential ramifications if this path
> > is taken.
> >
> > Tom
> >
> > > https://datatracker.ietf.org/doc/draft-templin-intarea-ipid-ext/05/
> > >
> > > and let fragmentation and reassembly operate at the same levels
> > > they always have. What do you think?
> > >
> > > > > > 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.
> > > > >
> > > > > I would not be opposed to splitting the document if it would help
> > > > > forward progress.
> > > > >
> > > > > > 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.
> > > > >
> > > > > I could see removing the references to IP parcels and OMNI, but I
> > > > > think we still need to define the new PTB Code values since the
> > > > > control messaging aspects of what is being proposed are equally
> > > > > as important as the Identification extension itself. Can we keep at
> > > > > least that much in a new reduced-scope draft that would go to 6man?
> > > >
> > > > Sure, maybe it could be listed some use cases as informative
> > > > references. It's going to be easier for your readers if a draft like
> > > > this is self-contained and doesn't require a working knowledge outside
> > > > of IPv4 or IPv6 protocol.
> > >
> > > Maybe a non-normative appendix?
> > >
> > > Thank you - Fred
> > >
> > > > Tom
> > > >
> > > >
> > > > >
> > > > > Thank you - Fred
> > > > >
> > > > > > Tom
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Thank you – Fred
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > From: Templin (US), Fred L <Fred.L.Templin=[e-mail]>
> > > > > > > Sent: Tuesday, November 21, 2023 7:14 PM
> > > > > > > To: Tom Herbert <[e-mail]>; Templin (US), Fred L <[e-mail]>
> > > > > > > Cc: int-area <[e-mail]>
> > > > > > > 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 <[e-mail]>
> > > > > > > Sent: Tuesday, November 21, 2023 4:22 PM
> > > > > > > To: Templin (US), Fred L <Fred.L.Templin=[e-mail]>
> > > > > > > Cc: Templin (US), Fred L <[e-mail]>; int-area <[e-mail]>
> > > > > > > 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=[e-mail]> 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 <[e-mail]> On Behalf Of Templin (US), Fred L
> > > > > > > Sent: Tuesday, November 21, 2023 1:30 PM
> > > > > > > To: Tom Herbert <tom=[e-mail]>
> > > > > > > Cc: int-area <[e-mail]>
> > > > > > > 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=[e-mail]>
> > > > > > > Sent: Tuesday, November 21, 2023 1:11 PM
> > > > > > > To: Templin (US), Fred L <[e-mail]>
> > > > > > > Cc: int-area <[e-mail]>
> > > > > > > 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=[e-mail]> 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=[e-mail]>
> > > > > > > Sent: Tuesday, November 21, 2023 12:04 PM
> > > > > > > To: Templin (US), Fred L <[e-mail]>
> > > > > > > Cc: int-area <[e-mail]>
> > > > > > > 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=[e-mail]> 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
> > > > > > > [e-mail]
> > > > > > > https://www.ietf.org/mailman/listinfo/int-area
> > > > >
> > >
>