Propagating Explicit
Congestion Notification Across IP Tunnel Headers Separated by a
ShimIndependentUKietf@bobbriscoe.nethttp://bobbriscoe.net/
Transport
Transport Area Working GroupCongestion Control and ManagementCongestion NotificationInformation SecurityTunnellingEncapsulation & DecapsulationProtocolECNLayeringRFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
rules for propagation of ECN consistent for all forms of IP in IP
tunnel. This specification updates RFC 6040 to clarify that its scope
includes tunnels where two IP headers are separated by at least one shim
header that is not sufficient on its own for wide area packet
forwarding. It surveys widely deployed IP tunnelling protocols that use
such shim header(s) and updates the specifications of those that do not
mention ECN propagation (L2TPv2, L2TPv3, GRE, Teredo and AMT). This
specification also updates RFC 6040 with configuration requirements
needed to make any legacy tunnel ingress safe.RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of Explicit Congestion
Notification (ECN ) consistent for all forms of
IP in IP tunnel.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 header
(v4 or v6). Some of these shim headers are designed as generic
encapsulations, so they do not necessarily directly encapsulate an inner
IP header. Instead they can encapsulate headers such as link-layer (L2)
protocols that in turn often encapsulate IP.To clear up confusion, this specification clarifies that the scope of
RFC 6040 includes any IP-in-IP tunnel, including those with shim
header(s) and other encapsulations between the IP headers. Where
necessary, it updates the specifications of the relevant encapsulation
protocols with the specific text necessary to comply with RFC 6040.This specification also updates RFC 6040 to state how operators ought
to configure a legacy tunnel ingress to avoid unsafe system
configurations.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 when, and only when, they appear in all capitals, as
shown here.This specification uses the terminology defined in RFC 6040 .In section 1.1 of RFC 6040, its scope is defined as: "...ECN field processing at encapsulation and decapsulation for
any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It
applies irrespective of whether IPv4 or IPv6 is used for either the
inner or outer headers. ..."This was intended to include cases where shim header(s) sit between
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 IP header either directly or indirectly by encapsulating other
headers that in turn encapsulate (or might encapsulate) an inner 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:those cases where it is infeasible for an implementation to
access an inner IP header when adding or removing an outer IP
header;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 clear the ECN field in any outer
IP header to 0b00.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 , the factors that determine
whether propagating ECN is feasible or desirable will be briefly
introduced.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
encapsulation is strictly a layering violation so it cannot be a
required behaviour. Nonetheless, some tunnel endpoints already look
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
. In such cases at least, it should be
feasible to also (independently) propagate the ECN field between the
same IP headers. Thus, access to the ECN field within an encapsulating
header can be a useful and benign optimization. The guidelines in
section 5 of give
the conditions for this layering violation to be benign.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 . Nonetheless, propagation of ECN
between IP headers, whether separated by shim headers or not, has to
be optional to implement and to use, because:Legacy implementations of tunnels without any ECN support
already existA network might be designed so that there is usually no
bottleneck within the tunnelIf 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 hitEven when no specific attempt has been made to implement propagation
of the ECN field at a tunnel ingress, it ought to be possible for the
operator to render a tunnel ingress safe by configuration. The main
safety concern is to disable (clear to zero) the ECN capability in the
outer IP header at the ingress if the egress of the tunnel does not
implement ECN logic to propagate any ECN markings into the packet
forwarded beyond the tunnel. Otherwise the non-ECN egress could discard
any ECN marking introduced within the tunnel, which would break all the
ECN-based control loops that regulate the traffic load over the
tunnel.Therefore this specification updates RFC 6040 by inserting the
following text at the end of section 4.3:"Whether or not an ingress implementation
claims compliance with RFC 6040, RFC 4301 or RFC3168, when the outer
tunnel header is IP (v4 or v6), if possible, the operator MUST
configure the ingress to zero the outer ECN field in any of the
following cases:if it is known that the tunnel egress does not support any of
the RFCs that define propagation of the ECN field (RFC 6040, RFC
4301 or the full functionality mode of RFC 3168)or if the behaviour of the egress is not known or an egress
with unknown behaviour might be dynamically paired with the
ingress.or if an IP header might be encapsulated within a non-IP
header that the tunnel ingress is encapsulating, but the ingress
does not inspect within the encapsulation.For the avoidance of doubt, the above only concerns the
outer IP header. The ingress MUST NOT alter the ECN field of the
arriving IP header that will become the inner IP header.In order that the network operator can comply with the above
safety rules, even if an implementation of a tunnel ingress does not
claim to support RFC 6040, RFC 4301 or the full functionality mode
of RFC 3168:it MUST NOT treat the former ToS octet (IPv4) or the former
Traffic Class octet (IPv6) as a single 8-bit field, as the
resulting linkage of ECN and Diffserv field propagation between
inner and outer is not consistent with the definition of the
6-bit Diffserv field in and ;it SHOULD be able to be configured to zero the ECN field of
the outer header."For instance, if a tunnel ingress with no ECN-specific logic had a
configuration capability to refer to the last 2 bits of the old ToS Byte
of the outer (e.g. with a 0x3 mask) and set them to zero, while also
being able to allow the DSCP to be re-mapped independently, that would
be sufficient to satisfy both the above implementation requirements.There might be concern that the above "MUST NOT" makes compliant
implementations non-compliant at a stroke. However, by definition it
solely applies to equipment that provides Diffserv configuration. Any
such Diffserv equipment that is configuring treatment of the former ToS
octet (IPv4) or the former Traffic Class octet (IPv6) as a single 8-bit
field must have always been non-compliant with the definition of the
6-bit Diffserv field in and . If a tunnel ingress does not have any ECN logic,
copying the ECN field as a side-effect of copying the DSCP is a
seriously unsafe bug that risks breaking the feedback loops that
regulate load on a tunnel.Zeroing the outer ECN field of all packets in all circumstances would
be safe, but it would not be sufficient to claim compliance with RFC
6040 because it would not meet the aim of introducing ECN support to
tunnels (see Section 4.3 of ).The following requirements update RFC6040, which omitted handling of
the ECN field during fragmentation or reassembly. These changes might
alter how many ECN-marked packets are propagated by a tunnel that
fragments packets, but this would not raise any backward compatibility
issues:If a tunnel ingress fragments a packet, it MUST set the outer ECN
field of all the fragments to the same value as it would have set if it
had not fragmented the packet.During reassembly of outer fragments , if the ECN fields of the outer
headers being reassembled into a single packet consist of a mixture of
Not-ECT and other ECN codepoints, the packet MUST be discarded.Section 5.3 of defines the process that a
tunnel egress follows to reassemble sets of outer fragments into packets.There follows a list of specifications of encapsulations with tightly
coupled shim header(s), in rough chronological order. The list is
confined to standards track or widely deployed protocols. The list is
not necessarily exhaustive so, for the avoidance of doubt, the scope of
RFC 6040 is defined in and is not
limited to this list. PPTP (Point-to-Point Tunneling Protocol) ;L2TP (Layer 2 Tunnelling Protocol), specifically L2TPv2 and L2TPv3 , which not
only includes all the L2-specific specializations of L2TP, but also
derivatives such as the Keyed IPv6 Tunnel ;GRE (Generic Routing Encapsulation) and
NVGRE (Network Virtualization using GRE) ;GTP (GPRS Tunnelling Protocol), specifically GTPv1 , GTP v1 User Plane , GTP v2
Control Plane ;Teredo ;CAPWAP (Control And Provisioning of Wireless Access Points) ;LISP (Locator/Identifier Separation Protocol) ;AMT (Automatic Multicast Tunneling) ;VXLAN (Virtual eXtensible Local Area Network) and VXLAN-GPE ;The Network Service Header (NSH ) for
Service Function Chaining (SFC);Geneve ;GUE (Generic UDP Encapsulation) ;Direct tunnelling of an IP packet within a UDP/IP datagram (see
Section 3.1.11 of );TCP Encapsulation of IKE and IPsec Packets (see Section 12.5 of
).Some of the listed protocols enable encapsulation of a variety of
network layer protocols as inner and/or outer. This specification
applies in the cases where there is an inner and outer IP header as
described in . Otherwise gives guidance on how to
design propagation of ECN into other protocols that might encapsulate
IP.Where protocols in the above list need to be updated to specify ECN
propagation and they are under IETF change control, update text is given
in the following subsections. For those not under IETF control, it is
RECOMMENDED that implementations of encapsulation and decapsulation
comply with RFC 6040. It is also RECOMMENDED that their specifications
are updated to add a requirement to comply with RFC 6040 (as updated by
the present document).PPTP is not under the change control of the IETF, but it has been
documented in an informational RFC . However,
there is no need for the present specification to update PPTP because
L2TP has been developed as a standardized replacement.NVGRE is not under the change control of the IETF, but it has been
documented in an informational RFC . NVGRE is a
specific use-case of GRE (it re-purposes the key field from the initial
specification of GRE as a Virtual Subnet ID).
Therefore the text that updates GRE in
below is also intended to update NVGRE.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
IETF controls standardization of the process
of adding both a GTP 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 of its own specifications of GTP and IP header
processing.The specification of CAPWAP already specifies RFC 3168 ECN
propagation and ECN capability negotiation. Without modification the
CAPWAP specification already interworks with the backward compatible
updates to RFC 3168 in RFC 6040.LISP made the ECN propagation procedures in RFC 3168 mandatory from
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 tunnel
endpoints to negotiate their ECN capabilities.VXLAN is not under the change control of the IETF but it has been
documented in an informational RFC. In contrast, VXLAN-GPE (Generic
Protocol Extension) is being documented under IETF change control. It is
RECOMMENDED that VXLAN and VXLAN-GPE implementations comply with RFC
6040 when the VXLAN header is inserted between (or removed from between)
IP headers. The authors of any future update to these specifications are
encouraged to add a requirement to comply with RFC 6040 as updated by
the present specification.The Network Service Header (NSH ) has been
defined as a shim-based encapsulation to identify the Service Function
Path (SFP) in the Service Function Chaining (SFC) architecture . A proposal has been made for the processing of ECN
when handling transport encapsulation .The specifications of Geneve and GUE already refer to RFC 6040 for
ECN encapsulation.Section 3.1.11 of RFC 8085 already explains that a tunnel that
encapsulates an IP header within a UDP/IP datagram needs to follow RFC
6040 when propagating the ECN field between inner and outer IP headers.
The requirements in update RFC 6040,
and hence implicitly update the UDP usage guidelines in RFC 8085 to add
the important but previously unstated requirement that, if the UDP
tunnel egress does not, or might not, support ECN propagation, a UDP
tunnel ingress has to clear the outer IP ECN field to 0b00, e.g. by
configuration.Section 12.5 of TCP Encapsulation of IKE and IPsec Packets already recommends the compatibility mode of RFC 6040
in this case, because there is not a one-to-one mapping between inner
and outer packets.The L2TP terminology used here is defined in and .L2TPv3 is used as a shim header between
any packet-switched network (PSN) header (e.g. IPv4, IPv6, MPLS) and
many types of layer 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 header (v4 or v6). Then this whole
stack of headers can be encapsulated optionally within an outer UDP
header then an outer PSN header that is typically IP (v4 or v6).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.Even though these shims are rather fat (particularly in the case
of L2TPv3), they still fit the definition of a tightly coupled shim
header over an encapsulating header (), because all the headers
encapsulating the L2 header are added (or removed) together. L2TPv2
and L2TPv3 are therefore within the scope of RFC 6040, as updated by
above.L2TP maintainers are RECOMMENDED to implement the ECN extension
to L2TPv2 and L2TPv3 defined in
below, in order to provide the benefits of ECN , whenever a node within an L2TP tunnel becomes
the bottleneck for an end-to-end traffic flow.The following text is appended to both Section 5.3 of and Section 4.5 of as
an update to the base L2TPv2 and L2TPv3 specifications:The operator of an LCCE that does not support the ECN
Extension in of RFCXXXX
MUST follow the configuration requirements in of RFCXXXX to ensure it clears
the outer IP ECN field to 0b00 when the outer PSN header is IP
(v4 or v6). {RFCXXXX refers to the present document so it will
need to be inserted by the RFC Editor}In particular, for an LCCE implementation that does not support
the ECN Extension, this means that configuration of how it
propagates the ECN field between inner and outer IP headers MUST
be independent of any configuration of the Diffserv extension of
L2TP .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 rules for propagation of the ECN field at ingress and
egress in Section 4 of RFC 6040 .Before encapsulating any data packets, RFC 6040 requires an
ingress LCCE to check that the egress LCCE supports ECN
propagation as defined in RFC 6040 or one of its compatible
predecessors ( or the full functionality
mode of ). If the egress supports ECN
propagation, the ingress LCCE can use the normal mode of
encapsulation (copying the ECN field from inner to outer).
Otherwise, the ingress LCCE has to use compatibility mode (clearing the outer IP ECN field to 0b00).An LCCE can determine the remote LCCE's support for ECN either
statically (by configuration) or by dynamic discovery during setup
of each control connection between the LCCEs, using the Capability
AVP defined in
below.Where the outer PSN header is some protocol other than IP that
supports ECN, the appropriate ECN propagation specification will
need to be followed, e.g. "Explicit Congestion Marking in MPLS"
. Where no specification exists for ECN
propagation by a particular PSN, gives general
guidance on how to design ECN propagation into a protocol that
encapsulates IP.The LCCE Capability Attribute-Value Pair (AVP) defined here
has Attribute Type ZZ. The Attribute Value field for this AVP is
a bit-mask with the following 16-bit format:This AVP MAY be present in the following message types: SCCRQ
and SCCRP (Start-Control-Connection-Request and
Start-Control-Connection-Reply). This AVP MAY be hidden (the
H-bit set to 0 or 1) and is optional (M-bit not set). The length
(before hiding) of this AVP MUST be 8 octets. The Vendor ID is
the IETF Vendor ID of 0.Bit 15 of the Value field of the LCCE Capability AVP is
defined as the ECN Capability flag (E). When the ECN Capability
flag is set to 1, it indicates that the sender supports ECN
propagation. When the ECN Capability flag is cleared to zero, or
when no LCCE Capabiliy AVP is present, it indicates that the
sender does not support ECN propagation. All the other bits are
reserved. They MUST be cleared to zero when sent and ignored
when received or forwarded.An LCCE initiating a control connection will send a
Start-Control-Connection-Request (SCCRQ) containing an LCCE
Capability AVP with the ECN Capability flag set to 1. If the
tunnel terminator supports ECN, it will return a
Start-Control-Connection-Reply (SCCRP) that also includes an
LCCE Capability AVP with the ECN Capability flag set to 1. Then,
for any sessions created by that control connection, both ends
of the tunnel can use the normal mode of RFC 6040, i.e. it can
copy the IP ECN field from inner to outer when encapsulating
data packets.If, on the other hand, the tunnel terminator does not support
ECN it will ignore the ECN flag in the LCCE Capability AVP and
send an SCCRP to the tunnel initiator without a Capability AVP
(or with a Capability AVP but with the ECN Capability flag
cleared to zero). The tunnel initiator interprets the absence of
the ECN Capability flag in the SCCRP as an indication that the
tunnel terminator is incapable of supporting ECN. When
encapsulating data packets for any sessions created by that
control connection, the tunnel initiator will then use the
compatibility mode of RFC 6040 to clear the ECN field of the
outer IP header to 0b00.If the tunnel terminator does not support this ECN extension,
the network operator is still expected to configure it to comply
with the safety provisions set out in above, when it acts as an ingress
LCCE.The GRE terminology used here is defined in . GRE is often used as a tightly coupled shim
header between IP headers. Sometimes the GRE shim header
encapsulates an L2 header, which might in turn encapsulate an IP
header. Therefore GRE is within the scope of RFC 6040 as updated by
above.GRE tunnel endpoint maintainers are RECOMMENDED to support as updated by the present specification, in order
to provide the benefits of ECN whenever a
node within a GRE tunnel becomes the bottleneck for an end-to-end IP
traffic flow tunnelled over GRE using IP as the delivery protocol
(outer header).GRE itself does not support dynamic set-up and configuration of
tunnels. However, control plane protocols such as Mobile IPv4 (MIP4)
, Mobile IPv6 (MIP6) , Proxy Mobile IP (PMIP)
and IKEv2 are sometimes used to set up GRE
tunnels dynamically.When these control protocols set up IP-in-IP or IPSec tunnels, it
is likely that they propagate the ECN field as defined in RFC 6040
or one of its compatible predecessors (RFC 4301 or the full
functionality mode of RFC 3168). However, if they use a GRE
encapsulation, this presumption is less sound.Therefore, If the outer delivery protocol is IP (v4 or v6) the
operator is obliged to follow the safe configuration requirements in
above. below updates the base GRE
specification with this requirement, to emphasize its
importance.Where the delivery protocol is some protocol other than IP that
supports ECN, the appropriate ECN propagation specification will
need to be followed, e.g Explicit Congestion Marking in MPLS . Where no specification exists for ECN
propagation by a particular PSN, gives more general
guidance on how to propagate ECN to and from protocols that
encapsulate IP.The following text is appended to Section 3 of as an update to the base GRE
specification:The operator of a GRE tunnel ingress MUST follow the
configuration requirements in of RFCXXXX when the outer
delivery protocol is IP (v4 or v6). {RFCXXXX refers to the
present document so it will need to be inserted by the RFC
Editor}Teredo provides a way to tunnel IPv6
over an IPv4 network, with a UDP-based shim header between the
two.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 would be possible to
add ECN capability negotiation to those that are subject to remote
OS update. However, for those implementations not subject to remote
OS update, it will not be feasible to require them to be configured
correctly, because Teredo tunnel endpoints are generally deployed on
hosts.Therefore, until ECN support is added to the specification of
Teredo, the only feasible further safety precaution available here
is to update the specification of Teredo implementations with the
following text, as a new section 5.1.3:"5.1.3 Safe 'Non-ECN' Teredo EncapsulationA 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."Automatic Multicast Tunneling (AMT ) is a
tightly coupled shim header that encapsulates an IP packet and is
itself encapsulated within a UDP/IP datagram. Therefore AMT is
within the scope of RFC 6040 as updated by above.AMT tunnel endpoint maintainers are RECOMMENDED to support as updated by the present specification, in order
to provide the benefits of ECN whenever a
node within an AMT tunnel becomes the bottleneck for an IP traffic
flow tunnelled over AMT.To comply with RFC 6040, an AMT relay and gateway will follow the
rules for propagation of the ECN field at ingress and egress
respectively, as described in Section 4 of RFC 6040 .Before encapsulating any data packets, RFC 6040 requires an
ingress AMT relay to check that the egress AMT gateway supports ECN
propagation as defined in RFC 6040 or one of its compatible
predecessors (RFC 4301 or the full functionality mode of RFC 3168).
If the egress gateway supports ECN, the ingress relay can use the
normal mode of encapsulation (copying the IP ECN field from inner to
outer). Otherwise, the ingress relay has to use compatibility mode,
which means it has to clear the outer ECN field to zero .An AMT tunnel is created dynamically (not manually), so the relay
will need to determine the remote gateway's support for ECN using
the ECN capability declaration defined in below.The following text is appended to Section 4.2.2 of as an update to the AMT specification:The operator of an AMT relay that does not support RFC 6040
or one of its compatible predecessors (RFC 4301 or the full
functionality mode of RFC 3168) MUST follow the configuration
requirements in of RFCXXXX
to ensure it clears the outer IP ECN field to zero. {RFCXXXX
refers to the present document so it will need to be inserted
by the RFC Editor}Bit 14 of the AMT Request Message counting from 0 (or bit 7 of
the Reserved field counting from 1) is defined here as the AMT
Gateway ECN Capability flag (E), as shown in . The
definitions of all other fields in the AMT Request Message are
unchanged from RFC 7450.When the E flag is set to 1, it indicates that the sender of
the message supports RFC 6040 ECN propagation. When it is cleared
to zero, it indicates the sender of the message does not support
RFC 6040 ECN propagation. An AMT gateway "that supports RFC 6040
ECN propagation" means one that propagates the ECN field to the
forwarded data packet based on the combination of arriving inner
and outer ECN fields, as defined in Section 4 of RFC 6040.The other bits of the Reserved field remain reserved. They will
continue to be cleared to zero when sent and ignored when either
received or forwarded, as specified in Section 5.1.3.3. of RFC
7450.An AMT gateway that does not support RFC 6040 MUST NOT set the
E flag of its Request Message to 1.An AMT gateway that supports RFC 6040 ECN propagation MUST set
the E flag of its Relay Discovery Message to 1.The action of the corresponding AMT relay that receives a
Request message with the E flag set to 1 depends on whether the
relay itself supports RFC 6040 ECN propagation:If the relay supports RFC 6040 ECN propagation, it will
store the ECN capability of the gateway along with its
address. Then whenever it tunnels datagrams towards this
gateway, it MUST use the normal mode of RFC 6040 to propagate
the ECN field when encapsulating datagrams (i.e. it copies the
IP ECN field from inner to outer).If the discovered AMT relay does not support RFC 6040 ECN
propagation, it will ignore the E flag in the Reserved field,
as per section 5.1.3.3. of RFC 7450. If the AMT relay does not support RFC 6040 ECN
propagation, the network operator is still expected to
configure it to comply with the safety provisions set out in
above.IANA is requested to assign the following L2TP Control Message
Attribute Value Pair:Attribute TypeDescriptionReferenceZZECN CapabilityRFCXXXX[TO BE REMOVED: This registration should take place at the following
location:
https://www.iana.org/assignments/l2tp-parameters/l2tp-parameters.xhtml
]The Security Considerations in and apply equally to the
scope defined for the present specification.Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list
<tsvwg@ietf.org>, and/or to the authors.Thanks to Ing-jyh (Inton) Tsang for initial discussions on the need
for ECN propagation in L2TP and its applicability. Thanks also to Carlos
Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen
Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake Holland
and Sri Gundavelli for helpful advice and comments. "A Comparison of
IPv6-over-IPv4 Tunnel Mechanisms" helped to
identify a number of tunnelling protocols to include within the scope of
this document.Bob Briscoe was part-funded by the Research Council of Norway through
the TimeIn project. The views expressed here are solely those of the
authors.GPRS Tunnelling Protocol (GTP) across the Gn and Gp
interface3GPPGeneral Packet Radio System (GPRS) Tunnelling Protocol User
Plane (GTPv1-U)3GPPEvolved General Packet Radio Service (GPRS) Tunnelling
Protocol for Control plane (GTPv2-C)3GPP