| Internet-Draft | MANET Internetworking | April 2026 |
| Templin & Jakubisin | Expires 4 October 2026 | [Page] |
[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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 October 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Mobile Ad-hoc Networks (MANETs) [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 [RFC0791][RFC8200], MANET routers represent multihop paths as "host routes" established through either proactive or on-demand discovery.¶
Individual MANETs typically include modest numbers of mobile nodes (e.g., O(1), O(10), O(100), etc.); this 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 cluster heads that limit the extent over which host routes propagate to reduce control message overhead. Finally, MANETs often operate autonomously unless or until they encounter Internetwork access points of opportunity.¶
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 [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".¶
Practical applications however suggest that MANETs can act as either true stub networks (e.g., a cellphone providing a hotspot for a multihop WiFi IBSS) 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 individual 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.¶
A widely-accepted axiom at the time of this writing suggests that there are more cellphones than people on the planet [STATISTA]. According to Wikipedia, the world population reached 8 billion in 2022 and is expected to reach 10 billion by 2056 [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.¶
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. Figure 1 illustrates an example of 2 distinct MANET local routing regions connected via the NBMA overlay using the Internet as transit:¶
.-(::::::::)
.-(::: Global ::)-.
X==+======(===================)======+==X
| `-(: Internet :)-' |
| `-(::::::)-' |
| |
.-(::::::::) .-(::::::::)
.-(::::::::::::)-. .-(::::::::::::)-.
(::::: MANET 1 :::::) (::::: MANET 2 :::::)
`-(::::::::::::)-' `-(::::::::::::)-'
`-(::::::)-' `-(::::::)-'
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 10**10. This includes address duplication avoidance through operational assurance since statistical properties alone may be insufficient to avoid duplication in such a large population.¶
The following terms are defined within the scope of this document:¶
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.¶
Example use cases of such MANETs include the following:¶
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.¶
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.¶
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.
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.¶
MANET Internetworking observes the IP addressing model in ad hoc networks [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. For MANETs that are only intermittently connected to an Internetwork, these IP addresses must be generated from prefixes of scope greater than link-local but not associated with any infrastructure aggregation points. For all MANET types, each address and router ID must be locally-unique within the (limited) MANET local routing region. For not-so-stubby MANETs, each address must also be globally-unique among all MANET local routing regions worldwide while router IDs only need be locally unique.¶
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 address and/or router ID. The globally-unique property for addresses 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.¶
Although the node population for each MANET local routing region is likely to be modest (O(100) or less), the total population of MANET nodes that may join the MANET Internetwork overlay may be on the order of the number of worldwide mobile connections (see: Section 1). Assuming O(10**10) wireless connections, 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% [RFC9374]. With such a high likelihood of duplication in the worldwide population, unresolvable collisions could disrupt communications.¶
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 MANET local addresses present in all MANETs must be mutually exclusive.¶
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 MANET local addresses as potential duplicates.¶
Nodes in not-so-stubby MANETs should therefore configure MANET local addresses managed for global uniqueness even if they first self-generate the addresses (e.g., based on a secure hash of a public key) before enrolling them in a registration service. The node assigns its MANET local address 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 a globally-unique IP address or randomly generated with sufficient statistical uniqueness properties within the local region.¶
An important use case for IPv6 Link-Local Addresses (LLAs) remains even when MANET routers assign MANET local addresses. MANET routers assign LLAs to their MANET interfaces by embedding their interface Media Access Control (MAC) addresses within the LLA Interface Identifier (IID) [RFC4862][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. Since each MANET 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 a locally 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.¶
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.¶
Nodes in the MANET local routing region 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) [RFC4861] or DHCPv6 [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.)¶
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.¶
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 Mobility Service Provider (MSP) Mobile Network Prefix (MNP) as a Provider-Independent (PI) IP prefix maintained by the overlay for the requesting node to provision on downstream-attached interfaces. 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.¶
In summary, MANET nodes 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 nodes can instead (or in addition) request their own MNPs and register their MANET local addresses with a MAP while using the MANET border router as a transit intermediate system according to the not-so-stubby model.¶
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.¶
Nodes within the MANET local routing region can discover the MANET local addresses of peers using services like Multicast DNS (mDNS) [RFC6762] supported by Simplified Multicast Forwarding (SMF) [RFC6621]. Peer-to-peer communications can then be coordinated in multihop fashion using OMNI encapsulation and header compression via an overlay virtual link spanning any MANET intermediate hops in the path.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 Section 4.4.¶
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.¶
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 Section 4.5.¶
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 MANET local address, 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.¶
A certain degree of coordination between peer nodes and the MSP is then required to maintain address mappings. The MSP is responsible for ensuring that each peer remains reachable at its stable IP address/prefix through distributed mobility management.¶
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 MANET local addresses.¶
When a MANET border router connects a stub MANET to an Internetwork, it can either delegate global-scoped IP addresses to stub MANET nodes or apply Network Address Translation (NAT) to non-global scoped addresses to support external communications.¶
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.¶
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.¶
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 the common MANET Internetworking overlay.¶
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.¶
This document is an informational problem statement and does not in itself address security. Security considerations can be found in solution space documents.¶
Discussions on the MANET working group mailing list helped shape concepts exposed in this document. Abdussalam Baryun encouraged a MANET use case analysis.¶
Polls conducted by chairs during the IETF124 MANET working group session presentation of this document showed unanimous and substantial interest in MANET Internetworking: https://datatracker.ietf.org/meeting/124/materials/minutes-124-manet-202511061630-00.¶
Discussions during the IETF125 MANET working group presentation and in subsequent MANET list posts that followed showed significant sustained interest.¶
This work is aligned with the Boeing/Virginia Tech National Security Institute (VTNSI) 5G MANET research program.¶
Honoring life, liberty and the pursuit of happiness.¶
<< RFC Editor - remove prior to publication >>¶
Differences from -04 to -05:¶
Updated discussion of world population estimates.¶
Clarified distinctions between IP addresses and router IDs.¶
Differences from -03 to -04:¶
Cited [RFC4862][RFC5889] and discussed LLAs.¶
Differences from -02 to -03:¶
Added terminology section; expanded use case discussion.¶
Updated architecture figure and made clarifications to the general discussion.¶
Updated acknowledgements to reflect IETF interest.¶
Differences from -01 to -02:¶
Simplified addressing model under Autoconfiguration section. Only autoconfiguration now necessary is for Mobile Network Prefixes (MNPs).¶
Differences from -00 to -01:¶
Differences from earlier versions:¶
First draft publication.¶