draft-ietf-dhc-dhcpv6-privacy-00.txt		draft-ietf-dhc-dhcpv6-privacy-01.txt
	dhc S. Krishnan		dhc S. Krishnan
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational T. Mrugalski		Intended status: Informational T. Mrugalski
	Expires: August 13, 2015 ISC		Expires: February 27, 2016 ISC
	S. Jiang		S. Jiang
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	February 9, 2015		August 26, 2015
	Privacy considerations for DHCPv6		Privacy considerations for DHCPv6
	draft-ietf-dhc-dhcpv6-privacy-00		draft-ietf-dhc-dhcpv6-privacy-01
	Abstract		Abstract
	DHCPv6 is a protocol that is used to provide addressing and		DHCPv6 is a protocol that is used to provide addressing and
	configuration information to IPv6 hosts. This document discusses the		configuration information to IPv6 hosts. This document described the
	various identifiers used by DHCPv6 and the potential privacy issues.		privacy issues associated with the use of DHCPv6 by the Internet
			users. It is intended to be an analysis of the present situation and
			doe not propose any solutions.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 August 13, 2015.		This Internet-Draft will expire on February 27, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Identifiers in DHCPv6 . . . . . . . . . . . . . . . . . . . . 3		3. Identifiers in DHCPv6 . . . . . . . . . . . . . . . . . . . . 4
	3.1. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. DUID . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Client ID Option . . . . . . . . . . . . . . . . . . . . 4		3.2. Client ID Option . . . . . . . . . . . . . . . . . . . . 4
	3.3. IA_NA, IA_TA, IA_PD, IA Address and IA Prefix Options . . 4		3.3. IA_NA, IA_TA, IA_PD, IA Address and IA Prefix Options . . 4
	3.4. Interface ID . . . . . . . . . . . . . . . . . . . . . . 5		3.4. Client FQDN Option . . . . . . . . . . . . . . . . . . . 5
	3.5. Subscriber ID . . . . . . . . . . . . . . . . . . . . . . 5		3.5. Client Link-layer Address Option . . . . . . . . . . . . 5
	3.6. Remote ID . . . . . . . . . . . . . . . . . . . . . . . . 5		3.6. Option Request Option . . . . . . . . . . . . . . . . . . 6
	3.7. Client FQDN Option . . . . . . . . . . . . . . . . . . . 6		3.7. Vendor Class and Vendor-specific Information Options . . 6
	3.8. Client Link-layer Address Option . . . . . . . . . . . . 6		3.8. Civic Location Option . . . . . . . . . . . . . . . . . . 6
	3.9. Option Request Option . . . . . . . . . . . . . . . . . . 6		3.9. Coordinate-Based Location Option . . . . . . . . . . . . 6
	3.10. Vendor Class Option . . . . . . . . . . . . . . . . . . . 6		3.10. Client System Architecture Type Option . . . . . . . . . 7
	3.11. Civic Location Option . . . . . . . . . . . . . . . . . . 7		3.11. Relay Agent Options . . . . . . . . . . . . . . . . . . . 7
	3.12. Coordinate-Based Location Option . . . . . . . . . . . . 7		3.11.1. Subscriber ID . . . . . . . . . . . . . . . . . . . 7
	3.13. Client System Architecture Type Option . . . . . . . . . 7		3.11.2. Interface ID . . . . . . . . . . . . . . . . . . . . 7
	4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 7		3.11.3. Remote ID . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Temporary addresses . . . . . . . . . . . . . . . . . . . 7		3.11.4. Relay-ID Option . . . . . . . . . . . . . . . . . . 8
	4.2. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 8		4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 8
	4.3. Allocation strategies . . . . . . . . . . . . . . . . . . 8		4.1. Temporary addresses . . . . . . . . . . . . . . . . . . . 8
	5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Device type discovery (fingerprinting) . . . . . . . . . 9		4.3. Allocation strategies . . . . . . . . . . . . . . . . . . 9
	5.2. Operating system discovery (fingerprinting) . . . . . . . 10		5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. Finding location information . . . . . . . . . . . . . . 10		5.1. Device type discovery (fingerprinting) . . . . . . . . . 10
	5.4. Finding previously visited networks . . . . . . . . . . . 10		5.2. Operating system discovery (fingerprinting) . . . . . . . 11
	5.5. Finding a stable identity . . . . . . . . . . . . . . . . 10		5.3. Finding location information . . . . . . . . . . . . . . 11
	5.6. Pervasive monitoring . . . . . . . . . . . . . . . . . . 10		5.4. Finding previously visited networks . . . . . . . . . . . 11
	5.7. Finding client's IP address or hostname . . . . . . . . . 10		5.5. Finding a stable identity . . . . . . . . . . . . . . . . 11
	5.8. Correlation of activities over time . . . . . . . . . . . 11		5.6. Pervasive monitoring . . . . . . . . . . . . . . . . . . 11
	5.9. Location tracking . . . . . . . . . . . . . . . . . . . . 11		5.7. Finding client's IP address or hostname . . . . . . . . . 12
	5.10. Leasequery & bulk leasequery . . . . . . . . . . . . . . 11		5.8. Correlation of activities over time . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5.9. Location tracking . . . . . . . . . . . . . . . . . . . . 12
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12		5.10. Leasequery & bulk leasequery . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	10.1. Normative References . . . . . . . . . . . . . . . . . . 12		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		10.1. Normative References . . . . . . . . . . . . . . . . . . 13
			10.2. Informative References . . . . . . . . . . . . . . . . . 14
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	DHCPv6 [RFC3315] is a protocol that is used to provide addressing and		DHCPv6 [RFC3315] is a protocol that is used to provide addressing and
	configuration information to IPv6 hosts. The DHCPv6 protocol uses		configuration information to IPv6 hosts. The DHCPv6 protocol uses
	several identifiers that could become a source for gleaning		several identifiers that could become a source for gleaning
	additional information about the IPv6 host. This information may		information about the IPv6 host. This information may include device
	include device type, operating system information, location(s) that		type, operating system information, location(s) that the device may
	the device may have previously visited, etc. This document discusses		have previously visited, etc. This document discusses the various
	the various identifiers used by DHCPv6 and the potential privacy		identifiers used by DHCPv6 and the potential privacy issues
	issues [RFC6973].		[RFC6973]. In particular, it also takes into consideration the
			problem of pervasive monitoring [RFC7258].
	Future works may propose protocol changes to fix the privacy issues		Future works may propose protocol changes to fix the privacy issues
	that have been analyzed in this document. It is out of scope for		that have been analyzed in this document. Protocol changes are out
	this document.		of scope for this document.
	Editor notes: for now, the document is mainly considering the privacy		The primary focus of this document is around privacy considerations
	of DHCPv6 client. The privacy of DHCPv6 server and relay agent are		for clients to support client mobility and connection to random
	considered less important because they are open for public services.		networks. The privacy or DHCP servers and relay agents are
	However, this may be a subject to change if further study shows		considered less important as they are typically open for public
	opposite result.		services. And, it is generally assumed that relay agent to server
			communication is protected from casual snooping, as that
			communication occurs in the provider's backbone. Nevertheless, the
			topics involving relay agents and servers are explored to some
			degree. However, future work may want to further explore privacy of
			DHCP servers and relay agents.
	2. Terminology		2. Terminology
	This section clarifies the terminology used throughout this document.
	Stable identifier - any property disclosed by a DHCPv6 client that
	does not change over time or changes very infrequently and is unique
	for said client in a given context. Examples include MAC address,
	client-id that does not change or a hostname. Stable identifier may
	or may not be globally unique.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119]. When these		document are to be interpreted as described in [RFC2119]. When these
	words are not in ALL CAPS (such as "should" or "Should"), they have		words are not in ALL CAPS (such as "should" or "Should"), they have
	their usual English meanings, and are not to be interpreted as		their usual English meanings, and are not to be interpreted as
	[RFC2119] key words.		[RFC2119] key words.
			Naming convention from [RFC3315] and related is used throughout this
			document. In addition the following terminology is used:
			Stable identifier - Any property disclosed by a DHCP client that
			does not change over time or changes very infrequently and is
			unique for said client in a given context. Examples may
			include MAC address, client-id or a hostname. Some
			identifiers may be considered stable only under certain
			conditions, for example one client implementation may keep
			its client-id stored in stable storage while other may
			generate it on the fly and use a different one after each
			boot. Stable identifier may or may not be globally unique.
	3. Identifiers in DHCPv6		3. Identifiers in DHCPv6
	There are several identifiers used in DHCPv6. This section provides		There are several identifiers used in DHCPv6. This section provides
	an introduction to the various options that will be used further in		an introduction to the various options that will be used further in
	the document.		the document.
	3.1. DUID		3.1. DUID
	Each DHCPv6 client and server has a DHCPv6 Unique Identifier (DUID)		Each DHCPv6 client and server has a DHCPv6 Unique Identifier (DUID)
	[RFC3315]. The DUID is designed to be unique across all DHCPv6		[RFC3315]. The DUID is designed to be unique across all DHCPv6
	clients and servers, and to remain stable after it has been initially		clients and servers, and to remain stable after it has been initially
	generated. The DUID can be of different forms. Commonly used forms		generated. The DUID can be of different forms. Commonly used forms
	are based on the link-layer address of one of the device's network		are based on the link-layer address of one of the device's network
	interfaces (with or without a timestamp), on the Universally Unique		interfaces (with or without a timestamp), on the Universally Unique
	IDentifier (UUID) [RFC6355]. The default type, recommended by		IDentifier (UUID) [RFC6355]. The default type, defined in
	[RFC3315], is DUID-LLT that is based on link-layer address, which is		Section 9.2 of [RFC3315] is DUID-LLT that is based on link-layer
	commonly implemented in most popular clients.		address. It is commonly implemented in most popular clients.
	It is important to understand DUID lifecycle. Clients and servers		It is important to understand DUID lifecycle. Clients and servers
	are expected to generate their DUID once (during first operation) and		are expected to generate their DUID once (during first operation) and
	store it in a non-volatile storage or use the same deterministic		store it in a non-volatile storage or use the same deterministic
	algorithm to generate the same DUID value again. This means that		algorithm to generate the same DUID value again. This means that
	most implementations will use the available link-layer address during		most implementations will use the available link-layer address during
	its first boot. Even if the administrator enables privacy extensions		its first boot. Even if the administrator enables privacy extensions
	(see [RFC4941]) and its equivalent for link-layer address		(see [RFC4941]) and its equivalent for link-layer address
	randomization, it is likely that those privacy mechanisms were		randomization, it is likely that those privacy mechanisms were
	disabled during the first device boot. Hence the original,		disabled during the first device boot. Hence the original,
	skipping to change at page 5, line 16		skipping to change at page 5, line 22
	each IA_NA, IA_TA and IA_PD options have an IAID field that is unique		each IA_NA, IA_TA and IA_PD options have an IAID field that is unique
	for each client/option type pair. It is up to the client to pick		for each client/option type pair. It is up to the client to pick
	unique IAID values. At least one popular implementation uses last		unique IAID values. At least one popular implementation uses last
	four octets of the link-layer address. In most cases, that means		four octets of the link-layer address. In most cases, that means
	that merely two bytes are missing for a full link-layer address		that merely two bytes are missing for a full link-layer address
	reconstruction. However, the first three octets in a typical link-		reconstruction. However, the first three octets in a typical link-
	layer address are vendor identifier. That can be determined with		layer address are vendor identifier. That can be determined with
	high level of certainty using other means, thus allowing full link-		high level of certainty using other means, thus allowing full link-
	layer address discovery.		layer address discovery.
	3.4. Interface ID		3.4. Client FQDN Option
	A DHCPv6 relay includes the Interface ID [RFC3315] option to identify
	the interface on which it received the client message that is being
	relayed.
	Although in principle Interface ID can be arbitrarily long with
	completely random values, it is often a text string that includes the
	relay agent name followed by interface name. This can be used for
	fingerprinting the relay or determining client's point of attachment.
	3.5. Subscriber ID
	A DHCPv6 relay includes a Subscriber ID option [RFC4580] to associate
	some provider-specific information with clients' DHCPv6 messages that
	is independent of the physical network configuration.
	In many deployments, the relay agent that inserts this option is
	configured to use client's link-layer address as Subscriber ID.
	3.6. Remote ID
	A DHCPv6 relay includes a Remote ID option [RFC4649] to identify the
	remote host end of the circuit.
	The remote-id is vendor specific, for which the vendor is indicated
	in the enterprise-number field. The remote-id field may encode the
	information that identified the DHCPv6 clients:
	o a "caller ID" telephone number for dial-up connection
	o a "user name" prompted for by a Remote Access Server
	o a remote caller ATM address o a "modem ID" of a cable data modem
	o the remote IP address of a point-to-point link
	o an interface or port identifier
	3.7. Client FQDN Option
	The Client Fully Qualified Domain Name (FQDN) option [RFC4704] is		The Client Fully Qualified Domain Name (FQDN) option [RFC4704] is
	used by DHCPv6 clients and servers to exchange information about the		used by DHCPv6 clients and servers to exchange information about the
	client's fully qualified domain name and about who has the		client's fully qualified domain name and about who has the
	responsibility for updating the DNS with the associated AAAA and PTR		responsibility for updating the DNS with the associated AAAA and PTR
	RRs.		RRs.
	A client can use this option to convey all or part of its domain name		A client can use this option to convey all or part of its domain name
	to a DHCPv6 server for the IPv6-address-to-FQDN mapping. In most		to a DHCPv6 server for the IPv6-address-to-FQDN mapping. In most
	case a client sends its hostname as a hint for the server. The		case a client sends its hostname as a hint for the server. The
	DHCPv6 server MAY be configured to modify the supplied name or to		DHCPv6 server MAY be configured to modify the supplied name or to
	substitute a different name. The server should send its notion of		substitute a different name. The server should send its notion of
	the complete FQDN for the client in the Domain Name field.		the complete FQDN for the client in the Domain Name field.
	3.8. Client Link-layer Address Option		3.5. Client Link-layer Address Option
	The Client link-layer address option [RFC6939] is used by first-hop		The Client link-layer address option [RFC6939] is used by first-hop
	DHCPv6 relays to provide the client's link-layer address towards the		DHCPv6 relays to provide the client's link-layer address towards the
	server.		server.
	DHCPv6 relay agents that receive messages originating from clients		DHCPv6 relay agents that receive messages originating from clients
	may include the link-layer source address of the received DHCPv6		may include the link-layer source address of the received DHCPv6
	message in the Client Link-Layer Address option, in relayed DHCPv6		message in the Client Link-Layer Address option, in relayed DHCPv6
	Relay-Forward messages.		Relay-Forward messages.
	3.9. Option Request Option		3.6. Option Request Option
	DHCPv6 clients include an Option Request option [RFC3315] in DHCPv6		DHCPv6 clients include an Option Request option [RFC3315] in DHCPv6
	messages to inform the server about options the client wants the		messages to inform the server about options the client wants the
	server to send to the client.		server to send to the client.
	The content of an Option Request option are the option codes for an		The content of an Option Request option are the option codes for an
	option requested by the client. The client may additionally include		option requested by the client. The client may additionally include
	instances of those options that are identified in the Option Request		instances of those options that are identified in the Option Request
	option, with data values as hints to the server about parameter		option, with data values as hints to the server about parameter
	values the client would like to have returned.		values the client would like to have returned.
	3.10. Vendor Class Option		3.7. Vendor Class and Vendor-specific Information Options
	This Vendor Class option [RFC3315] is used by a DHCPv6 client to		The Vendor Class option, defined in Section 22.16 of [RFC3315] is
	identify the vendor that manufactured the hardware on which the		used by a DHCPv6 client to identify the vendor that manufactured the
	client is running.		hardware on which the client is running.
			The Vendor-specific Information Option, defined in Section 22.17 of
			[RFC3315] includes enterprise number, which identifies the client's
			vendor and often includes a number of additional parameters that are
			specific to a given vendor. That may include any type of information
			the vendor deems useful. It should be noted that this information
			may be present (and different) in both directions: client to server
			and server to client communications.
	The information contained in the data area of this option is		The information contained in the data area of this option is
	contained in one or more opaque fields that identify details of the		contained in one or more opaque fields that identify details of the
	hardware configuration, for example, the version of the operating		hardware configuration, for example, the version of the operating
	system the client is running or the amount of memory installed on the		system the client is running or the amount of memory installed on the
	client.		client.
	3.11. Civic Location Option		3.8. Civic Location Option
	DHCPv6 servers use the Civic Location option [RFC4776] to delivery of		DHCPv6 servers use the Civic Location option [RFC4776] to delivery of
	location information (the civic and postal addresses) from the DHCPv6		location information (the civic and postal addresses) from the DHCPv6
	server to the DHCPv6 clients. It may refer to three locations: the		server to the DHCPv6 clients. It may refer to three locations: the
	location of the DHCPv6 server, the location of the network element		location of the DHCPv6 server, the location of the network element
	believed to be closest to the client, or the location of the client,		believed to be closest to the client, or the location of the client,
	identified by the "what" element within the option.		identified by the "what" element within the option.
	3.12. Coordinate-Based Location Option		3.9. Coordinate-Based Location Option
	The GeoLoc options [RFC6225] is used by DHCPv6 server to provide the		The GeoLoc options [RFC6225] is used by DHCPv6 server to provide the
	coordinate- based geographic location information to the DHCPv6		coordinate- based geographic location information to the DHCPv6
	clients. It enable a DHCPv6 client to obtain its location.		clients. It enable a DHCPv6 client to obtain its location.
	After the relevant DHCPv6 exchanges have taken place, the location		After the relevant DHCPv6 exchanges have taken place, the location
	information is stored on the end device rather than somewhere else,		information is stored on the end device rather than somewhere else,
	where retrieving it might be difficult in practice.		where retrieving it might be difficult in practice.
	3.13. Client System Architecture Type Option		3.10. Client System Architecture Type Option
	The Client System Architecture Type option [RFC5970] is used by		The Client System Architecture Type option [RFC5970] is used by
	DHCPv6 client to send a list of supported architecture types to the		DHCPv6 client to send a list of supported architecture types to the
	DHCPv6 server. It is used to provide configuration information for a		DHCPv6 server. It is used to provide configuration information for a
	node that must be booted using the network rather than from local		node that must be booted using the network rather than from local
	storage.		storage.
			3.11. Relay Agent Options
			A DHCPv6 relay agent may include a number of options. Those option
			contain information that can be used to identify the client. Those
			options are almost exclusively exchanged between the relay agent and
			the server, thus never leaving the operators network. In particular,
			they're almost never present in the last wireless hop in case of WiFi
			networks. The only exception to that rule is somewhat infrequently
			used Relay Supplied Options option [RFC6422]. This fact implies that
			the threat model related relay options is slightly different.
			Traffic sniffing at the last hop and related class of attacks
			typically do not apply. On the other hand, all attacks that involve
			operator's intfrastructure (either willing or coerced cooperation or
			infrastructure being compromised) usually apply.
			The following subsections describe various options inserted by the
			relay agents.
			3.11.1. Subscriber ID
			A DHCPv6 relay may include a Subscriber ID option [RFC4580] to
			associate some provider-specific information with clients' DHCPv6
			messages that is independent of the physical network configuration.
			In many deployments, the relay agent that inserts this option is
			configured to use client's link-layer address as Subscriber ID.
			3.11.2. Interface ID
			A DHCPv6 relay includes the Interface ID [RFC3315] option to identify
			the interface on which it received the client message that is being
			relayed.
			Although in principle Interface ID can be arbitrarily long with
			completely random values, it is often a text string that includes the
			relay agent name followed by interface name. This can be used for
			fingerprinting the relay or determining client's point of attachment.
			3.11.3. Remote ID
			A DHCPv6 relay includes a Remote ID option [RFC4649] to identify the
			remote host end of the circuit.
			The remote-id is vendor specific, for which the vendor is indicated
			in the enterprise-number field. The remote-id field may encode the
			information that identified the DHCPv6 clients:
			o a "caller ID" telephone number for dial-up connection
			o a "user name" prompted for by a Remote Access Server
			o a remote caller ATM address o a "modem ID" of a cable data modem
			o the remote IP address of a point-to-point link
			o an interface or port identifier
			3.11.4. Relay-ID Option
			Relay agent may include Relay-ID [RFC5460], which contains a unique
			relay agent identifier. While its intended use is to provide
			additional information for the server, so it would be able to respond
			to leasequeries later, this information can be also used to identify
			client's location within the network.
	4. Existing Mechanisms That Affect Privacy		4. Existing Mechanisms That Affect Privacy
	This section describes available DHCPv6 mechanisms that one can use		This section describes available DHCPv6 mechanisms that one can use
	to protect or enhance one's privacy.		to protect or enhance one's privacy.
	4.1. Temporary addresses		4.1. Temporary addresses
	[RFC3315] defines a mechanism for a client to request temporary		[RFC3315] defines a mechanism for a client to request temporary
	addresses. The idea behind temporary addresses is that a client can		addresses. The idea behind temporary addresses is that a client can
	request a temporary address for a specific purpose, use it, and then		request a temporary address for a specific purpose, use it, and then
	skipping to change at page 8, line 43		skipping to change at page 9, line 42
	implications.		implications.
	Iterative allocation - a server may choose to allocate addresses one		Iterative allocation - a server may choose to allocate addresses one
	by one. That strategy has the benefit of being very fast, thus can		by one. That strategy has the benefit of being very fast, thus can
	be favored in deployments that prefer performance. However, it makes		be favored in deployments that prefer performance. However, it makes
	the resources very predictable. Also, since the resources allocated		the resources very predictable. Also, since the resources allocated
	tend to be clustered at the beginning of available pool, it makes		tend to be clustered at the beginning of available pool, it makes
	scanning attacks much easier.		scanning attacks much easier.
	Identifier-based allocation - a server may choose to allocate an		Identifier-based allocation - a server may choose to allocate an
	address that is based on one of available identifiers, e.g. IID or		address that is based on one of available identifiers, e.g. IID or
	MAC address. This has a property of being convenient for converting		MAC address. This has a property of being convenient for converting
	IP address to/from other identifiers, especially if the identifier is		IP address to/from other identifiers, especially if the identifier is
	or contains MAC address. It is also convenient, as returning client		or contains MAC address. It is also convenient, as returning client
	is very likely to get the same address, even if the server does not		is very likely to get the same address, even if the server does not
	store previous client's address. Those properties are convenient for		store previous client's address. Those properties are convenient for
	system administrators, so DHCPv6 server implementors are sometimes		system administrators, so DHCPv6 server implementors are sometimes
	requested to implement it. There is at least one implementation that		requested to implement it. There is at least one implementation that
	supports it. On the other hand, the downside of such allocation is		supports it. On the other hand, the downside of such allocation is
	that the client now discloses its identifier in its IPv6 address to		that the client now discloses its identifier in its IPv6 address to
	all services it connects to. That means that correlation of		all services it connects to. That means that correlation of
	skipping to change at page 9, line 43		skipping to change at page 10, line 42
	way, e.g. client's address can be randomized, but it still can leak		way, e.g. client's address can be randomized, but it still can leak
	its MAC address in client-id option.		its MAC address in client-id option.
	Other allocation strategies may be implemented.		Other allocation strategies may be implemented.
	5. Attacks		5. Attacks
	5.1. Device type discovery (fingerprinting)		5.1. Device type discovery (fingerprinting)
	The type of device used by the client can be guessed by the attacker		The type of device used by the client can be guessed by the attacker
	using the Vendor Class option, the Client Link-layer Address option,		using the Vendor Class option, Vendor-specific Information option,
	and by parsing the Client ID option. All of those options may		the Client Link-layer Address option, and by parsing the Client ID
	contain OUI (Organizationally Unique Identifier) that represents the		option. All of those options may contain OUI (Organizationally
	device's vendor. That knowledge can be used for device-specific		Unique Identifier) that represents the device's vendor. That
	vulnerability exploitation attacks. See Section 3.4 of		knowledge can be used for device-specific vulnerability exploitation
			attacks. See Section 3.4 of
	[I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion		[I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion
	about this type of attack.		about this type of attack.
	5.2. Operating system discovery (fingerprinting)		5.2. Operating system discovery (fingerprinting)
	The operating system running on a client can be guessed using the		The operating system running on a client can be guessed using the
	Vendor Class option, the Client System Architecture Type option, or		Vendor Class option, the Vendor-specific Information option, the
	by using fingerprinting techniques on the combination of options		Client System Architecture Type option, or by using fingerprinting
	requested using the Option Request option. See Section 3.4 of		techniques on the combination of options requested using the Option
			Request option. See Section 3.4 of
	[I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion		[I-D.ietf-6man-ipv6-address-generation-privacy] for a discussion
	about this type of attack.		about this type of attack.
	5.3. Finding location information		5.3. Finding location information
	The location information can be obtained by the attacker by many		The location information can be obtained by the attacker by many
	means. The most direct way to obtain this information is by looking		means. The most direct way to obtain this information is by looking
	into a server initiated message that contains the Civic Location or		into a message originating from the server server that contains the
	GeoLoc option. It can also be indirectly inferred using the Remote		Civic Location or GeoLoc option. It can also be indirectly inferred
	ID Option (e.g. using a telephone number), the Interface ID option		using the Remote ID Option, the Interface ID option (e.g. if an
	(e.g. if an access circuit on an Access Node corresponds to a civic		access circuit on an Access Node corresponds to a civic location), or
	location), or the Subscriber ID Option (if the attacker has access to		the Subscriber ID Option (if the attacker has access to subscriber
	subscriber info).		info).
	5.4. Finding previously visited networks		5.4. Finding previously visited networks
	When DHCPv6 clients connect to a network, they attempt to obtain the		When DHCPv6 clients connect to a network, they attempt to obtain the
	same address they had used before they attached to the network. They		same address they had used before they attached to the network. They
	do this by putting the previously assigned address(es) in the IA		do this by putting the previously assigned address(es) in the IA
	Address Option(s) inside the IA_NA, IA_TA. By observing these		Address Option(s) inside the IA_NA, IA_TA. By observing these
	addresses, an attacker can identify the network the client had		addresses, an attacker can identify the network the client had
	previously visited.		previously visited.
	skipping to change at page 10, line 46		skipping to change at page 11, line 47
	An attacker might use a stable identity gleaned from DHCPv6 messages		An attacker might use a stable identity gleaned from DHCPv6 messages
	to correlate activities of a given client on unrelated networks. The		to correlate activities of a given client on unrelated networks. The
	Client FQDN option, the Subscriber ID Option and the Client ID		Client FQDN option, the Subscriber ID Option and the Client ID
	options can serve as long lived identifiers of DHCPv6 clients. The		options can serve as long lived identifiers of DHCPv6 clients. The
	Client FQDN option can also provide an identity that can easily be		Client FQDN option can also provide an identity that can easily be
	correlated with web server activity logs.		correlated with web server activity logs.
	5.6. Pervasive monitoring		5.6. Pervasive monitoring
	This is an enhancement, or a combination of most aforementioned		This is an enhancement, or a combination of most aforementioned
	mechanisms. Operator, who controls non-trivial number of access		mechanisms. Operator (or anyone who has access to its data), who
	points or network segments, may use obtained information about a		controls non-trivial number of access points or network segments, may
	single client and observer client's habits.		use obtained information about a single client and observer client's
			habits.
	5.7. Finding client's IP address or hostname		5.7. Finding client's IP address or hostname
	Many DHCPv6 deployments use DNS Updates [RFC4704] that put client's		Many DHCPv6 deployments use DNS Updates [RFC4704] that put client's
	information (current IP address, client's hostname). Client ID is		information (current IP address, client's hostname) into DNS, where
	also disclosed, able it in not easily accessible form (SHA-256 digest		it is easily accessible by anyone interested. Client ID is also
	of the client-id). Although SHA-256 is irreversible, so DHCPv6		disclosed, albeit in not easily accessible form (SHA-256 digest of
	client ID can't be converted back to client-id. However, SHA-256		the client-id). As SHA-256 is considered irreversible, DHCID can't
	digest can be used as a unique identifier that is accessible by any		be converted back to client-id. However, SHA-256 digest can be used
	host.		as an unique identifier that is accessible by any host.
	5.8. Correlation of activities over time		5.8. Correlation of activities over time
	As with other identifiers, an IPv6 address can be used to correlate		As with other identifiers, an IPv6 address can be used to correlate
	the activities of a host for at least as long as the lifetime of the		the activities of a host for at least as long as the lifetime of the
	address. If that address was generated from some other, stable		address. If that address was generated from some other, stable
	identifier and that generation scheme can be deducted by an attacker,		identifier and that generation scheme can be deducted by an attacker,
	the duration of correlation attack extends to that identifier. In		the duration of correlation attack extends to that identifier. In
	many cases, its lifetime is equal to the lifetime of the device		many cases, its lifetime is equal to the lifetime of the device
	itself. See Section 3.1 of		itself. See Section 3.1 of
	skipping to change at page 11, line 35		skipping to change at page 12, line 38
	If a stable identifier is used for assigning an address and such		If a stable identifier is used for assigning an address and such
	mapping is discovered by an attacker (e.g. a server that uses IEEE-		mapping is discovered by an attacker (e.g. a server that uses IEEE-
	identifier-based IID to generate IPv6 address), all scenarios		identifier-based IID to generate IPv6 address), all scenarios
	discussed in Section 3.2 of		discussed in Section 3.2 of
	[I-D.ietf-6man-ipv6-address-generation-privacy] apply. In particular		[I-D.ietf-6man-ipv6-address-generation-privacy] apply. In particular
	both passive (a service that the client connects to can log client's		both passive (a service that the client connects to can log client's
	address and draw conclusions regarding its location and movement		address and draw conclusions regarding its location and movement
	patterns based on prefix it is connecting from) and active (attacker		patterns based on prefix it is connecting from) and active (attacker
	can send ICMPv6 echo requests or other probe packets to networks of		can send ICMPv6 echo requests or other probe packets to networks of
	suspected client locations).		suspected client locations) can be used. To give specific example,
			by accessing a social portal from tomek-
			laptop.coffee.somecity.com.example, tomek-
			laptop.mycompany.com.example and tomek-laptop.myisp.example.com, the
			portal administrator can draw conclusions about tomek-laptop's owner
			current location and his habits.
	5.10. Leasequery & bulk leasequery		5.10. Leasequery & bulk leasequery
	Attackers may pretend as an access concentrator, either DHCPv6 relay		Attackers may pretend as an access concentrator, either DHCPv6 relay
	agent or DHCPv6 client, to obtain location information directly from		agent or DHCPv6 client, to obtain location information directly from
	the DHCP server(s) using the DHCPv6 Leasequery [RFC5007] mechanism.		the DHCP server(s) using the DHCPv6 Leasequery [RFC5007] mechanism.
	Location information is information needed by the access concentrator		Location information is information needed by the access concentrator
	to forward traffic to a broadband-accessible host. This information		to forward traffic to a broadband-accessible host. This information
	includes knowledge of the host hardware address, the port or virtual		includes knowledge of the host hardware address, the port or virtual
	circuit that leads to the host, and/or the hardware address of the		circuit that leads to the host, and/or the hardware address of the
	intervening subscriber modem.		intervening subscriber modem.
	Furthermore, the attackers may use DHCPv6 bulk leasequery [RFC5460]		Furthermore, the attackers may use DHCPv6 bulk leasequery [RFC5460]
	mechanism to obtain bulk information about DHCPv6 bindings, even		mechanism to obtain bulk information about DHCPv6 bindings, even
	without knowing the target bindings.		without knowing the target bindings.
			Additionally, active leasequery
			[I-D.ietf-dhc-dhcpv6-active-leasequery] is a mechanism for
			subscribing to DHCPv6 lease update changes in near real-time. The
			intent of this mechanism is to update operator's database, but if
			misused, an attacker could defeat server's authentication mechanisms
			and subscribe to all updates. He then could continue receiving
			updates, without any need for local presence.
	6. Security Considerations		6. Security Considerations
	TBD		In current practice, the client privacy and the client authentication
			are mutually exclusive. The client authentication procedure reveals
			additional client information in their certificates/identifiers.
			Full privacy for the clients may mean the clients are also anonymous
			for the server and the network.
	7. Privacy Considerations		7. Privacy Considerations
	This document at its entirety discusses privacy considerations in		This document at its entirety discusses privacy considerations in
	DHCPv6. As such, no separate section about this is needed.		DHCPv6. As such, no dedicated section about this is needed.
	8. IANA Considerations		8. IANA Considerations
	This draft does not request any IANA action.		This draft does not request any IANA action.
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thanks the valuable comments made by		The authors would like to thanks the valuable comments made by
	Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian		Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian
	Schaefer and other members of DHC WG.		Schaefer and other members of DHC WG.
	This document was produced using the xml2rfc tool [RFC2629].		This document was produced using the xml2rfc tool [RFC2629].
	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, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
	and M. Carney, "Dynamic Host Configuration Protocol for		C., and M. Carney, "Dynamic Host Configuration Protocol
	IPv6 (DHCPv6)", RFC 3315, July 2003.		for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
			2003, <http://www.rfc-editor.org/info/rfc3315>.
			[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
			Morris, J., Hansen, M., and R. Smith, "Privacy
			Considerations for Internet Protocols", RFC 6973,
			DOI 10.17487/RFC6973, July 2013,
			<http://www.rfc-editor.org/info/rfc6973>.
			[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
			Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
			2014, <http://www.rfc-editor.org/info/rfc7258>.
	10.2. Informative References		10.2. Informative References
	[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-03 (work		draft-ietf-6man-ipv6-address-generation-privacy-07 (work
	in progress), January 2015.		in progress), June 2015.
			[I-D.ietf-dhc-dhcpv6-active-leasequery]
			Dushyant, D., Kinnear, K., and D. Kukrety, "DHCPv6 Active
			Leasequery", draft-ietf-dhc-dhcpv6-active-leasequery-04
			(work in progress), July 2015.
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,		[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
	June 1999.		DOI 10.17487/RFC2629, June 1999,
			<http://www.rfc-editor.org/info/rfc2629>.
	[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic		[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
	Host Configuration Protocol (DHCP) version 6", RFC 3633,		Host Configuration Protocol (DHCP) version 6", RFC 3633,
	December 2003.		DOI 10.17487/RFC3633, December 2003,
			<http://www.rfc-editor.org/info/rfc3633>.
	[RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6		[RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
	(DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June		(DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
	2006.		DOI 10.17487/RFC4580, June 2006,
			<http://www.rfc-editor.org/info/rfc4580>.
	[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6		[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
	(DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August		(DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
	2006.		DOI 10.17487/RFC4649, August 2006,
			<http://www.rfc-editor.org/info/rfc4649>.
	[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, DOI 10.17487/RFC4704, October 2006,
			<http://www.rfc-editor.org/info/rfc4704>.
	[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol		[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
	(DHCPv4 and DHCPv6) Option for Civic Addresses		(DHCPv4 and DHCPv6) Option for Civic Addresses
	Configuration Information", RFC 4776, November 2006.		Configuration Information", RFC 4776,
			DOI 10.17487/RFC4776, November 2006,
			<http://www.rfc-editor.org/info/rfc4776>.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy		[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	Extensions for Stateless Address Autoconfiguration in		Extensions for Stateless Address Autoconfiguration in
	IPv6", RFC 4941, September 2007.		IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
			<http://www.rfc-editor.org/info/rfc4941>.
	[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,		[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
	"DHCPv6 Leasequery", RFC 5007, September 2007.		"DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007,
			September 2007, <http://www.rfc-editor.org/info/rfc5007>.
	[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February		[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
	2009.		DOI 10.17487/RFC5460, February 2009,
			<http://www.rfc-editor.org/info/rfc5460>.
	[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6		[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
	Options for Network Boot", RFC 5970, September 2010.		Options for Network Boot", RFC 5970, DOI 10.17487/RFC5970,
			September 2010, <http://www.rfc-editor.org/info/rfc5970>.
	[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic		[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed.,
	Host Configuration Protocol Options for Coordinate-Based		"Dynamic Host Configuration Protocol Options for
	Location Configuration Information", RFC 6225, July 2011.		Coordinate-Based Location Configuration Information",
			RFC 6225, DOI 10.17487/RFC6225, July 2011,
			<http://www.rfc-editor.org/info/rfc6225>.
	[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, August		DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355,
	2011.		DOI 10.17487/RFC6355, August 2011,
			<http://www.rfc-editor.org/info/rfc6355>.
	[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer		[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options",
	Address Option in DHCPv6", RFC 6939, May 2013.		RFC 6422, DOI 10.17487/RFC6422, December 2011,
			<http://www.rfc-editor.org/info/rfc6422>.
	[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
	Morris, J., Hansen, M., and R. Smith, "Privacy		Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
	Considerations for Internet Protocols", RFC 6973, July		May 2013, <http://www.rfc-editor.org/info/rfc6939>.
	2013.
	Authors' Addresses		Authors' Addresses
	Suresh Krishnan		Suresh Krishnan
	Ericsson		Ericsson
	8400 Decarie Blvd.		8400 Decarie Blvd.
	Town of Mount Royal, QC		Town of Mount Royal, QC
	Canada		Canada
	Phone: +1 514 345 7900 x42871		Phone: +1 514 345 7900 x42871
	Email: suresh.krishnan@ericsson.com		Email: suresh.krishnan@ericsson.com
	Tomek Mrugalski		Tomek Mrugalski
	skipping to change at page 14, line 19		skipping to change at page 16, line 26
	Phone: +1 514 345 7900 x42871		Phone: +1 514 345 7900 x42871
	Email: suresh.krishnan@ericsson.com		Email: suresh.krishnan@ericsson.com
	Tomek Mrugalski		Tomek Mrugalski
	Internet Systems Consortium, Inc.		Internet Systems Consortium, Inc.
	950 Charter Street		950 Charter Street
	Redwood City, CA 94063		Redwood City, CA 94063
	USA		USA
	Phone: +1 650 423 1345
	Email: tomasz.mrugalski@gmail.com		Email: tomasz.mrugalski@gmail.com
	Sheng Jiang		Sheng Jiang
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	Q14, Huawei Campus, No.156 BeiQing Road		Q14, Huawei Campus, No.156 BeiQing Road
	Hai-Dian District, Beijing 100095		Hai-Dian District, Beijing 100095
	P.R. China		P.R. China
	Email: jiangsheng@huawei.com		Email: jiangsheng@huawei.com
End of changes. 52 change blocks.
	169 lines changed or deleted		272 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/