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/d
On Tue, Nov 21, 2023, 11:44 AM Templin (US), Fred L 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 e
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 bot
On Tue, Nov 21, 2023, 12:15 PM Templin (US), Fred L 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 potentiall
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 othe
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 He
On Tue, Nov 21, 2023, 2:45 PM Templin (US), Fred L 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 ex
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-Fragme
