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

<!-- pre-edited by ST 05/28/24 -->

<!-- draft submitted in xml v3 -->

<!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;">
]>

<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, 6553, 8505, 9010" docName="draft-ietf-6lo-multicast-registration-19" > number="9685" symRefs="true" sortRefs="true">

<front>
   <title abbrev="Multicast and Anycast Subscription">IPv6 Subscription">Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription</title> Addresses</title>
   <seriesInfo name="RFC" value="9685"/>
   <author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor'>
      <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="November" year="2024"/>
   <area>INT</area>
   <workgroup>6lo</workgroup>

   <abstract>
   <t>
    This document updates the 6LoWPAN extensions to IPv6 Neighbor Discovery
    (RFC 4861, RFC
    (specified in RFCs 4861 and 8505) to enable a listener to subscribe to an IPv6 anycast
    or multicast address;  the address. This document also updates the Routing Protocol for
    Low-Power and Lossy Networks (RFC 6550, RFC (RPL) (specified in RFCs 6550 and 6553) to add a new Non-Storing Multicast Mode
    multicast mode and a new support for anycast addresses in Storing and
    Non-Storing Modes. modes.  This document extends RFC 9010 to enable a 6LoWPAN
    Router (6LR) to inject the anycast and multicast addresses in RPL.
   </t>
   </abstract>
</front>

<middle>

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

<section anchor="introduction">
  <name>Introduction</name>

  <t>The design of Low Power 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 (when 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>
   The <xref target="RFC6550">"Routing times.</t>

  <t>"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
  which may be a fuzzy concept anyway in each LLN.
</t><t>
   This trades a radio LLN.</t>

  <t>This stretches the quality of peer-to-peer (P2P) paths routes between RPL nodes inside the DODAG for a vastly reduced
  amount of control traffic and routing state that would be required to
  operate an any-to-any shortest path protocol. Additionally, broken routes
  may be fixed lazily and on-demand, on-demand based on dataplane data plane inconsistency
  discovery, which avoids wasting energy in the proactive repair of unused paths.
</t><t>
   RPL
  paths.</t>

  <t>RPL uses Destination Advertisement Object (DAO) messages to
  establish Downward routes.  DAO messages are an optional feature for
  applications that require point-to-multipoint (P2MP) or point-to- point
  (P2P) traffic.  RPL supports two modes of Downward traffic: Storing (fully
  stateful) or Non-Storing (fully source routed); see
   Section 9 of <xref target="RFC6550"/>. target="RFC6550"
  sectionFormat="of" section="9"/>. The mode is signaled in the Mode of
  Operation (MOP) field in the DODAG Information Object (DIO) messages and
  applies to the whole RPL Instance.

</t><t>
   Any Instance.</t>

<t>Any given RPL Instance is either storing Storing or non-storing. Non-Storing.  In both cases,
  P2P packets travel Up toward a DODAG root then Down to the final destination
  (unless the destination is on the Upward route).  In the Non-Storing case,
  the packet will travel all the way to a DODAG root before traveling Down.
  In the Storing case, the packet may be directed Down towards the destination
  by a common ancestor of the source and the destination prior to reaching a
  DODAG root.
   Section 12 of <xref target="RFC6550"/> target="RFC6550" sectionFormat="of" section="12"/> details
  the "Storing Storing Mode of Operation with multicast support" support with
  source-independent multicast routing in RPL.
</t><t>
   The RPL.</t>

  <t>The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" (ND) protocol <xref
  target="RFC4861"/> <xref target="RFC4862"/> was defined for serial links and
  shared transit media such as Ethernet at a time when broadcast
   was cheap on
  those media types was cheap, while memory for neighbor cache was expensive.  It was thus
  designed as a reactive protocol that relies on caching and multicast
  operations for the Address Discovery (aka Lookup) 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
  targeted. This is a waste of energy, energy and imply implies that all nodes are awake to
  hear the request, which is inconsistent with power
   saving power-saving (sleeping) modes.
</t><t>
   The
  modes.</t>

  <t>The original specification for 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) (6LR) Routers (6LRs) that serve(s) 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 6LR.
</t><t>
   <xref target="RFC8505"> "Registration 6LR.</t>

  <t>"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 so that a generic Address Registration mechanism that can be
  used to access services such as routing and ND proxy and introduces the
  Extended Address Registration Option (EARO) for that purpose. This provides
  a routing-agnostic interface for a host to request that the router injects a
  unicast IPv6 address in the local routing protocol and provide provides return
  reachability for that address.
</t><t>
   <xref target="RFC9010">"Routing address.</t>

  <t>"Routing for RPL Leaves"</xref> (Routing Protocol for Low-Power and Lossy Networks) Leaves" <xref target="RFC9010"/> provides the
  router counterpart of the mechanism for a host that implements <xref
  target="RFC8505"/> to inject its unicast Unique Local Addresses (ULAs) and
  Global Unicast Addresses (GUAs) in RPL.
   But though  Although RPL also provides
  multicast routing, 6LoWPAN ND supports only the registration of unicast addresses
  addresses, and there is no equivalent of <xref target="RFC9010"/> to specify
  the 6LR behavior upon the subscription of one or more multicast address(es).
</t><t>
   The <xref target="RFC3810">"Multicast addresses.</t>

  <t>"Multicast Listener Discovery Version 2 (MLDv2) for IPv6" </xref> <xref
  target="RFC3810"/> enables the router to learn which node listens to which
  multicast address, but as the classical IPv6 ND protocol, MLD relies on
  multicasting Queries queries to all nodes, which is unfit for low power low-power operations.
  As for IPv6 ND, it makes sense to let the 6LNs control when and how they
  maintain the state associated to their multicast addresses in the 6LR, e.g.,
  during their own wake time. In the case of a constrained node that already
  implements <xref target="RFC8505"/> for unicast reachability, it makes sense
  to extend to that support to subscribe the multicast addresses they listen to.
</t><t>
   This
  to.</t>

  <t>This specification Extends <xref target="RFC8505"/> and <xref
  target="RFC9010"/>
   to add by adding the capability for the 6LN to subscribe anycast
  and multicast addresses and for the 6LR to inject them in RPL when
  appropriate. Note that due to the unreliable propagation of packets in the
  LLN, it cannot be guaranteed that any given packet is delivered once and
  only once. If a breakage happens along the preferred parent tree that is
  normally used for multicast forwarding, the packet going up Up may be rerouted
  to an alternate parent, leading to potential failures and duplications,
  whereas a packet going down Down will not be delivered in the subtree. It is up
  to the Upper Layer Protocols (ULPs) to cope with both situations.
</t> situations.</t>

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

<section>
  <name>Terminology</name>
  <section anchor="bcp"><name>Requirements 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

	<t>In addition, the terms "Extends" and "Amends" are used as a more
	specific term terms for "Updates" per
  <xref target="I-D.kuehlewind-update-tag" /> section Section 3 of <xref
	target="I-D.kuehlewind-rswg-updates-tag"/> as follows:
  </t>
	follows:</t>

	<dl newline="false" indent="7" spacing="compact" > spacing="normal">
	  <dt>Amends/Amended by:</dt>
	  <dd>This tag pair is used with an amending RFC that changes the amended
	  RFC. This could include bug fixes, behavior changes 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 <bcp14>MUST</bcp14> also implement the amending RFC. </dd>

	  <dt>Extends/Extended by:</dt>
			<dd> This
	  <dd>This tag pair is used with an extending 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>References</name>
    <t>
	This anchor="lo">
    <name>Terminology from Relevant RFCs</name>
    <t>This document uses terms and concepts that are discussed in:
    </t> in:</t>
	<ul>
	<li> <xref target="RFC4861">"Neighbor
	  <li>"Neighbor Discovery for IP version 6"
		</xref> and 6 (IPv6)" <xref target="RFC4862">"IPv6 target="RFC4861"/>,</li>
	  <li>"IPv6 Stateless address Address Autoconfiguration"
		</xref>,
    </li>
	<li> <xref target="RFC6550">Routing target="RFC4862"/>,</li>
	  <li>"RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</xref>,
    </li>
	<li> Networks" <xref target="RFC6775">Neighbor target="RFC6550"/>,</li>
	  <li>"Neighbor Discovery Optimization for IPv6 over Low-Power
		and Lossy Networks</xref>, as well as
    </li>
    <li> Wireless Personal Area Networks (6LoWPANs)" <xref target="RFC8505">
		"Registration
	  target="RFC6775"/>,</li>
	  <li>"Registration Extensions for 6LoWPAN IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery"</xref> and
	</li>
    <li> Discovery" <xref target="RFC9008">
		"Using
	  target="RFC8505"/>, and</li>
	  <li>"Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane"</xref>.
	</li> Plane" <xref
	  target="RFC9008"/>.</li>
	</ul>
  </section> <!--	 end section "References" -->

  <section anchor="acronyms"><name>Glossary</name>
    <t> This anchor="abbreviations">
    <name>Abbreviations</name>
    <t>This document uses the following acronyms:</t> abbreviations:</t>
       <dl newline="false" indent="7" spacing="compact" >
       <dt>6BBR</dt><dd> 6LoWPAN Backbone Router </dd>
       <dt>6CIO</dt><dd> Capability spacing="normal">
	 <dt>6CIO:</dt><dd>Capability Indication Option </dd>
       <dt>6LBR</dt><dd> 6LoWPAN Option</dd>
	 <dt>6LBR:</dt><dd>6LoWPAN Border Router </dd>
       <dt>6LN</dt><dd> 6LoWPAN Node </dd>
       <dt>6LR</dt><dd> 6LoWPAN Router </dd>
       <dt>AMC</dt><dd> Address Mapping Confirmation </dd>
       <dt>AMR</dt><dd> Address Mapping Request</dd>
       <dt>ARO</dt><dd> Address Router</dd>
	 <dt>6LN:</dt><dd>6LoWPAN Node</dd>
	 <dt>6LR:</dt><dd>6LoWPAN Router</dd>
	 <dt>ARO:</dt><dd>Address Registration Option</dd>
       <dt>DAC</dt><dd> Duplicate
	 <dt>DAC:</dt><dd>Duplicate Address Confirmation </dd>
       <dt>DAD</dt><dd> Duplicate Confirmation</dd>
	 <dt>DAD:</dt><dd>Duplicate Address Detection </dd>
       <dt>DAO</dt><dd> Destination Detection</dd>
	 <dt>DAO:</dt><dd>Destination Advertisement Object </dd>
       <dt>DAR</dt><dd> Duplicate Object</dd>
	 <dt>DAR:</dt><dd>Duplicate Address Request</dd>
       <dt>DIO</dt><dd> DODAG
	 <dt>DIO:</dt><dd>DODAG Information Object </dd>
       <dt>DMB</dt><dd> Direct Object</dd>
	 <dt>DMB:</dt><dd>Direct MAC Broadcast </dd>
       <dt>DODAG</dt><dd> Destination-Oriented Broadcast</dd>
	 <dt>DODAG:</dt><dd>Destination-Oriented Directed Acyclic Graph </dd>
       <dt>EARO</dt><dd> Extended Graph</dd>
	 <dt>EARO:</dt><dd>Extended Address Registration Option</dd>
       <dt>EDAC</dt><dd> Extended
	 <dt>EDAC:</dt><dd>Extended Duplicate Address Confirmation  </dd>
       <dt>EDAR</dt><dd> Extended Confirmation</dd>
	 <dt>EDAR:</dt><dd>Extended Duplicate Address Request</dd>
       <dt>IR</dt><dd> Ingress Replication </dd>
       <dt>LLN</dt><dd> Low-Power
	 <dt>IR:</dt><dd>Ingress Replication</dd>
	 <dt>LLN:</dt><dd>Low-Power and Lossy Network </dd>
       <dt>MOP</dt><dd>  Mode Network</dd>
	 <dt>MLD:</dt><dd>Multicast Listener Discovery</dd>
	 <dt>MOP:</dt><dd>Mode of Operation </dd>
       <dt>NA</dt><dd>  Neighbor Advertisement </dd>
       <dt>NCE</dt><dd>  Neighbor
	 <dt>NA:</dt><dd>Neighbor Advertisement</dd>
	 <dt>NCE:</dt><dd>Neighbor Cache Entry  </dd>
       <dt>ND</dt><dd>  Neighbor Discovery  </dd>
       <dt>NS</dt><dd>  Neighbor Solicitation  </dd>
       <dt>RA</dt><dd>  Router Advertisement  </dd>
       <dt>ROVR</dt><dd> Registration Entry</dd>
	 <dt>ND:</dt><dd>Neighbor Discovery</dd>
	 <dt>NS:</dt><dd>Neighbor Solicitation</dd>
	 <dt>RA:</dt><dd>Router Advertisement</dd>
	 <dt>RAN:</dt><dd>RPL-Aware Node</dd>
	 <dt>ROVR:</dt><dd>Registration Ownership Verifier, pronounced "rover" </dd>
       <dt>RPL</dt><dd> Routing Verifier (pronounced "rover")</dd>
	 <dt>RPL:</dt><dd>Routing Protocol for Low-Power and Lossy Networks, pronounced "ripple" </dd>
       <dt>RS</dt><dd>  Router Solicitation  </dd>
       <dt>RTO</dt><dd> RPL Networks (pronounced "ripple")</dd>
	 <dt>RS:</dt><dd>Router Solicitation</dd>
	 <dt>RTO:</dt><dd>RPL Target Option </dd>
       <dt>TID</dt><dd> Transaction ID </dd>
       <dt>TIO</dt><dd> Transit Option</dd>
	 <dt>RUL:</dt><dd>RPL-Unaware Leaf</dd>
	 <dt>TID:</dt><dd>Transaction ID</dd>
	 <dt>TIO:</dt><dd>Transit Information Option </dd> Option</dd>
       </dl>
  </section>	<!-- end section "Glossary" -->

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

    <t> This anchor="terms">
    <name>New Terms</name>
    <t>This document introduces the following terms:</t>

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

       <dt>Origin</dt><dd> The spacing="normal">
      <dt>Origin:</dt>
      <dd>The node that issued an anycast or multicast
      advertisement, either in the form of either an NS(EARO) or as a DAO(TIO,
      RTO) </dd>
       <dt>Merge/merging</dt><dd> The message.</dd>
      <dt>Merge/merging:</dt>
      <dd>The action of receiving multiple anycast or multicast
      advertisements, either internally from self, in the form of an NS(EARO),
      NS(EARO) message, or as a DAO(TIO, RTO), RTO) message, and generating a single DAO(TIO,
      RTO).  The RPL router maintains a state per origin for each
      advertised address, address and merges the advertisements for all
      subscriptions for the same address in a single advertisement.  A RPL
      router that merges multicast advertisements from different origins
      becomes the origin of the merged advertisement and uses its own
      values for the Path Sequence and Registration Ownership Verifier (ROVR) fields.
       </dd>
       <dt>Subscribe/subscription</dt><dd> The fields.</dd>
      <dt>Subscribe/subscription:</dt>
      <dd>The special form of registration that leverages NS(EARO) to
      register (subscribe (or subscribe to) a multicast or an anycast address.
       </dd> address.</dd>
    </dl>
  </section> <!--	 end section "New terms" -->
</section>	<!-- end section "Terminology" -->

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

<section anchor="overview"><name>Overview</name>
   <t>
   This anchor="overview">
  <name>Overview</name>

   <t>This specification Extends <xref target="RFC8505"/> and inherits from
   <xref target="RFC8928"/> to provide a registration method - called
   subscription (called "subscription" in this case - case) for anycast and multicast address. addresses. The specification inherits the proof of ownership defined in <xref target="RFC8928"/> that already protects the address registration in <xref target="RFC8505"/> to also protect the new subscription mechanism. <xref target="RFC8505"/> is agnostic to the routing protocol in which the address may be redistributed.
   </t>
<t>

As redistributed.</t>

<t>As opposed to unicast addresses, there might be multiple registrations
   from multiple parties for the same address. The router retains one
   registration per party per for each multicast or anycast address, address but injects the
   route into the routing protocol only once for each address, address. The injection
   happens asynchronously to the registration. On the other hand, the validation
   exchange with the
   registrar (6LBR) is still needed if the router checks the right for the
   host to listen to the anycast or multicast address.
</t>

 <t>
    <xref address.</t>

   <t><xref target="figSub"/> depicts the registration of an anycast or a
   multicast address.  As shown, the 6LBR receives and accepts multiple Extended DAR
   EDAR messages for the same address, and the address being
   registered by multiple nodes is not treated as a duplication.
    </t> duplication.</t>

<figure anchor='figSub'><name> Registration anchor='figSub'>
  <name>Registration Flow for an anycast Anycast or multicast Multicast Address</name>

  <artwork><![CDATA[
    6LoWPAN Node           6LR             6LBR
      (host1)           (router)        (registrar)
         |                  |               |
         |   DMB link       |               |
         |                  |               |
         |  ND-Classic RS   |               |
         |----------------->|               |
         |------------>     |               |
         |------------------------>         |
         |  ND-Classic RA   |               |
         |<-----------------|               |
         |                  |               |
         |  NS(EARO)        |               |
         |----------------->|               |
         |                  | Extended DAR     EDAR      |
         |                  |-------------->|
         |                  |               |
         |                  | Extended DAC     EDAC      |
         |                  |<--------------|
         |        NA(EARO)  |
         |<-----------------|<inject route> ->
         |                  |
                   ...
      (host2)           (router)           6LBR
         |  NS(EARO)        |               |
         |----------------->|               |
         |                  |               |
         |                  | Extended DAR     EDAR      |
         |                  |-------------->|
         |                  |               |
         |                  | Extended DAC     EDAC      |
         |                  |<--------------|
         |        NA(EARO)  |               |
         |<-----------------|               |
                   ...
      (host1)           (router)
         |  NS(EARO)        |               |
         |----------------->|               |
         |                  |               |
         |        NA(EARO)  |               |
         |<-----------------|               |
                   ...
         |                  |<maintain route> ->
                   ...
]]></artwork>
</figure>

   <t>In classical networks, <xref target="RFC8505"/> may be used for an ND
   proxy operation as specified in <xref target="RFC8929"/>, target="RFC8929"/> or redistributed
   in a full-fledged routing protocol such as what might be done in BGP for
   Ethernet VPN <xref target="I-D.thubert-bess-secure-evpn-mac-signaling"/> or
   in the Routing In in Fat Trees (RIFT) protocol <xref
   target="I-D.ietf-rift-rift"/>. The device mobility can be gracefully
   supported as long as the routers can exchange and make sense of the
   sequence counter in the TID field of the EARO.
   </t>
   <t> In EARO.</t>

<t>In the case of LLNs, RPL <xref target="RFC6550"/> is the routing
   protocol of choice and <xref target="RFC9010"/> specifies how the unicast
   address advertised with <xref target="RFC8505"/> is redistributed in
   RPL. This specification also provides RPL extensions for anycast and
   multicast address operation and redistribution. In the RPL case case, and unless
   specified otherwise, the behavior of is the same as it is for unicast for the 6LBR that acts as RPL Root, of the intermediate routers
   down Down the RPL graph, of the 6LR 6LRs that act as access routers
   routers, and of the 6LNs that are the RPL-unaware destinations, is the same as for unicast. destinations. In particular, forwarding a packet happens as specified in section 11 of
   <xref target="RFC6550"/>, target="RFC6550" sectionFormat="of" section="11"/>, including loop
   avoidance and detection, though in the case of multicast case, multiple copies
   might be generated.
   </t> 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 modifies existing options and
   updates the associated behaviors to enable the Registration registration for Multicast Addresses multicast
   addresses as an extension to <xref target="RFC8505"/>.  As with the registration
   of a unicast address registration,
   address, the subscription to anycast and multicast addresses
   between a node and its router(s) is agnostic (meaning, independent, unaware of)
   to (meaning it is independent) from the routing protocol in which this information may be
   redistributed or aggregated by the router to other routers, though routers. However, protocol
   extensions would be needed in the protocol when multicast services are not available.
   </t>
   <t>
   This
   available.</t>

   <t>This specification also Extends <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 (IR) in
   Non-Storing Mode mode and anycast support in both Storing and Non-Storing modes. modes in the case of a route-over multilink subnet based
   on the RPL routing protocol.
   A 6LR that implements the RPL extensions specified herein MUST <bcp14>MUST</bcp14> also
   implement <xref target="RFC9010"/>.
   </t>
    <t>
    <xref target="RFC9010"/>.</t>

   <t><xref target="figref"/> illustrates the classical situation typical scenario of an LLN as
   a single IPv6 Subnet, subnet, with a 6LoWPAN Border Router (6LBR) 6LBR that acts as Root
   for RPL operations and maintains a registry of the active registrations as
   an abstract data structure called an Address Registrar "Address Registrar" for 6LoWPAN ND.
    </t>

    <t>
	The ND.</t>

    <t>The LLN may be a hub-and-spoke access link such as (Low-Power) Wi-Fi
    <xref target="IEEE80211"/> and (Low-Energy) Bluetooth (Low Energy) <xref target="IEEE802151"/>,
    target="IEEE802151"/> or a Route-Over LLN such as the Wi-SUN <xref
    target="I-D.heile-lpwan-wisun-overview"/> and 6TiSCH IPv6 over the TSCH mode of IEEE 802.15.4 (6TiSCH) <xref
    target="RFC9030"/> meshes that leverages leverage 6LoWPAN <xref target="RFC4919"/>
    <xref target="RFC6282"/> and RPL <xref target="RFC6550"/> over IEEE 802.15.4 <xref target="IEEE802154"/>.
    </t>
    target="IEEE802154"/>.</t>

    <figure anchor="figref" align="center"><name>Wireless Mesh</name>
    <artwork><![CDATA[
                  |
      ----+-------+------------
          |     Wire side
       +------+
       | 6LBR |
       |(Root)|
       +------+
       o  o  o  Wireless side
   o   o o   o  o o
  o  o  o o   o  o  o
 o  o  o   LLN  o   +---+
   o  o   o  o   o  |6LR|
   o o  o o   o     +---+
    o   o   o o o  o    z
   o  o oo o  o        +---+
          o            |6LN|
                       +---+
]]></artwork></figure>

   <t>
   A

   <t>A leaf acting as a 6LN registers its unicast addresses to a RPL
   router acting as a 6LR, 6LR using a layer-2 Layer 2 unicast NS message with an EARO as
   specified in <xref target="RFC8505"/>.
   The registration state is periodically renewed by the Registering Node, Node
   before the lifetime indicated in the EARO expires. As for unicast IPv6
   addresses, the 6LR uses an EDAR/EDAC EDAR and then an EDAC exchange with the 6LBR to notify the
   6LBR of the presence of the listeners.
   </t><t>
   This listeners.</t>

   <t>This specification updates the EARO with a new two-bit 2-bit field, the P-Field,
   as detailed in <xref target="R8505E"/>.  The existing R flag that requests
   reachability for the registered address Registered Address gets new behavior.  With this extension
   extension, the 6LNs can now subscribe to the anycast and multicast addresses
   they listen to, using a new P-Field in the EARO to signal that the
   registration is for a multicast address. Multiple 6LNs may subscribe the
   same multicast address to the same 6LR. Note the use of the term
   "subscribe": this means that when using the EARO registration mechanism, a node registers the
   unicast addresses that it owns, owns but subscribes to the multicast addresses
   that it listens to.
   </t><t>
   With to.</t>

   <t>With this specification, the 6LNs can also subscribe the anycast
   addresses they accept, accept using a new P-Field in the EARO to signal that the
   registration is for an anycast address. As for multicast, For multicast addresses, multiple 6LNs may
   subscribe the same anycast address to the same 6LR.
   </t><t>
   If 6LR.</t>

   <t>If the R flag is set in the subscription of one or more 6LNs for the
   same address, the 6LR injects the anycast addresses and multicast addresses
   of a scope larger than the link-scope in RPL, based on the longest subscription
   lifetime across the active subscriptions for the address.
   </t><t>
   In address.</t>

   <t>In the RPL "Storing Storing Mode of Operation with multicast support", support (<xref target="RFC6550" sectionFormat="of" section="12"/>), the DAO
   messages for the multicast address percolate along the RPL preferred RPL-preferred parent
   tree and mark a subtree that becomes the multicast tree for that multicast
   address, with 6LNs that subscribed to the address as the leaves.  As
   prescribed in section 12 of <xref target="RFC6550"/>, target="RFC6550" sectionFormat="of" section="12"/>, the 6LR forwards a
   multicast packet as an individual unicast MAC Medium Access Control (MAC) frame to each peer along the
   multicast tree, except to the node it received the packet from.
   </t><t>
   In from.</t>

   <t>In the new RPL "Non-Storing Non-Storing Mode of Operation with ingress replication multicast support" support
   that is introduced here, the DAO messages announce the multicast addresses
   as Targets
   though Targets, and never as Transit. Transits. The multicast distribution is an ingress replication
   IR whereby the Root encapsulates the multicast packets to
   all the 6LRs that are transit for the multicast address, using the same
   source-routing header as for unicast targets attached to the respective 6LRs.
   </t><t>
   LLN
   6LRs.</t>

   <t>LLN links are typically Direct MAC Broadcast (DMB)
   (more (see more in <xref
   target="I-D.ietf-6man-ipv6-over-wireless" />) with no emulation to increase
   range (over multiple radio hops) or reliability.  In such links,
   broadcasting is unreliable and asynchronous transmissions force a listener
   to remain awake, so asynchronous broadcasting is generally inefficient.
   The
   Thus, the expectation is thus that whenever possible, the 6LRs deliver the
   multicast packets as individual unicast MAC frames to each of the 6LNs that
   subscribed to the multicast address.  On the other hand, in a network where
   nodes do not sleep, asynchronous broadcasting may still help recovering
   faster when state is lost.
   </t><t>
   With lost.</t>

   <t>With this specification, anycast addresses can be injected in RPL in
   both Storing and Non-Storing modes. In Storing Mode mode, the RPL router accepts
   DAO messages from multiple children for the same anycast address, but it only forwards
   a packet to one of the children.  In Non-Storing Mode, mode, the Root maintains
   the list of all the RPL nodes that announced the anycast address as Target,
   but it forwards a given packet to only one of them.
   </t>

<t>
   Operationally them.</t>

   <t>Operationally speaking, deploying a new MOP means that one cannot update
   a live network. The network administrator must create a new instance with
   MOP 5 and migrate nodes to that instance by allowing them to join it.
   </t> it.</t>

   <t>For backward compatibility, this specification allows to build building a single
   DODAG signaled as MOP 1, 1 that conveys anycast, unicast, and multicast
   packets using the same source routing source-routing mechanism; see more in <xref target="deploy"/>.
   </t>
 <t>
   It
   target="deploy"/>.</t>

<t>It is also possible to leverage this specification between the 6LN and
   the 6LR for the registration of unicast, anycast anycast, and multicast IPv6
   addresses in networks that are not necessarily LLNs, LLNs and/or where the
   routing protocol between the 6LR and above its peer routers is not necessarily RPL. In that
   case, the distribution of packets between the 6LR and the 6LNs may
   effectively rely on a broadcast or multicast support at the lower layer, e.g., layer
   (e.g., using this specification as a replacement to MLD in an Ethernet bridged Ethernet-bridged domain and still using either a plain MAC-layer broadcast or snooping of
   this protocol to control the flooding. flooding). It may also rely on overlay services
   to optimize the impact of Broadcast, Unknown, and Multicast (BUM) traffic over a
   fabric, e.g. e.g., registering with <xref
   target="I-D.thubert-bess-secure-evpn-mac-signaling"/> and forwarding with
   <xref target="I-D.ietf-bess-evpn-optimized-ir"/>. </t>
 <t>
   For target="RFC9574"/>.</t>

   <t>For instance, it is possible to operate a RPL Instance in the new
   "Non-Storing
   Non-Storing Mode of Operation with ingress replication multicast support" support (while possibly
   signaling a MOP of 1) and use <xref target="RFC7731">"Multicast "Multicast Protocol for Low-Power and Lossy
   Networks (MPL)"</xref> (MPL)" <xref target="RFC7731"/> for the multicast operation.  MPL
   floods the DODAG with the multicast messages independently of the RPL DODAG
   topologies. Two variations are possible:
</t> possible:</t>

   <ul>
<li>
   In
     <li>In one possible variation, all the 6LNs set the R flag in the EARO
     for a multicast target, upon which the 6LRs send a unicast DAO message to
     the Root; the Root filters out the multicast messages for which there is
     no listener and only floods when there is.
</li>
<li>
   In a listener exists.</li>

<li>In a simpler variation, the 6LNs do not set the R flag and the Root
     floods all the multicast packets over the whole DODAG. Using configuration, a
     configuration mechanism, it is also possible to control the behavior of the 6LR to
     ignore the R flag and flag. It can be configured to either always or never send the DAO message, message and/or to control the Root and specify which groups it should flood or not flood.

</li>
     flood.</li>
   </ul>
 <t>
   Note

   <t>Note that if the configuration instructs the 6LR not to send the DAO, DAO message,
   then MPL can really by be used in conjunction with the RPL Storing Mode mode as well.
 </t>
   well.</t>

</section> <!-- end section "Overview" -->

<!-- Target Address is not a multicast address. -->
   <section anchor="tgt4861"><name>Updating anchor="tgt4861"><name>Amending RFC 4861</name>
   <t>
   Section 7.1 of <xref target="RFC4861"/>

   <t><xref target="RFC4861" sectionFormat="of" section="7.1"/> requires to silently discard discarding NS and NA packets when the Target Address is a multicast
   address. This specification Amends <xref target="RFC4861"/> by allowing to advertise the advertisement of multicast and anycast addresses in the Target Address field when
   the NS message is used for a registration, per section 5.5 of <xref target="RFC8505"/>.
    </t>
    </section ><!-- Updating RFC 4861 --> target="RFC8505"
   sectionFormat="of" section="5.5"/>.</t>
    </section>

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

    <t>
   This
    <t>This specification Extends <xref target="RFC7400"> "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks
   (6LoWPANs)"</xref> (6LoWPANs)" <xref target="RFC7400"/> by defining a new capability bit for use in
    the 6CIO.  <xref target="RFC7400"/> was already extended by <xref
    target="RFC8505"/> for use in IPv6 ND messages.
    </t>
    <t>
   The messages.</t>

    <t>The new "Registration for xcast Address Unicast, Multicast, and Anycast
      Addresses Supported" (X) X flag indicates
    to the 6LN that the 6LR accepts unicast, multicast, and anycast address
    registrations as specified in this document and will ensure that packets
    for the Registered Address will be routed to the 6LNs that registered with
    the R flag set appropriately.
    </t>
    <t>
   <xref appropriately.</t>

    <t><xref target="fig6CIO"/> illustrates the X flag in its suggested
    position (8, counting 0 to 15 in network order in the 16-bit array), to be confirmed by IANA.
   </t> array); see
    <xref target="New_Cap_Bits"/> for the IANA registration of capability bits.</t>

   <figure anchor="fig6CIO"><name>New Capability Bits in the 6CIO</name>
   <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  |    Reserved   |X|A|D|L|B|P|E|G|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
    </figure>

    <t> New

    <t>New Option Field:    </t> Field:</t>
	<dl>
	<dt>X</dt><dd>
	  <dt>X:</dt>
	  <dd>This is a 1-bit flag: flag for "Registration for Unicast, Multicast, and Anycast
	  Addresses Supported" </dd> Supported".</dd>
	</dl>
    </section>	<!-- end section "Extending RFC 7400" -->

   <section anchor="coex"><name>Updating anchor="coex">
     <name>Amending RFC 6550</name>
<t>
   This

   <t>This specification Amends <xref target="RFC6550"/> to mandate the use of
   the ROVR field as the indication of the origin of a Target advertisement in the
   RPL DAO messages, as specified as an option in section 6.1 of <xref target="RFC9010"/>.

</t><t>
   This
   target="RFC9010" sectionFormat="of" section="6.1"/>.</t>

   <t>This specification Extends <xref target="RFC6550"/> with a new P-Field in the RPL Target Option.
</t><t>
   The Option (RTO).</t>

   <t>The specification also Amends the behaviors of the Modes of Operation
   MOP 1 and MOP 3, 3 and Extends <xref target="RFC6550"/> with a new MOP 5.

</t> 5.</t>

   <section anchor="mrovr"><name>Mandating anchor="mrovr">
     <name>Mandating the ROVR field</name>
<t>

   For Field</name>

   <t>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 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 recognised recognized across multiple hops.

</t><t>
   <xref hops.</t>

   <t><xref target="RFC6550"/> uses the Path Sequence in the Transit
   Information Option (TIO) to retain only the freshest unicast route and
   remove the stale ones, e.g., in the case of mobility. <xref target="RFC9010"/>
   copies the TID Transaction ID (TID) from the EARO into the Path Sequence, Sequence and the ROVR field
   into the associated RPL
   Target Option (RTO). RTO.  This way, it is possible to
   identify both the registering node 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>
   This used.</t>

<t>This specification Extends <xref target="RFC6550"/> to require that, for anycast and
   multicast advertisements, advertisements to require that the Path Sequence is be used
   between
   between, and only between between, advertisements for the same Target and from the
   same origin (i.e, (i.e., with the same ROVR value); in value). In that case, only the
   freshest advertisement is retained. But retained, but the freshness comparison cannot
   apply if the origin is not determined (i.e., the origin did not support
   this specification).
</t><t>
   <xref 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>
   The received.</t>

<t>The RPL router that merges multiple advertisements for the same anycast
   or multicast addresses MUST <bcp14>MUST</bcp14> use and advertise the longest
   remaining lifetime across all the origins of the advertisements for that
   address.  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,
   that is
   advertisements. This value refers to either self or the single descendant that
   advertised the Target.
</t><t>

   Note Target if there is only one or the router itself if there is more than one.</t>

   <t>Note that the Registration Lifetime, TID TID, and ROVR fields are also placed
   in the EDAR message so the state created by the 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><!--Mandating the ROVR field--> EDAR.</t>

</section>

<section anchor="mop3"><name>Updating MOP 3</name>
<t>
   RPL

   <t>RPL supports multicast operations in the "Storing Storing Mode of Operation with
   multicast support" support (MOP 3) 3), which provides source-independent multicast
   routing in RPL, as prescribed in section 12 of <xref target="RFC6550"/>. target="RFC6550" sectionFormat="of" section="12"/>.
   MOP 3 is a storing Storing Mode of Operation. This operation builds a multicast
   tree within the RPL DODAG for each multicast address. This specification
   provides additional details for the MOP 3 operation.
</t> <t>
   The 3.</t>

   <t>The expectation in MOP 3 is that the unicast traffic also follows the
   Storing Mode of Operation. But However, this is rarely the case in LLN deployments
   of RPL where the "Non-Storing Non-Storing Mode of Operation" Operation (MOP 1) is the norm.
   Though it is preferred to build separate RPL Instances, one in MOP 1 and
   one in MOP 3, this specification allows hybrid use of the Storing Mode mode for
   multicast and the Non-Storing Mode mode for unicast in the same RPL Instance, as is
   elaborated in more detail in <xref target="deploy"/>.
</t><t>
   For target="deploy"/>.</t>

   <t>For anycast and multicast advertisements, including MOP 3, the ROVR
   field is placed in the RPL Target Option RTO as specified in <xref target=
   "RFC9010"/>
   target="RFC9010"/> for both MOP 3 and MOP 5 as it is for unicast advertisements.
</t> <t>
   Though
   advertisements.</t>

   <t>Though it was implicit with <xref target="RFC6550"/>, this specification
   clarifies that the freshness comparison based on the Path Sequence is not
   used when the origin cannot be determined, which is occurs in the case there. of multiple subscriptions of a multicast or unicast address.  The
   comparison is to be used only between advertisements from the same origin,
   which is either an individual subscriber, subscriber or a descendant that merged
   multiple advertisements.
</t> <t>
   A advertisements.</t>

   <t>A RPL router maintains a remaining Path Lifetime for each DAO message that it
   receives for a multicast target, target and sends its own DAO message for that target with
   the longest remaining lifetime across its listening children. If the router
   has only one descendant listening, it propagates the TID and ROVR as
   received. Conversely, if the router merges multiple advertisements
   (including possibly
   (possibly including one for itself as a listener), the router uses its own
   ROVR and TID values. This implies a possible transition of ROVR and TID
   values when the number of listening children changes from one to more or
   back to one, which should not be considered as an error or a change of
   ownership by the parents above.

</t> above.</t>
  </section>	<!-- end section "Updating MOP 3" -->

<section anchor="mop5"><name>New Non-Storing Multicast MOP</name>
<t>
   This
<t>This specification adds a "Non-Storing Non-Storing Mode of Operation with ingress
replication multicast support" (MOP to be support RPL (as assigned by IANA) IANA; see <xref target="RPL_Mode_Op"/>) whereby the
   non-storing
Non-Storing Mode DAO to the Root may advertise a multicast address in the RPL Target Option (RTO), RTO, whereas the Transit Information Option (TIO) cannot.

</t> <t>
   In TIO cannot.</t>

<t>In that mode, the RPL Root performs an ingress replication (IR) IR operation
on the multicast packets, meaning packets. This means that it transmits one copy of each multicast
packet to each 6LR that is a transit for the multicast target, using the same
   source routing
source-routing header and encapsulation as it would for a unicast packet for a RPL Unaware
RPL-Unaware Leaf (RUL) attached to that 6LR.
</t> <t>
   For 6LR.</t>

<t>For the intermediate routers, the packet appears as any source routed source-routed
unicast packet. The difference shows only at the 6LR, that which terminates the source
   routed
source-routed path and forwards the multicast packet to all 6LNs that
registered for the multicast address.
</t> <t>
   For address.</t>

<t>For a packet that is generated by the Root, this means that the Root builds
a
   source routing source-routing header as shown in section 8.1.3 of <xref target="RFC9008"/>, target="RFC9008" sectionFormat="of"
section="8.1.3"/>, but for which the last and only the last address is
multicast.  For a packet that is not generated by the Root, the Root
encapsulates the multicast packet as per section 8.2.4 of <xref target="RFC9008"/>. target="RFC9008"
sectionFormat="of" section="8.2.4"/>. In that case, the outer header is purely
unicast, and the encapsulated packet is purely multicast.
</t><t>
   For multicast.</t>

<t>For anycast and multicast advertisements in NA messages (at the 6LR) and DAO messages (at the Root) messages,
Root), as discussed in <xref target="mop3"/>, the freshness
comparison based on the TID field is applied only between messages from the
same origin, as determined by the same value in the ROVR field.
</t><t>
   The field.</t>

<t>The Root maintains a remaining Path Lifetime for each advertisement it
receives, and the 6LRs generate a 6LR generates the DAO message for multicast addresses with the
longest remaining lifetime across its registered 6LNs, using its own ROVR and
TID when multiple 6LNs subscribed, have subscribed or if this when the 6LR is one of the subscribers.
</t> <t>
   For this new mode as well, this a subscriber.</t>

<t>This specification allows to enable enabling the
operation in a MOP 1 brown field, field for this new mode as well; see more in <xref target="deploy"/>.
</t> target="deploy"/>.</t>
</section>	<!-- end section "New Non-Storing Multicast MOP" -->

<section anchor="anic"><name>RPL Anycast Operation</name>
<t>
   With
<t>With multicast, the address has a recognizable format, and a multicast
   packet is to be delivered to all the active subscribers.  In contrast, the
   format of an anycast address is not distinguishable from that of unicast. a unicast address. A
   legacy node may issue a DAO message without setting the P-Field to 2, 2; the
   unicast behavior may apply to anycast traffic within a portion of the
   network, but the packets will still be delivered.  That message will be
   undistinguishable from a unicast advertisement advertisement, and the anycast behavior in
   the dataplane data plane can only happen if all the nodes that advertise the same
   anycast address are synchronized with the same TID. That way, the multiple
   paths can remain in the RPL DODAG.
</t> <t>
   With DODAG.</t>

   <t>With the P-Field set to 2, this specification alleviates the issue of
   synchronizing the TIDs and ROVR fields. As for multicast, the freshness
   comparison based on the TID (in the EARO) and the Path Sequence (in the TIO) is
   ignored unless the messages have the same origin, as origin; this is inferred by the same
   ROVR in the RTO and/or the EARO, and the latest value of the lifetime is retained
   for each origin.
   </t>
   <t>
   A origin.</t>

   <t>A RPL router that propagates an advertisement from a single origin uses the
   ROVR and Path Sequence from that origin, whereas a router that merges
   multiple subscriptions uses its own ROVR and Path Sequence and the longest
   lifetime over the different advertisements.  A target is routed as anycast
   by a parent (or the Root) that received at least one DAO message for that
   target with the P-Field set to 2.
</t> <t>
   As 2.</t>

<t>As opposed to multicast, the anycast operation described therein herein applies
   to both addresses and prefixes, and the P-Field can be set to 2 for both.
   An external destination (address (such as an address or prefix) that may be injected as a RPL
   target
   Target from multiple border routers should be injected as anycast in RPL to
   enable load balancing. A In contrast, a mobile target that is multihomed should in contrast
   be advertised as unicast over the multiple interfaces to favor the
   TID comparison and vs. the instead of multipath load balancing.
</t> <t>
   For balancing.</t>

   <t>For either multicast and or anycast, there can be multiple subscriptions
   from multiple origins, each using a different value of the ROVR field that
   identifies the individual subscription.

   The 6LR maintains a subscription
   state per value of the ROVR per for each multicast or anycast address, but it injects
   the route into RPL only once for each address, and in address. In the case of a
   multicast address, this occurs only if its scope is larger than the link-scope (3 (three or more).
   Since the subscriptions are considered separate, the check on the TID that
   acts as the subscription sequence only applies to the subscription with the
   same ROVR.
</t>  <t>
   Like ROVR.</t>

   <t>Like the 6LR, a RPL router in Storing Mode mode propagates the merged
   advertisement to its parent(s) in DAO messages once and only once for each
   address, but it retains a routing table entry for each of the children that
   advertised the address.
</t> <t>
   When address.</t>

   <t>When forwarding multicast packets down Down the DODAG, the RPL router copies
   all the children that advertised the address in their DAO messages. In
   contrast, when forwarding anycast packets down Down the DODAG, the RPL router
   MUST
   <bcp14>MUST</bcp14> copy one and only one of the children that advertised
   the address in their DAO messages, messages and forward it to one parent if there is no
   such child.
</t> child.</t>
  </section>	<!-- end section "RPL Anycast Operation" -->

<section anchor="newpf"><name>New anchor="newpf">
  <name>New Registered Address Type Indicator P-Field</name>
<t> The

  <t>The new Registered Address Type Indicator (RATInd) is created for use in RPL
    Target Option, the
  RTO, the EARO, and the header of EDAR messages.  The RATInd
  indicates whether an address is unicast, multicast, or anycast.  The new
  2-bit P-Field is defined to transport the RATInd in different
    protocols.
</t>
<t>
    The protocols.</t>

<t>The P-Field can take the following values:
</t> values shown in <xref target="AM2"/>.</t>

<!-- Note: deleted Table 1 (pointing to Table 3 instead).

 <table anchor="pVALS" ><name>P-Field anchor="pVALS"><name>P-Field Values</name>
     <thead>
      <tr><td>P-Field Value</td><td>Registered
      <tr>
	<td>Value</td>
	<td>Registered Address Type</td></tr>
     </thead><tbody> Type Indicator</td>
      </tr>
     </thead>
     <tbody>
      <tr><td>0</td><td>Registration for a Unicast Address or prefix</td></tr> Address</td></tr>
      <tr><td>1</td><td>Registration for a Multicast Address</td></tr>
      <tr><td>2</td><td>Registration for an Anycast Address</td></tr>
      <tr><td>3</td><td>Reserved, MUST NOT
      <tr><td>3</td><td>Reserved; <bcp14>MUST NOT</bcp14> be used by the sender.</td></tr> sender</td></tr>
     </tbody>
 </table>  <!-- end table "P-Field values"
-->

	 <t>
	 The

	 <t>The intent for the value of 3 is a prefix registration (see <xref target="I-D.ietf-6lo-prefix-registration"/>,
	 target="I-D.ietf-6lo-prefix-registration"/>), which is expected to be
	 published soon after this specification. At the time of this writing,
	 RPL already advertises prefixes, and treated treats unicast addresses as prefgixes
	 prefixes with a length of 128, so it does not really need that new
	 value. On the other hand, 6LoWPAN ND does not, and so the value of 3 meaning
	 (meaning prefix registration registration) will not be processed adequately. As a result:
	 </t>
	 result:</t>

	 <ul>
	 <li>
	 When
	   <li>When the value of 3 is received in an RTO (see <xref
	   target="newrtoflg"/>), this value MUST <bcp14>MUST</bcp14> be ignored by
	   the receiver, meaning, receiver (meaning it is treated as a value of 0, 0) but the message is
	   processed normally (as per <xref target="RFC6550"/> and <xref target="RFC9010"/>).
	 </li>
	 <li>
	 In
	   target="RFC9010"/>).</li>
	   <li>In the case of an EARO (see <xref target="R8505E"/>) or an EDAR
	   (see <xref target="R8505D"/>), the message MUST <bcp14>MUST</bcp14> be
	   dropped, and the receiving node MAY <bcp14>MAY</bcp14> either reply
	   with a status of 12 "Invalid Registration" or remain silent.
	 </li> silent.</li>
	 </ul>
</section><!-- New P-Field -->

</section>

<section anchor="newrtoflg"><name>New RPL Target Option P-Field</name>
<t>
   <xref

<t><xref target="RFC6550"/> recognizes a multicast address by its format (as
specified in section 2.7 of <xref target="RFC4291"/>) target="RFC4291" sectionFormat="of" section="2.7"/>) and
applies the specified multicast operation if the address is recognized as
multicast.  This specification updates <xref target="RFC6550"/> to add the
2-bit P-Field (see <xref target="newpf"/>) to the RTO to indicate that the target address
Target Address is to be processed as unicast, multicast multicast, or anycast.
</t> anycast.</t>

   <ul>
     <li>An RTO that has the P-Field set to 0 is called a unicast RTO.</li>
     <li>An RTO that has the P-Field set to 1 is called a multicast RTO.</li>
     <li>An RTO that has the P-Field set to 2 is called an anycast RTO.</li>
   </ul> <t>
   The

<t>The suggested position for the P-Field is 2 counting from 0 to 7 in network
order as shown in <xref target="rto-fmt"/>, based on figure Figure 4 of <xref target="RFC9010"/>
target="RFC9010"/>, which defines the flags in position positions 0 and 1:
</t> 1:</t>

<figure anchor="rto-fmt"><name>Format anchor="rto-fmt">
  <name>Format of the RPL Target Option</name> Option (RTO)</name>
<artwork align="center">
   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 = 0x05 | Option Length |F|X| P |ROVRsz | Prefix Length |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                Target Prefix (Variable Length)                |
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
 ...            Registration Ownership Verifier (ROVR)           ...
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
    <t> New

    <t>New and updated Option Fields:    </t> Field:</t>
	<dl>
	<dt>P:</dt><dd>2-bit
	  <dt>P:</dt>
	  <dd>This is a 2-bit field; see <xref target="newpf"/></dd> target="newpf"/>.</dd>
	</dl>
</section>	<!-- end section "New RPL Target Option Flags" -->
</section>	<!-- end section "Updating RFC 6550" -->

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

<t>
   This

<t>This specification Extends <xref target="RFC8505"/> by adding the concept
of a subscription for anycast and multicast addresses and creating a new field
called the P-Field in the EARO and in the EDAR/EDAC EDAR and EDAC messages ti to signal the type
of registration.
</t> registration.</t>

<section anchor="R8505E"><name>Placing anchor="R8505E">
  <name>Placing the New P-Field in the EARO</name>

<t>
   Section 4.1 of <xref target="RFC8505"/>

<t><xref target="RFC8505" sectionFormat="of" section="4.1"/> defines the EARO
as an extension to the ARO option defined in <xref target="RFC6775"/>.  This
specification adds a new P-Field that is placed in the EARO flags that and is set as
   follows:

</t>
follows:</t>

<ul>
<li>
   The
  <li>The P-Field is set to 1 to signal that the Registered Address is a
  multicast address. When the P-Field is 1 and the R flag is set to 1 as well,
  the 6LR that conforms to this specification joins the multicast stream,  e.g., stream
  (e.g., by injecting the address in the RPL multicast support that is extended
  in this specification for the Non-Storing Mode.
</li>
<li>
   The mode).</li>
  <li>The P-Field is set to 2 to signal that the Registered Address is an
  anycast address. When the P-Field is 2 and the R flag is 1, the 6LR that
  conforms to this specification injects the anycast address in the routing
  protocol(s) that it participates to, e.g., in (e.g., in the RPL anycast support that
  is introduced in this specification for both the Storing and Non-Storing Modes.
</li>
  modes).</li>
</ul>
<t>
   <xref
<t><xref target="EARO"/> illustrates the P-Field in its suggested
   positions position
(2, counting 0 to 7 in network order in the 8-bit array), to be confirmed by IANA.
</t> array); see <xref target="PF"/> for the IANA registration of P-Field values.</t>

 <figure anchor="EARO"><name>EARO anchor="EARO"><name>Extended Address Registration Option (EARO) Format</name>
 <artwork align="center">
   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    |    Status     |    Opaque     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Rsv| P | I |R|T|     TID       |     Registration Lifetime     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
 ...          Registration Ownership Verifier (ROVR)              ...
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
 </figure><!-- end figure "EARO Option Format" -->

    <t> New
 </figure>

    <t>New and updated Option Fields:    </t> Fields:</t>
	<dl>
	<dt>Rsv:</dt><dd>
	  <dt>Rsv:</dt>
	  <dd>This is a 2-bit field; reserved, MUST field. It is reserved and <bcp14>MUST</bcp14> be
	  set to 0 and ignored by the receiver</dd>
	<dt>P:</dt><dd>2-bit receiver.</dd>
	  <dt>P:</dt>
	  <dd>This is a 2-bit P-Field; see <xref target="newpf"/></dd> target="newpf"/>.</dd>
	</dl>

