idnits 2.17.1 draft-ietf-tsvwg-gre-in-udp-encap-10.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 (March 1, 2016) is 2977 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) == Outdated reference: A later version (-15) exists of draft-ietf-tsvwg-circuit-breaker-13 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Crabbe 2 Internet-Draft 3 Intended status: Standard Track L. Yong 4 Huawei USA 5 X. Xu 6 Huawei Technologies 7 T. Herbert 8 Facebook 10 Expires: September 2016 March 1, 2016 12 GRE-in-UDP Encapsulation 13 draft-ietf-tsvwg-gre-in-udp-encap-10 15 Abstract 17 This document describes a method of encapsulating network protocol 18 packets within GRE and UDP headers. In this encapsulation method, 19 the source UDP port can be used as an entropy field for purposes of 20 load balancing, while the protocol of the encapsulated packet in the 21 GRE payload is identified by the GRE Protocol Type. This document 22 specifies requirements for two applicability scenarios for the 23 encapsulation: (1) General Internet; (2) Controlled Environment, 24 e.g. well-managed operator networks. The controlled environment has 25 less restrictive 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 September 1,2016. 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. Applicability Statement...................................4 63 1.2. GRE-in-UDP Tunnel Usage Requirements......................4 64 1.2.1. Requirements for Default GRE-in-UDP Tunnel...........5 65 1.2.2. Requirements Changes for WMON GRE-in-UDP Tunnel......5 66 2. Terminology....................................................6 67 2.1. Requirements Language.....................................6 68 3. Encapsulation in UDP...........................................6 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.....................................9 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. Middlebox Considerations.................................12 79 4.3. Differentiated Services and ECN Marking..................12 80 5. UDP Checksum Handling.........................................13 81 5.1. UDP Checksum with IPv4...................................13 82 5.2. UDP Checksum with IPv6...................................13 83 5.2.1. Middlebox Considerations............................16 84 6. Congestion Considerations.....................................17 85 7. Backward Compatibility........................................18 86 8. IANA Considerations...........................................18 87 9. Security Considerations.......................................19 88 10. Acknowledgements.............................................20 89 11. Contributors.................................................21 90 12. References...................................................22 91 12.1. Normative References....................................22 92 12.2. Informative References..................................23 93 13. Authors' Addresses...........................................24 95 1. Introduction 97 Load balancing, or more specifically statistical multiplexing of 98 traffic using Equal Cost Multi-Path (ECMP) and/or Link Aggregation 99 Groups (LAGs) in IP networks, is a widely used technique for 100 creating higher capacity networks out of lower capacity links. Most 101 existing routers in IP networks are already capable of distributing 102 IP traffic flows over ECMP paths and/or LAGs on the basis of a hash 103 function performed on flow invariant fields in IP packet headers and 104 their payload protocol headers. Specifically, when the IP payload is 105 a User Datagram Protocol (UDP)[RFC768] or Transmission Control 106 Protocol (TCP) [RFC793] packet, router hash functions frequently 107 operate on the five-tuple of source IP address, destination IP 108 address, source port, destination port, and protocol/next-header 110 GRE encapsulation has been widely used for many applications. For 111 example, to redirect IP traffic to traverse a different path instead 112 of the default path in an operator network, to tunnel private 113 network traffic over a public network by use of public IP network 114 addresses, to tunnel IPv6 traffic over an IPv4 network, tunnel 115 Ethernet traffic over IP networks [RFC7637], etc. Unfortunately, 116 using GRE encapsulated within IP may reduce the entropy available 117 for use in load balancing compared to TCP/IP or UDP/IP, especially 118 in cases where the GRE Key field [RFC2890] is not used for entropy 119 purpose, i.e., the Key field is used for security authentication. 121 This document defines a generic GRE-in-UDP encapsulation for 122 tunneling network protocol packets across an IP network. The GRE 123 header provides payload protocol type as an EtherType in the 124 protocol type field [RFC2784][RFC7676], and the UDP header provides 125 additional entropy by way of its source port. GRE-in-UDP offers the 126 additional possibility of using GRE across networks that might 127 otherwise disallow it; for instance GRE-in-UDP may be used to bridge 128 two islands where GRE is not used natively across the Internet. 130 This encapsulation method requires no changes to the transit IP 131 network. Hash functions in most existing IP routers may utilize and 132 benefit from the use of a GRE-in-UDP tunnel without needing any 133 change or upgrade to their ECMP implementation. The encapsulation 134 mechanism is applicable to a variety of IP networks including Data 135 Center and wide area networks. 137 GRE-in-UDP encapsulation may be used to encapsulate already tunneled 138 traffic, i.e. tunnel-in-tunnel. In this case, GRE-in-UDP tunnel 139 endpoints treat other tunnel endpoints as of the end hosts for the 140 traffic and do not differentiate such end hosts from other end 141 hosts. 143 1.1. Applicability Statement 145 GRE-in-UDP encapsulation applies to IPv4 and IPv6 networks including 146 the Internet. When using GRE-in-UDP encapsulation, encapsulated 147 traffic will be treated as a UDP application in an IP delivery 148 network. As such, GRE-in-UDP tunnel needs to meet UDP requirements 149 specified in [RFC5405bis], which imposes limits on GRE-in-UDP tunnel 150 usage. These limits may depend on both the network and the nature of 151 the encapsulated traffic. For example, the GRE-in-UDP tunnel 152 protocol does not provide any congestion control functionality 153 beyond that of the encapsulated traffic. Therefore, GRE-in-UDP MUST 154 be used only with congestion controlled traffic (e.g., IP traffic) 155 and/or within a network that has the congestion management. 157 [RFC5405bis] considers two types of applicability where IETF 158 applications utilize UDP: 1) General Internet and 2) Controlled 159 Environment. The controlled environment means within a single 160 administrative domain or bilaterally agreed connection between 161 domains. A network under controlled environment can be 162 managed/operated to meet certain conditions while the general 163 Internet cannot be. Tunnel protocol requirements under controlled 164 environment can be less restrictive than the requirements in the 165 general Internet. This document specifies GRE-in-UDP tunnel usage in 166 the general Internet and GRE-in-UDP tunnel usage in the well-managed 167 operator network that is an example of controlled environment. 169 For the purpose of this document, a well-managed operator network is 170 defined as an IP network that is traffic-engineered and/or otherwise 171 managed (e.g., via use of traffic rate limiters) to avoid 172 congestion. 174 This document refers to the GRE-in-UDP tunnel usage in the general 175 Internet as Default GRE-in-UDP Tunnel; the GRE-in-UDP tunnel usage 176 in a well-managed operator network as WMON GRE-in-UDP Tunnel. 178 1.2. GRE-in-UDP Tunnel Usage Requirements 180 The section summarizes GRE-in-UDP tunnel requirements. The 181 requirements for Default GRE-in-UDP tunnel are listed in Section 182 1.2.1, which applies to a GRE-in-UDP tunnel over the general 183 Internet; the relaxed requirements for WMON GRE-in-UDP Tunnel are 184 listed in Section 1.2.2, which applies to a GRE-in-UDP tunnel within 185 a well-managed operator network. These networks can use IPv4 or IPv6. 187 1.2.1. Requirements for Default GRE-in-UDP Tunnel 189 The following is a summary of the GRE-in-UDP requirements for use 190 over the general Internet: 192 1. UDP checksum SHOULD be used when encapsulating in IPv4. 194 2. UDP checksum MUST be used when encapsulating in IPv6. 196 3. GRE-in-UDP tunnel MUST NOT be used for traffic that has no 197 congestion control. IP-traffic can be assumed to be congestion- 198 controlled. GRE-in-UDP tunnels are not appropriate for other traffic 199 that does not use congestion control. 201 4. UDP source port that is used for flow entropy SHOULD be set to a 202 UDP ephemeral port (49152-65535). 204 5. UDP source port usage MUST be configurable so that a single value 205 is used for all traffic in the tunnel (this disables use of the UDP 206 source port to provide flow entropy). 208 6. For IPv6 delivery networks, the flow entropy SHOULD also be 209 placed in the flow label field for ECMP per [RFC6438]. 211 7. At the tunnel ingress, any fragmentation of the incoming packet 212 (e.g., because the tunnel has an MTU that is smaller than the packet 213 SHOULD be performed before encapsulation [RFC7588]. In addition, the 214 tunnel ingress MUST apply the UDP checksum to all encapsulated 215 fragments so that the tunnel egress can validate reassembly of the 216 fragments, and SHOULD use the same source UDP port for all packet 217 fragments to ensure the packet fragments traversing on the same path. 219 1.2.2. Requirements Changes for WMON GRE-in-UDP Tunnel 221 The following lists the changed requirements for WMON GRE-in-UDP 222 Tunnel that is used in a well-managed operator network; they replace 223 requirements 1-3 listed in section 1.2.1. The requirements 4-7 in 224 that section are unchanged for WMON GRE-in-UDP Tunnel. 226 1. UDP checksum MAY be used when encapsulating in IPv4. 228 2. Use of UDP checksum MUST be the default when encapsulating in 229 IPv6. This default MAY be overridden via configuration of UDP zero- 230 checksum mode. All usage of UDP zero-checksum mode with IPv6 is 231 subject to the additional requirements specified in Section 5.2. 233 3. GRE-in-UDP tunnel MAY encapsulate traffic that is not congestion 234 controlled. 236 2. Terminology 238 The terms defined in [RFC768][RFC2784] are used in this document. 240 Default GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can apply to the 241 general Internet. 243 WMON GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can only apply to a 244 well-managed operator network that is defined in Section 1.1. 246 2.1. Requirements Language 248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 250 document are to be interpreted as described in [RFC2119]. 252 3. Encapsulation in UDP 254 GRE-in-UDP encapsulation format is shown as follows: 256 0 1 2 3 257 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 259 IPv4 Header: 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 |Version| IHL |Type of Service| Total Length | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Identification |Flags| Fragment Offset | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Time to Live |Protcol=17(UDP)| Header Checksum | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Source IPv4 Address | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Destination IPv4 Address | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 UDP Header: 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Source Port = XXXX | Dest Port = TBD | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | UDP Length | UDP Checksum | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 GRE Header: 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |C| |K|S| Reserved0 | Ver | Protocol Type | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Checksum (optional) | Reserved1 (Optional) | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Key (optional) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Sequence Number (optional) | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Figure 1 UDP+GRE Headers in IPv4 292 0 1 2 3 293 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 295 IPv6 Header: 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |Version| Traffic Class | Flow Label | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 + + 303 | | 304 + Outer Source IPv6 Address + 305 | | 306 + + 307 | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | 310 + + 311 | | 312 + Outer Destination IPv6 Address + 313 | | 314 + + 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 UDP Header: 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Source Port = XXXX | Dest Port = TBD | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | UDP Length | UDP Checksum | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 GRE Header: 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 |C| |K|S| Reserved0 | Ver | Protocol Type | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Checksum (optional) | Reserved1 (Optional) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Key (optional) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Sequence Number (optional) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 2 UDP+GRE Headers in IPv6 338 The contents of the IP, UDP, and GRE headers that are relevant in 339 this encapsulation are described below. 341 3.1. IP Header 343 An encapsulator MUST encode its own IP address as the source IP 344 address and the decapsulator's IP address as the destination IP 345 address. The TTL field in the IP header MUST be set to a value 346 appropriate for delivery of the encapsulated packet to the peer of 347 the encapsulation. 349 3.2. UDP Header 351 3.2.1. Source Port 353 The UDP source port contains a 16-bit entropy value that is 354 generated by the encapsulator to identify a flow for the 355 encapsulated packet. The port value SHOULD be within the ephemeral 356 port range, i.e., 49152 to 65535, where the high order two bits of 357 the port are set to one. This provides fourteen bits of entropy for 358 the inner flow identifier. In the case that an encapsulator is 359 unable to derive flow entropy from the payload header or the entropy 360 usage has to be disabled to meet operational requirements (see 361 section 4.2), it SHOULD set a randomly selected constant value for 362 UDP source port to avoid payload packet flow reordering, e.g., the 363 port can be chosen as a hash of the tunnel ingress and egress IP 364 address. 366 The source port value for a flow set by an encapsulator MAY change 367 over the lifetime of the encapsulated flow. For instance, an 368 encapsulator may change the assignment for Denial of Service (DOS) 369 mitigation or as a means to effect routing through the ECMP network. 370 An encapsulator SHOULD NOT change the source port selected for a 371 flow more than once every thirty seconds. 373 For IPv6 delivery network, if IPv6 flow label load balancing is 374 supported [RFC6438], the flow entropy SHOULD also be placed in the 375 flow label field. 377 How an encapsulator generates flow entropy from the payload is 378 outside the scope of this document. 380 3.2.2. Destination Port 382 The destination port of the UDP header is set the GRE-in-UDP port or 383 GRE-UDP-DTLS (TBD) (see Section 8). 385 3.2.3. Checksum 387 The UDP checksum is set and processed per [RFC768] and [RFC1122] for 388 IPv4, and [RFC2460] for IPv6. Requirements for checksum handling and 389 use of zero UDP checksums are detailed in Section 5. 391 3.2.4. Length 393 The usage of this field is in accordance with the current UDP 394 specification in [RFC768]. This length will include the UDP header 395 (eight bytes), GRE header, and the GRE payload (encapsulated packet). 397 3.3. GRE Header 399 An encapsulator sets the protocol type (EtherType) of the packet 400 being encapsulated in the GRE Protocol Type field. 402 An encapsulator may set the GRE Key Present, Sequence Number Present, 403 and Checksum Present bits and associated fields in the GRE header as 404 defined by [RFC2784] and [RFC2890]. The reserved bits, i.e., 405 Reserved0, SHOULD be set zero. 407 The GRE checksum MAY be enabled to protect the GRE header and 408 payload. An encapsulator SHOULD NOT enable both the GRE checksum and 409 UDP checksum simultaneously as this would be mostly redundant. Since 410 the UDP checksum covers more of the packet including the GRE header 411 and payload, the UDP checksum SHOULD have preference to using GRE 412 checksum. The GRE checksum MAY be used for the payload integrity 413 check when use of UDP zero-checksum. 415 An implementation MAY use the GRE keyid to authenticate the 416 encapsulator. (See Security Section) In this model, a shared value 417 is either configured or negotiated between an encapsulator and 418 decapsulator. When a decapsulator determines a presented keyid is 419 not valid for the source, the packet MUST be dropped. 421 Although GRE-in-UDP encapsulation protocol uses both UDP header and 422 GRE header, it is one tunnel encapsulation protocol. GRE and UDP 423 headers MUST be applied and removed as a pair at the encapsulation 424 and decapsulation points. This specification does not support UDP 425 encapsulation of a GRE header where that GRE header is applied or 426 removed at a network node other than the UDP tunnel ingress or 427 egress. 429 4. Encapsulation Process Procedures 431 The procedures specified in this section apply to both Default GRE- 432 in-UDP tunnel and WMON GRE-in-UDP tunnel. 434 The GRE-in-UDP encapsulation allows encapsulated packets to be 435 forwarded through "GRE-in-UDP tunnels". When performing GRE-in-UDP 436 encapsulation by the encapsulator, the entropy value is generated by 437 the encapsulator and then be filled in the Source Port field of the 438 UDP header. The Destination Port field is set to a value (TBD) to 439 indicate that the UDP tunnel payload is a GRE packet. The Protocol 440 Type header field in GRE header is set to the EtherType value 441 corresponding to the protocol of the encapsulated packet. 443 Intermediate routers, upon receiving these UDP encapsulated packets, 444 could load balance these packets based on the hash of the five-tuple 445 of UDP packets. 447 Upon receiving these UDP encapsulated packets, the decapsulator 448 decapsulates them by removing the UDP and GRE headers and then 449 processes them accordingly. 451 GRE-in-UDP allows encapsulation of unicast, broadcast, or multicast 452 traffic. Entropy may be generated from the header of encapsulated 453 unicast or broadcast/multicast packets at an encapsulator. The 454 mapping mechanism between the encapsulated multicast traffic and the 455 multicast capability in the IP network is transparent and 456 independent to the encapsulation and is otherwise outside the scope 457 of this document. 459 To provide entropy for ECMP, GRE-in-UDP does not rely on GRE keep- 460 alive. It is RECOMMENED not to use GRE keep-alive in the GRE-in-UDP 461 tunnel. This aligns with middlebox traversal guidelines in Section 462 3.5 of [RFC5405bis]. 464 4.1. MTU and Fragmentation 466 Regarding packet fragmentation, an encapsulator/decapsulator SHOULD 467 be compliant with [RFC7588] and perform fragmentation before the 468 encapsulation. The size of fragments SHOULD be less or equal to the 469 PMTU associated with the path between the GRE ingress and the GRE 470 egress nodes minus the GRE and UDP overhead, assuming the egress 471 resemble MTU is larger than PMTU. When applying payload fragment, 472 the UDP checksum MUST be used so that the receiving endpoint can 473 validate reassembly of the fragments; the same src UDP port SHOULD 474 be used for all packet fragments to ensure the transit routers will 475 forward the fragments on the same path. 477 If a tunnel operator is able to control the payload MTU size, the 478 tunnel operator SHOULD factor in the additional bytes of tunnel 479 overhead when considering the MTU size to avoid the likelihood of 480 fragmentation. 482 4.2. Middlebox Considerations 484 The Source Port number of the UDP header is pertinent to the 485 middlebox behavior. Network Address/Port Translator (NAPT) is the 486 most commonly deployed Network Address Translation (NAT) device 487 [RFC4787]. An NAPT device establishes a NAT session to translate the 488 {private IP address, private source port number} tuple to a {public 489 IP address, public source port number} tuple, and vice versa, for 490 the duration of the UDP session. This provides a UDP application 491 with the "NAT-pass-through" function. NAPT allows multiple internal 492 hosts to share a single public IP address. The port number, i.e., 493 the UDP Source Port number, is used as the demultiplexer of the 494 multiple internal hosts. However, the above NAPT behaviors conflict 495 with the behavior that the UDP source port number is used as entropy 496 in GRE-in-UDP tunnel. 498 Each UDP tunnel is unidirectional, as GRE-in-UDP traffic is sent to 499 the GRE-in-UDP Destination Port (TBD), and in particular, is never 500 sent back to any port used as a UDP Source Port (which serves solely 501 as a source of entropy). It is common that a middlebox (e.g., 502 firewall) assume that bidirectional traffic uses a common pair of 503 UDP ports. This assumption also conflicts with the use of the UDP 504 source port number as entropy. 506 Hence, use of the UDP src port for entropy may impact middlebox 507 behavior. If a GRE-in-UDP tunnel is expected to pass a middlebox, to 508 avoid the impact, the operator either disable UDP source port for 509 entropy or configure the middlebox to deal with the UDP source port 510 variation. 512 4.3. Differentiated Services and ECN Marking 514 To ensure that tunneled traffic gets the same treatment over the IP 515 network, prior to the encapsulation process, an encapsulator should 516 process the payload to get the proper parameters to fill into the IP 517 header such as DiffServ [RFC2983]. Encapsulation end points that 518 support Explicit Congestion Notification (ECN) must use the method 519 described in [RFC6040] for ECN marking propagation. The congestion 520 control process is outside of the scope of this document. 522 5. UDP Checksum Handling 524 5.1. UDP Checksum with IPv4 526 Default GRE-in-UDP Tunnel SHOULD perform UDP checksum. WMON GRE-in- 527 UDP Tunnel MAY perform UDP checksum. 529 For UDP in IPv4, the UDP checksum MUST be processed as specified in 530 [RFC768] and [RFC1122] for both transmit and receive. The IPv4 531 header includes a checksum which protects against mis-delivery of 532 the packet due to corruption of IP addresses. The UDP checksum 533 potentially provides protection against corruption of the UDP header, 534 GRE header, and GRE payload. Enabling or disabling the use of 535 checksums is a deployment consideration that should take into 536 account the risk and effects of packet corruption, and whether the 537 packets in the network are protected by other, possibly stronger 538 mechanisms such as the Ethernet CRC. 540 When a decapsulator receives a packet, the UDP checksum field MUST 541 be processed. If the UDP checksum is non-zero, the decapsulator MUST 542 verify the checksum before accepting the packet. By default a 543 decapsulator SHOULD accept UDP packets with a zero checksum. A node 544 MAY be configured to disallow zero checksums per [RFC1122]; this may 545 be done selectively, for instance disallowing zero checksums from 546 certain hosts that are known to be sending over paths subject to 547 packet corruption. If verification of a non-zero checksum fails, a 548 decapsulator lacks the capability to verify a non-zero checksum, or 549 a packet with a zero-checksum was received and the decapsulator is 550 configured to disallow, the packet MUST be dropped and an event MAY 551 be logged. 553 5.2. UDP Checksum with IPv6 555 For UDP in IPv6, the UDP checksum MUST be processed as specified in 556 [RFC768] and [RFC2460] for both transmit and receive. 558 When UDP is used over IPv6, the UDP checksum is relied upon to 559 protect both the IPv6 and UDP headers from corruption. As such, 560 Default GRE-in-UDP Tunnel MUST perform UDP checksum; WMON GRE-in-UDP 561 Tunnel MAY be configured with the UDP zero-checksum mode if the 562 well-managed operator network or a set of closely cooperating well- 563 managed operator networks (such as by network operators who have 564 agreed to work together in order to jointly provide specific 565 services) meet at least one of following conditions: 567 a. It is known (perhaps through knowledge of equipment types and 568 lower layer checks) that packet corruption is exceptionally 569 unlikely and where the operator is willing to take the risk of 570 undetected packet corruption. 572 b. It is judged through observational measurements (perhaps of 573 historic or current traffic flows that use a non-zero checksum) 574 that the level of packet corruption is tolerably low and where 575 the operator is willing to take the risk of undetected packet 576 corruption. 578 c. Carrying applications that are tolerant of mis-delivered or 579 corrupted packets (perhaps through higher layer checksum, 580 validation, and retransmission or transmission redundancy) where 581 the operator is willing to rely on the applications using the 582 tunnel to survive any corrupt packets. 584 The following requirements apply to WMON GRE-in-UDP Tunnel that use 585 UDP zero-checksum mode: 587 a. Use of the UDP checksum with IPv6 MUST be the default 588 configuration of all GRE-in-UDP tunnels. 590 b. The GRE-in-UDP tunnel implementation MUST comply with all 591 requirements specified in Section 4 of [RFC6936] and with 592 requirement 1 specified in Section 5 of [RFC6936]. 594 c. The tunnel decapsulator SHOULD only allow the use of UDP zero- 595 checksum mode for IPv6 on a single received UDP Destination 596 Port regardless of the encapsulator. The motivation for this 597 requirement is possible corruption of the UDP Destination Port, 598 which may cause packet delivery to the wrong UDP port. If that 599 other UDP port requires the UDP checksum, the mis-delivered 600 packet will be discarded. 602 d. It is RECOMMENDED that UDP zero-checksum selectively be enabled 603 for certain source addresses. The tunnel decapsulator MUST 604 check that the source and destination IPv6 addresses are valid 605 for the GRE-in-UDP tunnel on which the packet was received if 606 that tunnel uses UDP zero-checksum mode and discard any packet 607 for which this check fails. 609 e. The tunnel encapsulator SHOULD use different IPv6 addresses for 610 each GRE-in-UDP tunnel that uses UDP zero-checksum mode 611 regardless of the decapsulator in order to strengthen the 612 decapsulator's check of the IPv6 source address (i.e., the same 613 IPv6 source address SHOULD NOT be used with more than one IPv6 614 destination address, independent of whether that destination 615 address is a unicast or multicast address). When this is not 616 possible, it is RECOMMENDED to use each source IPv6 address for 617 as few UDP zero-checksum mode GRE-in-UDP tunnels as is feasible. 619 f. When any middlebox exists on the path of a GRE-in-UDP tunnel, 620 it is RECOMMENDED to use the default mode, i.e. use UDP 621 checksum, to reduce the chance that the encapsulated packets to 622 be dropped. 624 g. Any middlebox that allows UDP zero-checksum mode for IPv6 MUST 625 comply with requirement 1 and 8-10 in Section 5 of [RFC6936]. 627 h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP 628 checksums from "escaping" to the general Internet; see Section 629 6 for examples of such measures. 631 i. IPv6 traffic with zero UDP checksums MUST be actively monitored 632 for errors by the network operator. For example, the operator 633 may monitor Ethernet layer packet error rates. 635 j. If a packet with a non-zero checksum is received, the checksum 636 MUST be verified before accepting the packet. This is 637 regardless of whether the tunnel encapsulator and decapsulator 638 have been configured with UDP zero-checksum mode. 640 The above requirements do not change either the requirements 641 specified in [RFC2460] as modified by [RFC6935] or the requirements 642 specified in [RFC6936]. 644 The requirement to check the source IPv6 address in addition to the 645 destination IPv6 address, plus the strong recommendation against 646 reuse of source IPv6 addresses among GRE-in-UDP tunnels collectively 647 provide some mitigation for the absence of UDP checksum coverage of 648 the IPv6 header. A well-managed operator network that satisfies at 649 least one of three conditions listed above in this section provides 650 additional assurance. 652 GRE-in-UDP is suitable for transmission over lower layers in the 653 well-managed operator networks that are allowed by the exceptions 654 stated above and the rate of corruption of the inner IP packet on 655 such networks is not expected to increase by comparison to GRE 656 traffic that is not encapsulated in UDP. For these reasons, GRE-in- 657 UDP does not provide an additional integrity check except when GRE 658 checksum is used when UDP zero-checksum mode is used with IPv6, and 659 this design is in accordance with requirements 2, 3 and 5 specified 660 in Section 5 of [RFC6936]. 662 GRE does not accumulate incorrect state as a consequence of GRE 663 header corruption. A corrupt GRE packet may result in either packet 664 discard or forwarding of the packet without accumulation of GRE 665 state. Active monitoring of GRE-in-UDP traffic for errors is 666 REQUIRED as occurrence of errors will result in some accumulation of 667 error information outside the protocol for operational and 668 management purposes. This design is in accordance with requirement 4 669 specified in Section 5 of [RFC6936]. 671 The remaining requirements specified in Section 5 of [RFC6936] are 672 not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply 673 because GRE does not include a control feedback mechanism. 674 Requirements 8-10 are middlebox requirements that do not apply to 675 GRE-in-UDP tunnel endpoints (see Section 5.2.1 for further middle 676 box discussion). 678 It is worth mentioning that the use of a zero UDP checksum should 679 present the equivalent risk of undetected packet corruption when 680 sending similar packet using GRE-in-IPv6 without UDP [RFC7676] and 681 without GRE checksums. 683 In summary, WMON GRE-in-UDP Tunnel is allowed to use UDP-zero- 684 checksum mode for IPv6 when the conditions and requirements stated 685 above are met. Otherwise the UDP checksum MUST be used for IPv6 as 686 specified in [RFC768] and [RFC2460]. Use of GRE checksum is 687 recommended when the UDP checksum is not used. 689 5.2.1. Middlebox Considerations 691 IPv6 datagrams with a zero UDP checksum will not be passed by any 692 middlebox that validates the checksum based on [RFC2460] or that 693 updates the UDP checksum field, such as NATs or firewalls. Changing 694 this behavior would require such middleboxes to be updated to 695 correctly handle datagrams with zero UDP checksums. The GRE-in-UDP 696 encapsulation does not provide a mechanism to safely fall back to 697 using a checksum when a path change occurs redirecting a tunnel over 698 a path that includes a middlebox that discards IPv6 datagrams with a 699 zero UDP checksum. In this case the GRE-in-UDP tunnel will be black- 700 holed by that middlebox. 702 As such, when any middlebox exists on the path of GRE-in-UDP tunnel, 703 it is RECOMMENDED to use the UDP checksum to reduce the chance that 704 the encapsulated packets to be dropped. Recommended changes to allow 705 firewalls, NATs and other middleboxes to support use of an IPv6 zero 706 UDP checksum are described in Section 5 of [RFC6936]. 708 6. Congestion Considerations 710 Section 3.1.9 of [RFC5405bis] discussed the congestion implications 711 of UDP tunnels. As discussed in [RFC5405bis], because other flows 712 can share the path with one or more UDP tunnels, congestion control 713 [RFC2914] needs to be considered. 715 The impact of congestion must be considered both in terms of the 716 effect on the rest of the network containing a UDP, and in terms of 717 the effect on the flows using the UDP tunnels. The potential impact 718 of congestion from a UDP tunnel depends upon what sort of traffic is 719 carried over the tunnel, as well as the path of the tunnel. 721 In many cases, GRE-in-UDP is used to carry IP traffic. IP traffic is 722 generally assumed to be congestion controlled, and thus a tunnel 723 carrying general IP traffic generally does not need additional 724 congestion control mechanisms. 726 GRE-in-UDP tunnel can be used in some cases to carry traffic that is 727 not necessarily congestion controlled. For example, GRE-in-UDP may 728 be used to carry MPLS that carries pseudowire or VPN traffic where 729 specific bandwidth guarantees are provided to each pseudowire or to 730 each VPN. In such cases, network operators may avoid congestion by 731 careful provisioning of their networks, by rate limiting of user 732 data traffic, and traffic engineering according to path capacity. 733 For this reason, GRE-in-UDP tunnel MUST be used within a single 734 operator's network that utilizes careful provisioning (e.g., rate 735 limiting at the entries of the network while over-provisioning 736 network capacity) to ensure against congestion, or within a limited 737 number of networks whose operators closely cooperate in order to 738 jointly provide this same careful provisioning. 740 The default GRE-in-UDP tunnel can be used to carry IP traffic that 741 is known to be congestion controlled on the Internet. Internet IP 742 traffic is generally assumed to be congestion-controlled. The 743 default GRE-in-UDP tunnel MUST NOT be used over the general Internet, 744 or over non-cooperating network operators, to carry traffic that is 745 not congestion-controlled. 747 WMON GRE-in-UDP Tunnel is used within a well-managed operator 748 network so that it can carry the traffic that is not necessarily 749 congestion controlled. Measures SHOULD be taken to prevent non- 750 congestion-controlled GRE-in-UDP traffic from "escaping" to the 751 general Internet, e.g.: 753 o Physical or logical isolation of the links carrying GRE-in-UDP 754 from the general Internet. 756 o Deployment of packet filters that block the UDP ports assigned 757 for GRE-in-UDP. 759 o Imposition of restrictions on GRE-in-UDP traffic by software 760 tools used to set up GRE-in-UDP tunnels between specific end 761 systems (as might be used within a single data center). For 762 examples, a GRE-in-UDP tunnel only carries IP traffic or a GRE- 763 in-UDP tunnel supports NVGRE encapsulation [RFC7637] only 764 (Although the payload type is Ethernet in NVGRE, NVGRE protocol 765 mandates that the payload of Ethernet is IP). 767 o Use of a "Circuit Breaker" for the tunneled traffic as described 768 in [CB]. 770 7. Backward Compatibility 772 In general, tunnel ingress routers have to be upgraded in order to 773 support the encapsulations described in this document. 775 No change is required at transit routers to support forwarding of 776 the encapsulation described in this document. 778 If a router that is intended for use as a decapsulator does not 779 support or enable GRE-in-UDP encapsulation described in this 780 document, it should not be listening on the destination port (TBD). 781 In these cases, the router will conform to normal UDP processing and 782 respond to an encapsulator with an ICMP message indicating "port 783 unreachable" according to [RFC792]. Upon receiving this ICMP 784 message, the node MUST NOT continue to use GRE-in-UDP encapsulation 785 toward this peer without management intervention. 787 8. IANA Considerations 789 IANA is requested to make the following allocations: 791 One UDP destination port number for the indication of GRE 793 Service Name: GRE-in-UDP 794 Transport Protocol(s): UDP 795 Assignee: IESG 796 Contact: IETF Chair 797 Description: GRE-in-UDP Encapsulation 798 Reference: [This.I-D] 799 Port Number: TBD 800 Service Code: N/A 801 Known Unauthorized Uses: N/A 802 Assignment Notes: N/A 804 One UDP destination port number for the indication of GRE with DTLS 806 Service Name: GRE-UDP-DTLS 807 Transport Protocol(s): UDP 808 Assignee: IESG 809 Contact: IETF Chair 810 Description: GRE-in-UDP Encapsulation with DTLS 811 Reference: [This.I-D] 812 Port Number: TBD 813 Service Code: N/A 814 Known Unauthorized Uses: N/A 815 Assignment Notes: N/A 817 9. Security Considerations 819 GRE-in-UDP encapsulation does not affect security for the payload 820 protocol. When using GRE-in-UDP, Network Security in a network is 821 mostly equivalent to that of a network using GRE. 823 Datagram Transport Layer Security (DTLS) [RFC6347] can be used for 824 application security and can preserve network and transport layer 825 protocol information. Specifically, if DTLS is used to secure the 826 GRE-in-UDP tunnel, the destination port of the UDP header MUST be 827 set to an IANA-assigned value (TBD2) indicating GRE-in-UDP with DTLS, 828 and that UDP port MUST NOT be used for other traffic. The UDP 829 source port field can still be used to add entropy, e.g., for load- 830 sharing purposes. DTLS usage is limited to a single DTLS session 831 for any specific tunnel encapsulator/ decapsulator pair (identified 832 by source and destination IP addresses). Both IP addresses MUST be 833 unicast addresses - multicast traffic is not supported when DTLS is 834 used. A GRE-in-UDP tunnel decapsulator that supports DTLS is 835 expected to be able to establish DTLS sessions with multiple tunnel 836 encapsulators, and likewise an GRE-in-UDP tunnel encapsulator is 837 expected to be able to establish DTLS sessions with multiple 838 decapsulators (although different source and/or destination IP 839 addresses may be involved -see Section 5.2 for discussion of one 840 situation where use of different source IP addresses is important). 842 In the case that UDP source port for entropy usage is disabled, a 843 random port SHOULD be selected in order to minimize the 844 vulnerability to off-path attacks.[RFC6056] The random port may also 845 be periodically changed to mitigate certain denial of service 846 attacks as mentioned in Section 3.2. 848 Using one standardized value as the UDP destination port for an 849 encapsulation indication may increase the vulnerability of off-path 850 attack. To overcome this, an alternate port may be agreed upon to 851 use between an encapsulator and decapsulator [RFC6056]. How the 852 encapsulator end points communicate the value is outside scope of 853 this document. 855 This document does not require that a decapsulator validates the IP 856 source address of the tunneled packets (with the exception that the 857 IPv6 source address MUST be validated when UDP zero-checksum mode is 858 used with IPv6), but it should be understood that failure to do so 859 presupposes that there is effective destination-based (or a 860 combination of source-based and destination-based) filtering at the 861 boundaries. 863 Corruption of GRE header can cause a privacy and security concern 864 for some applications that rely on the key field for traffic 865 segregation. When GRE key field is used for privacy and security, 866 ether UDP checksum or GRE checksum SHOULD be used for GRE-in-UDP 867 with both IPv4 and IPv6, and in particular, when UDP zero-checksum 868 mode is used, GRE checksum SHOULD be used. 870 10. Acknowledgements 872 Authors like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger 873 Geib, Lar Edds, Lloyd Wood, Bob Briscoe, and many others for their 874 review and valuable input on this draft. 876 Thank the design team led by David Black (members: Ross Callon, 877 Gorry Fairhurst, Xiaohu Xu, Lucy Yong) to efficiently work out the 878 descriptions for the congestion considerations and IPv6 UDP zero 879 checksum. 881 11. Contributors 883 The following people all contributed significantly to this document 884 and are listed below in alphabetical order: 886 David Black 887 EMC Corporation 888 176 South Street 889 Hopkinton, MA 01748 890 USA 892 Email: david.black@emc.com 894 Ross Callon 895 Juniper Networks 896 10 Technology Park Drive 897 Westford, MA 01886 898 USA 900 Email: rcallon@juniper.net 902 John E. Drake 903 Juniper Networks 905 Email: jdrake@juniper.net 907 Gorry Fairhurst 908 University of Aberdeen 910 Email: gorry@erg.abdn.ac.uk 912 Yongbing Fan 913 China Telecom 914 Guangzhou, China. 915 Phone: +86 20 38639121 917 Email: fanyb@gsta.com 919 Adrian Farrel 920 Juniper Networks 922 Email: adrian@olddog.co.uk 924 Vishwas Manral 925 Hewlett-Packard Corp. 926 3000 Hanover St, Palo Alto. 928 Email: vishwas.manral@hp.com 930 Carlos Pignataro 931 Cisco Systems 932 7200-12 Kit Creek Road 933 Research Triangle Park, NC 27709 USA 935 EMail: cpignata@cisco.com 937 12. References 939 12.1. Normative References 941 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 942 August 1980. 944 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 945 Communication Layers", RFC1122, October 1989. 947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 948 Requirement Levels", BCP 14, RFC2119, March 1997. 950 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 951 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 952 March 2000. 954 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 955 RFC2890, September 2000. 957 [RFC5405bis] Eggert, L., "Unicast UDP Usage Guideline for 958 Application Designers", draft-ietf-tsvwg-rfc5405bis, work 959 in progress. 961 [RFC6040] Briscoe, B., "Tunneling of Explicit Congestion 962 Notification", RFC6040, November 2010. 964 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 965 Security Version 1.2", RFC6347, 2012. 967 [RFC6438] Carpenter, B., Amante, S., "Using the IPv6 Flow Label for 968 Equal Cost Multipath Routing and Link Aggregation in 969 tunnels", RFC6438, November, 2011. 971 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 972 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 974 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 975 for the Use of IPv6 UDP Datagrams with Zero Checksums", 976 RFC 6936, April 2013. 978 12.2. Informative References 980 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 981 792, September 1981. 983 [RFC793] DARPA, "Transmission Control Protocol", RFC793, September 984 1981. 986 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 987 (IPv6) Specification", RFC 2460, December 1998. 989 [RFC2914] Floyd, S.,"Congestion Control Principles", RFC2914, 990 September 2000. 992 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, 993 October 2000. 995 [RFC4787] Audet, F., et al, "network Address Translation (NAT) 996 Behavioral Requirements for Unicast UDP", RFC4787, January 997 2007. 999 [RFC6056] Larsen, M. and Gont, F., "Recommendations for Transport- 1000 Protocol Port Randomization", RFC6056, January 2011. 1002 [RFC6438] Carpenter, B., Amante, S., "Using the Ipv6 Flow Label for 1003 Equal Cost Multipath Routing and Link Aggreation in 1004 Tunnels", RFC6438, November 2011. 1006 [RFC7588] Bonica, R., "A Fragmentation Strategy for Generic Routing 1007 Encapsulation (GRE)", RFC7588, July 2015. 1009 [RFC7637] Garg, P. and Wang, Y., "NVGRE: Network Virtualization 1010 Using Generic Routing Encapsulation", RFC7637, September 1011 2015. 1013 [RFC7676] Pignataro, C., Bonica, R., Krishnan, S., "IPv6 Support for 1014 Generic Routing Encapsulation (GRE)", RFC7676, October 1015 2015. 1017 [CB] Fairhurst, G., "Network Transport Circuit Breakers", 1018 draft-ietf-tsvwg-circuit-breaker-13, work in progress. 1020 13. Authors' Addresses 1022 Edward Crabbe 1024 Email: edward.crabbe@gmail.com 1026 Lucy Yong 1027 Huawei Technologies, USA 1029 Email: lucy.yong@huawei.com 1031 Xiaohu Xu 1032 Huawei Technologies, 1033 Beijing, China 1035 Email: xuxiaohu@huawei.com 1037 Tom Herbert 1038 Facebook 1039 1 Hacker Way 1040 Menlo Park, CA 1041 Email : tom@herbertland.com