<?xml version="1.0" encoding="utf-8"?>
<!--DOCTYPE encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"-->

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<!--[rfced] Would you like to update the title for
readability?

Original: IPv6 Neighbor Discovery Prefix Registration
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" submissionType="IETF" xml:lang="en" version="3"  updates="4861, 6550, 8505, 8928, 9010"  docName="draft-ietf-6lo-prefix-registration-18" > number="9926" symRefs="true" sortRefs="false">

<front>
   <title abbrev="Prefix Registration">IPv6 Neighbor Discovery Prefix Registration</title>
   <seriesInfo name="RFC" value="9926"/>
   <author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor'>
      <!-- <organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization> -->
      <address>
         <postal>
            <city>Roquefort-les-Pins</city>
            <code>06330</code>
          <country>France</country>
         </postal>
         <email>pascal.thubert@gmail.com</email>
      </address>
   </author>

   <area>Internet</area>
   <date month="January" year="2026"/>
   <area>INT</area>
   <workgroup>6lo</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

   <abstract>
   <t>
   This document updates IPv6 Neighbor Discovery (RFC 4861) and IPv6
   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
   neighbor routers.  The registration indicates that the registered
   prefix can be reached via the advertising node without a loop.  The
   unicast prefix registration allows the node to request one or more neighbor router(s) routers to
   redistribute the prefix in another routing domain regardless of the
   routing protocol used in that domain.  This document updates
   the Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC 6550,
   RFC 9010) (RPL), as specified in RFCs 6550 and 9010, to enable a 6LoWPAN Router (6LR) to inject the
   registered prefix in RPL.
   </t>
   </abstract>
</front>

<middle>

<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->

<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
   saving energy, which is the most constrained resource of all. Other design
   constraints, such as a limited memory capacity, duty cycling of the LLN
   devices
   devices, and low-power lossy transmissions, derive from that primary concern.
   The radio (both transmitting or simply listening) is a major energy drain drain,
   and the LLN protocols must be adapted to allow the nodes to remain sleeping
   with the radio turned off at most times.

</t> <t>
	Examples of LLNs include hub-and-spoke access links such as (Low-Power) Wi-Fi
   <xref target="IEEE80211"/> and Bluetooth (Low Energy)
   <xref target="IEEE802151"/>, Mesh-Under networks where the routing
   operation is handled at Layer-2, Layer 2 (L2), and Route-Over route-over networks such as the Wi-SUN
   <xref target="WI-SUN"/> and 6TiSCH <xref target="RFC9030"/>
   mesh networks, which leverage 6LoWPAN <xref target="RFC4919"/><xref target="RFC4919"/> <xref target="RFC6282"/>
   and RPL <xref target="RFC6550"/> over <xref target="IEEE802154"/>.

</t><t>
   LLNs and constrained devices are the original domain of application
   for 6LoWPAN protocols.  It It is thus a foremost concern, when designing
   those protocols, to minimize energy spendings.  In In non-LLN
   environments where lowering carbon emissions is also a priority, it
   could make sense to apply the 6LoWPAN designs and extend some of the
   6LoWPAN protocols.
   The general design points include:

</t>
<ul>
   <li>
     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>
    Using host-triggered operations to enable transient disconnections with the routers, e.g.,
	 to conserve power (sleep), but also to cope with inconsistent connectivity.
	 </li>
</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>
     This translates into:
   </t>

<ul>
   <li>Stateful proactively-built proactively built knowledge in the routers that is available at any point of time.
	</li>
   <li>
    Unicast host to router host-to-router operations triggered by the host and its applications.
	</li>

   <li>
    Minimal use of asynchronous L2-broadcast L2 broadcast operations that would keep the host awake and listening with no application-level need to do so.
   </li>

</ul>

<t>
   The <xref target="RFC6550">"Routing
   "RPL: IPv6 Routing Protocol for Low Power Low-Power and Lossy Networks"</xref> (RPL) Networks" <xref target="RFC6550"/> provides IPv6 <xref target="RFC8200"/>
   routing services within such constraints.
   To save signaling and routing state in constrained networks, the RPL routing
   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
   between 2 two peers, whatever that would mean in each LLN.
</t><t>
   The classical Neighbor Discovery (IPv6 ND) Protocol (NDP)
   <xref target="RFC4861"/> <xref target="RFC4862"/> was defined for serial
   links and shared transit media such as Ethernet at a time when L2-broadcast L2 broadcast
   was cheap on those media 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
   multicast operations for the Address Resolution (AR) (aka Address Discovery or
   Address Lookup) and Duplicate Address Detection (DAD) of IPv6 unicast addresses.
   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
   nodes are awake to hear the request, which is inconsistent with power
   saving power-saving (sleeping) modes.
</t><t>
   The <xref target="I-D.ietf-6man-ipv6-over-wireless">
   "Architecture and Framework for IPv6 over Non-Broadcast Access" (NBMA)</xref> <xref target="I-D.ietf-6man-ipv6-over-wireless"/>
   introduces an evolution of IPv6 ND towards a proactive AR method.
   Because the IPv6 model for
   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).
   SND is based on work done in the context of IoT, Internet of Things (IoT), known as 6LoWPAN ND.
   As opposed to the classical IPv6 ND Protocol, protocol, this evolution follows the
   energy conservation principles discussed above:
</t>
<ul><li>
   The original 6LoWPAN ND, <xref target="RFC6775"> "Neighbor Discovery
   Optimizations Optimization for 6LoWPAN networks"</xref>, IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" <xref target="RFC6775"/>, was introduced to avoid the
   excessive use of multicast messages and enable IPv6 ND for operations over
   energy-constrained nodes.
   <xref target="RFC6775"/> changes the classical IPv6 ND model to proactively
   establish the Neighbor Cache Entry (NCE) associated to the unicast address of
   a 6LoWPAN Node (6LN) in the one or more 6LoWPAN Router(s) Routers (6LRs) that serve it.
   To that effect, <xref target="RFC6775"/> defines a new Address Registration
   Option (ARO) that is placed in unicast Neighbor Solicitation (NS) and
   Neighbor Advertisement (NA) messages between the 6LN and the 6LRs.
</li><li>
   <xref target="RFC8505">
   "Registration Extensions for 6LoWPAN IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor
   Discovery"</xref> Discovery>" <xref target="RFC8505"/> updates <xref target="RFC6775"/> into a generic Address
   Registration mechanism and is the foundation for Subnet Neighbor Discovery (SND).
   SND introduces the Extended Address Registration Option (EARO) to enable the
   registering node to access services such as routing inside a subnet
   and ND proxy operations <xref target="RFC8929"/> operations. target="RFC8929"/>.
   This provides a routing-protocol-agnostic method for a host to
   request that the router injects inject a unicast IPv6 address in the local routing
   protocol and provide return reachability for that address.
