Network Working Group M. Stapp
Request for Comments: 5460 Cisco Systems, Inc.
Category: Standards Track February 2009
Network Working Group M. Stapp
Request for Comments: 5460 Cisco Systems, Inc.
Category: Standards Track February 2009
DHCPv6 Bulk Leasequery
DHCPv6批量租赁
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP.
IPv6的动态主机配置协议（DHCPv6）已通过一个Leasequery功能进行了扩展，该功能允许客户端请求有关DHCPv6绑定的信息。该机制仅限于查询单个绑定。在某些情况下，单个绑定查询可能没有效率，甚至不可能。本文档扩展了Leasequery协议，添加了新的查询类型，并允许通过TCP批量传输DHCPv6绑定数据。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Interaction between UDP Leasequery and Bulk Leasequery . . . . 5
5. Message and Option Definitions . . . . . . . . . . . . . . . . 6
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 6
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1. LEASEQUERY-DATA . . . . . . . . . . . . . . . . . . . 7
5.2.2. LEASEQUERY-DONE . . . . . . . . . . . . . . . . . . . 7
5.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 7
5.3.1. QUERY_BY_RELAY_ID . . . . . . . . . . . . . . . . . . 7
5.3.2. QUERY_BY_LINK_ADDRESS . . . . . . . . . . . . . . . . 8
5.3.3. QUERY_BY_REMOTE_ID . . . . . . . . . . . . . . . . . . 8
5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4.1. Relay-ID Option . . . . . . . . . . . . . . . . . . . 8
5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 9
5.6. Connection and Transmission Parameters . . . . . . . . . . 9
6. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Connecting . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Forming Queries . . . . . . . . . . . . . . . . . . . . . 10
6.3. Processing Replies . . . . . . . . . . . . . . . . . . . . 10
6.3.1. Reply Completion . . . . . . . . . . . . . . . . . . . 11
6.4. Querying Multiple Servers . . . . . . . . . . . . . . . . 11
6.5. Multiple Queries to a Single Server . . . . . . . . . . . 12
6.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 12
6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 13
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 13
7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 14
7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 15
7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Interaction between UDP Leasequery and Bulk Leasequery . . . . 5
5. Message and Option Definitions . . . . . . . . . . . . . . . . 6
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 6
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1. LEASEQUERY-DATA . . . . . . . . . . . . . . . . . . . 7
5.2.2. LEASEQUERY-DONE . . . . . . . . . . . . . . . . . . . 7
5.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 7
5.3.1. QUERY_BY_RELAY_ID . . . . . . . . . . . . . . . . . . 7
5.3.2. QUERY_BY_LINK_ADDRESS . . . . . . . . . . . . . . . . 8
5.3.3. QUERY_BY_REMOTE_ID . . . . . . . . . . . . . . . . . . 8
5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4.1. Relay-ID Option . . . . . . . . . . . . . . . . . . . 8
5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 9
5.6. Connection and Transmission Parameters . . . . . . . . . . 9
6. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Connecting . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Forming Queries . . . . . . . . . . . . . . . . . . . . . 10
6.3. Processing Replies . . . . . . . . . . . . . . . . . . . . 10
6.3.1. Reply Completion . . . . . . . . . . . . . . . . . . . 11
6.4. Querying Multiple Servers . . . . . . . . . . . . . . . . 11
6.5. Multiple Queries to a Single Server . . . . . . . . . . . 12
6.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 12
6.6. Closing Connections . . . . . . . . . . . . . . . . . . . 13
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Accepting Connections . . . . . . . . . . . . . . . . . . 13
7.2. Forming Replies . . . . . . . . . . . . . . . . . . . . . 14
7.3. Multiple or Parallel Queries . . . . . . . . . . . . . . . 15
7.4. Closing Connections . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
The DHCPv6 [RFC3315] protocol specifies a mechanism for the assignment of IPv6 address and configuration information to IPv6 nodes. IPv6 Prefix Delegation (PD) 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前缀委派（PD）[RFC3633]为DHCPv6委派IPv6前缀和相关数据指定了一种机制。DHCPv6服务器维护权威信息，包括委派IPv6前缀的绑定信息。
The client of a PD binding is typically a router, which then advertises the delegated prefix to locally-connected hosts. The delegated IPv6 prefix must be routeable in order to be useful. The actual DHCPv6 PD client may not be permitted to inject routes into the delegating network. In service-provider (SP) networks, for example, an edge router typically acts as a DHCPv6 relay agent, and this edge router often has the responsibility to maintain routes within the service-provider network for clients' PD bindings.
PD绑定的客户端通常是路由器，然后路由器向本地连接的主机播发委派的前缀。委派的IPv6前缀必须可路由才能使用。可能不允许实际的DHCPv6 PD客户端将路由注入委派网络。例如，在服务提供商（SP）网络中，边缘路由器通常充当DHCPv6中继代理，该边缘路由器通常负责维护服务提供商网络内的路由，以便客户端的PD绑定。
A DHCPv6 relay with this responsibility requires a means to recover binding information from the authoritative DHCPv6 server(s) in the event of replacement or reboot, in order to restore routeability to delegated prefixes. The relay may be a network device without adequate local storage to maintain the necessary binding-to-route data. A DHCPv6 Leasequery protocol [RFC5007] has been developed that allows queries for individual bindings from the authoritative DHCPv6 server(s). The individual query mechanism is only useable when the target binding is known to the requestor, such as upon receipt of traffic. In the case of DHCPv6 Prefix Delegation, the PD binding data may need to be known before any traffic arrives from the client router. The DHCPv6 relay router may not be able to form individual queries in such cases.
具有此职责的DHCPv6中继需要在更换或重新启动时从权威DHCPv6服务器恢复绑定信息的方法，以便恢复委派前缀的可路由性。中继器可以是没有足够的本地存储来维持路由数据的必要绑定的网络设备。DHCPv6租赁协议[RFC5007]已经开发，允许从权威DHCPv6服务器查询单个绑定。单个查询机制仅在请求者知道目标绑定时可用，例如在收到流量时。在DHCPv6前缀委派的情况下，在任何流量从客户端路由器到达之前，可能需要知道PD绑定数据。在这种情况下，DHCPv6中继路由器可能无法形成单独的查询。
This document extends the DHCPv6 Leasequery protocol to add support for queries that address these requirements. At the SP edge there may be many thousands of delegated prefixes per relay, so we specify the use of TCP [RFC4614] for efficiency of data transfer. We specify a new DHCPv6 option, the Relay Identifier option, to support efficient recovery of all data associated with a specific relay agent; we also add a query-type for this purpose. We add query-types by network segment and by Remote-ID option value, to assist a relay that needs to recover a subset of its clients' bindings.
本文档扩展了DHCPv6 Leasequery协议，以添加对满足这些需求的查询的支持。在SP边缘，每个中继可能有数千个委派前缀，因此我们指定使用TCP[RFC4614]来提高数据传输的效率。我们指定了一个新的DHCPv6选项，中继标识符选项，以支持与特定中继代理相关联的所有数据的高效恢复；我们还为此添加了一个查询类型。我们按网络段和远程ID选项值添加查询类型，以帮助需要恢复其客户端绑定子集的中继。
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]中所述进行解释。
DHCPv6 terminology is defined in [RFC3315]. DHCPv6 Leasequery terminology is defined in [RFC5007].
[RFC3315]中定义了DHCPv6术语。[RFC5007]中定义了DHCPv6租赁术语。
The Bulk Leasequery mechanism is modeled on the existing individual Leasequery protocol in [RFC5007]; most differences arise from the use of TCP. A Bulk Leasequery client opens a TCP connection to a DHCPv6 server, using the DHCPv6 port 547. Note that this implies that the Leasequery client has server IP address(es) available via configuration or some other means, and that it has unicast IP reachability to the server. No relaying for bulk leasequery is specified.
批量租赁机制基于[RFC5007]中现有的个人租赁协议建模；大多数差异源于TCP的使用。批量租赁客户机使用DHCPv6端口547打开到DHCPv6服务器的TCP连接。请注意，这意味着Leasequery客户端通过配置或其他方式具有可用的服务器IP地址，并且它对服务器具有单播IP可达性。未指定批量租赁的中继。
After establishing a connection, the client sends a LEASEQUERY message containing a query-type and data about bindings it is interested in. The server uses the query-type and the data to identify any relevant bindings. In order to support some query-types, servers may have to maintain additional data structures or be able to locate bindings based on specific option data. The server replies with a LEASEQUERY-REPLY message, indicating the success or failure of the query. If the query was successful, the server includes the first client's binding data in the LEASEQUERY-REPLY message also. If more than one client's bindings are being returned, the server then transmits the additional client bindings in a series of LEASEQUERY-DATA messages. If the server has sent at least one client's bindings, it sends a LEASEQUERY-DONE message when it has finished sending its replies. The client may reuse the connection to send additional queries. Each end of the TCP connection can be closed after all data has been sent.
建立连接后，客户机将发送一条LEASEQUERY消息，其中包含查询类型和有关其感兴趣的绑定的数据。服务器使用查询类型和数据来标识任何相关绑定。为了支持某些查询类型，服务器可能必须维护额外的数据结构，或者能够根据特定的选项数据定位绑定。服务器用一条LEASEQUERY-REPLY消息进行回复，指示查询的成功或失败。如果查询成功，服务器也会在LEASEQUERY-REPLY消息中包含第一个客户端的绑定数据。如果返回多个客户端的绑定，则服务器会在一系列LEASEQUERY-DATA消息中传输附加的客户端绑定。如果服务器至少发送了一个客户端的绑定，则在发送完回复后，会发送一条LEASEQUERY-DONE消息。客户端可以重用连接来发送其他查询。发送完所有数据后，可以关闭TCP连接的每一端。
This specification includes a new DHCPv6 option, the Relay-ID option. The option contains a DUID (DHCP Unique Identifier) identifying a DHCPv6 relay agent. Relay agents can include this option in Relay-Forward messages they send. Servers can retain the Relay-ID and associate it with bindings made on behalf of the relay's clients. A relay can then recover binding information about downstream clients by using the Relay-ID in a LEASEQUERY message. The Relay-ID option is defined in Section 5.4.1.
本规范包括一个新的DHCPv6选件，即继电器ID选件。该选项包含标识DHCPv6中继代理的DUID（DHCP唯一标识符）。中继代理可以在其发送的中继转发消息中包含此选项。服务器可以保留中继ID，并将其与代表中继客户端进行的绑定相关联。然后，中继可以通过在LEASEQUERY消息中使用中继ID来恢复关于下游客户端的绑定信息。第5.4.1节定义了继电器ID选项。
Bulk Leasequery supports the queries by IPv6 address and by Client DUID as specified in [RFC5007]. The Bulk Leasequery protocol also adds several new queries. The new queries introduced here cannot be used effectively with the UDP Leasequery protocol. Requestors MUST NOT send these new query-types in [RFC5007] query messages.
Bulk Leasequery支持按照[RFC5007]中指定的IPv6地址和客户端DUID进行查询。批量租赁协议还添加了几个新的查询。这里介绍的新查询不能有效地与UDP Leasequery协议一起使用。请求者不得在[RFC5007]查询消息中发送这些新查询类型。
Query by Relay Identifier - This query asks a server for the bindings associated with a specific relay; the relay is identified by a DUID carried in a Relay-ID option.
按中继标识符查询-此查询向服务器询问与特定中继关联的绑定；继电器由继电器ID选项中携带的DUID标识。
Query by Link Address - This query asks a server for the bindings on a particular network segment; the link is specified in the query's link-address field.
按链接地址查询-此查询向服务器询问特定网段上的绑定；链接在查询的链接地址字段中指定。
Query by Remote ID - This query asks a server for the bindings associated with a Relay Agent Remote-ID option [RFC4649] value.
按远程ID查询-此查询向服务器询问与中继代理远程ID选项[RFC4649]值关联的绑定。
Bulk Leasequery can be seen as an extension of the existing UDP Leasequery protocol [RFC5007]. This section tries to clarify the relationship between the two protocols.
批量租赁可以看作是现有UDP租赁协议[RFC5007]的扩展。本节试图澄清两个协议之间的关系。
The query-types introduced in the UDP Leasequery protocol can be used in the Bulk Leasequery protocol. One change in behavior is introduced when Bulk Leasequery is used. [RFC5007], in sections 4.1.2.5 and 4.3.3, specifies the use of a Client Link option in LEASEQUERY-REPLY messages in cases where multiple bindings were found. When Bulk Leasequery is used, this mechanism is not necessary: a server returning multiple bindings simply does so directly as specified in this document. The Client Link option MUST NOT appear in Bulk Leasequery replies.
UDP租赁协议中引入的查询类型可用于批量租赁协议。当使用批量租赁时，引入了一种行为变化。[RFC5007]在第4.1.2.5节和第4.3.3节中规定了在发现多个绑定的情况下，在LEASEQUY-REPLY消息中使用客户端链接选项。当使用Bulk Leasequery时，不需要这种机制：返回多个绑定的服务器只需按照本文档中的指定直接返回即可。客户端链接选项不得出现在批量租赁回复中。
Only LEASEQUERY, LEASEQUERY-REPLY, LEASEQUERY-DATA, and LEASEQUERY-DONE messages are allowed over the Bulk Leasequery connection. No other DHCPv6 messages are supported. The Bulk Leasequery connection is not an alternative DHCPv6 communication option for clients seeking DHCPv6 service.
在批量LEASEQUERY连接上只允许发送LEASEQUERY、LEASEQUERY-REPLY、LEASEQUERY-DATA和LEASEQUERY-DONE消息。不支持其他DHCPv6消息。对于寻求DHCPv6服务的客户端，批量租赁连接不是DHCPv6通信的替代选项。
The new queries introduced in this specification cannot be used with the UDP Leasequery protocol. Servers that implement this specification and also permit UDP queries MUST NOT accept Bulk Leasequery query-types in UDP Leasequery messages. Such servers MUST respond with an error status code of NotAllowed [RFC5007].
本规范中引入的新查询不能与UDP Leasequery协议一起使用。实现此规范并允许UDP查询的服务器不得接受UDP Leasequery消息中的批量Leasequery查询类型。此类服务器必须以不允许的错误状态代码[RFC5007]响应。
Implementors should note that the TCP message framing defined in Section 5.1 is not compatible with the UDP message format. If a TCP-framed request is sent as a UDP message, it may not be valid, because protocol fields will be offset by the message-size prefix.
实施者应注意，第5.1节中定义的TCP消息帧与UDP消息格式不兼容。如果TCP帧请求作为UDP消息发送，则可能无效，因为协议字段将被消息大小前缀偏移。
The use of TCP for the Bulk Leasequery protocol permits one or more DHCPv6 messages to be sent at a time. The receiver needs to be able to determine how large each message is. Two octets containing the message size in network byte order are prepended to each DHCPv6 message sent on a Bulk Leasequery TCP connection. The two message-size octets 'frame' each DHCPv6 message.
对批量租赁协议使用TCP允许一次发送一个或多个DHCPv6消息。接收者需要能够确定每条消息的大小。在Bulk Leasequery TCP连接上发送的每条DHCPv6消息前都有两个八位字节，其中包含网络字节顺序的消息大小。两个消息大小的八位字节“帧”每个DHCPv6消息。
DHCPv6 message framed for TCP:
针对TCP的DHCPv6消息框架：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message-size | msg-type | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: transaction-id | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| .
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message-size | msg-type | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: transaction-id | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| .
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
message-size the number of octets in the message that follows, as a 16-bit integer in network byte order.
message size消息中随后的八位字节数，为网络字节顺序的16位整数。
All other fields are as specified in DHCPv6 [RFC3315].
所有其他字段如DHCPv6[RFC3315]中所述。
The LEASEQUERY and LEASEQUERY-REPLY messages are defined in [RFC5007]. In a Bulk 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, only a single LEASEQUERY-REPLY message MUST appear. If the server is returning binding data, the LEASEQUERY-REPLY also contains the first client's binding data in an OPTION_CLIENT_DATA option.
[RFC5007]中定义了LEASEQUY和LEASEQUY-REPLY消息。在批量Leasequery exchange中，单个Leasequery-REPLY消息用于指示查询的成功或失败，并携带在单个查询和应答上下文中不会更改的数据，例如服务器ID和客户端ID选项。如果查询成功，则只能显示一条LEASEQUERY-REPLY消息。如果服务器正在返回绑定数据，那么LEASEQUERY-REPLY还将在OPTION\u client\u data选项中包含第一个客户端的绑定数据。
The LEASEQUERY-DATA message carries data about a single DHCPv6 client's leases and/or PD bindings on a single link. The purpose of the message is to reduce redundant data when there are multiple bindings to be sent. The LEASEQUERY-DATA message MUST be preceded by a LEASEQUERY-REPLY message. The LEASEQUERY-REPLY carries the query's status, the Leasequery's Client-ID and Server-ID options, and the first client's binding data if the query was successful.
LEASEQUERY-DATA消息携带关于单个DHCPv6客户端在单个链路上的租约和/或PD绑定的数据。该消息的目的是在要发送多个绑定时减少冗余数据。LEASEQUERY-DATA消息前面必须有LEASEQUERY-REPLY消息。LEASEQUERY-REPLY包含查询的状态、LEASEQUERY的客户端ID和服务器ID选项，以及第一个客户端的绑定数据（如果查询成功）。
LEASEQUERY-DATA MUST ONLY be sent in response to a successful LEASEQUERY, and only if more than one client's data is to be sent. The LEASEQUERY-DATA message's transaction-id field MUST match the transaction-id of the LEASEQUERY request message. The Server-ID, Client-ID, and OPTION_STATUS_CODE options SHOULD NOT be included: that data should be constant for any one Bulk Leasequery reply, and should have been conveyed in the LEASEQUERY-REPLY message.
LEASEQUERY-DATA必须仅在成功的LEASEQUERY后发送，并且仅当要发送多个客户端的数据时才发送。LEASEQUERY-DATA消息的事务id字段必须与LEASEQUERY请求消息的事务id匹配。不应包括服务器ID、客户端ID和选项\状态\代码选项：对于任何一个批量租赁回复，该数据应为常量，并应在租赁回复消息中传输。
The LEASEQUERY-DONE message indicates the end of a group of related Leasequery replies. The LEASEQUERY-DONE message's transaction-id field MUST match the transaction-id of the LEASEQUERY request message. The presence of the message itself signals the end of a stream of reply messages. A single LEASEQUERY-DONE MUST BE sent after all replies (a successful LEASEQUERY-REPLY and zero or more LEASEQUERY-DATA messages) to a successful Bulk Leasequery request that returned at least one binding.
LEASEQUERY-DONE消息表示一组相关LEASEQUERY回复的结束。LEASEQUERY-DONE消息的事务id字段必须与LEASEQUERY请求消息的事务id匹配。消息本身的存在表示应答消息流的结束。对于返回至少一个绑定的成功批量LEASEQUERY请求，必须在所有回复（成功的LEASEQUERY-REPLY和零条或多条LEASEQUERY-DATA消息）后发送单个LEASEQUERY-DONE。
A server may encounter an error condition after it has sent the initial LEASEQUERY-REPLY. In that case, it SHOULD attempt to send a LEASEQUERY-DONE with an OPTION_STATUS_CODE option indicating the error condition to the requestor. Other DHCPv6 options SHOULD NOT be included in the LEASEQUERY-DONE message.
服务器在发送初始LEASQUERY-REPLY后可能会遇到错误情况。在这种情况下，它应该尝试向请求者发送一个带有选项\u STATUS\u CODE选项的LEASEQUERY-DONE，该选项指示错误条件。LEASEQUERY-DONE消息中不应包括其他DHCPv6选项。
The OPTION_LQ_QUERY option is defined in [RFC5007]. We introduce the following new query-types: QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, and QUERY_BY_REMOTE_ID. These queries are designed to assist relay agents in recovering binding data in circumstances where some or all of the relay's binding data has been lost.
[RFC5007]中定义了选项\u LQ\u查询选项。我们引入了以下新的查询类型：按中继ID查询、按链接地址查询和按远程ID查询。这些查询旨在帮助中继代理在部分或全部中继绑定数据丢失的情况下恢复绑定数据。
This query asks the server to return bindings associated with the specified relay DUID.
此查询要求服务器返回与指定中继DUID关联的绑定。
QUERY_BY_RELAY_ID - The query-options MUST contain an OPTION_RELAY_ID option. If the link-address field is 0::0, the query asks for all bindings associated with the specified relay DUID. If the link-address is specified, the query asks for bindings on that link.
按中继ID查询-查询选项必须包含选项中继ID选项。如果链接地址字段为0:：0，则查询将询问与指定中继DUID关联的所有绑定。如果指定了链接地址，则查询将请求该链接上的绑定。
The QUERY_BY_LINK_ADDRESS asks the server to return bindings on a network segment identified by a link-address value from a relay's Relay-Forward message.
查询按链接地址要求服务器返回由中继的中继转发消息中的链接地址值标识的网段上的绑定。
QUERY_BY_LINK_ADDRESS - The query's link-address contains an address a relay may have used in the link-address of a Relay-Forward message. The Server attempts to locate bindings on the same network segment as the link-address.
查询按链接地址-查询的链接地址包含中继可能在中继转发消息的链接地址中使用的地址。服务器尝试在与链接地址相同的网段上查找绑定。
The QUERY_BY_REMOTE_ID asks the server to return bindings associated with a Remote-ID option value from a relay's Relay-Forward message. The query-options MUST include a Relay Agent Remote-ID option [RFC4649].
查询\u BY \u REMOTE \u ID要求服务器从中继的中继转发消息返回与远程ID选项值关联的绑定。查询选项必须包括中继代理远程ID选项[RFC4649]。
In order to support this query, a server needs to record the most-recent Remote-ID option value seen in a Relay-Forward message along with its other binding data.
为了支持此查询，服务器需要记录中继转发消息中看到的最新远程ID选项值及其其他绑定数据。
QUERY_BY_REMOTE_ID - The query-options MUST include a Relay Agent Remote-ID option [RFC4649]. If the Server has recorded Remote-ID values with its bindings, it uses the option's value to identify bindings to return.
按远程ID查询-查询选项必须包括中继代理远程ID选项[RFC4649]。如果服务器已使用其绑定记录了远程ID值，则它将使用该选项的值来标识要返回的绑定。
The Relay-ID option carries a DUID [RFC3315]. A relay agent MAY include the option in Relay-Forward messages it sends. Obviously, it will not be possible for a server to respond to QUERY_BY_RELAY_ID queries unless the relay agent has included this option. A relay SHOULD be able to generate a DUID for this purpose, and capture the result in stable storage. A relay SHOULD also allow the DUID value to be configurable: doing so allows an administrator to replace a relay agent while retaining the association between the relay and existing DHCPv6 bindings.
继电器ID选项带有DUID[RFC3315]。中继代理可以在其发送的中继转发消息中包含该选项。显然，除非中继代理包含此选项，否则服务器不可能响应查询\u BY\u RELAY\u ID查询。继电器应能够为此目的生成DUID，并在稳定存储中捕获结果。中继还应该允许配置DUID值：这样做允许管理员替换中继代理，同时保留中继和现有DHCPv6绑定之间的关联。
A DHCPv6 server MAY associate Relay-ID options from Relay-Forward messages it processes with prefix delegations and/or lease bindings that result. Doing so allows it to respond to QUERY_BY_RELAY_ID Leasequeries.
DHCPv6服务器可能会将其处理的中继转发消息中的中继ID选项与由此产生的前缀委派和/或租用绑定相关联。这样做允许它通过中继ID请求响应查询。
The format of the Relay-ID option is shown below:
继电器ID选项的格式如下所示：
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_RELAY_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_RELAY_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RELAY_ID.
选项代码选项继电器ID。
option-len Length of DUID in octets.
选项len DUID的长度（以八位字节为单位）。
DUID The DUID for the relay agent.
DUID中继代理的DUID。
QueryTerminated - Indicates that the server is unable to perform a query or has prematurely terminated the query for some reason (which should be communicated in the text of the message). This may be because the server is short of resources or is being shut down. The requestor may retry the query at a later time. The requestor should wait at least a short interval before retrying. Note that while a server may simply prematurely close its end of the connection, it is preferable for the server to send a LEASEQUERY-REPLY or LEASEQUERY-DONE with this status-code to notify the requestor of the condition.
QueryTerminated—表示服务器无法执行查询，或由于某种原因（应在消息文本中传达）提前终止了查询。这可能是因为服务器资源不足或正在关闭。请求者可以稍后重试查询。请求者在重试之前应至少等待一小段时间。请注意，虽然服务器可能只是过早地关闭其连接端，但服务器最好使用此状态代码发送LEASEQUERY-REPLY或LEASEQUERY-DONE以通知请求者该情况。
DHCPv6 servers that support Bulk Leasequery SHOULD listen for incoming TCP connections on the DHCPv6 server port 547. Implementations MAY offer to make the incoming port configurable, but port 547 MUST be the default. Client implementations SHOULD make TCP connections to port 547, and MAY offer to make the destination server port configurable.
支持批量租赁的DHCPv6服务器应侦听DHCPv6服务器端口547上的传入TCP连接。实现可能提供使传入端口可配置，但端口547必须是默认端口。客户端实现应该使TCP连接到端口547，并且可以提供使目标服务器端口可配置的功能。
This section presents a table of values used to control Bulk Leasequery behavior, including recommended defaults. Implementations MAY make these values configurable. However, configuring too-small
本节介绍用于控制批量租赁行为的值表，包括推荐的默认值。实现可以使这些值可配置。但是，配置太小
timeout values may lead to harmful behavior both to this application as well as to other traffic in the network. As a result, timeout values smaller than the default values are NOT RECOMMENDED.
超时值可能会导致此应用程序以及网络中的其他流量的有害行为。因此，不建议使用小于默认值的超时值。
Parameter Default Description
-------------------------------------------
BULK_LQ_DATA_TIMEOUT 300 s Bulk Leasequery data timeout
BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
Parameter Default Description
-------------------------------------------
BULK_LQ_DATA_TIMEOUT 300 s Bulk Leasequery data timeout
BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
A requestor attempts to establish a TCP connection to a DHCPv6 server in order to initiate a Leasequery exchange. If the attempt fails, the requestor MAY retry.
请求者试图建立到DHCPv6服务器的TCP连接，以启动请求交换。如果尝试失败，请求者可以重试。
After a connection is established, the requestor constructs a Leasequery message, as specified in [RFC5007]. The query may have any of the defined query-types, and includes the options and data required by the query-type chosen. The requestor sends the message size then sends the actual DHCPv6 message, as described in Section 5.1.
建立连接后，请求者按照[RFC5007]中的规定构造一条Leasequery消息。查询可以具有任何已定义的查询类型，并包括所选查询类型所需的选项和数据。请求者发送消息大小，然后发送实际的DHCPv6消息，如第5.1节所述。
If the TCP connection becomes blocked or stops being writeable while the requestor is sending its query, the requestor SHOULD be prepared to 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 LEASEQUERY-REPLY message from the TCP connection. If the TCP connection stops delivering reply data (if the connection stops being readable), the requestor SHOULD be prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT, and MAY begin retry-processing if configured to do so.
请求者尝试从TCP连接读取LEASQUERY-REPLY消息。如果TCP连接停止传递应答数据（如果连接停止可读），请求者应该准备在批量\u LQ\u data\u超时后终止连接，并且如果配置为这样做，可以开始重试处理。
The requestor examines the LEASEQUERY-REPLY message, and determines how to proceed. Message validation rules are specified in DHCPv6 Leasequery [RFC5007]. If the reply contains an error status code (carried in an OPTION_STATUS_CODE option), the requestor follows the recommendations in [RFC5007]. A successful reply that does not include an OPTION_CLIENT_DATA option indicates that the target server had no bindings matching the query.
请求者检查LEASEQUERY-REPLY消息，并确定如何继续。消息验证规则在DHCPv6 Leasequery[RFC5007]中指定。如果回复包含错误状态代码（包含在选项_status_code选项中），请求者将遵循[RFC5007]中的建议。如果成功的答复不包含选项\u CLIENT\u DATA选项，则表明目标服务器没有与查询匹配的绑定。
Note: The Leasequery protocol uses the OPTION_CLIENT_LINK option as an indicator that multiple bindings were present in response to a single query. For Bulk Leasequery, the OPTION_CLIENT_LINK option is not used, and MUST NOT be present in replies.
注意：Leasequery协议使用选项_CLIENT _LINK选项作为指示，表明响应单个查询时存在多个绑定。对于批量租赁，不使用选项_CLIENT _LINK选项，并且不得出现在回复中。
A successful LEASEQUERY-REPLY that is returning binding data includes an OPTION_CLIENT_DATA option and possibly additional options. If there are additional bindings to be returned, they will be carried in LEASEQUERY-DATA messages. Each LEASEQUERY-DATA message contains an OPTION_CLIENT_DATA option, and possibly other options. A LEASEQUERY-DATA message that does not contain an OPTION_CLIENT_DATA MUST be discarded.
返回绑定数据的成功LEASEQUERY-REPLY包括选项\客户端\数据选项以及可能的其他选项。如果要返回其他绑定，它们将在LEASEQUERY-DATA消息中携带。每个LEASEQUERY-DATA消息都包含一个选项\客户端\数据选项，可能还有其他选项。必须丢弃不包含选项“客户端”数据的LEASEQUERY-DATA消息。
A single bulk query can result in a large number of replies. For example, a single relay agent might be responsible for routes for thousands of clients' delegated prefixes. The requestor MUST be prepared to receive more than one LEASEQUERY-DATA with transaction-ids matching a single LEASEQUERY message.
单个批量查询可能会导致大量回复。例如，一个中继代理可能负责数千个客户端委托前缀的路由。请求者必须准备好接收多个具有与单个LEASEQUERY消息匹配的事务ID的LEASEQUERY-DATA。
The LEASEQUERY-DONE message ends a successful Bulk Leasequery request that returned at least one binding. A LEASEQUERY-REPLY without any bindings MUST NOT be followed by a LEASEQUERY-DONE message for the same transaction-id. After receiving LEASEQUERY-DONE from a server, the requestor MAY close the TCP connection to that server. If the transaction-id in the LEASEQUERY-DONE does not match an outstanding LEASEQUERY message, the client MUST close the TCP connection.
LEASEQUERY-DONE消息结束返回至少一个绑定的成功批量LEASEQUERY请求。对于同一事务id，不带任何绑定的LEASEQUERY-REPLY后不得出现LEASEQUERY-DONE消息。从服务器收到LEASEQUERY-DONE后，请求者可以关闭与该服务器的TCP连接。如果LEASEQUERY-DONE中的事务id与未完成的LEASEQUERY消息不匹配，则客户端必须关闭TCP连接。
The reply to a Bulk Leasequery request is complete (i.e., no further messages for that request transaction-id will be received) when one of these conditions is met:
当满足以下条件之一时，批量租赁请求的回复完成（即，不会收到该请求交易id的进一步消息）：
1. if the LEASEQUERY-REPLY message had no OPTION_CLIENT_DATA option, when the LEASEQUERY-REPLY is received,
1. 如果LEASEQUERY-REPLY消息没有选项\u CLIENT\u DATA选项，则在收到LEASEQUERY-REPLY时，
2. else if the LEASEQUERY-REPLY did have an OPTION_CLIENT_DATA, when the corresponding LEASEQUERY-DONE message is received,
2. 否则，如果LEASQUERY-REPLY确实具有选项“客户端”数据，则在收到相应的LEASQUERY-DONE消息时，
3. else when the connection is closed.
3. 否则，当连接关闭时。
A Bulk Leasequery client MAY be configured to attempt to connect to and query from multiple DHCPv6 servers in parallel. The DHCPv6 Leasequery specification [RFC5007] includes a discussion about reconciling binding data received from multiple DHCPv6 servers.
批量租赁客户机可以配置为尝试并行连接到多个DHCPv6服务器并从中进行查询。DHCPv6租赁规范[RFC5007]包括关于协调从多个DHCPv6服务器接收的绑定数据的讨论。
Bulk Leasequery clients may need to make multiple queries in order to recover binding information. A requestor MAY use a single connection to issue multiple queries. Each query MUST have a unique transaction-id. A server MAY process more than one query at a time. A server that is willing to do so MAY interleave replies to the multiple queries within the stream of reply messages it sends. Clients need to be aware that replies for multiple queries may be interleaved within the stream of reply messages. Clients that are not able to process interleaved replies (based on transaction-id) MUST NOT send more than one query at a time. Requestors should be aware that servers are not required to process queries in parallel, and that servers are likely to limit the rate at which they process queries from any one requestor.
批量租赁客户机可能需要进行多个查询才能恢复绑定信息。请求者可以使用单个连接发出多个查询。每个查询必须具有唯一的事务id。服务器一次可以处理多个查询。愿意这样做的服务器可以在其发送的回复消息流中交错对多个查询的回复。客户端需要知道，多个查询的回复可能在回复消息流中交错。无法处理交错回复（基于事务id）的客户端一次不得发送多个查询。请求者应该知道，不要求服务器并行处理查询，而且服务器可能会限制它们处理来自任何一个请求者的查询的速率。
This example illustrates what a series of queries and responses might look like. This is only an example -- there is no requirement that this sequence must be followed, or that clients or servers must support parallel queries.
此示例演示了一系列查询和响应的外观。这只是一个示例——不要求必须遵循此顺序，也不要求客户端或服务器必须支持并行查询。
In the example session, the client sends four queries after establishing a connection; "xid" denotes a transaction-id in the diagram. Query 1 results in a failure; query 2 succeeds and the stream of replies concludes before the client issues any new query. Query 3 and query 4 overlap, and the server interleaves its replies to those two queries.
在示例会话中，客户端在建立连接后发送四个查询；“xid”表示图中的事务id。查询1导致失败；查询2成功，在客户端发出任何新查询之前，答复流结束。查询3和查询4重叠，服务器将其对这两个查询的答复交织在一起。
Client Server
------ ------
LEASEQUERY xid 1 ----->
<----- LEASEQUERY-REPLY xid 1 (w/error)
LEASEQUERY xid 2 ----->
<----- LEASEQUERY-REPLY xid 2
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DONE xid 2
LEASEQUERY xid 3 ----->
LEASEQUERY xid 4 ----->
<----- LEASEQUERY-REPLY xid 4
<----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-REPLY xid 3
<----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DONE xid 3
<----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-DONE xid 4
Client Server
------ ------
LEASEQUERY xid 1 ----->
<----- LEASEQUERY-REPLY xid 1 (w/error)
LEASEQUERY xid 2 ----->
<----- LEASEQUERY-REPLY xid 2
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DONE xid 2
LEASEQUERY xid 3 ----->
LEASEQUERY xid 4 ----->
<----- LEASEQUERY-REPLY xid 4
<----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-REPLY xid 3
<----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DONE xid 3
<----- LEASEQUERY-DATA xid 4
<----- LEASEQUERY-DONE xid 4
The requestor MAY close its end of the TCP connection after sending a LEASEQUERY message to the server. The requestor MAY choose to retain the connection if it intends to issue additional queries. Note that this client 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.
请求者可以在向服务器发送LEASEQUERY消息后关闭其TCP连接端。如果请求者打算发出附加查询，则可以选择保留连接。请注意，此客户端行为并不保证连接可用于其他查询：服务器可能会根据自己的配置决定关闭连接。
Servers that implement DHCPv6 Bulk Leasequery listen for incoming TCP connections. Port numbers are discussed in Section 5.6. Servers MUST be able to limit the number of currently accepted and active connections. The value BULK_LQ_MAX_CONNS MUST be the default; implementations MAY permit the value to be configurable.
实现DHCPv6批量租赁请求的服务器侦听传入的TCP连接。第5.6节讨论了端口号。服务器必须能够限制当前接受和活动连接的数量。值BULK\u LQ\u MAX\u CONNS必须是默认值；实现可能允许对值进行配置。
Servers MAY restrict Bulk Leasequery connections and LEASEQUERY messages to certain clients. Connections that are not from permitted clients SHOULD BE closed immediately, to avoid server connection resource exhaustion. Servers MAY restrict some clients to certain query types. Servers MAY reply to queries that are not permitted with the NotAllowed status code [RFC5007], and/or close the connection.
服务器可能会将批量租赁连接和租赁消息限制到某些客户端。应立即关闭来自不允许的客户端的连接，以避免服务器连接资源耗尽。服务器可能会将某些客户端限制为某些查询类型。服务器可以使用不允许的状态代码[RFC5007]答复不允许的查询，和/或关闭连接。
If the TCP connection becomes blocked while the server is accepting a connection or reading a query, it SHOULD be prepared to terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow Servers to control the period of time they are willing to wait before abandoning an inactive connection, independent of the TCP implementations they may be using.
如果TCP连接在服务器接受连接或读取查询时被阻塞，则应准备在批量\u LQ\u数据\u超时后终止连接。我们提出这一建议是为了允许服务器在放弃非活动连接之前控制他们愿意等待的时间段，这与他们可能使用的TCP实现无关。
The DHCPv6 Leasequery [RFC5007] specification describes the initial construction of LEASEQUERY-REPLY messages and the processing of QUERY_BY_ADDRESS and QUERY_BY_CLIENTID. Use of the LEASEQUERY-REPLY and LEASEQUERY-DATA messages to carry multiple bindings is described in Section 5.2. Message transmission and framing for TCP is described in Section 5.1. If the connection becomes blocked while the server is attempting to send reply messages, the server SHOULD be prepared to terminate the TCP connection after BULK_LQ_DATA_TIMEOUT.
DHCPv6 Leasequery[RFC5007]规范描述了Leasequery-REPLY消息的初始构造以及按地址查询和按客户端ID查询的处理。第5.2节介绍了使用LEASEQUY-REPLY和LEASEQUY-DATA消息来承载多个绑定。第5.1节描述了TCP的消息传输和帧。如果在服务器尝试发送回复消息时连接被阻止，则服务器应准备在批量\u LQ\u数据\u超时后终止TCP连接。
If the server encounters an error during initial query processing, before any reply has been sent, it SHOULD send a LEASEQUERY-REPLY containing an error code in an OPTION_STATUS_CODE option. This signals to the requestor that no data will be returned. If the server encounters an error while processing a query that has already resulted in one or more reply messages, the server SHOULD send a LEASEQUERY-DONE message with an error status. The server SHOULD close its end of the connection as an indication that it was not able to complete query processing.
如果服务器在初始查询处理过程中遇到错误，则在发送任何回复之前，它应该发送一个包含选项\u STATUS\u code选项中的错误代码的LEASEQUERY-reply。这向请求者发出信号，表示不会返回任何数据。如果服务器在处理已产生一条或多条回复消息的查询时遇到错误，则服务器应发送一条状态为错误的LEASEQUERY-DONE消息。服务器应关闭其连接端，表示无法完成查询处理。
If the server does not find any bindings satisfying a query, it SHOULD send a LEASEQUERY-REPLY without an OPTION_STATUS_CODE option and without any OPTION_CLIENT_DATA option. Otherwise, the server sends 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] and extended below. The server returns subsequent bindings in LEASEQUERY-DATA messages, which can avoid redundant data (such as the requestor's Client-ID).
如果服务器未找到任何满足查询的绑定，则应发送不带选项\状态\代码选项和任何选项\客户端\数据选项的LEASEQUERY-REPLY。否则，服务器将在回复消息中发送每个绑定的数据。第一条回复消息是LEASEQUERY-reply。如[RFC5007]所述，绑定数据包含在选项\客户端\数据选项中，并在下面进行了扩展。服务器在LEASEQUERY-DATA消息中返回后续绑定，这可以避免冗余数据（例如请求者的客户端ID）。
For QUERY_BY_RELAY_ID, the server locates each binding associated with the query's Relay-ID option value. In order to give a meaningful reply to a QUERY_BY_RELAY_ID, the server has to be able to maintain this association in its DHCPv6 binding data. If the query's link-address is not set to 0::0, the server only returns bindings on links that could contain that address. If the link-address is not 0::0 and the server cannot find any matching links, the server SHOULD return the NotConfigured status in a LEASEQUERY-REPLY.
对于按中继ID查询，服务器定位与查询的中继ID选项值关联的每个绑定。为了通过中继ID对查询给出有意义的答复，服务器必须能够在其DHCPv6绑定数据中维护此关联。如果查询的链接地址未设置为0:：0，则服务器仅返回可能包含该地址的链接上的绑定。如果链接地址不是0:：0，并且服务器找不到任何匹配的链接，则服务器应在LEASEQUERY-REPLY中返回NotConfigured状态。
For QUERY_BY_LINK_ADDRESS, the server locates each binding associated with the link identified by the query's link-address value.
对于按链接地址查询，服务器将查找与查询的链接地址值标识的链接关联的每个绑定。
For QUERY_BY_REMOTE_ID, the server locates each binding associated with the query's Relay Remote-ID option value. In order to be able to give meaningful replies to this query, the server has to be able to maintain this association in its binding database. If the query message's link-address is not set to 0::0, the server only returns bindings on links that could contain that address. If the link-address is not 0::0 and the server cannot find any matching links, the server SHOULD return the NotConfigured status in a LEASEQUERY-REPLY.
对于按远程ID查询，服务器将查找与查询的中继远程ID选项值关联的每个绑定。为了能够对此查询给出有意义的答复，服务器必须能够在其绑定数据库中维护此关联。如果查询消息的链接地址未设置为0:：0，则服务器仅返回可能包含该地址的链接上的绑定。如果链接地址不是0:：0，并且服务器找不到任何匹配的链接，则服务器应在LEASEQUERY-REPLY中返回NotConfigured状态。
The server sends the LEASEQUERY-DONE message as specified in Section 5.2.
服务器按照第5.2节的规定发送LEASEQUERY-DONE消息。
As discussed in Section 6.5, requestors may want to leverage an existing connection if they need to make multiple queries. Servers MAY support reading and processing multiple queries from a single connection. A server MUST NOT read more query messages from a connection than it is prepared to process simultaneously.
如第6.5节所述，如果请求者需要进行多个查询，他们可能希望利用现有连接。服务器可能支持从单个连接读取和处理多个查询。服务器从连接中读取的查询消息不能超过它准备同时处理的数量。
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 close its end of the TCP connection after sending its last message (a LEASEQUERY-REPLY or a LEASEQUERY-DONE) in response to a query. Alternatively, the server MAY retain the connection and wait for additional queries from the client. The server SHOULD be prepared to limit the number of connections it maintains, and SHOULD be prepared to close idle connections to enforce the limit.
在发送最后一条消息（LEASEQUERY-REPLY或LEASEQUERY-DONE）以响应查询后，服务器可能会关闭其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 MAY attempt to notify its clients by using the QueryTerminated (Section 5.5) status code. If the server detects that the client end has been closed, the server MUST close its end of the connection after it has finished processing any outstanding requests from the client.
如果服务器在连接上发送数据时遇到错误，则必须关闭其TCP连接端。如果发现必须中止进程内请求，服务器必须关闭其TCP连接端。中止进程内请求的服务器可能会尝试使用QueryTerminated（第5.5节）状态代码通知其客户端。如果服务器检测到客户端已关闭，则服务器必须在完成处理来自客户端的任何未完成请求后关闭其连接端。
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 clients, 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, such as SYN flooding attacks, can compromise the ability of legitimate clients to receive service. Malicious clients 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. We recommend that servers offer configuration to limit the sources of incoming connections, that they limit the number of accepted connections and the number of in-process queries from any one connection, and that they limit the period of time during which an idle connection will be left open.
TCP的使用带来了一些额外的问题。试图耗尽DHCPv6服务器可用TCP连接资源的攻击，如SYN洪泛攻击，可能会损害合法客户端接收服务的能力。成功建立连接但随后发送无效查询、部分查询或根本不发送查询的恶意客户端也会耗尽服务器的可用连接池。我们建议服务器提供限制传入连接源的配置，限制接受连接的数量和来自任何一个连接的进程内查询的数量，并限制空闲连接保持打开的时间段。
IANA has assigned a new value in the registry of DHCPv6 Option Codes:
IANA已在DHCPv6选项代码注册表中分配了一个新值：
53 OPTION_RELAY_ID
53选项\u继电器\u ID
IANA has assigned a new value in the registry of DHCPv6 Status Codes:
IANA已在DHCPv6状态代码注册表中分配了一个新值：
11 QueryTerminated
11查询终止
IANA has assigned the following values in the registry of DHCPv6 Message types:
IANA在DHCPv6消息类型的注册表中分配了以下值：
16 LEASEQUERY-DONE 17 LEASEQUERY-DATA
16 LEASEQUERY-DONE 17 LEASEQUERY-DATA
IANA has assigned the following values in the registry of query-types for the DHCPv6 OPTION_LQ_QUERY option:
IANA在DHCPv6选项\u LQ\u查询选项的查询类型注册表中分配了以下值：
3 QUERY_BY_RELAY_ID 4 QUERY_BY_LINK_ADDRESS 5 QUERY_BY_REMOTE_ID
3按中继ID查询4按链接地址查询5按远程ID查询
The above-mentioned registries are available from http://www.iana.org.
上述登记处可从以下网址获得：http://www.iana.org.
Many of the ideas in this document were originally proposed by Kim Kinnear, Richard Johnson, Hemant Singh, Ole Troan, and Bernie Volz. Further suggestions and improvements were made by participants in the DHC working group, including John Brzozowski, Marcus Goller, Alfred Hoenes, Ted Lemon, Bud Millwood, and Thomas Narten.
本文件中的许多想法最初由金·金尼尔、理查德·约翰逊、赫曼特·辛格、奥勒·特隆和伯尼·沃尔兹提出。DHC工作组的参与者提出了进一步的建议和改进，包括John Brzowski、Marcus Goller、Alfred Hoenes、Ted Lemon、Bud Millwood和Thomas Narten。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006.
[RFC4649]Volz，B.，“IPv6（DHCPv6）中继代理远程ID选项的动态主机配置协议”，RFC 4649，2006年8月。
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5007]Brzowski，J.，Kinnear，K.，Volz，B.，和S.Zeng，“DHCPv6租赁”，RFC 5007，2007年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614]Duke，M.，Braden，R.，Eddy，W.，和E.Blanton，“传输控制协议（TCP）规范文件路线图”，RFC 46142006年9月。
Author's Address
作者地址
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Mark Stapp Cisco Systems，Inc.美国马萨诸塞州Boxborough大道1414号，邮编01719
Phone: +1 978 936 0000
EMail: mjs@cisco.com
Phone: +1 978 936 0000
EMail: mjs@cisco.com