Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology
Updates: rfc3879, rfc4007, rfc4291, rfc5889, 22 July 2024
rfc6724 (if approved)
Intended status: Standards Track
Expires: 23 January 2025
IPv6 Addresses for Ad Hoc Networks
draft-templin-6man-mla-16
Abstract
Ad Hoc networks often present an interesting environment for IPv6
addressing due to the indeterminant neighborhood properties of their
interfaces. IPv6 nodes must assign IPv6 addresses to their 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 IPv6
address types that can be assigned to Ad Hoc network interfaces.
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 23 January 2025.
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.
Templin Expires 23 January 2025 [Page 1]
Internet-Draft IPv6 MLAs July 2024
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 Ad Hoc Network Local Addressing . . . . . . . . . . . . 4
3. Assigning an MLA to an Interface . . . . . . . . . . . . . . 6
4. Reclaiming fec0::/10 . . . . . . . . . . . . . . . . . . . . 6
5. Obtaining and Assigning IPv6 GUAs/ULAs . . . . . . . . . . . 7
6. Address Selection . . . . . . . . . . . . . . . . . . . . . . 8
7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. ORCHIDv2 Addresses for Ad Hoc Networks . . . . . . . 13
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
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.
Templin Expires 23 January 2025 [Page 2]
Internet-Draft IPv6 MLAs July 2024
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)
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 type 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
multilink addressing model when necessary. The Ad Hoc network
multihop addressing and 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 (Ad Hoc) interface
should be unique, at least within the routing domain" and: "no on-
link subnet prefix is configured on this (Ad Hoc) 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 Ad Hoc network domains.
[RFC5889] suggests that Global Unicast [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.
Templin Expires 23 January 2025 [Page 3]
Internet-Draft IPv6 MLAs July 2024
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 "Multilink Local" scope for the IPv6 scoped addressing
architecture [RFC4007] with scope greater than link-local but lesser
than GUA/ULA is therefore necessary.
This document defines a new unique local unicast address variant
known as "Multilink Local Addresses (MLAs)". "Type-1" MLAs use the
formerly-deprecated IPv6 site-local prefix fec0::10 according to the
address generation procedures specified herein. "Type-2" MLAs
utilize the IPv6 prefix reserved for Overlay Routable Cryptographic
Hash Identifiers Version 2 (ORCHIDv2) [RFC7343], and "Type-3" MLAs
utilize the IPv6 prefix reserved for the Hierarchical Host Identity
Tag / DRIP Entity Tag (HHIT/DET) [RFC9374].
The term "multilink interface" refers to a node's IPv6 interface
connection to an Ad Hoc network with undetermined connectivity
properties where neighbor relationships appear as point-to-point
"links" and multiple adaptation layer forwarding hops between peers
may be necessary. However, the same principles apply for Ad Hoc
network interfaces with full neighborhood connectivity including
multiple access links such as Ethernet.
2. IPv6 Ad Hoc Network Local Addressing
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.
ULAs and GUAs 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 other MLA types. A related IPv6 address
type termed the Hierarchical Host Identity Tag or DRIP Entity Tag
(HHIT/DET)) [RFC9374] also provides a well-structured address format
Templin Expires 23 January 2025 [Page 4]
Internet-Draft IPv6 MLAs July 2024
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 type may be necessary
in environments where an HHIT/DET cannot be used.
Multilink 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 multilink interfaces within a single Ad
Hoc network that includes multiple distinct links/regions. Due to
these indeterminant multilink properties, exclusive use of IPv6 Link
Local Addresses (LLAs) is also out of scope.
This document therefore introduces MLA Type-1 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. MLA Type-1
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 |
+----------+-+-----------------------+----------------------------+
Figure 1: IPv6 MLA Type-1 Format
The node sets the first 10 bits of the Type-1 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 Type-1 MLA then has the proper
format of an IPv6 address with a 64-bit "prefix" followed by a 64-bit
interface identifier per the IPv6 addressing architecture. For
example:
Templin Expires 23 January 2025 [Page 5]
Internet-Draft IPv6 MLAs July 2024
fee7:6c29:de12:4b74:884e:9d2a:73fc:2d94
After a node creates a Type-1 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 address generation procedures apply when the L bit is
set to 1; generation procedures for L=0 may be specified by future
documents.
3. Assigning an MLA to an Interface
IPv6 Type-1, Type-2 and Type-3 MLAs have no topological orientation
and can therefore be assigned to any of a node's IPv6 multilink
interfaces with a /128 prefix length (i.e., as a singleton address).
The node can then begin to use these MLAs 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 MLA to multiple multilink 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 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 multilink interface as optimistic
addresses per [RFC4429], however it should deprecate an MLA if it
detects in-service duplication.
Note: a node can also assign an MLA to the OMNI interface as
discussed in [I-D.templin-6man-omni3].
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
Type-1 MLA top-level prefix. [RFC3879] documents the deprecation
rationale 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
Templin Expires 23 January 2025 [Page 6]
Internet-Draft IPv6 MLAs July 2024
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 multilink 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 MLA for each multilink interface set A, B,
etc. and maintain separate Ad Hoc network multihop routing protocol
instances for each set. MLAs 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 MLAs 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 (Type-1)
2001:20:280:1405:a3ad:1952:ad0:a69e%netB (Type-2)
2001:30:5efe:2018:c63d:9724:fca:1237%netC (Type-3)
The MLA Type-1 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
IPv6 nodes assign MLAs to their IPv6 multilink interfaces for use
only within the scope of locally connected Ad Hoc networks. These
MLAs 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. MLAs cannot appear in the source or destination for IPv6
packets forwarded beyond the locally connected Ad Hoc networks,
however, where an IPv6 GUA and possibly also a companion ULA address
is necessary.
Templin Expires 23 January 2025 [Page 7]
Internet-Draft IPv6 MLAs July 2024
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
MLAs as 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".
6. Address Selection
"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).
Templin Expires 23 January 2025 [Page 8]
Internet-Draft IPv6 MLAs July 2024
This document proposes a further update to the policy table for IPv6
Type-1 (prefix fec0::/10), Type-2 (prefix 2001:20::/28) and Type-3
(prefix 2001:30::/28) MLAs. 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
Figure 2: Policy Table Update for Multilink Local Addresses
With the proposed updates, these new MLA types appear as a lesser
precedence than IPv6 GUAs, IPv6 ULAs and IPv4 addresses. Within this
hierarchy, Type-3 MLAs appear as a greater precedence than Type-2's
which appear as a greater precedence than Type-1's. Type-1 MLAs now
appear as a greater precedence than deprecated IPv6 prefixes but a
lesser precedence than all other address types.
7. Requirements
IPv6 nodes MAY assign MLAs to their multilink 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 MLA.
IPv6 multihop routers MAY forward IPv6 packets with MLA 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 MLA source
or destination addresses to a link outside the packet's Ad Hoc
network of origin.
IPv6 Internetworking routers MUST NOT advertise MLA prefixes in
routing protocol exchanges with correspondents outside the Ad Hoc
network.
Templin Expires 23 January 2025 [Page 9]
Internet-Draft IPv6 MLAs July 2024
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.
8. Implementation Status
In progress.
9. 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 "Multilink
Local Unicast - Type-1" and with RFC set to "[RFCXXXX]" (i.e., this
document).
10. Security Considerations
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 generation procedures specified in for the various
MLA types, 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.
Additional security considerations for MLA Type-2 are documented in
[RFC7343] and for MLA Type-3 appear in [RFC9374].
11. Acknowledgements
This work was inspired by continued investigations into 5G MANET
operations in cooperation with the Virginia Tech National Security
Institute (VTNSI).
Templin Expires 23 January 2025 [Page 10]
Internet-Draft IPv6 MLAs July 2024
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.
12. References
12.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>.
[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>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[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>.
12.2. Informative References
Templin Expires 23 January 2025 [Page 11]
Internet-Draft IPv6 MLAs July 2024
[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, "Prioritizing
known-local IPv6 ULAs through address selection policy",
Work in Progress, Internet-Draft, draft-ietf-6man-rfc6724-
update-09, 28 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
rfc6724-update-09>.
[I-D.ietf-6man-zone-ui]
Carpenter, B. E. and R. M. Hinden, "Entering IPv6 Zone
Identifiers in User Interfaces", Work in Progress,
Internet-Draft, draft-ietf-6man-zone-ui-00, 27 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
zone-ui-00>.
[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>.
[I-D.templin-6man-aero3]
Templin, F., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin-
6man-aero3-10, 25 June 2024,
<https://datatracker.ietf.org/doc/html/draft-templin-6man-
aero3-10>.
[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-10, 25 June 2024,
<https://datatracker.ietf.org/doc/html/draft-templin-6man-
omni3-10>.
[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>.
Templin Expires 23 January 2025 [Page 12]
Internet-Draft IPv6 MLAs July 2024
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<https://www.rfc-editor.org/info/rfc4429>.
[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>.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September
2014, <https://www.rfc-editor.org/info/rfc7343>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>.
[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. ORCHIDv2 Addresses for Ad Hoc Networks
The Host Identity Protocol Version 2 (HIPv2) [RFC7401] specifies
constant values for the ORCHIDv2 generation algorithm to produce Host
Identity Tags (HITs) for use by the HIP protocol. For further study
is whether these same constant values can be used for generation of
ORCHIDv2s intended for assignment to Ad Hoc network interfaces or
whether an alternate set of constant values is necessary.
Appendix B. Change Log
<< RFC Editor - remove prior to publication >>
Differences from earlier versions:
* First draft publication.
Templin Expires 23 January 2025 [Page 13]
Internet-Draft IPv6 MLAs July 2024
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
United States of America
Email: fltemplin@acm.org
Templin Expires 23 January 2025 [Page 14]