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

Bob Briscoe <> Thu, 01 June 2017 13:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9024112EC34 for <>; Thu, 1 Jun 2017 06:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 zGJtvECPW14l for <>; Thu, 1 Jun 2017 06:09:08 -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 380E312EC35 for <>; Thu, 1 Jun 2017 06:09:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:From:Subject: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=q6xv70Pk9bRS+JmqPk3OlrVWM/J8D4FWUIsT6tEX3e0=; b=5sltv4K4F7SAyh3zrDw4Ms4Ww0 Qp6NduLvpyiFTaT1HSrvGL5JKKYJLOqIeFLs0Xb4HSEMgYOfCys7YZSkqcf62aw6c/HEzzBQiQLx9 1wYlf4A0cb1djypBIZDp0ymWmAT7W+d2JKj93uvRGLSCgEqt8cSxCioXhVZ9hFz06n7PFFmehdZpc JH+9xdFadG9yWqwUEggpp09Vwl0oyc+P660hdV0HrHllZfGn9puITWhC+pDPUdeXHvp9x9BQQjqMQ rZbIEbAx38R7YAHFbj9AExOswK5B4uYlGVt6qiM5qkL9OOpdiddYGr/5kdrPoa3AnBEZN3Og18XLM kotgHdag==;
Received: from [] (port=58824 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <>) id 1dGPqb-0007ya-M4; Thu, 01 Jun 2017 14:09:05 +0100
From: Bob Briscoe <>
To: Ignacio Goyret <>
Cc: "Black, David" <>, l2tp IETF list <>
References: <> <> <> <> <> <> <> <> <>
Message-ID: <>
Date: Thu, 1 Jun 2017 14:09:05 +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: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Thu, 01 Jun 2017 13:09:10 -0000


I realized that my previous email may have come across as critical of 
L2TP implementers that don't already comply with RFC6040. No criticism 
was intended - it is not at all easy to determine which specs to follow 
- one reason for this clarifying draft.

I've also corrected one sentence below...

On 01/06/17 05:02, Bob Briscoe wrote:
> Ignacio,
> On 01/06/17 00:55, Ignacio Goyret wrote:
>> At 15:11 5/31/2017, Bob Briscoe wrote:
>>>> I do not understand however why "Update", or what that implies to
>>>> a compliant implementation. Many features of L2TP are specified in
>>>> various WGs, not "Updating" the base specs.
>>> By my understanding of the word extension, if a implementation that
>>> is compliant with RFC3931 does not implement an extension, it is
>>> still compliant with RFC3931. Is this how the word "extension" is
>>> used in L2TP land?
>>> 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'm not sure you will get much traction for a "mandatory" update
>> because it would immediately invalidate any compliant deployed code
>> out there.
> I'm not asking for permission to make something mandatory. RFC6040 (or 
> its predecessors {Note 1}) is already mandatory.
> draft-ietf-tsvwg-rfc6040update-shim is just the "messenger", telling 
> L2TP implementers that RFC6040 is already mandatory.
> A mandatory update wouldn't invalidate any compliant deployed code, 
> because the only way that deployed code could be compliant would be to 
> already comply with RFC6040 or its predecessors. There is no other RFC 
> that says how to construct an ECN field during tunnelling. The 
> standards track predecessors of RFC6040 pre-dated L2TPv3 by 3.5 years. 
> And the experimental track predecessor of ECN tunnelling pre-dated 
> L2TPv2.
> The ECN field is in the main IP header (v4 and v6). It cannot be 
> omitted. When an L2TPv3 implementation creates an outer IP header 
> during encap, or forwards an IP header after decap, it has to set the 
> new ECN fields to some value. One would hope that an implementer would 
> try to find a spec to follow, rather than guessing this value. There 
> is only one RFC that says how to construct the ECN field during 
> tunnelling (RFC6040 or its predecessors). If an implementer has not 
> complied with one of these, she has not complied with the Internet 
> Protocol.
> draft-ietf-tsvwg-rfc6040update-shim is not changing the technical 
> effect of the ECN tunnelling spec [RFC6040]. All it is really doing is:
> a) Typing "Updates: 3931" at the top of a proposed RFC. This would 
> ideally have been typed at the top of the original ECN RFC [RFC3168]. 
> This flags to L2TP implementers that they need to take note of the 
> standards track update to IP tunnelling that happened in 2001. 
> Because, like you say, real life dictates there will be some L2TP 
> implementations that don't do it right.
> b) and helping to do it right, by providing the L2TP negotiation 
> machinery (that is also already mandatory for any tunnelling of IP in 
> IP).
> {Note 1}: The predecessors of RFC6040 are RFC3168 and RFC4301. They 
> all have the same technical effect - the deltas between them merely 
> altered trivia like handling combinations of ECN fields that wouldn't 
> normally be expected and other tinkering round the edges.
>> This goes back to the question of why negotiate it if it is mandatory.
> The standards action that is mandatory is compliance with RFC6040, 
> which made it mandatory to negotiate (or use configuration).
> Specifically, RFC6040 made it mandatory for a tunnel ingress to check 
> for (or be configured for) whether the egress supported ECN decap. In 
> the predecessors to RFC6040, negotiation was only specified for IPsec. 
> The only other type of tunnel considered was an RFC2003 tunnel, where 
> no negotiation of tunnel set up process had been defined, so 
> negotiation wasn't discussed for that case.
[BB adds:] RFC3168 did mention MPLS, GRE, L2TP and PPTP, but just said 
they "will be considered as the need arises"
>> Real life says that there will be some L2TP deployments that will
>> support ECN and some that won't, thus, the negotiation is needed
>> to maintain interoperability.
>> But if the negotiation is required, then this can't be an update
>> since it must allow for LCCEs that don't support ECN (which it must,
>> because some deployments may choose (or may have to) stay with
>> their non-ECN supporting code for a variety of reasons).
> As above, the update is to make negotiation mandatory.
> I hope this helps clarify.

> Cheers
> Bob
>> Yes, I know: it is sort of a circular argument but hopefully you
>> see what I mean.
>> -Ignacio

Bob Briscoe