<?xml version="1.0" encoding="ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC3115 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3115.xml">
<!ENTITY RFC3963 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3963.xml">
<!ENTITY RFC3971 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4389 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4389.xml">
<!ENTITY RFC4429 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4429.xml">
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4887 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4887.xml">
<!ENTITY RFC4903 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4903.xml">
<!ENTITY RFC4919 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4919.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC6550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6550.xml">
<!ENTITY RFC6282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml">
<!ENTITY RFC6275 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml">
<!ENTITY RFC6620 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6620.xml">
<!ENTITY RFC6775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6775.xml">
<!ENTITY I-D.ietf-ipv6-multilink-subnets SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ipv6-multilink-subnets.xml">
<!ENTITY I-D.ietf-roll-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-terminology.xml">
<!ENTITY I-D.chakrabarti-nordmark-6man-efficient-nd SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chakrabarti-nordmark-6man-efficient-nd.xml">
<!ENTITY I-D.thubert-6lowpan-backbone-router SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thubert-6lowpan-backbone-router.xml">


]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<rfc category="std" ipr="trust200902" docName="draft-thubert-6man-wind-sail-00">

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?> 

    <front>
        <title abbrev="WiND-SAIL">Wireless Neighbor Discovery Stateful Address Identification and Location exchange</title>
        <author initials="P" surname="Thubert" fullname="Pascal Thubert">
          <organization abbrev="Cisco">
             Cisco Systems
          </organization>
          <address>
            <postal>
             <street>Village d'Entreprises Green Side</street>
             <street>400, Avenue de Roumanille</street>
	     <street>Batiment T3</street>
             <city>Biot - Sophia Antipolis</city>
             <code>06410</code>
             <country>FRANCE</country>
            </postal>
            <phone>+33 4 97 23 26 34</phone>
            <email>pthubert@cisco.com</email>
	  </address>
        </author>
        <author initials="E" surname="Levy-Abegnoli" fullname="Eric Levy-Abegnoli">
          <organization abbrev="Cisco">
             Cisco Systems
          </organization>
          <address>
            <postal>
             <street>Village d'Entreprises Green Side</street>
             <street>400, Avenue de Roumanille</street>
	     <street>Batiment T3</street>
             <city>Biot - Sophia Antipolis</city>
             <code>06410</code>
             <country>FRANCE</country>
            </postal>
            <phone>+33 4 97 23 26 34</phone>
            <email>elevyabe@cisco.com</email>
	  </address>
        </author>
        <date/>

	<area>Internet</area>

	<workgroup>6MAN</workgroup>

        <abstract>
	  <t>
	    This draft proposes an extension to IPv6 Neighbor Discovery
		to exchange Stateful Address Identification and Location between
		State Maintaining Entities located over a backbone link about
		attached nodes that are attached to the backbone via a Wireless
		Link, in order to maintain all the entities up-to-date and 
		maintain reachability as the attached nodes move.
	  </t>
	</abstract>
    </front>

    <middle>

	<!-- **************************************************************** -->
	<!-- **************************************************************** -->
	<!-- **************************************************************** -->
	<!-- **************************************************************** -->
	<section anchor='introduction' title="Introduction">
	  <t>
	<xref target="RFC4861">"Neighbor Discovery for IP version 6"</xref> (IPv6 ND)
	relies heavily on multicast signaling messages on the local Link. 
	Conceptually, multicast is supposed to avoid broadcast messages, but, in most 
	practical cases, its operation at the link level is that of a broadcast. 
	This did not matter much at the time ND was originally designed, when an 
	Ethernet network was more or less a single shared wire, but since then, 
	large scale switched fabrics, low-power sleeping devices, mobile wireless 
	devices and virtual machines have changed the landscape dramatically. 
	</t>
    <t>
	The overhead of multicast in IPv6 ND has become significant and is now a major 
	annoyance in multiple scenarios, in particular for wireless nodes.
        With WIFI, a multicast message will consume the wireless link on all Access Points 
	around a switched fabric and will be transmitted at the lowest speed possible in
	order to ensure the maximum reception by all other wireless nodes. 
	This means that in an environment where bandwidth is scarce, a single multicast 
	packet may consume the bandwidth for hundreds of unicast packets. 
	Sadly, IPv6 ND is a major source of multicast messages in wireless devices, since 
	such messages are triggered each time a wireless device changes its point of attachment.  

	</t>
    <t>
        A similar situation can be seen in a datacenter, where Virtual Machine (VM) mobility 
	also triggers floods of multicast messages, which become a major hassle as the number 
	of VMs grows to the tens of thousands and above. At the IETF, a Working Group was
	created to discuss Address Resolution in Massive Datacenters (ARMD), but the work 
	did not go to completion. The problem with IPv6 ND multicast is still present, only 
	getting worse as the scale and degree of mobility augments with the massive 
	introduction of new mobile devices such as virtualized appliances, IoT and BYOD.

	</t>
    <t>
	At the same time, the need to better control the ownership, utilization and location 
	of IP addresses has become predominant in managed networks. The Source-Address Validation
	Improvements (SAVI) Working Group has proposed methods to locate, validate the 
	ownership, and police the utilization of IPv6 addresses by snooping IPv6 ND and 
	DHCP operations.
	But snooping requires being on the path of the protocols and is limited in 
	particular in and for unicast responses.
	</t>
    <t>
    Mobile nodes such as BYOD may change their point of attachment in the network but
	an eventual renumbering can be disruptive to existing connections. 
	Virtual devices - typically VMs in a datacenter - also move though in a different
	fashion, from a physical device to the next. In any case, the need to maintain a
    same IPv6 address across movements implies the creation of very large, eventually
    multi-link, subnets. In such a large subnet, it might be difficult with the existing
	protocols to differentiate duplication from a rapid sequence of movements. 	
	And if it is indeed a sequence of movements, then it might be difficult to select 
	the freshest information, and additional signaling is required to obtain the actual 
	location of an address in a deterministic fashion. 

		</t>
    <t>
	In a modern managed switched fabric, a number of devices host IPv6 State Maintaining
	Entities (6SMEs) that hold Stateful Address Identification and Location (SAIL)
        information about the entity that owns an IPv6 address. 
        A 6SME needs to reascertain periodically the state that it maintains and eliminate stale
	information. It is of common interest between all 6SMEs to share their information 
	and help one another learn new state, update existing state and remove stale state rapidly.
	A Binding Table maintained by a secured registration protocol is certainly a more robust 
	basis for 6SME activity than a classical  <xref target="RFC4861"> IPv6 NDP </xref>  Neighbor 
	Cache management coupled with protocol snooping as currently found with 
	<xref target="RFC6620">SAVI</xref>.
	</t>
    <t>
	<xref target="RFC6275"> Mobile IPv6</xref> introduced such a registration protocol to 
	maintain a tunnel and enable an IPv6 ND proxy operation over a Home Network. 
	Applied to IPv6 Neighbor Discovery, the registration model
	balances the benefits of distributed StateLess Address AutoConfiguration (SLAAC) 
	<xref target="RFC4862"/> for scalability and autonomic behaviours with the capability
	to reject or recuse an autoconfigured address on an exception basis - based for
	instance on administrative policies -, which is a desired feature for managed networks 
	that classically are operated with <xref target="RFC3115"> DHCPv6 </xref>.
	In that sense, the ND registration allows a scalable hybrid of managed and
	non-managed networks while minimizing the total number of multicast messages 
	between hosts, as well as between hosts and routers.
	</t>
	 <t>
        An IPv6 ND registration mechanism was standardized as <xref target="RFC6775"> 
	Neighbor Discovery Optimization for Low-power and Lossy Networks</xref>.
	The host to SME router operation is generalized by wireless ND 
	<xref target="I-D.chakrabarti-nordmark-6man-efficient-nd"/> for devices that
	are not necessarily attached to a LLN but may still benefit from registration.
	<xref target="RFC6775"/> also introduces a protocol between SMEs based on new
	ICMP messages. This draft extends that model in order to allow for a distributed,
	eventually hierarchical set of SMEs to share and maintain SAIL states.
	</t>
	<!--t> This draft suggests an extension to the IPv6 ND protocol to query, publish and subscribe to
	location information related to an IPv6 address, including in particular layer 2 (MAC) address mapping.
	The extension includes an additional option that will carry a coarse grained age as well as 
	meta information about the SAIL state, that is required between SMEs but not needed in ND operation
	from the original device.  
	  </t-->
	  		
