<?xml version="1.0" encoding="ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<rfc category="std" ipr="trust200902"
			docName="draft-thubert-6man-unicast-lookup-00"
            updates="8505">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<front> <title>IPv6 Neighbor Discovery Unicast Lookup</title>
    <author fullname="Pascal Thubert" initials="P.T." role="editor"
							surname="Thubert">
      <organization abbrev="Cisco Systems">Cisco Systems, Inc</organization>
      <address>
         <postal>
		 <street>Building D</street>
		 <street>45 Allee des Ormes - BP1200 </street>
            <city>MOUGINS - Sophia Antipolis</city>
            <code>06254</code>
            <country>FRANCE</country>
         </postal>
         <phone>+33 497 23 26 34</phone>
         <email>pthubert@cisco.com</email>
      </address>
    </author>
    
    <author fullname="Eric Levy-Abegnoli" initials="E.L.A."
							surname="Levy-Abegnoli">
      <organization abbrev="Cisco Systems">Cisco Systems, Inc</organization>
      <address>
         <postal>
		 <street>Building D</street>
		 <street>45 Allee des Ormes - BP1200 </street>
            <city>MOUGINS - Sophia Antipolis</city>
            <code>06254</code>
            <country>FRANCE</country>
         </postal>
         <phone>+33 497 23 26 20</phone>
         <email>elevyabe@cisco.com</email>
      </address>
    </author>
   <date/>

   <area>Internet</area>

   <workgroup>6man</workgroup>

   <abstract>
   <t>
    This document updates RFC 8505 in order to enable 
	unicast address lookup from a 6LoWPAN Border Router
    acting as an Address Registrar.
   </t>
   </abstract>
</front>

<middle>

<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="introduction" title="Introduction">
    <t>
    <xref target="RFC8505"/> defines the Routing Registrar and extends
    <xref target="RFC6775"/> to use a 6LoWPAN Border Router (6LBR) as a central
    service for Address Registration and duplicate detection amongst Routing
    Registrars and possibly individual Nodes that access it directly.
    </t>
    
    <t>
    <xref target="I-D.ietf-6lo-backbone-router"/> introduces the Backbone Router
    (6BBR) as a Routing Registrar that performs IPv6 ND <xref target="RFC4861"/>
    <xref target="RFC4862"/> proxy operation between IPv6 Nodes on a federating
    Backbone Link and Registering Nodes attached to a LowPower Lossy Networks
    (LLNs) that register their addresses to the 6BBR. The federated links form
    a Multilink Subnet (MLSN).
    </t>
    
    <t>
	The 6BBRs may exchange Extended Duplicate Address Messages (EDAR and EDAC)
    <xref target="RFC8505"/> to register the proxied addresses on behalf
    of the Registering Nodes to the 6LBR. 
    The Registration Ownership Verifier (ROVR) field in the EDAR and EDAC messages
    is used to correlate attempts to register the same address and to detect
    duplications. The ROVR can also be used as a proof-of-ownership
    (see <xref target="I-D.ietf-6lo-ap-nd"/>) to protect the Registered
    address against theft and impersonation attacks
    (more in <xref target="I-D.bi-savi-wlan"/>).
    Conflicting registrations to different 6BBRs for the same Registered address
    are resolved using the TID field, which creates a temporal order and enables
    to recognize the freshest registration.
	</t>
    
    <t>
    With <xref target="I-D.ietf-6lo-backbone-router"/>,
    the Link Layer address (LLA) that the 6BBR advertises for a Registered
    address on behalf of the Registered Node over the Backbone can belong to the
    Registering Node; in that case, the 6BBR acts as a Bridging Proxy and
    bridges the unicast packets.  Alternatively, the LLA can be that of the 6BBR
    on the Backbone interface, in which case the 6BBR acts as a Routing Proxy, 
	that receives the unicast packets at Layer-3 and routes them. The 6BBR 
    signals that LLA in a Source LLA Option (SLLAO) in the EDAR messages to the
    6LBR, and the 6LBR responds with a Target LLA Option (TLLAO) that indicates
    the LLA associated to the current registration. 
    </t>
    
    
	<t>
    It results that the 6LBR is capable of providing the LLA mapping for any
    address that was proactively registered with an SLLAO. This draft defines
    the protocol elements and the operations to try a unicast lookup with the
    6LBR. This may save a reactive IPv6 ND Neighbor Solicitation (NS) message,
    which is based on multicast and may be problematic in extensive wireless 
    domains (see <xref target="I-D.ietf-mboned-ieee802-mcast-problems"/>) as 
    well as in large switched fabrics.
    </t>
    
    
	<t>
    The registration and lookup services that the 6LBR provides do not have 
    to be limited to 6BBRs and are available to any node that supports
    <xref target="RFC8505"/> and <xref target="I-D.ietf-6lo-backbone-router"/> 
    to register an address, and / or this specification to resolve a mapping.
    The services are available on-link using an IPv6 NDP NS and off-link using 
    a new variation of the Extended Duplicate Address messages called Address 
    Mapping Messages. The policy and security settings that allow the access 
    to the 6LBR are out of scope.
    </t>
    

