draft-ietf-dhc-anonymity-profile-00.txt   draft-ietf-dhc-anonymity-profile-01.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: November 19, 2015 S. Krishnan Expires: January 1, 2016 S. Krishnan
Ericsson Ericsson
May 18, 2015 June 30, 2015
Anonymity profile for DHCP clients Anonymity profile for DHCP clients
draft-ietf-dhc-anonymity-profile-00.txt draft-ietf-dhc-anonymity-profile-01.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 November 19, 2015. This Internet-Draft will expire on January 1, 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 . . . . . . . . . . . 7 2.7. What about privacy for DHCP servers . . . . . . . . . . . 8
3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8 3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8
3.1. Client IP address field . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 9
3.4. Client Identifier Option . . . . . . . . . . . . . . . . 9 3.4. Client Identifier Option . . . . . . . . . . . . . . . . 10
3.5. Host Name Option . . . . . . . . . . . . . . . . . . . . 10 3.5. Host Name Option . . . . . . . . . . . . . . . . . . . . 11
3.6. Client FQDN Option . . . . . . . . . . . . . . . . . . . 11 3.6. Client FQDN Option . . . . . . . . . . . . . . . . . . . 11
3.7. UUID/GUID-based Client Identifier Option . . . . . . . . 11 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 . . . . . . . . . . . 12
4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 12 4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 12
4.1. Do not send Confirm messages . . . . . . . . . . . . . . 12 4.1. Do not send Confirm messages, unless really sure where . 13
4.2. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 13 4.2. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 13
4.2.1. Anonymous Information-Request . . . . . . . . . . . . 13 4.2.1. Anonymous Information-Request . . . . . . . . . . . . 14
4.3. Server Identifier Option . . . . . . . . . . . . . . . . 14 4.3. Server Identifier Option . . . . . . . . . . . . . . . . 14
4.4. Address assignment options . . . . . . . . . . . . . . . 14 4.4. Address assignment options . . . . . . . . . . . . . . . 15
4.4.1. Obtain temporary addresses . . . . . . . . . . . . . 14 4.4.1. Obtain temporary addresses . . . . . . . . . . . . . 15
4.5. Option Request Option . . . . . . . . . . . . . . . . . . 15 4.5. Option Request Option . . . . . . . . . . . . . . . . . . 16
4.5.1. Previous option values . . . . . . . . . . . . . . . 15 4.5.1. Previous option values . . . . . . . . . . . . . . . 16
4.6. Authentication Option . . . . . . . . . . . . . . . . . . 16 4.6. Authentication Option . . . . . . . . . . . . . . . . . . 16
4.7. User and Vendor Class DHCPv6 options . . . . . . . . . . 16 4.7. User and Vendor Class DHCPv6 options . . . . . . . . . . 17
4.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 16 4.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 17
5. Operational Considerations . . . . . . . . . . . . . . . . . 16 5. Operational Considerations . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Changes from previous versions . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 7, line 34 skipping to change at page 7, line 34
randomized MAC address to the network interface. Once that decision randomized MAC address to the network interface. Once that decision
is made, the following guidelines will avoid leakage of identity in is made, the following guidelines will avoid leakage of identity in
DHCP parameters or in assigned addresses. DHCP parameters or in assigned addresses.
There may be rare situations where the clients want anonymity to There may be rare situations where the clients want anonymity to
attackers but not to their DHCP server. These clients should still attackers but not to their DHCP server. These clients should still
use MAC Address randomization to hide from observers, and some form use MAC Address randomization to hide from observers, and some form
of encrypted communication to the DHCP server. This scenario is not of encrypted communication to the DHCP server. This scenario is not
yet supported in this document. yet supported in this document.
To preserve anonymity, the clients need to not use stable values for
the client identifiers. This is clearly a tradeoff, because a stable
client identifier guarantees that the client will receive consistent
parameters over time. An example is given in
[I-D.ietf-dhc-dynamic-shared-v4allocation], where the client
identifier is used to guarantee that the same client will always get
the same combination of IP address and port range. Static clients
benefit most from stable parameters, and can often be already
identified by physical connection layer parameters. These static
clients will normally not use the anonymity profile. Mobile clients,
in contrast, have the option of using the anonymity profile in
conjunction with [I-D.ietf-dhc-dynamic-shared-v4allocation] if they
are more concerned with privacy protection than with stable
parameters.
2.7. What about privacy for DHCP servers 2.7. What about privacy for DHCP servers
This document only provides recommendations for DHCP clients. The This document only provides recommendations for DHCP clients. The
main target are DHCP clients used in mobile devices. Such devices main target are DHCP clients used in mobile devices. Such devices
are a tempting target for various monitoring systems, and providing are a tempting target for various monitoring systems, and providing
them with a simple anonymity solution is urgent. We can argue that them with a simple anonymity solution is urgent. We can argue that
some mobile devices embed DHCP servers, and that providing solutions some mobile devices embed DHCP servers, and that providing solutions
for such devices is also quite important. Two plausible examples for such devices is also quite important. Two plausible examples
would be a DHCP server for a car network, or a DHCP server for a would be a DHCP server for a car network, or a DHCP server for a
mobile hot spot. However, mobile servers get a lot of privacy mobile hot spot. However, mobile servers get a lot of privacy
skipping to change at page 10, line 30 skipping to change at page 10, line 47
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.
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 construct a non-revealing identifier. If anonymity is desired in
such networks, the client SHOULD pick a random identifier that is
unique to the current link, using for example a combination of a
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.
Depending on implementations, the option value can carry either a Depending on implementations, the option value can carry either a
fully qualified domain name such as "node1984.example.com," or a fully qualified domain name such as "node1984.example.com," or a
simple host name such as "node1984." The host name is commonly used simple host name such as "node1984." The host name is commonly used
by the DHCP server to identify the host, and also to automatically by the DHCP server to identify the host, and also to automatically
update the address of the host in local name services. update the address of the host in local name services.
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 MAY avoid sending the When using the anonymity profile, DHCP clients SHOULD avoid sending
host name option. If they chose to send the option, DHCP clients the 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, so it qualified domain name, and MUST obfuscate the host name value.
could not be linked to anything other than the link layer address.
When obfuscating the host name, DHCP clients SHOULD set the host name When obfuscating the host name, DHCP clients SHOULD construct a
value to a hexadecimal representation of the link layer address that randomized host name by computing a secure hash of a local secret and
will be used in the underlying connection. They MAY choose another of the link layer address that will be used in the underlying
convention in rare cases, for example in multi-homed scenarios. connection, and then use as the name the hexadecimal representation
of the first 6 bytes of the hash. This procedure ensures that the
random name will not reveal the underlying link layer address.
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 12, line 45 skipping to change at page 13, line 20
configuration, because stateless configuration requires fewer configuration, because stateless configuration requires fewer
information disclosure than stateful configuration. information disclosure than stateful configuration.
When using the anonymity profile, DHCPv6 clients carefully select When using the anonymity profile, DHCPv6 clients carefully select
DHCPv6 options used in the various messages that they sent. The list DHCPv6 options used in the various messages that they sent. The list
of options that are mandatory or optional for each message is of options that are mandatory or optional for each message is
specified in [RFC3315]. Some of these options have specific specified in [RFC3315]. Some of these options have specific
implications on anonymity. The following sections provide guidance implications on anonymity. The following sections provide guidance
on the choice of option values when using the anonymity profile. on the choice of option values when using the anonymity profile.
4.1. Do not send Confirm messages 4.1. Do not send Confirm messages, unless really sure where
The [RFC3315] requires clients to send a Confirm message when they The [RFC3315] requires clients to send a Confirm message when they
attach to a new link to verify whether the addressing and attach to a new link to verify whether the addressing and
configuration information they previously received is still valid. configuration information they previously received is still valid.
This requirement was relaxed in [I-D.ietf-dhc-rfc3315bis]. When This requirement was relaxed in [I-D.ietf-dhc-rfc3315bis]. When
these clients send Confirm messages, they include any IAs assigned to these clients send Confirm messages, they include any IAs assigned to
the interface that may have moved to a new link, along with the the interface that may have moved to a new link, along with the
addresses associated with those IAs. By examining the addresses in addresses associated with those IAs. By examining the addresses in
the Confirm message an attacker can trivially identify the previous the Confirm message an attacker can trivially identify the previous
point(s) of attachment. point(s) of attachment.
Clients interested in protecting their privacy SHOULD NOT send Clients interested in protecting their privacy SHOULD NOT send
Confirm messages and instead directly try to acquire addresses on the Confirm messages and instead directly try to acquire addresses on the
new link. new link. However, not sending confirm messages can result in
connectivity hiatus in some scenarios, e.g. roaming between two
access points in the same wireless network. DHCPv6 clients that can
verify that the previous link and the current link are part of the
same network MAY send Confirm messages while still protecting their
privacy.
4.2. Client Identifier DHCPv6 Option 4.2. Client Identifier DHCPv6 Option
The client identifier option is defined in [RFC3315] with option code The client identifier option is defined in [RFC3315] with option code
1. The purpose of the client identifier option is to identify the 1. The purpose of the client identifier option is to identify the
client to the server. The content of the option is a DHCP User ID client to the server. The content of the option is a DHCP User ID
(DUID). One of the primary privacy concerns is that a client is (DUID). One of the primary privacy concerns is that a client is
disclosing a stable identifier (the DUID) that can be use for disclosing a stable identifier (the DUID) that can be use for
tracking and profiling. Three DUID formats are specified: Link-layer tracking and profiling. Three DUID formats are specified: Link-layer
address plus time, Vendor-assigned unique ID based on Enterprise address plus time, Vendor-assigned unique ID based on Enterprise
skipping to change at page 17, line 18 skipping to change at page 17, line 48
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, Tushar notably Noel Anderson, Lorenzo Colitti, Stephen Farrell, Nick Grifka,
Gupta, Gabriel Montenegro, Marcin Siodelski, Dave Thaler and Jun Wu. Tushar Gupta, Gabriel Montenegro, Marcin Siodelski, Dave Thaler and
Jun Wu.
9. References 9. Changes from previous versions
9.1. Normative References Changes from draft-00 to draft-01:
1. In Section 2.6, added guidance when using
[I-D.ietf-dhc-dynamic-shared-v4allocation].
2. In Section 3.4, added guidance for case when no link layer
address is available.
3. In Section 3.5, changed the recommended mechanism for obfuscating
host names, in order to avoid reveal the underlying link layer
address.
4. In Section 4.1, added an exception to the "should not send
confirm" recommendation, to account for the "good" use of Confirm
when roaming between access points on the same network.
10. 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-00 (work in progress), March 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.
skipping to change at page 18, line 21 skipping to change at page 19, line 21
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
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
9.2. Informative References 10.2. Informative References
[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-03 (work in progress), May draft-ietf-6man-default-iids-04 (work in progress), June
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-05 (work draft-ietf-6man-ipv6-address-generation-privacy-07 (work
in progress), April 2015. in progress), June 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.
[I-D.ietf-dhc-dynamic-shared-v4allocation]
Cui, Y., Qiong, Q., Farrer, I., Lee, Y., Sun, Q., and M.
Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",
draft-ietf-dhc-dynamic-shared-v4allocation-09 (work in
progress), May 2015.
[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, "Dynamic Host Configuration
 End of changes. 26 change blocks. 
40 lines changed or deleted 96 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/