[要約] RFC 4388は、DHCPリースクエリのためのプロトコルであり、DHCPサーバからリース情報を取得するためのメカニズムを提供します。目的は、ネットワーク管理者がリース情報をリアルタイムで取得し、ネットワークの状態を監視およびトラブルシューティングすることです。
Network Working Group R. Woundy
Request for Comments: 4388 Comcast Cable
Category: Standards Track K. Kinnear
Cisco Systems
February 2006
Dynamic Host Configuration Protocol (DHCP) Leasequery
動的ホスト構成プロトコル（DHCP）リースクリー
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided to DHCPv4 clients. Other processes and devices that already make use of DHCPv4 may need to access this information. The leasequery protocol provides these processes and devices a lightweight way to access IP address information.
動的ホスト構成プロトコルバージョン4（DHCPV4）サーバーは、DHCPV4クライアントに提供されたIPアドレスの信頼できるソースです。既にDHCPV4を使用している他のプロセスとデバイスは、この情報にアクセスする必要がある場合があります。リースクリープロトコルは、これらのプロセスとデバイスに、IPアドレス情報にアクセスするための軽量な方法を提供します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................5
3. Background ......................................................7
4. Design Goals ....................................................7
4.1. Broadcast ARP Is Undesirable ...............................7
4.2. SNMP and LDAP Are Not Appropriate ..........................8
4.3. DHCP Relay Agent Functionality Is Common ...................8
4.4. DHCP Servers Are a Reliable Source of Location
Information ................................................9
4.5. Minimal Additional Configuration Is Required ...............9
5. Protocol Overview ...............................................9
6. Protocol Details ...............................................12
6.1. Definitions Required for DHCPLEASEQUERY Processing ........12
6.2. Sending the DHCPLEASEQUERY Message ........................14
6.3. Receiving the DHCPLEASEQUERY Message ......................15
6.4. Responding to the DHCPLEASEQUERY Message ..................16
6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or
DHCPLEASEUNKNOWN Message ..................................20
6.6. Receiving No Response to the DHCPLEASEQUERY Message .......21
6.7. Lease Binding Data Storage Requirements ...................22
6.8. Using the DHCPLEASEQUERY Message with Multiple
DHCP Servers ..............................................23
7. Security Considerations ........................................23
8. IANA Considerations ............................................24
9. Acknowledgements ...............................................24
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................25
A DHCPv4 server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Sometimes devices or other processes may need access to this information. In some cases, these devices or processes already have the capability to send and receive DHCP packets, and so the leasequery protocol is designed to give these processes and devices a low-overhead way to access such information.
DHCPV4サーバーには、DHCPクライアントにリースされたIPアドレスに関するかなりの信頼できる情報が含まれています。デバイスやその他のプロセスがこの情報にアクセスする必要がある場合があります。場合によっては、これらのデバイスまたはプロセスには既にDHCPパケットを送信および受信する機能があるため、リースクリープロトコルは、これらのプロセスとデバイスにそのような情報にアクセスするための低オーバーヘッドの方法を提供するように設計されています。
For example, access concentrators that act as DHCP relay agents sometimes derive information important to their operation by extracting data out of the DHCP packets they forward, a process known as "gleaning". Unfortunately, the typical access concentrator loses its gleaned information when the access concentrator is rebooted or is replaced. This memo proposes that when gleaned DHCP information is not available, the access concentrator/relay agent can obtain the location information directly from the DHCP server(s) using the DHCPLEASEQUERY message.
たとえば、DHCPリレーエージェントとして作用するアクセスコンセントレーターは、「Gleaning」と呼ばれるプロセスであるDHCPパケットからデータを抽出することにより、操作に重要な情報を導き出すことがあります。残念ながら、典型的なアクセスコンセントレーターは、アクセス濃縮器が再起動されるか、交換されている場合に収集された情報を失います。このメモは、収集したDHCP情報が利用できない場合、Access Concenctor/RelayエージェントがDHCPleasequeryメッセージを使用してDHCPサーバーから直接位置情報を取得できることを提案しています。
To continue this example in more depth, in many broadband access networks, the access concentrator needs to associate an IP address lease to the correct endpoint location, which includes knowledge of the host hardware address, the port or virtual circuit that leads to the host, and/or the hardware address of the intervening subscriber modem. This is particularly important when one or more IP subnets are shared among many ports, circuits, and modems. Representative cable and DSL environments are depicted in Figures 1 and 2 below.
この例をより深く継続するために、多くのブロードバンドアクセスネットワークで、アクセスコンセントレーターは、ホストハードウェアアドレス、ホストにつながるポートまたは仮想回路の知識を含む正しいエンドポイントの位置にIPアドレスリースを関連付ける必要があります。および/または介在するサブスクライバーモデムのハードウェアアドレス。これは、1つ以上のIPサブネットが多くのポート、サーキット、モデム間で共有される場合に特に重要です。代表的なケーブル環境とDSL環境は、以下の図1および2に示されています。
+--------+ +---------------+
| DHCP | | DOCSIS CMTS |
| Server |-...-| or DVB INA |-------------------
+--------+ | (Relay Agent) | | |
+---------------+ +------+ +------+
|Modem1| |Modem2|
+------+ +------+
| | |
+-----+ +-----+ +-----+
|Host1| |Host2| |Host3|
+-----+ +-----+ +-----+
Figure 1: Cable Environment for DHCPLEASEQUERY
図1：DHCPleasequeryのケーブル環境
+--------+ +---------------+
| DHCP | | DSL Access | +-------+
| Server |-...-| Concentrator |-...-| DSLAM |
+--------+ | (Relay Agent) | +-------+
+---------------+ | |
+------+ +------+
|Modem1| |Modem2|
+------+ +------+
| | |
+-----+ +-----+ +-----+
|Host1| |Host2| |Host3|
+-----+ +-----+ +-----+
Figure 2: DSL Environment for DHCPLEASEQUERY
図2：DHCPLEASEQUERYのDSL環境
Knowledge of this location information can benefit the access concentrator in several ways:
この位置情報に関する知識は、いくつかの方法でアクセスコンセントレーターに利益をもたらすことができます。
1. The access concentrator can forward traffic to the access network using the correct access network port, down the correct virtual circuit, through the correct modem, to the correct hardware address.
1. Access Concencoratorは、正しいアクセスネットワークポートを使用して、正しい仮想回路を下って、正しいモデムを介して正しいハードウェアアドレスにアクセスネットワークにトラフィックを転送できます。
2. The access concentrator can perform IP source address verification of datagrams received from the access network. The verification may be based on the datagram source hardware address, the incoming access network port, the incoming virtual circuit, and/or the transmitting modem.
2. Access Concentorは、アクセスネットワークから受信したデータグラムのIPソースアドレスの確認を実行できます。検証は、Datagramソースハードウェアアドレス、着信アクセスネットワークポート、着信仮想回路、および/または送信モデムに基づいている場合があります。
3. The access concentrator can encrypt datagrams that can only be decrypted by the correct modem, using mechanisms such as [BPI] or [BPI+].
3. アクセス濃縮器は、[BPI]や[BPI]などのメカニズムを使用して、正しいモデムによってのみ復号化できるデータグラムを暗号化できます。
The access concentrator in this example obtains the location information primarily from "gleaning" information from DHCP server responses sent through the relay agent. When location information is not available from "gleaning", e.g., because the access concentrator has rebooted, the access concentrator can query the DHCP server(s) for location information using the DHCPLEASEQUERY message defined in this document.
この例のアクセスコンセントレーターは、主にリレーエージェントを介して送信されたDHCPサーバーの応答からの「収集」情報から位置情報を取得します。場所情報が「Gleaning」から利用できない場合、たとえば、アクセス濃縮器が再起動したため、アクセスコンセントレーターは、このドキュメントで定義されているDHCPleasequeryメッセージを使用して、DHCPサーバーをロケーション情報を照会できます。
The DHCPLEASEQUERY message is a new DHCP message type transmitted from a DHCP relay agent to a DHCP server. A DHCPLEASEQUERY-aware relay agent sends the DHCPLEASEQUERY message when it needs to know the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server replies with a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message. The DHCPLEASEACTIVE response to a DHCPLEASEQUERY message allows the relay agent to determine the IP endpoint location and the remaining duration of the IP address lease. The DHCPLEASEUNASSIGNED is similar to a DHCPLEASEACTIVE message, but indicates that there is no currently active lease on the resultant IP address but that this DHCP server is authoritative for this IP address. The DHCPLEASEUNKNOWN message indicates that the DHCP server has no knowledge of the information specified in the query (e.g., IP address, MAC address, or Client-identifier option).
DHCPleasequeryメッセージは、DHCPリレーエージェントからDHCPサーバーに送信される新しいDHCPメッセージタイプです。DHCPleasequery-Awareリレーエージェントは、IPエンドポイントの場所を知る必要がある場合にDHCPleasequeryメッセージを送信します。DHCPleasequery-Aware DHCPサーバーは、DHCPleaseUnassigned、DHCPleaSeactive、またはDHCPreaseunknownの知られているメッセージで返信します。DHCPLEASEQUERYメッセージに対するDHCPleaSeactive応答により、リレーエージェントはIPエンドポイントの位置とIPアドレスリースの残りの期間を決定できます。dhcpleaseunassignedはDHC遊液のメッセージに似ていますが、結果のIPアドレスに現在アクティブなリースがないが、このDHCPサーバーはこのIPアドレスに対して権威あることを示しています。DHCPleaseunknownのメッセージは、DHCPサーバーがクエリで指定された情報（IPアドレス、MACアドレス、またはクライアントIDENTIFIERオプションなど）の知識がないことを示しています。
The DHCPLEASEQUERY message does not presuppose a particular use for the information it returns -- it is simply designed to return information for which the DHCP server is an authoritative source to a client that requests that information. It is designed to make it straightforward for processes and devices that already interpret DHCP packets to access information from the DHCP server.
DHCPleasequeryメッセージは、返される情報の特定の使用を前提としていません。これは、DHCPサーバーがその情報を要求するクライアントの権威あるソースである情報を返すように設計されています。DHCPパケットを既に解釈してDHCPサーバーから情報にアクセスするプロセスとデバイスのために簡単にするように設計されています。
This document specifies an extension specifically to the DHCPv4 protocol [RFC2131]. Given the nature of the DHCPv6 protocol [RFC3315], there is no effective way to make the DHCPLEASEQUERY message interaction common between DHCPv4 and DHCPv6 even should the desire to do so exist.
このドキュメントは、DHCPV4プロトコル[RFC2131]の拡張機能を指定します。DHCPV6プロトコル[RFC3315]の性質を考えると、DHCPV4とDHCPV6の間でDHCPleasequeryメッセージの相互作用を一般的にする効果的な方法はありません。
The DHCPLEASEQUERY message was the result of a set of specific real-world implementation needs that appeared many years after the DHCPv4 protocol was in wide use. Furthermore, at the time of this writing, the DHCPv6 protocol has yet to be widely deployed. The needs of access concentrators in yet to be determined DHCPv6 deployment scenarios are difficult to estimate. If a DHCPLEASEQUERY-like function is necessary in DHCPv6, many of the ideas of this document will probably be applicable, while others may not. We have been cautioned against designing protocol capabilities for which there is only an imagined consumer, and that is all that exists today in the realm of DHCPLEASEQUERY for DHCPv6.
DHCPLEASEQUERYメッセージは、DHCPV4プロトコルが幅広く使用されてから何年も後に表示された特定の現実世界の実装ニーズのセットの結果でした。さらに、この執筆時点では、DHCPV6プロトコルはまだ広く展開されていません。まだ決定されていないDHCPV6展開シナリオのアクセスコンセントレーターのニーズを推定することは困難です。DHCPV6でDHCPLEASEQUERYのような機能が必要な場合、このドキュメントのアイデアの多くはおそらく適用されますが、他のものはそうではないかもしれません。私たちは、想像上の消費者しか存在しないプロトコル機能を設計することに警告されており、DHCPV6のDHCPleasequeryの領域には今日存在します。
Thus, this document applies only to DHCPv4, and for clarity we have not appended DHCPv4 to every appearance of several common terms. In this document, all references to IP addresses should be taken to mean IPv4 addresses, and all references to DHCP servers and DHCP clients should be taken to mean DHCPv4 servers and DHCPv4 clients.
したがって、このドキュメントはDHCPV4にのみ適用され、明確にするために、いくつかの一般的な用語のすべての外観にDHCPV4を追加していません。このドキュメントでは、IPアドレスへのすべての参照は、IPv4アドレスを平均するために取得する必要があり、DHCPサーバーとDHCPクライアントへのすべての参照は、DHCPV4サーバーとDHCPV4クライアントを平均化する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています。
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 DHCP relay agent functionality.
アクセスコンセントレーターは、パブリックブロードバンドアクセスネットワークのブロードバンドアクセスプロバイダーのエッジのルーターまたはスイッチです。このドキュメントは、アクセス濃縮器にDHCPリレーエージェント機能が含まれることを前提としています。
o "DHCP client"
o 「DHCPクライアント」
A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address.
DHCPクライアントは、DHCPを使用してネットワークアドレスなどの構成パラメーターを取得するインターネットホストです。
o "DHCP relay agent"
o 「DHCPリレーエージェント」
A DHCP relay agent is a third-party agent that transfers Bootstrap Protocol (BOOTP) and DHCP messages between clients and servers residing on different subnets, per [RFC951] and [RFC1542].
DHCPリレーエージェントは、[RFC951]および[RFC1542]ごとに、さまざまなサブネットに存在するクライアントとサーバー間のブートストラッププロトコル（BOOTP）とDHCPメッセージを転送するサードパーティエージェントです。
o "DHCP server"
o 「DHCPサーバー」
A DHCP server is an Internet host that returns configuration parameters to DHCP clients.
DHCPサーバーは、構成パラメーターをDHCPクライアントに返すインターネットホストです。
o "downstream"
o "下流"
Downstream is the direction from the access concentrator towards the broadband subscriber.
下流は、アクセス濃縮器からブロードバンドサブスクライバーへの方向です。
o "gleaning"
o 「グリーニング」
Gleaning is the extraction of location information from DHCP messages, as the messages are forwarded by the DHCP relay agent function.
Gleaningは、メッセージがDHCPリレーエージェント機能によって転送されるため、DHCPメッセージからの位置情報の抽出です。
o "location information"
o "位置情報"
Location information is information needed by the access concentrator to forward traffic to a broadband-accessible host. This information includes knowledge of the host hardware address, the port or virtual circuit that leads to the host, and/or the hardware address of the intervening subscriber modem.
位置情報は、Access Concenceratorがブロードバンドアクセス可能なホストに転送するために必要な情報です。この情報には、ホストハードウェアアドレス、ホストにつながるポートまたは仮想回路の知識、および/または介在するサブスクライバーモデムのハードウェアアドレスが含まれます。
o "MAC address"
o "Macアドレス"
In the context of a DHCP packet, a MAC address consists of the following fields: hardware type "htype", hardware length "hlen", and client hardware address "chaddr".
DHCPパケットのコンテキストでは、MACアドレスは次のフィールドで構成されています：ハードウェアタイプ「HTYPE」、ハードウェア長「HLEN」、クライアントハードウェアアドレス「Chaddr」。
o "stable storage"
o 「安定したストレージ」
Every DHCP server is assumed to have some form of what is called "stable storage". 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 server failure that requires restart of the server.
すべてのDHCPサーバーには、「安定したストレージ」と呼ばれる何らかの形の形があると想定されています。安定したストレージは、（とりわけ）IPアドレスのバインディングに関する情報を保持するために使用され、サーバーの再起動が必要なサーバー障害が発生した場合にこの情報が失われないようにします。
o "upstream"
o "上流の"
Upstream is the direction from the broadband subscriber towards the access concentrator.
上流は、ブロードバンドサブスクライバーからアクセス濃縮器への方向です。
The focus of this document is to enable processes and devices that wish to access information from the DHCP server in a lightweight and convenient manner. It is especially appropriate for processes and devices that already interpret DHCP packets.
このドキュメントの焦点は、軽量で便利な方法でDHCPサーバーから情報にアクセスしたいプロセスとデバイスを有効にすることです。DHCPパケットを既に解釈するプロセスとデバイスに特に適しています。
One important motivating example is that the DHCPLEASEQUERY message allows access concentrators to send DHCPLEASEQUERY messages to DHCP servers to obtain location information of broadband access network devices.
重要な動機付けの例の1つは、DHCPleasequeryメッセージにより、アクセスコンセントレータがDHCPleasequeryメッセージをDHCPサーバーに送信して、ブロードバンドアクセスネットワークデバイスの位置情報を取得できることです。
This document assumes that many access concentrators have an embedded DHCP relay agent functionality. Typical access concentrators include DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB Interactive Network Adapters (INAs) [EUROMODEM], and DSL Access Concentrators.
このドキュメントは、多くのアクセスコンセントレーターに埋め込まれたDHCPリレーエージェント機能があることを前提としています。典型的なアクセス濃縮器には、DOCSISケーブルモデム終了システム（CMTSS）[DOCSIS]、DVBインタラクティブネットワークアダプター（INAS）[Euromodem]、およびDSLアクセス濃縮器が含まれます。
The DHCPLEASEQUERY message is an extension to the DHCP protocol [RFC2131].
DHCPLEASEQUERYメッセージは、DHCPプロトコル[RFC2131]の拡張です。
The DHCPLEASEQUERY message is a query message only and does not affect the state of the IP address or the binding information associated with it.
dhcpleasequeryメッセージはクエリメッセージのみであり、IPアドレスの状態またはそれに関連する拘束力のある情報に影響しません。
The goal of this document is to provide a lightweight mechanism for processes or devices to access information contained in the DHCP server. It is designed to allow processes and devices that already process and interpret DHCP messages to access this information in a rapid and lightweight manner.
このドキュメントの目標は、プロセスまたはデバイスがDHCPサーバーに含まれる情報にアクセスするための軽量メカニズムを提供することです。DHCPメッセージを既に処理および解釈するプロセスとデバイスを許可し、この情報に迅速かつ軽量な方法でアクセスできるように設計されています。
Some of this information might be acquired in a different way, and the following sections discuss some of these alternative approaches.
この情報の一部は別の方法で取得される可能性があり、次のセクションでは、これらの代替アプローチのいくつかについて説明します。
The access concentrator can transmit a broadcast Address Resolution Protocol (ARP) Request [RFC826], and observe the origin and contents of the ARP Reply, to reconstruct the location information.
Access Concentoratorは、ブロードキャストアドレス解像度プロトコル（ARP）要求[RFC826]を送信し、ARP応答の起源と内容を観察して、位置情報を再構築できます。
The ARP mechanism is undesirable for three reasons:
ARPメカニズムは、3つの理由で望ましくありません。
1. the burden on the access concentrator to transmit over multiple access ports and virtual circuits (assuming that IP subnets span multiple ports or virtual circuits),
1. アクセスコンセントレーターの負担は、複数のアクセスポートと仮想回路を送信します（IPサブネットが複数のポートまたは仮想回路にまたがると仮定）、
2. the burden on the numerous subscriber hosts to receive and process the broadcast, and
2. 放送を受け取り、処理するための多数のサブスクライバーホストの負担と
3. the ease by which a malicious host can misrepresent itself as the IP endpoint.
3. 悪意のあるホストがIPエンドポイントと誤って伝えられる容易さ。
Access concentrator implementations typically do not have Simple Network Management Protocol (SNMP) management client interfaces nor Lightweight Directory Access Protocol (LDAP) client interfaces (although they typically do include SNMP management agents). This is one reason why this document does not leverage the proposed DHCP Server MIB [DHCPMIB].
アクセスコンセントレーターの実装には、通常、単純なネットワーク管理プロトコル（SNMP）管理クライアントインターフェイスも、軽量ディレクトリアクセスプロトコル（LDAP）クライアントインターフェイスもありません（通常、SNMP管理エージェントを含みます）。これが、このドキュメントが提案されているDHCPサーバーMIB [DHCPMIB]を活用しない理由の1つです。
The DHCP Server MIB effort [DHCPMIB] grew out of traffic engineering and troubleshooting activities at large DHCP installations, and is primarily intended as a method of gathering performance statistics about servers the load presented to them.
DHCPサーバーMIBの取り組み[DHCPMIB]は、大規模なDHCPインスタレーションでの交通工学とトラブルシューティングアクティビティから生まれ、主にそれらに提示されたサーバーに関するパフォーマンス統計を収集する方法として意図されています。
Despite the presence in the proposed DHCPv4 server MIB of objects that report configuration and status information, the MIB is intended to provide more generic, server-wide aggregated or summarized data. DHCPLEASEQUERY is intended to provide detailed, specific information about individual leases at a level that would be difficult or impossible to shoehorn into a MIB.
構成情報とステータス情報を報告するオブジェクトの提案されているDHCPV4サーバーMIBの存在にもかかわらず、MIBはより一般的でサーバー全体の集約化または要約データを提供することを目的としています。DHCPleasequeryは、MIBに靴を履くことが困難または不可能なレベルで個々のリースに関する詳細な具体的な情報を提供することを目的としています。
From an implementation standpoint, the DHCPLEASEQUERY message is not required to be supported by all DHCPv4 servers. Since it appears that defining optional MIB objects and objects for optional features in a MIB is discouraged, trying to support DHCPLEASEQUERY functionality optionally through a MIB would be similarly discouraged from an SNMP MIB standpoint.
実装の観点から、DHCPleasequeryメッセージはすべてのDHCPV4サーバーでサポートする必要はありません。MIBでオプションの機能にオプションのMIBオブジェクトとオブジェクトを定義することは落胆しているため、MIBを介してDHCPleasequeryの機能をサポートしようとすることは、SNMP MIBの観点から同様に落胆します。
Access concentrators commonly act as DHCP relay agents. Furthermore, many access concentrators already glean location information from DHCP server responses, as part of the relay agent function.
アクセス濃縮器は一般にDHCPリレー剤として機能します。さらに、多くのアクセスコンセントレーターは、リレーエージェント関数の一部として、DHCPサーバーの応答から位置情報をすでに収集しています。
The gleaning mechanism as a technique to determine the IP addresses valid for a particular downstream link is preferred over other mechanisms (ARP, SNMP, LDAP) because of the lack of additional network traffic, but sometimes gleaning information can be incomplete. The access concentrator usually cannot glean information from any DHCP unicast (i.e., non-relayed) messages due to performance reasons. Furthermore, the DHCP-gleaned location information often does not persist across access concentrator reboots (due to lack of stable storage), and almost never persists across concentrator replacements.
特定のダウンストリームリンクに有効なIPアドレスを決定する手法としてのグリーニングメカニズムは、追加のネットワークトラフィックがないため、他のメカニズム（ARP、SNMP、LDAP）よりも好まれますが、時には収集情報は不完全になる可能性があります。アクセスコンセントレーターは通常、パフォーマンスの理由により、DHCPユニキャスト（つまり、非関連）メッセージから情報を収集することはできません。さらに、DHCPで手入れされた位置情報は、アクセスコンセントレーターの再起動全体で持続せず（安定した保管が不足しているため）、コンセントレーターの交換全体でほとんど持続することはありません。
DHCP servers are the most reliable source of location information for access concentrators, particularly when the location information is dynamic and not reproducible by algorithmic means (e.g., when a single IP subnet extends behind many broadband modems). DHCP servers participate in all IP lease transactions (and therefore in all location information updates) with DHCP clients, whereas access concentrators sometimes miss some important lease transactions.
DHCPサーバーは、特に位置情報が動的であり、アルゴリズム手段で再現できない場合（たとえば、単一のIPサブネットが多くのブロードバンドモデムの背後に拡張されている場合）、アクセス濃縮器の位置情報の最も信頼性の高いソースです。DHCPサーバーは、DHCPクライアントとのすべてのIPリーストランザクション（したがってすべての位置情報の更新）に参加しますが、アクセスコンセントレーターは重要なリーストランザクションを逃すことがあります。
An access concentrator can be configured with the IP addresses of multiple different DHCP servers, so that no one DHCP server is a single point of failure.
アクセスコンセントレーターは、複数の異なるDHCPサーバーのIPアドレスで構成できます。これにより、DHCPサーバーは単一の障害ポイントではありません。
Access concentrators can usually query the same set of DHCP servers used for forwarding by the relay agent, thus minimizing configuration requirements.
アクセスコンセントレーターは通常、リレーエージェントによる転送に使用されるDHCPサーバーの同じセットを照会でき、構成要件を最小限に抑えることができます。
In the following discussion of the DHCPLEASEQUERY message, the client of the message is assumed to be an access concentrator. Note that access concentrators are not the only allowed (or required) consumers of the information provided by the DHCPLEASEQUERY message, but they do give readers a concrete feel for how the message might be used.
DHCPleasequeryメッセージの以下の議論では、メッセージのクライアントはアクセスコンセントレーターであると想定されています。DHCPleasequeryメッセージによって提供される情報のアクセスコンセントレーターは、許可されている（または必要な）消費者だけではありませんが、メッセージがどのように使用されるかについては、読者に具体的な感触を与えていることに注意してください。
The access concentrator initiates all DHCPLEASEQUERY message conversations. This document assumes that the access concentrator gleans location information in its DHCP relay agent function. However, the location information is usually unavailable after the reboot or replacement of the access concentrator.
Access Concentorは、すべてのDHCPleasequeryメッセージの会話を開始します。このドキュメントでは、Access ConcentoratorがDHCPリレーエージェント関数の位置情報をつかむことを前提としています。ただし、通常、位置情報は、アクセス濃縮器の再起動または交換後に利用できません。
Suppose the access concentrator is a router, and further suppose that the router receives an IP datagram to forward downstream to the public broadband access network. If the location information for the downstream next hop is missing, the access concentrator sends one or more DHCPLEASEQUERY message(s), each containing the IP address of the downstream next hop in the "ciaddr" field.
Access Concentoratorがルーターであると仮定し、さらにルーターがIPデータグラムを受信して、下流のパブリックブロードバンドアクセスネットワークに転送すると仮定します。ダウンストリームネクストホップの位置情報が欠落している場合、アクセスコンセントレーターは1つ以上のDHCPLEASEQUERYメッセージを送信します。それぞれが「CIADDR」フィールドの次のホップの下流ホップのIPアドレスを含みます。
This query will then be answered by returning the information current when this client's lease was last granted or renewed, allowing the access concentrator to forward the IP datagram.
このクエリは、このクライアントのリースが最後に付与または更新されたときに情報電流を返すことにより回答され、Access ConcentorがIPデータグラムを転送できるようにします。
An alternative approach is to send in a DHCPLEASEQUERY message with the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen", and "chaddr" fields) with a valid MAC address or a Client-identifier option (option 61) appearing in the options area. In this case, the DHCP server must return an IP address in the ciaddr if it has any record of the client described by the Client-identifier or MAC address. In the absence of specific configuration information to the contrary (see Section 6.4), it SHOULD be the IP address with the latest client-last-transaction-time associated with the client described by the MAC address or Client-identifier option.
別のアプローチは、有効なMACアドレスまたはクライアントIdentifierオプション（つまり、「HTYPE」、「HLEN」、および「CHADDR」フィールド）を空にした「CIADDR」フィールドとMACアドレス（つまり、「HTYPE」、「HLEN」、および「CHADDR」フィールド）を備えたDHCPLEASEQUERYメッセージを送信することです。オプション61）オプションエリアに表示されます。この場合、DHCPサーバーには、クライアントが識別子またはMACアドレスが記述したクライアントのレコードがある場合は、CIADDRのIPアドレスを返す必要があります。反対に特定の構成情報がない場合（セクション6.4を参照）、それはMACアドレスまたはクライアント識別子オプションで説明されているクライアントに関連付けられた最新のクライアント-Lastトランザクション時間を持つIPアドレスである必要があります。
The DHCP servers that implement this protocol always send a response to the DHCPLEASEQUERY message: either a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN. The reasons why a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message might be generated are explained in the specific query regimes, below.
このプロトコルを実装するDHCPサーバーは、常にDHCPleasequeryメッセージに応答を送信します。dhcpleaseunassigned、dhcpreaseactive、またはdhcpreaseunknownメッセージが生成される理由を、以下の特定のクエリ制度で説明する可能性があります。
Servers that do not implement the DHCPLEASEQUERY message SHOULD simply not respond.
DHCPleasequeryメッセージを実装していないサーバーは、単に応答しないはずです。
The DHCPLEASEQUERY message can support three query regimes: A server that implements the DHCPLEASEQUERY message must implement all three query regimes.
DHCPleasequeryメッセージは、3つのクエリ制度をサポートできます。DHCPleasequeryメッセージを実装するサーバーは、3つのクエリ制度すべてを実装する必要があります。
o Query by IP address:
o IPアドレスによるクエリ：
For this query, the requester supplies only an IP address in the DHCPLEASEQUERY message. The DHCP server will return any information that it has on the most recent client to have been assigned that IP address.
このクエリでは、requesterはDHCPleasequeryメッセージにIPアドレスのみを提供します。DHCPサーバーは、そのIPアドレスを割り当てられた最新のクライアントにある情報を返します。
The DHCP server replies with a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message if the IP address in the DHCPLEASEQUERY message corresponds to an IP address about which the server has definitive information (i.e., it is authorized to lease this IP address). The server replies with a DHCPLEASEUNKNOWN message if the server does not have definitive information concerning the address in the DHCPLEASEQUERY message.
DHCPサーバーは、DHCPleasequeryメッセージのIPアドレスがサーバーに決定的な情報を持っているIPアドレスに対応している場合、DHCPleaseUnassignedまたはDHCPleaseativeメッセージで返信します（つまり、このIPアドレスをリースすることが許可されています）。サーバーがDHCPleasequeryメッセージのアドレスに関する決定的な情報がない場合、サーバーはDHCPleaseunknownメッセージで返信します。
o Query by MAC address:
o Macアドレスによるクエリ：
For this query, the requester supplies only a MAC address in the DHCPLEASEQUERY message. The DHCP server will return any information that it has on the IP address most recently accessed by a client with that MAC address. In addition, it may supply additional IP addresses that have been associated with that MAC address in different subnets. Information about these bindings can then be found using the Query by IP Address, described above.
このクエリでは、requesterはDHCPleasequeryメッセージにMACアドレスのみを提供します。DHCPサーバーは、そのMACアドレスを持つクライアントが最近アクセスしたIPアドレスにある情報を返します。さらに、異なるサブネットのMACアドレスに関連付けられている追加のIPアドレスを提供する場合があります。これらのバインディングに関する情報は、上記のIPアドレスによるクエリを使用して見つけることができます。
The DHCP server replies with a DHCPLEASEACTIVE message if the MAC address in the DHCPLEASEQUERY message corresponds to a MAC address with an active lease on an IP address in this server. The server replies with a DHCPLEASEUNKNOWN message if the server does not presently have an active lease by a client with this MAC address in this DHCP server.
DHCPサーバーは、DHCPLEASEQUERYメッセージのMACアドレスがこのサーバーのIPアドレスにアクティブなリースを持つMACアドレスに対応する場合、DHCPleaSeactiveメッセージで返信します。サーバーがこのDHCPサーバーにこのMACアドレスを持つクライアントが現在アクティブなリースを持っていない場合、サーバーはDHCPleaseunknownのメッセージで返信します。
o Query by Client-identifier option:
o クライアントIdentifierによるクエリオプション：
For this query, the requester supplies only a Client-identifier option in the DHCPLEASEQUERY message. The DHCP server will return any information that it has on the IP address most recently accessed by a client with that Client-identifier. In addition, it may supply additional IP addresses that have been associated with Client-identifier in different subnets. Information about these bindings can then be found using the Query by IP Address, described above.
このクエリでは、requesterはDHCPleasequeryメッセージにクライアントIDENTIFIERオプションのみを提供します。DHCPサーバーは、そのクライアントIDENTIFIERを持つクライアントが最近アクセスしたIPアドレスにある情報を返します。さらに、さまざまなサブネットのクライアントIDに関連付けられている追加のIPアドレスを提供する場合があります。これらのバインディングに関する情報は、上記のIPアドレスによるクエリを使用して見つけることができます。
The DHCP server replies with a DHCPLEASEACTIVE message if the Client-identifier in the DHCPLEASEQUERY message currently has an active lease on an IP address in this DHCP server. The server replies with a DHCPLEASEUNKNOWN message if the server does not have an active lease by a client with this Client-identifier.
DHCPサーバーは、DHCPleasequeryメッセージのクライアントIDENTIFIERが現在このDHCPサーバーのIPアドレスにアクティブなリースを持っている場合、DHCPleaSeactiveメッセージで返信します。サーバーが、このクライアントIDENTIFIERを使用してクライアントがアクティブなリースを持っていない場合、サーバーはDHCPLEASEUNKNOWNのメッセージで返信します。
For many DHCP servers, the query by IP address is likely to be the most efficient form of leasequery. This is the form of DHCPLEASEQUERY that SHOULD be used if possible.
多くのDHCPサーバーの場合、IPアドレスによるクエリは、最も効率的な形式のリースクリーである可能性があります。これは、可能であれば使用する必要があるDHCPleasequeryの形式です。
The DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message reply must always contain the IP address in the "ciaddr" field. The DHCPLEASEACTIVE message SHOULD contain the physical address of the IP address lease owner in the "htype", "hlen", and "chaddr" fields. The Parameter Request List (option 55) can be used to request specific options to be returned about the IP address in the ciaddr. The reply often contains the time until expiration of the lease, and the original contents of the Relay Agent Information option [RFC3046]. The access concentrator uses the "chaddr" field and Relay Agent Information option to construct location information, which can be cached on the access concentrator until lease expiration.
DHCPLEASENASSIGNEDまたはDHCPLEASECTIVEメッセージの返信には、常に「CIADDR」フィールドにIPアドレスが含まれている必要があります。DHCPleaSeactiveメッセージには、「HTYPE」、「HLEN」、および「Chaddr」フィールドのIPアドレスリース所有者の物理アドレスを含める必要があります。パラメーターリクエストリスト（オプション55）を使用して、CIADDRのIPアドレスに関する特定のオプションをリクエストすることができます。返信には、多くの場合、リースが満了するまでの時間と、リレーエージェント情報オプションの元の内容[RFC3046]が含まれています。Access Concentoratorは、「Chaddr」フィールドおよびリレーエージェント情報オプションを使用して位置情報を構築します。
Any DHCP server that supports the DHCPLEASEQUERY message SHOULD save the information from the most recent Relay Agent Information option (option 82) [RFC3046] associated with every IP address that it serves. It is assumed that most clients that generate the DHCPLEASEQUERY message will ask for the Relay Agent Information option (option 82) in the Parameter Request List (option 55), and so supporting the DHCPLEASEQUERY message without having the Relay Agent Information option around to return to the client is likely to be less than helpful.
DHCPleasequeryメッセージをサポートするDHCPサーバーは、提供するすべてのIPアドレスに関連付けられた最新のリレーエージェント情報オプション（オプション82）[RFC3046]から情報を保存する必要があります。DHCPleasequeryメッセージを生成するほとんどのクライアントは、パラメーターリクエストリスト（オプション55）でリレーエージェント情報オプション（オプション82）を要求し、リレーエージェント情報オプションを持たずにDHCPleaseQueryメッセージをサポートすることを想定しています。クライアントは、役に立つよりも少ない可能性があります。
A server that implements DHCPLEASEQUERY SHOULD also save the information on the most recent Vendor class identifier, option 60, associated with each IP address, since this option is also likely to be requested by clients sending the DHCPLEASEQUERY message.
DHCPleasequeryを実装するサーバーは、各IPアドレスに関連付けられた最新のベンダークラス識別子であるオプション60の情報も保存する必要があります。
The operation of the DHCPLEASEQUERY message requires the definition of the following new and extended values for the DHCP packet beyond those defined by [RFC2131] and [RFC2132]. See also Section 8, IANA Considerations.
DHCPleasequeryメッセージの動作には、[RFC2131]および[RFC2132]で定義されたものを超えたDHCPパケットの次の新しい値と拡張値の定義が必要です。セクション8、IANAの考慮事項も参照してください。
1. The message type option (option 53) from [RFC2132] requires four new values: one for the DHCPLEASEQUERY message itself and one for each of its three possible responses DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, DHCPLEASEUNKNOWN. The values of these message types are shown below in an extension of the table from section 9.6 of [RFC2132]:
1. [RFC2132]のメッセージタイプオプション（オプション53）には、4つの新しい値が必要です。1つはDHCPleaseQueryメッセージ自体と、1つはそれぞれ3つの可能な応答、DHCPleaseUnassigned、DHCPleasective、DHCPleaseunknownです。これらのメッセージタイプの値は、[RFC2132]のセクション9.6のテーブルの延長に以下に示されています。
Value Message Type
----- ------------
10 DHCPLEASEQUERY
11 DHCPLEASEUNASSIGNED
12 DHCPLEASEUNKNOWN
13 DHCPLEASEACTIVE
2. There is a new option, the client-last-transaction-time:
2. 新しいオプション、クライアントラストトランザクション時間：
client-last-transaction-time
クライアントラストトランザクション時間
This option allows the receiver to determine the time of the most recent access of the client. It is particularly useful when DHCPLEASEACTIVE messages from two different DHCP servers need to be compared, although it can be useful in other situations. The value is a duration in seconds from the current time into the past when this IP address was most recently the subject of communication between the client and the DHCP server.
このオプションにより、受信者はクライアントの最新のアクセスの時間を決定できます。2つの異なるDHCPサーバーからのDHC遊液メッセージを比較する必要がある場合に特に役立ちますが、他の状況では役立ちます。このIPアドレスが最近ではクライアントとDHCPサーバーの間の通信の対象であった過去までの現在の時期から数秒で値があります。
This MUST NOT be an absolute time. This MUST NOT be an absolute number of seconds since Jan. 1, 1970. Instead, this MUST be an integer number of seconds in the past from the time the DHCPLEASEACTIVE message is sent that the client last dealt with this server about this IP address. In the same way that the IP Address Lease Time option (option 51) encodes a lease time that is a number of seconds into the future from the time the message was sent, this option encodes a value that is a number of seconds into the past from when the message was sent.
これは絶対的な時間であってはなりません。これは、1970年1月1日以来、絶対数秒であってはなりません。代わりに、これは、クライアントが最後にこのIPアドレスについてこのサーバーに対処したDHCPreasectiveメッセージが送信された時から、過去の整数秒数でなければなりません。IPアドレスリース時間オプション（オプション51）が、メッセージが送信された時から将来数秒になるリース時間をエンコードするのと同じように、このオプションは過去数秒の値をエンコードしますメッセージが送信されたときから。
The code for the this option is 91. The length of the this option is 4 octets.
このオプションのコードは91です。このオプションの長さは4オクテットです。
Code Len Seconds in the past
+-----+-----+-----+-----+-----+-----+
| 91 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
3. There in a second new option, the associated-ip option:
3. 2番目の新しいオプションで、関連するIPオプション：
associated-ip
ASSOICTION-IP
This option is used to return all of the IP addresses associated with the DHCP client specified in a particular DHCPLEASEQUERY message.
このオプションは、特定のDHCPleasequeryメッセージで指定されたDHCPクライアントに関連付けられたすべてのIPアドレスを返すために使用されます。
The code for this option is 92. The minimum length for this option is 4 octets, and the length MUST always be a multiple of 4.
このオプションのコードは92です。このオプションの最小長は4オクテットで、長さは常に4の倍数でなければなりません。
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 92 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
The DHCPLEASEQUERY message is typically sent by an access concentrator. The DHCPLEASEQUERY message uses the DHCP message format as described in [RFC2131], and uses message number 10 in the DHCP Message Type option (option 53). The DHCPLEASEQUERY message has the following pertinent message contents:
dhcpleasequeryメッセージは通常、アクセス濃縮器によって送信されます。DHCPleasequeryメッセージは、[RFC2131]で説明されているDHCPメッセージ形式を使用し、DHCPメッセージタイプオプション（オプション53）でメッセージ番号10を使用します。dhcpleasequeryメッセージには、次の関連するメッセージの内容があります。
o The giaddr MUST be set to the IP address of the requester (i.e., the access concentrator). The giaddr is independent of the "ciaddr" field to be searched -- it is simply the return address of the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message from the DHCP server.
o GIADDRは、要求者のIPアドレス（つまり、アクセス濃縮器）に設定する必要があります。GIADDRは、検索される「CIADDR」フィールドから独立しています。これは、DHCPサーバーからのDHCPleaseUnassigned、DHCPleasective、またはDHCPleaseunknownのメッセージの単なる返品アドレスです。
Note that this use of the giaddr is consistent with the definition of giaddr in [RFC2131], where the giaddr is always used as the return address of the DHCP response message. In some (but not all) contexts in RFC 2131, the giaddr is used as the "key" to access the appropriate address pool. The DHCPLEASEQUERY message is one of those cases where the giaddr MUST NOT be used as such a "key".
このGiadDRの使用は、[RFC2131]のGiadDRの定義と一致していることに注意してください。GIADDRは常にDHCP応答メッセージの返品アドレスとして使用されます。RFC 2131の一部の（すべてではない）コンテキストでは、GIADDRは適切なアドレスプールにアクセスするための「キー」として使用されます。DHCPleasequeryメッセージは、GIADDRをそのような「キー」として使用してはならない場合の1つです。
o The Parameter Request List option (option 55) SHOULD be set to the options of interest to the requester. The interesting options are likely to include the IP Address Lease Time option (option 51), the Relay Agent Information option (option 82), and possibly the Vendor class identifier option (option 60). In the absence of a Parameter Request List option, the server SHOULD return the same options it would return for a DHCPREQUEST message that didn't contain a DHCPLEASEQUERY message, which includes those mandated by Section 4.3.1 of [RFC2131] as well as any options that the server was configured to always return to a client.
o パラメーターリクエストリストオプション（オプション55）は、要求者にとって関心のあるオプションに設定する必要があります。興味深いオプションには、IPアドレスリース時間オプション（オプション51）、リレーエージェント情報オプション（オプション82）、および場合によってはベンダークラス識別子オプション（オプション60）が含まれる可能性があります。パラメーターリクエストリストオプションがない場合、サーバーは、[RFC2131]のセクション4.3.1で義務付けられているものを含むDHCPleasequeryメッセージを含むDHCPRequestメッセージに戻るのと同じオプションを返す必要があります。サーバーが常にクライアントに戻るように構成されたオプション。
Additional details concerning different query types are:
さまざまなクエリタイプに関する追加の詳細は次のとおりです。
o Query by IP address:
o IPアドレスによるクエリ：
The values of htype, hlen, and chaddr MUST be set to zero.
HTYPE、HLEN、およびCHADDRの値はゼロに設定する必要があります。
The "ciaddr" field MUST be set to the IP address of the lease to be queried.
「CIADDR」フィールドは、クエリのリースのIPアドレスに設定する必要があります。
The Client-identifier option (option 61) MUST NOT appear in the packet.
クライアントIdentifierオプション（オプション61）は、パケットに表示されてはなりません。
o Query by MAC address:
o Macアドレスによるクエリ：
The values of htype, hlen, and chaddr MUST be set to the value of the MAC address to search for.
HTYPE、HLEN、およびCHADDRの値は、検索するためにMACアドレスの値に設定する必要があります。
The "ciaddr" field MUST be set to zero.
「CIADDR」フィールドはゼロに設定する必要があります。
The Client-identifier option (option 61) MUST NOT appear in the packet.
クライアントIdentifierオプション（オプション61）は、パケットに表示されてはなりません。
o Query by Client-identifier option:
o クライアントIdentifierによるクエリオプション：
There MUST be a Client-identifier option (option 61) in the DHCPLEASEQUERY message.
DHCPleasequeryメッセージには、クライアントIDENTIFIERオプション（オプション61）が必要です。
The "ciaddr" field MUST be set to zero.
「CIADDR」フィールドはゼロに設定する必要があります。
The values of htype, hlen, and chaddr MUST be set to zero.
HTYPE、HLEN、およびCHADDRの値はゼロに設定する必要があります。
The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is known to possess authoritative information concerning the IP address. The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, and in the absence of information concerning which DHCP server might possess authoritative information concerning the IP address, it SHOULD be sent to all DHCP servers configured for the associated relay agent (if any are known).
DHCPleasequeryメッセージは、IPアドレスに関する権威ある情報を所有することが知られているDHCPサーバーに送信する必要があります。DHCPleasequeryメッセージは複数のDHCPサーバーに送信され、どのDHCPサーバーがIPアドレスに関する権威ある情報を所有しているかに関する情報がない場合、関連するリレーエージェント用に構成されたすべてのDHCPサーバーに送信する必要があります（存在する場合は、既知）。
Any device expecting to use a DHCPLEASEQUERY message SHOULD ensure that the Relay Agent Info option that it uses contains information that unambiguously identifies the device.
DHCPleasequeryメッセージを使用することを期待するデバイスは、使用するリレーエージェント情報オプションに、デバイスを明確に識別する情報が含まれていることを確認する必要があります。
A server that implements the DHCPLEASEQUERY message MUST implement all three query regimes: query by IP address, query by MAC address, and query by Client-identifier.
DHCPleasequeryメッセージを実装するサーバーは、3つのクエリシステムすべてを実装する必要があります。IPアドレスごとのクエリ、MACアドレスごとのクエリ、クライアントIdentifierによるクエリです。
A DHCPLEASEQUERY message MUST have a non-zero giaddr. The DHCPLEASEQUERY message MUST have exactly one of the following: a non-zero ciaddr, a non-zero htype/hlen/chaddr, or a Client-identifier option.
dhcpleasequeryメッセージには、ゼロ以外のgiaddrが必要です。dhcpleasequeryメッセージには、次のいずれかのいずれかを正確に備えている必要があります。非ゼロCiaddr、非ゼロHType/hlen/chaddr、またはクライアントIdentifierオプションです。
The DHCP server that receives a DHCPLEASEQUERY message MUST base its response on the particular data item used in the query.
DHCPleasequeryメッセージを受信するDHCPサーバーは、クエリで使用される特定のデータ項目に応答する必要があります。
The giaddr is used only for the destination address of any generated response and, while required, is not otherwise used in generating the response to the DHCPLEASEQUERY message. It MUST NOT be used to restrict the processing of the query in any way, and MUST NOT be used locate a subnet to which the ciaddr (if any) must belong.
GIADDRは、生成された応答の宛先アドレスにのみ使用され、必要ですが、DHCPleasequeryメッセージへの応答の生成には使用されません。クエリの処理をいかなる方法でも制限するために使用してはなりません。使用してはなりません。CIADDR（もしあれば）が属する必要があるサブネットを見つけてはなりません。
Note that this use of the giaddr is consistent with the definition of giaddr in [RFC2131], where the giaddr is always used as the return address of the DHCP response message. In some (but not all) contexts in RFC 2131, the giaddr is used as the "key" to access the appropriate address pool. The DHCPLEASEQUERY message is one of those cases where the giaddr MUST NOT be used as such a "key".
このGiadDRの使用は、[RFC2131]のGiadDRの定義と一致していることに注意してください。GIADDRは常にDHCP応答メッセージの返品アドレスとして使用されます。RFC 2131の一部の（すべてではない）コンテキストでは、GIADDRは適切なアドレスプールにアクセスするための「キー」として使用されます。DHCPleasequeryメッセージは、GIADDRをそのような「キー」として使用してはならない場合の1つです。
There are three possible responses to a DHCPLEASEQUERY message:
dhcpleasequeryメッセージには3つの応答があります。
o DHCPLEASEUNASSIGNED
o dhcpleaseunassigned
The server MUST respond with a DHCPLEASEUNASSIGNED message if this server has information about the IP address, but there is no active lease for the IP address. The DHCPLEASEUNASSIGNED message is only returned for a query by IP address, and indicates that the server manages this IP address, but there is no currently active lease on this IP address.
このサーバーがIPアドレスに関する情報を持っている場合、サーバーはDHCPleaseUnassignedメッセージで応答する必要がありますが、IPアドレスにアクティブなリースはありません。DHCPleaseUnassignedメッセージは、IPアドレスによるクエリに対してのみ返され、サーバーがこのIPアドレスを管理していることを示しますが、このIPアドレスに現在アクティブなリースはありません。
o DHCPLEASEUNKNOWN
o dhcpleaseunknown
The DHCPLEASEUNKNOWN message indicates that the server does not manage the IP address or the client specified in the DHCPLEASEQUERY message does not currently have a lease on an IP address.
DHCPleaseunknownのメッセージは、サーバーがIPアドレスを管理していないか、DHCPleasequeryメッセージで指定されているクライアントが現在IPアドレスにリースがないことを示しています。
When responding with a DHCPLEASEUNKNOWN, the DHCP server MUST NOT include other DHCP options in the response.
DHCPleaseunknownで応答する場合、DHCPサーバーには、応答に他のDHCPオプションを含めてはなりません。
o DHCPLEASEACTIVE
o dhcpleasective
The DHCPLEASEACTIVE message indicates that the server not only knows about the IP address and client specified in the DHCPLEASEACTIVE message, but also knows that there is an active lease by that client for that IP address.
DHCPleaSeactiveメッセージは、サーバーがDHCPreaseativeメッセージで指定されているIPアドレスとクライアントを知っているだけでなく、そのクライアントがそのIPアドレスにアクティブなリースがあることも知っていることを示しています。
The server MUST respond with a DHCPLEASEACTIVE message when the IP address returned in the "ciaddr" field is currently leased.
サーバーは、「CIADDR」フィールドで返されたIPアドレスが現在リースされているときに、DHCPleaSeactiveメッセージで応答する必要があります。
Since the response to a DHCPLEASEQUERY request can only contain full information about one IP address -- the one that appears in the "ciaddr" field -- determination of which IP address about which to respond is a key issue. Of course, the values of additional IP addresses for which a client has a lease must also be returned in the associated-ip option (Section 6.1, #3). This is the only information returned not directly associated with the IP address in the "ciaddr" field.
DHCPleasequeryリクエストへの応答には、1つのIPアドレス（「CIADDR」フィールドに表示されるIPアドレスに関する完全な情報のみが含まれているため、応答するIPアドレスが重要な問題であるかどうかが重要です。もちろん、クライアントがリースを持っている追加のIPアドレスの値も、関連するIPオプション（セクション6.1、＃3）で返品する必要があります。これは、「CIADDR」フィールドのIPアドレスに直接関連付けられていない返された唯一の情報です。
In the event that an IP address appears in the "ciaddr" field of a DHCPLEASEQUERY message, if that IP address is one managed by the DHCP server, then that IP address MUST be set in the "ciaddr" field of a DHCPLEASEUNASSIGNED message.
DHCPleasequeryメッセージの「CIADDR」フィールドにIPアドレスが表示された場合、そのIPアドレスがDHCPサーバーによって管理されている場合、そのIPアドレスはDHCPleaseNassignedメッセージの「CIADDR」フィールドに設定する必要があります。
If the IP address is not managed by the DHCP server, then a DHCPLEASEUNKNOWN message must be returned.
IPアドレスがDHCPサーバーによって管理されていない場合、DHCPleaseunknownのメッセージを返す必要があります。
If the "ciaddr" field of the DHCPLEASEQUERY is zero, then the DHCPLEASEQUERY message is a query by Client-identifier or MAC address. In this case, the client's identity is any client that has proffered an identical Client-identifier option (if the Client-identifier option appears in the DHCPLEASEQUERY message), or an identical MAC address (if the MAC address fields in the DHCPLEASEQUERY message are non-zero). This client matching approach will, for the purposes of this section, be described as "Client-identifier or MAC address".
DHCPleasequeryの「CIADDR」フィールドがゼロの場合、DHCPLEASEQUERYメッセージはクライアントIDENTIFIERまたはMACアドレスによるクエリです。この場合、クライアントのIDは、同一のクライアントIDENTIFIERオプションを提供したクライアント（クライアントIDENTIFIERオプションがDHCPleasequeryメッセージに表示される場合）または同一のMACアドレス（DHCPleasequeryメッセージのMacアドレスフィールドが非Nonの場合-ゼロ）。このクライアントマッチングアプローチは、このセクションの目的のために、「クライアントIdentifierまたはMacアドレス」と呼ばれます。
If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE message MUST be that of an IP address for which the client that most recently used the IP address matches the Client-identifier or MAC address specified in the DHCPLEASEQUERY message.
dhcpleasequeryメッセージで「ciaddr」フィールドがゼロの場合、dhcpleaseativeメッセージの「ciaddr」フィールドに配置されたIPアドレスは、最近IPアドレスを使用したクライアントがクライアントと一致するIPアドレスのアドレスでなければなりません。dhcpleasequeryメッセージで指定された識別子またはMacアドレス。
If there is only a single IP address that fulfills this criteria, then it MUST be placed in the "ciaddr" field of the DHCPLEASEACTIVE message.
この基準を満たす単一のIPアドレスのみがある場合、DHC遊液メッセージの「CIADDR」フィールドに配置する必要があります。
In the case where more than one IP address has been accessed by the client specified by the MAC address or Client-identifier option, then the DHCP server MUST return the IP address returned to the client in the most recent transaction with the client unless the DHCP server has been configured by the server administrator to use some other preference mechanism.
MACアドレスまたはクライアントIdentifierオプションによって指定されたクライアントが複数のIPアドレスにアクセスした場合、DHCPサーバーは、DHCPを除き、クライアントとの最新のトランザクションでクライアントにIPアドレスを返す必要があります。サーバーは、他のいくつかの優先メカニズムを使用するようにサーバー管理者によって構成されています。
If, after all of the above processing, no value is set in the "ciaddr" field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message, then a DHCPLEASEUNKNOWN message MUST be returned instead.
上記のすべての処理の後、dhcpleaseunassignedまたはdhcpleasectiveメッセージの「ciaddr」フィールドに値が設定されていない場合、代わりにdhcpleaseunknownのメッセージを返す必要があります。
Once the "ciaddr" field of the DHCPLEASEUNASSIGNED is set, the processing for a DHCPLEASEUNASSIGNED message is complete. No other options are returned for the DHCPLEASEUNASSIGNED message.
DHCPleaseNassignedの「CIADDR」フィールドが設定されると、DHCPleaseUnassignedメッセージの処理が完了します。DHCPleaseUnassignedメッセージに対して他のオプションは返されません。
For the DHCPLEASEACTIVE message, the rest of the processing largely involves returning information about the IP address specified in the "ciaddr" field.
DHCPleaSeactiveメッセージの場合、処理の残りの部分には、「CIADDR」フィールドで指定されたIPアドレスに関する情報を返すことが主に含まれます。
The IP address in the "ciaddr" field of the DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message MUST be one for which this server is responsible (or a DHCPLEASEUNKNOWN message would be have already been returned early in the processing described in the previous section).
dhcpleaseunassignedまたはdhcpreaseativeメッセージの「Ciaddr」フィールドのIPアドレスは、このサーバーが責任を負うものでなければなりません（または、前のセクションで説明した処理の早い段階でdhcpreaseunknownメッセージは既に返されています）。
The MAC address of the DHCPLEASEACTIVE message MUST be set to the values that identify the client associated with the IP address in the "ciaddr" field of the DHCPLEASEUNASSIGNED message.
dhcpleaseativeメッセージのMacアドレスは、DHCPleaseunassignedメッセージの「CIADDR」フィールドのIPアドレスに関連付けられているクライアントを識別する値に設定する必要があります。
If the Client-identifier option (option 61) is specified in the Parameter Request List option (option 55), then the Client-identifier (if any) of the client associated with the IP address in the "ciaddr" field SHOULD be returned in the DHCPLEASEACTIVE message.
クライアントIdentifierオプション（オプション61）がパラメーターリクエストリストオプション（オプション55）で指定されている場合、「CIADDR」フィールドのIPアドレスに関連付けられているクライアントのクライアントIDENTIFIER（もしあれば）を返してください。dhcpleaseactiveメッセージ。
In the case where more than one IP address has been involved in a DHCP message exchange with the client specified by the MAC address and/or Client-identifier option, then the list of all of the IP addresses MUST be returned in the associated-ip option, whether or not that option was requested as part of the Parameter Request List option.
MACアドレスおよび/またはクライアントIDENTIFIERオプションで指定されたクライアントとのDHCPメッセージ交換に複数のIPアドレスが関与している場合、すべてのIPアドレスのリストは、関連するIPで返品する必要があります。オプション、そのオプションがパラメーターリクエストリストオプションの一部として要求されたかどうか。
If the IP Address Lease Time option (option 51) is specified in the Parameter Request List and if there is a currently valid lease for the IP address specified in the ciaddr, then the DHCP server MUST return this option in the DHCPLEASEACTIVE message with its value equal to the time remaining until lease expiration. If there is no valid lease for the IP address, then the server MUST NOT return the IP Address Lease Time option (option 51).
IPアドレスリース時間オプション（オプション51）がパラメーターリクエストリストに指定されている場合、CIADDRで指定されているIPアドレスに現在有効なリースがある場合、DHCPサーバーはその値でDHCPleaSeactiveメッセージでこのオプションを返す必要があります。リースの有効期限まで残っている時間に等しくなります。IPアドレスに有効なリースがない場合、サーバーはIPアドレスリース時間オプションを返してはなりません（オプション51）。
A request for the Renewal (T1) Time Value option or the Rebinding (T2) Time Value option in the Parameter Request List of the DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time option is handled. If there is a valid lease and these times are not yet in the past, then the DHCP server SHOULD return these options (when requested) with the remaining time until renewal or rebinding, respectively. If these times are already in the past, or if there is not currently a valid lease for this IP address, the DHCP server MUST NOT return these options.
更新（T1）時間値オプションのリクエストまたはRebinding（T2）時間値オプションDHCPLEASEQUERYメッセージのパラメーターリクエストリストは、IPアドレスリース時間オプションが処理されるように処理する必要があります。有効なリースがあり、これらの時間がまだ過去にない場合、DHCPサーバーは、それぞれ更新またはリバインドまで残りの時間とともにこれらのオプション（要求がある場合）を返す必要があります。これらの時間がすでに過去にある場合、またはこのIPアドレスに現在有効なリースがない場合、DHCPサーバーはこれらのオプションを返してはなりません。
If the Relay Agent Information (option 82) is specified in the Parameter Request List, then the information contained in the most recent Relay Agent Information option received from the relay agent associated with this IP address MUST be included in the DHCPLEASEACTIVE message.
リレーエージェント情報（オプション82）がパラメーターリクエストリストに指定されている場合、このIPアドレスに関連付けられたリレーエージェントから受け取った最新のリレーエージェント情報オプションに含まれる情報は、DHCPleaSeactiveメッセージに含める必要があります。
The DHCPLEASEACTIVE message SHOULD include the values of all other options not specifically discussed above that were requested in the Parameter Request List of the DHCPLEASEQUERY message and that are acceptable to return based on the list of "non-sensitive options", discussed below.
DHCPleaSeactiveメッセージには、以下で説明する「非敏感なオプション」のリストに基づいて返されるDHCPleasequeryメッセージのパラメーターリクエストリストでリクエストされた上記で説明されていない他のすべてのオプションの値を含める必要があります。
DHCP servers SHOULD be configurable with a list of "non-sensitive options" that can be returned to the client when specified in the Parameter Request List of the DHCPLEASEQUERY message. Any option not on this list SHOULD NOT be returned to a client, even if requested by that client.
DHCPサーバーは、DHCPleasequeryメッセージのパラメーターリクエストリストで指定された場合にクライアントに返すことができる「非感受性オプション」のリストで構成可能である必要があります。このリストに載っていないオプションは、そのクライアントから要求されたとしても、クライアントに返されるべきではありません。
The DHCP server uses information from its lease binding database to supply the DHCPLEASEACTIVE option values. The values of the options that were returned to the DHCP client would generally be preferred, but in the absence of those, options that were sent in DHCP client requests would be acceptable.
DHCPサーバーは、リースバインディングデータベースからの情報を使用して、DHC遊液のオプション値を提供します。DHCPクライアントに返されたオプションの値が一般的に推奨されますが、それらがない場合、DHCPクライアントリクエストで送信されたオプションは受け入れられます。
In some cases, the Relay Agent Information option in an incoming DHCPREQUEST packet is used to help determine the options returned to the DHCP client that sent the DHCPREQUEST. When responding to a DHCPLEASEQUERY message, the DHCP server MUST use the saved Relay Agent Information option just like it did when responding to the DHCP client in order to determine the values of any options requested by the DHCPLEASEQUERY message. The goal is to return the same option values to the DHCPLEASEQUERY as those that were returned to the DHCPDISCOVER or DHCPREQUEST from the DHCP client (unless otherwise specified, above).
場合によっては、着信DHCPRequestパケットのリレーエージェント情報オプションを使用して、DHCPRequestを送信したDHCPクライアントに返されるオプションを決定するのに役立ちます。DHCPleasequeryメッセージに応答する場合、DHCPサーバーは、DHCPleasequeryメッセージによって要求されたオプションの値を決定するために、DHCPクライアントに応答するときと同じように保存されたリレーエージェント情報オプションを使用する必要があります。目標は、DHCPクライアントからDHCPDISCOVERまたはDHCPREQUESTに返されたものと同じオプション値をDHCPleasequeryに返すことです（特に指定されていない限り）。
In the event that two servers are cooperating to provide a high-availability DHCP server, as supported by [RFC2131], they would have to communicate some information about IP address bindings to each other. In order to properly support the DHCPLEASEQUERY message, these servers MUST ensure that they communicate the Relay Agent Information option information to each other in addition to any other IP address binding information.
[RFC2131]でサポートされているように、2つのサーバーが高可用性DHCPサーバーを提供するために協力している場合、IPアドレスのバインディングに関する情報を相互に伝える必要があります。DHCPleasequeryメッセージを適切にサポートするために、これらのサーバーは、他のIPアドレスバインディング情報に加えて、リレーエージェント情報オプション情報を相互に通信することを確認する必要があります。
The server expects a giaddr in the DHCPLEASEQUERY message, and unicasts the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN message to the giaddr. If the "giaddr" field is zero, then the DHCP server MUST NOT reply to the DHCPLEASEQUERY message.
サーバーは、DHCPleasequeryメッセージにGIADDRを期待し、GIADDRへのDHCPleaseUnassigned、DHCPleaseative、またはDHCPleaseunknownのメッセージをユニカストします。「GIADDR」フィールドがゼロの場合、DHCPサーバーはDHCPleasequeryメッセージに返信してはなりません。
When a DHCPLEASEACTIVE message is received in response to the DHCPLEASEQUERY message, it means that there is a currently active lease for this IP address in this DHCP server. The access concentrator SHOULD use the information in the "htype", "hlen", and "chaddr" fields of the DHCPLEASEACTIVE as well as any Relay Agent Information option information included in the packet to refresh its location information for this IP address.
DHCPleasequeryメッセージに応じてDHCPleaSeactiveメッセージが受信されると、このDHCPサーバーにこのIPアドレスに現在アクティブなリースがあることを意味します。Access concentoratorは、DHC遊液の「HTYPE」、「HLEN」、および「CHADDR」フィールドの情報と、このIPアドレスの位置情報を更新するためにパケットに含まれるリレーエージェント情報オプション情報を使用する必要があります。
When a DHCPLEASEUNASSIGNED message is received in response to the DHCPLEASEQUERY message, that means that there is no currently active lease for the IP address present in the DHCP server, but that this server does in fact manage that IP address. In this case, the access concentrator SHOULD cache this information in order to prevent unacceptable loads on the access concentrator and the DHCP server in the face of a malicious or seriously compromised device downstream of the access concentrator. This caching could be as simple as simply setting a bit saying that a response was received from a server that knew about this IP address but that there was no current lease. This would, of course, need to be cleared when the access concentrator next "gleaned" that a lease for this IP address came into existence.
DHCPleaseUnassignedメッセージがDHCPleasequeryメッセージに応じて受信されると、DHCPサーバーに存在するIPアドレスの現在アクティブなリースがないが、このサーバーは実際にそのIPアドレスを管理していることを意味します。この場合、アクセスコンセントレーターは、アクセス濃縮器の下流または重大な侵害されたデバイスに直面して、アクセスコンセントレーターとDHCPサーバーの容認できない負荷を防ぐために、この情報をキャッシュする必要があります。このキャッシングは、このIPアドレスを知っていたが現在のリースがなかったサーバーから応答が受信されたと少し設定するだけで簡単に設定するのと同じくらい簡単です。もちろん、このIPアドレスのリースが存在することを「収集」した場合、これはクリアする必要があります。
In either case, when a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE message is received in response to a DHCPLEASEQUERY message, it means that the DHCP server that responded is a DHCP server that manages the IP address present in the ciaddr, and the Relay Agent SHOULD cache this information for later use.
どちらの場合でも、DHCPLEASENASSIGNEDまたはDHCPLEASECTIVEメッセージがDHCPLEASEQUERYメッセージに応じて受信された場合、応答したDHCPサーバーはCIADDRに存在するIPアドレスを管理するDHCPサーバーであり、リレーエージェントはこの情報をキャッシュする必要があります。後で使用します。
When a DHCPLEASEUNKNOWN message is received by an access concentrator that has sent out a DHCPLEASEQUERY message, it means that the DHCP server contacted supports the DHCPLEASEQUERY message but that the DHCP server does not have definitive information concerning the IP address contained in the "ciaddr" field of the DHCPLEASEQUERY message. If there is no IP address in the "ciaddr" field of the DHCPLEASEQUERY message, then a DHCPLEASEUNKNOWN message means that the DHCP server does not have definitive information concerning the DHCP client specified in the "hlen", "htype", and "chaddr" fields or the Client-identifier option of the DHCPLEASEQUERY message.
DHCPleaseunknownの既知のメッセージがDHCPleasequeryメッセージを送信したAccess Concencoratorによって受信されると、DHCPサーバーがDHCPleasequeryメッセージをサポートしているが、DHCPサーバーには「Ciaddr」フィールドに含まれるIPアドレスに関する決定的な情報がないことを意味します。dhcpleasequeryメッセージの。DHCPleasequeryメッセージの「CIADDR」フィールドにIPアドレスがない場合、DHCPLEASEUNKNOWNのメッセージは、DHCPサーバーが「HLEN」、「HTYPE」、および「CHADDR」で指定されたDHCPクライアントに関する決定的な情報を持っていないことを意味します。dhcpleasequeryメッセージのフィールドまたはクライアント識別子オプション。
The access concentrator SHOULD cache this information, but only for a relatively short lifetime, approximately 5 minutes.
アクセスコンセントレーターは、この情報をキャッシュする必要がありますが、比較的短い寿命の場合にのみ、約5分です。
Having cached this information, the access concentrator SHOULD only infrequently direct a DHCPLEASEQUERY message to a DHCP server that responded to a DHCPLEASEQUERY message for a particular "ciaddr" field with a DHCPLEASEUNKNOWN.
この情報をキャッシュしたため、Access ConcentorはDHCPLEASEQUERYメッセージをDHCPサーバーにDHCPLEASEQUERYメッセージに応答したDHCPREASEQUERYメッセージにDHCPleaseunknownを使用して応答したDHCPサーバーにのみ頻繁に誘導する必要があります。
When an access concentrator receives no response to a DHCPLEASEQUERY message, there are several possible reasons:
Access concentatorがDHCPleasequeryメッセージに対する応答を受け取らない場合、いくつかの理由があります。
o The DHCPLEASEQUERY or a corresponding DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN was lost during transmission or the DHCPLEASEQUERY arrived at the DHCP server but it was dropped because the server was too busy.
o DHCPLEASEQUERYまたは対応するDHCPLESENASSIGNED、DHCPLEASECTIVE、またはDHCPLESEUNKNOUNTが送信中に失われたか、DHCPLEASEQUERYがDHCPサーバーに到着しましたが、サーバーが忙しすぎたためにドロップされました。
o The DHCP server doesn't support DHCPLEASEQUERY.
o DHCPサーバーはDHCPleasequeryをサポートしていません。
In the first of the cases above, a retransmission of the DHCPLEASEQUERY would be appropriate, but in the second of the two cases, a retransmission would not be appropriate. There is no way to tell these two cases apart (other than, perhaps, because of a DHCP server's response to other DHCPLEASEQUERY messages indicating that it does or does not support the DHCPLEASEQUERY message).
上記の最初のケースでは、DHCPleasequeryの再送信が適切ですが、2つのケースのうち2番目では、再送信は適切ではありません。これらの2つのケースを際立たせる方法はありません（おそらく、DHCPleasequeryメッセージをサポートするか、またはサポートしていないことを示す他のDHCPleaseQueryメッセージに対するDHCPサーバーの応答のため）。
An access concentrator that utilizes the DHCPLEASEQUERY message SHOULD attempt to resend DHCPLEASEQUERY messages to servers that do not respond to them using a backoff algorithm for the retry time that approximates an exponential backoff. The access concentrator SHOULD adjust the backoff approach such that DHCPLEASEQUERY messages do not arrive at a server that is not otherwise known to support the DHCPLEASEQUERY message at a rate of more than approximately one packet every 10 seconds, and yet (if the access concentrator needs to send DHCPLEASEQUERY messages) not less than one DHCPLEASEQUERY per 70 seconds.
DHCPleasequeryメッセージを使用するアクセスコンセントレーターは、指数バックオフに近い再試行時間のバックオフアルゴリズムを使用して応答しないサーバーにDHCPleasequeryメッセージを再送信しようとする必要があります。アクセス濃縮器は、DHCPleasequeryメッセージが、10秒ごとに約1パケットを超えるレートでDHCPleasequeryメッセージをサポートすることがわかっていないサーバーに到達しないように、バックオフアプローチを調整する必要があります（アクセスConcentorが必要な場合はまだ必要な場合dhcpleasequeryメッセージを送信）70秒あたり1つ以上のdhcpleasequeryを送信します。
In practice, this approach would probably best be handled by a per-server timer that is restarted whenever a response to a DHCPLEASEQUERY message is received, and expires after one minute. The per-server timer would start off expired, and in the expired state only one DHCPLEASEQUERY message would be queued for the associated server.
実際には、このアプローチはおそらく、DHCPleasequeryメッセージへの応答が受信され、1分後に期限切れになるたびに再起動されるサーバーごとのタイマーによって最もよく処理されるでしょう。サーバーごとのタイマーは期限切れから開始され、期限切れの状態では、関連するサーバーに対して1つのDHCPLEASEQUERYメッセージのみがキューに掲載されます。
All DHCPLEASEQUERY messages SHOULD use the exponential backoff algorithm specified in Section 4.1 of [RFC2131].
すべてのdhcpleasequeryメッセージは、[RFC2131]のセクション4.1で指定された指数バックオフアルゴリズムを使用する必要があります。
Thus, in the initial state, the per-server timer is expired, and a single DHCPLEASEQUERY message is queued for each server. After the first response to a DHCPLEASEQUERY message, the per-server timer is started. At that time, multiple DHCPLEASEQUERY messages can be sent in parallel to the DHCP server, though the total number SHOULD be limited to 100 or 200, to avoid swamping the DHCP server. Each of these messages uses the [RFC2131] exponential backoff algorithm. Every time a response to any of these messages is received, the per-server timer is reset and starts counting again up to one minute. In the event the per-server timer goes off, then all outstanding messages SHOULD be dropped except for a single DHCPLEASEQUERY message that is used to poll the server at approximately 64-second intervals until such time as another (or the first) response to the DHCPLEASEQUERY is received.
したがって、初期状態では、サーバーごとのタイマーが期限切れになり、各サーバーに対して単一のdhcpleasequeryメッセージがキューに掲載されます。DHCPleasequeryメッセージに対する最初の応答の後、サーバーごとのタイマーが開始されます。その時点では、DHCPサーバーの圧倒を避けるために、総数は100または200に制限する必要がありますが、DHCPサーバーと並行して複数のDHCPleasequeryメッセージを送信できます。これらの各メッセージは、[RFC2131]指数バックオフアルゴリズムを使用します。これらのメッセージのいずれかへの応答が受信されるたびに、サーバーごとのタイマーがリセットされ、最大1分間カウントを開始します。サーバーごとのタイマーがオフになった場合、約64秒の間隔でサーバーを投票するために使用される単一のDHCPLEASEQUERYメッセージを除いて、すべての未解決のメッセージをドロップする必要があります。dhcpleasequeryが受け取られます。
In the event that there is no DHCPLEASEQUERY traffic for one minute, then the per-server timer will expire. After that time, there will only be one DHCPLEASEQUERY message allowed to be outstanding to that server until a response to that message is received.
DHCPleasequeryトラフィックが1分間行われない場合、サーバーごとのタイマーが期限切れになります。その後、そのメッセージへの応答が受信されるまで、そのサーバーへの未解決のDHCPleasequeryメッセージは1つしかありません。
DHCP server implementations that implement the DHCPLEASEQUERY capability MUST save the most recent Relay Agent Information option from the most recent DHCPREQUEST packet for two reasons. First, it is almost certain to be requested by in the dhcp-parameter-request-list option in any DHCPLEASEQUERY request. Second, the saved Relay Agent Information option may be necessary to determine the value of other options given to the DHCP client, if these are requested by the dhcp-parameter-request list in the DHCPLEASEQUERY request.
DHCPLESEQUERY機能を実装するDHCPサーバーの実装は、2つの理由で最新のDHCPRequestパケットから最新のリレーエージェント情報オプションを保存する必要があります。まず、DHCPleasequeryリクエストでDHCP-Parameter-Request-Listオプションで要求されることはほぼ確実です。第二に、DHCPLEASEQUERYリクエストのDHCP-Parameter-Requestリストでリクエストされている場合、DHCPクライアントに指定された他のオプションの値を決定するには、保存されたリレーエージェント情報オプションが必要になる場合があります。
This is a list of the information that is required to successfully implement
これは、正常に実装するために必要な情報のリストです
o relay-agent-info option from client packet: MUST store with binding.
o クライアントパケットからのリレーエージェントINFOオプション：バインディングで保存する必要があります。
o client-last-transaction-time of last client interaction: MUST store with binding.
o 最後のクライアントインタラクションのクライアントラストトランザクション時間：バインディングで保存する必要があります。
o vendor-class-id: SHOULD store with binding.
o Vendor-Class-ID：バインディングで保存する必要があります。
These data storage requirements are minimally larger than those required for normal operation of the DHCP protocol, as required to properly implement [RFC2131].
これらのデータストレージ要件は、適切に実装するために必要なDHCPプロトコルの通常の動作に必要なものよりも最小限に大きくなります[RFC2131]。
When using the DHCPLEASEQUERY message in an environment where multiple DHCP servers may contain authoritative information about the same IP address (such as when two DHCP servers are cooperating to provide a high-availability DHCP service), multiple, possibly conflicting, responses might be received.
複数のDHCPサーバーが同じIPアドレスに関する権威ある情報を含む環境でDHCPleasequeryメッセージを使用する場合（2つのDHCPサーバーが高可用性DHCPサービスを提供するために協力している場合など）、複数の、おそらく矛盾する応答を受信する可能性があります。
In this case, some information in the response packet SHOULD be used to decide among the various responses. The client-last-transaction-time (if it is available) can be used to decide which server has more recent information concerning the IP address returned in the "ciaddr" field.
この場合、応答パケットの一部の情報を使用して、さまざまな応答の中から決定する必要があります。クライアントラストトランザクションタイム（使用可能な場合）を使用して、「CIADDR」フィールドに返されるIPアドレスに関する最新の情報があるサーバーを決定できます。
Access concentrators that use DHCP gleaning, refreshed with DHCPLEASEQUERY messages, will maintain accurate location information. Location information accuracy ensures that the access concentrator can forward data traffic to the intended location in the broadband access network, can perform IP source address verification of datagrams from the access network, and can encrypt traffic that can only be decrypted by the intended access modem (e.g., [BPI] and [BPI+]). As a result, the access concentrator does not need to depend on ARP broadcasts across the access network, which is susceptible to malicious hosts that masquerade as the intended IP endpoints. Thus, the DHCPLEASEQUERY message allows an access concentrator to provide considerably enhanced security.
DHCPLEASEQUERYメッセージでリフレッシュされたDHCP Gleaningを使用するコンセントレーターにアクセスすると、正確な位置情報が維持されます。位置情報の正確性により、アクセスコンセントレーターは、データトラフィックをブロードバンドアクセスネットワーク内の意図した場所に転送し、アクセスネットワークからのデータグラムのIPソースアドレスの検証を実行でき、意図したアクセスモデムによってのみ解読できるトラフィックを暗号化できます（例：[BPI]および[BPI]）。その結果、アクセスコンセントレーターは、アクセスネットワーク全体のARPブロードキャストに依存する必要はありません。これは、意図したIPエンドポイントを装った悪意のあるホストの影響を受けやすいです。したがって、DHCPleasequeryメッセージにより、アクセスConcencoratorが大幅に強化されたセキュリティを提供できます。
DHCP servers SHOULD prevent exposure of location information (particularly the mapping of hardware address to IP address lease, which can be an invasion of broadband subscriber privacy) by employing the techniques detailed in [RFC3118], "Authentication for DHCP Messages".
DHCPサーバーは、[RFC3118]で詳述されている手法、「DHCPメッセージの認証」に詳述されている手法を採用することにより、位置情報（特にハードウェアアドレスのIPアドレスリースへのマッピング）を防止する必要があります。
This RFC describes how a DHCP client interacts with a DHCP server. Access concentrators that send the DHCPLEASEQUERY message are essentially DHCP clients for the purposes of the DHCPLEASEQUERY message, even though they perform the functions of a DHCP relay agent as well. Thus, [RFC3118] is an appropriate mechanism for DHCPLEASEQUERY messages.
このRFCは、DHCPクライアントがDHCPサーバーとどのように相互作用するかを説明しています。DHCPLEASEQUERYメッセージを送信するアクセスコンセントレーターは、DHCPリレーエージェントの機能を実行している場合でも、DHCPleasequeryメッセージの目的のために基本的にDHCPクライアントです。したがって、[RFC3118]は、DHCPleasequeryメッセージの適切なメカニズムです。
Since [RFC3118] discusses the normal DHCP client interaction, consisting of a DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK, it is necessary to transpose the operations described in [RFC3118] to the DHCPLEASEQUERY domain. The operations described in [RFC3118] for DHCPDISCOVER are performed for DHCPLEASEQUERY, and the operations described for DHCPOFFER are performed for DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN messages.
[RFC3118]は、DHCPDISCOVER、DHCPOFFER、DHCPREQUEST、およびDHCPACKで構成される通常のDHCPクライアントの相互作用について議論しているため、[RFC3118]に記載されている操作をDHCPleaseQueryドメインに転置する必要があります。DHCPDISCOVERの[RFC3118]に記載されている操作は、DHCPleasequeryに対して実行され、DHCPofferに記載されている操作は、DHCPleaseUnassigned、DHCPleaseative、およびDHCPleaseunknownknownのメッセージに対して実行されます。
Access concentrators SHOULD minimize potential denial of service attacks on the DHCP servers by minimizing the generation of DHCPLEASEQUERY messages. In particular, the access concentrator SHOULD employ negative caching (i.e., cache DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN responses to DHCPLEASEQUERY messages) and ciaddr restriction (i.e., don't send a DHCPLEASEQUERY message with a ciaddr outside of the range of the attached broadband access networks). Together, these mechanisms limit the access concentrator to transmitting one DHCPLEASEQUERY message (excluding message retries) per legitimate broadband access network IP address after a reboot event.
アクセスコンセントレーターは、DHCPleasequeryメッセージの生成を最小限に抑えることにより、DHCPサーバーに対する潜在的な拒否攻撃を最小限に抑える必要があります。特に、アクセスコンセントレーターは、ネガティブキャッシュ（つまり、DHCPLEASENASSIGNED、DHCPLEASECTIVE、DHCPLEASEUNKNOUND RESPONDES TO DHCPLEASEQUERYメッセージに対するDHCPLEASEUNKNOWNの応答）およびCIADDRの制限を使用する必要があります（つまり、接続されたブロードバンドアクセスの範囲外のCIADDRを使用してDHCPleseQueryメッセージを送信しないでください。ネットワーク）。一緒に、これらのメカニズムは、アクセス濃縮器を制限して、再起動イベントの後、正当なブロードバンドアクセスネットワークIPアドレスごとに1つのDHCPleasequeryメッセージ（メッセージの再取得を除く）を送信します。
DHCP servers supporting the DHCPLEASEQUERY message SHOULD ensure that they cannot be successfully attacked by being flooded with large quantities of DHCPLEASEQUERY messages in a short time.
DHCPLEASEQUERYメッセージをサポートするDHCPサーバーは、短時間で大量のDHCPleasequeryメッセージであふれていることで、攻撃に成功することができないことを確認する必要があります。
In some environments, it may be appropriate to configure a DHCP server with the IP addresses of the relay agents for which it may respond to DHCPLEASEQUERY messages, thereby allowing it to respond only to requests from only a handful of relay agents. This does not provide any true security, but may be useful to thwart unsophisticated attacks of various sorts.
一部の環境では、DHCPleasequeryメッセージに応答するリレーエージェントのIPアドレスを使用してDHCPサーバーを構成することが適切な場合があり、それにより、少数のリレーエージェントのみからのリクエストのみに応答できるようにします。これは真のセキュリティを提供しませんが、さまざまな種類の洗練されていない攻撃を阻止するのに役立つ可能性があります。
IANA has assigned six values for this document. See Section 6.1 for details. There are four new messages types, which are the value of the message type option (option 53) from [RFC2132]. The value for DHCPLEASEQUERY is 10, the value for DHCPLEASEUNASSIGNED is 11, the value for DHCPLEASEUNKNOWN is 12, and the value for DHCPLEASEACTIVE is 13. Finally, there are two new DHCP option defined; the client-last-transaction-time option -- option code 91, and the associated-ip option -- option code 92.
IANAはこのドキュメントに6つの値を割り当てました。詳細については、セクション6.1を参照してください。[RFC2132]のメッセージタイプオプション（オプション53）の値である4つの新しいメッセージタイプがあります。DHCPleasequeryの値は10、DHCPleaseUnassignedの値は11、DHCPleaseunknownの値は12、DHCPleaseativeの値は13です。最後に、2つの新しいDHCPオプションが定義されています。クライアントラストトランザクションタイムオプション - オプションコード91、および関連するIPオプション - オプションコード92。
Jim Forster, Joe Ng, Guenter Roeck, and Mark Stapp contributed greatly to the initial creation of the DHCPLEASEQUERY message.
Jim Forster、Joe Ng、Guenter Roeck、Mark Stappは、DHCPleasequeryメッセージの最初の作成に大きく貢献しました。
Patrick Guelat suggested several improvements to support static IP addressing. Thomas Narten made many suggestions for improvements. Russ Housley pressed effectively for increased security capabilities, and Ted Hardie suggested ways to minimize undesired information leakage. Bert Wijnen suggested we clarify our focus to DHCPv4 and distinguish our approach from that of the DHCP MIB. R. Barr Hibbs, one of the authors of the DHCP MIB, supplied information to effectively distinguish that effort from DHCPLEASEQUERY.
Patrick Guelatは、静的IPアドレス指定をサポートするためのいくつかの改善を提案しました。トーマス・ナルテンは改善のために多くの提案をしました。Russ Housleyはセキュリティ機能の向上を効果的に押し付け、Ted Hardieは、望ましくない情報漏れを最小限に抑える方法を提案しました。Bert Wijnenは、DHCPV4への焦点を明確にし、アプローチをDHCP MIBのアプローチと区別することを提案しました。DHCP MIBの著者の1人であるR. Barr Hibbsは、その努力をDHCPleasequeryと効果的に区別するための情報を提供しました。
[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。、「動的ホスト構成プロトコル」、RFC 2131、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. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] DROMS、R。およびW. Arbaugh、「DHCPメッセージの認証」、RFC 3118、2001年6月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレス」、STD 37、RFC 826、1982年11月。
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC951] Croft、W。およびJ. Gilmore、「Bootstrap Protocol」、RFC 951、1985年9月。
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993.
[RFC1542] Wimer、W。、「ブートストラッププロトコルの説明と拡張」、RFC 1542、1993年10月。
[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月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[BPI] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface Specification SCTE 22-2 2002", 2002, available at http://www.scte.org/standards/.
[BPI] SCTEデータ標準小委員会、「データオーバーサービスインターフェイス仕様：DOCSIS 1.0ベースラインプライバシーインターフェイス仕様SCTE 22-2 2002 "、2002年、http：//www.scte.org/standards/で入手可能。
[BPI+] CableLabs, "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-050812", August 2005, available at http://www.cablemodem.com/.
[BPI] CableLabs、「データオーバーサービスインターフェイス仕様：ベースラインプライバシーとインターフェイス仕様CM-SP-BPI _I12-050812 "、2005年8月、http：//www.cablemodem.com/で入手可能。
[DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration Protocol (DHCP) Server MIB", Work in Progress, February 2004.
[DHCPMIB] Hibbs、R.、Waters、G。、「Dynamic Host Configuration Protocol（DHCP）Server MIB "、Work in Progress、2004年2月。
[DOCSIS] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Radio Frequency Interface Specification SCTE 22-1 2002", 2002, available at http://www.scte.org/standards/.
[docsis] SCTEデータ標準小委員会、「データオーバーサービスインターフェイス仕様：DOCSIS 1.0無線周波数インターフェイス仕様SCTE 22-1 2002」、2002年、http：//www.scte.org/standards/で入手可能。
[EUROMODEM] ECCA, "Technical Specification of a European Cable Modem for digital bi-directional communications via cable networks", Version 1.0, May 1999.
[Euromodem] ECCA、「ケーブルネットワークを介したデジタル双方向通信用の欧州ケーブルモデムの技術仕様」、バージョン1.0、1999年5月。
Authors' Addresses
著者のアドレス
Rich Woundy Comcast Cable 27 Industrial Ave. Chelmsford, MA 01824
豊富な創傷comcastケーブル27 IndustrialAve.Chelmsford、MA 01824
Phone: (978) 244-4010 EMail: richard_woundy@cable.comcast.com
電話：（978）244-4010メール：richard_woundy@cable.comcast.com
Kim Kinnear Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719
キム・キニア・シスコ・システム1414マサチューセッツ・アベニュー・ボックスボロー、マサチューセッツ州01719
Phone: (978) 936-0000 EMail: kkinnear@cisco.com
電話：（978）936-0000メール：kkinnear@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。