draft-ietf-dhc-anonymity-profile-05.txt		draft-ietf-dhc-anonymity-profile-06.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: July 16, 2016 ISC		Expires: August 1, 2016 ISC
	S. Krishnan		S. Krishnan
	Ericsson		Ericsson
	January 13, 2016		January 29, 2016
	Anonymity profile for DHCP clients		Anonymity profile for DHCP clients
	draft-ietf-dhc-anonymity-profile-05.txt		draft-ietf-dhc-anonymity-profile-06.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.		designed to minimize disclosure of identifying information.
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	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 July 16, 2016.		This Internet-Draft will expire on August 1, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 26		skipping to change at page 2, line 26
	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. 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 field . . . . . . . . . . . . . . 10		3.4. Client hardware address field . . . . . . . . . . . . . . 11
	3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11		3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11
	3.6. Parameter Request List Option . . . . . . . . . . . . . . 12		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 . . . . . . . . 14
	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. Avoiding fingerprinting . . . . . . . . . . . . . . . . . 15		4.1. 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 . . . . . . . . . . . . . 16		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 . . . . . . . . . . . . . . . . 17
	4.5. Address assignment options . . . . . . . . . . . . . . . 17		4.5. Address assignment options . . . . . . . . . . . . . . . 17
	4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 17		4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 18
	4.5.2. Prefix delegation . . . . . . . . . . . . . . . . . . 18		4.5.2. Prefix delegation . . . . . . . . . . . . . . . . . . 18
	4.6. Option Request Option . . . . . . . . . . . . . . . . . . 18		4.6. Option Request Option . . . . . . . . . . . . . . . . . . 18
	4.6.1. Previous option values . . . . . . . . . . . . . . . 18		4.6.1. Previous option values . . . . . . . . . . . . . . . 19
	4.7. Authentication Option . . . . . . . . . . . . . . . . . . 19		4.7. Authentication Option . . . . . . . . . . . . . . . . . . 19
	4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 19		4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 19
	4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 19		4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 19
	5. Operational Considerations . . . . . . . . . . . . . . . . . 19		5. Operational Considerations . . . . . . . . . . . . . . . . . 20
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 20		6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	9. Changes from previous versions . . . . . . . . . . . . . . . 20		9. Changes from previous versions . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	10.1. Normative References . . . . . . . . . . . . . . . . . . 22		10.1. Normative References . . . . . . . . . . . . . . . . . . 23
	10.2. Informative References . . . . . . . . . . . . . . . . . 23		10.2. Informative References . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	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 10, line 20		skipping to change at page 10, line 20
	locations. DHCP clients should ensure that the field is cleared when		locations. DHCP clients should ensure that the field is cleared when
	they know that the network attachment has changed, and in particular		they know that the network attachment has changed, and in particular
	if the link layer address is reset by the device's administrator.		if the link layer address is reset by the device's administrator.
	The clients using the anonymity profile MUST NOT include in the		The clients using the anonymity profile MUST NOT include in the
	message a Client IP Address that has been obtained with a different		message a Client IP Address that has been obtained with a different
	link-layer address.		link-layer address.
	3.3. Requested IP address option		3.3. Requested IP address option
	The Requested IP address option id defined in [RFC2132] with code 50.		The Requested IP address option is defined in [RFC2132] with code 50.
	It allows the client to request that a particular IP address be		It allows the client to request that a particular IP address be
	assigned. The option is mandatory in some protocol messages per		assigned. The option is mandatory in some protocol messages per
	[RFC2131], for example when a client selects to use an address		[RFC2131], for example when a client selects to use an address
	offered by a server. However, this option is not mandatory in the		offered by a server. However, this option is not mandatory in the
	DHCPDISCOVER message. It is simply a convenience, an attempt to		DHCPDISCOVER message. It is simply a convenience, an attempt to
	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. The risk exists for all forms of IP addresses, public or
			private, as some private addresses may be used in a wide scope, e.g.
			when an Internet Service Provider is using Network Address
			Translation.
	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 connecting to a network		There are scenarios in which a client connecting to a network
	remembers previously allocated address, i.e. is in the INIT-REBOOT		remembers previously allocated address, i.e. is in the INIT-REBOOT
	state. In that state, the client that is concerned with privacy		state. In that state, the client that is concerned with privacy
	SHOULD perform a complete four way handshake starting with		SHOULD perform a complete four way handshake starting with
	skipping to change at page 12, line 11		skipping to change at page 12, line 18
	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 Option		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 55. 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
	numbers in the Parameter Request List can be used to fingerprint the		numbers in the Parameter Request List can be used to fingerprint the
	client. This may not reveal the identity of a client, but may		client. This may not reveal the identity of a client, but may
	provide additional information, such as the device type, vendor type		provide additional information, such as the device type, vendor type
	skipping to change at page 14, line 9		skipping to change at page 14, line 16
	The UUID/GUID-based Client Machine Identifier option is defined in		The UUID/GUID-based Client Machine Identifier option is defined in
	[RFC4578], with option code 97. The option is part of a set of		[RFC4578], with option code 97. The option is part of a set of
	options for Intel Preboot eXecution Environment (PXE). The purpose		options for Intel Preboot eXecution Environment (PXE). The purpose
	of the PXE system is to perform management functions on a device		of the PXE system is to perform management functions on a device
	before its main OS is operational. The Client Machine Identifier		before its main OS is operational. The Client Machine Identifier
	carries a 16-octet Globally Unique Identifier (GUID), which uniquely		carries a 16-octet Globally Unique Identifier (GUID), which uniquely
	identifies the device.		identifies the device.
	The PXE system is clearly designed for devices operating in a		The PXE system is clearly designed for devices operating in a
	controlled environment, and its functions are not meant to be used by		controlled environment. The main usage of the PXE system is to
	mobile nodes visiting untrusted networks. If only for privacy		install a new version of the operating system through a high speed
	reasons, nodes visiting untrusted networks MUST disable the PXE		Ethernet connection. The process is typically controlled from the
	functions, and MUST NOT send the corresponding options.		user interface during the boot process. Common sense seems to
			dictate that getting a new operating system from an unauthenticated
			server at an untrusted location is a really bad idea, and that even
			if the option was available users would not activate it. In any
			case, the option is only used in the "pre boot" environment, and is
			there is no reason to use it once the system is up and running. If
			only for privacy reasons, nodes visiting untrusted networks MUST NOT
			send or use the PXE options.
	3.10. User and Vendor Class DHCP options		3.10. User and Vendor Class DHCP options
	Vendor identifying options are defined in [RFC2132] and [RFC3925].		Vendor identifying options are defined in [RFC2132] and [RFC3925].
	When using the anonymity profile, DHCP clients SHOULD NOT use the		When using the anonymity profile, DHCP clients SHOULD NOT use the
	Vendor Specific Information option (code 43), the Vendor Class		Vendor Specific Information option (code 43), the Vendor Class
	Identifier Option (60), the Vendor Class option (code 124), or the		Identifier Option (60), the Vendor Class option (code 124), or the
	Vendor Specific Information option (code 125) as these options		Vendor Specific Information option (code 125) as these options
	potentially reveal identifying information.		potentially reveal identifying information.
	skipping to change at page 15, line 47		skipping to change at page 16, line 12
	message an attacker can trivially identify the previous point(s) of		message an attacker can trivially identify the previous point(s) of
	attachment.		attachment.
	Clients interested in protecting their privacy SHOULD NOT send		Clients interested in protecting their privacy SHOULD NOT send
	Confirm messages and instead directly try to acquire addresses on the		Confirm messages and instead directly try to acquire addresses on the
	new link. However, not sending confirm messages can result in		new link. However, not sending confirm messages can result in
	connectivity hiatus in some scenarios, e.g. roaming between two		connectivity hiatus in some scenarios, e.g. roaming between two
	access points in the same wireless network. DHCPv6 clients that can		access points in the same wireless network. DHCPv6 clients that can
	verify that the previous link and the current link are part of the		verify that the previous link and the current link are part of the
	same network MAY send Confirm messages while still protecting their		same network MAY send Confirm messages while still protecting their
	privacy.		privacy. Such link identification should happen before DHCPv6 is
			used, and thus cannot depend on the DHCPv6 information used in
			[RFC6059]. In practice, the most reliable detection of network
			attachment is through link layer security, e.g. [IEEE8021X].
	4.3. Client Identifier DHCPv6 Option		4.3. Client Identifier DHCPv6 Option
	The client identifier option is defined in [RFC3315] with option code		The client identifier option is defined in [RFC3315] with option code
	1. The purpose of the client identifier option is to identify the		1. The purpose of the client identifier option is to identify the
	client to the server. The content of the option is a DHCP Unique		client to the server. The content of the option is a DHCP Unique
	Identifier (DUID). One of the primary privacy concerns is that a		Identifier (DUID). One of the primary privacy concerns is that a
	client is disclosing a stable identifier (the DUID) that can be use		client is disclosing a stable identifier (the DUID) that can be use
	for tracking and profiling. Three DUID formats are specified in		for tracking and profiling. Three DUID formats are specified in
	[RFC3315]: Link-layer address plus time, Vendor-assigned unique ID		[RFC3315]: Link-layer address plus time (DUID-LLT), Vendor-assigned
	based on Enterprise Number, Link-layer address. A fourth type, DUID-		unique ID based on Enterprise Number, and Link-layer address. A
	UUID is defined in [RFC6355].		fourth type, DUID-UUID is defined in [RFC6355].
	When using the anonymity profile in conjunction with randomized link-		When using the anonymity profile in conjunction with randomized link-
	layer addresses, DHCPv6 clients MUST use the DUID format number 3,		layer addresses, DHCPv6 clients MUST use the DUID format number 3,
	Link-layer address. The value of the Link-layer address should be		Link-layer address. The value of the Link-layer address should be
	that currently assigned to the interface.		that currently assigned to the interface.
	When using the anonymity profile without the benefit of randomized		When using the anonymity profile without the benefit of randomized
	link-layer addresses, clients that want to protect their privacy		link-layer addresses, clients that want to protect their privacy
	SHOULD generate a new randomized DUID-LLT every time they attach to a		SHOULD generate a new randomized DUID-LLT every time they attach to a
	new link or detect a possible link change event. The exact details		new link or detect a possible link change event. The exact details
	are left up to implementors, but there are several factors should be		are left up to implementors, but there are several factors should be
	taken into consideration. The DUID type SHOULD be set to 1 (DUID-		taken into consideration. The DUID type SHOULD be set to 1 (DUID-
	LLT). Hardware type SHOULD be set appropriately to the hardware		LLT). Hardware type SHOULD be set appropriately to the hardware
	type. Time MAY be set to current time, but this will reveal the fact		type. The link address embedded in the LLT SHOULD be set to a
	that the DUID is newly generated. Implementors interested in hiding		randomized value. Time SHOULD be set to a random timestamp from the
	this fact MAY use a time stamp from the past. e.g. a random timestamp		previous year. Time MAY be set to current time, but this will reveal
	from the previous year could be a good value.		the fact that the DUID is newly generated, and could provide
			information for device fingerprinting.
	4.3.1. Anonymous Information-Request		4.3.1. Anonymous Information-Request
	According to [RFC3315], a DHCPv6 client typically includes its client		According to [RFC3315], a DHCPv6 client typically includes its client
	identifier in most of the messages it sends. There is one exception,		identifier in most of the messages it sends. There is one exception,
	however. Client is allowed to omit its client identifier when		however. Client is allowed to omit its client identifier when
	sending Information-Request.		sending Information-Request.
	When using stateless DHCPv6, clients wanting to protect their privacy		When using stateless DHCPv6, clients wanting to protect their privacy
	SHOULD NOT include client identifiers in their Information-Request		SHOULD NOT include client identifiers in their Information-Request
	skipping to change at page 17, line 11		skipping to change at page 17, line 23
	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. Clients interested in privacy SHOULD request addresses using		server. In DHCPv6, the collection of addresses assigned to a client
	the Identity Association for Non-temporary Addresses Option (IA_NA,		is indemtified by an Identity Association (IA).Clients interested in
	code 3).		privacy SHOULD request addresses using the Identity Association for
			Non-temporary Addresses Option (IA_NA, code 3).
	The IA_NA option includes an IAID parameter that identifies a unique		The IA_NA option includes an IAID parameter that identifies a unique
	identity association for the interface for which the Address is		identity association for the interface for which the Address is
	requested. Clients interested in protecting their privacy MUST		requested. Clients interested in protecting their privacy MUST
	ensure that the IAID does not enable client identification. They		ensure that the IAID does not enable client identification. They
	also need to conform to the requirement of [RFC3315] that the IAID		also need to conform to the requirement of [RFC3315] that the IAID
	for that IA MUST be consistent across restarts of the DHCP client.		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		We interpret that as requiring that the IAID MUST be constant for the
	association, as long as the link layer address remains constant.		association, as long as the link layer address remains constant.
	skipping to change at page 20, line 19		skipping to change at page 20, line 36
	7. IANA Considerations		7. IANA Considerations
	This draft does not require any IANA action.		This draft does not require any IANA action.
	8. Acknowledgments		8. Acknowledgments
	The inspiration for this draft came from discussions in the Perpass		The inspiration for this draft came from discussions in the Perpass
	mailing list. Several people provided feedback on this draft,		mailing list. Several people provided feedback on this draft,
	notably Noel Anderson, Lorenzo Colitti, Stephen Farrell, Nick Grifka,		notably Noel Anderson, Lorenzo Colitti, Stephen Farrell, Nick Grifka,
	Tushar Gupta, Gabriel Montenegro, Marcin Siodelski, Dave Thaler,		Tushar Gupta, Brian Haberman, Gabriel Montenegro, Marcin Siodelski,
	Bernie Volz, and Jun Wu.		Dave Thaler, Bernie Volz, and Jun Wu.
	9. Changes from previous versions		9. Changes from previous versions
	The RFC Editor must ensure that this section is removed prior to RFC		The RFC Editor must ensure that this section is removed prior to RFC
	publication.		publication.
	Changes from draft-00 to draft-01:		Changes from draft-00 to draft-01:
	1. In Section 2.6, added guidance when using [RFC7618].		1. In Section 2.6, added guidance when using [RFC7618].
	skipping to change at page 22, line 19		skipping to change at page 22, line 37
	the IAID is composed of the interface identifier and the first		the IAID is composed of the interface identifier and the first
	three bytes of the HW address. This matches the implementation		three bytes of the HW address. This matches the implementation
	in Windows 10, and insures that variations will not be used to		in Windows 10, and insures that variations will not be used to
	fingerprint the client software.		fingerprint the client software.
	3. Dropping "This draft updates RFC4361" from the Abstract, since		3. Dropping "This draft updates RFC4361" from the Abstract, since
	this draft does not actually update RFC4361.		this draft does not actually update RFC4361.
	4. Pruned the list of normative references.		4. Pruned the list of normative references.
			Changes from draft-05 to draft-06 address comments received during AD
			evaluation
			1. In Section 3.3, clarified that the requirement to not publish
			addresses from previous networks also applies to private
			addresses.
			2. In Section 3.6, corrected the value of the option number to 55.
			3. In Section 3.9, provided more guidance on disabling the PXE
			option.
			4. In Section 4.2, provided guidance on network identification, with
			references to [RFC6059] and [IEEE8021X].
			5. In Section 4.5, expanded the Identity Association (IA) acronym.
			6. In Section 4.3, spelled out DUID-LLT and tightened the text to
			make randomized identifiers the recommended default.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	skipping to change at page 23, line 16		skipping to change at page 24, line 8
	[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-08 (work in progress),		draft-ietf-6man-default-iids-09 (work in progress),
	October 2015.		January 2016.
	[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-08 (work		draft-ietf-6man-ipv6-address-generation-privacy-08 (work
	in progress), September 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-02		considerations for DHCPv4", draft-ietf-dhc-dhcp-privacy-03
	(work in progress), December 2015.		(work in progress), January 2016.
	[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-02 (work in progress), December 2015.		dhcpv6-privacy-03 (work in progress), January 2016.
	[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-02 (work in progress), October 2015.		dhc-rfc3315bis-02 (work in progress), October 2015.
			[IEEE8021X]
			IEEE Std 802.1X-2010, "IEEE Standards for Local and
			Metropolitan Area Networks: Port based Network Access
			Control", Feb 2010, <http://standards.ieee.org/getieee802/
			download/802.1X-2010.pdf>.
	[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/>.
	[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, DOI 10.17487/RFC2132, March 1997,		Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
	<http://www.rfc-editor.org/info/rfc2132>.		<http://www.rfc-editor.org/info/rfc2132>.
	[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)",
	skipping to change at page 24, line 21		skipping to change at page 25, line 21
	Configuration Protocol (DHCP) Options for the Intel		Configuration Protocol (DHCP) Options for the Intel
	Preboot eXecution Environment (PXE)", RFC 4578,		Preboot eXecution Environment (PXE)", RFC 4578,
	DOI 10.17487/RFC4578, November 2006,		DOI 10.17487/RFC4578, November 2006,
	<http://www.rfc-editor.org/info/rfc4578>.		<http://www.rfc-editor.org/info/rfc4578>.
	[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, DOI 10.17487/RFC4704, October 2006,		Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
	<http://www.rfc-editor.org/info/rfc4704>.		<http://www.rfc-editor.org/info/rfc4704>.
			[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
			Detecting Network Attachment in IPv6", RFC 6059,
			DOI 10.17487/RFC6059, November 2010,
			<http://www.rfc-editor.org/info/rfc6059>.
	[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based		[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based
	DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355,		DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355,
	DOI 10.17487/RFC6355, August 2011,		DOI 10.17487/RFC6355, August 2011,
	<http://www.rfc-editor.org/info/rfc6355>.		<http://www.rfc-editor.org/info/rfc6355>.
	[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M.		[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M.
	Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",		Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",
	RFC 7618, DOI 10.17487/RFC7618, August 2015,		RFC 7618, DOI 10.17487/RFC7618, August 2015,
	<http://www.rfc-editor.org/info/rfc7618>.		<http://www.rfc-editor.org/info/rfc7618>.
End of changes. 27 change blocks.
	38 lines changed or deleted		84 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/