Network Working Group J. Brzozowski
Request for Comments: 5007 Comcast Cable
Category: Standards Track K. Kinnear
B. Volz
S. Zeng
Cisco Systems, Inc.
September 2007
Network Working Group J. Brzozowski
Request for Comments: 5007 Comcast Cable
Category: Standards Track K. Kinnear
B. Volz
S. Zeng
Cisco Systems, Inc.
September 2007
DHCPv6 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）。本备忘录的分发不受限制。
Abstract
摘要
This document specifies a leasequery exchange for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) that can be used to obtain lease information about DHCPv6 clients from a DHCPv6 server. This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. This document extends DHCPv6.
本文档指定了IPv6动态主机配置协议（DHCPv6）的租约交换，该协议可用于从DHCPv6服务器获取有关DHCPv6客户端的租约信息。本文档指定了可以检索的数据范围以及DHCPv6 leasequery请求者和服务器行为。本文档扩展了DHCPv6。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. On-Demand Query . . . . . . . . . . . . . . . . . . . . . 4
3.2. Anticipatory Query . . . . . . . . . . . . . . . . . . . . 5
3.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Message and Option Definitions . . . . . . . . . . . . . . 6
4.1.1. Messages . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 12
4.1.4. Transmission and Retransmission Parameters . . . . . . 12
4.2. Message Validation . . . . . . . . . . . . . . . . . . . . 12
4.2.1. LEASEQUERY . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2. LEASEQUERY-REPLY . . . . . . . . . . . . . . . . . . . 13
4.3. DHCPv6 Leasequery Requestor Behavior . . . . . . . . . . . 13
4.3.1. Creation of LEASEQUERY . . . . . . . . . . . . . . . . 13
4.3.2. Transmission of LEASEQUERY . . . . . . . . . . . . . . 13
4.3.3. Receipt of LEASEQUERY-REPLY . . . . . . . . . . . . . 14
4.3.4. Handling DHCPv6 Client Data from Multiple Sources . . 15
4.4. DHCPv6 Leasequery Server Behavior . . . . . . . . . . . . 16
4.4.1. Receipt of LEASEQUERY Messages . . . . . . . . . . . . 16
4.4.2. Constructing the Client's OPTION_CLIENT_DATA . . . . . 17
4.4.3. Transmission of LEASEQUERY-REPLY Messages . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. On-Demand Query . . . . . . . . . . . . . . . . . . . . . 4
3.2. Anticipatory Query . . . . . . . . . . . . . . . . . . . . 5
3.3. Query Types . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Message and Option Definitions . . . . . . . . . . . . . . 6
4.1.1. Messages . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Options . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 12
4.1.4. Transmission and Retransmission Parameters . . . . . . 12
4.2. Message Validation . . . . . . . . . . . . . . . . . . . . 12
4.2.1. LEASEQUERY . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2. LEASEQUERY-REPLY . . . . . . . . . . . . . . . . . . . 13
4.3. DHCPv6 Leasequery Requestor Behavior . . . . . . . . . . . 13
4.3.1. Creation of LEASEQUERY . . . . . . . . . . . . . . . . 13
4.3.2. Transmission of LEASEQUERY . . . . . . . . . . . . . . 13
4.3.3. Receipt of LEASEQUERY-REPLY . . . . . . . . . . . . . 14
4.3.4. Handling DHCPv6 Client Data from Multiple Sources . . 15
4.4. DHCPv6 Leasequery Server Behavior . . . . . . . . . . . . 16
4.4.1. Receipt of LEASEQUERY Messages . . . . . . . . . . . . 16
4.4.2. Constructing the Client's OPTION_CLIENT_DATA . . . . . 17
4.4.3. Transmission of LEASEQUERY-REPLY Messages . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
The DHCPv6 [2] protocol specifies a mechanism for the assignment of both IPv6 address and configuration information to IPv6 nodes. IPv6 Prefix Options for DHCPv6 [4] specifies a mechanism for the automated delegation of IPv6 prefixes and related options. Similar to DHCPv4 [5], DHCPv6 servers maintain authoritative information related to their operations including, but not limited to, lease information for IPv6 addresses and delegated prefixes.
DHCPv6[2]协议指定了一种将IPv6地址和配置信息分配给IPv6节点的机制。DHCPv6的IPv6前缀选项[4]指定了自动委派IPv6前缀和相关选项的机制。与DHCPv4[5]类似，DHCPv6服务器维护与其操作相关的权威信息，包括但不限于IPv6地址和委派前缀的租约信息。
The requirement exists in various types of IPv6 deployments, particularly those of a broadband variety, to leverage DHCPv6 [2] for retrieving data related to the operation of DHCPv6 servers programmatically. In particular, it is desirable to be able to extract lease information about IPv6 addresses and delegated prefixes assigned using DHCPv6 [2] [4]. Specific examples where this information has illustrated value are in broadband networks to facilitate access control by edge devices. This capability to programmatically extract lease data from the DHCPv6 server is called leasequery.
在各种类型的IPv6部署中，尤其是宽带部署中，需要利用DHCPv6[2]以编程方式检索与DHCPv6服务器操作相关的数据。特别是，希望能够提取关于使用DHCPv6[2][4]分配的IPv6地址和委派前缀的租约信息。该信息具有说明价值的具体示例是在宽带网络中，以促进边缘设备的访问控制。这种从DHCPv6服务器以编程方式提取租赁数据的功能称为leasequery。
The leasequery capability described in this document parallels the DHCPv4 leasequery capability documented in [3]. As such, it shares the basic motivations, background, design goals and constraints as described in [3]. Differences are due to the differences between IPv4 and IPv6 and by extension, DHCPv4 and DHCPv6. For example, Neighbor Discovery [7] is used in IPv6 instead of the Address Resolution Protocol (ARP) [8] (Section 4.1 of [3]) and DOCSIS 3.0 [11] defines IPv6 support for cable modem environments.
本文档中描述的租赁能力与[3]中描述的DHCPv4租赁能力类似。因此，它具有[3]中所述的基本动机、背景、设计目标和约束条件。这种差异是由于IPv4和IPv6之间的差异，以及扩展为DHCPv4和DHCPv6之间的差异造成的。例如，在IPv6中使用邻居发现[7]而不是地址解析协议（ARP）[8]（第4.1节，共[3]），DOCSIS 3.0[11]定义了对电缆调制解调器环境的IPv6支持。
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 [1].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
DHCPv6 terminology is defined in [2]. Terminology specific to DHCPv6 leasequery can be found below:
DHCPv6术语定义见[2]。DHCPv6租赁专用术语如下：
access concentrator An access concentrator is a router or switch at the broadband access provider's edge of a public broadband access network. This document assumes that the access concentrator includes the DHCPv6 relay agent functionality.
接入集中器接入集中器是位于宽带接入提供商公共宽带接入网络边缘的路由器或交换机。本文档假设访问集中器包含DHCPv6中继代理功能。
client(s) The nodes that have one or more bindings with a DHCPv6 server. This does not refer to the node issuing the LEASEQUERY unless it itself has one or more bindings with a DHCPv6 server.
客户端与DHCPv6服务器具有一个或多个绑定的节点。除非节点本身与DHCPv6服务器有一个或多个绑定，否则这并不指发出LEASEQUERY的节点。
gleaning Gleaning is the extraction of location information from DHCPv6 messages, as the messages are forwarded by the DHCP relay agent function.
收集收集是从DHCPv6消息中提取位置信息，因为消息由DHCP中继代理功能转发。
location information Location information is information needed by the access concentrator to forward traffic to a broadband-accessible host. This information includes knowledge of the host hardware address, the port or virtual circuit that leads to the host, and/or the hardware address of the intervening subscriber modem.
位置信息位置信息是接入集中器将流量转发到宽带接入主机所需的信息。此信息包括主机硬件地址、通向主机的端口或虚拟电路和/或介入用户调制解调器的硬件地址。
requestor The node that sends LEASEQUERY messages to one or more servers to retrieve information on the bindings for a client.
requestor向一个或多个服务器发送LEASEQUERY消息以检索客户端绑定信息的节点。
The focus of this document is to extend the DHCPv6 protocol to allow processes and devices that wish to access information from a DHCPv6 server to do so in a lightweight and convenient manner. It is especially appropriate for processes and devices that already interpret DHCPv6 messages.
本文档的重点是扩展DHCPv6协议，以允许希望从DHCPv6服务器访问信息的进程和设备以轻量级和方便的方式进行访问。它特别适用于已经解释DHCPv6消息的进程和设备。
The LEASEQUERY message is a query message only and does not affect the state of the IPv6 address or prefix, or the binding information associated with it.
LEASEQUERY消息仅为查询消息，不影响IPv6地址或前缀的状态，也不影响与其关联的绑定信息。
One important motivating example is that the LEASEQUERY message allows access concentrators to query DHCP servers to obtain location information of broadband access network devices. This is described in Section 1 of [3] for IPv4.
一个重要的激励示例是，LEASEQUERY消息允许接入集中器查询DHCP服务器以获取宽带接入网络设备的位置信息。这在IPv4的[3]第1节中进行了描述。
The on-demand leasequery capability allows requesting just the information necessary to satisfy an immediate need. If the requestor is an access concentrator, then the immediate need will typically be that it has received an IPv6 packet and it needs to refresh its information concerning the DHCPv6 client to which that IPv6 address is currently leased. In this case, the request will be by address. This fits clearly into the single request/response cycle common to other DHCPv6 message exchanges.
按需租赁功能允许仅请求满足即时需求所需的信息。如果请求者是访问集中器，那么立即需要的通常是它已接收到IPv6数据包，并且它需要刷新有关当前租用该IPv6地址的DHCPv6客户端的信息。在这种情况下，请求将按地址发送。这显然适合于其他DHCPv6消息交换通用的单个请求/响应周期。
However, this approach has limitations when used with prefix delegation [4] as no traffic may arrive because the access concentrator is unable to inject the appropriate routing information into the routing infrastructure, such as after a reboot. This approach does work if the access concentrator is configured to inject routing information for a prefix that aggregates potentially delegated prefixes. Or, it also works if the access concentrator and requesting router use a routing protocol; as then the requesting router can trigger the access concentrator to request information from a DHCPv6 server and inject appropriate routing information into the routing infrastructure.
但是，当与前缀委派[4]一起使用时，这种方法有局限性，因为访问集中器无法将适当的路由信息注入路由基础设施，例如在重新启动后，可能不会有流量到达。如果将访问集中器配置为为为聚合潜在委派前缀的前缀注入路由信息，则此方法确实有效。或者，如果接入集中器和请求路由器使用路由协议，它也可以工作；此时，请求路由器可以触发访问集中器从DHCPv6服务器请求信息，并将适当的路由信息注入路由基础结构。
A second approach for requesting information from a DHCPv6 server would be to use a leasequery-like capability to rebuild an internal data store containing information available from a DHCPv6 server. The rebuilding of the data store in this approach can take place as soon as possible after the need to rebuild it is discovered (such as on booting), and doesn't wait on the receipt of specific packets to trigger a piecemeal database update (as is the case for on-demand leasequery). This approach would also remove the limitation discussed above for prefix delegation.
从DHCPv6服务器请求信息的第二种方法是使用类似leasequery的功能来重建包含DHCPv6服务器可用信息的内部数据存储。在这种方法中，数据存储的重建可以在发现重建需要后尽快进行（例如在引导时），而不必等待收到特定数据包来触发逐段数据库更新（如按需租赁）。这种方法还将消除上文讨论的前缀授权限制。
This anticipatory query is not specified in this document and is an area of future work.
此预期查询未在本文档中指定，是未来工作的一个领域。
Leasequery provides for the following queries:
Leasequery提供以下查询：
Query by IPv6 address - This query allows a requestor to request from a server the bindings for a client that either is bound to the address or has been delegated the prefix that contains the address.
按IPv6地址查询-此查询允许请求者从服务器请求绑定到该地址或已被委派包含该地址的前缀的客户端的绑定。
Query by Client Identifier (DUID) - This query allows a requestor to request from a server the bindings for a specific client on a specific link or a list of the links on which the client has one or more bindings.
按客户端标识符查询（DUID）-此查询允许请求者从服务器请求特定链接上特定客户端的绑定，或请求客户端具有一个或多个绑定的链接列表。
The LEASEQUERY and LEASEQUERY-REPLY messages use the Client/Server message formats described in [2], Section 6. Two new message codes are defined:
LEASEQUERY和LEASEQUERY-REPLY消息使用第6节[2]中所述的客户机/服务器消息格式。定义了两个新的消息代码：
LEASEQUERY (14) - A requestor sends a LEASEQUERY message to any available server to obtain information on a client's leases. The options in an OPTION_LQ_QUERY determine the query.
LEASEQUERY（14）-请求者向任何可用的服务器发送LEASEQUERY消息，以获取有关客户端租约的信息。选项查询中的选项决定查询。
LEASEQUERY-REPLY (15) - A server sends a LEASEQUERY-REPLY message containing client data in response to a LEASEQUERY message.
LEASEQUERY-REPLY（15）-服务器发送包含客户端数据的LEASEQUERY-REPLY消息以响应LEASEQUERY消息。
The Query option is used only in a LEASEQUERY message and identifies the query being performed. The option includes the query type, link-address (or 0::0), and option(s) to provide data needed for the query.
查询选项仅在LEASEQUERY消息中使用，用于标识正在执行的查询。该选项包括查询类型、链接地址（或0:：0）和用于提供查询所需数据的选项。
The format of the Query option is shown below:
查询选项的格式如下所示：
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_QUERY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-type | |
+-+-+-+-+-+-+-+-+ |
| |
| link-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | .
+-+-+-+-+-+-+-+-+ .
. query-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_QUERY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-type | |
+-+-+-+-+-+-+-+-+ |
| |
| link-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | .
+-+-+-+-+-+-+-+-+ .
. query-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_QUERY (44)
选项代码选项查询（44）
option-len 17 + length of query-options field.
选项长度17+查询选项字段的长度。
link-address A global address that will be used by the server to identify the link to which the query applies, or 0::0 if unspecified.
链接地址服务器将用于标识查询应用到的链接的全局地址，如果未指定，则为0:：0。
query-type The query requested (see below).
查询类型请求的查询（见下文）。
query-options The options related to the query.
查询选项与查询相关的选项。
The query-type and required query-options are:
查询类型和所需的查询选项包括：
QUERY_BY_ADDRESS (1) - The query-options MUST contain an OPTION_IAADDR option [2]. The link-address field, if not 0::0, specifies an address for the link on which the client is located if the address in the OPTION_IAADDR option is of insufficient scope. Only the information for the client that has a lease for the specified address or was delegated a prefix that contains the specified address is returned (if available).
按地址查询（1）-查询选项必须包含选项IAADDR选项[2]。如果选项_IAADDR选项中的地址范围不足，则“链接地址”字段（如果不是0:：0）指定客户端所在链接的地址。仅返回具有指定地址租约或被委派包含指定地址的前缀的客户端的信息（如果可用）。
QUERY_BY_CLIENTID (2) - The query-options MUST contain an OPTION_CLIENTID option [2]. The link-address field, if not 0::0, specifies an address for the link on which the client is located. If the link-address field is 0::0, the server SHOULD search all of its links for the client.
QUERY\u BY\u CLIENTID（2）-查询选项必须包含选项\u CLIENTID选项[2]。链接地址字段（如果不是0:：0）指定客户端所在链接的地址。如果链接地址字段为0:：0，则服务器应在其所有链接中搜索客户端。
The query-options MAY also include an OPTION_ORO option [2] to indicate the options for each client that the requestor would like the server to return. Note that this OPTION_ORO is distinct and separate from an OPTION_ORO that may be in the requestor's LEASEQUERY message.
查询选项还可以包括选项[2]，用于指示请求者希望服务器返回的每个客户端的选项。请注意，此选项与请求者的请求消息中可能存在的选项不同。
If a server receives an OPTION_LQ_QUERY with a query-type it does not support, the server SHOULD return an UnknownQueryType status-code. If a server receives a supported query-type but the query-options is missing a required option, the server SHOULD return a MalformedQuery status-code.
如果服务器接收到一个带有其不支持的查询类型的选项查询，则服务器应返回一个UnknownQueryType状态代码。如果服务器接收到支持的查询类型，但查询选项缺少必需的选项，则服务器应返回格式错误的查询状态代码。
The Client Data option is used to encapsulate the data for a single client on a single link in a LEASEQUERY-REPLY message.
“客户端数据”选项用于将单个客户端的数据封装在LEASEQUERY-REPLY消息中的单个链接上。
The format of the Client Data option is shown below:
客户端数据选项的格式如下所示：
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_CLIENT_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. client-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_CLIENT_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. client-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENT_DATA (45)
选项代码选项客户端数据（45）
option-len Length, in octets, of the encapsulated client-options field.
封装的客户端选项字段的选项长度（以八位字节为单位）。
client-options The options associated with this client.
客户端选项与此客户端关联的选项。
The encapsulated client-options include the OPTION_CLIENTID, OPTION_IAADDR, OPTION_IAPREFIX, and OPTION_CLT_TIME options and other options specific to the client and requested by the requestor in the OPTION_ORO in the OPTION_LQ_QUERY's query-options. The server MUST return all of the client's statefully assigned addresses and delegated prefixes, with a non-zero valid lifetime, on the link.
封装的客户端选项包括选项CLIENTID、选项IAADDR、选项IAPREFIX和选项CLT时间选项以及特定于客户端的、由请求者在选项LQ查询的查询选项中的选项ORO中请求的其他选项。服务器必须返回链接上所有客户端有状态分配的地址和委派前缀，且有效生存期不为零。
The Client Last Transaction Time option is encapsulated in an OPTION_CLIENT_DATA and identifies how long ago the server last communicated with the client, in seconds.
“客户端上次事务时间”选项封装在选项“客户端”数据中，标识服务器上次与客户端通信的时间（以秒为单位）。
The format of the Client Last Transaction Time option is shown below:
客户端上次交易时间选项的格式如下所示：
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_CLT_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client-last-transaction-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_CLT_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client-last-transaction-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLT_TIME (46)
选项代码选项CLT时间（46）
option-len 4
选项len 4
client-last-transaction-time The number of seconds since the server last communicated with the client (on that link).
client last transaction time自服务器上次与客户端（在该链接上）通信以来的秒数。
The client-last-transaction-time is a positive value and reflects the number of seconds since the server last communicated with the client (on that link).
客户端上次事务时间为正值，反映自服务器上次与客户端（在该链接上）通信以来的秒数。
The Relay Data option is used only in a LEASEQUERY-REPLY message and provides the relay agent information used when the client last communicated with the server.
中继数据选项仅在LEASQUERY-REPLY消息中使用，并提供客户端上次与服务器通信时使用的中继代理信息。
The format of the Relay Data option is shown below:
继电器数据选项的格式如下所示：
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_RELAY_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| peer-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DHCP-relay-message |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_RELAY_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| peer-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DHCP-relay-message |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_RELAY_DATA (47)
选项代码选项LQ继电器数据（47）
option-len 16 + length of DHCP-relay-message.
选项len 16+DHCP中继消息的长度。
peer-address The address of the relay agent from which the relayed message was received by the server.
对等地址服务器从中接收中继消息的中继代理的地址。
DHCP-relay-message The last complete relayed message, excluding the client's message OPTION_RELAY_MSG, received by the server.
DHCP中继消息服务器接收到的最后一条完整的中继消息，不包括客户端的消息选项\u relay\u MSG。
This option is used by the server to return full relay agent information for a client. It MUST NOT be returned if the server does not have such information, either because the client communicated directly (without relay agent) with the server or if the server did not retain such information.
服务器使用此选项返回客户端的完整中继代理信息。如果服务器没有此类信息，或者因为客户端直接与服务器通信（没有中继代理），或者如果服务器没有保留此类信息，则不得返回此信息。
If returned, the DHCP-relay-message MUST contain a valid (perhaps multi-hop) RELAY-FORW message as the most recently received by the server for the client. However, the (innermost) OPTION_RELAY_MSG option containing the client's message MUST have been removed.
如果返回，DHCP中继消息必须包含有效的（可能是多跳的）中继FORW消息，作为服务器最近为客户端接收的消息。但是，包含客户端消息的（最里面的）选项\u RELAY\u MSG选项必须已删除。
This option SHOULD only be returned if requested by the OPTION_ORO of the OPTION_LQ_QUERY.
只有在选项查询的选项ORO请求时，才应返回此选项。
The Client Link option is used only in a LEASEQUERY-REPLY message and identifies the links on which the client has one or more bindings. It is used in reply to a query when no link-address was specified and the client is found to be on more than one link.
客户端链接选项仅在LEASQUERY-REPLY消息中使用，并标识客户端具有一个或多个绑定的链接。当未指定链接地址且发现客户机位于多个链接上时，可使用它来答复查询。
The format of the Client Link option is shown below:
客户端链接选项的格式如下所示：
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_CLIENT_LINK | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_CLIENT_LINK | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_CLIENT_LINK (48)
选项代码选项LQ客户端链接（48）
option-len Length of the list of links in octets; must be a multiple of 16.
选项len链接列表的长度（以八位字节为单位）；必须是16的倍数。
link-address A global address used by the server to identify the link on which the client is located.
链接地址服务器用于标识客户端所在链接的全局地址。
A server may respond to a query by client-id, where the 0::0 link-address was specified, with this option if the client is found to be on multiple links. The requestor may then repeat the query once for each link-address returned in the list, specifying the returned link-address. If the client is on a single link, the server SHOULD return the client's data in an OPTION_CLIENT_DATA option.
如果发现客户机位于多个链接上，则服务器可以通过指定了0:：0链接地址的客户机id响应查询，并使用此选项。然后，请求者可以为列表中返回的每个链接地址重复查询一次，并指定返回的链接地址。如果客户机位于单个链接上，则服务器应在OPTION\u client\u data选项中返回客户机的数据。
The following new status codes are defined:
定义了以下新的状态代码：
UnknownQueryType (7) - The query-type is unknown to or not supported by the server.
UnknownQueryType（7）—服务器不知道或不支持查询类型。
MalformedQuery (8) - The query is not valid; for example, a required query-option is missing from the OPTION_LQ_QUERY.
格式错误的查询（8）-该查询无效；例如，选项\u LQ\u查询中缺少必需的查询选项。
NotConfigured (9) - The server does not have the target address or link in its configuration.
NotConfigured（9）-服务器的配置中没有目标地址或链接。
NotAllowed (10) - The server does not allow the requestor to issue this LEASEQUERY.
NotAllowed（10）-服务器不允许请求者发出此请求。
This section presents a table of values used to describe the message transmission behavior for leasequery.
本节提供了一个值表，用于描述leasequery的消息传输行为。
Parameter Default Description
----------------------------------
LQ_TIMEOUT 1 sec Initial LEASEQUERY timeout
LQ_MAX_RT 10 secs Max LEASEQUERY timeout value
LQ_MAX_RC 5 Max LEASEQUERY retry attempts
Parameter Default Description
----------------------------------
LQ_TIMEOUT 1 sec Initial LEASEQUERY timeout
LQ_MAX_RT 10 secs Max LEASEQUERY timeout value
LQ_MAX_RC 5 Max LEASEQUERY retry attempts
Requestors and clients MUST discard any received LEASEQUERY messages.
请求者和客户端必须丢弃任何收到的LEASEQUERY消息。
Servers MUST discard any received LEASEQUERY messages that meet any of the following conditions:
服务器必须丢弃任何接收到的满足以下任何条件的LEASEQUERY消息：
o the message does not include an OPTION_CLIENTID option.
o 该消息不包括选项\客户端ID选项。
o the message includes an OPTION_SERVERID option but the contents of the OPTION_SERVERID option does not match the server's identifier.
o 消息包含选项\u SERVERID选项，但选项\u SERVERID选项的内容与服务器的标识符不匹配。
o the message does not include an OPTION_LQ_QUERY option.
o 该消息不包括选项\u LQ\u查询选项。
Requestors MUST discard any received LEASEQUERY-REPLY messages that meet any of the following conditions:
请求者必须丢弃任何收到的满足以下任何条件的LEASEQUERY-REPLY消息：
o the message does not include an OPTION_SERVERID option.
o 该消息不包括选项\u SERVERID选项。
o the message does not include an OPTION_CLIENTID option, or the contents of the OPTION_CLIENTID option do not match the DUID of the requestor.
o 消息不包含选项\u CLIENTID选项，或者选项\u CLIENTID选项的内容与请求者的DUID不匹配。
o the "transaction-id" field in the message does not match the value used in the original message.
o 消息中的“事务id”字段与原始消息中使用的值不匹配。
Servers and Relay Agents (on the server port, 547 [2]) MUST discard any received LEASEQUERY-REPLY messages.
服务器和中继代理（在服务器端口上，547[2]）必须丢弃任何接收到的LEASEQUERY-REPLY消息。
This section describes how a requestor initiates lease data retrieval from DHCPv6 servers.
本节描述请求者如何从DHCPv6服务器启动租赁数据检索。
The requestor sets the "msg-type" field to LEASEQUERY. The requestor generates a transaction ID and inserts this value in the "transaction-id" field.
请求者将“msg type”字段设置为LEASEQUERY。请求者生成事务ID并将该值插入“事务ID”字段。
The requestor MUST include an OPTION_CLIENTID option to identify itself to the server.
请求者必须包含一个选项\u CLIENTID选项，以便向服务器标识自己。
The requestor MUST include an OPTION_LQ_QUERY option and set the query-type, link-address, and query-options as appropriate to the query-type (Section 4.1.2.1).
请求者必须包括一个选项，并根据查询类型设置查询类型、链接地址和查询选项（第4.1.2.1节）。
The requestor SHOULD include an OPTION_SERVERID if it is not unicasting the LEASEQUERY yet only wants a response from a specific server.
如果请求者没有单播LEASEQUERY，但只需要特定服务器的响应，则请求者应该包含一个选项\u SERVERID。
The requestor MAY be configured to use a list of destination addresses, which MAY include unicast addresses, the All_DHCP_Servers multicast address, or other addresses selected by the network administrator. If the requestor has not been explicitly configured, it MAY use the All_DHCP_Servers multicast address as the default.
请求者可被配置为使用目的地地址列表，其可包括单播地址、所有DHCP服务器多播地址或网络管理员选择的其他地址。如果请求程序尚未明确配置，它可能会使用All_DHCP_Servers多播地址作为默认地址。
The requestor SHOULD send LEASEQUERY to one or more DHCPv6 servers that are known to possess authoritative information concerning the query target.
请求者应该向一个或多个DHCPv6服务器发送LEASEQUERY，这些服务器已知拥有有关查询目标的权威信息。
In the absence of information concerning which DHCPv6 servers might possess authoritative information on the query target, the requestor SHOULD send LEASEQUERY to all DHCPv6 servers that the requestor knows about or is configured with. For example, the requestor MAY send LEASEQUERY to the All_DHCP_Servers multicast address.
如果没有关于哪些DHCPv6服务器可能拥有查询目标的权威信息的信息，请求者应该向请求者知道或配置的所有DHCPv6服务器发送LEASEQUERY。例如，请求者可以向All_DHCP_服务器多播地址发送LEASEQUERY。
The requestor transmits LEASEQUERY messages according to Section 14 of [2], using the following parameters:
请求者根据[2]第14节的规定，使用以下参数传输租赁信息：
IRT LQ_TIMEOUT MRT LQ_MAX_RT MRC LQ_MAX_RC MRD 0
IRT LQ_超时MRT LQ_最大值\u RT MRC LQ_最大值\u RC MRD 0
If the message exchange fails, the requestor takes an action based on the requestor's local policy. Examples of actions the requestor might take include:
如果消息交换失败，请求者将根据请求者的本地策略采取操作。请求者可能采取的行动示例包括：
o Select another server from a list of servers known to the requestor.
o 从请求者已知的服务器列表中选择另一个服务器。
o Send to multiple servers by multicasting to the All_DHCP_Servers address.
o 通过多播发送到All_DHCP_服务器地址，发送到多个服务器。
o Terminate the request.
o 终止请求。
A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE option (or an OPTION_STATUS_CODE option with a success code). There are three variants:
成功的LEASQUERY-REPLY是一个没有选项\状态\代码选项（或带有成功代码的选项\状态\代码选项）的回复。有三种变体：
1. If the server had bindings for the requested client, the message includes an OPTION_CLIENT_DATA option and the requestor extracts the client data from the LEASEQUERY-REPLY and updates its binding information database. If the OPTION_CLIENT_DATA contains no OPTION_CLT_TIME, the requestor SHOULD silently discard the OPTION_CLIENT_DATA option.
1. 如果服务器具有所请求客户端的绑定，则消息将包含选项\u client\u DATA选项，请求者将从LEASEQUERY-REPLY中提取客户端数据并更新其绑定信息数据库。如果选项_CLIENT _DATA不包含选项_CLT _TIME，请求者应自动放弃选项_CLIENT _DATA选项。
2. If the server found bindings for the client on multiple links, the message includes an OPTION_CLIENT_LINK option. The requestor will need to reissue LEASEQUERY messages using each of the returned link-addresses to obtain the client's bindings.
2. 如果服务器在多个链接上找到客户端的绑定，则消息将包含选项\u client\u LINK选项。请求者需要使用每个返回的链接地址重新发出LEASEQUERY消息，以获取客户端的绑定。
3. If the server had no bindings for the client, neither the OPTION_CLIENT_DATA nor OPTION_CLIENT_LINK option will be present.
3. 如果服务器没有客户端的绑定，则不会出现选项\u client\u DATA或选项\u client\u LINK选项。
An unsuccessful LEASEQUERY-REPLY is one that has an OPTION_STATUS_CODE with an error code. Depending on the status code, the requestor may try a different server (such as for NotAllowed, NotConfigured, and UnknownQueryType), try a different or corrected query (such as for UnknownQueryType and MalformedQuery), or terminate the query.
不成功的LEASEQUERY-REPLY是一个带有错误代码的选项“状态”代码。根据状态代码的不同，请求者可能会尝试不同的服务器（例如NotAllowed、NotConfigured和UnknownQueryType），尝试不同的或更正的查询（例如UnknownQueryType和MalformedQuery），或者终止查询。
A requestor may receive lease data on the same client from the same DHCPv6 server in response to different types of LEASEQUERY. If a LEASEQUERY is sent to multiple servers, the requestor may receive from several servers lease data on the same DHCPv6 client. This section describes how the requestor handles multiple lease data sources on the same DHCPv6 client from the same server or different servers.
请求者可以在同一客户机上从同一DHCPv6服务器接收租赁数据，以响应不同类型的租赁。如果向多个服务器发送租赁请求，请求者可能会从同一DHCPv6客户端上的多个服务器接收租赁数据。本节描述请求者如何处理来自同一服务器或不同服务器的同一DHCPv6客户端上的多个租赁数据源。
The client data from the different sources may be disjoint or overlapping. The disjoint and overlapping relationship can happen between data from the same server or different servers.
来自不同来源的客户端数据可能不相交或重叠。来自同一服务器或不同服务器的数据之间可能存在不相交和重叠关系。
If client data from two sources on the same client are of different types or values, then the data are disjoint. An example of data of different types is when a requestor receives an IPv6 address lease from one server and a prefix lease from another server, both assigned to the same client. An example of different values (but the same type) is when a requestor receives two IPv6 address leases from two different servers, both assigned to the same client, but the leases are on two different IPv6 addresses. If the requestor receives disjoint client data from different sources, it SHOULD merge them.
如果来自同一客户机上两个源的客户机数据的类型或值不同，则这些数据是不相交的。不同类型数据的一个示例是，请求者从一台服务器接收IPv6地址租约和从另一台服务器接收前缀租约，这两种租约都分配给同一个客户端。不同值（但类型相同）的一个示例是，请求者从两个不同的服务器接收两个IPv6地址租约，这两个服务器都分配给同一个客户端，但租约位于两个不同的IPv6地址上。如果请求者从不同的来源接收到不相交的客户机数据，它应该合并它们。
If client data from two sources on the same client are of the same type and value, then the data are overlapping. An example of overlapping data is when a requestor receives a lease on the same IPv6 address from two different servers. Overlapping client data are also called conflicting data.
如果来自同一客户机上两个源的客户机数据具有相同的类型和值，则这些数据是重叠的。重叠数据的一个例子是，请求者从两个不同的服务器接收到相同IPv6地址的租约。重叠的客户机数据也称为冲突数据。
The requestor SHOULD use the OPTION_CLT_TIME to resolve data conflicts originated from different servers, and SHOULD accept data with most recent OPTION_CLT_TIME.
请求者应使用选项_CLT_TIME来解决来自不同服务器的数据冲突，并应接受具有最新选项_CLT_TIME的数据。
A DHCPv6 server sends LEASEQUERY-REPLY messages in response to valid LEASEQUERY messages it receives to return the statefully assigned addresses, delegated prefixes, and other information that match the query.
DHCPv6服务器发送LEASEQUERY-REPLY消息以响应其接收到的有效LEASEQUERY消息，以返回状态分配的地址、委派的前缀以及与查询匹配的其他信息。
Upon receipt of a valid LEASEQUERY message, the DHCPv6 server locates the requested client, collects data on the client, and constructs and returns a LEASEQUERY-REPLY. A LEASEQUERY message cannot be used to assign, release, or otherwise modify bindings or other configuration information.
收到有效的LEASEQUERY消息后，DHCPv6服务器将定位请求的客户端，收集客户端上的数据，并构造并返回LEASEQUERY-REPLY。LEASEQUERY消息不能用于分配、释放或以其他方式修改绑定或其他配置信息。
The server constructs a LEASEQUERY-REPLY message by setting the "msg-type" field to LEASEQUERY-REPLY, and copying the transaction ID from the LEASEQUERY message into the transaction-id field.
服务器通过将“msg type”字段设置为LEASEQUERY-REPLY，并将事务ID从LEASEQUERY消息复制到事务ID字段中，来构造LEASEQUERY-REPLY消息。
If the query-type in the OPTION_LQ_QUERY option is not a known or supported value, the server adds an OPTION_STATUS_CODE option with the UnknownQueryType status code and sends the LEASEQUERY-REPLY to the requestor. If the query-options do not contain the required options for the query-type, the server adds an OPTION_STATUS_CODE option with the MalformedQuery status code and sends the LEASEQUERY-REPLY to the client.
如果选项\u LQ\u query选项中的查询类型不是已知或受支持的值，服务器将添加带有未知查询类型状态代码的选项\u STATUS\u CODE选项，并向请求者发送LEASEQUERY-REPLY。如果查询选项不包含查询类型所需的选项，服务器将添加一个带有格式错误的查询状态代码的选项\u STATUS\u CODE选项，并向客户端发送LEASEQUERY-REPLY。
A server may also restrict LEASEQUERY messages, or query-types, to certain requestors. In this case, the server MAY discard the LEASEQUERY message or MAY add an OPTION_STATUS_CODE option with the NotAllowed status code and send the LEASEQUERY-REPLY to the requestor.
服务器还可以将LEASEQUERY消息或查询类型限制为某些请求者。在这种情况下，服务器可能会丢弃LEASEQUERY消息，或者可能会添加带有不允许状态代码的选项\状态\代码选项，并将LEASEQUERY-REPLY发送给请求者。
If the OPTION_LQ_QUERY specified a non-zero link-address, the server MUST use the link-address to find the appropriate link for the client. For a QUERY_BY_ADDRESS, if the 0::0 link-address was specified, the server uses the address from the OPTION_IAADDR option to find the appropriate link for the client. In either of these cases, if the server is unable to find the link, it SHOULD return an OPTION_STATUS_CODE option with the NotConfigured status and send the LEASEQUERY-REPLY to the requestor.
如果选项_LQ_查询指定了非零链接地址，则服务器必须使用该链接地址为客户端查找适当的链接。对于按地址查询，如果指定了0:：0链接地址，服务器将使用选项\u IAADDR选项中的地址为客户端查找适当的链接。在这两种情况下，如果服务器找不到链接，它应该返回一个带有NotConfigured状态的OPTION_STATUS_CODE选项，并向请求者发送LEASQUERY-REPLY。
For a QUERY_BY_CLIENTID, if a 0::0 link-address was specified, the server MUST search all of its links for the client. If the client is only found on a single link, the server SHOULD return that client's data in an OPTION_CLIENT_DATA option. If the client is found on more
对于\u BY \u CLIENTID查询，如果指定了0:：0链接地址，则服务器必须在其所有链接中搜索客户端。如果只在单个链接上找到客户机，则服务器应在OPTION\u client\u data选项中返回该客户机的数据。如果在多个服务器上找到客户端
than a single link, the server MUST return the list of links in the OPTION_CLIENT_LINK option; the server MUST NOT return any client data.
而不是单个链接，服务器必须返回选项\u CLIENT\u link选项中的链接列表；服务器不得返回任何客户端数据。
Otherwise, the server uses the data in the OPTION_LQ_QUERY to initiate the query. The result of the query will be zero or one client. This will result in zero or one OPTION_CLIENT_DATA option being added to the LEASEQUERY-REPLY.
否则，服务器将使用选项\u LQ\u查询中的数据来启动查询。查询结果将为零或一个客户端。这将导致在LEASEQUERY-REPLY中添加零个或一个选项\客户端\数据选项。
An OPTION_CLIENT_DATA option in a LEASEQUERY-REPLY message MUST minimally contain the following options: 1. OPTION_CLIENTID 2. OPTION_IAADDR and/or OPTION_IAPREFIX 3. OPTION_CLT_TIME
LEASQUERY-REPLY消息中的选项\客户端\数据选项必须至少包含以下选项：1。选项2。选项添加和/或选项添加前缀3。选项\u CLT\u时间
Depending on the bindings the client has on a link, either OPTION_IAADDR options, OPTION_IAPREFIX options, or both may be present.
根据客户端在链接上的绑定，可能存在选项\ IAADDR选项、选项\ IAPREFIX选项或两者。
The OPTION_CLIENT_DATA SHOULD include options requested in the OPTION_ORO of the OPTION_LQ_QUERY option in the LEASEQUERY message and that are acceptable to return based on the list of "sensitive options", discussed below.
选项客户数据应包括在租赁请求消息中的选项查询选项的选项ORO中请求的选项，这些选项可根据下面讨论的“敏感选项”列表返回。
DHCPv6 servers SHOULD be configurable with a list of "sensitive options" that must not be returned to the requestor when specified in the OPTION_ORO of the OPTION_LQ_QUERY option in the LEASEQUERY message. Any option on this list MUST NOT be returned to a requestor, even if requested by that requestor.
DHCPv6服务器应配置一个“敏感选项”列表，当在LEASQUERY消息中的OPTION_LQ_查询选项的OPTION_ORO中指定时，该列表不得返回给请求者。不得将此列表上的任何选项返回给请求者，即使该请求者已请求。
The server sends the LEASEQUERY-REPLY message as described in the "Transmission of Reply Messages" section of [2].
服务器发送LEASQUERY-REPLY消息，如[2]的“回复消息的传输”部分所述。
Access concentrators are expected to be common leasequery requestors. Access concentrators that use DHCPv6 gleaning (i.e., [10]), refreshed with LEASEQUERY messages, will maintain accurate client/binding information. This ensures that the access concentrator can forward data traffic to the intended destination in the broadband access network, can perform IPv6 source address verification of datagrams from the access network, and can encrypt traffic that can only be
访问集中器应该是常见的租赁请求器。使用DHCPv6收集（即，[10]）的访问集中器使用LEASEQUERY消息刷新，将维护准确的客户端/绑定信息。这确保了接入集中器可以将数据流量转发到宽带接入网络中的预期目的地，可以对来自接入网络的数据报执行IPv6源地址验证，并且可以对只能进行加密的流量进行加密
decrypted by the intended access modem (e.g., [12] and [13]). Thus, the leasequery capability allows an access concentrator to provide considerably enhanced security.
由预期接入调制解调器解密（例如，[12]和[13]）。因此，租赁能力允许接入集中器提供显著增强的安全性。
The "Security Considerations" section of [2] details the general threats to DHCPv6, and thus to LEASEQUERY messages. The "Authentication of DHCP Messages" section of [2] describes securing communication between relay agents and servers, as well as clients and servers. If the requestor is an access concentrator, the IPsec-based [9] security as described in [2] Section 21.1 SHOULD be used. Other types of requestors are essentially DHCPv6 clients. Thus, DHCPv6 authentication, Section 21 of [2], is an appropriate mechanism for securing LEASEQUERY and LEASEQUERY-REPLY messages. As the number of leasequery requestors and servers in an administrative domain is relatively small, any shared key distribution issues are minimized.
[2]的“安全注意事项”部分详细说明了DHCPv6面临的一般威胁，从而也详细说明了对LEASEQUERY消息的威胁。[2]的“DHCP消息的身份验证”部分描述了中继代理和服务器以及客户端和服务器之间的通信安全。如果请求者是访问集中器，则应使用第21.1节[2]中描述的基于IPsec的[9]安全性。其他类型的请求程序本质上是DHCPv6客户机。因此，DHCPv6身份验证（见[2]第21节）是保护LEASEQUERY和LEASEQUERY-REPLY消息的适当机制。由于管理域中的leasequery请求者和服务器的数量相对较少，因此任何共享密钥分发问题都被最小化。
After implementing the above approaches, the DHCPv6 server should only be communicating with trusted LEASEQUERY requestors, and so security needs should be met.
在实现了上述方法之后，DHCPv6服务器应该只与受信任的租赁请求者通信，因此应该满足安全需求。
However, not all traffic originates directly from these trusted requestors. For example, trusted relay agents can relay LEASEQUERY messages from untrusted requestors or elsewhere in the network. This SHOULD be prevented at least at the perimeter relay agents (or on all relay agents unless relayed LEASEQUERY messages are required for some requestors). DHCPv6 servers MAY be configured to discard relayed LEASEQUERY messages or restrict relay chaining.
然而，并非所有流量都直接来自这些受信任的请求者。例如，受信任的中继代理可以中继来自不受信任的请求者或网络中其他地方的LEASEQUERY消息。至少在外围中继代理上（或者在所有中继代理上，除非某些请求者需要中继的LEASEQUERY消息），应该防止这种情况发生。DHCPv6服务器可配置为丢弃中继的租赁消息或限制中继链接。
DHCPv6 servers SHOULD also provide for the ability to restrict the information returned for a client in a LEASEQUERY-REPLY even to a trusted LEASEQUERY requestor, as described in Section 4.4.2.
如第4.4.2节所述，DHCPv6服务器还应能够限制在LEASEQUERY-REPLY中为客户返回的信息，即使是对受信任的LEASEQUERY请求者。
Since even trusted access concentrators may generate LEASEQUERY requests as a result of activity external to the access concentrator, access concentrators SHOULD minimize potential denial-of-service attacks on the DHCPv6 servers by minimizing the generation of LEASEQUERY messages. In particular, the access concentrator SHOULD employ negative caching (i.e., cache the fact that a particular recent query failed to return client data) and address restrictions where possible (i.e., don't send a LEASEQUERY message for addresses outside the range of the attached broadband access networks). Together, these mechanisms limit the access concentrator to transmitting one LEASEQUERY message (excluding message retries) per legitimate broadband access network address after a reboot event.
由于即使是受信任的访问集中器也可能由于访问集中器外部的活动而生成LEASEQUERY请求，因此访问集中器应通过最小化LEASEQUERY消息的生成来最小化DHCPv6服务器上的潜在拒绝服务攻击。特别是，接入集中器应尽可能采用负缓存（即缓存某个特定的最近查询未能返回客户端数据的事实）和地址限制（即，不为连接的宽带接入网络范围之外的地址发送LEASEQUERY消息）。总之，这些机制将访问集中器限制为在重新启动事件后每个合法宽带访问网络地址发送一条LEASEQUERY消息（不包括消息重试）。
Packet-flooding denial-of-service attacks can result in the exhaustion of processing resources, thus preventing the server from serving legitimate and regular DHCPv6 clients as well as legitimate
数据包泛滥拒绝服务攻击可能导致处理资源耗尽，从而阻止服务器为合法和常规DHCPv6客户端以及合法的DHCPv6客户端提供服务
DHCPv6 LEASEQUERY requestors, denying configurations to legitimate DHCPv6 clients as well lease information to legitimate DHCPv6 LEASEQUERY requestors. While these attacks are unlikely when only communicating with trusted LEASEQUERY requestors, the possibility always exists that the trust is misplaced, security techniques are compromised, or even trusted requestors can have bugs in them. Therefore, techniques for defending against packet-flooding denial of service are always a good idea, and they include good perimeter security, as mentioned earlier, and rate limiting DHCPv6 traffic by relay agents, other network elements, or the server itself.
DHCPv6租赁请求者，拒绝向合法的DHCPv6客户端配置以及向合法的DHCPv6租赁请求者租赁信息。虽然这些攻击在仅与受信任的LEASEQUERY请求者通信时不太可能发生，但始终存在信任错位、安全技术受损或甚至受信任的请求者可能存在漏洞的可能性。因此，防范数据包泛滥拒绝服务的技术总是一个好主意，它们包括良好的外围安全性（如前所述），以及中继代理、其他网络元素或服务器本身对DHCPv6流量的速率限制。
One way to attack an access concentrator (as opposed to a DHCPv6 server) as a LEASEQUERY requestor is the establishment of a malicious server with the intent of providing incorrect lease or route information to the access concentrator, thwarting source IPv6 address verification, and preventing correct routing. This type of attack can be minimized by using IPsec as described in Section 21.1 of [2].
攻击作为租赁请求者的访问集中器（与DHCPv6服务器相反）的一种方法是建立恶意服务器，目的是向访问集中器提供不正确的租赁或路由信息，阻止源IPv6地址验证，并阻止正确的路由。如[2]第21.1节所述，可通过使用IPsec将此类攻击降至最低。
IANA has assigned the following new DHCPv6 Message types in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters:
IANA在中维护的注册表中分配了以下新的DHCPv6消息类型http://www.iana.org/assignments/dhcpv6-parameters:
LEASEQUERY LEASEQUERY-REPLY
LEASEQUERY LEASEQUERY-REPLY
IANA has assigned the following new DHCPv6 Option Codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters:
IANA在中维护的注册表中分配了以下新的DHCPv6选项代码：http://www.iana.org/assignments/dhcpv6-parameters:
OPTION_LQ_QUERY OPTION_CLIENT_DATA OPTION_CLT_TIME OPTION_LQ_RELAY_DATA OPTION_LQ_CLIENT_LINK
选项查询选项客户端数据选项CLT时间选项中继数据选项客户端链接
IANA has assigned the following new DHCPv6 Status Codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters:
IANA在中维护的注册表中分配了以下新的DHCPv6状态代码：http://www.iana.org/assignments/dhcpv6-parameters:
UnknownQueryType MalformedQuery NotConfigured NotAllowed
UnknownQueryType格式错误查询未配置不允许
IANA has created a new registry for the OPTION_LQ_QUERY option query-type codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters with the following initial assignments:
IANA已为中维护的注册表中的选项查询选项查询类型代码创建了一个新注册表http://www.iana.org/assignments/dhcpv6-parameters 完成以下初始任务：
QUERY_BY_ADDRESS 1 QUERY_BY_CLIENTID 2
查询人地址1查询人客户ID 2
New OPTION_LQ_QUERY option query-type codes are assigned through Standards Action, as defined in [6].
新选项查询选项查询类型代码通过标准操作分配，如[6]中所定义。
Thanks to Ralph Droms, Richard Johnson, Josh Littlefield, Hemant Singh, Pak Siripunkaw, Markus Stenberg, and Ole Troan for their input, ideas, and review during the production of this document.
感谢拉尔夫·德罗姆斯、理查德·约翰逊、乔什·利特菲尔德、赫曼特·辛格、帕克·西里蓬考、马库斯·斯滕伯格和奥勒·特罗安在本文件制作过程中的投入、想法和评论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[2] Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[3] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[3] Woundy，R.和K.Kinnear，“动态主机配置协议（DHCP）租赁”，RFC 4388，2006年2月。
[4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[4] Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[5] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[7] Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC24611998年12月。
[8] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[8] Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[9] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[9] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[10] Droms, R., "DHCPv6 Relay Agent Assignment Notification (RAAN) Option", Work in Progress, November 2006.
[10] Droms，R.，“DHCPv6中继代理分配通知（RAAN）选项”，正在进行的工作，2006年11月。
[11] CableLabs, "Data-Over-Cable Service Interface Specifications: DOCSIS 3.0, MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.0-I04-070518", May 2007, available at http://www.cablemodem.com/.
[11] CableLabs，“有线数据服务接口规范：DOCSIS 3.0，MAC和上层协议接口规范，CM-SP-MULPIv3.0-I04-070518”，2007年5月，可在http://www.cablemodem.com/.
[12] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface Specification SCTE 22-2 2002", 2002, available at http://www.scte.org/standards/.
[12] SCTE数据标准小组委员会，“有线数据服务接口规范：DOCSIS 1.0基线隐私接口规范SCTE 22-2 2002”，2002年，可访问http://www.scte.org/standards/.
[13] CableLabs, "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12- 050812", August 2005, available at http://www.cablemodem.com/.
[13] CableLabs，“有线数据服务接口规范：基线隐私加接口规范CM-SP-BPI+_I12-050812”，2005年8月，可在http://www.cablemodem.com/.
Authors' Addresses
作者地址
John Jason Brzozowski Comcast Cable 1800 Bishops Gate Boulevard Mt. Laurel, NJ 08054 USA
美国新泽西州劳雷尔山主教门大道1800号John Jason Brzowski Comcast电缆，邮编：08054
Phone: +1 856 324 2671
EMail: john_brzozowski@cable.comcast.com
Phone: +1 856 324 2671
EMail: john_brzozowski@cable.comcast.com
Kim Kinnear Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Kim Kinnear Cisco Systems，Inc.美国马萨诸塞州博克斯堡大道1414号，邮编01719
Phone: +1 978 936 0000
EMail: kkinnear@cisco.com
Phone: +1 978 936 0000
EMail: kkinnear@cisco.com
Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
伯纳德·沃兹思科系统公司，美国马萨诸塞州博克斯伯勒马萨诸塞大道1414号，邮编01719
Phone: +1 978 936 0000
EMail: volz@cisco.com
Phone: +1 978 936 0000
EMail: volz@cisco.com
Shengyou Zeng Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
盛友曾思科系统有限公司，美国马萨诸塞州博克斯堡马萨诸塞大道1414号，邮编01719
Phone: +1 978 936 0000
EMail: szeng@cisco.com
Phone: +1 978 936 0000
EMail: szeng@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.