<?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-ietf-manet-inet-gap-analysis-04"
ipr="trust200902" updates="">
  <front>
    <title abbrev="MANET Internetworking">MANET Internetworking: Problem Statement and Gap Analysis</title>

    <author fullname="Fred L. Templin" initials="F. L." role="editor"
            surname="Templin">
      <organization>The Boeing Company</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>

    <author fullname="Daniel J. Jakubisin" initials="D. J."
            surname="Jakubisin">
      <organization>National Security Institute, Virginia Tech</organization>

      <address>
        <postal>
          <street>2202 Kraft Dr.</street>

          <city>Blacksburg</city>

          <region>VA</region>

          <code>24060</code>

          <country>USA</country>
        </postal>

        <email>djj@vt.edu</email>
      </address>
    </author>

    <date day="30" month="July" year="2026"/>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t><xref target="RFC2501"/> defines a MANET as "an autonomous system
      of mobile nodes. The system may operate in isolation, or may have
      gateways to and interface with a fixed network" (such as the global
      public Internet). This document presents a MANET Internetworking
      problem statement and gap analysis.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Mobile Ad-hoc Networks (MANETs) <xref target="RFC2501"/> often
      include mobile nodes with limited range wireless transmission media
      interfaces that establish links via a dynamically changing set of
      neighbors within operational range. Each mobile node engages a MANET
      routing protocol to discover links to first hop neighbors as well
      as multihop paths to reach other nodes beyond. MANET routers represent
      multihop paths as "host routes" established through either proactive
      or on-demand discovery. These host routes name singleton destinations
      based on either L2 addressing and forwarding in the case of L2-MANET
      or IP addressing and forwarding <xref target="RFC0791"/>
      <xref target="RFC8200"/> in the case of L3-MANET.</t>

      <t>Individual MANETs typically include modest numbers of mobile
      nodes (e.g., O(10**1), O(10**2), etc.) which naturally limits the
      number of host routes needed in the local routing system. MANETs
      can merge to form larger MANETs and/or partition into smaller
      MANETs according to dynamic network conditions such as mobility.
      MANETs may also have internal clusters with IP addressed cluster
      heads that limit the extent over which host routes propagate to
      reduce control message overhead. Finally, MANETs often operate
      autonomously until they encounter Internetwork access points
      of opportunity.</t>

      <t>A MANET should be regarded as a mobile network that is either
      disconnected from the global Internetwork or only intermittently
      connected to the global Internetwork with the ability to move rapidly
      between different Internetwork attachment points. Due to the dynamic
      multilink nature of MANETs, MANET routers must configure a unique
      Multilink Local Address (MLA) and often also use prefix delegation
      to obtain a unique Mobile Network Prefix (MNP) to connect nodes
      on their downstream-attached interfaces.</t>

      <t>Data communications between two nodes within the same MANET local
      routing region follow host routes using MANET-internal links. When a
      MANET border router establishes an Internetwork link, it can provide
      "Internet connection-sharing" access to the rest of the MANET as a
      connected "stub" network. Per <xref target="RFC2501"/>, "stub networks
      carry traffic originating at and/or destined for internal nodes, but do
      not permit exogenous traffic to "transit" through the stub network".</t>

      <t>Practical applications however suggest that MANETs can act as
      either true stub networks (e.g., a cellphone providing an Internet
      connection sharing peer for a local multihop Wi-Fi region) or as
      "not-so-stubby" networks (e.g., Intelligent Transportation Systems
      where the 5G/6G "SideLink" service supports vehicle-to-vehicle (V2V)
      multihopping). In the former case, the cellphone acts as an IP
      router for a stub Wi-Fi MANET behind it and the individual Wi-Fi
      nodes act as dependent nodes. In the latter case, individual 5G/6G
      SideLink nodes can connect the stub MANETs they aggregate across
      not-so-stubby V2V multihop forwarding paths. MANET Internetworking
      must therefore be capable of accommodating all such scenarios.</t>

      <t>A widely-accepted axiom at the time of this writing suggests
      that there are more cellphones than people on the planet <xref
      target="STATISTA"/>. According to Wikipedia, the world population
      reached 8 billion in 2022 and is expected to reach 10 billion by
      2056 <xref target="WIKI"/>. Each mobile node that connects to the
      global public Internet can in some sense be regarded as a singleton
      "MANET" with the potential to connect still larger MANETs.</t>

      <t>A common concern cited for regarding a cellphone as a MANET
      router is battery consumption, but this not an issue when the
      cellphone is connected to a power source such as when used inside
      of a vehicle. Even in dismounted scenarios, however, having a
      (limited-duration) multi-hop communications capability may be
      deemed worthwhile and could provide a safety-of-life capability
      such as for emergency response, disaster relief, search and
      rescue, etc. Mapping services, streaming video and many other
      applications drain cellphone batteries, but people use them
      all the time. An endless variety of cellphone apps already
      exists, with many more released every day. For these reasons,
      it is expected that MANET apps for cellphones will eventually
      emerge and proliferate.</t>

      <t>With such a large population of candidate nodes, MANET
      Internetworking therefore regards the global Internet as a
      "network of (mobile ad-hoc) networks" with unrestricted dynamic
      relationships between distinct MANET local routing regions
      joined by a Non-Broadcast Multiple Access (NBMA) virtual overlay
      link manifested through encapsulation. <xref target="manet-inet"/>
      illustrates an example of 2 distinct MANET local routing regions
      connected via the NBMA overlay using the Internet as transit:</t>

      <figure anchor="manet-inet" title="MANET Internetworking">
        <artwork><![CDATA[ 
                             .-(::::::::)
                          .-(::: Global ::)-.
               X==+======(===================)======+==X
                  |        `-(: Internet :)-'       |
                  |           `-(::::::)-'          |
                  |                                 |
           .-(::::::::)                       .-(::::::::)
        .-(::::::::::::)-.                 .-(::::::::::::)-.
       (::::: MANET 1 :::::)              (::::: MANET 2 :::::)
         `-(::::::::::::)-'                 `-(::::::::::::)-'
            `-(::::::)-'                       `-(::::::)-'
]]></artwork>
      </figure>

      <t>While the figure depicts just 2 MANET local routing
      regions, many others worldwide will also want to connect
      to the virtual link. Since a sustained increase in both
      the world population and number of mobile wireless devices
      is certain, MANET Internetworking must therefore accommodate
      populations on the order of O(10**10) or more. This includes
      address duplication avoidance through operational assurance
      since statistical properties alone may be insufficient to
      avoid duplication in such large populations.</t>

      <t>Since each MANET itself is mobile, its border routers may
      continuously encounter different Internetwork access points
      as they roam while potentially configuring a different IP
      address at each access point. MANET border routers therefore
      must not continuously inject and withdraw mobile network prefixes
      into the Internetwork BGP routing system as they move since
      this would result in unacceptable churn. MANET routers instead
      maintain stable addresses in a Mobility Service Provider (MSP)
      overlay over the Internetwork such that the overlay addresses
      remain stable even if the border router's underlay address
      changes frequently.</t>

      <t>The overlay network BGP routing system must similarly
      be protected from mobility churn by maintaining address to
      mobility anchor point mappings in a scalable directory service
      such as the domain name system (DNS). Efficient path traversal
      across the overlay must be supported through traffic flow
      diversity per <xref target="RFC6437"/><xref target="RFC6438"/>
      with differentiated services applied within each flow. This is
      especially important for the common case of multilink MANET
      nodes (such as cellphones with both 5G and Wi-Fi interfaces)
      where overlay flow bindings are necessary for multilink
      coordination.</t>

      <t>BGP scaling in the modern Internet backbone accommodates
      O(10**6) prefixes that rarely change. Frequent advertisement and
      withdrawal of MLAs/MNPs can cause BGP churn resulting in instability
      in the global routing system such that BGP alone is not well suited
      to supporting mobile Internetworking by itself. With an overlay,
      the BGP routing service only needs to cover the addresses of
      Mobility Anchor Points (MAPs) which are stable nodes not subject
      to mobility. Within the overlay, the MAPs keep track of MLA/MNP to
      MAP associations which may change dynamically. This is accommodated
      through a combination of a hierarchical overlay BGP arrangement of
      the MAPs in combination with dynamic updates to the (reverse) DNS
      resource records that associate MLAs/MNPs with MAPs. Finally, the
      architecture is not limited to only one gigantic global overlay;
      there could be many smaller overlays operated by MSPs.</t>

      <t>"IPv6 Wireless Access in Vehicular Environments (IPWAVE):
      Problem Statement and Use Cases" <xref target="RFC9365"/>
      provides a complimentary analysis but does not explore
      MANET-specific idiosyncrasies. This document presents a
      MANET Internetworking problem statement and gap analysis.</t> 
    </section>

    <section anchor="terminology" title="Terminology">
      <t>The following terms are defined within the scope of this document:</t>

      <t><list style="hanging">
        <t hangText="Client"><vspace/>a MANET router that connects
        a mobile network to a multilink Internetworking service via
        Proxy/Servers in a Non-Broadcast, Multiple Access (NBMA) overlay.</t>

        <t hangText="Gateway"><vspace/>an overlay multilink network
        service node that runs an interdomain routing protocol (e.g.,
        BGP) and directory service (e.g., DNS) to track Client-to-MAP
        associations. Gateways furthermore join multiple Internetworking
        segments in an overlay multilink virtual bridging service
        to form larger Internetworks.</t>
       
        <t hangText="Internetwork"><vspace/>a more stable and wide-area
        terrestrial, non-terrestrial or hybrid network that can serve as
        transit to interconnect disjoint (or partitioned) MANET local
        routing regions. The global public Internet is an example, as
        are private operator service networks either individually or
        in concatenations with other service networks.</t>

        <t hangText="Media Access Control (MAC) Address"><vspace/>an
        IEEE EUI-48 or EUI-64 address, or an L2 address format specific
        to a custom data link specification.</t>

        <t hangText="Mobile Ad-hoc Network (MANET) "><vspace/>the same as
        defined in <xref target="RFC2501"/>; often includes mobile nodes
        with limited range wireless transmission media interfaces that
        establish links via a dynamically changing set of neighbors
        within operational range and engage in a MANET local routing
        protocol. The MANET local routing protocol can be configured
        to operate as either an L3 (IP-based) or L2 (MAC address-based)
        service according to operational requirements. In both cases,
        each MANET can dynamically partition into multiple smaller
        MANETs or merge with others to form larger MANETs. This may
        present a challenge to the classical IP "on-link" subnet
        model.</t>

        <t hangText="MANET Border Router"><vspace/>a MANET router that
        also has a continuous or intermittent interface connection to
        a transit Internetwork.</t>

        <t hangText="MANET Cluster Head"><vspace/>a MANET router that
        joins multiple smaller MANET local routing regions to form a
        single larger local routing region. Each smaller region is
        seen as a cluster within the larger region.</t>

        <t hangText="MANET Interface"><vspace/>a node's (typically
        wireless) limited range transmission media interface with
        indeterminant connectivity properties.</t>

        <t hangText="MANET Router"><vspace/>a node that runs a routing
        protocol over one or more MANET interfaces to establish multihop
        forwarding paths within a local routing region. Forwarding nodes
        in both L2- and L3-MANETs are considered "routers" even when
        forwarding is based on MAC addresses. All MANET routers are also
        considered MANET nodes, but not all MANET nodes necessarily act
        as MANET routers.</t>

        <t hangText="Mobility Anchor Point (MAP)"><vspace/>a
        Proxy/Server that also provides mobility, address/prefix
        autoconfiguration and address resolution services to
        Clients. The MAP also runs an interdomain routing protocol
        (e.g., BGP) to announce its Client associations to Gateways.
        All (reasonably) stable Proxy/Servers are eligible to serve
        as MAPs as part of a Distributed Mobility Management (DMM)
        service.</t>

        <t hangText="Mobile Network Prefix (MNP)"><vspace/>a longer IP
        prefix delegated from an MSP (e.g., 2001:db8:1000:2000::/56,
        2002:192.0.2.8::/46, etc.) and assigned to a Client. Clients
        receive MNPs from MAP Proxy/Servers and sub-delegate them to
        routers in downstream networks.</t>

        <t hangText="Mobility Service Prefix (MSP)"><vspace/>an aggregated
        IP GUA prefix (e.g., 2001:db8::/32, 2002:192.0.2.0::/40, etc.)
        assigned to a mobility service provider's overlay and from which
        more-specific MNPs are delegated.</t>

        <t hangText="Multilink Local Address (MLA)"><vspace/> an IPv6
        address based on a cryptographic hash of the node's public key
        regarded as its full identify. The MLA is regarded as a unique
        identity tag that, when assigned to an interface, becomes a
        valid IPv6 address with multilink-local scope. The MLA must
        be assured globally unique and routable at least within the
        overlay limited domain to support MANET Internetworking.
        A candidate MLA type appears in <xref target="RFC9374"/>.</t>

        <t hangText="Proxy/Server"><vspace/>an overlay multilink
        network service node in an Internetwork that provides
        proxy forwarding services to MANET border routers and
        other MANET router Clients.</t>
      </list></t>
    </section>

    <section anchor="use" title="MANET Use Cases">
      <t>MANETs have an important role in emergency response communications,
      disaster relief situations, communications in remote and rural areas, 
      military operations, vehicular and swarm communications, and 
      low-powered Internet of things (IoT) applications. MANETs provide 
      the ability to establish and maintain communications when infrastructure-
      based networks, such as 5G cellular communication systems, are not 
      accessible.  As described above, MANETs may also provide Internet
      connectivity to internal nodes, for example, as a "stub" network 
      via MANET routers which possess an Internetworking capability and 
      an external connection to a radio access network.</t>

      <t>Example use cases of such MANETs include the following:<list
      style="symbols">
        <t>Disaster Relief: Disaster situations may compromise network
        infrastructure, such as through the loss of base stations in a 
        cellular radio access network (RAN). In this scenario, MANET 
        networks can play a role in closing coverage gaps through 
        multi-hop routing to nodes within the coverage area of 
        uncompromised base stations. This use case is broadly 
        applicable to any situation in which nodes are operating 
        outside or at the periphery of RAN coverage.</t>

        <t>Tracking and Monitoring: Another example use case is the
        tracking and monitoring of data from low-cost low-power IoT 
        devices ("tags") which may be placed on packages during shipment 
        or storage. Such devices may transition in and out of coverage of 
        infrastructure-based networks, often being located in environments
        that are not conducive to RF propagation (e.g., shipping
        container, warehouse, etc.). The ability to discover and connect
        to neighboring MANET-enabled devices and to establish Internet 
        connectivity through such MANETs, enables real-time logistics
        and inventory data to be collected opportunistically.</t>

        <t>UAV Swarms: local communications within swarms for 
        coordination and cooperation is a good use case for 
        MANET networks due to the highly mobile dynamic nature 
        of such networks. Yet swarms may also benefit from 
        connectivity to the Internet, or other external networks.
        And in large swarm-based MANETs, routing of traffic through 
        infrastructure networks to MANET endpoints, rather than traversing
        the entire MANET can improve communications throughput 
        and reliability.<br/><br/>
        Under mobility conditions, distinct UAV swarms defined by MANET
        local routing regions will encounter situations where the local regions
        enter into communications range of each other. In this case, it is
        desirable to establish cluster heads between these regions and to
        propagation host routes over them as new interconnections are available
        and discovered. Moreover, UAV swarms for which internetworking will
        be persistent should be able to perform local region merger. In this
        case, internetworking protocols must support seamless merger of the
        MANET local routing regions into a larger region. Conversely, nodes
        or collections of nodes which leave coverage of the local region
        should be capable of establishing and operating an independent
        local region at a future time.</t> 
      </list></t>
    </section>

    <section anchor="layer" title="MANET Architectural Layering">
      <t>MANET routing for nodes operating in a common local routing
      region can be configured to operate as either a layer-3
      (L3-MANET) or layer-2 (L2-MANET) service.</t>

      <t>In L3-MANET, routing and addressing occurs at the IP layer
      and each MANET forwarding hop decrements the IP TTL/Hop-Limit.
      IP address uniqueness assurance is essential to avoid conflicts,
      while MAC address collisions may not pose significant operational
      issues. The MANET interface observes a partially-connected
      multi-access link with some nodes as single-hop IP neighbors
      and others reachable only over multi-hop paths. IP multicast
      transmissions only reach single-hop neighbors which must
      engage an IP layer service such as Simplified Multicast
      Forwarding (SMF) <xref target="RFC6621"/> to flood multicast
      messages to all MANET nodes. IP header compression state must
      be maintained at each MANET forwarding hop and may become
      invalidated due to path changes.</t>

      <t>In L2-MANET, routing and addressing occurs at the MAC layer
      and the IP TTL/Hop-Limit is not decremented. Both IP address
      and MAC address uniqueness assurance are essential to avoid
      conflicts. The MANET interface observes a fully-connected
      multi-access link with all nodes appearing as single-hop IP
      neighbors even though some may be separated by multiple L2 hops.
      IP multicast transmissions are propagated to all MANET nodes even
      though the L2 service may be required to forward at the layer
      below IP. IP header compression state is only maintained at the
      MANET ingress and egress nodes and is therefore not invalidated
      due to interior MANET path changes. Instead, the L2 header must
      carry additional overhead (including a TTL, packet identification
      and ancillary addresses) to support forwarding at a layer below IP.</t>

      <t>Since L3-MANETs propagate IP host routes, multicast-based
      address resolution services are unnecessary thereby reducing
      dependence on MANET multicast. By default, L2-MANETs require
      multicast-based address resolution services which can be
      minimized through proactive distribution of address
      resolution information.</t>

      <t>In both the L2- and L3-MANET models, MANETs can partition
      into smaller separate MANETs or merge to form larger MANETs.
      This presents a challenge to the classical IP subnet model
      where all nodes within the subnet are presumed to be reachable
      as single-hop neighbors connected to the same (shared) link.
      All MANET routers should therefore only configure the MLA
      and MSP prefixes as on-link prefixes on an overlay interface.
      This causes the node to invoke address resolution for both
      MANET-local nodes and target peers in other networks
      reached via the overlay. MANET Internetworking concepts
      apply equally to both the L3-MANET and L2-MANET models
      as discussed throughout the document.</t>
    </section>

    <section anchor="prob" title="MANET Internetworking Problem Statement">
      <t>MANETs present a unique set of Internetworking challenges not
      addressed by earlier works <xref target="RFC5889"/><xref target=
      "RFC9365"/>. The following sub-sections provide MANET Internetworking
      problem statements for aspects not (fully) satisfied by existing
      services that must be addressed by any solution proposals.</t>

      <section anchor="pr1" title="Problem 1: Multilink Local Addressing">
        <t>MANET Internetworking observes the IP addressing model in
        ad hoc networks <xref target="RFC5889"/>. Each MANET router
        requires a unique IP address for MANET local communications
        and a unique router ID for participation in the local routing
        protocol. The address is termed the Multilink Local Address
        (MLA) configured from a shared IPv6 prefix from which each
        node within the MANET internetworking overlay must configure
        a unique MLA.</t>

        <t>For MANETs that are only intermittently connected to an
        Internetwork, the MLA must be generated from a prefix of scope
        greater than link-local but not associated with any
        infrastructure aggregation points. For all MANET types, each
        MLA and router ID must be locally-unique within the (limited)
        MANET local routing region. For not-so-stubby MANETs, each MLA
        must also be globally-unique among all MANET local routing
        regions worldwide.</t>

        <t>The locally-unique property ensures that no two nodes that
        participate in the routing protocol within the same MANET local
        routing region configure the same MLA and/or router ID. The
        globally-unique property for MLAs may seem moot until one
        considers that a first MANET can merge with other MANETs, and
        nodes from a first MANET can freely move to other MANETs. This
        may allow a node from a first MANET where there are no duplicates
        to interact with other MANETs where a duplicate address may be
        encountered resulting in unpredictable behavior and/or
        communication failures.</t>

        <t>Although the node population for each MANET local routing
        region is likely to be modest, the total population of MANET
        routers that may join the MANET Internetworking overlay may be
        on the order of the number of worldwide mobile connections (see:
        <xref target="intro"/>). Assuming O(10**10) wireless connections,
        if MANET routers assigned random addresses from a 64-bit space,
        the probability of one or more collisions within the total
        world population (i.e., when multiple nodes independently
        configure the same address) exceeds 98% <xref target=
        "RFC9374"/>. With such a high likelihood of duplication
        in the worldwide population, unresolvable collisions could
        disrupt communications.</t>

        <t>When MANET Internetworking is applied to connect routers
        in different not-so-stubby MANETs, independent local routing
        regions are dynamically joined by an overlay that spans any
        underlying Internetworks as a normal course of operational
        data communications. When multiple MANET local routing
        regions merge in this way, the MLAs present in all MANETs
        must be mutually exclusive.</t>

        <t>In the limiting case, all worldwide MANET local routing
        regions may be considered to be persistently merged over
        the MANET Internetworking overlay at all times. Statistical
        uniqueness properties of random assignments from even
        very large populations may therefore be insufficient to
        ensure collision freedom since MANET Internetworking exposes
        the full world population of MLAs as potential duplicates.</t>

        <t>Nodes in not-so-stubby MANETs should therefore configure
        MLAs managed for global uniqueness even if they first
        self-generate the MLAs (e.g., based on a secure hash of a
        public key) before enrolling them in a registration service.
        The node assigns its MLA to an overlay multilink network
        interface or another virtual interface such as a loopback.
        Routers in all MANETs also configure unique router IDs that
        may be derived from the MLA or randomly generated with
        sufficient statistical uniqueness properties within the
        local region.</t>

        <t>In addition to MLAs, L2-MANET routers must also configure
        L2 MAC addresses on their MANET interfaces that are assured
        unique at least within the MANET local routing region. MAC
        addresses can be configured either through random generation
        with universal/local (U/L) bit set to "local" or
        administratively assigned according to an organizationally
        unique identifier (OUI) with U/L set to "universal". If
        multiple routers within the same MANET local routing region
        somehow configure the same MAC address they must detect and
        deconflict the duplication to ensure routing system integrity.</t>

        <t>In addition to MLAs, an important use case for IPv6
        Link-Local Addresses (LLAs) remains. MANET routers assign
        LLAs to their MANET interfaces by embedding their interface
        MAC addresses within the LLA Interface Identifier (IID)
        <xref target="RFC4862"/><xref target="RFC5889"/>. This
        provides a next hop address for routes discovered by the
        MANET routing protocol and supports stateless forwarding
        based on the LLA's embedded MAC address without requiring
        address resolution messaging. For L3-MANETs, if each router
        assigns a MAC address independently, the possibility for
        duplication exists but this does not present a problem if
        the MANET router sets its router ID to an assured-unique
        value instead of an LLA. Any packets forwarded according
        to a duplicate next hop LLA would simply be deconflicted
        by the IP layers of the multiple next hop routers.</t>
      </section>

      <section anchor="pr2" title="Problem 2: Autoconfiguration">
        <t>When a MANET comes in contact with a fixed Internetwork such
        as the global public Internet, nodes in the MANET that engage
        global mobile Internetworking services require some means of
        autoconfiguring global-scoped IP addresses or prefixes that
        are properly routable by network elements accessible from the
        current point of attachment. These network elements are typically
        proxies or gateways of some variety that connect to the mobile
        routing system.</t>

        <t>Nodes in L3-MANET local routing regions that are multiple
        IP hops away from a MANET border router with an Internetwork
        connection cannot use unmodified standard autoconfiguration
        services including IPv6 Neighbor Discovery (IPv6ND) <xref
        target="RFC4861"/> or DHCPv6 <xref target="RFC8415"/> over
        a MANET interface since these services are link-scoped in
        nature. (The DHCPv6 architecture includes a "relay" function,
        but the dynamic nature of links in (multi-link) MANET local
        routing regions may interfere with straightforward application
        of DHCPv6 relays.) Nodes in L2-MANET local routing regions
        see the MANET border routers as single-hop IP neighbors,
        but require a means of selecting specific border routers
        when multiple are present.</t>

        <t>Two methods of supporting generalized autoconfiguration for nodes
        within a MANET have been suggested. In a first method (conducted
        directly over MANET interfaces) first-hop neighboring nodes within
        the MANET collectively participate to repeat link-scoped
        autoconfiguration discovery requests to other neighbors that are
        topologically closer to a MANET border router. This hop-by-hop
        process continues between neighbors until the request arrives at
        a MANET border router that can then contact an Internetwork element
        capable of delegating an Internet Service Provider (ISP)
        Provider-Aggregated (PA) IP address or prefix. The Internetwork
        element then returns the delegated IP address/prefix in a reply
        that traverses the reverse path to the original requesting node.
        Each MANET router then configures a route to this IP address/prefix
        within the MANET local routing protocol, i.e., the MANET local
        routing protocol becomes aware of the delegation.</t>

        <t>In a second autoconfiguration method, the requesting node configures
        a (virtual) overlay multilink network interface over its (physical)
        MANET interface(s) and issues standard link-scoped IPv6ND and/or DHCPv6
        requests over the virtual interface. The virtual interface applies
        encapsulation to provide the appearance of a single NBMA link
        spanning the entire (multilink) MANET. This virtual link supports
        standard link-scoped autoconfiguration services coordinated with
        an Internetwork element capable of delegating an address. For stub
        MANETs, the MANET border router itself delegates a public or private
        IP address. For not-so-stubby MANETs, an overlay Internetwork Mobility
        Anchor Point (MAP) delegates a MNP as an IP prefix maintained by the
        overlay independently of the Internetwork attachment point. The MAP
        then returns the delegated IP prefix in a link-scoped reply over the
        virtual interface that traverses the reverse path to the original
        requesting node.</t>

        <t>In one alternative, MANET routers located one or more hops
        from a MANET border router can regard the MANET border router as
        a Network Address Translator (NAT) to convert MANET local addresses
        into MNP addresses with no autoconfiguration requirements; they can
        also request address delegations directly from the border router's
        MNP(s) and use them to support communications with Internetwork
        peers according to the stub model. MANET routers can instead (or
        in addition) request their own MNPs and register their MLAs with
        a MAP while using the MANET border router as a transit intermediate
        system according to the not-so-stubby model.</t>
      </section>

      <section anchor="pr3" title="Problem 3: MANET-local Communications">
        <t>Two nodes located within the same MANET local routing region should
        be able to communicate (across multiple hops if necessary) using MLA
        addressing with no external Internetwork infrastructure reference
        points. As long as the MLAs configured by communicating peers are
        unique, the MANET local routing system maintains continuous
        multihop forwarding services to ensure session continuity.</t>

        <t>Nodes within the MANET local routing region can discover the
        MLAs of peers using services like Multicast DNS (mDNS) <xref
        target="RFC6762"/>. Peer-to-peer communications can then be
        coordinated in multihop fashion using encapsulation and header
        compression via an overlay virtual link spanning any MANET
        intermediate hops in the path.</t>

        <t>Header compression represents a fundamental requirement for
        maximizing MANET-local communications efficiency, since the size
        of the compressed encapsulation and upper layer protocol headers
        is significantly smaller than the size of the uncompressed
        upper layer headers when no encapsulation is applied. However,
        header compression state must be synchronized between the
        endpoints of each IP hop.</t>

        <t>For L2-MANET, this means that only the MANET ingress and
        egress nodes (as well as any intermediate cluster heads) need
        to synchronize IP state since all other intermediate hops are
        based on MAC layer addressing and forwarding. For L3-MANET,
        all MANET hops between the ingress and egress nodes must also
        synchronize state meaning that resynchronization is required
        following a path change. A tension therefore exists between
        L2-MANET which includes larger MAC headers and L3-MANET which
        may be challenged to maintain state synchronization in dynamic
        networks.</t>

        <t>For both L2- and L3-MANETs, the MANET can partition into
        multiple smaller MANETs with some border routers remaining
        in a first partition and others relocated to other partitions.
        This means that it is not possible for a MANET to maintain a
        classic global IP shared subnet where all nodes are presumed
        to be connected to the same (shared )IP link. The only shared
        IP subnet that should appear on the link is the MLA prefix,
        since the overlay ensures reachability for MLA addressed
        nodes whether they are located in the local MANET or in
        a different MANET reached via a border router connected
        to the overlay.</t> 
      </section>

      <section anchor="pr4" title="Problem 4: MANET Peer to Internetwork Correspondent">
        <t>When an originating peer (or its stub MANET border router) within
        a not-so-stubby MANET needs to communicate with correspondents connected
        elsewhere in an external Internetwork, the peer consults the global DNS
        which returns a (stable) globally-routable IP address for the correspondent.
        The peer can then use one of its MNP-based IP addresses obtained through
        autoconfiguration and the global IP address of the Internetwork correspondent
        as the source and destination addresses for packet exchanges.</t>

        <t>To initiate communications with an Internetwork correspondent, the
        MANET peer first establishes per-flow on-demand virtual circuits
        in the overlay to an Internetwork relay beyond the MANET border. MANET
        local multihop routing will then convey the peer's original packets
        to the MANET border which then forwards them via the overlay to an
        Internetwork relay which directs the packets to the correspondent
        node.</t>

        <t>In the reverse path, the correspondent uses the MNP-based IP
        address of the peer obtained from the source address of initiating
        packets as the destination address for reply packets. Standard
        Internetwork routing will direct the packets back to the relay
        which then forwards them via per-flow overlay virtual circuits
        to the originating peer's MANET border. MANET local routing and
        forwarding will then convey the packets over one or more
        MANET local hops until they ultimately reach the peer.</t>

        <t>In this case, the originating peer's IP address need not appear
        in the global DNS since the correspondent discovers the address by
        examining the source of received packets.</t>
      </section>

      <section anchor="pr5" title="Problem 5: Internetwork Correspondent to MANET Peer">
        <t>When an Internetwork correspondent needs to communicate with a target
        peer within a MANET local routing region, the correspondent consults
        the global DNS to determine an IP address for the peer.</t>

        <t>The correspondent then forwards packets via standard Internet
        routing until they arrive at a relay. The relay then establishes
        per-flow virtual circuits in the overlay to the MANET peer
        while forwarding packets via the virtual circuit until
        they reach the destination. Reverse path forwarding from the
        MANET peer to the Internetwork correspondent is then conducted
        in the same manner described in <xref target="pr4"/>.</t>

        <t>IP addresses covered by delegated prefixes remain stable even
        across MANET-wide mobility events to the point that continuous
        dynamic updates to the DNS are not required to maintain
        uninterruptable communications. While it is possible that mobility
        events may cause minor temporary disruptions, transport protocol
        retransmissions will maintain continuity for any ongoing sessions.</t> 
      </section>

      <section anchor="pr6" title="Problem 6: Peer-to-Peer Between Different MANETs">
        <t>When two prospective peer nodes are located in different MANET
        local routing regions separated by one or more transit Internetwork
        segments, both peers should include their IP addresses in global
        DNS resource records for the same reasons cited in <xref target="pr5"/>.</t>

        <t>The peers then establish per-flow virtual circuits in the overlay
        to support peer-to-peer packet forwarding. The peers may use either
        an MNP address or their MLAs, which are routable within the overlay
        limited domain. The overlay therefore exhibits the outward appearance
        of a MANET-of-MANETs, where overlay interior nodes engage in an
        interdomain global routing service bridging many MANET local
        routing regions.</t>

        <t>A certain degree of coordination between peer nodes and their
        MAPs is then required to maintain address mappings. The overlay
        ensures that each peer remains reachable at its stable IP
        address/prefix through distributed mobility management.</t>

        <t>Note that a common use case includes joining multiple partitions
        of a formerly unified MANET local routing region. The partitions may
        arise from pre-planned or un-planned node mobility patterns, but as
        long as each partition includes a MANET border router with an
        Internetwork connection nodes within different partitions can
        continue to communicate using their MLAs.</t>
      </section>

      <section anchor="pr7" title="Problem 7: Stub MANET to Not-so-stubby MANET Connections">
        <t>When a MANET border router connects a stub MANET to an Internetwork,
        it can either delegate global-scoped IP addresses to stub MANET routers or
        apply Network Address Translation (NAT) to non-global scoped addresses
        (e.g., IPv6 Unique Local Addresses) to support external communications.</t>

        <t>In the public case, all manners of peer-to-peer communications
        are made possible due to the globally routable nature of the addresses.
        In the NAT case, only communications initiated by a stub network
        peer are supported since the reverse path terminates at the NAT.</t>

        <t>The stub MANET itself may configure a local overlay that
        regards the (multihop) MANET as a single unified link. In that
        case, the stub network overlay link is distinct from the
        overlay link that spans the global public Internet and the
        two links are joined by the MANET border router acting as
        an IPv6 router.</t>

        <t>In the not-so-stubby case, a single overlay link extends
        across both any transit Internetworks and the source and target
        MANETs themselves. All peer-to-peer communications are therefore
        conveyed across a globally-extended MANET Internetworking
        overlay.</t>
      </section>
    </section>

    <section anchor="gap" title="MANET Internetworking Gap Analysis">
      <t>Many current and past solution proposals address most aspects
      of the problems articulated in the previous section, but often
      have functional gaps that do not fully satisfy the requirements.
      The following gaps must be addressed by candidate solutions:</t>

      <section anchor="ga1" title="Gap 1: Multiple Heterogeneous MANET Interfaces">
        <t>In anticipated practices, nodes will often have multiple and
        heterogeneous MANET interfaces connected to the same MANET local
        routing region. Most notably, the vast majority of cellphones
        have both Wi-Fi and 5G cellular interfaces which will soon support
        a "SideLink" mode of operation for device-to-device communications
        outside of the context of cellular infrastructure.</t>

        <t>With their Wi-Fi interfaces engaged in "ad-hoc" mode and 5G
        interfaces engaged in "SideLink" mode, nodes within a MANET local
        routing region can exchange control information and forward packets
        across multiple hops if necessary even if some hops are carried
        over Wi-Fi and others over 5G SideLink. A unique addressing scheme
        is also necessary across the heterogeneous combined MANET region
        to maintain consistent and compatible routing information. Most
        importantly, the addressing schemes between the heterogeneous
        media must be mutually compatible and address assignments must
        be assured unique so that no duplication is possible.</t>

        <t>Aside from cellphones and the like (which represent an enormous
        use case space), multiple heterogeneous MANET interfaces often
        occur on mobile platforms such as tactical military and/or
        unmanned air systems. These same considerations also apply
        within any such domains.</t>
      </section>

      <section anchor="ga2" title="Gap 2: Maximum Packet Size Diversity">
        <t>In conjunction with Gap 1, heterogeneous MANET interfaces
        often also support diverse maximum packet sizes also known
        as the Maximum Transmission Unit (MTU). For example, the initial
        and final hops of a multihop path may support MTUs of 1500 octets
        or larger while some intermediate hops support MTUs as small as
        1280 octets. Communications must therefore remain continuous and
        without loss of large packets due to a path MTU "black hole". Any
        solution proposal must therefore address the need for maximum
        packet size diversity given the clear need to support
        heterogeneous environments.</t>
      </section>

      <section anchor="ga3" title="Gap 3: Header Compression">
        <t>MANET data plane packets often include sizeable upper layer
        headers including any encapsulations, the IP header and upper
        layer protocol headers. Especially for smaller packet sizes,
        the overhead for carrying significant header payloads can
        waste precious wireless transmission bandwidth.</t>

        <t>L2- and L3-MANET solutions have different approaches
        to header compression that may be better suited for some
        operational scenarios than others. L2-MANET includes larger
        L2 headers with every packet such that IP header compression
        state is required at the MANET ingress, egress and IP-addressed
        cluster head nodes, while L3-MANET uses minimal L2 headers but
        requires IP header compression state also in MANET intermediate
        nodes. Any solution proposal must therefore address the need
        for header compression for multi-hop packet flows within the
        context of intended use cases.</t>
      </section>

      <section anchor="ga4" title="Gap 4: MANET Border Router Discovery and Engagement">
        <t>Ordinary MANET routers must be able to discover and effectively
        engage the best MANET border router(s) especially when multiple
        alternatives may be present. For example, a MANET with 100
        ordinary nodes may include 4 MANET border routers that also
        have longer-range Internetworking links such as via LEO
        satellites. Each MANET router must discover border routers
        that may be multiple MANET local hops away and somehow cause
        their packets to flow through the MANET to a border router
        that in turn invokes MANET Internetworking. Any solution
        proposal must therefore address these needs.</t>
      </section>

      <section anchor="ga5" title="Gap 5: MANET Internetworking Security">
        <t>The fact that a node is admitted into a MANET local routing
        region does not ensure that the node is authorized to establish
        flow state in the MANET and/or invoke MANET Internetworking
        services. For that reason, a gap exists that requires a solution
        for securely admitting MANET clients into the MANET Internetworking
        service. Any solution proposal must therefore address the security
        gap.</t>
      </section>
    </section>

    <section anchor="sol" title="MANET Internetworking Solution Proposal Analysis">
      <t>The following sections provide an analysis of solution proposals
      with respect to the problem statements and gap analysis. Any solution
      proposal must explain how it addresses the problems while also showing
      how it either does or does not satisfy the technological gaps.</t>

      <section anchor="sol1" title="AERO/OMNI">
      </section>

      <section anchor="sol2" title="NEMO (RFC3963)">
      </section>

      <section anchor="sol3" title="LISP-based mobility and overlays">
      </section>

      <section anchor="sol4" title="HIP mobility">
      </section>

      <section anchor="sol5" title="DLEP-based MANET deployments with gatewaying">
      </section>

      <section anchor="sol6" title="Conventional tunneling / prefix delegation approaches">
      </section>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document is an informational problem statement and
      does not in itself request any IANA actions. IANA considerations
      can be found in solution space documents.</t>
    </section>

    <section anchor="secure" title="Security Considerations">
      <t>MANET Internetworking assumes a multi-layer security architecture.
      Physical and data link layer security is assumed within each MANET
      local routing region and with proper network layer authentication
      for admitting nodes into the MANET Internetworking overlay service.
      Transport and higher layer security should then be applied for
      end-to-end confidentiality, integrity and authorization.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>Discussions on the MANET working group mailing list helped shape
      concepts exposed in this document. The following are acknowledged
      for their helpful comments: Abdussalam Baryun, Lou Berger, Stuart
      Card, Juliusz Chroboczek, Christopher Dearlove, Donald Eastlake,
      Joel Halpern and others who provided valuable input on the list
      or through private discussions.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.0791"?>

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

    <references title="Informative References">

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

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

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

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

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

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

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

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

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

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

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

      <reference anchor="STATISTA">
        <front>
          <title>Number of connected devices worldwide as of October 2025, by device,
          https://www.statista.com/statistics/1559435/connected-devices-worldwide</title>

          <author fullname="Statista" initials="S." surname="Statista">
            <organization/>
          </author>

          <date month="March" year="2026"/>
        </front>
      </reference>

      <reference anchor="WIKI">
        <front>
          <title>World population milestones,
          https://en.wikipedia.org/wiki/World_population_milestones</title>

          <author fullname="Wikipedia" initials="W." surname="Wikipedia">
            <organization/>
          </author>

          <date month="March" year="2026"/>
        </front>
      </reference>
    </references>

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

      <t>Differences from -03 to -04:<list style="symbols">
        <t>Introduced distinction between L2/L3 MANETs.</t>

        <t>Supporting text added in response to list discussions.</t>
      </list></t>

      <t>Differences from -01 to -02:<list style="symbols">
        <t>Expanded gap analysis.</t>
      </list></t>

      <t>Differences from -00 to -01:<list style="symbols">
        <t>Updated based on list comments and private communications
        between April-June 2026.</t>
      </list></t>

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