idnits 2.17.1 draft-ietf-tsvwg-rfc6040update-shim-09.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 (July 8, 2019) is 1753 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-13 == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-07 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-09 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-13 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-07 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-nsh-ecn-support-01 -- 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 (~~), 7 warnings (==), 8 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 Independent 4 Updates: 6040, 2661, 2784, 3931, 4380, July 8, 2019 5 7450 (if approved) 6 Intended status: Standards Track 7 Expires: January 9, 2020 9 Propagating Explicit Congestion Notification Across IP Tunnel Headers 10 Separated by a Shim 11 draft-ietf-tsvwg-rfc6040update-shim-09 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 that use such shim header(s) and updates the specifications 22 of those that do not mention ECN propagation (L2TPv2, L2TPv3, GRE, 23 Teredo and AMT). This specification also updates RFC 6040 with 24 configuration requirements needed to make any legacy tunnel ingress 25 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 January 9, 2020. 44 Copyright Notice 46 Copyright (c) 2019 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. ECN Propagation and Fragmentation/Reassembly . . . . . . . . 7 68 6. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 8 69 6.1. Specific Updates to Protocols under IETF Change Control . 11 70 6.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 11 71 6.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 6.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 15 73 6.1.4. AMT . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 76 9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 18 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 80 11.2. Informative References . . . . . . . . . . . . . . . . . 19 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 RFC 6040 on "Tunnelling of Explicit Congestion Notification" 86 [RFC6040] made the rules for propagation of Explicit Congestion 87 Notification (ECN [RFC3168]) consistent for all forms of IP in IP 88 tunnel. 90 A common pattern for many tunnelling protocols is to encapsulate an 91 inner IP header (v4 or v6) with shim header(s) then an outer IP 92 header (v4 or v6). Some of these shim headers are designed as 93 generic encapsulations, so they do not necessarily directly 94 encapsulate an inner IP header. Instead they can encapsulate headers 95 such as link-layer (L2) protocols that in turn often encapsulate IP. 97 To clear up confusion, this specification clarifies that the scope of 98 RFC 6040 includes any IP-in-IP tunnel, including those with shim 99 header(s) and other encapsulations between the IP headers. Where 100 necessary, it updates the specifications of the relevant 101 encapsulation protocols with the specific text necessary to comply 102 with RFC 6040. 104 This specification also updates RFC 6040 to state how operators ought 105 to configure a legacy tunnel ingress to avoid unsafe system 106 configurations. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119] 113 when, and only when, they appear in all capitals, as shown here. 115 This specification uses the terminology defined in RFC 6040 116 [RFC6040]. 118 3. Scope of RFC 6040 120 In section 1.1 of RFC 6040, its scope is defined as: 122 "...ECN field processing at encapsulation and decapsulation for 123 any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It 124 applies irrespective of whether IPv4 or IPv6 is used for either 125 the inner or outer headers. ..." 127 This was intended to include cases where shim header(s) sit between 128 the IP headers. Many tunnelling implementers have interpreted the 129 scope of RFC 6040 as it was intended, but it is ambiguous. 130 Therefore, this specification updates RFC 6040 by adding the 131 following scoping text after the sentences quoted above: 133 It applies in cases where an outer IP header encapsulates an inner 134 IP header either directly or indirectly by encapsulating other 135 headers that in turn encapsulate (or might encapsulate) an inner 136 IP header. 138 There is another problem with the scope of RFC 6040. Like many IETF 139 specifications, RFC 6040 is written as a specification that 140 implementations can choose to claim compliance with. This means it 141 does not cover two important cases: 143 1. those cases where it is infeasible for an implementation to 144 access an inner IP header when adding or removing an outer IP 145 header; 147 2. those implementations that choose not to propagate ECN between IP 148 headers. 150 However, the ECN field is a non-optional part of the IP header (v4 151 and v6). So any implementation that creates an outer IP header has 152 to give the ECN field some value. There is only one safe value a 153 tunnel ingress can use if it does not know whether the egress 154 supports propagation of the ECN field; it has to clear the ECN field 155 in any outer IP header to 0b00. 157 However, an RFC has no jurisdiction over implementations that choose 158 not to comply with it or cannot comply with it, including all those 159 implementations that pre-dated the RFC. Therefore it would have been 160 unreasonable to add such a requirement to RFC 6040. Nonetheless, to 161 ensure safe propagation of the ECN field over tunnels, it is 162 reasonable to add requirements on operators, to ensure they configure 163 their tunnels safely (where possible). Before stating these 164 configuration requirements in Section 4, the factors that determine 165 whether propagating ECN is feasible or desirable will be briefly 166 introduced. 168 3.1. Feasibility of ECN Propagation between Tunnel Headers 170 In many cases shim header(s) and an outer IP header are always added 171 to (or removed from) an inner IP packet as part of the same 172 procedure. We call this a tightly coupled shim header. Processing 173 the shim and outer together is often necessary because the shim(s) 174 are not sufficient for packet forwarding in their own right; not 175 unless complemented by an outer header. In these cases it will often 176 be feasible for an implementation to propagate the ECN field between 177 the IP headers. 179 In some cases a tunnel adds an outer IP header and a tightly coupled 180 shim header to an inner header that is not an IP header, but that in 181 turn encapsulates an IP header (or might encapsulate an IP header). 182 For instance an inner Ethernet (or other link layer) header might 183 encapsulate an inner IP header as its payload. We call this a 184 tightly coupled shim over an encapsulating header. 186 Digging to arbitrary depths to find an inner IP header within an 187 encapsulation is strictly a layering violation so it cannot be a 188 required behaviour. Nonetheless, some tunnel endpoints already look 189 within a L2 header for an IP header, for instance to map the Diffserv 190 codepoint between an encapsulated IP header and an outer IP header 192 [RFC2983]. In such cases at least, it should be feasible to also 193 (independently) propagate the ECN field between the same IP headers. 194 Thus, access to the ECN field within an encapsulating header can be a 195 useful and benign optimization. The guidelines in section 5 of 196 [I-D.ietf-tsvwg-ecn-encap-guidelines] give the conditions for this 197 layering violation to be benign. 199 3.2. Desirability of ECN Propagation between Tunnel Headers 201 Developers and network operators are encouraged to implement and 202 deploy tunnel endpoints compliant with RFC 6040 (as updated by the 203 present specification) in order to provide the benefits of wider ECN 204 deployment [RFC8087]. Nonetheless, propagation of ECN between IP 205 headers, whether separated by shim headers or not, has to be optional 206 to implement and to use, because: 208 o Legacy implementations of tunnels without any ECN support already 209 exist 211 o A network might be designed so that there is usually no bottleneck 212 within the tunnel 214 o If the tunnel endpoints would have to search within an L2 header 215 to find an encapsulated IP header, it might not be worth the 216 potential performance hit 218 4. Making a non-ECN Tunnel Ingress Safe by Configuration 220 Even when no specific attempt has been made to implement propagation 221 of the ECN field at a tunnel ingress, it ought to be possible for the 222 operator to render a tunnel ingress safe by configuration. The main 223 safety concern is to disable (clear to zero) the ECN capability in 224 the outer IP header at the ingress if the egress of the tunnel does 225 not implement ECN logic to propagate any ECN markings into the packet 226 forwarded beyond the tunnel. Otherwise the non-ECN egress could 227 discard any ECN marking introduced within the tunnel, which would 228 break all the ECN-based control loops that regulate the traffic load 229 over the tunnel. 231 Therefore this specification updates RFC 6040 by inserting the 232 following text at the end of section 4.3: 234 " 235 Whether or not an ingress implementation claims compliance with 236 RFC 6040, RFC 4301 or RFC3168, when the outer tunnel header is IP 237 (v4 or v6), if possible, the operator MUST configure the ingress 238 to zero the outer ECN field in any of the following cases: 240 * if it is known that the tunnel egress does not support any of 241 the RFCs that define propagation of the ECN field (RFC 6040, 242 RFC 4301 or the full functionality mode of RFC 3168) 244 * or if the behaviour of the egress is not known or an egress 245 with unknown behaviour might be dynamically paired with the 246 ingress. 248 * or if an IP header might be encapsulated within a non-IP header 249 that the tunnel ingress is encapsulating, but the ingress does 250 not inspect within the encapsulation. 252 For the avoidance of doubt, the above only concerns the outer IP 253 header. The ingress MUST NOT alter the ECN field of the arriving 254 IP header that will become the inner IP header. 256 In order that the network operator can comply with the above 257 safety rules, even if an implementation of a tunnel ingress does 258 not claim to support RFC 6040, RFC 4301 or the full functionality 259 mode of RFC 3168: 261 * it MUST NOT treat the former ToS octet (IPv4) or the former 262 Traffic Class octet (IPv6) as a single 8-bit field, as the 263 resulting linkage of ECN and Diffserv field propagation between 264 inner and outer is not consistent with the definition of the 265 6-bit Diffserv field in [RFC2474] and [RFC3260]; 267 * it SHOULD be able to be configured to zero the ECN field of the 268 outer header. 270 " 272 For instance, if a tunnel ingress with no ECN-specific logic had a 273 configuration capability to refer to the last 2 bits of the old ToS 274 Byte of the outer (e.g. with a 0x3 mask) and set them to zero, while 275 also being able to allow the DSCP to be re-mapped independently, that 276 would be sufficient to satisfy both the above implementation 277 requirements. 279 There might be concern that the above "MUST NOT" makes compliant 280 implementations non-compliant at a stroke. However, by definition it 281 solely applies to equipment that provides Diffserv configuration. 282 Any such Diffserv equipment that is configuring treatment of the 283 former ToS octet (IPv4) or the former Traffic Class octet (IPv6) as a 284 single 8-bit field must have always been non-compliant with the 285 definition of the 6-bit Diffserv field in [RFC2474] and [RFC3260]. 286 If a tunnel ingress does not have any ECN logic, copying the ECN 287 field as a side-effect of copying the DSCP is a seriously unsafe bug 288 that risks breaking the feedback loops that regulate load on a 289 tunnel. 291 Zeroing the outer ECN field of all packets in all circumstances would 292 be safe, but it would not be sufficient to claim compliance with RFC 293 6040 because it would not meet the aim of introducing ECN support to 294 tunnels (see Section 4.3 of [RFC6040]). 296 5. ECN Propagation and Fragmentation/Reassembly 298 The following requirements update RFC6040, which omitted handling of 299 the ECN field during fragmentation or reassembly. These changes 300 might alter how many ECN-marked packets are propagated by a tunnel 301 that fragments packets, but this would not raise any backward 302 compatibility issues: 304 If a tunnel ingress fragments a packet, it MUST set the outer ECN 305 field of all the fragments to the same value as it would have set if 306 it had not fragmented the packet. 308 As a tunnel egress reassembles sets of outer fragments 309 [I-D.ietf-intarea-tunnels] into packets, it SHOULD propagate CE 310 markings on the basis that a congestion indication on a packet 311 applies to all the octets in the packet. On average, a tunnel egress 312 SHOULD approximately preserve the number of CE-marked and ECT(1)- 313 marked octets arriving and leaving (counting the size of inner 314 headers, but not encapsulating headers that are being stripped). 315 This process proceeds irrespective of the addresses on the inner 316 headers. 318 Even if only enough incoming CE-marked octets have arrived for part 319 of the departing packet, the next departing packet SHOULD be 320 immediately CE-marked. This ensures that CE-markings are propagated 321 immediately, rather than held back waiting for more incoming CE- 322 marked octets. Once there are no outstanding CE-marked octets, if 323 only enough incoming ECT(1)-marked octets have arrived for part of 324 the departing packet, the next departing packet SHOULD be immediately 325 marked ECT(1). 327 For instance, an algorithm for marking departing packets could 328 maintain a pair of counters, the first representing the balance of 329 arriving CE-marked octets minus departing CE-marked octets and the 330 second representing a similar balance of ECT(1)-marked octets. The 331 algorithm: 333 o adds the size of every CE-marked or ECT(1)-marked packet that 334 arrives to the appropriate counter; 336 o if the CE counter is positive, it CE-marks the next packet to 337 depart and subtracts its size from the CE counter; 339 o if the CE counter is negative but the ECT(1) counter is positive, 340 it marks the next packet to depart as ECT(1) and subtracts its 341 size from the ECT((1) counter; 343 o (the previous two steps will often leave a negative remainder in 344 the counters, which is deliberate); 346 o if neither counter is positive, it marks the next packet to depart 347 as ECT(0); 349 o until all the fragments of a packet have arrived, it does not 350 commit any updates to the counters so that, if reassembly fails 351 and the partly reassembled packet has to be discarded, none of the 352 discarded fragments will have updated any of the counters. 354 During reassembly of outer fragments [I-D.ietf-intarea-tunnels], if 355 the ECN fields of the outer headers being reassembled into a single 356 packet consist of a mixture of Not-ECT and other ECN codepoints, the 357 packet MUST be discarded. 359 A tunnel end-point that claims to support the present specification 360 MUST NOT use an approach that results in a significantly different 361 ECN-marking outcome to that defined by the "SHOULD" statements 362 throughout this section. "SHOULD" is only used to allow similar 363 perhaps more efficient approaches that result in approximately the 364 same outcome. 366 6. IP-in-IP Tunnels with Tightly Coupled Shim Headers 368 There follows a list of specifications of encapsulations with tightly 369 coupled shim header(s), in rough chronological order. The list is 370 confined to standards track or widely deployed protocols. The list 371 is not necessarily exhaustive so, for the avoidance of doubt, the 372 scope of RFC 6040 is defined in Section 3 and is not limited to this 373 list. 375 o PPTP (Point-to-Point Tunneling Protocol) [RFC2637]; 377 o L2TP (Layer 2 Tunnelling Protocol), specifically L2TPv2 [RFC2661] 378 and L2TPv3 [RFC3931], which not only includes all the L2-specific 379 specializations of L2TP, but also derivatives such as the Keyed 380 IPv6 Tunnel [RFC8159]; 382 o GRE (Generic Routing Encapsulation) [RFC2784] and NVGRE (Network 383 Virtualization using GRE) [RFC7637]; 385 o GTP (GPRS Tunnelling Protocol), specifically GTPv1 [GTPv1], GTP v1 386 User Plane [GTPv1-U], GTP v2 Control Plane [GTPv2-C]; 388 o Teredo [RFC4380]; 390 o CAPWAP (Control And Provisioning of Wireless Access Points) 391 [RFC5415]; 393 o LISP (Locator/Identifier Separation Protocol) [RFC6830]; 395 o AMT (Automatic Multicast Tunneling) [RFC7450]; 397 o VXLAN (Virtual eXtensible Local Area Network) [RFC7348] and VXLAN- 398 GPE [I-D.ietf-nvo3-vxlan-gpe]; 400 o The Network Service Header (NSH [RFC8300]) for Service Function 401 Chaining (SFC); 403 o Geneve [I-D.ietf-nvo3-geneve]; 405 o GUE (Generic UDP Encapsulation) [I-D.ietf-intarea-gue]; 407 o Direct tunnelling of an IP packet within a UDP/IP datagram (see 408 Section 3.1.11 of [RFC8085]); 410 o TCP Encapsulation of IKE and IPsec Packets (see Section 12.5 of 411 [RFC8229]). 413 Some of the listed protocols enable encapsulation of a variety of 414 network layer protocols as inner and/or outer. This specification 415 applies in the cases where there is an inner and outer IP header as 416 described in Section 3. Otherwise 417 [I-D.ietf-tsvwg-ecn-encap-guidelines] gives guidance on how to design 418 propagation of ECN into other protocols that might encapsulate IP. 420 Where protocols in the above list need to be updated to specify ECN 421 propagation and they are under IETF change control, update text is 422 given in the following subsections. For those not under IETF 423 control, it is RECOMMENDED that implementations of encapsulation and 424 decapsulation comply with RFC 6040. It is also RECOMMENDED that 425 their specifications are updated to add a requirement to comply with 426 RFC 6040 (as updated by the present document). 428 PPTP is not under the change control of the IETF, but it has been 429 documented in an informational RFC [RFC2637]. However, there is no 430 need for the present specification to update PPTP because L2TP has 431 been developed as a standardized replacement. 433 NVGRE is not under the change control of the IETF, but it has been 434 documented in an informational RFC [RFC7637]. NVGRE is a specific 435 use-case of GRE (it re-purposes the key field from the initial 436 specification of GRE [RFC1701] as a Virtual Subnet ID). Therefore 437 the text that updates GRE in Section 6.1.2 below is also intended to 438 update NVGRE. 440 Although the definition of the various GTP shim headers is under the 441 control of the 3GPP, it is hard to determine whether the 3GPP or the 442 IETF controls standardization of the _process_ of adding both a GTP 443 and an IP header to an inner IP header. Nonetheless, the present 444 specification is provided so that the 3GPP can refer to it from any 445 of its own specifications of GTP and IP header processing. 447 The specification of CAPWAP already specifies RFC 3168 ECN 448 propagation and ECN capability negotiation. Without modification the 449 CAPWAP specification already interworks with the backward compatible 450 updates to RFC 3168 in RFC 6040. 452 LISP made the ECN propagation procedures in RFC 3168 mandatory from 453 the start. RFC 3168 has since been updated by RFC 6040, but the 454 changes are backwards compatible so there is still no need for LISP 455 tunnel endpoints to negotiate their ECN capabilities. 457 VXLAN is not under the change control of the IETF but it has been 458 documented in an informational RFC. In contrast, VXLAN-GPE (Generic 459 Protocol Extension) is being documented under IETF change control. 460 It is RECOMMENDED that VXLAN and VXLAN-GPE implementations comply 461 with RFC 6040 when the VXLAN header is inserted between (or removed 462 from between) IP headers. The authors of any future update to these 463 specifications are encouraged to add a requirement to comply with RFC 464 6040 as updated by the present specification. 466 The Network Service Header (NSH [RFC8300]) has been defined as a 467 shim-based encapsulation to identify the Service Function Path (SFP) 468 in the Service Function Chaining (SFC) architecture [RFC7665]. A 469 proposal has been made for the processing of ECN when handling 470 transport encapsulation [I-D.ietf-sfc-nsh-ecn-support]. 472 The specifications of Geneve and GUE already refer to RFC 6040 for 473 ECN encapsulation. 475 Section 3.1.11 of RFC 8085 already explains that a tunnel that 476 encapsulates an IP header within a UDP/IP datagram needs to follow 477 RFC 6040 when propagating the ECN field between inner and outer IP 478 headers. The requirements in Section 4 update RFC 6040, and hence 479 implicitly update the UDP usage guidelines in RFC 8085 to add the 480 important but previously unstated requirement that, if the UDP tunnel 481 egress does not, or might not, support ECN propagation, a UDP tunnel 482 ingress has to clear the outer IP ECN field to 0b00, e.g. by 483 configuration. 485 Section 12.5 of TCP Encapsulation of IKE and IPsec Packets [RFC8229] 486 already recommends the compatibility mode of RFC 6040 in this case, 487 because there is not a one-to-one mapping between inner and outer 488 packets. 490 6.1. Specific Updates to Protocols under IETF Change Control 492 6.1.1. L2TP (v2 and v3) ECN Extension 494 The L2TP terminology used here is defined in [RFC2661] and [RFC3931]. 496 L2TPv3 [RFC3931] is used as a shim header between any packet-switched 497 network (PSN) header (e.g. IPv4, IPv6, MPLS) and many types of layer 498 2 (L2) header. The L2TPv3 shim header encapsulates an L2-specific 499 sub-layer then an L2 header that is likely to contain an inner IP 500 header (v4 or v6). Then this whole stack of headers can be 501 encapsulated optionally within an outer UDP header then an outer PSN 502 header that is typically IP (v4 or v6). 504 L2TPv2 is used as a shim header between any PSN header and a PPP 505 header, which is in turn likely to encapsulate an IP header. 507 Even though these shims are rather fat (particularly in the case of 508 L2TPv3), they still fit the definition of a tightly coupled shim 509 header over an encapsulating header (Section 3.1), because all the 510 headers encapsulating the L2 header are added (or removed) together. 511 L2TPv2 and L2TPv3 are therefore within the scope of RFC 6040, as 512 updated by Section 3 above. 514 L2TP maintainers are RECOMMENDED to implement the ECN extension to 515 L2TPv2 and L2TPv3 defined in Section 6.1.1.2 below, in order to 516 provide the benefits of ECN [RFC8087], whenever a node within an L2TP 517 tunnel becomes the bottleneck for an end-to-end traffic flow. 519 6.1.1.1. Safe Configuration of a 'Non-ECN' Ingress LCCE 521 The following text is appended to both Section 5.3 of [RFC2661] and 522 Section 4.5 of [RFC3931] as an update to the base L2TPv2 and L2TPv3 523 specifications: 525 The operator of an LCCE that does not support the ECN Extension in 526 Section 6.1.1.2 of RFCXXXX MUST follow the configuration 527 requirements in Section 4 of RFCXXXX to ensure it clears the outer 528 IP ECN field to 0b00 when the outer PSN header is IP (v4 or v6). 530 {RFCXXXX refers to the present document so it will need to be 531 inserted by the RFC Editor} 533 In particular, for an LCCE implementation that does not support the 534 ECN Extension, this means that configuration of how it propagates the 535 ECN field between inner and outer IP headers MUST be independent of 536 any configuration of the Diffserv extension of L2TP [RFC3308]. 538 6.1.1.2. ECN Extension for L2TP (v2 or v3) 540 When the outer PSN header and the payload inside the L2 header are 541 both IP (v4 or v6), to comply with RFC 6040, an LCCE will follow the 542 rules for propagation of the ECN field at ingress and egress in 543 Section 4 of RFC 6040 [RFC6040]. 545 Before encapsulating any data packets, RFC 6040 requires an ingress 546 LCCE to check that the egress LCCE supports ECN propagation as 547 defined in RFC 6040 or one of its compatible predecessors ([RFC4301] 548 or the full functionality mode of [RFC3168]). If the egress supports 549 ECN propagation, the ingress LCCE can use the normal mode of 550 encapsulation (copying the ECN field from inner to outer). 551 Otherwise, the ingress LCCE has to use compatibility mode [RFC6040] 552 (clearing the outer IP ECN field to 0b00). 554 An LCCE can determine the remote LCCE's support for ECN either 555 statically (by configuration) or by dynamic discovery during setup of 556 each control connection between the LCCEs, using the Capability AVP 557 defined in Section 6.1.1.2.1 below. 559 Where the outer PSN header is some protocol other than IP that 560 supports ECN, the appropriate ECN propagation specification will need 561 to be followed, e.g. "Explicit Congestion Marking in MPLS" 562 [RFC5129]. Where no specification exists for ECN propagation by a 563 particular PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives general 564 guidance on how to design ECN propagation into a protocol that 565 encapsulates IP. 567 6.1.1.2.1. LCCE Capability AVP for ECN Capability Negotiation 569 The LCCE Capability Attribute-Value Pair (AVP) defined here has 570 Attribute Type ZZ. The Attribute Value field for this AVP is a bit- 571 mask with the following 16-bit format: 573 0 1 574 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 |X X X X X X X X X X X X X X X E| 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 1: Value Field for the LCCE Capability Attribute 581 This AVP MAY be present in the following message types: SCCRQ and 582 SCCRP (Start-Control-Connection-Request and Start-Control-Connection- 583 Reply). This AVP MAY be hidden (the H-bit set to 0 or 1) and is 584 optional (M-bit not set). The length (before hiding) of this AVP 585 MUST be 8 octets. The Vendor ID is the IETF Vendor ID of 0. 587 Bit 15 of the Value field of the LCCE Capability AVP is defined as 588 the ECN Capability flag (E). When the ECN Capability flag is set to 589 1, it indicates that the sender supports ECN propagation. When the 590 ECN Capability flag is cleared to zero, or when no LCCE Capabiliy AVP 591 is present, it indicates that the sender does not support ECN 592 propagation. All the other bits are reserved. They MUST be cleared 593 to zero when sent and ignored when received or forwarded. 595 An LCCE initiating a control connection will send a Start-Control- 596 Connection-Request (SCCRQ) containing an LCCE Capability AVP with the 597 ECN Capability flag set to 1. If the tunnel terminator supports ECN, 598 it will return a Start-Control-Connection-Reply (SCCRP) that also 599 includes an LCCE Capability AVP with the ECN Capability flag set to 600 1. Then, for any sessions created by that control connection, both 601 ends of the tunnel can use the normal mode of RFC 6040, i.e. it can 602 copy the IP ECN field from inner to outer when encapsulating data 603 packets. 605 If, on the other hand, the tunnel terminator does not support ECN it 606 will ignore the ECN flag in the LCCE Capability AVP and send an SCCRP 607 to the tunnel initiator without a Capability AVP (or with a 608 Capability AVP but with the ECN Capability flag cleared to zero). 609 The tunnel initiator interprets the absence of the ECN Capability 610 flag in the SCCRP as an indication that the tunnel terminator is 611 incapable of supporting ECN. When encapsulating data packets for any 612 sessions created by that control connection, the tunnel initiator 613 will then use the compatibility mode of RFC 6040 to clear the ECN 614 field of the outer IP header to 0b00. 616 If the tunnel terminator does not support this ECN extension, the 617 network operator is still expected to configure it to comply with the 618 safety provisions set out in Section 6.1.1.1 above, when it acts as 619 an ingress LCCE. 621 6.1.2. GRE 623 The GRE terminology used here is defined in [RFC2784]. GRE is often 624 used as a tightly coupled shim header between IP headers. Sometimes 625 the GRE shim header encapsulates an L2 header, which might in turn 626 encapsulate an IP header. Therefore GRE is within the scope of RFC 627 6040 as updated by Section 3 above. 629 GRE tunnel endpoint maintainers are RECOMMENDED to support [RFC6040] 630 as updated by the present specification, in order to provide the 631 benefits of ECN [RFC8087] whenever a node within a GRE tunnel becomes 632 the bottleneck for an end-to-end IP traffic flow tunnelled over GRE 633 using IP as the delivery protocol (outer header). 635 GRE itself does not support dynamic set-up and configuration of 636 tunnels. However, control plane protocols such as Mobile IPv4 (MIP4) 637 [RFC5944], Mobile IPv6 (MIP6) [RFC6275], Proxy Mobile IP (PMIP) 638 [RFC5845] and IKEv2 [RFC7296] are sometimes used to set up GRE 639 tunnels dynamically. 641 When these control protocols set up IP-in-IP or IPSec tunnels, it is 642 likely that they propagate the ECN field as defined in RFC 6040 or 643 one of its compatible predecessors (RFC 4301 or the full 644 functionality mode of RFC 3168). However, if they use a GRE 645 encapsulation, this presumption is less sound. 647 Therefore, If the outer delivery protocol is IP (v4 or v6) the 648 operator is obliged to follow the safe configuration requirements in 649 Section 4 above. Section 6.1.2.1 below updates the base GRE 650 specification with this requirement, to emphasize its importance. 652 Where the delivery protocol is some protocol other than IP that 653 supports ECN, the appropriate ECN propagation specification will need 654 to be followed, e.g Explicit Congestion Marking in MPLS [RFC5129]. 655 Where no specification exists for ECN propagation by a particular 656 PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more general 657 guidance on how to propagate ECN to and from protocols that 658 encapsulate IP. 660 6.1.2.1. Safe Configuration of a 'Non-ECN' GRE Ingress 662 The following text is appended to Section 3 of [RFC2784] as an update 663 to the base GRE specification: 665 The operator of a GRE tunnel ingress MUST follow the configuration 666 requirements in Section 4 of RFCXXXX when the outer delivery 667 protocol is IP (v4 or v6). {RFCXXXX refers to the present document 668 so it will need to be inserted by the RFC Editor} 670 6.1.3. Teredo 672 Teredo [RFC4380] provides a way to tunnel IPv6 over an IPv4 network, 673 with a UDP-based shim header between the two. 675 For Teredo tunnel endpoints to provide the benefits of ECN, the 676 Teredo specification would have to be updated to include negotiation 677 of the ECN capability between Teredo tunnel endpoints. Otherwise it 678 would be unsafe for a Teredo tunnel ingress to copy the ECN field to 679 the IPv6 outer. 681 It is believed that current implementations do not support 682 propagation of ECN, but that they do safely zero the ECN field in the 683 outer IPv6 header. However the specification does not mention 684 anything about this. 686 To make existing Teredo deployments safe, it would be possible to add 687 ECN capability negotiation to those that are subject to remote OS 688 update. However, for those implementations not subject to remote OS 689 update, it will not be feasible to require them to be configured 690 correctly, because Teredo tunnel endpoints are generally deployed on 691 hosts. 693 Therefore, until ECN support is added to the specification of Teredo, 694 the only feasible further safety precaution available here is to 695 update the specification of Teredo implementations with the following 696 text, as a new section 5.1.3: 698 "5.1.3 Safe 'Non-ECN' Teredo Encapsulation 700 A Teredo tunnel ingress implementation that does not support ECN 701 propagation as defined in RFC 6040 or one of its compatible 702 predecessors (RFC 4301 or the full functionality mode of RFC 3168) 703 MUST zero the ECN field in the outer IPv6 header." 705 6.1.4. AMT 707 Automatic Multicast Tunneling (AMT [RFC7450]) is a tightly coupled 708 shim header that encapsulates an IP packet and is itself encapsulated 709 within a UDP/IP datagram. Therefore AMT is within the scope of RFC 710 6040 as updated by Section 3 above. 712 AMT tunnel endpoint maintainers are RECOMMENDED to support [RFC6040] 713 as updated by the present specification, in order to provide the 714 benefits of ECN [RFC8087] whenever a node within an AMT tunnel 715 becomes the bottleneck for an IP traffic flow tunnelled over AMT. 717 To comply with RFC 6040, an AMT relay and gateway will follow the 718 rules for propagation of the ECN field at ingress and egress 719 respectively, as described in Section 4 of RFC 6040 [RFC6040]. 721 Before encapsulating any data packets, RFC 6040 requires an ingress 722 AMT relay to check that the egress AMT gateway supports ECN 723 propagation as defined in RFC 6040 or one of its compatible 724 predecessors (RFC 4301 or the full functionality mode of RFC 3168). 725 If the egress gateway supports ECN, the ingress relay can use the 726 normal mode of encapsulation (copying the IP ECN field from inner to 727 outer). Otherwise, the ingress relay has to use compatibility mode, 728 which means it has to clear the outer ECN field to zero [RFC6040]. 730 An AMT tunnel is created dynamically (not manually), so the relay 731 will need to determine the remote gateway's support for ECN using the 732 ECN capability declaration defined in Section 6.1.4.2 below. 734 6.1.4.1. Safe Configuration of a 'Non-ECN' Ingress AMT Relay 736 The following text is appended to Section 4.2.2 of [RFC7450] as an 737 update to the AMT specification: 739 The operator of an AMT relay that does not support RFC 6040 or one 740 of its compatible predecessors (RFC 4301 or the full functionality 741 mode of RFC 3168) MUST follow the configuration requirements in 742 Section 4 of RFCXXXX to ensure it clears the outer IP ECN field to 743 zero. {RFCXXXX refers to the present document so it will need to 744 be inserted by the RFC Editor} 746 6.1.4.2. ECN Capability Declaration of an AMT Gateway 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | V=0 |Type=3 | Reserved |E|P| Reserved | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Request Nonce | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Figure 2: Updated AMT Request Message Format 758 Bit 14 of the AMT Request Message counting from 0 (or bit 7 of the 759 Reserved field counting from 1) is defined here as the AMT Gateway 760 ECN Capability flag (E), as shown in Figure 2. The definitions of 761 all other fields in the AMT Request Message are unchanged from RFC 762 7450. 764 When the E flag is set to 1, it indicates that the sender of the 765 message supports RFC 6040 ECN propagation. When it is cleared to 766 zero, it indicates the sender of the message does not support RFC 767 6040 ECN propagation. An AMT gateway "that supports RFC 6040 ECN 768 propagation" means one that propagates the ECN field to the forwarded 769 data packet based on the combination of arriving inner and outer ECN 770 fields, as defined in Section 4 of RFC 6040. 772 The other bits of the Reserved field remain reserved. They will 773 continue to be cleared to zero when sent and ignored when either 774 received or forwarded, as specified in Section 5.1.3.3. of RFC 7450. 776 An AMT gateway that does not support RFC 6040 MUST NOT set the E flag 777 of its Request Message to 1. 779 An AMT gateway that supports RFC 6040 ECN propagation MUST set the E 780 flag of its Relay Discovery Message to 1. 782 The action of the corresponding AMT relay that receives a Request 783 message with the E flag set to 1 depends on whether the relay itself 784 supports RFC 6040 ECN propagation: 786 o If the relay supports RFC 6040 ECN propagation, it will store the 787 ECN capability of the gateway along with its address. Then 788 whenever it tunnels datagrams towards this gateway, it MUST use 789 the normal mode of RFC 6040 to propagate the ECN field when 790 encapsulating datagrams (i.e. it copies the IP ECN field from 791 inner to outer). 793 o If the discovered AMT relay does not support RFC 6040 ECN 794 propagation, it will ignore the E flag in the Reserved field, as 795 per section 5.1.3.3. of RFC 7450. 797 If the AMT relay does not support RFC 6040 ECN propagation, the 798 network operator is still expected to configure it to comply with 799 the safety provisions set out in Section 6.1.4.1 above. 801 7. IANA Considerations 803 IANA is requested to assign the following L2TP Control Message 804 Attribute Value Pair: 806 +----------------+----------------+-----------+ 807 | Attribute Type | Description | Reference | 808 +----------------+----------------+-----------+ 809 | ZZ | ECN Capability | RFCXXXX | 810 +----------------+----------------+-----------+ 812 [TO BE REMOVED: This registration should take place at the following 813 location: https://www.iana.org/assignments/l2tp-parameters/l2tp- 814 parameters.xhtml ] 816 8. Security Considerations 818 The Security Considerations in [RFC6040] and 819 [I-D.ietf-tsvwg-ecn-encap-guidelines] apply equally to the scope 820 defined for the present specification. 822 9. Comments Solicited 824 Comments and questions are encouraged and very welcome. They can be 825 addressed to the IETF Transport Area working group mailing list 826 , and/or to the authors. 828 10. Acknowledgements 830 Thanks to Ing-jyh (Inton) Tsang for initial discussions on the need 831 for ECN propagation in L2TP and its applicability. Thanks also to 832 Carlos Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen 833 Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake 834 Holland and Sri Gundavelli for helpful advice and comments. "A 835 Comparison of IPv6-over-IPv4 Tunnel Mechanisms" [RFC7059] helped to 836 identify a number of tunnelling protocols to include within the scope 837 of this document. 839 Bob Briscoe was part-funded by the Research Council of Norway through 840 the TimeIn project. The views expressed here are solely those of the 841 authors. 843 11. References 845 11.1. Normative References 847 [I-D.ietf-tsvwg-ecn-encap-guidelines] 848 Briscoe, B., Kaippallimalil, J., and P. Thaler, 849 "Guidelines for Adding Congestion Notification to 850 Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- 851 encap-guidelines-13 (work in progress), May 2019. 853 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 854 Requirement Levels", BCP 14, RFC 2119, 855 DOI 10.17487/RFC2119, March 1997, 856 . 858 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 859 "Definition of the Differentiated Services Field (DS 860 Field) in the IPv4 and IPv6 Headers", RFC 2474, 861 DOI 10.17487/RFC2474, December 1998, 862 . 864 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 865 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 866 RFC 2661, DOI 10.17487/RFC2661, August 1999, 867 . 869 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 870 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 871 DOI 10.17487/RFC2784, March 2000, 872 . 874 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 875 of Explicit Congestion Notification (ECN) to IP", 876 RFC 3168, DOI 10.17487/RFC3168, September 2001, 877 . 879 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 880 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 881 RFC 3931, DOI 10.17487/RFC3931, March 2005, 882 . 884 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 885 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 886 December 2005, . 888 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 889 Network Address Translations (NATs)", RFC 4380, 890 DOI 10.17487/RFC4380, February 2006, 891 . 893 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 894 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 895 2008, . 897 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 898 Notification", RFC 6040, DOI 10.17487/RFC6040, November 899 2010, . 901 11.2. Informative References 903 [GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp 904 interface", Technical Specification TS 29.060. 906 [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling 907 Protocol User Plane (GTPv1-U)", Technical Specification TS 908 29.281. 910 [GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) 911 Tunnelling Protocol for Control plane (GTPv2-C)", 912 Technical Specification TS 29.274. 914 [I-D.ietf-intarea-gue] 915 Herbert, T., Yong, L., and O. Zia, "Generic UDP 916 Encapsulation", draft-ietf-intarea-gue-07 (work in 917 progress), March 2019. 919 [I-D.ietf-intarea-tunnels] 920 Touch, J. and M. Townsley, "IP Tunnels in the Internet 921 Architecture", draft-ietf-intarea-tunnels-09 (work in 922 progress), July 2018. 924 [I-D.ietf-nvo3-geneve] 925 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 926 Network Virtualization Encapsulation", draft-ietf- 927 nvo3-geneve-13 (work in progress), March 2019. 929 [I-D.ietf-nvo3-vxlan-gpe] 930 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 931 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-07 (work 932 in progress), April 2019. 934 [I-D.ietf-sfc-nsh-ecn-support] 935 Eastlake, D., Briscoe, B., and A. Malis, "Explicit 936 Congestion Notification (ECN) and Congestion Feedback 937 Using the Network Service Header (NSH)", draft-ietf-sfc- 938 nsh-ecn-support-01 (work in progress), July 2019. 940 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 941 Routing Encapsulation (GRE)", RFC 1701, 942 DOI 10.17487/RFC1701, October 1994, 943 . 945 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 946 W., and G. Zorn, "Point-to-Point Tunneling Protocol 947 (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, 948 . 950 [RFC2983] Black, D., "Differentiated Services and Tunnels", 951 RFC 2983, DOI 10.17487/RFC2983, October 2000, 952 . 954 [RFC3260] Grossman, D., "New Terminology and Clarifications for 955 Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, 956 . 958 [RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer 959 Two Tunneling Protocol (L2TP) Differentiated Services 960 Extension", RFC 3308, DOI 10.17487/RFC3308, November 2002, 961 . 963 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 964 Ed., "Control And Provisioning of Wireless Access Points 965 (CAPWAP) Protocol Specification", RFC 5415, 966 DOI 10.17487/RFC5415, March 2009, 967 . 969 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 970 "Generic Routing Encapsulation (GRE) Key Option for Proxy 971 Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010, 972 . 974 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 975 RFC 5944, DOI 10.17487/RFC5944, November 2010, 976 . 978 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 979 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 980 2011, . 982 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 983 Locator/ID Separation Protocol (LISP)", RFC 6830, 984 DOI 10.17487/RFC6830, January 2013, 985 . 987 [RFC7059] Steffann, S., van Beijnum, I., and R. van Rein, "A 988 Comparison of IPv6-over-IPv4 Tunnel Mechanisms", RFC 7059, 989 DOI 10.17487/RFC7059, November 2013, 990 . 992 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 993 Kivinen, "Internet Key Exchange Protocol Version 2 994 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 995 2014, . 997 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 998 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 999 eXtensible Local Area Network (VXLAN): A Framework for 1000 Overlaying Virtualized Layer 2 Networks over Layer 3 1001 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1002 . 1004 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 1005 DOI 10.17487/RFC7450, February 2015, 1006 . 1008 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 1009 Virtualization Using Generic Routing Encapsulation", 1010 RFC 7637, DOI 10.17487/RFC7637, September 2015, 1011 . 1013 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1014 Chaining (SFC) Architecture", RFC 7665, 1015 DOI 10.17487/RFC7665, October 2015, 1016 . 1018 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1019 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1020 March 2017, . 1022 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1023 Explicit Congestion Notification (ECN)", RFC 8087, 1024 DOI 10.17487/RFC8087, March 2017, 1025 . 1027 [RFC8159] Konstantynowicz, M., Ed., Heron, G., Ed., Schatzmayr, R., 1028 and W. Henderickx, "Keyed IPv6 Tunnel", RFC 8159, 1029 DOI 10.17487/RFC8159, May 2017, 1030 . 1032 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1033 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1034 August 2017, . 1036 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1037 "Network Service Header (NSH)", RFC 8300, 1038 DOI 10.17487/RFC8300, January 2018, 1039 . 1041 Author's Address 1043 Bob Briscoe 1044 Independent 1045 UK 1047 EMail: ietf@bobbriscoe.net 1048 URI: http://bobbriscoe.net/