draft-ietf-dhc-anonymity-profile-03.txt		draft-ietf-dhc-anonymity-profile-04.txt
	Network Working Group C. Huitema		Network Working Group C. Huitema
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track T. Mrugalski		Intended status: Standards Track T. Mrugalski
	Expires: March 4, 2016 ISC		Expires: April 4, 2016 ISC
	S. Krishnan		S. Krishnan
	Ericsson		Ericsson
	September 1, 2015		October 2, 2015
	Anonymity profile for DHCP clients		Anonymity profile for DHCP clients
	draft-ietf-dhc-anonymity-profile-03.txt		draft-ietf-dhc-anonymity-profile-04.txt
	Abstract		Abstract
	Some DHCP options carry unique identifiers. These identifiers can		Some DHCP options carry unique identifiers. These identifiers can
	enable device tracking even if the device administrator takes care of		enable device tracking even if the device administrator takes care of
	randomizing other potential identifications like link-layer addresses		randomizing other potential identifications like link-layer addresses
	or IPv6 addresses. The anonymity profile is designed for clients		or IPv6 addresses. The anonymity profile is designed for clients
	that wish to remain anonymous to the visited network. The profile		that wish to remain anonymous to the visited network. The profile
	provides guidelines on the composition of DHCP or DHCPv6 requests,		provides guidelines on the composition of DHCP or DHCPv6 requests,
	designed to minimize disclosure of identifying information. This		designed to minimize disclosure of identifying information. This
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 4, 2016.		This Internet-Draft will expire on April 4, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
	2. Application domain . . . . . . . . . . . . . . . . . . . . . 3		2. Application domain . . . . . . . . . . . . . . . . . . . . . 3
	2.1. MAC address Randomization hypotheses . . . . . . . . . . 4		2.1. MAC address Randomization hypotheses . . . . . . . . . . 4
	2.2. MAC address Randomization and DHCP . . . . . . . . . . . 5		2.2. MAC address Randomization and DHCP . . . . . . . . . . . 5
	2.3. Radio fingerprinting . . . . . . . . . . . . . . . . . . 5		2.3. Radio fingerprinting . . . . . . . . . . . . . . . . . . 5
	2.4. Operating system fingerprinting . . . . . . . . . . . . . 6		2.4. Operating system fingerprinting . . . . . . . . . . . . . 6
	2.5. No anonymity profile identification . . . . . . . . . . . 6		2.5. No anonymity profile identification . . . . . . . . . . . 6
	2.6. Using the anonymity profiles . . . . . . . . . . . . . . 7		2.6. Using the anonymity profiles . . . . . . . . . . . . . . 7
	2.7. What about privacy for DHCP servers . . . . . . . . . . . 8		2.7. What about privacy for DHCP servers . . . . . . . . . . . 8
	3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8		3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8
	3.1. Option encoding and avoiding fingerprinting . . . . . . . 9		3.1. Avoiding fingerprinting . . . . . . . . . . . . . . . . . 9
	3.2. Client IP address field . . . . . . . . . . . . . . . . . 9		3.2. Client IP address field . . . . . . . . . . . . . . . . . 9
	3.3. Requested IP address option . . . . . . . . . . . . . . . 10		3.3. Requested IP address option . . . . . . . . . . . . . . . 10
	3.4. Client hardware address . . . . . . . . . . . . . . . . . 10		3.4. Client hardware address field . . . . . . . . . . . . . . 10
	3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11		3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11
	3.6. Parameter Request List . . . . . . . . . . . . . . . . . 11		3.6. Parameter Request List Option . . . . . . . . . . . . . . 12
	3.7. Host Name Option . . . . . . . . . . . . . . . . . . . . 12		3.7. Host Name Option . . . . . . . . . . . . . . . . . . . . 12
	3.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 13		3.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 13
	3.9. UUID/GUID-based Client Identifier Option . . . . . . . . 13		3.9. UUID/GUID-based Client Identifier Option . . . . . . . . 13
	3.10. User and Vendor Class DHCP options . . . . . . . . . . . 14		3.10. User and Vendor Class DHCP options . . . . . . . . . . . 14
	4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 14		4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 14
	4.1. Option encoding and avoiding fingerprinting . . . . . . . 14		4.1. Option encoding and avoiding fingerprinting . . . . . . . 15
	4.2. Do not send Confirm messages, unless really sure where . 15		4.2. Do not send Confirm messages, unless really sure where . 15
	4.3. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 15		4.3. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 16
	4.3.1. Anonymous Information-Request . . . . . . . . . . . . 16		4.3.1. Anonymous Information-Request . . . . . . . . . . . . 16
	4.4. Server Identifier Option . . . . . . . . . . . . . . . . 16		4.4. Server Identifier Option . . . . . . . . . . . . . . . . 16
	4.5. Address assignment options . . . . . . . . . . . . . . . 16		4.5. Address assignment options . . . . . . . . . . . . . . . 17
	4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 17		4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 17
	4.6. Option Request Option . . . . . . . . . . . . . . . . . . 17		4.5.2. Prefix delegation . . . . . . . . . . . . . . . . . . 18
			4.6. Option Request Option . . . . . . . . . . . . . . . . . . 18
	4.6.1. Previous option values . . . . . . . . . . . . . . . 18		4.6.1. Previous option values . . . . . . . . . . . . . . . 18
	4.7. Authentication Option . . . . . . . . . . . . . . . . . . 18		4.7. Authentication Option . . . . . . . . . . . . . . . . . . 19
	4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 18		4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 19
	4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 18		4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 19
	5. Operational Considerations . . . . . . . . . . . . . . . . . 19		5. Operational Considerations . . . . . . . . . . . . . . . . . 19
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 19		6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	9. Changes from previous versions . . . . . . . . . . . . . . . 19		9. Changes from previous versions . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	10.1. Normative References . . . . . . . . . . . . . . . . . . 21		10.1. Normative References . . . . . . . . . . . . . . . . . . 22
	10.2. Informative References . . . . . . . . . . . . . . . . . 22		10.2. Informative References . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	Reports surfaced recently of systems that would monitor the wireless		Reports surfaced recently of systems that would monitor the wireless
	connections of passengers at Canadian airports [CNBC]. We can assume		connections of passengers at Canadian airports [CNBC]. We can assume
	that these are either fragments or trial runs of a wider system that		that these are either fragments or trial runs of a wider system that
	would attempt to monitor Internet users as they roam through wireless		would attempt to monitor Internet users as they roam through wireless
	access points and other temporary network attachments. We can also		access points and other temporary network attachments. We can also
	assume that privacy conscious users will attempt to evade this		assume that privacy conscious users will attempt to evade this
	monitoring, for example by ensuring that low level identifiers such		monitoring, for example by ensuring that low level identifiers such
	skipping to change at page 5, line 33		skipping to change at page 5, line 34
	the IP address remains constant, since it is tied to the DHCP		the IP address remains constant, since it is tied to the DHCP
	identifier. Conversely, if the DHCP identifier changes but the link-		identifier. Conversely, if the DHCP identifier changes but the link-
	layer address remains constant, the old and new identifiers and		layer address remains constant, the old and new identifiers and
	addresses can be correlated by listening to L2 traffic. The		addresses can be correlated by listening to L2 traffic. The
	procedures documented in the following sections construct DHCP		procedures documented in the following sections construct DHCP
	identifiers from the current link-layer address, automatically		identifiers from the current link-layer address, automatically
	providing for this synchronization.		providing for this synchronization.
	The proposed anonymity profiles solve this synchronization issues by		The proposed anonymity profiles solve this synchronization issues by
	deriving most identifiers from the link-layer address, and generally		deriving most identifiers from the link-layer address, and generally
	by making making sure that DHCP parameter values do not remain		by making sure that DHCP parameter values do not remain constant
	constant after an address change.		after an address change.
	2.3. Radio fingerprinting		2.3. Radio fingerprinting
	MAC address randomization solves the trivial monitoring problem in		MAC address randomization solves the trivial monitoring problem in
	which someone just uses a Wi-Fi scanner and records the MAC addresses		which someone just uses a Wi-Fi scanner and records the MAC addresses
	seen on the air. DHCP anonymity solves the more elaborated scenario		seen on the air. DHCP anonymity solves the more elaborated scenario
	in which someone monitor link-layer addresses and identities used in		in which someone monitor link-layer addresses and identities used in
	DHCP at the access point or DHCP server. But these are not the only		DHCP at the access point or DHCP server. But these are not the only
	ways to track a mobile device.		ways to track a mobile device.
	skipping to change at page 7, line 36		skipping to change at page 7, line 36
	care about privacy and servers do not object. We assume that the		care about privacy and servers do not object. We assume that the
	request for anonymity is materialized by the assignment of a		request for anonymity is materialized by the assignment of a
	randomized link-layer address to the network interface. Once that		randomized link-layer address to the network interface. Once that
	decision is made, the following guidelines will avoid leakage of		decision is made, the following guidelines will avoid leakage of
	identity in DHCP parameters or in assigned addresses.		identity in DHCP parameters or in assigned addresses.
	There may be rare situations where the clients want anonymity to		There may be rare situations where the clients want anonymity to
	attackers but not to their DHCP server. These clients should still		attackers but not to their DHCP server. These clients should still
	use link-layer address randomization to hide from observers, and some		use link-layer address randomization to hide from observers, and some
	form of encrypted communication to the DHCP server. This scenario is		form of encrypted communication to the DHCP server. This scenario is
	not yet supported in this document.		out of scope for this document.
	To preserve anonymity, the clients need to not use stable values for		To preserve anonymity, the clients need to not use stable values for
	the client identifiers. This is clearly a tradeoff, because a stable		the client identifiers. This is clearly a tradeoff, because a stable
	client identifier guarantees that the client will receive consistent		client identifier guarantees that the client will receive consistent
	parameters over time. An example is given in [RFC7618], where the		parameters over time. An example is given in [RFC7618], where the
	client identifier is used to guarantee that the same client will		client identifier is used to guarantee that the same client will
	always get the same combination of IP address and port range. Static		always get the same combination of IP address and port range. Static
	clients benefit most from stable parameters, and can often be already		clients benefit most from stable parameters, and can often be already
	identified by physical connection layer parameters. These static		identified by physical connection layer parameters. These static
	clients will normally not use the anonymity profile. Mobile clients,		clients will normally not use the anonymity profile. Mobile clients,
	skipping to change at page 8, line 33		skipping to change at page 8, line 33
	and [I-D.ietf-dhc-dhcpv6-privacy]. Mitigation of these issues is		and [I-D.ietf-dhc-dhcpv6-privacy]. Mitigation of these issues is
	left to further study.		left to further study.
	3. Anonymity profile for DHCPv4		3. Anonymity profile for DHCPv4
	Clients using the DHCPv4 anonymity profile limit the disclosure of		Clients using the DHCPv4 anonymity profile limit the disclosure of
	information by controlling the header parameters and by limiting the		information by controlling the header parameters and by limiting the
	number and values of options. The number of options depend on the		number and values of options. The number of options depend on the
	specific DHCP message:		specific DHCP message:
	DISCOVER: The anonymized DISCOVER messages MUST contain the Message		DHCPDISCOVER: The anonymized DHCPDISCOVER messages MUST contain the
	Type, Client Identifier, and Parameter Request List options. It		Message Type, MAY contain the Client Identifier, and MAY contain
	SHOULD NOT contain any other option.		the Parameter Request List options. It SHOULD NOT contain any
			other option.
	REQUEST: The anonymized REQUEST messages SHOULD contain the Message		DHCPREQUEST: The anonymized DHCPREQUEST messages MUST contain the
	Type, Client Identifier, Requested IP address and Parameter		Message Type, MAY contain the Client Identifier, and MAY contain
	Request List options. If the message is in response to an OFFER,		the Parameter Request List options. If the message is in response
	it SHOULD contain the corresponding Server Identifier option. It		to a DHCPOFFER, it MUST contain the corresponding Server
	SHOULD NOT contain any other option.		Identifier option and the Requested IP address. If the message is
			not in response to a DHCPOFFER, it MAY contain a Requested IP
			address as explained in Section 3.3. It SHOULD NOT contain any
			other option.
	DECLINE: The anonymized DECLINE messages SHOULD contain the Message		DHCPDECLINE: The anonymized DHCPDECLINE messages MUST contain the
	Type, Client Identifier and Server Identifier options.		Message Type, Server Identifier, and Requested IP address options,
			and MAY contain the Client Identifier options.
	RELEASE: The anonymized RELEASE messages SHOULD contain the Message		DHCPRELEASE: The anonymized DHCPRELEASE messages MUST contain the
	Type, Client Identifier and Server Identifier options.		Message Type and Server Identifier options, and MAY contain the
			Client Identifier option.
	INFORM: The anonymized INFORM messages MUST contain the Message		DHCPINFORM: The anonymized DHCPINFORM messages MUST contain the
	Type, Client Identifier, and Parameter Request List options. It		Message Type, and MAY contain the Client Identifier and Parameter
	SHOULD NOT contain any other option.		Request List options. It SHOULD NOT contain any other option.
	Header fields and option values SHOULD be set in accordance with the		Header fields and option values SHOULD be set in accordance with the
	DHCP specification, but some header fields and option values SHOULD		DHCP specification, but some header fields and option values SHOULD
	be constructed per the following guidelines.		be constructed per the following guidelines.
	The inclusion of HostName and FQDN options in DISCOVER, REQUEST or		The inclusion of HostName and FQDN options in DHCPDISCOVER,
	INFORM messages is discussed in Section 3.7 and Section 3.8.		DHCPREQUEST or DHCPINFORM messages is discussed in Section 3.7 and
			Section 3.8.
	3.1. Option encoding and avoiding fingerprinting		3.1. Avoiding fingerprinting
	There are many choices for implementing DHCPv4 messages. Clients can		There are many choices for implementing DHCPv4 messages. Clients can
	choose to transmit a specific set of options, pick particular		choose to transmit a specific set of options, pick particular
	encoding for these options, and transmit options in different orders.		encoding for these options, and transmit options in different orders.
	These choices can be use to fingerprint the client.		These choices can be use to fingerprint the client.
	The following sections provide guidance on the encoding of options.		The following sections provide guidance on the encoding of options
	However, this guidance alone may not be sufficient to prevent		and fields within the packets. However, this guidance alone may not
	fingerprinting from revealing information, such as the device type,		be sufficient to prevent fingerprinting from revealing information,
	vendor type or OS type and in some cases specific version, or from		such as the device type, vendor type or OS type and in some cases
	revealing whether the client is using the anonymity profile.		specific version, or from revealing whether the client is using the
			anonymity profile.
	The client willing to protect its privacy SHOULD limit the subset of		The client willing to protect its privacy SHOULD limit the subset of
	options sent in messages to the subset listed in the following		options sent in messages to the subset listed in the following
	sections.		sections.
	The client willing to protect its privacy SHOULD randomize options		The client willing to protect its privacy SHOULD randomize options
	order before sending any DHCPv4 message. If this random ordering		order before sending any DHCPv4 message. If this random ordering
	cannot be implemented, the client MAY arrange options by increasing		cannot be implemented, the client MAY arrange options by increasing
	order of option codes.		order of option codes.
	skipping to change at page 10, line 27		skipping to change at page 10, line 36
	regain the same IP address that was used in a previous connection.		regain the same IP address that was used in a previous connection.
	Doing so entails the risk of disclosing an IP address used by the		Doing so entails the risk of disclosing an IP address used by the
	client at a previous location, or with a different link-layer		client at a previous location, or with a different link-layer
	address.		address.
	When using the anonymity profile, clients SHOULD NOT use the		When using the anonymity profile, clients SHOULD NOT use the
	Requested IP address option in DHCPDISCOVER messages. They MUST use		Requested IP address option in DHCPDISCOVER messages. They MUST use
	the option when mandated by the DHCP protocol, for example in		the option when mandated by the DHCP protocol, for example in
	DHCPREQUEST messages.		DHCPREQUEST messages.
	There are scenarios in which a client connects to a network when a		There are scenarios in which a client connecting to a network
	lease is still valid. In that state, the client that is concerned		remembers previously allocated address, i.e. is in the INIT-REBOOT
	with privacy SHOULD perform a complete four way handshake starting		state. In that state, the client that is concerned with privacy
	with DHCPDISCOVER to obtain a new address lease. If the client can		SHOULD perform a complete four way handshake starting with
			DHCPDISCOVER to obtain a new address lease. If the client can
	ascertain that this is exactly the same network to which it was		ascertain that this is exactly the same network to which it was
	previously connected, and if the link layer address did not change,		previously connected, and if the link layer address did not change,
	the client MAY issue a DHCPREQUEST to try reclaim the current		the client MAY issue a DHCPREQUEST to try reclaim the current
	address.		address.
	3.4. Client hardware address		3.4. Client hardware address field
	Sixteen bytes in the header of the DHCP messages carry the "Client		Sixteen bytes in the header of the DHCP messages carry the "Client
	hardware address" (chaddr) as defined in [RFC2131]. The presence of		hardware address" (chaddr) as defined in [RFC2131]. The presence of
	this address is necessary for the proper operation of the DHCP		this address is necessary for the proper operation of the DHCP
	service.		service.
	Hardware addresses, called "link layer address" in many RFCs, can be		Hardware addresses, called "link layer address" in many RFCs, can be
	used to uniquely identify a device, especially if they follow the		used to uniquely identify a device, especially if they follow the
	IEEE 802 recommendations. These unique identifiers can be used by		IEEE 802 recommendations. These unique identifiers can be used by
	monitoring services to track the location of the device and its user.		monitoring services to track the location of the device and its user.
	skipping to change at page 11, line 47		skipping to change at page 12, line 8
	connection. It will also ensure that a strategy of randomizing the		connection. It will also ensure that a strategy of randomizing the
	link layer address will not be nullified by DHCP options.		link layer address will not be nullified by DHCP options.
	There are usages of DHCP where the underlying connection is a point		There are usages of DHCP where the underlying connection is a point
	to point link, in which case there is no link layer address available		to point link, in which case there is no link layer address available
	to construct a non-revealing identifier. If anonymity is desired in		to construct a non-revealing identifier. If anonymity is desired in
	such networks, the client SHOULD pick a random identifier that is		such networks, the client SHOULD pick a random identifier that is
	unique to the current link, using for example a combination of a		unique to the current link, using for example a combination of a
	local secret and an identifier of the connection.		local secret and an identifier of the connection.
	3.6. Parameter Request List		3.6. Parameter Request List Option
	The Parameter Request List (PRL) option is defined in [RFC2132] with		The Parameter Request List (PRL) option is defined in [RFC2132] with
	option code 61. It list the parameters requested from the server by		option code 61. It list the parameters requested from the server by
	the client. Different implementations request different		the client. Different implementations request different
	parameters.[RFC2132] specifies that "the client MAY list the options		parameters.[RFC2132] specifies that "the client MAY list the options
	in order of preference." It practice, this means that different		in order of preference." It practice, this means that different
	client implementations will request different parameters, in		client implementations will request different parameters, in
	different orders.		different orders.
	The choice of option numbers and the specific ordering of option		The choice of option numbers and the specific ordering of option
	skipping to change at page 16, line 44		skipping to change at page 17, line 11
	When using the anonymity profile, DHCPv6 clients SHOULD use the		When using the anonymity profile, DHCPv6 clients SHOULD use the
	Server Identifier Option (code 2) as specified in [RFC3315]. Clients		Server Identifier Option (code 2) as specified in [RFC3315]. Clients
	MUST only include server identifier values that were received with		MUST only include server identifier values that were received with
	the current link-layer address, because reuse of old values discloses		the current link-layer address, because reuse of old values discloses
	information that can be used to identify the client.		information that can be used to identify the client.
	4.5. Address assignment options		4.5. Address assignment options
	When using the anonymity profile, DHCPv6 clients might have to use		When using the anonymity profile, DHCPv6 clients might have to use
	SOLICIT or REQUEST messages to obtain IPv6 addresses through the DHCP		SOLICIT or REQUEST messages to obtain IPv6 addresses through the DHCP
	server. The clients SHOULD only use the options necessary to perform		server. Clients interested in privacy SHOULD request addresses using
	the requested DHCPv6 transactions, such as Identity Association for		the Identity Association for Non-temporary Addresses Option (IA_NA,
	Non-temporary Addresses Option (code 3) or Identity Association for		code 3).
	Temporary Addresses Option (code 4).
			The IA_NA option includes an IAID parameter that identifies a unique
			identity association for the interface for which the Address is
			requested. Clients interested in protecting their privacy MUST
			ensure that the IAID does not enable client identification. They
			also need to conform to the requirement of [RFC3315] that the IAID
			for that IA MUST be consistent across restarts of the DHCP client.
			We interpret that as requiring that the IAID MUST be constant for the
			association, as long as the link layer Address remains constant.
			Clients MAY meet the privacy, uniqueness and stability requirement of
			the IAID using by constructing it as the combination of one byte
			encoding the interface number in the system, and three bytes of the
			link layer address.
	The clients MAY use the IA Address Option (code 5) but need to		The clients MAY use the IA Address Option (code 5) but need to
	balance the potential advantage of "address continuity" versus the		balance the potential advantage of "address continuity" versus the
	potential risk of "previous address disclosure." A potential		potential risk of "previous address disclosure." A potential
	solution is to remove all stored addresses when a link-layer address		solution is to remove all stored addresses when a link-layer address
	changes, and to only use the IA Address option with addresses that		changes, and to only use the IA Address option with addresses that
	have been explicitly assigned through the current link-layer address.		have been explicitly assigned through the current link-layer address.
	The interaction between prefix delegation and anonymity require
	further study. For now, the simple solution is to avoid using prefix
	delegation when striving for anonymity. When using the anonymity
	profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of
	address assignment.
	4.5.1. Obtain temporary addresses		4.5.1. Obtain temporary addresses
	[RFC3315] defines a special container (IA_TA) for requesting		[RFC3315] defines a special container (IA_TA, code 4) for requesting
	temporary addresses. This is a good mechanism in principle, but		temporary addresses. This is a good mechanism in principle, but
	there are a number of issues associated with it. First, this is not		there are a number of issues associated with it. First, this is not
	a widely used feature, so clients depending solely on temporary		a widely used feature, so clients depending solely on temporary
	addresses may lock themselves out of service. Secondly, [RFC3315]		addresses may lock themselves out of service. Secondly, [RFC3315]
	does not specify any lifetime or lease length for temporary		does not specify any lifetime or lease length for temporary
	addresses. Therefore support for renewing temporary addresses may		addresses. Therefore support for renewing temporary addresses may
	vary between client implementations, including not being supported at		vary between client implementations, including not being supported at
	all. Finally, by requesting temporary addresses a client reveals its		all. Finally, by requesting temporary addresses a client reveals its
	desire for privacy and potentially risks countermeasures as described		desire for privacy and potentially risks countermeasures as described
	in Section 2.5.		in Section 2.5.
	Clients interested in their privacy SHOULD NOT use IA_TA. They		Because of these Clients interested in their privacy SHOULD NOT use
	should simply send an IA_NA with a randomized IAID. This, along with		IA_TA.
	the mitigation technique discussed in Section 4.4, will ensure that a
	client will get a new address that can be renewed and can be used as
	long as needed. To get a new address, it can send Request message
	with a new randomized IAID before releasing the other one. This will
	cause the server to assign a new address, as it still has a valid
	lease for the old IAID value. Once a new address is assigned, the
	address obtained using the older IAID value can be released safely,
	using the Release message or it may simply be allowed to time out.
	This solution may not work if the server enforces specific policies,		The addresses obtained according to Section 4.5 are temporary in
	e.g. only one address per client. If client does not succeed in		nature, and will be discarded when the link layer address is changed.
	receiving a second address using a new IAID, it may release the first		They thus meet most of the use cases of the temporary addresses
	one (using the old IAID) and then retry asking for a new address.		defined in [RFC4941]. Clients interested in their privacy should not
			publish their IPv6 addresses in the DNS or otherwise associate them
			with name services, and thus do not normally need two classes of
			addresses, one public, one temporary.
	From the Operating System perspective, addresses obtained using this		The use of mechanisms to allocate several IPv6 addresses to a client
	technique SHOULD be treated as temporary as specified in [RFC4941].		while preserving privacy is for further study.
			4.5.2. Prefix delegation
			The interaction between prefix delegation and anonymity require
			further study. For now, the simple solution is to avoid using prefix
			delegation when striving for anonymity. When using the anonymity
			profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of
			address assignment.
	4.6. Option Request Option		4.6. Option Request Option
	The Option Request Option (ORO) is defined in [RFC3315] with option		The Option Request Option (ORO) is defined in [RFC3315] with option
	code 6. It specifies the options that the client is requesting from		code 6. It specifies the options that the client is requesting from
	the server. The choice of requested options and the order of		the server. The choice of requested options and the order of
	encoding of these options in the ORO can be used to fingerprint the		encoding of these options in the ORO can be used to fingerprint the
	client.		client.
	The client willing to protect its privacy SHOULD only request a		The client willing to protect its privacy SHOULD only request a
	skipping to change at page 21, line 9		skipping to change at page 21, line 38
	strict ordering.		strict ordering.
	7. Changed the requirement in Section 4.6 to allow "increasing order		7. Changed the requirement in Section 4.6 to allow "increasing order
	of option codes" as an alternative to "randomized order of		of option codes" as an alternative to "randomized order of
	options".		options".
	8. In Section 4.5.1 revised the language stating lack of support for		8. In Section 4.5.1 revised the language stating lack of support for
	renewing temporary addresses, as RFC 3315 does in fact specify a		renewing temporary addresses, as RFC 3315 does in fact specify a
	mechanism for doing so.		mechanism for doing so.
			Changes from draft-03 to draft-04 address comments received during
			Working Group Last Call:
			1. In Section 3, tightened the normative language and the use of
			message codes.
			2. In Section 3.3, clarified the reference to the INIT-REBOOT
			scenario.
			3. Revised the writing of Section 4.5 for greater clarity.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-dhc-rfc3315bis]		[I-D.ietf-dhc-rfc3315bis]
	Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,		Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
	Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host		Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host
	Configuration Protocol for IPv6 (DHCPv6) bis", draft-ietf-		Configuration Protocol for IPv6 (DHCPv6) bis", draft-ietf-
	dhc-rfc3315bis-01 (work in progress), July 2015.		dhc-rfc3315bis-01 (work in progress), July 2015.
	skipping to change at page 22, line 37		skipping to change at page 23, line 32
	[I-D.ietf-6man-default-iids]		[I-D.ietf-6man-default-iids]
	Gont, F., Cooper, A., Thaler, D., and S. LIU,		Gont, F., Cooper, A., Thaler, D., and S. LIU,
	"Recommendation on Stable IPv6 Interface Identifiers",		"Recommendation on Stable IPv6 Interface Identifiers",
	draft-ietf-6man-default-iids-07 (work in progress), August		draft-ietf-6man-default-iids-07 (work in progress), August
	2015.		2015.
	[I-D.ietf-6man-ipv6-address-generation-privacy]		[I-D.ietf-6man-ipv6-address-generation-privacy]
	Cooper, A., Gont, F., and D. Thaler, "Privacy		Cooper, A., Gont, F., and D. Thaler, "Privacy
	Considerations for IPv6 Address Generation Mechanisms",		Considerations for IPv6 Address Generation Mechanisms",
	draft-ietf-6man-ipv6-address-generation-privacy-07 (work		draft-ietf-6man-ipv6-address-generation-privacy-08 (work
	in progress), June 2015.		in progress), September 2015.
	[I-D.ietf-dhc-dhcp-privacy]		[I-D.ietf-dhc-dhcp-privacy]
	Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy		Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy
	considerations for DHCPv4", draft-ietf-dhc-dhcp-privacy-01		considerations for DHCPv4", draft-ietf-dhc-dhcp-privacy-01
	(work in progress), August 2015.		(work in progress), August 2015.
	[I-D.ietf-dhc-dhcpv6-privacy]		[I-D.ietf-dhc-dhcpv6-privacy]
	Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy		Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
	considerations for DHCPv6", draft-ietf-dhc-		considerations for DHCPv6", draft-ietf-dhc-
	dhcpv6-privacy-01 (work in progress), August 2015.		dhcpv6-privacy-01 (work in progress), August 2015.
End of changes. 34 change blocks.
	83 lines changed or deleted		114 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/