< draft-thubert-6lo-rfc6775-update-reqs-03.txt		draft-thubert-6lo-rfc6775-update-reqs-04.txt >
	6Lo P. Thubert, Ed.		6Lo P. Thubert, Ed.
	Internet-Draft cisco		Internet-Draft cisco
	Intended status: Standards Track August 20, 2014		Intended status: Standards Track August 22, 2014
	Expires: February 19, 2015		Expires: February 21, 2015
	Requirements for an update to 6LoWPAN ND		Requirements for an update to 6LoWPAN ND
	draft-thubert-6lo-rfc6775-update-reqs-03		draft-thubert-6lo-rfc6775-update-reqs-04
	Abstract		Abstract
	Work presented at the ROLL, 6lo, 6TiSCH and 6MAN Working Groups		Work presented at the ROLL, 6lo, 6TiSCH and 6MAN Working Groups
	suggest that enhancements to the 6LoWPAN ND mechanism are now needed.		suggest that enhancements to the 6LoWPAN ND mechanism are now needed.
	This document elaborates on those requirements and suggests		This document elaborates on those requirements and suggests
	approaches to serve them.		approaches to serve them.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 19, 2015.		This Internet-Draft will expire on February 21, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (http://trustee.ietf.org/		Provisions Relating to IETF Documents (http://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 11 ¶		skipping to change at page 2, line 11 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. RPL Leaf Support in 6LoWPAN ND . . . . . . . . . . . . . . 5		3.1. RPL Leaf Support in 6LoWPAN ND . . . . . . . . . . . . . . 5
	3.2. registration Failures Due to Movement . . . . . . . . . . 6		3.2. registration Failures Due to Movement . . . . . . . . . . 6
	3.3. Proxy registration . . . . . . . . . . . . . . . . . . . . 6		3.3. Proxy registration . . . . . . . . . . . . . . . . . . . . 6
	3.4. Target Registration . . . . . . . . . . . . . . . . . . . 6		3.4. Target Registration . . . . . . . . . . . . . . . . . . . 6
	3.5. RPL root vs. 6LBR . . . . . . . . . . . . . . . . . . . . 7		3.5. RPL root vs. 6LBR . . . . . . . . . . . . . . . . . . . . 7
	3.6. Securing the Registration . . . . . . . . . . . . . . . . 7		3.6. Securing the Registration . . . . . . . . . . . . . . . . 7
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Requirements Related to Mobility . . . . . . . . . . . . . 8		4.1. Requirements Related to Mobility . . . . . . . . . . . . . 8
	4.2. Requirements Related to Routing Protocols . . . . . . . . 8		4.2. Requirements Related to Routing Protocols . . . . . . . . 9
	4.3. Requirements Related to the Variety of Low-Power Link types 9		4.3. Requirements Related to the Variety of Low-Power Link types 9
	4.4. Requirements Related to Proxy Operations . . . . . . . . . 10		4.4. Requirements Related to Proxy Operations . . . . . . . . . 10
	4.5. Requirements Related to Security . . . . . . . . . . . . . 10		4.5. Requirements Related to Security . . . . . . . . . . . . . 10
	4.6. Requirements Related to Low-Power devices . . . . . . . . 10		4.6. Requirements Related to Low-Power devices . . . . . . . . 11
	5. Suggested Changes to Protocol Elements . . . . . . . . . . . . 10		5. Suggested Changes to Protocol Elements . . . . . . . . . . . . 11
	5.1. ND Neighbor Solicitation (NS) . . . . . . . . . . . . . . 10		5.1. ND Neighbor Solicitation (NS) . . . . . . . . . . . . . . 11
	5.2. ND Router Advertisement (RA) . . . . . . . . . . . . . . . 11		5.2. ND Router Advertisement (RA) . . . . . . . . . . . . . . . 12
	5.3. RPL DODAG Information Object (DIO) . . . . . . . . . . . . 11		5.3. RPL DODAG Information Object (DIO) . . . . . . . . . . . . 12
	5.4. ND Enhanced Address Registration Option (EARO) . . . . . . 11		5.4. ND Enhanced Address Registration Option (EARO) . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	A number of use cases, including the Industrial Internet, require a		A number of use cases, including the Industrial Internet, require a
	large scale deployment of sensors that can not be realized with wires		large scale deployment of sensors that can not be realized with wires
	and is only feasible over wireless Low power and Lossy Network (LLN)		and is only feasible over wireless Low power and Lossy Network (LLN)
	technologies. When simpler hub-and-spoke topologies are not		technologies. When simpler hub-and-spoke topologies are not
	sufficient for the expected throughput and density, mesh networks		sufficient for the expected throughput and density, mesh networks
	must be deployed, which implies the concepts of hosts and routers,		must be deployed, which implies the concepts of hosts and routers,
	whether operated at Layer-2 or Layer-3.		whether operated at Layer-2 or Layer-3.
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 45 ¶
	Readers are expected to be familiar with all the terms and concepts		Readers are expected to be familiar with all the terms and concepts
	that are discussed in "Neighbor Discovery for IP version 6"		that are discussed in "Neighbor Discovery for IP version 6"
	[RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862],		[RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862],
	"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):		"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals" [RFC4919],		Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
	Neighbor Discovery Optimization for Low-power and Lossy Networks		Neighbor Discovery Optimization for Low-power and Lossy Networks
	[RFC6775] and "Transmission of IPv6 Packets over IEEE 802.15.4		[RFC6775] and "Transmission of IPv6 Packets over IEEE 802.15.4
	Networks" [RFC4944].		Networks" [RFC4944].
	Additionally, this document uses terminology from 6TiSCH [I-D.ietf-		Additionally, this document uses terminology from 6TiSCH [I-D.ietf-
	6tisch-terminology] and ROLL [I-D.ietf-roll-terminology].		6tisch-terminology] and ROLL [RFC7102].
	3. Overview		3. Overview
	The 6TiSCH architecture [I-D.ietf-6tisch-architecture] expects that		The 6TiSCH architecture [I-D.ietf-6tisch-architecture] expects that
	a 6LoWPAN device can connect as a leaf to a RPL network, where the		a 6LoWPAN device can connect as a leaf to a RPL network, where the
	leaf support is the minimal functionality to connect as a host to a		leaf support is the minimal functionality to connect as a host to a
	RPL network without the need to participate to the full routing		RPL network without the need to participate to the full routing
	protocol. The support of leaf can be implemented as a minor		protocol. The support of leaf can be implemented as a minor
	increment to 6LoWPAN ND, with the additional capability to carry a		increment to 6LoWPAN ND, with the additional capability to carry a
	sequence number that is used to track the movements of the device,		sequence number that is used to track the movements of the device,
	skipping to change at page 8, line 19 ¶		skipping to change at page 8, line 19 ¶
	each individual ND lookup/advertisement in a peer to peer model where		each individual ND lookup/advertisement in a peer to peer model where
	each lookup may be between different parties. This is not the case		each lookup may be between different parties. This is not the case
	in a 6LoWPAN ND LLN where, as illustrated in Figure 2, the 6LBR		in a 6LoWPAN ND LLN where, as illustrated in Figure 2, the 6LBR
	terminates all the flows and may store security information for later		terminates all the flows and may store security information for later
	validation.		validation.
	Additionally SEND requires considerably enlarged ND messages to carry		Additionally SEND requires considerably enlarged ND messages to carry
	cryptographic material, and requires that each protected address is		cryptographic material, and requires that each protected address is
	generated cryptographically, which implies the computation of a		generated cryptographically, which implies the computation of a
	different key for each Cryptographically Generated Address (CGA).		different key for each Cryptographically Generated Address (CGA).
			SEND as defined in [RFC3971] is thus largely unsuitable for
			application in a LLN.
	Once an Address is registered, the 6LBR maintains a state for that		Once an Address is registered, the 6LBR maintains a state for that
	Address and is in position to bind securely the first registration		Address and is in position to bind securely the first registration
	with the Node that placed it, whether the Address is CGA or not. It		with the Node that placed it, whether the Address is CGA or not. It
	should thus be possible to protect the ownership of all the addresses		should thus be possible to protect the ownership of all the addresses
	of a 6LoWPAN Node with a single key, and there should not be a need		of a 6LoWPAN Node with a single key, and there should not be a need
	to carry the cryptographic material more than once to the 6LBR.		to carry the cryptographic material more than once to the 6LBR.
			The energy constraint is usually a foremost factor, and attention
			should be paid to minimize the burden on the CPU. Hardware-assisted
			support of variants of the Counter with CBC-MAC [RFC3610] (CCM)
			authenticated encryption block cipher mode such as CCM* are common in
			LowPower ship-set implementations, and 6LoWPAN ND security mechanism
			should be capable to reuse them when applicable.
			Finally, the code footprint in the device being also an issue, the
			capability to reuse not only hardware-assist mechanisms but also
			software across layers has to be considered. For instance, if code
			has to be present for upper-layer operations, e.g AES-CCM Cipher
			Suites for Transport Layer Security (TLS) [RFC6655], then the
			capability to reuse that code should be considered.
	4. Requirements		4. Requirements
	4.1. Requirements Related to Mobility		4.1. Requirements Related to Mobility
	Due to the nature of LLN networks, even a fixed 6LoWPAN Node may		Due to the nature of LLN networks, even a fixed 6LoWPAN Node may
	change its point of attachment (a 6LR) and may not be able to notify		change its point of attachment (a 6LR) and may not be able to notify
	the 6LR that it has disconnected from. It results that the previous		the 6LR that it has disconnected from. It results that the previous
	6LR may still attract traffic that it cannot deliver any more. When		6LR may still attract traffic that it cannot deliver any more. When
	the 6LR changes, there is thus a need to identify stale states and		the 6LR changes, there is thus a need to identify stale states and
	restore reachability timely.		restore reachability timely.
	skipping to change at page 9, line 36 ¶		skipping to change at page 10, line 4 ¶
	Req2.3: Depending on their applicability to LLNs, other standard mesh		Req2.3: Depending on their applicability to LLNs, other standard mesh
	/MANET protocols MAY be considered as well.		/MANET protocols MAY be considered as well.
	4.3. Requirements Related to the Variety of Low-Power Link types		4.3. Requirements Related to the Variety of Low-Power Link types
	6LoWPAN ND [RFC6775] was defined with a focus on IEEE802.15.4 and in		6LoWPAN ND [RFC6775] was defined with a focus on IEEE802.15.4 and in
	particular the capability to derive a unique Identifier from a		particular the capability to derive a unique Identifier from a
	globally unique MAC-64 address. At this point, the 6lo Working Group		globally unique MAC-64 address. At this point, the 6lo Working Group
	is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique		is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique
	to other link types ITU-T G.9959 [I-D.brandt-6man-lowpanz], Master-		to other link types ITU-T G.9959 [I-D.brandt-6man-lowpanz], Master-
	Slave/Token-Passing [I-D.ietf-6man-6lobac], DECT Ultra Low Energy		Slave/Token-Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy [I-D
	[I-D.mariager-6lowpan-v6over-dect-ule], Near Field Communication [I-D		.ietf-6lo-dect-ule], Near Field Communication [I-D.hong-6lo-ipv6
	.hong-6lo-ipv6-over-nfc], as well as IEEE1901.2 Narrowband Powerline		-over-nfc], as well as IEEE1901.2 Narrowband Powerline Communication
	Communication Networks [I-D.popa-6lo-6loplc-ipv6-over-		Networks [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and
	ieee19012-networks] and BLUETOOTH(R) Low Energy [I-D.ietf-6lo-btle].		BLUETOOTH(R) Low Energy [I-D.ietf-6lo-btle].
	Related requirements are:		Related requirements are:
	Req3.1: The support of the registration mechanism SHOULD be extended		Req3.1: The support of the registration mechanism SHOULD be extended
	to more LLN links, matching at least the links that are considered by		to more LLN links, matching at least the links that are considered by
	6lo as well as other popular Low-Power links such as Low-Power Wi-Fi.		6lo as well as other popular Low-Power links such as Low-Power Wi-Fi.
	Req3.2: As part of this extension, a mechanism to compute a unique		Req3.2: As part of this extension, a mechanism to compute a unique
	Identifier should be provided, with the capability to form a Link-		Identifier should be provided, with the capability to form a Link-
	Local Address that can not be a duplicate. The Identifier SHOULD be		Local Address that can not be a duplicate. The Identifier SHOULD be
	skipping to change at page 10, line 22 ¶		skipping to change at page 10, line 42 ¶
	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.
	4.5. Requirements Related to Security		4.5. Requirements Related to Security
	In order to guarantee the operations of the 6LoWPAN ND flows, the		In order to guarantee the operations of the 6LoWPAN ND flows, the
	spoofing of the 6LR, 6LBR and 6BBRs roles should be avoided. Once a		spoofing of the 6LR, 6LBR and 6BBRs roles should be avoided. Once a
	node successfully registers an address, 6LoWPAN ND should provide the		node successfully registers an address, 6LoWPAN ND should provide
	means to protect that ownership even if the node is sleeping. In		energy-efficient means to protect that ownership even if the node is
	particular, the 6LR and the 6LBR then should be able to verify		sleeping. In particular, the 6LR and the 6LBR then should be able to
	whether a subsequent registration for a same Address comes from a		verify whether a subsequent registration for a same Address comes
	same node or is a duplicate.		from a same node or is a duplicate.
	Related requirements are:		Related requirements are:
	Req5.1: 6LoWPAN ND SHOULD provide a mechanism for the 6LR, 6LBR and		Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for
	6BBR to authenticate and authorize one another for their respective		the 6LR, 6LBR and 6BBR to authenticate and authorize one another for
	roles, as well as with the 6LoWPAN Node for the role of 6LR.		their respective roles, as well as with the 6LoWPAN Node for the role
			of 6LR.
	Req5.2: 6LoWPAN ND SHOULD provide a mechanism for the 6LR and the		Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for
	6LBR to validate whether a new registration corresponds to a same		the 6LR and the 6LBR to validate whether a new registration
	6LoWPAN Node, and, if not, determine the rightful owner, and deny or		corresponds to a same 6LoWPAN Node, and, if not, determine the
	clean-up the registration that is deemed in excess.		rightful owner, and deny or clean-up the registration that is deemed
			in excess.
			Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet
			sizes. In particular, the NS, NA, DAR and DAC messages for a re-
			registration flow SHOULD NOT exceed 80 octets so as to fit in a
			secured IEEE802.15.4 frame.
			Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be
			computationally intensive on the LoWPAN Node CPU. When a Key hash
			calculation is employed, a mechanism lighter than SHA-1 SHOULD be
			preferred.
			Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate
			SHOULD be minimized.
			Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable CCM* for use
			at both Layer 2 and Layer 3, and SHOULD enable the reuse of security
			code that has to be present on the device for upper layer security
			such as TLS.
			Req5.7: Public key and signature sizes SHOULD be minimized while
			maintaining adequate confidentiality and data origin authentication
			for multiple types of applications with various degrees of
			criticality.
	4.6. Requirements Related to Low-Power devices		4.6. Requirements Related to Low-Power devices
	The ND registration method is designed to save energy on Low-Power		The ND registration method is designed to save energy on Low-Power
	devices, and in particular enable duty-cycled devices that are		devices, and in particular enable duty-cycled devices that are
	sleeping most of the time and not capable to defend their own		sleeping most of the time and not capable to defend their own
	Addresses against always-on devices.		Addresses against always-on devices.
	Related requirements are:		Related requirements are:
	skipping to change at page 11, line 4 ¶		skipping to change at page 11, line 51 ¶
	Related requirements are:		Related requirements are:
	Req6.1: The registration mechanism SHOULD be applicable to a Low-		Req6.1: The registration mechanism SHOULD be applicable to a Low-
	Power device regardless of the link type, and enable a 6BBR to		Power device regardless of the link type, and enable a 6BBR to
	operate as a proxy to defend the registered Addresses on its behalf.		operate as a proxy to defend the registered Addresses on its behalf.
	5. Suggested Changes to Protocol Elements		5. Suggested Changes to Protocol Elements
	5.1. ND Neighbor Solicitation (NS)		5.1. ND Neighbor Solicitation (NS)
	The NS message used for registration should use a source address that		The NS message used for registration should use a source address that
	respects the rules in [RFC6775], [RFC4861], and [RFC4429] for DAD.		respects the rules in [RFC6775], [RFC4861], and [RFC4429] for DAD.
	The SLLA Option may be present but only if the address passed DAD,		The SLLA Option may be present but only if the address passed DAD,
	and it is used to allow the 6LR to respond as opposed to as a		and it is used to allow the 6LR to respond as opposed to as a
	registration mechanism.		registration mechanism.
	The address that is being registered is the target address in the NS		The address that is being registered is the target address in the NS
	message and the TLLA Option must be present.		message and the TLLA Option must be present.
	5.2. ND Router Advertisement (RA)		5.2. ND Router Advertisement (RA)
	[I-D.chakrabarti-nordmark-6man-efficient-nd] adds an 'E' bit in the		[I-D.chakrabarti-nordmark-6man-efficient-nd] adds an 'E' bit in the
	Router Advertisement flag, as well as a new Registrar Address Option		Router Advertisement flag, as well as a new Registrar Address Option
	(RAO). These fields are probably pertinent to LLNs inclusion into a		(RAO). These fields are probably pertinent to LLNs inclusion into a
	revised 6LoWPAN ND should be studied.		revised 6LoWPAN ND should be studied. If the new 6LoWPAN flows
			require a change of behaviour (e.g. registering the Target of the NS
			message) then the RA must indicate that the router supports the new
			capability, and the NS must indicate that the Target is registered as
			opposed to the Source in an unequivocal fashion.
	There is some amount of duplication between the options in the RPL		There is some amount of duplication between the options in the RPL
	DIO [RFC6550] and the options in the ND RA messages. At the same		DIO [RFC6550] and the options in the ND RA messages. At the same
	time, there are a number of options, including the 6LoWPAN Context		time, there are a number of options, including the 6LoWPAN Context
	Option (6CO) [RFC6775], the MTU and the SLLA Options [RFC4861] that		Option (6CO) [RFC6775], the MTU and the SLLA Options [RFC4861] that
	can only be found in the RA messages. Considering that these options		can only be found in the RA messages. Considering that these options
	are useful for a joining node, the recommendation would be to		are useful for a joining node, the recommendation would be to
	associate the RA messages to the join beacon, and make them rare when		associate the RA messages to the join beacon, and make them rare when
	the network is stable. On the other hand, the DIO message is to be		the network is stable. On the other hand, the DIO message is to be
	used as the propagated heartbeat of the RPL network and provide the		used as the propagated heartbeat of the RPL network and provide the
	skipping to change at page 12, line 36 ¶		skipping to change at page 13, line 31 ¶
	Status: 8-bit integer. A new value of 3 is suggested to indicate a		Status: 8-bit integer. A new value of 3 is suggested to indicate a
	rejection due to an obsolete TID, typically an indication of a		rejection due to an obsolete TID, typically an indication of a
	movement.		movement.
	RPLInstanceID: 8-bit integer. This field is set to 0 when unused.		RPLInstanceID: 8-bit integer. This field is set to 0 when unused.
	Otherwise it contains the RPLInstanceID for which this address is		Otherwise it contains the RPLInstanceID for which this address is
	registered, as specified in RPL [RFC6550], and discussed in		registered, as specified in RPL [RFC6550], and discussed in
	particular in section 3.1.2.		particular in section 3.1.2.
	P: One bit flag. Indicates that the address is to be redistributed		P: One bit flag. When the bit is set, the address being registered
	to obtain reachability, e.g. into the RPL protocol, or for ND		is Target of the NS as opposed to the Source, for instance to
	proxy operation.		enable ND proxy operation.
	N: One bit flag. Set if the device moved. If not set, the 6BBR will		N: One bit flag. Set if the device moved. If not set, the 6BBR will
	refrain from sending gratuitous NA(O) or other form of distributed		refrain from sending gratuitous NA(O) or other form of distributed
	ND cache clean-up over the backbone. For instance, the flag		ND cache clean-up over the backbone. For instance, the flag
	should be reset after the DAD operation upon address formation.		should be reset after the DAD operation upon address formation.
	6. Security Considerations		6. Security Considerations
	This specification expects that the link layer is sufficiently		This specification expects that the link layer is sufficiently
	protected, either by means of physical or IP security for the		protected, either by means of physical or IP security for the
	skipping to change at page 14, line 17 ¶		skipping to change at page 15, line 17 ¶
	[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6		[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
	Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,		Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
	September 2011.		September 2011.
	[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,		[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
	Levis, P., Pister, K., Struik, R., Vasseur, JP. and R.		Levis, P., Pister, K., Struik, R., Vasseur, JP. and R.
	Alexander, "RPL: IPv6 Routing Protocol for Low-Power and		Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
	Lossy Networks", RFC 6550, March 2012.		Lossy Networks", RFC 6550, March 2012.
			[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
			Transport Layer Security (TLS)", RFC 6655, July 2012.
	[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann,		[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann,
	"Neighbor Discovery Optimization for IPv6 over Low-Power		"Neighbor Discovery Optimization for IPv6 over Low-Power
	Wireless Personal Area Networks (6LoWPANs)", RFC 6775,		Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
	November 2012.		November 2012.
	[RFC6830] Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The		[RFC6830] Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The
	Locator/ID Separation Protocol (LISP)", RFC 6830, January		Locator/ID Separation Protocol (LISP)", RFC 6830, January
	2013.		2013.
	9.2. Informative References		9.2. Informative References
	skipping to change at page 14, line 45 ¶		skipping to change at page 15, line 48 ¶
	Wasserman, "Wired and Wireless IPv6 Neighbor Discovery		Wasserman, "Wired and Wireless IPv6 Neighbor Discovery
	Optimizations", Internet-Draft draft-chakrabarti-nordmark-		Optimizations", Internet-Draft draft-chakrabarti-nordmark-
	6man-efficient-nd-04, October 2013.		6man-efficient-nd-04, October 2013.
	[I-D.hong-6lo-ipv6-over-nfc]		[I-D.hong-6lo-ipv6-over-nfc]
	Hong, Y., Choi, Y., Youn, J., Kim, D. and J. Choi,		Hong, Y., Choi, Y., Youn, J., Kim, D. and J. Choi,
	"Transmission of IPv6 Packets over Near Field		"Transmission of IPv6 Packets over Near Field
	Communication", Internet-Draft draft-hong-6lo-ipv6-over-		Communication", Internet-Draft draft-hong-6lo-ipv6-over-
	nfc-01, August 2014.		nfc-01, August 2014.
			[I-D.ietf-6lo-6lobac]
			Lynn, K., Martocci, J., Neilson, C. and S. Donaldson,
			"Transmission of IPv6 over MS/TP Networks", Internet-Draft
			draft-ietf-6lo-6lobac-00, July 2014.
	[I-D.ietf-6lo-btle]		[I-D.ietf-6lo-btle]
	Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,		Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
	Shelby, Z. and C. Gomez, "Transmission of IPv6 Packets		Shelby, Z. and C. Gomez, "Transmission of IPv6 Packets
	over BLUETOOTH(R) Low Energy", Internet-Draft draft-ietf-		over BLUETOOTH(R) Low Energy", Internet-Draft draft-ietf-
	6lo-btle-02, June 2014.		6lo-btle-02, June 2014.
	[I-D.ietf-6man-6lobac]		[I-D.ietf-6lo-dect-ule]
	Lynn, K., Martocci, J., Neilson, C. and S. Donaldson,		Mariager, P., Petersen, J., Shelby, Z., Logt, M. and D.
	"Transmission of IPv6 over MS/TP Networks", Internet-Draft		Barthel, "Transmission of IPv6 Packets over DECT Ultra Low
	draft-ietf-6man-6lobac-01, March 2012.		Energy", Internet-Draft draft-ietf-6lo-dect-ule-00, June
			2014.
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., Watteyne, T. and R. Assimiti, "An		Thubert, P., Watteyne, T. and R. Assimiti, "An
	Architecture for IPv6 over the TSCH mode of IEEE		Architecture for IPv6 over the TSCH mode of IEEE
	802.15.4e", Internet-Draft draft-ietf-6tisch-		802.15.4e", Internet-Draft draft-ietf-6tisch-
	architecture-01, February 2014.		architecture-01, February 2014.
	[I-D.ietf-6tisch-terminology]		[I-D.ietf-6tisch-terminology]
	Palattella, M., Thubert, P., Watteyne, T. and Q. Wang,		Palattella, M., Thubert, P., Watteyne, T. and Q. Wang,
	"Terminology in IPv6 over the TSCH mode of IEEE		"Terminology in IPv6 over the TSCH mode of IEEE
	802.15.4e", Internet-Draft draft-ietf-6tisch-		802.15.4e", Internet-Draft draft-ietf-6tisch-
	terminology-00, November 2013.		terminology-00, November 2013.
	[I-D.ietf-roll-terminology]
	Vasseur, J., "Terms used in Routing for Low power And
	Lossy Networks", Internet-Draft draft-ietf-roll-
	terminology-13, October 2013.
	[I-D.mariager-6lowpan-v6over-dect-ule]
	Mariager, P., Petersen, J. and Z. Shelby, "Transmission of
	IPv6 Packets over DECT Ultra Low Energy", Internet-Draft
	draft-mariager-6lowpan-v6over-dect-ule-03, July 2013.
	[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]		[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]
	Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets		Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets
	over IEEE 1901.2 Narrowband Powerline Communication		over IEEE 1901.2 Narrowband Powerline Communication
	Networks", Internet-Draft draft-popa-6lo-6loplc-ipv6-over-		Networks", Internet-Draft draft-popa-6lo-6loplc-ipv6-over-
	ieee19012-networks-00, March 2014.		ieee19012-networks-00, March 2014.
			[RFC3610] Whiting, D., Housley, R. and N. Ferguson, "Counter with
			CBC-MAC (CCM)", RFC 3610, September 2003.
	[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P.		[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P.
	Thubert, "Network Mobility (NEMO) Basic Support Protocol",		Thubert, "Network Mobility (NEMO) Basic Support Protocol",
	RFC 3963, January 2005.		RFC 3963, January 2005.
	[RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure		[RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",		[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, March 2005.		RFC 3972, March 2005.
	[RFC4389] Thaler, D., Talwar, M. and C. Patel, "Neighbor Discovery		[RFC4389] Thaler, D., Talwar, M. and C. Patel, "Neighbor Discovery
	Proxies (ND Proxy)", RFC 4389, April 2006.		Proxies (ND Proxy)", RFC 4389, April 2006.
	[RFC4919] Kushalnagar, N., Montenegro, G. and C. Schumacher, "IPv6		[RFC4919] Kushalnagar, N., Montenegro, G. and C. Schumacher, "IPv6
	over Low-Power Wireless Personal Area Networks (6LoWPANs):		over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals", RFC		Overview, Assumptions, Problem Statement, and Goals", RFC
	4919, August 2007.		4919, August 2007.
			[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
			Lossy Networks", RFC 7102, January 2014.
	Author's Address		Author's Address
	Pascal Thubert, editor		Pascal Thubert, editor
	Cisco Systems, Inc		Cisco Systems, Inc
	Building D		Building D
	45 Allee des Ormes - BP1200		45 Allee des Ormes - BP1200
	MOUGINS - Sophia Antipolis, 06254		MOUGINS - Sophia Antipolis, 06254
	FRANCE		FRANCE
	Phone: +33 497 23 26 34		Phone: +33 497 23 26 34
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
End of changes. 21 change blocks.
	54 lines changed or deleted		106 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/