idnits 2.17.1 draft-ietf-intarea-frag-fragile-09.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 (February 12, 2019) is 1899 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-09 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-datagram-plpmtud-06 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-05 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area WG R. Bonica 3 Internet-Draft Juniper Networks 4 Intended status: Best Current Practice F. Baker 5 Expires: August 16, 2019 Unaffiliated 6 G. Huston 7 APNIC 8 R. Hinden 9 Check Point Software 10 O. Troan 11 Cisco 12 F. Gont 13 SI6 Networks 14 February 12, 2019 16 IP Fragmentation Considered Fragile 17 draft-ietf-intarea-frag-fragile-09 19 Abstract 21 This document describes IP fragmentation and explains how it reduces 22 the reliability of Internet communication. 24 This document also proposes alternatives to IP fragmentation and 25 provides recommendations for developers and network operators. 27 Status of This Memo 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 https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 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 August 16, 2019. 44 Copyright Notice 46 Copyright (c) 2019 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 (https://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 respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. IP Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Links, Paths, MTU and PMTU . . . . . . . . . . . . . . . 3 64 2.2. Fragmentation Procedures . . . . . . . . . . . . . . . . 5 65 2.3. Upper-Layer Reliance on IP Fragmentation . . . . . . . . 6 66 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 7 67 4. Reduced Reliability . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. Policy-Based Routing . . . . . . . . . . . . . . . . . . 7 69 4.2. Network Address Translation (NAT) . . . . . . . . . . . . 8 70 4.3. Stateless Firewalls . . . . . . . . . . . . . . . . . . . 9 71 4.4. Equal Cost Multipath, Link Aggregate Groups and Stateless 72 Load-Balancers . . . . . . . . . . . . . . . . . . . . . 9 73 4.5. IPv4 Reassembly Errors at High Data Rates . . . . . . . . 10 74 4.6. Security Vulnerabilities . . . . . . . . . . . . . . . . 10 75 4.7. PMTU Blackholing Due to ICMP Loss . . . . . . . . . . . . 11 76 4.7.1. Transient Loss . . . . . . . . . . . . . . . . . . . 12 77 4.7.2. Incorrect Implementation of Security Policy . . . . . 12 78 4.7.3. Persistent Loss Caused By Anycast . . . . . . . . . . 13 79 4.8. Blackholing Due To Filtering or Loss . . . . . . . . . . 13 80 5. Alternatives to IP Fragmentation . . . . . . . . . . . . . . 14 81 5.1. Transport Layer Solutions . . . . . . . . . . . . . . . . 14 82 5.2. Application Layer Solutions . . . . . . . . . . . . . . . 15 83 6. Applications That Rely on IPv6 Fragmentation . . . . . . . . 16 84 6.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 6.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 6.3. Packet-in-Packet Encapsulations . . . . . . . . . . . . . 17 87 6.4. Licklider Transmission Protocol (LTP) . . . . . . . . . . 18 88 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18 89 7.1. For Application and Protocol Developers . . . . . . . . . 18 90 7.2. For System Developers . . . . . . . . . . . . . . . . . . 18 91 7.3. For Middle Box Developers . . . . . . . . . . . . . . . . 19 92 7.4. For ECMP, LAG and Load-Balancer Developers And Operators 19 93 7.5. For Network Operators . . . . . . . . . . . . . . . . . . 19 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 99 11.2. Informative References . . . . . . . . . . . . . . . . . 21 100 Appendix A. Contributors' Address . . . . . . . . . . . . . . . 25 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 103 1. Introduction 105 Operational experience [Kent] [Huston] [RFC7872] reveals that IP 106 fragmentation reduces the reliability of Internet communication. 107 This document describes IP fragmentation and explains how it reduces 108 the reliability of Internet communication. This document also 109 proposes alternatives to IP fragmentation and provides 110 recommendations for developers and network operators. 112 While this document identifies issues associated with IP 113 fragmentation, it does not recommend deprecation. Some applications 114 (see Section 6) require IP fragmentation. Furthermore, fragmentation 115 is expected to work in limited domains where security and 116 interoperability issues can be addressed. 118 Rather than deprecating IP Fragmentation, this document recommends 119 that upper-layer protocols address the problem of fragmentation at 120 their layer, reducing their reliance on IP fragmentation to the 121 greatest degree possible. 123 2. IP Fragmentation 125 2.1. Links, Paths, MTU and PMTU 127 An Internet path connects a source node to a destination node. A 128 path can contain links and routers. If a path contains more than one 129 link, the links are connected in series and a router connects each 130 link to the next. 132 Internet paths are dynamic. Assume that the path from one node to 133 another contains a set of links and routers. If the network topology 134 changes, that path can also change so that it includes a different 135 set of links and routers. 137 Each link is constrained by the number of bytes that it can convey in 138 a single IP packet. This constraint is called the link Maximum 139 Transmission Unit (MTU). IPv4 [RFC0791] requires every link to 140 support a specified MTU (see NOTE 1). IPv6 [RFC8200] requires every 141 link to support an MTU of 1280 bytes or greater. These are called 142 the IPv4 and IPv6 minimum link MTU's. 144 Likewise, each Internet path is constrained by the number of bytes 145 that it can convey in a IP single packet. This constraint is called 146 the Path MTU (PMTU). For any given path, the PMTU is equal to the 147 smallest of its link MTU's. Because Internet paths are dynamic, PMTU 148 is also dynamic. 150 For reasons described below, source nodes estimate the PMTU between 151 themselves and destination nodes. A source node can produce 152 extremely conservative PMTU estimates in which: 154 o The estimate for each IPv4 path is equal to the IPv4 minimum link 155 MTU. 157 o The estimate for each IPv6 path is equal to the IPv6 minimum link 158 MTU. 160 While these conservative estimates are guaranteed to be less than or 161 equal to the actual PMTU, they are likely to be much less than the 162 actual PMTU. This may adversely affect upper-layer protocol 163 performance. 165 By executing Path MTU Discovery (PMTUD) [RFC1191] [RFC8201] 166 procedures, a source node can maintain a less conservative estimate 167 of the PMTU between itself and a destination node. In PMTUD, the 168 source node produces an initial PMTU estimate. This initial estimate 169 is equal to the MTU of the first link along the path to the 170 destination node. It can be greater than the actual PMTU. 172 Having produced an initial PMTU estimate, the source node sends non- 173 fragmentable IP packets to the destination node (see NOTE 2). If one 174 of these packets is larger than the actual PMTU, a downstream router 175 will not be able to forward the packet through the next link along 176 the path. Therefore, the downstream router drops the packet and 177 sends an Internet Control Message Protocol (ICMP) [RFC0792] [RFC4443] 178 Packet Too Big (PTB) message to the source node (see NOTE 3). The 179 ICMP PTB message indicates the MTU of the link through which the 180 packet could not be forwarded. The source node uses this information 181 to refine its PMTU estimate. 183 PMTUD produces a running estimate of the PMTU between a source node 184 and a destination node. Because PMTU is dynamic, at any given time, 185 the PMTU estimate can differ from the actual PMTU. In order to 186 detect PMTU increases, PMTUD occasionally resets the PMTU estimate to 187 its initial value and repeats the procedure described above. 189 Ideally, PMTUD operates as described above. However, in some 190 scenarios, PMTUD fails. For example: 192 o PMTUD relies on the network's ability to deliver ICMP PTB messages 193 to the source node. If the network cannot deliver ICMP PTB 194 messages to the source node, PMTUD fails. 196 o PMTUD is susceptible to attack because ICMP messages are easily 197 forged [RFC5927]. Such attacks can cause PMTUD to produce 198 unnecessarily conservative PMTU estimates. 200 NOTE 1: In IPv4, every host must be capable of receiving a packet 201 whose length is equal to 576 bytes. However, the IPv4 minimum link 202 MTU is not 576. Section 3.2 of RFC 791 explicitly states that the 203 IPv4 minimum link MTU is 68 bytes. But for practical purposes, many 204 network operators consider the IPv4 minimum link MTU to be 576 bytes. 205 So, for the purposes of this document, we assume that the IPv4 206 minimum link MTU is 576 bytes. 208 NOTE 2: A non-fragmentable packet can be fragmented at its source. 209 However, it cannot be fragmented by a downstream node. An IPv4 210 packet whose DF-bit is set to zero is fragmentable. An IPv4 packet 211 whose DF-bit is set to one is non-fragmentable. All IPv6 packets are 212 also non-fragmentable. 214 NOTE 3:: The ICMP PTB message has two instantiations. In ICMPv4 215 [RFC0792], the ICMP PTB message is Destination Unreachable message 216 with Code equal to (4) fragmentation needed and DF set. This message 217 was augmented by [RFC1191] to indicate the MTU of the link through 218 which the packet could not be forwarded. In ICMPv6 [RFC4443], the 219 ICMP PTB message is a Packet Too Big Message with Code equal to (0). 220 This message also indicates the MTU of the link through which the 221 packet could not be forwarded. 223 2.2. Fragmentation Procedures 225 When an upper-layer protocol submits data to the underlying IP 226 module, and the resulting IP packet's length is greater than the 227 PMTU, the packet is divided into fragments. Each fragment includes 228 an IP header and a portion of the original packet. 230 [RFC0791] describes IPv4 fragmentation procedures. An IPv4 packet 231 whose DF-bit is set to one can be fragmented by the source node, but 232 cannot be fragmented by a downstream router. An IPv4 packet whose 233 DF-bit is set to zero can be fragmented by the source node or by a 234 downstream router. When an IPv4 packet is fragmented, all IP options 235 appear in the first fragment, but only options whose "copy" bit is 236 set to one appear in subsequent fragments. 238 [RFC8200] describes IPv6 fragmentation procedures. An IPv6 packet 239 can be fragmented at the source node only. When an IPv6 packet is 240 fragmented, all extension headers appear in the first fragment, but 241 only per-fragment headers appear in subsequent fragments. Per- 242 fragment headers include the following: 244 o The IPv6 header. 246 o The Hop-by-hop Options header (if present) 248 o The Destination Options header (if present and if it precedes a 249 Routing header) 251 o The Routing Header (if present) 253 o The Fragment Header 255 In both IPv4 and IPv6, the upper-layer header appears in the first 256 fragment only. It does not appear in subsequent fragments. 258 2.3. Upper-Layer Reliance on IP Fragmentation 260 Upper-layer protocols can operate in the following modes: 262 o Do not rely on IP fragmentation. 264 o Rely on IP fragmentation by the source node only. 266 o Rely on IP fragmentation by any node. 268 Upper-layer protocols running over IPv4 can operate in all of the 269 above-mentioned modes. Upper-layer protocols running over IPv6 can 270 operate in the first and second modes only. 272 Upper-layer protocols that operate in the first two modes (above) 273 require access to the PMTU estimate. In order to fulfil this 274 requirement, they can: 276 o Estimate the PMTU to be equal to the IPv4 or IPv6 minimum link 277 MTU. 279 o Access the estimate that PMTUD produced. 281 o Execute PMTUD procedures themselves. 283 o Execute Packetization Layer PMTUD (PLPMTUD) [RFC4821] 284 [I-D.ietf-tsvwg-datagram-plpmtud] procedures. 286 According to PLPMTUD procedures, the upper-layer protocol maintains a 287 running PMTU estimate. It does so by sending probe packets of 288 various sizes to its upper-layer peer and receiving acknowledgements. 289 This strategy differs from PMTUD in that it relies of acknowledgement 290 of received messages, as opposed to ICMP PTB messages concerning 291 dropped messages. Therefore, PLPMTUD does not rely on the network's 292 ability to deliver ICMP PTB messages to the source. 294 3. Requirements Language 296 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 297 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 298 "OPTIONAL" in this document are to be interpreted as described in BCP 299 14 [RFC2119] [RFC8174] when, and only when, they appear in all 300 capitals, as shown here. 302 4. Reduced Reliability 304 This section explains how IP fragmentation reduces the reliability of 305 Internet communication. 307 4.1. Policy-Based Routing 309 IP Fragmentation causes problems for routers that implement policy- 310 based routing. 312 When a router receives a packet, it identifies the next-hop on route 313 to the packet's destination and forwards the packet to that next-hop. 314 In order to identify the next-hop, the router interrogates a local 315 data structure called the Forwarding Information Base (FIB). 317 Normally, the FIB contains destination-based entries that map a 318 destination prefix to a next-hop. Policy-based routing allows 319 destination-based and policy-based entries to coexist in the same 320 FIB. A policy-based FIB entry maps multiple fields, drawn from 321 either the IP or transport-layer header, to a next-hop. 323 +-------+--------------+-----------------+------------+-------------+ 324 | Entry | Type | Dest. Prefix | Next Hdr / | Next-Hop | 325 | | | | Dest. Port | | 326 +-------+--------------+-----------------+------------+-------------+ 327 | | | | | | 328 | 1 | Destination- | 2001:db8::1/128 | Any / Any | 2001:db8::2 | 329 | | based | | | | 330 | | | | | | 331 | 2 | Policy- | 2001:db8::1/128 | TCP / 80 | 2001:db8::3 | 332 | | based | | | | 333 +-------+--------------+-----------------+------------+-------------+ 335 Table 1: Policy-Based Routing FIB 337 Assume that a router maintains the FIB in Table 1. The first FIB 338 entry is destination-based. It maps the a destination prefix 339 (2001:db8::1/128) to a next-hop (2001:db8::2). The second FIB entry 340 is policy-based. It maps the same destination prefix 341 (2001:db8::1/128) and a destination port ( TCP / 80 ) to a different 342 next-hop (2001:db8::3). The second entry is more specific than the 343 first. 345 When the router receives the first fragment of a packet that is 346 destined for TCP port 80 on 2001:db8::1, it interrogates the FIB. 347 Both FIB entries satisfy the query. The router selects the second 348 FIB entry because it is more specific and forwards the packet to 349 2001:db8::3. 351 When the router receives the second fragment of the packet, it 352 interrogates the FIB again. This time, only the first FIB entry 353 satisfies the query, because the second fragment contains no 354 indication that the packet is destined for TCP port 80. Therefore, 355 the router selects the first FIB entry and forwards the packet to 356 2001:db8::2. 358 Policy-based routing is also known as filter-based-forwarding. 360 4.2. Network Address Translation (NAT) 362 IP fragmentation causes problems for Network Address Translation 363 (NAT) devices. When a NAT device detects a new, outbound flow, it 364 maps that flow's source port and IP address to another source port 365 and IP address. Having created that mapping, the NAT device 366 translates: 368 o The Source IP Address and Source Port on each outbound packet. 370 o The Destination IP Address and Destination Port on each inbound 371 packet. 373 A+P [RFC6346] and Carrier Grade NAT (CGN) [RFC6888] are two common 374 NAT strategies. In both approaches the NAT device must virtually 375 reassemble fragmented packets in order to translate and forward each 376 fragment. 378 Virtual reassembly in the network is problematic, because it is 379 computationally expensive and because it is prone to attacks 380 (Section 4.6). 382 4.3. Stateless Firewalls 384 IP fragmentation causes problems for stateless firewalls whose rules 385 include TCP and UDP ports. Because port information is not available 386 in the trailing fragments the firewall is limited to the following 387 options: 389 o Accept all trailing fragments, possibly admitting certain classes 390 of attack. 392 o Block all trailing fragments, possibly blocking legitimate 393 traffic. 395 Neither option is attractive. 397 4.4. Equal Cost Multipath, Link Aggregate Groups and Stateless Load- 398 Balancers 400 IP fragmentation causes problems for Equal Cost Multipath (ECMP), 401 Link Aggregate Groups (LAG) and other stateless load-balancing 402 technologies. In order to assign a packet or packet fragment to a 403 link, an intermediate node executes a hash (i.e., load-balancing) 404 algorithm. The following paragraphs describe a commonly deployed 405 hash algorithm. 407 If the packet or packet fragment contains a transport-layer header, 408 the algorithm accepts the following 5-tuple as input: 410 o IP Source Address. 412 o IP Destination Address. 414 o IPv4 Protocol or IPv6 Next Header. 416 o transport-layer source port. 418 o transport-layer destination port. 420 If the packet or packet fragment does not contain a transport-layer 421 header, the algorithm accepts only the following 3-tuple as input: 423 o IP Source Address. 425 o IP Destination Address. 427 o IPv4 Protocol or IPv6 Next Header. 429 Therefore, non-fragmented packets belonging to a flow can be assigned 430 to one link while fragmented packets belonging to the same flow can 431 be divided between that link and another. This can cause suboptimal 432 load-balancing. 434 [RFC6438] offers a partial solution to this problem for IPv6 devices 435 only. According to [RFC6438]: 437 "At intermediate routers that perform load distribution, the hash 438 algorithm used to determine the outgoing component-link in an ECMP 439 and/or LAG toward the next hop MUST minimally include the 3-tuple 440 {dest addr, source addr, flow label} and MAY also include the 441 remaining components of the 5-tuple." 443 If the algorithm includes only the 3-tuple {dest addr, source addr, 444 flow label}, it will assign all fragments belonging to a packet to 445 the same link. (See [RFC6437] and [RFC7098]). 447 4.5. IPv4 Reassembly Errors at High Data Rates 449 IPv4 fragmentation is not sufficiently robust for use under some 450 conditions in today's Internet. At high data rates, the 16-bit IP 451 identification field is not large enough to prevent frequent 452 incorrectly assembled IP fragments, and the TCP and UDP checksums are 453 insufficient to prevent the resulting corrupted datagrams from being 454 delivered to higher protocol layers. [RFC4963] describes some easily 455 reproduced experiments demonstrating the problem, and discusses some 456 of the operational implications of these observations. 458 These reassembly issues are not easily reproducible in IPv6 because 459 the IPv6 identification field is 32 bits long. 461 4.6. Security Vulnerabilities 463 Security researchers have documented several attacks that exploit IP 464 fragmentation. The following are examples: 466 o Overlapping fragment attacks [RFC1858][RFC3128][RFC5722] 468 o Resource exhaustion attacks (such as the Rose Attack) 470 o Attacks based on predictable fragment identification values 471 [RFC7739] 473 o Evasion of Network Intrusion Detection Systems (NIDS) [Ptacek1998] 475 In the overlapping fragment attack, an attacker constructs a series 476 of packet fragments. The first fragment contains an IP header, a 477 transport-layer header, and some transport-layer payload. This 478 fragment complies with local security policy and is allowed to pass 479 through a stateless firewall. A second fragment, having a non-zero 480 offset, overlaps with the first fragment. The second fragment also 481 passes through the stateless firewall. When the packet is 482 reassembled, the transport layer header from the first fragment is 483 overwritten by data from the second fragment. The reassembled packet 484 does not comply with local security policy. Had it traversed the 485 firewall in one piece, the firewall would have rejected it. 487 A stateless firewall cannot protect against the overlapping fragment 488 attack. However, destination nodes can protect against the 489 overlapping fragment attack by implementing the procedures described 490 in RFC 1858, RFC 3128 and RFC 8200. These reassembly procedures 491 detect the overlap and discard the packet. 493 The fragment reassembly algorithm is a stateful procedure for an 494 otherwise stateless protocol. Therefore, it can be exploited by 495 resource exhaustion attacks. An attacker can construct a series of 496 fragmented packets, with one fragment missing from each packet so 497 that the reassembly is impossible. Thus, this attack causes resource 498 exhaustion on the destination node, possibly denying reassembly 499 services to other flows. This type of attack can be mitigated by 500 flushing fragment reassembly buffers when necessary, at the expense 501 of possibly dropping legitimate fragments. 503 Each IP fragment contains an "Identification" field that destination 504 nodes use to reassemble fragmented packets. Many implementations set 505 the Identification field to a predictable value, thus making it easy 506 for an attacker to forge malicious IP fragments that would cause the 507 reassembly procedure for legitimate packets to fail. 509 NIDS aims at identifying malicious activity by analyzing network 510 traffic. Ambiguity in the possible result of the fragment reassembly 511 process may allow an attacker to evade these systems. Many of these 512 systems try to mitigate some of these evasion techniques (e.g. By 513 computing all possible outcomes of the fragment reassembly process, 514 at the expense of increased processing requirements). 516 4.7. PMTU Blackholing Due to ICMP Loss 518 As mentioned in Section 2.3, upper-layer protocols can be configured 519 to rely on PMTUD. Because PMTUD relies upon the network to deliver 520 ICMP PTB messages, those protocols also rely on the networks to 521 deliver ICMP PTB messages. 523 According to [RFC4890], ICMP PTB messages must not be filtered. 524 However, ICMP PTB delivery is not reliable. It is subject to both 525 transient and persistent loss. 527 Transient loss of ICMP PTB messages can cause transient PMTU black 528 holes. When the conditions contributing to transient loss abate, the 529 network regains its ability to deliver ICMP PTB messages and 530 connectivity between the source and destination nodes is restored. 531 Section 4.7.1 of this document describes conditions that lead to 532 transient loss of ICMP PTB messages. 534 Persistent loss of ICMP PTB messages can cause persistent black 535 holes. Section 4.7.2 and Section 4.7.3 of this document describe 536 conditions that lead to persistent loss of ICMP PTB messages. 538 The problem described in this section is specific to PMTUD. It does 539 not occur when the upper-layer protocol obtains its PMTU estimate 540 from PLPMTUD or from any other source. 542 4.7.1. Transient Loss 544 The following factors can contribute to transient loss of ICMP PTB 545 messages: 547 o Network congestion. 549 o Packet corruption. 551 o Transient routing loops. 553 o ICMP rate limiting. 555 The effect of rate limiting may be severe, as RFC 4443 recommends 556 strict rate limiting of IPv6 traffic. 558 4.7.2. Incorrect Implementation of Security Policy 560 Incorrect implementation of security policy can cause persistent loss 561 of ICMP PTB messages. 563 Assume that a Customer Premise Equipment (CPE) router implements the 564 following zone-based security policy: 566 o Allow any traffic to flow from the inside zone to the outside 567 zone. 569 o Do not allow any traffic to flow from the outside zone to the 570 inside zone unless it is part of an existing flow (i.e., it was 571 elicited by an outbound packet). 573 When a correct implementation of the above-mentioned security policy 574 receives an ICMP PTB message, it examines the ICMP PTB payload in 575 order to determine whether the original packet (i.e., the packet that 576 elicited the ICMP PTB message) belonged to an existing flow. If the 577 original packet belonged to an existing flow, the implementation 578 allows the ICMP PTB to flow from the outside zone to the inside zone. 579 If not, the implementation discards the ICMP PTB message. 581 When a incorrect implementation of the above-mentioned security 582 policy receives an ICMP PTB message, it discards the packet because 583 its source address is not associated with an existing flow. 585 The security policy described above is implemented incorrectly on 586 many consumer CPE routers. 588 4.7.3. Persistent Loss Caused By Anycast 590 Anycast can cause persistent loss of ICMP PTB messages. Consider the 591 example below: 593 A DNS client sends a request to an anycast address. The network 594 routes that DNS request to the nearest instance of that anycast 595 address (i.e., a DNS Server). The DNS server generates a response 596 and sends it back to the DNS client. While the response does not 597 exceed the DNS server's PMTU estimate, it does exceed the actual 598 PMTU. 600 A downstream router drops the packet and sends an ICMP PTB message 601 the packet's source (i.e., the anycast address). The network routes 602 the ICMP PTB message to the anycast instance closest to the 603 downstream router. That anycast instance may not be the DNS server 604 that originated the DNS response. It may be another DNS server with 605 the same anycast address. The DNS server that originated the 606 response may never receive the ICMP PTB message and may never update 607 its PMTU estimate. 609 4.8. Blackholing Due To Filtering or Loss 611 In RFC 7872, researchers sampled Internet paths to determine whether 612 they would convey packets that contain IPv6 extension headers. 613 Sampled paths terminated at popular Internet sites (e.g., popular 614 web, mail and DNS servers). 616 The study revealed that at least 28% of the sampled paths did not 617 convey packets containing the IPv6 Fragment extension header. In 618 most cases, fragments were dropped in the destination autonomous 619 system. In other cases, the fragments were dropped in transit 620 autonomous systems. 622 Another recent study [Huston] confirmed this finding. It reported 623 that 37% of sampled endpoints used IPv6-capable DNS resolvers that 624 were incapable of receiving a fragmented IPv6 response. 626 It is difficult to determine why network operators drop fragments. 627 Possible causes follow: 629 o Hardware inability to process fragmented packets. 631 o Failure to change vendor defaults. 633 o Unintentional misconfiguration. 635 o Intentional configuration (e.g., network operators consciously 636 chooses to drop IPv6 fragments in order to address the issues 637 raised in Section 4.1 through Section 4.7, above.) 639 5. Alternatives to IP Fragmentation 641 5.1. Transport Layer Solutions 643 The Transport Control Protocol (TCP) [RFC0793]) can be operated in a 644 mode that does not require IP fragmentation. 646 Applications submit a stream of data to TCP. TCP divides that stream 647 of data into segments, with no segment exceeding the TCP Maximum 648 Segment Size (MSS). Each segment is encapsulated in a TCP header and 649 submitted to the underlying IP module. The underlying IP module 650 prepends an IP header and forwards the resulting packet. 652 If the TCP MSS is sufficiently small, the underlying IP module never 653 produces a packet whose length is greater than the actual PMTU. 654 Therefore, IP fragmentation is not required. 656 TCP offers the following mechanisms for MSS management: 658 o Manual configuration 660 o PMTUD 662 o PLPMTUD 663 Manual configuration is always applicable. If the MSS is configured 664 to a sufficiently low value, the IP layer will never produce a packet 665 whose length is greater than the protocol minimum link MTU. However, 666 manual configuration prevents TCP from taking advantage of larger 667 link MTU's. 669 Upper-layer protocols can implement PMTUD in order to discover and 670 take advantage of larger path MTUs. However, as mentioned in 671 Section 2.1, PMTUD relies upon the network to deliver ICMP PTB 672 messages. Therefore, PMTUD is applicable only in environments where 673 the risk of ICMP PTB loss is acceptable. 675 By contrast, PLPMTUD does not rely upon the network's ability to 676 deliver ICMP PTB messages. However, in many loss-based TCP 677 congestion control algorithms, the dropping of a packet may cause the 678 TCP control algorithm to drop the congestion control window, or even 679 re-start with the entire slow start process. For high capacity, long 680 round-trip time, large volume TCP streams, the deliberate probing 681 with large packets and the consequent packet drop may impose too 682 harsh a penalty on total TCP throughput for it to be a viable 683 approach. [RFC4821] defines PLPMTUD procedures for TCP. 685 While TCP will never cause the underlying IP module to emit a packet 686 that is larger than the PMTU estimate, it can cause the underlying IP 687 module to emit a packet that is larger than the actual PMTU. If this 688 occurs, the packet is dropped, the PMTU estimate is updated, the 689 segment is divided into smaller segments and each smaller segment is 690 submitted to the underlying IP module. 692 The Datagram Congestion Control Protocol (DCCP) [RFC4340] and the 693 Stream Control Protocol (SCP) [RFC4960] also can be operated in a 694 mode that does not require IP fragmentation. They both accept data 695 from an application and divide that data into segments, with no 696 segment exceeding a maximum size. Both DCCP and SCP offer manual 697 configuration, PMTUD and PLPMTUD as mechanisms for managing that 698 maximum size. [I-D.ietf-tsvwg-datagram-plpmtud] proposes PLPMTUD 699 procedures for DCCP and SCP. 701 Currently, User Data Protocol (UDP) [RFC0768] lacks a fragmentation 702 mechanism of its own and relies on IP fragmentation. However, 703 [I-D.ietf-tsvwg-udp-options] proposes a fragmentation mechanism for 704 UDP. 706 5.2. Application Layer Solutions 708 [RFC8085] recognizes that IP fragmentation reduces the reliability of 709 Internet communication. It also recognizes that UDP lacks a 710 fragmentation mechanism of its own and relies on IP fragmentation. 712 Therefore, [RFC8085] offers the following advice regarding 713 applications the run over the UDP. 715 "An application SHOULD NOT send UDP datagrams that result in IP 716 packets that exceed the Maximum Transmission Unit (MTU) along the 717 path to the destination. Consequently, an application SHOULD either 718 use the path MTU information provided by the IP layer or implement 719 Path MTU Discovery (PMTUD) itself to determine whether the path to a 720 destination will support its desired message size without 721 fragmentation." 723 RFC 8085 continues: 725 "Applications that do not follow the recommendation to do PMTU/ 726 PLPMTUD discovery SHOULD still avoid sending UDP datagrams that would 727 result in IP packets that exceed the path MTU. Because the actual 728 path MTU is unknown, such applications SHOULD fall back to sending 729 messages that are shorter than the default effective MTU for sending 730 (EMTU_S in [RFC1122]). For IPv4, EMTU_S is the smaller of 576 bytes 731 and the first-hop MTU. For IPv6, EMTU_S is 1280 bytes. The 732 effective PMTU for a directly connected destination (with no routers 733 on the path) is the configured interface MTU, which could be less 734 than the maximum link payload size. Transmission of minimum-sized 735 UDP datagrams is inefficient over paths that support a larger PMTU, 736 which is a second reason to implement PMTU discovery." 738 RFC 8085 assumes that for IPv4, an EMTU_S of 576 is sufficiently 739 small, even though the IPv4 minimum link MTU is 68 bytes. 741 This advice applies equally to application that run directly over IP. 743 6. Applications That Rely on IPv6 Fragmentation 745 The following applications rely on IPv6 fragmentation: 747 o DNS [RFC1035] 749 o OSPFv3 [RFC2328][RFC5340] 751 o Packet-in-packet encapsulations 753 Each of these applications relies on IPv6 fragmentation to a varying 754 degree. In some cases, that reliance is essential, and cannot be 755 broken without fundamentally changing the protocol. In other cases, 756 that reliance is incidental, and most implementations already take 757 appropriate steps to avoid fragmentation. 759 This list is not comprehensive, and other protocols that rely on IP 760 fragmentation may exist. They are not specifically considered in the 761 context of this document. 763 6.1. DNS 765 DNS relies on UDP for efficiency, and the consequence is the use of 766 IP fragmentation for large responses, as permitted by the DNS EDNS(0) 767 options in the query. It is possible to mitigate the issue of 768 fragmentation-based packet loss by having queries use smaller EDNS(0) 769 UDP buffer sizes, or by having the DNS server limit the size of its 770 UDP responses to some self-imposed maximum packet size that may be 771 less than the preferred EDNS(0) UDP Buffer Size. In both cases, 772 large responses are truncated in the DNS, signalling to the client to 773 re-query using TCP to obtain the complete response. However, the 774 operational issue of the partial level of support for DNS over TCP, 775 particularly in the case where IPv6 transport is being used, becomes 776 a limiting factor of the efficacy of this approach [Damas]. 778 Larger DNS responses can normally be avoided by aggressively pruning 779 the Additional section of DNS responses. One scenario where such 780 pruning is ineffective is in the use of DNSSEC, where large key sizes 781 act to increase the response size to certain DNS queries. There is 782 no effective response to this situation within the DNS other than 783 using smaller cryptographic keys and adoption of DNSSEC 784 administrative practices that attempt to keep DNS response as short 785 as possible. 787 6.2. OSPF 789 OSPF implementations can emit messages large enough to cause 790 fragmentation. However, in order to optimize performance, most OSPF 791 implementations restrict their maximum message size to a value that 792 will not cause fragmentation. 794 6.3. Packet-in-Packet Encapsulations 796 In this document, packet-in-packet encapsulations include IP-in-IP 797 [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP 798 [RFC8086] and Generic Packet Tunneling in IPv6 [RFC2473]. [RFC4459] 799 describes fragmentation issues associated with all of the above- 800 mentioned encapsulations. 802 The fragmentation strategy described for GRE in [RFC7588] has been 803 deployed for all of the above-mentioned encapsulations. This 804 strategy does not rely on IP fragmentation except in one corner case. 805 (see Section 3.3.2.2 of RFC 7588 and Section 7.1 of RFC 2473). 806 Section 3.3 of [RFC7676] further describes this corner case. 808 See [I-D.ietf-intarea-tunnels] for further discussion. 810 6.4. Licklider Transmission Protocol (LTP) 812 Some UDP applications rely on IP fragmentation to achieve acceptable 813 levels of performance. These applications use UDP datagram sizes 814 that are larger than the path MTU so that more data can be conveyed 815 between the application and the kernel in a single system call. 817 For example, the Licklider Transmission Protocol (LTP) [RFC5326] 818 which is in current use on the International Space Station (ISS) uses 819 UDP datagram sizes larger than the path MTU to achieve acceptable 820 levels of performance even though this invokes IP fragmentation. 822 7. Recommendations 824 7.1. For Application and Protocol Developers 826 Developers SHOULD NOT develop new protocols or applications that rely 827 on IP fragmentation. When a new protocol or application is deployed 828 in an environment that does not fully support IP fragmentation, it 829 SHOULD operate correctly, either in its default configuration or in a 830 specified alternative configuration. 832 Developers MAY develop new protocols or applications that rely on IP 833 fragmentation if the protocol or application is to be run only in 834 environments where IP fragmentation is known to be supported. 836 Legacy protocols that depend upon IP fragmentation SHOULD be updated 837 to break that dependency. However, in some cases, there may be no 838 viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP- 839 in-IP encapsulation). In these cases, the protocol will continue to 840 rely on IP fragmentation but should only be used in environments 841 where IP fragmentation is known to be supported. 843 Protocols may be able to avoid IP fragmentation by using a 844 sufficiently small MTU (e.g. The protocol minimum link MTU), 845 disabling IP fragmentation, and ensuring that the transport protocol 846 in use adapts its segment size to the MTU. Other protocols may 847 deploy a sufficiently reliable PMTU discovery mechanism 848 (e.g.,PLMPTUD). 850 7.2. For System Developers 852 Software libraries SHOULD include provision for PLPMTUD for each 853 supported transport protocol. 855 7.3. For Middle Box Developers 857 Middle boxes SHOULD process IP fragments in a manner that is 858 consistent with [RFC0791] and [RFC8200]. In many cases, middle boxes 859 must maintain state in order to achieve this goal. 861 Price and performance considerations frequently motivate network 862 operators to deploy stateless middle boxes. These stateless middle 863 boxes may perform sub-optimally, process IP fragments in a manner 864 that is not compliant with RFC 791 or RFC 8200, or even discard IP 865 fragments completely. Such behaviors are NOT RECOMMENDED. If a 866 middleboxes implements non-standard behavior with respect to IP 867 fragmentation, then that behavior MUST be clearly documented. 869 7.4. For ECMP, LAG and Load-Balancer Developers And Operators 871 In their default configuration, when the IPv6 Flow Label is not equal 872 to zero, IPv6 devices that implement ECMP, LAG or other load- 873 balancing technologies SHOULD accept only the following fields as 874 input to their hash algorithm: 876 o IP Source Address. 878 o IP Destination Address. 880 o Flow Label. 882 Operators SHOULD deploy these devices in their default configuration. 884 7.5. For Network Operators 886 Operators MUST ensure proper PMTUD operation in their network, 887 including making sure the network generates PTB packets when dropping 888 packets too large compared to outgoing interface MTU. 890 As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB 891 messages unless they are known to be forged or otherwise 892 illegitimate. As stated in Section 4.7, filtering ICMPv6 PTB packets 893 causes PMTUD to fail. Many upper-layer protocols rely on PMTUD. 895 As per RFC 8200, network operators MUST NOT deploy IPv6 links whose 896 MTU is less than 1280 bytes. 898 Network operators SHOULD NOT filter IP fragments if they originated 899 at a domain name server or are destined for a domain name server. 901 8. IANA Considerations 903 This document makes no request of IANA. 905 9. Security Considerations 907 This document mitigates some of the security considerations 908 associated with IP fragmentation by discouraging its use. It does 909 not introduce any new security vulnerabilities, because it does not 910 introduce any new alternatives to IP fragmentation. Instead, it 911 recommends well-understood alternatives. 913 10. Acknowledgements 915 Thanks to Mikael Abrahamsson, Brian Carpenter, Silambu Chelvan, 916 Lorenzo Colitti, Mike Heard, Tom Herbert, Tatuya Jinmei, Jen Linkova, 917 Paolo Lucente, Manoj Nayak, Eric Nygren, Fred Templin and Joe Touch 918 for their comments. 920 11. References 922 11.1. Normative References 924 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 925 DOI 10.17487/RFC0768, August 1980, 926 . 928 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 929 DOI 10.17487/RFC0791, September 1981, 930 . 932 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 933 RFC 792, DOI 10.17487/RFC0792, September 1981, 934 . 936 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 937 RFC 793, DOI 10.17487/RFC0793, September 1981, 938 . 940 [RFC1035] Mockapetris, P., "Domain names - implementation and 941 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 942 November 1987, . 944 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 945 DOI 10.17487/RFC1191, November 1990, 946 . 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, 950 DOI 10.17487/RFC2119, March 1997, 951 . 953 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 954 Control Message Protocol (ICMPv6) for the Internet 955 Protocol Version 6 (IPv6) Specification", STD 89, 956 RFC 4443, DOI 10.17487/RFC4443, March 2006, 957 . 959 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 960 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 961 . 963 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 964 "IPv6 Flow Label Specification", RFC 6437, 965 DOI 10.17487/RFC6437, November 2011, 966 . 968 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 969 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 970 March 2017, . 972 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 973 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 974 May 2017, . 976 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 977 (IPv6) Specification", STD 86, RFC 8200, 978 DOI 10.17487/RFC8200, July 2017, 979 . 981 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 982 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 983 DOI 10.17487/RFC8201, July 2017, 984 . 986 11.2. Informative References 988 [Damas] Damas, J. and G. Huston, "Measuring ATR", April 2018, 989 . 991 [Huston] Huston, G., "IPv6, Large UDP Packets and the DNS 992 (http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html)", 993 August 2017. 995 [I-D.ietf-intarea-tunnels] 996 Touch, J. and M. Townsley, "IP Tunnels in the Internet 997 Architecture", draft-ietf-intarea-tunnels-09 (work in 998 progress), July 2018. 1000 [I-D.ietf-tsvwg-datagram-plpmtud] 1001 Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler, 1002 "Packetization Layer Path MTU Discovery for Datagram 1003 Transports", draft-ietf-tsvwg-datagram-plpmtud-06 (work in 1004 progress), November 2018. 1006 [I-D.ietf-tsvwg-udp-options] 1007 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 1008 udp-options-05 (work in progress), July 2018. 1010 [Kent] Kent, C. and J. Mogul, ""Fragmentation Considered 1011 Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in 1012 Computer Communications Technology, DOI 1013 10.1145/55483.55524", August 1987, 1014 . 1017 [Ptacek1998] 1018 Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial 1019 of Service: Eluding Network Intrusion Detection", 1998, 1020 . 1022 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1023 Communication Layers", STD 3, RFC 1122, 1024 DOI 10.17487/RFC1122, October 1989, 1025 . 1027 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1028 Considerations for IP Fragment Filtering", RFC 1858, 1029 DOI 10.17487/RFC1858, October 1995, 1030 . 1032 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1033 DOI 10.17487/RFC2003, October 1996, 1034 . 1036 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1037 DOI 10.17487/RFC2328, April 1998, 1038 . 1040 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1041 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1042 December 1998, . 1044 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1045 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1046 DOI 10.17487/RFC2784, March 2000, 1047 . 1049 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1050 Fragment Attack (RFC 1858)", RFC 3128, 1051 DOI 10.17487/RFC3128, June 2001, 1052 . 1054 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1055 Congestion Control Protocol (DCCP)", RFC 4340, 1056 DOI 10.17487/RFC4340, March 2006, 1057 . 1059 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1060 Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 1061 2006, . 1063 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1064 ICMPv6 Messages in Firewalls", RFC 4890, 1065 DOI 10.17487/RFC4890, May 2007, 1066 . 1068 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1069 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1070 . 1072 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1073 Errors at High Data Rates", RFC 4963, 1074 DOI 10.17487/RFC4963, July 2007, 1075 . 1077 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 1078 Transmission Protocol - Specification", RFC 5326, 1079 DOI 10.17487/RFC5326, September 2008, 1080 . 1082 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1083 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1084 . 1086 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 1087 RFC 5722, DOI 10.17487/RFC5722, December 2009, 1088 . 1090 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 1091 DOI 10.17487/RFC5927, July 2010, 1092 . 1094 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 1095 the IPv4 Address Shortage", RFC 6346, 1096 DOI 10.17487/RFC6346, August 2011, 1097 . 1099 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1100 for Equal Cost Multipath Routing and Link Aggregation in 1101 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1102 . 1104 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 1105 A., and H. Ashida, "Common Requirements for Carrier-Grade 1106 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 1107 April 2013, . 1109 [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 1110 Flow Label for Load Balancing in Server Farms", RFC 7098, 1111 DOI 10.17487/RFC7098, January 2014, 1112 . 1114 [RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely 1115 Deployed Solution to the Generic Routing Encapsulation 1116 (GRE) Fragmentation Problem", RFC 7588, 1117 DOI 10.17487/RFC7588, July 2015, 1118 . 1120 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 1121 for Generic Routing Encapsulation (GRE)", RFC 7676, 1122 DOI 10.17487/RFC7676, October 2015, 1123 . 1125 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1126 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1127 February 2016, . 1129 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1130 "Observations on the Dropping of Packets with IPv6 1131 Extension Headers in the Real World", RFC 7872, 1132 DOI 10.17487/RFC7872, June 2016, 1133 . 1135 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 1136 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 1137 March 2017, . 1139 Appendix A. Contributors' Address 1141 Authors' Addresses 1143 Ron Bonica 1144 Juniper Networks 1145 2251 Corporate Park Drive 1146 Herndon, Virginia 20171 1147 USA 1149 Email: rbonica@juniper.net 1151 Fred Baker 1152 Unaffiliated 1153 Santa Barbara, California 93117 1154 USA 1156 Email: FredBaker.IETF@gmail.com 1158 Geoff Huston 1159 APNIC 1160 6 Cordelia St 1161 Brisbane, 4101 QLD 1162 Australia 1164 Email: gih@apnic.net 1166 Robert M. Hinden 1167 Check Point Software 1168 959 Skyway Road 1169 San Carlos, California 94070 1170 USA 1172 Email: bob.hinden@gmail.com 1174 Ole Troan 1175 Cisco 1176 Philip Pedersens vei 1 1177 N-1366 Lysaker 1178 Norway 1180 Email: ot@cisco.com 1181 Fernando Gont 1182 SI6 Networks 1183 Evaristo Carriego 2644 1184 Haedo, Provincia de Buenos Aires 1185 Argentina 1187 Email: fgont@si6networks.com