Skip to main content

IPv6 Source Fragmentation for Link Adaptation Avoidance
draft-generic-6man-tunfrag-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Fred Templin
Last updated 2012-07-03
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-generic-6man-tunfrag-01
Network Working Group                                    F. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Intended status: Informational                             July 03, 2012
Expires: January 4, 2013

        IPv6 Source Fragmentation for Link Adaptation Avoidance
                   draft-generic-6man-tunfrag-01.txt

Abstract

   IPv6 intentionally deprecates fragmentation by routers in the
   network.  Instead, links with restricting MTUs must either drop each
   too-large packet and return an ICMP Packet Too Big message or perform
   link-specific fragmentation (also known as "link adaptation") at a
   layer below IPv6.  This latter category of links is often
   performance-challenged to accommodate steady-state link-specific
   fragmentation to the point that it would be highly desirable to push
   the fragmentation burden back to the IPv6 source.  A common case that
   exhibits these link characteristics is seen for IPv6-within-IP
   tunnels.  This document therefore proposes an update to the base IPv6
   specification to support link adaptation avoidance.

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 4, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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

Templin                  Expires January 4, 2013                [Page 1]
Internet-Draft          Link Adaptation Avoidance              July 2012

   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  IPv6 Protocol Specification Updates . . . . . . . . . . . . . . 3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5

Templin                  Expires January 4, 2013                [Page 2]
Internet-Draft          Link Adaptation Avoidance              July 2012

1.  Introduction

   IPv6 intentionally deprecates fragmentation by routers in the
   network.  Instead, links with restricting MTUs must either drop each
   too-large packet and return an ICMP Packet Too Big message or perform
   link-specific fragmentation (also known as "link adaptation") at a
   layer below IPv6.  This latter category of links is often
   performance-challenged to accommodate steady-state link-specific
   fragmentation to the point that it would be highly desirable to push
   the fragmentation burden back to the IPv6 source.  A common case that
   exhibits these link characteristics is seen for IPv6-within-IP
   tunnels [I-D.generic-v6ops-tunmtu].  This document therefore proposes
   an update to the base IPv6 specification to support link adaptation
   avoidance.

2.  Problem Statement

   The current "Internet cell size" is effectively 1500 bytes, i.e., the
   minimum MTU configured by the vast majority of links in the Internet.
   However, due to issues with Path MTU Discovery (PMTUD) this size can
   only be accommodated when links with smaller link-layer segment sizes
   are permitted to perform link adaptation.  A common example of such
   links is seen for IPv6-within-IP tunnels.  For those links, the
   tunnel ingress can perform fragmentation on the outer packet
   following encapsulation and can instead (or in addition) perform
   "tunnel fragmentation" via an encapsulation mid-layer inserted
   between the inner and outer header.  In both cases reassembly would
   be performed by the tunnel egress.

   Unfortunately, link-layer fragmentation can present a significant
   burden to the link endpoints, i.e., especially when the link supports
   high data rates and/or is located nearer the "middle" of the network
   instead of nearer the "edge".  The third alternative therefore is to
   ask the original IPv6 source to perform fragmentation on the packet
   before sending it out, in which case reassembly would be performed by
   the final destination.  This document therefore updates the IPv6
   protocol specification [RFC2460] to allow links that perform link
   adaptation to send advisory messages to the original source as
   described in the next section.

3.  IPv6 Protocol Specification Updates

   Section 5 of [RFC2460] states:

   "IPv6 requires that every link in the internet have an MTU of 1280
   octets or greater.  On any link that cannot convey a 1280-octet

Templin                  Expires January 4, 2013                [Page 3]
Internet-Draft          Link Adaptation Avoidance              July 2012

   packet in one piece, link-specific fragmentation and reassembly must
   be provided at a layer below IPv6."

   This document does not propose to change this requirement, but notes
   that link-specific fragmentation can be burdensome for some links
   (e.g., IPv6-within-IP tunnels), to the point that it would be highly
   desirable for the fragmentation to be pushed back to the original
   source.  In order to accommodate this, when the router at the link
   ingress performs link adaptation on a packet it should also send an
   advisory ICMPv6 Packet Too Big (PTB) message back to the original
   source (subject to rate limiting).  This document therefore proposes
   to add the following specification as a new final paragraph to the
   end of Section 5:

   "In response to an IPv6 packet that is sent to an IPv6 destination
   located beyond a link that must perform link-specific fragmentation,
   the originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
   should perform IPv6 fragmentation on any subsequent packets that are
   larger than this MTU value but no larger than the minimum of the
   source's link MTU and 1500 bytes.  Note that these Packet Too Big
   messages are advisory in nature and do not necessarily indicate
   packet loss.  Note also that the node is permitted to continue to
   send packets larger than 1500 bytes without fragmentation, but should
   implement [RFC4821] to ensure that the packets are reaching the final
   destination."

   An example tunnel protocol that invokes this new clause appears in:
   [I-D.templin-intarea-seal].

4.  IANA Considerations

   There are no IANA considerations for this document.

5.  Security Considerations

   The security considerations for [RFC2460] apply also to this
   document.

6.  Acknowledgments

   This method was inspired through discussion on the IETF v6ops and
   NANOG mailing lists in the May/June 2012 timeframe.

Templin                  Expires January 4, 2013                [Page 4]
Internet-Draft          Link Adaptation Avoidance              July 2012

7.  References

7.1.  Normative References

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

7.2.  Informative References

   [I-D.generic-v6ops-tunmtu]
              Templin, F., "Operational Issues with Tunnel Maximum
              Transmission Unit (MTU)", draft-generic-v6ops-tunmtu-08
              (work in progress), June 2012.

   [I-D.templin-intarea-seal]
              Templin, F., "The Subnetwork Encapsulation and Adaptation
              Layer (SEAL)", draft-templin-intarea-seal-42 (work in
              progress), December 2011.

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

Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org

Templin                  Expires January 4, 2013                [Page 5]