<?xml version="1.0" encoding="utf-8"?>
<!--DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"-->

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<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="8928" docName="draft-ietf-6lo-updating-rfc-8928-02" >
 
<front>

   <title abbrev="RFC 8928-Fix">Fixing the C-Flag in EARO</title>

   <author initials='P' surname='Thubert' fullname='Pascal Thubert' >
      <!-- <organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization> -->
      <address>
         <postal>
            <city>Roquefort-les-Pins</city>
            <code>06330</code>
          <country>France</country>
         </postal>
         <email>pascal.thubert@gmail.com</email>
      </address>
   </author>



   <author initials='A' surname='Rashid' fullname='Adnan Rashid'  >
      <organization abbrev='P Bari'>Politecnico di Bari</organization>
      <address>
         <postal>
            <street>Via Edoardo Orabona 4</street>
            <city>Bari</city>
            <code>70126</code>
          <country>Italy</country>
         </postal>
         <email>adnan.rashid@poliba.it</email>
      </address>
   </author>


   <area>Internet</area>


   <workgroup>6lo</workgroup>

   <abstract>
   <t>This document updates RFC 8928, “Address-Protected Neighbor Discovery for Low-Power and Lossy Networks” (AP-ND), by updating the bit 
      position for the C-flag in the Extended Address Registration Option (EARO) and registering it with IANA.
   <!-- This clarification ensures consistent implementation and interoperability of the AP-ND protocol, which protects against address theft and impersonation attacks in Low-Power
   and Lossy Networks (LLNs). This update provides a precise definition of the C-flag’s bit position, enabling correct deployment and verification of AP-ND’s security features. -->
   </t>
   </abstract>
</front>

<middle>

<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="introduction"> <name>Introduction</name>

<!-- <t>The classical 
 Neighbor Discovery (IPv6 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 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 Resolution (AR, aka Address Discovery or
   Address Lookup) and Duplicate Address Detection (DAD) of IPv6 unicast addresses.
   Those multicast operations typically impact every node on-link when at most
   one is really targeted, which is a waste of energy, and imply that all
   nodes are awake to hear the request, which is inconsistent with power
   saving (sleeping) modes.
</t>

<t>Low-Power Personal Area Networks (LoWPANs) require an optimized IPv6 Neighbor Discovery due to resource constraints and high multicast overhead. To address this, 6LoWPAN ND 
<xref target="RFC6775"/>, <xref target="RFC8505"/>, <xref target="RFC8929"/>, <xref target="RFC9685"/>, <xref target='I-D.ietf-6lo-prefix-registration'/> 
introduces a unicast, anycast, and multicast Address Registration (AR) mechanism as well as a Prefix Registration (PR) mechanism. Staring with <xref target="RFC8505"/>, 
the registration mechanism uses the Extended Address Registration Option (EARO), significantly reducing reliance on multicast for Duplicate Address Detection (DAD). 
In these networks, the 6LoWPAN Border Router (6LBR) serves as a central repository for registered addresses.
6LoWPAN ND is being generalized to NBMA networks as Subnet Neighbor Discovery (SND), see <xref target="I-D.ietf-6man-ipv6-over-wireless" />.  </t>

<t>For enhanced security, <xref target="RFC8505"/> introduces a Registration Ownership Verifier (ROVR) in the EARO. Building on this, the <xref target="RFC8928">
   "Address-Protected Neighbor Discovery for LLNs"</xref>, protects the ownership of unicast IPv6 addresses registered with <xref target="RFC8505"/>. 
   In this framework, a node auto-configures a public/private key pair and signs its address registrations, enabling the first-hop router (6LoWPAN Router (6LR)) to validate 
   registrations and perform source address verification.</t> -->

   <t>The <xref target="RFC8928"> Address-Protected Neighbor Discovery 
   for Low-Power and Lossy Networks (AP-ND)</xref> defined the C-flag in EARO. It is used to indicate that the Registration Ownership Verifier (ROVR) field contains
   a Crypto-ID and that the 6LoWPAN Node (6LN) may be challenged for ownership of the registered address. Initially <xref target="RFC8928"/> defined the C-flag in the EARO in bit position 3; later <xref target="RFC9685"/> defined the P-field in bits 2 and 3 of the 
   EARO flags field with proper IANA registration, causing an overlap with  Figure 1 of <xref target="RFC8928"/> which depicts the location of the C-flag.</t> 
   
   <t>This specification updates <xref target="RFC8928"/> by repositioning the C-flag as bit 1 of the EARO flags field, thereby preventing conflicts.</t>

</section>	<!-- end section = "Introduction"  -->



<section> <name>Terminology</name>
  <section anchor="bcp"><name>Requirements Language</name>
  <t>

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in BCP 14
    <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
    they appear in all capitals, as shown here.

  </t>

  </section>	<!-- end section "Requirements Language" -->

  <section anchor="lo"><name>References</name>
    <t>
	This document uses terms and concepts that are discussed in:
    </t>
<ul>
  <li>Neighbor Discovery for IP version 6 <xref target="RFC4861"></xref></li>
  <li>IPv6 Stateless Address Autoconfiguration <xref target="RFC4862"></xref></li>
  <li>Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) <xref target="RFC6775"></xref></li>
  <li>Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery <xref target="RFC8505"></xref></li>
  <li>IPv6 Backbone Router <xref target="RFC8929"></xref></li>
  <li>Address-Protected Neighbor Discovery for Low-Power and Lossy Networks <xref target="RFC8928"></xref></li>
  <li>Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses <xref target="RFC9685"></xref></li>
