Internet Engineering Task Force (IETF) T. Lemon
Request for Comments: 7969 Nominum, Inc.
Category: Informational T. Mrugalski
ISSN: 2070-1721 ISC
October 2016
Internet Engineering Task Force (IETF) T. Lemon
Request for Comments: 7969 Nominum, Inc.
Category: Informational T. Mrugalski
ISSN: 2070-1721 ISC
October 2016
Customizing DHCP Configuration on the Basis of Network Topology
根据网络拓扑定制DHCP配置
Abstract
摘要
DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and explains their operation.
DHCP服务器经过多年的发展，提供了超出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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第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/rfc7969.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7969.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Identifying Client's Location by DHCP Servers . . . . . . . . 3
3.1. DHCPv4-Specific Behavior . . . . . . . . . . . . . . . . 7
3.2. DHCPv6-Specific Behavior . . . . . . . . . . . . . . . . 7
4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 10
5. Relay Agent Running on a Host . . . . . . . . . . . . . . . . 12
6. Cascaded Relays . . . . . . . . . . . . . . . . . . . . . . . 12
7. Regional Configuration Example . . . . . . . . . . . . . . . 13
8. Multiple Subnets on the Same Link . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Identifying Client's Location by DHCP Servers . . . . . . . . 3
3.1. DHCPv4-Specific Behavior . . . . . . . . . . . . . . . . 7
3.2. DHCPv6-Specific Behavior . . . . . . . . . . . . . . . . 7
4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 10
5. Relay Agent Running on a Host . . . . . . . . . . . . . . . . 12
6. Cascaded Relays . . . . . . . . . . . . . . . . . . . . . . . 12
7. Regional Configuration Example . . . . . . . . . . . . . . . 13
8. Multiple Subnets on the Same Link . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
The DHCPv4 [RFC2131] and DHCPv6 [RFC3315] protocol specifications describe how addresses can be allocated to clients based on network topology information provided by the DHCP relay infrastructure. Address allocation decisions are integral to the allocation of addresses and prefixes in DHCP.
DHCPv4[RFC2131]和DHCPv6[RFC3315]协议规范描述了如何根据DHCP中继基础设施提供的网络拓扑信息将地址分配给客户端。地址分配决策是DHCP中地址和前缀分配的组成部分。
The DHCP protocol also describes mechanisms for provisioning devices with additional configuration information, for example, DNS [RFC1034] server addresses, default DNS search domains, and similar information.
DHCP协议还描述了为设备提供附加配置信息的机制，例如DNS[RFC1034]服务器地址、默认DNS搜索域和类似信息。
Although it was the intent of the authors of these specifications that DHCP servers would provision devices with configuration information appropriate to each device's location on the network, this practice was never documented, much less described in detail.
尽管这些规范的作者希望DHCP服务器为设备提供适合于每个设备在网络上的位置的配置信息，但这种做法从未被记录，更不用说详细描述了。
Existing DHCP server implementations do in fact provide such capabilities; the goal of this document is to describe those capabilities for the benefit of both operators and protocol designers who may wish to use DHCP as a means for configuring their own services but may not be aware of the capabilities provided by most modern DHCP servers.
现有的DHCP服务器实现实际上提供了这样的功能；本文档的目的是为了运营商和协议设计者的利益而描述这些功能，他们可能希望使用DHCP作为配置自己服务的手段，但可能不知道大多数现代DHCP服务器提供的功能。
o CPE device: Customer Premise Equipment device. Typically a router belonging to the customer that connects directly to the provider link.
o CPE设备：客户现场设备设备。通常是属于客户的直接连接到提供商链路的路由器。
o DHCP, DHCPv4, and DHCPv6: DHCP refers to the Dynamic Host Configuration Protocol in general and applies to both DHCPv4 and DHCPv6. The terms DHCPv4 and DHCPv6 are used in contexts where it is necessary to avoid ambiguity and explain differences.
o DHCP、DHCPv4和DHCPv6:DHCP通常指动态主机配置协议，适用于DHCPv4和DHCPv6。术语DHCPv4和DHCPv6用于有必要避免歧义和解释差异的上下文中。
o PE router: Provider Edge router. The provider router closest to the customer.
o PE路由器：提供商边缘路由器。距离客户最近的提供商路由器。
o Routable IP address: An IP address with a scope of use wider than the local link.
o 可路由IP地址：使用范围比本地链路更广的IP地址。
o Shared subnet: A case where two or more subnets of the same protocol family are available on the same link. 'Shared subnet' terminology is typically used in Unix environments. It is typically called 'multinet' in the Windows environment. The administrative configuration inside a Microsoft DHCP server is called 'DHCP Superscope'.
o 共享子网：同一链路上有两个或多个相同协议系列的子网的情况共享子网的术语通常在Unix环境中使用。在Windows环境中，它通常被称为“multinet”。Microsoft DHCP服务器内的管理配置称为“DHCP超级作用域”。
o Link or local link: A layer 2 network link, as defined in Section 1.2 of [RFC3297].
o 链路或本地链路：如[RFC3297]第1.2节所定义的第2层网络链路。
o Link subset: A portion of a link containing a subset of all the connection points on that link, which may be used to finely determine the physical location of a set of clients or may be used to determine topology to a finer degree of detail than the set of all locations at which that particular link is available. The smallest link subset is a single link attachment point, for example, a port on a layer 2 switch.
o 链路子集：链路的一部分，包含该链路上所有连接点的子集，可用于精确确定一组客户端的物理位置，或可用于确定拓扑，其详细程度比该特定链路可用的所有位置集更高。最小的链路子集是单个链路连接点，例如，第2层交换机上的端口。
Figure 1 illustrates a small hierarchy of network links with Link D serving as a backbone to which the DHCP server is attached.
图1显示了一个小型的网络链路层次结构，其中链路D作为连接DHCP服务器的主干。
Figure 2 illustrates a more complex case. Although some of its aspects are unlikely to be seen in actual production networks, they are beneficial for explaining finer aspects of the DHCP protocols. Note that some nodes act as routers (which forward all IP traffic) and some are relay agents (i.e., they run DHCP-specific software that forwards only DHCP traffic).
图2说明了一个更复杂的情况。虽然它的某些方面在实际生产网络中不太可能看到，但它们有助于解释DHCP协议的更精细方面。请注意，有些节点充当路由器（转发所有IP流量），有些节点充当中继代理（即，它们运行仅转发DHCP流量的DHCP特定软件）。
Link A Link B
|===+===========| |===========+======|
| |
| |
+---+---+ +---+---+
| relay | | relay |
| A | | B |
+---+---+ +---+---+
| |
| Link C |
|===+==========+=================+======|
|
|
+----+---+ +--------+
| router | | DHCP |
| A | | Server |
+----+---+ +----+---+
| |
| |
| Link D |
|==============+=================+======|
|
|
+----+---+
| router |
| B |
+----+---+
|
|
|===+==========+=================+======|
| Link E |
| |
+---+---+ +---+---+
| relay | | relay |
| C | | D |
+---+---+ +---+---+
| |
| |
|===+===========| |===========+======|
Link F Link G
Link A Link B
|===+===========| |===========+======|
| |
| |
+---+---+ +---+---+
| relay | | relay |
| A | | B |
+---+---+ +---+---+
| |
| Link C |
|===+==========+=================+======|
|
|
+----+---+ +--------+
| router | | DHCP |
| A | | Server |
+----+---+ +----+---+
| |
| |
| Link D |
|==============+=================+======|
|
|
+----+---+
| router |
| B |
+----+---+
|
|
|===+==========+=================+======|
| Link E |
| |
+---+---+ +---+---+
| relay | | relay |
| C | | D |
+---+---+ +---+---+
| |
| |
|===+===========| |===========+======|
Link F Link G
Figure 1: A Simple Network with a Small Hierarchy of Links
图1：一个简单的网络，链接层次很小
Link A Link B Link H
|===+==========| |=========+======| |======+======|
| | |
| | |
+---+---+ +---+---+ +---+---+
| relay | | relay | | relay |
| A | | B | | G |
+---+---+ +---+---+ +---+---+
| | |
| Link C | | Link J
|===+==========+==============+======| |======+======|
| |
| |
+----+---+ +--------+ +---+---+
| router | | DHCP | | relay |
| A | | Server | | F |
+----+---+ +----+---+ +---+---+
| | |
| | |
| Link D | |
|==============+=========+=======+=============+======|
| |
| |
+----+---+ +---+---+
| router | | relay |
| B | | E |
+----+---+ +---+---+
| |
| |
|===+==========+=========+=======+======|
| Link E |
| |
+---+---+ +---+---+
| relay | | relay |
| C | | D |
+---+---+ +---+---+
| |
| |
|===+===========| |===========+======|
Link F Link G
Link A Link B Link H
|===+==========| |=========+======| |======+======|
| | |
| | |
+---+---+ +---+---+ +---+---+
| relay | | relay | | relay |
| A | | B | | G |
+---+---+ +---+---+ +---+---+
| | |
| Link C | | Link J
|===+==========+==============+======| |======+======|
| |
| |
+----+---+ +--------+ +---+---+
| router | | DHCP | | relay |
| A | | Server | | F |
+----+---+ +----+---+ +---+---+
| | |
| | |
| Link D | |
|==============+=========+=======+=============+======|
| |
| |
+----+---+ +---+---+
| router | | relay |
| B | | E |
+----+---+ +---+---+
| |
| |
|===+==========+=========+=======+======|
| Link E |
| |
+---+---+ +---+---+
| relay | | relay |
| C | | D |
+---+---+ +---+---+
| |
| |
|===+===========| |===========+======|
Link F Link G
Figure 2: Complex Network
图2：复杂网络
These diagrams allow us to represent a variety of different network configurations and illustrate how existing DHCP servers can provide configuration information customized to the particular location from which a client is making its request.
这些图使我们能够表示各种不同的网络配置，并说明现有DHCP服务器如何根据客户机发出请求的特定位置提供定制的配置信息。
It is important to understand the background of how DHCP works when considering those diagrams. It is assumed that the DHCP clients may not have routable IP addresses when they are attempting to obtain configuration information.
在考虑这些图表时，了解DHCP如何工作的背景非常重要。假设DHCP客户端在试图获取配置信息时可能没有可路由的IP地址。
The reason for making this assumption is that one of the functions of DHCP is to bootstrap the DHCP client's IP address configuration. If the client does not yet have an IP address configured, it cannot route packets to an off-link DHCP server; therefore, some kind of relay mechanism is required.
做出这种假设的原因是DHCP的功能之一是引导DHCP客户端的IP地址配置。如果客户端尚未配置IP地址，则无法将数据包路由到断开链接的DHCP服务器；因此，需要某种中继机制。
The details of how packet delivery between clients and servers works are different between DHCPv4 and DHCPv6, but the essence is the same: whether or not the client actually has an IP configuration, it generally communicates with the DHCP server by sending its requests to a DHCP relay agent on the local link; this relay agent, which has a routable IP address, then forwards the DHCP requests to the DHCP server (directly or via other relays). In later stages of the configuration, when the client has acquired an address and certain conditions are met, it is possible for the client to send packets directly to the server, thus bypassing the relays. The conditions for such behavior are different for DHCPv4 and DHCPv6 and are discussed in Sections 3.1 and 3.2.
在DHCPv4和DHCPv6之间，客户端和服务器之间的数据包传递工作原理的细节不同，但本质是相同的：无论客户端是否实际具有IP配置，它通常通过将其请求发送到本地链路上的DHCP中继代理来与DHCP服务器通信；该中继代理具有可路由的IP地址，然后将DHCP请求转发到DHCP服务器（直接或通过其他中继）。在配置的后期阶段，当客户端获得地址并且满足某些条件时，客户端可以直接向服务器发送数据包，从而绕过中继。对于DHCPv4和DHCPv6，此类行为的条件不同，第3.1节和第3.2节对此进行了讨论。
To determine the client's point of attachment and link-specific configuration, the server typically uses the client-facing IP address of the relay agent. In some cases, the server may use the routable IP address of the client if the client has the routable IP address assigned to its interface and it is transmitted in the DHCP message. The server is then able to determine the client's point of attachment and select the appropriate subnet- or link-specific configuration.
为了确定客户端的连接点和特定于链路的配置，服务器通常使用中继代理面向客户端的IP地址。在某些情况下，如果客户端将可路由IP地址分配给其接口，并且在DHCP消息中传输，则服务器可能会使用客户端的可路由IP地址。然后，服务器可以确定客户端的连接点，并选择适当的子网或特定于链路的配置。
Sometimes it is useful for the relay agents to provide additional information about the topology. A number of extensions have been defined for this purpose. The specifics are different, but the core principle remains the same: the relay agent knows exactly where the original request came from, so it provides an identifier that will help the server to choose appropriate address pool and configuration parameters. Examples of such options are mentioned in the following sections.
有时，中继代理提供有关拓扑的附加信息很有用。为此，已经定义了许多扩展。具体细节有所不同，但核心原则保持不变：中继代理确切地知道原始请求来自何处，因此它提供了一个标识符，可以帮助服务器选择适当的地址池和配置参数。以下各节将介绍此类选项的示例。
Finally, clients may be connected to the same link as the server, so no relay agents are required. In such cases, the DHCPv4 server typically uses the IPv4 address assigned to the network interface over which the transmission was received to select an appropriate subnet. This is more complicated for DHCPv6, as the DHCPv6 server is not required to have any globally unique addresses. In such cases,
最后，客户端可以连接到与服务器相同的链路，因此不需要中继代理。在这种情况下，DHCPv4服务器通常使用分配给接收传输的网络接口的IPv4地址来选择适当的子网。这对于DHCPv6来说更为复杂，因为DHCPv6服务器不需要具有任何全局唯一的地址。在这种情况下，
additional configuration information may need to be required. Some servers allow indicating that a given subnet is directly reachable over a specific local network interface.
可能需要额外的配置信息。某些服务器允许指示给定子网可通过特定的本地网络接口直接访问。
In some cases in DHCPv4, when a DHCPv4 client has a routable IPv4 address, the message is unicast to the DHCPv4 server rather than going through a relay agent. Examples of such transmissions are renewal (DHCPREQUEST) and address release (DHCPRELEASE).
在DHCPv4的某些情况下，当DHCPv4客户端具有可路由的IPv4地址时，消息将单播到DHCPv4服务器，而不是通过中继代理。此类传输的示例包括续订（DHCPREQUEST）和地址释放（DHCPRELEASE）。
The relay agent that receives the client's message sets the giaddr field to the address of the network interface the message was received on. The relay agent may insert a relay agent option [RFC3046].
接收客户端消息的中继代理将giaddr字段设置为接收消息的网络接口的地址。中继代理可以插入中继代理选项[RFC3046]。
There are several options defined that are useful for subnet selection in DHCPv4. [RFC3527] defines the Link Selection sub-option that is inserted by a relay agent. This option is particularly useful when the relay agent needs to specify the subnet/link on which a DHCPv4 client resides, which is different from an IP address that can be used to communicate with the relay agent. The Virtual Subnet Selection (VSS) sub-option, specified in [RFC6607], can also be added by a relay agent to specify information in a VPN environment. In certain cases, it is useful for the client itself to specify the Virtual Subnet Selection option, e.g., when there are no relay agents involved during the VPN setup process.
在DHCPv4中定义了多个选项，可用于选择子网。[RFC3527]定义中继代理插入的链路选择子选项。当中继代理需要指定DHCPv4客户端所在的子网/链路时，此选项特别有用，该子网/链路不同于可用于与中继代理通信的IP地址。中继代理还可以添加[RFC6607]中指定的虚拟子网选择（VSS）子选项，以指定VPN环境中的信息。在某些情况下，客户端本身指定虚拟子网选择选项非常有用，例如，在VPN设置过程中不涉及中继代理时。
Another option that may influence the subnet selection is the IPv4 Subnet Selection option, defined in [RFC3011], which allows the client to explicitly request allocation from a given subnet.
另一个可能影响子网选择的选项是[RFC3011]中定义的IPv4子网选择选项，该选项允许客户端从给定子网显式请求分配。
In DHCPv6, unicast communication is possible in cases where the server is configured with a Server Unicast option (see Section 22.12 in [RFC3315]) and clients are able to take advantage of it. In such cases, once a client is assigned a (presumably global) address, it is able to contact the server directly, bypassing any relays. It should be noted that such a mode is completely controllable by administrators in DHCPv6. (They may simply choose to not configure the Server Unicast option, thus forcing clients to always send their messages via relay agents in every case).
在DHCPv6中，如果服务器配置了服务器单播选项（参见[RFC3315]中的第22.12节），并且客户端能够利用该选项，则可以进行单播通信。在这种情况下，一旦客户机被分配了一个（可能是全局的）地址，它就可以绕过任何中继直接与服务器联系。需要注意的是，DHCPv6中的管理员完全可以控制这种模式。（他们可能只是选择不配置服务器单播选项，从而强制客户端在任何情况下都始终通过中继代理发送消息）。
The DHCPv6 protocol [RFC3315] defines two core mechanisms that allow a server to distinguish which link the relay agent is connected to. The first mechanism is the link-address field in the Relay-forward and Relay-reply messages. The link-address field uniquely identifies
DHCPv6协议[RFC3315]定义了两种核心机制，允许服务器区分中继代理连接到哪个链路。第一种机制是中继转发和中继回复消息中的链路地址字段。链接地址字段唯一标识
the link and should not be mistaken for a link-local address. In normal circumstances, this is the solution that is easiest to maintain, as existing address assignments can be used and no additional administrative actions (like assigning dedicated identifiers for each relay agent, making sure they are unique, and maintaining a list of such identifiers) are needed. It requires, however, for the relay agent to have an address with a scope larger than link-local configured on its client-facing interface.
链接和不应被误认为是链接本地地址。在正常情况下，这是最容易维护的解决方案，因为可以使用现有的地址分配，并且不需要额外的管理操作（例如为每个中继代理分配专用标识符，确保它们是唯一的，并维护此类标识符的列表）。但是，中继代理需要在其面向客户端的接口上配置一个作用域大于本地链路的地址。
The second mechanism uses an Interface-ID option (see Section 22.18 of [RFC3315]) inserted by the relay agent, which identifies the link that the client is connected to. This mechanism may be used when the relay agent does not have a globally unique address or Unique Local Address (ULA) [RFC4193] configured on its client-facing interface, thus making the first mechanism not feasible. If the interface-id is unique within an administrative domain, the interface-id value may be used to select the appropriate subnet. As there is no guarantee for the uniqueness ([RFC3315] only mandates the interface-id to be unique within a single relay agent context), it is up to the administrator to check whether the relay agents deployed use unique interface-id values. If the interface-id values are not unique, the Interface-ID option cannot be used to determine the client's point of attachment.
第二种机制使用中继代理插入的接口ID选项（参见[RFC3315]第22.18节），该选项标识客户端连接到的链路。当中继代理没有在其面向客户端的接口上配置全局唯一地址或唯一本地地址（ULA）[RFC4193]时，可以使用该机制，从而使得第一种机制不可行。如果接口id在管理域中是唯一的，则可以使用接口id值选择适当的子网。由于无法保证唯一性（[RFC3315]仅要求接口id在单个中继代理上下文中是唯一的），因此应由管理员检查部署的中继代理是否使用唯一的接口id值。如果接口id值不唯一，则接口id选项不能用于确定客户端的连接点。
It should be noted that Relay-forward and Relay-reply messages are exchanged between relays and servers only. Clients are never exposed to those messages. Also, servers never receive Relay-reply messages. Relay agents must be able to process both Relay-forward (sending an already relayed message further towards the server when there is more than one relay agent in a chain) and Relay-reply (sending back the response towards the client when there is more than one relay agent in a chain).
应该注意的是，中继转发和中继回复消息仅在中继和服务器之间交换。客户端永远不会暴露于这些消息。此外，服务器从不接收中继回复消息。中继代理必须能够处理中继转发（当链中有多个中继代理时，将已中继的消息进一步发送到服务器）和中继回复（当链中有多个中继代理时，将响应发送回客户端）。
For completeness, we also mention an uncommon but valid case where relay agents use a link-local address in the link-address field in relayed Relay-forward messages. This may happen if the relay agent doesn't have any address with a larger scope on the interface connected to that specific link. Even though link-local addresses cannot be automatically used to associate the relay agent with a given link, with additional configuration information, the server may still be able to select the proper link.
为完整起见，我们还提到了一种罕见但有效的情况，即中继代理在中继转发消息的链接地址字段中使用链接本地地址。如果中继代理在连接到该特定链接的接口上没有任何范围更大的地址，则可能发生这种情况。即使链路本地地址不能自动用于将中继代理与给定链路关联，但服务器仍可以选择适当的链路，并提供其他配置信息。
This requires that the DHCP server has a way of associating a particular link-local address with a particular link. The network administrator can then explicitly configure the DHCP server to recognize that the particular link-address field in a relay message refers to that link.
这要求DHCP服务器具有将特定链接本地地址与特定链接关联的方法。然后，网络管理员可以显式配置DHCP服务器，以识别中继消息中的特定链路地址字段引用该链路。
There are two ways that this can work. One is that the DHCP server can provide a mechanism that explicitly associates the link-local address with a link. In this case, the network administrator simply determines the link-local address of the relay agent on a particular link, which we are presuming to be stable, and configures an association between that address and the link.
有两种方法可以起作用。一种是DHCP服务器可以提供一种机制，将链接本地地址与链接显式关联。在这种情况下，网络管理员只需确定特定链路上中继代理的链路本地地址（我们假定该地址是稳定的），并配置该地址与链路之间的关联。
If the DHCP server doesn't explicitly provide such a mechanism, it may still provide a "shared subnet" mechanism (see Section 8). If it does, the shared subnet mechanism can be used to explicitly associate a link-local address with a link. To do this, the network administrator creates a shared subnet association for the link, if one does not already exist. The network administrator then configures a /128 subnet that contains just the link-local address of the relay agent. The administrator then adds this new /128 to the shared subnet. Now, when a DHCP message comes in with that link-layer address in the link-address field, the correct shared network will be selected.
如果DHCP服务器没有明确提供这种机制，它可能仍然提供“共享子网”机制（参见第8节）。如果是，则可以使用共享子网机制将链路本地地址与链路显式关联。为此，网络管理员将为链路创建一个共享子网关联（如果还不存在）。然后，网络管理员配置仅包含中继代理的链路本地地址的/128子网。然后，管理员将此新的/128添加到共享子网。现在，当DHCP消息在链接地址字段中包含该链接层地址时，将选择正确的共享网络。
DHCPv6 also has support for more finely grained link identification using Lightweight DHCPv6 Relay Agents (LDRAs) [RFC6221]. In this case, the link-address field is set to an unspecified address (::), but the DHCPv6 server also receives an Interface-ID option from the relay agent that can be used to more precisely identify the client's location on the network. It is possible to mix LDRA and regular relay agents in the same network. See Sections 7.2 and 7.3 in [RFC6221] for detailed examples.
DHCPv6还支持使用轻量级DHCPv6中继代理（LDRA）进行更细粒度的链路识别[RFC6221]。在这种情况下，链接地址字段设置为未指定的地址（：），但DHCPv6服务器还从中继代理接收接口ID选项，该选项可用于更精确地标识客户端在网络上的位置。可以在同一网络中混合使用LDRA和常规中继代理。有关详细示例，请参见[RFC6221]中的第7.2节和第7.3节。
What this means in practice is that the DHCP server has sufficient information in all cases to pinpoint the link to which the client is connected. In some cases, it may additionally be possible to pinpoint the particular link subset to which the client is connected.
这在实践中意味着DHCP服务器在所有情况下都有足够的信息来确定客户端所连接的链接。在某些情况下，还可以精确定位客户端所连接的特定链路子集。
In all cases, then, the DHCPv6 server will have a link-identifying IP address, and in some cases, it may also have a link-specific identifier (e.g., the Interface-ID option or the Link Address option defined in Section 5 of [RFC6977]). It should be noted that the link-specific identifier is unique only within the scope of the link-identifying IP address. For example, the link-specific identifier of "eth0" assigned to a relay agent using IPv6 address 2001:db8::1 is distinct from an "eth0" identifier used by a different relay agent with address 2001:db8::2.
因此，在所有情况下，DHCPv6服务器都将具有标识IP地址的链路，在某些情况下，它还可能具有特定于链路的标识符（例如，[RFC6977]第5节中定义的接口ID选项或链路地址选项）。应当注意，链路特定标识符仅在链路标识IP地址的范围内是唯一的。例如，分配给使用IPv6地址2001:db8:：1的中继代理的特定于链路的标识符“eth0”与地址2001:db8:：2的其他中继代理使用的“eth0”标识符不同。
It is also possible for link-specific identifiers to be nested so that the actual identifier that identifies the specific link subset is an aggregate of two or more identifiers sent by a set of LDRAs in a chain; in general, this functions exactly as if a single identifier were received from a single LDRA, so we do not treat it specially in
还可以嵌套链路特定标识符，使得标识特定链路子集的实际标识符是由链中的一组ldra发送的两个或多个标识符的集合；一般来说，它的功能与从单个LDRA接收单个标识符的功能完全相同，因此我们不会在
the discussion below, but sites that use chained LDRA configurations will need to be aware of this when configuring their DHCPv6 servers.
下面将讨论，但是使用链式LDRA配置的站点在配置其DHCPv6服务器时需要注意这一点。
The Virtual Subnet Selection options, present in DHCPv4, are also defined for DHCPv6. The use case is the same as in DHCPv4: the relay agent inserts VSS options that can help the server to select the appropriate subnet with its address pool and associated configuration options. See [RFC6607] for details.
DHCPv4中的虚拟子网选择选项也为DHCPv6定义。该用例与DHCPv4中的相同：中继代理插入VSS选项，以帮助服务器选择适当的子网及其地址池和相关配置选项。详见[RFC6607]。
Consider Figure 1 in the context of a simple subnetted network. In this network, there are four leaf subnets on which DHCP clients will be configured: Links A, B, F, and G. Relays A, B, C, and D in this example are represented in the diagram as IP routers with an embedded relay function, because this is a very typical configuration, but the relay function can also be provided in a separate node on each link.
在简单的子网网络的上下文中考虑图1。在该网络中，有四个叶子网将配置DHCP客户端：链路A、B、F和G。在本例中，中继A、B、C和D在图中表示为具有嵌入式中继功能的IP路由器，因为这是一种非常典型的配置，但中继功能也可以在每个链路上的单独节点中提供。
In a simple network like this, there may be no need for link-specific configuration in DHCPv6, since local routing information is delivered through router advertisements. However, in IPv4, it is very typical to configure the default route using DHCP; in this case, the default route will be different on each link. In order to accomplish this, the DHCP server will need link-specific configuration for the default route.
在这样一个简单的网络中，DHCPv6中可能不需要特定于链路的配置，因为本地路由信息是通过路由器广告传递的。然而，在IPv4中，使用DHCP配置默认路由是非常典型的；在这种情况下，每条链路上的默认路由将不同。为了实现这一点，DHCP服务器需要对默认路由进行特定于链路的配置。
To illustrate, we will use an example from a hypothetical DHCP server that uses a simple JSON notation [RFC7159] for configuration. Although we know of no DHCP server that uses this specific syntax, most modern DHCP servers provide similar functionality.
为了说明这一点，我们将使用一个假设的DHCP服务器的示例，该服务器使用简单的JSON符号[RFC7159]进行配置。虽然我们知道没有使用这种特定语法的DHCP服务器，但大多数现代DHCP服务器都提供类似的功能。
{
"prefixes": {
"192.0.2.0/26": {
"options": {
"routers": ["192.0.2.1"]
},
"on-link": ["A"]
},
"192.0.2.64/26": {
"options": {
"routers": ["192.0.2.65"]
},
"on-link": ["B"]
},
"192.0.2.128/26": {
"options": {
"routers": ["192.0.2.129"]
},
"on-link": ["F"]
},
"192.0.2.192/26": {
"options": {
"routers": ["192.0.2.193"]
},
"on-link": ["G"]
}
}
}
{
"prefixes": {
"192.0.2.0/26": {
"options": {
"routers": ["192.0.2.1"]
},
"on-link": ["A"]
},
"192.0.2.64/26": {
"options": {
"routers": ["192.0.2.65"]
},
"on-link": ["B"]
},
"192.0.2.128/26": {
"options": {
"routers": ["192.0.2.129"]
},
"on-link": ["F"]
},
"192.0.2.192/26": {
"options": {
"routers": ["192.0.2.193"]
},
"on-link": ["G"]
}
}
}
Figure 3: Configuration Example
图3：配置示例
In Figure 3, we see a configuration example for this scenario: a set of prefixes, each of which has a set of options and a list of links for which it is on-link. We have defined one option for each prefix: a routers option. This option contains a list of values; each list only has one value, and that value is the IP address of the router specific to the prefix.
在图3中，我们看到了这个场景的一个配置示例：一组前缀，每个前缀都有一组选项和一个链接列表，它位于链接上。我们为每个前缀定义了一个选项：路由器选项。此选项包含一个值列表；每个列表只有一个值，该值是特定于前缀的路由器的IP地址。
When the DHCP server receives a request, it searches the list of prefixes for one that encloses the link-identifying IP address provided by the client or relay agent. The DHCP server then examines the options list associated with that prefix and returns those options to the client.
当DHCP服务器收到请求时，它会在前缀列表中搜索包含由客户端或中继代理提供的标识IP地址的链接的前缀。然后，DHCP服务器检查与该前缀关联的选项列表，并将这些选项返回给客户端。
So, for example, a client connected to Link A in the example would have a link-identifying IP address within the 192.0.2.0/26 prefix, so the DHCP server would match it to that prefix. Based on the configuration, the DHCP server would then return a routers option
因此，例如，在本例中，连接到链路a的客户端将在192.0.2.0/26前缀内具有标识IP地址的链路，因此DHCP服务器将其与该前缀匹配。根据配置，DHCP服务器将返回一个路由器选项
containing a single IP address: 192.0.2.1. A client on Link F would have a link-identifying address in the 192.0.2.128/26 prefix and would receive a routers option containing the IP address 192.0.2.129.
包含单个IP地址：192.0.2.1。链路F上的客户端将在192.0.2.128/26前缀中有一个链路标识地址，并将接收一个包含IP地址192.0.2.129的路由器选项。
A relay agent is DHCP software that may be run on any IP node. Although it is typically run on a router, this is by no means required by the DHCP protocol. The relay agent is simply a service that operates on a link, receiving link-local multicasts (IPv6) or broadcasts (IPv4) and relaying them, using IP routing, to a DHCP server. As long as the relay has an IP address on the link and a default route or a more specific route through which it can reach a DHCP server, it need not be a router or even have multiple interfaces.
中继代理是可以在任何IP节点上运行的DHCP软件。虽然它通常在路由器上运行，但这绝不是DHCP协议所要求的。中继代理只是一种在链路上运行的服务，它接收链路本地多播（IPv6）或广播（IPv4），并使用IP路由将它们中继到DHCP服务器。只要中继在链路上有一个IP地址和一个默认路由或一个更具体的路由，通过它可以到达DHCP服务器，它就不需要是路由器，甚至不需要有多个接口。
A relay agent can be run on a host connected to two links. That case is presented in Figure 2. There is router B that is connected to Links D and E. At the same time, there is also a host that is connected to the same links. The relay agent software is running on that host. That is uncommon but is a valid configuration.
中继代理可以在连接到两条链路的主机上运行。这种情况如图2所示。有一个路由器B连接到链路D和E。同时，还有一个主机连接到相同的链路。中继代理软件正在该主机上运行。这并不常见，但却是一种有效的配置。
Let's observe another case, shown in Figure 2. Note that in this configuration, the clients connected to Link G will send their requests to relay D, which will forward its packets directly to the DHCP server. That is typical but not the only possible configuration. It is possible to configure relay agent D to forward client messages to relay E, which in turn will send them to the DHCP server. This configuration is sometimes referred to as "cascaded relay agents".
让我们观察另一种情况，如图2所示。请注意，在此配置中，连接到链路G的客户端将向中继D发送请求，中继D将其数据包直接转发到DHCP服务器。这是典型的，但不是唯一可能的配置。可以将中继代理D配置为将客户端消息转发到中继E，中继E将把它们发送到DHCP服务器。这种配置有时被称为“级联中继代理”。
Note that the relaying mechanism works differently in DHCPv4 and in DHCPv6. In DHCPv4, only the first relay is able to set the giaddr field in the DHCPv4 packet. Any following relays that receive that packet will not change it as the server needs giaddr information from the first relay (i.e., the closest to the client). The server will send the response back to the giaddr address, which is the address of the first relay agent that saw the client's message. That means that the client messages travel on a different path than the server's responses. A message from a client connected to Link G will pass through relay D, then through relay E, to reach the server. A response message will be sent from the server to relay D via router B, and relay D will send it to the client on Link G.
请注意，中继机制在DHCPv4和DHCPv6中的工作方式不同。在DHCPv4中，只有第一个中继能够在DHCPv4数据包中设置giaddr字段。由于服务器需要来自第一个中继（即离客户端最近的中继）的giaddr信息，因此接收该数据包的任何后续中继都不会更改该数据包。服务器将把响应发送回giaddr地址，该地址是看到客户端消息的第一个中继代理的地址。这意味着客户端消息的传输路径与服务器的响应路径不同。来自连接到链路G的客户端的消息将通过中继器D，然后通过中继器E到达服务器。响应消息将通过路由器B从服务器发送到中继器D，中继器D将通过链路G发送到客户端。
Relaying in DHCPv6 is more structured. Each relay agent encapsulates a packet that is destined to the server and sends it towards the server. Depending on the configuration, that can be a server's unicast address, a multicast address, or the next relay agent address. The next relay repeats the encapsulation process. Although the resulting packet is more complex (may have up to 32 levels of encapsulation if the packet traveled through 32 relays), every relay may insert its own options, and it is clear which relay agent inserted which option.
DHCPv6中的中继更加结构化。每个中继代理封装一个发送到服务器的数据包，并将其发送到服务器。根据配置，可以是服务器的单播地址、多播地址或下一个中继代理地址。下一个继电器重复封装过程。尽管生成的数据包更复杂（如果数据包通过32个中继器，则可能具有多达32个封装级别），但每个中继器都可以插入自己的选项，并且很清楚哪个中继器代理插入了哪个选项。
In the Figure 2 example, Link C is a regional backbone for an ISP. Link E is also a regional backbone for that ISP. Relays A, B, C, and D are PE routers, and Links A, B, F, and G are actually link aggregators with individual layer 2 circuits to each customer -- for example, the relays might be Digital Subscriber Line Access Multiplexers (DSLAMs) or cable head-end systems. At each customer site, we assume there is a single CPE device attached to the link.
在图2的示例中，链路C是ISP的区域主干。链路E也是该ISP的区域主干网。中继器A、B、C和D是PE路由器，链路A、B、F和G实际上是链路聚合器，每个客户都有单独的第2层电路——例如，中继器可能是数字用户线路接入多路复用器（DSLAM）或电缆头端系统。在每个客户站点，我们假设有一个连接到链路的CPE设备。
We further assume that Links A, B, F, and G are each addressed by a single prefix, although it would be equally valid for each CPE device to be numbered on a separate prefix.
我们进一步假设链路A、B、F和G均由单个前缀寻址，尽管在单独的前缀上对每个CPE设备进行编号同样有效。
In a real-world deployment, there would likely be many more than two PE routers connected to each regional backbone; we have kept the number small for simplicity.
在实际部署中，可能会有两个以上的PE路由器连接到每个区域主干网；为了简单起见，我们把数字保持在小范围内。
In the example presented in Figure 4, the goal is to configure all the devices within a region with server addresses local to that region, so that service traffic does not have to be routed between regions unnecessarily.
在图4所示的示例中，目标是使用该区域的本地服务器地址配置该区域内的所有设备，以便不必在区域之间不必要地路由服务流量。
{
"prefixes": {
"2001:db8::/40": {
"on-link": ["A"]
},
"2001:db8:100::/40": {
"on-link": ["B"]
},
"2001:db8:200::/40": {
"on-link": ["F"]
},
"2001:db8:300::/40": {
"on-link": ["G"]
}
},
"links": {
"A": {"region": "omashu"},
"B": {"region": "omashu"},
"F": {"region": "gaoling"},
"G": {"region": "gaoling"}
},
"regions": {
"omashu": {
"options": {
"SIP Server": ["sip.omashu.example.org"],
"DNS Recursive Name Server": ["dns1.omashu.example.org",
"dns2.omashu.example.org"]
}
},
"gaoling": {
"options": {
"SIP Server": ["sip.gaoling.example.org"],
"DNS Recursive Name Server": ["dns1.gaoling.example.org",
"dns2.gaoling.example.org"]
}
}
}
}
{
"prefixes": {
"2001:db8::/40": {
"on-link": ["A"]
},
"2001:db8:100::/40": {
"on-link": ["B"]
},
"2001:db8:200::/40": {
"on-link": ["F"]
},
"2001:db8:300::/40": {
"on-link": ["G"]
}
},
"links": {
"A": {"region": "omashu"},
"B": {"region": "omashu"},
"F": {"region": "gaoling"},
"G": {"region": "gaoling"}
},
"regions": {
"omashu": {
"options": {
"SIP Server": ["sip.omashu.example.org"],
"DNS Recursive Name Server": ["dns1.omashu.example.org",
"dns2.omashu.example.org"]
}
},
"gaoling": {
"options": {
"SIP Server": ["sip.gaoling.example.org"],
"DNS Recursive Name Server": ["dns1.gaoling.example.org",
"dns2.gaoling.example.org"]
}
}
}
}
Figure 4: Regional Configuration Example
图4：区域配置示例
In this example, when a request comes in to the DHCPv6 server with a link-identifying IP address in the 2001:db8::/40 prefix, it is identified as being on Link A. The DHCPv6 server then looks on the list of links to see what region the client is in. Link A is identified as being in omashu. The DHCPv6 server then looks up omashu in the set of regions and discovers a list of region-specific options.
在本例中，当请求进入DHCPv6服务器时，带有标识IP地址的链接（在2001:db8:：/40前缀中），它被标识为位于链接a上。然后，DHCPv6服务器查看链接列表以查看客户端所在的区域。链接A被确定为在omashu中。然后，DHCPv6服务器在区域集中查找omashu，并发现特定于区域的选项列表。
The DHCPv6 server then resolves the domain names listed in the options and sends a SIP Server option containing the IP addresses that the resolver returned for sip.omashu.example.org and a DNS Recursive Name Server option containing the IP addresses returned by the resolver for dns1.omashu.example.org and dns2.omashu.example.org. Depending on the server capability and configuration, it may cache resolved responses for a specific period of time, repeat queries every time, or even keep the response until reconfiguration or shutdown. For more detailed discussion, see Section 7 of [RFC7227].
然后，DHCPv6服务器解析选项中列出的域名，并发送包含解析程序为SIP.omashu.example.org返回的IP地址的SIP服务器选项和包含解析程序为dns1.omashu.example.org和dns2.omashu.example.org返回的IP地址的DNS递归名称服务器选项。根据服务器的功能和配置，它可能会在特定的时间段内缓存已解析的响应，每次都重复查询，甚至在重新配置或关闭之前保留响应。有关更详细的讨论，请参见[RFC7227]第7节。
Similarly, if the DHCPv6 server receives a request from a DHCPv6 client where the link-identifying IP address is contained by the prefix 2001:db8:300::/40, then the DHCPv6 server identifies the client as being connected to Link G. The DHCPv6 server then identifies Link G as being in the gaoling region and returns the SIP Server and DNS Recursive Name Server options specific to that region.
类似地，如果DHCPv6服务器接收到来自DHCPv6客户端的请求，其中标识IP地址的链接包含在前缀2001:db8:300:：/40中，然后，DHCPv6服务器将客户端标识为连接到链路G。然后，DHCPv6服务器将链路G标识为位于高陵地区，并返回特定于该地区的SIP服务器和DNS递归名称服务器选项。
As with the previous example, the exact configuration syntax and structure shown above does not precisely match what existing DHCPv6 servers do, but the behavior illustrated in this example can be accomplished with most existing modern DHCPv6 servers.
与前一个示例一样，上面显示的确切配置语法和结构与现有DHCPv6服务器的功能并不完全匹配，但是本示例中所示的行为可以通过大多数现有的现代DHCPv6服务器来实现。
There are scenarios where there is more than one subnet from the same protocol family (i.e., two or more IPv4 subnets or two or more IPv6 subnets) configured on the same link. Such a configuration is often referred to as 'shared subnets' in Unix environments or 'multinet' in Microsoft terminology.
在某些情况下，同一链路上配置了来自同一协议系列的多个子网（即两个或多个IPv4子网或两个或多个IPv6子网）。这种配置在Unix环境中通常称为“共享子网”，在Microsoft术语中通常称为“多网”。
The most frequently mentioned use case is a network renumbering where some services are migrated to the new addressing scheme, but some aren't yet.
最常提到的用例是网络重新编号，其中一些服务迁移到新的寻址方案，但有些尚未迁移。
A second example is expanding the allocation space. In DHCPv4 and for DHCPv6 Prefix Delegation, there could be cases where multiple subnets are needed, because a single subnet may be too small to accommodate the client population.
第二个例子是扩展分配空间。在DHCPv4和DHCPv6前缀委派中，可能需要多个子网，因为单个子网可能太小，无法容纳客户端人口。
The third use case covers allocating addresses (or delegation prefixes) that are not the same as topological information. For example, the link-address is on prefix X, and the addresses to be assigned are on prefix Y. This could be based on differentiating information (i.e., whether the device is a CPE or cable modem in the Data Over Cable Service Interface Specification (DOCSIS)) or just because the link-address/giaddr is different from the actual allocation space.
第三个用例涉及分配与拓扑信息不同的地址（或委派前缀）。例如，链路地址位于前缀X上，而要分配的地址位于前缀Y上。这可能是基于区分信息（即，设备是有线数据服务接口规范（DOCSIS）中的CPE还是电缆调制解调器），或者仅仅因为链路地址/giaddr与实际分配空间不同。
The fourth use case is a cable network, where cable modems and the devices connected behind them are connected to the same layer 2 link. However, operators want the cable modems and user devices to get addresses from distinct address spaces, so users couldn't easily access their modems' management interfaces.
第四个用例是电缆网络，其中电缆调制解调器及其后面连接的设备连接到同一层2链路。然而，运营商希望有线调制解调器和用户设备从不同的地址空间获取地址，因此用户无法轻松访问调制解调器的管理界面。
To support such a configuration, additional differentiating information is required. Many DHCP server implementations offer a feature that is typically called "client classification". The server segregates incoming packets into one or more classes based on certain packet characteristics, e.g., the presence or value of certain options or even a match between existing options. Servers require additional information to handle such configuration, as they cannot use the topographical property of the relay addresses alone to properly choose a subnet. Exact details of such an operation are not part of the DHCPv4 or DHCPv6 protocols and are implementation dependent.
为了支持这种配置，需要额外的差异化信息。许多DHCP服务器实现提供了一种通常称为“客户机分类”的功能。服务器基于特定分组特征（例如，特定选项的存在或值，甚至现有选项之间的匹配）将传入分组划分为一个或多个类。服务器需要额外的信息来处理此类配置，因为它们无法单独使用中继地址的地形属性来正确选择子网。此类操作的确切细节不属于DHCPv4或DHCPv6协议的一部分，且取决于实现。
This document explains existing practice with respect to the use of Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host Configuration Protocol Version 6 [RFC3315]. The security considerations for these protocols are described in their specifications and in related documents that extend these protocols.
本文件解释了有关使用动态主机配置协议[RFC2131]和动态主机配置协议版本6[RFC3315]的现有实践。这些协议的安全注意事项在其规范和扩展这些协议的相关文档中进行了描述。
The mechanisms described in this document could possibly be exploited by an attacker to misrepresent its point of attachment in the network. This would cause the server to assign addresses, prefixes, and other configuration options, which can be considered a leak of information. In particular, this could be used as a preliminary stage of an attack when the DHCP server leaks information about available services in parts of the network the attacker does not have access to.
攻击者可能利用本文档中描述的机制在网络中歪曲其连接点。这将导致服务器分配地址、前缀和其他配置选项，这可能被视为信息泄漏。特别是，当DHCP服务器泄漏攻击者无法访问的部分网络中可用服务的信息时，这可能被用作攻击的初始阶段。
There are several ways that such an attack can be prevented. First, it is a common practice to filter DHCP traffic passing to clients within a particular administrative domain from outside of that domain, and also to filter DHCP traffic to clients outside of a particular administrative domain from within that domain. Second, the DHCP servers can be configured to not respond to traffic that is coming from unknown subnets (i.e., those subnets the server is not configured to serve). Third, some relays provide the ability to reject messages that do not fit expected characteristics. For example, the Cable Modem Termination System (CMTS) acting as a DHCP relay detects if the Media Access Control (MAC) address specified in chaddr in incoming DHCP messages matches the MAC address of the cable modem it came from and can alter its behavior accordingly. Also,
有几种方法可以防止这种攻击。首先，通常的做法是从特定管理域外部过滤传递到该域内的客户端的DHCP流量，以及从该域内部过滤到特定管理域外部的客户端的DHCP流量。其次，可以将DHCP服务器配置为不响应来自未知子网（即服务器未配置为服务的那些子网）的流量。第三，一些中继提供拒绝不符合预期特征的消息的能力。例如，充当DHCP中继的电缆调制解调器终端系统（CMTS）检测传入DHCP消息中chaddr中指定的媒体访问控制（MAC）地址是否与它来自的电缆调制解调器的MAC地址匹配，并相应地改变其行为。而且
relay agents and servers that are connected to clients directly can reject traffic that looks as if it has passed a relay (this could indicate the client is attempting to spoof a relay, possibly to inject forged relay options).
直接连接到客户端的中继代理和服务器可以拒绝看起来好像已通过中继的流量（这可能表示客户端试图欺骗中继，可能是为了注入伪造的中继选项）。
There are a number of general DHCP recommendations that should be considered in all DHCP deployments. While not strictly related to the mechanisms described in this document, they may be useful in certain deployment scenarios. [RFC7819] and [RFC7824] provide an analysis of privacy problems in DHCPv4 and DHCPv6, respectively. If those are of concern, [RFC7844] offers mitigation steps.
在所有DHCP部署中都应该考虑一些通用的DHCP建议。虽然与本文档中描述的机制没有严格的关系，但它们在某些部署场景中可能很有用。[RFC7819]和[RFC7824]分别分析了DHCPv4和DHCPv6中的隐私问题。如果存在这些问题，[RFC7844]提供了缓解措施。
Current DHCPv4 and DHCPv6 standards lack strong cryptographic protection. There is an ongoing effort in the DHC working group to address this. [SECURE-DHCPv6] attempts to provide a mechanism for strong authentication and encryption between DHCPv6 clients and servers. [SECURITY-MESSAGES] attempts to improve security of exchanges between DHCP relay agents and servers.
当前的DHCPv4和DHCPv6标准缺乏强大的加密保护。DHC工作组正在努力解决这一问题。[SECURE-DHCPv6]尝试为DHCPv6客户端和服务器之间的强身份验证和加密提供一种机制。[SECURITY-MESSAGES]尝试提高DHCP中继代理和服务器之间交换的安全性。
Another possible attack vector is to set up a rogue DHCP server and provide clients with false information, either as a denial of service or to execute a man-in-the-middle type of attack. This can be mitigated by deploying DHCPv6-Shield [RFC7610].
另一种可能的攻击向量是建立一个恶意DHCP服务器，并为客户端提供虚假信息，要么作为拒绝服务，要么在中间攻击类型中执行一个人。这可以通过部署DHCPv6屏蔽[RFC7610]来缓解。
Finally, there is an ongoing effort to update the DHCPv6 specification, which is currently 13 years old. Sections 21 ("Security Considerations") and 22 ("Privacy Considerations") of [DHCPv6bis] contain more recent analysis of the security and privacy considerations.
最后，正在努力更新DHCPv6规范，该规范目前已有13年的历史。[DHCPv6bis]第21节（“安全注意事项”）和第22节（“隐私注意事项”）包含对安全和隐私注意事项的最新分析。
[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>.
[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>.
[DHCPv6bis] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis", Work in Progress, draft-ietf-dhc-rfc3315bis-05, June 2016.
[DHCPv6bis]Mrugalski，T.，Siodelski，M.，Volz，B.，Yourtchenko，A.，Richardson，M.，Jiang，S.，Lemon，T.，和T.Winters，“IPv6（DHCPv6）bis的动态主机配置协议”，正在进行中，草案-ietf-dhc-rfc3315bis-05，2016年6月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", RFC 3011, DOI 10.17487/RFC3011, November 2000, <http://www.rfc-editor.org/info/rfc3011>.
[RFC3011]Waters，G.，“DHCP的IPv4子网选择选项”，RFC 3011，DOI 10.17487/RFC3011，2000年11月<http://www.rfc-editor.org/info/rfc3011>.
[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>.
[RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, DOI 10.17487/RFC3297, July 2002, <http://www.rfc-editor.org/info/rfc3297>.
[RFC3297]Klyne，G.，Iwazaki，R.，和D.Crocker，“基于电子邮件的消息传递服务的内容协商”，RFC 3297，DOI 10.17487/RFC3297，2002年7月<http://www.rfc-editor.org/info/rfc3297>.
[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>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 4193，DOI 10.17487/RFC4193，2005年10月<http://www.rfc-editor.org/info/rfc4193>.
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011, <http://www.rfc-editor.org/info/rfc6221>.
[RFC6221]Miles，D.，Ed.，Ooghe，S.，Dec，W.，Krishnan，S.，和A.Kavanagh，“轻型DHCPv6中继代理”，RFC 6221DOI 10.17487/RFC6221，2011年5月<http://www.rfc-editor.org/info/rfc6221>.
[RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet Selection Options for DHCPv4 and DHCPv6", RFC 6607, DOI 10.17487/RFC6607, April 2012, <http://www.rfc-editor.org/info/rfc6607>.
[RFC6607]Kinnear，K.，Johnson，R.，和M.Stapp，“DHCPv4和DHCPv6的虚拟子网选择选项”，RFC 6607，DOI 10.17487/RFC6607，2012年4月<http://www.rfc-editor.org/info/rfc6607>.
[RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6 Reconfiguration from Relay Agents", RFC 6977, DOI 10.17487/RFC6977, July 2013, <http://www.rfc-editor.org/info/rfc6977>.
[RFC6977]Boucadair，M.和X.Pougnard，“从中继代理触发DHCPv6重新配置”，RFC 6977，DOI 10.17487/RFC6977，2013年7月<http://www.rfc-editor.org/info/rfc6977>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <http://www.rfc-editor.org/info/rfc7227>.
[RFC7227]Hankins，D.，Mrugalski，T.，Siodelski，M.，Jiang，S.，和S.Krishnan，“创建新DHCPv6选项的指南”，BCP 187，RFC 7227，DOI 10.17487/RFC7227，2014年5月<http://www.rfc-editor.org/info/rfc7227>.
[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers", BCP 199, RFC 7610, DOI 10.17487/RFC7610, August 2015, <http://www.rfc-editor.org/info/rfc7610>.
[RFC7610]Gont，F.，Liu，W.，和G.Van de Velde，“DHCPv6防护：防范恶意DHCPv6服务器”，BCP 199，RFC 7610，DOI 10.17487/RFC7610，2015年8月<http://www.rfc-editor.org/info/rfc7610>.
[RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819, April 2016, <http://www.rfc-editor.org/info/rfc7819>.
[RFC7819]Jiang，S.，Krishnan，S.，和T.Mrugalski，“DHCP的隐私考虑”，RFC 7819，DOI 10.17487/RFC78192016年4月<http://www.rfc-editor.org/info/rfc7819>.
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Considerations for DHCPv6", RFC 7824, DOI 10.17487/RFC7824, May 2016, <http://www.rfc-editor.org/info/rfc7824>.
[RFC7824]Krishnan，S.，Mrugalski，T.，和S.Jiang，“DHCPv6的隐私考虑”，RFC 7824DOI 10.17487/RFC78242016年5月<http://www.rfc-editor.org/info/rfc7824>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles 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>.
[SECURE-DHCPv6] Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D. Zhang, "Secure DHCPv6", Work in Progress, draft-ietf-dhc-sedhcpv6-14, October 2016.
[SECURE-DHCPv6]蒋，S.，李，L.，崔，Y.，金美，T.，Lemon，T.，和D.Zhang，“安全DHCPv6”，正在进行的工作，草案-ietf-dhc-sedhcpv6-142016年10月。
[SECURITY-MESSAGES] Volz, B. and Y. Pal, "Security of Messages Exchanged Between Servers and Relay Agents", Work in Progress, draft-volz-dhc-relay-server-security-02, September 2016.
[SECURITY-MESSAGES]Volz，B.和Y.Pal，“服务器和中继代理之间交换的消息的安全性”，正在进行的工作，草稿-Volz-dhc-Relay-server-SECURITY-022016年9月。
Acknowledgements
致谢
Thanks to Dave Thaler for suggesting that even though "everybody knows" how DHCP servers are deployed in the real world, it might be worthwhile to have an IETF document that explains what everybody knows, because in reality not everybody is an expert in how DHCP servers are administered. Thanks to Andre Kostur, Carsten Strotmann, Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun, Jean-Francois Tremblay, Marcin Siodelski, Bernie Volz, and Yaron Sheffer for their reviews, comments, and feedback.
感谢Dave Thaler的建议，尽管“每个人都知道”DHCP服务器在现实世界中是如何部署的，但有一份IETF文档来解释每个人都知道的内容可能是值得的，因为实际上并非每个人都是DHCP服务器管理方面的专家。感谢Andre Kostur、Carsten Strotmann、Simon Perreault、Jinmei Tatuya、Suresh Krishnan、Qi Sun、Jean-Francois Tremblay、Marcin Siodelski、Bernie Volz和Yaron Sheffer的评论、评论和反馈。
Authors' Addresses
作者地址
Ted Lemon Nominum, Inc. 800 Bridge Parkway, Suite 100 Redwood City, CA 94065 United States of America
Ted Lemon Nominum，Inc.美国加利福尼亚州红木市桥路800号100室，邮编94065
Phone: +1-650-381-6000
Email: Ted.Lemon@nominum.com
Phone: +1-650-381-6000
Email: Ted.Lemon@nominum.com
Tomek Mrugalski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 United States of America
美国加利福尼亚州红木市Charter Street 950号Tomek Mrugalski Internet Systems Consortium，Inc.94063
Phone: +1-650-423-1345
Email: tomasz.mrugalski@gmail.com
Phone: +1-650-423-1345
Email: tomasz.mrugalski@gmail.com