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

[Bob Briscoe <[e-mail]>]

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.

>
> 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                               http://bobbriscoe.net/