[要約] RFC 5007は、DHCPv6 Leasequeryプロトコルの仕様を定義しており、DHCPv6サーバーに対してリース情報を問い合わせるためのメカニズムを提供します。目的は、ネットワーク管理者がリース情報を効果的に監視し、ネットワークのパフォーマンスやセキュリティを向上させることです。
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 Leasequery
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.
このドキュメントでは、DHCPv6サーバーからDHCPv6クライアントに関するリース情報を取得するために使用できるIPv6の動的ホスト構成プロトコル（DHCPv6）のleasequery交換について説明します。このドキュメントでは、取得できるデータの範囲と、DHCPv6リースクエリリクエスタとサーバーの動作の両方を指定します。このドキュメントは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
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 [4]のIPv6プレフィックスオプションは、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.
DHCPv6 [2]を活用してDHCPv6サーバーの操作に関連するデータをプログラムで取得するための要件は、さまざまな種類のIPv6展開、特にブロードバンドの展開に存在します。特に、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によるものです。たとえば、ネイバー探索[7]はIPv6でアドレス解決プロトコル（ARP）[8]（[3]のセクション4.1）ではなく使用され、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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [1]で説明されているように解釈されます。
DHCPv6 terminology is defined in [2]. Terminology specific to DHCPv6 leasequery can be found below:
DHCPv6の用語は、[2]で定義されています。 DHCPv6 leasequeryに固有の用語は次のとおりです。
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.
client（s）DHCPv6サーバーとの1つ以上のバインディングを持つノード。これ自体は、DHCPv6サーバーとの1つ以上のバインディングがない限り、LEASEQUERYを発行するノードを指しません。
gleaning Gleaning is the extraction of location information from DHCPv6 messages, as the messages are forwarded by the DHCP relay agent function.
グリーニンググリーニングとは、メッセージがDHCPリレーエージェント機能によって転送されるため、DHCPv6メッセージから位置情報を抽出することです。
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.
リクエスタクライアントのバインディングに関する情報を取得するために、1つ以上のサーバーに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.
重要な動機の1つの例は、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サーバーから情報を要求するための2番目のアプローチは、リースクエリのような機能を使用して、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）によるクエリ-このクエリを使用すると、リクエスタはサーバーから、特定のリンク上の特定のクライアントのバインディング、またはクライアントが1つ以上のバインディングを持つリンクのリストを要求できます。
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メッセージは、[2]のセクション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メッセージを送信します。 OPTION_LQ_QUERYのオプションは、クエリを決定します。
LEASEQUERY-REPLY (15) - A server sends a LEASEQUERY-REPLY message containing client data in response to a LEASEQUERY message.
LEASEQUERY-REPLY（15）-サーバーは、LEASEQUERYメッセージへの応答として、クライアントデータを含むLEASEQUERY-REPLYメッセージを送信します。
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_QUERY (44)
オプションコードOPTION_LQ_QUERY（44）
option-len 17 + length of query-options field.
option-len 17 + query-optionsフィールドの長さ。
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.
link-addressクエリが適用されるリンクを識別するためにサーバーによって使用されるグローバルアドレス。指定されていない場合は0 :: 0。
query-type The query requested (see below).
query-type要求されたクエリ（下記参照）。
query-options The options related to the query.
query-optionsクエリに関連するオプション。
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).
QUERY_BY_ADDRESS（1）-query-optionsには、OPTION_IAADDRオプション[2]が含まれている必要があります。 link-addressフィールドは、0 :: 0でない場合、OPTION_IAADDRオプションのアドレスのスコープが不十分な場合に、クライアントが配置されているリンクのアドレスを指定します。指定されたアドレスのリースを持つクライアント、または指定されたアドレスを含むプレフィックスが委任されたクライアントの情報のみが返されます（可能な場合）。
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_BY_CLIENTID（2）-query-optionsには、OPTION_CLIENTIDオプション[2]が含まれている必要があります。 link-addressフィールドは、0 :: 0でない場合、クライアントが配置されているリンクのアドレスを指定します。 link-addressフィールドが0 :: 0の場合、サーバーはクライアントのすべてのリンクを検索する必要があります（SHOULD）。
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.
query-optionsには、リクエスタがサーバーに返してほしい各クライアントのオプションを示すOPTION_OROオプション[2]も含まれる場合があります。このOPTION_OROは、リクエスタのLEASEQUERYメッセージに含まれる可能性のあるOPTION_OROとは異なり、別個のものであることに注意してください。
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.
サーバーが、サポートしていないクエリタイプのOPTION_LQ_QUERYを受信した場合、サーバーはUnknownQueryTypeステータスコードを返す必要があります（SHOULD）。サーバーがサポートされているクエリタイプを受信したが、query-optionsに必要なオプションがない場合、サーバーはMalformedQueryステータスコードを返す必要があります。
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENT_DATA (45)
オプションコードOPTION_CLIENT_DATA（45）
option-len Length, in octets, of the encapsulated client-options field.
option-lenカプセル化されたclient-optionsフィールドの長さ（オクテット単位）。
client-options The options associated with this client.
client-optionsこのクライアントに関連付けられたオプション。
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.
カプセル化されたクライアントオプションには、OPTION_CLIENTID、OPTION_IAADDR、OPTION_IAPREFIX、およびOPTION_CLT_TIMEオプションと、クライアントに固有でOPTION_LQ_QUERYのクエリオプションのOPTION_OROでリクエスタによって要求されたその他のオプションが含まれます。サーバーは、リンク上で、クライアントのステートフルに割り当てられたすべてのアドレスと委任されたプレフィックスを、ゼロ以外の有効な有効期間で返さなければなりません（MUST）。
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.
クライアントの最終トランザクション時間オプションはOPTION_CLIENT_DATAにカプセル化され、サーバーがクライアントと最後に通信してからの経過時間を秒単位で識別します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLT_TIME (46)
オプションコードOPTION_CLT_TIME（46）
option-len 4
オプションのみ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).
client-last-transaction-timeは正の値であり、サーバーが最後に（そのリンク上で）クライアントと通信してからの秒数を反映します。
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.
リレーデータオプションは、LEASEQUERY-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 |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_RELAY_DATA (47)
オプションコードOPTION_LQ_RELAY_DATA（47）
option-len 16 + length of DHCP-relay-message.
option-len 16 + DHCP-relay-messageの長さ。
peer-address The address of the relay agent from which the relayed message was received by the server.
peer-addressリレーされたメッセージがサーバーによって受信されたリレーエージェントのアドレス。
DHCP-relay-message The last complete relayed message, excluding the client's message OPTION_RELAY_MSG, received by the server.
DHCP-relay-messageサーバーが受信した、クライアントのメッセージOPTION_RELAY_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-relay-messageには、クライアントがサーバーが最後に受信した有効な（おそらくマルチホップの）RELAY-FORWメッセージが含まれている必要があります。ただし、クライアントのメッセージを含む（最も内側の）OPTION_RELAY_MSGオプションは削除されている必要があります。
This option SHOULD only be returned if requested by the OPTION_ORO of the OPTION_LQ_QUERY.
このオプションは、OPTION_LQ_QUERYのOPTION_OROによって要求された場合にのみ返されるべきです（SHOULD）。
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.
クライアントリンクオプションは、LEASEQUERY-REPLYメッセージでのみ使用され、クライアントが1つ以上のバインディングを持つリンクを識別します。リンクアドレスが指定されておらず、クライアントが複数のリンク上にあることが判明した場合に、クエリへの応答で使用されます。
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_CLIENT_LINK (48)
オプションコードOPTION_LQ_CLIENT_LINK（48）
option-len Length of the list of links in octets; must be a multiple of 16.
option-lenオクテット単位のリンクリストの長さ。 16の倍数でなければなりません。
link-address A global address used by the server to identify the link on which the client is located.
link-addressクライアントが配置されているリンクを識別するためにサーバーが使用するグローバルアドレス。
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リンクアドレスが指定されたclient-idによるクエリに応答できます。次に、リクエスタは、返されたリンクアドレスを指定して、リストに返されたリンクアドレスごとにクエリを1回繰り返します。クライアントが単一のリンク上にある場合、サーバーはOPTION_CLIENT_DATAオプションでクライアントのデータを返す必要があります（SHOULD）。
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.
MalformedQuery（8）-クエリが無効です。たとえば、OPTION_LQ_QUERYに必要なクエリオプションがありません。
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）-サーバーは、要求者がこのLEASEQUERYを発行することを許可しません。
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
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 メッセージにはOPTION_CLIENTIDオプションが含まれていません。
o the message includes an OPTION_SERVERID option but the contents of the OPTION_SERVERID option does not match the server's identifier.
o メッセージにOPTION_SERVERIDオプションが含まれていますが、OPTION_SERVERIDオプションの内容がサーバーの識別子と一致しません。
o the message does not include an OPTION_LQ_QUERY option.
o メッセージにはOPTION_LQ_QUERYオプションが含まれていません。
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 メッセージにはOPTION_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 メッセージにOPTION_CLIENTIDオプションが含まれていないか、OPTION_CLIENTIDオプションの内容が要求者のDUIDと一致しません。
o the "transaction-id" field in the message does not match the value used in the original message.
o メッセージの「transaction-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を生成し、この値を「transaction-id」フィールドに挿入します。
The requestor MUST include an OPTION_CLIENTID option to identify itself to the server.
リクエスタは、サーバーに対して自身を識別するためにOPTION_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).
リクエスタはOPTION_LQ_QUERYオプションを含め、クエリタイプ、リンクアドレス、およびクエリオプションをクエリタイプに適切に設定する必要があります（セクション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をユニキャストしておらず、特定のサーバーからの応答のみが必要な場合は、OPTION_SERVERIDを含める必要があります（SHOULD）。
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.
リクエスタは、宛先アドレスのリストを使用するように構成できます。これには、ユニキャストアドレス、All_DHCP_Serversマルチキャストアドレス、またはネットワーク管理者が選択した他のアドレスが含まれる場合があります。リクエスタが明示的に構成されていない場合、デフォルトとして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.
リクエスタは、クエリターゲットに関する信頼できる情報を持っていることがわかっている1つ以上のDHCPv6サーバーにLEASEQUERYを送信する必要があります（SHOULD）。
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を送信する必要があります（SHOULD）。たとえば、リクエスターは、LEASEQUERYをAll_DHCP_Serversマルチキャストアドレスに送信してもよい（MAY）。
The requestor transmits LEASEQUERY messages according to Section 14 of [2], using the following parameters:
リクエスタは、次のパラメータを使用して、[2]のセクション14に従ってLEASEQUERYメッセージを送信します。
IRT LQ_TIMEOUT MRT LQ_MAX_RT MRC LQ_MAX_RC MRD 0
IRT LQ_TIMEOUT MRT LQ_MAX_RT MRC LQ_MAX_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_Serversアドレスにマルチキャストすることにより、複数のサーバーに送信します。
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:
成功したLEASEQUERY-REPLYは、OPTION_STATUS_CODEオプション（または成功コードを含むOPTION_STATUS_CODEオプション）がないものです。 3つのバリアントがあります。
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. サーバーに要求されたクライアントのバインディングがあった場合、メッセージにはOPTION_CLIENT_DATAオプションが含まれ、リクエスターはLEASEQUERY-REPLYからクライアントデータを抽出し、そのバインディング情報データベースを更新します。 OPTION_CLIENT_DATAにOPTION_CLT_TIMEが含まれていない場合、リクエスタはOPTION_CLIENT_DATAオプションをサイレントに破棄する必要があります（SHOULD）。
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. サーバーがクライアントのバインディングを複数のリンクで見つけた場合、メッセージにはOPTION_CLIENT_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. サーバーにクライアントのバインディングがない場合、OPTION_CLIENT_DATAオプションもOPTION_CLIENT_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は、OPTION_STATUS_CODEにエラーコードが含まれているものです。ステータスコードに応じて、リクエスタは別のサーバー（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.
リクエスタは、異なるタイプのLEASEQUERYに応答して、同じDHCPv6サーバーから同じクライアントでリースデータを受信する場合があります。 LEASEQUERYが複数のサーバーに送信される場合、リクエスタは複数のサーバーから同じ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.
同じクライアント上の2つのソースからのクライアントデータのタイプまたは値が異なる場合、データはばらばらになります。異なるタイプのデータの例は、リクエスタが1つのサーバーからIPv6アドレスリースを受信し、別のサーバーからプレフィックスリースを受信した場合です。どちらも同じクライアントに割り当てられています。異なる値（ただし同じタイプ）の例は、リクエスターが2つの異なるサーバーから2つのIPv6アドレスリースを受信した場合で、どちらも同じクライアントに割り当てられていますが、リースは2つの異なる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.
同じクライアント上の2つのソースからのクライアントデータのタイプと値が同じ場合、データは重複しています。重複するデータの例は、リクエスタが2つの異なるサーバーから同じ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.
リクエスターは、OPTION_CLT_TIMEを使用して、異なるサーバーから発生したデータの競合を解決する必要があり（SHOULD）、最新のOPTION_CLT_TIMEのデータを受け入れる必要があります（SHOULD）。
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メッセージに応答してLEASEQUERY-REPLYメッセージを送信し、ステートフルに割り当てられたアドレス、委任されたプレフィックス、およびクエリに一致するその他の情報を返します。
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.
DHCPv6サーバーは、有効なLEASEQUERYメッセージを受信すると、要求されたクライアントを見つけ、クライアントでデータを収集し、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メッセージからtransaction-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.
OPTION_LQ_QUERYオプションのquery-typeが既知の値またはサポートされている値ではない場合、サーバーはUnknownQueryTypeステータスコードを含むOPTION_STATUS_CODEオプションを追加し、LEASEQUERY-REPLYをリクエスタに送信します。 query-optionsにquery-typeに必要なオプションが含まれていない場合、サーバーはMalformedQueryステータスコードを含むOPTION_STATUS_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メッセージを破棄するか、NotAllowedステータスコードを含むOPTION_STATUS_CODEオプションを追加して、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.
OPTION_LQ_QUERYがゼロ以外のリンクアドレスを指定した場合、サーバーはリンクアドレスを使用してクライアントに適切なリンクを見つける必要があります。 QUERY_BY_ADDRESSの場合、0 :: 0リンクアドレスが指定されていると、サーバーはOPTION_IAADDRオプションのアドレスを使用して、クライアントに適切なリンクを見つけます。これらのいずれの場合でも、サーバーがリンクを見つけることができない場合、サーバーはNotConfiguredステータスでOPTION_STATUS_CODEオプションを返し、LEASEQUERY-REPLYを要求者に送信する必要があります（SHOULD）。
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 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.
QUERY_BY_CLIENTIDの場合、0 :: 0リンクアドレスが指定されていると、サーバーはクライアントのすべてのリンクを検索する必要があります。クライアントが単一のリンクでのみ見つかった場合、サーバーはそのクライアントのデータをOPTION_CLIENT_DATAオプションで返す必要があります（SHOULD）。クライアントが複数のリンクで見つかった場合、サーバーはリンクのリストをOPTION_CLIENT_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.
それ以外の場合、サーバーはOPTION_LQ_QUERYのデータを使用してクエリを開始します。クエリの結果はゼロまたは1つのクライアントになります。これにより、LEASEQUERY-REPLYに0または1つのOPTION_CLIENT_DATAオプションが追加されます。
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
LEASEQUERY-REPLYメッセージのOPTION_CLIENT_DATAオプションには、少なくとも次のオプションを含める必要があります。1. OPTION_CLIENTID 2. OPTION_IAADDRおよび/またはOPTION_IAPREFIX 3. OPTION_CLT_TIME
Depending on the bindings the client has on a link, either OPTION_IAADDR options, OPTION_IAPREFIX options, or both may be present.
クライアントがリンク上に持っているバインディングに応じて、OPTION_IAADDRオプション、OPTION_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.
OPTION_CLIENT_DATAには、LEASEQUERYメッセージのOPTION_LQ_QUERYオプションのOPTION_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サーバーは、LEASEQUERYメッセージのOPTION_LQ_QUERYオプションのOPTION_OROで指定された場合にリクエスタに返してはならない「機密オプション」のリストを使用して構成可能である必要があります（SHOULD）。このリクエスタから要求された場合でも、このリストのオプションをリクエスタに返してはなりません（MUST NOT）。
The server sends the LEASEQUERY-REPLY message as described in the "Transmission of Reply Messages" section of [2].
[2]の「応答メッセージの送信」セクションで説明されているように、サーバーはLEASEQUERY-REPLYメッセージを送信します。
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 decrypted by the intended access modem (e.g., [12] and [13]). Thus, the leasequery capability allows an access concentrator to provide considerably enhanced security.
アクセスコンセントレータは、一般的なリースクエリリクエスタであることが想定されています。 LEASEQUERYメッセージで更新されるDHCPv6グリーニング（つまり、[10]）を使用するアクセスコンセントレーターは、正確なクライアント/バインディング情報を維持します。これにより、アクセスコンセントレーターは、ブロードバンドアクセスネットワークの目的の宛先にデータトラフィックを転送し、アクセスネットワークからのデータグラムのIPv6送信元アドレス検証を実行でき、目的のアクセスモデム（例： [12]および[13]）。したがって、leasequery機能を使用すると、アクセスコンセントレータはセキュリティを大幅に強化できます。
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メッセージの認証」セクションでは、リレーエージェントとサーバー、およびクライアントとサーバー間の通信のセキュリティ保護について説明しています。リクエスタがアクセスコンセントレータである場合、[2]セクション21.1で説明されているIPsecベースの[9]セキュリティを使用する必要があります（SHOULD）。他のタイプのリクエスタは基本的にDHCPv6クライアントです。したがって、DHCPv6認証（[2]のセクション21）は、LEASEQUERYおよびLEASEQUERY-REPLYメッセージを保護するための適切なメカニズムです。管理ドメイン内のリースクエリリクエスタとサーバーの数は比較的少ないため、共有キーの配布に関する問題は最小限に抑えられます。
After implementing the above approaches, the DHCPv6 server should only be communicating with trusted LEASEQUERY requestors, and so security needs should be met.
上記のアプローチを実装した後、DHCPv6サーバーは信頼できるLEASEQUERYリクエスターとのみ通信する必要があるため、セキュリティのニーズを満たす必要があります。
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メッセージが必要でない限り、すべてのリレーエージェント）で防止する必要があります（SHOULD）。 DHCPv6サーバーは、リレーされたLEASEQUERYメッセージを破棄するか、リレーチェーンを制限するように構成できます（MAY）。
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.
DHCPv6サーバーは、セクション4.4.2で説明されているように、LEASEQUERY-REPLYでクライアントに返される情報を信頼できるLEASEQUERYリクエスタに制限する機能も提供する必要があります（SHOULD）。
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メッセージを送信しないでください）ブロードバンドアクセスネットワーク）。これらのメカニズムにより、再起動イベント後、正当なブロードバンドアクセスネットワークアドレスごとに1つの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 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 LEASEQUERYリクエスターにサービスを提供できなくなり、正当なDHCPv6クライアントへの構成と正当なDHCPv6へのリース情報が拒否されますLEASEQUERYリクエスタ。信頼された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サーバーではなく）アクセスコンセントレータをLEASEQUERYリクエスタとして攻撃する1つの方法は、不正なサーバーを確立して、不正なリースまたはルート情報をアクセスコンセントレータに提供し、ソース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は、http：//www.iana.org/assignments/dhcpv6-parametersで管理されているレジストリに、次の新しいDHCPv6メッセージタイプを割り当てました。
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は、http：//www.iana.org/assignments/dhcpv6-parametersで管理されているレジストリに、次の新しいDHCPv6オプションコードを割り当てました。
OPTION_LQ_QUERY OPTION_CLIENT_DATA OPTION_CLT_TIME OPTION_LQ_RELAY_DATA OPTION_LQ_CLIENT_LINK
OPTION_LQ_QUERY OPTION_CLIENT_DATA OPTION_CLT_TIME OPTION_LQ_RELAY_DATA OPTION_LQ_CLIENT_LINK
IANA has assigned the following new DHCPv6 Status Codes in the registry maintained in http://www.iana.org/assignments/dhcpv6-parameters:
IANAは、http：//www.iana.org/assignments/dhcpv6-parametersで管理されているレジストリに、次の新しいDHCPv6ステータスコードを割り当てました。
UnknownQueryType MalformedQuery NotConfigured NotAllowed
UnknownQueryType MalformedQuery NotConfigured NotAllowed
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で管理されているレジストリに、次の初期割り当てでOPTION_LQ_QUERYオプションのクエリタイプコード用の新しいレジストリを作成しました。
QUERY_BY_ADDRESS 1 QUERY_BY_CLIENTID 2
QUERY_BY_ADDRESS 1 QUERY_BY_CLIENTID 2
New OPTION_LQ_QUERY option query-type codes are assigned through Standards Action, as defined in [6].
[6]で定義されているように、新しいOPTION_LQ_QUERYオプションのクエリタイプコードは、標準アクションを通じて割り当てられます。
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.
Ralph Droms、Richard Johnson、Josh Littlefield、Hemant Singh、Pak Siripunkaw、Markus Stenberg、およびOle Troanに、このドキュメントの作成中の意見、アイデア、およびレビューに感謝します。
[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.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003。
[3] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[3] Woundy、R。およびK. Kinnear、「Dynamic Host Configuration Protocol（DHCP）Leasequery」、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。、「Dynamic Host Configuration Protocol」、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、「RFCで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、「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年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] プラムマー、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 4301、2005年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、「Data-Over-Cable Service Interface Specifications：DOCSIS 3.0、MAC and Upper Layer Protocols Interface Specification、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 Data Standards Subcommittee、「Data-Over-Cable Service Interface Specifications：DOCSIS 1.0 Baseline Privacy Interface Specification 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、「Data-Over-Cable Service Interface Specifications：Baseline Privacy Plus Interface Specification 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
John Jason Brzozowski Comcast Cable 1800 Bishops Gate Boulevard Mt. Laurel、NJ 08054 USA
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 Massachusetts Ave. Boxborough、MA 01719 USA
Phone: +1 978 936 0000
EMail: kkinnear@cisco.com
Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Bernard Volz Cisco Systems、Inc. 1414 Massachusetts Ave. Boxborough、MA 01719 USA
Phone: +1 978 936 0000
EMail: volz@cisco.com
Shengyou Zeng Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Shengyou Zeng Cisco Systems、Inc. 1414 Massachusetts Ave. Boxborough、MA 01719 USA
Phone: +1 978 936 0000
EMail: szeng@cisco.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（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事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンライン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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。