< draft-ietf-ipngwg-addrconf-privacy-02.txt		draft-ietf-ipngwg-addrconf-privacy-03.txt >
			Please post. Tnx.
	INTERNET-DRAFT Thomas Narten		INTERNET-DRAFT Thomas Narten
	<draft-ietf-ipngwg-addrconf-privacy-02.txt> IBM		<draft-ietf-ipngwg-addrconf-privacy-03.txt> IBM
	Richard Draves		Richard Draves
	Microsoft Research		Microsoft Research
	July 14, 2000		September 19, 2000
	Privacy Extensions for Stateless Address Autoconfiguration in IPv6		Privacy Extensions for Stateless Address Autoconfiguration in IPv6
	<draft-ietf-ipngwg-addrconf-privacy-02.txt>		<draft-ietf-ipngwg-addrconf-privacy-03.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 43 ¶
	Abstract		Abstract
	Nodes use IPv6 stateless address autoconfiguration to generate		Nodes use IPv6 stateless address autoconfiguration to generate
	addresses without the necessity of a DHCP server. Addresses are		addresses without the necessity of a DHCP server. Addresses are
	formed by combining network prefixes with an interface identifier. On		formed by combining network prefixes with an interface identifier. On
	interfaces that contain embedded IEEE Identifiers, the interface		interfaces that contain embedded IEEE Identifiers, the interface
	identifier is typically derived from it. On other interface types,		identifier is typically derived from it. On other interface types,
	the interface identifier is generated through other means, for		the interface identifier is generated through other means, for
	example, via random number generation. This document describes an		example, via random number generation. This document describes an
	optional extension to IPv6 stateless address autoconfiguration for		extension to IPv6 stateless address autoconfiguration for interfaces
	interfaces whose interface identifier is derived from an IEEE		whose interface identifier is derived from an IEEE identifier. Use of
	identifier. Use of the extension causes nodes to generate global-		the extension causes nodes to generate global-scope addresses from
	scope addresses from interface identifiers that change over time,		interface identifiers that change over time, even in cases where the
	even in cases where the interface contains an embedded IEEE		interface contains an embedded IEEE identifier. Changing the
	identifier. Changing the interface identifier (and the global-scope		interface identifier (and the global-scope addresses generated from
	addresses generated from it) over time makes it more difficult for		it) over time makes it more difficult for eavesdroppers and other
	eavesdroppers and other information collectors to identify when		information collectors to identify when different addresses used in
	different addresses used in different transactions actually		different transactions actually correspond to the same node.
	correspond to the same node.
	Contents		Contents
	Status of this Memo.......................................... 1		Status of this Memo.......................................... 1
	1. Introduction............................................. 2		1. Introduction............................................. 2
	2. Background............................................... 3		2. Background............................................... 3
	2.1. Extended Use of the Same Identifier................. 3		2.1. Extended Use of the Same Identifier................. 3
	2.2. Not a New Issue..................................... 4		2.2. Not a New Issue..................................... 4
	2.3. Possible Approaches................................. 6		2.3. Possible Approaches................................. 6
	3. Protocol Description..................................... 7		3. Protocol Description..................................... 7
	3.1. Assumptions......................................... 8		3.1. Assumptions......................................... 8
	3.2. Generation Of Randomized Interface Identifiers...... 8		3.2. Generation Of Randomized Interface Identifiers...... 9
	3.3. Generating Anonymous Addresses...................... 10		3.3. Generating Anonymous Addresses...................... 10
	3.4. Expiration of Anonymous Addresses................... 11		3.4. Expiration of Anonymous Addresses................... 11
	3.5. Regeneration of Randomized Interface Identifiers.... 12		3.5. Regeneration of Randomized Interface Identifiers.... 12
	4. Implications of Changing Interface Identifiers........... 13		4. Implications of Changing Interface Identifiers........... 13
	5. Defined Constants........................................ 13		5. Defined Constants........................................ 14
	6. Open Issues and Future Work.............................. 14		6. Open Issues and Future Work.............................. 14
	7. Security Considerations.................................. 14		7. Security Considerations.................................. 14
	8. Acknowledgments.......................................... 14		8. Acknowledgments.......................................... 14
	9. References............................................... 15		9. References............................................... 15
	1. Introduction		1. Introduction
	skipping to change at page 3, line 23 ¶		skipping to change at page 3, line 22 ¶
	unique and may also change over time. The focus of this document is		unique and may also change over time. The focus of this document is
	on addresses derived from IEEE identifiers, as the concern being		on addresses derived from IEEE identifiers, as the concern being
	addressed exists only in those cases where the interface identifier		addressed exists only in those cases where the interface identifier
	is globally unique and non-changing. The rest of this document		is globally unique and non-changing. The rest of this document
	assumes that IEEE identifiers are being used, but the techniques		assumes that IEEE identifiers are being used, but the techniques
	described may also apply to interfaces with other types of globally		described may also apply to interfaces with other types of globally
	unique and persistent identifiers.		unique and persistent identifiers.
	This document discusses concerns associated with the embedding of		This document discusses concerns associated with the embedding of
	non-changing interface identifiers within IPv6 addresses and		non-changing interface identifiers within IPv6 addresses and
	describes optional extensions to stateless address autoconfiguration		describes extensions to stateless address autoconfiguration that can
	that can help mitigate those concerns in environments where such		help mitigate those concerns in environments where such concerns are
	concerns are significant. Section 2 provides background information		significant. Section 2 provides background information on the issue.
	on the issue. Section 3 describes a procedure for generating		Section 3 describes a procedure for generating alternate interface
	alternate interface identifiers and global-scope addresses. Section 4		identifiers and global-scope addresses. Section 4 discusses
	discusses implications of changing interface identifiers.		implications of changing interface identifiers.
	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 [KEYWORDS].		document are to be interpreted as described in [KEYWORDS].
	2. Background		2. Background
	This section discusses the problem in more detail, provides context		This section discusses the problem in more detail, provides context
	for evaluating the significance of the concerns in specific		for evaluating the significance of the concerns in specific
	environments and makes comparisons with existing practices.		environments and makes comparisons with existing practices.
	skipping to change at page 8, line 19 ¶		skipping to change at page 8, line 18 ¶
	future address (or identifier) based on a current one and it is		future address (or identifier) based on a current one and it is
	difficult to determine previous addresses (or identifiers) knowing		difficult to determine previous addresses (or identifiers) knowing
	only the present one.		only the present one.
	4) Generate a set of addresses from the same (randomized) interface		4) Generate a set of addresses from the same (randomized) interface
	identifier, one address for each prefix for which a global address		identifier, one address for each prefix for which a global address
	has been generated via stateless address autoconfiguration. Using		has been generated via stateless address autoconfiguration. Using
	the same interface identifier to generate a set of anonymous		the same interface identifier to generate a set of anonymous
	addresses reduces the number of IP multicast groups a host must		addresses reduces the number of IP multicast groups a host must
	join. Nodes join the solicited-node multicast address for each		join. Nodes join the solicited-node multicast address for each
	unicast address they support, and solicted-node addresses are		unicast address they support, and solicited-node addresses are
	dependent only on the low-order bits of the corresponding address.		dependent only on the low-order bits of the corresponding address.
	This decision was made to address the concern that a node that		This decision was made to address the concern that a node that
	joins a large number of multicast groups may be required to put		joins a large number of multicast groups may be required to put
	its interface into promiscuous mode, resulting in possible reduced		its interface into promiscuous mode, resulting in possible reduced
	performance.		performance.
	3.1. Assumptions		3.1. Assumptions
	The following algorithm assumes that each interface maintains an		The following algorithm assumes that each interface maintains an
	associated randomized interface identifier. When anonymous addresses		associated randomized interface identifier. When anonymous addresses
	skipping to change at page 8, line 42 ¶		skipping to change at page 8, line 41 ¶
	changes over time as described below, but the same identifier can be		changes over time as described below, but the same identifier can be
	used to generate more than one anonymous address.		used to generate more than one anonymous address.
	The algorithm also assumes that for a given anonymous address, one		The algorithm also assumes that for a given anonymous address, one
	can determine the corresponding public address. When an anonymous		can determine the corresponding public address. When an anonymous
	address is deprecated, a new anonymous address is generated. The		address is deprecated, a new anonymous address is generated. The
	specific valid and preferred lifetimes for the new address are		specific valid and preferred lifetimes for the new address are
	dependent on the corresponding lifetime values in the public address.		dependent on the corresponding lifetime values in the public address.
	Finally, this document assumes that when a node initiates outgoing		Finally, this document assumes that when a node initiates outgoing
	communication, anonymous addresses are preferred over public		communication, anonymous addresses can be given preference over other
	addresses. The details of this requirement are specified in		public addresses. This can mean that all outgoing connections use
	[ADDR_SELECT].		anonymous addresses by default, or that applications individually
			indicate whether they prefer to use anonymous or public addresses.
			Giving preference to anonymous address is consistent with on-going
			work that addresses the topic of source address-selection in the more
			general case [ADDR_SELECT].
	3.2. Generation Of Randomized Interface Identifiers.		3.2. Generation Of Randomized Interface Identifiers.
	We describe two approaches for the maintenance of the randomized		We describe two approaches for the maintenance of the randomized
	interface identifier. The first assumes the presence of stable		interface identifier. The first assumes the presence of stable
	storage that can be used to record state history for use as input		storage that can be used to record state history for use as input
	into the next iteration of the algorithm across system restarts. A		into the next iteration of the algorithm across system restarts. A
	second approach addresses the case where stable storage is		second approach addresses the case where stable storage is
	unavailable and a randomized interface identifier may need to be		unavailable and a randomized interface identifier may need to be
	generated at random.		generated at random.
	skipping to change at page 11, line 22 ¶		skipping to change at page 11, line 26 ¶
	an implementation MUST NOT create an anonymous address with a zero		an implementation MUST NOT create an anonymous address with a zero
	Preferred Lifetime.		Preferred Lifetime.
	4) New anonymous addresses are created by appending the interface's		4) New anonymous addresses are created by appending the interface's
	current randomized interface identifier to the prefix that was		current randomized interface identifier to the prefix that was
	used to generate the corresponding public address. If by chance		used to generate the corresponding public address. If by chance
	the new anonymous address is the same as an address already		the new anonymous address is the same as an address already
	assigned to the interface, generate a new randomized interface		assigned to the interface, generate a new randomized interface
	identifier and repeat this step.		identifier and repeat this step.
	5) Perform duplicate address detection (DAD) on the generated		5) Perform duplicate address detection (DAD) on the generated
	anonymous address. If DAD indicates the address is already in use,		anonymous address. If DAD indicates the address is already in use,
	generate a new randomized interface identifer as described in		generate a new randomized interface identifier as described in
	Section 3.2 above, and repeat the previous steps as appropriate up		Section 3.2 above, and repeat the previous steps as appropriate up
	to 5 times. If after 5 consecutive attempts no non-unique address		to 5 times. If after 5 consecutive attempts no non-unique address
	was generated, log a system error and give up attempting to		was generated, log a system error and give up attempting to
	generate anonymous addresses for that interface.		generate anonymous addresses for that interface.
	Note: because multiple anonymous addresses are generated from the		Note: because multiple anonymous addresses are generated from the
	same associated randomized interface identifier, there is little		same associated randomized interface identifier, there is little
	benefit in running DAD on every anonymous address. This document		benefit in running DAD on every anonymous address. This document
	recommends that DAD be run on the first address generated from a		recommends that DAD be run on the first address generated from a
	given randomized identifier, but that DAD be skipped on all		given randomized identifier, but that DAD be skipped on all
	skipping to change at page 13, line 40 ¶		skipping to change at page 13, line 45 ¶
	Some servers refuse to grant access to clients for which no DNS name		Some servers refuse to grant access to clients for which no DNS name
	exists. That is, they perform a DNS PTR query to determine the DNS		exists. That is, they perform a DNS PTR query to determine the DNS
	name, and may then also perform an A query on the returned name to		name, and may then also perform an A query on the returned name to
	verify that the returned DNS name maps back into the address being		verify that the returned DNS name maps back into the address being
	used. Consequently, clients not properly registered in the DNS may be		used. Consequently, clients not properly registered in the DNS may be
	unable to access some services. As noted earlier, however, a node's		unable to access some services. As noted earlier, however, a node's
	DNS name (if non-changing) serves as a constant identifier. If the		DNS name (if non-changing) serves as a constant identifier. If the
	extension described in this document becomes widely deployed, servers		extension described in this document becomes widely deployed, servers
	will likely need to change their behavior to not require every		will likely need to change their behavior to not require every
	address be in the DNS. One alternative is that DNS servers (for		address be in the DNS. Another alternative is to register anonymous
	client machines) may need to fabricate "dummy" answers so that all		addresses in DNS using random names (for example a string version of
	addresses, whether used or not, appear to have DNS names associated		the address itself).
	with them. Another alternative is to register anonymous addresses in
	DNS using random names (for example a string version of the address
	itself).
	5. Defined Constants		5. Defined Constants
	Constants defined in this document include:		Constants defined in this document include:
	ANON_VALID_LIFETIME -- Default value: 1 week. Users should be able to		ANON_VALID_LIFETIME -- Default value: 1 week. Users should be able to
	override the default value.		override the default value.
	ANON_PREFERRED_LIFETIME -- Default value: 1 day. Users should be able		ANON_PREFERRED_LIFETIME -- Default value: 1 day. Users should be able
	to override the default value.		to override the default value.
	REGEN_ADVANCE -- 5 seconds		REGEN_ADVANCE -- 5 seconds
End of changes. 12 change blocks.
	32 lines changed or deleted		33 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/