Re: [L2tpext] Propagating IP/ECN field when L2TP sits between IP as both L2 payload and PSN

Bob Briscoe <> Fri, 02 June 2017 13:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD107129B75 for <>; Fri, 2 Jun 2017 06:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 QiYCAxLPpQAi for <>; Fri, 2 Jun 2017 06:24: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 3638A126DCA for <>; Fri, 2 Jun 2017 06:24:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding: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=NRCinc/Fn1UNrt6dPiIRe6gVZnmI0sqMpkDQBqPfTLE=; b=7k4q70FJtEdK2jLPeMvo0M2Bt 9t2tucrm8MTeTN71BOoLLqOwq4Es1lm8DW4/RhHrdeel9Cvo/geA8RV75iKup6pncP55/AuVMZzGn D1pnF/RXmrnYOGAfE03GeqEEGwpdrjZ7pT1BQmX9bbhmUaVnEnzCLnbnMv/4o22swNQEKqm39bjQX SHwvBj9pXAQrly48XdIeJgDA2GZUSFE93OYN3LdKxt480Y/ANnKJiildSPsUsIQ2rTm6ZZmICLugs WIzevuTri1cymHOGGlp8PtpX25UxsA27U4EgxMoy2Zi27q+TSk9FM6A+lq2n1iEs25jeIOMHyfAW/ tCzFxoHkA==;
Received: from ([]:33590 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <>) id 1dGmYZ-0000Eq-Ic; Fri, 02 Jun 2017 14:23:59 +0100
To: Ignacio Goyret <>
Cc: "Black, David" <>, l2tp IETF list <>
References: <> <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Fri, 2 Jun 2017 14:23:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------5702327C13CE5A71D7068A8B"
Content-Language: en-GB
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:
Archived-At: <>
Subject: Re: [L2tpext] Propagating IP/ECN field when L2TP sits between IP as both L2 payload and PSN
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Layer Two Tunneling Protocol Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Jun 2017 13:24:05 -0000


RFC6040 contains the following para:

    If an ingress claims compliance with this specification, it MUST NOT
    permanently disable ECN processing across the tunnel (i.e., only
    using compatibility mode).  It is true that such a tunnel ingress is
    at least safe with the ECN behaviour of any egress it may encounter,
    but it does not meet the central aim of this specification:
    introducing ECN support to tunnels.

To be safe, an L2TP ingress could permanently use compatibility mode. 
Compatibility mode simply involves the ingress clearing the 2-bit ECN 
field in the outer (setting to 00). This would not allow the L2TP 
endpoint to claim compliance with RFC6040, but at least it would be 
safe. I think it would be useful to add this as operational advice to 

I would imagine most implementations of L2TP could be configured to do 
this (do you agree?). I suspect some still allow config of the setting 
the whole 8-bit ToS bytes, in which the 2 lowest significant bits are 
the ECN field (distinct from the 6-bit Diffserv field).

Nonetheless, altho safety is important, the main purpose of this draft 
is to go beyond that - to say how an implementer would add ECN support 
to L2TP. See inline...

On 01/06/17 21:24, Ignacio Goyret wrote:
>>> Whereas, if one IP header encapsulates another, if the ECN field
>>> were processed in any way other than RFC6040, it would be invalid
>>> (unless another RFC were written to update RFC6040). Therefore,
>>> whenever L2TP is tunnelling IP in IP, it is mandatory to comply
>>> with RFC6040. So I am asking the L2TPext WG for advice on how you
>>> guys would make a mandatory update to L2TP, rather than 'just' an
>>> optional extension.
>> I think first we probably need to understand the applicability because
>> it is not an IP-in-IP encap, there's a Layer 2 header in between, not
>> tightly coupled but rather part of the transported payload.
> And an IP header (if present) may be down various layers and not easily
> accessible.
> So far, LCCEs do not need to decapsulate all the stacked layers trying
> to look for a potential IP header. Adding that requirement as a MUST is
> a tall order that may be too onerous and impossible to satisfy.

As recently discussed on int-area, I am going to widen the applicability 
of draft-ietf-tsvwg-rfc6040shim-update to include cases where a L2 
header is being encapsulated. But this wider scope would not be as 

I definitely do not want to make this a MUST. I made this point myself, 
in response to Tom Herbert on the int-area list a couple of days ago, 
pasted here:

> On 31/05/17 02:45, Bob Briscoe wrote:
>> One way to include all these cases in the scope of the draft is to 
>> say the tunnel endpoint SHOULD check the L2 payload for an IP header, 
>> even when the L2 header is not being added / removed. But that is 
>> rather an onerous requirement, don't you think? Especially given this 
>> would be asking the implementer to violate layering, we can only ask 
>> that it is done when feasible; it cannot be a hard requirement (e.g. 
>> L2 payload could be encrypted). 

I think MAY is too weak, but SHOULD is too strong, so how about this 
form of wording:
"If feasible, the tunnel endpoint SHOULD check the L2 payload for an IP 

And I intend to add something along the lines of: "Otherwise, if the 
outer is IP, it MUST zero the outer ECN field."

>> Now, what you describe in terms of level of mandatory applies to RFC 6040.
>> If an implementation does not comply with RFC 6040 it is, well, not
>> compliant with RFC 6040.
> Exactly.
> And that's why I believe this should be a _recommended_ extension when
> inner IP headers can be found easily but it cannot be a mandatory
> requirement for the L2TP protocol as a whole.
As above, I strongly agree with you.


> -Ignacio

Bob Briscoe