</section>

        <section title="Terminology">
            <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
            "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
            and "OPTIONAL" in this document are to be interpreted as
            described in <xref target="RFC2119"/>.</t>

	    <t>Readers are expected to be familiar with all the terms and concepts
	    that are discussed in <xref target="RFC4861">"Neighbor Discovery for
	    IP version 6"</xref>, <xref target="RFC4862">"IPv6 Stateless Address
	    Autoconfiguration"</xref>, <xref target="RFC4919">"IPv6 over Low-Power
	    Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
	    Problem Statement, and Goals"</xref>,
		 <xref target="RFC6775">Neighbor Discovery Optimization 
		 for Low-power and Lossy Networks</xref> and 
		 <xref target="I-D.ietf-ipv6-multilink-subnets">
		 "Multi-link Subnet Support in IPv6"</xref>.
           </t>
	    <t>Readers may benefit from reading the <xref target="RFC6550"> "RPL: 
		IPv6 Routing Protocol for Low-Power and Lossy Networks" </xref> specification;
		<xref target="RFC4903">"Multi-Link Subnet Issues"</xref>;
		<xref target="RFC6275"> "Mobility Support in IPv6" </xref>; <xref target="RFC4389">
	    "Neighbor Discovery Proxies (ND Proxy)" </xref>; <xref target="RFC6620">"FCFS
              SAVI: First-Come, First-Served Source Address Validation Improvement for 
			  Locally Assigned IPv6 Addresses"</xref>; and
	    <xref target="RFC4429">"Optimistic Duplicate Address Detection"
	    </xref> prior to this specification for a clear
	    understanding of the art in ND-proxying and binding.</t>
	   <t>Additionally, this document uses terminology from <xref
      target="I-D.ietf-roll-terminology"></xref>, and reuses or introduces the
            following terminology:
	  <list hangIndent="6" style="hanging">

	   <t hangText="6LoWPAN Router (6LR):"> Please refer to <xref target="RFC6775"/>.</t>
	   <t hangText="6LoWPAN Border Router (6LBR):"> Please refer to <xref target="RFC6775"/>.</t>
	   <t hangText="DAR and DAC messages:"> Please refer to <xref target="RFC6775"/>.</t>
	   <t hangText="Multi-link subnet:"> Please refer to  <xref target="I-D.ietf-ipv6-multilink-subnets"/>.</t>
	
	   <t hangText="Backbone:">A link that forms the core of a multi-link subnet.
	   All ARs and legacy devices are connected to the Backbone and classical
	   ND operation ensure connectivity over that link. 
	    </t>
		<t hangText="attached link:">
	        An abstract link in a multi-link subnet other than the backbone.
			That link is classically not implemented as a fixed wire, and may
			only provide non-continuous connectivity, in particular with support
			for mobility. An attached link may be for instance a classical WiFi
			(IEEE802.11) link, a link in a wireless mesh network, or an overlay tunnel.
		</t>
		<t hangText="attached node:">
	    A device in a multi-link subnet that is not directly connected to the Backbone 
		but reachable via an attached link.
		</t>
	
	   <t hangText="Backbone Router (BBR):">
	    A BBR is an IPv6 router that connects attached links to a Backbone link
		and enables the connectivity of an attached node by proxying IPv6 NDP 
		over the Backbone for that node, either with the node MAC address, 
		or its own. 
		The BBR is a 6SME that can obtain attachment states from attached nodes by
		different methods, for instance by snooping IPv6 NDP or DHCPv6, by learning
		host routes acting as a RPL root, by accepting ND registrations acting as an AR or
		an IR.
           </t>
 	  <t hangText="Stateful Address Identification and Location (SAIL):">
             As opposed to a cache entry, a SAIL state is Stateful in that it is obtained
	     and maintained through a (secured) registration mechanism.
             A SAIL state may include for instance a secured identification of the owner
             of the address (e.g. a trusted token, a public key or a certificate), 
	     the position of the IPv6 address in the network (e.g. VLAN, Access Switch
	     or Access Point), or the mapping of the IPv6 address with a MAC address. 
	     Some of this information may be stable, for instance a owner Identification,
             while other may be transient, for instance the Access Point identifier in a
             mobility scenario or the MAC address mapping in the case of NDP proxy operations.
	    </t>
          <t hangText=" State Maintaining Entity (SME):">An entity that hold SAIL information. SMEs
            are implemented in devices such as security appliances such as Network Access Controllers (NACs),
	    SAVI switches that protect the ownership of an IPv6 address and control the ingress 
	    of the network, Wireless LAN Controllers (WLCs) that terminate a CAPWAP tunnel and 
    	must rapidly re-enable reachability for a mobile device both at layer 2 and layer 3, 
	    as well as overlay terminators such as used for network virtualization (NVO3).
	    Overlay termination may operate both at layer 2 or layer 3, and may be found in data
	    centers and enterprise networks to support mobility or extend the layer 2 fabric over
	    a Layer 3 infrastructure, as well as in Service Provider networks to support IPv6 mobility. 
	 </t>
	   <t hangText="Binding:">
	   The association of an IPv6 address with some SAIL state. A registrar maintains a
           binding table to store and query such associations.
	    </t>

	   <t hangText="Registering Node (RN):">
	     An IPv6 node that obtains and retains ownership of an IPv6 address through the 
		 process of IPv6 ND registration.
	    </t>
	   <t hangText="Authoritative Registrar (AR):">
	     A 6SME that stores authoritative information about a registration.
		 An AR is the reference for address and SAIL state binding within its 
		 domain of authority, e.g. a specific subset of addresses within a subnet.
		 There can be multiple ARs in a subnet and domains may overlap for redundancy 
		 and balancing.
	    </t>
	   <t hangText="Intermediate Registrar (IR):">
	     A 6SME  that stores information about a registration as part of the registration
		 flow. IRs form a directed acyclic graph (DAG) that is directed towards ARs. 
                 A registration from an RN will be addressed to an IR and will follow the IR
                 DAG till it reaches a node that can grant the ownership, typically a AR. 

	    </t>
	   <t hangText="Registration Interface (RIF):">
	     The interface between an RN and an IR. 
		 The RIF is typically implemented
		 using Wireless ND, but can also be implicitely implemented
		 by snooping IPv6 ND, e.g. as suggested by SAVI.
	    </t>
	   <t hangText="Validation Interface (VIF):">
	     The interface between a child IR and a parent IR or AR.
		 The VIF is typically implemented using this specification 
		 which extends the DAR and DAC messages as defined in  
		 <xref target="RFC6775"/>.
	    </t>
	   <t hangText="Determination Interface (DIF):">
	     The interface between ARs. It can be implemented using LISP, 
		 routing protocol extensions, or using IPv6 ND proxy extensions such
		 as suggested by <xref target="I-D.thubert-6lowpan-backbone-router"/> .		 

	    </t>
	    </list>
	   </t>
        </section>


	<!-- **************************************************************** -->
	<section anchor='overview' title="Overview">
	


	   <t>
	          The scope of this draft is a potentially large and potentially 
            multi-link subnet <xref target="I-D.ietf-ipv6-multilink-subnets"/> 
			formed by a high speed Backbone that federates additional links
			of heterogeneous MAC/PHY types, for instance an Ethernet switched fabric
			federating a Route-Over mesh that may interconnect thousands of LLN
			devices over multiple wireless hops.		 

           </t>
			<t> 
		 In order to avoid floods of multicast packets inherent to a reactive discovery,
		 a node - referred to as a Registering Node (RN) - needs to claim its addresses 
		 proactively, binding them with its location in the network and a Lower Layer Address
		 (LLA), over confirmed exchanges with a neighborhood Intermediate Registrar (IR).

		 
		 <figure anchor='figIRAR'
 title="Backbone Link, IRs and ARs">
