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

["Templin (US), Fred L" <[e-mail]>]

I will take a swing at what I have in mind, run it up the flagpole in 6man, and see what happens there.

Thanks - Fred

> -----Original Message-----
> From: Tom Herbert <[e-mail]>
> Sent: Monday, November 27, 2023 1:01 PM
> To: Templin (US), Fred L <[e-mail]>
> Cc: int-area <[e-mail]>
> Subject: Re: [EXTERNAL] Re: "Identification Extension for the Internet Protocol" question
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> 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
> > > > > >
> > > >
> >