draft-ietf-tsvwg-rfc6040update-shim-12.txt   draft-ietf-tsvwg-rfc6040update-shim-13.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft Independent Internet-Draft Independent
Updates: 6040, 2661, 2784, 3931, 4380, November 15, 2020 Updates: 6040, 2661, 2784, 3931, 4380, March 8, 2021
7450 (if approved) 7450 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: May 19, 2021 Expires: September 9, 2021
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-12 draft-ietf-tsvwg-rfc6040update-shim-13
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 that use such shim header(s) and updates the specifications protocols that use such shim header(s) and updates the specifications
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 19, 2021. This Internet-Draft will expire on September 9, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 29 skipping to change at page 2, line 29
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. ECN Propagation and Fragmentation/Reassembly . . . . . . . . 7 5. ECN Propagation and Fragmentation/Reassembly . . . . . . . . 7
6. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 7 6. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 7
6.1. Specific Updates to Protocols under IETF Change Control . 10 6.1. Specific Updates to Protocols under IETF Change Control . 10
6.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 10 6.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 10
6.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 14
6.1.4. AMT . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.4. AMT . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 17 9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
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
skipping to change at page 7, line 24 skipping to change at page 7, line 24
The following requirements update RFC6040, which omitted handling of The following requirements update RFC6040, which omitted handling of
the ECN field during fragmentation or reassembly. These changes the ECN field during fragmentation or reassembly. These changes
might alter how many ECN-marked packets are propagated by a tunnel might alter how many ECN-marked packets are propagated by a tunnel
that fragments packets, but this would not raise any backward that fragments packets, but this would not raise any backward
compatibility issues: compatibility issues:
If a tunnel ingress fragments a packet, it MUST set the outer ECN If a tunnel ingress fragments a packet, it MUST set the outer ECN
field of all the fragments to the same value as it would have set if field of all the fragments to the same value as it would have set if
it had not fragmented the packet. it had not fragmented the packet.
Section 5.3 of [RFC3168] defines the process that a tunnel egress
follows to reassemble sets of outer fragments
[I-D.ietf-intarea-tunnels] into packets.
During reassembly of outer fragments [I-D.ietf-intarea-tunnels], if During reassembly of outer fragments [I-D.ietf-intarea-tunnels], if
the ECN fields of the outer headers being reassembled into a single the ECN fields of the outer headers being reassembled into a single
packet consist of a mixture of Not-ECT and other ECN codepoints, the packet consist of a mixture of Not-ECT and other ECN codepoints, the
packet MUST be discarded. packet MUST be discarded.
Section 5.3 of [RFC3168] defines the process that a tunnel egress If there is mix of ECT(0) and ECT(1) fragments, then the reassembled
follows to reassemble sets of outer fragments packet MUST be set to either ECT(0) or ECT(1). In this case,
[I-D.ietf-intarea-tunnels] into packets. reassembly SHOULD take into account that the RFC series has so far
ensured that ECT(0) and ECT(1) can either be considered equivalent,
or they can provide 2 levels of congestion severity, where the
ranking of severity from highest to lowest is CE, ECT(1), ECT(0)
[RFC6040].
6. IP-in-IP Tunnels with Tightly Coupled Shim Headers 6. 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.
skipping to change at page 17, line 41 skipping to change at page 18, line 14
Bob Briscoe was part-funded by the Research Council of Norway through Bob Briscoe was part-funded by the Research Council of Norway through
the TimeIn project. The views expressed here are solely those of the the TimeIn project. The views expressed here are solely those of the
authors. authors.
11. References 11. References
11.1. Normative References 11.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. and J. Kaippallimalil, "Guidelines for Adding
"Guidelines for Adding Congestion Notification to Congestion Notification to Protocols that Encapsulate IP",
Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- draft-ietf-tsvwg-ecn-encap-guidelines-14 (work in
encap-guidelines-13 (work in progress), May 2019. progress), November 2020.
[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 19, line 37 skipping to change at page 20, line 9
[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 (VXLAN-GPE)", draft-ietf-nvo3-vxlan- Extension for VXLAN (VXLAN-GPE)", draft-ietf-nvo3-vxlan-
gpe-10 (work in progress), July 2020. gpe-10 (work in progress), July 2020.
[I-D.ietf-sfc-nsh-ecn-support] [I-D.ietf-sfc-nsh-ecn-support]
Eastlake, D., Briscoe, B., and A. Malis, "Explicit Eastlake, D., Briscoe, B., and A. Malis, "Explicit
Congestion Notification (ECN) and Congestion Feedback Congestion Notification (ECN) and Congestion Feedback
Using the Network Service Header (NSH)", draft-ietf-sfc- Using the Network Service Header (NSH)", draft-ietf-sfc-
nsh-ecn-support-03 (work in progress), July 2020. nsh-ecn-support-04 (work in progress), December 2020.
[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>.
 End of changes. 11 change blocks. 
18 lines changed or deleted 26 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/