< draft-sarikaya-6lo-ap-nd-03.txt		draft-sarikaya-6lo-ap-nd-04.txt >
	6lo M. Sethi, Ed.		6lo M. Sethi, Ed.
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Updates: 6775 (if approved) P. Thubert		Updates: 6775 (if approved) P. Thubert
	Intended status: Standards Track Cisco		Intended status: Standards Track Cisco
	Expires: February 17, 2017 B. Sarikaya		Expires: February 23, 2017 B. Sarikaya, Ed.
	Huawei USA		Huawei USA
	August 16, 2016		August 22, 2016
	Address Protected Neighbor Discovery for Low-power and Lossy Networks		Address Protected Neighbor Discovery for Low-power and Lossy Networks
	draft-sarikaya-6lo-ap-nd-03		draft-sarikaya-6lo-ap-nd-04
	Abstract		Abstract
	This document defines an extension to 6LoWPAN Neighbor Discovery.		This document defines an extension to 6LoWPAN Neighbor Discovery.
	This extension is designed for low-power and lossy network		This extension is designed for low-power and lossy network
	environments and it supports multi-hop operation. Nodes supporting		environments and it supports multi-hop operation. Nodes supporting
	this extension compute a Cryptographically Unique Interface ID and		this extension compute a Cryptographically Unique Interface ID and
	associate it with one or more of their Registered Addresses. The		associate it with one or more of their Registered Addresses. The
	Cryptographic ID (Crypto-ID) uniquely identifies the owner of the		Cryptographic ID (Crypto-ID) uniquely identifies the owner of the
	Registered Address. It is used in place of the EUI-64 address that		Registered Address. It is used in place of the EUI-64 address that
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 17, 2017.		This Internet-Draft will expire on February 23, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 8, line 26 ¶		skipping to change at page 8, line 26 ¶
	the node moves at a different place and receives a different prefix.		the node moves at a different place and receives a different prefix.
	In this scenario, the node uses the same Crypto-ID to protect its new		In this scenario, the node uses the same Crypto-ID to protect its new
	IPv6 address. This prevents other nodes from stealing the address		IPv6 address. This prevents other nodes from stealing the address
	and trying to use it as their source address.		and trying to use it as their source address.
	Note that if the device that moves always forms new MAC and IP		Note that if the device that moves always forms new MAC and IP
	address [RFC6775], then this new address can be used for		address [RFC6775], then this new address can be used for
	registration. In case of a collision of the new MAC and therefore IP		registration. In case of a collision of the new MAC and therefore IP
	address, the node can easily form a new IPv6 address. This is one		address, the node can easily form a new IPv6 address. This is one
	case where the use of Crypto-ID would not be needed. Crypto-ID or		case where the use of Crypto-ID would not be needed. Crypto-ID or
	ND-PAR should be activated when when the IP address is claimed at		ND-PAR should be activated when the IP address is claimed at another
	another place, or for a different MAC address at the same place, e.g.		place, or for a different MAC address at the same place, e.g. for MAC
	for MAC address privacy		address privacy [I-D.ietf-6man-ipv6-address-generation-privacy].
	[I-D.ietf-6man-ipv6-address-generation-privacy].
	6LN 6LR		6LN 6LR
	| |		| |
	|<------------------- RA --------------------------|		|<------------------- RA --------------------------|
	| |		| |
	|----------- NS with ARO and Crypto-ID ----------->|		|----------- NS with ARO and Crypto-ID ----------->|
	| |		| |
	|<---------- NA with ARO (status=req-proof) -------|		|<---------- NA with ARO (status=req-proof) -------|
	| |		| |
	|----------- NS with ARO and Crypto-ID ----------->|		|----------- NS with ARO and Crypto-ID ----------->|
	skipping to change at page 14, line 23 ¶		skipping to change at page 14, line 23 ¶
	The same considerations regarding the threats to the Local Link		The same considerations regarding the threats to the Local Link
	Network covered in [RFC3971] apply.		Network covered in [RFC3971] apply.
	The threats discussed in Section 9.2 of [RFC3971] are countered by		The threats discussed in Section 9.2 of [RFC3971] are countered by
	the protocol described in this document as well.		the protocol described in this document as well.
	Collisions of Crypto-ID is a possibility that needs to be considered.		Collisions of Crypto-ID is a possibility that needs to be considered.
	The formula for calculating probability of a collision is 1 -		The formula for calculating probability of a collision is 1 -
	e^{-k^2/(2n)}. If the Crypto-ID is 64-bit long, then the chance of		e^{-k^2/(2n)}. If the Crypto-ID is 64-bit long, then the chance of
	finding a collision is 0.01% when we the network contains 66 million		finding a collision is 0.01% when the network contains 66 million
	nodes. It is important to note the collision is only relevant when		nodes. It is important to note that the collision is only relevant
	this happens withing one stub network (6LBR). A collision of ID in		when this happens within one stub network (6LBR). A collision of ID
	ND-PAR is a rare event. However, when such a collision does happen,		in ND-PAR is a rare event. However, when such a collision does
	the protocol operation is not affected, although it opens a window		happen, the protocol operation is not affected, although it opens a
	for a node to hijack an address from another. The link-layer		window for a node to hijack an address from another. The link-layer
	security ensures that the nodes would normally not be aware of a		security ensures that the nodes would normally not be aware of a
	collision on the subnet. If a malicious node is able to gain		collision on the subnet. If a malicious node is able to gain
	knowledge of a collision through other means, the only thing that it		knowledge of a collision through other means, the only thing that it
	could do is to steal addresses from the other honest. This would be		could do is to steal addresses from the other honest node. This
	no different from what is already possible in a 6lo network today.		would be no different from what is already possible in a 6lo network
			today.
	6. IANA considerations		6. IANA considerations
	IANA is requested to assign two new option type values, TBA1 and TBA2		IANA is requested to assign two new option type values, TBA1 and TBA2
	under the subregistry "IPv6 Neighbor Discovery Option Formats".		under the subregistry "IPv6 Neighbor Discovery Option Formats".
	7. Acknowledgements		7. Acknowledgements
	We are grateful to Rene Struik and Robert Moskowitz for their		We are grateful to Rene Struik and Robert Moskowitz for their
	comments that lead to many improvements to this document.		comments that lead to many improvements to this document.
	skipping to change at page 17, line 24 ¶		skipping to change at page 17, line 30 ¶
	Pascal Thubert		Pascal Thubert
	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
	Behcet Sarikaya		Behcet Sarikaya (editor)
	Huawei USA		Huawei USA
	5340 Legacy Dr. Building 3		5340 Legacy Dr. Building 3
	Plano, TX 75024		Plano, TX 75024
	Email: sarikaya@ieee.org		Email: sarikaya@ieee.org
End of changes. 8 change blocks.
	17 lines changed or deleted		17 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/