[要約] RFC 6926は、DHCPv4 Bulk Leasequeryプロトコルに関する仕様です。このRFCの目的は、DHCPサーバーから大量のリース情報を効率的に取得するための方法を提供することです。
Internet Engineering Task Force (IETF) K. Kinnear
Request for Comments: 6926 M. Stapp
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 R. Desetti
B. Joshi
Infosys Ltd.
N. Russell
Sea Street Technologies Inc.
P. Kurapati
Juniper Networks
B. Volz
Cisco Systems, Inc.
April 2013
DHCPv4 Bulk Leasequery
DHCPv4一括リースクエリ
Abstract
概要
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP.
IPv4の動的ホスト構成プロトコル（DHCPv4）Leasequeryプロトコルを使用すると、要求者はDHCPv4バインディングに関する情報を要求できます。このプロトコルは、個々のバインディングのクエリに限定されています。状況によっては、個々のバインディングクエリが効率的でなく、場合によっては不可能になることもあります。このドキュメントでは、DHCPv4 Leasequeryプロトコルを拡張して、TCPを介したDHCPv4アドレスバインディングデータのバルク転送を可能にします。
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/rfc6926.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6926で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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 .....................................................5
3. Design Goals ....................................................8
3.1. Information Acquisition before Data Starts .................8
3.2. Lessen Need for Caching and Negative Caching ...............8
3.3. Antispoofing in 'Fast Path' ................................8
3.4. Minimize Data Transmission .................................9
4. Protocol Overview ...............................................9
5. Interaction between UDP Leasequery and Bulk Leasequery .........11
6. Message and Option Definitions .................................12
6.1. Message Framing for TCP ...................................12
6.2. New or Changed Options ....................................13
6.3. Connection and Transmission Parameters ....................20
7. Requestor Behavior .............................................21
7.1. Connecting and General Processing .........................21
7.2. Forming a Bulk Leasequery .................................21
7.3. Processing Bulk Replies ...................................23
7.4. Processing Time Values in Leasequery Messages .............25
7.5. Querying Multiple Servers .................................26
7.6. Making Sense out of Multiple Responses concerning
a Single IPv4 Address .....................................26
7.7. Multiple Queries to a Single Server over One Connection ...27
7.8. Closing Connections .......................................28
8. Server Behavior ................................................29
8.1. Accepting Connections .....................................29
8.2. Replying to a Bulk Leasequery .............................29
8.3. Building a Single Reply for Bulk Leasequery ...............33
8.4. Multiple or Parallel Queries ..............................34
8.5. Closing Connections .......................................35
9. Security Considerations ........................................35
10. IANA Considerations ...........................................37
11. Acknowledgements ..............................................38
12. References ....................................................38
12.1. Normative References .....................................38
12.2. Informative References ...................................39
DHCPv4 [RFC2131] [RFC2132] specifies a protocol for the assignment of IPv4 address and configuration information to IPv4 nodes. DHCPv4 servers maintain authoritative binding information.
DHCPv4 [RFC2131] [RFC2132]は、IPv4アドレスと構成情報をIPv4ノードに割り当てるためのプロトコルを指定します。 DHCPv4サーバーは、信頼できるバインディング情報を維持します。
+--------+
| DHCPv4 | +--------------+
| Server |-...-| DHCP |
| | | Relay Agent |
+--------+ +--------------+
| |
+------+ +------+
|Modem1| |Modem2|
+------+ +------+
| | |
+-----+ +-----+ +-----+
|Node1| |Node2| |Node3|
+-----+ +-----+ +-----+
Figure 1: Example DHCPv4 Configuration
図1：DHCPv4構成の例
DHCPv4 relay agents receive DHCPv4 messages and frequently append a Relay Agent Information option [RFC3046] before relaying them to the configured DHCPv4 servers (see Figure 1). In this process, some relay agents also glean lease information sent by the server and cache it locally. This information is used for a variety of purposes. Two examples are prevention of spoofing attempts from the DHCPv4 clients and installation of routes. When a relay agent reboots, this information is frequently lost.
DHCPv4リレーエージェントは、DHCPv4メッセージを受信し、構成済みのDHCPv4サーバーにリレーする前に、リレーエージェント情報オプション[RFC3046]を頻繁に追加します（図1を参照）。このプロセスでは、一部のリレーエージェントもサーバーから送信されたリース情報を収集し、ローカルにキャッシュします。この情報は、さまざまな目的で使用されます。 2つの例は、DHCPv4クライアントからのなりすましの試みの防止とルートのインストールです。リレーエージェントが再起動すると、この情報は頻繁に失われます。
The DHCPv4 Leasequery capability [RFC4388] extends the basic DHCPv4 capability to allow an external entity, such as a relay agent, to query a DHCPv4 server to rapidly recover lease state information about a particular IP address or client.
DHCPv4 Leasequery機能[RFC4388]は、基本的なDHCPv4機能を拡張して、リレーエージェントなどの外部エンティティがDHCPv4サーバーにクエリを実行し、特定のIPアドレスまたはクライアントに関するリース状態情報を迅速に回復できるようにします。
The existing query types in Leasequery are typically data driven; the relay agent initiates the Leasequery when it receives data traffic from or to the client. This approach may not scale well when there are thousands of clients connected to the relay agent or when the relay agent has a need to rebuild its internal data store prior to processing traffic in one direction or another.
Leasequeryの既存のクエリタイプは通常、データ駆動型です。リレーエージェントは、クライアントとの間でデータトラフィックを受信すると、リースクエリを開始します。数千のクライアントがリレーエージェントに接続されている場合、またはリレーエージェントがトラフィックをある方向または別の方向に処理する前に内部データストアを再構築する必要がある場合、このアプローチは適切にスケーリングしない可能性があります。
Some applications require the ability to query the server without waiting for traffic from or to clients. This query capability, in turn, requires an underlying transport more suitable to the bulk transmission of data.
一部のアプリケーションでは、クライアントとの間のトラフィックを待たずにサーバーにクエリを実行する機能が必要です。このクエリ機能には、データのバルク送信により適した基礎となるトランスポートが必要です。
This document extends the DHCPv4 Leasequery protocol [RFC4388] to add support for queries that address these additional requirements. There may be many thousands of DHCPv4 bindings returned as the result of a single request, so TCP [RFC4614] is specified for efficiency of data transfer. We define several additional query types, each of which can return multiple responses, in order to meet a variety of requirements.
このドキュメントは、DHCPv4 Leasequeryプロトコル[RFC4388]を拡張して、これらの追加要件に対処するクエリのサポートを追加します。単一の要求の結果として何千ものDHCPv4バインディングが返される可能性があるため、TCP [RFC4614]はデータ転送の効率のために指定されています。さまざまな要件を満たすために、それぞれが複数の応答を返すことができるいくつかの追加のクエリタイプを定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
This document uses the following terms:
このドキュメントでは、次の用語を使用します。
o "absolute time"
o 「絶対時間」
Absolute time is a 32-bit quantity containing the number of seconds since January 1, 1970.
絶対時間は、1970年1月1日からの秒数を含む32ビット量です。
o "access concentrator"
o 「アクセスコンセントレーター」
An access concentrator is a router or switch at the broadband access provider's edge of a public broadband access network. This document assumes that the access concentrator includes the DHCPv4 relay agent functionality, for example, a CMTS (Cable Modem Termination System) in a cable environment or a DSLAM (Digital Subscriber Line Access Multiplexer) in a DSL environment.
アクセスコンセントレータは、ブロードバンドアクセスプロバイダーのパブリックブロードバンドアクセスネットワークのエッジにあるルーターまたはスイッチです。このドキュメントでは、アクセスコンセントレータにDHCPv4リレーエージェント機能が含まれていることを前提としています。たとえば、ケーブル環境ではCMTS（ケーブルモデムターミネーションシステム）、DSL環境ではDSLAM（デジタル加入者回線アクセスマルチプレクサ）などです。
o "active binding"
o 「アクティブバインディング」
An IP address with an active binding refers to an IP address that is currently associated with a DHCPv4 client where that DHCPv4 client has the right to use the IP address.
アクティブなバインディングのあるIPアドレスは、現在DHCPv4クライアントに関連付けられているIPアドレスを指し、DHCPv4クライアントはIPアドレスを使用する権利を持っています。
o "Bulk Leasequery"
o 「一括リースクエリ」
Bulk Leasequery involves requesting and receiving the existing DHCPv4 address binding information in an efficient manner.
Bulk Leasequeryには、既存のDHCPv4アドレスバインディング情報を効率的な方法で要求および受信することが含まれます。
o "clock skew"
o 「クロックスキュー」
The clock skew for a Bulk Leasequery connection is the difference between the absolute time on a DHCPv4 server and the absolute time on the system where a requestor of a Bulk Leasequery is executing. It is not absolutely constant but is likely to vary only slowly.
Bulk Leasequery接続のクロックスキューは、DHCPv4サーバーの絶対時間とBulk Leasequeryのリクエスタが実行されているシステムの絶対時間の差です。絶対的に一定ではありませんが、ゆっくりと変化する可能性があります。
It is possible that, when both systems run NTP, the clock skew is negligible; this is not only acceptable but desired.
両方のシステムがNTPを実行している場合、クロックスキューは無視できる可能性があります。これは受け入れられるだけでなく、望ましいことです。
While it is easy to think that this can be calculated precisely after one message is received by a requestor from a DHCPv4 server, a more accurate value is derived from continuously examining the instantaneous value developed from each message received from a DHCPv4 server and using it to make small adjustments to the existing value held in the requestor.
これは、DHCPv4サーバーからリクエスタが1つのメッセージを受信した後に正確に計算できると考えるのは簡単ですが、より正確な値は、DHCPv4サーバーから受信した各メッセージから開発された瞬時値を継続的に調べ、それを使用してリクエスタに保持されている既存の値を少し調整します。
o "Default VPN"
o 「デフォルトVPN」
A default VPN indicates that the address being described belongs to the set of addresses not part of any VPN (in other words, the normal address space operated on by DHCP). This includes Special Use IPv4 Addresses as defined in [RFC5735].
デフォルトのVPNは、記述されているアドレスが、VPN（つまり、DHCPで操作される通常のアドレス空間）の一部ではないアドレスのセットに属していることを示します。これには、[RFC5735]で定義されている特別な用途のIPv4アドレスが含まれます。
o "DHCPv4 client"
o 「DHCPv4クライアント」
A DHCPv4 client is an Internet node using DHCPv4 to obtain configuration parameters such as a network address.
DHCPv4クライアントは、DHCPv4を使用してネットワークアドレスなどの構成パラメーターを取得するインターネットノードです。
o "DHCPv4 relay agent"
o 「DHCPv4リレーエージェント」
A DHCPv4 relay agent is an agent that is neither a DHCPv4 client nor a DHCP server that transfers BOOTP and DHCPv4 messages between clients and servers residing on different subnets, per [RFC951] and [RFC1542].
DHCPv4リレーエージェントは、DHCPv4クライアントでもDHCPサーバーでもないエージェントであり、[RFC951]および[RFC1542]に従って、異なるサブネット上にあるクライアントとサーバー間でBOOTPおよびDHCPv4メッセージを転送します。
o "DHCPv4 server"
o 「DHCPv4サーバー」
A DHCPv4 server is an Internet node that returns configuration parameters to DHCPv4 clients.
DHCPv4サーバーは、構成パラメーターをDHCPv4クライアントに返すインターネットノードです。
o "DSLAM"
o 「DSLAM」
DSLAM stands for Digital Subscriber Line Access Multiplexer.
DSLAMはDigital Subscriber Line Access Multiplexerの略です。
o "downstream"
o "下流"
Downstream refers to a direction away from the central part of a network and toward the edge. In a DHCPv4 context, this typically refers to a network direction that is away from the DHCPv4 server and toward the DHCPv4 client.
ダウンストリームとは、ネットワークの中央部分から離れ、エッジに向かう方向を指します。 DHCPv4コンテキストでは、これは通常、DHCPv4サーバーからDHCPv4クライアントに向かうネットワーク方向を指します。
o "Global VPN"
o 「グローバルVPN」
Global VPN is another name for the default VPN.
グローバルVPNは、デフォルトVPNの別名です。
o "IP address"
o "IPアドレス"
In this document, the term "IP address" refers to an IPv4 IP address.
このドキュメントでは、「IPアドレス」という用語はIPv4 IPアドレスを指します。
o "IP address binding"
o 「IPアドレスのバインド」
An IP address binding is the information that a DHCPv4 server keeps regarding the relationship between a DHCPv4 client and an IP address. This includes the identity of the DHCPv4 client and the expiration time, if any, of any lease that client has on a particular IP address. In some contexts, this may include information on IP addresses that are currently associated with DHCPv4 clients, and in others, it may also include IP addresses with no current association to a DHCPv4 client.
IPアドレスバインディングは、DHCPv4クライアントとIPアドレスの間の関係に関してDHCPv4サーバーが保持する情報です。これには、DHCPv4クライアントのIDと、クライアントが特定のIPアドレスに対して持っているリースの有効期限（ある場合）が含まれます。一部のコンテキストでは、これには現在DHCPv4クライアントに関連付けられているIPアドレスに関する情報が含まれる場合があり、DHCPv4クライアントに現在関連付けられていないIPアドレスが含まれる場合もあります。
o "MAC address"
o "Macアドレス"
In the context of a DHCPv4 message, a Media Access Control (MAC) address consists of the fields: hardware type "htype", hardware length "hlen", and client hardware address "chaddr".
DHCPv4メッセージのコンテキストでは、メディアアクセスコントロール（MAC）アドレスは、ハードウェアタイプ「htype」、ハードウェア長「hlen」、およびクライアントハードウェアアドレス「chaddr」のフィールドで構成されます。
o "upstream"
o "上流の"
Upstream refers to a direction toward the central part of a network and away from the edge. In a DHCPv4 context, this typically refers to a network direction that is away from the DHCPv4 client and toward the DHCPv4 server.
上流とは、ネットワークの中央部分に向かって、エッジから離れる方向を指します。 DHCPv4コンテキストでは、これは通常、DHCPv4クライアントからDHCPv4サーバーに向かうネットワーク方向を指します。
o "stable storage"
o 「安定保管」
Stable storage is used to hold information concerning IP address bindings (among other things) so that this information is not lost in the event of a failure that requires restart of the network element. DHCPv4 servers are typically expected to have high-speed access to stable storage, while relay agents and access concentrators usually do not have access to stable storage, although they may have periodic access to such storage.
ネットワーク要素の再起動が必要な障害が発生した場合にこの情報が失われないように、（特に）IPアドレスバインディングに関する情報を保持するために安定したストレージが使用されます。 DHCPv4サーバーは通常、安定したストレージへの高速アクセスが期待されますが、リレーエージェントとアクセスコンセントレータは通常、安定したストレージへのアクセスはありませんが、定期的にそのようなストレージへのアクセスがある場合があります。
o "xid"
o 「xid」
Transaction-id. The term "xid" refers to the DHCPv4 field containing the transaction-id of the message.
トランザクションID。 「xid」という用語は、メッセージのトランザクションIDを含むDHCPv4フィールドを指します。
The goal of this document is to provide a lightweight protocol for an access concentrator or other network element (such as a DHCP relay agent) to retrieve IP address binding information available in the DHCPv4 server. The protocol should also allow an access concentrator or DHCP relay agent to retrieve consolidated IP address binding information for either the entire access concentrator or a single connection/circuit. Throughout the discussion below, everything that applies to an access concentrator also applies to a DHCP relay agent.
このドキュメントの目的は、アクセスコンセントレータまたは他のネットワーク要素（DHCPリレーエージェントなど）がDHCPv4サーバーで利用可能なIPアドレスバインディング情報を取得するための軽量プロトコルを提供することです。このプロトコルでは、アクセスコンセントレータまたはDHCPリレーエージェントが、アクセスコンセントレータ全体または単一の接続/回線の統合IPアドレスバインディング情報を取得できるようにする必要もあります。以下の説明全体を通して、アクセスコンセントレータに適用されるすべてのものがDHCPリレーエージェントにも適用されます。
The existing data-driven approach required by [RFC4388] means that the Leasequeries can only be performed after an access concentrator receives data. To implement antispoofing, the concentrator must drop messages for each client until it gets lease information from the DHCPv4 server for that client. If an access concentrator finishes the Leasequeries before it starts receiving data, then there is no need to drop legitimate messages. In this way, outage time may be reduced.
[RFC4388]が必要とする既存のデータ駆動型アプローチは、リースクエリはアクセスコンセントレータがデータを受信した後にのみ実行できることを意味します。スプーフィング対策を実装するには、コンセントレータはDHCPv4サーバーからそのクライアントのリース情報を取得するまで、各クライアントのメッセージをドロップする必要があります。アクセスコンセントレータがデータの受信を開始する前にLeasequeriesを終了する場合、正当なメッセージをドロップする必要はありません。このようにして、停止時間を短縮できます。
The result of a single Leasequery should be cached, whether that results in a positive or negative cache, in order to remember that the Leasequery was performed. This caching is required to limit the traffic imposed upon a DHCPv4 server by Leasequeries for information already received.
Leasequeryが実行されたことを思い出すために、単一のLeasequeryの結果は、それがポジティブまたはネガティブキャッシュをもたらすかどうかに関係なく、キャッシュされるべきです。このキャッシュは、既に受信した情報のリースクエリによってDHCPv4サーバーに課されるトラフィックを制限するために必要です。
These caches not only consume precious resources, they also need to be managed. Hence, they should be avoided as much as possible. One of the goals of the DHCPv4 Bulk Leasequery is to reduce the need for this sort of caching.
これらのキャッシュは貴重なリソースを消費するだけでなく、管理する必要もあります。したがって、それらはできるだけ回避する必要があります。 DHCPv4一括リースクエリの目標の1つは、この種のキャッシュの必要性を減らすことです。
If antispoofing is not done in the fast path, it will become a bottleneck and may lead to denial of service of the access concentrator. The Leasequeries should make it possible to do antispoofing in the fast path.
高速パスでスプーフィング対策が行われていない場合、ボトルネックになり、アクセスコンセントレータのサービス拒否につながる可能性があります。 Leasequeriesは、高速パスでスプーフィング対策を実行できるようにする必要があります。
It may be that a network element is able to periodically save its entire list of assigned IP addresses to some form of stable storage. In this case, it will wish to recover all of the updates to this information without duplicating the information it has recovered from its own stable storage.
ネットワーク要素が、割り当てられたIPアドレスのリスト全体を何らかの形式の安定したストレージに定期的に保存できる可能性があります。この場合、自身の安定したストレージから回復した情報を複製せずに、この情報に対するすべての更新を回復したいとします。
Bulk Leasequery allows the specification of a query-start-time as well as a query-end-time. Use of query times allows a network element that periodically commits information to stable storage to recover just what it lost since the last commit.
一括リースクエリでは、クエリの開始時間とクエリの終了時間を指定できます。クエリ時間を使用すると、情報を定期的に安定したストレージにコミットして、最後のコミット以降に失ったものだけを回復するネットワーク要素が可能になります。
The DHCPv4 Bulk Leasequery protocol is modeled on the existing individual DHCPv4 Leasequery protocol in [RFC4388] as well as related work on DHCPv6 Bulk Leasequery [RFC5460]. A Bulk Leasequery requestor opens a TCP connection to a DHCPv4 server using the DHCPv4 port 67. 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 DHCPv4 server. No relaying of Bulk Leasequery messages is specified.
DHCPv4バルクリースクエリプロトコルは、[RFC4388]の既存の個々のDHCPv4リースクエリプロトコル、およびDHCPv6バルクリースクエリ[RFC5460]での関連作業に基づいてモデル化されています。一括リースクエリリクエスタは、DHCPv4ポート67を使用してDHCPv4サーバーへのTCP接続を開きます。これは、リースクエリリクエスタが構成またはその他の方法で利用可能なサーバーIPアドレスを持ち、DHCPv4へのユニキャストIP到達可能性があることを意味しますサーバ。一括リースクエリメッセージのリレーは指定されていません。
After establishing a connection, the requestor sends a DHCPBULKLEASEQUERY message over the connection.
接続を確立した後、リクエスタは接続を介してDHCPBULKLEASEQUERYメッセージを送信します。
The server uses the message type and additional data in the DHCPv4 DHCPBULKLEASEQUERY message to identify any relevant bindings.
サーバーは、DHCPv4 DHCPBULKLEASEQUERYメッセージのメッセージタイプと追加データを使用して、関連するバインディングを識別します。
In order to support some query types, servers may have to maintain additional data structures or otherwise be able to locate bindings that have been requested by the Leasequery requestor.
一部のクエリタイプをサポートするために、サーバーは追加のデータ構造を維持する必要があるか、そうでなければLeasequeryリクエスタによって要求されたバインディングを見つけることができる必要があります。
Relevant bindings are returned in DHCPv4 messages with either the DHCPLEASEACTIVE message type for an IP address with a currently active lease or, in some situations, a DHCPLEASEUNASSIGNED message type for an IP address that is controlled by the DHCPv4 server but is not actively leased by a DHCPv4 client at the present time.
関連するバインディングは、現在アクティブなリースを持つIPアドレスのDHCPLEASEACTIVEメッセージタイプ、または状況によっては、DHCPv4サーバーによって制御されているが、現時点でのDHCPv4クライアント。
The Bulk Leasequery protocol is designed to provide an external entity with information concerning existing DHCPv4 IPv4 address bindings managed by the DHCPv4 server. When complete, the DHCPv4 server will send a DHCPLEASEQUERYDONE message. If a connection is lost while processing a Bulk Leasequery, the Bulk Leasequery must be retried as there is no provision for determining the extent of data already received by the requestor for a Bulk Leasequery.
Bulk Leasequeryプロトコルは、DHCPv4サーバーによって管理される既存のDHCPv4 IPv4アドレスバインディングに関する情報を外部エンティティに提供するように設計されています。完了すると、DHCPv4サーバーはDHCPLEASEQUERYDONEメッセージを送信します。 Bulk Leasequeryの処理中に接続が失われた場合、Bulk Leasequeryのリクエスタによってすでに受信されたデータの範囲を決定するための規定がないため、Bulk Leasequeryを再試行する必要があります。
Bulk Leasequery supports queries by MAC address and by Client Identifier in a way similar to [RFC4388]. The Bulk Leasequery protocol also adds several new queries.
Bulk Leasequeryは、[RFC4388]と同様の方法で、MACアドレスとクライアントIDによるクエリをサポートしています。 Bulk Leasequeryプロトコルは、いくつかの新しいクエリも追加します。
o Query by Relay Identifier
o リレー識別子によるクエリ
This query asks a server for the bindings associated with a specific relay agent; the relay agent is identified by a Relay Agent Identifier carried in a Relay-ID sub-option [RFC6925]. Relay agents can include this sub-option while relaying messages to DHCPv4 servers. Servers can retain the Relay-ID and associate it with bindings made on behalf of the relay agent's clients. The bindings returned are only those for DHCPv4 clients with a currently active binding.
このクエリは、特定のリレーエージェントに関連付けられているバインディングをサーバーに要求します。リレーエージェントは、Relay-IDサブオプション[RFC6925]に含まれるリレーエージェント識別子によって識別されます。リレーエージェントは、メッセージをDHCPv4サーバーにリレーするときにこのサブオプションを含めることができます。サーバーは、Relay-IDを保持し、それをリレーエージェントのクライアントに代わって作成されたバインディングに関連付けることができます。返されるバインディングは、現在アクティブなバインディングを持つDHCPv4クライアントのバインディングのみです。
o Query by Remote ID
o リモートIDによるクエリ
This query asks a server for the bindings associated with a relay agent Remote ID sub-option [RFC3046] value. The bindings returned are only those for DHCPv4 clients with a currently active binding.
このクエリは、リレーエージェントのリモートIDサブオプション[RFC3046]の値に関連付けられているバインディングをサーバーに要求します。返されるバインディングは、現在アクティブなバインディングを持つDHCPv4クライアントのバインディングのみです。
o Query for All Configured IP Addresses
o すべての構成済みIPアドレスのクエリ
This query asks a server for information concerning all IP addresses configured in that DHCPv4 server by specifying no other type of query. In this case, the bindings returned are for all configured IP addresses, whether or not they contain a currently active binding to a DHCPv4 client, since one point of this type of query is to update an existing database with changes after a particular point in time.
このクエリは、他の種類のクエリを指定せずに、そのDHCPv4サーバーで構成されているすべてのIPアドレスに関する情報をサーバーに要求します。この場合、返されるバインディングは、DHCPv4クライアントへの現在アクティブなバインディングが含まれているかどうかに関係なく、構成されたすべてのIPアドレスに対するものです。このタイプのクエリの1つのポイントは、特定の時点の後に既存のデータベースを変更して更新するためです。 。
Any of the above queries can be qualified by the specification of a query-start-time or a query-end-time (or both). When these timers are used as qualifiers, they indicate that a binding should be included if it changed on or after the query-start-time and on or before the query-end-time.
上記のクエリはいずれも、クエリ開始時間またはクエリ終了時間（あるいはその両方）の指定によって修飾できます。これらのタイマーが修飾子として使用されている場合、それらは、クエリ開始時刻以降、およびクエリ終了時刻以前に変更された場合にバインディングを含める必要があることを示します。
In addition, any of the above queries can be qualified by the specification of a VPN-ID option [RFC6607] to select the VPN on which the query should be processed. The VPN-ID option is also extended to allow queries across all available VPNs. In the absence of any VPN-ID option, only the default (global) VPN is used to satisfy the query.
さらに、VPN-IDオプション[RFC6607]を指定して上記のクエリを修飾し、クエリを処理するVPNを選択できます。 VPN-IDオプションも拡張され、使用可能なすべてのVPNでクエリを実行できるようになりました。 VPN-IDオプションがない場合、デフォルト（グローバル）VPNのみがクエリを満たすために使用されます。
Bulk Leasequery can be seen as an extension of the existing UDP Leasequery protocol [RFC4388]. This section clarifies the relationship between the two protocols.
バルクリースクエリは、既存のUDPリースクエリプロトコル[RFC4388]の拡張機能と見なすことができます。このセクションでは、2つのプロトコルの関係を明らかにします。
The Bulk Leasequery TCP connection is only designed to handle the DHCPBULKLEASEQUERY request. It is not intended as an alternative DHCPv4 communication option for clients seeking other DHCPv4 services. DHCPv4 address allocation could not be performed over a TCP connection in any case, as a TCP connection requires an IP address and no IPv4 address exists prior to a successful DHCPv4 address allocation exchange. In addition, the existing DHCPv4 UDP transmission regime is implemented in untold millions of devices deployed worldwide, and complicating DHCPv4 services with alternative transmission approaches (even if it were possible) would be worse than any perceived benefit to doing so.
Bulk Leasequery TCP接続は、DHCPBULKLEASEQUERY要求を処理するようにのみ設計されています。他のDHCPv4サービスを求めるクライアントのための代替DHCPv4通信オプションとしては意図されていません。 TCP接続にはIPアドレスが必要であり、DHCPv4アドレス割り当ての交換が成功する前にIPv4アドレスが存在しないため、TCPv接続を介してDHCPv4アドレス割り当てを実行できませんでした。さらに、既存のDHCPv4 UDP送信体制は、世界中に展開されている数百万のデバイスに実装されており、DHCPv4サービスを（可能な場合でも）代替の送信アプローチで複雑にすることは、そうすることによる認識されている利点よりも悪いでしょう。
Two of the query types introduced in the UDP Leasequery protocol can be used in the Bulk Leasequery protocol -- Query by MAC address and Query by Client-identifier.
UDP Leasequeryプロトコルで導入された2つのクエリタイプは、Bulk Leasequeryプロトコルで使用できます。MACアドレスによるクエリとクライアント識別子によるクエリです。
The contents of the reply messages are similar between the existing UDP Leasequery protocol and the Bulk Leasequery protocol, though more information is returned in the Bulk Leasequery messages.
応答メッセージの内容は、既存のUDP LeasequeryプロトコルとBulk Leasequeryプロトコルの間で類似していますが、Bulk Leasequeryメッセージでより多くの情報が返されます。
One change in behavior for these existing queries is required when Bulk Leasequery is used. Sections 6.1, 6.4.1, and 6.4.2 of [RFC4388] specify the use of an associated-ip option in DHCPLEASEACTIVE messages in cases where multiple bindings were found. When Bulk Leasequery is used, this mechanism is not necessary; a server returning multiple bindings simply does so directly as specified in this document. The associated-ip option MUST NOT appear in Bulk Leasequery replies.
Bulk Leasequeryを使用する場合、これらの既存のクエリの動作を1つ変更する必要があります。 [RFC4388]のセクション6.1、6.4.1、6.4.2は、複数のバインディングが見つかった場合のDHCPLEASEACTIVEメッセージでassociated-ipオプションの使用を指定しています。 Bulk Leasequeryを使用する場合、このメカニズムは必要ありません。複数のバインディングを返すサーバーは、このドキュメントで指定されているように、単純に直接バインドします。 associated-ipオプションは、Bulk Leasequery応答に表示してはなりません（MUST NOT）。
Implementors should note that the TCP message framing defined in Section 6.1 is not compatible with the UDP message format. If a TCP-framed request is sent as a UDP message, it may not be valid, because protocol fields will be offset by the message-size prefix.
実装者は、セクション6.1で定義されたTCPメッセージフレーミングがUDPメッセージ形式と互換性がないことに注意する必要があります。 TCPフレーム化された要求がUDPメッセージとして送信される場合、プロトコルフィールドはメッセージサイズのプレフィックスによってオフセットされるため、有効ではない可能性があります。
The use of TCP for the Bulk Leasequery protocol permits multiple messages to be sent from one end of the connection to the other without requiring a request/response paradigm as does UDP DHCPv4 [RFC2131]. The receiver needs to be able to determine the size of each message it receives. Two octets containing the message size in network byte order are prepended to each DHCPv4 message sent on a Bulk Leasequery TCP connection. The two message-size octets 'frame' each DHCPv4 message.
Bulk LeasequeryプロトコルにTCPを使用すると、UDP DHCPv4 [RFC2131]のように要求/応答パラダイムを必要とせずに、接続の一端から他端に複数のメッセージを送信できます。受信者は、受信する各メッセージのサイズを判別できる必要があります。ネットワークバイトオーダーのメッセージサイズを含む2つのオクテットが、Bulk Leasequery TCP接続で送信される各DHCPv4メッセージに付加されます。 2つのメッセージサイズのオクテットは、各DHCPv4メッセージを「フレーム」します。
The maximum message size is 65535 octets.
最大メッセージサイズは65535オクテットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message-size | op (1) | htype (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hlen (1) | hops (1) | .... |
+---------------+---------------+ +
| |
. remainder of DHCPv4 message,
. from Figure 1 of [RFC2131] .
. .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
message-size the number of octets in the message that follows, as a 16-bit unsigned integer in network byte order.
message-size続くメッセージのオクテット数。ネットワークバイトオーダーの16ビット符号なし整数として。
All other fields are as specified in DHCPv4 [RFC2131].
他のすべてのフィールドは、DHCPv4 [RFC2131]で指定されているとおりです。
Figure 2: Format of a DHCPv4 Message in TCP
図2：TCPでのDHCPv4メッセージのフォーマット
The intent in using this format is that code that currently knows how to deal with sending or receiving a message in [RFC2131] format will easily be able to deal with the message contained in the TCP framing.
この形式を使用する意図は、[RFC2131]形式でメッセージを送受信する方法を現在知っているコードが、TCPフレーミングに含まれるメッセージを簡単に処理できるようにすることです。
The existing messages DHCPLEASEUNASSIGNED and DHCPLEASEACTIVE are used as the value of the dhcp-message-type option to indicate an IP address that is currently not leased or currently leased to a DHCPv4 client, respectively [RFC4388].
既存のメッセージDHCPLEASEUNASSIGNEDおよびDHCPLEASEACTIVEは、dhcp-message-typeオプションの値として使用され、現在DHCPv4クライアントに現在リースされていないか、現在リースされているIPアドレスを示します[RFC4388]。
Additional options have also been defined to enable the Bulk Leasequery protocol to communicate useful information to the requestor.
Bulk Leasequeryプロトコルがリクエスタに有用な情報を伝達できるように、追加のオプションも定義されています。
The dhcp-message-type option (option 53) from Section 9.6 of [RFC2132] requires new values. The values of these message types are shown below in an extension of the table from Section 9.6 of [RFC2132]:
[RFC2132]のセクション9.6のdhcp-message-typeオプション（オプション53）には、新しい値が必要です。これらのメッセージタイプの値を、[RFC2132]のセクション9.6の表の拡張部分に以下に示します。
Value Message Type
----- ------------
14 DHCPBULKLEASEQUERY
15 DHCPLEASEQUERYDONE
The status-code option allows a machine-readable value to be returned regarding the status of a DHCPBULKLEASEQUERY request.
status-codeオプションを使用すると、DHCPBULKLEASEQUERYリクエストのステータスに関する機械可読な値を返すことができます。
This option has two possible scopes when used with Bulk 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 or DHCPLEASEUNASSIGNED. It refers to the message stream related to an entire request if the value of the dhcp-message-type is DHCPLEASEQUERYDONE.
このオプションは、Bulk Leasequeryと組み合わせて使用すると、表示されるコンテキストに応じて、2つのスコープを持つ可能性があります。 dhcp-message-typeの値がDHCPLEASEACTIVEまたはDHCPLEASEUNASSIGNEDである場合は、単一のLeasequery応答の情報を参照します。 dhcp-message-typeの値がDHCPLEASEQUERYDONEの場合、リクエスト全体に関連するメッセージストリームを指します。
The code for this option is 151. The length of this option is a minimum of 1 octet.
このオプションのコードは151です。このオプションの長さは1オクテット以上です。
Status Status
Code Len Code Message
+------+------+------+------+------+-- --+-----+
| 151 | n+1 |status| s1 | s2 | ... | sn |
+------+------+------+------+------+-- --+-----+
The status-code is indicated in one octet as defined in the table below. The Status Message is an optional UTF-8-encoded text string suitable for display to an end user. This text string MUST NOT contain a termination character (e.g., a null). The Len field describes the length of the Status Message without any terminator character. Null characters MUST NOT appear in the Status Message string, and it is a protocol violation for them to appear in any position in the Status Message, including at the end.
ステータスコードは、次の表で定義されているように1オクテットで示されます。ステータスメッセージは、エンドユーザーへの表示に適したオプションのUTF-8エンコードテキスト文字列です。このテキスト文字列には、終了文字（nullなど）を含めてはなりません（MUST NOT）。 Lenフィールドは、ターミネータ文字なしのステータスメッセージの長さを示します。ステータスメッセージ文字列にヌル文字を含めることはできません。また、ステータスメッセージの末尾を含め、任意の位置に表示されるのはプロトコル違反です。
Name Status Code Description
---- ----------- -----------
Success 000 Success. Also signaled by absence of
a status-code option.
UnspecFail 001 Failure, reason unspecified.
UnspecFail 001失敗、理由は不明。
QueryTerminated 002 Indicates that the server is unable to perform a query or has prematurely terminated the query for some reason (which should be communicated in the text message).
QueryTerminated 002サーバーがクエリを実行できないか、なんらかの理由でクエリを早期に終了したことを示します（テキストメッセージで通知する必要があります）。
MalformedQuery 003 The query was not understood.
MalformedQuery 003クエリは理解されませんでした。
NotAllowed 004 The query or request was understood but was not allowed in this context.
NotAllowed 004クエリまたはリクエストは理解されましたが、このコンテキストでは許可されませんでした。
A status-code option MAY appear in the options field of a DHCPv4 message. If the status-code option does not appear, it is assumed that the operation was successful. The status-code option SHOULD NOT appear in a message that is successful unless there is some text string that needs to be communicated to the requestor.
ステータスコードオプションは、DHCPv4メッセージのオプションフィールドに表示される場合があります。 status-codeオプションが表示されない場合は、操作が成功したと見なされます。ステータスコードオプションは、リクエスタに通知する必要のあるテキスト文字列がない限り、成功したメッセージに表示されるべきではありません（SHOULD NOT）。
The base-time option is the current time the message was created to be sent by the DHCPv4 server to the requestor of the Bulk Leasequery. This MUST be an absolute time. All of the other time-based options in the reply message are relative to this time, including the dhcp-lease-time [RFC2132] and client-last-transaction-time [RFC4388]. This time is in the context of the DHCPv4 server that placed this option in a message.
base-timeオプションは、DHCPv4サーバーによってBulk Leasequeryの要求者に送信されるメッセージが作成された現在の時刻です。これは絶対時間でなければなりません。 dhcp-lease-time [RFC2132]およびclient-last-transaction-time [RFC4388]を含む、応答メッセージの他の時間ベースのオプションはすべて、この時間に関連しています。今回は、メッセージにこのオプションを配置したDHCPv4サーバーのコンテキストです。
This is an unsigned integer in network byte order.
これは、ネットワークバイトオーダーの符号なし整数です。
The code for this option is 152. The length of this option is 4 octets.
このオプションのコードは152です。このオプションの長さは4オクテットです。
DHCPv4 Server
Code Len base-time
+-----+-----+-----+-----+-----+-----+
| 152 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
The start-time-of-state option allows the receiver to determine the time at which the IP address made the transition into its current state.
start-time-of-stateオプションを使用すると、レシーバーはIPアドレスが現在の状態に移行した時刻を判別できます。
This MUST NOT be an absolute time, which is equivalent to saying that this MUST NOT be an absolute number of seconds since January 1, 1970. Instead, this MUST be the unsigned integer number of seconds from the time the IP address transitioned its current state to the time specified in the base-time option in the same message.
これは絶対時間であってはなりません。これは、1970年1月1日からの絶対秒数であってはならないということと同じです。代わりに、IPアドレスが現在の状態に遷移した時間からの符号なし整数秒数でなければなりません。同じメッセージのbase-timeオプションで指定された時刻に。
This is an unsigned integer in network byte order.
これは、ネットワークバイトオーダーの符号なし整数です。
The code for this option is 153. The length of this option is 4 octets.
このオプションのコードは153です。このオプションの長さは4オクテットです。
Seconds in the past
Code Len from base-time
+-----+-----+-----+-----+-----+-----+
| 153 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
The query-start-time option specifies a start query time to the DHCPv4 server. If specified, only bindings that have changed on or after the query-start-time should be included in the response to the query.
query-start-timeオプションは、DHCPv4サーバーへの開始クエリ時間を指定します。指定した場合、query-start-time以降に変更されたバインディングのみをクエリへの応答に含める必要があります。
The requestor MUST determine the query-start-time using lease information it has received from the DHCPv4 server. This MUST be an absolute time in the DHCPv4 server's context (see Section 7.4).
リクエスタは、DHCPv4サーバーから受信したリース情報を使用してquery-start-timeを決定する必要があります。これはDHCPv4サーバーのコンテキストでの絶対時間でなければなりません（セクション7.4を参照）。
Typically (though this is not a requirement), the query-start-time option will contain the value most recently received in a base-time option by the requestor, as this will indicate the last successful communication with the DHCP server.
通常、これは必須ではありませんが、クエリ開始時刻オプションには、リクエスタがベースタイムオプションで最後に受信した値が含まれます。これは、DHCPサーバーとの最後の正常な通信を示すためです。
This MUST be an absolute time.
これは絶対時間でなければなりません。
This is an unsigned integer in network byte order.
これは、ネットワークバイトオーダーの符号なし整数です。
The code for this option is 154. The length of this option is 4 octets.
このオプションのコードは154です。このオプションの長さは4オクテットです。
DHCPv4 Server
Code Len query-start-time
+-----+-----+-----+-----+-----+-----+
| 154 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
The query-end-time option specifies an end query time to the DHCPv4 server. If specified, only bindings that have changed on or before the query-end-time should be included in the response to the query.
query-end-timeオプションは、DHCPv4サーバーへの終了クエリ時間を指定します。指定した場合、query-end-timeまたはそれ以前に変更されたバインディングのみをクエリへの応答に含める必要があります。
The requestor MUST determine the query-end-time based on lease information it has received from the DHCPv4 server. This MUST be an absolute time in the context of the DHCPv4 server.
リクエスタは、DHCPv4サーバーから受信したリース情報に基づいて、クエリの終了時間を決定する必要があります。これは、DHCPv4サーバーのコンテキストでは絶対時間でなければなりません。
In the absence of information to the contrary, the requestor SHOULD assume that the time context of the DHCPv4 server is identical to the time context of the requestor (see Section 7.4).
反対の情報がない場合、リクエスタは、DHCPv4サーバーの時間コンテキストがリクエスタの時間コンテキストと同じであると想定する必要があります（セクション7.4を参照）。
This is an unsigned integer in network byte order.
これは、ネットワークバイトオーダーの符号なし整数です。
The code for this option is 155. The length of this option is 4 octets.
このオプションのコードは155です。このオプションの長さは4オクテットです。
DHCPv4 Server
Code Len query-end-time
+-----+-----+-----+-----+-----+-----+
| 155 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
The dhcp-state option allows greater detail to be returned than allowed by the DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types.
dhcp-stateオプションを使用すると、DHCPLEASEACTIVEおよびDHCPLEASEUNASSIGNEDメッセージタイプで許可されるよりも詳細な情報を返すことができます。
The code for this option is 156. The length of this option is 1 octet.
このオプションのコードは156です。このオプションの長さは1オクテットです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 156 | Length | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
156 The option code.
156オプションコード。
Length The option length, 1 octet.
長さオプションの長さ、1オクテット。
State The state of the IP address.
状態IPアドレスの状態。
Value State
----- -----
1 AVAILABLE Address is available to local DHCPv4 server
2 ACTIVE Address is assigned to a DHCPv4 client
3 EXPIRED Lease has expired
4 RELEASED Lease has been released by DHCPv4 client
5 ABANDONED Server or client flagged address as unusable
6 RESET Lease was freed by some external agent
7 REMOTE Address is available to a remote DHCPv4 server
8 TRANSITIONING Address is moving between states
Note that some of these states may be transient and may not appear in normal use. A DHCPv4 server MUST implement at least the AVAILABLE and ACTIVE states and SHOULD implement at least the ABANDONED and RESET states.
これらの状態の一部は一時的な場合があり、通常の使用では表示されない場合があることに注意してください。 DHCPv4サーバーは、少なくともAVAILABLEおよびACTIVE状態を実装する必要があり、少なくともABANDONEDおよびRESET状態を実装する必要があります。
Note the states AVAILABLE and REMOTE are relative to the current server. An address that is available to the current server should show AVAILABLE on that server, and if another server is involved with that address as well, it should show as REMOTE on that other server.
AVAILABLEとREMOTEの状態は、現在のサーバーに関連しています。現在のサーバーで使用できるアドレスは、そのサーバーでAVAILABLEと表示され、そのアドレスに別のサーバーが関係している場合は、そのサーバーでREMOTEと表示されます。
The dhcp-state option SHOULD contain ACTIVE when it appears in a DHCPLEASEACTIVE message. A DHCPv4 server MAY choose to not send a dhcp-state option in a DHCPLEASEACTIVE message, and a requestor SHOULD assume that the dhcp-state is ACTIVE if no dhcp-state option appears in a DHCPLEASEACTIVE message.
DHCPLEASEACTIVEメッセージに表示される場合、dhcp-stateオプションにはACTIVEを含める必要があります（SHOULD）。 DHCPv4サーバーは、DHCPLEASEACTIVEメッセージでdhcp-stateオプションを送信しないことを選択できます。リクエスタは、DHCPLEASEACTIVEメッセージにdhcp-stateオプションが表示されない場合、dhcp-stateがACTIVEであると想定する必要があります。
The reference to local and remote relate to possible use in an environment that includes multiple servers cooperating to provide an increased availability solution. In this case, an IP address with the state of AVAILABLE is available to the local server, while one with the state of REMOTE is available to a remote server. Usually, an IP address that is AVAILABLE on one server would be REMOTE on any remote server. The TRANSITIONING state is also likely to be useful in multiple server deployments, where sometimes one server must interlock a state change with one or more other servers. Should a Bulk Leasequery need to send information concerning the state of the IP address during this period, it SHOULD use the TRANSITIONING state, since the IP address is likely to be neither ACTIVE or AVAILABLE.
ローカルおよびリモートへの言及は、可用性の向上ソリューションを提供するために協力する複数のサーバーを含む環境での可能な使用に関連しています。この場合、AVAILABLEの状態のIPアドレスはローカルサーバーで使用できますが、REMOTEの状態のIPアドレスはリモートサーバーで使用できます。通常、1つのサーバーで使用可能なIPアドレスは、どのリモートサーバーでもREMOTEです。 TRANSITIONING状態は、複数のサーバーの展開でも役立つ可能性があります。この場合、1つのサーバーが他の1つ以上のサーバーと状態変更を連動させる必要がある場合があります。 Bulk Leasequeryがこの期間中にIPアドレスの状態に関する情報を送信する必要がある場合、IPアドレスはACTIVEでもAVAILABLEでもない可能性が高いため、TRANSITIONING状態を使用する必要があります。
There is no requirement for the state of an IP address to transition in a well-defined way from state to state. To put this another way, you cannot draw a simple state transition graph for the states of an IP address, and the requestor of a Leasequery MUST NOT depend on one certain state always following a particular previous state. While a state transition diagram can be drawn, it would be fully connected and therefore conveys no useful information. Every state can (at times) follow every other state.
IPアドレスの状態が明確に定義された方法で状態から状態に移行する必要はありません。別の言い方をすれば、IPアドレスの状態の単純な状態遷移グラフを描画することはできません。また、リースクエリのリクエスタは、常に特定の以前の状態に続く特定の状態に依存してはなりません。状態遷移図を描くことはできますが、完全に接続されているため、有用な情報は伝達されません。すべての状態は（時々）他のすべての状態に従うことができます。
The data-source option contains information about the source of the data in a DHCPLEASEACTIVE or a DHCPLEASEUNASSIGNED message. It SHOULD be used when there are two or more servers that might have information about a particular IP address binding. Frequently, two servers work together to provide an increased availability solution for the DHCPv4 service, and in these cases, both servers will respond to Bulk Leasequery requests for the same IP address. When one server is working with another server and both may respond with information about the same IP address, each server SHOULD return the data-source option with the other information provided about the IP address.
data-sourceオプションには、DHCPLEASEACTIVEまたはDHCPLEASEUNASSIGNEDメッセージ内のデータのソースに関する情報が含まれています。特定のIPアドレスバインディングに関する情報を持つ可能性のある2つ以上のサーバーがある場合に使用する必要があります。多くの場合、2台のサーバーが連携してDHCPv4サービスの可用性を向上させるソリューションを提供します。この場合、両方のサーバーが同じIPアドレスの一括リースクエリ要求に応答します。あるサーバーが別のサーバーと連携しており、両方が同じIPアドレスに関する情報で応答する可能性がある場合、各サーバーは、IPアドレスについて提供された他の情報とともにデータソースオプションを返す必要があります。
The data contained in this option will allow an external process to better discriminate between the information provided by each of the servers servicing this IPv4 address.
このオプションに含まれるデータにより、外部プロセスは、このIPv4アドレスにサービスを提供する各サーバーによって提供される情報をより適切に区別できます。
The code for this option is 157. The length of this option is 1 octet.
このオプションのコードは157です。このオプションの長さは1オクテットです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 157 | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
157 The option code.
157オプションコード。
Length The option length, 1 octet.
長さオプションの長さ、1オクテット。
Flags The source information for this message.
フラグこのメッセージのソース情報。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| UNA |R|
+-+-+-+-+-+-+-+-+
R: REMOTE flag
R：REMOTEフラグ
remote = 1 local = 0
リモート= 1ローカル= 0
UNA: UNASSIGNED
ONE：未割り当て
The REMOTE flag is used to indicate where the most recent change of state (or other interesting change) concerning this IPv4 address took place. If the value is local, then the change took place on the server from which this message was transmitted. If the value is remote, then the change took place on some other server and was made known to the server from which this message was transmitted.
REMOTEフラグは、このIPv4アドレスに関する最新の状態変化（またはその他の興味深い変化）が発生した場所を示すために使用されます。値がローカルの場合、このメッセージの送信元サーバーで変更が行われました。値がリモートの場合、変更は他のサーバーで行われ、このメッセージの送信元サーバーに通知されました。
If this option was requested and it doesn't appear, the requestor MUST consider that the data-source was local.
このオプションが要求されたが表示されない場合、要求者はデータソースがローカルであると見なさなければならない（MUST）。
Unassigned bits MUST be ignored.
割り当てられていないビットは無視する必要があります。
All of the (sub-)options defined in [RFC6607] carry identical payloads, consisting of a type and additional VSS (Virtual Subnet Selection) information. The existing table is extended (see below) with a new type 254 to allow specification of a type code that indicates that all VPNs are to be used to process the Bulk Leasequery.
[RFC6607]で定義されているすべての（サブ）オプションは、タイプと追加のVSS（仮想サブネット選択）情報で構成される同一のペイロードを伝送します。既存のテーブルは、新しいタイプ254で拡張され（以下を参照）、すべてのVPNを使用して一括リースクエリを処理することを示すタイプコードを指定できるようになっています。
Type VSS Information Format
----------------------------------------------------------
0 Network Virtual Terminal (NVT) ASCII VPN identifier
1 RFC 2685 VPN-ID
CHANGED -> 2-253 Unassigned
NEW -> 254 All VPNs (wildcard)
255 Global, default VPN
DHCPv4 servers that support Bulk Leasequery SHOULD listen for incoming TCP connections on the DHCPv4 server port 67. Implementations MAY offer to make the incoming port configurable, but port 67 MUST be the default. Requestors SHOULD make TCP connections to port 67 and MAY offer to make the destination server port configurable.
Bulk LeasequeryをサポートするDHCPv4サーバーは、DHCPv4サーバーポート67で着信TCP接続をリッスンする必要があります。実装は、着信ポートを構成可能にすることを提案できますが、ポート67がデフォルトでなければなりません（MUST）。リクエスターは、ポート67へのTCP接続を作成する必要があり（SHOULD）、宛先サーバーのポートを構成可能にするように提案できます（MAY）。
This section presents a table of values used to control Bulk Leasequery behavior, including recommended defaults. Implementations MAY make these values configurable. However, configuring too-small timeout values may lead to harmful behavior both to this application as well as to other traffic in the network. As a result, timeout values smaller than the default values are NOT RECOMMENDED.
このセクションでは、推奨されるデフォルトを含め、一括リースクエリの動作を制御するために使用される値の表を示します。実装はこれらの値を構成可能にするかもしれません。ただし、設定するタイムアウト値が小さすぎると、このアプリケーションとネットワーク内の他のトラフィックの両方に悪影響を及ぼす可能性があります。その結果、デフォルト値より小さいタイムアウト値は推奨されません。
Parameter Default Description
--------------------------------------------------------------------
BULK_LQ_DATA_TIMEOUT 300 secs Bulk Leasequery data timeout
for both client and server
(see Sections 7 and 8)
BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections
at the server side (see Section 8.1)
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.
リクエスタは、リースクエリの交換を開始するために、DHCPv4サーバーへのTCP接続を確立しようとします。試行が失敗した場合、リクエスタは再試行してもかまいません。
If Bulk Leasequery is terminated prematurely by a DHCPLEASEQUERYDONE with a status-code option with a 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.
Bulk Leasequeryが、ステータスコードオプションがQueryTerminatedのDHCPLEASEQUERYDONEによって、またはそれが送信された接続の失敗によって、途中で終了した場合、リクエスタは、新しい接続の作成後にリクエストを再試行できます。
Messages from the DHCPv4 server come as multiple responses to a single DHCPBULKLEASEQUERY message. Thus, each DHCPBULKLEASEQUERY request MUST have an xid (transaction-id) unique on the connection on which it is sent. All of the messages that come as a response to that message will contain the same xid as the request. The xid allows the data-streams of two different DHCPBULKLEASEQUERY requests to be demultiplexed by the requestor.
DHCPv4サーバーからのメッセージは、単一のDHCPBULKLEASEQUERYメッセージに対する複数の応答として送信されます。したがって、各DHCPBULKLEASEQUERY要求には、それが送信される接続で一意のxid（transaction-id）が必要です。そのメッセージへの応答として来るすべてのメッセージには、要求と同じxidが含まれます。 xidを使用すると、2つの異なるDHCPBULKLEASEQUERY要求のデータストリームをリクエスタで逆多重化できます。
Bulk Leasequery is designed to create a connection that will transfer the state of some subset (or possibly all) of the IP address bindings from the DHCPv4 server to the requestor. The DHCPv4 server will send all of the requested IPv4 address bindings across this connection with minimal delay after it receives the request. In this context, "all IP address binding information" means information about all IPv4 addresses configured within the DHCPv4 server that meet the specified query criteria. For some query criteria, this may include IP address binding information for IP addresses that may not now have or ever have had an association with a specific DHCPv4 client.
Bulk Leasequeryは、DHCPv4サーバーからリクエスタにIPアドレスバインディングの一部（または場合によってはすべて）の状態を転送する接続を作成するように設計されています。 DHCPv4サーバーは、要求を受信した後、最小限の遅延で、この接続を介して要求されたすべてのIPv4アドレスバインディングを送信します。このコンテキストでは、「すべてのIPアドレスバインディング情報」とは、指定されたクエリ条件を満たすDHCPv4サーバー内で構成されたすべてのIPv4アドレスに関する情報を意味します。一部のクエリ基準の場合、これには、特定のDHCPv4クライアントとの関連付けがない、または関連付けられていないIPアドレスのIPアドレスバインディング情報が含まれる場合があります。
To form the Bulk query, a DHCPv4 request is constructed with a dhcp-message-type of DHCPBULKLEASEQUERY. The query SHOULD have a dhcp-parameter-request-list to inform the DHCPv4 server which DHCPv4 options are of interest to the requestor sending the DHCPBULKLEASEQUERY message. The dhcp-parameter-request-list in a DHCPBULKLEASEQUERY message SHOULD contain the codes for base-time, dhcp-lease-time, start-time-of-state, and client-last-transaction-time.
バルククエリを形成するために、DHCPv4リクエストはDHCPBULKLEASEQUERYのdhcp-message-typeで構築されます。クエリにはdhcp-parameter-request-listがあり、どのDHCPv4オプションがDHCPBULKLEASEQUERYメッセージを送信するリクエスタにとって重要であるかをDHCPv4サーバーに通知する必要があります（SHOULD）。 DHCPBULKLEASEQUERYメッセージのdhcp-parameter-request-listには、base-time、dhcp-lease-time、start-time-of-state、およびclient-last-transaction-timeのコードを含める必要があります。
A DHCPBULKLEASEQUERY request is constructed of one primary query and optionally one or more qualifiers for it.
DHCPBULKLEASEQUERY要求は、1つのプライマリクエリと、オプションで1つ以上の修飾子で構成されます。
The possible primary queries are listed below. Each DHCPBULKLEASEQUERY request MUST contain only one of these primary queries.
可能なプライマリクエリを以下に示します。各DHCPBULKLEASEQUERY要求には、これらのプライマリクエリの1つだけが含まれている必要があります。
o Query by MAC address
o MACアドレスによるクエリ
In a Query by MAC address, the chaddr, htype, and hlen of the DHCPv4 packet are filled in with the values requested.
MACアドレスによるクエリでは、DHCPv4パケットのchaddr、htype、およびhlenに、要求された値が入力されます。
o Query by Client-identifier
o クライアント識別子によるクエリ
In a Query by Client-identifier, a Client-identifier option containing the requested value is included in the DHCPBULKLEASEQUERY request.
クライアント識別子によるクエリでは、要求された値を含むクライアント識別子オプションがDHCPBULKLEASEQUERY要求に含まれています。
o Query by Remote ID
o リモートIDによるクエリ
In a Query by Remote ID, a Remote ID sub-option containing the requested value is included in the relay-agent-information option of the DHCPBULKLEASEQUERY request.
リモートIDによるクエリでは、要求された値を含むリモートIDサブオプションが、DHCPBULKLEASEQUERY要求のrelay-agent-informationオプションに含まれています。
o Query by Relay-ID
o リレーIDによるクエリ
In a Query by Relay-ID, a Relay-ID sub-option [RFC6925] containing the requested value is included in the relay-agent-information option of the DHCPBULKLEASEQUERY request.
リレーIDによるクエリでは、要求された値を含むリレーIDサブオプション[RFC6925]が、DHCPBULKLEASEQUERY要求のリレーエージェント情報オプションに含まれています。
o Query for All Configured IP Addresses
o すべての構成済みIPアドレスのクエリ
A Query for All Configured IP addresses is signaled by the absence of any other primary query.
すべての構成済みIPアドレスのクエリは、他のプライマリクエリがないことによって通知されます。
There are three qualifiers that can be applied to any of the above primary queries. These qualifiers can appear individually or together in any combination, but only one of each can appear.
上記のプライマリクエリのいずれにも適用できる3つの修飾子があります。これらの修飾子は個別に、または組み合わせて表示できますが、表示できるのはそれぞれ1つだけです。
o Query Start Time
o クエリ開始時間
Inclusion of a query-start-time option specifies that only IP address bindings that have changed on or after the time specified in the query-start-time option should be returned.
query-start-timeオプションを含めると、query-start-timeオプションで指定された時刻以降に変更されたIPアドレスバインディングのみが返されることを指定します。
o Query End Time
o クエリ終了時間
Inclusion of a query-end-time option specifies that only IP address bindings that have changed on or before the time specified in the query-end-time option should be returned.
query-end-timeオプションを含めると、query-end-timeオプションで指定された時刻以前に変更されたIPアドレスバインディングのみが返されます。
o VPN-ID
o VPN-ID
If no VPN-ID option appears in the DHCPBULKLEASEQUERY, the default (global) VPN is searched to satisfy the query specified by the DHCPBULKLEASEQUERY. Using the VPN-ID option [RFC6607] allows the requestor to specify a single VPN other than the default VPN. In addition, the VPN-ID option has been extended as part of this document to allow specification that all configured VPNs be searched in order to satisfy the query specified in the DHCPBULKLEASEQUERY.
DHCPBULKLEASEQUERYにVPN-IDオプションが表示されない場合、DHCPBULKLEASEQUERYで指定されたクエリを満たすために、デフォルト（グローバル）VPNが検索されます。 VPN-IDオプション[RFC6607]を使用すると、要求者はデフォルトのVPN以外の単一のVPNを指定できます。さらに、このドキュメントの一部としてVPN-IDオプションが拡張され、DHCPBULKLEASEQUERYで指定されたクエリを満たすために、構成されているすべてのVPNを検索するように指定できるようになりました。
In all cases, any message returned from a DHCPBULKLEASEQUERY request containing information about an IP address for other than the default (global) VPN MUST contain a VPN-ID option in the message.
すべての場合において、デフォルト（グローバル）VPN以外のIPアドレスに関する情報を含むDHCPBULKLEASEQUERY要求から返されるメッセージには、メッセージにVPN-IDオプションが含まれている必要があります。
Use of the query-start-time or the query-end-time options or both can serve to reduce the amount of data transferred over the TCP connection by a considerable amount. Note that the times specified in the query-start-time or query-end-time options are absolute times, not durations offset from "now".
query-start-timeまたはquery-end-timeオプション、あるいはその両方を使用すると、TCP接続を介して転送されるデータの量を大幅に削減できます。 query-start-timeまたはquery-end-timeオプションで指定された時間は絶対時間であり、「現在」からの継続時間オフセットではないことに注意してください。
The TCP connection may become blocked or stop being writable while the requestor is sending its query. Should this happen, the implementation's behavior is controlled by the current value of BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this document, and this value may be overridden by local configuration of the operator.
リクエスタがクエリを送信している間、TCP接続がブロックされるか、書き込みが停止する場合があります。これが発生した場合、実装の動作はBULK_LQ_DATA_TIMEOUTの現在の値によって制御されます。デフォルト値はこのドキュメントの他の場所に記載されており、この値はオペレーターのローカル構成によってオーバーライドされる場合があります。
If this situation is detected, the requestor SHOULD start a timer using the current value of BULK_LQ_DATA_TIMEOUT. If that timer expires, the requestor SHOULD terminate the connection. This timer is completely independent of any TCP timeout established by the TCP protocol connection.
この状況が検出された場合、リクエスタはBULK_LQ_DATA_TIMEOUTの現在の値を使用してタイマーを開始する必要があります（SHOULD）。そのタイマーが時間切れになると、リクエスタは接続を終了する必要があります（SHOULD）。このタイマーは、TCPプロトコル接続によって確立されたTCPタイムアウトから完全に独立しています。
The requestor attempts to read a DHCPv4 Leasequery reply message from the TCP connection.
リクエスターは、TCP接続からDHCPv4 Leasequery応答メッセージを読み取ろうとします。
The TCP connection may stop delivering reply data (i.e., the connection stops being readable). Should this happen, the implementation's behavior is controlled by the current value of BULK_LQ_DATA_TIMEOUT. The default value is given elsewhere in this document, and this value may be overridden by local configuration of the operator.
TCP接続は、応答データの配信を停止する場合があります（つまり、接続は読み取り可能でなくなります）。これが発生した場合、実装の動作はBULK_LQ_DATA_TIMEOUTの現在の値によって制御されます。デフォルト値はこのドキュメントの他の場所に記載されており、この値はオペレーターのローカル構成によってオーバーライドされる場合があります。
If this situation is detected, the requestor SHOULD start a timer using the current value of BULK_LQ_DATA_TIMEOUT. If that timer expires, the requestor SHOULD terminate the connection.
この状況が検出された場合、リクエスタはBULK_LQ_DATA_TIMEOUTの現在の値を使用してタイマーを開始する必要があります（SHOULD）。そのタイマーが時間切れになると、リクエスタは接続を終了する必要があります（SHOULD）。
A single Bulk Leasequery can, and usually will, result in a large number of replies. The requestor MUST be prepared to receive more than one reply with an xid matching a single DHCPBULKLEASEQUERY message from a single DHCPv4 server. If the xid in the received message does not match an outstanding DHCPBULKLEASEQUERY message, the requestor MUST close the TCP connection.
単一の一括リースクエリは、通常、多数の応答を返す可能性があります。リクエスタは、単一のDHCPv4サーバーからの単一のDHCPBULKLEASEQUERYメッセージに一致するxidを持つ複数の応答を受信できるように準備する必要があります。受信したメッセージのxidが未解決のDHCPBULKLEASEQUERYメッセージと一致しない場合、リクエスタはTCP接続を閉じる必要があります。
If the requestor receives more data than it can process, it can simply abort the connection and try again with a more specific request. It can also simply read the TCP connection more slowly and match the rate at which it can digest the information returned in the Bulk Leasequery packets with the rate at which it reads those packets from the TCP connection.
リクエスタが処理できる以上のデータを受信した場合、リクエスタは接続を中止して、より具体的なリクエストで再試行できます。また、TCP接続の読み取り速度を遅くし、Bulk Leasequeryパケットで返された情報をダイジェストできる速度と、TCP接続からパケットを読み取る速度を一致させることもできます。
The DHCPv4 server MUST send a server-identifier option (option 54) in the first response to any DHCPBULKLEASEQUERY message. The DHCPv4 server SHOULD NOT send server-identifier options in subsequent responses to that DHCPBULKLEASEQUERY message. The requestor MUST cache the server-identifier option from the first response and apply it to any subsequent responses.
DHCPv4サーバーは、DHCPBULKLEASEQUERYメッセージへの最初の応答でサーバー識別子オプション（オプション54）を送信する必要があります。 DHCPv4サーバーは、そのDHCPBULKLEASEQUERYメッセージへの後続の応答でサーバー識別子オプションを送信すべきではありません（SHOULD NOT）。リクエスタは、最初の応答からのサーバー識別子オプションをキャッシュし、それを後続の応答に適用する必要があります。
The response messages generated by a DHCPBULKLEASEQUERY request are:
DHCPBULKLEASEQUERY要求によって生成される応答メッセージは次のとおりです。
o DHCPLEASEACTIVE
o DHCPLEASEACTIVE
A Bulk Leasequery will generate DHCPLEASEACTIVE messages containing binding data for bound IP addresses that match the specified query criteria. The IP address that is bound to a DHCPv4 client will appear in the ciaddr field of the DHCPLEASEACTIVE message. The message may contain a non-zero chaddr, htype, hlen, and possibly additional options.
一括リースクエリは、指定されたクエリ条件に一致するバインドされたIPアドレスのバインドデータを含むDHCPLEASEACTIVEメッセージを生成します。 DHCPv4クライアントにバインドされているIPアドレスは、DHCPLEASEACTIVEメッセージのciaddrフィールドに表示されます。メッセージには、ゼロ以外のchaddr、htype、hlen、および場合によっては追加のオプションが含まれることがあります。
o DHCPLEASEUNASSIGNED
o DHCPLEASEUNASSIGNED
Some queries will also generate DHCPLEASEUNASSIGNED messages for IP addresses that match the query criteria. These messages indicate that the IP address is managed by the DHCPv4 server but is not currently bound to any DHCPv4 client. The IP address to which this message refers will appear in the ciaddr field of the DHCPLEASEUNASSIGNED message. A DHCPLEASEUNASSGINED message MAY also contain information about the last DHCPv4 client that was bound to this IP address. The message may contain a non-zero chaddr, htype, hlen, and possibly additional options in this case.
一部のクエリでは、クエリ基準に一致するIPアドレスのDHCPLEASEUNASSIGNEDメッセージも生成されます。これらのメッセージは、IPアドレスがDHCPv4サーバーによって管理されているが、現在どのDHCPv4クライアントにもバインドされていないことを示しています。このメッセージが参照するIPアドレスは、DHCPLEASEUNASSIGNEDメッセージのciaddrフィールドに表示されます。 DHCPLEASEUNASSGINEDメッセージには、このIPアドレスにバインドされた最後のDHCPv4クライアントに関する情報も含まれる場合があります。このメッセージには、0以外のchaddr、htype、hlenが含まれる場合があり、この場合は追加のオプションが含まれる可能性があります。
o DHCPLEASEQUERYDONE
o DHCPLEASEQUERYDONE
A response of DHCPLEASEQUERYDONE indicates that the server has completed its response to the query and that no more messages will be sent in response to the DHCPBULKLEASEQUERY. More details will sometimes be available in the received status-code option in the DHCPLEASEQUERYDONE message. If there is no status-code option in the DHCPLEASEQUERYDONE message, then the query completed successfully.
DHCPLEASEQUERYDONEの応答は、サーバーがクエリへの応答を完了し、DHCPBULKLEASEQUERYへの応答としてこれ以上メッセージが送信されないことを示します。 DHCPLEASEQUERYDONEメッセージの受信されたステータスコードオプションで詳細が得られる場合があります。 DHCPLEASEQUERYDONEメッセージにステータスコードオプションがない場合、クエリは正常に完了しました。
Note that a query that returned no data, that is, a DHCPBULKLEASEQUERY request followed by a DHCPLEASEQUERYDONE response, is considered a successful query in that no errors occurred during the processing. It is not considered an error to have no information to return to a DHCPBULKLEASEQUERY request.
データを返さなかったクエリ、つまりDHCPBULKLEASEQUERY要求の後にDHCPLEASEQUERYDONE応答が続くものは、処理中にエラーが発生しなかったという点で、成功したクエリと見なされます。 DHCPBULKLEASEQUERY要求に戻るための情報がないことは、エラーとは見なされません。
The DHCPLEASEUNKNOWN message MUST NOT appear in a response to a Bulk Leasequery.
DHCPLEASEUNKNOWNメッセージは、Bulk Leasequeryへの応答に表示されてはなりません（MUST NOT）。
The requestor MUST NOT assume that there is any inherent order in the IP address binding information that is sent in response to a DHCPBULKLEASEQUERY. While the base-time will tend to increase monotonically (as it is the current time on the DHCPv4 server), the actual time that any IP address binding information changed is unrelated to the base-time.
リクエスタは、DHCPBULKLEASEQUERYへの応答として送信されるIPアドレスバインディング情報に固有の順序があると想定してはなりません（MUST NOT）。ベースタイムは単調に増加する傾向がありますが（DHCPv4サーバーの現在の時刻であるため）、IPアドレスバインディング情報が変更された実際の時間はベースタイムとは無関係です。
The DHCPLEASEQUERYDONE message always ends a successful DHCPBULKLEASEQUERY request and any unsuccessful DHCPBULKLEASEQUERY requests not terminated by a dropped connection. After receiving a DHCPLEASEQUERYDONE from a server, the requestor MAY close the TCP connection to that server if no other DHCPBULKLEASEQUERY is outstanding on that TCP connection.
DHCPLEASEQUERYDONEメッセージは常に、成功したDHCPBULKLEASEQUERY要求と、切断された接続によって終了されなかった失敗したDHCPBULKLEASEQUERY要求を終了します。サーバーからDHCPLEASEQUERYDONEを受信した後、そのTCP接続で他のDHCPBULKLEASEQUERYが未解決である場合、リクエスタはそのサーバーへのTCP接続を閉じることができます（MAY）。
The DHCPv4 Leasequery protocol [RFC4388] uses the associated-ip option as an indicator that multiple bindings were present in response to a single DHCPv4 client-based query. For Bulk Leasequery, a separate message is returned for each binding, so the associated-ip option is not used.
DHCPv4 Leasequeryプロトコル[RFC4388]は、関連するIPオプションを、単一のDHCPv4クライアントベースのクエリに応答して複数のバインディングが存在したことを示すインジケータとして使用します。 Bulk Leasequeryの場合、バインディングごとに個別のメッセージが返されるため、関連付けられたIPオプションは使用されません。
Bulk Leasequery requests may be made to a DHCPv4 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 Bulk Leasequery response, and in the situation where multiple DHCPv4 servers are queried, the situation becomes even more complex.
バルクリースクエリ要求は、絶対時刻が要求元のローカル時刻と同期していない可能性があるDHCPv4サーバーに対して行われる場合があります。したがって、最も単純なBulk Leasequery応答でも少なくとも2つのタイムコンテキストがあり、複数のDHCPv4サーバーが照会される状況では、状況はさらに複雑になります。
If the requestor of a 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 DHCPv4 server.
Bulk Leasequeryのリクエスタが何らかの形式で返されたデータを保存する場合、さまざまな時間値を保存する必要があります。これらの一部はリクエスタのコンテキストでの時間であり、一部はDHCPv4サーバーのコンテキストでの時間です。
When receiving a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message from the DHCPv4 server, the message will contain a base-time option. The time contained in this base-time option is in the context of the DHCPv4 server. As such, it is an ideal time to save and use as input to a DHCPBULKLEASEQUERY in the query-start-time or query-end-time options, should the requestor ever need to issue a DHCPBULKLEASEQUERY message using those options as part of a later query, since those options require a time in the context of the DHCPv4 server.
DHCPv4サーバーからDHCPLEASEACTIVEまたはDHCPLEASEUNASSIGNEDメッセージを受信すると、メッセージにはベースタイムオプションが含まれます。この基本時間オプションに含まれる時間は、DHCPv4サーバーのコンテキストにあります。したがって、リクエスタが後でこれらのオプションを使用してDHCPBULKLEASEQUERYメッセージを発行する必要がある場合は、クエリ開始時間またはクエリ終了時間オプションでDHCPBULKLEASEQUERYへの入力として保存して使用するのが理想的です。これらのオプションはDHCPv4サーバーのコンテキストで時間を必要とするためです。
In addition to saving the base-time for possible future use in a query-start-time or query-end-time option, the base-time 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. These other time values are specified as a offset (duration) from the base-time value and not as an absolute time.
query-start-timeまたはquery-end-timeオプションで将来使用できるようにベース時間を保存することに加えて、ベース時間は、Leasequeryメッセージ内の他の時間を次の値に変換する一部として使用されます。リクエスタのコンテキストで意味があります。これらの他の時間値は、絶対時間としてではなく、基準時間値からのオフセット（期間）として指定されます。
In systems whose clocks are synchronized, perhaps using NTP, the clock skew will usually be zero.
NTPを使用するなど、クロックが同期しているシステムでは、通常、クロックスキューはゼロになります。
A Bulk Leasequery requestor MAY be configured to attempt to connect to and query from multiple DHCPv4 servers in parallel. The DHCPv4 Leasequery specification [RFC4388] includes a discussion about reconciling binding data received from multiple DHCPv4 servers.
Bulk Leasequeryリクエスタは、複数のDHCPv4サーバーに並列に接続して照会するように構成できます（MAY）。 DHCPv4 Leasequery仕様[RFC4388]には、複数のDHCPv4サーバーから受信したバインディングデータの調整に関する説明が含まれています。
In addition, the algorithm in Section 7.6 should be used.
さらに、セクション7.6のアルゴリズムを使用する必要があります。
7.6. Making Sense out of Multiple Responses concerning a Single IPv4 Address
7.6. 単一のIPv4アドレスに関する複数の応答を理解する
Any requestor of an Bulk Leasequery MUST be prepared for multiple responses to arrive for a particular IPv4 address from multiple different DHCPv4 servers. The following algorithm SHOULD be used to decide if the information just received is more up to date (i.e., better) than the best existing information. In the discussion below, the information that is received from a DHCPv4 server about a particular IPv4 address is termed a "record". The times used in the algorithm below SHOULD have been converted into the requestor's context, and the time comparisons SHOULD be performed in a manner consistent with the information in Section 7.4.
Bulk Leasequeryのリクエスタは、複数の異なるDHCPv4サーバーから特定のIPv4アドレスに到達するための複数の応答を準備する必要があります。次のアルゴリズムは、受信したばかりの情報が既存の最良の情報よりも最新である（つまり、より優れている）かどうかを判断するために使用する必要があります（SHOULD）。以下の説明では、特定のIPv4アドレスに関してDHCPv4サーバーから受信した情報を「レコード」と呼びます。以下のアルゴリズムで使用される時間はリクエスタのコンテキストに変換されるべきであり（SHOULD）、時間の比較はセクション7.4の情報と一致する方法で実行されるべきです（SHOULD）。
o If both the existing and the new record contain client-last-transaction-time information, the record with the later client-last-transaction-time is considered better.
o 既存のレコードと新しいレコードの両方にclient-last-transaction-time情報が含まれている場合、client-last-transaction-timeが新しいレコードがより適切であると見なされます。
o If one of the records contains client-last-transaction-time information and the other one doesn't, then compare the client-last-transaction-time in the record that contains it against the other record's start-time-of-state. The record with the later time is considered better.
o 1つのレコードにclient-last-transaction-time情報が含まれ、もう1つのレコードに含まれていない場合、それを含むレコードのclient-last-transaction-timeを他のレコードのstart-time-of-stateと比較します。時間が遅い方が良いとされています。
o If neither record contains client-last-transaction-time information, compare their start-time-of-state information. The record with the later start-time-of-state is considered better.
o どちらのレコードにもclient-last-transaction-time情報が含まれていない場合は、それらのstart-time-of-state情報を比較します。状態の開始時刻が後の方が良いレコードと見なされます。
o If none of the comparisons above yield a clear answer as to which record is later, then compare the value of the REMOTE flag from the data-source option for each record. If the values of the REMOTE flag are different between the two records, the record with the REMOTE flag value of local is considered better.
o 上記のどの比較でも、どちらのレコードが遅いかについて明確な答えが得られない場合は、各レコードのデータソースオプションからのREMOTEフラグの値を比較します。 REMOTEフラグの値が2つのレコード間で異なる場合、REMOTEフラグの値がローカルであるレコードのほうが適していると見なされます。
The above algorithm does not necessarily determine which record is better. In the event that the algorithm is inconclusive with regard to a record that was just received by the requestor, the requestor SHOULD use additional information in the two records to make a determination as to which record is better.
上記のアルゴリズムは、どのレコードがより良いかを必ずしも決定するわけではありません。アルゴリズムがリクエスタによって受信されたばかりのレコードに関して決定的でない場合、リクエスタは2つのレコードの追加情報を使用して、どちらのレコードがより優れているかを判断する必要があります。
Bulk Leasequery requestors may need to make multiple queries in order to recover binding information. A requestor MAY use a single connection to issue multiple queries to a server willing to support them. Each query MUST have a unique xid.
一括Leasequeryリクエスタは、バインディング情報を回復するために複数のクエリを実行する必要がある場合があります。リクエスタは、単一の接続を使用して、サポートする意思のあるサーバーに複数のクエリを発行できます。各クエリには一意のxidが必要です。
A server SHOULD allow configuration of the number of queries that can be processed simultaneously over a single connection. A server SHOULD read the number of queries it is configured to process simultaneously and only read any subsequent queries as current queries are processed.
サーバーは、単一の接続で同時に処理できるクエリの数の設定を許可する必要があります（SHOULD）。サーバーは、同時に処理するように構成されているクエリの数を読み取り、現在のクエリが処理されるときに後続のクエリのみを読み取る必要があります。
A server that is processing multiple queries simultaneously MUST NOT block sending replies on new queries until all replies for the existing query are complete. Requestors need to be aware that replies for multiple queries may be interleaved within the stream of reply messages. Requestors that are not able to process interleaved replies (based on xid) MUST NOT send more than one query over a single connection prior to the completion of the previous query.
複数のクエリを同時に処理しているサーバーは、既存のクエリに対するすべての返信が完了するまで、新しいクエリに対する返信の送信をブロックしてはなりません（MUST NOT）。リクエスタは、複数のクエリに対する応答が応答メッセージのストリーム内にインターリーブされる可能性があることを認識する必要があります。 （xidに基づいて）インタリーブされた応答を処理できないリクエスタは、前のクエリが完了する前に、単一の接続を介して複数のクエリを送信してはなりません（MUST NOT）。
Requestors should be aware that servers are not required to process more than one query over a connection at a time (the limiting case for the configuration described above) and that servers are likely to limit the rate at which they process queries from any one requestor.
リクエスタは、サーバーが接続を介して一度に複数のクエリを処理する必要がないこと（上記の構成の制限的なケース）と、サーバーが任意の1つのリクエスタからのクエリを処理するレートを制限する可能性が高いことを認識する必要があります。
This example illustrates what a series of queries and responses might look like. This is only an example -- there is no requirement that this sequence must be followed or that requestors or servers must support parallel queries.
この例は、一連のクエリと応答がどのように見えるかを示しています。これは単なる例です。このシーケンスに従う必要があるという要件や、リクエスタまたはサーバーが並列クエリをサポートする必要があるという要件はありません。
In the example session, the client sends four queries after establishing a connection. Query 1 returns no results; query 2 returns 3 messages, and the stream of replies concludes before the client issues any new query. Query 3 and query 4 overlap, and the server interleaves its replies to those two queries.
サンプルセッションでは、クライアントは接続を確立した後で4つのクエリを送信します。クエリ1は結果を返しません。クエリ2は3つのメッセージを返し、クライアントが新しいクエリを発行する前に、一連の応答が終了します。クエリ3とクエリ4は重複しており、サーバーはそれらの2つのクエリへの応答をインターリーブします。
Requestor Server
--------- ------
DHCPBULKLEASEQUERY xid 1 ----->
<----- DHCPLEASEQUERYDONE xid 1
DHCPBULKLEASEQUERY xid 2 ----->
<----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEACTIVE xid 2
<----- DHCPLEASEQUERYDONE xid 2
DHCPBULKLEASEQUERY xid 3 ----->
DHCPBULKLEASEQUERY xid 4 ----->
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 3
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEUNASSIGNED xid 3
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEACTIVE xid 3
<----- DHCPLEASEQUERYDONE xid 3
<----- DHCPLEASEACTIVE xid 4
<----- DHCPLEASEQUERYDONE xid 4
If a requestor has no additional queries to send, or doesn't know if it has additional queries to send or not, then it SHOULD close the connection after receiving the DHCPLEASEQUERYDONE message for the last outstanding query that it sent.
リクエスタが送信する追加のクエリがない場合、または送信する追加のクエリがあるかどうかわからない場合は、最後に送信した未解決のクエリのDHCPLEASEQUERYDONEメッセージを受信した後、接続を閉じる必要があります。
The requestor SHOULD close connections in a graceful manner and not an abort. The requestor SHOULD NOT assume that the manner in which the DHCP server closed a connection carries any special meaning.
リクエスタは、打ち切りではなく、適切な方法で接続を閉じる必要があります（SHOULD）。リクエスタは、DHCPサーバーが接続を閉じる方法に特別な意味があることを想定してはなりません。
Typically, the requestor is the entity that will close the connection, as servers will often wait with an open connection in case the requestor has additional queries.
通常、リクエスタは接続を閉じるエンティティです。サーバーはリクエスタに追加のクエリがある場合、開いた接続で待機することが多いためです。
If a server closes a connection with an exception condition, the requestor SHOULD consider as valid any completely received intermediate results, and the requestor MAY retry the Bulk Leasequery operation.
サーバーが例外条件で接続を閉じた場合、リクエスターは完全に受信された中間結果を有効と見なすべきであり（SHOULD）、リクエスターは一括リースクエリ操作を再試行してもよい（MAY）。
Servers that implement DHCPv4 Bulk Leasequery listen for incoming TCP connections. Port numbers are discussed in Section 6.3. Servers MUST be able to limit the number of concurrently accepted and active connections. The value BULK_LQ_MAX_CONNS SHOULD be the default; implementations MAY permit the value to be configurable. Connections SHOULD be accepted and, if the number of connections is over BULK_LQ_MAX_CONNS, they SHOULD be closed immediately.
DHCPv4一括リースクエリを実装するサーバーは、着信TCP接続をリッスンします。ポート番号については、セクション6.3で説明します。サーバーは、同時に受け入れられるアクティブな接続の数を制限できる必要があります。値BULK_LQ_MAX_CONNSがデフォルトである必要があります。実装では、値を構成可能にすることができます（MAY）。接続は受け入れられるべきであり（SHOULD）、接続の数がBULK_LQ_MAX_CONNSを超える場合、それらはすぐに閉じられるべきです（SHOULD）。
Servers MAY restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY messages to certain requestors. Connections not from permitted requestors SHOULD be closed immediately to avoid server connection resource exhaustion. Servers MAY restrict some requestors to certain query types. Servers MAY reply to queries that are not permitted with the DHCPLEASEQUERYDONE message with a status-code option status of NotAllowed or MAY simply close the connection.
サーバーは、バルクリースクエリ接続とDHCPBULKLEASEQUERYメッセージを特定のリクエスタに制限する場合があります。サーバー接続リソースの枯渇を避けるために、許可されたリクエスターからのものではない接続はすぐに閉じる必要があります。サーバーは一部のリクエスタを特定のクエリタイプに制限する場合があります。サーバーは、ステータスコードオプションのステータスがNotAllowedであるDHCPLEASEQUERYDONEメッセージで許可されていないクエリに応答するか、単に接続を閉じることができます。
If the TCP connection becomes blocked while the server is accepting a connection or reading a query, it SHOULD be prepared to terminate the connection after 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の後で接続を終了する準備をしておく必要があります。この推奨事項は、サーバーが使用しているTCP実装とは関係なく、非アクティブな接続を破棄する前にサーバーが待機する時間を制御できるようにするためのものです。
If the connection becomes blocked while the server is attempting to send reply messages, the server SHOULD be prepared to terminate the TCP connection after a BULK_LQ_DATA_TIMEOUT.
サーバーが応答メッセージを送信しようとしている間に接続がブロックされた場合、サーバーは、BULK_LQ_DATA_TIMEOUTの後でTCP接続を終了する準備をする必要があります。
Every Bulk Leasequery request MUST be terminated by sending a final DHCPLEASEQUERYDONE message if such a message can be sent. The DHCPLEASEQUERYDONE message MUST have a status-code option status if the termination was other than successful, and SHOULD NOT contain a status-code option status if the termination was successful.
そのようなメッセージを送信できる場合は、すべてのバルクリースクエリ要求を最後のDHCPLEASEQUERYDONEメッセージを送信して終了する必要があります。 DHCPLEASEQUERYDONEメッセージには、終了が成功以外の場合はステータスコードオプションステータスが含まれている必要があり、終了が成功の場合はステータスコードオプションステータスが含まれてはいけません（SHOULD NOT）。
If the DHCPv4 server encounters an error during processing of the DHCPBULKLEASEQUERY message, either during initial processing or later during the message processing, it SHOULD send a DHCPLEASEQUERYDONE containing a status-code option. It MAY close the connection after this error is signaled, but that is not required.
DHCPBULKLEASEQUERYメッセージの処理中に、初期処理中または後でメッセージ処理中にDHCPv4サーバーでエラーが発生した場合、DHCPv4サーバーは、ステータスコードオプションを含むDHCPLEASEQUERYDONEを送信する必要があります（SHOULD）。このエラーが通知された後、接続を閉じる場合がありますが、これは必須ではありません。
If the server does not find any bindings satisfying a query, it MUST send a DHCPLEASEQUERYDONE. It SHOULD NOT include a status-code option with a Success status unless there is a useful string to include in the status-code option. Otherwise, the server sends each binding's data in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message.
サーバーがクエリを満たすバインディングを見つけられない場合は、DHCPLEASEQUERYDONEを送信する必要があります。 status-codeオプションに含めるのに役立つ文字列がない限り、Successステータスにstatus-codeオプションを含めないでください。それ以外の場合、サーバーは各バインディングのデータをDHCPLEASEACTIVEまたはDHCPLEASEUNASSIGNEDメッセージで送信します。
The response to a DHCPBULKLEASEQUERY may involve examination of multiple DHCPv4 IP address bindings maintained by the DHCPv4 server. The Bulk Leasequery protocol does not require any ordering of the IP addresses returned in DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED messages.
DHCPBULKLEASEQUERYへの応答には、DHCPv4サーバーによって維持されている複数のDHCPv4 IPアドレスバインディングの調査が含まれる場合があります。 Bulk Leasequeryプロトコルは、DHCPLEASEACTIVEまたはDHCPLEASEUNASSIGNEDメッセージで返されるIPアドレスの順序付けを必要としません。
When responding to a DHCPBULKLEASEQUERY message, the DHCPv4 server MUST NOT send more than one message for each applicable IP address, even if the state of some of those IP addresses changes during the processing of the message. Updates to such IP address state are already handled by normal protocol processing, so no special effort is needed here.
DHCPBULKLEASEQUERYメッセージに応答する場合、メッセージの処理中に一部のIPアドレスの状態が変化したとしても、DHCPv4サーバーは該当するIPアドレスごとに複数のメッセージを送信してはなりません（MUST NOT）。このようなIPアドレス状態の更新は、通常のプロトコル処理によってすでに処理されているため、ここでは特別な作業は必要ありません。
If the ciaddr, yiaddr, or siaddr is non-zero in a DHCPBULKLEASEQUERY request, the request must be terminated immediately by a DHCPLEASEQUERYDONE message with a status-code option status of MalformedQuery.
DHCPBULKLEASEQUERYリクエストでciaddr、yiaddr、またはsiaddrがゼロ以外の場合、ステータスコードオプションのステータスがMalformedQueryのDHCPLEASEQUERYDONEメッセージでリクエストをすぐに終了する必要があります。
Any DHCPBULKLEASEQUERY that has more than one of the following primary query types specified MUST be terminated immediately by a DHCPLEASEQUERYDONE message with a status-code option status code of NotAllowed.
次のプライマリクエリの種類が複数指定されているDHCPBULKLEASEQUERYは、ステータスコードオプションのステータスコードがNotAllowedのDHCPLEASEQUERYDONEメッセージで直ちに終了する必要があります。
The allowable queries in a DHCPBULKLEASEQUERY message are processed as follows. Note that the descriptions of the primary queries below must be constrained by the actions of any of the three qualifiers described subsequently as well.
DHCPBULKLEASEQUERYメッセージで許可されるクエリは、次のように処理されます。以下のプライマリクエリの説明は、後で説明する3つの修飾子のいずれかのアクションによって制約される必要があることに注意してください。
The following table discusses how to process the various queries. For information on how to identify the query, see the information in Section 7.2.
次の表では、さまざまなクエリの処理方法について説明します。クエリを識別する方法については、セクション7.2の情報を参照してください。
o Query by MAC address
o MACアドレスによるクエリ
Every IP address that has a current binding to a DHCPv4 client matching the chaddr, htype, and hlen in the DHCPBULKLEASEQUERY request MUST be returned in a DHCPLEASEACTIVE message.
DHCPBULKLEASEQUERYリクエストのchaddr、htype、およびhlenに一致するDHCPv4クライアントへの現在のバインディングを持つすべてのIPアドレスは、DHCPLEASEACTIVEメッセージで返される必要があります。
o Query by Client-identifier
o クライアント識別子によるクエリ
Every IP address that has a current binding to a DHCPv4 client matching the Client-identifier option in the DHCPBULKLEASEQUERY request MUST be returned in a DHCPLEASEACTIVE message.
DHCPBULKLEASEQUERY要求のClient-identifierオプションと一致するDHCPv4クライアントへの現在のバインディングを持つすべてのIPアドレスは、DHCPLEASEACTIVEメッセージで返される必要があります。
o Query by Remote ID
o リモートIDによるクエリ
Every IP address that has a current binding to a DHCPv4 client matching the Remote ID sub-option of the relay-agent-information option in the DHCPBULKLEASEQUERY request MUST be returned in a DHCPLEASEACTIVE message.
DHCPBULKLEASEQUERYリクエストのrelay-agent-informationオプションのリモートIDサブオプションと一致するDHCPv4クライアントへの現在のバインディングを持つすべてのIPアドレスは、DHCPLEASEACTIVEメッセージで返される必要があります。
o Query by Relay-ID
o リレーIDによるクエリ
Every IP address that has a current binding to a DHCPv4 client matching the Relay-ID sub-option of the relay-agent-information option in the DHCPBULKLEASEQUERY request MUST be returned in a DHCPLEASEACTIVE message.
DHCPBULKLEASEQUERYリクエストのrelay-agent-informationオプションのRelay-IDサブオプションと一致するDHCPv4クライアントへの現在のバインディングを持つすべてのIPアドレスは、DHCPLEASEACTIVEメッセージで返される必要があります。
o Query for All Configured IP Addresses
o すべての構成済みIPアドレスのクエリ
A Query for All Configured IP addresses is signaled by the absence of any other primary query. That is, if there is no value in the chaddr, hlen, htype, no Client-identifier option, and no Remote ID sub-option or Relay-ID sub-option of the relay-agent-information option, then the request is a query for information concerning all configured IP addresses. In this case, every configured IP address that has a current binding to a DHCPv4 client MUST be returned in a DHCPLEASEACTIVE message. In addition, every configured IP address that does not have a current binding to a DHCPv4 client MUST be returned in a DHCPLEASEUNASSIGNED message.
すべての構成済みIPアドレスのクエリは、他のプライマリクエリがないことによって通知されます。つまり、chaddr、hlen、htype、Client-identifierオプション、およびrelay-agent-informationオプションのRemote IDサブオプションまたはRelay-IDサブオプションに値がない場合、リクエストはすべての構成済みIPアドレスに関する情報を照会します。この場合、DHCPv4クライアントへの現在のバインディングを持つすべての構成済みIPアドレスは、DHCPLEASEACTIVEメッセージで返される必要があります。さらに、DHCPv4クライアントへの現在のバインディングがないすべての構成済みIPアドレスは、DHCPLEASEUNASSIGNEDメッセージで返される必要があります。
In this form of query, each configured IP address MUST be returned at most one time. In the absence of qualifiers restricting the number of IP addresses returned, every configured IP address MUST be returned exactly once.
この形式のクエリでは、構成された各IPアドレスが最大で一度に返される必要があります。返されるIPアドレスの数を制限する修飾子がない場合は、構成されているすべてのIPアドレスを1回だけ返す必要があります。
There are three qualifiers that can be applied to any of the above primary queries. These qualifiers can appear individually or together in any combination, but only one of each can appear.
上記のプライマリクエリのいずれにも適用できる3つの修飾子があります。これらの修飾子は個別に、または組み合わせて表示できますが、表示できるのはそれぞれ1つだけです。
o Query Start Time
o クエリ開始時間
If a query-start-time option appears in the DHCPBULKLEASEQUERY request, only IP address bindings that have changed on or after the time specified in the query-start-time option should be returned.
DHCPBULKLEASEQUERY要求にquery-start-timeオプションが含まれている場合、query-start-timeオプションで指定された時刻以降に変更されたIPアドレスバインディングのみが返されます。
o Query End Time
o クエリ終了時間
If a query-end-time option appears in the DHCPBULKLEASEQUERY request, only IP address bindings that have changed on or before the time specified in the query-end-time option should be returned.
DHCPBULKLEASEQUERY要求にquery-end-timeオプションが含まれている場合、query-end-timeオプションで指定された時刻以前に変更されたIPアドレスバインディングのみが返されます。
o VPN-ID
o VPN-ID
If no VPN-ID option appears in the DHCPBULKLEASEQUERY, the default (global) VPN is used to satisfy the query. A VPN-ID option [RFC6607] value other than the wildcard value (254) allows the requestor to specify a single VPN other than the default VPN. In addition, the VPN-ID option has been extended as part of this document to allow specification of a type 254, which indicates that all configured VPNs be searched in order to satisfy the primary query.
DHCPBULKLEASEQUERYにVPN-IDオプションが表示されない場合、デフォルト（グローバル）VPNを使用してクエリが満たされます。ワイルドカード値（254）以外のVPN-IDオプション[RFC6607]値を使用すると、要求者はデフォルトのVPN以外の単一のVPNを指定できます。さらに、このドキュメントの一部としてVPN-IDオプションが拡張され、タイプ254を指定できるようになりました。これは、設定されたすべてのVPNがプライマリクエリを満たすために検索されることを示します。
In all cases, if the information returned in a DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED message is for a VPN other than the default (global) VPN, a VPN-ID option MUST appear in the packet.
すべての場合において、DHCPLEASEACTIVEまたはDHCPLEASEUNASSIGNEDメッセージで返される情報がデフォルト（グローバル）VPN以外のVPNに関するものである場合は、VPN-IDオプションがパケットに含まれている必要があります。
The query-start-time and query-end-time qualifiers are used to constrain the amount of data returned by a Bulk Leasequery request by returning only IP addresses whose address bindings have changed in some way during the time window specified by the query-start-time and query-end-time.
query-start-time修飾子とquery-end-time修飾子は、query-startで指定された時間枠の間にアドレスバインディングが何らかの方法で変更されたIPアドレスのみを返すことにより、Bulk Leasequery要求によって返されるデータの量を制限するために使用されます-timeおよびquery-end-time。
A DHCPv4 server SHOULD consider an address binding to have changed during a specified time window if either the client-last-transaction-time or the start-time-of-state of the address binding changed during that time window.
DHCPv4サーバーは、アドレスバインディングのclient-last-transaction-timeまたはstart-time-of-stateのいずれかがその時間枠の間に変更された場合、指定された時間枠の間にアドレスバインディングが変更されたと見なす必要があります。
The DHCPv4 server MAY return address binding data in any order, as long as binding information for any given IP address is not repeated. When all binding data for a given DHCPBULKLEASEQUERY has been sent, the DHCPv4 server MUST send a DHCPBULKLEASEQUERYDONE message.
DHCPv4サーバーは、特定のIPアドレスのバインディング情報が繰り返されない限り、任意の順序でアドレスバインディングデータを返すことができます。特定のDHCPBULKLEASEQUERYのすべてのバインディングデータが送信されると、DHCPv4サーバーはDHCPBULKLEASEQUERYDONEメッセージを送信する必要があります。
The DHCPv4 Leasequery specification [RFC4388] describes the initial construction of DHCPLEASEQUERY reply messages using the DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED message types in Section 6.4.2. All of the reply messages in Bulk Leasequery are similar to the reply messages for an IP address query. Message transmission and framing for TCP are described in this document in Section 6.1.
DHCPv4 Leasequery仕様[RFC4388]は、セクション6.4.2のDHCPLEASEACTIVEおよびDHCPLEASEUNASSIGNEDメッセージタイプを使用したDHCPLEASEQUERY応答メッセージの初期構成について説明しています。 Bulk Leasequeryのすべての応答メッセージは、IPアドレスクエリの応答メッセージに似ています。 TCPのメッセージ送信とフレーミングについては、このドキュメントのセクション6.1で説明しています。
[RFC2131] and [RFC4388] specify that every response message MUST contain the server-identifier option. However, that option will be the same for every response from a particular DHCPBULKLEASEQUERY request. Thus, the DHCPv4 server MUST include the server-identifier option in the first message sent in response to a DHCPBULKLEASEQUERY. It SHOULD NOT include the server-identifier option in later messages.
[RFC2131]と[RFC4388]は、すべての応答メッセージにサーバー識別子オプションが含まれている必要があることを指定しています。ただし、そのオプションは、特定のDHCPBULKLEASEQUERY要求からのすべての応答で同じになります。したがって、DHCPv4サーバーは、DHCPBULKLEASEQUERYへの応答として送信される最初のメッセージにserver-identifierオプションを含める必要があります。後のメッセージにserver-identifierオプションを含めないでください。
The message type of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based on the value of the dhcp-state option. If the dhcp-state option value is ACTIVE, then the message type is DHCPLEASEACTIVE; otherwise, the message type is DHCPLEASEUNASSIGNED.
DHCPLEASEACTIVEまたはDHCPLEASEUNASSIGNEDのメッセージタイプは、dhcp-stateオプションの値に基づいています。 dhcp-stateオプションの値がACTIVEの場合、メッセージタイプはDHCPLEASEACTIVEです。それ以外の場合、メッセージタイプはDHCPLEASEUNASSIGNEDです。
In addition to the basic message construction described in [RFC4388], the following guidelines exist:
[RFC4388]で説明されている基本的なメッセージ構成に加えて、次のガイドラインが存在します：
1. If the dhcp-state option code appears in the dhcp-parameter-request-list, the DHCPv4 server SHOULD include a dhcp-state option whose value corresponds most closely to the state held by the DHCPv4 server for the IP address associated with this reply. If the state is ACTIVE and the message being returned is DHCPLEASEACTIVE, then the DHCPv4 server MAY choose to not send the dhcp-state option. The requestor SHOULD assume that any DHCPLEASEACTIVE message arriving without a requested dhcp-state option has a dhcp-state of ACTIVE.
1. dhcp-stateオプションコードがdhcp-parameter-request-listにある場合、DHCPv4サーバーは、この応答に関連付けられたIPアドレスに対してDHCPv4サーバーが保持する状態に最も近い値を持つdhcp-stateオプションを含める必要があります（SHOULD）。状態がACTIVEであり、返されるメッセージがDHCPLEASEACTIVEの場合、DHCPv4サーバーはdhcp-stateオプションを送信しないことを選択できます（MAY）。リクエスタは、要求されたdhcp-stateオプションなしで到着したDHCPLEASEACTIVEメッセージのdhcp-stateがACTIVEであると想定する必要があります（SHOULD）。
2. If the base-time option code appears in the dhcp-parameter-request-list, the DHCPv4 server MUST include a base-time option, which is the current time in the DHCPv4 server's context and the time from which the start-time-of-state, dhcp-lease-time, client-last-transaction-time, and other duration-style times are based upon.
2. ベースタイムオプションコードがdhcp-parameter-request-listにある場合、DHCPv4サーバーはベースタイムオプションを含める必要があります。これは、DHCPv4サーバーのコンテキストの現在の時刻と、start-time-ofの開始時刻です。 -state、dhcp-lease-time、client-last-transaction-time、およびその他の期間スタイルの時間が基準になります。
3. If the start-time-of-state option code appears in the dhcp-parameter-request-list, the DHCPv4 server MUST include a start-time-of-state option whose value represents the time at which the dhcp-state option's state became valid.
3. start-time-of-stateオプションコードがdhcp-parameter-request-listにある場合、DHCPv4サーバーは、値がdhcp-stateオプションの状態になった時刻を表すstart-time-of-stateオプションを含める必要があります。有効。
4. If the dhcp-lease-time option code appears in the dhcp-parameter-request-list, the DHCPv4 server MUST include a dhcp-lease-time option for any state that has a timeout value associated with it.
4. dhcp-lease-timeオプションコードがdhcp-parameter-request-listにある場合、DHCPv4サーバーは、タイムアウト値が関連付けられているすべての状態のdhcp-lease-timeオプションを含める必要があります。
5. If the data-source option code appears in the dhcp-parameter-request-list, the DHCPv4 server MUST include the data-source option in any situation where any of the bits would be non-zero. Thus, in the absence of the data-source option, the assumption is that all of the flags are zero.
5. データソースオプションコードがdhcp-parameter-request-listにある場合、DHCPv4サーバーは、いずれかのビットがゼロ以外の状況にデータソースオプションを含める必要があります。したがって、データソースオプションがない場合は、すべてのフラグがゼロであると想定されます。
6. If the client-last-transaction-time option code appears in the dhcp-parameter-request-list, the DHCPv4 server MUST include the client-last-transaction-time option in any situation where the information is available.
6. client-last-transaction-timeオプションコードがdhcp-parameter-request-listに含まれている場合、DHCPv4サーバーは、情報が利用可能なあらゆる状況でclient-last-transaction-timeオプションを含める必要があります。
7. If there is a dhcp-parameter-request-list in the initial DHCPBULKLEASEQUERY request, then it should be used for all of the replies generated by that request. Some options can be sent from a DHCPv4 client to the server or from the DHCPv4 server to a DHCPv4 client. Option 125 is such an option. If the option code for one of these options appears in the dhcp-parameter-request-list, it SHOULD result in returning the value of the option sent by the DHCPv4 client to the server if one exists.
7. 最初のDHCPBULKLEASEQUERY要求にdhcp-parameter-request-listがある場合は、その要求によって生成されるすべての応答に使用する必要があります。一部のオプションは、DHCPv4クライアントからサーバーに、またはDHCPv4サーバーからDHCPv4クライアントに送信できます。オプション125はそのようなオプションです。これらのオプションのいずれかのオプションコードがdhcp-parameter-request-listにある場合、DHCPv4クライアントからサーバーに送信されたオプションの値が存在する場合は、その値を返す必要があります（SHOULD）。
Note that there may be other requirements for a reply to a DHCPBULKLEASEQUERY request, as discussed in Section 8.2.
セクション8.2で説明されているように、DHCP BULK LEASEQUERY要求への応答には他の要件がある場合があることに注意してください。
As discussed in Section 7.3, requestors may want to use a connection that has already been established when they need to make additional queries. Servers SHOULD support reading and processing multiple queries from a single connection and SHOULD allow configuration of the number of simultaneous queries it may process. A server MUST NOT read more query messages from a connection than it is prepared to process simultaneously.
セクション7.3で説明したように、リクエスタは、追加のクエリを実行する必要があるときに、すでに確立されている接続を使用する場合があります。サーバーは、単一の接続からの複数のクエリの読み取りと処理をサポートする必要があり（SHOULD）、処理できる同時クエリの数を設定できる必要があります（SHOULD）。サーバーは、同時に処理する準備ができているよりも多くのクエリメッセージを接続から読み取ってはなりません。
This SHOULD be a feature that is administratively controlled. Servers 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.
これは管理上制御される機能であるべきです（SHOULD）。サーバーは、サービスを求めるリクエスタが複数ある場合にリソースの使用を制御するために、1つのリクエスタから許可される同時クエリの数を制限する構成を提供する必要があります。
The DHCPv4 server SHOULD close connections in a graceful manner and not abort the connection. The DHCPv4 server SHOULD NOT assume that the manner in which the requestor closed a connection carries any special meaning.
DHCPv4サーバーは、正常な方法で接続を閉じ、接続を中止しないようにする必要があります（SHOULD）。 DHCPv4サーバーは、リクエスタが接続を閉じた方法に特別な意味があると想定してはなりません。
Typically, the DHCPv4 server will only close the connection after some form of an exception or a timeout on the connection.
通常、DHCPv4サーバーは、なんらかの形式の例外または接続のタイムアウト後にのみ接続を閉じます。
Using a timer to detect when a connection is idle and then closing that connection is designed to protect the DHCPv4 server from consuming unnecessary resources.
タイマーを使用して接続がアイドル状態にあることを検出し、その接続を閉じることは、DHCPv4サーバーが不要なリソースを消費しないように設計されています。
The DHCPv4 server should start a timer for BULK_LQ_DATA_TIMEOUT seconds for a particular connection after it sends a DHCPLEASEQUERYDONE message over that connection if there is no current query outstanding for that connection. It should restart this timer if a query arrives over that connection. If the timer expires, the DHCPv4 server should close the connection.
DHCPv4サーバーは、特定の接続に対してDHCPLEASEQUERYDONEメッセージを送信した後、その接続に対して現在未解決のクエリがない場合、特定の接続に対してBULK_LQ_DATA_TIMEOUT秒間タイマーを開始する必要があります。その接続を介してクエリが到着した場合、このタイマーを再起動する必要があります。タイマーの期限が切れた場合、DHCPv4サーバーは接続を閉じる必要があります。
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 status-code option in a DHCPLEASEQUERYDONE message, including a message string indicating details of the reason for the abort. If the connection is closed for any reason, all of the data flows associated with any currently outstanding DHCPBULKLEASEQUERY messages will be terminated.
サーバーは、接続でのデータ送信エラーが発生した場合、TCP接続の最後を閉じる必要があります。サーバーは、インプロセス要求を中止する必要があると判断した場合、TCP接続の最後を閉じる必要があります。インプロセス要求を中止するサーバーは、DHCPLEASEQUERYDONEメッセージのstatus-codeオプションのQueryTerminatedステータスコードを使用して、中止の理由の詳細を示すメッセージ文字列を含め、それを要求元に通知する必要があります（SHOULD）。何らかの理由で接続が閉じられると、現在未解決のDHCPBULKLEASEQUERYメッセージに関連付けられているすべてのデータフローが終了します。
If the server detects that the requesting end of the connection has been closed, the server MUST close its end of the connection.
接続の要求側が閉じられたことをサーバーが検出した場合、サーバーは接続の終わりを閉じなければなりません（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 authentication of LEASEQUERY messages, mitigation of packet-flooding DoS attacks, and restriction to trusted requestors.
[RFC2131]のセキュリティに関する考慮事項のセクションでは、DHCPv4に対する一般的な脅威について詳しく説明しています。 DHCPv4 Leasequery仕様[RFC4388]は、特にLEASEQUERYメッセージの認証、パケットフラッディングDoS攻撃の緩和、および信頼できるリクエスタへの制限に関して、Leasequeryプロトコルの推奨事項を説明しています。
The use of TCP introduces some additional concerns. Attacks that attempt to exhaust the DHCPv4 server's available TCP connection resources, such as SYN flooding attacks, 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. We recommend that servers offer configuration to limit the sources of incoming connections, that they limit the number of accepted connections and the number of in-process queries from any one connection, and that they limit the period of time during which an idle connection will be left open.
TCPの使用は、いくつかの追加の懸念をもたらします。 SYNフラッディング攻撃など、DHCPv4サーバーの利用可能なTCP接続リソースを使い果たしようとする攻撃は、正当なリクエスタがサービスを受信する能力を危険にさらす可能性があります。接続の確立に成功したが、無効なクエリ、部分クエリ、またはまったくクエリを送信しない悪意のある要求者も、サーバーの利用可能な接続のプールを使い果たす可能性があります。サーバーが着信接続のソースを制限する構成を提供すること、1つの接続からの受け入れられる接続の数とインプロセスクエリの数を制限すること、およびアイドル接続が行われる期間を制限することをお勧めします開いたまま。
There are two specific issues regarding Bulk Leasequery security that deserve explicit mention. The first is preventing information that Bulk Leasequery can provide from reaching clients who are not authorized to receive such information. The second is ensuring that authorized clients of the Bulk Leasequery capability receive accurate information from the server (and that this information is not disrupted in transit).
明示的な言及に値する、Bulk Leasequeryのセキュリティに関する2つの特定の問題があります。 1つ目は、Bulk Leasequeryが提供できる情報が、そのような情報の受信を許可されていないクライアントに届かないようにすることです。 2つ目は、Bulk Leasequery機能の承認されたクライアントがサーバーから正確な情報を受け取ることを保証することです（この情報が転送中に中断されないこと）。
To prevent information leakage to unauthorized clients, servers SHOULD restrict Bulk Leasequery connections and DHCPBULKLEASEQUERY messages to certain requestors, either through explicit configuration of the server itself or by employing external network elements to provide such restrictions. In particular, the typical DHCPv4 client SHOULD NOT be allowed to receive a response to a Bulk Leasequery request, and some technique MUST exist to allow prevention of such access in any environment where Bulk Leasequery is deployed.
許可されていないクライアントへの情報漏えいを防ぐために、サーバーは、サーバー自体の明示的な構成を通じて、または外部ネットワーク要素を使用してそのような制限を提供することにより、バルクリースクエリ接続とDHCPBULKLEASEQUERYメッセージを特定のリクエスタに制限する必要があります。特に、一般的なDHCPv4クライアントは、Bulk Leasequery要求への応答の受信を許可されるべきではなく（SHOULD）、Bulk Leasequeryが展開されているすべての環境でそのようなアクセスを防止できるようにするための技術が存在しなければなりません。
Connections not from permitted requestors SHOULD be closed immediately to avoid server connection resource exhaustion or alternatively, simply not be allowed to reach the server at all. Servers SHOULD have the capability to restrict certain requestors to certain query types. Servers MAY reply to queries that are not permitted with the DHCPLEASEQUERYDONE message with a status-code option status of NotAllowed or MAY simply close the connection.
許可されたリクエスタからでない接続は、サーバー接続リソースの枯渇を回避するためにすぐに閉じる必要があります。あるいは、サーバーへの到達をまったく許可しないでください。サーバーは、特定のリクエスタを特定のクエリタイプに制限する機能を持つ必要があります。サーバーは、ステータスコードオプションのステータスがNotAllowedであるDHCPLEASEQUERYDONEメッセージで許可されていないクエリに応答するか、単に接続を閉じることができます。
To prevent disruption and malicious corruption of Bulk Leasequery data flows between the server and authorized clients, these data flows SHOULD transit only secured networks. These data flows are typically infrastructure oriented, and there is usually no reason to have them flowing over networks where such attacks are likely. In the rare cases where these data flows might need to be sent through unsecured networks, they MUST be sent over connections secured through means external to the DHCPv4/DHCPv6 server and its client(s) (e.g., through VPNs).
サーバーと承認されたクライアント間のBulk Leasequeryデータフローの中断と悪意のある破損を防ぐために、これらのデータフローは安全なネットワークのみを転送する必要があります。これらのデータフローは通常インフラストラクチャ指向であり、通常、このような攻撃が発生する可能性のあるネットワークを介してフローをフローさせる理由はありません。これらのデータフローを安全でないネットワーク経由で送信する必要があるまれなケースでは、DHCPv4 / DHCPv6サーバーとそのクライアントの外部の手段（VPNなど）経由で保護された接続を介して送信する必要があります。
Authentication for DHCP messages [RFC3118] MUST NOT be used to attempt to secure transmission of the messages described in this document. In particular, the message framing would not be protected by using the mechanisms described in [RFC3118] (which was designed only with UDP transport in mind).
DHCPメッセージの認証[RFC3118]は、このドキュメントで説明されているメッセージの安全な送信を試みるために使用してはなりません（MUST NOT）。特に、[RFC3118]（UDPトランスポートのみを考慮して設計された）で説明されているメカニズムを使用しても、メッセージのフレーミングは保護されません。
IANA has assigned the following new DHCPv4 option codes from the registry "BOOTP Vendor Extensions and DHCP Options" maintained at http://www.iana.org/assignments/bootp-dhcp-parameters.
IANAは、http：//www.iana.org/assignments/bootp-dhcp-parametersで管理されているレジストリ「BOOTPベンダー拡張とDHCPオプション」から、次の新しいDHCPv4オプションコードを割り当てました。
1. An option code of 151 for status-code.
1. status-codeのオプションコード151。
2. An option code of 152 for base-time.
2. 基本時間のオプションコード152。
3. An option code of 153 for start-time-of-state.
3. start-time-of-stateのオプションコード153。
4. An option code of 154 for query-start-time.
4. query-start-timeのオプションコード154。
5. An option code of 155 for query-end-time.
5. query-end-timeのオプションコード155。
6. An option code of 156 for dhcp-state.
6. dhcp-stateのオプションコード156。
7. An option code of 157 for data-source.
7. データソースのオプションコード157。
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 14 for DHCPBULKLEASEQUERY.
1. DHCPBULKLEASEQUERYの場合、dhcp-message-typeは14です。
2. A dhcp-message-type of 15 for DHCPLEASEQUERYDONE.
2. DHCPLEASEQUERYDONEの場合、dhcp-message-typeは15。
IANA has created a new registry on the same assignments page, titled "DHCP State 156 Values" (where 156 corresponds to the assigned value of the dhcp-state option above). This registry has the following initial values:
IANAは、同じ割り当てページに「DHCP State 156 Values」というタイトルの新しいレジストリを作成しました（156は上記のdhcp-stateオプションの割り当てられた値に対応しています）。このレジストリには、次の初期値があります。
State
-----
1 AVAILABLE
2 ACTIVE
3 EXPIRED
4 RELEASED
5 ABANDONED
6 RESET
7 REMOTE
8 TRANSITIONING
New values for this namespace may only be defined by IETF Review, as described in [RFC5226].
この名前空間の新しい値は、[RFC5226]で説明されているように、IETFレビューでのみ定義できます。
IANA has created a new registry on the same assignments page, titled "DHCP Status Code 151 Values" (where 151 corresponds to the assigned value of the status-code option above). This registry has the following initial values:
IANAは、「DHCPステータスコード151値」というタイトルの同じ割り当てページに新しいレジストリを作成しました（151は、上記のステータスコードオプションの割り当てられた値に対応しています）。このレジストリには、次の初期値があります。
Name status-code
---- -----------
Success 000
UnspecFail 001
QueryTerminated 002
MalformedQuery 003
NotAllowed 004
New values for this namespace may only be defined by IETF Review, as described in [RFC5226].
この名前空間の新しい値は、[RFC5226]で説明されているように、IETFレビューでのみ定義できます。
IANA has revised the registry "VSS Type Options" created by [RFC6607] in the overall area "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters". It has been revised to appear as follows. Note that the number range for "Unassigned" has changed, and a new line for "All VPNs (wildcard)" was added.
IANAは、[RFC6607]によって作成されたレジストリ「VSSタイプオプション」を全面的に「動的ホスト構成プロトコル（DHCP）およびブートストラッププロトコル（BOOTP）パラメータ」で改訂しました。以下のように修正されました。 「未割り当て」の番号範囲が変更され、「すべてのVPN（ワイルドカード）」の新しい行が追加されたことに注意してください。
Type VSS Information Format
------------------------------------------------------------
0 Network Virtual Terminal (NVT) ASCII VPN identifier
1 RFC 2685 VPN-ID
2-253 Unassigned
254 All VPNs (wildcard)
255 Global, default VPN
Significant text as well as important ideas were borrowed in whole or in part from "DHCPv6 Bulk Leasequery" [RFC5460], written by Mark Stapp. Further suggestions and improvements were made by participants in the DHC Working Group, including Alfred Hoenes.
Mark Stappによって書かれた「DHCPv6 Bulk Leasequery」[RFC5460]から、重要なアイデアだけでなく重要なテキストも、全体または一部が借用されました。 Alfred Hoenesを含むDHCワーキンググループの参加者によって、さらなる提案と改善が行われました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、1997年3月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。
[RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.、Ed。およびW. Arbaugh、Ed。、「Authentication for DHCP Messages」、RFC 3118、2001年6月。
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RFC4388] Woundy、R。、およびK. Kinnear、「Dynamic Host Configuration Protocol（DHCP）Leasequery」、RFC 4388、2006年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]綿、M。およびL.ベゴダ、「特別な用途のIPv4アドレス」、BCP 153、RFC 5735、2010年1月。
[RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet Selection Options for DHCPv4 and DHCPv6", RFC 6607, April 2012.
[RFC6607] Kinnear、K.、Johnson、R。、およびM. Stapp、「DHCPv4およびDHCPv6の仮想サブネット選択オプション」、RFC 6607、2012年4月。
[RFC6925] Joshi, B., Desetti, R., and M. Stapp, "The DHCPv4 Relay Agent Identifier Sub-Option", RFC 6925, April 2013.
[RFC6925] Joshi、B.、Desetti、R。、およびM. Stapp、「DHCPv4リレーエージェントIDサブオプション」、RFC 6925、2013年4月。
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC951] Croft、W. and J. Gilmore、 "Bootstrap Protocol"、RFC 951、September 1985。
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993.
[RFC1542] Wimer、W。、「Bootstrap Protocolの説明と拡張」、RFC 1542、1993年10月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614] Duke、M.、Braden、R.、Eddy、W。、およびE. Blanton、「A Transmission Map for Transmission Control Protocol（TCP）Specification Documents」、RFC 4614、2006年9月。
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 2009.
[RFC5460] Stapp、M。、「DHCPv6 Bulk Leasequery」、RFC 5460、2009年2月。
Authors' Addresses
著者のアドレス
Kim Kinnear Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, Massachusetts 01719 USA
Kim Kinnear Cisco Systems、Inc. 1414 Massachusetts Ave. Boxborough、Massachusetts 01719 USA
Phone: (978) 936-0000 EMail: kkinnear@cisco.com
電話：（978）936-0000メール：kkinnear@cisco.com
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, Massachusetts 01719 USA
Mark Stapp Cisco Systems、Inc. 1414 Massachusetts Ave. Boxborough、Massachusetts 01719 USA
Phone: (978) 936-0000 EMail: mjs@cisco.com
電話：（978）936-0000メール：mjs@cisco.com
D.T.V Ramakrishna Rao Infosys Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India
D.T.V Ramakrishna Rao Infosys Ltd. 44 Electronics City、Hosur Road Bangalore 560 100 India
EMail: ramakrishnadtv@infosys.com
URI: http://www.infosys.com/
Bharat Joshi Infosys Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India
Bharat Joshi Infosys Ltd. 44 Electronics City、Hosur Road Bangalore 560 100 India
EMail: bharat_joshi@infosys.com
URI: http://www.infosys.com/
Neil Russell Sea Street Technologies Inc.
Neil Russell Sea Street Technologies Inc.
EMail: neil.e.russell@gmail.com Pavan Kurapati Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
メール：nil.e.rsall@gmail.com pawan kurpatiジュニパーネットワーク1194いいえ。マチルダAV。サニーベール、94089彼
EMail: kurapati@juniper.net
URI: http://www.juniper.net/
Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, Massachusetts 01719 USA
Bernie Volz Cisco Systems、Inc. 1414 Massachusetts Ave. Boxborough、Massachusetts 01719 USA
Phone: (978) 936-0000 EMail: volz@cisco.com
電話：（978）936-0000メール：volz@cisco.com