</section> <!-- end section "Placing the New P-Field in the EARO" -->
<section anchor="R8505D"><name>Placing anchor="R8505D">
  <name>Placing the New P-Field in the EDAR Message</name>

<t>
   Section 4 of <xref target="RFC6775"/>

  <t><xref target="RFC6775" sectionFormat="of" section="4"/> provides the same
  format for DAR and DAC messages but the status Status field is only used in DAC
  messages and has to be set to zero 0 in DAR messages. <xref target="RFC8505"/>
  extends the DAC message as an EDAC but does not change the status Status field in
  the EDAR.

</t>
<t>
   This EDAR.</t>

  <t>This specification repurposes the status Status field in the EDAR as a Flags
  field.  It adds a new P-Field to the EDAR flags field to match the P-Field in
  the EARO and signal the new types of registration. The EDAC message is not
   modified.
</t>
<t>
   <xref
  modified.</t>

  <t><xref target="EDAR"/> illustrates the P-Field in its suggested position (0,
  counting 0 to 7 in network order in the 8-bit array), to be confirmed by
   IANA.
</t> array); see <xref target="EDAR_Message_Flags"/> for the IANA registration of EDAR message flags.</t>

 <figure anchor="EDAR"><name>Extended Duplicate Address Request (EDAR) Message Format</name>
 <artwork align="center">
  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 | Reserved  |     TID       |     Registration Lifetime     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