</section>	<!-- end section = "Introduction"  -->



<section title="Terminology">
  <section anchor='bcp' title="BCP 14">
  <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 "BCP 14" -->

  <section anchor='lo' title="References">
    <t>
	This document uses terms and concepts that are discussed in:
	<list style="symbols">
	<t> <xref target="RFC4861">"Neighbor Discovery for IP version 6"
		</xref> and
	    <xref target="RFC4862">"IPv6 Stateless address Autoconfiguration"
		</xref>,
    </t>
	<t> <xref target="RFC6775">Neighbor Discovery Optimization for Low-Power
		and Lossy Networks</xref>, as well as    
    </t>
    <t>
	    <xref target="RFC8505">
		"Registration Extensions for 6LoWPAN Neighbor Discovery"</xref> and
        <xref target="I-D.ietf-6lo-backbone-router">"IPv6 Backbone Router"
        </xref>.
	</t>
	</list>
    </t>
  </section> <!--	 end section "References" -->
  
  <section anchor='new' title="New Terms">
    <t>
	This document introduces the following terminology:
	<list hangIndent="6" style="hanging">
    
	<t hangText="Address Mapping Request">	<vspace blankLines="1"/>
	    An ICMP message with an ICMP type of 157 (DAR) and a Code Prefix of 1.
	</t>
	<t hangText="Address Mapping Confirm">	<vspace blankLines="1"/>
	    An ICMP message with an ICMP type of 158 (DAC) and a Code Prefix of 1.
	</t>
	<t hangText="Address Registrar">	<vspace blankLines="1"/>
	    The Address Registrar is an abstract database that is maintained by the 
        6LBR to store the state associated with its registrations.
	</t>
	<t hangText="Address Registration">	<vspace blankLines="1"/>
	    An Address Registration is an abstract state associated to one
        registration, in other words one entry in the Address Registrar.
	</t>
    
	</list>
    </t>
  </section>	<!-- end section "New Terms" -->

  <section anchor='acronyms' title="Acronym Definitions">
    <t> This document uses the following acronyms:
       <list hangIndent="6" style="hanging" >
       <t hangText="6BBR:"> 6LoWPAN Backbone Router </t>
       <t hangText="6LBR:"> 6LoWPAN Border Router </t>
       <t hangText="6LR:"> 6LoWPAN Router </t>
       <t hangText="6CIO:"> Capability Indication Option </t>
       <t hangText="AMC:"> Address Mapping Confirmation </t>
       <t hangText="AMR:"> Address Mapping Request</t>
       <t hangText="ARO:"> Address Registration Option</t>
       <t hangText="DAC:"> Duplicate Address Confirmation </t>
       <t hangText="DAD:"> Duplicate Address Detection </t>
       <t hangText="DAR:"> Duplicate Address Request</t>
       <t hangText="EDAC:"> Extended Duplicate Address Confirmation  </t>
       <t hangText="EDAR:"> Extended Duplicate Address Request</t>
       <t hangText="DODAG:"> Destination-Oriented Directed Acyclic Graph </t>
       <t hangText="LLN:"> Low-Power and Lossy Network </t>
       <t hangText="NA:">  Neighbor Advertisement </t>  
       <t hangText="NCE:">  Neighbor Cache Entry  </t>
       <t hangText="ND:">  Neighbor Discovery  </t>
       <t hangText="NS:">  Neighbor Solicitation  </t>
       <t hangText="ROVR:"> Registration Ownership Verifier </t>
       <t hangText="RA:">  Router Advertisement  </t>
       <t hangText="RS:">  Router Solicitation  </t>
       <t hangText="TID:"> Transaction ID </t>
       </list>
    </t>

  </section>	<!-- end section "Acronym Definitions" -->


