draft-ietf-dhc-anonymity-profile-01.txt		draft-ietf-dhc-anonymity-profile-02.txt
	Network Working Group C. Huitema		Network Working Group C. Huitema
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Updates: 4361 (if approved) T. Mrugalski		Updates: 4361 (if approved) T. Mrugalski
	Intended status: Standards Track ISC		Intended status: Standards Track ISC
	Expires: January 1, 2016 S. Krishnan		Expires: February 21, 2016 S. Krishnan
	Ericsson		Ericsson
	June 30, 2015		August 20, 2015
	Anonymity profile for DHCP clients		Anonymity profile for DHCP clients
	draft-ietf-dhc-anonymity-profile-01.txt		draft-ietf-dhc-anonymity-profile-02.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 January 1, 2016.		This Internet-Draft will expire on February 21, 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 22		skipping to change at page 2, line 22
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . 7
	3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8		3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8
	3.1. Client IP address field . . . . . . . . . . . . . . . . . 9		3.1. Client IP address field . . . . . . . . . . . . . . . . . 9
	3.2. Requested IP address option . . . . . . . . . . . . . . . 9		3.2. Requested IP address option . . . . . . . . . . . . . . . 9
	3.3. Client hardware address . . . . . . . . . . . . . . . . . 9		3.3. Client hardware address . . . . . . . . . . . . . . . . . 10
	3.4. Client Identifier Option . . . . . . . . . . . . . . . . 10		3.4. Client Identifier Option . . . . . . . . . . . . . . . . 10
	3.5. Host Name Option . . . . . . . . . . . . . . . . . . . . 11		3.5. Host Name Option . . . . . . . . . . . . . . . . . . . . 11
	3.6. Client FQDN Option . . . . . . . . . . . . . . . . . . . 11		3.6. Client FQDN Option . . . . . . . . . . . . . . . . . . . 12
	3.7. UUID/GUID-based Client Identifier Option . . . . . . . . 12		3.7. UUID/GUID-based Client Identifier Option . . . . . . . . 12
	3.8. User and Vendor Class DHCP options . . . . . . . . . . . 12		3.8. User and Vendor Class DHCP options . . . . . . . . . . . 13
	4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 12		4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 13
	4.1. Do not send Confirm messages, unless really sure where . 13		4.1. Do not send Confirm messages, unless really sure where . 14
	4.2. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 13		4.2. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 14
	4.2.1. Anonymous Information-Request . . . . . . . . . . . . 14		4.2.1. Anonymous Information-Request . . . . . . . . . . . . 15
	4.3. Server Identifier Option . . . . . . . . . . . . . . . . 14		4.3. Server Identifier Option . . . . . . . . . . . . . . . . 15
	4.4. Address assignment options . . . . . . . . . . . . . . . 15		4.4. Address assignment options . . . . . . . . . . . . . . . 15
	4.4.1. Obtain temporary addresses . . . . . . . . . . . . . 15		4.4.1. Obtain temporary addresses . . . . . . . . . . . . . 16
	4.5. Option Request Option . . . . . . . . . . . . . . . . . . 16		4.5. Option Request Option . . . . . . . . . . . . . . . . . . 16
	4.5.1. Previous option values . . . . . . . . . . . . . . . 16		4.5.1. Previous option values . . . . . . . . . . . . . . . 17
	4.6. Authentication Option . . . . . . . . . . . . . . . . . . 16		4.6. Authentication Option . . . . . . . . . . . . . . . . . . 17
	4.7. User and Vendor Class DHCPv6 options . . . . . . . . . . 17		4.7. User and Vendor Class DHCPv6 options . . . . . . . . . . 17
	4.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 17		4.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 17
	5. Operational Considerations . . . . . . . . . . . . . . . . . 17		5. Operational Considerations . . . . . . . . . . . . . . . . . 18
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	9. Changes from previous versions . . . . . . . . . . . . . . . 18		9. Changes from previous versions . . . . . . . . . . . . . . . 18
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	10.1. Normative References . . . . . . . . . . . . . . . . . . 18		10.1. Normative References . . . . . . . . . . . . . . . . . . 19
	10.2. Informative References . . . . . . . . . . . . . . . . . 19		10.2. Informative References . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	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 8, line 34		skipping to change at page 8, line 29
	[I-D.ietf-dhc-dhcp-privacy] and [I-D.ietf-dhc-dhcpv6-privacy].		[I-D.ietf-dhc-dhcp-privacy] and [I-D.ietf-dhc-dhcpv6-privacy].
	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		DISCOVER: The anonymized DISCOVER messages MUST contain the Message
	Type, Client Identifier, Host name, and Parameter Request List		Type, Client Identifier, and Parameter Request List options. It
	options. It SHOULD NOT contain any other option.		SHOULD NOT contain any other option.
	REQUEST: The anonymized REQUEST messages SHOULD contain the Message		REQUEST: The anonymized REQUEST messages SHOULD contain the Message
	Type, Client Identifier, Host name, and Parameter Request List		Type, Client Identifier, Requested IP address and Parameter
	options. If the message is in response to an OFFER, it SHOULD		Request List options. If the message is in response to an OFFER,
	contain the corresponding Server Identifier option. It SHOULD NOT		it SHOULD contain the corresponding Server Identifier option. It
	contain any other option.		SHOULD NOT contain any other option.
	DECLINE: The anonymized DECLINE messages SHOULD contain the Message		DECLINE: The anonymized DECLINE messages SHOULD contain the Message
	Type, Client Identifier and Server Identifier options.		Type, Client Identifier and Server Identifier options.
	RELEASE: The anonymized RELEASE messages SHOULD contain the Message		RELEASE: The anonymized RELEASE messages SHOULD contain the Message
	Type, Client Identifier and Server Identifier options.		Type, Client Identifier and Server Identifier options.
	INFORM: The anonymized INFORM messages MUST contain the Message		INFORM: The anonymized INFORM messages MUST contain the Message
	Type, Client Id, Host name, and Parameter Request List options.		Type, Client Id, and Parameter Request List options. It SHOULD
	It SHOULD NOT contain any other option.		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
			INFORM messages is discussed in Section 3.5 and Section 3.6.
	3.1. Client IP address field		3.1. Client IP address field
	Four bytes in the header of the DHCP messages carry the "Client IP		Four bytes in the header of the DHCP messages carry the "Client IP
	address" (ciaddr) as defined in [RFC2131]. In DHCP, this field is		address" (ciaddr) as defined in [RFC2131]. In DHCP, this field is
	used by the clients to indicate the address that they used		used by the clients to indicate the address that they used
	previously, so that as much as possible the server can allocate them		previously, so that as much as possible the server can allocate them
	the same address.		the same address.
	There is very little privacy implication of sending this address in		There is very little privacy implication of sending this address in
	the DHCP messages, except in one case, when connecting to a different		the DHCP messages, except in one case, when connecting to a different
	skipping to change at page 9, line 47		skipping to change at page 10, line 5
	convenience, an attempt to regain the same IP address that was used		convenience, an attempt to regain the same IP address that was used
	in a previous connection. Doing so entails the risk of disclosing an		in a previous connection. Doing so entails the risk of disclosing an
	IP address used by the client at a previous location, or with a		IP address used by the client at a previous location, or with a
	different MAC Address.		different MAC 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
			lease is still valid. In that state, the client that is concerned
			with privacy 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
			previously connected, and if the link layer address did not change,
			the client MAY issue a DHCPREQUEST to try reclaim the current
			address.
	3.3. Client hardware address		3.3. Client hardware address
	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
	skipping to change at page 10, line 47		skipping to change at page 11, line 20
	tradeoff should depend on the circumstances.		tradeoff should depend on the circumstances.
	In contradiction to [RFC4361], When using the anonymity profile, DHCP		In contradiction to [RFC4361], When using the anonymity profile, DHCP
	clients MUST use client identifiers based solely on the link layer		clients MUST use client identifiers based solely on the link layer
	address that will be used in the underlying connection. This will		address that will be used in the underlying connection. This will
	ensure that the DHCP client identifier does not leak any information		ensure that the DHCP client identifier does not leak any information
	that is not already available to entities monitoring the network		that is not already available to entities monitoring the network
	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.
			In general, clients that care about privacy SHOULD NOT use RFC4361 as
			doing so would provide a stable identifier even when MAC
			randomization is used. If RFC4361 needs to be used, it is
			RECOMMENDED for the client to only use the DUID type DUID-LL (3) with
			the link layer address of the interface on which the DHCP message is
			sent.
	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.5. Host Name Option		3.5. Host Name Option
	The Host Name option is defined in [RFC2132] with option code 12.		The Host Name option is defined in [RFC2132] with option code 12.
	skipping to change at page 11, line 24		skipping to change at page 12, line 5
	Fully qualified domain names are obviously unique identifiers, but		Fully qualified domain names are obviously unique identifiers, but
	even simple host names can provide a significant amount of		even simple host names can provide a significant amount of
	information on the identity of the device. They are typically chosen		information on the identity of the device. They are typically chosen
	to be unique in the context where the device is most often used. If		to be unique in the context where the device is most often used. If
	that context is wide enough, in a large company or in a big		that context is wide enough, in a large company or in a big
	university, the host name will be a pretty good identifier of the		university, the host name will be a pretty good identifier of the
	device. Monitoring services could use that information in		device. Monitoring services could use that information in
	conjunction with traffic analysis and quickly derive the identity of		conjunction with traffic analysis and quickly derive the identity of
	the device's owner.		the device's owner.
	When using the anonymity profile, DHCP clients SHOULD avoid sending		When using the anonymity profile, DHCP clients SHOULD NOT send the
	the host name option. If they chose to send the option, DHCP clients		host name option. If they chose to send the option, DHCP clients
	MUST always send a non-qualified host name instead of a fully		MUST always send a non-qualified host name instead of a fully
	qualified domain name, and MUST obfuscate the host name value.		qualified domain name, and MUST obfuscate the host name value.
	When obfuscating the host name, DHCP clients SHOULD construct a		There are many ways to obfuscate a host name. The construction rules
	randomized host name by computing a secure hash of a local secret and		SOULD guarantee that a different host name is generated each time the
	of the link layer address that will be used in the underlying		link-layer address changes and that the obfuscated host name will not
	connection, and then use as the name the hexadecimal representation		reveal the underlying link layer address. The construction SHOULD
	of the first 6 bytes of the hash. This procedure ensures that the		generate names that are unique enough to minimize collisions in the
	random name will not reveal the underlying link layer address.		local link. Clients MAY use the following algorithm: compute a
			secure hash of a local secret and of the link layer address that will
			be used in the underlying connection, and then use the hexadecimal
			representation of the first 6 bytes of the hash as the obfuscated
			host name.
			There is a potential downside to having a specific name pattern for
			hosts that require anonymity, as explained in Section 2.5. For this
			reason, the above algorithm is just a suggestion.
	3.6. Client FQDN Option		3.6. Client FQDN Option
	The Client FQDN option is defined in [RFC4702] with option code 81.		The Client FQDN option is defined in [RFC4702] with option code 81.
	The option allows the DHCP clients to advertise to the DHCP server		The option allows the DHCP clients to advertise to the DHCP server
	their fully qualified domain name (FQDN) such as		their fully qualified domain name (FQDN) such as
	"mobile.example.com." This would allow the DHCP server to update in		"mobile.example.com." This would allow the DHCP server to update in
	the DNS the PTR record for the IP address allocated to the client.		the DNS the PTR record for the IP address allocated to the client.
	Depending on circumstances, either the DHCP client or the DHCP server		Depending on circumstances, either the DHCP client or the DHCP server
	could update in the DNS the A record for the FQDN of the client.		could update in the DNS the A record for the FQDN of the client.
	skipping to change at page 15, line 31		skipping to change at page 16, line 15
	The interaction between prefix delegation and anonymity require		The interaction between prefix delegation and anonymity require
	further study. For now, the simple solution is to avoid using prefix		further study. For now, the simple solution is to avoid using prefix
	delegation when striving for anonymity. When using the anonymity		delegation when striving for anonymity. When using the anonymity
	profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of		profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of
	address assignment.		address assignment.
	4.4.1. Obtain temporary addresses		4.4.1. Obtain temporary addresses
	[RFC3315] defines a special container (IA_TA) for requesting		[RFC3315] defines a special container (IA_TA) 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 of all, this
	widely used feature, so clients depending solely on temporary		is not widely used feature. Thus clients cannot count on it to be
	addresses may lock themselves out of service. Secondly, [RFC3315]		always available. Secondly, [RFC3315] does not specify any renewal
	does not specify any renewal mechanisms for temporary addresses.		mechanisms for temporary addresses. Therefore the support for
	Therefore support for renewing temporary addresses may vary between		renewing temporary addresses in server implementations usually varies
	server implementations, including not being supported at all.		between poor and non-existent. Finally, a client reveals its desire
	Finally, by requesting temporary addresses a client reveals its		for privacy just by requesting temporary addresses, and potentially
	desire for privacy and potentially risks countermeasures as described		risks countermeasures as described in Section 2.5.
	in Section 2.5.
	Clients interested in their privacy SHOULD NOT use IA_TA. They		Clients interested in their privacy SHOULD NOT use the IA_TA. They
	should simply send an IA_NA with a randomized IAID. This, along with		should simply send an IA_NA with a randomized IAID. This, along with
	the mitigation technique discussed in Section 4.3, will ensure that a		the mitigation technique discussed in Section 4.3, will ensure that a
	client will get a new address that can be renewed and can be used as		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		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		with a new randomized IAID before releasing the older one. This will
	cause the server to assign a new address, as it still has a valid		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		lease for the old IAID value. Once a new address is assigned, the
	address obtained using the older IAID value can be released safely,		address obtained using the older IAID value can be released safely or
	using the Release message or it may simply be allowed to time out.		be allowed to time out.
	This solution may not work if the server enforces specific policies,
	e.g. only one address per client. If client does not succeed in
	receiving a second address using a new IAID, it may release the first
	one (using an old IAID) and then retry asking for a new address.
	From the Operating System perspective, addresses obtained using this		From the Operating System perspective, addresses obtained using this
	technique SHOULD be treated as temporary as specified in [RFC4941].		technique SHOULD be treated as temporary addresses as specified in
			[RFC4941].
			Note that this solution may not work if the server enforces specific
			policies such as providing only one address per client. If client
			does not succeed in obtaining a second address using a new IAID, it
			needs to release the first one (using an old IAID) and then retry
			asking for a new address.
	4.5. Option Request Option		4.5. Option Request Option
	A DHCPv6 client may reveal other types of information, besides unique		A DHCPv6 client may reveal other types of information, besides unique
	identifiers. There are many ways a DHCPv6 client can perform certain		identifiers. There are many ways a DHCPv6 client can perform certain
	actions and the specifics can be used to fingerprint the client.		actions and the specifics can be used to fingerprint the client.
	This may not reveal the identity of a client, but may provide		This may not reveal the identity of a client, but may provide
	additional information, such as the device type, vendor type or OS		additional information, such as the device type, vendor type or OS
	type and in some cases specific version.		type and in some cases specific version.
	skipping to change at page 17, line 28		skipping to change at page 18, line 11
	the client. As explained in Section 3.6 they MAY use a local-only		the client. As explained in Section 3.6 they MAY use a local-only
	FQDN by combining a host name derived from the link layer address and		FQDN by combining a host name derived from the link layer address and
	a suffix advertised by the local DHCP server.		a suffix advertised by the local DHCP server.
	5. Operational Considerations		5. Operational Considerations
	The anonymity profile has the effect of hiding the client identity		The anonymity profile has the effect of hiding the client identity
	from the DHCP server. This is not always desirable. Some DHCP		from the DHCP server. This is not always desirable. Some DHCP
	servers provide facilities like publishing names and addresses in the		servers provide facilities like publishing names and addresses in the
	DNS, or ensuring that returning clients get reassigned the same		DNS, or ensuring that returning clients get reassigned the same
	address. Implementers should be careful to only use the anonymity		address.
	profile when privacy trumps management considerations.
	Clients using the anonymity profile in general consume more		Clients using the anonymity profile may be consuming more resources.
	resources. For example when they change MAC address and request for		For example when they change MAC address and request for a new IP,
	a new IP, the old one is still marked as leased by the server.		the old one is still marked as leased by the server.
			Implementers SHOULD provide a way for clients to control when the
			anonymity profile is used, and when standard behavior is preferred.
			Implementers MAY implement this control by tying use of the anonymity
			profile to that of link-layer address randomization.
	6. Security Considerations		6. Security Considerations
	The use of the anonymity profile does not change the security		The use of the anonymity profile does not change the security
	considerations of the DHCPv4 or DHCPv6 protocols.		considerations of the DHCPv4 or DHCPv6 protocols.
	7. IANA Considerations		7. IANA Considerations
	This draft does not require any IANA action.		This draft does not require any IANA action.
	skipping to change at page 18, line 31		skipping to change at page 19, line 17
	when roaming between access points on the same network.		when roaming between access points on the same network.
	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-00 (work in progress), March 2015.		dhc-rfc3315bis-01 (work in progress), July 2015.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
	2131, March 1997.		2131, DOI 10.17487/RFC2131, March 1997,
			<http://www.rfc-editor.org/info/rfc2131>.
	[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor		[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
	Extensions", RFC 2132, March 1997.		Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
			<http://www.rfc-editor.org/info/rfc2132>.
	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
	and M. Carney, "Dynamic Host Configuration Protocol for		and M. Carney, "Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6)", RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
	[RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for		[RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for
	Dynamic Host Configuration Protocol version 4 (DHCPv4)",		Dynamic Host Configuration Protocol version 4 (DHCPv4)",
	RFC 3925, October 2004.		RFC 3925, DOI 10.17487/RFC3925, October 2004,
			<http://www.rfc-editor.org/info/rfc3925>.
	[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client		[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
	Identifiers for Dynamic Host Configuration Protocol		Identifiers for Dynamic Host Configuration Protocol
	Version Four (DHCPv4)", RFC 4361, February 2006.		Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361,
			February 2006, <http://www.rfc-editor.org/info/rfc4361>.
	[RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host		[RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
	Configuration Protocol (DHCP) Client Fully Qualified		Configuration Protocol (DHCP) Client Fully Qualified
	Domain Name (FQDN) Option", RFC 4702, October 2006.		Domain Name (FQDN) Option", RFC 4702, DOI 10.17487/
			RFC4702, October 2006,
			<http://www.rfc-editor.org/info/rfc4702>.
	[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for		[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)		IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
	Option", RFC 4704, October 2006.		Option", RFC 4704, October 2006.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy		[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	skipping to change at page 19, line 32		skipping to change at page 20, line 24
	[CNBC] Weston, G., Greenwald, G., and R. Gallagher, "CBC News:		[CNBC] Weston, G., Greenwald, G., and R. Gallagher, "CBC News:
	CSEC used airport Wi-Fi to track Canadian travellers", Jan		CSEC used airport Wi-Fi to track Canadian travellers", Jan
	2014, <http://www.cbc.ca/news/politics/csec-used-airport-		2014, <http://www.cbc.ca/news/politics/csec-used-airport-
	wi-fi-to-track-canadian-travellers-edward-snowden-		wi-fi-to-track-canadian-travellers-edward-snowden-
	documents-1.2517881>.		documents-1.2517881>.
	[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-04 (work in progress), June		draft-ietf-6man-default-iids-05 (work in progress), July
	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-03 (work
	in progress), June 2015.		in progress), January 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 DHCP", draft-ietf-dhc-dhcp-privacy-00		considerations for DHCP", draft-ietf-dhc-dhcp-privacy-00
	(work in progress), February 2015.		(work in progress), February 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-00 (work in progress), February 2015.		dhcpv6-privacy-00 (work in progress), February 2015.
	skipping to change at page 20, line 20		skipping to change at page 21, line 9
	[IEEE-OUI]		[IEEE-OUI]
	IEEE, "Organizationally Unique Identifiers		IEEE, "Organizationally Unique Identifiers
	http://www.ieee.org/netstorage/standards/oui.txt",		http://www.ieee.org/netstorage/standards/oui.txt",
	<http://www.ieee.org/netstorage/standards/oui.txt>.		<http://www.ieee.org/netstorage/standards/oui.txt>.
	[IETFMACRandom]		[IETFMACRandom]
	Zuniga, JC., "MAC Privacy", November 2014,		Zuniga, JC., "MAC Privacy", November 2014,
	<http://www.ietf.org/blog/2014/11/mac-privacy/>.		<http://www.ietf.org/blog/2014/11/mac-privacy/>.
	[RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration		[RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host
	Protocol (DHCP) Options for the Intel Preboot eXecution		Configuration Protocol (DHCP) Options for the Intel
	Environment (PXE)", RFC 4578, November 2006.		Preboot eXecution Environment (PXE)", RFC 4578, DOI
			10.17487/RFC4578, November 2006,
			<http://www.rfc-editor.org/info/rfc4578>.
	[WiFiRadioFingerprinting]		[WiFiRadioFingerprinting]
	Brik, V., Banerjee, S., Gruteser, M., and S. Oh, "Wireless		Brik, V., Banerjee, S., Gruteser, M., and S. Oh, "Wireless
	Device Identification with Radiometric Signatures",		Device Identification with Radiometric Signatures",
	September 2008,		September 2008, <http://www.winlab.rutgers.edu/~gruteser/
	<http://www.winlab.rutgers.edu/~gruteser/papers/		papers/brik_paradis.pdf>.
	brik_paradis.pdf>.
	Authors' Addresses		Authors' Addresses
	Christian Huitema		Christian Huitema
	Microsoft		Microsoft
	Redmond, WA 98052		Redmond, WA 98052
	U.S.A.		U.S.A.
	Email: huitema@microsoft.com		Email: huitema@microsoft.com
End of changes. 38 change blocks.
	79 lines changed or deleted		118 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/