MANET Internetworking: Problem Statement and Gap Analysis
draft-ietf-manet-inet-gap-analysis-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Fred Templin , Daniel J. Jakubisin | ||
| Last updated | 2026-08-14 (Latest revision 2026-08-12) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-manet-inet-gap-analysis-07
Network Working Group F. L. Templin, Ed.
Internet-Draft The Boeing Company
Intended status: Informational D. J. Jakubisin
Expires: 15 February 2027 National Security Institute, Virginia Tech
14 August 2026
MANET Internetworking: Problem Statement and Gap Analysis
draft-ietf-manet-inet-gap-analysis-07
Abstract
[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.
Status of This Memo
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 15 February 2027.
Copyright Notice
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.
Templin & Jakubisin Expires 15 February 2027 [Page 1]
Internet-Draft MANET Internetworking August 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. MANET Use Cases . . . . . . . . . . . . . . . . . . . . . . . 8
4. MANET Internetworking Problem Statement . . . . . . . . . . . 9
4.1. Problem 1: Mobility, Partitions and Merges . . . . . . . 10
4.2. Problem 2: Multilink Local Addressing . . . . . . . . . . 10
4.3. Problem 3: Autoconfiguration . . . . . . . . . . . . . . 12
4.4. Problem 4: MANET-local Communications . . . . . . . . . . 14
4.5. Problem 5: MANET Peer to Internetwork Correspondent . . . 14
4.6. Problem 6: Internetwork Correspondent to MANET Peer . . . 15
4.7. Problem 7: Peer-to-Peer Between Different MANETs . . . . 15
4.8. Problem 8: Stub MANET to Not-so-stubby MANET
Connections . . . . . . . . . . . . . . . . . . . . . . . 16
5. MANET Internetworking Gap Analysis . . . . . . . . . . . . . 16
5.1. Gap 1: Multiple Heterogeneous MANET Interfaces . . . . . 17
5.2. Gap 2: Maximum Packet Size Diversity . . . . . . . . . . 17
5.3. Gap 3: Header Compression . . . . . . . . . . . . . . . . 17
5.4. Gap 4: MANET Border Router Discovery and Engagement . . . 18
5.5. Gap 5: MANET Internetworking Security . . . . . . . . . . 18
6. MANET Internetworking Solution Proposal Analysis . . . . . . 18
6.1. AERO/OMNI . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. NEMO (RFC3963) . . . . . . . . . . . . . . . . . . . . . 19
6.3. LISP-based mobility and overlays . . . . . . . . . . . . 19
6.4. HIP mobility . . . . . . . . . . . . . . . . . . . . . . 19
6.5. DLEP-based MANET deployments with gatewaying . . . . . . 19
6.6. Conventional tunneling / prefix delegation approaches . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. MANET Architectural Layering . . . . . . . . . . . . 22
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
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. MANET nodes that act as routers engage a MANET
routing protocol (e.g., OSPF-MDR [RFC5614], OLSRv2 [RFC7181], Babel
[RFC8966], etc.) 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" that name singleton destinations,
Templin & Jakubisin Expires 15 February 2027 [Page 2]
Internet-Draft MANET Internetworking August 2026
with IP addressing and forwarding [RFC0791][RFC8200] engaged in
accordance with protocol layering (see: Appendix A).
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.
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. MANETs can also
dynamically partition into multiple smaller MANETs or merge to form
unified larger MANETs. 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) for distribution on downstream-attached
interfaces according to the prefix per client model [RFC9663].
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 client MANET routers 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 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.
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]. With their
Templin & Jakubisin Expires 15 February 2027 [Page 3]
Internet-Draft MANET Internetworking August 2026
multiple wireless access technologies capable of supporting a device-
to-device (D2D) multihop forwarding service, all cellphones can be
regarded as potential MANET routers.
A common concern cited for engaging a cellphone as a MANET router is
battery consumption, but this not an issue when the device is
connected to a power source such as when used inside of a vehicle.
Even in dismounted scenarios, a (limited-duration) multihop
communications capability could provide vital services such as for
emergency response, disaster relief, search and rescue, etc. Mapping
and streaming video applications drain cellphone batteries but
everyone uses them all the time, plus an endless variety of other
power-hungry apps already exists with many more released every day.
Moreover, at the dawning of the millennium few people imagined that a
cellphone could be made to serve as a Wi-Fi access point but that
capability has since become both robust and ubiquitous. These
factors strongly suggest that cellphones will continue to adapt to
support advanced communication services.
With such a large population of potential MANET routers (to also
include non-cellphone node types), MANET Internetworking therefore
regards the global Internet as a "network of (mobile ad-hoc)
networks" with dynamic peering relationships between distinct MANET
local routing regions joined by a Non-Broadcast Multiple Access
(NBMA) overlay virtual link manifested through encapsulation.
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 :::::)
`-(::::::::::::)-' `-(::::::::::::)-'
`-(::::::)-' `-(::::::)-'
Figure 1: MANET Internetworking
While the figure depicts just 2 MANET local routing regions, the NBMA
virtual link extends to include any other MANETs worldwide that want
to connect. Since a sustained increase in both the world population
and number of mobile wireless devices is certain, MANET
Internetworking must therefore scale to accommodate populations as
Templin & Jakubisin Expires 15 February 2027 [Page 4]
Internet-Draft MANET Internetworking August 2026
large as O(10**10) or more, i.e., even though there may be far fewer
active nodes at any moment in time. This includes address
duplication avoidance through operational assurance since statistical
properties alone may be insufficient to avoid duplication in such
large populations.
Since each MANET is a flexible mobile unit, its border routers may
continuously encounter different Internetwork access points as they
roam while potentially configuring a different IP address at each
access point. The MANET may also be subject to frequent partitions
and merges causing continuous changes in border router to client
associations. 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 a border router's
Internetwork connections change frequently.
The overlay network BGP routing system must similarly be protected
from mobility churn by maintaining address to Mobility Anchor Point
(MAP) 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 [RFC6437][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.
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 distribute the addresses of MAPs
which are stable nodes not subject to mobility dynamics. 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 peering arrangement of the MAPs and Gateways
in combination with dynamic updates to the (reverse) DNS resource
records that associate MLAs/MNPs with MAPs.
"IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem
Statement and Use Cases" [RFC9365] provides a complimentary analysis
but does not explore MANET-specific idiosyncrasies. This document
presents a MANET Internetworking problem statement and gap analysis.
Templin & Jakubisin Expires 15 February 2027 [Page 5]
Internet-Draft MANET Internetworking August 2026
2. Terminology
The following terms are defined within the scope of this document:
Client
a MANET router that connects a mobile network to a multilink
Internetworking service via Proxy/Servers in a Non-Broadcast,
Multiple Access (NBMA) overlay.
Gateway
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.
Internetwork
a stable wide-area terrestrial, non-terrestrial or hybrid backbone
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.
Internet Protocol (IP) Address
an IPv4 [RFC0791] or IPv6 [RFC8200] address assigned to an
interface of the node.
Media Access Control (MAC) Address
an IEEE EUI-48 or EUI-64 address, or an L2 address format specific
to another data link type.
Mobile Ad-hoc Network (MANET)
the same as defined in [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.
Each MANET can dynamically merge with others to form larger MANETs
or partition into multiple smaller MANETs where even a singleton
MANET router with no neighbors is considered a MANET unto itself.
This may present a challenge to the classical IP subnet model.
MANET Border Router
a MANET router that also has a continuous or intermittent
interface connection to a transit Internetwork.
Templin & Jakubisin Expires 15 February 2027 [Page 6]
Internet-Draft MANET Internetworking August 2026
MANET Cluster Head
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.
MANET Interface
a node's (typically wireless) limited range transmission media
interface with indeterminant connectivity properties.
MANET Router
a node that runs a routing protocol over one or more MANET
interfaces to establish multihop forwarding paths within a local
routing region.
Mobility Anchor Point (MAP)
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.
Mobile Network Prefix (MNP)
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.
Mobility Service Prefix (MSP)
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.
Multilink Local Address (MLA)
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. The MLA prefix
is configured as on-link on each node's overlay multilink
interface providing the appearance of an IP subnet shared by all
MANETs. A candidate MLA type appears in [RFC9374].
Templin & Jakubisin Expires 15 February 2027 [Page 7]
Internet-Draft MANET Internetworking August 2026
Proxy/Server
an overlay multilink network service node in an Internetwork that
provides proxy forwarding services to MANET border routers and
other MANET router Clients.
Relay
a Proxy/Server that supports forwarding between Clients connected
to the overlay and Internetwork correspondents.
virtual link
a Non-Broadcast, Multiple Access (NBMA) virtual overlay configured
over one or more Internetworks and their connected MANETs. The
virtual link itself constitutes an Internetworking limited domain
[RFC8799].
3. MANET Use Cases
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 multihop
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.
Templin & Jakubisin Expires 15 February 2027 [Page 8]
Internet-Draft MANET Internetworking August 2026
* 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.
4. MANET Internetworking Problem Statement
MANETs present a unique set of Internetworking challenges not
addressed by earlier works [RFC5889][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.
Templin & Jakubisin Expires 15 February 2027 [Page 9]
Internet-Draft MANET Internetworking August 2026
4.1. Problem 1: Mobility, Partitions and Merges
Unlike traditional fixed networks, MANETs are often mobile and
subject to frequent partitions and merges as nodes move with relation
both to one another and to Internetwork access points of opportunity.
A unified MANET that initially connects to Internetwork access point
A can at the next moment split into multiple partitions connecting to
Internetwork access points B, C, D etc. with each partition appearing
as its own separate multi-access link. These partitions may in the
future merge with partitions of other (original) MANETs in ways that
do no correspond uniformly to logical IP subnet boundaries.
Individual MANET routers can also move independently from a first
MANET to join another MANET, while MANET routers with no immediate
neighbors can be regarded as singleton MANETs unto themselves.
This means that the MANET cannot simply represent itself as an
aggregated logical IP subnet prefix at each Internetwork access point
since all nodes covered by the prefix may not necessarily reside
within the same partition. However, MANET nodes regard the MLA and
MSP prefixes as on-link prefixes on an overlay multilink network
interface configured over the MANET interfaces. This causes all
addresses covered by those prefixes to appear as on-link via the
overlay limited domain while only a (much) smaller subset appear
within a local MANET routing region.
Additionally, since each partition can transition quickly from a
first Internetwork access point connection to a diversity of
subsequent Internetwork connections it is essential that the MANET
border routers refrain from constantly injecting and withdrawing
mobile IP prefixes into the Internetwork routing system. MANET nodes
should instead obtain individual MNPs from an overlay network MAP
proxy/server which in turn maintains the MNPs within a scalable
overlay routing system.
4.2. Problem 2: Multilink Local Addressing
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. 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 address.
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
Templin & Jakubisin Expires 15 February 2027 [Page 10]
Internet-Draft MANET Internetworking August 2026
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.
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.
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: Section 1). 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%
[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 MLAs
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 MLAs as
potential duplicates.
Templin & Jakubisin Expires 15 February 2027 [Page 11]
Internet-Draft MANET Internetworking August 2026
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 attachment to the overlay NBMA link.
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.
In addition to MLAs, MANET routers must also configure L2 MAC
addresses on their MANET interfaces that are assured unique at least
within the MANET local routing region. IEEE MAC addresses can be
either administratively assigned according to an organizationally
unique identifier (OUI) with U/L set to "universal" or configured
through random generation with universal/local (U/L) bit set to
"local". 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.
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) [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.
4.3. Problem 3: Autoconfiguration
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.
MANET nodes that are (or may become) 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.) MANET
nodes also require a means of selecting specific border routers when
there are multiple candidates.
Templin & Jakubisin Expires 15 February 2027 [Page 12]
Internet-Draft MANET Internetworking August 2026
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 connected 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.
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 their MLAs 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.
Templin & Jakubisin Expires 15 February 2027 [Page 13]
Internet-Draft MANET Internetworking August 2026
4.4. Problem 4: MANET-local Communications
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.
Nodes within the MANET local routing region can discover the MLAs of
peers using services like Multicast DNS (mDNS) [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.
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.
MANETs can also 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
interface 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 prefixes that should appear on the overlay virtual
link are the MLA and MSP prefixes, since the overlay ensures
reachability for MLA/MNP addressed nodes whether they are located in
the local MANET routing region or in a different MANET routing region
reached via a border router's connection to the overlay.
4.5. Problem 5: MANET Peer to Internetwork Correspondent
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.
To initiate communications with an Internetwork correspondent, the
MANET peer first establishes per-flow on-demand virtual circuit state
in the overlay to an overlay-to-Internetwork relay beyond the MANET
Templin & Jakubisin Expires 15 February 2027 [Page 14]
Internet-Draft MANET Internetworking August 2026
border. MANET local multihop routing will then convey the peer's
original packets via the MANET border to the relay which directs them
to the Internetwork 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.
4.6. Problem 6: Internetwork Correspondent to MANET Peer
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 an Internetwork-to-overlay 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.5.
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. While mobility events may cause
minor temporary disruptions at lower layers, reliable transport
protocols will ensure upper layer session continuity.
4.7. Problem 7: Peer-to-Peer Between Different MANETs
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.6.
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
Templin & Jakubisin Expires 15 February 2027 [Page 15]
Internet-Draft MANET Internetworking August 2026
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 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.
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.
4.8. Problem 8: Stub MANET to Not-so-stubby MANET Connections
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.
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 the MANET
border router acting as 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 a globally-extended MANET Internetworking overlay.
5. MANET Internetworking Gap Analysis
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:
Templin & Jakubisin Expires 15 February 2027 [Page 16]
Internet-Draft MANET Internetworking August 2026
5.1. Gap 1: Multiple Heterogeneous MANET Interfaces
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.
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.
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.
5.2. Gap 2: Maximum Packet Size Diversity
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.
5.3. Gap 3: Header Compression
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.
Templin & Jakubisin Expires 15 February 2027 [Page 17]
Internet-Draft MANET Internetworking August 2026
L2- and L3-MANET solutions have different approaches to header
compression that may be better suited for some operational scenarios
than others (see: Appendix A). 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
multihop packet flows within the context of intended use cases.
5.4. Gap 4: MANET Border Router Discovery and Engagement
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.
5.5. Gap 5: MANET Internetworking Security
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.
6. MANET Internetworking Solution Proposal Analysis
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.
Templin & Jakubisin Expires 15 February 2027 [Page 18]
Internet-Draft MANET Internetworking August 2026
6.1. AERO/OMNI
6.2. NEMO (RFC3963)
6.3. LISP-based mobility and overlays
6.4. HIP mobility
6.5. DLEP-based MANET deployments with gatewaying
6.6. Conventional tunneling / prefix delegation approaches
7. IANA Considerations
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.
8. Security Considerations
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.
9. Acknowledgements
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, Henning Rogge, Jim Stevens and others who provided valuable
input.
10. References
10.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
Templin & Jakubisin Expires 15 February 2027 [Page 19]
Internet-Draft MANET Internetworking August 2026
10.2. Informative References
[RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501,
DOI 10.17487/RFC2501, January 1999,
<https://www.rfc-editor.org/info/rfc2501>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
DOI 10.17487/RFC4903, June 2007,
<https://www.rfc-editor.org/info/rfc4903>.
[RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET)
Extension of OSPF Using Connected Dominating Set (CDS)
Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009,
<https://www.rfc-editor.org/info/rfc5614>.
[RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing
Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
September 2010, <https://www.rfc-editor.org/info/rfc5889>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
[RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding",
RFC 6621, DOI 10.17487/RFC6621, May 2012,
<https://www.rfc-editor.org/info/rfc6621>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
Templin & Jakubisin Expires 15 February 2027 [Page 20]
Internet-Draft MANET Internetworking August 2026
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol Version 2",
RFC 7181, DOI 10.17487/RFC7181, April 2014,
<https://www.rfc-editor.org/info/rfc7181>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021,
<https://www.rfc-editor.org/info/rfc8966>.
[RFC9365] Jeong, J., Ed., "IPv6 Wireless Access in Vehicular
Environments (IPWAVE): Problem Statement and Use Cases",
RFC 9365, DOI 10.17487/RFC9365, March 2023,
<https://www.rfc-editor.org/info/rfc9365>.
[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
<https://www.rfc-editor.org/info/rfc9374>.
[RFC9663] Colitti, L., Linkova, J., Ed., and X. Ma, Ed., "Using
DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique
IPv6 Prefixes per Client in Large Broadcast Networks",
RFC 9663, DOI 10.17487/RFC9663, October 2024,
<https://www.rfc-editor.org/info/rfc9663>.
[STATISTA] Statista, S., "Number of connected devices worldwide as of
October 2025, by device,
https://www.statista.com/statistics/1559435/connected-
devices-worldwide", March 2026.
[WIKI] Wikipedia, W., "World population milestones,
https://en.wikipedia.org/wiki/
World_population_milestones", March 2026.
Templin & Jakubisin Expires 15 February 2027 [Page 21]
Internet-Draft MANET Internetworking August 2026
Appendix A. MANET Architectural Layering
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.
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
multihop paths. IP multicast transmissions only reach single-hop
neighbors which must engage an IP layer service such as Simplified
Multicast Forwarding (SMF) [RFC6621] to flood multicast messages to
all nodes in the MANET local routing region. Hop-by-hop IP state
(e.g., for header compression, flow bindings, etc.) must be
maintained at each MANET forwarding hop and may become invalidated
due to path changes.
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. Hop-by-hop IP state is
maintained only 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.
Since L3-MANETs proactively propagate IP host routes, multicast-based
address resolution services can often be satisfied by node-local
information thereby reducing dependence on MANET-wide multicast.
Multicast-based address resolution services for L2-MANETs can
similarly be minimized through proactive distribution of IP to MAC
address resolution information.
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
Templin & Jakubisin Expires 15 February 2027 [Page 22]
Internet-Draft MANET Internetworking August 2026
address resolution for both MANET-local nodes and target peers in
other networks reached via the overlay while avoiding multilink
subnet issues [RFC4903] since the overlay appears as a connected NBMA
link. MANET Internetworking concepts apply equally to both the
L3-MANET and L2-MANET models as discussed throughout the document.
Appendix B. Change Log
<< RFC Editor - remove prior to publication >>
Differences from -06 to -07:
* Clarified that cellphones can be regarded as *potential* MANET
routers even if they never enact that capability.
* Minimized touch-points for the L2/L3 discussion and moved the
MANET Layering section to an appendix.
Differences from -05 to -06:
* Clarified that problem #1 also includes mobility, and that an
isolated MANET router is regarded as a MANET unto itself.
* Editorial updates.
Differences from -04 to -05:
* Resolutions for some IETF126 comments.
* Introduced partitions and merges as #1 problem.
* Cited several important RFCs.
Differences from -02 to -04:
* Introduced distinction between L2/L3 MANETs.
* Supporting text added in response to list discussions.
Differences from -01 to -02:
* Expanded gap analysis.
Differences from -00 to -01:
* Updated based on list comments and private communications between
April-June 2026.
Templin & Jakubisin Expires 15 February 2027 [Page 23]
Internet-Draft MANET Internetworking August 2026
Differences from earlier versions:
* First draft publication.
Authors' Addresses
Fred L. Templin (editor)
The Boeing Company
P.O. Box 3707
Seattle, WA 98124
United States of America
Email: fltemplin@acm.org
Daniel J. Jakubisin
National Security Institute, Virginia Tech
2202 Kraft Dr.
Blacksburg, VA 24060
United States of America
Email: djj@vt.edu
Templin & Jakubisin Expires 15 February 2027 [Page 24]