</ul>
  </section> <!--	 end section "References" -->

<section anchor='acronyms' > <name>Acronyms</name>
   <t>This document uses the following abbreviations:</t>
   <dl spacing='compact'>
      <dt><strong>6LN:</strong></dt><dd>6LoWPAN Node</dd>
      <dt><strong>6LBR:</strong></dt><dd>6LoWPAN Border Router</dd>
      <dt><strong>6LR:</strong></dt><dd>6LoWPAN Router</dd>
      <dt><strong>AP-ND:</strong></dt><dd>Address-Protected Neighbor Discovery</dd>
      <dt><strong>ARO:</strong></dt><dd>Address Registration Option</dd>
      <dt><strong>CIPO:</strong></dt><dd>Crypto-ID Parameters Option</dd>
      <dt><strong>DAD:</strong></dt><dd>Duplicate Address Detection</dd>
      <dt><strong>EARO:</strong></dt><dd>Extended Address Registration Option</dd>
      <dt><strong>LLN:</strong></dt><dd>Low-Power and Lossy Network</dd>
      <dt><strong>LoWPAN:</strong></dt><dd>Low-Rate Wireless Personal Area Network (IEEE Std. 802.15.4) <xref target="IEEE802154"/></dd>
      <dt><strong>NDP:</strong></dt><dd>Neighbor Discovery Protocol</dd>
      <dt><strong>RATInd:</strong></dt><dd>Registered Address Type Indicator</dd>
      <dt><strong>ROVR:</strong></dt><dd>Registration Ownership Verifier</dd>
      <dt><strong>TID:</strong></dt><dd>Transaction ID</dd>
    </dl>

     </section><!-- Acronyms -->


</section>	<!-- end section "Terminology" -->



<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->


<section anchor="updating"><name>Updating RFC 8928</name>
<t>
 	 <!-- The  <xref target="RFC8928">"Address-Protected Neighbor Discovery for Low-Power and Lossy Networks"</xref>
    was defined to protect the ownership of unicast IPv6 addresses that are registered with <xref target="RFC8505"/>. -->

    <!-- In <xref target="RFC8928"/>, the C-flag at bit 3 position in the EARO flags field as represented in Figure 1 of <xref target="RFC8928"/>.
    <xref target="RFC8928"/> fails to specify the bit number and to make the IANA registration for that bit position. Later on, <xref target="RFC9685"/>
    defines the P-Field in bits 2 and 3 of the EARO flags field, obtains a proper IANA registration, but causes an overlap with the representation 
    in Figure 1 of <xref target="RFC8928"/>. This specification updates <xref target="RFC8928"/> to position the C-flag as bit 1 of	the EARO flag,
    as represented in <xref target="RFC8928"/>, to avoid the overlapping definitions. -->
  <xref target="RFC8928"/> incorrectly refers to the Extended Address Registration Option (EARO) as the Enhanced Address Registration Option.
  This specification corrects this terminology throughout the document.
