idnits 2.17.1 draft-ietf-tsvwg-rfc6040update-shim-06.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 (March 18, 2018) is 2203 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-09 == Outdated reference: A later version (-03) exists of draft-eastlake-sfc-nsh-ecn-support-00 == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-05 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-06 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-05 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 8229 (Obsoleted by RFC 9329) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 9 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 CableLabs 4 Updates: 6040, 2661, 2784, 3931, 4380, March 18, 2018 5 7450 (if approved) 6 Intended status: Standards Track 7 Expires: September 19, 2018 9 Propagating Explicit Congestion Notification Across IP Tunnel Headers 10 Separated by a Shim 11 draft-ietf-tsvwg-rfc6040update-shim-06 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, Teredo and AMT). This specification also updates RFC 24 6040 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 https://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 September 19, 2018. 44 Copyright Notice 46 Copyright (c) 2018 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 (https://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 . 9 69 5.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 9 70 5.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.1.4. AMT . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 8. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 16 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 79 10.2. Informative References . . . . . . . . . . . . . . . . . 18 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 82 1. Introduction 84 RFC 6040 on "Tunnelling of Explicit Congestion Notification" 85 [RFC6040] made the rules for propagation of Explicit Congestion 86 Notification (ECN [RFC3168]) consistent for all forms of IP in IP 87 tunnel. 89 A common pattern for many tunnelling protocols is to encapsulate an 90 inner IP header (v4 or v6) with shim header(s) then an outer IP 91 header (v4 or v6). Some of these shim headers are designed as 92 generic encapsulations, so they do not necessarily directly 93 encapsulate an inner IP header. Instead they can encapsulate headers 94 such as link-layer (L2) protocols that in turn often encapsulate IP. 96 To clear up confusion, this specification clarifies that the scope of 97 RFC 6040 includes any IP-in-IP tunnel, including those with shim 98 header(s) and other encapsulations between the IP headers. Where 99 necessary, it updates the specifications of the relevant 100 encapsulation protocols with the specific text necessary to comply 101 with RFC 6040. 103 This specification also updates RFC 6040 to state how operators ought 104 to configure a legacy tunnel ingress to avoid unsafe system 105 configurations. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119] 112 when, and only when, they appear in all capitals, as shown here. 114 This specification uses the terminology defined in RFC 6040 115 [RFC6040]. 117 3. Scope of RFC 6040 119 In section 1.1 of RFC 6040, its scope is defined as: 121 "...ECN field processing at encapsulation and decapsulation for 122 any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It 123 applies irrespective of whether IPv4 or IPv6 is used for either 124 the inner or outer headers. ..." 126 This was intended to include cases where shim header(s) sit between 127 the IP headers. Many tunnelling implementers have interpreted the 128 scope of RFC 6040 as it was intended, but it is ambiguous. 129 Therefore, this specification updates RFC 6040 by adding the 130 following scoping text after the sentences quoted above: 132 It applies in cases where an outer IP header encapsulates an inner 133 IP header either directly or indirectly by encapsulating other 134 headers that in turn encapsulate (or might encapsulate) an inner 135 IP header. 137 There is another problem with the scope of RFC 6040. Like many IETF 138 specifications, RFC 6040 is written as a specification that 139 implementations can choose to claim compliance with. This means it 140 does not cover two important cases: 142 1. those cases where it is infeasible for an implementation to 143 access an inner IP header when adding or removing an outer IP 144 header; 146 2. those implementations that choose not to propagate ECN between IP 147 headers. 149 However, the ECN field is a non-optional part of the IP header (v4 150 and v6). So any implementation that creates an outer IP header has 151 to give the ECN field some value. There is only one safe value a 152 tunnel ingress can use if it does not know whether the egress 153 supports propagation of the ECN field; it has to clear the ECN field 154 in any outer IP header to 0b00. 156 However, an RFC has no jurisdiction over implementations that choose 157 not to comply with it or cannot comply with it, including all those 158 implementations that pre-dated the RFC. Therefore it would have been 159 unreasonable to add such a requirement to RFC 6040. Nonetheless, to 160 ensure safe propagation of the ECN field over tunnels, it is 161 reasonable to add requirements on operators, to ensure they configure 162 their tunnels safely (where possible). Before stating these 163 configuration requirements in Section 4, the factors that determine 164 whether propagating ECN is feasible or desirable will be briefly 165 introduced. 167 3.1. Feasibility of ECN Propagation between Tunnel Headers 169 In many cases shim header(s) and an outer IP header are always added 170 to (or removed from) an inner IP packet as part of the same 171 procedure. We call this a tightly coupled shim header. Processing 172 the shim and outer together is often necessary because the shim(s) 173 are not sufficient for packet forwarding in their own right; not 174 unless complemented by an outer header. In these cases it will often 175 be feasible for an implementation to propagate the ECN field between 176 the IP headers. 178 In some cases a tunnel adds an outer IP header and a tightly coupled 179 shim header to an inner header that is not an IP header, but that in 180 turn encapsulates an IP header (or might encapsulate an IP header). 181 For instance an inner Ethernet (or other link layer) header might 182 encapsulate an inner IP header as its payload. We call this a 183 tightly coupled shim over an encapsulating header. 185 Digging to arbitrary depths to find an inner IP header within an 186 encapsulation is strictly a layering violation so it cannot be a 187 required behaviour. Nonetheless, some tunnel endpoints already look 188 within a L2 header for an IP header, for instance to map the Diffserv 189 codepoint between an encapsulated IP header and an outer IP header 191 [RFC2983]. In such cases at least, it should be feasible to also 192 (independently) propagate the ECN field between the same IP headers. 193 Thus, access to the ECN field within an encapsulating header can be a 194 useful and benign optimization. The guidelines in section 6 of 195 [I-D.ietf-tsvwg-ecn-encap-guidelines] give the conditions for this 196 layering violation to be benign. 198 3.2. Desirability of ECN Propagation between Tunnel Headers 200 Developers and network operators are encouraged to implement and 201 deploy tunnel endpoints compliant with RFC 6040 (as updated by the 202 present specification) in order to provide the benefits of wider ECN 203 deployment [RFC8087]. Nonetheless, propagation of ECN between IP 204 headers, whether separated by shim headers or not, has to be optional 205 to implement and to use, because: 207 o Legacy implementations of tunnels without any ECN support already 208 exist 210 o A network might be designed so that there is usually no bottleneck 211 within the tunnel 213 o If the tunnel endpoints would have to search within an L2 header 214 to find an encapsulated IP header, it might not be worth the 215 potential performance hit 217 4. Making a non-ECN Tunnel Ingress Safe by Configuration 219 Even when no specific attempt has been made to implement propagation 220 of the ECN field at a tunnel ingress, it ought to be possible for the 221 operator to render a tunnel ingress safe by configuration. The main 222 safety concern is to disable (clear to zero) the ECN capability in 223 the outer IP header at the ingress if the egress of the tunnel does 224 not implement ECN logic to propagate any ECN markings into the packet 225 forwarded beyond the tunnel. Otherwise the non-ECN egress could 226 discard any ECN marking introduced within the tunnel, which would 227 break all the ECN-based control loops that regulate the traffic load 228 over the tunnel. 230 Therefore this specification updates RFC 6040 by inserting the 231 following text just before the last paragraph of section 4.3: 233 When the outer tunnel header is IP (v4 or v6), if possible, the 234 operator MUST configure the ingress to zero the outer ECN field in 235 any of the following cases: 237 * if it is known that the tunnel egress does not support 238 propagation of the ECN field (RFC 6040, RFC 4301 or the full 239 functionality mode of RFC 3168) 241 * or if the behaviour of the egress is not known or an egress 242 with unknown behaviour might be dynamically paired with the 243 ingress. 245 * or if an IP header might be encapsulated within a non-IP header 246 that the tunnel ingress is encapsulating, but the ingress does 247 not inspect within the encapsulation. 249 In order that the network operator can comply with the above safety 250 rules, even if a tunnel ingress does not claim to support RFC 6040, 251 RFC 4301 or the full functionality mode of RFC 3168, the 252 implementation of the tunnel ingress: 254 o MUST make propagation of the ECN field between inner and outer IP 255 headers independent of any configuration of Diffserv codepoint 256 propagation; 258 o SHOULD zero the outer ECN field in its default configuration. 260 There might be concern that the above "MUST" makes compliant 261 equipment non-compliant at a stroke. However, any equipment that is 262 still treating the ToS octet (IPv4) or the Traffic Class octet (IPv6) 263 as a single 8-bit field is already non-compliant, and has been since 264 1998 when the upper 6 bits were separated off for the Diffserv 265 codepoint (DSCP) [RFC2474]. For instance, copying the ECN field as a 266 side-effect of copying the DSCP is a seriously unsafe bug that risks 267 breaking the feedback loops that regulate load on a tunnel. 269 Permanently zeroing the outer ECN field is safe, but it is not 270 sufficient to claim compliance with RFC 6040 because it does not meet 271 the aim of introducing ECN support to tunnels (see Section 4.3 of 272 [RFC6040]). 274 5. IP-in-IP Tunnels with Tightly Coupled Shim Headers 276 There follows a list of specifications of encapsulations with tightly 277 coupled shim header(s), in rough chronological order. The list is 278 confined to standards track or widely deployed protocols. The list 279 is not necessarily exhaustive so, for the avoidance of doubt, the 280 scope of RFC 6040 is defined in Section 3 and is not limited to this 281 list. 283 o PPTP (Point-to-Point Tunneling Protocol) [RFC2637]; 284 o L2TP (Layer 2 Tunnelling Protocol), specifically L2TPv2 [RFC2661] 285 and L2TPv3 [RFC3931], which not only includes all the L2-specific 286 specializations of L2TP, but also derivatives such as the Keyed 287 IPv6 Tunnel [RFC8159]; 289 o GRE (Generic Routing Encapsulation) [RFC2784] and NVGRE (Network 290 Virtualization using GRE) [RFC7637]; 292 o GTP (GPRS Tunnelling Protocol), specifically GTPv1 [GTPv1], GTP v1 293 User Plane [GTPv1-U], GTP v2 Control Plane [GTPv2-C]; 295 o Teredo [RFC4380]; 297 o CAPWAP (Control And Provisioning of Wireless Access Points) 298 [RFC5415]; 300 o LISP (Locator/Identifier Separation Protocol) [RFC6830]; 302 o AMT (Automatic Multicast Tunneling) [RFC7450]; 304 o VXLAN (Virtual eXtensible Local Area Network) [RFC7348] and VXLAN- 305 GPE [I-D.ietf-nvo3-vxlan-gpe]; 307 o The Network Service Header (NSH [RFC8300]) for Service Function 308 Chaining (SFC); 310 o Geneve [I-D.ietf-nvo3-geneve]; 312 o GUE (Generic UDP Encapsulation) [I-D.ietf-intarea-gue]; 314 o Direct tunnelling of an IP packet within a UDP/IP datagram (see 315 Section 3.1.11 of [RFC8085]); 317 o TCP Encapsulation of IKE and IPsec Packets (see Section 12.5 of 318 [RFC8229]). 320 Some of the listed protocols enable encapsulation of a variety of 321 network layer protocols as inner and/or outer. This specification 322 applies in the cases where there is an inner and outer IP header as 323 described in Section 3. Otherwise 324 [I-D.ietf-tsvwg-ecn-encap-guidelines] gives guidance on how to design 325 propagation of ECN into other protocols that might encapsulate IP. 327 Where protocols in the above list need to be updated to specify ECN 328 propagation and they are under IETF change control, update text is 329 given in the following subsections. For those not under IETF 330 control, it is RECOMMENDED that implementations of encapsulation and 331 decapsulation comply with RFC 6040. It is also RECOMMENDED that 332 their specifications are updated to add a requirement to comply with 333 RFC 6040 (as updated by the present document). 335 PPTP is not under the change control of the IETF, but it has been 336 documented in an informational RFC [RFC2637]. However, there is no 337 need for the present specification to update PPTP because L2TP has 338 been developed as a standardized replacement. 340 NVGRE is not under the change control of the IETF, but it has been 341 documented in an informational RFC [RFC7637]. NVGRE is a specific 342 use-case of GRE (it re-purposes the key field from the initial 343 specification of GRE [RFC1701] as a Virtual Subnet ID). Therefore 344 the text that updates GRE in Section 5.1.2 below is also intended to 345 update NVGRE. 347 Although the definition of the various GTP shim headers is under the 348 control of the 3GPP, it is hard to determine whether the 3GPP or the 349 IETF controls standardization of the _process_ of adding both a GTP 350 and an IP header to an inner IP header. Nonetheless, the present 351 specification is provided so that the 3GPP can refer to it from any 352 of its own specifications of GTP and IP header processing. 354 The specification of CAPWAP already specifies RFC 3168 ECN 355 propagation and ECN capability negotiation. Without modification the 356 CAPWAP specification already interworks with the backward compatible 357 updates to RFC 3168 in RFC 6040. 359 LISP made the ECN propagation procedures in RFC 3168 mandatory from 360 the start. RFC 3168 has since been updated by RFC 6040, but the 361 changes are backwards compatible so there is still no need for LISP 362 tunnel endpoints to negotiate their ECN capabilities. 364 VXLAN is not under the change control of the IETF but it has been 365 documented in an informational RFC. In contrast, VXLAN-GPE (Generic 366 Protocol Extension) is being documented under IETF change control. 367 It is RECOMMENDED that VXLAN and VXLAN-GPE implementations comply 368 with RFC 6040 when the VXLAN header is inserted between (or removed 369 from between) IP headers. The authors of any future update to these 370 specifications are encouraged to add a requirement to comply with RFC 371 6040 as updated by the present specification. 373 The Network Service Header (NSH [RFC8300]) has been defined as a 374 shim-based encapsulation to identify the Service Function Path (SFP) 375 in the Service Function Chaining (SFC) architecture [RFC7665]. A 376 proposal has been made for the processing of ECN when handling 377 transport encapsulation [I-D.eastlake-sfc-nsh-ecn-support]. 379 The specifications of Geneve and GUE already refer to RFC 6040 for 380 ECN encapsulation. 382 Section 3.1.11 of the UDP usage guidelines [RFC8085] already explains 383 that a tunnel that encapsulates an IP header directly within a UDP/IP 384 datagram needs to follow RFC 6040 when propagating the ECN field 385 between inner and outer IP headers. The requirements in Section 4 386 update RFC 6040 so, by reference, they automatically update RFC 8085 387 to add the important but previously unstated requirement that, if the 388 UDP tunnel egress does not, or might not, support ECN propagation, a 389 legacy UDP tunnel ingress has to clear the outer IP ECN field to 390 0b00, e.g. by configuration. 392 Section 12.5 of TCP Encapsulation of IKE and IPsec Packets [RFC8229] 393 already recommends the compatibility mode of RFC 6040 in this case, 394 because there is not a one-to-one mapping between inner and outer 395 packets. 397 5.1. Specific Updates to Protocols under IETF Change Control 399 5.1.1. L2TP (v2 and v3) ECN Extension 401 The L2TP terminology used here is defined in [RFC2661] and [RFC3931]. 403 L2TPv3 [RFC3931] is used as a shim header between any packet-switched 404 network (PSN) header (e.g. IPv4, IPv6, MPLS) and many types of layer 405 2 (L2) header. The L2TPv3 shim header encapsulates an L2-specific 406 sub-layer then an L2 header that is likely to contain an inner IP 407 header (v4 or v6). Then this whole stack of headers can be 408 encapsulated optionally within an outer UDP header then an outer PSN 409 header that is typically IP (v4 or v6). 411 L2TPv2 is used as a shim header between any PSN header and a PPP 412 header, which is in turn likely to encapsulate an IP header. 414 Even though these shims are rather fat (particularly in the case of 415 L2TPv3), they still fit the definition of a tightly coupled shim 416 header over an encapsulating header (Section 3.1), because all the 417 headers encapsulating the L2 header are added (or removed) together. 418 L2TPv2 and L2TPv3 are therefore within the scope of RFC 6040, as 419 updated by Section 3 above. 421 L2TP maintainers are RECOMMENDED to implement the ECN extension to 422 L2TPv2 and L2TPv3 defined in Section 5.1.1.2 below, in order to 423 provide the benefits of ECN [RFC8087], whenever a node within an L2TP 424 tunnel becomes the bottleneck for an end-to-end traffic flow. 426 5.1.1.1. Safe Configuration of a 'Non-ECN' Ingress LCCE 428 The following text is appended to both Section 5.3 of [RFC2661] and 429 Section 4.5 of [RFC3931] as an update to the base L2TPv2 and L2TPv3 430 specifications: 432 The operator of an LCCE that does not support the ECN Extension in 433 Section 5.1.1.2 of RFCXXXX MUST follow the configuration 434 requirements in Section 4 of RFCXXXX to ensure it clears the outer 435 IP ECN field to 0b00 when the outer PSN header is IP (v4 or v6). 436 {RFCXXXX refers to the present document so it will need to be 437 inserted by the RFC Editor} 439 In particular, for an LCCE implementation that does not support the 440 ECN Extension, this means that configuration of how it propagates the 441 ECN field between inner and outer IP headers MUST be independent of 442 any configuration of the Diffserv extension of L2TP [RFC3308]. 444 5.1.1.2. ECN Extension for L2TP (v2 or v3) 446 When the outer PSN header and the payload inside the L2 header are 447 both IP (v4 or v6), to comply with RFC 6040, an LCCE will follow the 448 rules for propagation of the ECN field at ingress and egress in 449 Section 4 of RFC 6040 [RFC6040]. 451 Before encapsulating any data packets, RFC 6040 requires an ingress 452 LCCE to check that the egress LCCE supports ECN propagation as 453 defined in RFC 6040 or one of its compatible predecessors ([RFC4301] 454 or the full functionality mode of [RFC3168]). If the egress supports 455 ECN propagation, the ingress LCCE can use the normal mode of 456 encapsulation (copying the ECN field from inner to outer). 457 Otherwise, the ingress LCCE has to use compatibility mode [RFC6040] 458 (clearing the outer IP ECN field to 0b00). 460 An LCCE can determine the remote LCCE's support for ECN either 461 statically (by configuration) or by dynamic discovery during setup of 462 each control connection between the LCCEs, using the Capability AVP 463 defined in Section 5.1.1.2.1 below. 465 Where the outer PSN header is some protocol other than IP that 466 supports ECN, the appropriate ECN propagation specification will need 467 to be followed, e.g. "Explicit Congestion Marking in MPLS" 468 [RFC5129]. Where no specification exists for ECN propagation by a 469 particular PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives general 470 guidance on how to design ECN propagation into a protocol that 471 encapsulates IP. 473 5.1.1.2.1. LCCE Capability AVP for ECN Capability Negotiation 475 The LCCE Capability Attribute-Value Pair (AVP) defined here has 476 Attribute Type ZZ. The Attribute Value field for this AVP is a bit- 477 mask with the following 16-bit format: 479 0 1 480 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |X X X X X X X X X X X X X X X E| 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 Figure 1: Value Field for the LCCE Capability Attribute 487 This AVP MAY be present in the following message types: SCCRQ and 488 SCCRP (Start-Control-Connection-Request and Start-Control-Connection- 489 Reply). This AVP MAY be hidden (the H-bit set to 0 or 1) and is 490 optional (M-bit not set). The length (before hiding) of this AVP 491 MUST be 8 octets. The Vendor ID is the IETF Vendor ID of 0. 493 Bit 15 of the Value field of the LCCE Capability AVP is defined as 494 the ECN Capability flag (E). When the ECN Capability flag is set to 495 1, it indicates that the sender supports ECN propagation. When the 496 ECN Capability flag is cleared to zero, or when no LCCE Capabiliy AVP 497 is present, it indicates that the sender does not support ECN 498 propagation. All the other bits are reserved. They MUST be cleared 499 to zero when sent and ignored when received or forwarded. 501 An LCCE initiating a control connection will send a Start-Control- 502 Connection-Request (SCCRQ) containing an LCCE Capability AVP with the 503 ECN Capability flag set to 1. If the tunnel terminator supports ECN, 504 it will return a Start-Control-Connection-Reply (SCCRP) that also 505 includes an LCCE Capability AVP with the ECN Capability flag set to 506 1. Then, for any sessions created by that control connection, both 507 ends of the tunnel can use the normal mode of RFC 6040, i.e. it can 508 copy the IP ECN field from inner to outer when encapsulating data 509 packets. 511 If, on the other hand, the tunnel terminator does not support ECN it 512 will ignore the ECN flag in the LCCE Capability AVP and send an SCCRP 513 to the tunnel initiator without a Capability AVP (or with a 514 Capability AVP but with the ECN Capability flag cleared to zero). 515 The tunnel initiator interprets the absence of the ECN Capability 516 flag in the SCCRP as an indication that the tunnel terminator is 517 incapable of supporting ECN. When encapsulating data packets for any 518 sessions created by that control connection, the tunnel initiator 519 will then use the compatibility mode of RFC 6040 to clear the ECN 520 field of the outer IP header to 0b00. 522 If the tunnel terminator does not support this ECN extension, the 523 network operator is still expected to configure it to comply with the 524 safety provisions set out in Section 5.1.1.1 above, when it acts as 525 an ingress LCCE. 527 5.1.2. GRE 529 The GRE terminology used here is defined in [RFC2784]. GRE is often 530 used as a tightly coupled shim header between IP headers. Sometimes 531 the GRE shim header encapsulates an L2 header, which might in turn 532 encapsulate an IP header. Therefore GRE is within the scope of RFC 533 6040 as updated by Section 3 above. 535 GRE tunnel endpoint maintainers are RECOMMENDED to support [RFC6040] 536 as updated by the present specification, in order to provide the 537 benefits of ECN [RFC8087] whenever a node within a GRE tunnel becomes 538 the bottleneck for an end-to-end IP traffic flow tunnelled over GRE 539 using IP as the delivery protocol (outer header). 541 GRE itself does not support dynamic set-up and configuration of 542 tunnels. However, control plane protocols such as Mobile IPv4 (MIP4) 543 [RFC5944], Mobile IPv6 (MIP6) [RFC6275], Proxy Mobile IP (PMIP) 544 [RFC5845] and IKEv2 [RFC5996] are sometimes used to set up GRE 545 tunnels dynamically. 547 When these control protocols set up IP-in-IP or IPSec tunnels, it is 548 likely that they propagate the ECN field as defined in RFC 6040 or 549 one of its compatible predecessors (RFC 4301 or the full 550 functionality mode of RFC 3168). However, if they use a GRE 551 encapsulation, this presumption is less sound. 553 Therefore, If the outer delivery protocol is IP (v4 or v6) the 554 operator is obliged to follow the safe configuration requirements in 555 Section 4 above. Section 5.1.2.1 below updates the base GRE 556 specification with this requirement, to emphasize its importance. 558 Where the delivery protocol is some protocol other than IP that 559 supports ECN, the appropriate ECN propagation specification will need 560 to be followed, e.g Explicit Congestion Marking in MPLS [RFC5129]. 561 Where no specification exists for ECN propagation by a particular 562 PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more general 563 guidance on how to propagate ECN to and from protocols that 564 encapsulate IP. 566 5.1.2.1. Safe Configuration of a 'Non-ECN' GRE Ingress 568 The following text is appended to Section 3 of [RFC2784] as an update 569 to the base GRE specification: 571 The operator of a GRE tunnel ingress MUST follow the configuration 572 requirements in Section 4 of RFCXXXX when the outer delivery 573 protocol is IP (v4 or v6). {RFCXXXX refers to the present document 574 so it will need to be inserted by the RFC Editor} 576 5.1.3. Teredo 578 Teredo [RFC4380] provides a way to tunnel IPv6 over an IPv4 network, 579 with a UDP-based shim header between the two. 581 For Teredo tunnel endpoints to provide the benefits of ECN, the 582 Teredo specification would have to be updated to include negotiation 583 of the ECN capability between Teredo tunnel endpoints. Otherwise it 584 would be unsafe for a Teredo tunnel ingress to copy the ECN field to 585 the IPv6 outer. 587 It is believed that current implementations do not support 588 propagation of ECN, but that they do safely zero the ECN field in the 589 outer IPv6 header. However the specification does not mention 590 anything about this. 592 To make existing Teredo deployments safe, it would be possible to add 593 ECN capability negotiation to those that are subject to remote OS 594 update. However, for those implementations not subject to remote OS 595 update, it will not be feasible to require them to be configured 596 correctly, because Teredo tunnel endpoints are generally deployed on 597 hosts. 599 Therefore, until ECN support is added to the specification of Teredo, 600 the only feasible further safety precaution available here is to 601 update the specification of Teredo implementations with the following 602 text, as a new section 5.1.3: 604 "5.1.3 Safe 'Non-ECN' Teredo Encapsulation 606 A Teredo tunnel ingress implementation that does not support ECN 607 propagation as defined in RFC 6040 or one of its compatible 608 predecessors (RFC 4301 or the full functionality mode of RFC 3168) 609 MUST zero the ECN field in the outer IPv6 header." 611 5.1.4. AMT 613 Automatic Multicast Tunneling (AMT [RFC7450]) is a tightly coupled 614 shim header that encapsulates an IP packet and is itself encapsulated 615 within a UDP/IP datagram. Therefore AMT is within the scope of RFC 616 6040 as updated by Section 3 above. 618 AMT tunnel endpoint maintainers are RECOMMENDED to support [RFC6040] 619 as updated by the present specification, in order to provide the 620 benefits of ECN [RFC8087] whenever a node within an AMT tunnel 621 becomes the bottleneck for an IP traffic flow tunnelled over AMT. 623 To comply with RFC 6040, an AMT relay and gateway will follow the 624 rules for propagation of the ECN field at ingress and egress 625 respectively, as described in Section 4 of RFC 6040 [RFC6040]. 627 Before encapsulating any data packets, RFC 6040 requires an ingress 628 AMT relay to check that the egress AMT gateway supports ECN 629 propagation as defined in RFC 6040 or one of its compatible 630 predecessors (RFC 4301 or the full functionality mode of RFC 3168). 631 If the egress gateway supports ECN, the ingress relay can use the 632 normal mode of encapsulation (copying the IP ECN field from inner to 633 outer). Otherwise, the ingress relay has to use compatibility mode, 634 which means it has to clear the outer ECN field to zero [RFC6040]. 636 An AMT tunnel is created dynamically (not manually), so the relay 637 will need to determine the remote gateway's support for ECN using the 638 ECN capability declaration defined in Section 5.1.4.2 below. 640 5.1.4.1. Safe Configuration of a 'Non-ECN' Ingress AMT Relay 642 The following text is appended to Section 4.2.2 of [RFC7450] as an 643 update to the AMT specification: 645 The operator of an AMT relay that does not support RFC 6040 or one 646 of its compatible predecessors (RFC 4301 or the full functionality 647 mode of RFC 3168) MUST follow the configuration requirements in 648 Section 4 of RFCXXXX to ensure it clears the outer IP ECN field to 649 zero. {RFCXXXX refers to the present document so it will need to 650 be inserted by the RFC Editor} 652 5.1.4.2. ECN Capability Declaration of an AMT Gateway 653 0 1 2 3 654 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | V=0 |Type=3 | Reserved |E|P| Reserved | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Request Nonce | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Figure 2: Updated AMT Request Message Format 663 Bit 14 of the AMT Request Message counting from 0 (or bit 7 of the 664 Reserved field counting from 1) is defined here as the AMT Gateway 665 ECN Capability flag (E), as shown in Figure 2. The definitions of 666 all other fields in the AMT Request Message are unchanged from RFC 667 7450. 669 When the E flag is set to 1, it indicates that the sender of the 670 message supports RFC 6040 ECN propagation. When it is cleared to 671 zero, it indicates the sender of the message does not support RFC 672 6040 ECN propagation. An AMT gateway "that supports RFC 6040 ECN 673 propagation" means one that propagates the ECN field to the forwarded 674 data packet based on the combination of arriving inner and outer ECN 675 fields, as defined in Section 4 of RFC 6040. 677 The other bits of the Reserved field remain reserved. They will 678 continue to be cleared to zero when sent and ignored when either 679 received or forwarded, as specified in Section 5.1.3.3. of RFC 7450. 681 An AMT gateway that does not support RFC 6040 MUST NOT set the E flag 682 of its Request Message to 1. 684 An AMT gateway that supports RFC 6040 ECN propagation MUST set the E 685 flag of its Relay Discovery Message to 1. 687 The action of the corresponding AMT relay that receives a Request 688 message with the E flag set to 1 depends on whether the relay itself 689 supports RFC 6040 ECN propagation: 691 o If the relay supports RFC 6040 ECN propagation, it will store the 692 ECN capability of the gateway along with its address. Then 693 whenever it tunnels datagrams towards this gateway, it MUST use 694 the normal mode of RFC 6040 to propagate the ECN field when 695 encapsulating datagrams (i.e. it copies the IP ECN field from 696 inner to outer). 698 o If the discovered AMT relay does not support RFC 6040 ECN 699 propagation, it will ignore the E flag in the Reserved field, as 700 per section 5.1.3.3. of RFC 7450. 702 If the AMT relay does not support RFC 6040 ECN propagation, the 703 network operator is still expected to configure it to comply with 704 the safety provisions set out in Section 5.1.4.1 above. 706 6. IANA Considerations 708 IANA is requested to assign the following L2TP Control Message 709 Attribute Value Pair: 711 +----------------+----------------+-----------+ 712 | Attribute Type | Description | Reference | 713 +----------------+----------------+-----------+ 714 | ZZ | ECN Capability | RFCXXXX | 715 +----------------+----------------+-----------+ 717 [TO BE REMOVED: This registration should take place at the following 718 location: https://www.iana.org/assignments/l2tp-parameters/l2tp- 719 parameters.xhtml ] 721 7. Security Considerations 723 The Security Considerations in [RFC6040] and 724 [I-D.ietf-tsvwg-ecn-encap-guidelines] apply equally to the scope 725 defined for the present specification. 727 8. Comments Solicited 729 Comments and questions are encouraged and very welcome. They can be 730 addressed to the IETF Transport Area working group mailing list 731 , and/or to the authors. 733 9. Acknowledgements 735 Thanks to Ing-jyh (Inton) Tsang for initial discussions on the need 736 for ECN propagation in L2TP and its applicability. Thanks also to 737 Carlos Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen 738 Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake 739 Holland and Sri Gundavelli for helpful advice and comments. "A 740 Comparison of IPv6-over-IPv4 Tunnel Mechanisms" [RFC7059] helped to 741 identify a number of tunnelling protocols to include within the scope 742 of this document. 744 Bob Briscoe was part-funded by the Research Council of Norway through 745 the TimeIn project. The views expressed here are solely those of the 746 authors. 748 10. References 750 10.1. Normative References 752 [I-D.ietf-tsvwg-ecn-encap-guidelines] 753 Briscoe, B., Kaippallimalil, J., and P. Thaler, 754 "Guidelines for Adding Congestion Notification to 755 Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- 756 encap-guidelines-09 (work in progress), July 2017. 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, 760 DOI 10.17487/RFC2119, March 1997, 761 . 763 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 764 "Definition of the Differentiated Services Field (DS 765 Field) in the IPv4 and IPv6 Headers", RFC 2474, 766 DOI 10.17487/RFC2474, December 1998, 767 . 769 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 770 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 771 RFC 2661, DOI 10.17487/RFC2661, August 1999, 772 . 774 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 775 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 776 DOI 10.17487/RFC2784, March 2000, 777 . 779 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 780 of Explicit Congestion Notification (ECN) to IP", 781 RFC 3168, DOI 10.17487/RFC3168, September 2001, 782 . 784 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 785 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 786 RFC 3931, DOI 10.17487/RFC3931, March 2005, 787 . 789 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 790 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 791 December 2005, . 793 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 794 Network Address Translations (NATs)", RFC 4380, 795 DOI 10.17487/RFC4380, February 2006, 796 . 798 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 799 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 800 2008, . 802 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 803 Notification", RFC 6040, DOI 10.17487/RFC6040, November 804 2010, . 806 10.2. Informative References 808 [GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp 809 interface", Technical Specification TS 29.060. 811 [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling 812 Protocol User Plane (GTPv1-U)", Technical Specification TS 813 29.281. 815 [GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) 816 Tunnelling Protocol for Control plane (GTPv2-C)", 817 Technical Specification TS 29.274. 819 [I-D.eastlake-sfc-nsh-ecn-support] 820 Eastlake, D. and B. Briscoe, "Network Service Header (NSH) 821 Explicit Congestion Notification (ECN) Support", draft- 822 eastlake-sfc-nsh-ecn-support-00 (work in progress), March 823 2018. 825 [I-D.ietf-intarea-gue] 826 Herbert, T., Yong, L., and O. Zia, "Generic UDP 827 Encapsulation", draft-ietf-intarea-gue-05 (work in 828 progress), December 2017. 830 [I-D.ietf-nvo3-geneve] 831 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 832 Network Virtualization Encapsulation", draft-ietf- 833 nvo3-geneve-06 (work in progress), March 2018. 835 [I-D.ietf-nvo3-vxlan-gpe] 836 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 837 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-05 (work 838 in progress), October 2017. 840 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 841 Routing Encapsulation (GRE)", RFC 1701, 842 DOI 10.17487/RFC1701, October 1994, 843 . 845 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 846 W., and G. Zorn, "Point-to-Point Tunneling Protocol 847 (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, 848 . 850 [RFC2983] Black, D., "Differentiated Services and Tunnels", 851 RFC 2983, DOI 10.17487/RFC2983, October 2000, 852 . 854 [RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer 855 Two Tunneling Protocol (L2TP) Differentiated Services 856 Extension", RFC 3308, DOI 10.17487/RFC3308, November 2002, 857 . 859 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 860 Ed., "Control And Provisioning of Wireless Access Points 861 (CAPWAP) Protocol Specification", RFC 5415, 862 DOI 10.17487/RFC5415, March 2009, 863 . 865 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 866 "Generic Routing Encapsulation (GRE) Key Option for Proxy 867 Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010, 868 . 870 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 871 RFC 5944, DOI 10.17487/RFC5944, November 2010, 872 . 874 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 875 "Internet Key Exchange Protocol Version 2 (IKEv2)", 876 RFC 5996, DOI 10.17487/RFC5996, September 2010, 877 . 879 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 880 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 881 2011, . 883 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 884 Locator/ID Separation Protocol (LISP)", RFC 6830, 885 DOI 10.17487/RFC6830, January 2013, 886 . 888 [RFC7059] Steffann, S., van Beijnum, I., and R. van Rein, "A 889 Comparison of IPv6-over-IPv4 Tunnel Mechanisms", RFC 7059, 890 DOI 10.17487/RFC7059, November 2013, 891 . 893 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 894 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 895 eXtensible Local Area Network (VXLAN): A Framework for 896 Overlaying Virtualized Layer 2 Networks over Layer 3 897 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 898 . 900 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 901 DOI 10.17487/RFC7450, February 2015, 902 . 904 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 905 Virtualization Using Generic Routing Encapsulation", 906 RFC 7637, DOI 10.17487/RFC7637, September 2015, 907 . 909 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 910 Chaining (SFC) Architecture", RFC 7665, 911 DOI 10.17487/RFC7665, October 2015, 912 . 914 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 915 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 916 March 2017, . 918 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 919 Explicit Congestion Notification (ECN)", RFC 8087, 920 DOI 10.17487/RFC8087, March 2017, 921 . 923 [RFC8159] Konstantynowicz, M., Ed., Heron, G., Ed., Schatzmayr, R., 924 and W. Henderickx, "Keyed IPv6 Tunnel", RFC 8159, 925 DOI 10.17487/RFC8159, May 2017, 926 . 928 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 929 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 930 August 2017, . 932 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 933 "Network Service Header (NSH)", RFC 8300, 934 DOI 10.17487/RFC8300, January 2018, 935 . 937 Author's Address 939 Bob Briscoe 940 CableLabs 941 UK 943 EMail: ietf@bobbriscoe.net 944 URI: http://bobbriscoe.net/