Boeing Research & Technology

P.O. Box 3707 Seattle WA 98124 USA fltemplin@acm.org

I-D Internet-Draft 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 when there is no infrastructure present on the link 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).

When two or more IPv6 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 local-use addresses and exchange IPv6 packets even if there is no operator infrastructure present. The key feature of these local-use 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 local-use IPv6 addresses could then be used for continuous local-scoped communications and/or to bootstrap the assignment of topologically-oriented addresses under the IPv6 multi-addressing architecture . This document proposes a new unique local unicast address space known as MANET Local Addresses (MLAs). MLAs are distinguished by a reserved IPv6 prefix "P" as defined in this document which is used in conjunction with the Universally Unique Interface IDentifier (UUID) to form IPv6 addresses.

The IPv6 addressing architecture specified in and defines the supported IPv6 unicast/multicast/anycast address forms with various scopes ranging from link-local to unique-local to global. Unique-local and global-scoped unicast addresses are typically assigned through Stateless Address AutoConfiguration (SLAAC) and/or the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) , 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)) 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. 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 partitions. Due to these degenerate link properties, the 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 a DET/HHIT and/or other IPv6 unicast address types (noting again that a single interface may have multiple IPv6 addresses ). The address uses an n-bit IPv6 prefix "P" along with a (128-n)-bit interface identifier that includes the least-significant bits of a Universally Unique IDentifier (UUID) as shown in .

In this format, nodes can construct an MLA by first creating a self-generated UUID per the writing the n bits of P over the n most significant bits of the UUID. Due to the structure of the UUID which encodes a 4-bit Version code beginning at bit 48, n must be chosen to be no larger than 48, with the smallest value of n possible preferred in order to maintain maximum UUID resolution. Several alternatives have been proposed for the selection of P, including 1000::/4, 0f00::/8, a sub-prefix of 5f00::/8 and the ULA-C prefix fc00::/8 (see: ). An example IPv6 MLA using the ULA-C prefix plus the UUIDv4 format is shown in :

In this example, the node creates a 128-bit UUIDv4 per then simply replaces the most significant 8 bits with the constant string '11111100' (0xfc); the resulting 128-bit MLA then has the format of an IPv6 address with an 8-bit prefix and 120-bit interface identifier as permitted by the IPv6 addressing architecture. For example: fc84:6c29:de12:4b74:884e:9d2a:73fc:2d94::/8 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: while the MLA example specified above is relative to UUIDv4, the same format can be applied also to all other UUID versions specified in , i.e. by replacing the most significant n bits of the UUID with the n leading bits of P. New UUID version types are therefore advised to provide compatibility for this construction method.

IPv6 MLAs have no topological orientation and can therefore be assigned to any of a node's IPv6 interfaces. The addresses may 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 configure and assign a new IPv6 MLA if it later detects a duplicate through (in-service) DAD.

The list of candidates for use as MLA prefix P enumerated above were discussed thoroughly on the list, with various benefits and drawbacks noted for each. Returning to a debate from over 20 years ago, this document now proposes to reclaim the deprecated prefix "fec0::/10" for use as the MLA top-level prefix . The prefix (formerly known as the "Site-Local IPv6 Addresses") 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 recategorize as obsolete and update to reflect this new use for "fec0::/10".

IPv6 nodes MAY assign self-generated IPv6 MLAs to their interface connections to local networks (or MANETs). If the node later 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 prefix P to in routing protocol exchanges with correspondents outside the local network (or MANET). For this reason, the ULA-C prefix has the advantage that it is already scoped for local use.

In progress.

This document has no requirements for IANA.

TBD.

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 are expected to shape future versions of this document. The author acknowledges all those whose useful comments have helped further the understanding of this proposal. Kyzer Davis (RFC9562 author) is acknowledged for his review and comments that helped shape the document. Honoring life, liberty and the pursuit of happiness.

<< RFC Editor - remove prior to publication >> Differences from earlier versions: First draft publication.