rfc9926v1.txt   rfc9926.txt 
Internet Engineering Task Force (IETF) P. Thubert, Ed. Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 9926 January 2026 Request for Comments: 9926 January 2026
Updates: 4861, 6550, 8505, 8928, 9010 Updates: 4861, 6550, 8505, 8928, 9010
Category: Standards Track Category: Standards Track
ISSN: 2070-1721 ISSN: 2070-1721
IPv6 Neighbor Discovery Prefix Registration Prefix Registration for IPv6 Neighbor Discovery
Abstract Abstract
This document updates IPv6 Neighbor Discovery (RFC 4861) and IPv6 This document updates IPv6 Neighbor Discovery (RFC 4861) and IPv6
Subnet Neighbor Discovery (RFC 8505, RFC 8928) to enable a node that Subnet Neighbor Discovery (RFC 8505, RFC 8928) to enable a node that
owns or is directly connected to a prefix to register that prefix to owns or is directly connected to a prefix to register that prefix to
neighbor routers. The registration indicates that the registered neighbor routers. The registration indicates that the registered
prefix can be reached via the advertising node without a loop. The prefix can be reached via the advertising node without a loop. The
unicast prefix registration allows the node to request one or more unicast prefix registration allows the node to request one or more
neighbor routers to redistribute the prefix in another routing domain neighbor routers to redistribute the prefix in another routing domain
skipping to change at line 91 skipping to change at line 91
13.2. New 6LoWPAN Capability Bit 13.2. New 6LoWPAN Capability Bit
14. Normative References 14. Normative References
15. Informative References 15. Informative References
Acknowledgments Acknowledgments
Author's Address Author's Address
1. Introduction 1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is the most constrained resource of focused on saving energy, which is the most constrained resource of
all. Other design constraints, such as a limited memory capacity, all. Other design constraints (such as a limited memory capacity,
duty cycling of the LLN devices, and low-power lossy transmissions, duty cycling of the LLN devices, and low-power lossy transmissions)
derive from that primary concern. The radio (both transmitting or derive from that primary concern. The radio (both transmitting or
simply listening) is a major energy drain, and the LLN protocols must simply listening) is a major energy drain, and the LLN protocols must
be adapted to allow the nodes to remain sleeping with the radio be adapted to allow the nodes to remain sleeping with the radio
turned off at most times. turned off at most times.
Examples of LLNs include hub-and-spoke access links such as (Low- Examples of LLNs include hub-and-spoke access links such as (Low-
Power) Wi-Fi [IEEE80211] and Bluetooth (Low Energy) [IEEE802151], Power) Wi-Fi [IEEE80211] and Bluetooth (Low Energy) [IEEE802151],
Mesh-Under networks where the routing operation is handled at Layer 2 Mesh-Under networks where the routing operation is handled at Layer 2
(L2), and route-over networks such as the Wi-SUN [WI-SUN] and 6TiSCH (L2), and route-over networks such as the Wi-SUN [WI-SUN] and 6TiSCH
[RFC9030] mesh networks, which leverage 6LoWPAN [RFC4919] [RFC6282] [RFC9030] mesh networks, which leverage 6LoWPAN [RFC4919] [RFC6282]
skipping to change at line 120 skipping to change at line 120
6LoWPAN protocols. The general design points include: 6LoWPAN protocols. The general design points include:
* Placing the protocol complexity in the less-constrained routers to * Placing the protocol complexity in the less-constrained routers to
simplify the host implementation and avoid expanding the control simplify the host implementation and avoid expanding the control
traffic to all nodes. traffic to all nodes.
* Using host-triggered operations to enable transient disconnections * Using host-triggered operations to enable transient disconnections
with the routers, e.g., to conserve power (sleep), but also to with the routers, e.g., to conserve power (sleep), but also to
cope with inconsistent connectivity. cope with inconsistent connectivity.
This translates into: These points translate into:
* Stateful proactively built knowledge in the routers that is * Stateful proactively built knowledge in the routers that is
available at any point of time. available at any point of time.
* Unicast host-to-router operations triggered by the host and its * Unicast host-to-router operations triggered by the host and its
applications. applications.
* Minimal use of asynchronous L2 broadcast operations that would * Minimal use of asynchronous L2 broadcast operations that would
keep the host awake and listening with no application-level need keep the host awake and listening with no application-level need
to do so. to do so.
skipping to change at line 143 skipping to change at line 143
[RFC6550] provides IPv6 [RFC8200] routing services within such [RFC6550] provides IPv6 [RFC8200] routing services within such
constraints. To save signaling and routing state in constrained constraints. To save signaling and routing state in constrained
networks, the RPL routing is only performed along a Destination- networks, the RPL routing is only performed along a Destination-
Oriented Directed Acyclic Graph (DODAG) that is optimized to reach a Oriented Directed Acyclic Graph (DODAG) that is optimized to reach a
Root node, as opposed to along the shortest path between two peers, Root node, as opposed to along the shortest path between two peers,
whatever that would mean in each LLN. whatever that would mean in each LLN.
The classical Neighbor Discovery Protocol (NDP) [RFC4861] [RFC4862] The classical Neighbor Discovery Protocol (NDP) [RFC4861] [RFC4862]
was defined for serial links and shared transit media such as was defined for serial links and shared transit media such as
Ethernet at a time when L2 broadcast was cheap on those media, while Ethernet at a time when L2 broadcast was cheap on those media, while
memory for neighbor cache was expensive. It was thus designed as a memory for neighbor cache was expensive. Thus, it was designed as a
reactive protocol that relies on caching and multicast operations for reactive protocol that relies on caching and multicast operations for
the Address Resolution (AR) (aka Address Discovery or Address Lookup) the Duplicate Address Detection (DAD) and Address Resolution (AR),
and Duplicate Address Detection (DAD) of IPv6 unicast addresses. aka address discovery or address lookup, of IPv6 unicast addresses.
Those multicast operations typically impact every node on-link when Those multicast operations typically impact every node on-link when
at most one is really targeted, which is a waste of energy, and imply at most one is really targeted, which is a waste of energy, and imply
that all nodes are awake to hear the request, which is inconsistent that all nodes are awake to hear the request, which is inconsistent
with power-saving (sleeping) modes. with power-saving (sleeping) modes.
"Architecture and Framework for IPv6 over Non-Broadcast Access" "Architecture and Framework for IPv6 over Non-Broadcast Access"
[IPv6-over-NBMA] introduces an evolution of IPv6 ND towards a [IPv6-over-NBMA] introduces an evolution of IPv6 ND towards a
proactive AR method. Because the IPv6 model for NBMA depends on a proactive AR method. Because the IPv6 model for NBMA depends on a
routing protocol to reach inside the Subnet, the IPv6 ND extension routing protocol to reach inside the subnet, the IPv6 ND extension
for NBMA is referred to as Subnet Neighbor Discovery (SND). SND is for NBMA is referred to as Subnet Neighbor Discovery (SND). SND is
based on work done in the context of Internet of Things (IoT), known based on work done in the context of Internet of Things (IoT), known
as 6LoWPAN ND. As opposed to the classical IPv6 ND protocol, this as 6LoWPAN ND. As opposed to the classical IPv6 ND protocol, this
evolution follows the energy conservation principles discussed above: evolution follows the energy conservation principles discussed above:
* The original 6LoWPAN ND, "Neighbor Discovery Optimization for IPv6 * The original 6LoWPAN ND, "Neighbor Discovery Optimization for IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs)" over Low-Power Wireless Personal Area Networks (6LoWPANs)"
[RFC6775], was introduced to avoid the excessive use of multicast [RFC6775], was introduced to avoid the excessive use of multicast
messages and enable IPv6 ND for operations over energy-constrained messages and enable IPv6 ND for operations over energy-constrained
nodes. [RFC6775] changes the classical IPv6 ND model to nodes. [RFC6775] changes the classical IPv6 ND model to
skipping to change at line 205 skipping to change at line 205
This specification updates the above registration and subscription This specification updates the above registration and subscription
methods to enable a node to register a unicast prefix to the routing methods to enable a node to register a unicast prefix to the routing
system and get it injected in the routing protocol. As with system and get it injected in the routing protocol. As with
[RFC8505], the prefix registration is agnostic to the routing [RFC8505], the prefix registration is agnostic to the routing
protocol in which the router injects the prefix, and the router is protocol in which the router injects the prefix, and the router is
agnostic to the method that was used to allocate the prefix to the agnostic to the method that was used to allocate the prefix to the
node. The energy conservation principles in [RFC8505] are retained node. The energy conservation principles in [RFC8505] are retained
as well, meaning that the node does not have to send or expect as well, meaning that the node does not have to send or expect
asynchronous multicast messages. asynchronous multicast messages.
It can be noted that an energy-conserving node is not necessarily a Please note that an energy-conserving node is not necessarily a
router, so even when advertising a prefix, it is a design choice not router, so even when a node is advertising a prefix, it is a design
to use Router Advertisement (RA) messages that would make the node choice not to use Router Advertisement (RA) messages that would make
appear as a router to peer nodes. From the design principles above, the node appear as a router to peer nodes. From the design
it is clearly a design choice not to leverage broadcasts from or to principles above, it is clearly a design choice not to leverage (1)
the node, or complex state machines in the node. It is also a design broadcasts from or to the node or (2) complex state machines in the
choice to use and extend the EARO as opposed to the Route Information node. It is also a design choice to use and extend the EARO as
Option (RIO) [RFC4191] because the RIO is not intended to inject opposed to the Route Information Option (RIO) [RFC4191] because the
routes in routing, and is lacking related control information like RIO is not intended to inject routes in routing, and is lacking
the R bit in the EARO. Additionally, an RA with RIO cannot be related control information like the R bit in the EARO.
trusted for a safe injection in the routing protocol for the lack of Additionally, an RA with RIO cannot be trusted for a safe injection
the equivalent of the Registration Ownership Verifier (ROVR) in the routing protocol for the lack of the equivalent of the
[RFC8928] in the EARO. Registration Ownership Verifier (ROVR) [RFC8928] in the EARO.
2. Terminology 2. Terminology
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Inherited Terms and Concepts 2.2. Inherited Terms and Concepts
This document uses terms and concepts that are discussed in: This document uses terms and concepts that are discussed in:
* "TLS User Mapping Extension" [RFC4861] and * "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] and
* "IPv6 Stateless Address Autoconfiguration" [RFC4862] for the * "IPv6 Stateless Address Autoconfiguration" [RFC4862] for the
Neighbor Solicitation operation, Neighbor Solicitation operation,
* "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless * "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)" [RFC6775], as well as Personal Area Networks (6LoWPANs)" [RFC6775], as well as
* "Registration Extensions for IPv6 over Low-Power Wireless Personal * "Registration Extensions for IPv6 over Low-Power Wireless Personal
Area Network (6LoWPAN) Neighbor Discovery" [RFC8505], and Area Network (6LoWPAN) Neighbor Discovery" [RFC8505], and
* "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" * "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"
[RFC6550] for RPL, which is the routing protocol used in LLNs for [RFC6550] for RPL, which is the routing protocol used in LLNs for
SND. SND.
2.3. Acronyms and Initialisms 2.3. Acronyms and Initialisms
This document uses the following abbreviations: This document uses the following abbreviations:
*6CIO:* 6LoWPAN Capability Indication Option [RFC7400] 6CIO: 6LoWPAN Capability Indication Option [RFC7400]
*6LBR:* 6LoWPAN Border Router [RFC6775] 6LBR: 6LoWPAN Border Router [RFC6775]
*6LN:* 6LoWPAN Node [RFC6775] 6LN: 6LoWPAN Node [RFC6775]
*6LR:* 6LoWPAN Router [RFC6775] 6LR: 6LoWPAN Router [RFC6775]
*ARO:* Address Registration Option [RFC6775] ARO: Address Registration Option [RFC6775]
*DAD:* Duplicate Address Detection [RFC4861] DAD: Duplicate Address Detection [RFC4861]
*DAO:* Destination Advertisement Object [RFC6550] DAO: Destination Advertisement Object [RFC6550]
*DODAG:* Destination-Oriented Directed Acyclic Graph DODAG: Destination-Oriented Directed Acyclic Graph
*EARO:* Extended Address Registration Option [RFC8505] EARO: Extended Address Registration Option [RFC8505]
*EDAC:* Extended Duplicate Address Confirmation [RFC8505] EDAC: Extended Duplicate Address Confirmation [RFC8505]
*EDAR:* Extended Duplicate Address Request [RFC8505] EDAR: Extended Duplicate Address Request [RFC8505]
*ESS:* Extended Service Set [IEEE80211] ESS: Extended Service Set [IEEE80211]
*IPAM:* IP Address Management IPAM: IP Address Management
*LLN:* Low-Power and Lossy Network LLN: Low-Power and Lossy Network
*LLA:* Link-Layer Address LLA: Link-Layer Address
*LoWPAN:* Low-Power Wireless Personal Area Network [IEEE802154] LoWPAN: Low-Power Wireless Personal Area Network
*MAC:* Medium Access Control LR-WPAN: Low-Rate Wireless Personal Area Network [IEEE802154]
*NA:* Neighbor Advertisement (message) [RFC4861] MAC: Medium Access Control
*NBMA:* Non-Broadcast Multi-Access (full mesh) NA: Neighbor Advertisement (message) [RFC4861]
*NCE:* Neighbor Cache Entry [RFC4861] NBMA: Non-Broadcast Multi-Access (full mesh)
*ND:* Neighbor Discovery (protocol) NCE: Neighbor Cache Entry [RFC4861]
*NDP:* Neighbor Discovery Protocol ND: Neighbor Discovery (protocol)
*NS:* Neighbor Solicitation (message) [RFC4861] NDP: Neighbor Discovery Protocol
*ROVR:* Registration Ownership Verifier (pronounced "rover") NS: Neighbor Solicitation (message) [RFC4861]
ROVR: Registration Ownership Verifier (pronounced "rover")
[RFC8505] [RFC8505]
*RPL:* IPv6 Routing Protocol for LLNs (pronounced "ripple") RPL: IPv6 Routing Protocol for LLNs (pronounced "ripple")
[RFC6550] [RFC6550]
*RA:* Router Advertisement (message) [RFC4861] RA: Router Advertisement (message) [RFC4861]
*RS:* Router Solicitation (message) [RFC4861] RS: Router Solicitation (message) [RFC4861]
*RTO:* RPL Target Option [RFC6550] RTO: RPL Target Option [RFC6550]
*SLLAO:* Source Link-Layer Address Option [RFC4861] SLLAO: Source Link-Layer Address Option [RFC4861]
*SND:* Subnet Neighbor Discovery (protocol) SND: Subnet Neighbor Discovery (protocol)
*TID:* Transaction ID [RFC8505] TID: Transaction ID [RFC8505]
*TIO:* Transit Information Option [RFC6550] TIO: Transit Information Option [RFC6550]
*TLLAO:* Target Link-Layer Address Option [RFC4861] TLLAO: Target Link-Layer Address Option [RFC4861]
2.4. New Terms 2.4. New Terms
This document introduces the following terms: This document introduces the following term:
*Origin:* The node that issued the prefix advertisement, either in Origin: The node that issued the prefix advertisement, either in the
the form of a NS(EARO) or as a DAO(TIO, RTO) form of a NS(EARO) or as a DAO(TIO, RTO)
*Merge:* The action of receiving multiple anycast or multicast
advertisements, either internally from self, in the form of a
NS(EARO), or as a DAO(TIO, RTO), and generating a single
DAO(TIO, RTO). The 6RPL router maintains a state per origin
for each advertised address, and merges the advertisements for
all subscriptions for the same address in a single
advertisement. A RPL router that merges then becomes the
origin of the merged advertisement and uses its own values for
the Path Sequence and ROVR fields.
3. Overview 3. Overview
This specification inherits from [RFC6550], [RFC8505], and [RFC9010] This specification inherits from [RFC6550], [RFC8505], and [RFC9010]
to register prefixes as opposed to addresses. to register prefixes as opposed to addresses.
An SND deployment consists of: The IPv6 ND operation is agnostic to the routing protocol used in the
SND. Route-over LLNs typically leverage RPL. A RPL-based SND
deployment consists of:
* one or more 6LBRs that act as RPL Root, * one or more 6LBRs that act as RPL Root,
* intermediate routers down the RPL graph that propagate routing * intermediate routers down the RPL graph that propagate routing
information on addresses and prefixes towards the Root, information on addresses and prefixes towards the Root,
* 6LRs that are RPL-aware 6LNs and can leverage RPL directly to * 6LRs that are RPL-aware 6LNs and can leverage RPL directly to
expose their addresses and prefixes, and expose their addresses and prefixes, and
* 6LNs that are the RPL-unaware destinations and need SND to obtain * 6LNs that are the RPL-unaware destinations and need SND to obtain
skipping to change at line 333 skipping to change at line 327
The SND operation for prefixes inherits from that for unicast The SND operation for prefixes inherits from that for unicast
addresses, meaning that it is the same unless specified otherwise addresses, meaning that it is the same unless specified otherwise
herein. In particular, forwarding a packet happens as specified in herein. In particular, forwarding a packet happens as specified in
Section 11 of [RFC6550], including loop avoidance and detection. Section 11 of [RFC6550], including loop avoidance and detection.
However, in the case of multicast, multiple copies might be However, in the case of multicast, multiple copies might be
generated. generated.
[RFC8505] is a prerequisite to this specification. A node that [RFC8505] is a prerequisite to this specification. A node that
implements this MUST also implement [RFC8505]. This specification implements this MUST also implement [RFC8505]. This specification
does not introduce a new option; it modifies existing options and does not introduce a new option; it modifies existing options and
updates the associated behaviors to enable the Registration for updates the associated behaviors to enable the registration for
prefixes as an extension to [RFC8505]. prefixes as an extension to [RFC8505].
This specification updates the P-Field introduced in [RFC9685] for This specification updates the P-Field introduced in [RFC9685] for
use in EARO, DAR, and RTO, with the new value of 3 to indicate the use in EARO, DAR, and RTO, with the new value of 3 to indicate the
registration of a prefix, as detailed in Section 7.2. With this registration of a prefix, as detailed in Section 7.2. With this
extension, the 6LN can now express its willingness to receive the extension, the 6LN can now express its willingness to receive the
traffic for all addresses in the range of a prefix, using the P-Field traffic for all addresses in the range of a prefix, using the P-Field
value of 3 in the EARO to signal that the registration is for such value of 3 in the EARO to signal that the registration is for such
prefix. Multiple 6LNs acting as border routers to the same external prefix. Multiple 6LNs acting as border routers to the same external
network or as access routers to the same subnet may register the same network or as access routers to the same subnet may register the same
skipping to change at line 389 skipping to change at line 383
zeros in the Target Address field. zeros in the Target Address field.
5. Updating RFC 7400 5. Updating RFC 7400
This specification updates "6LoWPAN-GHC: Generic Header Compression This specification updates "6LoWPAN-GHC: Generic Header Compression
for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"
[RFC7400] by defining a new capability bit for use in the 6CIO. [RFC7400] by defining a new capability bit for use in the 6CIO.
[RFC7400] was already updated by [RFC8505] for use in IPv6 ND [RFC7400] was already updated by [RFC8505] for use in IPv6 ND
messages. messages.
The new "Registration for prefixes Supported" (F) flag indicates to The new "Registration for prefixes supported" (F) flag indicates to
the 6LN that the 6LR (1) accepts IPv6 prefix registrations as the 6LN that the 6LR (1) accepts IPv6 prefix registrations as
specified in this document, (2) will ensure that packets for the specified in this document, (2) will ensure that packets for the
addresses that match this prefix will be routed to the 6LNs that addresses that match this prefix will be routed to the 6LNs that
registered the prefix, and (3) will ensure that the route to the registered the prefix, and (3) will ensure that the route to the
prefix will be redistributed if the R flag is set to 1. prefix will be redistributed if the R flag is set to 1.
Figure 1 illustrates the F flag in its position (16, counting 0 to 47 Figure 1 illustrates the F flag in its position (16, counting 0 to 47
in network order in the 48-bit array). in network order in the 48-bit array).
0 1 2 3 0 1 2 3
skipping to change at line 411 skipping to change at line 405
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 1 | Experimental |X|A|D|L|B|P|E|G| | Type | Length = 1 | Experimental |X|A|D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved | |F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: New Capability Bit in the 6CIO Figure 1: New Capability Bit in the 6CIO
New Option Field: New Option Field:
*F:* 1-bit flag, set to 1 to indicate "Registration for prefixes F: 1-bit flag, set to 1 to indicate "Registration for prefixes
Supported" supported"
6. Updating RFC 6550 6. Updating RFC 6550
[RFC6550] uses the Path Sequence in the Transit Information Option [RFC6550] uses the Path Sequence in the Transit Information Option
(TIO) to retain only the freshest unicast route and remove stale (TIO) to retain only the freshest unicast route and remove stale
ones, e.g., in the case of mobility. [RFC9010] copies the TID from ones, e.g., in the case of mobility. [RFC9010] copies the TID from
the EARO into the Path Sequence, and the ROVR field into the the EARO into the Path Sequence, and the ROVR field into the
associated RPL Target Option (RTO). This way, it is possible to associated RPL Target Option (RTO). This way, it is possible to
identify both the registering node and the order of registration in identify both the registering node and the order of registration in
RPL for each individual advertisement, so the most recent path and RPL for each individual advertisement, so the most recent path and
skipping to change at line 456 skipping to change at line 450
[RFC6550] uses the Path Lifetime in the TIO to indicate the remaining [RFC6550] uses the Path Lifetime in the TIO to indicate the remaining
time for which the advertisement is valid for unicast route time for which the advertisement is valid for unicast route
determination, and a Path Lifetime value of 0 invalidates that route. determination, and a Path Lifetime value of 0 invalidates that route.
[RFC9010] maps the Address Registration lifetime in the EARO and the [RFC9010] maps the Address Registration lifetime in the EARO and the
Path Lifetime in the TIO so they are comparable when both forms of Path Lifetime in the TIO so they are comparable when both forms of
advertisements are received. advertisements are received.
The RPL router that merges multiple advertisements for the same The RPL router that merges multiple advertisements for the same
prefix uses and advertises the longest remaining lifetime across all prefix uses and advertises the longest remaining lifetime across all
the origins of the advertisements for that prefix. When the lifetime the origins of the advertisements for that prefix. When the lifetime
expires, the router sends a no-path DAO (i.e., the lifetime is 0) expires, the router sends a no-path DAO message (i.e., the lifetime
using the same value for the ROVR value as for the previous is 0) using the same value for the ROVR value as for the previous
advertisements. This value refers to either the router itself or the advertisements. This value refers to either the single descendant
single descendant that advertised the Target. that advertised the Target if there is only one or the router itself
if there is more than one.
Note that the Registration Lifetime, TID, and ROVR fields are also Note that the Registration Lifetime, TID, and ROVR fields are also
placed in the EDAR message, so the state created by EDAR is also placed in the EDAR message, so the state created by EDAR is also
comparable with that created upon an NS(EARO) or a DAO message. For comparable with that created upon an NS(EARO) or a DAO message. For
simplicity, the text below mentions only NS(EARO) but it also applies simplicity, the text below mentions only NS(EARO) but it also applies
to EDAR. to EDAR.
7. Updating RFC 8505 7. Updating RFC 8505
This specification updates the EARO and EDAR messages to enable the This specification updates the EARO and EDAR messages to enable the
registration of prefixes and updates the Registration operation in registration of prefixes and updates the registration operation in
the case of a prefix, in particular from the standpoint of the 6LR, the case of a prefix, in particular from the standpoint of the 6LR,
e.g., to enable the Registration of overlapping prefixes. e.g., to enable the registration of overlapping prefixes.
7.1. New P-Field Value 7.1. New P-Field Value
[RFC9685] defines a 2-bit P-Field with values 0 through 2 and [RFC9685] defines a 2-bit P-Field with values 0 through 2 and
reserves the value 3 for future use. This specification defines the reserves the value 3 for future use. This specification defines the
semantics of P-Field value 3. semantics of P-Field value 3.
When the P-Field is set to 3, it indicates that the Registered When the P-Field is set to 3, it indicates that the Registered
Address represents a prefix rather than a single address. Upon Address represents a prefix rather than a single address. Upon
receiving an NS(EARO) message with the P-Field set to 3, the receiver receiving an NS(EARO) message with the P-Field set to 3, the receiver
MUST install a route to the indicated prefix via the source address MUST install a route to the indicated prefix via the source address
of the NS(EARO) message. of the NS(EARO) message.
This specification assigns the value 3 to the P-Field, resulting in This specification assigns the value 3 to the P-Field, resulting in
the following complete set of defined values: the following complete set of defined values:
+=======+======================================+ +=======+======================================+
| Value | Meaning | | Value | Meaning |
+=======+======================================+ +=======+======================================+
| *0* | Registration for a Unicast Address | | 0 | Registration for a Unicast Address |
+-------+--------------------------------------+ +-------+--------------------------------------+
| *1* | Registration for a Multicast Address | | 1 | Registration for a Multicast Address |
+-------+--------------------------------------+ +-------+--------------------------------------+
| *2* | Registration for an Anycast Address | | 2 | Registration for an Anycast Address |
+-------+--------------------------------------+ +-------+--------------------------------------+
| *3* | Registration for a Prefix | | 3 | Registration for a Unicast Prefix |
+-------+--------------------------------------+ +-------+--------------------------------------+
Table 1: P-Field Values Table 1: P-Field Values
7.2. New EARO Prefix Length Field and F flag 7.2. New EARO Prefix Length Field and F flag
Section 4.1 of [RFC8505] defines the EARO as an extension to the ARO Section 4.1 of [RFC8505] defines the EARO as an extension to the ARO
option defined in [RFC6775]. option defined in [RFC6775].
The Status field is used only when the EARO is placed in an NA The Status field is used only when the EARO is placed in an NA
skipping to change at line 557 skipping to change at line 552
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... ROVR ... ... ROVR ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EARO Format for Use in NS Messages Figure 2: EARO Format for Use in NS Messages
New and updated Option Fields: New and updated Option Fields:
*F:* (Forwarding Flag) A 1-bit flag. When set to 1, it indicates F: (Forwarding Flag) A 1-bit flag. When set to 1, it indicates that
that the sender expects other routers to forward packets to the the sender expects other routers to forward packets to the sender
sender when those packets are sourced from within the registered when those packets are sourced from within the registered prefix.
prefix.
*Prefix Length:* A 7-bit unsigned integer. When the P-Field is set Prefix Length: A 7-bit unsigned integer. When the P-Field is set to
to 3 and the EARO is included in an NS message, this field MUST 3 and the EARO is included in an NS message, this field MUST
contain a prefix length expressed in bits, with a value between 16 contain a prefix length expressed in bits, with a value in the
and 120 inclusive. When the EARO is included in an NA message, inclusive range of 16 to 120. When the EARO is included in an NA
this field MUST carry a status value, regardless of the setting of message, this field MUST carry a status value, regardless of the
the P-Field. In all other cases, this field is reserved; it MUST setting of the P-Field. In all other cases, this field is
be set to zero by the sender and MUST be ignored by the receiver. reserved; it MUST be set to zero by the sender and MUST be ignored
by the receiver.
*r* (reserved): A 1-bit reserved field. It MUST be set to zero by r (reserved): A 1-bit reserved field. It MUST be set to zero by the
the sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
7.3. New EDAR Prefix Length Field 7.3. New EDAR Prefix Length Field
This specification adds the new value of 3 to the P-Field to signal This specification adds the new value of 3 to the P-Field to signal
that the Registered Address is a prefix. When that is the case, the that the Registered Address is a prefix. When that is the case, the
prefix is assumed to be at most 120 bits long, padded with zeros up prefix is assumed to be at most 120 bits long, padded with zeros up
to 120 bits, and the remaining byte is dedicated to one reserved bit to 120 bits, and the remaining byte is dedicated to one reserved bit
and the prefix length. and the Prefix Length.
Figure 3 illustrates the EDAR message when the value of the P-Field Figure 3 illustrates the EDAR message when the value of the P-Field
is 3. Figure 4 shows the response EDAC message, with the Status is 3. Figure 4 shows the response EDAC message, with the Status
field and the echoed Prefix. field and the echoed Prefix.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |CodePfx|CodeSfx| Checksum | | Type |CodePfx|CodeSfx| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 635 skipping to change at line 630
+ +-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+
| |r|Prefix Length| | |r|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: EDAC Message Format Figure 4: EDAC Message Format
New and updated EDAR/EDAC Message Fields: New and updated EDAR/EDAC Message Fields:
*Prefix:* A 15-byte field that carries up to 120 bits of the prefix. Prefix: A 15-byte field that carries up to 120 bits of the prefix.
If the prefix is shorter than 120 bits, the remaining bits MUST be If the prefix is shorter than 120 bits, the remaining bits MUST be
padded with zeros. The receiver MUST treat the padding as zeroed padded with zeros. The receiver MUST treat the padding as zeroed
and MUST overwrite any unused bits with zeros before using the and MUST overwrite any unused bits with zeros before using the
prefix. prefix.
*r* (reserved): A 1-bit reserved field. It MUST be set to zero by r (reserved): A 1-bit reserved field. It MUST be set to zero by the
the sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
*Prefix Length:* A 7-bit unsigned integer indicating the length of Prefix Length: A 7-bit unsigned integer indicating the length of the
the prefix in bits. The value MUST be in the inclusive range of prefix in bits. The value MUST be in the inclusive range of 16 to
16 to 120. 120.
The capability to place the P-Field and the contiguous "Reserved" The capability to place the P-Field and the contiguous "Reserved"
field in the EDAR message is specified in Section 7.2 of [RFC9685]. field in the EDAR message is specified in Section 7.2 of [RFC9685].
The capability to append ND options to the EDAR and EDAC messages is The capability to append ND options to the EDAR and EDAC messages is
introduced in Section 3.1 of [RFC8929]. introduced in Section 3.1 of [RFC8929].
All other fields follow the same definition as specified in All other fields follow the same definition as specified in
[RFC8505]. The values for these fields and RFC references are [RFC8505]. The values for these fields and RFC references are
maintained by IANA under the "Internet Control Message Protocol maintained by IANA under the "Internet Control Message Protocol
skipping to change at line 676 skipping to change at line 671
silent. When the node comes back to life, existing registration silent. When the node comes back to life, existing registration
state might be lost if it was not safely stored, e.g., in state might be lost if it was not safely stored, e.g., in
persistent memory. persistent memory.
* Only unicast addresses can be registered. * Only unicast addresses can be registered.
* The 6LN must register all its Unique Local Addresses (ULAs) and * The 6LN must register all its Unique Local Addresses (ULAs) and
Global Unicast Addresses (GUAs) with a NS(EARO). Global Unicast Addresses (GUAs) with a NS(EARO).
* The 6LN may set the R flag in the EARO to obtain return * The 6LN may set the R flag in the EARO to obtain return
reachability services by the 6LR, e.g., through ND proxy reachability services from the 6LR, e.g., through ND proxy
operations, or by injecting the route in a route-over subnet. operations or by injecting the route in a route-over subnet.
* The 6LR maintains a registration state per Registered Address, * The 6LR maintains a registration state per Registered Address,
including an NCE with the Link Layer Address (LLA) of the including an NCE with the Link Layer Address (LLA) of the
Registered Node (the 6LN here). Registered Node (the 6LN here).
The operation for registering prefixes is similar to that for The operation for registering prefixes is similar to that for
addresses from the perspective of the 6LN, but shows important addresses from the perspective of the 6LN, but shows important
differences on the router side, which maintains a separate state for differences on the router side, which maintains a separate state for
each origin and merges them in its own advertisements. This each origin and merges them in its own advertisements. This
specification adds the following behavior, similar to that introduced specification adds the following behavior, similar to that introduced
skipping to change at line 765 skipping to change at line 760
redistribute the prefix on other links using a routing protocol. redistribute the prefix on other links using a routing protocol.
The 6LR MUST NOT reregister that prefix to yet another router The 6LR MUST NOT reregister that prefix to yet another router
unless loops are avoided some way, e.g., following a tree unless loops are avoided some way, e.g., following a tree
structure. structure.
* The 6LR and the 6LBR are extended to accept more than one * The 6LR and the 6LBR are extended to accept more than one
registration for the same prefix, since multiple 6LNs may register registration for the same prefix, since multiple 6LNs may register
it. The ROVR in the EARO identifies uniquely a registration it. The ROVR in the EARO identifies uniquely a registration
within the namespace of the Registered Prefix. within the namespace of the Registered Prefix.
* The 6LR MUST maintain a registration state per tuple (IPv6 prefix/ * The 6LR MUST maintain a registration state per tuple (IPv6 prefix,
length, ROVR) for all registered prefixes. It SHOULD notify the prefix length, ROVR) for all registered prefixes. It SHOULD
6LBR with an EDAR message, unless it determined that the 6LBR is notify the 6LBR with an EDAR message, unless it determined that
legacy and does not support this specification (see Section 5). the 6LBR is legacy and does not support this specification (see
In turn, the 6LBR MUST maintain a registration state per tuple Section 5). In turn, the 6LBR MUST maintain a registration state
(IPv6 prefix, ROVR) for all prefixes. per tuple (IPv6 prefix, ROVR) for all prefixes.
8. Updating RFC 9010 8. Updating RFC 9010
With [RFC9010]: With [RFC9010]:
* The 6LR injects only unicast routes in RPL. * The 6LR injects only unicast routes in RPL.
* Upon a registration with the R flag set to 1 in the EARO, the 6LR * Upon a registration with the R flag set to 1 in the EARO, the 6LR
injects the address in the RPL unicast support. injects the address in the RPL unicast support.
skipping to change at line 908 skipping to change at line 903
12.2. Application to RPL-Based Route-Over LLNs 12.2. Application to RPL-Based Route-Over LLNs
This specification also updates [RFC6550] and [RFC9010] in the case This specification also updates [RFC6550] and [RFC9010] in the case
of a route-over multilink subnet based on the RPL routing protocol, of a route-over multilink subnet based on the RPL routing protocol,
to add multicast ingress replication in Non-Storing Mode and anycast to add multicast ingress replication in Non-Storing Mode and anycast
support in both Storing and Non-Storing modes. A 6LR that implements support in both Storing and Non-Storing modes. A 6LR that implements
the RPL extensions specified therein MUST also implement [RFC9010]. the RPL extensions specified therein MUST also implement [RFC9010].
Figure 5 illustrates the classical situation of an LLN as a single Figure 5 illustrates the classical situation of an LLN as a single
IPv6 Subnet, with a 6LoWPAN Border Router (6LBR) that acts as Root IPv6 subnet, with a 6LoWPAN Border Router (6LBR) that acts as Root
for RPL operations and as Address Registrar for 6LowPAN ND. for RPL operations and as Address Registrar for 6LowPAN ND.
.- -- . .- -- .
.-( ). .-( ).
( Internet ) ( Internet )
(___.________.___) (___.________.___)
| |
---+-------+-- ---+-------+--
| |
+--------+ +--------+
skipping to change at line 1071 skipping to change at line 1066
as follows. as follows.
13.1. Updated P-Field Registry 13.1. Updated P-Field Registry
This specification updates the P-Field introduced in [RFC9685] to This specification updates the P-Field introduced in [RFC9685] to
assign the value of 3, which is the only remaining unassigned value assign the value of 3, which is the only remaining unassigned value
for the 2-bit field. To that effect, IANA has updated the "P-Field for the 2-bit field. To that effect, IANA has updated the "P-Field
Values" registry in the "Internet Control Message Protocol version 6 Values" registry in the "Internet Control Message Protocol version 6
(ICMPv6) Parameters" registry group as indicated in Table 2: (ICMPv6) Parameters" registry group as indicated in Table 2:
+=======+===========================+===========+ +=======+===================================+===========+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+===========================+===========+ +=======+===================================+===========+
| *3* | Registration for a Prefix | RFC 9926 | | 3 | Registration for a Unicast Prefix | RFC 9926 |
+-------+---------------------------+-----------+ +-------+-----------------------------------+-----------+
Table 2: New P-Field Value Table 2: New P-Field Value
13.2. New 6LoWPAN Capability Bit 13.2. New 6LoWPAN Capability Bit
IANA has made an addition to the "6LoWPAN Capability Bits" IANA has made an addition to the "6LoWPAN Capability Bits"
[IANA.ICMP.6CIO] registry in the "Internet Control Message Protocol [IANA.ICMP.6CIO] registry in the "Internet Control Message Protocol
version 6 (ICMPv6) Parameters" registry group as indicated in version 6 (ICMPv6) Parameters" registry group as indicated in
Table 3: Table 3:
IANA has fixed the description of bit 9 (the "A" flag defined in IANA has fixed the description of bit 9 (the "A" flag defined in
[RFC8928]). It is not called "1" but "A". [RFC8928]). It is not called "1" but "A".
+======+=============================================+===========+ +=====+=============================================+===========+
| Bit | Description | Reference | | Bit | Description | Reference |
+======+=============================================+===========+ +=====+=============================================+===========+
| *9* | AP-ND Enabled (A bit) | [RFC8928] | | 9 | AP-ND Enabled (A bit) | [RFC8928] |
+------+---------------------------------------------+-----------+ +-----+---------------------------------------------+-----------+
| *16* | Registration for prefixes Supported (F bit) | RFC 9926 | | 16 | Registration for prefixes supported (F bit) | RFC 9926 |
+------+---------------------------------------------+-----------+ +-----+---------------------------------------------+-----------+
Table 3: New 6LoWPAN Capability Bit Table 3: New 6LoWPAN Capability Bit
14. Normative References 14. Normative References
[IANA.ICMP]
IANA, "Internet Control Message Protocol version 6
(ICMPv6) Parameters",
<https://www.iana.org/assignments/icmpv6-parameters>.
[IANA.ICMP.6CIO]
IANA, "6LoWPAN Capability Bits",
<https://www.iana.org/assignments/icmpv6-parameters>.
[IANA.RPL] IANA, "Routing Protocol for Low Power and Lossy Networks
(RPL)", <https://www.iana.org/assignments/rpl>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
skipping to change at line 1168 skipping to change at line 1175
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks) (Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>. <https://www.rfc-editor.org/info/rfc9010>.
[RFC9685] Thubert, P., Ed., "Listener Subscription for IPv6 Neighbor [RFC9685] Thubert, P., Ed., "Listener Subscription for IPv6 Neighbor
Discovery Multicast and Anycast Addresses", RFC 9685, Discovery Multicast and Anycast Addresses", RFC 9685,
DOI 10.17487/RFC9685, November 2024, DOI 10.17487/RFC9685, November 2024,
<https://www.rfc-editor.org/info/rfc9685>. <https://www.rfc-editor.org/info/rfc9685>.
[IANA.ICMP]
IANA, "Internet Control Message Protocol version 6
(ICMPv6) Parameters",
<https://www.iana.org/assignments/icmpv6-parameters>.
[IANA.ICMP.6CIO]
IANA, "6LoWPAN Capability Bits",
<https://www.iana.org/assignments/icmpv6-parameters>.
[IANA.RPL] IANA, "Routing Protocol for Low Power and Lossy Networks
(RPL)", <https://www.iana.org/assignments/rpl>.
15. Informative References 15. Informative References
[BCP38] Best Current Practice 38, [BCP38] Best Current Practice 38,
<https://www.rfc-editor.org/info/bcp38>. <https://www.rfc-editor.org/info/bcp38>.
At the time of writing, this BCP comprises the following: At the time of writing, this BCP comprises the following:
Ferguson, P. and D. Senie, "Network Ingress Filtering: Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[IEEE80211]
IEEE, "IEEE Standard for Information Technology --
Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Networks -- Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE
Std 802.11-2022, DOI 10.1109/IEEESTD.2021.9363693,
<https://ieeexplore.ieee.org/document/9363693>.
[IEEE802151]
IEEE, "IEEE Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN - Specific
Requirements - Part 15: Wireless Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Wireless
Personal Area Networks (WPANs)", IEEE Std 802.15.1-2002,
DOI 10.1109/IEEESTD.2002.93621,
<https://ieeexplore.ieee.org/document/1016473>.
[IEEE802154]
IEEE, "IEEE Standard for Information technology -- Local
and metropolitan area networks -- Specific requirements --
Part 15.4: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Low Rate Wireless
Personal Area Networks (WPANs)", IEEE Std 802.15.4-2006,
DOI 10.1109/IEEESTD.2006.232110,
<https://ieeexplore.ieee.org/document/1700009>.
[IPv6-over-NBMA]
Thubert, P. and M. Richardson, "Architecture and Framework
for IPv6 over Non-Broadcast Access", Work in Progress,
Internet-Draft, draft-ietf-6man-ipv6-over-wireless-09, 9
November 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-6man-ipv6-over-wireless-09>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007, RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>. <https://www.rfc-editor.org/info/rfc4919>.
skipping to change at line 1217 skipping to change at line 1246
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time- [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021, RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>. <https://www.rfc-editor.org/info/rfc9030>.
[IPv6-over-NBMA]
Thubert, P. and M. Richardson, "Architecture and Framework
for IPv6 over Non-Broadcast Access", Work in Progress,
Internet-Draft, draft-ietf-6man-ipv6-over-wireless-09, 9
November 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-6man-ipv6-over-wireless-09>.
[IEEE802154]
IEEE, "IEEE Standard for Information technology -- Local
and metropolitan area networks -- Specific requirements --
Part 15.4: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Low Rate Wireless
Personal Area Networks (WPANs)", IEEE Std 802.15.4-2006,
DOI 10.1109/IEEESTD.2006.232110, 2006,
<https://ieeexplore.ieee.org/document/1700009>.
[IEEE80211]
IEEE, "IEEE Standard for Information Technology --
Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Networks -- Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE
Std 802.11-2022, DOI 10.1109/IEEESTD.2021.9363693,
<https://ieeexplore.ieee.org/document/9363693>.
[WI-SUN] "Wi-SUN Alliance", <https://wi-sun.org/>. [WI-SUN] "Wi-SUN Alliance", <https://wi-sun.org/>.
[IEEE802151]
IEEE, "IEEE Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN - Specific
Requirements - Part 15: Wireless Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Wireless
Personal Area Networks (WPANs)", IEEE Std 802.15.1-2002,
DOI 10.1109/IEEESTD.2002.93621, 2002,
<https://ieeexplore.ieee.org/document/1016473>.
Acknowledgments Acknowledgments
Many thanks to Dave Thaler and Dan Romascanu for their early reviews, Many thanks to Dave Thaler and Dan Romascanu for their early reviews,
Adnan Rashid for all his contributions, and Éric Vyncke for his in- Adnan Rashid for all his contributions, and Éric Vyncke for his in-
depth AD review. Many thanks as well to the reviewers of the IETF depth AD review. Many thanks as well to the reviewers of the IETF
Last Call and IESG rounds: Dan Romascanu, Shuping Peng, Mohamed Last Call and IESG rounds: Dan Romascanu, Shuping Peng, Mohamed
Boucadair, Paul Wouters, Ketan Talaulikar, Gunter Van de Velde, Mike Boucadair, Paul Wouters, Ketan Talaulikar, Gunter Van de Velde, Mike
Bishop, and Roman Danyliw. Bishop, and Roman Danyliw.
Author's Address Author's Address
 End of changes. 42 change blocks. 
170 lines changed or deleted 165 lines changed or added

This html diff was produced by rfcdiff 1.48.