</section>	<!-- end section "Terminology" -->



<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->

<section anchor='overview' title="Overview">

    <t>
    <xref target="figBackbone"/> illustrates a Backbone Link that federates a 
    collection of LLNs as a single IPv6 Subnet, with a number of 6BBRs
    providing proxy-ND services to their attached LLNs. 
    </t>
    <t>
    A collection of IPv6 Nodes are present on the Backbone and use IPv6 ND
    <xref target="RFC4861"/><xref target="RFC4862"/> procedures for 
    DAD and Lookup.
    </t>
    <t>
	The LLN may be a hub-and-spoke access link such	as (Low-Power) 
    IEEE STD. 802.11 (Wi-Fi) <xref target="IEEEstd80211"/>
	and IEEE STD. 802.15.1 (Bluetooth) <xref target="IEEEstd802151"/>,
    or a Mesh-Under or a Route-Over network <xref target="RFC8505"/>.
    </t>
    
    <figure anchor='figBackbone' title="Backbone Link and 6LBR">
    <artwork><![CDATA[
                 |
              +-----+               +-----+       +-----+
    (default) |     |          6LBR |     |       |     | IPv6 
       Router |     |               |     |       |     | Node
              +-----+               +-----+       +-----+
                 |  Backbone side      |             | 
     ----+-------+-----------------+---+-------------+----+-----
         |                         |                      |
      +------+                 +------+                +------+
      | 6BBR |                 | 6BBR |                | 6BBR |
      |      |                 |      |                |      |
      +------+                 +------+                +------+
         o     Wireless side   o   o  o                  o o
     o o   o  o            o o   o  o  o             o  o  o  o o
    o  o o  o o            o   o  o  o  o            o  o  o o o
    o   o  o  o               o    o  o               o  o   o
      o   o o                    o  o                     o o

      LLN                        LLN                      LLN
    ]]></artwork></figure>


    <t>   
    A 6LBR provides registration services for the purpose of proactive IPv6 ND
    and maintains a registry of the active registrations as an abstract data
    structure called an Address Registrar.
    An entry in the Address Registrar is called an "Address Registration".
    </t>

    <t> 
    The Address Registration retains:
    <list style="symbols">
        <t>
        the value for the ROVR associated to the registration, the current
        value of the TID, and the remaining Lifetime.
        </t>
        <t>
        a list of LLAs that are associated with the IPv6 address and can be
        used in a TLLAO as a response to a lookup. 
        </t>
    </list>
    Examples where more than one address may be available include the case of
    an anycast address and the case of an LLN address that is proxied by more
    than one 6BBR. 
    </t>

    <t> 
	Unless otherwise configured, a 6LBR does the following:
	<list style="symbols">
        <t>
        The 6LBR maintains an entry in the Address Registrar for any type of
        unicast and anycast addresses including those with link-local scope.
        </t>
        <t>
        Based on that entry, it provides duplicate avoidance services within the
        scope of its Address Registrar.
        </t>
        <t>
        The 6LBR also provides address lookup services for the Registered
        Address using unicast ICMPv6 DAR and DAC-based Address Mapping messages.
        </t>
    </list>
    The Address Mapping messages can be exchanged using global unicast
    addresses as source and destination addresses, so they can be used for
    both on-link and off-link queries.
    NS and NA messages may also be used, but in that case the unicast source
    and destination addresses are link-local addresses and the 6LBR must be
    on-link. 
    </t>
    
    <t>   
    The 6LBR proactive operations may coexist on the Backbone with reactive 
    IPv6 ND <xref target="RFC4861"/><xref target="RFC4862"/> that rely on 
    multicast for Duplicate Address Detection (DAD) and Address Lookup. 
    Nodes that support this specification operate with the 6LBR before
    attempting the reactive operation, which may be avoided if the 6LBR
    is conclusive, either detecting a duplication or returning a mapping.
    </t>
    
