idnits 2.17.1 draft-briscoe-tsvwg-rfc6040update-shim-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2661, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2637, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6040, but the abstract doesn't seem to directly say this. It does mention RFC6040 though, so this could be OK. -- The draft header indicates that this document updates RFC2784, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1701, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1701, updated by this document, for RFC5378 checks: 1993-09-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 15, 2016) is 2712 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'GTPv1' -- Possible downref: Non-RFC (?) normative reference: ref. 'GTPv1-U' -- Possible downref: Non-RFC (?) normative reference: ref. 'GTPv2-C' == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-03 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-ecn-encap-guidelines-07 ** Downref: Normative reference to an Informational RFC: RFC 1701 ** Downref: Normative reference to an Informational RFC: RFC 2637 ** Downref: Normative reference to an Informational RFC: RFC 7348 ** Downref: Normative reference to an Informational RFC: RFC 7637 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group B. Briscoe 3 Internet-Draft Simula Research Laboratory 4 Updates: 6040, 2661, 1701, 2784, 2637, November 15, 2016 5 3931 (if approved) 6 Intended status: Standards Track 7 Expires: May 19, 2017 9 Propagating Explicit Congestion Notification Across IP Tunnel Headers 10 Separated by a Shim 11 draft-briscoe-tsvwg-rfc6040update-shim-00 13 Abstract 15 RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the 16 rules for propagation of ECN consistent for all forms of IP in IP 17 tunnel. This specification extends the scope of RFC 6040 to include 18 tunnels where two IP headers are separated by a shim header that 19 cannot stand alone. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 19, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 2 58 4. Specific Updates to Existing RFCs . . . . . . . . . . . . . . 3 59 5. IANA Considerations (to be removed by RFC Editor) . . . . . . 4 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 4 62 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Scope of RFC 6040 67 RFC 6040 on "Tunnelling of Explicit Congestion Notification" 68 [RFC6040] made the rules for propagation of Explicit Congestion 69 Notification (ECN [RFC3168]) consistent for all forms of IP in IP 70 tunnel. The scope of RFC 6040 was stated as 72 "...ECN field processing at encapsulation and decapsulation for 73 any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It 74 applies irrespective of whether IPv4 or IPv6 is used for either 75 the inner or outer headers. ..." 77 A common pattern for many tunnelling protocols is to encapsulate an 78 inner IP header with shim header(s) then an outer IP header. To 79 clear up confusion, this specification clarifies that the scope of 80 RFC 6040 includes any IP-in-IP tunnel, including those with shim 81 header(s) between the IP headers. 83 2. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 3. IP-in-IP Tunnels with Tightly Coupled Shim Headers 91 In many cases the shim header(s) and the outer IP header are always 92 added (or removed) as part of the same process. We call this a 93 tightly coupled shim header. Processing the shim and outer together 94 is often necessary because the shim(s) are not sufficient for packet 95 forwarding in their own right; not unless complemented by an outer 96 header. 98 For all such tightly coupled shim headers, the rules in [RFC6040] for 99 propagating the ECN field SHOULD be applied directly between the 100 inner and outer IP headers. This specification therefore updates the 101 following specifications of tightly coupled shim headers by adding 102 that RFC 6040 SHOULD apply when the shim header is used between IP 103 headers: 105 o L2TPv2 [RFC2661], L2TPv3 [RFC3931] 107 o GRE [RFC1701], [RFC2784], [RFC7637] 109 o PPTP [RFC2637] 111 o GTP [GTPv1], [GTPv1-U], [GTPv2-C] 113 o VXLAN [RFC7348]. 115 Geneve [I-D.ietf-nvo3-geneve] and Generic UDP Encapsulation (GUE) 116 [I-D.ietf-nvo3-gue] are also tightly coupled shim headers, but their 117 specifications already refer to RFC 6040 for ECN encapsulation. 119 The above is written as a 'SHOULD' not a 'MUST' to allow for the 120 possibility that the structure of some pre-existing tunnel 121 implementations might make it hard to predict what other headers will 122 be added or removed subsequently. 124 Although the definition of the various GTP shim headers is under the 125 control of the 3GPP, it is hard to determine whether the 3GPP or the 126 IETF controls standardization of the _process_ of adding both a GTP 127 and an IP header to an inner IP header. Nonetheless, the present 128 specification is provided so that the 3GPP can refer to it from any 129 of its own specifications of GTP and IP header processing. 131 Similarly, VXLAN and NVGRE are not under the control of the IETF, but 132 the present specification is provided so that the authors of any 133 future update to these specifications can refer to it. 135 More generally, whatever form IP-in-IP tunnelling takes, the ECN 136 field SHOULD be propagated according to the rules in RFC 6040 137 wherever possible. Otherwise [I-D.ietf-tsvwg-ecn-encap-guidelines] 138 gives more general guidance on how to propagate ECN to and from 139 protocols that encapsulate IP.pdat 141 4. Specific Updates to Existing RFCs 143 o L2TPv2 [RFC2661], L2TPv3 [RFC3931] 145 o GRE [RFC1701], 146 o GRE [RFC2784] 148 o PPTP [RFC2637] 150 {ToDo: Provide text for each of the above bullets} 152 5. IANA Considerations (to be removed by RFC Editor) 154 This memo includes no request to IANA. 156 6. Security Considerations 158 The Security Considerations in RFC 6040 apply equally to the wider 159 scope defined by the present specification. 161 7. Comments Solicited 163 Comments and questions are encouraged and very welcome. They can be 164 addressed to the IETF Transport Area working group mailing list 165 , and/or to the authors. 167 8. Normative References 169 [GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp 170 interface", Technical Specification TS 29.060. 172 [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling 173 Protocol User Plane (GTPv1-U)", Technical Specification TS 174 29.281. 176 [GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) 177 Tunnelling Protocol for Control plane (GTPv2-C)", 178 Technical Specification TS 29.274. 180 [I-D.ietf-nvo3-geneve] 181 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 182 Network Virtualization Encapsulation", draft-ietf- 183 nvo3-geneve-03 (work in progress), September 2016. 185 [I-D.ietf-nvo3-gue] 186 Herbert, T., Yong, L., and O. Zia, "Generic UDP 187 Encapsulation", draft-ietf-nvo3-gue-05 (work in progress), 188 October 2016. 190 [I-D.ietf-tsvwg-ecn-encap-guidelines] 191 Briscoe, B., Kaippallimalil, J., and P. Thaler, 192 "Guidelines for Adding Congestion Notification to 193 Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- 194 encap-guidelines-07 (work in progress), July 2016. 196 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 197 Routing Encapsulation (GRE)", RFC 1701, 198 DOI 10.17487/RFC1701, October 1994, 199 . 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, 203 DOI 10.17487/RFC2119, March 1997, 204 . 206 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 207 W., and G. Zorn, "Point-to-Point Tunneling Protocol 208 (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, 209 . 211 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 212 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 213 RFC 2661, DOI 10.17487/RFC2661, August 1999, 214 . 216 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 217 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 218 DOI 10.17487/RFC2784, March 2000, 219 . 221 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 222 of Explicit Congestion Notification (ECN) to IP", 223 RFC 3168, DOI 10.17487/RFC3168, September 2001, 224 . 226 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 227 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 228 RFC 3931, DOI 10.17487/RFC3931, March 2005, 229 . 231 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 232 Notification", RFC 6040, DOI 10.17487/RFC6040, November 233 2010, . 235 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 236 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 237 eXtensible Local Area Network (VXLAN): A Framework for 238 Overlaying Virtualized Layer 2 Networks over Layer 3 239 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 240 . 242 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 243 Virtualization Using Generic Routing Encapsulation", 244 RFC 7637, DOI 10.17487/RFC7637, September 2015, 245 . 247 Author's Address 249 Bob Briscoe 250 Simula Research Laboratory 251 UK 253 EMail: ietf@bobbriscoe.net 254 URI: http://bobbriscoe.net/