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

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/