draft-ietf-ipv6-privacy-addrs-v2-00.txt		draft-ietf-ipv6-privacy-addrs-v2-01.txt
	IPv6 Working Group T. Narten		IPv6 Working Group T. Narten
	Internet-Draft IBM Corporation		Internet-Draft IBM Corporation
	Expires: March 16, 2005 R. Draves		Expires: April 22, 2005 R. Draves
	Microsoft Research		Microsoft Research
	S. Krishnan		S. Krishnan
	Ericsson		Ericsson
	September 15, 2004		October 22, 2004
	Privacy Extensions for Stateless Address Autoconfiguration in IPv6		Privacy Extensions for Stateless Address Autoconfiguration in IPv6
	draft-ietf-ipv6-privacy-addrs-v2-00		draft-ietf-ipv6-privacy-addrs-v2-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	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		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36		skipping to change at page 1, line 37
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 16, 2005.		This Internet-Draft will expire on April 22, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	Nodes use IPv6 stateless address autoconfiguration to generate		Nodes use IPv6 stateless address autoconfiguration to generate
	addresses without the necessity of a Dynamic Host Configuration		addresses using a combination of locally available information and
	Protocol (DHCP) server. Addresses are formed by combining network		information advertised by routers. Addresses are formed by combining
	prefixes with an interface identifier. On interfaces that contain		network prefixes with an interface identifier. On interfaces that
	embedded IEEE Identifiers, the interface identifier is typically		contain embedded IEEE Identifiers, the interface identifier is
	derived from it. On other interface types, the interface identifier		typically derived from it. On other interface types, the interface
	is generated through other means, for example, via random number		identifier is generated through other means, for example, via random
	generation. This document describes an extension to IPv6 stateless		number generation. This document describes an extension to IPv6
	address autoconfiguration for interfaces whose interface identifier		stateless address autoconfiguration for interfaces whose interface
	is derived from an IEEE identifier. Use of the extension causes		identifier is derived from an IEEE identifier. Use of the extension
	nodes to generate global scope addresses from interface identifiers		causes nodes to generate global scope addresses from interface
	that change over time, even in cases where the interface contains an		identifiers that change over time, even in cases where the interface
	embedded IEEE identifier. Changing the interface identifier (and the		contains an embedded IEEE identifier. Changing the interface
	global scope addresses generated from it) over time makes it more		identifier (and the global scope addresses generated from it) over
	difficult for eavesdroppers and other information collectors to		time makes it more difficult for eavesdroppers and other information
	identify when different addresses used in different transactions		collectors to identify when different addresses used in different
	actually correspond to the same node.		transactions actually correspond to the same node.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Conventions used in this document . . . . . . . . . . . . 3		1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 4
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2 Conventions used in this document . . . . . . . . . . . . 4
	2.1 Extended Use of the Same Identifier . . . . . . . . . . . 4		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 5		2.1 Extended Use of the Same Identifier . . . . . . . . . . . 5
	2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 6		2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 6
	2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 7		2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 7
	3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9		2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 8
	3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9		3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10
	3.2 Generation Of Randomized Interface Identifiers . . . . . . 11		3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2.1 When Stable Storage Is Present . . . . . . . . . . . . 11		3.2 Generation Of Randomized Interface Identifiers . . . . . . 12
	3.2.2 In The Absence of Stable Storage . . . . . . . . . . . 12		3.2.1 When Stable Storage Is Present . . . . . . . . . . . . 12
	3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 13		3.2.2 In The Absence of Stable Storage . . . . . . . . . . . 13
	3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 13		3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 14
			3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 14
	3.4 Expiration of Temporary Addresses . . . . . . . . . . . . 15		3.4 Expiration of Temporary Addresses . . . . . . . . . . . . 15
	3.5 Regeneration of Randomized Interface Identifiers . . . . . 15		3.5 Regeneration of Randomized Interface Identifiers . . . . . 16
	3.6 Deployment Considerations . . . . . . . . . . . . . . . . 16		3.6 Deployment Considerations . . . . . . . . . . . . . . . . 17
	4. Implications of Changing Interface Identifiers . . . . . . . . 18		4. Implications of Changing Interface Identifiers . . . . . . . . 19
	5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 19		5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 20
	6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 20		6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21
	7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 21		7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 22
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 22		8. Changes from version 00 . . . . . . . . . . . . . . . . . . . 23
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23		9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	Intellectual Property and Copyright Statements . . . . . . . . 26		11.1 Normative References . . . . . . . . . . . . . . . . . . . . 26
			11.2 Informative References . . . . . . . . . . . . . . . . . . . 26
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
			Intellectual Property and Copyright Statements . . . . . . . . 29
	1. Introduction		1. Introduction
	Stateless address autoconfiguration [ADDRCONF] defines how an IPv6		Stateless address autoconfiguration [ADDRCONF] defines how an IPv6
	node generates addresses without the need for a DHCP server. Some		node generates addresses without the need for a DHCPv6 server. Some
	types of network interfaces come with an embedded IEEE Identifier		types of network interfaces come with an embedded IEEE Identifier
	(i.e., a link-layer MAC address), and in those cases stateless		(i.e., a link-layer MAC address), and in those cases stateless
	address autoconfiguration uses the IEEE identifier to generate a 64-		address autoconfiguration uses the IEEE identifier to generate a 64-
	bit interface identifier [ADDRARCH]. By design, the interface		bit interface identifier [ADDRARCH]. By design, the interface
	identifier is likely to be globally unique when generated in this		identifier is likely to be globally unique when generated in this
	fashion. The interface identifier is in turn appended to a prefix to		fashion. The interface identifier is in turn appended to a prefix to
	form a 128-bit IPv6 address.		form a 128-bit IPv6 address.
	All nodes combine interface identifiers (whether derived from an IEEE		All nodes combine interface identifiers (whether derived from an IEEE
	identifier or generated through some other technique) with the		identifier or generated through some other technique) with the
	reserved link-local prefix to generate link-local addresses for their		reserved link-local prefix to generate link-local addresses for their
	attached interfaces. Additional addresses can then be created by		attached interfaces. Additional addresses can then be created by
	combining prefixes advertised in Router Advertisements via Neighbor		combining prefixes advertised in Router Advertisements via Neighbor
	Discovery [DISCOVERY] with the interface identifier.		Discovery [DISCOVERY] with the interface identifier.
	Not all nodes and interfaces contain IEEE identifiers. In such		Not all nodes and interfaces contain IEEE identifiers. In such
	cases, an interface identifier is generated through some other means		cases, an interface identifier is generated through some other means
	(e.g., at random), and the resultant interface identifier is not		(e.g., at random), and the resultant interface identifier may not be
	globally unique and may also change over time. The focus of this		globally unique and may also change over time. The focus of this
	document is on addresses derived from IEEE identifiers, as the		document is on addresses derived from IEEE identifiers, as the
	concern being addressed exists only in those cases where the		concern being addressed exists only in those cases where the
	interface identifier is globally unique and non-changing. The rest		interface identifier is globally unique and non-changing. The rest
	of this document assumes that IEEE identifiers are being used, but		of this document assumes that IEEE identifiers are being used, but
	the techniques described may also apply to interfaces with other		the techniques described may also apply to interfaces with other
	types of globally unique and/or persistent identifiers.		types of globally unique and/or 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
	skipping to change at page 3, line 48		skipping to change at page 4, line 5
	help mitigate those concerns for individual users and in environments		help mitigate those concerns for individual users and in environments
	where such concerns are significant. Section 2 provides background		where such concerns are significant. Section 2 provides background
	information on the issue. Section 3 describes a procedure for		information on the issue. Section 3 describes a procedure for
	generating alternate interface identifiers and global scope		generating alternate interface identifiers and global scope
	addresses. Section 4 discusses implications of changing interface		addresses. Section 4 discusses implications of changing interface
	identifiers. The term "global scope addresses" is used in this		identifiers. The term "global scope addresses" is used in this
	document to collectively refer to "Global unicast addresses" as		document to collectively refer to "Global unicast addresses" as
	defined in [ADDRARCH] and "Unique local addresses" as defined in		defined in [ADDRARCH] and "Unique local addresses" as defined in
	[ULA]		[ULA]
	1.1 Conventions used in this document		1.1 Problem Statement
			Addresses generated using Stateless address autoconfiguration
			[ADDRCONF]contain an embedded 64-bit interface identifier, which
			remains constant over time. Anytime a fixed identifier is used in
			multiple contexts, it becomes possible to correlate seemingly
			unrelated activity using this identifier.
			The correlation can be performed by
			o An attacker who is in the path between the node in question and
			the peer(s) it is communicating to, and can view the IPv6
			addresses present in the datagrams.
			o An attacker who can access the communication logs of the peers
			with which the node has communicated.
			Since the identifier is embedded within the IPv6 address, which is a
			fundamental requirement of communication, it cannot be easily hidden.
			This document proposes a solution to this issue by generating
			interface identifiers which vary over time.
			Please note that an attacker, who is on path, may be able to perform
			significant correlation based on
			o The payload contents of the packets on the wire
			o The characteristics of the packets such as packet size and timing
			Use of temporary addresses will not prevent such payload based
			correlation
			1.2 Conventions used in this document
	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].
	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 4, line 23		skipping to change at page 5, line 23
	The use of a non-changing interface identifier to form addresses is a		The use of a non-changing interface identifier to form addresses is a
	specific instance of the more general case where a constant		specific instance of the more general case where a constant
	identifier is reused over an extended period of time and in multiple		identifier is reused over an extended period of time and in multiple
	independent activities. Anytime the same identifier is used in		independent activities. Anytime the same identifier is used in
	multiple contexts, it becomes possible for that identifier to be used		multiple contexts, it becomes possible for that identifier to be used
	to correlate seemingly unrelated activity. For example, a network		to correlate seemingly unrelated activity. For example, a network
	sniffer placed strategically on a link across which all traffic to/		sniffer placed strategically on a link across which all traffic to/
	from a particular host crosses could keep track of which destinations		from a particular host crosses could keep track of which destinations
	a node communicated with and at what times. Such information can in		a node communicated with and at what times. Such information can in
	some cases be used to infer things, such as what hours an employee		some cases be used to infer things, such as what hours an employee
	was active, when someone is at home, etc.		was active, when someone is at home, etc. Although it might appear
			that changing an address regularly in such environments would be
			desirable to lessen privacy concerns, it should be noted that the
			network prefix portion of an address also serves as a constant
			identifier. All nodes at (say) a home, would have the same network
			prefix, which identifies the topological location of those nodes.
			This has implications for privacy, though not at the same granularity
			as the concern that this document addresses. Specifically, all nodes
			within a home could be grouped together for the purposes of
			collecting information. If the network contains a very small number
			of nodes, say just one, changing just the interface identifier will
			not enhance privacy at all, since the prefix serves as a constant
			identifier.
	One of the requirements for correlating seemingly unrelated		One of the requirements for correlating seemingly unrelated
	activities is the use (and reuse) of an identifier that is		activities is the use (and reuse) of an identifier that is
	recognizable over time within different contexts. IP addresses		recognizable over time within different contexts. IP addresses
	provide one obvious example, but there are more. Many nodes also		provide one obvious example, but there are more. Many nodes also
	have DNS names associated with their addresses, in which case the DNS		have DNS names associated with their addresses, in which case the DNS
	name serves as a similar identifier. Although the DNS name		name serves as a similar identifier. Although the DNS name
	associated with an address is more work to obtain (it may require a		associated with an address is more work to obtain (it may require a
	DNS query) the information is often readily available. In such		DNS query) the information is often readily available. In such
	cases, changing the address on a machine over time would do little to		cases, changing the address on a machine over time would do little to
	skipping to change at page 5, line 9		skipping to change at page 6, line 21
	other parties. Even when higher layers encrypt their payloads,		other parties. Even when higher layers encrypt their payloads,
	addresses in packet headers appear in the clear. Consequently, if a		addresses in packet headers appear in the clear. Consequently, if a
	mobile host (e.g., laptop) accessed the network from several		mobile host (e.g., laptop) accessed the network from several
	different locations, an eavesdropper might be able to track the		different locations, an eavesdropper might be able to track the
	movement of that mobile host from place to place, even if the upper		movement of that mobile host from place to place, even if the upper
	layer payloads were encrypted.		layer payloads were encrypted.
	2.2 Address Usage in IPv4 Today		2.2 Address Usage in IPv4 Today
	Addresses used in today's Internet are often non-changing in practice		Addresses used in today's Internet are often non-changing in practice
	for extended periods of time, especially in non-home environments		for extended periods of time. In an increasing number of sites,
	(e.g., corporations, campuses, etc.). In such sites, addresses are		addresses are assigned statically and typically change infrequently.
	assigned statically and typically change infrequently. Over the last		Over the last few years, sites have begun moving away from static
	few years, sites have begun moving away from static allocation to		allocation to dynamic allocation via DHCP [DHCP]. In theory, the
	dynamic allocation via DHCP [DHCP]. In theory, the address a client		address a client gets via DHCP can change over time, but in practice
	gets via DHCP can change over time, but in practice servers often		servers often return the same address to the same client (unless
	return the same address to the same client (unless addresses are in		addresses are in such short supply that they are reused immediately
	such short supply that they are reused immediately by a different		by a different node when they become free). Thus, even within sites
	node when they become free). Thus, even within sites using DHCP,		using DHCP, clients frequently end up using the same address for
	clients frequently end up using the same address for weeks to months		weeks to months at a time.
	at a time.
	For home users accessing the Internet over dialup lines, the		For home users accessing the Internet over dialup lines, the
	situation is generally different. Such users do not have permanent		situation is generally different. Such users do not have permanent
	connections and are often assigned temporary addresses each time they		connections and are often assigned temporary addresses each time they
	connect to their ISP (e.g., AOL). Consequently, the addresses they		connect to their ISP (e.g., AOL). Consequently, the addresses they
	use change frequently over time and are shared among a number of		use change frequently over time and are shared among a number of
	different users. Thus, an address does not reliably identify a		different users. Thus, an address does not reliably identify a
	particular device over time spans of more than a few minutes.		particular device over time spans of more than a few minutes.
	A more interesting case concerns always-on connections (e.g., cable		A more interesting case concerns always-on connections (e.g., cable
	modems, ISDN, DSL, etc.) that result in a home site using the same		modems, ISDN, DSL, etc.) that result in a home site using the same
	address for extended periods of time. This is a scenario that is		address for extended periods of time. This is a scenario that is
	just starting to become common in IPv4 and promises to become more of		just starting to become common in IPv4 and promises to become more of
	a concern as always-on internet connectivity becomes widely		a concern as always-on internet connectivity becomes widely
	available. Although it might appear that changing an address		available.
	regularly in such environments would be desirable to lessen privacy
	concerns, it should be noted that the network prefix portion of an
	address also serves as a constant identifier. All nodes at (say) a
	home, would have the same network prefix, which identifies the
	topological location of those nodes. This has implications for
	privacy, though not at the same granularity as the concern that this
	document addresses. Specifically, all nodes within a home would be
	grouped together for the purposes of collecting information. This
	issue is difficult to address, because the routing prefix part of an
	address contains topology information and cannot contain arbitrary
	values.
	Finally, it should be noted that nodes that need a (non-changing) DNS		Finally, it should be noted that nodes that need a (non-changing) DNS
	name generally have static addresses assigned to them to simplify the		name generally have static addresses assigned to them to simplify the
	configuration of DNS servers. Although Dynamic DNS [DDNS] can be		configuration of DNS servers. Although Dynamic DNS [DDNS] can be
	used to update the DNS dynamically, it is not yet widely deployed.		used to update the DNS dynamically, it is not yet widely deployed.
	In addition, changing an address but keeping the same DNS name does		In addition, changing an address but keeping the same DNS name does
	not really address the underlying concern, since the DNS name becomes		not really address the underlying concern, since the DNS name becomes
	a non-changing identifier. Servers generally require a DNS name (so		a non-changing identifier. Servers generally require a DNS name (so
	clients can connect to them), and clients often do as well (e.g.,		clients can connect to them), and clients often do as well (e.g.,
	some servers refuse to speak to a client whose address cannot be		some servers refuse to speak to a client whose address cannot be
	skipping to change at page 6, line 33		skipping to change at page 7, line 33
	user's address could contain an interface identifier that remains the		user's address could contain an interface identifier that remains the
	same from one dialup session to the next, even if the rest of the		same from one dialup session to the next, even if the rest of the
	address changes. The way PPP is used today, however, PPP servers		address changes. The way PPP is used today, however, PPP servers
	typically unilaterally inform the client what address they are to use		typically unilaterally inform the client what address they are to use
	(i.e., the client doesn't generate one on its own). This practice,		(i.e., the client doesn't generate one on its own). This practice,
	if continued in IPv6, would avoid the concerns that are the focus of		if continued in IPv6, would avoid the concerns that are the focus of
	this document.		this document.
	A more troubling case concerns mobile devices (e.g., laptops, PDAs,		A more troubling case concerns mobile devices (e.g., laptops, PDAs,
	etc.) that move topologically within the Internet. Whenever they		etc.) that move topologically within the Internet. Whenever they
	move (in the absence of technology such as mobile IP [MOBILEIP]),		move they form new addresses for their current topological point of
	they form new addresses for their current topological point of
	attachment. This is typified today by the "road warrior" who has		attachment. This is typified today by the "road warrior" who has
	Internet connectivity both at home and at the office. While the		Internet connectivity both at home and at the office. While the
	node's address changes as it moves, however, the interface identifier		node's address changes as it moves, however, the interface identifier
	contained within the address remains the same (when derived from an		contained within the address remains the same (when derived from an
	IEEE Identifier). In such cases, the interface identifier can be		IEEE Identifier). In such cases, the interface identifier can be
	used to track the movement and usage of a particular machine. For		used to track the movement and usage of a particular machine. For
	example, a server that logs usage information together with a source		example, a server that logs usage information together with a source
	addresses, is also recording the interface identifier since it is		addresses, is also recording the interface identifier since it is
	embedded within an address. Consequently, any data-mining technique		embedded within an address. Consequently, any data-mining technique
	that correlates activity based on addresses could easily be extended		that correlates activity based on addresses could easily be extended
	skipping to change at page 7, line 14		skipping to change at page 8, line 14
	In summary, IPv6 addresses on a given interface generated via		In summary, IPv6 addresses on a given interface generated via
	Stateless Autoconfiguration contain the same interface identifier,		Stateless Autoconfiguration contain the same interface identifier,
	regardless of where within the Internet the device connects. This		regardless of where within the Internet the device connects. This
	facilitates the tracking of individual devices (and thus potentially		facilitates the tracking of individual devices (and thus potentially
	users). The purpose of this document is to define mechanisms that		users). The purpose of this document is to define mechanisms that
	eliminate this issue, in those situations where it is a concern.		eliminate this issue, in those situations where it is a concern.
	2.4 Possible Approaches		2.4 Possible Approaches
	One way to avoid some of the problems discussed above is to use DHCP		One way to avoid some of the problems discussed above is to use
	for obtaining addresses. With DHCP, the DHCP server could arrange to		DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be
	hand out addresses that change over time.		configured to hand out addresses that change over time. But DHCPv6
			will solve the privacy issue only if it frequently handed out
			constantly changing addresses to the nodes. Since this does not
			happen automatically, and is difficult to configure manually, DHCPv6
			is not a self contained alternative for solving the privacy issues
			addressed by this document. However, in the absence of stateless
			address autoconfiguration, DHCPv6 can be used for distributing
			temporary addresses to clients.
	Another approach, compatible with the stateless address		Another approach, compatible with the stateless address
	autoconfiguration architecture, would be to change the interface id		autoconfiguration architecture, would be to change the interface id
	portion of an address over time and generate new addresses from the		portion of an address over time and generate new addresses from the
	interface identifier for some address scopes. Changing the interface		interface identifier for some address scopes. Changing the interface
	identifier can make it more difficult to look at the IP addresses in		identifier can make it more difficult to look at the IP addresses in
	independent transactions and identify which ones actually correspond		independent transactions and identify which ones actually correspond
	to the same node, both in the case where the routing prefix portion		to the same node, both in the case where the routing prefix portion
	of an address changes and when it does not.		of an address changes and when it does not.
	skipping to change at page 9, line 42		skipping to change at page 10, line 42
	multicast groups a host must join. Nodes join the solicited-node		multicast groups a host must join. Nodes join the solicited-node
	multicast address for each unicast address they support, and		multicast address for each unicast address they support, and
	solicited-node addresses are dependent only on the low-order bits		solicited-node addresses are dependent only on the low-order bits
	of the corresponding address. This default behaviour was made to		of the corresponding address. This default behaviour was made to
	address the concern that a node that joins a large number of		address the concern that a node that joins a large number of
	multicast groups may be required to put its interface into		multicast groups may be required to put its interface into
	promiscuous mode, resulting in possible reduced performance.		promiscuous mode, resulting in possible reduced performance.
	A node highly concerned about privacy MAY use different interface		A node highly concerned about privacy MAY use different interface
	identifiers on different prefixes, resulting in a set of global		identifiers on different prefixes, resulting in a set of global
	addresses that cannot be easily tied to each other. This may be		addresses that cannot be easily tied to each other. For example
	useful, for example, to a mobile node using multiple wireless		a node MAY create different interface identifiers I1,I2, and I3
	interfaces to connect to multiple independent networks.		for use with different prefixes P1,P2, and P3 on the same
			interface.
	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 temporary addresses		associated randomized interface identifier. When temporary addresses
	are generated, the current value of the associated randomized		are generated, the current value of the associated randomized
	interface identifier is used. The actual value of the identifier		interface identifier is used. The actual value of the identifier
	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 temporary address.		used to generate more than one temporary address.
	The algorithm also assumes that for a given temporary address, an		The algorithm also assumes that for a given temporary address, an
	implementation can determine the corresponding public address from		implementation can determine the prefix from which it was generated.
	which it was generated. When a temporary address is deprecated, a		When a temporary address is deprecated, a new temporary address is
	new temporary address is generated. The specific valid and preferred		generated. The specific valid and preferred lifetimes for the new
	lifetimes for the new address are dependent on the corresponding		address are dependent on the corresponding lifetime values set for
	lifetime values in the public address.		the prefix from which it was generated.
	Finally, this document assumes that when a node initiates outgoing		Finally, this document assumes that when a node initiates outgoing
	communication, temporary addresses can be given preference over		communication, temporary addresses can be given preference over
	public addresses, when the device is configured to do so. This is		public addresses, when the device is configured to do so.
	consistent with on-going work that addresses the topic of		[ADDR_SELECT] mandates implementations to provide a mechanism, which
	source-address selection in the more general case [ADDR_SELECT] and		allows an application to configure its preference for temporary
	also means that all connections initiated by the node can use		addresses over public addresses. It also allows for an
	temporary addresses without requiring application-specific		implementation to prefer temporary addresses by default, so that the
	enablement. This document also assumes that an API will exist that		connections initiated by the node can use temporary addresses without
	allows individual applications to indicate whether they prefer to use		requiring application-specific enablement. This document also
	temporary or public addresses and override the system defaults.		assumes that an API will exist that allows individual applications to
			indicate whether they prefer to use temporary or public addresses and
			override the system defaults.
	3.2 Generation Of Randomized Interface Identifiers		3.2 Generation Of Randomized Interface Identifiers
	We describe two approaches for the generation and maintenance of the		We describe two approaches for the generation and maintenance of the
	randomized interface identifier. The first assumes the presence of		randomized interface identifier. The first assumes the presence of
	stable storage that can be used to record state history for use as		stable storage that can be used to record state history for use as
	input into the next iteration of the algorithm across system		input into the next iteration of the algorithm across system
	restarts. A second approach addresses the case where stable storage		restarts. A second approach addresses the case where stable storage
	is unavailable and there is a need to generate randomized interface		is unavailable and there is a need to generate randomized interface
	identifiers without previous state.		identifiers without previous state.
			The random interface identifier generation algorithm, as described in
			this document, uses MD5 as the hash algorithm. The node MAY use
			another algorithm instead of MD5 to produce the random interface
			identifier.
	3.2.1 When Stable Storage Is Present		3.2.1 When Stable Storage Is Present
	The following algorithm assumes the presence of a 64-bit "history		The following algorithm assumes the presence of a 64-bit "history
	value" that is used as input in generating a randomized interface		value" that is used as input in generating a randomized interface
	identifier. The very first time the system boots (i.e., out-of-the-		identifier. The very first time the system boots (i.e., out-of-the-
	box), a random value SHOULD be generated using techniques that help		box), a random value SHOULD be generated using techniques that help
	ensure the initial value is hard to guess [RANDOM]. Whenever a new		ensure the initial value is hard to guess [RANDOM]. Whenever a new
	interface identifier is generated, a value generated by the		interface identifier is generated, a value generated by the
	computation is saved in the history value for the next iteration of		computation is saved in the history value for the next iteration of
	the algorithm.		the algorithm.
	skipping to change at page 13, line 12		skipping to change at page 14, line 12
	vary from one machine to another), append some random data and		vary from one machine to another), append some random data and
	compute the MD5 digest as before.		compute the MD5 digest as before.
	3.2.3 Alternate approaches		3.2.3 Alternate approaches
	Please note that there are other approaches to generate random		Please note that there are other approaches to generate random
	interface identifiers, albeit with different goals and applicability.		interface identifiers, albeit with different goals and applicability.
	One such approach is CGA [CGA], which generates a random interface		One such approach is CGA [CGA], which generates a random interface
	identifier based on the public key of the node. The goal of CGAs is		identifier based on the public key of the node. The goal of CGAs is
	to prove ownership of an address and to prevent spoofing and stealing		to prove ownership of an address and to prevent spoofing and stealing
	of existing IPv6 addresses. The CGA random interface identifier		of existing IPv6 addresses. They are used for securing neighbor
			discovery using [SEND]. The CGA random interface identifier
	generation algorithm may not be suitable for privacy addresses		generation algorithm may not be suitable for privacy addresses
	because of the following properties		because of the following properties
	o It requires the node to have a public key. This means that the		o It requires the node to have a public key. This means that the
	node can still be identified by its public key		node can still be identified by its public key
	o The random interface identifier process is computationally		o The random interface identifier process is computationally
	intensive and hence discourages frequent regeneration		intensive and hence discourages frequent regeneration
	3.3 Generating Temporary Addresses		3.3 Generating Temporary Addresses
	[ADDRCONF] describes the steps for generating a link-local address		[ADDRCONF] 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 [ADDRCONF] as		addresses for other scopes. This document extends [ADDRCONF] 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 [ADDRCONF],		1. Process the Prefix Information Option as defined in [ADDRCONF],
	either creating a new public address or adjusting the lifetimes		either creating a new public address or adjusting the lifetimes
	of existing addresses, both public and temporary. When adjusting		of existing addresses, both public and temporary. If a received
	the lifetime of an existing temporary address, there are two		option will extend the lifetime of a public address, the
	cases to consider:		lifetimes of temporary addresses should be extended, subject to
	A. In some cases, the lifetimes in a received option will be		the overall constraint that no temporary addresses should ever
	shorter than the lifetimes of an existing temporary addresses		remain "valid" or "preferred" for a time longer than
	derived from the prefix given in the option. This		(TEMP_VALID_LIFETIME-DESYNC_FACTOR) or
	corresponds to the case where the lifetimes have been
	reconfigured by a system administrator to have a shorter
	lifetime. Perform the following procedure to determine how
	to update the lifetime of the temporary address:
	B.
	+ If the received Valid Lifetime is greater than 2 hours
	update the lifetime of the temporary address to the
	received lifetime.
	+ If the RemainingLifetime of the temporary address is less
	than or equal to 2 hours ignore the received option.
	+ Otherwise set the valid lifetime to 2 hours.
	C. These steps are necessary to prevent a denial of service
	attack where a bogus advertisement contains prefixes with
	very small Valid Lifetimes
	D. In many cases, the lifetime of a received option will extend
	the lifetime of a public address. For example, a site might
	advertise short lifetimes (on the order of hours or minutes)
	that are effectively extended with each new RA. In such
	cases, the lifetimes of temporary addresses should be
	extended, subject to the overall constraint that no temporary
	addresses should ever remain "valid" or "preferred" for a
	time longer than (TEMP_VALID_LIFETIME-DESYNC_FACTOR) or
	(TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively. The		(TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively. The
	configuration variables TEMP_VALID_LIFETIME and		configuration variables TEMP_VALID_LIFETIME and
	TEMP_PREFERRED_LIFETIME correspond to approximate target		TEMP_PREFERRED_LIFETIME correspond to approximate target
	lifetimes for temporary addresses.		lifetimes for temporary addresses.
	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.
	2. When a new public address is created as described in [ADDRCONF]
			3. When a new public address is created as described in [ADDRCONF]
	(because the prefix advertised does not match the prefix of any		(because the prefix advertised does not match the prefix of any
	address already assigned to the interface, and the Valid Lifetime		address already assigned to the interface, and the Valid Lifetime
	in the option is not zero), the node SHOULD also create a new		in the option is not zero), the node SHOULD also create a new
	temporary address.		temporary address.
	3. 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 public address 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
	public address or TEMP_VALID_LIFETIME		public address or TEMP_VALID_LIFETIME
	* Its Preferred Lifetime is the lower of the Preferred Lifetime		* Its Preferred Lifetime is the lower of the Preferred Lifetime
	of the public address or		of the prefix or TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR.
	TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR.		5. A temporary address is created only if this calculated Preferred
	4. 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.
	5. New temporary addresses MUST be created by appending the		6. New temporary addresses MUST be created by appending the
	interface's current randomized interface identifier to the prefix		interface's current randomized interface identifier to the prefix
	that was used to generate the corresponding public address.		that was received.
	6. 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 as described in Section 3.2 above, and repeat the		identifier as described in Section 3.2 above, and repeat the
	previous steps as appropriate up to 5 times. If after 5		previous steps as appropriate up to TEMP_IDGEN_RETRIES times. If
	consecutive attempts no non-unique address was generated, the		after TEMP_IDGEN_RETRIES consecutive attempts no non-unique
	node MUST log a system error and MUST NOT attempt to generate		address was generated, the node MUST log a system error and MUST
	temporary addresses for that interface. Note that DAD MUST be		NOT attempt to generate temporary addresses for that interface.
	performed on every unicast address generated from this randomized		Note that DAD MUST be performed on every unicast address
	interface identifier.		generated from this randomized interface identifier.
	3.4 Expiration of Temporary Addresses		3.4 Expiration of Temporary Addresses
	When a temporary address becomes deprecated, a new one MUST be		When a temporary address becomes deprecated, a new one MUST be
	generated. This is done by repeating the actions described in		generated. This is done by repeating the actions described in
	Section 3.3, starting at step 3). Note that, except for the		Section 3.3, starting at step 3). Note that, except for the
	transient period when a temporary address is being regenerated, in		transient period when a temporary address is being regenerated, in
	normal operation at most one temporary address corresponding to a		normal operation at most one temporary address per prefix should be
	public address should be in a non-deprecated state at any given time.		in a non-deprecated state at any given time on a given interface.
	Note that if a temporary address becomes deprecated as result of		Note that if a temporary address becomes deprecated as result of
	processing a Prefix Information Option with a zero Preferred		processing a Prefix Information Option with a zero Preferred
	Lifetime, then a new temporary address MUST NOT be generated. The		Lifetime, then a new temporary address MUST NOT be generated.To
	Prefix Information Option will also deprecate the corresponding		ensure that a preferred temporary address is always available, a new
	public address. To insure that a preferred temporary address is		temporary address SHOULD be regenerated slightly before its
	always available, a new temporary address SHOULD be regenerated		predecessor is deprecated. This is to allow sufficient time to avoid
	slightly before its predecessor is deprecated. This is to allow		race conditions in the case where generating a new temporary address
	sufficient time to avoid race conditions in the case where generating		is not instantaneous, such as when duplicate address detection must
	a new temporary address is not instantaneous, such as when duplicate		be run. The node SHOULD start the address regeneration process
	address detection must be run. The node SHOULD start the address		REGEN_ADVANCE time units before a temporary address would actually be
	regeneration process REGEN_ADVANCE time units before a temporary		deprecated.
	address would actually be deprecated.
	As an optional optimization, an implementation MAY remove a		As an optional optimization, an implementation MAY remove a
	deprecated temporary address that is not in use by applications or		deprecated temporary address that is not in use by applications or
	upper-layers. For TCP connections, such information is available in		upper-layers as detailed in Section 6
	control blocks. For UDP-based applications, it may be the case that
	only the applications have knowledge about what addresses are
	actually in use. Consequently, one may need to use heuristics in
	deciding when an address is no longer in use (e.g., the default
	TEMP_VALID_LIFETIME suggested above).
	3.5 Regeneration of Randomized Interface Identifiers		3.5 Regeneration of Randomized Interface Identifiers
	The frequency at which temporary addresses changes depends on how a		The frequency at which temporary addresses changes depends on how a
	device is being used (e.g., how frequently it initiates new		device is being used (e.g., how frequently it initiates new
	communication) and the concerns of the end user. The most egregious		communication) and the concerns of the end user. The most egregious
	privacy concerns appear to involve addresses used for long periods of		privacy concerns appear to involve addresses used for long periods of
	time (weeks to months to years). The more frequently an address		time (weeks to months to years). The more frequently an address
	changes, the less feasible collecting or coordinating information		changes, the less feasible collecting or coordinating information
	keyed on interface identifiers becomes. Moreover, the cost of		keyed on interface identifiers becomes. Moreover, the cost of
	skipping to change at page 16, line 29		skipping to change at page 17, line 9
	same time. When the preferred lifetime expires, a new temporary		same time. When the preferred lifetime expires, a new temporary
	address MUST be generated using the new randomized interface		address MUST be generated using the new randomized interface
	identifier.		identifier.
	Because the precise frequency at which it is appropriate to generate		Because the precise frequency at which it is appropriate to generate
	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 default value given of		applications are used by end users. Thus, the suggested default
	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 randomized		Finally, when an interface connects to a new link, a new randomized
	interface identifier SHOULD be generated immediately together with a		interface identifier SHOULD be generated immediately together with a
	new set of temporary addresses. If a device moves from one ethernet		new set of temporary addresses. If a device moves from one ethernet
	to another, generating a new set of temporary addresses from a		to another, generating a new set of temporary addresses from a
	different randomized interface identifier ensures that the device		different randomized interface identifier ensures that the device
	uses different randomized interface identifiers for the temporary		uses different randomized interface identifiers for the temporary
	addresses associated with the two links, making it more difficult to		addresses associated with the two links, making it more difficult to
	correlate addresses from the two different links as being from the		correlate addresses from the two different links as being from the
	same node. The process by which a node can determine whether a link		same node. The node MAY follow any process available to it, to
	change has occurred is described by Detecting Network Attachment		determine that the link change has occurred. One such process is
	[DNA]		described by Detecting Network Attachment [DNA]
	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 simply 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.
			Additionally, sites might wish to selectively enable or disable the
			use of temporary addresses for some prefixes. For example, a site
			might wish to disable temporary address generation for "Unique local"
			[ULA] prefixes while still generating temporary addresses for all
			other global prefixes. Another site might wish to enable temporary
			address generation only for the prefixes 2001::/16 and 2002::/16
			while disabling it for all other prefixes. To support this behavior,
			implementations SHOULD provide a way to enable and disable generation
			of temporary addresses for specific prefix subranges. This
			per-prefix setting SHOULD override the global settings on the node
			with respect to the specified prefix subranges.
	The use of temporary addresses may cause unexpected difficulties with		The use of temporary addresses may cause unexpected difficulties with
	some applications. As described below, some servers refuse to accept		some applications. As described below, some servers refuse to accept
	communications from clients for which they cannot map the IP address		communications from clients for which they cannot map the IP address
	into an DNS name. In addition, some applications may not behave		into an DNS name. In addition, some applications may not behave
	robustly if temporary addresses are used and an address expires		robustly if temporary addresses are used and an address expires
	before the application has terminated, or if it opens multiple		before the application has terminated, or if it opens multiple
	sessions, but expects them to all use the same addresses.		sessions, but expects them to all use the same addresses.
	Consequently, the use of temporary addresses SHOULD be disabled by		Consequently, the use of temporary addresses SHOULD be disabled by
	default in order to minimize potential disruptions. Individual		default in order to minimize potential disruptions. Individual
	applications, which have specific knowledge about the normal duration		applications, which have specific knowledge about the normal duration
	skipping to change at page 18, line 40		skipping to change at page 19, line 40
	The wide deployment of the extension described in this document could		The wide deployment of the extension described in this document could
	challenge the practice of inverse-DNS-based "authentication," which		challenge the practice of inverse-DNS-based "authentication," which
	has little validity, though it is widely implemented. In order to		has little validity, though it is widely implemented. In order to
	meet server challenges, nodes could register temporary addresses in		meet server challenges, nodes could register temporary addresses in
	the DNS using random names (for example a string version of the		the DNS using random names (for example a string version of the
	random address itself).		random address itself).
	Use of the extensions defined in this document may complicate		Use of the extensions defined in this document may complicate
	debugging and other operational troubleshooting activities.		debugging and other operational troubleshooting activities.
	Consequently, it may be site policy that temporary addresses should		Consequently, it may be site policy that temporary addresses should
	not be used. Consequently, implementations must provide a method for		not be used. Consequently, implementations MUST provide a method for
	the end user or trusted administrator to override the use of		the end user or trusted administrator to override the use of
	temporary addresses.		temporary addresses.
	5. Defined Constants		5. Defined Constants
	Constants defined in this document include:		Constants defined in this document include:
	TEMP_VALID_LIFETIME -- Default value: 1 week. Users should be able		TEMP_VALID_LIFETIME -- Default value: 1 week. Users should be able
	to override the default value.		to override the default value.
	skipping to change at page 20, line 5		skipping to change at page 20, line 24
	REGEN_ADVANCE -- 5 seconds		REGEN_ADVANCE -- 5 seconds
	MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR.		MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR.
	DESYNC_FACTOR -- A random value within the range 0 -		DESYNC_FACTOR -- A random value within the range 0 -
	MAX_DESYNC_FACTOR. It is computed once at system start (rather than		MAX_DESYNC_FACTOR. It is computed once at system start (rather than
	each time it is used) and must never be greater than		each time it is used) and must never be greater than
	(TEMP_VALID_LIFETIME - REGEN_ADVANCE).		(TEMP_VALID_LIFETIME - REGEN_ADVANCE).
			TEMP_IDGEN_RETRIES -- Default value: 3
	6. Future Work		6. Future Work
	An implementation might want to keep track of which addresses are		An implementation might want to keep track of which addresses are
	being used by upper layers so as to be able to remove a deprecated		being used by upper layers so as to be able to remove a deprecated
	temporary address from internal data structures once no upper layer		temporary address from internal data structures once no upper layer
	protocols are using it (but not before). This is in contrast to		protocols are using it (but not before). This is in contrast to
	current approaches where addresses are removed from an interface when		current approaches where addresses are removed from an interface when
	they become invalid [ADDRCONF], independent of whether or not upper		they become invalid [ADDRCONF], independent of whether or not upper
	layer protocols are still using them. For TCP connections, such		layer protocols are still using them. For TCP connections, such
	information is available in control blocks. For UDP-based		information is available in control blocks. For UDP-based
	applications, it may be the case that only the applications have		applications, it may be the case that only the applications have
	knowledge about what addresses are actually in use. Consequently, an		knowledge about what addresses are actually in use. Consequently, an
	implementation generally will need to use heuristics in deciding when		implementation generally will need to use heuristics in deciding when
	an address is no longer in use (e.g., as is suggested in Section		an address is no longer in use.
	3.4).
	The determination as to whether to use public vs. temporary		The determination as to whether to use public vs. temporary
	addresses can in some cases only be made by an application. For		addresses can in some cases only be made by an application. For
	example, some applications may always want to use temporary		example, some applications may always want to use temporary
	addresses, while others may want to use them only in some		addresses, while others may want to use them only in some
	circumstances or not at all. Suitable API extensions will likely		circumstances or not at all. Suitable API extensions will likely
	need to be developed to enable individual applications to indicate		need to be developed to enable individual applications to indicate
	with sufficient granularity their needs with regards to the use of		with sufficient granularity their needs with regards to the use of
	temporary addresses. Recommendations on DNS practices to avoid the		temporary addresses. Recommendations on DNS practices to avoid the
	problem described in Section 4 when reverse DNS lookups fail may be		problem described in Section 4 when reverse DNS lookups fail may be
	needed.		needed. [DNSOP] contains a more detailed discussion of the DNS
			related issues.
	While this document discusses ways of obscuring a user's permanent IP		While this document discusses ways of obscuring a user's permanent IP
	address, the method described is believed to be ineffective against		address, the method described is believed to be ineffective against
	sophisticated forms of traffic analysis. To increase effectiveness,		sophisticated forms of traffic analysis. To increase effectiveness,
	one may need to consider use of more advanced techniques, such as		one may need to consider use of more advanced techniques, such as
	Onion Routing [ONION].		Onion Routing [ONION].
	Open Issues		Open Issues
	1) Implementations should allow system administrators to configure		1) Implementations should allow system administrators to configure
	skipping to change at page 22, line 5		skipping to change at page 23, line 5
	addresses as described in this document		addresses as described in this document
	7. Removed references to site-local addresses		7. Removed references to site-local addresses
	8. Added a check for denial of service attacks using low valid		8. Added a check for denial of service attacks using low valid
	lifetimes in router advertisements		lifetimes in router advertisements
	9. Changed the document to use RFC2119 language		9. Changed the document to use RFC2119 language
	10. The node is now allowed to generate different interface		10. The node is now allowed to generate different interface
	identifiers for different prefixes, if it so desires.		identifiers for different prefixes, if it so desires.
	11. DAD is now performed on all unicast addresses created from the		11. DAD is now performed on all unicast addresses created from the
	same interface identifier instead of just the first one		same interface identifier instead of just the first one
	8. Security Considerations		8. Changes from version 00
	Ingress filtering is being deployed as a means of preventing the use		This section summarizes the changes from version 00 of this draft
	of spoofed source addresses in Distributed Denial of Service(DDoS)		1. The algorithm used for generating random interface identifiers is
	attacks. In a network with a large number of nodes, new temporary		no longer restricted to just MD5
	addresses are created at a fairly high rate. This might make it		2. Added a problem statement
	difficult for ingress filtering mechanisms to distinguish between		3. Classified the references into normative and informative
	legitimately changing temporary addresses and spoofed source		4. Reduced default number of retries to 3 from 5 and added a
	addresses which "in-prefix"(They use a topologically correct prefix		configuration variable
	and non-existent interface ID). This can be addressed by using		5. Removed text about RA processing which is duplicated from
	access control mechanisms on a per address basis on the network		[ADDRCONF]
	egress point.		6. Added text about the privacy implications of a non-changing
			prefix
			7. Added a per-prefix enable/disable setting
			8. Added text about the means of correlation
			9. Clarified text about DHCPv6
			10. Added reference to dnsop issues draft
	9. Acknowledgements		9. Security Considerations
			Ingress filtering has been and is being deployed as a means of
			preventing the use of spoofed source addresses in Distributed Denial
			of Service(DDoS) attacks. In a network with a large number of nodes,
			new temporary addresses are created at a fairly high rate. This
			might make it difficult for ingress filtering mechanisms to
			distinguish between legitimately changing temporary addresses and
			spoofed source addresses, which are "in-prefix"(They use a
			topologically correct prefix and non-existent interface ID). This
			can be addressed by using access control mechanisms on a per address
			basis on the network egress point.
			10. Acknowledgements
	The authors would like to acknowledge the contributions of the ipv6		The authors would like to acknowledge the contributions of the ipv6
	working group and, in particular, Ran Atkinson, Matt Crawford, Steve		working group and, in particular, Ran Atkinson, Matt Crawford, Steve
	Deering, Allison Mankin, Peter Bieringer, Jari Arkko, Pekka Nikander,		Deering, Allison Mankin, Peter Bieringer, Jari Arkko, Pekka Nikander,
	Pekka Savola, and Francis Dupont for their detailed comments.		Pekka Savola, and Francis Dupont for their detailed comments.
	10 References		11. References
			11.1 Normative References
	[ADDRARCH]		[ADDRARCH]
	Hinden, R. and S. Deering, "IP Version 6 Addressing		Hinden, R. and S. Deering, "Internet Protocol Version 6
	Architecture", RFC 2373, July 1998.		(IPv6) Addressing Architecture", RFC 3513, April 2003.
	[ADDRCONF]		[ADDRCONF]
	Thomson, S. and T. Narten, "IPv6 Stateless Address		Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless
	Autoconfiguration", RFC 2462, December 1998.		Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-06
			(work in progress), September 2004.
	[ADDR_SELECT]		[ADDR_SELECT]
	Draves, R., "Default Address Selection for Internet		Draves, R., "Default Address Selection for Internet
	Protocol version 6 (IPv6)", RFC 3484, February 2003.		Protocol version 6 (IPv6)", RFC 3484, February 2003.
			[DISCOVERY]
			Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
			"Neighbor Discovery for IP version 6 (IPv6)",
			draft-ietf-ipv6-2461bis-00 (work in progress), July 2004.
			[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the
			Internet Protocol", RFC 2401, November 1998.
			[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
			April 1992.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", RFC 2119, March 1997.
			[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
			Addresses", RFC 2526, March 1999.
			11.2 Informative References
	[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",		[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
	draft-ietf-send-cga-06 (work in progress), April 2004.		draft-ietf-send-cga-06 (work in progress), April 2004.
	[COOKIES] Kristol, D. and L. Montulli, "HTTP State Management		[COOKIES] Kristol, D. and L. Montulli, "HTTP State Management
	Mechanism", RFC 2965, October 2000.		Mechanism", RFC 2965, October 2000.
	[DDNS] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic		[DDNS] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
	Updates in the Domain Name System (DNS UPDATE)", RFC 2136,		Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
	April 1997.		April 1997.
	[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC		[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC
	2131, March 1997.		2131, March 1997.
	[DISCOVERY]		[DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
	Narten, T., Nordmark, E. and W. Simpson, "Neighbor		M. Carney, "Dynamic Host Configuration Protocol for IPv6
	Discovery for IP Version 6 (IPv6)", RFC 2461, December		(DHCPv6)", RFC 3315, July 2003.
	1998.
	[DNA] Choi, J. and G. Daley, "Detecting Network Attachment in		[DNA] Choi, J. and G. Daley, "Detecting Network Attachment in
	IPv6 Goals", draft-ietf-dna-goals-01 (work in progress),		IPv6 Goals", draft-ietf-dna-goals-01 (work in progress),
	September 2004.		September 2004.
	[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the		[DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational
	Internet Protocol", RFC 2401, November 1998.		Considerations and Issues with IPv6 DNS",
			draft-ietf-dnsop-ipv6-dns-issues-09 (work in progress),
			August 2004.
	[ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler,		[ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler,
	"Intra-Site Automatic Tunnel Addressing Protocol		"Intra-Site Automatic Tunnel Addressing Protocol
	(ISATAP)", draft-ietf-ngtrans-isatap-22 (work in		(ISATAP)", draft-ietf-ngtrans-isatap-22 (work in
	progress), May 2004.		progress), May 2004.
	[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	April 1992.
	[MOBILEIP]
	Perkins, C., "IP Mobility Support", RFC 2002, October
	1996.
	[ONION] Reed, MGR., Syverson, PFS. and DMG. Goldschlag, "Proxies		[ONION] Reed, MGR., Syverson, PFS. and DMG. Goldschlag, "Proxies
	for Anonymous Routing", Proceedings of the 12th Annual		for Anonymous Routing", Proceedings of the 12th Annual
	Computer Security Applications Conference, San Diego, CA,		Computer Security Applications Conference, San Diego, CA,
	December 1996.		December 1996.
	[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness		[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
	Recommendations for Security", RFC 1750, December 1994.		Recommendations for Security", RFC 1750, December 1994.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
	Requirement Levels", RFC 2119, March 1997.		Nikander, "SEcure Neighbor Discovery (SEND)",
			draft-ietf-send-ndopt-06 (work in progress), July 2004.
	[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
	Addresses", RFC 2526, March 1999.
	[ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast		[ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in		Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in
	progress), June 2004.		progress), June 2004.
	Authors' Addresses		Authors' Addresses
	Thomas Narten		Thomas Narten
	IBM Corporation		IBM Corporation
	P.O. Box 12195		P.O. Box 12195
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/