| Internet-Draft | IPv6 MLAs | July 2024 |
| Templin | Expires 6 January 2025 | [Page] |
Ad Hoc networks present an interesting challenge for IPv6 addressing due to the indeterminant neighborhood properties of their interfaces. IPv6 nodes must assign IPv6 addresses to their multihop interface connections to Ad Hoc networks that are locally unique but must not be propagated to other networks. IPv6 nodes must therefore be able to assign self-generated addresses to their interfaces when there are no IPv6 Internetworking routers present that can coordinate topology-relative IPv6 addresses or prefixes. This document specifies a means for IPv6 nodes to generate and assign address types useful for Ad Hoc network communications.¶
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 6 January 2025.¶
Copyright (c) 2024 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.¶
When two or more IPv6 [RFC8200] nodes come together within an Ad Hoc network operating region (e.g., such as in a Mobile Ad-hoc NETwork (MANET)), they must be able to assign unique addresses, discover multihop routes and exchange IPv6 packets with peers even if there is no Internetworking infrastructure present.¶
Ad Hoc networks often include IPv6 nodes that configure interface connections to links with undetermined connectivity properties such that multihop traversal may be necessary to span the network. These same principles may apply for both wireless and wired-line communications. The transitive property of connectivity for conventional shared media links is therefore not assured, while IPv6 nodes must still be able to assign and use IPv6 addresses that are unique within the local Ad Hoc network. This is true even for nodes that configure multiple interface connections to the same Ad Hoc network as a localized multihop forwarding domain with multiple links.¶
By its nature, the term "Ad Hoc network" implies logical groupings whereas the historical term "site" suggested physical boundaries such as a building or a campus. In particular, Ad Hoc networks can self-organize amorphously even if they overlap with other (logical) Ad Hoc networks, split apart to form multiple smaller networks or join together to form larger networks. Clustering has been suggested as a means to organize these logical groupings, but Ad Hoc network ecosystems are often in a constant state of flux and likely to change over time. An address form that can be used by nodes that float freely between logical Ad Hoc network boundaries is therefore necessary.¶
The term "Ad Hoc" used throughout this document extends to include isolated localized IPv6 networks where peer to peer communications may require multihop traversal of multiple links whether or not the peers are particularly mobile or ad hoc. For any isolated Ad Hoc network (i.e., one for which IPv6 Internetworking routers are either absent or only intermittently available), a localized IPv6 addressing scheme that allows Ad Hoc nodes to communicate internally is necessary. Therefore, all IPv6 nodes that connect to Ad Hoc networks should be prepared to operate according to the Ad Hoc network multihop addressing model when necessary. The Ad Hoc network multihop forwarding service appears at an architectural sublayer termed the "adaptation layer" below the IPv6 Internetworking layer but above the true link layer. Multihop forwarding in Ad Hoc networks is therefore considered an adaptation layer service.¶
Section 6 of the "IP Addressing Model in Ad Hoc Networks" [RFC5889] states that: "an IP address configured on this (multihop) interface should be unique, at least within the routing domain" and: "no on-link subnet prefix is configured on this (multihop) interface". The 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 multihop forwarding domains.¶
[RFC5889] suggests that global [RFC4291] (aka "GUA") and unique-local [RFC4193] (aka "ULA") addresses are Ad Hoc network addressing candidates. However, provisioning of unique GUAs and ULAs must be coordinated either through administrative actions or through an automated address delegation service coordinated by IPv6 Internetworking routers that connect the Ad Hoc network to other networks. Since such routers may not always be available, this document asserts that new forms of self-generated and unique Ad Hoc network local IPv6 addresses are needed.¶
The key feature of these Ad Hoc network adaptation layer 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 include topologically-oriented prefixes, since the (newly-formed) Ad Hoc networks may not (yet) connect to any other Internetworking topologies.¶
Ad Hoc network nodes must be able to use adaptation layer IPv6 addresses for continuous local communications and/or to coordinate topologically-oriented addresses for assignment on other interfaces. A new "Multihop local" scope for the IPv6 scoped addressing architecture [RFC4007] with scope greater than link-local but lesser than global/unique-local unicast is therefore necessary.¶
This document defines a new unique local unicast address space known as "Multihop Local Addresses (MLAs)". MLAs use the formerly-deprecated IPv6 site-local prefix fec0::10 according to the address generation procedures specified herein. The document further discusses the utility of the Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) [RFC7343] and the Hierarchical Host Identity Tag / DRIP Entity Tag (HHIT/DET) specified in [RFC9374] for adaptation layer addressing purposes.¶
The term "multihop interface" refers to a node's IPv6 interface connection to an Ad Hoc network with undetermined connectivity properties where multiple adaptation layer forwarding hops between peers may be necessary.¶
The IPv6 addressing architecture specified in [RFC4007], [RFC4193] and [RFC4291] defines the supported IPv6 unicast/multicast/anycast address forms with various scopes including link- and site-local. 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 Ad Hoc networks.¶
ORCHIDv2 [RFC7343] provides an IPv6 address type that an Ad hoc network node can use for adaptation layer address self-generation instead of or in addition to MLAs. A related IPv6 address type known as the Hierarchical Host Identity Tag or DRIP Entity Tag (HHIT/DET)) [RFC9374] also provides a well-structured address format with exceptional uniqueness properties. A portion of the HHIT/DET includes a 64-bit hash of the node's ORCHIDv2 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. Hence, a fully self-generated MLA or ORCHIDv2 may be necessary in environments where an HHIT/DET cannot be used.¶
Multihop interface connections to Ad Hoc networks have the interesting property that a multihop router R will often need to forward packets between 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 multihop interfaces within a single Ad Hoc network 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 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 | +----------+-+-----------------------+----------------------------+
The node sets the first 10 bits of the MLA 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¶
After a node creates an MLA, it can use the address within the context of spontaneously-organized Ad Hoc networks in which two or more nodes come together in the absence of stable 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 multihop peers within an Ad Hoc network.¶
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.¶
IPv6 MLAs, ORCHIDs and/or HHIT/DETs have no topological orientation and can therefore be assigned to any of a node's IPv6 multihop interfaces with a /128 prefix length (i.e., as a singleton address). The node can then begin to use these adaptation layer addresses as the source/destination addresses of IPv6 packets that are forwarded over the interface within an Ad Hoc network multihop forwarding region. The node can assign the same adaptation layer address to multiple multihop interfaces all members of the same Ad Hoc network, but must assign a different address to the interfaces of each interface set connected to other Ad Hoc networks.¶
MLAs, ORCHIDs and HHIT/DETs may then serve as a basis for multihop forwarding over an IPv6 interface and/or for local neighborhood discovery over other IPv6 interface types. Due to their uniqueness properties, the node can assign these address types to a multihop interface without invoking pre-service Duplicate Address Detection (DAD), however it should deprecate an address if it detects in-service duplication.¶
Note: a node can also assign an adaptation layer address to the OMNI interface as well as to virtual interfaces linked to any of its non-Ad Hoc underlay interfaces as discussed in [I-D.templin-6man-omni3].¶
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 an Ad Hoc network is a coherent logical one based on time-varying (multihop) connectivity and not necessarily one constrained by physical boundaries. Especially in Ad Hoc networks that employ a proactive local routing protocol the list of available adaptation layer addresses in each network is continuously updated for temporal consistency.¶
For example, an IPv6 node may connect to multiple distinct Ad Hoc networks with a first set of multihop interfaces connected to network "A", a second set of interfaces connected to network "B", etc. According to the scoped IPv6 addressing architecture, the node would assign a separate adaptation layer address for each multihop interface set A, B, etc. and maintain separate Ad Hoc network multihop routing protocol instances for each set. Adaptation layer addresses A, B, etc. then become the router IDs for the separate routing protocol instances, but the IPv6 node may elect to redistribute discovered adaptation layer routes between the instances. The uniqueness properties of these adaptation layer addresses therefore transcends logical Ad Hoc network boundaries but without "leaking" into external networks.¶
A means for entering Ad Hoc network local IPv6 Zone Identifiers in user interfaces is necessary according to [I-D.ietf-6man-zone-ui]. Examples of an Ad Hoc network local unicast address qualified by a zone identifier are:¶
fee7:6c29:de12:4b74:884e:9d2a:73fc:2d94%netA (MLA)¶
2001:20:0a1c:1293:fef0:7983:cab0:1000%netB (ORCHIDv2)¶
2001:30:280:1405:a3ad:1952:ad0:a69e%netC (HHIT/DET)¶
The MLA 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".¶
IPv6 nodes assign MLA, ORCHIDv2 and/or HHIT/DET adaptation layer addresses to their IPv6 multihop interfaces for use only within the scope of locally connected Ad Hoc networks. These adaptation layer addresses can appear in Ad Hoc network multihop routing protocol control messages and can also appear as the source and destination addresses for IPv6 packets forwarded within the locally connected Ad Hoc networks. Adaptation layer cannot appear in the source or destination addresses for IPv6 packets forwarded beyond the locally connected Ad Hoc networks, however, where an IPv6 Globally-Unique (GUA) and possibly also a companion Unique-Local (ULA) address is necessary.¶
In order to support communications beyond the Ad Hoc local scope, each IPv6 node is required to obtain an IPv6 GUA/ULA pair through an IPv6 Internetworking border router or proxy that connects the Ad Hoc network to other networks. Since the border router/proxy may be multiple adaptation layer hops away, however, the IPv6 node configures and engages an Overlay Multilink Network (OMNI) Interface as specified in [I-D.templin-6man-omni3]. The IPv6 node assigns the GUA/ULA to the OMNI interface which forwards original packets by inserting an adaptation layer IPv6 encapsulation header that uses adaptation layer addresses as the source/destination addresses while the original packet uses GUAs/ULAs.¶
The IPv6 Internetworking border router/proxy may be configured as an IPv6-to-IPv6 Network Prefix Translation (NPTv6) gateway that 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]. The NPTv6 gateway will then statelessly translate each ULA into its corresponding GUA (and vice versa) for IPv6 packets that transit between the inside and outside domains.¶
The gateway provides service per the "ULA-Only" or "ULA+PA" [I-D.ietf-v6ops-ula-usage-considerations] connected network models. The IPv6 node can then use the ULA for local-scoped communications with internal peers and the GUA for global-scoped communications with external peers via the gateway as either a "NPTv6 translator" or "NPTv6 pass-through". IPv6 nodes can then select address pair combinations according to IPv6 default address selection rules [I-D.ietf-6man-rfc6724-update].¶
After receiving a ULA+PA GUA delegation, IPv6 nodes 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 IPv6 node 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".¶
"Default Address Selection for Internet Protocol Version 6 (IPv6)" [RFC6724] provides a policy table that specifies precedence values and preferred source prefixes for destination prefixes. "Preference for IPv6 ULAs over IPv4 addresses in RFC6724" [I-D.ietf-6man-rfc6724-update] updates the policy table entries for ULAs, IPv4 addresses and the 6to4 prefix (2002::/16).¶
This document proposes a further update to the policy table for IPv6 MLAs (prefix fec0::/10), ORCHIDv2s (prefix 2001:20::/28) and HHITs (prefix 2001:30::/28). The proposed updates appear in the table below:¶
draft-ietf-6man-rfc6724-update Updated
Prefix Precedence Label Prefix Precedence Label
::1/128 50 0 ::1/128 50 0
::/0 40 1 ::/0 40 1
::ffff:0:0/96 20 4 ::ffff:0:0/96 20 4
2002::/16 5 2 2002::/16 5 2
2001::/32 5 5 2001::/32 5 5
fc00::/7 30 13 fc00::/7 30 13
::/96 1 3 ::/96 1 3
fec0::/10 1 11 fec0::/10 2 11 (*)
3ffe::/16 1 12 3ffe::/16 1 12
2001:30::/28 4 14 (*)
2001:20::/28 3 14 (*)
(*) value(s) changed in update
With the proposed updates, these new adaptation layer address types appear as a lesser precedence than IPv6 GUAs, IPv6 ULAs and IPv4 addresses. Within this hierarchy, HHIT/DETs appear as a greater precedence than ORCHIDv2s which appear as a greater precedence than MLAs. IPv6 MLAs now appear as a greater precedence than deprecated IPv6 prefixes but a lesser precedence than all other address types.¶
IPv6 nodes MAY assign adaptation layer addresses to their multihop interface connections to Ad Hoc networks. If the node becomes aware that the address is already in use by another node, it instead generates and assigns a new adaptation layer address.¶
IPv6 multihop routers MAY forward IPv6 packets with adaptation layer source or destination addresses over multiple hops within the same Ad Hoc network as an adaptation layer function.¶
IPv6 Internetworking routers MUST NOT forward packets with adaptation layer source or destination addresses to a link outside the packet's Ad Hoc network of origin.¶
IPv6 Internetworking routers MUST NOT advertise the prefix fec0::/10 in routing protocol exchanges with correspondents outside the Ad Hoc network.¶
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.¶
In progress.¶
[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 "Multihop Local Unicast" and with RFC set to "[RFCXXXX]" (i.e., this document).¶
IPv6 MLAs include very large uniquely-assigned bit strings in both the prefix and interface identifier components which together provide strong uniqueness properties.¶
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 MLA duplication would be through either intentional or unintentional misconfiguration.¶
An IPv6 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.¶
Security considerations for HHIT/DETs are documented in [RFC9374].¶
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.¶
<< RFC Editor - remove prior to publication >>¶
Differences from earlier versions:¶
First draft publication.¶