One document matched: draft-briscoe-tsvwg-rfc6040bis-00.txt
Transport Area Working Group B. Briscoe
Internet-Draft Simula Research Laboratory
Updates: 2661, 1701, 2784, 2637, 7348 July 8, 2016
(if approved)
Intended status: Standards Track
Expires: January 9, 2017
Propagating Explicit Congestion Notification Across IP Tunnel Headers
Separated by a Shim
draft-briscoe-tsvwg-rfc6040bis-00
Abstract
RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
rules for propagation of ECN consistent for all forms of IP in IP
tunnel. This specification extends the scope of RFC 6040 to include
tunnels where two IP headers are separated by a shim header that
cannot stand alone.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Briscoe Expires January 9, 2017 [Page 1]
Internet-Draft ECN Tunnelling July 2016
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 2
4. IANA Considerations (to be removed by RFC Editor) . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 3
6. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 4
7. Normative References . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Scope of RFC 6040
RFC 6040 on "Tunnelling of Explicit Congestion Notification"
[RFC6040] made the rules for propagation of Explicit Congestion
Notification (ECN [RFC3168]) consistent for all forms of IP in IP
tunnel. The scope of RFC 6040 was stated as
"...ECN field processing at encapsulation and decapsulation for
any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It
applies irrespective of whether IPv4 or IPv6 is used for either
the inner or outer headers. ..."
A common pattern for many tunnelling protocols is to encapsulate an
inner IP header with shim header(s) then an outer IP header. To
clear up confusion, this specification clarifies that the scope of
RFC 6040 includes any IP-in-IP tunnel, including those with shim
header(s) between the IP headers.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. IP-in-IP Tunnels with Tightly Coupled Shim Headers
In many cases the shim header(s) and the outer IP header are always
added (or removed) as part of the same process. We call this a
tightly coupled shim header. Processing the shim and outer together
is often necessary because the shim(s) are not sufficient for packet
forwarding in their own right; not unless complemented by an outer
header.
Briscoe Expires January 9, 2017 [Page 2]
Internet-Draft ECN Tunnelling July 2016
For all such tightly coupled shim headers, the rules in [RFC6040] for
propagating the ECN field SHOULD be applied directly between the
inner and outer IP headers. This specification therefore updates the
following specifications of tightly coupled shim headers by adding
that RFC 6040 SHOULD apply when the shim header is used between IP
headers:
o L2TP [RFC2661]
o GRE [RFC1701], [RFC2784]
o PPTP [RFC2637]
o GTP [GTPv1], [GTPv1-U], [GTPv2-C]
o VXLAN [RFC7348].
The above is written as a 'SHOULD' not a 'MUST' to allow for the
possibility that the structure of some pre-existing tunnel
implementations might make it hard to predict what other headers will
be added or removed subsequently.
Although the definition of the various GTP shim headers is under the
control of the 3GPP, it is hard to determine whether the 3GPP or the
IETF controls standardization of the _process_ of adding both a GTP
and an IP header to an inner IP header. Nonetheless, the present
specification is provided so that the 3GPP can refer to it from any
of its own specifications of GTP and IP header processing.
More 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.
4. IANA Considerations (to be removed by RFC Editor)
This memo includes no request to IANA.
5. Security Considerations
The Security Considerations in RFC 6040 apply equally to the wider
scope defined by the present specification.
Briscoe Expires January 9, 2017 [Page 3]
Internet-Draft ECN Tunnelling July 2016
6. Comments Solicited
Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list
<tsvwg@ietf.org>, and/or to the authors.
7. Normative 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-tsvwg-ecn-encap-guidelines]
Briscoe, B., Kaippallimalil, J., and P. Thaler,
"Guidelines for Adding Congestion Notification to
Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
encap-guidelines-05 (work in progress), March 2016.
[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
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, DOI 10.17487/RFC2661, August 1999,
<http://www.rfc-editor.org/info/rfc2661>.
Briscoe Expires January 9, 2017 [Page 4]
Internet-Draft ECN Tunnelling July 2016
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<http://www.rfc-editor.org/info/rfc2784>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>.
Author's Address
Bob Briscoe
Simula Research Laboratory
UK
EMail: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/
Briscoe Expires January 9, 2017 [Page 5]
| PAFTECH AB 2003-2026 | 2026-04-22 08:02:57 |