</li><li>
   <xref target="RFC9685">
   "IPv6
   "Listener Subscription for IPv6 Neighbor Discovery Multicast Address Listener Subscription"</xref> and Anycast Addresses" <xref target="RFC9685"/>
   updates <xref target="RFC8505"/> to enable a listener to subscribe to an IPv6
    anycast or multicast address; the draft document also updates <xref target="RFC9010"/>
    to enable a 6LR to inject the anycast and multicast addresses in RPL.
    Similarly, this specification updates <xref target="RFC8505"/> and
    <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 routing-protocol-independent
    fashion to a 6LR that it is expected to redistribute the prefixes.
</li></ul>

<t>
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. As with <xref target="RFC8505"/>, the prefix registration is agnostic to the routing protocol in which the router injects the prefix, and the router is agnostic to the method that was used to allocate the prefix to the node.
The energy conservation principles in <xref target="RFC8505"/> are retained as well,
meaning that the node does not have to send or expect asynchronous multicast messages.

</t><t>

</t>
<!--[rfced] May this be rephrased as follows for clarity?
In the original, the repetition of "it" (with different antecedents)
is unclear.

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.

Perhaps:
   Please note that an energy-conserving node is not necessarily a
   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.

Or:
   Note that an energy-conserving node is not necessarily a
   router, so even when a node is advertising a prefix, a design
   choice is not using Router Advertisement (RA) messages that
   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?

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.

Perhaps:
   From the design principles above,
   it is clearly a design choice not to leverage (1) broadcasts from or to
   the node or (2) complex state machines in the node.
-->
<t>
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. 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. 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 Ownership Verifier (ROVR) <xref target="RFC8928"/> in the EARO.
</t>

</section>	<!-- end section = "Introduction"  -->

<section> <name>Terminology</name>
  <section anchor="bcp"><name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
    "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>

<!-- <t> -->
  <!-- In addition, the terms "updates" and "updates" are used as a more specific term for "Updates" per -->
  <!-- <xref target="I-D.kuehlewind-update-tag" /> section 3 as follows: -->
  <!-- </t> -->
   <!-- <dl newline="false" indent="7" spacing="compact" > -->
       <!-- <dt><strong>updates/Amended by:</strong></dt> -->
			<!-- <dd>This tag pair is used with an amending RFC that changes the amended RFC. This could include bug fixes, behavior changes etc. This is intended to specify mandatory changes to the protocol. The goal of this tag pair is to signal to anyone looking to implement the amended RFC that they MUST also implement the amending RFC. </dd> -->
	   <!-- <dt><strong>updates/Extended by:</strong></dt> -->
			<!-- <dd> This tag pair is used with an updating RFC that defines an optional addition to the extended RFC. This can be used by documents that use existing extension points or clarifications that do not change existing protocol behavior. This signals to implementers and protocol designers that there are changes to the extended RFC that they need to consider but not necessarily implement.</dd> -->
       <!-- </dl> -->
  </section>	<!-- end section "Requirements Language" -->

  <section anchor="lo"><name>Inherited Terms and Concepts</name>
    <t>
	This document uses terms and concepts that are discussed in:
    </t>
	<ul>
	<li> "TLS User Mapping Extension" <xref target="RFC4861">"Neighbor Discovery for IP version 6"
		</xref> target="RFC4861"/> and
      </li><li>
	    <xref target="RFC4862">"IPv6
	    "IPv6 Stateless Address Autoconfiguration"
		</xref> <xref target="RFC4862"/> for the Neighbor Solicitation operation,
    </li>
	<li> <xref target="RFC6775">Neighbor "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</xref>, (6LoWPANs)" <xref target="RFC6775"/>, as well as
    </li>
    <li>
	    <xref target="RFC8505">
	    "Registration Extensions for 6LoWPAN IPv6 over
 Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" for SND operations </xref> <xref target="RFC8505"/>, and
	</li>
   <li>
    <xref target="RFC6550">"Routing
    "RPL: IPv6 Routing Protocol for Low Power Low-Power and Lossy Networks"</xref> Networks" <xref target="RFC6550"/> for RPL, which is the routing protocol used in LLNs for SND.
   </li>
	</ul>
  </section> <!--	 end section "References" -->

<section anchor='acronyms' > <name>Acronyms and Initialisms</name>
    <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>
       <dl spacing='compact'> spacing='compact' indent="12">
       <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>6LN:</strong></dt><dd> 6LoWPAN Node  <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 target="RFC6775"/></dd>
       <dt><strong>DAD:</strong></dt><dd> Duplicate Address Detection <xref target="RFC4861"/></dd>
       <dt><strong>DAO:</strong></dt><dd> Destination Advertisement Object <xref target="RFC6550"/> </dd>
       <dt><strong>DODAG:</strong></dt><dd> Destination-Oriented Directed Acyclic Graph </dd>
       <dt><strong>EARO:</strong></dt><dd> Extended Address Registration Option <xref target="RFC8505"/></dd>
       <dt><strong>EDAC:</strong></dt><dd> Extended Duplicate Address Confirmation <xref target="RFC8505"/> </dd>
       <dt><strong>EDAR:</strong></dt><dd> Extended Duplicate Address Request <xref target="RFC8505"/></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>LLN:</strong></dt><dd> Low-Power and Lossy Network </dd>
       <dt><strong>LLA:</strong></dt><dd> Link Layer Link-Layer Address </dd>
        <dt><strong>LoWPAN:</strong></dt><dd> Low-Rate Low-Power Wireless Personal Area Network  <xref target="IEEE802154"/></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>NBMA:</strong></dt><dd> Non-Broadcast Multi-Access (full mesh)</dd>
       <dt><strong>NCE:</strong></dt><dd> Neighbor Cache Entry <xref target="RFC4861"/> </dd>
       <dt><strong>ND:</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 target="RFC4861"/></dd>
       <dt><strong>ROVR:</strong></dt><dd> Registration Ownership Verifier (pronounced "rover") <xref target="RFC8505"/> </dd>
       <dt><strong>RPL:</strong></dt><dd>IPv6 Routing Protocol for LLNs (pronounced "ripple") <xref target="RFC6550"/></dd>
       <dt><strong>RA:</strong></dt><dd> Router Advertisement (message) <xref target="RFC4861"/></dd>
       <dt><strong>RS:</strong></dt><dd> Router Solicitation (message) <xref target="RFC4861"/> </dd>
       <dt><strong>RTO:</strong></dt><dd> RPL Target Option <xref target="RFC6550"/> </dd>
       <dt><strong>SLLAO:</strong></dt><dd>Source Link-Layer Address Option <xref target="RFC4861"/> </dd>
       <dt><strong>SND:</strong></dt><dd>Subnet Neighbor Discovery (protocol)</dd>
       <dt><strong>TID:</strong></dt><dd> Transaction ID <xref target="RFC8505"/></dd>
       <dt><strong>TIO:</strong></dt><dd> Transit Information Option <xref target="RFC6550"/> </dd>
       <dt><strong>TLLAO:</strong></dt><dd>Target Link-Layer Address Option <xref target="RFC4861"/> </dd>

       </dl>

     </section><!-- Acronyms -->

     </section>

  <section anchor="terms"><name>New terms</name> Terms</name>

    <t> This document introduces the following terms:</t>

       <dl newline="false" indent="7" spacing="compact" >

       <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) </dd>

