idnits 2.17.1 draft-ietf-tsvwg-rfc6040update-shim-02.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 16, 2017) is 2503 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 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 5 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 16, 2017 5 (if approved) 6 Intended status: Standards Track 7 Expires: December 18, 2017 9 Propagating Explicit Congestion Notification Across IP Tunnel Headers 10 Separated by a Shim 11 draft-ietf-tsvwg-rfc6040update-shim-02 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. It 20 surveys widely deployed IP tunnelling protocols separated by a shim 21 and updates the specifications of those that do not mention ECN 22 propagation (L2TPv2, L2TPv3, GRE and Teredo). The specification also 23 updates RFC 6040 with configuration requirements needed to make any 24 legacy tunnel ingress safe. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 18, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 3 63 3.1. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . 3 64 3.2. Making a non-ECN Tunnel Ingress Safe by Configuration . . 4 65 3.3. Specific Updates to Protocols under IETF Change Control . 6 66 3.3.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 8 67 3.3.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.3.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 11 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 6. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 11 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 8.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 RFC 6040 on "Tunnelling of Explicit Congestion Notification" 81 [RFC6040] made the rules for propagation of Explicit Congestion 82 Notification (ECN [RFC3168]) consistent for all forms of IP in IP 83 tunnel. 85 A common pattern for many tunnelling protocols is to encapsulate an 86 inner IP header (v4 or v6) with shim header(s) then an outer IP 87 header (v4 or v6). Some of these shim headers are designed as 88 generic encapsulations, so they do not necessarily directly 89 encapsulate an inner IP header. Instead they can encapsulate headers 90 such as link-layer (L2) protocols that in turn often encapsulate IP. 92 To clear up confusion, this specification clarifies that the scope of 93 RFC 6040 includes any IP-in-IP tunnel, including those with shim 94 header(s) and other encapsulations between the IP headers. Where 95 necessary, it updates the specifications of the relevant 96 encapsulation protocols with the specific text necessary to comply 97 with RFC 6040. 99 This specification also updates RFC 6040 to state how operators ought 100 to configure a legacy tunnel ingress to avoid unsafe system 101 configurations. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119] 108 when, and only when, they appear in all capitals, as shown here. 110 This specification uses the terminology defined in RFC 6040 111 [RFC6040]. 113 3. IP-in-IP Tunnels with Tightly Coupled Shim Headers 115 3.1. Scope of RFC 6040 117 In many cases the shim header(s) and the outer IP header are always 118 added (or removed) as part of the same process. We call this a 119 tightly coupled shim header. Processing the shim and outer together 120 is often necessary because the shim(s) are not sufficient for packet 121 forwarding in their own right; not unless complemented by an outer 122 header. 124 In some cases a tunnel adds an outer IP header and a tightly coupled 125 shim header to an inner header that is not an IP header, but that in 126 turn encapsulates an IP header (or might encapsulate an IP header). 127 For instance an inner Ethernet (or other link layer) header might 128 encapsulate an inner IP header as its payload. We call this a 129 tightly coupled shim over an encapsulating header. 131 In section 1.1 of RFC 6040 its scope was defined as: 133 "...ECN field processing at encapsulation and decapsulation for 134 any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It 135 applies irrespective of whether IPv4 or IPv6 is used for either 136 the inner or outer headers. ..." 138 This specification updates RFC 6040 by adding the following scoping 139 text after the sentences quoted above: 141 It applies in cases where an outer IP header encapsulates an inner 142 IP header either directly or indirectly by encapsulating other 143 headers that in turn encapsulate (or might encapsulate) an inner 144 IP header. 146 Digging to arbitrary depths to find an inner IP header within an 147 encapsulation is strictly a layering violation so it cannot be a 148 required behaviour. Nonetheless, some tunnel endpoints already look 149 within a L2 header for an IP header, for instance to map the Diffserv 150 codepoint between an encapsulated IP header and an outer IP header 151 [RFC2983]. In such cases at least, it should be feasible to also 152 (independently) propagate the ECN field between the same IP headers. 153 Thus, as long as the guidelines in section 6 of 154 [I-D.ietf-tsvwg-ecn-encap-guidelines] are followed, access to the ECN 155 field within an encapsulating header can be a useful and benign 156 optimization. On the other hand, if a tunnel ingress is not willing 157 to find an inner IP header, Section 3.2 below specifies that it has 158 to disable the ECN capability in the outer header by zeroing the ECN 159 field. 161 3.2. Making a non-ECN Tunnel Ingress Safe by Configuration 163 Even when ECN propagation is not implemented or is not being used, it 164 ought to be possible to render a tunnel ingress safe by 165 configuration. The main safety concern is to disable the ECN 166 capability in the outer IP header if the egress of the tunnel does 167 not implement ECN logic to propagate any ECN markings into the packet 168 forwarded beyond the tunnel. Otherwise the non-ECN egress could 169 discard any ECN marking introduced within the tunnel, which would 170 break all the ECN-based control loops that regulate the traffic load 171 over the tunnel. 173 Therefore this specification updates RFC 6040 by inserting the 174 following text just before the last paragraph of section 4.3: 176 When the implementation of a tunnel ingress does not support 177 [RFC6040] or one of its compatible predecessors ([RFC4301] or the 178 full functionality mode of [RFC3168]) and when the outer tunnel 179 header is IP (v4 or v6), if possible, the operator MUST configure 180 the ingress to zero the outer ECN field in any of the following 181 cases: 183 * if it is known that the tunnel egress does not support 184 propagation of the ECN field (RFC 6040, RFC 4301 or the full 185 functionality mode of RFC 3168) 187 * or if the behaviour of the egress is not known or an egress 188 with unknown behaviour might be dynamically paired with the 189 ingress. 191 * or if an IP header might be encapsulated within a non-IP header 192 that the tunnel ingress is encapsulating, but the ingress does 193 not inspect within the encapsulation. 195 In order that the network operator can comply with the above safety 196 rules, even if a tunnel ingress does not support RFC 6040, RFC 4301 197 or the full functionality mode of RFC 3168, the implementation of the 198 tunnel ingress: 200 o MUST make propagation of the ECN field between inner and outer IP 201 headers independent of any configuration of Diffserv codepoint 202 propagation; 204 o SHOULD zero the outer ECN field in its default configuration. 206 There might be concern that the above "MUST" makes compliant 207 equipment non-compliant at a stroke. However, any equipment that is 208 still treating the ToS octet (IPv4) or the Traffic Class octet (IPv6) 209 as a single 8-bit field is already non-compliant, and has been since 210 1998 when the upper 6 bits were separated off for the Diffserv 211 codepoint (DSCP) [RFC2474]. For instance, copying the ECN field as a 212 side-effect of copying the DSCP is a seriously unsafe bug that risks 213 breaking the feedback loops that regulate load on a tunnel. 215 Permanently zeroing the outer ECN field is safe, but it is not 216 sufficient to claim compliance with RFC 6040 because it does not meet 217 the aim of introducing ECN support to tunnels (see Section 4.3 of 218 [RFC6040]). Developers and network operators are encouraged to 219 implement and deploy tunnel endpoints compliant with RFC 6040 (as 220 updated by the present specification) in order to provide the 221 benefits of wider ECN deployment [RFC8087]. Nonetheless, propagation 222 of ECN between IP headers, whether separated by shim headers or not, 223 has to be OPTIONAL to implement and to use, because: 225 o Legacy implementations of tunnels without any ECN support already 226 exist 228 o A network might be designed so that there is usually no bottleneck 229 within the tunnel 231 o If the tunnel endpoints would have to search within an L2 header 232 to find an encapsulated IP header, it might not be worth the 233 potential performance hit 235 3.3. Specific Updates to Protocols under IETF Change Control 237 There follows a list of specifications of encapsulations with tightly 238 coupled shim header(s). The list is not necessarily exhaustive so, 239 for the avoidance of doubt, RFC 6040 applies to all tightly coupled 240 shim headers whether or not they are listed here and whether or not 241 the shim encapsulates an IP header or a different header that 242 encapsulates (or might encapsulate) an IP header. The list is 243 confined to standards track or widely deployed protocols. 245 o PPTP (Point-to-Point Tunneling Protocol) [RFC2637]; 247 o L2TP (Layer 2 Tunnelling Protocol), specifically L2TPv2 [RFC2661] 248 and L2TPv3 [RFC3931], which not only includes all the L2-specific 249 specializations of L2TP, but also derivatives such as the Keyed 250 IPv6 Tunnel [RFC8159]; 252 o GRE (Generic Routing Encapsulation) [RFC2784] and NVGRE (Network 253 Virtualization using GRE) [RFC7637]; 255 o GTP (GPRS Tunnelling Protocol), specifically GTPv1 [GTPv1], GTP v1 256 User Plane [GTPv1-U], GTP v2 Control Plane [GTPv2-C]; 258 o Teredo [RFC4380]; 260 o CAPWAP (Control And Provisioning of Wireless Access Points) 261 [RFC5415]; 263 o LISP (Locator/Identifier Separation Protocol) [RFC6830]; 265 o VXLAN (Virtual eXtensible Local Area Network) [RFC7348] and VXLAN- 266 GPE [I-D.ietf-nvo3-vxlan-gpe]; 268 o Geneve [I-D.ietf-nvo3-geneve]; 270 o GUE (Generic UDP Encapsulation) [I-D.ietf-intarea-gue]. 272 Some of the listed protocols enable encapsulation of a variety of 273 network layer protocols as inner and/or outer. This specification 274 applies in the cases where there is an inner and outer IP header as 275 described in Section 3.1. Otherwise 276 [I-D.ietf-tsvwg-ecn-encap-guidelines] gives guidance on how to design 277 propagation of ECN into other protocols that might encapsulate IP. 279 Where protocols in the above list are under IETF change control and 280 they need to be updated to specify ECN propagation, update text is 281 given in the following subsections. For those not under IETF 282 control, it is RECOMMENDED that implementations of encapsulation and 283 decapsulation comply with RFC 6040. It is also RECOMMENDED that 284 their specifications are updated to add a requirement to comply with 285 RFC 6040 (as updated by the present document). 287 PPTP is not under the change control of the IETF, but it has been 288 documented in an informational RFC [RFC2637]. However, there is no 289 need for the present specification to update PPTP because L2TP has 290 been developed as a standardized replacement. 292 NVGRE is not under the change control of the IETF, but it has been 293 documented in an informational RFC [RFC7637]. NVGRE is a specific 294 use-case of GRE (it re-purposes the key field from the initial 295 specification of GRE [RFC1701] as a Virtual Subnet ID). Therefore 296 the text that updates GRE in Section 3.3.2 below is also intended to 297 update NVGRE. 299 Although the definition of the various GTP shim headers is under the 300 control of the 3GPP, it is hard to determine whether the 3GPP or the 301 IETF controls standardization of the _process_ of adding both a GTP 302 and an IP header to an inner IP header. Nonetheless, the present 303 specification is provided so that the 3GPP can refer to it from any 304 of its own specifications of GTP and IP header processing. 306 The specification of CAPWAP already specifies RFC 3168 ECN 307 propagation and ECN capability negotiation. Without modification the 308 CAPWAP specification already interworks with the backward compatible 309 updates to RFC 3168 in RFC 6040. 311 LISP made the ECN propagation procedures in RFC 3168 mandatory from 312 the start. RFC 3168 has since been updated by RFC 6040, but the 313 changes are backwards compatible so there is still no need for LISP 314 tunnel endpoints to negotiate their ECN capabilities. 316 VXLAN is not under the change control of the IETF but it has been 317 documented in an informational RFC. It is RECOMMENDED that VXLAN 318 implementations comply with RFC 6040 when the VXLAN header is 319 inserted between (or removed from between) IP headers. And the 320 authors of any future update to these specifications are encouraged 321 to add a requirement to comply with RFC 6040 as updated by the 322 present specification. 324 VXLAN-GPE (Generic Protocol Extension) is on the IETF standards 325 track. It is expected that it will specify ECN propagation before it 326 is published as an RFC. {ToDo: Update this text once the VXLAN-GPE 327 text has been updated.} 329 The specifications of Geneve and GUE already refer to RFC 6040 for 330 ECN encapsulation. 332 3.3.1. L2TP (v2 and v3) ECN Extension 334 The L2TP terminology used here is defined in [RFC2661] and [RFC3931]. 336 L2TPv3 [RFC3931] is used as a shim header between any packet-switched 337 network (PSN) header (e.g. IPv4, IPv6, MPLS) and many types of layer 338 2 (L2) header. The L2TPv3 shim header encapsulates an L2-specific 339 sub-layer then an L2 header that is likely to contain an inner IP 340 header (v4 or v6). Then this whole stack of headers can be 341 encapsulated optionally within an outer UDP header then an outer PSN 342 header that is typically IP (v4 or v6). 344 L2TPv2 is used as a shim header between any PSN header and a PPP 345 header, which is in turn likely to encapsulate an IP header. 347 Even though these shims are rather fat (particularly in the case of 348 L2TPv3), they still fit the definition of a tightly coupled shim 349 header over an encapsulating header (Section 3.1), because all the 350 headers encapsulating the L2 header are added (or removed) together. 351 L2TPv2 and L2TPv3 are therefore within the scope of RFC 6040, as 352 updated by Section 3.1 above. 354 L2TP maintainers are RECOMMENDED to implement the ECN extension to 355 L2TPv2 and L2TPv3 defined in Section 3.3.1.2 below, in order to 356 provide the benefits of ECN [RFC8087], whenever a node within an L2TP 357 tunnel becomes the bottleneck for an end-to-end traffic flow. 359 3.3.1.1. Safe Configuration of a 'Non-ECN' Ingress LCCE 361 The following text is appended to both Section 5.3 of [RFC2661] and 362 Section 4.5 of [RFC3931] as an update to the base L2TPv2 and L2TPv3 363 specifications: 365 An LCCE that does not support the ECN Extension in Section 3.3.1.2 366 of RFCXXXX MUST follow the configuration requirements in 367 Section 3.2 of RFCXXXX for when the outer PSN header is IP (v4 or 368 v6). {RFCXXXX refers to the present document so it will need to be 369 inserted by the RFC Editor} 371 In particular this means that an LCCE implementation that does not 372 support the ECN Extension MUST propagate the ECN field between inner 373 and outer IP headers independently of any configuration of the 374 Diffserv extension of L2TP [RFC3308]. 376 3.3.1.2. ECN Extension for L2TP (v2 or v3) 378 When the outer PSN header and the payload inside the L2 header are 379 both IP (v4 or v6), to comply with RFC 6040, an LCCE will follow the 380 rules for propagation of the ECN field at ingress and egress in 381 Section 4 of RFC 6040 [RFC6040]. 383 Before encapsulating any data packets, RFC 6040 requires an ingress 384 LCCE to check that the egress LCCE supports ECN propagation. If the 385 egress supports ECN, the ingress LCCE can use the normal mode of 386 encapsulation. Otherwise, the ingress LCCE has to use compatibility 387 mode [RFC6040]. An LCCE can determine the remote LCCE's support for 388 ECN either statically (by configuration) or by dynamic discovery 389 during setup of each control connection between the LCCEs, using the 390 Capability AVP defined in Section 3.3.1.2.1 below. 392 Where the outer PSN header is some protocol other than IP that 393 supports ECN, the appropriate ECN propagation specification will need 394 to be followed, e.g. "Explicit Congestion Marking in MPLS" 395 [RFC5129]. Where no specification exists for ECN propagation by a 396 particular PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives general 397 guidance on how to design ECN propagation into a protocol that 398 encapsulates IP. 400 3.3.1.2.1. LCCE Capability AVP for ECN Capability Negotiation 402 The LCCE Capability Attribute Value Pair (AVP) defined here has 403 Attribute Type ZZ. The Attribute Value field for this AVP is a bit- 404 mask with the following 16-bit format: 406 0 1 407 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |X X X X X X X X X X X X X X X E| 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 This AVP MAY be present in the following message types: SCCRQ and 413 SCCRP (Start-Control-Connection-Request and Start-Control-Connection- 414 Reply). This AVP MAY be hidden (the H-bit set to 0 or 1) and is 415 optional (M-bit not set). The length (before hiding) of this AVP 416 MUST be 8 octets. The Vendor ID is the IETF Vendor ID of 0. 418 Bit 15 of the Value field of the LCCE Capability AVP is defined as 419 the ECN Capability flag (E). When the ECN Capability flag is set to 420 1, it indicates that the sender supports ECN propagation. When the 421 ECN Capability flag is cleared to zero, or when no LCCE Capabiliy AVP 422 is present, it indicates that the sender does not support ECN 423 propagation. All the other bits are reserved. They MUST be cleared 424 to zero when sent and ignored when received or forwarded. 426 An LCCE initiating a control connection will send a Start-Control- 427 Connection-Request (SCCRQ) containing an LCCE Capability AVP with the 428 ECN Capability flag set to 1. If the tunnel terminator supports ECN, 429 it will return a Start-Control-Connection-Reply (SCCRP) that also 430 includes an LCCE Capability AVP with the ECN Capability flag set to 431 1. Then, for any sessions created by that control connection, both 432 ends of the tunnel can use the normal mode of RFC 6040 to propagate 433 the ECN field when encapsulating data packets. 435 If, on the other hand, the tunnel terminator does not support ECN it 436 will ignore the ECN flag in the LCCE Capability AVP and send an SCCRP 437 to the tunnel initiator without a Capability AVP (or with a 438 Capability AVP but with the ECN Capability flag cleared to zero). 439 The tunnel initiator interprets the absence of the ECN Capability 440 flag in the SCCRP as an indication that the tunnel terminator is 441 incapable of supporting ECN. When encapsulating data packets for any 442 sessions created by that control connection, the tunnel initiator 443 will then use the compatibility mode of RFC 6040 to clear the ECN 444 field of the outer IP header to 0b00. 446 If the tunnel terminator does not support this ECN extension, the 447 network operator is still expected to configure it to comply with the 448 safety provisions set out in Section 3.3.1.1 above, when it acts as 449 an ingress LCCE. 451 3.3.2. GRE 453 The GRE terminology used here is defined in [RFC2784]. GRE is often 454 used as a tightly coupled shim header between IP headers. Sometimes 455 the GRE shim header encapsulates an L2 header, which might in turn 456 encapsulate an IP header. Therefore GRE is within the scope of RFC 457 6040 as updated by Section 3.1 above. 459 GRE tunnel endpoint maintainers are RECOMMENDED to support [RFC6040] 460 as updated by the present specification, in order to provide the 461 benefits of ECN [RFC8087] whenever a node within a GRE tunnel becomes 462 the bottleneck for an end-to-end IP traffic flow tunnelled over GRE 463 using IP as the delivery protocol (outer header). 465 GRE tunnels do not support dynamic configuration based on capability 466 negotiation, so the ECN capability has to be manually configured, 467 which is specified in Section 4.3 of RFC 6040. 469 Where the delivery protocol is some protocol other than IP that 470 supports ECN, the appropriate ECN propagation specification will need 471 to be followed, e.g Explicit Congestion Marking in MPLS [RFC5129]. 472 Where no specification exists for ECN propagation by a particular 473 PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more general 474 guidance on how to propagate ECN to and from protocols that 475 encapsulate IP. 477 3.3.2.1. Safe Configuration of a 'Non-ECN' GRE Ingress 479 The following text is appended to Section 3 of [RFC2784] as an update 480 to the base GRE specification: 482 A GRE tunnel ingress that does not support RFC 6040 or one of its 483 compatible predecessors (RFC 4301 or the full functionality mode 484 of RFC 3168) MUST follow the configuration requirements in 485 Section 3.2 of RFCXXXX for when the outer delivery protocol is IP 486 (v4 or v6). {RFCXXXX refers to the present document so it will 487 need to be inserted by the RFC Editor} 489 3.3.3. Teredo 491 {ToDo} 493 4. IANA Considerations 495 IANA is requested to assign the following L2TP Control Message 496 Attribute Value Pair: 498 +----------------+----------------+-----------+ 499 | Attribute Type | Description | Reference | 500 +----------------+----------------+-----------+ 501 | ZZ | ECN Capability | RFCXXXX | 502 +----------------+----------------+-----------+ 504 [TO BE REMOVED: This registration should take place at the following 505 location: https://www.iana.org/assignments/l2tp-parameters/l2tp- 506 parameters.xhtml ] 508 5. Security Considerations 510 The Security Considerations in [RFC6040] and 511 [I-D.ietf-tsvwg-ecn-encap-guidelines] apply equally to the scope 512 defined for the present specification. 514 6. Comments Solicited 516 Comments and questions are encouraged and very welcome. They can be 517 addressed to the IETF Transport Area working group mailing list 518 , and/or to the authors. 520 7. Acknowledgements 522 Thanks to Ing-jyh (Inton) Tsang for initial discussions on the need 523 for ECN propagation in L2TP and its applicability. Thanks also to 524 Carlos Pignataro, Tom Herbert and Ignacio Goyret for helpful advice 525 and comments. 527 8. References 529 8.1. Normative References 531 [I-D.ietf-tsvwg-ecn-encap-guidelines] 532 Briscoe, B., Kaippallimalil, J., and P. Thaler, 533 "Guidelines for Adding Congestion Notification to 534 Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- 535 encap-guidelines-08 (work in progress), March 2017. 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, 539 DOI 10.17487/RFC2119, March 1997, 540 . 542 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 543 "Definition of the Differentiated Services Field (DS 544 Field) in the IPv4 and IPv6 Headers", RFC 2474, 545 DOI 10.17487/RFC2474, December 1998, 546 . 548 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 549 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 550 RFC 2661, DOI 10.17487/RFC2661, August 1999, 551 . 553 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 554 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 555 DOI 10.17487/RFC2784, March 2000, 556 . 558 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 559 of Explicit Congestion Notification (ECN) to IP", 560 RFC 3168, DOI 10.17487/RFC3168, September 2001, 561 . 563 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 564 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 565 RFC 3931, DOI 10.17487/RFC3931, March 2005, 566 . 568 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 569 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 570 December 2005, . 572 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 573 Network Address Translations (NATs)", RFC 4380, 574 DOI 10.17487/RFC4380, February 2006, 575 . 577 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 578 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 579 2008, . 581 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 582 Notification", RFC 6040, DOI 10.17487/RFC6040, November 583 2010, . 585 8.2. Informative References 587 [GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp 588 interface", Technical Specification TS 29.060. 590 [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling 591 Protocol User Plane (GTPv1-U)", Technical Specification TS 592 29.281. 594 [GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) 595 Tunnelling Protocol for Control plane (GTPv2-C)", 596 Technical Specification TS 29.274. 598 [I-D.ietf-intarea-gue] 599 Herbert, T., Yong, L., and O. Zia, "Generic UDP 600 Encapsulation", draft-ietf-intarea-gue-04 (work in 601 progress), May 2017. 603 [I-D.ietf-nvo3-geneve] 604 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 605 Network Virtualization Encapsulation", draft-ietf- 606 nvo3-geneve-04 (work in progress), March 2017. 608 [I-D.ietf-nvo3-vxlan-gpe] 609 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 610 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work 611 in progress), April 2017. 613 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 614 Routing Encapsulation (GRE)", RFC 1701, 615 DOI 10.17487/RFC1701, October 1994, 616 . 618 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 619 W., and G. Zorn, "Point-to-Point Tunneling Protocol 620 (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, 621 . 623 [RFC2983] Black, D., "Differentiated Services and Tunnels", 624 RFC 2983, DOI 10.17487/RFC2983, October 2000, 625 . 627 [RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer 628 Two Tunneling Protocol (L2TP) Differentiated Services 629 Extension", RFC 3308, DOI 10.17487/RFC3308, November 2002, 630 . 632 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 633 Ed., "Control And Provisioning of Wireless Access Points 634 (CAPWAP) Protocol Specification", RFC 5415, 635 DOI 10.17487/RFC5415, March 2009, 636 . 638 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 639 Locator/ID Separation Protocol (LISP)", RFC 6830, 640 DOI 10.17487/RFC6830, January 2013, 641 . 643 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 644 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 645 eXtensible Local Area Network (VXLAN): A Framework for 646 Overlaying Virtualized Layer 2 Networks over Layer 3 647 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 648 . 650 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 651 Virtualization Using Generic Routing Encapsulation", 652 RFC 7637, DOI 10.17487/RFC7637, September 2015, 653 . 655 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 656 Explicit Congestion Notification (ECN)", RFC 8087, 657 DOI 10.17487/RFC8087, March 2017, 658 . 660 [RFC8159] Konstantynowicz, M., Ed., Heron, G., Ed., Schatzmayr, R., 661 and W. Henderickx, "Keyed IPv6 Tunnel", RFC 8159, 662 DOI 10.17487/RFC8159, May 2017, 663 . 665 Author's Address 667 Bob Briscoe 668 Simula Research Laboratory 669 UK 671 EMail: ietf@bobbriscoe.net 672 URI: http://bobbriscoe.net/