<?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-08" ipr="trust200902"
updates="rfc3879, rfc4007, rfc4291, rfc5889, rfc6724">
  <front>
    <title abbrev="IPv6 MLAs">IPv6 MANET Local Addressing</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="5" month="June" 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 coordinate topology-relative
      IPv6 addresses or prefixes. This document therefore specifies a
      means for MANET routers to generate and assign address types
      useful for MANET local communications.</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 include 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,
      provisioning 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 new forms of self-generated and
      unique MANET local IPv6 addresses are 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
      local communications and/or to coordinate 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. The document further discusses
      the utility of the Hierarchical Host Identity Tag (HHIT) specified
      in <xref target="RFC9374"/> for MANET local addressing purposes.</t>
    </section>

    <section anchor="ipv6" title="IPv6 MANET Local Addressing">
      <t>The IPv6 addressing architecture specified in <xref target=
      "RFC4007"/>, <xref target="RFC4193"/> and <xref target="RFC4291"/>
      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 Hierarchical Host
      Identity Tag (HHIT) (aka DRIP Entity Tag (DET)) <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. Hence, a fully self-generated MLA may be
      necessary in environments where an HHIT cannot be used.</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 can both 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 the MLA as a new fully
      self-generated IPv6 unicast address type 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>The node sets the first 10 bits of the MLA 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 MANET Local Addresses to an Interface">
      <t>IPv6 MLAs and HHITS have no topological orientation and can
      therefore be assigned to any of a node's MANET interfaces with a
      /128 prefix length (i.e., as a singleton address). The node can
      then begin to use MLAs or HHITs 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 or HHIT to multiple
      interfaces all members of the same MANET, but must assign a different
      MLA or HHIT to the interfaces of each interface set connected to
      different MANETs.</t>

      <t>MLAs and HHITs 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 or HHIT to an interface without invoking
      (pre-service) Duplicate Address Detection (DAD), however it should
      deprecate an address 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 based on
      (multihop) connectivity 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
      properties of MLAs and HHITs therefore transcends logical
      MANET boundaries but without "leaking" into external networks.</t> 

      <t>The MLA 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"/>, <xref target="RFC4291"/> and
      <xref target="RFC5889"/> 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 and/or HHITs to their MANET
      interfaces for use only within the scope of their locally
      connected MANETs. The MLAs and HHITs 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 and
      HHITs 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 a
      border router/proxy that connects the MANET to the global
      IPv6 Internet. 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 forwards original
      packets by inserting an IPv6 encapsulation header that uses
      MLAs or HHITs as the source/destination addresses while the
      original packet uses GUAs.</t>

      <t>The proxy may be 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 the ULA to its OMNI interface which encapsulates each
      original packet in an IPv6 header that uses MLAs or HHITs as
      the encapsulation source/destination addresses while the
      original 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 proxy delegates a ULA and its companion
      Provider-Aggregated (PA) GUA for each MANET router which
      assigns them  according to either the "ULA+PA" or "ULA-Only"
      connected network models <xref target=
      "I-D.ietf-v6ops-ula-usage-considerations"/>.
      If the MANET router employs the "ULA+PA" model, it can assign
      both the ULA and GUA to the OMNI interface. The MANET router
      can then use the ULA for local-scoped communications with peers
      inside the MANET and the GUA for global-scoped communications
      with external peers via the proxy as a "NPTv6 pass-through".
      MANET routers can then select address pair combinations
      according to IPv6 default address selection rules <xref
      target="I-D.ietf-6man-rfc6724-update"/>.</t>

      <t>After receiving a ULA plus PA GUA delegation, MANET routers
      that require Provider-Independent (PI) GUAs can 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 IPv6 and/or IPv4 PI prefixes from the mobility
      service. The MANET router can then sub-delegate GUAs from
      the PI prefixes to its attached downstream local networks
      which may in turn engage an arbitrarily large IPv6 and/or
      IPv4 "Internet of Things".</t>
    </section>

   <section anchor="addrsel" title="Address Selection">
      <t>"Default Address Selection for Internet Protocol Version 6
      (IPv6)" <xref target="RFC6724"/> provides a policy table that
      specifies precedence values and preferred source prefixes for
      destination prefixes. "Preference for IPv6 ULAs over IPv4
      addresses in RFC6724" <xref target="I-D.ietf-6man-rfc6724-update"/>
      updates the policy table entries for ULAs, IPv4 addresses and
      the 6to4 prefix (2002::/16).</t>

      <t>This document proposes a further update to the policy table
      for IPv6 MLAs (prefix fec0::/10) and HHITs (prefix 2001:30::/28).
      The proposed updates appear in the table below:

      <figure anchor="rfc6724update"
              title="Policy Table Update for MANET Local Addresses">
          <artwork><![CDATA[
 draft-ietf-6man-rfc6724-update                           Updated
Prefix        Precedence Label        Prefix        Precedence Label
::1/128               50     0        ::1/128               50     0
::/0                  40     1        ::/0                  40     1
::ffff:0:0/96         20     4        ::ffff:0:0/96         20     4
2002::/16              5     2        2002::/16              5     2
2001::/32              5     5        2001::/32              5     5
fc00::/7              30    13        fc00::/7              30    13
::/96                  1     3        ::/96                  1     3
fec0::/10              1    11        fec0::/10              3    11 (*)
3ffe::/16              1    12        3ffe::/16              1    12
                                      2001:30::/28           4    14 (*)
(*) value(s) changed in update
]]></artwork></figure>
      With the proposed updates, IPv6 HHITs now appear as a lesser
      precedence than IPv6 GUAs, IPv6 ULAs and IPv4 addresses but as
      a greater precedence than IPv6 MLAs. IPv6 MLAs now appear as a
      greater precedence than deprecated IPv6 prefixes but a lesser
      precedence than all other address types.</t>
   </section>

   <section anchor="reqs" title="Requirements">
      <t>IPv6 nodes MAY assign self-generated IPv6 MLAs and/or
      HHITs 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/HHIT.</t>

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

      <t>IPv6 routers MUST NOT forward packets with MLA/HHIT 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 (or
      any IPv6 prefixes reserved for HHITs) 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"?>

      <?rfc include="reference.RFC.6724"?>
    </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"?>

      <?rfc include="reference.I-D.ietf-6man-rfc6724-update"?>

      <?rfc include="reference.I-D.ietf-v6ops-ula-usage-considerations"?>
    </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>
