< draft-sarikaya-6lo-cga-nd-00.txt		draft-sarikaya-6lo-cga-nd-01.txt >
	6lo B. Sarikaya, Ed.		6lo B. Sarikaya, Ed.
	Internet-Draft Huawei USA		Internet-Draft Huawei USA
	Intended status: Standards Track F. Xia		Intended status: Standards Track F. Xia
	Expires: January 2, 2015 Huawei Technologies Co., Ltd.		Expires: April 13, 2015 Huawei Technologies Co., Ltd.
	July 1, 2014		October 10, 2014
	Lightweight and Secure Neighbor Discovery for Low-power and Lossy		Lightweight and Secure Neighbor Discovery for Low-power and Lossy
	Networks		Networks
	draft-sarikaya-6lo-cga-nd-00		draft-sarikaya-6lo-cga-nd-01
	Abstract		Abstract
	Modifications to 6lowpan Neighbor Discovery protocol are proposed in		Modifications to 6lowpan Neighbor Discovery protocol are proposed in
	order to secure the neighbor discovery for low-power and lossy		order to secure the neighbor discovery for low-power and lossy
	networks. This document defines lightweight and secure version of		networks. This document defines lightweight and secure version of
	the neighbor discovery for low-power and lossy networks. The nodes		the neighbor discovery for low-power and lossy networks. The nodes
	generate a Cryptographically Generated Address, register the		generate a Cryptographically Generated Address, register the
	Cryptographically Generated Address with a default router and		Cryptographically Generated Address with a default router and
	periodically refresh the registration. Cryptographically generated		periodically refresh the registration. Cryptographically generated
	address and digital signatures are calculated using elliptic curve		address and digital signatures are calculated using elliptic curve
	cryptography, so that the cryptographic operations are suitable for		cryptography, so that the cryptographic operations are suitable for
	low power devices.		low power devices.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 2, 2015.		This Internet-Draft will expire on April 13, 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		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
	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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	4. New Options . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. New Options . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4.1. CGA Parameters and Digital Signature Option . . . . . . . 4		4.1. CGA Parameters and Digital Signature Option . . . . . . . 3
	4.2. Digital Signature Option . . . . . . . . . . . . . . . . . 6		4.2. Digital Signature Option . . . . . . . . . . . . . . . . 5
	4.3. Calculation of the Digital Signature and CGA Using ECC . . 7		4.3. Calculation of the Digital Signature and CGA Using ECC . 7
	5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 8		5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 7
	5.1. Packet Sizes . . . . . . . . . . . . . . . . . . . . . . . 9		5.1. Packet Sizes . . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 9
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10		6.1. Multihop Operation . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 11		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	9.2. Informative references . . . . . . . . . . . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . 12
			10.2. Informative references . . . . . . . . . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Neighbor discovery for IPv6 [RFC4861] and stateless address		Neighbor discovery for IPv6 [RFC4861] and stateless address
	autoconfiguration [RFC4862], together referred to as neighbor		autoconfiguration [RFC4862], together referred to as neighbor
	discovery protocols (NDP), are defined for regular hosts operating		discovery protocols (NDP), are defined for regular hosts operating
	with wired/wireless links. These protocols are not suitable and		with wired/wireless links. These protocols are not suitable and
	require optimizations for resource constrained, low power hosts		require optimizations for resource constrained, low power hosts
	operating with lossy wireless links. Neighbor discovery		operating with lossy wireless links. Neighbor discovery
	optimizations for 6lowpan networks include simple optimizations such		optimizations for 6lowpan networks include simple optimizations such
	skipping to change at page 3, line 49 ¶		skipping to change at page 3, line 29 ¶
	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 in this document is based on the definitions in		The terminology in this document is based on the definitions in
	[RFC3971], [RFC3972] in addition to the ones specified in [RFC6775].		[RFC3971], [RFC3972] in addition to the ones specified in [RFC6775].
	3. Problem Statement		3. Problem Statement
	In this section we state requirements of a secure neighbor discovery		6LowPAN neighbor discovery protocol [RFC6775] needs to be extended to
	protocol for low-power and lossy networks.		make it secure and also for being more efficient as well as other use
			cases. Requirements on such enhancements are stated in
	The protocol MUST be based on the Neighbor Discovery Optimization for		[I-D.thubert-6lo-rfc6775-update-reqs].
	Low-power and Lossy Networks protocol defined in [RFC6775] due to the
	host-initiated interactions to allow for sleeping hosts, elimination
	of multicast-based address resolution for hosts, etc.
	New options to be added to neighbor solicitation messages MUST lead
	to small packet sizes. Smaller packet sizes facilitate low-power
	transmission by resource constrained nodes on lossy links.
	CGA generation, signature and key hash calculation MUST avoid the use
	of SHA-1 which is known to have security flaws. In this document, we
	use SHA-2 instead of SHA-1 and thus avoid SHA-1's flaws.
	Public key and signature sizes MUST be minimized and signature
	calculation MUST be lightweight. In this document we adopt ECC and
	ECDSA with the P-256 curve in order to meet this requirement.
	4. New Options		4. New Options
	4.1. CGA Parameters and Digital Signature Option		4.1. CGA Parameters and Digital Signature Option
	This option contains both CGA parameters and the digital signature.		This option contains both CGA parameters and the digital signature.
	A summary of the CGA Parameters and Digital Signature Option format		A summary of the CGA Parameters and Digital Signature Option format
	is shown below.		is shown below.
	skipping to change at page 7, line 10 ¶		skipping to change at page 6, line 37 ¶
	Type		Type
	TBA2 for Digital Signature		TBA2 for Digital Signature
	Length		Length
	The length of the option (including the Type, Length, Reserved,		The length of the option (including the Type, Length, Reserved,
	Key Hash, Digital Signature and Padding fields) in units of 8		Key Hash, Digital Signature and Padding fields) in units of 8
	octets.		octets.
	Key Hash		Key Hash
	The Key Hash field is a 128-bit field containing the most		The Key Hash field is a 128-bit field containing the most
	significant (leftmost) 128 bits of a SHA-2 hash of the public key		significant (leftmost) 128 bits of a SHA-2 hash of the public key
	used for constructing the signature. This is the same as in		used for constructing the signature. This is the same as in
	[RFC3971] except for SHA-1 which has been replaced by SHA-2.		[RFC3971] except for SHA-1 which has been replaced by SHA-2.
	Digital Signature		Digital Signature
	Same as in Section 4.1.		Same as in Section 4.1.
	Padding
			Padding
	The Padding field contains a variable-length field containing as		The Padding field contains a variable-length field containing as
	many bytes long as remain after the end of the signature.		many bytes long as remain after the end of the signature.
	4.3. Calculation of the Digital Signature and CGA Using ECC		4.3. Calculation of the Digital Signature and CGA Using ECC
	Due to the use of Elliptic Curve Cryptography, the following		Due to the use of Elliptic Curve Cryptography, the following
	modifications are needed to [RFC3971] and [RFC3972].		modifications are needed to [RFC3971] and [RFC3972].
	The digital signature is constructed by using the sender's private		The digital signature is constructed by using the sender's private
	key over the same sequence of octets specified in Section 5.2 of		key over the same sequence of octets specified in Section 5.2 of
	[RFC3971] up to all neighbor discovery protocol options preceding the		[RFC3971] up to all neighbor discovery protocol options preceding the
	Digital Signature option containing the ECC-based signature. The		Digital Signature option containing the ECC-based signature. The
	signature value is computed using the ECDSA signature algorithm as		signature value is computed using the ECDSA signature algorithm as
	defined in [SEC1] and hash function SHA-256.		defined in [SEC1] and hash function SHA-256.
	Public Key is the most important parameter in CGA Parameters defined		Public Key is the most important parameter in CGA Parameters defined
	in Section 4.1. Public Key MUST be DER-encoded ASN.1 structure of		in Section 4.1. Public Key MUST be DER-encoded ASN.1 structure of
	the type SubjectPublicKeyInfo formatted as ECC Public Key. The		the type SubjectPublicKeyInfo formatted as ECC Public Key. The
	AlgorithmIdentifier, contained in ASN.1 structure of type		AlgorithmIdentifier, contained in ASN.1 structure of type
	SubjectPublicKeyInfo, MUST be the (unrestricted) id- ecPublicKey		SubjectPublicKeyInfo, MUST be the (unrestricted) id- ecPublicKey
	algorithm identifier, which is OID 1.2.840.10045.2.1, and the		algorithm identifier, which is OID 1.2.840.10045.2.1, and the
	subjectPublicKey MUST be formatted as an ECC Public Key, specified in		subjectPublicKey MUST be formatted as an ECC Public Key, specified in
	Section 2.2 of [RFC5480].		Section 2.2 of [RFC5480].
	Note that the ECC key lengths are determined by the namedCurves		Note that the ECC key lengths are determined by the namedCurves
	parameter stored in ECParameters field of the AlgorithmIdentifier.		parameter stored in ECParameters field of the AlgorithmIdentifier.
	The named curve to use is secp256r1 corresponding to P-256 which is		The named curve to use is secp256r1 corresponding to P-256 which is
	OID 1.2.840.10045.3.1.7 [SEC2].		OID 1.2.840.10045.3.1.7 [SEC2].
	skipping to change at page 8, line 23 ¶		skipping to change at page 8, line 8 ¶
	6LoWPAN Border Routers (6LBR) send router advertisements (RA).		6LoWPAN Border Routers (6LBR) send router advertisements (RA).
	6LoWPAN Nodes (6LN, or simply "nodes") receive these RAs and generate		6LoWPAN Nodes (6LN, or simply "nodes") receive these RAs and generate
	their own cryptographically generated addresses using elliptic curve		their own cryptographically generated addresses using elliptic curve
	cryptography as explained in Section 4.3. The node sends a neighbor		cryptography as explained in Section 4.3. The node sends a neighbor
	solicitation (NS) message with the address registration option (ARO)		solicitation (NS) message with the address registration option (ARO)
	to 6LBR. Such a NS is called an address registration NS.		to 6LBR. Such a NS is called an address registration NS.
	An LSEND for LLN node MUST send an address registration NS message		An LSEND for LLN node MUST send an address registration NS message
	after adding CGA Parameters and Digital Signature Option defined in		after adding CGA Parameters and Digital Signature Option defined in
	Section 4.1. Source address MUST be set to its crypotographically		Section 4.1. Source address MUST be set to its crypotographically
	generated address. An LSEND for LLN node MUST set the Owner		generated address. An LSEND for LLN node MUST set the Extended
	Interface Identifier field (EUI-64) in ARO to the rightmost 64 bits		Unique Identifier (EUI-64) field [Guide] in ARO to the rightmost 64
	of its crypotographically generated address. The Subnet Prefix field		bits of its crypotographically generated address. The Subnet Prefix
	of CGA Parameters MUST be set to the leftmost 64 bits of its		field of CGA Parameters MUST be set to the leftmost 64 bits of its
	crypotographically generated address. The Public Key field of CGA		crypotographically generated address. The Public Key field of CGA
	Parameters MUST be set to the node's ECC Public Key.		Parameters MUST be set to the node's ECC Public Key.
	It needs to be investigated whether to change SeND to use the Owner
	Interface Identifier (UII) for the CGA calculation as opposed to the
	source address. UII is more stable and a device could register all
	its addresses with a single CGA-based UII / keypair. It also needs
	to be investigated to modify 6LoWPAN ND [RFC6775] which registers the
	source address to change that to register the target address.
	6LBR receives the address registration NS. 6LBR then verifies the		6LBR receives the address registration NS. 6LBR then verifies the
	source address as described in Section 5.1.2. of [RFC3971] using the		source address as described in Section 5.1.2. of [RFC3971] using the
	claimed source address and CGA Parameters field in the message.		claimed source address and CGA Parameters field in the message.
	After successfully verifying the address 6LBR next does a		After successfully verifying the address 6LBR next does a
	cryptographic check of the signature included in the Digital		cryptographic check of the signature included in the Digital
	Signature field in the message. If all checks succeed then 6LBR		Signature field in the message. If all checks succeed then 6LBR
	performs a duplicate address detection procedure on the address. If		performs a duplicate address detection procedure on the address. If
	that also succeeds 6LBR registers the CGA in the neighbor cache. 6LBR		that also succeeds 6LBR registers the CGA in the neighbor cache. 6LBR
	also caches the node's public key.		also caches the node's public key.
	skipping to change at page 10, line 17 ¶		skipping to change at page 9, line 41 ¶
	octets with Padding of 7 octets. The total message size of an		octets with Padding of 7 octets. The total message size of an
	original LSEND address registration NS message is 216 octets and such		original LSEND address registration NS message is 216 octets and such
	a message can be encapsulated into three 802.15.4 frames.		a message can be encapsulated into three 802.15.4 frames.
	An address registration refresh NS message contains an ARO which is		An address registration refresh NS message contains an ARO which is
	16 octets and the digital signature option containing 16 octet key		16 octets and the digital signature option containing 16 octet key
	hash and 71 octet signature and 5 octet Padding. The message is 152		hash and 71 octet signature and 5 octet Padding. The message is 152
	octets long with the header. Such a message could be encapsulated in		octets long with the header. Such a message could be encapsulated in
	two 802.15.4 frames.		two 802.15.4 frames.
	6. Security Considerations		The overhead of LSEND is valid initially and in base LSEND, possibly
			after bootstrapping at the address registration neighbor solicitation
			message. It disappears after that as we explain below in Section 6
			in case optimal LSEND is used.
			6. Optimizations
			In this section we present optimizations to the base LSEND defined
			above. We use EUI-64 identifier instead of source address in CGA
			calculations. We also extend LSEND operation to 6LoWPAN multihop
			network.
			Digital signature and CGA are calculated over EUI-64 or interface id
			of the node. It is only done initially at once not repeated with
			every message the node sends. The calculation does not change even
			if the node has a new address since EUI-64 does not change. This
			means that this CGA can be used to claim multiple targets. The
			calculation is ECC based as described in Section 4.3.
			Protocol interactions are as defined in Section 5. The address
			registration NS message contains CGA Parameters and Digital Signature
			Option defined in Section 4.1. The node MUST set the Extended Unique
			Identifier (EUI-64) field [Guide] in ARO to the crypotographically
			generated address. The Subnet Prefix field of CGA Parameters MUST be
			set to the 64-bit prefix in the RA message received from 6LBR.
			Source address MUST be set to the prefix concatenated with the node's
			crypotographically generated address. The Public Key field of CGA
			Parameters MUST be set to the node's ECC Public Key.
			CGA calculated may need to be modified before it is used as EUI-64.
			The b2 bit or U/L or "u" bit MUST be set to zero for globally unique
			and b1 bit or I/G or "g" bit MUST be set to zero for unicast before
			using it in IPv6 address as the interface identifier. In LSEND,
			senders and receivers ignore any differences in the three leftmost
			bits and in bits 6 and 7 (i.e., the "u" and "g" bits) in the
			interface identifiers [RFC3972].
			The Target Address field in NS message is set to the prefix
			concatenated with the node's crypotographically generated address.
			This address does not need duplicate address detection as EUI-64 is
			globally unique. So a host cannot steal an address that is already
			registered unless it has the key for the EUI-64. The same EUI-64 can
			thus be used to protect multiple addresses e.g. when the node
			receives a different prefix. The node adds CGA Parameters (including
			Public Key) and Digital Signature Option defined in Section 4.1 into
			NS message. The node sends the address registration option (ARO)
			which is set to the CGA calculated.
			Protocol interactions given in xref target="Dynamic-fig"/> are
			modified a bit in that Digital Signature option with the public key
			and ARO are passed to and stored by the 6LR/6LBR on the first NS and
			not sent again the in the next NS.
			The 6LR/6LBR ensures first-come/first-serve by storing the ARO and
			the cryptographical material correlated to the target being
			registered. Then, if the node is the first to claim any address it
			likes, then it becomes owner of that address and the address is bound
			to the CGA in the 6LR/6LBR registry. This procedure avoids the
			constrained device to compute multiple keys for multiple addresses.
			The registration process allows the node to tie all the addresses to
			the same EUI-64 and have the 6LR/6LBR enforce first come first serve
			after that.
			6.1. Multihop Operation
			In multihop 6LoWPAN, 6LBR sends RAs with prefixes downstream and it
			is the 6LR that receives and relays them to the nodes. 6LR and 6LBR
			communicate with the ICMPv6 Duplicate Address Request (DAR) and the
			Duplicate Address Confirmation (DAC) messages. The DAR and DAC use
			the same message format as NS and NA with different ICMPv6 type
			values.
			In LSEND we extend DAR/DAC messages to carry CGA Parameters and
			Digital Signature Option defined in Section 4.1.
			In a multihop 6LoWPAN, the node exchanges the messages shown in
			Figure 1 with 6LR not with 6LBR. 6LBR must be aware of who owns an
			address (EUI-64) to defend the first user if there is an attacker on
			another 6LR. Because of this the content that the source signs and
			the signature needs to be propagated to the 6LBR in DAR message. For
			this purpose we need the DAR message sent by 6LR to 6LBR MUST contain
			CGA Parameters and Digital Signature Option carrying the CGA that the
			node calculates and its public key. DAR message also contains ARO.
			It is possible that occasionally, 6LR may miss the node's CGA (that
			it received in ARO) or the crypto information (that it received in
			CGA Parameters and Digital Signature Option). 6LR should be able to
			ask for it again. This is done by restarting the exchanges shown in
			Figure 1. The result enables 6LR to refresh CGA and public key
			information that was lost. 6LR MUST send DAR message with CGA
			Parameters and Digital Signature Option and ARO to 6LBR. 6LBR as a
			reply forms a DAC message with the information copied from the DAR
			and the Status field is set to zero. With this exchange, the 6LBR
			can (re)validate and store the CGA and crypto information to make
			sure that the 6LR is not a fake.
			7. Security Considerations
	The same considerations regarding the threats to the Local Link Not		The same considerations regarding the threats to the Local Link Not
	Covered (as in [RFC3971]) apply.		Covered (as 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.
	As to the attacks to the protocol itself, denial of service attacks		As to the attacks to the protocol itself, denial of service attacks
	that involve producing a very high number of packets are deemed		that involve producing a very high number of packets are deemed
	unlikely because of the assumptions on the node capabilities in low-		unlikely because of the assumptions on the node capabilities in low-
	power and lossy networks.		power and lossy networks.
	7. IANA considerations		8. IANA considerations
	This document defines two new options to be used in neighbor		This document defines two new options to be used in neighbor
	discovery protocol messages and new type values for CGA Parameters		discovery protocol messages and new type values for CGA Parameters
	and Digital Signature Option (TBA1) and Digital Signature Option		and Digital Signature Option (TBA1) and Digital Signature Option
	(TBA2) need to be assigned by IANA.		(TBA2) need to be assigned by IANA.
	This document defines 0xE8C47FB7FD2BB885DAB2D31A0F2808B4 for LSEND		This document defines 0xE8C47FB7FD2BB885DAB2D31A0F2808B4 for LSEND
	CGA Message Type Tag.		CGA Message Type Tag.
	8. Acknowledgements		9. Acknowledgements
	Greg Zaverucha from RIM made contributions to this document.		Greg Zaverucha from RIM made contributions to this document.
	Comments from Pascal Thubert are appreciated.		Comments from Pascal Thubert are appreciated.
	9. References		10. References
	9.1. Normative References
			10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor		[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
	Discovery (ND) Trust Models and Threats", RFC 3756,		Discovery (ND) Trust Models and Threats", RFC 3756, May
	May 2004.		2004.
	[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.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	skipping to change at page 11, line 35 ¶		skipping to change at page 13, line 5 ¶
	[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,		[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
	"Elliptic Curve Cryptography Subject Public Key		"Elliptic Curve Cryptography Subject Public Key
	Information", RFC 5480, March 2009.		Information", RFC 5480, March 2009.
	[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.
	[SEC1] "Standards for Efficient Crtptography Group. SEC 1:		[SEC1] "Standards for Efficient Crtptography Group. SEC 1:
	Elliptic Curve Cryptography Version 2.0", May 2009.		Elliptic Curve Cryptography Version 2.0", May 2009.
			[Guide] "Guidelines for 64-bit global Identifier (EUI-64TM)",
			November 2012,
			<http://standards.ieee.org/develop/regauth/tut/eui64.pdf>.
	[ANSIX9.62]		[ANSIX9.62]
	"American National Standards Institute (ANSI), ANS X9.62-		"American National Standards Institute (ANSI), ANS
	2005: The Elliptic Curve Digital Signature Algorithm		X9.62-2005: The Elliptic Curve Digital Signature Algorithm
	(ECDSA)", November 2005.		(ECDSA)", November 2005.
	9.2. Informative references		10.2. Informative references
	[SEC2] "Standards for Efficient Crtptography Group. SEC 2:		[SEC2] "Standards for Efficient Crtptography Group. SEC 2:
	Recommended Elliptic Curve Domain Parameters Version		Recommended Elliptic Curve Domain Parameters Version 2.0",
	2.0", January 2010.		January 2010.
	[FIPS-186-3]		[FIPS-186-3]
	"National Institute of Standards and Technology, "Digital		"National Institute of Standards and Technology, "Digital
	Signature Standard"", June 2009.		Signature Standard"", June 2009.
	[NIST-ST] "National Institute of Standards and Technology, "NIST		[NIST-ST] "National Institute of Standards and Technology, "NIST
	Comments on Cryptanalytic Attackts on SHA-1"",		Comments on Cryptanalytic Attackts on SHA-1"", January
	January 2009,		2009,
	<http://csrc.nist.gov/groups/ST/hash/statement.html>.		<http://csrc.nist.gov/groups/ST/hash/statement.html>.
			[I-D.rafiee-6man-ssas]
			Rafiee, H. and C. Meinel, "A Simple Secure Addressing
			Scheme for IPv6 AutoConfiguration (SSAS)", draft-rafiee-
			6man-ssas-11 (work in progress), September 2014.
			[I-D.thubert-6lo-rfc6775-update-reqs]
			Thubert, P., "Requirements for an update to 6LoWPAN ND",
			draft-thubert-6lo-rfc6775-update-reqs-04 (work in
			progress), August 2014.
	Authors' Addresses		Authors' Addresses
	Behcet Sarikaya (editor)		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
	Frank Xia		Frank Xia
	Huawei Technologies Co., Ltd.		Huawei Technologies Co., Ltd.
	101 Software Avenue, Yuhua District		101 Software Avenue, Yuhua District
	Nanjing, Jiangsu 210012, China		Nanjing, Jiangsu 210012, China
	Phone: ++86-25-56625443		Phone: ++86-25-56625443
	Email: xiayangsong@huawei.com		Email: xiayangsong@huawei.com
End of changes. 25 change blocks.
	71 lines changed or deleted		163 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/