draft-ietf-ipv6-privacy-addrs-v2-02.txt		draft-ietf-ipv6-privacy-addrs-v2-03.txt
	IPv6 Working Group T. Narten		IPv6 Working Group T. Narten
	Internet-Draft IBM Corporation		Internet-Draft IBM Corporation
	Expires: June 23, 2005 R. Draves		Expires: October 6, 2005 R. Draves
	Microsoft Research		Microsoft Research
	S. Krishnan		S. Krishnan
	Ericsson		Ericsson
	December 23, 2004		April 4, 2005
	Privacy Extensions for Stateless Address Autoconfiguration in IPv6		Privacy Extensions for Stateless Address Autoconfiguration in IPv6
	draft-ietf-ipv6-privacy-addrs-v2-02		draft-ietf-ipv6-privacy-addrs-v2-03
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of Section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		author represents that any applicable patent or other IPR claims of
			which he or she is aware have been or will be disclosed, and any of
			which he or she 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
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	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."
	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 June 23, 2005.		This Internet-Draft will expire on October 6, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005).
	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. On interfaces that		network prefixes with an interface identifier. On interfaces that
	contain embedded IEEE Identifiers, the interface identifier is		contain embedded IEEE Identifiers, the interface identifier is
	typically derived from it. On other interface types, the interface		typically derived from it. On other interface types, the interface
	identifier is generated through other means, for example, via random		identifier is generated through other means, for example, via random
	skipping to change at page 2, line 18		skipping to change at page 2, line 21
	causes nodes to generate global scope addresses from interface		causes nodes to generate global scope addresses from interface
	identifiers that change over time, even in cases where the interface		identifiers that change over time, even in cases where the interface
	contains an embedded IEEE identifier. Changing the interface		contains an embedded IEEE identifier. Changing the interface
	identifier (and the global scope addresses generated from it) over		identifier (and the global scope addresses generated from it) over
	time makes it more difficult for eavesdroppers and other information		time makes it more difficult for eavesdroppers and other information
	collectors to identify when different addresses used in different		collectors to identify when different addresses used in different
	transactions actually correspond to the same node.		transactions actually correspond to the same node.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 4		1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 5
	1.2 Conventions used in this document . . . . . . . . . . . . 4		1.2 Conventions used in this document . . . . . . . . . . . . 5
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1 Extended Use of the Same Identifier . . . . . . . . . . . 5		2.1 Extended Use of the Same Identifier . . . . . . . . . . . 6
	2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 6		2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 7
	2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 7		2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 8
	2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 8		2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 9
	3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10		3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 11
	3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 10		3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11
	3.2 Generation Of Randomized Interface Identifiers . . . . . . 12		3.2 Generation Of Randomized Interface Identifiers . . . . . . 13
	3.2.1 When Stable Storage Is Present . . . . . . . . . . . . 12		3.2.1 When Stable Storage Is Present . . . . . . . . . . . . 13
	3.2.2 In The Absence of Stable Storage . . . . . . . . . . . 13		3.2.2 In The Absence of Stable Storage . . . . . . . . . . . 14
	3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 14		3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 15
	3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 14		3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 15
	3.4 Expiration of Temporary Addresses . . . . . . . . . . . . 15		3.4 Expiration of Temporary Addresses . . . . . . . . . . . . 16
	3.5 Regeneration of Randomized Interface Identifiers . . . . . 16		3.5 Regeneration of Randomized Interface Identifiers . . . . . 17
	3.6 Deployment Considerations . . . . . . . . . . . . . . . . 17		3.6 Deployment Considerations . . . . . . . . . . . . . . . . 18
	4. Implications of Changing Interface Identifiers . . . . . . . . 19		4. Implications of Changing Interface Identifiers . . . . . . . . 20
	5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 20		5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 21
	6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21		6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 22
	7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 22		7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 23
	8. Changes from version 00 . . . . . . . . . . . . . . . . . . . 23		8. Changes from version 00 . . . . . . . . . . . . . . . . . . . 24
	9. Changes from version 01 . . . . . . . . . . . . . . . . . . . 24		9. Changes from version 01 . . . . . . . . . . . . . . . . . . . 25
	10. Security Considerations . . . . . . . . . . . . . . . . . . 25		10. Changes from version 02 . . . . . . . . . . . . . . . . . . 26
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26		11. Security Considerations . . . . . . . . . . . . . . . . . . 27
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
	12.1 Normative References . . . . . . . . . . . . . . . . . . . . 27		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
	12.2 Informative References . . . . . . . . . . . . . . . . . . . 27		13.1 Normative References . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28		13.2 Informative References . . . . . . . . . . . . . . . . . . 29
	Intellectual Property and Copyright Statements . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
			Intellectual Property and Copyright Statements . . . . . . . . 32
	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 DHCPv6 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
	skipping to change at page 3, line 30		skipping to change at page 4, line 30
	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 may not be		(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, because
	concern being addressed exists only in those cases where the		tracking of individual devices, the concern being addressed here, is
	interface identifier is globally unique and non-changing. The rest		possible only in those cases where the interface identifier is
	of this document assumes that IEEE identifiers are being used, but		globally unique and non-changing. The rest of this document assumes
	the techniques described may also apply to interfaces with other		that IEEE identifiers are being used, but the techniques described
	types of globally unique and/or persistent identifiers.		may also apply to interfaces with other 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
	describes extensions to stateless address autoconfiguration that can		describes extensions to stateless address autoconfiguration that can
	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 Problem Statement		1.1 Problem Statement
	Addresses generated using Stateless address autoconfiguration		Addresses generated using Stateless address autoconfiguration
	[ADDRCONF]contain an embedded 64-bit interface identifier, which		[ADDRCONF]contain an embedded interface identifier, which remains
	remains constant over time. Anytime a fixed identifier is used in		constant over time. Anytime a fixed identifier is used in multiple
	multiple contexts, it becomes possible to correlate seemingly		contexts, it becomes possible to correlate seemingly unrelated
	unrelated activity using this identifier.		activity using this identifier.
	The correlation can be performed by		The correlation can be performed by
	o An attacker who is in the path between the node in question and		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		the peer(s) it is communicating to, and can view the IPv6
	addresses present in the datagrams.		addresses present in the datagrams.
	o An attacker who can access the communication logs of the peers		o An attacker who can access the communication logs of the peers
	with which the node has communicated.		with which the node has communicated.
	Since the identifier is embedded within the IPv6 address, which is a		Since the identifier is embedded within the IPv6 address, which is a
	fundamental requirement of communication, it cannot be easily hidden.		fundamental requirement of communication, it cannot be easily hidden.
	skipping to change at page 5, line 19		skipping to change at page 6, line 19
	environments and makes comparisons with existing practices.		environments and makes comparisons with existing practices.
	2.1 Extended Use of the Same Identifier		2.1 Extended Use of the Same Identifier
	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
	from a particular host crosses could keep track of which destinations		to/from a particular host crosses could keep track of which
	a node communicated with and at what times. Such information can in		destinations a node communicated with and at what times. Such
	some cases be used to infer things, such as what hours an employee		information can in some cases be used to infer things, such as what
	was active, when someone is at home, etc. Although it might appear		hours an employee was active, when someone is at home, etc. Although
	that changing an address regularly in such environments would be		it might appear that changing an address regularly in such
	desirable to lessen privacy concerns, it should be noted that the		environments would be desirable to lessen privacy concerns, it should
	network prefix portion of an address also serves as a constant		be noted that the network prefix portion of an address also serves as
	identifier. All nodes at (say) a home, would have the same network		a constant identifier. All nodes at (say) a home, would have the
	prefix, which identifies the topological location of those nodes.		same network prefix, which identifies the topological location of
	This has implications for privacy, though not at the same granularity		those nodes. This has implications for privacy, though not at the
	as the concern that this document addresses. Specifically, all nodes		same granularity as the concern that this document addresses.
	within a home could be grouped together for the purposes of		Specifically, all nodes within a home could be grouped together for
	collecting information. If the network contains a very small number		the purposes of collecting information. If the network contains a
	of nodes, say just one, changing just the interface identifier will		very small number of nodes, say just one, changing just the interface
	not enhance privacy at all, since the prefix serves as a constant		identifier will not enhance privacy at all, since the prefix serves
	identifier.		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 8, line 18		skipping to change at page 9, line 18
	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 having a static non-changing address is to use		One way to avoid having a static non-changing address is to use
	DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be		DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be
	configured to hand out addresses that change over time. But DHCPv6		configured to hand out addresses that change over time. But DHCPv6
	will solve the privacy issue only if it frequently handed out		will solve the privacy issue only if it frequently handed out
	constantly changing addresses to the nodes. Since this does not		constantly changing addresses to the nodes or if the DHCPv6 client
	happen automatically, and is difficult to configure manually, DHCPv6		moves from links to links frequently, being allocated independent
	is not a self contained alternative for solving the privacy issues		addresses from different DHCPv6 servers. However, the former does
	addressed by this document. However, in the absence of stateless		not happen automatically, and is difficult to configure manually; the
	address autoconfiguration, DHCPv6 can be used for distributing		latter cannot be assumed for static (not frequently moving) hosts.
	temporary addresses to clients.		Thus, 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		autoconfiguration architecture, would be to change the interface
	identifier portion of an address over time and generate new addresses		identifier portion of an address over time and generate new addresses
	from the interface identifier for some address scopes. Changing the		from the interface identifier for some address scopes. Changing the
	interface identifier can make it more difficult to look at the IP		interface identifier can make it more difficult to look at the IP
	addresses in independent transactions and identify which ones		addresses in independent transactions and identify which ones
	actually correspond to the same node, both in the case where the		actually correspond to the same node, both in the case where the
	routing prefix portion of an address changes and when it does not.		routing prefix portion of an address changes and when it does not.
	skipping to change at page 25, line 5		skipping to change at page 26, line 5
	9. Changes from version 01		9. Changes from version 01
	This section summarizes the changes from version 01 of this draft		This section summarizes the changes from version 01 of this draft
	1. Clarifiying the length of interface identifier		1. Clarifiying the length of interface identifier
	2. Added a per-prefix enable/disable knob as a SHOULD to retain		2. Added a per-prefix enable/disable knob as a SHOULD to retain
	backward compatibility		backward compatibility
	3. Removed normative reference to ISATAP to avoid downref problem		3. Removed normative reference to ISATAP to avoid downref problem
	4. Added text for per-prefix knobs to be applied at any granularity		4. Added text for per-prefix knobs to be applied at any granularity
	5. Moved RFC2526 to informative reference		5. Moved RFC2526 to informative reference
	10. Security Considerations		10. Changes from version 02
			This section summarizes the changes from version 02 of this draft
			1. Explained briefly the concern that is being addressed in the
			introduction
			2. Removed reference to 64 bit identifiers in the ADDRCONF context
			3. Added clarifying text for the usage of DHCPv6 as an alternate
			approach
			4. Moved RFC3484 to informative reference
			5. Updated references for SEND, and CGA as they became RFCs
			6. Updated draft versions for ULA, DNSOP issues, 2461bis, 2462bis
			and DNA goals
			11. Security Considerations
	Ingress filtering has been and is being deployed as a means of		Ingress filtering has been and is being deployed as a means of
	preventing the use of spoofed source addresses in Distributed Denial		preventing the use of spoofed source addresses in Distributed Denial
	of Service(DDoS) attacks. In a network with a large number of nodes,		of Service(DDoS) attacks. In a network with a large number of nodes,
	new temporary addresses are created at a fairly high rate. This		new temporary addresses are created at a fairly high rate. This
	might make it difficult for ingress filtering mechanisms to		might make it difficult for ingress filtering mechanisms to
	distinguish between legitimately changing temporary addresses and		distinguish between legitimately changing temporary addresses and
	spoofed source addresses, which are "in-prefix"(They use a		spoofed source addresses, which are "in-prefix"(They use a
	topologically correct prefix and non-existent interface ID). This		topologically correct prefix and non-existent interface ID). This
	can be addressed by using access control mechanisms on a per address		can be addressed by using access control mechanisms on a per address
	basis on the network egress point.		basis on the network egress point.
	11. Acknowledgements		12. 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, Francis Dupont, Brian Haberman, and Tatuya Jinmei for		Pekka Savola, Francis Dupont, Brian Haberman, and Tatuya Jinmei for
	their detailed comments.		their detailed comments.
	12. References		13. References
	12.1 Normative References		13.1 Normative References
	[ADDRARCH]		[ADDRARCH]
	Hinden, R. and S. Deering, "Internet Protocol Version 6		Hinden, R. and S. Deering, "Internet Protocol Version 6
	(IPv6) Addressing Architecture", RFC 3513, April 2003.		(IPv6) Addressing Architecture", RFC 3513, April 2003.
	[ADDRCONF]		[ADDRCONF]
	Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless		Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-06		Address Autoconfiguration",
	(work in progress), September 2004.		Internet-Draft draft-ietf-ipv6-rfc2462bis-07, December
			2004.
	[ADDR_SELECT]
	Draves, R., "Default Address Selection for Internet
	Protocol version 6 (IPv6)", RFC 3484, February 2003.
	[DISCOVERY]		[DISCOVERY]
	Narten, T., Nordmark, E., Simpson, W. and H. Soliman,		Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)",		"Neighbor Discovery for IP version 6 (IPv6)",
	draft-ietf-ipv6-2461bis-00 (work in progress), July 2004.		Internet-Draft draft-ietf-ipv6-2461bis-02, February 2005.
	[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the		[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the
	Internet Protocol", RFC 2401, November 1998.		Internet Protocol", RFC 2401, November 1998.
	[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,		[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	April 1992.		April 1992.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	12.2 Informative References		13.2 Informative References
			[ADDR_SELECT]
			Draves, R., "Default Address Selection for Internet
			Protocol version 6 (IPv6)", RFC 3484, February 2003.
	[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",		[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
	draft-ietf-send-cga-06 (work in progress), April 2004.		RFC 3972, March 2005.
	[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",
	2131, March 1997.		RFC 2131, March 1997.
	[DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and		[DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
	M. Carney, "Dynamic Host Configuration Protocol for IPv6		M. Carney, "Dynamic Host Configuration Protocol for IPv6
	(DHCPv6)", RFC 3315, July 2003.		(DHCPv6)", RFC 3315, July 2003.
	[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", Internet-Draft draft-ietf-dna-goals-04,
	September 2004.		December 2004.
	[DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational		[DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational
	Considerations and Issues with IPv6 DNS",		Considerations and Issues with IPv6 DNS",
	draft-ietf-dnsop-ipv6-dns-issues-09 (work in progress),		Internet-Draft draft-ietf-dnsop-ipv6-dns-issues-10,
	August 2004.		October 2004.
	[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.
	[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast		[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
	Addresses", RFC 2526, March 1999.		Addresses", RFC 2526, March 1999.
	[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.		[SEND] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure
	Nikander, "SEcure Neighbor Discovery (SEND)",		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	draft-ietf-send-ndopt-06 (work in progress), July 2004.
	[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",
	progress), June 2004.		Internet-Draft draft-ietf-ipv6-unique-local-addr-09,
			January 2005.
	Authors' Addresses		Authors' Addresses
	Thomas Narten		Thomas Narten
	IBM Corporation		IBM Corporation
	P.O. Box 12195		P.O. Box 12195
	Research Triangle Park, NC		Research Triangle Park, NC
	USA		USA
	EMail: narten@raleigh.ibm.com		Email: narten@raleigh.ibm.com
	Richard Draves		Richard Draves
	Microsoft Research		Microsoft Research
	One Microsoft Way		One Microsoft Way
	Redmond, WA		Redmond, WA
	USA		USA
	EMail: richdr@microsoft.com		Email: richdr@microsoft.com
	Suresh Krishnan		Suresh Krishnan
	Ericsson		Ericsson
	8400 Decarie Blvd.		8400 Decarie Blvd.
	Town of Mount Royal, QC		Town of Mount Royal, QC
	Canada		Canada
	EMail: suresh.krishnan@ericsson.com		Email: suresh.krishnan@ericsson.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	skipping to change at page 30, line 41		skipping to change at page 32, line 41
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/