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
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).
著作権（C）インターネット協会（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の）サーバーは、IPの信頼できるソースは、それがのDHCPv4クライアントに提供していることに対処です。すでにのDHCPv4を利用する他のプロセスとデバイスは、この情報にアクセスする必要があるかもしれません。 LEASEQUERYプロトコルは、これらのプロセスとデバイスに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サーバは、IPは、それがDHCPクライアントにリースしたアドレスに関するかなりの正式な情報が含まれています。時には、デバイスまたは他のプロセスは、この情報にアクセスする必要があるかもしれません。いくつかのケースでは、これらのデバイスまたはプロセスがすでに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リレーエージェントとして動作するアクセスコンセントレータは時々彼らは前方に、プロセスは「落穂拾い」として知られているDHCPパケットからデータを抽出し、それらの動作に重要な情報を導き出します。アクセスコンセントレータが再起動されるか、交換されたときに残念なことに、典型的なアクセスコンセントレータは、その収集した情報を失います。このメモは、収集されたDHCP情報が利用できない場合、アクセスコンセントレータ/リレーエージェントは、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.アクセスコンセントレータは、正しい仮想回線ダウン、正しいモデムを介して、正しいハードウェア・アドレスに、正しいアクセス・ネットワーク・ポートを使用してアクセスネットワークにトラフィックを転送することができます。
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.アクセスコンセントレータは、アクセスネットワークから受信したデータグラムのIP送信元アドレスの検証を行うことができます。検証は、データグラムの送信元ハードウェアアドレス、着信アクセスネットワークポート、受信仮想回線、および/または送信モデムに基づいてもよいです。
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サーバの応答から情報を「落穂拾い」から位置情報を取得します。位置情報は「グリーニング」から入手可能でない場合、アクセスコンセントレータがリブートしているため、例えば、アクセスコンセントレータは、この文書で定義された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メッセージタイプです。それはIPエンドポイントの場所を知っておく必要がある場合DHCPLEASEQUERY対応のリレーエージェントは、DHCPLEASEQUERYメッセージを送信します。 DHCPLEASEQUERY対応のDHCPサーバはDHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、またはDHCPLEASEUNKNOWNメッセージで応答します。 DHCPLEASEQUERYメッセージにDHCPLEASEACTIVE応答は、リレーエージェントは、IPエンドポイントの位置とIPアドレスのリースの残り時間を決定することを可能にします。 DHCPLEASEUNASSIGNEDはDHCPLEASEACTIVEメッセージに似ていますが、結果として得られるIPアドレス上のアクティブなリースが何も現在存在しないことを示しているが、このDHCPサーバーは、このIPアドレスに対して権限を持っていることを。 DHCPLEASEUNKNOWNメッセージは、DHCPサーバは、クエリ（例えば、IPアドレス、MACアドレス、またはクライアント識別子オプション）で指定された情報の知識を有していないことを示しています。
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の展開シナリオを推定することは困難で決定されます。 DHCPLEASEQUERYのような機能がDHCPv6のに必要であれば他はないかもしれないが、この文書のアイデアの多くは、おそらく、適用されます。私たちは、想像消費者が存在しているため、プロトコル機能を設計することに警告を発してきた、そしてそれは、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]ごとに、異なるサブネット上にあるクライアントとサーバ間のブートストラッププロトコル（BOOTP）およびDHCPメッセージを転送エージェントと[RFC1542]です。
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.
メッセージが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.
位置情報は、ブロードバンドでアクセスできるホストへのトラフィックを転送するために、アクセスコンセントレータが必要とする情報です。この情報は、ホストのハードウェアアドレス、ポート、またはホストにつながる仮想回線、および/または介在加入者モデムのハードウェアアドレスの知識を含みます。
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.
一つの重要な動機の例は、DHCPLEASEQUERYメッセージは、アクセスコンセントレータは、ブロードバンド・アクセス・ネットワーク・デバイスの位置情報を取得するためにDHCPサーバにDHCPLEASEQUERYメッセージを送信することを可能にするということです。
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ケーブルモデム終端システム（CMTS）[DOCSIS]、DVBインタラクティブネットワークアダプタ（のINA）[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.
アクセスコンセントレータは、ブロードキャストアドレス解決プロトコル（ARP）要求[RFC826]を送信し、位置情報を再構成するために、ARP応答の起源と内容を観察することができます。
The ARP mechanism is undesirable for three reasons:
ARPメカニズムは三つの理由で望ましくありません。
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管理エージェントが含まれませんが）アクセスコンセントレータの実装は通常、簡易ネットワーク管理プロトコル（SNMP）管理クライアント・インタフェースやLDAP（Lightweight Directory Access Protocol）クライアント・インタフェースを持っていません。これは、このドキュメントでは、提案したDHCPサーバーMIB [DHCPMIB]を活用しない理由の一つです。
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オブジェクトとオブジェクトを定義することも同様にSNMP MIBの観点からがっかりすることでしょうMIBを通じて、必要に応じてDHCPLEASEQUERY機能をサポートしようと、落胆していることが表示されますので。
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サーバーが単一障害点がないように、アクセスコンセントレータは、複数の異なるDHCPサーバのIPアドレスで設定することができます。
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.
アクセスコンセントレータは、すべてのDHCPLEASEQUERYメッセージの会話を開始します。この文書では、アクセスコンセントレータは、そのDHCPリレーエージェント機能で位置情報をgleansことを前提としています。しかし、位置情報は、アクセスコンセントレータのリブートまたは交換後に通常利用できません。
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.
アクセスコンセントレータがルータであると仮定し、さらにルータは、公共ブロードバンドアクセスネットワークの下流に転送するようにIPデータグラムを受信したとします。下流の次のホップの位置情報が欠落している場合、アクセスコンセントレータは、それぞれ「ciaddr」フィールドに下流の次のホップのIPアドレスを含む、一つ以上のDHCPLEASEQUERYメッセージ（S）を送信します。
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.
このクエリは、アクセスコンセントレータは、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アドレスまたはクライアント識別子オプションを指定して「ciaddr」フィールドでDHCPLEASEQUERYメッセージ空とMACアドレスに送信することである（すなわち、「htypeフィールド」、「HLEN」、および「とchaddr」フィールド）オプション領域に表示されるオプション61）。それはクライアント識別子またはMACアドレスで説明したクライアントの任意のレコードを持っている場合この場合、DHCPサーバは、ciaddrにIPアドレスを返す必要があります。逆に特定の設定情報がない場合には（セクション6.4を参照）、それはMACアドレスまたはクライアント識別子オプションで説明したクライアントに関連付けられた最新のクライアント最後のトランザクション時間と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.
どちらかDHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、またはDHCPLEASEUNKNOWN：このプロトコルを実装するDHCPサーバは常にDHCPLEASEQUERYメッセージへの応答を送信します。 DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、またはDHCPLEASEUNKNOWNメッセージが生成される可能性があります理由は、以下の、特定のクエリ体制で説明されています。
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:
IPアドレスによるOクエリ：
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.
このクエリでは、リクエスタは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.
DHCPLEASEQUERYメッセージ内のIPアドレスがサーバ（すなわち、このIPアドレスをリースすることを許可されている）、決定的な情報を持っているどのIPアドレスに対応する場合、DHCPサーバはDHCPLEASEUNASSIGNED又はDHCPLEASEACTIVEメッセージで応答します。サーバはDHCPLEASEQUERYメッセージ内のアドレスに関する決定的な情報を持っていない場合、サーバーはDHCPLEASEUNKNOWNメッセージで応答します。
o Query by MAC address:
MACアドレスによるOクエリ：
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.
このクエリでは、リクエスタは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.
DHCPLEASEQUERYメッセージでMACアドレスが、このサーバーでIPアドレス上のアクティブなリースとMACアドレスに対応している場合、DHCPサーバはDHCPLEASEACTIVEメッセージで応答します。サーバは現在、このDHCPサーバでこのMACアドレスを持つクライアントがアクティブなリースを持っていない場合、サーバーはDHCPLEASEUNKNOWNメッセージで応答します。
o Query by Client-identifier option:
クライアント識別子オプションにより、Oクエリ：
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.
このクエリでは、リクエスタはDHCPLEASEQUERYメッセージで唯一のクライアント識別子オプションを提供します。 DHCPサーバは、それが、最近そのクライアント識別子を使用して、クライアントがアクセスするIPアドレスを持っているすべての情報を返します。また、異なるサブネット内のクライアント識別子に関連付けられている追加の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.
DHCPLEASEQUERYメッセージでクライアント識別子が現在このDHCPサーバにIPアドレス上のアクティブなリースを持っている場合、DHCPサーバはDHCPLEASEACTIVEメッセージで応答します。サーバは、このクライアント識別子を持つクライアントがアクティブなリースを持っていない場合、サーバーは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アドレスによるクエリはLEASEQUERYの最も効率的な形である可能性が高いです。これは、可能な場合に使用されるべきである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.
DHCPLEASEUNASSIGNEDまたはDHCPLEASEACTIVEメッセージ応答は、常に「ciaddr」フィールドにIPアドレスが含まれている必要があります。 DHCPLEASEACTIVEメッセージは「htypeフィールド」、「HLEN」、および「とchaddr」フィールドにIPアドレスのリース所有者の物理アドレスを含むべきです。パラメータ要求リスト（オプション55）はciaddrでのIPアドレスについて返される特定のオプションを要求するために使用することができます。回答は、多くの場合、リースの期限、およびリレーエージェント情報オプション[RFC3046]の元の内容までの時間が含まれています。アクセスコンセントレータは、リース期限までアクセスコンセントレータ上にキャッシュすることができ、位置情報を、構築するために「と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メッセージを生成ほとんどのクライアントは、周りに戻るにはパラメータ要求リストのリレーエージェント情報オプション（オプション82）（オプション55）を要求し、そのためリレーエージェント情報オプションを持たずに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も、このオプションはまた、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]:
DHCPLEASEQUERYメッセージ自体のための1つ、その三つの可能な応答DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、DHCPLEASEUNKNOWNごとに1つ1. [RFC2132]からメッセージタイプオプション（オプション53）は、4つの新しい値を必要とします。これらのメッセージタイプの値は、[RFC2132]のセクション9.6からのテーブルの拡張に以下に示します。
Value Message Type
----- ------------
10 DHCPLEASEQUERY
11 DHCPLEASEUNASSIGNED
12 DHCPLEASEUNKNOWN
13 DHCPLEASEACTIVE
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.
このオプションは、受信機は、クライアントの最新のアクセスの時間を決定することができます。二つの異なるDHCPサーバからDHCPLEASEACTIVEメッセージを比較する必要があるとき、それは他の状況において有用であることができるが、それは、特に便利です。値は、この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年には代わりに、これはクライアントが最後にこのIPアドレスについては、このサーバーを扱っていることDHCPLEASEACTIVEメッセージが送信された時点から過去の秒の整数でなければならない、1月1日からの秒の絶対数にすることはできません。 IPアドレスのリース時間オプション（オプション51）は、メッセージが送信された時点から未来への秒数であるリース時間を符号化し、このオプションは過去に秒数で値を符号化するのと同じようにメッセージが送信されたときから。
The code for the this option is 91. The length of the this option is 4 octets.
このオプションのためのコードは、このオプションの長さが4つのオクテットで91です。
Code Len Seconds in the past
+-----+-----+-----+-----+-----+-----+
| 91 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
associated-ip
関連する-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.
このオプションのためのコードは、このオプションの最小の長さが4つのオクテットで92であり、そして長さが常に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、DHCPLEASEACTIVE、または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のこの使用はGIADDRが常にDHCP応答メッセージのリターンアドレスとして使用されている[RFC2131]でのgiaddrの定義と一致していることに留意されたいです。 RFC 2131でいくつかの（すべてではない）のコンテキストでは、GIADDRは、適切なアドレスプールにアクセスするための「鍵」として使用されます。 DHCPLEASEQUERYメッセージはGIADDRは、「キー」として使用することはできませんこれらの場合のいずれかです。
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:
IPアドレスによるOクエリ：
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.
クライアント識別子オプション（オプション61）は、パケットに現れてはいけません。
o Query by MAC address:
MACアドレスによるOクエリ：
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.
クライアント識別子オプション（オプション61）は、パケットに現れてはいけません。
o Query by Client-identifier option:
クライアント識別子オプションにより、Oクエリ：
There MUST be a Client-identifier option (option 61) in the DHCPLEASEQUERY message.
DHCPLEASEQUERYメッセージにクライアント識別子オプション（オプション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サーバに送ってもよいし、いずれかがある場合は、IPアドレスに関する信頼できる情報を持っている可能性があるDHCPサーバーに関する情報がない場合には、それが（関連するリレーエージェントに設定されたすべての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.
クライアント識別子によりIPアドレスによるクエリ、MACアドレスによるクエリ、およびクエリ：DHCPLEASEQUERYメッセージを実装し、サーバはすべての3つのクエリ政権を実装しなければなりません。
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を持たなければなりません。非ゼロciaddr、非ゼロhtypeフィールド/ HLEN /とchaddr、またはClient-identifierオプション：DHCPLEASEQUERYメッセージは正確に次のいずれかを持っていなければなりません。
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のこの使用はGIADDRが常にDHCP応答メッセージのリターンアドレスとして使用されている[RFC2131]でのgiaddrの定義と一致していることに留意されたいです。 RFC 2131でいくつかの（すべてではない）のコンテキストでは、GIADDRは、適切なアドレスプールにアクセスするための「鍵」として使用されます。 DHCPLEASEQUERYメッセージはGIADDRは、「キー」として使用することはできませんこれらの場合のいずれかです。
There are three possible responses to a DHCPLEASEQUERY message:
DHCPLEASEQUERYメッセージには3個の可能な応答があります。
o DHCPLEASEUNASSIGNED
または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アドレスか、現在のIPアドレスのリースを持たないDHCPLEASEQUERYメッセージで指定されたクライアントを管理していないことを示しています。
When responding with a DHCPLEASEUNKNOWN, the DHCP server MUST NOT include other DHCP options in the response.
DHCPLEASEUNKNOWNで応答するとき、DHCPサーバーが応答して、他のDHCPオプションを含んではいけません。
o DHCPLEASEACTIVE
O DHCPLEASEACTIVE
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メッセージは、サーバがDHCPLEASEACTIVEメッセージで指定された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.
「ciaddr」フィールドに表示されます1 - - 対応する程度IPアドレスが重要な問題となっている決意DHCPLEASEQUERY要求に対する応答は1つの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.
そのIPアドレスはDHCPサーバによって管理されるものであれば、IPアドレスがDHCPLEASEQUERYメッセージの「ciaddr」フィールドに表示された場合には、そのIPアドレスはDHCPLEASEUNASSIGNEDメッセージの「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メッセージはクライアント識別子またはMACアドレスによるクエリです。 DHCPLEASEQUERYメッセージでMACアドレスフィールドが非であれば、この場合には、クライアントのアイデンティティは、（クライアント識別子オプションがDHCPLEASEQUERYメッセージに表示されている場合）、同一のクライアント識別子オプションを差し出さた任意のクライアント、または同一のMACアドレス（あります-ゼロ）。このクライアントマッチングアプローチは、このセクションの目的のために、「クライアント識別子または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.
「ciaddr」フィールドはDHCPLEASEQUERYメッセージでゼロであれば、DHCPLEASEACTIVEメッセージの「ciaddr」フィールドに配置されたIPアドレスは、最後にIPアドレスを使用するクライアントは、クライアント - と一致しているIPアドレスのものでなければならない（MUST） 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アドレスがあれば、それはDHCPLEASEACTIVEメッセージの「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.
複数のIPアドレスをMACアドレスまたはクライアント識別子オプションで指定されたクライアントによってアクセスされた場合は、その後、DHCPサーバは、IPアドレスはDHCPでない限り、クライアントと直近の取引でクライアントに返さ返さなければなりませんサーバーは、他のいくつかの好みのメカニズムを使用するようにサーバー管理者によって設定されています。
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又はDHCPLEASEACTIVEメッセージの「ciaddr」フィールドに設定されていない場合、DHCPLEASEUNKNOWNメッセージが代わりに返さなければなりません。
6.4.2. Building a DHCPLEASEUNASSIGNED or DHCPLEASEACTIVE Message Once the "ciaddr" Field Is Set
6.4.2. 「ciaddr」フィールドが設定されるとDHCPLEASEUNASSIGNEDまたはDHCPLEASEACTIVEメッセージの構築
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.
DHCPLEASEUNASSIGNEDの「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またはDHCPLEASEACTIVEメッセージの「ciaddr」フィールドにIPアドレスは、このサーバが（またはDHCPLEASEUNKNOWNメッセージは、すでに前のセクションで説明した処理の早い段階で返されたことになる）担当する1でなければなりません。
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.
DHCPLEASEACTIVEメッセージの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.
クライアント識別子オプション（オプション61）はパラメータ要求リストのオプション（オプション55）で指定されている場合は、「ciaddr」フィールドにIPアドレスに関連付けられたクライアントのクライアント識別子は、（もしあれば）で返されるべきである（SHOULD） 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.
複数のIPアドレスは、MACアドレスおよび/またはクライアント識別子オプションで指定されたクライアントとDHCPメッセージ交換に関与してきた場合には、その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）時間値オプションまたはDHCPLEASEQUERYメッセージのパラメータ要求リストの再バインド（T2）時間値オプションの要求は、リース期間オプションが処理される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サーバは、DHCPLEASEACTIVEオプションの値を供給するために、そのリースバインディングデータベースからの情報を使用しています。 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アドレスバインディング情報に加えて、相互にリレーエージェント情報オプションの情報を通信することを保証しなければなりません。
6.4.3. Sending a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN Message
6.4.3. DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、またはDHCPLEASEUNKNOWNメッセージを送信
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、DHCPLEASEACTIVE、又はDHCPLEASEUNKNOWNメッセージをユニキャストします。 「GIADDR」フィールドがゼロの場合は、DHCPサーバはDHCPLEASEQUERYメッセージに返信してはなりません。
6.5. Receiving a DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN Message
6.5. DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、またはDHCPLEASEUNKNOWNメッセージの受信
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.
DHCPLEASEACTIVEメッセージがDHCPLEASEQUERYメッセージに応答して受信されると、それはこのDHCPサーバーでこのIPアドレスの現在アクティブなリースがあることを意味します。アクセスコンセントレータは「htypeフィールド」、「HLEN」、およびDHCPLEASEACTIVEの「と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.
いずれの場合も、DHCPLEASEUNASSIGNEDまたはDHCPLEASEACTIVEメッセージが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メッセージを送出したアクセスコンセントレータによって受信されると、それは連絡をDHCPサーバはDHCPLEASEQUERYメッセージをサポートすることを意味しますが、DHCPサーバは「ciaddr」フィールドに含まれるIPアドレスに関する決定的な情報を持っていないことDHCPLEASEQUERYメッセージの。 DHCPLEASEQUERYメッセージの「ciaddr」フィールドにIPアドレスがない場合は、DHCPLEASEUNKNOWNメッセージは、DHCPサーバは、DHCPの「HLEN」、「htypeフィールド」で指定されたクライアント、および「とchaddr」に関する決定的な情報を持っていないことを意味しますフィールドまたは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.
この情報をキャッシュされた、アクセスコンセントレータはまれにしかDHCPLEASEUNKNOWNで特定の「ciaddr」フィールドのDHCPLEASEQUERYメッセージに応答したDHCPサーバにDHCPLEASEQUERYメッセージを指示すべきです。
When an access concentrator receives no response to a DHCPLEASEQUERY message, there are several possible reasons:
アクセスコンセントレータは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.
DHCPLEASEQUERYまたは対応するDHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、またはDHCPLEASEUNKNOWN oを送信中に失われたか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例第二に、再送は適切ではないであろう。 （なぜならそれがないかDHCPLEASEQUERYメッセージをサポートしていないことを示す他のDHCPLEASEQUERYメッセージへのDHCPサーバの応答で、おそらく、以外）離れてこれらの2つの場合を伝える方法はありません。
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メッセージは、そうでない場合は、まだ多くのパケット1程度以下10秒ごと、およびの割合でDHCPLEASEQUERYメッセージをサポートすることが知られていないサーバーに到達しないように、バックオフアプローチを調整する必要があり（アクセスコンセントレータは、必要がある場合70秒に1つのDHCPLEASEQUERY未満ではない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分後に期限が切れます。サーバごとのタイマーが期限切れになったオフに開始すると、期限切れの状態で唯一の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メッセージへの最初の応答の後、サーバごとのタイマーがスタートします。総数は100または200に制限されるべきであるけれども、その時点で、複数DHCPLEASEQUERYメッセージがDHCPサーバをスワンピング避けるために、DHCPサーバに並列に送信することができます。これらのメッセージのそれぞれには、[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.
1分間何もDHCPLEASEQUERYトラフィックがないことをイベントでは、その後、サーバ単位のタイマーが期限切れになります。その時間の後、唯一のそのメッセージに対する応答が受信されるまで、そのサーバーに卓越したことが許さ1つのDHCPLEASEQUERYメッセージがあるでしょう。
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.
DHCPLEASEQUERY機能を実装するDHCPサーバの実装は、2つの理由のために最新のDHCPREQUESTパケットから最新のリレーエージェント情報オプションを保存する必要があります。まず、どんなDHCPLEASEQUERY要求では、dhcp-parameter-request-listオプションにによって要求されることはほぼ確実です。第二に、保存されたリレーエージェント情報オプションは、これらがDHCPLEASEQUERY要求でDHCPパラメータ要求リストによって要求された場合、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クライアントパケットからrelay-agent-infoオプションは：結合して保存する必要があります。
o client-last-transaction-time of last client interaction: MUST store with binding.
最後のクライアントとの対話のクライアント - 最後のトランザクション時○：結合して保存する必要があります。
o vendor-class-id: SHOULD store with binding.
OベンダークラスID：結合を格納する必要があります。
These data storage requirements are minimally larger than those required for normal operation of the DHCP protocol, as required to properly implement [RFC2131].
これらのデータストレージ要件を適切に[RFC2131]を実装するために必要に応じて、DHCPプロトコルの正常動作に必要なものより最小限に大きいです。
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サーバは（例えば2台のDHCPサーバーは、高可用性DHCPサービスを提供するために協力しているときのように）同じIPアドレスに関する信頼できる情報が含まれていてもよい環境でのDHCPLEASEQUERYメッセージを使用する場合は、複数の、おそらく競合、応答が受信される可能性があります。
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.
この場合、応答パケット内のいくつかの情報は、各種の応答の中で決定するために使用されるべきです。クライアント - 最後のトランザクション時間が（それが利用可能な場合）のIPアドレスは「ciaddr」フィールドに返さに関するより最新の情報を持っているサーバーを決定するために使用することができます。
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.
DHCP落穂拾いを使用したアクセスコンセントレータは、DHCPLEASEQUERYメッセージでリフレッシュ、正確な位置情報を維持します。位置情報の精度は、アクセスコンセントレータは、（アクセス・ネットワークからのデータグラムのIP送信元アドレスの検証を行うことができ、ブロードバンドアクセスネットワーク内の意図された位置にデータトラフィックを転送することができ、そしてのみ意図アクセスモデムによって復号化することができるトラフィックを暗号化することができることを確実にします例えば、[BPI]と[BPI +]）。その結果、アクセスコンセントレータは、意図したIPエンドポイントになりすます悪質なホストの影響を受けやすい、アクセスネットワーク、全体にARPブロードキャストに依存する必要はありません。このように、DHCPLEASEQUERYメッセージは、アクセスコンセントレータはかなり強化されたセキュリティを提供することができます。
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サーバは、「DHCPメッセージの認証」、[RFC3118]に詳述された技術を用いて位置情報（ブロードバンド加入者のプライバシーの侵害とすることができる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
[RFC3118]は、通常のDHCPクライアントの相互作用を説明しているので、DHCPDISCOVER、DHCPOFFER、DHCPREQUEST、およびDHCPACKからなる、DHCPLEASEQUERYドメインに[RFC3118]で説明した動作を転置する必要があります。 [RFC3118]で説明した動作のために
DHCPDISCOVER are performed for DHCPLEASEQUERY, and the operations described for DHCPOFFER are performed for DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN messages.
DHCPDISCOVERはDHCPLEASEQUERYに対して行われ、DHCPOFFERについて記載した操作はDHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、及びDHCPLEASEUNKNOWNメッセージに対して実行されます。
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サーバ上のサービス拒否攻撃を最小限に抑える必要があります。具体的には、アクセスコンセントレータは、ネガティブキャッシュを使用すべきである（すなわち、DHCPLEASEQUERYメッセージにキャッシュDHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、及びDHCPLEASEUNKNOWN応答）とciaddr制限（すなわち、添付のブロードバンドアクセスの範囲外ciaddrとDHCPLEASEQUERYメッセージを送信しませんネットワーク）。一緒に、これらのメカニズムは、再起動イベントの後に正当なブロードバンドアクセスネットワークのIPアドレスごと（メッセージの再試行を除く）を一度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つの新しいメッセージタイプが存在します。定義された2つの新しいDHCPオプションがあり、DHCPLEASEQUERYの値はDHCPLEASEUNKNOWNの値が12である、DHCPLEASEUNASSIGNEDの値は11であり、10であり、そしてDHCPLEASEACTIVEの値は最後に13です。クライアント - 最後のトランザクション時のオプション - オプションコード91、および関連する-IPオプション - オプションコード92。
Jim Forster, Joe Ng, Guenter Roeck, and Mark Stapp contributed greatly to the initial creation of the DHCPLEASEQUERY message.
ジム・フォースター、ジョー・呉、ギュンターRoeck、そしてマーク・スタップは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.
パトリックGuelatは、静的IPアドレスをサポートするために、いくつかの改良を提案しました。トーマスNarten氏は、改善のための多くの提案をしました。ラスHousleyは増加したセキュリティ機能のために効果的に押され、そしてテッドハーディーは、望ましくない情報漏洩を最小限にする方法を提案しました。バートWijnenは、私たちがDHCPv4のに我々の焦点を明確にし、DHCP MIBのことから、我々のアプローチを区別提案しました。 R.バールヒッブス、DHCP MIBの著者の一人は、効果的にDHCPLEASEQUERYからその努力を区別するための情報を提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]パトリック、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]プラマー、D.、「イーサネットアドレス解決プロトコル：またはイーサネットハードウェア上での送信のためにイーサネット（登録商標）アドレスを48ビットに、ネットワーク・プロトコル・アドレス変換」、STD 37、RFC 826、1982年11月。
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC951]クロフト、W.及びJ.ギルモア、 "ブートストラッププロトコル"、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]アレクサンダー、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、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データ標準分科会、「データオーバーケーブルサービスインターフェイス仕様：2002 DOCSIS 1.0ベースラインプライバシーインターフェイス仕様SCTE 22-2」http://www.scte.org/standards/で入手可能な、2002、。
[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" http://www.cablemodem.com/で入手可能な、2005年8月、。
[DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration Protocol (DHCP) Server MIB", Work in Progress, February 2004.
[DHCPMIB]ヒッブス、R.、ウォーターズ、G.、 "動的ホスト構成プロトコル（DHCP）サーバーのMIB"、進歩、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」http://www.scte.org/standards/で入手可能な、2002、。
[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
リッチWoundy Comcastのケーブル27産業アベニュー。チェルムズフォード、MA 01824
Phone: (978) 244-4010 EMail: richard_woundy@cable.comcast.com
電話：（978）244-4010 Eメール：richard_woundy@cable.comcast.com
Kim Kinnear Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719
キム・キニアシスコシステムズ1414マサチューセッツアベニューボックスボロー、MA 01719
Phone: (978) 936-0000 EMail: kkinnear@cisco.com
電話：（978）936-0000 Eメール：kkinnear@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。