...            Registration Ownership Verifier (ROVR)           ...
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                                                               |
 +                       Registered Address                      +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
 </figure><!-- end figure "EDAR Message Format" -->

    <t> New
 </figure>

    <t>New and updated Option Fields:    </t> Fields:</t>
    <dl>
	<dt>Reserved</dt><dd>
	<dt>Reserved:</dt><dd>This is a 6-bit field: reserved, MUST field. It is reserved and <bcp14>MUST</bcp14> be set to 0 and ignored by the receiver</dd>
	<dt>P:</dt><dd>2-bit receiver.</dd>
	<dt>P:</dt><dd>This is a 2-bit field; see <xref target="newpf"/></dd> target="newpf"/>.</dd>
    </dl>
</section> <!-- end section "Placing the New P-Field in the EDAR Message" -->

<section anchor="multireg"><name>Registration anchor="multireg">
  <name>Registration Extensions</name>
<t>
   <xref

<t><xref target="RFC8505"/> specifies the following behaviours:
</t> behaviors:</t>

<ul>
   <li>
   A
   <li>A router that expects to reboot may send a final RA message, upon which
   nodes should subscribe elsewhere or redo the subscription 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 persisted, e.g., in persistent memory.
   </li>
   <li>
   The memory.</li>
   <li>The registration method is specified only for unicast addresses.
   </li>
   <li>
   The addresses.</li>
   <li>The 6LN must register all its ULA ULAs and GUA GUAs with an NS(EARO).
   </li>
   <li>
   The NS(EARO) message.</li>
   <li>The 6LN may set the R flag in the EARO to obtain return reachability
   services by the 6LR, e.g., through ND proxy operations, operations or by injecting the
   route in a route-over subnet.
   </li>
   <li>
   the subnet.</li>
   <li>the 6LR maintains a registration state per Registered Address, including an
   NCE with the Link Layer Link-Layer Address (LLA) of the Registered Node (the 6LN here).
   </li> here).</li>
