< draft-thubert-6lo-rfc6775-update-reqs-05.txt		draft-thubert-6lo-rfc6775-update-reqs-06.txt >
	6Lo P. Thubert, Ed.		6Lo P. Thubert, Ed.
	Internet-Draft cisco		Internet-Draft cisco
	Intended status: Standards Track October 27, 2014		Intended status: Standards Track P. van der Stok
	Expires: April 28, 2015		Expires: July 18, 2015 consultant
			January 14, 2015
	Requirements for an update to 6LoWPAN ND		Requirements for an update to 6LoWPAN ND
	draft-thubert-6lo-rfc6775-update-reqs-05		draft-thubert-6lo-rfc6775-update-reqs-06
	Abstract		Abstract
	Work presented at the ROLL, 6lo, 6TiSCH and 6MAN Working Groups		Work presented at the ROLL, 6lo, 6TiSCH and 6MAN Working Groups
	suggest that enhancements to the 6LoWPAN ND mechanism are now needed.		suggest that enhancements to the 6LoWPAN ND mechanism are now needed.
	This document elaborates on those requirements and suggests		This document elaborates on those requirements and suggests
	approaches to serve them.		approaches to serve them.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 28, 2015.		This Internet-Draft will expire on July 18, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (http://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Simplified BSD License text		to this document. Code Components extracted from this document must
	as described in Section 4.e of the Trust Legal Provisions and are		include Simplified BSD License text as described in Section 4.e of
	provided without warranty as described in the Simplified BSD License.		the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Requirements Related to Mobility . . . . . . . . . . . . . 5		4.1. Requirements Related to Mobility . . . . . . . . . . . . 6
	4.2. Requirements Related to Routing Protocols . . . . . . . . 6		4.2. Requirements Related to Routing Protocols . . . . . . . . 7
	4.3. Requirements Related to the Variety of Low-Power Link types 6		4.3. Requirements Related to the Variety of Low-Power Link
	4.4. Requirements Related to Proxy Operations . . . . . . . . . 7		types . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.5. Requirements Related to Security . . . . . . . . . . . . . 7		4.4. Requirements Related to Proxy Operations . . . . . . . . 8
	4.6. Requirements Related to Low-Power devices . . . . . . . . 8		4.5. Requirements Related to Security . . . . . . . . . . . . 9
	4.7. Requirements Related to Scalability . . . . . . . . . . . 8		4.6. Requirements Related to Scalability . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 12
	Appendix A. Suggested Changes to Protocol Elements . . . . . . . . 12		Appendix A. Suggested Changes to Protocol Elements . . . . . . . 14
	Appendix A.1. ND Neighbor Solicitation (NS) . . . . . . . . . . 12		A.1. ND Neighbor Solicitation (NS) . . . . . . . . . . . . . . 14
	Appendix A.2. ND Router Advertisement (RA) . . . . . . . . . . 12		A.2. ND Router Advertisement (RA) . . . . . . . . . . . . . . 15
	Appendix A.3. RPL DODAG Information Object (DIO) . . . . . . . 13		A.3. RPL DODAG Information Object (DIO) . . . . . . . . . . . 15
	Appendix A.4. ND Enhanced Address Registration Option (EARO) . 13		A.4. ND Enhanced Address Registration Option (EARO) . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	A number of use cases, including the Industrial Internet, require a		A number of use cases, including the Industrial Internet, require a
	large scale deployment of sensors that can not be realized with wires		large scale deployment of sensors that can not be realized with wires
	and is only feasible over wireless Low power and Lossy Network (LLN)		and is only feasible over wireless Low power and Lossy Network (LLN)
	technologies. When simpler hub-and-spoke topologies are not		technologies. When simpler hub-and-spoke topologies are not
	sufficient for the expected throughput and density, mesh networks		sufficient for the expected throughput and density, mesh networks are
	must be deployed, which implies the concepts of hosts and routers,		deployed, which implies the routing of packets over the mesh,
	whether operated at Layer-2 or Layer-3.		operated at either Layer-2 or Layer-3.
	The IETF has designed the LLN host-to-router and router-to-router		For routing over a mesh at layer-3, the IETF has designed the IPv6
	protocol that supports address assignment and the router-to-router		Routing Protocol over LLN (RPL) [RFC6550].
	protocol that supports reachability across Route-Over LLNs in
	different Areas. It was clear for both efforts that the scalability
	requirements could only be met with IPv6 [RFC2460], and there is no
	fundamental contradiction between those protocols to that regard.
	While DHCPv6 is still a viable option in LLNs, the new IETF standard		To assign routable addresses, DHCPv6 is still a viable option in
	that supports address assignment specifically for LLNs is 6LoWPAN ND,		LLNs. However, the IETF standard that supports address assignment
	the Neighbor Discovery Optimization for Low-power and Lossy Networks		specifically for LLNs is 6LoWPAN ND, the Neighbor Discovery
	[RFC6775]. 6LoWPAN ND was designed as a stand-alone mechanism		Optimization for Low-power and Lossy Networks [RFC6775]. 6LoWPAN ND
	separately from its IETF routing counterpart, the IPv6 Routing		was designed as a stand-alone mechanism separately from its IETF
	Protocol for Low power and Lossy Networks [RFC6550] (RPL), and the		routing counterpart, the IPv6 Routing Protocol for Low power and
	interaction between the 2 protocols was not defined.		Lossy Networks [RFC6550] (RPL), and the interaction between the 2
			protocols was not defined.
	The 6TiSCH WG is now considering an architecture [I-D.ietf-6tisch-		The 6TiSCH WG is now considering an architecture
	architecture] whereby a 6LowPAN ND host could connect to the Internet		[I-D.ietf-6tisch-architecture] whereby a 6LowPAN ND host could
	via a RPL Network, but this requires additions to the protocol to		connect to the Internet via a RPL Network, but this requires
	support mobility and reachability in a secured and manageable		additions to the 6LOWPAN ND protocol to support mobility and
	environment.		reachability in a secured and manageable environment.
	At the same time, new work at 6MAN on Efficiency aware IPv6 Neighbor		At the same time, new work at 6MAN on Efficiency aware IPv6 Neighbor
	Discovery Optimizations [I-D.chakrabarti-nordmark-6man-efficient-nd]		Discovery Optimizations [I-D.chakrabarti-nordmark-6man-efficient-nd]
	suggests that 6LoWPAN ND can be extended to other types of networks		suggests that 6LoWPAN ND can be extended to other types of networks
	on top of the Low power and Lossy Networks (LLNs) for which it was		on top of the Low power and Lossy Networks (LLNs) for which it was
	already defined. The value of such extension is especially apparent		already defined. The value of such extension is especially apparent
	in the case of mobile wireless devices, to reduce the multicast		in the case of mobile wireless devices, to reduce the multicast
	operations that are related to classical ND ([RFC4861], [RFC4862])		operations that are related to classical ND ([RFC4861], [RFC4862])
	and plague the wireless medium. In this context also, there is a		and plague the wireless medium. In this context also, there is a
	need for additions to the protocol.		need for additions to 6LOWPAN ND.
	The Optimistic Duplicate Address Detection [RFC4429] (ODAD)		The Optimistic Duplicate Address Detection [RFC4429] (ODAD)
	specification details how an address can be used before a Duplicate		specification details how an address can be used before a Duplicate
	Address Detection (DAD) is complete, and insists that an address that		Address Detection (DAD) is complete, and insists that an address that
	is TENTATIVE should not be associated to a Source Link-Layer Address		is TENTATIVE should not be associated to a Source Link-Layer Address
	Option in a Neighbor Solicitation message. As we expect the 6LoWPAN		Option in a Neighbor Solicitation message. Applying this rule to
	ND protocol for a more general use, it can make sense to keep		6LOWPAN ND implies another change to its specification.
	respecting that rule, which is another change to the specification.
			In [I-D.richardson-6tisch--security-6top], the 6tisch working group
			considers the use of layer-2 security. It develops a network
			bootstrap protocol that provides secure link connections at the same
			rate that nodes are discovered. This approach needs the presence of
			a routing protocol to route packets from a joining node to a security
			providing node (e.g. a PCE or commissioning tool).
	This document suggests a limited evolution to [RFC6775] so as to		This document suggests a limited evolution to [RFC6775] so as to
	allow operation of a 6LoWPAN ND node as a leaf in a RPL network. It		allow operation of a 6LoWPAN ND node while a routing protocol (in
	also suggests a more generalized use of the information in the ARO		first instance RPL) is present and operational. It also suggests a
	option outside of the strict LLN domain, for instance over a		more generalized use of the information in the ARO option of the ND
	converged backbone.		messages outside the strict LLN domain, for instance over a converged
			backbone.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Readers are expected to be familiar with all the terms and concepts		Readers are expected to be familiar with all the terms and concepts
	that are discussed in "Neighbor Discovery for IP version 6"		that are discussed in "Neighbor Discovery for IP version 6"
	[RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862],		[RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862],
	"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):		"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals" [RFC4919],		Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
	Neighbor Discovery Optimization for Low-power and Lossy Networks		Neighbor Discovery Optimization for Low-power and Lossy Networks
	[RFC6775] and "Transmission of IPv6 Packets over IEEE 802.15.4		[RFC6775] and "Transmission of IPv6 Packets over IEEE 802.15.4
	Networks" [RFC4944].		Networks" [RFC4944].
	Additionally, this document uses terminology from 6TiSCH [I-D.ietf-		Additionally, this document uses terminology from 6TiSCH
	6tisch-terminology] and ROLL [RFC7102].		[I-D.ietf-6tisch-terminology] and ROLL [RFC7102].
	3. Overview		3. Overview
	The 6TiSCH architecture [I-D.ietf-6tisch-architecture] expects that		This document is mostly motivated by the work ongoing in the 6TiSCH
	a 6LoWPAN device can connect as a leaf to a RPL network, where the		working group. The 6TiSCH architecture
	leaf support is the minimal functionality to connect as a host to a		[I-D.ietf-6tisch-architecture] draft explains the network
	RPL network without the need to participate to the full routing		architecture of a 6TiSCH network. This architecture is used for the
	protocol. The support of leaf can be implemented as a minor		remainder of this document.
	increment to 6LoWPAN ND, with the additional capability to carry a
	sequence number that is used to track the movements of the device,
	and optionally some information about the RPL topology that this
	device will join.
	The scope of the 6TiSCH Architecture is a Backbone Link that		The scope of the 6TiSCH Architecture is a Backbone Link that
	federates multiple LLNs as a single IPv6 Multi-Link Subnet. Each LLN		federates multiple LLNs (mesh) as a single IPv6 Multi-Link Subnet.
	in the subnet is anchored at a Backbone Router (6BBR). The Backbone		Each LLN in the subnet is anchored at a Backbone Router (6BBR). The
	Routers interconnect the LLNs over the Backbone Link and emulate that		Backbone Routers interconnect the LLNs over the Backbone Link and
	the LLN nodes are present on the Backbone by proxy-ND operations. An		emulate that the LLN nodes are present on the Backbone thus creating
	LLN node can move freely from an LLN Route-Over mesh anchored at a		a so-called: Multi-Link Subnet. An LLN node can move freely from an
	Backbone Router to another anchored at a same or a different Backbone		LLN anchored at a Backbone Router to another LLN anchored at the same
	Router inside the Multi-Link Subnet and conserve its addresses.		or a different Backbone Router inside the Multi-Link Subnet and
			conserve its addresses.
	---+------------------------		---+------------------------
	| Plant Network		| Plant Network
	|		|
	+-----+		+-----+
	| | Gateway		| | Gateway
	| |		| |
	+-----+		+-----+
	|		|
	| Backbone Link (with VLANs)		| Backbone Link (with VLANs)
	+--------------------+------------------+		+--------------------+------------------+
	| | |		| | |
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	| | Backbone | | Backbone | | Backbone		| | Backbone | | Backbone | | Backbone
	| | router | | router | | router		| | router | | router | | router
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	| | | | | |		| | | | | |
	0 0 0 0 0 (6LBR == RPL root)		0 0 0 0 0 (6LBR == LLN border router)
	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 (6LR == RPL router)		o o o o o o o o o o (6LR == LLN router)
	o o o o o o o z		o o o o o o o z
	o o o o o z		o o o o o z
	RPL Instances (6LoWPAN Host == RPL leaf)		RPL Instances (6LoWPAN Host == LLN host)
	The root of the RPL topology is logically separated from the 6BBR		Figure 1: 6TiSCH architecture
	that is used to connect the RPL topology to the backbone. The RPL
	root can use Efficient ND as the interface to register an LLN node in		The 6LBR is the border router that is placed between the LLN and
	its topology to the 6BBR for whatever operation the 6BBR performs,		nodes outside the LLN. The 6LBR is logically separated from the 6BBR
	such as ND proxy operations, or injection in a routing protocol. It		that is used to connect the LLN to the backbone. The 6LBR can use
	results that, as illustrated in Figure 2, the periodic signaling		Efficient ND as the interface to register an LLN node in its topology
	could start at the leaf node with 6LoWPAN ND, then would be carried		to the 6BBR for whatever operation the 6BBR performs, such as ND
	over RPL to the RPL root, and then with Efficient-ND to the 6BBR.		proxy operations, or injection in a routing protocol. It results
	Efficient ND being an adaptation of 6LoWPAN ND, it makes sense to		that, as illustrated in Figure 2, the periodic signaling could start
	keep those two homogeneous in the way they use the source and the		at the leaf node with 6LoWPAN ND, then would be routed to the 6LBR,
	target addresses in the Neighbor Solicitation (NS) messages for		and then with Efficient-ND to the 6BBR. Efficient ND being an
	registration, as well as in the options that they use for that		adaptation of 6LoWPAN ND, it makes sense to keep those two
	process.		homogeneous in the way they use the source and the target addresses
			in the Neighbor Solicitation (NS) messages for registration, as well
			as in the options that they use for that process.
			6LoWPAN host 6LR 6LBR 6BBR
	6LoWPAN Node 6LR 6LBR 6BBR
	(RPL leaf) (router) (root)
	| | | |		| | | |
	| 6LoWPAN ND |6LoWPAN ND+RPL | Efficient ND | IPv6 ND		| 6LoWPAN ND | 6LoWPAN ND | Efficient ND | IPv6 ND
	| LLN link |Route-Over mesh| IPv6 link | Backbone		| LLN link | IPv6 route | IPv6 link | Backbone
	| | | |		| | | |
	| NS(ARO) | | |		| NS(ARO) | | |
	|-------------->| | |		|-------------->| | |
	| 6LoWPAN ND | DAR (then DAO)| |		| 6LoWPAN ND | DAR (then DAO)| |
	| |-------------->| |		| |-------------->| |
	| | | NS(ARO) |		| | | NS(ARO) |
	| | |-------------->|		| | |-------------->|
	| | | | DAD		| | | | DAD
	| | | |------>		| | | |------>
	| | | |		| | | |
	| | | NA(ARO) |		| | | NA(ARO) |
	| | |<--------------|		| | |<--------------|
	| | DAC | |		| | DAC | |
	| |<--------------| |		| |<--------------| |
	| NA(ARO) | | |		| NA(ARO) | | |
	|<--------------| | |		|<--------------| | |
	As the network builds up, a node should start as a leaf to join the		Figure 2: (Re-)Registration Flow over Multi-Link Subnet
	RPL network, and may later turn into both a RPL-capable router and a
	6LR, so as to accept leaf nodes to recursively join the network.
	Section 5 of the 6TiSCH architecture [I-D.ietf-6tisch-architecture]		As the network builds up, a LoWPAN host starts as a leaf to join the
			LLN, and may later turn into a 6LR, so as to accept other nodes to
			recursively join the LLN.
			Section 5 of the 6TiSCH architecture [I-D.ietf-6tisch-architecture]
	provides more information on the need to update the protocols that		provides more information on the need to update the protocols that
	sustain the requirements in the next section.		sustain the requirements in the next section.
	4. Requirements		4. Requirements
	4.1. Requirements Related to Mobility		4.1. Requirements Related to Mobility
	Due to the nature of LLN networks, even a fixed 6LoWPAN Node may		Due to the unstable nature of LLN links, even in a LLN of immobile
	change its point of attachment (a 6LR) and may not be able to notify		nodes a 6LoWPAN Node may change its point of attachment to a 6LR, say
	the 6LR that it has disconnected from. It results that the previous		6LR-a, and may not be able to notify 6LR-a. Consequently, 6LR-a may
	6LR may still attract traffic that it cannot deliver any more. When		still attract traffic that it cannot deliver any more. When links to
	the 6LR changes, there is thus a need to identify stale states and		a 6LR change state, there is thus a need to identify stale states in
	restore reachability timely.		a 6LR and restore reachability in a timely fashion.
	Req1.1: Upon a change of point of attachment, connectivity via a new		Req1.1: Upon a change of point of attachment, connectivity via a new
	6LR MUST be restored timely without the need to de-register from the		6LR MUST be restored timely without the need to de-register from the
	previous 6LR.		previous 6LR.
	Req1.2: For that purpose, the protocol MUST enable to differentiate		Req1.2: For that purpose, the protocol MUST enable to differentiate
	multiple registrations from a same 6LoWPAN Node from two different		between multiple registrations from one 6LoWPAN Node and
	6LoWPAN Nodes claiming a same address.		registrations from different 6LoWPAN Nodes claiming the same address.
	Req1.3: This information MUST be passed from the 6LR to the 6LBR, and		Req1.3: Stale states MUST be cleaned up in 6LRs.
	the 6LBR SHOULD be able to clean up the stale state asynchronously in
	the previous 6LR.
	Req1.4: A 6LoWPAN Node SHOULD also be capable to register a same		Req1.4: A 6LoWPAN Node SHOULD also be capable to register its Address
	Address to multiple 6LRs, and this, concurrently.		to multiple 6LRs, and this, concurrently.
	4.2. Requirements Related to Routing Protocols		4.2. Requirements Related to Routing Protocols
	The point of attachment of a 6LoWPAN Node may be a 6LR in an LLN		The point of attachment of a 6LoWPAN Node may be a 6LR in an LLN
	mesh. An LLN route-over mesh is typically based on RPL, which is the		mesh. IPv6 routing in a LLN can be based on RPL, which is the
	routing protocol that was defined at the IETF for this particular		routing protocol that was defined at the IETF for this particular
	purpose. It derives that in this scenario, the 6LR would classically		purpose. Other routing protocols than RPL are also considered by
	support RPL. One goal is that a 6LoWPAN Node attached via ND to a		Standard Defining Organizations (SDO) on the basis of the expected
	RPL-capable 6LR would not need to participate to the RPL protocol to		network characteristics. It is required that a 6LoWPAN Node attached
	obtain reachability via the 6LR. An additional goal would be to		via ND to a 6LR would need to participate in the selected routing
	obtain reachability via other routing protocols through a same ND-		protocol to obtain reachability via the 6LR.
	based abstraction.
			Next to the 6LBR unicast address registered by ND, other addresses
			including multicast addresses are needed as well. For example a
			routing protocol often uses a multicast address to register changes
			to established paths. ND needs to register such a multicast address
			to enable routing concurrently with discovery.
			Multicast is needed for groups. Groups MAY be formed by device type
			(e.g. routers, street lamps), location (Geography, RPL sub-tree), or
			both.
			The Bit Index Explicit Replication (BIER) Architecture
			[I-D.wijnands-bier-architecture] proposes an optimized technique to
			enable multicast in a LLN with a very limited requirement for routing
			state in the nodes.
	Related requirements are:		Related requirements are:
	Req2.1: The ND registration method SHOULD be extended in such a		Req2.1: The ND registration method SHOULD be extended in such a
	fashion that the 6LR MAY advertise the Address of a 6LoWPAN Node over		fashion that the 6LR MAY advertise the Address of a 6LoWPAN Node over
	RPL and obtain reachability to that Address over the RPL domain.		the selected routing protocol and obtain reachability to that Address
			using the selected routing protocol.
	Req2.2: The Address Registration Option that is used in the ND		Req2.2: Considering RPL, the Address Registration Option that is used
	registration SHOULD be extended to carry enough information to		in the ND registration SHOULD be extended to carry enough information
	generate a DAO message as specified in [RFC6550] section 6.4, in		to generate a DAO message as specified in [RFC6550] section 6.4, in
	particular the capability to compute a DAOSequence and, as an option,		particular the capability to compute a DAOSequence and, as an option,
	a RPLInstanceID.		a RPLInstanceID.
	Req2.3: Depending on their applicability to LLNs, other standard mesh		Req2.3: Multicast operations SHOULD be supported and optimized, for
	/MANET protocols MAY be considered as well.		instance using BIER or MPL. Whether ND is appropriate for the
			registration to the 6BBR is to be defined, considering the additional
	Req2.4: Multicast operations SHOULD be supported and optimized.		burden of supporting the Multicast Listener Discovery Version 2
	Groups MAY be formed by device type (e.g. routers, street lamps),		[RFC3810] (MLDv2) for IPv6.
	location (Geography, RPL sub-tree), or both. RPL already has the
	capability to advertise multicast groups; whether ND is appropriate
	for the registration to the 6BBR is to be defined, considering the
	additional burden of supporting the Multicast Listener Discovery
	Version 2 [RFC3810] (MLDv2) for IPv6.
	4.3. Requirements Related to the Variety of Low-Power Link types		4.3. Requirements Related to the Variety of Low-Power Link types
	6LoWPAN ND [RFC6775] was defined with a focus on IEEE802.15.4 and in		6LoWPAN ND [RFC6775] was defined with a focus on IEEE802.15.4 and in
	particular the capability to derive a unique Identifier from a		particular the capability to derive a unique Identifier from a
	globally unique MAC-64 address. At this point, the 6lo Working Group		globally unique MAC-64 address. At this point, the 6lo Working Group
	is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique		is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique
	to other link types ITU-T G.9959 [I-D.brandt-6man-lowpanz], Master-		to other link types ITU-T G.9959 [I-D.brandt-6man-lowpanz], Master-
	Slave/Token-Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy [I-D		Slave/Token-Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy
	.ietf-6lo-dect-ule], Near Field Communication [I-D.hong-6lo-ipv6		[I-D.ietf-6lo-dect-ule], Near Field Communication
	-over-nfc], as well as IEEE1901.2 Narrowband Powerline Communication		[I-D.hong-6lo-ipv6-over-nfc], as well as IEEE1901.2 Narrowband
	Networks [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and		Powerline Communication Networks
	BLUETOOTH(R) Low Energy [I-D.ietf-6lo-btle].		[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R)
			Low Energy [I-D.ietf-6lo-btle].
	Related requirements are:		Related requirements are:
	Req3.1: The support of the registration mechanism SHOULD be extended		Req3.1: The support of the registration mechanism SHOULD be extended
	to more LLN links, matching at least the links that are considered by		to more LLN links than IEEE 802.15.4, matching at least the LLN links
	6lo as well as other popular Low-Power links such as Low-Power Wi-Fi.		for which an "IPv6 over foo" specification exists, as well as Low-
			Power Wi-Fi.
	Req3.2: As part of this extension, a mechanism to compute a unique		Req3.2: As part of this extension, a mechanism to compute a unique
	Identifier should be provided, with the capability to form a Link-		Identifier should be provided, with the capability to form a Link-
	Local Address that can not be a duplicate. The Identifier SHOULD be		Local Address that SHOULD be unique at least within the LLN connected
	unique at least to the domain where an Address formed by this device		to a 6LBR discovered by ND in each node within the LLN.
	may be advertised through ND mechanisms.
	Req3.3: The Address Registration Option used in the ND registration		Req3.3: The Address Registration Option used in the ND registration
	SHOULD be extended to carry the relevant forms of unique Identifier.		SHOULD be extended to carry the relevant forms of unique Identifier.
			Req3.4: The Neighbour Discovery should specify the formation of a
			site-local address that follows the security recommendations from
			[RFC7217].
	4.4. Requirements Related to Proxy Operations		4.4. Requirements Related to Proxy Operations
	Sleeping devices may not be able to answer themselves to a lookup		Duty-cycled devices may not be able to answer themselves to a lookup
	from a node that uses classical ND on a backbone and may need a proxy		from a node that uses classical ND on a backbone and may need a
	operation by a 6BBR. Additionally, the device may need to rely on the		proxy. Additionally, the duty-cycled device may need to rely on the
	6LBR to perform that registration to the 6BBR.		6LBR to perform registration to the 6BBR.
			The ND registration method SHOULD defend the addresses of duty-cycled
			devices that are sleeping most of the time and not capable to defend
			their own Addresses.
	Related requirements are:		Related requirements are:
	Req4.1: The registration mechanism SHOULD enable a third party to		Req4.1: The registration mechanism SHOULD enable a third party to
	proxy register an Address on behalf of a 6LoWPAN node that may be		proxy register an Address on behalf of a 6LoWPAN node that may be
	sleeping or located deeper in an LLN mesh.		sleeping or located deeper in an LLN mesh.
			Req4.2: The registration mechanism SHOULD be applicable to a duty-
			cycled device regardless of the link type, and enable a 6BBR to
			operate as a proxy to defend the registered Addresses on its behalf.
			Req4.3: The registration mechanism SHOULD enable long sleep
			durations, in the order of multiple days to a month.
	4.5. Requirements Related to Security		4.5. Requirements Related to Security
	In order to guarantee the operations of the 6LoWPAN ND flows, the		In order to guarantee the operations of the 6LoWPAN ND flows, the
	spoofing of the 6LR, 6LBR and 6BBRs roles should be avoided. Once a		spoofing of the 6LR, 6LBR and 6BBRs roles should be avoided. Once a
	node successfully registers an address, 6LoWPAN ND should provide		node successfully registers an address, 6LoWPAN ND should provide
	energy-efficient means to protect that ownership even if the node is		energy-efficient means for the 6LBR to protect that ownership even
	sleeping. In particular, the 6LR and the 6LBR then should be able to		when the node that registered the address is sleeping.
	verify whether a subsequent registration for a same Address comes
	from a same node or is a duplicate.		In particular, the 6LR and the 6LBR then should be able to verify
			whether a subsequent registration for a given Address comes from the
			original node.
			In a LLN it makes sense to base security on layer-2 security. During
			bootstrap of the LLN, nodes join the network after authorization by a
			Joining Assistant (JA) or a Commissioning Tool (CT). After joining
			nodes communicate with each other via secured links. The keys for
			the layer-2 security are distributed by the JA/CT. The JA/CT can be
			part of the LLN or be outside the LLN. In both cases it is needed
			that packets are routed between JA/CT and the joining node.
	Related requirements are:		Related requirements are:
	Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for		Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for
	the 6LR, 6LBR and 6BBR to authenticate and authorize one another for		the 6LR, 6LBR and 6BBR to authenticate and authorize one another for
	their respective roles, as well as with the 6LoWPAN Node for the role		their respective roles, as well as with the 6LoWPAN Node for the role
	of 6LR.		of 6LR.
	Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for		Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for
	the 6LR and the 6LBR to validate whether a new registration		the 6LR and the 6LBR to validate new registration of authorized
	corresponds to a same 6LoWPAN Node, and, if not, determine the		nodes. Joining of unauthorized nodes MUST be impossible.
	rightful owner, and deny or clean-up the registration that is deemed
	in excess.
	Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet		Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet
	sizes. In particular, the NS, NA, DAR and DAC messages for a re-		sizes. In particular, the NS, NA, DAR and DAC messages for a re-
	registration flow SHOULD NOT exceed 80 octets so as to fit in a		registration flow SHOULD NOT exceed 80 octets so as to fit in a
	secured IEEE802.15.4 frame.		secured IEEE802.15.4 frame.
	Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be		Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be
	computationally intensive on the LoWPAN Node CPU. When a Key hash		computationally intensive on the LoWPAN Node CPU. When a Key hash
	calculation is employed, a mechanism lighter than SHA-1 SHOULD be		calculation is employed, a mechanism lighter than SHA-1 SHOULD be
	preferred.		preferred.
	Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate		Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate
	SHOULD be minimized.		SHOULD be minimized.
	Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable CCM* for use		Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable CCM* for use
	at both Layer 2 and Layer 3, and SHOULD enable the reuse of security		at both Layer 2 and Layer 3, and SHOULD enable the reuse of security
	code that has to be present on the device for upper layer security		code that has to be present on the device for upper layer security
	such as TLS.		such as TLS.
	Req5.7: Public key and signature sizes SHOULD be minimized while		Req5.7: Public key and signature sizes SHOULD be minimized while
	maintaining adequate confidentiality and data origin authentication		maintaining adequate confidentiality and data origin authentication
	for multiple types of applications with various degrees of		for multiple types of applications with various degrees of
	criticality.		criticality.
	4.6. Requirements Related to Low-Power devices		Req5.8: Routing of packets should continue when links pass from the
			unsecured to the secured state.
	The ND registration method is designed to save energy on Low-Power
	devices, and in particular enable duty-cycled devices that are
	sleeping most of the time and not capable to defend their own
	Addresses against always-on devices.
	Related requirements are:
	Req6.1: The registration mechanism SHOULD be applicable to a Low-		Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for
	Power device regardless of the link type, and enable a 6BBR to		the 6LR and the 6LBR to validate whether a new registration for a
	operate as a proxy to defend the registered Addresses on its behalf.		given address corresponds to the same 6LoWPAN Node that registered it
			initially, and, if not, determine the rightful owner, and deny or
			clean-up the registration that is duplicate.
	Req6.2: The registration mechanism SHOULD enable long sleep		4.6. Requirements Related to Scalability
	durations, in the order of multiple days to a month, for devices
	capable of operating over the course of ten or more years without the
	need to recharge or replace the batteries.
	4.7. Requirements Related to Scalability
	Use cases from Automatic Meter Reading (AMR, collection tree		Use cases from Automatic Meter Reading (AMR, collection tree
	operations) and Advanced Metering Infrastructure (AMI, bi-directional		operations) and Advanced Metering Infrastructure (AMI, bi-directional
	communication to the meters) indicate the needs for a large number of		communication to the meters) indicate the needs for a large number of
	LLN nodes pertaining to a single RPL DODAG (e.g. 5000) and connected		LLN nodes pertaining to a single RPL DODAG (e.g. 5000) and connected
	to the 6LBR over a large number of LLN hops (e.g. 15).		to the 6LBR over a large number of LLN hops (e.g. 15).
	Related requirements are:		Related requirements are:
	Req7.1: The registration mechanism SHOULD enable a single 6LBR to		Req6.1: The registration mechanism SHOULD enable a single 6LBR to
	register multiple thousands of devices.		register multiple thousands of devices.
	Req7.2: The timing of the registration operation should allow for a		Req6.2: The timing of the registration operation should allow for a
	large latency such as found in LLNs with ten and more hops.		large latency such as found in LLNs with ten and more hops.
	5. Security Considerations		5. Security Considerations
	This specification expects that the link layer is sufficiently		This specification expects that the link layer is sufficiently
	protected, either by means of physical or IP security for the		protected, either by means of IP security for the Backbone Link or
	Backbone Link or MAC sublayer cryptography. In particular, it is		MAC sublayer cryptography. In particular, it is expected that the
	expected that the LLN MAC provides secure unicast to/from the		LLN MAC provides secure unicast to/from the Backbone Router and
	Backbone Router and secure broadcast from the Backbone Router in a		secure broadcast from the Backbone Router in a way that prevents
	way that prevents tempering with or replaying the RA messages.		tampering with or replaying the RA messages. Still, Section 4.5 has
	Still, Section 4.5 has a requirement for a mutual authentication and		a requirement for a mutual authentication and authorization for a
	authorization for a role for 6LRs, 6LBRs and 6BBRs.		role for 6LRs, 6LBRs and 6BBRs.
	This documents also suggests in Appendix Appendix A.4 that a 6LoWPAN		This documents also suggests in Appendix A.4 that a 6LoWPAN Node
	Node could form a single Unique Interface ID (CUID) based on		could form a single Unique Interface ID (CUID) based on cryptographic
	cryptographic techniques similar to CGA. The CUID would be used as		techniques similar to CGA. The CUID would be used as Unique
	Unique Interface Identifier in the ARO option and new Secure ND		Interface Identifier in the ARO option and new Secure ND procedures
	procedures would be proposed to use it as opposed to the source IPv6		would be proposed to use it as opposed to the source IPv6 address to
	address to secure the binding between an Address and its owning Node,		secure the binding between an Address and its owning Node, and
	and enforce First/Come-First/Serve at the 6LBR.		enforce First/Come-First/Serve at the 6LBR.
	6. IANA Considerations		6. IANA Considerations
	This draft does not require an IANA action.		This draft does not require an IANA action.
	7. Acknowledgments		7. Acknowledgments
	The author wishes acknowledge the contributions by Samita		The author wishes acknowledge the contributions by Samita
	Chakrabarti, Erik Normark, JP Vasseur, Eric Levy-Abegnoli, Patrick		Chakrabarti, Erik Normark, JP Vasseur, Eric Levy-Abegnoli, Patrick
	Wetterwald, Thomas Watteyne, and Behcet Sarikaya.		Wetterwald, Thomas Watteyne, and Behcet Sarikaya.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	6 (IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
	in IPv6", RFC 3775, June 2004.
	[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery		[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
	Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.		Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		Architecture", RFC 4291, February 2006.
	[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)		[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
	for IPv6", RFC 4429, April 2006.		for IPv6", RFC 4429, April 2006.
	[RFC4443] Conta, A., Deering, S. and M. Gupta, "Internet Control		[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
	Message Protocol (ICMPv6) for the Internet Protocol		Message Protocol (ICMPv6) for the Internet Protocol
	Version 6 (IPv6) Specification", RFC 4443, March 2006.		Version 6 (IPv6) Specification", RFC 4443, March 2006.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, September 2007.		Address Autoconfiguration", RFC 4862, September 2007.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J. and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4		"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, September 2007.		Networks", RFC 4944, September 2007.
	[RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support		[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
	in IPv6", RFC 6275, July 2011.		in IPv6", RFC 6275, July 2011.
	[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6		[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
	Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,		Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
	September 2011.		September 2011.
	[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,		[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
	Levis, P., Pister, K., Struik, R., Vasseur, JP. and R.		Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
	Alexander, "RPL: IPv6 Routing Protocol for Low-Power and		Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
	Lossy Networks", RFC 6550, March 2012.		Lossy Networks", RFC 6550, March 2012.
	[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for		[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
	Transport Layer Security (TLS)", RFC 6655, July 2012.		Transport Layer Security (TLS)", RFC 6655, July 2012.
	[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann,		[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
	"Neighbor Discovery Optimization for IPv6 over Low-Power		"Neighbor Discovery Optimization for IPv6 over Low-Power
	Wireless Personal Area Networks (6LoWPANs)", RFC 6775,		Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
	November 2012.		November 2012.
	[RFC6830] Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The
	Locator/ID Separation Protocol (LISP)", RFC 6830, January
	2013.
	8.2. Informative References		8.2. Informative References
	[I-D.brandt-6man-lowpanz]		[I-D.brandt-6man-lowpanz]
	Brandt, A. and J. Buron, "Transmission of IPv6 packets		Brandt, A. and J. Buron, "Transmission of IPv6 packets
	over ITU-T G.9959 Networks", Internet-Draft draft-brandt-		over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02
	6man-lowpanz-02, June 2013.		(work in progress), June 2013.
	[I-D.chakrabarti-nordmark-6man-efficient-nd]		[I-D.chakrabarti-nordmark-6man-efficient-nd]
	Chakrabarti, S., Nordmark, E., Thubert, P. and M.		Chakrabarti, S., Nordmark, E., Thubert, P., and M.
	Wasserman, "Wired and Wireless IPv6 Neighbor Discovery		Wasserman, "IPv6 Neighbor Discovery Optimizations for
	Optimizations", Internet-Draft draft-chakrabarti-nordmark-		Wired and Wireless Networks", draft-chakrabarti-nordmark-
	6man-efficient-nd-04, October 2013.		6man-efficient-nd-06 (work in progress), July 2014.
	[I-D.hong-6lo-ipv6-over-nfc]		[I-D.hong-6lo-ipv6-over-nfc]
	Hong, Y., Choi, Y., Youn, J., Kim, D. and J. Choi,		Hong, Y. and J. Youn, "Transmission of IPv6 Packets over
	"Transmission of IPv6 Packets over Near Field		Near Field Communication", draft-hong-6lo-ipv6-over-nfc-03
	Communication", Internet-Draft draft-hong-6lo-ipv6-over-		(work in progress), November 2014.
	nfc-01, August 2014.
	[I-D.ietf-6lo-6lobac]		[I-D.ietf-6lo-6lobac]
	Lynn, K., Martocci, J., Neilson, C. and S. Donaldson,		Lynn, K., Martocci, J., Neilson, C., and S. Donaldson,
	"Transmission of IPv6 over MS/TP Networks", Internet-Draft		"Transmission of IPv6 over MS/TP Networks", draft-ietf-
	draft-ietf-6lo-6lobac-00, July 2014.		6lo-6lobac-00 (work in progress), July 2014.
	[I-D.ietf-6lo-btle]		[I-D.ietf-6lo-btle]
	Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,		Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
	Shelby, Z. and C. Gomez, "Transmission of IPv6 Packets		Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
	over BLUETOOTH(R) Low Energy", Internet-Draft draft-ietf-		over BLUETOOTH(R) Low Energy", draft-ietf-6lo-btle-06
	6lo-btle-02, June 2014.		(work in progress), January 2015.
	[I-D.ietf-6lo-dect-ule]		[I-D.ietf-6lo-dect-ule]
	Mariager, P., Petersen, J., Shelby, Z., Logt, M. and D.		Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D.
	Barthel, "Transmission of IPv6 Packets over DECT Ultra Low		Barthel, "Transmission of IPv6 Packets over DECT Ultra Low
	Energy", Internet-Draft draft-ietf-6lo-dect-ule-00, June		Energy", draft-ietf-6lo-dect-ule-00 (work in progress),
	2014.		June 2014.
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., Watteyne, T. and R. Assimiti, "An		Thubert, P., Watteyne, T., and R. Assimiti, "An
	Architecture for IPv6 over the TSCH mode of IEEE		Architecture for IPv6 over the TSCH mode of IEEE
	802.15.4e", Internet-Draft draft-ietf-6tisch-		802.15.4e", draft-ietf-6tisch-architecture-04 (work in
	architecture-01, February 2014.		progress), October 2014.
	[I-D.ietf-6tisch-terminology]		[I-D.ietf-6tisch-terminology]
	Palattella, M., Thubert, P., Watteyne, T. and Q. Wang,		Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
	"Terminology in IPv6 over the TSCH mode of IEEE		"Terminology in IPv6 over the TSCH mode of IEEE
	802.15.4e", Internet-Draft draft-ietf-6tisch-		802.15.4e", draft-ietf-6tisch-terminology-03 (work in
	terminology-00, November 2013.		progress), January 2015.
	[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]		[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]
	Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets		Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets
	over IEEE 1901.2 Narrowband Powerline Communication		over IEEE 1901.2 Narrowband Powerline Communication
	Networks", Internet-Draft draft-popa-6lo-6loplc-ipv6-over-		Networks", draft-popa-6lo-6loplc-ipv6-over-
	ieee19012-networks-00, March 2014.		ieee19012-networks-00 (work in progress), March 2014.
	[RFC3610] Whiting, D., Housley, R. and N. Ferguson, "Counter with		[I-D.richardson-6tisch--security-6top]
			Richardson, M., "6tisch secure join using 6top", draft-
			richardson-6tisch--security-6top-04 (work in progress),
			November 2014.
			[I-D.wijnands-bier-architecture]
			Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
			S. Aldrin, "Multicast using Bit Index Explicit
			Replication", draft-wijnands-bier-architecture-02 (work in
			progress), December 2014.
			[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
	CBC-MAC (CCM)", RFC 3610, September 2003.		CBC-MAC (CCM)", RFC 3610, September 2003.
	[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P.		[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
	Thubert, "Network Mobility (NEMO) Basic Support Protocol",		Thubert, "Network Mobility (NEMO) Basic Support Protocol",
	RFC 3963, January 2005.		RFC 3963, January 2005.
	[RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure		[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",		[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, March 2005.		RFC 3972, March 2005.
	[RFC4389] Thaler, D., Talwar, M. and C. Patel, "Neighbor Discovery		[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
	Proxies (ND Proxy)", RFC 4389, April 2006.		Proxies (ND Proxy)", RFC 4389, April 2006.
	[RFC4919] Kushalnagar, N., Montenegro, G. and C. Schumacher, "IPv6		[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
	over Low-Power Wireless Personal Area Networks (6LoWPANs):		over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals", RFC		Overview, Assumptions, Problem Statement, and Goals", RFC
	4919, August 2007.		4919, August 2007.
			[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
			Locator/ID Separation Protocol (LISP)", RFC 6830, January
			2013.
	[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and		[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
	Lossy Networks", RFC 7102, January 2014.		Lossy Networks", RFC 7102, January 2014.
			[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
			Interface Identifiers with IPv6 Stateless Address
			Autoconfiguration (SLAAC)", RFC 7217, April 2014.
	Appendix A. Suggested Changes to Protocol Elements		Appendix A. Suggested Changes to Protocol Elements
	Appendix A.1. ND Neighbor Solicitation (NS)		A.1. ND Neighbor Solicitation (NS)
	The NS message used for registration should use a source address that		The NS message used for registration should use a source address that
	respects the rules in [RFC6775], [RFC4861], and [RFC4429] for DAD.		respects the rules in [RFC6775], [RFC4861], and [RFC4429] for DAD.
	The SLLA Option may be present but only if the address passed DAD,		The SLLA Option may be present but only if the address passed DAD,
	and it is used to allow the 6LR to respond as opposed to as a		and it is used to allow the 6LR to respond as opposed to as a
	registration mechanism.		registration mechanism.
	The address that is being registered is the target address in the NS		The address that is being registered is the target address in the NS
	message and the TLLA Option must be present.		message and the TLLA Option must be present.
	Appendix A.2. ND Router Advertisement (RA)		A.2. ND Router Advertisement (RA)
	[I-D.chakrabarti-nordmark-6man-efficient-nd] adds an 'E' bit in the		[I-D.chakrabarti-nordmark-6man-efficient-nd] adds an 'E' bit in the
	Router Advertisement flag, as well as a new Registrar Address Option		Router Advertisement flag, as well as a new Registrar Address Option
	(RAO). These fields are probably pertinent to LLNs inclusion into a		(RAO). These fields are probably pertinent to LLNs inclusion into a
	revised 6LoWPAN ND should be studied. If the new 6LoWPAN flows		revised 6LoWPAN ND should be studied. If the new 6LoWPAN flows
	require a change of behaviour (e.g. registering the Target of the NS		require a change of behaviour (e.g. registering the Target of the NS
	message) then the RA must indicate that the router supports the new		message) then the RA must indicate that the router supports the new
	capability, and the NS must indicate that the Target is registered as		capability, and the NS must indicate that the Target is registered as
	opposed to the Source in an unequivocal fashion.		opposed to the Source in an unequivocal fashion.
	There is some amount of duplication between the options in the RPL		There is some amount of duplication between the options in the RPL
	DIO [RFC6550] and the options in the ND RA messages. At the same		DIO [RFC6550] and the options in the ND RA messages. At the same
	time, there are a number of options, including the 6LoWPAN Context		time, there are a number of options, including the 6LoWPAN Context
	Option (6CO) [RFC6775], the MTU and the SLLA Options [RFC4861] that		Option (6CO) [RFC6775], the MTU and the SLLA Options [RFC4861] that
	can only be found in the RA messages. Considering that these options		can only be found in the RA messages. Considering that these options
	are useful for a joining node, the recommendation would be to		are useful for a joining node, the recommendation would be to
	associate the RA messages to the join beacon, and make them rare when		associate the RA messages to the join beacon, and make them rare when
	the network is stable. On the other hand, the DIO message is to be		the network is stable. On the other hand, the DIO message is to be
	used as the propagated heartbeat of the RPL network and provide the		used as the propagated heartbeat of the RPL network and provide the
	sense of time and liveliness.		sense of time and liveliness.
	RAs should also be issued and the information therein propagated when		RAs should also be issued and the information therein propagated when
	a change occurs in the information therein, such as a router or a		a change occurs in the information therein, such as a router or a
	prefix lifetime.		prefix lifetime.
	Appendix A.3. RPL DODAG Information Object (DIO)		A.3. RPL DODAG Information Object (DIO)
	If the RPL root serves as 6LBR, it makes sense to add at least a bit		If the RPL root serves as 6LBR, it makes sense to add at least a bit
	of information in the DIO to signal so. A Registrar Address Option		of information in the DIO to signal so. A Registrar Address Option
	(RAO) may also be considered for addition.		(RAO) may also be considered for addition.
	Appendix A.4. ND Enhanced Address Registration Option (EARO)		A.4. ND Enhanced Address Registration Option (EARO)
	The ARO option contains a Unique ID that is supposed to identify the		The ARO option contains a Unique ID that is supposed to identify the
	device across multiple registrations. It is envisioned that the		device across multiple registrations. It is envisioned that the
	device could form a single CGA-based Unique Interface ID (CUID) to		device could form a single CGA-based Unique Interface ID (CUID) to
	securely bind all of its addresses. The CUID would be used as Unique		securely bind all of its addresses. The CUID would be used as Unique
	Interface Identifier in the ARO option and to form a Link-Local		Interface Identifier in the ARO option and to form a Link-Local
	address that would be deemed unique regardless of the Link type.		address that would be deemed unique regardless of the Link type.
	Provided that the relevant cryptographic material is passed to the		Provided that the relevant cryptographic material is passed to the
	6LBR upon the first registration or on-demand at a later time, the		6LBR upon the first registration or on-demand at a later time, the
	6LBR can validate that a Node is effectively the owner of a CUID, and		6LBR can validate that a Node is effectively the owner of a CUID, and
	skipping to change at page 14, line 5 ¶		skipping to change at page 16, line 22 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Status | RPLInstanceID |		| Type | Length | Status | RPLInstanceID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Res|P|N| IDS |T| TID | Registration Lifetime |		|Res|P|N| IDS |T| TID | Registration Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Unique Interface Identifier (variable length) ~		~ Unique Interface Identifier (variable length) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The representation above is based on [I-D.chakrabarti-nordmark-6man-		Figure 3: EARO
	efficient-nd]. Only the proposed changes from that specification are
	discussed below but the expectation is that 6LoWPAN ND and Efficient
	ND converge on the ARO format.
	Status: 8-bit integer. A new value of 3 is suggested to indicate a		The representation above is based on
			[I-D.chakrabarti-nordmark-6man-efficient-nd]. Only the proposed
			changes from that specification are discussed below but the
			expectation is that 6LoWPAN ND and Efficient ND converge on the ARO
			format.
			Status: 8-bit integer. A new value of 3 is suggested to indicate a
	rejection due to an obsolete TID, typically an indication of a		rejection due to an obsolete TID, typically an indication of a
	movement.		movement.
	RPLInstanceID: 8-bit integer. This field is set to 0 when unused.		RPLInstanceID: 8-bit integer. This field is set to 0 when unused.
	Otherwise it contains the RPLInstanceID for which this address is		Otherwise it contains the RPLInstanceID for which this address is
	registered, as specified in RPL [RFC6550], and discussed in		registered, as specified in RPL [RFC6550], and discussed in
	particular in section 3.1.2.		particular in section 3.1.2.
	P: One bit flag. When the bit is set, the address being registered		P: One bit flag. When the bit is set, the address being registered
	is Target of the NS as opposed to the Source, for instance to		is Target of the NS as opposed to the Source, for instance to
	enable ND proxy operation.		enable ND proxy operation.
	N: One bit flag. Set if the device moved. If not set, the 6BBR will		N: One bit flag. Set if the device moved. If not set, the 6BBR will
	refrain from sending gratuitous NA(O) or other form of distributed		refrain from sending gratuitous NA(O) or other form of distributed
	ND cache clean-up over the backbone. For instance, the flag		ND cache clean-up over the backbone. For instance, the flag
	should be reset after the DAD operation upon address formation.		should be reset after the DAD operation upon address formation.
	Author's Address		Authors' Addresses
	Pascal Thubert, editor		Pascal Thubert (editor)
	Cisco Systems, Inc		Cisco Systems, Inc
	Building D		Building D
	45 Allee des Ormes - BP1200		45 Allee des Ormes - BP1200
	MOUGINS - Sophia Antipolis, 06254		MOUGINS - Sophia Antipolis 06254
	FRANCE		FRANCE
	Phone: +33 497 23 26 34		Phone: +33 497 23 26 34
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
			Peter van der Stok
			consultant
			Phone: +31-492474673 (Netherlands), +33-966015248 (France)
			Email: consultancy@vanderstok.org
			URI: www.vanderstok.org
End of changes. 95 change blocks.
	262 lines changed or deleted		308 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/