Internet Engineering Task Force (IETF) S. Jiang
Request for Comments: 7819 Huawei Technologies Co., Ltd
Category: Informational S. Krishnan
ISSN: 2070-1721 Ericsson
T. Mrugalski
ISC
April 2016
Internet Engineering Task Force (IETF) S. Jiang
Request for Comments: 7819 Huawei Technologies Co., Ltd
Category: Informational S. Krishnan
ISSN: 2070-1721 Ericsson
T. Mrugalski
ISC
April 2016
Privacy Considerations for DHCP
DHCP的隐私注意事项
Abstract
摘要
DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues.
DHCP是一种用于向IPv4主机提供寻址和配置信息的协议。本文档讨论DHCP使用的各种标识符以及潜在的隐私问题。
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/rfc7819.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7819.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language and Terminology . . . . . . . . . . . . 3
3. DHCP Options Carrying Identifiers . . . . . . . . . . . . . . 4
3.1. Client Identifier Option . . . . . . . . . . . . . . . . 4
3.2. Address Fields and Options . . . . . . . . . . . . . . . 4
3.3. Client FQDN Option . . . . . . . . . . . . . . . . . . . 5
3.4. Parameter Request List Option . . . . . . . . . . . . . . 5
3.5. Vendor Class and Vendor-Identifying Vendor Class Options 5
3.6. Civic Location Option . . . . . . . . . . . . . . . . . . 6
3.7. Coordinate-Based Location Option . . . . . . . . . . . . 6
3.8. Client System Architecture Type Option . . . . . . . . . 6
3.9. Relay Agent Information Option and Suboptions . . . . . . 6
4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 7
4.1. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Allocation Strategies . . . . . . . . . . . . . . . . . . 7
5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Device Type Discovery . . . . . . . . . . . . . . . . . . 9
5.2. Operating System Discovery . . . . . . . . . . . . . . . 9
5.3. Finding Location Information . . . . . . . . . . . . . . 9
5.4. Finding Previously Visited Networks . . . . . . . . . . . 9
5.5. Finding a Stable Identity . . . . . . . . . . . . . . . . 9
5.6. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 10
5.7. Finding Client's IP Address or Hostname . . . . . . . . . 10
5.8. Correlation of Activities over Time . . . . . . . . . . . 10
5.9. Location Tracking . . . . . . . . . . . . . . . . . . . . 10
5.10. Leasequery and Bulk Leasequery . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language and Terminology . . . . . . . . . . . . 3
3. DHCP Options Carrying Identifiers . . . . . . . . . . . . . . 4
3.1. Client Identifier Option . . . . . . . . . . . . . . . . 4
3.2. Address Fields and Options . . . . . . . . . . . . . . . 4
3.3. Client FQDN Option . . . . . . . . . . . . . . . . . . . 5
3.4. Parameter Request List Option . . . . . . . . . . . . . . 5
3.5. Vendor Class and Vendor-Identifying Vendor Class Options 5
3.6. Civic Location Option . . . . . . . . . . . . . . . . . . 6
3.7. Coordinate-Based Location Option . . . . . . . . . . . . 6
3.8. Client System Architecture Type Option . . . . . . . . . 6
3.9. Relay Agent Information Option and Suboptions . . . . . . 6
4. Existing Mechanisms That Affect Privacy . . . . . . . . . . . 7
4.1. DNS Updates . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Allocation Strategies . . . . . . . . . . . . . . . . . . 7
5. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Device Type Discovery . . . . . . . . . . . . . . . . . . 9
5.2. Operating System Discovery . . . . . . . . . . . . . . . 9
5.3. Finding Location Information . . . . . . . . . . . . . . 9
5.4. Finding Previously Visited Networks . . . . . . . . . . . 9
5.5. Finding a Stable Identity . . . . . . . . . . . . . . . . 9
5.6. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 10
5.7. Finding Client's IP Address or Hostname . . . . . . . . . 10
5.8. Correlation of Activities over Time . . . . . . . . . . . 10
5.9. Location Tracking . . . . . . . . . . . . . . . . . . . . 10
5.10. Leasequery and Bulk Leasequery . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
The Dynamic Host Configuration Protocol (DHCP) [RFC2131] is used to provide addressing and configuration information to IPv4 hosts. DHCP uses several identifiers that could become a source for gleaning information about the IPv4 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 DHCP and the potential privacy issues [RFC6973]. In particular, it takes into consideration the problem of pervasive monitoring [RFC7258].
动态主机配置协议（DHCP）[RFC2131]用于向IPv4主机提供寻址和配置信息。DHCP使用多个标识符，这些标识符可能成为收集IPv4主机信息的来源。此信息可能包括设备类型、操作系统信息、设备以前可能访问过的位置等。本文档讨论DHCP使用的各种标识符和潜在的隐私问题[RFC6973]。特别是，它考虑了普遍监测的问题[RFC7258]。
Future works may propose protocol changes to fix the privacy issues that have been analyzed in this document. Those changes are out of scope for this document.
未来的工作可能会提出协议更改，以修复本文档中分析的隐私问题。这些更改超出了本文档的范围。
The primary focus of this document is around privacy considerations for clients to support client mobility and connection to random networks. The privacy of DHCP servers and relay agents is considered less important as they are typically open for public services. And, it is generally assumed that communication from relay agent to 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 the privacy of DHCP servers and relay agents.
本文档的主要重点是围绕客户机的隐私考虑，以支持客户机移动性和与随机网络的连接。DHCP服务器和中继代理的隐私被认为不太重要，因为它们通常对公共服务开放。而且，通常假设从中继代理到服务器的通信受到保护，不会受到偶然的窥探，因为该通信发生在提供商的主干网中。然而，涉及中继代理和服务器的主题在一定程度上得到了探讨。然而，未来的工作可能需要进一步探索DHCP服务器和中继代理的隐私。
Naming conventions from [RFC2131] and related documents are used throughout this document.
本文件使用[RFC2131]和相关文件中的命名约定。
In addition, the following terminology is used:
此外，还使用了以下术语：
Stable identifier - Any property disclosed by a DHCP client that does not change over time or changes very infrequently and is unique for said client in a given context. Examples include 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, while another may generate it on the fly and use a different one after each boot. Stable identifiers may or may not be globally unique.
稳定标识符-DHCP客户端公开的任何属性，该属性不会随时间变化或很少变化，并且在给定上下文中对所述客户端是唯一的。示例包括MAC地址、客户端id和主机名。某些标识符可能仅在某些条件下被认为是稳定的；例如，一个客户机实现可以将其客户机id存储在稳定的存储中，而另一个客户机实现可以动态生成它，并在每次引导后使用不同的id。稳定标识符可能是全局唯一的，也可能不是全局唯一的。
In DHCP, there are a few options that contain identification information or that can be used to extract identification information about the client. This section enumerates various options and the identifiers that they convey and that can be used to disclose client identification. They are targets of various attacks that are analyzed in Section 5.
在DHCP中，有几个选项包含标识信息或可用于提取有关客户端的标识信息。本节列举了各种选项及其传达的标识符，以及可用于披露客户身份的标识符。它们是第5节分析的各种攻击的目标。
The Client Identifier option [RFC2131] is used to pass an explicit client identifier to a DHCP server.
客户端标识符选项[RFC2131]用于将显式客户端标识符传递给DHCP服务器。
The client identifier is an opaque key that must be unique to that client within the subnet to which the client is attached. It typically remains stable after it has been initially generated. It may contain a hardware address, identical to the contents of the 'chaddr' field, or another type of identifier, such as a DNS name. Section 9.2 of [RFC3315] specifies DUID-LLT (Link-layer plus time) as the recommended DUID (DHCP Unique Identifier) type in DHCPv6. Section 6.1 of [RFC4361] introduces this concept to DHCP. Those two documents recommend that client identifiers be generated by using the permanent link-layer address of the network interface that the client is trying to configure. [RFC4361] updates the recommendation for a Client Identifier as follows: "[it] consists of a type field whose value is normally 255, followed by a four-byte IA_ID field, followed by the DUID for the client as defined in RFC 3315, section 9". This does not change the lifecycle of client identifiers. Clients are expected to generate their client identifiers once (during first operation) and store them in non-volatile storage or use the same deterministic algorithm to generate the same client identifier values again.
客户端标识符是一个不透明的密钥，它必须在客户端所连接的子网内对该客户端唯一。它通常在最初生成后保持稳定。它可能包含与“chaddr”字段内容相同的硬件地址，或其他类型的标识符，如DNS名称。[RFC3315]第9.2节指定DUID-LLT（链路层加时间）为DHCPv6中推荐的DUID（DHCP唯一标识符）类型。[RFC4361]第6.1节将此概念介绍给DHCP。这两个文档建议使用客户端尝试配置的网络接口的永久链路层地址来生成客户端标识符。[RFC4361]将客户机标识符的建议更新如下：“[it]包括一个值通常为255的类型字段，后跟一个四字节IA_ID字段，后跟RFC 3315第9节中定义的客户机DUID”。这不会更改客户端标识符的生命周期。客户机应生成其客户机标识符一次（在第一次操作期间），并将其存储在非易失性存储器中，或使用相同的确定性算法再次生成相同的客户机标识符值。
This means that typically an implementation will use the available link-layer address during its first boot. Even if the administrator enables link-layer address randomization, it is likely that it was not yet enabled during the first device boot. Hence the original, unobfuscated link-layer address will likely end up being announced as the client identifier, even if the link-layer address has changed (or even if it is being changed on a periodic basis). The exposure of the original link-layer address in the client identifier will also undermine other privacy extensions such as [RFC4941].
这意味着实现通常会在第一次引导期间使用可用的链路层地址。即使管理员启用了链路层地址随机化，也有可能在第一次设备引导期间尚未启用。因此，即使链路层地址已经更改（或者即使它正在定期更改），原始的、未模糊的链路层地址也可能最终被宣布为客户端标识符。在客户端标识符中暴露原始链路层地址也会破坏其他隐私扩展，如[RFC4941]。
The 'yiaddr' field [RFC2131] in a DHCP message is used to convey an allocated address from the server to the client.
DHCP消息中的“yiaddr”字段[RFC2131]用于将分配的地址从服务器传送到客户端。
The DHCP specification [RFC2131] provides a way to specify the client link-layer address in the DHCP message header. A DHCP message header has 'htype' and 'chaddr' fields to specify the client link-layer address type and the link-layer address, respectively. The 'chaddr' field is used both as a hardware address for transmission of reply messages and as a client identifier.
DHCP规范[RFC2131]提供了在DHCP消息头中指定客户端链路层地址的方法。DHCP消息头具有“htype”和“chaddr”字段，分别指定客户端链路层地址类型和链路层地址。“chaddr”字段既用作发送回复消息的硬件地址，也用作客户端标识符。
The 'requested IP address' option [RFC2131] is used by a client to suggest that a particular IP address be assigned.
客户端使用“请求的IP地址”选项[RFC2131]来建议分配特定的IP地址。
The Client Fully Qualified Domain Name (FQDN) option [RFC4702] is used by DHCP clients and servers to exchange information about the client's FQDN and about who has the responsibility for updating the DNS with the associated A and PTR RRs.
DHCP客户端和服务器使用客户端完全限定域名（FQDN）选项[RFC4702]来交换有关客户端FQDN的信息以及有关谁负责使用关联的A和PTR RRs更新DNS的信息。
A client can use this option to convey all or part of its domain name to a DHCP server for the IP-address-to-FQDN mapping. In most cases, a client sends its hostname as a hint for the server. The DHCP 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.
客户端可以使用此选项将其全部或部分域名传送到DHCP服务器，以实现IP地址到FQDN的映射。在大多数情况下，客户端发送其主机名作为对服务器的提示。DHCP服务器可以配置为修改提供的名称或替换其他名称。服务器应在“域名”字段中为客户端发送其完整FQDN的概念。
The Parameter Request List option [RFC2131] is used to inform the server about options the client wants the server to send to the client. The contents of a Parameter Request List option are the option codes of the options requested by the client.
参数请求列表选项[RFC2131]用于通知服务器客户端希望服务器发送给客户端的选项。参数请求列表选项的内容是客户端请求的选项的选项代码。
The Vendor Class option [RFC2131], the Vendor-Identifying Vendor Class option, and the Vendor-Identifying Vendor Information option [RFC3925] are used by the DHCP client to identify the vendor that manufactured the hardware on which the client is running.
DHCP客户端使用供应商类别选项[RFC2131]、供应商标识供应商类别选项和供应商标识供应商信息选项[RFC3925]来标识制造客户端运行的硬件的供应商。
The information contained in the data area of this option is contained in one or more opaque fields that identify the details of the hardware configuration of the host on which the client is running or of industry consortium compliance -- for example, the version of the operating system the client is running or the amount of memory installed on the client.
此选项的数据区域中包含的信息包含在一个或多个不透明字段中，这些字段标识客户端运行的主机的硬件配置或行业联盟合规性的详细信息，例如，客户端正在运行的操作系统版本或客户端上安装的内存量。
DHCP servers use the Civic Location Option [RFC4776] to deliver location information (the civic and postal addresses) to DHCP clients. It may refer to three locations: the location of the DHCP 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.
DHCP服务器使用公民位置选项[RFC4776]将位置信息（公民和邮政地址）传递给DHCP客户端。它可能指三个位置：DHCP服务器的位置、据信距离客户端最近的网元的位置，或者由选项中的“what”元素标识的客户端的位置。
The GeoConf and GeoLoc options [RFC6225] are used by a DHCP server to provide coordinate-based geographic location information to DHCP clients. They enable a DHCP client to obtain its geographic location.
DHCP服务器使用GeoConf和GeoLoc选项[RFC6225]向DHCP客户端提供基于坐标的地理位置信息。它们使DHCP客户端能够获取其地理位置。
The Client System Architecture Type Option [RFC4578] is used by a DHCP client to send a list of supported architecture types to the DHCP 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.
DHCP客户端使用客户端系统体系结构类型选项[RFC4578]向DHCP服务器发送受支持体系结构类型的列表。它由必须使用网络而不是从本地存储引导的客户端使用，因此服务器可以决定应该向客户端提供哪个引导文件。
A DHCP relay agent includes a Relay Agent Information option[RFC3046] to identify the remote host end of the circuit. It contains a "circuit ID" suboption for the incoming circuit, which is an agent-local identifier of the circuit from which a DHCP client-to-server packet was received, and a "remote ID" suboption that provides a trusted identifier for the remote high-speed modem.
DHCP中继代理包括中继代理信息选项[RFC3046]，用于识别电路的远程主机端。它包含传入电路的“电路ID”子选项，该子选项是接收DHCP客户端到服务器数据包的电路的代理本地标识符，以及为远程高速调制解调器提供可信标识符的“远程ID”子选项。
Possible encoding of the "circuit ID" suboption includes: router interface number, switching hub port number, remote access server port number, frame relay Data Link Connection Identifier (DLCI), ATM virtual circuit number, cable data virtual circuit number, etc.
“电路ID”子选项的可能编码包括：路由器接口号、交换集线器端口号、远程访问服务器端口号、帧中继数据链路连接标识符（DLCI）、ATM虚拟电路号、电缆数据虚拟电路号等。
Possible encoding of the "remote ID" suboption includes: a "caller ID" telephone number for dial-up connection, a "user name" prompted for by a remote access server, a remote caller's ATM address, a "modem ID" of a cable data modem, the remote IP address of a point-to-point link, a remote X.25 address for X.25 connections, etc.
“远程ID”子选项的可能编码包括：用于拨号连接的“呼叫方ID”电话号码、远程访问服务器提示的“用户名”、远程呼叫方的ATM地址、电缆数据调制解调器的“调制解调器ID”、点对点链路的远程IP地址、用于X.25连接的远程X.25地址等。
The link-selection suboption [RFC3527] is used by any DHCP relay agent that desires to specify a subnet/link for a DHCP client request that it is relaying but needs the subnet/link specification to be different from the IP address the DHCP server should use when
链路选择子选项[RFC3527]由任何DHCP中继代理使用，该代理希望为其正在中继的DHCP客户端请求指定子网/链路，但需要子网/链路规范不同于DHCP服务器应使用的IP地址
communicating with the relay agent. It contains an IP address that can identify the client's subnet/link. Also, assuming there is knowledge of the network topology, it also reveals client location.
与中继代理进行通信。它包含一个可以识别客户端子网/链路的IP地址。此外，假设有网络拓扑的知识，它还可以显示客户端的位置。
A DHCP relay includes a Subscriber-ID option [RFC3993] to associate some provider-specific information with clients' DHCP messages that is independent of the physical network configuration through which the subscriber is connected. The "subscriber-id" assigned by the provider is intended to be stable as customers connect through different paths and as network changes occur. The Subscriber-ID is an ASCII string that is assigned and configured by the network provider.
DHCP中继包括一个订户ID选项[RFC3993]，用于将某些特定于提供商的信息与客户端的DHCP消息相关联，该消息独立于订户所连接的物理网络配置。供应商分配的“订户id”旨在在客户通过不同路径连接以及网络发生变化时保持稳定。订户ID是由网络提供商分配和配置的ASCII字符串。
This section describes deployed DHCP mechanisms that affect privacy.
本节介绍影响隐私的已部署DHCP机制。
The Client FQDN (Fully Qualified Domain Name) Option [RFC4702] used along with DNS Updates [RFC2136] defines a mechanism that allows both clients and server to insert into the DNS domain information about clients. Both forward (A) and reverse (PTR) resource records can be updated. This allows other nodes to conveniently refer to a host, despite the fact that its IP address may be changing.
与DNS更新[RFC2136]一起使用的客户端FQDN（完全限定域名）选项[RFC4702]定义了一种机制，允许客户端和服务器在DNS域中插入有关客户端的信息。正向（A）和反向（PTR）资源记录都可以更新。这允许其他节点方便地引用主机，尽管其IP地址可能正在更改。
This mechanism exposes two important pieces of information: current address (which can be mapped to current location) and client's hostname. The stable hostname can then be used to correlate the client across different network attachments even when its IP addresses keep changing.
该机制公开了两条重要信息：当前地址（可以映射到当前位置）和客户端主机名。然后，即使客户端的IP地址不断更改，也可以使用稳定的主机名跨不同的网络附件将客户端关联起来。
A DHCP server running in typical, stateful mode is given a task of managing one or more pools of IP addresses. When a client requests an address, the server must pick an address out of a configured pool. Depending on the server's implementation, various allocation strategies are possible. Choices in this regard may have privacy implications. Note that the constraints in DHCP and DHCPv6 are radically different, but servers that allow allocation strategy configuration may allow configuring them in both DHCP and DHCPv6. Not every allocation strategy is equally suitable for DHCP and for DHCPv6.
在典型的有状态模式下运行的DHCP服务器被赋予管理一个或多个IP地址池的任务。当客户端请求地址时，服务器必须从配置的池中选择一个地址。根据服务器的实现，可以使用各种分配策略。这方面的选择可能涉及隐私问题。请注意，DHCP和DHCPv6中的约束完全不同，但是允许配置分配策略的服务器可能允许在DHCP和DHCPv6中配置它们。并非每个分配策略都同样适用于DHCP和DHCPv6。
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 allocated addresses very predictable. Also, since the addresses allocated tend to be clustered at the beginning of an available pool, it makes scanning attacks much easier.
迭代分配：服务器可以选择逐个分配地址。这种策略的好处是速度非常快，因此在更喜欢性能的部署中受到青睐。但是，它使分配的地址非常可预测。此外，由于分配的地址往往集中在可用池的开头，这使得扫描攻击更加容易。
Identifier-based allocation: Some server implementations may choose to allocate an address that is based on one of the available identifiers, e.g., client identifier or MAC address. It is also convenient, as a returning client is very likely to get the same address. Those properties are convenient for system administrators, so DHCP server implementers are often requested to implement it. The downside of such an allocation is that the client has a very stable IP address. That means that correlation of activities over time, location tracking, address scanning, and OS/vendor discovery apply. This is certainly an issue in DHCPv6, but due to a much smaller address space it is almost never a problem in DHCP.
基于标识符的分配：一些服务器实现可能选择基于一个可用标识符（例如，客户端标识符或MAC地址）分配地址。这也很方便，因为返回的客户很可能会得到相同的地址。这些属性对于系统管理员来说很方便，因此常常要求DHCP服务器实现者来实现它。这种分配的缺点是客户端有一个非常稳定的IP地址。这意味着随着时间的推移，活动的相关性、位置跟踪、地址扫描和操作系统/供应商发现适用。这在DHCPv6中肯定是一个问题，但由于地址空间小得多，所以在DHCP中几乎不存在问题。
Hash allocation: This is 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., it can be reversed), it introduces no improvement over identifier-based allocation.
哈希分配：这是基于标识符的分配的扩展。不是直接使用标识符，而是首先对其进行哈希处理。如果哈希正确实现，它将消除公开标识符的缺陷，该属性消除了地址扫描和操作系统/供应商发现的敏感性。如果散列实现得很差（例如，它可以反转），那么它不会比基于标识符的分配带来任何改进。
Random allocation: A server can pick a resource randomly out of an available pool. This allocation scheme essentially prevents returning clients from getting the same address again. On the other hand, it is beneficial from a privacy perspective as addresses generated that way are not susceptible to correlation attacks, OS/vendor discovery attacks, or identity discovery attacks. Note that even though the address itself may be resilient to a given attack, the client may still be susceptible if additional information is disclosed in another way, e.g., 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.
可实施其他分配策略。
Given the limited size of most IPv4 public address pools, allocation mechanisms in IPv4 may not provide much privacy protection or leak much useful information, if misused.
考虑到大多数IPv4公共地址池的有限大小，IPv4中的分配机制可能无法提供太多隐私保护，或者如果被滥用，可能会泄漏太多有用的信息。
The type of device used by the client can be guessed by the attacker using the Vendor Class Option, the 'chaddr' field, and by parsing the Client ID Option. All of those options may contain an Organizationally Unique Identifier (OUI) that represents the device's vendor. That knowledge can be used for device-specific vulnerability exploitation attacks.
攻击者可以使用Vendor Class选项、“chaddr”字段并通过解析client ID选项猜测客户端使用的设备类型。所有这些选项都可能包含表示设备供应商的组织唯一标识符（OUI）。这些知识可用于特定于设备的漏洞攻击。
The operating system running on a client can be guessed using the Vendor Class option, the Client System Architecture Type option, or by using fingerprinting techniques on the combination of options requested using the Parameter Request List option.
可以使用Vendor Class选项、client system Architecture Type选项或使用指纹技术对使用Parameter Request List选项请求的选项组合猜测客户端上运行的操作系统。
The 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, GeoConf, or GeoLoc options. It can also be indirectly inferred using the Relay Agent Information option, with the remote ID suboption, the circuit 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 information).
攻击者可以通过多种方式获取位置信息。获取此信息的最直接方法是查看来自服务器的消息，该服务器包含Civic Location、GeoConf或GeoLoc选项。还可以使用中继代理信息选项、远程ID子选项、电路ID选项（例如，如果接入节点上的接入电路对应于civic位置）或订户ID选项（如果攻击者可以访问订户信息）间接推断出该信息。
When DHCP clients connect to a network, they attempt to obtain the same address they had used before they attached to the network. They do this by putting the previously assigned address in the requested IP address option. By observing these addresses, an attacker can identify the network the client had previously visited.
当DHCP客户端连接到网络时，它们会尝试获取连接到网络之前使用的相同地址。他们通过将以前分配的地址放在请求的IP地址选项中来实现这一点。通过观察这些地址，攻击者可以识别客户端以前访问过的网络。
An attacker might use a stable identity gleaned from DHCP 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 DHCP clients. The Client FQDN option can also provide an identity that can easily be correlated with web server activity logs.
攻击者可能会使用从DHCP消息中收集的稳定身份来关联无关网络上给定客户端的活动。客户端FQDN选项、订户ID选项和客户端ID选项可以用作DHCP客户端的长期标识符。客户端FQDN选项还可以提供一个可以轻松与web服务器活动日志关联的标识。
Pervasive monitoring [RFC7258] is widespread (and often covert) surveillance through intrusive gathering of protocol artifacts, including application content, or protocol metadata such as headers. An operator who controls a nontrivial number of access points or network segments may use obtained information about a single client and observe the client's habits. Although users may not expect true privacy from their operators, the information that is set up to be monitored by users' service operators may also be gathered by an adversary who monitors a wide range of networks and develops correlations from that information.
普适监控[RFC7258]是通过侵入式收集协议工件（包括应用程序内容或协议元数据，如标头）进行的广泛（通常是隐蔽）监控。控制大量接入点或网段的运营商可以使用获得的关于单个客户机的信息，并观察客户机的习惯。尽管用户可能不希望他们的运营商提供真正的隐私，但设置由用户服务运营商监控的信息也可能由监控范围广泛的网络并根据该信息建立关联的对手收集。
Many DHCP deployments use DNS Updates [RFC4702] that put a 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 not in an easily accessible form (SHA-256 digest of the client-id). As SHA-256 is considered irreversible, DHCP client ID can't be converted back to client-id. However, SHA-256 digest can be used as a unique identifier that is accessible by any host.
许多DHCP部署使用DNS更新[RFC4702]，将客户机信息（当前IP地址、客户机主机名）放入DNS中，任何感兴趣的人都可以轻松访问。还公开了客户ID，尽管不是以易于访问的形式（客户ID的SHA-256摘要）。由于SHA-256被认为是不可逆的，DHCP客户端ID无法转换回客户端ID。但是，SHA-256摘要可用作任何主机都可以访问的唯一标识符。
As with other identifiers, an IP 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.
与其他标识符一样，IP地址可用于关联主机的活动，时间至少与地址的生命周期相同。如果该地址是由其他稳定的标识符生成的，并且攻击者可以推断该生成方案，则相关攻击的持续时间将延长到该标识符的持续时间。在许多情况下，其寿命等于设备本身的寿命。
If a stable identifier is used for assigning an address and such mapping is discovered by an attacker, it can be used for tracking a user. In particular, both passive (a service that the client connects to can log the client's address and draw conclusions regarding its location and movement patterns based on the addresses it is connecting from) and active (an attacker can send ICMP echo requests or other probe packets to networks of suspected client locations) methods 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
如果一个稳定的标识符用于分配地址，并且攻击者发现了这种映射，那么它可以用于跟踪用户。特别是，可以使用被动（客户端连接到的服务可以记录客户端的地址，并根据其连接的地址得出关于其位置和移动模式的结论）和主动（攻击者可以向可疑客户端位置的网络发送ICMP回显请求或其他探测数据包）方法。举一个具体的例子，通过从tomek-laptop.coffee.somecity.com.example、tomek-laptop.mycompany.com.example和tomek-laptop.myisp.example.com访问社交门户，门户管理员可以
conclusions about tomek-laptop's owner's current location and his habits.
关于tomek笔记本电脑所有者当前位置和习惯的结论。
Attackers may pretend to be an access concentrator, either as a DHCP relay agent or as a DHCP client, to obtain location information directly from the DHCP server(s) using the DHCP leasequery [RFC4388] mechanism.
攻击者可以伪装成访问集中器，作为DHCP中继代理或DHCP客户端，使用DHCP租赁[RFC4388]机制直接从DHCP服务器获取位置信息。
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 DHCP bulk leasequery [RFC6926] mechanism to obtain bulk information about DHCP bindings, even without knowing the target bindings.
此外，即使不知道目标绑定，攻击者也可能使用DHCP批量租赁[RFC6926]机制获取有关DHCP绑定的批量信息。
Additionally, active leasequery [RFC7724] is a mechanism for subscribing to DHCP 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.
此外，active leasequery[RFC7724]是一种近实时订阅DHCP租约更新更改的机制。该机制的目的是更新操作员的数据库；但是，如果该机制被滥用，攻击者可能会破坏服务器的身份验证机制并订阅所有更新。然后，他可以继续接收更新，而不需要任何本地存在。
In current practice, the client privacy and client authentication are mutually exclusive. The client authentication procedure reveals additional client information in the certificates and 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 DHCP. As such, no dedicated discussion is needed.
本文档全文讨论DHCP中的隐私注意事项。因此，不需要专门讨论。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<http://www.rfc-editor.org/info/rfc2131>.
[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>.
[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>.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, DOI 10.17487/RFC3046, January 2001, <http://www.rfc-editor.org/info/rfc3046>.
[RFC3046]Patrick，M.，“DHCP中继代理信息选项”，RFC 3046，DOI 10.17487/RFC3046，2001年1月<http://www.rfc-editor.org/info/rfc3046>.
[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>.
[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link Selection sub-option for the Relay Agent Information Option for DHCPv4", RFC 3527, DOI 10.17487/RFC3527, April 2003, <http://www.rfc-editor.org/info/rfc3527>.
[RFC3527]Kinnear，K.，Stapp，M.，Johnson，R.，和J.Kumarasamy，“DHCPv4中继代理信息选项的链路选择子选项”，RFC 3527，DOI 10.17487/RFC3527，2003年4月<http://www.rfc-editor.org/info/rfc3527>.
[RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 3925, DOI 10.17487/RFC3925, October 2004, <http://www.rfc-editor.org/info/rfc3925>.
[RFC3925]Littlefield，J.，“动态主机配置协议版本4（DHCPv4）的供应商识别供应商选项”，RFC 3925，DOI 10.17487/RFC3925，2004年10月<http://www.rfc-editor.org/info/rfc3925>.
[RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 3993, DOI 10.17487/RFC3993, March 2005, <http://www.rfc-editor.org/info/rfc3993>.
[RFC3993]Johnson，R.，Palaniappan，T.，和M.Stapp，“动态主机配置协议（DHCP）中继代理选项的用户ID子选项”，RFC 3993，DOI 10.17487/RFC3993，2005年3月<http://www.rfc-editor.org/info/rfc3993>.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, DOI 10.17487/RFC4361, February 2006, <http://www.rfc-editor.org/info/rfc4361>.
[RFC4361]Lemon，T.和B.Sommerfeld，“动态主机配置协议第四版（DHCPv4）的节点特定客户端标识符”，RFC 4361，DOI 10.17487/RFC4361，2006年2月<http://www.rfc-editor.org/info/rfc4361>.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, DOI 10.17487/RFC4388, February 2006, <http://www.rfc-editor.org/info/rfc4388>.
[RFC4388]Woundy，R.和K.Kinnear，“动态主机配置协议（DHCP）租赁”，RFC 4388，DOI 10.17487/RFC4388，2006年2月<http://www.rfc-editor.org/info/rfc4388>.
[RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)", RFC 4578, DOI 10.17487/RFC4578, November 2006, <http://www.rfc-editor.org/info/rfc4578>.
[RFC4578]Johnston，M.和S.Venaas，编辑，“英特尔预引导执行环境（PXE）的动态主机配置协议（DHCP）选项”，RFC 4578，DOI 10.17487/RFC4578，2006年11月<http://www.rfc-editor.org/info/rfc4578>.
[RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option", RFC 4702, DOI 10.17487/RFC4702, October 2006, <http://www.rfc-editor.org/info/rfc4702>.
[RFC4702]Stapp，M.，Volz，B.，和Y.Rekhter，“动态主机配置协议（DHCP）客户端完全限定域名（FQDN）选项”，RFC 4702，DOI 10.17487/RFC4702，2006年10月<http://www.rfc-editor.org/info/rfc4702>.
[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>.
[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>.
[RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell, N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery", RFC 6926, DOI 10.17487/RFC6926, April 2013, <http://www.rfc-editor.org/info/rfc6926>.
[RFC6926]金尼尔，K.，斯塔普，M.，德塞蒂，R.，乔希，B.，罗素，N.，库拉帕蒂，P.，和B.沃尔兹，“DHCPv4散装租赁”，RFC 6926，DOI 10.17487/RFC6926，2013年4月<http://www.rfc-editor.org/info/rfc6926>.
[RFC7724] Kinnear, K., Stapp, M., Volz, B., and N. Russell, "Active DHCPv4 Lease Query", RFC 7724, DOI 10.17487/RFC7724, December 2015, <http://www.rfc-editor.org/info/rfc7724>.
[RFC7724]Kinnear，K.，Stapp，M.，Volz，B.，和N.Russell，“动态DHCPv4租赁查询”，RFC 7724，DOI 10.17487/RFC77242015年12月<http://www.rfc-editor.org/info/rfc7724>.
Acknowledgements
致谢
The authors would like to thank the valuable comments made by Stephen Farrell, Ted Lemon, Ines Robles, Russ White, Christian Huitema, Bernie Volz, Jinmei Tatuya, Marcin Siodelski, Christian Schaefer, Robert Sparks, Peter Yee, and other members of DHC WG.
作者要感谢斯蒂芬·法雷尔、特德·莱蒙、伊内斯·罗伯斯、罗斯·怀特、克里斯蒂安·惠特马、伯尼·沃兹、金美·塔图亚、马辛·西奥德尔斯基、克里斯蒂安·谢弗、罗伯特·斯帕克斯、彼得·叶和DHC工作组其他成员所作的宝贵评论。
Authors' Addresses
作者地址
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
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