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