</ul>

  <t>
   This

<t>This specification Amends une the above behavior behaviors and Extends it them with the
   following behavior:
  </t> behaviors:</t>
   <ul>
     <li>The concept of subscription is introduced for anycast and multicast
     addresses as an extension to the registration of a unicast address registration. address.  The
     respective operations are similar from the perspective of the 6LN, but
     they show important differences on the router side, which maintains a separate
     state for each origin and merges them in its own advertisements.
   </li> advertisements.</li>

     <li>
   <t>
   New
       <t>New ARO Statuses are introduced to indicate a "Registration Refresh
       Request" and an "Invalid Registration" (see <xref target="AROstat"/>).
   </t>
   <t>
   The
       target="AROstat"/>).</t>

       <t>The former status is used in asynchronous NA(EARO) messages to
       indicate to peer 6LNs that they are requested to reregister all
       addresses that were previously registered to the originating node. The
       NA message may be sent to a unicast or a multicast link-scope address
       and should be contained within the L2 range where nodes may effectively have registered/subscribed
       effectively registered or, respectively, subscribed to this router, e.g., router (e.g., a radio
       broadcast domain. domain). The latter is generic to any error in the EARO, EARO and
       is used
   e.g., used, for example, to report that the P-Field is not consistent with the
       Registered Address in NS(EARO) and EDAR messages.
   </t>
   <t>
   A messages.</t>

       <t>A router that wishes to refresh its state, e.g., state (e.g., upon reboot or in
       any situation where it may have missed a registration or lost a
       registration state, SHOULD state) <bcp14>SHOULD</bcp14> send an asynchronous NA(EARO)
       with this new status value. Failure to do so will delay the recovery of
       the network
   till until the next periodic registration by the attached 6LNs
       and packets may be lost till until then.  That asynchronous multicast
       NA(EARO) MUST <bcp14>MUST</bcp14> be sent to the all-nodes link
   scope link-scope
       multicast address (ff02::1) (ff02::1), and the Target MUST <bcp14>MUST</bcp14> be set to
       the link local link-local address that was exposed previously by this node to
       accept registrations.
   </t>
   <t>
   The registrations.</t>

       <t>The TID field in the multicast NA(EARO) message is the one associated to the
       Target and follows the same rules as the TID in the NS(EARO) message for the
       same
   Target, Target; see section 5.2 of <xref target="RFC8505"/>, target="RFC8505" sectionFormat="of"
       section="5.2"/>, which points at
   section 7.2 of to <xref target="RFC6550"/> target="RFC6550"
       sectionFormat="of" section="7.2"/> for the lollipop mechanism used in
       the TID operation. It is incremented by the sender each time it sends a
       new series of NS and/or NA messages with the EARO about the Target.  The TID
       indicates a reboot when it is in the "straight" part of the lollipop,
       between the initial value and 255. After that that, the TID remains below 128
       as long as the device is alive. An asynchronous multicast NA(EARO) with
       a TID below 128 MUST NOT <bcp14>MUST NOT</bcp14> be considered as indicating a reboot.

   </t>
   <!--
   In an unreliable environment, the asynchronous multicast NA(EARO) message MAY
   be resent in a fast sequence for reliability, in which case the TID MUST be
   incremented each time.

   The multicast NA(EARO) SHOULD be resent enough times for the TID to be issued
   with the value of 255 so the next NA(EARO) after the initial series is
   outside the lollipop and not confused with a reboot.
   A 6LN that has recently processed the multicast NA(EARO) indicating
   "Registration Refresh Request" ignores the next multicast NA(EARO) with
   the same status and a newer TID received within the duration of the initial
   series.
    -->
   <t>

   The
       reboot.</t>

     <t>The asynchronous multicast NA(EARO) indicating a "Registration Refresh
     Request"
   MAY <bcp14>MAY</bcp14> be reissued a few times within a short
     period, to increase the chances that the message is received by all
     registered nodes despite the unreliable transmissions within the LLN; the
     TID MUST <bcp14>MUST</bcp14> be incremented each time.  The receiver 6LN MUST
     <bcp14>MUST</bcp14> consider that multiple NA(EARO) messages indicating a
     "Registration Refresh Request" from the same 6LR received within that
     short period with comparable (their and increasing TID values (i.e., their absolute difference is less than SEQUENCE_WINDOW, the
     SEQUENCE_WINDOW; see section 7.2 of <xref target="RFC6550"/>) and increasing TID values target="RFC6550" sectionFormat="of"
     section="7.2"/>)  are in fact indicative of the same request; the request. The 6LN MUST <bcp14>MUST</bcp14> process one and only one of the
     series of messages. If the TIDs are desynchronized (not comparable), comparable) or
     decreased, then the NA(EARO) is considered as a new request and it MUST
     <bcp14>MUST</bcp14> be processed.

   </t>
   <t>
   The processed.</t>

     <t>The multicast NA(EARO) SHOULD <bcp14>SHOULD</bcp14> be resent enough times
     for the TID to be issued with the value of 255 so the next NA(EARO) after
     the initial series is outside the lollipop and is not confused with a
     reboot.  By default default, the TID initial setting after boot is 252, the
     SEQUENCE_WINDOW is 4, the duration of the short period is 10 seconds, the
     interval between retries is 1 second, and the number of retries is 3. To
     reach 255 at boot time, the sender MAY <bcp14>MAY</bcp14> either issue at
     least 4 NA messages, skip a TID value, or start with a value that is more
     than 252.  The best values for the short period, the number of retries,
     and the TID initial setting depend on the environment and SHOULD
     <bcp14>SHOULD</bcp14> be configurable.
   </t> configurable.</t>
   </li>

   <li>
   <t>
   A
     <t>A new IPv6 ND Consistent Uptime option Option (CUO) is introduced to be
     placed in IPv6 ND messages. The CUO allows to figure figuring out the state
     consistency between the sender and the receiver. For instance, a node
     that rebooted needs to reset its uptime to 0.  A Router router that changed
     information like a prefix information option has to advertise an
     incremented state sequence. To that effect, the CUO carries a Node State
     Sequence Information (NSSI) and a Consistent Uptime.  See <xref
     target="CUO"/> for the option details.
   </t>
   <t>
   A details.</t>

     <t>A node that receives the CUO checks whether it is indicative of a
     desynchronization between peers. A peer that discovers that a router has
     changed should reassess which addresses it formed based on the new PIOs
     from that router, router and resync the state that it installed in the router, e.g., router
     (e.g., the registration state for its addresses. addresses).  In the process, the peer
     may attempt to form to:</t>
     <ul>
       <li>form new addresses and register them, deprecate them,</li>
       <li>deprecate old addresses and deregister them using a Lifetime of 0, and reform and</li>
       <li>reform any potentially lost state,
   e.g., state (e.g., by registering again an
       existing address that it will keep using. A using).</li>
     </ul>

     <t>A loss of state is inferred if the Consistent Uptime of the peer is
     less than the time since the state was installed, or if the NSSI is
     incremented for a consistent uptime.
   </t> Consistent Uptime.</t>
   </li>
   <li>
   <t>
   Registration
     <t>Registration for multicast and anycast addresses is now supported. The
     P-Field is added to the EARO to signal when the registered address Registered Address is
     anycast or multicast. If the The value of the P-Field is not consistent with
     the Registered Address, that is if
   </t> Address if:</t>

   <ul>
   <li>
   the
     <li>the Registered Address is a multicast address (section 2.4 of <xref target="RFC4291"/>) (<xref target="RFC4291"
     sectionFormat="of" section="2.4"/>) and the P-Field indicates a value
     that is not 1, or
   </li><li>the or</li>
     <li>the Registered Address is not a multicast address and the P-Field
     indicates a value that is 1.
   </li> 1.</li>
   </ul>
   <t>

   <t>If this occurs, then the message, NS(EARO) or EDAR, MUST <bcp14>MUST</bcp14> be dropped, and
   the receiving node MAY <bcp14>MAY</bcp14> either reply with a status of 12
   "Invalid Registration" or remain silent.
  </t> silent.</t>
 </li>
   <li>
   The

   <li>The Status field in the EDAR message that was reserved and not used in RFC 8505
   <xref target="RFC8505"/> is repurposed to transport the flags to signal
   multicast and anycast.
   </li>
   <li>
   The anycast.</li>

   <li>The 6LN MUST <bcp14>MUST</bcp14> also subscribe all the IPv6 multicast
   addresses that it listens to, and it MUST <bcp14>MUST</bcp14> set the P-Field to
   1 in the EARO for those addresses.  The one exception is the all-nodes
   link-scope multicast address ff02::1 <xref target="RFC4291"/> target="RFC4291"/>, which is
   implicitly registered by all nodes, meaning that all nodes are expected to
   accept messages sent to ff02::1 but are not expected to register it.
   </li>
   <li>
   The it.</li>

   <li>The 6LN MAY <bcp14>MAY</bcp14> set the R flag in the EARO to obtain the
   delivery of the multicast packets by the 6LR, e.g., 6LR (e.g., by MLD proxy
   operations, or by injecting the address in a route-over subnet or in the
   Protocol Independent Multicast <xref target="RFC7761"/> protocol.
   </li>
   <li>
   The protocol).</li>

   <li>The 6LN MUST <bcp14>MUST</bcp14> also subscribe all the IPv6 anycast
   addresses that it supports supports, and it MUST <bcp14>MUST</bcp14> set the P-Field in
   the EARO to 2 for those addresses.
   </li>
   <li>
   The addresses.</li>

   <li>The 6LR and the 6LBR are extended to accept more than one subscription
   for the same address when it is anycast or multicast, since multiple 6LNs
   may subscribe to the same address of these types. In both cases, the
   Registration Ownership Verifier (ROVR) ROVR
   in the EARO identifies uniquely identifies a registration within the namespace of the
   Registered Address.
   </li>
   <li> Address.</li>

