idnits 2.17.1 draft-ietf-intarea-frag-fragile-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 14, 2019) is 1808 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) == Unused Reference: 'RFC6864' is defined on line 1147, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-datagram-plpmtud-07 ** 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 (-32) exists of draft-ietf-tsvwg-udp-options-07 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 5 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: November 15, 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 May 14, 2019 16 IP Fragmentation Considered Fragile 17 draft-ietf-intarea-frag-fragile-10 19 Abstract 21 This document describes IP fragmentation and explains how it 22 introduces fragility to 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 November 15, 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 1.1. IP-in-IP Tunnels . . . . . . . . . . . . . . . . . . . . 3 63 2. IP Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Links, Paths, MTU and PMTU . . . . . . . . . . . . . . . 3 65 2.2. Fragmentation Procedures . . . . . . . . . . . . . . . . 5 66 2.3. Upper-Layer Reliance on IP Fragmentation . . . . . . . . 6 67 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 7 68 4. Increased Fragility . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. Policy-Based Routing . . . . . . . . . . . . . . . . . . 7 70 4.2. Network Address Translation (NAT) . . . . . . . . . . . . 8 71 4.3. Stateless Firewalls . . . . . . . . . . . . . . . . . . . 9 72 4.4. Equal Cost Multipath, Link Aggregate Groups and Stateless 73 Load-Balancers . . . . . . . . . . . . . . . . . . . . . 9 74 4.5. IPv4 Reassembly Errors at High Data Rates . . . . . . . . 10 75 4.6. Security Vulnerabilities . . . . . . . . . . . . . . . . 11 76 4.7. PMTU Blackholing Due to ICMP Loss . . . . . . . . . . . . 12 77 4.7.1. Transient Loss . . . . . . . . . . . . . . . . . . . 12 78 4.7.2. Incorrect Implementation of Security Policy . . . . . 13 79 4.7.3. Persistent Loss Caused By Anycast . . . . . . . . . . 13 80 4.7.4. Persistent Loss Caused By Unidirectional Routing . . 14 81 4.8. Blackholing Due To Filtering or Loss . . . . . . . . . . 14 82 5. Alternatives to IP Fragmentation . . . . . . . . . . . . . . 15 83 5.1. Transport Layer Solutions . . . . . . . . . . . . . . . . 15 84 5.2. Application Layer Solutions . . . . . . . . . . . . . . . 16 85 6. Applications That Rely on IPv6 Fragmentation . . . . . . . . 17 86 6.1. Domain Name Service (DNS) . . . . . . . . . . . . . . . . 17 87 6.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . 18 88 6.3. Packet-in-Packet Encapsulations . . . . . . . . . . . . . 18 89 6.4. UDP Applications Enhancing Performance . . . . . . . . . 18 90 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18 91 7.1. For Application and Protocol Developers . . . . . . . . . 18 92 7.2. For System Developers . . . . . . . . . . . . . . . . . . 19 93 7.3. For Middle Box Developers . . . . . . . . . . . . . . . . 19 94 7.4. For ECMP, LAG and Load-Balancer Developers And Operators 19 95 7.5. For Network Operators . . . . . . . . . . . . . . . . . . 20 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 101 11.2. Informative References . . . . . . . . . . . . . . . . . 22 102 Appendix A. Contributors' Address . . . . . . . . . . . . . . . 25 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 105 1. Introduction 107 Operational experience [Kent] [Huston] [RFC7872] reveals that IP 108 fragmentation introduces fragility to Internet communication. This 109 document describes IP fragmentation and explains how it introduces 110 fragility to Internet communication. This document also proposes 111 alternatives to IP fragmentation and provides recommendations for 112 developers and network operators. 114 While this document identifies issues associated with IP 115 fragmentation, it does not recommend deprecation. Some applications 116 (see Section 6) require IP fragmentation. Furthermore, fragmentation 117 is expected to work in domains where security and interoperability 118 issues are addressed. 120 Rather than deprecating IP Fragmentation, this document recommends 121 that upper-layer protocols address the problem of fragmentation at 122 their layer, reducing their reliance on IP fragmentation to the 123 greatest degree possible. 125 1.1. IP-in-IP Tunnels 127 This document acknowledges that in some cases, packets must be 128 fragmented within IP-in-IP tunnels [I-D.ietf-intarea-tunnels]. 129 Therefore, this document makes no recommendations regarding IP-in-IP 130 tunnels. 132 2. IP Fragmentation 134 2.1. Links, Paths, MTU and PMTU 136 An Internet path connects a source node to a destination node. A 137 path can contain links and routers. If a path contains more than one 138 link, the links are connected in series and a router connects each 139 link to the next. 141 Internet paths are dynamic. Assume that the path from one node to 142 another contains a set of links and routers. If a link fails, the 143 path can also change so that it includes a different set of links and 144 routers. 146 Each link is constrained by the number of bytes that it can convey in 147 a single IP packet. This constraint is called the link Maximum 148 Transmission Unit (MTU). IPv4 [RFC0791] requires every link to 149 support a specified MTU (see NOTE 1). IPv6 [RFC8200] requires every 150 link to support an MTU of 1280 bytes or greater. These are called 151 the IPv4 and IPv6 minimum link MTU's. 153 Likewise, each Internet path is constrained by the number of bytes 154 that it can convey in a IP single packet. This constraint is called 155 the Path MTU (PMTU). For any given path, the PMTU is equal to the 156 smallest of its link MTU's. Because Internet paths are dynamic, PMTU 157 is also dynamic. 159 For reasons described below, source nodes estimate the PMTU between 160 themselves and destination nodes. A source node can produce 161 extremely conservative PMTU estimates in which: 163 o The estimate for each IPv4 path is equal to the IPv4 minimum link 164 MTU. 166 o The estimate for each IPv6 path is equal to the IPv6 minimum link 167 MTU. 169 While these conservative estimates are guaranteed to be less than or 170 equal to the actual PMTU, they are likely to be much less than the 171 actual PMTU. This may adversely affect upper-layer protocol 172 performance. 174 By executing Path MTU Discovery (PMTUD) [RFC1191] [RFC8201] 175 procedures, a source node can maintain a less conservative estimate 176 of the PMTU between itself and a destination node. In PMTUD, the 177 source node produces an initial PMTU estimate. This initial estimate 178 is equal to the MTU of the first link along the path to the 179 destination node. It can be greater than the actual PMTU. 181 Having produced an initial PMTU estimate, the source node sends non- 182 fragmentable IP packets to the destination node (see NOTE 2). If one 183 of these packets is larger than the actual PMTU, a downstream router 184 will not be able to forward the packet through the next link along 185 the path. Therefore, the downstream router drops the packet and 186 sends an Internet Control Message Protocol (ICMP) [RFC0792] [RFC4443] 187 Packet Too Big (PTB) message to the source node (see NOTE 3). The 188 ICMP PTB message indicates the MTU of the link through which the 189 packet could not be forwarded. The source node uses this information 190 to refine its PMTU estimate. 192 PMTUD produces a running estimate of the PMTU between a source node 193 and a destination node. Because PMTU is dynamic, at any given time, 194 the PMTU estimate can differ from the actual PMTU. In order to 195 detect PMTU increases, PMTUD occasionally resets the PMTU estimate to 196 its initial value and repeats the procedure described above. 198 Ideally, PMTUD operates as described above. However, in some 199 scenarios, PMTUD fails. For example: 201 o PMTUD relies on the network's ability to deliver ICMP PTB messages 202 to the source node. If the network cannot deliver ICMP PTB 203 messages to the source node, PMTUD fails. 205 o PMTUD is susceptible to attack because ICMP messages are easily 206 forged [RFC5927] and not authenticated by the receiver. Such 207 attacks can cause PMTUD to produce unnecessarily conservative PMTU 208 estimates. 210 NOTE 1: In IPv4, every host must be capable of receiving a packet 211 whose length is equal to 576 bytes. However, the IPv4 minimum link 212 MTU is not 576. Section 3.2 of RFC 791 explicitly states that the 213 IPv4 minimum link MTU is 68 bytes. But for practical purposes, many 214 network operators consider the IPv4 minimum link MTU to be 576 bytes. 215 So, for the purposes of this document, we assume that the IPv4 216 minimum path MTU is 576 bytes. 218 NOTE 2: A non-fragmentable packet can be fragmented at its source. 219 However, it cannot be fragmented by a downstream node. An IPv4 220 packet whose DF-bit is set to zero is fragmentable. An IPv4 packet 221 whose DF-bit is set to one is non-fragmentable. All IPv6 packets are 222 also non-fragmentable. 224 NOTE 3:: The ICMP PTB message has two instantiations. In ICMPv4 225 [RFC0792], the ICMP PTB message is Destination Unreachable message 226 with Code equal to (4) fragmentation needed and DF set. This message 227 was augmented by [RFC1191] to indicate the MTU of the link through 228 which the packet could not be forwarded. In ICMPv6 [RFC4443], the 229 ICMP PTB message is a Packet Too Big Message with Code equal to (0). 230 This message also indicates the MTU of the link through which the 231 packet could not be forwarded. 233 2.2. Fragmentation Procedures 235 When an upper-layer protocol submits data to the underlying IP 236 module, and the resulting IP packet's length is greater than the 237 PMTU, the packet is divided into fragments. Each fragment includes 238 an IP header and a portion of the original packet. 240 [RFC0791] describes IPv4 fragmentation procedures. An IPv4 packet 241 whose DF-bit is set to one can be fragmented by the source node, but 242 cannot be fragmented by a downstream router. An IPv4 packet whose 243 DF-bit is set to zero can be fragmented by the source node or by a 244 downstream router. When an IPv4 packet is fragmented, all IP options 245 appear in the first fragment, but only options whose "copy" bit is 246 set to one appear in subsequent fragments. 248 [RFC8200] describes IPv6 fragmentation procedures. An IPv6 packet 249 can be fragmented at the source node only. When an IPv6 packet is 250 fragmented, all extension headers appear in the first fragment, but 251 only per-fragment headers appear in subsequent fragments. Per- 252 fragment headers include the following: 254 o The IPv6 header. 256 o The Hop-by-hop Options header (if present) 258 o The Destination Options header (if present and if it precedes a 259 Routing header) 261 o The Routing Header (if present) 263 o The Fragment Header 265 In both IPv4 and IPv6, the upper-layer header appears in the first 266 fragment only. It does not appear in subsequent fragments. 268 2.3. Upper-Layer Reliance on IP Fragmentation 270 Upper-layer protocols can operate in the following modes: 272 o Do not rely on IP fragmentation. 274 o Rely on IP fragmentation by the source node only. 276 o Rely on IP fragmentation by any node. 278 Upper-layer protocols running over IPv4 can operate in all of the 279 above-mentioned modes. Upper-layer protocols running over IPv6 can 280 operate in the first and second modes only. 282 Upper-layer protocols that operate in the first two modes (above) 283 require access to the PMTU estimate. In order to fulfil this 284 requirement, they can: 286 o Estimate the PMTU to be equal to the IPv4 or IPv6 minimum link 287 MTU. 289 o Access the estimate that PMTUD produced. 291 o Execute PMTUD procedures themselves. 293 o Execute Packetization Layer PMTUD (PLPMTUD) [RFC4821] 294 [I-D.ietf-tsvwg-datagram-plpmtud] procedures. 296 According to PLPMTUD procedures, the upper-layer protocol maintains a 297 running PMTU estimate. It does so by sending probe packets of 298 various sizes to its upper-layer peer and receiving acknowledgements. 299 This strategy differs from PMTUD in that it relies of acknowledgement 300 of received messages, as opposed to ICMP PTB messages concerning 301 dropped messages. Therefore, PLPMTUD does not rely on the network's 302 ability to deliver ICMP PTB messages to the source. 304 3. Requirements Language 306 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 307 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 308 "OPTIONAL" in this document are to be interpreted as described in BCP 309 14 [RFC2119] [RFC8174] when, and only when, they appear in all 310 capitals, as shown here. 312 4. Increased Fragility 314 This section explains how IP fragmentation introduces fragility to 315 Internet communication. 317 4.1. Policy-Based Routing 319 IP Fragmentation causes problems for routers that implement policy- 320 based routing. 322 When a router receives a packet, it identifies the next-hop on route 323 to the packet's destination and forwards the packet to that next-hop. 324 In order to identify the next-hop, the router interrogates a local 325 data structure called the Forwarding Information Base (FIB). 327 Normally, the FIB contains destination-based entries that map a 328 destination prefix to a next-hop. Policy-based routing allows 329 destination-based and policy-based entries to coexist in the same 330 FIB. A policy-based FIB entry maps multiple fields, drawn from 331 either the IP or transport-layer header, to a next-hop. 333 +-------+--------------+-----------------+------------+-------------+ 334 | Entry | Type | Dest. Prefix | Next Hdr / | Next-Hop | 335 | | | | Dest. Port | | 336 +-------+--------------+-----------------+------------+-------------+ 337 | | | | | | 338 | 1 | Destination- | 2001:db8::1/128 | Any / Any | 2001:db8::2 | 339 | | based | | | | 340 | | | | | | 341 | 2 | Policy- | 2001:db8::1/128 | TCP / 80 | 2001:db8::3 | 342 | | based | | | | 343 +-------+--------------+-----------------+------------+-------------+ 345 Table 1: Policy-Based Routing FIB 347 Assume that a router maintains the FIB in Table 1. The first FIB 348 entry is destination-based. It maps the a destination prefix 349 (2001:db8::1/128) to a next-hop (2001:db8::2). The second FIB entry 350 is policy-based. It maps the same destination prefix 351 (2001:db8::1/128) and a destination port ( TCP / 80 ) to a different 352 next-hop (2001:db8::3). The second entry is more specific than the 353 first. 355 When the router receives the first fragment of a packet that is 356 destined for TCP port 80 on 2001:db8::1, it interrogates the FIB. 357 Both FIB entries satisfy the query. The router selects the second 358 FIB entry because it is more specific and forwards the packet to 359 2001:db8::3. 361 When the router receives the second fragment of the packet, it 362 interrogates the FIB again. This time, only the first FIB entry 363 satisfies the query, because the second fragment contains no 364 indication that the packet is destined for TCP port 80. Therefore, 365 the router selects the first FIB entry and forwards the packet to 366 2001:db8::2. 368 Policy-based routing is also known as filter-based-forwarding. 370 4.2. Network Address Translation (NAT) 372 IP fragmentation causes problems for Network Address Translation 373 (NAT) devices. When a NAT device detects a new, outbound flow, it 374 maps that flow's source port and IP address to another source port 375 and IP address. Having created that mapping, the NAT device 376 translates: 378 o The Source IP Address and Source Port on each outbound packet. 380 o The Destination IP Address and Destination Port on each inbound 381 packet. 383 A+P [RFC6346] and Carrier Grade NAT (CGN) [RFC6888] are two common 384 NAT strategies. In both approaches the NAT device must virtually 385 reassemble fragmented packets in order to translate and forward each 386 fragment. (See NOTE 1.) 388 Virtual reassembly in the network is problematic, because it is 389 computationally expensive and because it is prone to attacks 390 (Section 4.6). 392 NOTE 1: Virtual reassembly is a procedure in which a device 393 reassembles a packet, forwards its fragments, and discards the 394 reassembled copy. In A+P and CGN, virtual reassembly is required in 395 order to correctly translate fragment addresses. 397 4.3. Stateless Firewalls 399 IP fragmentation causes problems for stateless firewalls whose rules 400 include TCP and UDP ports. Because port information is not available 401 in the trailing fragments the firewall is limited to the following 402 options: 404 o Accept all trailing fragments, possibly admitting certain classes 405 of attack. 407 o Block all trailing fragments, possibly blocking legitimate 408 traffic. 410 Neither option is attractive. 412 4.4. Equal Cost Multipath, Link Aggregate Groups and Stateless Load- 413 Balancers 415 IP fragmentation causes problems for Equal Cost Multipath (ECMP), 416 Link Aggregate Groups (LAG) and other stateless load-balancing 417 technologies. In order to assign a packet or packet fragment to a 418 link, an intermediate node executes a hash (i.e., load-balancing) 419 algorithm. The following paragraphs describe a commonly deployed 420 hash algorithm. 422 If the packet or packet fragment contains a transport-layer header, 423 the algorithm accepts the following 5-tuple as input: 425 o IP Source Address. 427 o IP Destination Address. 429 o IPv4 Protocol or IPv6 Next Header. 431 o transport-layer source port. 433 o transport-layer destination port. 435 If the packet or packet fragment does not contain a transport-layer 436 header, the algorithm accepts only the following 3-tuple as input: 438 o IP Source Address. 440 o IP Destination Address. 442 o IPv4 Protocol or IPv6 Next Header. 444 Therefore, non-fragmented packets belonging to a flow can be assigned 445 to one link while fragmented packets belonging to the same flow can 446 be divided between that link and another. This can cause suboptimal 447 load-balancing. 449 [RFC6438] offers a partial solution to this problem for IPv6 devices 450 only. According to [RFC6438]: 452 "At intermediate routers that perform load distribution, the hash 453 algorithm used to determine the outgoing component-link in an ECMP 454 and/or LAG toward the next hop MUST minimally include the 3-tuple 455 {dest addr, source addr, flow label} and MAY also include the 456 remaining components of the 5-tuple." 458 If the algorithm includes only the 3-tuple {dest addr, source addr, 459 flow label}, it will assign all fragments belonging to a packet to 460 the same link. (See [RFC6437] and [RFC7098]). 462 In order to avoid the problem described above, implementations SHOULD 463 implement the recommendations provided in Section 7.4 of this 464 document. 466 4.5. IPv4 Reassembly Errors at High Data Rates 468 IPv4 fragmentation is not sufficiently robust for use under some 469 conditions in today's Internet. At high data rates, the 16-bit IP 470 identification field is not large enough to prevent frequent 471 incorrectly assembled IP fragments, and the TCP and UDP checksums are 472 insufficient to prevent the resulting corrupted datagrams from being 473 delivered to higher protocol layers. [RFC4963] describes some easily 474 reproduced experiments demonstrating the problem, and discusses some 475 of the operational implications of these observations. 477 These reassembly issues are not easily reproducible in IPv6 because 478 the IPv6 identification field is 32 bits long. 480 4.6. Security Vulnerabilities 482 Security researchers have documented several attacks that exploit IP 483 fragmentation. The following are examples: 485 o Overlapping fragment attacks [RFC1858][RFC3128][RFC5722] 487 o Resource exhaustion attacks (such as the Rose Attack) 489 o Attacks based on predictable fragment identification values 490 [RFC7739] 492 o Evasion of Network Intrusion Detection Systems (NIDS) [Ptacek1998] 494 In the overlapping fragment attack, an attacker constructs a series 495 of packet fragments. The first fragment contains an IP header, a 496 transport-layer header, and some transport-layer payload. This 497 fragment complies with local security policy and is allowed to pass 498 through a stateless firewall. A second fragment, having a non-zero 499 offset, overlaps with the first fragment. The second fragment also 500 passes through the stateless firewall. When the packet is 501 reassembled, the transport layer header from the first fragment is 502 overwritten by data from the second fragment. The reassembled packet 503 does not comply with local security policy. Had it traversed the 504 firewall in one piece, the firewall would have rejected it. 506 A stateless firewall cannot protect against the overlapping fragment 507 attack. However, destination nodes can protect against the 508 overlapping fragment attack by implementing the procedures described 509 in RFC 1858, RFC 3128 and RFC 8200. These reassembly procedures 510 detect the overlap and discard the packet. 512 The fragment reassembly algorithm is a stateful procedure in an 513 otherwise stateless protocol. Therefore, it can be exploited by 514 resource exhaustion attacks. An attacker can construct a series of 515 fragmented packets, with one fragment missing from each packet so 516 that the reassembly is impossible. Thus, this attack causes resource 517 exhaustion on the destination node, possibly denying reassembly 518 services to other flows. This type of attack can be mitigated by 519 flushing fragment reassembly buffers when necessary, at the expense 520 of possibly dropping legitimate fragments. 522 Each IP fragment contains an "Identification" field that destination 523 nodes use to reassemble fragmented packets. Many implementations set 524 the Identification field to a predictable value, thus making it easy 525 for an attacker to forge malicious IP fragments that would cause the 526 reassembly procedure for legitimate packets to fail. 528 NIDS aims at identifying malicious activity by analyzing network 529 traffic. Ambiguity in the possible result of the fragment reassembly 530 process may allow an attacker to evade these systems. Many of these 531 systems try to mitigate some of these evasion techniques (e.g. By 532 computing all possible outcomes of the fragment reassembly process, 533 at the expense of increased processing requirements). 535 4.7. PMTU Blackholing Due to ICMP Loss 537 As mentioned in Section 2.3, upper-layer protocols can be configured 538 to rely on PMTUD. Because PMTUD relies upon the network to deliver 539 ICMP PTB messages, those protocols also rely on the networks to 540 deliver ICMP PTB messages. 542 According to [RFC4890], ICMP PTB messages must not be filtered. 543 However, ICMP PTB delivery is not reliable. It is subject to both 544 transient and persistent loss. 546 Transient loss of ICMP PTB messages can cause transient PMTU black 547 holes. When the conditions contributing to transient loss abate, the 548 network regains its ability to deliver ICMP PTB messages and 549 connectivity between the source and destination nodes is restored. 550 Section 4.7.1 of this document describes conditions that lead to 551 transient loss of ICMP PTB messages. 553 Persistent loss of ICMP PTB messages can cause persistent black 554 holes. Section 4.7.2 and Section 4.7.3 of this document describe 555 conditions that lead to persistent loss of ICMP PTB messages. 557 The problem described in this section is specific to PMTUD. It does 558 not occur when the upper-layer protocol obtains its PMTU estimate 559 from PLPMTUD or from any other source. 561 4.7.1. Transient Loss 563 The following factors can contribute to transient loss of ICMP PTB 564 messages: 566 o Network congestion. 568 o Packet corruption. 570 o Transient routing loops. 572 o ICMP rate limiting. 574 The effect of rate limiting may be severe, as RFC 4443 recommends 575 strict rate limiting of IPv6 traffic. 577 4.7.2. Incorrect Implementation of Security Policy 579 Incorrect implementation of security policy can cause persistent loss 580 of ICMP PTB messages. 582 Assume that a Customer Premise Equipment (CPE) router implements the 583 following zone-based security policy: 585 o Allow any traffic to flow from the inside zone to the outside 586 zone. 588 o Do not allow any traffic to flow from the outside zone to the 589 inside zone unless it is part of an existing flow (i.e., it was 590 elicited by an outbound packet). 592 When a correct implementation of the above-mentioned security policy 593 receives an ICMP PTB message, it examines the ICMP PTB payload in 594 order to determine whether the original packet (i.e., the packet that 595 elicited the ICMP PTB message) belonged to an existing flow. If the 596 original packet belonged to an existing flow, the implementation 597 allows the ICMP PTB to flow from the outside zone to the inside zone. 598 If not, the implementation discards the ICMP PTB message. 600 When a incorrect implementation of the above-mentioned security 601 policy receives an ICMP PTB message, it discards the packet because 602 its source address is not associated with an existing flow. 604 The security policy described above is implemented incorrectly on 605 many consumer CPE routers. 607 4.7.3. Persistent Loss Caused By Anycast 609 Anycast can cause persistent loss of ICMP PTB messages. Consider the 610 example below: 612 A DNS client sends a request to an anycast address. The network 613 routes that DNS request to the nearest instance of that anycast 614 address (i.e., a DNS Server). The DNS server generates a response 615 and sends it back to the DNS client. While the response does not 616 exceed the DNS server's PMTU estimate, it does exceed the actual 617 PMTU. 619 A downstream router drops the packet and sends an ICMP PTB message 620 the packet's source (i.e., the anycast address). The network routes 621 the ICMP PTB message to the anycast instance closest to the 622 downstream router. That anycast instance may not be the DNS server 623 that originated the DNS response. It may be another DNS server with 624 the same anycast address. The DNS server that originated the 625 response may never receive the ICMP PTB message and may never update 626 its PMTU estimate. 628 4.7.4. Persistent Loss Caused By Unidirectional Routing 630 Unidirectional routing can cause persistent loss of ICMP PTB 631 messages. Consider the example below: 633 A source node sends a packet to a destination node. All intermediate 634 nodes maintain a route to the destination node, but do not maintain a 635 route to the source node. In this case, when an intermediate node 636 encounters an MTU issue, it cannot send an ICMP PTB message to the 637 source node. 639 4.8. Blackholing Due To Filtering or Loss 641 In RFC 7872, researchers sampled Internet paths to determine whether 642 they would convey packets that contain IPv6 extension headers. 643 Sampled paths terminated at popular Internet sites (e.g., popular 644 web, mail and DNS servers). 646 The study revealed that at least 28% of the sampled paths did not 647 convey packets containing the IPv6 Fragment extension header. In 648 most cases, fragments were dropped in the destination autonomous 649 system. In other cases, the fragments were dropped in transit 650 autonomous systems. 652 Another recent study [Huston] confirmed this finding. It reported 653 that 37% of sampled endpoints used IPv6-capable DNS resolvers that 654 were incapable of receiving a fragmented IPv6 response. 656 It is difficult to determine why network operators drop fragments. 657 Possible causes follow: 659 o Hardware inability to process fragmented packets. 661 o Failure to change vendor defaults. 663 o Unintentional misconfiguration. 665 o Intentional configuration (e.g., network operators consciously 666 chooses to drop IPv6 fragments in order to address the issues 667 raised in Section 4.1 through Section 4.7, above.) 669 5. Alternatives to IP Fragmentation 671 5.1. Transport Layer Solutions 673 The Transport Control Protocol (TCP) [RFC0793]) can be operated in a 674 mode that does not require IP fragmentation. 676 Applications submit a stream of data to TCP. TCP divides that stream 677 of data into segments, with no segment exceeding the TCP Maximum 678 Segment Size (MSS). Each segment is encapsulated in a TCP header and 679 submitted to the underlying IP module. The underlying IP module 680 prepends an IP header and forwards the resulting packet. 682 If the TCP MSS is sufficiently small, the underlying IP module never 683 produces a packet whose length is greater than the actual PMTU. 684 Therefore, IP fragmentation is not required. 686 TCP offers the following mechanisms for MSS management: 688 o Manual configuration 690 o PMTUD 692 o PLPMTUD 694 Manual configuration is always applicable. If the MSS is configured 695 to a sufficiently low value, the IP layer will never produce a packet 696 whose length is greater than the protocol minimum link MTU. However, 697 manual configuration prevents TCP from taking advantage of larger 698 link MTU's. 700 Upper-layer protocols can implement PMTUD in order to discover and 701 take advantage of larger path MTUs. However, as mentioned in 702 Section 2.1, PMTUD relies upon the network to deliver ICMP PTB 703 messages. Therefore, PMTUD is applicable only in environments where 704 the risk of ICMP PTB loss is acceptable. 706 By contrast, PLPMTUD does not rely upon the network's ability to 707 deliver ICMP PTB messages. It utilises probe messages sent as TCP 708 segments to determine if the probed PMTU can be successfully used 709 across the network path. In PLPMTUD, probing is separated from 710 congestion control, so that loss of a TCP probe segment does not 711 cause a reduction of the congestion control window. [RFC4821] 712 defines PLPMTUD procedures for TCP. 714 While TCP will never cause the underlying IP module to emit a packet 715 that is larger than the PMTU estimate, it can cause the underlying IP 716 module to emit a packet that is larger than the actual PMTU. If this 717 occurs, the packet is dropped, the PMTU estimate is updated, the 718 segment is divided into smaller segments and each smaller segment is 719 submitted to the underlying IP module. 721 The Datagram Congestion Control Protocol (DCCP) [RFC4340]. the Stream 722 Control Protocol (SCP) [RFC4960], and the Stream Control Transport 723 Protocol (SCTP) [RFC4960] also can be operated in a mode that does 724 not require IP fragmentation. They both accept data from an 725 application and divide that data into segments, with no segment 726 exceeding a maximum size. Both DCCP and SCP offer manual 727 configuration, PMTUD and PLPMTUD as mechanisms for managing that 728 maximum size. [I-D.ietf-tsvwg-datagram-plpmtud] proposes PLPMTUD 729 procedures for DCCP and SCP. 731 Currently, User Data Protocol (UDP) [RFC0768] lacks a fragmentation 732 mechanism of its own and relies on IP fragmentation. However, 733 [I-D.ietf-tsvwg-udp-options] proposes a fragmentation mechanism for 734 UDP. 736 5.2. Application Layer Solutions 738 [RFC8085] recognizes that IP fragmentation reduces the reliability of 739 Internet communication. It also recognizes that UDP lacks a 740 fragmentation mechanism of its own and relies on IP fragmentation. 741 Therefore, [RFC8085] offers the following advice regarding 742 applications the run over the UDP. 744 "An application SHOULD NOT send UDP datagrams that result in IP 745 packets that exceed the Maximum Transmission Unit (MTU) along the 746 path to the destination. Consequently, an application SHOULD either 747 use the path MTU information provided by the IP layer or implement 748 Path MTU Discovery (PMTUD) itself to determine whether the path to a 749 destination will support its desired message size without 750 fragmentation." 752 RFC 8085 continues: 754 "Applications that do not follow the recommendation to do PMTU/ 755 PLPMTUD discovery SHOULD still avoid sending UDP datagrams that would 756 result in IP packets that exceed the path MTU. Because the actual 757 path MTU is unknown, such applications SHOULD fall back to sending 758 messages that are shorter than the default effective MTU for sending 759 (EMTU_S in [RFC1122]). For IPv4, EMTU_S is the smaller of 576 bytes 760 and the first-hop MTU. For IPv6, EMTU_S is 1280 bytes. The 761 effective PMTU for a directly connected destination (with no routers 762 on the path) is the configured interface MTU, which could be less 763 than the maximum link payload size. Transmission of minimum-sized 764 UDP datagrams is inefficient over paths that support a larger PMTU, 765 which is a second reason to implement PMTU discovery." 767 RFC 8085 assumes that for IPv4, an EMTU_S of 576 is sufficiently 768 small, even though the IPv4 minimum link MTU is 68 bytes. 770 This advice applies equally to application that run directly over IP. 772 6. Applications That Rely on IPv6 Fragmentation 774 The following applications rely on IPv6 fragmentation: 776 o DNS [RFC1035] 778 o OSPFv3 [RFC2328][RFC5340] 780 o Packet-in-packet encapsulations 782 Each of these applications relies on IPv6 fragmentation to a varying 783 degree. In some cases, that reliance is essential, and cannot be 784 broken without fundamentally changing the protocol. In other cases, 785 that reliance is incidental, and most implementations already take 786 appropriate steps to avoid fragmentation. 788 This list is not comprehensive, and other protocols that rely on IP 789 fragmentation may exist. They are not specifically considered in the 790 context of this document. 792 6.1. Domain Name Service (DNS) 794 DNS relies on UDP for efficiency, and the consequence is the use of 795 IP fragmentation for large responses, as permitted by the DNS EDNS(0) 796 options in the query. It is possible to mitigate the issue of 797 fragmentation-based packet loss by having queries use smaller EDNS(0) 798 UDP buffer sizes, or by having the DNS server limit the size of its 799 UDP responses to some self-imposed maximum packet size that may be 800 less than the preferred EDNS(0) UDP Buffer Size. In both cases, 801 large responses are truncated in the DNS, signalling to the client to 802 re-query using TCP to obtain the complete response. However, the 803 operational issue of the partial level of support for DNS over TCP, 804 particularly in the case where IPv6 transport is being used, becomes 805 a limiting factor of the efficacy of this approach [Damas]. 807 Larger DNS responses can normally be avoided by aggressively pruning 808 the Additional section of DNS responses. One scenario where such 809 pruning is ineffective is in the use of DNSSEC, where large key sizes 810 act to increase the response size to certain DNS queries. There is 811 no effective response to this situation within the DNS other than 812 using smaller cryptographic keys and adoption of DNSSEC 813 administrative practices that attempt to keep DNS response as short 814 as possible. 816 6.2. Open Shortest Path First (OSPF) 818 OSPF implementations can emit messages large enough to cause 819 fragmentation. However, in order to optimize performance, most OSPF 820 implementations restrict their maximum message size to a value that 821 will not cause fragmentation. 823 6.3. Packet-in-Packet Encapsulations 825 In this document, packet-in-packet encapsulations include IP-in-IP 826 [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP 827 [RFC8086] and Generic Packet Tunneling in IPv6 [RFC2473]. [RFC4459] 828 describes fragmentation issues associated with all of the above- 829 mentioned encapsulations. 831 The fragmentation strategy described for GRE in [RFC7588] has been 832 deployed for all of the above-mentioned encapsulations. This 833 strategy does not rely on IP fragmentation except in one corner case. 834 (see Section 3.3.2.2 of RFC 7588 and Section 7.1 of RFC 2473). 835 Section 3.3 of [RFC7676] further describes this corner case. 837 See [I-D.ietf-intarea-tunnels] for further discussion. 839 6.4. UDP Applications Enhancing Performance 841 Some UDP applications rely on IP fragmentation to achieve acceptable 842 levels of performance. These applications use UDP datagram sizes 843 that are larger than the path MTU so that more data can be conveyed 844 between the application and the kernel in a single system call. 846 For example, the Licklider Transmission Protocol (LTP) [RFC5326] 847 which is in current use on the International Space Station (ISS) uses 848 UDP datagram sizes larger than the path MTU to achieve acceptable 849 levels of performance even though this invokes IP fragmentation. 851 7. Recommendations 853 7.1. For Application and Protocol Developers 855 Developers SHOULD NOT develop new protocols or applications that rely 856 on IP fragmentation. When a new protocol or application is deployed 857 in an environment that does not fully support IP fragmentation, it 858 SHOULD operate correctly, either in its default configuration or in a 859 specified alternative configuration. 861 Developers MAY develop new protocols or applications that rely on IP 862 fragmentation if the protocol or application is to be run only in 863 environments where IP fragmentation is known to be supported. 865 Legacy protocols that depend upon IP fragmentation SHOULD be updated 866 to break that dependency. However, in some cases, there may be no 867 viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP- 868 in-IP encapsulation). In these cases, the protocol will continue to 869 rely on IP fragmentation but should only be used in environments 870 where IP fragmentation is known to be supported. 872 Protocols may be able to avoid IP fragmentation by using a 873 sufficiently small MTU (e.g. The protocol minimum link MTU), 874 disabling IP fragmentation, and ensuring that the transport protocol 875 in use adapts its segment size to the MTU. Other protocols may 876 deploy a sufficiently reliable PMTU discovery mechanism 877 (e.g.,PLMPTUD). 879 UDP applications SHOULD abide by the recommendations state in 880 Section 3.2 of [RFC8085]. 882 7.2. For System Developers 884 Software libraries SHOULD include provision for PLPMTUD for each 885 supported transport protocol. 887 7.3. For Middle Box Developers 889 Middle boxes should process IP fragments in a manner that is 890 consistent with [RFC0791] and [RFC8200]. In many cases, middle boxes 891 must maintain state in order to achieve this goal. 893 Price and performance considerations frequently motivate network 894 operators to deploy stateless middle boxes. These stateless middle 895 boxes may perform sub-optimally, process IP fragments in a manner 896 that is not compliant with RFC 791 or RFC 8200, or even discard IP 897 fragments completely. Such behaviors are NOT RECOMMENDED. If a 898 middleboxes implements non-standard behavior with respect to IP 899 fragmentation, then that behavior MUST be clearly documented. 901 7.4. For ECMP, LAG and Load-Balancer Developers And Operators 903 In their default configuration, when the IPv6 Flow Label is not equal 904 to zero, IPv6 devices that implement ECMP, LAG or other load- 905 balancing technologies SHOULD accept only the following fields as 906 input to their hash algorithm: 908 o IP Source Address. 910 o IP Destination Address. 912 o Flow Label. 914 Operators SHOULD deploy these devices in their default configuration. 916 These recommendations are similar to those presented in [RFC6438] and 917 [RFC7098]. They differ in that they specify a default configuration. 919 7.5. For Network Operators 921 Operators MUST ensure proper PMTUD operation in their network, 922 including making sure the network generates PTB packets when dropping 923 packets too large compared to outgoing interface MTU. However, 924 implementations MAY rate limit ICMP messages as per [RFC1812] and 925 [RFC4443]. 927 As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB 928 messages unless they are known to be forged or otherwise 929 illegitimate. As stated in Section 4.7, filtering ICMPv6 PTB packets 930 causes PMTUD to fail. Many upper-layer protocols rely on PMTUD. 932 As per RFC 8200, network operators MUST NOT deploy IPv6 links whose 933 MTU is less than 1280 bytes. 935 Network operators SHOULD NOT filter IP fragments if they originated 936 at a domain name server or are destined for a domain name server. 937 This is because domain name services are critical to operation of the 938 Internet. 940 8. IANA Considerations 942 This document makes no request of IANA. 944 9. Security Considerations 946 This document mitigates some of the security considerations 947 associated with IP fragmentation by discouraging its use. It does 948 not introduce any new security vulnerabilities, because it does not 949 introduce any new alternatives to IP fragmentation. Instead, it 950 recommends well-understood alternatives. 952 10. Acknowledgements 954 Thanks to Mikael Abrahamsson, Brian Carpenter, Silambu Chelvan, 955 Lorenzo Colitti, Gorry Fairhurst, Mike Heard, Tom Herbert, Tatuya 956 Jinmei, Jen Linkova, Paolo Lucente, Manoj Nayak, Eric Nygren, Fred 957 Templin and Joe Touch for their comments. 959 11. References 961 11.1. Normative References 963 [I-D.ietf-tsvwg-datagram-plpmtud] 964 Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 965 T. Voelker, "Packetization Layer Path MTU Discovery for 966 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-07 967 (work in progress), February 2019. 969 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 970 DOI 10.17487/RFC0768, August 1980, 971 . 973 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 974 DOI 10.17487/RFC0791, September 1981, 975 . 977 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 978 RFC 792, DOI 10.17487/RFC0792, September 1981, 979 . 981 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 982 RFC 793, DOI 10.17487/RFC0793, September 1981, 983 . 985 [RFC1035] Mockapetris, P., "Domain names - implementation and 986 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 987 November 1987, . 989 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 990 DOI 10.17487/RFC1191, November 1990, 991 . 993 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 994 Requirement Levels", BCP 14, RFC 2119, 995 DOI 10.17487/RFC2119, March 1997, 996 . 998 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 999 Control Message Protocol (ICMPv6) for the Internet 1000 Protocol Version 6 (IPv6) Specification", STD 89, 1001 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1002 . 1004 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1005 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1006 . 1008 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1009 "IPv6 Flow Label Specification", RFC 6437, 1010 DOI 10.17487/RFC6437, November 2011, 1011 . 1013 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1014 for Equal Cost Multipath Routing and Link Aggregation in 1015 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1016 . 1018 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1019 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1020 March 2017, . 1022 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1023 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1024 May 2017, . 1026 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1027 (IPv6) Specification", STD 86, RFC 8200, 1028 DOI 10.17487/RFC8200, July 2017, 1029 . 1031 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 1032 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 1033 DOI 10.17487/RFC8201, July 2017, 1034 . 1036 11.2. Informative References 1038 [Damas] Damas, J. and G. Huston, "Measuring ATR", April 2018, 1039 . 1041 [Huston] Huston, G., "IPv6, Large UDP Packets and the DNS 1042 (http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html)", 1043 August 2017. 1045 [I-D.ietf-intarea-tunnels] 1046 Touch, J. and M. Townsley, "IP Tunnels in the Internet 1047 Architecture", draft-ietf-intarea-tunnels-09 (work in 1048 progress), July 2018. 1050 [I-D.ietf-tsvwg-udp-options] 1051 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 1052 udp-options-07 (work in progress), March 2019. 1054 [Kent] Kent, C. and J. Mogul, ""Fragmentation Considered 1055 Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in 1056 Computer Communications Technology, DOI 1057 10.1145/55483.55524", August 1987, 1058 . 1061 [Ptacek1998] 1062 Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial 1063 of Service: Eluding Network Intrusion Detection", 1998, 1064 . 1066 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1067 Communication Layers", STD 3, RFC 1122, 1068 DOI 10.17487/RFC1122, October 1989, 1069 . 1071 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 1072 RFC 1812, DOI 10.17487/RFC1812, June 1995, 1073 . 1075 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1076 Considerations for IP Fragment Filtering", RFC 1858, 1077 DOI 10.17487/RFC1858, October 1995, 1078 . 1080 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1081 DOI 10.17487/RFC2003, October 1996, 1082 . 1084 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1085 DOI 10.17487/RFC2328, April 1998, 1086 . 1088 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1089 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1090 December 1998, . 1092 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1093 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1094 DOI 10.17487/RFC2784, March 2000, 1095 . 1097 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1098 Fragment Attack (RFC 1858)", RFC 3128, 1099 DOI 10.17487/RFC3128, June 2001, 1100 . 1102 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1103 Congestion Control Protocol (DCCP)", RFC 4340, 1104 DOI 10.17487/RFC4340, March 2006, 1105 . 1107 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1108 Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 1109 2006, . 1111 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1112 ICMPv6 Messages in Firewalls", RFC 4890, 1113 DOI 10.17487/RFC4890, May 2007, 1114 . 1116 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1117 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1118 . 1120 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1121 Errors at High Data Rates", RFC 4963, 1122 DOI 10.17487/RFC4963, July 2007, 1123 . 1125 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 1126 Transmission Protocol - Specification", RFC 5326, 1127 DOI 10.17487/RFC5326, September 2008, 1128 . 1130 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1131 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1132 . 1134 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 1135 RFC 5722, DOI 10.17487/RFC5722, December 2009, 1136 . 1138 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 1139 DOI 10.17487/RFC5927, July 2010, 1140 . 1142 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 1143 the IPv4 Address Shortage", RFC 6346, 1144 DOI 10.17487/RFC6346, August 2011, 1145 . 1147 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 1148 RFC 6864, DOI 10.17487/RFC6864, February 2013, 1149 . 1151 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 1152 A., and H. Ashida, "Common Requirements for Carrier-Grade 1153 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 1154 April 2013, . 1156 [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 1157 Flow Label for Load Balancing in Server Farms", RFC 7098, 1158 DOI 10.17487/RFC7098, January 2014, 1159 . 1161 [RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely 1162 Deployed Solution to the Generic Routing Encapsulation 1163 (GRE) Fragmentation Problem", RFC 7588, 1164 DOI 10.17487/RFC7588, July 2015, 1165 . 1167 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 1168 for Generic Routing Encapsulation (GRE)", RFC 7676, 1169 DOI 10.17487/RFC7676, October 2015, 1170 . 1172 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1173 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1174 February 2016, . 1176 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1177 "Observations on the Dropping of Packets with IPv6 1178 Extension Headers in the Real World", RFC 7872, 1179 DOI 10.17487/RFC7872, June 2016, 1180 . 1182 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 1183 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 1184 March 2017, . 1186 Appendix A. Contributors' Address 1188 Authors' Addresses 1190 Ron Bonica 1191 Juniper Networks 1192 2251 Corporate Park Drive 1193 Herndon, Virginia 20171 1194 USA 1196 Email: rbonica@juniper.net 1197 Fred Baker 1198 Unaffiliated 1199 Santa Barbara, California 93117 1200 USA 1202 Email: FredBaker.IETF@gmail.com 1204 Geoff Huston 1205 APNIC 1206 6 Cordelia St 1207 Brisbane, 4101 QLD 1208 Australia 1210 Email: gih@apnic.net 1212 Robert M. Hinden 1213 Check Point Software 1214 959 Skyway Road 1215 San Carlos, California 94070 1216 USA 1218 Email: bob.hinden@gmail.com 1220 Ole Troan 1221 Cisco 1222 Philip Pedersens vei 1 1223 N-1366 Lysaker 1224 Norway 1226 Email: ot@cisco.com 1228 Fernando Gont 1229 SI6 Networks 1230 Evaristo Carriego 2644 1231 Haedo, Provincia de Buenos Aires 1232 Argentina 1234 Email: fgont@si6networks.com