Internet Engineering Task Force (IETF) D. Raghuvanshi
Request for Comments: 7653 K. Kinnear
Updates: 5460 D. Kukrety
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 October 2015
Internet Engineering Task Force (IETF) D. Raghuvanshi
Request for Comments: 7653 K. Kinnear
Updates: 5460 D. Kukrety
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 October 2015
DHCPv6 Active Leasequery
DHCPv6主动租赁
Abstract
摘要
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv6 bindings. That mechanism is limited to queries for DHCPv6 binding data updates prior to the time the DHCPv6 server receives the Leasequery request. Continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv6 Leasequery protocol and allows for active transfer of real-time DHCPv6 binding information data via TCP. This document also updates DHCPv6 Bulk Leasequery (RFC 5460) by adding new options.
IPv6的动态主机配置协议（DHCPv6）已通过一个Leasequery功能进行了扩展，该功能允许请求者请求有关DHCPv6绑定的信息。该机制仅限于在DHCPv6服务器收到Leasequery请求之前查询DHCPv6绑定数据更新。有时需要使用Leasequery数据持续更新外部请求者。本文档扩展了DHCPv6 Leasequery协议，并允许通过TCP主动传输实时DHCPv6绑定信息数据。本文档还通过添加新选项更新了DHCPv6批量租赁（RFC 5460）。
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/rfc7653.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7653.
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 ....................................................4
2. Terminology .....................................................4
3. Protocol Overview ...............................................6
4. Interaction between Active Leasequery and Bulk Leasequery .......8
5. Extension to DHCPv6 Bulk Leasequery .............................8
6. Message and Option Definitions ..................................9
6.1. Message Framing for TCP ....................................9
6.2. Messages ...................................................9
6.2.1. ACTIVELEASEQUERY ....................................9
6.2.2. STARTTLS ...........................................10
6.2.3. Response Messages ..................................10
6.3. Options ...................................................10
6.3.1. OPTION_LQ_BASE_TIME ................................10
6.3.2. OPTION_LQ_START_TIME ...............................11
6.3.3. OPTION_LQ_END_TIME .................................12
6.4. Connection and Transmission Parameters ....................12
7. Information Communicated by Active Leasequery ..................13
8. Requestor Behavior .............................................14
8.1. General Processing ........................................14
8.2. Initiating a Connection ...................................14
8.3. Forming an Active Leasequery ..............................15
8.4. Processing Active Replies .................................16
8.4.1. Processing Replies from a Request Containing an
OPTION_LQ_START_TIME ...............................18
8.5. Processing Time Values in Leasequery Messages .............20
8.6. Examples ..................................................21
8.6.1. Query Failure ......................................21
8.6.2. Data Missing on Server .............................21
8.6.3. Successful Query ...................................21
8.7. Closing Connections .......................................22
9. Server Behavior ................................................22
9.1. Accepting Connections .....................................22
9.2. Rejecting Connections .....................................24
9.3. Replying to an Active Leasequery ..........................24
9.4. Multiple or Parallel Queries ..............................26
9.5. Closing Connections .......................................26
10. Security Considerations .......................................27
11. IANA Considerations ...........................................28
12. References ....................................................28
12.1. Normative References .....................................28
12.2. Informative References ...................................29
Acknowledgments ...................................................30
Authors' Addresses ................................................30
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Protocol Overview ...............................................6
4. Interaction between Active Leasequery and Bulk Leasequery .......8
5. Extension to DHCPv6 Bulk Leasequery .............................8
6. Message and Option Definitions ..................................9
6.1. Message Framing for TCP ....................................9
6.2. Messages ...................................................9
6.2.1. ACTIVELEASEQUERY ....................................9
6.2.2. STARTTLS ...........................................10
6.2.3. Response Messages ..................................10
6.3. Options ...................................................10
6.3.1. OPTION_LQ_BASE_TIME ................................10
6.3.2. OPTION_LQ_START_TIME ...............................11
6.3.3. OPTION_LQ_END_TIME .................................12
6.4. Connection and Transmission Parameters ....................12
7. Information Communicated by Active Leasequery ..................13
8. Requestor Behavior .............................................14
8.1. General Processing ........................................14
8.2. Initiating a Connection ...................................14
8.3. Forming an Active Leasequery ..............................15
8.4. Processing Active Replies .................................16
8.4.1. Processing Replies from a Request Containing an
OPTION_LQ_START_TIME ...............................18
8.5. Processing Time Values in Leasequery Messages .............20
8.6. Examples ..................................................21
8.6.1. Query Failure ......................................21
8.6.2. Data Missing on Server .............................21
8.6.3. Successful Query ...................................21
8.7. Closing Connections .......................................22
9. Server Behavior ................................................22
9.1. Accepting Connections .....................................22
9.2. Rejecting Connections .....................................24
9.3. Replying to an Active Leasequery ..........................24
9.4. Multiple or Parallel Queries ..............................26
9.5. Closing Connections .......................................26
10. Security Considerations .......................................27
11. IANA Considerations ...........................................28
12. References ....................................................28
12.1. Normative References .....................................28
12.2. Informative References ...................................29
Acknowledgments ...................................................30
Authors' Addresses ................................................30
The DHCPv6 protocol [RFC3315] specifies a mechanism for the assignment of IPv6 address and configuration information to IPv6 nodes. IPv6 Prefix Delegation for DHCPv6 [RFC3633] specifies a mechanism for DHCPv6 delegation of IPv6 prefixes and related data. DHCPv6 servers maintain authoritative information including binding information for delegated IPv6 prefixes.
DHCPv6协议[RFC3315]指定了一种将IPv6地址和配置信息分配给IPv6节点的机制。DHCPv6的IPv6前缀委派[RFC3633]指定用于DHCPv6委派IPv6前缀和相关数据的机制。DHCPv6服务器维护权威信息，包括委派IPv6前缀的绑定信息。
Requirements exist for external entities to keep up to date on the correspondence between DHCPv6 clients and their bindings. These entities need to keep up with the current binding activity of the DHCPv6 server. Keeping up with this binding activity is termed "active" leasequery.
外部实体需要在DHCPv6客户机及其绑定之间保持最新的通信。这些实体需要跟上DHCPv6服务器当前的绑定活动。跟上这种结合活动被称为“主动”租赁。
The DHCPv6 Bulk Leasequery [RFC5460] capability can be used to recover useful information from a DHCPv6 server when some external entity starts up. This entity could be one that is directly involved in the DHCPv6 client-server transactions (e.g., a relay agent), or it could be an external process that needs information present in the DHCPv6 server's lease state database.
当某些外部实体启动时，DHCPv6批量租赁[RFC5460]功能可用于从DHCPv6服务器恢复有用信息。该实体可以是直接参与DHCPv6客户机-服务器事务的实体（例如，中继代理），也可以是需要DHCPv6服务器租赁状态数据库中提供信息的外部进程。
The Active Leasequery capability documented here is designed to allow an entity not directly involved in DHCPv6 client-server transactions to nevertheless keep current with the state of the DHCPv6 lease state information in real time.
此处介绍的主动租赁功能旨在允许未直接参与DHCPv6客户机-服务器事务的实体实时保持DHCPv6租赁状态信息的最新状态。
This document updates DHCPv6 Bulk Leasequery [RFC5460] by adding new options, as described in Section 6.2.1. For DHCPv6 servers supporting Bulk Leasequery and not Active Leasequery, Section 9.2 specifies the mechanism to reject incoming Active Leasequery requests.
本文件通过添加新选项更新DHCPv6批量租赁[RFC5460]，如第6.2.1节所述。对于支持批量租赁和非活动租赁的DHCPv6服务器，第9.2节规定了拒绝传入活动租赁请求的机制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
DHCPv6 terminology is defined in [RFC3315]. Terminology specific to DHCPv6 Active Leasequery can be found below:
[RFC3315]中定义了DHCPv6术语。DHCPv6主动租赁专用术语如下：
o absolute time
o 绝对时间
A 32-bit unsigned quantity containing the number of seconds since midnight (UTC), January 1, 2000, modulo 2^32.
一种32位无符号量，包含自2000年1月1日午夜（UTC）以来的秒数，模为2^32。
o Active Leasequery
o 主动租赁
Keeping up to date in real time (or near real time) with DHCPv6 binding activity.
通过DHCPv6绑定活动实时（或近实时）保持最新。
o Bulk Leasequery
o 散装租赁
Requesting and receiving information about all or some of the existing DHCPv6 binding information in an efficient manner, as defined by [RFC5460].
按照[RFC5460]的定义，以高效的方式请求和接收关于所有或部分现有DHCPv6绑定信息的信息。
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 binding change/update
o 绑定更改/更新
Any change in the DHCPv6 binding state. This also includes expiration or deletion of the binding.
DHCPv6绑定状态的任何更改。这还包括绑定的过期或删除。
o catch-up information
o 追赶信息
If a DHCPv6 Active Leasequery requestor sends an OPTION_LQ_START_TIME option in an ACTIVELEASEQUERY message, the DHCPv6 server will attempt to send the requestor the information that changed since the time specified in the OPTION_LQ_START_TIME option. The binding information sent to satisfy this request is the catch-up information.
如果DHCPv6活动租赁请求者在ACTIVELEASEQUERY消息中发送选项\u LQ\u START\u TIME选项，DHCPv6服务器将尝试向请求者发送自选项\u LQ\u START\u TIME选项中指定的时间以来更改的信息。为满足此请求而发送的绑定信息是追赶信息。
o catch-up phase
o 追赶阶段
The period while catch-up information is being sent is the catch-up phase.
发送追赶信息的时间段是追赶阶段。
o clock skew
o 时钟偏移
The difference between the absolute time on a DHCPv6 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 message is received by a requestor from a DHCPv6 server, a more accurate value is derived from continuously examining the instantaneous value developed from each message received from a DHCPv6 server
DHCPv6服务器上的绝对时间与系统上活动或批量租赁请求者正在执行的绝对时间之间的差异称为该活动或批量租赁连接的“时钟偏移”。它不是绝对恒定的，但可能只是缓慢地变化。虽然很容易认为这可以在请求者从DHCPv6服务器接收到一条消息后精确计算，但通过不断检查从DHCPv6服务器接收到的每条消息产生的瞬时值，可以得出更准确的值
and using it to make small adjustments to the existing value held in the requestor.
并使用它对请求者持有的现有值进行小的调整。
o DHCPv6 binding state
o DHCPv6结合状态
Data stored on the DHCPv6 server related to binding.
存储在DHCPv6服务器上与绑定相关的数据。
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 transaction-id
o 事务id
An opaque value used to match responses with queries initiated by an Active Leasequery requestor.
一个不透明值，用于将响应与活动Leasequery请求者发起的查询相匹配。
The Active Leasequery mechanism is modeled on the existing DHCPv6 Bulk Leasequery [RFC5460]; most differences arise from the long-term nature of the TCP [RFC7414] connection required for Active Leasequery. A DHCPv6 server that supports Active Leasequery MUST support Bulk Leasequery [RFC5460] as well.
主动租赁机制是在现有DHCPv6批量租赁机制[RFC5460]的基础上建模的；大多数差异源于主动租赁所需的TCP[RFC7414]连接的长期性质。支持活动租赁的DHCPv6服务器还必须支持批量租赁[RFC5460]。
An Active Leasequery requestor opens a TCP connection to a DHCPv6 server, using the DHCPv6 port 547. 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 DHCPv6 server. No relaying for Active Leasequery is specified.
活动的租赁请求者使用DHCPv6端口547打开到DHCPv6服务器的TCP连接。请注意，这意味着租赁请求者通过配置或其他方式具有可用的服务器IP地址，并且它具有到DHCPv6服务器的单播IP可达性。未指定活动租赁的中继。
After establishing a connection, the requestor sends an ACTIVELEASEQUERY message over the connection. In response, the server sends updates to the requestor using LEASEQUERY-REPLY and LEASEQUERY-DATA messages. This response procedure is similar to the procedure specified in [RFC5460], 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 a long-lived connection. Additionally, the Active Leasequery server SHOULD provide a mechanism to control which data is allowed to be included in the OPTION_CLIENT_DATA messages sent to the requestor. See Section 9.3.
建立连接后，请求者通过连接发送ActiveLeaRequesty消息。作为响应，服务器使用LEASEQUERY-REPLY和LEASEQUERY-DATA消息向请求者发送更新。此响应过程类似于[RFC5460]中指定的过程，不同之处在于，在活动Leasequery的情况下，每当发生某些活动以更改绑定状态时，服务器都会发送更新，因此需要长期连接。此外，主动租赁服务器应提供一种机制，以控制发送给请求者的选项\u客户端\u数据消息中允许包含哪些数据。见第9.3节。
Active Leasequery has features that allow this external entity to lose its connection and then reconnect and receive the latest information concerning any IPv6 bindings changed while it was not connected.
Active Leasequery具有允许此外部实体断开连接，然后重新连接并接收有关未连接时更改的任何IPv6绑定的最新信息的功能。
These features 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 DHCPv6 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 DHCPv6 server from which it is receiving updates and then reconnects to that server.
这些功能旨在允许活动租赁请求者在重新启动租赁状态数据库或运行租赁状态数据库的计算机重新初始化后，有效地更新租赁状态数据库。当请求者始终连接到DHCPv6服务器时，很容易定义一个工作的协议。由于这不够健壮，本文档中的许多机制旨在有效地处理活动租赁请求者与DHCPv6服务器断开连接（从该服务器接收更新，然后重新连接到该服务器）时发生的情况。
Central to this approach, 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 DHCPv6 server will determine whether or not data was missed while the Active Leasequery requestor was not connected.
这种方法的核心是，如果活动租赁请求者失去服务，允许其在后续活动租赁请求中指定其最新更新的时间，DHCPv6服务器将确定活动租赁请求者未连接时是否丢失了数据。
The DHCPv6 server processing the Active Leasequery request MAY limit the amount of data saved, and methods exist for the DHCPv6 server to inform the Active Leasequery requestor that data was missed (i.e., not all data could be saved). In this situation, the Active Leasequery requestor should issue a Bulk Leasequery [RFC5460] to recover information not available through an Active Leasequery.
处理活动租赁请求的DHCPv6服务器可能会限制保存的数据量，并且DHCPv6服务器存在通知活动租赁请求者丢失数据的方法（即，并非所有数据都可以保存）。在这种情况下，主动租赁请求者应发出批量租赁请求[RFC5460]，以恢复无法通过主动租赁请求获得的信息。
DHCPv6 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 DHCPv6 Active Leasequery requestor whose connection was temporarily interrupted. In other words, DHCPv6 servers supporting catch-up are required to have some mechanism to keep/save historic information of bindings.
DHCPv6服务器不需要保留与活动租赁请求连接上丢失的数据相对应的任何数据，但通常会选择保留与某些最近活动相对应的数据，以供连接暂时中断的DHCPv6活动租赁请求者进行后续查询。换句话说，支持追赶的DHCPv6服务器需要有某种机制来保存绑定的历史信息。
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 DHCPv6 server was lost for a longer time than the DHCPv6 server would keep track of the specific changes to the IPv6 binding information.
当数据库不包含绑定信息时，活动的Leasequery请求者通常会使用Bulk Leasequery以所有当前数据初始化其数据库。此外，如果与DHCPv6服务器的连接丢失的时间超过DHCPv6服务器跟踪IPv6绑定信息的特定更改的时间，则它将使用批量租赁服务来恢复丢失的信息。
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 OPTION_CLIENT_DATA and additional options
服务器为响应活动租赁请求而发送的消息应与服务器为批量租赁请求发送的关于数据编码到活动租赁响应中的方式的消息相同。此外，主动租赁请求者为解释对主动租赁请求的响应而采取的行动应与请求者解释对批量租赁请求的响应的方式相同。因此，处理OPTION_CLIENT_数据和其他选项
discussed in the Bulk Leasequery specification [RFC5460] 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 OPTION_CLIENT_DATA option even if they were requested by inclusion in the OPTION_ORO option.
在实施主动租赁时，应遵循批量租赁规范[RFC5460]中的讨论，例外情况是，响应活动租赁请求的服务器应能够配置为防止特定数据项包含在选项\u客户端\u数据选项中，即使这些数据项是通过包含在选项\u ORO选项中请求的。
Active Leasequery is an extension of the Bulk Leasequery protocol [RFC5460]. The format of messages returned to an Active Leasequery requestor is identical to that defined for the Bulk Leasequery protocol [RFC5460].
主动租赁是批量租赁协议[RFC5460]的扩展。返回给活动租赁请求者的消息格式与为批量租赁协议[RFC5460]定义的消息格式相同。
Applications that employ Active Leasequery to keep a database up to date with respect to the DHCPv6 server's lease state database should use an initial Bulk Leasequery to bring their database into equivalence with that of the DHCPv6 server and then use Active Leasequery to keep that database current with respect to the DHCPv6 server's lease state database.
使用Active Leasequery使数据库相对于DHCPv6服务器的租约状态数据库保持最新的应用程序应使用初始批量租约使其数据库与DHCPv6服务器的数据库等效，然后使用Active Leasequery使该数据库相对于DHCPv6服务器的租约状态保持最新数据库
There are several differences between the Active and Bulk Leasequery protocols. Active Leasequery defines a new message (ACTIVELEASEQUERY) to send Active Leasequery requests to the DHCPv6 server. An Active Leasequery connection sends all available updates to the requestor, based on the OPTION_LQ_QUERY option (see Section 6.2.1).
主动租赁协议和批量租赁协议之间存在一些差异。Active Leasequery定义一条新消息（ACTIVELEASEQUERY），用于向DHCPv6服务器发送活动Leasequery请求。活动的Leasequery连接根据选项“查询”选项（参见第6.2.1节）向请求者发送所有可用更新。
An Active Leasequery connection does not ever "complete", though the DHCPv6 server can close the connection for a variety of reasons associated with some sort of exception condition.
活动的Leasequery连接永远不会“完成”，尽管DHCPv6服务器可能会由于与某种异常情况相关的各种原因关闭连接。
This document extends the capabilities of the DHCPv6 Bulk Leasequery protocol [RFC5460] by defining new options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME, and OPTION_LQ_END_TIME). The DHCPv6 server sends the OPTION_LQ_BASE_TIME option in a Bulk Leasequery response if the requestor asked for the same in the Bulk Leasequery request. OPTION_LQ_START_TIME and OPTION_LQ_END_TIME can be used in a Bulk Leasequery request made to the DHCPv6 server. More details about these options are specified in Section 6.3.
本文档通过定义新选项（OPTION_LQ_BASE_TIME、OPTION_LQ_START_TIME和OPTION_LQ_END_TIME），扩展了DHCPv6批量租赁协议[RFC5460]的功能。如果请求者在批量租赁请求中请求相同的选项，DHCPv6服务器将在批量租赁响应中发送选项\u LQ\u BASE\u TIME选项。选项\u LQ\u开始时间和选项\u LQ\u结束时间可用于向DHCPv6服务器发出的批量租赁请求。有关这些选项的更多详细信息，请参见第6.3节。
The use of TCP for the Active Leasequery protocol permits one or more DHCPv6 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 message framing technique used for DHCPv6 Bulk Leasequery [RFC5460] is used for Active Leasequery as well.
将TCP用于主动租赁协议允许发送一条或多条DHCPv6消息以响应单个主动租赁请求。接收者需要能够确定每条消息的大小。DHCPv6批量租赁[RFC5460]使用的相同消息帧技术也用于活动租赁。
The intent in using the same format is that code that currently knows how to deal with a message returned from DHCPv6 Bulk Leasequery [RFC5460] will be able to deal with the message held inside of the TCP framing.
使用相同格式的目的是，当前知道如何处理从DHCPv6批量租赁[RFC5460]返回的消息的代码将能够处理TCP帧内保存的消息。
When using Transport Layer Security (TLS), once TLS negotiation completes, the connection will be encrypted and is now protected from eavesdropping, and normal Active Leasequery messages are sent and received using the TLS application data protocol services (see Section 10 of [RFC5246]).
当使用传输层安全性（TLS）时，一旦TLS协商完成，连接将被加密，现在可以防止窃听，并且使用TLS应用程序数据协议服务发送和接收正常的活动租赁消息（参见[RFC5246]第10节）。
The new message type (ACTIVELEASEQUERY) is designed for keeping the requestor up to date in real time (or near real time) with DHCPv6 bindings. It asks the server to return DHCPv6 binding activity that occurs subsequent to the receipt of the Active Leasequery request.
新的消息类型（ACTIVELEASEQUERY）设计用于通过DHCPv6绑定使请求者实时（或接近实时）保持最新。它要求服务器返回在收到活动的租赁请求后发生的DHCPv6绑定活动。
An ACTIVELEASEQUERY request MUST contain a transaction-id, and that transaction-id MUST be locally unique on the TCP connection on which it is sent to the DHCPv6 server.
ActiveLeaRequest请求必须包含事务id，并且该事务id在发送到DHCPv6服务器的TCP连接上必须是本地唯一的。
When sending an ACTIVELEASEQUERY request, the requestor MAY include the OPTION_LQ_START_TIME option in the ACTIVELEASEQUERY request. In this case, the DHCPv6 server returns all the bindings changed on or after the OPTION_LQ_START_TIME.
发送ACTIVELEASEQUERY请求时，请求者可能会在ACTIVELEASEQUERY请求中包含选项\u LQ\u START\u TIME选项。在这种情况下，DHCPv6服务器返回在选项_LQ _START _TIME时或之后更改的所有绑定。
If the requestor is interested in receiving all binding updates from the DHCPv6 server, it MUST NOT include the OPTION_LQ_QUERY option in the ACTIVELEASEQUERY message. But if the requestor is only interested in specific binding updates, it MAY include an OPTION_LQ_QUERY option along with a query-types defined in [RFC5007] and [RFC5460].
如果请求者有兴趣从DHCPv6服务器接收所有绑定更新，那么它不能在ActiveLeaRequesty消息中包含选项\u LQ\u QUERY选项。但是，如果请求者只对特定的绑定更新感兴趣，那么它可能包括一个选项\u LQ\u查询选项以及[RFC5007]和[RFC5460]中定义的查询类型。
Other DHCPv6 options used in the LEASEQUERY message (as specified in [RFC5460]) can also be used in the ACTIVELEASEQUERY message.
LEASEQUERY消息中使用的其他DHCPv6选项（如[RFC5460]中所述）也可用于ACTIVELEASEQUERY消息。
The new message type (STARTTLS) is designed for establishment of a TLS connection between a requestor and a DHCPv6 server. The STARTTLS message SHOULD be sent without any options. Any options received in a STARTTLS message SHOULD be ignored.
新的消息类型（STARTTLS）设计用于在请求者和DHCPv6服务器之间建立TLS连接。发送STARTTLS消息时应不带任何选项。应忽略STARTTLS消息中接收到的任何选项。
More details about this message are specified in Section 8.2.
有关此消息的更多详细信息，请参见第8.2节。
The LEASEQUERY-REPLY message is defined in [RFC5007]. The LEASEQUERY-DATA and LEASEQUERY-DONE messages are defined in [RFC5460].
[RFC5007]中定义了LEASQUERY-REPLY消息。[RFC5460]中定义了LEASEQUERY-DATA和LEASEQUERY-DONE消息。
In an Active Leasequery exchange, a single LEASEQUERY-REPLY message is used to indicate the success or failure of a query and to carry data that do not change in the context of a single query and answer, such as the Server-ID and Client-ID options. If a query is successful, the DHCPv6 server MUST respond to it with exactly one LEASEQUERY-REPLY message. If the server is returning binding data, the LEASEQUERY-REPLY also contains the first client's binding data in an OPTION_CLIENT_DATA option. Additional binding data is returned using a LEASEQUERY-DATA message as explained in DHCPv6 Bulk Leasequery [RFC5460]. In case of a query failure, a single LEASEQUERY-REPLY message is returned without any binding data.
在活动的Leasequery exchange中，单个Leasequery-REPLY消息用于指示查询的成功或失败，并携带在单个查询和应答上下文中不会更改的数据，例如服务器ID和客户端ID选项。如果查询成功，DHCPv6服务器必须仅用一条LEASEQUERY-REPLY消息响应查询。如果服务器正在返回绑定数据，那么LEASEQUERY-REPLY还将在OPTION\u client\u data选项中包含第一个客户端的绑定数据。如DHCPv6批量租赁[RFC5460]中所述，使用LEASEQUERY-data消息返回额外的绑定数据。如果查询失败，将返回一条没有任何绑定数据的LEASEQUERY-REPLY消息。
New options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME, and OPTION_LQ_END_TIME) are defined as an extension to DHCPv6 Bulk Leasequery [RFC5460]. The reply messages for Active Leasequery use these options along with the options defined in [RFC3315], [RFC5007], and [RFC5460].
新选项（选项基本时间、选项开始时间和选项结束时间）定义为DHCPv6批量租赁的扩展[RFC5460]。活动租赁的回复消息使用这些选项以及[RFC3315]、[RFC5007]和[RFC5460]中定义的选项。
The OPTION_LQ_BASE_TIME option is the current time the message was created to be sent by the DHCPv6 server to the requestor of the Active or Bulk Leasequery if the requestor asked for the same in an Active or Bulk Leasequery request. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC). All of the other time-based options in the reply message are relative to this time, including OPTION_CLT_TIME [RFC5007]. This time is in the context of the DHCPv6 server that placed this option in a message.
选项_LQ_BASE_TIME选项是创建消息的当前时间，如果请求者在活动或批量租赁请求中请求消息，则DHCPv6服务器将消息发送给活动或批量租赁请求者。这必须是绝对时间（即自UTC 2000年1月1日午夜起的秒数）。回复消息中所有其他基于时间的选项都与此时间相关，包括选项_CLT_time[RFC5007]。这一次是在DHCPv6服务器的上下文中，该服务器将此选项放置在消息中。
This is an unsigned integer in network byte order.
这是网络字节顺序的无符号整数。
The code for this option is 100.
此选项的代码为100。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_BASE_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| base-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_BASE_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| base-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_BASE_TIME (100) option-len 4 base-time DHCPv6 Server Base Time
选项代码选项LQ基本时间（100）选项len 4基本时间DHCPv6服务器基本时间
The OPTION_LQ_START_TIME option specifies a query start time to the DHCPv6 server. If specified, only bindings that have changed on or after the OPTION_LQ_START_TIME should be included in the response to the query. This option MAY be used in Active or Bulk Leasequery requests made to a DHCPv6 server.
选项_LQ_START_TIME指定DHCPv6服务器的查询开始时间。如果指定，则只有在选项_LQ _START _TIME时或之后更改的绑定才应包含在查询响应中。此选项可用于向DHCPv6服务器发出的活动或批量租赁请求。
The requestor MUST determine the OPTION_LQ_START_TIME using lease information it has received from the DHCPv6 server. This MUST be an absolute time in the DHCPv6 server's context (see Section 8.5).
请求者必须使用从DHCPv6服务器收到的租约信息来确定选项“开始时间”。这必须是DHCPv6服务器上下文中的绝对时间（请参阅第8.5节）。
Typically (though this is not a requirement), the OPTION_LQ_START_TIME option will contain the value most recently received in an OPTION_LQ_BASE_TIME option by the requestor, as this will indicate the last successful communication with the DHCPv6 server.
通常（尽管这不是要求），选项\u LQ\u START\u TIME选项将包含请求者最近在选项\u LQ\u BASE\u TIME选项中接收到的值，因为这将指示与DHCPv6服务器的最后一次成功通信。
This is an unsigned integer in network byte order.
这是网络字节顺序的无符号整数。
The code for this option is 101.
此选项的代码为101。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_START_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-start-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_START_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-start-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_START_TIME (101) option-len 4 query-start-time DHCPv6 Server Query Start Time
选项代码选项开始时间（101）选项len 4查询开始时间DHCPv6服务器查询开始时间
The OPTION_LQ_END_TIME option specifies a query end time to the DHCPv6 server. If specified, only bindings that have changed on or before the OPTION_LQ_END_TIME should be included in the response to the query. This option MAY be used in a Bulk Leasequery request, but it MUST NOT be used in an Active Leasequery request.
选项\u LQ\u END\u TIME选项指定DHCPv6服务器的查询结束时间。如果指定，则只有在选项_LQ _END _TIME时或之前更改的绑定才应包含在查询响应中。此选项可用于批量租赁请求，但不得用于活动租赁请求。
The requestor MUST determine the OPTION_LQ_END_TIME based on lease information it has received from the DHCPv6 server. This MUST be an absolute time in the context of the DHCPv6 server.
请求者必须根据从DHCPv6服务器接收到的租约信息确定选项“LQ”和“结束时间”。在DHCPv6服务器的上下文中，这必须是绝对时间。
In the absence of information to the contrary, the requestor SHOULD assume that the time context of the DHCPv6 server is identical to the time context of the requestor (see Section 8.5).
如果没有相反的信息，请求者应该假设DHCPv6服务器的时间上下文与请求者的时间上下文相同（参见第8.5节）。
This is an unsigned integer in network byte order.
这是网络字节顺序的无符号整数。
The code for this option is 102.
此选项的代码为102。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_END_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-end-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_END_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-end-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_END_TIME (102) option-len 4 query-end-time DHCPv6 Server Query End Time
选项代码选项\u LQ\u结束\u时间（102）选项len 4查询结束时间DHCPv6服务器查询结束时间
Active Leasequery uses the same port configuration as DHCPv6 Bulk Leasequery [RFC5460]. It also uses the other transmission parameters (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC5460].
主动租赁使用与DHCPv6批量租赁相同的端口配置[RFC5460]。它还使用[RFC5460]中定义的其他传输参数（大容量数据超时和大容量最大连接）。
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 and 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 secs | Active Leasequery receive |
| | | timeout |
| ACTIVE_LQ_SEND_TIMEOUT | 120 secs | Active Leasequery send |
| | | timeout |
| ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle |
| | | timeout |
+------------------------+----------+-------------------------------+
+------------------------+----------+-------------------------------+
| Parameter | Default | Description |
+------------------------+----------+-------------------------------+
| ACTIVE_LQ_RCV_TIMEOUT | 120 secs | Active Leasequery receive |
| | | timeout |
| ACTIVE_LQ_SEND_TIMEOUT | 120 secs | Active Leasequery send |
| | | timeout |
| ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle |
| | | timeout |
+------------------------+----------+-------------------------------+
While the information communicated by a DHCPv6 Bulk Leasequery [RFC5460] is taken directly from the DHCPv6 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 DHCPv6 server's lease state database.
虽然DHCPv6批量租赁[RFC5460]传递的信息直接取自DHCPv6服务器的租赁状态数据库，但活动租赁所传递的信息是实时信息。因此，它是当前与DHCPv6服务器的租约状态数据库中的特定绑定关联的信息。
This is of significance, because if the Active Leasequery requestor runs slowly or the requestor disconnects from the DHCPv6 server and then reconnects with an OPTION_LQ_START_TIME option (signaling a catch-up operation), the information communicated to the Active Leasequery requestor is only the most current information from the DHCPv6 server's lease state database.
这很重要，因为如果活动的租赁请求者运行缓慢，或者请求者与DHCPv6服务器断开连接，然后使用选项_LQ _START _TIME选项重新连接（发出追赶操作的信号），传递给活动租赁请求者的信息只是DHCPv6服务器租赁状态数据库中的最新信息。
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 DHCPv6 server is only required to transmit information about a binding that is current when the message is created and handed off to the TCP stack to send to the requestor.
活动租赁请求者不得假设每个租赁状态更改都通过活动租赁连接进行通信。即使活动的Leasequery请求者保持连接，DHCPv6服务器也只需要在创建消息并将其传递到TCP堆栈以发送给请求者时传输有关当前绑定的信息。
If the TCP connection blocks and the DHCPv6 server is waiting to send information down the connection, when the connection becomes available to be written, the DHCPv6 server MAY create the message 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连接阻塞，并且DHCPv6服务器正在等待通过该连接发送信息，则当该连接可供写入时，DHCPv6服务器可能会创建要在此时发送的消息。将发送绑定的当前状态，并且在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 DHCPv6 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
因此，主动租赁协议不允许请求者建立每个租赁上每个活动的完整历史记录。如果调整DHCPv6服务器的参数以考虑活动租赁请求者的要求，则可以创建租赁的重要状态更改的有效历史记录。例如，绑定到期或释放后的时间段可以配置得足够长（比如说几分钟，甚至更长）
the receive timeout), so that an Active Leasequery requestor would be less likely to miss any changes in the binding.
接收超时），以便活动的Leasequery请求者不太可能错过绑定中的任何更改。
A requestor attempts to establish a TCP connection to a DHCPv6 server in order to initiate an Active 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 6.4.
请求者试图建立到DHCPv6服务器的TCP连接，以启动活动的租赁交换。如果尝试失败，请求者可以重试。重试次数不应超过每活动\u LQ\u空闲\u超时一次。见第6.4节。
If an Active Leasequery is terminated prematurely by a LEASEQUERY-DONE with a DHCPv6 status code (carried in an OPTION_STATUS_CODE option) 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 6.4.
如果一个活动租赁被一个状态代码为QueryTerminated的DHCPv6状态代码（包含在选项_status_code选项中）的租赁结束提前终止，或者被提交的连接失败提前终止，请求者可以在创建新连接后重试请求。重试次数不应超过每活动\u LQ\u空闲\u超时一次。见第6.4节。
Messages from the DHCPv6 server come as multiple responses to a single ACTIVELEASEQUERY message. Thus, each ACTIVELEASEQUERY request MUST have a transaction-id unique on the connection on which it is sent, and all of the messages that come as a response to it contain the same transaction-id as the request.
来自DHCPv6服务器的消息是对单个ActiveLeaRequesty消息的多个响应。因此，每个ActiveLeaRequesty请求在其发送的连接上必须具有唯一的事务id，并且作为响应的所有消息都包含与请求相同的事务id。
A requestor SHOULD be able to operate in either insecure or secure mode. This MAY be a feature that is administratively controlled.
请求者应该能够在不安全或安全模式下操作。这可能是受管理控制的功能。
When operating in insecure mode, the requestor SHOULD proceed to send an ACTIVELEASEQUERY message after the establishment of a TCP connection.
在不安全模式下操作时，请求者应在建立TCP连接后继续发送ActiveLeaRequesty消息。
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] SHOULD be followed when negotiating this connection.
在安全模式下操作时，请求者必须尝试通过TCP连接协商TLS[RFC5246]连接。如果协商失败，请求者必须关闭TCP连接。协商此连接时，应遵循[RFC7525]中的建议。
A requestor requests the establishment of a TLS connection by sending the STARTTLS message to the DHCPv6 server as the first message over the TCP connection. This message indicates to the DHCPv6 server that a TLS connection over this TCP connection is desired. There are four possibilities after the requestor sends the STARTTLS message to the DHCPv6 server:
请求者通过TCP连接向DHCPv6服务器发送STARTTLS消息作为第一条消息，请求建立TLS连接。此消息向DHCPv6服务器指示需要通过此TCP连接进行TLS连接。请求者向DHCPv6服务器发送STARTTLS消息后，有四种可能：
1. No response from the DHCPv6 server.
1. DHCPv6服务器没有响应。
2. The DHCPv6 server closes the TCP connection after it receives the STARTTLS message.
2. DHCPv6服务器在收到STARTTLS消息后关闭TCP连接。
3. The DHCPv6 server responds with a REPLY [RFC3315] message with a DHCPv6 status code of TLSConnectionRefused.
3. DHCPv6服务器响应一条回复[RFC3315]消息，其中DHCPv6状态代码为TLSConnectionRejected。
4. The DHCPv6 server responds with a REPLY [RFC3315] message without a DHCPv6 status code, indicating success.
4. DHCPv6服务器响应一条回复[RFC3315]消息，但没有DHCPv6状态代码，表示成功。
In any of the first three possibilities, the DHCPv6 server can be assumed to not support TLS. In this case, the requestor MUST close the TCP connection.
在前三种可能性中，可以假设DHCPv6服务器不支持TLS。在这种情况下，请求者必须关闭TCP连接。
In the final possibility, where the DHCPv6 server has responded with a REPLY message without a DHCPv6 status code in response to the requestor's STARTTLS message, the requestor SHOULD initiate the exchange of the messages involved in a TLS handshake [RFC5246]. During the TLS handshake, the requestor MUST validate the DHCPv6 server's digital certificate.
在最后一种情况下，如果DHCPv6服务器响应请求者的STARTTLS消息时使用了没有DHCPv6状态代码的回复消息，则请求者应启动TLS握手中涉及的消息交换[RFC5246]。在TLS握手期间，请求者必须验证DHCPv6服务器的数字证书。
If the handshake exchange yields a functioning TLS connection, then the requestor SHOULD transmit an ACTIVELEASEQUERY request over that TLS connection and use that TLS connection for all further interactions in which it engages with the DHCPv6 server over this TCP connection.
如果握手交换产生一个正常工作的TLS连接，则请求者应通过该TLS连接发送ACTIVELEASEQUERY请求，并将该TLS连接用于通过该TCP连接与DHCPv6服务器进行的所有后续交互。
If the handshake exchange does not yield a functioning TLS connection, then the requestor MUST close the TCP connection.
如果握手交换没有产生正常工作的TLS连接，那么请求者必须关闭TCP连接。
Active Leasequery is designed to create a long-lived connection between the requestor and the DHCPv6 server processing the active query. The DHCPv6 server SHOULD send binding information back across this connection with minimal delay after it learns of the binding information. It learns about bindings either because it makes the bindings itself or because it has received information about a binding from another server.
Active Leasequery旨在创建请求者与处理活动查询的DHCPv6服务器之间的长期连接。DHCPv6服务器在获悉绑定信息后，应通过此连接以最小的延迟将绑定信息发送回。它了解绑定，要么是因为它自己创建绑定，要么是因为它从另一台服务器接收到关于绑定的信息。
An important capability of Active Leasequery is the ability of the requestor to 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 DHCPv6 server processing a previous Active Leasequery.
主动租赁的一个重要功能是请求者能够指定将一些最新数据立即发送给请求者，同时或多或少实时地传输正在进行的绑定信息。此功能用于允许活动租赁请求者在临时失去与处理先前活动租赁请求的DHCPv6服务器的连接时恢复丢失的信息。
This capability is enabled by the transmission of an OPTION_LQ_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 DHCPv6 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 DHCPv6 server, the requestor SHOULD place this highest base-time value into an OPTION_LQ_START_TIME option in the new Active Leasequery request.
此功能通过传输选项_LQ _BASE _TIME选项来启用，每个租赁回复都作为先前活动租赁的结果发送。请求者应跟踪通过活动租赁连接从特定DHCPv6服务器收到的最高基准时间，如果请求者发现有必要（无论出于何种原因）重新建立与该DHCPv6服务器的活动租赁连接，请求者应将此最高基准时间值放入新活动租赁请求中的选项\u LQ\u START\u time选项中。
Note that until all of the recent data (catch-up data) has been received, the requestor MUST NOT keep track of the base-time (OPTION_LQ_BASE_TIME) received in Leasequery reply messages to use later in a subsequent Active Leasequery request.
请注意，在收到所有最近的数据（追赶数据）之前，请求者不得跟踪在Leasequery回复消息中接收到的基准时间（OPTION_LQ_base_time），以便稍后在后续活动的Leasequery请求中使用。
If the requestor doesn't wish to request an update of information missed when it was not connected to the DHCPv6 server, then it SHOULD NOT include the OPTION_LQ_START_TIME option in the Active Leasequery request.
如果请求者不希望请求更新未连接到DHCPv6服务器时丢失的信息，则不应在活动租赁请求中包含选项_LQ _START _TIME。
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 DHCPv6 LEASEQUERY-REPLY message from the TCP connection. If the stream of replies becomes blocked, the requestor SHOULD terminate the connection after ACTIVE_LQ_RCV_TIMEOUT and MAY begin retry processing if configured to do so.
请求者尝试从TCP连接读取DHCPv6 LEASEQUERY-REPLY消息。如果回复流被阻塞，请求者应在活动\u LQ\u RCV\u超时后终止连接，如果配置为这样做，则可以开始重试处理。
The requestor examines the LEASEQUERY-REPLY message and determines how to proceed. Message validation rules are specified in DHCPv6 Leasequery [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460]. If the reply contains a DHCPv6 status code (carried in an OPTION_STATUS_CODE option), the requestor should follow the recommendations in [RFC5007].
请求者检查LEASEQUERY-REPLY消息并确定如何继续。消息验证规则在DHCPv6租约[RFC5007]和DHCPv6批量租约[RFC5460]中指定。如果回复包含DHCPv6状态代码（包含在选项_status_code选项中），请求者应遵循[RFC5007]中的建议。
Note that the connection resulting from accepting an Active Leasequery request may be long-lived and may not have data transferring continuously during its lifetime. Therefore, the DHCPv6 server SHOULD send a LEASEQUERY-DATA message without binding data (OPTION_CLIENT_DATA) 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 connection is idle (i.e.,
请注意，接受活动租赁请求所产生的连接可能是长期存在的，并且在其生存期内可能没有连续的数据传输。因此，DHCPv6服务器应该在每个活动的空闲超时秒（默认值60）发送一个不绑定数据（选项客户机数据）的LEASEQUERY-DATA消息，以便请求者知道连接保持活动状态。仅当连接空闲时（即。，
server has no binding data to send). During a normal exchange of binding data, receiving a LEASEQUERY-DATA message signifies that 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 DHCPv6 server to send messages. Thus, ACTIVE_LQ_RCV_TIMEOUT controls how sensitive the requestor is to delays by the DHCPv6 server in sending updates or LEASEQUERY-DATA messages.
服务器没有要发送的绑定数据）。在绑定数据的正常交换期间，收到LEASEQUERY-data消息表示连接处于活动状态。请注意，活动\u LQ\u RCV\u超时的默认值为120秒，是活动\u LQ\u空闲\u超时的默认值60秒的两倍，该值驱动DHCPv6服务器发送消息。因此，ACTIVE_LQ_RCV_TIMEOUT控制请求者在发送更新或LEASEQUERY-DATA消息时对DHCPv6服务器延迟的敏感程度。
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 ACTIVELEASEQUERY message from a single DHCPv6 server.
一个活动的租赁请求可以并且通常会导致大量的回复。请求者必须准备好从单个DHCPv6服务器接收多个具有与单个ActiveLeaRequesty消息匹配的事务ID的回复。
An Active Leasequery has two regimes: during the catch-up phase (if any) and after any catch-up phase. If the Active Leasequery was requested with an OPTION_LQ_START_TIME option, the Active Leasequery starts out in the catch-up phase. See Section 8.4.1 for information on processing during the catch-up phase, as well as how to determine when the catch-up phase is complete.
主动租赁有两种制度：追赶阶段期间（如有）和追赶阶段之后。如果主动租赁请求带有选项\u LQ\u START\u TIME选项，则主动租赁将在追赶阶段开始。关于追赶阶段的处理信息，以及如何确定追赶阶段何时完成，请参见第8.4.1节。
The updates sent by the DHCPv6 server during the catch-up phase are not in the order that the lease state data was updated. Therefore, the OPTION_LQ_BASE_TIME option from messages during this phase MUST NOT be saved and used to compute the subsequent ACTIVELEASEQUERY message's OPTION_LQ_START_TIME option.
DHCPv6服务器在追赶阶段发送的更新不符合租约状态数据的更新顺序。因此，不得保存此阶段消息中的选项\u LQ\u BASE\u TIME选项，并将其用于计算后续ACTIVELEASEQUERY消息的选项\u LQ\u START\u TIME选项。
After the catch-up phase, or during the entire series of messages received as the response to an Active Leasequery request with no OPTION_LQ_START_TIME (and therefore no catch-up phase), the OPTION_LQ_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 DHCPv6 server) can be used in a subsequent Active Leasequery message's OPTION_LQ_START_TIME after a loss of the Active Leasequery connection.
在赶超阶段之后，或在作为对活动租赁请求的响应而接收的整个消息系列期间，没有选项\u LQ\u开始时间（因此没有赶超阶段），最近消息的选项\u LQ\u基本时间选项应保存为最近接收数据时间的记录。此基准时间（在DHCPv6服务器的上下文中）可用于活动租赁服务连接丢失后后续活动租赁服务消息的选项\u LQ\u START\u time中。
The LEASEQUERY-DONE message MAY unilaterally terminate a successful Active Leasequery request that is currently in progress in the event that the DHCPv6 server determines that it cannot continue processing an Active Leasequery request. For example, when a server is requested to shut down, it SHOULD send a LEASEQUERY-DONE message with a DHCPv6 status code of QueryTerminated and include the OPTION_LQ_BASE_TIME option in the message. This MUST be the last message on that connection, and once the message has been transmitted, the server MUST close the connection.
如果DHCPv6服务器确定无法继续处理活动租赁请求，则LEASEQUERY-DONE消息可能会单方面终止当前正在进行的成功活动租赁请求。例如，当服务器被请求关闭时，它应该发送一条LEASEQUERY-DONE消息，DHCPv6状态代码为QueryTerminated，并在消息中包含选项_LQ_BASE_TIME选项。这必须是该连接上的最后一条消息，消息传输完毕后，服务器必须关闭连接。
After receiving LEASEQUERY-DONE with a QueryTerminated status from a server, the requestor MAY close the TCP connection to that server.
在从服务器接收到带有QueryTerminated状态的LEASEQUERY-DONE后，请求者可以关闭与该服务器的TCP连接。
8.4.1. Processing Replies from a Request Containing an OPTION_LQ_START_TIME
8.4.1. 处理来自包含选项“开始时间”的请求的答复
If the Active Leasequery was requested with an OPTION_LQ_START_TIME option, the DHCPv6 server will attempt to send information about all bindings that changed since the time specified in the OPTION_LQ_START_TIME. This is the catch-up phase of the Active Leasequery processing. The DHCPv6 server MAY also send information about real-time binding updates over the same connection. Thus, the catch-up phase can run in parallel with the normal updates generated by the Active Leasequery request.
如果使用选项_LQ _START _TIME请求活动租赁，DHCPv6服务器将尝试发送自选项_LQ _START _TIME中指定的时间以来更改的所有绑定的信息。这是主动租赁请求处理的追赶阶段。DHCPv6服务器还可以通过同一连接发送有关实时绑定更新的信息。因此，追赶阶段可以与活动租赁请求生成的正常更新并行运行。
A DHCPv6 server MAY keep only a limited amount of time-ordered information available to respond to an Active Leasequery request containing an OPTION_LQ_START_TIME option. Thus, it is possible that the time specified in the OPTION_LQ_START_TIME option represents a time not covered by the time-ordered information kept by the DHCPv6 server. In such case, when there is not enough data saved in the DHCPv6 server to satisfy the request specified by the OPTION_LQ_START_TIME option, the DHCPv6 server will reply immediately with a LEASEQUERY-REPLY message with a DHCPv6 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 Active Leasequery request.
DHCPv6服务器可能仅保留有限的时间顺序信息，以响应包含选项\u LQ\u START\u time选项的活动租赁请求。因此，选项_LQ _START _time选项中指定的时间可能表示DHCPv6服务器保存的时序信息未涵盖的时间。在这种情况下，当DHCPv6服务器中保存的数据不足，无法满足选项_LQ_START_TIME选项指定的请求时，DHCPv6服务器将立即回复一条LEASEQUERY-reply消息，其中DHCPv6状态代码为DataMissing，基本时间选项等于服务器的当前时间。这将标志着追赶阶段的结束，随后在此连接上接收到的唯一更新是来自活动租赁请求的实时更新。
If there is enough data saved to satisfy the request, then LEASEQUERY-REPLY (with OPTION_STATUS_CODE of Success or reply without the OPTION_STATUS_CODE option) and LEASEQUERY-DATA messages will begin to arrive from the DHCPv6 server. Some of these messages will be related to the OPTION_LQ_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 DHCPv6 server. In general, there is no way to determine the source of each message.
如果保存了足够的数据以满足请求，则LEASEQUY-REPLY（带有选项\u STATUS\u成功代码或REPLY（不带选项\u STATUS\u代码选项））和LEASEQUY-data消息将开始从DHCPv6服务器到达。其中一些消息将与选项LQ启动时间请求相关，并且是追赶阶段的一部分。其中一些消息将是DHCPv6服务器中发生的绑定更改的实时更新。一般来说，没有办法确定每条消息的来源。
The updates sent by the DHCPv6 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 DHCPv6 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 Active Leasequery were to terminate prior to the completion of the catch-up phase.
DHCPv6服务器在追赶阶段发送的更新与绑定数据的更新顺序不一致。因此，在追赶阶段完成之前，从处理活动租赁请求的DHCPv6服务器接收到的最新基本时间值无法从传入消息中重置（并在后续活动租赁请求的查询开始时间选项中使用），因为如果主动租赁权在追赶阶段完成之前终止，那么这样做将损害恢复丢失信息的能力。
The requestor will know that the catch-up phase is complete when the DHCPv6 server transmits a LEASEQUERY-DATA message with the DHCPv6 status code of CatchUpComplete (or a LEASEQUERY-REPLY message with a
当DHCPv6服务器发送DHCPv6状态代码为CatchUpComplete的LEASEQUERY-DATA消息（或带有
DHCPv6 status code of DataMissing, as discussed above). Once this message is transmitted, all additional LEASEQUERY-DATA messages will relate to real-time ("new") binding changes in the DHCPv6 server.
数据丢失的DHCPv6状态代码（如上所述）。传输此消息后，所有其他LEASEQUERY-DATA消息将与DHCPv6服务器中的实时（“新”）绑定更改相关。
As discussed in Section 8.4, the requestor SHOULD keep track of the latest base-time option value received over a particular connection, to be used in a subsequent Active Leasequery 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 LEASEQUERY-DONE 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.
如第8.4节所述，请求者应跟踪通过特定连接接收到的最新基准时间选项值，以便在后续活动租赁请求中使用，但前提是追赶阶段已完成。在追赶阶段完成之前，如果连接应该消失，或者如果请求者接收到LEASEQUERY-DONE消息，那么当它重新连接时，它必须使用来自上一个连接的基本时间值，而不是来自最近关闭的连接的任何基本时间值。
In the event that there was enough data available to the DHCPv6 server to begin to satisfy the request implied by the OPTION_LQ_START_TIME option but during the processing of that data, the server found that it was unable to continue (during transmission, the aging algorithm causes [some of] the saved data to become unavailable), the DHCPv6 server will terminate the catch-up phase of processing immediately by sending a LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing and with a base-time option of the current time.
如果DHCPv6服务器有足够的可用数据开始满足选项_LQ _START _TIME选项暗示的请求，但在处理该数据期间，服务器发现无法继续（在传输期间，老化算法导致[部分]保存的数据变为不可用），DHCPv6服务器将通过发送一条LEASEQUERY-DATA消息立即终止处理的追赶阶段，该消息的DHCPv6状态代码为DataMissing，基本时间选项为当前时间。
The requestor MUST NOT assume that every individual state change of every binding during the period from the time specified in the OPTION_LQ_START_TIME and the present is replicated in an Active Leasequery reply message. 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 OPTION_LQ_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.
请求者不得假设从选项_LQ _START _time中指定的时间到当前的时间段内，每个绑定的每个单独状态更改都会复制到活动的Leasequery回复消息中。请求者可以假设，对于在选项_LQ _START _TIME和当前时间指定的时间段内具有一个或多个状态更改的每个绑定，将存在至少一个活动的Leasequery回复消息。每个绑定的最后一条消息将包含当前的状态，在处理的追赶阶段，可能有一条或多条消息涉及单个绑定。
Bindings can change multiple times while the requestor is not connected (that is, during the time from the OPTION_LQ_START_TIME to the present). 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 OPTION_LQ_START_TIME to the present.
当请求者未连接时（即从选项\u LQ\u START\u time到现在），绑定可以更改多次。请求者只会收到关于绑定当前状态的信息，而不会收到关于从选项开始到现在期间发生的每个状态更改的信息。
If the LEASEQUERY-REPLY or LEASEQUERY-DATA message containing a DHCPv6 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 bindings in the DHCPv6 server, then the requestor SHOULD issue a Bulk Leasequery request to recover the information missing from its database. This Bulk Leasequery request SHOULD include an OPTION_LQ_START_TIME option with the same value as the
如果收到包含DataMissing的DHCPv6状态代码的LEASEQUY-REPLY或LEASEQUY-DATA消息，并且请求者希望保持其数据库与DHCPv6服务器中绑定的当前状态相关的最新状态，然后，请求者应该发出批量请求，以恢复其数据库中丢失的信息。此批量租赁请求应包含一个选项\u LQ\u START\u TIME选项，该选项的值与
OPTION_LQ_START_TIME option previously included in the Active Leasequery responses from the DHCPv6 server and an OPTION_LQ_END_TIME option equal to the OPTION_LQ_BASE_TIME option returned by the DHCPv6 server in the LEASEQUERY-REPLY or LEASEQUERY-DATA message with the DHCPv6 status code of DataMissing.
选项_LQ_START_TIME选项之前包含在DHCPv6服务器的活动租赁响应中，选项_LQ_END_TIME选项等于DHCPv6服务器在租赁回复或租赁数据消息中返回的选项_LQ_BASE_TIME选项，DHCPv6状态代码为DataMissing。
Typically, the requestor would have one connection open to a DHCPv6 server for an Active Leasequery request and possibly one additional connection open for a Bulk Leasequery request to the same DHCPv6 server to fill in the data that might have been missed prior to the initiation of the Active Leasequery. The Bulk Leasequery connection would typically run to completion and be closed, leaving one Active Leasequery connection open to a single DHCPv6 server.
通常，请求者将为活动租赁请求打开一个到DHCPv6服务器的连接，并可能为到同一DHCPv6服务器的批量租赁请求打开一个额外的连接，以填充在启动活动租赁请求之前可能丢失的数据。批量Leasequery连接通常会运行到完成并关闭，从而使一个活动的Leasequery连接对单个DHCPv6服务器保持打开状态。
Active or Bulk Leasequery requests can be made to a DHCPv6 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 Active or Bulk Leasequery response.
可以向DHCPv6服务器发出活动或批量租赁请求，该服务器的绝对时间可能与请求者的本地时间不同步。因此，即使是最简单的活动或批量请求响应，也至少有两个时间上下文。
If the requestor of an Active or 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 DHCPv6 server.
如果活动或批量租赁请求者正在保存以某种形式返回的数据，则需要存储各种时间值；其中一些是请求者上下文中的时间，一些是DHCPv6服务器上下文中的时间。
When receiving an Active or Bulk Leasequery reply message from the DHCPv6 server, the message will contain an OPTION_LQ_BASE_TIME option. The time contained in this OPTION_LQ_BASE_TIME option is in the context of the DHCPv6 server. As such, it is an ideal time to save and use as input to an Active or Bulk Leasequery message in the OPTION_LQ_START_TIME or OPTION_LQ_END_TIME options should the requestor need to ever issue an Active or Bulk Leasequery message using these options as part of a later query, since these options require a time in the context of the DHCPv6 server.
从DHCPv6服务器接收活动或批量租赁回复消息时，该消息将包含选项\u LQ\u BASE\u TIME选项。此选项\u LQ\u BASE\u time选项中包含的时间在DHCPv6服务器的上下文中。因此，如果请求者需要在以后的查询中使用这些选项发出活动或批量租赁消息（因为这些选项在DHCPv6服务器的上下文中需要一段时间），那么在选项\u LQ\u START\u time或选项\u LQ\u END\u time选项中保存并用作活动或批量租赁消息的输入是一个理想的时间。
In addition to saving the OPTION_LQ_BASE_TIME for possible future use in the OPTION_LQ_START_TIME or OPTION_LQ_END_TIME options, the OPTION_LQ_BASE_TIME option 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.
除了保存选项_LQ_BASE_TIME以备将来在选项_LQ_START_TIME或选项_LQ_END_TIME选项中使用外，选项_LQ_BASE_TIME选项还用于将Leasequery消息中的其他时间转换为在请求者上下文中有意义的值。
In systems whose clocks are synchronized, perhaps using the Network Time Protocol (NTP), the clock skew will usually be zero, which is not only acceptable, but desired.
在时钟同步的系统中，可能使用网络时间协议（NTP），时钟偏差通常为零，这不仅是可以接受的，而且是需要的。
These examples illustrate what a series of queries and responses might look like. These are only examples -- there is no requirement that these sequences must be followed.
这些示例说明了一系列查询和响应可能是什么样子。这些只是示例——不要求必须遵循这些顺序。
This example illustrates the message flows in case the DHCPv6 server identifies that it cannot accept and/or process an Active Leasequery request from the requestor. This could be because of various reasons (i.e., UnknownQueryType, MalformedQuery, NotConfigured, NotAllowed, and NotSupported).
此示例说明了DHCPv6服务器无法接受和/或处理来自请求者的活动租赁请求时的消息流。这可能是由于各种原因造成的（例如，UnknownQueryType、格式错误的查询、NotConfigured、NotAllowed和NotSupported）。
Client Server
------ ------
ACTIVELEASEQUERY xid 1 ----->
<----- LEASEQUERY-REPLY xid 1 (w/error)
Client Server
------ ------
ACTIVELEASEQUERY xid 1 ----->
<----- LEASEQUERY-REPLY xid 1 (w/error)
This example illustrates the message flows in case the DHCPv6 server identifies that it does not have enough data saved to satisfy the request specified by the OPTION_LQ_START_TIME option.
此示例说明了DHCPv6服务器发现其保存的数据不足，无法满足选项\u LQ\u START\u TIME选项指定的请求时的消息流。
In this case, the DHCPv6 server will reply immediately with a LEASEQUERY-REPLY message with a DHCPv6 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 Active Leasequery request.
在这种情况下，DHCPv6服务器将立即回复一条LEASEQUERY-reply消息，其中DHCPv6状态代码为DataMissing，基本时间选项等于服务器的当前时间。这将标志着追赶阶段的结束，随后在此连接上接收到的唯一更新是来自活动租赁请求的实时更新。
Client Server
------ ------
ACTIVELEASEQUERY xid 2 ----->
<----- LEASEQUERY-REPLY xid 2 (w/error)
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2
Client Server
------ ------
ACTIVELEASEQUERY xid 2 ----->
<----- LEASEQUERY-REPLY xid 2 (w/error)
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2
This example illustrates the message flows in case of successful query processing by the DHCPv6 server.
此示例演示了DHCPv6服务器成功处理查询时的消息流。
In this case, the DHCPv6 server will reply immediately with a LEASEQUERY-REPLY message (with OPTION_STATUS_CODE of Success or reply without OPTION_STATUS_CODE option), followed by binding data in
在这种情况下，DHCPv6服务器将立即回复一条LEASEQUERY-reply消息（带有选项\u STATUS\u CODE of Success或reply而不带有选项\u STATUS\u CODE选项），然后在中绑定数据
LEASEQUERY-DATA messages. In case the DHCPv6 server wants to abort an in-process request and terminate the connection due to some reason, it sends LEASEQUERY-DONE with an error code present in the OPTION_STATUS_CODE option.
LEASEQUERY-DATA消息。如果DHCPv6服务器由于某种原因想要中止进程内请求并终止连接，它将发送LEASEQUERY-DONE，并在选项_STATUS_code选项中显示错误代码。
Client Server
------ ------
ACTIVELEASEQUERY xid 3 ----->
<----- LEASEQUERY-REPLY xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DONE xid 3 (w/error)
Client Server
------ ------
ACTIVELEASEQUERY xid 3 ----->
<----- LEASEQUERY-REPLY xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DONE xid 3 (w/error)
The requestor or DHCPv6 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.
请求者或DHCPv6 Leasequery服务器可随时关闭其TCP连接端。如果请求者打算发出附加查询，则可以选择保留连接。请注意，此请求者行为并不保证连接可用于其他查询：服务器可能会根据自己的配置决定关闭连接。
A DHCPv6 server that supports Active Leasequery MUST support DHCPv6 Bulk Leasequery [RFC5460] along with the updates mentioned in this document.
支持活动租赁的DHCPv6服务器必须支持DHCPv6批量租赁[RFC5460]以及本文档中提到的更新。
DHCPv6 servers that implement DHCPv6 Active Leasequery listen for incoming TCP connections. The approach used in accepting the requestor's connection is the same as specified in DHCPv6 Bulk Leasequery [RFC5460], 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.
实现DHCPv6 Active Leasequery的DHCPv6服务器侦听传入的TCP连接。接受请求者连接时使用的方法与DHCPv6批量租赁[RFC5460]中规定的方法相同，但默认情况下不得启用对活动租赁的支持，并且必须在其运行之前执行明确的配置步骤。
DHCPv6 servers SHOULD be able to operate in either insecure or secure mode. 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.
DHCPv6服务器应该能够在不安全或安全模式下运行。这可能是一种管理控制的模式，其中服务器需要TLS连接才能运行，或者仅在没有TLS连接的情况下运行。在这两种情况下，即使不支持在安全模式下的操作，在不安全模式下的操作也不能是默认操作。在不安全模式下的操作必须始终需要明确的配置步骤，与支持活动租赁所需的配置步骤分开。
When operating in insecure mode, the DHCPv6 server simply waits for the requestor to send the Active Leasequery request after the establishment of a TCP connection. If it receives a STARTTLS message, it MUST respond with a REPLY [RFC3315] message with a DHCPv6 status code of TLSConnectionRefused.
在不安全模式下运行时，DHCPv6服务器只需等待请求者在建立TCP连接后发送活动的Leasequery请求。如果接收到STARTTLS消息，则必须以回复[RFC3315]消息响应，DHCPv6状态代码为TLSConnectionRejected。
When operating in secure mode, DHCPv6 servers MUST support TLS [RFC5246] to protect the integrity and privacy of the data transmitted over the TCP connection. When operating in secure mode, DHCPv6 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.
在安全模式下运行时，DHCPv6服务器必须支持TLS[RFC5246]，以保护通过TCP连接传输的数据的完整性和隐私。在安全模式下运行时，DHCPv6服务器必须可配置，以便与哪些请求者通信。请求者在启动TLS连接时提供的证书用于区分可接受和不可接受的请求者。
When operating in secure mode, the DHCPv6 server MUST begin to negotiate a TLS connection with a requestor who asks for one and MUST close the TCP connections that are not secured with TLS or for which the requestor's certificate is deemed unacceptable. The recommendations in [RFC7525] SHOULD be followed when negotiating a TLS connection.
在安全模式下运行时，DHCPv6服务器必须开始与请求TLS连接的请求者协商TLS连接，并且必须关闭未使用TLS进行安全保护或请求者证书被视为不可接受的TCP连接。协商TLS连接时，应遵循[RFC7525]中的建议。
A requestor will request a TLS connection by sending a STARTTLS as the first message over a newly created TCP connection. If the DHCPv6 server supports TLS connections and has not been configured to not allow them on this link, the DHCPv6 server MUST respond to this STARTTLS message by sending a REPLY [RFC3315] message without a DHCPv6 status code back to the requestor. This indicates to the requestor that the DHCPv6 server will support the negotiation of a TLS connection over this existing TCP connection.
请求者将通过在新创建的TCP连接上发送STARTTLS作为第一条消息来请求TLS连接。如果DHCPv6服务器支持TLS连接，并且尚未配置为不允许在该链接上使用TLS连接，则DHCPv6服务器必须通过向请求者发送不带DHCPv6状态代码的回复[RFC3315]消息来响应此STARTTLS消息。这向请求者指示DHCPv6服务器将支持通过现有TCP连接协商TLS连接。
If for some reason the DHCPv6 server cannot support a TLS connection or has been configured to not support a TLS connection, then it SHOULD send a REPLY message with a DHCPv6 status code of TLSConnectionRefused back to the requestor.
如果由于某种原因DHCPv6服务器无法支持TLS连接或已配置为不支持TLS连接，则它应将带有DHCPv6状态代码TLSConnectionRejected的回复消息发送回请求者。
In the event that the DHCPv6 server sends a REPLY message without a DHCPv6 status code option included (which indicates success), the requestor is supposed to initiate a TLS handshake [RFC5246] (see Section 8.2). During the TLS handshake, the DHCPv6 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.
如果DHCPv6服务器发送的回复消息中未包含DHCPv6状态代码选项（表示成功），则请求者应启动TLS握手[RFC5246]（参见第8.2节）。在TLS握手期间，DHCPv6服务器必须验证请求者的数字证书。此外，请求者提供的数字证书用于决定是否允许该请求者执行活动租赁请求。如果认为此请求者的证书不可接受，服务器必须中止TLS连接的创建。
All TLS connections established between a requestor and a DHCPv6 server for the purposes of supporting Active Leasequery MUST be mutually authenticated.
为了支持主动租赁，请求者和DHCPv6服务器之间建立的所有TLS连接必须经过相互验证。
If the TLS handshake is not successful in creating a TLS connection, the server MUST close the TCP connection.
如果TLS握手未能成功创建TLS连接，则服务器必须关闭TCP连接。
Servers that do not implement DHCPv6 Active and Bulk Leasequery SHOULD NOT listen for incoming TCP connections for these requests.
未实现DHCPv6 Active和Bulk Leasequery的服务器不应侦听这些请求的传入TCP连接。
If the DHCPv6 server supporting Bulk Leasequery and not Active Leasequery receives an Active Leasequery request, it SHOULD send a LEASEQUERY-REPLY with a DHCPv6 status code of NotSupported. It SHOULD close the TCP connection after this error is signaled.
如果支持批量租赁和非活动租赁的DHCPv6服务器收到活动租赁请求，则应发送状态代码为NotSupported的租赁回复。发出此错误信号后，它应关闭TCP连接。
The DHCPv6 Leasequery [RFC5007] specification describes the initial construction of LEASEQUERY-REPLY messages. Use of the LEASEQUERY-REPLY and LEASEQUERY-DATA messages to carry multiple bindings is described in DHCPv6 Bulk Leasequery [RFC5460]. Message transmission and framing for TCP is described in Section 6.1.
DHCPv6 Leasequery[RFC5007]规范描述了Leasequery-REPLY消息的初始构造。DHCPv6批量租赁[RFC5460]中描述了使用LEASEQUY-REPLY和LEASEQUY-DATA消息来承载多个绑定。第6.1节描述了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 for how long the DHCPv6 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 DHCPv6 server SHOULD close the TCP connection.
如果在服务器尝试发送回复消息时连接被阻止，则服务器应在活动\u LQ\u发送\u超时后终止TCP连接。此超时控制DHCPv6服务器准备等待请求者读取和处理足够信息以解除TCP连接阻塞的时间。默认值为两分钟，这意味着如果超过两分钟，请求者没有读取足够的信息来解除TCP连接的阻塞，DHCPv6服务器应该关闭TCP连接。
If the DHCPv6 server encounters an error during the initial processing of the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-REPLY message containing an error code of some kind in a DHCPv6 status code option. It SHOULD close the connection after this error is signaled.
如果DHCPv6服务器在初始处理ACTIVELEASEQUERY消息期间遇到错误，则应发送包含DHCPv6状态代码选项中某种类型错误代码的LEASEQUERY-REPLY消息。它应该在发出此错误信号后关闭连接。
If the DHCPv6 server encounters an error during later processing of the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-DONE containing an error code of some kind in a DHCPv6 status code option. It SHOULD close the connection after this error is signaled.
如果DHCPv6服务器在以后处理ACTIVELEASEQUERY消息时遇到错误，它应该发送一个包含DHCPv6状态代码选项中某种错误代码的LEASEQUERY-DONE。它应该在发出此错误信号后关闭连接。
If the server finds any bindings satisfying a query, it SHOULD send each binding's data in a reply message. The first reply message is a LEASEQUERY-REPLY. The binding data is carried in an OPTION_CLIENT_DATA option, as specified in [RFC5007]. The server SHOULD send subsequent bindings in LEASEQUERY-DATA messages, which can avoid redundant data (such as the requestor's Client-ID).
如果服务器发现任何满足查询的绑定，它应该在回复消息中发送每个绑定的数据。第一条回复消息是LEASEQUERY-reply。按照[RFC5007]中的规定，绑定数据在选项\客户端\数据选项中携带。服务器应该在LEASEQUERY-DATA消息中发送后续绑定，这样可以避免冗余数据（例如请求者的客户端ID）。
Every reply to an Active Leasequery request MUST contain the information specified in replies to a DHCPv6 Bulk Leasequery request [RFC5460], 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 OPTION_ORO option.
对活动租赁请求的每个回复必须包含对DHCPv6批量租赁请求[RFC5460]的回复中指定的信息，例外情况是，实现Active Leasequery的服务器应能够配置为防止向请求者发送特定数据项，即使这些数据项是在选项_ORO选项中请求的。
Some servers can be configured to respond to a DHCPv6 Leasequery [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460] for an IPv6 binding that is reserved in such a way that it appears that the IPv6 binding is leased to the DHCP client for which it is reserved. These servers SHOULD also respond to an Active Leasequery request with the same information as they would to a Bulk Leasequery request when they first determine that the IPv6 binding is reserved to a DHCP client.
一些服务器可以配置为对保留的IPv6绑定响应DHCPv6 Leasequery[RFC5007]和DHCPv6 Bulk Leasequery[RFC5460]，其保留方式似乎是将IPv6绑定租给保留该绑定的DHCP客户端。当这些服务器首次确定IPv6绑定保留给DHCP客户端时，它们还应使用与批量租赁请求相同的信息响应活动租赁请求。
If an Active Leasequery or Bulk Leasequery request contains the OPTION_LQ_BASE_TIME option code present in OPTION_ORO, the DHCPv6 server MUST include the OPTION_LQ_BASE_TIME option in every reply for this request. The value for the base-time option is the current absolute time in the DHCPv6 server's context.
如果活动租赁请求或批量租赁请求包含OPTION_ORO中的OPTION_LQ_BASE_TIME选项代码，则DHCPv6服务器必须在该请求的每个答复中包含OPTION_LQ_BASE_TIME选项。基本时间选项的值是DHCPv6服务器上下文中的当前绝对时间。
If an Active Leasequery request contains an OPTION_LQ_START_TIME option, it indicates that the requestor would like the DHCPv6 server to send it not only messages that correspond to DHCPv6 binding activity that occurs subsequent to the receipt of the Active Leasequery request, but also messages that correspond to DHCPv6 binding activity that occurred prior to the Active Leasequery request.
如果活动租赁请求包含选项_LQ _START _TIME选项，则表明请求者希望DHCPv6服务器不仅向其发送与收到活动租赁请求后发生的DHCPv6绑定活动相对应的消息，但也包括与活动的Leasequery请求之前发生的DHCPv6绑定活动相对应的消息。
If the OPTION_LQ_END_TIME option appears in an Active Leasequery request, the DHCPv6 server SHOULD send a LEASEQUERY-REPLY message with a DHCPv6 status code of MalformedQuery and terminate the connection.
如果在活动的Leasequery请求中出现选项\u LQ\u END\u TIME选项，DHCPv6服务器应发送带有格式错误查询的DHCPv6状态代码的Leasequery-REPLY消息，并终止连接。
In order to implement a meaningful response to this query, the DHCPv6 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 an Active Leasequery request containing a OPTION_LQ_START_TIME option, the DHCPv6 server can respond with replies for all binding activity occurring on that OPTION_LQ_START_TIME or later times.
为了实现对此查询的有意义的响应，DHCPv6服务器可以跟踪绑定活动，并将更改与消息中的特定基本时间值相关联。然后，当包含选项\u LQ\u START\u TIME选项的活动租赁请求请求执行此操作时，DHCPv6服务器可以对该选项\u LQ\u START\u TIME或更晚时间发生的所有绑定活动作出响应。
These replies based on the OPTION_LQ_START_TIME MAY be interleaved with the messages generated due to current binding activity.
这些基于选项_LQ _START _TIME的回复可能与由于当前绑定活动而生成的消息交错。
Once the transmission of the DHCPv6 Leasequery messages associated with the OPTION_LQ_START_TIME option are complete, a LEASEQUERY-DATA message MUST be sent with a DHCPv6 status code value of CatchUpComplete.
一旦与选项_LQ _START _TIME选项相关联的DHCPv6 Leasequery消息传输完成，必须发送一条Leasequery-DATA消息，其中DHCPv6状态代码值为CatchUpComplete。
The DHCPv6 server SHOULD, but is not required to, keep track of a limited amount of previous binding activity. The DHCPv6 server MAY choose to only do this in the event that it has received at least one Active Leasequery request in the past, as to do so will almost certainly entail some utilization of resources that would be wasted if there are no Active Leasequery requestors for this DHCPv6 server. The DHCPv6 server SHOULD make the amount of previous binding activity it retains configurable. There is no requirement on the DHCPv6 server to retain this information over a server restart (or even to retain such information at all).
DHCPv6服务器应该（但不是必须）跟踪有限数量的以前的绑定活动。DHCPv6服务器可以选择仅在其过去至少收到一个活动租赁请求的情况下执行此操作，因为这样做几乎肯定会导致一些资源的利用，如果此DHCPv6服务器没有活动租赁请求者，这些资源将被浪费。DHCPv6服务器应使其保留的先前绑定活动的数量可配置。DHCPv6服务器不需要在服务器重新启动时保留此信息（甚至根本不需要保留此类信息）。
Unless there is an error or some requirement to cease processing a Active Leasequery request yielding a LEASEQUERY-DONE message, such as a server shutdown, there will be no LEASEQUERY-DONE message at the conclusion of the Active Leasequery processing because that processing will not conclude but will continue until either the requestor or the server closes the connection.
除非出现错误或要求停止处理产生Leasequery-DONE消息的活动Leasequery请求，例如服务器关闭，在活动的LEASEQUERY处理结束时将不会有LEASEQUERY-DONE消息，因为该处理不会结束，但将继续，直到请求者或服务器关闭连接。
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.
每个活动的租赁请求都必须在单个TCP连接上发出，而在发出请求时没有其他活动的请求。
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 Leasequeries, the requestor MUST use different TCP connections.
通常，当第一个活动租赁请求仍处于活动状态时，活动租赁请求的请求者不需要发送第二个活动租赁请求。但是，同时发送活动租赁和批量租赁是可能的，也是合理的。在并行活动和批量租赁的情况下，请求者必须使用不同的TCP连接。
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 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
如果服务器在连接上发送数据时遇到错误，则必须关闭其TCP连接端。如果发现必须中止进程内请求，服务器必须关闭其TCP连接端。中止进程内请求的服务器应尝试通过使用QueryTerminated命令向其请求者发出信号
status code in the DHCPv6 status code option in a LEASEQUERY-DONE message. If the server detects that the requestor end has been closed, the server MUST close its end of the connection.
LEASQUERY-DONE消息中DHCPv6状态代码选项中的状态代码。如果服务器检测到请求端已关闭，则服务器必须关闭其连接端。
The server SHOULD limit the number of connections it maintains and SHOULD close idle connections to enforce the limit.
服务器应限制其维护的连接数，并应关闭空闲连接以强制执行该限制。
The Security Considerations section of [RFC3315] details the general threats to DHCPv6. The DHCPv6 Leasequery specification [RFC5007] describes recommendations for the Leasequery protocol, especially with regard to relayed Leasequery messages, mitigation of packet-flooding denial-of-service (DoS) attacks, restriction to trusted requestors, and use of IPsec [RFC4301].
[RFC3315]的安全注意事项部分详细说明了DHCPv6面临的一般威胁。DHCPv6 Leasequery规范[RFC5007]描述了Leasequery协议的建议，特别是关于中继Leasequery消息、缓解数据包溢出拒绝服务（DoS）攻击、对受信任请求者的限制以及IPsec的使用[RFC4301]。
The use of TCP introduces some additional concerns. Attacks that attempt to exhaust the DHCPv6 server's available TCP connection resources can compromise the ability of legitimate requestors to receive service. Malicious requestors who succeed in establishing connections but who then send invalid queries, partial queries, or no queries at all can also exhaust a server's pool of available connections.
TCP的使用带来了一些额外的问题。试图耗尽DHCPv6服务器可用TCP连接资源的攻击可能会损害合法请求者接收服务的能力。成功建立连接但随后发送无效查询、部分查询或根本不发送查询的恶意请求者也会耗尽服务器的可用连接池。
When operating in secure mode, TLS [RFC5246] is used to secure the connection. The recommendations in [RFC7525] SHOULD be followed when negotiating a TLS connection.
在安全模式下操作时，TLS[RFC5246]用于保护连接。协商TLS连接时，应遵循[RFC7525]中的建议。
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 DHCPv6 server from which it was acquired and SHOULD be secured by mechanisms as strong as those used for the data held by that DHCPv6 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.
通过使用主动租赁获取的数据可能与从中获取数据的DHCPv6服务器所持有的数据受到相同的滥用，并且应通过与DHCPv6服务器所持有数据相同的机制进行保护。通过使用活动租赁服务获取的数据应在其获取用途结束后尽快删除。
Authentication for DHCP messages [RFC3315] MUST NOT be used to attempt to secure transmission of the messages described in this document.
DHCP消息的身份验证[RFC3315]不得用于尝试安全传输本文档中描述的消息。
IANA has assigned new DHCPv6 option codes in the "Option Codes" registry maintained at <http://www.iana.org/assignments/ dhcpv6-parameters>:
IANA已在维护于的“选项代码”注册表中分配了新的DHCPv6选项代码<http://www.iana.org/assignments/ dhcpv6参数>：
OPTION_LQ_BASE_TIME (100)
选项LQ基本时间（100）
OPTION_LQ_START_TIME (101)
选项LQ开始时间（101）
OPTION_LQ_END_TIME (102)
选项LQ结束时间（102）
IANA has assigned new values in the DHCPv6 "Status Codes" registry maintained at <http://www.iana.org/assignments/dhcpv6-parameters>:
IANA已在DHCPv6“状态代码”注册表中分配了新值，该注册表位于<http://www.iana.org/assignments/dhcpv6-parameters>:
DataMissing (12)
数据缺失（12）
CatchUpComplete (13)
捕集完成（13）
NotSupported (14)
不受支持（14）
TLSConnectionRefused (15)
TLS连接被拒绝（15）
IANA has assigned values for the following new DHCPv6 message types in the "Message Types" registry maintained at <http://www.iana.org/assignments/dhcpv6-parameters>:
IANA在维护的“消息类型”注册表中为以下新的DHCPv6消息类型分配了值<http://www.iana.org/assignments/dhcpv6-parameters>:
ACTIVELEASEQUERY (22)
活动租赁（22）
STARTTLS (23)
STARTTLS（23）
[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>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，DOI 10.17487/RFC3633，2003年12月<http://www.rfc-editor.org/info/rfc3633>.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, September 2007, <http://www.rfc-editor.org/info/rfc5007>.
[RFC5007]Brzowski，J.，Kinnear，K.，Volz，B.，和S.Zeng，“DHCPv6租赁”，RFC 5007，DOI 10.17487/RFC5007，2007年9月<http://www.rfc-editor.org/info/rfc5007>.
[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>.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, DOI 10.17487/RFC5460, February 2009, <http://www.rfc-editor.org/info/rfc5460>.
[RFC5460]Stapp，M.，“DHCPv6散装租赁”，RFC 5460，DOI 10.17487/RFC5460，2009年2月<http://www.rfc-editor.org/info/rfc5460>.
[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>.
[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
致谢
Some of the concepts and content present in this document are based on DHCPv4 Active Leasequery, which was originally proposed by Kim Kinnear, Bernie Volz, Mark Stapp, and Neil Russell.
本文档中的一些概念和内容基于DHCPv4主动租赁，最初由Kim Kinnear、Bernie Volz、Mark Stapp和Neil Russell提出。
Useful review comments were provided by Scott Bradner, Francis Dupont, and Stephen Farrell. The privacy protections were substantially upgraded due to these comments and discussions.
Scott Bradner、Francis Dupont和Stephen Farrell提供了有用的审查意见。由于这些评论和讨论，隐私保护大幅升级。
Authors' Addresses
作者地址
Dushyant Raghuvanshi Cisco Systems, Inc. Cessna Business Park Varthur Hobli, Outer Ring Road Bangalore, Karnataka 560037 India
印度卡纳塔克邦班加罗尔外环路瓦瑟霍布利塞斯纳商业园Dushyant Raghuvanshi Cisco Systems，Inc.560037
Phone: +91 80 4426-7372
Email: draghuva@cisco.com
Phone: +91 80 4426-7372
Email: draghuva@cisco.com
Kim Kinnear Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, Massachusetts 01719 United States
Kim Kinnear Cisco Systems，Inc.美国马萨诸塞州Boxborough马萨诸塞大道1414号01719
Phone: +1 978 936-0000
Email: kkinnear@cisco.com
Phone: +1 978 936-0000
Email: kkinnear@cisco.com
Deepak Kukrety Cisco Systems, Inc. Cessna Business Park Varthur Hobli, Outer Ring Road Bangalore, Karnataka 560037 India
Deepak Kukrety Cisco Systems，Inc.印度卡纳塔克邦班加罗尔外环路瓦图尔霍布里塞斯纳商业园560037
Phone: +91 80 4426-7346
Email: dkukrety@cisco.com
Phone: +91 80 4426-7346
Email: dkukrety@cisco.com