<!--[rfced] Section 7.3. We are having trouble parsing this
sentence. Is the intended meaning that all the nodes that
registered an address to the 6LR also registered the link-scope
multicast address ff02::1 to all the nodes? Please clarify.

Original:
   The 6LR MUST also consider that all the nodes that registered an
   address to it (as known by the Source Link-Layer Address Option) Option
   (SLLAO)) also registered to the all nodes link-scope multicast
   address ff02::1 <xref target="RFC4291"/>.
   </li>
   <li> [RFC4291].

Perhaps:
   The 6LR MUST also consider that all the nodes that registered an
   address to it (as known by the Source Link-Layer Address Option
   (SLLAO)) also registered the link-scope multicast address ff02::1
   [RFC4291] to all the nodes.
-->

<!-- [Pascal]: no: ff02::1 is the "all nodes" link-scope multicast address-->

   <li>The 6LR <bcp14>MUST</bcp14> also consider that all the nodes that
   registered an address to it (as known by the Source Link-Layer Address
   Option (SLLAO)) also registered ff02::1 <xref target="RFC4291"/> to the all-nodes link-scope multicast address.</li>

   <li>The 6LR <bcp14>MUST</bcp14> maintain a subscription state per tuple
   (IPv6 address, ROVR) for both anycast and multicast types of address. addresses. 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. In turn, the 6LBR MUST <bcp14>MUST</bcp14> maintain a
   subscription state per tuple (IPv6 address, ROVR) for both anycast and
   multicast types of address.
   </li> address.</li>

   </ul>

</section> <!-- end section "Registering Extensions"-->

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

<section anchor="updating2"><name>Updating anchor="updating2">
  <name>Extending RFC 9010</name>
<t>
   <xref

  <t><xref target="RFC9010"/> specifies the following behaviours:
</t> behaviors:</t>
   <ul>
   <li>
   The
     <li>The 6LR has no specified procedure to inject multicast and anycast routes in RPL even though RPL supports multicast.
   </li>
   <li>
   Upon multicast.</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 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 Layer 2 frame
     to the LLA of the node that registered the unicast address.
   </li> address.</li>
   </ul>
   <t>
   This

   <t>This specification Extends <xref target="RFC9010"/> by adding the following behavior:
   </t> behavior:</t>

   <ul>
   <li>
   Upon
     <li>Upon a subscription with the R flag and the P-Field both set to 1 in the EARO,
     if the scope of the multicast address is above link-scope <xref target="RFC7346"/>,
     then the 6LR injects the address in the RPL multicast support and sets the P
   field P-Field in the RTO to 1 as well.
   </li><li>
   Upon well.</li>
     <li>Upon a subscription with the R flag set to 1 and the P-Field set to 2 in the EARO,
     the 6LR injects the address in the new RPL anycast support and sets the P-Field
     to 2 in the RTO.
   </li><li>
   Upon RTO.</li>
     <li>Upon receiving a packet directed to a multicast address for which it has at
     least one subscription, the 6LR delivers a copy of the packet as a unicast
   layer-2
     Layer 2 frame to the LLA of each of the nodes that registered to that
     multicast address.
   </li><li>
   Upon address.</li>
     <li>Upon receiving a packet directed to an anycast address for which it has at
     least one subscription, the 6LR delivers a copy of the packet as a unicast
   layer-2
     Layer 2 frame to the LLA of exactly one of the nodes that registered to that
     multicast address.
   </li> address.</li>
   </ul>
</section> <!-- end section "Updating RFC 9010"-->

<section  anchor="sec8928"><name>Leveraging anchor="sec8928">
  <name>Leveraging RFC 8928</name>
<t>
    <xref target="RFC8928"> Address-Protected

  <t>"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>
    With target="RFC8505"/>.</t>

  <t>With <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
  methods.</t>

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

</t>
<t>
    Anycast 6LN).</t>

  <t>Anycast and multicast addresses are not owned by one node. Multiple nodes
  may subscribe to the same address.  In that context, the method specified in
  <xref target="RFC8928"/> cannot be used with autoconfigured keypairs key pairs to
  protect a single ownership.
</t>
<t>
    For ownership.</t>

  <t>For an anycast or a multicast address, it is still possible to leverage
  <xref target="RFC8928"/> to enforce the right to subscribe.  If <xref
  target="RFC8928"/> is used, a keypair MUST key pair <bcp14>MUST</bcp14> be associated with
  the address before it is deployed, and a ROVR MUST <bcp14>MUST</bcp14> be generated
  from that keypair key pair as specified in <xref target="RFC8928"/>.  The address and
  the ROVR MUST <bcp14>MUST</bcp14> then be installed in the 6LBR so it can recognize
  the address and compare the ROVR on the first subscription.
</t>
<t>
    The keypair MUST subscription.</t>

  <t>The key pair <bcp14>MUST</bcp14> then be provisioned in each node that needs
  to subscribe to the anycast or multicast address, so the node can follow the
  steps in <xref target="RFC8928"/> to subscribe to the address.
</t> address.</t>
</section>  <!-- Leveraging RFC 8929 -->

<section anchor="CUO"><name>Consistent anchor="CUO">
  <name>Consistent Uptime Option </name>

  <t>This specification introduces a new option that characterizes the uptime
  of the sender. The option may be used by routers in RA messages and by any
  node in NS, NA, and RS messages. It is used by the receiver to infer whether
  some state synchronization might be lost, e.g., lost (e.g., due to reboot.
</t> reboot).</t>

 <figure anchor="CUOF"><name>Consistent anchor="CUOF">
   <name>Consistent Uptime Option (CUO) Format</name>
 <artwork align="center">
  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    | Exponent  |  Uptime Mantissa  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |S|U|   flags   |          NSSI         |     Peer NSSI         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 </artwork>
 </figure><!-- end figure "Consistent Uptime Option Format" -->
 </figure>