</section> <!-- anchor='overview' title="Overview" -->



<section anchor='updating' title="Updating RFC 8505">

   <t>
	This specification leverages the capability to insert IPv6 ND options in
	the EDAR and EDAC messages that was introduced in
    <xref target="I-D.ietf-6lo-backbone-router"/>.
   </t>
   
   <t>
	It extends DAR and DAR ICMP messages for address lookup
    in <xref target="DAM"/> that use the same ICMP types as EDAR and EDAC but a
    different Code Prefix. 
   </t>
   
   <t>
    It also adds a new Status "Not Found" in
    <xref target="earo"/>) that indicates that the address being searched is 
    not present in the Address Registrar.
   </t>

   <t>
   A 6LBR signals itself by setting the "B" bit in the 6CIO of the RA
   messages that it generates <xref target="RFC8505"/>. 
   This specification adds a new "A" bit in the 6CIO to indicate support of
   address mapping (see <xref target="CIO"/>). 
   </t>
   
   
<section anchor='option'
	title="Extended Neighbor Discovery Options and Messages">
    
   <t>This specification does not introduce new options; it modifies
   existing options and updates the associated behaviors.</t>

    <section anchor='CIO'
       title="Extending the Capability Indication Option">
    <t>
	This specification defines a new capability bit for use in the 6CIO, as
	defined by <xref target="RFC7400"/> and extended in<xref target="RFC8505"/>
    for use in IPv6 ND messages.
    </t>
    <t>
	The new "A" bit indicates that the 6LBR provides address mapping
    services per this specification.    
    </t>
    <figure anchor='fig6CIO' title="New Capability Bits in the 6CIO">
    <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    |A|D|L|B|P|E|G|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ]]></artwork>
    </figure>

    <t> Option Fields:
	<list style='hanging'>
	<t hangText="Type:"> 36 </t>
	<t hangText="A:"> The 6LBR provides address mapping services.  </t>
	</list>
    </t>
    </section>	<!-- end section "Extending the Capability Indication Option" -->


    <section anchor='DAM'
        title="New Code Prefix for Address Mapping Messages">
    <t>
	The Extended Duplicate Address messages share a common base format defined
    in section 4.2 of <xref target="RFC8505"/>, with the ICMP type respectively
    set to 157 and 158 that is inherited from the DAR and DAC messages defined
    in section 4.4 of <xref target="RFC6775"/>. The ICMP Code is split in two
    4-bit fields, the Code Prefix and the Code Suffix, and the only Code 
    Prefix defined in <xref target="RFC8505"/> is 0, signaling a DAD.
    </t>
    <t>    
    The Address Mapping messages use the same values for the ICMP Type as the
    corresponding Extended Duplicate Address messages.
    This specification adds the Code Prefix of 1 to signal Address Mapping.
    ICMP messages with the ICMP type set to 157 or 158, and a Code Prefix of 1
    are thus respectively an Address Mapping Request (AMR) and an Address
    Mapping Confirm (AMC).
    </t>
    </section><!-- end section "New Code Prefix for Address Mapping Messages" -->

    <section anchor="earo" title="New ARO Status">
    <t>	
    The Extended Address Registration Option (EARO) is defined in section 4.1
    of <xref target="RFC8505"/>. It contains a Status field that is common with
    with the EDAR and EDAC messages defined in section 4.2 of
    <xref target="RFC8505"/>. 
    This specification defines a new Status "Not Found" as indicated in
    <xref target="AROstatus"/>
    </t>
	<texttable anchor="AROstatus" title="EARO Status" >
	  	<ttcol align="center">Value</ttcol>
	  	<ttcol align="left">Description </ttcol>

	<c> 0..10 </c> 
    <c>As defined in <xref target="RFC6775"/> and <xref target="RFC8505"/>.</c>
	<c> 11 </c> <c>Not Found: The address is not present in the Address Registrar (value to be confirmed by IANA)</c>
	</texttable> <!-- end table "EARO Status" -->

    <t>
    The Status of "Not Found" can be used in an NA(EARO) and in an AMC messages
    as a response to an address lookup operation.
    </t>
    
    </section><!-- end section "New ARO Status"-->

   
