<?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-mla-05" ipr="trust200902"
updates="rfc3879, rfc4007, rfc4291, rfc5889">
  <front>
    <title abbrev="IPv6 MLAs">IPv6 MANET Local Addresses (MLAs)</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="29" month="May" year="2024"/>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>Mobile Ad-hoc NETworks (MANETs) present an interesting challenge
      for IPv6 addressing due to the indeterminant neighborhood properties
      of MANET interfaces. MANET routers must assign an IPv6 address to each
      MANET interface that is both unique and routable within the MANET but
      must not be forwarded to other networks. MANET routers must be able to
      assign self-generated addresses to their MANET interfaces when there
      is no infrastructure present that can delegate topology-relative IPv6
      addresses or prefixes. This document therefore specifies a means for
      MANET routers to generate and assign MANET Local Addresses (MLAs).</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 addresses, discover multihop routes
      and exchange IPv6 packets with local network peers over their
      MANET interfaces even if there is no operator infrastructure
      present.</t>

      <t>MANETs consist of routers that configure interfaces to links
      with undetermined connectivity, in particular where the transitive
      property of connectivity for traditional shared links is not
      assured. MANET routers must nonetheless assign and use IPv6
      addresses that are unique within the MANET. This is true even
      for nodes that configure multiple interface connections to
      the same MANET as a multilink routing domain.</t>
        
      <t>Section 6 of the "IP Addressing Model in Ad Hoc Networks"
      <xref target="RFC5889"/> states that: "an IP address configured on
      this (MANET) interface should be unique, at least within the
      routing domain" and: "no on-link subnet prefix is configured
      on this (MANET) interface". The section then continues to explain
      why IPv6 Link-Local Addresses (LLAs) are of limited utility on
      links with undetermined connectivity, to the point that they
      cannot be used exclusively within multilink routing domains.</t>

      <t><xref target="RFC5889"/> suggests that global <xref target=
      "RFC4291"/> (aka "GUA") and unique-local <xref target="RFC4193"/>
      (aka "ULA") addresses are MANET addressing candidates. However,
      assignment of unique GUAs and ULAs must be coordinated either
      through administrative actions or through an automated address
      delegation service that all MANET routers can access. This
      document asserts that a new form of self-generated and
      unique MANET-local IPv6 addresses is needed.</t>

      <t>The key feature of these MANET-local 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 MANET-local IPv6 addresses could then be used for continuous
      MANET-local communications and/or to bootstrap the delegation of
      topologically-oriented addresses for assignment on other interfaces.
      This would also manifest a new "MANET-local" scope for the IPv6
      scoped addressing architecture <xref target="RFC4007"/> with scope
      greater than link-local but lesser than global/unique-local unicast.</t>

      <t>This document proposes a new unique local unicast address space
      known as MANET Local Addresses (MLAs). MLAs use the formerly-deprecated
      IPv6 site-local prefix fec0::10 according to the address generation
      procedures specified in this document.</t>
    </section>

    <section anchor="ipv6" title="IPv6 MANET Local Addresses (MLAs)">
      <t>The IPv6 addressing architecture specified in <xref target=
      "RFC4291"/>, <xref target="RFC4193"/> and <xref target="RFC4007"/>
      defines the supported IPv6 unicast/multicast/anycast address
      forms with various scopes including link-local, site-local
      and others. Unique-local and global unicast addresses are
      typically obtained 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 plus bits 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. Furthermore, <xref target="RFC9374"/>
      provides no guidance for assignment of a DET/HHIT to
      an interface nor any evidence that they could be used as
      the source/destination addresses of IPv6 packets.</t>

      <t>MANET interfaces have the interesting property that a MANET
      router R will often need to forward packets between MANET nodes
      A and B even though R uses the same interface in the inbound
      and outbound directions. Since nodes A and B may not be able to
      communicate directly even though both can communicate directly
      with R, the link connectivity property is intransitive and the
      IPv6 Neighbor Discovery (ND) Redirect service cannot be used.
      Conversely, R may need to forward packets between nodes A
      and B via different MANET interfaces within a single MANET
      that includes multiple distinct links/regions. Due to these
      indeterminant (multi-)link properties, exclusive use of IPv6
      Link Local Addresses (LLAs) is also out of scope.</t>

      <t>This document therefore introduces a new fully-self-generated
      IPv6 unicast address format known as the MANET Local Address
      (MLA) that can be used either instead of or in addition to
      other IPv6 unicast address types. MLAs use the formerly-deprecated
      Site-Local IPv6 Address prefix fec0::10 according to the modified
      format shown in <xref target="mla-fmt"/>:

      <figure anchor="mla-fmt"
              title="IPv6 MANET Local Address (MLA) Format">
          <artwork><![CDATA[   | 10 bits  |1|       53 bits         |         64 bits            |
   +----------+-+-----------------------+----------------------------+
   |1111111011|L|      subnet ID        |       interface ID         |
   +----------+-+-----------------------+----------------------------+
   ]]></artwork></figure></t>

      <t>In this format, the node sets the first 10 bits of the address
      to the constant string '1111111011' then sets the 11th bit (i.e.,
      the "(L)ocal" bit) to 1. The node next sets subnet ID to a 53 bit
      random value calculated the same as specified in Section 3.2.1 of
      <xref target="RFC4193"/> for the Unique Local Address Global ID.</t>

      <t>The node finally generates and assigns a semantically opaque
      interface ID based on this self-generated prefix as specified in
      <xref target="RFC7217"/>; the resulting 128-bit MLA then has the
      proper format of an IPv6 address with a 64-bit "prefix" followed
      by a 64-bit interface identifier as required by the IPv6 addressing
      architecture. For example:</t>

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

      <t>After a node creates an MLA, 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: the above MLA generation procedures apply when the
      L bit is set to 1; MLA generation procedures for L=0 may be
      specified by future documents.</t>
    </section>

    <section anchor="interface" title="Assigning IPv6 MLAs to an Interface">
      <t>IPv6 MLAs have no topological orientation and can therefore be
      assigned to any of a node's IPv6 interfaces. The node can then begin
      to use MLAs as the source/destination addresses of IPv6 packets that
      are forwarded over the interface within a local routing region. The
      node can assign the same MLA to multiple interfaces all members of
      the same MANET, but must assign a different MLA to its interface
      connections to different MANETs.</t>

      <t>MLAs may then 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, the node
      can assign an IPv6 MLA to an interface without invoking (pre-service)
      Duplicate Address Detection (DAD), however it should deprecate the
      MLA and assign a new IPv6 MLA if it detects a duplicate through
      (in-service) DAD.</t>
    </section>

    <section anchor="site-loc" title="Reclaiming fec0::/10">
      <t>Returning to a debate from more than 20 years ago, this
      document now proposes to reclaim the deprecated prefix
      "fec0::/10" for use as the MLA top-level prefix. <xref
      target="RFC3879"/> documents the reasons for deprecation
      including the assertion that "Site is an Ill-Defined Concept".
      However, the concept of a MANET is a logical one and not
      necessarily one constrained by physical boundaries.</t>

      <t>For example, a MANET router may connect to multiple
      distinct MANETs with a first set of interfaces connected
      to MANET "A", a second set of interfaces connected to
      MANET "B", etc. According to the scoped IPv6 addressing
      architecture, the router would assign a separate MLA for
      each interface set A, B, etc. and maintain separate MANET
      routing protocol instances for each set. MLAs A, B, etc.
      then become the router IDs for the separate routing protocol
      instances, but the MANET router may elect to redistribute
      discovered MLA routes between the instances. The uniqueness
      property of MLAs therefore transcends logical MANET boundaries
      but without "leaking" into external networks.</t> 

      <t>The prefix (formerly known as "Site-Local") has the distinct
      advantage that it is reserved and available for reclamation by
      a future standards track publication, for which this document
      qualifies. Upon publication as a standards track RFC, the RFC
      Editor is instructed to update <xref target="RFC3879"/>,
      <xref target="RFC4007"/> and <xref target="RFC4291"/> to
      reflect this new use for "fec0::/10".</t>
    </section>

    <section anchor="ula-gua" title="Obtaining and Assigning IPv6 GUAs/ULAs">
      <t>MANET routers assign MLAs to their MANET interfaces
      for use only within the scope of their locally connected
      MANETs. MLAs are carried in MANET routing protocol
      control messages and can also appear as the source and
      destination addresses for IPv6 packets forwarded within
      the locally connected MANETs. MLAs cannot appear in the
      source or destination addresses for IPv6 packets forwarded
      beyond the locally connected MANETs, however, where an IPv6
      Globally-Unique (GUA) and possibly also a companion
      Unique-Local (ULA) address is necessary.</t>

      <t>In order to support global-scope communications, each
      MANET router is required to obtain an IPv6 GUA through another
      MANET router that connects to the global IPv6 Internet while
      acting as a proxy. Since the proxy may be multiple MANET hops
      away, however, the MANET router configures and engages an
      Overlay Multilink Network (OMNI) Interface as specified in
      <xref target="I-D.templin-6man-omni3"/>. The MANET router
      assigns the GUA to the OMNI interface which then inserts an
      IPv6 encapsulation header that uses MLAs as the encapsulation
      source/destination addresses while the inner packet uses
      GUAs.</t>

      <t>In many instances, however, the proxy is configured as
      an IPv6-to-IPv6 Network Prefix Translation (NPTv6) gateway
      that connects the rest of the MANET to the outside Internet.
      In that case, the proxy supplies each MANET router with a
      ULA internally and maintains a 1:1 relationship between the
      ULA on the "inside" and a GUA on the "outside" as discussed
      in <xref target="I-D.bctb-6man-rfc6296-bis"/>. Each MANET
      router will then assign a ULA to the OMNI interface which
      then inserts an IPv6 encapsulation header that uses MLAs
      as the encapsulation source/destination addresses while
      the inner packet uses ULAs/GUAs. The NPTv6 gateway will
      then statelessly translate each ULA into its corresponding
      GUA (and vice versa) for packets that transit the proxy.</t>

      <t>The MANET proxy delegates Provider-Aggregated (PA)
      GUAs to each MANET router that requests a ULA/GUA pair.
      MANET routers that require Provider-Independent (PI)
      GUAs can then use the OMNI interface in conjunction with
      the Automatic Extended Route Optimization (AERO) global
      distributed mobility management service <xref target=
      "I-D.templin-6man-aero3"/> to request and maintain PI
      prefixes from the mobility service. The MANET router
      can then sub-delegate GUAs from PI prefixes to its
      attached downstream local networks which could engage
      an arbitrarily large IPv6 and/or IPv4 "Internet of
      Things".</t>
    </section>

   <section anchor="reqs" title="Requirements">
      <t>IPv6 nodes MAY assign self-generated IPv6 MLAs to their
      interface connections to local networks (or MANETs). If the
      node becomes aware that the address is already in use by
      another node, it instead generates and assigns a new MLA.</t>

      <t>IPv6 routers MAY forward IPv6 packets with MLA source or
      destination addresses over multiple hops within the same local
      network (or MANET).</t>

      <t>IPv6 routers MUST NOT forward packets with MLA source or
      destination addresses to a link outside the packet's local
      network (or MANET) of origin.</t>

      <t>IPv6 routers MUST NOT advertise the prefix fec0::/10 in
      routing protocol exchanges with correspondents outside the
      local network (or MANET).</t>

      <t>The default behavior of exterior routing protocol sessions
      between administrative routing regions must be to ignore receipt
      of and not advertise prefixes in the fee0::/11 block.</t>

      <t>At the present time, AAAA and PTR records for MLAs in the
      fee0::/11 block are not recommended to be installed in the
      global DNS.</t>
   </section>

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

    <section anchor="iana" title="IANA Considerations">
      <t><xref target="RFC3879"/> instructed IANA to mark the
      FEC0::/10 prefix as "deprecated", and as such it does not
      appear in the IANA IPv6 Special-Purpose Address Registry.</t>

      <t>Upon publication, IANA is instructed to add the prefix
      FEC0::/10 to the 'iana-ipv6-special-registry' registry
      with the name "MANET-Local Unicast" and with RFC set to
      "[RFCXXXX]" (i.e., this document).</t>
    </section>

    <section anchor="secure" title="Security Considerations">
      <t>IPv6 MLAs include very large uniquely-assigned bit strings
      in both the prefix and interface identifier components. With
      the random prefix generation procedures specified in <xref
      target="RFC4193"/> and the semantically opaque interface
      identifier generation procedures specified in <xref
      target="RFC7217"/> the only apparent opportunity for
      address duplication would be through either intentional or
      unintentional misconfiguration. A node that generates an
      MLA and assigns it to an interface should therefore be
      prepared to deprecate the MLA and generate/assign a new
      one if it detects a legitimate duplicate.</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 continue to shape updated versions of this document. The
      author acknowledges all those whose useful comments have helped
      further the understanding of this proposal.</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.7217"?>

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

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

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

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

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

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

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

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

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

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

      <?rfc include="reference.I-D.bctb-6man-rfc6296-bis"?>
    </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>
