<?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="std" docName="draft-templin-6man-jumbofrag-01"
     ipr="trust200902" updates="RFC2675">
  <front>
    <title abbrev="IPv6 Packet Identification">IPv6 Packet
    Identification</title>

    <author fullname="Fred L. Templin" initials="F. L." role="editor"
            surname="Templin">
      <organization>Boeing Research &amp; 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="18" month="November" year="2021"/>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>Unlike Internet Protocol, version 4 (IPv4), Internet Protocol,
      version 6 (IPv6) does not include an Identification field in the basic
      packet header. Instead, IPv6 includes a 32-bit Identification field in a
      Fragment Header extension since the architecture assumed that the sole
      purpose for the Identification is to support the fragmentation and
      reassembly process. This document asserts that per-packet
      Identifications may be useful for other purposes, e.g., to allow
      recipients to detect spurious packets that may have been injected into
      the network by an attacker. But, rather than defining a new extension
      header, this document recommends employing the existing Fragment Header
      for per-packet identification even if the packet itself appears as an
      "atomic fragment".</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Unlike Internet Protocol, version 4 (IPv4) <xref target="RFC0791"/>,
      Internet Protocol, version 6 (IPv6) <xref target="RFC8200"/> does not
      include an Identification field in the basic packet header. Instead,
      IPv6 includes a 32-bit Identification field in a Fragment Header
      extension since the architecture assumed that the sole purpose for an
      Identification is to support the fragmentation and reassembly process.
      This document asserts that per-packet Identifications may be useful for
      other purposes, e.g., to allow recipients to detect spurious packets
      that may have been injected into the network by an attacker. But, rather
      than defining a new extension header, this document recommends employing
      the existing Fragment Header for per-packet identification even if the
      packet itself appears as an "atomic fragment".</t>

      <t>Atomic fragments are defined as "IPv6 packets that contain a Fragment
      Header with the Fragment Offset set to 0 and the M flag set to 0" <xref
      target="RFC6946"/>. When an IPv6 source includes a Fragment Header
      (i.e., either in an atomic fragment or in multiple fragments), only the
      source itself and not an intermediate IPv6 node on the path is permitted
      to alter its contents. This is mandated in the base IPv6 specification
      which states "unlike IPv4, fragmentation in IPv6 is performed only by
      source nodes, not by routers along a packet's delivery path".</t>

      <t>IPv6 sources that include a Fragment Header include an unpredictable
      Identification value with each packet <xref target="RFC7739"/>. If the
      IPv6 source and destination maintain a "window" of acceptable
      Identification values, this may allow the destination to discern packets
      originated by the true IPv6 source from spurious packets injected into
      the network by an attacker.</t>

      <t>This document therefore asserts that IPv6 sources are permitted to
      include a Fragment Header in their packet transmissions (i.e., whether
      as atomic fragments or in multiple fragments) as long as they include
      suitable unpredictable Identification values. This includes IPv6
      "jumbograms" (i.e., packets larger than 65,535 octets <xref
      target="RFC2675"/>) which can only be prepared as atomic fragments since
      they are not eligible for fragmentation. Since the current jumbogram
      specification forbids sources from including a Fragment Header of any
      kind, this document updates <xref target="RFC2675"/>.</t>
    </section>

    <section anchor="aero-omni" title="IPv6 Packet Identification">
      <t>When IPv6 sources and destinations have some way of maintaining
      "windows" of acceptable Identification values, the destination may be
      able to examine received packet Identifications to determine whether
      they likely originated from the source. The AERO <xref
      target="I-D.templin-6man-aero"/> and OMNI <xref
      target="I-D.templin-6man-omni"/> specifications discuss methods for
      maintaining windows of unpredictable values that may reduce attack
      profiles in some environments.</t>
    </section>

    <section anchor="issues" title="RFC2675 Updates">
      <t>The following updates to <xref target="RFC2675"/> are requested:<list
          style="symbols">
          <t>Section 3, third paragraph, change: "The Jumbo Payload option
          must not be used in a packet that carries a Fragment header" to:
          "The Jumbo Payload option must not be used in a packet that carries
          a non-atomic Fragment header <xref target="RFC6946"/>".</t>

          <t>Section 3, in the list of errors, change: "error: Jumbo Payload
          option present and Fragment header present" to: "error: Jumbo
          Payload option present and non-atomic Fragment header present".</t>

          <t>Add [RFC6946] to Informative References.</t>
        </list></t>
    </section>

    <section anchor="implement" title="Implementation Status">
      <t>TBD.</t>
    </section>

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

    <section anchor="secure" title="Security Considerations">
      <t>Communications networking security is necessary to preserve
      confidentiality, integrity and availability.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>This work was inspired by ongoing AERO/OMNI/DTN investigations.</t>

      <t>.</t>
    </section>
  </middle>

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

      <?rfc ?>

      <?rfc ?>

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

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

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

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

      <?rfc include="reference.I-D.templin-6man-omni"?>

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

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

      <?rfc ?>

      <?rfc ?>
    </references>
  </back>
</rfc>
