idnits 2.17.1 draft-ietf-intarea-frag-fragile-15.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 (July 6, 2019) is 1746 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: 'RFC5326' is defined on line 1158, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-datagram-plpmtud-08 ** 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: January 7, 2020 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 July 6, 2019 16 IP Fragmentation Considered Fragile 17 draft-ietf-intarea-frag-fragile-15 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 January 7, 2020. 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 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. IP Fragmentation . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Links, Paths, MTU and PMTU . . . . . . . . . . . . . . . 4 66 2.2. Fragmentation Procedures . . . . . . . . . . . . . . . . 6 67 2.3. Upper-Layer Reliance on IP Fragmentation . . . . . . . . 7 68 3. Increased Fragility . . . . . . . . . . . . . . . . . . . . . 7 69 3.1. Virtual Reassembly . . . . . . . . . . . . . . . . . . . 7 70 3.2. Policy-Based Routing . . . . . . . . . . . . . . . . . . 8 71 3.3. Network Address Translation (NAT) . . . . . . . . . . . . 9 72 3.4. Stateless Firewalls . . . . . . . . . . . . . . . . . . . 9 73 3.5. Equal Cost Multipath, Link Aggregate Groups and Stateless 74 Load-Balancers . . . . . . . . . . . . . . . . . . . . . 10 75 3.6. IPv4 Reassembly Errors at High Data Rates . . . . . . . . 11 76 3.7. Security Vulnerabilities . . . . . . . . . . . . . . . . 11 77 3.8. PMTU Blackholing Due to ICMP Loss . . . . . . . . . . . . 12 78 3.8.1. Transient Loss . . . . . . . . . . . . . . . . . . . 13 79 3.8.2. Incorrect Implementation of Security Policy . . . . . 13 80 3.8.3. Persistent Loss Caused By Anycast . . . . . . . . . . 14 81 3.8.4. Persistent Loss Caused By Unidirectional Routing . . 14 82 3.9. Blackholing Due To Filtering or Loss . . . . . . . . . . 14 83 4. Alternatives to IP Fragmentation . . . . . . . . . . . . . . 15 84 4.1. Transport Layer Solutions . . . . . . . . . . . . . . . . 15 85 4.2. Application Layer Solutions . . . . . . . . . . . . . . . 17 86 5. Applications That Rely on IPv6 Fragmentation . . . . . . . . 17 87 5.1. Domain Name Service (DNS) . . . . . . . . . . . . . . . . 18 88 5.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . 18 89 5.3. Packet-in-Packet Encapsulations . . . . . . . . . . . . . 18 90 5.4. UDP Applications Enhancing Performance . . . . . . . . . 19 91 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19 92 6.1. For Application and Protocol Developers . . . . . . . . . 19 93 6.2. For System Developers . . . . . . . . . . . . . . . . . . 20 94 6.3. For Middle Box Developers . . . . . . . . . . . . . . . . 20 95 6.4. For ECMP, LAG and Load-Balancer Developers And Operators 20 96 6.5. For Network Operators . . . . . . . . . . . . . . . . . . 21 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 102 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 103 10.2. Informative References . . . . . . . . . . . . . . . . . 23 104 Appendix A. Contributors' Address . . . . . . . . . . . . . . . 26 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 107 1. Introduction 109 Operational experience [Kent] [Huston] [RFC7872] reveals that IP 110 fragmentation introduces fragility to Internet communication. This 111 document describes IP fragmentation and explains the fragility it 112 introduces. It also proposes alternatives to IP fragmentation and 113 provides recommendations for developers and network operators. 115 While this document identifies issues associated with IP 116 fragmentation, it does not recommend deprecation. Legacy protocols 117 that depend upon IP fragmentation SHOULD be updated to remove that 118 dependency. However, some applications and environments (see 119 Section 5) require IP fragmentation. In these cases, the protocol 120 will continue to rely on IP fragmentation, but the designer should to 121 be aware that fragmented packets may result in blackholes; a design 122 should include appropriate safeguards. 124 Rather than deprecating IP Fragmentation, this document recommends 125 that upper-layer protocols address the problem of fragmentation at 126 their layer, reducing their reliance on IP fragmentation to the 127 greatest degree possible. 129 1.1. IP-in-IP Tunnels 131 This document acknowledges that in some cases, packets must be 132 fragmented within IP-in-IP tunnels [I-D.ietf-intarea-tunnels]. 133 Therefore, this document makes no additional recommendations 134 regarding IP-in-IP tunnels. 136 1.2. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 2. IP Fragmentation 146 2.1. Links, Paths, MTU and PMTU 148 An Internet path connects a source node to a destination node. A 149 path may contain links and routers. If a path contains more than one 150 link, the links are connected in series and a router connects each 151 link to the next. 153 Internet paths are dynamic. Assume that the path from one node to 154 another contains a set of links and routers. If a link fails, the 155 path can also change so that it includes a different set of links and 156 routers. 158 Each link is constrained by the number of bytes that it can convey in 159 a single IP packet. This constraint is called the link Maximum 160 Transmission Unit (MTU). Whlie the end-to-end Path MTU is the size 161 of a single IPv4 header, IPv4 [RFC0791] requires every link to 162 support at least a specified MTU (see NOTE 1). IPv6 [RFC8200] 163 similarly requires every link to support an MTU of 1280 bytes or 164 greater. These are called the IPv4 and IPv6 minimum link MTU's. 166 Likewise, each Internet path is constrained by the number of bytes 167 that it can convey in a single IP packet. This constraint is called 168 the Path MTU (PMTU). For any given path, the PMTU is equal to the 169 smallest of its link MTU's. Because Internet paths are dynamic, PMTU 170 is also dynamic. 172 For reasons described below, source nodes estimate the PMTU between 173 themselves and destination nodes. A source node can produce 174 extremely conservative PMTU estimates in which: 176 o The estimate for each IPv4 path is equal to the IPv4 minimum link 177 MTU. 179 o The estimate for each IPv6 path is equal to the IPv6 minimum link 180 MTU. 182 While these conservative estimates are guaranteed to be less than or 183 equal to the actual PMTU, they are likely to be much less than the 184 actual PMTU. This may adversely affect upper-layer protocol 185 performance. 187 By executing Path MTU Discovery (PMTUD) [RFC1191] [RFC8201] 188 procedures, a source node can maintain a less conservative estimate 189 of the PMTU between itself and a destination node. In PMTUD, the 190 source node produces an initial PMTU estimate. This initial estimate 191 is equal to the MTU of the first link along the path to the 192 destination node. It can be greater than the actual PMTU. 194 Having produced an initial PMTU estimate, the source node sends non- 195 fragmentable IP packets to the destination node (see NOTE 2). If one 196 of these packets is larger than the actual PMTU, a downstream router 197 will not be able to forward the packet through the next link along 198 the path. Therefore, the downstream router drops the packet and 199 sends an Internet Control Message Protocol (ICMP) [RFC0792] [RFC4443] 200 Packet Too Big (PTB) message to the source node (see NOTE 3). The 201 ICMP PTB message indicates the MTU of the link through which the 202 packet could not be forwarded. The source node uses this information 203 to refine its PMTU estimate. 205 PMTUD produces a running estimate of the PMTU between a source node 206 and a destination node. Because PMTU is dynamic, the PMTU estimate 207 can be larger than the actual PMTU. In order to detect PMTU 208 increases, PMTUD occasionally resets the PMTU estimate to its initial 209 value and repeats the procedure described above. 211 Ideally, PMTUD operates as described above. However, in some 212 scenarios, PMTUD fails. For example: 214 o PMTUD relies on the network's ability to deliver ICMP PTB messages 215 to the source node. If the network cannot deliver ICMP PTB 216 messages to the source node, PMTUD fails. 218 o PMTUD is susceptible to attack because ICMP messages are easily 219 forged [RFC5927] and not authenticated by the receiver. Such 220 attacks can cause PMTUD to produce unnecessarily conservative PMTU 221 estimates. 223 NOTE 1: In IPv4, every host must be capable of receiving a packet 224 whose length is equal to 576 bytes. However, the IPv4 minimum link 225 MTU is not 576. Section 3.2 of RFC 791 explicitly states that the 226 IPv4 minimum link MTU is 68 bytes. But for practical purposes, many 227 network operators consider the IPv4 minimum link MTU to be 576 bytes, 228 to minimize the requirement for fragmentation en route. So, for the 229 purposes of this document, we assume that the IPv4 minimum path MTU 230 is 576 bytes. 232 NOTE 2: A non-fragmentable packet can be fragmented at its source. 233 However, it cannot be fragmented by a downstream node. An IPv4 234 packet whose DF-bit is set to 0 is fragmentable. An IPv4 packet 235 whose DF-bit is set to 1 is non-fragmentable. All IPv6 packets are 236 also non-fragmentable. 238 NOTE 3: The ICMP PTB message has two instantiations. In ICMPv4 239 [RFC0792], the ICMP PTB message is a Destination Unreachable message 240 with Code equal to 4 fragmentation needed and DF set. This message 241 was augmented by [RFC1191] to indicate the MTU of the link through 242 which the packet could not be forwarded. In ICMPv6 [RFC4443], the 243 ICMP PTB message is a Packet Too Big Message with Code equal to 0. 244 This message also indicates the MTU of the link through which the 245 packet could not be forwarded. 247 2.2. Fragmentation Procedures 249 When an upper-layer protocol submits data to the underlying IP 250 module, and the resulting IP packet's length is greater than the 251 PMTU, the packet is divided into fragments. Each fragment includes 252 an IP header and a portion of the original packet. 254 [RFC0791] describes IPv4 fragmentation procedures. An IPv4 packet 255 whose DF-bit is set to 1 may be fragmented by the source node, but 256 may not be fragmented by a downstream router. An IPv4 packet whose 257 DF-bit is set to 0 may be fragmented by the source node or by a 258 downstream router. When an IPv4 packet is fragmented, all IP options 259 (which are within the IPv4 header) appear in the first fragment, but 260 only options whose "copy" bit is set to 1 appear in subsequent 261 fragments. 263 [RFC8200], notably in section 4.5, describes IPv6 fragmentation 264 procedures. An IPv6 packet may be fragmented only at the source 265 node. When an IPv6 packet is fragmented, all extension headers 266 appear in the first fragment, but only per-fragment headers appear in 267 subsequent fragments. Per-fragment headers include the following: 269 o The IPv6 header. 271 o The Hop-by-hop Options header (if present) 273 o The Destination Options header (if present and if it precedes a 274 Routing header) 276 o The Routing Header (if present) 278 o The Fragment Header 280 In IPv4, the upper-layer header usually appears in the first 281 fragment, due to the sizes of the headers involved; in IPv6, it is 282 required to. 284 2.3. Upper-Layer Reliance on IP Fragmentation 286 Upper-layer protocols can operate in the following modes: 288 o Do not rely on IP fragmentation. 290 o Rely on IP fragmentation by the source node only. 292 o Rely on IP fragmentation by any node. 294 Upper-layer protocols running over IPv4 can operate in all of the 295 above-mentioned modes. Upper-layer protocols running over IPv6 can 296 operate in the first and second modes only. 298 Upper-layer protocols that operate in the first two modes (above) 299 require access to the PMTU estimate. In order to fulfill this 300 requirement, they can: 302 o Estimate the PMTU to be equal to the IPv4 or IPv6 minimum link 303 MTU. 305 o Access the estimate that PMTUD produced. 307 o Execute PMTUD procedures themselves. 309 o Execute Packetization Layer PMTUD (PLPMTUD) [RFC4821] 310 [I-D.ietf-tsvwg-datagram-plpmtud] procedures. 312 According to PLPMTUD procedures, the upper-layer protocol maintains a 313 running PMTU estimate. It does so by sending probe packets of 314 various sizes to its upper-layer peer and receiving acknowledgements. 315 This strategy differs from PMTUD in that it relies on acknowledgement 316 of received messages, as opposed to ICMP PTB messages concerning 317 dropped messages. Therefore, PLPMTUD does not rely on the network's 318 ability to deliver ICMP PTB messages to the source. 320 3. Increased Fragility 322 This section explains how IP fragmentation introduces fragility to 323 Internet communication. 325 3.1. Virtual Reassembly 327 Virtual reassembly is a procedure in which a device conceptually 328 reassembles a packet, forwards its fragments, and discards the 329 reassembled copy. In A+P and CGN, virtual reassembly is required in 330 order to correctly translate fragment addresses. It could be useful 331 to address the problems in Section 3.2, Section 3.3, Section 3.4, and 332 Section 3.5. 334 Virtual reassembly in the network is problematic, however, because it 335 is computationally expensive and because it holds state for 336 indeterminate periods of time, is prone to errors and, is prone to 337 attacks (Section 3.7). 339 One of the benefits of fragmenting at the source, as IPv6 does, is 340 that there is no question of temporary state or involved processes as 341 required in virtual fragmentation. The sender has the entire 342 message, and is fragmenting it as needed - and can apply that 343 knowledge consistently across the fragments it produces. It is 344 better than virtual fragmentation in that sense. 346 3.2. Policy-Based Routing 348 IP Fragmentation causes problems for routers that implement policy- 349 based routing. 351 When a router receives a packet, it identifies the next-hop on route 352 to the packet's destination and forwards the packet to that next-hop. 353 In order to identify the next-hop, the router interrogates a local 354 data structure called the Forwarding Information Base (FIB). 356 Normally, the FIB contains destination-based entries that map a 357 destination prefix to a next-hop. Policy-based routing allows 358 destination-based and policy-based entries to coexist in the same 359 FIB. A policy-based FIB entry maps multiple fields, drawn from 360 either the IP or transport-layer header, to a next-hop. 362 +-------+--------------+-----------------+------------+-------------+ 363 | Entry | Type | Dest. Prefix | Next Hdr / | Next-Hop | 364 | | | | Dest. Port | | 365 +-------+--------------+-----------------+------------+-------------+ 366 | | | | | | 367 | 1 | Destination- | 2001:db8::1/128 | Any / Any | 2001:db8::2 | 368 | | based | | | | 369 | | | | | | 370 | 2 | Policy- | 2001:db8::1/128 | TCP / 80 | 2001:db8::3 | 371 | | based | | | | 372 +-------+--------------+-----------------+------------+-------------+ 374 Table 1: Policy-Based Routing FIB 376 Assume that a router maintains the FIB in Table 1. The first FIB 377 entry is destination-based. It maps a destination prefix 378 2001:db8::1/128 to a next-hop 2001:db8::2. The second FIB entry is 379 policy-based. It maps the same destination prefix 2001:db8::1/128 380 and a destination port ( TCP / 80 ) to a different next-hop 381 (2001:db8::3). The second entry is more specific than the first. 383 When the router receives the first fragment of a packet that is 384 destined for TCP port 80 on 2001:db8::1, it interrogates the FIB. 385 Both FIB entries satisfy the query. The router selects the second 386 FIB entry because it is more specific and forwards the packet to 387 2001:db8::3. 389 When the router receives the second fragment of the packet, it 390 interrogates the FIB again. This time, only the first FIB entry 391 satisfies the query, because the second fragment contains no 392 indication that the packet is destined for TCP port 80. Therefore, 393 the router selects the first FIB entry and forwards the packet to 394 2001:db8::2. 396 Policy-based routing is also known as filter-based-forwarding. 398 3.3. Network Address Translation (NAT) 400 IP fragmentation causes problems for Network Address Translation 401 (NAT) devices. When a NAT device detects a new, outbound flow, it 402 maps that flow's source port and IP address to another source port 403 and IP address. Having created that mapping, the NAT device 404 translates: 406 o The Source IP Address and Source Port on each outbound packet. 408 o The Destination IP Address and Destination Port on each inbound 409 packet. 411 A+P [RFC6346] and Carrier Grade NAT (CGN) [RFC6888] are two common 412 NAT strategies. In both approaches the NAT device must virtually 413 reassemble fragmented packets in order to translate and forward each 414 fragment. (See NOTE 1.) 416 3.4. Stateless Firewalls 418 As discussed in more detail in Section 3.7, IP fragmentation causes 419 problems for stateless firewalls whose rules include TCP and UDP 420 ports. Because port information is not available in the trailing 421 fragments the firewall is limited to the following options: 423 o Accept all trailing fragments, possibly admitting certain classes 424 of attack. 426 o Block all trailing fragments, possibly blocking legitimate 427 traffic. 429 Neither option is attractive. 431 3.5. Equal Cost Multipath, Link Aggregate Groups and Stateless Load- 432 Balancers 434 IP fragmentation causes problems for Equal Cost Multipath (ECMP), 435 Link Aggregate Groups (LAG) and other stateless load-distribution 436 technologies. In order to assign a packet or packet fragment to a 437 link, an intermediate node executes a hash (i.e., load-distributing) 438 algorithm. The following paragraphs describe a commonly deployed 439 hash algorithm. 441 If the packet or packet fragment contains a transport-layer header, 442 the algorithm accepts the following 5-tuple as input: 444 o IP Source Address. 446 o IP Destination Address. 448 o IPv4 Protocol or IPv6 Next Header. 450 o transport-layer source port. 452 o transport-layer destination port. 454 If the packet or packet fragment does not contain a transport-layer 455 header, the algorithm accepts only the following 3-tuple as input: 457 o IP Source Address. 459 o IP Destination Address. 461 o IPv4 Protocol or IPv6 Next Header. 463 Therefore, non-fragmented packets belonging to a flow can be assigned 464 to one link while fragmented packets belonging to the same flow can 465 be divided between that link and another. This can cause suboptimal 466 load-distribution. 468 [RFC6438] offers a partial solution to this problem for IPv6 devices 469 only. According to [RFC6438]: 471 "At intermediate routers that perform load balancing, the hash 472 algorithm used to determine the outgoing component-link in an ECMP 473 and/or LAG toward the next hop MUST minimally include the 3-tuple 474 {dest addr, source addr, flow label} and MAY also include the 475 remaining components of the 5-tuple." 477 If the algorithm includes only the 3-tuple {dest addr, source addr, 478 flow label}, it will assign all fragments belonging to a packet to 479 the same link. (See [RFC6437] and [RFC7098]). 481 In order to avoid the problem described above, implementations SHOULD 482 implement the recommendations provided in Section 6.4 of this 483 document. 485 3.6. IPv4 Reassembly Errors at High Data Rates 487 IPv4 fragmentation is not sufficiently robust for use under some 488 conditions in today's Internet. At high data rates, the 16-bit IP 489 identification field is not large enough to prevent duplicate IDs 490 resulting in frequent incorrectly assembled IP fragments, and the TCP 491 and UDP checksums are insufficient to prevent the resulting corrupted 492 datagrams from being delivered to higher protocol layers. [RFC4963] 493 describes some easily reproduced experiments demonstrating the 494 problem, and discusses some of the operational implications of these 495 observations. 497 These reassembly issues do not occur as frequently in IPv6 because 498 the IPv6 identification field is 32 bits long. 500 3.7. Security Vulnerabilities 502 Security researchers have documented several attacks that exploit IP 503 fragmentation. The following are examples: 505 o Overlapping fragment attacks [RFC1858][RFC3128][RFC5722] 507 o Resource exhaustion attacks 509 o Attacks based on predictable fragment identification values 510 [RFC7739] 512 o Evasion of Network Intrusion Detection Systems (NIDS) [Ptacek1998] 514 In the overlapping fragment attack, an attacker constructs a series 515 of packet fragments. The first fragment contains an IP header, a 516 transport-layer header, and some transport-layer payload. This 517 fragment complies with local security policy and is allowed to pass 518 through a stateless firewall. A second fragment, having a non-zero 519 offset, overlaps with the first fragment. The second fragment also 520 passes through the stateless firewall. When the packet is 521 reassembled, the transport layer header from the first fragment is 522 overwritten by data from the second fragment. The reassembled packet 523 does not comply with local security policy. Had it traversed the 524 firewall in one piece, the firewall would have rejected it. 526 A stateless firewall cannot protect against the overlapping fragment 527 attack. However, destination nodes can protect against the 528 overlapping fragment attack by implementing the procedures described 529 in RFC 1858, RFC 3128 and RFC 8200. These reassembly procedures 530 detect the overlap and discard the packet. 532 The fragment reassembly algorithm is a stateful procedure in an 533 otherwise stateless protocol. Therefore, it can be exploited by 534 resource exhaustion attacks. An attacker can construct a series of 535 fragmented packets, with one fragment missing from each packet so 536 that the reassembly is impossible. Thus, this attack causes resource 537 exhaustion on the destination node, possibly denying reassembly 538 services to other flows. This type of attack can be mitigated by 539 flushing fragment reassembly buffers when necessary, at the expense 540 of possibly dropping legitimate fragments. 542 Each IP fragment contains an "Identification" field that destination 543 nodes use to reassemble fragmented packets. Many implementations set 544 the Identification field to a predictable value, thus making it easy 545 for an attacker to forge malicious IP fragments that would cause the 546 reassembly procedure for legitimate packets to fail. 548 NIDS aims at identifying malicious activity by analyzing network 549 traffic. Ambiguity in the possible result of the fragment reassembly 550 process may allow an attacker to evade these systems. Many of these 551 systems try to mitigate some of these evasion techniques (e.g. By 552 computing all possible outcomes of the fragment reassembly process, 553 at the expense of increased processing requirements). 555 3.8. PMTU Blackholing Due to ICMP Loss 557 As mentioned in Section 2.3, upper-layer protocols can be configured 558 to rely on PMTUD. Because PMTUD relies upon the network to deliver 559 ICMP PTB messages, those protocols also rely on the networks to 560 deliver ICMP PTB messages. 562 According to [RFC4890], ICMP PTB messages must not be filtered. 563 However, ICMP PTB delivery is not reliable. It is subject to both 564 transient and persistent loss. 566 Transient loss of ICMP PTB messages can cause transient PMTU black 567 holes. When the conditions contributing to transient loss abate, the 568 network regains its ability to deliver ICMP PTB messages and 569 connectivity between the source and destination nodes is restored. 571 Section 3.8.1 of this document describes conditions that lead to 572 transient loss of ICMP PTB messages. 574 Persistent loss of ICMP PTB messages can cause persistent black 575 holes. Section 3.8.2, Section 3.8.3, and Section 3.8.4 of this 576 document describe conditions that lead to persistent loss of ICMP PTB 577 messages. 579 The problem described in this section is specific to PMTUD. It does 580 not occur when the upper-layer protocol obtains its PMTU estimate 581 from PLPMTUD or from any other source. 583 3.8.1. Transient Loss 585 The following factors can contribute to transient loss of ICMP PTB 586 messages: 588 o Network congestion. 590 o Packet corruption. 592 o Transient routing loops. 594 o ICMP rate limiting. 596 The effect of rate limiting may be severe, as RFC 4443 recommends 597 strict rate limiting of IPv6 traffic. 599 3.8.2. Incorrect Implementation of Security Policy 601 Incorrect implementation of security policy can cause persistent loss 602 of ICMP PTB messages. 604 Assume that a Customer Premise Equipment (CPE) router implements the 605 following zone-based security policy: 607 o Allow any traffic to flow from the inside zone to the outside 608 zone. 610 o Do not allow any traffic to flow from the outside zone to the 611 inside zone unless it is part of an existing flow (i.e., it was 612 elicited by an outbound packet). 614 When a correct implementation of the above-mentioned security policy 615 receives an ICMP PTB message, it examines the ICMP PTB payload in 616 order to determine whether the original packet (i.e., the packet that 617 elicited the ICMP PTB message) belonged to an existing flow. If the 618 original packet belonged to an existing flow, the implementation 619 allows the ICMP PTB to flow from the outside zone to the inside zone. 620 If not, the implementation discards the ICMP PTB message. 622 When a incorrect implementation of the above-mentioned security 623 policy receives an ICMP PTB message, it discards the packet because 624 its source address is not associated with an existing flow. 626 The security policy described above is implemented incorrectly on 627 many consumer CPE routers. 629 3.8.3. Persistent Loss Caused By Anycast 631 Anycast can cause persistent loss of ICMP PTB messages. Consider the 632 example below: 634 A DNS client sends a request to an anycast address. The network 635 routes that DNS request to the nearest instance of that anycast 636 address (i.e., a DNS Server). The DNS server generates a response 637 and sends it back to the DNS client. While the response does not 638 exceed the DNS server's PMTU estimate, it does exceed the actual 639 PMTU. 641 A downstream router drops the packet and sends an ICMP PTB message 642 the packet's source (i.e., the anycast address). The network routes 643 the ICMP PTB message to the anycast instance closest to the 644 downstream router. That anycast instance may not be the DNS server 645 that originated the DNS response. It may be another DNS server with 646 the same anycast address. The DNS server that originated the 647 response may never receive the ICMP PTB message and may never update 648 its PMTU estimate. 650 3.8.4. Persistent Loss Caused By Unidirectional Routing 652 Unidirectional routing can cause persistent loss of ICMP PTB 653 messages. Consider the example below: 655 A source node sends a packet to a destination node. All intermediate 656 nodes maintain a route to the destination node, but do not maintain a 657 route to the source node. In this case, when an intermediate node 658 encounters an MTU issue, it cannot send an ICMP PTB message to the 659 source node. 661 3.9. Blackholing Due To Filtering or Loss 663 In RFC 7872, researchers sampled Internet paths to determine whether 664 they would convey packets that contain IPv6 extension headers. 665 Sampled paths terminated at popular Internet sites (e.g., popular 666 web, mail and DNS servers). 668 The study revealed that at least 28% of the sampled paths did not 669 convey packets containing the IPv6 Fragment extension header. In 670 most cases, fragments were dropped in the destination autonomous 671 system. In other cases, the fragments were dropped in transit 672 autonomous systems. 674 Another recent study [Huston] confirmed this finding. It reported 675 that 37% of sampled endpoints used IPv6-capable DNS resolvers that 676 were incapable of receiving a fragmented IPv6 response. 678 It is difficult to determine why network operators drop fragments. 679 Possible causes follow: 681 o Hardware inability to process fragmented packets. 683 o Failure to change vendor defaults. 685 o Unintentional misconfiguration. 687 o Intentional configuration (e.g., network operators consciously 688 chooses to drop IPv6 fragments in order to address the issues 689 raised in Section 3.2 through Section 3.8, above.) 691 4. Alternatives to IP Fragmentation 693 4.1. Transport Layer Solutions 695 The Transport Control Protocol (TCP) [RFC0793]) can be operated in a 696 mode that does not require IP fragmentation. 698 Applications submit a stream of data to TCP. TCP divides that stream 699 of data into segments, with no segment exceeding the TCP Maximum 700 Segment Size (MSS). Each segment is encapsulated in a TCP header and 701 submitted to the underlying IP module. The underlying IP module 702 prepends an IP header and forwards the resulting packet. 704 If the TCP MSS is sufficiently small, the underlying IP module never 705 produces a packet whose length is greater than the actual PMTU. 706 Therefore, IP fragmentation is not required. 708 TCP offers the following mechanisms for MSS management: 710 o Manual configuration 712 o PMTUD 714 o PLPMTUD 715 Manual configuration is always applicable. If the MSS is configured 716 to a sufficiently low value, the IP layer will never produce a packet 717 whose length is greater than the protocol minimum link MTU. However, 718 manual configuration prevents TCP from taking advantage of larger 719 link MTU's. 721 Upper-layer protocols can implement PMTUD in order to discover and 722 take advantage of larger path MTUs. However, as mentioned in 723 Section 2.1, PMTUD relies upon the network to deliver ICMP PTB 724 messages. Therefore, PMTUD can only provide an estimate of the PMTU 725 in environments where the risk of ICMP PTB loss is acceptable (e.g., 726 known to not be filtered). 728 By contrast, PLPMTUD does not rely upon the network's ability to 729 deliver ICMP PTB messages. It utilises probe messages sent as TCP 730 segments to determine whether the probed PMTU can be successfully 731 used across the network path. In PLPMTUD, probing is separated from 732 congestion control, so that loss of a TCP probe segment does not 733 cause a reduction of the congestion control window. [RFC4821] 734 defines PLPMTUD procedures for TCP. 736 While TCP will never knowingly cause the underlying IP module to emit 737 a packet that is larger than the PMTU estimate, it can cause the 738 underlying IP module to emit a packet that is larger than the actual 739 PMTU. For example, if routing changes and as a result the PMTU 740 becomes smaller, TCP will not know until the ICMP PTB message 741 arrives. If this occurs, the packet is dropped, the PMTU estimate is 742 updated, the segment is divided into smaller segments and each 743 smaller segment is submitted to the underlying IP module. 745 The Datagram Congestion Control Protocol (DCCP) [RFC4340] and the 746 Stream Control Transport Protocol (SCTP) [RFC4960] also can be 747 operated in a mode that does not require IP fragmentation. They both 748 accept data from an application and divide that data into segments, 749 with no segment exceeding a maximum size. 751 DCCP offers manual configuration, PMTUD, and PLPMTUD as mechanisms 752 for managing that maximum size. Datagram protocols can also 753 implement PLPMTUD to estimate the PMTU 754 via[I-D.ietf-tsvwg-datagram-plpmtud]. This proposes procedures for 755 performing PLPMTUD with UDP, UDP-Options, SCTP, QUIC and other 756 datagram protocols. 758 Currently, User Data Protocol (UDP) [RFC0768] lacks a fragmentation 759 mechanism of its own and relies on IP fragmentation. However, 760 [I-D.ietf-tsvwg-udp-options] proposes a fragmentation mechanism for 761 UDP. 763 4.2. Application Layer Solutions 765 [RFC8085] recognizes that IP fragmentation reduces the reliability of 766 Internet communication. It also recognizes that UDP lacks a 767 fragmentation mechanism of its own and relies on IP fragmentation. 768 Therefore, [RFC8085] offers the following advice regarding 769 applications the run over the UDP. 771 "An application SHOULD NOT send UDP datagrams that result in IP 772 packets that exceed the Maximum Transmission Unit (MTU) along the 773 path to the destination. Consequently, an application SHOULD either 774 use the path MTU information provided by the IP layer or implement 775 Path MTU Discovery (PMTUD) itself to determine whether the path to a 776 destination will support its desired message size without 777 fragmentation." 779 RFC 8085 continues: 781 "Applications that do not follow the recommendation to do PMTU/ 782 PLPMTUD discovery SHOULD still avoid sending UDP datagrams that would 783 result in IP packets that exceed the path MTU. Because the actual 784 path MTU is unknown, such applications SHOULD fall back to sending 785 messages that are shorter than the default effective MTU for sending 786 (EMTU_S in [RFC1122]). For IPv4, EMTU_S is the smaller of 576 bytes 787 and the first-hop MTU. For IPv6, EMTU_S is 1280 bytes [RFC8200]. 788 The effective PMTU for a directly connected destination (with no 789 routers on the path) is the configured interface MTU, which could be 790 less than the maximum link payload size. Transmission of minimum- 791 sized UDP datagrams is inefficient over paths that support a larger 792 PMTU, which is a second reason to implement PMTU discovery." 794 RFC 8085 assumes that for IPv4, an EMTU_S of 576 is sufficiently 795 small is sufficiently small to be supported by most current Internet 796 paths, even though the IPv4 minimum link MTU is 68 bytes. 798 This advice applies equally to any application that runs directly 799 over IP. 801 5. Applications That Rely on IPv6 Fragmentation 803 The following applications rely on IPv6 fragmentation: 805 o DNS [RFC1035] 807 o OSPFv3 [RFC2328][RFC5340] 809 o Packet-in-packet encapsulations 810 Each of these applications relies on IPv6 fragmentation to a varying 811 degree. In some cases, that reliance is essential, and cannot be 812 broken without fundamentally changing the protocol. In other cases, 813 that reliance is incidental, and most implementations already take 814 appropriate steps to avoid fragmentation. 816 This list is not comprehensive, and other protocols that rely on IP 817 fragmentation may exist. They are not specifically considered in the 818 context of this document. 820 5.1. Domain Name Service (DNS) 822 DNS relies on UDP for efficiency, and the consequence is the use of 823 IP fragmentation for large responses, as permitted by the DNS EDNS0 824 options in the query. It is possible to mitigate the issue of 825 fragmentation-based packet loss by having queries use smaller EDNS0 826 UDP buffer sizes, or by having the DNS server limit the size of its 827 UDP responses to some self-imposed maximum packet size that may be 828 less than the preferred EDNS0 UDP Buffer Size. In both cases, large 829 responses are truncated in the DNS, signalling to the client to re- 830 query using TCP to obtain the complete response. However, the 831 operational issue of the partial level of support for DNS over TCP, 832 particularly in the case where IPv6 transport is being used, becomes 833 a limiting factor of the efficacy of this approach [Damas]. 835 Larger DNS responses can normally be avoided by aggressively pruning 836 the Additional section of DNS responses. One scenario where such 837 pruning is ineffective is in the use of DNSSEC, where large key sizes 838 act to increase the response size to certain DNS queries. There is 839 no effective response to this situation within the DNS other than 840 using smaller cryptographic keys and adoption of DNSSEC 841 administrative practices that attempt to keep DNS response as short 842 as possible. 844 5.2. Open Shortest Path First (OSPF) 846 OSPF implementations can emit messages large enough to cause 847 fragmentation. However, in order to optimize performance, most OSPF 848 implementations restrict their maximum message size to a value that 849 will not cause fragmentation. 851 5.3. Packet-in-Packet Encapsulations 853 In this document, packet-in-packet encapsulations include IP-in-IP 854 [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP 855 [RFC8086] and Generic Packet Tunneling in IPv6 [RFC2473]. [RFC4459] 856 describes fragmentation issues associated with all of the above- 857 mentioned encapsulations. 859 The fragmentation strategy described for GRE in [RFC7588] has been 860 deployed for all of the above-mentioned encapsulations. This 861 strategy does not rely on IP fragmentation except in one corner case. 862 (see Section 3.3.2.2 of RFC 7588 and Section 7.1 of RFC 2473). 863 Section 3.3 of [RFC7676] further describes this corner case. 865 See [I-D.ietf-intarea-tunnels] for further discussion. 867 5.4. UDP Applications Enhancing Performance 869 Some UDP applications rely on IP fragmentation to achieve acceptable 870 levels of performance. These applications use UDP datagram sizes 871 that are larger than the path MTU so that more data can be conveyed 872 between the application and the kernel in a single system call. 874 To pick one example, the Licklider Transmission Protocol (LTP), 875 [RFC5326]which is in current use on the International Space Station 876 (ISS), uses UDP datagram sizes larger than the path MTU to achieve 877 acceptable levels of performance even though this invokes IP 878 fragmentation. More generally, SNMP and video applications may 879 transmit an application-layer quantum of data, depending on the 880 network layer to fragment and reassemble as needed. 882 6. Recommendations 884 6.1. For Application and Protocol Developers 886 Developers SHOULD NOT develop new protocols or applications that rely 887 on IP fragmentation. When a new protocol or application is deployed 888 in an environment that does not fully support IP fragmentation, it 889 SHOULD operate correctly, either in its default configuration or in a 890 specified alternative configuration. 892 Developers MAY develop new protocols or applications that rely on IP 893 fragmentation if the protocol or application is to be run only in 894 environments where IP fragmentation is known to be supported. 896 Legacy protocols that depend upon IP fragmentation SHOULD be updated 897 to break that dependency. However, in some cases, there may be no 898 viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP- 899 in-IP encapsulation). In these cases, the protocol will continue to 900 rely on IP fragmentation but should only be used in environments 901 where IP fragmentation is known to be supported. 903 Protocols may be able to avoid IP fragmentation by using a 904 sufficiently small MTU (e.g. The protocol minimum link MTU), 905 disabling IP fragmentation, and ensuring that the transport protocol 906 in use adapts its segment size to the MTU. Other protocols may 907 deploy a sufficiently reliable PMTU discovery mechanism 908 (e.g.,PLMPTUD). 910 UDP applications SHOULD abide by the recommendations stated in 911 Section 3.2 of [RFC8085]. 913 6.2. For System Developers 915 Software libraries SHOULD include provision for PLPMTUD for each 916 supported transport protocol. 918 6.3. For Middle Box Developers 920 Middle boxes should process IP fragments in a manner that is 921 consistent with [RFC0791] and [RFC8200]. In many cases, middle boxes 922 must maintain state in order to achieve this goal. 924 Price and performance considerations frequently motivate network 925 operators to deploy stateless middle boxes. These stateless middle 926 boxes may perform sub-optimally, process IP fragments in a manner 927 that is not compliant with RFC 791 or RFC 8200, or even discard IP 928 fragments completely. Such behaviors are NOT RECOMMENDED. If a 929 middleboxes implements non-standard behavior with respect to IP 930 fragmentation, then that behavior MUST be clearly documented. 932 6.4. For ECMP, LAG and Load-Balancer Developers And Operators 934 In their default configuration, when the IPv6 Flow Label is not equal 935 to zero, IPv6 devices that implement Equal-Cost Multipath (ECMP) 936 Routing as described in OSPF [RFC2328] and other routing protocols, 937 Link Aggregation Grouping (LAG) [RFC7424], or other load-distribution 938 technologies SHOULD accept only the following fields as input to 939 their hash algorithm: 941 o IP Source Address. 943 o IP Destination Address. 945 o Flow Label. 947 Operators SHOULD deploy these devices in their default configuration. 949 These recommendations are similar to those presented in [RFC6438] and 950 [RFC7098]. They differ in that they specify a default configuration. 952 6.5. For Network Operators 954 Operators MUST ensure proper PMTUD operation in their network, 955 including making sure the network generates PTB packets when dropping 956 packets too large compared to outgoing interface MTU. However, 957 implementations MAY rate limit ICMP messages as per [RFC1812] and 958 [RFC4443]. 960 As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB 961 messages unless they are known to be forged or otherwise 962 illegitimate. As stated in Section 3.8, filtering ICMPv6 PTB packets 963 causes PMTUD to fail. Many upper-layer protocols rely on PMTUD. 965 As per RFC 8200, network operators MUST NOT deploy IPv6 links whose 966 MTU is less than 1280 bytes. 968 Network operators SHOULD NOT filter IP fragments if they are known to 969 have originated at a domain name server or be destined for a domain 970 name server. This is because domain name services are critical to 971 operation of the Internet. 973 7. IANA Considerations 975 This document makes no request of IANA. 977 8. Security Considerations 979 This document mitigates some of the security considerations 980 associated with IP fragmentation by discouraging its use. It does 981 not introduce any new security vulnerabilities, because it does not 982 introduce any new alternatives to IP fragmentation. Instead, it 983 recommends well-understood alternatives. 985 9. Acknowledgements 987 Thanks to Mikael Abrahamsson, Brian Carpenter, Silambu Chelvan, 988 Lorenzo Colitti, Gorry Fairhurst, Mike Heard, Tom Herbert, Tatuya 989 Jinmei, Jen Linkova, Paolo Lucente, Manoj Nayak, Eric Nygren, Fred 990 Templin and Joe Touch for their comments. 992 10. References 994 10.1. Normative References 996 [I-D.ietf-tsvwg-datagram-plpmtud] 997 Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 998 T. Voelker, "Packetization Layer Path MTU Discovery for 999 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08 1000 (work in progress), June 2019. 1002 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1003 DOI 10.17487/RFC0768, August 1980, 1004 . 1006 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1007 DOI 10.17487/RFC0791, September 1981, 1008 . 1010 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1011 RFC 792, DOI 10.17487/RFC0792, September 1981, 1012 . 1014 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1015 RFC 793, DOI 10.17487/RFC0793, September 1981, 1016 . 1018 [RFC1035] Mockapetris, P., "Domain names - implementation and 1019 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1020 November 1987, . 1022 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1023 DOI 10.17487/RFC1191, November 1990, 1024 . 1026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1027 Requirement Levels", BCP 14, RFC 2119, 1028 DOI 10.17487/RFC2119, March 1997, 1029 . 1031 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1032 Control Message Protocol (ICMPv6) for the Internet 1033 Protocol Version 6 (IPv6) Specification", STD 89, 1034 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1035 . 1037 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1038 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1039 . 1041 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1042 "IPv6 Flow Label Specification", RFC 6437, 1043 DOI 10.17487/RFC6437, November 2011, 1044 . 1046 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1047 for Equal Cost Multipath Routing and Link Aggregation in 1048 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 1049 . 1051 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1052 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1053 March 2017, . 1055 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1056 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1057 May 2017, . 1059 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1060 (IPv6) Specification", STD 86, RFC 8200, 1061 DOI 10.17487/RFC8200, July 2017, 1062 . 1064 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 1065 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 1066 DOI 10.17487/RFC8201, July 2017, 1067 . 1069 10.2. Informative References 1071 [Damas] Damas, J. and G. Huston, "Measuring ATR", April 2018, 1072 . 1074 [Huston] Huston, G., "IPv6, Large UDP Packets and the DNS 1075 http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html", 1076 August 2017. 1078 [I-D.ietf-intarea-tunnels] 1079 Touch, J. and M. Townsley, "IP Tunnels in the Internet 1080 Architecture", draft-ietf-intarea-tunnels-09 (work in 1081 progress), July 2018. 1083 [I-D.ietf-tsvwg-udp-options] 1084 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 1085 udp-options-07 (work in progress), March 2019. 1087 [Kent] Kent, C. and J. Mogul, ""Fragmentation Considered 1088 Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in 1089 Computer Communications Technology, DOI 1090 10.1145/55483.55524", August 1987, 1091 . 1094 [Ptacek1998] 1095 Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial 1096 of Service: Eluding Network Intrusion Detection", 1998, 1097 . 1099 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1100 Communication Layers", STD 3, RFC 1122, 1101 DOI 10.17487/RFC1122, October 1989, 1102 . 1104 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 1105 RFC 1812, DOI 10.17487/RFC1812, June 1995, 1106 . 1108 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1109 Considerations for IP Fragment Filtering", RFC 1858, 1110 DOI 10.17487/RFC1858, October 1995, 1111 . 1113 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1114 DOI 10.17487/RFC2003, October 1996, 1115 . 1117 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1118 DOI 10.17487/RFC2328, April 1998, 1119 . 1121 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1122 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1123 December 1998, . 1125 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1126 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1127 DOI 10.17487/RFC2784, March 2000, 1128 . 1130 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1131 Fragment Attack (RFC 1858)", RFC 3128, 1132 DOI 10.17487/RFC3128, June 2001, 1133 . 1135 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1136 Congestion Control Protocol (DCCP)", RFC 4340, 1137 DOI 10.17487/RFC4340, March 2006, 1138 . 1140 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1141 Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 1142 2006, . 1144 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1145 ICMPv6 Messages in Firewalls", RFC 4890, 1146 DOI 10.17487/RFC4890, May 2007, 1147 . 1149 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1150 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1151 . 1153 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1154 Errors at High Data Rates", RFC 4963, 1155 DOI 10.17487/RFC4963, July 2007, 1156 . 1158 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 1159 Transmission Protocol - Specification", RFC 5326, 1160 DOI 10.17487/RFC5326, September 2008, 1161 . 1163 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1164 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1165 . 1167 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 1168 RFC 5722, DOI 10.17487/RFC5722, December 2009, 1169 . 1171 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 1172 DOI 10.17487/RFC5927, July 2010, 1173 . 1175 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 1176 the IPv4 Address Shortage", RFC 6346, 1177 DOI 10.17487/RFC6346, August 2011, 1178 . 1180 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 1181 A., and H. Ashida, "Common Requirements for Carrier-Grade 1182 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 1183 April 2013, . 1185 [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 1186 Flow Label for Load Balancing in Server Farms", RFC 7098, 1187 DOI 10.17487/RFC7098, January 2014, 1188 . 1190 [RFC7424] Krishnan, R., Yong, L., Ghanwani, A., So, N., and B. 1191 Khasnabish, "Mechanisms for Optimizing Link Aggregation 1192 Group (LAG) and Equal-Cost Multipath (ECMP) Component Link 1193 Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424, 1194 January 2015, . 1196 [RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely 1197 Deployed Solution to the Generic Routing Encapsulation 1198 (GRE) Fragmentation Problem", RFC 7588, 1199 DOI 10.17487/RFC7588, July 2015, 1200 . 1202 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 1203 for Generic Routing Encapsulation (GRE)", RFC 7676, 1204 DOI 10.17487/RFC7676, October 2015, 1205 . 1207 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1208 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1209 February 2016, . 1211 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1212 "Observations on the Dropping of Packets with IPv6 1213 Extension Headers in the Real World", RFC 7872, 1214 DOI 10.17487/RFC7872, June 2016, 1215 . 1217 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 1218 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 1219 March 2017, . 1221 Appendix A. Contributors' Address 1222 Authors' Addresses 1224 Ron Bonica 1225 Juniper Networks 1226 2251 Corporate Park Drive 1227 Herndon, Virginia 20171 1228 USA 1230 Email: rbonica@juniper.net 1232 Fred Baker 1233 Unaffiliated 1234 Santa Barbara, California 93117 1235 USA 1237 Email: FredBaker.IETF@gmail.com 1239 Geoff Huston 1240 APNIC 1241 6 Cordelia St 1242 Brisbane, 4101 QLD 1243 Australia 1245 Email: gih@apnic.net 1247 Robert M. Hinden 1248 Check Point Software 1249 959 Skyway Road 1250 San Carlos, California 94070 1251 USA 1253 Email: bob.hinden@gmail.com 1255 Ole Troan 1256 Cisco 1257 Philip Pedersens vei 1 1258 N-1366 Lysaker 1259 Norway 1261 Email: ot@cisco.com 1262 Fernando Gont 1263 SI6 Networks 1264 Evaristo Carriego 2644 1265 Haedo, Provincia de Buenos Aires 1266 Argentina 1268 Email: fgont@si6networks.com