draft-ietf-dhc-anonymity-profile-05.txt | draft-ietf-dhc-anonymity-profile-06.txt | |||
---|---|---|---|---|
Network Working Group C. Huitema | Network Working Group C. Huitema | |||
Internet-Draft Microsoft | Internet-Draft Microsoft | |||
Intended status: Standards Track T. Mrugalski | Intended status: Standards Track T. Mrugalski | |||
Expires: July 16, 2016 ISC | Expires: August 1, 2016 ISC | |||
S. Krishnan | S. Krishnan | |||
Ericsson | Ericsson | |||
January 13, 2016 | January 29, 2016 | |||
Anonymity profile for DHCP clients | Anonymity profile for DHCP clients | |||
draft-ietf-dhc-anonymity-profile-05.txt | draft-ietf-dhc-anonymity-profile-06.txt | |||
Abstract | Abstract | |||
Some DHCP options carry unique identifiers. These identifiers can | Some DHCP options carry unique identifiers. These identifiers can | |||
enable device tracking even if the device administrator takes care of | enable device tracking even if the device administrator takes care of | |||
randomizing other potential identifications like link-layer addresses | randomizing other potential identifications like link-layer addresses | |||
or IPv6 addresses. The anonymity profile is designed for clients | or IPv6 addresses. The anonymity profile is designed for clients | |||
that wish to remain anonymous to the visited network. The profile | that wish to remain anonymous to the visited network. The profile | |||
provides guidelines on the composition of DHCP or DHCPv6 requests, | provides guidelines on the composition of DHCP or DHCPv6 requests, | |||
designed to minimize disclosure of identifying information. | designed to minimize disclosure of identifying information. | |||
skipping to change at page 1, line 39 | skipping to change at page 1, line 39 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on July 16, 2016. | This Internet-Draft will expire on August 1, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 26 | skipping to change at page 2, line 26 | |||
2.2. MAC address Randomization and DHCP . . . . . . . . . . . 5 | 2.2. MAC address Randomization and DHCP . . . . . . . . . . . 5 | |||
2.3. Radio fingerprinting . . . . . . . . . . . . . . . . . . 5 | 2.3. Radio fingerprinting . . . . . . . . . . . . . . . . . . 5 | |||
2.4. Operating system fingerprinting . . . . . . . . . . . . . 6 | 2.4. Operating system fingerprinting . . . . . . . . . . . . . 6 | |||
2.5. No anonymity profile identification . . . . . . . . . . . 6 | 2.5. No anonymity profile identification . . . . . . . . . . . 6 | |||
2.6. Using the anonymity profiles . . . . . . . . . . . . . . 7 | 2.6. Using the anonymity profiles . . . . . . . . . . . . . . 7 | |||
2.7. What about privacy for DHCP servers . . . . . . . . . . . 8 | 2.7. What about privacy for DHCP servers . . . . . . . . . . . 8 | |||
3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8 | 3. Anonymity profile for DHCPv4 . . . . . . . . . . . . . . . . 8 | |||
3.1. Avoiding fingerprinting . . . . . . . . . . . . . . . . . 9 | 3.1. Avoiding fingerprinting . . . . . . . . . . . . . . . . . 9 | |||
3.2. Client IP address field . . . . . . . . . . . . . . . . . 9 | 3.2. Client IP address field . . . . . . . . . . . . . . . . . 9 | |||
3.3. Requested IP address option . . . . . . . . . . . . . . . 10 | 3.3. Requested IP address option . . . . . . . . . . . . . . . 10 | |||
3.4. Client hardware address field . . . . . . . . . . . . . . 10 | 3.4. Client hardware address field . . . . . . . . . . . . . . 11 | |||
3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11 | 3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11 | |||
3.6. Parameter Request List Option . . . . . . . . . . . . . . 12 | 3.6. Parameter Request List Option . . . . . . . . . . . . . . 12 | |||
3.7. Host Name Option . . . . . . . . . . . . . . . . . . . . 12 | 3.7. Host Name Option . . . . . . . . . . . . . . . . . . . . 12 | |||
3.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 13 | 3.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 13 | |||
3.9. UUID/GUID-based Client Identifier Option . . . . . . . . 13 | 3.9. UUID/GUID-based Client Identifier Option . . . . . . . . 14 | |||
3.10. User and Vendor Class DHCP options . . . . . . . . . . . 14 | 3.10. User and Vendor Class DHCP options . . . . . . . . . . . 14 | |||
4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 14 | 4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 14 | |||
4.1. Avoiding fingerprinting . . . . . . . . . . . . . . . . . 15 | 4.1. Avoiding fingerprinting . . . . . . . . . . . . . . . . . 15 | |||
4.2. Do not send Confirm messages, unless really sure where . 15 | 4.2. Do not send Confirm messages, unless really sure where . 15 | |||
4.3. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 16 | 4.3. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 16 | |||
4.3.1. Anonymous Information-Request . . . . . . . . . . . . 16 | 4.3.1. Anonymous Information-Request . . . . . . . . . . . . 16 | |||
4.4. Server Identifier Option . . . . . . . . . . . . . . . . 16 | 4.4. Server Identifier Option . . . . . . . . . . . . . . . . 17 | |||
4.5. Address assignment options . . . . . . . . . . . . . . . 17 | 4.5. Address assignment options . . . . . . . . . . . . . . . 17 | |||
4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 17 | 4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 18 | |||
4.5.2. Prefix delegation . . . . . . . . . . . . . . . . . . 18 | 4.5.2. Prefix delegation . . . . . . . . . . . . . . . . . . 18 | |||
4.6. Option Request Option . . . . . . . . . . . . . . . . . . 18 | 4.6. Option Request Option . . . . . . . . . . . . . . . . . . 18 | |||
4.6.1. Previous option values . . . . . . . . . . . . . . . 18 | 4.6.1. Previous option values . . . . . . . . . . . . . . . 19 | |||
4.7. Authentication Option . . . . . . . . . . . . . . . . . . 19 | 4.7. Authentication Option . . . . . . . . . . . . . . . . . . 19 | |||
4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 19 | 4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 19 | |||
4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 19 | 4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 19 | |||
5. Operational Considerations . . . . . . . . . . . . . . . . . 19 | 5. Operational Considerations . . . . . . . . . . . . . . . . . 20 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
9. Changes from previous versions . . . . . . . . . . . . . . . 20 | 9. Changes from previous versions . . . . . . . . . . . . . . . 20 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 23 | 10.2. Informative References . . . . . . . . . . . . . . . . . 23 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
1. Introduction | 1. Introduction | |||
Reports surfaced recently of systems that would monitor the wireless | Reports surfaced recently of systems that would monitor the wireless | |||
connections of passengers at Canadian airports [CNBC]. We can assume | connections of passengers at Canadian airports [CNBC]. We can assume | |||
that these are either fragments or trial runs of a wider system that | that these are either fragments or trial runs of a wider system that | |||
would attempt to monitor Internet users as they roam through wireless | would attempt to monitor Internet users as they roam through wireless | |||
access points and other temporary network attachments. We can also | access points and other temporary network attachments. We can also | |||
assume that privacy conscious users will attempt to evade this | assume that privacy conscious users will attempt to evade this | |||
monitoring, for example by ensuring that low level identifiers such | monitoring, for example by ensuring that low level identifiers such | |||
skipping to change at page 10, line 20 | skipping to change at page 10, line 20 | |||
locations. DHCP clients should ensure that the field is cleared when | locations. DHCP clients should ensure that the field is cleared when | |||
they know that the network attachment has changed, and in particular | they know that the network attachment has changed, and in particular | |||
if the link layer address is reset by the device's administrator. | if the link layer address is reset by the device's administrator. | |||
The clients using the anonymity profile MUST NOT include in the | The clients using the anonymity profile MUST NOT include in the | |||
message a Client IP Address that has been obtained with a different | message a Client IP Address that has been obtained with a different | |||
link-layer address. | link-layer address. | |||
3.3. Requested IP address option | 3.3. Requested IP address option | |||
The Requested IP address option id defined in [RFC2132] with code 50. | The Requested IP address option is defined in [RFC2132] with code 50. | |||
It allows the client to request that a particular IP address be | It allows the client to request that a particular IP address be | |||
assigned. The option is mandatory in some protocol messages per | assigned. The option is mandatory in some protocol messages per | |||
[RFC2131], for example when a client selects to use an address | [RFC2131], for example when a client selects to use an address | |||
offered by a server. However, this option is not mandatory in the | offered by a server. However, this option is not mandatory in the | |||
DHCPDISCOVER message. It is simply a convenience, an attempt to | DHCPDISCOVER message. It is simply a convenience, an attempt to | |||
regain the same IP address that was used in a previous connection. | regain the same IP address that was used in a previous connection. | |||
Doing so entails the risk of disclosing an IP address used by the | Doing so entails the risk of disclosing an IP address used by the | |||
client at a previous location, or with a different link-layer | client at a previous location, or with a different link-layer | |||
address. | address. The risk exists for all forms of IP addresses, public or | |||
private, as some private addresses may be used in a wide scope, e.g. | ||||
when an Internet Service Provider is using Network Address | ||||
Translation. | ||||
When using the anonymity profile, clients SHOULD NOT use the | When using the anonymity profile, clients SHOULD NOT use the | |||
Requested IP address option in DHCPDISCOVER messages. They MUST use | Requested IP address option in DHCPDISCOVER messages. They MUST use | |||
the option when mandated by the DHCP protocol, for example in | the option when mandated by the DHCP protocol, for example in | |||
DHCPREQUEST messages. | DHCPREQUEST messages. | |||
There are scenarios in which a client connecting to a network | There are scenarios in which a client connecting to a network | |||
remembers previously allocated address, i.e. is in the INIT-REBOOT | remembers previously allocated address, i.e. is in the INIT-REBOOT | |||
state. In that state, the client that is concerned with privacy | state. In that state, the client that is concerned with privacy | |||
SHOULD perform a complete four way handshake starting with | SHOULD perform a complete four way handshake starting with | |||
skipping to change at page 12, line 11 | skipping to change at page 12, line 18 | |||
There are usages of DHCP where the underlying connection is a point | There are usages of DHCP where the underlying connection is a point | |||
to point link, in which case there is no link layer address available | to point link, in which case there is no link layer address available | |||
to construct a non-revealing identifier. If anonymity is desired in | to construct a non-revealing identifier. If anonymity is desired in | |||
such networks, the client SHOULD pick a random identifier that is | such networks, the client SHOULD pick a random identifier that is | |||
unique to the current link, using for example a combination of a | unique to the current link, using for example a combination of a | |||
local secret and an identifier of the connection. | local secret and an identifier of the connection. | |||
3.6. Parameter Request List Option | 3.6. Parameter Request List Option | |||
The Parameter Request List (PRL) option is defined in [RFC2132] with | The Parameter Request List (PRL) option is defined in [RFC2132] with | |||
option code 61. It list the parameters requested from the server by | option code 55. It list the parameters requested from the server by | |||
the client. Different implementations request different | the client. Different implementations request different | |||
parameters.[RFC2132] specifies that "the client MAY list the options | parameters.[RFC2132] specifies that "the client MAY list the options | |||
in order of preference." It practice, this means that different | in order of preference." It practice, this means that different | |||
client implementations will request different parameters, in | client implementations will request different parameters, in | |||
different orders. | different orders. | |||
The choice of option numbers and the specific ordering of option | The choice of option numbers and the specific ordering of option | |||
numbers in the Parameter Request List can be used to fingerprint the | numbers in the Parameter Request List can be used to fingerprint the | |||
client. This may not reveal the identity of a client, but may | client. This may not reveal the identity of a client, but may | |||
provide additional information, such as the device type, vendor type | provide additional information, such as the device type, vendor type | |||
skipping to change at page 14, line 9 | skipping to change at page 14, line 16 | |||
The UUID/GUID-based Client Machine Identifier option is defined in | The UUID/GUID-based Client Machine Identifier option is defined in | |||
[RFC4578], with option code 97. The option is part of a set of | [RFC4578], with option code 97. The option is part of a set of | |||
options for Intel Preboot eXecution Environment (PXE). The purpose | options for Intel Preboot eXecution Environment (PXE). The purpose | |||
of the PXE system is to perform management functions on a device | of the PXE system is to perform management functions on a device | |||
before its main OS is operational. The Client Machine Identifier | before its main OS is operational. The Client Machine Identifier | |||
carries a 16-octet Globally Unique Identifier (GUID), which uniquely | carries a 16-octet Globally Unique Identifier (GUID), which uniquely | |||
identifies the device. | identifies the device. | |||
The PXE system is clearly designed for devices operating in a | The PXE system is clearly designed for devices operating in a | |||
controlled environment, and its functions are not meant to be used by | controlled environment. The main usage of the PXE system is to | |||
mobile nodes visiting untrusted networks. If only for privacy | install a new version of the operating system through a high speed | |||
reasons, nodes visiting untrusted networks MUST disable the PXE | Ethernet connection. The process is typically controlled from the | |||
functions, and MUST NOT send the corresponding options. | user interface during the boot process. Common sense seems to | |||
dictate that getting a new operating system from an unauthenticated | ||||
server at an untrusted location is a really bad idea, and that even | ||||
if the option was available users would not activate it. In any | ||||
case, the option is only used in the "pre boot" environment, and is | ||||
there is no reason to use it once the system is up and running. If | ||||
only for privacy reasons, nodes visiting untrusted networks MUST NOT | ||||
send or use the PXE options. | ||||
3.10. User and Vendor Class DHCP options | 3.10. User and Vendor Class DHCP options | |||
Vendor identifying options are defined in [RFC2132] and [RFC3925]. | Vendor identifying options are defined in [RFC2132] and [RFC3925]. | |||
When using the anonymity profile, DHCP clients SHOULD NOT use the | When using the anonymity profile, DHCP clients SHOULD NOT use the | |||
Vendor Specific Information option (code 43), the Vendor Class | Vendor Specific Information option (code 43), the Vendor Class | |||
Identifier Option (60), the Vendor Class option (code 124), or the | Identifier Option (60), the Vendor Class option (code 124), or the | |||
Vendor Specific Information option (code 125) as these options | Vendor Specific Information option (code 125) as these options | |||
potentially reveal identifying information. | potentially reveal identifying information. | |||
skipping to change at page 15, line 47 | skipping to change at page 16, line 12 | |||
message an attacker can trivially identify the previous point(s) of | message an attacker can trivially identify the previous point(s) of | |||
attachment. | attachment. | |||
Clients interested in protecting their privacy SHOULD NOT send | Clients interested in protecting their privacy SHOULD NOT send | |||
Confirm messages and instead directly try to acquire addresses on the | Confirm messages and instead directly try to acquire addresses on the | |||
new link. However, not sending confirm messages can result in | new link. However, not sending confirm messages can result in | |||
connectivity hiatus in some scenarios, e.g. roaming between two | connectivity hiatus in some scenarios, e.g. roaming between two | |||
access points in the same wireless network. DHCPv6 clients that can | access points in the same wireless network. DHCPv6 clients that can | |||
verify that the previous link and the current link are part of the | verify that the previous link and the current link are part of the | |||
same network MAY send Confirm messages while still protecting their | same network MAY send Confirm messages while still protecting their | |||
privacy. | privacy. Such link identification should happen before DHCPv6 is | |||
used, and thus cannot depend on the DHCPv6 information used in | ||||
[RFC6059]. In practice, the most reliable detection of network | ||||
attachment is through link layer security, e.g. [IEEE8021X]. | ||||
4.3. Client Identifier DHCPv6 Option | 4.3. Client Identifier DHCPv6 Option | |||
The client identifier option is defined in [RFC3315] with option code | The client identifier option is defined in [RFC3315] with option code | |||
1. The purpose of the client identifier option is to identify the | 1. The purpose of the client identifier option is to identify the | |||
client to the server. The content of the option is a DHCP Unique | client to the server. The content of the option is a DHCP Unique | |||
Identifier (DUID). One of the primary privacy concerns is that a | Identifier (DUID). One of the primary privacy concerns is that a | |||
client is disclosing a stable identifier (the DUID) that can be use | client is disclosing a stable identifier (the DUID) that can be use | |||
for tracking and profiling. Three DUID formats are specified in | for tracking and profiling. Three DUID formats are specified in | |||
[RFC3315]: Link-layer address plus time, Vendor-assigned unique ID | [RFC3315]: Link-layer address plus time (DUID-LLT), Vendor-assigned | |||
based on Enterprise Number, Link-layer address. A fourth type, DUID- | unique ID based on Enterprise Number, and Link-layer address. A | |||
UUID is defined in [RFC6355]. | fourth type, DUID-UUID is defined in [RFC6355]. | |||
When using the anonymity profile in conjunction with randomized link- | When using the anonymity profile in conjunction with randomized link- | |||
layer addresses, DHCPv6 clients MUST use the DUID format number 3, | layer addresses, DHCPv6 clients MUST use the DUID format number 3, | |||
Link-layer address. The value of the Link-layer address should be | Link-layer address. The value of the Link-layer address should be | |||
that currently assigned to the interface. | that currently assigned to the interface. | |||
When using the anonymity profile without the benefit of randomized | When using the anonymity profile without the benefit of randomized | |||
link-layer addresses, clients that want to protect their privacy | link-layer addresses, clients that want to protect their privacy | |||
SHOULD generate a new randomized DUID-LLT every time they attach to a | SHOULD generate a new randomized DUID-LLT every time they attach to a | |||
new link or detect a possible link change event. The exact details | new link or detect a possible link change event. The exact details | |||
are left up to implementors, but there are several factors should be | are left up to implementors, but there are several factors should be | |||
taken into consideration. The DUID type SHOULD be set to 1 (DUID- | taken into consideration. The DUID type SHOULD be set to 1 (DUID- | |||
LLT). Hardware type SHOULD be set appropriately to the hardware | LLT). Hardware type SHOULD be set appropriately to the hardware | |||
type. Time MAY be set to current time, but this will reveal the fact | type. The link address embedded in the LLT SHOULD be set to a | |||
that the DUID is newly generated. Implementors interested in hiding | randomized value. Time SHOULD be set to a random timestamp from the | |||
this fact MAY use a time stamp from the past. e.g. a random timestamp | previous year. Time MAY be set to current time, but this will reveal | |||
from the previous year could be a good value. | the fact that the DUID is newly generated, and could provide | |||
information for device fingerprinting. | ||||
4.3.1. Anonymous Information-Request | 4.3.1. Anonymous Information-Request | |||
According to [RFC3315], a DHCPv6 client typically includes its client | According to [RFC3315], a DHCPv6 client typically includes its client | |||
identifier in most of the messages it sends. There is one exception, | identifier in most of the messages it sends. There is one exception, | |||
however. Client is allowed to omit its client identifier when | however. Client is allowed to omit its client identifier when | |||
sending Information-Request. | sending Information-Request. | |||
When using stateless DHCPv6, clients wanting to protect their privacy | When using stateless DHCPv6, clients wanting to protect their privacy | |||
SHOULD NOT include client identifiers in their Information-Request | SHOULD NOT include client identifiers in their Information-Request | |||
skipping to change at page 17, line 11 | skipping to change at page 17, line 23 | |||
When using the anonymity profile, DHCPv6 clients SHOULD use the | When using the anonymity profile, DHCPv6 clients SHOULD use the | |||
Server Identifier Option (code 2) as specified in [RFC3315]. Clients | Server Identifier Option (code 2) as specified in [RFC3315]. Clients | |||
MUST only include server identifier values that were received with | MUST only include server identifier values that were received with | |||
the current link-layer address, because reuse of old values discloses | the current link-layer address, because reuse of old values discloses | |||
information that can be used to identify the client. | information that can be used to identify the client. | |||
4.5. Address assignment options | 4.5. Address assignment options | |||
When using the anonymity profile, DHCPv6 clients might have to use | When using the anonymity profile, DHCPv6 clients might have to use | |||
SOLICIT or REQUEST messages to obtain IPv6 addresses through the DHCP | SOLICIT or REQUEST messages to obtain IPv6 addresses through the DHCP | |||
server. Clients interested in privacy SHOULD request addresses using | server. In DHCPv6, the collection of addresses assigned to a client | |||
the Identity Association for Non-temporary Addresses Option (IA_NA, | is indemtified by an Identity Association (IA).Clients interested in | |||
code 3). | privacy SHOULD request addresses using the Identity Association for | |||
Non-temporary Addresses Option (IA_NA, code 3). | ||||
The IA_NA option includes an IAID parameter that identifies a unique | The IA_NA option includes an IAID parameter that identifies a unique | |||
identity association for the interface for which the Address is | identity association for the interface for which the Address is | |||
requested. Clients interested in protecting their privacy MUST | requested. Clients interested in protecting their privacy MUST | |||
ensure that the IAID does not enable client identification. They | ensure that the IAID does not enable client identification. They | |||
also need to conform to the requirement of [RFC3315] that the IAID | also need to conform to the requirement of [RFC3315] that the IAID | |||
for that IA MUST be consistent across restarts of the DHCP client. | for that IA MUST be consistent across restarts of the DHCP client. | |||
We interpret that as requiring that the IAID MUST be constant for the | We interpret that as requiring that the IAID MUST be constant for the | |||
association, as long as the link layer address remains constant. | association, as long as the link layer address remains constant. | |||
skipping to change at page 20, line 19 | skipping to change at page 20, line 36 | |||
7. IANA Considerations | 7. IANA Considerations | |||
This draft does not require any IANA action. | This draft does not require any IANA action. | |||
8. Acknowledgments | 8. Acknowledgments | |||
The inspiration for this draft came from discussions in the Perpass | The inspiration for this draft came from discussions in the Perpass | |||
mailing list. Several people provided feedback on this draft, | mailing list. Several people provided feedback on this draft, | |||
notably Noel Anderson, Lorenzo Colitti, Stephen Farrell, Nick Grifka, | notably Noel Anderson, Lorenzo Colitti, Stephen Farrell, Nick Grifka, | |||
Tushar Gupta, Gabriel Montenegro, Marcin Siodelski, Dave Thaler, | Tushar Gupta, Brian Haberman, Gabriel Montenegro, Marcin Siodelski, | |||
Bernie Volz, and Jun Wu. | Dave Thaler, Bernie Volz, and Jun Wu. | |||
9. Changes from previous versions | 9. Changes from previous versions | |||
The RFC Editor must ensure that this section is removed prior to RFC | The RFC Editor must ensure that this section is removed prior to RFC | |||
publication. | publication. | |||
Changes from draft-00 to draft-01: | Changes from draft-00 to draft-01: | |||
1. In Section 2.6, added guidance when using [RFC7618]. | 1. In Section 2.6, added guidance when using [RFC7618]. | |||
skipping to change at page 22, line 19 | skipping to change at page 22, line 37 | |||
the IAID is composed of the interface identifier and the first | the IAID is composed of the interface identifier and the first | |||
three bytes of the HW address. This matches the implementation | three bytes of the HW address. This matches the implementation | |||
in Windows 10, and insures that variations will not be used to | in Windows 10, and insures that variations will not be used to | |||
fingerprint the client software. | fingerprint the client software. | |||
3. Dropping "This draft updates RFC4361" from the Abstract, since | 3. Dropping "This draft updates RFC4361" from the Abstract, since | |||
this draft does not actually update RFC4361. | this draft does not actually update RFC4361. | |||
4. Pruned the list of normative references. | 4. Pruned the list of normative references. | |||
Changes from draft-05 to draft-06 address comments received during AD | ||||
evaluation | ||||
1. In Section 3.3, clarified that the requirement to not publish | ||||
addresses from previous networks also applies to private | ||||
addresses. | ||||
2. In Section 3.6, corrected the value of the option number to 55. | ||||
3. In Section 3.9, provided more guidance on disabling the PXE | ||||
option. | ||||
4. In Section 4.2, provided guidance on network identification, with | ||||
references to [RFC6059] and [IEEE8021X]. | ||||
5. In Section 4.5, expanded the Identity Association (IA) acronym. | ||||
6. In Section 4.3, spelled out DUID-LLT and tightened the text to | ||||
make randomized identifiers the recommended default. | ||||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | |||
skipping to change at page 23, line 16 | skipping to change at page 24, line 8 | |||
[CNBC] Weston, G., Greenwald, G., and R. Gallagher, "CBC News: | [CNBC] Weston, G., Greenwald, G., and R. Gallagher, "CBC News: | |||
CSEC used airport Wi-Fi to track Canadian travellers", Jan | CSEC used airport Wi-Fi to track Canadian travellers", Jan | |||
2014, <http://www.cbc.ca/news/politics/csec-used-airport- | 2014, <http://www.cbc.ca/news/politics/csec-used-airport- | |||
wi-fi-to-track-canadian-travellers-edward-snowden- | wi-fi-to-track-canadian-travellers-edward-snowden- | |||
documents-1.2517881>. | documents-1.2517881>. | |||
[I-D.ietf-6man-default-iids] | [I-D.ietf-6man-default-iids] | |||
Gont, F., Cooper, A., Thaler, D., and S. LIU, | Gont, F., Cooper, A., Thaler, D., and S. LIU, | |||
"Recommendation on Stable IPv6 Interface Identifiers", | "Recommendation on Stable IPv6 Interface Identifiers", | |||
draft-ietf-6man-default-iids-08 (work in progress), | draft-ietf-6man-default-iids-09 (work in progress), | |||
October 2015. | January 2016. | |||
[I-D.ietf-6man-ipv6-address-generation-privacy] | [I-D.ietf-6man-ipv6-address-generation-privacy] | |||
Cooper, A., Gont, F., and D. Thaler, "Privacy | Cooper, A., Gont, F., and D. Thaler, "Privacy | |||
Considerations for IPv6 Address Generation Mechanisms", | Considerations for IPv6 Address Generation Mechanisms", | |||
draft-ietf-6man-ipv6-address-generation-privacy-08 (work | draft-ietf-6man-ipv6-address-generation-privacy-08 (work | |||
in progress), September 2015. | in progress), September 2015. | |||
[I-D.ietf-dhc-dhcp-privacy] | [I-D.ietf-dhc-dhcp-privacy] | |||
Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy | Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy | |||
considerations for DHCPv4", draft-ietf-dhc-dhcp-privacy-02 | considerations for DHCPv4", draft-ietf-dhc-dhcp-privacy-03 | |||
(work in progress), December 2015. | (work in progress), January 2016. | |||
[I-D.ietf-dhc-dhcpv6-privacy] | [I-D.ietf-dhc-dhcpv6-privacy] | |||
Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy | Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy | |||
considerations for DHCPv6", draft-ietf-dhc- | considerations for DHCPv6", draft-ietf-dhc- | |||
dhcpv6-privacy-02 (work in progress), December 2015. | dhcpv6-privacy-03 (work in progress), January 2016. | |||
[I-D.ietf-dhc-rfc3315bis] | [I-D.ietf-dhc-rfc3315bis] | |||
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., | Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., | |||
Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host | Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host | |||
Configuration Protocol for IPv6 (DHCPv6) bis", draft-ietf- | Configuration Protocol for IPv6 (DHCPv6) bis", draft-ietf- | |||
dhc-rfc3315bis-02 (work in progress), October 2015. | dhc-rfc3315bis-02 (work in progress), October 2015. | |||
[IEEE8021X] | ||||
IEEE Std 802.1X-2010, "IEEE Standards for Local and | ||||
Metropolitan Area Networks: Port based Network Access | ||||
Control", Feb 2010, <http://standards.ieee.org/getieee802/ | ||||
download/802.1X-2010.pdf>. | ||||
[IETFMACRandom] | [IETFMACRandom] | |||
Zuniga, JC., "MAC Privacy", November 2014, | Zuniga, JC., "MAC Privacy", November 2014, | |||
<http://www.ietf.org/blog/2014/11/mac-privacy/>. | <http://www.ietf.org/blog/2014/11/mac-privacy/>. | |||
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor | [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor | |||
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, | Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2132>. | <http://www.rfc-editor.org/info/rfc2132>. | |||
[RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for | [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for | |||
Dynamic Host Configuration Protocol version 4 (DHCPv4)", | Dynamic Host Configuration Protocol version 4 (DHCPv4)", | |||
skipping to change at page 24, line 21 | skipping to change at page 25, line 21 | |||
Configuration Protocol (DHCP) Options for the Intel | Configuration Protocol (DHCP) Options for the Intel | |||
Preboot eXecution Environment (PXE)", RFC 4578, | Preboot eXecution Environment (PXE)", RFC 4578, | |||
DOI 10.17487/RFC4578, November 2006, | DOI 10.17487/RFC4578, November 2006, | |||
<http://www.rfc-editor.org/info/rfc4578>. | <http://www.rfc-editor.org/info/rfc4578>. | |||
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for | [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for | |||
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) | IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) | |||
Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, | Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, | |||
<http://www.rfc-editor.org/info/rfc4704>. | <http://www.rfc-editor.org/info/rfc4704>. | |||
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for | ||||
Detecting Network Attachment in IPv6", RFC 6059, | ||||
DOI 10.17487/RFC6059, November 2010, | ||||
<http://www.rfc-editor.org/info/rfc6059>. | ||||
[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based | [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based | |||
DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, | DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, | |||
DOI 10.17487/RFC6355, August 2011, | DOI 10.17487/RFC6355, August 2011, | |||
<http://www.rfc-editor.org/info/rfc6355>. | <http://www.rfc-editor.org/info/rfc6355>. | |||
[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. | [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. | |||
Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", | Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", | |||
RFC 7618, DOI 10.17487/RFC7618, August 2015, | RFC 7618, DOI 10.17487/RFC7618, August 2015, | |||
<http://www.rfc-editor.org/info/rfc7618>. | <http://www.rfc-editor.org/info/rfc7618>. | |||
End of changes. 27 change blocks. | ||||
38 lines changed or deleted | 84 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |