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

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

> > On Mar 16, 2020, at 8:09 PM, Rodney W. Grimes <[e-mail]> wrote:
> > 
> >> 
> >> 
> >>> 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.
> 
> EMTU_R as defined in RFC 1122. See also draft-ietf-intarea-tunnels

EMTU_R as defined in RFC 1122 is greater than or equal to 576, not 1500 as you stated.

> 
> > 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.
> 
> Except that it doesn?t unless you KNOW that the path supports 1500B. But there?s no rule in IPv6 that the EMTU_S min is 1280B *AND* the links MUST support 1500B.
> 
> I.e., that?s why the EMTU_S min is 1500B - so you can reassemble when you don?t know otherwise. But even when IPv6 was created there were problems with PMTUD.

EMTU_S min is not 1500B, and infact 1122 says:
	It is generally desirable to avoid local fragmentation and to
	choose EMTU_S low enough to avoid fragmentation in any gateway
	along the path.  In the absence of actual knowledge of the
	minimum MTU along the path, the IP layer SHOULD use
	EMTU_S <= 576 whenever the destination address is not on a
	connected network, and otherwise use the connected network's

Again the intent here appears to be to avoid framentation along the path,
and iirc is what lead the the path MTU being cached by the BSD kernels
route table code, which is one mechansim used by people to deal with
the path MTU problem and tunnels.

> Joe
-- 
Rod Grimes                                                 [e-mail]