</t>
<t>
  In <xref target="RFC8928"/>, the C-flag is specified in the EARO flags field at bit position 3 (as depicted in the Figure 1 of <xref target="RFC8928"/>); 
  however, <xref target="RFC8928"/> fails to register its position with IANA. Later, <xref target="RFC9685"/> defined the P-field 
  in bits 2 and 3 of the EARO flags field and obtained proper IANA registration, but this introduced an overlap with the 
  representation in <xref target="RFC8928"/>. To resolve the conflict, this specification updates <xref target="RFC8928"/> by repositioning 
  the C-flag to bit 1 of the EARO flags field, thereby avoiding the overlapping definitions. 
  </t>
  <t>
  <xref target="EARO"/> replaces Figure 1 in <xref target="RFC8928"/> in the case of an EARO used in an NS message.  
  </t>
<figure anchor="EARO">
  <name>Extended Address Registration Option (EARO) Format for use in NS messages</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    |F|PrefixLength |    Opaque     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |r|C| P | I |R|T|     TID       |     Registration Lifetime     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
 ...               Registration Ownership Verifier               ...
  |                  (64, 128, 192, or 256 bits)                  |   
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  </artwork>
</figure><!-- end figure "EARO Option Format" -->
<t>
<xref target="EARO2"/> replaces Figure 1 in <xref target="RFC8928"/> in the case of an EARO used in an NA message. The difference between the two formats is in the usage of bits 16 to 23.
</t>
<figure anchor="EARO2">
  <name>Extended Address Registration Option (EARO) Format for use in NA messages</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    | r |  Status   |    Opaque     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |r|C| P | I |R|T|     TID       |     Registration Lifetime     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
 ...               Registration Ownership Verifier               ...
  |                  (64, 128, 192, or 256 bits)                  |   
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  </artwork>
</figure><!-- end figure "EARO Option Format" -->
<t>Option fields of interest for this specification:</t>


<dl>
  <dt><strong>Type:</strong></dt>
  <dd>33</dd>   
  
  <dt><strong>Length:</strong></dt>
  <dd>Defined in <xref target="RFC8505"/> and copied in the "EARO Length" field in the associated Crypto-ID Parameters Option (CIPO).</dd>
  
      <dt><strong>F:</strong></dt> <dd>  1-bit flag; set to 1 to indicate that the sender expects other
      routers to forward packets to self when the packets are sourced
      within the registered prefix. For use in NS messages only  <xref target= "I-D.ietf-6lo-prefix-registration"/>.</dd>

      <dt><strong>Prefix Length</strong></dt> <dd>  7-bit integer: This field contains a prefix length
      expressed in bits if the P field is set to 3 and the EARO is
      placed in an NS message.  In that case the value MUST be between
      16 and 120, both included.  The field contains a Status if the
      EARO is placed in an NA message regardless of the setting of the P
      flag.  In all other cases it is reserved, so it MUST be set to 0
      by the sender and ignored by the receiver. For use in NS messages only  <xref target= "I-D.ietf-6lo-prefix-registration"/>.</dd>

   <dt><strong>Status:</strong></dt> <dd> 6-bit unsigned integer.  Indicates the status of a registration in the NA response. The field MUST be set to 0 in NS messages unless the registration is for a prefix, in which case the F flag is set and the prefix length is provided. For use in NA messages only. The Status field is defined in <xref target="RFC8505"/> and resized by <xref target="RFC9010"/> .
   The values for the Status field are available in   <xref target="IANA.ICMP.ARO.STAT"/></dd>
  <dt><strong>Opaque:</strong></dt>
  <dd> 8-bit field opaque to ND. It MUST be set to 0 when not used. Defined in <xref target="RFC8505"/>.</dd>
  
  <dt><strong>r (reserved):</strong></dt>
  <dd>1-bit reserved field. It MUST be set to zero by the sender and MUST be ignored by the receiver.</dd>
  
  <dt><strong>C:</strong></dt>
  <dd>1-bit flag, moved from its position in Figure 1 of <xref target="RFC8928"/>. It is set to indicate that the ROVR field contains a Crypto-ID and that the 6LN MAY be challenged for ownership.</dd>
  
  <dt><strong>P:</strong></dt>
  <dd>2-bit field for Registered Address Type Indicator (RATInd). Indicates whether an address is unicast, multicast, or anycast. 
   Used to transport the RATInd in different protocols. All values registry are defined in Table 2 of <xref target="RFC9685"/>.</dd> 
  
  <dt><strong>I:</strong></dt>
  <dd>2-bit integer field that helps to decide how to use the 8-bit Opaque field.
   When 0, it means the Opaque field has info about the default routing path.
   Other values are reserved. Defined in <xref target="RFC8505"/>.</dd>
  
  <dt><strong>R:</strong></dt>
  <dd>1-bit flag. Registering Node sets the R-flag to request reachability services for the Registered Address from a
   Routing Registrar. Defined in <xref target="RFC8505"/>.</dd>

  <dt><strong>T:</strong></dt>
  <dd>1-bit flag. Set if the next octet is used as a TID. Defined in <xref target="RFC8505"/>.</dd>

  <dt><strong>TID and Registration Lifetime:</strong></dt>
  <dd>8-bit unsigned integer that tracks transactions for registrations. 
   It is incremented with each new transaction and ignored unless the T-flag is set. Defined in <xref target="RFC8505"/>.</dd>
  
   <dt><strong>Registration Lifetime:</strong></dt>
   <dd>16-bit integer representing the lifetime in minutes of the Registered Address.
      Zero indicates the registration has ended, and the associated state MUST be removed. Defined in <xref target="RFC8505"/>.</dd>

  <dt><strong>Registration Ownership Verifier (ROVR):</strong></dt>
  <dd>Variable length field, used to verify who "owns" a registered IPv6 address <xref target="RFC8505"/>. 
   When the C-flag is set, this field contains a Crypto-ID <xref target="RFC8928"/>.</dd>
   