</section>	<!-- end section "Extended ND Options And Messages" -->


    <section anchor="am" title="Address Mapping Messages">
    <t>
    A 6LBR signals that support by setting the "B" bit in the 6CIO of the RA
    messages that it generates. 
    A 6LBR that supports this specification MUST also set the "A" bit, indicating support of the Address Mapping messages for address lookup. 
    </t>
    
    <t>
    In the Address Mapping flow, the querier IPv6 Node uses an AMR message,
    which is characterized by an ICMPv6 Type of 157 and a Code Prefix of 1.
    When used on-link, the AMR message SHOULD carry a SLLAO indicating the LLA
    of the querier.
    The Code Suffix MUST be set to 0 indicating a ROVR Length of 64 bits. The
    ROVR, TID and Lifetime fields MUST be set to 0 and ignored by the receiver.
    </t>
    

    <t>
    The 6LBR MUST respond with an AMC message, which is characterized by an
    ICMPv6 Type of 158 and a Code Prefix of 1.
    <list style="symbols">
       <t> If the address is not present in the Address Registrar then the 6LBR 
       MUST set the status to "Not Found". The Code Suffix MUST be set to 0 
       indicating a ROVR Length of 64 bits. The ROVR, TID and Lifetime fields
       MUST be set to 0 and ignored by the receiver.
       </t>
       <t>
       Else if the address is present in the Address Registrar then the AMC
       fields MUST be set from the ROVR, TID and remaining Lifetime values in
       the Address Registration and the Status MUST be set to 0.
       </t>
       <t>
       If at least one LLA is found in the Address Registration, then the 6LBR
       MUST place one in a TLLAO option in the AMC message.
       </t>
    </list>
    The AMC is sent unicast the 6LBR to the querier. 
    </t>
    </section>	<!-- end section "Extended Duplicate Address Messages" -->
    
    <section anchor="nd" title="IPv6 ND-based Address Lookup">
    
    <t>
    A 6LBR that is deployed on-link SHOULD provide NS/NA-based services. It
    signals that support by setting the "L" bit in the 6CIO of the RA
    messages that it generates, indicating that it is a 6LR
    <xref target="RFC8505"/>. 
    </t>
    
    <t>
    A 6LBR thus typically sets the "A", the "B", and the "L" bits when
    attached to a Backbone Link that it serves, as illustrated in
    <xref target='figBackbone'/>. In that case, the IPv6 Nodes and 6BBRs can
    use an NS/NA exchange with the 6LBR for both duplicate detection and lookup
    services.       
    </t>
    
    <t>
    The NS(Lookup) is sent unicast from link-local address of the querier to 
    the link-local address of the 6LBR. It carries a SLLAO
    <xref target="RFC4861"/> and it MUST NOT carry an EARO option to avoid the 
    confusion with a registration.
    </t>
    
    <t>
    The 6LBR MUST respond with an NA message that contains an EARO. 
    <list style="symbols">
       <t> If the address is not present in the Address Registrar then the 6LBR 
       MUST set the status to "Not Found". The ROVR, TID and Lifetime fields
       MUST be set to 0 and ignored by the receiver.
       </t>
       <t>
       Else if the address is present in the Address Registrar then the EARO 
       fields MUST be set from the ROVR, TID and remaining Lifetime values in
       the Address Registration and the Status MUST be set to 0.
       </t>
       <t>
       If at least one LLA is found in the Address Registration, then the 6LBR
       MUST place one in a TLLAO option in the NA message.
       </t>
    </list>
    The NA is sent unicast from link-local address of the 6LBR to the link-local address of the querier. 
    </t>
    
    </section><!-- anchor="nd" title="IPv6 ND-based Address Lookup"-->
    
      
