rfc9926.original.xml   rfc9926.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!--DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"-->
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902
"
tocInclude="true" indexInclude="true" obsoletes="" consensus="true"
submissionType="IETF" xml:lang="en" version="3" updates="4861, 6550, 8505, 8928
, 9010" docName="draft-ietf-6lo-prefix-registration-18" >
<front> <!--[rfced] Would you like to update the title for
readability?
<title abbrev="Prefix Registration">IPv6 Neighbor Discovery Prefix Registrati Original: IPv6 Neighbor Discovery Prefix Registration
on</title> Perhaps: Prefix Registration for IPv6 Neighbor Discovery
-->
<!-- [rfced] Because this document updates RFCs 4861, 6550,
8505, 8928, and 9010, please review the errata for each
of those RFCs:
https://www.rfc-editor.org/errata/rfc4861
https://www.rfc-editor.org/errata/rfc6550
https://www.rfc-editor.org/errata/rfc8505
https://www.rfc-editor.org/errata/rfc8928
https://www.rfc-editor.org/errata/rfc9010
and let us know if you confirm our opinion that none of them
are relevant to the content of this document.
-->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902
" tocInclude="true" indexInclude="true" obsoletes="" consensus="true" submissio
nType="IETF" xml:lang="en" version="3" updates="4861, 6550, 8505, 8928, 9010"
docName="draft-ietf-6lo-prefix-registration-18" number="9926" symRefs="true" sor
tRefs="false">
<front>
<title abbrev="Prefix Registration">IPv6 Neighbor Discovery Prefix Registrati
on</title>
<seriesInfo name="RFC" value="9926"/>
<author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor '> <author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor '>
<!-- <organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization > --> <!-- <organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization > -->
<address> <address>
<postal> <postal>
<city>Roquefort-les-Pins</city> <city>Roquefort-les-Pins</city>
<code>06330</code> <code>06330</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>pascal.thubert@gmail.com</email> <email>pascal.thubert@gmail.com</email>
</address> </address>
</author> </author>
<date month="January" year="2026"/>
<area>INT</area>
<workgroup>6lo</workgroup>
<area>Internet</area> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<workgroup>6lo</workgroup> <keyword>example</keyword>
<abstract> <abstract>
<t> <t>
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 neighbor router(s) to unicast prefix registration allows the node to request one or more neighbor r outers to
redistribute the prefix in another routing domain regardless of the redistribute the prefix in another routing domain regardless of the
routing protocol used in that domain. This document updates routing protocol used in that domain. This document updates
Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC 6550, the Routing Protocol for Low-Power and Lossy Networks (RPL), as specified in
RFC 9010) to enable a 6LoWPAN Router (6LR) to inject the RFCs 6550 and 9010, to enable a 6LoWPAN Router (6LR) to inject the
registered prefix in RPL. registered prefix in RPL.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="introduction"> <name>Introduction</name> <section anchor="introduction"> <name>Introduction</name>
<!--[rfced] Please clarify; is this a list of 3 items?
Original:
Other design constraints, such as a limited memory capacity,
duty cycling of the LLN devices and low-power lossy transmissions,
derive from that primary concern.
Perhaps:
Other design constraints (such as a limited memory capacity,
duty cycling of the LLN devices, and low-power lossy transmissions)
derive from that primary concern.
-->
<t>The design of Low Power and Lossy Networks (LLNs) is generally focused on <t>The design of Low Power and Lossy Networks (LLNs) is generally focused on
saving energy, which is the most constrained resource of all. Other design saving energy, which is the most constrained resource of all. Other design
constraints, such as a limited memory capacity, duty cycling of the LLN constraints, such as a limited memory capacity, duty cycling of the LLN
devices and low-power lossy transmissions, derive from that primary concern. devices, and low-power lossy transmissions, derive from that primary concern.
The radio (both transmitting or simply listening) is a major energy drain The radio (both transmitting or simply listening) is a major energy drain,
and the LLN protocols must be adapted to allow the nodes to remain sleeping and the LLN protocols must be adapted to allow the nodes to remain sleeping
with the radio turned off at most times. with the radio turned off at most times.
</t> <t> </t> <t>
Examples of LLNs include hub-and-spoke access links such as (Low-Power) W i-Fi Examples of LLNs include hub-and-spoke access links such as (Low-Power) W i-Fi
<xref target="IEEE80211"/> and Bluetooth (Low Energy) <xref target="IEEE80211"/> and Bluetooth (Low Energy)
<xref target="IEEE802151"/>, Mesh-Under networks where the routing <xref target="IEEE802151"/>, Mesh-Under networks where the routing
operation is handled at Layer-2, and Route-Over networks such as the Wi-SUN operation is handled at Layer 2 (L2), and route-over networks such as the Wi- SUN
<xref target="WI-SUN"/> and 6TiSCH <xref target="RFC9030"/> <xref target="WI-SUN"/> and 6TiSCH <xref target="RFC9030"/>
mesh networks, which leverage 6LoWPAN <xref target="RFC4919"/><xref target="R FC6282"/> mesh networks, which leverage 6LoWPAN <xref target="RFC4919"/> <xref target=" RFC6282"/>
and RPL <xref target="RFC6550"/> over <xref target="IEEE802154"/>. and RPL <xref target="RFC6550"/> over <xref target="IEEE802154"/>.
</t><t> </t><t>
LLNs and constrained devices are the original domain of application LLNs and constrained devices are the original domain of application
for 6LoWPAN protocols.  It is thus a foremost concern, when designing for 6LoWPAN protocols. It is thus a foremost concern, when designing
those protocols, to minimize energy spendings.  In non-LLN those protocols, to minimize energy spendings. In non-LLN
environments where lowering carbon emissions is also a priority, it environments where lowering carbon emissions is also a priority, it
could make sense to apply the 6LoWPAN designs and extend some of the could make sense to apply the 6LoWPAN designs and extend some of the
6LoWPAN protocols. 6LoWPAN protocols.
The general design points include: The general design points include:
</t> </t>
<ul> <ul>
<li> <li>
Placing the protocol complexity in the less-constrained routers to simplify the host implementation and avoid expanding the control traffic to all nodes. Placing the protocol complexity in the less-constrained routers to simplify the host implementation and avoid expanding the control traffic to all nodes.
</li> </li>
skipping to change at line 102 skipping to change at line 122
</t> </t>
<ul> <ul>
<li> <li>
Placing the protocol complexity in the less-constrained routers to simplify the host implementation and avoid expanding the control traffic to all nodes. Placing the protocol complexity in the less-constrained routers to simplify the host implementation and avoid expanding the control traffic to all nodes.
</li> </li>
<li> <li>
Using host-triggered operations to enable transient disconnections with the routers, e.g., Using host-triggered operations to enable transient disconnections with the routers, e.g.,
to conserve power (sleep), but also to cope with inconsistent connectivi ty. to conserve power (sleep), but also to cope with inconsistent connectivi ty.
</li> </li>
</ul> </ul>
<!--[rfced] Please clarify "This" in "This translates into:".
The preceding text is a list of design points, so perhaps
it may be updated to "These points translate into:"?
Original:
The general design points include:
* Placing the protocol complexity [...]
* Using host-triggered operations [...]
This translates into:
* Stateful proactively-built knowledge in the routers that is
available at any point of time.
* Unicast host to router operations triggered by the host and its
applications.
* Minimal use of asynchronous L2-broadcast operations that would
keep the host awake and listening with no application-level need
to do so.
-->
<t> <t>
This translates into: This translates into:
</t> </t>
<ul> <ul>
<li>Stateful proactively-built knowledge in the routers that is available at any point of time. <li>Stateful proactively built knowledge in the routers that is available at any point of time.
</li> </li>
<li> <li>
Unicast host to router operations triggered by the host and its applications . Unicast host-to-router operations triggered by the host and its applications .
</li> </li>
<li> <li>
Minimal use of asynchronous L2-broadcast operations that would keep the host awake and listening with no application-level need to do so. Minimal use of asynchronous L2 broadcast operations that would keep the host awake and listening with no application-level need to do so.
</li> </li>
</ul> </ul>
<t> <t>
The <xref target="RFC6550">"Routing Protocol for Low Power "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" <xref target="R
and Lossy Networks"</xref> (RPL) provides IPv6 <xref target="RFC8200"/> FC6550"/> provides IPv6 <xref target="RFC8200"/>
routing services within such constraints. routing services within such constraints.
To save signaling and routing state in constrained networks, the RPL routing To save signaling and routing state in constrained networks, the RPL routing
is only performed along a Destination-Oriented Directed Acyclic Graph (DODAG) is only performed along a Destination-Oriented Directed Acyclic Graph (DODAG)
that is optimized to reach a Root node, as opposed to along the shortest path that is optimized to reach a Root node, as opposed to along the shortest path
between 2 peers, whatever that would mean in each LLN. between two peers, whatever that would mean in each LLN.
</t><t> </t><t>
The classical Neighbor Discovery (IPv6 ND) Protocol (NDP) The classical Neighbor Discovery Protocol (NDP)
<xref target="RFC4861"/> <xref target="RFC4862"/> was defined for serial <xref target="RFC4861"/> <xref target="RFC4862"/> was defined for serial
links and shared transit media such as Ethernet at a time when L2-broadcast links and shared transit media such as Ethernet at a time when L2 broadcast
was cheap on those media while memory for neighbor cache was expensive. was cheap on those media, while memory for neighbor cache was expensive.
<!--[rfced] May this be rephrased for readability so DAD is first?
Original:
It was thus designed
as a reactive protocol that relies on caching and multicast
operations for the Address Resolution (AR, aka Address Discovery or
Address Lookup) and Duplicate Address Detection (DAD) of IPv6 unicast
addresses.
Perhaps:
Thus, it was designed
as a reactive protocol that relies on caching and multicast
operations for the Duplicate Address Detection (DAD) and Address
Resolution (AR), aka address discovery or address lookup, of IPv6
unicast addresses.
-->
It was thus designed as a reactive protocol that relies on caching and It was thus designed as a reactive protocol that relies on caching and
multicast operations for the Address Resolution (AR, aka Address Discovery or multicast operations for the Address Resolution (AR) (aka Address Discovery o r
Address Lookup) and Duplicate Address Detection (DAD) of IPv6 unicast address es. Address Lookup) and Duplicate Address Detection (DAD) of IPv6 unicast address es.
Those multicast operations typically impact every node on-link when at most Those multicast operations typically impact every node on-link when at most
one is really targeted, which is a waste of energy, and imply that all one is really targeted, which is a waste of energy, and imply that all
nodes are awake to hear the request, which is inconsistent with power nodes are awake to hear the request, which is inconsistent with power-saving
saving (sleeping) modes. (sleeping) modes.
</t><t> </t><t>
The <xref target="I-D.ietf-6man-ipv6-over-wireless"> "Architecture and Framework for IPv6 over Non-Broadcast Access" <xref target=
"Architecture and Framework for IPv6 over Non-Broadcast Access" (NBMA)</xref> "I-D.ietf-6man-ipv6-over-wireless"/>
introduces an evolution of IPv6 ND towards a proactive AR method. introduces an evolution of IPv6 ND towards a proactive AR method.
Because the IPv6 model for Because the IPv6 model for
NBMA depends on a routing protocol to reach inside the Subnet, the NBMA depends on a routing protocol to reach inside the Subnet, the
IPv6 ND extension for NBMA is referred to as Subnet Neighbor Discovery (SND). IPv6 ND extension for NBMA is referred to as Subnet Neighbor Discovery (SND).
SND is based on work done in the context of IoT, known as 6LoWPAN ND. SND is based on work done in the context of Internet of Things (IoT), known a
As opposed to the classical IPv6 ND Protocol, this evolution follows the s 6LoWPAN ND.
As opposed to the classical IPv6 ND protocol, this evolution follows the
energy conservation principles discussed above: energy conservation principles discussed above:
</t> </t>
<ul><li> <ul><li>
The original 6LoWPAN ND, <xref target="RFC6775"> "Neighbor Discovery The original 6LoWPAN ND, "Neighbor Discovery Optimization for IPv6 over Low-P
Optimizations for 6LoWPAN networks"</xref>, was introduced to avoid the ower Wireless Personal Area Networks (6LoWPANs)" <xref target="RFC6775"/>, was i
ntroduced to avoid the
excessive use of multicast messages and enable IPv6 ND for operations over excessive use of multicast messages and enable IPv6 ND for operations over
energy-constrained nodes. energy-constrained nodes.
<xref target="RFC6775"/> changes the classical IPv6 ND model to proactively <xref target="RFC6775"/> changes the classical IPv6 ND model to proactively
establish the Neighbor Cache Entry (NCE) associated to the unicast address of establish the Neighbor Cache Entry (NCE) associated to the unicast address of
a 6LoWPAN Node (6LN) in the 6LoWPAN Router(s) (6LRs) that serve it. a 6LoWPAN Node (6LN) in the one or more 6LoWPAN Routers (6LRs) that serve it.
To that effect, <xref target="RFC6775"/> defines a new Address Registration To that effect, <xref target="RFC6775"/> defines a new Address Registration
Option (ARO) that is placed in unicast Neighbor Solicitation (NS) and Option (ARO) that is placed in unicast Neighbor Solicitation (NS) and
Neighbor Advertisement (NA) messages between the 6LN and the 6LRs. Neighbor Advertisement (NA) messages between the 6LN and the 6LRs.
</li><li> </li><li>
<xref target="RFC8505"> "Registration Extensions for 6LoWPAN Neighbor "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Netwo
Discovery"</xref> updates <xref target="RFC6775"/> into a generic Address rk (6LoWPAN) Neighbor Discovery>" <xref target="RFC8505"/> updates <xref target=
"RFC6775"/> into a generic Address
Registration mechanism and is the foundation for Subnet Neighbor Discovery (S ND). Registration mechanism and is the foundation for Subnet Neighbor Discovery (S ND).
SND introduces the Extended Address Registration Option (EARO) to enable the SND introduces the Extended Address Registration Option (EARO) to enable the
registering node to access services such as routing inside a subnet registering node to access services such as routing inside a subnet
and ND proxy <xref target="RFC8929"/> operations. and ND proxy operations <xref target="RFC8929"/>.
This provides a routing-protocol-agnostic method for a host to This provides a routing-protocol-agnostic method for a host to
request that the router injects a unicast IPv6 address in the local routing request that the router inject a unicast IPv6 address in the local routing
protocol and provide return reachability for that address. protocol and provide return reachability for that address.
</li><li> </li><li>
<xref target="RFC9685"> "Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addr
"IPv6 Neighbor Discovery Multicast Address Listener Subscription"</xref> esses" <xref target="RFC9685"/>
updates <xref target="RFC8505"/> to enable a listener to subscribe to an IPv6 updates <xref target="RFC8505"/> to enable a listener to subscribe to an IPv6
anycast or multicast address; the draft also updates <xref target="RFC9010"/ > anycast or multicast address; the document also updates <xref target="RFC901 0"/>
to enable a 6LR to inject the anycast and multicast addresses in RPL. to enable a 6LR to inject the anycast and multicast addresses in RPL.
Similarly, this specification updates <xref target="RFC8505"/> and Similarly, this specification updates <xref target="RFC8505"/> and
<xref target="RFC9010"/> to add the capability for a 6LN to register unicast <xref target="RFC9010"/> to add the capability for a 6LN to register unicast
prefixes up to 120 bits long, as opposed to addresses, and to signal in a ro uting-protocol-independent prefixes up to 120 bits long, as opposed to addresses, and to signal in a ro uting-protocol-independent
fashion to a 6LR that it is expected to redistribute the prefixes. fashion to a 6LR that it is expected to redistribute the prefixes.
</li></ul> </li></ul>
<t> <t>
This specification updates the above registration and subscription methods This specification updates the above registration and subscription methods
to enable a node to register a unicast prefix to the routing system and get it i njected in the routing protocol. As with <xref target="RFC8505"/>, the prefix re gistration is agnostic to the routing protocol in which the router injects the p refix, and the router is agnostic to the method that was used to allocate the pr efix to the node. to enable a node to register a unicast prefix to the routing system and get it i njected in the routing protocol. As with <xref target="RFC8505"/>, the prefix re gistration is agnostic to the routing protocol in which the router injects the p refix, and the router is agnostic to the method that was used to allocate the pr efix to the node.
The energy conservation principles in <xref target="RFC8505"/> are retained as w ell, The energy conservation principles in <xref target="RFC8505"/> are retained as w ell,
meaning that the node does not have to send or expect asynchronous multicast mes sages. meaning that the node does not have to send or expect asynchronous multicast mes sages.
</t><t>
It can be noted that an energy-conserving node is not necessarily a router, so e
ven when advertising a prefix, it is a design choice not to use Router Advertise
ment (RA) messages that would make the node appear as a router to peer nodes. Fr
om the design principles above, it is clearly a design choice not to leverage br
oadcasts from or to the node, or complex state machines in the node. It is also
a design choice to use and extend the EARO as opposed to the Route Information
Option (RIO) <xref target="RFC4191"/> because the RIO is not intended to inject
routes in routing, and is lacking related control information like the R bit in
the EARO. Additionally, an RA with RIO cannot be trusted for a safe injection in
the routing protocol for the lack of the equivalent of the Registration Ownersh
ip Verifier (ROVR) <xref target="RFC8928"/> in the EARO.
</t> </t>
<!--[rfced] May this be rephrased as follows for clarity?
In the original, the repetition of "it" (with different antecedents)
is unclear.
</section> <!-- end section = "Introduction" --> Original:
It can be noted that an energy-conserving node is not necessarily a
router, so even when advertising a prefix, it is a design choice not
to use Router Advertisement (RA) messages that would make the node
appear as a router to peer nodes.
<section> <name>Terminology</name> Perhaps:
<section anchor="bcp"><name>Requirements Language</name> Please note that an energy-conserving node is not necessarily a
<t> router, so even when a node is advertising a prefix, it is a
design choice not to use Router Advertisement (RA) messages that would
make the node appear as a router to peer nodes.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Or:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and Note that an energy-conserving node is not necessarily a
"OPTIONAL" in this document are to be interpreted as described in BCP 14 router, so even when a node is advertising a prefix, a design
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, choice is not using Router Advertisement (RA) messages that
they appear in all capitals, as shown here. would make the node appear as a router to peer nodes.
-->
<!--[rfced] Please clarify this sentence. Is it a list of two items
that are not being leveraged?
</t> Original:
From the design principles above,
it is clearly a design choice not to leverage broadcasts from or to
the node, or complex state machines in the node.
<!-- <t> --> Perhaps:
<!-- In addition, the terms "updates" and "updates" are used as a more specifi From the design principles above,
c term for "Updates" per --> it is clearly a design choice not to leverage (1) broadcasts from or to
<!-- <xref target="I-D.kuehlewind-update-tag" /> section 3 as follows: --> the node or (2) complex state machines in the node.
<!-- </t> --> -->
<!-- <dl newline="false" indent="7" spacing="compact" > --> <t>
<!-- <dt><strong>updates/Amended by:</strong></dt> --> It can be noted that an energy-conserving node is not necessarily a router, so e
<!-- <dd>This tag pair is used with an amending RFC that ven when advertising a prefix, it is a design choice not to use Router Advertise
changes the amended RFC. This could include bug fixes, behavior changes etc. Thi ment (RA) messages that would make the node appear as a router to peer nodes. Fr
s is intended to specify mandatory changes to the protocol. The goal of this tag om the design principles above, it is clearly a design choice not to leverage br
pair is to signal to anyone looking to implement the amended RFC that they MUST oadcasts from or to the node, or complex state machines in the node. It is also
also implement the amending RFC. </dd> --> a design choice to use and extend the EARO as opposed to the Route Information
<!-- <dt><strong>updates/Extended by:</strong></dt> --> Option (RIO) <xref target="RFC4191"/> because the RIO is not intended to inject
<!-- <dd> This tag pair is used with an updating RFC that routes in routing, and is lacking related control information like the R bit in
defines an optional addition to the extended RFC. This can be used by documents the EARO. Additionally, an RA with RIO cannot be trusted for a safe injection in
that use existing extension points or clarifications that do not change existin the routing protocol for the lack of the equivalent of the Registration Ownersh
g protocol behavior. This signals to implementers and protocol designers that th ip Verifier (ROVR) <xref target="RFC8928"/> in the EARO.
ere are changes to the extended RFC that they need to consider but not necessari </t>
ly implement.</dd> -->
<!-- </dl> -->
</section> <!-- end section "Requirements Language" --> </section>
<section> <name>Terminology</name>
<section anchor="bcp"><name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section>
<section anchor="lo"><name>Inherited Terms and Concepts</name> <section anchor="lo"><name>Inherited Terms and Concepts</name>
<t> <t>
This document uses terms and concepts that are discussed in: This document uses terms and concepts that are discussed in:
</t> </t>
<ul> <ul>
<li> <xref target="RFC4861">"Neighbor Discovery for IP version 6" <li> "TLS User Mapping Extension" <xref target="RFC4861"/> and
</xref> and
</li><li> </li><li>
<xref target="RFC4862">"IPv6 Stateless Address Autoconfiguration" "IPv6 Stateless Address Autoconfiguration" <xref target="RFC4862"/> f
</xref> for the Neighbor Solicitation operation, or the Neighbor Solicitation operation,
</li> </li>
<li> <xref target="RFC6775">Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</xref>, as well as <li> "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Pe rsonal Area Networks (6LoWPANs)" <xref target="RFC6775"/>, as well as
</li> </li>
<li> <li>
<xref target="RFC8505"> "Registration Extensions for IPv6 over
"Registration Extensions for 6LoWPAN Neighbor Discovery" for SND Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" <xref ta
operations </xref> and rget="RFC8505"/>, and
</li> </li>
<li> <li>
<xref target="RFC6550">"Routing Protocol for Low Power "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" <xref target="
and Lossy Networks"</xref> for RPL, which is the routing protocol used in LLN RFC6550"/> for RPL, which is the routing protocol used in LLNs for SND.
s for SND.
</li> </li>
</ul> </ul>
</section> <!-- end section "References" --> </section>
<section anchor='acronyms' > <name>Acronyms and Initialisms</name> <section anchor='acronyms' > <name>Acronyms and Initialisms</name>
<t> This document uses the following abbreviations: <t> This document uses the following abbreviations:
<!-- [rfced] We have updated the expansion for LoWPAN as follows
to match usage in RFCs. Although the title of the cited document
[IEEE802154] uses the words "Low-Rate Personal Area Network", LoWPAN
has been expanded as follows in RFCs.
Original:
LoWPAN: Low-Rate Personal Area Network [IEEE802154]
Current:
LoWPAN: Low-Power Wireless Personal Area Network [IEEE802154]
-->
<!-- [rfced] Regarding usage of <strong> elements in this document.
please review the occurrences and let us know if any updates are
needed for consistency. Details below.
In the HTML and PDF outputs, <strong> yields bold.
In the text output, <strong> yields an asterisk before and after.
(Our suggestions below are due to the asterisks in the text output.)
- S 2.3: used for acronyms upon being defined.
- S 2.4: used for new terms upon being defined.
- S 5: used for flag name; does not match how "F" appears within Figure 1.
we suggest removing this usage.
- S 7.1, 13.1, 13.2: used for left-column values in Tables 1, 2 and 3;
we suggest removing this usage.
- S 7.2, 7.3: used for names of fields; does not match how they appear within
Figures 2 and 3; we suggest removing this usage.
-->
</t> </t>
<dl spacing='compact'> <dl spacing='compact' indent="12">
<dt><strong>6CIO:</strong></dt><dd> 6LoWPAN Capability Indication Option <xref target="RFC7400"/></dd> <dt><strong>6CIO:</strong></dt><dd> 6LoWPAN Capability Indication Option <xref target="RFC7400"/></dd>
<dt><strong>6LBR:</strong></dt><dd> 6LoWPAN Border Router <xref target=" RFC6775"/></dd> <dt><strong>6LBR:</strong></dt><dd> 6LoWPAN Border Router <xref target=" RFC6775"/></dd>
<dt><strong>6LN:</strong></dt><dd> 6LoWPAN Node <xref target="RFC6775"/> </dd> <dt><strong>6LN:</strong></dt><dd> 6LoWPAN Node <xref target="RFC6775"/> </dd>
<dt><strong>6LR:</strong></dt><dd> 6LoWPAN Router <xref target="RFC6775" /></dd> <dt><strong>6LR:</strong></dt><dd> 6LoWPAN Router <xref target="RFC6775" /></dd>
<dt><strong>ARO:</strong></dt><dd> Address Registration Option <xref tar get="RFC6775"/></dd> <dt><strong>ARO:</strong></dt><dd> Address Registration Option <xref tar get="RFC6775"/></dd>
<dt><strong>DAD:</strong></dt><dd> Duplicate Address Detection <xref targ et="RFC4861"/></dd> <dt><strong>DAD:</strong></dt><dd> Duplicate Address Detection <xref targ et="RFC4861"/></dd>
<dt><strong>DAO:</strong></dt><dd> Destination Advertisement Object <xref target="RFC6550"/> </dd> <dt><strong>DAO:</strong></dt><dd> Destination Advertisement Object <xref target="RFC6550"/> </dd>
<dt><strong>DODAG:</strong></dt><dd> Destination-Oriented Directed Acycli c Graph </dd> <dt><strong>DODAG:</strong></dt><dd> Destination-Oriented Directed Acycli c Graph </dd>
<dt><strong>EARO:</strong></dt><dd> Extended Address Registration Option <xref target="RFC8505"/></dd> <dt><strong>EARO:</strong></dt><dd> Extended Address Registration Option <xref target="RFC8505"/></dd>
<dt><strong>EDAC:</strong></dt><dd> Extended Duplicate Address Confirmati on <xref target="RFC8505"/> </dd> <dt><strong>EDAC:</strong></dt><dd> Extended Duplicate Address Confirmati on <xref target="RFC8505"/> </dd>
<dt><strong>EDAR:</strong></dt><dd> Extended Duplicate Address Request <x ref target="RFC8505"/></dd> <dt><strong>EDAR:</strong></dt><dd> Extended Duplicate Address Request <x ref target="RFC8505"/></dd>
<dt><strong>ESS:</strong></dt><dd> Extended Service Set <xref target=" IEEE80211"/></dd> <dt><strong>ESS:</strong></dt><dd> Extended Service Set <xref target=" IEEE80211"/></dd>
<dt><strong>IPAM:</strong></dt><dd> IP Address Management</dd> <dt><strong>IPAM:</strong></dt><dd> IP Address Management</dd>
<dt><strong>LLN:</strong></dt><dd> Low-Power and Lossy Network </dd> <dt><strong>LLN:</strong></dt><dd> Low-Power and Lossy Network </dd>
<dt><strong>LLA:</strong></dt><dd> Link Layer Address </dd> <dt><strong>LLA:</strong></dt><dd> Link-Layer Address </dd>
<dt><strong>LoWPAN:</strong></dt><dd> Low-Rate Personal Area Network <xr <dt><strong>LoWPAN:</strong></dt><dd> Low-Power Wireless Personal Area N
ef target="IEEE802154"/></dd> etwork <xref target="IEEE802154"/></dd>
<dt><strong>MAC:</strong></dt><dd> Medium Access Control</dd> <dt><strong>MAC:</strong></dt><dd> Medium Access Control</dd>
<dt><strong>NA:</strong></dt><dd> Neighbor Advertisement (message) <xref target="RFC4861"/></dd> <dt><strong>NA:</strong></dt><dd> Neighbor Advertisement (message) <xref target="RFC4861"/></dd>
<dt><strong>NBMA:</strong></dt><dd> Non-Broadcast Multi-Access (full mesh )</dd> <dt><strong>NBMA:</strong></dt><dd> Non-Broadcast Multi-Access (full mesh )</dd>
<dt><strong>NCE:</strong></dt><dd> Neighbor Cache Entry <xref target="RFC 4861"/> </dd> <dt><strong>NCE:</strong></dt><dd> Neighbor Cache Entry <xref target="RFC 4861"/> </dd>
<dt><strong>ND:</strong></dt><dd> Neighbor Discovery (protocol) </dd> <dt><strong>ND:</strong></dt><dd> Neighbor Discovery (protocol) </dd>
<dt><strong>NDP:</strong></dt><dd> Neighbor Discovery Protocol </dd> <dt><strong>NDP:</strong></dt><dd> Neighbor Discovery Protocol </dd>
<dt><strong>NS:</strong></dt><dd> Neighbor Solicitation (message) <xref t arget="RFC4861"/></dd> <dt><strong>NS:</strong></dt><dd> Neighbor Solicitation (message) <xref t arget="RFC4861"/></dd>
<dt><strong>ROVR:</strong></dt><dd> Registration Ownership Verifier (pron ounced "rover") <xref target="RFC8505"/> </dd> <dt><strong>ROVR:</strong></dt><dd> Registration Ownership Verifier (pron ounced "rover") <xref target="RFC8505"/> </dd>
<dt><strong>RPL:</strong></dt><dd>IPv6 Routing Protocol for LLNs (pronoun ced "ripple") <xref target="RFC6550"/></dd> <dt><strong>RPL:</strong></dt><dd>IPv6 Routing Protocol for LLNs (pronoun ced "ripple") <xref target="RFC6550"/></dd>
<dt><strong>RA:</strong></dt><dd> Router Advertisement (message) <xref ta rget="RFC4861"/></dd> <dt><strong>RA:</strong></dt><dd> Router Advertisement (message) <xref ta rget="RFC4861"/></dd>
<dt><strong>RS:</strong></dt><dd> Router Solicitation (message) <xref tar get="RFC4861"/> </dd> <dt><strong>RS:</strong></dt><dd> Router Solicitation (message) <xref tar get="RFC4861"/> </dd>
<dt><strong>RTO:</strong></dt><dd> RPL Target Option <xref target="RFC655 0"/> </dd> <dt><strong>RTO:</strong></dt><dd> RPL Target Option <xref target="RFC655 0"/> </dd>
<dt><strong>SLLAO:</strong></dt><dd>Source Link-Layer Address Option <xre f target="RFC4861"/> </dd> <dt><strong>SLLAO:</strong></dt><dd>Source Link-Layer Address Option <xre f target="RFC4861"/> </dd>
<dt><strong>SND:</strong></dt><dd>Subnet Neighbor Discovery (protocol)</d d> <dt><strong>SND:</strong></dt><dd>Subnet Neighbor Discovery (protocol)</d d>
<dt><strong>TID:</strong></dt><dd> Transaction ID <xref target="RFC8505"/ ></dd> <dt><strong>TID:</strong></dt><dd> Transaction ID <xref target="RFC8505"/ ></dd>
<dt><strong>TIO:</strong></dt><dd> Transit Information Option <xref targe t="RFC6550"/> </dd> <dt><strong>TIO:</strong></dt><dd> Transit Information Option <xref targe t="RFC6550"/> </dd>
<dt><strong>TLLAO:</strong></dt><dd>Target Link-Layer Address Option <xre f target="RFC4861"/> </dd> <dt><strong>TLLAO:</strong></dt><dd>Target Link-Layer Address Option <xre f target="RFC4861"/> </dd>
</dl> </dl>
</section><!-- Acronyms --> </section>
<section anchor="terms"><name>New terms</name> <section anchor="terms"><name>New Terms</name>
<t> This document introduces the following terms:</t> <t> This document introduces the following terms:</t>
<dl newline="false" indent="7" spacing="compact" > <dl newline="false" indent="7" spacing="compact" >
<dt><strong>Origin:</strong></dt><dd> The node that issued the prefix <dt><strong>Origin:</strong></dt><dd> The node that issued the prefix
advertisement, either in the form of a NS(EARO) or as a DAO(TIO, RTO) </d d> advertisement, either in the form of a NS(EARO) or as a DAO(TIO, RTO) </d d>
<!--[rfced] Please clarify this definition; are there 2 or 3 options?
Original:
*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).
Perhaps (if 2):
*Merge:* The process of aggregating multiple advertisements - received
internally as an NS(EARO) or externally as a DAO(TIO, RTO) - into
a single outgoing DAO(TIO, RTO).
Or(if 3):
*Merge:* The action of receiving multiple anycast or multicast
advertisements, either (1) internally from self, (2) in the form of a
NS(EARO), (3) or as a DAO(TIO, RTO), and generating a single
DAO(TIO, RTO).
-->
<dt><strong>Merge:</strong></dt><dd> The action of receiving multiple any cast or <dt><strong>Merge:</strong></dt><dd> The action of receiving multiple any cast or
multicast advertisements, either internally from self, in the form of 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). 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 s ingle advertisement. 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 s ingle advertisement.
A RPL router that merges then becomes the origin of the merged advertisem ent A RPL router that merges then becomes the origin of the merged advertisem ent
and uses its own values for the Path Sequence and ROVR fields. and uses its own values for the Path Sequence and ROVR fields.
</dd> </dd>
</dl> </dl>
</section>
</section> <!-- end section "New terms" --> </section>
</section> <!-- end section "Terminology" -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="overview"><name>Overview</name> <section anchor="overview"><name>Overview</name>
<t> <t>
This specification inherits from <xref target="RFC6550"/>, This specification inherits from <xref target="RFC6550"/>,
<xref target="RFC8505"/>, and <xref target="RFC9010"/> to register prefixes a s opposed to addresses. <xref target="RFC8505"/>, and <xref target="RFC9010"/> to register prefixes a s opposed to addresses.
</t><t> </t><t>
An SND deployment consists of: An SND deployment consists of:
</t> </t>
<ul> <ul>
<li> <li>
One or more 6LBR(s) that act(s) as RPL Root one or more 6LBRs that act as RPL Root,
</li> <li> </li> <li>
intermediate routers down the RPL graph that propagate routing information on addresses and prefixes intermediate routers down the RPL graph that propagate routing information on addresses and prefixes
towards the Root towards the Root,
</li> <li> </li> <li>
6LRs that are RPL-aware 6LNs and can leverage RPL directly to expose their ad dresses and prefixes 6LRs that are RPL-aware 6LNs and can leverage RPL directly to expose their ad dresses and prefixes, and
</li> <li> </li> <li>
and 6LNs that are the RPL-unaware destinations and need SND to obtain reachab ility tover the RPL LLN for their addresses and, with this specification, their prefixes as well. 6LNs that are the RPL-unaware destinations and need SND to obtain reachabilit y over the RPL LLN for their addresses and, with this specification, their prefi xes as well.
</li> </li>
</ul> </ul>
<t> <t>
The SND operation for prefixes inherits from that for unicast addresses, The SND operation for prefixes inherits from that for unicast addresses,
meaning that it is the same unless specified otherwise herein. meaning that it is the same unless specified otherwise herein.
In particular, forwarding a packet happens as specified in section 11 of In particular, forwarding a packet happens as specified in
<xref target="RFC6550"/>, including loop avoidance and detection, though in <xref target="RFC6550" section="11"/>, including loop avoidance and detection
the case of multicast multiple copies might be generated. . However, in
the case of multicast, multiple copies might be generated.
</t> </t>
<t><xref target="RFC8505"/> is a pre-requisite to this specification. <t><xref target="RFC8505"/> is a prerequisite to this specification.
A node that implements this MUST also implement <xref target="RFC8505"/>. A node that implements this <bcp14>MUST</bcp14> also implement <xref target="
RFC8505"/>.
This specification does not introduce a new option; it modifies This specification does not introduce a new option; it modifies
existing options and updates the associated behaviors to enable the existing options and updates the associated behaviors to enable the
Registration for prefixes as an extension to Registration for prefixes as an extension to
<xref target="RFC8505"/>. <xref target="RFC8505"/>.
</t> </t>
<!--[rfced] Is the meaning of "same" (4 instances in this sentence) clear, or
is the point (in last 2 instances) that there is one given prefix?
i.e., For the last 2 instances, the "same" as what?
Original:
Multiple 6LNs acting as border routers to the same external
network or as access routers to the same subnet may register the same
prefix to the same 6LR or to different 6LRs.
Perhaps:
Multiple 6LNs acting as border routers to the same external
network or as access routers to the same subnet may register
a given prefix to one 6LR or to different 6LRs.
-->
<t> <t>
This specification updates the P-Field introduced in <xref target= This specification updates the P-Field introduced in <xref target=
"RFC9685"/> for use in EARO, DAR, and RTO, "RFC9685"/> for use in EARO, DAR, and RTO,
with the new value of 3 to indicate the registration of a prefix, as with the new value of 3 to indicate the registration of a prefix, as
detailed in <xref target="R8505E"/>. detailed in <xref target="R8505E"/>.
With this extension, the 6LN can now express its willingness to receive the t raffic for all addresses in the range of a prefix, using the P-Field value of 3 in the EARO to signal that the With this extension, the 6LN can now express its willingness to receive the t raffic 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 prefix. Multiple 6LNs acting as border routers to th e same external network or as access routers to the same subnet may register the same prefix to the same 6LR or to different 6LRs. registration is for such prefix. Multiple 6LNs acting as border routers to th e same external network or as access routers to the same subnet may register the same prefix to the same 6LR or to different 6LRs.
</t><t> </t><t>
If the R flag is set in the registration of one or more 6LNs for the same If the R flag is set in the registration of one or more 6LNs for the same
prefix, then, according to its redistribution policy, the 6LR MUST prefix, then, according to its redistribution policy, the 6LR <bcp14>MUST</bc p14>
redistribute the prefix in the routing protocol(s) (e.g., RPL) that redistribute the prefix in the routing protocol(s) (e.g., RPL) that
it participates in. The duration of the redistribution is it participates in. The duration of the redistribution is
based on the longest registration lifetime across the based on the longest registration lifetime across the
non-expired received registrations for the prefix. non-expired received registrations for the prefix.`
</t><t> </t><t>
Examples of use-cases where this specification may apply include virtual lin Examples of use cases where this specification may apply include virtual lin
ks, shared links, ks, shared links,
and hub links as shown in <xref target="Shared"/> and <xref target="Hub"/>, and hub links as shown in Sections <xref target="Shared" format="counter"/>
respectively. and <xref target="Hub" format="counter"/>, respectively.
More generally, the 6LN may be a router running a different routing protocol in an More generally, the 6LN may be a router running a different routing protocol in an
external network, e.g., a stub network, and acting as a border router. external network, e.g., a stub network, and acting as a border router.
Using the prefix registration method enables decoupling the routing Using the prefix registration method enables decoupling the routing
protocol in the 6LN from the routing protocol that the 6LRs run in the main LLN protocol in the 6LN from the routing protocol that the 6LRs run in the main LLN
and provide signaling to stimulate the redistribution. and provide signaling to stimulate the redistribution.
</t> </t>
</section> <!-- end section "Overview" --> </section>
<section anchor="tgt4861"><name>Updating RFC 4861</name> <section anchor="tgt4861"><name>Updating RFC 4861</name>
<t> <t>
<!-- [rfced] Please review whether this sentence is accurate
and let us know if any changes are needed.
We note that Section 5.5 of [RFC8505] does not mention [RFC4861].
Also, regarding the "Updates" relationship between RFCs,
RFC 8505 updates RFC 6775, not RFC 4861.
Original:
Section 5.5 of [RFC8505] updates [RFC4861] to signal the Registered
Address in the Target Address field.
-->
<xref target="RFC4861"/> expects that the NS/NA exchange is for a unicast <xref target="RFC4861"/> expects that the NS/NA exchange is for a unicast
address, which is indicated in the Target Address field of the ND message. address, which is indicated in the Target Address field of the ND message.
Section 5.5 of <xref target="RFC8505"/> updates <xref target="RFC4861"/> <xref target="RFC8505" section="5.5"/> updates <xref target="RFC4861"/>
to signal the Registered Address in the Target Address field. to signal the Registered Address in the Target Address field.
</t> </t>
<t> <t>
This specification updates <xref target="RFC4861"/> by allowing a 6LN to adve rtise a This specification updates <xref target="RFC4861"/> by allowing a 6LN to adve rtise a
prefix in the Target Address field when the NS or NA message is used prefix in the Target Address field when the NS or NA message is used
for a registration, per section 5.5 of <xref target="RFC8505"/>; in that case for a registration, per <xref target="RFC8505" section="5.5"/>. In that case,
, the the
prefix length MUST be indicated in the EARO of the NS message, overloading prefix length <bcp14>MUST</bcp14> be indicated in the EARO of the NS message,
overloading
the field that is used in the NA response for the Status. the field that is used in the NA response for the Status.
</t> </t>
<t> <t>
If the 6LN owns at least one an IPv6 address that is derived from the If the 6LN owns at least one IPv6 address that is derived from the
registered prefix with a non-0 interface ID, then it MUST indicate registered prefix with a non-zero interface ID, then it <bcp14>MUST</bcp14> i
ndicate
one of these addresses in full in the Target Address field of the one of these addresses in full in the Target Address field of the
NS(EARO) message. Else, it MUST indicate the prefix padded with 0s NS(EARO) message. Else, it <bcp14>MUST</bcp14> indicate the prefix padded wit h zeros
in the Target Address field. in the Target Address field.
</t> </t>
</section> <!-- end section "Updating RFC 4861" --> </section>
<section anchor="CIO"><name>Updating RFC 7400</name> <section anchor="CIO"><name>Updating RFC 7400</name>
<t> <t>
This specification updates <xref target="RFC7400"> "6LoWPAN-GHC: Generic <!-- [rfced] How should the second sentence be updated for accuracy?
Header Compression for IPv6 over Low-Power Wireless Personal Area Networks The original is not accurate because RFC 8505 does not update RFC 7400.
(6LoWPANs)"</xref> by defining a new capability bit for use in the (RFC 8505 updates RFC 6775.)
Original:
This specification updates "6LoWPAN-GHC: Generic Header Compression
for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"
[RFC7400] by defining a new capability bit for use in the 6CIO.
[RFC7400] was already updated by [RFC8505] for use in IPv6 ND
messages.
-->
This specification updates "<xref format="title" target="RFC7400"/>" <xref ta
rget="RFC7400"/> by defining a new capability bit for use in the
6CIO. <xref target="RFC7400"/> was already updated by <xref target="RFC8505" /> for use in IPv6 ND messages. 6CIO. <xref target="RFC7400"/> was already updated by <xref target="RFC8505" /> for use in IPv6 ND messages.
</t> </t>
<!--[rfced] Why is "Supported" capitalized here? If this may be
changed, then we will ask IANA to update the registry
(https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#sixl
owpan-capability-bits) based on your reply.
Original:
The new "Registration for prefixes Supported" (F) flag indicates ...
Perhaps:
The new "Registration for prefixes supported (F bit)" indicates ...
Or (if you prefer title case, which is similar to X flag in that registry):
The new "Registration for Prefixes Supported (F bit)" indicates ...
-->
<t> <t>
The new "Registration for prefixes Supported" (F) flag indicates The new "Registration for prefixes Supported" (F) flag indicates
to the 6LN that the 6LR accepts IPv6 prefix to the 6LN that the 6LR (1) accepts IPv6 prefix
registrations as specified in this document and will ensure that packets registrations as specified in this document, (2) will ensure that packets
for the addresses that match this prefix will be routed to the 6LNs that for the addresses that match this prefix will be routed to the 6LNs that
registered the prefix, and the route to the prefix will be redistributed if registered the prefix, and (3) will ensure that the route to the prefix will be redistributed if
the R flag is set to 1. the R flag is set to 1.
</t> </t>
<t> <t>
<xref target="fig6CIO"/> illustrates the F flag in its position <xref target="fig6CIO"/> illustrates the F flag in its position
(16, counting 0 to 47 in network order in the 48-bit array). (16, counting 0 to 47 in network order in the 48-bit array).
</t><t>
- to be confirmed by IANA
</t><t>
- and updated by RFC Editor if needed.
</t> </t>
<figure anchor="fig6CIO"><name>New Capability Bit in the 6CIO</name> <figure anchor="fig6CIO"><name>New Capability Bit in the 6CIO</name>
<artwork> <artwork><![CDATA[
<![CDATA[ 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 | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> </figure>
<t> New Option Field: </t> <t> New Option Field: </t>
<dl> <dl spacing="normal" newline="false">
<dt><strong>F:</strong></dt><dd> 1-bit flag, set to 1 to indicate "Regist ration for prefixes Supported" </dd> <dt><strong>F:</strong></dt><dd> 1-bit flag, set to 1 to indicate "Regist ration for prefixes Supported" </dd>
</dl> </dl>
</section> <!-- end section "Updating RFC 7400" --> </section>
<section anchor="coex"><name>Updating RFC 6550</name> <section anchor="coex"><name>Updating RFC 6550</name>
<t> <t>
<xref target="RFC6550"/> uses the Path Sequence in the Transit Information <xref target="RFC6550"/> uses the Path Sequence in the Transit Information
Option (TIO) to retain only the freshest unicast route and remove stale ones, Option (TIO) to retain only the freshest unicast route and remove stale ones,
e.g., in the case of mobility. <xref target="RFC9010"/> copies the TID from e.g., in the case of mobility. <xref target="RFC9010"/> copies the TID from
the EARO into the Path Sequence, and the ROVR field into the associated RPL the EARO into the Path Sequence, and the ROVR field into the associated RPL
Target Option (RTO). Target Option (RTO).
This way, it is possible to identify both the registering node and the This way, it is possible to identify both the registering node and the
order of registration in RPL for each individual advertisement, so the order of registration in RPL for each individual advertisement, so the
most recent path and lifetime values are used. most recent path and lifetime values are used.
</t><t> </t><t>
<xref target="RFC9685"/> requires the use of the <xref target="RFC9685"/> requires the use of the
ROVR field as the indication of the origin of a Target advertisement in the ROVR field as the indication of the origin of a Target advertisement in the
RPL DAO messages, as specified in section 6.1 of <xref target="RFC9010"/>. RPL DAO messages, as specified in <xref target="RFC9010" section="6.1"/>.
For anycast and multicast advertisements (in NS or DAO messages), multiple For anycast and multicast advertisements (in NS or DAO messages), multiple
origins may subscribe to the same address, in which case the multiple origins may subscribe to the same address, in which case the multiple
advertisements from the different or unknown origins are merged by the common advertisements from the different or unknown origins are merged by the common
parent; in that case, the common parent becomes the origin of the merged parent. In that case, the common parent becomes the origin of the merged
advertisements and uses its own ROVR value. On the other hand, a parent that advertisements and uses its own ROVR value. On the other hand, a parent that
propagates an advertisement from a single origin uses the original ROVR in propagates an advertisement from a single origin uses the original ROVR in
the propagated RTO, as it does for unicast address advertisements, so the the propagated RTO, as it does for unicast address advertisements, so the
origin is recognized across multiple hops. origin is recognized across multiple hops.
</t><t> </t><t>
This specification updates <xref target="RFC6550"/> to require that, This specification updates <xref target="RFC6550"/> to require that,
for prefix routes, the Path Sequence is used between and only between for prefix routes, the Path Sequence is used between and only between
advertisements for the same Target and from the same origin (i.e., with the s ame ROVR value); in that case, only the freshest advertisement is retained. But the freshness comparison cannot apply if the advertisements for the same Target and from the same origin (i.e., with the s ame ROVR value); in that case, only the freshest advertisement is retained. Howe ver, the freshness comparison cannot apply if the
origin is not determined (i.e., the origin did not support this specification ). origin is not determined (i.e., the origin did not support this specification ).
</t><t> </t><t>
<xref target="RFC6550"/> uses the Path Lifetime in the TIO to indicate the <xref target="RFC6550"/> uses the Path Lifetime in the TIO to indicate the
remaining time for which the advertisement is valid for unicast route remaining 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.
<xref target="RFC9010"/> maps the Address Registration lifetime in the EARO <xref target="RFC9010"/> maps the Address Registration lifetime in the EARO
and the Path Lifetime in the TIO so they are comparable when both forms of and the Path Lifetime in the TIO so they are comparable when both forms of
advertisements are received. advertisements are received.
</t><t> </t>
<!--[rfced] FYI, we updated this text to clarify the "that is" phrase
and be more similar to RFC 9685 (Section 6).
Please let us know any further updates. Do you want to include
"if there is only one" and "if there is more than one"?
Original:
When the lifetime
expires, the router sends a no-path DAO (i.e., the lifetime is 0)
using the same value for ROVR value as for the previous
advertisements, that is either itself or the single descendant that
advertised the Target.
Current:
When the lifetime
expires, the router sends a no-path DAO (i.e., the lifetime 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
single descendant that advertised the Target.
For comparison, from RFC 9685 (Section 6):
When the lifetime expires, the router sends a no-path
DAO message (i.e., the lifetime is 0) using the same value for the
ROVR value as for the previous advertisements. This value refers to
either the single descendant that advertised the Target if there is
only one or the router itself if there is more than one.
-->
<t>
The RPL router that merges multiple advertisements for the same prefix The RPL router that merges multiple advertisements for the same prefix
uses and advertises the longest remaining lifetime uses and advertises the longest remaining lifetime
across all the origins of the advertisements for that prefix. across all the origins of the advertisements for that prefix.
When the lifetime expires, the router sends a no-path DAO (i.e., the lifetime When the lifetime expires, the router sends a no-path DAO (i.e., the lifetime
is 0) using the same value for ROVR value as for the previous advertisements, is 0) using the same value for the ROVR value as for the previous advertiseme
that is either itself or the single descendant that advertised the Target. nts.
This value refers to either the router itself or the single descendant that a
dvertised the Target.
</t><t> </t><t>
Note that the Registration Lifetime, TID and ROVR fields are also placed in Note that the Registration Lifetime, TID, and ROVR fields are also placed in
the EDAR message so the state created by EDAR is also comparable with that cr the EDAR message, so the state created by EDAR is also comparable with that c
eated upon an NS(EARO) or a DAO message. For simplicity the text below reated upon an NS(EARO) or a DAO message. For simplicity, the text below
mentions only NS(EARO) but applies also to EDAR. mentions only NS(EARO) but it also applies to EDAR.
</t> </t>
</section> <!-- end section "Updating RFC 6550" --> </section>
<section anchor="updating"><name>Updating RFC 8505</name> <section anchor="updating"><name>Updating RFC 8505</name>
<t> <t>
This specification updates the EARO and EDAR messages to enable the registration of prefixes and updates the Registration operation in the case of a prefix, in particular from the standpoint of the 6LR, e.g., to enable the Registration of o verlapping prefixes. This specification updates the EARO and EDAR messages to enable the registration of prefixes and updates the Registration operation in the case of a prefix, in particular from the standpoint of the 6LR, e.g., to enable the Registration of o verlapping prefixes.
</t> </t>
<section anchor="R8505EF"><name>New P-Field value</name> <section anchor="R8505EF"><name>New P-Field Value</name>
<!-- <t> <xref target="RFC9685"/> defines a 2-bits P-Field with values from 0 to
2, and reserves value 3. -->
<!-- This specification defines value 3 for the P-Field, and uses it to signa
l that the -->
<!-- Registered Address is a prefix. When the P-Field is set to 3, the receiv
er installs a route to the -->
<!-- prefix via the sender's address used as source address in the NS(EARO) -
->
<!-- registration message. -->
<!-- </t> -->
<t> <xref target="RFC9685"/> defines a 2-bit P-Field with values 0 through 2 an d reserves the <t> <xref target="RFC9685"/> defines a 2-bit P-Field with values 0 through 2 an d reserves the
value 3 for future use. This specification defines the semantics of P-Field value 3 for future use. This specification defines the semantics of P-Field
value 3. value 3.
</t><t> </t><t>
When the P-Field is set to 3, it indicates that the Registered Address When the P-Field is set to 3, it indicates that the Registered Address
represents a prefix rather than a single address. Upon receiving an NS(EARO) represents a prefix rather than a single address. Upon receiving an NS(EARO)
message with the P-Field set to 3, the receiver MUST install a route to the message with the P-Field set to 3, the receiver <bcp14>MUST</bcp14> install a ro ute to the
indicated prefix via the source address of the NS(EARO) message. indicated prefix via the source address of the NS(EARO) message.
</t><t> </t><t>
This specification assigns the value 3 to the P-Field, resulting in the This specification assigns the value 3 to the P-Field, resulting in the
following complete set of defined values: following complete set of defined values:
</t> </t>
<table anchor="pVALS" ><name>P-Field Values</name> <!--[rfced] In Table 1, this meaning has been updated to exactly match
the IANA registry. Please let us know if that is not your intention.
(See https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#
p-field-values)
Original: 3 | Registration for a Unicast prefix
Current: 3 | Registration for a Prefix
Due to this, please review whether any other updates updates
are needed. For example, in Section 1, should "unicast" be removed here?
Original:
This specification updates the above registration and subscription
methods to enable a node to register a unicast prefix to the routing
system and get it injected in the routing protocol.
-->
<table anchor="pVALS" ><name>P-Field Values</name>
<thead> <thead>
<tr><td>Value</td><td>Meaning</td></tr> <tr><th>Value</th><th>Meaning</th></tr>
</thead><tbody> </thead><tbody>
<tr><td><strong>0</strong></td><td>Registration for a Unicast Address</td> </tr> <tr><td><strong>0</strong></td><td>Registration for a Unicast Address</td> </tr>
<tr><td><strong>1</strong></td><td>Registration for a Multicast Address</t d></tr> <tr><td><strong>1</strong></td><td>Registration for a Multicast Address</t d></tr>
<tr><td><strong>2</strong></td><td>Registration for an Anycast Address</td ></tr> <tr><td><strong>2</strong></td><td>Registration for an Anycast Address</td ></tr>
<tr><td><strong>3</strong></td><td>Registration for a Unicast prefix</td>< /tr> <tr><td><strong>3</strong></td><td>Registration for a Prefix</td></tr>
</tbody> </tbody>
</table> <!-- end table "P-Field values" --> </table>
</section><!-- New P-Field value --> </section>
<section anchor="R8505E"><name>New EARO Prefix Length Field and F flag</name> <section anchor="R8505E"><name>New EARO Prefix Length Field and F flag</name>
<t> <t>
Section 4.1 of <xref target="RFC8505"/> defines the EARO as an extension to <xref target="RFC8505" section="4.1"/> defines the EARO as an extension to
the ARO option defined in <xref target="RFC6775"/>. the ARO option defined in <xref target="RFC6775"/>.
</t> </t>
<t> <t>
The Status field is used only when the EARO is placed in an NA message. The Status field is used only when the EARO is placed in an NA message.
This specification repurposes that field to carry the prefix length This specification repurposes that field to carry the prefix length
when the EARO is placed in an NS message as illustrated in <xref target="EARO" />. when the EARO is placed in an NS message as illustrated in <xref target="EARO" />.
The prefix length is expressed as 7 bits and the most significant bit of the f ield The prefix length is expressed as 7 bits, and the most significant bit of the field
is reserved. A 7-bit value of 0 is understood as a truncated 128, meaning that is reserved. A 7-bit value of 0 is understood as a truncated 128, meaning that
this registration is for an address as opposed to a prefix. this registration is for an address as opposed to a prefix.
This approach is backward compatible with <xref target="RFC8505"/> and spans This approach is backward compatible with <xref target="RFC8505"/> and spans
both addresses and prefixes. both addresses and prefixes.
</t> </t>
<t> <t>
This specification adds a new F flag to signal that the Registered Prefix This specification adds a new F flag to signal that the Registered Prefix
is topologically correct through the Registering Node. This means that the is topologically correct through the Registering Node. This means that the
Registering Node relays packets that are sourced in the Registered Prefix Registering Node relays packets that are sourced in the Registered Prefix
to the outside, in accordance with to the outside, in accordance with "<xref target="RFC2827" format="title"/>"
<xref target="RFC2827">"Network Ingress Filtering"</xref> . <xref target="BCP38"/>.
The receiver forwards packets to the Registering Node The receiver forwards packets to the Registering Node
address when the source address of the packets derives from the Registered Pr efix. address when the source address of the packets derives from the Registered Pr efix.
Note that to avoid loops, the receiver must be in the inside so packets Note that to avoid loops, the receiver must be in the inside so packets
sent by the sender towards the outside may never reach the receiver. sent by the sender towards the outside may never reach the receiver.
The notion of inside and outside are administratively defined, e.g., inside The notion of "inside" and "outside" are administratively defined, e.g., "ins
is a particular Layer-2 network such as an Ethernet fabric. ide"
is a particular L2 network such as an Ethernet fabric.
</t> </t>
<t> <t>
When the F flag is not set, the Registering Node owns the prefix and will When the F flag is not set, the Registering Node owns the prefix and will
deliver packets to the destination if the destination address derives deliver packets to the destination if the destination address derives
from the prefix. Conversely, if the F flag is set, the Registering Node will from the prefix. Conversely, if the F flag is set, the Registering Node will
forward traffic whose source address derives from the Registered Prefix into forward traffic whose source address derives from the Registered Prefix into
a network location (e.g., to an ISP Provider Edge) where this source address a network location (e.g., to an ISP Provider Edge) where this source address
is topologically correct (e.g., derives from a prefix assigned by that ISP). is topologically correct (e.g., derives from a prefix assigned by that ISP).
The F flag is encoded in the most significant bit of the EARO Status field The F flag is encoded in the most significant bit of the EARO Status field
when the Status field is used to transport a Prefix Length as shown in when the Status field is used to transport a Prefix Length as shown in
<xref target="EARO"/>. <xref target="EARO"/>.
</t> </t>
<figure anchor="EARO"><name>EARO Format for Use in NS Messages</name> <figure anchor="EARO"><name>EARO Format for Use in NS Messages</name>
<artwork align="center"> <artwork align="center"><![CDATA[
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 | Length |F|Prefix Length| Opaque | | Type | Length |F|Prefix Length| Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r|C| P | I |R|T| TID | Registration Lifetime | |r|C| P | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... ROVR ... ... ROVR ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure><!-- end figure "EARO Option Format" -->
<t> New and updated Option Fields: </t> <t> New and updated Option Fields: </t>
<dl> <dl>
<dt><strong>F:</strong> (Forwarding Flag)</dt><dd> <dt><strong>F:</strong> (Forwarding Flag)</dt><dd>
A 1-bit flag. When set to 1, it indicates that the sender expects A 1-bit flag. When set to 1, it indicates that the sender expects
other routers to forward packets to the sender when those packets other routers to forward packets to the sender when those packets
are sourced from within the registered prefix.</dd> are sourced from within the registered prefix.</dd>
<dt><strong>Prefix Length:</strong></dt><dd> <dt><strong>Prefix Length:</strong></dt><dd>
A 7-bit unsigned integer. When the P-Field is set to 3 and the EARO is inclu ded A 7-bit unsigned integer. When the P-Field is set to 3 and the EARO is inclu ded
in an NS message, this field MUST contain a prefix in an NS message, this field <bcp14>MUST</bcp14> contain a prefix
length expressed in bits, with a value between 16 and 120 inclusive. When the length expressed in bits, with a value between 16 and 120 inclusive. When the
EARO is included in an NA message, this field MUST EARO is included in an NA message, this field <bcp14>MUST</bcp14>
carry a status value, regardless of the setting of the P-Field. In all other carry a status value, regardless of the setting of the P-Field. In all other
cases, this field is reserved; it MUST be set to zero by the sender and MUST be cases, this field is reserved; it <bcp14>MUST</bcp14> be set to zero by the s ender and <bcp14>MUST</bcp14> be
ignored by the receiver. ignored by the receiver.
</dd> </dd>
<dt><strong>r</strong> (reserved):</dt> <dt><strong>r</strong> (reserved):</dt>
<dd>A 1-bit reserved field. It MUST be set to zero by the sender and <dd>A 1-bit reserved field. It <bcp14>MUST</bcp14> be set to zero by the send
MUST be ignored by the receiver.</dd> er and
<bcp14>MUST</bcp14> be ignored by the receiver.</dd>
</dl> </dl>
</section> <!-- end section "New EARO Prefix Length Field" --> </section>
<section anchor="R8505D"><name>New EDAR Prefix Length Field</name> <section anchor="R8505D"><name>New EDAR Prefix Length Field</name>
<t> <t>
This specification adds the new value of 3 to the P-Field to signal that the 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 prefix is 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 to 120 bits, and th e assumed to be at most 120 bits long, padded with zeros up to 120 bits, and th e
remaining byte is dedicated to one reserved bit and the prefix length. remaining byte is dedicated to one reserved bit and the prefix length.
</t> </t>
<t> <t>
<xref target="EDAR"/> illustrates the EDAR message when the value of the <xref target="EDAR"/> illustrates the EDAR message when the value of the
P-Field is 3. <xref target="EDAC"/> shows the response EDAC message, P-Field is 3. <xref target="EDAC"/> shows the response EDAC message,
with the Status field and the echoed Prefix. with the Status field and the echoed Prefix.
</t> </t>
<figure anchor="EDAR"><name>EDAR Message Format with P == 3</name> <figure anchor="EDAR"><name>EDAR Message Format with P == 3</name>
<artwork align="center"> <artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P=3| Reserved | TID | Registration Lifetime | |P=3| Reserved | TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... ROVR ... ... ROVR ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Prefix + + Prefix +
| | | |
+ (up to 120 bits, padded with 0s) + + (up to 120 bits, padded with zeros) +
| | | |
+ +-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+
| |r|Prefix Length| | |r|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>
</artwork> </figure>
</figure><!-- end figure "EDAR Message Format with P == 3" -->
<figure anchor="EDAC"><name>EDAC Message Format</name> <figure anchor="EDAC"><name>EDAC Message Format</name>
<artwork align="center"> <artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TID | Registration Lifetime | | Status | TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... ROVR ... ... ROVR ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Prefix + + Prefix +
| | | |
+ (up to 120 bits, padded with 0s) + + (up to 120 bits, padded with zeros) +
| | | |
+ +-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+
| |r|Prefix Length| | |r|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>
</artwork> </figure>
</figure><!-- end figure "EDAR Message Format with P == 3" -->
<t> New and updated EDAR/EDAC Message Fields: </t> <t> New and updated EDAR/EDAC Message Fields: </t>
<dl> <dl>
<dt><strong>Prefix:</strong></dt><dd>A 15-byte field that carries up <dt><strong>Prefix:</strong></dt><dd>A 15-byte field that carries up
to 120 bits of the prefix. If the prefix isshorter than 120 bits, the to 120 bits of the prefix. If the prefix is shorter than 120 bits, the
remaining bits MUST be padded with zeros. remaining bits <bcp14>MUST</bcp14> be padded with zeros.
The receiver MUST treat the padding as zeroed and MUST overwrite any The receiver <bcp14>MUST</bcp14> treat the padding as zeroed and <bcp14>MUST<
/bcp14> overwrite any
unused bits with zeros before using the prefix.</dd> unused bits with zeros before using the prefix.</dd>
<dt><strong>r</strong> (reserved):</dt> <dt><strong>r</strong> (reserved):</dt>
<dd>A 1-bit reserved field. It MUST be set to zero by the sender and <dd>A 1-bit reserved field. It <bcp14>MUST</bcp14> be set to zero by the send
MUST be ignored by the receiver.</dd> er and
<bcp14>MUST</bcp14> be ignored by the receiver.</dd>
<!--[rfced] If these phrases have the same meaning, would you like to
make them consistent?
Section 7.2: between 16 and 120 inclusive
Section 7.3: in the inclusive range of 16 to 120
-->
<dt><strong>Prefix Length:</strong></dt><dd>A 7-bit unsigned integer <dt><strong>Prefix Length:</strong></dt><dd>A 7-bit unsigned integer
indicating the length of the prefix in bits. The value MUST be in the indicating the length of the prefix in bits. The value <bcp14>MUST</bcp14> be in the
inclusive range of 16 to 120.</dd> inclusive range of 16 to 120.</dd>
</dl> </dl>
<t> <t>
The capability to place The P-Field and the contiguous "Reserved" field in th e EDAR message are specified in section 7.2 of <xref target="RFC9685"/>. The capability to place the P-Field and the contiguous "Reserved" field in th e EDAR message is specified in <xref target="RFC9685" section="7.2"/>.
</t> </t>
<t> <t>
The capability to append ND options to the EDAR and EDAC messages is introduc ed in section 3.1 of <xref target="RFC8929"/>. The capability to append ND options to the EDAR and EDAC messages is introduc ed in <xref target="RFC8929" section="3.1"/>.
</t> </t>
<t> <t>
All other fields follow the same definition as specified in <xref target="RFC 8505"/>. All other fields follow the same definition as specified in <xref target="RFC 8505"/>.
The values for these fields and RFC references are maintained by IANA under t he "Internet Control Message The values for these fields and RFC references are maintained by IANA under t he "Internet Control Message
Protocol version 6 (ICMPv6) Parameters" <xref target="IANA.ICMP"/> registry grouping. Protocol version 6 (ICMPv6) Parameters" <xref target="IANA.ICMP"/> registry group.
</t> </t>
</section> <!-- end section "New EDAR Prefix Length Field" --> </section>
<section anchor="multireg"><name>Updating the Registration Operation</name> <section anchor="multireg"><name>Updating the Registration Operation</name>
<t> <t>
With <xref target="RFC8505"/>: With <xref target="RFC8505"/>:
</t> </t>
<ul> <ul>
<li> <li>
A router that expects to reboot may send a final RA message, upon which A router that expects to reboot may send a final RA message, upon which
nodes should register elsewhere or redo the registration to the same router nodes should register elsewhere or redo the registration to the same router
upon reboot. upon reboot.
In all other cases, a node reboot is silent. In all other cases, a node reboot is silent.
When the node comes back to life, existing registration When the node comes back to life, existing registration
state might be lost if it was not safely stored, e.g., in persistent memory. state might be lost if it was not safely stored, e.g., in persistent memory.
</li> </li>
<li> <li>
Only unicast addresses can be registered. Only unicast addresses can be registered.
</li> </li>
<li> <li>
The 6LN must register all its Unique Local Addresses (ULAs) and Global Unicas t Addresses (GUAs) with a NS(EARO). The 6LN must register all its Unique Local Addresses (ULAs) and Global Unicas t Addresses (GUAs) with a NS(EARO).
</li> </li>
<!--[rfced] How may this be rephrased for clarity? Specifically,
"by the LR" is unclear.
If these are 2 methods of obtaining return reachability services,
then we suggest parallel structure as follows. Adding numbering
is optional.
Original:
* The 6LN may set the R flag in the EARO to obtain return
reachability services by the 6LR, e.g., through ND proxy
operations, or by injecting the route in a route-over subnet.
Perhaps:
* The 6LN may set the R flag in the EARO to obtain return
reachability services (1) by relying on the 6LR, e.g.,
through ND proxy operations, or (2) by injecting the route in
a route-over subnet.
-->
<li> <li>
The 6LN may set the R flag in the EARO to obtain return reachability services by the 6LR, e.g., through ND proxy operations, or by injecting the route in a r oute-over subnet. The 6LN may set the R flag in the EARO to obtain return reachability services by the 6LR, e.g., through ND proxy operations, or by injecting the route in a r oute-over subnet.
</li> </li>
<li> <li>
The 6LR maintains a registration state per Registered Address, including an The 6LR maintains a registration state per Registered Address, including an
NCE with the Link Layer Address (LLA) of the Registered Node (the 6LN here). NCE with the Link Layer Address (LLA) of the Registered Node (the 6LN here).
</li> </li>
</ul> </ul>
<t> <t>
The operation for registering prefixes is similar to that for addresses from the The operation for registering prefixes is similar to that for addresses from the
skipping to change at line 768 skipping to change at line 973
<ul> <ul>
<li> <li>
<t> <t>
The EARO status indicating a "Registration Refresh Request" applies to prefix es The EARO status indicating a "Registration Refresh Request" applies to prefix es
as well. as well.
</t> </t>
<t> <t>
This status is used in asynchronous NA(EARO) messages to indicate to peer 6LN s This status is used in asynchronous NA(EARO) messages to indicate to peer 6LN s
that they are requested to reregister all addresses and prefixes that were that they are requested to reregister all addresses and prefixes that were
previously registered to the originating node. The NA message MAY be sent to previously registered to the originating node. The NA message <bcp14>MAY</bcp
a unicast or a multicast link-scope address and SHOULD be contained within 14> be sent to
a unicast or a multicast link-scope address and <bcp14>SHOULD</bcp14> be cont
ained within
the L2 range where nodes may effectively have registered/subscribed to this the L2 range where nodes may effectively have registered/subscribed to this
router, e.g., a radio broadcast domain to preserve energy and spectrum. router, e.g., a radio broadcast domain to preserve energy and spectrum.
</t> </t>
<t> <t>
A device that wishes to refresh its state, e.g., upon reboot if it may have A device that wishes to refresh its state, e.g., upon reboot if it may have
lost some registration state, SHOULD send an asynchronous NA(EARO) with this lost some registration state, <bcp14>SHOULD</bcp14> send an asynchronous NA(E
new status value. That asynchronous NA(EARO) SHOULD be sent to the all-nodes ARO) with this
link-scope multicast address (ff02::1) and Target MUST be set to the new status value. That asynchronous NA(EARO) <bcp14>SHOULD</bcp14> be sent to
the all-nodes
link-scope multicast address (ff02::1), and Target <bcp14>MUST</bcp14> be set
to the
link-local address that was exposed previously by this node to accept link-local address that was exposed previously by this node to accept
registrations, and the TID MUST be set to 0; the ROVR field MUST be set to registrations, and the TID <bcp14>MUST</bcp14> be set to 0; the ROVR field <b
all zeroes and ignored by the receiver. cp14>MUST</bcp14> be set to
all zeros and ignored by the receiver.
</t> </t>
<t> <t>
In an environment with unreliable transmissions, the multicast NA(EARO) In an environment with unreliable transmissions, the multicast NA(EARO)
message may be resent in a fast sequence, in which case the TID is incremente d each time. message may be resent in a fast sequence, in which case the TID is incremente d each time.
A 6LN that has recently A 6LN that has recently
processed the NA(EARO) indicating a "Registration Refresh Request" processed the NA(EARO) indicating a "Registration Refresh Request"
ignores the additional NA(EARO) also ignores the additional NA(EARO) also
indicating a "Registration Refresh Request" within the duration of indicating a "Registration Refresh Request" within the duration of
the fast sequence. That duration depends on the the fast sequence. That duration depends on the
environment and has to be configured. By default, it is 10 seconds. environment and has to be configured. By default, it is 10 seconds.
skipping to change at line 805 skipping to change at line 1010
<t> <t>
Registration for prefixes is now supported. The value of 3 in the P-Field of Registration for prefixes is now supported. The value of 3 in the P-Field of
the EARO and the EDAR message signals when the registration is for a prefix the EARO and the EDAR message signals when the registration is for a prefix
as opposed to an address. DAD for prefixes and addresses becomes a prefix as opposed to an address. DAD for prefixes and addresses becomes a prefix
overlap match. Whether overlapping addresses and prefixes may be registered overlap match. Whether overlapping addresses and prefixes may be registered
is a network policy decision and out of scope. is a network policy decision and out of scope.
The same prefix may be injected twice (multiple routes) as long as they use The same prefix may be injected twice (multiple routes) as long as they use
the same value of the ROVR. the same value of the ROVR.
</t> </t>
<t> <t>
Overlaps may be desirable. It may happen for instance that a router or a Overlaps may be desirable. For instance, it may happen that a router or a
proxy (see <xref target="ext8929"/>) registers a prefix or an aggregation proxy (see <xref target="ext8929"/>) registers a prefix or an aggregation
while a host using an address from that prefix or a prefix from that while a host using an address from that prefix or a prefix from that
aggregation also registers its piece. aggregation also registers its piece.
</t> </t>
<t> <t>
In case of an overlapping registration, the longest prefix match wins, meanin g that In case of an overlapping registration, the longest prefix match wins, meanin g that
if the network policy allows for overlapping registrations, then the if the network policy allows for overlapping registrations, then the
routes for the registered prefixes are installed towards the node that routes for the registered prefixes are installed towards the node that
registered with the longest prefix match, all the way to /128. registered with the longest prefix match, all the way to /128.
</t> </t>
</li> </li>
<li> <li>
If the 6LR acts as a border router to external prefixes or owns the prefixes entirely, If the 6LR acts as a border router to external prefixes or owns the prefixes entirely,
it SHOULD register all those prefixes on all interfaces from which it might b it <bcp14>SHOULD</bcp14> register all those prefixes on all interfaces from w
e needed to relay traffic to that prefix. hich it might be needed to relay traffic to that prefix.
<!--[rfced] FYI, we changed "the set" to "set the" here. Please review
that the sentence conveys the intended meaning.
It MUST set the P-Field in the Original:
EARO to 3 for those prefixes, and the set R flag to receive the traffic It MUST set the P-Field in the EARO to 3 for those
associated to the prefixes. It MAY refrain from registering a prefix prefixes, and the set R flag to receive the traffic associated to
the prefixes.
Current:
It MUST set the P-Field in the EARO to 3 for those
prefixes and set the R flag to receive the traffic associated to
the prefixes.
-->
It <bcp14>MUST</bcp14> set the P-Field in the
EARO to 3 for those prefixes and set the R flag to receive the traffic
associated to the prefixes. It <bcp14>MAY</bcp14> refrain from registering a
prefix
on one interface if that prefix is already successfully registered on on one interface if that prefix is already successfully registered on
another interface, or the router handled the EDAR / EDAC flow by itself, another interface, or the router handled the EDAR/EDAC flow by itself,
to ensure that the prefix ownership is known and validated by the 6LBR. to ensure that the prefix ownership is known and validated by the 6LBR.
Additionally, if the router expect to receive traffic for that prefix on that Additionally, if the router expects to receive traffic for that prefix on tha t
interface, it needs to ensure that the prefix is advertised some other way, interface, it needs to ensure that the prefix is advertised some other way,
e.g., over a routing protocol such as RPL. e.g., over a routing protocol such as RPL.
</li> </li>
<li> <li>
The 6LN MAY set the R flag in the EARO to request the 6LR to redistribute The 6LN <bcp14>MAY</bcp14> set the R flag in the EARO to request the 6LR to r
the prefix on other links using a routing protocol. The 6LR MUST NOT edistribute
the prefix on other links using a routing protocol. The 6LR <bcp14>MUST NOT</
bcp14>
reregister that prefix to yet another router unless loops are avoided some wa y, reregister that prefix to yet another router unless loops are avoided some wa y,
e.g., following a tree structure. e.g., following a tree structure.
</li> </li>
<li> <li>
The 6LR and the 6LBR are extended to accept more than one registration for The 6LR and the 6LBR are extended to accept more than one registration for
the same prefix, since multiple 6LNs may register it. the same prefix, since multiple 6LNs may register it.
The ROVR in the EARO identifies uniquely a registration The ROVR in the EARO identifies uniquely a registration
within the namespace of the Registered Prefix. within the namespace of the Registered Prefix.
</li> </li>
<!--[rfced] Please clarify this tuple "(IPv6 prefix/length, ROVR)".
Does it mean the first item is a prefix or a prefix length?
The notation "IPv6 prefix/length" has not appeared in any RFCs.
Original:
* The 6LR MUST maintain a registration state per tuple (IPv6 prefix/
length, ROVR) for all registered prefixes.
Perhaps:
* The 6LR MUST maintain a registration state per tuple (IPv6 prefix
or prefix length, ROVR) for all registered prefixes.
Or (if it is a 3-tuple):
* The 6LR MUST maintain a registration state per tuple (IPv6 prefix,
prefix length, ROVR) for all registered prefixes.
-->
<li> <li>
The 6LR MUST maintain a registration state per tuple (IPv6 prefix/length, RO The 6LR <bcp14>MUST</bcp14> maintain a registration state per tuple (IPv6 pr
VR) efix/length, ROVR)
for all registered prefixes. It SHOULD notify the 6LBR for all registered prefixes. It <bcp14>SHOULD</bcp14> notify the 6LBR
with an EDAR message, unless it determined that the 6LBR is legacy and does with an EDAR message, unless it determined that the 6LBR is legacy and does
not support this specification (see <xref target="CIO"/>). In turn, the 6 LBR MUST maintain a not support this specification (see <xref target="CIO"/>). In turn, the 6 LBR <bcp14>MUST</bcp14> maintain a
registration state per tuple (IPv6 prefix, ROVR) for all prefixes. registration state per tuple (IPv6 prefix, ROVR) for all prefixes.
</li> </li>
</ul> </ul>
</section> <!-- end section "Updating the Registration Operation"--> </section>
</section> <!-- end section "Updating RFC 8505"--> </section>
<section anchor="updating2"><name>Updating RFC 9010</name> <section anchor="updating2"><name>Updating RFC 9010</name>
<t> <t>
With <xref target="RFC9010"/>: With <xref target="RFC9010"/>:
</t> </t>
<ul> <ul>
<li> <li>
The 6LR injects only unicast routes in RPL. The 6LR injects only unicast routes in RPL.
</li> </li>
<li> <li>
Upon a registration with the R flag set to 1 in the EARO, the 6LR injects the address in the RPL unicast support. Upon a registration with the R flag set to 1 in the EARO, the 6LR injects the address in the RPL unicast support.
</li> </li>
<li> <li>
Upon receiving a packet directed to a unicast address for which it has an Upon receiving a packet directed to a unicast address for which it has an
active registration, the 6LR delivers the packet as a unicast layer-2 frame active registration, the 6LR delivers the packet as a unicast L2 frame
to the LLA of the node that registered the unicast address. to the LLA of the node that registered the unicast address.
</li> </li>
</ul> </ul>
<t> <t>
This specification adds the following behavior: This specification adds the following behavior:
</t> </t>
<ul> <ul>
<li> <li>
Upon a registration with the R flag set to 1 and the P-Field set to 3 in the EARO, the 6LR injects the prefix in RPL using a prefix RTO. Upon a registration with the R flag set to 1 and the P-Field set to 3 in the EARO, the 6LR injects the prefix in RPL using a prefix RTO.
The P-Field in the RTP MUST be set to 3. The P-Field in the RTP <bcp14>MUST</bcp14> be set to 3.
</li><li> </li><li>
Upon receiving a packet directed to an address that derives from a prefix for Upon receiving a packet directed to an address that derives from a prefix for
which it has at least one registration, the 6LR delivers a copy of the packet which it has at least one registration, the 6LR delivers a copy of the packet
as a unicast layer-2 frame to the LLA of exactly one of the nodes that as a unicast L2 frame to the LLA of exactly one of the nodes that
registered to that prefix, using the longest prefix match derivation to find the registered to that prefix, using the longest prefix match derivation to find the
best 6LN. best 6LN.
</li> </li>
</ul> </ul>
</section> <!-- end section "Updating RFC 9010"--> </section>
<section anchor="sec8928"><name>Updating RFC 8928</name> <section anchor="sec8928"><name>Updating RFC 8928</name>
<t> <t>
<xref target="RFC8928"> Address-Protected Neighbor Discovery for "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" <xre
Low-Power and Lossy Networks </xref> was defined to protect the ownership of f target="RFC8928"/> was defined to protect the ownership of unicast IPv6 addres
unicast IPv6 addresses that are registered with ses that are registered with
<xref target="RFC8505"/>. <xref target="RFC8505"/>.
</t> </t>
<!--t><xref target="RFC8928"/> defines the "C" flag but fails to explicit the bi
t number and fails to make a IANA registration for that bit position. On the oth
er hand, a position for the bit (bit 3) is represented in Figure 1 of <xref targ
et="RFC8928"/>. <xref target="RFC9685"/> defines the P-Field in bits 2 and 3 of
the EARO flags field, obtains a proper IANA registration, but causes an overlap
with the representation in Figure 1 of <xref target="RFC8928"/>. This specificat
ion updates <xref target="RFC8928"/> to position the "C" flag as bit 1 of the EA
RO flag, as represented in <xref target="EARO"/>, to avoid the overlapping defin
itions.
</t-->
<t> <t>
With <xref target="RFC8928"/>, it is possible for a node to autoconfigure a With Address-Protected Neighbor Discovery (AP-ND) <xref target="RFC8928"/>, it is possible for a node to autoconfigure a
pair of public and private keys and use them to sign the registration of pair of public and private keys and use them to sign the registration of
addresses that are either autoconfigured or obtained through other methods. addresses that are either autoconfigured or obtained through other methods.
</t> </t>
<t> <t>
The first hop router (the 6LR) can then validate a registration and The first-hop router (the 6LR) can then validate a registration and
perform source address validation on packets coming from the sender node perform source address validation on packets coming from the sender node
(the 6LN). (the 6LN).
</t> </t>
<t> <t>
As multiple nodes may register the same prefix, the method specified As multiple nodes may register the same prefix, the method specified
in <xref target="RFC8928"/> cannot be used with node-local in <xref target="RFC8928"/> cannot be used with node-local
autoconfigured keypairs, which protect a single ownership only. autoconfigured keypairs, which protect a single ownership only.
</t> </t>
<t> <t>
For a prefix, as for an anycast or a multicast address, it is still possible For a prefix, as for an anycast or a multicast address, it is still possible
to leverage <xref target="RFC8928"/> to enforce the right to register. to leverage AP-ND <xref target="RFC8928"/> to enforce the right to register.
If <xref target="RFC8928"/> is used, a keypair MUST be created and If AP-ND <xref target="RFC8928"/> is used, a keypair <bcp14>MUST</bcp14> be
associated with the prefix before the prefix is deployed, and a ROVR MUST be created and
associated with the prefix before the prefix is deployed, and a ROVR <bcp14>
MUST</bcp14> be
generated from that keypair as specified in <xref target="RFC8928"/>. generated from that keypair as specified in <xref target="RFC8928"/>.
The prefix and the ROVR MUST then be installed in the 6LBR at the first The prefix and the ROVR <bcp14>MUST</bcp14> then be installed in the 6LBR at the first
registration, or by an external mechanism such as IP Address Management registration, or by an external mechanism such as IP Address Management
(IPAM) or DHCPv6 snooping prior to the first registration. (IPAM) or DHCPv6 snooping prior to the first registration.
This way, the 6LBR can recognize the prefix This way, the 6LBR can recognize the prefix
on the future registrations and validate the right to register based on the on the future registrations and validate the right to register based on the
ROVR. ROVR.
</t> </t>
<t> <t>
The keypair MUST then be provisioned in each node that needs to The keypair <bcp14>MUST</bcp14> then be provisioned in each node that needs to
register the prefix or a prefix within, so the node can follow the register the prefix or a prefix within, so the node can follow the
steps in <xref target="RFC8928"/> to register the prefix. steps in <xref target="RFC8928"/> to register the prefix.
</t> </t>
<t> <t>
Upon receiving an NA message with the status set to 5 "Validation Requested" , the Upon receiving an NA message with the status set to 5 "Validation Requested" , the
node that registered the address or prefix performs the proof of ownership b ased node that registered the address or prefix performs the proof of ownership b ased
on that longest prefix match. on that longest prefix match.
</t> </t>
</section> <!-- Updating RFC 8928 --> </section>
<section anchor="ext8929"><name>Updating RFC 8929</name> <section anchor="ext8929"><name>Updating RFC 8929</name>
<t> <t>
<xref target="RFC8929">"IPv6 Backbone Router"</xref> defines a proxy "IPv6 Backbone Router" <xref target="RFC8929"/> defines a proxy
operation whereby a 6LoWPAN Border Router (6LBR) operation whereby a 6LoWPAN Border Router (6LBR)
may impersonate a 6LN when performing an address registration. may impersonate a 6LN when performing an address registration.
In that case, <xref target="RFC8505"/> messages are used as is, with In that case, <xref target="RFC8505"/> messages are used as is, with
one change that the SLLAO in the proxied NS(EARO) messages indicates the one change that the SLLAO in the proxied NS(EARO) messages indicates the
Registering Node (the 6LBR) as opposed to the Registered Node (the 6LN). Registering Node (the 6LBR) as opposed to the Registered Node (the 6LN).
See figure 5 of <xref target="RFC8929"/> for an example of proxy operation See Figure 5 of <xref target="RFC8929"/> for an example of proxy operation
by the 6LBR, which generates an NS(EARO) upon receiving an EDAR message. by the 6LBR, which generates an NS(EARO) upon receiving an EDAR message.
</t> </t>
<!--[rfced] Please clarify this sentence; what does "and this on" mean?
Also, we suggest not repeating "updates".
Original:
This specification updates that proxy operation with the updates in
[RFC9685] and this on the formats and content of the EARO, the EDAR,
and the EDAC messages, to support the P-Field and the signaling of
prefixes.
Perhaps:
This specification updates that proxy operation as specified in
[RFC9685] and defines the formats and content of the
EARO, EDAR, and EDAC messages in order to support the P-Field and the
signaling of prefixes.
-->
<t> <t>
This specification updates that proxy operation with the updates in <xref targ This specification updates that proxy operation with the updates in
et="RFC9685"/> <xref target="RFC9685"/> and this on the formats and content of the EARO, the
and this on the formats and content of the EARO, the EDAR, and the EDAC messag EDAR,
es, and the EDAC messages, to support the P-Field and the signaling of
to support the P-Field and the signaling of prefixes. The proxy MUST use the P prefixes. The proxy <bcp14>MUST</bcp14> use the P-Field as received
-Field as received in the EDAR or NS(EARO) message to generate the proxied NS(EARO), and it <bcp1
in the EDAR or NS(EARO) message to generate the proxied NS(EARO), and it MUST 4>MUST</bcp14>
use the exact same prefix and prefix length as received in the case of use the exact same prefix and prefix length as received in the case of
a prefix registration. a prefix registration.
</t> </t>
</section> <!-- Updating RFC 8929 --> </section>
<section anchor="sec"><name>Security Considerations</name> <section anchor="sec"><name>Security Considerations</name>
<t> <t>
This specification updates <xref target="RFC8505"/>, and This specification updates <xref target="RFC8505"/>, and
the security section of that document also applies to this document. the security considerations of that document also apply to this document.
In particular, the link layer SHOULD be sufficiently In particular, the link layer <bcp14>SHOULD</bcp14> be sufficiently
protected to prevent rogue access, else a rogue node with physical Access protected to prevent rogue access, else a rogue node with physical access
to the network may inject packets and perform an attack from within. to the network may inject packets and perform an attack from within.
</t> </t>
<t> <t>
<xref target="sec8928"/> leverages <xref target="RFC8928"/> to prevent a <xref target="sec8928"/> leverages AP-ND <xref target="RFC8928"/> to prevent
rogue node to register a unicast address that it does not own. a
rogue node from registering a unicast address that it does not own.
The mechanism could be extended to anycast and multicast addresses The mechanism could be extended to anycast and multicast addresses
if the values of the ROVR they use are known in advance, if the values of the ROVR they use are known in advance,
but how this is done is but how this is done is
not in scope for this specification. not in scope for this specification.
One way would be to authorize in advance the ROVR of the valid users. One way would be to authorize in advance the ROVR of the valid users.
A less preferred way could be to synchronize the ROVR and TID values across A less preferred way could be to synchronize the ROVR and TID values across
the valid registering nodes as a preshared key material. the valid registering nodes as a preshared key material.
</t> </t>
<t> <t>
In the latter case, it could be possible to update the keys associated to In the latter case, it could be possible to update the keys associated to
a prefix in all the 6LNs, but the flow is not clearly documented and may a prefix in all the 6LNs, but the flow is not clearly documented and may
not complete in due time for all nodes in LLN use cases. It may be simpler not complete in due time for all nodes in LLN use cases. It may be simpler
to install an all-new address with new keys over a period of time, and to install an all-new address with new keys over a period of time and
switch the traffic to that address when the migration is complete. switch the traffic to that address when the migration is complete.
</t> </t>
</section> <!-- end section "Security Considerations" --> </section>
<section anchor="back"><name>Operational Considerations</name> <section anchor="back"><name>Operational Considerations</name>
<section anchor="legacy"><name>Partially Upgraded Networks</name> <section anchor="legacy"><name>Partially Upgraded Networks</name>
<!--[rfced] May this sentence be rephrased as follows for clarity?
Specifically, "and all of the above" reads oddly.
Original:
A mix of devices that support only [RFC8505], both [RFC8505] and
[RFC9685], and all of the above plus this specification, may coexist.
Different cases may occur:
Perhaps:
A mix of devices (i.e., those that support only [RFC8505], both
[RFC8505] and [RFC9685], or those two plus this specification) may coexist.
Different cases may occur:
Or:
Devices may coexist while providing different support (i.e., only
[RFC8505], both [RFC8505] and [RFC9685], or those two as well as this
specification). The following cases may occur:
-->
<t> <t>
A mix of devices that support only <xref target="RFC8505"/>, both A mix of devices that support only <xref target="RFC8505"/>, both
<xref target="RFC8505"/> and <xref target="RFC9685"/>, and all of the <xref target="RFC8505"/> and <xref target="RFC9685"/>, and all of the
above plus this specification, may coexist. above plus this specification, may coexist. Different cases may occur:
Different cases may occur:
</t> </t>
<ul> <ul>
<li> <li>
A legacy 6LN will not register prefixes and the service will be A legacy 6LN will not register prefixes, and the service will be
the same when the network is upgraded. the same when the network is upgraded.
</li> </li>
<li> <li>
A legacy 6LR will not set the F flag A legacy 6LR will not set the F flag
in the 6CIO and an upgraded 6LN will not register prefixes with that in the 6CIO and an upgraded 6LN will not register prefixes with that
router, though it may with other 6LRs that do support this specification. router, though it may with other 6LRs that do support this specification.
</li> </li>
<li> <li>
Upon an EDAR message, a legacy 6LBR may not realize that the address being Upon an EDAR message, a legacy 6LBR may not realize that the address being
registered comes with a whole prefix, and return that it is duplicate in the registered comes with a whole prefix, and return that it is duplicate in the
EDAC status. The 6LR MUST ignore a duplicate status in the EDAR for prefixes. EDAC status. The 6LR <bcp14>MUST</bcp14> ignore a duplicate status in the EDA R for prefixes.
</li> </li>
</ul> </ul>
</section> <!-- end section "Partially Upgraded Networks" --> </section>
<section anchor="LLN"><name>Application to RPL-Based Route-Over LLNs</name> <section anchor="LLN"><name>Application to RPL-Based Route-Over LLNs</name>
<t> <t>
This specification also updates <xref target="RFC6550"/> and This specification also updates <xref target="RFC6550"/> and
<xref target="RFC9010"/> in the case of a route-over multilink subnet based <xref target="RFC9010"/> in the case of a route-over multilink subnet based
on the RPL routing protocol, to add multicast ingress replication in on the RPL routing protocol, to add multicast ingress replication in
Non-Storing Mode and anycast support in both Storing and Non-Storing modes. Non-Storing Mode and anycast support in both Storing and Non-Storing modes.
A 6LR that implements the RPL extensions specified therein MUST also A 6LR that implements the RPL extensions specified therein <bcp14>MUST</bcp14 > also
implement <xref target="RFC9010"/>. implement <xref target="RFC9010"/>.
</t> </t>
<t> <t>
<xref target="figref"/> illustrates the classical situation of an LLN as a <xref target="figref"/> illustrates the classical situation of an LLN as a
single IPv6 Subnet, with a 6LoWPAN Border Router (6LBR) that acts as Root single 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.
</t> </t>
<figure anchor="figref" align="center"><name>RPL-Based Route-Over LLN</name> <figure anchor="figref" align="center"><name>RPL-Based Route-Over LLN</name>
<artwork><![CDATA[ <artwork><![CDATA[
skipping to change at line 1060 skipping to change at line 1325
o o o o o o
o o o o o o o o o o o o
o o o LLN o +-------+ o o o LLN o +-------+
o o o | 6LR | RPL Router o o o | 6LR | RPL Router
o o o o +-------+ o o o o +-------+
o o o o +-------+ RPL o o o o +-------+ RPL
o | 6LN | leaf o | 6LN | leaf
+-------+ L +-------+ L
o : LLN node o : LLN node
]]></artwork></figure> ]]></artwork></figure>
<t> <t>
A RPL leaf L acting as a 6LN registers its addresses and prefixes A RPL leaf L acting as a 6LN registers its addresses and prefixes
to a RPL router acting as a 6LR, using a layer-2 unicast NS message to a RPL router acting as a 6LR, using a L2 unicast NS message
with an EARO as specified in <xref target="RFC8505"/> and <xref target= with an EARO as specified in <xref target="RFC8505"/> and <xref target=
"RFC9685"/>. "RFC9685"/>.
Note that a RPL leaf acting as 6LN may still be a border router for another Note that a RPL leaf acting as 6LN may still be a border router for another
routing protocol, an access router for an IP link, or a virtual Router routing protocol, an access router for an IP link, or a virtual Router
serving virtual machines or applications within the same physical node. serving virtual machines or applications within the same physical node.
Note also that a RPL-aware Leaf would preferably leverage RPL directly Note also that a RPL-aware Leaf would preferably leverage RPL directly
to inject routes, to fully leverage the routing protocol. to inject routes, to fully leverage the routing protocol.
The registration state is periodically renewed by the Registering Node (the 6 LN), The registration state is periodically renewed by the Registering Node (the 6 LN),
before the lifetime indicated in the EARO expires (at the 6LR). As for unicas t IPv6 before the lifetime indicated in the EARO expires (at the 6LR). As for unicas t IPv6
addresses, the 6LR uses an Extended Duplicate Address Request/Confirmation addresses, the 6LR uses an Extended Duplicate Address Request/Confirmation
(EDAR/EDAC) exchange with the 6LBR to notify the 6LBR of the presence of the listeners. (EDAR/EDAC) exchange with the 6LBR to notify the 6LBR of the presence of the listeners.
<!--[rfced] Is "the Prefix" here referring to the Prefix field,
or should it be lowercased to match the other instances within this sentence?
Original:
With this specification, a router that owns a prefix or provides reachability With this specification, a router that owns a prefix or provides reachability
to an external prefix but is not a RPL router can also register those to an external prefix but is not a RPL router can also register those
prefixes with the R flag set, to enable reachability to the Prefix prefixes with the R flag set, to enable reachability to the Prefix
within the RPL domain.
-->
With this specification, a router that owns a prefix or provides reachability
to an external prefix but is not a RPL router can also register those
prefixes with the R flag set, to enable reachability to the Prefix
within the RPL domain. within the RPL domain.
</t> </t>
</section><!--end section "LLN Mesh Network" --> </section>
<section anchor="Shared"><name>Application to a Shared Link</name> <section anchor="Shared"><name>Application to a Shared Link</name>
<t> <t>
A shared link is a situation where more than one prefix is deployed over A shared link is a situation where more than one prefix is deployed over
a L2 link (say a switched Ethernet fabric, or a Wi-Fi Extended Service Set ( ESS) federating multiple Access Points (APs)), an L2 link (say, a switched Ethernet fabric or a Wi-Fi Extended Service Set (ESS) federating multiple Access Points (APs)),
and not necessarily all nodes are aware of all prefixes. <xref target="figsh ared"/> depicts such and not necessarily all nodes are aware of all prefixes. <xref target="figsh ared"/> depicts such
a situation, with 2 routers 6LR1 and 6LR2 that own respective prefixes P1:: a situation, with two routers 6LR1 and 6LR2 that own respective prefixes P1:
and P2::, and expose those in their RA messages over the same link. :
and P2:: and expose those in their RA messages over the same link.
Note that the shared link maybe operated with any combination of NDP and SND Note that the shared link maybe operated with any combination of NDP and SND
as discussed in section 7 of <xref target="I-D.ietf-6man-ipv6-over-wireless "/>. as discussed in <xref target="I-D.ietf-6man-ipv6-over-wireless" section="7"/ >.
</t> </t>
<figure anchor="figshared" align="center"><name>Shared Link</name> <figure anchor="figshared" align="center"><name>Shared Link</name>
<artwork><![CDATA[ <artwork><![CDATA[
.- -- . .- -- .
.-( ). .-( ).
( Internet ) ( Internet )
(___.________.___) (___.________.___)
| |
+----+--+ +-------+ +----+--+ +-------+
| P1::a | | P2::b | | P1::a | | P2::b |
| 6LR1 | | 6LR2 | | 6LR1 | | 6LR2 |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
----+--+------+---------+-+-------+---------+---- ----+--+------+---------+-+-------+---------+----
| | | | | | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
|P1::c| |P2::d| |P2::e| |P1::f| |P1::g| |P1::c| |P2::d| |P2::e| |P1::f| |P1::g|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+]]></artwork></figure>
]]></artwork></figure>
<t> <t>
Say that 6LR1 is the router providing access to the outside, and 6LR2 is Say that 6LR1 is the router providing access to the outside, and 6LR2 is
aware of 6LR1 as its default gateway. With this specification, 6LR2 aware of 6LR1 as its default gateway. With this specification, 6LR2
registers P2:: to 6LR1 and 6LR1 installs a route to P2:: via 6LR2. This way, registers P2:: to 6LR1, and 6LR1 installs a route to P2:: via 6LR2. This way ,
addresses that derive from P2:: can still be reached via 6LR1 and then 6LR2. addresses that derive from P2:: can still be reached via 6LR1 and then 6LR2.
6LR2 may then leverage ICMP Redirect messages <xref target="RFC4861"/> 6LR2 may then leverage ICMP Redirect messages <xref target="RFC4861"/> to sh
to shorten the orten the
path between 6LR1 and the nodes that own those addresses. path between 6LR1 and the nodes that own those addresses.
</t> </t>
<t> If P2 was delegated by 6LR1, e.g., using the <xref target="RFC8415"> <t> If P2 were delegated by 6LR1, e.g., using DHCPv6 <xref target="RFC8415"/>,
"Dynamic Host Configuration Protocol for IPv6" </xref> (DHCPv6),
then the expectation is that 6LR1 aggregates then the expectation is that 6LR1 aggregates
P1:: and P2:: in its advertisements to the outside, and there is no need to P1:: and P2:: in its advertisements to the outside, and there is no need to
set the R flag. But unless 6LR2 knows about such a situation, e.g., through set the R flag. However, unless 6LR2 knows about such a situation, e.g., thr
configuration, 6LR2 SHOULD set the R flag requesting ough
configuration, 6LR2 <bcp14>SHOULD</bcp14> set the R flag requesting
6LR1 to advertise P2:: so as to obtain reachability. 6LR1 to advertise P2:: so as to obtain reachability.
</t> </t>
</section> <!-- end section "Shared Link" --> </section>
<section anchor="Hub"><name>Application to a Hub Link with Stub Spokes</name> <section anchor="Hub"><name>Application to a Hub Link with Stub Spokes</name>
<t> <t>
A hub link is a situation where stub links are deployed around a backbone an d A hub link is a situation where stub links are deployed around a backbone an d
interconnected by routers. <xref target="fighub"/> depicts such interconnected by routers. <xref target="fighub"/> depicts such
a situation, with one router 6LR1 serving the hub link and at least one a situation, with one router 6LR1 serving the hub link and at least one
router like 6LR2 and 6LR3 providing connectivity from the stub links to the router like 6LR2 and 6LR3 providing connectivity from the stub links to the
hub link. In this example, say that there is one prefix on each link, hub link. In this example, say that there is one prefix on each link --
P1:: on the hub link and P2:: and P3:: on the stub links. P1:: on the hub link, and P2:: and P3:: on the stub links.
</t> </t>
<figure anchor="fighub" align="center"><name>Hub and Stubs</name> <figure anchor="fighub" align="center"><name>Hub and Stubs</name>
<artwork><![CDATA[ <artwork><![CDATA[
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|P2::s| |P2::d| |P2::e| |P2::f| |P2::s| |P2::d| |P2::e| |P2::f|
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | | | |
----+----+----+---------+--STUB-LINK--+----- ----+----+----+---------+--STUB-LINK--+-----
| |
+---+---+ +-------+ +---+---+ +-------+
| P2::r | | | .- --.. | P2::r | | | .- --..
| 6LR2 | | 6LR1 +---- .-( ). | 6LR2 | | 6LR1 +---- .-( ).
| P1::b | | P1::a | ( Internet ) | P1::b | | P1::a | ( Internet )
skipping to change at line 1175 skipping to change at line 1443
+---+---+ +--+--+ +---+---+ | +---+---+ +--+--+ +---+---+ |
| P1::c | |P1::n| | P1::q | | | P1::c | |P1::n| | P1::q | |
| 6LR3 | +-----+ | 6LR4 +----+ | 6LR3 | +-----+ | 6LR4 +----+
| P3::m | | P3::a | | P3::m | | P3::a |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
----+--+------+---------+--STUB-LINK--+-+----- ----+--+------+---------+--STUB-LINK--+-+-----
| | | | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
|P3::h| |P3::i| |P3::j| |P3::k| |P3::h| |P3::i| |P3::j| |P3::k|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+]]></artwork></figure>
]]></artwork></figure>
<t> <t>
As before, say that 6LR1 is the router providing access to the outside, and As before, say that 6LR1 is the router providing access to the outside, and
6LR2 is aware of 6LR1 as its default gateway. With this specification, 6LR2 6LR2 is aware of 6LR1 as its default gateway. With this specification, 6LR2
registers P2:: to 6LR1 and 6LR1 installs a route to P2:: via 6LR2. This way, registers P2:: to 6LR1, and 6LR1 installs a route to P2:: via 6LR2. This way ,
nodes on the stub link behind 6LR2 that derive their addresses from P2:: can nodes on the stub link behind 6LR2 that derive their addresses from P2:: can
still be reached via 6LR1 and then 6LR2. The same goes for 6LR3 and any othe r still be reached via 6LR1 and then 6LR2. The same goes for 6LR3 and any othe r
routers serving stub links. routers serving stub links.
</t><t> </t><t>
If P2 was delegated by 6LR1, then the expectation is that 6LR1 aggregates If P2 were delegated by 6LR1, then the expectation is that 6LR1 aggregates
P1:: and P2:: in its advertisements to the outside, and there is no need to P1:: and P2:: in its advertisements to the outside, and there is no need to
set the R flag. But unless 6LR2 knows about such a situation, e.g., through set the R flag. However, unless 6LR2 knows about such a situation, e.g., thr
configuration, 6LR2 SHOULD set the R flag requesting ough
configuration, 6LR2 <bcp14>SHOULD</bcp14> set the R flag requesting
6LR1 to advertise P2:: so as to obtain reachability. 6LR1 to advertise P2:: so as to obtain reachability.
</t><t> </t><t>
In this example, routers 6LR3 and 6LR4 both connect to the same stub link wh ere subnet P3 is installed. In this example, routers 6LR3 and 6LR4 both connect to the same stub link wh ere subnet P3 is installed.
They may both register P3 to 6LR1, and 6LR1 will apply its own load balancin g logic to use They may both register P3 to 6LR1, and 6LR1 will apply its own load-balancin g logic to use
either of the routers. either of the routers.
</t> </t>
</section> <!-- end section "Hub Link" --> </section>
</section> <!-- end section "Operational Considerations" --> </section>
<section ><name>IANA Considerations</name> <section ><name>IANA Considerations</name>
<t> <t>
Note to RFC Editor, to be removed: please replace "This RFC" throughout this IANA has made changes under the "Internet Control Message
document by the RFC number for this specification once it is allocated.
</t>
<t>
IANA is requested to make changes under the "Internet Control Message
Protocol version 6 (ICMPv6) Parameters" <xref target="IANA.ICMP"/> and the Protocol version 6 (ICMPv6) Parameters" <xref target="IANA.ICMP"/> and the
"Routing Protocol for Low Power and Lossy Networks (RPL)" <xref target="IANA .RPL"/> "Routing Protocol for Low Power and Lossy Networks (RPL)" <xref target="IANA .RPL"/>
registry groupings, as follows: registry groups, as follows.
</t> </t>
<section anchor="PF"><name>Updated P-Field Registry</name> <section anchor="PF"><name>Updated P-Field Registry</name>
<t> <t>
This specification updates the P-Field introduced in <xref target= This specification updates the P-Field introduced in <xref target=
"RFC9685"/> to assign the value of 3, which is "RFC9685"/> to assign the value of 3, which is
the only remaining unassigned value for the 2-bit field. To that effect, the only remaining unassigned value for the 2-bit field. To that effect,
IANA is requested to update the "P-Field values" registry under the IANA has updated the "P-Field Values" registry in the
heading "Internet Control Message Protocol version 6 (ICMPv6) Parameters" "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry g
roup
as indicated in <xref target="AM2"/>: as indicated in <xref target="AM2"/>:
</t> </t>
<table anchor="AM2" ><name>New P-Field value</name> <table anchor="AM2" ><name>New P-Field Value</name>
<thead> <thead>
<tr><td>Value</td><td>Meaning</td><td>Reference</td></tr> <tr><th>Value</th><th>Meaning</th><th>Reference</th></tr>
</thead><tbody> </thead><tbody>
<tr><td><strong>3</strong></td><td>Registration for a prefix</td><td>This RFC</td></tr> <tr><td><strong>3</strong></td><td>Registration for a Prefix</td><td>RFC 9 926</td></tr>
</tbody> </tbody>
</table> <!-- end table "New P-Field values" --> </table>
</section><!-- end section "Updated P-Field Registry" --> </section>
<section anchor="CIOF"> <name>New 6LoWPAN Capability Bit</name> <section anchor="CIOF"> <name>New 6LoWPAN Capability Bit</name>
<t> <t>
IANA is requested to make an addition to the IANA has made an addition to the
"6LoWPAN Capability Bits" <xref target="IANA.ICMP.6CIO"/> registry under the "6LoWPAN Capability Bits" <xref target="IANA.ICMP.6CIO"/> registry in the
heading "Internet Control Message Protocol version 6 (ICMPv6) Parameters" "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry g
roup
as indicated in <xref target="CIOdat"/>: as indicated in <xref target="CIOdat"/>:
</t> </t>
<t>IANA is also requested to fix the description of bit 9 (the "A" flag defi ned in <xref target="RFC8928"/>). <t>IANA has fixed the description of bit 9 (the "A" flag defined in <xref ta rget="RFC8928"/>).
It is not called "1" but "A". It is not called "1" but "A".
</t> </t>
<table anchor="CIOdat" ><name>New 6LoWPAN Capability Bit</name> <table anchor="CIOdat" ><name>New 6LoWPAN Capability Bit</name>
<thead> <thead>
<tr><td>Bit</td><td>Description</td><td>Reference</td></tr> <tr><th>Bit</th><th>Description</th><th>Reference</th></tr>
</thead><tbody> </thead><tbody>
<tr><td><strong>9 </strong></td><td>AP-ND Enabled (A bit) </td><td><xref t <tr><td><strong>9</strong></td><td>AP-ND Enabled (A bit)</td><td><xref tar
arget="RFC8928"/></td></tr> get="RFC8928"/></td></tr>
<tr><td><strong>16 (suggested)</strong></td><td>Registration for prefixes <tr><td><strong>16</strong></td><td>Registration for prefixes Supported (F
Supported (F bit)</td><td>This RFC</td></tr> bit)</td><td>RFC 9926</td></tr>
</tbody> </tbody>
</table> <!-- end table "New 6LoWPAN Capability Bit" --> </table>
</section> <!-- end section "New 6LoWPAN Capability Bit" -->
</section> <!-- end section "IANA Considerations" --> </section>
<section title="Acknowledgments"> </section>
<t>
Many thanks to Dave Thaler and Dan Romascanu for their early reviews, Adnan R
ashid for all his contributions,
and Eric Vyncke for his in-depth AD review.
Many thanks as well to the reviewers of the IETF last call and IESG rounds, D
an Romascanu,
Shuping Peng, Mohamed Boucadair, Paul Wouters, Ketan Talaulikar, Gunter Van d
e Velde, Mike Bishop, Roman Danyliw, ...
</t>
</section> <!-- title="Acknowledgments" -->
</middle> </middle>
<back> <back>
<displayreference target="RFC2827" to="BCP38"/> <!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->
<references title="Normative References"> <displayreference target="I-D.ietf-6man-ipv6-over-wireless" to="IPv6-over-NBMA"/
<!-- RFC --> >
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <references><name>Normative References</name>
nce.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference 9.xml"/>
.RFC.4861.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.486
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere 1.xml"/>
nce.RFC.4862.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.486
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere 2.xml"/>
nce.RFC.6550.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.655
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere 0.xml"/>
nce.RFC.6775.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.677
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere 5.xml"/>
nce.RFC.7400.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.740
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere 0.xml"/>
nce.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere 4.xml"/>
nce.RFC.8200.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.820
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere 0.xml"/>
nce.RFC.8505.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.850
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.892
8.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.892
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.901
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.968
5.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <reference anchor="IANA.ICMP" target="https://www.iana.org/assignments
.RFC.8928.xml"/> /icmpv6-parameters">
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <front>
.RFC.8929.xml"/> <title>Internet Control Message Protocol version 6 (ICMPv6) Param
eters</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <reference anchor="IANA.ICMP.6CIO" target="https://www.iana.org/assignmen
.RFC.9010.xml"/> ts/icmpv6-parameters">
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <front>
.RFC.9685.xml"/> <title>6LoWPAN Capability Bits</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<reference anchor="IANA.ICMP"> <reference anchor="IANA.RPL" target="https://www.iana.org/assignments
<front> /rpl">
<title>IANA Registry for ICMPv6</title> <front>
<author> <title>
<organization> Routing Protocol for Low Power and Lossy Networks (RPL)
IANA </title>
</organization> <author>
</author> <organization>IANA</organization>
<date year=""></date> </author>
</front> </front>
<seriesInfo name="IANA," value="https://www.iana.org/assignments/ </reference>
icmpv6-parameters/icmpv6-parameters.xhtml"></seriesInfo>
</reference>
<reference anchor="IANA.ICMP.6CIO"> </references>
<front>
<title>IANA Registry for the 6LoWPAN Capability Bits</tit
le>
<author>
<organization>
IANA
</organization>
</author>
<date year=""></date>
</front>
<seriesInfo name="IANA," value="https://www.iana.org/assignments/
icmpv6-parameters/icmpv6-parameters.xhtml#sixlowpan-capability-bits"></seriesInf
o>
</reference>
<!--reference anchor="IANA.ICMP.EARO">
<front>
<title>IANA Registry for the Address Registration Option
Flags</title>
<author>
<organization>
IANA
</organization>
</author>
<date year=""></date>
</front>
<seriesInfo name="IANA," value="https://www.iana.org/assignments/
icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-adress-registration-option-flag
s"></seriesInfo>
</reference-->
<reference anchor="IANA.RPL"> <references><name>Informative References</name>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0038
<title>IANA Registry for the RPL</title> .xml"/>
<author>
<organization>
IANA
</organization>
</author>
<date year=""></date>
</front>
<seriesInfo name="IANA," value="https://www.iana.org/assignments/
rpl/rpl.xhtml"></seriesInfo>
</reference>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4191.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4919.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6282.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9030.
xml"/>
<!-- [I-D.ietf-6man-ipv6-over-wireless]
draft-ietf-6man-ipv6-over-wireless-08
IESG State: I-D Exists as of 1/21/26.
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
-6man-ipv6-over-wireless.xml"/>
<references title="Informative References"> <!-- [rfced] Please review the informative reference [IEEE802154].
<!-- RFC --> The title provided matches a version of this IEEE Standard from 2006.
The most up-to-date version of this reference was published in 2024.
Which version of the IEEE Standard should be referenced in
this document?
<!-- I-D --> Original:
[IEEE802154] IEEE standard for Information Technology, "IEEE Std
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks".
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference Current:
.RFC.2827.xml"/> [IEEE802154]
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference IEEE, "IEEE Standard for Information technology - Local
.RFC.4191.xml"/> and metropolitan area networks - Specific requirements -
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference Part 15.4: Wireless Medium Access Control (MAC) and
.RFC.4919.xml"/> Physical Layer (PHY) Specifications for Low Rate Wireless
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference Personal Area Networks (WPANs)", IEEE Std 802.15.4-2006,
.RFC.6282.xml"/> DOI 10.1109/IEEESTD.2006.232110, 2006,
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference <https://ieeexplore.ieee.org/document/1700009>.
.RFC.8415.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference
.RFC.9030.xml"/>
<!-- <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/r Most recent version (potential update):
eference.I-D.kuehlewind-update-tag.xml'/> -->
<!--xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refer [IEEE802154]
ence.I-D.heile-lpwan-wisun-overview.xml"/--> IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/referenc Std 802.15.4-2024, DOI 10.1109/IEEESTD.2024.10794632,
e.I-D.ietf-6man-ipv6-over-wireless.xml"/> 2024, <https://ieeexplore.ieee.org/document/10794632>.
<reference anchor="IEEE802154"> -->
<!-- [XML for if the authors want to update to the latest version.]
<reference anchor="IEEE802154-2024" target="https://ieeexplore.ieee.org/document
/10794632">
<front>
<title>
IEEE Standard for Low-Rate Wireless Networks
</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2024"/>
</front>
<seriesInfo name="IEEE Std" value="802.15.4-2024"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2024.10794632"/>
</reference>
-->
<reference anchor="IEEE802154" target="https://ieeexplore.ieee.org/documen
t/1700009">
<front> <front>
<title>IEEE Std 802.15.4, Part. 15.4: Wireless Medium Access <title>IEEE Standard for Information technology -- Local and metropo
Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate litan area networks -- Specific requirements -- Part 15.4: Wireless Medium Acces
Wireless Personal Area Networks s Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Pe
rsonal Area Networks (WPANs)
</title> </title>
<author> <author>
<organization>IEEE standard for Information Technology</organizat ion> <organization>IEEE</organization>
</author> </author>
<date/> <date year="2006"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.15.4-2006"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2006.232110"/>
</reference> </reference>
<reference anchor="IEEE80211" <reference anchor="IEEE80211"
target="https://ieeexplore.ieee.org/document/9363693" > target="https://ieeexplore.ieee.org/document/9363693" >
<front> <front>
<title> <title>
IEEE Standard 802.11 - IEEE Standard for Information IEEE Standard for Information Technology -- Telecommunications and I
Technology - Telecommunications and information exchange nformation Exchange between
between systems Local and metropolitan area networks - Systems - Local and Metropolitan Area Networks -- Specific Requirements - Part 1
Specific requirements - Part 11: Wireless LAN Medium 1: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specificati
Access Control (MAC) and Physical Layer (PHY) ons
Specifications.
</title> </title>
<author> <author>
<organization>IEEE standard for Information Technology</organizat ion> <organization>IEEE</organization>
</author> </author>
<date/> <date/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.11-2022"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9363693"/>
</reference> </reference>
<reference anchor="WI-SUN" <reference anchor="WI-SUN"
target="https://wi-sun.org/" > target="https://wi-sun.org/" >
<front> <front>
<title> <title>
Wi-SUN Alliance Wi-SUN Alliance
</title> </title>
<author/> <author/>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="IEEE802151"> <!-- [rfced] Please review the informative reference [IEEE802151].
We added the following URL to this reference. Note that the title
is slightly different. Please let us know if you prefer otherwise.
Original:
[IEEE802151] IEEE standard for Information Technology, "IEEE
Standard for Information Technology - Telecommunications and
Information Exchange Between Systems - Local and Metropolitan Area
Networks - Specific Requirements. - Part 15.1: Wireless Medium Access
Control (MAC) and Physical Layer (PHY) Specifications for Wireless
Personal Area Networks (WPANs)".
Current:
[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>.
-->
<reference anchor="IEEE802151" target="https://ieeexplore.ieee.org/documen
t/1016473">
<front> <front>
<title> IEEE Standard for Information Technology - <title>IEEE Standard for Telecommunications and Information Exchange
Telecommunications and Information Exchange Between Systems - Between Systems - LAN/MAN - Specific Requirements - Part 15: Wireless Medium Ac
Local and Metropolitan Area Networks - Specific Requirements. - cess Control (MAC) and Physical Layer (PHY) Specifications for Wireless Personal
Part 15.1: Wireless Medium Access Control (MAC) and Physical Area Networks (WPANs)
Layer (PHY) Specifications for Wireless Personal Area Networks
(WPANs)
</title> </title>
<author> <author>
<organization> IEEE standard for Information Technology <organization>IEEE</organization>
</organization>
</author> </author>
<date/> <date year="2002"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.15.1-2002"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2002.93621"/>
</reference> </reference>
</references> </references>
<section numbered="false">
<name>Acknowledgments</name>
<t>
Many thanks to <contact fullname="Dave Thaler"/> and <contact fullname="Dan
Romascanu"/> for their early reviews, <contact fullname="Adnan Rashid"/>
for all his contributions, and <contact fullname="Éric Vyncke"/> for his
in-depth AD review. Many thanks as well to the reviewers of the IETF Last
Call and IESG rounds: <contact fullname="Dan Romascanu"/>, <contact
fullname="Shuping Peng"/>, <contact fullname="Mohamed Boucadair"/>,
<contact fullname="Paul Wouters"/>, <contact fullname="Ketan Talaulikar"/>,
<contact fullname="Gunter Van de Velde"/>, <contact fullname="Mike
Bishop"/>, and <contact fullname="Roman Danyliw"/>.
</t>
</section>
</back> </back>
<!--[rfced] Terminology: The following terms appear inconsistently
in the original; please let us know if any updates are needed.
a) subnet vs. Subnet
We suggest lowercasing these instances to match usage elsewhere in the document.
Capitalized instances:
inside the Subnet
a single IPv6 Subnet
b) registration vs. Registration
Capitalized instances:
the Registration for prefixes
the Registration operation
the Registration of overlapping prefixes
c) prefix length vs. Prefix Length
Presumably, this should be capitalized when referring to the field name.
It's not clear if some instances of lowercase are accurate.
For example: Section 7.3, perhaps capitalize it here?
"the remaining byte is dedicated to one reserved bit and the prefix length"
d) FYI, as "Layer 2 (L2)" appears in Section 1, we updated
subsequent instances of "Layer 2" to "L2". Please let us know
if you prefer otherwise.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</rfc> </rfc>
 End of changes. 240 change blocks. 
528 lines changed or deleted 898 lines changed or added

This html diff was produced by rfcdiff 1.48.