idnits 2.17.1 draft-ietf-tsvwg-rfc6040update-shim-03.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 RFC4380, but the abstract doesn't seem to mention this, which it should. -- 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 (June 27, 2017) is 2485 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 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-04 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-12 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 7 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, 4380 June 27, 2017 5 (if approved) 6 Intended status: Standards Track 7 Expires: December 29, 2017 9 Propagating Explicit Congestion Notification Across IP Tunnel Headers 10 Separated by a Shim 11 draft-ietf-tsvwg-rfc6040update-shim-03 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 updates RFC 6040 to clarify that its 18 scope includes tunnels where two IP headers are separated by at least 19 one shim header that is not sufficient on its own for wide area 20 packet forwarding. It surveys widely deployed IP tunnelling 21 protocols separated by such shim header(s) and updates the 22 specifications of those that do not mention ECN propagation (L2TPv2, 23 L2TPv3, GRE and Teredo). This specification also updates RFC 6040 24 with configuration requirements needed to make any legacy tunnel 25 ingress safe. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 29, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Feasibility of ECN Propagation between Tunnel Headers . . 4 65 3.2. Desirability of ECN Propagation between Tunnel Headers . 5 66 4. Making a non-ECN Tunnel Ingress Safe by Configuration . . . . 5 67 5. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 6 68 5.1. Specific Updates to Protocols under IETF Change Control . 8 69 5.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 8 70 5.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 12 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 8. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 13 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 10.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 RFC 6040 on "Tunnelling of Explicit Congestion Notification" 84 [RFC6040] made the rules for propagation of Explicit Congestion 85 Notification (ECN [RFC3168]) consistent for all forms of IP in IP 86 tunnel. 88 A common pattern for many tunnelling protocols is to encapsulate an 89 inner IP header (v4 or v6) with shim header(s) then an outer IP 90 header (v4 or v6). Some of these shim headers are designed as 91 generic encapsulations, so they do not necessarily directly 92 encapsulate an inner IP header. Instead they can encapsulate headers 93 such as link-layer (L2) protocols that in turn often encapsulate IP. 95 To clear up confusion, this specification clarifies that the scope of 96 RFC 6040 includes any IP-in-IP tunnel, including those with shim 97 header(s) and other encapsulations between the IP headers. Where 98 necessary, it updates the specifications of the relevant 99 encapsulation protocols with the specific text necessary to comply 100 with RFC 6040. 102 This specification also updates RFC 6040 to state how operators ought 103 to configure a legacy tunnel ingress to avoid unsafe system 104 configurations. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119] 111 when, and only when, they appear in all capitals, as shown here. 113 This specification uses the terminology defined in RFC 6040 114 [RFC6040]. 116 3. Scope of RFC 6040 118 In section 1.1 of RFC 6040, its scope is defined as: 120 "...ECN field processing at encapsulation and decapsulation for 121 any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It 122 applies irrespective of whether IPv4 or IPv6 is used for either 123 the inner or outer headers. ..." 125 This was intended to include cases where shim header(s) sit between 126 the IP headers. Many tunnelling implementers have interpreted the 127 scope of RFC 6040 as it was intended, but it is ambiguous. 128 Therefore, this specification updates RFC 6040 by adding the 129 following scoping text after the sentences quoted above: 131 It applies in cases where an outer IP header encapsulates an inner 132 IP header either directly or indirectly by encapsulating other 133 headers that in turn encapsulate (or might encapsulate) an inner 134 IP header. 136 There is another problem with the scope of RFC 6040. Like many IETF 137 specifications, RFC 6040 is written as a specification that 138 implementations can choose to claim compliance with. This means it 139 does not cover two important cases: 141 1. those cases where it is infeasible for an implementation to 142 access an inner IP header when adding or removing an outer IP 143 header; 145 2. those implementations that choose not to propagate ECN between IP 146 headers. 148 However, the ECN field is a non-optional part of the IP header (v4 149 and v6). So any implementation that creates an outer IP header has 150 to give the ECN field some value. There is only one safe value a 151 tunnel ingress can use if it does not know whether the egress 152 supports propagation of the ECN field; it has to zero the ECN field 153 in any outer IP header. 155 However, an RFC has no jurisdiction over implementations that choose 156 not to comply with it or cannot comply with it, including all those 157 implementations that pre-dated the RFC. Therefore it would have been 158 unreasonable to add such a requirement to RFC 6040. Nonetheless, to 159 ensure safe propagation of the ECN field over tunnels, it is 160 reasonable to add requirements on operators, to ensure they configure 161 their tunnels safely (where possible). Before stating these 162 configuration requirements in Section 4, the factors that determine 163 whether propagating ECN is feasible or desirable will be briefly 164 introduced. 166 3.1. Feasibility of ECN Propagation between Tunnel Headers 168 In many cases shim header(s) and an outer IP header are always added 169 to (or removed from) an inner IP packet as part of the same 170 procedure. We call this a tightly coupled shim header. Processing 171 the shim and outer together is often necessary because the shim(s) 172 are not sufficient for packet forwarding in their own right; not 173 unless complemented by an outer header. In these cases it will often 174 be feasible for an implementation to propagate the ECN field between 175 the IP headers. 177 In some cases a tunnel adds an outer IP header and a tightly coupled 178 shim header to an inner header that is not an IP header, but that in 179 turn encapsulates an IP header (or might encapsulate an IP header). 180 For instance an inner Ethernet (or other link layer) header might 181 encapsulate an inner IP header as its payload. We call this a 182 tightly coupled shim over an encapsulating header. 184 Digging to arbitrary depths to find an inner IP header within an 185 encapsulation is strictly a layering violation so it cannot be a 186 required behaviour. Nonetheless, some tunnel endpoints already look 187 within a L2 header for an IP header, for instance to map the Diffserv 188 codepoint between an encapsulated IP header and an outer IP header 189 [RFC2983]. In such cases at least, it should be feasible to also 190 (independently) propagate the ECN field between the same IP headers. 191 Thus, access to the ECN field within an encapsulating header can be a 192 useful and benign optimization. The guidelines in section 6 of 194 [I-D.ietf-tsvwg-ecn-encap-guidelines] give the conditions for this 195 layering violation to be benign. 197 3.2. Desirability of ECN Propagation between Tunnel Headers 199 Developers and network operators are encouraged to implement and 200 deploy tunnel endpoints compliant with RFC 6040 (as updated by the 201 present specification) in order to provide the benefits of wider ECN 202 deployment [RFC8087]. Nonetheless, propagation of ECN between IP 203 headers, whether separated by shim headers or not, has to be optional 204 to implement and to use, because: 206 o Legacy implementations of tunnels without any ECN support already 207 exist 209 o A network might be designed so that there is usually no bottleneck 210 within the tunnel 212 o If the tunnel endpoints would have to search within an L2 header 213 to find an encapsulated IP header, it might not be worth the 214 potential performance hit 216 4. Making a non-ECN Tunnel Ingress Safe by Configuration 218 Even when ECN propagation is not implemented or is not being used, it 219 ought to be possible to render a tunnel ingress safe by 220 configuration. The main safety concern is to disable the ECN 221 capability in the outer IP header if the egress of the tunnel does 222 not implement ECN logic to propagate any ECN markings into the packet 223 forwarded beyond the tunnel. Otherwise the non-ECN egress could 224 discard any ECN marking introduced within the tunnel, which would 225 break all the ECN-based control loops that regulate the traffic load 226 over the tunnel. 228 Therefore this specification updates RFC 6040 by inserting the 229 following text just before the last paragraph of section 4.3: 231 When the implementation of a tunnel ingress does not support 232 [RFC6040] or one of its compatible predecessors ([RFC4301] or the 233 full functionality mode of [RFC3168]) and when the outer tunnel 234 header is IP (v4 or v6), if possible, the operator MUST configure 235 the ingress to zero the outer ECN field in any of the following 236 cases: 238 * if it is known that the tunnel egress does not support 239 propagation of the ECN field (RFC 6040, RFC 4301 or the full 240 functionality mode of RFC 3168) 242 * or if the behaviour of the egress is not known or an egress 243 with unknown behaviour might be dynamically paired with the 244 ingress. 246 * or if an IP header might be encapsulated within a non-IP header 247 that the tunnel ingress is encapsulating, but the ingress does 248 not inspect within the encapsulation. 250 In order that the network operator can comply with the above safety 251 rules, even if a tunnel ingress does not support RFC 6040, RFC 4301 252 or the full functionality mode of RFC 3168, the implementation of the 253 tunnel ingress: 255 o MUST make propagation of the ECN field between inner and outer IP 256 headers independent of any configuration of Diffserv codepoint 257 propagation; 259 o SHOULD zero the outer ECN field in its default configuration. 261 There might be concern that the above "MUST" makes compliant 262 equipment non-compliant at a stroke. However, any equipment that is 263 still treating the ToS octet (IPv4) or the Traffic Class octet (IPv6) 264 as a single 8-bit field is already non-compliant, and has been since 265 1998 when the upper 6 bits were separated off for the Diffserv 266 codepoint (DSCP) [RFC2474]. For instance, copying the ECN field as a 267 side-effect of copying the DSCP is a seriously unsafe bug that risks 268 breaking the feedback loops that regulate load on a tunnel. 270 Permanently zeroing the outer ECN field is safe, but it is not 271 sufficient to claim compliance with RFC 6040 because it does not meet 272 the aim of introducing ECN support to tunnels (see Section 4.3 of 273 [RFC6040]). 275 5. IP-in-IP Tunnels with Tightly Coupled Shim Headers 277 There follows a list of specifications of encapsulations with tightly 278 coupled shim header(s), in rough chronological order. The list is 279 confined to standards track or widely deployed protocols. The list 280 is not necessarily exhaustive so, for the avoidance of doubt, the 281 scope of RFC 6040 is defined in Section 3 and is not limited to this 282 list. 284 o PPTP (Point-to-Point Tunneling Protocol) [RFC2637]; 286 o L2TP (Layer 2 Tunnelling Protocol), specifically L2TPv2 [RFC2661] 287 and L2TPv3 [RFC3931], which not only includes all the L2-specific 288 specializations of L2TP, but also derivatives such as the Keyed 289 IPv6 Tunnel [RFC8159]; 291 o GRE (Generic Routing Encapsulation) [RFC2784] and NVGRE (Network 292 Virtualization using GRE) [RFC7637]; 294 o GTP (GPRS Tunnelling Protocol), specifically GTPv1 [GTPv1], GTP v1 295 User Plane [GTPv1-U], GTP v2 Control Plane [GTPv2-C]; 297 o Teredo [RFC4380]; 299 o CAPWAP (Control And Provisioning of Wireless Access Points) 300 [RFC5415]; 302 o LISP (Locator/Identifier Separation Protocol) [RFC6830]; 304 o VXLAN (Virtual eXtensible Local Area Network) [RFC7348] and VXLAN- 305 GPE [I-D.ietf-nvo3-vxlan-gpe]; 307 o NSH (Network Service Header) [I-D.ietf-sfc-nsh]; 309 o Geneve [I-D.ietf-nvo3-geneve]; 311 o GUE (Generic UDP Encapsulation) [I-D.ietf-intarea-gue]. 313 Some of the listed protocols enable encapsulation of a variety of 314 network layer protocols as inner and/or outer. This specification 315 applies in the cases where there is an inner and outer IP header as 316 described in Section 3. Otherwise 317 [I-D.ietf-tsvwg-ecn-encap-guidelines] gives guidance on how to design 318 propagation of ECN into other protocols that might encapsulate IP. 320 Where protocols in the above list need to be updated to specify ECN 321 propagation and they are under IETF change control, update text is 322 given in the following subsections. For those not under IETF 323 control, it is RECOMMENDED that implementations of encapsulation and 324 decapsulation comply with RFC 6040. It is also RECOMMENDED that 325 their specifications are updated to add a requirement to comply with 326 RFC 6040 (as updated by the present document). 328 PPTP is not under the change control of the IETF, but it has been 329 documented in an informational RFC [RFC2637]. However, there is no 330 need for the present specification to update PPTP because L2TP has 331 been developed as a standardized replacement. 333 NVGRE is not under the change control of the IETF, but it has been 334 documented in an informational RFC [RFC7637]. NVGRE is a specific 335 use-case of GRE (it re-purposes the key field from the initial 336 specification of GRE [RFC1701] as a Virtual Subnet ID). Therefore 337 the text that updates GRE in Section 5.1.2 below is also intended to 338 update NVGRE. 340 Although the definition of the various GTP shim headers is under the 341 control of the 3GPP, it is hard to determine whether the 3GPP or the 342 IETF controls standardization of the _process_ of adding both a GTP 343 and an IP header to an inner IP header. Nonetheless, the present 344 specification is provided so that the 3GPP can refer to it from any 345 of its own specifications of GTP and IP header processing. 347 The specification of CAPWAP already specifies RFC 3168 ECN 348 propagation and ECN capability negotiation. Without modification the 349 CAPWAP specification already interworks with the backward compatible 350 updates to RFC 3168 in RFC 6040. 352 LISP made the ECN propagation procedures in RFC 3168 mandatory from 353 the start. RFC 3168 has since been updated by RFC 6040, but the 354 changes are backwards compatible so there is still no need for LISP 355 tunnel endpoints to negotiate their ECN capabilities. 357 VXLAN is not under the change control of the IETF but it has been 358 documented in an informational RFC. In contrast, VXLAN-GPE (Generic 359 Protocol Extension) is being documented under IETF change control. 360 It is RECOMMENDED that VXLAN and VXLAN-GPE implementations comply 361 with RFC 6040 when the VXLAN header is inserted between (or removed 362 from between) IP headers. The authors of any future update to these 363 specifications are encouraged to add a requirement to comply with RFC 364 6040 as updated by the present specification. 366 The specification of NSH does not currently include the process of 367 encapsulation. It is assumed that ECN propagation will be included 368 in whatever encapsulation an NSH implementation uses. 370 The specifications of Geneve and GUE already refer to RFC 6040 for 371 ECN encapsulation. 373 5.1. Specific Updates to Protocols under IETF Change Control 375 5.1.1. L2TP (v2 and v3) ECN Extension 377 The L2TP terminology used here is defined in [RFC2661] and [RFC3931]. 379 L2TPv3 [RFC3931] is used as a shim header between any packet-switched 380 network (PSN) header (e.g. IPv4, IPv6, MPLS) and many types of layer 381 2 (L2) header. The L2TPv3 shim header encapsulates an L2-specific 382 sub-layer then an L2 header that is likely to contain an inner IP 383 header (v4 or v6). Then this whole stack of headers can be 384 encapsulated optionally within an outer UDP header then an outer PSN 385 header that is typically IP (v4 or v6). 387 L2TPv2 is used as a shim header between any PSN header and a PPP 388 header, which is in turn likely to encapsulate an IP header. 390 Even though these shims are rather fat (particularly in the case of 391 L2TPv3), they still fit the definition of a tightly coupled shim 392 header over an encapsulating header (Section 3.1), because all the 393 headers encapsulating the L2 header are added (or removed) together. 394 L2TPv2 and L2TPv3 are therefore within the scope of RFC 6040, as 395 updated by Section 3 above. 397 L2TP maintainers are RECOMMENDED to implement the ECN extension to 398 L2TPv2 and L2TPv3 defined in Section 5.1.1.2 below, in order to 399 provide the benefits of ECN [RFC8087], whenever a node within an L2TP 400 tunnel becomes the bottleneck for an end-to-end traffic flow. 402 5.1.1.1. Safe Configuration of a 'Non-ECN' Ingress LCCE 404 The following text is appended to both Section 5.3 of [RFC2661] and 405 Section 4.5 of [RFC3931] as an update to the base L2TPv2 and L2TPv3 406 specifications: 408 An LCCE that does not support the ECN Extension in Section 5.1.1.2 409 of RFCXXXX MUST follow the configuration requirements in Section 4 410 of RFCXXXX for when the outer PSN header is IP (v4 or v6). 411 {RFCXXXX refers to the present document so it will need to be 412 inserted by the RFC Editor} 414 In particular, for an LCCE implementation that does not support the 415 ECN Extension, this means that configuration of how it propagates the 416 ECN field between inner and outer IP headers MUST be independent of 417 any configuration of the Diffserv extension of L2TP [RFC3308]. 419 5.1.1.2. ECN Extension for L2TP (v2 or v3) 421 When the outer PSN header and the payload inside the L2 header are 422 both IP (v4 or v6), to comply with RFC 6040, an LCCE will follow the 423 rules for propagation of the ECN field at ingress and egress in 424 Section 4 of RFC 6040 [RFC6040]. 426 Before encapsulating any data packets, RFC 6040 requires an ingress 427 LCCE to check that the egress LCCE supports ECN propagation. If the 428 egress supports ECN, the ingress LCCE can use the normal mode of 429 encapsulation. Otherwise, the ingress LCCE has to use compatibility 430 mode [RFC6040]. An LCCE can determine the remote LCCE's support for 431 ECN either statically (by configuration) or by dynamic discovery 432 during setup of each control connection between the LCCEs, using the 433 Capability AVP defined in Section 5.1.1.2.1 below. 435 Where the outer PSN header is some protocol other than IP that 436 supports ECN, the appropriate ECN propagation specification will need 437 to be followed, e.g. "Explicit Congestion Marking in MPLS" 438 [RFC5129]. Where no specification exists for ECN propagation by a 439 particular PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives general 440 guidance on how to design ECN propagation into a protocol that 441 encapsulates IP. 443 5.1.1.2.1. LCCE Capability AVP for ECN Capability Negotiation 445 The LCCE Capability Attribute Value Pair (AVP) defined here has 446 Attribute Type ZZ. The Attribute Value field for this AVP is a bit- 447 mask with the following 16-bit format: 449 0 1 450 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |X X X X X X X X X X X X X X X E| 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 This AVP MAY be present in the following message types: SCCRQ and 456 SCCRP (Start-Control-Connection-Request and Start-Control-Connection- 457 Reply). This AVP MAY be hidden (the H-bit set to 0 or 1) and is 458 optional (M-bit not set). The length (before hiding) of this AVP 459 MUST be 8 octets. The Vendor ID is the IETF Vendor ID of 0. 461 Bit 15 of the Value field of the LCCE Capability AVP is defined as 462 the ECN Capability flag (E). When the ECN Capability flag is set to 463 1, it indicates that the sender supports ECN propagation. When the 464 ECN Capability flag is cleared to zero, or when no LCCE Capabiliy AVP 465 is present, it indicates that the sender does not support ECN 466 propagation. All the other bits are reserved. They MUST be cleared 467 to zero when sent and ignored when received or forwarded. 469 An LCCE initiating a control connection will send a Start-Control- 470 Connection-Request (SCCRQ) containing an LCCE Capability AVP with the 471 ECN Capability flag set to 1. If the tunnel terminator supports ECN, 472 it will return a Start-Control-Connection-Reply (SCCRP) that also 473 includes an LCCE Capability AVP with the ECN Capability flag set to 474 1. Then, for any sessions created by that control connection, both 475 ends of the tunnel can use the normal mode of RFC 6040 to propagate 476 the ECN field when encapsulating data packets. 478 If, on the other hand, the tunnel terminator does not support ECN it 479 will ignore the ECN flag in the LCCE Capability AVP and send an SCCRP 480 to the tunnel initiator without a Capability AVP (or with a 481 Capability AVP but with the ECN Capability flag cleared to zero). 482 The tunnel initiator interprets the absence of the ECN Capability 483 flag in the SCCRP as an indication that the tunnel terminator is 484 incapable of supporting ECN. When encapsulating data packets for any 485 sessions created by that control connection, the tunnel initiator 486 will then use the compatibility mode of RFC 6040 to clear the ECN 487 field of the outer IP header to 0b00. 489 If the tunnel terminator does not support this ECN extension, the 490 network operator is still expected to configure it to comply with the 491 safety provisions set out in Section 5.1.1.1 above, when it acts as 492 an ingress LCCE. 494 5.1.2. GRE 496 The GRE terminology used here is defined in [RFC2784]. GRE is often 497 used as a tightly coupled shim header between IP headers. Sometimes 498 the GRE shim header encapsulates an L2 header, which might in turn 499 encapsulate an IP header. Therefore GRE is within the scope of RFC 500 6040 as updated by Section 3 above. 502 GRE tunnel endpoint maintainers are RECOMMENDED to support [RFC6040] 503 as updated by the present specification, in order to provide the 504 benefits of ECN [RFC8087] whenever a node within a GRE tunnel becomes 505 the bottleneck for an end-to-end IP traffic flow tunnelled over GRE 506 using IP as the delivery protocol (outer header). 508 GRE tunnels do not support dynamic configuration based on capability 509 negotiation, so the ECN capability has to be manually configured. 510 For a GRE ingress implementation that supports ECN propagation, 511 manual configuration requirements are specified in Section 4.3 of RFC 512 6040. Otherwise they are specified in Section 5.1.2.1 below. 514 Where the delivery protocol is some protocol other than IP that 515 supports ECN, the appropriate ECN propagation specification will need 516 to be followed, e.g Explicit Congestion Marking in MPLS [RFC5129]. 517 Where no specification exists for ECN propagation by a particular 518 PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more general 519 guidance on how to propagate ECN to and from protocols that 520 encapsulate IP. 522 5.1.2.1. Safe Configuration of a 'Non-ECN' GRE Ingress 524 The following text is appended to Section 3 of [RFC2784] as an update 525 to the base GRE specification: 527 A GRE tunnel ingress that does not support RFC 6040 or one of its 528 compatible predecessors (RFC 4301 or the full functionality mode 529 of RFC 3168) MUST follow the configuration requirements in 530 Section 4 of RFCXXXX for when the outer delivery protocol is IP 531 (v4 or v6). {RFCXXXX refers to the present document so it will 532 need to be inserted by the RFC Editor} 534 5.1.3. Teredo 536 Teredo [RFC4380] provides a way to tunnel IPv6 over an IPv4 network, 537 with a UDP-based shim header between the two. 539 For Teredo tunnel endpoints to provide the benefits of ECN, the 540 Teredo specification would have to be updated to include negotiation 541 of the ECN capability between Teredo tunnel endpoints. Otherwise it 542 would be unsafe for a Teredo tunnel ingress to copy the ECN field to 543 the IPv6 outer. 545 It is believed that current implementations do not support 546 propagation of ECN, but that they do safely zero the ECN field in the 547 outer IPv6 header. However the specification does not mention 548 anything about this. To make existing Teredo deployments safe it 549 will not be feasible to require them to be configured correctly, 550 because Teredo tunnel endpoints are generally deployed on hosts. 551 Therefore, the only feasible safety precaution available here is to 552 update the specification of Teredo implementations until ECN support 553 is added. The following text updates the Teredo specification 554 [RFC4380], as a new section 5.1.3: 556 "5.1.3 Safe 'Non-ECN' Teredo Encapsulation 558 A Teredo tunnel ingress implementation that does not support ECN 559 propagation as defined in RFC 6040 or one of its compatible 560 predecessors (RFC 4301 or the full functionality mode of RFC 3168) 561 MUST zero the ECN field in the outer IPv6 header." 563 6. IANA Considerations 565 IANA is requested to assign the following L2TP Control Message 566 Attribute Value Pair: 568 +----------------+----------------+-----------+ 569 | Attribute Type | Description | Reference | 570 +----------------+----------------+-----------+ 571 | ZZ | ECN Capability | RFCXXXX | 572 +----------------+----------------+-----------+ 574 [TO BE REMOVED: This registration should take place at the following 575 location: https://www.iana.org/assignments/l2tp-parameters/l2tp- 576 parameters.xhtml ] 578 7. Security Considerations 580 The Security Considerations in [RFC6040] and 581 [I-D.ietf-tsvwg-ecn-encap-guidelines] apply equally to the scope 582 defined for the present specification. 584 8. Comments Solicited 586 Comments and questions are encouraged and very welcome. They can be 587 addressed to the IETF Transport Area working group mailing list 588 , and/or to the authors. 590 9. Acknowledgements 592 Thanks to Ing-jyh (Inton) Tsang for initial discussions on the need 593 for ECN propagation in L2TP and its applicability. Thanks also to 594 Carlos Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen 595 Balasubramanian and Joe Touch for helpful advice and comments. 597 10. References 599 10.1. Normative References 601 [I-D.ietf-tsvwg-ecn-encap-guidelines] 602 Briscoe, B., Kaippallimalil, J., and P. Thaler, 603 "Guidelines for Adding Congestion Notification to 604 Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- 605 encap-guidelines-08 (work in progress), March 2017. 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, 609 DOI 10.17487/RFC2119, March 1997, 610 . 612 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 613 "Definition of the Differentiated Services Field (DS 614 Field) in the IPv4 and IPv6 Headers", RFC 2474, 615 DOI 10.17487/RFC2474, December 1998, 616 . 618 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 619 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 620 RFC 2661, DOI 10.17487/RFC2661, August 1999, 621 . 623 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 624 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 625 DOI 10.17487/RFC2784, March 2000, 626 . 628 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 629 of Explicit Congestion Notification (ECN) to IP", 630 RFC 3168, DOI 10.17487/RFC3168, September 2001, 631 . 633 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 634 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 635 RFC 3931, DOI 10.17487/RFC3931, March 2005, 636 . 638 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 639 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 640 December 2005, . 642 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 643 Network Address Translations (NATs)", RFC 4380, 644 DOI 10.17487/RFC4380, February 2006, 645 . 647 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 648 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 649 2008, . 651 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 652 Notification", RFC 6040, DOI 10.17487/RFC6040, November 653 2010, . 655 10.2. Informative References 657 [GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp 658 interface", Technical Specification TS 29.060. 660 [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling 661 Protocol User Plane (GTPv1-U)", Technical Specification TS 662 29.281. 664 [GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) 665 Tunnelling Protocol for Control plane (GTPv2-C)", 666 Technical Specification TS 29.274. 668 [I-D.ietf-intarea-gue] 669 Herbert, T., Yong, L., and O. Zia, "Generic UDP 670 Encapsulation", draft-ietf-intarea-gue-04 (work in 671 progress), May 2017. 673 [I-D.ietf-nvo3-geneve] 674 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 675 Network Virtualization Encapsulation", draft-ietf- 676 nvo3-geneve-04 (work in progress), March 2017. 678 [I-D.ietf-nvo3-vxlan-gpe] 679 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 680 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work 681 in progress), April 2017. 683 [I-D.ietf-sfc-nsh] 684 Quinn, P. and U. Elzur, "Network Service Header", draft- 685 ietf-sfc-nsh-12 (work in progress), February 2017. 687 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 688 Routing Encapsulation (GRE)", RFC 1701, 689 DOI 10.17487/RFC1701, October 1994, 690 . 692 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 693 W., and G. Zorn, "Point-to-Point Tunneling Protocol 694 (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, 695 . 697 [RFC2983] Black, D., "Differentiated Services and Tunnels", 698 RFC 2983, DOI 10.17487/RFC2983, October 2000, 699 . 701 [RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer 702 Two Tunneling Protocol (L2TP) Differentiated Services 703 Extension", RFC 3308, DOI 10.17487/RFC3308, November 2002, 704 . 706 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 707 Ed., "Control And Provisioning of Wireless Access Points 708 (CAPWAP) Protocol Specification", RFC 5415, 709 DOI 10.17487/RFC5415, March 2009, 710 . 712 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 713 Locator/ID Separation Protocol (LISP)", RFC 6830, 714 DOI 10.17487/RFC6830, January 2013, 715 . 717 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 718 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 719 eXtensible Local Area Network (VXLAN): A Framework for 720 Overlaying Virtualized Layer 2 Networks over Layer 3 721 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 722 . 724 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 725 Virtualization Using Generic Routing Encapsulation", 726 RFC 7637, DOI 10.17487/RFC7637, September 2015, 727 . 729 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 730 Explicit Congestion Notification (ECN)", RFC 8087, 731 DOI 10.17487/RFC8087, March 2017, 732 . 734 [RFC8159] Konstantynowicz, M., Ed., Heron, G., Ed., Schatzmayr, R., 735 and W. Henderickx, "Keyed IPv6 Tunnel", RFC 8159, 736 DOI 10.17487/RFC8159, May 2017, 737 . 739 Author's Address 741 Bob Briscoe 742 Simula Research Laboratory 743 UK 745 EMail: ietf@bobbriscoe.net 746 URI: http://bobbriscoe.net/