</section> <!-- end section "Updating RFC 8505"-->

<section anchor="back" title="Backward Compatibility">
</section>	<!-- end section "Backward Compatibility" -->

<section  anchor="sec" title="Security Considerations">
<t>
    This specification extends <xref target="RFC8505"/>, and
    the security section of that document also applies to this document.
    In particular, the link layer SHOULD be sufficiently
    protected to prevent rogue access.
<!--  CEP: That is a strong assumption.  Any estimate on how many 802.15.4
		 		devices could support it?   -->
</t>
</section>	<!-- end section "Security Considerations" -->


<section title="IANA Considerations">
<t>
    <list style="empty">
    <t>
	Note to RFC Editor, to be removed: please replace "This RFC"
	throughout this document by the RFC number for this specification
	once it is allocated.
    </t>
    </list>
</t>
<t>
    IANA is requested to make a number of changes under the
    "Internet Control Message Protocol version 6 (ICMPv6) Parameters"
    registry, as follows.
</t>

    <section title="ICMP Codes">
    <t>
	IANA is requested to create 2 new subregistries of the ICMPv6 "Code"
        Fields registry, which itself is a subregistry of the Internet Control
        Message Protocol  version 6 (ICMPv6) Parameters for the ICMP codes.
        </t>
    <t>

        The new subregistries relate to the ICMP type
        157, Duplicate Address Request (shown in <xref target="DARcode"/>), and
        158, Duplicate Address Confirmation (shown in <xref target="DACcode"/>),
        respectively. For those two ICMP types, the ICMP Code field is split
	into 2 subfields, the "Code Prefix" and the "Code Prefix".  The new
	subregistries relate to the "Code Prefix" portion of the ICMP Code.
        The range of "Code Prefix" is 0..15 in all cases.
        The policy is "IETF Review" or "IESG Approval" <xref target="RFC8126"/>
        for both subregistries.
    </t>
    <t>
        The new subregistries are to be initialized as follows:
    </t>

    <texttable anchor="DARcode"
        title="New Code Prefixes for ICMP type 157 DAR message">
      <!-- <preamble> New Code Prefixes for ICMP types 157 DAR message </preamble> -->
      		<ttcol align="left"> Code Prefix </ttcol>
      		<ttcol align="left"> Meaning </ttcol>
      		<ttcol align="left"> Reference </ttcol>
      <c>0</c> <c>Duplicate Address Detection</c>	<c>RFC 6775</c>
      <c>1</c> <c>Address Mapping</c>	<c>This RFC</c>
      <c>2...15</c>  <c>Unassigned</c>	<c></c>
    </texttable>     <!-- end table "New Code Prefixes for the DAR message" -->

    <texttable anchor="DACcode"
        title="New Code Prefixes for ICMP type 158 DAC message">
      <!-- <preamble> New Code Prefixes for ICMP types 158 DAC message </preamble> -->
      		<ttcol align="left"> Code Prefix </ttcol>
      		<ttcol align="left"> Meaning </ttcol>
      		<ttcol align="left"> Reference </ttcol>
      <c>0</c> <c>Duplicate Address Detection</c>	<c>RFC 6775</c>
      <c>1</c> <c>Address Mapping</c>	<c>This RFC</c>
      <c>2...15</c>  <c>Unassigned</c>	<c></c>
    </texttable>    <!-- end table "New Code Prefixes for the DAC message" -->

    <!--t>Also, all even values of the Code field are reserved for the
    ICMP types above, and should not be assigned in the future.</t-->

    </section>	<!-- end section "ICMP Codes" -->

    <section title="New ARO Status values">
	<t> IANA is requested to make additions to the Address Registration
	    Option Status Values Registry as follows:
	</t>

	<texttable anchor="AROstat" title="New ARO Status values">
	<!-- <preamble>Address Registration Option Status Values Registry</preamble> -->
	  			<ttcol align="center"> ARO Status </ttcol>
	  			<ttcol align="left"> Description </ttcol>
	  			<ttcol align="left"> Document </ttcol>
	  <c>11</c>   <c>Not Found</c>			<c>This RFC</c>
	</texttable>	<!-- end table "New ARO Status values" +-->
    </section>	<!-- end section "New ARO Status values" -->

    <section title="New 6LoWPAN Capability Bits">
	<t>
	    IANA is requested to make additions to the Subregistry for
	    "6LoWPAN Capability Bits" as follows:
	</t>

	<texttable anchor="CIOdat" title="New 6LoWPAN Capability Bits">
	<!-- <preamble> Subregistry for "6LoWPAN Capability Bits" under the -->
	    <!-- "Internet Control Message Protocol version 6 (ICMPv6) Parameters" -->
	<!-- </preamble> -->
	  			<ttcol align="center"> Capability Bit </ttcol>
	  			<ttcol align="left"> Description </ttcol>
	  			<ttcol align="left"> Document </ttcol>
	  <c>9</c>  <c>AM  Support (A bit)</c>    <c>This RFC</c>
	</texttable>	<!-- end table "New 6LoWPAN Capability Bits" -->
    </section>	<!-- end section "New 6LoWPAN Capability Bits" -->
