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

Joe Touch <> Tue, 17 March 2020 06:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B8F23A18C7 for <>; Mon, 16 Mar 2020 23:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sIwzeqeeEYkL for <>; Mon, 16 Mar 2020 23:14:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C0143A18C4 for <>; Mon, 16 Mar 2020 23:14:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=WFrPpR4ORl4jItQLB/tT/FIo1xkJmM5kWMtnBj3A+94=; b=DM5laUjyqlqgibZ2l3NNLJzWsE h4KEpOu/njEL4e/WHXt7aufAeqYXcp0yhdVUvZuk86Z1jWtJsDWHJlYtDsrY86GFXpyHrqDx1O2vc jeJ1Ig/8EVDoylq5GoZb7r+MBTWzqVHRYS5JPRupSbRv8KoWzOZwmwCIYsZ6CtMyBpKafw1ydOjAT L86hGTJwog3gF2cVsuYIsjL+lqxgr+EFD5RQlkdz5fdTYzveYpXXsESZ+wS7h1bnbledSn9Llj0DZ cANlwNgGgPti10IUmUIou5WOBfh4c7R41dhbNX/TtcxyPvKe6kyAGZfU0gCGpcsmDpgY4EkmCiIsk GVczFC9w==;
Received: from ([]:64653 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1jE5UC-001BSO-M2; Tue, 17 Mar 2020 02:14:01 -0400
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Joe Touch <>
In-Reply-To: <>
Date: Mon, 16 Mar 2020 23:13:56 -0700
Cc: "" <>
Message-Id: <>
References: <>
To: "Rodney W. Grimes" <>
X-Mailer: iPad Mail (17D50)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Mar 2020 06:14:09 -0000

> On Mar 16, 2020, at 10:22 PM, Rodney W. Grimes <> wrote:
>>>> On Mar 16, 2020, at 8:09 PM, Rodney W. Grimes <> wrote:
>>>>> On Mar 16, 2020, at 2:42 PM, Jonathan Morton <> wrote:
>>>>>> On 16 Mar, 2020, at 11:38 pm, Joseph Touch <> 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.

The term is defined originally in RFC1122. The 576 value applies to IPv4. It is 1500B in RFC8200 for IPv6.

>>> 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.

Nobody is arguing that fragmentation should be avoided where possible. However, there’s no way to avoid it at a tunnel ingress over the tunnel path unless somehow the ingress KNOWS that EMTU_S can be 1500b. It’s normally 1280 for IPv6. It’s only larger when the tunnel path is engineered that way over known links or when the ingress runs PLPMTUD. 

The choice of 1280 allows for the POTENTIAL to avoid fragmentation *IF* the path is known engineered for 1500B or PLPMTUD runs between ingress and egress. But that choice doesn’t ENSURE fragmentation is avoided.