draft-ietf-tsvwg-rfc6040update-shim-06.txt   draft-ietf-tsvwg-rfc6040update-shim-07.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft CableLabs Internet-Draft Independent
Updates: 6040, 2661, 2784, 3931, 4380, March 18, 2018 Updates: 6040, 2661, 2784, 3931, 4380, November 12, 2018
7450 (if approved) 7450 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 19, 2018 Expires: May 16, 2019
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-06 draft-ietf-tsvwg-rfc6040update-shim-07
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 September 19, 2018. This Internet-Draft will expire on May 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Feasibility of ECN Propagation between Tunnel Headers . . 4 3.1. Feasibility of ECN Propagation between Tunnel Headers . . 4
3.2. Desirability of ECN Propagation between Tunnel Headers . 5 3.2. Desirability of ECN Propagation between Tunnel Headers . 5
4. Making a non-ECN Tunnel Ingress Safe by Configuration . . . . 5 4. Making a non-ECN Tunnel Ingress Safe by Configuration . . . . 5
5. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 6 5. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 7
5.1. Specific Updates to Protocols under IETF Change Control . 9 5.1. Specific Updates to Protocols under IETF Change Control . 9
5.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 9 5.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 9
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
skipping to change at page 5, line 8 skipping to change at page 5, line 8
Digging to arbitrary depths to find an inner IP header within an Digging to arbitrary depths to find an inner IP header within an
encapsulation is strictly a layering violation so it cannot be a encapsulation is strictly a layering violation so it cannot be a
required behaviour. Nonetheless, some tunnel endpoints already look required behaviour. Nonetheless, some tunnel endpoints already look
within a L2 header for an IP header, for instance to map the Diffserv within a L2 header for an IP header, for instance to map the Diffserv
codepoint between an encapsulated IP header and an outer IP header codepoint between an encapsulated IP header and an outer IP header
[RFC2983]. In such cases at least, it should be feasible to also [RFC2983]. In such cases at least, it should be feasible to also
(independently) propagate the ECN field between the same IP headers. (independently) propagate the ECN field between the same IP headers.
Thus, access to the ECN field within an encapsulating header can be a Thus, access to the ECN field within an encapsulating header can be a
useful and benign optimization. The guidelines in section 6 of useful and benign optimization. The guidelines in section 5 of
[I-D.ietf-tsvwg-ecn-encap-guidelines] give the conditions for this [I-D.ietf-tsvwg-ecn-encap-guidelines] give the conditions for this
layering violation to be benign. layering violation to be benign.
3.2. Desirability of ECN Propagation between Tunnel Headers 3.2. Desirability of ECN Propagation between Tunnel Headers
Developers and network operators are encouraged to implement and Developers and network operators are encouraged to implement and
deploy tunnel endpoints compliant with RFC 6040 (as updated by the deploy tunnel endpoints compliant with RFC 6040 (as updated by the
present specification) in order to provide the benefits of wider ECN present specification) in order to provide the benefits of wider ECN
deployment [RFC8087]. Nonetheless, propagation of ECN between IP deployment [RFC8087]. Nonetheless, propagation of ECN between IP
headers, whether separated by shim headers or not, has to be optional headers, whether separated by shim headers or not, has to be optional
skipping to change at page 5, line 45 skipping to change at page 5, line 45
operator to render a tunnel ingress safe by configuration. The main operator to render a tunnel ingress safe by configuration. The main
safety concern is to disable (clear to zero) the ECN capability in 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 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 at the end of section 4.3:
When the outer tunnel header is IP (v4 or v6), if possible, the "
operator MUST configure the ingress to zero the outer ECN field in Whether or not an ingress implementation claims compliance with
any of the following cases: RFC 6040, RFC 4301 or RFC3168, when the outer tunnel 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 For the avoidance of doubt, the above only concerns the outer IP
rules, even if a tunnel ingress does not claim to support RFC 6040, header. The ingress MUST NOT alter the ECN field of the arriving
RFC 4301 or the full functionality mode of RFC 3168, the IP header that will become the inner IP header.
implementation of the tunnel ingress:
o MUST make propagation of the ECN field between inner and outer IP In order that the network operator can comply with the above
headers independent of any configuration of Diffserv codepoint safety rules, even if an implementation of a tunnel ingress does
propagation; not claim to support RFC 6040, RFC 4301 or the full functionality
mode of RFC 3168:
o SHOULD zero the outer ECN field in its default configuration. * it MUST make propagation of the ECN field between inner and
outer IP headers independent of any configuration of Diffserv
codepoint propagation;
* it SHOULD be able to be configured to zero the outer ECN field.
"
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 former ToS octet (IPv4) or the former Traffic
as a single 8-bit field is already non-compliant, and has been since Class octet (IPv6) as a single 8-bit field is already non-compliant,
1998 when the upper 6 bits were separated off for the Diffserv and has been since 1998 when the upper 6 bits were separated off for
codepoint (DSCP) [RFC2474]. For instance, copying the ECN field as a the Diffserv field [RFC2474], [RFC3260]. For instance, copying the
side-effect of copying the DSCP is a seriously unsafe bug that risks ECN field as a side-effect of copying the DSCP is a seriously unsafe
breaking the feedback loops that regulate load on a tunnel. bug that risks breaking the feedback loops that regulate load on a
tunnel.
Permanently zeroing the outer ECN field is safe, but it is not Permanently zeroing the outer ECN field is safe, but it is not
sufficient to claim compliance with RFC 6040 because it does not meet sufficient to claim compliance with RFC 6040 because it does not meet
the aim of introducing ECN support to tunnels (see Section 4.3 of the aim of introducing ECN support to tunnels (see Section 4.3 of
[RFC6040]). [RFC6040]).
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
skipping to change at page 17, line 17 skipping to change at page 17, line 17
authors. 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-09 (work in progress), July 2017. encap-guidelines-11 (work in progress), Novemeber 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
skipping to change at page 18, line 32 skipping to change at page 18, line 32
[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] [I-D.eastlake-sfc-nsh-ecn-support]
Eastlake, D. and B. Briscoe, "Network Service Header (NSH) Eastlake, D., Briscoe, B., and A. Malis, "Explicit
Explicit Congestion Notification (ECN) Support", draft- Congestion Notification (ECN) and Congestion Feedback
eastlake-sfc-nsh-ecn-support-00 (work in progress), March Using the Network Service Header (NSH)", draft-eastlake-
2018. sfc-nsh-ecn-support-02 (work in progress), October 2018.
[I-D.ietf-intarea-gue] [I-D.ietf-intarea-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T. and O. Zia, "Generic UDP Encapsulation",
Encapsulation", draft-ietf-intarea-gue-05 (work in draft-ietf-intarea-gue-06 (work in progress), August 2018.
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-06 (work in progress), March 2018. nvo3-geneve-08 (work in progress), October 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-06 (work
in progress), October 2017. in progress), April 2018.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, Routing Encapsulation (GRE)", RFC 1701,
DOI 10.17487/RFC1701, October 1994, DOI 10.17487/RFC1701, October 1994,
<https://www.rfc-editor.org/info/rfc1701>. <https://www.rfc-editor.org/info/rfc1701>.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol W., and G. Zorn, "Point-to-Point Tunneling Protocol
(PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999,
<https://www.rfc-editor.org/info/rfc2637>. <https://www.rfc-editor.org/info/rfc2637>.
[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,
<https://www.rfc-editor.org/info/rfc2983>. <https://www.rfc-editor.org/info/rfc2983>.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002,
<https://www.rfc-editor.org/info/rfc3260>.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc5415>. <https://www.rfc-editor.org/info/rfc5415>.
skipping to change at page 21, line 8 skipping to change at page 21, line 13
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., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
Author's Address Author's Address
Bob Briscoe Bob Briscoe
CableLabs Independent
UK UK
EMail: ietf@bobbriscoe.net EMail: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/ URI: http://bobbriscoe.net/
 End of changes. 19 change blocks. 
37 lines changed or deleted 49 lines changed or added

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