Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 7824 Ericsson
Category: Informational T. Mrugalski
ISSN: 2070-1721 ISC
S. Jiang
Huawei Technologies Co., Ltd.
May 2016
Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 7824 Ericsson
Category: Informational T. Mrugalski
ISSN: 2070-1721 ISC
S. Jiang
Huawei Technologies Co., Ltd.
May 2016
Privacy Considerations for DHCPv6
DHCPv6的隐私注意事项
Abstract
摘要
DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document describes the privacy issues associated with the use of DHCPv6 by Internet users. It is intended to be an analysis of the present situation and does not propose any solutions.
DHCPv6是一种用于向IPv6主机提供寻址和配置信息的协议。本文档描述了与互联网用户使用DHCPv6相关的隐私问题。本报告旨在分析目前的情况，不提出任何解决办法。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7824.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7824.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Identifiers in DHCPv6 Options and Fields ........................5
3.1. Source IPv6 Address ........................................5
3.2. DUID .......................................................5
3.3. Client Identifier Option ...................................6
3.4. IA_NA, IA_TA, IA_PD, IA Address, and IA Prefix Options .....6
3.5. Client FQDN Option .........................................6
3.6. Client Link-Layer Address Option ...........................7
3.7. Option Request Option ......................................7
3.8. Vendor Class and Vendor-Specific Information Options .......7
3.9. Civic Location Option ......................................8
3.10. Coordinate-Based Location Option ..........................8
3.11. Client System Architecture Type Option ....................8
3.12. Relay Agent Options .......................................8
3.12.1. Subscriber-ID Option ...............................9
3.12.2. Interface ID Option ................................9
3.12.3. Remote ID Option ...................................9
3.12.4. Relay-ID Option ....................................9
4. Existing Mechanisms That Affect Privacy ........................10
4.1. Temporary Addresses .......................................10
4.2. DNS Updates ...............................................10
4.3. Allocation Strategies .....................................10
5. Attacks ........................................................12
5.1. Device Type Discovery (Fingerprinting) ....................12
5.2. Operating System Discovery (Fingerprinting) ...............12
5.3. Finding Location Information ..............................12
5.4. Finding Previously Visited Networks .......................13
5.5. Finding a Stable Identity .................................13
5.6. Pervasive Monitoring ......................................13
5.7. Finding a Client's IP Address or Hostname .................14
5.8. Correlation of Activities over Time .......................14
5.9. Location Tracking .........................................14
5.10. Leasequery and Bulk Leasequery ...........................15
6. Security Considerations ........................................15
7. Privacy Considerations .........................................15
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................16
Acknowledgements ..................................................18
Authors' Addresses ................................................18
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Identifiers in DHCPv6 Options and Fields ........................5
3.1. Source IPv6 Address ........................................5
3.2. DUID .......................................................5
3.3. Client Identifier Option ...................................6
3.4. IA_NA, IA_TA, IA_PD, IA Address, and IA Prefix Options .....6
3.5. Client FQDN Option .........................................6
3.6. Client Link-Layer Address Option ...........................7
3.7. Option Request Option ......................................7
3.8. Vendor Class and Vendor-Specific Information Options .......7
3.9. Civic Location Option ......................................8
3.10. Coordinate-Based Location Option ..........................8
3.11. Client System Architecture Type Option ....................8
3.12. Relay Agent Options .......................................8
3.12.1. Subscriber-ID Option ...............................9
3.12.2. Interface ID Option ................................9
3.12.3. Remote ID Option ...................................9
3.12.4. Relay-ID Option ....................................9
4. Existing Mechanisms That Affect Privacy ........................10
4.1. Temporary Addresses .......................................10
4.2. DNS Updates ...............................................10
4.3. Allocation Strategies .....................................10
5. Attacks ........................................................12
5.1. Device Type Discovery (Fingerprinting) ....................12
5.2. Operating System Discovery (Fingerprinting) ...............12
5.3. Finding Location Information ..............................12
5.4. Finding Previously Visited Networks .......................13
5.5. Finding a Stable Identity .................................13
5.6. Pervasive Monitoring ......................................13
5.7. Finding a Client's IP Address or Hostname .................14
5.8. Correlation of Activities over Time .......................14
5.9. Location Tracking .........................................14
5.10. Leasequery and Bulk Leasequery ...........................15
6. Security Considerations ........................................15
7. Privacy Considerations .........................................15
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................16
Acknowledgements ..................................................18
Authors' Addresses ................................................18
DHCPv6 [RFC3315] is a protocol that is used to provide addressing and configuration information to IPv6 hosts. DHCPv6 uses several identifiers that could become a source for gleaning information about the IPv6 host. This information may include device type, operating system information, location(s) that the device may have previously visited, etc. This document discusses the various identifiers used by DHCPv6 and the potential privacy issues [RFC6973]. In particular, it also takes into consideration the problem of pervasive monitoring [RFC7258].
DHCPv6[RFC3315]是一种用于向IPv6主机提供寻址和配置信息的协议。DHCPv6使用多个标识符，这些标识符可能成为收集IPv6主机信息的来源。此信息可能包括设备类型、操作系统信息、设备以前可能访问过的位置等。本文档讨论DHCPv6使用的各种标识符以及潜在的隐私问题[RFC6973]。特别是，它还考虑了普遍监测的问题[RFC7258]。
Future works may propose protocol changes to fix the privacy issues that have been analyzed in this document. See [RFC7844] for one of such changes. Protocol changes are out of scope for this document.
未来的工作可能会提出协议更改，以修复本文档中分析的隐私问题。请参阅[RFC7844]了解其中一项更改。协议更改超出了本文档的范围。
The primary focus of this document is around privacy considerations for clients to support client mobility and connection to random networks. The privacy of DHCPv6 servers and relay agents are considered less important as they are typically open for public services. And, it is generally assumed that communication from the relay agent to the server is protected from casual snooping, as that communication occurs in the provider's backbone. Nevertheless, the topics involving relay agents and servers are explored to some degree. However, future work may want to further explore privacy of DHCPv6 servers and relay agents.
本文档的主要重点是围绕客户机的隐私考虑，以支持客户机移动性和与随机网络的连接。DHCPv6服务器和中继代理的隐私被认为不太重要，因为它们通常对公共服务开放。并且，通常假设从中继代理到服务器的通信受到保护，不受偶然窥探，因为该通信发生在提供者的主干中。然而，涉及中继代理和服务器的主题在一定程度上得到了探讨。然而，未来的工作可能需要进一步探索DHCPv6服务器和中继代理的隐私。
Naming conventions from [RFC3315] and other DHCPv6-related RFCs are used throughout this document. In addition, the following term is used:
本文件使用[RFC3315]和其他DHCPv6相关RFC中的命名约定。此外，还使用以下术语：
Stable identifier: Any property disclosed by a DHCPv6 client that does not change over time or changes very infrequently and is unique for said client in a given context. Examples include Media Access Control (MAC) address, client-id, and a hostname. Some identifiers may be considered stable only under certain conditions; for example, one client implementation may keep its client-id stored in stable storage whereas another may generate it on the fly and use a different one after each boot. Stable identifiers may or may not be globally unique.
稳定标识符：DHCPv6客户机披露的任何属性，该属性不会随时间变化或很少变化，并且在给定上下文中对所述客户机是唯一的。示例包括媒体访问控制（MAC）地址、客户端id和主机名。某些标识符可能仅在某些条件下被认为是稳定的；例如，一个客户端实现可以将其客户端id存储在稳定的存储中，而另一个客户端实现可以动态生成它，并在每次引导后使用不同的id。稳定标识符可能是全局唯一的，也可能不是全局唯一的。
In DHCPv6, there are many options that include identification information or that can be used to extract identification information about the client. This section enumerates various options or fields and the identifiers conveyed in them, which can be used to disclose client identification. The attacks that are enabled by such disclosures are detailed in Section 5.
在DHCPv6中，有许多选项包括标识信息或可用于提取有关客户端的标识信息。本节列举了各种选项或字段以及其中传递的标识符，可用于披露客户身份。第5节详细介绍了此类披露导致的攻击。
Although an IPv6 link-local address is technically not a part of DHCPv6, it appears in the DHCPv6 transmissions, so it is mentioned here for completeness.
虽然IPv6链路本地地址在技术上不是DHCPv6的一部分，但它出现在DHCPv6传输中，因此为了完整性，这里提到它。
If the client does not use privacy extensions (see [RFC4941]) or similar solutions and its IPv6 link-local address is based on a physical link-layer address, this information is disclosed to the DHCPv6 server and to anyone who manages to intercept this transmission.
如果客户端不使用隐私扩展（请参见[RFC4941]）或类似解决方案，并且其IPv6链路本地地址基于物理链路层地址，则会将此信息披露给DHCPv6服务器和任何试图拦截此传输的人。
There are multiple cases where IPv6 link-local addresses are used in DHCPv6. Initial client transmissions are always sent from the IPv6 link-local addresses even when the server unicast option (see Sections 22.12 and 18 of [RFC3315] for details) is enabled. If there are relay agents, they forward the client's traffic wrapped in Relay-forward and store original source IPv6 address in peer-address field.
DHCPv6中使用IPv6链路本地地址的情况有多种。即使启用了服务器单播选项（有关详细信息，请参阅[RFC3315]第22.12和18节），初始客户端传输也始终从IPv6链路本地地址发送。如果有中继代理，它们将转发封装在中继转发中的客户端流量，并将原始源IPv6地址存储在对等地址字段中。
Each DHCPv6 client and server has a DHCP Unique Identifier (DUID) [RFC3315]. The DUID is designed to be unique across all DHCPv6 clients and servers and to remain stable after it has been initially generated. The DUID can be of different forms. Commonly used forms are based on the link-layer address of one of the device's network interfaces (with or without a timestamp) [RFC3315], or on the Universally Unique IDentifier (UUID) [RFC6355]. The default type, defined in Section 9.2 of [RFC3315] is DUID-LLT that is based on link-layer address. It is commonly implemented in most popular clients.
每个DHCPv6客户端和服务器都有一个DHCP唯一标识符（DUID）[RFC3315]。DUID设计为在所有DHCPv6客户端和服务器中都是唯一的，并在最初生成后保持稳定。DUID可以是不同的形式。常用形式基于设备网络接口之一的链路层地址（带或不带时间戳）[RFC3315]，或基于通用唯一标识符（UUID）[RFC6355]。[RFC3315]第9.2节中定义的默认类型是基于链路层地址的DUID-LLT。它通常在大多数流行的客户端中实现。
It is important to understand DUID life cycle. Clients and servers are expected to generate their DUID once (during first operation) and store it in a non-volatile storage or use the same deterministic algorithm to generate the same DUID value again. This means that most implementations will use the available link-layer address during their first boot. Even if the administrator enables link-layer address randomization, it is likely that it was not yet enabled
了解DUID生命周期很重要。客户机和服务器需要生成一次DUID（在第一次操作期间），并将其存储在非易失性存储器中，或者使用相同的确定性算法再次生成相同的DUID值。这意味着大多数实现将在第一次启动时使用可用的链路层地址。即使管理员启用了链接层地址随机化，也有可能尚未启用
during the first device boot. Hence, the original, unobfuscated link-layer address will likely end up being announced as the client DUID, even if the link-layer address has changed (or even if being changed on a periodic basis). The exposure of the original link-layer address in DUID will also undermine other privacy extensions such as [RFC4941].
在第一次设备引导期间。因此，即使链路层地址已更改（或即使定期更改），原始的未模糊链路层地址也可能最终被宣布为客户端DUID。DUID中原始链路层地址的暴露也会破坏其他隐私扩展，如[RFC4941]。
The Client Identifier option (OPTION_CLIENTID) [RFC3315] is used to carry the DUID of a DHCPv6 client between a client and a server. There is an analogous Server Identifier Option, but it is not as interesting in the privacy context (unless a host can be convinced to start acting as a server). See Section 3.2 for relevant discussion about DUIDs.
客户端标识符选项（optionclientId）[RFC3315]用于在客户端和服务器之间携带DHCPv6客户端的DUID。有一个类似的服务器标识符选项，但它在隐私上下文中没有那么有趣（除非可以说服主机开始充当服务器）。有关DUIDs的相关讨论，请参见第3.2节。
The Identity Association for Non-temporary Addresses (IA_NA) option [RFC3315] is used to carry the parameters and any non-temporary addresses associated with the given IA_NA. The Identity Association for Temporary Addresses (IA_TA) option [RFC3315] is analogous to the IA_NA option but is used for temporary addresses. The IA Address option [RFC3315] is used to specify IPv6 addresses associated with an IA_NA or an IA_TA and is encapsulated within the Options field of such an IA_NA or IA_TA option. The Identity Association for Prefix Delegation (IA_PD) [RFC3633] option is used to carry the prefixes that are assigned to the requesting router. IA Prefix option [RFC3633] is used to specify IPv6 prefixes associated with an IA_PD and is encapsulated within the Options field of such an IA_PD option.
非临时地址标识关联（IA_NA）选项[RFC3315]用于携带参数以及与给定IA_NA关联的任何非临时地址。临时地址标识关联（IA_TA）选项[RFC3315]与IA_NA选项类似，但用于临时地址。IA地址选项[RFC3315]用于指定与IA_NA或IA_TA关联的IPv6地址，并封装在此类IA_NA或IA_TA选项的选项字段中。前缀委派的身份关联（IA_PD）[RFC3633]选项用于携带分配给请求路由器的前缀。IA前缀选项[RFC3633]用于指定与IA_PD关联的IPv6前缀，并封装在此类IA_PD选项的选项字段中。
To differentiate between instances of the same type of IA containers for a client, each IA_NA, IA_TA, and IA_PD options have an IAID field with a unique value for a given IA type. It is up to the client to pick unique IAID values. At least one popular implementation uses the last four octets of the link-layer address. In most cases, that means that merely two bytes are missing for a full link-layer address reconstruction. However, the first three octets in a typical link-layer address are vendor identifiers. That can be determined with a high level of certainty using other means, thus allowing full link-layer address discovery.
为了区分客户端相同类型IA容器的实例，每个IA_NA、IA_TA和IA_PD选项都有一个IAID字段，该字段具有给定IA类型的唯一值。由客户机选择唯一的IAID值。至少有一种流行的实现使用链路层地址的最后四个八位字节。在大多数情况下，这意味着完整链路层地址重建只缺少两个字节。然而，典型链路层地址中的前三个八位字节是供应商标识符。这可以使用其他方法以高度的确定性来确定，从而允许全链路层地址发现。
The Client Fully Qualified Domain Name (FQDN) option [RFC4704] is used by DHCPv6 clients and servers to exchange information about the client's FQDN and about who has the responsibility for updating the DNS with the associated AAAA and PTR RRs.
DHCPv6客户端和服务器使用客户端完全限定域名（FQDN）选项[RFC4704]来交换有关客户端FQDN的信息，以及有关谁负责使用关联的AAAA和PTR RRs更新DNS的信息。
A client can use this option to convey all or part of its domain name to a DHCPv6 server for the IPv6-address-to-FQDN mapping. In most cases, a client sends its hostname as a hint for the server. The DHCPv6 server may be configured to modify the supplied name or to substitute a different name. The server should send its notion of the complete FQDN for the client in the Domain Name field.
客户端可以使用此选项将其全部或部分域名传输到DHCPv6服务器，以实现IPv6地址到FQDN的映射。在大多数情况下，客户端发送其主机名作为对服务器的提示。DHCPv6服务器可配置为修改提供的名称或替换其他名称。服务器应在“域名”字段中为客户端发送其完整FQDN的概念。
The client link-layer address option [RFC6939] is used by first-hop DHCPv6 relays to provide the client's link-layer address towards the server.
第一跳DHCPv6中继使用客户机链路层地址选项[RFC6939]向服务器提供客户机链路层地址。
DHCPv6 relay agents that receive messages originating from clients may include the link-layer source address of the received DHCPv6 message in the client link-layer address option, in relayed DHCPv6 Relay-forward messages.
接收来自客户端的消息的DHCPv6中继代理可以在中继的DHCPv6中继转发消息中的客户端链路层地址选项中包括接收到的DHCPv6消息的链路层源地址。
DHCPv6 clients include an Option Request option [RFC3315] in DHCPv6 messages to inform the server about options the client wants the server to send to the client.
DHCPv6客户端在DHCPv6消息中包含一个选项请求选项[RFC3315]，用于通知服务器客户端希望服务器发送给客户端的选项。
The contents of an Option Request option are the option codes for options requested by the client. The client may additionally include instances of those options that are identified in the Option Request option, with data values as hints to the server about parameter values the client would like to have returned.
选项请求选项的内容是客户请求的选项的选项代码。客户机还可以包括在选项请求选项中标识的那些选项的实例，并将数据值作为关于客户机希望返回的参数值的提示发送给服务器。
The Vendor Class option, defined in Section 22.16 of [RFC3315], is used by a DHCPv6 client to identify the vendor that manufactured the hardware on which the client is running.
DHCPv6客户机使用[RFC3315]第22.16节中定义的供应商类别选项来识别制造客户机运行硬件的供应商。
The Vendor-specific information option, defined in Section 22.17 of [RFC3315], includes enterprise number, which identifies the client's vendor and often includes a number of additional parameters that are specific to a given vendor. That may include any type of information the vendor deems useful. It should be noted that this information may be present (and different) in both directions: client-to-server and server-to-client communications.
[RFC3315]第22.17节中定义的特定于供应商的信息选项包括企业编号，该编号识别客户的供应商，通常包括特定于给定供应商的许多附加参数。这可能包括供应商认为有用的任何类型的信息。应该注意的是，这些信息可能在两个方向上都存在（并且不同）：客户端到服务器和服务器到客户端通信。
The information contained in the data area of this option is contained in one or more opaque fields that identify details of the hardware configuration, for example, the version of the operating system the client is running or the amount of memory installed on the client.
此选项的数据区域中包含的信息包含在一个或多个不透明字段中，这些字段标识硬件配置的详细信息，例如，客户端正在运行的操作系统版本或客户端上安装的内存量。
DHCPv6 servers use the Civic Location option [RFC4776] to deliver location information (the civic and postal addresses) from the DHCPv6 server to DHCPv6 clients. It may refer to three locations: the location of the DHCPv6 server, the location of the network element believed to be closest to the client, or the location of the client, identified by the "what" element within the option.
DHCPv6服务器使用思域位置选项[RFC4776]将位置信息（思域和邮政地址）从DHCPv6服务器传递到DHCPv6客户端。它可能指三个位置：DHCPv6服务器的位置、据信距离客户端最近的网元的位置，或者由选项中的“what”元素标识的客户端的位置。
The GeoLoc options [RFC6225] are used by the DHCPv6 server to provide coordinate-based geographic location information to DHCPv6 clients. They enable a DHCPv6 client to obtain its location.
DHCPv6服务器使用GeoLoc选项[RFC6225]向DHCPv6客户端提供基于坐标的地理位置信息。它们使DHCPv6客户机能够获取其位置。
The Client System Architecture Type option [RFC5970] is used by the DHCPv6 client to send a list of supported architecture types to the DHCPv6 server. It is used by clients that must be booted using the network rather than from local storage, so the server can decide which boot file should be provided to the client.
DHCPv6客户端使用客户端系统体系结构类型选项[RFC5970]向DHCPv6服务器发送受支持体系结构类型的列表。它由必须使用网络而不是从本地存储引导的客户端使用，因此服务器可以决定应该向客户端提供哪个引导文件。
A DHCPv6 relay agent may include a number of options. Those options contain information that can be used to identify the client. Those options are almost exclusively exchanged between the relay agent and the server, thus never leaving the operators network. In particular, they're almost never present in the last wireless hop in case of WiFi networks. The only exception to that rule is somewhat infrequently used Relay-Supplied Options option [RFC6422]. This fact implies that the threat-model-related relay options are slightly different. Traffic sniffing at the last hop and related class of attacks typically do not apply. On the other hand, all attacks that involve the operator's infrastructure (either willing or coerced cooperation or infrastructure being compromised) usually apply.
DHCPv6中继代理可以包括许多选项。这些选项包含可用于识别客户端的信息。这些选项几乎只在中继代理和服务器之间交换，因此永远不会离开运营商网络。特别是，在使用WiFi网络的情况下，它们几乎从未出现在最后一个无线跳跃中。该规则的唯一例外是很少使用的继电器提供的选项[RFC6422]。这一事实意味着与威胁模型相关的中继选项略有不同。最后一跳的流量嗅探和相关类型的攻击通常不适用。另一方面，所有涉及运营商基础设施的攻击（自愿或强制合作或基础设施受损）通常都适用。
The following subsections describe various options inserted by the relay agents.
以下小节描述了中继代理插入的各种选项。
A DHCPv6 relay may include a Subscriber-ID option [RFC4580] to associate some provider-specific information with clients' DHCPv6 messages that is independent of the physical network configuration.
DHCPv6中继可包括订户ID选项[RFC4580]，以将一些特定于提供商的信息与独立于物理网络配置的客户端的DHCPv6消息相关联。
In many deployments, the relay agent that inserts this option is configured to use client's link-layer address as Subscriber-ID.
在许多部署中，插入此选项的中继代理被配置为使用客户端的链路层地址作为订户ID。
A DHCPv6 relay includes the Interface ID option [RFC3315] to identify the interface on which it received the client message that is being relayed.
DHCPv6中继器包括接口ID选项[RFC3315]，用于标识接收到正在中继的客户端消息的接口。
Although, in principle, the Interface ID can be arbitrarily long with completely random values, it is sometimes a text string that includes the relay agent name followed by the interface name. This can be used for fingerprinting the relay or determining a client's point of attachment.
虽然原则上，接口ID可以是任意长且完全随机的值，但它有时是一个文本字符串，包含中继代理名称，后跟接口名称。这可用于对继电器进行指纹识别或确定客户的连接点。
A DHCPv6 relay includes a Remote ID option [RFC4649] to identify the remote host end of the circuit.
DHCPv6继电器包括一个远程ID选项[RFC4649]，用于识别电路的远程主机端。
The remote-id is vendor specific, for which the vendor is indicated in the enterprise-number field. The remote-id field may encode the information that identified DHCPv6 clients:
远程id是特定于供应商的，其供应商在“企业编号”字段中指明。远程id字段可以对识别DHCPv6客户端的信息进行编码：
o a "caller ID" telephone number for dial-up connection
o 用于拨号连接的“来电显示”电话号码
o a "user name" prompted for by a Remote Access Server
o 远程访问服务器提示输入的“用户名”
o a remote caller ATM address o a "modem ID" of a cable data modem
o 电缆数据调制解调器的“调制解调器ID”的远程呼叫者ATM地址
o the remote IP address of a point-to-point link
o 点到点链路的远程IP地址
o an interface or port identifier
o 接口或端口标识符
Relay agent may include Relay-ID option [RFC5460], which contains a unique relay agent identifier. While its intended use is to provide additional information for the server, so it would be able to respond to leasequeries later, this information can be also used to identify a client's location within the network.
中继代理可以包括中继ID选项[RFC5460]，该选项包含唯一的中继代理标识符。虽然其预期用途是为服务器提供附加信息，以便稍后能够响应leasequeries，但此信息也可用于标识客户端在网络中的位置。
This section describes deployed DHCPv6 mechanisms that can affect privacy.
本节介绍可能影响隐私的已部署DHCPv6机制。
[RFC3315] defines a mechanism for a client to request temporary addresses. The idea behind temporary addresses is that a client can request a temporary address for a specific purpose, use it, and then never renew it (i.e., let it expire).
[RFC3315]定义客户端请求临时地址的机制。临时地址背后的理念是，客户可以为特定目的请求临时地址，使用它，然后再不续订（即，让它过期）。
There are a number of serious issues, both related to protocol and its implementations, that make temporary addresses nearly useless for their original goal. First, [RFC3315] does not include T1 and T2 renewal timers in IA_TA (a container for temporary addresses). However, in Section 18.1.3, it explicitly mentions that temporary addresses can be renewed. Client implementations may mistakenly renew temporary addresses if they are not careful (i.e., by including the IA_TA with the same IAID in Renew or Rebind requests, rather than a new IAID -- see Section 22.5 of [RFC3315]), thus forfeiting short liveness. [RFC4704] does not explicitly prohibit servers from updating DNS for assigned temporary addresses, and there are implementations that can be configured to do that. However, this is not advised as publishing a client's IPv6 address in DNS that is publicly available is a major privacy breach.
有许多严重的问题，都与协议及其实现有关，这使得临时地址对于其原始目标几乎毫无用处。首先，[RFC3315]不包括IA_TA（临时地址容器）中的T1和T2续订计时器。然而，在第18.1.3节中，明确提到临时地址可以更新。如果不小心，客户端实现可能会错误地续订临时地址（即，在续订或重新绑定请求中包含具有相同IAID的IA_TA，而不是新的IAID，请参见[RFC3315]的第22.5节），从而丧失短生存期。[RFC4704]并没有明确禁止服务器为分配的临时地址更新DNS，有些实现可以配置为这样做。但是，不建议这样做，因为在公开可用的DNS中发布客户端的IPv6地址是一种严重的隐私侵犯。
The Client FQDN option [RFC4704] used along with DNS UPDATE [RFC2136] defines a mechanism that allows both clients and the server to insert information about clients into the DNS domain. Both forward (AAAA) and reverse (PTR) resource records can be updated. This allows other nodes to conveniently refer to a host, despite the fact that its IPv6 address may be changing.
与DNS更新[RFC2136]一起使用的客户端FQDN选项[RFC4704]定义了一种机制，允许客户端和服务器将有关客户端的信息插入DNS域。正向（AAAA）和反向（PTR）资源记录都可以更新。这允许其他节点方便地引用主机，尽管其IPv6地址可能正在更改。
This mechanism exposes two important pieces of information: the current address (which can be mapped to current location) and a client's hostname. The stable hostname can then by used to correlate the client across different network attachments even when its IPv6 address keeps changing.
此机制公开了两条重要信息：当前地址（可以映射到当前位置）和客户端的主机名。稳定的主机名可用于在不同网络附件之间关联客户端，即使其IPv6地址不断更改。
A DHCPv6 server running in typical, stateful mode is given a task of managing one or more pools of IPv6 resources (currently non-temporary addresses, temporary addresses and/or prefixes, but more resource types may be defined in the future). When a client requests a
在典型的有状态模式下运行的DHCPv6服务器的任务是管理一个或多个IPv6资源池（当前为非临时地址、临时地址和/或前缀，但将来可能会定义更多的资源类型）。当客户端请求
resource, the server must pick a resource out of the configured pool. Depending on the server's implementation, various allocation strategies are possible. Choices in this regard may have privacy implications.
资源，服务器必须从配置的池中选取资源。根据服务器的实现，可以使用各种分配策略。这方面的选择可能涉及隐私问题。
Iterative allocation: a server may choose to allocate addresses one by one. That strategy has the benefit of being very fast, thus being favored in deployments that prefer performance. However, it makes the resources very predictable. Also, since the resources allocated tend to be clustered at the beginning of an available pool, it makes scanning attacks much easier.
迭代分配：服务器可以选择逐个分配地址。这种策略的好处是速度非常快，因此在更喜欢性能的部署中受到青睐。但是，它使资源非常可预测。此外，由于分配的资源往往集中在可用池的开头，因此扫描攻击变得更加容易。
Identifier-based allocation: some server implementations use a fixed identifier for a specific client, seemingly taken from the client's MAC address when available or some lower bits of client's source IPv6 address. This has a property of being convenient for converting IP address to/from other identifiers, especially if the identifier is or contains a MAC address. It is also convenient, as a returning client is very likely to get the same address, even if the server does not retain the client's previous address. Those properties are convenient for system administrators, so DHCPv6 server implementors are sometimes requested to implement it. There is at least one implementation that supports it. The downside of such allocation is that the client now discloses its identifier in its IPv6 address to all services to which it connects. That means that attacks related to the correlation of activities over time, location tracking, address scanning, and OS/ vendor discovery apply.
基于标识符的分配：一些服务器实现为特定客户机使用固定标识符，在可用时似乎取自客户机的MAC地址或客户机源IPv6地址的较低位。这具有便于将IP地址转换成其他标识符或从其他标识符转换IP地址的特性，特别是当标识符是或包含MAC地址时。这也很方便，因为返回的客户机很可能获得相同的地址，即使服务器不保留客户机以前的地址。这些属性对于系统管理员来说很方便，因此有时会要求DHCPv6服务器实现者来实现它。至少有一个实现支持它。这种分配的缺点是，客户端现在将其IPv6地址中的标识符公开给它所连接的所有服务。这意味着与活动随时间变化的相关性、位置跟踪、地址扫描和操作系统/供应商发现相关的攻击适用。
Hash allocation: an extension of identifier-based allocation. Instead of using the identifier directly, it is hashed first. If the hash is implemented correctly, it removes the flaw of disclosing the identifier, a property that eliminates susceptibility to address scanning and OS/vendor discovery. If the hash is poorly implemented (e.g., can be reversed), it introduces no improvement over identifier-based allocation. Even a well-implemented hash does not mitigate the threat of correlation over time.
哈希分配：基于标识符的分配的扩展。不是直接使用标识符，而是首先对其进行哈希处理。如果哈希正确实现，它将消除公开标识符的缺陷，该属性消除了地址扫描和操作系统/供应商发现的敏感性。如果哈希实现得不好（例如，可以反转），则它不会比基于标识符的分配带来任何改进。即使是一个实现良好的散列，也不能随着时间的推移减轻相关性的威胁。
Random allocation: a server can pick a resource pseudorandomly out of an available pool. This allocation scheme essentially prevents returning clients from getting the same address or prefix again. On the other hand, it is beneficial from a privacy perspective as addresses and prefixes generated that way are not susceptible to correlation attacks, OS/vendor discovery attacks, or identity discovery attacks. Note that even though the address or prefix itself may be resilient to a given attack, the client may still be
随机分配：服务器可以从可用池中伪随机选取资源。这种分配方案本质上防止返回的客户端再次获得相同的地址或前缀。另一方面，从隐私角度来看，这是有益的，因为以这种方式生成的地址和前缀不易受到关联攻击、操作系统/供应商发现攻击或身份发现攻击的影响。请注意，即使地址或前缀本身可以抵御给定的攻击，客户机仍然可能会受到攻击
susceptible if additional information is disclosed other way; for example, the client's address may be randomized, but it still can leak its MAC address in the Client Identifier option.
如果以其他方式披露额外信息，则易受影响；例如，客户机的地址可能是随机的，但它仍然可以在客户机标识符选项中泄漏其MAC地址。
Other allocation strategies may be implemented.
可实施其他分配策略。
The type of device used by the client can be guessed by the attacker using the Vendor Class option, Vendor-specific information option, the client link-layer address option, and by parsing the Client Identifier option. All of those options may contain OUI (Organizationally Unique Identifier) that represents the device's vendor. That knowledge can be used for device-specific vulnerability exploitation attacks. See Section 3.4 of [RFC7721] for a discussion about this type of attack.
攻击者可以使用“供应商类别”选项、“供应商特定信息”选项、“客户机链接层地址”选项以及解析“客户机标识符”选项猜测客户机使用的设备类型。所有这些选项都可能包含表示设备供应商的OUI（组织唯一标识符）。这些知识可用于特定于设备的漏洞攻击。有关此类攻击的讨论，请参见[RFC7721]第3.4节。
The operating system running on a client can be guessed using the Vendor Class option, the Vendor-specific information option, the Client System Architecture Type option, or by using fingerprinting techniques on the combination of options requested using the Option Request option.
可以使用Vendor Class选项、Vendor specific information选项、client system Architecture Type选项，或者通过对使用option Request选项请求的选项组合使用指纹识别技术来猜测客户端上运行的操作系统。
The physical location information can be obtained by the attacker by many means. The most direct way to obtain this information is by looking into a message originating from the server that contains the Civic Location or GeoLoc options. It can also be indirectly inferred using the Remote ID option, the Interface ID option (e.g., if an access circuit on an Access Node corresponds to a civic location), or the Subscriber-ID option (if the attacker has access to subscriber info).
攻击者可以通过多种方式获取物理位置信息。获取此信息的最直接方法是查看来自包含Civic Location或GeoLoc选项的服务器的消息。还可以使用远程ID选项、接口ID选项（例如，如果接入节点上的接入电路对应于civic位置）或订户ID选项（如果攻击者可以访问订户信息）间接推断。
Another way to discover a client's physical location is to use geolocation services. Those services typically map IP prefixes into geographical locations. The services are usually based on known locations of the subnet, so they may reveal a client's location to the extent of the network to which it is connected, if they can locate the network. However, they usually are not able to discover specific physical location within a network. That is not always true and it depends on the quality of the a priori information available in the geolocation services databases. It should be noted that this threat is general to the DHCPv6 mechanism. Regardless of the
另一种发现客户物理位置的方法是使用地理定位服务。这些服务通常将IP前缀映射到地理位置。这些服务通常基于子网的已知位置，因此如果能够定位网络，它们可能会显示客户端在其连接的网络范围内的位置。但是，它们通常无法发现网络中的特定物理位置。这并不总是正确的，它取决于地理定位服务数据库中可用的先验信息的质量。应该注意的是，这种威胁对DHCPv6机制来说是普遍的。不顾一切
allocation strategy used by the DHCPv6 server implementation, the addresses assigned will always belong to the subnet the server is configured to manage. Cases of using ULAs (Unique Local Addresses) assigned by the DHCPv6 server are out of scope for this document.
DHCPv6服务器实现使用的分配策略，分配的地址将始终属于服务器配置为管理的子网。使用DHCPv6服务器分配的ULA（唯一本地地址）的情况超出了本文档的范围。
When DHCPv6 clients reconnect to a network, they attempt to obtain the same address they used when they previously attached to that network. They do this by putting the previously assigned address(es) in the IA Address option(s). [RFC3315] does not exclude IA_TA in such a case, so it is possible that a client implementation includes an address contained in an IA_TA for the Confirm message. By observing these addresses, an attacker can identify the network the client had previously visited.
当DHCPv6客户端重新连接到网络时，它们会尝试获取与以前连接到该网络时使用的相同地址。他们通过将以前分配的地址放在IA地址选项中来实现这一点。[RFC3315]在这种情况下不排除IA_TA，因此客户端实现可能包括包含在确认消息的IA_TA中的地址。通过观察这些地址，攻击者可以识别客户端以前访问过的网络。
An attacker might use a stable identity gleaned from DHCPv6 messages to correlate activities of a given client on unrelated networks. The Client FQDN option, the Subscriber-ID option, and the Client ID option can serve as long-lived identifiers of DHCPv6 clients. The Client FQDN option can also provide an identity that can easily be correlated with web server activity logs.
攻击者可能使用从DHCPv6消息中收集的稳定身份来关联无关网络上给定客户端的活动。客户机FQDN选项、订户ID选项和客户机ID选项可以用作DHCPv6客户机的长期标识符。客户端FQDN选项还可以提供一个可以轻松与web服务器活动日志关联的标识。
It should be noted that in the general case, the MAC addresses as such are not available in the DHCPv6 packets. Therefore, they cannot be used directly in a reliable way. However, they may become indirectly available using other mechanisms: the client-id contains the link-local address if DUID-LL or DUID-LLT types are used, the source IPv6 address may use an EUI-64 that contains a MAC address, some access technologies may specify a MAC address in dedicated options (e.g., cable modems use MAC addresses in Data Over Cable Service Interface Specification (DOCSIS) options). Relay agents may insert additional information that is used to help the server to identify the client. This could be the Remote-Id option, Subscriber-ID option, client link-layer address option or Vendor-specific information options. Options inserted by relay agents usually traverse only the relay-server path, so they typically can't be eavesdropped by intercepting the client's transmissions. This depends on the actual deployment model and used access technologies.
应当注意的是，在一般情况下，在DHCPv6分组中，MAC地址本身不可用。因此，它们不能以可靠的方式直接使用。但是，它们可能通过其他机制间接可用：客户端id包含链路本地地址如果使用DUID-LL或DUID-LLT类型，则源IPv6地址可能使用包含MAC地址的EUI-64，某些访问技术可能在专用选项中指定MAC地址（例如，电缆调制解调器在电缆数据服务接口规范（DOCSIS）选项中使用MAC地址）。中继代理可以插入用于帮助服务器识别客户端的附加信息。这可能是远程Id选项、订户Id选项、客户端链接层地址选项或特定于供应商的信息选项。中继代理插入的选项通常只遍历中继服务器路径，因此通常不能被窃听这取决于实际的部署模型和使用的访问技术。
Pervasive Monitoring (PM) is widespread (and often covert) surveillance through intrusive gathering of protocol artifacts, including application content or protocol metadata such as headers. Active or passive wiretaps and traffic analysis, (e.g., correlation,
普适性监视（PM）是通过侵入性收集协议工件（包括应用程序内容或协议元数据，如标头）进行的广泛（通常是隐蔽）监视。主动或被动窃听和流量分析（例如相关性、，
timing or measuring packet sizes) or subverting the cryptographic keys used to secure protocols can also be used as part of pervasive monitoring. PM is distinguished by being indiscriminate and very large scale; it does not necessarily introduce new types of technical compromise. See [RFC7258] for a discussion about PM.
定时或测量数据包大小）或破坏用于保护协议的加密密钥也可以用作普及监控的一部分。PM的特点是不分青红皂白，规模非常大；它不一定会引入新类型的技术妥协。有关PM的讨论，请参见[RFC7258]。
In the DHCPv6 context, the PM approach can be used to collect any identifiers discussed in Section 3. DHCPv4 and DHCPv6 are especially susceptible as the initial message sent (SOLICIT in the case of DHCPv6) is one of the very first packets sent when visiting a network. Furthermore, in certain cases, this packet can be logged even on networks that do not support IPv6 (some implementations initiate DHCPv6 even without receiving RA with M or O bits set). This may be an easily overlooked attack vector when an IPv6-capable device connects to an IPv4-only network, gains only IPv4 connectivity, but still leaks its stable identifiers over DHCPv6.
在DHCPv6上下文中，PM方法可用于收集第3节中讨论的任何标识符。DHCPv4和DHCPv6特别容易受到影响，因为发送的初始消息（在DHCPv6的情况下是请求）是访问网络时发送的最早的数据包之一。此外，在某些情况下，即使在不支持IPv6的网络上也可以记录此数据包（一些实现甚至在未接收设置了M或O位的RA的情况下启动DHCPv6）。当IPv6设备能够连接到IPv4的网络时，这可能是一个容易被忽略的攻击向量，只获得IPv4连通性，但是仍然在DHCPv6上泄漏其稳定的标识符。
Using the PM approach, the attacks discussed in Sections 5.1, 5.2, 5.3, 5.4, 5.5, 5.7, 5.8, and possibly 5.9, apply.
使用PM方法，第5.1节、第5.2节、第5.3节、第5.4节、第5.5节、第5.7节、第5.8节和第5.9节中讨论的攻击适用。
Many DHCPv6 deployments use DNS Updates [RFC4704] that put client's information (current IP address, client's hostname) into the DNS, where it is easily accessible by anyone interested. Client ID is also disclosed, albeit in not an easily accessible form (SHA-256 digest of the client-id). As SHA-256 is considered irreversible, DHCID can't be converted back to client-id. However, SHA-256 digest can be used as an unique identifier that is accessible by any host.
许多DHCPv6部署使用DNS更新[RFC4704]，将客户机信息（当前IP地址、客户机主机名）放入DNS，任何感兴趣的人都可以轻松访问。还公开了客户ID，尽管不是以易于访问的形式（客户ID的SHA-256摘要）。由于SHA-256被认为是不可逆的，DHCID无法转换回客户端id。但是，SHA-256摘要可用作任何主机都可以访问的唯一标识符。
As with other identifiers, an IPv6 address can be used to correlate the activities of a host for at least as long as the lifetime of the address. If that address was generated from some other, stable identifier and that generation scheme can be deduced by an attacker, the duration of the correlation attack extends to that of the identifier. In many cases, its lifetime is equal to the lifetime of the device itself. See Section 3.1 of [RFC7721] for detailed discussion.
与其他标识符一样，IPv6地址可用于关联主机的活动，时间至少与地址的生命周期相同。如果该地址是由其他稳定的标识符生成的，并且攻击者可以推断该生成方案，则相关攻击的持续时间将延长到该标识符的持续时间。在许多情况下，其寿命等于设备本身的寿命。详细讨论见[RFC7721]第3.1节。
If a stable identifier is used for assigning an address and such mapping is discovered by an attacker (e.g., a server that uses IEEE-identifier-based IID to generate an IPv6 address), all scenarios discussed in Section 3.2 of [RFC7721] apply. In particular, both passive (a service that the client connects to can log the client's
如果使用稳定标识符分配地址，并且攻击者（例如，使用基于IEEE标识符的IID生成IPv6地址的服务器）发现此类映射，则[RFC7721]第3.2节中讨论的所有场景均适用。特别是，两个被动（客户端连接到的服务）都可以记录客户端的
address and draw conclusions regarding its location and movement patterns based on the prefix it is connecting from) and active (an attacker can send ICMPv6 echo requests or other probe packets to networks of suspected client locations) can be used. To give a specific example, by accessing a social portal from tomek-laptop.coffee.somecity.com.example, tomek-laptop.mycompany.com.example, and tomek-laptop.myisp.example.com, the portal administrator can draw conclusions about tomek-laptop's owner's current location and his habits.
根据其连接的前缀地址并得出关于其位置和移动模式的结论）和活动（攻击者可以向可疑客户端位置的网络发送ICMPv6回显请求或其他探测数据包）可以使用。举一个具体的例子，通过从tomek-laptop.coffee.somecity.com.example、tomek-laptop.mycompany.com.example和tomek-laptop.myisp.example.com访问社交门户，门户管理员可以得出关于tomek-laptop所有者当前位置和习惯的结论。
Attackers may masquerade as an access concentrator, either as a DHCPv6 relay agent or as a DHCPv6 client, to obtain location information directly from the DHCPv6 server(s) using the DHCPv6 Leasequery [RFC5007] mechanism.
攻击者可以伪装成访问集中器（DHCPv6中继代理或DHCPv6客户端），以使用DHCPv6租赁[RFC5007]机制直接从DHCPv6服务器获取位置信息。
Location information is information needed by the access concentrator to forward traffic to a broadband-accessible host. This information includes knowledge of the host hardware address, the port or virtual circuit that leads to the host, and/or the hardware address of the intervening subscriber modem.
位置信息是接入集中器将流量转发到宽带接入主机所需的信息。此信息包括主机硬件地址、通向主机的端口或虚拟电路和/或介入用户调制解调器的硬件地址。
Furthermore, the attackers may use the DHCPv6 bulk leasequery [RFC5460] mechanism to obtain bulk information about DHCPv6 bindings, even without knowing the target bindings.
此外，即使不知道目标绑定，攻击者也可能使用DHCPv6批量租赁[RFC5460]机制获取有关DHCPv6绑定的批量信息。
Additionally, active leasequery [RFC7653] is a mechanism for subscribing to DHCPv6 lease update changes in near real-time. The intent of this mechanism is to update an operator's database; however, if the mechanism is misused, an attacker could defeat the server's authentication mechanisms and subscribe to all updates. He then could continue receiving updates, without any need for local presence.
此外，主动租赁[RFC7653]是一种近实时订阅DHCPv6租赁更新更改的机制。该机制的目的是更新操作员的数据库；但是，如果该机制被滥用，攻击者可能会破坏服务器的身份验证机制并订阅所有更新。然后，他可以继续接收更新，而不需要任何本地存在。
In current practice, the client privacy and client authentication are mutually exclusive. The client authentication procedure reveals additional client information in their certificates/identifiers. Full privacy for the clients may mean the clients are also anonymous to the server and the network.
在当前实践中，客户端隐私和客户端身份验证是互斥的。客户端身份验证过程在其证书/标识符中显示其他客户端信息。客户端的完全隐私可能意味着客户端对服务器和网络也是匿名的。
This document in its entirety discusses privacy considerations in DHCPv6. As such, no dedicated discussion is needed.
本文档整体讨论DHCPv6中的隐私注意事项。因此，不需要专门讨论。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<http://www.rfc-editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <http://www.rfc-editor.org/info/rfc7721>.
[RFC7721]Cooper，A.，Gont，F.，和D.Thaler，“IPv6地址生成机制的安全和隐私考虑”，RFC 7721，DOI 10.17487/RFC7721，2016年3月<http://www.rfc-editor.org/info/rfc7721>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <http://www.rfc-editor.org/info/rfc2136>.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 2136，DOI 10.17487/RFC2136，1997年4月<http://www.rfc-editor.org/info/rfc2136>.
[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>.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，DOI 10.17487/RFC3633，2003年12月<http://www.rfc-editor.org/info/rfc3633>.
[RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, DOI 10.17487/RFC4580, June 2006, <http://www.rfc-editor.org/info/rfc4580>.
[RFC4580]Volz，B.，“IPv6（DHCPv6）中继代理用户ID选项的动态主机配置协议”，RFC 4580，DOI 10.17487/RFC4580，2006年6月<http://www.rfc-editor.org/info/rfc4580>.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, DOI 10.17487/RFC4649, August 2006, <http://www.rfc-editor.org/info/rfc4649>.
[RFC4649]Volz，B.，“IPv6（DHCPv6）中继代理远程ID选项的动态主机配置协议”，RFC 4649，DOI 10.17487/RFC4649，2006年8月<http://www.rfc-editor.org/info/rfc4649>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, <http://www.rfc-editor.org/info/rfc4704>.
[RFC4704]Volz，B.，“IPv6（DHCPv6）客户端完全限定域名（FQDN）选项的动态主机配置协议”，RFC 4704，DOI 10.17487/RFC4704，2006年10月<http://www.rfc-editor.org/info/rfc4704>.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, DOI 10.17487/RFC4776, November 2006, <http://www.rfc-editor.org/info/rfc4776>.
[RFC4776]Schulzrinne，H.，“公民地址配置信息的动态主机配置协议（DHCPv4和DHCPv6）选项”，RFC 4776，DOI 10.17487/RFC4776，2006年11月<http://www.rfc-editor.org/info/rfc4776>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 4941，DOI 10.17487/RFC49411907年9月<http://www.rfc-editor.org/info/rfc4941>.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, September 2007, <http://www.rfc-editor.org/info/rfc5007>.
[RFC5007]Brzowski，J.，Kinnear，K.，Volz，B.，和S.Zeng，“DHCPv6租赁”，RFC 5007，DOI 10.17487/RFC5007，2007年9月<http://www.rfc-editor.org/info/rfc5007>.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, DOI 10.17487/RFC5460, February 2009, <http://www.rfc-editor.org/info/rfc5460>.
[RFC5460]Stapp，M.，“DHCPv6散装租赁”，RFC 5460，DOI 10.17487/RFC5460，2009年2月<http://www.rfc-editor.org/info/rfc5460>.
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 Options for Network Boot", RFC 5970, DOI 10.17487/RFC5970, September 2010, <http://www.rfc-editor.org/info/rfc5970>.
[RFC5970]Huth，T.，Freimann，J.，Zimmer，V.，和D.Thaler，“网络引导的DHCPv6选项”，RFC 5970，DOI 10.17487/RFC5970，2010年9月<http://www.rfc-editor.org/info/rfc5970>.
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed., "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, DOI 10.17487/RFC6225, July 2011, <http://www.rfc-editor.org/info/rfc6225>.
[RFC6225]Polk，J.，Linsner，M.，Thomson，M.，和B.Aboba，Ed.，“基于坐标的位置配置信息的动态主机配置协议选项”，RFC 6225，DOI 10.17487/RFC6225，2011年7月<http://www.rfc-editor.org/info/rfc6225>.
[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, DOI 10.17487/RFC6355, August 2011, <http://www.rfc-editor.org/info/rfc6355>.
[RFC6355]Narten，T.和J.Johnson，“基于UUID的DHCPv6唯一标识符（DUID-UUID）的定义”，RFC 6355，DOI 10.17487/RFC6355，2011年8月<http://www.rfc-editor.org/info/rfc6355>.
[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 6422, DOI 10.17487/RFC6422, December 2011, <http://www.rfc-editor.org/info/rfc6422>.
[RFC6422]Lemon，T.和Q.Wu，“继电器提供的DHCP选项”，RFC 6422，DOI 10.17487/RFC6422，2011年12月<http://www.rfc-editor.org/info/rfc6422>.
[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, May 2013, <http://www.rfc-editor.org/info/rfc6939>.
[RFC6939]Halwasia，G.，Bhandari，S.，和W.Dec，“DHCPv6中的客户链路层地址选项”，RFC 6939，DOI 10.17487/RFC6939，2013年5月<http://www.rfc-editor.org/info/rfc6939>.
[RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, October 2015, <http://www.rfc-editor.org/info/rfc7653>.
[RFC7653]Raghuvanshi，D.，Kinnear，K.，和D.Kukrety，“DHCPv6主动租赁”，RFC 7653，DOI 10.17487/RFC7653，2015年10月<http://www.rfc-editor.org/info/rfc7653>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profile for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <http://www.rfc-editor.org/info/rfc7844>.
[RFC7844]Huitema，C.，Mrugalski，T.，和S.Krishnan，“DHCP客户端的匿名配置文件”，RFC 7844，DOI 10.17487/RFC7844，2016年5月<http://www.rfc-editor.org/info/rfc7844>.
Acknowledgements
致谢
The authors would like to thank Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian Schaefer, Jinmei Tatuya, Bernie Volz, Marcin Siodelski, Christian Huitema, Brian Haberman, Robert Sparks, Peter Yee, Ben Campbell, and other members of DHC WG for their valuable comments.
作者要感谢斯蒂芬·法雷尔、特德·莱蒙、伊内斯·罗伯斯、罗斯·怀特、克里斯蒂安·谢弗、金美·塔图亚、伯尼·沃尔兹、马辛·西奥德尔斯基、克里斯蒂安·惠特马、布赖恩·哈伯曼、罗伯特·斯帕克斯、彼得·叶、本·坎贝尔以及DHC工作组其他成员的宝贵意见。
Authors' Addresses
作者地址
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Tomek Mrugalski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 United States
美国加利福尼亚州红木市Charter Street 950号Tomek Mrugalski Internet Systems Consortium，Inc.94063
Email: tomasz.mrugalski@gmail.com
Email: tomasz.mrugalski@gmail.com
Sheng Jiang Huawei Technologies Co., Ltd. Q14, Huawei Campus, No.156 BeiQing Road Hai-Dian District, Beijing 100095 China
中国北京海淀区北青路156号华为校园盛江华为技术有限公司Q14 100095
Email: jiangsheng@huawei.com
Email: jiangsheng@huawei.com