<artwork><![CDATA[
            +-----+                   +-----+
            |     | AR                |     | AR
            |     |                   |     | ND proxy
            +-----+                   +-----+
               |                         |
               |      Backbone Link      |
         +--------------------+------------------+
         |     legacy + proxy | + registration   |
         |              mixed | ND operations    |
      +-----+              +-----+            +-----+
      |     |IR            |     |IR          |     | IR + AR
      |     |ND proxy      |     |            |     | ND proxy
      +-----+              +-----+            +-----+
	     |     routing over attached links       |
	     |   registration ND operations only     |
      +-----+              +-----+            +-----+
      |     |IR            |     |IR          |     | IR 
      |     |--------------|     |------------|     | 
      +-----+              +-----+            +-----+
]]></artwork>
</figure>
            The IR may confirm the claim with an Authoritative Registrar (AR), eventually 
		 over a graph of other IRs. If the ownership is granted, the RN may use the
		 address for a lifetime that is associated with the grant, at which point it will
		 need to reconfirm the address by registering again.
           </t>
			<t>	 
		 In the case of a meshed 6LoWPAN <xref target="RFC6282"/> <xref target="RFC6775"/> 
		 LLN topology , the neighborhood IR is a 6LoWPAN Router (6LR) and the AR is a 
		 6LoWPAN Border Router (6LBR).
		 When the topology grows, the IPv6 ND registration model as described in 
		 <xref target="RFC6775"/>, with a single AR (the 6LBR), may not scale.
		  </t>

		 <t> With this draft,
		all registrars maintain an abstract Binding Table of their registered addresses.
		The Binding Table operates as a distributed database of information related to addresses 
		whether the address owner reside on the attached links or on the Backbone. ARs use extensions
		to the Neighbor Discovery Protocol to exchange that information across the Backbone
		either in the classical ND reactive fashion, or through a new pub/sub mechanism
		that is introduced by this specification. 
		</t>
		<t>
          With this specification, multiple IRs and one AR can be deployed so as 
		  to scale the IPv6 ND registration model yet avoiding any
          broadcast beyond one Layer-2 hop; IRs cover the whole multi-link subnet
		  in a fashion that any node in the network has at least one
		  neighborhood IR one Layer-2 hop away so it may perform an NDP 
          registration with that IR using link local addresses regardless
		  of the link type, wired or wireless.
		  <figure anchor='figrh'
 title="Registrar hierarchy">
