Internet Engineering Task Force (IETF) K. Kinnear
Request for Comments: 6926 M. Stapp
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 R. Desetti
B. Joshi
Infosys Ltd.
N. Russell
Sea Street Technologies Inc.
P. Kurapati
Juniper Networks
B. Volz
Cisco Systems, Inc.
April 2013
Internet Engineering Task Force (IETF) K. Kinnear
Request for Comments: 6926 M. Stapp
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 R. Desetti
B. Joshi
Infosys Ltd.
N. Russell
Sea Street Technologies Inc.
P. Kurapati
Juniper Networks
B. Volz
Cisco Systems, Inc.
April 2013
DHCPv4 Bulk Leasequery
DHCPv4散装租赁
Abstract
摘要
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP.
IPv4的动态主机配置协议（DHCPv4）Leasequery协议允许请求者请求有关DHCPv4绑定的信息。此协议仅限于查询单个绑定。在某些情况下，单个绑定查询可能没有效率，甚至不可能。本文档扩展了DHCPv4 Leasequery协议，允许通过TCP批量传输DHCPv4地址绑定数据。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6926.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6926.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Design Goals ....................................................8
3.1. Information Acquisition before Data Starts .................8
3.2. Lessen Need for Caching and Negative Caching ...............8
3.3. Antispoofing in 'Fast Path' ................................8
3.4. Minimize Data Transmission .................................9
4. Protocol Overview ...............................................9
5. Interaction between UDP Leasequery and Bulk Leasequery .........11
6. Message and Option Definitions .................................12
6.1. Message Framing for TCP ...................................12
6.2. New or Changed Options ....................................13
6.3. Connection and Transmission Parameters ....................20
7. Requestor Behavior .............................................21
7.1. Connecting and General Processing .........................21
7.2. Forming a Bulk Leasequery .................................21
7.3. Processing Bulk Replies ...................................23
7.4. Processing Time Values in Leasequery Messages .............25
7.5. Querying Multiple Servers .................................26
7.6. Making Sense out of Multiple Responses concerning
a Single IPv4 Address .....................................26
7.7. Multiple Queries to a Single Server over One Connection ...27
7.8. Closing Connections .......................................28
8. Server Behavior ................................................29
8.1. Accepting Connections .....................................29
8.2. Replying to a Bulk Leasequery .............................29
8.3. Building a Single Reply for Bulk Leasequery ...............33
8.4. Multiple or Parallel Queries ..............................34
8.5. Closing Connections .......................................35
9. Security Considerations ........................................35
10. IANA Considerations ...........................................37
11. Acknowledgements ..............................................38
12. References ....................................................38
12.1. Normative References .....................................38
12.2. Informative References ...................................39
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Design Goals ....................................................8
3.1. Information Acquisition before Data Starts .................8
3.2. Lessen Need for Caching and Negative Caching ...............8
3.3. Antispoofing in 'Fast Path' ................................8
3.4. Minimize Data Transmission .................................9
4. Protocol Overview ...............................................9
5. Interaction between UDP Leasequery and Bulk Leasequery .........11
6. Message and Option Definitions .................................12
6.1. Message Framing for TCP ...................................12
6.2. New or Changed Options ....................................13
6.3. Connection and Transmission Parameters ....................20
7. Requestor Behavior .............................................21
7.1. Connecting and General Processing .........................21
7.2. Forming a Bulk Leasequery .................................21
7.3. Processing Bulk Replies ...................................23
7.4. Processing Time Values in Leasequery Messages .............25
7.5. Querying Multiple Servers .................................26
7.6. Making Sense out of Multiple Responses concerning
a Single IPv4 Address .....................................26
7.7. Multiple Queries to a Single Server over One Connection ...27
7.8. Closing Connections .......................................28
8. Server Behavior ................................................29
8.1. Accepting Connections .....................................29
8.2. Replying to a Bulk Leasequery .............................29
8.3. Building a Single Reply for Bulk Leasequery ...............33
8.4. Multiple or Parallel Queries ..............................34
8.5. Closing Connections .......................................35
9. Security Considerations ........................................35
10. IANA Considerations ...........................................37
11. Acknowledgements ..............................................38
12. References ....................................................38
12.1. Normative References .....................................38
12.2. Informative References ...................................39
DHCPv4 [RFC2131] [RFC2132] specifies a protocol for the assignment of IPv4 address and configuration information to IPv4 nodes. DHCPv4 servers maintain authoritative binding information.
DHCPv4[RFC2131][RFC2132]指定一个协议，用于将IPv4地址和配置信息分配给IPv4节点。DHCPv4服务器维护权威绑定信息。
+--------+
| DHCPv4 | +--------------+
| Server |-...-| DHCP |
| | | Relay Agent |
+--------+ +--------------+
| |
+------+ +------+
|Modem1| |Modem2|
+------+ +------+
| | |
+-----+ +-----+ +-----+
|Node1| |Node2| |Node3|
+-----+ +-----+ +-----+
+--------+
| DHCPv4 | +--------------+
| Server |-...-| DHCP |
| | | Relay Agent |
+--------+ +--------------+
| |
+------+ +------+
|Modem1| |Modem2|
+------+ +------+
| | |
+-----+ +-----+ +-----+
|Node1| |Node2| |Node3|
+-----+ +-----+ +-----+
Figure 1: Example DHCPv4 Configuration
图1：DHCPv4配置示例
DHCPv4 relay agents receive DHCPv4 messages and frequently append a Relay Agent Information option [RFC3046] before relaying them to the configured DHCPv4 servers (see Figure 1). In this process, some relay agents also glean lease information sent by the server and cache it locally. This information is used for a variety of purposes. Two examples are prevention of spoofing attempts from the DHCPv4 clients and installation of routes. When a relay agent reboots, this information is frequently lost.
DHCPv4中继代理接收DHCPv4消息，并在将消息中继到已配置的DHCPv4服务器之前经常附加中继代理信息选项[RFC3046]（见图1）。在此过程中，一些中继代理还收集服务器发送的租约信息并在本地缓存。此信息用于多种用途。两个示例是防止来自DHCPv4客户端的欺骗尝试和安装路由。中继代理重新启动时，此信息经常丢失。
The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 capability to allow an external entity, such as a relay agent, to query a DHCPv4 server to rapidly recover lease state information about a particular IP address or client.
DHCPv4租赁能力[RFC4388]扩展了DHCPv4的基本能力，允许外部实体（如中继代理）查询DHCPv4服务器，以快速恢复有关特定IP地址或客户端的租赁状态信息。
The existing query types in Leasequery are typically data driven; the relay agent initiates the Leasequery when it receives data traffic from or to the client. This approach may not scale well when there are thousands of clients connected to the relay agent or when the relay agent has a need to rebuild its internal data store prior to processing traffic in one direction or another.
Leasequery中现有的查询类型通常是数据驱动的；中继代理在从客户端接收数据流量或向客户端接收数据流量时启动租赁请求。当有数千个客户端连接到中继代理时，或者当中继代理在处理一个或另一个方向的流量之前需要重建其内部数据存储时，这种方法可能无法很好地扩展。
Some applications require the ability to query the server without waiting for traffic from or to clients. This query capability, in turn, requires an underlying transport more suitable to the bulk transmission of data.
有些应用程序需要能够查询服务器，而无需等待来自或到客户端的流量。反过来，这种查询功能需要一种更适合大容量数据传输的底层传输。
This document extends the DHCPv4 Leasequery protocol [RFC4388] to add support for queries that address these additional requirements. There may be many thousands of DHCPv4 bindings returned as the result of a single request, so TCP [RFC4614] is specified for efficiency of data transfer. We define several additional query types, each of which can return multiple responses, in order to meet a variety of requirements.
本文档扩展了DHCPv4租赁协议[RFC4388]，以添加对满足这些附加要求的查询的支持。单个请求可能会返回数千个DHCPv4绑定，因此指定TCP[RFC4614]是为了提高数据传输效率。我们定义了几个额外的查询类型，每个查询类型都可以返回多个响应，以满足各种需求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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 "absolute time"
o “绝对时间”
Absolute time is a 32-bit quantity containing the number of seconds since January 1, 1970.
绝对时间是一个32位的量，包含自1970年1月1日以来的秒数。
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 DHCPv4 relay agent functionality, for example, a CMTS (Cable Modem Termination System) in a cable environment or a DSLAM (Digital Subscriber Line Access Multiplexer) in a DSL environment.
接入集中器是位于公共宽带接入网络的宽带接入提供商边缘的路由器或交换机。本文档假设接入集中器包括DHCPv4中继代理功能，例如，电缆环境中的CMTS（电缆调制解调器终端系统）或DSL环境中的DSLAM（数字用户线接入多路复用器）。
o "active binding"
o “活动绑定”
An IP address with an active binding refers to an IP address that is currently associated with a DHCPv4 client where that DHCPv4 client has the right to use the IP address.
具有活动绑定的IP地址是指当前与DHCPv4客户端关联的IP地址，该DHCPv4客户端有权使用该IP地址。
o "Bulk Leasequery"
o “批量租赁”
Bulk Leasequery involves requesting and receiving the existing DHCPv4 address binding information in an efficient manner.
批量租赁涉及以有效的方式请求和接收现有DHCPv4地址绑定信息。
o "clock skew"
o “时钟偏移”
The clock skew for a Bulk Leasequery connection is the difference between the absolute time on a DHCPv4 server and the absolute time on the system where a requestor of a Bulk Leasequery is executing. It is not absolutely constant but is likely to vary only slowly.
批量租赁连接的时钟偏差是DHCPv4服务器上的绝对时间与执行批量租赁请求者的系统上的绝对时间之间的差值。它不是绝对恒定的，但可能只是缓慢地变化。
It is possible that, when both systems run NTP, the clock skew is negligible; this is not only acceptable but desired.
当两个系统都运行NTP时，时钟偏差可以忽略不计；这不仅是可以接受的，而且是需要的。
While it is easy to think that this can be calculated precisely after one message is received by a requestor from a DHCPv4 server, a more accurate value is derived from continuously examining the instantaneous value developed from each message received from a DHCPv4 server and using it to make small adjustments to the existing value held in the requestor.
虽然很容易认为这可以在请求者从DHCPv4服务器接收到一条消息后精确计算，通过不断检查从DHCPv4服务器接收到的每条消息产生的瞬时值，并使用它对请求程序中的现有值进行小的调整，可以得到更准确的值。
o "Default VPN"
o “默认VPN”
A default VPN indicates that the address being described belongs to the set of addresses not part of any VPN (in other words, the normal address space operated on by DHCP). This includes Special Use IPv4 Addresses as defined in [RFC5735].
默认VPN表示所描述的地址属于不属于任何VPN的地址集（换句话说，由DHCP操作的正常地址空间）。这包括[RFC5735]中定义的特殊用途IPv4地址。
o "DHCPv4 client"
o “DHCPv4客户端”
A DHCPv4 client is an Internet node using DHCPv4 to obtain configuration parameters such as a network address.
DHCPv4客户端是使用DHCPv4获取配置参数（如网络地址）的Internet节点。
o "DHCPv4 relay agent"
o “DHCPv4中继代理”
A DHCPv4 relay agent is an agent that is neither a DHCPv4 client nor a DHCP server that transfers BOOTP and DHCPv4 messages between clients and servers residing on different subnets, per [RFC951] and [RFC1542].
DHCPv4中继代理既不是DHCPv4客户端，也不是DHCP服务器，它根据[RFC951]和[RFC1542]在驻留在不同子网上的客户端和服务器之间传输BOOTP和DHCPv4消息。
o "DHCPv4 server"
o “DHCPv4服务器”
A DHCPv4 server is an Internet node that returns configuration parameters to DHCPv4 clients.
DHCPv4服务器是向DHCPv4客户端返回配置参数的Internet节点。
o "DSLAM"
o “DSLAM”
DSLAM stands for Digital Subscriber Line Access Multiplexer.
DSLAM代表数字用户线接入多路复用器。
o "downstream"
o “下游”
Downstream refers to a direction away from the central part of a network and toward the edge. In a DHCPv4 context, this typically refers to a network direction that is away from the DHCPv4 server and toward the DHCPv4 client.
下游是指远离网络中心部分并朝向边缘的方向。在DHCPv4上下文中，这通常是指远离DHCPv4服务器并朝向DHCPv4客户端的网络方向。
o "Global VPN"
o “全球VPN”
Global VPN is another name for the default VPN.
全局VPN是默认VPN的另一个名称。
o "IP address"
o “IP地址”
In this document, the term "IP address" refers to an IPv4 IP address.
在本文档中，术语“IP地址”指IPv4 IP地址。
o "IP address binding"
o “IP地址绑定”
An IP address binding is the information that a DHCPv4 server keeps regarding the relationship between a DHCPv4 client and an IP address. This includes the identity of the DHCPv4 client and the expiration time, if any, of any lease that client has on a particular IP address. In some contexts, this may include information on IP addresses that are currently associated with DHCPv4 clients, and in others, it may also include IP addresses with no current association to a DHCPv4 client.
IP地址绑定是DHCPv4服务器保存的有关DHCPv4客户端和IP地址之间关系的信息。这包括DHCPv4客户端的标识以及该客户端在特定IP地址上的任何租约的到期时间（如果有）。在某些上下文中，这可能包括有关当前与DHCPv4客户端关联的IP地址的信息，在其他上下文中，它还可能包括当前与DHCPv4客户端没有关联的IP地址。
o "MAC address"
o “MAC地址”
In the context of a DHCPv4 message, a Media Access Control (MAC) address consists of the fields: hardware type "htype", hardware length "hlen", and client hardware address "chaddr".
在DHCPv4消息的上下文中，媒体访问控制（MAC）地址由以下字段组成：硬件类型“htype”、硬件长度“hlen”和客户端硬件地址“chaddr”。
o "upstream"
o “上游”
Upstream refers to a direction toward the central part of a network and away from the edge. In a DHCPv4 context, this typically refers to a network direction that is away from the DHCPv4 client and toward the DHCPv4 server.
上游是指朝向网络中心部分且远离边缘的方向。在DHCPv4上下文中，这通常是指远离DHCPv4客户端并朝向DHCPv4服务器的网络方向。
o "stable storage"
o “稳定存储”
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 failure that requires restart of the network element. DHCPv4 servers are typically expected to have high-speed access to stable storage, while relay agents and access concentrators usually do not have access to stable storage, although they may have periodic access to such storage.
稳定存储用于保存有关IP地址绑定的信息（除其他外），以便在发生需要重新启动网元的故障时不会丢失这些信息。通常预期DHCPv4服务器可以高速访问稳定存储，而中继代理和访问集中器通常无法访问稳定存储，尽管它们可以定期访问此类存储。
o "xid"
o “xid”
Transaction-id. The term "xid" refers to the DHCPv4 field containing the transaction-id of the message.
事务id。术语“xid”指包含消息事务id的DHCPv4字段。
The goal of this document is to provide a lightweight protocol for an access concentrator or other network element (such as a DHCP relay agent) to retrieve IP address binding information available in the DHCPv4 server. The protocol should also allow an access concentrator or DHCP relay agent to retrieve consolidated IP address binding information for either the entire access concentrator or a single connection/circuit. Throughout the discussion below, everything that applies to an access concentrator also applies to a DHCP relay agent.
本文档的目标是为访问集中器或其他网络元素（如DHCP中继代理）提供一个轻量级协议，以检索DHCPv4服务器中可用的IP地址绑定信息。该协议还应允许访问集中器或DHCP中继代理检索整个访问集中器或单个连接/电路的统一IP地址绑定信息。在下面的整个讨论中，适用于访问集中器的所有内容也适用于DHCP中继代理。
The existing data-driven approach required by [RFC4388] means that the Leasequeries can only be performed after an access concentrator receives data. To implement antispoofing, the concentrator must drop messages for each client until it gets lease information from the DHCPv4 server for that client. If an access concentrator finishes the Leasequeries before it starts receiving data, then there is no need to drop legitimate messages. In this way, outage time may be reduced.
[RFC4388]所要求的现有数据驱动方法意味着只有在访问集中器接收到数据后才能执行租赁。要实现反屏蔽，集中器必须删除每个客户端的消息，直到它从该客户端的DHCPv4服务器获取租约信息。如果访问集中器在开始接收数据之前完成了Leasequeries，那么就没有必要删除合法消息。这样，停机时间可能会缩短。
The result of a single Leasequery should be cached, whether that results in a positive or negative cache, in order to remember that the Leasequery was performed. This caching is required to limit the traffic imposed upon a DHCPv4 server by Leasequeries for information already received.
应缓存单个Leasequery的结果，无论该结果是正缓存还是负缓存，以便记住执行了Leasequery。对于已接收的信息，需要使用此缓存来限制Leasequeries对DHCPv4服务器施加的流量。
These caches not only consume precious resources, they also need to be managed. Hence, they should be avoided as much as possible. One of the goals of the DHCPv4 Bulk Leasequery is to reduce the need for this sort of caching.
这些缓存不仅消耗宝贵的资源，还需要管理。因此，应尽可能避免这些情况。DHCPv4批量租赁的目标之一是减少对这种缓存的需求。
If antispoofing is not done in the fast path, it will become a bottleneck and may lead to denial of service of the access concentrator. The Leasequeries should make it possible to do antispoofing in the fast path.
如果不在快速路径中执行反屏蔽，它将成为瓶颈，并可能导致访问集中器拒绝服务。Leasequeries应能在快速路径中进行防喷溅。
It may be that a network element is able to periodically save its entire list of assigned IP addresses to some form of stable storage. In this case, it will wish to recover all of the updates to this information without duplicating the information it has recovered from its own stable storage.
可能是网元能够定期将其分配的IP地址的整个列表保存到某种形式的稳定存储器中。在这种情况下，它希望恢复此信息的所有更新，而不复制它从自己的稳定存储中恢复的信息。
Bulk Leasequery allows the specification of a query-start-time as well as a query-end-time. Use of query times allows a network element that periodically commits information to stable storage to recover just what it lost since the last commit.
批量请求允许指定查询开始时间和查询结束时间。查询时间的使用允许网络元素定期将信息提交到稳定的存储器，以恢复自上次提交以来丢失的信息。
The DHCPv4 Bulk Leasequery protocol is modeled on the existing individual DHCPv4 Leasequery protocol in [RFC4388] as well as related work on DHCPv6 Bulk Leasequery [RFC5460]. A Bulk Leasequery requestor opens a TCP connection to a DHCPv4 server using the DHCPv4 port 67. Note that this implies that the Leasequery requestor has server IP address(es) available via configuration or some other means and that it has unicast IP reachability to the DHCPv4 server. No relaying of Bulk Leasequery messages is specified.
DHCPv4批量租赁协议以[RFC4388]中现有的单个DHCPv4租赁协议以及DHCPv6批量租赁[RFC5460]的相关工作为模型。批量租赁请求者使用DHCPv4端口67打开到DHCPv4服务器的TCP连接。请注意，这意味着租赁请求者通过配置或其他方式具有可用的服务器IP地址，并且它具有到DHCPv4服务器的单播IP可达性。未指定批量租赁消息的中继。
After establishing a connection, the requestor sends a DHCPBULKLEASEQUERY message over the connection.
建立连接后，请求者通过连接发送DHCPBULKLEASEQUERY消息。
The server uses the message type and additional data in the DHCPv4 DHCPBULKLEASEQUERY message to identify any relevant bindings.
服务器使用DHCPv4 DHCPBULKLEASEQUERY消息中的消息类型和其他数据来标识任何相关绑定。
In order to support some query types, servers may have to maintain additional data structures or otherwise be able to locate bindings that have been requested by the Leasequery requestor.
为了支持某些查询类型，服务器可能必须维护额外的数据结构，或者能够定位Leasequery请求者请求的绑定。
Relevant bindings are returned in DHCPv4 messages with either the DHCPLEASEACTIVE message type for an IP address with a currently active lease or, in some situations, a DHCPLEASEUNASSIGNED message type for an IP address that is controlled by the DHCPv4 server but is not actively leased by a DHCPv4 client at the present time.
在DHCPv4消息中返回相关绑定，对于具有当前活动租用的IP地址，返回DHCPLEASEACTIVE消息类型；在某些情况下，对于由DHCPv4服务器控制但目前未由DHCPv4客户端活动租用的IP地址，返回DHCPLEASEUNASSIGNED消息类型。
The Bulk Leasequery protocol is designed to provide an external entity with information concerning existing DHCPv4 IPv4 address bindings managed by the DHCPv4 server. When complete, the DHCPv4 server will send a DHCPLEASEQUERYDONE message. If a connection is lost while processing a Bulk Leasequery, the Bulk Leasequery must be retried as there is no provision for determining the extent of data already received by the requestor for a Bulk Leasequery.
批量租赁协议旨在向外部实体提供有关DHCPv4服务器管理的现有DHCPv4 IPv4地址绑定的信息。完成后，DHCPv4服务器将发送DHCPLeaseQueryOne消息。如果在处理批量租赁请求时连接丢失，则必须重试批量租赁请求，因为没有规定确定批量租赁请求的请求者已接收的数据范围。
Bulk Leasequery supports queries by MAC address and by Client Identifier in a way similar to [RFC4388]. The Bulk Leasequery protocol also adds several new queries.
Bulk Leasequery以类似于[RFC4388]的方式支持按MAC地址和客户端标识符进行查询。批量租赁协议还添加了几个新的查询。
o Query by Relay Identifier
o 按中继标识符查询
This query asks a server for the bindings associated with a specific relay agent; the relay agent is identified by a Relay Agent Identifier carried in a Relay-ID sub-option [RFC6925]. Relay agents can include this sub-option while relaying messages to DHCPv4 servers. Servers can retain the Relay-ID and associate it with bindings made on behalf of the relay agent's clients. The bindings returned are only those for DHCPv4 clients with a currently active binding.
此查询向服务器请求与特定中继代理关联的绑定；中继代理由中继ID子选项[RFC6925]中携带的中继代理标识符标识。中继代理在将消息中继到DHCPv4服务器时可以包括此子选项。服务器可以保留中继ID，并将其与代表中继代理的客户端进行的绑定相关联。返回的绑定仅适用于具有当前活动绑定的DHCPv4客户端。
o Query by Remote ID
o 按远程ID查询
This query asks a server for the bindings associated with a relay agent Remote ID sub-option [RFC3046] value. The bindings returned are only those for DHCPv4 clients with a currently active binding.
此查询向服务器询问与中继代理远程ID子选项[RFC3046]值关联的绑定。返回的绑定仅适用于具有当前活动绑定的DHCPv4客户端。
o Query for All Configured IP Addresses
o 查询所有配置的IP地址
This query asks a server for information concerning all IP addresses configured in that DHCPv4 server by specifying no other type of query. In this case, the bindings returned are for all configured IP addresses, whether or not they contain a currently active binding to a DHCPv4 client, since one point of this type of query is to update an existing database with changes after a particular point in time.
此查询通过不指定其他类型的查询，向服务器询问有关该DHCPv4服务器中配置的所有IP地址的信息。在这种情况下，返回的绑定适用于所有配置的IP地址，无论它们是否包含到DHCPv4客户端的当前活动绑定，因为此类查询的一个点是在特定时间点之后使用更改更新现有数据库。
Any of the above queries can be qualified by the specification of a query-start-time or a query-end-time (or both). When these timers are used as qualifiers, they indicate that a binding should be included if it changed on or after the query-start-time and on or before the query-end-time.
上述任何查询都可以通过指定查询开始时间或查询结束时间（或两者）来限定。当这些计时器用作限定符时，它们指示如果绑定在查询开始时间或之后以及查询结束时间或之前发生更改，则应包括该绑定。
In addition, any of the above queries can be qualified by the specification of a VPN-ID option [RFC6607] to select the VPN on which the query should be processed. The VPN-ID option is also extended to allow queries across all available VPNs. In the absence of any VPN-ID option, only the default (global) VPN is used to satisfy the query.
此外，可以通过指定VPN-ID选项[RFC6607]来限定上述任何查询，以选择应在其上处理查询的VPN。VPN-ID选项也被扩展，以允许跨所有可用VPN进行查询。如果没有任何VPN-ID选项，则仅使用默认（全局）VPN来满足查询。
Bulk Leasequery can be seen as an extension of the existing UDP Leasequery protocol [RFC4388]. This section clarifies the relationship between the two protocols.
批量租赁可以看作是现有UDP租赁协议[RFC4388]的扩展。本节阐明了两个协议之间的关系。
The Bulk Leasequery TCP connection is only designed to handle the DHCPBULKLEASEQUERY request. It is not intended as an alternative DHCPv4 communication option for clients seeking other DHCPv4 services. DHCPv4 address allocation could not be performed over a TCP connection in any case, as a TCP connection requires an IP address and no IPv4 address exists prior to a successful DHCPv4 address allocation exchange. In addition, the existing DHCPv4 UDP transmission regime is implemented in untold millions of devices deployed worldwide, and complicating DHCPv4 services with alternative transmission approaches (even if it were possible) would be worse than any perceived benefit to doing so.
Bulk Leasequery TCP连接仅设计用于处理DHCPBULKLEASEQUERY请求。对于寻求其他DHCPv4服务的客户，它不打算作为替代DHCPv4通信选项。在任何情况下都无法通过TCP连接执行DHCPv4地址分配，因为TCP连接需要IP地址，并且在成功进行DHCPv4地址分配交换之前不存在IPv4地址。此外，现有的DHCPv4 UDP传输机制在全球部署的数不清的数百万台设备中实施，使用替代传输方法（即使可能）使DHCPv4服务复杂化将比这样做的任何预期好处都要糟糕。
Two of the query types introduced in the UDP Leasequery protocol can be used in the Bulk Leasequery protocol -- Query by MAC address and Query by Client-identifier.
UDP Leasequery协议中引入的两种查询类型可用于批量Leasequery协议——按MAC地址查询和按客户端标识符查询。
The contents of the reply messages are similar between the existing UDP Leasequery protocol and the Bulk Leasequery protocol, though more information is returned in the Bulk Leasequery messages.
回复消息的内容在现有UDP Leasequery协议和Bulk Leasequery协议之间类似，但Bulk Leasequery消息中会返回更多信息。
One change in behavior for these existing queries is required when Bulk Leasequery is used. Sections 6.1, 6.4.1, and 6.4.2 of [RFC4388] specify the use of an associated-ip option in DHCPLEASEACTIVE messages in cases where multiple bindings were found. When Bulk Leasequery is used, this mechanism is not necessary; a server returning multiple bindings simply does so directly as specified in this document. The associated-ip option MUST NOT appear in Bulk Leasequery replies.
使用Bulk Leasequery时，需要对这些现有查询的行为进行一次更改。[RFC4388]第6.1节、第6.4.1节和第6.4.2节规定了在发现多个绑定的情况下，在DHCPLEASEACTIVE消息中使用关联的ip选项。当使用批量租赁时，不需要此机制；返回多个绑定的服务器只是按照本文档中的指定直接执行。关联的ip选项不得出现在批量租赁回复中。
Implementors should note that the TCP message framing defined in Section 6.1 is not compatible with the UDP message format. If a TCP-framed request is sent as a UDP message, it may not be valid, because protocol fields will be offset by the message-size prefix.
实施者应注意，第6.1节中定义的TCP消息帧与UDP消息格式不兼容。如果TCP帧请求作为UDP消息发送，则可能无效，因为协议字段将被消息大小前缀偏移。
The use of TCP for the Bulk Leasequery protocol permits multiple messages to be sent from one end of the connection to the other without requiring a request/response paradigm as does UDP DHCPv4 [RFC2131]. The receiver needs to be able to determine the size of each message it receives. Two octets containing the message size in network byte order are prepended to each DHCPv4 message sent on a Bulk Leasequery TCP connection. The two message-size octets 'frame' each DHCPv4 message.
批量租赁协议使用TCP允许从连接的一端向另一端发送多条消息，而无需UDP DHCPv4[RFC2131]那样的请求/响应范例。接收者需要能够确定接收到的每条消息的大小。在大容量租赁TCP连接上发送的每条DHCPv4消息前都有两个八位字节，其中包含网络字节顺序的消息大小。两个消息大小的八位字节“帧”每个DHCPv4消息。
The maximum message size is 65535 octets.
最大消息大小为65535个八位字节。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message-size | op (1) | htype (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hlen (1) | hops (1) | .... |
+---------------+---------------+ +
| |
. remainder of DHCPv4 message,
. from Figure 1 of [RFC2131] .
. .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message-size | op (1) | htype (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hlen (1) | hops (1) | .... |
+---------------+---------------+ +
| |
. remainder of DHCPv4 message,
. from Figure 1 of [RFC2131] .
. .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
message-size the number of octets in the message that follows, as a 16-bit unsigned integer in network byte order.
消息大小消息中的八位字节数，以网络字节顺序表示，为16位无符号整数。
All other fields are as specified in DHCPv4 [RFC2131].
所有其他字段如DHCPv4[RFC2131]中所述。
Figure 2: Format of a DHCPv4 Message in TCP
图2:TCP中DHCPv4消息的格式
The intent in using this format is that code that currently knows how to deal with sending or receiving a message in [RFC2131] format will easily be able to deal with the message contained in the TCP framing.
使用此格式的目的是，当前知道如何处理发送或接收[RFC2131]格式消息的代码将能够轻松处理TCP帧中包含的消息。
The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are used as the value of the dhcp-message-type option to indicate an IP address that is currently not leased or currently leased to a DHCPv4 client, respectively [RFC4388].
现有消息DHCPLEASEUNASSIGNED和DHCPLEASEACTIVE用作dhcp消息类型选项的值，分别表示当前未租用或租用给DHCPv4客户端的IP地址[RFC4388]。
Additional options have also been defined to enable the Bulk Leasequery protocol to communicate useful information to the requestor.
还定义了其他选项，以使批量租赁协议能够向请求者传递有用的信息。
The dhcp-message-type option (option 53) from Section 9.6 of [RFC2132] requires new values. The values of these message types are shown below in an extension of the table from Section 9.6 of [RFC2132]:
[RFC2132]第9.6节中的dhcp消息类型选项（选项53）需要新值。这些消息类型的值在[RFC2132]第9.6节表格的扩展部分中显示如下：
Value Message Type
----- ------------
14 DHCPBULKLEASEQUERY
15 DHCPLEASEQUERYDONE
Value Message Type
----- ------------
14 DHCPBULKLEASEQUERY
15 DHCPLEASEQUERYDONE
The status-code option allows a machine-readable value to be returned regarding the status of a DHCPBULKLEASEQUERY request.
status code选项允许返回有关DHCPBULKLEASEQUERY请求状态的机器可读值。
This option has two possible scopes when used with Bulk Leasequery, depending on the context in which it appears. It refers to the information in a single Leasequery reply if the value of the dhcp-message-type is DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED. It refers to the message stream related to an entire request if the value of the dhcp-message-type is DHCPLEASEQUERYDONE.
此选项与Bulk Leasequery一起使用时有两个可能的作用域，具体取决于它出现的上下文。如果dhcp消息类型的值为DHCPLEASEACTIVE或DHCPleAsUnassigned，则它是指单个Leasequery回复中的信息。如果dhcp消息类型的值为DHCPLeaseQueryOne，则它是指与整个请求相关的消息流。
The code for this option is 151. The length of this option is a minimum of 1 octet.
此选项的代码为151。此选项的长度至少为1个八位字节。
Status Status
Code Len Code Message
+------+------+------+------+------+-- --+-----+
| 151 | n+1 |status| s1 | s2 | ... | sn |
+------+------+------+------+------+-- --+-----+
Status Status
Code Len Code Message
+------+------+------+------+------+-- --+-----+
| 151 | n+1 |status| s1 | s2 | ... | sn |
+------+------+------+------+------+-- --+-----+
The status-code is indicated in one octet as defined in the table below. The Status Message is an optional UTF-8-encoded text string suitable for display to an end user. This text string MUST NOT contain a termination character (e.g., a null). The Len field describes the length of the Status Message without any terminator character. Null characters MUST NOT appear in the Status Message string, and it is a protocol violation for them to appear in any position in the Status Message, including at the end.
状态代码以下表中定义的一个八位字节表示。状态消息是一个可选的UTF-8编码文本字符串，适合向最终用户显示。此文本字符串不得包含终止字符（例如，null）。Len字段描述不带任何终止符的状态消息的长度。空字符不能出现在状态消息字符串中，如果它们出现在状态消息的任何位置（包括末尾），则违反了协议。
Name Status Code Description
---- ----------- -----------
Success 000 Success. Also signaled by absence of
a status-code option.
Name Status Code Description
---- ----------- -----------
Success 000 Success. Also signaled by absence of
a status-code option.
UnspecFail 001 Failure, reason unspecified.
UNSPECTFAIL 001故障，原因未明。
QueryTerminated 002 Indicates that the server is unable to perform a query or has prematurely terminated the query for some reason (which should be communicated in the text message).
QueryTerminated 002表示服务器无法执行查询，或由于某种原因（应在文本消息中传达）提前终止了查询。
MalformedQuery 003 The query was not understood.
查询003格式错误无法理解该查询。
NotAllowed 004 The query or request was understood but was not allowed in this context.
NotAllowed 004查询或请求已被理解，但在此上下文中不允许。
A status-code option MAY appear in the options field of a DHCPv4 message. If the status-code option does not appear, it is assumed that the operation was successful. The status-code option SHOULD NOT appear in a message that is successful unless there is some text string that needs to be communicated to the requestor.
状态代码选项可能出现在DHCPv4消息的选项字段中。如果状态代码选项未出现，则假定操作成功。状态代码选项不应出现在成功的消息中，除非有一些文本字符串需要传达给请求者。
The base-time option is the current time the message was created to be sent by the DHCPv4 server to the requestor of the Bulk Leasequery. This MUST be an absolute time. All of the other time-based options in the reply message are relative to this time, including the dhcp-lease-time [RFC2132] and client-last-transaction-time [RFC4388]. This time is in the context of the DHCPv4 server that placed this option in a message.
基本时间选项是创建消息的当前时间，该消息将由DHCPv4服务器发送给批量请求的请求者。这一定是绝对时间。回复消息中所有其他基于时间的选项都与此时间相关，包括dhcp租约时间[RFC2132]和客户端上次事务时间[RFC4388]。这一次是在DHCPv4服务器的上下文中，该服务器将此选项放置在消息中。
This is an unsigned integer in network byte order.
这是网络字节顺序的无符号整数。
The code for this option is 152. The length of this option is 4 octets.
此选项的代码为152。此选项的长度为4个八位字节。
DHCPv4 Server
Code Len base-time
+-----+-----+-----+-----+-----+-----+
| 152 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
DHCPv4 Server
Code Len base-time
+-----+-----+-----+-----+-----+-----+
| 152 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
The start-time-of-state option allows the receiver to determine the time at which the IP address made the transition into its current state.
start time of state选项允许接收方确定IP地址转换到其当前状态的时间。
This MUST NOT be an absolute time, which is equivalent to saying that this MUST NOT be an absolute number of seconds since January 1, 1970. Instead, this MUST be the unsigned integer number of seconds from the time the IP address transitioned its current state to the time specified in the base-time option in the same message.
这不能是绝对时间，也就是说，这不能是自1970年1月1日以来的绝对秒数。相反，这必须是无符号整数秒数，从IP地址转换其当前状态到同一消息中的“基本时间”选项中指定的时间。
This is an unsigned integer in network byte order.
这是网络字节顺序的无符号整数。
The code for this option is 153. The length of this option is 4 octets.
此选项的代码为153。此选项的长度为4个八位字节。
Seconds in the past
Code Len from base-time
+-----+-----+-----+-----+-----+-----+
| 153 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
Seconds in the past
Code Len from base-time
+-----+-----+-----+-----+-----+-----+
| 153 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
The query-start-time option specifies a start query time to the DHCPv4 server. If specified, only bindings that have changed on or after the query-start-time should be included in the response to the query.
查询开始时间选项指定DHCPv4服务器的开始查询时间。如果指定，则只有在查询开始时间当天或之后更改的绑定才应包含在查询响应中。
The requestor MUST determine the query-start-time using lease information it has received from the DHCPv4 server. This MUST be an absolute time in the DHCPv4 server's context (see Section 7.4).
请求者必须使用从DHCPv4服务器收到的租约信息确定查询开始时间。这必须是DHCPv4服务器上下文中的绝对时间（参见第7.4节）。
Typically (though this is not a requirement), the query-start-time option will contain the value most recently received in a base-time option by the requestor, as this will indicate the last successful communication with the DHCP server.
通常（尽管这不是一个要求），查询开始时间选项将包含请求者最近在基本时间选项中接收到的值，因为这将指示与DHCP服务器的最后一次成功通信。
This MUST be an absolute time.
这一定是绝对时间。
This is an unsigned integer in network byte order.
这是网络字节顺序的无符号整数。
The code for this option is 154. The length of this option is 4 octets.
此选项的代码为154。此选项的长度为4个八位字节。
DHCPv4 Server
Code Len query-start-time
+-----+-----+-----+-----+-----+-----+
| 154 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
DHCPv4 Server
Code Len query-start-time
+-----+-----+-----+-----+-----+-----+
| 154 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
The query-end-time option specifies an end query time to the DHCPv4 server. If specified, only bindings that have changed on or before the query-end-time should be included in the response to the query.
查询结束时间选项指定DHCPv4服务器的结束查询时间。如果指定，则只有在查询结束时间当天或之前更改的绑定才应包含在查询响应中。
The requestor MUST determine the query-end-time based on lease information it has received from the DHCPv4 server. This MUST be an absolute time in the context of the DHCPv4 server.
请求者必须根据从DHCPv4服务器收到的租约信息确定查询结束时间。在DHCPv4服务器的上下文中，这必须是绝对时间。
In the absence of information to the contrary, the requestor SHOULD assume that the time context of the DHCPv4 server is identical to the time context of the requestor (see Section 7.4).
如果没有相反的信息，请求者应假设DHCPv4服务器的时间上下文与请求者的时间上下文相同（参见第7.4节）。
This is an unsigned integer in network byte order.
这是网络字节顺序的无符号整数。
The code for this option is 155. The length of this option is 4 octets.
此选项的代码为155。此选项的长度为4个八位字节。
DHCPv4 Server
Code Len query-end-time
+-----+-----+-----+-----+-----+-----+
| 155 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
DHCPv4 Server
Code Len query-end-time
+-----+-----+-----+-----+-----+-----+
| 155 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
The dhcp-state option allows greater detail to be returned than allowed by the DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types.
dhcp状态选项允许返回比DHCPLEASEACTIVE和DHCPLEASEUNASSIGNED消息类型所允许的更详细的信息。
The code for this option is 156. The length of this option is 1 octet.
此选项的代码为156。此选项的长度为1个八位字节。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 156 | Length | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 156 | Length | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
156 The option code.
156选项代码。
Length The option length, 1 octet.
长度选项长度，1个八位字节。
State The state of the IP address.
说明IP地址的状态。
Value State
----- -----
1 AVAILABLE Address is available to local DHCPv4 server
2 ACTIVE Address is assigned to a DHCPv4 client
3 EXPIRED Lease has expired
4 RELEASED Lease has been released by DHCPv4 client
5 ABANDONED Server or client flagged address as unusable
6 RESET Lease was freed by some external agent
7 REMOTE Address is available to a remote DHCPv4 server
8 TRANSITIONING Address is moving between states
Value State
----- -----
1 AVAILABLE Address is available to local DHCPv4 server
2 ACTIVE Address is assigned to a DHCPv4 client
3 EXPIRED Lease has expired
4 RELEASED Lease has been released by DHCPv4 client
5 ABANDONED Server or client flagged address as unusable
6 RESET Lease was freed by some external agent
7 REMOTE Address is available to a remote DHCPv4 server
8 TRANSITIONING Address is moving between states
Note that some of these states may be transient and may not appear in normal use. A DHCPv4 server MUST implement at least the AVAILABLE and ACTIVE states and SHOULD implement at least the ABANDONED and RESET states.
请注意，其中一些状态可能是瞬态的，在正常使用中可能不会出现。DHCPv4服务器必须至少实现可用和活动状态，并且应至少实现放弃和重置状态。
Note the states AVAILABLE and REMOTE are relative to the current server. An address that is available to the current server should show AVAILABLE on that server, and if another server is involved with that address as well, it should show as REMOTE on that other server.
注意：可用状态和远程状态是相对于当前服务器的。当前服务器可用的地址应在该服务器上显示为可用，如果另一台服务器也与该地址相关，则该地址应在该另一台服务器上显示为远程。
The dhcp-state option SHOULD contain ACTIVE when it appears in a DHCPLEASEACTIVE message. A DHCPv4 server MAY choose to not send a dhcp-state option in a DHCPLEASEACTIVE message, and a requestor SHOULD assume that the dhcp-state is ACTIVE if no dhcp-state option appears in a DHCPLEASEACTIVE message.
dhcp状态选项出现在DHCPLEASEACTIVE消息中时应包含ACTIVE。DHCPv4服务器可以选择不在DHCPLEASEACTIVE消息中发送dhcp状态选项，如果DHCPLEASEACTIVE消息中没有出现dhcp状态选项，请求者应假定dhcp状态为活动状态。
The reference to local and remote relate to possible use in an environment that includes multiple servers cooperating to provide an increased availability solution. In this case, an IP address with the state of AVAILABLE is available to the local server, while one with the state of REMOTE is available to a remote server. Usually, an IP address that is AVAILABLE on one server would be REMOTE on any remote server. The TRANSITIONING state is also likely to be useful in multiple server deployments, where sometimes one server must interlock a state change with one or more other servers. Should a Bulk Leasequery need to send information concerning the state of the IP address during this period, it SHOULD use the TRANSITIONING state, since the IP address is likely to be neither ACTIVE or AVAILABLE.
“本地”和“远程”指的是在包括多台服务器协作以提供更高可用性解决方案的环境中的可能使用。在这种情况下，状态为“可用”的IP地址可用于本地服务器，而状态为“远程”的IP地址可用于远程服务器。通常，一台服务器上可用的IP地址在任何远程服务器上都是远程的。转换状态在多个服务器部署中也可能很有用，有时一个服务器必须将状态更改与一个或多个其他服务器联锁。如果批量租赁公司在此期间需要发送有关IP地址状态的信息，则应使用转换状态，因为IP地址可能既不活动也不可用。
There is no requirement for the state of an IP address to transition in a well-defined way from state to state. To put this another way, you cannot draw a simple state transition graph for the states of an IP address, and the requestor of a Leasequery MUST NOT depend on one certain state always following a particular previous state. While a state transition diagram can be drawn, it would be fully connected and therefore conveys no useful information. Every state can (at times) follow every other state.
不要求IP地址的状态以定义良好的方式从一个状态转换到另一个状态。换句话说，您不能为IP地址的状态绘制一个简单的状态转换图，并且Leasequery的请求者不能依赖于某个特定的状态，该状态总是在某个特定的前一个状态之后。虽然可以绘制状态转换图，但它是完全连接的，因此不会传递任何有用的信息。每个州（有时）都可以跟随其他州。
The data-source option contains information about the source of the data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message. It SHOULD be used when there are two or more servers that might have information about a particular IP address binding. Frequently, two servers work together to provide an increased availability solution for the DHCPv4 service, and in these cases, both servers will respond to Bulk Leasequery requests for the same IP address. When one server is working with another server and both may respond with information about the same IP address, each server SHOULD return the data-source option with the other information provided about the IP address.
数据源选项包含DHCPLEASEACTIVE或DHCPLEASEUNASSIGNED消息中的数据源信息。当有两个或多个服务器可能具有关于特定IP地址绑定的信息时，应该使用它。通常，两台服务器协同工作，为DHCPv4服务提供更高的可用性解决方案，在这种情况下，两台服务器都将响应相同IP地址的批量租赁请求。当一台服务器与另一台服务器协同工作时，两台服务器都可能会使用有关相同IP地址的信息进行响应，每个服务器都应返回数据源选项，并提供有关IP地址的其他信息。
The data contained in this option will allow an external process to better discriminate between the information provided by each of the servers servicing this IPv4 address.
此选项中包含的数据将允许外部进程更好地区分为该IPv4地址提供服务的每个服务器提供的信息。
The code for this option is 157. The length of this option is 1 octet.
此选项的代码为157。此选项的长度为1个八位字节。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 157 | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 157 | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
157 The option code.
157选项代码。
Length The option length, 1 octet.
长度选项长度，1个八位字节。
Flags The source information for this message.
标记此消息的源信息。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| UNA |R|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| UNA |R|
+-+-+-+-+-+-+-+-+
R: REMOTE flag
R：远程标志
remote = 1 local = 0
远程=1本地=0
UNA: UNASSIGNED
UNA：未分配
The REMOTE flag is used to indicate where the most recent change of state (or other interesting change) concerning this IPv4 address took place. If the value is local, then the change took place on the server from which this message was transmitted. If the value is remote, then the change took place on some other server and was made known to the server from which this message was transmitted.
远程标志用于指示与此IPv4地址有关的最新状态更改（或其他有趣的更改）发生的位置。如果该值是本地的，则更改发生在发送此消息的服务器上。如果该值是远程的，则该更改发生在其他服务器上，并被发送此消息的服务器知道。
If this option was requested and it doesn't appear, the requestor MUST consider that the data-source was local.
如果请求了这个选项并且它没有出现，请求者必须考虑数据源是本地的。
Unassigned bits MUST be ignored.
必须忽略未分配的位。
All of the (sub-)options defined in [RFC6607] carry identical payloads, consisting of a type and additional VSS (Virtual Subnet Selection) information. The existing table is extended (see below) with a new type 254 to allow specification of a type code that indicates that all VPNs are to be used to process the Bulk Leasequery.
[RFC6607]中定义的所有（子）选项都具有相同的有效载荷，包括类型和附加VSS（虚拟子网选择）信息。现有表格扩展为新的254类型（见下文），以允许指定类型代码，表明所有VPN将用于处理批量租赁。
Type VSS Information Format
----------------------------------------------------------
0 Network Virtual Terminal (NVT) ASCII VPN identifier
1 RFC 2685 VPN-ID
CHANGED -> 2-253 Unassigned
NEW -> 254 All VPNs (wildcard)
255 Global, default VPN
Type VSS Information Format
----------------------------------------------------------
0 Network Virtual Terminal (NVT) ASCII VPN identifier
1 RFC 2685 VPN-ID
CHANGED -> 2-253 Unassigned
NEW -> 254 All VPNs (wildcard)
255 Global, default VPN
DHCPv4 servers that support Bulk Leasequery SHOULD listen for incoming TCP connections on the DHCPv4 server port 67. Implementations MAY offer to make the incoming port configurable, but port 67 MUST be the default. Requestors SHOULD make TCP connections to port 67 and MAY offer to make the destination server port configurable.
支持批量租赁的DHCPv4服务器应侦听DHCPv4服务器端口67上的传入TCP连接。实现可能提供使传入端口可配置，但端口67必须是默认端口。请求者应与端口67建立TCP连接，并可提供使目标服务器端口可配置的服务。
This section presents a table of values used to control Bulk Leasequery behavior, including recommended defaults. Implementations MAY make these values configurable. However, configuring too-small timeout values may lead to harmful behavior both to this application as well as to other traffic in the network. As a result, timeout values smaller than the default values are NOT RECOMMENDED.
本节介绍用于控制批量租赁行为的值表，包括推荐的默认值。实现可以使这些值可配置。但是，配置太小的超时值可能会导致此应用程序以及网络中的其他流量出现有害行为。因此，不建议使用小于默认值的超时值。
Parameter Default Description
--------------------------------------------------------------------
BULK_LQ_DATA_TIMEOUT 300 secs Bulk Leasequery data timeout
for both client and server
(see Sections 7 and 8)
BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
at the server side (see Section 8.1)
Parameter Default Description
--------------------------------------------------------------------
BULK_LQ_DATA_TIMEOUT 300 secs Bulk Leasequery data timeout
for both client and server
(see Sections 7 and 8)
BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
at the server side (see Section 8.1)
A requestor attempts to establish a TCP connection to a DHCPv4 server in order to initiate a Leasequery exchange. If the attempt fails, the requestor MAY retry.
请求者试图建立到DHCPv4服务器的TCP连接，以启动请求交换。如果尝试失败，请求者可以重试。
If Bulk Leasequery is terminated prematurely by a DHCPLEASEQUERYDONE with a status-code option with a status code of QueryTerminated or by the failure of the connection over which it was being submitted, the requestor MAY retry the request after the creation of a new connection.
如果具有状态代码为QueryTerminated的状态代码选项的DHCPLEASEQUERYDONE提前终止批量租赁请求，或者由于提交请求的连接失败而提前终止批量租赁请求，请求者可以在创建新连接后重试请求。
Messages from the DHCPv4 server come as multiple responses to a single DHCPBULKLEASEQUERY message. Thus, each DHCPBULKLEASEQUERY request MUST have an xid (transaction-id) unique on the connection on which it is sent. All of the messages that come as a response to that message will contain the same xid as the request. The xid allows the data-streams of two different DHCPBULKLEASEQUERY requests to be demultiplexed by the requestor.
来自DHCPv4服务器的消息是对单个DHCPBULKLEASEQUERY消息的多个响应。因此，每个DHCPBULKLEASEQUERY请求在其发送的连接上必须具有唯一的xid（事务id）。作为对该消息的响应而来的所有消息将包含与请求相同的xid。xid允许请求者将两个不同DHCPBULKLEASEQUERY请求的数据流解复用。
Bulk Leasequery is designed to create a connection that will transfer the state of some subset (or possibly all) of the IP address bindings from the DHCPv4 server to the requestor. The DHCPv4 server will send all of the requested IPv4 address bindings across this connection with minimal delay after it receives the request. In this context, "all IP address binding information" means information about all IPv4 addresses configured within the DHCPv4 server that meet the specified query criteria. For some query criteria, this may include IP address binding information for IP addresses that may not now have or ever have had an association with a specific DHCPv4 client.
Bulk Leasequery旨在创建一个连接，该连接将IP地址绑定的某些子集（或可能全部）的状态从DHCPv4服务器传输到请求者。DHCPv4服务器将在收到请求后以最小的延迟通过此连接发送所有请求的IPv4地址绑定。在此上下文中，“所有IP地址绑定信息”是指有关在DHCPv4服务器中配置的、满足指定查询条件的所有IPv4地址的信息。对于某些查询条件，这可能包括IP地址的IP地址绑定信息，这些IP地址可能现在或曾经与特定DHCPv4客户端没有关联。
To form the Bulk query, a DHCPv4 request is constructed with a dhcp-message-type of DHCPBULKLEASEQUERY. The query SHOULD have a dhcp-parameter-request-list to inform the DHCPv4 server which DHCPv4 options are of interest to the requestor sending the DHCPBULKLEASEQUERY message. The dhcp-parameter-request-list in a DHCPBULKLEASEQUERY message SHOULD contain the codes for base-time, dhcp-lease-time, start-time-of-state, and client-last-transaction-time.
为了形成批量查询，使用DHCPBULKLEASEQUERY的dhcp消息类型构造DHCPv4请求。查询应具有dhcp参数请求列表，以通知DHCPv4服务器发送DHCPBULKLEASEQUERY消息的请求者感兴趣的DHCPv4选项。DHCPBULKLEASEQUERY消息中的dhcp参数请求列表应包含基本时间、dhcp租约时间、状态开始时间和客户端上次事务时间的代码。
A DHCPBULKLEASEQUERY request is constructed of one primary query and optionally one or more qualifiers for it.
DHCPBULKLEASEQUERY请求由一个主查询和可选的一个或多个限定符构成。
The possible primary queries are listed below. Each DHCPBULKLEASEQUERY request MUST contain only one of these primary queries.
下面列出了可能的主要查询。每个DHCPBULKLEASEQUERY请求只能包含其中一个主查询。
o Query by MAC address
o 按MAC地址查询
In a Query by MAC address, the chaddr, htype, and hlen of the DHCPv4 packet are filled in with the values requested.
在按MAC地址查询中，DHCPv4数据包的chaddr、htype和hlen将填入请求的值。
o Query by Client-identifier
o 按客户端标识符查询
In a Query by Client-identifier, a Client-identifier option containing the requested value is included in the DHCPBULKLEASEQUERY request.
在按客户端标识符进行的查询中，包含请求值的客户端标识符选项包含在DHCPBULKLEASEQUERY请求中。
o Query by Remote ID
o 按远程ID查询
In a Query by Remote ID, a Remote ID sub-option containing the requested value is included in the relay-agent-information option of the DHCPBULKLEASEQUERY request.
在按远程ID查询中，包含请求值的远程ID子选项包含在DHCPBULKLEASEQUERY请求的中继代理信息选项中。
o Query by Relay-ID
o 按中继ID查询
In a Query by Relay-ID, a Relay-ID sub-option [RFC6925] containing the requested value is included in the relay-agent-information option of the DHCPBULKLEASEQUERY request.
在按中继ID查询中，包含请求值的中继ID子选项[RFC6925]包含在DHCPBULKLEASEQUERY请求的中继代理信息选项中。
o Query for All Configured IP Addresses
o 查询所有配置的IP地址
A Query for All Configured IP addresses is signaled by the absence of any other primary query.
如果没有任何其他主查询，则表示查询所有配置的IP地址。
There are three qualifiers that can be applied to any of the above primary queries. These qualifiers can appear individually or together in any combination, but only one of each can appear.
有三个限定符可应用于上述任何主要查询。这些限定符可以单独出现，也可以组合出现，但每个限定符只能出现一个。
o Query Start Time
o 查询开始时间
Inclusion of a query-start-time option specifies that only IP address bindings that have changed on or after the time specified in the query-start-time option should be returned.
包含查询开始时间选项指定只返回在查询开始时间选项中指定的时间当天或之后更改的IP地址绑定。
o Query End Time
o 查询结束时间
Inclusion of a query-end-time option specifies that only IP address bindings that have changed on or before the time specified in the query-end-time option should be returned.
包含查询结束时间选项指定只返回在查询结束时间选项中指定的时间当天或之前更改的IP地址绑定。
o VPN-ID
o VPN-ID
If no VPN-ID option appears in the DHCPBULKLEASEQUERY, the default (global) VPN is searched to satisfy the query specified by the DHCPBULKLEASEQUERY. Using the VPN-ID option [RFC6607] allows the requestor to specify a single VPN other than the default VPN. In addition, the VPN-ID option has been extended as part of this document to allow specification that all configured VPNs be searched in order to satisfy the query specified in the DHCPBULKLEASEQUERY.
如果DHCPBULKLEASEQUERY中没有出现VPN-ID选项，则搜索默认（全局）VPN以满足DHCPBULKLEASEQUERY指定的查询。使用VPN-ID选项[RFC6607]允许请求者指定默认VPN以外的单个VPN。此外，VPN-ID选项已扩展为本文档的一部分，以允许搜索所有配置的VPN，以满足DHCPBULKLEASEQUERY中指定的查询。
In all cases, any message returned from a DHCPBULKLEASEQUERY request containing information about an IP address for other than the default (global) VPN MUST contain a VPN-ID option in the message.
在所有情况下，从DHCPBULKLEASEQUERY请求返回的任何消息（包含有关默认（全局）VPN以外的IP地址的信息）必须在消息中包含VPN-ID选项。
Use of the query-start-time or the query-end-time options or both can serve to reduce the amount of data transferred over the TCP connection by a considerable amount. Note that the times specified in the query-start-time or query-end-time options are absolute times, not durations offset from "now".
使用查询开始时间或查询结束时间选项或两者都可以将通过TCP连接传输的数据量减少相当多。请注意，查询开始时间或查询结束时间选项中指定的时间是绝对时间，而不是从“现在”开始偏移的持续时间。
The TCP connection may become blocked or stop being writable while the requestor is sending its query. Should this happen, the implementation's behavior is controlled by the current value of BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this document, and this value may be overridden by local configuration of the operator.
当请求者发送其查询时，TCP连接可能被阻止或停止可写。如果发生这种情况，实现的行为将由BULK_LQ_DATA_TIMEOUT的当前值控制。本文档其他地方给出了默认值，该值可能会被操作员的本地配置覆盖。
If this situation is detected, the requestor SHOULD start a timer using the current value of BULK_LQ_DATA_TIMEOUT. If that timer expires, the requestor SHOULD terminate the connection. This timer is completely independent of any TCP timeout established by the TCP protocol connection.
如果检测到这种情况，请求者应该使用BULK_LQ_DATA_TIMEOUT的当前值启动计时器。如果计时器过期，请求者应该终止连接。此计时器完全独立于TCP协议连接建立的任何TCP超时。
The requestor attempts to read a DHCPv4 Leasequery reply message from the TCP connection.
请求者尝试从TCP连接读取DHCPv4 Leasequery回复消息。
The TCP connection may stop delivering reply data (i.e., the connection stops being readable). Should this happen, the implementation's behavior is controlled by the current value of BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this document, and this value may be overridden by local configuration of the operator.
TCP连接可能停止传送应答数据（即，连接停止可读）。如果发生这种情况，实现的行为将由BULK_LQ_DATA_TIMEOUT的当前值控制。本文档其他地方给出了默认值，该值可能会被操作员的本地配置覆盖。
If this situation is detected, the requestor SHOULD start a timer using the current value of BULK_LQ_DATA_TIMEOUT. If that timer expires, the requestor SHOULD terminate the connection.
如果检测到这种情况，请求者应该使用BULK_LQ_DATA_TIMEOUT的当前值启动计时器。如果计时器过期，请求者应该终止连接。
A single Bulk Leasequery can, and usually will, result in a large number of replies. The requestor MUST be prepared to receive more than one reply with an xid matching a single DHCPBULKLEASEQUERY message from a single DHCPv4 server. If the xid in the received message does not match an outstanding DHCPBULKLEASEQUERY message, the requestor MUST close the TCP connection.
单个批量租赁可以，而且通常会导致大量回复。请求者必须准备好从单个DHCPv4服务器接收多个具有与单个DHCPBULKLEASEQUERY消息匹配的xid的回复。如果收到的消息中的xid与未完成的DHCPBULKLEASEQUERY消息不匹配，请求者必须关闭TCP连接。
If the requestor receives more data than it can process, it can simply abort the connection and try again with a more specific request. It can also simply read the TCP connection more slowly and match the rate at which it can digest the information returned in the Bulk Leasequery packets with the rate at which it reads those packets from the TCP connection.
如果请求者接收到的数据超过了其处理能力，它可以简单地中止连接，然后使用更具体的请求重试。它还可以简单地以更慢的速度读取TCP连接，并将其消化Bulk Leasequery数据包中返回的信息的速率与从TCP连接读取这些数据包的速率相匹配。
The DHCPv4 server MUST send a server-identifier option (option 54) in the first response to any DHCPBULKLEASEQUERY message. The DHCPv4 server SHOULD NOT send server-identifier options in subsequent responses to that DHCPBULKLEASEQUERY message. The requestor MUST cache the server-identifier option from the first response and apply it to any subsequent responses.
DHCPv4服务器必须在对任何DHCPBULKLEASEQUERY消息的第一次响应中发送服务器标识符选项（选项54）。DHCPv4服务器不应在对该DHCPBULKLEASEQUERY消息的后续响应中发送服务器标识符选项。请求者必须缓存第一个响应中的服务器标识符选项，并将其应用于任何后续响应。
The response messages generated by a DHCPBULKLEASEQUERY request are:
DHCPBULKLEASEQUERY请求生成的响应消息包括：
o DHCPLEASEACTIVE
o DHCPlaseActive
A Bulk Leasequery will generate DHCPLEASEACTIVE messages containing binding data for bound IP addresses that match the specified query criteria. The IP address that is bound to a DHCPv4 client will appear in the ciaddr field of the DHCPLEASEACTIVE message. The message may contain a non-zero chaddr, htype, hlen, and possibly additional options.
批量租赁将生成DHCPLEASEACTIVE消息，其中包含符合指定查询条件的绑定IP地址的绑定数据。绑定到DHCPv4客户端的IP地址将显示在DHCPLEASEACTIVE消息的ciaddr字段中。消息可能包含非零chaddr、htype、hlen以及可能的其他选项。
o DHCPLEASEUNASSIGNED
o 未分配
Some queries will also generate DHCPLEASEUNASSIGNED messages for IP addresses that match the query criteria. These messages indicate that the IP address is managed by the DHCPv4 server but is not currently bound to any DHCPv4 client. The IP address to which this message refers will appear in the ciaddr field of the DHCPLEASEUNASSIGNED message. A DHCPLEASEUNASSGINED message MAY also contain information about the last DHCPv4 client that was bound to this IP address. The message may contain a non-zero chaddr, htype, hlen, and possibly additional options in this case.
一些查询还将为符合查询条件的IP地址生成未分配消息。这些消息表示IP地址由DHCPv4服务器管理，但当前未绑定到任何DHCPv4客户端。此消息引用的IP地址将显示在DHCPLEASEUNASSIGNED消息的ciaddr字段中。DHCPLeaseUnasgned消息还可能包含关于绑定到此IP地址的最后一个DHCPv4客户端的信息。消息可能包含非零chaddr、htype、hlen，在本例中可能还包含其他选项。
o DHCPLEASEQUERYDONE
o DHCPLEASEQUERYDONE
A response of DHCPLEASEQUERYDONE indicates that the server has completed its response to the query and that no more messages will be sent in response to the DHCPBULKLEASEQUERY. More details will sometimes be available in the received status-code option in the DHCPLEASEQUERYDONE message. If there is no status-code option in the DHCPLEASEQUERYDONE message, then the query completed successfully.
DHCPLeaseQueryOne的响应表示服务器已完成对查询的响应，并且不会再发送任何消息来响应DHCPBULKLEASEQUERY。DHCPLeaseQueryOne消息中的received status code（接收状态代码）选项有时会提供更多详细信息。如果DHCPLeaseQueryOne消息中没有状态代码选项，则查询成功完成。
Note that a query that returned no data, that is, a DHCPBULKLEASEQUERY request followed by a DHCPLEASEQUERYDONE response, is considered a successful query in that no errors occurred during the processing. It is not considered an error to have no information to return to a DHCPBULKLEASEQUERY request.
请注意，如果查询没有返回任何数据，即DHCPBulkLeaseRequest请求后跟DHCPLeaseQueryOne响应，则认为该查询是成功的，因为在处理过程中没有发生错误。没有返回DHCPBULKLEASEQUERY请求的信息不被视为错误。
The DHCPLEASEUNKNOWN message MUST NOT appear in a response to a Bulk Leasequery.
DHCPLEASEUNKNOWN消息不得出现在对批量请求的响应中。
The requestor MUST NOT assume that there is any inherent order in the IP address binding information that is sent in response to a DHCPBULKLEASEQUERY. While the base-time will tend to increase monotonically (as it is the current time on the DHCPv4 server), the actual time that any IP address binding information changed is unrelated to the base-time.
请求者不得假设为响应DHCPBULKLEASEQUERY而发送的IP地址绑定信息中存在任何固有顺序。虽然基准时间将趋于单调增加（因为它是DHCPv4服务器上的当前时间），但任何IP地址绑定信息更改的实际时间与基准时间无关。
The DHCPLEASEQUERYDONE message always ends a successful DHCPBULKLEASEQUERY request and any unsuccessful DHCPBULKLEASEQUERY requests not terminated by a dropped connection. After receiving a DHCPLEASEQUERYDONE from a server, the requestor MAY close the TCP connection to that server if no other DHCPBULKLEASEQUERY is outstanding on that TCP connection.
DHCPLeaseQueryOne消息始终结束一个成功的DHCPBULKLEASEQUERY请求和任何未被断开的连接终止的不成功的DHCPBULKLEASEQUERY请求。从服务器接收到DHCPLeaseQueryOne后，如果TCP连接上没有其他未完成的DHCPBulkLeaseRequesty，请求者可以关闭与该服务器的TCP连接。
The DHCPv4 Leasequery protocol [RFC4388] uses the associated-ip option as an indicator that multiple bindings were present in response to a single DHCPv4 client-based query. For Bulk Leasequery, a separate message is returned for each binding, so the associated-ip option is not used.
DHCPv4 Leasequery协议[RFC4388]使用关联的ip选项作为指示器，指示存在多个绑定以响应单个基于DHCPv4客户端的查询。对于批量租赁，将为每个绑定返回单独的消息，因此不使用关联的ip选项。
Bulk Leasequery requests may be made to a DHCPv4 server whose absolute time may not be synchronized with the local time of the requestor. Thus, there are at least two time contexts in even the simplest Bulk Leasequery response, and in the situation where multiple DHCPv4 servers are queried, the situation becomes even more complex.
可向DHCPv4服务器发出批量租赁请求，该服务器的绝对时间可能与请求者的本地时间不同步。因此，即使在最简单的批量请求响应中，也至少存在两个时间上下文，并且在查询多个DHCPv4服务器的情况下，情况变得更加复杂。
If the requestor of a Bulk Leasequery is saving the data returned in some form, it has a requirement to store a variety of time values; some of these will be time in the context of the requestor, and some will be time in the context of the DHCPv4 server.
如果批量租赁请求者正在保存以某种形式返回的数据，则需要存储各种时间值；其中一些是请求者上下文中的时间，一些是DHCPv4服务器上下文中的时间。
When receiving a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message from the DHCPv4 server, the message will contain a base-time option. The time contained in this base-time option is in the context of the DHCPv4 server. As such, it is an ideal time to save and use as input to a DHCPBULKLEASEQUERY in the query-start-time or query-end-time options, should the requestor ever need to issue a DHCPBULKLEASEQUERY message using those options as part of a later query, since those options require a time in the context of the DHCPv4 server.
当从DHCPv4服务器接收DHCPLEASEACTIVE或DHCPLEASEUNASSIGNED消息时，该消息将包含一个基准时间选项。此基本时间选项中包含的时间在DHCPv4服务器的上下文中。因此，在查询开始时间或查询结束时间选项中，如果请求者需要在以后的查询中使用这些选项发出DHCPBULKLEASEQUERY消息，这是保存并用作DHCPBULKLEASEQUERY输入的理想时间，因为这些选项在DHCPv4服务器的上下文中需要一段时间。
In addition to saving the base-time for possible future use in a query-start-time or query-end-time option, the base-time is used as part of the conversion of the other times in the Leasequery message to values that are meaningful in the context of the requestor. These other time values are specified as a offset (duration) from the base-time value and not as an absolute time.
除了在查询开始时间或查询结束时间选项中保存基准时间以备将来可能使用外，基准时间还用于将Leasequery消息中的其他时间转换为在请求者上下文中有意义的值。这些其他时间值指定为基准时间值的偏移量（持续时间），而不是绝对时间。
In systems whose clocks are synchronized, perhaps using NTP, the clock skew will usually be zero.
在时钟同步的系统中，可能使用NTP，时钟偏差通常为零。
A Bulk Leasequery requestor MAY be configured to attempt to connect to and query from multiple DHCPv4 servers in parallel. The DHCPv4 Leasequery specification [RFC4388] includes a discussion about reconciling binding data received from multiple DHCPv4 servers.
批量租赁请求程序可配置为尝试并行连接到多个DHCPv4服务器并从中进行查询。DHCPv4租赁规范[RFC4388]包括关于协调从多个DHCPv4服务器接收的绑定数据的讨论。
In addition, the algorithm in Section 7.6 should be used.
此外，应使用第7.6节中的算法。
7.6. Making Sense out of Multiple Responses concerning a Single IPv4 Address
7.6. 利用关于单个IPv4地址的多个响应
Any requestor of an Bulk Leasequery MUST be prepared for multiple responses to arrive for a particular IPv4 address from multiple different DHCPv4 servers. The following algorithm SHOULD be used to decide if the information just received is more up to date (i.e., better) than the best existing information. In the discussion below, the information that is received from a DHCPv4 server about a particular IPv4 address is termed a "record". The times used in the algorithm below SHOULD have been converted into the requestor's context, and the time comparisons SHOULD be performed in a manner consistent with the information in Section 7.4.
批量租赁请求的任何请求者都必须准备好从多个不同的DHCPv4服务器获得特定IPv4地址的多个响应。应使用以下算法来确定刚刚收到的信息是否比最佳现有信息更为最新（即更好）。在下面的讨论中，从DHCPv4服务器接收的关于特定IPv4地址的信息称为“记录”。以下算法中使用的时间应已转换为请求者的上下文，时间比较应以与第7.4节中信息一致的方式进行。
o If both the existing and the new record contain client-last-transaction-time information, the record with the later client-last-transaction-time is considered better.
o 如果现有记录和新记录都包含客户端上次事务时间信息，则认为具有较晚客户端上次事务时间的记录更好。
o If one of the records contains client-last-transaction-time information and the other one doesn't, then compare the client-last-transaction-time in the record that contains it against the other record's start-time-of-state. The record with the later time is considered better.
o 如果其中一条记录包含客户端上次事务时间信息，而另一条不包含，则将包含该信息的记录中的客户端上次事务时间与另一条记录的状态开始时间进行比较。时间越晚的记录被认为越好。
o If neither record contains client-last-transaction-time information, compare their start-time-of-state information. The record with the later start-time-of-state is considered better.
o 如果两条记录都不包含客户端上次事务时间信息，请比较它们的状态信息的开始时间。状态开始时间较晚的记录被认为更好。
o If none of the comparisons above yield a clear answer as to which record is later, then compare the value of the REMOTE flag from the data-source option for each record. If the values of the REMOTE flag are different between the two records, the record with the REMOTE flag value of local is considered better.
o 如果上面的比较都没有给出哪个记录更晚的明确答案，那么比较每个记录的数据源选项中远程标志的值。如果两个记录之间的远程标志值不同，则认为远程标志值为local的记录更好。
The above algorithm does not necessarily determine which record is better. In the event that the algorithm is inconclusive with regard to a record that was just received by the requestor, the requestor SHOULD use additional information in the two records to make a determination as to which record is better.
上述算法不一定确定哪个记录更好。如果算法对于请求者刚收到的记录不确定，请求者应使用两个记录中的附加信息来确定哪个记录更好。
Bulk Leasequery requestors may need to make multiple queries in order to recover binding information. A requestor MAY use a single connection to issue multiple queries to a server willing to support them. Each query MUST have a unique xid.
批量租赁请求者可能需要进行多个查询以恢复绑定信息。请求者可以使用单个连接向愿意支持它们的服务器发出多个查询。每个查询必须具有唯一的xid。
A server SHOULD allow configuration of the number of queries that can be processed simultaneously over a single connection. A server SHOULD read the number of queries it is configured to process simultaneously and only read any subsequent queries as current queries are processed.
服务器应允许配置可通过单个连接同时处理的查询数。服务器应该读取其配置为同时处理的查询数，并且只在处理当前查询时读取任何后续查询。
A server that is processing multiple queries simultaneously MUST NOT block sending replies on new queries until all replies for the existing query are complete. Requestors need to be aware that replies for multiple queries may be interleaved within the stream of reply messages. Requestors that are not able to process interleaved replies (based on xid) MUST NOT send more than one query over a single connection prior to the completion of the previous query.
同时处理多个查询的服务器在现有查询的所有答复完成之前，不得阻止发送对新查询的答复。请求者需要知道，多个查询的回复可能在回复消息流中交错。无法处理交错回复（基于xid）的请求者在完成前一个查询之前，不得通过单个连接发送多个查询。
Requestors should be aware that servers are not required to process more than one query over a connection at a time (the limiting case for the configuration described above) and that servers are likely to limit the rate at which they process queries from any one requestor.
请求者应该知道，服务器不需要一次通过连接处理多个查询（上述配置的限制情况），并且服务器可能会限制它们处理来自任何一个请求者的查询的速率。
This example illustrates what a series of queries and responses might look like. This is only an example -- there is no requirement that this sequence must be followed or that requestors or servers must support parallel queries.
此示例演示了一系列查询和响应的外观。这只是一个示例——不要求必须遵循此序列，也不要求请求者或服务器必须支持并行查询。
In the example session, the client sends four queries after establishing a connection. Query 1 returns no results; query 2 returns 3 messages, and the stream of replies concludes before the client issues any new query. Query 3 and query 4 overlap, and the server interleaves its replies to those two queries.
在示例会话中，客户端在建立连接后发送四个查询。查询1不返回任何结果；查询2返回3条消息，在客户端发出任何新查询之前，回复流结束。查询3和查询4重叠，服务器将其对这两个查询的答复交织在一起。
Requestor Server
--------- ------
DHCPBULKLEASEQUERY xid 1 ----->
<----- DHCPLEASEQUERYDONE xid 1
DHCPBULKLEASEQUERY xid 2 ----->
<----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEQUERYDONE xid 2
DHCPBULKLEASEQUERY xid 3 ----->
DHCPBULKLEASEQUERY xid 4 ----->
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 3
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEUNASSIGNED xid 3
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 3
<----- DHCPLEASEQUERYDONE xid 3
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEQUERYDONE xid 4
Requestor Server
--------- ------
DHCPBULKLEASEQUERY xid 1 ----->
<----- DHCPLEASEQUERYDONE xid 1
DHCPBULKLEASEQUERY xid 2 ----->
<----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEQUERYDONE xid 2
DHCPBULKLEASEQUERY xid 3 ----->
DHCPBULKLEASEQUERY xid 4 ----->
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 3
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEUNASSIGNED xid 3
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 3
<----- DHCPLEASEQUERYDONE xid 3
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEQUERYDONE xid 4
If a requestor has no additional queries to send, or doesn't know if it has additional queries to send or not, then it SHOULD close the connection after receiving the DHCPLEASEQUERYDONE message for the last outstanding query that it sent.
如果请求者没有其他要发送的查询，或者不知道是否有其他要发送的查询，那么它应该在收到上次发送的未完成查询的DHCPLeaseQueryOne消息后关闭连接。
The requestor SHOULD close connections in a graceful manner and not an abort. The requestor SHOULD NOT assume that the manner in which the DHCP server closed a connection carries any special meaning.
请求者应该以优雅的方式关闭连接，而不是中止。请求者不应认为DHCP服务器关闭连接的方式具有任何特殊意义。
Typically, the requestor is the entity that will close the connection, as servers will often wait with an open connection in case the requestor has additional queries.
通常，请求者是将关闭连接的实体，因为如果请求者有其他查询，服务器通常会使用打开的连接等待。
If a server closes a connection with an exception condition, the requestor SHOULD consider as valid any completely received intermediate results, and the requestor MAY retry the Bulk Leasequery operation.
如果服务器关闭具有异常条件的连接，请求者应该认为任何完全接收的中间结果都是有效的，并且请求者可以重试散列出租操作。
Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP connections. Port numbers are discussed in Section 6.3. Servers MUST be able to limit the number of concurrently accepted and active connections. The value BULK_LQ_MAX_CONNS SHOULD be the default; implementations MAY permit the value to be configurable. Connections SHOULD be accepted and, if the number of connections is over BULK_LQ_MAX_CONNS, they SHOULD be closed immediately.
实现DHCPv4批量租赁请求的服务器侦听传入的TCP连接。第6.3节讨论了端口号。服务器必须能够限制并发接受和活动连接的数量。值BULK_LQ_MAX_CONNS应为默认值；实现可能允许对值进行配置。应接受连接，如果连接数量超过批量连接，应立即关闭连接。
Servers MAY restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY messages to certain requestors. Connections not from permitted requestors SHOULD be closed immediately to avoid server connection resource exhaustion. Servers MAY restrict some requestors to certain query types. Servers MAY reply to queries that are not permitted with the DHCPLEASEQUERYDONE message with a status-code option status of NotAllowed or MAY simply close the connection.
服务器可能会将批量Leasequery连接和DHCPBULKLEASEQUERY消息限制给某些请求者。应立即关闭来自不允许的请求者的连接，以避免服务器连接资源耗尽。服务器可能会将某些请求者限制为某些查询类型。服务器可以使用状态代码选项status为NotAllowed来答复DHCPLeaseQueryOne消息不允许的查询，也可以简单地关闭连接。
If the TCP connection becomes blocked while the server is accepting a connection or reading a query, it SHOULD be prepared to terminate the connection after a BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow servers to control the period of time they are willing to wait before abandoning an inactive connection, independent of the TCP implementations they may be using.
如果TCP连接在服务器接受连接或读取查询时被阻塞，则应准备在批量\u LQ\u数据\u超时后终止连接。我们提出这一建议是为了允许服务器在放弃非活动连接之前控制他们愿意等待的时间段，这与他们可能使用的TCP实现无关。
If the connection becomes blocked while the server is attempting to send reply messages, the server SHOULD be prepared to terminate the TCP connection after a BULK_LQ_DATA_TIMEOUT.
如果在服务器尝试发送回复消息时连接被阻止，则服务器应准备在批量\u LQ\u数据\u超时后终止TCP连接。
Every Bulk Leasequery request MUST be terminated by sending a final DHCPLEASEQUERYDONE message if such a message can be sent. The DHCPLEASEQUERYDONE message MUST have a status-code option status if the termination was other than successful, and SHOULD NOT contain a status-code option status if the termination was successful.
如果可以发送最终DHCPLeaseQueryOne消息，则必须通过发送最终DHCPLeaseQueryOne消息来终止每个批量租赁请求。如果终止未成功，则DHCPLeaseQueryOne消息必须具有状态代码选项状态，如果终止成功，则不应包含状态代码选项状态。
If the DHCPv4 server encounters an error during processing of the DHCPBULKLEASEQUERY message, either during initial processing or later during the message processing, it SHOULD send a DHCPLEASEQUERYDONE containing a status-code option. It MAY close the connection after this error is signaled, but that is not required.
如果DHCPv4服务器在处理DHCPBULKLEASEQUERY消息期间（无论是在初始处理期间还是在消息处理的后期）遇到错误，则应发送包含状态代码选项的DHCPleaseQueryOne。发出此错误信号后，它可能会关闭连接，但这不是必需的。
If the server does not find any bindings satisfying a query, it MUST send a DHCPLEASEQUERYDONE. It SHOULD NOT include a status-code option with a Success status unless there is a useful string to include in the status-code option. Otherwise, the server sends each binding's data in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message.
如果服务器未找到任何满足查询的绑定，则必须发送DHCPLeaseQueryOne。除非状态代码选项中包含有用的字符串，否则它不应包含状态为成功的状态代码选项。否则，服务器将在DHCPLEASEACTIVE或DHCPLEASEUNASSIGNED消息中发送每个绑定的数据。
The response to a DHCPBULKLEASEQUERY may involve examination of multiple DHCPv4 IP address bindings maintained by the DHCPv4 server. The Bulk Leasequery protocol does not require any ordering of the IP addresses returned in DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED messages.
对DHCPBULKLEASEQUERY的响应可能涉及检查DHCPv4服务器维护的多个DHCPv4 IP地址绑定。批量租赁协议不要求对DHCPLEASEACTIVE或DHCPleASUnassigned消息中返回的IP地址进行任何排序。
When responding to a DHCPBULKLEASEQUERY message, the DHCPv4 server MUST NOT send more than one message for each applicable IP address, even if the state of some of those IP addresses changes during the processing of the message. Updates to such IP address state are already handled by normal protocol processing, so no special effort is needed here.
在响应DHCPBULKLEASEQUERY消息时，DHCPv4服务器不得为每个适用的IP地址发送多条消息，即使其中一些IP地址的状态在消息处理过程中发生变化。对这样的IP地址状态的更新已经由正常的协议处理来处理，所以这里不需要特别的努力。
If the ciaddr, yiaddr, or siaddr is non-zero in a DHCPBULKLEASEQUERY request, the request must be terminated immediately by a DHCPLEASEQUERYDONE message with a status-code option status of MalformedQuery.
如果DHCPBULKLEASEQUERY请求中的ciaddr、yiaddr或siaddr非零，则必须立即通过DHCPLeaseQueryOne消息终止该请求，该消息的状态代码选项状态为畸形查询。
Any DHCPBULKLEASEQUERY that has more than one of the following primary query types specified MUST be terminated immediately by a DHCPLEASEQUERYDONE message with a status-code option status code of NotAllowed.
任何指定了以下一种以上主查询类型的DHCPBULKLEASEQUERY都必须立即通过状态代码选项status code为NotAllowed的DHCPLeaseQueryOne消息终止。
The allowable queries in a DHCPBULKLEASEQUERY message are processed as follows. Note that the descriptions of the primary queries below must be constrained by the actions of any of the three qualifiers described subsequently as well.
DHCPBULKLEASEQUERY消息中允许的查询处理如下。请注意，以下主要查询的描述也必须受到后面描述的三个限定符中任何一个的操作的约束。
The following table discusses how to process the various queries. For information on how to identify the query, see the information in Section 7.2.
下表讨论了如何处理各种查询。有关如何识别查询的信息，请参阅第7.2节中的信息。
o Query by MAC address
o 按MAC地址查询
Every IP address that has a current binding to a DHCPv4 client matching the chaddr, htype, and hlen in the DHCPBULKLEASEQUERY request MUST be returned in a DHCPLEASEACTIVE message.
与DHCPBULKLEASEQUERY请求中的chaddr、htype和hlen匹配的DHCPv4客户端具有当前绑定的每个IP地址必须在DHCPLEASEACTIVE消息中返回。
o Query by Client-identifier
o 按客户端标识符查询
Every IP address that has a current binding to a DHCPv4 client matching the Client-identifier option in the DHCPBULKLEASEQUERY request MUST be returned in a DHCPLEASEACTIVE message.
与DHCPBULKLEASEQUERY请求中的客户端标识符选项匹配的DHCPv4客户端当前绑定的每个IP地址必须在DHCPLEASEACTIVE消息中返回。
o Query by Remote ID
o 按远程ID查询
Every IP address that has a current binding to a DHCPv4 client matching the Remote ID sub-option of the relay-agent-information option in the DHCPBULKLEASEQUERY request MUST be returned in a DHCPLEASEACTIVE message.
与DHCPBULKLEASEQUERY请求中中继代理信息选项的远程ID子选项相匹配的DHCPv4客户端当前绑定的每个IP地址必须在DHCPLEASEACTIVE消息中返回。
o Query by Relay-ID
o 按中继ID查询
Every IP address that has a current binding to a DHCPv4 client matching the Relay-ID sub-option of the relay-agent-information option in the DHCPBULKLEASEQUERY request MUST be returned in a DHCPLEASEACTIVE message.
与DHCPBULKLEASEQUERY请求中中继代理信息选项的中继ID子选项相匹配的DHCPv4客户端当前绑定的每个IP地址必须在DHCPLEASEACTIVE消息中返回。
o Query for All Configured IP Addresses
o 查询所有配置的IP地址
A Query for All Configured IP addresses is signaled by the absence of any other primary query. That is, if there is no value in the chaddr, hlen, htype, no Client-identifier option, and no Remote ID sub-option or Relay-ID sub-option of the relay-agent-information option, then the request is a query for information concerning all configured IP addresses. In this case, every configured IP address that has a current binding to a DHCPv4 client MUST be returned in a DHCPLEASEACTIVE message. In addition, every configured IP address that does not have a current binding to a DHCPv4 client MUST be returned in a DHCPLEASEUNASSIGNED message.
如果没有任何其他主查询，则表示查询所有配置的IP地址。也就是说，如果chaddr、hlen、htype、no Client identifier选项和Relay agent information选项的non Remote ID sub选项或Relay ID sub选项中没有值，则请求是对所有配置的IP地址的信息的查询。在这种情况下，当前绑定到DHCPv4客户机的每个配置的IP地址都必须在DHCPLEASEACTIVE消息中返回。此外，必须在DHCPLEASEUNASSIGNED消息中返回当前未绑定到DHCPv4客户端的每个已配置IP地址。
In this form of query, each configured IP address MUST be returned at most one time. In the absence of qualifiers restricting the number of IP addresses returned, every configured IP address MUST be returned exactly once.
在这种形式的查询中，每个配置的IP地址最多只能返回一次。如果没有限制返回的IP地址数量的限定符，则每个配置的IP地址必须只返回一次。
There are three qualifiers that can be applied to any of the above primary queries. These qualifiers can appear individually or together in any combination, but only one of each can appear.
有三个限定符可应用于上述任何主要查询。这些限定符可以单独出现，也可以组合出现，但每个限定符只能出现一个。
o Query Start Time
o 查询开始时间
If a query-start-time option appears in the DHCPBULKLEASEQUERY request, only IP address bindings that have changed on or after the time specified in the query-start-time option should be returned.
如果DHCPBULKLEASEQUERY请求中出现查询开始时间选项，则只应返回在查询开始时间选项中指定的时间当天或之后更改的IP地址绑定。
o Query End Time
o 查询结束时间
If a query-end-time option appears in the DHCPBULKLEASEQUERY request, only IP address bindings that have changed on or before the time specified in the query-end-time option should be returned.
如果DHCPBULKLEASEQUERY请求中出现查询结束时间选项，则只应返回在查询结束时间选项中指定的时间当天或之前更改的IP地址绑定。
o VPN-ID
o VPN-ID
If no VPN-ID option appears in the DHCPBULKLEASEQUERY, the default (global) VPN is used to satisfy the query. A VPN-ID option [RFC6607] value other than the wildcard value (254) allows the requestor to specify a single VPN other than the default VPN. In addition, the VPN-ID option has been extended as part of this document to allow specification of a type 254, which indicates that all configured VPNs be searched in order to satisfy the primary query.
如果DHCPBULKLEASEQUERY中没有出现VPN-ID选项，则使用默认（全局）VPN来满足查询。通配符值（254）以外的VPN-ID选项[RFC6607]值允许请求者指定默认VPN以外的单个VPN。此外，VPN-ID选项已扩展为本文档的一部分，以允许指定类型254，该类型指示搜索所有配置的VPN以满足主查询。
In all cases, if the information returned in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message is for a VPN other than the default (global) VPN, a VPN-ID option MUST appear in the packet.
在所有情况下，如果DHCPLEASEACTIVE或DHCPLEASEUNASSIGNED消息中返回的信息针对的是默认（全局）VPN以外的VPN，则数据包中必须显示VPN-ID选项。
The query-start-time and query-end-time qualifiers are used to constrain the amount of data returned by a Bulk Leasequery request by returning only IP addresses whose address bindings have changed in some way during the time window specified by the query-start-time and query-end-time.
查询开始时间和查询结束时间限定符用于通过仅返回其地址绑定在查询开始时间和查询结束时间指定的时间窗口内以某种方式更改的IP地址来限制批量租赁请求返回的数据量。
A DHCPv4 server SHOULD consider an address binding to have changed during a specified time window if either the client-last-transaction-time or the start-time-of-state of the address binding changed during that time window.
DHCPv4服务器应该考虑地址绑定在指定的时间窗口内发生改变，如果客户机上次事务时间或地址绑定状态的起始时间在该时间窗口期间改变。
The DHCPv4 server MAY return address binding data in any order, as long as binding information for any given IP address is not repeated. When all binding data for a given DHCPBULKLEASEQUERY has been sent, the DHCPv4 server MUST send a DHCPBULKLEASEQUERYDONE message.
只要不重复任何给定IP地址的绑定信息，DHCPv4服务器可以按任何顺序返回地址绑定数据。发送给定DHCPBULKLEASEQUERY的所有绑定数据后，DHCPv4服务器必须发送DHCPBULKLEASEQUERYDONE消息。
The DHCPv4 Leasequery specification [RFC4388] describes the initial construction of DHCPLEASEQUERY reply messages using the DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types in Section 6.4.2. All of the reply messages in Bulk Leasequery are similar to the reply messages for an IP address query. Message transmission and framing for TCP are described in this document in Section 6.1.
DHCPv4租赁规范[RFC4388]描述了使用第6.4.2节中的DHCPLEASEACTIVE和DHCPLEASEUNASSIGNED消息类型的DHCPLEASEQUERY回复消息的初始构造。Bulk Leasequery中的所有回复消息类似于IP地址查询的回复消息。本文件第6.1节描述了TCP的消息传输和帧。
[RFC2131] and [RFC4388] specify that every response message MUST contain the server-identifier option. However, that option will be the same for every response from a particular DHCPBULKLEASEQUERY request. Thus, the DHCPv4 server MUST include the server-identifier option in the first message sent in response to a DHCPBULKLEASEQUERY. It SHOULD NOT include the server-identifier option in later messages.
[RFC2131]和[RFC4388]指定每个响应消息必须包含服务器标识符选项。但是，对于来自特定DHCPBULKLEASEQUERY请求的每个响应，该选项都是相同的。因此，DHCPv4服务器必须在响应DHCPBULKLEASEQUERY发送的第一条消息中包含服务器标识符选项。在以后的消息中不应包括服务器标识符选项。
The message type of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based on the value of the dhcp-state option. If the dhcp-state option value is ACTIVE, then the message type is DHCPLEASEACTIVE; otherwise, the message type is DHCPLEASEUNASSIGNED.
DHCPLEASEACTIVE或DHCPLEASEUNASSIGNED的消息类型基于dhcp状态选项的值。如果dhcp状态选项值为ACTIVE，则消息类型为DHCPLEASEACTIVE；否则，消息类型为未分配。
In addition to the basic message construction described in [RFC4388], the following guidelines exist:
除了[RFC4388]中描述的基本消息构造外，还存在以下准则：
1. If the dhcp-state option code appears in the dhcp-parameter-request-list, the DHCPv4 server SHOULD include a dhcp-state option whose value corresponds most closely to the state held by the DHCPv4 server for the IP address associated with this reply. If the state is ACTIVE and the message being returned is DHCPLEASEACTIVE, then the DHCPv4 server MAY choose to not send the dhcp-state option. The requestor SHOULD assume that any DHCPLEASEACTIVE message arriving without a requested dhcp-state option has a dhcp-state of ACTIVE.
1. 如果dhcp参数请求列表中出现dhcp状态选项代码，则DHCPv4服务器应包括一个dhcp状态选项，该选项的值与DHCPv4服务器为与此回复关联的IP地址保持的状态最为接近。如果状态为ACTIVE，并且返回的消息为DHCPLEASEACTIVE，则DHCPv4服务器可以选择不发送dhcp状态选项。请求者应假设在没有请求的dhcp状态选项的情况下到达的任何DHCPLEASEACTIVE消息的dhcp状态为ACTIVE。
2. If the base-time option code appears in the dhcp-parameter-request-list, the DHCPv4 server MUST include a base-time option, which is the current time in the DHCPv4 server's context and the time from which the start-time-of-state, dhcp-lease-time, client-last-transaction-time, and other duration-style times are based upon.
2. 如果基准时间选项代码出现在dhcp参数请求列表中，则DHCPv4服务器必须包含基准时间选项，该选项是DHCPv4服务器上下文中的当前时间，以及状态开始时间、dhcp租约时间、客户端上次事务时间和其他持续时间样式时间所基于的时间。
3. If the start-time-of-state option code appears in the dhcp-parameter-request-list, the DHCPv4 server MUST include a start-time-of-state option whose value represents the time at which the dhcp-state option's state became valid.
3. 如果状态开始时间选项代码出现在dhcp参数请求列表中，DHCPv4服务器必须包含状态开始时间选项，其值表示dhcp状态选项的状态生效的时间。
4. If the dhcp-lease-time option code appears in the dhcp-parameter-request-list, the DHCPv4 server MUST include a dhcp-lease-time option for any state that has a timeout value associated with it.
4. 如果dhcp租用时间选项代码出现在dhcp参数请求列表中，则DHCPv4服务器必须为任何具有相关超时值的状态包含dhcp租用时间选项。
5. If the data-source option code appears in the dhcp-parameter-request-list, the DHCPv4 server MUST include the data-source option in any situation where any of the bits would be non-zero. Thus, in the absence of the data-source option, the assumption is that all of the flags are zero.
5. 如果数据源选项代码出现在dhcp参数请求列表中，则DHCPv4服务器必须在任何位为非零的情况下包含数据源选项。因此，在没有数据源选项的情况下，假设所有标志都为零。
6. If the client-last-transaction-time option code appears in the dhcp-parameter-request-list, the DHCPv4 server MUST include the client-last-transaction-time option in any situation where the information is available.
6. 如果dhcp参数请求列表中出现客户机上次交易时间选项代码，则DHCPv4服务器必须在信息可用的任何情况下包含客户机上次交易时间选项。
7. If there is a dhcp-parameter-request-list in the initial DHCPBULKLEASEQUERY request, then it should be used for all of the replies generated by that request. Some options can be sent from a DHCPv4 client to the server or from the DHCPv4 server to a DHCPv4 client. Option 125 is such an option. If the option code for one of these options appears in the dhcp-parameter-request-list, it SHOULD result in returning the value of the option sent by the DHCPv4 client to the server if one exists.
7. 如果初始DHCPBULKLEASEQUERY请求中存在dhcp参数请求列表，则该列表应用于该请求生成的所有回复。一些选项可以从DHCPv4客户端发送到服务器，也可以从DHCPv4服务器发送到DHCPv4客户端。选择125就是这样一种选择。如果这些选项之一的选项代码出现在dhcp参数请求列表中，则应返回DHCPv4客户端发送到服务器的选项值（如果存在）。
Note that there may be other requirements for a reply to a DHCPBULKLEASEQUERY request, as discussed in Section 8.2.
请注意，如第8.2节所述，对DHCPBULKLEASEQUERY请求的回复可能还有其他要求。
As discussed in Section 7.3, requestors may want to use a connection that has already been established when they need to make additional queries. Servers SHOULD support reading and processing multiple queries from a single connection and SHOULD allow configuration of the number of simultaneous queries it may process. A server MUST NOT read more query messages from a connection than it is prepared to process simultaneously.
如第7.3节所述，请求者可能希望在需要进行其他查询时使用已经建立的连接。服务器应该支持从单个连接读取和处理多个查询，并且应该允许配置它可能处理的同时查询的数量。服务器从连接中读取的查询消息不能超过它准备同时处理的数量。
This SHOULD be a feature that is administratively controlled. Servers SHOULD offer configuration that limits the number of simultaneous queries permitted from any one requestor, in order to control resource use if there are multiple requestors seeking service.
这应该是一个受管理控制的功能。服务器应提供限制任何一个请求者允许的同时查询数量的配置，以便在有多个请求者寻求服务时控制资源使用。
The DHCPv4 server SHOULD close connections in a graceful manner and not abort the connection. The DHCPv4 server SHOULD NOT assume that the manner in which the requestor closed a connection carries any special meaning.
DHCPv4服务器应该以优雅的方式关闭连接，而不是中止连接。DHCPv4服务器不应假定请求者关闭连接的方式具有任何特殊意义。
Typically, the DHCPv4 server will only close the connection after some form of an exception or a timeout on the connection.
通常，DHCPv4服务器仅在连接出现某种形式的异常或超时后才会关闭连接。
Using a timer to detect when a connection is idle and then closing that connection is designed to protect the DHCPv4 server from consuming unnecessary resources.
使用计时器检测连接何时空闲，然后关闭该连接是为了保护DHCPv4服务器不消耗不必要的资源。
The DHCPv4 server should start a timer for BULK_LQ_DATA_TIMEOUT seconds for a particular connection after it sends a DHCPLEASEQUERYDONE message over that connection if there is no current query outstanding for that connection. It should restart this timer if a query arrives over that connection. If the timer expires, the DHCPv4 server should close the connection.
如果当前没有未完成的连接查询，则DHCPv4服务器应在通过该连接发送DHCPleaseQueryOne消息后，为特定连接的大容量数据超时秒启动计时器。如果查询通过该连接到达，它应该重新启动该计时器。如果计时器过期，DHCPv4服务器应关闭连接。
The server MUST close its end of the TCP connection if it encounters an error sending data on the connection. The server MUST close its end of the TCP connection if it finds that it has to abort an in-process request. A server aborting an in-process request SHOULD attempt to signal that to its requestors by using the QueryTerminated status code in the status-code option in a DHCPLEASEQUERYDONE message, including a message string indicating details of the reason for the abort. If the connection is closed for any reason, all of the data flows associated with any currently outstanding DHCPBULKLEASEQUERY messages will be terminated.
如果服务器在连接上发送数据时遇到错误，则必须关闭其TCP连接端。如果发现必须中止进程内请求，服务器必须关闭其TCP连接端。中止进程内请求的服务器应尝试通过在DHCPLeaseQueryOne消息的状态代码选项中使用QueryTerminated状态代码（包括指示中止原因的详细信息的消息字符串）向其请求者发送该信号。如果连接因任何原因关闭，则与任何当前未完成的DHCPBULKLEASEQUERY消息关联的所有数据流都将终止。
If the server detects that the requesting end of the connection has been closed, the server MUST close its end of the connection.
如果服务器检测到连接的请求端已关闭，则服务器必须关闭其连接端。
The Security Considerations section of [RFC2131] details the general threats to DHCPv4. The DHCPv4 Leasequery specification [RFC4388] describes recommendations for the Leasequery protocol, especially with regard to authentication of LEASEQUERY messages, mitigation of packet-flooding DoS attacks, and restriction to trusted requestors.
[RFC2131]的安全注意事项部分详细说明了DHCPv4面临的一般威胁。DHCPv4 Leasequery规范[RFC4388]描述了Leasequery协议的建议，特别是关于Leasequery消息的身份验证、数据包溢出DoS攻击的缓解以及对受信任请求者的限制。
The use of TCP introduces some additional concerns. Attacks that attempt to exhaust the DHCPv4 server's available TCP connection resources, such as SYN flooding attacks, can compromise the ability of legitimate requestors to receive service. Malicious requestors who succeed in establishing connections but who then send invalid
TCP的使用带来了一些额外的问题。试图耗尽DHCPv4服务器可用TCP连接资源的攻击，如SYN洪泛攻击，可能会损害合法请求者接收服务的能力。成功建立连接但随后发送无效消息的恶意请求者
queries, partial queries, or no queries at all can also exhaust a server's pool of available connections. We recommend that servers offer configuration to limit the sources of incoming connections, that they limit the number of accepted connections and the number of in-process queries from any one connection, and that they limit the period of time during which an idle connection will be left open.
查询、部分查询或根本不查询也会耗尽服务器的可用连接池。我们建议服务器提供限制传入连接源的配置，限制接受连接的数量和来自任何一个连接的进程内查询的数量，并限制空闲连接保持打开的时间段。
There are two specific issues regarding Bulk Leasequery security that deserve explicit mention. The first is preventing information that Bulk Leasequery can provide from reaching clients who are not authorized to receive such information. The second is ensuring that authorized clients of the Bulk Leasequery capability receive accurate information from the server (and that this information is not disrupted in transit).
有两个关于批量租赁安全的具体问题值得明确提及。第一是阻止批量租赁可以提供的信息到达未经授权接收此类信息的客户。第二是确保具有批量租赁功能的授权客户端从服务器接收到准确的信息（并且该信息在传输过程中不会中断）。
To prevent information leakage to unauthorized clients, servers SHOULD restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY messages to certain requestors, either through explicit configuration of the server itself or by employing external network elements to provide such restrictions. In particular, the typical DHCPv4 client SHOULD NOT be allowed to receive a response to a Bulk Leasequery request, and some technique MUST exist to allow prevention of such access in any environment where Bulk Leasequery is deployed.
为防止信息泄漏给未经授权的客户端，服务器应通过服务器本身的显式配置或通过使用外部网络元素提供此类限制，将批量Leasequery连接和DHCPBULKLEASEQUERY消息限制给某些请求者。特别是，不应允许典型的DHCPv4客户端接收对批量租赁请求的响应，并且必须存在一些技术，以允许在部署批量租赁的任何环境中防止此类访问。
Connections not from permitted requestors SHOULD be closed immediately to avoid server connection resource exhaustion or alternatively, simply not be allowed to reach the server at all. Servers SHOULD have the capability to restrict certain requestors to certain query types. Servers MAY reply to queries that are not permitted with the DHCPLEASEQUERYDONE message with a status-code option status of NotAllowed or MAY simply close the connection.
应该立即关闭来自不允许的请求者的连接，以避免服务器连接资源耗尽，或者干脆不允许访问服务器。服务器应该能够将某些请求者限制为某些查询类型。服务器可以使用状态代码选项status为NotAllowed来答复DHCPLeaseQueryOne消息不允许的查询，也可以简单地关闭连接。
To prevent disruption and malicious corruption of Bulk Leasequery data flows between the server and authorized clients, these data flows SHOULD transit only secured networks. These data flows are typically infrastructure oriented, and there is usually no reason to have them flowing over networks where such attacks are likely. In the rare cases where these data flows might need to be sent through unsecured networks, they MUST be sent over connections secured through means external to the DHCPv4/DHCPv6 server and its client(s) (e.g., through VPNs).
为防止服务器和授权客户端之间的批量租赁服务数据流中断和恶意损坏，这些数据流应仅传输安全网络。这些数据流通常面向基础设施，通常没有理由让它们在可能发生此类攻击的网络上流动。在极少数情况下，这些数据流可能需要通过不安全的网络发送，它们必须通过DHCPv4/DHCPv6服务器及其客户端外部的安全连接（例如，通过VPN）发送。
Authentication for DHCP messages [RFC3118] MUST NOT be used to attempt to secure transmission of the messages described in this document. In particular, the message framing would not be protected by using the mechanisms described in [RFC3118] (which was designed only with UDP transport in mind).
DHCP消息的身份验证[RFC3118]不得用于尝试安全传输本文档中描述的消息。特别是，使用[RFC3118]中描述的机制（仅考虑UDP传输）不会保护消息帧。
IANA has assigned the following new DHCPv4 option codes from the registry "BOOTP Vendor Extensions and DHCP Options" maintained at http://www.iana.org/assignments/bootp-dhcp-parameters.
IANA已从位于的注册表“BOOTP供应商扩展和DHCP选项”中分配了以下新的DHCPv4选项代码http://www.iana.org/assignments/bootp-dhcp-parameters.
1. An option code of 151 for status-code.
1. 状态代码的选项代码为151。
2. An option code of 152 for base-time.
2. 基准时间的选项代码为152。
3. An option code of 153 for start-time-of-state.
3. 状态开始时间的选项代码为153。
4. An option code of 154 for query-start-time.
4. 查询开始时间的选项代码为154。
5. An option code of 155 for query-end-time.
5. 查询结束时间的选项代码为155。
6. An option code of 156 for dhcp-state.
6. dhcp状态的选项代码为156。
7. An option code of 157 for data-source.
7. 数据源的选项代码为157。
IANA has assigned the following new DHCP message types from the registry "DHCP Message Type 53 Values" maintained at http://www.iana.org/assignments/bootp-dhcp-parameters.
IANA已从维护在的注册表“DHCP消息类型53值”中分配了以下新的DHCP消息类型http://www.iana.org/assignments/bootp-dhcp-parameters.
1. A dhcp-message-type of 14 for DHCPBULKLEASEQUERY.
1. DHCPBULKLEASEQUERY的dhcp消息类型为14。
2. A dhcp-message-type of 15 for DHCPLEASEQUERYDONE.
2. DHCPLeaseQueryOne的dhcp消息类型为15。
IANA has created a new registry on the same assignments page, titled "DHCP State 156 Values" (where 156 corresponds to the assigned value of the dhcp-state option above). This registry has the following initial values:
IANA在同一个分配页面上创建了一个新的注册表，标题为“DHCP状态156值”（其中156对应于上面DHCP状态选项的分配值）。此注册表具有以下初始值：
State
-----
1 AVAILABLE
2 ACTIVE
3 EXPIRED
4 RELEASED
5 ABANDONED
6 RESET
7 REMOTE
8 TRANSITIONING
State
-----
1 AVAILABLE
2 ACTIVE
3 EXPIRED
4 RELEASED
5 ABANDONED
6 RESET
7 REMOTE
8 TRANSITIONING
New values for this namespace may only be defined by IETF Review, as described in [RFC5226].
该名称空间的新值只能由IETF Review定义，如[RFC5226]所述。
IANA has created a new registry on the same assignments page, titled "DHCP Status Code 151 Values" (where 151 corresponds to the assigned value of the status-code option above). This registry has the following initial values:
IANA在同一个分配页面上创建了一个新的注册表，标题为“DHCP状态代码151值”（其中151对应于上述状态代码选项的分配值）。此注册表具有以下初始值：
Name status-code
---- -----------
Success 000
UnspecFail 001
QueryTerminated 002
MalformedQuery 003
NotAllowed 004
Name status-code
---- -----------
Success 000
UnspecFail 001
QueryTerminated 002
MalformedQuery 003
NotAllowed 004
New values for this namespace may only be defined by IETF Review, as described in [RFC5226].
该名称空间的新值只能由IETF Review定义，如[RFC5226]所述。
IANA has revised the registry "VSS Type Options" created by [RFC6607] in the overall area "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters". It has been revised to appear as follows. Note that the number range for "Unassigned" has changed, and a new line for "All VPNs (wildcard)" was added.
IANA修改了[RFC6607]在“动态主机配置协议（DHCP）和引导协议（BOOTP）参数”总区域中创建的注册表“VSS类型选项”。它已修订如下。请注意，“未分配”的数字范围已更改，并添加了“所有VPN（通配符）”的新行。
Type VSS Information Format
------------------------------------------------------------
0 Network Virtual Terminal (NVT) ASCII VPN identifier
1 RFC 2685 VPN-ID
2-253 Unassigned
254 All VPNs (wildcard)
255 Global, default VPN
Type VSS Information Format
------------------------------------------------------------
0 Network Virtual Terminal (NVT) ASCII VPN identifier
1 RFC 2685 VPN-ID
2-253 Unassigned
254 All VPNs (wildcard)
255 Global, default VPN
Significant text as well as important ideas were borrowed in whole or in part from "DHCPv6 Bulk Leasequery" [RFC5460], written by Mark Stapp. Further suggestions and improvements were made by participants in the DHC Working Group, including Alfred Hoenes.
重要的文本以及重要的思想全部或部分借用自Mark Stapp编写的“DHCPv6批量租赁”[RFC5460]。DHC工作组的参与者，包括Alfred Hoenes，提出了进一步的建议和改进。
[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月。
[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月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]Patrick，M.，“DHCP中继代理信息选项”，RFC3046，2001年1月。
[RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118]Droms，R.，Ed.，和W.Arbaugh，Ed.，“DHCP消息的身份验证”，RFC31182001年6月。
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RFC4388]Woundy，R.和K.Kinnear，“动态主机配置协议（DHCP）租赁”，RFC 4388，2006年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]Cotton，M.和L.Vegoda，“特殊用途IPv4地址”，BCP 153，RFC 57352010年1月。
[RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet Selection Options for DHCPv4 and DHCPv6", RFC 6607, April 2012.
[RFC6607]Kinnear，K.，Johnson，R.，和M.Stapp，“DHCPv4和DHCPv6的虚拟子网选择选项”，RFC 6607，2012年4月。
[RFC6925] Joshi, B., Desetti, R., and M. Stapp, "The DHCPv4 Relay Agent Identifier Sub-Option", RFC 6925, April 2013.
[RFC6925]Joshi，B.，Desetti，R.，和M.Stapp，“DHCPv4中继代理标识符子选项”，RFC 69252013年4月。
[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月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614]Duke，M.，Braden，R.，Eddy，W.，和E.Blanton，“传输控制协议（TCP）规范文件路线图”，RFC 46142006年9月。
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 2009.
[RFC5460]Stapp，M.，“DHCPv6散装租赁”，RFC 54602009年2月。
Authors' Addresses
作者地址
Kim Kinnear Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, Massachusetts 01719 USA
Kim Kinnear Cisco Systems，Inc.美国马萨诸塞州Boxborough马萨诸塞大道1414号，邮编01719
Phone: (978) 936-0000 EMail: kkinnear@cisco.com
电话：（978）936-0000电子邮件：kkinnear@cisco.com
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, Massachusetts 01719 USA
Mark Stapp Cisco Systems，Inc.美国马萨诸塞州Boxborough马萨诸塞大道1414号，邮编01719
Phone: (978) 936-0000 EMail: mjs@cisco.com
电话：（978）936-0000电子邮件：mjs@cisco.com
D.T.V Ramakrishna Rao Infosys Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India
印度班加罗尔霍苏尔路电子城44号D.T.V罗摩克里希纳·拉奥信息系统有限公司560 100
EMail: ramakrishnadtv@infosys.com
URI: http://www.infosys.com/
EMail: ramakrishnadtv@infosys.com
URI: http://www.infosys.com/
Bharat Joshi Infosys Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India
印度班加罗尔霍苏尔路电子城44号Bharat Joshi Infosys Ltd.560 100
EMail: bharat_joshi@infosys.com
URI: http://www.infosys.com/
EMail: bharat_joshi@infosys.com
URI: http://www.infosys.com/
Neil Russell Sea Street Technologies Inc.
尼尔·拉塞尔海洋街科技公司。
EMail: neil.e.russell@gmail.com
EMail: neil.e.russell@gmail.com
Pavan Kurapati Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号帕万·库拉帕蒂Juniper Networks，邮编94089
EMail: kurapati@juniper.net
URI: http://www.juniper.net/
EMail: kurapati@juniper.net
URI: http://www.juniper.net/
Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, Massachusetts 01719 USA
Bernie Volz Cisco Systems，Inc.美国马萨诸塞州Boxborough马萨诸塞大道1414号，邮编01719
Phone: (978) 936-0000 EMail: volz@cisco.com
电话：（978）936-0000电子邮件：volz@cisco.com