Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology
Updates: rfc4007, rfc5889, rfc6724 (if approved) 3 April 2025
Intended status: Standards Track
Expires: 5 October 2025
IPv6 Addresses for Ad Hoc Networks
draft-templin-6man-mla-27
Abstract
Ad Hoc networks present an IPv6 addressing challenge due to the
undetermined neighborhood properties of their interfaces. IPv6 nodes
assign IPv6 addresses to their Ad Hoc networks that must be locally
unique. IPv6 nodes must therefore be able to assign topology-
independent addresses when topology-oriented IPv6 address delegation
services are either absent or only intermittently available. This
document introduces a new IPv6 address type that nodes can
autonomously assign for use over Ad-Hoc networks.
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 5 October 2025.
Copyright Notice
Copyright (c) 2025 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
Templin Expires 5 October 2025 [Page 1]
Internet-Draft IPv6 MLAs April 2025
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 . . . . . . . . . . . . . . 5
4. MLAs in the Scoped Addressing Architecture . . . . . . . . . 6
5. MLAs for Ad Hoc Networks . . . . . . . . . . . . . . . . . . 7
6. Obtaining and Assigning IPv6 ULAs/GUAs . . . . . . . . . . . 7
7. Address Selection . . . . . . . . . . . . . . . . . . . . . . 8
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 10
13.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
When two or more IPv6 [RFC8200] nodes come together to form an Ad Hoc
network, they must be able to assign unique addresses and exchange
IPv6 packets with peers even if there is no Internetworking
infrastructure present. A classical example is a Mobile Ad-hoc
Network (MANET) where wireless nodes within a common radio frequency
locality discover multihop routes to support peer-to-peer
communications. However, arbitrary collections of fixed nodes
interconnected by sparse collections of physical links are also
examples. See [RFC5889] for further characteristics of Ad Hoc
networks.
Ad Hoc networks often include IPv6 nodes that configure interface
attachments to links with undetermined connectivity properties such
that multihop traversal may be necessary to span the network. The
transitive property of connectivity for conventional shared media
links is therefore not assured, while nodes must still be able to
configure IPv6 addresses that are unique within the local Ad Hoc
network. This is true even for nodes that configure multiple
interface attachments to the same Ad Hoc network as a localized
multihop/multilink forwarding domain.
Templin Expires 5 October 2025 [Page 2]
Internet-Draft IPv6 MLAs April 2025
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 local IPv6 networks where peer to peer communications may
require multihop and/or multilink traversal regardless of whether the
network is particularly mobile or spontaneously organized. For any
such isolated network (i.e., one for which IPv6 Internetworking
proxy/servers are either absent or only intermittently available), a
topology-independent IPv6 addressing scheme that allows peer nodes to
communicate internally is necessary. Therefore, all nodes that
connect to such isolated IPv6 networks should be prepared to operate
according to this multilink Ad Hoc addressing model when necessary.
Each node then coordinates multihop forwarding services at an
IPv6-based architectural sublayer termed the "adaptation layer" below
the Internetworking layer but above the true link layer.
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. (Note that [RFC5498] provides IANA
allocations for MANET protocols as a complementary publication.)
Templin Expires 5 October 2025 [Page 3]
Internet-Draft IPv6 MLAs April 2025
[RFC5889] suggests Global Unicast [RFC4291] (aka "GUA") and Unique-
Local [RFC4193] (aka "ULA") addresses as Ad Hoc network addressing
candidates. However, GUAs and ULAs are topology-oriented address
types that must be obtained through either administrative actions or
an address autoconfiguration service based on IPv6 proxy/servers that
connect the Ad Hoc network to a larger Internetwork. (In particular
topology-oriented address types are typically obtained through DHCPv6
messages and/or Router Advertisement Prefix Information Options with
prefix length shorter than 128.) Since such Internetworking services
may not always be available, however, this document asserts that a
topology-independent and unique Ad Hoc network local IPv6 address
type is needed. The address type may include multiple sub-types,
some of which may be coordinated with address registration services
and others that may be partially or fully self-generated.
The key feature of these Ad Hoc network adaptation layer IPv6
addresses is that they must have excellent statistical uniqueness
properties such that there is little/no chance of conflicting with an
address assigned by another node. The addresses need not include
topology-oriented prefixes, since the (newly-formed) Ad Hoc networks
may not (yet) connect to established Internetworking topologies.
Ad Hoc network nodes must be able to use adaptation layer IPv6
addresses for continuous local communications and/or to coordinate
topology-oriented addresses for assignment on other interfaces. A
new "Multilink Local" scope for the IPv6 scoped addressing
architecture [RFC4007] with scope greater than LLA but lesser than
ULA/GUA is therefore needed. This document therefore defines a new
unique local unicast address variant known as "Multilink Local
Addresses (MLAs)".
Candidate MLA examples are found in [RFC7343][RFC9374][RFC9602]. The
IPv6 address assignment policy is clarified in
[I-D.ietf-6man-addr-assign].
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 types with various scopes. 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
Internetworking infrastructure which may not be continuously or
intermittently available in spontaneously-formed Ad Hoc networks.
Templin Expires 5 October 2025 [Page 4]
Internet-Draft IPv6 MLAs April 2025
Interface attachments 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 transitive property for link connectivity does not apply
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 interfaces within an Ad Hoc network that includes multiple
distinct links/regions. Due to these indeterminant multilink
properties, exclusive use of IPv6 LLAs is also out of scope.
This document therefore introduces a new IPv6 MLA address type based
on one or more well-formed IPv6 prefixes "TBD::/N" (see IANA
Considerations). 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 node can limit MLA
usage to bootstrapping the assignment of topology-oriented IPv6
addresses through other means mentioned earlier. The node can
instead extend its MLA usage to longer term patterns such as
sustained communications with single-hop neighbors on a local link or
even between Ad Hoc network multihop peers.
3. Assigning an MLA to an Interface
IPv6 MLAs are topology-independent and can therefore be assigned to a
virtual interface of the node with a /128 prefix length (i.e., as a
singleton address). The node can then begin to use an MLA as the
Source/Destination Address of IPv6 packets that are forwarded over an
interface attachment to an Ad Hoc network multihop forwarding region.
A node can specifically assign an MLA to a loopback interface to
support the operation of an Ad Hoc network routing protocol while
also assigning the MLA to an Overlay Multilink Network (OMNI)
Interface [I-D.templin-6man-omni3]. In that case, MLAs can support
extended communications with remote peers over the OMNI link overlay
network.
MLAs may then serve as a basis for multihop forwarding and/or for
local neighborhood discovery over other IPv6 interface types. Due to
their uniqueness properties, the node can assign MLAs as optimistic
addresses per [RFC4429], however it should take actions to deconflict
if it detects in-service duplication.
Templin Expires 5 October 2025 [Page 5]
Internet-Draft IPv6 MLAs April 2025
4. MLAs in the Scoped Addressing Architecture
With reference to a debate that concluded in the earliest years of
the third millennium, a case could be made for reclaiming the
deprecated site-local address prefix "fec0::/10" for use as a top-
level MLA prefix. However, some implementations still honor the
deprecation and continue to regard the prefix as a defunct historical
artifact.
[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
(multilink) 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 interfaces connected to network "A", a
second set of interfaces connected to network "B", etc. According to
the scoped IPv6 addressing architecture [RFC4007], the node would
assign a separate MLA to virtual interfaces associated with each Ad
Hoc network 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 must therefore transcend 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 as follows:
TBD::884e:9d2a:73fc:2d94%netA
TBD::c63d:9724:fca:1237%netB
This document updates the IPv6 scoped addressing architecture
[RFC4007] by introducing a "Multilink-Local" unicast addressing
scope. In particular, this document adds a third unicast address
scope to Section 4 of [RFC4007] as follows:
* Multilink-Local scope, for uniquely identifying a node's attached
Ad Hoc networks.
Templin Expires 5 October 2025 [Page 6]
Internet-Draft IPv6 MLAs April 2025
The size relationship among scopes is further updated as:
* For unicast scopes, link-local is a smaller scope than Multilink-
Local, which is a smaller scope than global.
In [RFC4007], Section 5 under: "Zones of the different scopes are
instantiated as follows", add the new bullet:
* Each Ad Hoc network and the interfaces attached to that Ad Hoc
network comprise a single zone of Multilink-Local scope (for
unicast).
5. MLAs for Ad Hoc Networks
This document updates [RFC5889] to add a new address type "Multilink-
Local" to the list of IPv6 address types found in Section 1 as:
* For IPv6, these addresses may be global [RFC3587], Unique-Local
[RFC4193], Multilink-Local [RFCXXXX] or Link-Local [RFC4291].
6. Obtaining and Assigning IPv6 ULAs/GUAs
IPv6 nodes assign MLAs to an IPv6 virtual interface for use only
within the scope of locally connected 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.
In order to support communications beyond the Ad Hoc local scope,
each IPv6 node is required to obtain an IPv6 ULA/GUA pair through an
IPv6 Internetworking proxy/server that connects the Ad Hoc network to
other networks. Since the proxy/server may be multiple adaptation
layer hops away, however, each node configures and engages an OMNI
Interface as specified in [I-D.templin-6man-omni3]. The IPv6 node
assigns the ULA/GUA 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 proxy/server 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 [RFC6296]. 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.
Templin Expires 5 October 2025 [Page 7]
Internet-Draft IPv6 MLAs April 2025
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".
7. Address Selection
"Default Address Selection for Internet Protocol Version 6 (IPv6)"
[RFC6724] provides a policy table that specifies precedence values
and preferred Source Address prefixes for specific Destination
Addresses. "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. The proposed update appears 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 1 11
3ffe::/16 1 12 3ffe::/16 1 12
TBD::/N 4 14 (*)
(*) value(s) changed in update
Figure 1: Policy Table Update for Multilink Local Addresses
Templin Expires 5 October 2025 [Page 8]
Internet-Draft IPv6 MLAs April 2025
With the proposed updates, this new MLA address type appears as a
lesser precedence than IPv6 GUAs, IPv6 ULAs and IPv4 addresses but as
a greater precedence than deprecated IPv6 prefixes.
8. Requirements
IPv6 nodes assign unique MLAs to an IPv6 virtual interface (e.g., an
OMNI interface) configured over underlying interface attachments to
Ad Hoc networks. If the node becomes aware that a tentative self-
generated MLA is already in use by another node, it instead generates
and assigns a new MLA. If the node becomes aware that an MLA for
which it holds a certificate through an official registration service
is already in use by another node, it should log and report the
incident to the registration service authority.
IPv6 routers MAY forward IPv6 packets with adaptation layer MLA
Source or Destination Addresses over multiple hops within the same Ad
Hoc network as an adaptation layer function.
IPv6 routers MUST NOT forward packets with adaptation layer MLA
Source or Destination Addresses to a link outside the packet's Ad Hoc
network of origin, although MLAs MAY occur as network layer IPv6
Source or Destination Addresses in packets forwarded between disjoint
MANETs via the virtual overlay.
9. Implementation Status
In progress.
10. IANA Considerations
IANA considerations will be updated with specific requirements for
MLA delegations prior to publication.
11. Security Considerations
IPv6 MLAs include very large uniquely-assigned bit strings in both
the prefix and interface identifier components which together provide
ample uniqueness properties.
With the random generation procedures expected for the various MLA
types, the only apparent opportunity for MLA duplication would be
through either intentional or unintentional misconfiguration.
Templin Expires 5 October 2025 [Page 9]
Internet-Draft IPv6 MLAs April 2025
Certain MLA types may have cryptographically generated portions tied
to a certificate with the node's public key while other portions of
the address identify a registration service where address proof-of-
ownership can be confirmed. This stands in contrast to autonomous
assignment of fully self-generated MLAs while relying entirely on
statistical uniqueness properties.
An IPv6 node that configures an MLA and assigns it to a virtual
interface with an optimistic expectation of uniqueness should
therefore be prepared to deconflict legitimate duplications.
12. Acknowledgements
This work was inspired by continued investigations into 5G MANET
operations in cooperation with the Virginia Tech National Security
Institute (VTNSI).
Emerging discussions both in-person and on the IPv6 maintenance
(6man) and MANET mailing lists 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.
13. References
13.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>.
Templin Expires 5 October 2025 [Page 10]
Internet-Draft IPv6 MLAs April 2025
[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>.
[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>.
13.2. Informative References
[I-D.ietf-6man-addr-assign]
Carpenter, B. E., Krishnan, S., and D. Farmer,
"Clarification of IPv6 Address Assignment Policy", Work in
Progress, Internet-Draft, draft-ietf-6man-addr-assign-02,
11 December 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-6man-addr-assign-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-18, 16 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
rfc6724-update-18>.
[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-08, 25 February
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
6man-zone-ui-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-05, 11
December 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-v6ops-ula-usage-considerations-05>.
[I-D.templin-6man-aero3]
Templin, F., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin-
6man-aero3-40, 31 March 2025,
<https://datatracker.ietf.org/doc/html/draft-templin-6man-
aero3-40>.
Templin Expires 5 October 2025 [Page 11]
Internet-Draft IPv6 MLAs April 2025
[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-47, 2 April 2025,
<https://datatracker.ietf.org/doc/html/draft-templin-6man-
omni3-47>.
[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>.
[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>.
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
(MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March
2009, <https://www.rfc-editor.org/info/rfc5498>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>.
[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>.
[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>.
[RFC9602] Krishnan, S., "Segment Routing over IPv6 (SRv6) Segment
Identifiers in the IPv6 Addressing Architecture",
RFC 9602, DOI 10.17487/RFC9602, October 2024,
<https://www.rfc-editor.org/info/rfc9602>.
Templin Expires 5 October 2025 [Page 12]
Internet-Draft IPv6 MLAs April 2025
Appendix A. Change Log
<< RFC Editor - remove prior to publication >>
Differences from earlier versions:
Draft -26 to -27
* Significant updates to requirements.
* Relaxed "1x1" assignment of MLAs to a single MANET.
* Included references for candidate MLA types.
Draft -24 to -26
* Stress address deconfliction instead of deprecation when
address duplication is detected.
* Security considerations for MLA types that support remote
attestation.
* Discussion of site as an ill-defined concept in contrast to
"Multilink Local Scope".
Draft -23 to -24
* Change reference to RFC6296.
* Added more explanation about Ad Hoc Networks.
* MLAs now assigned only to a virtual interface associated with
the Ad-Hoc network and not the physical interfaces themselves.
* Added specifics of how this document updates other RFCs.
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 5 October 2025 [Page 13]