<artwork><![CDATA[

            +-----+
            |     |  -----.
            |  RN |   RIF |    +-----+       +-----+       +-----+
            +-----+       .->  |     | ----> |     | ----> |     | 
			              .->  |  IR | VIF   |  IR | VIF   | AR  |  
            +-----+   RIF |    +-----+       +-----+       +-----+
            |     |  -----.                                   ^
		    |  RN |                                          DIF
            +-----+                                           v
                               +-----+       +-----+       +-----+
			  ...              |     | VIF   |     | VIF   |     |  
            +-----+       .->  |  IR | ----> |  IR | ----> | AR  | 
            |     |   RIF |    +-----+       +-----+       +-----+
            |  RN |  -----.
            +-----+
]]></artwork>
</figure> 
          IRs and ARs form a DAG directed towards the AR(s); but how this DAG 
		  is set up is out of scope for this specification.
		  </t>
		  <t>     
          If more than one AR is deployed, a strategy 
		  (e.g. a distributed hash table (DHT) or a DNS-like hierarchy) and a
		  method to distribute and synchronize the individual domains of authority
          between ARs, must be put in place. Such method is out of scope for 
          this document. In the case where an overlap of domain is acceptable,
          a protocol must be put in place between ARs so as to resolve conflicts,
          and clean up stale states. Such a protocol is out of scope for this 
          document.
		  </t>
        </section>
	<section anchor='context' title="General Context">
	<section anchor='vseff' title="Efficient ND">
		  <t> 
	      <xref target="I-D.chakrabarti-nordmark-6man-efficient-nd"/> updates the
		  specification of the RIF interface between the RN and the IR, 
		  that was initially defined in <xref target="RFC6775"/> for 6LoWPAN devices.
		  The draft details the operation of a IPv6 ND-efficiency-aware Router(NEAR), 
		  that is the neighborhood IR to which an RN, 
		  which is called a Efficiency-Aware Host (EAH), registers. 
		  A NEAR is also an AR as it has the exclusive authority on the bindings 
		  for its registered EAHs. 
<figure anchor='figNEAR'
 title="Efficient ND model">
<artwork><![CDATA[

            +-----+                   +-----+
            |NEAR | IR                |NEAR | IR
            |     | AR                |     | AR <--.
            +-----+                   +-----+       |
               |                         |        new NDP
               |      Backbone Link      |     registration
         +--------------------+------------------+  |
         | legacy + efficient | ND operations    |  |
         |                    |                  |   
     +-------+            +-------+          +-------+
     |legacy |            |legacy |          | EAH   | RN 
     | host  |            |router |          |       | 
     +-------+            +-------+          +-------+
     
		 
]]></artwork>
</figure>
		  
		  In the case of a WIFI connection, the NEAR is a BBR for the wireless device, 
		  and may be collocated with a standalone AP or a Wireless LAN Controller. 
<figure anchor='figNEARWiFI'
 title="Efficient ND with WiFi access">
<artwork><![CDATA[

            +-----+                   +-----+
            |NEAR | IR                |NEAR | IR
            |     | AR                |WLC  | AR <--.
            +-----+                   +-----+      |||
               |                         |        new NDP
               |      Backbone Link      |     registration
         +--------------------+------------------+ |||
        | | legacy + proxy   | | ND operations     |||
        | |                  | |                   |||          
    o +-----+ o          o +-----+ o           o +-----+ o    
   o  |  AP |  o        o  |  AP |  o         o  |  AP |  o   
    o +-----+  o         o +-----+ o           o +-----+ o
 	    o o                  o  o                 o   o
	wireless attached links                    EAH  o  RN
]]></artwork>
</figure>
 		  This specification extends  <xref target="I-D.chakrabarti-nordmark-6man-efficient-nd"/>, 
		  by allowing the separation of IR and AR functions, which are collapsed inside the NEAR.
		  This draft introduces the VIF interface between IRs, and between IRs and ARs, as well
		  as the DIF interface between ARs with potentially overlapping domain, and other 6SMEs.
		  </t>  	
		  <t>
    For the purpose of the new NDP registration, <xref target="I-D.chakrabarti-nordmark-6man-efficient-nd"/> 
	defines an extended ARO option that is advertised by an EAH. The new ARO option includes a sequence counter
	called TID that enables a short term freshness assertion between rapid re-registrations of a mobile 
	device, and a unique ID that is used for the Duplicate Address Detection (DAD).
		  </t>  	
		  <t> 
	A 6SME may maintain a state for a longer time than covered by the ARO TID, so a coarse age
	information is be needed to compare old state information over the VIF and DIF interfaces.
	Additionally, the 6SME may qualify information with additional metadata to help resolve conflicts. 
	For instance, in the case of a duplicated IPv6 address, additional meta information such
	as the protocol that was used to establish the state (SLAAC vs. DHCPv6), a device type 
	(trusted server vs. unknown host), or a Secure ND cryptographic address ownership validation 
	(<xref target="RFC3971"/>, <xref target="RFC3972"/>) can help protect the address where it 
	is assigned in a more trusted fashion even if a rogue managed to grab the address while the
	more trusted owner was not able to defend it.
		  </t>  	
		  <t>  This specification proposes a new ND option that contains such information
	and complements the information in the ARO option for use on the VIF and DIF interfaces.
  	</t>
        </section>
	<section anchor='ndpp' title="Proxying classical ND">
	      <t>
	      A 6SME such as an IR, a AR or a BBR may proxy classical <xref target="RFC4861"> IPv6 NDP
	      </xref> on behalf of a virtual, a wireless, or a low power device so as to offload 
	      the device, to dampen the network load such as induced by the multicast operations of 
	      the proxied protocol, or simply to attract over the backbone and then relay
          its traffic to the mobile or sleeping device even if the device is not reachable at 
          that particular time. 
		  </t>  	
		  <t> 
