Network Working Group R. Woundy
Request for Comments: 4388 Comcast Cable
Category: Standards Track K. Kinnear
Cisco Systems
February 2006
Network Working Group R. Woundy
Request for Comments: 4388 Comcast Cable
Category: Standards Track K. Kinnear
Cisco Systems
February 2006
Dynamic Host Configuration Protocol (DHCP) Leasequery
动态主机配置协议（DHCP）租赁
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided to DHCPv4 clients. Other processes and devices that already make use of DHCPv4 may need to access this information. The leasequery protocol provides these processes and devices a lightweight way to access IP address information.
动态主机配置协议版本4（DHCPv4）服务器是它提供给DHCPv4客户端的IP地址的权威来源。已经使用DHCPv4的其他进程和设备可能需要访问此信息。leasequery协议为这些进程和设备提供了访问IP地址信息的轻量级方式。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................5
3. Background ......................................................7
4. Design Goals ....................................................7
4.1. Broadcast ARP Is Undesirable ...............................7
4.2. SNMP and LDAP Are Not Appropriate ..........................8
4.3. DHCP Relay Agent Functionality Is Common ...................8
4.4. DHCP Servers Are a Reliable Source of Location
Information ................................................9
4.5. Minimal Additional Configuration Is Required ...............9
5. Protocol Overview ...............................................9
6. Protocol Details ...............................................12
6.1. Definitions Required for DHCPLEASEQUERY Processing ........12
6.2. Sending the DHCPLEASEQUERY Message ........................14
6.3. Receiving the DHCPLEASEQUERY Message ......................15
6.4. Responding to the DHCPLEASEQUERY Message ..................16
6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN Message ..................................20
6.6. Receiving No Response to the DHCPLEASEQUERY Message .......21
6.7. Lease Binding Data Storage Requirements ...................22
6.8. Using the DHCPLEASEQUERY Message with Multiple
DHCP Servers ..............................................23
7. Security Considerations ........................................23
8. IANA Considerations ............................................24
9. Acknowledgements ...............................................24
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................25
1. Introduction ....................................................2
2. Terminology .....................................................5
3. Background ......................................................7
4. Design Goals ....................................................7
4.1. Broadcast ARP Is Undesirable ...............................7
4.2. SNMP and LDAP Are Not Appropriate ..........................8
4.3. DHCP Relay Agent Functionality Is Common ...................8
4.4. DHCP Servers Are a Reliable Source of Location
Information ................................................9
4.5. Minimal Additional Configuration Is Required ...............9
5. Protocol Overview ...............................................9
6. Protocol Details ...............................................12
6.1. Definitions Required for DHCPLEASEQUERY Processing ........12
6.2. Sending the DHCPLEASEQUERY Message ........................14
6.3. Receiving the DHCPLEASEQUERY Message ......................15
6.4. Responding to the DHCPLEASEQUERY Message ..................16
6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN Message ..................................20
6.6. Receiving No Response to the DHCPLEASEQUERY Message .......21
6.7. Lease Binding Data Storage Requirements ...................22
6.8. Using the DHCPLEASEQUERY Message with Multiple
DHCP Servers ..............................................23
7. Security Considerations ........................................23
8. IANA Considerations ............................................24
9. Acknowledgements ...............................................24
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................25
A DHCPv4 server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Sometimes devices or other processes may need access to this information. In some cases, these devices or processes already have the capability to send and receive DHCP packets, and so the leasequery protocol is designed to give these processes and devices a low-overhead way to access such information.
DHCPv4服务器包含关于其租用给DHCP客户端的IP地址的大量权威信息。有时，设备或其他进程可能需要访问此信息。在某些情况下，这些设备或进程已经具有发送和接收DHCP数据包的能力，因此leasequery协议旨在为这些进程和设备提供访问此类信息的低开销方式。
For example, access concentrators that act as DHCP relay agents sometimes derive information important to their operation by extracting data out of the DHCP packets they forward, a process known as "gleaning". Unfortunately, the typical access concentrator loses its gleaned information when the access concentrator is rebooted or is replaced. This memo proposes that when gleaned DHCP information is not available, the access concentrator/relay agent can obtain the
例如，充当DHCP中继代理的访问集中器有时通过从它们转发的DHCP数据包中提取数据来获取对其操作重要的信息，这一过程称为“收集”。不幸的是，当重新启动或更换访问集中器时，典型的访问集中器会丢失其收集的信息。此备忘录建议，当收集的DHCP信息不可用时，访问集中器/中继代理可以获得
location information directly from the DHCP server(s) using the DHCPLEASEQUERY message.
使用DHCPLEASEQUERY消息直接从DHCP服务器获取位置信息。
To continue this example in more depth, in many broadband access networks, the access concentrator needs to associate an IP address lease to the correct endpoint location, which 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. This is particularly important when one or more IP subnets are shared among many ports, circuits, and modems. Representative cable and DSL environments are depicted in Figures 1 and 2 below.
为了更深入地继续该示例，在许多宽带接入网络中，接入集中器需要将IP地址租约与正确的端点位置相关联，该端点位置包括主机硬件地址、通向主机的端口或虚拟电路和/或介入用户调制解调器的硬件地址的知识。当一个或多个IP子网在多个端口、电路和调制解调器之间共享时，这一点尤为重要。下面的图1和图2描述了典型的电缆和DSL环境。
+--------+ +---------------+
| DHCP | | DOCSIS CMTS |
| Server |-...-| or DVB INA |-------------------
+--------+ | (Relay Agent) | | |
+---------------+ +------+ +------+
|Modem1| |Modem2|
+------+ +------+
| | |
+-----+ +-----+ +-----+
|Host1| |Host2| |Host3|
+-----+ +-----+ +-----+
+--------+ +---------------+
| DHCP | | DOCSIS CMTS |
| Server |-...-| or DVB INA |-------------------
+--------+ | (Relay Agent) | | |
+---------------+ +------+ +------+
|Modem1| |Modem2|
+------+ +------+
| | |
+-----+ +-----+ +-----+
|Host1| |Host2| |Host3|
+-----+ +-----+ +-----+
Figure 1: Cable Environment for DHCPLEASEQUERY
图1:DHCPLEASEQUERY的电缆环境
+--------+ +---------------+
| DHCP | | DSL Access | +-------+
| Server |-...-| Concentrator |-...-| DSLAM |
+--------+ | (Relay Agent) | +-------+
+---------------+ | |
+------+ +------+
|Modem1| |Modem2|
+------+ +------+
| | |
+-----+ +-----+ +-----+
|Host1| |Host2| |Host3|
+-----+ +-----+ +-----+
+--------+ +---------------+
| DHCP | | DSL Access | +-------+
| Server |-...-| Concentrator |-...-| DSLAM |
+--------+ | (Relay Agent) | +-------+
+---------------+ | |
+------+ +------+
|Modem1| |Modem2|
+------+ +------+
| | |
+-----+ +-----+ +-----+
|Host1| |Host2| |Host3|
+-----+ +-----+ +-----+
Figure 2: DSL Environment for DHCPLEASEQUERY
图2:DHCPLEASEQUERY的DSL环境
Knowledge of this location information can benefit the access concentrator in several ways:
了解此位置信息可以从以下几个方面使访问集中器受益：
1. The access concentrator can forward traffic to the access network using the correct access network port, down the correct virtual circuit, through the correct modem, to the correct hardware address.
1. 接入集中器可以使用正确的接入网络端口，通过正确的调制解调器，沿着正确的虚拟电路，将流量转发到接入网络，到达正确的硬件地址。
2. The access concentrator can perform IP source address verification of datagrams received from the access network. The verification may be based on the datagram source hardware address, the incoming access network port, the incoming virtual circuit, and/or the transmitting modem.
2. 接入集中器可以对从接入网络接收的数据报执行IP源地址验证。验证可以基于数据报源硬件地址、输入接入网络端口、输入虚拟电路和/或传输调制解调器。
3. The access concentrator can encrypt datagrams that can only be decrypted by the correct modem, using mechanisms such as [BPI] or [BPI+].
3. 访问集中器可以使用[BPI]或[BPI+]等机制对只能由正确调制解调器解密的数据报进行加密。
The access concentrator in this example obtains the location information primarily from "gleaning" information from DHCP server responses sent through the relay agent. When location information is not available from "gleaning", e.g., because the access concentrator has rebooted, the access concentrator can query the DHCP server(s) for location information using the DHCPLEASEQUERY message defined in this document.
本例中的访问集中器主要从通过中继代理发送的DHCP服务器响应“收集”信息中获取位置信息。当位置信息无法从“收集”中获得时，例如，由于访问集中器已重新启动，访问集中器可以使用本文档中定义的DHCPLEASEQUERY消息查询DHCP服务器的位置信息。
The DHCPLEASEQUERY message is a new DHCP message type transmitted from a DHCP relay agent to a DHCP server. A DHCPLEASEQUERY-aware relay agent sends the DHCPLEASEQUERY message when it needs to know the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server replies with a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message. The DHCPLEASEACTIVE response to a DHCPLEASEQUERY message allows the relay agent to determine the IP endpoint location and the remaining duration of the IP address lease. The DHCPLEASEUNASSIGNED is similar to a DHCPLEASEACTIVE message, but indicates that there is no currently active lease on the resultant IP address but that this DHCP server is authoritative for this IP address. The DHCPLEASEUNKNOWN message indicates that the DHCP server has no knowledge of the information specified in the query (e.g., IP address, MAC address, or Client-identifier option).
DHCPLEASEQUERY消息是从DHCP中继代理传输到DHCP服务器的新DHCP消息类型。当需要知道IP端点的位置时，支持DHCPLEASEQUERY的中继代理发送DHCPLEASEQUERY消息。支持DHCPLEASEQUERY的DHCP服务器使用DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE或DHCPLEASEUNKNOWN消息进行答复。DHCPLEASEQUERY消息的DHCPLEASEACTIVE响应允许中继代理确定IP端点位置和IP地址租用的剩余持续时间。DHCPLEASEUNASSIGNED类似于DHCPLEASEACTIVE消息，但表示结果IP地址上当前没有活动租约，但此DHCP服务器对此IP地址具有权威性。DHCPLEASEUNKNOWN消息表示DHCP服务器不知道查询中指定的信息（例如，IP地址、MAC地址或客户端标识符选项）。
The DHCPLEASEQUERY message does not presuppose a particular use for the information it returns -- it is simply designed to return information for which the DHCP server is an authoritative source to a client that requests that information. It is designed to make it straightforward for processes and devices that already interpret DHCP packets to access information from the DHCP server.
DHCPLEASEQUERY消息并不预先假定它返回的信息的特定用途——它只是设计用于将DHCP服务器作为权威来源的信息返回给请求该信息的客户端。它旨在使已经解释DHCP数据包的进程和设备能够直接从DHCP服务器访问信息。
This document specifies an extension specifically to the DHCPv4 protocol [RFC2131]. Given the nature of the DHCPv6 protocol [RFC3315], there is no effective way to make the DHCPLEASEQUERY message interaction common between DHCPv4 and DHCPv6 even should the desire to do so exist.
本文档指定了DHCPv4协议[RFC2131]的扩展。鉴于DHCPv6协议[RFC3315]的性质，没有有效的方法使DHCPv4和DHCPv6之间的DHCPLEASEQUERY消息交互变得通用，即使存在这样做的愿望。
The DHCPLEASEQUERY message was the result of a set of specific real-world implementation needs that appeared many years after the DHCPv4 protocol was in wide use. Furthermore, at the time of this writing, the DHCPv6 protocol has yet to be widely deployed. The needs of access concentrators in yet to be determined DHCPv6 deployment scenarios are difficult to estimate. If a DHCPLEASEQUERY-like function is necessary in DHCPv6, many of the ideas of this document will probably be applicable, while others may not. We have been cautioned against designing protocol capabilities for which there is only an imagined consumer, and that is all that exists today in the realm of DHCPLEASEQUERY for DHCPv6.
DHCPLEASEQUERY消息是在DHCPv4协议广泛使用多年后出现的一组特定的实际实现需求的结果。此外，在撰写本文时，DHCPv6协议尚未得到广泛部署。在尚未确定的DHCPv6部署场景中，访问集中器的需求很难估计。如果DHCPv6中需要类似DHCPLEASEQUERY的函数，那么本文档中的许多想法可能适用，而其他想法可能不适用。我们已经被警告不要设计只有一个想象中的消费者的协议功能，而这就是目前DHCPLEASEQUERY for DHCPv6领域中存在的所有功能。
Thus, this document applies only to DHCPv4, and for clarity we have not appended DHCPv4 to every appearance of several common terms. In this document, all references to IP addresses should be taken to mean IPv4 addresses, and all references to DHCP servers and DHCP clients should be taken to mean DHCPv4 servers and DHCPv4 clients.
因此，本文档仅适用于DHCPv4，为了清楚起见，我们没有将DHCPv4附加到几个常见术语的每个外观中。在本文档中，对IP地址的所有引用均应被视为IPv4地址，对DHCP服务器和DHCP客户端的所有引用均应被视为DHCPv4服务器和DHCPv4客户端。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document uses the following terms:
本文件使用以下术语：
o "access concentrator"
o “访问集中器”
An access concentrator is a router or switch at the broadband access provider's edge of a public broadband access network. This document assumes that the access concentrator includes the DHCP relay agent functionality.
接入集中器是位于公共宽带接入网络的宽带接入提供商边缘的路由器或交换机。本文档假设访问集中器包含DHCP中继代理功能。
o "DHCP client"
o “DHCP客户端”
A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address.
DHCP客户端是使用DHCP获取配置参数（如网络地址）的Internet主机。
o "DHCP relay agent"
o “DHCP中继代理”
A DHCP relay agent is a third-party agent that transfers Bootstrap Protocol (BOOTP) and DHCP messages between clients and servers residing on different subnets, per [RFC951] and [RFC1542].
DHCP中继代理是第三方代理，根据[RFC951]和[RFC1542]在位于不同子网上的客户端和服务器之间传输引导协议（BOOTP）和DHCP消息。
o "DHCP server"
o “DHCP服务器”
A DHCP server is an Internet host that returns configuration parameters to DHCP clients.
DHCP服务器是向DHCP客户端返回配置参数的Internet主机。
o "downstream"
o “下游”
Downstream is the direction from the access concentrator towards the broadband subscriber.
下游是从接入集中器到宽带用户的方向。
o "gleaning"
o “收集”
Gleaning is the extraction of location information from DHCP messages, as the messages are forwarded by the DHCP relay agent function.
收集是从DHCP消息中提取位置信息，因为消息由DHCP中继代理功能转发。
o "location information"
o “位置信息”
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.
位置信息是接入集中器将流量转发到宽带接入主机所需的信息。此信息包括主机硬件地址、通向主机的端口或虚拟电路和/或介入用户调制解调器的硬件地址。
o "MAC address"
o “MAC地址”
In the context of a DHCP packet, a MAC address consists of the following fields: hardware type "htype", hardware length "hlen", and client hardware address "chaddr".
在DHCP数据包的上下文中，MAC地址由以下字段组成：硬件类型“htype”、硬件长度“hlen”和客户端硬件地址“chaddr”。
o "stable storage"
o “稳定存储”
Every DHCP server is assumed to have some form of what is called "stable storage". Stable storage is used to hold information concerning IP address bindings (among other things) so that this information is not lost in the event of a server failure that requires restart of the server.
假设每个DHCP服务器都有某种形式的所谓“稳定存储”。稳定存储用于保存有关IP地址绑定的信息（除其他外），以便在服务器发生故障时，需要重新启动服务器时不会丢失这些信息。
o "upstream"
o “上游”
Upstream is the direction from the broadband subscriber towards the access concentrator.
上行是从宽带用户到接入集中器的方向。
The focus of this document is to enable processes and devices that wish to access information from the DHCP server in a lightweight and convenient manner. It is especially appropriate for processes and devices that already interpret DHCP packets.
本文档的重点是启用希望以轻量级和方便的方式从DHCP服务器访问信息的进程和设备。它特别适用于已经解释DHCP数据包的进程和设备。
One important motivating example is that the DHCPLEASEQUERY message allows access concentrators to send DHCPLEASEQUERY messages to DHCP servers to obtain location information of broadband access network devices.
一个重要的激励示例是，DHCPLEASEQUERY消息允许接入集中器向DHCP服务器发送DHCPLEASEQUERY消息，以获取宽带接入网络设备的位置信息。
This document assumes that many access concentrators have an embedded DHCP relay agent functionality. Typical access concentrators include DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB Interactive Network Adapters (INAs) [EUROMODEM], and DSL Access Concentrators.
本文档假设许多访问集中器具有嵌入式DHCP中继代理功能。典型的接入集中器包括DOCSIS电缆调制解调器终端系统（CMTSs）[DOCSIS]、DVB交互式网络适配器（INA）[EUROMODEM]和DSL接入集中器。
The DHCPLEASEQUERY message is an extension to the DHCP protocol [RFC2131].
DHCPLEASEQUERY消息是DHCP协议[RFC2131]的扩展。
The DHCPLEASEQUERY message is a query message only and does not affect the state of the IP address or the binding information associated with it.
DHCPLEASEQUERY消息仅为查询消息，不影响IP地址的状态或与其关联的绑定信息。
The goal of this document is to provide a lightweight mechanism for processes or devices to access information contained in the DHCP server. It is designed to allow processes and devices that already process and interpret DHCP messages to access this information in a rapid and lightweight manner.
本文档的目标是为进程或设备提供一种轻量级机制，以访问DHCP服务器中包含的信息。它旨在允许已经处理和解释DHCP消息的进程和设备以快速、轻量级的方式访问此信息。
Some of this information might be acquired in a different way, and the following sections discuss some of these alternative approaches.
其中一些信息可能以不同的方式获取，以下各节将讨论其中一些替代方法。
The access concentrator can transmit a broadcast Address Resolution Protocol (ARP) Request [RFC826], and observe the origin and contents of the ARP Reply, to reconstruct the location information.
接入集中器可以发送广播地址解析协议（ARP）请求[RFC826]，并观察ARP应答的来源和内容，以重构位置信息。
The ARP mechanism is undesirable for three reasons:
ARP机制不受欢迎，原因有三：
1. the burden on the access concentrator to transmit over multiple access ports and virtual circuits (assuming that IP subnets span multiple ports or virtual circuits),
1. 接入集中器在多个接入端口和虚拟电路上传输的负担（假设IP子网跨越多个端口或虚拟电路），
2. the burden on the numerous subscriber hosts to receive and process the broadcast, and
2. 众多用户主机接收和处理广播的负担，以及
3. the ease by which a malicious host can misrepresent itself as the IP endpoint.
3. 恶意主机很容易将自己误报为IP端点。
Access concentrator implementations typically do not have Simple Network Management Protocol (SNMP) management client interfaces nor Lightweight Directory Access Protocol (LDAP) client interfaces (although they typically do include SNMP management agents). This is one reason why this document does not leverage the proposed DHCP Server MIB [DHCPMIB].
访问集中器实现通常没有简单网络管理协议（SNMP）管理客户端接口，也没有轻型目录访问协议（LDAP）客户端接口（尽管它们通常包括SNMP管理代理）。这就是本文档没有利用建议的DHCP服务器MIB[DHCPMIB]的原因之一。
The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering and troubleshooting activities at large DHCP installations, and is primarily intended as a method of gathering performance statistics about servers the load presented to them.
DHCP服务器MIB工作[DHCPMIB]源于大型DHCP安装中的流量工程和故障排除活动，主要用于收集服务器的性能统计数据和负载。
Despite the presence in the proposed DHCPv4 server MIB of objects that report configuration and status information, the MIB is intended to provide more generic, server-wide aggregated or summarized data. DHCPLEASEQUERY is intended to provide detailed, specific information about individual leases at a level that would be difficult or impossible to shoehorn into a MIB.
尽管建议的DHCPv4服务器MIB中存在报告配置和状态信息的对象，但MIB旨在提供更通用、服务器范围的聚合或汇总数据。DHCPLEASEQUERY旨在提供有关个别租赁的详细、具体的信息，这些信息在某种程度上很难或不可能塞进MIB。
From an implementation standpoint, the DHCPLEASEQUERY message is not required to be supported by all DHCPv4 servers. Since it appears that defining optional MIB objects and objects for optional features in a MIB is discouraged, trying to support DHCPLEASEQUERY functionality optionally through a MIB would be similarly discouraged from an SNMP MIB standpoint.
从实现的角度来看，并非所有DHCPv4服务器都需要支持DHCPLEASEQUERY消息。由于似乎不鼓励在MIB中定义可选MIB对象和可选功能的对象，因此从SNMP MIB的角度来看，尝试通过MIB可选地支持DHCPLEASEQUERY功能也同样不鼓励。
Access concentrators commonly act as DHCP relay agents. Furthermore, many access concentrators already glean location information from DHCP server responses, as part of the relay agent function.
访问集中器通常充当DHCP中继代理。此外，作为中继代理功能的一部分，许多访问集中器已经从DHCP服务器响应中收集位置信息。
The gleaning mechanism as a technique to determine the IP addresses valid for a particular downstream link is preferred over other mechanisms (ARP, SNMP, LDAP) because of the lack of additional network traffic, but sometimes gleaning information can be incomplete. The access concentrator usually cannot glean information from any DHCP unicast (i.e., non-relayed) messages due to performance reasons. Furthermore, the DHCP-gleaned location information often
由于缺少额外的网络通信量，与其他机制（ARP、SNMP、LDAP）相比，作为确定特定下游链路有效IP地址的技术的收集机制更受欢迎，但有时收集信息可能不完整。由于性能原因，访问集中器通常无法从任何DHCP单播（即非中继）消息中收集信息。此外，DHCP经常收集位置信息
does not persist across access concentrator reboots (due to lack of stable storage), and almost never persists across concentrator replacements.
不会在访问集中器重新启动时持续（由于缺少稳定的存储），并且几乎不会在集中器更换时持续。
DHCP servers are the most reliable source of location information for access concentrators, particularly when the location information is dynamic and not reproducible by algorithmic means (e.g., when a single IP subnet extends behind many broadband modems). DHCP servers participate in all IP lease transactions (and therefore in all location information updates) with DHCP clients, whereas access concentrators sometimes miss some important lease transactions.
DHCP服务器是接入集中器位置信息的最可靠来源，特别是当位置信息是动态的且无法通过算法手段再现时（例如，当单个IP子网延伸到多个宽带调制解调器之后）。DHCP服务器与DHCP客户端一起参与所有IP租用事务（因此也参与所有位置信息更新），而访问集中器有时会错过一些重要的租用事务。
An access concentrator can be configured with the IP addresses of multiple different DHCP servers, so that no one DHCP server is a single point of failure.
访问集中器可以配置多个不同DHCP服务器的IP地址，因此没有一个DHCP服务器是单点故障。
Access concentrators can usually query the same set of DHCP servers used for forwarding by the relay agent, thus minimizing configuration requirements.
访问集中器通常可以查询中继代理用于转发的同一组DHCP服务器，从而最小化配置要求。
In the following discussion of the DHCPLEASEQUERY message, the client of the message is assumed to be an access concentrator. Note that access concentrators are not the only allowed (or required) consumers of the information provided by the DHCPLEASEQUERY message, but they do give readers a concrete feel for how the message might be used.
在下面对DHCPLEASEQUERY消息的讨论中，假定消息的客户端是访问集中器。请注意，访问集中器不是DHCPLEASEQUERY消息所提供信息的唯一允许（或必需）使用者，但它们确实让读者具体感受到消息的使用方式。
The access concentrator initiates all DHCPLEASEQUERY message conversations. This document assumes that the access concentrator gleans location information in its DHCP relay agent function. However, the location information is usually unavailable after the reboot or replacement of the access concentrator.
访问集中器启动所有DHCPLEASEQUERY消息对话。本文档假设访问集中器在其DHCP中继代理功能中收集位置信息。但是，在重新启动或更换访问集中器后，位置信息通常不可用。
Suppose the access concentrator is a router, and further suppose that the router receives an IP datagram to forward downstream to the public broadband access network. If the location information for the downstream next hop is missing, the access concentrator sends one or more DHCPLEASEQUERY message(s), each containing the IP address of the downstream next hop in the "ciaddr" field.
假设接入集中器是路由器，并且进一步假设路由器接收IP数据报以向下游转发到公共宽带接入网络。如果下游下一跳的位置信息丢失，则访问集中器发送一个或多个DHCPLEASEQUERY消息，每个消息在“ciaddr”字段中包含下游下一跳的IP地址。
This query will then be answered by returning the information current when this client's lease was last granted or renewed, allowing the access concentrator to forward the IP datagram.
然后，通过返回上次授予或续订此客户端租约时的当前信息来回答此查询，从而允许访问集中器转发IP数据报。
An alternative approach is to send in a DHCPLEASEQUERY message with the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen", and "chaddr" fields) with a valid MAC address or a Client-identifier option (option 61) appearing in the options area. In this case, the DHCP server must return an IP address in the ciaddr if it has any record of the client described by the Client-identifier or MAC address. In the absence of specific configuration information to the contrary (see Section 6.4), it SHOULD be the IP address with the latest client-last-transaction-time associated with the client described by the MAC address or Client-identifier option.
另一种方法是发送DHCPLEASEQUERY消息，其中“ciaddr”字段为空，MAC地址（即“htype”、“hlen”和“chaddr”字段）的有效MAC地址或客户端标识符选项（选项61）出现在选项区域中。在这种情况下，如果DHCP服务器具有由客户端标识符或MAC地址描述的任何客户端记录，则必须在ciaddr中返回IP地址。如果没有相反的特定配置信息（见第6.4节），则应为MAC地址或客户机标识符选项中描述的与客户机关联的最新客户机上次交易时间的IP地址。
The DHCP servers that implement this protocol always send a response to the DHCPLEASEQUERY message: either a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN. The reasons why a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message might be generated are explained in the specific query regimes, below.
实现此协议的DHCP服务器始终发送对DHCPLEASEQUERY消息的响应：DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE或DHCPLEASEUNKNOWN。在下面的特定查询机制中解释了生成DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE或DHCPLEASEUNKNOWN消息的原因。
Servers that do not implement the DHCPLEASEQUERY message SHOULD simply not respond.
不实现DHCPLEASEQUERY消息的服务器不应该响应。
The DHCPLEASEQUERY message can support three query regimes: A server that implements the DHCPLEASEQUERY message must implement all three query regimes.
DHCPLEASEQUERY消息可以支持三种查询机制：实现DHCPLEASEQUERY消息的服务器必须实现所有三种查询机制。
o Query by IP address:
o 按IP地址查询：
For this query, the requester supplies only an IP address in the DHCPLEASEQUERY message. The DHCP server will return any information that it has on the most recent client to have been assigned that IP address.
对于此查询，请求者仅在DHCPLEASEQUERY消息中提供一个IP地址。DHCP服务器将返回它在最近的客户端上拥有的任何信息，这些信息被分配给该IP地址。
The DHCP server replies with a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message if the IP address in the DHCPLEASEQUERY message corresponds to an IP address about which the server has definitive information (i.e., it is authorized to lease this IP address). The server replies with a DHCPLEASEUNKNOWN message if the server does not have definitive information concerning the address in the DHCPLEASEQUERY message.
如果DHCPLEASEQUERY消息中的IP地址对应于服务器具有确定信息的IP地址，则DHCP服务器将使用DHCPLEASEUNASSIGNED或DHCPLEASEACTIVE消息进行回复（即，它被授权租用此IP地址）。如果服务器没有关于DHCPLEASEQUERY消息中地址的确定信息，则服务器会回复DHCPLEASEUNKNOWN消息。
o Query by MAC address:
o 按MAC地址查询：
For this query, the requester supplies only a MAC address in the DHCPLEASEQUERY message. The DHCP server will return any information that it has on the IP address most recently accessed by a client with that MAC address. In addition, it may supply additional IP addresses that have been associated with that MAC address in different subnets. Information about these bindings
对于此查询，请求者仅在DHCPLEASEQUERY消息中提供MAC地址。DHCP服务器将返回它在具有该MAC地址的客户端最近访问的IP地址上拥有的任何信息。此外，它还可以提供与不同子网中的MAC地址相关联的附加IP地址。有关这些绑定的信息
can then be found using the Query by IP Address, described above.
然后可以使用上面描述的按IP地址查询来找到。
The DHCP server replies with a DHCPLEASEACTIVE message if the MAC address in the DHCPLEASEQUERY message corresponds to a MAC address with an active lease on an IP address in this server. The server replies with a DHCPLEASEUNKNOWN message if the server does not presently have an active lease by a client with this MAC address in this DHCP server.
如果DHCPLEASEQUERY消息中的MAC地址对应于此服务器IP地址上具有活动租约的MAC地址，则DHCP服务器将使用DHCPLEASEACTIVE消息进行回复。如果服务器当前没有此DHCP服务器中具有此MAC地址的客户端的活动租约，则服务器将使用DHCPLEASEUNKNOWN消息进行答复。
o Query by Client-identifier option:
o 按客户端标识符查询选项：
For this query, the requester supplies only a Client-identifier option in the DHCPLEASEQUERY message. The DHCP server will return any information that it has on the IP address most recently accessed by a client with that Client-identifier. In addition, it may supply additional IP addresses that have been associated with Client-identifier in different subnets. Information about these bindings can then be found using the Query by IP Address, described above.
对于此查询，请求者仅在DHCPLEASEQUERY消息中提供一个客户机标识符选项。DHCP服务器将返回它在具有该客户端标识符的客户端最近访问的IP地址上拥有的任何信息。此外，它还可以提供与不同子网中的客户端标识符关联的附加IP地址。然后可以使用上面描述的按IP地址查询来找到有关这些绑定的信息。
The DHCP server replies with a DHCPLEASEACTIVE message if the Client-identifier in the DHCPLEASEQUERY message currently has an active lease on an IP address in this DHCP server. The server replies with a DHCPLEASEUNKNOWN message if the server does not have an active lease by a client with this Client-identifier.
如果DHCPLEASEQUERY消息中的客户端标识符当前在此DHCP服务器中的IP地址上具有活动租约，则DHCP服务器将使用DHCPLEASEACTIVE消息进行答复。如果服务器没有具有此客户端标识符的客户端的活动租约，则服务器将使用DHCPLEASEUNKNOWN消息进行答复。
For many DHCP servers, the query by IP address is likely to be the most efficient form of leasequery. This is the form of DHCPLEASEQUERY that SHOULD be used if possible.
对于许多DHCP服务器，按IP地址查询可能是最有效的查询形式。这是DHCPLEASEQUERY的形式，如果可能的话，应该使用它。
The DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message reply must always contain the IP address in the "ciaddr" field. The DHCPLEASEACTIVE message SHOULD contain the physical address of the IP address lease owner in the "htype", "hlen", and "chaddr" fields. The Parameter Request List (option 55) can be used to request specific options to be returned about the IP address in the ciaddr. The reply often contains the time until expiration of the lease, and the original contents of the Relay Agent Information option [RFC3046]. The access concentrator uses the "chaddr" field and Relay Agent Information option to construct location information, which can be cached on the access concentrator until lease expiration.
DHCPLEASEUNASSIGNED或DHCPLEASEACTIVE邮件回复必须始终在“ciaddr”字段中包含IP地址。DHCPLEASEACTIVE消息应在“htype”、“hlen”和“chaddr”字段中包含IP地址租约所有者的物理地址。参数请求列表（选项55）可用于请求返回有关ciaddr中IP地址的特定选项。回复通常包含租约到期前的时间，以及中继代理信息选项[RFC3046]的原始内容。访问集中器使用“chaddr”字段和中继代理信息选项来构造位置信息，这些信息可以缓存在访问集中器上，直到租约到期。
Any DHCP server that supports the DHCPLEASEQUERY message SHOULD save the information from the most recent Relay Agent Information option (option 82) [RFC3046] associated with every IP address that it serves. It is assumed that most clients that generate the DHCPLEASEQUERY message will ask for the Relay Agent Information
任何支持DHCPLEASEQUERY消息的DHCP服务器都应保存与其服务的每个IP地址相关联的最新中继代理信息选项（选项82）[RFC3046]中的信息。假设生成DHCPLEASEQUERY消息的大多数客户端都会请求中继代理信息
option (option 82) in the Parameter Request List (option 55), and so supporting the DHCPLEASEQUERY message without having the Relay Agent Information option around to return to the client is likely to be less than helpful.
参数请求列表（选项55）中的选项（选项82），因此在没有中继代理信息选项的情况下支持DHCPLEASEQUERY消息返回到客户端可能没有什么帮助。
A server that implements DHCPLEASEQUERY SHOULD also save the information on the most recent Vendor class identifier, option 60, associated with each IP address, since this option is also likely to be requested by clients sending the DHCPLEASEQUERY message.
实现DHCPLEASEQUERY的服务器还应保存与每个IP地址关联的最新供应商类别标识符选项60的信息，因为发送DHCPLEASEQUERY消息的客户端也可能会请求此选项。
The operation of the DHCPLEASEQUERY message requires the definition of the following new and extended values for the DHCP packet beyond those defined by [RFC2131] and [RFC2132]. See also Section 8, IANA Considerations.
DHCPLEASEQUERY消息的操作需要为DHCP数据包定义以下新值和扩展值，超出[RFC2131]和[RFC2132]定义的值。另见第8节IANA注意事项。
1. The message type option (option 53) from [RFC2132] requires four new values: one for the DHCPLEASEQUERY message itself and one for each of its three possible responses DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, DHCPLEASEUNKNOWN. The values of these message types are shown below in an extension of the table from section 9.6 of [RFC2132]:
1. [RFC2132]中的消息类型选项（选项53）需要四个新值：一个用于DHCPLEASEQUERY消息本身，另一个用于其三个可能响应DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE和DHCPLEASEUNKNOWN。这些消息类型的值在[RFC2132]第9.6节表格的扩展部分中显示如下：
Value Message Type
----- ------------
10 DHCPLEASEQUERY
11 DHCPLEASEUNASSIGNED
12 DHCPLEASEUNKNOWN
13 DHCPLEASEACTIVE
Value Message Type
----- ------------
10 DHCPLEASEQUERY
11 DHCPLEASEUNASSIGNED
12 DHCPLEASEUNKNOWN
13 DHCPLEASEACTIVE
2. There is a new option, the client-last-transaction-time:
2. 有一个新选项，即客户端上次交易时间：
client-last-transaction-time
客户上次交易时间
This option allows the receiver to determine the time of the most recent access of the client. It is particularly useful when DHCPLEASEACTIVE messages from two different DHCP servers need to be compared, although it can be useful in other situations. The value is a duration in seconds from the current time into the past when this IP address was most recently the subject of communication between the client and the DHCP server.
此选项允许接收方确定客户端最近一次访问的时间。当需要比较来自两个不同DHCP服务器的DHCPLEASEACTIVE消息时，它特别有用，尽管它在其他情况下也很有用。该值是从当前时间到该IP地址最近成为客户端和DHCP服务器之间通信主题的过去时间的持续时间（秒）。
This MUST NOT be an absolute time. This MUST NOT be an absolute number of seconds since Jan. 1, 1970. Instead, this MUST be an integer number of seconds in the past from the time the DHCPLEASEACTIVE message is sent that the client last dealt with this server about this IP address. In the same way that the IP Address Lease Time option (option 51) encodes a lease time that is a number of seconds into the future from the time the message was sent, this option encodes a value that is a number of seconds into the past from when the message was sent.
这不能是绝对时间。这不能是自1970年1月1日以来的绝对秒数。相反，这必须是从发送DHCPLEASEACTIVE消息到客户机最后一次处理此服务器有关此IP地址的时间的整数秒数。与IP地址租用时间选项（选项51）对租用时间进行编码的方式相同，该租用时间是从消息发送时算起的未来秒数，该选项对从消息发送时算起的过去秒数的值进行编码。
The code for the this option is 91. The length of the this option is 4 octets.
此选项的代码为91。此选项的长度为4个八位字节。
Code Len Seconds in the past
+-----+-----+-----+-----+-----+-----+
| 91 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
Code Len Seconds in the past
+-----+-----+-----+-----+-----+-----+
| 91 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
3. There in a second new option, the associated-ip option:
3. 第二个新选项是关联的ip选项：
associated-ip
关联ip
This option is used to return all of the IP addresses associated with the DHCP client specified in a particular DHCPLEASEQUERY message.
此选项用于返回与特定DHCPLEASEQUERY消息中指定的DHCP客户端关联的所有IP地址。
The code for this option is 92. The minimum length for this option is 4 octets, and the length MUST always be a multiple of 4.
此选项的代码为92。此选项的最小长度为4个八位字节，长度必须始终为4的倍数。
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 92 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 92 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
The DHCPLEASEQUERY message is typically sent by an access concentrator. The DHCPLEASEQUERY message uses the DHCP message format as described in [RFC2131], and uses message number 10 in the DHCP Message Type option (option 53). The DHCPLEASEQUERY message has the following pertinent message contents:
DHCPLEASEQUERY消息通常由访问集中器发送。DHCPLEASEQUERY消息使用[RFC2131]中所述的DHCP消息格式，并使用DHCP消息类型选项（选项53）中的消息编号10。DHCPLEASEQUERY消息具有以下相关消息内容：
o The giaddr MUST be set to the IP address of the requester (i.e., the access concentrator). The giaddr is independent of the "ciaddr" field to be searched -- it is simply the return address of the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message from the DHCP server.
o giaddr必须设置为请求者（即访问集中器）的IP地址。giaddr独立于要搜索的“ciaddr”字段——它只是来自DHCP服务器的DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE或DHCPLEASEUNKNOWN消息的返回地址。
Note that this use of the giaddr is consistent with the definition of giaddr in [RFC2131], where the giaddr is always used as the return address of the DHCP response message. In some (but not all) contexts in RFC 2131, the giaddr is used as the "key" to access the appropriate address pool. The DHCPLEASEQUERY message is one of those cases where the giaddr MUST NOT be used as such a "key".
请注意，giaddr的使用与[RFC2131]中giaddr的定义一致，其中giaddr始终用作DHCP响应消息的返回地址。在RFC 2131中的某些（但不是全部）上下文中，giaddr用作访问适当地址池的“密钥”。DHCPLEASEQUERY消息是giaddr不能用作此类“密钥”的情况之一。
o The Parameter Request List option (option 55) SHOULD be set to the options of interest to the requester. The interesting options are likely to include the IP Address Lease Time option (option 51), the Relay Agent Information option (option 82), and possibly the Vendor class identifier option (option 60). In the absence of a Parameter Request List option, the server SHOULD return the same options it would return for a DHCPREQUEST message that didn't contain a DHCPLEASEQUERY message, which includes those mandated by Section 4.3.1 of [RFC2131] as well as any options that the server was configured to always return to a client.
o 参数请求列表选项（选项55）应设置为请求者感兴趣的选项。有趣的选项可能包括IP地址租赁时间选项（选项51）、中继代理信息选项（选项82）以及供应商类别标识符选项（选项60）。在没有参数请求列表选项的情况下，服务器应返回与不包含DHCPLEASEQUERY消息的DHCPREQUEST消息相同的选项，其中包括[RFC2131]第4.3.1节规定的选项以及服务器配置为始终返回到客户端的任何选项。
Additional details concerning different query types are:
有关不同查询类型的其他详细信息如下：
o Query by IP address:
o 按IP地址查询：
The values of htype, hlen, and chaddr MUST be set to zero.
htype、hlen和chaddr的值必须设置为零。
The "ciaddr" field MUST be set to the IP address of the lease to be queried.
“ciaddr”字段必须设置为要查询的租约的IP地址。
The Client-identifier option (option 61) MUST NOT appear in the packet.
客户端标识符选项（选项61）不得出现在数据包中。
o Query by MAC address:
o 按MAC地址查询：
The values of htype, hlen, and chaddr MUST be set to the value of the MAC address to search for.
htype、hlen和chaddr的值必须设置为要搜索的MAC地址的值。
The "ciaddr" field MUST be set to zero.
“ciaddr”字段必须设置为零。
The Client-identifier option (option 61) MUST NOT appear in the packet.
客户端标识符选项（选项61）不得出现在数据包中。
o Query by Client-identifier option:
o 按客户端标识符查询选项：
There MUST be a Client-identifier option (option 61) in the DHCPLEASEQUERY message.
DHCPLEASEQUERY消息中必须有一个客户端标识符选项（选项61）。
The "ciaddr" field MUST be set to zero.
“ciaddr”字段必须设置为零。
The values of htype, hlen, and chaddr MUST be set to zero.
htype、hlen和chaddr的值必须设置为零。
The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is known to possess authoritative information concerning the IP address. The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, and in the absence of information concerning which DHCP server might possess authoritative information concerning the IP address, it SHOULD be sent to all DHCP servers configured for the associated relay agent (if any are known).
DHCPLEASEQUERY消息应发送到已知拥有有关IP地址的权威信息的DHCP服务器。DHCPLEASEQUERY消息可以发送到多个DHCP服务器，如果没有关于哪个DHCP服务器可能拥有关于IP地址的权威信息的信息，则应将其发送到为相关中继代理配置的所有DHCP服务器（如果已知）。
Any device expecting to use a DHCPLEASEQUERY message SHOULD ensure that the Relay Agent Info option that it uses contains information that unambiguously identifies the device.
任何希望使用DHCPLEASEQUERY消息的设备都应确保其使用的中继代理信息选项包含明确标识设备的信息。
A server that implements the DHCPLEASEQUERY message MUST implement all three query regimes: query by IP address, query by MAC address, and query by Client-identifier.
实现DHCPLEASEQUERY消息的服务器必须实现所有三种查询机制：按IP地址查询、按MAC地址查询和按客户端标识符查询。
A DHCPLEASEQUERY message MUST have a non-zero giaddr. The DHCPLEASEQUERY message MUST have exactly one of the following: a non-zero ciaddr, a non-zero htype/hlen/chaddr, or a Client-identifier option.
DHCPLEASEQUERY消息必须具有非零giaddr。DHCPLEASEQUERY消息必须正好包含以下内容之一：非零ciaddr、非零htype/hlen/chaddr或客户端标识符选项。
The DHCP server that receives a DHCPLEASEQUERY message MUST base its response on the particular data item used in the query.
接收DHCPLEASEQUERY消息的DHCP服务器必须根据查询中使用的特定数据项进行响应。
The giaddr is used only for the destination address of any generated response and, while required, is not otherwise used in generating the response to the DHCPLEASEQUERY message. It MUST NOT be used to restrict the processing of the query in any way, and MUST NOT be used locate a subnet to which the ciaddr (if any) must belong.
giaddr仅用于任何生成的响应的目标地址，虽然需要，但在生成对DHCPLEASEQUERY消息的响应时不使用。它不得用于以任何方式限制查询的处理，也不得用于定位ciaddr（如果有）必须属于的子网。
Note that this use of the giaddr is consistent with the definition of giaddr in [RFC2131], where the giaddr is always used as the return address of the DHCP response message. In some (but not all) contexts in RFC 2131, the giaddr is used as the "key" to access the appropriate address pool. The DHCPLEASEQUERY message is one of those cases where the giaddr MUST NOT be used as such a "key".
请注意，giaddr的使用与[RFC2131]中giaddr的定义一致，其中giaddr始终用作DHCP响应消息的返回地址。在RFC 2131中的某些（但不是全部）上下文中，giaddr用作访问适当地址池的“密钥”。DHCPLEASEQUERY消息是giaddr不能用作此类“密钥”的情况之一。
There are three possible responses to a DHCPLEASEQUERY message:
对DHCPLEASEQUERY消息有三种可能的响应：
o DHCPLEASEUNASSIGNED
o 未分配
The server MUST respond with a DHCPLEASEUNASSIGNED message if this server has information about the IP address, but there is no active lease for the IP address. The DHCPLEASEUNASSIGNED message is only returned for a query by IP address, and indicates that the server manages this IP address, but there is no currently active lease on this IP address.
如果此服务器具有有关IP地址的信息，但没有IP地址的活动租约，则服务器必须使用DHCPLEASEUNASSIGNED消息进行响应。DHCPLEASEUNASSIGNED消息仅针对IP地址查询返回，并指示服务器管理此IP地址，但此IP地址上当前没有活动租约。
o DHCPLEASEUNKNOWN
o DHCPL未知
The DHCPLEASEUNKNOWN message indicates that the server does not manage the IP address or the client specified in the DHCPLEASEQUERY message does not currently have a lease on an IP address.
DHCPLEASEUNKNOWN消息表示服务器没有管理IP地址，或者DHCPLEASEQUERY消息中指定的客户端当前没有IP地址租约。
When responding with a DHCPLEASEUNKNOWN, the DHCP server MUST NOT include other DHCP options in the response.
当使用DHCPLEASEUNKNOWN进行响应时，DHCP服务器不得在响应中包含其他DHCP选项。
o DHCPLEASEACTIVE
o DHCPlaseActive
The DHCPLEASEACTIVE message indicates that the server not only knows about the IP address and client specified in the DHCPLEASEACTIVE message, but also knows that there is an active lease by that client for that IP address.
DHCPLEASEACTIVE消息表示服务器不仅知道DHCPLEASEACTIVE消息中指定的IP地址和客户端，还知道该客户端对该IP地址有活动租约。
The server MUST respond with a DHCPLEASEACTIVE message when the IP address returned in the "ciaddr" field is currently leased.
当“ciaddr”字段中返回的IP地址当前已租用时，服务器必须使用DHCPLEASEACTIVE消息进行响应。
Since the response to a DHCPLEASEQUERY request can only contain full information about one IP address -- the one that appears in the "ciaddr" field -- determination of which IP address about which to respond is a key issue. Of course, the values of additional IP addresses for which a client has a lease must also be returned in the associated-ip option (Section 6.1, #3). This is the only information returned not directly associated with the IP address in the "ciaddr" field.
由于对DHCPLEASEQUERY请求的响应只能包含关于一个IP地址的完整信息——“ciaddr”字段中显示的IP地址，因此确定要响应的IP地址是一个关键问题。当然，客户拥有租约的其他IP地址的值也必须在关联的IP选项中返回（第6.1节，第3节）。这是返回的唯一与“ciaddr”字段中的IP地址没有直接关联的信息。
In the event that an IP address appears in the "ciaddr" field of a DHCPLEASEQUERY message, if that IP address is one managed by the DHCP server, then that IP address MUST be set in the "ciaddr" field of a DHCPLEASEUNASSIGNED message.
如果一个IP地址出现在DHCPLEASEQUERY消息的“ciaddr”字段中，如果该IP地址是由DHCP服务器管理的，则必须在DHCPLEASEUNASSIGNED消息的“ciaddr”字段中设置该IP地址。
If the IP address is not managed by the DHCP server, then a DHCPLEASEUNKNOWN message must be returned.
如果IP地址不是由DHCP服务器管理的，则必须返回DHCPLEASEUNKNOWN消息。
If the "ciaddr" field of the DHCPLEASEQUERY is zero, then the DHCPLEASEQUERY message is a query by Client-identifier or MAC address. In this case, the client's identity is any client that has proffered an identical Client-identifier option (if the Client-identifier option appears in the DHCPLEASEQUERY message), or an identical MAC address (if the MAC address fields in the DHCPLEASEQUERY message are non-zero). This client matching approach will, for the purposes of this section, be described as "Client-identifier or MAC address".
如果DHCPLEASEQUERY的“ciaddr”字段为零，则DHCPLEASEQUERY消息是按客户端标识符或MAC地址进行的查询。在这种情况下，客户机标识是提供相同客户机标识符选项（如果客户机标识符选项出现在DHCPLEASEQUERY消息中）或相同MAC地址（如果DHCPLEASEQUERY消息中的MAC地址字段非零）的任何客户机。在本节中，这种客户机匹配方法将被描述为“客户机标识符或MAC地址”。
If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE message MUST be that of an IP address for which the client that most recently used the IP address matches the Client-identifier or MAC address specified in the DHCPLEASEQUERY message.
如果DHCPLEASEQUERY消息中的“ciaddr”字段为零，则DHCPLEASEACTIVE消息的“ciaddr”字段中的IP地址必须是最近使用IP地址的客户端与DHCPLEASEQUERY消息中指定的客户端标识符或MAC地址相匹配的IP地址。
If there is only a single IP address that fulfills this criteria, then it MUST be placed in the "ciaddr" field of the DHCPLEASEACTIVE message.
如果只有一个IP地址满足此标准，则必须将其置于DHCPLEASEACTIVE消息的“ciaddr”字段中。
In the case where more than one IP address has been accessed by the client specified by the MAC address or Client-identifier option, then the DHCP server MUST return the IP address returned to the client in the most recent transaction with the client unless the DHCP server has been configured by the server administrator to use some other preference mechanism.
如果MAC地址或客户端标识符选项指定的客户端访问了多个IP地址，然后，DHCP服务器必须返回在最近与客户端的事务中返回给客户端的IP地址，除非服务器管理员已将DHCP服务器配置为使用某些其他首选项机制。
If, after all of the above processing, no value is set in the "ciaddr" field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message, then a DHCPLEASEUNKNOWN message MUST be returned instead.
如果在所有上述处理之后，DHCPLEASEUNASSIGNED或DHCPLEASEACTIVE消息的“ciaddr”字段中未设置任何值，则必须返回DHCPLEASEUNKNOWN消息。
6.4.2. Building a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE Message Once the "ciaddr" Field Is Set
6.4.2. 设置“ciaddr”字段后生成DHCPLEASEUNASSIGNED或DHCPLEASEACTIVE消息
Once the "ciaddr" field of the DHCPLEASEUNASSIGNED is set, the processing for a DHCPLEASEUNASSIGNED message is complete. No other options are returned for the DHCPLEASEUNASSIGNED message.
设置DHCPLEASEUNASSIGNED消息的“ciaddr”字段后，DHCPLEASEUNASSIGNED消息的处理完成。没有为DHCPLEASEUNASSIGNED消息返回其他选项。
For the DHCPLEASEACTIVE message, the rest of the processing largely involves returning information about the IP address specified in the "ciaddr" field.
对于DHCPLEASEACTIVE消息，其余的处理主要涉及返回有关“ciaddr”字段中指定的IP地址的信息。
The IP address in the "ciaddr" field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message MUST be one for which this server is responsible (or a DHCPLEASEUNKNOWN message would be have already been returned early in the processing described in the previous section).
DHCPLEASEUNASSIGNED或DHCPLEASEACTIVE消息的“ciaddr”字段中的IP地址必须是该服务器负责的IP地址（否则，在上一节所述的处理过程中，DHCPLEASEUNKNOWN消息将在早期返回）。
The MAC address of the DHCPLEASEACTIVE message MUST be set to the values that identify the client associated with the IP address in the "ciaddr" field of the DHCPLEASEUNASSIGNED message.
DHCPLEASEACTIVE消息的MAC地址必须设置为在DHCPLEASEUNASSIGNED消息的“ciaddr”字段中标识与IP地址关联的客户端的值。
If the Client-identifier option (option 61) is specified in the Parameter Request List option (option 55), then the Client-identifier (if any) of the client associated with the IP address in the "ciaddr" field SHOULD be returned in the DHCPLEASEACTIVE message.
如果在参数请求列表选项（选项55）中指定了客户端标识符选项（选项61），则应在DHCPLEASEACTIVE消息中返回与“ciaddr”字段中的IP地址相关联的客户端标识符（如果有）。
In the case where more than one IP address has been involved in a DHCP message exchange with the client specified by the MAC address and/or Client-identifier option, then the list of all of the IP addresses MUST be returned in the associated-ip option, whether or not that option was requested as part of the Parameter Request List option.
如果与MAC地址和/或客户端标识符选项指定的客户端进行DHCP消息交换时涉及多个IP地址，则必须在关联的IP选项中返回所有IP地址的列表，无论该选项是否作为参数请求列表选项的一部分被请求。
If the IP Address Lease Time option (option 51) is specified in the Parameter Request List and if there is a currently valid lease for the IP address specified in the ciaddr, then the DHCP server MUST return this option in the DHCPLEASEACTIVE message with its value equal to the time remaining until lease expiration. If there is no valid lease for the IP address, then the server MUST NOT return the IP Address Lease Time option (option 51).
如果在参数请求列表中指定了IP地址租约时间选项（选项51），并且如果ciaddr中指定的IP地址存在当前有效租约，则DHCP服务器必须在DHCPLEASEACTIVE消息中返回此选项，其值等于租约到期前的剩余时间。如果IP地址没有有效的租约，则服务器不得返回IP地址租约时间选项（选项51）。
A request for the Renewal (T1) Time Value option or the Rebinding (T2) Time Value option in the Parameter Request List of the DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time option is handled. If there is a valid lease and these times are not
DHCPLEASEQUERY消息的参数请求列表中的续订（T1）时间值选项或重新绑定（T2）时间值选项的请求必须像处理IP地址租赁时间选项一样进行处理。如果有有效的租约，而这些时间不是
yet in the past, then the DHCP server SHOULD return these options (when requested) with the remaining time until renewal or rebinding, respectively. If these times are already in the past, or if there is not currently a valid lease for this IP address, the DHCP server MUST NOT return these options.
然而，在过去，DHCP服务器应该返回这些选项（在请求时）以及分别在续订或重新绑定之前的剩余时间。如果这些时间已经过去，或者当前没有此IP地址的有效租约，DHCP服务器不得返回这些选项。
If the Relay Agent Information (option 82) is specified in the Parameter Request List, then the information contained in the most recent Relay Agent Information option received from the relay agent associated with this IP address MUST be included in the DHCPLEASEACTIVE message.
如果在参数请求列表中指定了中继代理信息（选项82），则从与此IP地址关联的中继代理接收的最新中继代理信息选项中包含的信息必须包含在DHCPLEASEACTIVE消息中。
The DHCPLEASEACTIVE message SHOULD include the values of all other options not specifically discussed above that were requested in the Parameter Request List of the DHCPLEASEQUERY message and that are acceptable to return based on the list of "non-sensitive options", discussed below.
DHCPLEASEACTIVE消息应包括在DHCPLEASEQUERY消息的参数请求列表中请求的、可根据下文讨论的“非敏感选项”列表返回的所有其他选项的值（上文未具体讨论）。
DHCP servers SHOULD be configurable with a list of "non-sensitive options" that can be returned to the client when specified in the Parameter Request List of the DHCPLEASEQUERY message. Any option not on this list SHOULD NOT be returned to a client, even if requested by that client.
DHCP服务器应配置“非敏感选项”列表，当在DHCPLEASEQUERY消息的参数请求列表中指定时，可以将这些选项返回给客户端。任何不在此列表中的选项都不应返回给客户机，即使该客户机请求。
The DHCP server uses information from its lease binding database to supply the DHCPLEASEACTIVE option values. The values of the options that were returned to the DHCP client would generally be preferred, but in the absence of those, options that were sent in DHCP client requests would be acceptable.
DHCP服务器使用其租约绑定数据库中的信息来提供DHCPLEASEACTIVE选项值。返回到DHCP客户端的选项值通常是首选的，但如果没有这些值，则可以接受在DHCP客户端请求中发送的选项。
In some cases, the Relay Agent Information option in an incoming DHCPREQUEST packet is used to help determine the options returned to the DHCP client that sent the DHCPREQUEST. When responding to a DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay Agent Information option just like it did when responding to the DHCP client in order to determine the values of any options requested by the DHCPLEASEQUERY message. The goal is to return the same option values to the DHCPLEASEQUERY as those that were returned to the DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise specified, above).
在某些情况下，传入DHCPREQUEST数据包中的中继代理信息选项用于帮助确定返回给发送DHCPREQUEST的DHCP客户端的选项。当响应DHCPLEASEQUERY消息时，DHCP服务器必须像响应DHCP客户端一样使用保存的中继代理信息选项，以确定DHCPLEASEQUERY消息请求的任何选项的值。目标是将与从DHCP客户端返回到DHCPDISCOVER或DHCPREQUEST的选项值相同的选项值返回到DHCPLEASEQUERY（除非上面另有指定）。
In the event that two servers are cooperating to provide a high-availability DHCP server, as supported by [RFC2131], they would have to communicate some information about IP address bindings to each other. In order to properly support the DHCPLEASEQUERY message, these servers MUST ensure that they communicate the Relay Agent Information option information to each other in addition to any other IP address binding information.
如果两台服务器合作提供[RFC2131]支持的高可用性DHCP服务器，则它们必须相互传递一些有关IP地址绑定的信息。为了正确支持DHCPLEASEQUERY消息，这些服务器必须确保除了其他任何IP地址绑定信息之外，它们还相互传递中继代理信息选项信息。
6.4.3. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN Message
6.4.3. 发送DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE或DHCPLEASEUNKNOWN消息
The server expects a giaddr in the DHCPLEASEQUERY message, and unicasts the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message to the giaddr. If the "giaddr" field is zero, then the DHCP server MUST NOT reply to the DHCPLEASEQUERY message.
服务器希望DHCPLEASEQUERY消息中包含giaddr，并将DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE或DHCPLEASEUNKNOWN消息单播到giaddr。如果“giaddr”字段为零，则DHCP服务器不得回复DHCPLEASEQUERY消息。
6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN Message
6.5. 接收DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE或DHCPLEASEUNKNOWN消息
When a DHCPLEASEACTIVE message is received in response to the DHCPLEASEQUERY message, it means that there is a currently active lease for this IP address in this DHCP server. The access concentrator SHOULD use the information in the "htype", "hlen", and "chaddr" fields of the DHCPLEASEACTIVE as well as any Relay Agent Information option information included in the packet to refresh its location information for this IP address.
当接收到响应DHCPLEASEQUERY消息的DHCPLEASEACTIVE消息时，表示此DHCP服务器中存在此IP地址的当前活动租约。接入集中器应使用DHCPLEASEACTIVE的“htype”、“hlen”和“chaddr”字段中的信息以及数据包中包含的任何中继代理信息选项信息来刷新该IP地址的位置信息。
When a DHCPLEASEUNASSIGNED message is received in response to the DHCPLEASEQUERY message, that means that there is no currently active lease for the IP address present in the DHCP server, but that this server does in fact manage that IP address. In this case, the access concentrator SHOULD cache this information in order to prevent unacceptable loads on the access concentrator and the DHCP server in the face of a malicious or seriously compromised device downstream of the access concentrator. This caching could be as simple as simply setting a bit saying that a response was received from a server that knew about this IP address but that there was no current lease. This would, of course, need to be cleared when the access concentrator next "gleaned" that a lease for this IP address came into existence.
当收到响应DHCPLEASEQUERY消息的DHCPLEASEUNASSIGNED消息时，这意味着DHCP服务器中当前没有IP地址的活动租约，但该服务器实际上管理该IP地址。在这种情况下，访问集中器应缓存该信息，以防止在访问集中器下游的恶意或严重受损设备面前，访问集中器和DHCP服务器上出现不可接受的负载。这种缓存可以非常简单，只需设置一个位，表示从知道此IP地址但没有当前租约的服务器接收到响应。当然，这需要在访问集中器下一次“收集”到该IP地址的租约时清除。
In either case, when a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message is received in response to a DHCPLEASEQUERY message, it means that the DHCP server that responded is a DHCP server that manages the IP address present in the ciaddr, and the Relay Agent SHOULD cache this information for later use.
在任何一种情况下，当接收到响应DHCPLEASEQUERY消息的DHCPLEASEUNASSIGNED或DHCPLEASEACTIVE消息时，这意味着响应的DHCP服务器是管理ciaddr中存在的IP地址的DHCP服务器，中继代理应缓存此信息以备将来使用。
When a DHCPLEASEUNKNOWN message is received by an access concentrator that has sent out a DHCPLEASEQUERY message, it means that the DHCP server contacted supports the DHCPLEASEQUERY message but that the DHCP server does not have definitive information concerning the IP address contained in the "ciaddr" field of the DHCPLEASEQUERY message. If there is no IP address in the "ciaddr" field of the DHCPLEASEQUERY message, then a DHCPLEASEUNKNOWN message means that
当发送DHCPLEASEQUERY消息的访问集中器接收到DHCPLEASEUNKNOWN消息时，这意味着所联系的DHCP服务器支持DHCPLEASEQUERY消息，但DHCP服务器没有关于DHCPLEASEQUERY消息的“ciaddr”字段中包含的IP地址的确定信息。如果DHCPLEASEQUERY消息的“ciaddr”字段中没有IP地址，则DHCPLEASEUNKNOWN消息表示
the DHCP server does not have definitive information concerning the DHCP client specified in the "hlen", "htype", and "chaddr" fields or the Client-identifier option of the DHCPLEASEQUERY message.
DHCP服务器没有在“hlen”、“htype”和“chaddr”字段或DHCPLEASEQUERY消息的“客户端标识符”选项中指定的有关DHCP客户端的确定信息。
The access concentrator SHOULD cache this information, but only for a relatively short lifetime, approximately 5 minutes.
访问集中器应缓存此信息，但仅在相对较短的生命周期内（约5分钟）缓存。
Having cached this information, the access concentrator SHOULD only infrequently direct a DHCPLEASEQUERY message to a DHCP server that responded to a DHCPLEASEQUERY message for a particular "ciaddr" field with a DHCPLEASEUNKNOWN.
缓存了此信息后，访问集中器只应偶尔将DHCPLEASEQUERY消息定向到DHCP服务器，该服务器使用DHCPLEASEUNKNOWN响应特定“ciaddr”字段的DHCPLEASEQUERY消息。
When an access concentrator receives no response to a DHCPLEASEQUERY message, there are several possible reasons:
当访问集中器没有收到对DHCPLEASEQUERY消息的响应时，可能有以下几个原因：
o The DHCPLEASEQUERY or a corresponding DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN was lost during transmission or the DHCPLEASEQUERY arrived at the DHCP server but it was dropped because the server was too busy.
o DHCPLEASEQUERY或相应的DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE或DHCPLEASEUNKNOWN在传输过程中丢失，或者DHCPLEASEQUERY到达DHCP服务器，但由于服务器太忙而被删除。
o The DHCP server doesn't support DHCPLEASEQUERY.
o DHCP服务器不支持DHCPLEASEQUERY。
In the first of the cases above, a retransmission of the DHCPLEASEQUERY would be appropriate, but in the second of the two cases, a retransmission would not be appropriate. There is no way to tell these two cases apart (other than, perhaps, because of a DHCP server's response to other DHCPLEASEQUERY messages indicating that it does or does not support the DHCPLEASEQUERY message).
在上述第一种情况下，DHCPLEASEQUERY的重新传输是合适的，但在第二种情况下，重新传输是不合适的。无法区分这两种情况（可能是因为DHCP服务器对其他DHCPLEASEQUERY消息的响应表明它支持或不支持DHCPLEASEQUERY消息）。
An access concentrator that utilizes the DHCPLEASEQUERY message SHOULD attempt to resend DHCPLEASEQUERY messages to servers that do not respond to them using a backoff algorithm for the retry time that approximates an exponential backoff. The access concentrator SHOULD adjust the backoff approach such that DHCPLEASEQUERY messages do not arrive at a server that is not otherwise known to support the DHCPLEASEQUERY message at a rate of more than approximately one packet every 10 seconds, and yet (if the access concentrator needs to send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per 70 seconds.
使用DHCPLEASEQUERY消息的访问集中器应尝试使用退避算法将DHCPLEASEQUERY消息重新发送到不响应它们的服务器，重试时间近似于指数退避。接入集中器应调整退避方法，以使DHCPLEASEQUERY消息不会以大约每10秒超过一个数据包的速率到达不知道支持DHCPLEASEQUERY消息的服务器，并且（如果接入集中器需要发送DHCPLEASEQUERY消息）每70秒不少于一次DHCPLEASEQUERY。
In practice, this approach would probably best be handled by a per-server timer that is restarted whenever a response to a DHCPLEASEQUERY message is received, and expires after one minute. The per-server timer would start off expired, and in the expired state only one DHCPLEASEQUERY message would be queued for the associated server.
在实践中，这种方法最好由每服务器计时器来处理，该计时器在收到对DHCPLEASEQUERY消息的响应时重新启动，并在一分钟后过期。每服务器计时器将从过期开始，在过期状态下，只有一条DHCPLEASEQUERY消息将排队等待关联的服务器。
All DHCPLEASEQUERY messages SHOULD use the exponential backoff algorithm specified in Section 4.1 of [RFC2131].
所有DHCPLEASEQUERY消息应使用[RFC2131]第4.1节中规定的指数退避算法。
Thus, in the initial state, the per-server timer is expired, and a single DHCPLEASEQUERY message is queued for each server. After the first response to a DHCPLEASEQUERY message, the per-server timer is started. At that time, multiple DHCPLEASEQUERY messages can be sent in parallel to the DHCP server, though the total number SHOULD be limited to 100 or 200, to avoid swamping the DHCP server. Each of these messages uses the [RFC2131] exponential backoff algorithm. Every time a response to any of these messages is received, the per-server timer is reset and starts counting again up to one minute. In the event the per-server timer goes off, then all outstanding messages SHOULD be dropped except for a single DHCPLEASEQUERY message that is used to poll the server at approximately 64-second intervals until such time as another (or the first) response to the DHCPLEASEQUERY is received.
因此，在初始状态下，每服务器计时器过期，并且为每台服务器排队一条DHCPLEASEQUERY消息。在第一次响应DHCPLEASEQUERY消息后，启动每服务器计时器。此时，可以将多个DHCPLEASEQUERY消息并行发送到DHCP服务器，但总数应限制为100或200，以避免淹没DHCP服务器。这些消息中的每一条都使用[RFC2131]指数退避算法。每次收到对这些消息的响应时，每服务器计时器都会重置，并重新开始计数，直到一分钟。如果每服务器计时器关闭，则应删除所有未完成的消息，但用于以大约64秒的间隔轮询服务器的单个DHCPLEASEQUERY消息除外，直到收到对DHCPLEASEQUERY的另一个（或第一个）响应为止。
In the event that there is no DHCPLEASEQUERY traffic for one minute, then the per-server timer will expire. After that time, there will only be one DHCPLEASEQUERY message allowed to be outstanding to that server until a response to that message is received.
如果一分钟内没有DHCPLEASEQUERY流量，则每服务器计时器将过期。在此之后，在收到对该消息的响应之前，只允许有一条DHCPLEASEQUERY消息未送达该服务器。
DHCP server implementations that implement the DHCPLEASEQUERY capability MUST save the most recent Relay Agent Information option from the most recent DHCPREQUEST packet for two reasons. First, it is almost certain to be requested by in the dhcp-parameter-request-list option in any DHCPLEASEQUERY request. Second, the saved Relay Agent Information option may be necessary to determine the value of other options given to the DHCP client, if these are requested by the dhcp-parameter-request list in the DHCPLEASEQUERY request.
实现DHCPLEASEQUERY功能的DHCP服务器实现必须从最新的DHCPREQUEST数据包中保存最新的中继代理信息选项，原因有二。首先，几乎可以肯定，任何DHCPLEASEQUERY请求中的dhcp参数请求列表选项中都会有请求。第二，如果DHCPLEASEQUERY请求中的DHCP参数请求列表请求提供给DHCP客户端的其他选项，则可能需要保存的中继代理信息选项来确定这些选项的值。
This is a list of the information that is required to successfully implement
这是成功实施所需的信息列表
o relay-agent-info option from client packet: MUST store with binding.
o 客户端数据包中的中继代理信息选项：必须与绑定一起存储。
o client-last-transaction-time of last client interaction: MUST store with binding.
o 上次客户端交互的客户端上次事务时间：必须与绑定一起存储。
o vendor-class-id: SHOULD store with binding.
o 供应商类id:应与绑定一起存储。
These data storage requirements are minimally larger than those required for normal operation of the DHCP protocol, as required to properly implement [RFC2131].
这些数据存储要求至少比DHCP协议正常运行所需的数据存储要求大，这是正确实施[RFC2131]所需的。
When using the DHCPLEASEQUERY message in an environment where multiple DHCP servers may contain authoritative information about the same IP address (such as when two DHCP servers are cooperating to provide a high-availability DHCP service), multiple, possibly conflicting, responses might be received.
在多个DHCP服务器可能包含关于同一IP地址的权威信息的环境中使用DHCPLEASEQUERY消息时（例如，当两个DHCP服务器合作提供高可用性DHCP服务时），可能会收到多个可能冲突的响应。
In this case, some information in the response packet SHOULD be used to decide among the various responses. The client-last-transaction-time (if it is available) can be used to decide which server has more recent information concerning the IP address returned in the "ciaddr" field.
在这种情况下，应该使用响应包中的一些信息来决定各种响应。客户机上一次事务处理时间（如果可用）可用于确定哪个服务器具有与“ciaddr”字段中返回的IP地址有关的最新信息。
Access concentrators that use DHCP gleaning, refreshed with DHCPLEASEQUERY messages, will maintain accurate location information. Location information accuracy ensures that the access concentrator can forward data traffic to the intended location in the broadband access network, can perform IP source address verification of datagrams from the access network, and can encrypt traffic that can only be decrypted by the intended access modem (e.g., [BPI] and [BPI+]). As a result, the access concentrator does not need to depend on ARP broadcasts across the access network, which is susceptible to malicious hosts that masquerade as the intended IP endpoints. Thus, the DHCPLEASEQUERY message allows an access concentrator to provide considerably enhanced security.
使用DHCP收集、使用DHCPLEASEQUERY消息刷新的访问集中器将维护准确的位置信息。位置信息准确性确保接入集中器可以将数据业务转发到宽带接入网络中的预期位置，可以对来自接入网络的数据报执行IP源地址验证，并且可以加密只能由预期接入调制解调器解密的业务（例如，[BPI]和[BPI+]）。因此，接入集中器不需要依赖于接入网络上的ARP广播，这容易受到伪装成预期IP端点的恶意主机的影响。因此，DHCPLEASEQUERY消息允许访问集中器提供显著增强的安全性。
DHCP servers SHOULD prevent exposure of location information (particularly the mapping of hardware address to IP address lease, which can be an invasion of broadband subscriber privacy) by employing the techniques detailed in [RFC3118], "Authentication for DHCP Messages".
DHCP服务器应通过采用[RFC3118]“DHCP消息的身份验证”中详述的技术，防止位置信息泄露（特别是硬件地址到IP地址租赁的映射，这可能会侵犯宽带用户隐私）。
This RFC describes how a DHCP client interacts with a DHCP server. Access concentrators that send the DHCPLEASEQUERY message are essentially DHCP clients for the purposes of the DHCPLEASEQUERY message, even though they perform the functions of a DHCP relay agent as well. Thus, [RFC3118] is an appropriate mechanism for DHCPLEASEQUERY messages.
此RFC描述DHCP客户端如何与DHCP服务器交互。发送DHCPLEASEQUERY消息的访问集中器本质上是用于DHCPLEASEQUERY消息的DHCP客户端，即使它们也执行DHCP中继代理的功能。因此，[RFC3118]是DHCPLEASEQUERY消息的适当机制。
Since [RFC3118] discusses the normal DHCP client interaction, consisting of a DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK, it is necessary to transpose the operations described in [RFC3118] to the DHCPLEASEQUERY domain. The operations described in [RFC3118] for
由于[RFC3118]讨论了正常的DHCP客户端交互，包括DHCPDISCOVER、DHCPOFFER、DHCPREQUEST和DHCPACK，因此有必要将[RFC3118]中描述的操作转移到DHCPLEASEQUERY域。[RFC3118]中描述的操作
DHCPDISCOVER are performed for DHCPLEASEQUERY, and the operations described for DHCPOFFER are performed for DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN messages.
DHCPDISCOVER针对DHCPLEASEQUERY执行，DHCPlover描述的操作针对DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE和DHCPLEASEUNKNOWN消息执行。
Access concentrators SHOULD minimize potential denial of service attacks on the DHCP servers by minimizing the generation of DHCPLEASEQUERY messages. In particular, the access concentrator SHOULD employ negative caching (i.e., cache DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY messages) and ciaddr restriction (i.e., don't send a DHCPLEASEQUERY message with a ciaddr outside of the range of the attached broadband access networks). Together, these mechanisms limit the access concentrator to transmitting one DHCPLEASEQUERY message (excluding message retries) per legitimate broadband access network IP address after a reboot event.
访问集中器应通过最小化DHCPLEASEQUERY消息的生成来最小化对DHCP服务器的潜在拒绝服务攻击。特别是，接入集中器应采用负缓存（即，缓存DHCPLEASEUNASSIGNED、DHCPleAsActive和DHCPLEASEUNKNOWN对DHCPLEASEQUERY消息的响应）和ciaddr限制（即，不发送ciaddr在连接的宽带接入网络范围之外的DHCPLEASEQUERY消息）。总之，这些机制将访问集中器限制为在重新启动事件后，每个合法宽带访问网络IP地址发送一条DHCPLEASEQUERY消息（不包括消息重试）。
DHCP servers supporting the DHCPLEASEQUERY message SHOULD ensure that they cannot be successfully attacked by being flooded with large quantities of DHCPLEASEQUERY messages in a short time.
支持DHCPLEASEQUERY消息的DHCP服务器应确保它们不会在短时间内被大量DHCPLEASEQUERY消息淹没而被成功攻击。
In some environments, it may be appropriate to configure a DHCP server with the IP addresses of the relay agents for which it may respond to DHCPLEASEQUERY messages, thereby allowing it to respond only to requests from only a handful of relay agents. This does not provide any true security, but may be useful to thwart unsophisticated attacks of various sorts.
在某些环境中，可能适合使用中继代理的IP地址配置DHCP服务器，以便它可以响应DHCPLEASEQUERY消息，从而允许它仅响应来自少数中继代理的请求。这不会提供任何真正的安全性，但可能有助于阻止各种简单的攻击。
IANA has assigned six values for this document. See Section 6.1 for details. There are four new messages types, which are the value of the message type option (option 53) from [RFC2132]. The value for DHCPLEASEQUERY is 10, the value for DHCPLEASEUNASSIGNED is 11, the value for DHCPLEASEUNKNOWN is 12, and the value for DHCPLEASEACTIVE is 13. Finally, there are two new DHCP option defined; the client-last-transaction-time option -- option code 91, and the associated-ip option -- option code 92.
IANA为此文档分配了六个值。详见第6.1节。有四种新的消息类型，它们是[RFC2132]中消息类型选项（选项53）的值。DHCPLEASEQUERY的值为10，DHCPLEASEUNASSIGNED的值为11，DHCPLEASEUNKNOWN的值为12，DHCPLEASEACTIVE的值为13。最后，定义了两个新的DHCP选项；客户端上一个事务时间选项（选项代码91）和关联的ip选项（选项代码92）。
Jim Forster, Joe Ng, Guenter Roeck, and Mark Stapp contributed greatly to the initial creation of the DHCPLEASEQUERY message.
Jim Forster、Joe Ng、Guenter Roeck和Mark Stapp对DHCPLEASEQUERY消息的初始创建做出了巨大贡献。
Patrick Guelat suggested several improvements to support static IP addressing. Thomas Narten made many suggestions for improvements. Russ Housley pressed effectively for increased security capabilities, and Ted Hardie suggested ways to minimize undesired information leakage. Bert Wijnen suggested we clarify our focus to DHCPv4 and
Patrick Guelat提出了一些改进，以支持静态IP寻址。Thomas Narten提出了许多改进建议。Russ Housley有效地要求提高安全能力，Ted Hardie提出了减少不必要的信息泄漏的方法。Bert Wijnen建议我们将重点放在DHCPv4和
distinguish our approach from that of the DHCP MIB. R. Barr Hibbs, one of the authors of the DHCP MIB, supplied information to effectively distinguish that effort from DHCPLEASEQUERY.
将我们的方法与DHCP MIB的方法区分开来。DHCP MIB的作者之一R.Barr Hibbs提供了信息，可以有效地将这种努力与DHCPLEASEQUERY区分开来。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]Patrick，M.，“DHCP中继代理信息选项”，RFC3046，2001年1月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118]Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC951]Croft，W.和J.Gilmore，“引导协议”，RFC9511985年9月。
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993.
[RFC1542]Wimer，W.“引导协议的澄清和扩展”，RFC 1542，1993年10月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[BPI] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface Specification SCTE 22-2 2002", 2002, available at http://www.scte.org/standards/.
[BPI]SCTE数据标准小组委员会，“有线数据服务接口规范：DOCSIS 1.0基线隐私接口规范SCTE 22-2 2002”，2002年，可在http://www.scte.org/standards/.
[BPI+] CableLabs, "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-050812", August 2005, available at http://www.cablemodem.com/.
[BPI+]CableLabs，“有线数据服务接口规范：基线隐私加接口规范CM-SP-BPI+_I12-050812”，2005年8月，可在http://www.cablemodem.com/.
[DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration Protocol (DHCP) Server MIB", Work in Progress, February 2004.
[DHCPMIB]Hibbs，R.，Waters，G.，“动态主机配置协议（DHCP）服务器MIB”，正在进行的工作，2004年2月。
[DOCSIS] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Radio Frequency Interface Specification SCTE 22-1 2002", 2002, available at http://www.scte.org/standards/.
[DOCSIS]SCTE数据标准小组委员会，“电缆数据服务接口规范：DOCSIS 1.0射频接口规范SCTE 22-1 2002”，2002年，可在http://www.scte.org/standards/.
[EUROMODEM] ECCA, "Technical Specification of a European Cable Modem for digital bi-directional communications via cable networks", Version 1.0, May 1999.
[EUROMODEM]ECCA，“通过电缆网络进行数字双向通信的欧洲电缆调制解调器技术规范”，版本1.0，1999年5月。
Authors' Addresses
作者地址
Rich Woundy Comcast Cable 27 Industrial Ave. Chelmsford, MA 01824
马萨诸塞州切姆斯福德工业大道27号Rich Woundy Comcast电缆，邮编01824
Phone: (978) 244-4010 EMail: richard_woundy@cable.comcast.com
电话：（978）244-4010电子邮件：richard_woundy@cable.comcast.com
Kim Kinnear Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719
Kim Kinnear思科系统公司马萨诸塞州伯斯堡大道1414号，马萨诸塞州01719
Phone: (978) 936-0000 EMail: kkinnear@cisco.com
电话：（978）936-0000电子邮件：kkinnear@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。