draft-ietf-dhc-anonymity-profile-06.txt		draft-ietf-dhc-anonymity-profile-07.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: August 1, 2016 ISC		Expires: August 18, 2016 ISC
	S. Krishnan		S. Krishnan
	Ericsson		Ericsson
	January 29, 2016		February 15, 2016
	Anonymity profile for DHCP clients		Anonymity profile for DHCP clients
	draft-ietf-dhc-anonymity-profile-06.txt		draft-ietf-dhc-anonymity-profile-07.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 August 1, 2016.		This Internet-Draft will expire on August 18, 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 37		skipping to change at page 2, line 37
	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 . . . . . . . . 14		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 . . . . . . . . . . . . 17
	4.4. Server Identifier Option . . . . . . . . . . . . . . . . 17		4.4. Server Identifier Option . . . . . . . . . . . . . . . . 17
	4.5. Address assignment options . . . . . . . . . . . . . . . 17		4.5. Address assignment options . . . . . . . . . . . . . . . 17
	4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 18		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 . . . . . . . . . . . . . . . . . . 19
	4.6.1. Previous option values . . . . . . . . . . . . . . . 19		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 . . . . . . . . . . . . . . . . . . . 20
	5. Operational Considerations . . . . . . . . . . . . . . . . . 20		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 . . . . . . . . . . . . . . . 21
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	10.1. Normative References . . . . . . . . . . . . . . . . . . 23		10.1. Normative References . . . . . . . . . . . . . . . . . . 23
	10.2. Informative References . . . . . . . . . . . . . . . . . 23		10.2. Informative References . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	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 12, line 12		skipping to change at page 12, line 12
	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.
	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		highly likely to be unique to the current link, using for example a
	local secret and an identifier of the connection.		combination of a local secret and an identifier of the connection.
			The algorithm for combining secret and identifiers described in
			section 5 of [RFC7217] solves a similar problem. The criteria for
			the generation of random numbers are stated in [RFC4086].
	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 55. 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.
	skipping to change at page 16, line 37		skipping to change at page 16, line 39
	fourth type, DUID-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. Syntactically this
	are left up to implementors, but there are several factors should be		identifier will conform to [RFC3315] but its content is meaningless.
	taken into consideration. The DUID type SHOULD be set to 1 (DUID-		The exact details are left up to implementors, but there are several
	LLT). Hardware type SHOULD be set appropriately to the hardware		factors should be taken into consideration. The DUID type SHOULD be
	type. The link address embedded in the LLT SHOULD be set to a		set to 1 (DUID-LLT). Hardware type SHOULD be set appropriately to
	randomized value. Time SHOULD be set to a random timestamp from the		the hardware type. The link address embedded in the LLT SHOULD be
	previous year. Time MAY be set to current time, but this will reveal		set to a randomized value. Time SHOULD be set to a random timestamp
	the fact that the DUID is newly generated, and could provide		from the previous year. Time MAY be set to current time, but this
	information for device fingerprinting.		will reveal the fact that the DUID is newly generated, and could
			provide information for device fingerprinting. The criteria for
			generating highly unique random numbers are listed in [RFC4086].
	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 18, line 35		skipping to change at page 18, line 37
	defined in [RFC4941]. Clients interested in their privacy should not		defined in [RFC4941]. Clients interested in their privacy should not
	publish their IPv6 addresses in the DNS or otherwise associate them		publish their IPv6 addresses in the DNS or otherwise associate them
	with name services, and thus do not normally need two classes of		with name services, and thus do not normally need two classes of
	addresses, one public, one temporary.		addresses, one public, one temporary.
	The use of mechanisms to allocate several IPv6 addresses to a client		The use of mechanisms to allocate several IPv6 addresses to a client
	while preserving privacy is for further study.		while preserving privacy is for further study.
	4.5.2. Prefix delegation		4.5.2. Prefix delegation
	The interaction between prefix delegation and anonymity require		The use of DHCPv6 address assignment option for Prefix Delegation is
	further study. For now, the simple solution is to avoid using prefix		defined in [RFC3633]. Because current host OS implementations do not
	delegation when striving for anonymity. When using the anonymity		typically request prefixes, clients that wish to use DHCPv6 PD - just
	profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of		like clients that wish to use any DHCP or DHCPv6 option that is not
	address assignment.		currently widely used - should recognize that doing so will serve as
			a form of fingerprinting unless or until client use of DHCPv6 PD
			becomes more widespread.
			The anonymity properties of DHCPv6 Prefix Delegation, which use IA_PD
			identity associations, are similar to those of of DHCPv6 address
			assignment using IA_NA identity associations. The IAID could
			potentially be used to identify the client, and a prefix hint sent in
			the IA_PD Prefix option could be used to track the client's previous
			location. Clients that desire anonymity and never request more than
			one prefix SHOULD set the IAID value to zero, as authorized in
			section 6 of [RFC3633], and SHOULD NOT document any previously
			assigned prefix in the IA_PD Prefix option.
	4.6. Option Request Option		4.6. Option Request Option
	The Option Request Option (ORO) is defined in [RFC3315] with option		The Option Request Option (ORO) is defined in [RFC3315] with option
	code 6. It specifies the options that the client is requesting from		code 6. It specifies the options that the client is requesting from
	the server. The choice of requested options and the order of		the server. The choice of requested options and the order of
	encoding of these options in the ORO can be used to fingerprint the		encoding of these options in the ORO can be used to fingerprint the
	client.		client.
	The client willing to protect its privacy SHOULD only request a		The client willing to protect its privacy SHOULD only request a
	skipping to change at page 20, line 17		skipping to change at page 20, line 29
	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.		address.
	Clients using the anonymity profile may be consuming more resources.		Clients using the anonymity profile may be consuming more resources.
	For example when they change link-layer address and request for a new		For example when they change link-layer address and request for a new
	IP, the old one is still marked as leased by the server.		IP, the old one is still marked as leased by the server.
			Some DHCP servers will only give addresses to pre-registered MAC
			addresses, forcing clients to choose between remaining anonymous and
			obtaining connectivity.
	Implementers SHOULD provide a way for clients to control when the		Implementers SHOULD provide a way for clients to control when the
	anonymity profile is used, and when standard behavior is preferred.		anonymity profile is used, and when standard behavior is preferred.
	Implementers MAY implement this control by tying use of the anonymity		Implementers MAY implement this control by tying use of the anonymity
	profile to that of link-layer address randomization.		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.
	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, Brian Carpenter, Lorenzo Colitti, Stephen
	Tushar Gupta, Brian Haberman, Gabriel Montenegro, Marcin Siodelski,		Farrell, Nick Grifka, Tushar Gupta, Brian Haberman, Gabriel
	Dave Thaler, Bernie Volz, and Jun Wu.		Montenegro, Marcin Siodelski, 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 23, line 8		skipping to change at page 23, line 25
	option.		option.
	4. In Section 4.2, provided guidance on network identification, with		4. In Section 4.2, provided guidance on network identification, with
	references to [RFC6059] and [IEEE8021X].		references to [RFC6059] and [IEEE8021X].
	5. In Section 4.5, expanded the Identity Association (IA) acronym.		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		6. In Section 4.3, spelled out DUID-LLT and tightened the text to
	make randomized identifiers the recommended default.		make randomized identifiers the recommended default.
			Changes from draft-06 to draft-07 address comments received during
			IETF last call
			1. Added informative references to [RFC4086] and [RFC7217] in
			Section 3.5.
			2. In Section 4.3, added precision that the generated DUID-LLT are
			meaningless, and added an informative reference to [RFC4086].
			3. In Section 4.5.2, reworked the text to reflect the consensus from
			IPv6 experts and provide informed guidance on the use of the
			option if prefix delegation is required.
			4. In Section 5, noticed servers that might mandate link layer
			address registration.
	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",
	RFC 2131, DOI 10.17487/RFC2131, March 1997,		RFC 2131, DOI 10.17487/RFC2131, March 1997,
	<http://www.rfc-editor.org/info/rfc2131>.		<http://www.rfc-editor.org/info/rfc2131>.
	[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,		[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
	C., and M. Carney, "Dynamic Host Configuration Protocol		C., and M. Carney, "Dynamic Host Configuration Protocol
	for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July		for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
	2003, <http://www.rfc-editor.org/info/rfc3315>.		2003, <http://www.rfc-editor.org/info/rfc3315>.
			[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
			Host Configuration Protocol (DHCP) version 6", RFC 3633,
			DOI 10.17487/RFC3633, December 2003,
			<http://www.rfc-editor.org/info/rfc3633>.
	[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,		Domain Name (FQDN) Option", RFC 4702,
	DOI 10.17487/RFC4702, October 2006,		DOI 10.17487/RFC4702, October 2006,
	<http://www.rfc-editor.org/info/rfc4702>.		<http://www.rfc-editor.org/info/rfc4702>.
	[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,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007,
	<http://www.rfc-editor.org/info/rfc4861>.		<http://www.rfc-editor.org/info/rfc4861>.
	skipping to change at page 24, line 31		skipping to change at page 25, line 19
	[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-03 (work in progress), January 2016.		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-03 (work in progress), February 2016.
	[IEEE8021X]		[IEEE8021X]
	IEEE Std 802.1X-2010, "IEEE Standards for Local and		IEEE Std 802.1X-2010, "IEEE Standards for Local and
	Metropolitan Area Networks: Port based Network Access		Metropolitan Area Networks: Port based Network Access
	Control", Feb 2010, <http://standards.ieee.org/getieee802/		Control", Feb 2010, <http://standards.ieee.org/getieee802/
	download/802.1X-2010.pdf>.		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)",
	RFC 3925, DOI 10.17487/RFC3925, October 2004,		RFC 3925, DOI 10.17487/RFC3925, October 2004,
	<http://www.rfc-editor.org/info/rfc3925>.		<http://www.rfc-editor.org/info/rfc3925>.
			[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
			"Randomness Requirements for Security", BCP 106, RFC 4086,
			DOI 10.17487/RFC4086, June 2005,
			<http://www.rfc-editor.org/info/rfc4086>.
	[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, DOI 10.17487/RFC4361,		Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361,
	February 2006, <http://www.rfc-editor.org/info/rfc4361>.		February 2006, <http://www.rfc-editor.org/info/rfc4361>.
	[RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host		[RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host
	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>.
	skipping to change at page 25, line 31		skipping to change at page 26, line 26
	[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for		[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
	Detecting Network Attachment in IPv6", RFC 6059,		Detecting Network Attachment in IPv6", RFC 6059,
	DOI 10.17487/RFC6059, November 2010,		DOI 10.17487/RFC6059, November 2010,
	<http://www.rfc-editor.org/info/rfc6059>.		<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>.
			[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
			Interface Identifiers with IPv6 Stateless Address
			Autoconfiguration (SLAAC)", RFC 7217,
			DOI 10.17487/RFC7217, April 2014,
			<http://www.rfc-editor.org/info/rfc7217>.
	[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>.
	[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/papers/		<http://www.winlab.rutgers.edu/~gruteser/papers/
End of changes. 19 change blocks.
	30 lines changed or deleted		83 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/