<figure anchor='figBackbone'
 title="Backbone Link and Backbone Routers">
<artwork><![CDATA[
                    Backbone (Home) Link      
         +--------------------+------------------+
         | legacy + proxy     | ND operations    |
         |                    |                  |
      +-----+             +-----+             +-----+
      |MIP/ |IR +         |MIP/ |IR +         |MIP/ |IR  <-. 
      |HA   |AR           |NEMO |AR           |NEMO |AR    |
      +-----+             +-----+             +-----+   Binding
     // | | \\           // | | \\           // | | \\  Update      
    //  | |  \\         //  | |   MN        MR   MN  \\    |
    MN   MN   \\       //   MR                        MN --. 
               MN     MN      tunnel-based attached links         		 
]]></artwork>
</figure> The 6SME may perform the proxy operation on behalf of
          an original device using the original device LLA, or may proxy the Layer-2
		  information with their own LLA and either rewrite it later in the packets, 
		  or route the packet again over an attached link, as examplified by a 
	      <xref target="RFC6275"> MIPv6 </xref> or a <xref target="RFC3963"> 
		  NEMO </xref> Home Agent (HA).
		  </t>  	
		  <t> 
          The HA is authoritative for any Mobile Node (MN) that successfully registers to it through
		  a Binding Update/Ack flow and its domain of authority is the subnet(s) on the Home
		  Link, potentially overlapping with other HAs. ND proxy operations are used over
		  the Home Link to resolve collisions.
		  </t>  	
		  <t> 
		  The MN is thus an RN and the HA cumulates IR, AR and proxy functionalities. With 
		  <xref target="RFC3963"> NEMO </xref>, the model is conserved but the RN is now
		  a Mobile Router that registers a prefix together with its own address, so the
		  operation in the Backbone link is a mix of ND proxy and routing.
		  <xref target="RFC3963"> Network Mobility Home Network Models </xref> provides
		  more information on that model.
	 </t>	
        </section>
	<section anchor='LLNBBR' title="Federating Large LLNs">
		  <t>In the case of a large multi-link subnet, this specification expects that a 
		  Backbone link is deployed to interconnect all the ARs and legacy NDP devices.
		  Each interconnected attached link, whether it is a WIFI access, a mesh network, 
		  a 6LoWPAN/RPL LLN or an overlaid tunnel, is anchored to the Backbone at a
          Backbone Router (BBR). The BBRs interconnect the multi-link subnet over
          the Backbone Link at layer 3, enabling connectivity within the subnet over IP. 
          <figure anchor='figBackbone1' title="RPL Backbone Routers">
