Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology
Updates: rfc3879, rfc4007, rfc4291, rfc5889 (if 29 May 2024
approved)
Intended status: Standards Track
Expires: 30 November 2024
IPv6 MANET Local Addresses (MLAs)
draft-templin-6man-mla-06
Abstract
Mobile Ad-hoc NETworks (MANETs) present an interesting challenge for
IPv6 addressing due to the indeterminant neighborhood properties of
MANET interfaces. MANET routers must assign an IPv6 address to each
MANET interface that is both unique and routable within the MANET but
must not be forwarded to other networks. MANET routers must be able
to assign self-generated addresses to their MANET interfaces when
there is no infrastructure present that can delegate topology-
relative IPv6 addresses or prefixes. This document therefore
specifies a means for MANET routers to generate and assign MANET
Local Addresses (MLAs).
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 30 November 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Templin Expires 30 November 2024 [Page 1]
Internet-Draft IPv6 MLAs May 2024
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IPv6 MANET Local Addresses (MLAs) . . . . . . . . . . . . . . 3
3. Assigning IPv6 MLAs to an Interface . . . . . . . . . . . . . 5
4. Reclaiming fec0::/10 . . . . . . . . . . . . . . . . . . . . 5
5. Obtaining and Assigning IPv6 GUAs/ULAs . . . . . . . . . . . 6
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
When two or more IPv6 [RFC8200] nodes come together within a common
local operating region (e.g., during the formation of a Mobile Ad-hoc
Network (MANET)), they must be able to assign unique addresses,
discover multihop routes and exchange IPv6 packets with local network
peers over their MANET interfaces even if there is no operator
infrastructure present.
MANETs consist of routers that configure interfaces to links with
undetermined connectivity, in particular where the transitive
property of connectivity for traditional shared links is not assured.
MANET routers must nonetheless assign and use IPv6 addresses that are
unique within the MANET. This is true even for nodes that configure
multiple interface connections to the same MANET as a multilink
routing domain.
Section 6 of the "IP Addressing Model in Ad Hoc Networks" [RFC5889]
states that: "an IP address configured on this (MANET) interface
should be unique, at least within the routing domain" and: "no on-
link subnet prefix is configured on this (MANET) interface". The
Templin Expires 30 November 2024 [Page 2]
Internet-Draft IPv6 MLAs May 2024
section then continues to explain why IPv6 Link-Local Addresses
(LLAs) are of limited utility on links with undetermined
connectivity, to the point that they cannot be used exclusively
within multilink routing domains.
[RFC5889] suggests that global [RFC4291] (aka "GUA") and unique-local
[RFC4193] (aka "ULA") addresses are MANET addressing candidates.
However, assignment of unique GUAs and ULAs must be coordinated
either through administrative actions or through an automated address
delegation service that all MANET routers can access. This document
asserts that a new form of self-generated and unique MANET-local IPv6
addresses is needed.
The key feature of these MANET-local IPv6 addresses is that they must
be assured unique so that there is no chance of conflicting with an
address assigned by another node. There is no requirement that the
addresses have topologically-oriented prefixes, since the (newly-
formed) local network may not (yet) connect to any other
Internetworking topologies.
The MANET-local IPv6 addresses could then be used for continuous
MANET-local communications and/or to bootstrap the delegation of
topologically-oriented addresses for assignment on other interfaces.
This would also manifest a new "MANET-local" scope for the IPv6
scoped addressing architecture [RFC4007] with scope greater than
link-local but lesser than global/unique-local unicast.
This document proposes a new unique local unicast address space known
as "MANET Local Addresses (MLAs)". MLAs use the formerly-deprecated
IPv6 site-local prefix fec0::10 according to the address generation
procedures specified in this document.
2. IPv6 MANET Local Addresses (MLAs)
The IPv6 addressing architecture specified in [RFC4291], [RFC4193]
and [RFC4007] defines the supported IPv6 unicast/multicast/anycast
address forms with various scopes including link-local, site-local
and others. Unique-local and global unicast addresses are typically
obtained through Stateless Address AutoConfiguration (SLAAC)
[RFC4862] and/or the Dynamic Host Configuration Protocol for IPv6
(DHCPv6) [RFC8415], but these services require the presence of IPv6
network infrastructure which may not be immediately available in
spontaneously-formed MANETs or other isolated local networks.
A new IPv6 address type known as the DRIP Entity Tag (DET) (or,
Hierarchical Host Identity Tag (HHIT)) [RFC9374] provides a well-
structured address format with exceptional uniqueness properties. A
portion of the address includes the node's self-generated Overlay
Templin Expires 30 November 2024 [Page 3]
Internet-Draft IPv6 MLAs May 2024
Routable Cryptographic Hash IDentifier (ORCHID) while the remainder
of the address includes a well-formed IPv6 prefix plus bits
corresponding to an attestation service that supports address proof-
of-ownership. Verification of the attestation aspect of the address
requires access to network infrastructure, but this may not always be
available. Furthermore, [RFC9374] provides no guidance for
assignment of a DET/HHIT to an interface nor any evidence that they
could be used as the source/destination addresses of IPv6 packets.
MANET interfaces have the interesting property that a MANET router R
will often need to forward packets between MANET nodes A and B even
though R uses the same interface in the inbound and outbound
directions. Since nodes A and B may not be able to communicate
directly even though both can communicate directly with R, the link
connectivity property is intransitive and the IPv6 Neighbor Discovery
(ND) Redirect service cannot be used. Conversely, R may need to
forward packets between nodes A and B via different MANET interfaces
within a single MANET that includes multiple distinct links/regions.
Due to these indeterminant (multi-)link properties, exclusive use of
IPv6 Link Local Addresses (LLAs) is also out of scope.
This document therefore introduces the MLA as a new fully self-
generated IPv6 unicast address type that can be used either instead
of or in addition to other IPv6 unicast address types. MLAs use the
formerly-deprecated Site-Local IPv6 Address prefix fec0::10 according
to the modified format shown in Figure 1:
| 10 bits |1| 53 bits | 64 bits |
+----------+-+-----------------------+----------------------------+
|1111111011|L| subnet ID | interface ID |
+----------+-+-----------------------+----------------------------+
Figure 1: IPv6 MANET Local Address (MLA) Format
In this format, the node sets the first 10 bits of the address to the
constant string '1111111011' then sets the 11th bit (i.e., the
"(L)ocal" bit) to 1. The node next sets subnet ID to a 53 bit random
value calculated the same as specified in Section 3.2.1 of [RFC4193]
for the Unique Local Address Global ID.
The node finally generates and assigns a semantically opaque
interface ID based on this self-generated prefix as specified in
[RFC7217]; the resulting 128-bit MLA then has the proper format of an
IPv6 address with a 64-bit "prefix" followed by a 64-bit interface
identifier as required by the IPv6 addressing architecture. For
example:
fee7:6c29:de12:4b74:884e:9d2a:73fc:2d94
Templin Expires 30 November 2024 [Page 4]
Internet-Draft IPv6 MLAs May 2024
After a node creates an MLA, it can use the address within the
context of spontaneously-organized local networks in which two or
more nodes come together in the absence of supporting infrastructure
and can still exchange IPv6 packets with little or no chance of
address collisions. The use could be limited to bootstrapping the
assignment of topologically correct IPv6 addresses through other
means mentioned earlier, or it could extend to longer term usage
patterns such as sustained communications with single-hop neighbors
on a local link or even between multi-hop peers within a MANET.
Note: the above MLA generation procedures apply when the L bit is set
to 1; MLA generation procedures for L=0 may be specified by future
documents.
3. Assigning IPv6 MLAs to an Interface
IPv6 MLAs have no topological orientation and can therefore be
assigned to any of a node's IPv6 interfaces with a /128 prefix (i.e.,
as a singleton address). The node can then begin to use MLAs as the
source/destination addresses of IPv6 packets that are forwarded over
the interface within a local routing region. The node can assign the
same MLA to multiple interfaces all members of the same MANET, but
must assign a different MLA to the interfaces of each interface set
connected to different MANETs.
MLAs may then serve as a basis for multihop forwarding over a MANET
interface and/or for local neighborhood discovery over other IPv6
interface types. Due to their uniqueness properties, the node can
assign an IPv6 MLA to an interface without invoking (pre-service)
Duplicate Address Detection (DAD), however it should deprecate the
MLA and assign a new IPv6 MLA if it detects a duplicate through (in-
service) DAD.
4. Reclaiming fec0::/10
Returning to a debate from more than 20 years ago, this document now
proposes to reclaim the deprecated prefix "fec0::/10" for use as the
MLA top-level prefix. [RFC3879] documents the reasons for
deprecation including the assertion that "Site is an Ill-Defined
Concept". However, the concept of a MANET is a logical one and not
necessarily one constrained by physical boundaries.
For example, a MANET router may connect to multiple distinct MANETs
with a first set of interfaces connected to MANET "A", a second set
of interfaces connected to MANET "B", etc. According to the scoped
IPv6 addressing architecture, the router would assign a separate MLA
for each interface set A, B, etc. and maintain separate MANET routing
protocol instances for each set. MLAs A, B, etc. then become the
Templin Expires 30 November 2024 [Page 5]
Internet-Draft IPv6 MLAs May 2024
router IDs for the separate routing protocol instances, but the MANET
router may elect to redistribute discovered MLA routes between the
instances. The uniqueness property of MLAs therefore transcends
logical MANET boundaries but without "leaking" into external
networks.
The prefix (formerly known as "Site-Local") has the distinct
advantage that it is reserved and available for reclamation by a
future standards track publication, for which this document
qualifies. Upon publication as a standards track RFC, the RFC Editor
is instructed to update [RFC3879], [RFC4007], [RFC4291] and [RFC5889]
to reflect this new use for "fec0::/10".
5. Obtaining and Assigning IPv6 GUAs/ULAs
MANET routers assign MLAs to their MANET interfaces for use only
within the scope of their locally connected MANETs. MLAs are carried
in MANET routing protocol control messages and can also appear as the
source and destination addresses for IPv6 packets forwarded within
the locally connected MANETs. MLAs cannot appear in the source or
destination addresses for IPv6 packets forwarded beyond the locally
connected MANETs, however, where an IPv6 Globally-Unique (GUA) and
possibly also a companion Unique-Local (ULA) address is necessary.
In order to support global-scope communications, each MANET router is
required to obtain an IPv6 GUA through a border router/proxy that
connects the MANET to the global IPv6 Internet. Since the proxy may
be multiple MANET hops away, however, the MANET router configures and
engages an Overlay Multilink Network (OMNI) Interface as specified in
[I-D.templin-6man-omni3]. The MANET router assigns the GUA to the
OMNI interface which forwards original packets by inserting an IPv6
encapsulation header that uses MLAs as the source/destination
addresses while the original packet uses GUAs.
The proxy may be configured as an IPv6-to-IPv6 Network Prefix
Translation (NPTv6) gateway that connects the rest of the MANET to
the outside Internet. In that case, the proxy supplies each MANET
router with a ULA internally and maintains a 1:1 relationship between
the ULA on the "inside" and a GUA on the "outside" as discussed in
[I-D.bctb-6man-rfc6296-bis]. Each MANET router will then assign the
ULA to its OMNI interface which encapsulates each original packet in
an IPv6 header that uses MLAs as the encapsulation source/destination
addresses while the original packet uses ULAs/GUAs. The NPTv6
gateway will then statelessly translate each ULA into its
corresponding GUA (and vice versa) for packets that transit the
proxy.
Templin Expires 30 November 2024 [Page 6]
Internet-Draft IPv6 MLAs May 2024
The proxy delegates a ULA and its companion Provider-Aggregated (PA)
GUA for each MANET router which assigns them according to either the
"ULA+PA" or "ULA-Only" connected network models
[I-D.ietf-v6ops-ula-usage-considerations]. If the MANET router
employs the "ULA+PA" model, it can assign both the ULA and GUA to the
OMNI interface. The MANET router can then use the ULA for local-
scoped communications with peers inside the MANET and the GUA for
global-scoped communications with external peers via the proxy as a
"NPTv6 pass-through". MANET routers can then select address pair
combinations according to IPv6 default address selection rules
[I-D.ietf-6man-rfc6724-update].
After receiving a ULA plus PA GUA delegation, MANET routers that
require Provider-Independent (PI) GUAs can use the OMNI interface in
conjunction with the Automatic Extended Route Optimization (AERO)
global distributed mobility management service
[I-D.templin-6man-aero3] to request and maintain IPv6 and/or IPv4 PI
prefixes from the mobility service. The MANET router can then sub-
delegate GUAs from the PI prefixes to its attached downstream local
networks which may in turn engage an arbitrarily large IPv6 and/or
IPv4 "Internet of Things".
6. Requirements
IPv6 nodes MAY assign self-generated IPv6 MLAs to their interface
connections to local networks (or MANETs). If the node becomes aware
that the address is already in use by another node, it instead
generates and assigns a new MLA.
IPv6 routers MAY forward IPv6 packets with MLA source or destination
addresses over multiple hops within the same local network (or
MANET).
IPv6 routers MUST NOT forward packets with MLA source or destination
addresses to a link outside the packet's local network (or MANET) of
origin.
IPv6 routers MUST NOT advertise the prefix fec0::/10 in routing
protocol exchanges with correspondents outside the local network (or
MANET).
The default behavior of exterior routing protocol sessions between
administrative routing regions must be to ignore receipt of and not
advertise prefixes in the fee0::/11 block.
At the present time, AAAA and PTR records for MLAs in the fee0::/11
block are not recommended to be installed in the global DNS.
Templin Expires 30 November 2024 [Page 7]
Internet-Draft IPv6 MLAs May 2024
7. Implementation Status
In progress.
8. IANA Considerations
[RFC3879] instructed IANA to mark the FEC0::/10 prefix as
"deprecated", and as such it does not appear in the IANA IPv6
Special-Purpose Address Registry.
Upon publication, IANA is instructed to add the prefix FEC0::/10 to
the 'iana-ipv6-special-registry' registry with the name "MANET-Local
Unicast" and with RFC set to "[RFCXXXX]" (i.e., this document).
9. Security Considerations
IPv6 MLAs include very large uniquely-assigned bit strings in both
the prefix and interface identifier components. With the random
prefix generation procedures specified in [RFC4193] and the
semantically opaque interface identifier generation procedures
specified in [RFC7217] the only apparent opportunity for address
duplication would be through either intentional or unintentional
misconfiguration. A node that generates an MLA and assigns it to an
interface should therefore be prepared to deprecate the MLA and
generate/assign a new one if it detects a legitimate duplicate.
10. Acknowledgements
This work was inspired by continued investigations into 5G MANET
operations in cooperation with the Virginia Tech National Security
Institute (VTNSI).
Emerging discussions on the IPv6 maintenance (6man) mailing list
continue to shape updated versions of this document. The author
acknowledges all those whose useful comments have helped further the
understanding of this proposal.
Honoring life, liberty and the pursuit of happiness.
11. References
11.1. Normative References
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005,
<https://www.rfc-editor.org/info/rfc4007>.
Templin Expires 30 November 2024 [Page 8]
Internet-Draft IPv6 MLAs May 2024
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[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>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[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>.
11.2. Informative References
[I-D.bctb-6man-rfc6296-bis]
Cullen, M., Baker, F., Trøan, O., and N. Buraglio, "RFC
6296bis IPv6-to-IPv6 Network Prefix Translation", Work in
Progress, Internet-Draft, draft-bctb-6man-rfc6296-bis-02,
26 January 2024, <https://datatracker.ietf.org/doc/html/
draft-bctb-6man-rfc6296-bis-02>.
[I-D.ietf-6man-rfc6724-update]
Buraglio, N., Chown, T., and J. Duncan, "Preference for
IPv6 ULAs over IPv4 addresses in RFC6724", Work in
Progress, Internet-Draft, draft-ietf-6man-rfc6724-update-
08, 9 April 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-6man-rfc6724-update-08>.
[I-D.ietf-v6ops-ula-usage-considerations]
Jiang, S., Liu, B., and N. Buraglio, "Considerations For
Using Unique Local Addresses", Work in Progress, Internet-
Draft, draft-ietf-v6ops-ula-usage-considerations-04, 17
May 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-v6ops-ula-usage-considerations-04>.
Templin Expires 30 November 2024 [Page 9]
Internet-Draft IPv6 MLAs May 2024
[I-D.templin-6man-aero3]
Templin, F., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin-
6man-aero3-04, 22 May 2024,
<https://datatracker.ietf.org/doc/html/draft-templin-6man-
aero3-04>.
[I-D.templin-6man-omni3]
Templin, F., "Transmission of IP Packets over Overlay
Multilink Network (OMNI) Interfaces", Work in Progress,
Internet-Draft, draft-templin-6man-omni3-04, 22 May 2024,
<https://datatracker.ietf.org/doc/html/draft-templin-6man-
omni3-04>.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, DOI 10.17487/RFC3879, September
2004, <https://www.rfc-editor.org/info/rfc3879>.
[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>.
[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>.
[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>.
Appendix A. Change Log
<< RFC Editor - remove prior to publication >>
Differences from earlier versions:
* First draft publication.
Author's Address
Templin Expires 30 November 2024 [Page 10]
Internet-Draft IPv6 MLAs May 2024
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
United States of America
Email: fltemplin@acm.org
Templin Expires 30 November 2024 [Page 11]