</dl>

</section> <!-- end section "Updating RFC 8928" -->

<section><name>Security Considerations</name>
   <t>This specification does not introduce any new security considerations beyond those already discussed in <xref target="RFC8928"/> and <xref target="RFC8505"/>.</t>
</section> <!-- end section "Security Considerations" -->


<section ><name>IANA Considerations</name>

 <section><name>Bit Position of the C-flag</name>
	<t> 
   This specification updates the location of the C-flag introduced in <xref target=
    "RFC8928"/> to position it as bit 1 in the EARO flags field.
   IANA is requested to reference this RFC in addition to <xref target="RFC8928"/> when updating the "Address Registration Option
    Flags" <xref target="IANA.ICMP.ARO.FLG"/> registry under the heading
    "Internet Control Message Protocol version 6 (ICMPv6) Parameters" as
    specified in <xref target="AROflags"/>:
	</t>
   
	<table anchor="AROflags" ><name>Bit Position of the C-flag</name>
   <thead>
      <tr><td>ARO flag</td><td>Meaning</td><td>Reference</td></tr>
   </thead><tbody>
      <tr><td>1 (suggested)</td><td> C-Flag </td><td>RFC This and RFC 8928</td></tr>
   </tbody>
	</table>	<!-- end table "New  ARO flag" +-->
    </section>	<!-- end section "New ARO flag -->




</section>	<!-- end section "IANA Considerations" -->
<!-- 
<section title="Acknowledgments">
<t>
Many thanks to Dave Thaler and Dan Romascanu for their early INT-DIR review.
</t>
</section> title="Acknowledgments" -->


</middle>

<back>

    <references title="Normative References">
    
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
   <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"/>
   <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8928.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9010.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9685.xml"/>

            
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6lo-prefix-registration.xml"/>
    
       <reference anchor="IANA.ICMP.ARO.FLG">
       <front>
			<title>IANA Registry for the Address Registration Option Flags</title>
			<author>
				<organization>
					IANA
				</organization>
			</author>
			<date year=""></date>
		</front>
		<seriesInfo name="IANA," value="https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-adress-registration-option-flags"></seriesInfo>
	   </reference>
      

       <reference anchor="IANA.ICMP.ARO.STAT">
       <front>
			<title>IANA Registry for the Address Registration Option Status Value</title>
			<author>
				<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>

    </references>


    <references title="Informative References">
    
      <reference anchor="IEEE802154">
         <front>
            <title>IEEE Std 802.15.4, Part. 15.4: Wireless Medium Access
            Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate
            Wireless Personal Area Networks
            </title>
            <author>
               <organization>IEEE standard for Information Technology</organization>
            </author>
            <date/>
         </front>
      </reference>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml"/>
   <!-- <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.I-D.ietf-6lo-prefix-registration-10.xml"/> -->

 <!-- <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-ipv6-over-wireless.xml'/> -->
   


   </references>


</back>

</rfc>
