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

[Bob Briscoe <[e-mail]>]

Ignacio,

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 
draft-ietf-tsvwg-rfc6040shim-update.

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

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 
header"

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.


Bob

>
> -Ignacio
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/