<dl>
<dt> Type: </dt>
    <dd>To be assigned
  <dt>Type:</dt>
  <dd>Assigned by IANA, IANA; see <xref target="NDOpt"/> </dd>
<dt> Length: </dt>
    <dd> 1 </dd>
<dt> Uptime Exponent: </dt>
    <dd>6-bit target="NDOpt"/>.</dd>
  <dt>Length:</dt><dd>1</dd>
  <dt>Uptime Exponent:</dt>
  <dd>A 6-bit unsigned integer: The integer and the Exponent to the base 2 of the uptime unit </dd>
<dt> Uptime Mantissa: </dt>
    <dd>10-bit unit.</dd>
  <dt>Uptime Mantissa:</dt>
  <dd>A 10-bit unsigned integer: The integer and the mantissa of the uptime value </dd> value.</dd>
  <dt>S:</dt>
    <dd>
  <dd>A 1-bit flag, flag set to 1 to indicate that the sender is low-power
  and may sleep.</dd>
  <dt>U:</dt>
    <dd>
  <dd>A 1-bit flag, flag set to 1 to indicate that the Peer NSSI field is
  valid; it MUST <bcp14>MUST</bcp14> be set to 0 when the message is not unicast and MUST
  <bcp14>MUST</bcp14> be set to 1 when the message is unicast and the sender has
  an NSSI state for the intended receiver.</dd>
  <dt>flags:</dt>
    <dd> 6-bit, reserved. MUST
  <dd>6-bit flags that are reserved and that <bcp14>MUST</bcp14> be
  set to 0 by the sender and ignored by the receiver.</dd>
<dt> NSSI: </dt>
    <dd>12-bit
  <dt>NSSI:</dt>
  <dd>A 12-bit unsigned integer: The integer that represents the Node State Sequence Information, MUST Information (NSSI). It
  <bcp14>MUST</bcp14> be stored by the receiver if it has a dependency on
  information advertised or stored at the sender.</dd>
<dt> Peer NSSI: </dt>
    <dd>12-bit
  <dt>Peer NSSI:</dt>
  <dd>A 12-bit unsigned integer: Echoes integer that echoes the last known NSSI from the peer.</dd>
</dl>

<t>The Consistent Uptime indicates how long the sender has been continuously
up and running (though possibly sleeping) without loss of state.  It is
expressed by the Uptime Mantissa in units of 2 to the power of the Uptime
Exponent in milliseconds. The receiver derives the boot time of the sender as the
current time minus the sender's Consistent Uptime.

</t><t>
   If Uptime.</t>

<t>If the boot time of the sender is updated to a newer time, any state that
the receiver installed in the sender before the reboot is probably lost. The
receiver MUST <bcp14>MUST</bcp14> reassess all the state it installed in the server
(e.g., any registration) and reinstall if it is still needed.

</t><t>

   The needed.</t>

<t>The U flag not set in a unicast message from the sender indicates that it
the sender has lost all state from this node.  If the U flag is set, then the Peer NSSI
field can be used to assess which changes the sender missed.
   The For the other way
around, any state that was installed in the receiver from information by the
sender before it rebooted MUST <bcp14>MUST</bcp14> be removed and may or may not be
reinstalled later.
</t>
<t>
   The later.</t>

<t>The value of the uptime is reset to 0 at some point of the sender's reboot
sequence, but it may not be still be 0 when the first message is sent, so the
receiver must not expect a value of 0 as the signal of a reboot.
</t> reboot.</t>

<table anchor="timex" ><name>Consistent anchor="timex">
  <name>Consistent Uptime Rough Values</name>
  <thead>
      <tr><td>Mantissa</td><td>Exponent</td><td>Resolution</td><td>Uptime</td></tr>
   </thead><tbody>
      <tr><td>1</td><td>0</td><td>1ms</td><td>1ms</td></tr>
      <tr><td>5</td><td>10</td><td>1s</td><td>5 seconds</td></tr>
      <tr><td>2</td><td>15</td><td>30s</td><td>1mn</td></tr>
      <tr><td>2</td><td>21</td><td>33mn</td><td>1 hour</td></tr>
    <tr>
      <td>Mantissa</td>
      <td>Exponent</td>
      <td>Resolution</td>
      <td>Uptime</td>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>0</td>
      <td>1 ms</td>
      <td>1 ms</td>
    </tr>
    <tr>
      <td>5</td>
      <td>10</td>
      <td>1 s</td>
      <td>5 seconds</td>
    </tr>
    <tr>
      <td>2</td>
      <td>15</td>
      <td>30 s</td>
      <td>1 mn</td>
    </tr>
    <tr>
      <td>2</td>
      <td>21</td>
      <td>33 mn</td>
      <td>1 hour</td>
    </tr>
  </tbody>
</table>	<!-- end table "Consistent Uptime Example Values" +-->

<t>
   The

<t>The NSSI SHOULD <bcp14>SHOULD</bcp14> be stored in persistent memory by the sender
and incremented when it may have missed or lost state about a peer, or when it has
updated some state in a fashion that will impact a peer, e.g., peer (e.g., a host formed a
new address or a router advertises a new prefix. prefix).  When persisting is not
possible, then the NSSI is randomly generated.
</t><t>
   As generated.</t>

<t>As long as the NSSI remains constant, the cross-dependent state (such as
addresses in a host that depend on a prefix in a router) can remain stable,
meaning less checks in the receiver.  Any change in the value of the NSSI is
an indication that the sender updated some state and that the dependent state
in the receiver should be reassessed, e.g., reassessed (e.g., addresses that were formed based
on an RA with a previous NSSI should be checked, or new addresses may be
formed and
   registered.
</t><t>

</t>

</section><!-- Consistent Uptime Option --> registered).</t>

</section>

<section anchor="deploy"><name>Operational considerations</name>
<t>
   With anchor="deploy">
  <name>Operational Considerations</name>

  <t>With this specification, a RPL DODAG forms a realm, and multiple RPL
  DODAGs may be federated in a single RPL Instance administratively. This
  means that a multicast address that needs to span a RPL DODAG MUST
  <bcp14>MUST</bcp14> use a scope of Realm-Local whereas a multicast address
  that needs to span a RPL Instance
   MUST <bcp14>MUST</bcp14> use a scope of
  Admin-Local as discussed in section 3 of <xref
   target="RFC7346">"IPv6 target="RFC7346" sectionFormat="of"
  section="3"/>, "IPv6 Multicast Address Scopes"</xref>.
</t>
<t>
   <xref target="RFC6052">"IPv6 Scopes".</t>

  <t>"IPv6 Addressing of IPv4/IPv6 Translators"</xref> Translators" <xref target="RFC6052"/>
  enables to embed embedding IPv4 addresses in IPv6 addresses. The Root of a DODAG may
  leverage that technique to translate IPv4 traffic in IPv6 and route along
  the RPL domain. When encapsulating a packet with an IPv4 multicast
  Destination Address, it MUST <bcp14>MUST</bcp14> use a multicast address with the
  appropriate scope, Realm-Local or Admin-Local.
</t>
<t><xref target="RFC3306">"Unicast-Prefix-based Admin-Local.</t>

  <t>"Unicast-Prefix-based IPv6 Multicast Addresses"</xref> Addresses" <xref target="RFC3306"/>
  enables to form 2^32 forming 2<sup>32</sup> multicast addresses from a single /64 prefix.
  If an IPv6 prefix is associated to an Instance or a RPL DODAG, this provides
  a namespace that can be used in any desired fashion. It For instance, it is for instance
  possible for a standard defining organization to form its own registry and
  allocate 32-bit values from that namespace to network functions or device
  types. When used within a RPL deployment that is associated with a /64 prefix
  prefix, the IPv6 multicast addresses can be automatically derived from the
  prefix and the 32-bit value for either a Realm-Local or an Admin-Local
  multicast address as needed in the configuration.

</t>
<t>
   This configuration.</t>

  <t>This specification introduces the new RPL MOP 5.  Operationally speaking,
  deploying a new RPL MOP means that one cannot update a live network. The
  network administrator must create a new instance with MOP 5 and migrate
  nodes to that instance by allowing them to join it.

</t>
<t>
   In it.</t>

  <t>In a "green field" deployment where all nodes support this specification,
  it is possible to deploy a single RPL Instance using a multicast MOP for
  unicast, multicast, and anycast addresses.
</t><t>
   In addresses.</t>

  <t>In a "brown field" where legacy devices that do not support this
  specification co-exist coexist with upgraded devices, it is RECOMMENDED
  <bcp14>RECOMMENDED</bcp14> to deploy one RPL Instance in any Mode of Operation MOP
  (typically MOP 1) for unicast that legacy nodes can join, join and a
  separate RPL Instance dedicated to multicast and anycast operations using a
  multicast MOP.
</t><t>
   To MOP.</t>

  <t>To deploy a Storing Mode mode multicast operation using MOP 3 in a RPL domain,
  it is required that there is enough density of the RPL routers that support MOP 3 have enough density
  to build a DODAG that covers all the potential listeners and include includes the
  spanning multicast trees that are needed to distribute the multicast flows.
  This might not be the case when extending the capabilities of an existing
   network.
</t><t>
   In
  network.</t>

  <t>In the case of the new Non-Storing multicast MOP, arguably the new
  support is only needed at the 6LRs that will accept multicast listeners. It
  is still required that each listener can be able to reach at least one such 6LR, so the
  upgraded 6LRs must be deployed to cover all the 6LN 6LNs that need multicast services.
</t><t>
   Using
  services.</t>

  <t>Using separate RPL Instances for in the one hand unicast traffic and in on the
   other one hand and for
  anycast and multicast traffic on the other hand allows to for the use of different
  objective
   function, functions; one favoring favors the link quality up Up for unicast collection
  and one
   favoring downwards the other favors Downwards link quality for multicast distribution.
</t><t>
   But distribution.</t>

  <t>However, this might be impractical in some use cases where the signaling and
  the state to be installed in the devices are very constrained, the upgraded
  devices are too sparse, or the devices do not support more multiple instances.
</t><t>
   When
  instances.</t>

  <t>When using a single RPL Instance, MOP 3 expects the Storing Mode of
  Operation for both unicast and multicast, which is an issue in constrained
  networks that typically use MOP 1 for unicast. This specification allows a
  mixed mode that is signaled as MOP 1 in the DIO messages for backward
  compatibility, where limited multicast and/or anycast is available, under
  the following conditions:
</t> conditions:</t>

  <ul>
 <li>
   There MUST
    <li>There <bcp14>MUST</bcp14> be enough density of the 6LRs that support the
    mixed mode to cover all the 6LNs that require multicast or anycast
    services.  In Storing Mode, mode, there MUST <bcp14>MUST</bcp14> be enough density of
    the 6LRs that support the mixed mode to also form a DODAG to the Root.
 </li>  <li>
   The Root.</li>
    <li>The RPL routers that support the mixed mode are configured to operate
    in accordance with the desired operation in the network.
 </li> <li>
   The network.</li>
    <li>The MOP signaled in the RPL DIO messages is MOP 1 to enable the legacy
    nodes to operate as leaves.
 </li> <li>
   The leaves.</li>
    <li>The support of multicast and/or anycast in the RPL Instance SHOULD
    <bcp14>SHOULD</bcp14> be signaled by the 6LRs to the 6LN using a 6CIO, 6CIO; see
    <xref target="CIO"/>.
 </li> <li>
   Alternatively, target="CIO"/>.</li>
    <li>Alternatively, the support of multicast in the RPL domain can be
    globally known by other means such as including configuration or external information such as
    support of a version of an industry standard that mandates it. In
    that case, all the routers MUST <bcp14>MUST</bcp14> support the mixed mode.
 </li> mode.</li>
  </ul>

</section>	<!-- end section "Operational considerations" -->

<section  anchor="sec"><name>Security anchor="sec">
  <name>Security Considerations</name>
<t>
    This

  <t>This specification Extends <xref target="RFC8505"/> and <xref target="RFC9010"/>,
  target="RFC9010"/> and leverages <xref target="RFC9008"/>.  The security section
  sections in these documents also apply to this document.  In particular, the
  link layer SHOULD <bcp14>SHOULD</bcp14> be sufficiently protected to prevent rogue access.
</t><t>
    <xref
  access.</t>

<t><xref target="RFC6550"> RPL </xref> already supports routing on multicast
  addresses, whereby the endpoint that subscribes to the group and to do so injects by injecting
  the multicast address participates to RPL as a RPL aware node (RAN). RPL-Aware Node (RAN) in the RPL.
  Using an extension of RFC 8505 <xref target="RFC8505"/> as opposed to RPL to
  subscribe the address allows a RPL unaware leaf RPL-Unaware Leaf (RUL) to subscribe as well.
  As noted in <xref target="RFC9010"/>, this provides a better security
  posture for the RPL network, since the nodes that do not really need to
  speak RPL, or are not trusted enough to inject RPL messages, can be
  forbidden from doing so, which bars a number of attacks attack vectors from within
  RPL. Acting as an RUL, those nodes may still leverage the RPL network through
  the capabilities that are opened via ND operations. With this draft, specification, a node
  that needs multicast delivery can now obtain the service in a RPL domain
  while not being allowed to inject RPL messages.
	</t>
<t>

</t>
<t> Compared messages.</t>

  <t>Compared to <xref target="RFC6550"/>, this draft specification enables to track tracking the
  origin of the multicast subscription inside the RPL network.  This is a
  first step to enable a form of Route Ownership Validation (ROV) (see <xref
  target="RFC6811"/>) in RPL using the ROVR field in the EARO as proof of ownership.
