IPv6 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 25 November 2024.¶

Copyright Notice

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.¶

Table of Contents

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 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 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 assignment of topologically-oriented addresses under the IPv6 multi-addressing architecture [RFC4291]. 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 assigned 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 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 a new fully-self-generated IPv6 unicast address format known as the MANET Local Address (MLA) that can be used either instead of or in addition to other IPv6 unicast address types (noting again that a single interface may have multiple IPv6 addresses [RFC4291]). The address uses 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         |
   +----------+-+-----------------------+----------------------------+

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¶

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. 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.¶

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 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] and [RFC4291] to reflect this new use for "fec0::/10".¶

5. 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.¶

6. Implementation Status

In progress.¶

7. 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).¶

8. 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.¶

9. 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.¶

Author's Address