idnits 2.17.1 draft-bonica-6man-frag-deprecate-01.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 (June 21, 2013) is 3962 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: 'RFC4443' is defined on line 268, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-predictable-fragment-id' is defined on line 300, 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 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 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: December 23, 2013 R. Bush 7 Internet Initiative Japan 8 June 21, 2013 10 IPv6 Fragment Header Deprecated 11 draft-bonica-6man-frag-deprecate-01 13 Abstract 15 This memo deprecates the IPv6 Fragment Header. It provides reasons 16 for deprecation and updates RFC 2460. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 23, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Case For Deprecation . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Resource Conservation . . . . . . . . . . . . . . . . . . 3 61 2.2. Fragmentation Is Rare . . . . . . . . . . . . . . . . . . 3 62 2.2.1. UDP-based Applications That Rely on Fragmentation . . 4 63 2.3. Attack Vectors . . . . . . . . . . . . . . . . . . . . . 4 64 2.4. Operator Behavior . . . . . . . . . . . . . . . . . . . . 5 65 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 7.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 Each link on the Internet is characterized by a Maximum Transmission 77 Unit (MTU). A link's MTU represents the maximum packet size that can 78 be conveyed over the link, without fragmentation. MTU is a 79 unidirectional metric. A bidirectional link may be characterized by 80 one MTU in the forward direction and another MTU in the reverse 81 direction. IPv6 [RFC2460] requires that every link in the Internet 82 have an MTU of 1280 octets or greater. On any link that cannot 83 convey a 1280-octet packet in one piece, link-specific fragmentation 84 and reassembly must be provided at a layer below IPv6. Therefore, 85 the PMTU between any two IPv6 nodes is 1280 bytes or greater. 87 Likewise, for any given source node, the path to a particular 88 destination node is characterized by a path MTU (PMTU). At a given 89 source, the PMTU associated with a destination is equal to the 90 minimum MTU of all of the links that contribute to the path between 91 the source and the destination. 93 [RFC2460] strongly recommends that IPv6 nodes implement Path MTU 94 Discovery (PMTUD) [RFC1981], in order to discover and take advantage 95 of PMTUs greater than 1280 octets. However, a minimal IPv6 96 implementation (e.g., in a boot ROM) may simply restrict itself to 97 sending packets no larger than 1280 octets, and omit implementation 98 of PMTUD. 100 In order to send a packet larger than a path's MTU, a node may use 101 the IPv6 Fragment header to fragment the packet at the source and 102 have it reassembled at the destination(s). However, the use of such 103 fragmentation is discouraged in any application that is able to 104 adjust its packets to fit the measured path MTU (i.e., down to 1280 105 octets). 107 In IPv6, a packet can be fragmented only by the host that originates 108 it. This constitutes a departure from the IPv4 [RFC0791] 109 fragmentation strategy, in which a packet can be fragmented by its 110 originator or by any router that it traverses en route to its 111 destination. 113 This memo deprecates the IPv6 Fragment Header. It provides reasons 114 for deprecation and updates [RFC2460]. 116 2. Case For Deprecation 118 This section presents a case for deprecating the IPv6 Fragment 119 Header. 121 2.1. Resource Conservation 123 Packets that are fragmented at their source need to be reassembled at 124 their destination. [Kent87] points out that the reassembly process 125 is resource intensive. It consumes significant compute and memory 126 resources. While the cited reference refers to IPv4 fragmentation 127 and reassembly, many of its criticisms are equally applicable to 128 IPv6. 130 By comparison, if a source node were to execute PMTUD procedures, and 131 if applications were to avoid sending datagrams that would result in 132 IP packets that exceed the PMTU, the task of reassembly could be 133 avoided, altogether. 135 2.2. Fragmentation Is Rare 137 Today, most popular operating systems implement PMTUD or an extension 138 thereof, called Packetization Layer MTU Discovery (PMTUD) [RFC4821]. 139 Most popular TCP [RFC0793] implementations leverage this technology 140 and restrict their segment size so that IP fragmentation is not 141 required. As a result, IPv6 fragments carrying TCP payload are 142 rarely observed on the Internet. 144 Likewise, many UDP-based [RFC0768] applications follow the 145 recommendations of [RFC5405]. According to [RFC5405], "an 146 application SHOULD NOT send UDP datagrams that result in IP packets 147 that exceed the MTU of the path to the destination. Consequently, an 148 application SHOULD either use the path MTU information provided by 149 the IP layer or implement path MTU discovery itself to determine 150 whether the path to a destination will support its desired message 151 size without fragmentation. Applications that do not follow this 152 recommendation to do PMTU discovery SHOULD still avoid sending UDP 153 datagrams that would result in IP packets that exceed the path MTU. 154 Because the actual path MTU is unknown, such applications SHOULD fall 155 back to sending messages that are shorter than the default effective 156 MTU for sending." The effective MTU for IPv6 is 1280 bytes. 158 Because many UDP-based applications follow the above-quoted 159 recommendation, IPv6 fragments carrying UDP traffic are also rarely 160 observed on the Internet. 162 2.2.1. UDP-based Applications That Rely on Fragmentation 164 The following is a list of UDP-based applications that do not follow 165 the recommendation of [RFC5405] and rely in IPv6 fragmentation: 167 o DNSSEC [RFC4035]. (However, it is useful to note the DNS queries 168 and responses can run over TCP.) 170 The effectiveness of these protocols may currently be degraded by 171 operator behavior. SeeSection 2.4 for details. 173 2.3. Attack Vectors 175 Security researchers have found and continue to find attack vectors 176 that rely on IP fragmentation. For example, 177 [I-D.ietf-6man-oversized-header-chain] and 178 [I-D.ietf-6man-nd-extension-headers] describe variants of the tiny 179 fragment attack [RFC1858]. In this attack, a packet is crafted so 180 that it can evade stateless firewall filters. The stateless firewall 181 filter matches on fields drawn from the IPv6 header and an upper 182 layer header. However, the packet is fragmented so that the upper 183 layer header, or a significant part of that header, does not appear 184 in the first fragment. Because a stateless firewall cannot parse 185 payload beyond the first fragment, the packet evades detection by the 186 firewall. 188 Security researcher have also studied reassembly algorithms on 189 popular computing platforms, with the following goals: 191 o to discover fragility in seldom exercised parts of the IP stack 192 o to engineer flows that maximize resources consumed by the 193 reassembly process 195 The Dawn and Rose Attacks [Hollis] are the products of such research. 197 All of the attack vectors mentioned above can be mitigated with 198 firewalls and increasingly sophisticated reassembly algorithms. 199 However, the continued investment required to mitigate newly 200 discovered vulnerabilities detracts from the cost effectiveness of 201 IPv6 as a networking solution. 203 2.4. Operator Behavior 205 For reasons described above, and also articulated in 206 [I-D.taylor-v6ops-fragdrop], many network operators filter all IPv6 207 fragments. Also, the default behavior of many currently deployed 208 firewalls is to discard IPv6 fragments. 210 In one recent study [DeBoer], two researchers distributed probes to 211 423 IPv6 enabled sites. The researchers then tested connectivity 212 between an experimental control center and the probes. They found 213 that during any given trial period, sixty percent of the sites that 214 could be reached with unfragmented packets could also be reached with 215 fragmented packets. The remaining forty percent appeared to be 216 filtering IPv6 fragments 218 3. Recommendation 220 This memo deprecates IPv6 fragmentation and the IPv6 fragment header. 221 New application and transport layer protocols MUST NOT send datagrams 222 that result in IPv6 packets exceeding the MTU of the path to the 223 destination. However, legacy applications and transport layer 224 protocols will continue to do so. 226 New IPv6 host implementations MAY support IPv6 fragmentation and 227 reassembly, but are not required to do so. 229 Network operators MAY filter IPv6 fragments. 231 4. IANA Considerations 233 IANA is requested to mark the Fragment Header for IPv6 (44) as 234 deprecated in the Protocol Numbers registry. 236 5. Security Considerations 238 Deprecation of the IPv6 Fragment Header will improve network security 239 by eliminating attacks that rely on fragmentation. 241 6. Acknowledgements 243 The author wishes to acknowledge Bob Hinden and Ole Troan for their 244 review and constructive comments. 246 7. References 248 7.1. Normative References 250 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 251 August 1980. 253 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 254 1981. 256 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 257 793, September 1981. 259 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 260 for IP version 6", RFC 1981, August 1996. 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 266 (IPv6) Specification", RFC 2460, December 1998. 268 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 269 Message Protocol (ICMPv6) for the Internet Protocol 270 Version 6 (IPv6) Specification", RFC 4443, March 2006. 272 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 273 Discovery", RFC 4821, March 2007. 275 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 276 for Application Designers", BCP 145, RFC 5405, November 277 2008. 279 7.2. Informative References 281 [DeBoer] De Boer, M. and J. Bosma, "Discovering Path MTU black 282 holes on the Internet using RIPE Atlas", July 2012, . 286 [Hollis] Hollis, K., "The Rose Attack Explained", , . 289 [I-D.ietf-6man-nd-extension-headers] 290 Gont, F., "Security Implications of IPv6 Fragmentation 291 with IPv6 Neighbor Discovery", draft-ietf-6man-nd- 292 extension-headers-05 (work in progress), June 2013. 294 [I-D.ietf-6man-oversized-header-chain] 295 Gont, F. and V. Manral, "Security and Interoperability 296 Implications of Oversized IPv6 Header Chains", draft-ietf- 297 6man-oversized-header-chain-02 (work in progress), 298 November 2012. 300 [I-D.ietf-6man-predictable-fragment-id] 301 Gont, F., "Security Implications of Predictable Fragment 302 Identification Values", draft-ietf-6man-predictable- 303 fragment-id-00 (work in progress), March 2013. 305 [I-D.taylor-v6ops-fragdrop] 306 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 307 M., and T. Taylor, "Why Operators Filter Fragments and 308 What It Implies", draft-taylor-v6ops-fragdrop-01 (work in 309 progress), June 2013. 311 [Kent87] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", 312 In Proc. SIGCOMM '87 Workshop on Frontiers in Computer 313 Communications Technology , August 1987. 315 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 316 Considerations for IP Fragment Filtering", RFC 1858, 317 October 1995. 319 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 320 Rose, "Protocol Modifications for the DNS Security 321 Extensions", RFC 4035, March 2005. 323 Authors' Addresses 325 Ron Bonica 326 Juniper Networks 327 2251 Corporate Park Drive 328 Herndon, Virginia 20170 329 USA 331 Email: rbonica@juniper.net 332 Warren Kumari 333 Google, Inc. 334 1600 Amphitheatre Parkway 335 Mountainview, California 94043 336 USA 338 Email: warren@kumari.net 340 Randy Bush 341 Internet Initiative Japan 342 5147 Crystal Springs 343 Bainbridge Island Washington 344 USA 346 Email: randy@psg.com