<!--[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 anycast or
       multicast advertisements, either internally from self, in the form of
       a NS(EARO), or as a DAO(TIO, RTO), and generating a single DAO(TIO, RTO).
       The 6RPL router maintains a state per origin for each advertised address, and merges the advertisements for all subscriptions for the same address in a single advertisement.
       A RPL router that merges then becomes the origin of the merged advertisement
       and uses its own values for the Path Sequence and ROVR fields.
       </dd>
       </dl>
  </section> <!--	 end section "New terms" -->
</section>	<!-- end section "Terminology" -->

<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->

<section anchor="overview"><name>Overview</name>
   <t>
   This specification inherits from <xref target="RFC6550"/>,
   <xref target="RFC8505"/>, and <xref target="RFC9010"/> to register prefixes as opposed to addresses.
   </t><t>
   An SND deployment consists of:
   </t>
   <ul>
   <li>
   One
   one or more 6LBR(s) 6LBRs that act(s) act as RPL Root Root,
   </li>   <li>
   intermediate routers down the RPL graph that propagate routing information on addresses and prefixes
   towards the Root Root,
   </li>   <li>
   6LRs that are RPL-aware 6LNs and can leverage RPL directly to expose their addresses and prefixes prefixes, and
   </li>   <li>
   and
   6LNs that are the RPL-unaware destinations and need SND to obtain reachability tover over the RPL LLN for their addresses and, with this specification, their prefixes as well.
   </li>
   </ul>
   <t>
   The SND operation for prefixes inherits from that for unicast addresses,
   meaning that it is the same unless specified otherwise herein.
   In particular, forwarding a packet happens as specified in section 11 of
   <xref target="RFC6550"/>, target="RFC6550" section="11"/>, including loop avoidance and detection, though detection. However, in
   the case of multicast multicast, multiple copies might be generated.
   </t>
   <t><xref target="RFC8505"/> is a pre-requisite prerequisite to this specification.
   A node that implements this MUST <bcp14>MUST</bcp14> also implement <xref target="RFC8505"/>.
   This specification does not introduce a new option; it modifies
   existing options and updates the associated behaviors to enable the
   Registration for prefixes as an extension to
   <xref target="RFC8505"/>.
   </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>
   This specification updates the P-Field introduced in <xref target=
   "RFC9685"/> for use in EARO, DAR, and RTO,
   with the new value of 3 to indicate the registration of a prefix, as
   detailed in <xref target="R8505E"/>.
   With this extension, the 6LN can now express its willingness to receive the traffic for all addresses in the range of a prefix, using the P-Field value of 3 in the EARO to signal that the
   registration is for such prefix. Multiple 6LNs acting as border routers to the same external network or as access routers to the same subnet may register the same prefix to the same 6LR or to different 6LRs.
</t><t>
   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 <bcp14>MUST</bcp14>
   redistribute the prefix in the routing protocol(s) (e.g., RPL) that
   it participates in. The duration of the redistribution is
   based on the longest registration lifetime across the
   non-expired received registrations for the prefix. prefix.`
</t><t>
    Examples of use-cases use cases where this specification may apply include virtual links, shared links,
    and hub links as shown in Sections <xref target="Shared"/> target="Shared" format="counter"/> and <xref target="Hub"/>, target="Hub" format="counter"/>, respectively.
    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.
    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
    and provide signaling to stimulate the redistribution.
</t>
</section> <!-- end section "Overview" -->

   <section anchor="tgt4861"><name>Updating RFC 4861</name>
   <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
   address, which is indicated in the Target Address field of the ND message.
   Section 5.5 of
   <xref target="RFC8505"/> target="RFC8505" section="5.5"/> updates <xref target="RFC4861"/>
   to signal the Registered Address in the Target Address field.
   </t>
   <t>
   This specification updates <xref target="RFC4861"/> by allowing a 6LN to advertise a
   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 target="RFC8505" section="5.5"/>. In that case, the
   prefix length MUST <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.

   </t>
   <t>
   If the 6LN owns at least one an IPv6 address that is derived from the
   registered prefix with a non-0 non-zero interface ID, then it MUST <bcp14>MUST</bcp14> indicate
   one of these addresses in full in the Target Address field of the
   NS(EARO) message. Else, it MUST <bcp14>MUST</bcp14> indicate the prefix padded with 0s zeros
   in the Target Address field.
   </t>
</section> <!-- end section "Updating RFC 4861" -->

    <section anchor="CIO"><name>Updating RFC 7400</name>

    <t>
<!-- [rfced] How should the second sentence be updated for accuracy?
The original is not accurate because RFC 8505 does not update RFC 7400.
(RFC 8505 updates RFC 6775.)

Original:
   This specification updates <xref target="RFC7400"> "6LoWPAN-GHC: Generic Header Compression
   for IPv6 over Low-Power Wireless Personal Area Networks
   (6LoWPANs)"</xref> (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 target="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.
    </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#sixlowpan-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>
   The new "Registration for prefixes Supported" (F) flag indicates
   to the 6LN that the 6LR (1) accepts IPv6 prefix
   registrations as specified in this document and document, (2) will ensure that packets
   for the addresses that match this prefix will be routed to the 6LNs that
   registered the prefix, and (3) will ensure that the route to the prefix will be redistributed if
   the R flag is set to 1.
    </t>
    <t>
   <xref target="fig6CIO"/> illustrates the F flag in its position
   (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>

   <figure anchor="fig6CIO"><name>New Capability Bit in the 6CIO</name>
   <artwork>
    <![CDATA[
   <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length = 1  | Experimental  |X|A|D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|                         Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
    </figure>

    <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 "Registration for prefixes Supported" </dd>
	</dl>

    </section>	<!-- end section "Updating RFC 7400" -->

<section anchor="coex"><name>Updating RFC 6550</name>
<t>
   <xref target="RFC6550"/> uses the Path Sequence in the Transit Information
   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
   the EARO into the Path Sequence, and the ROVR field into the associated RPL
   Target Option (RTO).
   This way, it is possible to identify both the registering node and the
   order of registration in RPL for each individual advertisement, so the
   most recent path and lifetime values are used.
</t><t>

   <xref target="RFC9685"/> requires the use of 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"/>. target="RFC9010" section="6.1"/>.
   For anycast and multicast advertisements (in NS or DAO messages), 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
   parent; in
   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
   propagates an advertisement from a single origin uses the original ROVR in
   the propagated RTO, as it does for unicast address advertisements, so the
   origin is recognized across multiple hops.

</t><t>
   This specification updates <xref target="RFC6550"/> to require that,
   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 same ROVR value); in that case, only the freshest advertisement is retained. But However, the freshness comparison cannot apply if the
   origin is not determined (i.e., the origin did not support this specification).
</t><t>
   <xref target="RFC6550"/> uses the Path Lifetime in the TIO to indicate the
   remaining time for which the advertisement is valid for unicast route
   determination, and a Path Lifetime value of 0 invalidates that route.
   <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
   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
   uses and advertises the longest remaining lifetime
   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
   is 0) using the same value for the ROVR value as for the previous advertisements,
   that is advertisements.
   This value refers to either the router itself or the single descendant that advertised the Target.
</t><t>

   Note that the Registration Lifetime, TID TID, and ROVR fields are also placed in
   the EDAR message message, so the state created by EDAR is also comparable with that created upon an NS(EARO) or a DAO message. For simplicity simplicity, the text below
   mentions only NS(EARO) but applies it also applies to EDAR.
</t>

</section>	<!-- end section "Updating RFC 6550" -->

<section anchor="updating"><name>Updating RFC 8505</name>

<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 overlapping prefixes.
</t>

<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 signal that the -->
   <!-- Registered Address is a prefix. When the P-Field is set to 3, the receiver installs a route to the -->
   <!-- prefix via the sender's address used as source address in the NS(EARO) -->
   <!-- registration message. -->

<!-- </t> --> Value</name>

<t> <xref target="RFC9685"/>  defines a 2-bit P-Field with values 0 through 2 and reserves the
value 3 for future use. This specification defines the semantics of P-Field
value 3.
</t><t>
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)
message with the P-Field set to 3, the receiver MUST <bcp14>MUST</bcp14> install a route to the
indicated prefix via the source address of the NS(EARO) message.
</t><t>
This specification assigns the value 3 to the P-Field, resulting in the
following complete set of defined values:

</t>
<!--[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>
      <tr><td>Value</td><td>Meaning</td></tr>
      <tr><th>Value</th><th>Meaning</th></tr>
     </thead><tbody>
      <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</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> Prefix</td></tr>
     </tbody>
    </table>  <!-- end table "P-Field values" -->

</section><!-- New P-Field value -->

</section>

<section anchor="R8505E"><name>New EARO Prefix Length Field and F flag</name>

<t>
   Section 4.1 of
   <xref target="RFC8505"/> target="RFC8505" section="4.1"/> defines the EARO as an extension to
   the ARO option defined in <xref target="RFC6775"/>.

</t>
<t>
  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
  when the EARO is placed in an NS message as illustrated in <xref target="EARO"/>.
  The prefix length is expressed as 7 bits 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
  this registration is for an address as opposed to a prefix.
  This approach is backward compatible with <xref target="RFC8505"/> and spans
  both addresses and prefixes.
  </t>

<t>
   This specification adds a new F flag to signal that the Registered Prefix
   is topologically correct through the Registering Node. This means that the
   Registering Node relays packets that are sourced in the Registered Prefix
   to the outside, in accordance with "<xref target="RFC2827" format="title"/>"
   <xref target="RFC2827">"Network Ingress Filtering"</xref> . target="BCP38"/>.
   The receiver forwards packets to the Registering Node
   address when the source address of the packets derives from the Registered Prefix.
   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.
   The notion of inside "inside" and outside "outside" are administratively defined, e.g., inside "inside"
   is a particular Layer-2 L2 network such as an Ethernet fabric.
</t>
<t>

   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
   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
   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).
   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
   <xref target="EARO"/>.
</t>
 <figure anchor="EARO"><name>EARO Format for Use in NS Messages</name>
 <artwork align="center"> align="center"><![CDATA[
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Length    |F|Prefix Length|    Opaque     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |r|C| P | I |R|T|     TID       |     Registration Lifetime     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
 ...                            ROVR                             ...
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
 </figure><!-- end figure "EARO Option Format" -->
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
 </figure>

    <t> New and updated Option Fields:    </t>
    <dl>
	<dt><strong>F:</strong> (Forwarding Flag)</dt><dd>
   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
   are sourced from within the registered prefix.</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 included
   in an NS message, this field MUST <bcp14>MUST</bcp14> contain a prefix
   length expressed in bits, with a value between 16 and 120 inclusive. When the
   EARO is included in an NA message, this field MUST <bcp14>MUST</bcp14>
   carry a status value, regardless of the setting of the P-Field. In all other
   cases, this field is reserved; it MUST <bcp14>MUST</bcp14> be set to zero by the sender and MUST <bcp14>MUST</bcp14> be
   ignored by the receiver.
    </dd>

   <dt><strong>r</strong> (reserved):</dt>
   <dd>A 1-bit reserved field. It MUST <bcp14>MUST</bcp14> be set to zero by the sender and
   MUST
   <bcp14>MUST</bcp14> be ignored by the receiver.</dd>

    </dl>

</section> <!-- end section "New EARO Prefix Length Field" -->

<section anchor="R8505D"><name>New EDAR Prefix Length Field</name>

<t>
   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
   assumed to be at most 120 bits long, padded with zeros up to 120 bits, and the
   remaining byte is dedicated to one reserved bit and the prefix length.
</t>
<t>
   <xref target="EDAR"/> illustrates the EDAR message when the value of the
   P-Field is 3. <xref target="EDAC"/> shows the response EDAC message,
   with the Status field and the echoed Prefix.
</t>
 <figure anchor="EDAR"><name>EDAR Message Format with P == 3</name>
 <artwork align="center"> align="center"><![CDATA[
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |CodePfx|CodeSfx|          Checksum             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |P=3| Reserved  |     TID       |     Registration Lifetime     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
...                          ROVR                               ...
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                           Prefix                              +
 |                                                               |
 +              (up to 120 bits, padded with 0s) zeros)              +
 |                                                               |
 +                                               +-+-+-+-+-+-+-+-+
 |                                               |r|Prefix Length|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Options ...
 +-+-+-+-+-+-+-+-+-+-+-+-
</artwork>
 </figure><!-- end figure "EDAR Message Format with P == 3" -->
 +-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>
 </figure>

 <figure anchor="EDAC"><name>EDAC Message Format</name>
 <artwork align="center"> align="center"><![CDATA[
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |CodePfx|CodeSfx|          Checksum             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Status     |     TID       |     Registration Lifetime     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
...                          ROVR                               ...
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                           Prefix                              +
 |                                                               |
 +              (up to 120 bits, padded with 0s) zeros)              +
 |                                                               |
 +                                               +-+-+-+-+-+-+-+-+
 |                                               |r|Prefix Length|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Options ...
 +-+-+-+-+-+-+-+-+-+-+-+-
</artwork>
 </figure><!-- end figure "EDAR Message Format with P == 3" -->
 +-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>
 </figure>

    <t> New and updated EDAR/EDAC Message Fields:    </t>
	<dl>

	<dt><strong>Prefix:</strong></dt><dd>A 15-byte field that carries up
   to 120 bits of the prefix. If the prefix isshorter is shorter than 120 bits, the
   remaining bits MUST <bcp14>MUST</bcp14> be padded with zeros.
   The receiver MUST <bcp14>MUST</bcp14> treat the padding as zeroed and MUST <bcp14>MUST</bcp14> overwrite any
   unused bits with zeros before using the prefix.</dd>

   <dt><strong>r</strong> (reserved):</dt>
   <dd>A 1-bit reserved field. It MUST <bcp14>MUST</bcp14> be set to zero by the sender and
   MUST
   <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
   indicating the length of the prefix in bits. The value MUST <bcp14>MUST</bcp14> be in the
   inclusive range of 16 to 120.</dd>
	</dl>

   <t>
   The capability to place The the P-Field and the contiguous "Reserved" field in the EDAR message are is specified in section 7.2 of <xref target="RFC9685"/>. target="RFC9685" section="7.2"/>.
   </t>
   <t>
   The capability to append ND options to the EDAR and EDAC messages is introduced in section 3.1 of <xref target="RFC8929"/>. target="RFC8929" section="3.1"/>.
   </t>
   <t>
   All other fields follow the same definition as specified in <xref target="RFC8505"/>.
   The values for these fields and RFC references are maintained by IANA under the "Internet Control Message
    Protocol version 6 (ICMPv6) Parameters" <xref target="IANA.ICMP"/> registry grouping. group.
   </t>

</section> <!-- end section "New EDAR Prefix Length Field" -->

<section anchor="multireg"><name>Updating the Registration Operation</name>
<t>
   With <xref target="RFC8505"/>:
   </t>
<ul>
   <li>
   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
   upon reboot.
   In all other cases, a node reboot is silent.
   When the node comes back to life, existing registration
   state might be lost if it was not safely stored, e.g., in persistent memory.
   </li>
   <li>
   Only unicast addresses can be registered.
   </li>
   <li>
   The 6LN must register all its Unique Local Addresses (ULAs) and Global Unicast Addresses (GUAs) with a NS(EARO).
   </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>
   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.
   </li>
   <li>
   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).
   </li>
   </ul>
   <t>
   The operation for registering prefixes is similar to that for addresses from the
   perspective of the 6LN, but shows important differences on the router side,
   which maintains a separate state for each origin and merges them in its own
   advertisements. This specification adds the following behavior, similar to that introduced
   by <xref target="RFC9685"/> for multicast addresses:
  </t>
   <ul>

   <li>
   <t>
   The EARO status indicating a "Registration Refresh Request" applies to prefixes
   as well.
   </t>
   <t>
   This status is used in asynchronous NA(EARO) messages to indicate to peer 6LNs
   that they are requested to reregister all addresses and prefixes that were
   previously registered to the originating node. The NA message MAY <bcp14>MAY</bcp14> be sent to
   a unicast or a multicast link-scope address and SHOULD <bcp14>SHOULD</bcp14> be contained within
   the L2 range where nodes may effectively have registered/subscribed to this
   router, e.g., a radio broadcast domain to preserve energy and spectrum.

   </t>
   <t>
   A device that wishes to refresh its state, e.g., upon reboot if it may have
   lost some registration state, SHOULD <bcp14>SHOULD</bcp14> send an asynchronous NA(EARO) with this
   new status value. That asynchronous NA(EARO) SHOULD <bcp14>SHOULD</bcp14> be sent to the all-nodes
   link-scope multicast address (ff02::1) (ff02::1), and Target MUST <bcp14>MUST</bcp14> be set to the
   link-local address that was exposed previously by this node to accept
   registrations, and the TID MUST <bcp14>MUST</bcp14> be set to 0; the ROVR field MUST <bcp14>MUST</bcp14> be set to
   all zeroes zeros and ignored by the receiver.
   </t>
   <t>
   In an environment with unreliable transmissions, the multicast NA(EARO)
   message may be resent in a fast sequence, in which case the TID is incremented each time.
   A 6LN that has recently
   processed the NA(EARO)  indicating a "Registration Refresh Request"
   ignores the additional NA(EARO) also
   indicating a "Registration Refresh Request" within the duration of
   the fast sequence. That duration depends on the
   environment and has to be configured. By default, it is 10 seconds.
   </t>
   </li>
   <li>
   <t>
   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
   as opposed to an address. DAD for prefixes and addresses becomes a prefix
   overlap match. Whether overlapping addresses and prefixes may be registered
   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 value of the ROVR.
   </t>
   <t>
   Overlaps may be desirable. It For instance, it may happen for instance that a router or a
   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
   aggregation also registers its piece.
   </t>
   <t>
   In case of an overlapping registration, the longest prefix match wins, meaning that
   if the  network policy allows for overlapping registrations, then the
   routes for the registered prefixes are installed towards the node that
   registered with  the longest prefix match, all the way to /128.
   </t>
   </li>
   <li>
   If the 6LR acts as a border router to external prefixes or owns the prefixes entirely,
   it SHOULD <bcp14>SHOULD</bcp14> register all those prefixes on all interfaces from which 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.

Original:
      It MUST set the P-Field in the EARO to 3 for those
      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 MAY <bcp14>MAY</bcp14> refrain from registering a prefix
   on one interface if that prefix is already successfully registered on
   another interface, or the router handled the EDAR / EDAC EDAR/EDAC flow by itself,
   to ensure that the prefix ownership is known and validated by the 6LBR.
   Additionally, if the router expect expects to receive traffic for that prefix on that
   interface, it needs to ensure that the prefix is advertised some other way,
   e.g., over a routing protocol such as RPL.
   </li>
   <li>
   The 6LN MAY <bcp14>MAY</bcp14> set the R flag in the EARO to request the 6LR to redistribute
   the prefix on other links using a routing protocol. The 6LR MUST NOT <bcp14>MUST NOT</bcp14>
   reregister that prefix to yet another router unless loops are avoided some way,
   e.g., following a tree structure.
   </li>
   <li>
   The 6LR and the 6LBR are extended to accept more than one registration for
   the same prefix, since multiple 6LNs may register it.
   The ROVR in the EARO identifies uniquely a registration
   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>
    The 6LR <bcp14>MUST</bcp14> maintain a registration state per tuple (IPv6 prefix/length, ROVR)
    for all registered prefixes. It SHOULD <bcp14>SHOULD</bcp14> notify the 6LBR
    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 6LBR MUST <bcp14>MUST</bcp14> maintain a
    registration state per tuple (IPv6 prefix, ROVR) for all prefixes.
   </li>

   </ul>

</section> <!-- end section "Updating the Registration Operation"-->

</section> <!-- end section "Updating RFC 8505"-->

<section anchor="updating2"><name>Updating RFC 9010</name>
<t>
   With <xref target="RFC9010"/>:
   </t>
   <ul>
   <li>
   The 6LR injects only unicast routes in RPL.
   </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.
   </li>
   <li>
   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 L2 frame
   to the LLA of the node that registered the unicast address.
   </li>
   </ul>
   <t>
   This specification adds the following behavior:
   </t>
   <ul>
   <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.
   The P-Field in the RTP MUST <bcp14>MUST</bcp14> be set to 3.

   </li><li>
   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
   as a unicast layer-2 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
   best 6LN.
   </li>
   </ul>

</section> <!-- end section "Updating RFC 9010"-->

<section  anchor="sec8928"><name>Updating RFC 8928</name>
<t>
    <xref target="RFC8928"> Address-Protected
    "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks </xref> Networks" <xref target="RFC8928"/> was defined to protect the ownership of unicast IPv6 addresses that are registered with
    <xref target="RFC8505"/>.

</t>
<!--t><xref target="RFC8928"/> defines the "C" flag but fails to explicit the bit number and fails to make a IANA registration for that bit position. On the other hand, a position for the bit (bit 3) is represented in Figure 1 of <xref target="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 specification updates <xref target="RFC8928"/> to position the "C" flag as bit 1 of the EARO flag, as represented in <xref target="EARO"/>, to avoid the overlapping definitions.
</t-->

<t>
    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
    addresses that are either autoconfigured or obtained through other methods.

</t>
<t>
    The first hop first-hop router (the 6LR) can then validate a registration and
    perform source address validation on packets coming from the sender node
    (the 6LN).

</t>
<t>
    As multiple nodes may register the same prefix, the method specified
    in <xref target="RFC8928"/> cannot be used with node-local
    autoconfigured keypairs, which protect a single ownership only.
</t>
<t>
    For a prefix, as for an anycast or a multicast address, it is still possible
    to leverage AP-ND <xref target="RFC8928"/> to enforce the right to register.
    If AP-ND <xref target="RFC8928"/> is used, a keypair MUST <bcp14>MUST</bcp14> be created and
    associated with the prefix before the prefix is deployed, and a ROVR MUST <bcp14>MUST</bcp14> be
    generated from that keypair as specified in <xref target="RFC8928"/>.
    The prefix and the ROVR MUST <bcp14>MUST</bcp14> then be installed in the 6LBR at the first
    registration, or by an external mechanism such as IP Address Management
	(IPAM) or DHCPv6 snooping prior to the first registration.
	This way, the 6LBR can recognize the prefix
    on the future registrations and validate the right to register based on the
    ROVR.
</t>
<t>
    The keypair MUST <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
    steps in <xref target="RFC8928"/> to register the prefix.
</t>
<t>
    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 based
	on that longest prefix match.
</t>
</section>  <!-- Updating RFC 8928 -->

<section  anchor="ext8929"><name>Updating RFC 8929</name>
<t>
  <xref target="RFC8929">"IPv6
  "IPv6 Backbone Router"</xref> Router" <xref target="RFC8929"/> defines a proxy
  operation whereby a 6LoWPAN Border Router (6LBR)
  may impersonate a 6LN when performing an address registration.
  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
  Registering Node (the 6LBR) as opposed to the Registered Node (the 6LN).
  See figure 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.
</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>
   This specification updates that proxy operation with the updates in
   <xref target="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. The proxy MUST <bcp14>MUST</bcp14> use the P-Field as received
  in the EDAR or NS(EARO) message to generate the proxied NS(EARO), and it MUST <bcp14>MUST</bcp14>
  use the exact same prefix and prefix length as received in the case of
  a prefix registration.

</t>
</section>  <!-- Updating RFC 8929 -->

<section  anchor="sec"><name>Security Considerations</name>
<t>
    This specification updates <xref target="RFC8505"/>, and
    the security section considerations of that document also applies apply to this document.
    In particular, the link layer SHOULD <bcp14>SHOULD</bcp14> be sufficiently
    protected to prevent rogue access, else a rogue node with physical Access access
    to the network may inject packets and perform an attack from within.
</t>
<t>
   <xref target="sec8928"/> leverages AP-ND <xref target="RFC8928"/> to prevent a
   rogue node to register from registering a unicast address that it does not own.
   The mechanism could be extended to anycast and multicast addresses
   if the values of the ROVR they use are known in advance,
   but how this is done is
   not in scope for this specification.
   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
   the valid registering nodes as a preshared key material.
</t>
<t>
   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
   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, time and
   switch the traffic to that address when the migration is complete.
</t>
</section>	<!-- end section "Security Considerations" -->

<section anchor="back"><name>Operational Considerations</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>
   A mix of devices that support only <xref target="RFC8505"/>, both
   <xref target="RFC8505"/> and <xref target="RFC9685"/>, and all of the
   above plus this specification, may coexist.  Different cases may occur:
</t>
<ul>
<li>
   A legacy 6LN will not register prefixes prefixes, and the service will be
   the same when the network is upgraded.
</li>
<li>
   A legacy 6LR will not set the F flag
   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.
</li>
<li>
   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
   EDAC status. The 6LR MUST <bcp14>MUST</bcp14> ignore a duplicate status in the EDAR for prefixes.
</li>
</ul>

</section> <!-- end section "Partially Upgraded Networks" -->
<section anchor="LLN"><name>Application to RPL-Based Route-Over LLNs</name>
   <t>
   This specification also updates <xref target="RFC6550"/> and
   <xref target="RFC9010"/> in the case of a route-over multilink subnet based
   on the RPL routing protocol, to add multicast ingress replication in
   Non-Storing Mode and anycast support in both Storing and Non-Storing modes.
   A 6LR that implements the RPL extensions specified therein MUST <bcp14>MUST</bcp14> also
   implement <xref target="RFC9010"/>.
   </t>
    <t>
    <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
    for RPL operations and as Address Registrar for 6LowPAN ND.
    </t>

    <figure anchor="figref" align="center"><name>RPL-Based Route-Over LLN</name>
    <artwork><![CDATA[
         .- -- .
      .-(        ).
     (   Internet   )
    (___.________.___)
              |
   ---+-------+--
      |
    +--------+
    |  6LBR  |
    | (Root) |
    +--------+
    o   o  o  o
      o   o  o
 o  o  o       o  o  o
 o  o  o  LLN   o   +-------+
   o  o          o  |  6LR  | RPL Router
   o o    o   o     +-------+
   o  o    o  o          +-------+  RPL
          o              |  6LN  |  leaf
                         +-------+  L

  o : LLN node
]]></artwork></figure>

<t>
   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 L2 unicast NS message
   with an EARO as specified in <xref target="RFC8505"/> and <xref target=
   "RFC9685"/>.
   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
   serving virtual machines or applications within the same physical node.
   Note also that a RPL-aware Leaf would preferably leverage RPL directly
   to inject routes, to fully leverage the routing protocol.
   The registration state is periodically renewed by the Registering Node (the 6LN),
   before the lifetime indicated in the EARO expires (at the 6LR). As for unicast IPv6
   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.
<!--[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
   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.

</t>

</section><!--end section "LLN Mesh Network"
-->
   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.
</t>

</section>

<section anchor="Shared"><name>Application to a Shared Link</name>

<t>
    A shared link is a situation where more than one prefix is deployed over
    a
    an L2 link (say (say, a switched Ethernet fabric, 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="figshared"/> depicts such
    a situation, with 2 two routers 6LR1 and 6LR2 that own respective prefixes P1::
    and P2::, 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
    as discussed in section 7 of <xref target="I-D.ietf-6man-ipv6-over-wireless"/>. target="I-D.ietf-6man-ipv6-over-wireless" section="7"/>.
</t>

    <figure anchor="figshared" align="center"><name>Shared Link</name>
    <artwork><![CDATA[
         .- -- .
      .-(        ).
     (   Internet   )
    (___.________.___)
          |
     +----+--+          +-------+
     | P1::a |          | P2::b |
     | 6LR1  |          | 6LR2  |
     +---+---+          +---+---+
         |                  |
  ----+--+------+---------+-+-------+---------+----
      |         |         |         |         |
   +--+--+   +--+--+   +--+--+   +--+--+   +--+--+
   |P1::c|   |P2::d|   |P2::e|   |P1::f|   |P1::g|
   +-----+   +-----+   +-----+   +-----+   +-----+

    ]]></artwork></figure>   +-----+]]></artwork></figure>
<t>
    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
    registers P2:: to 6LR1 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.

    6LR2 may then leverage ICMP Redirect messages <xref target="RFC4861"/> to shorten the
    path between 6LR1 and the nodes that own those addresses.
    </t>

<t> If P2 was were delegated by 6LR1, e.g., using the DHCPv6 <xref target="RFC8415">
    "Dynamic Host Configuration Protocol for IPv6" </xref> (DHCPv6), target="RFC8415"/>,
    then the expectation is that 6LR1 aggregates
    P1:: and P2:: in its advertisements to the outside, and there is no need to
    set the R flag. But However, unless 6LR2 knows about such a situation, e.g., through
    configuration, 6LR2 SHOULD <bcp14>SHOULD</bcp14> set the R flag requesting
    6LR1 to advertise P2:: so as to obtain reachability.
</t>
</section> <!-- end section "Shared Link" -->

<section anchor="Hub"><name>Application to a Hub Link with Stub Spokes</name>

<t>
    A hub link is a situation where stub links are deployed around a backbone and
    interconnected by routers. <xref target="fighub"/> depicts such
    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
    hub link. In this example, say that there is one prefix on each link, link --
    P1:: on the hub link link, and P2:: and P3:: on the stub links.
</t>

    <figure anchor="fighub" align="center"><name>Hub and Stubs</name>
    <artwork><![CDATA[
   +-----+   +-----+   +-----+       +-----+
   |P2::s|   |P2::d|   |P2::e|       |P2::f|
   +--+--+   +--+--+   +--+--+       +--+--+
      |         |         |             |
  ----+----+----+---------+--STUB-LINK--+-----
           |
       +---+---+              +-------+
       | P2::r |              |       |        .- --..
       | 6LR2  |              | 6LR1  +---- .-(       ).
       | P1::b |              | P1::a |   (   Internet  )
       +---+---+              +---+---+  (___._______.___)
           |                      |              |
  -------+-+---------+--HUB-LINK--+-----+--      |
         |           |                  |        |
     +---+---+    +--+--+           +---+---+    |
     | P1::c |    |P1::n|           | P1::q |    |
     | 6LR3  |    +-----+           | 6LR4  +----+
     | P3::m |                      | P3::a |
     +---+---+                      +---+---+
         |                              |
  ----+--+------+---------+--STUB-LINK--+-+-----
      |         |         |               |
   +--+--+   +--+--+   +--+--+         +--+--+
   |P3::h|   |P3::i|   |P3::j|         |P3::k|
   +-----+   +-----+   +-----+         +-----+

    ]]></artwork></figure>         +-----+]]></artwork></figure>
<t>
    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
    registers P2:: to 6LR1 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
    still be reached via 6LR1 and then 6LR2. The same goes for 6LR3 and any other
    routers serving stub links.
</t><t>
    If P2 was 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
    set the R flag. But However, unless 6LR2 knows about such a situation, e.g., through
    configuration, 6LR2 SHOULD <bcp14>SHOULD</bcp14> set the R flag requesting
    6LR1 to advertise P2:: so as to obtain reachability.
</t><t>
    In this example, routers 6LR3 and 6LR4 both connect to the same stub link where subnet P3 is installed.
    They may both register P3 to 6LR1, and 6LR1 will apply its own load balancing load-balancing logic to use
    either of the routers.
</t>
</section> <!-- end section "Hub Link" -->
</section>	<!-- end section "Operational Considerations" -->

<section ><name>IANA Considerations</name>
<t>
    Note to RFC Editor, to be removed: please replace "This RFC" throughout this
    document by the RFC number for this specification once it is allocated.
</t>
<t>
    IANA is requested to make has made changes under the "Internet Control Message
    Protocol version 6 (ICMPv6) Parameters" <xref target="IANA.ICMP"/> and the
    "Routing Protocol for Low Power and Lossy Networks (RPL)" <xref target="IANA.RPL"/>
    registry groupings, groups, as follows: follows.
</t>

    <section anchor="PF"><name>Updated P-Field Registry</name>

	<t>
    This specification updates the P-Field introduced in <xref target=
    "RFC9685"/> to assign the value of 3, which is
    the only remaining unassigned value for the 2-bit field. To that effect,
    IANA is requested to update has updated the "P-Field values" Values" registry under in the
    heading
    "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry group
    as indicated in <xref target="AM2"/>:
	</t>

	 <table anchor="AM2" ><name>New P-Field value</name> Value</name>
     <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>
      <tr><td><strong>3</strong></td><td>Registration for a prefix</td><td>This RFC</td></tr> Prefix</td><td>RFC 9926</td></tr>
     </tbody>
    </table>  <!-- end table "New P-Field values" -->

    </section><!-- end section "Updated P-Field Registry" -->

    </section>

    <section anchor="CIOF">   <name>New 6LoWPAN Capability Bit</name>
	<t>
    IANA is requested to make has made an addition to the
    "6LoWPAN Capability Bits" <xref target="IANA.ICMP.6CIO"/> registry under in the
    heading
    "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry group
    as indicated in <xref target="CIOdat"/>:
	</t>
   <t>IANA is also requested to fix has fixed the description of bit 9 (the  "A" flag defined in <xref target="RFC8928"/>).
   It is not called "1" but "A".
   </t>
	<table anchor="CIOdat" ><name>New 6LoWPAN Capability Bit</name>
   <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>
      <tr><td><strong>9 </strong></td><td>AP-ND
      <tr><td><strong>9</strong></td><td>AP-ND Enabled (A bit) </td><td><xref bit)</td><td><xref target="RFC8928"/></td></tr>
      <tr><td><strong>16 (suggested)</strong></td><td>Registration
      <tr><td><strong>16</strong></td><td>Registration for prefixes Supported (F bit)</td><td>This RFC</td></tr> bit)</td><td>RFC 9926</td></tr>

   </tbody>
	</table>	<!-- end table "New 6LoWPAN Capability Bit" -->

    </section>	<!-- end section "New 6LoWPAN Capability Bit" -->

</section>

</middle>

<back>

<!-- end section "IANA Considerations" -->

<section title="Acknowledgments">
<t>
   Many thanks [rfced] Would you like the references to Dave Thaler and Dan Romascanu for be alphabetized
or left in their early reviews, Adnan Rashid 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, Dan Romascanu,
   Shuping Peng, Mohamed Boucadair, Paul Wouters, Ketan Talaulikar, Gunter Van de Velde, Mike Bishop, Roman Danyliw, ...
</t>
</section> <!-- title="Acknowledgments" current order?
-->

</middle>

<back>

<displayreference   target="RFC2827"    to="BCP38"/>

    <references title="Normative References">
	<!-- RFC  --> target="I-D.ietf-6man-ipv6-over-wireless" to="IPv6-over-NBMA"/>

    <references><name>Normative References</name>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7400.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7400.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8928.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8928.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9010.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9010.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9685.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9685.xml"/>

	   <reference anchor="IANA.ICMP"> anchor="IANA.ICMP" target="https://www.iana.org/assignments/icmpv6-parameters">
             <front>
			<title>IANA Registry for ICMPv6</title>
               <title>Internet Control Message Protocol version 6 (ICMPv6) Parameters</title>
               <author>
				<organization>
					IANA
				</organization>
                 <organization>IANA</organization>
               </author>
			<date year=""></date>
             </front>
		<seriesInfo name="IANA," value="https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml"></seriesInfo>
           </reference>

       <reference anchor="IANA.ICMP.6CIO"> anchor="IANA.ICMP.6CIO" target="https://www.iana.org/assignments/icmpv6-parameters">
         <front>
			<title>IANA Registry for the 6LoWPAN
           <title>6LoWPAN Capability Bits</title>
           <author>
				<organization>
					IANA
				</organization>
             <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"></seriesInfo>
       </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-flags"></seriesInfo>
	   </reference-->

	   <reference  anchor="IANA.RPL">  anchor="IANA.RPL" target="https://www.iana.org/assignments/rpl">
             <front>
			<title>IANA Registry
               <title>
                 Routing Protocol for the RPL</title> Low Power and Lossy Networks (RPL)
               </title>
               <author>
				<organization>
					IANA
				</organization>
                 <organization>IANA</organization>
               </author>
			<date year=""></date>
             </front>
		<seriesInfo name="IANA," value="https://www.iana.org/assignments/rpl/rpl.xhtml"></seriesInfo>
           </reference>

    </references>

    <references title="Informative References">
	<!-- RFC  -->

    <!-- I-D -->

    <references><name>Informative References</name>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2827.xml"/> href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0038.xml"/>

    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4191.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4191.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4919.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4919.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9030.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9030.xml"/>
<!-- <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.kuehlewind-update-tag.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://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.heile-lpwan-wisun-overview.xml"/-->
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-ipv6-over-wireless.xml"/>
      <reference anchor="IEEE802154">
         <front>
            <title>IEEE href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-ipv6-over-wireless.xml"/>

<!-- [rfced] Please review the informative reference [IEEE802154].
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?

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".

Current:
   [IEEE802154]
              IEEE, "IEEE Standard for Information technology - Local
              and metropolitan area networks - Specific requirements -
              Part 15.4: Wireless Medium Access Control (MAC) and
              Physical Layer (PHY) Specifications for Low Rate Wireless
              Personal Area Networks (WPANs)", IEEE Std 802.15.4-2006,
              DOI 10.1109/IEEESTD.2006.232110, 2006,
              <https://ieeexplore.ieee.org/document/1700009>.

Most recent version (potential update):

   [IEEE802154]
              IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
              Std 802.15.4-2024, DOI 10.1109/IEEESTD.2024.10794632,
              2024, <https://ieeexplore.ieee.org/document/10794632>.
-->

<!-- [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 standard
    <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/document/1700009">
         <front>
            <title>IEEE Standard for Information Technology</organization> technology -- Local and metropolitan area networks -- Specific requirements -- Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (WPANs)
            </title>
            <author>
               <organization>IEEE</organization>
            </author>
            <date/>
            <date year="2006"/>
         </front>
         <seriesInfo name="IEEE Std" value="802.15.4-2006"/>
         <seriesInfo name="DOI" value="10.1109/IEEESTD.2006.232110"/>
      </reference>

      <reference anchor="IEEE80211"
                 target="https://ieeexplore.ieee.org/document/9363693" >
        <front>
          <title>
            IEEE Standard 802.11 - IEEE Standard for Information Technology - -- Telecommunications and information exchange Information Exchange between systems
Systems - Local and metropolitan area networks - Metropolitan Area Networks -- Specific requirements Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
            Specifications. Specifications
          </title>
          <author>
               <organization>IEEE standard for Information Technology</organization>
               <organization>IEEE</organization>
           </author>
          <date/>
        </front>
        <seriesInfo name="IEEE Std" value="802.11-2022"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9363693"/>
      </reference>

      <reference anchor="WI-SUN"
                 target="https://wi-sun.org/" >
        <front>
          <title>
            Wi-SUN Alliance
          </title>
          <author/>
          <date/>
        </front>
      </reference>
      <reference anchor="IEEE802151">
         <front>
            <title>
<!-- [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)
            </title>
            <author>
            	<organization> (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 standard 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/document/1016473">
         <front>
            <title>IEEE Standard for Telecommunications and Information Technology
		</organization> 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)
            </title>
            <author>
            	<organization>IEEE</organization>
            </author>
            <date/>
            <date year="2002"/>
         </front>
         <seriesInfo name="IEEE Std" value="802.15.1-2002"/>
         <seriesInfo name="DOI" value="10.1109/IEEESTD.2002.93621"/>
      </reference>

    </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>

<!--[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>