Re: Propagating IP/ECN field when L2TP sits between IP as both L2 payload and PSN
Ignacio Goyret <[email protected]> Thu, 1 Jun 2017 13:24:10 -0700
| Newsgroups | gmane.ietf.l2tpext |
|---|---|
| Message-ID | <[email protected]> |
>> 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. >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. -Ignacio