draft-ietf-6man-stable-privacy-addresses-03.txt		draft-ietf-6man-stable-privacy-addresses-04.txt
	IPv6 maintenance Working Group (6man) F. Gont		IPv6 maintenance Working Group (6man) F. Gont
	Internet-Draft SI6 Networks / UTN-FRH		Internet-Draft SI6 Networks / UTN-FRH
	Intended status: Standards Track January 27, 2013		Intended status: Standards Track March 21, 2013
	Expires: July 31, 2013		Expires: September 22, 2013
	A method for Generating Stable Privacy-Enhanced Addresses with IPv6		A method for Generating Stable Privacy-Enhanced Addresses with IPv6
	Stateless Address Autoconfiguration (SLAAC)		Stateless Address Autoconfiguration (SLAAC)
	draft-ietf-6man-stable-privacy-addresses-03		draft-ietf-6man-stable-privacy-addresses-04
	Abstract		Abstract
	This document specifies a method for generating IPv6 Interface		This document specifies a method for generating IPv6 Interface
	Identifiers to be used with IPv6 Stateless Address Autoconfiguration		Identifiers to be used with IPv6 Stateless Address Autoconfiguration
	(SLAAC), such that addresses configured using this method are stable		(SLAAC), such that addresses configured using this method are stable
	within each subnet, but the Interface Identifier changes when hosts		within each subnet, but the Interface Identifier changes when hosts
	move from one network to another. The aforementioned method is meant		move from one network to another. The aforementioned method is meant
	to be an alternative to generating Interface Identifiers based on		to be an alternative to generating Interface Identifiers based on
	IEEE identifiers, such that the benefits of stable addresses can be		IEEE identifiers, such that the benefits of stable addresses can be
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 July 31, 2013.		This Internet-Draft will expire on September 22, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 34		skipping to change at page 8, line 34
	non-volatile memory). See Section 4 for additional details.		non-volatile memory). See Section 4 for additional details.
	secret_key:		secret_key:
	A secret key that is not known by the attacker. The secret		A secret key that is not known by the attacker. The secret
	key MUST be initialized at system installation time to a		key MUST be initialized at system installation time to a
	pseudo-random number (see [RFC4086] for randomness		pseudo-random number (see [RFC4086] for randomness
	requirements for security). An implementation MAY provide the		requirements for security). An implementation MAY provide the
	means for the user to change the secret key.		means for the user to change the secret key.
	2. The Interface Identifier is finally obtained by taking the		2. The Interface Identifier is finally obtained by taking the
	leftmost 64 bits of the RID value computed in the previous step,		leftmost 64 bits of the RID value computed in the previous step.
	and setting bit 6 (the leftmost bit is numbered 0) to zero. This		The resulting Interface Identifier should be compared against the
	creates an interface identifier with the universal/local bit		list of reserved interface identifiers [IANA-RESERVED-IID], and
	indicating local significance only. The resulting Interface		against those interface identifiers already employed in an
	Identifier should be compared against the list of reserved		address of the same network interface and the same network
	interface identifiers [IANA-RESERVED-IID], and to those interface		prefix. In the event that an unacceptable identifier has been
	identifiers already employed in an address of the same network		generated, this situation should be handled in the same way as
	interface and the same network prefix. In the event that an		the case of duplicate addresses (see Section 4).
	unacceptable identifier has been generated, this situation should
	be handled in the same way as the case of duplicate addresses
	(see Section 4).
	This document does not require the use of any specific PRF for the		This document does not require the use of any specific PRF for the
	function F() above, since the choice of such PRF is usually a trade-		function F() above, since the choice of such PRF is usually a trade-
	off between a number of properties (processing requirements, ease of		off between a number of properties (processing requirements, ease of
	implementation, possible intellectual property rights, etc.), and		implementation, possible intellectual property rights, etc.), and
	since the best possible choice for F() might be different for		since the best possible choice for F() might be different for
	different types of devices (e.g. embedded systems vs. regular		different types of devices (e.g. embedded systems vs. regular
	servers) and might possibly change over time.		servers) and might possibly change over time.
	Note that the result of F() in the algorithm above is no more secure		Note that the result of F() in the algorithm above is no more secure
End of changes. 4 change blocks.
	15 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/