Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

["Rodney W. Grimes" <[e-mail]>]

> 
> 
> > On Mar 16, 2020, at 2:42 PM, Jonathan Morton <[e-mail]> wrote:
> > 
> >> On 16 Mar, 2020, at 11:38 pm, Joseph Touch <[e-mail]> wrote:
> >> 
> >> That?s not always possible. If the net runs over minimal IPv6 links, there?s no way to ensure a traffic can support 1280B packets over 1280B tunnels.

True, not always possible, but very often practical and done as minimal IPv6 links generally only exist inside of tunneled tunnels :-)  ((Ie, GRE -> IPSec -> PPPoE))

> > 
> > I think the 1280B minimum was intended to allow for the possibility of running through tunnels on conventional 1500B physical networks.
> 
> Actually, the 1280B is the path min; the receiver min is 1500B exactly to allow for this sort of frag/reassembly (where a tunnel egress *is* such a receiver). The 1500B comes from Ethernet; the 1280B is smaller deliberately.

receiver min?  I am not familiar with that term.

And as you state 1500B no doubt comes from the Ethernet specification.

I shall endorse Jonathans position with this:
	The 1280 IPv6 minMTU originated from a November 14, 1997 mailing
	from Steve Deering to the IPng mailing list, which stated:
	"In the ipngwg meeting in Munich, I proposed increasing the IPv6
        minimum MTU from 576 bytes to something closer to the Ethernet MTU
        of 1500 bytes, (i.e., 1500 minus room for a couple layers of
        encapsulating headers, so that min- MTU-size packets that are
        tunneled across 1500-byte-MTU paths won't be subject to
        fragmentation/reassembly on ingress/egress from the tunnels, in most
        cases).

So infact this is all meant to MINIMIZE fragmentation.

> Joe
-- 
Rod Grimes                                                 [e-mail]