draft-ietf-6lo-rfc6775-update-12.txt		draft-ietf-6lo-rfc6775-update-13.txt
	6lo P. Thubert, Ed.		6lo P. Thubert, Ed.
	Internet-Draft cisco		Internet-Draft cisco
	Updates: 6775 (if approved) E. Nordmark		Updates: 6775 (if approved) E. Nordmark
	Intended status: Standards Track Zededa		Intended status: Standards Track Zededa
	Expires: August 24, 2018 S. Chakrabarti		Expires: August 26, 2018 S. Chakrabarti
	Verizon		Verizon
	C. Perkins		C. Perkins
	Futurewei		Futurewei
	February 20, 2018		February 22, 2018
	An Update to 6LoWPAN ND		An Update to 6LoWPAN ND
	draft-ietf-6lo-rfc6775-update-12		draft-ietf-6lo-rfc6775-update-13
	Abstract		Abstract
	This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to		This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to
	clarify the role of the protocol as a registration technique,		clarify the role of the protocol as a registration technique,
	simplify the registration operation in 6LoWPAN routers, as well as to		simplify the registration operation in 6LoWPAN routers, as well as to
	provide enhancements to the registration capabilities and mobility		provide enhancements to the registration capabilities and mobility
	detection for different network topologies including the backbone		detection for different network topologies including the backbone
	routers performing proxy Neighbor Discovery in a low power network.		routers performing proxy Neighbor Discovery in a low power network.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 August 24, 2018.		This Internet-Draft will expire on August 26, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Internet-Draft An Update to 6LoWPAN ND February
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Applicability of Address Registration Options . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Applicability of Address Registration Options . . . . . . . . 5
	4. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 6		4. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Extended Address Registration Option (EARO) . . . . . . . 7		4.1. Extended Address Registration Option (EARO) . . . . . . . 7
	4.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 7		4.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 7
	4.2.1. Comparing TID values . . . . . . . . . . . . . . . . 8		4.2.1. Comparing TID values . . . . . . . . . . . . . . . . 7
	4.3. Registration Unique ID . . . . . . . . . . . . . . . . . 9		4.3. Registration Unique ID . . . . . . . . . . . . . . . . . 9
	4.4. Extended Duplicate Address Messages . . . . . . . . . . . 10		4.4. Extended Duplicate Address Messages . . . . . . . . . . . 10
	4.5. Registering the Target Address . . . . . . . . . . . . . 10		4.5. Registering the Target Address . . . . . . . . . . . . . 10
	4.6. Link-Local Addresses and Registration . . . . . . . . . . 11		4.6. Link-Local Addresses and Registration . . . . . . . . . . 11
	4.7. Maintaining the Registration States . . . . . . . . . . . 12		4.7. Maintaining the Registration States . . . . . . . . . . . 12
	5. Detecting Enhanced ARO Capability Support . . . . . . . . . . 14		5. Detecting Enhanced ARO Capability Support . . . . . . . . . . 14
	6. Extended ND Options And Messages . . . . . . . . . . . . . . 14		6. Extended ND Options And Messages . . . . . . . . . . . . . . 14
	6.1. Enhanced Address Registration Option (EARO) . . . . . . . 14		6.1. Enhanced Address Registration Option (EARO) . . . . . . . 14
	6.2. Extended Duplicate Address Message Formats . . . . . . . 17		6.2. Extended Duplicate Address Message Formats . . . . . . . 16
	6.3. New 6LoWPAN Capability Bits in the Capability Indication		6.3. New 6LoWPAN Capability Bits in the Capability Indication
	Option . . . . . . . . . . . . . . . . . . . . . . . . . 18		Option . . . . . . . . . . . . . . . . . . . . . . . . . 17
	7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 19		7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 18
	7.1. Discovering the capabilities of an ND peer . . . . . . . 19		7.1. Discovering the capabilities of an ND peer . . . . . . . 18
	7.1.1. Using the "E" Flag in the 6CIO . . . . . . . . . . . 19		7.1.1. Using the "E" Flag in the 6CIO . . . . . . . . . . . 18
	7.1.2. Using the "T" Flag in the EARO . . . . . . . . . . . 19		7.1.2. Using the "T" Flag in the EARO . . . . . . . . . . . 18
	7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 20		7.2. RFC6775-only 6LoWPAN Node . . . . . . . . . . . . . . . . 19
	7.3. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 20		7.3. RFC6775-only 6LoWPAN Router . . . . . . . . . . . . . . . 19
	7.4. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 21		7.4. RFC6775-only 6LoWPAN Border Router . . . . . . . . . . . 20
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 21		8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23		9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	10.1. ARO Flags . . . . . . . . . . . . . . . . . . . . . . . 24		10.1. ARO Flags . . . . . . . . . . . . . . . . . . . . . . . 23
	10.2. ICMP Codes . . . . . . . . . . . . . . . . . . . . . . . 24		10.2. ICMP Codes . . . . . . . . . . . . . . . . . . . . . . . 23
	10.3. New ARO Status values . . . . . . . . . . . . . . . . . 25		10.3. New ARO Status values . . . . . . . . . . . . . . . . . 24
	10.4. New 6LoWPAN capability Bits . . . . . . . . . . . . . . 26		10.4. New 6LoWPAN capability Bits . . . . . . . . . . . . . . 24
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	12.1. Normative References . . . . . . . . . . . . . . . . . . 27		12.1. Normative References . . . . . . . . . . . . . . . . . . 25
	12.2. Informative References . . . . . . . . . . . . . . . . . 28		12.2. Informative References . . . . . . . . . . . . . . . . . 26
	12.3. External Informative References . . . . . . . . . . . . 31		12.3. External Informative References . . . . . . . . . . . . 30
	Appendix A. Applicability and Requirements Served . . . . . . . 32		Appendix A. Applicability and Requirements Served . . . . . . . 30
	Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 33		Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 31
			B.1. Requirements Related to Mobility . . . . . . . . . . . . 31
	Internet-Draft An Update to 6LoWPAN ND February		B.2. Requirements Related to Routing Protocols . . . . . . . . 32
	B.1. Requirements Related to Mobility . . . . . . . . . . . . 33
	B.2. Requirements Related to Routing Protocols . . . . . . . . 33
	B.3. Requirements Related to the Variety of Low-Power Link		B.3. Requirements Related to the Variety of Low-Power Link
	types . . . . . . . . . . . . . . . . . . . . . . . . . . 34		types . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	B.4. Requirements Related to Proxy Operations . . . . . . . . 35		B.4. Requirements Related to Proxy Operations . . . . . . . . 34
	B.5. Requirements Related to Security . . . . . . . . . . . . 35		B.5. Requirements Related to Security . . . . . . . . . . . . 34
	B.6. Requirements Related to Scalability . . . . . . . . . . . 37		B.6. Requirements Related to Scalability . . . . . . . . . . . 35
	B.7. Matching Requirements with Specifications . . . . . . . . 37		B.7. Requirements Related to Operations and Management . . . . 36
			B.8. Matching Requirements with Specifications . . . . . . . . 36
	Appendix C. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . 38		Appendix C. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	The scope of this draft is an IPv6 Low Power Networks including star		The scope of this draft is an IPv6 Low Power Networks including star
	and mesh topologies. This specification modifies and extends the		and mesh topologies. This specification modifies and extends the
	behavior and protocol elements of "Neighbor Discovery Optimization		behavior and protocol elements of "Neighbor Discovery Optimization
	for IPv6 over Low-Power Wireless Personal Area Networks" (6LoWPAN ND)		for IPv6 over Low-Power Wireless Personal Area Networks" (6LoWPAN ND)
	[RFC6775] to enable additional capabilities and enhancements such as:		[RFC6775] to enable additional capabilities and enhancements such as:
	o Support for indicating mobility vs retry (T-bit)		o Support for indicating mobility vs retry (T-bit)
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 25 ¶
	1. Introduction		1. Introduction
	The scope of this draft is an IPv6 Low Power Networks including star		The scope of this draft is an IPv6 Low Power Networks including star
	and mesh topologies. This specification modifies and extends the		and mesh topologies. This specification modifies and extends the
	behavior and protocol elements of "Neighbor Discovery Optimization		behavior and protocol elements of "Neighbor Discovery Optimization
	for IPv6 over Low-Power Wireless Personal Area Networks" (6LoWPAN ND)		for IPv6 over Low-Power Wireless Personal Area Networks" (6LoWPAN ND)
	[RFC6775] to enable additional capabilities and enhancements such as:		[RFC6775] to enable additional capabilities and enhancements such as:
	o Support for indicating mobility vs retry (T-bit)		o Support for indicating mobility vs retry (T-bit)
	o Simplify the registration flow for link-local addresses		o Simplify the registration flow for link-local addresses
	o Enhancement to Address Registration Option (ARO)		o Enhancement to Address Registration Option (ARO)
	o Permitting registration of a target address		o Permitting registration of a target address
	o Clarification of support of privacy and temporary addresses		o Clarification of support of privacy and temporary addresses
	The applicability of 6LoWPAN ND registration is discussed in		The applicability of 6LoWPAN ND registration is discussed in
	Section 2, and new extensions and updates to [RFC6775] are presented		Section 3, and new extensions and updates to [RFC6775] are presented
	in Section 4. Considerations on Backward Compatibility, Security and		in Section 4. Considerations on Backward Compatibility, Security and
	Privacy are also elaborated upon in Section 7, Section 8 and in		Privacy are also elaborated upon in Section 7, Section 8 and in
	Section 9, respectively.		Section 9, respectively.
	2. Applicability of Address Registration Options		2. Terminology
	The purpose of the Address Registration Option (ARO) in the legacy
	6LoWPAN ND specification is to facilitate duplicate address detection
	(DAD) for hosts as well as populate Neighbor Cache Entries (NCE)
	[RFC4861] in the routers. This reduces the reliance on multicast
	operations, which are often as intrusive as broadcast, in IPv6 ND
	operations.
	With this specification, a failed or useless registration can be
	detected for reasons other than address duplication. Examples
	include: the router having run out of space; a registration bearing a
	stale sequence number perhaps denoting a movement of the host after
	Internet-Draft An Update to 6LoWPAN ND February
	the registration was placed; a host misbehaving and attempting to
	register an invalid address such as the unspecified address
	[RFC4291]; or a host using an address which is not topologically
	correct on that link.
	In such cases the host will receive an error to help diagnose the
	issue and may retry, possibly with a different address, and possibly
	registering to a different router, depending on the returned error.
	The ability to return errors to address registrations is not intended
	to be used to restrict the ability of hosts to form and use multiple
	addresses, as recommended in "Host Address Availability
	Recommendations" [RFC7934].
	In particular, the freedom to form and register addresses is needed
	for enhanced privacy; each host may register a number of addresses
	using mechanisms such as "Privacy Extensions for Stateless Address
	Autoconfiguration (SLAAC) in IPv6" [RFC4941].
	In IPv6 ND [RFC4861], a router must have enough storage to hold
	neighbor cache entries for all the addresses to which it may forward.
	A router using the Address Registration mechanism also needs enough
	storage to hold NCEs for all the addresses that may be registered to
	it, regardless of whether or not they are actively communicating.
	The number of registrations supported by a 6LoWPAN Router (6LR) or
	6LoWPAN Border Router (6LBR) must be clearly documented.
	A network administrator should deploy updated 6LR/6LBRs to support
	the number and type of devices in their network, based on the number
	of IPv6 addresses that those devices require and their address
	renewal rate and behavior.
	3. 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].
	The Terminology used in this document is consistent with and		The Terminology used in this document is consistent with and
	incorporates that described in Terms Used in Routing for Low-Power		incorporates that described in Terms Used in Routing for Low-Power
	and Lossy Networks (LLNs). [RFC7102].		and Lossy Networks (LLNs). [RFC7102].
	Other terms in use in LLNs are found in Terminology for Constrained-		Other terms in use in LLNs are found in Terminology for Constrained-
	skipping to change at page 4, line 53 ¶		skipping to change at page 4, line 4 ¶
	The Terminology used in this document is consistent with and		The Terminology used in this document is consistent with and
	incorporates that described in Terms Used in Routing for Low-Power		incorporates that described in Terms Used in Routing for Low-Power
	and Lossy Networks (LLNs). [RFC7102].		and Lossy Networks (LLNs). [RFC7102].
	Other terms in use in LLNs are found in Terminology for Constrained-		Other terms in use in LLNs are found in Terminology for Constrained-
	Node Networks [RFC7228].		Node Networks [RFC7228].
	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		that are discussed in
	o "Neighbor Discovery for IP version 6" [RFC4861],		o "Neighbor Discovery for IP version 6" [RFC4861],
	Internet-Draft An Update to 6LoWPAN ND February
	o "IPv6 Stateless Address Autoconfiguration" [RFC4862],		o "IPv6 Stateless Address Autoconfiguration" [RFC4862],
	o "Problem Statement and Requirements for IPv6 over Low-Power		o "Problem Statement and Requirements for IPv6 over Low-Power
	Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606],		Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606],
	o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):		o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals" [RFC4919],		Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
	o "Neighbor Discovery Optimization for Low-power and Lossy Networks"		o "Neighbor Discovery Optimization for Low-power and Lossy Networks"
	[RFC6775] and		[RFC6775] and
	o "Multi-link Subnet Support in IPv6"		o "Multi-link Subnet Support in IPv6"
	[I-D.ietf-ipv6-multilink-subnets],		[I-D.ietf-ipv6-multilink-subnets],
	as well as the following terminology:		as well as the following terminology:
	Backbone Link: An IPv6 transit link that interconnects two or more		Backbone Link: An IPv6 transit link that interconnects two or more
	Backbone Routers. It is expected to be a higher speed device		Backbone Routers. It is expected to be of high speed compared
	speed compared to the LLN in order to carry the traffic that is		to the LLN in order to carry the traffic that is required to
	required to federate multiple segments of the potentially large		federate multiple segments of the potentially large LLN into a
	LLN into a single IPv6 subnet.		single IPv6 subnet.
	Backbone Router: A logical network function in an IPv6 router that		Backbone Router: A logical network function in an IPv6 router that
	federates a LLN over a Backbone Link. In order to do so, the		federates a LLN over a Backbone Link. In order to do so, the
	Backbone Router (6BBR) proxies the 6LoWPAN ND operations		Backbone Router (6BBR) proxies the 6LoWPAN ND operations
	detailed in the document onto the matching operations that run		detailed in the document onto the matching operations that run
	over the backbone, typically IPv6 ND. Note that 6BBR is a		over the backbone, typically IPv6 ND. Note that 6BBR is a
	logical function, just like 6LR and 6LBR, and that a same		logical function, just like 6LR and 6LBR, and that a same
	physical router may operate all three.		physical router may operate all three.
	Extended LLN: The aggregation of multiple LLNs as defined in		Extended LLN: The aggregation of multiple LLNs as defined in
	[RFC4919], interconnected by a Backbone Link via Backbone		[RFC4919], interconnected by a Backbone Link via Backbone
	Routers, and forming a single IPv6 MultiLink Subnet.		Routers, and forming a single IPv6 MultiLink Subnet.
	Registration: The process during which a 6LN registers its		Registration: The process during which a 6LN registers its
	address(es) with the Border Router so the 6BBR can serve as		address(es) with the Border Router so the 6BBR can serve as
	proxy for ND operations over the Backbone.		proxy for ND operations over the Backbone.
	Binding: The association between an IP address with a MAC address, a		Binding: The association between an IP address with a MAC address, a
	port and/or other information about the node that owns the IP		port and/or other information about the node that owns the IP
	address.		address.
	Registered Node: The node for which the registration is performed,		Registered Node: The node for which the registration is performed,
	and which owns the fields in the EARO option.		and which owns the fields in the EARO option.
	Registering Node: The node that performs the registration to the		Registering Node: The node that performs the registration to the
	6BBR, which may proxy for the registered node.		6BBR, which may proxy for the registered node.
	Internet-Draft An Update to 6LoWPAN ND February
	Registered Address: An address owned by the Registered Node node		Registered Address: An address owned by the Registered Node node
	that was or is being registered.		that was or is being registered.
			RFC6775-only: Applied to a type of node or a type of message, this
			adjective indicates a behavior that is strictly as specified by
			[RFC6775] as opposed to updated with this specification.
			updated: a 6LN, a 6LR or a 6LBR that supports this specification.
	legacy: a 6LN, a 6LR or a 6LBR that supports [RFC6775] but not this		3. Applicability of Address Registration Options
	specification.
	updated: a 6LN, a 6LR or a 6LBR that supports this specification.		The purpose of the Address Registration Option (ARO) in [RFC6775] is
			to facilitate duplicate address detection (DAD) for hosts as well as
			populate Neighbor Cache Entries (NCE) [RFC4861] in the routers. This
			reduces the reliance on multicast operations, which are often as
			intrusive as broadcast, in IPv6 ND operations.
			With this specification, a failed or useless registration can be
			detected by a 6LR or a 6LBR for reasons other than address
			duplication. Examples include: the router having run out of space; a
			registration bearing a stale sequence number perhaps denoting a
			movement of the host after the registration was placed; a host
			misbehaving and attempting to register an invalid address such as the
			unspecified address [RFC4291]; or a host using an address which is
			not topologically correct on that link.
			In such cases the host will receive an error to help diagnose the
			issue and may retry, possibly with a different address, and possibly
			registering to a different router, depending on the returned error.
			The ability to return errors to address registrations is not intended
			to be used to restrict the ability of hosts to form and use multiple
			addresses, as recommended in "Host Address Availability
			Recommendations" [RFC7934].
			In particular, the freedom to form and register addresses is needed
			for enhanced privacy; each host may register a number of addresses
			using mechanisms such as "Privacy Extensions for Stateless Address
			Autoconfiguration (SLAAC) in IPv6" [RFC4941].
			In IPv6 ND [RFC4861], a router must have enough storage to hold
			neighbor cache entries for all the addresses to which it may forward.
			A router using the Address Registration mechanism also needs enough
			storage to hold NCEs for all the addresses that may be registered to
			it, regardless of whether or not they are actively communicating.
			The number of registrations supported by a 6LoWPAN Router (6LR) or
			6LoWPAN Border Router (6LBR) must be clearly documented.
			A network administrator should deploy updated 6LR/6LBRs to support
			the number and type of devices in their network, based on the number
			of IPv6 addresses that those devices require and their address
			renewal rate and behavior.
	4. Updating RFC 6775		4. Updating RFC 6775
	This specification introduces the Extended Address Registration		This specification introduces the Extended Address Registration
	Option (EARO) based on the ARO as defined [RFC6775]; in particular a		Option (EARO) based on the ARO as defined [RFC6775]; in particular a
	"T" flag is added that MUST be set in NS messages when this		"T" flag is added that MUST be set in NS messages when this
	specification is used, and echoed in NA messages to confirm that the		specification is used, and echoed in NA messages to confirm that the
	protocol is supported.		protocol is supported.
	The extensions to the ARO option are used in the Duplicate Address		The extensions to the ARO option are used in the Duplicate Address
	Request (DAR) and Duplicate Address Confirmation (DAC) messages, so		Request (DAR) and Duplicate Address Confirmation (DAC) messages, so
	as to convey the additional information all the way to the 6LBR. In		as to convey the additional information all the way to the 6LBR. In
	turn the 6LBR may proxy the registration using IPv6 ND over a		turn the 6LBR may proxy the registration using IPv6 ND over a
	backbone as illustrated in Figure 1. Note that this specification		Backbone Link as illustrated in Figure 1. Note that this
	avoids the extended DAR flow for Link Local Addresses in a Route-Over		specification avoids the extended DAR flow for Link Local Addresses
	[RFC6606] mesh.		in a Route-Over [RFC6606] mesh.
	6LN 6LR 6LBR 6BBR		6LN 6LR 6LBR 6BBR
	| | | |		| | | |
	| NS(EARO) | | |		| NS(EARO) | | |
	|--------------->| | |		|--------------->| | |
	| | Extended DAR | |		| | Extended DAR | |
	| |-------------->| |		| |-------------->| |
	| | | |		| | | |
	| | | proxy NS(EARO) |		| | | proxy NS(EARO) |
	| | |--------------->|		| | |--------------->|
	skipping to change at page 7, line 5 ¶		skipping to change at page 6, line 38 ¶
	| | | proxy NA(EARO) |		| | | proxy NA(EARO) |
	| | |<---------------|		| | |<---------------|
	| | Extended DAC | |		| | Extended DAC | |
	| |<--------------| |		| |<--------------| |
	| NA(EARO) | | |		| NA(EARO) | | |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	Figure 1: (Re-)Registration Flow		Figure 1: (Re-)Registration Flow
	Internet-Draft An Update to 6LoWPAN ND February
	In order to support various types of link layers, it is RECOMMENDED		In order to support various types of link layers, it is RECOMMENDED
	to allow multiple registrations, including for privacy / temporary		to allow multiple registrations, including for privacy / temporary
	addresses, and provide new mechanisms to help clean up stale		addresses, and provide new mechanisms to help clean up stale
	registration states as soon as possible.		registration states as soon as possible.
	Section 5 of [RFC6775] specifies how a 6LN bootstraps an interface		Section 5 of [RFC6775] specifies how a 6LN bootstraps an interface
	and locates available 6LRs; a Registering Node SHOULD prefer		and locates available 6LRs; a Registering Node SHOULD prefer
	registering to a 6LR that is found to support this specification, as		registering to a 6LR that is found to support this specification, as
	discussed in Section 7.1, over a legacy one.		discussed in Section 7.1, over a RFC6775-only one.
	4.1. Extended Address Registration Option (EARO)		4.1. Extended Address Registration Option (EARO)
	The Extended ARO (EARO) deprecates the ARO and is backward compatible		The Extended ARO (EARO) deprecates the ARO and is backward compatible
	with it. More details on backward compatibility can be found in		with it. More details on backward compatibility can be found in
	Section 7.		Section 7.
	The semantics of the ARO are modified as follows:		The semantics of the ARO are modified as follows:
	o The address that is being registered with a Neighbor Solicitation		o The address that is being registered with a Neighbor Solicitation
	skipping to change at page 8, line 5 ¶		skipping to change at page 7, line 40 ¶
	4.2. Transaction ID		4.2. Transaction ID
	The Transaction ID (TID) is a sequence number that is incremented		The Transaction ID (TID) is a sequence number that is incremented
	with each re-registration. The TID is used to detect the freshness		with each re-registration. The TID is used to detect the freshness
	of the registration request and useful to detect one single		of the registration request and useful to detect one single
	registration by multiple 6LoWPAN border routers (e.g., 6LBRs and		registration by multiple 6LoWPAN border routers (e.g., 6LBRs and
	6BBRs) supporting the same 6LoWPAN. The TID may also be used by the		6BBRs) supporting the same 6LoWPAN. The TID may also be used by the
	network to track the sequence of movements of a node in order to		network to track the sequence of movements of a node in order to
	route to the current (freshest known) location of a moving node.		route to the current (freshest known) location of a moving node.
	Internet-Draft An Update to 6LoWPAN ND February
	When a Registered Node is registered with multiple 6BBRs in parallel,		When a Registered Node is registered with multiple 6BBRs in parallel,
	the same TID SHOULD be used, to enable the 6BBRs to determine that		the same TID SHOULD be used, to enable the 6BBRs to determine that
	the registrations are the same, and distinguish that situation from a		the registrations are the same, and distinguish that situation from a
	movement.		movement.
	4.2.1. Comparing TID values		4.2.1. Comparing TID values
	The TID is a sequence counter and its operation is the exact match of		The TID is a sequence counter and its operation is the exact match of
	the path sequence specified in RPL, the IPv6 Routing Protocol for		the path sequence specified in RPL, the IPv6 Routing Protocol for
	Low-Power and Lossy Networks [RFC6550] specification.		Low-Power and Lossy Networks [RFC6550] specification.
	skipping to change at page 8, line 43 ¶		skipping to change at page 8, line 30 ¶
	detailed below.		detailed below.
	A window of comparison, SEQUENCE_WINDOW = 16, is configured based on		A window of comparison, SEQUENCE_WINDOW = 16, is configured based on
	a value of 2^N, where N is defined to be 4 in this specification.		a value of 2^N, where N is defined to be 4 in this specification.
	For a given sequence counter,		For a given sequence counter,
	1. The sequence counter SHOULD be initialized to an implementation		1. The sequence counter SHOULD be initialized to an implementation
	defined value which is 128 or greater prior to use. A		defined value which is 128 or greater prior to use. A
	recommended value is 240 (256 - SEQUENCE_WINDOW).		recommended value is 240 (256 - SEQUENCE_WINDOW).
	2. When a sequence counter increment would cause the sequence		2. When a sequence counter increment would cause the sequence
	counter to increment beyond its maximum value, the sequence		counter to increment beyond its maximum value, the sequence
	counter MUST wrap back to zero. When incrementing a sequence		counter MUST wrap back to zero. When incrementing a sequence
	counter greater than or equal to 128, the maximum value is 255.		counter greater than or equal to 128, the maximum value is 255.
	When incrementing a sequence counter less than 128, the maximum		When incrementing a sequence counter less than 128, the maximum
	value is 127.		value is 127.
	3. When comparing two sequence counters, the following rules MUST be		3. When comparing two sequence counters, the following rules MUST be
	applied:		applied:
	Internet-Draft An Update to 6LoWPAN ND February
	1. When a first sequence counter A is in the interval [128..255]		1. When a first sequence counter A is in the interval [128..255]
	and a second sequence counter B is in [0..127]:		and a second sequence counter B is in [0..127]:
	1. If (256 + B - A) is less than or equal to		1. If (256 + B - A) is less than or equal to
	SEQUENCE_WINDOW, then B is greater than A, A is less than		SEQUENCE_WINDOW, then B is greater than A, A is less than
	B, and the two are not equal.		B, and the two are not equal.
	2. If (256 + B - A) is greater than SEQUENCE_WINDOW, then A		2. If (256 + B - A) is greater than SEQUENCE_WINDOW, then A
	is greater than B, B is less than A, and the two are not		is greater than B, B is less than A, and the two are not
	equal.		equal.
	For example, if A is 240, and B is 5, then (256 + 5 - 240) is		For example, if A is 240, and B is 5, then (256 + 5 - 240) is
	21. 21 is greater than SEQUENCE_WINDOW (16), thus 240 is		21. 21 is greater than SEQUENCE_WINDOW (16), thus 240 is
	greater than 5. As another example, if A is 250 and B is 5,		greater than 5. As another example, if A is 250 and B is 5,
	then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW		then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW
	(16), thus 250 is less than 5.		(16), thus 250 is less than 5.
	2. In the case where both sequence counters to be compared are		2. In the case where both sequence counters to be compared are
	less than or equal to 127, and in the case where both		less than or equal to 127, and in the case where both
	sequence counters to be compared are greater than or equal to		sequence counters to be compared are greater than or equal to
	128:		128:
	1. If the absolute magnitude of difference between the two		1. If the absolute magnitude of difference between the two
	sequence counters is less than or equal to		sequence counters is less than or equal to
	SEQUENCE_WINDOW, then a comparison as described in		SEQUENCE_WINDOW, then a comparison as described in
	[RFC1982] is used to determine the relationships greater		[RFC1982] is used to determine the relationships greater
	than, less than, and equal.		than, less than, and equal.
	skipping to change at page 9, line 51 ¶		skipping to change at page 9, line 31 ¶
	the results of the comparison are not defined, then a node should		the results of the comparison are not defined, then a node should
	give precedence to the sequence number that was most recently		give precedence to the sequence number that was most recently
	incremented. Failing this, the node should select the sequence		incremented. Failing this, the node should select the sequence
	number in order to minimize the resulting changes to its own		number in order to minimize the resulting changes to its own
	state.		state.
	4.3. Registration Unique ID		4.3. Registration Unique ID
	The Registration Unique ID (RUID) enables a duplicate address		The Registration Unique ID (RUID) enables a duplicate address
	registration to be distinguished from a double registration or a		registration to be distinguished from a double registration or a
	movement. An ND message from the 6BBR over the Backbone that is		movement. An ND message from the 6BBR over the Backbone Link that is
	proxied on behalf of a Registered Node must carry the most recent		proxied on behalf of a Registered Node must carry the most recent
	EARO option seen for that node. A NS/NA with an EARO and a NS/NA		EARO option seen for that node. A NS/NA with an EARO and a NS/NA
	Internet-Draft An Update to 6LoWPAN ND February
	without a EARO thus represent different nodes; if they relate to a		without a EARO thus represent different nodes; if they relate to a
	same target then an address duplication is likely.		same target then an address duplication is likely.
	The Registration Unique ID in [RFC6775] is a EUI-64 globally unique		The Registration Unique ID in [RFC6775] is a EUI-64 globally unique
	address configured at a Lower Layer, under the assumption that		address configured at a Lower Layer, under the assumption that
	duplicate EUI-64 addresses are avoided.		duplicate EUI-64 addresses are avoided.
	With this specification, the Registration Unique ID is allowed to be		With this specification, the Registration Unique ID is allowed to be
	extended to different types of identifier, as long as the type is		extended to different types of identifier, as long as the type is
	clearly indicated. For instance, the type can be a cryptographic		clearly indicated. For instance, the type can be a cryptographic
	skipping to change at page 10, line 42 ¶		skipping to change at page 10, line 23 ¶
	TID field is added to the Extended DAR (EDAR) and the Extended DAC		TID field is added to the Extended DAR (EDAR) and the Extended DAC
	(EDAC) messages as a replacement to a Reserved field, and an odd		(EDAC) messages as a replacement to a Reserved field, and an odd
	value of the ICMP Code indicates support for the TID, to transport		value of the ICMP Code indicates support for the TID, to transport
	the "T" flag.		the "T" flag.
	In order to prepare for future extensions, and though no option has		In order to prepare for future extensions, and though no option has
	been defined for the Duplicate Address messages, implementations		been defined for the Duplicate Address messages, implementations
	SHOULD expect ND options after the main body, and SHOULD ignore them.		SHOULD expect ND options after the main body, and SHOULD ignore them.
	As for the EARO, the Extended Duplicate Address messages are backward		As for the EARO, the Extended Duplicate Address messages are backward
	compatible with the legacy versions, and remarks concerning backwards		compatible with the RFC6775-only versions, and remarks concerning
	compatibility for the protocol between the 6LN and the 6LR apply		backwards compatibility for the protocol between the 6LN and the 6LR
	similarly between a 6LR and a 6LBR.		apply similarly between a 6LR and a 6LBR.
	4.5. Registering the Target Address		4.5. Registering the Target Address
	The Registering Node is the node that performs the registration to		The Registering Node is the node that performs the registration to
	the 6BBR. As in [RFC6775], it may be the Registered Node as well, in		the 6BBR. As in [RFC6775], it may be the Registered Node as well, in
	which case it registers one of its own addresses, and indicates its		which case it registers one of its own addresses, and indicates its
	own MAC Address as Source Link Layer Address (SLLA) in the NS(EARO).		own MAC Address as Source Link Layer Address (SLLA) in the NS(EARO).
	This specification adds the capability to proxy the registration		This specification adds the capability to proxy the registration
	operation on behalf of a Registered Node that is reachable over a LLN		operation on behalf of a Registered Node that is reachable over a LLN
	Internet-Draft An Update to 6LoWPAN ND February
	mesh. In that case, if the Registered Node is reachable from the		mesh. In that case, if the Registered Node is reachable from the
	6BBR over a Mesh-Under mesh, the Registering Node indicates the MAC		6BBR over a Mesh-Under mesh, the Registering Node indicates the MAC
	Address of the Registered Node as SLLA in the NS(EARO). If the		Address of the Registered Node as SLLA in the NS(EARO). If the
	Registered Node is reachable over a Route-Over mesh from the		Registered Node is reachable over a Route-Over mesh from the
	Registering Node, the SLLA in the NS(ARO) is that of the Registering		Registering Node, the SLLA in the NS(ARO) is that of the Registering
	Node. This enables the Registering Node to attract the packets from		Node. This enables the Registering Node to attract the packets from
	the 6BBR and route them over the LLN to the Registered Node.		the 6BBR and route them over the LLN to the Registered Node.
	In order to enable the latter operation, this specification changes		In order to enable the latter operation, this specification changes
	the behavior of the 6LN and the 6LR so that the Registered Address is		the behavior of the 6LN and the 6LR so that the Registered Address is
	found in the Target Address field of the NS and NA messages as		found in the Target Address field of the NS and NA messages as
	opposed to the Source Address. With this convention, a TLLA option		opposed to the Source Address. With this convention, a TLLA option
	indicates the link-layer address of the 6LN that owns the address,		indicates the link-layer address of the 6LN that owns the address,
	whereas the SLLA Option in a NS message indicates that of the		whereas the SLLA Option in a NS message indicates that of the
	Registering Node, which can be the owner device, or a proxy.		Registering Node, which can be the owner device, or a proxy.
	The Registering Node is reachable from the 6LR, and is also the one		The Registering Node is reachable from the 6LR, and is also the one
	expecting packets for the 6LN. Therefore, it MUST place its own Link		expecting packets for the 6LN. Therefore, it MUST place its own Link
	Layer Address in the SLLA Option that MUST always be placed in a		Layer Address in the SLLA Option that MUST always be placed in a
	registration NS(EARO) message. This maintains compatibility with		registration NS(EARO) message. This maintains compatibility with
	legacy 6LoWPAN ND [RFC6775].		RFC6775-only 6LoWPAN ND [RFC6775].
	4.6. Link-Local Addresses and Registration		4.6. Link-Local Addresses and Registration
	Considering that LLN nodes are often not wired and may move, there is		Considering that LLN nodes are often not wired and may move, there is
	no guarantee that a Link-Local address stays unique between a		no guarantee that a Link-Local address stays unique between a
	potentially variable and unbounded set of neighboring nodes.		potentially variable and unbounded set of neighboring nodes.
	Compared to [RFC6775], this specification only requires that a Link-		Compared to [RFC6775], this specification only requires that a Link-
	Local address is unique from the perspective of the two nodes that		Local address is unique from the perspective of the two nodes that
	use it to communicate (e.g. the 6LN and the 6LR in an NS/NA		use it to communicate (e.g. the 6LN and the 6LR in an NS/NA
	skipping to change at page 12, line 4 ¶		skipping to change at page 11, line 37 ¶
	they are reachable over one hop and that at least one of the 2 nodes		they are reachable over one hop and that at least one of the 2 nodes
	acts as a 6LR. A node MUST register a Link-Local address to a 6LR in		acts as a 6LR. A node MUST register a Link-Local address to a 6LR in
	order to obtain reachability from that 6LR beyond the current		order to obtain reachability from that 6LR beyond the current
	exchange, and in particular to use the Link-Local address as source		exchange, and in particular to use the Link-Local address as source
	address to register other addresses, e.g. global addresses.		address to register other addresses, e.g. global addresses.
	If there is no collision with an address previously registered to		If there is no collision with an address previously registered to
	this 6LR by another 6LN, then the Link-Local address is unique from		this 6LR by another 6LN, then the Link-Local address is unique from
	the standpoint of this 6LR and the registration is acceptable.		the standpoint of this 6LR and the registration is acceptable.
	Alternatively, two different 6LRs might expose the same Link-Local		Alternatively, two different 6LRs might expose the same Link-Local
	Internet-Draft An Update to 6LoWPAN ND February
	address but different link-layer addresses. In that case, a 6LN MUST		address but different link-layer addresses. In that case, a 6LN MUST
	only interact with at most one of the 6LRs.		only interact with at most one of the 6LRs.
	The DAD process between the 6LR and a 6LBR, which is based on an		The DAD process between the 6LR and a 6LBR, which is based on an
	exchange of Duplicate Address messages, does not need to take place		exchange of Duplicate Address messages, does not need to take place
	for Link-Local addresses.		for Link-Local addresses.
	When registering to a 6LR that conforms this specification, a node		When registering to a 6LR that conforms this specification, a node
	MUST use a Link-Local address as the source address of the		MUST use a Link-Local address as the source address of the
	registration, whatever the type of IPv6 address that is being		registration, whatever the type of IPv6 address that is being
	skipping to change at page 13, line 4 ¶		skipping to change at page 12, line 36 ¶
	4.7. Maintaining the Registration States		4.7. Maintaining the Registration States
	This section discusses protocol actions that involve the Registering		This section discusses protocol actions that involve the Registering
	Node, the 6LR and the 6LBR. It must be noted that the portion that		Node, the 6LR and the 6LBR. It must be noted that the portion that
	deals with a 6LBR only applies to those addresses that are registered		deals with a 6LBR only applies to those addresses that are registered
	to it; as discussed in Section 4.6, this is not the case for Link-		to it; as discussed in Section 4.6, this is not the case for Link-
	Local addresses. The registration state includes all data that is		Local addresses. The registration state includes all data that is
	stored in the router relative to that registration, in particular,		stored in the router relative to that registration, in particular,
	but not limited to, an NCE in a 6LR. 6LBRs and 6BBRs may store		but not limited to, an NCE in a 6LR. 6LBRs and 6BBRs may store
	additional registration information in more complex data structures		additional registration information in more complex data structures
	Internet-Draft An Update to 6LoWPAN ND February
	and use protocols that are out of scope of this document to keep them		and use protocols that are out of scope of this document to keep them
	synchronized when they are distributed.		synchronized when they are distributed.
	When its Neighbor Cache is full, a 6LR cannot accept a new		When its Neighbor Cache is full, a 6LR cannot accept a new
	registration. In that situation, the EARO is returned in a NA		registration. In that situation, the EARO is returned in a NA
	message with a Status of 2, and the Registering Node may attempt to		message with a Status of 2, and the Registering Node may attempt to
	register to another 6LR.		register to another 6LR.
	If the registry in the 6LBR is saturated, the LBR cannot guarantee		If the registry in the 6LBR is saturated, then the LBR cannot decide
	that a new address is effectively not a duplicate. In that case, the		whether a new address is a duplicate. In that case, the 6LBR replies
	6LBR replies to a EDAR message with a EDAC message that carries a new		to a EDAR message with a EDAC message that carries a new Status Code
	Status Code indicating "6LBR Registry saturated" Table 1. Note: this		indicating "6LBR Registry saturated" Table 1. Note: this code is
	code is used by 6LBRs instead of Status 2 when responding to a		used by 6LBRs instead of Status 2 when responding to a Duplicate
	Duplicate Address message exchange and passed on to the Registering		Address message exchange and passed on to the Registering Node by the
	Node by the 6LR. There is no point for the node to retry this		6LR. There is no point for the node to retry this registration
	registration immediately via another 6LR, since the problem is global		immediately via another 6LR, since the problem is global to the
	to the network. The node may either abandon that address, de-		network. The node may either abandon that address, de-register other
	register other addresses first to make room, or keep the address in		addresses first to make room, or keep the address in TENTATIVE state
	TENTATIVE state and retry later.		and retry later.
	A node renews an existing registration by sending a new NS(EARO)		A node renews an existing registration by sending a new NS(EARO)
	message for the Registered Address. In order to refresh the		message for the Registered Address. In order to refresh the
	registration state in the 6LBR, the registration MUST be reported to		registration state in the 6LBR, the registration MUST be reported to
	the 6LBR.		the 6LBR.
	A node that ceases to use an address SHOULD attempt to de-register		A node that ceases to use an address SHOULD attempt to de-register
	that address from all the 6LRs to which it has registered the		that address from all the 6LRs to which it has registered the
	address, which is achieved using an NS(EARO) message with a		address, which is achieved using an NS(EARO) message with a
	Registration Lifetime of 0.		Registration Lifetime of 0.
	A node that moves away from a particular 6LR SHOULD attempt to de-		A node that moves away from a particular 6LR SHOULD attempt to de-
	register all of its addresses registered to that 6LR and register to		register all of its addresses registered to that 6LR and register to
	a new 6LR with an incremented TID. When/if the node shows up		a new 6LR with an incremented TID. When/if the node shows up
	elsewhere, an asynchronous NA(EARO) or EDAC message with a status of		elsewhere, an asynchronous NA(EARO) or EDAC message with a status of
	3 "Moved" SHOULD be used to clean up the state in the previous		3 "Moved" SHOULD be used to clean up the state in the previous
	location. For instance, as described in		location. For instance, as described in
	[I-D.ietf-6lo-backbone-router], the "Moved" status can be used by a		[I-D.ietf-6lo-backbone-router], the "Moved" status can be used by a
	6BBR in a NA(EARO) message to indicate that the ownership of the		6BBR in a NA(EARO) message to indicate that the ownership of the
	proxy state on the Backbone was transferred to another 6BBR, as the		proxy state on the Backbone Link was transferred to another 6BBR, as
	consequence of a movement of the device. The receiver of the message		the consequence of a movement of the device. The receiver of the
	SHOULD propagate the status down the chain towards the Registered		message SHOULD propagate the status down the chain towards the
	node (e.g. reversing an existing RPL [RFC6550] path) and then clean		Registered node (e.g. reversing an existing RPL [RFC6550] path) and
	up its state.		then clean up its state.
	Upon receiving a NS(EARO) message with a Registration Lifetime of 0		Upon receiving a NS(EARO) message with a Registration Lifetime of 0
	and determining that this EARO is the freshest for a given NCE (see		and determining that this EARO is the freshest for a given NCE (see
	Section 4.2), a 6LR cleans up its NCE. If the address was registered		Section 4.2), a 6LR cleans up its NCE. If the address was registered
	to the 6LBR, then the 6LR MUST report to the 6LBR, through a		to the 6LBR, then the 6LR MUST report to the 6LBR, through a
	Internet-Draft An Update to 6LoWPAN ND February
	Duplicate Address exchange with the 6LBR, indicating the null		Duplicate Address exchange with the 6LBR, indicating the null
	Registration Lifetime and the latest TID that this 6LR is aware of.		Registration Lifetime and the latest TID that this 6LR is aware of.
	Upon receiving the Extended DAR message, the 6LBR evaluates if this		Upon receiving the Extended DAR message, the 6LBR evaluates if this
	is the most recent TID it has received for that particular registry		is the most recent TID it has received for that particular registry
	entry. If so, then the entry is scheduled to be removed, and the		entry. If so, then the entry is scheduled to be removed, and the
	EDAR is answered with a EDAC message bearing a Status of 0		EDAR is answered with a EDAC message bearing a Status of 0
	("Success"). Otherwise, a Status 3 ("Moved") is returned instead,		("Success"). Otherwise, a Status 3 ("Moved") is returned instead,
	and the existing entry is maintained.		and the existing entry is maintained.
	skipping to change at page 15, line 4 ¶		skipping to change at page 14, line 36 ¶
	the following subsections.		the following subsections.
	6.1. Enhanced Address Registration Option (EARO)		6.1. Enhanced Address Registration Option (EARO)
	The Address Registration Option (ARO) is defined in section 4.1. of		The Address Registration Option (ARO) is defined in section 4.1. of
	[RFC6775].		[RFC6775].
	The Enhanced Address Registration Option (EARO) updates the ARO		The Enhanced Address Registration Option (EARO) updates the ARO
	option within Neighbor Discovery NS and NA messages between a 6LN and		option within Neighbor Discovery NS and NA messages between a 6LN and
	its 6LR. On the other hand, the Extended Duplicate Address messages,		its 6LR. On the other hand, the Extended Duplicate Address messages,
	Internet-Draft An Update to 6LoWPAN ND February
	EDAR and EDAC, replace the DAR and DAC messages so as to transport		EDAR and EDAC, replace the DAR and DAC messages so as to transport
	the new information between 6LRs and 6LBRs across LLN meshes such as		the new information between 6LRs and 6LBRs across LLN meshes such as
	6TiSCH networks.		6TiSCH networks.
	An NS message with an EARO option is a registration if and only if it		An NS message with an EARO option is a registration if and only if it
	also carries an SLLAO option. The EARO option also used in NS and NA		also carries an SLLAO option. The EARO option also used in NS and NA
	messages between Backbone Routers [I-D.ietf-6lo-backbone-router] over		messages between Backbone Routers [I-D.ietf-6lo-backbone-router] over
	the Backbone link to sort out the distributed registration state; in		the Backbone Link to sort out the distributed registration state; in
	that case, it does not carry the SLLAO option and is not confused		that case, it does not carry the SLLAO option and is not confused
	with a registration.		with a registration.
	When using the EARO option, the address being registered is found in		When using the EARO option, the address being registered is found in
	the Target Address field of the NS and NA messages.		the Target Address field of the NS and NA messages.
	The EARO extends the ARO and is indicated by the "T" flag set. The		The EARO extends the ARO and is indicated by the "T" flag set. The
	format of the EARO option is as follows:		format of the EARO option is as follows:
	0 1 2 3		0 1 2 3
	skipping to change at page 16, line 4 ¶		skipping to change at page 15, line 34 ¶
	Status: 8-bit unsigned integer. Indicates the status of a		Status: 8-bit unsigned integer. Indicates the status of a
	registration in the NA response. MUST be set to 0 in		registration in the NA response. MUST be set to 0 in
	NS messages. See Table 1 below.		NS messages. See Table 1 below.
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| Value | Description |		| Value | Description |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	| 0..2 | See [RFC6775]. Note: a Status of 1 "Duplicate Address" |		| 0..2 | See [RFC6775]. Note: a Status of 1 "Duplicate Address" |
	| | applies to the Registered Address. If the Source Address |		| | applies to the Registered Address. If the Source Address |
	| | conflicts with an existing registration, "Duplicate |		| | conflicts with an existing registration, "Duplicate |
	Internet-Draft An Update to 6LoWPAN ND February
	| | Source Address" should be used. |		| | Source Address" should be used. |
	| | |		| | |
	| 3 | Moved: The registration failed because it is not the |		| 3 | Moved: The registration failed because it is not the |
	| | freshest. This Status indicates that the registration is |		| | freshest. This Status indicates that the registration is |
	| | rejected because another more recent registration was |		| | rejected because another more recent registration was |
	| | done, as indicated by a same OUI and a more recent TID. |		| | done, as indicated by a same RUID and a more recent TID. |
	| | One possible cause is a stale registration that has |		| | One possible cause is a stale registration that has |
	| | progressed slowly in the network and was passed by a more |		| | progressed slowly in the network and was passed by a more |
	| | recent one. It could also indicate a OUI collision. |		| | recent one. It could also indicate a RUID collision. |
	| | |		| | |
	| 4 | Removed: The binding state was removed. This may be |		| 4 | Removed: The binding state was removed. This may be |
	| | placed in an asynchronous NS(ARO) message, or as the |		| | placed in an asynchronous NS(ARO) message, or as the |
	| | rejection of a proxy registration to a Backbone Router |		| | rejection of a proxy registration to a Backbone Router |
	| | |		| | |
	| 5 | Validation Requested: The Registering Node is challenged |		| 5 | Validation Requested: The Registering Node is challenged |
	| | for owning the Registered Address or for being an |		| | for owning the Registered Address or for being an |
	| | acceptable proxy for the registration. This Status is |		| | acceptable proxy for the registration. This Status is |
	| | expected in asynchronous messages from a registrar (6LR, |		| | expected in asynchronous messages from a registrar (6LR, |
	| | 6LBR, 6BBR) to indicate that the registration state is |		| | 6LBR, 6BBR) to indicate that the registration state is |
	skipping to change at page 17, line 4 ¶		skipping to change at page 16, line 31 ¶
	| | passed on to the Registering Node by the 6LR. |		| | passed on to the Registering Node by the 6LR. |
	| | |		| | |
	| 10 | Validation Failed: The proof of ownership of the |		| 10 | Validation Failed: The proof of ownership of the |
	| | registered address is not correct. |		| | registered address is not correct. |
	+-------+-----------------------------------------------------------+		+-------+-----------------------------------------------------------+
	Table 1: EARO Status		Table 1: EARO Status
	Reserved: This field is unused. It MUST be initialized to zero		Reserved: This field is unused. It MUST be initialized to zero
	by the sender and MUST be ignored by the receiver.		by the sender and MUST be ignored by the receiver.
			T: One bit flag. Set if the next octet is used as a
	Internet-Draft An Update to 6LoWPAN ND February
	T: One bit flag. Set if the next octet is a used as a
	TID.		TID.
	TID: 1-byte integer; a transaction id that is maintained		TID: 1-byte integer; a transaction id that is maintained
	by the node and incremented with each transaction.		by the node and incremented with each transaction.
	The node SHOULD maintain the TID in a persistent		The node SHOULD maintain the TID in a persistent
	storage.		storage.
	Registration Lifetime: 16-bit integer; expressed in minutes. 0		Registration Lifetime: 16-bit integer; expressed in minutes. 0
	means that the registration has ended and the		means that the registration has ended and the
	associated state should be removed.		associated state should be removed.
			Registration Unique IDentifier (RUID): A globally unique identifier
	Registration Unique IDentifier (OUI): A globally unique identifier
	for the node associated. This can be the EUI-64		for the node associated. This can be the EUI-64
	derived IID of an interface, or some provable ID		derived IID of an interface, or some provable ID
	obtained cryptographically.		obtained cryptographically.
	6.2. Extended Duplicate Address Message Formats		6.2. Extended Duplicate Address Message Formats
	The Duplicate Address Request (DAR) and the Duplicate Address		The Duplicate Address Request (DAR) and the Duplicate Address
	Confirmation (DAC) messages are defined in section 4.4 of [RFC6775].		Confirmation (DAC) messages are defined in section 4.4 of [RFC6775].
	Those messages follow a common base format, which enables information		Those messages follow a common base format, which enables information
	from the ARO to be transported over multiple hops.		from the ARO to be transported over multiple hops.
	The Duplicate Address Messages are extended to adapt to the Extended		The Duplicate Address Messages are extended to adapt to the Extended
	ARO format, as follows:		ARO format, as follows:
	Internet-Draft An Update to 6LoWPAN ND February
	0 1 2 3		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		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 | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Status | TID | Registration Lifetime |		| Status | TID | Registration Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Registration Unique ID (EUI-64 or equivalent) +		+ Registration Unique ID (EUI-64 or equivalent) +
	| |		| |
	skipping to change at page 18, line 35 ¶		skipping to change at page 17, line 36 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Duplicate Address Messages Format		Figure 3: Duplicate Address Messages Format
	Modified Message Fields		Modified Message Fields
	Code: The ICMP Code as defined in [RFC4443]. The ICMP Code		Code: The ICMP Code as defined in [RFC4443]. The ICMP Code
	MUST be set to 1 with this specification. An odd		MUST be set to 1 with this specification. An odd
	value of the ICMP Code indicates that the TID field		value of the ICMP Code indicates that the TID field
	is present and obeys this specification.		is present and obeys this specification.
	TID: 1-byte integer; same definition and processing as the		TID: 1-byte integer; same definition and processing as the
	TID in the EARO option as defined in Section 6.1.		TID in the EARO option as defined in Section 6.1.
			Registration Unique IDentifier (RUID): 8 bytes; same definition and
	Registration Unique IDentifier (OUI): 8 bytes; same definition and		processing as the RUID in the EARO option as defined
	processing as the OUI in the EARO option as defined
	in Section 6.1.		in Section 6.1.
	6.3. New 6LoWPAN Capability Bits in the Capability Indication Option		6.3. New 6LoWPAN Capability Bits in the Capability Indication Option
	This specification defines new capability bits for use in the 6CIO,		This specification defines new capability bits for use in the 6CIO,
	which was introduced by [RFC7400] for use in IPv6 ND RA messages.		which was introduced by [RFC7400] for use in IPv6 ND RA messages.
	Routers that support this specification MUST set the "E" flag and 6LN		Routers that support this specification MUST set the "E" flag and 6LN
	SHOULD favor 6LR routers that support this specification over those		SHOULD favor 6LR routers that support this specification over those
	that do not. Routers that are capable of acting as 6LR, 6LBR and		that do not. Routers that are capable of acting as 6LR, 6LBR and
	6BBR SHOULD set the "L", "B" and "P" flags, respectively. In		6BBR SHOULD set the "L", "B" and "P" flags, respectively. In
	particular, the function 6LR is often collocated with that of 6LBR.		particular, the function 6LR is often collocated with that of 6LBR.
	Internet-Draft An Update to 6LoWPAN ND February
	Those flags are not mutually exclusive and if a router is capable of		Those flags are not mutually exclusive and if a router is capable of
	performing multiple functions, it SHOULD set all the related flags.		performing multiple functions, it SHOULD set all the related flags.
	0 1 2 3		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		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length = 1 | Reserved |L|B|P|E|G|		| Type | Length = 1 | Reserved |L|B|P|E|G|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |		| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 19, line 51 ¶		skipping to change at page 18, line 45 ¶
	A router that supports this specification SHOULD indicate that with a		A router that supports this specification SHOULD indicate that with a
	6CIO.		6CIO.
	If the Registering Node receives a 6CIO in a Router Advertisement		If the Registering Node receives a 6CIO in a Router Advertisement
	message, then the setting of the "E" Flag indicates whether or not		message, then the setting of the "E" Flag indicates whether or not
	this specification is supported.		this specification is supported.
	7.1.2. Using the "T" Flag in the EARO		7.1.2. Using the "T" Flag in the EARO
	One alternate way for a 6LN to discover the router's capabilities is		One alternate way for a 6LN to discover the router's capabilities is
	to first register a Link Local address, placing the same address in		to start by registering a Link Local address, placing the same
	the Source and Target Address fields of the NS message, and setting		address in the Source and Target Address fields of the NS message,
	the "T" Flag. The node may for instance register an address that is		and setting the "T" Flag. The node may for instance register an
			address that is based on EUI-64. For such an address, DAD is not
	Internet-Draft An Update to 6LoWPAN ND February		required and using the SLLAO option in the NS is actually more
			consistent with existing ND specifications such as the "Optimistic
	based on EUI-64. For such an address, DAD is not required and using		Duplicate Address Detection (ODAD) for IPv6" [RFC4429].
	the SLLAO option in the NS is actually more consistent with existing
	ND specifications such as the "Optimistic Duplicate Address Detection
	(ODAD) for IPv6" [RFC4429].
	Once its first registration is complete, the node knows from the		Once its first registration is complete, the node knows from the
	setting of the "T" Flag in the response whether the router supports		setting of the "T" Flag in the response whether the router supports
	this specification. If support is verified, the node may register		this specification. If support is verified, the node may register
	other addresses that it owns, or proxy-register addresses on behalf		other addresses that it owns, or proxy-register addresses on behalf
	some another node, indicating those addresses being registered in the		some another node, indicating those addresses being registered in the
	Target Address field of the NS messages, while using one of its own		Target Address field of the NS messages, while using one of its own
	previously registered addresses as source.		previously registered addresses as source.
	A node that supports this specification MUST always use an EARO as a		A node that supports this specification MUST always use an EARO as a
	replacement to an ARO in its registration to a router. This is		replacement to an ARO in its registration to a router. This is
	harmless since the "T" flag and TID field are reserved in [RFC6775],		harmless since the "T" flag and TID field are reserved in [RFC6775],
	and are ignored by a legacy router. A router that supports this		and are ignored by a RFC6775-only router. A router that supports
	specification answers an ARO with an ARO and answers an EARO with an		this specification answers an ARO with an ARO and answers an EARO
	EARO.		with an EARO.
	This specification changes the behavior of the peers in a		This specification changes the behavior of the peers in a
	registration flow. To enable backward compatibility, a 6LN that		registration flow. To enable backward compatibility, a 6LN that
	registers to a 6LR that is not known to support this specification		registers to a 6LR that is not known to support this specification
	MUST behave in a manner that is compatible with [RFC6775]. A 6LN can		MUST behave in a manner that is compatible with [RFC6775]. A 6LN can
	achieve that by sending a NS(EARO) message with a Link-Local Address		achieve that by sending a NS(EARO) message with a Link-Local Address
	used as both Source and Target Address, as described in Section 4.6.		used as both Source and Target Address, as described in Section 4.6.
	Once the 6LR is known to support this specification, the 6LN MUST		Once the 6LR is known to support this specification, the 6LN MUST
	obey this specification.		obey this specification.
	7.2. Legacy 6LoWPAN Node		7.2. RFC6775-only 6LoWPAN Node
	A legacy 6LN will use the Registered Address as source and will not		A RFC6775-only 6LN will use the Registered Address as source and will
	use an EARO option. An updated 6LR MUST accept that registration if		not use an EARO option. An updated 6LR MUST accept that registration
	it is valid per [RFC6775], and it MUST manage the binding cache		if it is valid per [RFC6775], and it MUST manage the binding cache
	accordingly. The updated 6LR MUST then use the legacy Duplicate		accordingly. The updated 6LR MUST then use the RFC6775-only
	Address messages as specified in [RFC6775] to indicate to the 6LBR		Duplicate Address messages as specified in [RFC6775] to indicate to
	that the TID is not present in the messages.		the 6LBR that the TID is not present in the messages.
	The main difference with [RFC6775] is that Duplicate Address exchange		The main difference with [RFC6775] is that Duplicate Address exchange
	for DAD is avoided for Link-Local addresses. In any case, the 6LR		for DAD is avoided for Link-Local addresses. In any case, the 6LR
	SHOULD use an EARO in the reply, and may use any of the Status codes		SHOULD use an EARO in the reply, and may use any of the Status codes
	defined in this specification.		defined in this specification.
	7.3. Legacy 6LoWPAN Router		7.3. RFC6775-only 6LoWPAN Router
	The first registration by an updated 6LN MUST be for a Link-Local		The first registration by an updated 6LN MUST be for a Link-Local
	address, using that Link-Local address as source. A legacy 6LR will		address, using that Link-Local address as source. A RFC6775-only 6LR
			will not make a difference and treat that registration as if the 6LN
	Internet-Draft An Update to 6LoWPAN ND February		was a RFC6775-only node.
	not make a difference and treat that registration as if the 6LN was a
	legacy node.
	An updated 6LN will always use an EARO option in the registration NS		An updated 6LN will always use an EARO option in the registration NS
	message, whereas a legacy 6LR will always reply with an ARO option in		message, whereas a RFC6775-only 6LR will always reply with an ARO
	the NA message. From that first registration, the updated 6LN can		option in the NA message. From that first registration, the updated
	determine whether or not the 6LR supports this specification.		6LN can determine whether or not the 6LR supports this specification.
	After detecting a legacy 6LR, an updated 6LN SHOULD attempt to find		After detecting a RFC6775-only 6LR, an updated 6LN SHOULD attempt to
	an alternate 6LR that is updated for a reasonable time that depends		find an alternate 6LR that is updated for a reasonable time that
	on the type of device and the expected deployment.		depends on the type of device and the expected deployment.
	An updated 6LN SHOULD use an EARO in the request regardless of the		An updated 6LN SHOULD use an EARO in the request regardless of the
	type of 6LR, legacy or updated, which implies that the "T" flag is		type of 6LR, RFC6775-only or updated, which implies that the "T" flag
	set.		is set.
	If an updated 6LN moves from an updated 6LR to a legacy 6LR, the		If an updated 6LN moves from an updated 6LR to a RFC6775-only 6LR,
	legacy 6LR will send a legacy DAR message, which can not be compared		the RFC6775-only 6LR will send a RFC6775-only DAR message, which can
	with an updated one for freshness.		not be compared with an updated one for freshness.
	Allowing legacy DAR messages to replace a state established by the		Allowing RFC6775-only DAR messages to replace a state established by
	updated protocol in the 6LBR would be an attack vector and that		the updated protocol in the 6LBR would be an attack vector and that
	cannot be the default behavior.		cannot be the default behavior.
	But if legacy and updated 6LRs coexist temporarily in a network, then		But if RFC6775-only and updated 6LRs coexist temporarily in a
	it makes sense for an administrator to install a policy that allows		network, then it makes sense for an administrator to install a policy
	so, and the capability to install such a policy should be		that allows so, and the capability to install such a policy should be
	configurable in a 6LBR though it is out of scope for this document.		configurable in a 6LBR though it is out of scope for this document.
	7.4. Legacy 6LoWPAN Border Router		7.4. RFC6775-only 6LoWPAN Border Router
	With this specification, the Duplicate Address messages are extended		With this specification, the Duplicate Address messages are extended
	to transport the EARO information. Similarly to the NS/NA exchange,		to transport the EARO information. Similarly to the NS/NA exchange,
	updated 6LBR devices always use the Extended Duplicate Address		updated 6LBR devices always use the Extended Duplicate Address
	messages and all the associated behavior so they can always be		messages and all the associated behavior so they can always be
	differentiated from legacy ones.		differentiated from RFC6775-only ones.
	Note that a legacy 6LBR will accept and process an EDAR message as if		Note that a RFC6775-only 6LBR will accept and process an EDAR message
	it was a legacy DAR, so legacy support of DAD is preserved.		as if it was a RFC6775-only DAR, so the support of DAD is preserved.
	8. Security Considerations		8. Security Considerations
	This specification extends [RFC6775], and the security section of		This specification extends [RFC6775], and the security section of
	that draft also applies to this as well. In particular, it is		that standard also applies to this as well. In particular, it is
	expected that the link layer is sufficiently protected to prevent a		expected that the link layer is sufficiently protected to prevent a
	rogue access, either by means of physical or IP security on the		rogue access, either by means of physical or IP security on the
	Backbone Link and link layer cryptography on the LLN.		Backbone Link and link layer cryptography on the LLN.
	Internet-Draft An Update to 6LoWPAN ND February
	This specification also expects that the LLN MAC provides secure		This specification also expects that the LLN MAC provides secure
	unicast to/from the Backbone Router and secure Broadcast from the		unicast to/from the Backbone Router and secure Broadcast from the
	Backbone Router in a way that prevents tampering with or replaying		Backbone Router in a way that prevents tampering with or replaying
	the RA messages.		the RA messages.
	This specification recommends using privacy techniques (see		This specification recommends using privacy techniques (see
	Section 9), and protection against address theft such as provided by		Section 9), and protection against address theft such as provided by
	"Address Protected Neighbor Discovery for Low-power and Lossy		"Address Protected Neighbor Discovery for Low-power and Lossy
	Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the		Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the
	Registered Address using a cryptographic RUID.		Registered Address using a cryptographic RUID.
	The registration mechanism may be used by a rogue node to attack the		The registration mechanism may be used by a rogue node to attack the
	6LR or the 6LBR with a Denial-of-Service attack against the registry.		6LR or the 6LBR with a Denial-of-Service attack against the registry.
	It may also happen that the registry of a 6LR or a 6LBR is saturated		It may also happen that the registry of a 6LR or a 6LBR is saturated
	and cannot take any more registration, which effectively denies the		and cannot take any more registration, which effectively denies the
	requesting a node the capability to use a new address. In order to		requesting node the capability to use a new address. In order to
	alleviate those concerns, Section 4.7 provides a number of		alleviate those concerns, Section 4.7 provides a number of
	recommendations that ensure that a stale registration is removed as		recommendations that ensure that a stale registration is removed as
	soon as possible from the 6LR and 6LBR. In particular, this		soon as possible from the 6LR and 6LBR. In particular, this
	specification recommends that:		specification recommends that:
	o A node that ceases to use an address SHOULD attempt to de-register		o A node that ceases to use an address SHOULD attempt to de-register
	that address from all the 6LRs to which it is registered. See		that address from all the 6LRs to which it is registered. See
	Section 4.2 for the mechanism to avoid replay attacks and avoiding		Section 4.2 for the mechanism to avoid replay attacks and avoiding
	the use of stale registration information.		the use of stale registration information.
	o The Registration lifetimes SHOULD be individually configurable for		o The Registration lifetimes SHOULD be individually configurable for
	each address or group of addresses. The nodes SHOULD be		each address or group of addresses. The nodes SHOULD be
	configured with a Registration Lifetime that reflects their		configured with a Registration Lifetime that reflects their
	expectation of how long they will use the address with the 6LR to		expectation of how long they will use the address with the 6LR to
	which it is registered. In particular, use cases that involve		which it is registered. In particular, use cases that involve
	mobility or rapid address changes SHOULD use lifetimes that are		mobility or rapid address changes SHOULD use lifetimes that are
	larger yet of a same order as the duration of the expectation of		larger yet of a same order as the duration of the expectation of
	presence.		presence.
	o The router (6LR or 6LBR) SHOULD be configurable so as to limit the		o The router (6LR or 6LBR) SHOULD be configurable so as to limit the
	number of addresses that can be registered by a single node, as		number of addresses that can be registered by a single node, as
	identified at least by MAC address and preferably by security		identified at least by MAC address and preferably by security
	credentials. When that maximum is reached, the router should use		credentials. When that maximum is reached, the router should use
	a Least-Recently-Used (LRU) algorithm to clean up the addresses,		a Least-Recently-Used (LRU) algorithm to clean up the addresses,
	keeping at least one Link-Local address. The router SHOULD		keeping at least one Link-Local address. The router SHOULD
	attempt to keep one or more stable addresses if stability can be		attempt to keep one or more stable addresses if stability can be
	determined, e.g. from the way the IID is formed or because they		determined, e.g. from the way the IID is formed or because they
	are used over a much longer time span than other (privacy,		are used over a much longer time span than other (privacy,
	shorter-lived) addresses. Address lifetimes SHOULD be		shorter-lived) addresses. Address lifetimes SHOULD be
	skipping to change at page 23, line 4 ¶		skipping to change at page 21, line 44 ¶
	number of addresses that can be registered by a single node, as		number of addresses that can be registered by a single node, as
	identified at least by MAC address and preferably by security		identified at least by MAC address and preferably by security
	credentials. When that maximum is reached, the router should use		credentials. When that maximum is reached, the router should use
	a Least-Recently-Used (LRU) algorithm to clean up the addresses,		a Least-Recently-Used (LRU) algorithm to clean up the addresses,
	keeping at least one Link-Local address. The router SHOULD		keeping at least one Link-Local address. The router SHOULD
	attempt to keep one or more stable addresses if stability can be		attempt to keep one or more stable addresses if stability can be
	determined, e.g. from the way the IID is formed or because they		determined, e.g. from the way the IID is formed or because they
	are used over a much longer time span than other (privacy,		are used over a much longer time span than other (privacy,
	shorter-lived) addresses. Address lifetimes SHOULD be		shorter-lived) addresses. Address lifetimes SHOULD be
	individually configurable.		individually configurable.
	Internet-Draft An Update to 6LoWPAN ND February
	o In order to avoid denial of registration for the lack of		o In order to avoid denial of registration for the lack of
	resources, administrators should take great care to deploy		resources, administrators should take great care to deploy
	adequate numbers of 6LRs to cover the needs of the nodes in their		adequate numbers of 6LRs to cover the needs of the nodes in their
	range, so as to avoid a situation of starving nodes. It is		range, so as to avoid a situation of starving nodes. It is
	expected that the 6LBR that serves a LLN is a more capable node		expected that the 6LBR that serves a LLN is a more capable node
	then the average 6LR, but in a network condition where it may		then the average 6LR, but in a network condition where it may
	become saturated, a particular deployment should distribute the		become saturated, a particular deployment should distribute the
	6LBR functionality, for instance by leveraging a high speed		6LBR functionality, for instance by leveraging a high speed
	Backbone and Backbone Routers to aggregate multiple LLNs into a		Backbone Link and Backbone Routers to aggregate multiple LLNs into
	larger subnet.		a larger subnet.
	The LLN nodes depend on the 6LBR and the 6BBR for their operation. A		The LLN nodes depend on the 6LBR and the 6BBR for their operation. A
	trust model must be put in place to ensure that the right devices are		trust model must be put in place to ensure that the right devices are
	acting in these roles, so as to avoid threats such as black-holing,		acting in these roles, so as to avoid threats such as black-holing,
	or bombing attack whereby an impersonated 6LBR would destroy state in		or bombing attack whereby an impersonated 6LBR would destroy state in
	the network by using the "Removed" Status code. This trust model		the network by using the "Removed" Status code. This trust model
	could be at a minimum based on a Layer-2 access control, or could		could be at a minimum based on a Layer-2 access control, or could
	provide role validation as well (see Req5.1 in Appendix B.5).		provide role validation as well (see Req5.1 in Appendix B.5).
	9. Privacy Considerations		9. Privacy Considerations
	As indicated in section Section 2, this protocol does not aim at		As indicated in Section 3, this protocol does not aim at limiting the
	limiting the number of IPv6 addresses that a device can form. A host		number of IPv6 addresses that a device can form. A host should be
	should be able to form and register any address that is topologically		able to form and register any address that is topologically correct
	correct in the subnet(s) advertised by the 6LR/6LBR.		in the subnet(s) advertised by the 6LR/6LBR.
	This specification does not mandate any particular way for forming		This specification does not mandate any particular way for forming
	IPv6 addresses, but it discourages using EUI-64 for forming the		IPv6 addresses, but it discourages using EUI-64 for forming the
	Interface ID in the Link-Local address because this method prevents		Interface ID in the Link-Local address because this method prevents
	the usage of "SEcure Neighbor Discovery (SEND)" [RFC3971] and		the usage of "SEcure Neighbor Discovery (SEND)" [RFC3971] and
	"Cryptographically Generated Addresses (CGA)" [RFC3972], and that of		"Cryptographically Generated Addresses (CGA)" [RFC3972], and that of
	address privacy techniques.		address privacy techniques.
	"Privacy Considerations for IPv6 Adaptation-Layer Mechanisms"		"Privacy Considerations for IPv6 Adaptation-Layer Mechanisms"
	[RFC8065] explains why privacy is important and how to form privacy-		[RFC8065] explains why privacy is important and how to form privacy-
	skipping to change at page 24, line 4 ¶		skipping to change at page 22, line 43 ¶
	The IPv6 address of the 6LN in the IPv6 header can be compressed		The IPv6 address of the 6LN in the IPv6 header can be compressed
	statelessly when the Interface Identifier in the IPv6 address can be		statelessly when the Interface Identifier in the IPv6 address can be
	derived from the Lower Layer address. When it is not critical to		derived from the Lower Layer address. When it is not critical to
	benefit from that compression, e.g. the address can be compressed		benefit from that compression, e.g. the address can be compressed
	statefully, or it is rarely used and/or it is used only over one hop,		statefully, or it is rarely used and/or it is used only over one hop,
	then privacy concerns should be considered. In particular, new		then privacy concerns should be considered. In particular, new
	implementations should follow the IETF "Recommendation on Stable IPv6		implementations should follow the IETF "Recommendation on Stable IPv6
	Interface Identifiers" [RFC8064] This RFC recommends the use of "A		Interface Identifiers" [RFC8064] This RFC recommends the use of "A
	Method for Generating Semantically Opaque Interface Identifiers with		Method for Generating Semantically Opaque Interface Identifiers with
	Internet-Draft An Update to 6LoWPAN ND February
	IPv6 Stateless Address Autoconfiguration (SLAAC)" [RFC7217] for		IPv6 Stateless Address Autoconfiguration (SLAAC)" [RFC7217] for
	generating Interface Identifiers to be used in SLAAC.		generating Interface Identifiers to be used in SLAAC.
	10. IANA Considerations		10. IANA Considerations
	Note to RFC Editor: please replace "This RFC" throughout this		Note to RFC Editor: please replace "This RFC" throughout this
	document by the RFC number for this specification once it is		document by the RFC number for this specification once it is
	attributed.		attributed.
	IANA is requested to make a number of changes under the "Internet		IANA is requested to make a number of changes under the "Internet
	skipping to change at page 25, line 5 ¶		skipping to change at page 23, line 38 ¶
	Table 2: new ARO Flags		Table 2: new ARO Flags
	10.2. ICMP Codes		10.2. ICMP Codes
	IANA is requested to create a new entry in the ICMPv6 "Code" Fields		IANA is requested to create a new entry in the ICMPv6 "Code" Fields
	subregistry of the Internet Control Message Protocol version 6		subregistry of the Internet Control Message Protocol version 6
	(ICMPv6) Parameters for the ICMP codes related to the ICMP type 157		(ICMPv6) Parameters for the ICMP codes related to the ICMP type 157
	and 158 Duplicate Address Request (shown in Table 3) and Confirmation		and 158 Duplicate Address Request (shown in Table 3) and Confirmation
	(shown in Table 4), respectively, as follows:		(shown in Table 4), respectively, as follows:
	Internet-Draft An Update to 6LoWPAN ND February
	New entries for ICMP types 157 DAR message		New entries for ICMP types 157 DAR message
	+-------+----------------------+------------+		+-------+----------------------+------------+
	| Code | Name | Reference |		| Code | Name | Reference |
	+-------+----------------------+------------+		+-------+----------------------+------------+
	| 0 | Original DAR message | RFC 6775 |		| 0 | Original DAR message | RFC 6775 |
	| | | |		| | | |
	| 1 | Extended DAR message | This RFC |		| 1 | Extended DAR message | This RFC |
	+-------+----------------------+------------+		+-------+----------------------+------------+
	skipping to change at page 26, line 5 ¶		skipping to change at page 24, line 22 ¶
	| 1 | Extended DAC message | This RFC |		| 1 | Extended DAC message | This RFC |
	+-------+----------------------+------------+		+-------+----------------------+------------+
	Table 4: new ICMPv6 Code Fields		Table 4: new ICMPv6 Code Fields
	10.3. New ARO Status values		10.3. New ARO Status values
	IANA is requested to make additions to the Address Registration		IANA is requested to make additions to the Address Registration
	Option Status Values Registry as follows:		Option Status Values Registry as follows:
	Internet-Draft An Update to 6LoWPAN ND February
	Address Registration Option Status Values Registry		Address Registration Option Status Values Registry
	+-------------+-----------------------------------------+-----------+		+-------------+-----------------------------------------+-----------+
	| ARO Status | Description | Document |		| ARO Status | Description | Document |
	+-------------+-----------------------------------------+-----------+		+-------------+-----------------------------------------+-----------+
	| 3 | Moved | This RFC |		| 3 | Moved | This RFC |
	| | | |		| | | |
	| 4 | Removed | This RFC |		| 4 | Removed | This RFC |
	| | | |		| | | |
	| 5 | Validation Requested | This RFC |		| 5 | Validation Requested | This RFC |
	skipping to change at page 27, line 5 ¶		skipping to change at page 25, line 22 ¶
	| | | |		| | | |
	| 12 | 6LBR capable (B bit) | This RFC |		| 12 | 6LBR capable (B bit) | This RFC |
	| | | |		| | | |
	| 13 | 6BBR capable (P bit) | This RFC |		| 13 | 6BBR capable (P bit) | This RFC |
	| | | |		| | | |
	| 14 | EARO support (E bit) | This RFC |		| 14 | EARO support (E bit) | This RFC |
	+-----------------+----------------------+-----------+		+-----------------+----------------------+-----------+
	Table 6: New 6LoWPAN capability Bits		Table 6: New 6LoWPAN capability Bits
	Internet-Draft An Update to 6LoWPAN ND February
	11. Acknowledgments		11. Acknowledgments
	Kudos to Eric Levy-Abegnoli who designed the First Hop Security		Kudos to Eric Levy-Abegnoli who designed the First Hop Security
	infrastructure upon which the first backbone router was implemented.		infrastructure upon which the first backbone router was implemented.
	Many thanks to Sedat Gormus, Rahul Jadhav and Lorenzo Colitti for		Many thanks to Sedat Gormus, Rahul Jadhav, Tim Chown, Juergen
	their various contributions and reviews. Also many thanks to Thomas		Schoenwaelder, Chris Lonvick and Lorenzo Colitti for their various
	Watteyne for his early implementation of a 6LN that was instrumental		contributions and reviews. Also many thanks to Thomas Watteyne for
	to the early tests of the 6LR, 6LBR and Backbone Router.		his early implementation of a 6LN that was instrumental to the early
			tests of the 6LR, 6LBR and Backbone Router.
	12. References		12. References
	12.1. Normative References		12.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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 28, line 5 ¶		skipping to change at page 26, line 26 ¶
	Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,		Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
	DOI 10.17487/RFC6282, September 2011,		DOI 10.17487/RFC6282, September 2011,
	<https://www.rfc-editor.org/info/rfc6282>.		<https://www.rfc-editor.org/info/rfc6282>.
	[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.		[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
	Bormann, "Neighbor Discovery Optimization for IPv6 over		Bormann, "Neighbor Discovery Optimization for IPv6 over
	Low-Power Wireless Personal Area Networks (6LoWPANs)",		Low-Power Wireless Personal Area Networks (6LoWPANs)",
	RFC 6775, DOI 10.17487/RFC6775, November 2012,		RFC 6775, DOI 10.17487/RFC6775, November 2012,
	<https://www.rfc-editor.org/info/rfc6775>.		<https://www.rfc-editor.org/info/rfc6775>.
	Internet-Draft An Update to 6LoWPAN ND February
	[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for		[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
	IPv6 over Low-Power Wireless Personal Area Networks		IPv6 over Low-Power Wireless Personal Area Networks
	(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November		(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
	2014, <https://www.rfc-editor.org/info/rfc7400>.		2014, <https://www.rfc-editor.org/info/rfc7400>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	skipping to change at page 29, line 5 ¶		skipping to change at page 27, line 31 ¶
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode		Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
	in progress), November 2017.		in progress), November 2017.
	[I-D.ietf-ipv6-multilink-subnets]		[I-D.ietf-ipv6-multilink-subnets]
	Thaler, D. and C. Huitema, "Multi-link Subnet Support in		Thaler, D. and C. Huitema, "Multi-link Subnet Support in
	IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in		IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
	progress), July 2002.		progress), July 2002.
	Internet-Draft An Update to 6LoWPAN ND February
	[I-D.ietf-mboned-ieee802-mcast-problems]		[I-D.ietf-mboned-ieee802-mcast-problems]
	Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.		Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
	Zuniga, "Multicast Considerations over IEEE 802 Wireless		Zuniga, "Multicast Considerations over IEEE 802 Wireless
	Media", draft-ietf-mboned-ieee802-mcast-problems-01 (work		Media", draft-ietf-mboned-ieee802-mcast-problems-01 (work
	in progress), February 2018.		in progress), February 2018.
	[I-D.perkins-intarea-multicast-ieee802]		[I-D.perkins-intarea-multicast-ieee802]
	Perkins, C., Stanley, D., Kumari, W., and J. Zuniga,		Perkins, C., Stanley, D., Kumari, W., and J. Zuniga,
	"Multicast Considerations over IEEE 802 Wireless Media",		"Multicast Considerations over IEEE 802 Wireless Media",
	draft-perkins-intarea-multicast-ieee802-03 (work in		draft-perkins-intarea-multicast-ieee802-03 (work in
	skipping to change at page 29, line 30 ¶		skipping to change at page 28, line 5 ¶
	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", draft-popa-6lo-6loplc-ipv6-over-		Networks", draft-popa-6lo-6loplc-ipv6-over-
	ieee19012-networks-00 (work in progress), March 2014.		ieee19012-networks-00 (work in progress), March 2014.
	[I-D.struik-lwip-curve-representations]		[I-D.struik-lwip-curve-representations]
	Struik, R., "Alternative Elliptic Curve Representations",		Struik, R., "Alternative Elliptic Curve Representations",
	draft-struik-lwip-curve-representations-00 (work in		draft-struik-lwip-curve-representations-00 (work in
	progress), October 2017.		progress), October 2017.
			[RFC1558] Howes, T., "A String Representation of LDAP Search
			Filters", RFC 1558, DOI 10.17487/RFC1558, December 1993,
			<https://www.rfc-editor.org/info/rfc1558>.
	[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,		[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
	DOI 10.17487/RFC1982, August 1996,		DOI 10.17487/RFC1982, August 1996,
	<https://www.rfc-editor.org/info/rfc1982>.		<https://www.rfc-editor.org/info/rfc1982>.
	[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with		[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
	CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September		CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
	2003, <https://www.rfc-editor.org/info/rfc3610>.		2003, <https://www.rfc-editor.org/info/rfc3610>.
	[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener		[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
	Discovery Version 2 (MLDv2) for IPv6", RFC 3810,		Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
	skipping to change at page 30, line 5 ¶		skipping to change at page 28, line 35 ¶
	<https://www.rfc-editor.org/info/rfc3971>.		<https://www.rfc-editor.org/info/rfc3971>.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",		[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, DOI 10.17487/RFC3972, March 2005,		RFC 3972, DOI 10.17487/RFC3972, March 2005,
	<https://www.rfc-editor.org/info/rfc3972>.		<https://www.rfc-editor.org/info/rfc3972>.
	[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)		[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
	for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,		for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
	<https://www.rfc-editor.org/info/rfc4429>.		<https://www.rfc-editor.org/info/rfc4429>.
	Internet-Draft An Update to 6LoWPAN ND February
	[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",		Overview, Assumptions, Problem Statement, and Goals",
	RFC 4919, DOI 10.17487/RFC4919, August 2007,		RFC 4919, DOI 10.17487/RFC4919, August 2007,
	<https://www.rfc-editor.org/info/rfc4919>.		<https://www.rfc-editor.org/info/rfc4919>.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy		[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	Extensions for Stateless Address Autoconfiguration in		Extensions for Stateless Address Autoconfiguration in
	IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,		IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
	<https://www.rfc-editor.org/info/rfc4941>.		<https://www.rfc-editor.org/info/rfc4941>.
	skipping to change at page 31, line 5 ¶		skipping to change at page 29, line 36 ¶
	[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets		[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
	over ITU-T G.9959 Networks", RFC 7428,		over ITU-T G.9959 Networks", RFC 7428,
	DOI 10.17487/RFC7428, February 2015,		DOI 10.17487/RFC7428, February 2015,
	<https://www.rfc-editor.org/info/rfc7428>.		<https://www.rfc-editor.org/info/rfc7428>.
	[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,		[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
	Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low		Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
	Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,		Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
	<https://www.rfc-editor.org/info/rfc7668>.		<https://www.rfc-editor.org/info/rfc7668>.
	Internet-Draft An Update to 6LoWPAN ND February
	[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,		[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
	"Host Address Availability Recommendations", BCP 204,		"Host Address Availability Recommendations", BCP 204,
	RFC 7934, DOI 10.17487/RFC7934, July 2016,		RFC 7934, DOI 10.17487/RFC7934, July 2016,
	<https://www.rfc-editor.org/info/rfc7934>.		<https://www.rfc-editor.org/info/rfc7934>.
	[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,		[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
	"Recommendation on Stable IPv6 Interface Identifiers",		"Recommendation on Stable IPv6 Interface Identifiers",
	RFC 8064, DOI 10.17487/RFC8064, February 2017,		RFC 8064, DOI 10.17487/RFC8064, February 2017,
	<https://www.rfc-editor.org/info/rfc8064>.		<https://www.rfc-editor.org/info/rfc8064>.
	skipping to change at page 32, line 5 ¶		skipping to change at page 30, line 36 ¶
	IEEE Standard 802.15.4, DOI 10.1109/IEEE		IEEE Standard 802.15.4, DOI 10.1109/IEEE
	P802.15.4-REVd/D01, June 2017,		P802.15.4-REVd/D01, June 2017,
	<http://ieeexplore.ieee.org/document/7460875/>.		<http://ieeexplore.ieee.org/document/7460875/>.
	[Perlman83]		[Perlman83]
	Perlman, R., "Fault-Tolerant Broadcast of Routing		Perlman, R., "Fault-Tolerant Broadcast of Routing
	Information", North-Holland Computer Networks 7: 395-405,		Information", North-Holland Computer Networks 7: 395-405,
	1983, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/		1983, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/
	readings/p83.pdf>.		readings/p83.pdf>.
	Internet-Draft An Update to 6LoWPAN ND February
	Appendix A. Applicability and Requirements Served		Appendix A. Applicability and Requirements Served
	This specification extends 6LoWPAN ND to provide a sequence number to		This specification extends 6LoWPAN ND to provide a sequence number to
	the registration and serves the requirements expressed Appendix B.1		the registration and serves the requirements expressed Appendix B.1
	by enabling the mobility of devices from one LLN to the next based on		by enabling the mobility of devices from one LLN to the next based on
	the complementary work in the "IPv6 Backbone Router"		the complementary work in the "IPv6 Backbone Router"
	[I-D.ietf-6lo-backbone-router] specification.		[I-D.ietf-6lo-backbone-router] specification.
	In the context of the the TimeSlotted Channel Hopping (TSCH) mode of		In the context of the the TimeSlotted Channel Hopping (TSCH) mode of
	IEEE Std. 802.15.4 [IEEEstd802154], the "6TiSCH architecture"		IEEE Std. 802.15.4 [IEEEstd802154], the "6TiSCH architecture"
	skipping to change at page 32, line 32 ¶		skipping to change at page 31, line 12 ¶
	implement the 6TiSCH architecture and serves the requirements listed		implement the 6TiSCH architecture and serves the requirements listed
	in Appendix B.2.		in Appendix B.2.
	The term LLN is used loosely in this specification to cover multiple		The term LLN is used loosely in this specification to cover multiple
	types of WLANs and WPANs, including Low-Power Wi-Fi, BLUETOOTH(R) Low		types of WLANs and WPANs, including Low-Power Wi-Fi, BLUETOOTH(R) Low
	Energy, IEEE Std.802.11AH and IEEE Std.802.15.4 wireless meshes, so		Energy, IEEE Std.802.11AH and IEEE Std.802.15.4 wireless meshes, so
	as to address the requirements discussed in Appendix B.3.		as to address the requirements discussed in Appendix B.3.
	This specification can be used by any wireless node to associate at		This specification can be used by any wireless node to associate at
	Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing		Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing
	services including proxy-ND operations over the Backbone, effectively		services including proxy-ND operations over a Backbone Link,
	providing a solution to the requirements expressed in Appendix B.4.		effectively providing a solution to the requirements expressed in
			Appendix B.4.
	This specification is extended by "Address Protected Neighbor		This specification is extended by "Address Protected Neighbor
	Discovery for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd] to		Discovery for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd] to
	providing a solution to some of the security-related requirements		providing a solution to some of the security-related requirements
	expressed in Appendix B.5.		expressed in Appendix B.5.
	"Efficiency aware IPv6 Neighbor Discovery Optimizations"		"Efficiency aware IPv6 Neighbor Discovery Optimizations"
	[I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND		[I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND
	[RFC6775] can be extended to other types of links beyond IEEE Std.		[RFC6775] can be extended to other types of links beyond IEEE Std.
	802.15.4 for which it was defined. The registration technique is		802.15.4 for which it was defined. The registration technique is
	skipping to change at page 33, line 5 ¶		skipping to change at page 31, line 36 ¶
	packets is not sufficiently efficient in terms of delivery ratio or		packets is not sufficiently efficient in terms of delivery ratio or
	energy consumption in the end devices, in particular to enable		energy consumption in the end devices, in particular to enable
	energy-constrained sleeping nodes. The value of such extension is		energy-constrained sleeping nodes. The value of such extension is
	especially apparent in the case of mobile wireless nodes, to reduce		especially apparent in the case of mobile wireless nodes, to reduce
	the multicast operations that are related to IPv6 ND ([RFC4861],		the multicast operations that are related to IPv6 ND ([RFC4861],
	[RFC4862]) and affect the operation of the wireless medium		[RFC4862]) and affect the operation of the wireless medium
	[I-D.ietf-mboned-ieee802-mcast-problems]		[I-D.ietf-mboned-ieee802-mcast-problems]
	[I-D.perkins-intarea-multicast-ieee802]. This serves the scalability		[I-D.perkins-intarea-multicast-ieee802]. This serves the scalability
	requirements listed in Appendix B.6.		requirements listed in Appendix B.6.
	Internet-Draft An Update to 6LoWPAN ND February		Finally Appendix B.8 provides a matching of requirements with the
	Finally Appendix B.7 provides a matching of requirements with the
	specifications that serves them.		specifications that serves them.
	Appendix B. Requirements		Appendix B. Requirements
	This section lists requirements that were discussed at 6lo for an		This section lists requirements that were discussed at 6lo for an
	update to 6LoWPAN ND. This specification meets most of them, but		update to 6LoWPAN ND. This specification meets most of them, but
	those listed in Appendix B.5 which are deferred to a different		those listed in Appendix B.5 which are deferred to a different
	specification such as [I-D.ietf-6lo-ap-nd], and those related to		specification such as [I-D.ietf-6lo-ap-nd], and those related to
	multicast.		multicast.
	skipping to change at page 34, line 4 ¶		skipping to change at page 32, line 34 ¶
	that was defined at the IETF for this particular purpose. Other		that was defined at the IETF for this particular purpose. Other
	routing protocols than RPL are also considered by Standard Defining		routing protocols than RPL are also considered by Standard Defining
	Organizations (SDO) on the basis of the expected network		Organizations (SDO) on the basis of the expected network
	characteristics. It is required that a 6LoWPAN Node attached via ND		characteristics. It is required that a 6LoWPAN Node attached via ND
	to a 6LR would need to participate in the selected routing protocol		to a 6LR would need to participate in the selected routing protocol
	to obtain reachability via the 6LR.		to obtain reachability via the 6LR.
	Next to the 6LBR unicast address registered by ND, other addresses		Next to the 6LBR unicast address registered by ND, other addresses
	including multicast addresses are needed as well. For example a		including multicast addresses are needed as well. For example a
	routing protocol often uses a multicast address to register changes		routing protocol often uses a multicast address to register changes
	Internet-Draft An Update to 6LoWPAN ND February
	to established paths. ND needs to register such a multicast address		to established paths. ND needs to register such a multicast address
	to enable routing concurrently with discovery.		to enable routing concurrently with discovery.
	Multicast is needed for groups. Groups may be formed by device type		Multicast is needed for groups. Groups may be formed by device type
	(e.g. routers, street lamps), location (Geography, RPL sub-tree), or		(e.g. routers, street lamps), location (Geography, RPL sub-tree), or
	both.		both.
	The Bit Index Explicit Replication (BIER) Architecture [RFC8279]		The Bit Index Explicit Replication (BIER) Architecture [RFC8279]
	proposes an optimized technique to enable multicast in a LLN with a		proposes an optimized technique to enable multicast in a LLN with a
	very limited requirement for routing state in the nodes.		very limited requirement for routing state in the nodes.
	skipping to change at page 35, line 4 ¶		skipping to change at page 33, line 35 ¶
	Communication [I-D.ietf-6lo-nfc], IEEE Std. 802.11ah		Communication [I-D.ietf-6lo-nfc], IEEE Std. 802.11ah
	[I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 Narrowband		[I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 Narrowband
	Powerline Communication Networks		Powerline Communication Networks
	[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R)		[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R)
	Low Energy [RFC7668].		Low Energy [RFC7668].
	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 than IEEE Std.802.15.4, matching at least the LLN		to more LLN links than IEEE Std.802.15.4, matching at least the LLN
	Internet-Draft An Update to 6LoWPAN ND February
	links for which an "IPv6 over foo" specification exists, as well as		links for which an "IPv6 over foo" specification exists, as well as
	Low-Power Wi-Fi.		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 SHOULD be unique at least within the LLN connected		Local Address that SHOULD be unique at least within the LLN connected
	to a 6LBR discovered by ND in each node within the LLN.		to a 6LBR discovered by ND in each node within the LLN.
	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		Req3.4: The Neighbour Discovery should specify the formation of a
	site-local address that follows the security recommendations from		site-local address that follows the security recommendations from
	[RFC7217].		[RFC7217].
	B.4. Requirements Related to Proxy Operations		B.4. Requirements Related to Proxy Operations
	Duty-cycled 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 IPv6 ND on a Backbone and may need a proxy.		from a node that uses IPv6 ND on a Backbone Link and may need a
	Additionally, the duty-cycled device may need to rely on the 6LBR to		proxy. Additionally, the duty-cycled device may need to rely on the
	perform registration to the 6BBR.		6LBR to perform registration to the 6BBR.
	The ND registration method SHOULD defend the addresses of duty-cycled		The ND registration method SHOULD defend the addresses of duty-cycled
	devices that are sleeping most of the time and not capable to defend		devices that are sleeping most of the time and not capable to defend
	their own Addresses.		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.
	skipping to change at page 36, line 5 ¶		skipping to change at page 34, line 37 ¶
	durations, in the order of multiple days to a month.		durations, in the order of multiple days to a month.
	B.5. Requirements Related to Security		B.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 for the 6LBR to protect that ownership even		energy-efficient means for the 6LBR to protect that ownership even
	when the node that registered the address is sleeping.		when the node that registered the address is sleeping.
	Internet-Draft An Update to 6LoWPAN ND February
	In particular, the 6LR and the 6LBR then should be able to verify		In particular, the 6LR and the 6LBR then should be able to verify
	whether a subsequent registration for a given address comes from the		whether a subsequent registration for a given address comes from the
	original node.		original node.
	In a LLN it makes sense to base security on layer-2 security. During		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		bootstrap of the LLN, nodes join the network after authorization by a
	Joining Assistant (JA) or a Commissioning Tool (CT). After joining		Joining Assistant (JA) or a Commissioning Tool (CT). After joining
	nodes communicate with each other via secured links. The keys for		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		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		part of the LLN or be outside the LLN. In both cases it is needed
	skipping to change at page 37, line 5 ¶		skipping to change at page 35, line 37 ¶
	present on the device for upper layer security such as TLS.		present on the device for upper layer security 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.
	Req5.8: Routing of packets should continue when links pass from the		Req5.8: Routing of packets should continue when links pass from the
	unsecured to the secured state.		unsecured to the secured state.
	Internet-Draft An Update to 6LoWPAN ND February
	Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for		Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for
	the 6LR and the 6LBR to validate whether a new registration for a		the 6LR and the 6LBR to validate whether a new registration for a
	given address corresponds to the same 6LoWPAN Node that registered it		given address corresponds to the same 6LoWPAN Node that registered it
	initially, and, if not, determine the rightful owner, and deny or		initially, and, if not, determine the rightful owner, and deny or
	clean-up the registration that is duplicate.		clean-up the registration that is duplicate.
	B.6. Requirements Related to Scalability		B.6. 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
	skipping to change at page 37, line 29 ¶		skipping to change at page 36, line 11 ¶
	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:
	Req6.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.
	Req6.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.
	B.7. Matching Requirements with Specifications		B.7. Requirements Related to Operations and Management
			Section 3.8 of "Architectural Principles of the Internet" [RFC1558]
			recommends to : "avoid options and parameters whenever possible. Any
			options and parameters should be configured or negotiated dynamically
			rather than manually". This is especially true in LLNs where the
			number of devices may be large and manual configuration is
			infeasible. Capabilities for a dynamic configuration of LLN devices
			can also be constrained by the network and power limitation.
			A Network Administrator should be able to validate that the network
			is operating within capacity, and that in particular a 6LBR does not
			get overloaded with an excessive amount of registration, so he can
			take actions such as adding a Backbone Link with additional 6LBRs and
			6BBRs to his network.
			Related requirements are:
			Req7.1: A management model SHOULD be provided providing access to the
			6LBR and its capacity. It is recommended that the 6LBR be reachable
			over a non-LLN link.
			Req7.2: A management model SHOULD be provided providing access to the
			6LR and its capacity to host additional NCE. This management model
			SHOULD avoid polling individual 6LRs n a way that could disrupt the
			operation of the LLN.
			Req7.3: information on successful and failed registration SHOULD be
			provided, including information such as the RUID of the 6LN, the
			Registered Address, the Address of the 6LR and the duration of the
			registration flow.
			Req7.4: In case of a failed registration, information on the failure
			including the identification of the node that rejected the
			registration and the status in the EARO SHOULD be provided
			B.8. Matching Requirements with Specifications
	I-drafts/RFCs addressing requirements		I-drafts/RFCs addressing requirements
	+-------------+-----------------------------------------+		+-------------+-----------------------------------------+
	| Requirement | Document |		| Requirement | Document |
	+-------------+-----------------------------------------+		+-------------+-----------------------------------------+
	| Req1.1 | [I-D.ietf-6lo-backbone-router] |		| Req1.1 | [I-D.ietf-6lo-backbone-router] |
	| | |		| | |
	| Req1.2 | [RFC6775] |		| Req1.2 | [RFC6775] |
	| | |		| | |
	skipping to change at page 38, line 4 ¶		skipping to change at page 37, line 24 ¶
	| | |		| | |
	| Req2.2 | This RFC |		| Req2.2 | This RFC |
	| | |		| | |
	| Req2.3 | |		| Req2.3 | |
	| | |		| | |
	| Req3.1 | Technology Dependant |		| Req3.1 | Technology Dependant |
	| | |		| | |
	| Req3.2 | Technology Dependant |		| Req3.2 | Technology Dependant |
	| | |		| | |
	| Req3.3 | Technology Dependant |		| Req3.3 | Technology Dependant |
	Internet-Draft An Update to 6LoWPAN ND February
	| | |		| | |
	| Req3.4 | Technology Dependant |		| Req3.4 | Technology Dependant |
	| | |		| | |
	| Req4.1 | This RFC |		| Req4.1 | This RFC |
	| | |		| | |
	| Req4.2 | This RFC |		| Req4.2 | This RFC |
	| | |		| | |
	| Req4.3 | [RFC6775] |		| Req4.3 | [RFC6775] |
	| | |		| | |
	| Req5.1 | |		| Req5.1 | |
	skipping to change at page 38, line 37 ¶		skipping to change at page 38, line 6 ¶
	| | |		| | |
	| Req5.7 | [I-D.ietf-6lo-ap-nd] |		| Req5.7 | [I-D.ietf-6lo-ap-nd] |
	| | |		| | |
	| Req5.8 | |		| Req5.8 | |
	| | |		| | |
	| Req5.9 | [I-D.ietf-6lo-ap-nd] |		| Req5.9 | [I-D.ietf-6lo-ap-nd] |
	| | |		| | |
	| Req6.1 | This RFC |		| Req6.1 | This RFC |
	| | |		| | |
	| Req6.2 | This RFC |		| Req6.2 | This RFC |
			| | |
			| Req7.1 | |
			| | |
			| Req7.2 | |
			| | |
			| Req7.3 | |
			| | |
			| Req7.4 | |
	+-------------+-----------------------------------------+		+-------------+-----------------------------------------+
	Table 7: Addressing requirements		Table 7: Work Addressing requirements
	Appendix C. Subset of a 6LoWPAN Glossary		Appendix C. Subset of a 6LoWPAN Glossary
	This document often uses the followng acronyms:		This document often uses the followng acronyms:
	6BBR: 6LoWPAN Backbone Router (proxy for the registration)		6BBR: 6LoWPAN Backbone Router (proxy for the registration)
	6LBR: 6LoWPAN Border Router (authoritative on DAD)		6LBR: 6LoWPAN Border Router (authoritative on DAD)
	6LN: 6LoWPAN Node		6LN: 6LoWPAN Node
	6LR: 6LoWPAN Router (relay to the registration process)		6LR: 6LoWPAN Router (relay to the registration process)
	6CIO: Capability Indication Option		6CIO: Capability Indication Option
	Internet-Draft An Update to 6LoWPAN ND February
	(E)ARO: (Extended) Address Registration Option		(E)ARO: (Extended) Address Registration Option
	DAD: Duplicate Address Detection		DAD: Duplicate Address Detection
	LLN: Low Power Lossy Network (a typical IoT network)		LLN: Low Power Lossy Network (a typical IoT network)
	NCE: Neighbor Cache Entry		NCE: Neighbor Cache Entry
			RUID: Registration Unique ID
	TSCH: TimeSlotted Channel Hopping		TSCH: TimeSlotted Channel Hopping
	TID: Transaction ID (a sequence counter in the EARO)		TID: Transaction ID (a sequence counter in the EARO)
	Authors' Addresses		Authors' Addresses
	Pascal Thubert (editor)		Pascal Thubert (editor)
	Cisco Systems, Inc		Cisco Systems, Inc
	Building D (Regus) 45 Allee des Ormes		Building D (Regus) 45 Allee des Ormes
	Mougins - Sophia Antipolis		Mougins - Sophia Antipolis
	France		France
End of changes. 120 change blocks.
	316 lines changed or deleted		235 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/