draft-ietf-tsvwg-rfc6040update-shim-05.txt   draft-ietf-tsvwg-rfc6040update-shim-06.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft CableLabs Internet-Draft CableLabs
Updates: 6040, 2661, 2784, 3931, 4380, November 12, 2017 Updates: 6040, 2661, 2784, 3931, 4380, March 18, 2018
7450 (if approved) 7450 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: May 16, 2018 Expires: September 19, 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-05 draft-ietf-tsvwg-rfc6040update-shim-06
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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 16, 2018. This Internet-Draft will expire on September 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
5.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.4. AMT . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.4. AMT . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 16 8. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
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 7, line 27 skipping to change at page 7, line 27
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 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 The Network Service Header (NSH [RFC8300]) for Service Function
Chaining (SFC);
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 o Direct tunnelling of an IP packet within a UDP/IP datagram (see
Section 3.1.11 of [RFC8085]); Section 3.1.11 of [RFC8085]);
o TCP Encapsulation of IKE and IPsec Packets (see Section 12.5 of o TCP Encapsulation of IKE and IPsec Packets (see Section 12.5 of
[RFC8229]). [RFC8229]).
skipping to change at page 8, line 45 skipping to change at page 8, line 45
VXLAN is not under the change control of the IETF but it has been VXLAN is not under the change control of the IETF but it has been
documented in an informational RFC. In contrast, VXLAN-GPE (Generic documented in an informational RFC. In contrast, VXLAN-GPE (Generic
Protocol Extension) is being documented under IETF change control. Protocol Extension) is being documented under IETF change control.
It is RECOMMENDED that VXLAN and VXLAN-GPE implementations comply It is RECOMMENDED that VXLAN and VXLAN-GPE implementations comply
with RFC 6040 when the VXLAN header is inserted between (or removed with RFC 6040 when the VXLAN header is inserted between (or removed
from between) IP headers. The authors of any future update to these from between) IP headers. The authors of any future update to these
specifications are encouraged to add a requirement to comply with RFC specifications are encouraged to add a requirement to comply with RFC
6040 as updated by the present specification. 6040 as updated by the present specification.
Although the Service Function Chaining (SFC) architecture [RFC7665] The Network Service Header (NSH [RFC8300]) has been defined as a
depends on a shim-based encapsulation to identify the service shim-based encapsulation to identify the Service Function Path (SFP)
function path (SFP), it does not specify the processing of ECN when in the Service Function Chaining (SFC) architecture [RFC7665]. A
handling transport encapsulation. proposal has been made for the processing of ECN when handling
transport encapsulation [I-D.eastlake-sfc-nsh-ecn-support].
The specifications of Geneve and GUE already refer to RFC 6040 for The specifications of Geneve and GUE already refer to RFC 6040 for
ECN encapsulation. ECN encapsulation.
Section 3.1.11 of the UDP usage guidelines [RFC8085] already explains Section 3.1.11 of the UDP usage guidelines [RFC8085] already explains
that a tunnel that encapsulates an IP header directly within a UDP/IP that a tunnel that encapsulates an IP header directly within a UDP/IP
datagram needs to follow RFC 6040 when propagating the ECN field datagram needs to follow RFC 6040 when propagating the ECN field
between inner and outer IP headers. The requirements in Section 4 between inner and outer IP headers. The requirements in Section 4
update RFC 6040 so, by reference, they automatically update RFC 8085 update RFC 6040 so, by reference, they automatically update RFC 8085
to add the important but previously unstated requirement that, if the to add the important but previously unstated requirement that, if the
skipping to change at page 13, line 12 skipping to change at page 13, line 12
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:
The operator of a GRE tunnel ingress MUST follow the configuration The operator of a GRE tunnel ingress MUST follow the configuration
requirements in Section 4 of RFCXXXX when the outer delivery requirements in Section 4 of RFCXXXX when the outer delivery
protocol is IP (v4 or v6). {RFCXXXX refers to the present protocol is IP (v4 or v6). {RFCXXXX refers to the present document
document so it will need to be inserted by the RFC Editor} so it will need to be inserted by the RFC Editor}
5.1.3. Teredo 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
skipping to change at page 18, line 31 skipping to change at page 18, line 31
interface", Technical Specification TS 29.060. interface", Technical Specification TS 29.060.
[GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", Technical Specification TS Protocol User Plane (GTPv1-U)", Technical Specification TS
29.281. 29.281.
[GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) [GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS)
Tunnelling Protocol for Control plane (GTPv2-C)", Tunnelling Protocol for Control plane (GTPv2-C)",
Technical Specification TS 29.274. Technical Specification TS 29.274.
[I-D.eastlake-sfc-nsh-ecn-support]
Eastlake, D. and B. Briscoe, "Network Service Header (NSH)
Explicit Congestion Notification (ECN) Support", draft-
eastlake-sfc-nsh-ecn-support-00 (work in progress), March
2018.
[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-05 (work in
progress), May 2017. progress), December 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-05 (work in progress), September 2017. nvo3-geneve-06 (work in progress), March 2018.
[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-05 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-05 (work
in progress), October 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,
<https://www.rfc-editor.org/info/rfc1701>. <https://www.rfc-editor.org/info/rfc1701>.
skipping to change at page 20, line 44 skipping to change at page 20, line 49
[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,
<https://www.rfc-editor.org/info/rfc8159>. <https://www.rfc-editor.org/info/rfc8159>.
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
Author's Address Author's Address
Bob Briscoe Bob Briscoe
CableLabs CableLabs
UK UK
EMail: ietf@bobbriscoe.net EMail: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/ URI: http://bobbriscoe.net/
 End of changes. 13 change blocks. 
16 lines changed or deleted 29 lines changed or added

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