<?xml version="1.0"?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc toc="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-andrews-6man-fragopt-00.txt">
  <front>
    <title abbrev="hop by hop frag opts">IPv6 Stateless Fragmentation Identification Options</title>
    <author initials="M." surname="Andrews" fullname="M. Andrews">
      <organization abbrev="ISC">Internet Systems Consortium</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <region>CA</region>
          <code>94063</code>
          <country>US</country>
        </postal>
        <email>marka@isc.org</email>
      </address>
    </author>
    <date month="Aug" year="2013"/>
    <abstract>
      <t>
	Fragmented IPv6 packets are often dropped because there is no
	way to identify whether a fragment matches a otherwise permitted
	packet as the L4 header information is not available on all the
	fragments.
      </t>
      <t>
	The document defines hop-by-hop options that can be used to
	supply the missing information in non initial fragments.
      </t>
    </abstract>
  </front>
  <middle>
    <section toc="yes" anchor="intro" title="Introduction">
      <t>
	Fragmented IPv6 packets are often dropped because there is no
	way to identify whether a fragment matches a otherwise permitted
	packet as the L4 header information is not available on all the
	fragments.
      </t>
      <t>
	The document defines hop-by-hop options that can be used to
	supply the missing information in non initial fragments.
      </t>
      <t>
 	The informtion required differs depending upon the L4 packet.
	For TCP and UDP the source and destination ports are needed.
	For ICMP the type of ICMP packet is needed.
      </t>
      <t>
	These options are expected to be used by middle boxes (firewalls
	and loadbalancers) and end nodes.
      </t>
    </section>
    <section toc="yes" anchor="tcpandudp" title="TCP and UDP Fragements">
      <t>
	For TCP and UDP a skippable hop-by-hop option <xref
	target="RFC2460" /> (for backwards compatibilty) containing
	the source and destination ports from the TCP and UDP headers
	is needed. To permit the use of NATs, however undesired,
	the option contents are marked changable enroute.  The option code
	has nmemonic PORTS and value (TBD) and is added to all
	fragments of UDP and TCP packets when they are fragmented.
	By adding the option to all fragments you reduce the amount
	of fragmentation reassembly failures that would result if
	you only added the option to non-initial fragments and were
	dropping non-initial fragments without this option.
      </t>
      <figure>
        <artwork>
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|1|  (TBD)  |      4        |           source port         |
   +---------------+---------------+---------------+---------------+
   |       destination port        |
   +-------------------------------+
        </artwork>
      </figure>
    </section>
    <section toc="yes" anchor="security" title="Security Considerations">
      <t>
	The use of these options will expose nodes to more fragmention
	based attacks and potentually more traffic which will ultimately
	be dropped if a attacker can guess which option values will be
	permitted.
      </t>
      <t>
	With the exception of the fragmentation based attacks, permitting
	fragments with these options is no worse that permitting multiple
	unfragmented packets based in the same parameters.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <reference anchor="RFC2460">
        <front>
          <title>Internet Protocol, Version 6 (IPv6) Specification</title>
          <author initials="S." surname="Deering" fullname="S. Deering">
            <organization />
          </author>
          <author initials="R." surname="Hinden" fullname="R. Hinden">
            <organization />
          </author>
          <date month="December" year="1998" />
        </front>
        <seriesInfo name="RFC" value="2460" />
      </reference>
    </references>
  </back>
</rfc>
