draft-ietf-dhc-anonymity-profile-06.txt | draft-ietf-dhc-anonymity-profile-07.txt | |||
---|---|---|---|---|
Network Working Group C. Huitema | Network Working Group C. Huitema | |||
Internet-Draft Microsoft | Internet-Draft Microsoft | |||
Intended status: Standards Track T. Mrugalski | Intended status: Standards Track T. Mrugalski | |||
Expires: August 1, 2016 ISC | Expires: August 18, 2016 ISC | |||
S. Krishnan | S. Krishnan | |||
Ericsson | Ericsson | |||
January 29, 2016 | February 15, 2016 | |||
Anonymity profile for DHCP clients | Anonymity profile for DHCP clients | |||
draft-ietf-dhc-anonymity-profile-06.txt | draft-ietf-dhc-anonymity-profile-07.txt | |||
Abstract | Abstract | |||
Some DHCP options carry unique identifiers. These identifiers can | Some DHCP options carry unique identifiers. These identifiers can | |||
enable device tracking even if the device administrator takes care of | enable device tracking even if the device administrator takes care of | |||
randomizing other potential identifications like link-layer addresses | randomizing other potential identifications like link-layer addresses | |||
or IPv6 addresses. The anonymity profile is designed for clients | or IPv6 addresses. The anonymity profile is designed for clients | |||
that wish to remain anonymous to the visited network. The profile | that wish to remain anonymous to the visited network. The profile | |||
provides guidelines on the composition of DHCP or DHCPv6 requests, | provides guidelines on the composition of DHCP or DHCPv6 requests, | |||
designed to minimize disclosure of identifying information. | designed to minimize disclosure of identifying information. | |||
skipping to change at page 1, line 39 | skipping to change at page 1, line 39 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on August 1, 2016. | This Internet-Draft will expire on August 18, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 37 | skipping to change at page 2, line 37 | |||
3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11 | 3.5. Client Identifier Option . . . . . . . . . . . . . . . . 11 | |||
3.6. Parameter Request List Option . . . . . . . . . . . . . . 12 | 3.6. Parameter Request List Option . . . . . . . . . . . . . . 12 | |||
3.7. Host Name Option . . . . . . . . . . . . . . . . . . . . 12 | 3.7. Host Name Option . . . . . . . . . . . . . . . . . . . . 12 | |||
3.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 13 | 3.8. Client FQDN Option . . . . . . . . . . . . . . . . . . . 13 | |||
3.9. UUID/GUID-based Client Identifier Option . . . . . . . . 14 | 3.9. UUID/GUID-based Client Identifier Option . . . . . . . . 14 | |||
3.10. User and Vendor Class DHCP options . . . . . . . . . . . 14 | 3.10. User and Vendor Class DHCP options . . . . . . . . . . . 14 | |||
4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 14 | 4. Anonymity profile for DHCPv6 . . . . . . . . . . . . . . . . 14 | |||
4.1. Avoiding fingerprinting . . . . . . . . . . . . . . . . . 15 | 4.1. Avoiding fingerprinting . . . . . . . . . . . . . . . . . 15 | |||
4.2. Do not send Confirm messages, unless really sure where . 15 | 4.2. Do not send Confirm messages, unless really sure where . 15 | |||
4.3. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 16 | 4.3. Client Identifier DHCPv6 Option . . . . . . . . . . . . . 16 | |||
4.3.1. Anonymous Information-Request . . . . . . . . . . . . 16 | 4.3.1. Anonymous Information-Request . . . . . . . . . . . . 17 | |||
4.4. Server Identifier Option . . . . . . . . . . . . . . . . 17 | 4.4. Server Identifier Option . . . . . . . . . . . . . . . . 17 | |||
4.5. Address assignment options . . . . . . . . . . . . . . . 17 | 4.5. Address assignment options . . . . . . . . . . . . . . . 17 | |||
4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 18 | 4.5.1. Obtain temporary addresses . . . . . . . . . . . . . 18 | |||
4.5.2. Prefix delegation . . . . . . . . . . . . . . . . . . 18 | 4.5.2. Prefix delegation . . . . . . . . . . . . . . . . . . 18 | |||
4.6. Option Request Option . . . . . . . . . . . . . . . . . . 18 | 4.6. Option Request Option . . . . . . . . . . . . . . . . . . 19 | |||
4.6.1. Previous option values . . . . . . . . . . . . . . . 19 | 4.6.1. Previous option values . . . . . . . . . . . . . . . 19 | |||
4.7. Authentication Option . . . . . . . . . . . . . . . . . . 19 | 4.7. Authentication Option . . . . . . . . . . . . . . . . . . 19 | |||
4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 19 | 4.8. User and Vendor Class DHCPv6 options . . . . . . . . . . 19 | |||
4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 19 | 4.9. Client FQDN Option . . . . . . . . . . . . . . . . . . . 20 | |||
5. Operational Considerations . . . . . . . . . . . . . . . . . 20 | 5. Operational Considerations . . . . . . . . . . . . . . . . . 20 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
9. Changes from previous versions . . . . . . . . . . . . . . . 20 | 9. Changes from previous versions . . . . . . . . . . . . . . . 21 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 23 | 10.2. Informative References . . . . . . . . . . . . . . . . . 24 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
1. Introduction | 1. Introduction | |||
Reports surfaced recently of systems that would monitor the wireless | Reports surfaced recently of systems that would monitor the wireless | |||
connections of passengers at Canadian airports [CNBC]. We can assume | connections of passengers at Canadian airports [CNBC]. We can assume | |||
that these are either fragments or trial runs of a wider system that | that these are either fragments or trial runs of a wider system that | |||
would attempt to monitor Internet users as they roam through wireless | would attempt to monitor Internet users as they roam through wireless | |||
access points and other temporary network attachments. We can also | access points and other temporary network attachments. We can also | |||
assume that privacy conscious users will attempt to evade this | assume that privacy conscious users will attempt to evade this | |||
monitoring, for example by ensuring that low level identifiers such | monitoring, for example by ensuring that low level identifiers such | |||
skipping to change at page 12, line 12 | skipping to change at page 12, line 12 | |||
address that will be used in the underlying connection. This will | address that will be used in the underlying connection. This will | |||
ensure that the DHCP client identifier does not leak any information | ensure that the DHCP client identifier does not leak any information | |||
that is not already available to entities monitoring the network | that is not already available to entities monitoring the network | |||
connection. It will also ensure that a strategy of randomizing the | connection. It will also ensure that a strategy of randomizing the | |||
link layer address will not be nullified by DHCP options. | link layer address will not be nullified by DHCP options. | |||
There are usages of DHCP where the underlying connection is a point | There are usages of DHCP where the underlying connection is a point | |||
to point link, in which case there is no link layer address available | to point link, in which case there is no link layer address available | |||
to construct a non-revealing identifier. If anonymity is desired in | to construct a non-revealing identifier. If anonymity is desired in | |||
such networks, the client SHOULD pick a random identifier that is | such networks, the client SHOULD pick a random identifier that is | |||
unique to the current link, using for example a combination of a | highly likely to be unique to the current link, using for example a | |||
local secret and an identifier of the connection. | combination of a local secret and an identifier of the connection. | |||
The algorithm for combining secret and identifiers described in | ||||
section 5 of [RFC7217] solves a similar problem. The criteria for | ||||
the generation of random numbers are stated in [RFC4086]. | ||||
3.6. Parameter Request List Option | 3.6. Parameter Request List Option | |||
The Parameter Request List (PRL) option is defined in [RFC2132] with | The Parameter Request List (PRL) option is defined in [RFC2132] with | |||
option code 55. It list the parameters requested from the server by | option code 55. It list the parameters requested from the server by | |||
the client. Different implementations request different | the client. Different implementations request different | |||
parameters.[RFC2132] specifies that "the client MAY list the options | parameters.[RFC2132] specifies that "the client MAY list the options | |||
in order of preference." It practice, this means that different | in order of preference." It practice, this means that different | |||
client implementations will request different parameters, in | client implementations will request different parameters, in | |||
different orders. | different orders. | |||
skipping to change at page 16, line 37 | skipping to change at page 16, line 39 | |||
fourth type, DUID-UUID is defined in [RFC6355]. | fourth type, DUID-UUID is defined in [RFC6355]. | |||
When using the anonymity profile in conjunction with randomized link- | When using the anonymity profile in conjunction with randomized link- | |||
layer addresses, DHCPv6 clients MUST use the DUID format number 3, | layer addresses, DHCPv6 clients MUST use the DUID format number 3, | |||
Link-layer address. The value of the Link-layer address should be | Link-layer address. The value of the Link-layer address should be | |||
that currently assigned to the interface. | that currently assigned to the interface. | |||
When using the anonymity profile without the benefit of randomized | When using the anonymity profile without the benefit of randomized | |||
link-layer addresses, clients that want to protect their privacy | link-layer addresses, clients that want to protect their privacy | |||
SHOULD generate a new randomized DUID-LLT every time they attach to a | SHOULD generate a new randomized DUID-LLT every time they attach to a | |||
new link or detect a possible link change event. The exact details | new link or detect a possible link change event. Syntactically this | |||
are left up to implementors, but there are several factors should be | identifier will conform to [RFC3315] but its content is meaningless. | |||
taken into consideration. The DUID type SHOULD be set to 1 (DUID- | The exact details are left up to implementors, but there are several | |||
LLT). Hardware type SHOULD be set appropriately to the hardware | factors should be taken into consideration. The DUID type SHOULD be | |||
type. The link address embedded in the LLT SHOULD be set to a | set to 1 (DUID-LLT). Hardware type SHOULD be set appropriately to | |||
randomized value. Time SHOULD be set to a random timestamp from the | the hardware type. The link address embedded in the LLT SHOULD be | |||
previous year. Time MAY be set to current time, but this will reveal | set to a randomized value. Time SHOULD be set to a random timestamp | |||
the fact that the DUID is newly generated, and could provide | from the previous year. Time MAY be set to current time, but this | |||
information for device fingerprinting. | will reveal the fact that the DUID is newly generated, and could | |||
provide information for device fingerprinting. The criteria for | ||||
generating highly unique random numbers are listed in [RFC4086]. | ||||
4.3.1. Anonymous Information-Request | 4.3.1. Anonymous Information-Request | |||
According to [RFC3315], a DHCPv6 client typically includes its client | According to [RFC3315], a DHCPv6 client typically includes its client | |||
identifier in most of the messages it sends. There is one exception, | identifier in most of the messages it sends. There is one exception, | |||
however. Client is allowed to omit its client identifier when | however. Client is allowed to omit its client identifier when | |||
sending Information-Request. | sending Information-Request. | |||
When using stateless DHCPv6, clients wanting to protect their privacy | When using stateless DHCPv6, clients wanting to protect their privacy | |||
SHOULD NOT include client identifiers in their Information-Request | SHOULD NOT include client identifiers in their Information-Request | |||
skipping to change at page 18, line 35 | skipping to change at page 18, line 37 | |||
defined in [RFC4941]. Clients interested in their privacy should not | defined in [RFC4941]. Clients interested in their privacy should not | |||
publish their IPv6 addresses in the DNS or otherwise associate them | publish their IPv6 addresses in the DNS or otherwise associate them | |||
with name services, and thus do not normally need two classes of | with name services, and thus do not normally need two classes of | |||
addresses, one public, one temporary. | addresses, one public, one temporary. | |||
The use of mechanisms to allocate several IPv6 addresses to a client | The use of mechanisms to allocate several IPv6 addresses to a client | |||
while preserving privacy is for further study. | while preserving privacy is for further study. | |||
4.5.2. Prefix delegation | 4.5.2. Prefix delegation | |||
The interaction between prefix delegation and anonymity require | The use of DHCPv6 address assignment option for Prefix Delegation is | |||
further study. For now, the simple solution is to avoid using prefix | defined in [RFC3633]. Because current host OS implementations do not | |||
delegation when striving for anonymity. When using the anonymity | typically request prefixes, clients that wish to use DHCPv6 PD - just | |||
profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of | like clients that wish to use any DHCP or DHCPv6 option that is not | |||
address assignment. | currently widely used - should recognize that doing so will serve as | |||
a form of fingerprinting unless or until client use of DHCPv6 PD | ||||
becomes more widespread. | ||||
The anonymity properties of DHCPv6 Prefix Delegation, which use IA_PD | ||||
identity associations, are similar to those of of DHCPv6 address | ||||
assignment using IA_NA identity associations. The IAID could | ||||
potentially be used to identify the client, and a prefix hint sent in | ||||
the IA_PD Prefix option could be used to track the client's previous | ||||
location. Clients that desire anonymity and never request more than | ||||
one prefix SHOULD set the IAID value to zero, as authorized in | ||||
section 6 of [RFC3633], and SHOULD NOT document any previously | ||||
assigned prefix in the IA_PD Prefix option. | ||||
4.6. Option Request Option | 4.6. Option Request Option | |||
The Option Request Option (ORO) is defined in [RFC3315] with option | The Option Request Option (ORO) is defined in [RFC3315] with option | |||
code 6. It specifies the options that the client is requesting from | code 6. It specifies the options that the client is requesting from | |||
the server. The choice of requested options and the order of | the server. The choice of requested options and the order of | |||
encoding of these options in the ORO can be used to fingerprint the | encoding of these options in the ORO can be used to fingerprint the | |||
client. | client. | |||
The client willing to protect its privacy SHOULD only request a | The client willing to protect its privacy SHOULD only request a | |||
skipping to change at page 20, line 17 | skipping to change at page 20, line 29 | |||
The anonymity profile has the effect of hiding the client identity | The anonymity profile has the effect of hiding the client identity | |||
from the DHCP server. This is not always desirable. Some DHCP | from the DHCP server. This is not always desirable. Some DHCP | |||
servers provide facilities like publishing names and addresses in the | servers provide facilities like publishing names and addresses in the | |||
DNS, or ensuring that returning clients get reassigned the same | DNS, or ensuring that returning clients get reassigned the same | |||
address. | address. | |||
Clients using the anonymity profile may be consuming more resources. | Clients using the anonymity profile may be consuming more resources. | |||
For example when they change link-layer address and request for a new | For example when they change link-layer address and request for a new | |||
IP, the old one is still marked as leased by the server. | IP, the old one is still marked as leased by the server. | |||
Some DHCP servers will only give addresses to pre-registered MAC | ||||
addresses, forcing clients to choose between remaining anonymous and | ||||
obtaining connectivity. | ||||
Implementers SHOULD provide a way for clients to control when the | Implementers SHOULD provide a way for clients to control when the | |||
anonymity profile is used, and when standard behavior is preferred. | anonymity profile is used, and when standard behavior is preferred. | |||
Implementers MAY implement this control by tying use of the anonymity | Implementers MAY implement this control by tying use of the anonymity | |||
profile to that of link-layer address randomization. | profile to that of link-layer address randomization. | |||
6. Security Considerations | 6. Security Considerations | |||
The use of the anonymity profile does not change the security | The use of the anonymity profile does not change the security | |||
considerations of the DHCPv4 or DHCPv6 protocols. | considerations of the DHCPv4 or DHCPv6 protocols. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This draft does not require any IANA action. | This draft does not require any IANA action. | |||
8. Acknowledgments | 8. Acknowledgments | |||
The inspiration for this draft came from discussions in the Perpass | The inspiration for this draft came from discussions in the Perpass | |||
mailing list. Several people provided feedback on this draft, | mailing list. Several people provided feedback on this draft, | |||
notably Noel Anderson, Lorenzo Colitti, Stephen Farrell, Nick Grifka, | notably Noel Anderson, Brian Carpenter, Lorenzo Colitti, Stephen | |||
Tushar Gupta, Brian Haberman, Gabriel Montenegro, Marcin Siodelski, | Farrell, Nick Grifka, Tushar Gupta, Brian Haberman, Gabriel | |||
Dave Thaler, Bernie Volz, and Jun Wu. | Montenegro, Marcin Siodelski, Dave Thaler, Bernie Volz, and Jun Wu. | |||
9. Changes from previous versions | 9. Changes from previous versions | |||
The RFC Editor must ensure that this section is removed prior to RFC | The RFC Editor must ensure that this section is removed prior to RFC | |||
publication. | publication. | |||
Changes from draft-00 to draft-01: | Changes from draft-00 to draft-01: | |||
1. In Section 2.6, added guidance when using [RFC7618]. | 1. In Section 2.6, added guidance when using [RFC7618]. | |||
skipping to change at page 23, line 8 | skipping to change at page 23, line 25 | |||
option. | option. | |||
4. In Section 4.2, provided guidance on network identification, with | 4. In Section 4.2, provided guidance on network identification, with | |||
references to [RFC6059] and [IEEE8021X]. | references to [RFC6059] and [IEEE8021X]. | |||
5. In Section 4.5, expanded the Identity Association (IA) acronym. | 5. In Section 4.5, expanded the Identity Association (IA) acronym. | |||
6. In Section 4.3, spelled out DUID-LLT and tightened the text to | 6. In Section 4.3, spelled out DUID-LLT and tightened the text to | |||
make randomized identifiers the recommended default. | make randomized identifiers the recommended default. | |||
Changes from draft-06 to draft-07 address comments received during | ||||
IETF last call | ||||
1. Added informative references to [RFC4086] and [RFC7217] in | ||||
Section 3.5. | ||||
2. In Section 4.3, added precision that the generated DUID-LLT are | ||||
meaningless, and added an informative reference to [RFC4086]. | ||||
3. In Section 4.5.2, reworked the text to reflect the consensus from | ||||
IPv6 experts and provide informed guidance on the use of the | ||||
option if prefix delegation is required. | ||||
4. In Section 5, noticed servers that might mandate link layer | ||||
address registration. | ||||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | |||
RFC 2131, DOI 10.17487/RFC2131, March 1997, | RFC 2131, DOI 10.17487/RFC2131, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2131>. | <http://www.rfc-editor.org/info/rfc2131>. | |||
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, | [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, | |||
C., and M. Carney, "Dynamic Host Configuration Protocol | C., and M. Carney, "Dynamic Host Configuration Protocol | |||
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July | for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July | |||
2003, <http://www.rfc-editor.org/info/rfc3315>. | 2003, <http://www.rfc-editor.org/info/rfc3315>. | |||
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic | ||||
Host Configuration Protocol (DHCP) version 6", RFC 3633, | ||||
DOI 10.17487/RFC3633, December 2003, | ||||
<http://www.rfc-editor.org/info/rfc3633>. | ||||
[RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host | [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host | |||
Configuration Protocol (DHCP) Client Fully Qualified | Configuration Protocol (DHCP) Client Fully Qualified | |||
Domain Name (FQDN) Option", RFC 4702, | Domain Name (FQDN) Option", RFC 4702, | |||
DOI 10.17487/RFC4702, October 2006, | DOI 10.17487/RFC4702, October 2006, | |||
<http://www.rfc-editor.org/info/rfc4702>. | <http://www.rfc-editor.org/info/rfc4702>. | |||
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | |||
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | |||
DOI 10.17487/RFC4861, September 2007, | DOI 10.17487/RFC4861, September 2007, | |||
<http://www.rfc-editor.org/info/rfc4861>. | <http://www.rfc-editor.org/info/rfc4861>. | |||
skipping to change at page 24, line 31 | skipping to change at page 25, line 19 | |||
[I-D.ietf-dhc-dhcpv6-privacy] | [I-D.ietf-dhc-dhcpv6-privacy] | |||
Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy | Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy | |||
considerations for DHCPv6", draft-ietf-dhc- | considerations for DHCPv6", draft-ietf-dhc- | |||
dhcpv6-privacy-03 (work in progress), January 2016. | dhcpv6-privacy-03 (work in progress), January 2016. | |||
[I-D.ietf-dhc-rfc3315bis] | [I-D.ietf-dhc-rfc3315bis] | |||
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., | Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., | |||
Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host | Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host | |||
Configuration Protocol for IPv6 (DHCPv6) bis", draft-ietf- | Configuration Protocol for IPv6 (DHCPv6) bis", draft-ietf- | |||
dhc-rfc3315bis-02 (work in progress), October 2015. | dhc-rfc3315bis-03 (work in progress), February 2016. | |||
[IEEE8021X] | [IEEE8021X] | |||
IEEE Std 802.1X-2010, "IEEE Standards for Local and | IEEE Std 802.1X-2010, "IEEE Standards for Local and | |||
Metropolitan Area Networks: Port based Network Access | Metropolitan Area Networks: Port based Network Access | |||
Control", Feb 2010, <http://standards.ieee.org/getieee802/ | Control", Feb 2010, <http://standards.ieee.org/getieee802/ | |||
download/802.1X-2010.pdf>. | download/802.1X-2010.pdf>. | |||
[IETFMACRandom] | [IETFMACRandom] | |||
Zuniga, JC., "MAC Privacy", November 2014, | Zuniga, JC., "MAC Privacy", November 2014, | |||
<http://www.ietf.org/blog/2014/11/mac-privacy/>. | <http://www.ietf.org/blog/2014/11/mac-privacy/>. | |||
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor | [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor | |||
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, | Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2132>. | <http://www.rfc-editor.org/info/rfc2132>. | |||
[RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for | [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for | |||
Dynamic Host Configuration Protocol version 4 (DHCPv4)", | Dynamic Host Configuration Protocol version 4 (DHCPv4)", | |||
RFC 3925, DOI 10.17487/RFC3925, October 2004, | RFC 3925, DOI 10.17487/RFC3925, October 2004, | |||
<http://www.rfc-editor.org/info/rfc3925>. | <http://www.rfc-editor.org/info/rfc3925>. | |||
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | ||||
"Randomness Requirements for Security", BCP 106, RFC 4086, | ||||
DOI 10.17487/RFC4086, June 2005, | ||||
<http://www.rfc-editor.org/info/rfc4086>. | ||||
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client | [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client | |||
Identifiers for Dynamic Host Configuration Protocol | Identifiers for Dynamic Host Configuration Protocol | |||
Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361, | Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361, | |||
February 2006, <http://www.rfc-editor.org/info/rfc4361>. | February 2006, <http://www.rfc-editor.org/info/rfc4361>. | |||
[RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host | [RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host | |||
Configuration Protocol (DHCP) Options for the Intel | Configuration Protocol (DHCP) Options for the Intel | |||
Preboot eXecution Environment (PXE)", RFC 4578, | Preboot eXecution Environment (PXE)", RFC 4578, | |||
DOI 10.17487/RFC4578, November 2006, | DOI 10.17487/RFC4578, November 2006, | |||
<http://www.rfc-editor.org/info/rfc4578>. | <http://www.rfc-editor.org/info/rfc4578>. | |||
skipping to change at page 25, line 31 | skipping to change at page 26, line 26 | |||
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for | [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for | |||
Detecting Network Attachment in IPv6", RFC 6059, | Detecting Network Attachment in IPv6", RFC 6059, | |||
DOI 10.17487/RFC6059, November 2010, | DOI 10.17487/RFC6059, November 2010, | |||
<http://www.rfc-editor.org/info/rfc6059>. | <http://www.rfc-editor.org/info/rfc6059>. | |||
[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based | [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based | |||
DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, | DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, | |||
DOI 10.17487/RFC6355, August 2011, | DOI 10.17487/RFC6355, August 2011, | |||
<http://www.rfc-editor.org/info/rfc6355>. | <http://www.rfc-editor.org/info/rfc6355>. | |||
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque | ||||
Interface Identifiers with IPv6 Stateless Address | ||||
Autoconfiguration (SLAAC)", RFC 7217, | ||||
DOI 10.17487/RFC7217, April 2014, | ||||
<http://www.rfc-editor.org/info/rfc7217>. | ||||
[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. | [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. | |||
Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", | Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", | |||
RFC 7618, DOI 10.17487/RFC7618, August 2015, | RFC 7618, DOI 10.17487/RFC7618, August 2015, | |||
<http://www.rfc-editor.org/info/rfc7618>. | <http://www.rfc-editor.org/info/rfc7618>. | |||
[WiFiRadioFingerprinting] | [WiFiRadioFingerprinting] | |||
Brik, V., Banerjee, S., Gruteser, M., and S. Oh, "Wireless | Brik, V., Banerjee, S., Gruteser, M., and S. Oh, "Wireless | |||
Device Identification with Radiometric Signatures", | Device Identification with Radiometric Signatures", | |||
September 2008, | September 2008, | |||
<http://www.winlab.rutgers.edu/~gruteser/papers/ | <http://www.winlab.rutgers.edu/~gruteser/papers/ | |||
End of changes. 19 change blocks. | ||||
30 lines changed or deleted | 83 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |