IPv6 Fragment Header Deprecated
Author(s): Randy Bush, Warren Kumari, Ron Bonica, Hagen Pfeifer
This memo deprecates IPv6 fragmentation and the IPv6 fragment header. It provides reasons for deprecation and updates RFC 2460....
6man Working Group R. Bonica Internet-Draft Juniper Networks Updates: RFC 2460 (if approved) W. Kumari Intended status: Standards Track Google, Inc. Expires: January 12, 2014 R. Bush Internet Initiative Japan H. Pfeifer ProtocolLabs July 11, 2013 IPv6 Fragment Header Deprecated draft-bonica-6man-frag-deprecate-02 Abstract This memo deprecates IPv6 fragmentation and the IPv6 fragment header. It provides reasons for deprecation and updates RFC 2460. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 12, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Bonica, et al. Expires January 12, 2014 [Page 1] Internet-Draft IPv6 Fragment Deprecated July 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Case For Deprecation . . . . . . . . . . . . . . . . . . . . 3 2.1. Resource Conservation . . . . . . . . . . . . . . . . . . 3 2.2. Application Reliance on IPv6 Fragmentation . . . . . . . 3 2.3. Attack Vectors . . . . . . . . . . . . . . . . . . . . . 5 2.4. Operator Behavior . . . . . . . . . . . . . . . . . . . . 6 3. Applications That Rely on Fragmentation . . . . . . . . . . . 6 3.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. SIIT . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. DCCP and NFS . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Each link on the Internet is characterized by a Maximum Transmission Unit (MTU). A link's MTU represents the maximum packet size that can be conveyed over the link, without fragmentation. IPv6 [RFC 2460] requires that every link in the Internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. For any given source node, the path to a particular destination is characterized by a path MTU (PMTU). At a given source, the PMTU associated with a destination is equal to the minimum MTU of all of the links in the path between the source and the destination. Because every IPv6-enabled link must support an MTU or 1280 bytes or Bonica, et al. Expires January 12, 2014 [Page 2] Internet-Draft IPv6 Fragment Deprecated July 2013 greater, the PMTU between any two IPv6 nodes is also 1280 bytes or greater. [RFC 2460] strongly recommends that IPv6 nodes implement Path MTU Discovery (PMTUD) [RFC1981], in order to discover and take advantage of PMTU values greater than 1280 octets. However, a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of PMTUD. In order to send a packet larger than a path's MTU, a node may use the IPv6 Fragment header to fragment the packet at the source and have it reassembled at the destination(s). However, the use of such fragmentation is discouraged in any application that is able to adjust its packets to fit the measured path MTU (i.e., down to 1280 octets). In IPv6, a packet can be fragmented only by the host that originates it. This constitutes a departure from the IPv4 [RFC0791] fragmentation strategy, in which a packet can be fragmented by its originator or by any router that it traverses en route to its destination. This memo deprecates IPv6 fragmentation and the IPv6 fragment header. It provides reasons for deprecation and updates [RFC 2460]. 2. Case For Deprecation This section presents a case for deprecating the IPv6 Fragment Header. 2.1. Resource Conservation Packets that are fragmented at their source need to be reassembled at their destination. [Kent87] points out that the reassembly process is resource intensive. It consumes significant compute and memory resources. While the cited reference refers to IPv4 fragmentation and reassembly, many of its criticisms are equally applicable to IPv6. By comparison, if a source node were to execute PMTUD procedures, and if applications were to avoid sending datagrams that would result in IP packets that exceed the PMTU, the task of reassembly could be avoided, altogether. 2.2. Application Reliance on IPv6 Fragmentation Today, a limited number of applications rely upon IPv6 fragmentation. Bonica, et al. Expires January 12, 2014 [Page 3] Internet-Draft IPv6 Fragment Deprecated July 2013 Most popular TCP implementations include PMTUD or an extension thereof, called Packetization Layer MTU Discovery (PMTUD) [RFC4821]. Therefore, in the nominal case, applications obtaining transport services from these TCP implementations never cause IPv6 fragments to be sent. However, some TCP implementations that include PMTUD do emit segments long enough to cause IPv6 fragmentation. This happens in the following circumstance: o The TCP implementation establishes two (or more) sessions to the same destination o Because the TCP implementation has not yet emitted any long segments, the underlying IPv6 implementation estimates the PMTU for destination to be equal to the MTU of the first link in the path to the destination. This estimate is incorrect, and will be revised, below. o The first TCP session submits a long segment to the underlying IPv6 implementation o The underlying IPv6 implementation determines that if it were to encapsulate this segment in an IPv6 header, the resulting packet would not exceed its current estimate of the PMTU for the destination. So, the underlying IPv6 implementation emits a non- fragmented IPv6 packet. This packet exceeds the actual PMTU for the destination o A downstream router discards the long packet and returns an ICMPv6 Packet Too Big (PTB) message. o The first TCP session reduces its Maximum Segment Size (MSS) to an appropriate value o The underlying IPv6 implementation reduces its estimate of the PMTU for the destination to an appropriate value o The second TCP session submits a long segment to the underlying IPv6 implementation. It does so without first querying the underlying IPv6 implementation to learn its estimate of the PMTU for the destination o The underlying IPv6 implementation determines that if it were to encapsulate this segment in an IPv6 header, the resulting packet would exceed its current estimate of the PMTU for the destination. So, the underlying IPv6 implementation emits multiple IPv6 fragments. Bonica, et al. Expires January 12, 2014 [Page 4] Internet-Draft IPv6 Fragment Deprecated July 2013 The authors suggest that the behavior described above may be sub- optimal, and that TCP implementations should leverage PMTU information that the underlying IPv6 implementation could provide. Many UDP-based [RFC0768] applications follow the recommendations of [RFC5405]. According to [RFC5405], "an application SHOULD NOT send UDP datagrams that result in IP packets that exceed the MTU of the path to the destination. Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement path MTU discovery itself to determine whether the path to a destination will support its desired message size without fragmentation. Applications that do not follow this recommendation to do PMTU discovery SHOULD still avoid sending UDP datagrams that would result in IP packets that exceed the path MTU. Because the actual path MTU is unknown, such applications SHOULD fall back to sending messages that are shorter than the default effective MTU for sending." The effective MTU for IPv6 is 1280 bytes. However, several applications are known to rely on IPv6 fragmentation. Some of these are mentioned in Section 3. 2.3. Attack Vectors Security researchers have found and continue to find attack vectors that rely on IP fragmentation. For example, [I-D.ietf-6man-oversized-header-chain] and [I-D.ietf-6man-nd-extension-headers] describe variants of the tiny fragment attack [RFC1858]. In this attack, a packet is crafted so that it can evade stateless firewall filters. The stateless firewall filter matches on fields drawn from the IPv6 header and an upper layer header. However, the packet is fragmented so that the upper layer header, or a significant part of that header, does not appear in the first fragment. Because a stateless firewall cannot parse payload beyond the first fragment, the packet evades detection by the firewall. Security researcher have also studied reassembly algorithms on popular computing platforms, with the following goals: o to discover fragility in seldom exercised parts of the IP stack o to engineer flows that maximize resources consumed by the reassembly process The Dawn and Rose Attacks [Hollis] are the products of such research. All of the attack vectors mentioned above can be mitigated with firewalls and increasingly sophisticated reassembly algorithms. Bonica, et al. Expires January 12, 2014 [Page 5] Internet-Draft IPv6 Fragment Deprecated July 2013 However, the continued investment required to mitigate newly discovered vulnerabilities detracts from the cost effectiveness of IPv6 as a networking solution. 2.4. Operator Behavior For reasons described above, and also articulated in [I-D.taylor-v6ops-fragdrop], many network operators filter all IPv6 fragments. Also, the default behavior of many currently deployed firewalls is to discard IPv6 fragments. In one recent study [DeBoer], two researchers utilized a measurement network to measure fragment filtering. They sent packets, fragmented to the minimum MTU of 1280, to 502 IPv6 enabled and reachable probes. They found that during any given trial period, ten percent of the probes did not receive fragmented packets. 3. Applications That Rely on Fragmentation The following is a list of applications that are currently known to rely on IPv6 fragmentation: o DNSSEC [RFC4035]. o SIIT [RFC6145] o OSPFv3 [RFC5340] o NFSv4 [RFC3530] o DCCP [RFC4340] Some tunneling configurations also rely upon IPv6 fragmentation. See Section 3.5 for details. Each of these applications relies on fragmentation to a varying degree. In some cases, that reliance is essential, and cannot be broken without fundamentally changing the protocol. In other cases, that reliance is incidental, and most protocol implementations already take appropriate steps to avoid fragmentation. Each of these applications will continue to emit IPv6 fragments, even after the IPv6 fragmentation header is deprecated. In order to achieve backwards compatibility, new IPv6 implementations will continue to support reassembly of incoming fragments. See for Section 4 details. Bonica, et al. Expires January 12, 2014 [Page 6] Internet-Draft IPv6 Fragment Deprecated July 2013 3.1. DNSSEC DNSSEC can obtain transport services from either UDP or TCP. Superior performance and scaling characteristics are observed when DNSSEC runs over UDP. When running over UDP, DNSSEC is likely to cause the generation of IPv6 fragments. By comparison, when running over TCP, DNSSEC is much less likely to cause the generation of IPv6 fragments. When running over UDP, DNSSEC's reliance upon IPv6 fragmentation is fundamental. That reliance cannot be broken without changing the DNSSEC specification. DNSSEC is an essential part of the Internet architecture. Therefore, this issue is for further study and must be resolved before IPv6 fragmentation can be deprecated. 3.2. SIIT [RFC6145] requires the following: o "When the IPv4 sender does not set the DF bit, the translator SHOULD always include an IPv6 Fragment Header to indicate that the sender allows fragmentation. The translator MAY provide a configuration function that allows the translator not to include the Fragment Header for the non-fragmented IPv6 packets". o "If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than 1280 bytes, the packet SHOULD be fragmented so the resulting IPv6 packet (with Fragment Header added to each fragment) will be less than or equal to 1280 bytes." These behaviors cannot be changed, and for these reasons, SIIT devices will continue to emit IPv6 fragments, even after IPv6 fragmentation has been deprecated. SIIT also emits ICMPv6 PTB messages with MTU less than 1280. In that case, the originating IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that SIIT can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. This problem could be avoided if SIIT executed an alternative procedure. For example, rather than discarding the packet and Bonica, et al. Expires January 12, 2014 [Page 7] Internet-Draft IPv6 Fragment Deprecated July 2013 sending an ICMPv6 PTB message with MTU less than 1280, SIIT could generate a random number for use as the Identification value and forward the packet. This issue clearly requires further study. 3.3. OSPFv3 OSPFv3 implementations may emit messages large enough to cause IPv6 fragmentation. However, in keeping with the recommendations of [RFC 2460], and in order to optimize performance, most OSPFv3 implementation refrain from doing so. Many implementations simply restrict their maximum message size to some value that is safely below 1280. 3.4. DCCP and NFS Details TBD 3.5. Tunneling TBD 4. Recommendation This memo deprecates IPv6 fragmentation and the IPv6 fragment header. Application and transport layer protocols SHOULD support effective PLMTUD [RFC4821], since ICMP-based PMTUD [RFC1981] is unreliable. Any application or transport layer protocol that cannot support effective PMTUD MUST NOT in any circumstances send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes. IPv6 stacks and forwarding nodes MUST continue to support inbound fragmented IPv6 packets as specified in [RFC 2460]. However, this requirement exceeds the capability of some types of forwarding nodes such as firewalls and load balancers. Therefore implementers and operators need to be aware that on many paths through the Internet, IPv6 fragmentation will fail. Legacy applications and transport layer protocols that do not conform to the previous paragraph can expect connectivity failures as a result. 5. IANA Considerations IANA is requested to mark the Fragment Header for IPv6 (44) as deprecated in the Protocol Numbers registry. 6. Security Considerations Deprecation of the IPv6 Fragment Header will improve network security by eliminating attacks that rely on fragmentation. Bonica, et al. Expires January 12, 2014 [Page 8] Internet-Draft IPv6 Fragment Deprecated July 2013 7. Acknowledgements The author wishes to acknowledge Tore Anderson, Mark Andrews, Brian Carpenter, Havard Eidnes, Bob Hinden, Geoff Huston, George Michaelson, Simon Perreault, Arturo Servin, Mark Smith, Fred Templin, Willem Toorop, Glen Turner and Ole Troan for their review and constructive comments. 8. References 8.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 0768, August 1980. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 0791, September 1981. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC1981, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC4443, March 2006. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC4821, March 2007. [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC5405, November 2008. 8.2. Informative References [DeBoer] De Boer, M. and J. Bosma, "Discovering Path MTU black holes on the Internet using RIPE Atlas", July 2012, <http: //www.nlnetlabs.nl/downloads/publications/pmtu-black- holes-msc-thesis.pdf>. Bonica, et al. Expires January 12, 2014 [Page 9] Internet-Draft IPv6 Fragment Deprecated July 2013 [Hollis] Hollis, K., "The Rose Attack Explained", , <http:// digital.net/~gandalf/Rose_Frag_Attack_Explained.htm>. [I-D.ietf-6man-nd-extension-headers] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", draft-ietf-6man-nd- extension-headers-05 (work in progress), June 2013. [I-D.ietf-6man-oversized-header-chain] Gont, F. and V. Manral, "Security and Interoperability Implications of Oversized IPv6 Header Chains", draft-ietf- 6man-oversized-header-chain-02 (work in progress), November 2012. [I-D.ietf-6man-predictable-fragment-id] Gont, F., "Security Implications of Predictable Fragment Identification Values", draft-ietf-6man-predictable- fragment-id-00 (work in progress), March 2013. [I-D.taylor-v6ops-fragdrop] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, M., and T. Taylor, "Why Operators Filter Fragments and What It Implies", draft-taylor-v6ops-fragdrop-01 (work in progress), June 2013. [Kent87] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology , August 1987. [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC1858, October 1995. [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC3530, April 2003. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC4035, March 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC4340, March 2006. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC5340, July 2008. Bonica, et al. Expires January 12, 2014 [Page 10] Internet-Draft IPv6 Fragment Deprecated July 2013 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC6145, April 2011. Authors' Addresses Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia 20170 USA Email: firstname.lastname@example.org Warren Kumari Google, Inc. 1600 Amphitheatre Parkway Mountainview, California 94043 USA Email: email@example.com Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island Washington USA Email: firstname.lastname@example.org Hagen Paul Pfeifer ProtocolLabs Munich 81379 Germany Email: email@example.com URI: http://www.protocollabs.com Bonica, et al. Expires January 12, 2014 [Page 11]