Internet Engineering Task Force (IETF) K. Kinnear
Request for Comments: 7724 M. Stapp
Updates: 6926 B. Volz
Category: Standards Track Cisco Systems
ISSN: 2070-1721 N. Russell
Staples
December 2015
Internet Engineering Task Force (IETF) K. Kinnear
Request for Comments: 7724 M. Stapp
Updates: 6926 B. Volz
Category: Standards Track Cisco Systems
ISSN: 2070-1721 N. Russell
Staples
December 2015
Active DHCPv4 Lease Query
活动DHCPv4租赁查询
Abstract
摘要
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings (RFC 4388). That mechanism is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient, or even possible. In addition, continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 binding information data via TCP. This document updates RFC 6926, "DHCPv4 Bulk Leasequery".
IPv4的动态主机配置协议（DHCPv4）已通过一个允许请求者请求有关DHCPv4绑定的信息的Leasequery功能进行了扩展（RFC 4388）。该机制仅限于查询单个绑定。在某些情况下，单个绑定查询可能没有效率，甚至不可能。此外，有时需要使用Leasequery数据持续更新外部请求者。本文档扩展了DHCPv4 Leasequery协议，并允许通过TCP主动传输接近实时的DHCPv4绑定信息数据。本文件更新了RFC 6926“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/rfc7724.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7724.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. Interaction Between Active Leasequery and Bulk Leasequery . . 8
5. Message and Option Definitions . . . . . . . . . . . . . . . 9
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 9
5.2. New or Changed Options . . . . . . . . . . . . . . . . . 9
5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 10
5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 10
5.3. Connection and Transmission Parameters . . . . . . . . . 11
6. Information Communicated by Active Leasequery . . . . . . . . 11
7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 12
7.1. General Processing . . . . . . . . . . . . . . . . . . . 12
7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 13
7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 14
7.4. Processing Active Replies . . . . . . . . . . . . . . . . 15
7.4.1. Processing Replies from a Request Containing a
query-start-time . . . . . . . . . . . . . . . . . . 17
7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 19
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 19
8.1.1. Update to RFC 6926 . . . . . . . . . . . . . . . . . 21
8.2. Replying to an Active Leasequery . . . . . . . . . . . . 21
8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 23
8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. Interaction Between Active Leasequery and Bulk Leasequery . . 8
5. Message and Option Definitions . . . . . . . . . . . . . . . 9
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 9
5.2. New or Changed Options . . . . . . . . . . . . . . . . . 9
5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 10
5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 10
5.3. Connection and Transmission Parameters . . . . . . . . . 11
6. Information Communicated by Active Leasequery . . . . . . . . 11
7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 12
7.1. General Processing . . . . . . . . . . . . . . . . . . . 12
7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 13
7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 14
7.4. Processing Active Replies . . . . . . . . . . . . . . . . 15
7.4.1. Processing Replies from a Request Containing a
query-start-time . . . . . . . . . . . . . . . . . . 17
7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 19
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 19
8.1.1. Update to RFC 6926 . . . . . . . . . . . . . . . . . 21
8.2. Replying to an Active Leasequery . . . . . . . . . . . . 21
8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 23
8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 capability [RFC2131] [RFC2132] to allow an external entity to query a DHCPv4 server to recover lease state information about a particular IPv4 address or client in near real-time.
DHCPv4租赁功能[RFC4388]扩展了DHCPv4的基本功能[RFC2131][RFC2132]，允许外部实体查询DHCPv4服务器，以近乎实时地恢复有关特定IPv4地址或客户端的租赁状态信息。
Continuous update of an external requestor with Leasequery data is sometimes desired. These requestors need to keep up with the current binding activity of the DHCPv4 server. Keeping up with these binding activities is termed "active" leasequery.
有时需要使用Leasequery数据持续更新外部请求者。这些请求者需要跟上DHCPv4服务器当前的绑定活动。跟上这些结合活动被称为“主动”租赁。
The DHCPv4 Bulk Leasequery [RFC6926] capability can be used to recover useful information from a DHCPv4 server when some external entity starts up. This entity could be one that is directly involved in the DHCPv4 client-server transactions (e.g., a relay agent), or it could be an external process that needs information present in the DHCPv4 server's lease state database.
当某些外部实体启动时，DHCPv4批量租赁[RFC6926]功能可用于从DHCPv4服务器恢复有用信息。该实体可以是直接参与DHCPv4客户机-服务器事务的实体（例如，中继代理），也可以是需要DHCPv4服务器租赁状态数据库中提供信息的外部进程。
The Active Leasequery capability documented here is designed to allow an entity not directly involved in DHCPv4 client-server transactions to nevertheless keep current with the state of the DHCPv4 lease state information in real-time.
此处记录的主动租赁功能旨在允许未直接参与DHCPv4客户机-服务器事务的实体实时保持DHCPv4租赁状态信息的最新状态。
This document updates DHCPv4 Bulk Leasequery [RFC6926] in that it specifies the DHCPv4 server must close the TCP connection if it receives a DHCPv4 message that is not allowed over the TCP connection (for example, DHCPDISCOVER, DHCPLEASEQUERY). See Section 8.1.1.
本文档更新了DHCPv4批量租赁请求[RFC6926]，因为它指定如果DHCPv4服务器接收到TCP连接上不允许的DHCPv4消息（例如，DHCPDISCOVER、DHCPLASEQUERY），则必须关闭TCP连接。见第8.1.1节。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses the following terms:
本文件使用以下术语：
o "Active Leasequery"
o “主动租赁”
Keeping up to date in real-time (or near real-time) with DHCPv4 binding activity.
通过DHCPv4绑定活动实时（或接近实时）更新。
o "binding"
o “绑定”
The information that a DHCPv4 server keeps regarding the relationship between a DHCPv4 client and an IPv4 address. This includes the identity of the DHCPv4 client and the expiration time, if any, of any lease that client has on a particular IPv4 address.
DHCPv4服务器保存的有关DHCPv4客户端和IPv4地址之间关系的信息。这包括DHCPv4客户端的标识以及该客户端在特定IPv4地址上的任何租约的到期时间（如果有）。
o "Bulk Leasequery"
o “批量租赁”
Requesting and receiving the information about all or some of the existing DHCPv4 binding information in an efficient manner, as defined by [RFC6926].
按照[RFC6926]的定义，以高效的方式请求和接收关于所有或部分现有DHCPv4绑定信息的信息。
o "blocked TCP connection"
o “被阻止的TCP连接”
A TCP connection is considered blocked if the underlying TCP transport will not accept new messages to be sent without blocking the thread that is attempting to send the message.
如果底层TCP传输在不阻止试图发送消息的线程的情况下不接受要发送的新消息，则认为TCP连接已被阻止。
o "catch-up information"
o “追赶信息”
If a DHCPv4 Active Leasequery requestor sends in a query-start-time option in a DHCPACTIVELEASEQUERY message, the DHCPv4 server will attempt to send the requestor the information that changed since the time specified in the query-start-time option. The binding information sent to satisfy this request is the catch-up information.
如果DHCPv4 Active Leasequery请求者在DHCPACTIVELEASEQUERY消息中发送查询开始时间选项，则DHCPv4服务器将尝试向请求者发送自查询开始时间选项中指定的时间以来更改的信息。为满足此请求而发送的绑定信息是追赶信息。
o "catch-up phase"
o “追赶阶段”
The period while the catch-up information is being sent is the catch-up phase.
发送追赶信息的时间段是追赶阶段。
o "clock skew"
o “时钟偏移”
The difference between the absolute time on a DHCPv4 server and the absolute time on the system where a requestor of an Active or Bulk Leasequery is executing is termed the "clock skew" for that Active or Bulk Leasequery connection. It is not absolutely constant but is likely to vary only slowly. While it is easy to think that this can be calculated precisely after one packet is received by a requestor from a DHCPv4 server, a more accurate value is derived from continuously examining the instantaneous value developed from each packet received from a DHCPv4 server and using it to make small adjustments to the existing value held in the requestor.
DHCPv4服务器上的绝对时间与系统上活动或批量租赁请求者正在执行的绝对时间之间的差异称为该活动或批量租赁连接的“时钟偏移”。它不是绝对恒定的，但可能只是缓慢地变化。虽然很容易认为这可以在请求者从DHCPv4服务器接收到一个数据包后精确计算，通过不断检查从DHCPv4服务器接收到的每个数据包产生的瞬时值，并使用它对请求程序中的现有值进行微小调整，可以得出更准确的值。
o "DHCPv4 client"
o “DHCPv4客户端”
A DHCPv4 client is an IPv4 node using DHCP to obtain configuration parameters such as a network address.
DHCPv4客户端是使用DHCP获取配置参数（如网络地址）的IPv4节点。
o "DHCPv4 relay agent"
o “DHCPv4中继代理”
A DHCPv4 relay agent is a third-party agent that transfers BOOTP and DHCPv4 messages between clients and servers residing on different subnets, per [RFC951] and [RFC1542].
DHCPv4中继代理是第三方代理，根据[RFC951]和[RFC1542]，在驻留在不同子网上的客户端和服务器之间传输BOOTP和DHCPv4消息。
o "DHCPv4 server"
o “DHCPv4服务器”
A DHCPv4 server is an IPv4 node that returns configuration parameters to DHCPv4 clients.
DHCPv4服务器是向DHCPv4客户端返回配置参数的IPv4节点。
o "insecure mode"
o “不安全模式”
When operating in insecure mode, the TCP connection between the requestor and DHCPv4 server is not protected in any way. In addition, the identity of the requestor is not validated by the server nor is the identity of the server validated by the requestor.
在不安全模式下操作时，请求程序和DHCPv4服务器之间的TCP连接不受任何保护。此外，服务器不会验证请求者的身份，请求者也不会验证服务器的身份。
o "MAC address"
o “MAC地址”
In the context of a DHCP message, a Media Access Control (MAC) address consists of the fields: hardware type "htype", hardware length "hlen", and client hardware address "chaddr".
在DHCP消息的上下文中，媒体访问控制（MAC）地址由以下字段组成：硬件类型“htype”、硬件长度“hlen”和客户端硬件地址“chaddr”。
o "requestor"
o “请求者”
The node that sends LEASEQUERY messages to one or more servers to retrieve information on the bindings for a client.
向一个或多个服务器发送LEASEQUERY消息以检索客户端绑定信息的节点。
o "secure mode"
o “安全模式”
When operating in secure mode, the TCP connection between the requestor and the DHCPv4 server is protected by TLS [RFC5246]. In addition, the requestor uses the certificates exchanged between it and the DHCPv4 server while setting up the TLS connection to validate the identity of the server. The DHCPv4 server also uses these certificates to validate the identity of the requestor.
在安全模式下运行时，请求程序和DHCPv4服务器之间的TCP连接受TLS[RFC5246]保护。此外，请求者在设置TLS连接以验证服务器身份时，使用它与DHCPv4服务器之间交换的证书。DHCPv4服务器还使用这些证书来验证请求者的身份。
The Active Leasequery mechanism is modeled on the existing individual Leasequery protocol in [RFC4388] as well as related work on DHCPv4 Bulk Leasequery [RFC6926]; most differences arise from the long-term nature of the TCP [RFC7414] connection required for Active Leasequery. In addition, a DHCPv4 server that supports Active Leasequery must support Bulk Leasequery [RFC6926] as well. See Section 8.
主动租赁机制基于[RFC4388]中现有的单独租赁协议以及DHCPv4批量租赁[RFC6926]的相关工作进行建模；大多数差异源于主动租赁所需的TCP[RFC7414]连接的长期性质。此外，支持活动租赁的DHCPv4服务器还必须支持批量租赁[RFC6926]。见第8节。
An Active Leasequery requestor opens a TCP connection to a DHCPv4 Server, using the DHCPv4 port 67. Note that this implies that the Leasequery requestor has the server IPv4 address(es) available via configuration or some other means, and that it has unicast IP
活动的租赁请求者使用DHCPv4端口67打开到DHCPv4服务器的TCP连接。请注意，这意味着Leasequery请求者通过配置或某些其他方式具有可用的服务器IPv4地址，并且它具有单播IP
reachability to the DHCPv4 server. The message framing for TCP is discussed in Section 5.1. No relaying for Active Leasequery is specified.
可访问DHCPv4服务器。第5.1节讨论了TCP的消息帧。未指定活动租赁的中继。
After establishing a connection, the requestor sends an DHCPACTIVELEASEQUERY message over the connection. In response, the server sends updates to the requestor using DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages that are extensions of these messages as defined in [RFC4388] and [RFC6926]. This response procedure is similar to the procedure specified in [RFC6926], except that in the case of Active Leasequery the server sends updates whenever some activity occurs to change the binding state -- thus the need for the long-lived connection. Additionally, the Active Leasequery server should provide a mechanism to control which data is allowed to be included in the messages sent to the requestor. See Section 8.2.
建立连接后，请求者通过该连接发送一条DHCPActivableAseQuery消息。作为响应，服务器使用DHCPLEASEACTIVE和DHCPLEASEUNASSIGNED消息向请求者发送更新，DHCPLEASEUNASSIGNED消息是[RFC4388]和[RFC6926]中定义的这些消息的扩展。此响应过程类似于[RFC6926]中指定的过程，不同之处在于，在活动的Leasequery中，每当发生某些活动以更改绑定状态时，服务器都会发送更新，因此需要长时间的连接。此外，活动的Leasequery服务器应该提供一种机制来控制哪些数据被允许包含在发送给请求者的消息中。见第8.2节。
Since [RFC6926] did not specify what to do with an unknown message type received over the DHCP TCP connection, system administrators SHOULD NOT allow a DHCPACTIVELEASEQUERY message to be sent over a DHCP TCP connection to a DHCPv4 server that does not support Active Leasequery.
由于[RFC6926]未指定如何处理通过DHCP TCP连接接收到的未知消息类型，因此系统管理员不应允许通过DHCP TCP连接将DHCPACTIVELEASEQUERY消息发送到不支持Active Leasequery的DHCPv4服务器。
Active Leasequery is designed to provide continuous updates of DHCPv4 binding activity to an external entity.
Active Leasequery旨在向外部实体提供DHCPv4绑定活动的持续更新。
Active Leasequery has features that allow this external entity to lose its connection and then reconnect and receive the latest information concerning any IPv4 bindings changed while it was not connected.
Active Leasequery具有允许此外部实体断开连接，然后重新连接并接收有关未连接时更改的任何IPv4绑定的最新信息的功能。
These capabilities are designed to allow the Active Leasequery requestor to efficiently become current with respect to the lease state database after it has been restarted or the machine on which it is running has been reinitialized. It is easy to define a protocol that works when the requestor is always connected to the DHCPv4 server. Since that isn't sufficiently robust, much of the mechanism in this document is designed to deal efficiently with situations that occur when the Active Leasequery requestor becomes disconnected from the DHCPv4 server from which it is receiving updates and then becomes reconnected to that server.
这些功能旨在允许活动租赁请求者在重新启动租赁状态数据库或运行租赁状态数据库的计算机重新初始化后，有效地更新租赁状态数据库。当请求者始终连接到DHCPv4服务器时，很容易定义一个工作的协议。由于这还不够健壮，本文档中的许多机制旨在有效地处理活动租赁请求者与DHCPv4服务器断开连接并重新连接到该服务器时发生的情况。
Central to this approach is the concept that, if the Active Leasequery requestor loses service, it is allowed to specify the time of its most recent update in a subsequent Active Leasequery request, and the DHCPv4 server will determine whether or not data was missed while the Active Leasequery requestor was not connected.
该方法的核心概念是，如果活动租赁请求者失去服务，允许其在后续活动租赁请求中指定其最新更新的时间，DHCPv4服务器将确定活动租赁请求者未连接时是否丢失数据。
The DHCP server processing the Active Leasequery request MAY limit the amount of data saved, and methods exist for the DHCPv4 server to inform the Active Leasequery requestor that more data was missed than could be saved. In this situation, the Active Leasequery requestor would issue a Bulk Leasequery [RFC6926] to recover information not available through an Active Leasequery.
处理活动租赁请求的DHCP服务器可能会限制保存的数据量，并且DHCPv4服务器有方法通知活动租赁请求者丢失的数据超过了可以保存的数据量。在这种情况下，活动租赁请求者将发出批量租赁请求[RFC6926]，以恢复无法通过活动租赁请求获得的信息。
DHCPv4 servers are not required to keep any data corresponding to data missed on an Active Leasequery connection, but will typically choose to keep data corresponding to some recent activity available for subsequent queries by a DHCPv4 Active Leasequery requestor whose connection was temporarily interrupted.
DHCPv4服务器不需要保留与活动租赁连接上丢失的数据相对应的任何数据，但通常会选择保留与某些最近活动相对应的数据，以供连接暂时中断的DHCPv4活动租赁请求者进行后续查询。
An Active Leasequery requestor would typically use Bulk Leasequery to initialize its database with all current data when that database contains no binding information. In addition, it would use Bulk Leasequery to recover missed information in the event that its connection with the DHCPv4 server was lost for a longer time than the DHCPv4 server would keep track of the specific changes to the IPv4 binding information.
当数据库不包含绑定信息时，活动的Leasequery请求者通常会使用Bulk Leasequery以所有当前数据初始化其数据库。此外，如果与DHCPv4服务器的连接丢失的时间比DHCPv4服务器跟踪IPv4绑定信息的特定更改的时间长，则它将使用Bulk Leasequery恢复丢失的信息。
The messages sent by the server in response to an Active Leasequery request should be identical to the messages sent by the server to a Bulk Leasequery request regarding the way the data is encoded into the Active Leasequery responses. In addition, the actions taken by the Active Leasequery requestor to interpret the responses to an Active Leasequery request should be identical to the way that the requestor interprets the responses to a Bulk Leasequery request. Thus, the handling of time, clock skew, data source, and other items discussed in the Bulk Leasequery specification [RFC6926] are to be followed when implementing Active Leasequery, with the exception that a server responding to an Active Leasequery request SHOULD be able to be configured to prevent specific data items from being included in the response to the requestor even if they were requested by inclusion in the dhcp-parameter-request-list option.
服务器为响应活动租赁请求而发送的消息应与服务器为批量租赁请求发送的关于数据编码到活动租赁响应中的方式的消息相同。此外，主动租赁请求者为解释对主动租赁请求的响应而采取的行动应与请求者解释对批量租赁请求的响应的方式相同。因此，在实施主动租赁时，应遵循批量租赁规范[RFC6926]中讨论的时间、时钟偏差、数据源和其他项目的处理，例外情况是，响应活动租赁请求的服务器应能够配置为防止特定数据项包含在对请求者的响应中，即使这些数据项是通过包含在dhcp参数请求列表选项中请求的。
Active Leasequery is an extension of the Bulk Leasequery protocol [RFC6926]. The contents of messages returned to an Active Leasequery requestor are identical to those defined for the Bulk Leasequery protocol.
主动租赁是批量租赁协议[RFC6926]的扩展。返回给活动租赁请求者的消息内容与为批量租赁协议定义的内容相同。
Applications that employ Active Leasequery to keep a database up to date with respect to the DHCPv4 server's lease state database should use an initial Bulk Leasequery to bring their database into
使用Active Leasequery使数据库与DHCPv4服务器的租约状态数据库保持最新的应用程序应使用初始批量租约将其数据库带入
equivalence with that of the DHCPv4 server, and then use Active Leasequery to keep that database current with respect to the DHCPv4 server's lease state database.
与DHCPv4服务器的租约状态等效，然后使用Active Leasequery使该数据库相对于DHCPv4服务器的租约状态数据库保持最新。
There are several differences between the Active and Bulk Leasequery protocols. Active Leasequery defines only one qualifier (the query-start-time) and no query types, while Bulk Leasequery defines several query types and qualifiers. An Active Leasequery connection sends all available updates to the requestor.
主动租赁协议和批量租赁协议之间存在一些差异。Active Leasequery仅定义一个限定符（查询开始时间）而不定义查询类型，而Bulk Leasequery定义了多个查询类型和限定符。活动的Leasequery连接将所有可用更新发送给请求者。
An Active Leasequery connection does not ever "complete", though the DHCPv4 server can close the connection for a variety of reasons associated with some sort of exception condition.
活动的Leasequery连接永远不会“完成”，尽管DHCPv4服务器可能会由于与某种异常情况相关的各种原因关闭连接。
The use of TCP for the Active Leasequery protocol permits one or more DHCPv4 messages to be sent in response to a single Active Leasequery request. The receiver needs to be able to determine how large each message is. The same framing technique used for Bulk Leasequery [RFC6926] is used for Active Leasequery.
主动租赁协议使用TCP允许发送一条或多条DHCPv4消息以响应单个主动租赁请求。接收者需要能够确定每条消息的大小。用于批量租赁[RFC6926]的相同成帧技术也用于主动租赁。
When using TLS to secure a connection [RFC5246], the message framing for TLS uses the same format as that used for TCP. One DHCP message is carried in one TLS record.
使用TLS保护连接[RFC5246]时，TLS的消息帧使用与TCP相同的格式。在一个TLS记录中携带一条DHCP消息。
The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are used as the value of the dhcp-message-type option to indicate an IPv4 address that is currently not leased or is currently leased to a DHCPv4 client, respectively.
现有消息DHCPLEASEUNASSIGNED和DHCPLEASEACTIVE用作dhcp消息类型选项的值，分别表示当前未租用或租用给DHCPv4客户端的IPv4地址。
All of the message types and options defined for Bulk Leasequery [RFC6926] are also used by Active Leasequery. In addition, new message types and option types are defined for Active Leasequery, as described below.
为批量租赁[RFC6926]定义的所有消息类型和选项也由活动租赁使用。此外，还为活动租赁服务定义了新的消息类型和选项类型，如下所述。
The message type option (option 53) from [RFC2132] requires additional values. The values of these message types are shown below in an extension of the table from Section 9.6 of [RFC2132]:
[RFC2132]中的消息类型选项（选项53）需要附加值。这些消息类型的值在[RFC2132]第9.6节表格的扩展部分中显示如下：
+-------+----------------------+
| Value | Message Type |
+-------+----------------------+
| 16 | DHCPACTIVELEASEQUERY |
| 17 | DHCPLEASEQUERYSTATUS |
| 18 | DHCPTLS |
+-------+----------------------+
+-------+----------------------+
| Value | Message Type |
+-------+----------------------+
| 16 | DHCPACTIVELEASEQUERY |
| 17 | DHCPLEASEQUERYSTATUS |
| 18 | DHCPTLS |
+-------+----------------------+
The dhcp-status-code option defined in [RFC6926] allows greater detail to be returned regarding the status of a DHCP request. While specified in the Bulk Leasequery document, this DHCPv4 option is also used in Active Leasequery.
[RFC6926]中定义的dhcp状态代码选项允许返回有关dhcp请求状态的更详细信息。虽然在批量租赁文档中指定，但此DHCPv4选项也在活动租赁中使用。
This option has two possible scopes when used with Active 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, DHCPLEASEUNASSIGNED, or DHCPTLS. It refers to the message stream related to an entire request if the value of the dhcp-message-type is DHCPLEASEQUERYSTATUS.
此选项与Active Leasequery一起使用时有两个可能的作用域，具体取决于它出现的上下文。如果dhcp消息类型的值为DHCPLEASEACTIVE、DHCPLEASEUNASSIGNED或DHCPTLS，则它是指单个leasequery回复中的信息。如果dhcp消息类型的值为DHCPLEASEQUERYSTATUS，则它是指与整个请求相关的消息流。
Additional status codes defined for support of Active Leasequery are:
为支持活动租赁而定义的其他状态代码包括：
+----------------------+-------------+------------------------------+
| Name | Status-Code | Description |
+----------------------+-------------+------------------------------+
| DataMissing | 5 | Indicates that IPv4 binding |
| | | information requested is not |
| | | available. |
| ConnectionActive | 6 | Indicates that this |
| | | connection remains active. |
| CatchUpComplete | 7 | Indicates that this Active |
| | | Leasequery connection has |
| | | completed sending all of the |
| | | saved data requested. |
| TLSConnectionRefused | 8 | Indicates that a TLS |
| | | connection is not allowed. |
+----------------------+-------------+------------------------------+
+----------------------+-------------+------------------------------+
| Name | Status-Code | Description |
+----------------------+-------------+------------------------------+
| DataMissing | 5 | Indicates that IPv4 binding |
| | | information requested is not |
| | | available. |
| ConnectionActive | 6 | Indicates that this |
| | | connection remains active. |
| CatchUpComplete | 7 | Indicates that this Active |
| | | Leasequery connection has |
| | | completed sending all of the |
| | | saved data requested. |
| TLSConnectionRefused | 8 | Indicates that a TLS |
| | | connection is not allowed. |
+----------------------+-------------+------------------------------+
A dhcp-status-code option MAY appear in the options field of a DHCP message. If the dhcp-status-code option does not appear, it is assumed that the operation was successful. The dhcp-status-code option SHOULD NOT appear in a message that is successful unless it is needed to convey some text message along with the Success status code.
dhcp状态代码选项可能出现在dhcp消息的选项字段中。如果未显示dhcp状态代码选项，则假定操作成功。dhcp状态代码选项不应出现在成功的消息中，除非需要它与成功状态代码一起传递一些文本消息。
Active Leasequery uses the same port configuration as DHCPv4 Bulk Leasequery [RFC6926]. It also uses other transmission parameters (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC6926].
主动租赁使用与DHCPv4批量租赁相同的端口配置[RFC6926]。它还使用[RFC6926]中定义的其他传输参数（大容量数据超时和大容量最大连接）。
This section presents a table of values used to control Active 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 SHOULD NOT be used.
本节介绍用于控制活动租赁行为的值表，包括建议的默认值。实现可以使这些值可配置。但是，配置太小的超时值可能会导致此应用程序以及网络中的其他流量出现有害行为。因此，不应使用小于默认值的超时值。
+------------------------+---------+-------------------------------+
| Parameter | Default | Description |
+------------------------+---------+-------------------------------+
| ACTIVE_LQ_RCV_TIMEOUT | 120 s | Active Leasequery receive |
| | | timeout |
| ACTIVE_LQ_SEND_TIMEOUT | 120 s | Active Leasequery send |
| | | timeout |
| ACTIVE_LQ_IDLE_TIMEOUT | 60 s | Active Leasequery idle |
| | | timeout |
+------------------------+---------+-------------------------------+
+------------------------+---------+-------------------------------+
| Parameter | Default | Description |
+------------------------+---------+-------------------------------+
| ACTIVE_LQ_RCV_TIMEOUT | 120 s | Active Leasequery receive |
| | | timeout |
| ACTIVE_LQ_SEND_TIMEOUT | 120 s | Active Leasequery send |
| | | timeout |
| ACTIVE_LQ_IDLE_TIMEOUT | 60 s | Active Leasequery idle |
| | | timeout |
+------------------------+---------+-------------------------------+
While the information communicated by a Bulk Leasequery [RFC6926] is taken directly from the DHCPv4 server's lease state database, the information communicated by an Active Leasequery is real-time information. As such, it is the information that is currently associated with a particular binding in the DHCPv4 server's lease state database.
虽然批量租赁[RFC6926]传递的信息直接取自DHCPv4服务器的租赁状态数据库，但活动租赁所传递的信息是实时信息。因此，它是当前与DHCPv4服务器的租约状态数据库中的特定绑定关联的信息。
This is of significance, because if the Active Leasequery requestor runs slowly or the requestor disconnects from the DHCPv4 server and then reconnects with a query-start-time (signaling a catch-up operation), the information communicated to the Active Leasequery requestor is only the most current information from the DHCPv4 server's lease state database.
这很重要，因为如果活动的Leasequery请求程序运行缓慢，或者请求程序与DHCPv4服务器断开连接，然后在查询开始时重新连接（发出追赶操作的信号），传递给活动租赁请求者的信息只是DHCPv4服务器租赁状态数据库中的最新信息。
The requestor of an Active Leasequery MUST NOT assume that every lease state change is communicated across an Active Leasequery connection. Even if the Active Leasequery requestor remains connected, the DHCPv4 server is only required to transmit information about a binding that is current when the packet is created and handed off to the TCP stack to send to the requestor.
活动租赁请求者不得假设每个租赁状态更改都通过活动租赁连接进行通信。即使活动的Leasequery请求者保持连接，DHCPv4服务器也只需要在创建数据包并将其传递到TCP堆栈以发送给请求者时传输当前绑定的信息。
If the TCP connection blocks and the DHCPv4 server is waiting to send information down the connection, when the connection becomes available to be written, the DHCPv4 server MAY create the packet to send at this time. The current state of the binding will be sent, and any transition in state or other information that occurred while the TCP connection was blocked will be lost.
如果TCP连接阻塞，并且DHCPv4服务器正在等待沿连接发送信息，则当连接可供写入时，DHCPv4服务器可能会创建此时要发送的数据包。将发送绑定的当前状态，并且在TCP连接被阻止时发生的任何状态转换或其他信息都将丢失。
Thus, the Active Leasequery protocol does not allow the requestor to build a complete history of every activity on every lease. An effective history of the important state changes for a lease can be created if the parameters of the DHCPv4 server are tuned to take into account the requirements of an Active Leasequery requestor. For instance, the period after the expiration or release of a binding could be configured long enough (say, several minutes, well more than the receive timeout), so that an Active Leasequery requestor would never miss any changes in the binding.
因此，主动租赁协议不允许请求者建立每个租赁上每个活动的完整历史记录。如果调整DHCPv4服务器的参数以考虑活动租赁请求者的要求，则可以创建租赁的重要状态更改的有效历史记录。例如，可以将绑定过期或释放后的时间段配置为足够长（例如，几分钟，远远超过接收超时），以便活动的Leasequery请求者永远不会错过绑定中的任何更改。
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. Retries should not be more frequent than one every ACTIVE_LQ_IDLE_TIMEOUT. See Section 5.3.
请求者试图建立到DHCPv4服务器的TCP连接，以启动请求交换。如果尝试失败，请求者可以重试。重试次数不应超过每活动\u LQ\u空闲\u超时一次。见第5.3节。
If an Active Leasequery is terminated prematurely by a DHCPLEASEQUERYDONE with a dhcp-message 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. Retries should not be more frequent than one every ACTIVE_LQ_IDLE_TIMEOUT. See Section 5.3.
如果活动租赁被dhcp消息状态代码为QueryTerminated的DHCPLeaseQueryOne提前终止，或者被提交的连接失败提前终止，请求者可以在创建新连接后重试请求。重试次数不应超过每活动\u LQ\u空闲\u超时一次。见第5.3节。
Messages from the DHCPv4 server come as multiple responses to a single DHCPACTIVELEASEQUERY message. Thus, each DHCPACTIVELEASEQUERY or DHCPBULKLEASEQUERY request must have an xid (transaction-id) unique on the connection on which it is sent (see Section 7.3), and all of the messages that come as a response to it contain the same xid as the request.
来自DHCPv4服务器的消息作为对单个DHCPActivableAseQuery消息的多个响应。因此，每个DHCPActiveLaseQuery或DHCPBULKLEASEQUERY请求在其发送的连接上必须具有唯一的xid（事务id）（参见第7.3节），并且作为响应的所有消息都包含与请求相同的xid。
Only one DHCPACTIVELEASEQUERY is allowed on any one TCP connection at a time. Parallel DHCPACTIVELEASEQUERY requests on the same TCP connection are not allowed.
一次只允许在任何一个TCP连接上使用一个DHCPACTIVELEASEQUERY。不允许在同一TCP连接上执行并行DHCPactiveLaseQuery请求。
A requestor SHOULD be able to operate in either insecure or secure mode. See Section 9. This MAY be a feature that is administratively controlled.
请求者应该能够在不安全或安全模式下操作。见第9节。这可能是受管理控制的功能。
When operating in insecure mode, the requestor sends a DHCPACTIVELEASEQUERY request after the establishment of a TCP connection.
在不安全模式下操作时，请求者在建立TCP连接后发送DHCPActiveLaseQuery请求。
When operating in secure mode, the requestor MUST attempt to negotiate a TLS [RFC5246] connection over the TCP connection. If this negotiation fails, the requestor MUST close the TCP connection. The recommendations in [RFC7525] apply when negotiating this connection.
在安全模式下操作时，请求者必须尝试通过TCP连接协商TLS[RFC5246]连接。如果协商失败，请求者必须关闭TCP连接。[RFC7525]中的建议适用于协商此连接。
A requestor requests the establishment of a TLS connection by sending the DHCPTLS message to the DHCPv4 server as the first message over the TCP connection. The DHCPTLS message SHOULD be sent without any options. This message indicates to the DHCPv4 server that a TLS connection over this TCP connection is desired. There are four possibilities after the requestor sends the DHCPTLS message to the DHCPV4 server:
请求者通过TCP连接向DHCPv4服务器发送DHCPTLS消息作为第一条消息，请求建立TLS连接。发送DHCPTLS消息时应不带任何选项。此消息向DHCPv4服务器指示需要通过此TCP连接进行TLS连接。请求者向DHCPV4服务器发送DHCPTLS消息后，有四种可能：
1. No response from the DHCPv4 server.
1. DHCPv4服务器没有响应。
2. The DHCPv4 server closes the TCP connection after it receives the DHCPTLS message.
2. DHCPv4服务器在收到DHCPTLS消息后关闭TCP连接。
3. DHCPv4 server responds with a DHCPTLS message with a dhcp-status-code of TLSConnectionRefused.
3. DHCPv4服务器响应DHCPTLS消息，dhcp状态代码为TLSConnectionRejected。
4. DHCPv4 server responds with DHCPTLS message with no dhcp-status-code, indicating success.
4. DHCPv4服务器响应DHCPTLS消息，不带dhcp状态代码，表示成功。
In any of the first three possibilities, the DHCPv4 server can be assumed to not support TLS. In this case, the requestor MUST close the connection.
在前三种可能性中，可以假设DHCPv4服务器不支持TLS。在这种情况下，请求者必须关闭连接。
In the final possibility, where the DHCPv4 server has responded with a DHCPTLS message with no dhcp-status-code in response to the requestor's DHCPTLS message, the requestor SHOULD initiate the exchange of the messages involved in a TLS handshake [RFC5246].
在最后一种情况下，如果DHCPv4服务器响应请求者的DHCPTLS消息时使用了没有dhcp状态代码的DHCPTLS消息，则请求者应启动TLS握手中涉及的消息交换[RFC5246]。
During the TLS handshake, the requestor MUST validate the DHCPv4 server's digital certificates.
在TLS握手期间，请求者必须验证DHCPv4服务器的数字证书。
If the handshake exchange yields a functioning TLS connection, then the requestor SHOULD transmit a DHCPACTIVELEASEQUERY message over that TLS connection and use that TLS connection for all further interactions in which it engages with the DHCPv4 server over this TCP connection.
如果握手交换产生一个正常工作的TLS连接，则请求者应通过该TLS连接发送DHCPACTIVELEASEQUERY消息，并将该TLS连接用于通过该TCP连接与DHCPv4服务器进行的所有进一步交互。
If the handshake exchange does not yield a functioning TLS connection, then the requestor MUST close the TCP connection.
如果握手交换没有产生正常工作的TLS连接，那么请求者必须关闭TCP连接。
The Active Leasequery is designed to create a long-lived connection between the requestor and the DHCPv4 server processing the active query. The DHCPv4 server SHOULD send binding information back across this connection with minimal delay after it learns of the binding information. It will learn about the bindings either because it makes the bindings itself or because it has received information about a binding from another server.
Active Leasequery旨在创建请求者与处理活动查询的DHCPv4服务器之间的长期连接。DHCPv4服务器在获悉绑定信息后，应通过此连接以最小的延迟将绑定信息发送回。它将了解绑定，因为它自己创建绑定，或者因为它已从另一台服务器接收到有关绑定的信息。
An Active Leasequery is a DHCPv4 request with a dhcp-message-type of DHCPACTIVELEASEQUERY. The DHCPv4 request MUST NOT have a ciaddr, a chaddr, or a dhcp-client-identifier. The DHCPv4 request MUST have an xid (transaction-id) unique on the connection on which it is sent. The DHCPv4 request SHOULD have a dhcp-parameter-request-list to inform the DHCPv4 server which DHCPv4 options are of interest to the requestor sending the DHCPACTIVELEASEQUERY message.
活动租赁请求是dhcp消息类型为DHCPACTIVELEASEQUERY的DHCPv4请求。DHCPv4请求不得具有ciaddr、chaddr或dhcp客户端标识符。DHCPv4请求在其发送的连接上必须具有唯一的xid（事务id）。DHCPv4请求应具有dhcp参数请求列表，以通知DHCPv4服务器发送DHCPACTIVELEASEQUERY消息的请求者感兴趣的DHCPv4选项。
An important capability of the Active Leasequery is that the requestor can specify that some recent data be sent immediately to the requestor in parallel with the transmission of the ongoing binding information in more or less real time. This capability is used in order to allow an Active Leasequery requestor to recover missed information in the event that it temporarily loses connectivity with the DHCPv4 server processing a previous Active Leasequery.
主动租赁请求的一个重要功能是，请求者可以指定将一些最近的数据立即发送给请求者，同时或多或少实时地传输正在进行的绑定信息。此功能用于允许活动租赁请求者在临时失去与处理先前活动租赁请求的DHCPv4服务器的连接时恢复丢失的信息。
This capability is enabled by the transmission of a 4-octet base-time option with each Leasequery reply sent as the result of a previous Active Leasequery. The requestor SHOULD keep track of the highest base-time received from a particular DHCPv4 server over an Active Leasequery connection, and in the event that the requestor finds it necessary (for whatever reason) to reestablish an Active Leasequery connection to that DHCPv4 server, the requestor should place this
此功能通过传输4个八位字节的基本时间选项来启用，每个Leasequery回复都作为先前活动Leasequery的结果发送。请求者应跟踪通过活动租赁连接从特定DHCPv4服务器接收的最高基准时间，如果请求者发现有必要（出于任何原因）重新建立与该DHCPv4服务器的活动租赁连接，则请求者应将此
highest base-time value into a query-start-time option in the new DHCPACTIVELEASEQUERY request. (See Sections 6.2.5 and 7.2 of [RFC6926] for information on the query-start-time option.)
在新的DHCPActivableAseQuery请求中，查询开始时间选项的最高基准时间值。（有关查询开始时间选项的信息，请参见[RFC6926]第6.2.5节和第7.2节。）
Note that until all of the recent data (catch-up data) has been received, the requestor MUST NOT keep track of the base-time received in Leasequery reply messages to use later in a subsequent Bulk Leasequery or Active Leasequery request.
请注意，在收到所有最近的数据（追赶数据）之前，请求者不得跟踪Leasequery回复消息中接收到的基本时间，以便稍后在后续批量Leasequery或活动Leasequery请求中使用。
If the requestor doesn't wish to request an update of information missed when it was not connected to the DHCPv4 server, then it does not include the query-start-time option in the DHCPACTIVELEASEQUERY request.
如果请求者不希望请求更新未连接到DHCPv4服务器时丢失的信息，则在DHCPactiveLaseQuery请求中不包括查询开始时间选项。
If the TCP connection becomes blocked or stops being writable while the requestor is sending its query, the requestor SHOULD terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow requestors to control the period of time they are willing to wait before abandoning a connection, independent of notifications from the TCP implementations they may be using.
如果TCP连接在请求者发送其查询时被阻止或停止可写，请求者应在大容量数据超时后终止连接。我们提出此建议是为了允许请求者在放弃连接之前控制他们愿意等待的时间段，而不依赖于他们可能使用的TCP实现的通知。
The Requestor attempts to read a DHCPv4 leasequery reply message from the TCP connection.
请求者尝试从TCP连接读取DHCPv4 leasequery回复消息。
Note that the connection resulting from accepting a DHCPACTIVELEASEQUERY request may be long-lived and may not have data transferring continuously during its lifetime. Therefore, the DHCPv4 server SHOULD send a DHCPLEASEQUERYSTATUS message with a dhcp-status-code of ConnectionActive every ACTIVE_LQ_IDLE_TIMEOUT seconds (default 60) in order for the requestor to know that the connection remains alive. This approach is followed only when the connection is idle (i.e., the server has no binding data to send). During normal binding data exchange, receiving DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED messages by the requestor itself signifies that the connection is active. Note that the default for ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of the ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds, which drives the DHCPv4 server to send messages. Thus, ACTIVE_LQ_RCV_TIMEOUT controls how sensitive the requestor is to be to delays by the DHCPv4 server in sending updates or DHCPLEASEQUERYSTATUS messages.
请注意，接受DHCPactiveLaseQuery请求所产生的连接可能是长期的，并且在其生命周期内可能没有连续的数据传输。因此，DHCPv4服务器应发送一条DHCPLEASEQUERYSTATUS消息，其中dhcp状态代码为ConnectionActive every ACTIVE\u LQ\u IDLE\u TIMEOUT seconds（默认值60），以便请求者知道连接保持活动状态。只有当连接空闲时（即，服务器没有要发送的绑定数据），才采用这种方法。在正常绑定数据交换期间，请求者本身接收到DHCPLEASEACTIVE或DHCPLEASEUNASSIGNED消息表示连接处于活动状态。请注意，活动\u LQ\u RCV\u超时的默认值为120秒，是活动\u LQ\u空闲\u超时的默认值60秒的两倍，该值驱动DHCPv4服务器发送消息。因此，ACTIVE_LQ_RCV_TIMEOUT控制请求者在发送更新或DHCPLEASEQUERYSTATUS消息时对DHCPv4服务器延迟的敏感程度。
If the stream of replies becomes blocked with no messages being received, the Requestor SHOULD terminate the connection after ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured to do so.
如果回复流被阻止且未收到任何消息，则请求者应在ACTIVE_LQ_RCV_超时后终止连接，并可在配置为这样做的情况下开始重试处理。
A successful query that is returning binding data MUST include a non-zero ciaddr. It may also include a non-zero chaddr, htype, and hlen as well as additional options. If there are additional bindings to be returned, they will be carried in additional Active Leasequery messages.
返回绑定数据的成功查询必须包含非零ciaddr。它还可能包括非零chaddr、htype和hlen以及其他选项。如果要返回其他绑定，它们将在其他活动的Leasequery消息中携带。
Any requestor of an Active Leasequery operation MUST be prepared to receive multiple copies of the binding information for a particular IPv4 address. See the Bulk Leasequery document [RFC6926] for information on how to deal with this situation.
活动Leasequery操作的任何请求者都必须准备好接收特定IPv4地址的绑定信息的多个副本。有关如何处理这种情况的信息，请参阅批量租赁文档[RFC6926]。
A single Active Leasequery can and usually will result in a large number of replies. The Requestor MUST be prepared to receive more than one reply with transaction-ids matching a single DHCPACTIVELEASEQUERY message from a single DHCPv4 server.
一个活动的租赁请求可以并且通常会导致大量的回复。请求者必须准备好从单个DHCPv4服务器接收多个事务ID与单个DHCPActivableAseQuery消息匹配的回复。
A DHCPACTIVELEASEQUERY has two regimes -- during the catch-up phase, if any, and after any catch-up phase. If the DHCPACTIVELASEQUERY request had a query-start-time, then the DHCPACTIVELEASEQUERY starts out in the catch-up phase. See Section 7.4.1 for information on processing during the catch-up phase, as well as how to determine when the catch-up phase is complete.
DHCPactiveLaseQuery有两种机制——在追赶阶段期间（如果有）和追赶阶段之后。如果DHCPActiveRequest具有查询开始时间，则DHCPACTIVELASEQUERY将在追赶阶段开始。关于追赶阶段的处理信息，以及如何确定追赶阶段何时完成，请参见第7.4.1节。
After the catch-up phase, or during the entire series of messages received as the response to a DHCPACTIVELEASEQUERY request with no query-start-time (and therefore no catch-up phase), the base-time option of the most recent message SHOULD be saved as a record of the most recent time that data was received. This base-time (in the context of the DHCPv4 server) can be used in a subsequent DHCPACTIVELEASEQUERY message's query-start-time or in a DHCPBULKLEASEQUERY message's query-start-time, if one is required, after a loss of the Active Leasequery connection.
在追赶阶段之后，或者在作为对DHCPActivableAseQuery请求的响应而接收的整个消息系列中，没有查询开始时间（因此也没有追赶阶段），最近消息的基本时间选项应保存为接收数据的最近时间的记录。此基准时间（在DHCPv4服务器的上下文中）可用于后续DHCPActiveLaseQuery消息的查询开始时间，或在失去活动的Leasequery连接后DHCPBULKLEASEQUERY消息的查询开始时间（如果需要）中。
The DHCPLEASEQUERYSTATUS message MAY unilaterally terminate a successful DHCPACTIVELEASEQUERY request that is currently in progress in the event that the DHCPv4 server determines that it cannot continue processing a DHCPACTIVELEASEQUERY request. For example, when a server is requested to shut down, it SHOULD send a DHCPLEASEQUERYSTATUS message with a dhcp-status-code of QueryTerminated and include in the message a base-time. This MUST be the last message on that connection, and once the message has been transmitted, the server MUST close the connection.
如果DHCPv4服务器确定其无法继续处理DHCPACTIVELEASEQUERY请求，则DHCPLEASEQUERYSTATUS消息可能会单方面终止当前正在进行的成功DHCPACTIVELEASEQUERY请求。例如，当请求关闭服务器时，它应发送一条DHCPLEASEQUERYSTATUS消息，其中dhcp状态代码为QueryTerminated，并在消息中包含一个基准时间。这必须是该连接上的最后一条消息，消息传输完毕后，服务器必须关闭连接。
After receiving DHCPLEASEQUERYSTATUS with a QueryTerminated status from a server, the Requestor MAY close the TCP connection to that server.
从服务器接收到状态为QueryTerminated的DHCPLEASEQUERYSTATUS后，请求者可以关闭与该服务器的TCP连接。
The DHCPv4 Leasequery protocol uses the associated-ip option as an indicator that multiple bindings were present in response to a single client-based query. For Active Leasequery, client-based queries are not supported, and so the associated-ip option is not used and MUST NOT be present in replies.
DHCPv4 Leasequery协议使用关联的ip选项作为指示器，指示在响应单个基于客户端的查询时存在多个绑定。对于Active Leasequery，不支持基于客户端的查询，因此不使用关联的ip选项，并且回复中不得出现该选项。
If the DHCPACTIVELEASEQUERY was requested with a query-start-time, the DHCPv4 server will attempt to send information about all bindings that changed since the time specified in the query-start-time. This is the catch-up phase of the DHCPACTIVELEASEQUERY processing. The DHCPv4 server MAY also begin immediate updates over the same connection of real-time binding information changes. Thus, the catch-up phase can run in parallel with the normal updates generated by the DHCPACTIVELEASEQUERY request.
如果使用查询开始时间请求DHCPactiveLaseQuery，DHCPv4服务器将尝试发送自查询开始时间中指定的时间以来更改的所有绑定的信息。这是DHCPActivableAseQuery处理的追赶阶段。DHCPv4服务器还可以通过实时绑定信息更改的同一连接立即开始更新。因此，追赶阶段可以与DHCPACTIVELEASEQUERY请求生成的正常更新并行运行。
A DHCPv4 server MAY keep only a limited amount of time-ordered information available to respond to a DHCPACTIVELEASEQUERY request containing a query-start-time. Thus, it is possible that the time specified in the query-start-time represents a time not covered by the time-ordered information kept by the DHCPv4 server. In such case, when there is not enough data saved in the DHCPv4 server to satisfy the request specified by the query-start-time option, the DHCPv4 server will reply immediately with a DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DataMissing with a base-time option equal to the server's current time. This will signal the end of the catch-up phase, and the only updates that will subsequently be received on this connection are the real-time updates from the DHCPACTIVELEASEQUERY request.
DHCPv4服务器可能只保留有限数量的时间顺序信息，用于响应包含查询开始时间的DHCPactiveLaseQuery请求。因此，查询开始时间中指定的时间可能表示DHCPv4服务器保存的时间顺序信息未涵盖的时间。在这种情况下，当DHCPv4服务器中保存的数据不足，无法满足查询开始时间选项指定的请求时，DHCPv4服务器将立即回复一条DHCPLEASEQUERYSTATUS消息，该消息的dhcp状态代码为DataMissing，基本时间选项等于服务器的当前时间。这将标志着追赶阶段的结束，并且随后在此连接上接收到的唯一更新是来自DHCPactiveLaseQuery请求的实时更新。
If there is enough data saved to satisfy the request, then DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will begin arrive from the DHCPv4 server. Some of these messages will be related to the query-start-time request and be part of the catch-up phase. Some of these messages will be real-time updates of binding changes taking place in the DHCPv4 server. In general, there is no way to determine the source of each message.
如果保存了足够的数据以满足请求，则DHCPLEASEACTIVE和DHCPLEASEUNASSIGNED消息将开始从DHCPv4服务器到达。其中一些消息将与查询开始时间请求相关，并且是追赶阶段的一部分。其中一些消息将是DHCPv4服务器中发生的绑定更改的实时更新。一般来说，没有办法确定每条消息的来源。
The updates sent by the DHCPv4 server during the catch-up phase are not in the order that the binding data was updated. Therefore, until the catch-up phase is complete, the latest base-time value received from a DHCPv4 server processing an Active Leasequery request cannot be reset from the incoming messages (and used in a subsequent Active Leasequery's query-start-time option), because to do so would compromise the ability to recover lost information if the DHCPACTIVELEASEQUERY were to terminate prior to the completion of the catch-up phase.
DHCPv4服务器在追赶阶段发送的更新与绑定数据的更新顺序不一致。因此，在追赶阶段完成之前，从处理活动租赁请求的DHCPv4服务器接收到的最新基本时间值无法从传入消息中重置（并在后续活动租赁请求的查询开始时间选项中使用），因为如果DHCPactiveLaseQuery在追赶阶段完成之前终止，那么这样做将损害恢复丢失信息的能力。
The requestor will know that the catch-up phase is complete because the DHCPv4 server will transmit a DHCPLEASEQUERYSTATUS message with the dhcp-status-code of CatchUpComplete (or, as discussed above, DataMissing). Once this message is transmitted, all additional DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will relate to real-time ("new") binding changes in the DHCPv4 server.
请求者将知道追赶阶段已完成，因为DHCPv4服务器将发送dhcp状态代码为CatchUpComplete（或如上所述的DataMissing）的DHCPLEASEQUERYSTATUS消息。传输此消息后，所有附加的DHCPLEASEACTIVE和DHCPLEASEUNASSIGNED消息将与DHCPv4服务器中的实时（“新”）绑定更改相关。
As discussed in Section 6.3, the requestor SHOULD keep track of the latest base-time option value received over a particular connection, to be used in a subsequent DHCPACTIVELEASEQUERY request -- but only if the catch-up phase is complete. Prior to the completion of the catch-up phase, if the connection should go away or if the requestor receives a DHCPLEASEQUERYDONE message, then when it reconnects it MUST use the base-time value from the previous connection and not any base-time value received from the recently closed connection.
如第6.3节所述，请求者应跟踪通过特定连接接收到的最新基准时间选项值，以便在后续DHCPActivableAseQuery请求中使用——但前提是追赶阶段已完成。在追赶阶段完成之前，如果连接应该消失，或者如果请求者接收到DHCPLeaseQueryOne消息，那么当它重新连接时，它必须使用来自上一个连接的基本时间值，而不是来自最近关闭的连接的任何基本时间值。
In the event that there was enough data available to the DHCPv4 server to begin to satisfy the request implied by the query-start-time option, but during the processing of that data the server found that it was unable to continue (perhaps there was barely enough, the connection was very slow, and the aging algorithm caused the saved data to become unavailable), the DHCPv4 server will terminate the catch-up phase of processing immediately by sending a DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DataMissing and with a base-time option of the current time.
如果DHCPv4服务器有足够的可用数据开始满足查询开始时间选项暗示的请求，但在处理该数据期间，服务器发现无法继续（可能不够，连接速度非常慢，老化算法导致保存的数据变得不可用），DHCPv4服务器将通过发送一条DHCPLEASEQUERYSTATUS消息立即终止处理的追赶阶段，该消息的dhcp状态代码为DataMissing，基时选项为当前时间。
The requestor must not assume that every individual state change of every binding during the period from the time specified in the query-start-time and the present is replicated in an Active Leasequery reply message. See Section 6. The requestor MAY assume that at least one Active Leasequery reply message will exist for every binding that had one or more changes of state during the period specified by the query-start-time and the current time. The last message for each binding will contain the state at the current time, and there can be one or more messages concerning a single binding during the catch-up phase of processing.
请求者不得假设在查询开始时间和当前时间指定的时间段内，每个绑定的每个单独状态更改都会复制到活动的Leasequery回复消息中。见第6节。请求者可以假设，在查询开始时间和当前时间指定的时间段内，每个具有一个或多个状态更改的绑定将至少存在一个活动的Leasequery回复消息。每个绑定的最后一条消息将包含当前的状态，在处理的追赶阶段，可能有一条或多条消息涉及单个绑定。
Bindings can change multiple times while the requestor is not connected. The requestor will only receive information about the current state of the binding, not information about each state change that occurred during the period from the query-start-time to the present.
当请求者未连接时，绑定可以更改多次。请求者将只接收关于绑定当前状态的信息，而不是关于从查询开始时间到当前期间发生的每个状态更改的信息。
If the DHCPLEASEQUERYSTATUS message containing a dhcp-status-code of DataMissing is received and the requestor is interested in keeping its database up to date with respect to the current state of the bindings in the DHCPv4 server, then the requestor SHOULD issue a DHCPBULKLEASEQUERY request to recover the information missing from
如果收到包含DataMissing的dhcp状态代码的DHCPLEASEQUERYSTATUS消息，并且请求者希望保持其数据库相对于DHCPv4服务器中绑定的当前状态的最新状态，则请求者应发出DHCPBULKLEASEQUERY请求，以从中恢复丢失的信息
its database. This DHCPBULKLEASEQUERY should include a query-start-time option, set to the same value as the query-start-time option previously included in the DHCPACTIVELEASEQUERY responses from the DHCPv4 server, and a query-end-time option equal to the base-time option returned by the DHCPv4 server in the DHCPLEASEQUERYSTATUS message with the dhcp-status-code of DataMissing.
它的数据库。此DHCPBULKLEASEQUERY应包含一个查询开始时间选项，该选项的值与DHCPv4服务器的DHCPactiveEleaseQuery响应中先前包含的查询开始时间选项的值相同，以及查询结束时间选项，该选项等于DHCPLEASEQUERYSTATUS消息中DHCPv4服务器返回的基准时间选项，dhcp状态代码为DataMissing。
Typically, the requestor would have one connection open to a DHCPv4 server for a DHCPACTIVELEASEQUERY request and possibly one additional connection open for a DHCPBULKLEASEQUERY request to the same DHCPv4 server to fill in the data that might have been missed prior to the initiation of the DHCPACTIVELEASEQUERY. The Bulk Leasequery connection would typically run to completion and be closed, leaving one Active Leasequery connection open to a single DHCPv4 server.
通常，请求者会为DHCPACTIVELEASEQUERY请求打开一个到DHCPv4服务器的连接，并可能为到同一个DHCPv4服务器的DHCPBULKLEASEQUERY请求打开一个额外的连接，以填充在启动DHCPACTIVELEASEQUERY之前可能丢失的数据。批量Leasequery连接通常会运行到完成并关闭，从而使一个活动的Leasequery连接对单个DHCPv4服务器保持打开状态。
The Requestor or DHCPv4 leasequery server MAY close its end of the TCP connection at any time. The Requestor MAY choose to retain the connection if it intends to issue additional queries. Note that this requestor behavior does not guarantee that the connection will be available for additional queries: the server might decide to close the connection based on its own configuration.
请求者或DHCPv4 leasequery服务器可随时关闭其TCP连接端。如果请求者打算发出附加查询，则可以选择保留连接。请注意，此请求者行为并不保证连接可用于其他查询：服务器可能会根据自己的配置决定关闭连接。
A DHCPv4 server that supports Active Leasequery MUST support Bulk Leasequery [RFC6926] as well.
支持活动租赁的DHCPv4服务器也必须支持批量租赁[RFC6926]。
DHCPv4 servers that implement DHCPv4 Active Leasequery listen for incoming TCP connections. The approach used in accepting the requestor's connection is the same as specified in DHCPv4 Bulk Leasequery [RFC6926], with the exception that support for Active Leasequery MUST NOT be enabled by default, and MUST require an explicit configuration step to be performed before it will operate.
实现DHCPv4 Active Leasequery的DHCPv4服务器侦听传入的TCP连接。接受请求者连接时使用的方法与DHCPv4批量租赁[RFC6926]中规定的方法相同，但默认情况下不得启用对活动租赁的支持，并且必须在其运行之前执行明确的配置步骤。
DHCPv4 servers SHOULD be able to operate in either insecure or secure mode. See Section 9. This MAY be a mode that is administratively controlled, where the server will require a TLS connection to operate or will only operate without a TLS connection. In either case, operation in insecure mode MUST NOT be the default, even if operation in secure mode is not supported. Operation in insecure mode MUST always require an explicit configuration step, separate from the configuration step required to enable support for Active Leasequery.
DHCPv4服务器应该能够在不安全或安全模式下运行。见第9节。这可能是一种管理控制的模式，其中服务器需要TLS连接才能运行，或者仅在没有TLS连接的情况下运行。在这两种情况下，即使不支持在安全模式下的操作，在不安全模式下的操作也不能是默认操作。在不安全模式下的操作必须始终需要明确的配置步骤，与支持活动租赁所需的配置步骤分开。
When operating in insecure mode, the DHCPv4 server simply waits for the requestor to send the Active Leasequery after the establishment of TCP connection. If it receives a DHCPTLS message, it will respond with TLSConnectionRefused in a DHCPTLS message.
在不安全模式下运行时，DHCPv4服务器只需在TCP连接建立后等待请求者发送活动的请求。如果它收到DHCPTLS消息，它将在DHCPTLS消息中以TLSConnectionRejected响应。
When operating in secure mode, DHCPv4 servers MUST support TLS [RFC5246] to protect the integrity and privacy of the data transmitted over the TCP connection. When operating in secure mode, DHCPv4 servers MUST be configurable with regard to which requestors they will communicate. The certificate presented by a requestor when initiating the TLS connection is used to distinguish between acceptable and unacceptable requestors.
在安全模式下运行时，DHCPv4服务器必须支持TLS[RFC5246]，以保护通过TCP连接传输的数据的完整性和隐私。在安全模式下运行时，DHCPv4服务器必须可配置，以与哪些请求者通信。请求者在启动TLS连接时提供的证书用于区分可接受和不可接受的请求者。
When operating in secure mode, a DHCPv4 server MUST begin to negotiate a TLS connection with a requestor who asks for one, and MUST close TCP connections that are not secured with TLS or for which the requestor's certificate is deemed unacceptable. The recommendations in [RFC7525] apply when negotiating a TLS connection.
在安全模式下运行时，DHCPv4服务器必须开始与请求TLS连接的请求者协商TLS连接，并且必须关闭未使用TLS保护或请求者证书被视为不可接受的TCP连接。[RFC7525]中的建议适用于协商TLS连接。
A requestor will request a TLS connection by sending a DHCPTLS as the first message over a newly created TCP connection. If the DHCPv4 server supports TLS connections and has not been configured to not allow them on this link, the DHCPv4 server MUST respond to this DHCPTLS message by sending a DHCPTLS message with no dhcp-status-code back to the requestor. This indicates to the requestor that the DHCPv4 server will support the negotiation of a TLS connection over this existing TCP connection.
请求者将通过在新创建的TCP连接上发送DHCPTLS作为第一条消息来请求TLS连接。如果DHCPv4服务器支持TLS连接，并且尚未配置为不允许在该链接上使用TLS连接，则DHCPv4服务器必须通过向请求者发送不带dhcp状态代码的DHCPTLS消息来响应此DHCPTLS消息。这向请求者指示DHCPv4服务器将支持通过现有TCP连接协商TLS连接。
If a connection is to be rejected because of a limitation of the number of open connections, the TCP connection itself should be rejected, or the subsequent ACTIVELEASEQUERY message should be rejected. Capacity-related rejections SHOULD NOT affect the response to the DHCPTLS message.
如果由于开放连接数量的限制而拒绝连接，则应拒绝TCP连接本身，或拒绝后续ACTIVELEASEQUERY消息。与容量相关的拒绝不应影响对DHCPTLS消息的响应。
Any options appearing in a DHCPTLS message received by a DHCPv4 server SHOULD be ignored. This is a "SHOULD" instead of a "MUST" in order to allow use of the DHCPTLS message in later documents, possibly with the use of options, without requiring those documents to update this document.
应忽略DHCPv4服务器接收的DHCPTLS消息中出现的任何选项。这是一个“应该”而不是“必须”，以便允许在以后的文档中使用DHCPTLS消息，可能使用选项，而无需这些文档更新此文档。
If for some reason the DHCPv4 server cannot support or has been configured to not support a TLS connection, then it sends a DHCPTLS message with a dhcp-status-code of TLSConnectionRefused back to the requestor.
如果由于某种原因，DHCPv4服务器无法支持或已配置为不支持TLS连接，则它将向请求者发送一条DHCPTLS消息，该消息的dhcp状态代码为TLSConnectionRejected。
In the event that the DHCPv4 server sends a DHCPTLS message with no dhcp-status-code option included (which indicates success), the requestor is supposed to initiate a TLS handshake [RFC5246] (see
如果DHCPv4服务器发送的DHCPTLS消息不包含dhcp状态代码选项（表示成功），则请求者应启动TLS握手[RFC5246]（请参阅）
Section 7.2). During the TLS handshake, the DHCPv4 server MUST validate the requestor's digital certificate. In addition, the digital certificate presented by the requestor is used to decide if this requestor is allowed to perform an Active Leasequery. If this requestor's certificate is deemed unacceptable, the server MUST abort the creation of the TLS connection.
第7.2节）。在TLS握手期间，DHCPv4服务器必须验证请求者的数字证书。此外，请求者提供的数字证书用于决定是否允许该请求者执行活动租赁请求。如果认为此请求者的证书不可接受，服务器必须中止TLS连接的创建。
All TLS connections established between a requestor and a DHCPv4 server for the purposes of supporting Active Leasequery MUST be mutually authenticated.
为了支持主动租赁，在请求者和DHCPv4服务器之间建立的所有TLS连接必须经过相互验证。
If the TLS handshake is not successful in creating a TLS connection, the server MUST close the TCP connection.
如果TLS握手未能成功创建TLS连接，则服务器必须关闭TCP连接。
If the TCP connection becomes blocked while the server is accepting a connection or reading a query, it SHOULD 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 DATA\u超时后终止连接。我们提出这一建议是为了允许服务器在放弃非活动连接之前控制他们愿意等待的时间段，这与他们可能使用的TCP实现无关。
In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which didn't discuss this situation explicitly), if the DHCPv4 server receives a DHCPv4 message containing a dhcp-message-type option with a value that is not supported over a TCP connection, it MUST close the TCP connection.
在DHCPv4批量租赁协议[RFC6926]的更新中（未明确讨论此情况），如果DHCPv4服务器接收到包含dhcp消息类型选项的DHCPv4消息，该选项的值在TCP连接上不受支持，则必须关闭TCP连接。
If the connection becomes blocked while the server is attempting to send reply messages, the server SHOULD terminate the TCP connection after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs how long the DHCPv4 server is prepared to wait for the requestor to read and process enough information to unblock the TCP connection. The default is two minutes, which means that if more than two minutes goes by without the requestor reading enough information to unblock the TCP connection, the DHCPv4 server SHOULD close the TCP connection.
如果在服务器尝试发送回复消息时连接被阻止，则服务器应在活动\u LQ\u发送\u超时后终止TCP连接。此超时控制DHCPv4服务器准备等待请求者读取和处理足够信息以解除TCP连接阻塞的时间。默认值为两分钟，这意味着如果请求者没有读取足够的信息来解除对TCP连接的阻塞，而超过两分钟的时间，DHCPv4服务器应该关闭TCP连接。
If the DHCPv4 server encounters an error during processing of the DHCPACTIVELEASEQUERY message, either during initial processing or later during the message processing, it SHOULD send a DHCPLEASEQUERYSTATUS containing an error code of some kind in a dhcp-status-code option. It SHOULD close the connection after this error is signaled.
如果DHCPv4服务器在处理DHCPActiveLaseQuery消息期间（无论是在初始处理期间还是之后的消息处理期间）遇到错误，它应发送一个DHCPLEASEQUERYSTATUS，其中包含dhcp状态代码选项中的某种错误代码。它应该在发出此错误信号后关闭连接。
Every reply to a DHCPACTIVELEASEQUERY request MUST contain the information specified in replies to a DHCPBULKLEASEQUERY request [RFC6926], with the exception that a server implementing Active Leasequery SHOULD be able to be configured to prevent specific data items from being sent to the requestor even if these data items were requested in the dhcp-parameter-request-list option.
对DHCPActiveLaseQuery请求的每个回复必须包含对DHCPBULKLEASEQUERY请求[RFC6926]的回复中指定的信息，例外情况是，实现Active Leasequery的服务器应能够配置为阻止向请求者发送特定数据项，即使这些数据项是在dhcp参数请求列表选项中请求的。
Some servers can be configured to respond to a DHCPv4 Leasequery [RFC4388] or a DHCPBULKLEASEQUERY [RFC6926] for an IPv4 binding that is reserved in such a way that it appears that the IPv4 binding is leased to the DHCP client for which it is reserved. These servers SHOULD also respond to a DHCPACTIVELEASEQUERY request with the same information as they would to a DHCPBULKLEASEQUERY request when they first determine that the IPv4 binding is reserved to a DHCP client.
某些服务器可以配置为响应保留的IPv4绑定的DHCPv4 Leasequery[RFC4388]或DHCPBULKLEASEQUERY[RFC6926]，其保留方式似乎是将IPv4绑定租给保留该绑定的DHCP客户端。当这些服务器第一次确定IPv4绑定保留给DHCP客户端时，它们还应使用与响应DHCPBULKLEASEQUERY请求相同的信息来响应DHCPactiveLaseQuery请求。
If a DHCPACTIVELEASEQUERY request contains a query-start-time option, it indicates that the requestor would like the DHCPv4 server to send it not only messages that correspond to DHCPv4 binding activity that occurs subsequent to the receipt of the DHCPLEASEACTIVE request, but also messages that correspond to DHCPv4 binding activity that occurred prior to the DHCPACTIVELEASEQUERY request.
如果DHCPactiveLaseQuery请求包含查询开始时间选项，则表示请求者希望DHCPv4服务器不仅向其发送与收到DHCPLEASEACTIVE请求后发生的DHCPv4绑定活动相对应的消息，还包括与DHCPActiveLaseQuery请求之前发生的DHCPv4绑定活动相对应的消息。
If a query-end-time option appears in a DHCPACTIVELEASEQUERY the DHCPv4 server should send a DHCPLEASEQUERYSTATUS message with a dhcp-status-code of MalformedQuery and terminate the connection.
如果DHCPActiveLaseQuery中出现查询结束时间选项，则DHCPv4服务器应发送一条DHCPLEASEQUERYSTATUS消息，其中dhcp状态代码为MallformedQuery，并终止连接。
In order to implement a meaningful response to this query, the DHCPv4 server MAY keep track of the binding activity and associate changes with particular base-time values from the messages. Then, when requested to do so by a DHCPACTIVELEASEQUERY request containing a query-start-time option, the DHCPv4 server can respond with replies for all binding activity occurring on that query-start-time or later times.
为了实现对此查询的有意义响应，DHCPv4服务器可以跟踪绑定活动，并将更改与消息中的特定基本时间值相关联。然后，当包含查询开始时间选项的DHCPactiveLaseQuery请求请求执行此操作时，DHCPv4服务器可以对该查询开始时间或以后发生的所有绑定活动进行响应。
These replies based on the query-start-time MAY be interleaved with the messages generated due to current binding activity.
这些基于查询开始时间的回复可能与由于当前绑定活动而生成的消息交错。
Once the transmission of the DHCPv4 Leasequery messages associated with the query-start-time option are complete, a DHCPLEASEQUERYSTATUS message MUST be sent with a dhcp-status-code value of CatchUpComplete.
与查询开始时间选项关联的DHCPv4 Leasequery消息传输完成后，必须发送dhcp状态代码值为CatchUpComplete的DHCPLEASEQUERYSTATUS消息。
The DHCPv4 server SHOULD keep track of previous binding activity. It SHOULD limit the amount of previous binding activity it keeps track of. The DHCPv4 server MAY choose to only do this in the event that it has received at least one DHCPACTIVELEASEQUERY request in the past, as to do so will almost certainly entail some utilization of resources that would be wasted if there are no DHCPACTIVELEASEQUERY
DHCPv4服务器应该跟踪以前的绑定活动。它应该限制以前跟踪的绑定活动的数量。DHCPv4服务器可能会选择仅在其过去至少收到一个DHCPACTIVELEASEQUERY请求的情况下执行此操作，因为这样做几乎肯定会占用一些资源，如果没有DHCPACTIVELEASEQUERY，这些资源将被浪费
requestors for this DHCPv4 server. The DHCPv4 server SHOULD make the amount of previous binding activity it retains configurable. There is no requirement on the DHCPv4 server to retain this information over a server restart (or even to retain such information at all).
此DHCPv4服务器的请求程序。DHCPv4服务器应使其保留的先前绑定活动的数量可配置。DHCPv4服务器不需要在服务器重新启动时保留此信息（甚至根本不需要保留此类信息）。
Unless there is an error or some requirement to cease processing a DHCPACTIVELEASEQUERY request yielding a DHCPLEASEQUERYSTATUS message, such as a server shutdown, there will be no DHCPLEASEQUERYSTATUS message at the conclusion of the DHCPACTIVELEASEQUERY processing because that processing will not conclude but will continue until either the requestor or the server closes the connection.
除非出现错误或要求停止处理产生DHCPLEASEQUERYSTATUS消息的DHCPActiveLaseQuery请求，例如服务器关闭，DHCPACTIVELEASEQUERY处理结束时将不会有DHCPLEASEQUERYSTATUS消息，因为该处理不会结束，但将继续，直到请求者或服务器关闭连接。
While the form of the data being sent by a DHCPACTIVELEASEQUERY is essentially the same as that being sent by a DHCPBULKLEASEQUERY, the reasons for sending information differs considerably between these two capabilities. In the DHCPBULKLEASEQUERY context, the entire contents of the lease state database (subject to the constraints of the various query options) are returned to the requestor. In the DHCPACTIVELEASEQUERY context, changes to the lease state database are returned to the requestor essentially as they happen. For instance, when an IPv4 binding transitions from the leased state to some other state, the DHCPACTIVELEASEQUERY will send a DHCPLEASEUNASSIGNED packet with information regarding that binding. The server may then entirely forget about that IPv4 binding (or not), but it is important to tell the DHCPACTIVELEASEQUERY requestor that a binding has transitioned away from the leased state.
虽然DHCPACTIVELEASEQUERY发送的数据的形式与DHCPBULKLEASEQUERY发送的数据的形式基本相同，但这两种功能发送信息的原因有很大不同。在DHCPBULKLEASEQUERY上下文中，租约状态数据库的全部内容（受各种查询选项的约束）将返回给请求者。在DHCPActivableAseQuery上下文中，对租约状态数据库的更改基本上在发生时返回给请求者。例如，当IPv4绑定从租用状态转换到其他状态时，DHCPactiveLaseQuery将发送一个包含该绑定信息的DHCPLEASEUNASSIGNED数据包。然后，服务器可能会完全忘记IPv4绑定（或不忘记），但告诉DHCPActivableAseQuery请求者绑定已从租用状态转移是很重要的。
The relationship between the time that the server replies to a DHCP client request and the time that the DHCP server sends a reply to a DHCPACTIVELEASEQUERY message is a matter of implementation (and thus not defined by this document). However, the server SHOULD NOT delay responding to the DHCP client in order to transmit a reply to a DHCPACTIVELEASEQUERY message, and the server SHOULD send the reply to the DHCPACTIVELASEQUERY message as soon as possible after responding to the client.
服务器回复DHCP客户端请求的时间与DHCP服务器发送回复DHCPActivableAseQuery消息的时间之间的关系是一个实现问题（因此本文档未定义）。但是，服务器不应延迟对DHCP客户端的响应，以便发送对DHCPACTIVELASEQUERY消息的回复，并且服务器应在响应客户端后尽快将回复发送到DHCPACTIVELASEQUERY消息。
Every Active Leasequery request MUST be made on a single TCP connection where there is no other request active at the time the request is made. Note that this is different than what was allowed in Section 7.7 of [RFC6926] for Bulk Leasequery requests.
每个活动的租赁请求都必须在单个TCP连接上发出，而在发出请求时没有其他活动的请求。请注意，这与[RFC6926]第7.7节中允许的批量租赁请求不同。
Typically, a requestor of an Active Leasequery would not need to send a second Active Leasequery while the first is still active. However, sending an Active Leasequery and a Bulk Leasequery in parallel would be possible and reasonable. In case of parallel Active and Bulk Leasequery requests, the requestor MUST use different connections.
通常，当第一个活动租赁请求仍处于活动状态时，活动租赁请求的请求者不需要发送第二个活动租赁请求。但是，同时发送活动租赁和批量租赁是可能的，也是合理的。在并行活动和批量租赁请求的情况下，请求者必须使用不同的连接。
This MAY be a feature that is administratively controlled. Servers that are able to process queries in parallel 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 server MAY end communication by sending a DHCPLEASEQUERYSTATUS message and then immediately closing the TCP connection. Alternatively, the server MAY retain the connection and wait for additional queries from the requestor. The server SHOULD limit the number of connections it maintains and SHOULD close idle connections to enforce the limit.
服务器可以通过发送DHCPLEASEQUERYSTATUS消息，然后立即关闭TCP连接来结束通信。或者，服务器可以保留连接并等待来自请求者的附加查询。服务器应限制其维护的连接数，并应关闭空闲连接以强制执行该限制。
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 dhcp-status-code option in a DHCPLEASEQUERYSTATUS message. If the server detects that the requestor end has been closed, the server MUST close its end of the connection.
如果服务器在连接上发送数据时遇到错误，则必须关闭其TCP连接端。如果发现必须中止进程内请求，服务器必须关闭其TCP连接端。中止进程内请求的服务器应尝试通过使用DHCPLEASEQUERYSTATUS消息中dhcp状态代码选项中的QueryTerminated状态代码向其请求者发送该信号。如果服务器检测到请求端已关闭，则服务器必须关闭其连接端。
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 relayed LEASEQUERY messages, mitigation of packet-flooding DoS attacks, restriction to trusted requestors, and use of IPsec [RFC4301].
[RFC2131]的安全注意事项部分详细说明了DHCPv4面临的一般威胁。DHCPv4 Leasequery规范[RFC4388]描述了Leasequery协议的建议，特别是关于中继Leasequery消息、缓解数据包溢出DoS攻击、对受信任请求者的限制以及IPsec的使用[RFC4301]。
The use of TCP introduces some additional concerns. Attacks that attempt to exhaust the DHCPv4 server's available TCP connection resources can compromise the ability of legitimate clients to receive service. Malicious requestors who succeed in establishing connections, but who then send invalid queries, partial queries, or no queries at all also can exhaust a server's pool of available connections.
TCP的使用带来了一些额外的问题。试图耗尽DHCPv4服务器可用TCP连接资源的攻击可能会损害合法客户端接收服务的能力。成功建立连接但随后发送无效查询、部分查询或根本不发送查询的恶意请求者也会耗尽服务器的可用连接池。
Two modes of operation exist for this protocol, insecure mode and secure mode. These two modes exist because there are essentially two models of use for this protocol. In one model, the requestor of an Active Leasequery is connected to the Internet in an arbitrary location, and the information transmitted needs to be protected
此协议存在两种操作模式：不安全模式和安全模式。这两种模式的存在是因为该协议基本上有两种使用模式。在一个模型中，主动租赁请求者在任意位置连接到Internet，传输的信息需要得到保护
during transmission. In addition, the identities of both requestor and server need to be verified. For this model of use, the secure mode is appropriate.
在传输过程中。此外，还需要验证请求者和服务器的身份。对于这种使用模式，安全模式是合适的。
The other model of use is where the requestor of the Active Leasequery resides in a network element that is essentially "next to" the element containing the DHCP server, and both of these elements are inside a protected environment. For this model, the insecure mode is sufficient since there are other, more global, protections in place to protect this information.
另一种使用模式是，活动租赁请求的请求者驻留在基本上“紧挨着”包含DHCP服务器的元素的网络元素中，并且这两个元素都位于受保护的环境中。对于这种模式，不安全模式就足够了，因为有其他更全局的保护措施来保护这些信息。
When operating in secure mode, TLS [RFC5246] is used to secure the connection. The recommendations in [RFC7525] apply when negotiating a TLS connection.
在安全模式下操作时，TLS[RFC5246]用于保护连接。[RFC7525]中的建议适用于协商TLS连接。
Operating in insecure mode (see Section 8.1) does not provide any way to validate the authorization of requestors of a DHCPV4 Active Leasequery request.
在不安全模式下操作（见第8.1节）不提供任何方式来验证DHCPV4主动租赁请求请求者的授权。
Servers SHOULD offer configuration parameters to limit the sources of incoming connections through validation and use of the digital certificates presented to create a TLS connection. They SHOULD also limit the number of accepted connections and limit the period of time during which an idle connection will be left open.
服务器应提供配置参数，通过验证和使用提供的数字证书来创建TLS连接，从而限制传入连接的来源。它们还应该限制可接受连接的数量，并限制空闲连接保持打开的时间段。
The data acquired by using an Active Leasequery is subject to the same potential abuse as the data held by the DHCPv4 server from which it was acquired and SHOULD be secured by mechanisms as strong as those used for the data held by that DHCPv4 server. The data acquired by using an Active Leasequery SHOULD be deleted as soon as possible after the use for which it was acquired has passed.
通过使用主动租赁获取的数据可能与从中获取数据的DHCPv4服务器所持有的数据受到相同的滥用，并且应通过与DHCPv4服务器所持有数据相同的机制进行保护。通过使用活动租赁服务获取的数据应在其获取用途结束后尽快删除。
Servers that implement the Bulk Leasequery protocol [RFC6926] but do not implement the Active Leasequery protocol SHOULD implement the update to [RFC6926] discussed in Section 8.1.1.
实施批量租赁协议[RFC6926]但未实施活动租赁协议的服务器应实施第8.1.1节中讨论的[RFC6926]更新。
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 16 for DHCPACTIVELEASEQUERY.
1. DHCPActiveLaseQuery的dhcp消息类型为16。
2. A dhcp-message-type of 17 for DHCPLEASEQUERYSTATUS.
2. DHCPLEASEQUERYSTATUS的dhcp消息类型为17。
3. A dhcp-message-type of 18 for DHCPTLS.
3. DHCPTLS的dhcp消息类型为18。
IANA has assigned the following new DHCP status codes from the registry "DHCP Status Code Type 151 Values" maintained at <http://www.iana.org/assignments/bootp-dhcp-parameters>:
IANA已从维护在的注册表“DHCP状态代码类型151值”中分配以下新的DHCP状态代码<http://www.iana.org/assignments/bootp-dhcp-parameters>:
+----------------------+-------------+
| Name | Status-Code |
+----------------------+-------------+
| DataMissing | 5 |
| ConnectionActive | 6 |
| CatchUpComplete | 7 |
| TLSConnectionRefused | 8 |
+----------------------+-------------+
+----------------------+-------------+
| Name | Status-Code |
+----------------------+-------------+
| DataMissing | 5 |
| ConnectionActive | 6 |
| CatchUpComplete | 7 |
| TLSConnectionRefused | 8 |
+----------------------+-------------+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<http://www.rfc-editor.org/info/rfc2131>.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, DOI 10.17487/RFC4388, February 2006, <http://www.rfc-editor.org/info/rfc4388>.
[RFC4388]Woundy，R.和K.Kinnear，“动态主机配置协议（DHCP）租赁”，RFC 4388，DOI 10.17487/RFC4388，2006年2月<http://www.rfc-editor.org/info/rfc4388>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell, N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery", RFC 6926, DOI 10.17487/RFC6926, April 2013, <http://www.rfc-editor.org/info/rfc6926>.
[RFC6926]金尼尔，K.，斯塔普，M.，德塞蒂，R.，乔希，B.，罗素，N.，库拉帕蒂，P.，和B.沃尔兹，“DHCPv4散装租赁”，RFC 6926，DOI 10.17487/RFC6926，2013年4月<http://www.rfc-editor.org/info/rfc6926>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, DOI 10.17487/RFC0951, September 1985, <http://www.rfc-editor.org/info/rfc951>.
[RFC951]Croft，W.和J.Gilmore，“引导协议”，RFC 951，DOI 10.17487/RFC09511985年9月<http://www.rfc-editor.org/info/rfc951>.
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542, October 1993, <http://www.rfc-editor.org/info/rfc1542>.
[RFC1542]Wimer，W.，“引导协议的澄清和扩展”，RFC 1542，DOI 10.17487/RFC1542，1993年10月<http://www.rfc-editor.org/info/rfc1542>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 2132，DOI 10.17487/RFC2132，1997年3月<http://www.rfc-editor.org/info/rfc2132>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, <http://www.rfc-editor.org/info/rfc7414>.
[RFC7414]杜克，M.，布拉登，R.，艾迪，W.，布兰顿，E.，和A.齐默尔曼，“传输控制协议（TCP）规范文件路线图”，RFC 7414，DOI 10.17487/RFC7414，2015年2月<http://www.rfc-editor.org/info/rfc7414>.
Acknowledgments
致谢
The ideas in this document came in part from work in DHCPv6 and DHCPv4 Bulk Leasequery as well as from in depth discussions between the authors. Useful review comments by Ted Lemon, Scott Bradner, Francis Dupont, and Stephen Farrell on drafts for DHCPv6 Active Leasequery were also included in this draft. Brian Haberman's review brought this document into much closer alignment with DHCPv6 Active Leasequery. Additional reviews by Alissa Cooper, Spencer Dawkins, Christer Holmberg, and Ben Campbell added clarity to this document.
The ideas in this document came in part from work in DHCPv6 and DHCPv4 Bulk Leasequery as well as from in depth discussions between the authors. Useful review comments by Ted Lemon, Scott Bradner, Francis Dupont, and Stephen Farrell on drafts for DHCPv6 Active Leasequery were also included in this draft. Brian Haberman's review brought this document into much closer alignment with DHCPv6 Active Leasequery. Additional reviews by Alissa Cooper, Spencer Dawkins, Christer Holmberg, and Ben Campbell added clarity to this document.translate error, please retry
Authors' Addresses
作者地址
Kim Kinnear Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 United States
Kim Kinnear Cisco Systems，Inc.美国马萨诸塞州博克斯堡大道1414号，邮编01719
Email: kkinnear@cisco.com
Email: kkinnear@cisco.com
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 United States
Mark Stapp Cisco Systems，Inc.美国马萨诸塞州Boxborough大道1414号，邮编01719
Email: mjs@cisco.com
Email: mjs@cisco.com
Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 United States
Bernie Volz Cisco Systems，Inc.美国马萨诸塞州Boxborough大道1414号，邮编01719
Email: volz@cisco.com
Email: volz@cisco.com
Neil Russell Staples 500 Staples Drive Framingham, MA 01702 United States
Neil Russell Staples 500 Staples Drive美国马萨诸塞州弗雷明翰01702
Email: neil.e.russell@gmail.com
Email: neil.e.russell@gmail.com