< draft-ietf-tsvwg-rfc6040update-shim-04.txt   draft-ietf-tsvwg-rfc6040update-shim-05.txt >
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft Simula Research Laboratory Internet-Draft CableLabs
Updates: 6040, 2661, 2784, 3931, 4380 July 3, 2017 Updates: 6040, 2661, 2784, 3931, 4380, November 12, 2017
(if approved) 7450 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 4, 2018 Expires: May 16, 2018
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-04 draft-ietf-tsvwg-rfc6040update-shim-05
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 separated by such shim header(s) and updates the
specifications of those that do not mention ECN propagation (L2TPv2, specifications of those that do not mention ECN propagation (L2TPv2,
L2TPv3, GRE and Teredo). This specification also updates RFC 6040 L2TPv3, GRE, Teredo and AMT). This specification also updates RFC
with configuration requirements needed to make any legacy tunnel 6040 with configuration requirements needed to make any legacy tunnel
ingress safe. 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 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 January 4, 2018. This Internet-Draft will expire on May 16, 2018.
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 (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
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. 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 . . . . . 6 5. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 6
5.1. Specific Updates to Protocols under IETF Change Control . 8 5.1. Specific Updates to Protocols under IETF Change Control . 9
5.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 8 5.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 9
5.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5.1.4. AMT . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
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 4, line 12 skipping to change at page 4, line 16
access an inner IP header when adding or removing an outer IP access an inner IP header when adding or removing an outer IP
header; header;
2. those implementations that choose not to propagate ECN between IP 2. those implementations that choose not to propagate ECN between IP
headers. headers.
However, the ECN field is a non-optional part of the IP header (v4 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 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 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 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 supports propagation of the ECN field; it has to clear the ECN field
in any outer IP header. in any outer IP header to 0b00.
However, an RFC has no jurisdiction over implementations that choose However, an RFC has no jurisdiction over implementations that choose
not to comply with it or cannot comply with it, including all those not to comply with it or cannot comply with it, including all those
implementations that pre-dated the RFC. Therefore it would have been implementations that pre-dated the RFC. Therefore it would have been
unreasonable to add such a requirement to RFC 6040. Nonetheless, to unreasonable to add such a requirement to RFC 6040. Nonetheless, to
ensure safe propagation of the ECN field over tunnels, it is ensure safe propagation of the ECN field over tunnels, it is
reasonable to add requirements on operators, to ensure they configure reasonable to add requirements on operators, to ensure they configure
their tunnels safely (where possible). Before stating these their tunnels safely (where possible). Before stating these
configuration requirements in Section 4, the factors that determine configuration requirements in Section 4, the factors that determine
whether propagating ECN is feasible or desirable will be briefly whether propagating ECN is feasible or desirable will be briefly
skipping to change at page 5, line 29 skipping to change at page 5, line 33
o A network might be designed so that there is usually no bottleneck o A network might be designed so that there is usually no bottleneck
within the tunnel within the tunnel
o If the tunnel endpoints would have to search within an L2 header 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 to find an encapsulated IP header, it might not be worth the
potential performance hit potential performance hit
4. Making a non-ECN Tunnel Ingress Safe by Configuration 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 no specific attempt has been made to implement propagation
ought to be possible to render a tunnel ingress safe by of the ECN field at a tunnel ingress, it ought to be possible for the
configuration. The main safety concern is to disable the ECN operator to render a tunnel ingress safe by configuration. The main
capability in the outer IP header if the egress of the tunnel does 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 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.
Therefore this specification updates RFC 6040 by inserting the Therefore this specification updates RFC 6040 by inserting the
following text just before the last paragraph of section 4.3: following text just before the last paragraph of section 4.3:
When the implementation of a tunnel ingress does not support When the outer tunnel header is IP (v4 or v6), if possible, the
[RFC6040] or one of its compatible predecessors ([RFC4301] or the operator MUST configure the ingress to zero the outer ECN field in
full functionality mode of [RFC3168]) and when the outer tunnel any of the following cases:
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 * if it is known that the tunnel egress does not support
propagation of the ECN field (RFC 6040, RFC 4301 or the full propagation of the ECN field (RFC 6040, RFC 4301 or the full
functionality mode of RFC 3168) 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.
In order that the network operator can comply with the above safety In order that the network operator can comply with the above safety
rules, even if a tunnel ingress does not support RFC 6040, RFC 4301 rules, even if a tunnel ingress does not claim to support RFC 6040,
or the full functionality mode of RFC 3168, the implementation of the RFC 4301 or the full functionality mode of RFC 3168, the
tunnel ingress: implementation of the tunnel ingress:
o MUST make propagation of the ECN field between inner and outer IP o MUST make propagation of the ECN field between inner and outer IP
headers independent of any configuration of Diffserv codepoint headers independent of any configuration of Diffserv codepoint
propagation; propagation;
o SHOULD zero the outer ECN field in its default configuration. o SHOULD zero the outer ECN field in its default configuration.
There might be concern that the above "MUST" makes compliant There might be concern that the above "MUST" makes compliant
equipment non-compliant at a stroke. However, any equipment that is equipment non-compliant at a stroke. However, any equipment that is
still treating the ToS octet (IPv4) or the Traffic Class octet (IPv6) still treating the ToS octet (IPv4) or the Traffic Class octet (IPv6)
skipping to change at page 6, line 48 skipping to change at page 7, line 4
5. IP-in-IP Tunnels with Tightly Coupled Shim Headers 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), 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];
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];
o GTP (GPRS Tunnelling Protocol), specifically GTPv1 [GTPv1], GTP v1 o GTP (GPRS Tunnelling Protocol), specifically GTPv1 [GTPv1], GTP v1
User Plane [GTPv1-U], GTP v2 Control Plane [GTPv2-C]; User Plane [GTPv1-U], GTP v2 Control Plane [GTPv2-C];
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 AMT (Automatic Multicast Tunneling) [RFC7450];
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 SFC (Service Function Chaining) [RFC7665]; o SFC (Service Function Chaining) [RFC7665];
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];
o Direct tunnelling of an IP packet within a UDP/IP datagram (see
Section 3.1.11 of [RFC8085]);
o TCP Encapsulation of IKE and IPsec Packets (see Section 12.5 of
[RFC8229]).
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. 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 need to be updated to specify ECN Where protocols in the above list need to be updated to specify ECN
propagation and they are under IETF change control, update text is propagation and they are under IETF change control, update text is
skipping to change at page 8, line 39 skipping to change at page 9, line 5
6040 as updated by the present specification. 6040 as updated by the present specification.
Although the Service Function Chaining (SFC) architecture [RFC7665] Although the Service Function Chaining (SFC) architecture [RFC7665]
depends on a shim-based encapsulation to identify the service depends on a shim-based encapsulation to identify the service
function path (SFP), it does not specify the processing of ECN when function path (SFP), it does not specify the processing of ECN when
handling transport encapsulation. handling transport encapsulation.
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
that a tunnel that encapsulates an IP header directly within a UDP/IP
datagram needs to follow RFC 6040 when propagating the ECN field
between inner and outer IP headers. The requirements in Section 4
update RFC 6040 so, by reference, they automatically update 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
legacy 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 [RFC8229]
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.
5.1. Specific Updates to Protocols under IETF Change Control 5.1. Specific Updates to Protocols under IETF Change Control
5.1.1. L2TP (v2 and v3) ECN Extension 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
skipping to change at page 9, line 26 skipping to change at page 10, line 11
L2TPv2 and L2TPv3 defined in Section 5.1.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.
5.1.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 5.1.1.2 The operator of an LCCE that does not support the ECN Extension in
of RFCXXXX MUST follow the configuration requirements in Section 4 Section 5.1.1.2 of RFCXXXX MUST follow the configuration
of RFCXXXX for when the outer PSN header is IP (v4 or v6). 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).
{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) 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 as
egress supports ECN, the ingress LCCE can use the normal mode of defined in RFC 6040 or one of its compatible predecessors ([RFC4301]
encapsulation. Otherwise, the ingress LCCE has to use compatibility or the full functionality mode of [RFC3168]). If the egress supports
mode [RFC6040]. An LCCE can determine the remote LCCE's support for ECN propagation, the ingress LCCE can use the normal mode of
ECN either statically (by configuration) or by dynamic discovery encapsulation (copying the ECN field from inner to outer).
during setup of each control connection between the LCCEs, using the Otherwise, the ingress LCCE has to use compatibility mode [RFC6040]
Capability AVP defined in Section 5.1.1.2.1 below. (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 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.
5.1.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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Value Field for the LCCE Capability Attribute
This AVP MAY be present in the following message types: SCCRQ and This AVP MAY be present in the following message types: SCCRQ and
SCCRP (Start-Control-Connection-Request and Start-Control-Connection- 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 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 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. 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 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 the ECN Capability flag (E). When the ECN Capability flag is set to
1, it indicates that the sender supports ECN propagation. When the 1, it indicates that the sender supports ECN propagation. When the
ECN Capability flag is cleared to zero, or when no LCCE Capabiliy AVP ECN Capability flag is cleared to zero, or when no LCCE Capabiliy AVP
is present, it indicates that the sender does not support ECN is present, it indicates that the sender does not support ECN
propagation. All the other bits are reserved. They MUST be cleared propagation. All the other bits are reserved. They MUST be cleared
to zero when sent and ignored when received or forwarded. to zero when sent and ignored when received or forwarded.
An LCCE initiating a control connection will send a Start-Control- An LCCE initiating a control connection will send a Start-Control-
Connection-Request (SCCRQ) containing an LCCE Capability AVP with the Connection-Request (SCCRQ) containing an LCCE Capability AVP with the
ECN Capability flag set to 1. If the tunnel terminator supports ECN, ECN Capability flag set to 1. If the tunnel terminator supports ECN,
it will return a Start-Control-Connection-Reply (SCCRP) that also it will return a Start-Control-Connection-Reply (SCCRP) that also
includes an LCCE Capability AVP with the ECN Capability flag set to includes an LCCE Capability AVP with the ECN Capability flag set to
1. Then, for any sessions created by that control connection, both 1. Then, for any sessions created by that control connection, both
ends of the tunnel can use the normal mode of RFC 6040 to propagate ends of the tunnel can use the normal mode of RFC 6040, i.e. it can
the ECN field when encapsulating data packets. 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 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 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 to the tunnel initiator without a Capability AVP (or with a
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
skipping to change at page 11, line 29 skipping to change at page 12, line 24
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 tunnels do not support dynamic configuration based on capability GRE itself does not support dynamic set-up and configuration of
negotiation, so the ECN capability has to be manually configured. tunnels. However, control plane protocols such as Mobile IPv4 (MIP4)
For a GRE ingress implementation that supports ECN propagation, [RFC5944], Mobile IPv6 (MIP6) [RFC6275], Proxy Mobile IP (PMIP)
manual configuration requirements are specified in Section 4.3 of RFC [RFC5845] and IKEv2 [RFC5996] are sometimes used to set up GRE
6040. Otherwise they are specified in Section 5.1.2.1 below. 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
Section 4 above. Section 5.1.2.1 below updates the base GRE
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 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 The operator of a GRE tunnel ingress MUST follow the configuration
compatible predecessors (RFC 4301 or the full functionality mode requirements in Section 4 of RFCXXXX when the outer delivery
of RFC 3168) MUST follow the configuration requirements in protocol is IP (v4 or v6). {RFCXXXX refers to the present
Section 4 of RFCXXXX for when the outer delivery protocol is IP document so it will need to be inserted by the RFC Editor}
(v4 or v6). {RFCXXXX refers to the present document so it will
need to be inserted by the RFC Editor}
5.1.3. Teredo 5.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.
It is believed that current implementations do not support It is believed that current implementations do not support
propagation of ECN, but that they do safely zero the ECN field in the propagation of ECN, but that they do safely zero the ECN field in the
outer IPv6 header. However the specification does not mention outer IPv6 header. However the specification does not mention
anything about this. To make existing Teredo deployments safe it anything about this.
will not be feasible to require them to be configured correctly,
because Teredo tunnel endpoints are generally deployed on hosts. To make existing Teredo deployments safe, it would be possible to add
Therefore, the only feasible safety precaution available here is to ECN capability negotiation to those that are subject to remote OS
update the specification of Teredo implementations until ECN support update. However, for those implementations not subject to remote OS
is added. The following text updates the Teredo specification update, it will not be feasible to require them to be configured
[RFC4380], as a new section 5.1.3: 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 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
Automatic Multicast Tunneling (AMT [RFC7450]) 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 Section 3 above.
AMT tunnel endpoint maintainers are RECOMMENDED to support [RFC6040]
as updated by the present specification, in order to provide the
benefits of ECN [RFC8087] 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 [RFC6040].
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 [RFC6040].
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 Section 5.1.4.2 below.
5.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
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
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
be inserted by the RFC Editor}
5.1.4.2. ECN Capability Declaration of an AMT Gateway
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=3 | Reserved |E|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Updated AMT Request Message Format
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 Figure 2. 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:
o 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).
o 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 Section 5.1.4.1 above.
6. IANA Considerations 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 |
+----------------+----------------+-----------+ +----------------+----------------+-----------+
skipping to change at page 13, line 22 skipping to change at page 16, line 45
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 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, Ignacio Goyret, Alia Atlas, Praveen Carlos Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen
Balasubramanian, Joe Touch and Mohamed Boucadair for helpful advice Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake
and comments. Holland and Sri Gundavelli for helpful advice and comments. "A
Comparison of IPv6-over-IPv4 Tunnel Mechanisms" [RFC7059] 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.
10. References 10. References
10.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-09 (work in progress), July 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,
<http://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,
<http://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, DOI 10.17487/RFC2661, August 1999, RFC 2661, DOI 10.17487/RFC2661, August 1999,
<http://www.rfc-editor.org/info/rfc2661>. <https://www.rfc-editor.org/info/rfc2661>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<http://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)", "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005, RFC 3931, DOI 10.17487/RFC3931, March 2005,
<http://www.rfc-editor.org/info/rfc3931>. <https://www.rfc-editor.org/info/rfc3931>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006, DOI 10.17487/RFC4380, February 2006,
<http://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, <http://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, <http://www.rfc-editor.org/info/rfc6040>. 2010, <https://www.rfc-editor.org/info/rfc6040>.
10.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.
skipping to change at page 15, line 13 skipping to change at page 18, line 39
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-04 (work in Encapsulation", draft-ietf-intarea-gue-04 (work in
progress), May 2017. progress), May 2017.
[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-05 (work in progress), September 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-05 (work
in progress), April 2017. in progress), October 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>. <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,
<http://www.rfc-editor.org/info/rfc2637>. <https://www.rfc-editor.org/info/rfc2637>.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000, RFC 2983, DOI 10.17487/RFC2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>. <https://www.rfc-editor.org/info/rfc2983>.
[RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer [RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer
Two Tunneling Protocol (L2TP) Differentiated Services Two Tunneling Protocol (L2TP) Differentiated Services
Extension", RFC 3308, DOI 10.17487/RFC3308, November 2002, Extension", RFC 3308, DOI 10.17487/RFC3308, November 2002,
<http://www.rfc-editor.org/info/rfc3308>. <https://www.rfc-editor.org/info/rfc3308>.
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control And Provisioning of Wireless Access Points Ed., "Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification", RFC 5415, (CAPWAP) Protocol Specification", RFC 5415,
DOI 10.17487/RFC5415, March 2009, DOI 10.17487/RFC5415, March 2009,
<http://www.rfc-editor.org/info/rfc5415>. <https://www.rfc-editor.org/info/rfc5415>.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy
Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010,
<https://www.rfc-editor.org/info/rfc5845>.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
RFC 5944, DOI 10.17487/RFC5944, November 2010,
<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
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
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,
<http://www.rfc-editor.org/info/rfc6830>. <https://www.rfc-editor.org/info/rfc6830>.
[RFC7059] Steffann, S., van Beijnum, I., and R. van Rein, "A
Comparison of IPv6-over-IPv4 Tunnel Mechanisms", RFC 7059,
DOI 10.17487/RFC7059, November 2013,
<https://www.rfc-editor.org/info/rfc7059>.
[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,
<http://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation", Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015, RFC 7637, DOI 10.17487/RFC7637, September 2015,
<http://www.rfc-editor.org/info/rfc7637>. <https://www.rfc-editor.org/info/rfc7637>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087, Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017, DOI 10.17487/RFC8087, March 2017,
<http://www.rfc-editor.org/info/rfc8087>. <https://www.rfc-editor.org/info/rfc8087>.
[RFC8159] Konstantynowicz, M., Ed., Heron, G., Ed., Schatzmayr, R., [RFC8159] Konstantynowicz, M., Ed., Heron, G., Ed., Schatzmayr, R.,
and W. Henderickx, "Keyed IPv6 Tunnel", RFC 8159, and W. Henderickx, "Keyed IPv6 Tunnel", RFC 8159,
DOI 10.17487/RFC8159, May 2017, DOI 10.17487/RFC8159, May 2017,
<http://www.rfc-editor.org/info/rfc8159>. <https://www.rfc-editor.org/info/rfc8159>.
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>.
Author's Address Author's Address
Bob Briscoe Bob Briscoe
Simula Research Laboratory CableLabs
UK UK
EMail: ietf@bobbriscoe.net EMail: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/ URI: http://bobbriscoe.net/
 End of changes. 51 change blocks. 
98 lines changed or deleted 280 lines changed or added

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