<artwork><![CDATA[

            +-----+                   +-----+
            |     | AR                |     | AR
            |     |                   |     |
            +-----+                   +-----+
               |                         |
               |      Backbone Link      |
         +--------------------+------------------+
         |     legacy + proxy | + registration   |
         |              mixed | ND operations    |
      +-----+             +-----+             +-----+
      | RPL | BBR         | RPL | BBR         | RPL | BBR
      |root | ND proxy    |root | ND proxy    |root | ND proxy
      +-----+             +-----+             +-----+
    IR o  o  IR o        o   IR  o        o  o  IR  o      
     o o IR  o     o     o IR   o  IR  o   o IR  o     IR 
    o IR o  IR  o  IR o o   o  o  o  o      o        o    o   
    o    IR   o    o     IR    o  IR           
       o   o                o  o         LLN attached links         
]]></artwork>
</figure>
         
		  </t>
  

		 <t>
		 If the LLN uses a Route-Over model based on 
		 <xref target="RFC6550">RPL</xref>, the Backbone Router (BBR) that connects the 
		 LLN to the Backbone is the root for the RPL LLN. The BBR proxies the ND
		 protocol over the backbone for the addresses that it has learnt through RPL as 
		 host routes, using its own LLA and location to attract traffic for the attached
		 nodes and route it over the LLN. 
           </t>
		  <t>  
		  Over the Backbone, this setup implements the "simple scenario" in 
		  <xref target="I-D.ietf-ipv6-multilink-subnets"/>
		  whereby the router acts "as an asymmetric Neighbor Discovery proxy"; 
		  over the RPL-based LLN mesh, the setup implements the more "complex scenario" 
		  whereby "an arbitrary topology exists, and routers within the subnet communicate
		  using some means of exchanging host routes".		  
		  </t>
		  <!--t> 
		   <xref target="I-D.thubert-6lowpan-backbone-router"/> describes this mixed model,
		   simple over the backbone and complex over the LLN, and how,
           using such proxy-ND operations over the Backbone,
		   a BBR emulates that a attached node is present
           on the Backbone and so as to maintain reachability for legacy IPv6 ND hosts.
           </t>
		  <t> With 
		   <xref target="I-D.thubert-6lowpan-backbone-router"/>, an attached
		   node can move freely from a wireless attached link
		   anchored at one BBR to another that is anchored at another BBR 
		   on the same backbone and conserve any of the IPv6 addresses that it has formed. 
		   In a same fashion, an Efficiency-Aware Host (EAH) residing on the Backbone may 
		   change its BBR - acting as  IPv6 ND-efficiency-aware Router (NEAR) - and conserve 
		   its addresses with no disruption.
           </t-->
	   <t>
		<xref target="I-D.thubert-6lowpan-backbone-router"/> describes this mixed model,
	    and how a Backbone Router perform ND proxy operation for their attached nodes
		over the The Backbone Link regardless of the mode of registration for the
		attached nodes. 
	     The operation described in the draft is compatible with that of a
		 <xref target="RFC6275">MIPv6</xref> Home Agent.
	     This enables mobility support for wireless attached nodes that would move
	     outside of the network delimited by the Backbone link and back.
		 In any case, it is expected that the registration provides
		 a sequence counter, a lifetime and a unique identifier of the attached nodes
		 in such a fashion that they can be matched or compared across protocols.		
           </t>

		  <t>  This specifications indicates how the new ND option can be used in
		  conjunction with ND proxy techniques over the Backbone to 
		  implement the DIF interface.
  	</t>
	   <!--t>
           </t-->



        </section>



        </section>

	<section anchor='mess' title="New types and formats">
	        <t>This section introduces message formats for all messages used in this specification.</t>
	
		<t>The specification expects that the protocol running on the LLN can provide
		a sequence number called Transaction ID (TID) that is associated to the registration. 
		When a node registers to multiple registrars (IRs or ARs), it is expected that the same TID is used, 
		to enable the registrar to correlate the registrations as being a single one, and
		differentiate that situation from a movement. Otherwise, the resolution makes
		it so that only the most recent registration was perceived from the highest TID
		is kept.</t>
		
	    <t>The specification expects that the protocol running on the LLN can provide
		a unique ID for the owner of the address that is being registered. 
		The Owner Unique ID enables to differentiate
		a duplicate registration from a double registration. In case of a duplicate, the last
		registration looses. The Owner Unique ID can be as simple as a EUI-64 burnin address, if
		the device manufacturor is convinced that there can not be a manuf error that would 
		cause duplicate EUI64 addresses. Alternatively, the unique ID can be a hash of supposedly
		unique information from multiple orthogonal sources, for instance:
		<list  style="symbols">
		<t> Burn in address.
		</t>
		<t> configured address, id, security keys...
		</t>
		<t> (pseudo) Random number, radio link metrics ...
		</t>
		</list>
		In any fashion, it is recommended that the device stores the unique ID in persistent memory.
		Otherwise, it will be prevented to re-register after a reboot that would cause a loss of memory
		until the Backbone Router times out the registration.
		</t>
		<t>The unique ID and the sequence number are placed in a new ND option that is used by the
		Backbone Routers over the Backbone link to detect duplicates and movements. The option format 
		is as follows:
		</t>


<figure anchor='sailor' title="SAIL Option Record">
<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 = 2  |R| rsv         |origin | trust |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |T|N|  rsv      |     TID       |   Registration age (10 sec)   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +         ALI                                                   +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ]]></artwork>
</figure>

<!--

	   
	   TID: 1-byte integer; a transaction id that is maintained by the device 
	   and incremented with each transaction.
	   it is recommended that the device maintains the TID in a persistent storage. 
	   
	   T flag: Set if the next octet is a TID.
	   N flag: Set if the device moved. If not set, the router will refrain from sending NA(O) after DAD in mixed mode.
	   The TID is really a sequence counter, and it is managed as described in section 7.2. Sequence Counter Operation of [RFC 6550]
	   
