idnits 2.17.1 draft-bonica-6man-frag-deprecate-02.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2013) is 3941 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0793' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-predictable-fragment-id' is defined on line 447, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) == Outdated reference: A later version (-09) exists of draft-ietf-6man-oversized-header-chain-02 == Outdated reference: A later version (-10) exists of draft-ietf-6man-predictable-fragment-id-00 == Outdated reference: A later version (-02) exists of draft-taylor-v6ops-fragdrop-01 -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group R. Bonica 3 Internet-Draft Juniper Networks 4 Updates: RFC 2460 (if approved) W. Kumari 5 Intended status: Standards Track Google, Inc. 6 Expires: January 12, 2014 R. Bush 7 Internet Initiative Japan 8 H. Pfeifer 9 ProtocolLabs 10 July 11, 2013 12 IPv6 Fragment Header Deprecated 13 draft-bonica-6man-frag-deprecate-02 15 Abstract 17 This memo deprecates IPv6 fragmentation and the IPv6 fragment header. 18 It provides reasons for deprecation and updates RFC 2460. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 12, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Case For Deprecation . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Resource Conservation . . . . . . . . . . . . . . . . . . 3 63 2.2. Application Reliance on IPv6 Fragmentation . . . . . . . 3 64 2.3. Attack Vectors . . . . . . . . . . . . . . . . . . . . . 5 65 2.4. Operator Behavior . . . . . . . . . . . . . . . . . . . . 6 66 3. Applications That Rely on Fragmentation . . . . . . . . . . . 6 67 3.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.2. SIIT . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.3. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.4. DCCP and NFS . . . . . . . . . . . . . . . . . . . . . . 8 71 3.5. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 8 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 8.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 Each link on the Internet is characterized by a Maximum Transmission 84 Unit (MTU). A link's MTU represents the maximum packet size that can 85 be conveyed over the link, without fragmentation. IPv6 [RFC2460] 86 requires that every link in the Internet have an MTU of 1280 octets 87 or greater. On any link that cannot convey a 1280-octet packet in 88 one piece, link-specific fragmentation and reassembly must be 89 provided at a layer below IPv6. 91 For any given source node, the path to a particular destination is 92 characterized by a path MTU (PMTU). At a given source, the PMTU 93 associated with a destination is equal to the minimum MTU of all of 94 the links in the path between the source and the destination. 95 Because every IPv6-enabled link must support an MTU or 1280 bytes or 96 greater, the PMTU between any two IPv6 nodes is also 1280 bytes or 97 greater. 99 [RFC2460] strongly recommends that IPv6 nodes implement Path MTU 100 Discovery (PMTUD) [RFC1981], in order to discover and take advantage 101 of PMTU values greater than 1280 octets. However, a minimal IPv6 102 implementation (e.g., in a boot ROM) may simply restrict itself to 103 sending packets no larger than 1280 octets, and omit implementation 104 of PMTUD. 106 In order to send a packet larger than a path's MTU, a node may use 107 the IPv6 Fragment header to fragment the packet at the source and 108 have it reassembled at the destination(s). However, the use of such 109 fragmentation is discouraged in any application that is able to 110 adjust its packets to fit the measured path MTU (i.e., down to 1280 111 octets). 113 In IPv6, a packet can be fragmented only by the host that originates 114 it. This constitutes a departure from the IPv4 [RFC0791] 115 fragmentation strategy, in which a packet can be fragmented by its 116 originator or by any router that it traverses en route to its 117 destination. 119 This memo deprecates IPv6 fragmentation and the IPv6 fragment header. 120 It provides reasons for deprecation and updates [RFC2460]. 122 2. Case For Deprecation 124 This section presents a case for deprecating the IPv6 Fragment 125 Header. 127 2.1. Resource Conservation 129 Packets that are fragmented at their source need to be reassembled at 130 their destination. [Kent87] points out that the reassembly process 131 is resource intensive. It consumes significant compute and memory 132 resources. While the cited reference refers to IPv4 fragmentation 133 and reassembly, many of its criticisms are equally applicable to 134 IPv6. 136 By comparison, if a source node were to execute PMTUD procedures, and 137 if applications were to avoid sending datagrams that would result in 138 IP packets that exceed the PMTU, the task of reassembly could be 139 avoided, altogether. 141 2.2. Application Reliance on IPv6 Fragmentation 143 Today, a limited number of applications rely upon IPv6 fragmentation. 145 Most popular TCP implementations include PMTUD or an extension 146 thereof, called Packetization Layer MTU Discovery (PMTUD) [RFC4821]. 147 Therefore, in the nominal case, applications obtaining transport 148 services from these TCP implementations never cause IPv6 fragments to 149 be sent. However, some TCP implementations that include PMTUD do 150 emit segments long enough to cause IPv6 fragmentation. This happens 151 in the following circumstance: 153 o The TCP implementation establishes two (or more) sessions to the 154 same destination 156 o Because the TCP implementation has not yet emitted any long 157 segments, the underlying IPv6 implementation estimates the PMTU 158 for destination to be equal to the MTU of the first link in the 159 path to the destination. This estimate is incorrect, and will be 160 revised, below. 162 o The first TCP session submits a long segment to the underlying 163 IPv6 implementation 165 o The underlying IPv6 implementation determines that if it were to 166 encapsulate this segment in an IPv6 header, the resulting packet 167 would not exceed its current estimate of the PMTU for the 168 destination. So, the underlying IPv6 implementation emits a non- 169 fragmented IPv6 packet. This packet exceeds the actual PMTU for 170 the destination 172 o A downstream router discards the long packet and returns an ICMPv6 173 Packet Too Big (PTB) message. 175 o The first TCP session reduces its Maximum Segment Size (MSS) to an 176 appropriate value 178 o The underlying IPv6 implementation reduces its estimate of the 179 PMTU for the destination to an appropriate value 181 o The second TCP session submits a long segment to the underlying 182 IPv6 implementation. It does so without first querying the 183 underlying IPv6 implementation to learn its estimate of the PMTU 184 for the destination 186 o The underlying IPv6 implementation determines that if it were to 187 encapsulate this segment in an IPv6 header, the resulting packet 188 would exceed its current estimate of the PMTU for the destination. 189 So, the underlying IPv6 implementation emits multiple IPv6 190 fragments. 192 The authors suggest that the behavior described above may be sub- 193 optimal, and that TCP implementations should leverage PMTU 194 information that the underlying IPv6 implementation could provide. 196 Many UDP-based [RFC0768] applications follow the recommendations of 197 [RFC5405]. According to [RFC5405], "an application SHOULD NOT send 198 UDP datagrams that result in IP packets that exceed the MTU of the 199 path to the destination. Consequently, an application SHOULD either 200 use the path MTU information provided by the IP layer or implement 201 path MTU discovery itself to determine whether the path to a 202 destination will support its desired message size without 203 fragmentation. Applications that do not follow this recommendation 204 to do PMTU discovery SHOULD still avoid sending UDP datagrams that 205 would result in IP packets that exceed the path MTU. Because the 206 actual path MTU is unknown, such applications SHOULD fall back to 207 sending messages that are shorter than the default effective MTU for 208 sending." The effective MTU for IPv6 is 1280 bytes. 210 However, several applications are known to rely on IPv6 211 fragmentation. Some of these are mentioned in Section 3. 213 2.3. Attack Vectors 215 Security researchers have found and continue to find attack vectors 216 that rely on IP fragmentation. For example, 217 [I-D.ietf-6man-oversized-header-chain] and 218 [I-D.ietf-6man-nd-extension-headers] describe variants of the tiny 219 fragment attack [RFC1858]. In this attack, a packet is crafted so 220 that it can evade stateless firewall filters. The stateless firewall 221 filter matches on fields drawn from the IPv6 header and an upper 222 layer header. However, the packet is fragmented so that the upper 223 layer header, or a significant part of that header, does not appear 224 in the first fragment. Because a stateless firewall cannot parse 225 payload beyond the first fragment, the packet evades detection by the 226 firewall. 228 Security researcher have also studied reassembly algorithms on 229 popular computing platforms, with the following goals: 231 o to discover fragility in seldom exercised parts of the IP stack 233 o to engineer flows that maximize resources consumed by the 234 reassembly process 236 The Dawn and Rose Attacks [Hollis] are the products of such research. 238 All of the attack vectors mentioned above can be mitigated with 239 firewalls and increasingly sophisticated reassembly algorithms. 241 However, the continued investment required to mitigate newly 242 discovered vulnerabilities detracts from the cost effectiveness of 243 IPv6 as a networking solution. 245 2.4. Operator Behavior 247 For reasons described above, and also articulated in 248 [I-D.taylor-v6ops-fragdrop], many network operators filter all IPv6 249 fragments. Also, the default behavior of many currently deployed 250 firewalls is to discard IPv6 fragments. 252 In one recent study [DeBoer], two researchers utilized a measurement 253 network to measure fragment filtering. They sent packets, fragmented 254 to the minimum MTU of 1280, to 502 IPv6 enabled and reachable probes. 255 They found that during any given trial period, ten percent of the 256 probes did not receive fragmented packets. 258 3. Applications That Rely on Fragmentation 260 The following is a list of applications that are currently known to 261 rely on IPv6 fragmentation: 263 o DNSSEC [RFC4035]. 265 o SIIT [RFC6145] 267 o OSPFv3 [RFC5340] 269 o NFSv4 [RFC3530] 271 o DCCP [RFC4340] 273 Some tunneling configurations also rely upon IPv6 fragmentation. See 274 Section 3.5 for details. 276 Each of these applications relies on fragmentation to a varying 277 degree. In some cases, that reliance is essential, and cannot be 278 broken without fundamentally changing the protocol. In other cases, 279 that reliance is incidental, and most protocol implementations 280 already take appropriate steps to avoid fragmentation. 282 Each of these applications will continue to emit IPv6 fragments, even 283 after the IPv6 fragmentation header is deprecated. In order to 284 achieve backwards compatibility, new IPv6 implementations will 285 continue to support reassembly of incoming fragments. See for 286 Section 4 details. 288 3.1. DNSSEC 290 DNSSEC can obtain transport services from either UDP or TCP. 291 Superior performance and scaling characteristics are observed when 292 DNSSEC runs over UDP. 294 When running over UDP, DNSSEC is likely to cause the generation of 295 IPv6 fragments. By comparison, when running over TCP, DNSSEC is much 296 less likely to cause the generation of IPv6 fragments. 298 When running over UDP, DNSSEC's reliance upon IPv6 fragmentation is 299 fundamental. That reliance cannot be broken without changing the 300 DNSSEC specification. 302 DNSSEC is an essential part of the Internet architecture. Therefore, 303 this issue is for further study and must be resolved before IPv6 304 fragmentation can be deprecated. 306 3.2. SIIT 308 [RFC6145] requires the following: 310 o "When the IPv4 sender does not set the DF bit, the translator 311 SHOULD always include an IPv6 Fragment Header to indicate that the 312 sender allows fragmentation. The translator MAY provide a 313 configuration function that allows the translator not to include 314 the Fragment Header for the non-fragmented IPv6 packets". 316 o "If the DF flag is not set and the IPv4 packet will result in an 317 IPv6 packet larger than 1280 bytes, the packet SHOULD be 318 fragmented so the resulting IPv6 packet (with Fragment Header 319 added to each fragment) will be less than or equal to 1280 bytes." 321 These behaviors cannot be changed, and for these reasons, SIIT 322 devices will continue to emit IPv6 fragments, even after IPv6 323 fragmentation has been deprecated. 325 SIIT also emits ICMPv6 PTB messages with MTU less than 1280. In that 326 case, the originating IPv6 node is not required to reduce the size of 327 subsequent packets to less than 1280, but must include a Fragment 328 header in those packets so that SIIT can obtain a suitable 329 Identification value to use in resulting IPv4 fragments. Note that 330 this means the payload may have to be reduced to 1232 octets (1280 331 minus 40 for the IPv6 header and 8 for the Fragment header), and 332 smaller still if additional extension headers are used. 334 This problem could be avoided if SIIT executed an alternative 335 procedure. For example, rather than discarding the packet and 336 sending an ICMPv6 PTB message with MTU less than 1280, SIIT could 337 generate a random number for use as the Identification value and 338 forward the packet. This issue clearly requires further study. 340 3.3. OSPFv3 342 OSPFv3 implementations may emit messages large enough to cause IPv6 343 fragmentation. However, in keeping with the recommendations of 344 [RFC2460], and in order to optimize performance, most OSPFv3 345 implementation refrain from doing so. Many implementations simply 346 restrict their maximum message size to some value that is safely 347 below 1280. 349 3.4. DCCP and NFS 351 Details TBD 353 3.5. Tunneling 355 TBD 357 4. Recommendation 359 This memo deprecates IPv6 fragmentation and the IPv6 fragment header. 360 Application and transport layer protocols SHOULD support effective 361 PLMTUD [RFC4821], since ICMP-based PMTUD [RFC1981] is unreliable. 362 Any application or transport layer protocol that cannot support 363 effective PMTUD MUST NOT in any circumstances send IPv6 packets that 364 exceed the IPv6 minimum MTU of 1280 bytes. 366 IPv6 stacks and forwarding nodes MUST continue to support inbound 367 fragmented IPv6 packets as specified in [RFC2460]. However, this 368 requirement exceeds the capability of some types of forwarding nodes 369 such as firewalls and load balancers. Therefore implementers and 370 operators need to be aware that on many paths through the Internet, 371 IPv6 fragmentation will fail. Legacy applications and transport 372 layer protocols that do not conform to the previous paragraph can 373 expect connectivity failures as a result. 375 5. IANA Considerations 377 IANA is requested to mark the Fragment Header for IPv6 (44) as 378 deprecated in the Protocol Numbers registry. 380 6. Security Considerations 382 Deprecation of the IPv6 Fragment Header will improve network security 383 by eliminating attacks that rely on fragmentation. 385 7. Acknowledgements 387 The author wishes to acknowledge Tore Anderson, Mark Andrews, Brian 388 Carpenter, Havard Eidnes, Bob Hinden, Geoff Huston, George 389 Michaelson, Simon Perreault, Arturo Servin, Mark Smith, Fred Templin, 390 Willem Toorop, Glen Turner and Ole Troan for their review and 391 constructive comments. 393 8. References 395 8.1. Normative References 397 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 398 August 1980. 400 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 401 1981. 403 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 404 793, September 1981. 406 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 407 for IP version 6", RFC 1981, August 1996. 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 413 (IPv6) Specification", RFC 2460, December 1998. 415 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 416 Message Protocol (ICMPv6) for the Internet Protocol 417 Version 6 (IPv6) Specification", RFC 4443, March 2006. 419 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 420 Discovery", RFC 4821, March 2007. 422 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 423 for Application Designers", BCP 145, RFC 5405, November 424 2008. 426 8.2. Informative References 428 [DeBoer] De Boer, M. and J. Bosma, "Discovering Path MTU black 429 holes on the Internet using RIPE Atlas", July 2012, . 433 [Hollis] Hollis, K., "The Rose Attack Explained", , . 436 [I-D.ietf-6man-nd-extension-headers] 437 Gont, F., "Security Implications of IPv6 Fragmentation 438 with IPv6 Neighbor Discovery", draft-ietf-6man-nd- 439 extension-headers-05 (work in progress), June 2013. 441 [I-D.ietf-6man-oversized-header-chain] 442 Gont, F. and V. Manral, "Security and Interoperability 443 Implications of Oversized IPv6 Header Chains", draft-ietf- 444 6man-oversized-header-chain-02 (work in progress), 445 November 2012. 447 [I-D.ietf-6man-predictable-fragment-id] 448 Gont, F., "Security Implications of Predictable Fragment 449 Identification Values", draft-ietf-6man-predictable- 450 fragment-id-00 (work in progress), March 2013. 452 [I-D.taylor-v6ops-fragdrop] 453 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 454 M., and T. Taylor, "Why Operators Filter Fragments and 455 What It Implies", draft-taylor-v6ops-fragdrop-01 (work in 456 progress), June 2013. 458 [Kent87] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", 459 In Proc. SIGCOMM '87 Workshop on Frontiers in Computer 460 Communications Technology , August 1987. 462 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 463 Considerations for IP Fragment Filtering", RFC 1858, 464 October 1995. 466 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 467 Beame, C., Eisler, M., and D. Noveck, "Network File System 468 (NFS) version 4 Protocol", RFC 3530, April 2003. 470 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 471 Rose, "Protocol Modifications for the DNS Security 472 Extensions", RFC 4035, March 2005. 474 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 475 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 477 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 478 for IPv6", RFC 5340, July 2008. 480 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 481 Algorithm", RFC 6145, April 2011. 483 Authors' Addresses 485 Ron Bonica 486 Juniper Networks 487 2251 Corporate Park Drive 488 Herndon, Virginia 20170 489 USA 491 Email: rbonica@juniper.net 493 Warren Kumari 494 Google, Inc. 495 1600 Amphitheatre Parkway 496 Mountainview, California 94043 497 USA 499 Email: warren@kumari.net 501 Randy Bush 502 Internet Initiative Japan 503 5147 Crystal Springs 504 Bainbridge Island Washington 505 USA 507 Email: randy@psg.com 509 Hagen Paul Pfeifer 510 ProtocolLabs 511 Munich 81379 512 Germany 514 Email: hagen.pfeifer@protocollabs.com 515 URI: http://www.protocollabs.com