One document matched: draft-templin-intarea-grefrag-00.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-templin-intarea-grefrag-00.txt"
     ipr="trust200902" updates="RFC2784, RFC2890">
  <front>
    <title abbrev="GRE Fragmentation">GRE Tunnel Fragmentation</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="8" month="April" year="2015"/>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet
      when the delivery packet exceeds the tunnel MTU, or when otherwise
      necessary. This can cause problems when unmitigated IPv4 fragemntation
      ensues, or when middleboxes drop IPv6 fragments unconditionally. This
      document proposes GRE tunnel fragmentation which avoids these
      pitfalls..</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>GRE is specified in <xref target="RFC2784"/> and <xref
      target="RFC2890"/>. In its current manifestation, GRE allows for
      fragmentation of the payload packet only if it is an IPv4 packet with
      the Don't Fragment (DF) bit set to 0. GRE also allows for fragmentation
      of the delivery packet, but this can cause problems in some
      applications. A third option (introduced here) is for the GRE tunnel to
      perform tunnel fragmentation and reassembly on the payload packet.</t>

      <t>In this way, the ingress can fragment the payload packet (while
      treating the payload packet's headers as ordinary data) and encapsulate
      each fragment in a separate delivery header. The GRE header requires a
      new fragment header field to support this.</t>

      <t>This tunnel fragmentation method was first suggested in Section 3.1.7
      of <xref target="RFC2764"/>, and also appears in more recent works <xref
      target="I-D.templin-aerolink"/> <xref
      target="I-D.herbert-gue-fragmentation"/>.</t>
    </section>

    <section anchor="minencaps" title="GRE Fragmentation Header">
      <t><xref target="grefrag"/> shows the GRE header as specified in <xref
      target="RFC2784"/><xref target="RFC2890"/> but with a new optional
      "Fragment Header" and two new control bits ("F" and "D"):</t>

      <figure anchor="grefrag" title="GRE Header with Fragment Header">
        <artwork><![CDATA[
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C| |K|S|F|D|  Reserved0  | Ver |         Protocol Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Checksum (optional)      |       Reserved1 (Optional)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key (optional)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Sequence Number (Optional)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Fragment Header (Optional)                    |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>

      <t>In this format, when the "F" bit is set to 1 the GRE header includes
      a Fragment header formatted as specified in Section 4.5 of <xref
      target="RFC2460"/>. When the "D" bit is set to 1, this serves as an
      indicating to any further GRE encapsulations in the path (i.e., either a
      nested encapsulation or a re-encapsulation) that the GRE packet must not
      be fragmented (further).</t>
    </section>

    <section anchor="whentoinsert" title="GRE Tunnel Fragmentation Procedures">
      <t>GRE tunnel fragmentation treats the entire GRE payload packet
      (including the payload headers) as opaque data. The GRE tunnel ingress
      breaks the payload packet into N fragments and encapsulates each
      fragment in a separate GRE header and GRE delivery header. The first
      fragment therefore includes the GRE payload headers and first portion of
      the GRE payload data, while subsequent fragments include the remaining
      portions of the GRE payload data. The GRE tunnel ingress then sends each
      fragment to the GRE tunnel egress. Apart from the appearance of the
      Fragment Header within the GRE header, the fragmentation procedure is
      the same as for IPv6 fragmentation.</t>

      <t>When the GRE tunnel egress receives the fragments, it reassembles the
      GRE payload packet by concatenating the data portions of each fragment
      according to their offsets. Apart from the appearance of the Fragment
      Header within the GRE header, the reassembly procedure is the same as
      for IPv6 reassembly.</t>

      <t>In order to support this fragmentation and reassembly procedure, the
      GRE tunnel ingress must know the maximum sized packet the GRE tunnel
      egress is capable of reassembling, i.e., the Maximum Reassembly Unit
      (MRU). The GRE tunnnel egress MUST therefore configure a minimum MRU of
      2KB, and MAY configure a larger MRU. </t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document introduces no IANA considerations.</t>
    </section>

    <section anchor="secure" title="Security Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

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

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

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

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

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

      <?rfc ?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.templin-aerolink"?>

      <?rfc include="reference.I-D.herbert-gue-fragmentation"?>
    </references>
  </back>
</rfc>