-->

     <t> Option Fields
	 
        <list style='hanging'>
	     <t hangText="Type:">8-bit identifier of the type of option. 
		 
		 </t>
	     <t hangText="Length:">2
		 
		 </t>
	     <t hangText="R:">One bit flag. Set if the sender is relaying the option received from a downstream node, whether a RN or an IR.
	     </t>
	     <t hangText="origin :">4-bit unsigned integer. Indicates the origin of the entry.
	       <list style = 'hanging'>
		 <t hangText ="0 - SLACC:">Address was auto-configured on the RN [RF4862]</t>
		 <t hangText ="1 - DHCP:">Address was assigned to the RN by DHCP</t>
		 <t hangText ="2 - LOCAL:">Address was manually configured on the RN</t>
		 <t hangText ="3 - STATIC:">Address was manually configured on the IR as a downstream address, i.e. an address
		 assigned to a downstream node</t>
		 <t hangText ="4 - DATA:">Address was gleaned on the first IR as the source of a data packet</t>
	       </list>
	     </t>
	     <t hangText="trust :">4-bit unsigned integer. Indicates the level of trust the attaching node place in the entry 
	       <list style = 'hanging'>
		 <t hangText ="0 - NO_TRUST:">No particular trust associated with the entry</t>
		 <t hangText ="1 - L2L3_MATCH:">The layer-2 source MAC and Link-layer-Address claimed in the registration match</t>
		 <t hangText ="2 - TRUSTED_BY_POLICY:">The address is trusted by policy on the attaching node</t>
		 <t hangText ="3 - AUTHENTICATED">The address has been authenticated by a cryptographic protocol (CGA, etc.)></t>
	       </list>
	     </t>
		<t> </t>
	     <t hangText="T:">One bit flag. Set if the next octet is a used as a TID following follow section 7 of 
		<xref target="RFC6550"> RPL </xref>  for sequence counters. If the bit is not set, a unsigned char is expected.
		 </t>
	     <t hangText="N:">One bit flag. Set if the device moved. If not set, the router will refrain from sending gratuitous NA(O)
		 over the backbone, for instance after the DAD operation upon entry creation.
		 </t>
	     <t hangText="rsv:">This field is unused.  It MUST be initialized to zero by
      the sender and MUST be ignored by the receiver.
		 
		 </t>
	     <t hangText="TID:">1-byte integer; a transaction id that is maintained by the device 
	   and incremented with each transaction.
	   it is recommended that the device maintains the TID in a persistent storage. The TID is incremented at each registration.
		 
		 </t>
	     <t hangText="Registration Age:">2-byte integer; the duration since the last update of TID in units of 10 seconds. 
		 
		 </t>
	     <t hangText="Attaching Location Identifier:">A locally unique identifier for the
	     IR interface attaching the registering host. 
	     </t>
	</list>

	</t>

	</section>

	<section anchor='vifops' title="Validation Interface Operations">
	  <t>
	  The Validation Interface (VIF) is the interface between a child Intermediate Registrar (IR) and a parent registrar,
	  whether an Intermediate Registrar or Authoritative Registrar (AR). An IR parent or upstream chain is defined as the set of IRs
	  along the DAG starting from this IR, directed to (and including) the AR. An IR child or downstream chain is defined as the set of
	  IRs from this IR an entry was learnt from including the IR attaching to the RN. The goal of VIF is to perform one
	  or several of the followings:
	  <list style="symbols">
	    <t>Validate a new registration along the parent chain</t>
	    <t>Record a registration along the parent chain</t>
	    <t>Update a registration along the parent chain</t>
	    <t>Cancel a registration along the parent chain</t>
	    <t>Delete a record along the parent chain</t>
	    <t>Delete a record along the child chain</t>
	  </list>
	  </t>

	  <section title="Child to Parent Operations">
	    <t>The first IR in the chain (attached to the RN) initiates validation and registration of an address registered by the RN or
	    snooped on the interface attaching the RN to the node, by building a DAR message, including a SLLA and a SAIL option where:
	    <list style="symbols">
	      <t>Source of the DAR is an IP address of the IR interface to the next IR in the chain.</t>
	      <t>Destination of the DAR is an IP address of the next IR.</t>
	      <t>R bit set to zero. If the IR acts as an RN, the the bit is set to 1</t>
	      <t>Origin can take any of the values defined, based on how the address was assigned</t>
	      <t>If the registration was received from the RN (or gleaned) on an IR interface administratively trusted, the field "trust"
	      is set to TRUSTED_BY_POLICY. Otherwise, if the registration carried CGA [RFC3971] credential that the IR successfully verified,
	      the field "trust" is set to AUTHENTICATED. Otherwise, if the source mac of the registration message received by the IR is
	      identical to the Link-Layer Address provided by the message in the SLLA option, the trust field is set to L2L3_MATCH.
	      Otherwise, it is set to NO_TRUST.</t>
	      <t>An SLLA option MUST be included in the DAR message along with the SAIL option, that contains the Link-Layer address
	      bound to the IP address bein registered.</t>
	    </list>
	    </t>

	    <t>While waiting for a response, a TENTATIVE entry is created on the IR. Several attributes are stored next to the entry:
	    the EUI64 provided by the RN, Link Layer Address provided in the SLLA option, the origin and trust values (computed by the IR,
	    based on the registration, and local policies), the ALI the registration was received from, the lifetime.
	    In the absence of a DAC response, DAR messages sent in the context of VIF fron the IR are retransmitted after 250ms
	    [DAR_INTERVAL], up to 2 times [MAX_DAR_RETRANSMIT]. Upon receiving a negative response (duplicate address status) or when the
	    maximum retransmit is exhausted, the entry is removed from the IR. 
	    </t>

	    <t>The IR can also initiate update and delete operations. An update is no different from an address validation: the DAR will carry
	    the same address and EUI-64 as the one provided in a previous validation, while any other attribute such as SLLA option,
	    Lifetime, Origin, Trust or ALI will eventually be different from the value previously provided </t>

	    <t>In order to cancel a registration, a DAR is sent, with a lifetime set to zero. It should carry a SAIL option to allow the
	    receiving IR or AR to validate the delete.</t>

	  </section>

	  <section title="Parent to Child Operations">
	    <section title="Address validation and registration">
	      <t>Upon receiving a DAR message with a SAIL option, an IR will lookup in the local table to verify whether the address already
	      exist.</t>
	      <t> If it does not exist, two cases arise. 
	      <list style="numbers">

		<t>The IR is not an AR. It creates the entry as "TENTATIVE", together with attributes such as EUI64, IR address it came from,
		origin and trust values. It then builds and sends a DAR message sourced with one address of its interface to the next IR,
		set destination address to the next IR address, sets the R bit to 1 and copies all other fields	from the received DAR.
		It also starts a 250ms TENTATIVE_TIMER timer ot 250ms [DAR_INTERVAL]. Should this timer expire, the DAR is re-transmitted
		up to 2 times, then the entry is deleted.
		If a negative response (DAC with status 1) is received, a DAC with status 1 is sent to the downstream IR, and the TENTATIVE
		entry is deleted. If a positive response (DAC with status 0) is received, the timer TENTATIVE_TIMER is stopped,
		the entry state moved to REACHABLE and a DAC with status 0 is sent to downstream IR.   
		</t>

		<t>The IR is also the AR: it queries other ARs over the DIF interface. While waiting for a response, it may create the entry
		in "TENTATIVE" state. Upon confirmation from another AR that the entry exist elsewhere, the entry in TENTATIVE is deleted, and
		a DAC message is sent back to the source of the DAR message (previous IR), with a status set to 1 (Duplicate address).
		Upon receiving this DAC, each downstream IR deletes its own TENTATIVE entry, and sends a DAC, status 1, to the next child IR
		until it reaches the IR attaching the RN, which builds an NA with ARO option, and status set to duplicate address.
		If the DIF interface returns no conflict on the address, the entry state is moved to REACHABLE, and a DAC with status 0
		is sent to the downstream IRs which move their TENTATIVE entry to REACHABLE. When the DAC reaches the attaching IR, it
		send an NA with ARO option, status 0 to the RN.
		</t>
	      </list>
	    </t>
	    <t>If the same address carried in the DAR exist on one of the IR or the AR, with a different EUI-64 interface identifier, the
	    two entries attributes are compared. A trustlevel value is computed for each entry (as a function of the trust value,
	    the origin and the R bit). The two trustlevel values are compared numerically as follows:
	    <list style="numbers">
	      <t>If the trustlevel of the existing entry is bigger or equal than the one carried by the DAR, the DAR is not propagated,
	      and a DAC with status 1 (duplicate address) is sent back to downstream IR, up to the attaching IR which sends a NA with an
	      ARO option, status 1 to the RN.
	      </t>
	      <t>If the trustlevel of the existing entry is strictly smaller that the one carried by the DAR, it replaces it, and the DAR
	      is propagated towards the upstream IR up to the AR. Again, DAR follow the rule of hop-by-hop retransmission and acknowledgment
	      already described.</t>
	      <t>
	      At the same time, if the entry being replaced was associated with a different IR than the one this DAR came from, another DAR,
	      with the previous EUI64 value, and a lifetime set to zero is sent to downstream IR the previous registration came from. This
	      message causes the downstream IR to remove the entry, provided that the EUI64 match, to build and send a DAR to the next IR,
	      and to acknowledge the deletion with a DAC, status 0. If the EUI64 don't match, it means the entry has already been replaced,
	      and the DAR need not to be propagated from this IR.  DAR retransmission follow the same pattern already described. DAC are not
	      propagated. Upon receiving the DAR with lifetime set to zero, the attaching IR sends an unsolicited NA to the RN with an ARO
	      option, status 1 (duplicate address).
	      </t>
	    </list>
	    </t>

	    </section>
	    <section title="Registration update">
	      <t>An update message is a DAR that carries an address and EUI64 interface identifier matching an IR or AR table entry, 
	      and at least one of the following field different from the previously registered value: LifeTime, Origin, trust, ALI or
	      IR child. Upon receiving an update, the IR or AR updates its entry and propagate to the upstream IR or AR. The AR will in
	      return send a DAC message with a status of 0 to acknowledge the update. </t>
	      <t>If the attribute being updated is the IR address the DAR is coming from (child IR), the host has moved to a different 
	      downstream IR chain, and the entry along the previous chain must be cleaned up. A DAR message, with a lifetime set to zero is
	      sent (and retried if not acknowledged) to the old downstream IR. This message causes the downstream IR to remove the entry.
	      The downstream IR should propagate the DAR to the next IR in chain, and acknowledge it with a DAC.
	      </t>
	    </section>
	  </section>
	    <section title="Registration deletion">
	      <t>A registration deletion can come from the IR attaching to the RN, because the RN left the link, from any IR as the result
	      of an administrative action, or from the AR because the lifetime has expired or again following an administrative action.
	      In all cases, a DAR message with a lifetime set to zero is sent either upstream or downstream, retried and acknowledged 
	      at each hop along the chain, if necessary. When the deletion is initiated on the IR attaching to the RN, a SAIL option
	      MUST be provided to enable any upstream registrar to verify that the deletion is coming from the location the RN was attached
	      to. For deletion following the parent chain, the ALI value carried in the SAIL option is compared with the ALI value registered
	      for this address, and entry is deleted is the two match. For deletion following the child chain, this check is not required.
	      Upon deleting the entry, the IR builds and sends a DAC to acknowledge the deletion, then  build and send a DAR to propagate the
	      deletion, downstream or upstream.
	      </t>
	    </section>
	</section>
        <section title="Security Considerations">
           <t>
	   This specification expects that the link layer is sufficiently protected, either
	   by means of physical or IP security for the Backbone Link or MAC sublayer cryptography.
	   In particular, it is expected that the LLN MAC provides secure unicast
	   to/from the Backbone Router and secure BBRoadcast from the Backbone Router in a way that prevents
	   tempering with or replaying the RA messages.
	   </t>
	   <t>
	   The use of EUI-64 for forming the Interface ID in the link local address prevents the usage
	   of Secure ND (<xref target="RFC3971"/> and <xref target="RFC3972"/>) and address privacy
	   techniques. Considering the envisioned deployments and the MAC layer security applied,
	   this is not considered an issue at this time.
	   </t>

        </section>
        <section title="IANA Considerations">
        <t>A new type is requested for an ND option.</t>
        </section>


<section title="Acknowledgments">
<t>TBD</t>
</section>

    </middle>

    <back>
	
    <references title='Normative References'>
       &RFC2119;

       &RFC2460;

       &RFC4291;

       &RFC4429;
	   
       &RFC4443;

       &RFC4861;

       &RFC4862;

       &RFC4944;

       &RFC6282;
	   
       &RFC6550;
	   
       &RFC6620;

       &RFC6775;

    </references>
	
    <references title='Informative References'>

       &RFC3115;
	   
       &RFC3963;
	   
       &RFC3971;

       &RFC3972;

       &RFC4389;
	   
       &RFC4887;

       &RFC4903;
	   
       &RFC4919;

       &RFC6275;
	   
	  <?rfc include='reference.I-D.ietf-ipv6-multilink-subnets.xml'?> 
	    
      <?rfc include='reference.I-D.thubert-6lowpan-backbone-router.xml'?>
	  
      <?rfc include='reference.I-D.ietf-roll-terminology.xml'?>
	  
	  <?rfc include='reference.I-D.chakrabarti-nordmark-6man-efficient-nd.xml'?> 

	  
    </references>
	
    </back>

</rfc>
