idnits 2.17.1 draft-ietf-tsvwg-gre-in-udp-encap-15.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 18, 2016) is 2837 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) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Lucy Yong(Ed.) 2 Internet-Draft Huawei Technologies 3 Intended status: Standard Track E. Crabbe 4 Oracle 5 X. Xu 6 Huawei Technologies 7 T. Herbert 8 Facebook 10 Expires: January 2017 July 18, 2016 12 GRE-in-UDP Encapsulation 13 draft-ietf-tsvwg-gre-in-udp-encap-15 15 Abstract 17 This document specifies a method of encapsulating network protocol 18 packet within GRE and UDP headers. This GRE-in-UDP encapsulation 19 allows the UDP source port field to be used as an entropy field. 20 This may be used for load balancing of GRE traffic in transit 21 networks using existing ECMP mechanisms. This document also 22 specifies GRE-in-UDP tunnel requirements for two applicability 23 scenarios: (1) general Internet; (2) a traffic-managed controlled 24 environment. The controlled environment has less restrictive 25 requirements than the general Internet. 27 Status of This Document 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any 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 18,2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction...................................................3 62 1.1. Terminology...............................................4 63 1.2. Requirements Language.....................................4 64 2. Applicability Statement........................................4 65 2.1. GRE-in-UDP Tunnel Requirements............................5 66 2.1.1. Requirements for Default GRE-in-UDP Tunnel...........5 67 2.1.2. Requirements for TMCE GRE-in-UDP Tunnel..............6 68 3. GRE-in-UDP Encapsulation.......................................7 69 3.1. IP Header.................................................9 70 3.2. UDP Header................................................9 71 3.2.1. Source Port..........................................9 72 3.2.2. Destination Port....................................10 73 3.2.3. Checksum............................................10 74 3.2.4. Length..............................................10 75 3.3. GRE Header...............................................10 76 4. Encapsulation Process Procedures..............................11 77 4.1. MTU and Fragmentation....................................11 78 4.2. Differentiated Services and ECN Marking..................12 79 5. Use of DTLS...................................................12 80 6. UDP Checksum Handling.........................................13 81 6.1. UDP Checksum with IPv4...................................13 82 6.2. UDP Checksum with IPv6...................................13 83 7. Middlebox Considerations......................................16 84 7.1. Middlebox Considerations for Zero Checksums..............17 85 8. Congestion Considerations.....................................17 86 9. Backward Compatibility........................................18 87 10. IANA Considerations..........................................19 88 11. Security Considerations......................................20 89 12. Acknowledgements.............................................20 90 13. Contributors.................................................21 91 14. References...................................................22 92 14.1. Normative References....................................22 93 14.2. Informative References..................................23 94 15. Authors' Addresses...........................................24 96 1. Introduction 98 This document specifies a generic GRE-in-UDP encapsulation for 99 tunneling network protocol packets across an IP network. This 100 encapsulation uses Generic Routing Encapsulation (GRE) 101 [RFC2784][RFC7676] and User Datagram Protocol(UDP) [RFC768] headers. 102 The GRE header provides payload protocol type as an EtherType in the 103 protocol type field, and the source port field in the UDP header may 104 be used to provide additional entropy. 106 A GRE-in-UDP tunnel offers the possibility of better performance for 107 load balancing GRE traffic in transit networks using existing Equal- 108 Cost Multi-Path (ECMP) mechanisms. Existing ECMP mechanisms, when 109 the IP payload is a UDP or Transmission Control Protocol 110 (TCP)[RFC793] packet, frequently use of a hash of the five-tuple of 111 source IP address, destination IP address, UDP/TCP source port, 112 UDP/TCP destination port, and protocol/next-header. 114 A GRE-in-UDP tunnel also offers the possibility of using GRE across 115 networks that might otherwise disallow it; for instance GRE-in-UDP 116 may be used to bridge two islands where GRE is not supported 117 natively across the middleboxes. 119 GRE-in-UDP encapsulation may be used to encapsulate already tunneled 120 traffic, i.e. tunnel-in-tunnel. In this case, GRE-in-UDP tunnel do 121 not differentiate such end hosts from other end hosts, i.e., 122 applying the same treatment for traffic from hosts and tunnel 123 endpoints. 125 This document specifies GRE-in-UDP tunnel requirements for two 126 applicability scenarios: (1) general Internet; (2) a traffic-managed 127 controlled environment. The controlled environment has less 128 restrictive requirements than the general Internet. 130 The document also specifies Datagram Transport Layer Security (DTLS) 131 version of GRE-in-UDP tunnel to be used where/when security is a 132 concern. 134 GRE-in-UDP encapsulation usage requires no changes to the transit IP 135 network. Hash functions in most existing IP routers may utilize and 136 benefit from the use of a GRE-in-UDP tunnel without needing any 137 change or upgrade to their ECMP implementation. The encapsulation 138 mechanism is applicable to a variety of IP networks including Data 139 Center and wide area networks, IPv4 and IPv6 networks. 141 1.1. Terminology 143 The terms defined in [RFC768] and [RFC2784] are used in this 144 document. Following are additional terms used in this draft. 146 ECMP: Equal-Cost Multi-Path. 148 Flow Entropy: The information to be derived from traffic or 149 applications and to be used by network devices in ECMP process 150 [RFC6438]. 152 Default GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can apply to the 153 general Internet. 155 TMCE: A Traffic-managed controlled environment, i.e. an IP network 156 that is traffic-engineered and/or otherwise managed (e.g., via use 157 of traffic rate limiters) to avoid congestion, as defined in Section 158 2. 160 TMCE GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can only apply to a 161 traffic-managed controlled environment that is defined in Section 2. 163 1.2. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 2. Applicability Statement 171 GRE-in-UDP encapsulation as specified herein applies to IPv4 and 172 IPv6 networks. When using GRE-in-UDP encapsulation, packets so 173 encapsulated are treated as UDP datagrams by an IP network. As such, 174 a GRE-in-UDP tunnel needs to meet the UDP requirements specified in 175 [RFC5405bis], which imposes requirements on GRE-in-UDP tunnel usage. 176 These requirements depend on both the delivery network and the 177 nature of the encapsulated traffic. For example, the GRE-in-UDP 178 tunnel protocol does not provide any congestion control 179 functionality beyond that of the encapsulated traffic. Therefore, a 180 GRE-in-UDP tunnel MUST be used only with congestion controlled 181 traffic (e.g., IP unicast traffic) and/or within a network that has 182 traffic management capability to avoid congestion. 184 [RFC5405bis] considers two types of IETF UDP applications: 1) 185 General Internet and 2) A controlled environment. The controlled 186 environment means a single administrative domain or bilaterally 187 agreed connection between domains. A network forming a controlled 188 environment can be managed/operated to meet certain conditions while 189 the general Internet cannot be; thus the requirements for a tunnel 190 protocol operating under a controlled environment can be less 191 restrictive than the requirements in the general Internet. 193 For the purpose of this document, a traffic-managed controlled 194 environment is defined as an IP network that is traffic-engineered 195 and/or otherwise managed (e.g., via use of traffic rate limiters) to 196 avoid congestion. 198 This document specifies GRE-in-UDP tunnel usage in the general 199 Internet and GRE-in-UDP tunnel usage in a traffic-managed controlled 200 environment and uses "default GRE-in-UDP tunnel" and "TMCE GRE-in- 201 UDP tunnel" terms to refer to each usage. 203 2.1. GRE-in-UDP Tunnel Requirements 205 This section states out the requirements for a GRE-in-UDP tunnel. 206 Section 2.1.1 describes the requirements for a default GRE-in-UDP 207 tunnel that is suitable for the general Internet; Section 2.1.2 208 describes a set of relaxed requirements for a TMCE GRE-in-UDP tunnel 209 used in a traffic-managed controlled environment. Both Setions 2.1.1 210 and 2.1.2 are applicable to an IPv4 or IPv6 delivery network. 212 2.1.1. Requirements for Default GRE-in-UDP Tunnel 214 The following is a summary of the default GRE-in-UDP tunnel 215 requirements: 217 1. A UDP checksum SHOULD be used when encapsulating in IPv4. 219 2. A UDP checksum MUST be used when encapsulating in IPv6. 221 3. GRE-in-UDP tunnel MUST NOT be used for traffic that does not 222 implement congestion control. As stated in [RFC5405bis], IP-based 223 unicast traffic is generally assumed to be congestion-controlled, 224 i.e., it is assumed that the transport protocols generating IP-based 225 traffic at the sender already employ mechanisms that are sufficient 226 to address congestion on the path. GRE-in-UDP tunnels are not 227 appropriate for traffic that is not known to be congestion- 228 controlled (e.g., IP multicast traffic). 230 4. UDP source port values that are used as a source of flow entropy 231 SHOULD be chosen from the ephemeral port range (49152- 232 65535).[RFC5405bis] 233 5. The use of the UDP source port MUST be configurable so that a 234 single value can be set for all traffic within the tunnel (this 235 disables use of the UDP source port to provide flow entropy). When a 236 single value is set, a random port SHOULD be selected in order to 237 minimize the vulnerability to off-path attacks [RFC6056]. 239 6. For IPv6 delivery networks, the flow entropy SHOULD also be 240 placed in the flow label field for ECMP per [RFC6438]. 242 7. At the tunnel ingress, any fragmentation of the incoming packet 243 (e.g., because the tunnel has an MTU that is smaller than the packet) 244 SHOULD be performed before encapsulation. In addition, the tunnel 245 ingress MUST apply the UDP checksum to all encapsulated fragments so 246 that the tunnel egress can validate resemble of the fragments; it 247 MUST set the same DSCP value as in the DS field of the payload 248 packet in all fragments [RFC2474]. To avoid unwanted forwarding over 249 multiple paths, the same source UDP port value SHOULD be set in all 250 packet fragments. 252 2.1.2. Requirements for TMCE GRE-in-UDP Tunnel 254 The section contains the TMCE GRE-in-UDP tunnel requirements. It 255 lists the changed requirements, compared with a Default GRE-in-UDP 256 Tunnel, for a TMCE GRE-in-UDP Tunnel, which corresponds to the 257 requirements 1-3 listed in Section 2.1.1. 259 1. A UDP checksum SHOULD be used when encapsulating in IPv4. A 260 tunnel endpoint sending GRE-in-UDP MAY disable the UDP checksum, 261 since GRE has been designed to work without a UDP checksum [RFC2784]. 262 However, a checksum also offers protection from mis-delivery to 263 another port. 265 2. Use of UDP checksum MUST be the default when encapsulating in 266 IPv6. This default MAY be overridden via configuration of UDP zero- 267 checksum mode. All usage of UDP zero-checksum mode with IPv6 is 268 subject to the additional requirements specified in Section 6.2. 270 3. A GRE-in-UDP tunnel MAY encapsulate traffic that is not 271 congestion controlled. 273 The requirements 4-7 listed in Section 2.1.1 also apply to a TMCE 274 GRE-in-UDP Tunnel. 276 3. GRE-in-UDP Encapsulation 278 The GRE-in-UDP encapsulation format contains a UDP header [RFC768] 279 and a GRE header [RFC2890]. The format is shown as follows: 280 (presented in bit order) 282 0 1 2 3 283 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 285 IPv4 Header: 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |Version| IHL |Type of Service| Total Length | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Identification |Flags| Fragment Offset | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Time to Live |Protcol=17(UDP)| Header Checksum | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Source IPv4 Address | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Destination IPv4 Address | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 UDP Header: 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Source Port = Entropy Value | Dest. Port = TBD1/TBD2 | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | UDP Length | UDP Checksum | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 GRE Header: 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 |C| |K|S| Reserved0 | Ver | Protocol Type | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Checksum (optional) | Reserved1 (Optional) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Key (optional) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Sequence Number (optional) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 1 UDP+GRE Headers in IPv4 318 0 1 2 3 319 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 321 IPv6 Header: 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 |Version| Traffic Class | Flow Label | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 + + 329 | | 330 + Outer Source IPv6 Address + 331 | | 332 + + 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 + + 337 | | 338 + Outer Destination IPv6 Address + 339 | | 340 + + 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 UDP Header: 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Source Port = entropy value | Dest. Port = TBD1/TBD2 | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | UDP Length | UDP Checksum | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 GRE Header: 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 |C| |K|S| Reserved0 | Ver | Protocol Type | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Checksum (optional) | Reserved1 (Optional) | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Key (optional) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Sequence Number (optional) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 2 UDP+GRE Headers in IPv6 364 The contents of the IP, UDP, and GRE headers that are relevant in 365 this encapsulation are described below. 367 3.1. IP Header 369 An encapsulator MUST encode its own IP address as the source IP 370 address and the decapsulator's IP address as the destination IP 371 address. A sufficiently large value is needed in the IPv4 TTL field 372 or IPv6 Hop Count field to allow delivery of the encapsulated packet 373 to the peer of the encapsulation. 375 3.2. UDP Header 377 3.2.1. Source Port 379 GRE-in-UDP permits the UDP source port value to be used to encode an 380 entropy value. The UDP source port contains a 16-bit entropy value 381 that is generated by the encapsulator to identify a flow for the 382 encapsulated packet. The port value SHOULD be within the ephemeral 383 port range, i.e., 49152 to 65535, where the high order two bits of 384 the port are set to one. This provides fourteen bits of entropy for 385 the inner flow identifier. In the case that an encapsulator is 386 unable to derive flow entropy from the payload header or the entropy 387 usage has to be disabled to meet operational requirements (see 388 Section 7), to avoid reordering with a packet flow, the encapsulator 389 SHOULD use the same UDP source port value for all packets assigned 390 to a flow e.g., the result of an algorithm that perform a hash of 391 the tunnel ingress and egress IP address. 393 The source port value for a flow set by an encapsulator MAY change 394 over the lifetime of the encapsulated flow. For instance, an 395 encapsulator may change the assignment for Denial of Service (DOS) 396 mitigation or as a means to effect routing through the ECMP network. 397 An encapsulator SHOULD NOT change the source port selected for a 398 flow more than once every thirty seconds. 400 An IPv6 GRE-in-UDP tunnel endpoint should copy a flow entropy value 401 in the IPv6 flow label field (requirement 6). This permits network 402 equipment to inspect this value and utilize it during forwarding, 403 e.g. to perform ECMP [RFC6438]. 405 This document places requirements on the generation of the flow 406 entropy value [RFC5405bis] but does not specify the algorithm that 407 an implementation should use to derive this value. 409 3.2.2. Destination Port 411 The destination port of the UDP header is set either GRE-in-UDP 412 (TBD1) or GRE-UDP-DTLS (TBD2) (see Section 5). 414 3.2.3. Checksum 416 The UDP checksum is set and processed per [RFC768] and [RFC1122] for 417 IPv4, and [RFC2460] for IPv6. Requirements for checksum handling and 418 use of zero UDP checksums are detailed in Section 6. 420 3.2.4. Length 422 The usage of this field is in accordance with the current UDP 423 specification in [RFC768]. This length will include the UDP header 424 (eight bytes), GRE header, and the GRE payload (encapsulated packet). 426 3.3. GRE Header 428 An encapsulator sets the protocol type (EtherType) of the packet 429 being encapsulated in the GRE Protocol Type field. 431 An encapsulator MAY set the GRE Key Present, Sequence Number Present, 432 and Checksum Present bits and associated fields in the GRE header as 433 defined by [RFC2784] and [RFC2890]. Usage of the reserved bits, i.e., 434 Reserved0, is specified in [RFC2784]. 436 The GRE checksum MAY be enabled to protect the GRE header and 437 payload. When the UDP checksum is enabled, it protects the GRE 438 payload, resulting in the GRE checksum being mostly redundant. 439 Enabling both checksums may result in unnecessary processing. Since 440 the UDP checksum covers the pseudo-header and the packet payload, 441 including the GRE header and its payload, the UDP checksum SHOULD be 442 used in preference to using the GRE checksum. 444 An implementation MAY use the GRE keyid to authenticate the 445 encapsulator.(See Security Considerations Section) In this model, a 446 shared value is either configured or negotiated between an 447 encapsulator and decapsulator. When a decapsulator determines a 448 presented keyid is not valid for the source, the packet MUST be 449 dropped. 451 Although GRE-in-UDP encapsulation protocol uses both UDP header and 452 GRE header, it is one tunnel encapsulation protocol. GRE and UDP 453 headers MUST be applied and removed as a pair at the encapsulation 454 and decapsulation points. This specification does not support UDP 455 encapsulation of a GRE header where that GRE header is applied or 456 removed at a network node other than the UDP tunnel ingress or 457 egress. 459 4. Encapsulation Process Procedures 461 The procedures specified in this section apply to both a default 462 GRE-in-UDP tunnel and a TMCE GRE-in-UDP tunnel. 464 The GRE-in-UDP encapsulation allows encapsulated packets to be 465 forwarded through "GRE-in-UDP tunnels". The encapsulator MUST set 466 the UDP and GRE header according to Section 3. 468 Intermediate routers, upon receiving these UDP encapsulated packets, 469 could load balance these packets based on the hash of the five-tuple 470 of UDP packets. 472 Upon receiving these UDP encapsulated packets, the decapsulator 473 decapsulates them by removing the UDP and GRE headers and then 474 processes them accordingly. 476 GRE-in-UDP allows encapsulation of unicast, IPv4 broadcast, or 477 multicast traffic. Entropy may be generated from the header of 478 encapsulated packets at an encapsulator. The mapping mechanism 479 between the encapsulated multicast traffic and the multicast 480 capability in the IP network is transparent and independent of the 481 encapsulation and is otherwise outside the scope of this document. 483 To provide entropy for ECMP, GRE-in-UDP does not rely on GRE keep- 484 alive. It is RECOMMENED not to use GRE keep-alive in the GRE-in-UDP 485 tunnel. This aligns with middlebox traversal guidelines in Section 486 3.5 of [RFC5405bis]. 488 4.1. MTU and Fragmentation 490 Regarding packet fragmentation, an encapsulator/decapsulator SHOULD 491 perform fragmentation before the encapsulation. The size of 492 fragments SHOULD be less or equal to the PMTU associated with the 493 path between the GRE ingress and the GRE egress tunnel endpoints 494 minus the GRE and UDP overhead, assuming the egress resemble MTU is 495 larger than PMTU. When applying payload fragmentation, the UDP 496 checksum MUST be used so that the receiving endpoint can validate 497 resemble of the fragments; the same source UDP port SHOULD be used 498 for all packet fragments to ensure the transit routers will forward 499 the fragments on the same path. 501 If the operator of the transit network supporting the tunnel is able 502 to control the payload MTU size, the MTU SHOULD be configured to 503 avoid fragmentation, i.e., sufficient for the largest supported size 504 of packet, including all additional bytes introduced by the tunnel 505 overhead [RFC5405bis]. 507 4.2. Differentiated Services and ECN Marking 509 To ensure that tunneled traffic receives the same treatment over the 510 IP network as traffic that is not tunneled, prior to the 511 encapsulation process, an encapsulator processes the tunneled IP 512 packet headers to retrieve appropriate parameters for the 513 encapsulating IP packet header such as DiffServ [RFC2983]. 514 Encapsulation end points that support Explicit Congestion 515 Notification (ECN) must use the method described in [RFC6040] for 516 ECN marking propagation. The congestion control process is outside 517 of the scope of this document. 519 Additional information on IP header processing is provided in 520 Section 3.1. 522 5. Use of DTLS 524 Datagram Transport Layer Security (DTLS) [RFC6347] can be used for 525 application security and can preserve network and transport layer 526 protocol information. Specifically, if DTLS is used to secure the 527 GRE-in-UDP tunnel, the destination port of the UDP header MUST be 528 set to an IANA-assigned value (TBD2) indicating GRE-in-UDP with DTLS, 529 and that UDP port MUST NOT be used for other traffic. The UDP source 530 port field can still be used to add entropy, e.g., for load-sharing 531 purposes. DTLS applies to a default GRE-in-UDP tunnel and a TMCE 532 GRE-in-UDP tunnel. 534 Use of DTLS is limited to a single DTLS session for any specific 535 tunnel encapsulator/decapsulator pair (identified by source and 536 destination IP addresses). Both IP addresses MUST be unicast 537 addresses - multicast traffic is not supported when DTLS is used. A 538 GRE-in-UDP tunnel decapsulator that supports DTLS is expected to be 539 able to establish DTLS sessions with multiple tunnel encapsulators, 540 and likewise a GRE-in-UDP tunnel encapsulator is expected to be able 541 to establish DTLS sessions with multiple decapsulators. Different 542 source and/or destination IP addresses will be involved (see Section 543 6.2) for discussion of one situation where use of different source 544 IP addresses is important. 546 If the traffic to be encapsulated is already encrypted, it is 547 usually not necessary to encrypt it again. Applying DTLS to GRE-in- 548 UDP tunnel requires both tunnel end points to configure use of DTLS. 550 6. UDP Checksum Handling 552 6.1. UDP Checksum with IPv4 554 For UDP in IPv4, the UDP checksum MUST be processed as specified in 555 [RFC768] and [RFC1122] for both transmit and receive. The IPv4 556 header includes a checksum that protects against mis-delivery of the 557 packet due to corruption of IP addresses. The UDP checksum 558 potentially provides protection against corruption of the UDP header, 559 GRE header, and GRE payload. Disabling the use of checksums is a 560 deployment consideration that should take into account the risk and 561 effects of packet corruption. 563 When a decapsulator receives a packet, the UDP checksum field MUST 564 be processed. If the UDP checksum is non-zero, the decapsulator MUST 565 verify the checksum before accepting the packet. By default a 566 decapsulator SHOULD accept UDP packets with a zero checksum. A node 567 MAY be configured to disallow zero checksums per [RFC1122]; this may 568 be done selectively, for instance disallowing zero checksums from 569 certain hosts that are known to be sending over paths subject to 570 packet corruption. If verification of a non-zero checksum fails, a 571 decapsulator lacks the capability to verify a non-zero checksum, or 572 a packet with a zero-checksum was received and the decapsulator is 573 configured to disallow, the packet MUST be dropped and an event MAY 574 be logged. 576 6.2. UDP Checksum with IPv6 578 For UDP in IPv6, the UDP checksum MUST be processed as specified in 579 [RFC768] and [RFC2460] for both transmit and receive. 581 When UDP is used over IPv6, the UDP checksum is relied upon to 582 protect both the IPv6 and UDP headers from corruption. As such, A 583 default GRE-in-UDP Tunnel MUST perform UDP checksum; A TMCE GRE-in- 584 UDP Tunnel MAY be configured with the UDP zero-checksum mode if the 585 traffic-managed controlled environment or a set of closely 586 cooperating traffic-managed controlled environments (such as by 587 network operators who have agreed to work together in order to 588 jointly provide specific services) meet at least one of following 589 conditions: 591 a. It is known (perhaps through knowledge of equipment types and 592 lower layer checks) that packet corruption is exceptionally 593 unlikely and where the operator is willing to take the risk of 594 undetected packet corruption. 596 b. It is judged through observational measurements (perhaps of 597 historic or current traffic flows that use a non-zero checksum) 598 that the level of packet corruption is tolerably low and where 599 the operator is willing to take the risk of undetected packet 600 corruption. 602 c. Carrying applications that are tolerant of mis-delivered or 603 corrupted packets (perhaps through higher layer checksum, 604 validation, and retransmission or transmission redundancy) where 605 the operator is willing to rely on the applications using the 606 tunnel to survive any corrupt packets. 608 The following requirements apply to a TMCE GRE-in-UDP tunnel that 609 uses UDP zero-checksum mode: 611 a. Use of the UDP checksum with IPv6 MUST be the default 612 configuration of all GRE-in-UDP tunnels. 614 b. The GRE-in-UDP tunnel implementation MUST comply with all 615 requirements specified in Section 4 of [RFC6936] and with 616 requirement 1 specified in Section 5 of [RFC6936]. 618 c. The tunnel decapsulator SHOULD only allow the use of UDP zero- 619 checksum mode for IPv6 on a single received UDP Destination 620 Port regardless of the encapsulator. The motivation for this 621 requirement is possible corruption of the UDP Destination Port, 622 which may cause packet delivery to the wrong UDP port. If that 623 other UDP port requires the UDP checksum, the mis-delivered 624 packet will be discarded. 626 d. It is RECOMMENDED that the UDP zero-checksum mode for IPv6 is 627 only enabled for certain selected source addresses. The tunnel 628 decapsulator MUST check that the source and destination IPv6 629 addresses are valid for the GRE-in-UDP tunnel on which the 630 packet was received if that tunnel uses UDP zero-checksum mode 631 and discard any packet for which this check fails. 633 e. The tunnel encapsulator SHOULD use different IPv6 addresses for 634 each GRE-in-UDP tunnel that uses UDP zero-checksum mode 635 regardless of the decapsulator in order to strengthen the 636 decapsulator's check of the IPv6 source address (i.e., the same 637 IPv6 source address SHOULD NOT be used with more than one IPv6 638 destination address, independent of whether that destination 639 address is a unicast or multicast address). When this is not 640 possible, it is RECOMMENDED to use each source IPv6 address for 641 as few UDP zero-checksum mode GRE-in-UDP tunnels as is feasible. 643 f. When any middlebox exists on the path of a GRE-in-UDP tunnel, 644 it is RECOMMENDED to use the default mode, i.e. use UDP 645 checksum, to reduce the chance that the encapsulated packets 646 will be dropped. 648 g. Any middlebox that allows the UDP zero-checksum mode for IPv6 649 MUST comply with requirement 1 and 8-10 in Section 5 of 650 [RFC6936]. 652 h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP 653 checksums from "escaping" to the general Internet; see Section 654 8 for examples of such measures. 656 i. IPv6 traffic with zero UDP checksums MUST be actively monitored 657 for errors by the network operator. For example, the operator 658 may monitor Ethernet layer packet error rates. 660 j. If a packet with a non-zero checksum is received, the checksum 661 MUST be verified before accepting the packet. This is 662 regardless of whether the tunnel encapsulator and decapsulator 663 have been configured with UDP zero-checksum mode. 665 The above requirements do not change either the requirements 666 specified in [RFC2460] as modified by [RFC6935] or the requirements 667 specified in [RFC6936]. 669 The requirement to check the source IPv6 address in addition to the 670 destination IPv6 address, plus the strong recommendation against 671 reuse of source IPv6 addresses among GRE-in-UDP tunnels collectively 672 provide some mitigation for the absence of UDP checksum coverage of 673 the IPv6 header. A traffic-managed controlled environment that 674 satisfies at least one of three conditions listed at the beginning 675 of this section provides additional assurance. 677 A GRE-in-UDP tunnel is suitable for transmission over lower layers 678 in the traffic-managed controlled environments that are allowed by 679 the exceptions stated above and the rate of corruption of the inner 680 IP packet on such networks is not expected to increase by comparison 681 to GRE traffic that is not encapsulated in UDP. For these reasons, 682 GRE-in-UDP does not provide an additional integrity check except 683 when GRE checksum is used when UDP zero-checksum mode is used with 684 IPv6, and this design is in accordance with requirements 2, 3 and 5 685 specified in Section 5 of [RFC6936]. 687 Generic Router Encapsulation (GRE) does not accumulate incorrect 688 transport layer state as a consequence of GRE header corruption. A 689 corrupt GRE packet may result in either packet discard or forwarding 690 of the packet without accumulation of GRE state. Active monitoring 691 of GRE-in-UDP traffic for errors is REQUIRED as occurrence of errors 692 will result in some accumulation of error information outside the 693 protocol for operational and management purposes. This design is in 694 accordance with requirement 4 specified in Section 5 of [RFC6936]. 696 The remaining requirements specified in Section 5 of [RFC6936] are 697 not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply 698 because GRE does not include a control feedback mechanism. 699 Requirements 8-10 are middlebox requirements that do not apply to 700 GRE-in-UDP tunnel endpoints (see Section 7.1 for further middlebox 701 discussion). 703 It is worth mentioning that the use of a zero UDP checksum should 704 present the equivalent risk of undetected packet corruption when 705 sending similar packet using GRE-in-IPv6 without UDP [RFC7676] and 706 without GRE checksums. 708 In summary, a TMCE GRE-in-UDP Tunnel is allowed to use UDP-zero- 709 checksum mode for IPv6 when the conditions and requirements stated 710 above are met. Otherwise the UDP checksum need to be used for IPv6 711 as specified in [RFC768] and [RFC2460]. Use of GRE checksum is 712 RECOMMENED when the UDP checksum is not used. 714 7. Middlebox Considerations 716 Many middleboxes read or update UDP port information of the packets 717 that they forward. Network Address/Port Translator (NAPT) is the 718 most commonly deployed Network Address Translation (NAT) device 719 [RFC4787]. An NAPT device establishes a NAT session to translate the 720 {private IP address, private source port number} tuple to a {public 721 IP address, public source port number} tuple, and vice versa, for 722 the duration of the UDP session. This provides a UDP application 723 with the "NAT-pass-through" function. NAPT allows multiple internal 724 hosts to share a single public IP address. The port number, i.e., 725 the UDP Source Port number, is used as the demultiplexer of the 726 multiple internal hosts. However, the above NAPT behaviors conflict 727 with the behavior a GRE-in-UDP tunnel that is configured to use the 728 UDP source port value to provide entropy. 730 A GRE-in-UDP tunnel is unidirectional; the tunnel traffic is not 731 expected to be returned back to the UDP source port values used to 732 generate entropy. However some middleboxes (e.g., firewall) assume 733 that bidirectional traffic uses a common pair of UDP ports. This 734 assumption also conflicts with the use of the UDP source port field 735 as entropy. 737 Hence, use of the UDP source port for entropy may impact middleboxes 738 behavior. If a GRE-in-UDP tunnel is expected to be used on a path 739 with a middlebox, the tunnel can be configured to either disable use 740 of the UDP source port for entropy or to configure middleboxes to 741 pass packets with UDP source port entropy. 743 7.1. Middlebox Considerations for Zero Checksums 745 IPv6 datagrams with a zero UDP checksum will not be passed by any 746 middlebox that validates the checksum based on [RFC2460] or that 747 updates the UDP checksum field, such as NATs or firewalls. Changing 748 this behavior would require such middleboxes to be updated to 749 correctly handle datagrams with zero UDP checksums. The GRE-in-UDP 750 encapsulation does not provide a mechanism to safely fall back to 751 using a checksum when a path change occurs redirecting a tunnel over 752 a path that includes a middlebox that discards IPv6 datagrams with a 753 zero UDP checksum. In this case the GRE-in-UDP tunnel will be black- 754 holed by that middlebox. 756 As such, when any middlebox exists on the path of GRE-in-UDP tunnel, 757 use of the UDP checksum is RECOMMENDED to increase the probability 758 of successful transmission of GRE-in-UDP packets. Recommended 759 changes to allow firewalls, NATs and other middleboxes to support 760 use of an IPv6 zero UDP checksum are described in Section 5 of 761 [RFC6936]. 763 8. Congestion Considerations 765 Section 3.1.9 of [RFC5405bis] discusses the congestion 766 considerations for design and use of UDP tunnels; this is important 767 because other flows could share the path with one or more UDP 768 tunnels, necessitating congestion control [RFC2914] to avoid 769 distractive interference. 771 Congestion has potential impacts both on the rest of the network 772 containing a UDP tunnel, and on the traffic flows using the UDP 773 tunnels. These impacts depend upon what sort of traffic is carried 774 over the tunnel, as well as the path of the tunnel. 776 A default GRE-in-UDP tunnel MAY be used to carry IP traffic that is 777 known to be congestion controlled on the Internet. IP unicast 778 traffic is generally assumed to be congestion-controlled. A default 779 GRE-in-UDP tunnel MUST NOT be used to carry traffic that is not 780 known to be congestion-controlled. 782 A TMCE GRE-in-UDP tunnel can be used to carry traffic that is known 783 not to be congestion controlled. For example, GRE-in-UDP may be used 784 to carry MPLS that carries pseudowire or VPN traffic where specific 785 bandwidth guarantees are provided to each pseudowire or to each VPN. 786 In such cases, network operators may avoid congestion by careful 787 provisioning of their networks, by rate limiting of user data 788 traffic, and traffic engineering according to path capacity. 790 When a TMCE GRE-in-UDP tunnel carries traffic that is not known to 791 be congestion controlled, the tunnel MUST be used within a traffic- 792 managed controlled environment (e.g., single operator network that 793 utilizes careful provisioning such as rate limiting at the entries 794 of the network while over-provisioning network capacity) to manage 795 congestion, or within a limited number of networks whose operators 796 closely cooperate in order to jointly provide this same careful 797 provisioning. When a TMCE GRE-in-UDP tunnel is used to carry the 798 traffic that is not known to be congestion controlled, measures 799 SHOULD be taken to prevent the GRE-in-UDP traffic from "escaping" to 800 the general Internet, e.g.: 802 o Physical or logical isolation of the links carrying GRE-in-UDP 803 from the general Internet. 805 o Deployment of packet filters that block the UDP ports assigned 806 for GRE-in-UDP. 808 o Imposition of restrictions on GRE-in-UDP traffic by software 809 tools used to set up GRE-in-UDP tunnels between specific end 810 systems (as might be used within a single data center) or by 811 tunnel ingress nodes for tunnels that don't terminate at end 812 systems. 814 o Use of a "Circuit Breaker" for the tunneled traffic as described 815 in [CB]. 817 9. Backward Compatibility 819 In general, tunnel ingress routers have to be upgraded in order to 820 support the encapsulations described in this document. 822 No change is required at transit routers to support forwarding of 823 the encapsulation described in this document. 825 If a tunnel endpoint (a host or router) that is intended for use as 826 a decapsulator does not support or enable the GRE-in-UDP 827 encapsulation described in this document, that endpoint will not 828 listen on the destination port assigned to the GRE-encapsulation 829 (TBD1 and TBD2). In these cases, the endpoint will perform normal 830 UDP processing and respond to an encapsulator with an ICMP message 831 indicating "port unreachable" according to [RFC792]. Upon receiving 832 this ICMP message, the node MUST NOT continue to use GRE-in-UDP 833 encapsulation toward this peer without management intervention. 835 10. IANA Considerations 837 IANA is requested to make the following allocations: 839 One UDP destination port number for the indication of GRE, 841 Service Name: GRE-in-UDP 842 Transport Protocol(s): UDP 843 Assignee: IESG 844 Contact: IETF Chair 845 Description: GRE-in-UDP Encapsulation 846 Reference: [This.I-D] 847 Port Number: TBD1 848 Service Code: N/A 849 Known Unauthorized Uses: N/A 850 Assignment Notes: N/A 852 Editor Note: replace "TBD1" in section 3 and 9 with IANA assigned 853 number. 855 One UDP destination port number for the indication of GRE with DTLS, 857 Service Name: GRE-UDP-DTLS 858 Transport Protocol(s): UDP 859 Assignee: IESG 860 Contact: IETF Chair 861 Description: GRE-in-UDP Encapsulation with DTLS 862 Reference: [This.I-D] 863 Port Number: TBD2 864 Service Code: N/A 865 Known Unauthorized Uses: N/A 866 Assignment Notes: N/A 868 Editor Note: replace "TBD2" in section 3, 5, and 9 with IANA 869 assigned number. 871 11. Security Considerations 873 GRE-in-UDP encapsulation does not affect security for the payload 874 protocol. The security considerations for GRE apply to GRE-in-UDP, 875 see [RFC2784]. 877 To secure original traffic, DTLS SHOULD be used as specified in 878 Section 5. 880 In the case that UDP source port for entropy usage is disabled, a 881 random port SHOULD be selected in order to minimize the 882 vulnerability to off-path attacks.[RFC6056] The random port may also 883 be periodically changed to mitigate certain denial of service 884 attacks as mentioned in Section 3.2.1. 886 Using one standardized value as the UDP destination port to indicate 887 an encapsulation may increase the vulnerability of off-path attack. 888 To overcome this, an alternate port may be agreed upon to use 889 between an encapsulator and decapsulator [RFC6056]. How the 890 encapsulator end points communicate the value is outside scope of 891 this document. 893 This document does not require that a decapsulator validates the IP 894 source address of the tunneled packets (with the exception that the 895 IPv6 source address MUST be validated when UDP zero-checksum mode is 896 used with IPv6), but it should be understood that failure to do so 897 presupposes that there is effective destination-based (or a 898 combination of source-based and destination-based) filtering at the 899 boundaries. 901 Corruption of a GRE header can cause a privacy and security concern 902 for some applications that rely on the key field for traffic 903 segregation. When the GRE key field is used for privacy and security, 904 ether UDP checksum or GRE checksum SHOULD be used for GRE-in-UDP 905 with both IPv4 and IPv6, and in particular, when UDP zero-checksum 906 mode is used, GRE checksum SHOULD be used. 908 12. Acknowledgements 910 Authors like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger 911 Geib, Lar Edds, Lloyd Wood, Bob Briscoe, and many others for their 912 review and valuable input on this draft. 914 Thank Donald Eastlake, Eliot Lear, Martin Stiemerling, and Spencer 915 Dawkins for their detail reviews and valuable suggestions in WGLC 916 and IESG process. 918 Thank the design team led by David Black (members: Ross Callon, 919 Gorry Fairhurst, Xiaohu Xu, Lucy Yong) to efficiently work out the 920 descriptions for the congestion considerations and IPv6 UDP zero 921 checksum. 923 Thank David Black and Gorry Fairhurst for their great help in 924 document content and editing. 926 13. Contributors 928 The following people all contributed significantly to this document 929 and are listed below in alphabetical order: 931 David Black 932 EMC Corporation 933 176 South Street 934 Hopkinton, MA 01748 935 USA 937 Email: david.black@emc.com 939 Ross Callon 940 Juniper Networks 941 10 Technology Park Drive 942 Westford, MA 01886 943 USA 945 Email: rcallon@juniper.net 947 John E. Drake 948 Juniper Networks 950 Email: jdrake@juniper.net 952 Gorry Fairhurst 953 University of Aberdeen 955 Email: gorry@erg.abdn.ac.uk 956 Yongbing Fan 957 China Telecom 958 Guangzhou, China. 959 Phone: +86 20 38639121 961 Email: fanyb@gsta.com 963 Adrian Farrel 964 Juniper Networks 966 Email: adrian@olddog.co.uk 968 Vishwas Manral 969 Hewlett-Packard Corp. 970 3000 Hanover St, Palo Alto. 972 Email: vishwas.manral@hp.com 974 Carlos Pignataro 975 Cisco Systems 976 7200-12 Kit Creek Road 977 Research Triangle Park, NC 27709 USA 979 EMail: cpignata@cisco.com 981 14. References 983 14.1. Normative References 985 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 986 August 1980. 988 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 989 Communication Layers", RFC1122, October 1989. 991 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 992 Requirement Levels", BCP 14, RFC2119, March 1997. 994 [RFC2474] Nichols K., Blake S., Baker F., Black D., "Definition of 995 the Differentiated Services Field (DS Field) in the IPv4 996 and IPv6 Headers", December 1998. 998 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 999 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1000 March 2000. 1002 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 1003 RFC2890, September 2000. 1005 [RFC5405bis] Eggert, L., "Unicast UDP Usage Guideline for 1006 Application Designers", draft-ietf-tsvwg-rfc5405bis, work 1007 in progress. 1009 [RFC6040] Briscoe, B., "Tunneling of Explicit Congestion 1010 Notification", RFC6040, November 2010. 1012 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 1013 Security Version 1.2", RFC6347, 2012. 1015 [RFC6438] Carpenter, B., Amante, S., "Using the IPv6 Flow Label for 1016 Equal Cost Multipath Routing and Link Aggregation in 1017 tunnels", RFC6438, November, 2011. 1019 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1020 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1022 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1023 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1024 RFC 6936, April 2013. 1026 14.2. Informative References 1028 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 1029 792, September 1981. 1031 [RFC793] DARPA, "Transmission Control Protocol", RFC793, September 1032 1981. 1034 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1035 (IPv6) Specification", RFC 2460, December 1998. 1037 [RFC2914] Floyd, S.,"Congestion Control Principles", RFC2914, 1038 September 2000. 1040 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, 1041 October 2000. 1043 [RFC4787] Audet, F., et al, "network Address Translation (NAT) 1044 Behavioral Requirements for Unicast UDP", RFC4787, January 1045 2007. 1047 [RFC6056] Larsen, M. and Gont, F., "Recommendations for Transport- 1048 Protocol Port Randomization", RFC6056, January 2011. 1050 [RFC6438] Carpenter, B., Amante, S., "Using the Ipv6 Flow Label for 1051 Equal Cost Multipath Routing and Link Aggreation in 1052 Tunnels", RFC6438, November 2011. 1054 [RFC7676] Pignataro, C., Bonica, R., Krishnan, S., "IPv6 Support for 1055 Generic Routing Encapsulation (GRE)", RFC7676, October 1056 2015. 1058 [CB] Fairhurst, G., "Network Transport Circuit Breakers", 1059 draft-ietf-tsvwg-circuit-breaker-15, work in progress. 1061 15. Authors' Addresses 1063 Lucy Yong 1064 Huawei Technologies, USA 1066 Email: lucy.yong@huawei.com 1068 Edward Crabbe 1069 Oracle 1071 Email: edward.crabbe@gmail.com 1073 Xiaohu Xu 1074 Huawei Technologies, 1075 Beijing, China 1077 Email: xuxiaohu@huawei.com 1079 Tom Herbert 1080 Facebook 1081 1 Hacker Way 1082 Menlo Park, CA 1083 Email : tom@herbertland.com