draft-ietf-tsvwg-rfc6040update-shim-00.txt   draft-ietf-tsvwg-rfc6040update-shim-01.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft Simula Research Laboratory Internet-Draft Simula Research Laboratory
Updates: 6040, 2661, 1701, 2784, 2637, November 15, 2016 Updates: 6040, 2661, 2784, 3931 (if May 30, 2017
3931 (if approved) approved)
Intended status: Standards Track Intended status: Standards Track
Expires: May 19, 2017 Expires: December 1, 2017
Propagating Explicit Congestion Notification Across IP Tunnel Headers Propagating Explicit Congestion Notification Across IP Tunnel Headers
Separated by a Shim Separated by a Shim
draft-ietf-tsvwg-rfc6040update-shim-00 draft-ietf-tsvwg-rfc6040update-shim-01
Abstract Abstract
RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
rules for propagation of ECN consistent for all forms of IP in IP rules for propagation of ECN consistent for all forms of IP in IP
tunnel. This specification extends the scope of RFC 6040 to include tunnel. This specification extends the scope of RFC 6040 to include
tunnels where two IP headers are separated by a shim header that tunnels where two IP headers are separated by at least one shim
cannot stand alone. header that is not sufficient on its own for packet forwarding.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 19, 2017. This Internet-Draft will expire on December 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . . . 2 1. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 2 3. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 3
4. Specific Updates to Existing RFCs . . . . . . . . . . . . . . 3 4. Specific Updates to Protocols under IETF Change Control . . . 4
5. IANA Considerations (to be removed by RFC Editor) . . . . . . 4 4.1. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Scope of RFC 6040 1. Scope of RFC 6040
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. The scope of RFC 6040 was stated as tunnel. The scope of RFC 6040 was stated as
"...ECN field processing at encapsulation and decapsulation for "...ECN field processing at encapsulation and decapsulation for
any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It
applies irrespective of whether IPv4 or IPv6 is used for either applies irrespective of whether IPv4 or IPv6 is used for either
the inner or outer headers. ..." the inner or outer headers. ..."
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 with shim header(s) then an outer IP header. To inner IP header with shim header(s) then an outer IP header. To
clear up confusion, this specification clarifies that the scope of clear up confusion, this specification clarifies that the scope of
RFC 6040 includes any IP-in-IP tunnel, including those with shim RFC 6040 includes any IP-in-IP tunnel, including those with shim
header(s) between the IP headers. header(s) between the IP headers.
Propagation of ECN between tunnelled IP headers is related to
propagation of the Diffserv field over tunnels [RFC2983]. However,
unlike Diffserv, no configuration knobs are required, because the
network operator has no choices over propagation of the ECN field,
which has end-to-end semantics.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119]
when, and only when, they appear in all capitals, as shown here.
3. IP-in-IP Tunnels with Tightly Coupled Shim Headers 3. IP-in-IP Tunnels with Tightly Coupled Shim Headers
In many cases the shim header(s) and the outer IP header are always In many cases the shim header(s) and the outer IP header are always
added (or removed) as part of the same process. We call this a added (or removed) as part of the same process. We call this a
tightly coupled shim header. Processing the shim and outer together tightly coupled shim header. Processing the shim and outer together
is often necessary because the shim(s) are not sufficient for packet is often necessary because the shim(s) are not sufficient for packet
forwarding in their own right; not unless complemented by an outer forwarding in their own right; not unless complemented by an outer
header. header.
For all such tightly coupled shim headers, the rules in [RFC6040] for For all such tightly coupled shim headers, the rules in [RFC6040] for
propagating the ECN field SHOULD be applied directly between the propagating the ECN field MUST be applied between the inner and outer
inner and outer IP headers. This specification therefore updates the IP headers. The above is written as a 'MUST' because RFC 6040 allows
following specifications of tightly coupled shim headers by adding a compatibility mode for the encapsulator in cases where the
that RFC 6040 SHOULD apply when the shim header is used between IP decapsulator does not (or cannot) support ECN propagation. In the
headers: compatibility mode, the outer ECN field is cleared to zero.
There follows a list of encapsulations with tightly coupled shim
header(s). The list is not necessarily exhaustive, so the above
requirement applies to all tightly coupled shim headers whether or
not they are listed here.
o L2TPv2 [RFC2661], L2TPv3 [RFC3931] o L2TPv2 [RFC2661], L2TPv3 [RFC3931]
o GRE [RFC1701], [RFC2784], [RFC7637] o GRE [RFC2784], NVGRE [RFC7637]
o PPTP [RFC2637] o PPTP [RFC2637]
o GTP [GTPv1], [GTPv1-U], [GTPv2-C] o GTPv1 [GTPv1], GTP v1 User Plane [GTPv1-U], GTP v2 Control Plane
[GTPv2-C]
o VXLAN [RFC7348]. o VXLAN [RFC7348].
Geneve [I-D.ietf-nvo3-geneve] and Generic UDP Encapsulation (GUE) Geneve [I-D.ietf-nvo3-geneve] and Generic UDP Encapsulation (GUE)
[I-D.ietf-nvo3-gue] are also tightly coupled shim headers, but their [I-D.ietf-intarea-gue] are also tightly coupled shim headers, but
specifications already refer to RFC 6040 for ECN encapsulation. their specifications already refer to RFC 6040 for ECN encapsulation.
The above is written as a 'SHOULD' not a 'MUST' to allow for the Some of the listed protocols enable encapsulation of a variety of
possibility that the structure of some pre-existing tunnel network layer protocols as inner and/or outer. This specification
implementations might make it hard to predict what other headers will applies when the inner and outer are both IP (v4 or v6). More
be added or removed subsequently. generally, whatever form IP-in-IP tunnelling takes, the ECN field
SHOULD be propagated according to the rules in RFC 6040 wherever
possible. Otherwise [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more
general guidance on how to propagate ECN to and from protocols that
encapsulate IP.
Specific update text for those protocols in the above list that are
under IETF change control is given in Section 4. For those not under
IETF control, it is RECOMMENDED that implementations of encapsulation
and decapsulation comply with RFC 6040. It is also RECOMMENDED that
their specifications are updated to add a requirement to comply with
RFC 6040.
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.
Similarly, VXLAN and NVGRE are not under the control of the IETF, but PPTP is not under the change control of the IETF, but it has been
the present specification is provided so that the authors of any documented in an informational RFC [RFC2637]. However, there is no
future update to these specifications can refer to it. need for this memo to update PPTP because L2TP has been developed as
a standardized replacement.
More generally, whatever form IP-in-IP tunnelling takes, the ECN NVGRE is not under the change control of the IETF, but it has been
field SHOULD be propagated according to the rules in RFC 6040 documented in an informational RFC [RFC7637]. NVGRE is a specific
wherever possible. Otherwise [I-D.ietf-tsvwg-ecn-encap-guidelines] use-case of GRE (it re-purposes the key field from the initial
gives more general guidance on how to propagate ECN to and from specification of GRE [RFC1701] as a Virtual Subnet ID). Therefore
protocols that encapsulate IP.pdat the text that updates GRE below is also intended to update NVGRE.
4. Specific Updates to Existing RFCs VXLAN is not under the change control of the IETF but it has been
documented in an informational RFC. It is RECOMMENDED that VXLAN
implementations comply with RFC 6040 when the VXLAN header is
inserted between (or removed from between) IP headers. And the
authors of any future update to these specifications are encouraged
to add a requirement to comply with RFC 6040.
o L2TPv2 [RFC2661], L2TPv3 [RFC3931] 4. Specific Updates to Protocols under IETF Change Control
o GRE [RFC1701], 4.1. L2TPv3
o GRE [RFC2784]
o PPTP [RFC2637] L2TPv3 [RFC3931] can be used as a shim header that encapsulates an
L2-specific sub-layer then an L2 header containing an inner IP header
(v4 or v6). Then this whole stack of headers can be encapsulated
optionally within an outer UDP header then an outer IP header (v4 or
v6). Even though this shim is rather fat, it still fits the
definition of a tightly coupled shim header, because all the headers
are added (or removed) together.
{ToDo: Provide text for each of the above bullets} ECN propagation is defined here as an update to L2TPv3 itself,
because the ECN field in IP has end-to-end semantics with no operator
choice. In contrast, Diffserv handling was defined as an extension
to L2TP[RFC3308] because the operator of the tunnel determines
whether and how Diffserv is handled. This memo updates the
specification of L2TPv3 [RFC3931] as follows:
5. IANA Considerations (to be removed by RFC Editor) Append the following text to Section 4.5 of [RFC3931]:
This memo includes no request to IANA. "When the payload inside the L2 header and the outer PSN header
are both IP (v4 or v6), the ECN field MUST be propagated between
these IP headers according to the rules in Section 4 of RFC 6040
[RFC6040]. ECN propagation occurs both when the packet is
encapsulated and when it is decapsulated.
Before encapsulating any data packets, these rules require an LCCE
to check that the remote LCCE supports ECN propagation. If it
does, the normal mode of encapsulation can be used, otherwise the
compatibility mode is required [RFC6040]. 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 ECN AVP defined
below.
Where the outer PSN header is some protocol other than IP that
supports ECN, the appropriate ECN propagation specification will
need to be followed, e.g Explicit Congestion Marking in MPLS
[RFC5129]. Where no specification exists for ECN propagation by
particular PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more
general guidance on how to propagate ECN to and from protocols
that encapsulate IP."
Append the following text to the list of Control Connection AVPs
(Attribute Value Pairs) in Section 5.4.3 of [RFC3931]:
"ECN Capability (SCCRQ, SCCRP)
The ECN Capability AVP, Attribute Type ZZ, declares that the
sender of the AVP supports propagation of ECN. An LCCE
initiating a control connection will send a Start-Control-
Connection-Request (SCCRQ) containing the ECN AVP. If the
tunnel terminator supports ECN, it will return a Start-Control-
Connection-Reply (SCCRP) that also includes the ECN AVP. Then
both ends of the tunnel can use the normal mode of RFC 6040 to
propagate the ECN field when encapsulating data packets for any
sessions created by that control connection.
If, on the other hand, the tunnel terminator does not support
ECN it will ignore the ECN AVP and send an SCCRP to the tunnel
initiator without the ECN AVP. The tunnel initiator interprets
the absence of the ECN AVP in the SCCRP as an indication that
the tunnel terminator is incapable of supporting ECN. When
encapsulating data packets for any sessions created by that
control connection, it will then use the compatibility mode of
RFC 6040 to clear the ECN field of the outer IP header.
If there is no ECN AVP in an arriving control connection
request (SCCRQ), a tunnel terminator MUST NOT include the ECN
APV in its reply (SCCRP).
The Attribute Value field for this AVP is a bit-mask with the
following format:
0 1
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be present in the following message types: SCCRQ
and SCCRP. This AVP MAY be hidden (the H-bit set to 0 or 1)
and is optional (M-bit not set). The length (before hiding) of
this AVP MUST be 8 octets. The Vendor ID is the IETF Vendor ID
of 0.
When bit 15 of this attribute value field is set to 1, it
indicates that the sender supports ECN propagation. All the
other bits are reserved. They MUST be cleared to zero when
sent and ignored when received."
"
4.2. GRE
This memo updates the specification of GRE [RFC2784] by appending the
following text to Section 3:
"When the payload and delivery protocols are either both IP (v4 or
v6), the ECN field SHOULD be propagated between these IP headers
according to the rules in Section 4 of RFC 6040 [RFC6040]. ECN
propagation occurs both when the packet is encapsulated and when
it is decapsulated. In a case where the tunnel egress does not
support ECN propagation, RFC 6040 requires the encapsulator to use
compatibility mode.
Where the delivery protocol (outer header) is some protocol other
than IP that supports ECN, the appropriate ECN propagation
specification will need to be followed, e.g Explicit Congestion
Marking in MPLS [RFC5129]. Where no specification exists for ECN
propagation by particular PSN,
[I-D.ietf-tsvwg-ecn-encap-guidelines] gives more general guidance
on how to propagate ECN to and from protocols that encapsulate
IP."
5. IANA Considerations
IANA is requested to assign the following L2TP Control Message
Attribute Value Pair:
+----------------+----------------+-----------+
| Attribute Type | Description | Reference |
+----------------+----------------+-----------+
| ZZ | ECN Capability | RFCXXXX |
+----------------+----------------+-----------+
[TO BE REMOVED: This registration should take place at the following
location: https://www.iana.org/assignments/l2tp-parameters/l2tp-
parameters.xhtml ]
6. Security Considerations 6. Security Considerations
The Security Considerations in RFC 6040 apply equally to the wider The Security Considerations in [RFC6040] and
scope defined by the present specification. [I-D.ietf-tsvwg-ecn-encap-guidelines] apply equally to the scope
defined for the present specification.
7. Comments Solicited 7. 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.
8. Normative References 8. Acknowledgements
[GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp
interface", Technical Specification TS 29.060.
[GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", Technical Specification TS
29.281.
[GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) Thanks for Ing-jyh (Inton) Tsang for initial discussions on the need
Tunnelling Protocol for Control plane (GTPv2-C)", for ECN propagation in L2TP and its applicability.
Technical Specification TS 29.274.
[I-D.ietf-nvo3-geneve] 9. References
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-03 (work in progress), September 2016.
[I-D.ietf-nvo3-gue] 9.1. Normative References
Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-ietf-nvo3-gue-05 (work in progress),
October 2016.
[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-07 (work in progress), July 2016. encap-guidelines-08 (work in progress), March 2017.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701,
DOI 10.17487/RFC1701, October 1994,
<http://www.rfc-editor.org/info/rfc1701>.
[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>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol
(PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999,
<http://www.rfc-editor.org/info/rfc2637>.
[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>. <http://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>. <http://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>. <http://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>. <http://www.rfc-editor.org/info/rfc3931>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <http://www.rfc-editor.org/info/rfc5129>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <http://www.rfc-editor.org/info/rfc6040>. 2010, <http://www.rfc-editor.org/info/rfc6040>.
9.2. Informative References
[GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp
interface", Technical Specification TS 29.060.
[GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", Technical Specification TS
29.281.
[GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS)
Tunnelling Protocol for Control plane (GTPv2-C)",
Technical Specification TS 29.274.
[I-D.ietf-intarea-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-ietf-intarea-gue-04 (work in
progress), May 2017.
[I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-04 (work in progress), March 2017.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701,
DOI 10.17487/RFC1701, October 1994,
<http://www.rfc-editor.org/info/rfc1701>.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol
(PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999,
<http://www.rfc-editor.org/info/rfc2637>.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>.
[RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer
Two Tunneling Protocol (L2TP) Differentiated Services
Extension", RFC 3308, DOI 10.17487/RFC3308, November 2002,
<http://www.rfc-editor.org/info/rfc3308>.
[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>. <http://www.rfc-editor.org/info/rfc7348>.
[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,
 End of changes. 32 change blocks. 
78 lines changed or deleted 254 lines changed or added

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