idnits 2.17.1 draft-ietf-tsvwg-rfc6040update-shim-01.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 RFC3931, 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2661, updated by this document, for RFC5378 checks: 1996-09-19) -- 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 (May 30, 2017) is 2522 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) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-ecn-encap-guidelines-08 == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-04 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 6 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, 2784, 3931 (if May 30, 2017 5 approved) 6 Intended status: Standards Track 7 Expires: December 1, 2017 9 Propagating Explicit Congestion Notification Across IP Tunnel Headers 10 Separated by a Shim 11 draft-ietf-tsvwg-rfc6040update-shim-01 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 at least one shim 19 header that is not sufficient on its own for packet forwarding. 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 December 1, 2017. 38 Copyright Notice 40 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 3 58 4. Specific Updates to Protocols under IETF Change Control . . . 4 59 4.1. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 7 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 9.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Scope of RFC 6040 72 RFC 6040 on "Tunnelling of Explicit Congestion Notification" 73 [RFC6040] made the rules for propagation of Explicit Congestion 74 Notification (ECN [RFC3168]) consistent for all forms of IP in IP 75 tunnel. The scope of RFC 6040 was stated as 77 "...ECN field processing at encapsulation and decapsulation for 78 any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It 79 applies irrespective of whether IPv4 or IPv6 is used for either 80 the inner or outer headers. ..." 82 A common pattern for many tunnelling protocols is to encapsulate an 83 inner IP header with shim header(s) then an outer IP header. To 84 clear up confusion, this specification clarifies that the scope of 85 RFC 6040 includes any IP-in-IP tunnel, including those with shim 86 header(s) between the IP headers. 88 Propagation of ECN between tunnelled IP headers is related to 89 propagation of the Diffserv field over tunnels [RFC2983]. However, 90 unlike Diffserv, no configuration knobs are required, because the 91 network operator has no choices over propagation of the ECN field, 92 which has end-to-end semantics. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119] 99 when, and only when, they appear in all capitals, as shown here. 101 3. IP-in-IP Tunnels with Tightly Coupled Shim Headers 103 In many cases the shim header(s) and the outer IP header are always 104 added (or removed) as part of the same process. We call this a 105 tightly coupled shim header. Processing the shim and outer together 106 is often necessary because the shim(s) are not sufficient for packet 107 forwarding in their own right; not unless complemented by an outer 108 header. 110 For all such tightly coupled shim headers, the rules in [RFC6040] for 111 propagating the ECN field MUST be applied between the inner and outer 112 IP headers. The above is written as a 'MUST' because RFC 6040 allows 113 a compatibility mode for the encapsulator in cases where the 114 decapsulator does not (or cannot) support ECN propagation. In the 115 compatibility mode, the outer ECN field is cleared to zero. 117 There follows a list of encapsulations with tightly coupled shim 118 header(s). The list is not necessarily exhaustive, so the above 119 requirement applies to all tightly coupled shim headers whether or 120 not they are listed here. 122 o L2TPv2 [RFC2661], L2TPv3 [RFC3931] 124 o GRE [RFC2784], NVGRE [RFC7637] 126 o PPTP [RFC2637] 128 o GTPv1 [GTPv1], GTP v1 User Plane [GTPv1-U], GTP v2 Control Plane 129 [GTPv2-C] 131 o VXLAN [RFC7348]. 133 Geneve [I-D.ietf-nvo3-geneve] and Generic UDP Encapsulation (GUE) 134 [I-D.ietf-intarea-gue] are also tightly coupled shim headers, but 135 their specifications already refer to RFC 6040 for ECN encapsulation. 137 Some of the listed protocols enable encapsulation of a variety of 138 network layer protocols as inner and/or outer. This specification 139 applies when the inner and outer are both IP (v4 or v6). More 140 generally, whatever form IP-in-IP tunnelling takes, the ECN field 141 SHOULD be propagated according to the rules in RFC 6040 wherever 142 possible. Otherwise [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more 143 general guidance on how to propagate ECN to and from protocols that 144 encapsulate IP. 146 Specific update text for those protocols in the above list that are 147 under IETF change control is given in Section 4. For those not under 148 IETF control, it is RECOMMENDED that implementations of encapsulation 149 and decapsulation comply with RFC 6040. It is also RECOMMENDED that 150 their specifications are updated to add a requirement to comply with 151 RFC 6040. 153 Although the definition of the various GTP shim headers is under the 154 control of the 3GPP, it is hard to determine whether the 3GPP or the 155 IETF controls standardization of the _process_ of adding both a GTP 156 and an IP header to an inner IP header. Nonetheless, the present 157 specification is provided so that the 3GPP can refer to it from any 158 of its own specifications of GTP and IP header processing. 160 PPTP is not under the change control of the IETF, but it has been 161 documented in an informational RFC [RFC2637]. However, there is no 162 need for this memo to update PPTP because L2TP has been developed as 163 a standardized replacement. 165 NVGRE is not under the change control of the IETF, but it has been 166 documented in an informational RFC [RFC7637]. NVGRE is a specific 167 use-case of GRE (it re-purposes the key field from the initial 168 specification of GRE [RFC1701] as a Virtual Subnet ID). Therefore 169 the text that updates GRE below is also intended to update NVGRE. 171 VXLAN is not under the change control of the IETF but it has been 172 documented in an informational RFC. It is RECOMMENDED that VXLAN 173 implementations comply with RFC 6040 when the VXLAN header is 174 inserted between (or removed from between) IP headers. And the 175 authors of any future update to these specifications are encouraged 176 to add a requirement to comply with RFC 6040. 178 4. Specific Updates to Protocols under IETF Change Control 180 4.1. L2TPv3 182 L2TPv3 [RFC3931] can be used as a shim header that encapsulates an 183 L2-specific sub-layer then an L2 header containing an inner IP header 184 (v4 or v6). Then this whole stack of headers can be encapsulated 185 optionally within an outer UDP header then an outer IP header (v4 or 186 v6). Even though this shim is rather fat, it still fits the 187 definition of a tightly coupled shim header, because all the headers 188 are added (or removed) together. 190 ECN propagation is defined here as an update to L2TPv3 itself, 191 because the ECN field in IP has end-to-end semantics with no operator 192 choice. In contrast, Diffserv handling was defined as an extension 193 to L2TP[RFC3308] because the operator of the tunnel determines 194 whether and how Diffserv is handled. This memo updates the 195 specification of L2TPv3 [RFC3931] as follows: 197 Append the following text to Section 4.5 of [RFC3931]: 199 "When the payload inside the L2 header and the outer PSN header 200 are both IP (v4 or v6), the ECN field MUST be propagated between 201 these IP headers according to the rules in Section 4 of RFC 6040 202 [RFC6040]. ECN propagation occurs both when the packet is 203 encapsulated and when it is decapsulated. 205 Before encapsulating any data packets, these rules require an LCCE 206 to check that the remote LCCE supports ECN propagation. If it 207 does, the normal mode of encapsulation can be used, otherwise the 208 compatibility mode is required [RFC6040]. An LCCE can determine 209 the remote LCCE's support for ECN either statically (by 210 configuration) or by dynamic discovery during setup of each 211 control connection between the LCCEs, using the ECN AVP defined 212 below. 214 Where the outer PSN header is some protocol other than IP that 215 supports ECN, the appropriate ECN propagation specification will 216 need to be followed, e.g Explicit Congestion Marking in MPLS 217 [RFC5129]. Where no specification exists for ECN propagation by 218 particular PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more 219 general guidance on how to propagate ECN to and from protocols 220 that encapsulate IP." 222 Append the following text to the list of Control Connection AVPs 223 (Attribute Value Pairs) in Section 5.4.3 of [RFC3931]: 225 "ECN Capability (SCCRQ, SCCRP) 227 The ECN Capability AVP, Attribute Type ZZ, declares that the 228 sender of the AVP supports propagation of ECN. An LCCE 229 initiating a control connection will send a Start-Control- 230 Connection-Request (SCCRQ) containing the ECN AVP. If the 231 tunnel terminator supports ECN, it will return a Start-Control- 232 Connection-Reply (SCCRP) that also includes the ECN AVP. Then 233 both ends of the tunnel can use the normal mode of RFC 6040 to 234 propagate the ECN field when encapsulating data packets for any 235 sessions created by that control connection. 237 If, on the other hand, the tunnel terminator does not support 238 ECN it will ignore the ECN AVP and send an SCCRP to the tunnel 239 initiator without the ECN AVP. The tunnel initiator interprets 240 the absence of the ECN AVP in the SCCRP as an indication that 241 the tunnel terminator is incapable of supporting ECN. When 242 encapsulating data packets for any sessions created by that 243 control connection, it will then use the compatibility mode of 244 RFC 6040 to clear the ECN field of the outer IP header. 246 If there is no ECN AVP in an arriving control connection 247 request (SCCRQ), a tunnel terminator MUST NOT include the ECN 248 APV in its reply (SCCRP). 250 The Attribute Value field for this AVP is a bit-mask with the 251 following format: 253 0 1 254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |X X X X X X X X X X X X X X X E| 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 This AVP MAY be present in the following message types: SCCRQ 260 and SCCRP. This AVP MAY be hidden (the H-bit set to 0 or 1) 261 and is optional (M-bit not set). The length (before hiding) of 262 this AVP MUST be 8 octets. The Vendor ID is the IETF Vendor ID 263 of 0. 265 When bit 15 of this attribute value field is set to 1, it 266 indicates that the sender supports ECN propagation. All the 267 other bits are reserved. They MUST be cleared to zero when 268 sent and ignored when received." 270 " 272 4.2. GRE 274 This memo updates the specification of GRE [RFC2784] by appending the 275 following text to Section 3: 277 "When the payload and delivery protocols are either both IP (v4 or 278 v6), the ECN field SHOULD be propagated between these IP headers 279 according to the rules in Section 4 of RFC 6040 [RFC6040]. ECN 280 propagation occurs both when the packet is encapsulated and when 281 it is decapsulated. In a case where the tunnel egress does not 282 support ECN propagation, RFC 6040 requires the encapsulator to use 283 compatibility mode. 285 Where the delivery protocol (outer header) is some protocol other 286 than IP that supports ECN, the appropriate ECN propagation 287 specification will need to be followed, e.g Explicit Congestion 288 Marking in MPLS [RFC5129]. Where no specification exists for ECN 289 propagation by particular PSN, 290 [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more general guidance 291 on how to propagate ECN to and from protocols that encapsulate 292 IP." 294 5. IANA Considerations 296 IANA is requested to assign the following L2TP Control Message 297 Attribute Value Pair: 299 +----------------+----------------+-----------+ 300 | Attribute Type | Description | Reference | 301 +----------------+----------------+-----------+ 302 | ZZ | ECN Capability | RFCXXXX | 303 +----------------+----------------+-----------+ 305 [TO BE REMOVED: This registration should take place at the following 306 location: https://www.iana.org/assignments/l2tp-parameters/l2tp- 307 parameters.xhtml ] 309 6. Security Considerations 311 The Security Considerations in [RFC6040] and 312 [I-D.ietf-tsvwg-ecn-encap-guidelines] apply equally to the scope 313 defined for the present specification. 315 7. Comments Solicited 317 Comments and questions are encouraged and very welcome. They can be 318 addressed to the IETF Transport Area working group mailing list 319 , and/or to the authors. 321 8. Acknowledgements 323 Thanks for Ing-jyh (Inton) Tsang for initial discussions on the need 324 for ECN propagation in L2TP and its applicability. 326 9. References 328 9.1. Normative References 330 [I-D.ietf-tsvwg-ecn-encap-guidelines] 331 Briscoe, B., Kaippallimalil, J., and P. Thaler, 332 "Guidelines for Adding Congestion Notification to 333 Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- 334 encap-guidelines-08 (work in progress), March 2017. 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, 338 DOI 10.17487/RFC2119, March 1997, 339 . 341 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 342 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 343 RFC 2661, DOI 10.17487/RFC2661, August 1999, 344 . 346 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 347 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 348 DOI 10.17487/RFC2784, March 2000, 349 . 351 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 352 of Explicit Congestion Notification (ECN) to IP", 353 RFC 3168, DOI 10.17487/RFC3168, September 2001, 354 . 356 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 357 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 358 RFC 3931, DOI 10.17487/RFC3931, March 2005, 359 . 361 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 362 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 363 2008, . 365 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 366 Notification", RFC 6040, DOI 10.17487/RFC6040, November 367 2010, . 369 9.2. Informative References 371 [GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp 372 interface", Technical Specification TS 29.060. 374 [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling 375 Protocol User Plane (GTPv1-U)", Technical Specification TS 376 29.281. 378 [GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) 379 Tunnelling Protocol for Control plane (GTPv2-C)", 380 Technical Specification TS 29.274. 382 [I-D.ietf-intarea-gue] 383 Herbert, T., Yong, L., and O. Zia, "Generic UDP 384 Encapsulation", draft-ietf-intarea-gue-04 (work in 385 progress), May 2017. 387 [I-D.ietf-nvo3-geneve] 388 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 389 Network Virtualization Encapsulation", draft-ietf- 390 nvo3-geneve-04 (work in progress), March 2017. 392 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 393 Routing Encapsulation (GRE)", RFC 1701, 394 DOI 10.17487/RFC1701, October 1994, 395 . 397 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 398 W., and G. Zorn, "Point-to-Point Tunneling Protocol 399 (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, 400 . 402 [RFC2983] Black, D., "Differentiated Services and Tunnels", 403 RFC 2983, DOI 10.17487/RFC2983, October 2000, 404 . 406 [RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer 407 Two Tunneling Protocol (L2TP) Differentiated Services 408 Extension", RFC 3308, DOI 10.17487/RFC3308, November 2002, 409 . 411 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 412 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 413 eXtensible Local Area Network (VXLAN): A Framework for 414 Overlaying Virtualized Layer 2 Networks over Layer 3 415 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 416 . 418 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 419 Virtualization Using Generic Routing Encapsulation", 420 RFC 7637, DOI 10.17487/RFC7637, September 2015, 421 . 423 Author's Address 425 Bob Briscoe 426 Simula Research Laboratory 427 UK 429 EMail: ietf@bobbriscoe.net 430 URI: http://bobbriscoe.net/