</t>
<t>
   <xref
  ownership.</t>

  <t><xref target="sec8928"/> leverages <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 is 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. users in advance.  A less preferred way could would be to synchronize the
  ROVR and TID values across the valid subscribers as a preshared key material.
</t>
<t>
   In
  material.</t>

  <t>In the latter case, it could be possible to update the keys associated to
  an address 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, and
  switch the traffic to that address when the migration is complete.
</t> complete.</t>
</section>	<!-- end section "Security Considerations" -->

<section anchor="back"><name>Backward anchor="back">
  <name>Backward Compatibility</name>
<t>
   A

  <t>A legacy 6LN will not subscribe multicast addresses addresses, and the service will
  be the same when the network is upgraded. A legacy 6LR will not set the X
  flag in the 6CIO 6CIO, and an upgraded 6LN will not subscribe multicast addresses.
</t>
<t>
   Upon
  addresses.</t>

  <t>Upon receiving an EDAR message, a legacy 6LBR may not realize that the address
  being registered is anycast or multicast, multicast and will return that it is a duplicate in
  the EDAC status. The 6LR MUST <bcp14>MUST</bcp14> ignore a duplicate status in
  the EDAC for anycast and multicast addresses.
</t>
<t>
   As addresses.</t>

  <t>As detailed in <xref target="deploy"/>, it is possible to add multicast on
  an existing MOP 1 deployment.
</t>

<t>
   The deployment.</t>

  <t>The combination of a multicast address and the P-Field set to 0 in an RTO
  in a MOP 3 RPL Instance is understood by an indication to the receiver that supports this
  specification (the parent) as an indication that the sender (child) does not support this specification, but specification.
  However, the RTO is accepted and processed as if the P-Field was set to 1 for backward compatibility.
  </t>

<t>
   When

  <t>When the DODAG is operated in MOP 3, a legacy node will not set the P-Field
  and still expect multicast service as specified in section 12 of <xref
   target="RFC6550"/>. target="RFC6550"
  sectionFormat="of" section="12"/>.  In MOP 3 3, an RTO that is received with a
  target that is multicast and the P-Field set to 0 MUST <bcp14>MUST</bcp14> be
  considered as multicast and MUST <bcp14>MUST</bcp14> be processed as if the P-Field
  is set to 1.
</t> 1.</t>
</section>	<!-- end section "Backward Compatibility" -->

<section ><name>IANA

<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;
    also, requests to IANA must be edited to reflect the IANA actions once
    performed.
</t>
<t>
    Note to IANA, to be removed: the I Field is defined in
    <xref target="RFC9010"/> but is missing from the registry, so the bit
    positions must be added for completeness in conformance with the RFC.
</t>
<t>
    IANA is requested to make

  <t>IANA 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, as follows:
</t> groupings; see details in the subsections that follow.</t>

    <section anchor="PF"><name>New anchor="PF">
      <name>New P-Field values Values Registry</name>

	<t>
    IANA is requested to create

      <t>IANA has created a new "P-Field values" Values" registry under the
    heading
      "Internet Control Message Protocol version 6 (ICMPv6)
      Parameters" registry group to store the expression of the Registered Address Type Indicator RATInd as a P-Field.
	</t>

 <t> Registration P-Field.</t>

      <t>The registration procedure is "Standards Action" Standards Action <xref
      target='RFC8126'/>. The initial allocation is allocations are as indicated in <xref target="AM2"/>:
 </t>
      target="AM2"/>:</t>

      <table anchor="AM2" ><name>P-Field values</name> anchor="AM2">
	<name>P-Field Values Registry</name>
	<thead>
      <tr><td>Value</td><td>Registered
	  <tr>
	    <td>Value</td>
	    <td>Registered Address Type Indicator</td><td>Reference</td></tr>
     </thead><tbody>
      <tr><td>0</td><td>Registration Indicator</td>
	    <td>Reference</td>
	  </tr>
	</thead>
	<tbody>
	  <tr>
	    <td>0</td>
	    <td>Registration for a Unicast Address</td> <td>This RFC</td></tr>
      <tr><td>1</td><td>Registration
	    <td>RFC 9685</td>
	  </tr>
	  <tr>
	    <td>1</td>
	    <td>Registration for a Multicast Address</td> <td>This RFC</td></tr>
      <tr><td>2</td><td>Registration
	    <td>RFC 9685</td>
	  </tr>
	  <tr>
	    <td>2</td>
	    <td>Registration for an Anycast Address</td> <td>This RFC</td></tr>
      <tr><td>3</td><td>Unassigned</td><td>This RFC</td></tr>
	    <td>RFC 9685</td>
	  </tr>
	  <tr>
	    <td>3</td>
	    <td>Unassigned</td>
	    <td>RFC 9685</td>
	  </tr>
	</tbody>
      </table>  <!-- end table "P-Field values" -->

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

    <section><name>New
    </section>

    <section anchor="EDAR_Message_Flags">
      <name>New EDAR Message Flags Registry</name>
	<t>
    IANA is requested to create

      <t>IANA has created a new "EDAR Message Flags" registry under
      the
    heading "Internet Control Message Protocol version 6 (ICMPv6) Parameters".
	</t>

 <t> Registration
      Parameters" registry group.</t>

      <t>The registration procedure is "IETF Review" IETF Review or "IESG Approval" IESG Approval <xref
      target='RFC8126'/>. The initial allocation is allocations are as indicated in <xref target="EDARflags"/>:
 </t>
      target="EDARflags"/>:</t>

      <table anchor="EDARflags" ><name>EDAR anchor="EDARflags">
	<name>EDAR Message flags</name> Flags Registry</name>
	<thead>
      <tr><td>Bit Number</td><td>Meaning</td><td>Reference</td></tr>
   </thead><tbody>
      <tr><td>0..1 (suggested)</td><td> P-Field
	  <tr>
	    <td>Bit Number</td>
	    <td>Meaning</td>
	    <td>Reference</td>
	  </tr>
	</thead>
	<tbody>
	  <tr>
	    <td>0-1</td>
	    <td>P-Field (2 bits), see <xref target="PF"/>
      </td><td>This RFC</td></tr>
      <tr><td>2..7</td><td>Unassigned </td><td></td></tr> bits)</td>
	    <td>RFC 9685, <xref target="PF"/></td>
	  </tr>
	  <tr>
	    <td>2-7</td>
	    <td>Unassigned</td>
	    <td></td>
	  </tr>
	</tbody>
      </table>	<!-- end table "EDAR Message flags" +-->

    </section>	<!-- end section "New EDAR Message flags Registry -->

 <section><name>New EARO flags</name>
	<t> IANA is requested to make additions
<section>
      <name>New Address Registration Option Flags</name>

      <t>IANA has made an addition to the "Address Registration
      Option Flags" registry <xref target="IANA.ICMP.ARO.FLG"/> registry under the heading
      "Internet Control Message Protocol version 6 (ICMPv6)
      Parameters" registry group as indicated in <xref target="AROflags"/>:
	</t> target="AROflags"/>:</t>

      <table anchor="AROflags" ><name>New ARO flags</name> anchor="AROflags"><name>New Address Registration Option Flags</name>
      <thead>
      <tr><td>ARO flag</td><td>Meaning</td><td>Reference</td></tr>
   </thead><tbody>
      <tr><td>2..3 (suggested)</td><td> P-Field
	<tr>
	  <td>Bit Number</td>
	  <td>Description</td>
	  <td>Reference</td>
	</tr>
      </thead>
      <tbody>
	<tr>
	  <td>2-3</td>
	  <td>P-Field (2 bits), see bits)</td>
	  <td>RFC 9685, <xref target="PF"/></td><td>This RFC</td></tr> target="PF"/></td>
	</tr>
      </tbody>
      </table>	<!-- end table "New  ARO flag" +-->

    </section>	<!-- end section "New ARO flag -->

    <section><name>New RTO flags</name>
	<t> IANA is requested to make additions

    <section>
      <name>New RPL Target Option Flags</name>

      <t>IANA has made an addition to the "RPL Target Option Flags"
      registry <xref target="IANA.RPL.RTO.FLG"/>  registry under the heading "Routing
      Protocol for Low Power and Lossy Networks (RPL)" registry group as indicated in <xref target="RTOflags"/>:
	</t>
      target="RTOflags"/>:</t>

      <table anchor="RTOflags" ><name>New RTO flags</name> anchor="RTOflags"><name>New RPL Target Option Flags</name>
      <thead>
      <tr><td>Bit Number</td><td>Meaning</td><td>Reference</td></tr>
   </thead><tbody>
      <tr><td>2..3 (suggested)</td><td> P-Field
	<tr>
	  <td>Bit Number</td>
	  <td>Capability Description</td>
	  <td>Reference</td>
	</tr>
      </thead>
      <tbody>
	<tr>
	  <td>2-3</td>
	  <td>P-Field (2 bits), see bits)</td>
	  <td>RFC 9685, <xref target="PF"/></td><td>This RFC</td></tr> target="PF"/></td>
	</tr>
      </tbody>
      </table>	<!-- end table "New  RTO flags" +-->

    </section>	<!-- end section "New RTO flags -->

    <section><name>New

    <section anchor="RPL_Mode_Op">
      <name>New RPL Mode of Operation</name>
	<t> IANA is requested to make

    <t>IANA has made an addition to the "Mode of Operation"
    registry <xref target="IANA.RPL.MOP"/> registry under the heading "Routing Protocol for
    Low Power and Lossy Networks (RPL)" registry group as indicated in <xref target="RMOP"/>:
	</t> target="RMOP"/>:</t>

    <table anchor="RMOP" ><name>New anchor="RMOP"><name>New RPL Mode of Operation</name>
    <thead>
      <tr><td>Value</td><td>Description</td><td>Reference</td></tr>
   </thead><tbody>
      <tr><td>5 (suggested)</td><td>Non-Storing
      <tr>
	<td>Value</td>
	<td>Description</td>
	<td>Reference</td>
      </tr>
    </thead>
    <tbody>
      <tr>
	<td>5</td>
	<td>Non-Storing Mode of Operation with ingress
	replication multicast support</td><td>This RFC</td></tr> support</td>
	<td>RFC 9685</td>
      </tr>
    </tbody>
  </table>	<!-- end table "New  RTO flags" +-->
</section>	<!-- end section "New RTO flags -->

   <section title="New anchor="New_Cap_Bits">
      <name>New 6LoWPAN Capability Bits">
	<t>
    IANA is requested to make Bit</name>

      <t>IANA has made an addition to the "6LoWPAN Capability
      Bits" registry <xref target="IANA.ICMP.6CIO"/> registry under the
    heading
      "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry group as
      indicated in <xref target="CIOdat"/>:
	</t> target="CIOdat"/>:</t>

      <table anchor="CIOdat" ><name>New anchor="CIOdat"><name>New 6LoWPAN Capability Bits</name> Bit</name>
      <thead>
      <tr><td>Capability Bit</td><td>Meaning</td><td>Reference</td></tr>
   </thead><tbody>
      <tr><td>8 (suggested)</td><td>X
	<tr>
	  <td>Bit</td>
	  <td>Description</td>
	  <td>Reference</td>
	</tr>
      </thead>
      <tbody>
	<tr>
	  <td>8</td>
	  <td>X flag: Registration for Unicast, Multicast, and Anycast Addresses Supported</td><td>This RFC</td></tr> Supported</td>
	  <td>RFC 9685</td>
	</tr>
      </tbody>
      </table>	<!-- end table "New 6LoWPAN Capability Bits" -->

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

    <section title="New

    <section>
      <name>New Address Registration Option Status Values">
	<t>
   IANA is requested to make Values</name>

      <t>IANA has made additions to the "Address Registration
      Option Status Values" registry <xref target="IANA.ICMP.ARO.STAT"/> registry under
      the heading "Internet Control Message Protocol version 6 (ICMPv6) Parameters",
      Parameters" registry group as follows:
	</t> indicated in <xref target="AROstat"/>:</t>

      <table anchor="AROstat" ><name>New anchor="AROstat"><name>New Address Registration Option Status Values"</name> Values</name>
      <thead>
      <tr><td>Value </td><td>Description</td><td>Reference</td></tr>
   </thead><tbody>
      <tr><td>11 (suggested)</td><td>Registration
	<tr>
	  <td>Value</td>
	  <td>Description</td>
	  <td>Reference</td>
	</tr>
      </thead>
      <tbody>
	<tr>
	  <td>11</td>
	  <td>Registration Refresh Request</td><td>This RFC</td></tr>
      <tr><td>12 (suggested)</td><td>Invalid Registration</td><td>This RFC</td></tr> Request</td>
	  <td>RFC 9685</td>
	</tr>
	<tr>
	  <td>12</td>
	  <td>Invalid Registration</td>
	  <td>RFC 9685</td>
	</tr>
      </tbody>
      </table>	<!-- end table "New Address Registration Option Status Values" -->

    </section>	<!-- end section "New Address Registration Option Status Values" -->

    <section title="New

    <section>
      <name>New IPv6 Neighbor Discovery Option">
	<t>
   IANA is requested to make additions Option Format</name>

	<t>IANA has made an addition to the "IPv6 Neighbor Discovery
	Option Formats" registry under the heading "Internet Control Message
	Protocol version 6 (ICMPv6) Parameters", Parameters" registry group as follows:
	</t> indicated in <xref target="NDOpt"/>:</t>

	<table anchor="NDOpt" ><name>New anchor="NDOpt">
	  <name>New IPv6 Neighbor Discovery Option"</name> Option Format</name>
	<thead>
      <tr><td>Value </td><td>Description</td><td>Reference</td></tr>
   </thead><tbody>
      <tr><td>42 (suggested)</td><td>Consistent
	  <tr>
	    <td>Type</td>
	    <td>Description</td>
	    <td>Reference</td>
	  </tr>
	</thead>
	<tbody>
	  <tr>
	    <td>42</td>
	    <td>Consistent Uptime Option</td><td>This RFC</td></tr> Option</td>
	    <td>RFC 9685</td>
	  </tr>
	</tbody>
	</table>	<!-- end table "IPv6 Neighbor Discovery Option" -->
    </section>	<!-- end section "IPv6 Neighbor Discovery Option" -->

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

