draft-ietf-tsvwg-rfc6040update-shim-02.txt   draft-ietf-tsvwg-rfc6040update-shim-03.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft Simula Research Laboratory Internet-Draft Simula Research Laboratory
Updates: 6040, 2661, 2784, 3931, 4380 June 16, 2017 Updates: 6040, 2661, 2784, 3931, 4380 June 27, 2017
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: December 18, 2017 Expires: December 29, 2017
Propagating Explicit Congestion Notification Across IP Tunnel Headers Propagating Explicit Congestion Notification Across IP Tunnel Headers
Separated by a Shim Separated by a Shim
draft-ietf-tsvwg-rfc6040update-shim-02 draft-ietf-tsvwg-rfc6040update-shim-03
Abstract Abstract
RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
rules for propagation of ECN consistent for all forms of IP in IP rules for propagation of ECN consistent for all forms of IP in IP
tunnel. This specification extends the scope of RFC 6040 to include tunnel. This specification updates RFC 6040 to clarify that its
tunnels where two IP headers are separated by at least one shim scope includes tunnels where two IP headers are separated by at least
header that is not sufficient on its own for packet forwarding. It one shim header that is not sufficient on its own for wide area
surveys widely deployed IP tunnelling protocols separated by a shim packet forwarding. It surveys widely deployed IP tunnelling
and updates the specifications of those that do not mention ECN protocols separated by such shim header(s) and updates the
propagation (L2TPv2, L2TPv3, GRE and Teredo). The specification also specifications of those that do not mention ECN propagation (L2TPv2,
updates RFC 6040 with configuration requirements needed to make any L2TPv3, GRE and Teredo). This specification also updates RFC 6040
legacy tunnel ingress safe. with configuration requirements needed to make any legacy tunnel
ingress safe.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 18, 2017. This Internet-Draft will expire on December 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 3 3. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . 3 3.1. Feasibility of ECN Propagation between Tunnel Headers . . 4
3.2. Making a non-ECN Tunnel Ingress Safe by Configuration . . 4 3.2. Desirability of ECN Propagation between Tunnel Headers . 5
3.3. Specific Updates to Protocols under IETF Change Control . 6 4. Making a non-ECN Tunnel Ingress Safe by Configuration . . . . 5
3.3.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 8 5. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 6
3.3.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Specific Updates to Protocols under IETF Change Control . 8
3.3.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 12
6. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
RFC 6040 on "Tunnelling of Explicit Congestion Notification" RFC 6040 on "Tunnelling of Explicit Congestion Notification"
[RFC6040] made the rules for propagation of Explicit Congestion [RFC6040] made the rules for propagation of Explicit Congestion
Notification (ECN [RFC3168]) consistent for all forms of IP in IP Notification (ECN [RFC3168]) consistent for all forms of IP in IP
tunnel. tunnel.
A common pattern for many tunnelling protocols is to encapsulate an A common pattern for many tunnelling protocols is to encapsulate an
inner IP header (v4 or v6) with shim header(s) then an outer IP inner IP header (v4 or v6) with shim header(s) then an outer IP
skipping to change at page 3, line 21 skipping to change at page 3, line 23
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] document are to be interpreted as described in RFC 2119 [RFC2119]
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
This specification uses the terminology defined in RFC 6040 This specification uses the terminology defined in RFC 6040
[RFC6040]. [RFC6040].
3. IP-in-IP Tunnels with Tightly Coupled Shim Headers 3. Scope of RFC 6040
3.1. Scope of RFC 6040
In many cases the shim header(s) and the outer IP header are always
added (or removed) as part of the same process. We call this a
tightly coupled shim header. Processing the shim and outer together
is often necessary because the shim(s) are not sufficient for packet
forwarding in their own right; not unless complemented by an outer
header.
In some cases a tunnel adds an outer IP header and a tightly coupled
shim header to an inner header that is not an IP header, but that in
turn encapsulates an IP header (or might encapsulate an IP header).
For instance an inner Ethernet (or other link layer) header might
encapsulate an inner IP header as its payload. We call this a
tightly coupled shim over an encapsulating header.
In section 1.1 of RFC 6040 its scope was defined as: In section 1.1 of RFC 6040, its scope is defined as:
"...ECN field processing at encapsulation and decapsulation for "...ECN field processing at encapsulation and decapsulation for
any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It
applies irrespective of whether IPv4 or IPv6 is used for either applies irrespective of whether IPv4 or IPv6 is used for either
the inner or outer headers. ..." the inner or outer headers. ..."
This specification updates RFC 6040 by adding the following scoping This was intended to include cases where shim header(s) sit between
text after the sentences quoted above: the IP headers. Many tunnelling implementers have interpreted the
scope of RFC 6040 as it was intended, but it is ambiguous.
Therefore, this specification updates RFC 6040 by adding the
following scoping text after the sentences quoted above:
It applies in cases where an outer IP header encapsulates an inner It applies in cases where an outer IP header encapsulates an inner
IP header either directly or indirectly by encapsulating other IP header either directly or indirectly by encapsulating other
headers that in turn encapsulate (or might encapsulate) an inner headers that in turn encapsulate (or might encapsulate) an inner
IP header. IP header.
There is another problem with the scope of RFC 6040. Like many IETF
specifications, RFC 6040 is written as a specification that
implementations can choose to claim compliance with. This means it
does not cover two important cases:
1. those cases where it is infeasible for an implementation to
access an inner IP header when adding or removing an outer IP
header;
2. those implementations that choose not to propagate ECN between IP
headers.
However, the ECN field is a non-optional part of the IP header (v4
and v6). So any implementation that creates an outer IP header has
to give the ECN field some value. There is only one safe value a
tunnel ingress can use if it does not know whether the egress
supports propagation of the ECN field; it has to zero the ECN field
in any outer IP header.
However, an RFC has no jurisdiction over implementations that choose
not to comply with it or cannot comply with it, including all those
implementations that pre-dated the RFC. Therefore it would have been
unreasonable to add such a requirement to RFC 6040. Nonetheless, to
ensure safe propagation of the ECN field over tunnels, it is
reasonable to add requirements on operators, to ensure they configure
their tunnels safely (where possible). Before stating these
configuration requirements in Section 4, the factors that determine
whether propagating ECN is feasible or desirable will be briefly
introduced.
3.1. Feasibility of ECN Propagation between Tunnel Headers
In many cases shim header(s) and an outer IP header are always added
to (or removed from) an inner IP packet as part of the same
procedure. We call this a tightly coupled shim header. Processing
the shim and outer together is often necessary because the shim(s)
are not sufficient for packet forwarding in their own right; not
unless complemented by an outer header. In these cases it will often
be feasible for an implementation to propagate the ECN field between
the IP headers.
In some cases a tunnel adds an outer IP header and a tightly coupled
shim header to an inner header that is not an IP header, but that in
turn encapsulates an IP header (or might encapsulate an IP header).
For instance an inner Ethernet (or other link layer) header might
encapsulate an inner IP header as its payload. We call this a
tightly coupled shim over an encapsulating header.
Digging to arbitrary depths to find an inner IP header within an Digging to arbitrary depths to find an inner IP header within an
encapsulation is strictly a layering violation so it cannot be a encapsulation is strictly a layering violation so it cannot be a
required behaviour. Nonetheless, some tunnel endpoints already look required behaviour. Nonetheless, some tunnel endpoints already look
within a L2 header for an IP header, for instance to map the Diffserv within a L2 header for an IP header, for instance to map the Diffserv
codepoint between an encapsulated IP header and an outer IP header codepoint between an encapsulated IP header and an outer IP header
[RFC2983]. In such cases at least, it should be feasible to also [RFC2983]. In such cases at least, it should be feasible to also
(independently) propagate the ECN field between the same IP headers. (independently) propagate the ECN field between the same IP headers.
Thus, as long as the guidelines in section 6 of Thus, access to the ECN field within an encapsulating header can be a
[I-D.ietf-tsvwg-ecn-encap-guidelines] are followed, access to the ECN useful and benign optimization. The guidelines in section 6 of
field within an encapsulating header can be a useful and benign
optimization. On the other hand, if a tunnel ingress is not willing
to find an inner IP header, Section 3.2 below specifies that it has
to disable the ECN capability in the outer header by zeroing the ECN
field.
3.2. Making a non-ECN Tunnel Ingress Safe by Configuration [I-D.ietf-tsvwg-ecn-encap-guidelines] give the conditions for this
layering violation to be benign.
3.2. Desirability of ECN Propagation between Tunnel Headers
Developers and network operators are encouraged to implement and
deploy tunnel endpoints compliant with RFC 6040 (as updated by the
present specification) in order to provide the benefits of wider ECN
deployment [RFC8087]. Nonetheless, propagation of ECN between IP
headers, whether separated by shim headers or not, has to be optional
to implement and to use, because:
o Legacy implementations of tunnels without any ECN support already
exist
o A network might be designed so that there is usually no bottleneck
within the tunnel
o If the tunnel endpoints would have to search within an L2 header
to find an encapsulated IP header, it might not be worth the
potential performance hit
4. Making a non-ECN Tunnel Ingress Safe by Configuration
Even when ECN propagation is not implemented or is not being used, it Even when ECN propagation is not implemented or is not being used, it
ought to be possible to render a tunnel ingress safe by ought to be possible to render a tunnel ingress safe by
configuration. The main safety concern is to disable the ECN configuration. The main safety concern is to disable the ECN
capability in the outer IP header if the egress of the tunnel does capability in the outer IP header if the egress of the tunnel does
not implement ECN logic to propagate any ECN markings into the packet not implement ECN logic to propagate any ECN markings into the packet
forwarded beyond the tunnel. Otherwise the non-ECN egress could forwarded beyond the tunnel. Otherwise the non-ECN egress could
discard any ECN marking introduced within the tunnel, which would discard any ECN marking introduced within the tunnel, which would
break all the ECN-based control loops that regulate the traffic load break all the ECN-based control loops that regulate the traffic load
over the tunnel. over the tunnel.
skipping to change at page 5, line 32 skipping to change at page 6, line 36
still treating the ToS octet (IPv4) or the Traffic Class octet (IPv6) still treating the ToS octet (IPv4) or the Traffic Class octet (IPv6)
as a single 8-bit field is already non-compliant, and has been since as a single 8-bit field is already non-compliant, and has been since
1998 when the upper 6 bits were separated off for the Diffserv 1998 when the upper 6 bits were separated off for the Diffserv
codepoint (DSCP) [RFC2474]. For instance, copying the ECN field as a codepoint (DSCP) [RFC2474]. For instance, copying the ECN field as a
side-effect of copying the DSCP is a seriously unsafe bug that risks side-effect of copying the DSCP is a seriously unsafe bug that risks
breaking the feedback loops that regulate load on a tunnel. breaking the feedback loops that regulate load on a tunnel.
Permanently zeroing the outer ECN field is safe, but it is not Permanently zeroing the outer ECN field is safe, but it is not
sufficient to claim compliance with RFC 6040 because it does not meet sufficient to claim compliance with RFC 6040 because it does not meet
the aim of introducing ECN support to tunnels (see Section 4.3 of the aim of introducing ECN support to tunnels (see Section 4.3 of
[RFC6040]). Developers and network operators are encouraged to [RFC6040]).
implement and deploy tunnel endpoints compliant with RFC 6040 (as
updated by the present specification) in order to provide the
benefits of wider ECN deployment [RFC8087]. Nonetheless, propagation
of ECN between IP headers, whether separated by shim headers or not,
has to be OPTIONAL to implement and to use, because:
o Legacy implementations of tunnels without any ECN support already
exist
o A network might be designed so that there is usually no bottleneck
within the tunnel
o If the tunnel endpoints would have to search within an L2 header
to find an encapsulated IP header, it might not be worth the
potential performance hit
3.3. Specific Updates to Protocols under IETF Change Control 5. IP-in-IP Tunnels with Tightly Coupled Shim Headers
There follows a list of specifications of encapsulations with tightly There follows a list of specifications of encapsulations with tightly
coupled shim header(s). The list is not necessarily exhaustive so, coupled shim header(s), in rough chronological order. The list is
for the avoidance of doubt, RFC 6040 applies to all tightly coupled confined to standards track or widely deployed protocols. The list
shim headers whether or not they are listed here and whether or not is not necessarily exhaustive so, for the avoidance of doubt, the
the shim encapsulates an IP header or a different header that scope of RFC 6040 is defined in Section 3 and is not limited to this
encapsulates (or might encapsulate) an IP header. The list is list.
confined to standards track or widely deployed protocols.
o PPTP (Point-to-Point Tunneling Protocol) [RFC2637]; o PPTP (Point-to-Point Tunneling Protocol) [RFC2637];
o L2TP (Layer 2 Tunnelling Protocol), specifically L2TPv2 [RFC2661] o L2TP (Layer 2 Tunnelling Protocol), specifically L2TPv2 [RFC2661]
and L2TPv3 [RFC3931], which not only includes all the L2-specific and L2TPv3 [RFC3931], which not only includes all the L2-specific
specializations of L2TP, but also derivatives such as the Keyed specializations of L2TP, but also derivatives such as the Keyed
IPv6 Tunnel [RFC8159]; IPv6 Tunnel [RFC8159];
o GRE (Generic Routing Encapsulation) [RFC2784] and NVGRE (Network o GRE (Generic Routing Encapsulation) [RFC2784] and NVGRE (Network
Virtualization using GRE) [RFC7637]; Virtualization using GRE) [RFC7637];
skipping to change at page 6, line 38 skipping to change at page 7, line 21
o Teredo [RFC4380]; o Teredo [RFC4380];
o CAPWAP (Control And Provisioning of Wireless Access Points) o CAPWAP (Control And Provisioning of Wireless Access Points)
[RFC5415]; [RFC5415];
o LISP (Locator/Identifier Separation Protocol) [RFC6830]; o LISP (Locator/Identifier Separation Protocol) [RFC6830];
o VXLAN (Virtual eXtensible Local Area Network) [RFC7348] and VXLAN- o VXLAN (Virtual eXtensible Local Area Network) [RFC7348] and VXLAN-
GPE [I-D.ietf-nvo3-vxlan-gpe]; GPE [I-D.ietf-nvo3-vxlan-gpe];
o NSH (Network Service Header) [I-D.ietf-sfc-nsh];
o Geneve [I-D.ietf-nvo3-geneve]; o Geneve [I-D.ietf-nvo3-geneve];
o GUE (Generic UDP Encapsulation) [I-D.ietf-intarea-gue]. o GUE (Generic UDP Encapsulation) [I-D.ietf-intarea-gue].
Some of the listed protocols enable encapsulation of a variety of Some of the listed protocols enable encapsulation of a variety of
network layer protocols as inner and/or outer. This specification network layer protocols as inner and/or outer. This specification
applies in the cases where there is an inner and outer IP header as applies in the cases where there is an inner and outer IP header as
described in Section 3.1. Otherwise described in Section 3. Otherwise
[I-D.ietf-tsvwg-ecn-encap-guidelines] gives guidance on how to design [I-D.ietf-tsvwg-ecn-encap-guidelines] gives guidance on how to design
propagation of ECN into other protocols that might encapsulate IP. propagation of ECN into other protocols that might encapsulate IP.
Where protocols in the above list are under IETF change control and Where protocols in the above list need to be updated to specify ECN
they need to be updated to specify ECN propagation, update text is propagation and they are under IETF change control, update text is
given in the following subsections. For those not under IETF given in the following subsections. For those not under IETF
control, it is RECOMMENDED that implementations of encapsulation and control, it is RECOMMENDED that implementations of encapsulation and
decapsulation comply with RFC 6040. It is also RECOMMENDED that decapsulation comply with RFC 6040. It is also RECOMMENDED that
their specifications are updated to add a requirement to comply with their specifications are updated to add a requirement to comply with
RFC 6040 (as updated by the present document). RFC 6040 (as updated by the present document).
PPTP is not under the change control of the IETF, but it has been PPTP is not under the change control of the IETF, but it has been
documented in an informational RFC [RFC2637]. However, there is no documented in an informational RFC [RFC2637]. However, there is no
need for the present specification to update PPTP because L2TP has need for the present specification to update PPTP because L2TP has
been developed as a standardized replacement. been developed as a standardized replacement.
NVGRE is not under the change control of the IETF, but it has been NVGRE is not under the change control of the IETF, but it has been
documented in an informational RFC [RFC7637]. NVGRE is a specific documented in an informational RFC [RFC7637]. NVGRE is a specific
use-case of GRE (it re-purposes the key field from the initial use-case of GRE (it re-purposes the key field from the initial
specification of GRE [RFC1701] as a Virtual Subnet ID). Therefore specification of GRE [RFC1701] as a Virtual Subnet ID). Therefore
the text that updates GRE in Section 3.3.2 below is also intended to the text that updates GRE in Section 5.1.2 below is also intended to
update NVGRE. update NVGRE.
Although the definition of the various GTP shim headers is under the Although the definition of the various GTP shim headers is under the
control of the 3GPP, it is hard to determine whether the 3GPP or the control of the 3GPP, it is hard to determine whether the 3GPP or the
IETF controls standardization of the _process_ of adding both a GTP IETF controls standardization of the _process_ of adding both a GTP
and an IP header to an inner IP header. Nonetheless, the present and an IP header to an inner IP header. Nonetheless, the present
specification is provided so that the 3GPP can refer to it from any specification is provided so that the 3GPP can refer to it from any
of its own specifications of GTP and IP header processing. of its own specifications of GTP and IP header processing.
The specification of CAPWAP already specifies RFC 3168 ECN The specification of CAPWAP already specifies RFC 3168 ECN
propagation and ECN capability negotiation. Without modification the propagation and ECN capability negotiation. Without modification the
CAPWAP specification already interworks with the backward compatible CAPWAP specification already interworks with the backward compatible
updates to RFC 3168 in RFC 6040. updates to RFC 3168 in RFC 6040.
LISP made the ECN propagation procedures in RFC 3168 mandatory from LISP made the ECN propagation procedures in RFC 3168 mandatory from
the start. RFC 3168 has since been updated by RFC 6040, but the the start. RFC 3168 has since been updated by RFC 6040, but the
changes are backwards compatible so there is still no need for LISP changes are backwards compatible so there is still no need for LISP
tunnel endpoints to negotiate their ECN capabilities. tunnel endpoints to negotiate their ECN capabilities.
VXLAN is not under the change control of the IETF but it has been VXLAN is not under the change control of the IETF but it has been
documented in an informational RFC. It is RECOMMENDED that VXLAN documented in an informational RFC. In contrast, VXLAN-GPE (Generic
implementations comply with RFC 6040 when the VXLAN header is Protocol Extension) is being documented under IETF change control.
inserted between (or removed from between) IP headers. And the It is RECOMMENDED that VXLAN and VXLAN-GPE implementations comply
authors of any future update to these specifications are encouraged with RFC 6040 when the VXLAN header is inserted between (or removed
to add a requirement to comply with RFC 6040 as updated by the from between) IP headers. The authors of any future update to these
present specification. specifications are encouraged to add a requirement to comply with RFC
6040 as updated by the present specification.
VXLAN-GPE (Generic Protocol Extension) is on the IETF standards The specification of NSH does not currently include the process of
track. It is expected that it will specify ECN propagation before it encapsulation. It is assumed that ECN propagation will be included
is published as an RFC. {ToDo: Update this text once the VXLAN-GPE in whatever encapsulation an NSH implementation uses.
text has been updated.}
The specifications of Geneve and GUE already refer to RFC 6040 for The specifications of Geneve and GUE already refer to RFC 6040 for
ECN encapsulation. ECN encapsulation.
3.3.1. L2TP (v2 and v3) ECN Extension 5.1. Specific Updates to Protocols under IETF Change Control
5.1.1. L2TP (v2 and v3) ECN Extension
The L2TP terminology used here is defined in [RFC2661] and [RFC3931]. The L2TP terminology used here is defined in [RFC2661] and [RFC3931].
L2TPv3 [RFC3931] is used as a shim header between any packet-switched L2TPv3 [RFC3931] is used as a shim header between any packet-switched
network (PSN) header (e.g. IPv4, IPv6, MPLS) and many types of layer network (PSN) header (e.g. IPv4, IPv6, MPLS) and many types of layer
2 (L2) header. The L2TPv3 shim header encapsulates an L2-specific 2 (L2) header. The L2TPv3 shim header encapsulates an L2-specific
sub-layer then an L2 header that is likely to contain an inner IP sub-layer then an L2 header that is likely to contain an inner IP
header (v4 or v6). Then this whole stack of headers can be header (v4 or v6). Then this whole stack of headers can be
encapsulated optionally within an outer UDP header then an outer PSN encapsulated optionally within an outer UDP header then an outer PSN
header that is typically IP (v4 or v6). header that is typically IP (v4 or v6).
L2TPv2 is used as a shim header between any PSN header and a PPP L2TPv2 is used as a shim header between any PSN header and a PPP
header, which is in turn likely to encapsulate an IP header. header, which is in turn likely to encapsulate an IP header.
Even though these shims are rather fat (particularly in the case of Even though these shims are rather fat (particularly in the case of
L2TPv3), they still fit the definition of a tightly coupled shim L2TPv3), they still fit the definition of a tightly coupled shim
header over an encapsulating header (Section 3.1), because all the header over an encapsulating header (Section 3.1), because all the
headers encapsulating the L2 header are added (or removed) together. headers encapsulating the L2 header are added (or removed) together.
L2TPv2 and L2TPv3 are therefore within the scope of RFC 6040, as L2TPv2 and L2TPv3 are therefore within the scope of RFC 6040, as
updated by Section 3.1 above. updated by Section 3 above.
L2TP maintainers are RECOMMENDED to implement the ECN extension to L2TP maintainers are RECOMMENDED to implement the ECN extension to
L2TPv2 and L2TPv3 defined in Section 3.3.1.2 below, in order to L2TPv2 and L2TPv3 defined in Section 5.1.1.2 below, in order to
provide the benefits of ECN [RFC8087], whenever a node within an L2TP provide the benefits of ECN [RFC8087], whenever a node within an L2TP
tunnel becomes the bottleneck for an end-to-end traffic flow. tunnel becomes the bottleneck for an end-to-end traffic flow.
3.3.1.1. Safe Configuration of a 'Non-ECN' Ingress LCCE 5.1.1.1. Safe Configuration of a 'Non-ECN' Ingress LCCE
The following text is appended to both Section 5.3 of [RFC2661] and The following text is appended to both Section 5.3 of [RFC2661] and
Section 4.5 of [RFC3931] as an update to the base L2TPv2 and L2TPv3 Section 4.5 of [RFC3931] as an update to the base L2TPv2 and L2TPv3
specifications: specifications:
An LCCE that does not support the ECN Extension in Section 3.3.1.2 An LCCE that does not support the ECN Extension in Section 5.1.1.2
of RFCXXXX MUST follow the configuration requirements in of RFCXXXX MUST follow the configuration requirements in Section 4
Section 3.2 of RFCXXXX for when the outer PSN header is IP (v4 or of RFCXXXX for when the outer PSN header is IP (v4 or v6).
v6). {RFCXXXX refers to the present document so it will need to be {RFCXXXX refers to the present document so it will need to be
inserted by the RFC Editor} inserted by the RFC Editor}
In particular this means that an LCCE implementation that does not In particular, for an LCCE implementation that does not support the
support the ECN Extension MUST propagate the ECN field between inner ECN Extension, this means that configuration of how it propagates the
and outer IP headers independently of any configuration of the ECN field between inner and outer IP headers MUST be independent of
Diffserv extension of L2TP [RFC3308]. any configuration of the Diffserv extension of L2TP [RFC3308].
3.3.1.2. ECN Extension for L2TP (v2 or v3) 5.1.1.2. ECN Extension for L2TP (v2 or v3)
When the outer PSN header and the payload inside the L2 header are When the outer PSN header and the payload inside the L2 header are
both IP (v4 or v6), to comply with RFC 6040, an LCCE will follow the both IP (v4 or v6), to comply with RFC 6040, an LCCE will follow the
rules for propagation of the ECN field at ingress and egress in rules for propagation of the ECN field at ingress and egress in
Section 4 of RFC 6040 [RFC6040]. Section 4 of RFC 6040 [RFC6040].
Before encapsulating any data packets, RFC 6040 requires an ingress Before encapsulating any data packets, RFC 6040 requires an ingress
LCCE to check that the egress LCCE supports ECN propagation. If the LCCE to check that the egress LCCE supports ECN propagation. If the
egress supports ECN, the ingress LCCE can use the normal mode of egress supports ECN, the ingress LCCE can use the normal mode of
encapsulation. Otherwise, the ingress LCCE has to use compatibility encapsulation. Otherwise, the ingress LCCE has to use compatibility
mode [RFC6040]. An LCCE can determine the remote LCCE's support for mode [RFC6040]. An LCCE can determine the remote LCCE's support for
ECN either statically (by configuration) or by dynamic discovery ECN either statically (by configuration) or by dynamic discovery
during setup of each control connection between the LCCEs, using the during setup of each control connection between the LCCEs, using the
Capability AVP defined in Section 3.3.1.2.1 below. Capability AVP defined in Section 5.1.1.2.1 below.
Where the outer PSN header is some protocol other than IP that Where the outer PSN header is some protocol other than IP that
supports ECN, the appropriate ECN propagation specification will need supports ECN, the appropriate ECN propagation specification will need
to be followed, e.g. "Explicit Congestion Marking in MPLS" to be followed, e.g. "Explicit Congestion Marking in MPLS"
[RFC5129]. Where no specification exists for ECN propagation by a [RFC5129]. Where no specification exists for ECN propagation by a
particular PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives general particular PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives general
guidance on how to design ECN propagation into a protocol that guidance on how to design ECN propagation into a protocol that
encapsulates IP. encapsulates IP.
3.3.1.2.1. LCCE Capability AVP for ECN Capability Negotiation 5.1.1.2.1. LCCE Capability AVP for ECN Capability Negotiation
The LCCE Capability Attribute Value Pair (AVP) defined here has The LCCE Capability Attribute Value Pair (AVP) defined here has
Attribute Type ZZ. The Attribute Value field for this AVP is a bit- Attribute Type ZZ. The Attribute Value field for this AVP is a bit-
mask with the following 16-bit format: mask with the following 16-bit format:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X X X X X X X X X X X X X X X E| |X X X X X X X X X X X X X X X E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 29 skipping to change at page 11, line 12
Capability AVP but with the ECN Capability flag cleared to zero). Capability AVP but with the ECN Capability flag cleared to zero).
The tunnel initiator interprets the absence of the ECN Capability The tunnel initiator interprets the absence of the ECN Capability
flag in the SCCRP as an indication that the tunnel terminator is flag in the SCCRP as an indication that the tunnel terminator is
incapable of supporting ECN. When encapsulating data packets for any incapable of supporting ECN. When encapsulating data packets for any
sessions created by that control connection, the tunnel initiator sessions created by that control connection, the tunnel initiator
will then use the compatibility mode of RFC 6040 to clear the ECN will then use the compatibility mode of RFC 6040 to clear the ECN
field of the outer IP header to 0b00. field of the outer IP header to 0b00.
If the tunnel terminator does not support this ECN extension, the If the tunnel terminator does not support this ECN extension, the
network operator is still expected to configure it to comply with the network operator is still expected to configure it to comply with the
safety provisions set out in Section 3.3.1.1 above, when it acts as safety provisions set out in Section 5.1.1.1 above, when it acts as
an ingress LCCE. an ingress LCCE.
3.3.2. GRE 5.1.2. GRE
The GRE terminology used here is defined in [RFC2784]. GRE is often The GRE terminology used here is defined in [RFC2784]. GRE is often
used as a tightly coupled shim header between IP headers. Sometimes used as a tightly coupled shim header between IP headers. Sometimes
the GRE shim header encapsulates an L2 header, which might in turn the GRE shim header encapsulates an L2 header, which might in turn
encapsulate an IP header. Therefore GRE is within the scope of RFC encapsulate an IP header. Therefore GRE is within the scope of RFC
6040 as updated by Section 3.1 above. 6040 as updated by Section 3 above.
GRE tunnel endpoint maintainers are RECOMMENDED to support [RFC6040] GRE tunnel endpoint maintainers are RECOMMENDED to support [RFC6040]
as updated by the present specification, in order to provide the as updated by the present specification, in order to provide the
benefits of ECN [RFC8087] whenever a node within a GRE tunnel becomes benefits of ECN [RFC8087] whenever a node within a GRE tunnel becomes
the bottleneck for an end-to-end IP traffic flow tunnelled over GRE the bottleneck for an end-to-end IP traffic flow tunnelled over GRE
using IP as the delivery protocol (outer header). using IP as the delivery protocol (outer header).
GRE tunnels do not support dynamic configuration based on capability GRE tunnels do not support dynamic configuration based on capability
negotiation, so the ECN capability has to be manually configured, negotiation, so the ECN capability has to be manually configured.
which is specified in Section 4.3 of RFC 6040. For a GRE ingress implementation that supports ECN propagation,
manual configuration requirements are specified in Section 4.3 of RFC
6040. Otherwise they are specified in Section 5.1.2.1 below.
Where the delivery protocol is some protocol other than IP that Where the delivery protocol is some protocol other than IP that
supports ECN, the appropriate ECN propagation specification will need supports ECN, the appropriate ECN propagation specification will need
to be followed, e.g Explicit Congestion Marking in MPLS [RFC5129]. to be followed, e.g Explicit Congestion Marking in MPLS [RFC5129].
Where no specification exists for ECN propagation by a particular Where no specification exists for ECN propagation by a particular
PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more general PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more general
guidance on how to propagate ECN to and from protocols that guidance on how to propagate ECN to and from protocols that
encapsulate IP. encapsulate IP.
3.3.2.1. Safe Configuration of a 'Non-ECN' GRE Ingress 5.1.2.1. Safe Configuration of a 'Non-ECN' GRE Ingress
The following text is appended to Section 3 of [RFC2784] as an update The following text is appended to Section 3 of [RFC2784] as an update
to the base GRE specification: to the base GRE specification:
A GRE tunnel ingress that does not support RFC 6040 or one of its A GRE tunnel ingress that does not support RFC 6040 or one of its
compatible predecessors (RFC 4301 or the full functionality mode compatible predecessors (RFC 4301 or the full functionality mode
of RFC 3168) MUST follow the configuration requirements in of RFC 3168) MUST follow the configuration requirements in
Section 3.2 of RFCXXXX for when the outer delivery protocol is IP Section 4 of RFCXXXX for when the outer delivery protocol is IP
(v4 or v6). {RFCXXXX refers to the present document so it will (v4 or v6). {RFCXXXX refers to the present document so it will
need to be inserted by the RFC Editor} need to be inserted by the RFC Editor}
3.3.3. Teredo 5.1.3. Teredo
{ToDo} Teredo [RFC4380] provides a way to tunnel IPv6 over an IPv4 network,
with a UDP-based shim header between the two.
4. IANA Considerations For Teredo tunnel endpoints to provide the benefits of ECN, the
Teredo specification would have to be updated to include negotiation
of the ECN capability between Teredo tunnel endpoints. Otherwise it
would be unsafe for a Teredo tunnel ingress to copy the ECN field to
the IPv6 outer.
It is believed that current implementations do not support
propagation of ECN, but that they do safely zero the ECN field in the
outer IPv6 header. However the specification does not mention
anything about this. To make existing Teredo deployments safe it
will not be feasible to require them to be configured correctly,
because Teredo tunnel endpoints are generally deployed on hosts.
Therefore, the only feasible safety precaution available here is to
update the specification of Teredo implementations until ECN support
is added. The following text updates the Teredo specification
[RFC4380], as a new section 5.1.3:
"5.1.3 Safe 'Non-ECN' Teredo Encapsulation
A Teredo tunnel ingress implementation that does not support ECN
propagation as defined in RFC 6040 or one of its compatible
predecessors (RFC 4301 or the full functionality mode of RFC 3168)
MUST zero the ECN field in the outer IPv6 header."
6. IANA Considerations
IANA is requested to assign the following L2TP Control Message IANA is requested to assign the following L2TP Control Message
Attribute Value Pair: Attribute Value Pair:
+----------------+----------------+-----------+ +----------------+----------------+-----------+
| Attribute Type | Description | Reference | | Attribute Type | Description | Reference |
+----------------+----------------+-----------+ +----------------+----------------+-----------+
| ZZ | ECN Capability | RFCXXXX | | ZZ | ECN Capability | RFCXXXX |
+----------------+----------------+-----------+ +----------------+----------------+-----------+
[TO BE REMOVED: This registration should take place at the following [TO BE REMOVED: This registration should take place at the following
location: https://www.iana.org/assignments/l2tp-parameters/l2tp- location: https://www.iana.org/assignments/l2tp-parameters/l2tp-
parameters.xhtml ] parameters.xhtml ]
5. Security Considerations 7. Security Considerations
The Security Considerations in [RFC6040] and The Security Considerations in [RFC6040] and
[I-D.ietf-tsvwg-ecn-encap-guidelines] apply equally to the scope [I-D.ietf-tsvwg-ecn-encap-guidelines] apply equally to the scope
defined for the present specification. defined for the present specification.
6. Comments Solicited 8. Comments Solicited
Comments and questions are encouraged and very welcome. They can be Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list addressed to the IETF Transport Area working group mailing list
<tsvwg@ietf.org>, and/or to the authors. <tsvwg@ietf.org>, and/or to the authors.
7. Acknowledgements 9. Acknowledgements
Thanks to Ing-jyh (Inton) Tsang for initial discussions on the need Thanks to Ing-jyh (Inton) Tsang for initial discussions on the need
for ECN propagation in L2TP and its applicability. Thanks also to for ECN propagation in L2TP and its applicability. Thanks also to
Carlos Pignataro, Tom Herbert and Ignacio Goyret for helpful advice Carlos Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen
and comments. Balasubramanian and Joe Touch for helpful advice and comments.
8. References 10. References
8.1. Normative References 10.1. Normative References
[I-D.ietf-tsvwg-ecn-encap-guidelines] [I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B., Kaippallimalil, J., and P. Thaler, Briscoe, B., Kaippallimalil, J., and P. Thaler,
"Guidelines for Adding Congestion Notification to "Guidelines for Adding Congestion Notification to
Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
encap-guidelines-08 (work in progress), March 2017. encap-guidelines-08 (work in progress), March 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 13, line 22 skipping to change at page 14, line 37
<http://www.rfc-editor.org/info/rfc4380>. <http://www.rfc-editor.org/info/rfc4380>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <http://www.rfc-editor.org/info/rfc5129>. 2008, <http://www.rfc-editor.org/info/rfc5129>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <http://www.rfc-editor.org/info/rfc6040>. 2010, <http://www.rfc-editor.org/info/rfc6040>.
8.2. Informative References 10.2. Informative References
[GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp [GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp
interface", Technical Specification TS 29.060. interface", Technical Specification TS 29.060.
[GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", Technical Specification TS Protocol User Plane (GTPv1-U)", Technical Specification TS
29.281. 29.281.
[GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) [GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS)
Tunnelling Protocol for Control plane (GTPv2-C)", Tunnelling Protocol for Control plane (GTPv2-C)",
skipping to change at page 14, line 5 skipping to change at page 15, line 20
[I-D.ietf-nvo3-geneve] [I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf- Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-04 (work in progress), March 2017. nvo3-geneve-04 (work in progress), March 2017.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work
in progress), April 2017. in progress), April 2017.
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-12 (work in progress), February 2017.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, Routing Encapsulation (GRE)", RFC 1701,
DOI 10.17487/RFC1701, October 1994, DOI 10.17487/RFC1701, October 1994,
<http://www.rfc-editor.org/info/rfc1701>. <http://www.rfc-editor.org/info/rfc1701>.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol W., and G. Zorn, "Point-to-Point Tunneling Protocol
(PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999,
<http://www.rfc-editor.org/info/rfc2637>. <http://www.rfc-editor.org/info/rfc2637>.
 End of changes. 47 change blocks. 
125 lines changed or deleted 199 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/