idnits 2.17.1 draft-ietf-tsvwg-gre-in-udp-encap-16.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 2839 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-16 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. Deployed ECMP mechanisms 109 frequently use a hash of the five-tuple of source IP address, 110 destination IP address, UDP/TCP source port, UDP/TCP destination 111 port; this hashing distributes UDP and Transmission Control Protocol 112 (TCP)[RFC793] traffic between a common pair of IP addresses across 113 paths, but uses a single path for corresponding GRE traffic because 114 only the two IP addresses and protocol/next header fields 115 participate in the ECMP hash. Encapsulating GRE in UDP enables use 116 of the UDP source port to provide entropy to ECMP hashing. 118 A GRE-in-UDP tunnel also offers the possibility of using GRE across 119 networks that might otherwise disallow it; for instance GRE-in-UDP 120 may be used to bridge two islands where GRE is not supported 121 natively across the middleboxes. 123 GRE-in-UDP encapsulation may be used to encapsulate already tunneled 124 traffic, i.e. tunnel-in-tunnel. In this case, GRE-in-UDP tunnel do 125 not differentiate such end hosts from other end hosts, i.e., 126 applying the same treatment for traffic from hosts and tunnel 127 endpoints. 129 This document specifies GRE-in-UDP tunnel requirements for two 130 applicability scenarios: (1) general Internet; (2) a traffic-managed 131 controlled environment. The controlled environment has less 132 restrictive requirements than the general Internet. 134 The document also specifies Datagram Transport Layer Security (DTLS) 135 version of GRE-in-UDP tunnel to be used where/when security is a 136 concern. 138 GRE-in-UDP encapsulation usage requires no changes to the transit IP 139 network. Hash functions in most existing IP routers may utilize and 140 benefit from the use of a GRE-in-UDP tunnel without needing any 141 change or upgrade to their ECMP implementation. The encapsulation 142 mechanism is applicable to a variety of IP networks including Data 143 Center and wide area networks, IPv4 and IPv6 networks. 145 1.1. Terminology 147 The terms defined in [RFC768] and [RFC2784] are used in this 148 document. Following are additional terms used in this draft. 150 ECMP: Equal-Cost Multi-Path. 152 Flow Entropy: The information to be derived from traffic or 153 applications and to be used by network devices in ECMP process 154 [RFC6438]. 156 Default GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can apply to the 157 general Internet. 159 TMCE: A Traffic-managed controlled environment, i.e. an IP network 160 that is traffic-engineered and/or otherwise managed (e.g., via use 161 of traffic rate limiters) to avoid congestion, as defined in Section 162 2. 164 TMCE GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can only apply to a 165 traffic-managed controlled environment that is defined in Section 2. 167 1.2. Requirements Language 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 2. Applicability Statement 175 GRE-in-UDP encapsulation as specified herein applies to IPv4 and 176 IPv6 networks. When using GRE-in-UDP encapsulation, packets so 177 encapsulated are treated as UDP datagrams by an IP network. As such, 178 a GRE-in-UDP tunnel needs to meet the UDP requirements specified in 179 [RFC5405bis], which imposes requirements on GRE-in-UDP tunnel usage. 180 These requirements depend on both the delivery network and the 181 nature of the encapsulated traffic. For example, the GRE-in-UDP 182 tunnel protocol does not provide any congestion control 183 functionality beyond that of the encapsulated traffic. Therefore, a 184 GRE-in-UDP tunnel MUST be used only with congestion controlled 185 traffic (e.g., IP unicast traffic) and/or within a network that has 186 traffic management capability to avoid congestion. 188 [RFC5405bis] considers two types of IETF UDP applications: 1) 189 General Internet and 2) A controlled environment. The controlled 190 environment means a single administrative domain or bilaterally 191 agreed connection between domains. A network forming a controlled 192 environment can be managed/operated to meet certain conditions while 193 the general Internet cannot be; thus the requirements for a tunnel 194 protocol operating under a controlled environment can be less 195 restrictive than the requirements in the general Internet. 197 For the purpose of this document, a traffic-managed controlled 198 environment is defined as an IP network that is traffic-engineered 199 and/or otherwise managed (e.g., via use of traffic rate limiters) to 200 avoid congestion. 202 This document specifies GRE-in-UDP tunnel usage in the general 203 Internet and GRE-in-UDP tunnel usage in a traffic-managed controlled 204 environment and uses "default GRE-in-UDP tunnel" and "TMCE GRE-in- 205 UDP tunnel" terms to refer to each usage. 207 2.1. GRE-in-UDP Tunnel Requirements 209 This section states out the requirements for a GRE-in-UDP tunnel. 210 Section 2.1.1 describes the requirements for a default GRE-in-UDP 211 tunnel that is suitable for the general Internet; Section 2.1.2 212 describes a set of relaxed requirements for a TMCE GRE-in-UDP tunnel 213 used in a traffic-managed controlled environment. Both Setions 2.1.1 214 and 2.1.2 are applicable to an IPv4 or IPv6 delivery network. 216 2.1.1. Requirements for Default GRE-in-UDP Tunnel 218 The following is a summary of the default GRE-in-UDP tunnel 219 requirements: 221 1. A UDP checksum SHOULD be used when encapsulating in IPv4. 223 2. A UDP checksum MUST be used when encapsulating in IPv6. 225 3. GRE-in-UDP tunnel MUST NOT be used for traffic that does not 226 implement congestion control. As stated in [RFC5405bis], IP-based 227 unicast traffic is generally assumed to be congestion-controlled, 228 i.e., it is assumed that the transport protocols generating IP-based 229 traffic at the sender already employ mechanisms that are sufficient 230 to address congestion on the path. GRE-in-UDP tunnels are not 231 appropriate for traffic that is not known to be congestion- 232 controlled (e.g., IP multicast traffic). 234 4. UDP source port values that are used as a source of flow entropy 235 SHOULD be chosen from the ephemeral port range (49152- 236 65535).[RFC5405bis] 238 5. The use of the UDP source port MUST be configurable so that a 239 single value can be set for all traffic within the tunnel (this 240 disables use of the UDP source port to provide flow entropy). When a 241 single value is set, a random port SHOULD be selected in order to 242 minimize the vulnerability to off-path attacks [RFC6056]. 244 6. For IPv6 delivery networks, the flow entropy SHOULD also be 245 placed in the flow label field for ECMP per [RFC6438]. 247 7. At the tunnel ingress, any fragmentation of the incoming packet 248 (e.g., because the tunnel has an MTU that is smaller than the packet) 249 SHOULD be performed before encapsulation. In addition, the tunnel 250 ingress MUST apply the UDP checksum to all encapsulated fragments so 251 that the tunnel egress can validate reassembly of the fragments; it 252 MUST set the same DSCP value as in the DS field of the payload 253 packet in all fragments [RFC2474]. To avoid unwanted forwarding over 254 multiple paths, the same source UDP port value SHOULD be set in all 255 packet fragments. 257 2.1.2. Requirements for TMCE GRE-in-UDP Tunnel 259 The section contains the TMCE GRE-in-UDP tunnel requirements. It 260 lists the changed requirements, compared with a Default GRE-in-UDP 261 Tunnel, for a TMCE GRE-in-UDP Tunnel, which corresponds to the 262 requirements 1-3 listed in Section 2.1.1. 264 1. A UDP checksum SHOULD be used when encapsulating in IPv4. A 265 tunnel endpoint sending GRE-in-UDP MAY disable the UDP checksum, 266 since GRE has been designed to work without a UDP checksum [RFC2784]. 267 However, a checksum also offers protection from mis-delivery to 268 another port. 270 2. Use of UDP checksum MUST be the default when encapsulating in 271 IPv6. This default MAY be overridden via configuration of UDP zero- 272 checksum mode. All usage of UDP zero-checksum mode with IPv6 is 273 subject to the additional requirements specified in Section 6.2. 275 3. A GRE-in-UDP tunnel MAY encapsulate traffic that is not 276 congestion controlled. 278 The requirements 4-7 listed in Section 2.1.1 also apply to a TMCE 279 GRE-in-UDP Tunnel. 281 3. GRE-in-UDP Encapsulation 283 The GRE-in-UDP encapsulation format contains a UDP header [RFC768] 284 and a GRE header [RFC2890]. The format is shown as follows: 285 (presented in bit order) 287 0 1 2 3 288 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 290 IPv4 Header: 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |Version| IHL |Type of Service| Total Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Identification |Flags| Fragment Offset | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Time to Live |Protcol=17(UDP)| Header Checksum | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Source IPv4 Address | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Destination IPv4 Address | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 UDP Header: 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Source Port = Entropy Value | Dest. Port = TBD1/TBD2 | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | UDP Length | UDP Checksum | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 GRE Header: 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |C| |K|S| Reserved0 | Ver | Protocol Type | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Checksum (optional) | Reserved1 (Optional) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Key (optional) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Sequence Number (optional) | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 1 UDP+GRE Headers in IPv4 323 0 1 2 3 324 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 326 IPv6 Header: 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 |Version| Traffic Class | Flow Label | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 + + 334 | | 335 + Outer Source IPv6 Address + 336 | | 337 + + 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 + + 342 | | 343 + Outer Destination IPv6 Address + 344 | | 345 + + 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 UDP Header: 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Source Port = entropy value | Dest. Port = TBD1/TBD2 | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | UDP Length | UDP Checksum | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 GRE Header: 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 |C| |K|S| Reserved0 | Ver | Protocol Type | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Checksum (optional) | Reserved1 (Optional) | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Key (optional) | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Sequence Number (optional) | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Figure 2 UDP+GRE Headers in IPv6 369 The contents of the IP, UDP, and GRE headers that are relevant in 370 this encapsulation are described below. 372 3.1. IP Header 374 An encapsulator MUST encode its own IP address as the source IP 375 address and the decapsulator's IP address as the destination IP 376 address. A sufficiently large value is needed in the IPv4 TTL field 377 or IPv6 Hop Count field to allow delivery of the encapsulated packet 378 to the peer of the encapsulation. 380 3.2. UDP Header 382 3.2.1. Source Port 384 GRE-in-UDP permits the UDP source port value to be used to encode an 385 entropy value. The UDP source port contains a 16-bit entropy value 386 that is generated by the encapsulator to identify a flow for the 387 encapsulated packet. The port value SHOULD be within the ephemeral 388 port range, i.e., 49152 to 65535, where the high order two bits of 389 the port are set to one. This provides fourteen bits of entropy for 390 the inner flow identifier. In the case that an encapsulator is 391 unable to derive flow entropy from the payload header or the entropy 392 usage has to be disabled to meet operational requirements (see 393 Section 7), to avoid reordering with a packet flow, the encapsulator 394 SHOULD use the same UDP source port value for all packets assigned 395 to a flow e.g., the result of an algorithm that perform a hash of 396 the tunnel ingress and egress IP address. 398 The source port value for a flow set by an encapsulator MAY change 399 over the lifetime of the encapsulated flow. For instance, an 400 encapsulator may change the assignment for Denial of Service (DOS) 401 mitigation or as a means to effect routing through the ECMP network. 402 An encapsulator SHOULD NOT change the source port selected for a 403 flow more than once every thirty seconds. 405 An IPv6 GRE-in-UDP tunnel endpoint should copy a flow entropy value 406 in the IPv6 flow label field (requirement 6). This permits network 407 equipment to inspect this value and utilize it during forwarding, 408 e.g. to perform ECMP [RFC6438]. 410 This document places requirements on the generation of the flow 411 entropy value [RFC5405bis] but does not specify the algorithm that 412 an implementation should use to derive this value. 414 3.2.2. Destination Port 416 The destination port of the UDP header is set either GRE-in-UDP 417 (TBD1) or GRE-UDP-DTLS (TBD2) (see Section 5). 419 3.2.3. Checksum 421 The UDP checksum is set and processed per [RFC768] and [RFC1122] for 422 IPv4, and [RFC2460] for IPv6. Requirements for checksum handling and 423 use of zero UDP checksums are detailed in Section 6. 425 3.2.4. Length 427 The usage of this field is in accordance with the current UDP 428 specification in [RFC768]. This length will include the UDP header 429 (eight bytes), GRE header, and the GRE payload (encapsulated packet). 431 3.3. GRE Header 433 An encapsulator sets the protocol type (EtherType) of the packet 434 being encapsulated in the GRE Protocol Type field. 436 An encapsulator MAY set the GRE Key Present, Sequence Number Present, 437 and Checksum Present bits and associated fields in the GRE header as 438 defined by [RFC2784] and [RFC2890]. Usage of the reserved bits, i.e., 439 Reserved0, is specified in [RFC2784]. 441 The GRE checksum MAY be enabled to protect the GRE header and 442 payload. When the UDP checksum is enabled, it protects the GRE 443 payload, resulting in the GRE checksum being mostly redundant. 444 Enabling both checksums may result in unnecessary processing. Since 445 the UDP checksum covers the pseudo-header and the packet payload, 446 including the GRE header and its payload, the UDP checksum SHOULD be 447 used in preference to using the GRE checksum. 449 An implementation MAY use the GRE keyid to authenticate the 450 encapsulator.(See Security Considerations Section) In this model, a 451 shared value is either configured or negotiated between an 452 encapsulator and decapsulator. When a decapsulator determines a 453 presented keyid is not valid for the source, the packet MUST be 454 dropped. 456 Although GRE-in-UDP encapsulation protocol uses both UDP header and 457 GRE header, it is one tunnel encapsulation protocol. GRE and UDP 458 headers MUST be applied and removed as a pair at the encapsulation 459 and decapsulation points. This specification does not support UDP 460 encapsulation of a GRE header where that GRE header is applied or 461 removed at a network node other than the UDP tunnel ingress or 462 egress. 464 4. Encapsulation Process Procedures 466 The procedures specified in this section apply to both a default 467 GRE-in-UDP tunnel and a TMCE GRE-in-UDP tunnel. 469 The GRE-in-UDP encapsulation allows encapsulated packets to be 470 forwarded through "GRE-in-UDP tunnels". The encapsulator MUST set 471 the UDP and GRE header according to Section 3. 473 Intermediate routers, upon receiving these UDP encapsulated packets, 474 could load balance these packets based on the hash of the five-tuple 475 of UDP packets. 477 Upon receiving these UDP encapsulated packets, the decapsulator 478 decapsulates them by removing the UDP and GRE headers and then 479 processes them accordingly. 481 GRE-in-UDP allows encapsulation of unicast, IPv4 broadcast, or 482 multicast traffic. Entropy may be generated from the header of 483 encapsulated packets at an encapsulator. The mapping mechanism 484 between the encapsulated multicast traffic and the multicast 485 capability in the IP network is transparent and independent of the 486 encapsulation and is otherwise outside the scope of this document. 488 To provide entropy for ECMP, GRE-in-UDP does not rely on GRE keep- 489 alive. It is RECOMMENED not to use GRE keep-alive in the GRE-in-UDP 490 tunnel. This aligns with middlebox traversal guidelines in Section 491 3.5 of [RFC5405bis]. 493 4.1. MTU and Fragmentation 495 Regarding packet fragmentation, an encapsulator/decapsulator SHOULD 496 perform fragmentation before the encapsulation. The size of 497 fragments SHOULD be less or equal to the PMTU associated with the 498 path between the GRE ingress and the GRE egress tunnel endpoints 499 minus the GRE and UDP overhead, assuming the egress MTU for 500 reassembled packets is larger than PMTU. When applying payload 501 fragmentation, the UDP checksum MUST be used so that the receiving 502 endpoint can validate reassembly of the fragments; the same source 503 UDP port SHOULD be used for all packet fragments to ensure the 504 transit routers will forward the fragments on the same path. 506 If the operator of the transit network supporting the tunnel is able 507 to control the payload MTU size, the MTU SHOULD be configured to 508 avoid fragmentation, i.e., sufficient for the largest supported size 509 of packet, including all additional bytes introduced by the tunnel 510 overhead [RFC5405bis]. 512 4.2. Differentiated Services and ECN Marking 514 To ensure that tunneled traffic receives the same treatment over the 515 IP network as traffic that is not tunneled, prior to the 516 encapsulation process, an encapsulator processes the tunneled IP 517 packet headers to retrieve appropriate parameters for the 518 encapsulating IP packet header such as DiffServ [RFC2983]. 519 Encapsulation end points that support Explicit Congestion 520 Notification (ECN) must use the method described in [RFC6040] for 521 ECN marking propagation. The congestion control process is outside 522 of the scope of this document. 524 Additional information on IP header processing is provided in 525 Section 3.1. 527 5. Use of DTLS 529 Datagram Transport Layer Security (DTLS) [RFC6347] can be used for 530 application security and can preserve network and transport layer 531 protocol information. Specifically, if DTLS is used to secure the 532 GRE-in-UDP tunnel, the destination port of the UDP header MUST be 533 set to an IANA-assigned value (TBD2) indicating GRE-in-UDP with DTLS, 534 and that UDP port MUST NOT be used for other traffic. The UDP source 535 port field can still be used to add entropy, e.g., for load-sharing 536 purposes. DTLS applies to a default GRE-in-UDP tunnel and a TMCE 537 GRE-in-UDP tunnel. 539 Use of DTLS is limited to a single DTLS session for any specific 540 tunnel encapsulator/decapsulator pair (identified by source and 541 destination IP addresses). Both IP addresses MUST be unicast 542 addresses - multicast traffic is not supported when DTLS is used. A 543 GRE-in-UDP tunnel decapsulator that supports DTLS is expected to be 544 able to establish DTLS sessions with multiple tunnel encapsulators, 545 and likewise a GRE-in-UDP tunnel encapsulator is expected to be able 546 to establish DTLS sessions with multiple decapsulators. Different 547 source and/or destination IP addresses will be involved (see Section 548 6.2) for discussion of one situation where use of different source 549 IP addresses is important. 551 If the traffic to be encapsulated is already encrypted, it is 552 usually not necessary to encrypt it again. Applying DTLS to GRE-in- 553 UDP tunnel requires both tunnel end points to configure use of DTLS. 555 6. UDP Checksum Handling 557 6.1. UDP Checksum with IPv4 559 For UDP in IPv4, the UDP checksum MUST be processed as specified in 560 [RFC768] and [RFC1122] for both transmit and receive. The IPv4 561 header includes a checksum that protects against mis-delivery of the 562 packet due to corruption of IP addresses. The UDP checksum 563 potentially provides protection against corruption of the UDP header, 564 GRE header, and GRE payload. Disabling the use of checksums is a 565 deployment consideration that should take into account the risk and 566 effects of packet corruption. 568 When a decapsulator receives a packet, the UDP checksum field MUST 569 be processed. If the UDP checksum is non-zero, the decapsulator MUST 570 verify the checksum before accepting the packet. By default a 571 decapsulator SHOULD accept UDP packets with a zero checksum. A node 572 MAY be configured to disallow zero checksums per [RFC1122]; this may 573 be done selectively, for instance disallowing zero checksums from 574 certain hosts that are known to be sending over paths subject to 575 packet corruption. If verification of a non-zero checksum fails, a 576 decapsulator lacks the capability to verify a non-zero checksum, or 577 a packet with a zero-checksum was received and the decapsulator is 578 configured to disallow, the packet MUST be dropped and an event MAY 579 be logged. 581 6.2. UDP Checksum with IPv6 583 For UDP in IPv6, the UDP checksum MUST be processed as specified in 584 [RFC768] and [RFC2460] for both transmit and receive. 586 When UDP is used over IPv6, the UDP checksum is relied upon to 587 protect both the IPv6 and UDP headers from corruption. As such, A 588 default GRE-in-UDP Tunnel MUST perform UDP checksum; A TMCE GRE-in- 589 UDP Tunnel MAY be configured with the UDP zero-checksum mode if the 590 traffic-managed controlled environment or a set of closely 591 cooperating traffic-managed controlled environments (such as by 592 network operators who have agreed to work together in order to 593 jointly provide specific services) meet at least one of following 594 conditions: 596 a. It is known (perhaps through knowledge of equipment types and 597 lower layer checks) that packet corruption is exceptionally 598 unlikely and where the operator is willing to take the risk of 599 undetected packet corruption. 601 b. It is judged through observational measurements (perhaps of 602 historic or current traffic flows that use a non-zero checksum) 603 that the level of packet corruption is tolerably low and where 604 the operator is willing to take the risk of undetected packet 605 corruption. 607 c. Carrying applications that are tolerant of mis-delivered or 608 corrupted packets (perhaps through higher layer checksum, 609 validation, and retransmission or transmission redundancy) where 610 the operator is willing to rely on the applications using the 611 tunnel to survive any corrupt packets. 613 The following requirements apply to a TMCE GRE-in-UDP tunnel that 614 uses UDP zero-checksum mode: 616 a. Use of the UDP checksum with IPv6 MUST be the default 617 configuration of all GRE-in-UDP tunnels. 619 b. The GRE-in-UDP tunnel implementation MUST comply with all 620 requirements specified in Section 4 of [RFC6936] and with 621 requirement 1 specified in Section 5 of [RFC6936]. 623 c. The tunnel decapsulator SHOULD only allow the use of UDP zero- 624 checksum mode for IPv6 on a single received UDP Destination 625 Port regardless of the encapsulator. The motivation for this 626 requirement is possible corruption of the UDP Destination Port, 627 which may cause packet delivery to the wrong UDP port. If that 628 other UDP port requires the UDP checksum, the mis-delivered 629 packet will be discarded. 631 d. It is RECOMMENDED that the UDP zero-checksum mode for IPv6 is 632 only enabled for certain selected source addresses. The tunnel 633 decapsulator MUST check that the source and destination IPv6 634 addresses are valid for the GRE-in-UDP tunnel on which the 635 packet was received if that tunnel uses UDP zero-checksum mode 636 and discard any packet for which this check fails. 638 e. The tunnel encapsulator SHOULD use different IPv6 addresses for 639 each GRE-in-UDP tunnel that uses UDP zero-checksum mode 640 regardless of the decapsulator in order to strengthen the 641 decapsulator's check of the IPv6 source address (i.e., the same 642 IPv6 source address SHOULD NOT be used with more than one IPv6 643 destination address, independent of whether that destination 644 address is a unicast or multicast address). When this is not 645 possible, it is RECOMMENDED to use each source IPv6 address for 646 as few UDP zero-checksum mode GRE-in-UDP tunnels as is feasible. 648 f. When any middlebox exists on the path of a GRE-in-UDP tunnel, 649 it is RECOMMENDED to use the default mode, i.e. use UDP 650 checksum, to reduce the chance that the encapsulated packets 651 will be dropped. 653 g. Any middlebox that allows the UDP zero-checksum mode for IPv6 654 MUST comply with requirement 1 and 8-10 in Section 5 of 655 [RFC6936]. 657 h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP 658 checksums from "escaping" to the general Internet; see Section 659 8 for examples of such measures. 661 i. IPv6 traffic with zero UDP checksums MUST be actively monitored 662 for errors by the network operator. For example, the operator 663 may monitor Ethernet layer packet error rates. 665 j. If a packet with a non-zero checksum is received, the checksum 666 MUST be verified before accepting the packet. This is 667 regardless of whether the tunnel encapsulator and decapsulator 668 have been configured with UDP zero-checksum mode. 670 The above requirements do not change either the requirements 671 specified in [RFC2460] as modified by [RFC6935] or the requirements 672 specified in [RFC6936]. 674 The requirement to check the source IPv6 address in addition to the 675 destination IPv6 address, plus the strong recommendation against 676 reuse of source IPv6 addresses among GRE-in-UDP tunnels collectively 677 provide some mitigation for the absence of UDP checksum coverage of 678 the IPv6 header. A traffic-managed controlled environment that 679 satisfies at least one of three conditions listed at the beginning 680 of this section provides additional assurance. 682 A GRE-in-UDP tunnel is suitable for transmission over lower layers 683 in the traffic-managed controlled environments that are allowed by 684 the exceptions stated above and the rate of corruption of the inner 685 IP packet on such networks is not expected to increase by comparison 686 to GRE traffic that is not encapsulated in UDP. For these reasons, 687 GRE-in-UDP does not provide an additional integrity check except 688 when GRE checksum is used when UDP zero-checksum mode is used with 689 IPv6, and this design is in accordance with requirements 2, 3 and 5 690 specified in Section 5 of [RFC6936]. 692 Generic Router Encapsulation (GRE) does not accumulate incorrect 693 transport layer state as a consequence of GRE header corruption. A 694 corrupt GRE packet may result in either packet discard or forwarding 695 of the packet without accumulation of GRE state. Active monitoring 696 of GRE-in-UDP traffic for errors is REQUIRED as occurrence of errors 697 will result in some accumulation of error information outside the 698 protocol for operational and management purposes. This design is in 699 accordance with requirement 4 specified in Section 5 of [RFC6936]. 701 The remaining requirements specified in Section 5 of [RFC6936] are 702 not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply 703 because GRE does not include a control feedback mechanism. 704 Requirements 8-10 are middlebox requirements that do not apply to 705 GRE-in-UDP tunnel endpoints (see Section 7.1 for further middlebox 706 discussion). 708 It is worth mentioning that the use of a zero UDP checksum should 709 present the equivalent risk of undetected packet corruption when 710 sending similar packet using GRE-in-IPv6 without UDP [RFC7676] and 711 without GRE checksums. 713 In summary, a TMCE GRE-in-UDP Tunnel is allowed to use UDP-zero- 714 checksum mode for IPv6 when the conditions and requirements stated 715 above are met. Otherwise the UDP checksum need to be used for IPv6 716 as specified in [RFC768] and [RFC2460]. Use of GRE checksum is 717 RECOMMENED when the UDP checksum is not used. 719 7. Middlebox Considerations 721 Many middleboxes read or update UDP port information of the packets 722 that they forward. Network Address/Port Translator (NAPT) is the 723 most commonly deployed Network Address Translation (NAT) device 724 [RFC4787]. An NAPT device establishes a NAT session to translate the 725 {private IP address, private source port number} tuple to a {public 726 IP address, public source port number} tuple, and vice versa, for 727 the duration of the UDP session. This provides a UDP application 728 with the "NAT-pass-through" function. NAPT allows multiple internal 729 hosts to share a single public IP address. The port number, i.e., 730 the UDP Source Port number, is used as the demultiplexer of the 731 multiple internal hosts. However, the above NAPT behaviors conflict 732 with the behavior a GRE-in-UDP tunnel that is configured to use the 733 UDP source port value to provide entropy. 735 A GRE-in-UDP tunnel is unidirectional; the tunnel traffic is not 736 expected to be returned back to the UDP source port values used to 737 generate entropy. However some middleboxes (e.g., firewall) assume 738 that bidirectional traffic uses a common pair of UDP ports. This 739 assumption also conflicts with the use of the UDP source port field 740 as entropy. 742 Hence, use of the UDP source port for entropy may impact middleboxes 743 behavior. If a GRE-in-UDP tunnel is expected to be used on a path 744 with a middlebox, the tunnel can be configured to either disable use 745 of the UDP source port for entropy or to configure middleboxes to 746 pass packets with UDP source port entropy. 748 7.1. Middlebox Considerations for Zero Checksums 750 IPv6 datagrams with a zero UDP checksum will not be passed by any 751 middlebox that validates the checksum based on [RFC2460] or that 752 updates the UDP checksum field, such as NATs or firewalls. Changing 753 this behavior would require such middleboxes to be updated to 754 correctly handle datagrams with zero UDP checksums. The GRE-in-UDP 755 encapsulation does not provide a mechanism to safely fall back to 756 using a checksum when a path change occurs redirecting a tunnel over 757 a path that includes a middlebox that discards IPv6 datagrams with a 758 zero UDP checksum. In this case the GRE-in-UDP tunnel will be black- 759 holed by that middlebox. 761 As such, when any middlebox exists on the path of GRE-in-UDP tunnel, 762 use of the UDP checksum is RECOMMENDED to increase the probability 763 of successful transmission of GRE-in-UDP packets. Recommended 764 changes to allow firewalls, NATs and other middleboxes to support 765 use of an IPv6 zero UDP checksum are described in Section 5 of 766 [RFC6936]. 768 8. Congestion Considerations 770 Section 3.1.9 of [RFC5405bis] discusses the congestion 771 considerations for design and use of UDP tunnels; this is important 772 because other flows could share the path with one or more UDP 773 tunnels, necessitating congestion control [RFC2914] to avoid 774 distractive interference. 776 Congestion has potential impacts both on the rest of the network 777 containing a UDP tunnel, and on the traffic flows using the UDP 778 tunnels. These impacts depend upon what sort of traffic is carried 779 over the tunnel, as well as the path of the tunnel. 781 A default GRE-in-UDP tunnel MAY be used to carry IP traffic that is 782 known to be congestion controlled on the Internet. IP unicast 783 traffic is generally assumed to be congestion-controlled. A default 784 GRE-in-UDP tunnel MUST NOT be used to carry traffic that is not 785 known to be congestion-controlled. 787 A TMCE GRE-in-UDP tunnel can be used to carry traffic that is known 788 not to be congestion controlled. For example, GRE-in-UDP may be used 789 to carry MPLS that carries pseudowire or VPN traffic where specific 790 bandwidth guarantees are provided to each pseudowire or to each VPN. 791 In such cases, network operators may avoid congestion by careful 792 provisioning of their networks, by rate limiting of user data 793 traffic, and traffic engineering according to path capacity. 795 When a TMCE GRE-in-UDP tunnel carries traffic that is not known to 796 be congestion controlled, the tunnel MUST be used within a traffic- 797 managed controlled environment (e.g., single operator network that 798 utilizes careful provisioning such as rate limiting at the entries 799 of the network while over-provisioning network capacity) to manage 800 congestion, or within a limited number of networks whose operators 801 closely cooperate in order to jointly provide this same careful 802 provisioning. When a TMCE GRE-in-UDP tunnel is used to carry the 803 traffic that is not known to be congestion controlled, measures 804 SHOULD be taken to prevent the GRE-in-UDP traffic from "escaping" to 805 the general Internet, e.g.: 807 o Physical or logical isolation of the links carrying GRE-in-UDP 808 from the general Internet. 810 o Deployment of packet filters that block the UDP ports assigned 811 for GRE-in-UDP. 813 o Imposition of restrictions on GRE-in-UDP traffic by software 814 tools used to set up GRE-in-UDP tunnels between specific end 815 systems (as might be used within a single data center) or by 816 tunnel ingress nodes for tunnels that don't terminate at end 817 systems. 819 o Use of a "Circuit Breaker" for the tunneled traffic as described 820 in [CB]. 822 9. Backward Compatibility 824 In general, tunnel ingress routers have to be upgraded in order to 825 support the encapsulations described in this document. 827 No change is required at transit routers to support forwarding of 828 the encapsulation described in this document. 830 If a tunnel endpoint (a host or router) that is intended for use as 831 a decapsulator does not support or enable the GRE-in-UDP 832 encapsulation described in this document, that endpoint will not 833 listen on the destination port assigned to the GRE-encapsulation 834 (TBD1 and TBD2). In these cases, the endpoint will perform normal 835 UDP processing and respond to an encapsulator with an ICMP message 836 indicating "port unreachable" according to [RFC792]. Upon receiving 837 this ICMP message, the node MUST NOT continue to use GRE-in-UDP 838 encapsulation toward this peer without management intervention. 840 10. IANA Considerations 842 IANA is requested to make the following allocations: 844 One UDP destination port number for the indication of GRE, 846 Service Name: GRE-in-UDP 847 Transport Protocol(s): UDP 848 Assignee: IESG 849 Contact: IETF Chair 850 Description: GRE-in-UDP Encapsulation 851 Reference: [This.I-D] 852 Port Number: TBD1 853 Service Code: N/A 854 Known Unauthorized Uses: N/A 855 Assignment Notes: N/A 857 Editor Note: replace "TBD1" in section 3 and 9 with IANA assigned 858 number. 860 One UDP destination port number for the indication of GRE with DTLS, 862 Service Name: GRE-UDP-DTLS 863 Transport Protocol(s): UDP 864 Assignee: IESG 865 Contact: IETF Chair 866 Description: GRE-in-UDP Encapsulation with DTLS 867 Reference: [This.I-D] 868 Port Number: TBD2 869 Service Code: N/A 870 Known Unauthorized Uses: N/A 871 Assignment Notes: N/A 873 Editor Note: replace "TBD2" in section 3, 5, and 9 with IANA 874 assigned number. 876 11. Security Considerations 878 GRE-in-UDP encapsulation does not affect security for the payload 879 protocol. The security considerations for GRE apply to GRE-in-UDP, 880 see [RFC2784]. 882 To secure original traffic, DTLS SHOULD be used as specified in 883 Section 5. 885 In the case that UDP source port for entropy usage is disabled, a 886 random port SHOULD be selected in order to minimize the 887 vulnerability to off-path attacks.[RFC6056] The random port may also 888 be periodically changed to mitigate certain denial of service 889 attacks as mentioned in Section 3.2.1. 891 Using one standardized value as the UDP destination port to indicate 892 an encapsulation may increase the vulnerability of off-path attack. 893 To overcome this, an alternate port may be agreed upon to use 894 between an encapsulator and decapsulator [RFC6056]. How the 895 encapsulator end points communicate the value is outside scope of 896 this document. 898 This document does not require that a decapsulator validates the IP 899 source address of the tunneled packets (with the exception that the 900 IPv6 source address MUST be validated when UDP zero-checksum mode is 901 used with IPv6), but it should be understood that failure to do so 902 presupposes that there is effective destination-based (or a 903 combination of source-based and destination-based) filtering at the 904 boundaries. 906 Corruption of a GRE header can cause a privacy and security concern 907 for some applications that rely on the key field for traffic 908 segregation. When the GRE key field is used for privacy and security, 909 ether UDP checksum or GRE checksum SHOULD be used for GRE-in-UDP 910 with both IPv4 and IPv6, and in particular, when UDP zero-checksum 911 mode is used, GRE checksum SHOULD be used. 913 12. Acknowledgements 915 Authors like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger 916 Geib, Lar Edds, Lloyd Wood, Bob Briscoe, and many others for their 917 review and valuable input on this draft. 919 Thank Donald Eastlake, Eliot Lear, Martin Stiemerling, and Spencer 920 Dawkins for their detail reviews and valuable suggestions in WGLC 921 and IESG process. 923 Thank the design team led by David Black (members: Ross Callon, 924 Gorry Fairhurst, Xiaohu Xu, Lucy Yong) to efficiently work out the 925 descriptions for the congestion considerations and IPv6 UDP zero 926 checksum. 928 Thank David Black and Gorry Fairhurst for their great help in 929 document content and editing. 931 13. Contributors 933 The following people all contributed significantly to this document 934 and are listed below in alphabetical order: 936 David Black 937 EMC Corporation 938 176 South Street 939 Hopkinton, MA 01748 940 USA 942 Email: david.black@emc.com 944 Ross Callon 945 Juniper Networks 946 10 Technology Park Drive 947 Westford, MA 01886 948 USA 950 Email: rcallon@juniper.net 952 John E. Drake 953 Juniper Networks 955 Email: jdrake@juniper.net 957 Gorry Fairhurst 958 University of Aberdeen 960 Email: gorry@erg.abdn.ac.uk 961 Yongbing Fan 962 China Telecom 963 Guangzhou, China. 964 Phone: +86 20 38639121 966 Email: fanyb@gsta.com 968 Adrian Farrel 969 Juniper Networks 971 Email: adrian@olddog.co.uk 973 Vishwas Manral 974 Hewlett-Packard Corp. 975 3000 Hanover St, Palo Alto. 977 Email: vishwas.manral@hp.com 979 Carlos Pignataro 980 Cisco Systems 981 7200-12 Kit Creek Road 982 Research Triangle Park, NC 27709 USA 984 EMail: cpignata@cisco.com 986 14. References 988 14.1. Normative References 990 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 991 August 1980. 993 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 994 Communication Layers", RFC1122, October 1989. 996 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 997 Requirement Levels", BCP 14, RFC2119, March 1997. 999 [RFC2474] Nichols K., Blake S., Baker F., Black D., "Definition of 1000 the Differentiated Services Field (DS Field) in the IPv4 1001 and IPv6 Headers", December 1998. 1003 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1004 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1005 March 2000. 1007 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 1008 RFC2890, September 2000. 1010 [RFC5405bis] Eggert, L., "Unicast UDP Usage Guideline for 1011 Application Designers", draft-ietf-tsvwg-rfc5405bis, work 1012 in progress. 1014 [RFC6040] Briscoe, B., "Tunneling of Explicit Congestion 1015 Notification", RFC6040, November 2010. 1017 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 1018 Security Version 1.2", RFC6347, 2012. 1020 [RFC6438] Carpenter, B., Amante, S., "Using the IPv6 Flow Label for 1021 Equal Cost Multipath Routing and Link Aggregation in 1022 tunnels", RFC6438, November, 2011. 1024 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1025 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1027 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1028 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1029 RFC 6936, April 2013. 1031 14.2. Informative References 1033 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 1034 792, September 1981. 1036 [RFC793] DARPA, "Transmission Control Protocol", RFC793, September 1037 1981. 1039 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1040 (IPv6) Specification", RFC 2460, December 1998. 1042 [RFC2914] Floyd, S.,"Congestion Control Principles", RFC2914, 1043 September 2000. 1045 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, 1046 October 2000. 1048 [RFC4787] Audet, F., et al, "network Address Translation (NAT) 1049 Behavioral Requirements for Unicast UDP", RFC4787, January 1050 2007. 1052 [RFC6056] Larsen, M. and Gont, F., "Recommendations for Transport- 1053 Protocol Port Randomization", RFC6056, January 2011. 1055 [RFC6438] Carpenter, B., Amante, S., "Using the Ipv6 Flow Label for 1056 Equal Cost Multipath Routing and Link Aggreation in 1057 Tunnels", RFC6438, November 2011. 1059 [RFC7676] Pignataro, C., Bonica, R., Krishnan, S., "IPv6 Support for 1060 Generic Routing Encapsulation (GRE)", RFC7676, October 1061 2015. 1063 [CB] Fairhurst, G., "Network Transport Circuit Breakers", 1064 draft-ietf-tsvwg-circuit-breaker-15, work in progress. 1066 15. Authors' Addresses 1068 Lucy Yong 1069 Huawei Technologies, USA 1071 Email: lucy.yong@huawei.com 1073 Edward Crabbe 1074 Oracle 1076 Email: edward.crabbe@gmail.com 1078 Xiaohu Xu 1079 Huawei Technologies, 1080 Beijing, China 1082 Email: xuxiaohu@huawei.com 1084 Tom Herbert 1085 Facebook 1086 1 Hacker Way 1087 Menlo Park, CA 1088 Email : tom@herbertland.com