[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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 RFC 2119 [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 [RFC2460]
   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.

   [RFC2460] 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 [RFC2460].

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
   [RFC2460], 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 [RFC2460].  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 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, 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", RFC 1981, August 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  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", RFC 4443, March 2006.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, March 2007.

   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
              for Application Designers", BCP 145, RFC 5405, 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", RFC 1858,
              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", RFC 3530, April 2003.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, 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", RFC 6145, April 2011.

Authors' Addresses

   Ron Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, Virginia  20170
   USA

   Email: rbonica@juniper.net


   Warren Kumari
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountainview, California  94043
   USA

   Email: warren@kumari.net


   Randy Bush
   Internet Initiative Japan
   5147 Crystal Springs
   Bainbridge Island  Washington
   USA

   Email: randy@psg.com


   Hagen Paul Pfeifer
   ProtocolLabs
   Munich  81379
   Germany

   Email: hagen.pfeifer@protocollabs.com
   URI:   http://www.protocollabs.com












Bonica, et al.          Expires January 12, 2014               [Page 11]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/