[要約] RFC 7724は、Active DHCPv4 Lease Queryプロトコルに関する仕様を定めたものであり、DHCPv4サーバーに対してアクティブなリース情報を問い合わせるための手段を提供します。このプロトコルの目的は、ネットワーク管理者がリース情報を効果的に監視し、ネットワークリソースの最適化を図ることです。
Internet Engineering Task Force (IETF) K. Kinnear
Request for Comments: 7724 M. Stapp
Updates: 6926 B. Volz
Category: Standards Track Cisco Systems
ISSN: 2070-1721 N. Russell
Staples
December 2015
Active DHCPv4 Lease Query
アクティブDHCPv4リースクエリ
Abstract
概要
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings (RFC 4388). That mechanism is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient, or even possible. In addition, continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 binding information data via TCP. This document updates RFC 6926, "DHCPv4 Bulk Leasequery".
IPv4の動的ホスト構成プロトコル（DHCPv4）は、要求者がDHCPv4バインディングに関する情報を要求できるようにするLeasequery機能で拡張されました（RFC 4388）。そのメカニズムは、個々のバインディングのクエリに限定されます。状況によっては、個々のバインディングクエリが効率的でなく、場合によっては不可能です。さらに、Leasequeryデータを使用した外部リクエスタの継続的な更新が必要になる場合があります。このドキュメントはDHCPv4 Leasequeryプロトコルを拡張し、TCPを介してほぼリアルタイムのDHCPv4バインディング情報データのアクティブな転送を可能にします。このドキュメントは、RFC 6926「DHCPv4 Bulk Leasequery」を更新します。
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/rfc7724.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7724で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. Interaction Between Active Leasequery and Bulk Leasequery . . 8
5. Message and Option Definitions . . . . . . . . . . . . . . . 9
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 9
5.2. New or Changed Options . . . . . . . . . . . . . . . . . 9
5.2.1. dhcp-message-type . . . . . . . . . . . . . . . . . . 10
5.2.2. dhcp-status-code . . . . . . . . . . . . . . . . . . 10
5.3. Connection and Transmission Parameters . . . . . . . . . 11
6. Information Communicated by Active Leasequery . . . . . . . . 11
7. Requestor Behavior . . . . . . . . . . . . . . . . . . . . . 12
7.1. General Processing . . . . . . . . . . . . . . . . . . . 12
7.2. Initiating a Connection . . . . . . . . . . . . . . . . . 13
7.3. Forming an Active Leasequery . . . . . . . . . . . . . . 14
7.4. Processing Active Replies . . . . . . . . . . . . . . . . 15
7.4.1. Processing Replies from a Request Containing a
query-start-time . . . . . . . . . . . . . . . . . . 17
7.5. Closing Connections . . . . . . . . . . . . . . . . . . . 19
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Accepting Connections . . . . . . . . . . . . . . . . . . 19
8.1.1. Update to RFC 6926 . . . . . . . . . . . . . . . . . 21
8.2. Replying to an Active Leasequery . . . . . . . . . . . . 21
8.3. Multiple or Parallel Queries . . . . . . . . . . . . . . 23
8.4. Closing Connections . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 capability [RFC2131] [RFC2132] to allow an external entity to query a DHCPv4 server to recover lease state information about a particular IPv4 address or client in near real-time.
DHCPv4 Leasequery機能[RFC4388]は、基本的なDHCPv4機能[RFC2131] [RFC2132]を拡張して、外部エンティティがDHCPv4サーバーにクエリを実行し、特定のIPv4アドレスまたはクライアントに関するリース状態情報をほぼリアルタイムで回復できるようにします。
Continuous update of an external requestor with Leasequery data is sometimes desired. These requestors need to keep up with the current binding activity of the DHCPv4 server. Keeping up with these binding activities is termed "active" leasequery.
Leasequeryデータを使用した外部リクエスタの継続的な更新が必要になる場合があります。これらのリクエスターは、DHCPv4サーバーの現在のバインディングアクティビティに対応する必要があります。これらのバインディングアクティビティに追いつくことは、「アクティブな」leasequeryと呼ばれます。
The DHCPv4 Bulk Leasequery [RFC6926] capability can be used to recover useful information from a DHCPv4 server when some external entity starts up. This entity could be one that is directly involved in the DHCPv4 client-server transactions (e.g., a relay agent), or it could be an external process that needs information present in the DHCPv4 server's lease state database.
DHCPv4バルクリースクエリ[RFC6926]機能を使用すると、外部エンティティが起動したときにDHCPv4サーバーから有用な情報を回復できます。このエンティティは、DHCPv4クライアント/サーバートランザクション（リレーエージェントなど）に直接関係するエンティティである場合もあれば、DHCPv4サーバーのリース状態データベースに存在する情報を必要とする外部プロセスである場合もあります。
The Active Leasequery capability documented here is designed to allow an entity not directly involved in DHCPv4 client-server transactions to nevertheless keep current with the state of the DHCPv4 lease state information in real-time.
ここに記載されているアクティブLeasequery機能は、DHCPv4クライアント/サーバートランザクションに直接関与していないエンティティでも、DHCPv4リース状態情報をリアルタイムで最新に保つことができるように設計されています。
This document updates DHCPv4 Bulk Leasequery [RFC6926] in that it specifies the DHCPv4 server must close the TCP connection if it receives a DHCPv4 message that is not allowed over the TCP connection (for example, DHCPDISCOVER, DHCPLEASEQUERY). See Section 8.1.1.
このドキュメントは、DHCPv4 Bulk Leasequery [RFC6926]を更新し、TCP接続で許可されていないDHCPv4メッセージ（DHCPDISCOVER、DHCPLEASEQUERYなど）を受信した場合、DHCPv4サーバーがTCP接続を閉じる必要があることを指定しています。セクション8.1.1を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses the following terms:
このドキュメントでは、次の用語を使用します。
o "Active Leasequery"
o 「アクティブリースクエリ」
Keeping up to date in real-time (or near real-time) with DHCPv4 binding activity.
DHCPv4バインディングアクティビティを使用して、リアルタイム（またはほぼリアルタイム）で最新の状態に保ちます。
o "binding"
o 「製本」
The information that a DHCPv4 server keeps regarding the relationship between a DHCPv4 client and an IPv4 address. This includes the identity of the DHCPv4 client and the expiration time, if any, of any lease that client has on a particular IPv4 address.
DHCPv4サーバーがDHCPv4クライアントとIPv4アドレスの間の関係に関して保持する情報。これには、DHCPv4クライアントのIDと、クライアントが特定のIPv4アドレスに対して持っているリースの有効期限（ある場合）が含まれます。
o "Bulk Leasequery"
o 「一括リースクエリ」
Requesting and receiving the information about all or some of the existing DHCPv4 binding information in an efficient manner, as defined by [RFC6926].
[RFC6926]で定義されているように、既存のDHCPv4バインディング情報のすべてまたは一部に関する情報を効率的な方法で要求および受信する。
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 "catch-up information"
o 「追いつき情報」
If a DHCPv4 Active Leasequery requestor sends in a query-start-time option in a DHCPACTIVELEASEQUERY message, the DHCPv4 server will attempt to send the requestor the information that changed since the time specified in the query-start-time option. The binding information sent to satisfy this request is the catch-up information.
DHCPv4 Active LeasequeryリクエスタがDHCPACTIVELEASEQUERYメッセージのquery-start-timeオプションで送信する場合、DHCPv4サーバーは、query-start-timeオプションで指定された時間以降に変更された情報をリクエスタに送信しようとします。この要求を満たすために送信されるバインディング情報はキャッチアップ情報です。
o "catch-up phase"
o 「キャッチアップフェーズ」
The period while the catch-up information is being sent is the catch-up phase.
キャッチアップ情報が送信されている期間は、キャッチアップフェーズです。
o "clock skew"
o 「クロックスキュー」
The difference between the absolute time on a DHCPv4 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 packet is received by a requestor from a DHCPv4 server, a more accurate value is derived from continuously examining the instantaneous value developed from each packet received from a DHCPv4 server and using it to make small adjustments to the existing value held in the requestor.
DHCPv4サーバーの絶対時間とアクティブまたはバルクリースクエリのリクエスタが実行されているシステムの絶対時間の差は、そのアクティブまたはバルクリースクエリ接続の「クロックスキュー」と呼ばれます。絶対的に一定ではありませんが、ゆっくりと変化する可能性があります。これは、DHCPv4サーバーからリクエスタが1つのパケットを受信した後に正確に計算できると考えるのは簡単ですが、より正確な値は、DHCPv4サーバーから受信した各パケットから生成された瞬時値を継続的に調べ、それを使用してリクエスタに保持されている既存の値を少し調整します。
o "DHCPv4 client"
o 「DHCPv4クライアント」
A DHCPv4 client is an IPv4 node using DHCP to obtain configuration parameters such as a network address.
DHCPv4クライアントは、DHCPを使用してネットワークアドレスなどの構成パラメーターを取得するIPv4ノードです。
o "DHCPv4 relay agent"
o 「DHCPv4リレーエージェント」
A DHCPv4 relay agent is a third-party agent that transfers BOOTP and DHCPv4 messages between clients and servers residing on different subnets, per [RFC951] and [RFC1542].
DHCPv4リレーエージェントは、[RFC951]および[RFC1542]に従って、異なるサブネット上にあるクライアントとサーバー間でBOOTPおよびDHCPv4メッセージを転送するサードパーティエージェントです。
o "DHCPv4 server"
o 「DHCPv4サーバー」
A DHCPv4 server is an IPv4 node that returns configuration parameters to DHCPv4 clients.
DHCPv4サーバーは、構成パラメーターをDHCPv4クライアントに返すIPv4ノードです。
o "insecure mode"
o 「安全でないモード」
When operating in insecure mode, the TCP connection between the requestor and DHCPv4 server is not protected in any way. In addition, the identity of the requestor is not validated by the server nor is the identity of the server validated by the requestor.
安全でないモードで動作している場合、リクエスタとDHCPv4サーバー間のTCP接続はいかなる方法でも保護されません。さらに、リクエスターのIDはサーバーによって検証されず、サーバーのIDもリクエスターによって検証されません。
o "MAC address"
o "Macアドレス"
In the context of a DHCP message, a Media Access Control (MAC) address consists of the fields: hardware type "htype", hardware length "hlen", and client hardware address "chaddr".
DHCPメッセージのコンテキストでは、メディアアクセスコントロール（MAC）アドレスは、ハードウェアタイプ「htype」、ハードウェア長「hlen」、およびクライアントハードウェアアドレス「chaddr」のフィールドで構成されます。
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 "secure mode"
o 「セキュアモード」
When operating in secure mode, the TCP connection between the requestor and the DHCPv4 server is protected by TLS [RFC5246]. In addition, the requestor uses the certificates exchanged between it and the DHCPv4 server while setting up the TLS connection to validate the identity of the server. The DHCPv4 server also uses these certificates to validate the identity of the requestor.
セキュアモードで動作している場合、リクエスタとDHCPv4サーバー間のTCP接続はTLS [RFC5246]によって保護されます。さらに、リクエスターは、サーバーのIDを検証するためにTLS接続をセットアップするときに、リクエスターとDHCPv4サーバーの間で交換される証明書を使用します。 DHCPv4サーバーは、これらの証明書を使用して要求者のIDを検証します。
The Active Leasequery mechanism is modeled on the existing individual Leasequery protocol in [RFC4388] as well as related work on DHCPv4 Bulk Leasequery [RFC6926]; most differences arise from the long-term nature of the TCP [RFC7414] connection required for Active Leasequery. In addition, a DHCPv4 server that supports Active Leasequery must support Bulk Leasequery [RFC6926] as well. See Section 8.
Active Leasequeryメカニズムは、[RFC4388]の既存の個々のLeasequeryプロトコルと、DHCPv4 Bulk Leasequery [RFC6926]に関する関連作業をモデルにしています。ほとんどの違いは、Active Leasequeryに必要なTCP [RFC7414]接続の長期的な性質から生じます。さらに、Active LeasequeryをサポートするDHCPv4サーバーは、Bulk Leasequery [RFC6926]もサポートする必要があります。セクション8を参照してください。
An Active Leasequery requestor opens a TCP connection to a DHCPv4 Server, using the DHCPv4 port 67. Note that this implies that the Leasequery requestor has the server IPv4 address(es) available via configuration or some other means, and that it has unicast IP reachability to the DHCPv4 server. The message framing for TCP is discussed in Section 5.1. No relaying for Active Leasequery is specified.
アクティブLeasequeryリクエスターは、DHCPv4ポート67を使用して、DHCPv4サーバーへのTCP接続を開きます。これは、LeasequeryリクエスターがサーバーのIPv4アドレスを構成またはその他の手段で使用できること、およびユニキャストIP到達可能性があることを意味しますDHCPv4サーバーへ。 TCPのメッセージフレーミングについては、セクション5.1で説明します。 Active Leasequeryのリレーは指定されていません。
After establishing a connection, the requestor sends an DHCPACTIVELEASEQUERY message over the connection. In response, the server sends updates to the requestor using DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages that are extensions of these messages as defined in [RFC4388] and [RFC6926]. This response procedure is similar to the procedure specified in [RFC6926], 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 the long-lived connection. Additionally, the Active Leasequery server should provide a mechanism to control which data is allowed to be included in the messages sent to the requestor. See Section 8.2.
接続を確立した後、リクエスタは接続を介してDHCPACTIVELEASEQUERYメッセージを送信します。応答として、サーバーは、[RFC4388]および[RFC6926]で定義されているこれらのメッセージの拡張であるDHCPLEASEACTIVEおよびDHCPLEASEUNASSIGNEDメッセージを使用して、リクエスタに更新を送信します。この応答手順は、[RFC6926]で指定されている手順と似ていますが、アクティブリースクエリの場合、バインディング状態を変更するアクティビティが発生するたびにサーバーが更新を送信するため、長期間の接続が必要です。さらに、Active Leasequeryサーバーは、リクエスタに送信されるメッセージにどのデータを含めることができるかを制御するメカニズムを提供する必要があります。セクション8.2を参照してください。
Since [RFC6926] did not specify what to do with an unknown message type received over the DHCP TCP connection, system administrators SHOULD NOT allow a DHCPACTIVELEASEQUERY message to be sent over a DHCP TCP connection to a DHCPv4 server that does not support Active Leasequery.
[RFC6926]はDHCP TCP接続経由で受信した不明なメッセージタイプをどうするかを指定しなかったため、システム管理者は、DHCPACTIVELEASEQUERYメッセージをDHCP TCP接続経由でActive LeasequeryをサポートしないDHCPv4サーバーに送信することを許可すべきではありません。
Active Leasequery is designed to provide continuous updates of DHCPv4 binding activity to an external entity.
アクティブLeasequeryは、外部エンティティにDHCPv4バインディングアクティビティの継続的な更新を提供するように設計されています。
Active Leasequery has features that allow this external entity to lose its connection and then reconnect and receive the latest information concerning any IPv4 bindings changed while it was not connected.
アクティブLeasequeryには、この外部エンティティが接続を失い、再接続して、接続されていない間に変更されたIPv4バインディングに関する最新情報を受信できる機能があります。
These capabilities 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 DHCPv4 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 DHCPv4 server from which it is receiving updates and then becomes reconnected to that server.
これらの機能は、アクティブLeasequeryリクエスタが再起動された後、またはそれが実行されているマシンが再初期化された後に、リース状態データベースに関して効率的に最新になるように設計されています。リクエスタが常にDHCPv4サーバーに接続されている場合に機能するプロトコルを定義するのは簡単です。これは十分に堅牢ではないため、このドキュメントのメカニズムの多くは、アクティブリースクエリリクエスタが更新を受信しているDHCPv4サーバーから切断され、そのサーバーに再接続されたときに発生する状況を効率的に処理するように設計されています。
Central to this approach is the concept that, 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 DHCPv4 server will determine whether or not data was missed while the Active Leasequery requestor was not connected.
このアプローチの中心となるのは、アクティブリースクエリリクエスタがサービスを失った場合、後続のアクティブリースクエリリクエストで最新の更新の時間を指定できるため、DHCPv4サーバーが、アクティブなLeasequeryリクエスタは接続されていません。
The DHCP server processing the Active Leasequery request MAY limit the amount of data saved, and methods exist for the DHCPv4 server to inform the Active Leasequery requestor that more data was missed than could be saved. In this situation, the Active Leasequery requestor would issue a Bulk Leasequery [RFC6926] to recover information not available through an Active Leasequery.
Active Leasequery要求を処理するDHCPサーバーは、保存されるデータの量を制限する場合があり、DHCPv4サーバーがActive Leasequeryリクエスターに保存できるデータよりも多くのデータが失われたことを通知するメソッドが存在します。この状況では、アクティブリースクエリリクエスタは、バルクリースクエリ[RFC6926]を発行して、アクティブリースクエリでは利用できない情報を回復します。
DHCPv4 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 DHCPv4 Active Leasequery requestor whose connection was temporarily interrupted.
DHCPv4サーバーは、Active Leasequery接続で失われたデータに対応するデータを保持する必要はありませんが、通常、接続が一時的に中断されたDHCPv4 Active Leasequeryリクエスターによる後続のクエリで利用できる最近のアクティビティに対応するデータを保持することを選択します。
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 DHCPv4 server was lost for a longer time than the DHCPv4 server would keep track of the specific changes to the IPv4 binding information.
アクティブなLeasequeryリクエスタは通常、データベースにバインディング情報が含まれていない場合、Bulk Leasequeryを使用してデータベースを現在のすべてのデータで初期化します。さらに、DHCPv4サーバーとの接続がIPv4バインディング情報への特定の変更を追跡し続けるよりも長い間DHCPv4サーバーとの接続が失われた場合、失われた情報を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 time, clock skew, data source, and other items discussed in the Bulk Leasequery specification [RFC6926] 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 response to the requestor even if they were requested by inclusion in the dhcp-parameter-request-list option.
Active Leasequeryリクエストへの応答としてサーバーが送信するメッセージは、データがActive Leasequeryレスポンスにエンコードされる方法に関して、サーバーがBulk Leasequeryリクエストに送信するメッセージと同じである必要があります。さらに、アクティブリースクエリリクエスタがアクティブリースクエリリクエストへの応答を解釈するために実行するアクションは、リクエスタがバルクリースクエリリクエストへの応答を解釈する方法と同じでなければなりません。したがって、時間、クロックスキュー、データソース、およびバルクリースクエリ仕様[RFC6926]で説明されているその他の項目の処理は、アクティブリースクエリを実装する際に従う必要があります。ただし、アクティブリースクエリリクエストに応答するサーバーは、特定のデータ項目がdhcp-parameter-request-listオプションに含めることによって要求された場合でも、リクエスターへの応答に含まれないように構成します。
Active Leasequery is an extension of the Bulk Leasequery protocol [RFC6926]. The contents of messages returned to an Active Leasequery requestor are identical to those defined for the Bulk Leasequery protocol.
Active Leasequeryは、Bulk Leasequeryプロトコル[RFC6926]の拡張です。 Active Leasequeryリクエスタに返されるメッセージの内容は、Bulk Leasequeryプロトコルに対して定義されたものと同じです。
Applications that employ Active Leasequery to keep a database up to date with respect to the DHCPv4 server's lease state database should use an initial Bulk Leasequery to bring their database into equivalence with that of the DHCPv4 server, and then use Active Leasequery to keep that database current with respect to the DHCPv4 server's lease state database.
DHCPv4サーバーのリース状態データベースに関してデータベースを最新の状態に保つためにアクティブリースクエリを使用するアプリケーションは、初期のバルクリースクエリを使用してデータベースをDHCPv4サーバーと同等にしてから、アクティブリースクエリを使用してそのデータベースを最新に保つ必要があります。 DHCPv4サーバーのリース状態データベースに関して。
There are several differences between the Active and Bulk Leasequery protocols. Active Leasequery defines only one qualifier (the query-start-time) and no query types, while Bulk Leasequery defines several query types and qualifiers. An Active Leasequery connection sends all available updates to the requestor.
アクティブとバルクリースクエリプロトコルの間にはいくつかの違いがあります。 Active Leasequeryは1つの修飾子（query-start-time）のみを定義し、クエリタイプは定義しませんが、Bulk Leasequeryはいくつかのクエリタイプと修飾子を定義します。アクティブなLeasequery接続は、利用可能なすべての更新をリクエスタに送信します。
An Active Leasequery connection does not ever "complete", though the DHCPv4 server can close the connection for a variety of reasons associated with some sort of exception condition.
DHCPv4サーバーは、ある種の例外条件に関連するさまざまな理由で接続を閉じることができますが、アクティブなLeasequery接続は決して「完了」しません。
The use of TCP for the Active Leasequery protocol permits one or more DHCPv4 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 framing technique used for Bulk Leasequery [RFC6926] is used for Active Leasequery.
Active LeasequeryプロトコルにTCPを使用すると、1つのActive Leasequery要求に応答して1つ以上のDHCPv4メッセージを送信できます。受信者は、各メッセージの大きさを判別できる必要があります。 Bulk Leasequery [RFC6926]で使用されているのと同じフレーミング技術がActive Leasequeryでも使用されます。
When using TLS to secure a connection [RFC5246], the message framing for TLS uses the same format as that used for TCP. One DHCP message is carried in one TLS record.
TLSを使用して接続を保護する場合[RFC5246]、TLSのメッセージフレーミングは、TCPに使用されるものと同じフォーマットを使用します。 1つのDHCPメッセージが1つのTLSレコードで運ばれます。
The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are used as the value of the dhcp-message-type option to indicate an IPv4 address that is currently not leased or is currently leased to a DHCPv4 client, respectively.
既存のメッセージDHCPLEASEUNASSIGNEDとDHCPLEASEACTIVEは、dhcp-message-typeオプションの値として使用され、現在リースされていない、またはDHCPv4クライアントに現在リースされているIPv4アドレスをそれぞれ示します。
All of the message types and options defined for Bulk Leasequery [RFC6926] are also used by Active Leasequery. In addition, new message types and option types are defined for Active Leasequery, as described below.
Bulk Leasequery [RFC6926]に定義されているすべてのメッセージタイプとオプションは、Active Leasequeryでも使用されます。さらに、以下で説明するように、新しいメッセージタイプとオプションタイプがActive Leasequeryに対して定義されています。
The message type option (option 53) from [RFC2132] requires additional values. The values of these message types are shown below in an extension of the table from Section 9.6 of [RFC2132]:
[RFC2132]のメッセージタイプオプション（オプション53）には、追加の値が必要です。これらのメッセージタイプの値を、[RFC2132]のセクション9.6の表の拡張部分に以下に示します。
+-------+----------------------+
| Value | Message Type |
+-------+----------------------+
| 16 | DHCPACTIVELEASEQUERY |
| 17 | DHCPLEASEQUERYSTATUS |
| 18 | DHCPTLS |
+-------+----------------------+
The dhcp-status-code option defined in [RFC6926] allows greater detail to be returned regarding the status of a DHCP request. While specified in the Bulk Leasequery document, this DHCPv4 option is also used in Active Leasequery.
[RFC6926]で定義されているdhcp-status-codeオプションを使用すると、DHCP要求のステータスに関する詳細を返すことができます。 Bulk Leasequeryドキュメントで指定されていますが、このDHCPv4オプションはActive Leasequeryでも使用されます。
This option has two possible scopes when used with Active Leasequery, depending on the context in which it appears. It refers to the information in a single leasequery reply if the value of the dhcp-message-type is DHCPLEASEACTIVE, DHCPLEASEUNASSIGNED, or DHCPTLS. It refers to the message stream related to an entire request if the value of the dhcp-message-type is DHCPLEASEQUERYSTATUS.
このオプションは、それが表示されるコンテキストに応じて、Active Leasequeryで使用される場合、2つの可能なスコープを持ちます。 dhcp-message-typeの値がDHCPLEASEACTIVE、DHCPLEASEUNASSIGNED、またはDHCPTLSの場合、単一のleasequery応答の情報を参照します。 dhcp-message-typeの値がDHCPLEASEQUERYSTATUSの場合、リクエスト全体に関連するメッセージストリームを参照します。
Additional status codes defined for support of Active Leasequery are:
Active Leasequeryのサポート用に定義されている追加のステータスコードは次のとおりです。
+----------------------+-------------+------------------------------+
| Name | Status-Code | Description |
+----------------------+-------------+------------------------------+
| DataMissing | 5 | Indicates that IPv4 binding |
| | | information requested is not |
| | | available. |
| ConnectionActive | 6 | Indicates that this |
| | | connection remains active. |
| CatchUpComplete | 7 | Indicates that this Active |
| | | Leasequery connection has |
| | | completed sending all of the |
| | | saved data requested. |
| TLSConnectionRefused | 8 | Indicates that a TLS |
| | | connection is not allowed. |
+----------------------+-------------+------------------------------+
A dhcp-status-code option MAY appear in the options field of a DHCP
message. If the dhcp-status-code option does not appear, it is
assumed that the operation was successful. The dhcp-status-code
option SHOULD NOT appear in a message that is successful unless it is
needed to convey some text message along with the Success status
code.
Active Leasequery uses the same port configuration as DHCPv4 Bulk Leasequery [RFC6926]. It also uses other transmission parameters (BULK_LQ_DATA_TIMEOUT and BULK_LQ_MAX_CONNS) as defined in [RFC6926].
Active LeasequeryはDHCPv4 Bulk Leasequery [RFC6926]と同じポート構成を使用します。また、[RFC6926]で定義されている他の送信パラメータ（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 as well as 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 s | Active Leasequery receive |
| | | timeout |
| ACTIVE_LQ_SEND_TIMEOUT | 120 s | Active Leasequery send |
| | | timeout |
| ACTIVE_LQ_IDLE_TIMEOUT | 60 s | Active Leasequery idle |
| | | timeout |
+------------------------+---------+-------------------------------+
While the information communicated by a Bulk Leasequery [RFC6926] is taken directly from the DHCPv4 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 DHCPv4 server's lease state database.
一括リースクエリ[RFC6926]によって通信される情報はDHCPv4サーバーのリース状態データベースから直接取得されますが、アクティブリースクエリによって通信される情報はリアルタイムの情報です。したがって、DHCPv4サーバーのリース状態データベースの特定のバインディングに現在関連付けられているのはこの情報です。
This is of significance, because if the Active Leasequery requestor runs slowly or the requestor disconnects from the DHCPv4 server and then reconnects with a query-start-time (signaling a catch-up operation), the information communicated to the Active Leasequery requestor is only the most current information from the DHCPv4 server's lease state database.
これは重要です。アクティブリースクエリリクエスタの実行速度が遅い場合、またはリクエスタがDHCPv4サーバーから切断してからクエリ開始時間（キャッチアップ操作を通知）で再接続する場合、アクティブリースクエリリクエスタに送信される情報はDHCPv4サーバーのリース状態データベースからの最新情報。
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 DHCPv4 server is only required to transmit information about a binding that is current when the packet is created and handed off to the TCP stack to send to the requestor.
アクティブリースクエリのリクエスタは、すべてのリース状態の変更がアクティブリースクエリ接続を介して通信されると想定してはなりません（MUST NOT）。 Active Leasequeryリクエスターが接続されたままであっても、DHCPv4サーバーは、パケットが作成され、リクエスターに送信するためにTCPスタックにハンドオフされるときに現在のバインディングに関する情報を送信することだけが必要です。
If the TCP connection blocks and the DHCPv4 server is waiting to send information down the connection, when the connection becomes available to be written, the DHCPv4 server MAY create the packet 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接続がブロックし、DHCPv4サーバーが接続を介して情報を送信するのを待機している場合、接続が書き込み可能になると、DHCPv4サーバーはこの時点で送信するパケットを作成できます（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 DHCPv4 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 never miss any changes in the binding.
したがって、アクティブリースクエリプロトコルでは、リクエスタがすべてのリースのすべてのアクティビティの完全な履歴を作成することはできません。 DHCPv4サーバーのパラメーターがActive Leasequeryリクエスターの要件を考慮するように調整されている場合、リースの重要な状態変化の効果的な履歴を作成できます。たとえば、バインディングの有効期限または解放後の期間を十分に長く（たとえば、受信タイムアウトよりも数分長く）構成できるため、アクティブなLeasequeryリクエスタがバインディングの変更を見逃すことはありません。
A requestor attempts to establish a TCP connection to a DHCPv4 server in order to initiate a 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 5.3.
リクエスタは、リースクエリの交換を開始するために、DHCPv4サーバーへのTCP接続を確立しようとします。試行が失敗した場合、リクエスタは再試行してもよい（MAY）。再試行の頻度は、ACTIVE_LQ_IDLE_TIMEOUTごとに1回より多くすべきではありません。セクション5.3を参照してください。
If an Active Leasequery is terminated prematurely by a DHCPLEASEQUERYDONE with a dhcp-message status-code 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 5.3.
Active LeasequeryがQueryTerminatedのdhcp-message status-codeを持つDHCPLEASEQUERYDONEによって、またはそれが送信された接続の失敗によって途中で終了した場合、リクエスターは新しい接続の作成後に要求を再試行してもよい（MAY）。再試行の頻度は、ACTIVE_LQ_IDLE_TIMEOUTごとに1回より多くすべきではありません。セクション5.3を参照してください。
Messages from the DHCPv4 server come as multiple responses to a single DHCPACTIVELEASEQUERY message. Thus, each DHCPACTIVELEASEQUERY or DHCPBULKLEASEQUERY request must have an xid (transaction-id) unique on the connection on which it is sent (see Section 7.3), and all of the messages that come as a response to it contain the same xid as the request.
DHCPv4サーバーからのメッセージは、単一のDHCPACTIVELEASEQUERYメッセージに対する複数の応答として送信されます。したがって、各DHCPACTIVELEASEQUERYまたはDHCPBULKLEASEQUERY要求には、それが送信される接続で一意のxid（transaction-id）が必要であり（セクション7.3を参照）、それに応答するすべてのメッセージには、要求と同じxidが含まれます。 。
Only one DHCPACTIVELEASEQUERY is allowed on any one TCP connection at a time. Parallel DHCPACTIVELEASEQUERY requests on the same TCP connection are not allowed.
一度に1つのTCP接続で許可されるDHCPACTIVELEASEQUERYは1つだけです。同じTCP接続での並列DHCPACTIVELEASEQUERY要求は許可されません。
A requestor SHOULD be able to operate in either insecure or secure mode. See Section 9. This MAY be a feature that is administratively controlled.
リクエスタは、非セキュアモードまたはセキュアモードのいずれかで動作できる必要があります（SHOULD）。セクション9を参照してください。これは、管理上制御される機能である場合があります。
When operating in insecure mode, the requestor sends a DHCPACTIVELEASEQUERY request after the establishment of a TCP connection.
安全でないモードで動作している場合、リクエスタはTCP接続の確立後にDHCPACTIVELEASEQUERY要求を送信します。
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] apply when negotiating this connection.
セキュアモードで動作している場合、リクエスタはTCP接続を介してTLS [RFC5246]接続のネゴシエートを試行する必要があります。このネゴシエーションが失敗した場合、リクエスタはTCP接続を閉じる必要があります。 [RFC7525]の推奨事項は、この接続をネゴシエートするときに適用されます。
A requestor requests the establishment of a TLS connection by sending the DHCPTLS message to the DHCPv4 server as the first message over the TCP connection. The DHCPTLS message SHOULD be sent without any options. This message indicates to the DHCPv4 server that a TLS connection over this TCP connection is desired. There are four possibilities after the requestor sends the DHCPTLS message to the DHCPV4 server:
リクエスタは、TCP接続上の最初のメッセージとしてDHCPv4サーバーにDHCPTLSメッセージを送信することにより、TLS接続の確立を要求します。 DHCPTLSメッセージは、オプションなしで送信する必要があります（SHOULD）。このメッセージは、このTCP接続を介したTLS接続が必要であることをDHCPv4サーバーに示します。リクエスタがDHCPTLSメッセージをDHCPV4サーバーに送信した後、4つの可能性があります。
1. No response from the DHCPv4 server.
1. DHCPv4サーバーからの応答がありません。
2. The DHCPv4 server closes the TCP connection after it receives the DHCPTLS message.
2. DHCPv4サーバーは、DHCPTLSメッセージを受信した後、TCP接続を閉じます。
3. DHCPv4 server responds with a DHCPTLS message with a dhcp-status-code of TLSConnectionRefused.
3. DHCPv4サーバーは、TLSConnectionRefusedのdhcp-status-codeを含むDHCPTLSメッセージで応答します。
4. DHCPv4 server responds with DHCPTLS message with no dhcp-status-code, indicating success.
4. DHCPv4サーバーは、成功を示すdhcp-status-codeのないDHCPTLSメッセージで応答します。
In any of the first three possibilities, the DHCPv4 server can be assumed to not support TLS. In this case, the requestor MUST close the connection.
最初の3つの可能性のいずれかで、DHCPv4サーバーはTLSをサポートしていないと想定できます。この場合、リクエスタは接続を閉じる必要があります。
In the final possibility, where the DHCPv4 server has responded with a DHCPTLS message with no dhcp-status-code in response to the requestor's DHCPTLS message, the requestor SHOULD initiate the exchange of the messages involved in a TLS handshake [RFC5246].
DHCPv4サーバーがリクエスターのDHCPTLSメッセージに応答してdhcp-status-codeのないDHCPTLSメッセージで応答した最後の可能性では、リクエスターはTLSハンドシェイク[RFC5246]に含まれるメッセージの交換を開始する必要があります。
During the TLS handshake, the requestor MUST validate the DHCPv4 server's digital certificates.
TLSハンドシェイクの間、リクエスタはDHCPv4サーバーのデジタル証明書を検証する必要があります。
If the handshake exchange yields a functioning TLS connection, then the requestor SHOULD transmit a DHCPACTIVELEASEQUERY message over that TLS connection and use that TLS connection for all further interactions in which it engages with the DHCPv4 server over this TCP connection.
ハンドシェイク交換が機能するTLS接続を生成する場合、リクエスタは、そのTLS接続を介してDHCPACTIVELEASEQUERYメッセージを送信し、このTLS接続を、このTCP接続を介してDHCPv4サーバーと通信するすべてのさらなる対話に使用する必要があります。
If the handshake exchange does not yield a functioning TLS connection, then the requestor MUST close the TCP connection.
ハンドシェイク交換が機能するTLS接続を生成しない場合、リクエスタはTCP接続を閉じる必要があります。
The Active Leasequery is designed to create a long-lived connection between the requestor and the DHCPv4 server processing the active query. The DHCPv4 server SHOULD send binding information back across this connection with minimal delay after it learns of the binding information. It will learn about the bindings either because it makes the bindings itself or because it has received information about a binding from another server.
アクティブリースクエリは、リクエスタとアクティブクエリを処理しているDHCPv4サーバーとの間に長期間の接続を作成するように設計されています。 DHCPv4サーバーは、バインディング情報を学習した後、最小限の遅延でこの接続を通じてバインディング情報を送信する必要があります（SHOULD）。バインディング自体を作成するか、別のサーバーからバインディングに関する情報を受け取ったため、バインディングについて学習します。
An Active Leasequery is a DHCPv4 request with a dhcp-message-type of DHCPACTIVELEASEQUERY. The DHCPv4 request MUST NOT have a ciaddr, a chaddr, or a dhcp-client-identifier. The DHCPv4 request MUST have an xid (transaction-id) unique on the connection on which it is sent. The DHCPv4 request SHOULD have a dhcp-parameter-request-list to inform the DHCPv4 server which DHCPv4 options are of interest to the requestor sending the DHCPACTIVELEASEQUERY message.
Active Leasequeryは、dhcp-message-typeがDHCPACTIVELEASEQUERYのDHCPv4要求です。 DHCPv4要求には、ciaddr、chaddr、またはdhcp-client-identifierを含めることはできません。 DHCPv4要求には、それが送信される接続で一意のxid（transaction-id）が必要です。 DHCPv4要求には、DHCPACTIVELEASEQUERYメッセージを送信するリクエスタにとってどのDHCPv4オプションが重要であるかをDHCPv4サーバーに通知するためのdhcp-parameter-request-listが必要です（SHOULD）。
An important capability of the Active Leasequery is that the requestor can 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 DHCPv4 server processing a previous Active Leasequery.
Active Leasequeryの重要な機能は、進行中のバインディング情報の送信と並行して、リアルタイムでリクエスタに最近のデータをすぐに送信するようにリクエスタが指定できることです。この機能は、アクティブリースクエリリクエスタが以前のアクティブリースクエリを処理しているDHCPv4サーバーとの接続を一時的に失った場合に、失われた情報を回復できるようにするために使用されます。
This capability is enabled by the transmission of a 4-octet 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 DHCPv4 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 DHCPv4 server, the requestor should place this highest base-time value into a query-start-time option in the new DHCPACTIVELEASEQUERY request. (See Sections 6.2.5 and 7.2 of [RFC6926] for information on the query-start-time option.)
この機能は、以前のアクティブLeasequeryの結果として送信された各Leasequery応答で4オクテットのベースタイムオプションを送信することで有効になります。リクエスタは、アクティブLeasequery接続を介して特定のDHCPv4サーバーから受信した最も高い基本時刻を追跡する必要があり、リクエスタがそのDHCPv4サーバーへのアクティブLeasequery接続を再確立する必要がある場合（何らかの理由で）、リクエスタは、この最も高いベースタイム値を新しいDHCPACTIVELEASEQUERYリクエストのquery-start-timeオプションに配置する必要があります。 （query-start-timeオプションの詳細については、[RFC6926]のセクション6.2.5および7.2を参照してください。）
Note that until all of the recent data (catch-up data) has been received, the requestor MUST NOT keep track of the base-time received in Leasequery reply messages to use later in a subsequent Bulk Leasequery or Active Leasequery request.
すべての最近のデータ（キャッチアップデータ）が受信されるまで、リクエスターは、後続のバルクリースクエリまたはアクティブリースクエリリクエストで後で使用するために、リースクエリ応答メッセージで受信した基本時間を追跡してはなりません。
If the requestor doesn't wish to request an update of information missed when it was not connected to the DHCPv4 server, then it does not include the query-start-time option in the DHCPACTIVELEASEQUERY request.
リクエスタがDHCPv4サーバーに接続されていないときに失われた情報の更新を要求したくない場合は、DHCPACTIVELEASEQUERY要求にquery-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 DHCPv4 leasequery reply message from the TCP connection.
リクエスタは、TCP接続からDHCPv4 leasequery応答メッセージを読み取ろうとします。
Note that the connection resulting from accepting a DHCPACTIVELEASEQUERY request may be long-lived and may not have data transferring continuously during its lifetime. Therefore, the DHCPv4 server SHOULD send a DHCPLEASEQUERYSTATUS message with a dhcp-status-code of ConnectionActive 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 the connection is idle (i.e., the server has no binding data to send). During normal binding data exchange, receiving DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED messages by the requestor itself signifies that the 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 DHCPv4 server to send messages. Thus, ACTIVE_LQ_RCV_TIMEOUT controls how sensitive the requestor is to be to delays by the DHCPv4 server in sending updates or DHCPLEASEQUERYSTATUS messages.
DHCPACTIVELEASEQUERY要求を受け入れた結果の接続は、存続期間が長い可能性があり、その存続期間中にデータが継続的に転送されない可能性があることに注意してください。したがって、リクエスターが接続が存続していることを知るために、DHCPv4サーバーはDHCPLEASEQUERYSTATUSメッセージをConnectionActiveのdhcp-status-codeとともにACTIVE_LQ_IDLE_TIMEOUT秒（デフォルトは60）ごとに送信する必要があります（SHOULD）。このアプローチは、接続がアイドル状態の場合にのみ実行されます（つまり、サーバーに送信するバインディングデータがありません）。通常のバインディングデータ交換中に、リクエスタ自体がDHCPLEASEACTIVEまたはDHCPLEASEUNASSIGNEDメッセージを受信すると、接続がアクティブであることを示します。 ACTIVE_LQ_RCV_TIMEOUTのデフォルトは120秒であり、ACTIVE_LQ_IDLE_TIMEOUTのデフォルトの60秒の値の2倍であることに注意してください。これにより、DHCPv4サーバーがメッセージを送信します。したがって、ACTIVE_LQ_RCV_TIMEOUTは、リクエスタが更新またはDHCPLEASEQUERYSTATUSメッセージを送信する際にDHCPv4サーバーによる遅延に対してどの程度敏感であるかを制御します。
If the stream of replies becomes blocked with no messages being received, the Requestor SHOULD terminate the connection after ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured to do so.
メッセージが受信されずに応答のストリームがブロックされた場合、リクエスターは、ACTIVE_LQ_RCV_TIMEOUTの後で接続を終了する必要があり（SHOULD）、そのように構成されている場合は再試行処理を開始できます（MAY）。
A successful query that is returning binding data MUST include a non-zero ciaddr. It may also include a non-zero chaddr, htype, and hlen as well as additional options. If there are additional bindings to be returned, they will be carried in additional Active Leasequery messages.
バインディングデータを返す成功したクエリには、ゼロ以外のciaddrを含める必要があります。また、ゼロ以外のchaddr、htype、およびhlenと、追加のオプションが含まれる場合もあります。返される追加のバインディングがある場合、それらは追加のActive Leasequeryメッセージで送信されます。
Any requestor of an Active Leasequery operation MUST be prepared to receive multiple copies of the binding information for a particular IPv4 address. See the Bulk Leasequery document [RFC6926] for information on how to deal with this situation.
Active Leasequery操作のリクエスタは、特定のIPv4アドレスのバインディング情報の複数のコピーを受信できるように準備する必要があります。この状況に対処する方法については、Bulk Leasequeryドキュメント[RFC6926]を参照してください。
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 DHCPACTIVELEASEQUERY message from a single DHCPv4 server.
1つのActive Leasequeryは、通常、多数の応答を返す可能性があります。リクエスタは、単一のDHCPv4サーバーからの単一のDHCPACTIVELEASEQUERYメッセージに一致するトランザクションIDを含む複数の応答を受信できるように準備する必要があります。
A DHCPACTIVELEASEQUERY has two regimes -- during the catch-up phase, if any, and after any catch-up phase. If the DHCPACTIVELASEQUERY request had a query-start-time, then the DHCPACTIVELEASEQUERY starts out in the catch-up phase. See Section 7.4.1 for information on processing during the catch-up phase, as well as how to determine when the catch-up phase is complete.
DHCPACTIVELEASEQUERYには、キャッチアップフェーズ（存在する場合）中とキャッチアップフェーズ後の2つのレジームがあります。 DHCPACTIVELASEQUERY要求にquery-start-timeがあった場合、DHCPACTIVELEASEQUERYはキャッチアップフェーズで開始されます。キャッチアップフェーズの処理に関する情報と、キャッチアップフェーズがいつ完了したかを判断する方法については、セクション7.4.1を参照してください。
After the catch-up phase, or during the entire series of messages received as the response to a DHCPACTIVELEASEQUERY request with no query-start-time (and therefore no catch-up phase), the 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 DHCPv4 server) can be used in a subsequent DHCPACTIVELEASEQUERY message's query-start-time or in a DHCPBULKLEASEQUERY message's query-start-time, if one is required, after a loss of the Active Leasequery connection.
キャッチアップフェーズの後、またはクエリ開始時刻なしで（したがって、キャッチアップフェーズなしで）DHCPACTIVELEASEQUERY要求への応答として受信された一連のメッセージ全体の中で、最新のメッセージのベースタイムオプションは、SHOULDデータが受信された最新の時間の記録として保存されます。この基本時間（DHCPv4サーバーのコンテキストで）は、アクティブなLeasequery接続が失われた後、後続のDHCPACTIVELEASEQUERYメッセージのquery-start-time、または必要に応じてDHCPBULKLEASEQUERYメッセージのquery-start-timeで使用できます。 。
The DHCPLEASEQUERYSTATUS message MAY unilaterally terminate a successful DHCPACTIVELEASEQUERY request that is currently in progress in the event that the DHCPv4 server determines that it cannot continue processing a DHCPACTIVELEASEQUERY request. For example, when a server is requested to shut down, it SHOULD send a DHCPLEASEQUERYSTATUS message with a dhcp-status-code of QueryTerminated and include in the message a base-time. This MUST be the last message on that connection, and once the message has been transmitted, the server MUST close the connection.
DHCPv4サーバーがDHCPACTIVELEASEQUERY要求の処理を続行できないと判断した場合、DHCPLEASEQUERYSTATUSメッセージは、現在進行中のDHCPACTIVELEASEQUERY要求を一方的に終了する場合があります（MAY）。たとえば、サーバーがシャットダウンを要求された場合、サーバーはDHCPTLEQUEQUERYSTATUSメッセージをQueryTerminatedのdhcp-status-codeで送信し、ベースタイムをメッセージに含める必要があります（SHOULD）。これはその接続の最後のメッセージである必要があり、メッセージが送信されると、サーバーは接続を閉じる必要があります。
After receiving DHCPLEASEQUERYSTATUS with a QueryTerminated status from a server, the Requestor MAY close the TCP connection to that server.
サーバーからQueryTerminatedステータスのDHCPLEASEQUERYSTATUSを受け取った後、リクエスタはそのサーバーへのTCP接続を閉じてもよい（MAY）。
The DHCPv4 Leasequery protocol uses the associated-ip option as an indicator that multiple bindings were present in response to a single client-based query. For Active Leasequery, client-based queries are not supported, and so the associated-ip option is not used and MUST NOT be present in replies.
DHCPv4 Leasequeryプロトコルは、関連するIPオプションを、単一のクライアントベースのクエリに応答して複数のバインディングが存在したことを示すインジケータとして使用します。 Active Leasequeryの場合、クライアントベースのクエリはサポートされないため、関連付けられたIPオプションは使用されず、応答に存在してはなりません（MUST NOT）。
If the DHCPACTIVELEASEQUERY was requested with a query-start-time, the DHCPv4 server will attempt to send information about all bindings that changed since the time specified in the query-start-time. This is the catch-up phase of the DHCPACTIVELEASEQUERY processing. The DHCPv4 server MAY also begin immediate updates over the same connection of real-time binding information changes. Thus, the catch-up phase can run in parallel with the normal updates generated by the DHCPACTIVELEASEQUERY request.
DHCPACTIVELEASEQUERYがquery-start-timeで要求された場合、DHCPv4サーバーは、query-start-timeで指定された時間以降に変更されたすべてのバインディングに関する情報を送信しようとします。これは、DHCPACTIVELEASEQUERY処理のキャッチアップフェーズです。 DHCPv4サーバーは、リアルタイムのバインディング情報変更の同じ接続を介して、すぐに更新を開始する場合があります。したがって、キャッチアップフェーズは、DHCPACTIVELEASEQUERY要求によって生成される通常の更新と並行して実行できます。
A DHCPv4 server MAY keep only a limited amount of time-ordered information available to respond to a DHCPACTIVELEASEQUERY request containing a query-start-time. Thus, it is possible that the time specified in the query-start-time represents a time not covered by the time-ordered information kept by the DHCPv4 server. In such case, when there is not enough data saved in the DHCPv4 server to satisfy the request specified by the query-start-time option, the DHCPv4 server will reply immediately with a DHCPLEASEQUERYSTATUS message with a dhcp-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 DHCPACTIVELEASEQUERY request.
DHCPv4サーバーは、クエリ開始時刻を含むDHCPACTIVELEASEQUERY要求に応答するために利用できる限られた時間順の情報のみを保持してもよい（MAY）。したがって、query-start-timeで指定された時間が、DHCPv4サーバーが保持する時間順の情報でカバーされていない時間を表す可能性があります。このような場合、query-start-timeオプションで指定された要求を満たすのに十分なデータがDHCPv4サーバーに保存されていない場合、DHCPv4サーバーは、DHCPLEASEQUERYSTATUSメッセージで応答し、dhcp-status-codeがDataMissingであるサーバーの現在時刻に等しい基本時間オプション。これにより、キャッチアップフェーズの終了が通知されます。その後、この接続で受信される唯一の更新は、DHCPACTIVELEASEQUERY要求からのリアルタイムの更新です。
If there is enough data saved to satisfy the request, then DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will begin arrive from the DHCPv4 server. Some of these messages will be related to the query-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 DHCPv4 server. In general, there is no way to determine the source of each message.
要求を満たすのに十分なデータが保存されている場合、DHCPLEASEACTIVEおよびDHCPLEASEUNASSIGNEDメッセージがDHCPv4サーバーから到着し始めます。これらのメッセージの一部は、クエリ開始時間リクエストに関連し、キャッチアップフェーズの一部になります。これらのメッセージの一部は、DHCPv4サーバーで行われているバインディング変更のリアルタイム更新です。一般に、各メッセージのソースを判別する方法はありません。
The updates sent by the DHCPv4 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 DHCPv4 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 DHCPACTIVELEASEQUERY were to terminate prior to the completion of the catch-up phase.
キャッチアップフェーズ中にDHCPv4サーバーによって送信された更新は、バインディングデータが更新された順序ではありません。したがって、キャッチアップフェーズが完了するまで、Active Leasequery要求を処理するDHCPv4サーバーから受信した最新のベースタイム値は、着信メッセージからリセットできません（そして、後続のActive Leasequeryのquery-start-timeオプションで使用されます）。 DHCPACTIVELEASEQUERYがキャッチアップフェーズの完了前に終了すると、失われた情報を回復する機能が損なわれるためです。
The requestor will know that the catch-up phase is complete because the DHCPv4 server will transmit a DHCPLEASEQUERYSTATUS message with the dhcp-status-code of CatchUpComplete (or, as discussed above, DataMissing). Once this message is transmitted, all additional DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED messages will relate to real-time ("new") binding changes in the DHCPv4 server.
DHCPv4サーバーがDHCPLEASEQUERYSTATUSメッセージをCatchUpComplete（または、前述のようにDataMissing）のdhcp-status-codeで送信するため、リクエスタはキャッチアップフェーズが完了したことを認識します。このメッセージが送信されると、追加のすべてのDHCPLEASEACTIVEおよびDHCPLEASEUNASSIGNEDメッセージは、DHCPv4サーバーでのリアルタイム（「新しい」）バインディングの変更に関連します。
As discussed in Section 6.3, the requestor SHOULD keep track of the latest base-time option value received over a particular connection, to be used in a subsequent DHCPACTIVELEASEQUERY 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 DHCPLEASEQUERYDONE 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.
セクション6.3で説明したように、リクエスタは、後続のDHCPACTIVELEASEQUERYリクエストで使用するために、特定の接続で受信した最新のベースタイムオプション値を追跡する必要があります（ただし、キャッチアップフェーズが完了した場合のみ）。キャッチアップフェーズが完了する前に、接続を解除する必要がある場合、またはリクエスタがDHCPLEASEQUERYDONEメッセージを受信した場合、再接続する際には、受信したベースタイム値ではなく、以前の接続のベースタイム値を使用する必要があります。最近閉じた接続から。
In the event that there was enough data available to the DHCPv4 server to begin to satisfy the request implied by the query-start-time option, but during the processing of that data the server found that it was unable to continue (perhaps there was barely enough, the connection was very slow, and the aging algorithm caused the saved data to become unavailable), the DHCPv4 server will terminate the catch-up phase of processing immediately by sending a DHCPLEASEQUERYSTATUS message with a dhcp-status-code of DataMissing and with a base-time option of the current time.
DHCPv4サーバーがquery-start-timeオプションによって暗示される要求を満たすために開始するのに十分なデータが利用可能であったが、そのデータの処理中にサーバーが続行できないことがわかった場合（おそらく十分に、接続が非常に遅く、エージングアルゴリズムによって保存されたデータが使用できなくなった場合）、DHCPv4サーバーは、dhcp-status-codeがDataMissingであるDHCPLEASEQUERYSTATUSメッセージを送信することにより、処理のキャッチアップフェーズを直ちに終了します。現在時刻のベースタイムオプション。
The requestor must not assume that every individual state change of every binding during the period from the time specified in the query-start-time and the present is replicated in an Active Leasequery reply message. See Section 6. 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 query-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.
リクエスタは、query-start-timeで指定された時刻から現在までの期間のすべてのバインディングの個々の状態変化がすべてActive Leasequery応答メッセージで複製されると想定してはなりません。セクション6を参照してください。リクエスタは、query-start-timeと現在の時間で指定された期間に1つ以上の状態の変化があったすべてのバインディングに対して、少なくとも1つのActive Leasequery応答メッセージが存在すると想定できます。各バインディングの最後のメッセージには、現時点での状態が含まれ、処理のキャッチアップフェーズ中に単一のバインディングに関するメッセージが1つ以上存在する可能性があります。
Bindings can change multiple times while the requestor is not connected. 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 query-start-time to the present.
リクエスタが接続されていない間、バインディングは複数回変更される可能性があります。リクエスタは、クエリの開始時刻から現在までの期間中に発生した各状態変化に関する情報ではなく、バインディングの現在の状態に関する情報のみを受け取ります。
If the DHCPLEASEQUERYSTATUS message containing a dhcp-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 the bindings in the DHCPv4 server, then the requestor SHOULD issue a DHCPBULKLEASEQUERY request to recover the information missing from its database. This DHCPBULKLEASEQUERY should include a query-start-time option, set to the same value as the query-start-time option previously included in the DHCPACTIVELEASEQUERY responses from the DHCPv4 server, and a query-end-time option equal to the base-time option returned by the DHCPv4 server in the DHCPLEASEQUERYSTATUS message with the dhcp-status-code of DataMissing.
DataMissingのdhcp-status-codeを含むDHCPLEASEQUERYSTATUSメッセージが受信され、リクエスターがDHCPv4サーバーのバインディングの現在の状態に関してデータベースを最新の状態に保つことに関心がある場合、リクエスターはDHCPBULKLEASEQUERY要求を発行して（SHOULD）データベースから欠落している情報を回復します。このDHCPBULKLEASEQUERYには、以前にDHCPv4サーバーからのDHCPACTIVELEASEQUERY応答に含まれていたquery-start-timeオプションと同じ値に設定されたquery-start-timeオプションと、base-timeに等しいquery-end-timeオプションを含める必要があります。 DataMissingのdhcp-status-codeを含むDHCPLEASEQUERYSTATUSメッセージでDHCPv4サーバーによって返されるオプション。
Typically, the requestor would have one connection open to a DHCPv4 server for a DHCPACTIVELEASEQUERY request and possibly one additional connection open for a DHCPBULKLEASEQUERY request to the same DHCPv4 server to fill in the data that might have been missed prior to the initiation of the DHCPACTIVELEASEQUERY. The Bulk Leasequery connection would typically run to completion and be closed, leaving one Active Leasequery connection open to a single DHCPv4 server.
通常、リクエスターは、DHCPACTIVELEASEQUERY要求のためにDHCPv4サーバーへの接続を1つ開いており、DHCPACTIVELEASEQUERYの開始前に欠落していた可能性があるデータを埋めるために、同じDHCPv4サーバーへのDHCPBULKLEASEQUERY要求のために1つの追加接続を開く可能性があります。バルクリースクエリ接続は通常、完了するまで実行されて閉じられ、1つのアクティブリースクエリ接続が単一のDHCPv4サーバーに対して開いたままになります。
The Requestor or DHCPv4 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.
リクエスターまたはDHCPv4リースクエリサーバーは、TCP接続の最後をいつでも閉じることができます（MAY）。リクエスタは、追加のクエリを発行する場合、接続を保持することを選択できます（MAY）。このリクエスタの動作は、接続が追加のクエリで使用できることを保証するものではないことに注意してください。サーバーは独自の構成に基づいて接続を閉じることを決定する場合があります。
A DHCPv4 server that supports Active Leasequery MUST support Bulk Leasequery [RFC6926] as well.
Active LeasequeryをサポートするDHCPv4サーバーは、Bulk Leasequery [RFC6926]もサポートする必要があります。
DHCPv4 servers that implement DHCPv4 Active Leasequery listen for incoming TCP connections. The approach used in accepting the requestor's connection is the same as specified in DHCPv4 Bulk Leasequery [RFC6926], 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.
DHCPv4 Active Leasequeryを実装するDHCPv4サーバーは、着信TCP接続をリッスンします。リクエスタの接続を受け入れる際に使用されるアプローチは、DHCPv4バルクリースクエリ[RFC6926]で指定されているものと同じですが、アクティブリースクエリのサポートをデフォルトで有効にしてはならず（MUST）、操作する前に明示的な構成手順を実行する必要がある。
DHCPv4 servers SHOULD be able to operate in either insecure or secure mode. See Section 9. 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.
DHCPv4サーバーは、非セキュアモードまたはセキュアモードのいずれかで動作できる必要があります（SHOULD）。セクション9を参照してください。これは、サーバーが動作するためにTLS接続を必要とするか、TLS接続なしでのみ動作する、管理上制御されるモードである可能性があります。どちらの場合も、セキュアモードでの操作がサポートされていない場合でも、非セキュアモードでの操作をデフォルトにすることはできません。安全でないモードでの操作では、アクティブリースクエリのサポートを有効にするために必要な構成手順とは別に、常に明示的な構成手順が必要です。
When operating in insecure mode, the DHCPv4 server simply waits for the requestor to send the Active Leasequery after the establishment of TCP connection. If it receives a DHCPTLS message, it will respond with TLSConnectionRefused in a DHCPTLS message.
安全でないモードで動作している場合、DHCPv4サーバーは、TCP接続の確立後、リクエスタがActive Leasequeryを送信するのを待つだけです。 DHCPTLSメッセージを受信すると、DHCPTLSメッセージ内のTLSConnectionRefusedで応答します。
When operating in secure mode, DHCPv4 servers MUST support TLS [RFC5246] to protect the integrity and privacy of the data transmitted over the TCP connection. When operating in secure mode, DHCPv4 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.
セキュアモードで動作する場合、DHCPv4サーバーは、TCP接続を介して送信されるデータの完全性とプライバシーを保護するためにTLS [RFC5246]をサポートする必要があります。セキュアモードで動作している場合、DHCPv4サーバーは、通信するリクエスタに関して構成可能である必要があります。 TLS接続を開始するときにリクエスタによって提示される証明書は、受け入れ可能なリクエスタと受け入れられないリクエスタを区別するために使用されます。
When operating in secure mode, a DHCPv4 server MUST begin to negotiate a TLS connection with a requestor who asks for one, and MUST close TCP connections that are not secured with TLS or for which the requestor's certificate is deemed unacceptable. The recommendations in [RFC7525] apply when negotiating a TLS connection.
セキュアモードで動作している場合、DHCPv4サーバーは、接続を要求するリクエスタとTLS接続のネゴシエーションを開始する必要があり、TLSで保護されていないか、リクエスタの証明書が受け入れられないと見なされるTCP接続を閉じる必要があります。 [RFC7525]の推奨事項は、TLS接続をネゴシエートするときに適用されます。
A requestor will request a TLS connection by sending a DHCPTLS as the first message over a newly created TCP connection. If the DHCPv4 server supports TLS connections and has not been configured to not allow them on this link, the DHCPv4 server MUST respond to this DHCPTLS message by sending a DHCPTLS message with no dhcp-status-code back to the requestor. This indicates to the requestor that the DHCPv4 server will support the negotiation of a TLS connection over this existing TCP connection.
リクエスタは、新しく作成されたTCP接続を介してDHCPTLSを最初のメッセージとして送信することにより、TLS接続を要求します。 DHCPv4サーバーがTLS接続をサポートし、このリンクでそれらを許可しないように構成されていない場合、DHCPv4サーバーはdhcp-status-codeのないDHCPTLSメッセージをリクエスターに送信することにより、このDHCPTLSメッセージに応答する必要があります。これは、DHCPv4サーバーがこの既存のTCP接続を介したTLS接続のネゴシエーションをサポートすることを要求者に示します。
If a connection is to be rejected because of a limitation of the number of open connections, the TCP connection itself should be rejected, or the subsequent ACTIVELEASEQUERY message should be rejected. Capacity-related rejections SHOULD NOT affect the response to the DHCPTLS message.
オープン接続数の制限のために接続が拒否される場合は、TCP接続自体を拒否するか、後続のACTIVELEASEQUERYメッセージを拒否する必要があります。キャパシティ関連の拒否は、DHCPTLSメッセージへの応答に影響を与えないでください。
Any options appearing in a DHCPTLS message received by a DHCPv4 server SHOULD be ignored. This is a "SHOULD" instead of a "MUST" in order to allow use of the DHCPTLS message in later documents, possibly with the use of options, without requiring those documents to update this document.
DHCPv4サーバーが受信したDHCPTLSメッセージに表示されるオプションはすべて無視してください。今後のドキュメントでDHCPTLSメッセージを使用できるようにするため、これは「必須」ではなく「SHOULD」であり、オプションを使用して、これらのドキュメントでこのドキュメントを更新する必要はありません。
If for some reason the DHCPv4 server cannot support or has been configured to not support a TLS connection, then it sends a DHCPTLS message with a dhcp-status-code of TLSConnectionRefused back to the requestor.
何らかの理由でDHCPv4サーバーがTLS接続をサポートできないか、TLS接続をサポートしないように構成されている場合は、DHCPConnectionメッセージをTLSConnectionRefusedのDHCPcp-status-codeでリクエスタに送信します。
In the event that the DHCPv4 server sends a DHCPTLS message with no dhcp-status-code option included (which indicates success), the requestor is supposed to initiate a TLS handshake [RFC5246] (see
DHCPv4サーバーがdhcp-status-codeオプションを含まない（成功を示す）DHCPTLSメッセージを送信する場合、リクエスターはTLSハンドシェイク[RFC5246]を開始することになっています（参照）
Section 7.2). During the TLS handshake, the DHCPv4 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.
セクション7.2）。 TLSハンドシェイクの間、DHCPv4サーバーは要求者のデジタル証明書を検証する必要があります。さらに、リクエスタによって提示されたデジタル証明書は、このリクエスタがアクティブリースクエリを実行できるかどうかを決定するために使用されます。このリクエスターの証明書が受け入れられないと思われる場合、サーバーはTLS接続の作成を中止しなければなりません（MUST）。
All TLS connections established between a requestor and a DHCPv4 server for the purposes of supporting Active Leasequery MUST be mutually authenticated.
Active Leasequeryをサポートする目的でリクエスタとDHCPv4サーバーの間に確立されたすべてのTLS接続は、相互に認証される必要があります。
If the TLS handshake is not successful in creating a TLS connection, the server MUST close the TCP connection.
TLSハンドシェイクがTLS接続の作成に成功しない場合、サーバーはTCP接続を閉じる必要があります。
If the TCP connection becomes blocked while the server is accepting a connection or reading a query, it SHOULD terminate the connection after a BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow servers to control the period of time they are willing to wait before abandoning an inactive connection, independent of the TCP implementations they may be using.
サーバーが接続を受け入れている間、またはクエリを読み取っている間にTCP接続がブロックされた場合、BULK_LQ_DATA_TIMEOUTの後で接続を終了する必要があります（SHOULD）。この推奨事項は、サーバーが使用しているTCP実装とは無関係に、非アクティブな接続を破棄する前にサーバーが待機する時間を制御できるようにするためのものです。
In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which didn't discuss this situation explicitly), if the DHCPv4 server receives a DHCPv4 message containing a dhcp-message-type option with a value that is not supported over a TCP connection, it MUST close the TCP connection.
DHCPv4バルクリースクエリプロトコル[RFC6926]（この状況については明示的に説明していません）への更新で、DHCPv4サーバーが、TCP接続でサポートされていない値を持つdhcp-message-typeオプションを含むDHCPv4メッセージを受信した場合、それはTCP接続を閉じなければなりません。
If the connection becomes blocked while the server is attempting to send reply messages, the server SHOULD terminate the TCP connection after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs how long the DHCPv4 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 DHCPv4 server SHOULD close the TCP connection.
サーバーが応答メッセージを送信しようとしている間に接続がブロックされた場合、サーバーは、ACTIVE_LQ_SEND_TIMEOUTの後でTCP接続を終了する必要があります（SHOULD）。このタイムアウトは、リクエスターがTCP接続のブロックを解除するのに十分な情報を読み取って処理するのをDHCPv4サーバーが待機する準備ができる時間を管理します。デフォルトは2分です。つまり、リクエスターがTCP接続をブロック解除するのに十分な情報を読み取らないまま2分以上経過した場合、DHCPv4サーバーはTCP接続を閉じる必要があります（SHOULD）。
If the DHCPv4 server encounters an error during processing of the DHCPACTIVELEASEQUERY message, either during initial processing or later during the message processing, it SHOULD send a DHCPLEASEQUERYSTATUS containing an error code of some kind in a dhcp-status-code option. It SHOULD close the connection after this error is signaled.
DHCPv4サーバーがDHCPACTIVELEASEQUERYメッセージの処理中に、初期処理中または後でメッセージ処理中にエラーを検出した場合、DHCPv4サーバーは、dhcp-status-codeオプションにある種のエラーコードを含むDHCPLEASEQUERYSTATUSを送信する必要があります。このエラーが通知された後、接続を閉じる必要があります。
Every reply to a DHCPACTIVELEASEQUERY request MUST contain the information specified in replies to a DHCPBULKLEASEQUERY request [RFC6926], 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 dhcp-parameter-request-list option.
DHCPACTIVELEASEQUERY要求へのすべての応答には、DHCPBULKLEASEQUERY要求[RFC6926]への応答で指定された情報を含める必要があります。ただし、アクティブリースクエリを実装するサーバーは、特定のデータ項目が要求元に送信されないように構成できる必要があります（SHOULD）。 dhcp-parameter-request-listオプションでデータ項目が要求されました。
Some servers can be configured to respond to a DHCPv4 Leasequery [RFC4388] or a DHCPBULKLEASEQUERY [RFC6926] for an IPv4 binding that is reserved in such a way that it appears that the IPv4 binding is leased to the DHCP client for which it is reserved. These servers SHOULD also respond to a DHCPACTIVELEASEQUERY request with the same information as they would to a DHCPBULKLEASEQUERY request when they first determine that the IPv4 binding is reserved to a DHCP client.
一部のサーバーは、予約されているDHCPクライアントにIPv4バインディングがリースされているように見えるように、予約されているIPv4バインディングのDHCPv4 Leasequery [RFC4388]またはDHCPBULKLEASEQUERY [RFC6926]に応答するように構成できます。これらのサーバーは、IPv4バインディングがDHCPクライアントに予約されていると最初に判断したときに、DHCPBULKLEASEQUERY要求に対するのと同じ情報でDHCPACTIVELEASEQUERY要求にも応答する必要があります（SHOULD）。
If a DHCPACTIVELEASEQUERY request contains a query-start-time option, it indicates that the requestor would like the DHCPv4 server to send it not only messages that correspond to DHCPv4 binding activity that occurs subsequent to the receipt of the DHCPLEASEACTIVE request, but also messages that correspond to DHCPv4 binding activity that occurred prior to the DHCPACTIVELEASEQUERY request.
DHCPACTIVELEASEQUERY要求にquery-start-timeオプションが含まれている場合、リクエスタはDHCPv4サーバーに、DHCPLEASEACTIVE要求の受信後に発生するDHCPv4バインディングアクティビティに対応するメッセージだけでなく、 DHCPACTIVELEASEQUERY要求の前に発生したDHCPv4バインディングアクティビティに対応します。
If a query-end-time option appears in a DHCPACTIVELEASEQUERY the DHCPv4 server should send a DHCPLEASEQUERYSTATUS message with a dhcp-status-code of MalformedQuery and terminate the connection.
query-end-timeオプションがDHCPACTIVELEASEQUERYに表示される場合、DHCPv4サーバーは、MalformedQueryのdhcp-status-codeを含むDHCPLEASEQUERYSTATUSメッセージを送信し、接続を終了する必要があります。
In order to implement a meaningful response to this query, the DHCPv4 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 a DHCPACTIVELEASEQUERY request containing a query-start-time option, the DHCPv4 server can respond with replies for all binding activity occurring on that query-start-time or later times.
このクエリに対する意味のある応答を実装するために、DHCPv4サーバーはバインディングアクティビティを追跡し、メッセージからの特定のベースタイム値に変更を関連付けることができます（MAY）。次に、query-start-timeオプションを含むDHCPACTIVELEASEQUERY要求によって要求された場合、DHCPv4サーバーは、そのquery-start-time以降に発生したすべてのバインディングアクティビティに対する応答で応答できます。
These replies based on the query-start-time MAY be interleaved with the messages generated due to current binding activity.
query-start-timeに基づくこれらの応答は、現在のバインディングアクティビティが原因で生成されたメッセージとインターリーブされる場合があります。
Once the transmission of the DHCPv4 Leasequery messages associated with the query-start-time option are complete, a DHCPLEASEQUERYSTATUS message MUST be sent with a dhcp-status-code value of CatchUpComplete.
query-start-timeオプションに関連付けられたDHCPv4 Leasequeryメッセージの送信が完了したら、DHCPLEASEQUERYSTATUSメッセージをCatchUpCompleteのdhcp-status-code値とともに送信する必要があります。
The DHCPv4 server SHOULD keep track of previous binding activity. It SHOULD limit the amount of previous binding activity it keeps track of. The DHCPv4 server MAY choose to only do this in the event that it has received at least one DHCPACTIVELEASEQUERY request in the past, as to do so will almost certainly entail some utilization of resources that would be wasted if there are no DHCPACTIVELEASEQUERY requestors for this DHCPv4 server. The DHCPv4 server SHOULD make the amount of previous binding activity it retains configurable. There is no requirement on the DHCPv4 server to retain this information over a server restart (or even to retain such information at all).
DHCPv4サーバーは、以前のバインディングアクティビティを追跡する必要があります（SHOULD）。それは追跡する以前のバインディングアクティビティの量を制限する必要があります。 DHCPv4サーバーは、過去に少なくとも1つのDHCPACTIVELEASEQUERY要求を受信した場合にのみこれを実行することを選択できます。これを行うと、このDHCPv4にDHCPACTIVELEASEQUERYリクエスタが存在しない場合、無駄になるリソースの使用がほぼ確実に伴うためです。サーバ。 DHCPv4サーバーは、保持する以前のバインディングアクティビティの量を構成可能にする必要があります（SHOULD）。 DHCPv4サーバーでは、サーバーの再起動後もこの情報を保持する必要はありません（またはそのような情報を保持する必要はありません）。
Unless there is an error or some requirement to cease processing a DHCPACTIVELEASEQUERY request yielding a DHCPLEASEQUERYSTATUS message, such as a server shutdown, there will be no DHCPLEASEQUERYSTATUS message at the conclusion of the DHCPACTIVELEASEQUERY processing because that processing will not conclude but will continue until either the requestor or the server closes the connection.
エラーや、サーバーのシャットダウンなどのDHCPLEASEQUERYSTATUSメッセージを生成するDHCPACTIVELEASEQUERY要求の処理を中止する必要がある場合を除き、DHCPACTIVELEASEQUERY処理の最後にDHCPLEASEQUERYSTATUSメッセージは表示されません。リクエスタまたはサーバーが接続を閉じます。
While the form of the data being sent by a DHCPACTIVELEASEQUERY is essentially the same as that being sent by a DHCPBULKLEASEQUERY, the reasons for sending information differs considerably between these two capabilities. In the DHCPBULKLEASEQUERY context, the entire contents of the lease state database (subject to the constraints of the various query options) are returned to the requestor. In the DHCPACTIVELEASEQUERY context, changes to the lease state database are returned to the requestor essentially as they happen. For instance, when an IPv4 binding transitions from the leased state to some other state, the DHCPACTIVELEASEQUERY will send a DHCPLEASEUNASSIGNED packet with information regarding that binding. The server may then entirely forget about that IPv4 binding (or not), but it is important to tell the DHCPACTIVELEASEQUERY requestor that a binding has transitioned away from the leased state.
DHCPACTIVELEASEQUERYによって送信されるデータの形式は基本的にDHCPBULKLEASEQUERYによって送信されるデータの形式と同じですが、情報を送信する理由はこれら2つの機能の間でかなり異なります。 DHCPBULKLEASEQUERYコンテキストでは、リース状態データベースの内容全体（さまざまなクエリオプションの制約に従う）がリクエスタに返されます。 DHCPACTIVELEASEQUERYコンテキストでは、リース状態データベースへの変更は、基本的に発生時にリクエスタに返されます。たとえば、IPv4バインディングがリース状態から他の状態に移行すると、DHCPACTIVELEASEQUERYはDHCPLEASEUNASSIGNEDパケットをそのバインディングに関する情報とともに送信します。その場合、サーバーはそのIPv4バインディングを完全に忘れるかもしれませんが、バインディングがリース状態から移行したことをDHCPACTIVELEASEQUERYリクエスタに通知することが重要です。
The relationship between the time that the server replies to a DHCP client request and the time that the DHCP server sends a reply to a DHCPACTIVELEASEQUERY message is a matter of implementation (and thus not defined by this document). However, the server SHOULD NOT delay responding to the DHCP client in order to transmit a reply to a DHCPACTIVELEASEQUERY message, and the server SHOULD send the reply to the DHCPACTIVELASEQUERY message as soon as possible after responding to the client.
サーバーがDHCPクライアント要求に応答する時間とDHCPサーバーがDHCPACTIVELEASEQUERYメッセージに応答を送信する時間の関係は、実装の問題です（したがって、このドキュメントでは定義していません）。ただし、サーバーはDHCPACTIVELEASEQUERYメッセージへの応答を送信するためにDHCPクライアントへの応答を遅らせるべきではなく（SHOULD）、サーバーはクライアントに応答した後できるだけ早くDHCPACTIVELASEQUERYメッセージへの応答を送信する必要があります（SHOULD）。
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. Note that this is different than what was allowed in Section 7.7 of [RFC6926] for Bulk Leasequery requests.
すべてのアクティブなLeasequery要求は、要求が行われたときにアクティブな他の要求がない単一のTCP接続で行われる必要があります。これは、Bulk Leasequeryリクエストに対して[RFC6926]のセクション7.7で許可されたものとは異なることに注意してください。
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 Leasequery requests, the requestor MUST use different connections.
通常、アクティブリースクエリのリクエスタは、最初のアクティブリースクエリがまだアクティブな間に、2番目のアクティブリースクエリを送信する必要はありません。ただし、アクティブリースクエリと一括リースクエリを同時に送信することは可能であり、合理的です。並行アクティブリクエストと一括リースクエリリクエストの場合、リクエスタは異なる接続を使用する必要があります。
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 MAY end communication by sending a DHCPLEASEQUERYSTATUS message and then immediately closing the TCP connection. Alternatively, the server MAY retain the connection and wait for additional queries from the requestor. The server SHOULD limit the number of connections it maintains and SHOULD close idle connections to enforce the limit.
サーバーは、DHCPLEASEQUERYSTATUSメッセージを送信し、TCP接続をすぐに閉じることにより、通信を終了してもよい（MAY）。あるいは、サーバーは接続を保持し、リクエスタからの追加のクエリを待つ場合があります。サーバーは維持する接続の数を制限する必要があり（SHOULD）、制限を実施するためにアイドル接続を閉じる必要があります（SHOULD）。
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 dhcp-status-code option in a DHCPLEASEQUERYSTATUS message. If the server detects that the requestor end has been closed, the server MUST close its end of the connection.
サーバーは、接続でのデータ送信エラーが発生した場合、TCP接続の最後を閉じる必要があります。サーバーは、インプロセス要求を中止する必要があると判断した場合、TCP接続の最後を閉じる必要があります。インプロセス要求を中止するサーバーは、DHCPLEASEQUERYSTATUSメッセージのdhcp-status-codeオプションのQueryTerminatedステータスコードを使用して、要求元にそのことを通知する必要があります（SHOULD）。サーバーがリクエスターの終わりが閉じられたことを検出した場合、サーバーは接続の終わりを閉じなければなりません（MUST）。
The Security Considerations section of [RFC2131] details the general threats to DHCPv4. The DHCPv4 Leasequery specification [RFC4388] describes recommendations for the Leasequery protocol, especially with regard to relayed LEASEQUERY messages, mitigation of packet-flooding DoS attacks, restriction to trusted requestors, and use of IPsec [RFC4301].
[RFC2131]のセキュリティに関する考慮事項のセクションでは、DHCPv4に対する一般的な脅威について詳しく説明しています。 DHCPv4 Leasequery仕様[RFC4388]は、特にリレーされたLEASEQUERYメッセージ、パケットフラッディングDoS攻撃の緩和、信頼できるリクエスタへの制限、およびIPsec [RFC4301]の使用に関して、Leasequeryプロトコルの推奨事項を説明しています。
The use of TCP introduces some additional concerns. Attacks that attempt to exhaust the DHCPv4 server's available TCP connection resources can compromise the ability of legitimate clients to receive service. Malicious requestors who succeed in establishing connections, but who then send invalid queries, partial queries, or no queries at all also can exhaust a server's pool of available connections.
TCPの使用は、いくつかの追加の懸念をもたらします。 DHCPv4サーバーの利用可能なTCP接続リソースを使い果たしようとする攻撃は、正当なクライアントがサービスを受け取る能力を危険にさらす可能性があります。接続の確立に成功したが、無効なクエリ、部分的なクエリを送信する、またはまったくクエリを送信しない悪意のある要求者も、サーバーの利用可能な接続のプールを使い果たす可能性があります。
Two modes of operation exist for this protocol, insecure mode and secure mode. These two modes exist because there are essentially two models of use for this protocol. In one model, the requestor of an Active Leasequery is connected to the Internet in an arbitrary location, and the information transmitted needs to be protected during transmission. In addition, the identities of both requestor and server need to be verified. For this model of use, the secure mode is appropriate.
このプロトコルには、非セキュアモードとセキュアモードの2つの動作モードがあります。これら2つのモードが存在するのは、このプロトコルには基本的に2つの使用モデルがあるためです。 1つのモデルでは、Active Leasequeryのリクエスターは任意の場所でインターネットに接続されており、送信中の情報は送信中に保護する必要があります。さらに、要求者とサーバーの両方のIDを確認する必要があります。この使用モデルでは、セキュアモードが適切です。
The other model of use is where the requestor of the Active Leasequery resides in a network element that is essentially "next to" the element containing the DHCP server, and both of these elements are inside a protected environment. For this model, the insecure mode is sufficient since there are other, more global, protections in place to protect this information.
もう1つの使用モデルは、Active Leasequeryのリクエスターが、DHCPサーバーを含む要素の本質的に「隣」にあるネットワーク要素にあり、これらの要素の両方が保護された環境内にある場合です。このモデルでは、この情報を保護するためのよりグローバルな保護が他にもあるため、安全でないモードで十分です。
When operating in secure mode, TLS [RFC5246] is used to secure the connection. The recommendations in [RFC7525] apply when negotiating a TLS connection.
セキュアモードで動作している場合、TLS [RFC5246]を使用して接続を保護します。 [RFC7525]の推奨事項は、TLS接続をネゴシエートするときに適用されます。
Operating in insecure mode (see Section 8.1) does not provide any way to validate the authorization of requestors of a DHCPV4 Active Leasequery request.
安全でないモードでの操作（セクション8.1を参照）は、DHCPV4 Active Leasequery要求の要求者の承認を検証する方法を提供しません。
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 DHCPv4 server from which it was acquired and SHOULD be secured by mechanisms as strong as those used for the data held by that DHCPv4 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を使用して取得したデータは、取得元のDHCPv4サーバーが保持するデータと同じ不正使用の可能性があり、そのDHCPv4サーバーが保持するデータに使用されるものと同じくらい強力なメカニズムで保護する必要があります。 Active Leasequeryを使用して取得したデータは、取得した使用が経過した後、できるだけ早く削除する必要があります（SHOULD）。
Servers that implement the Bulk Leasequery protocol [RFC6926] but do not implement the Active Leasequery protocol SHOULD implement the update to [RFC6926] discussed in Section 8.1.1.
Bulk Leasequeryプロトコル[RFC6926]を実装しているが、Active Leasequeryプロトコルを実装していないサーバーは、セクション8.1.1で説明されている[RFC6926]への更新を実装する必要があります（SHOULD）。
IANA has assigned the following new DHCP message types from the registry "DHCP Message Type 53 Values" maintained at <http://www.iana.org/assignments/bootp-dhcp-parameters>:
IANAは、<http://www.iana.org/assignments/bootp-dhcp-parameters>で管理されているレジストリ「DHCP Message Type 53 Values」から、次の新しいDHCPメッセージタイプを割り当てました。
1. A dhcp-message-type of 16 for DHCPACTIVELEASEQUERY.
1. DHCPACTIVELEASEQUERYのdhcp-message-typeは16。
2. A dhcp-message-type of 17 for DHCPLEASEQUERYSTATUS.
2. DHCPLEASEQUERYSTATUSのdhcp-message-typeは17。
3. A dhcp-message-type of 18 for DHCPTLS.
3. DHCPTLSのdhcp-message-typeは18。
IANA has assigned the following new DHCP status codes from the registry "DHCP Status Code Type 151 Values" maintained at <http://www.iana.org/assignments/bootp-dhcp-parameters>:
IANAは、<http://www.iana.org/assignments/bootp-dhcp-parameters>で管理されているレジストリ「DHCPステータスコードタイプ151値」から、次の新しいDHCPステータスコードを割り当てました。
+----------------------+-------------+
| Name | Status-Code |
+----------------------+-------------+
| DataMissing | 5 |
| ConnectionActive | 6 |
| CatchUpComplete | 7 |
| TLSConnectionRefused | 8 |
+----------------------+-------------+
[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>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<http://www.rfc-editor.org/info/rfc2131>。
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, DOI 10.17487/RFC4388, February 2006, <http://www.rfc-editor.org/info/rfc4388>.
[RFC4388] Woundy、R。、およびK. Kinnear、「Dynamic Host Configuration Protocol（DHCP）Leasequery」、RFC 4388、DOI 10.17487 / RFC4388、2006年2月、<http://www.rfc-editor.org/info/rfc4388 >。
[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>。
[RFC6926] Kinnear, K., Stapp, M., Desetti, R., Joshi, B., Russell, N., Kurapati, P., and B. Volz, "DHCPv4 Bulk Leasequery", RFC 6926, DOI 10.17487/RFC6926, April 2013, <http://www.rfc-editor.org/info/rfc6926>.
[RFC6926] Kinnear、K.、Stapp、M.、Desetti、R.、Joshi、B.、Russell、N.、Kurapati、P。、およびB. Volz、「DHCPv4 Bulk Leasequery」、RFC 6926、DOI 10.17487 / RFC6926、2013年4月、<http://www.rfc-editor.org/info/rfc6926>。
[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>。
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, DOI 10.17487/RFC0951, September 1985, <http://www.rfc-editor.org/info/rfc951>.
[RFC951] Croft、W. and J. Gilmore、 "Bootstrap Protocol"、RFC 951、DOI 10.17487 / RFC0951、September 1985、<http://www.rfc-editor.org/info/rfc951>。
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542, October 1993, <http://www.rfc-editor.org/info/rfc1542>.
[RFC1542] Wimer、W。、「ブートストラッププロトコルの説明と拡張」、RFC 1542、DOI 10.17487 / RFC1542、1993年10月、<http://www.rfc-editor.org/info/rfc1542>。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、DOI 10.17487 / RFC2132、1997年3月、<http://www.rfc-editor.org/info/rfc2132>。
[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
謝辞
The ideas in this document came in part from work in DHCPv6 and DHCPv4 Bulk Leasequery as well as from in depth discussions between the authors. Useful review comments by Ted Lemon, Scott Bradner, Francis Dupont, and Stephen Farrell on drafts for DHCPv6 Active Leasequery were also included in this draft. Brian Haberman's review brought this document into much closer alignment with DHCPv6 Active Leasequery. Additional reviews by Alissa Cooper, Spencer Dawkins, Christer Holmberg, and Ben Campbell added clarity to this document.
このドキュメントのアイデアの一部は、DHCPv6とDHCPv4のバルクリースクエリでの作業と、作成者間の詳細な議論から生まれました。 DHCPv6 Active Leasequeryのドラフトに関するテッドレモン、スコットブラドナー、フランシスデュポン、およびスティーブンファレルによる有用なレビューコメントもこのドラフトに含まれていました。 Brian Habermanのレビューにより、このドキュメントはDHCPv6 Active Leasequeryとより密接に連携しました。 Alissa Cooper、Spencer Dawkins、Christer Holmberg、Ben Campbellによる追加のレビューにより、このドキュメントが明確になりました。
Authors' Addresses
著者のアドレス
Kim Kinnear Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 United States
Kim Kinnear Cisco Systems、Inc. 1414 Massachusetts Ave Boxborough、MA 01719 United States
Email: kkinnear@cisco.com
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 United States
Mark Stapp Cisco Systems、Inc. 1414 Massachusetts Ave Boxborough、MA 01719 United States
Email: mjs@cisco.com
Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 United States
Bernie Volz Cisco Systems、Inc. 1414 Massachusetts Ave Boxborough、MA 01719アメリカ合衆国
Email: volz@cisco.com
Neil Russell Staples 500 Staples Drive Framingham, MA 01702 United States
Neil Russell Staples 500 Staples Drive Framingham、MA 01702アメリカ
Email: neil.e.russell@gmail.com