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

Ignacio,

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