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