</section>	<!-- end section "IANA Considerations" -->

<section title="Acknowledgments">
<t>

</t>
</section> <!-- title="Acknowledgments" -->







</middle>

<back>
    <references title='Normative References'>
	<!-- RFC  -->
	<?rfc include='reference.RFC.2119.xml'?>
	<?rfc include='reference.RFC.4861.xml'?>
	<?rfc include='reference.RFC.4862.xml'?>
	<?rfc include='reference.RFC.6775.xml'?>
	<?rfc include='reference.RFC.7400.xml'?>
	<?rfc include='reference.RFC.8126.xml'?>
	<?rfc include='reference.RFC.8174.xml'?>
	<?rfc include='reference.RFC.8505.xml'?>

    </references>


    <references title='Informative References'>
	<!-- RFC  -->

    <!-- I-D -->
	<?rfc include='reference.I-D.ietf-6lo-backbone-router.xml'?>
	<?rfc include='reference.I-D.ietf-mboned-ieee802-mcast-problems.xml'?>
	<?rfc include='reference.I-D.ietf-6lo-ap-nd.xml'?>
	<!--?rfc include='reference.I-D.ietf-6tisch-terminology.xml'?-->
    <?rfc include='reference.I-D.bi-savi-wlan.xml'?>
    
      <reference anchor="IEEEstd80211">
         <front>
            <title>IEEE Standard for Information technology --
		Telecommunications and information exchange between systems
		Local and metropolitan area networks-- Specific requirements
		Part 11: Wireless LAN Medium Access Control (MAC) and Physical
		Layer (PHY) Specifications
            </title>
            <author>
               <organization>
		IEEE standard for Information Technology</organization>
            </author>
            <date/>
         </front>
      </reference>
    
      <reference anchor="IEEEstd802151">
         <front>
            <title> IEEE Standard for Information Technology -
		Telecommunications and Information Exchange Between Systems -
		Local and Metropolitan Area Networks - Specific Requirements. -
		Part 15.1: Wireless Medium Access Control (MAC) and Physical
		Layer (PHY) Specifications for Wireless Personal Area Networks
		(WPANs)
            </title>
            <author>
            	<organization> IEEE standard for Information Technology
		</organization>
            </author>
            <date/>
         </front>
      </reference>
      
    </references>

</back>

</rfc>
