< draft-ietf-tsvwg-rfc6040update-shim-08.txt   draft-ietf-tsvwg-rfc6040update-shim-09.txt >
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft Independent Internet-Draft Independent
Updates: 6040, 2661, 2784, 3931, 4380, March 29, 2019 Updates: 6040, 2661, 2784, 3931, 4380, July 8, 2019
7450 (if approved) 7450 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 30, 2019 Expires: January 9, 2020
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-08 draft-ietf-tsvwg-rfc6040update-shim-09
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 updates RFC 6040 to clarify that its tunnel. This specification updates RFC 6040 to clarify that its
scope includes tunnels where two IP headers are separated by at least 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 one shim header that is not sufficient on its own for wide area
packet forwarding. It surveys widely deployed IP tunnelling packet forwarding. It surveys widely deployed IP tunnelling
protocols separated by such shim header(s) and updates the protocols that use such shim header(s) and updates the specifications
specifications of those that do not mention ECN propagation (L2TPv2, of those that do not mention ECN propagation (L2TPv2, L2TPv3, GRE,
L2TPv3, GRE, Teredo and AMT). This specification also updates RFC Teredo and AMT). This specification also updates RFC 6040 with
6040 with configuration requirements needed to make any legacy tunnel configuration requirements needed to make any legacy tunnel ingress
ingress safe. 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 30, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Feasibility of ECN Propagation between Tunnel Headers . . 4 3.1. Feasibility of ECN Propagation between Tunnel Headers . . 4
3.2. Desirability of ECN Propagation between Tunnel Headers . 5 3.2. Desirability of ECN Propagation between Tunnel Headers . 5
4. Making a non-ECN Tunnel Ingress Safe by Configuration . . . . 5 4. Making a non-ECN Tunnel Ingress Safe by Configuration . . . . 5
5. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 7 5. ECN Propagation and Fragmentation/Reassembly . . . . . . . . 7
5.1. Specific Updates to Protocols under IETF Change Control . 9 6. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 8
5.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 9 6.1. Specific Updates to Protocols under IETF Change Control . 11
5.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 11
5.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 13 6.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.4. AMT . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.1.4. AMT . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
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 6, line 5 skipping to change at page 6, line 5
Therefore this specification updates RFC 6040 by inserting the Therefore this specification updates RFC 6040 by inserting the
following text at the end of section 4.3: following text at the end of section 4.3:
" "
Whether or not an ingress implementation claims compliance with Whether or not an ingress implementation claims compliance with
RFC 6040, RFC 4301 or RFC3168, when the outer tunnel header is IP RFC 6040, RFC 4301 or RFC3168, when the outer tunnel header is IP
(v4 or v6), if possible, the operator MUST configure the ingress (v4 or v6), if possible, the operator MUST configure the ingress
to zero the outer ECN field in any of the following cases: to zero the outer ECN field in any of the following cases:
* if it is known that the tunnel egress does not support * if it is known that the tunnel egress does not support any of
propagation of the ECN field (RFC 6040, RFC 4301 or the full the RFCs that define propagation of the ECN field (RFC 6040,
functionality mode of RFC 3168) RFC 4301 or the full functionality mode of RFC 3168)
* or if the behaviour of the egress is not known or an egress * or if the behaviour of the egress is not known or an egress
with unknown behaviour might be dynamically paired with the with unknown behaviour might be dynamically paired with the
ingress. ingress.
* or if an IP header might be encapsulated within a non-IP header * or if an IP header might be encapsulated within a non-IP header
that the tunnel ingress is encapsulating, but the ingress does that the tunnel ingress is encapsulating, but the ingress does
not inspect within the encapsulation. not inspect within the encapsulation.
For the avoidance of doubt, the above only concerns the outer IP For the avoidance of doubt, the above only concerns the outer IP
header. The ingress MUST NOT alter the ECN field of the arriving header. The ingress MUST NOT alter the ECN field of the arriving
IP header that will become the inner IP header. IP header that will become the inner IP header.
In order that the network operator can comply with the above In order that the network operator can comply with the above
safety rules, even if an implementation of a tunnel ingress does safety rules, even if an implementation of a tunnel ingress does
not claim to support RFC 6040, RFC 4301 or the full functionality not claim to support RFC 6040, RFC 4301 or the full functionality
mode of RFC 3168: mode of RFC 3168:
* it MUST make propagation of the ECN field between inner and * it MUST NOT treat the former ToS octet (IPv4) or the former
outer IP headers independent of any configuration of Diffserv Traffic Class octet (IPv6) as a single 8-bit field, as the
codepoint propagation; 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 [RFC2474] and [RFC3260];
* it SHOULD be able to be configured to zero the outer ECN field. * it SHOULD be able to be configured to zero the ECN field of the
outer header.
" "
There might be concern that the above "MUST" makes compliant For instance, if a tunnel ingress with no ECN-specific logic had a
equipment non-compliant at a stroke. However, any equipment that is configuration capability to refer to the last 2 bits of the old ToS
still treating the former ToS octet (IPv4) or the former Traffic Byte of the outer (e.g. with a 0x3 mask) and set them to zero, while
Class octet (IPv6) as a single 8-bit field is already non-compliant, also being able to allow the DSCP to be re-mapped independently, that
and has been since 1998 when the upper 6 bits were separated off for would be sufficient to satisfy both the above implementation
the Diffserv field [RFC2474], [RFC3260]. For instance, copying the requirements.
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 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 [RFC2474] and [RFC3260].
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. tunnel.
Permanently zeroing the outer ECN field is safe, but it is not Zeroing the outer ECN field of all packets in all circumstances would
sufficient to claim compliance with RFC 6040 because it does not meet be safe, but it would not be sufficient to claim compliance with RFC
the aim of introducing ECN support to tunnels (see Section 4.3 of 6040 because it would not meet the aim of introducing ECN support to
[RFC6040]). tunnels (see Section 4.3 of [RFC6040]).
5. IP-in-IP Tunnels with Tightly Coupled Shim Headers 5. ECN Propagation and Fragmentation/Reassembly
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.
As a tunnel egress reassembles sets of outer fragments
[I-D.ietf-intarea-tunnels] into packets, it SHOULD propagate CE
markings on the basis that a congestion indication on a packet
applies to all the octets in the packet. On average, a tunnel egress
SHOULD approximately preserve the number of CE-marked and ECT(1)-
marked octets arriving and leaving (counting the size of inner
headers, but not encapsulating headers that are being stripped).
This process proceeds irrespective of the addresses on the inner
headers.
Even if only enough incoming CE-marked octets have arrived for part
of the departing packet, the next departing packet SHOULD be
immediately CE-marked. This ensures that CE-markings are propagated
immediately, rather than held back waiting for more incoming CE-
marked octets. Once there are no outstanding CE-marked octets, if
only enough incoming ECT(1)-marked octets have arrived for part of
the departing packet, the next departing packet SHOULD be immediately
marked ECT(1).
For instance, an algorithm for marking departing packets could
maintain a pair of counters, the first representing the balance of
arriving CE-marked octets minus departing CE-marked octets and the
second representing a similar balance of ECT(1)-marked octets. The
algorithm:
o adds the size of every CE-marked or ECT(1)-marked packet that
arrives to the appropriate counter;
o if the CE counter is positive, it CE-marks the next packet to
depart and subtracts its size from the CE counter;
o if the CE counter is negative but the ECT(1) counter is positive,
it marks the next packet to depart as ECT(1) and subtracts its
size from the ECT((1) counter;
o (the previous two steps will often leave a negative remainder in
the counters, which is deliberate);
o if neither counter is positive, it marks the next packet to depart
as ECT(0);
o until all the fragments of a packet have arrived, it does not
commit any updates to the counters so that, if reassembly fails
and the partly reassembled packet has to be discarded, none of the
discarded fragments will have updated any of the counters.
During reassembly of outer fragments [I-D.ietf-intarea-tunnels], 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.
A tunnel end-point that claims to support the present specification
MUST NOT use an approach that results in a significantly different
ECN-marking outcome to that defined by the "SHOULD" statements
throughout this section. "SHOULD" is only used to allow similar
perhaps more efficient approaches that result in approximately the
same outcome.
6. 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), in rough chronological order. The list is coupled shim header(s), in rough chronological order. The list is
confined to standards track or widely deployed protocols. The list confined to standards track or widely deployed protocols. The list
is not necessarily exhaustive so, for the avoidance of doubt, the is not necessarily exhaustive so, for the avoidance of doubt, the
scope of RFC 6040 is defined in Section 3 and is not limited to this scope of RFC 6040 is defined in Section 3 and is not limited to this
list. list.
o PPTP (Point-to-Point Tunneling Protocol) [RFC2637]; o PPTP (Point-to-Point Tunneling Protocol) [RFC2637];
skipping to change at page 8, line 29 skipping to change at page 10, line 9
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 5.1.2 below is also intended to the text that updates GRE in Section 6.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
skipping to change at page 9, line 18 skipping to change at page 10, line 47
The Network Service Header (NSH [RFC8300]) has been defined as a The Network Service Header (NSH [RFC8300]) has been defined as a
shim-based encapsulation to identify the Service Function Path (SFP) shim-based encapsulation to identify the Service Function Path (SFP)
in the Service Function Chaining (SFC) architecture [RFC7665]. A in the Service Function Chaining (SFC) architecture [RFC7665]. A
proposal has been made for the processing of ECN when handling proposal has been made for the processing of ECN when handling
transport encapsulation [I-D.ietf-sfc-nsh-ecn-support]. transport encapsulation [I-D.ietf-sfc-nsh-ecn-support].
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.
Section 3.1.11 of the UDP usage guidelines [RFC8085] already explains Section 3.1.11 of RFC 8085 already explains that a tunnel that
that a tunnel that encapsulates an IP header directly within a UDP/IP encapsulates an IP header within a UDP/IP datagram needs to follow
datagram needs to follow RFC 6040 when propagating the ECN field RFC 6040 when propagating the ECN field between inner and outer IP
between inner and outer IP headers. The requirements in Section 4 headers. The requirements in Section 4 update RFC 6040, and hence
update RFC 6040 so, by reference, they automatically update RFC 8085 implicitly update the UDP usage guidelines in RFC 8085 to add the
to add the important but previously unstated requirement that, if the important but previously unstated requirement that, if the UDP tunnel
UDP tunnel egress does not, or might not, support ECN propagation, a egress does not, or might not, support ECN propagation, a UDP tunnel
legacy UDP tunnel ingress has to clear the outer IP ECN field to ingress has to clear the outer IP ECN field to 0b00, e.g. by
0b00, e.g. by configuration. configuration.
Section 12.5 of TCP Encapsulation of IKE and IPsec Packets [RFC8229] Section 12.5 of TCP Encapsulation of IKE and IPsec Packets [RFC8229]
already recommends the compatibility mode of RFC 6040 in this case, already recommends the compatibility mode of RFC 6040 in this case,
because there is not a one-to-one mapping between inner and outer because there is not a one-to-one mapping between inner and outer
packets. packets.
5.1. Specific Updates to Protocols under IETF Change Control 6.1. Specific Updates to Protocols under IETF Change Control
5.1.1. L2TP (v2 and v3) ECN Extension 6.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).
skipping to change at page 10, line 10 skipping to change at page 11, line 38
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 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 5.1.1.2 below, in order to L2TPv2 and L2TPv3 defined in Section 6.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.
5.1.1.1. Safe Configuration of a 'Non-ECN' Ingress LCCE 6.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:
The operator of an LCCE that does not support the ECN Extension in The operator of an LCCE that does not support the ECN Extension in
Section 5.1.1.2 of RFCXXXX MUST follow the configuration Section 6.1.1.2 of RFCXXXX MUST follow the configuration
requirements in Section 4 of RFCXXXX to ensure it clears the outer requirements in Section 4 of RFCXXXX to ensure it clears the outer
IP ECN field to 0b00 when the outer PSN header is IP (v4 or v6). 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 {RFCXXXX refers to the present document so it will need to be
inserted by the RFC Editor} inserted by the RFC Editor}
In particular, for an LCCE implementation that does not support the In particular, for an LCCE implementation that does not support the
ECN Extension, this means that configuration of how it propagates the ECN Extension, this means that configuration of how it propagates the
ECN field between inner and outer IP headers MUST be independent of ECN field between inner and outer IP headers MUST be independent of
any configuration of the Diffserv extension of L2TP [RFC3308]. any configuration of the Diffserv extension of L2TP [RFC3308].
5.1.1.2. ECN Extension for L2TP (v2 or v3) 6.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 as LCCE to check that the egress LCCE supports ECN propagation as
defined in RFC 6040 or one of its compatible predecessors ([RFC4301] defined in RFC 6040 or one of its compatible predecessors ([RFC4301]
or the full functionality mode of [RFC3168]). If the egress supports or the full functionality mode of [RFC3168]). If the egress supports
ECN propagation, the ingress LCCE can use the normal mode of ECN propagation, the ingress LCCE can use the normal mode of
encapsulation (copying the ECN field from inner to outer). encapsulation (copying the ECN field from inner to outer).
Otherwise, the ingress LCCE has to use compatibility mode [RFC6040] Otherwise, the ingress LCCE has to use compatibility mode [RFC6040]
(clearing the outer IP ECN field to 0b00). (clearing the outer IP ECN field to 0b00).
An LCCE can determine the remote LCCE's support for ECN either An LCCE can determine the remote LCCE's support for ECN either
statically (by configuration) or by dynamic discovery during setup of statically (by configuration) or by dynamic discovery during setup of
each control connection between the LCCEs, using the Capability AVP each control connection between the LCCEs, using the Capability AVP
defined in Section 5.1.1.2.1 below. defined in Section 6.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.
5.1.1.2.1. LCCE Capability AVP for ECN Capability Negotiation 6.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 12, line 15 skipping to change at page 13, line 50
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 5.1.1.1 above, when it acts as safety provisions set out in Section 6.1.1.1 above, when it acts as
an ingress LCCE. an ingress LCCE.
5.1.2. GRE 6.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 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 itself does not support dynamic set-up and configuration of GRE itself does not support dynamic set-up and configuration of
tunnels. However, control plane protocols such as Mobile IPv4 (MIP4) tunnels. However, control plane protocols such as Mobile IPv4 (MIP4)
[RFC5944], Mobile IPv6 (MIP6) [RFC6275], Proxy Mobile IP (PMIP) [RFC5944], Mobile IPv6 (MIP6) [RFC6275], Proxy Mobile IP (PMIP)
[RFC5845] and IKEv2 [RFC5996] are sometimes used to set up GRE [RFC5845] and IKEv2 [RFC7296] are sometimes used to set up GRE
tunnels dynamically. tunnels dynamically.
When these control protocols set up IP-in-IP or IPSec tunnels, it is 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 likely that they propagate the ECN field as defined in RFC 6040 or
one of its compatible predecessors (RFC 4301 or the full one of its compatible predecessors (RFC 4301 or the full
functionality mode of RFC 3168). However, if they use a GRE functionality mode of RFC 3168). However, if they use a GRE
encapsulation, this presumption is less sound. encapsulation, this presumption is less sound.
Therefore, If the outer delivery protocol is IP (v4 or v6) the Therefore, If the outer delivery protocol is IP (v4 or v6) the
operator is obliged to follow the safe configuration requirements in operator is obliged to follow the safe configuration requirements in
Section 4 above. Section 5.1.2.1 below updates the base GRE Section 4 above. Section 6.1.2.1 below updates the base GRE
specification with this requirement, to emphasize its importance. specification with this requirement, to emphasize its importance.
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.
5.1.2.1. Safe Configuration of a 'Non-ECN' GRE Ingress 6.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:
The operator of a GRE tunnel ingress MUST follow the configuration The operator of a GRE tunnel ingress MUST follow the configuration
requirements in Section 4 of RFCXXXX when the outer delivery requirements in Section 4 of RFCXXXX when the outer delivery
protocol is IP (v4 or v6). {RFCXXXX refers to the present document protocol is IP (v4 or v6). {RFCXXXX refers to the present document
so it will need to be inserted by the RFC Editor} so it will need to be inserted by the RFC Editor}
5.1.3. Teredo 6.1.3. Teredo
Teredo [RFC4380] provides a way to tunnel IPv6 over an IPv4 network, Teredo [RFC4380] provides a way to tunnel IPv6 over an IPv4 network,
with a UDP-based shim header between the two. with a UDP-based shim header between the two.
For Teredo tunnel endpoints to provide the benefits of ECN, the For Teredo tunnel endpoints to provide the benefits of ECN, the
Teredo specification would have to be updated to include negotiation Teredo specification would have to be updated to include negotiation
of the ECN capability between Teredo tunnel endpoints. Otherwise it of the ECN capability between Teredo tunnel endpoints. Otherwise it
would be unsafe for a Teredo tunnel ingress to copy the ECN field to would be unsafe for a Teredo tunnel ingress to copy the ECN field to
the IPv6 outer. the IPv6 outer.
skipping to change at page 14, line 7 skipping to change at page 15, line 40
update the specification of Teredo implementations with the following update the specification of Teredo implementations with the following
text, as a new section 5.1.3: text, as a new section 5.1.3:
"5.1.3 Safe 'Non-ECN' Teredo Encapsulation "5.1.3 Safe 'Non-ECN' Teredo Encapsulation
A Teredo tunnel ingress implementation that does not support ECN A Teredo tunnel ingress implementation that does not support ECN
propagation as defined in RFC 6040 or one of its compatible propagation as defined in RFC 6040 or one of its compatible
predecessors (RFC 4301 or the full functionality mode of RFC 3168) predecessors (RFC 4301 or the full functionality mode of RFC 3168)
MUST zero the ECN field in the outer IPv6 header." MUST zero the ECN field in the outer IPv6 header."
5.1.4. AMT 6.1.4. AMT
Automatic Multicast Tunneling (AMT [RFC7450]) is a tightly coupled Automatic Multicast Tunneling (AMT [RFC7450]) is a tightly coupled
shim header that encapsulates an IP packet and is itself encapsulated shim header that encapsulates an IP packet and is itself encapsulated
within a UDP/IP datagram. Therefore AMT is within the scope of RFC within a UDP/IP datagram. Therefore AMT is within the scope of RFC
6040 as updated by Section 3 above. 6040 as updated by Section 3 above.
AMT tunnel endpoint maintainers are RECOMMENDED to support [RFC6040] AMT 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 an AMT tunnel benefits of ECN [RFC8087] whenever a node within an AMT tunnel
becomes the bottleneck for an IP traffic flow tunnelled over AMT. becomes the bottleneck for an IP traffic flow tunnelled over AMT.
skipping to change at page 14, line 34 skipping to change at page 16, line 20
AMT relay to check that the egress AMT gateway supports ECN AMT relay to check that the egress AMT gateway supports ECN
propagation as defined in RFC 6040 or one of its compatible propagation as defined in RFC 6040 or one of its compatible
predecessors (RFC 4301 or the full functionality mode of RFC 3168). predecessors (RFC 4301 or the full functionality mode of RFC 3168).
If the egress gateway supports ECN, the ingress relay can use the If the egress gateway supports ECN, the ingress relay can use the
normal mode of encapsulation (copying the IP ECN field from inner to normal mode of encapsulation (copying the IP ECN field from inner to
outer). Otherwise, the ingress relay has to use compatibility mode, outer). Otherwise, the ingress relay has to use compatibility mode,
which means it has to clear the outer ECN field to zero [RFC6040]. which means it has to clear the outer ECN field to zero [RFC6040].
An AMT tunnel is created dynamically (not manually), so the relay An AMT tunnel is created dynamically (not manually), so the relay
will need to determine the remote gateway's support for ECN using the will need to determine the remote gateway's support for ECN using the
ECN capability declaration defined in Section 5.1.4.2 below. ECN capability declaration defined in Section 6.1.4.2 below.
5.1.4.1. Safe Configuration of a 'Non-ECN' Ingress AMT Relay 6.1.4.1. Safe Configuration of a 'Non-ECN' Ingress AMT Relay
The following text is appended to Section 4.2.2 of [RFC7450] as an The following text is appended to Section 4.2.2 of [RFC7450] as an
update to the AMT specification: update to the AMT specification:
The operator of an AMT relay that does not support RFC 6040 or one The operator of an AMT relay that does not support RFC 6040 or one
of its compatible predecessors (RFC 4301 or the full functionality of its compatible predecessors (RFC 4301 or the full functionality
mode of RFC 3168) MUST follow the configuration requirements in mode of RFC 3168) MUST follow the configuration requirements in
Section 4 of RFCXXXX to ensure it clears the outer IP ECN field to Section 4 of RFCXXXX to ensure it clears the outer IP ECN field to
zero. {RFCXXXX refers to the present document so it will need to zero. {RFCXXXX refers to the present document so it will need to
be inserted by the RFC Editor} be inserted by the RFC Editor}
5.1.4.2. ECN Capability Declaration of an AMT Gateway 6.1.4.2. ECN Capability Declaration of an AMT Gateway
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=3 | Reserved |E|P| Reserved | | V=0 |Type=3 | Reserved |E|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Updated AMT Request Message Format Figure 2: Updated AMT Request Message Format
skipping to change at page 16, line 11 skipping to change at page 17, line 40
the normal mode of RFC 6040 to propagate the ECN field when the normal mode of RFC 6040 to propagate the ECN field when
encapsulating datagrams (i.e. it copies the IP ECN field from encapsulating datagrams (i.e. it copies the IP ECN field from
inner to outer). inner to outer).
o If the discovered AMT relay does not support RFC 6040 ECN o If the discovered AMT relay does not support RFC 6040 ECN
propagation, it will ignore the E flag in the Reserved field, as propagation, it will ignore the E flag in the Reserved field, as
per section 5.1.3.3. of RFC 7450. per section 5.1.3.3. of RFC 7450.
If the AMT relay does not support RFC 6040 ECN propagation, the If the AMT relay does not support RFC 6040 ECN propagation, the
network operator is still expected to configure it to comply with network operator is still expected to configure it to comply with
the safety provisions set out in Section 5.1.4.1 above. the safety provisions set out in Section 6.1.4.1 above.
6. IANA Considerations 7. 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 ]
7. Security Considerations 8. 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.
8. Comments Solicited 9. 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.
9. Acknowledgements 10. 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, Ignacio Goyret, Alia Atlas, Praveen Carlos Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen
Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake
Holland and Sri Gundavelli for helpful advice and comments. "A Holland and Sri Gundavelli for helpful advice and comments. "A
Comparison of IPv6-over-IPv4 Tunnel Mechanisms" [RFC7059] helped to Comparison of IPv6-over-IPv4 Tunnel Mechanisms" [RFC7059] helped to
identify a number of tunnelling protocols to include within the scope identify a number of tunnelling protocols to include within the scope
of this document. of this document.
Bob Briscoe was part-funded by the Research Council of Norway through Bob Briscoe was part-funded by the Research Council of Norway through
the TimeIn project. The views expressed here are solely those of the the TimeIn project. The views expressed here are solely those of the
authors. authors.
10. References 11. References
10.1. Normative References 11.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-11 (work in progress), November 2018. encap-guidelines-13 (work in progress), May 2019.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
skipping to change at page 18, line 18 skipping to change at page 19, line 48
<https://www.rfc-editor.org/info/rfc4380>. <https://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, <https://www.rfc-editor.org/info/rfc5129>. 2008, <https://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, <https://www.rfc-editor.org/info/rfc6040>. 2010, <https://www.rfc-editor.org/info/rfc6040>.
10.2. Informative References 11.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)",
Technical Specification TS 29.274. Technical Specification TS 29.274.
[I-D.ietf-intarea-gue] [I-D.ietf-intarea-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-ietf-intarea-gue-07 (work in Encapsulation", draft-ietf-intarea-gue-07 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-intarea-tunnels]
Touch, J. and M. Townsley, "IP Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-09 (work in
progress), July 2018.
[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-13 (work in progress), March 2019. nvo3-geneve-13 (work in progress), March 2019.
[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-06 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-07 (work
in progress), April 2018. in progress), April 2019.
[I-D.ietf-sfc-nsh-ecn-support] [I-D.ietf-sfc-nsh-ecn-support]
Eastlake, D., Briscoe, B., and A. Malis, "Explicit Eastlake, D., Briscoe, B., and A. Malis, "Explicit
Congestion Notification (ECN) and Congestion Feedback Congestion Notification (ECN) and Congestion Feedback
Using the Network Service Header (NSH)", draft-ietf-sfc- Using the Network Service Header (NSH)", draft-ietf-sfc-
nsh-ecn-support-00 (work in progress), February 2019. nsh-ecn-support-01 (work in progress), July 2019.
[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,
<https://www.rfc-editor.org/info/rfc1701>. <https://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,
<https://www.rfc-editor.org/info/rfc2637>. <https://www.rfc-editor.org/info/rfc2637>.
skipping to change at page 19, line 43 skipping to change at page 21, line 29
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy "Generic Routing Encapsulation (GRE) Key Option for Proxy
Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010, Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010,
<https://www.rfc-editor.org/info/rfc5845>. <https://www.rfc-editor.org/info/rfc5845>.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
RFC 5944, DOI 10.17487/RFC5944, November 2010, RFC 5944, DOI 10.17487/RFC5944, November 2010,
<https://www.rfc-editor.org/info/rfc5944>. <https://www.rfc-editor.org/info/rfc5944>.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, DOI 10.17487/RFC5996, September 2010,
<https://www.rfc-editor.org/info/rfc5996>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>. <https://www.rfc-editor.org/info/rfc6830>.
[RFC7059] Steffann, S., van Beijnum, I., and R. van Rein, "A [RFC7059] Steffann, S., van Beijnum, I., and R. van Rein, "A
Comparison of IPv6-over-IPv4 Tunnel Mechanisms", RFC 7059, Comparison of IPv6-over-IPv4 Tunnel Mechanisms", RFC 7059,
DOI 10.17487/RFC7059, November 2013, DOI 10.17487/RFC7059, November 2013,
<https://www.rfc-editor.org/info/rfc7059>. <https://www.rfc-editor.org/info/rfc7059>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015, DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>. <https://www.rfc-editor.org/info/rfc7450>.
 End of changes. 48 change blocks. 
89 lines changed or deleted 177 lines changed or added

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