<section title="Acknowledgments">
<t>
   This work is a production of an effective collaboration between the IETF 6lo
   WG and the Wi-Sun FAN WG. Thanks to all in both WGs who contributed reviews
   and productive suggestions, in particular Carsten Bormann, Paul Duffy,
   Klaus Hueske, Adnan Rashid, Rahul Jadhav, Gene Falendysz, Don Sturek,
   Dario Tedeschi, Saurabh Jain, and Chris Hett, with special thanks
   to Esko Dijk for his useful WGLC reviews and proposed changes.
   Also many thanks to Eric Vyncke, Sandy Ginoza, Zaheduzzaman Sarker,
   Paul Wouters, Roman Danyliw, John Scudder, Dirk Von Hugo, Murray Kucherawy,
   Kyle Rose, Scott Kelly, and Dan Romascanu for their suggestions and comments during
   the IETF last call and IESG review cycle.
</t>
</section> <!-- title="Acknowledgments" -->

</middle>

<back>

<displayreference target="IEEE802154"            to="IEEE Std 802.15.4"/> to="IEEE-802.15.4"/>
<displayreference target="IEEE802151"            to="IEEE Std 802.15.1"/> to="IEEE-802.15.1"/>
<displayreference target="IEEE80211"             to="IEEE Std 802.11"/> to="IEEE-802.11"/>

<displayreference target="I-D.kuehlewind-rswg-updates-tag" to="UPDATES-TAG"/>
<displayreference target="I-D.ietf-rift-rift" to="RIFT"/>
<displayreference target="I-D.ietf-6lo-prefix-registration" to="REGISTRATION"/>
<displayreference target="I-D.ietf-6man-ipv6-over-wireless" to="IPv6-OVER-WIRELESS"/>
<displayreference target="I-D.thubert-bess-secure-evpn-mac-signaling" to="MAC-SIGNALING"/>
<displayreference target="I-D.heile-lpwan-wisun-overview" to="Wi-SUN"/>

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

<references>
  <name>References</name>
    <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.3306.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3306.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.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.7346.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7346.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.8126.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.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.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.9030.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9030.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.ARO.FLG"> anchor="IANA.ICMP.ARO.FLG" target="https://www.iana.org/assignments/icmpv6-parameters">
	 <front>
			<title>IANA Registry for the Address
	   <title>Address Registration Option Flags</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#icmpv6-adress-registration-option-flags"></seriesInfo>
       </reference>

       <reference anchor="IANA.ICMP.ARO.STAT"> anchor="IANA.ICMP.ARO.STAT" target="https://www.iana.org/assignments/icmpv6-parameters">
	 <front>
			<title>IANA Registry for the Address
	   <title>Address Registration Option Status Value</title> Values</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#address-registration"></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.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>

   <reference  anchor="IANA.RPL.RTO.FLG"> anchor="IANA.RPL.RTO.FLG" target="https://www.iana.org/assignments/rpl">
     <front>
			<title> IANA Sub-Registry for the RTO
       <title>RPL Target Option Flags</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#rpl-target-option-flags"></seriesInfo>
   </reference>

   <reference  anchor="IANA.RPL.MOP"> anchor="IANA.RPL.MOP" target="https://www.iana.org/assignments/rpl">
     <front>
			<title> IANA Sub-Registry for the RPL Mode
       <title>Mode of Operation</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#MOP"></seriesInfo>
   </reference>

 </references>

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

    <!-- I-D -->
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4919.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/>

 <references>
    <name>Informative References</name>

    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7731.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6811.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.7761.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.6052.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7731.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.6811.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9008.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-optimized-ir.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6052.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rift-rift.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-prefix-registration.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9008.xml"/>
    <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-ipv6-over-wireless.xml'/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9574.xml"/>

<!--[draft-kuehlewind-rswg-updates-tag] Editorial state/stream-->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.kuehlewind-update-tag.xml'/>
    <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.thubert-bess-secure-evpn-mac-signaling.xml"/> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.kuehlewind-rswg-updates-tag.xml"/>

<!--[draft-heile-lpwan-wisun-overview] Expired. Entered the long way to get the correct initials.-->
<reference anchor="IEEE802154"> anchor="I-D.heile-lpwan-wisun-overview" target="https://datatracker.ietf.org/doc/html/draft-heile-lpwan-wisun-overview-00">
  <front>
            <title>IEEE Std 802.15.4, Part. 15.4: Wireless Medium Access
            Control (MAC)
    <title>Wi-SUN FAN Overview</title>
    <author fullname="ROBERT HEILE" initials="H." surname="Robert">
      <organization>Wi-SUN Alliance</organization>
    </author>
    <author fullname="Bing (Remy) Liu" initials="B." surname="Liu">
      <organization>Huawei Technologies</organization>
    </author>
    <author fullname="Mingui Zhang" initials="M." surname="Zhang">
      <organization>Huawei Technologies</organization>
    </author>
    <author fullname="Charles E. Perkins" initials="C." surname="Perkins">
      <organization>Futurewei</organization>
    </author>
    <date day="3" month="July" year="2017"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-heile-lpwan-wisun-overview-00"/>
</reference>

<!--[draft-thubert-bess-secure-evpn-mac-signaling] Expired. Long way to get editor role.-->
<reference anchor="I-D.thubert-bess-secure-evpn-mac-signaling" target="https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling-04">
  <front>
    <title>Secure EVPN MAC Signaling</title>
    <author fullname="Pascal Thubert" initials="P." surname="Thubert" role="editor"/>
    <author fullname="Tony Przygienda" initials="T." surname="Przygienda">
      <organization>Juniper Networks, Inc</organization>
    </author>
    <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
      <organization>Microsoft</organization>
    </author>
    <date day="13" month="September" year="2023"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-thubert-bess-secure-evpn-mac-signaling-04"/>
</reference>

<!--[draft-ietf-6man-ipv6-over-wireles] IESG state: I-D exists. Long way to get editor role.-->
<reference anchor="I-D.ietf-6man-ipv6-over-wireless" target="https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-over-wireless-06">
  <front>
    <title>Architecture and Physical Layer (PHY) Specifications Framework for IPv6 over Non-Broadcast Access</title>
    <author fullname="Pascal Thubert" initials="P." surname="Thubert" role="editor"/>
    <author fullname="Michael Richardson" initials="M." surname="Richardson">
      <organization>Sandelman Software Works</organization>
    </author>
    <date day="23" month="May" year="2024"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-6man-ipv6-over-wireless-06"/>
</reference>

<!--[draft-ietf-6lo-prefix-registration] IESG state: I-D exists. Long way to get editor role.-->
<reference anchor="I-D.ietf-6lo-prefix-registration" target="https://datatracker.ietf.org/doc/html/draft-ietf-6lo-prefix-registration-05">
  <front>
    <title>IPv6 Neighbor Discovery Prefix Registration</title>
    <author fullname="Pascal Thubert" initials="P." surname="Thubert" role="editor"/>
    <date day="5" month="November" year="2024"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-6lo-prefix-registration-05"/>
</reference>

<!--[draft-ietf-rift-rift-24] in RFC Editor state. Long way to get editor roles.-->
<reference anchor="I-D.ietf-rift-rift" target="https://datatracker.ietf.org/doc/html/draft-ietf-rift-rift-24">
  <front>
    <title>RIFT: Routing in Fat Trees</title>
    <author fullname="Tony Przygienda" initials="T." surname="Przygienda">
      <organization>Juniper Networks</organization>
    </author>
    <author fullname="Jordan Head" initials="J." surname="Head" role="editor">
      <organization>Juniper Networks</organization>
    </author>
    <author fullname="Alankar Sharma" initials="A." surname="Sharma" role="editor">
      <organization>Hudson River Trading</organization>
    </author>
    <author fullname="Pascal Thubert" initials="P." surname="Thubert">
      <organization>Individual</organization>
    </author>
    <author fullname="Bruno Rijsman" initials="B." surname="Rijsman">
      <organization>Individual</organization>
    </author>
    <author fullname="Dmitry Afanasiev" initials="D." surname="Afanasiev">
      <organization>Yandex</organization>
    </author>
    <date day="23" month="May" year="2024"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-rift-rift-24"/>
</reference>

      <reference anchor="IEEE802154" target="https://ieeexplore.ieee.org/document/9144691">
         <front>
            <title>IEEE Standard for Low-Rate Wireless Personal Area Networks
            </title> Networks</title>
            <author>
               <organization>IEEE standard for Information Technology</organization>
               <organization>IEEE</organization>
            </author>
            <date/>
         </front>
	 <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9144691"/>
	 <seriesInfo name="IEEE Std" value="802.15.4-2020"/>
      </reference>

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

      <reference anchor="IEEE802151"> anchor="IEEE802151" target="https://ieeexplore.ieee.org/document/1490827">
         <front>
            <title> IEEE
            <title>IEEE Standard for Information Technology -
		Telecommunications and Information Exchange Between Systems technology - Local and Metropolitan Area Networks
            metropolitan area networks - Specific Requirements. requirements - Part 15.1: 15.1a:
            Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications
            specifications for Wireless Personal Area Networks
		(WPANs)
            </title> (WPAN)</title>
            <author>
            	<organization> IEEE standard for Information Technology
		</organization>
            	<organization>IEEE</organization>
            </author>
            <date/>
         </front>
	 <seriesInfo name="IEEE Std" value="802.15.1-2005"/>
 	 <seriesInfo name="DOI" value="10.1109/IEEESTD.2005.96290"/>
      </reference>
    </references>
  </references>

<section numbered="false">
  <name>Acknowledgments</name>

  <t>This work is a production of an effective collaboration between the IETF
  6lo WG and the Wi-Sun FAN WG. Thanks to all in both WGs who contributed
  reviews and productive suggestions, in particular: <contact
  fullname="Carsten Bormann"/>, <contact fullname="Paul Duffy, Klaus
  Hueske"/>, <contact fullname="Adnan Rashid"/>, <contact fullname="Rahul
  Jadhav"/>, <contact fullname="Gene Falendysz"/>, <contact fullname="Don
  Sturek"/>, <contact fullname="Dario Tedeschi"/>, <contact fullname="Saurabh
  Jain"/>, <contact fullname="and Chris Hett"/>, with special thanks to
  <contact fullname="Esko Dijk"/> for his useful WGLC reviews and proposed
  changes. Also many thanks to <contact fullname="Éric Vyncke"/>, <contact
  fullname="Sandy Ginoza"/>, <contact fullname="Zaheduzzaman Sarker"/>,
  <contact fullname="Paul Wouters"/>, <contact fullname="Roman Danyliw"/>,
  <contact fullname="John Scudder"/>, <contact fullname="Dirk Von Hugo"/>,
  <contact fullname="Murray Kucherawy"/>, <contact fullname="Kyle Rose"/>,
  <contact fullname="Scott Kelly"/>, and <contact fullname="Dan Romascanu"/>
  for their suggestions and comments during the IETF last call and IESG review
  cycle.</t>
</section>

</back>

<!--[rfced] Terminology

a) We note inconsistent capitalization for the following terms. Please
review and let us know how to update for consistency.

  Lifetime vs. lifetime: depends if it's the lifetime field in the EARO (upper) or the duration of the life of a thing (lower)

  Target vs. target: uppercase when dealing with the RPL Target Option else lowercase

  Transit vs. transit: same (regarding the RPL Transit Option)

  Up / Upward / Down vs. up / down / downward (those are defined and used uppercase in   RFC 6550 that define them, let us retain all uppercase)

    Original (capitalized):
       In both cases, P2P packets travel Up toward a DODAG root then Down
       to the final destination (unless the destination is on the Upward
       route).  In the Non-Storing case, the packet will travel all the
       way to a DODAG root before traveling Down.  In the Storing case,
       the packet may be directed Down towards the destination...

    Original (not capitalized):
       When forwarding multicast packets down the DODAG, the RPL router
       copies all the children that advertised the address in their DAO
       messages.  In contrast, when forwarding anycast packets down the
       DODAG...
-->

<!--[rfced] Please review the following questions and changes regarding the
abbreviations used in this document.

a) In the Introduction, P2P is expanded as both "peer-to-peer (P2P)" and
"point-to-point (P2P)" - is this correct? If so, how may we clarify what
expansion "P2P" refers to in the text below?

Original:
   In both cases, P2P packets travel Up toward a DODAG root then Down to the
   final destination (unless the destination is on the Upward route).

[Pascal]: let us retain P2P for point to point on both links and paths and forget about peer to peer. Peer-to-peer is used only once in RFC 9010 and only once here. I applied the following Proposal:

This trades the quality of peer-to-peer (P2P) paths for a vastly
->
This stretches the routes between RPL nodes inside the DODAG for a vastly

Does that work for you?

NOTE
[RFC Editor]: This update will need AD approval

d) The terms "DAO", "NS", and "NA" mostly appear in this document as "DAO
messages", "NS messages", etc. For consistency, should standalone instances of
these terms be updated? See some examples below (not an exhaustive list):

Original:
   In Storing Mode the RPL router accepts DAO from multiple children...

   It is incremented by the sender each time it sends a new series of NS
   and/or NA with the EARO about the Target.

Perhaps:
   In Storing mode, the RPL router accepts DAO messages from multiple children...

   It is incremented by the sender each time it sends
   a new series of NS and/or NA messages with the EARO about the Target.

[Pascal]: yes to all cases, please

-->

</rfc>