RFC4388 日本語訳
4388 Dynamic Host Configuration Protocol (DHCP) Leasequery. R. Woundy,K. Kinnear. February 2006. (Format: TXT=63914 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Woundy
Request for Comments: 4388 Comcast Cable
Category: Standards Track K. Kinnear
Cisco Systems
February 2006
Woundyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4388年のコムキャストケーブルカテゴリ: 標準化過程K.キネアシスコシステムズ2006年2月
Dynamic Host Configuration Protocol (DHCP) Leasequery
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
Dynamic Host Configuration Protocolバージョン4(DHCPv4)サーバはそれがDHCPv4クライアントに提供したIPアドレスの権威筋です。 既にDHCPv4を利用する他のプロセスとデバイスは、この情報にアクセスする必要があるかもしれません。 leasequeryプロトコルはIPアドレス情報にアクセスする軽量の方法をこれらのプロセスとデバイスに供給します。
Woundy & Kinnear Standards Track [Page 1] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[1ページ]。
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
1. 序論…2 2. 用語…5 3. バックグラウンド…7 4. 目標を設計してください…7 4.1. 放送ARPは望ましくありません…7 4.2. SNMPとLDAPは適切ではありません…8 4.3. DHCP中継エージェントの機能性は一般的です…8 4.4. DHCPサーバは位置情報の信頼すべき筋です…9 4.5. 最小量の追加構成が必要です…9 5. 概要について議定書の中で述べてください…9 6. 詳細について議定書の中で述べてください…12 6.1. 定義がDHCPLEASEQUERY処理に必要です…12 6.2. DHCPLEASEQUERYメッセージを送ります…14 6.3. DHCPLEASEQUERYメッセージを受け取ります…15 6.4. DHCPLEASEQUERYメッセージに応じます…16 6.5. DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、またはDHCPLEASEUNKNOWNメッセージを受け取ります…20 6.6. DHCPLEASEQUERYメッセージへの応答を全く受けません…21 6.7. 拘束力があるデータ保存要件を賃貸してください…22 6.8. 複数のDHCPサーバがあるDHCPLEASEQUERYメッセージを使用します…23 7. セキュリティ問題…23 8. IANA問題…24 9. 承認…24 10. 参照…25 10.1. 標準の参照…25 10.2. 有益な参照…25
1. Introduction
1. 序論
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パケットを送って、受ける能力が既にあるので、leasequeryプロトコルはそのような情報にアクセスする低いオーバーヘッド方法をこれらのプロセスとデバイスに与えるように設計されています。
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
例えば、DHCPがエージェントをリレーするとき作動するアクセス集中装置は時々それらが進めるDHCPパケットからデータを抜粋することによって彼らの操作に重要な情報を引き出します、「落ち穂拾い」として知られているプロセス。 残念ながら、典型的なアクセス集中装置はいつアクセス集中装置をリブートするか、または取り替えるかという収集された情報を失います。 このメモは、収集されたDHCP情報が利用可能でないときに、アクセス集中装置/中継エージェントが得ることができるよう提案します。
Woundy & Kinnear Standards Track [Page 2] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[2ページ]。
location information directly from the DHCP server(s) using the DHCPLEASEQUERY message.
直接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|
+-----+ +-----+ +-----+
+--------+ +---------------+ | DHCP| | DOCSIS CMTS| | サーバ|-...-| または、DVB INA|------------------- +--------+ | (中継エージェント) | | | +---------------+ +------+ +------+ |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|
+-----+ +-----+ +-----+
+--------+ +---------------+ | DHCP| | DSLアクセス| +-------+ | サーバ|-...-| 集中装置|-...-| DSLAM| +--------+ | (中継エージェント) | +-------+ +---------------+ | | +------+ +------+ |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. アクセス集中装置は正しいアクセスネットワークポートを使用することでアクセスネットワークにトラフィックを送ることができます、正しい仮想の回路の下側に、正しいモデムを通して、正しいハードウェア・アドレスに。
Woundy & Kinnear Standards Track [Page 3] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[3ページ]。
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アドレスにありませんが、このIPアドレスに、このDHCPサーバが正式であることを示します。 DHCPLEASEUNKNOWNメッセージは、DHCPサーバで質問(例えば、IPアドレス、MACアドレス、またはClient-識別子オプション)で情報に関する知識を全く指定しないのを示します。
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]の本質を考えて、そうする願望が存在しているなら、DHCPLEASEQUERYメッセージ相互作用をDHCPv4とDHCPv6の間で一般的にするのさえどんな効果的な方法もありません。
Woundy & Kinnear Standards Track [Page 4] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[4ページ]。
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プロトコルが広く使用中であった何年も後に現れた1セットの特定の本当の世界実装の必要性の結果でした。 その上、この書くこと時点で、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を追加するというわけではありませんでした。本書では、IPv4アドレスを意味するためにIPアドレスのすべての参照を取るべきです、そして、DHCPv4サーバとDHCPv4クライアントを意味するためにDHCPサーバとDHCPクライアントについてのすべての言及を取るべきです。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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中継エージェントはBootstrapプロトコル(BOOTP)とDHCPメッセージを異なったサブネットにあるクライアントとサーバの間に移す第三者エージェントです、[RFC951]と[RFC1542]単位で。
Woundy & Kinnear Standards Track [Page 5] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[5ページ]。
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.
上流はアクセス集中装置に向かった広帯域の加入者からの方向です。
Woundy & Kinnear Standards Track [Page 6] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[6ページ]。
3. Background
3. バックグラウンド
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メッセージで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 Cable Modem Termination Systems(CMTSs)[DOCSIS]、DVB Interactive Network Adapters(INAs)[EUROMODEM]、およびDSL Access Concentratorsを含んでいます。
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アドレスかそれに関連している拘束力がある情報の状態に影響しません。
4. Design Goals
4. デザイン目標
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.
異なった方法でこの何らかの情報を取得するかもしれなくて、以下のセクションはこれらの代替的アプローチのいくつかについて論じます。
4.1. Broadcast ARP Is Undesirable
4.1. 放送ARPは望ましくありません。
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)が要求する放送Address Resolutionプロトコル[RFC826]を伝えて、位置情報を再建するためにARP Replyの発生源とコンテンツを観測できます。
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サブネットが複数のポートか仮想の回路にかかると仮定する)の上に送るアクセス集中装置での負担
Woundy & Kinnear Standards Track [Page 7] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[7ページ]。
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終点としてそれ自体を誤り伝えることができる容易さ。
4.2. SNMP and LDAP Are Not Appropriate
4.2. SNMPとLDAPは適切ではありません。
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].
アクセス集中装置実装には、管理クライアントが連結して、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)クライアントが連結するSimple Network Managementプロトコル(SNMP)が通常ありません(SNMP管理エージェントを通常含んでいますが)。 これはこのドキュメントが提案されたDHCP Server 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 Server 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見地から同様にお勧めできないでしょう。
4.3. DHCP Relay Agent Functionality Is Common
4.3. DHCP中継エージェントの機能性は一般的です。
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
特定の川下のリンクに、有効なIPアドレスを決定するテクニックとしての落ち穂拾いメカニズムは追加ネットワークトラフィックの不足のために他のメカニズム(アルプ、SNMP、LDAP)より好まれますが、時々情報を収集するのは不完全である場合があります。 通常、アクセス集中装置は性能理由のためどんなDHCPユニキャスト(すなわち、非リレーされた)メッセージからの情報も収集できません。 その上、DHCPによって収集された位置情報、しばしば
Woundy & Kinnear Standards Track [Page 8] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[8ページ]。
does not persist across access concentrator reboots (due to lack of stable storage), and almost never persists across concentrator replacements.
アクセス集中装置リブート(安定貯蔵の不足による)の向こう側に固執していなくて、また集中装置交換の向こう側にほとんど固執していません。
4.4. DHCP Servers Are a Reliable Source of Location Information
4.4. 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アドレスでアクセス集中装置を構成できます、どんな1DHCPのサーバも1ポイントの失敗でないように。
4.5. Minimal Additional Configuration Is Required
4.5. 最小量の追加構成が必要です。
Access concentrators can usually query the same set of DHCP servers used for forwarding by the relay agent, thus minimizing configuration requirements.
通常、アクセス集中装置は推進に中継エージェントによって使用された同じセットのDHCPサーバについて質問できます、その結果、構成必要条件を最小にします。
5. Protocol Overview
5. プロトコル概要
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中継エージェント機能における位置情報を収集すると仮定します。 しかしながら、通常、位置情報はアクセス集中装置のリブートか交換の後に入手できません。
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データグラムを受けるとさらに仮定してください。 次の川下のホップのための位置情報がなくなるなら、アクセス集中装置は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.
次に、このクライアントのリースが最後に承諾されたか、または更新されたとき現情報を返すことによって、この質問は答えられるでしょう、アクセス集中装置がIPデータグラムを進めるのを許容して。
Woundy & Kinnear Standards Track [Page 9] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[9ページ]。
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.
代替的アプローチは"ciaddr"野原が人影がなく、有効なMACアドレスかClient-識別子オプション(オプション61)があるMACアドレス(すなわち、"htype"、"hlen"、および"chaddr"分野)がオプション部門に現れていてDHCPLEASEQUERYメッセージを送ることです。 この場合、Client-識別子かMACアドレスでクライアントのどんな記録についても説明するなら、それでDHCPサーバはciaddrのIPアドレスを返さなければなりません。 それと反対(セクション6.4を見る)な特定の設定情報がないときそれ、SHOULD、MACアドレスかClient-識別子オプションで説明されるクライアントとの最後のトランザクション時間の最新のクライアントが関連している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、DHCPLEASEACTIVEかDHCPLEASEUNKNOWNのどちらか。 DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、またはDHCPLEASEUNKNOWNメッセージが生成されるかもしれない理由は下の特定の質問政権で説明されます。
Servers that do not implement the DHCPLEASEQUERY message SHOULD simply not respond.
DHCPLEASEQUERYメッセージがSHOULDであると実装しないサーバが絶対に反応しません。
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.
この質問のために、リクエスタは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:
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
この質問のために、リクエスタはDHCPLEASEQUERYメッセージのMACアドレスだけを供給します。 DHCPサーバはそれがごく最近そのMACアドレスでクライアントによってアクセスされたIPアドレスに持っているどんな情報も返すでしょう。 さらに、それは異なったサブネットにおけるそのMACアドレスに関連した追加IPアドレスを供給するかもしれません。 これらの結合に関する情報
Woundy & Kinnear Standards Track [Page 10] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[10ページ]。
can then be found using the Query by IP Address, described
above.
そして、上で説明されたIP AddressでQueryを使用しているのを見つけることができます。
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.
活発なリースがこのサーバのIPアドレスにある状態でDHCPLEASEQUERYメッセージのMACアドレスがMACアドレスに一致しているなら、DHCPサーバはDHCPLEASEACTIVEメッセージで返答します。サーバにこのMACアドレスがこのDHCPサーバにある状態でクライアントによる活発なリースが現在ないなら、サーバはDHCPLEASEUNKNOWNメッセージで返答します。
o Query by Client-identifier option:
o Client-識別子オプションで以下について質問してください。
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メッセージにおけるClient-識別子オプションだけを供給します。 DHCPサーバはそれがごく最近そのClient-識別子でクライアントによってアクセスされたIPアドレスに持っているどんな情報も返すでしょう。 さらに、それは異なったサブネットにおけるClient-識別子に関連した追加IPアドレスを供給するかもしれません。 そして、上で説明されたIP AddressでQueryを使用しているのをこれらの結合に関する情報を見つけることができます。
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メッセージのClient-識別子が現在このDHCPサーバのIPアドレスに活発なリースを持っているなら、DHCPサーバはDHCPLEASEACTIVEメッセージで返答します。サーバにクライアントによる活発なリースがこのClient-識別子と共にないなら、サーバは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のフォームです。できれば、SHOULDは使用されます。
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メッセージSHOULDは"htype"、"hlen"、および"chaddr"分野にIPアドレスリース所有者の物理アドレスを保管しています。 ciaddrのIPアドレスに関して返されるよう特定のオプションに要求するのに、Parameter Request List(オプション55)を使用できます。 回答はしばしば借用期限の終了までの時間、およびRelayエージェント情報オプション[RFC3046]に関するオリジナルコンテンツを含んでいます。 アクセス集中装置は、位置情報を構成するのに"chaddr"分野とRelayエージェント情報オプションを使用します。(アクセス集中装置の上にリース満了まで位置情報をキャッシュできます)。
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
最新のRelayエージェント情報オプション(オプション82)[RFC3046]からSHOULDが保存するDHCPLEASEQUERYメッセージに情報をサポートするどんなDHCPサーバもそれが役立つあらゆるIPアドレスと交際しました。 DHCPLEASEQUERYメッセージを生成するほとんどのクライアントがRelayエージェント情報を求めると思われます。
Woundy & Kinnear Standards Track [Page 11] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[11ページ]。
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.
Parameter Request List(オプション55)と、したがって、あまり役立っていないのをクライアントに戻りそうであるというRelayエージェント情報オプションより持つことのないDHCPLEASEQUERYメッセージをサポートすることにおけるオプション(オプション82)。
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 SHOULDが最新のVendorクラス識別子の情報を保存する道具(オプション60)がそれぞれのIPアドレスに関連づけたサーバもDHCPLEASEQUERYメッセージを送るクライアントによって要求されていそうです。
6. Protocol Details
6. プロトコルの詳細
6.1. Definitions Required for DHCPLEASEQUERY Processing
6.1. 定義がDHCPLEASEQUERY処理に必要です。
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パケットのために以下の新しくて拡張している値の定義を必要とします。 IANA Considerations、また、セクション8を見てください。
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つの新しい値を必要とします: DHCPLEASEQUERYメッセージ自体のためのものとそれぞれの3の可能な応答DHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、DHCPLEASEUNKNOWNのためのもの。 これらのメッセージタイプの値は以下に[RFC2132]のセクション9.6からテーブルの拡大で示されます:
Value Message Type
----- ------------
10 DHCPLEASEQUERY
11 DHCPLEASEUNASSIGNED
12 DHCPLEASEUNKNOWN
13 DHCPLEASEACTIVE
値のメッセージタイプ----- ------------ 10 DHCPLEASEQUERY11DHCPLEASEUNASSIGNED12DHCPLEASEUNKNOWN13DHCPLEASEACTIVE
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サーバからのDHCPLEASEACTIVEメッセージが、比較される必要があるとき、それは特に役に立ちます、それが他の状況で役に立つ場合がありますが。 値は現在の最も最近このIPアドレスがクライアントとDHCPサーバとのコミュニケーションの対象であった過去までの時間からの秒の持続時間です。
Woundy & Kinnear Standards Track [Page 12] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[12ページ]。
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アドレスに関するこのサーバに対処したというDHCPLEASEACTIVEメッセージが送られる時からの過去の整数秒数であるに違いありません。 IP Address Lease Timeオプション(オプション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 |
+-----+-----+-----+-----+-----+-----+
過去の+のコードレンSeconds-----+-----+-----+-----+-----+-----+ | 91 | 4 | t1| t2| t3| t4| +-----+-----+-----+-----+-----+-----+
3. There in a second new option, the associated-ip option:
3. そこ、2番目の新しいオプション、関連ipオプションで:
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.
このオプションのためのコードは92です。 このオプションのための最小の長さは4つの八重奏です、そして、いつも長さは4の倍数であるに違いありません。
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 92 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
コードレンアドレス1アドレス2+-----+-----+-----+-----+-----+-----+-----+-----+-- | 92 | n| a1| a2| a3| a4| a1| a2| ... +-----+-----+-----+-----+-----+-----+-----+-----+--
Woundy & Kinnear Standards Track [Page 13] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[13ページ]。
6.2. Sending the DHCPLEASEQUERY Message
6.2. DHCPLEASEQUERYメッセージを送ります。
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 Message Typeオプション(オプション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の定義と一致していることに注意してください。 RFC2131のいくつかの(すべてでない)文脈では、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 オプションへのセットはリクエスタに興味があったなら、Parameter Request ListがSHOULDにゆだねます(オプション55)。 おもしろいオプションはIP Address Lease Timeオプション(オプション51)、Relayエージェント情報オプション(オプション82)、およびことによるとVendorクラス識別子オプション(オプション60)を含んでいそうです。 Parameter Request Listオプションがないとき、サーバSHOULDはそれがDHCPLEASEQUERYメッセージを含まなかったDHCPREQUESTメッセージのために返す同じオプションを返して、どれがそれらを含んでいるかがどんなオプションと同様に.1セクション4.3[RFC2131]でサーバがいつもクライアントに戻るために構成されたのを強制しました。
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.
Client-識別子オプション(オプション61)はパケットに現れてはいけません。
Woundy & Kinnear Standards Track [Page 14] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[14ページ]。
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.
捜し求めるMACアドレスの値にhtype、hlen、およびchaddrの値を設定しなければなりません。
The "ciaddr" field MUST be set to zero.
"ciaddr"分野をゼロに設定しなければなりません。
The Client-identifier option (option 61) MUST NOT appear in the
packet.
Client-識別子オプション(オプション61)はパケットに現れてはいけません。
o Query by Client-identifier option:
o Client-識別子オプションで以下について質問してください。
There MUST be a Client-identifier option (option 61) in the
DHCPLEASEQUERY message.
DHCPLEASEQUERYメッセージにはClient-識別子オプション(オプション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はSHOULDを通信させます。IPアドレスに関して信頼できる情報を持っているのが知られているDHCPサーバに送ります。 DHCPLEASEQUERYメッセージを1つ以上のDHCPサーバに送って、どのDHCPに関するIPアドレスに関してサーバには信頼できる情報があるかもしれなくて、それがSHOULDであるかという情報がないとき関連中継エージェントのために構成されたすべての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.
それが使用するRelayエージェントInfoオプションがそんなに明白に情報を含んでいるというSHOULDが確実にするDHCPLEASEQUERYメッセージを使用すると予想するどんなデバイスもデバイスを特定します。
6.3. Receiving the DHCPLEASEQUERY Message
6.3. 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アドレスで質問して、Client-識別子は質問します。
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メッセージには、ちょうど以下の1つがなければなりません: 非ゼロciaddr、非ゼロhtype/hlen/chaddr、またはClient-識別子オプション。
The DHCP server that receives a DHCPLEASEQUERY message MUST base its response on the particular data item used in the query.
DHCPLEASEQUERYメッセージを受け取るDHCPサーバは応答を質問に使用される特定のデータ項目に基礎づけなければなりません。
Woundy & Kinnear Standards Track [Page 15] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[15ページ]。
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の定義と一致していることに注意してください。 RFC2131のいくつかの(すべてでない)文脈では、giaddrは、適切なアドレスプールにアクセスするのに「キー」として使用されます。 DHCPLEASEQUERYメッセージはそのような「キー」としてgiaddrを使用してはいけないそれらのケースの1つです。
6.4. Responding to the DHCPLEASEQUERY Message
6.4. DHCPLEASEQUERYメッセージに応じます。
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 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メッセージで反応しなければなりません。
Woundy & Kinnear Standards Track [Page 16] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[16ページ]。
6.4.1. Determining the IP address about Which to Respond
6.4.1. Whichに関するIPアドレスをRespondに決定します。
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オプション(セクション6.1、#3)でクライアントがリースを持っている追加IPアドレスの値を返さなければなりません。 これは直接でない"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アドレスがDHCPLEASEQUERYメッセージの"ciaddr"分野に現れる場合、そのIPアドレスがDHCPサーバによって管理されたものであるならDHCPLEASEUNASSIGNEDメッセージの"ciaddr"分野にそのIPアドレスを設定しなければなりません。
If the IP address is not managed by the DHCP server, then a DHCPLEASEUNKNOWN message must be returned.
DHCPサーバでIPアドレスを管理しないなら、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メッセージはClient-識別子かMACアドレスで質問です。 この場合、クライアントのアイデンティティは同じClient-識別子オプション(Client識別子オプションが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アドレスを使用したクライアントがDHCPLEASEQUERYメッセージで指定されたClient-識別子かMACアドレスに合っているIPアドレスのものであるに違いありません。
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.
そして、1つ以上のIPアドレスがMACアドレスかClient-識別子オプションで指定されたクライアントによってアクセスされた場合では、DHCPサーバはDHCPサーバがある他の好みのメカニズムを使用するためにサーバアドミニストレータによって構成されていない場合クライアントがいる最新のトランザクションでクライアントに返されたIPアドレスを返さなければなりません。
Woundy & Kinnear Standards Track [Page 17] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[17ページ]。
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メッセージがそうであるだろう、早く前項で説明された処理で既に返してください、そうした、)
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.
DHCPLEASEUNASSIGNEDメッセージの"ciaddr"分野のIPアドレスに関連しているクライアントを特定する値にDHCPLEASEACTIVEメッセージのMACアドレスを設定しなければなりません。
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.
Client-識別子オプション(オプション61)がParameter Request Listオプション(オプション55)で指定されるなら、そして、DHCPLEASEACTIVEメッセージで"ciaddr"分野SHOULDで返すIPアドレスに関連しているクライアントのClient-識別子です(もしあれば)。
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アドレス、そして/または、Client-識別子オプションで指定されている状態で1つ以上のIPアドレスがDHCP交換処理にかかわった場合では、次に、関連ipオプションでIPアドレスのすべてのリストを返さなければなりません、そのオプションがParameter Request Listオプションの一部として要求されたか否かに関係なく。
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 Address Lease Timeオプション(オプション51)がParameter Request Listで指定されて、現在有効なリースがciaddrで指定されたIPアドレスのためにあれば、リース満了まで残っていて、DHCPサーバは時間まで値の同輩がいるDHCPLEASEACTIVEメッセージにおけるこのオプションを返さなければなりません。 IPアドレスのためのどんな有効なリースもなければ、サーバはIP Address Lease Timeオプション(オプション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
IP Address Lease Timeオプションが扱われるようにRenewal(T1)時間ValueオプションかDHCPLEASEQUERYメッセージのParameter Request ListのRebinding(T2)時間Valueオプションを求める要求を扱わなければなりません。 有効なリースがあるか、そして、これらの回はそうではありません。
Woundy & Kinnear Standards Track [Page 18] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[18ページ]。
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.
そして、しかし、過去に、DHCPサーバSHOULDは残っている時間と共にこれらのオプションをそれぞれ更新か縛り直すまで返します(要求されると)。 これらの回が過去に既にあるか、または有効なリースが現在でないときにこの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.
Relayエージェント情報(オプション82)がParameter Request Listで指定されるなら、DHCPLEASEACTIVEメッセージにこのIPアドレスに関連している中継エージェントから受け取られた最新のRelayエージェント情報オプションに含まれた情報を含まなければなりません。
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メッセージSHOULDは、以下で議論した「非敏感なオプション」のリストに基づいて戻るために上で明確に議論したというわけではないすべてのDHCPLEASEQUERYメッセージのParameter Request Listで要求された、許容できる別の選択肢の値を含んでいます。
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サーバSHOULD、DHCPLEASEQUERYメッセージのParameter Request Listで指定されるとクライアントに返すことができる「非敏感なオプション」のリストで、構成可能であってください。 どんなオプションもこれにSHOULD NOTを記載しません。そのクライアントがクライアント要求しても、返してください。
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パケットのRelayエージェント情報オプションは、DHCPREQUESTを送ったDHCPクライアントに返されたオプションを決定するのを助けるのに使用されます。DHCPLEASEQUERYメッセージに応じるとき、DHCPサーバはDHCPLEASEQUERYメッセージによって要求されたどんなオプションの値も決定するためにDHCPクライアントに応じるときまさしくそれのような情報オプションがした保存しているRelayエージェントを使用しなければなりません。 目標は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アドレス結合情報に加えてRelayエージェント情報オプション情報を互いに伝えるのを確実にしなければなりません。
Woundy & Kinnear Standards Track [Page 19] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[19ページ]。
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を予想します、そして、ユニキャストのDHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、またはDHCPLEASEUNKNOWNがgiaddrへ通信します。 "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.
DHCPLEASEQUERYメッセージに対応してDHCPLEASEACTIVEメッセージを受け取るとき、それは、このDHCPサーバにはこのIPアドレスのための現在活発なリースがあることを意味します。アクセス集中装置SHOULDはこのIPアドレスに位置情報をリフレッシュするためにパケットにどんなRelayエージェント情報オプション情報も含んでいることと同様にDHCPLEASEACTIVEの"htype"、"hlen"、および"chaddr"分野で情報を使用します。
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.
DHCPLEASEQUERYメッセージに対応してDHCPLEASEUNASSIGNEDメッセージを受け取るとき、それは、DHCPサーバにおける現在のIPアドレスのためのどんな現在活発なリースもありませんが、事実上、このサーバがそのIPアドレスを管理することを意味します。 この場合、アクセス集中装置SHOULDは、アクセス集中装置の悪意があるか真剣に感染しているデバイス川下に直面してアクセス集中装置と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.
DHCPLEASEQUERYメッセージに対応してDHCPLEASEUNASSIGNEDかDHCPLEASEACTIVEメッセージを受け取るとき、どちらの場合ではも、反応したDHCPサーバがciaddrの現在のIPアドレスを管理するDHCPサーバであることを意味します、そして、RelayエージェントSHOULDは後の使用のためのこの情報をキャッシュします。
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
DHCPLEASEQUERYメッセージを出したアクセス集中装置でDHCPLEASEUNKNOWNメッセージを受け取るとき、それは、連絡されたDHCPサーバがDHCPLEASEQUERYメッセージをサポートしますが、DHCPLEASEQUERYメッセージの"ciaddr"分野に保管されていたIPアドレスに関してDHCPサーバには決定的な情報がないことを意味します。 IPアドレスが全くDHCPLEASEQUERYメッセージの"ciaddr"分野になければ、DHCPLEASEUNKNOWNメッセージはそれを意味します。
Woundy & Kinnear Standards Track [Page 20] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[20ページ]。
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.
DHCPサーバには、"hlen"、"htype"、および"chaddr"分野で指定されたDHCPクライアントかDHCPLEASEQUERYメッセージのClient-識別子オプションに関して決定的な情報がありません。
The access concentrator SHOULD cache this information, but only for a relatively short lifetime, approximately 5 minutes.
この情報をキャッシュしますが、アクセス集中装置SHOULDは比較的短い生涯だけおよそ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.
この情報をキャッシュしたので、アクセス集中装置SHOULDはDHCPLEASEUNKNOWNと共に特定の"ciaddr"分野へのDHCPLEASEQUERYメッセージに反応したDHCPサーバにDHCPLEASEQUERYメッセージをまれに向けるだけです。
6.6. Receiving No Response to the DHCPLEASEQUERY Message
6.6. 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.
o DHCPLEASEQUERY、対応するDHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、またはDHCPLEASEUNKNOWNがトランスミッションの間、なくされたか、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).
ケースの1番目では、上では、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.
指数のbackoffに近似する再試行時間にbackoffアルゴリズムを使用することでそれらに反応しないサーバにDHCPLEASEQUERYにメッセージを再送するDHCPLEASEQUERYメッセージSHOULD試みを利用するアクセス集中装置。 アクセス集中装置SHOULDがbackoffアプローチを調整するので、DHCPLEASEQUERYメッセージはおよそ1つ以上のパケットのレートにおけるDHCPLEASEQUERYメッセージが10秒毎であるとサポートするのは別の方法で知られないサーバ、およびしかし(アクセス集中装置が、メッセージをDHCPLEASEQUERYに送る必要があるなら)、少なくとも70秒あたり1DHCPLEASEQUERYに到着しません。
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.
たぶん実際には、aでこのアプローチを扱うだろう、最も良い-、DHCPLEASEQUERYメッセージへの応答が受け取られていて、1分後に期限が切れるときはいつも、再開されるサーバタイマ。 1サーバあたりのタイマは、満期で始めて、関連サーバのために満期の州の1DHCPLEASEQUERYだけのメッセージに列に並ばせられるでしょう。
Woundy & Kinnear Standards Track [Page 21] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[21ページ]。
All DHCPLEASEQUERY messages SHOULD use the exponential backoff algorithm specified in Section 4.1 of [RFC2131].
すべてのDHCPLEASEQUERYメッセージSHOULDが[RFC2131]のセクション4.1で指定された指数のbackoffアルゴリズムを使用します。
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.
したがって、初期状態では、1サーバあたりのタイマが満期です、そして、ただ一つのDHCPLEASEQUERYメッセージが各サーバのために列に並ばせられます。DHCPLEASEQUERYメッセージへの最初の応答の後に、1サーバあたりのタイマは始動されます。 その時、DHCPサーバに平行に複数のDHCPLEASEQUERYメッセージを送ることができて、総数SHOULDですが、100か200に制限されます。DHCPサーバを浸すのを避けてください、そして、それぞれに関するこれらのメッセージは[RFC2131]指数のbackoffアルゴリズムを使用します。 毎回これらのメッセージのどれかへの応答が受け取られている、-、サーバタイマは、リセットされて、再び最大1分に数え始めます。 イベントでは、1サーバあたりのタイマは発射されて、次に、すべての傑出しているメッセージがSHOULDです。DHCPLEASEQUERYへの別の(または、1番目)応答のような時間が受け取られているまでおよそ64秒の間隔で、サーバに投票するのに使用されるただ一つの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分間ないと、1サーバあたりのタイマは期限が切れるでしょう。 それ以後、そのメッセージへの応答が受け取られているまでそのサーバに傑出しているのが許容された1つのDHCPLEASEQUERYメッセージしかないでしょう。
6.7. Lease Binding Data Storage Requirements
6.7. 拘束力があるデータ保存要件を賃貸してください。
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パケットから最新のRelayエージェント情報がオプションであると保存しなければなりません。 まず最初に、それはdhcp-パラメタどんなDHCPLEASEQUERYのリストオプションも要求している要求で要求されているのが、ほとんど確かです。 2番目に、保存しているRelayエージェント情報オプションがDHCPクライアントに与えられた別の選択肢の値を決定するのに必要であるかもしれません、これらがDHCPLEASEQUERY要求における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 クライアントパケットからのリレーエージェントインフォメーションオプション: 結合で保存しなければなりません。
o client-last-transaction-time of last client interaction: MUST
store with binding.
o 最後のトランザクション時間の最後のクライアントとの対話のクライアント: 結合で保存しなければなりません。
o vendor-class-id: SHOULD store with binding.
o ベンダークラスイド: 結合があるSHOULD店。
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プロトコルの通常の操作に必要に応じて必要であるものより最少量で大きいです。
Woundy & Kinnear Standards Track [Page 22] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[22ページ]。
6.8. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers
6.8. 複数のDHCPサーバがあるDHCPLEASEQUERYメッセージを使用します。
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アドレス(2つのDHCPサーバが協力している、高可用性を提供する時などのDHCPサービス)を含むかもしれない環境で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.
この場合何らかの情報、応答パケットSHOULDでは、様々な応答の中で決めるのに使用されてください。 "ciaddr"分野で返されたIPアドレスに関してどのサーバにより最近の情報があるかを決めるために、クライアント最後のトランザクション時間(それが利用可能であるなら)を費やすことができます。
7. Security Considerations
7. セキュリティ問題
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落ち穂拾いを使用するアクセス集中装置が正確な位置情報を維持するでしょう。 位置情報精度は、アクセス集中装置が広帯域アクセスネットワークで意図している位置にデータ通信量を送ることができて、アクセスネットワークからデータグラムのIPソースアドレス検査を実行できて、意図しているアクセスモデム(例えば、[BPI]と[BPI+])で解読することができるだけであるトラフィックを暗号化できるのを確実にします。 その結果、アクセス集中装置はアクセスネットワークの向こう側にARP放送による必要はありません。意図しているIP終点のふりをする悪意があるホストにとって、ネットワークは影響されやすいです。 したがって、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サーバSHOULDは、[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メッセージを送るアクセス集中装置は本質的にはDHCPLEASEQUERYメッセージの目的のためのDHCPクライアントです、また、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、DHCPOFFER、DHCPREQUEST、およびDHCPACKから成って、[RFC3118]が正常なDHCPクライアントとの対話について議論するので、[RFC3118]でDHCPLEASEQUERYドメインに説明された操作を転移させるのが必要です。 操作は[RFC3118]で説明しました。
Woundy & Kinnear Standards Track [Page 23] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[23ページ]。
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.
アクセス集中装置SHOULDは、DHCPサーバでDHCPLEASEQUERYメッセージの世代を最小にすることによって、潜在的サービス不能攻撃を最小にします。 特に、アクセス集中装置SHOULDは否定的キャッシュ(すなわち、キャッシュDHCPLEASEUNASSIGNED、DHCPLEASEACTIVE、およびDHCPLEASEQUERYメッセージへのDHCPLEASEUNKNOWN応答)とciaddr制限を使います(すなわち、付属広帯域アクセスネットワークの範囲の外にciaddrがあるDHCPLEASEQUERYメッセージを送らないでください)。 これらのメカニズムはアクセス集中装置をリブートイベントの後に正統の広帯域アクセスネットワーク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メッセージがSHOULDであるとサポートする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サーバを構成するのは適切であるかもしれません、その結果、それが一握りだけの中継エージェントから要求だけに応じるのを許容します。 これは、少しの本当のセキュリティも提供しませんが、様々な種類の世慣れていない攻撃を阻むために役に立つかもしれません。
8. IANA Considerations
8. IANA問題
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を見てください。 4つの新しいメッセージタイプがあります。(タイプは[RFC2132]からのメッセージタイプオプション(オプション53)の値です)。 DHCPLEASEQUERYのための値は10です、そして、DHCPLEASEUNASSIGNEDのための値は11です、そして、DHCPLEASEUNKNOWNのための値は12です、そして、DHCPLEASEACTIVEのための値は13です。 最終的に、新しいDHCPオプションが定義した2があります。 クライアント最後のトランザクション時間オプション--オプションコード91、および関連ipオプション--オプションコード92。
9. Acknowledgements
9. 承認
Jim Forster, Joe Ng, Guenter Roeck, and Mark Stapp contributed greatly to the initial creation of the DHCPLEASEQUERY message.
ジム・フォルスター、ジョー・ウン、ギュンターRoeck、およびマーク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
パトリックGuelatは、静的なIPアドレシングをサポートするためにいくつかの改良を勧めました。 トーマスNartenは改良のための多くの提案をしました。 事実上、うるさく求められたラスHousleyはセキュリティ能力を増強しました、そして、テッド・ハーディーは望まれない情報漏出を最小にする方法を勧めました。 そしてバートWijnenが、私たちが焦点をDHCPv4にはっきりさせるのを示した。
Woundy & Kinnear Standards Track [Page 24] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[24ページ]。
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.
DHCP MIBのものと私たちのアプローチを区別してください。 R。 DHCP MIBの作者のひとり歳のバール・ヒッブスは、事実上、DHCPLEASEQUERYとその取り組みを区別するために情報を提供しました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[RFC3046] パトリック、M.、「DHCP中継エージェント情報オプション」、RFC3046、2001年1月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3118] DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、2001年6月。
10.2. Informative References
10.2. 有益な参照
[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.bitに扱う」STD37、RFC826、1982年11月。
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985.
[RFC951] 耕地とW.とJ.ギルモア、「プロトコルを独力で進んでください」、RFC951、1985年9月。
[RFC1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993.
[RFC1542]Wimer、W.、「明確化と拡大、プロトコルを独力で進んでください、」、RFC1542、10月1993日
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997.
[RFC2132] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、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 http://www.scte.org/standards/ で利用可能なBaseline Privacy Interface Specification SCTE22-2 2002、インチ2002。
Woundy & Kinnear Standards Track [Page 25] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[25ページ]。
[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、「データ過剰ケーブルサービスは仕様を連結します」。 Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-050812", August 2005, available at http://www.cablemodem.com/.
[DHCPMIB] Hibbs, R., Waters, G., "Dynamic Host Configuration
Protocol (DHCP) Server MIB", Work in Progress, February
2004.
[DHCPMIB]ヒッブス(R.)は水を飲んで、G.、「Dynamic Host Configuration Protocol(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 http://www.scte.org/standards/ で利用可能なRadio Frequency Interface Specification SCTE22-1 2002、インチ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、「ケーブルネットワークを通したデジタル双方向のコミュニケーションのためのヨーロッパのCable Modemの仕様書」、バージョン1.0、1999年5月。
Authors' Addresses
作者のアドレス
Rich Woundy Comcast Cable 27 Industrial Ave. Chelmsford, MA 01824
金持ちWoundyコムキャストは27の産業Aveに電報を打ちます。 チェルムズフォード、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マサチューセッツAve Boxborough、MA 01719
Phone: (978) 936-0000 EMail: kkinnear@cisco.com
以下に電話をしてください。 (978) 936-0000 メールしてください: kkinnear@cisco.com
Woundy & Kinnear Standards Track [Page 26] RFC 4388 DHCP Leasequery February 2006
WoundyとキネアStandardsはDHCP Leasequery2006年2月にRFC4388を追跡します[26ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Woundy & Kinnear Standards Track [Page 27]
Woundyとキネア標準化過程[27ページ]
一覧
スポンサーリンク
