<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<?rfc iprnotified='no'?>
<rfc category="info" docName="draft-templin-manet-inet-00"
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>Boeing Technology Innovation</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="27" month="August" year="2025"/>

    <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. As IP routers <xref
      target="RFC0791"/><xref target="RFC8200"/>, MANET routers represent
      multihop paths as "host routes" established through either proactive
      or reactive discovery.</t>

      <t>Individual MANETs typically include modest numbers of mobile
      nodes (e.g., O(1), O(10), O(100), 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
      often operate autonomously unless or until they encounter
      Internetwork access points of opportunity. </t>

      <t>Data communications between two nodes within the same MANET
      follow host routes using MANET-internal links. When a MANET 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
      true stub networks (e.g., a cellphone that provides a hotspot for
      a multihop WiFi SSID) 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 WiFi MANET behind it and the multihop
      WiFi 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>Google AI reports that: "There are currently more mobile phones
      than people in the world. While the exact number fluctuates, estimates
      suggest there are over 12 billion mobile connections worldwide". Each
      mobile node that connects to the global public Internet can therefore
      be regarded as a network access point for a singleton "MANET" with
      the potential to connect still larger MANETs.</t>
    </section>

    <section anchor="gap" title="MANET Internetworking Problem Statement and Gap Analysis">
      <section anchor="pr1" title="Problem 1: MANET Local Addressing">
        <t>Each MANET router requires a unique IP address for MANET-local
        communications; the router often uses this same address to configure
        a unique "router ID". For MANETs that are only intermittently
        connected to an Internetwork, these addresses must be generated
        from IP prefixes of scope greater than link-local but not associated
        with infrastructure aggregation points. For all MANET types, each
        address/ID must be locally-unique within the (limited) local MANET
        routing domain. For not-so-stubby MANETs, the address/ID must also
        be globally-unique among all local MANET routing domains worldwide. </t>

        <t>The locally-unique property ensures that no two nodes that
        participate in the MANET routing protocol within the same local
        routing domain configure the same address/ID. The globally-unique
        property may seem moot until one considers that MANETs 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 encounter other MANETs where a
        duplicate address may be encountered.</t>

        <t>Although the node population for each MANET local routing
        domain is likely to be modest, the total population of MANET nodes
        may be on the order of the number of worldwide mobile connections
        (12B). Therefore, if MANET nodes 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 for some pair(s)
        of nodes in the world population, an unresolvable collision
        would occur if duplicates ever met within the same local
        routing domain.</t>

        <t>For stub MANETs that always acts independently of all others,
        the risk of a duplication event within each local routing domain
        due to a new node joining is vanishingly small even for extreme
        mobility frequencies according to Appendix A.2 of <xref target=
        "RFC4429"/>. Stub MANETs can therefore rely on statistical
        uniqueness properties of randomly assigned addresses.</t>

        <t>When MANET Internetworking is applied for connecting routers
        in different not-so-stubby MANETs, however, independent local
        routing domains are dynamically joined by (temporary) switched
        virtual circuits across the Internetwork overlay as a normal
        course of operational data communications. When these temporary
        MANET merge events occur, the MANET local IP addresses present
        in the source and destination MANETs must be mutually exclusive.
        These merge events must further be considered to occur at truly
        unbounded frequencies across the global population due to
        the unpredictable nature of worldwide Internetworking
        dynamics for peer-to-peer communications. Statistical
        uniqueness properties of random assignments from even
        very large populations may therefore be insufficient to
        ensure collision freedom.</t>

        <t>MANET Internetworking therefore regards the global public
        Internet as a "MANET-of-MANETs", and with unbounded dynamic
        relationships between distinct local MANET routing regions
        joined by switched virtual circuits. This exposes the full
        world population of MANET local addresses as potential
        duplicates.</t>

        <t>Nodes in not-so-stubby MANETs should therefore configure
        MANET local addresses managed for uniqueness even if they
        first self-generate the addresses before enrolling them
        in a registration service. Such address registration is
        not required for nodes that only connect via stub MANETs.</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 and/or prefixes that
        are properly routable by network elements accessible from the
        current point of attachment. These network elements are typically
        proxies or routers of some variety that connect to the mobile
        routing system.</t>

        <t>Nodes in the local MANET that are multiple IP hops away from an
        Internet connection sharing peer 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) local MANET routing regions precludes
        straightforward application of DHCPv6 relays.)</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 an Internet connection sharing node. This
        hop-by-hop process continues between neighbors until the request
        arrives at an Internet connection sharing node 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 is made 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 Non-Broadcast Multiple
        Access (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 Internet connection sharing node itself delegates a public
        or private IP address. For not-so-stubby MANETS, an overlay network element
        beyond the Internet connection sharing node delegates a Mobility Service
        Provider (MSP) Proxy-Aggregated (PA) and/or Proxy-Independent (PI) IP
        address/prefix as overlay network addresses. The delegating node then
        returns the delegated IP address/prefix in a link-scoped reply over the
        virtual interface that traverses the reverse path to the original
        requesting node. Each MANET router optionally configures a route to
        this IP address/prefix via the virtual interface, i.e., the MANET
        local routing protocol is optionally made aware of the delegation
        within the virtual overlay.</t>
      </section>

      <section anchor="pr3" title="Problem 3: MANET-internal Communications">
        <t>Two nodes located within the same local MANET routing region should
        be able to communicate (across multiple hops if necessary) using MANET
        local addressing with no external Internetwork infrastructure reference
        points. As long as the MANET-local addresses 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 local MANET routing region can discover the
        MANET local addresses of peers using services like Multicast DNS
        (mDNS) <xref target="RFC6762"/> supported by Simplified Multicast
        Forwarding (SMF) <xref target="RFC6621"/>. Peer-to-peer communications
        can then be coordinated either in multihop fashion directly over
        the physical MANET interfaces or via a single virtual hop using
        overlay multilink network interface encapsulation. In that case,
        the MANET peers establish a switched virtual circuit spanning
        any intermediate hops in the path.</t>
      </section>

      <section anchor="pr4" title="Problem 4: MANET Peer to Internetwork Correspondent">
        <t>When an originating peer (or its stub MANET Internet connection-sharing
        node) within a not-so-stubby MANET needs to communicate with a correspondent
        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 MSP-provided PA/PI 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>The MANET peer first establishes a switched virtual circuit 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 Internetwork relay which engages standard Internetwork routing
        and forwarding to direct the packets to the correspondent node. In
        the reverse path, the correspondent uses the overlay 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 an overlay switched virtual circuit 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. This means that the
        originating peer can use a PA address to initiate sessions.
        However, if the PA address changes (e.g., due to movement to a
        new Internetwork attachment point) any communication sessions in
        progress with Internetwork correspondents will fail and the peer
        will need to re-establish them under the new PA address.</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 local MANET routing region, the correspondent consults
        the global DNS. Due to the uncertainty of mobility-based re-addressing
        for PA addresses, however, the peer would be best served by including
        only PI addresses in its global DNS resource records.</t>

        <t>The correspondent then forwards packets via standard Internet
        routing until they arrive at a relay. The relay then establishes a
        switched virtual circuit in the overlay to the MANET peer then
        begins forwarding packets via the switched virtual circuit until
        they reach the destination.</t>

        <t>PI addresses remain stable even across MANET-wide mobility events
        to the point that continuous dynamic updates to the DNS would not be
        necessary 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 with a common Internetwork as a transit network,
        both peers should include PI addresses in their global DNS resource
        records for the same reasons cited in <xref target="pr5"/>.</t>

        <t>The peers then establish switched virtual circuits in the overlay
        to support peer-to-peer bidirectional packet forwarding.</t>

        <t>Maintaining PI addresses requires a certain degree of coordination
        between peer nodes and the MSP. The MSP is responsible for ensuring
        that each peer remains reachable at its stable PI address/prefix
        through distributed mobility management.</t>
      </section>

      <section anchor="pr7" title="Problem 7: Stub MANET to Not-so-stubby MANET Connections">
        <t>When an Internet connection sharing MANET router connects a stub
        MANET, it can either delegate true PI addresses to stub MANET nodes
        or delegate private IP addresses then apply Network Address Translation
        (NAT) to support external communications.</t>

        <t>In the PI case, all manners of peer-to-peer communications are
        made possible due to the globally routable nature of PI 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 an IPv6 router.</t>
      </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 document.</t>
    </section>

    <section anchor="secure" title="Security Considerations">
      <t>This document is an informational problem statement and
      does not in itself address security. Security considerations
      can be found in solution space document.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>Discussions on the MANET working group mailing list helped shape
      concepts exposed in this document.</t>

      <t>This work is aligned with the Boeing/Virginia Tech National
      Security Institute (VTNSI) 5G MANET research program.</t>

      <t>Honoring life, liberty and the pursuit of happiness.</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.4429"?>

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

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

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

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