<?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-6man-ula-uuid-01" ipr="trust200902" updates="">
  <front>
    <title abbrev="IPv6 ULA-UUID Address">IP6 ULAs with UUID Interface Identifiers (ULA-UUID)</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="16" month="May" year="2024"/>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>Internet Protocol, version 6 (IPv6) defines a Unique Local
      IPv6 Unicast Address (ULA) format based on the IANA-assigned
      prefix fc00::/7. The structure for sub-prefix fd00::/8 is well
      defined, but the remaining sub-prefix fc00::/8 is reserved for
      future use. This document proposes a use for sub-prefix
      fc00::/8 in conjunction with the Universally Unique Interface
      IDentifier (UUID).</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>When two or more IPv6 <xref target="RFC8200"/> nodes come
      together within a common local operating region (e.g., during
      the formation of a Mobile Ad-hoc Network (MANET)), they must
      be able to assign unique local-use addresses and exchange IPv6
      packets even if there is no operator infrastructure present.</t>

      <t>The key feature of these local-use IPv6 addresses is that they
      must be assured unique so that there is no chance of conflicting
      with an address assigned by another node. There is no requirement
      that the addresses have topologically-oriented prefixes, since the
      (newly-formed) local network may not (yet) connect to any other
      Internetworking topologies.</t>

      <t>The local-use IPv6 addresses could then be used for continuous
      local communications and/or to bootstrap the assignment of
      topologically-oriented addresses under the IPv6 multi-addressing
      architecture <xref target="RFC4291"/>.</t>

      <t>IPv6 defines a Unique Local IPv6 Unicast address (ULA)
      format <xref target="RFC4193"/> based on the IANA-assigned
      prefix fc00::/7. The sub-prefix fd00::/8 is well defined,
      but the remaining sub-prefix fc00::/8 is reserved for future
      use. This document proposes a use for sub-prefix fc00::/8 in
      conjunction with the Universally Unique Interface IDentifier
      (UUID) <xref target="RFC9562"/>.</t>
    </section>

    <section anchor="ipv6" title="The IPv6 ULA-UUID Address">
      <t>The IPv6 addressing architecture specified in <xref target=
      "RFC4291"/> and <xref target="RFC4193"/> defines the supported
      IPv6 address forms for unicast, multicast and anycast. Unicast
      addresses are typically assigned through Stateless Address
      AutoConfiguration (SLAAC) <xref target="RFC4862"/> and/or
      the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
      <xref target="RFC8415"/>, but these services require the
      presence of IPv6 network infrastructure which may not be
      immediately available in spontaneously-formed MANETs or
      other isolated local networks.</t>

      <t>A new IPv6 address type known as the DRIP Entity Tag
      (DET) (or, Hierarchical Host Identity Tag (HHIT)) <xref
      target="RFC9374"/> provides a well-structured address
      format with exceptional uniqueness properties. A portion
      of the address includes the node's self-generated Overlay
      Routable Cryptographic Hash IDentifier (ORCHID) while
      the remainder of the address includes a well-formed IPv6
      prefix corresponding to an attestation service that
      supports address proof-of-ownership. Verification of
      the attestation aspect of the address requires access
      to network infrastructure, but this may not always be
      available.</t>

      <t>This document therefore proposes a new fully-self-generated
      IPv6 unicast address format that can be used either instead of
      or in addition to a DET/HHIT and/or other IPv6 unicast address
      types (noting again that a single interface may have multiple
      IPv6 addresses <xref target="RFC4291"/>). The address uses the
      8-bit ULA prefix fc00::/8 along with a 120-bit interface identifier
      that includes the 120 least-significant bits of a Universally
      Unique IDentifier (UUID). With reference to Figure 8 of <xref
      target= "RFC9562"/> which depicts the UUIDv4 format, this
      "IPv6 ULA-UUID address" format is shown in <xref target=
      "ula-uuid"/>:

      <figure anchor="ula-uuid"
              title="IPv6 ULA-UUID Address Format">
          <artwork><![CDATA[    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|1|1|1|1|1|0|0|                   random_a                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          random_a             |  ver  |       random_b        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |var|                       random_c                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           random_c                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ]]></artwork></figure></t>

      <t>To form an IPv6 ULA-UUID, the node creates a 128-bit UUIDv4
      per <xref target="RFC9562"/> then simply replaces the most
      significant 8 bits with the constant string '11111100' (0xfc);
      the resulting 128-bit ULA-UUID then has the format of an IPv6
      address with an 8-bit subnet prefix and 120-bit interface identifier
      as permitted by the IPv6 addressing architecture. For example:</t>

      <t><list style="empty">
        <t>fc84:6c29:de12:4b74:884e:9d2a:73fc:2d94::/8</t>
      </list></t>

      <t>After a node creates a ULA-UUID, it can use the address
      within the context of spontaneously-organized local networks
      in which two or more nodes come together in the absence of
      supporting infrastructure and can still exchange IPv6 packets
      with little or no chance of address collisions. The use could
      be limited to bootstrapping the assignment of topologically
      correct IPv6 addresses through other means mentioned earlier,
      or it could extend to longer term usage patterns such as
      sustained communications with single-hop neighbors on a
      local link or even between multi-hop peers within a MANET.</t>
      
      <t>Note: while the ULA-UUID format specified above is
      relative to UUIDv4, the same format can be applied also
      to all other UUID versions specified in <xref target=
      "RFC9562"/>, i.e. by replacing the most significant 8
      bits of the UUID with the constant string '11111100' (0xfc).</t>
    </section>

    <section anchor="interface" title="Assigning IPv6 ULA-UUIDs to an Interface">
      <t>IPv6 ULA-UUID addresses based on the prefix "fc00::/8" have
      no topological orientation and can therefore be assigned to any
      of a node's IPv6 interfaces. The addresses may serve as a basis
      for multihop forwarding over a MANET interface and/or for local
      neighborhood discovery over other IPv6 interface types. Due to
      their uniqueness properties, IPv6 ULA-UUID addresses can be
      assigned to interfaces without invoking Duplicate Address
      Detection (DAD).</t>
    </section>

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

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

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

    <section anchor="ack" title="Acknowledgements">
      <t>This work was inspired by continued investigations into
      5G MANET operations in cooperation with the Virginia Tech
      National Security Institute (VTNSI).</t>

      <t>Emerging discussions on the IPv6 maintenance (6man) mailing
      list are expected to shape future versions of this document.
      The author acknowledges all those whose useful comments have
      helped further the understanding of this proposal.</t>

      <t>Kyzer Davis (RFC9562 author) is acknowledged for his review
      and comments that helped shape the document.</t>

      <t>Honoring life, liberty and the pursuit of happiness.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

    <section title="Change Log">
      <t>&lt;&lt; RFC Editor - remove prior to publication &gt;&gt;</t>

      <t>Differences from earlier versions:<list style="symbols">
          <t>First draft publication.</t>
        </list></t>
    </section>
  </back>
</rfc>
