idnits 2.17.1 draft-ietf-tsvwg-gre-in-udp-encap-11.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 10, 2016) is 2966 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 Lucy Yong (Ed.) 2 Internet-Draft Huawei USA 3 Intended status: Standard Track E. Crabbe 5 X. Xu 6 Huawei Technologies 7 T. Herbert 8 Facebook 10 Expires: September 2016 March 10, 2016 12 GRE-in-UDP Encapsulation 13 draft-ietf-tsvwg-gre-in-udp-encap-11 15 Abstract 17 This document describes a method of encapsulating network protocol 18 packets within GRE and UDP headers. The GRE-in-UDP encapsulation 19 allows the UDP source port field to be used as an entropy field. 20 This may be used for load balancing of GRE traffic in transit 21 networks using existing ECMP mechanisms. This document specifies 22 GRE-in-UDP tunnel requirements for two applicability scenarios: (1) 23 general 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 September 10,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. Terminology...............................................3 63 1.2. Requirements Language.....................................4 64 2. Applicability Statement........................................4 65 2.1. GRE-in-UDP Tunnel Usage Requirements......................5 66 2.1.1. Requirements for Default GRE-in-UDP Tunnel...........5 67 2.1.2. Requirements Changes for TMCE GRE-in-UDP Tunnel......6 68 3. GRE-in-UDP Encapsulation.......................................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....................................10 73 3.2.3. Checksum............................................10 74 3.2.4. Length..............................................10 75 3.3. GRE Header...............................................10 76 4. Encapsulation Process Procedures..............................11 77 4.1. MTU and Fragmentation....................................11 78 4.2. Differentiated Services and ECN Marking..................12 79 5. Use of DTLS...................................................12 80 6. UDP Checksum Handling.........................................12 81 6.1. UDP Checksum with IPv4...................................12 82 6.2. UDP Checksum with IPv6...................................13 83 7. Middlebox Considerations......................................16 84 7.1. Middlebox Considerations for Zero Checksums..............17 85 8. Congestion Considerations.....................................17 86 9. Backward Compatibility........................................18 87 10. IANA Considerations..........................................19 88 11. Security Considerations......................................20 89 12. Acknowledgements.............................................20 90 13. Contributors.................................................21 91 14. References...................................................22 92 14.1. Normative References....................................22 93 14.2. Informative References..................................23 94 15. Authors' Addresses...........................................24 96 1. Introduction 98 This document defines a generic GRE-in-UDP encapsulation for 99 tunneling network protocol packets across an IP network. The 100 encapsulation uses Generic Routing Encapsulation (GRE) 101 [RFC2784][RFC7676] and User Datagram Protocol(UDP) [RFC768] headers. 102 The GRE header provides payload protocol type as an EtherType in the 103 protocol type field, and the source port field in the UDP header may 104 be used to provide additional entropy that may be used for load 105 balancing GRE traffic in transit networks using existing Equal-Cost 106 Multi-Path (ECMP) mechanism. The existing ECMP mechanism is that, 107 when the IP payload is a UDP or Transmission Control Protocol (TCP) 108 [RFC793] packet, router hash functions frequently operate on the 109 five-tuple of source IP address, destination IP address, UDP/TCP 110 source port, UDP/TCP destination port, and protocol/next-header. A 111 GRE-in-UDP tunnel offers the additional possibility of using GRE 112 across networks that might otherwise disallow it; for instance GRE- 113 in-UDP may be used to bridge two islands where GRE is not used 114 natively across the Internet. 116 This encapsulation method requires no changes to the transit IP 117 network. Hash functions in most existing IP routers may utilize and 118 benefit from the use of a GRE-in-UDP tunnel without needing any 119 change or upgrade to their ECMP implementation. The encapsulation 120 mechanism is applicable to a variety of IP networks including Data 121 Center and wide area networks. 123 GRE-in-UDP encapsulation may be used to encapsulate already tunneled 124 traffic, i.e. tunnel-in-tunnel. In this case, GRE-in-UDP tunnel do 125 not differentiate such end hosts from other end hosts, i.e., 126 applying the same treatment for traffic from hosts and tunnel 127 endpoints. 129 This document specifies GRE-in-UDP tunnel requirements for two 130 applicability scenarios: (1) general Internet; (2) a traffic-managed 131 controlled environment. The controlled environment has less 132 restrictive requirements than the general Internet. 134 1.1. Terminology 136 The terms defined in [RFC768][RFC2784] are used in this document. 138 A traffic-managed controlled environment: an IP network that is 139 traffic-engineered and/or otherwise managed (e.g., via use of 140 traffic rate limiters) to avoid congestion happening. 142 TMCE GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can only apply to a 143 traffic-managed controlled environment that is defined in Section 2. 145 Default GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can apply to the 146 general Internet. 148 ECMP: Equal-Cost Multi-Path 150 TMCE: Traffic-managed controlled environment (defined in Section 2) 152 1.2. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 2. Applicability Statement 160 GRE-in-UDP encapsulation applies to IPv4 and IPv6 networks. When 161 using GRE-in-UDP encapsulation, packets encapsulated by GRE-in-UDP 162 are treated as UDP datagrams by an IP network. As such, GRE-in-UDP 163 tunnel needs to meet the UDP requirements specified in [RFC5405bis], 164 which imposes the requirements on GRE-in-UDP tunnel usage. These 165 requirements depend on both the delivery network and the nature of 166 the encapsulated traffic. For example, the GRE-in-UDP tunnel 167 protocol does not provide any congestion control functionality 168 beyond that of the encapsulated traffic. Therefore, a GRE-in-UDP 169 tunnel MUST be used only with congestion controlled traffic (e.g., 170 IP traffic) and/or within a network that has traffic management 171 capability to avoid congestion. 173 [RFC5405bis] considers two types of applicability where IETF 174 applications utilize UDP: 1) General Internet and 2) A controlled 175 environment. The controlled environment means a single 176 administrative domain or bilaterally agreed connection between 177 domains. A network forming a controlled environment can be 178 managed/operated to meet certain conditions while the general 179 Internet cannot be; thus the requirements for a tunnel protocol 180 operating under a controlled environment can be less restrictive 181 than the requirements in the general Internet. 183 For the purpose of this document, a traffic-managed controlled 184 environment is defined as an IP network that is traffic-engineered 185 and/or otherwise managed (e.g., via use of traffic rate limiters) to 186 avoid congestion happening. The document specifies GRE-in-UDP tunnel 187 usage in the general Internet and specifies GRE-in-UDP tunnel usage 188 in a traffic-managed controlled environment. Furthermore, a default 189 GRE-in-UDP tunnel described in this document refers to the usage 190 over the general Internet; a TMCE GRE-in-UDP tunnel described in 191 this document refers to the usage in a traffic-managed controlled 192 environment. 194 2.1. GRE-in-UDP Tunnel Usage Requirements 196 This section provides a summary of the requirements for a GRE-in-UDP 197 tunnel. Section 2.1.1 describes the default usage of GRE-in-UDP 198 tunnel that is suitable for the general Internet; Section 2.1.2 199 describes a set of relaxed requirements for a TMCE GRE-in-UDP tunnel 200 used in a traffic-managed controlled environment. Both can be IPv4 201 or IPv6. 203 2.1.1. Requirements for Default GRE-in-UDP Tunnel 205 The following is a summary of the default GRE-in-UDP requirements 206 for use over the general Internet: 208 1. A UDP checksum SHOULD be used when encapsulating in IPv4. 210 2. A UDP checksum MUST be used when encapsulating in IPv6. 212 3. GRE-in-UDP tunnel MUST NOT be used for traffic that does not 213 implement congestion control. IP-traffic can be assumed to be 214 congestion-controlled. GRE-in-UDP tunnels are not appropriate for 215 other traffic that does not use congestion control. 217 4. UDP source port values that are used for flow entropy SHOULD be 218 chosen from the ephemeral port range (49152-65535). 220 5. The use of the UDP source port MUST be configurable so that a 221 single value can be set for all traffic within the tunnel (this 222 disables use of the UDP source port to provide flow entropy). When a 223 single value is set, a random port SHOULD be selected in order to 224 minimize the vulnerability to off-path attacks [RFC6056]. 226 6. For IPv6 delivery networks, the flow entropy SHOULD also be 227 placed in the flow label field for ECMP per [RFC6438]. 229 7. At the tunnel ingress, any fragmentation of the incoming packet 230 (e.g., because the tunnel has an MTU that is smaller than the packet 231 SHOULD be performed before encapsulation [RFC7588]. In addition, the 232 tunnel ingress MUST apply the UDP checksum to all encapsulated 233 fragments so that the tunnel egress can validate reassembly of the 234 fragments; it MUST set the same DSCP value to all fragments. To 235 avoid unwanted forwarding over multiple paths the same source UDP 236 port value SHOULD be set in all packet fragments. 238 2.1.2. Requirements Changes for TMCE GRE-in-UDP Tunnel 240 The section lists the changed requirements for a TMCE GRE-in-UDP 241 Tunnel that applies to a traffic-managed controlled environment. 242 This replaces requirements 1-3 listed in Section 2.1.1. The 243 requirements 4-7 in Section 2.1.1 remain unchanged for a TMCE GRE- 244 in-UDP Tunnel. 246 1. A UDP checksum SHOULD be used when encapsulating in IPv4. A 247 tunnel endpoint sending GRE-in-UDP MAY disable the UDP checksum, 248 since GRE has been designed to work without a UDP checksum [RFC2784]. 249 However, a checksum also offers protection from mis-delivery to 250 another port. 252 2. Use of UDP checksum MUST be the default when encapsulating in 253 IPv6. This default MAY be overridden via configuration of UDP zero- 254 checksum mode. All usage of UDP zero-checksum mode with IPv6 is 255 subject to the additional requirements specified in Section 6.2. 257 3. A GRE-in-UDP tunnel MAY encapsulate traffic that is not 258 congestion controlled. 260 3. GRE-in-UDP Encapsulation 262 The GRE-in-UDP encapsulation format contains UDP header [RFC768] and 263 GRE header [RFC2890]. The format is shown as follows: (presented in 264 bit order) 265 0 1 2 3 266 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 268 IPv4 Header: 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 |Version| IHL |Type of Service| Total Length | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Identification |Flags| Fragment Offset | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Time to Live |Protcol=17(UDP)| Header Checksum | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Source IPv4 Address | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Destination IPv4 Address | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 UDP Header: 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Source Port = Entropy Value | Dest. Port = TBD1/TBD2 | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | UDP Length | UDP Checksum | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 GRE Header: 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 |C| |K|S| Reserved0 | Ver | Protocol Type | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Checksum (optional) | Reserved1 (Optional) | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Key (optional) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Sequence Number (optional) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 IANA Note: Replace TBD1 and TBD2 with the IANA-assigned numbers 301 Figure 1 UDP+GRE Headers in IPv4 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 IPv6 Header: 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 |Version| Traffic Class | Flow Label | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | | 313 + + 314 | | 315 + Outer Source IPv6 Address + 316 | | 317 + + 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 + + 322 | | 323 + Outer Destination IPv6 Address + 324 | | 325 + + 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 UDP Header: 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Source Port = entropy value | Dest. Port = TBD1/TBD2 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | UDP Length | UDP Checksum | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 GRE Header: 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 |C| |K|S| Reserved0 | Ver | Protocol Type | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Checksum (optional) | Reserved1 (Optional) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Key (optional) | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Sequence Number (optional) | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 IANA Note: Replace TBD1 and TBD2 with the IANA-assigned numbers 349 Figure 2 UDP+GRE Headers in IPv6 351 The contents of the IP, UDP, and GRE headers that are relevant in 352 this encapsulation are described below. 354 3.1. IP Header 356 An encapsulator MUST encode its own IP address as the source IP 357 address and the decapsulator's IP address as the destination IP 358 address. A sufficiently large value is needed in the IPv4 TTL field 359 or IPv6 Hop Count field to allow delivery of the encapsulated packet 360 to the peer of the encapsulation. 362 3.2. UDP Header 364 3.2.1. Source Port 366 GRE-in-UDP permits the UDP source port value to be used to encode an 367 entropy value. The UDP source port contains a 16-bit entropy value 368 that is generated by the encapsulator to identify a flow for the 369 encapsulated packet. The port value SHOULD be within the ephemeral 370 port range, i.e., 49152 to 65535, where the high order two bits of 371 the port are set to one. This provides fourteen bits of entropy for 372 the inner flow identifier. In the case that an encapsulator is 373 unable to derive flow entropy from the payload header or the entropy 374 usage has to be disabled to meet operational requirements (see 375 Section 7), to avoid reordering with a packet flow, the encapsulator 376 SHOULD use the same UDP source port value for all packets assigned 377 to a flow e.g., the result of an algorithm that perform a hash of 378 the tunnel ingress and egress IP address. 380 The source port value for a flow set by an encapsulator MAY change 381 over the lifetime of the encapsulated flow. For instance, an 382 encapsulator may change the assignment for Denial of Service (DOS) 383 mitigation or as a means to effect routing through the ECMP network. 384 An encapsulator SHOULD NOT change the source port selected for a 385 flow more than once every thirty seconds. 387 Note: An IPv6 tunnel endpoint should copy a flow entropy value in 388 the IPv6 flow label field (requirement 6). This permits network 389 equipment to inspect this value and utilize it during forwarding, 390 e.g. to perform ECMP [RFC6438]. 392 This document places requirements on the generation of the flow 393 entropy value but does not specify the algorithm that an 394 implementation should use to derive this value. 396 3.2.2. Destination Port 398 The destination port of the UDP header is set either GRE-in-UDP 399 (TBD1) or GRE-UDP-DTLS (TBD2) (see Section 5). IANA Note: Please 400 replace TBD1 and TBD2 with the IANA-assigned numbers. 402 3.2.3. Checksum 404 The UDP checksum is set and processed per [RFC768] and [RFC1122] for 405 IPv4, and [RFC2460] for IPv6. Requirements for checksum handling and 406 use of zero UDP checksums are detailed in Section 6. 408 3.2.4. Length 410 The usage of this field is in accordance with the current UDP 411 specification in [RFC768]. This length will include the UDP header 412 (eight bytes), GRE header, and the GRE payload (encapsulated packet). 414 3.3. GRE Header 416 An encapsulator sets the protocol type (EtherType) of the packet 417 being encapsulated in the GRE Protocol Type field. 419 An encapsulator MAY set the GRE Key Present, Sequence Number Present, 420 and Checksum Present bits and associated fields in the GRE header as 421 defined by [RFC2784] and [RFC2890]. Usage of the reserved bits, i.e., 422 Reserved0, is specified in [RFC2784]. 424 The GRE checksum MAY be enabled to protect the GRE header and 425 payload. When the UDP checksum is enabled, it protects the GRE 426 payload, resulting in the GRE checksum being mostly redundant. 427 Enabling both checksums may result in unnecessary processing. Since 428 the UDP checksum covers the pseudo-header and the packet payload, 429 including the GRE header and its payload, the UDP checksum SHOULD be 430 used in preference to using the GRE checksum. 432 An implementation MAY use the GRE keyid to authenticate the 433 encapsulator. (See Security Section) In this model, a shared value 434 is either configured or negotiated between an encapsulator and 435 decapsulator. When a decapsulator determines a presented keyid is 436 not valid for the source, the packet MUST be dropped. 438 Although GRE-in-UDP encapsulation protocol uses both UDP header and 439 GRE header, it is one tunnel encapsulation protocol. GRE and UDP 440 headers MUST be applied and removed as a pair at the encapsulation 441 and decapsulation points. This specification does not support UDP 442 encapsulation of a GRE header where that GRE header is applied or 443 removed at a network node other than the UDP tunnel ingress or 444 egress. 446 4. Encapsulation Process Procedures 448 The procedures specified in this section apply to both a default 449 GRE-in-UDP tunnel and a TMCE GRE-in-UDP tunnel. 451 The GRE-in-UDP encapsulation allows encapsulated packets to be 452 forwarded through "GRE-in-UDP tunnels". The encapsulator MUST set 453 the UDP and GRE header according to Section 3. 455 Intermediate routers, upon receiving these UDP encapsulated packets, 456 could load balance these packets based on the hash of the five-tuple 457 of UDP packets. 459 Upon receiving these UDP encapsulated packets, the decapsulator 460 decapsulates them by removing the UDP and GRE headers and then 461 processes them accordingly. 463 GRE-in-UDP allows encapsulation of unicast, IPv4 broadcast, or 464 multicast traffic. Entropy may be generated from the header of 465 encapsulated packets at an encapsulator. The mapping mechanism 466 between the encapsulated multicast traffic and the multicast 467 capability in the IP network is transparent and independent to the 468 encapsulation and is otherwise outside the scope of this document. 470 To provide entropy for ECMP, GRE-in-UDP does not rely on GRE keep- 471 alive. It is RECOMMENED not to use GRE keep-alive in the GRE-in-UDP 472 tunnel. This aligns with middlebox traversal guidelines in Section 473 3.5 of [RFC5405bis]. 475 4.1. MTU and Fragmentation 477 Regarding packet fragmentation, an encapsulator/decapsulator SHOULD 478 be compliant with [RFC7588] and perform fragmentation before the 479 encapsulation. The size of fragments SHOULD be less or equal to the 480 PMTU associated with the path between the GRE ingress and the GRE 481 egress tunnel endpoints minus the GRE and UDP overhead, assuming the 482 egress resemble MTU is larger than PMTU. When applying payload 483 fragmentation, the UDP checksum MUST be used so that the receiving 484 endpoint can validate reassembly of the fragments; the same src UDP 485 port SHOULD be used for all packet fragments to ensure the transit 486 routers will forward the fragments on the same path. 488 If the operator of the transit network supporting the tunnel is able 489 to control the payload MTU size, the MTU SHOULD be configured to 490 avoid fragmentation, i.e., sufficient for the largest supported size 491 of packet, including all additional bytes introduced by the tunnel 492 overhead [RFC5405bis]. 494 4.2. Differentiated Services and ECN Marking 496 To ensure that tunneled traffic receives the same treatment over the 497 IP network, prior to the encapsulation process, an encapsulator 498 processes the tunneled IP packet headers to retrieve appropriate 499 parameters for the encapsulating IP packet header such as DiffServ 500 [RFC2983]. Encapsulation end points that support Explicit Congestion 501 Notification (ECN) must use the method described in [RFC6040] for 502 ECN marking propagation. The congestion control process is outside 503 of the scope of this document. 505 Additional information on IP header processing is provided in 506 Section 3.1. 508 5. Use of DTLS 510 Datagram Transport Layer Security (DTLS) [RFC6347] can be used for 511 application security and can preserve network and transport layer 512 protocol information. Specifically, if DTLS is used to secure the 513 GRE-in-UDP tunnel, the destination port of the UDP header MUST be 514 set to an IANA-assigned value (TBD2) indicating GRE-in-UDP with DTLS, 515 and that UDP port MUST NOT be used for other traffic. The UDP 516 source port field can still be used to add entropy, e.g., for load- 517 sharing purposes. DTLS usage is limited to a single DTLS session 518 for any specific tunnel encapsulator/ decapsulator pair (identified 519 by source and destination IP addresses). Both IP addresses MUST be 520 unicast addresses - multicast traffic is not supported when DTLS is 521 used. A GRE-in-UDP tunnel decapsulator that supports DTLS is 522 expected to be able to establish DTLS sessions with multiple tunnel 523 encapsulators, and likewise an GRE-in-UDP tunnel encapsulator is 524 expected to be able to establish DTLS sessions with multiple 525 decapsulators (although different source and/or destination IP 526 addresses may be involved (see Section 6.2) for discussion of one 527 situation where use of different source IP addresses is important). 529 IANA Note: Please replace TBD2 with the IANA-assigned numbers. 531 6. UDP Checksum Handling 533 6.1. UDP Checksum with IPv4 535 For UDP in IPv4, the UDP checksum MUST be processed as specified in 536 [RFC768] and [RFC1122] for both transmit and receive. The IPv4 537 header includes a checksum which protects against mis-delivery of 538 the packet due to corruption of IP addresses. The UDP checksum 539 potentially provides protection against corruption of the UDP header, 540 GRE header, and GRE payload. Disabling the use of checksums is a 541 deployment consideration that should take into account the risk and 542 effects of packet corruption. 544 When a decapsulator receives a packet, the UDP checksum field MUST 545 be processed. If the UDP checksum is non-zero, the decapsulator MUST 546 verify the checksum before accepting the packet. By default a 547 decapsulator SHOULD accept UDP packets with a zero checksum. A node 548 MAY be configured to disallow zero checksums per [RFC1122]; this may 549 be done selectively, for instance disallowing zero checksums from 550 certain hosts that are known to be sending over paths subject to 551 packet corruption. If verification of a non-zero checksum fails, a 552 decapsulator lacks the capability to verify a non-zero checksum, or 553 a packet with a zero-checksum was received and the decapsulator is 554 configured to disallow, the packet MUST be dropped and an event MAY 555 be logged. 557 6.2. UDP Checksum with IPv6 559 For UDP in IPv6, the UDP checksum MUST be processed as specified in 560 [RFC768] and [RFC2460] for both transmit and receive. 562 When UDP is used over IPv6, the UDP checksum is relied upon to 563 protect both the IPv6 and UDP headers from corruption. As such, A 564 default GRE-in-UDP Tunnel MUST perform UDP checksum; A TMCE GRE-in- 565 UDP Tunnel MAY be configured with the UDP zero-checksum mode if the 566 traffic-managed controlled environment or a set of closely 567 cooperating traffic-managed controlled environments (such as by 568 network operators who have agreed to work together in order to 569 jointly provide specific services) meet at least one of following 570 conditions: 572 a. It is known (perhaps through knowledge of equipment types and 573 lower layer checks) that packet corruption is exceptionally 574 unlikely and where the operator is willing to take the risk of 575 undetected packet corruption. 577 b. It is judged through observational measurements (perhaps of 578 historic or current traffic flows that use a non-zero checksum) 579 that the level of packet corruption is tolerably low and where 580 the operator is willing to take the risk of undetected packet 581 corruption. 583 c. Carrying applications that are tolerant of mis-delivered or 584 corrupted packets (perhaps through higher layer checksum, 585 validation, and retransmission or transmission redundancy) where 586 the operator is willing to rely on the applications using the 587 tunnel to survive any corrupt packets. 589 The following requirements apply to a TMCE GRE-in-UDP tunnel that 590 use UDP zero-checksum mode: 592 a. Use of the UDP checksum with IPv6 MUST be the default 593 configuration of all GRE-in-UDP tunnels. 595 b. The GRE-in-UDP tunnel implementation MUST comply with all 596 requirements specified in Section 4 of [RFC6936] and with 597 requirement 1 specified in Section 5 of [RFC6936]. 599 c. The tunnel decapsulator SHOULD only allow the use of UDP zero- 600 checksum mode for IPv6 on a single received UDP Destination 601 Port regardless of the encapsulator. The motivation for this 602 requirement is possible corruption of the UDP Destination Port, 603 which may cause packet delivery to the wrong UDP port. If that 604 other UDP port requires the UDP checksum, the mis-delivered 605 packet will be discarded. 607 d. It is RECOMMENDED that the UDP zero-checksum mode for IPv6 is 608 only enabled for certain selected source addresses. The tunnel 609 decapsulator MUST check that the source and destination IPv6 610 addresses are valid for the GRE-in-UDP tunnel on which the 611 packet was received if that tunnel uses UDP zero-checksum mode 612 and discard any packet for which this check fails. 614 e. The tunnel encapsulator SHOULD use different IPv6 addresses for 615 each GRE-in-UDP tunnel that uses UDP zero-checksum mode 616 regardless of the decapsulator in order to strengthen the 617 decapsulator's check of the IPv6 source address (i.e., the same 618 IPv6 source address SHOULD NOT be used with more than one IPv6 619 destination address, independent of whether that destination 620 address is a unicast or multicast address). When this is not 621 possible, it is RECOMMENDED to use each source IPv6 address for 622 as few UDP zero-checksum mode GRE-in-UDP tunnels as is feasible. 624 f. When any middlebox exists on the path of a GRE-in-UDP tunnel, 625 it is RECOMMENDED to use the default mode, i.e. use UDP 626 checksum, to reduce the chance that the encapsulated packets to 627 be dropped. 629 g. Any middlebox that allows the UDP zero-checksum mode for IPv6 630 MUST comply with requirement 1 and 8-10 in Section 5 of 631 [RFC6936]. 633 h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP 634 checksums from "escaping" to the general Internet; see Section 635 8 for examples of such measures. 637 i. IPv6 traffic with zero UDP checksums MUST be actively monitored 638 for errors by the network operator. For example, the operator 639 may monitor Ethernet layer packet error rates. 641 j. If a packet with a non-zero checksum is received, the checksum 642 MUST be verified before accepting the packet. This is 643 regardless of whether the tunnel encapsulator and decapsulator 644 have been configured with UDP zero-checksum mode. 646 The above requirements do not change either the requirements 647 specified in [RFC2460] as modified by [RFC6935] or the requirements 648 specified in [RFC6936]. 650 The requirement to check the source IPv6 address in addition to the 651 destination IPv6 address, plus the strong recommendation against 652 reuse of source IPv6 addresses among GRE-in-UDP tunnels collectively 653 provide some mitigation for the absence of UDP checksum coverage of 654 the IPv6 header. A traffic-managed controlled environment that 655 satisfies at least one of three conditions listed above in this 656 section provides additional assurance. 658 A GRE-in-UDP tunnel is suitable for transmission over lower layers 659 in the traffic-managed controlled environments that are allowed by 660 the exceptions stated above and the rate of corruption of the inner 661 IP packet on such networks is not expected to increase by comparison 662 to GRE traffic that is not encapsulated in UDP. For these reasons, 663 GRE-in-UDP does not provide an additional integrity check except 664 when GRE checksum is used when UDP zero-checksum mode is used with 665 IPv6, and this design is in accordance with requirements 2, 3 and 5 666 specified in Section 5 of [RFC6936]. 668 Generic Router Encapsulation (GRE) does not accumulate incorrect 669 state as a consequence of GRE header corruption. A corrupt GRE 670 packet may result in either packet discard or forwarding of the 671 packet without accumulation of GRE state. Active monitoring of GRE- 672 in-UDP traffic for errors is REQUIRED as occurrence of errors will 673 result in some accumulation of error information outside the 674 protocol for operational and management purposes. This design is in 675 accordance with requirement 4 specified in Section 5 of [RFC6936]. 677 The remaining requirements specified in Section 5 of [RFC6936] are 678 not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply 679 because GRE does not include a control feedback mechanism. 680 Requirements 8-10 are middlebox requirements that do not apply to 681 GRE-in-UDP tunnel endpoints (see Section 7.1 for further middlebox 682 discussion). 684 It is worth mentioning that the use of a zero UDP checksum should 685 present the equivalent risk of undetected packet corruption when 686 sending similar packet using GRE-in-IPv6 without UDP [RFC7676] and 687 without GRE checksums. 689 In summary, a TMCE GRE-in-UDP Tunnel is allowed to use UDP-zero- 690 checksum mode for IPv6 when the conditions and requirements stated 691 above are met. Otherwise the UDP checksum need to be used for IPv6 692 as specified in [RFC768] and [RFC2460]. Use of GRE checksum is 693 RECOMMENED when the UDP checksum is not used. 695 7. Middlebox Considerations 697 Many middleboxes read or update UDP port information of the packets 698 that they forward. Network Address/Port Translator (NAPT) is the 699 most commonly deployed Network Address Translation (NAT) device 700 [RFC4787]. An NAPT device establishes a NAT session to translate the 701 {private IP address, private source port number} tuple to a {public 702 IP address, public source port number} tuple, and vice versa, for 703 the duration of the UDP session. This provides a UDP application 704 with the "NAT-pass-through" function. NAPT allows multiple internal 705 hosts to share a single public IP address. The port number, i.e., 706 the UDP Source Port number, is used as the demultiplexer of the 707 multiple internal hosts. However, the above NAPT behaviors conflict 708 with the behavior a GRE-in-UDP tunnel that is configured to use the 709 UDP source port value to provide entropy. 711 A GRE-in-UDP tunnel is unidirectional; the tunnel traffic is not 712 expected to be returned back to the UDP source port values used to 713 generate entropy. However some middleboxes (e.g., firewall) assume 714 that bidirectional traffic uses a common pair of UDP ports. This 715 assumption also conflicts with the use of the UDP source port field 716 as entropy. 718 Hence, use of the UDP source port for entropy may impact middleboxes 719 behavior. If a GRE-in-UDP tunnel is expected to be used on a path 720 with a middlebox, the tunnel can be configured to either disable use 721 of the UDP source port for entropy or to configure middleboxes to 722 pass packets with UDP source port entropy. 724 7.1. Middlebox Considerations for Zero Checksums 726 IPv6 datagrams with a zero UDP checksum will not be passed by any 727 middlebox that validates the checksum based on [RFC2460] or that 728 updates the UDP checksum field, such as NATs or firewalls. Changing 729 this behavior would require such middleboxes to be updated to 730 correctly handle datagrams with zero UDP checksums. The GRE-in-UDP 731 encapsulation does not provide a mechanism to safely fall back to 732 using a checksum when a path change occurs redirecting a tunnel over 733 a path that includes a middlebox that discards IPv6 datagrams with a 734 zero UDP checksum. In this case the GRE-in-UDP tunnel will be black- 735 holed by that middlebox. 737 As such, when any middlebox exists on the path of GRE-in-UDP tunnel, 738 it is RECOMMENDED to use the UDP checksum to increase the 739 probability of successful transmission of GRE-in-UDP packets. 740 Recommended changes to allow firewalls, NATs and other middleboxes 741 to support use of an IPv6 zero UDP checksum are described in Section 742 5 of [RFC6936]. 744 8. Congestion Considerations 746 Section 3.1.9 of [RFC5405bis] discussed the congestion implications 747 of UDP tunnels. As discussed in [RFC5405bis], because other flows 748 can share the path with one or more UDP tunnels, congestion control 749 [RFC2914] needs to be considered. 751 The impact of congestion must be considered both in terms of the 752 effect on the rest of the network containing a UDP, and in terms of 753 the effect on the flows using the UDP tunnels. The potential impact 754 of congestion from a UDP tunnel depends upon what sort of traffic is 755 carried over the tunnel, as well as the path of the tunnel. 757 In many cases, a GRE-in-UDP tunnel is used to carry IP traffic. IP 758 traffic is generally assumed to be congestion controlled, and thus a 759 tunnel carrying general IP traffic generally does not need 760 additional congestion control mechanisms. 762 A default GRE-in-UDP tunnel can be used to carry IP traffic that is 763 known to be congestion controlled on the Internet. Internet IP 764 traffic is generally assumed to be congestion-controlled. The 765 default usage MUST NOT be used over the general Internet, or over 766 non-cooperating network operators, to carry traffic that is not 767 congestion-controlled. 769 A TMCE GRE-in-UDP tunnel can be used to carry traffic that is not 770 necessarily congestion controlled. For example, GRE-in-UDP may be 771 used to carry MPLS that carries pseudowire or VPN traffic where 772 specific bandwidth guarantees are provided to each pseudowire or to 773 each VPN. In such cases, network operators may avoid congestion by 774 careful provisioning of their networks, by rate limiting of user 775 data traffic, and traffic engineering according to path capacity. 776 For this reason, when a TMCE GRE-in-UDP tunnel carries this type of 777 traffic, the usage MUST be constrained to a traffic-managed 778 controlled environment (e.g., single operator network that utilizes 779 careful provisioning (e.g., rate limiting at the entries of the 780 network while over-provisioning network capacity) to manage 781 congestion, or within a limited number of networks whose operators 782 closely cooperate in order to jointly provide this same careful 783 provisioning. 785 When a TMCE GRE-in-UDP tunnel is used to carry the traffic that is 786 not necessary congestion controlled, measures SHOULD be taken to 787 prevent non-congestion-controlled GRE-in-UDP traffic from "escaping" 788 to the general Internet, e.g.: 790 o Physical or logical isolation of the links carrying GRE-in-UDP 791 from the general Internet. 793 o Deployment of packet filters that block the UDP ports assigned 794 for GRE-in-UDP. 796 o Imposition of restrictions on GRE-in-UDP traffic by software 797 tools used to set up GRE-in-UDP tunnels between specific end 798 systems (as might be used within a single data center). For 799 examples, a GRE-in-UDP tunnel only carries IP traffic or a GRE- 800 in-UDP tunnel supports NVGRE encapsulation [RFC7637] only 801 (Although the payload type is Ethernet in NVGRE, NVGRE protocol 802 mandates that the payload of Ethernet is IP). 804 o Use of a "Circuit Breaker" for the tunneled traffic as described 805 in [CB]. 807 9. Backward Compatibility 809 In general, tunnel ingress routers have to be upgraded in order to 810 support the encapsulations described in this document. 812 No change is required at transit routers to support forwarding of 813 the encapsulation described in this document. 815 If a tunnel endpoint (a host or router) that is intended for use as 816 a decapsulator does not support or enable the GRE-in-UDP 817 encapsulation described in this document, it is not that an endpoint 818 will listen on the destination port assigned to the GRE- 819 encapsulation (TBD1 and TBD2). In these cases, the endpoint will 820 perform normal UDP processing and respond to an encapsulator with an 821 ICMP message indicating "port unreachable" according to [RFC792]. 822 Upon receiving this ICMP message, the node MUST NOT continue to use 823 GRE-in-UDP encapsulation toward this peer without management 824 intervention. 826 IANA NOTE: Please replace TBD1 and TBD2 with the IANA-assigned 827 numbers. 829 10. IANA Considerations 831 IANA is requested to make the following allocations: 833 One UDP destination port number for the indication of GRE 835 Service Name: GRE-in-UDP 836 Transport Protocol(s): UDP 837 Assignee: IESG 838 Contact: IETF Chair 839 Description: GRE-in-UDP Encapsulation 840 Reference: [This.I-D] 841 Port Number: TBD1 842 Service Code: N/A 843 Known Unauthorized Uses: N/A 844 Assignment Notes: N/A 846 One UDP destination port number for the indication of GRE with DTLS 848 Service Name: GRE-UDP-DTLS 849 Transport Protocol(s): UDP 850 Assignee: IESG 851 Contact: IETF Chair 852 Description: GRE-in-UDP Encapsulation with DTLS 853 Reference: [This.I-D] 854 Port Number: TBD2 855 Service Code: N/A 856 Known Unauthorized Uses: N/A 857 Assignment Notes: N/A 859 11. Security Considerations 861 GRE-in-UDP encapsulation does not affect security for the payload 862 protocol. When using GRE-in-UDP, Network Security in a network is 863 mostly equivalent to that of a network using GRE. 865 To secure original traffic, DTLS SHOULD be used. (See Section 5) 867 In the case that UDP source port for entropy usage is disabled, a 868 random port SHOULD be selected in order to minimize the 869 vulnerability to off-path attacks.[RFC6056] The random port may also 870 be periodically changed to mitigate certain denial of service 871 attacks as mentioned in Section 3.2.1. 873 Using one standardized value as the UDP destination port for an 874 encapsulation indication may increase the vulnerability of off-path 875 attack. To overcome this, an alternate port may be agreed upon to 876 use between an encapsulator and decapsulator [RFC6056]. How the 877 encapsulator end points communicate the value is outside scope of 878 this document. 880 This document does not require that a decapsulator validates the IP 881 source address of the tunneled packets (with the exception that the 882 IPv6 source address MUST be validated when UDP zero-checksum mode is 883 used with IPv6), but it should be understood that failure to do so 884 presupposes that there is effective destination-based (or a 885 combination of source-based and destination-based) filtering at the 886 boundaries. 888 Corruption of a GRE header can cause a privacy and security concern 889 for some applications that rely on the key field for traffic 890 segregation. When GRE key field is used for privacy and security, 891 ether UDP checksum or GRE checksum SHOULD be used for GRE-in-UDP 892 with both IPv4 and IPv6, and in particular, when UDP zero-checksum 893 mode is used, GRE checksum SHOULD be used. 895 12. Acknowledgements 897 Authors like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger 898 Geib, Lar Edds, Lloyd Wood, Bob Briscoe, and many others for their 899 review and valuable input on this draft. 901 Thank the design team led by David Black (members: Ross Callon, 902 Gorry Fairhurst, Xiaohu Xu, Lucy Yong) to efficiently work out the 903 descriptions for the congestion considerations and IPv6 UDP zero 904 checksum. 906 Thank David Black and Gorry Fairhurst for their great help in 907 document editing. 909 13. Contributors 911 The following people all contributed significantly to this document 912 and are listed below in alphabetical order: 914 David Black 915 EMC Corporation 916 176 South Street 917 Hopkinton, MA 01748 918 USA 920 Email: david.black@emc.com 922 Ross Callon 923 Juniper Networks 924 10 Technology Park Drive 925 Westford, MA 01886 926 USA 928 Email: rcallon@juniper.net 930 John E. Drake 931 Juniper Networks 933 Email: jdrake@juniper.net 935 Gorry Fairhurst 936 University of Aberdeen 938 Email: gorry@erg.abdn.ac.uk 940 Yongbing Fan 941 China Telecom 942 Guangzhou, China. 943 Phone: +86 20 38639121 945 Email: fanyb@gsta.com 946 Adrian Farrel 947 Juniper Networks 949 Email: adrian@olddog.co.uk 951 Vishwas Manral 952 Hewlett-Packard Corp. 953 3000 Hanover St, Palo Alto. 955 Email: vishwas.manral@hp.com 957 Carlos Pignataro 958 Cisco Systems 959 7200-12 Kit Creek Road 960 Research Triangle Park, NC 27709 USA 962 EMail: cpignata@cisco.com 964 14. References 966 14.1. Normative References 968 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 969 August 1980. 971 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 972 Communication Layers", RFC1122, October 1989. 974 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 975 Requirement Levels", BCP 14, RFC2119, March 1997. 977 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 978 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 979 March 2000. 981 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 982 RFC2890, September 2000. 984 [RFC5405bis] Eggert, L., "Unicast UDP Usage Guideline for 985 Application Designers", draft-ietf-tsvwg-rfc5405bis, work 986 in progress. 988 [RFC6040] Briscoe, B., "Tunneling of Explicit Congestion 989 Notification", RFC6040, November 2010. 991 [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer 992 Security Version 1.2", RFC6347, 2012. 994 [RFC6438] Carpenter, B., Amante, S., "Using the IPv6 Flow Label for 995 Equal Cost Multipath Routing and Link Aggregation in 996 tunnels", RFC6438, November, 2011. 998 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 999 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1001 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1002 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1003 RFC 6936, April 2013. 1005 14.2. Informative References 1007 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 1008 792, September 1981. 1010 [RFC793] DARPA, "Transmission Control Protocol", RFC793, September 1011 1981. 1013 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1014 (IPv6) Specification", RFC 2460, December 1998. 1016 [RFC2914] Floyd, S.,"Congestion Control Principles", RFC2914, 1017 September 2000. 1019 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, 1020 October 2000. 1022 [RFC4787] Audet, F., et al, "network Address Translation (NAT) 1023 Behavioral Requirements for Unicast UDP", RFC4787, January 1024 2007. 1026 [RFC6056] Larsen, M. and Gont, F., "Recommendations for Transport- 1027 Protocol Port Randomization", RFC6056, January 2011. 1029 [RFC6438] Carpenter, B., Amante, S., "Using the Ipv6 Flow Label for 1030 Equal Cost Multipath Routing and Link Aggreation in 1031 Tunnels", RFC6438, November 2011. 1033 [RFC7588] Bonica, R., "A Fragmentation Strategy for Generic Routing 1034 Encapsulation (GRE)", RFC7588, July 2015. 1036 [RFC7637] Garg, P. and Wang, Y., "NVGRE: Network Virtualization 1037 Using Generic Routing Encapsulation", RFC7637, September 1038 2015. 1040 [RFC7676] Pignataro, C., Bonica, R., Krishnan, S., "IPv6 Support for 1041 Generic Routing Encapsulation (GRE)", RFC7676, October 1042 2015. 1044 [CB] Fairhurst, G., "Network Transport Circuit Breakers", 1045 draft-ietf-tsvwg-circuit-breaker-13, work in progress. 1047 15. Authors' Addresses 1049 Edward Crabbe 1051 Email: edward.crabbe@gmail.com 1053 Lucy Yong 1054 Huawei Technologies, USA 1056 Email: lucy.yong@huawei.com 1058 Xiaohu Xu 1059 Huawei Technologies, 1060 Beijing, China 1062 Email: xuxiaohu@huawei.com 1064 Tom Herbert 1065 Facebook 1066 1 Hacker Way 1067 Menlo Park, CA 1068 Email : tom@herbertland.com