draft-ietf-tsvwg-rfc6040update-shim-09.txt   draft-ietf-tsvwg-rfc6040update-shim-10.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, July 8, 2019 Updates: 6040, 2661, 2784, 3931, 4380, March 9, 2020
7450 (if approved) 7450 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 9, 2020 Expires: September 10, 2020
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-09 draft-ietf-tsvwg-rfc6040update-shim-10
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 January 9, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 25 skipping to change at page 2, line 25
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. ECN Propagation and Fragmentation/Reassembly . . . . . . . . 7 5. ECN Propagation and Fragmentation/Reassembly . . . . . . . . 7
6. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 8 6. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 8
6.1. Specific Updates to Protocols under IETF Change Control . 11 6.1. Specific Updates to Protocols under IETF Change Control . 10
6.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 11 6.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 10
6.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 15 6.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 14
6.1.4. AMT . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1.4. AMT . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 18 9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 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
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 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.
As a tunnel egress reassembles sets of outer fragments
[I-D.ietf-intarea-tunnels] into packets, it SHOULD propagate CE
markings on the basis that a congestion indication on a packet
applies to all the octets in the packet. On average, a tunnel egress
SHOULD approximately preserve the number of CE-marked and ECT(1)-
marked octets arriving and leaving (counting the size of inner
headers, but not encapsulating headers that are being stripped).
This process proceeds irrespective of the addresses on the inner
headers.
Even if only enough incoming CE-marked octets have arrived for part
of the departing packet, the next departing packet SHOULD be
immediately CE-marked. This ensures that CE-markings are propagated
immediately, rather than held back waiting for more incoming CE-
marked octets. Once there are no outstanding CE-marked octets, if
only enough incoming ECT(1)-marked octets have arrived for part of
the departing packet, the next departing packet SHOULD be immediately
marked ECT(1).
For instance, an algorithm for marking departing packets could
maintain a pair of counters, the first representing the balance of
arriving CE-marked octets minus departing CE-marked octets and the
second representing a similar balance of ECT(1)-marked octets. The
algorithm:
o adds the size of every CE-marked or ECT(1)-marked packet that
arrives to the appropriate counter;
o if the CE counter is positive, it CE-marks the next packet to
depart and subtracts its size from the CE counter;
o if the CE counter is negative but the ECT(1) counter is positive,
it marks the next packet to depart as ECT(1) and subtracts its
size from the ECT((1) counter;
o (the previous two steps will often leave a negative remainder in
the counters, which is deliberate);
o if neither counter is positive, it marks the next packet to depart
as ECT(0);
o until all the fragments of a packet have arrived, it does not
commit any updates to the counters so that, if reassembly fails
and the partly reassembled packet has to be discarded, none of the
discarded fragments will have updated any of the counters.
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.
A tunnel end-point that claims to support the present specification As a tunnel egress reassembles sets of outer fragments
MUST NOT use an approach that results in a significantly different [I-D.ietf-intarea-tunnels] into packets, as long as no fragment
ECN-marking outcome to that defined by the "SHOULD" statements carries the Not-ECT codepoint, it SHOULD propagate CE markings such
throughout this section. "SHOULD" is only used to allow similar that the proportion of reassembled packets output with CE markings is
perhaps more efficient approaches that result in approximately the broadly the same as the proportion of fragments arriving with CE
same outcome. markings.
The above statement describes the approximate desired outcome, not
the specific mechanism. A simple to achieve this outcome would be to
leave a CE-mark on a reassembled packet if the head fragment is CE-
marked, irrespective of the markings on the other fragments.
Nonetheless, "SHOULD" is used in the above requirement to allow
similar perhaps more efficient approaches that result in
approximately the same outcome.
In RFC 3168 the approach to propagating CE markings during fragment
reassembly required that a reassembled packet has to be be CE-marked
if any of its fragments is CE-marked. This "logical OR" approach to
CE marking during reassembly was intended to ensure that no
individual CE marking is ever lost. However, an unintended
consequence is that the proportion of packets with CE markings
increases. For instance, with the logical OR approach, once a
sequence of packets each consisting of 2 fragments, has been
reassembled, the fraction of packets that are CE-marked roughly
doubles (because the number of marks remains roughly the same, but
the number of packets halves).
This specification does not rule out the logical OR approach of RFC
3168. So a tunnel egress MAY CE-mark a reassembled packet if any of
the fragments are CE-marked (and none are Not-ECT). However, this
approach could result in reduced link utilization, or bias against
flows that are fragmented relative to those that are not.
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 20, line 15 skipping to change at page 19, line 37
[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.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-07 (work in Encapsulation", draft-ietf-intarea-gue-09 (work in
progress), March 2019. progress), October 2019.
[I-D.ietf-intarea-tunnels] [I-D.ietf-intarea-tunnels]
Touch, J. and M. Townsley, "IP Tunnels in the Internet Touch, J. and M. Townsley, "IP Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-09 (work in Architecture", draft-ietf-intarea-tunnels-10 (work in
progress), July 2018. progress), September 2019.
[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-13 (work in progress), March 2019. nvo3-geneve-16 (work in progress), March 2020.
[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-07 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-09 (work
in progress), April 2019. in progress), December 2019.
[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-01 (work in progress), July 2019. nsh-ecn-support-02 (work in progress), January 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. 15 change blocks. 
73 lines changed or deleted 53 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/