One document matched: draft-foo-v6ops-6rdmtu-02.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-foo-v6ops-6rdmtu-02.txt" ipr="trust200902">
  <front>
    <title abbrev="SEAL">6rd Tunnel 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="30" month="January" year="2014"/>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>The tunnel MTU on 6rd Provider Edge (PE) and Consumer Edge (CE)
      routers is currently recommended to be set to 1480. This is to avoid
      IPv4 fragmentation within the tunnel, but requires the tunnel ingress to
      drop any IPv6 packet larger than 1480 bytes and return an ICMPv6 Packet
      Too Big (PTB) message. Concerns for operational issues with both IPv4
      and IPv6 Path MTU Discovery point to the possibility of MTU-related
      black holes when a packet is dropped due to an MTU restriction somewhere
      in the Internet. Fortunately, the "Internet cell size" is 1500 bytes
      (i.e., the minimum MTU configured by the vast majority of links in the
      Internet) so if the 6rd PE router can set a tunnel MTU of at least 1500
      bytes the MTU issues are alleviated. This document specifies methods
      that can be employed to support these larger sizes.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The tunnel MTU on 6rd Provider Edge (PE) and Consumer Edge (CE)
      routers is currently recommended to be set to 1500 bytes minus the IPv4
      header encapsulation overhead minus the encapsulation overhead for any
      additional encapsulations that may occur on the path <xref
      target="RFC5969"/>. This is to avoid IPv4 fragmentation within the
      tunnel <xref target="RFC0791"/>, but requires the tunnel ingress to drop
      any IPv6 packet larger than the tunnel MTU and return an ICMPv6 Packet
      Too Big (PTB) message <xref target="RFC2460"/>. Concerns for operational
      issues with both IPv4 and IPv6 Path MTU Discovery <xref
      target="RFC1191"/><xref target="RFC1981"/> point to the possibility of
      MTU-related black holes when a packet is dropped due to an MTU
      restriction somewhere in the Internet. Fortunately, the "Internet cell
      size" is 1500 bytes (i.e., the minimum MTU configured by the vast
      majority of links in the Internet) so if the 6rd PE router can set a
      tunnel MTU of at least 1500 bytes the MTU issues are alleviated. This
      document specifies methods that can be employed to support these larger
      sizes.</t>

      <t>Pushing the 6rd tunnel MTU to 1500 bytes or larger is met with the
      challenge that the addition of the IPv4 encapsulation header would cause
      a 1500 byte IPv6 packet to appear as a 1520 byte IPv4 packet on the
      wire. This can result in the packet being either fragmented or dropped
      by an IPv4 router that configures a smaller link MTU, depending on the
      setting of the "Don't Fragment" (DF) bit in the IPv4 header. Therefore,
      this document recommends complementary mechanisms to ensure that packets
      of various sizes can be delivered as long as the underlying IPv4 network
      can support the larger sizes. The following two sections present the
      methods used by 6rd PE and CE routers.</t>
    </section>

    <section title="6rd Provider Edge (PE) Router MTU Mitigations">
      <t>The 6rd PE Router employs the following MTU-handling mitigations:</t>

      <t><figure>
          <artwork><![CDATA[
   1. Set the 6rd tunnel interface MTU to the maximum of 1500 and
      the MTU of the underlying IPv4 interface minus the expected
      encapsulation overhead for the IPv4 header as well as any
      other encapsulations that may occur on the path.
   2. For each 6rd CE, maintain a RATE-LIMIT boolean variable set
      to TRUE.
   3. When the PE sends an IPv6 packet no larger than 1500 bytes
      minus encapsulation overhead to a CE, encapsulate and set the
      DF bit to 1.
   4. When the PE sends an IPv6 packet larger than 1500 bytes to a
      CE, encapsulate and set the DF bit to 1. Optionally cache any
      IPv4 MTU values returned in ICMPv4 packet too big messages
      that may result.
   5. When the PE sends an IPv6 packet larger than 1500 bytes minus
      the encapsulation overhead but no larger than 1500 bytes,
      encapsulate and set the DF bit to 0. Send the packet to the CE
      subject to rate limiting if RATE-LIMIT is TRUE. The packet may
      be fragmented in the IPv4 network on the path to the CE.
   6. Send a 1500 byte IPv6 probe packet to each active CE subject
      to rate limiting using the neighbor reachability test procedure
      specified in Section 8 of RFC5969. If the probe succeeds, set
      RATE-LIMIT for the CE to FALSE.
]]></artwork>
        </figure></t>
    </section>

    <section title="6rd Provider Edge (CE) Router MTU Mitigations">
      <t>The 6rd CE Router employs the following MTU-handling techhniques:</t>

      <t><figure>
          <artwork><![CDATA[
   1. Set the 6rd tunnel interface MTU to the maximum of 1280 and the
      the MTU of the underlying IPv4 interface minus the expected
      encapsulation overhead for the IPv4 header as well as any other
      encapsulations that may occur on the path.
   2. If the underlying interface has a sufficiently-large MTU, send
      a 1500 byte IPv6 probe packet to the PE using the neighbor
      reachability test procedure specified in Section 8 of RFC5969.
      If the probe succeeds, set the IPv4 MTU for the PE to the MTU
      of the underlying IPv4 interface; else, set the IPv4 MTU to
      1520 minus the expected encapsulation overhead.
   3. For each TCP session initiated by an IPv6 host within the CE's
      LAN, rewrite the Maximum Segment Size (MSS) to 1500 minus the
      TCP header length minus the IPv6 header length minus the
      encapsulation overhead for (see: [RFC0879][RFC6691]). As a
      result, the local IPv6 host and its remote IPv6 correspondent
      will begin their TCP messages exchanges using IPv6 packets no
      larger than the minimum tunnel path MTU.
   4. When the CE sends an IPv6 packet to the PE, if the encapsulated
      packet is larger than the IPv4 MTU for the PE drop and return
      an ICMPv6 Packet Too Big. Else, set the DF bit to 1 and send
      the packet.
   5. For each neighboring CE, maintain a RATE-LIMIT boolean variable
      set to TRUE.
   6. When the CE sends an IPv6 packet no larger than 1500 bytes minus
      the encapsulation overhead to a neighboring CE, encapsulate and
      set the DF bit to 1.
   7. When the CE sends an IPv6 packet larger than 1500 bytes to a
      neighboring CE, encapsulate and set the DF bit to 1. Optionally
      cache any IPv4 MTU values returned in ICMPv4 packet too big
      messages that may result.
   8. When the CE sends an IPv6 packet larger than 1500 bytes minus
      the encapsulation overhead but no larger than 1500 bytes to a
      neighboring CE, encapsulate and set the DF bit to 0. Send the
      packet to the neighboring CE subject to rate limiting if
      RATE-LIMIT is TRUE.
   9. Send a 1500 byte IPv6 probe packet to each active neighboring
      CE subject to rate limiting using the neighbor reachability
      test procedure specified in Section 8 of RFC5969. If the probe
      succeeds, set RATE-LIMIT for the CE to FALSE.
]]></artwork>
        </figure></t>
    </section>

    <section title="Discussion">
      <t>There are several interrelated aspects to the recommended MTU
      mitigations. First, the unconditional rewriting of the MSS by CE routers
      ensures that the initial packets sent by IPv6 correspondents will be no
      larger than the minimum tunnel path MTU following encapsulation. The
      IPv6 correspondents can thereafter use [RFC4821] to attempt to increase
      the MSS during the course of the TCP session and thereby take advantage
      of larger packet sizes when avaialble.</t>

      <t>However, not all transport protocols observe the TCP MSS and so the
      packets of other protocols generated by IPv6 hosts may be larger than
      would fit in the minimum tunnel path MTU. Since most IPv6 hosts expect
      to see a minimum MTU of 1500 bytes without any ancillary MTU assurance
      mitigations, the approach specified here takes special care of packets
      larger than the minimum tunnel path MTU but no larger than 1500 bytes.
      Namely, these packets are allowed to undergo IPv4 fragmentation on the
      path from the PE to a CE or on the path from a CE to another CE. Since
      sustained fragmentation at high data rates is dangerous however <xref
      target="RFC4963"/> packets in this size range must only be admitted into
      the tunnel subject to rate limiting so that reassembly misassociations
      do not occur. Meanwhile, packets larger than 1500 bytes are admitted
      into the tunnel unconditionally on a "best effort" basis with the
      understanding that these packets may be dropped silently.</t>

      <t>Using these methods, CE routers may need to perform a small amount of
      IPv4 reassembly. PE routers on the other hand will never be asked to
      perform reassembly.</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 6rd apply also to this document.</t>
    </section>

    <section anchor="acknowledge" title="Acknowledgments">
      <t>This method was inspired through many years of discussion on IETF
      lists and other forums on the topic of tunnel MTU.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc ?>

      <?rfc ?>

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

      <?rfc ?>

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

      <?rfc ?>

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

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

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

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

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

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