One document matched: draft-generic-v6ops-tunmtu-09.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<?rfc iprnotified='no'?>
<rfc category="info" docName="draft-generic-v6ops-tunmtu-09.txt"
     ipr="trust200902">
  <front>
    <title abbrev="Tunnel MTU Issues">Operational Issues with Tunnel Maximum
    Transmission Unit (MTU)</title>

    <author fullname="Fred L. Templin" initials="F. L." role="editor"
            surname="Templin">
      <organization>Boeing Research & Technology</organization>

      <address>
        <postal>
          <street>P.O. Box 3707</street>

          <city>Seattle</city>

          <region>WA</region>

          <code>98124</code>

          <country>USA</country>
        </postal>

        <email>fltemplin@acm.org</email>
      </address>
    </author>

    <date day="4" month="July" year="2012" />

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>The Maximum Transmission Unit (MTU) for popular IP-within-IP tunnels
      is currently recommended to be set to 1500 (or less) minus the length of
      the encapsulation headers when static MTU determination is used. This
      requires the tunnel ingress to either fragment any IP packet larger than
      the MTU or drop the packet and return an ICMP Packet Too Big (PTB)
      message. Concerns for operational issues with Path MTU Discovery (PMTUD)
      point to the possibility of MTU-related black holes when a packet is
      dropped due to an MTU restriction. The current "Internet cell size" is
      effectively 1500 bytes (i.e., the minimum MTU configured by the vast
      majority of links in the Internet) and should therefore also be the
      minimum MTU assigned to tunnels, but this has proven to be problematic
      in common operational practice. This document therefore discusses
      operational issues for IP-within-IP tunnel MTUs.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Maximum Transmission Unit (MTU) for popular IP-within-IP tunnels
      is currently recommended to be set to 1500 (or less) minus the length of
      the encapsulation headers when static MTU determination is used. This
      requires the tunnel ingress to either fragment any IP packet larger than
      the MTU or drop the packet and return an ICMP Packet Too Big (PTB)
      message <xref target="RFC0791"></xref><xref target="RFC2460"></xref>.
      Concerns for operational issues with Path MTU Discovery (PMTUD) <xref
      target="RFC1191"></xref><xref target="RFC1981"></xref> point to the
      possibility of MTU-related black holes when a packet is dropped due to
      an MTU restriction. The current "Internet cell size" is effectively 1500
      bytes (i.e., the minimum MTU configured by the vast majority of links in
      the Internet) and should therefore also be the minimum MTU assigned to
      tunnels, but this has proven to be problematic in common operational
      practice. This document therefore discusses operational issues for
      IP-within-IP tunnel MTUs.</t>
    </section>

    <section title="Tunnel MTU Issues">
      <t>Pushing the tunnel MTU to 1500 bytes or beyond is met with the
      challenge that the addition of encapsulation headers would cause an
      inner IP packet that is 1500 bytes (or slightly smaller) to appear as a
      slightly larger than 1500 byte outer IP packet on the wire, where it may
      be too large to traverse the path in one piece. When an IP tunnel
      configures an MTU smaller than 1500 bytes, packets that are small enough
      to traverse earlier links in the path toward the final destination may
      be dropped at the tunnel ingress which then returns a PTB message to the
      original source. However, operational experience has shown that the PTB
      messages can be lost in the network <xref target="RFC2923"></xref>, in
      which case the source does not receive notification of the loss.</t>

      <t>It is therefore highly desirable that the tunnel configure an MTU of
      at least 1500 bytes even though encapsulation would cause some tunneled
      packets to be slightly larger than 1500 bytes. In that case, the tunnel
      ingress would need to make special adaptations to deliver packets that
      are no larger than 1500 bytes yet larger than can be accommodated in a
      single piece.</t>

      <t>One possibility is to use IP fragmentation of the inner IP layer
      protocol before encapsulation so that inner packet fragments can be
      delivered via the tunnel without loss due to a size restriction and then
      reassembled at the final destination. This option removes the burden
      from the tunnel endpoints, but is only available for IPv4 packets (since
      IPv6 deprecates router fragmentation <xref target="RFC2460"></xref>),
      and is further only available when the IPv4 header sets the Don't
      Fragment (DF) bit in the IPv4 header to 0. For IPv6, the tunnel endpoint
      can invoke inner packet fragmentation only if it has a way of requesting
      the original host to perform the fragmentation itself.</t>

      <t>A second possibility is to use IP fragmentation of the outer IP layer
      protocol following encapsulation so that the outer packet fragments can
      be delivered via the tunnel without loss due to a size restriction and
      then reassembled at the tunnel egress. This option is available for
      tunnels over both IPv4 and IPv6, and indeed the tunnel ingress is
      permitted to use IPv6 fragmentation since it is acting as a "host"
      (i.e., and not a router) for the encapsulated packets it produces. While
      IPv6 fragmentation is assumed to be "safe at all speeds", IPv4
      fragmentation is dangerous at high data rates due to the possibility of
      Identification field wrapping while reassemblies are still active <xref
      target="RFC4963"></xref>. Also, if outer IP fragmentation were used the
      tunnel ingress has no assurance that the egress can reassemble packets
      larger than 1500 bytes, since the Minimum Reassembly Unit (MRU) is 1500
      bytes for IPv6 <xref target="RFC2460"></xref> and only 576 bytes for
      IPv4 <xref target="RFC1122"></xref>.</t>

      <t>A third possibility for accommodating inner packets that are slightly
      too large is the use of "tunnel fragmentation" based on a mid-layer
      encapsulation that is inserted between the inner and outer IP headers.
      Tunnel fragmentation requires separate packet Identification and
      segmentation control bits in the mid-layer encapsulation that are
      distinct from those that appear in the inner and/or outer headers. As
      for outer fragmentation, the tunnel egress is responsible for
      reassembly. Tunnel fragmentation can be particularly useful for tunnels
      over IPv4, since the mid-layer encapsulation can include an extended
      Identification field that avoids the identification wrapping issue
      discussed above. However, tunnel fragmentation is not used in common
      widely-deployed tunneling mechanisms at the time of this writing. An
      example of tunnel fragmentation appears in SEAL <xref
      target="I-D.templin-intarea-seal"></xref>.</t>

      <t>Following any inner, tunnel or outer fragmentation, the ingress must
      allow the encapsulated packets or fragments to be further fragmented by
      a router on the path that configures a link with a too-small MTU. These
      fragments would be reassembled by the tunnel egress the same as if the
      fragmentation occurred within the tunnel ingress. This final form of
      fragmentation is undesirable and should be avoided if at all possible
      through the application of fragmentation at the tunnel ingress. However,
      common widely-deployed tunneling mechanisms at the time of this writing
      make no such provisions.</t>
    </section>

    <section title="Jumbo Packet Accommodation">
      <t>In addition to failure to accommodate packets up to 1500 bytes in
      length, current tunneling solutions typically do not make provisions for
      delivering packets that are larger than 1500 bytes. As long as they are
      no larger than the underlying link used for tunneling, the tunnel
      ingress should admit such "jumbo" packets into the tunnel and allow them
      to either be delivered to the egress in one piece or be dropped with the
      possibility of a PTB message being returned. The original host will then
      be able to determine the correct packet sizes whether or not PTB
      messages are delivered if it is using <xref target="RFC4821"></xref>.
      However, this approach is not used in common widely-deployed tunneling
      mechanisms at the time of this writing.</t>
    </section>

    <section title="Common Tunneling Mechanisms">
      <t>The operational issues discussed in this document apply to existing
      IPv6-within-IPv4 transition mechanisms, including configured tunnels
      <xref target="RFC4213"></xref>, 6to4 <xref target="RFC3056"></xref>,
      Teredo <xref target="RFC4380"></xref>, ISATAP <xref
      target="RFC5214"></xref>, DSMIP <xref target="RFC5555"></xref>, 6rd
      <xref target="RFC5969"></xref>, etc.</t>

      <t>The issues further apply to existing IP-within-IP tunneling
      mechanisms of all varieties, including GRE <xref
      target="RFC1701"></xref>, IPv4-in-IPv4 <xref target="RFC2003"></xref>,
      IPv6-in-IPv6 <xref target="RFC2473"></xref>, IPv4-in-IPv6 <xref
      target="RFC6333"></xref>, IPsec <xref target="RFC4301"></xref>, etc.</t>
    </section>

    <section title="IANA Considerations">
      <t>There are no IANA considerations for this document.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>The security considerations for the various tunneling mechanisms
      apply also to this document.</t>
    </section>

    <section anchor="acknowledge" title="Acknowledgments">
      <t>This method was inspired through discussion on the IETF v6ops and
      NANOG mailing lists in the May/June 2012 timeframe.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.0791"?>

      <?rfc include="reference.RFC.2460"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.1981"?>

      <?rfc include="reference.RFC.1191"?>

      <?rfc include="reference.RFC.3056"?>

      <?rfc include="reference.RFC.5214"?>

      <?rfc include="reference.RFC.5555"?>

      <?rfc include="reference.RFC.5969"?>

      <?rfc include="reference.RFC.4380"?>

      <?rfc include="reference.RFC.2473"?>

      <?rfc include="reference.RFC.6333"?>

      <?rfc include="reference.RFC.4213"?>

      <?rfc include="reference.RFC.4301"?>

      <?rfc include="reference.RFC.4963"?>

      <?rfc include="reference.RFC.1701"?>

      <?rfc include="reference.RFC.2003"?>

      <?rfc include="reference.I-D.templin-intarea-seal"?>

      <?rfc include="reference.I-D.ietf-intarea-ipv4-id-update"?>

      <?rfc include="reference.RFC.4821"?>

      <?rfc include="reference.RFC.2923"?>

      <?rfc include="reference.RFC.1122"?>
    </references>
  </back>
</rfc>