[要約] RFC 7653は、DHCPv6 Active Leasequeryプロトコルの仕様を定義しています。このプロトコルの目的は、DHCPv6サーバーに対してアクティブなリース情報をクエリすることです。
Internet Engineering Task Force (IETF) D. Raghuvanshi
Request for Comments: 7653 K. Kinnear
Updates: 5460 D. Kukrety
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 October 2015
DHCPv6 Active Leasequery
DHCPv6アクティブリースクエリ
Abstract
概要
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv6 bindings. That mechanism is limited to queries for DHCPv6 binding data updates prior to the time the DHCPv6 server receives the Leasequery request. Continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv6 Leasequery protocol and allows for active transfer of real-time DHCPv6 binding information data via TCP. This document also updates DHCPv6 Bulk Leasequery (RFC 5460) by adding new options.
IPv6の動的ホスト構成プロトコル（DHCPv6）は、リクエスタがDHCPv6バインディングに関する情報を要求できるようにするLeasequery機能で拡張されました。そのメカニズムは、DHCPv6サーバーがLeasequery要求を受信する前のDHCPv6バインディングデータ更新のクエリに限定されます。 Leasequeryデータを使用した外部リクエスタの継続的な更新が必要になる場合があります。このドキュメントはDHCPv6 Leasequeryプロトコルを拡張し、TCPを介してリアルタイムのDHCPv6バインディング情報データのアクティブな転送を可能にします。このドキュメントでは、新しいオプションを追加してDHCPv6一括リースクエリ（RFC 5460）も更新しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7653.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7653で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Protocol Overview ...............................................6
4. Interaction between Active Leasequery and Bulk Leasequery .......8
5. Extension to DHCPv6 Bulk Leasequery .............................8
6. Message and Option Definitions ..................................9
6.1. Message Framing for TCP ....................................9
6.2. Messages ...................................................9
6.2.1. ACTIVELEASEQUERY ....................................9
6.2.2. STARTTLS ...........................................10
6.2.3. Response Messages ..................................10
6.3. Options ...................................................10
6.3.1. OPTION_LQ_BASE_TIME ................................10
6.3.2. OPTION_LQ_START_TIME ...............................11
6.3.3. OPTION_LQ_END_TIME .................................12
6.4. Connection and Transmission Parameters ....................12
7. Information Communicated by Active Leasequery ..................13
8. Requestor Behavior .............................................14
8.1. General Processing ........................................14
8.2. Initiating a Connection ...................................14
8.3. Forming an Active Leasequery ..............................15
8.4. Processing Active Replies .................................16
8.4.1. Processing Replies from a Request Containing an
OPTION_LQ_START_TIME ...............................18
8.5. Processing Time Values in Leasequery Messages .............20
8.6. Examples ..................................................21
8.6.1. Query Failure ......................................21
8.6.2. Data Missing on Server .............................21
8.6.3. Successful Query ...................................21
8.7. Closing Connections .......................................22
9. Server Behavior ................................................22
9.1. Accepting Connections .....................................22
9.2. Rejecting Connections .....................................24
9.3. Replying to an Active Leasequery ..........................24
9.4. Multiple or Parallel Queries ..............................26
9.5. Closing Connections .......................................26
10. Security Considerations .......................................27
11. IANA Considerations ...........................................28
12. References ....................................................28
12.1. Normative References .....................................28
12.2. Informative References ...................................29
Acknowledgments ...................................................30
Authors' Addresses ................................................30
The DHCPv6 protocol [RFC3315] specifies a mechanism for the assignment of IPv6 address and configuration information to IPv6 nodes. IPv6 Prefix Delegation for DHCPv6 [RFC3633] specifies a mechanism for DHCPv6 delegation of IPv6 prefixes and related data. DHCPv6 servers maintain authoritative information including binding information for delegated IPv6 prefixes.
DHCPv6プロトコル[RFC3315]は、IPv6アドレスと構成情報をIPv6ノードに割り当てるメカニズムを指定します。 DHCPv6のIPv6プレフィックス委任[RFC3633]は、IPv6プレフィックスと関連データのDHCPv6委任のメカニズムを指定します。 DHCPv6サーバーは、委任されたIPv6プレフィックスのバインド情報を含む信頼できる情報を維持します。
Requirements exist for external entities to keep up to date on the correspondence between DHCPv6 clients and their bindings. These entities need to keep up with the current binding activity of the DHCPv6 server. Keeping up with this binding activity is termed "active" leasequery.
外部エンティティがDHCPv6クライアントとそのバインディング間の対応を最新に保つための要件があります。これらのエンティティは、DHCPv6サーバーの現在のバインディングアクティビティに対応する必要があります。このバインディングアクティビティに追いつくことは「アクティブな」leasequeryと呼ばれます。
The DHCPv6 Bulk Leasequery [RFC5460] capability can be used to recover useful information from a DHCPv6 server when some external entity starts up. This entity could be one that is directly involved in the DHCPv6 client-server transactions (e.g., a relay agent), or it could be an external process that needs information present in the DHCPv6 server's lease state database.
DHCPv6バルクリースクエリ[RFC5460]機能を使用すると、外部エンティティが起動したときにDHCPv6サーバーから有用な情報を回復できます。このエンティティは、DHCPv6クライアント/サーバートランザクション（リレーエージェントなど）に直接関与するエンティティである場合もあれば、DHCPv6サーバーのリース状態データベースに存在する情報を必要とする外部プロセスである場合もあります。
The Active Leasequery capability documented here is designed to allow an entity not directly involved in DHCPv6 client-server transactions to nevertheless keep current with the state of the DHCPv6 lease state information in real time.
ここに記載されているアクティブLeasequery機能は、DHCPv6クライアント/サーバートランザクションに直接関与していないエンティティでも、DHCPv6リース状態情報をリアルタイムで最新に保つことができるように設計されています。
This document updates DHCPv6 Bulk Leasequery [RFC5460] by adding new options, as described in Section 6.2.1. For DHCPv6 servers supporting Bulk Leasequery and not Active Leasequery, Section 9.2 specifies the mechanism to reject incoming Active Leasequery requests.
このドキュメントは、セクション6.2.1で説明されているように、新しいオプションを追加することによりDHCPv6バルクリースクエリ[RFC5460]を更新します。 Bulk Leasequeryをサポートし、Active LeasequeryをサポートしないDHCPv6サーバーの場合、セクション9.2では、着信Active Leasequery要求を拒否するメカニズムを指定しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
DHCPv6 terminology is defined in [RFC3315]. Terminology specific to DHCPv6 Active Leasequery can be found below:
DHCPv6の用語は[RFC3315]で定義されています。 DHCPv6 Active Leasequeryに固有の用語は次のとおりです。
o absolute time
o 絶対時間
A 32-bit unsigned quantity containing the number of seconds since midnight (UTC), January 1, 2000, modulo 2^32.
2000年1月1日午前2時32時（UTC）からの秒数を含む32ビットの符号なし数量。
o Active Leasequery
o アクティブリースクエリ
Keeping up to date in real time (or near real time) with DHCPv6 binding activity.
DHCPv6バインディングアクティビティにより、リアルタイム（またはほぼリアルタイム）で最新の状態に保ちます。
o Bulk Leasequery
o 一括リースクエリ
Requesting and receiving information about all or some of the existing DHCPv6 binding information in an efficient manner, as defined by [RFC5460].
[RFC5460]で定義されているように、既存のDHCPv6バインディング情報のすべてまたは一部に関する情報を効率的な方法で要求および受信する。
o blocked TCP connection
o ブロックされたTCP接続
A TCP connection is considered blocked if the underlying TCP transport will not accept new messages to be sent without blocking the thread that is attempting to send the message.
メッセージを送信しようとしているスレッドをブロックせずに、基になるTCPトランスポートが送信される新しいメッセージを受け入れない場合、TCP接続はブロックされていると見なされます。
o binding change/update
o バインディングの変更/更新
Any change in the DHCPv6 binding state. This also includes expiration or deletion of the binding.
DHCPv6バインディング状態の変更。これには、バインディングの有効期限または削除も含まれます。
o catch-up information
o 追いつき情報
If a DHCPv6 Active Leasequery requestor sends an OPTION_LQ_START_TIME option in an ACTIVELEASEQUERY message, the DHCPv6 server will attempt to send the requestor the information that changed since the time specified in the OPTION_LQ_START_TIME option. The binding information sent to satisfy this request is the catch-up information.
DHCPv6 Active LeasequeryリクエスタがACTIVELEASEQUERYメッセージでOPTION_LQ_START_TIMEオプションを送信すると、DHCPv6サーバーは、OPTION_LQ_START_TIMEオプションで指定された時間以降に変更された情報をリクエスタに送信しようとします。この要求を満たすために送信されるバインディング情報はキャッチアップ情報です。
o catch-up phase
o キャッチアップフェーズ
The period while catch-up information is being sent is the catch-up phase.
キャッチアップ情報が送信されている期間は、キャッチアップフェーズです。
o clock skew
o 時計のずれ
The difference between the absolute time on a DHCPv6 server and the absolute time on the system where a requestor of an Active or Bulk Leasequery is executing is termed the "clock skew" for that Active or Bulk Leasequery connection. It is not absolutely constant but is likely to vary only slowly. While it is easy to think that this can be calculated precisely after one message is received by a requestor from a DHCPv6 server, a more accurate value is derived from continuously examining the instantaneous value developed from each message received from a DHCPv6 server and using it to make small adjustments to the existing value held in the requestor.
DHCPv6サーバーの絶対時間とアクティブまたはバルクリースクエリのリクエスタが実行されているシステムの絶対時間の差は、そのアクティブまたはバルクリースクエリ接続の「クロックスキュー」と呼ばれます。絶対的に一定ではありませんが、ゆっくりと変化する可能性があります。これは、DHCPv6サーバーからリクエスタが1つのメッセージを受信した後に正確に計算できると考えるのは簡単ですが、より正確な値は、DHCPv6サーバーから受信した各メッセージから生成された瞬間的な値を継続的に調べ、それを使用してリクエスタに保持されている既存の値を少し調整します。
o DHCPv6 binding state
o DHCPv6バインディング状態
Data stored on the DHCPv6 server related to binding.
バインディングに関連してDHCPv6サーバーに格納されたデータ。
o requestor
o 依頼者
The node that sends LEASEQUERY messages to one or more servers to retrieve information on the bindings for a client.
LEASEQUERYメッセージを1つ以上のサーバーに送信して、クライアントのバインディングに関する情報を取得するノード。
o transaction-id
o トランザクションID
An opaque value used to match responses with queries initiated by an Active Leasequery requestor.
Active Leasequeryリクエスタによって開始されたクエリと応答を照合するために使用される不透明な値。
The Active Leasequery mechanism is modeled on the existing DHCPv6 Bulk Leasequery [RFC5460]; most differences arise from the long-term nature of the TCP [RFC7414] connection required for Active Leasequery. A DHCPv6 server that supports Active Leasequery MUST support Bulk Leasequery [RFC5460] as well.
Active Leasequeryメカニズムは、既存のDHCPv6 Bulk Leasequery [RFC5460]をモデルにしています。ほとんどの違いは、Active Leasequeryに必要なTCP [RFC7414]接続の長期的な性質から生じます。 Active LeasequeryをサポートするDHCPv6サーバーは、Bulk Leasequery [RFC5460]もサポートする必要があります。
An Active Leasequery requestor opens a TCP connection to a DHCPv6 server, using the DHCPv6 port 547. Note that this implies that the Leasequery requestor has server IP address(es) available via configuration or some other means, and that it has unicast IP reachability to the DHCPv6 server. No relaying for Active Leasequery is specified.
アクティブなLeasequeryリクエスタは、DHCPv6ポート547を使用して、DHCPv6サーバーへのTCP接続を開きます。これは、Leasequeryリクエスタが構成またはその他の手段で利用可能なサーバーIPアドレスを持ち、ユニキャストIP到達可能性があることを意味しますDHCPv6サーバー。 Active Leasequeryのリレーは指定されていません。
After establishing a connection, the requestor sends an ACTIVELEASEQUERY message over the connection. In response, the server sends updates to the requestor using LEASEQUERY-REPLY and LEASEQUERY-DATA messages. This response procedure is similar to the procedure specified in [RFC5460], except that in the case of Active Leasequery, the server sends updates whenever some activity occurs to change the binding state -- thus the need for a long-lived connection. Additionally, the Active Leasequery server SHOULD provide a mechanism to control which data is allowed to be included in the OPTION_CLIENT_DATA messages sent to the requestor. See Section 9.3.
接続を確立した後、リクエスタは接続を介してACTIVELEASEQUERYメッセージを送信します。それに応じて、サーバーはLEASEQUERY-REPLYおよびLEASEQUERY-DATAメッセージを使用してリクエスタに更新を送信します。この応答手順は、[RFC5460]で指定されている手順と似ていますが、アクティブリースクエリの場合、サーバーが何らかのアクティビティが発生して更新を送信し、バインディング状態を変更するため、長期間の接続が必要になります。さらに、Active Leasequeryサーバーは、リクエスタに送信されるOPTION_CLIENT_DATAメッセージにどのデータを含めることができるかを制御するメカニズムを提供する必要があります（SHOULD）。セクション9.3を参照してください。
Active Leasequery has features that allow this external entity to lose its connection and then reconnect and receive the latest information concerning any IPv6 bindings changed while it was not connected.
アクティブLeasequeryには、この外部エンティティが接続を失い、再接続して、接続されていない間に変更されたIPv6バインディングに関する最新情報を受信できる機能があります。
These features are designed to allow the Active Leasequery requestor to efficiently become current with respect to the lease state database after it has been restarted or the machine on which it is running has been reinitialized. It is easy to define a protocol that works when the requestor is always connected to the DHCPv6 server. Since that isn't sufficiently robust, much of the mechanism in this document is designed to deal efficiently with situations that occur when the Active Leasequery requestor becomes disconnected from the DHCPv6 server from which it is receiving updates and then reconnects to that server.
これらの機能は、アクティブLeasequeryリクエスタが再起動された後、またはそれが実行されているマシンが再初期化された後に、リース状態データベースに関して効率的に最新になるように設計されています。リクエスタが常にDHCPv6サーバーに接続されている場合に機能するプロトコルを定義するのは簡単です。これは十分に堅牢ではないため、このドキュメントのメカニズムの多くは、Active Leasequeryリクエスターが更新を受信しているDHCPv6サーバーから切断され、そのサーバーに再接続するときに発生する状況を効率的に処理するように設計されています。
Central to this approach, if the Active Leasequery requestor loses service, it is allowed to specify the time of its most recent update in a subsequent Active Leasequery request, and the DHCPv6 server will determine whether or not data was missed while the Active Leasequery requestor was not connected.
このアプローチの中心となるのは、アクティブリースクエリリクエスタがサービスを失った場合、後続のアクティブリースクエリリクエストで最新の更新時刻を指定でき、DHCPv6サーバーは、アクティブリースクエリリクエスタがあった間にデータが失われたかどうかを判断します接続されていません。
The DHCPv6 server processing the Active Leasequery request MAY limit the amount of data saved, and methods exist for the DHCPv6 server to inform the Active Leasequery requestor that data was missed (i.e., not all data could be saved). In this situation, the Active Leasequery requestor should issue a Bulk Leasequery [RFC5460] to recover information not available through an Active Leasequery.
Active Leasequeryリクエストを処理するDHCPv6サーバーは、保存されるデータの量を制限する場合があり、DHCPv6サーバーがActive Leasequeryリクエスタにデータが欠落したことを通知するメソッドが存在します（つまり、すべてのデータを保存できるわけではありません）。この状況では、アクティブリースクエリリクエスタは、バルクリースクエリ[RFC5460]を発行して、アクティブリースクエリでは利用できない情報を回復する必要があります。
DHCPv6 servers are not required to keep any data corresponding to data missed on an Active Leasequery connection but will typically choose to keep data corresponding to some recent activity available for subsequent queries by a DHCPv6 Active Leasequery requestor whose connection was temporarily interrupted. In other words, DHCPv6 servers supporting catch-up are required to have some mechanism to keep/save historic information of bindings.
DHCPv6サーバーは、アクティブリースクエリ接続で失われたデータに対応するデータを保持する必要はありませんが、通常、接続が一時的に中断されたDHCPv6アクティブリースクエリリクエスタによる後続のクエリで利用できる最近のアクティビティに対応するデータを保持することを選択します。つまり、キャッチアップをサポートするDHCPv6サーバーには、バインディングの履歴情報を保持/保存するためのメカニズムが必要です。
An Active Leasequery requestor would typically use Bulk Leasequery to initialize its database with all current data when that database contains no binding information. In addition, it would use Bulk Leasequery to recover missed information in the event that its connection with the DHCPv6 server was lost for a longer time than the DHCPv6 server would keep track of the specific changes to the IPv6 binding information.
アクティブなLeasequeryリクエスタは通常、データベースにバインディング情報が含まれていない場合、Bulk Leasequeryを使用してデータベースを現在のすべてのデータで初期化します。さらに、DHCPv6サーバーがIPv6バインディング情報への特定の変更を追跡するよりも長い時間、DHCPv6サーバーとの接続が失われた場合に、Bulk Leasequeryを使用して失われた情報を回復します。
The messages sent by the server in response to an Active Leasequery request should be identical to the messages sent by the server to a Bulk Leasequery request regarding the way the data is encoded into the Active Leasequery responses. In addition, the actions taken by the Active Leasequery requestor to interpret the responses to an Active Leasequery request should be identical to the way that the requestor interprets the responses to a Bulk Leasequery request. Thus, the handling of OPTION_CLIENT_DATA and additional options discussed in the Bulk Leasequery specification [RFC5460] are to be followed when implementing Active Leasequery, with the exception that a server responding to an Active Leasequery request SHOULD be able to be configured to prevent specific data items from being included in the OPTION_CLIENT_DATA option even if they were requested by inclusion in the OPTION_ORO option.
Active Leasequeryリクエストへの応答としてサーバーが送信するメッセージは、データがActive Leasequeryレスポンスにエンコードされる方法に関して、サーバーがBulk Leasequeryリクエストに送信するメッセージと同じである必要があります。さらに、アクティブリースクエリリクエスタがアクティブリースクエリリクエストへの応答を解釈するために実行するアクションは、リクエスタがバルクリースクエリリクエストへの応答を解釈する方法と同じでなければなりません。したがって、一括リースクエリの仕様[RFC5460]で説明されているOPTION_CLIENT_DATAと追加オプションの処理は、アクティブリースクエリの実装時に従う必要があります。ただし、アクティブリースクエリ要求に応答するサーバーは、特定のデータ項目を防ぐように構成できる必要があります（SHOULD）。 OPTION_CLIO_DATAオプションへの組み込みによって要求された場合でも、OPTION_CLIENT_DATAオプションに組み込まれないようにします。
Active Leasequery is an extension of the Bulk Leasequery protocol [RFC5460]. The format of messages returned to an Active Leasequery requestor is identical to that defined for the Bulk Leasequery protocol [RFC5460].
Active Leasequeryは、Bulk Leasequeryプロトコル[RFC5460]の拡張です。 Active Leasequeryリクエスタに返されるメッセージの形式は、Bulk Leasequeryプロトコル[RFC5460]で定義されているものと同じです。
Applications that employ Active Leasequery to keep a database up to date with respect to the DHCPv6 server's lease state database should use an initial Bulk Leasequery to bring their database into equivalence with that of the DHCPv6 server and then use Active Leasequery to keep that database current with respect to the DHCPv6 server's lease state database.
DHCPv6サーバーのリース状態データベースに関してデータベースを最新の状態に保つためにアクティブリースクエリを使用するアプリケーションは、初期バルクリースクエリを使用してデータベースをDHCPv6サーバーと同等にしてから、アクティブリースクエリを使用してデータベースを最新に保つ必要がありますDHCPv6サーバーのリース状態データベースに関して。
There are several differences between the Active and Bulk Leasequery protocols. Active Leasequery defines a new message (ACTIVELEASEQUERY) to send Active Leasequery requests to the DHCPv6 server. An Active Leasequery connection sends all available updates to the requestor, based on the OPTION_LQ_QUERY option (see Section 6.2.1).
アクティブとバルクリースクエリプロトコルの間にはいくつかの違いがあります。 Active Leasequeryは、DHCPv6サーバーにActive Leasequery要求を送信するための新しいメッセージ（ACTIVELEASEQUERY）を定義します。アクティブLeasequery接続は、OPTION_LQ_QUERYオプションに基づいて、利用可能なすべての更新をリクエスタに送信します（セクション6.2.1を参照）。
An Active Leasequery connection does not ever "complete", though the DHCPv6 server can close the connection for a variety of reasons associated with some sort of exception condition.
DHCPv6サーバーは、ある種の例外条件に関連するさまざまな理由で接続を閉じることができますが、アクティブなLeasequery接続は決して「完了」しません。
This document extends the capabilities of the DHCPv6 Bulk Leasequery protocol [RFC5460] by defining new options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME, and OPTION_LQ_END_TIME). The DHCPv6 server sends the OPTION_LQ_BASE_TIME option in a Bulk Leasequery response if the requestor asked for the same in the Bulk Leasequery request. OPTION_LQ_START_TIME and OPTION_LQ_END_TIME can be used in a Bulk Leasequery request made to the DHCPv6 server. More details about these options are specified in Section 6.3.
このドキュメントは、新しいオプション（OPTION_LQ_BASE_TIME、OPTION_LQ_START_TIME、およびOPTION_LQ_END_TIME）を定義することにより、DHCPv6バルクリースクエリプロトコル[RFC5460]の機能を拡張します。 DHCPv6サーバーは、要求者がBulk Leasequery要求でOPTION_LQ_BASE_TIMEオプションを要求した場合、それをBulk Leasequery応答で送信します。 OPTION_LQ_START_TIMEおよびOPTION_LQ_END_TIMEは、DHCPv6サーバーに対して行われる一括リースクエリ要求で使用できます。これらのオプションの詳細については、セクション6.3を参照してください。
The use of TCP for the Active Leasequery protocol permits one or more DHCPv6 messages to be sent in response to a single Active Leasequery request. The receiver needs to be able to determine how large each message is. The same message framing technique used for DHCPv6 Bulk Leasequery [RFC5460] is used for Active Leasequery as well.
Active LeasequeryプロトコルにTCPを使用すると、1つのActive Leasequery要求に応答して1つ以上のDHCPv6メッセージを送信できます。受信者は、各メッセージの大きさを判別できる必要があります。 DHCPv6バルクリースクエリ[RFC5460]で使用されているのと同じメッセージフレーミング技術が、アクティブリースクエリでも使用されます。
The intent in using the same format is that code that currently knows how to deal with a message returned from DHCPv6 Bulk Leasequery [RFC5460] will be able to deal with the message held inside of the TCP framing.
同じ形式を使用する意図は、DHCPv6バルクリースクエリ[RFC5460]から返されたメッセージを処理する方法を現在知っているコードが、TCPフレーミング内に保持されているメッセージを処理できるようにすることです。
When using Transport Layer Security (TLS), once TLS negotiation completes, the connection will be encrypted and is now protected from eavesdropping, and normal Active Leasequery messages are sent and received using the TLS application data protocol services (see Section 10 of [RFC5246]).
トランスポート層セキュリティ（TLS）を使用する場合、TLSネゴシエーションが完了すると、接続は暗号化され、盗聴から保護されます。通常のActive Leasequeryメッセージは、TLSアプリケーションデータプロトコルサービスを使用して送受信されます（[RFC5246]のセクション10を参照）。 ）。
The new message type (ACTIVELEASEQUERY) is designed for keeping the requestor up to date in real time (or near real time) with DHCPv6 bindings. It asks the server to return DHCPv6 binding activity that occurs subsequent to the receipt of the Active Leasequery request.
新しいメッセージタイプ（ACTIVELEASEQUERY）は、DHCPv6バインディングを使用してリクエスタをリアルタイム（またはほぼリアルタイム）で最新の状態に保つように設計されています。 Active Leasequery要求の受信後に発生するDHCPv6バインディングアクティビティを返すようにサーバーに要求します。
An ACTIVELEASEQUERY request MUST contain a transaction-id, and that transaction-id MUST be locally unique on the TCP connection on which it is sent to the DHCPv6 server.
ACTIVELEASEQUERY要求にはトランザクションIDが含まれている必要があり、そのトランザクションIDはDHCPv6サーバーに送信されるTCP接続でローカルに一意である必要があります。
When sending an ACTIVELEASEQUERY request, the requestor MAY include the OPTION_LQ_START_TIME option in the ACTIVELEASEQUERY request. In this case, the DHCPv6 server returns all the bindings changed on or after the OPTION_LQ_START_TIME.
ACTIVELEASEQUERYリクエストを送信する場合、リクエスタは、ACTIVELEASEQUERYリクエストにOPTION_LQ_START_TIMEオプションを含めることができます（MAY）。この場合、DHCPv6サーバーは、OPTION_LQ_START_TIME以降に変更されたすべてのバインディングを返します。
If the requestor is interested in receiving all binding updates from the DHCPv6 server, it MUST NOT include the OPTION_LQ_QUERY option in the ACTIVELEASEQUERY message. But if the requestor is only interested in specific binding updates, it MAY include an OPTION_LQ_QUERY option along with a query-types defined in [RFC5007] and [RFC5460].
リクエスタがDHCPv6サーバーからすべてのバインディング更新を受信することに関心がある場合、ACTIVELEASEQUERYメッセージにOPTION_LQ_QUERYオプションを含めてはなりません（MUST NOT）。ただし、リクエスタが特定のバインディングの更新のみに関心がある場合は、[RFC5007]および[RFC5460]で定義されているクエリタイプとともにOPTION_LQ_QUERYオプションを含めることができます（MAY）。
Other DHCPv6 options used in the LEASEQUERY message (as specified in [RFC5460]) can also be used in the ACTIVELEASEQUERY message.
LEASEQUERYメッセージで使用されるその他のDHCPv6オプション（[RFC5460]で指定）は、ACTIVELEASEQUERYメッセージでも使用できます。
The new message type (STARTTLS) is designed for establishment of a TLS connection between a requestor and a DHCPv6 server. The STARTTLS message SHOULD be sent without any options. Any options received in a STARTTLS message SHOULD be ignored.
新しいメッセージタイプ（STARTTLS）は、リクエスタとDHCPv6サーバー間のTLS接続を確立するために設計されています。 STARTTLSメッセージは、オプションなしで送信する必要があります（SHOULD）。 STARTTLSメッセージで受信したオプションはすべて無視してください。
More details about this message are specified in Section 8.2.
このメッセージの詳細については、セクション8.2を参照してください。
The LEASEQUERY-REPLY message is defined in [RFC5007]. The LEASEQUERY-DATA and LEASEQUERY-DONE messages are defined in [RFC5460].
LEASEQUERY-REPLYメッセージは[RFC5007]で定義されています。 LEASEQUERY-DATAおよびLEASEQUERY-DONEメッセージは、[RFC5460]で定義されています。
In an Active Leasequery exchange, a single LEASEQUERY-REPLY message is used to indicate the success or failure of a query and to carry data that do not change in the context of a single query and answer, such as the Server-ID and Client-ID options. If a query is successful, the DHCPv6 server MUST respond to it with exactly one LEASEQUERY-REPLY message. If the server is returning binding data, the LEASEQUERY-REPLY also contains the first client's binding data in an OPTION_CLIENT_DATA option. Additional binding data is returned using a LEASEQUERY-DATA message as explained in DHCPv6 Bulk Leasequery [RFC5460]. In case of a query failure, a single LEASEQUERY-REPLY message is returned without any binding data.
アクティブLeasequery交換では、単一のLEASEQUERY-REPLYメッセージを使用して、クエリの成功または失敗を示し、単一のクエリおよび応答のコンテキストで変化しないデータ（サーバーIDやクライアントIDなど）を伝送します。 IDオプション。クエリが成功した場合、DHCPv6サーバーは1つのLEASEQUERY-REPLYメッセージで応答する必要があります。サーバーがバインディングデータを返す場合、LEASEQUERY-REPLYには、OPTION_CLIENT_DATAオプションに最初のクライアントのバインディングデータも含まれます。 DHCPv6バルクリースクエリ[RFC5460]で説明されているように、LEASEQUERY-DATAメッセージを使用して追加のバインディングデータが返されます。クエリが失敗した場合、単一のLEASEQUERY-REPLYメッセージがバインディングデータなしで返されます。
New options (OPTION_LQ_BASE_TIME, OPTION_LQ_START_TIME, and OPTION_LQ_END_TIME) are defined as an extension to DHCPv6 Bulk Leasequery [RFC5460]. The reply messages for Active Leasequery use these options along with the options defined in [RFC3315], [RFC5007], and [RFC5460].
新しいオプション（OPTION_LQ_BASE_TIME、OPTION_LQ_START_TIME、およびOPTION_LQ_END_TIME）は、DHCPv6 Bulk Leasequery [RFC5460]の拡張機能として定義されています。 Active Leasequeryの応答メッセージは、[RFC3315]、[RFC5007]、および[RFC5460]で定義されたオプションとともにこれらのオプションを使用します。
The OPTION_LQ_BASE_TIME option is the current time the message was created to be sent by the DHCPv6 server to the requestor of the Active or Bulk Leasequery if the requestor asked for the same in an Active or Bulk Leasequery request. This MUST be an absolute time (i.e., seconds since midnight January 1, 2000 UTC). All of the other time-based options in the reply message are relative to this time, including OPTION_CLT_TIME [RFC5007]. This time is in the context of the DHCPv6 server that placed this option in a message.
OPTION_LQ_BASE_TIMEオプションは、リクエスターがActiveまたはBulk Leasequeryリクエストで要求した場合に、DHCPv6サーバーがActiveまたはBulk Leasequeryのリクエスターに送信するメッセージが作成された現在の時刻です。これは絶対時間でなければなりません（つまり、2000年1月1日の午前0時からの秒数）。 OPTION_CLT_TIME [RFC5007]を含む、応答メッセージの他のすべての時間ベースのオプションは、この時間に関連しています。今回は、メッセージにこのオプションを配置したDHCPv6サーバーのコンテキストです。
This is an unsigned integer in network byte order.
これは、ネットワークバイトオーダーの符号なし整数です。
The code for this option is 100.
このオプションのコードは100です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_BASE_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| base-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_BASE_TIME (100) option-len 4 base-time DHCPv6 Server Base Time
option-code OPTION_LQ_BASE_TIME（100）option-len 4基本時間DHCPv6サーバー基本時間
The OPTION_LQ_START_TIME option specifies a query start time to the DHCPv6 server. If specified, only bindings that have changed on or after the OPTION_LQ_START_TIME should be included in the response to the query. This option MAY be used in Active or Bulk Leasequery requests made to a DHCPv6 server.
OPTION_LQ_START_TIMEオプションは、DHCPv6サーバーへのクエリ開始時間を指定します。指定した場合、OPTION_LQ_START_TIME以降に変更されたバインディングのみをクエリへの応答に含める必要があります。このオプションは、DHCPv6サーバーに対して行われるアクティブまたは一括リースクエリ要求で使用できます。
The requestor MUST determine the OPTION_LQ_START_TIME using lease information it has received from the DHCPv6 server. This MUST be an absolute time in the DHCPv6 server's context (see Section 8.5).
リクエスタは、DHCPv6サーバーから受信したリース情報を使用して、OPTION_LQ_START_TIMEを決定する必要があります。これはDHCPv6サーバーのコンテキストでの絶対時間でなければなりません（セクション8.5を参照）。
Typically (though this is not a requirement), the OPTION_LQ_START_TIME option will contain the value most recently received in an OPTION_LQ_BASE_TIME option by the requestor, as this will indicate the last successful communication with the DHCPv6 server.
通常、これは必須ではありませんが、OPTION_LQ_START_TIMEオプションには、リクエスタがOPTION_LQ_BASE_TIMEオプションで最後に受信した値が含まれます。これは、DHCPv6サーバーとの最後の正常な通信を示すためです。
This is an unsigned integer in network byte order.
これは、ネットワークバイトオーダーの符号なし整数です。
The code for this option is 101.
このオプションのコードは101です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_START_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-start-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_START_TIME (101) option-len 4 query-start-time DHCPv6 Server Query Start Time
option-code OPTION_LQ_START_TIME（101）option-len 4 query-start-time DHCPv6 Server Query Start Time
The OPTION_LQ_END_TIME option specifies a query end time to the DHCPv6 server. If specified, only bindings that have changed on or before the OPTION_LQ_END_TIME should be included in the response to the query. This option MAY be used in a Bulk Leasequery request, but it MUST NOT be used in an Active Leasequery request.
OPTION_LQ_END_TIMEオプションは、DHCPv6サーバーへのクエリ終了時間を指定します。指定した場合、OPTION_LQ_END_TIME以前に変更されたバインディングのみをクエリへの応答に含める必要があります。このオプションは、バルクリースクエリリクエストで使用できますが、アクティブリースクエリリクエストで使用してはなりません。
The requestor MUST determine the OPTION_LQ_END_TIME based on lease information it has received from the DHCPv6 server. This MUST be an absolute time in the context of the DHCPv6 server.
リクエスタは、DHCPv6サーバーから受信したリース情報に基づいて、OPTION_LQ_END_TIMEを決定する必要があります。これは、DHCPv6サーバーのコンテキストでは絶対時間でなければなりません。
In the absence of information to the contrary, the requestor SHOULD assume that the time context of the DHCPv6 server is identical to the time context of the requestor (see Section 8.5).
反対の情報がない場合、リクエスタは、DHCPv6サーバーの時間コンテキストがリクエスタの時間コンテキストと同じであると想定する必要があります（セクション8.5を参照）。
This is an unsigned integer in network byte order.
これは、ネットワークバイトオーダーの符号なし整数です。
The code for this option is 102.
このオプションのコードは102です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_END_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-end-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_END_TIME (102) option-len 4 query-end-time DHCPv6 Server Query End Time
option-code OPTION_LQ_END_TIME（102）option-len 4 query-end-time DHCPv6 Server Query End Time
Active Leasequery uses the same port configuration as DHCPv6 Bulk Leasequery [RFC5460]. It also uses the other transmission parameters (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC5460].
Active LeasequeryはDHCPv6 Bulk Leasequery [RFC5460]と同じポート構成を使用します。 [RFC5460]で定義されている他の送信パラメータ（BULK_LQ_DATA_TIMEOUTおよびBULK_LQ_MAX_CONNS）も使用します。
This section presents a table of values used to control Active Leasequery behavior, including recommended defaults. Implementations MAY make these values configurable. However, configuring too-small timeout values may lead to harmful behavior both to this application and to other traffic in the network. As a result, timeout values smaller than the default values SHOULD NOT be used.
このセクションでは、推奨されるデフォルトを含む、Active Leasequeryの動作を制御するために使用される値の表を示します。実装はこれらの値を構成可能にするかもしれません。ただし、設定するタイムアウト値が小さすぎると、このアプリケーションとネットワーク内の他のトラフィックの両方に悪影響を及ぼす可能性があります。その結果、デフォルト値より小さいタイムアウト値は使用されるべきではありません。
+------------------------+----------+-------------------------------+
| Parameter | Default | Description |
+------------------------+----------+-------------------------------+
| ACTIVE_LQ_RCV_TIMEOUT | 120 secs | Active Leasequery receive |
| | | timeout |
| ACTIVE_LQ_SEND_TIMEOUT | 120 secs | Active Leasequery send |
| | | timeout |
| ACTIVE_LQ_IDLE_TIMEOUT | 60 secs | Active Leasequery idle |
| | | timeout |
+------------------------+----------+-------------------------------+
While the information communicated by a DHCPv6 Bulk Leasequery [RFC5460] is taken directly from the DHCPv6 server's lease state database, the information communicated by an Active Leasequery is real-time information. As such, it is the information that is currently associated with a particular binding in the DHCPv6 server's lease state database.
DHCPv6一括リースクエリ[RFC5460]によって通信される情報はDHCPv6サーバーのリース状態データベースから直接取得されますが、アクティブリースクエリによって通信される情報はリアルタイムの情報です。したがって、DHCPv6サーバーのリース状態データベースの特定のバインディングに現在関連付けられているのはこの情報です。
This is of significance, because if the Active Leasequery requestor runs slowly or the requestor disconnects from the DHCPv6 server and then reconnects with an OPTION_LQ_START_TIME option (signaling a catch-up operation), the information communicated to the Active Leasequery requestor is only the most current information from the DHCPv6 server's lease state database.
これは重要です。アクティブリースクエリリクエスタの実行速度が遅い場合、またはリクエスタがDHCPv6サーバーから切断してからOPTION_LQ_START_TIMEオプション（キャッチアップ操作を通知）で再接続する場合、アクティブリースクエリリクエスタに通知される情報は最新のものだけです。 DHCPv6サーバーのリース状態データベースからの情報。
The requestor of an Active Leasequery MUST NOT assume that every lease state change is communicated across an Active Leasequery connection. Even if the Active Leasequery requestor remains connected, the DHCPv6 server is only required to transmit information about a binding that is current when the message is created and handed off to the TCP stack to send to the requestor.
アクティブリースクエリのリクエスタは、すべてのリース状態の変更がアクティブリースクエリ接続を介して通信されると想定してはなりません（MUST NOT）。 Active Leasequeryリクエスターが接続されたままであっても、DHCPv6サーバーは、メッセージが作成されてリクエスターに送信するためにTCPスタックに渡されるときに最新であるバインディングに関する情報を送信するだけで済みます。
If the TCP connection blocks and the DHCPv6 server is waiting to send information down the connection, when the connection becomes available to be written, the DHCPv6 server MAY create the message to send at this time. The current state of the binding will be sent, and any transition in state or other information that occurred while the TCP connection was blocked will be lost.
TCP接続がブロックし、DHCPv6サーバーが接続を介して情報を送信するのを待っている場合、接続が書き込み可能になると、DHCPv6サーバーはこの時点で送信するメッセージを作成できます（MAY）。バインディングの現在の状態が送信され、TCP接続がブロックされている間に発生した状態の遷移やその他の情報は失われます。
Thus, the Active Leasequery protocol does not allow the requestor to build a complete history of every activity on every lease. An effective history of the important state changes for a lease can be created if the parameters of the DHCPv6 server are tuned to take into account the requirements of an Active Leasequery requestor. For instance, the period after the expiration or release of a binding could be configured long enough (say several minutes, well more than the receive timeout), so that an Active Leasequery requestor would be less likely to miss any changes in the binding.
したがって、アクティブリースクエリプロトコルでは、リクエスタがすべてのリースのすべてのアクティビティの完全な履歴を作成することはできません。アクティブリースクエリリクエスタの要件を考慮してDHCPv6サーバーのパラメータが調整されている場合、リースの重要な状態変化の効果的な履歴を作成できます。たとえば、バインディングの有効期限またはリリース後の期間を十分に長く（たとえば、受信タイムアウトよりも数分長く）構成できるため、アクティブなLeasequeryリクエスタがバインディングの変更を見逃す可能性が低くなります。
A requestor attempts to establish a TCP connection to a DHCPv6 server in order to initiate an Active Leasequery exchange. If the attempt fails, the requestor MAY retry. Retries should not be more frequent than one every ACTIVE_LQ_IDLE_TIMEOUT. See Section 6.4.
リクエスターは、Active Leasequery交換を開始するために、DHCPv6サーバーへのTCP接続を確立しようとします。試行が失敗した場合、リクエスタは再試行してもよい（MAY）。再試行の頻度は、ACTIVE_LQ_IDLE_TIMEOUTごとに1回より多くすべきではありません。セクション6.4を参照してください。
If an Active Leasequery is terminated prematurely by a LEASEQUERY-DONE with a DHCPv6 status code (carried in an OPTION_STATUS_CODE option) of QueryTerminated or by the failure of the connection over which it was being submitted, the requestor MAY retry the request after the creation of a new connection. Retries should not be more frequent than one every ACTIVE_LQ_IDLE_TIMEOUT. See Section 6.4.
Active Leasequeryが、QueryTerminatedのDHCPv6ステータスコード（OPTION_STATUS_CODEオプションで実行される）を持つLEASEQUERY-DONEによって、またはそれが送信された接続の失敗によって途中で終了した場合、リクエスタは、新しい接続。再試行の頻度は、ACTIVE_LQ_IDLE_TIMEOUTごとに1回より多くすべきではありません。セクション6.4を参照してください。
Messages from the DHCPv6 server come as multiple responses to a single ACTIVELEASEQUERY message. Thus, each ACTIVELEASEQUERY request MUST have a transaction-id unique on the connection on which it is sent, and all of the messages that come as a response to it contain the same transaction-id as the request.
DHCPv6サーバーからのメッセージは、1つのACTIVELEASEQUERYメッセージに対する複数の応答として送信されます。したがって、各ACTIVELEASEQUERY要求には、送信先の接続で一意のトランザクションIDが必要であり、その応答として送信されるすべてのメッセージには、要求と同じトランザクションIDが含まれている必要があります。
A requestor SHOULD be able to operate in either insecure or secure mode. This MAY be a feature that is administratively controlled.
リクエスタは、非セキュアモードまたはセキュアモードのいずれかで動作できる必要があります（SHOULD）。これは管理上制御される機能であるかもしれません。
When operating in insecure mode, the requestor SHOULD proceed to send an ACTIVELEASEQUERY message after the establishment of a TCP connection.
安全でないモードで動作している場合、リクエスタは、TCP接続の確立後にACTIVELEASEQUERYメッセージの送信に進む必要があります（SHOULD）。
When operating in secure mode, the requestor MUST attempt to negotiate a TLS [RFC5246] connection over the TCP connection. If this negotiation fails, the requestor MUST close the TCP connection. The recommendations in [RFC7525] SHOULD be followed when negotiating this connection.
セキュアモードで動作している場合、リクエスタはTCP接続を介してTLS [RFC5246]接続のネゴシエートを試行する必要があります。このネゴシエーションが失敗した場合、リクエスタはTCP接続を閉じる必要があります。 [RFC7525]の推奨事項は、この接続をネゴシエートする際に従う必要があります。
A requestor requests the establishment of a TLS connection by sending the STARTTLS message to the DHCPv6 server as the first message over the TCP connection. This message indicates to the DHCPv6 server that a TLS connection over this TCP connection is desired. There are four possibilities after the requestor sends the STARTTLS message to the DHCPv6 server:
リクエスターは、TCP接続を介して最初のメッセージとしてSTARTTLSメッセージをDHCPv6サーバーに送信することにより、TLS接続の確立を要求します。このメッセージは、DHCPv6サーバーに対して、このTCP接続を介したTLS接続が必要であることを示しています。リクエスタがSTARTTLSメッセージをDHCPv6サーバーに送信した後、4つの可能性があります。
1. No response from the DHCPv6 server.
1. DHCPv6サーバーからの応答がありません。
2. The DHCPv6 server closes the TCP connection after it receives the STARTTLS message.
2. DHCPv6サーバーは、STARTTLSメッセージを受信した後、TCP接続を閉じます。
3. The DHCPv6 server responds with a REPLY [RFC3315] message with a DHCPv6 status code of TLSConnectionRefused.
3. DHCPv6サーバーは、TLSConnectionRefusedのDHCPv6ステータスコードを含むREPLY [RFC3315]メッセージで応答します。
4. The DHCPv6 server responds with a REPLY [RFC3315] message without a DHCPv6 status code, indicating success.
4. DHCPv6サーバーは、成功を示すDHCPv6ステータスコードなしでREPLY [RFC3315]メッセージで応答します。
In any of the first three possibilities, the DHCPv6 server can be assumed to not support TLS. In this case, the requestor MUST close the TCP connection.
最初の3つの可能性のいずれかで、DHCPv6サーバーはTLSをサポートしていないと想定できます。この場合、リクエスタはTCP接続を閉じる必要があります。
In the final possibility, where the DHCPv6 server has responded with a REPLY message without a DHCPv6 status code in response to the requestor's STARTTLS message, the requestor SHOULD initiate the exchange of the messages involved in a TLS handshake [RFC5246]. During the TLS handshake, the requestor MUST validate the DHCPv6 server's digital certificate.
DHCPv6サーバーがリクエスタのSTARTTLSメッセージに応答してDHCPv6ステータスコードなしでREPLYメッセージで応答した最後の可能性では、リクエスタはTLSハンドシェイク[RFC5246]に含まれるメッセージの交換を開始する必要があります。 TLSハンドシェイク中に、リクエスタはDHCPv6サーバーのデジタル証明書を検証する必要があります。
If the handshake exchange yields a functioning TLS connection, then the requestor SHOULD transmit an ACTIVELEASEQUERY request over that TLS connection and use that TLS connection for all further interactions in which it engages with the DHCPv6 server over this TCP connection.
ハンドシェイク交換が機能するTLS接続を生成する場合、リクエスターは、そのTLS接続を介してACTIVELEASEQUERY要求を送信し、このTCP接続を介してDHCPv6サーバーと通信するすべての以降の対話にそのTLS接続を使用する必要があります（SHOULD）。
If the handshake exchange does not yield a functioning TLS connection, then the requestor MUST close the TCP connection.
ハンドシェイク交換が機能するTLS接続を生成しない場合、リクエスタはTCP接続を閉じる必要があります。
Active Leasequery is designed to create a long-lived connection between the requestor and the DHCPv6 server processing the active query. The DHCPv6 server SHOULD send binding information back across this connection with minimal delay after it learns of the binding information. It learns about bindings either because it makes the bindings itself or because it has received information about a binding from another server.
アクティブLeasequeryは、リクエスタとアクティブクエリを処理するDHCPv6サーバーの間に長期間の接続を作成するように設計されています。 DHCPv6サーバーは、バインディング情報を学習した後、最小限の遅延でこの接続を介してバインディング情報を送信する必要があります（SHOULD）。バインディング自体を作成するか、別のサーバーからバインディングに関する情報を受け取ったため、バインディングについて学習します。
An important capability of Active Leasequery is the ability of the requestor to specify that some recent data be sent immediately to the requestor in parallel with the transmission of the ongoing binding information in more or less real time. This capability is used in order to allow an Active Leasequery requestor to recover missed information in the event that it temporarily loses connectivity with the DHCPv6 server processing a previous Active Leasequery.
Active Leasequeryの重要な機能は、進行中のバインディング情報の送信とほぼリアルタイムで最近のデータをリクエスタに直ちに送信するようにリクエスタが指定できることです。この機能は、アクティブリースクエリリクエスタが以前のアクティブリースクエリを処理しているDHCPv6サーバーとの接続を一時的に失った場合に、失われた情報を回復できるようにするために使用されます。
This capability is enabled by the transmission of an OPTION_LQ_BASE_TIME option with each Leasequery reply sent as the result of a previous Active Leasequery. The requestor SHOULD keep track of the highest base-time received from a particular DHCPv6 server over an Active Leasequery connection, and in the event that the requestor finds it necessary (for whatever reason) to reestablish an Active Leasequery connection to that DHCPv6 server, the requestor SHOULD place this highest base-time value into an OPTION_LQ_START_TIME option in the new Active Leasequery request.
この機能は、OPTION_LQ_BASE_TIMEオプションの送信によって有効にされます。各Leasequery応答は、前のアクティブLeasequeryの結果として送信されます。リクエスタは、アクティブLeasequery接続を介して特定のDHCPv6サーバーから受信した最高のベースタイムを追跡する必要があり、リクエスタがそのDHCPv6サーバーへのアクティブLeasequery接続を再確立する必要がある場合は（何らかの理由で）、リクエスタは、この最も高いベースタイム値を新しいActive LeasequeryリクエストのOPTION_LQ_START_TIMEオプションに配置する必要があります（SHOULD）。
Note that until all of the recent data (catch-up data) has been received, the requestor MUST NOT keep track of the base-time (OPTION_LQ_BASE_TIME) received in Leasequery reply messages to use later in a subsequent Active Leasequery request.
すべての最近のデータ（キャッチアップデータ）が受信されるまで、リクエスターは、後続のアクティブLeasequery要求で後で使用するために、Leasequery応答メッセージで受信された基本時間（OPTION_LQ_BASE_TIME）を追跡してはなりません。
If the requestor doesn't wish to request an update of information missed when it was not connected to the DHCPv6 server, then it SHOULD NOT include the OPTION_LQ_START_TIME option in the Active Leasequery request.
リクエスタがDHCPv6サーバーに接続されていないときに失われた情報の更新を要求したくない場合は、アクティブリースクエリリクエストにOPTION_LQ_START_TIMEオプションを含めないでください。
If the TCP connection becomes blocked or stops being writable while the requestor is sending its query, the requestor SHOULD terminate the connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow requestors to control the period of time they are willing to wait before abandoning a connection, independent of notifications from the TCP implementations they may be using.
リクエスタがクエリを送信している間にTCP接続がブロックされるか書き込み可能でなくなった場合、リクエスタはBULK_LQ_DATA_TIMEOUTの後で接続を終了する必要があります（SHOULD）。この推奨事項は、使用しているTCP実装からの通知に関係なく、リクエスタが接続を放棄する前に待機する時間を制御できるようにするためのものです。
The requestor attempts to read a DHCPv6 LEASEQUERY-REPLY message from the TCP connection. If the stream of replies becomes blocked, the requestor SHOULD terminate the connection after ACTIVE_LQ_RCV_TIMEOUT and MAY begin retry processing if configured to do so.
リクエスターは、TCP接続からDHCPv6 LEASEQUERY-REPLYメッセージを読み取ろうとします。応答のストリームがブロックされた場合、リクエスタは、ACTIVE_LQ_RCV_TIMEOUTの後で接続を終了する必要があり（SHOULD）、そのように構成されている場合は再試行処理を開始できます（MAY）。
The requestor examines the LEASEQUERY-REPLY message and determines how to proceed. Message validation rules are specified in DHCPv6 Leasequery [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460]. If the reply contains a DHCPv6 status code (carried in an OPTION_STATUS_CODE option), the requestor should follow the recommendations in [RFC5007].
リクエスタはLEASEQUERY-REPLYメッセージを調べて、続行方法を決定します。メッセージ検証ルールは、DHCPv6 Leasequery [RFC5007]およびDHCPv6 Bulk Leasequery [RFC5460]で指定されています。応答にDHCPv6ステータスコード（OPTION_STATUS_CODEオプションで送信される）が含まれている場合、要求者は[RFC5007]の推奨事項に従う必要があります。
Note that the connection resulting from accepting an Active Leasequery request may be long-lived and may not have data transferring continuously during its lifetime. Therefore, the DHCPv6 server SHOULD send a LEASEQUERY-DATA message without binding data (OPTION_CLIENT_DATA) every ACTIVE_LQ_IDLE_TIMEOUT seconds (default 60) in order for the requestor to know that the connection remains alive. This approach is followed only when connection is idle (i.e., server has no binding data to send). During a normal exchange of binding data, receiving a LEASEQUERY-DATA message signifies that connection is active. Note that the default for ACTIVE_LQ_RCV_TIMEOUT is 120 seconds, twice the value of the ACTIVE_LQ_IDLE_TIMEOUT's default of 60 seconds, which drives the DHCPv6 server to send messages. Thus, ACTIVE_LQ_RCV_TIMEOUT controls how sensitive the requestor is to delays by the DHCPv6 server in sending updates or LEASEQUERY-DATA messages.
Active Leasequeryリクエストの受け入れから生じる接続は、存続期間が長く、その存続期間中にデータが継続的に転送されない可能性があることに注意してください。したがって、リクエスターが接続が存続していることを認識するために、DHCPv6サーバーはデータをバインドせずにLEASEQUERY-DATAメッセージ（OPTION_CLIENT_DATA）をACTIVE_LQ_IDLE_TIMEOUT秒（デフォルトは60）ごとに送信する必要があります（SHOULD）。このアプローチは、接続がアイドル状態の場合にのみ実行されます（つまり、サーバーに送信するバインディングデータがありません）。バインディングデータの通常の交換中に、LEASEQUERY-DATAメッセージを受信すると、接続がアクティブであることを示します。 ACTIVE_LQ_RCV_TIMEOUTのデフォルトは120秒であり、ACTIVE_LQ_IDLE_TIMEOUTのデフォルトの60秒の値の2倍であることに注意してください。これにより、DHCPv6サーバーがメッセージを送信します。したがって、ACTIVE_LQ_RCV_TIMEOUTは、更新プログラムまたはLEASEQUERY-DATAメッセージの送信におけるDHCPv6サーバーによる遅延に対するリクエスターの感度を制御します。
A single Active Leasequery can and usually will result in a large number of replies. The requestor MUST be prepared to receive more than one reply with transaction-ids matching a single ACTIVELEASEQUERY message from a single DHCPv6 server.
1つのActive Leasequeryは、通常、多数の応答を返す可能性があります。リクエスタは、単一のDHCPv6サーバーからの単一のACTIVELEASEQUERYメッセージに一致するトランザクションIDを持つ複数の応答を受信できるように準備する必要があります。
An Active Leasequery has two regimes: during the catch-up phase (if any) and after any catch-up phase. If the Active Leasequery was requested with an OPTION_LQ_START_TIME option, the Active Leasequery starts out in the catch-up phase. See Section 8.4.1 for information on processing during the catch-up phase, as well as how to determine when the catch-up phase is complete.
アクティブリースクエリには、キャッチアップフェーズ中（存在する場合）とキャッチアップフェーズ後の2つのレジームがあります。 OPTION_LQ_START_TIMEオプションを指定してアクティブリースクエリが要求された場合、アクティブリースクエリはキャッチアップフェーズで開始されます。キャッチアップフェーズの処理に関する情報と、キャッチアップフェーズがいつ完了したかを判断する方法については、セクション8.4.1を参照してください。
The updates sent by the DHCPv6 server during the catch-up phase are not in the order that the lease state data was updated. Therefore, the OPTION_LQ_BASE_TIME option from messages during this phase MUST NOT be saved and used to compute the subsequent ACTIVELEASEQUERY message's OPTION_LQ_START_TIME option.
キャッチアップフェーズ中にDHCPv6サーバーによって送信された更新は、リース状態データが更新された順序ではありません。したがって、このフェーズ中のメッセージのOPTION_LQ_BASE_TIMEオプションを保存して、後続のACTIVELEASEQUERYメッセージのOPTION_LQ_START_TIMEオプションを計算するために使用してはなりません（MUST NOT）。
After the catch-up phase, or during the entire series of messages received as the response to an Active Leasequery request with no OPTION_LQ_START_TIME (and therefore no catch-up phase), the OPTION_LQ_BASE_TIME option of the most recent message SHOULD be saved as a record of the most recent time that data was received. This base-time (in the context of the DHCPv6 server) can be used in a subsequent Active Leasequery message's OPTION_LQ_START_TIME after a loss of the Active Leasequery connection.
キャッチアップフェーズの後、またはOPTION_LQ_START_TIMEがない（したがって、キャッチアップフェーズがない）Active Leasequery要求への応答として受信される一連のメッセージ全体の間に、最新のメッセージのOPTION_LQ_BASE_TIMEオプションをレコードとして保存する必要があります（SHOULD）データが受信された最新の時間の。このベースタイム（DHCPv6サーバーのコンテキストで）は、アクティブLeasequery接続が失われた後の後続のアクティブLeasequeryメッセージのOPTION_LQ_START_TIMEで使用できます。
The LEASEQUERY-DONE message MAY unilaterally terminate a successful Active Leasequery request that is currently in progress in the event that the DHCPv6 server determines that it cannot continue processing an Active Leasequery request. For example, when a server is requested to shut down, it SHOULD send a LEASEQUERY-DONE message with a DHCPv6 status code of QueryTerminated and include the OPTION_LQ_BASE_TIME option in the message. This MUST be the last message on that connection, and once the message has been transmitted, the server MUST close the connection.
LEASEQUERY-DONEメッセージは、DHCPv6サーバーがActive Leasequery要求の処理を続行できないと判断した場合に、現在進行中の正常なActive Leasequery要求を一方的に終了する場合があります。たとえば、サーバーがシャットダウンを要求された場合、サーバーはDHCPv6ステータスコードがQueryTerminatedのLEASEQUERY-DONEメッセージを送信し、メッセージにOPTION_LQ_BASE_TIMEオプションを含める必要があります（SHOULD）。これはその接続の最後のメッセージである必要があり、メッセージが送信されると、サーバーは接続を閉じる必要があります。
After receiving LEASEQUERY-DONE with a QueryTerminated status from a server, the requestor MAY close the TCP connection to that server.
サーバーからQueryTerminatedステータスのLEASEQUERY-DONEを受け取った後、リクエスタはそのサーバーへのTCP接続を閉じてもよい（MAY）。
8.4.1. Processing Replies from a Request Containing an OPTION_LQ_START_TIME
8.4.1. OPTION_LQ_START_TIMEを含むリクエストからの返信の処理
If the Active Leasequery was requested with an OPTION_LQ_START_TIME option, the DHCPv6 server will attempt to send information about all bindings that changed since the time specified in the OPTION_LQ_START_TIME. This is the catch-up phase of the Active Leasequery processing. The DHCPv6 server MAY also send information about real-time binding updates over the same connection. Thus, the catch-up phase can run in parallel with the normal updates generated by the Active Leasequery request.
OPTION_LQ_START_TIMEオプションを指定してアクティブリースクエリが要求された場合、DHCPv6サーバーは、OPTION_LQ_START_TIMEで指定された時刻以降に変更されたすべてのバインディングに関する情報を送信しようとします。これは、Active Leasequery処理のキャッチアップフェーズです。 DHCPv6サーバーは、同じ接続を介してリアルタイムのバインディング更新に関する情報を送信することもできます（MAY）。したがって、キャッチアップフェーズは、Active Leasequery要求によって生成される通常の更新と並行して実行できます。
A DHCPv6 server MAY keep only a limited amount of time-ordered information available to respond to an Active Leasequery request containing an OPTION_LQ_START_TIME option. Thus, it is possible that the time specified in the OPTION_LQ_START_TIME option represents a time not covered by the time-ordered information kept by the DHCPv6 server. In such case, when there is not enough data saved in the DHCPv6 server to satisfy the request specified by the OPTION_LQ_START_TIME option, the DHCPv6 server will reply immediately with a LEASEQUERY-REPLY message with a DHCPv6 status code of DataMissing with a base-time option equal to the server's current time. This will signal the end of the catch-up phase, and the only updates that will subsequently be received on this connection are the real-time updates from the Active Leasequery request.
DHCPv6サーバーは、OPTION_LQ_START_TIMEオプションを含むActive Leasequery要求に応答するために利用可能な限られた時間の順序情報のみを保持してもよい（MAY）。したがって、OPTION_LQ_START_TIMEオプションで指定された時間が、DHCPv6サーバーが保持する時間順の情報でカバーされない時間を表す可能性があります。そのような場合、OPTION_LQ_START_TIMEオプションで指定された要求を満たすのに十分なデータがDHCPv6サーバーに保存されていない場合、DHCPv6サーバーは、ベースタイムオプションでDHCPv6ステータスコードがDataMissingであるLEASEQUERY-REPLYメッセージで即座に応答します。サーバーの現在時刻と同じです。これにより、キャッチアップフェーズの終了が通知されます。その後、この接続で受信される唯一の更新は、Active Leasequery要求からのリアルタイムの更新です。
If there is enough data saved to satisfy the request, then LEASEQUERY-REPLY (with OPTION_STATUS_CODE of Success or reply without the OPTION_STATUS_CODE option) and LEASEQUERY-DATA messages will begin to arrive from the DHCPv6 server. Some of these messages will be related to the OPTION_LQ_START_TIME request and be part of the catch-up phase. Some of these messages will be real-time updates of binding changes taking place in the DHCPv6 server. In general, there is no way to determine the source of each message.
要求を満たすのに十分なデータが保存されている場合、LEASEQUERY-REPLY（OPTION_STATUS_CODEは成功、またはOPTION_STATUS_CODEオプションなしで応答）とLEASEQUERY-DATAメッセージがDHCPv6サーバーから届き始めます。これらのメッセージの一部は、OPTION_LQ_START_TIMEリクエストに関連し、キャッチアップフェーズの一部になります。これらのメッセージの一部は、DHCPv6サーバーで行われているバインディング変更のリアルタイム更新です。一般に、各メッセージのソースを判別する方法はありません。
The updates sent by the DHCPv6 server during the catch-up phase are not in the order that the binding data was updated. Therefore, until the catch-up phase is complete, the latest base-time value received from a DHCPv6 server processing an Active Leasequery request cannot be reset from the incoming messages (and used in a subsequent Active Leasequery's query-start-time option), because to do so would compromise the ability to recover lost information if the Active Leasequery were to terminate prior to the completion of the catch-up phase.
キャッチアップフェーズ中にDHCPv6サーバーによって送信された更新は、バインディングデータが更新された順序ではありません。したがって、キャッチアップフェーズが完了するまで、Active Leasequery要求を処理するDHCPv6サーバーから受信した最新のベースタイム値は、着信メッセージからリセットできません（そして、後続のActive Leasequeryのquery-start-timeオプションで使用されます）。これを行うと、キャッチアップフェーズの完了前にアクティブリースクエリが終了した場合、失われた情報を回復する機能が損なわれます。
The requestor will know that the catch-up phase is complete when the DHCPv6 server transmits a LEASEQUERY-DATA message with the DHCPv6 status code of CatchUpComplete (or a LEASEQUERY-REPLY message with a DHCPv6 status code of DataMissing, as discussed above). Once this message is transmitted, all additional LEASEQUERY-DATA messages will relate to real-time ("new") binding changes in the DHCPv6 server.
DHCPv6サーバーがDHCPv6ステータスコードがCatchUpCompleteのLEASEQUERY-DATAメッセージ（またはDHCPv6ステータスコードがDataMissingのLEASEQUERY-REPLYメッセージを上で説明したように送信）を送信すると、リクエスタはキャッチアップフェーズが完了したことを知っています。このメッセージが送信されると、追加のすべてのLEASEQUERY-DATAメッセージは、DHCPv6サーバーでのリアルタイム（「新しい」）バインディングの変更に関連します。
As discussed in Section 8.4, the requestor SHOULD keep track of the latest base-time option value received over a particular connection, to be used in a subsequent Active Leasequery request, but only if the catch-up phase is complete. Prior to the completion of the catch-up phase, if the connection should go away or if the requestor receives a LEASEQUERY-DONE message, then when it reconnects, it MUST use the base-time value from the previous connection and not any base-time value received from the recently closed connection.
セクション8.4で説明したように、リクエスタは、特定の接続を介して受信した最新のベースタイムオプション値を追跡し、後続のアクティブリースクエリ要求で使用する必要があります（ただし、キャッチアップフェーズが完了した場合のみ）。キャッチアップフェーズが完了する前に、接続を切断する必要がある場合、またはリクエスタがLEASEQUERY-DONEメッセージを受信した場合、再接続するときに、以前の接続からのベースタイム値を使用する必要があります。最近閉じた接続から受信した時間の値。
In the event that there was enough data available to the DHCPv6 server to begin to satisfy the request implied by the OPTION_LQ_START_TIME option but during the processing of that data, the server found that it was unable to continue (during transmission, the aging algorithm causes [some of] the saved data to become unavailable), the DHCPv6 server will terminate the catch-up phase of processing immediately by sending a LEASEQUERY-DATA message with a DHCPv6 status code of DataMissing and with a base-time option of the current time.
DHCPv6サーバーが利用できる十分なデータがあり、OPTION_LQ_START_TIMEオプションによって暗黙に指定された要求を満たし始めることができたが、そのデータの処理中に、サーバーが続行できないことが判明した場合（送信中に、エージングアルゴリズムが原因で[一部の]保存されたデータが使用できなくなる）、DHCPv6サーバーは、DatavissingのDHCPv6ステータスコードと現在時刻のベースタイムオプションを含むLEASEQUERY-DATAメッセージを送信することにより、処理のキャッチアップフェーズを直ちに終了します。
The requestor MUST NOT assume that every individual state change of every binding during the period from the time specified in the OPTION_LQ_START_TIME and the present is replicated in an Active Leasequery reply message. The requestor MAY assume that at least one Active Leasequery reply message will exist for every binding that had one or more changes of state during the period specified by the OPTION_LQ_START_TIME and the current time. The last message for each binding will contain the state at the current time, and there can be one or more messages concerning a single binding during the catch-up phase of processing.
リクエスターは、OPTION_LQ_START_TIMEで指定された時刻から現在までの期間の間に、すべてのバインディングの個々の状態が変化し、現在がActive Leasequery応答メッセージで複製されると想定してはなりません。リクエスタは、OPTION_LQ_START_TIMEと現在の時刻で指定された期間中に1つ以上の状態の変化があったすべてのバインディングに対して、少なくとも1つのアクティブなLeasequery応答メッセージが存在すると想定してもよい（MAY）。各バインディングの最後のメッセージには、現時点での状態が含まれ、処理のキャッチアップフェーズ中に単一のバインディングに関するメッセージが1つ以上存在する可能性があります。
Bindings can change multiple times while the requestor is not connected (that is, during the time from the OPTION_LQ_START_TIME to the present). The requestor will only receive information about the current state of the binding, not information about each state change that occurred during the period from the OPTION_LQ_START_TIME to the present.
リクエスタが接続されていない間（つまり、OPTION_LQ_START_TIMEから現在まで）に、バインディングは複数回変更される可能性があります。リクエスタは、バインディングの現在の状態に関する情報のみを受信し、OPTION_LQ_START_TIMEから現在までの期間中に発生した各状態変化に関する情報は受信しません。
If the LEASEQUERY-REPLY or LEASEQUERY-DATA message containing a DHCPv6 status code of DataMissing is received and the requestor is interested in keeping its database up to date with respect to the current state of bindings in the DHCPv6 server, then the requestor SHOULD issue a Bulk Leasequery request to recover the information missing from its database. This Bulk Leasequery request SHOULD include an OPTION_LQ_START_TIME option with the same value as the OPTION_LQ_START_TIME option previously included in the Active Leasequery responses from the DHCPv6 server and an OPTION_LQ_END_TIME option equal to the OPTION_LQ_BASE_TIME option returned by the DHCPv6 server in the LEASEQUERY-REPLY or LEASEQUERY-DATA message with the DHCPv6 status code of DataMissing.
DatavissingのDHCPv6ステータスコードを含むLEASEQUERY-REPLYまたはLEASEQUERY-DATAメッセージが受信され、リクエスタがDHCPv6サーバーのバインディングの現在の状態に関してデータベースを最新に保つことに関心がある場合、リクエスタは、データベースから欠落している情報を回復するための一括Leasequeryリクエスト。この一括リースクエリ要求には、以前にDHCPv6サーバーからのアクティブリースクエリ応答に含まれていたOPTION_LQ_START_TIMEオプションと同じ値のOPTION_LQ_START_TIMEオプションと、LEASEQUERY-REPLYまたはLEASEQUERY-REPLYのDHCPv6サーバーによって返されたOPTION_LQ_BASE_TIMEオプションと等しいOPTION_LQ_END_TIMEオプションが含まれる必要があります（SHOULD）。 DataMissingのDHCPv6ステータスコードを含むDATAメッセージ。
Typically, the requestor would have one connection open to a DHCPv6 server for an Active Leasequery request and possibly one additional connection open for a Bulk Leasequery request to the same DHCPv6 server to fill in the data that might have been missed prior to the initiation of the Active Leasequery. The Bulk Leasequery connection would typically run to completion and be closed, leaving one Active Leasequery connection open to a single DHCPv6 server.
通常、リクエスタは、Active Leasequery要求のためにDHCPv6サーバーへの1つの接続を開き、同じDHCPv6サーバーへのBulk Leasequery要求のために1つの追加の接続を開いて、の開始前に失われた可能性のあるデータを入力します。アクティブLeasequery。一括リースクエリ接続は通常、完了するまで実行されて閉じられ、1つのアクティブリースクエリ接続が単一のDHCPv6サーバーに対して開かれたままになります。
Active or Bulk Leasequery requests can be made to a DHCPv6 server whose absolute time may not be synchronized with the local time of the requestor. Thus, there are at least two time contexts in even the simplest Active or Bulk Leasequery response.
アクティブまたはバルクLeasequery要求は、絶対時間がリクエスタのローカル時間と同期していない可能性があるDHCPv6サーバーに対して行うことができます。したがって、最も単純なアクティブ応答またはバルクリースクエリの応答でさえ、少なくとも2つの時間コンテキストがあります。
If the requestor of an Active or Bulk Leasequery is saving the data returned in some form, it has a requirement to store a variety of time values; some of these will be time in the context of the requestor, and some will be time in the context of the DHCPv6 server.
アクティブまたは一括リースクエリのリクエスタが返されたデータを何らかの形式で保存している場合、さまざまな時間値を保存する必要があります。これらの一部はリクエスタのコンテキストでの時間であり、一部はDHCPv6サーバーのコンテキストでの時間です。
When receiving an Active or Bulk Leasequery reply message from the DHCPv6 server, the message will contain an OPTION_LQ_BASE_TIME option. The time contained in this OPTION_LQ_BASE_TIME option is in the context of the DHCPv6 server. As such, it is an ideal time to save and use as input to an Active or Bulk Leasequery message in the OPTION_LQ_START_TIME or OPTION_LQ_END_TIME options should the requestor need to ever issue an Active or Bulk Leasequery message using these options as part of a later query, since these options require a time in the context of the DHCPv6 server.
DHCPv6サーバーからアクティブまたは一括リースクエリ応答メッセージを受信すると、メッセージにはOPTION_LQ_BASE_TIMEオプションが含まれます。このOPTION_LQ_BASE_TIMEオプションに含まれる時間は、DHCPv6サーバーのコンテキストにあります。そのため、リクエスタが後のクエリの一部としてこれらのオプションを使用してアクティブまたはバルクリースクエリメッセージを発行する必要がある場合は、OPTION_LQ_START_TIMEまたはOPTION_LQ_END_TIMEオプションでアクティブまたはバルクリースクエリメッセージへの入力として保存して使用するのが理想的です。これらのオプションは、DHCPv6サーバーのコンテキストで時間を必要とするためです。
In addition to saving the OPTION_LQ_BASE_TIME for possible future use in the OPTION_LQ_START_TIME or OPTION_LQ_END_TIME options, the OPTION_LQ_BASE_TIME option is used as part of the conversion of the other times in the Leasequery message to values that are meaningful in the context of the requestor.
OPTION_LQ_START_TIMEまたはOPTION_LQ_END_TIMEオプションで将来使用できるようにOPTION_LQ_BASE_TIMEを保存することに加えて、OPTION_LQ_BASE_TIMEオプションは、要求元のコンテキストで意味のある値へのLeasequeryメッセージ内の他の時間の変換の一部として使用されます。
In systems whose clocks are synchronized, perhaps using the Network Time Protocol (NTP), the clock skew will usually be zero, which is not only acceptable, but desired.
おそらくネットワークタイムプロトコル（NTP）を使用してクロックが同期されているシステムでは、クロックスキューは通常ゼロです。これは許容できるだけでなく、望ましいことです。
These examples illustrate what a series of queries and responses might look like. These are only examples -- there is no requirement that these sequences must be followed.
これらの例は、一連のクエリと応答がどのように見えるかを示しています。これらは単なる例であり、これらのシーケンスに従う必要はありません。
This example illustrates the message flows in case the DHCPv6 server identifies that it cannot accept and/or process an Active Leasequery request from the requestor. This could be because of various reasons (i.e., UnknownQueryType, MalformedQuery, NotConfigured, NotAllowed, and NotSupported).
この例は、DHCPv6サーバーがリクエスターからのアクティブLeasequery要求を受け入れたり処理したりできないことを識別した場合のメッセージフローを示しています。これは、さまざまな理由（UnknownQueryType、MalformedQuery、NotConfigured、NotAllowed、NotSupportedなど）が原因である可能性があります。
Client Server
------ ------
ACTIVELEASEQUERY xid 1 ----->
<----- LEASEQUERY-REPLY xid 1 (w/error)
This example illustrates the message flows in case the DHCPv6 server identifies that it does not have enough data saved to satisfy the request specified by the OPTION_LQ_START_TIME option.
この例は、OPTION_LQ_START_TIMEオプションで指定された要求を満たすのに十分なデータが保存されていないことをDHCPv6サーバーが識別した場合のメッセージフローを示しています。
In this case, the DHCPv6 server will reply immediately with a LEASEQUERY-REPLY message with a DHCPv6 status code of DataMissing with a base-time option equal to the server's current time. This will signal the end of the catch-up phase, and the only updates that will subsequently be received on this connection are the real-time updates from the Active Leasequery request.
この場合、DHCPv6サーバーは、サーバーの現在の時刻に等しい基本時刻オプションを使用して、DataMissingのDHCPv6ステータスコードを含むLEASEQUERY-REPLYメッセージで即座に応答します。これにより、キャッチアップフェーズの終了が通知されます。その後、この接続で受信される唯一の更新は、Active Leasequery要求からのリアルタイムの更新です。
Client Server
------ ------
ACTIVELEASEQUERY xid 2 ----->
<----- LEASEQUERY-REPLY xid 2 (w/error)
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2
<----- LEASEQUERY-DATA xid 2
This example illustrates the message flows in case of successful query processing by the DHCPv6 server.
この例は、DHCPv6サーバーによるクエリ処理が成功した場合のメッセージフローを示しています。
In this case, the DHCPv6 server will reply immediately with a LEASEQUERY-REPLY message (with OPTION_STATUS_CODE of Success or reply without OPTION_STATUS_CODE option), followed by binding data in LEASEQUERY-DATA messages. In case the DHCPv6 server wants to abort an in-process request and terminate the connection due to some reason, it sends LEASEQUERY-DONE with an error code present in the OPTION_STATUS_CODE option.
この場合、DHCPv6サーバーは、LEASEQUERY-REPLYメッセージ（成功のOPTION_STATUS_CODEを指定するか、OPTION_STATUS_CODEオプションを指定せずに応答する）ですぐに応答し、その後、LEASEQUERY-DATAメッセージでデータをバインドします。 DHCPv6サーバーがインプロセス要求を中止し、なんらかの理由で接続を終了したい場合は、OPTION_STATUS_CODEオプションにエラーコードが存在するLEASEQUERY-DONEを送信します。
Client Server
------ ------
ACTIVELEASEQUERY xid 3 ----->
<----- LEASEQUERY-REPLY xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DATA xid 3
<----- LEASEQUERY-DONE xid 3 (w/error)
The requestor or DHCPv6 Leasequery server MAY close its end of the TCP connection at any time. The requestor MAY choose to retain the connection if it intends to issue additional queries. Note that this requestor behavior does not guarantee that the connection will be available for additional queries: the server might decide to close the connection based on its own configuration.
リクエスタまたはDHCPv6 Leasequeryサーバーは、TCP接続の最後をいつでも閉じることができます（MAY）。リクエスタは、追加のクエリを発行する場合、接続を保持することを選択できます。このリクエスタの動作は、接続が追加のクエリで使用できることを保証するものではないことに注意してください。サーバーは独自の構成に基づいて接続を閉じることを決定する場合があります。
A DHCPv6 server that supports Active Leasequery MUST support DHCPv6 Bulk Leasequery [RFC5460] along with the updates mentioned in this document.
Active LeasequeryをサポートするDHCPv6サーバーは、このドキュメントで言及されている更新と共にDHCPv6 Bulk Leasequery [RFC5460]をサポートする必要があります。
DHCPv6 servers that implement DHCPv6 Active Leasequery listen for incoming TCP connections. The approach used in accepting the requestor's connection is the same as specified in DHCPv6 Bulk Leasequery [RFC5460], with the exception that support for Active Leasequery MUST NOT be enabled by default and MUST require an explicit configuration step to be performed before it will operate.
DHCPv6 Active Leasequeryを実装するDHCPv6サーバーは、着信TCP接続をリッスンします。リクエスタの接続の受け入れに使用されるアプローチは、DHCPv6バルクリースクエリ[RFC5460]で指定されているものと同じですが、アクティブリースクエリのサポートはデフォルトで有効にしてはならず、動作する前に明示的な構成手順を実行する必要があることを例外とします。
DHCPv6 servers SHOULD be able to operate in either insecure or secure mode. This MAY be a mode that is administratively controlled, where the server will require a TLS connection to operate or will only operate without a TLS connection. In either case, operation in insecure mode MUST NOT be the default, even if operation in secure mode is not supported. Operation in insecure mode MUST always require an explicit configuration step, separate from the configuration step required to enable support for Active Leasequery.
DHCPv6サーバーは、非セキュアモードまたはセキュアモードのいずれかで動作できる必要があります（SHOULD）。これは、サーバーが動作するためにTLS接続を必要とするか、TLS接続なしでのみ動作する、管理上制御されるモードである場合があります。どちらの場合も、セキュアモードでの操作がサポートされていない場合でも、非セキュアモードでの操作をデフォルトにすることはできません。安全でないモードでの操作では、アクティブリースクエリのサポートを有効にするために必要な構成手順とは別に、常に明示的な構成手順が必要です。
When operating in insecure mode, the DHCPv6 server simply waits for the requestor to send the Active Leasequery request after the establishment of a TCP connection. If it receives a STARTTLS message, it MUST respond with a REPLY [RFC3315] message with a DHCPv6 status code of TLSConnectionRefused.
安全でないモードで動作している場合、DHCPv6サーバーは、TCP接続の確立後、リクエスタがActive Leasequery要求を送信するのを待つだけです。 STARTTLSメッセージを受信した場合は、TLSConnectionRefusedのDHCPv6ステータスコードを含むREPLY [RFC3315]メッセージで応答する必要があります。
When operating in secure mode, DHCPv6 servers MUST support TLS [RFC5246] to protect the integrity and privacy of the data transmitted over the TCP connection. When operating in secure mode, DHCPv6 servers MUST be configurable with regard to which requestors they will communicate. The certificate presented by a requestor when initiating the TLS connection is used to distinguish between acceptable and unacceptable requestors.
セキュアモードで動作する場合、DHCPv6サーバーは、TCP接続を介して送信されるデータの整合性とプライバシーを保護するためにTLS [RFC5246]をサポートする必要があります。セキュアモードで動作している場合、DHCPv6サーバーは、通信するリクエスタに関して構成可能でなければなりません。 TLS接続を開始するときにリクエスタによって提示される証明書は、受け入れ可能なリクエスタと受け入れられないリクエスタを区別するために使用されます。
When operating in secure mode, the DHCPv6 server MUST begin to negotiate a TLS connection with a requestor who asks for one and MUST close the TCP connections that are not secured with TLS or for which the requestor's certificate is deemed unacceptable. The recommendations in [RFC7525] SHOULD be followed when negotiating a TLS connection.
セキュアモードで動作している場合、DHCPv6サーバーは、接続を要求するリクエスタとTLS接続のネゴシエーションを開始しなければならず、TLSで保護されていないか、リクエスタの証明書が受け入れられないと見なされるTCP接続を閉じる必要があります。 [RFC7525]の推奨事項は、TLS接続をネゴシエートするときに従う必要があります。
A requestor will request a TLS connection by sending a STARTTLS as the first message over a newly created TCP connection. If the DHCPv6 server supports TLS connections and has not been configured to not allow them on this link, the DHCPv6 server MUST respond to this STARTTLS message by sending a REPLY [RFC3315] message without a DHCPv6 status code back to the requestor. This indicates to the requestor that the DHCPv6 server will support the negotiation of a TLS connection over this existing TCP connection.
リクエスタは、新しく作成されたTCP接続を介して最初のメッセージとしてSTARTTLSを送信することにより、TLS接続を要求します。 DHCPv6サーバーがTLS接続をサポートし、このリンクでそれらを許可しないように構成されていない場合、DHCPv6サーバーは、リクエスタにDHCPv6ステータスコードなしでREPLY [RFC3315]メッセージを送信して、このSTARTTLSメッセージに応答する必要があります。これは、DHCPv6サーバーがこの既存のTCP接続を介したTLS接続のネゴシエーションをサポートすることを要求者に示します。
If for some reason the DHCPv6 server cannot support a TLS connection or has been configured to not support a TLS connection, then it SHOULD send a REPLY message with a DHCPv6 status code of TLSConnectionRefused back to the requestor.
何らかの理由でDHCPv6サーバーがTLS接続をサポートできないか、TLS接続をサポートしないように構成されている場合、DHCPv6ステータスコードがTLSConnectionRefusedのREPLYメッセージをリクエスタに送信する必要があります（SHOULD）。
In the event that the DHCPv6 server sends a REPLY message without a DHCPv6 status code option included (which indicates success), the requestor is supposed to initiate a TLS handshake [RFC5246] (see Section 8.2). During the TLS handshake, the DHCPv6 server MUST validate the requestor's digital certificate. In addition, the digital certificate presented by the requestor is used to decide if this requestor is allowed to perform an Active Leasequery. If this requestor's certificate is deemed unacceptable, the server MUST abort the creation of the TLS connection.
DHCPv6サーバーがDHCPv6ステータスコードオプションを含まずにREPLYメッセージを送信した場合（成功を示します）、リクエスターはTLSハンドシェイク[RFC5246]を開始することになっています（セクション8.2を参照）。 TLSハンドシェイクの間、DHCPv6サーバーは要求者のデジタル証明書を検証する必要があります。さらに、リクエスタによって提示されたデジタル証明書は、このリクエスタがアクティブリースクエリを実行できるかどうかを決定するために使用されます。このリクエスターの証明書が受け入れられないと思われる場合、サーバーはTLS接続の作成を中止しなければなりません（MUST）。
All TLS connections established between a requestor and a DHCPv6 server for the purposes of supporting Active Leasequery MUST be mutually authenticated.
Active Leasequeryをサポートする目的でリクエスタとDHCPv6サーバーの間に確立されたすべてのTLS接続は、相互に認証される必要があります。
If the TLS handshake is not successful in creating a TLS connection, the server MUST close the TCP connection.
TLSハンドシェイクがTLS接続の作成に成功しない場合、サーバーはTCP接続を閉じる必要があります。
Servers that do not implement DHCPv6 Active and Bulk Leasequery SHOULD NOT listen for incoming TCP connections for these requests.
DHCPv6 ActiveおよびBulk Leasequeryを実装していないサーバーは、これらの要求の着信TCP接続をリッスンしてはいけません（SHOULD NOT）。
If the DHCPv6 server supporting Bulk Leasequery and not Active Leasequery receives an Active Leasequery request, it SHOULD send a LEASEQUERY-REPLY with a DHCPv6 status code of NotSupported. It SHOULD close the TCP connection after this error is signaled.
Bulk Leasequeryではなく、Bulk LeasequeryをサポートするDHCPv6サーバーがActive Leasequeryリクエストを受信した場合、DHCPv6ステータスコードがNotSupportedのLEASEQUERY-REPLYを送信する必要があります。このエラーが通知された後、TCP接続を閉じる必要があります。
The DHCPv6 Leasequery [RFC5007] specification describes the initial construction of LEASEQUERY-REPLY messages. Use of the LEASEQUERY-REPLY and LEASEQUERY-DATA messages to carry multiple bindings is described in DHCPv6 Bulk Leasequery [RFC5460]. Message transmission and framing for TCP is described in Section 6.1.
DHCPv6 Leasequery [RFC5007]仕様では、LEASEQUERY-REPLYメッセージの初期構成について説明しています。 LEASEQUERY-REPLYおよびLEASEQUERY-DATAメッセージを使用して複数のバインディングを伝送する方法については、DHCPv6バルクリースクエリ[RFC5460]で説明されています。 TCPのメッセージ送信とフレーミングについては、セクション6.1で説明します。
If the connection becomes blocked while the server is attempting to send reply messages, the server SHOULD terminate the TCP connection after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs for how long the DHCPv6 server is prepared to wait for the requestor to read and process enough information to unblock the TCP connection. The default is two minutes, which means that if more than two minutes goes by without the requestor reading enough information to unblock the TCP connection, the DHCPv6 server SHOULD close the TCP connection.
サーバーが応答メッセージを送信しようとしている間に接続がブロックされた場合、サーバーは、ACTIVE_LQ_SEND_TIMEOUTの後でTCP接続を終了する必要があります（SHOULD）。このタイムアウトは、リクエスターがTCP接続のブロックを解除するのに十分な情報を読み取って処理するのをDHCPv6サーバーが待機する準備ができる時間を管理します。デフォルトは2分です。つまり、リクエスターがTCP接続のブロックを解除するのに十分な情報を読み取らないまま2分以上経過した場合、DHCPv6サーバーはTCP接続を閉じる必要があります（SHOULD）。
If the DHCPv6 server encounters an error during the initial processing of the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-REPLY message containing an error code of some kind in a DHCPv6 status code option. It SHOULD close the connection after this error is signaled.
DHCPv6サーバーは、ACTIVELEASEQUERYメッセージの初期処理中にエラーを検出した場合、DHCPv6ステータスコードオプションにある種のエラーコードを含むLEASEQUERY-REPLYメッセージを送信する必要があります（SHOULD）。このエラーが通知された後、接続を閉じる必要があります。
If the DHCPv6 server encounters an error during later processing of the ACTIVELEASEQUERY message, it SHOULD send a LEASEQUERY-DONE containing an error code of some kind in a DHCPv6 status code option. It SHOULD close the connection after this error is signaled.
DHCPv6サーバーは、ACTIVELEASEQUERYメッセージの処理中にエラーが発生した場合、DHCPv6ステータスコードオプションにある種のエラーコードを含むLEASEQUERY-DONEを送信する必要があります（SHOULD）。このエラーが通知された後、接続を閉じる必要があります。
If the server finds any bindings satisfying a query, it SHOULD send each binding's data in a reply message. The first reply message is a LEASEQUERY-REPLY. The binding data is carried in an OPTION_CLIENT_DATA option, as specified in [RFC5007]. The server SHOULD send subsequent bindings in LEASEQUERY-DATA messages, which can avoid redundant data (such as the requestor's Client-ID).
サーバーがクエリを満たすバインディングを見つけた場合、サーバーは各バインディングのデータを応答メッセージで送信する必要があります（SHOULD）。最初の応答メッセージはLEASEQUERY-REPLYです。バインディングデータは、[RFC5007]で指定されているように、OPTION_CLIENT_DATAオプションで伝達されます。サーバーは、後続のバインディングをLEASEQUERY-DATAメッセージで送信する必要があります。これにより、冗長なデータ（リクエスタのクライアントIDなど）を回避できます。
Every reply to an Active Leasequery request MUST contain the information specified in replies to a DHCPv6 Bulk Leasequery request [RFC5460], with the exception that a server implementing Active Leasequery SHOULD be able to be configured to prevent specific data items from being sent to the requestor even if these data items were requested in the OPTION_ORO option.
Active Leasequery要求へのすべての応答には、DHCPv6一括Leasequery要求[RFC5460]への応答で指定された情報を含める必要があります。ただし、Active Leasequeryを実装するサーバーは、特定のデータ項目が要求者に送信されないように構成できる必要があります（SHOULD）。これらのデータ項目がOPTION_OROオプションで要求された場合でも。
Some servers can be configured to respond to a DHCPv6 Leasequery [RFC5007] and DHCPv6 Bulk Leasequery [RFC5460] for an IPv6 binding that is reserved in such a way that it appears that the IPv6 binding is leased to the DHCP client for which it is reserved. These servers SHOULD also respond to an Active Leasequery request with the same information as they would to a Bulk Leasequery request when they first determine that the IPv6 binding is reserved to a DHCP client.
一部のサーバーは、予約されているDHCPクライアントにIPv6バインディングがリースされているように見えるように、予約されているIPv6バインディングのDHCPv6 Leasequery [RFC5007]およびDHCPv6バルクリースクエリ[RFC5460]に応答するように構成できます。 。これらのサーバーは、IPv6バインディングがDHCPクライアントに予約されていると最初に判断したときに、バルクリースクエリリクエストへの応答と同じ情報でアクティブリースクエリリクエストにも応答する必要があります（SHOULD）。
If an Active Leasequery or Bulk Leasequery request contains the OPTION_LQ_BASE_TIME option code present in OPTION_ORO, the DHCPv6 server MUST include the OPTION_LQ_BASE_TIME option in every reply for this request. The value for the base-time option is the current absolute time in the DHCPv6 server's context.
Active LeasequeryまたはBulk Leasequery要求にOPTION_OROにあるOPTION_LQ_BASE_TIMEオプションコードが含まれている場合、DHCPv6サーバーはこの要求に対するすべての応答にOPTION_LQ_BASE_TIMEオプションを含める必要があります。 base-timeオプションの値は、DHCPv6サーバーのコンテキストでの現在の絶対時間です。
If an Active Leasequery request contains an OPTION_LQ_START_TIME option, it indicates that the requestor would like the DHCPv6 server to send it not only messages that correspond to DHCPv6 binding activity that occurs subsequent to the receipt of the Active Leasequery request, but also messages that correspond to DHCPv6 binding activity that occurred prior to the Active Leasequery request.
Active LeasequeryリクエストにOPTION_LQ_START_TIMEオプションが含まれている場合、これはリクエスタがDHCPv6サーバーに、Active Leasequeryリクエストの受信後に発生するDHCPv6バインディングアクティビティに対応するメッセージだけでなく、 Active Leasequery要求の前に発生したDHCPv6バインディングアクティビティ。
If the OPTION_LQ_END_TIME option appears in an Active Leasequery request, the DHCPv6 server SHOULD send a LEASEQUERY-REPLY message with a DHCPv6 status code of MalformedQuery and terminate the connection.
OPTION_LQ_END_TIMEオプションがアクティブLeasequery要求に含まれている場合、DHCPv6サーバーは、MalformedQueryのDHCPv6ステータスコードを含むLEASEQUERY-REPLYメッセージを送信して、接続を終了する必要があります（SHOULD）。
In order to implement a meaningful response to this query, the DHCPv6 server MAY keep track of the binding activity and associate changes with particular base-time values from the messages. Then, when requested to do so by an Active Leasequery request containing a OPTION_LQ_START_TIME option, the DHCPv6 server can respond with replies for all binding activity occurring on that OPTION_LQ_START_TIME or later times.
このクエリに対して意味のある応答を実装するために、DHCPv6サーバーはバインディングアクティビティを追跡し、メッセージからの特定のベースタイム値に変更を関連付けることができます（MAY）。次に、OPTION_LQ_START_TIMEオプションを含むActive Leasequery要求によって要求されると、DHCPv6サーバーは、そのOPTION_LQ_START_TIME以降に発生したすべてのバインディングアクティビティに対する応答で応答できます。
These replies based on the OPTION_LQ_START_TIME MAY be interleaved with the messages generated due to current binding activity.
OPTION_LQ_START_TIMEに基づくこれらの応答は、現在のバインディングアクティビティが原因で生成されたメッセージとインターリーブされる場合があります。
Once the transmission of the DHCPv6 Leasequery messages associated with the OPTION_LQ_START_TIME option are complete, a LEASEQUERY-DATA message MUST be sent with a DHCPv6 status code value of CatchUpComplete.
OPTION_LQ_START_TIMEオプションに関連付けられたDHCPv6 Leasequeryメッセージの送信が完了したら、LEASEQUERY-DATAメッセージをCatchUpCompleteのDHCPv6ステータスコード値とともに送信する必要があります。
The DHCPv6 server SHOULD, but is not required to, keep track of a limited amount of previous binding activity. The DHCPv6 server MAY choose to only do this in the event that it has received at least one Active Leasequery request in the past, as to do so will almost certainly entail some utilization of resources that would be wasted if there are no Active Leasequery requestors for this DHCPv6 server. The DHCPv6 server SHOULD make the amount of previous binding activity it retains configurable. There is no requirement on the DHCPv6 server to retain this information over a server restart (or even to retain such information at all).
DHCPv6サーバーは、以前のバインディングアクティビティの限られた量を追跡する必要がありますが、必須ではありません。 DHCPv6サーバーは、過去に少なくとも1つのActive Leasequery要求を受信した場合にのみこれを実行することを選択できます。これにより、ほぼ確実に、Active Leasequeryリクエスタが存在しない場合に無駄になるリソースの使用率が増加します。このDHCPv6サーバー。 DHCPv6サーバーは、保持する以前のバインディングアクティビティの量を構成可能にする必要があります（SHOULD）。 DHCPv6サーバーでは、サーバーの再起動後もこの情報を保持する必要はありません（またはそのような情報を保持する必要はありません）。
Unless there is an error or some requirement to cease processing a Active Leasequery request yielding a LEASEQUERY-DONE message, such as a server shutdown, there will be no LEASEQUERY-DONE message at the conclusion of the Active Leasequery processing because that processing will not conclude but will continue until either the requestor or the server closes the connection.
エラーや、サーバーのシャットダウンなどのLEASEQUERY-DONEメッセージを生成するアクティブなLeasequery要求の処理を中止する必要がある場合を除き、処理が完了しないため、アクティブなLeasequery処理の最後にLEASEQUERY-DONEメッセージは表示されません。リクエスタまたはサーバーが接続を閉じるまで続行されます。
Every Active Leasequery request MUST be made on a single TCP connection where there is no other request active at the time the request is made.
すべてのアクティブなLeasequery要求は、要求が行われたときにアクティブな他の要求がない単一のTCP接続で行われる必要があります。
Typically, a requestor of an Active Leasequery would not need to send a second Active Leasequery while the first is still active. However, sending an Active Leasequery and a Bulk Leasequery in parallel would be possible and reasonable. In case of parallel Active and Bulk Leasequeries, the requestor MUST use different TCP connections.
通常、アクティブリースクエリのリクエスタは、最初のアクティブリースクエリがまだアクティブな間に、2番目のアクティブリースクエリを送信する必要はありません。ただし、アクティブリースクエリと一括リースクエリを同時に送信することは可能であり、合理的です。並行アクティブリースと一括リースの場合、リクエスタは異なるTCP接続を使用する必要があります。
This MAY be a feature that is administratively controlled. Servers that are able to process queries in parallel SHOULD offer configuration that limits the number of simultaneous queries permitted from any one requestor, in order to control resource use if there are multiple requestors seeking service.
これは管理上制御される機能であるかもしれません。クエリを並行して処理できるサーバーは、サービスを求めるリクエスタが複数ある場合にリソースの使用を制御するために、1つのリクエスタから許可される同時クエリの数を制限する構成を提供する必要があります。
The server MUST close its end of the TCP connection if it encounters an error sending data on the connection. The server MUST close its end of the TCP connection if it finds that it has to abort an in-process request. A server aborting an in-process request SHOULD attempt to signal that to its requestors by using the QueryTerminated status code in the DHCPv6 status code option in a LEASEQUERY-DONE message. If the server detects that the requestor end has been closed, the server MUST close its end of the connection.
サーバーは、接続でのデータ送信エラーが発生した場合、TCP接続の最後を閉じる必要があります。サーバーは、インプロセス要求を中止する必要があると判断した場合、TCP接続の最後を閉じる必要があります。インプロセスリクエストを中止するサーバーは、LEASEQUERY-DONEメッセージのDHCPv6ステータスコードオプションのQueryTerminatedステータスコードを使用して、そのリクエストをリクエスタに通知する必要があります。サーバーがリクエスターの終わりが閉じられたことを検出した場合、サーバーは接続の終わりを閉じなければなりません（MUST）。
The server SHOULD limit the number of connections it maintains and SHOULD close idle connections to enforce the limit.
サーバーは維持する接続の数を制限する必要があり（SHOULD）、制限を実施するためにアイドル接続を閉じる必要があります（SHOULD）。
The Security Considerations section of [RFC3315] details the general threats to DHCPv6. The DHCPv6 Leasequery specification [RFC5007] describes recommendations for the Leasequery protocol, especially with regard to relayed Leasequery messages, mitigation of packet-flooding denial-of-service (DoS) attacks, restriction to trusted requestors, and use of IPsec [RFC4301].
[RFC3315]のセキュリティに関する考慮事項のセクションでは、DHCPv6に対する一般的な脅威について詳しく説明しています。 DHCPv6 Leasequery仕様[RFC5007]は、特にリレーされたLeasequeryメッセージ、パケットフラッディングサービス拒否（DoS）攻撃の緩和、信頼できるリクエスタへの制限、およびIPsec [RFC4301]の使用に関して、Leasequeryプロトコルの推奨事項を説明しています。
The use of TCP introduces some additional concerns. Attacks that attempt to exhaust the DHCPv6 server's available TCP connection resources can compromise the ability of legitimate requestors to receive service. Malicious requestors who succeed in establishing connections but who then send invalid queries, partial queries, or no queries at all can also exhaust a server's pool of available connections.
TCPの使用は、いくつかの追加の懸念をもたらします。 DHCPv6サーバーの利用可能なTCP接続リソースを使い果たしようとする攻撃は、正当な要求者がサービスを受け取る能力を危険にさらす可能性があります。接続の確立に成功したが、無効なクエリ、部分クエリ、またはまったくクエリを送信しない悪意のある要求者も、サーバーの利用可能な接続のプールを使い果たす可能性があります。
When operating in secure mode, TLS [RFC5246] is used to secure the connection. The recommendations in [RFC7525] SHOULD be followed when negotiating a TLS connection.
セキュアモードで動作している場合、TLS [RFC5246]を使用して接続を保護します。 [RFC7525]の推奨事項は、TLS接続をネゴシエートするときに従う必要があります。
Servers SHOULD offer configuration parameters to limit the sources of incoming connections through validation and use of the digital certificates presented to create a TLS connection. They SHOULD also limit the number of accepted connections and limit the period of time during which an idle connection will be left open.
サーバーは、TLS接続を作成するために提示されたデジタル証明書の検証と使用を通じて、着信接続のソースを制限する構成パラメーターを提供する必要があります（SHOULD）。また、受け入れられる接続の数を制限し、アイドル状態の接続を開いたままにする期間を制限する必要があります（SHOULD）。
The data acquired by using an Active Leasequery is subject to the same potential abuse as the data held by the DHCPv6 server from which it was acquired and SHOULD be secured by mechanisms as strong as those used for the data held by that DHCPv6 server. The data acquired by using an Active Leasequery SHOULD be deleted as soon as possible after the use for which it was acquired has passed.
Active Leasequeryを使用して取得されたデータは、取得元のDHCPv6サーバーが保持するデータと同じ悪用される可能性があり、そのDHCPv6サーバーが保持するデータに使用されるものと同じくらい強力なメカニズムで保護する必要があります。 Active Leasequeryを使用して取得したデータは、取得した使用が経過した後、できるだけ早く削除する必要があります（SHOULD）。
Authentication for DHCP messages [RFC3315] MUST NOT be used to attempt to secure transmission of the messages described in this document.
DHCPメッセージの認証[RFC3315]は、このドキュメントで説明されているメッセージの安全な送信を試みるために使用してはなりません（MUST NOT）。
IANA has assigned new DHCPv6 option codes in the "Option Codes" registry maintained at <http://www.iana.org/assignments/ dhcpv6-parameters>:
IANAは、<http://www.iana.org/assignments/ dhcpv6-parameters>で管理されている「オプションコード」レジストリで新しいDHCPv6オプションコードを割り当てました。
OPTION_LQ_BASE_TIME (100)
OPTION_LQ_BASE_TIME（100）
OPTION_LQ_START_TIME (101)
OPTION_LQ_START_TIME（101）
OPTION_LQ_END_TIME (102)
OPTION_LQ_END_TIME（102）
IANA has assigned new values in the DHCPv6 "Status Codes" registry maintained at <http://www.iana.org/assignments/dhcpv6-parameters>:
IANAは、<http://www.iana.org/assignments/dhcpv6-parameters>で管理されているDHCPv6 "Status Codes"レジストリに新しい値を割り当てました。
DataMissing (12)
データ欠落（12）
CatchUpComplete (13)
キャッチアップコンプリート（13）
NotSupported (14)
サポートされていません（14）
TLSConnectionRefused (15)
TLSConnectionRefused（15）
IANA has assigned values for the following new DHCPv6 message types in the "Message Types" registry maintained at <http://www.iana.org/assignments/dhcpv6-parameters>:
IANAは、<http://www.iana.org/assignments/dhcpv6-parameters>で管理されている「メッセージタイプ」レジストリで、次の新しいDHCPv6メッセージタイプの値を割り当てました。
ACTIVELEASEQUERY (22)
アクティブリースクエリ（22）
STARTTLS (23)
スタートTLS（23）
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、DOI 10.17487 / RFC3633、2003年12月、<http：//www.rfc-editor。 org / info / rfc3633>。
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, September 2007, <http://www.rfc-editor.org/info/rfc5007>.
[RFC5007] Brzozowski、J.、Kinnear、K.、Volz、B。、およびS. Zeng、「DHCPv6 Leasequery」、RFC 5007、DOI 10.17487 / RFC5007、2007年9月、<http：//www.rfc-editor。 org / info / rfc5007>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, DOI 10.17487/RFC5460, February 2009, <http://www.rfc-editor.org/info/rfc5460>.
[RFC5460] Stapp、M。、「DHCPv6 Bulk Leasequery」、RFC 5460、DOI 10.17487 / RFC5460、2009年2月、<http://www.rfc-editor.org/info/rfc5460>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, <http://www.rfc-editor.org/info/rfc7414>.
[RFC7414]デューク、M。、ブレーデン、R。、エディ、W。、ブラントン、E。、およびA.ジマーマン、「A Transmission map for Transmission Control Protocol（TCP）Specification Documents」、RFC 7414、DOI 10.17487 / RFC7414、 2015年2月、<http://www.rfc-editor.org/info/rfc7414>。
Acknowledgments
謝辞
Some of the concepts and content present in this document are based on DHCPv4 Active Leasequery, which was originally proposed by Kim Kinnear, Bernie Volz, Mark Stapp, and Neil Russell.
このドキュメントにある概念と内容の一部は、Kim Kinnear、Bernie Volz、Mark Stapp、およびNeil Russellによって最初に提案されたDHCPv4 Active Leasequeryに基づいています。
Useful review comments were provided by Scott Bradner, Francis Dupont, and Stephen Farrell. The privacy protections were substantially upgraded due to these comments and discussions.
スコットブラドナー、フランシスデュポン、スティーブンファレルから、有益なレビューコメントが寄せられました。これらのコメントと議論により、プライバシー保護は大幅にアップグレードされました。
Authors' Addresses
著者のアドレス
Dushyant Raghuvanshi Cisco Systems, Inc. Cessna Business Park Varthur Hobli, Outer Ring Road Bangalore, Karnataka 560037 India
Dushyant Raghuvanshi Cisco Systems、Inc. Chase's Business Park Worthur Hobali、Outer Ring Road Bangalore、Karnataka ೫೬೦೦೩೭インド
Phone: +91 80 4426-7372
Email: draghuva@cisco.com
Kim Kinnear Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, Massachusetts 01719 United States
Kim Kinnear Cisco Systems、Inc. 1414 Massachusetts Avenue Boxborough、Massachusetts 01719 United States
Phone: +1 978 936-0000
Email: kkinnear@cisco.com
Deepak Kukrety Cisco Systems, Inc. Cessna Business Park Varthur Hobli, Outer Ring Road Bangalore, Karnataka 560037 India
Deepak Kukrety Cisco Systems、Inc. Cessna Business Park Varthur Hobli、Outer Ring Road Bangalore、Karnatakaインド
Phone: +91 80 4426-7346
Email: dkukrety@cisco.com