draft-ietf-6man-rfc4941bis-01.txt		draft-ietf-6man-rfc4941bis-02.txt
	IPv6 Maintenance (6man) Working Group F. Gont		IPv6 Maintenance (6man) Working Group F. Gont
	Internet-Draft SI6 Networks / UTN-FRH		Internet-Draft SI6 Networks / UTN-FRH
	Obsoletes: rfc4941 (if approved) S. Krishnan		Obsoletes: rfc4941 (if approved) S. Krishnan
	Intended status: Standards Track Ericsson Research		Intended status: Standards Track Ericsson Research
	Expires: September 12, 2019 T. Narten		Expires: January 9, 2020 T. Narten
	IBM Corporation		IBM Corporation
	R. Draves		R. Draves
	Microsoft Research		Microsoft Research
	March 11, 2019		July 8, 2019
	Privacy Extensions for Stateless Address Autoconfiguration in IPv6		Privacy Extensions for Stateless Address Autoconfiguration in IPv6
	draft-ietf-6man-rfc4941bis-01		draft-ietf-6man-rfc4941bis-02
	Abstract		Abstract
	Nodes use IPv6 stateless address autoconfiguration to generate		Nodes use IPv6 stateless address autoconfiguration to generate
	addresses using a combination of locally available information and		addresses using a combination of locally available information and
	information advertised by routers. Addresses are formed by combining		information advertised by routers. Addresses are formed by combining
	network prefixes with an interface identifier. This document		network prefixes with an interface identifier. This document
	describes an extension that causes nodes to generate global scope		describes an extension that causes nodes to generate global scope
	addresses from interface identifiers that change over time. Changing		addresses from interface identifiers that change over time. Changing
	the interface identifier (and the global scope addresses generated		the interface identifier (and the global scope addresses generated
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 September 12, 2019.		This Internet-Draft will expire on January 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	skipping to change at page 7, line 50 ¶		skipping to change at page 7, line 50 ¶
	requiring application-specific enablement. This document also		requiring application-specific enablement. This document also
	assumes that an API will exist that allows individual applications to		assumes that an API will exist that allows individual applications to
	indicate whether they prefer to use temporary or stable addresses and		indicate whether they prefer to use temporary or stable addresses and
	override the system defaults.		override the system defaults.
	3.2. Generation of Randomized Interface Identifiers		3.2. Generation of Randomized Interface Identifiers
	The following subsections specify some possible algorithms for		The following subsections specify some possible algorithms for
	generating temporary interface identifiers that comply with the		generating temporary interface identifiers that comply with the
	requirements in [I-D.gont-6man-non-stable-iids]. The algorithm		requirements in [I-D.gont-6man-non-stable-iids]. The algorithm
	specified in Section 3.2.1 benefits from a Peseudo-Random Number		specified in Section 3.2.1 benefits from a Pseudo-Random Number
	Generator (PRNG) available on the system. On the other hand, the		Generator (PRNG) available on the system. On the other hand, the
	algorithm specified in Section 3.2.2 allows for code reuse by nodes		algorithm specified in Section 3.2.2 allows for code reuse by nodes
	that implement [RFC7217].		that implement [RFC7217].
	3.2.1. Simple Randomized Interface Identifiers		3.2.1. Simple Randomized Interface Identifiers
	One possible approach would be to select a pseudorandom number of the		One possible approach would be to select a pseudorandom number of the
	appropriate length. A node employing this algorithm should generate		appropriate length. A node employing this algorithm should generate
	IIDs as follows:		IIDs as follows:
	skipping to change at page 10, line 33 ¶		skipping to change at page 10, line 33 ¶
	[RFC4862] describes the steps for generating a link-local address		[RFC4862] describes the steps for generating a link-local address
	when an interface becomes enabled as well as the steps for generating		when an interface becomes enabled as well as the steps for generating
	addresses for other scopes. This document extends [RFC4862] as		addresses for other scopes. This document extends [RFC4862] as
	follows. When processing a Router Advertisement with a Prefix		follows. When processing a Router Advertisement with a Prefix
	Information option carrying a global scope prefix for the purposes of		Information option carrying a global scope prefix for the purposes of
	address autoconfiguration (i.e., the A bit is set), the node MUST		address autoconfiguration (i.e., the A bit is set), the node MUST
	perform the following steps:		perform the following steps:
	1. Process the Prefix Information Option as defined in [RFC4862],		1. Process the Prefix Information Option as defined in [RFC4862],
	either creating a new stable address or adjusting the lifetimes		adjusting the lifetimes of existing temporary addresses. If a
	of existing addresses, both stable and temporary. If a received		received option may extend the lifetimes of temporary addresses,
	option will extend the lifetime of a stable address, the		with the overall constraint that no temporary addresses should
	lifetimes of temporary addresses should be extended, subject to		ever remain "valid" or "preferred" for a time longer than
	the overall constraint that no temporary addresses should ever
	remain "valid" or "preferred" for a time longer than
	(TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME -		(TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME -
	DESYNC_FACTOR) respectively. The configuration variables		DESYNC_FACTOR) respectively. The configuration variables
	TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to		TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to
	approximate target lifetimes for temporary addresses.		approximate target lifetimes for temporary addresses.
	2. One way an implementation can satisfy the above constraints is to		2. One way an implementation can satisfy the above constraints is to
	associate with each temporary address a creation time (called		associate with each temporary address a creation time (called
	CREATION_TIME) that indicates the time at which the address was		CREATION_TIME) that indicates the time at which the address was
	created. When updating the preferred lifetime of an existing		created. When updating the preferred lifetime of an existing
	temporary address, it would be set to expire at whichever time is		temporary address, it would be set to expire at whichever time is
	earlier: the time indicated by the received lifetime or		earlier: the time indicated by the received lifetime or
	(CREATION_TIME + TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR). A		(CREATION_TIME + TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR). A
	similar approach can be used with the valid lifetime.		similar approach can be used with the valid lifetime.
	3. When a new stable address is created as described in [RFC4862],		3. If the node has not configured any temporary address for the
	or if the node has not configured any temporary address for the
	corresponding prefix, the node SHOULD create a new temporary		corresponding prefix, the node SHOULD create a new temporary
	address for such prefix.		address for such prefix.
	4. When creating a temporary address, the lifetime values MUST be		4. When creating a temporary address, the lifetime values MUST be
	derived from the corresponding prefix as follows:		derived from the corresponding prefix as follows:
	* Its Valid Lifetime is the lower of the Valid Lifetime of the		* Its Valid Lifetime is the lower of the Valid Lifetime of the
	prefix and TEMP_VALID_LIFETIME		prefix and TEMP_VALID_LIFETIME
	* Its Preferred Lifetime is the lower of the Preferred Lifetime		* Its Preferred Lifetime is the lower of the Preferred Lifetime
	of prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR.		of prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR.
	5. A temporary address is created only if this calculated Preferred		5. A temporary address is created only if this calculated Preferred
	Lifetime is greater than REGEN_ADVANCE time units. In		Lifetime is greater than REGEN_ADVANCE time units. In
	particular, an implementation MUST NOT create a temporary address		particular, an implementation MUST NOT create a temporary address
	with a zero Preferred Lifetime.		with a zero Preferred Lifetime.
	6. New temporary addresses MUST be created by appending the		6. New temporary addresses MUST be created by appending a randomized
	interface's current randomized interface identifier to the prefix		interface identifier (generates as described in Section 3.2 of
	that was received.		this document) to the prefix that was received.
	7. The node MUST perform duplicate address detection (DAD) on the		7. The node MUST perform duplicate address detection (DAD) on the
	generated temporary address. If DAD indicates the address is		generated temporary address. If DAD indicates the address is
	already in use, the node MUST generate a new randomized interface		already in use, the node MUST generate a new randomized interface
	identifier, and repeat the previous steps as appropriate up to		identifier, and repeat the previous steps as appropriate up to
	TEMP_IDGEN_RETRIES times. If after TEMP_IDGEN_RETRIES		TEMP_IDGEN_RETRIES times. If after TEMP_IDGEN_RETRIES
	consecutive attempts no non-unique address was generated, the		consecutive attempts no non-unique address was generated, the
	node MUST log a system error and MUST NOT attempt to generate		node MUST log a system error and MUST NOT attempt to generate
	temporary addresses for that interface. Note that DAD MUST be		temporary addresses for that interface. Note that DAD MUST be
	performed on every unicast address generated from this randomized		performed on every unicast address generated from this randomized
	skipping to change at page 13, line 12 ¶		skipping to change at page 13, line 11 ¶
	new addresses varies from one environment to another, implementations		new addresses varies from one environment to another, implementations
	SHOULD provide end users with the ability to change the frequency at		SHOULD provide end users with the ability to change the frequency at
	which addresses are regenerated. The default value is given in		which addresses are regenerated. The default value is given in
	TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time		TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time
	at which to invalidate a temporary address depends on how		at which to invalidate a temporary address depends on how
	applications are used by end users. Thus, the suggested default		applications are used by end users. Thus, the suggested default
	value of one week (TEMP_VALID_LIFETIME) may not be appropriate in all		value of one week (TEMP_VALID_LIFETIME) may not be appropriate in all
	environments. Implementations SHOULD provide end users with the		environments. Implementations SHOULD provide end users with the
	ability to override both of these default values.		ability to override both of these default values.
	Finally, when an interface connects to a new link, a new set of		Finally, when an interface connects to a new (different) link, a new
	temporary addresses MUST be generated immediately. If a device moves		set of temporary addresses MUST be generated immediately. If a
	from one ethernet to another, generating a new set of temporary		device moves from one ethernet to another, generating a new set of
	addresses ensures that the device uses different randomized interface		temporary addresses ensures that the device uses different randomized
	identifiers for the temporary addresses associated with the two		interface identifiers for the temporary addresses associated with the
	links, making it more difficult to correlate addresses from the two		two links, making it more difficult to correlate addresses from the
	different links as being from the same node. The node MAY follow any		two different links as being from the same node. The node MAY follow
	process available to it, to determine that the link change has		any process available to it, to determine that the link change has
	occurred. One such process is described by Detecting Network		occurred. One such process is described by "Simple Procedures for
	Attachment [RFC4135].		Detecting Network Attachment in IPv6" [RFC6059]. Detecting link
			changes would prevent link down/up events from causing temporary
			addresses to be (unnecessarily) regenerated.
	3.6. Deployment Considerations		3.6. Deployment Considerations
	Devices implementing this specification MUST provide a way for the		Devices implementing this specification MUST provide a way for the
	end user to explicitly enable or disable the use of temporary		end user to explicitly enable or disable the use of temporary
	addresses. In addition, a site might wish to disable the use of		addresses. In addition, a site might wish to disable the use of
	temporary addresses in order to simplify network debugging and		temporary addresses in order to simplify network debugging and
	operations. Consequently, implementations SHOULD provide a way for		operations. Consequently, implementations SHOULD provide a way for
	trusted system administrators to enable or disable the use of		trusted system administrators to enable or disable the use of
	temporary addresses.		temporary addresses.
	skipping to change at page 16, line 41 ¶		skipping to change at page 16, line 41 ¶
	8. Section 3.2.3 from [RFC4941] was removed, based on the		8. Section 3.2.3 from [RFC4941] was removed, based on the
	explanation of that very section of RFC4941.		explanation of that very section of RFC4941.
	9. All the verified errata for [RFC4941] has been incorporated.		9. All the verified errata for [RFC4941] has been incorporated.
	9. Acknowledgments		9. Acknowledgments
	The authors would like to thank (in alphabetical order) Brian		The authors would like to thank (in alphabetical order) Brian
	Carpenter, Tim Chown, Lorenzo Colitti, David Farmer, Tom Herbert, Bob		Carpenter, Tim Chown, Lorenzo Colitti, David Farmer, Tom Herbert, Bob
	Hinden, Michael Richardson, and Johanna Ullrich for providing		Hinden, Christian Huitema, Dave Plonka, Michael Richardson, Mark
	valuable comments on earlier versions of this document.		Smith, and Johanna Ullrich for providing valuable comments on earlier
			versions of this document.
	This document is based on [RFC4941] (a revision of RFC3041). Suresh		This document is based on [RFC4941] (a revision of RFC3041). Suresh
	Krishnan was the sole author of RFC4941. He would like to		Krishnan was the sole author of RFC4941. He would like to
	acknowledge the contributions of the ipv6 working group and, in		acknowledge the contributions of the ipv6 working group and, in
	particular, Jari Arkko, Pekka Nikander, Pekka Savola, Francis Dupont,		particular, Jari Arkko, Pekka Nikander, Pekka Savola, Francis Dupont,
	Brian Haberman, Tatuya Jinmei, and Margaret Wasserman for their		Brian Haberman, Tatuya Jinmei, and Margaret Wasserman for their
	detailed comments.		detailed comments.
	Rich Draves and Thomas Narten were the authors of RFC 3041. They		Rich Draves and Thomas Narten were the authors of RFC 3041. They
	would like to acknowledge the contributions of the ipv6 working group		would like to acknowledge the contributions of the ipv6 working group
	skipping to change at page 18, line 5 ¶		skipping to change at page 18, line 5 ¶
	[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers",		[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers",
	RFC 5453, DOI 10.17487/RFC5453, February 2009,		RFC 5453, DOI 10.17487/RFC5453, February 2009,
	<https://www.rfc-editor.org/info/rfc5453>.		<https://www.rfc-editor.org/info/rfc5453>.
	[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,		[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
	"Default Address Selection for Internet Protocol Version 6		"Default Address Selection for Internet Protocol Version 6
	(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,		(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
	<https://www.rfc-editor.org/info/rfc6724>.		<https://www.rfc-editor.org/info/rfc6724>.
	[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
	Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
	February 2014, <https://www.rfc-editor.org/info/rfc7136>.
	[RFC7217] Gont, F., "A Method for Generating Semantically Opaque		[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
	Interface Identifiers with IPv6 Stateless Address		Interface Identifiers with IPv6 Stateless Address
	Autoconfiguration (SLAAC)", RFC 7217,		Autoconfiguration (SLAAC)", RFC 7217,
	DOI 10.17487/RFC7217, April 2014,		DOI 10.17487/RFC7217, April 2014,
	<https://www.rfc-editor.org/info/rfc7217>.		<https://www.rfc-editor.org/info/rfc7217>.
	[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 19, line 10 ¶		skipping to change at page 19, line 10 ¶
	[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,		[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	DOI 10.17487/RFC1321, April 1992,		DOI 10.17487/RFC1321, April 1992,
	<https://www.rfc-editor.org/info/rfc1321>.		<https://www.rfc-editor.org/info/rfc1321>.
	[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,		[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
	C., and M. Carney, "Dynamic Host Configuration Protocol		C., and M. Carney, "Dynamic Host Configuration Protocol
	for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July		for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
	2003, <https://www.rfc-editor.org/info/rfc3315>.		2003, <https://www.rfc-editor.org/info/rfc3315>.
	[RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network
	Attachment in IPv6", RFC 4135, DOI 10.17487/RFC4135,
	August 2005, <https://www.rfc-editor.org/info/rfc4135>.
	[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational		[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
	Considerations and Issues with IPv6 DNS", RFC 4472,		Considerations and Issues with IPv6 DNS", RFC 4472,
	DOI 10.17487/RFC4472, April 2006,		DOI 10.17487/RFC4472, April 2006,
	<https://www.rfc-editor.org/info/rfc4472>.		<https://www.rfc-editor.org/info/rfc4472>.
	[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6		[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
	Socket API for Source Address Selection", RFC 5014,		Socket API for Source Address Selection", RFC 5014,
	DOI 10.17487/RFC5014, September 2007,		DOI 10.17487/RFC5014, September 2007,
	<https://www.rfc-editor.org/info/rfc5014>.		<https://www.rfc-editor.org/info/rfc5014>.
End of changes. 12 change blocks.
	36 lines changed or deleted		28 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/