RFC1541 日本語訳
1541 Dynamic Host Configuration Protocol. R. Droms. October 1993. (Format: TXT=96950 bytes) (Obsoletes RFC1531) (Obsoleted by RFC2131) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Droms Request for Comments: 1541 Bucknell University Obsoletes: 1531 October 1993 Category: Standards Track
Dromsがコメントのために要求するワーキンググループR.をネットワークでつないでください: 1541年のBucknell大学は以下を時代遅れにします。 1531 1993年10月のカテゴリ: 標準化過程
Dynamic Host Configuration Protocol
Dynamic Host Configuration Protocol
Status of this memo
このメモの状態
This RFC 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" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはインターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior of BOOTP relay agents [7, 23], and DHCP participants can interoperate with BOOTP participants [9]. Due to some errors introduced into RFC 1531 in the editorial process, this memo is reissued as RFC 1541.
Dynamic Host Configuration Protocol(DHCP)はTCP/IPネットワークで設定情報をホストに渡すのにフレームワークを提供します。 DHCPはBootstrapプロトコル(BOOTP)[7]に基づいています、再利用できるネットワーク・アドレスと追加設定オプション[19]の自動配分の能力を加えて。 DHCPはBOOTP中継エージェント[7、23]の振舞いを得ます、そして、DHCP関係者はBOOTP関係者[9]と共に共同利用できます。 編集のプロセスでRFC1531に紹介されたいくつかの誤りのため、このメモはRFC1541として再発行されます。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Problem definition and issues . . . . . . . . . . . . . . . . 4
1.3 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Configuration parameters repository . . . . . . . . . . . . . 10
2.2 Dynamic allocation of network addresses . . . . . . . . . . . 11
3. The Client-Server Protocol . . . . . . . . . . . . . . . . . . 11
3.1 Client-server interaction - allocating a network address. . . 12
3.2 Client-server interaction - reusing a previously allocated
network address . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Interpretation and representation of time values. . . . . . . 19
3.4 Host parameters in DHCP . . . . . . . . . . . . . . . . . . . 19
3.5 Use of DHCP in clients with multiple interfaces . . . . . . . 20
3.6 When clients should use DHCP. . . . . . . . . . . . . . . . . 20
4. Specification of the DHCP client-server protocol . . . . . . . 21
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 1.1が関係づけた2は働いています。 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 問題定義と問題.41.3Requirements。 . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4用語. . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5Design目標。 . . . . . . . . . . . . . . . . . . . . . . . . 6 2. .102.2にSummary. . . . . . . . . . . . . . . . . . . . . . . 8 2.1Configurationパラメタ倉庫について議定書の中で述べてください。ネットワークのDynamic配分は.113を扱います。 Client-サーバプロトコル. . . . . . . . . . . . . . . . . . 11 3.1Client-サーバ相互作用--ネットワーク・アドレスを割り当てます。 . . 12 3.2クライアント/サーバ相互作用--時間的価値の以前に割り当てられたネットワーク・アドレス. . . . . . . . . . . . . . . . . . . . . . . 17 3.3Interpretationと表現を再利用します。 . . . . . . 19 3.4 .203.6人のWhenクライアントがそうするべきである複数のインタフェースをもっているクライアントのDHCPのDHCP.193.5UseのホストパラメタはDHCPを使用します。 . . . . . . . . . . . . . . . . 20 4. DHCPクライアント/サーバプロトコル. . . . . . . 21の仕様
Droms [Page 1] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[1ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 21 4.2 DHCP server administrative controls . . . . . . . . . . . . . 23 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 24 4.3.1 DHCPDISCOVER message. . . . . . . . . . . . . . . . . . . . 24 4.3.2 DHCPREQUEST message . . . . . . . . . . . . . . . . . . . . 27 4.3.3 DHCPDECLINE message . . . . . . . . . . . . . . . . . . . . 29 4.3.4 DHCPRELEASE message . . . . . . . . . . . . . . . . . . . . 29 4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 29 4.4.1 Initialization and allocation of network address. . . . . . 29 4.4.2 Initialization with known network address . . . . . . . . . 33 4.4.3 Initialization with a known DHCP server address . . . . . . 34 4.4.4 Reacquisition and expiration. . . . . . . . . . . . . . . . 34 4.4.5 DHCPRELEASE . . . . . . . . . . . . . . . . . . . . . . . . 35 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 35 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 37 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 38 A. Host Configuration Parameters . . . . . . . . . . . . . . . . 39
4.1 組み立てて、メッセージをDHCPに送ります。 . . . . . . . . . . . 21 4.2 DHCPサーバ運営管理コントロール. . . . . . . . . . . . . 23 4.3DHCPサーバの振舞い。 . . . . . . . . . . . . . . . . . . . . 24 4.3 .1DHCPDISCOVERメッセージ。 . . . . . . . . . . . . . . . . . . . 24 4.3 .2 DHCPREQUESTメッセージ.274.3.3DHCPDECLINEメッセージ.294.3.4DHCPRELEASEメッセージ. . . . . . . . . . . . . . . . . . . . 29 4.4DHCPクライアントの振舞い。 . . . . . . . . . . . . . . . . . . . . 29 4.4 .1 ネットワーク・アドレスの初期設定と配分。 . . . . . 29 4.4 知られているネットワーク・アドレスによる.2初期設定、.334.4、.3初期設定、知られているDHCPサーバアドレス. . . . . . 34 4.4.4Reacquisitionと満了で。 . . . . . . . . . . . . . . . 34 4.4 .5 DHCPRELEASE. . . . . . . . . . . . . . . . . . . . . . . . 35 5。 承認。 . . . . . . . . . . . . . . . . . . . . . . . 35 6. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 36 7。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 37 8. 作者の.38のアドレスA.ホスト設定パラメータ. . . . . . . . . . . . . . . . 39
List of Figures
数字のリスト
1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 10
3. Timeline diagram of messages exchanged between DHCP client and
servers when allocating a new network address. . . . . . . . . 15
4. Timeline diagram of messages exchanged between DHCP client and
servers when reusing a previously allocated network address. . 18
5. State-transition diagram for DHCP clients. . . . . . . . . . . 31
1. DHCPメッセージ. . . . . . . . . . . . . . . . . . . 9 2の形式。 '旗'分野の形式。 . . . . . . . . . . . . . . . . . 10 3. 新しいネットワーク・アドレスを割り当てるときDHCPクライアントとサーバの間で交換されたメッセージのスケジュールダイヤグラム。 . . . . . . . . 15 4. 以前に割り当てられたネットワーク・アドレスを再利用するときDHCPクライアントとサーバの間で交換されたメッセージのスケジュールダイヤグラム。 . 18 5. DHCPクライアントのための状態遷移ダイヤグラム。 . . . . . . . . . . 31
List of Tables
テーブルのリスト
1. Description of fields in a DHCP message. . . . . . . . . . . . 14 2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Fields and options used by DHCP servers. . . . . . . . . . . . 25 4. Fields and options used by DHCP clients. . . . . . . . . . . . 32
1. DHCPメッセージにおける、分野の記述。 . . . . . . . . . . . 14 2. DHCPメッセージ。 . . . . . . . . . . . . . . . . . . . . . . . . 16 3. DHCPサーバによって使用される分野とオプション。 . . . . . . . . . . . 25 4. DHCPクライアントによって使用された分野とオプション。 . . . . . . . . . . . 32
1. Introduction
1. 序論
The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts.
Dynamic Host Configuration Protocol(DHCP)は設定パラメータをインターネット・ホストに提供します。 DHCPは2つのコンポーネントから成ります: DHCPサーバからホストとネットワーク・アドレスの配分のためのメカニズムからホストまでホスト特有の設定パラメータを提供するためのプロトコル。
DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. Throughout the remainder of this document, the term "server" refers to a host providing initialization
DHCPはクライアント・サーバモデルの上に造られます。そこでは、指定されたDHCPサーバー・ホストは、ダイナミックに構成されたホストに、ネットワーク・アドレスを割り当てて、設定パラメータを提供します。 このドキュメントの残り中では、「サーバ」という用語は初期化を提供するホストについて言及します。
Droms [Page 2] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[2ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
parameters through DHCP, and the term "client" refers to a host requesting initialization parameters from a DHCP server.
DHCPを通したパラメタ、および「クライアント」がDHCPサーバから初期化パラメタを要求するホストを示す用語。
A host should not act as a DHCP server unless explicitly configured to do so by a system administrator. The diversity of hardware and protocol implementations in the Internet would preclude reliable operation if random hosts were allowed to respond to DHCP requests. For example, IP requires the setting of many parameters within the protocol implementation software. Because IP can be used on many dissimilar kinds of network hardware, values for those parameters cannot be guessed or assumed to have correct defaults. Also, distributed address allocation schemes depend on a polling/defense mechanism for discovery of addresses that are already in use. IP hosts may not always be able to defend their network addresses, so that such a distributed address allocation scheme cannot be guaranteed to avoid allocation of duplicate network addresses.
システム管理者でそうするために明らかに構成されない場合、ホストはDHCPサーバとして務めるべきではありません。 無作為のホストがDHCP要求に応じることができるなら、インターネットのハードウェアとプロトコル実装の多様性は信頼できる操作を排除するでしょうに。 例えば、IPはプロトコル実装ソフトウェアの中の多くのパラメタの設定を必要とします。 多くの異なった種類のネットワークハードウェアの上でIPを使用できるので、正しいデフォルトを持っているとそれらのパラメタのための値を推測できないか、思うことができません。 また、分配されたアドレス配分体系は既に使用中のアドレスの発見のために世論調査/防衛機構によります。 IPホストはいつも彼らのネットワーク・アドレスを防御できるかもしれないというわけではありません、写しネットワーク・アドレスの配分を避けるためにそのような分配されたアドレス配分体系を保証できないように。
DHCP supports three mechanisms for IP address allocation. In "automatic allocation", DHCP assigns a permanent IP address to a host. In "dynamic allocation", DHCP assigns an IP address to a host for a limited period of time (or until the host explicitly relinquishes the address). In "manual allocation", a host's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the host. A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.
DHCPはIPアドレス配分のために3つのメカニズムをサポートします。 「自動配分」では、DHCPは永久的なIPアドレスをホストに割り当てます。 「動的割当て」で、DHCPは時間の限定期間の間、IPアドレスをホストに割り当てます(ホストが明らかにアドレスを放棄するまで)。 「手動の配分」では、ホストのIPアドレスはネットワーク管理者によって割り当てられます、そして、DHCPは、単に割り当てられたアドレスをホストに伝えるのに使用されます。 ネットワーク管理者の方針によって、特定のネットワークはこれらのメカニズムの1つ以上を使用するでしょう。
Dynamic allocation is the only one of the three mechanisms that allows automatic reuse of an address that is no longer needed by the host to which it was assigned. Thus, dynamic allocation is particularly useful for assigning an address to a host that will be connected to the network only temporarily or for sharing a limited pool of IP addresses among a group of hosts that do not need permanent IP addresses. Dynamic allocation may also be a good choice for assigning an IP address to a new host being permanently connected to a network where IP addresses are sufficiently scarce that it is important to reclaim them when old hosts are retired. Manual allocation allows DHCP to be used to eliminate the error-prone process of manually configuring hosts with IP addresses in environments where (for whatever reasons) it is desirable to manage IP address assignment outside of the DHCP mechanisms.
動的割当てはもうそれが割り当てられたホストによって必要とされないアドレスの自動再利用を許す3つのメカニズムの唯一無二です。 したがって、動的割当ては特に一時だけネットワークに接続されるホストにアドレスを割り当てるか、または永久的なIPアドレスを必要としないホストのグループでIPアドレスの限られたプールを共有することの役に立ちます。 また、動的割当ては、年取ったホストが退職しているとき、それらを開墾するために重要な状態で永久にIPアドレスが十分不十分であるネットワークに接続される新しいホストへのそれがそうであるIPアドレスを割り当てるための良い選択であるかもしれません。 手動の配分は、(いかなる理由によるも)それがDHCPメカニズムの外でIPアドレス課題を管理するのにおいて望ましいところにDHCPが環境におけるIPアドレスで手動でホストを構成する誤り傾向があるプロセスを排除するのに使用されるのを許容します。
The format of DHCP messages is based on the format of BOOTP messages, to capture the BOOTP relay agent behavior described as part of the BOOTP specification [7, 23] and to allow interoperability of existing BOOTP clients with DHCP servers. Using BOOTP relaying agents eliminates the necessity of having a DHCP server on each physical network segment.
DHCPメッセージの形式は、BOOTPがBOOTP仕様[7、23]の一部として記述された中継エージェントの振舞いであることを得て、DHCPサーバで既存のBOOTPクライアントの相互運用性を許容するためにBOOTPメッセージの形式に基づいています。 エージェントをリレーするBOOTPを使用すると、それぞれの物理ネットワークセグメントにDHCPサーバを持っているという必要性は排除されます。
Droms [Page 3] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[3ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
1.1 Related Work
1.1 関連仕事
There are several Internet protocols and related mechanisms that address some parts of the dynamic host configuration problem. The Reverse Address Resolution Protocol (RARP) [10] (through the extensions defined in the Dynamic RARP (DRARP) [5]) explicitly addresses the problem of network address discovery, and includes an automatic IP address assignment mechanism. The Trivial File Transfer Protocol (TFTP) [20] provides for transport of a boot image from a boot server. The Internet Control Message Protocol (ICMP) [16] provides for informing hosts of additional routers via "ICMP redirect" messages. ICMP also can provide subnet mask information through the "ICMP mask request" message and other information through the (obsolete) "ICMP information request" message. Hosts can locate routers through the ICMP router discovery mechanism [8].
ダイナミックなホスト設定問題のいくつかの部分を扱ういくつかのインターネットプロトコルと関連するメカニズムがあります。 逆アドレス解決プロトコル(RARP)[10]、(Dynamic RARP(DRARP)で定義された拡大で、[5])は明らかにネットワーク・アドレス発見のその問題を訴えて、自動IPアドレス割当機構を含んでいます。 トリビアル・ファイル転送プロトコル(TFTP)[20]はブート・サーバーからブーツイメージの輸送に備えます。インターネット・コントロール・メッセージ・プロトコル(ICMP)[16]は追加ルータについて「ICMP再直接」のメッセージでホストに知らせるのに提供されます。 ICMPも(時代遅れ)の「ICMP情報要求」メッセージを通して「ICMPマスク要求」メッセージと他の情報を通してサブネットマスク情報を提供できます。 ホストはICMPルータ発見メカニズム[8]を通してルータの場所を見つけることができます。
BOOTP is a transport mechanism for a collection of configuration information. BOOTP is also extensible, and official extensions [17] have been defined for several configuration parameters. Morgan has proposed extensions to BOOTP for dynamic IP address assignment [15]. The Network Information Protocol (NIP), used by the Athena project at MIT, is a distributed mechanism for dynamic IP address assignment [19]. The Resource Location Protocol RLP [1] provides for location of higher level services. Sun Microsystems diskless workstations use a boot procedure that employs RARP, TFTP and an RPC mechanism called "bootparams" to deliver configuration information and operating system code to diskless hosts. (Sun Microsystems, Sun Workstation and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun networks also use DRARP and an auto-installation mechanism to automate the configuration of new hosts in an existing network.
BOOTPは設定情報の収集のための移送機構です。 また、BOOTPも広げることができます、そして、公式の拡大[17]はいくつかの設定パラメータのために定義されました。 モーガンは動的IPアドレス課題[15]のためにBOOTPに拡大を提案しました。 MITでアティナプロジェクトによって使用されたNetwork情報プロトコル(NIP)は動的IPアドレス課題[19]のための分配されたメカニズムです。 Resource LocationプロトコルRLP[1]は、より高く平らなサービスの位置に備えます。 サン・マイクロシステムズのディスクレスワークステーションはそれが設定情報とオペレーティングシステムコードを提供するのにRARP、TFTP、および"bootparams"と呼ばれるRPCメカニズムを使うブート手順をディスクレス・ホストに使用します。 (サン・マイクロシステムズ、サンワークステーション、およびSunOSはサン・マイクロシステムズ・インクの商標です) Sunネットワークの中にはまた、既存のネットワークにおける、新しいホストの構成を自動化するのにDRARPと自動インストールメカニズムを使用するものもあります。
In other related work, the path minimum transmission unit (MTU) discovery algorithm can determine the MTU of an arbitrary internet path [14]. Comer and Droms have proposed the use of the Address Resolution Protocol (ARP) as a transport protocol for resource location and selection [6]. Finally, the Host Requirements RFCs [3, 4] mention specific requirements for host reconfiguration and suggest a scenario for initial configuration of diskless hosts.
他の関連する仕事では、経路の最小のトランスミッション単位(MTU)発見アルゴリズムは任意のインターネット経路[14]のMTUを決定できます。 新来者とDromsはリソース位置と選択[6]のためのトランスポート・プロトコルとしてAddress Resolutionプロトコル(ARP)の使用を提案しました。 最終的に、Host Requirements RFCs[3、4]はホスト再構成のために決められた一定の要求について言及して、ディスクレス・ホストの初期の構成のためにシナリオを勧めます。
1.2 Problem definition and issues
1.2 問題定義と問題
DHCP is designed to supply hosts with the configuration parameters defined in the Host Requirements RFCs. After obtaining parameters via DHCP, a host should be able to exchange packets with any other host in the Internet. The parameters supplied by DHCP are listed in Appendix A.
DHCPは、Host Requirements RFCsで定義された設定パラメータをホストに提供するように設計されています。 DHCPを通してパラメタを得た後に、ホストはインターネットでいかなる他のホストともパケットを交換できるべきです。 DHCPによって提供されたパラメタはAppendix Aにリストアップされています。
Droms [Page 4] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[4ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
Not all of these parameters are required for a newly initialized host. A client and server may negotiate for the transmission of only those parameters required by the client or specific to a particular subnet.
これらのパラメタのすべてが新たに初期化しているホストに必要であるというわけではありません。 クライアントとサーバは特定のサブネットにクライアントか特定によって必要とされたそれらのパラメタだけの伝達を交渉するかもしれません。
DHCP allows but does not require the configuration of host parameters not directly related to the IP protocol. DHCP also does not address registration of newly configured hosts with the Domain Name System (DNS) [12, 13].
許容しますが、DHCPは直接IPプロトコルに関連しないホストパラメタの構成を必要としません。 DHCPもドメインネームシステム(DNS)[12、13]との新たに構成されたホストの登録を扱いません。
DHCP is not intended for use in configuring routers.
DHCPはルータを構成することにおける使用のために意図しません。
1.3 Requirements
1.3 要件
Throughout this document, the words that are used to define the significance of particular requirements are capitalized. These words are:
このドキュメント中では、特定の要件の意味を定義するのに使用される単語は大文字で書かれます。 これらの単語は以下の通りです。
o "MUST"
o "MUST"
This word or the adjective "REQUIRED" means that the
item is an absolute requirement of this specification.
「必要である」というこの単語か形容詞が、項目がこの仕様に関する絶対条件であることを意味します。
o "MUST NOT"
o 「必須NOT」
This phrase means that the item is an absolute prohibition
of this specification.
この句は、項目がこの仕様の絶対禁止であることを意味します。
o "SHOULD"
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to ignore
this item, but the full implications should be understood and
the case carefully weighed before choosing a different course.
この単語か形容詞がこの項目を無視する特定の事情の正当な理由を存在するかもしれない手段に「推薦しました」が、完全な含意は、理解されていて異なったコースを選ぶ前に慎重に熟慮されたケースであるべきです。
o "SHOULD NOT"
o 「」であるべきです
This phrase means that there may exist valid reasons in
particular circumstances when the listed behavior is acceptable
or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior
described with this label.
この句は、このラベルで説明されたどんな振舞いも実装する前にいつ記載された振舞いが許容できるか、または役に立ちさえしますが、完全な含意が理解されるべきであるか、そして、この件が慎重に熟慮した特定の事情の正当な理由が存在するかもしれないことを意味します。
Droms [Page 5] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[5ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
o "MAY"
o 「5月」
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the
same item.
「任意である」というこの単語か形容詞が、本当に、この項目が任意であることを意味します。 特定の市場がそれを必要とするか、または例えば製品を高めるので、1つのベンダーが、項目を含んでいるのを選ぶかもしれません。 別のベンダーは同じ項目を省略するかもしれません。
1.4 Terminology
1.4 用語
This document uses the following terms:
このドキュメントは次の用語を使用します:
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 server"
o 「DHCPサーバ」
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
DHCPサーバはDHCPクライアントに設定パラメータを返すインターネット・ホストです。
o "BOOTP relay agent"
o 「BOOTP中継エージェント」
A BOOTP relay agent is an Internet host or router that passes
DHCP messages between DHCP clients and DHCP servers. DHCP is
designed to use the same relay agent behavior as specified in
the BOOTP protocol specification.
BOOTP中継エージェントはインターネット・ホストであるかDHCPクライアントの間でメッセージをDHCPに通過するルータとDHCPはサーバです。 DHCPは、BOOTPプロトコル仕様に基づく指定されるのと同じ中継エージェントの振舞いを使用するように設計されています。
o "binding"
o 「付きます」。
A binding is a collection of configuration parameters, including
at least an IP address, associated with or "bound to" a DHCP
client. Bindings are managed by DHCP servers.
結合はDHCPクライアントが少なくともIPアドレスを含んでいて、交際するか、または「縛られた」設定パラメータの収集です。 結合はDHCPサーバによって管理されます。
1.5 Design goals
1.5 デザイン目標
The following list gives general design goals for DHCP.
以下のリストはDHCPの一般的なデザイン目標を与えます。
o DHCP should be a mechanism rather than a policy. DHCP must
allow local system administrators control over configuration
parameters where desired; e.g., local system administrators
should be able to enforce local policies concerning allocation
and access to local resources where desired.
o DHCPは方針よりむしろメカニズムであるべきです。 DHCPは必要であるところで設定パラメータのローカルシステム管理者コントロールを許さなければなりません。 例えば、ローカルシステム管理者は必要であるところで配分とローカル資源へのアクセスに関してローカルの方針を実施できるべきです。
Droms [Page 6] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[6ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
o Hosts should require no manual configuration. Each host should
be able to discover appropriate local configuration parameters
without user intervention and incorporate those parameters into
its own configuration.
o ホストはどんな手動の構成も必要とするべきではありません。 それぞれのホストは、ユーザ介入なしで適切なローカルの設定パラメータを発見して、それらのパラメタをそれ自身の構成に組み入れることができるべきです。
o Networks should require no hand configuration for individual
hosts. Under normal circumstances, the network manager should
not have to enter any per-host configuration parameters.
o ネットワークは個々のホストのために手の構成を全く必要とするべきではありません。 通常の状況下で、ネットワークマネージャはどんな1ホストあたりの設定パラメータにも入るはずである必要はありません。
o DHCP should not require a server on each subnet. To allow for
scale and economy, DHCP must work across routers or through the
intervention of BOOTP/DHCP relay agents.
o DHCPは各サブネットでサーバを必要とするはずがありません。 スケールと経済を考慮するために、DHCPはルータの向こう側に、または、BOOTP/DHCP中継エージェントの介入を通して働かなければなりません。
o A DHCP host must be prepared to receive multiple responses to a
request for configuration parameters. Some installations may
include multiple, overlapping DHCP servers to enhance
reliability and increase performance.
o DHCPホストは設定パラメータに関する要求への複数の応答を受ける用意ができていなければなりません。 いくつかのインストールが、信頼性を高めて、性能を増強するために複数の、そして、重なっているDHCPサーバを含むかもしれません。
o DHCP must coexist with statically configured, non-participating
hosts and with existing network protocol implementations.
o DHCPは静的に構成されて、非参加しているホストと既存のネットワーク・プロトコル実装に共存しなければなりません。
o DHCP must interoperate with the BOOTP relay agent behavior as
described by RFC 951 and by Wimer [21].
o RFC951とWimer[21]によって説明されるようにDHCPはBOOTP中継エージェントの振舞いで共同利用しなければなりません。
o DHCP must provide service to existing BOOTP clients.
o DHCPは既存のBOOTPクライアントに対するサービスを提供しなければなりません。
The following list gives design goals specific to the transmission of the network layer parameters. DHCP must:
以下のリストはネットワーク層パラメタの伝達に特定にデザイン目標を与えます。 DHCPはそうしなければなりません:
o Guarantee that any specific network address will not be in
use by more than one host at a time,
o どんな特定のネットワーク・アドレスも一度に1人以上のホストで使用中にならないのを保証してください。
o Retain host configuration across host reboot. A host should,
whenever possible, be assigned the same configuration parameters
(e.g., network address) in response to each request,
o ホストリブートの向こう側にホスト構成を保有してください。 割り当てられた同じくらいが各要求に対応した設定パラメータ(例えば、ネットワーク・アドレス)であったときに、可能であるときはいつも、ホストはそうするべきです。
o Retain host configuration across server reboots, and, whenever
possible, a host should be assigned the same configuration
parameters despite restarts of the DHCP mechanism,
o 可能であるときはいつも、ホストにサーバリブートの向こう側にホスト構成を保有してください。そうすれば、DHCPメカニズムの再開にもかかわらず、同じ設定パラメータは割り当てられるべきです。
o Allow automatic assignment of configuration parameters to new
hosts to avoid hand configuration for new hosts,
o 新しいホストへの設定パラメータの自動課題に新しいホストのために手の構成を避けさせてください。
o Support fixed or permanent allocation of configuration
parameters to specific hosts.
o 設定パラメータの修理されたか永久的な配分を特定のホストにサポートしてください。
Droms [Page 7] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[7ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
2. Protocol Summary
2. プロトコル概要
From the client's point of view, DHCP is an extension of the BOOTP mechanism. This behavior allows existing BOOTP clients to interoperate with DHCP servers without requiring any change to the clients' initialization software. A separate document details the interactions between BOOTP and DHCP clients and servers [9]. There are some new, optional transactions that optimize the interaction between DHCP clients and servers that are described in sections 3 and 4.
クライアントの観点から、DHCPはBOOTPメカニズムの拡大です。 この振舞いで、クライアントの初期化ソフトウェアへの変化を必要としないで、既存のBOOTPクライアントはDHCPサーバで共同利用できます。 別々のドキュメントはBOOTPと、DHCPクライアントとサーバ[9]との相互作用を詳しく述べます。 DHCPクライアントの間の相互作用を最適化するいくつかの新しくて、任意のトランザクションとセクション3と4で説明されるサーバがあります。
Figure 1 gives the format of a DHCP message and table 1 describes each of the fields in the DHCP message. The numbers in parentheses indicate the size of each field in octets. The names for the fields given in the figure will be used throughout this document to refer to the fields in DHCP messages.
図1はDHCPメッセージの書式を与えます、そして、テーブル1はDHCPメッセージのそれぞれの分野について説明します。 括弧の数は八重奏における、それぞれの分野のサイズを示します。 図で与えられた野原への名前は、DHCPメッセージの野原について言及するのにこのドキュメント中で使用されるでしょう。
There are two primary differences between DHCP and BOOTP. First, DHCP defines mechanisms through which clients can be assigned a network address for a fixed lease, allowing for serial reassignment of network addresses to different clients. Second, DHCP provides the mechanism for a client to acquire all of the IP configuration parameters that it needs in order to operate.
DHCPとBOOTPの間には、2つのプライマリ違いがあります。 まず最初に、DHCPは固定リースのためのネットワーク・アドレスをクライアントに割り当てることができるメカニズムを定義します、異なったクライアントにとってネットワーク・アドレスの連続の再割当てを考慮して。 2番目に、クライアントがそれが作動するために必要とするIP設定パラメータのすべてを取得するように、DHCPはメカニズムを提供します。
DHCP introduces a small change in terminology intended to clarify the meaning of one of the fields. What was the "vendor extensions" field in BOOTP has been re-named the "options" field in DHCP. Similarly, the tagged data items that were used inside the BOOTP "vendor extensions" field, which were formerly referred to as "vendor extensions," are now termed simply "options."
DHCPは分野の1つの意味をはっきりさせることを意図する用語で小銭を導入します。 BOOTPの「ベンダー拡大」分野であったことはDHCPの「オプション」分野に改名されました。 同様に、以前「ベンダー拡大」と呼ばれたBOOTP「ベンダー拡大」野原の中で使用されたタグ付けをされたデータ項目は現在、単に「オプション」と呼ばれます。
DHCP defines a new 'client identifier' option that is used to pass an explicit client identifier to a DHCP server. This change eliminates the overloading of the 'chaddr' field in BOOTP messages, where 'chaddr' is used both as a hardware address for transmission of BOOTP reply messages and as a client identifier. The 'client identifier' option may contain a hardware address, identical to the contents of the 'chaddr' field, or it may contain another type of identifier, such as a DNS name. Other client identifier types may be defined as needed for use with DHCP. New client identifier types will be registered with the IANA [18] and will be included in new revisions of the Assigned Numbers document, as well as described in detail in future revisions of the DHCP Options [2].
DHCPは明白なクライアント識別子をDHCPサーバに通過するのに使用される新しい'クライアント識別子'オプションを定義します。この変化はBOOTPメッセージにおける、'chaddr'分野の積みすぎを排除します。(そこでは、'chaddr'がBOOTP応答メッセージの伝達のためのハードウェア・アドレスとしてクライアント識別子として使用されます)。 'クライアント識別子'オプションはハードウェア・アドレスを含むかもしれません、'chaddr'分野のコンテンツと同じであるか、または別のタイプに関する識別子を含むかもしれません、DNS名のように。 他のクライアント識別子タイプはDHCPとの使用のために必要に応じて定義されるかもしれません。 新しいクライアント識別子タイプは、IANA[18]に示されて、Assigned民数記ドキュメントの新しい改正に含まれていて、DHCP Options[2]の今後の改正で詳細に説明されるでしょう。
Droms [Page 8] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[8ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op (1) | htype (1) | hlen (1) | hops (1) | +---------------+---------------+---------------+---------------+ | xid (4) | +-------------------------------+-------------------------------+ | secs (2) | flags (2) | +-------------------------------+-------------------------------+ | ciaddr (4) | +---------------------------------------------------------------+ | yiaddr (4) | +---------------------------------------------------------------+ | siaddr (4) | +---------------------------------------------------------------+ | giaddr (4) | +---------------------------------------------------------------+ | | | chaddr (16) | | | | | +---------------------------------------------------------------+ | | | sname (64) | +---------------------------------------------------------------+ | | | file (128) | +---------------------------------------------------------------+ | | | options (312) | +---------------------------------------------------------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプアート(1)| htype(1)| hlen(1)| ホップ(1)| +---------------+---------------+---------------+---------------+ | xid(4)| +-------------------------------+-------------------------------+ | secs(2)| 旗(2)| +-------------------------------+-------------------------------+ | ciaddr(4)| +---------------------------------------------------------------+ | yiaddr(4)| +---------------------------------------------------------------+ | siaddr(4)| +---------------------------------------------------------------+ | giaddr(4)| +---------------------------------------------------------------+ | | | chaddr(16)| | | | | +---------------------------------------------------------------+ | | | sname(64)| +---------------------------------------------------------------+ | | | ファイル(128)| +---------------------------------------------------------------+ | | | オプション(312)| +---------------------------------------------------------------+
Figure 1: Format of a DHCP message
図1: DHCPメッセージの形式
DHCP clarifies the interpretation of the 'siaddr' field as the address of the server to use in the next step of the client's bootstrap process. A DHCP server may return its own address in the 'siaddr' field, if the server is prepared to supply the next bootstrap service (e.g., delivery of an operating system executable image). A DHCP server always returns its own address in the 'server identifier' option.
クライアントのものの次のステップで使用するサーバのアドレスがプロセスを独力で進むとき、DHCPは'siaddr'分野の解釈をはっきりさせます。 DHCPサーバは'siaddr'分野でそれ自身のアドレスを返すかもしれなくて、サーバが次を供給するように準備されるなら、サービス(例えば、オペレーティングシステムの実行可能なイメージの配送)を独力で進んでください。 DHCPサーバはいつも'サーバ識別子'オプションにおけるそれ自身のアドレスを返します。
The options field is now variable length, with the minimum extended to 312 octets. This brings the minimum size of a DHCP message up to 576 octets, the minimum IP datagram size a host must be prepared to accept [3]. DHCP clients may negotiate the use of larger DHCP messages through the 'Maximum DHCP message size' option. The options field may be further extended into the 'file' and 'sname' fields.
オプション分野は最小限が312の八重奏まで広げられている現在可変な長さです。 これは576の八重奏、最小のIPデータグラムサイズへのホストが[3]を受け入れる用意ができていなければならないというDHCPメッセージの最小規模をもたらします。 DHCPクライアントは、より大きいDHCPメッセージの'最大のDHCPメッセージサイズ'オプションによる使用を交渉するかもしれません。 オプション分野はさらに'ファイル'と'sname'分野に広げられるかもしれません。
Droms [Page 9] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[9ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
A new option, called 'vendor specific information', has been added to allow for expansion of the number of options that can be supported [2]. Options encapsulated as 'vendor specific information' must be carefully defined and documented so as to allow for interoperability between clients and servers from diferent vendors. In particular, vendors defining 'vendor specific information' MUST document those options in the form of the DHCP Options document, MUST choose to represent those options either in data types already defined for DHCP options or in other well-defined data types, and MUST choose options that can be readily encoded in configuration files for exchange with servers provided by other vendors. Options included as 'vendor specific options' MUST be readily supportable by all servers.
'ベンダー特殊情報'と呼ばれる新しいオプションは、[2]であることをサポートできるオプションの数の拡張を考慮するために加えられます。 オプションは、diferentベンダーからクライアントとサーバの間の相互運用性を考慮するために'ベンダー特殊情報'を慎重に定義されて、記録しなければならないので、要約されました。 'ベンダー特殊情報'を定義するベンダーは、特に、DHCP Optionsドキュメントの形にそれらのオプションを記録しなければならなくて、DHCPオプションのために既に定義されたデータ型か他の明確なデータ型におけるそれらのオプションを表すのを選ばなければならなくて、サーバが他のベンダーによって提供されている状態で交換のための構成ファイルで容易にコード化できるオプションを選ばなければなりません。 'ベンダーの特定のオプション'としてオプションを含んでいるのはすべてのサーバで容易に我慢できなければなりません。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B| MBZ |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5++++++++++++++++B| MBZ| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST flag
B: BROADCAST旗
MBZ: MUST BE ZERO (reserved for future use)
MBZ: ゼロでなければなりません。(今後の使用のために、予約されます)
Figure 2: Format of the 'flags' field
図2: '旗'分野の形式
DHCP uses the 'flags' field [21]. The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents. Figure 2 gives the format of the 'flags' field.
DHCPは'旗'分野[21]を使用します。 一番左ビットはBROADCAST(B)旗と定義されます。 このドキュメントのセクション4.1でこの旗の意味論について議論します。 旗の分野の残っているビットは今後の使用のために予約されます。 それらをクライアントによってゼロに設定されて、サーバと中継エージェントは無視しなければなりません。 図2は'旗'分野の書式を与えます。
2.1 Configuration parameters repository
2.1 構成パラメタ倉庫
The first service provided by DHCP is to provide persistent storage of network parameters for network clients. The model of DHCP persistent storage is that the DHCP service stores a key-value entry for each client, where the key is some unique identifier (for example, an IP subnet number and a unique identifier within the subnet) and the value contains the configuration parameters for the client.
DHCPによって提供されたファーストサービスは回路パラメータの永続的なストレージをネットワーククライアントに提供することです。 DHCPの永続的なストレージのモデルはDHCPサービスが各クライアントのためのキー値エントリーを保存するということです。(そこでは、キーが何らかのユニークな識別子(例えば、IPサブネット番号とサブネットの中のユニークな識別子)であり、値はクライアントへの設定パラメータを保管しています)。
For example, the key might be the pair (IP-subnet-number, hardware- address), allowing for serial or concurrent reuse of a hardware address on different subnets, and for hardware addresses that may not be globally unique. Alternately, the key might be the pair (IP- subnet-number, hostname), allowing the server to assign parameters intelligently to a host that has been moved to a different subnet or
例えば、キーは組であるかもしれません(IPサブネット番号、ハードウェアアドレス)、異なったサブネット、およびグローバルにユニークでないかもしれないハードウェア・アドレスのためのハードウェア・アドレスの連続の、または、同時発生の再利用を考慮して。 または交互に、キーは組であるかもしれません(IPサブネット番号、ホスト名)、サーバが知的に異なったサブネットに動かされたホストにパラメタを割り当てるのを許容して。
Droms [Page 10] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[10ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
has changed hardware addresses (perhaps because the network interface failed and was replaced).
ハードウェア・アドレス(恐らく、ネットワーク・インターフェースは失敗して、取り替えたので)を変えました。
A client can query the DHCP service to retrieve its configuration parameters. The client interface to the configuration parameters repository consists of protocol messages to request configuration parameters and responses from the server carrying the configuration parameters.
クライアントは、設定パラメータを検索するためにDHCPサービスについて質問できます。 設定パラメータ倉庫へのクライアントインタフェースは設定パラメータを運ぶサーバから設定パラメータと応答を要求するプロトコルメッセージから成ります。
2.2 Dynamic allocation of network addresses
ネットワーク・アドレスの2.2動的割当て
The second service provided by DHCP is the allocation of temporary or permanent network (IP) addresses to hosts. The basic mechanism for the dynamic allocation of network addresses is simple: a client requests the use of an address for some period of time. The allocation mechanism (the collection of DHCP servers) guarantees not to reallocate that address within the requested time and attempts to return the same network address each time the client requests an address. In this document, the period over which a network address is allocated to a client is referred to as a "lease" [11]. The client may extend its lease with subsequent requests. The client may issue a message to release the address back to the server when the client no longer needs the address. The client may ask for a permanent assignment by asking for an infinite lease. Even when assigning "permanent" addresses, a server may choose to give out lengthy but non-infinite leases to allow detection of the fact that the host has been retired.
DHCPによって提供されたセカンドサービスはホストへの一時的であるか永久的なネットワーク(IP)アドレスの配分です。 ネットワーク・アドレスの動的割当てのための基本的機構は簡単です: クライアントはアドレスのいつかの期間の使用を要求します。 配分メカニズム(DHCPサーバの収集)は、要求された時中にアドレスをそれに再割当てして、各回同じネットワーク・アドレスにクライアント要求を返す試みにアドレスは再割当てしないのを保証します。 本書では、ネットワーク・アドレスがクライアントに割り当てられる期間は「リース」[11]と呼ばれます。 クライアントはその後の要求でリースを広げるかもしれません。 クライアントがもうアドレスを必要としないと、クライアントはアドレスをサーバにリリースして戻すメッセージを発行するかもしれません。 クライアントは、無限のリースを求めることによって、永久的な課題を求めるかもしれません。 「永久的な」アドレスを割り当てるときさえ、サーバは、ホストが退職しているという事実の検出を許すために長い、しかし、非無限のリースを配るのを選ぶかもしれません。
In some environments it will be necessary to reassign network addresses due to exhaustion of available addresses. In such environments, the allocation mechanism will reuse addresses whose lease has expired. The server should use whatever information is available in the configuration information repository to choose an address to reuse. For example, the server may choose the least recently assigned address. As a consistency check, the allocation mechanism may probe the reused address, e.g., with an ICMP echo request, before allocating the address, and the client will probe the newly received address, e.g., with ARP.
いくつかの環境で、利用可能なアドレスの疲労困憊のためネットワーク・アドレスを再選任するのが必要でしょう。 そのような環境で、配分メカニズムはリースが期限が切れたアドレスを再利用するでしょう。 サーバは、再利用するアドレスを選ぶのに設定情報倉庫でどんな利用可能な情報も使用するべきです。 例えば、アドレスが最近割り当てられる場合、サーバは最も最少に選ばれるかもしれません。 一貫性チェックとして、配分メカニズムは再利用されたアドレスを調べるかもしれません、例えば、ICMPエコー要求で、アドレスを割り当てる前に、そして、クライアントが新たに受け取られたアドレスを調べるでしょう、例えば、ARPと共に。
3. The Client-Server Protocol
3. クライアント/サーバプロトコル
DHCP uses the BOOTP message format defined in RFC 951 and given in table 1 and figure 1. The 'op' field of each DHCP message sent from a client to a server contains BOOTREQUEST. BOOTREPLY is used in the 'op' field of each DHCP message sent from a server to a client.
DHCPはRFC951で定義されて、テーブル1と図1で与えられたBOOTPメッセージ・フォーマットを使用します。 発信して、サーバへのクライアントがBOOTREQUEST. BOOTREPLYを含むというそれぞれのDHCPメッセージの'オプアート'分野はサーバからクライアントに送られたそれぞれのDHCPメッセージの'オプアート'分野で使用されます。
The first four octets of the 'options' field of the DHCP message contain the (decimal) values 99, 130, 83 and 99, respectively (this
DHCPメッセージの'オプション'分野の最初の4つの八重奏がそれぞれ(10進)の値99、130、83、および99を含んでいる、(これ
Droms [Page 11] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[11ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
is the same magic cookie as is defined in RFC 1497). The remainder of the 'options' field consists a list of tagged parameters that are called "options". All of the "vendor extensions" listed in RFC 1497 are also DHCP options. A separate document gives the complete set of options defined for use with DHCP [2].
RFCで定義される同じ魔法のクッキーは1497ですか?) 'オプション'分野の残りは成ります。「オプション」と呼ばれるタグ付けをされたパラメタのリスト。 また、RFC1497に記載された「ベンダー拡大」のすべてがDHCPオプションです。 別々のドキュメントは使用のためにDHCP[2]で定義された完全なオプションを与えます。
Several options have been defined so far. One particular option - the "DHCP message type" option - must be included in every DHCP message. This option defines the "type" of the DHCP message. Additional options may be allowed, required, or not allowed, depending on the DHCP message type.
いくつかのオプションが今までのところ、定義されました。 あらゆるDHCPメッセージに1つの特定のオプション(「DHCPメッセージタイプ」オプション)を含まなければなりません。 このオプションはDHCPメッセージの「タイプ」を定義します。 DHCPメッセージタイプに頼っていて、追加オプションは、許容されていないか、必要でない、許容できません。
Throughout this document, DHCP messages that include a 'DHCP message type' option will be referred to by the type of the message; e.g., a DHCP message with 'DHCP message type' option type 1 will be referred to as a "DHCPDISCOVER" message.
このドキュメント中では、'DHCPメッセージタイプ'オプションを含んでいるDHCPメッセージがメッセージのタイプによって示されるでしょう。 例えば'DHCPメッセージタイプ'オプションタイプ1があるDHCPメッセージは"DHCPDISCOVER"メッセージと呼ばれるでしょう。
3.1 Client-server interaction - allocating a network address
3.1 Client-server interaction - allocating a network address
The following summary of the protocol exchanges between clients and servers refers to the DHCP messages described in table 2. The timeline diagram in figure 3 shows the timing relationships in a typical client-server interaction. If the client already knows its address, some steps may be omitted; this abbreviated interaction is described in section 3.2.
The following summary of the protocol exchanges between clients and servers refers to the DHCP messages described in table 2. The timeline diagram in figure 3 shows the timing relationships in a typical client-server interaction. If the client already knows its address, some steps may be omitted; this abbreviated interaction is described in section 3.2.
1. The client broadcasts a DHCPDISCOVER message on its local physical
subnet. The DHCPDISCOVER message may include options that suggest
values for the network address and lease duration. BOOTP relay
agents may pass the message on to DHCP servers not on the same
physical subnet.
1. The client broadcasts a DHCPDISCOVER message on its local physical subnet. The DHCPDISCOVER message may include options that suggest values for the network address and lease duration. BOOTP relay agents may pass the message on to DHCP servers not on the same physical subnet.
2. Each server may respond with a DHCPOFFER message that includes an
available network address in the 'yiaddr' field (and other
configuration parameters in DHCP options). Servers need not
reserve the offered network address, although the protocol will
work more efficiently if the server avoids allocating the offered
network address to another client. The server unicasts the
DHCPOFFER message to the client (using the DHCP/BOOTP relay agent
if necessary) if possible, or may broadcast the message to a
broadcast address (preferably 255.255.255.255) on the client's
subnet.
2. Each server may respond with a DHCPOFFER message that includes an available network address in the 'yiaddr' field (and other configuration parameters in DHCP options). Servers need not reserve the offered network address, although the protocol will work more efficiently if the server avoids allocating the offered network address to another client. The server unicasts the DHCPOFFER message to the client (using the DHCP/BOOTP relay agent if necessary) if possible, or may broadcast the message to a broadcast address (preferably 255.255.255.255) on the client's subnet.
3. The client receives one or more DHCPOFFER messages from one or
more servers. The client may choose to wait for multiple
responses. The client chooses one server from which to request
configuration parameters, based on the configuration parameters
offered in the DHCPOFFER messages. The client broadcasts a
3. The client receives one or more DHCPOFFER messages from one or more servers. The client may choose to wait for multiple responses. The client chooses one server from which to request configuration parameters, based on the configuration parameters offered in the DHCPOFFER messages. The client broadcasts a
Droms [Page 12] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms [Page 12] RFC 1541 Dynamic Host Configuration Protocol October 1993
DHCPREQUEST message that MUST include the 'server identifier'
option to indicate which server it has selected, and may include
other options specifying desired configuration values. This
DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP
relay agents. To help ensure that any DHCP/BOOTP relay agents
forward the DHCPREQUEST message to the same set of DHCP servers
that received the original DHCPDISCOVER message, the DHCPREQUEST
message must use the same value in the DHCP message header's
'secs' field and be sent to the same IP broadcast address as the
original DHCPDISCOVER message. The client times out and
retransmits the DHCPDISCOVER message if the client receives no
DHCPOFFER messages.
DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected, and may include other options specifying desired configuration values. This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents. To help ensure that any DHCP/BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message must use the same value in the DHCP message header's 'secs' field and be sent to the same IP broadcast address as the original DHCPDISCOVER message. The client times out and retransmits the DHCPDISCOVER message if the client receives no DHCPOFFER messages.
4. The servers receive the DHCPREQUEST broadcast from the client.
Those servers not selected by the DHCPREQUEST message use the
message as notification that the client has declined that server's
offer. The server selected in the DHCPREQUEST message commits the
binding for the client to persistent storage and responds with a
DHCPACK message containing the configuration parameters for the
requesting client. The combination of 'chaddr' and assigned
network address constitute an unique identifier for the client's
lease and are used by both the client and server to identify a
lease referred to in any DHCP messages. The 'yiaddr' field in the
DHCPACK messages is filled in with the selected network address.
4. The servers receive the DHCPREQUEST broadcast from the client. Those servers not selected by the DHCPREQUEST message use the message as notification that the client has declined that server's offer. The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client. The combination of 'chaddr' and assigned network address constitute an unique identifier for the client's lease and are used by both the client and server to identify a lease referred to in any DHCP messages. The 'yiaddr' field in the DHCPACK messages is filled in with the selected network address.
If the selected server is unable to satisfy the DHCPREQUEST message
(e.g., the requested network address has been allocated), the
server SHOULD respond with a DHCPNAK message.
If the selected server is unable to satisfy the DHCPREQUEST message (e.g., the requested network address has been allocated), the server SHOULD respond with a DHCPNAK message.
A server may choose to mark addresses offered to clients in
DHCPOFFER messages as unavailable. The server should mark an
address offered to a client in a DHCPOFFER message as available if
the server receives no DHCPREQUEST message from that client.
A server may choose to mark addresses offered to clients in DHCPOFFER messages as unavailable. The server should mark an address offered to a client in a DHCPOFFER message as available if the server receives no DHCPREQUEST message from that client.
Droms [Page 13] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms [Page 13] RFC 1541 Dynamic Host Configuration Protocol October 1993
FIELD OCTETS DESCRIPTION ----- ------ -----------
FIELD OCTETS DESCRIPTION ----- ------ -----------
op 1 Message op code / message type.
1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Hardware address type, see ARP section in "Assigned
Numbers" RFC; e.g., '1' = 10mb ethernet.
hlen 1 Hardware address length (e.g. '6' for 10mb
ethernet).
hops 1 Client sets to zero, optionally used by relay-agents
when booting via a relay-agent.
xid 4 Transaction ID, a random number chosen by the
client, used by the client and server to associate
messages and responses between a client and a
server.
secs 2 Filled in by client, seconds elapsed since client
started trying to boot.
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; filled in by client in
DHCPREQUEST if verifying previously allocated
configuration parameters.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK and DHCPNAK by
server.
giaddr 4 Relay agent IP address, used in booting via a
relay-agent.
chaddr 16 Client hardware address.
sname 64 Optional server host name, null terminated string.
file 128 Boot file name, null terminated string; "generic"
name or null in DHCPDISCOVER, fully qualified
directory-path name in DHCPOFFER.
options 312 Optional parameters field. See the options
documents for a list of defined options.
op 1 Message op code / message type. 1 = BOOTREQUEST, 2 = BOOTREPLY htype 1 Hardware address type, see ARP section in "Assigned Numbers" RFC; e.g., '1' = 10mb ethernet. hlen 1 Hardware address length (e.g. '6' for 10mb ethernet). hops 1 Client sets to zero, optionally used by relay-agents when booting via a relay-agent. xid 4 Transaction ID, a random number chosen by the client, used by the client and server to associate messages and responses between a client and a server. secs 2 Filled in by client, seconds elapsed since client started trying to boot. flags 2 Flags (see figure 2). ciaddr 4 Client IP address; filled in by client in DHCPREQUEST if verifying previously allocated configuration parameters. yiaddr 4 'your' (client) IP address. siaddr 4 IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK and DHCPNAK by server. giaddr 4 Relay agent IP address, used in booting via a relay-agent. chaddr 16 Client hardware address. sname 64 Optional server host name, null terminated string. file 128 Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER. options 312 Optional parameters field. See the options documents for a list of defined options.
Table 1: Description of fields in a DHCP message
Table 1: Description of fields in a DHCP message
Droms [Page 14] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms [Page 14] RFC 1541 Dynamic Host Configuration Protocol October 1993
Server Client Server
(not selected) (selected)
Server Client Server (not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\_____________ |
|/ DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/|
| \_________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\_____________ |
|/ DHCPREQUEST | DHCPREQUEST \|
| | |
| | Commits configuration
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\_____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
v v v | | | | Begins initialization | | | | | _____________/|\_____________ | |/ DHCPDISCOVER | DHCPDISCOVER \| | | | Determines | Determines configuration | configuration | | | |\ | ____________/| | \_________ | /DHCPOFFER | | DHCPOFFER\ |/ | | \ | | | Collects replies | | \| | | Selects configuration | | | | | _____________/|\_____________ | |/ DHCPREQUEST | DHCPREQUEST \| | | | | | Commits configuration | | | | | _____________/| | |/ DHCPACK | | | | | Initialization complete | | | | . . . . . . | | | | Graceful shutdown | | | | | |\_____________ | | | DHCPRELEASE \| | | | | | Discards lease | | | v v v
Figure 3: Timeline diagram of messages exchanged between DHCP
client and servers when allocating a new network address
Figure 3: Timeline diagram of messages exchanged between DHCP client and servers when allocating a new network address
Droms [Page 15] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms [Page 15] RFC 1541 Dynamic Host Configuration Protocol October 1993
Message Use ------- ---
Message Use ------- ---
DHCPDISCOVER - Client broadcast to locate available servers.
DHCPDISCOVER - Client broadcast to locate available servers.
DHCPOFFER - Server to client in response to DHCPDISCOVER with
offer of configuration parameters.
DHCPOFFER - Server to client in response to DHCPDISCOVER with offer of configuration parameters.
DHCPREQUEST - Client broadcast to servers requesting offered
parameters from one server and implicitly declining
offers from all others.
DHCPREQUEST - Client broadcast to servers requesting offered parameters from one server and implicitly declining offers from all others.
DHCPACK - Server to client with configuration parameters,
including committed network address.
DHCPACK - Server to client with configuration parameters, including committed network address.
DHCPNAK - Server to client refusing request for configuration
parameters (e.g., requested network address already
allocated).
DHCPNAK - Server to client refusing request for configuration parameters (e.g., requested network address already allocated).
DHCPDECLINE - Client to server indicating configuration parameters
(e.g., network address) invalid.
DHCPDECLINE - Client to server indicating configuration parameters (e.g., network address) invalid.
DHCPRELEASE - Client to server relinquishing network address and
cancelling remaining lease.
DHCPRELEASE - Client to server relinquishing network address and cancelling remaining lease.
Table 2: DHCP messages
Table 2: DHCP messages
5. The client receives the DHCPACK message with configuration
parameters. The client performs a final check on the parameters
(e.g., ARP for allocated network address), and notes the duration
of the lease and the lease identification cookie specified in the
DHCPACK message. At this point, the client is configured. If the
client detects a problem with the parameters in the DHCPACK
message, the client sends a DHCPDECLINE message to the server and
restarts the configuration process. The client should wait a
minimum of ten seconds before restarting the configuration process
to avoid excessive network traffic in case of looping.
5. The client receives the DHCPACK message with configuration parameters. The client performs a final check on the parameters (e.g., ARP for allocated network address), and notes the duration of the lease and the lease identification cookie specified in the DHCPACK message. At this point, the client is configured. If the client detects a problem with the parameters in the DHCPACK message, the client sends a DHCPDECLINE message to the server and restarts the configuration process. The client should wait a minimum of ten seconds before restarting the configuration process to avoid excessive network traffic in case of looping.
If the client receives a DHCPNAK message, the client restarts the
configuration process.
If the client receives a DHCPNAK message, the client restarts the configuration process.
The client times out and retransmits the DHCPREQUEST message if the
client receives neither a DHCPACK or a DHCPNAK message. The client
retransmits the DHCPREQUEST according to the retransmission
algorithm in section 4.1. If the client receives neither a DHCPACK
or a DHCPNAK message after ten retransmissions of the DHCPREQUEST
message, the client reverts to INIT state and restarts the
initialization process. The client SHOULD notify the user that the
The client times out and retransmits the DHCPREQUEST message if the client receives neither a DHCPACK or a DHCPNAK message. The client retransmits the DHCPREQUEST according to the retransmission algorithm in section 4.1. If the client receives neither a DHCPACK or a DHCPNAK message after ten retransmissions of the DHCPREQUEST message, the client reverts to INIT state and restarts the initialization process. The client SHOULD notify the user that the
Droms [Page 16] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms [Page 16] RFC 1541 Dynamic Host Configuration Protocol October 1993
initialization process has failed and is restarting.
initialization process has failed and is restarting.
6. The client may choose to relinquish its lease on a network address
by sending a DHCPRELEASE message to the server. The client
identifies the lease to be released by including its network
address in the 'ciaddr' field and its hardware address in the
'chaddr' field.
6. The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server. The client identifies the lease to be released by including its network address in the 'ciaddr' field and its hardware address in the 'chaddr' field.
3.2 Client-server interaction - reusing a previously allocated network
address
3.2 Client-server interaction - reusing a previously allocated network address
If a client remembers and wishes to reuse a previously allocated network address (allocated either by DHCP or some means outside the protocol), a client may choose to omit some of the steps described in the previous section. The timeline diagram in figure 4 shows the timing relationships in a typical client-server interaction for a client reusing a previously allocated network address.
If a client remembers and wishes to reuse a previously allocated network address (allocated either by DHCP or some means outside the protocol), a client may choose to omit some of the steps described in the previous section. The timeline diagram in figure 4 shows the timing relationships in a typical client-server interaction for a client reusing a previously allocated network address.
1. The client broadcasts a DHCPREQUEST message on its local subnet.
The DHCPREQUEST message includes the client's network address in
the 'ciaddr' field. DHCP/BOOTP relay agents pass the message on
to DHCP servers not on the same subnet.
1. The client broadcasts a DHCPREQUEST message on its local subnet. The DHCPREQUEST message includes the client's network address in the 'ciaddr' field. DHCP/BOOTP relay agents pass the message on to DHCP servers not on the same subnet.
2. Servers with knowledge of the client's configuration parameters
respond with a DHCPACK message to the client.
2. Servers with knowledge of the client's configuration parameters respond with a DHCPACK message to the client.
If the client's request is invalid (e.g., the client has moved
to a new subnet), servers may respond with a DHCPNAK message to
the client.
If the client's request is invalid (e.g., the client has moved to a new subnet), servers may respond with a DHCPNAK message to the client.
3. The client receives the DHCPACK message with configuration
prameters. The client performs a final check on the parameters
(as in section 3.1), and notes the duration of the lease and
the lease identification cookie specified in the DHCPACK
message. At this point, the client is configured.
3. The client receives the DHCPACK message with configuration prameters. The client performs a final check on the parameters (as in section 3.1), and notes the duration of the lease and the lease identification cookie specified in the DHCPACK message. At this point, the client is configured.
If the client detects a problem with the parameters in the
DHCPACK message, the client sends a DHCPDECLINE message to the
server and restarts the configuration process by requesting a
new network address. This action corresponds to the client
moving to the INIT state in the DHCP state diagram, which is
described in section 4.4.
If the client detects a problem with the parameters in the DHCPACK message, the client sends a DHCPDECLINE message to the server and restarts the configuration process by requesting a new network address. This action corresponds to the client moving to the INIT state in the DHCP state diagram, which is described in section 4.4.
Droms [Page 17] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms [Page 17] RFC 1541 Dynamic Host Configuration Protocol October 1993
Server Client Server
Server Client Server
v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| ___________/ | \___________ |
| /DHCPREQUEST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \_______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v v
v v v | | | | Begins | | initialization | | | | | /|\ | | ___________/ | \___________ | | /DHCPREQUEST | DHCPREQUEST\ | |/ | \| | | | Locates | Locates configuration | configuration | | | |\ | /| | \ | ___________/ | | \ | / DHCPACK | | \_______ |/ | | DHCPACK\ | | | Initialization | | complete | | \| | | | | | (Subsequent | | DHCPACKS | | ignored) | | | | | | | v v v
Figure 4: Timeline diagram of messages exchanged between DHCP
client and servers when reusing a previously allocated
network address
図4: 以前に割り当てられたネットワーク・アドレスを再利用するときDHCPクライアントとサーバの間で交換されたメッセージのスケジュールダイヤグラム
If the client receives a DHCPNAK message, it cannot reuse its
remembered network address. It must instead request a new
address by restarting the configuration process, this time
using the (non-abbreviated) procedure described in section
3.1. This action also corresponds to the client moving to
the INIT state in the DHCP state diagram.
クライアントがDHCPNAKメッセージを受け取るなら、それは覚えていられたネットワーク・アドレスを再利用できません。 それは、代わりにコンフィギュレーションプロセス(セクション3.1で説明された(非簡略化される)の手順を用いる今回)を再開することによって、新しいアドレスを要求しなければなりません。 また、この動作はDHCP州のダイヤグラムによるINIT状態に移行するクライアントに文通されます。
The client times out and retransmits the DHCPREQUEST message if
the client receives neither a DHCPACK nor a DHCPNAK message.
The time between retransmission MUST be chosen according to
the algorithm given in section 4.1. If the client receives no
answer after transmitting 4 DHCPREQUEST messages, the client
MAY choose to use the previously allocated network address and
そして、クライアント回、外、クライアントがDHCPACKもDHCPNAKメッセージも受け取らないなら、DHCPREQUESTメッセージを再送します。 セクション4.1で与えられたアルゴリズムによると、「再-トランスミッション」の間の時間を選ばなければなりません。 そして4つのDHCPREQUESTメッセージを送った後にクライアントが答えを全く受けないなら、クライアントが、以前に割り当てられたネットワーク・アドレスを使用するのを選ぶかもしれない。
Droms [Page 18] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[18ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
configuration parameters for the remainder of the unexpired
lease. This corresponds to moving to BOUND state in the client
state transition diagram shown in figure 5.
満期になっていないリースの残りのための設定パラメータ。 これは5が中で計算するのが示された属国変遷ダイヤグラムによるBOUND状態に移行すると対応しています。
4. The client may choose to relinquish its lease on a network
address by sending a DHCPRELEASE message to the server. The
client identifies the lease to be released with the lease
identification cookie.
4. クライアントは、ネットワーク・アドレスでDHCPRELEASEメッセージをサーバに送ることによってリースを放棄するのを選ぶかもしれません。クライアントは、リース識別クッキーでリリースされるためにリースを特定します。
Note that in this case, where the client retains its network
address locally, the client will not normally relinquish its
lease during a graceful shutdown. Only in the case where the
client explicitly needs to relinquish its lease, e.g., the client
is about to be moved to a different subnet, will the client send
a DHCPRELEASE message.
この場合通常、クライアントが局所的にネットワーク・アドレスを保有するところに、クライアントが優雅な閉鎖の間リースを放棄しないことに注意してください。 場合だけでは、クライアントが、明らかにリースを放棄する必要があって、例えば、クライアントが異なったサブネットに動かされようとしているところに、クライアントはDHCPRELEASEメッセージを送るでしょう。
3.3 Interpretation and representation of time values
3.3 時間的価値の解釈と表現
A client acquires a lease for a network address for a fixed period of time (which may be infinite). Throughout the protocol, times are to be represented in units of seconds. The time value of 0xffffffff is reserved to represent "infinity". The minimum lease duration is one hour.
クライアントは一定期間(無限であるかもしれない)ネットワーク・アドレスのためのリースを取得します。 プロトコル中では、回はユニットの秒に表されることになっています。 0xffffffffの時間的価値は、「無限」を表すために予約されます。 最小のリース持続時間は1時間です。
As clients and servers may not have synchronized clocks, times are represented in DHCP messages as relative times, to be interpreted with respect to the client's local clock. Representing relative times in units of seconds in an unsigned 32 bit word gives a range of relative times from 0 to approximately 100 years, which is sufficient for the relative times to be measured using DHCP.
クライアントとサーバが時計を連動させていないとき、回は、クライアントの地方の時計に関して解釈されるために相対的な時勢としてDHCPメッセージに表されます。 32ビットの未署名の単語によるユニットの秒に相対的な時勢を表すと、さまざまな相対的な0〜およそ100年までの回を与えます。(年は、DHCPを使用することで相対的な時勢を測定できます)。
The algorithm for lease duration interpretation given in the previous paragraph assumes that client and server clocks are stable relative to each other. If there is drift between the two clocks, the server may consider the lease expired before the client does. To compensate, the server may return a shorter lease duration to the client than the server commits to its local database of client information.
前のパラグラフでされたリース持続時間解釈のためのアルゴリズムはそのクライアントを仮定します、そして、サーバ時計は互いに比例して安定しています。 2個の時計の間には、ドリフトがあれば、サーバは、クライアントの前の満期のリースがすると考えるかもしれません。 代償するために、サーバはサーバがクライアント情報のローカルのデータベースに遂行するより短いリース持続時間をクライアントに返すかもしれません。
3.4 Host parameters in DHCP
3.4 DHCPのホストパラメタ
Not all clients require initialization of all parameters listed in Appendix A. Two techniques are used to reduce the number of parameters transmitted from the server to the client. First, most of the parameters have defaults defined in the Host Requirements RFCs; if the client receives no parameters from the server that override the defaults, a client uses those default values. Second, in its initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
すべてのクライアントがAppendix A.にリストアップされたすべてのパラメタの初期化を必要とするというわけではありません。Twoのテクニックは、サーバからクライアントまで伝えられたパラメタの数を減少させるのに使用されます。 まず最初に、パラメタの大部分には、Host Requirements RFCsで定義されたデフォルトがあります。 クライアントがサーバからのデフォルトをくつがえすパラメタを全く受け取らないなら、クライアントはそれらのデフォルト値を使用します。 2番目に、その初期のDHCPDISCOVERかDHCPREQUESTメッセージに、クライアントは供給するかもしれません。
Droms [Page 19] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[19ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
server with a list of specific parameters the client is interested in.
クライアントが興味を持っている特定のパラメタのリストがあるサーバ。
The client SHOULD include the 'maximum DHCP message size' option to let the server know how large the server may make its DHCP messages. The parameters returned to a client may still exceed the space allocated to options in a DHCP message. In this case, two additional options flags (which must appear in the 'options' field of the message) indicate that the 'file' and 'sname' fields are to be used for options.
クライアントSHOULDは'最大のDHCPメッセージサイズ'オプションを含んでいます。サーバに大きい状態でその方法を知らせるように、サーバはDHCPメッセージを作るかもしれません。 クライアントに返されたパラメタはまだDHCPメッセージにおけるオプションに割り当てられたスペースを超えているかもしれません。 この場合、その'ファイル'と'sname'がさばく旗(メッセージの'オプション'分野に現れなければならない)が、示す2つの追加オプションはオプションに使用されることです。
The client can inform the server which configuration parameters the client is interested in by including the 'parameter request list' option. The data portion of this option explicitly lists the options requested by tag number.
クライアントは、クライアントがどの設定パラメータに興味を持っているかをサーバに'パラメタ要求リスト'オプションを含んでいることによって、知らせることができます。 このオプションのデータ部は明らかにタグ番号によって要求されたオプションを記載します。
In addition, the client may suggest values for the network address and lease time in the DHCPDISCOVER message. The client may include the 'requested IP address' option to suggest that a particular IP address be assigned, and may include the 'IP address lease time' option to suggest the lease time it would like. No other options representing "hints" at configuration parameters are allowed in a DHCPDISCOVER or DHCPREQUEST message. The 'ciaddr' field is to be filled in only in a DHCPREQUEST message when the client is requesting use of a previously allocated IP address.
さらに、クライアントはDHCPDISCOVERメッセージでネットワーク・アドレスとリース時間の値を勧めるかもしれません。 クライアントは、特定のIPアドレスが割り当てられるのを示すために'要求されたIPアドレス'オプションを入れて、それが欲しいリース時間を示すために'IPアドレスリース時間'オプションを入れるかもしれません。 設定パラメータで「ヒント」を表す別の選択肢が全くDHCPDISCOVERかDHCPREQUESTメッセージに許容されていません。 'ciaddr'分野はクライアントが以前に割り当てられたIPアドレスの使用を要求しているとき、DHCPREQUESTメッセージだけが記入されることです。
If a server receives a DHCPREQUEST message with an invalid 'ciaddr', the server SHOULD respond to the client with a DHCPNAK message and may choose to report the problem to the system administrator. The server may include an error message in the 'message' option.
サーバが無効の'ciaddr'でDHCPREQUESTメッセージを受け取るなら、サーバSHOULDはDHCPNAKメッセージでクライアントにこたえます、そして、問題をシステム管理者に報告するのを選ぶかもしれません。 サーバは'メッセージ'オプションにエラーメッセージを含むかもしれません。
3.5 Use of DHCP in clients with multiple interfaces
3.5 複数のインタフェースをもっているクライアントにおけるDHCPの使用
A host with multiple network interfaces must use DHCP through each interface independently to obtain configuration information parameters for those separate interfaces.
複数のネットワーク・インターフェースをもっているホストは、それらの別々のインタフェースのための設定情報パラメタを得るのに各インタフェースを通して独自にDHCPを使用しなければなりません。
3.6 When clients should use DHCP
クライアントであるときに、3.6はDHCPを使用するべきです。
A host should use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network, as the local network configuration may change without the host's or user's knowledge.
企業内情報通信網パラメタが変化したかもしれないときはいつも、ホストは、reacquireにDHCPを使用するべきであるか、またはそのIPアドレスと回路パラメータについて確かめるべきです。 企業内情報通信網構成が変えるかもしれないように、例えば、システムブート時か企業内情報通信網からの断線の後に、ホストかユーザの知識なしで変化してください。
If a host has knowledge of a previous network address and is unable to contact a local DHCP server, the host may continue to use the previous network address until the lease for that address expires.
ホストが前のネットワーク・アドレスに関する知識を持って、ローカルのDHCPサーバに連絡できないなら、ホストは、そのアドレスのためのリースが期限が切れるまで前のネットワーク・アドレスを使用し続けるかもしれません。
Droms [Page 20] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[20ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
If the lease expires before the host can contact a DHCP server, the host must immediately discontinue use of the previous network address and may inform local users of the problem.
ホストがDHCPサーバに連絡できる前にリースが期限が切れるなら、ホストは、すぐに、前のネットワーク・アドレスの使用を中止しなければならなくて、問題について地元のユーザに知らせるかもしれません。
4. Specification of the DHCP client-server protocol
4. DHCPクライアント/サーバプロトコルの仕様
In this section, we assume that a DHCP server has a block of network addresses from which it can satisfy requests for new addresses. Each server also maintains a database of allocated addresses and leases in local permanent storage.
このセクションでは、私たちは、DHCPサーバにはそれが新しいアドレスを求める要望に応じることができる1ブロックのネットワーク・アドレスがあると思います。 また、各サーバは地方の永久記録媒体における割り当てられたアドレスとリースに関するデータベースを維持します。
4.1 Constructing and sending DHCP messages
4.1 構成とメッセージをDHCPに送ること。
DHCP clients and servers both construct DHCP messages by filling in fields in the fixed format section of the message and appending tagged data items in the variable length option area. The options area includes first a four-octet 'magic cookie' (which was described in section 3), followed by the options. The last option must always be the 'end' option.
DHCPクライアントとサーバは、メッセージの固定フォーマット部に分野に記入して、可変長オプション部門でタグ付けをされたデータ項目を追加することによって、ともにDHCPメッセージを構成します。 オプションがあとに続いていて、オプション部門は最初に、4八重奏の'魔法のクッキー'(セクション3で説明された)を含んでいます。 いつも最後のオプションは'終わり'オプションであるに違いありません。
DHCP uses UDP as its transport protocol. DHCP messages from a client to a server are sent to the 'DHCP server' port (67), and DHCP messages from a server to a client are sent to the 'DHCP client' port (68).
DHCPはトランスポート・プロトコルとしてUDPを使用します。 'DHCPサーバ'ポート(67)にクライアントからサーバまでのDHCPメッセージを送ります、そして、'DHCPクライアント'ポート(68)にサーバからクライアントまでのDHCPメッセージを送ります。
DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0.
IPアドレスを得るそのクライアントの前でクライアントによって放送されたDHCPメッセージで、IPヘッダーのソースアドレス分野は0にセットしなければなりません。
If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the DHCP relaying agent whose address appears in 'giaddr'. If the 'giaddr' field is zero, the client is on the same subnet, and the server sends any return messages to either the client's network address, if that address was supplied in the 'ciaddr' field, or to the client's hardware address or to the local subnet broadcast address.
クライアントからのDHCPメッセージの'giaddr'分野が非ゼロであるなら、サーバで、'DHCPサーバ'ポートへのDHCPに関するどんなリターンメッセージもアドレスが'giaddr'に現れるエージェントをリレーします。 'giaddr'分野がゼロであるなら、クライアントは同じサブネットにいます、そして、サーバはどんなリターンメッセージもクライアントのネットワーク・アドレスに送ります、クライアントのハードウェア・アドレス、または、'ciaddr'分野か、ローカルのサブネット放送演説にそのアドレスを供給したなら。
If the options in a DHCP message extend into the 'sname' and 'file' fields, the 'option overload' option MUST appear in the 'options' field, with value 1, 2 or 3, as specified in the DHCP options document [2]. If the 'option overload' option is present in the 'options' field, the options in the 'options' field MUST be terminated by an 'end' option, and MAY contain one or more 'pad' options to fill the options field. The options in the 'sname' and 'file' fields (if in use as indicated by the 'options overload' option) MUST begin with the first octet of the field, MUST be terminated by an 'end' option, and MUST be followed by 'pad' options
DHCPメッセージにおけるオプションが'sname'と'ファイル'分野に広がっているなら、'オプションオーバーロード'オプションは'オプション'分野に現れなければなりません、値1、2または3でオプションはDHCPで指定されるように[2]を記録します。 'オプションオーバーロード'オプションが'オプション'分野に存在しているなら、'オプション'分野でのオプションは、'終わり'オプションで終えなければならなくて、オプション分野をいっぱいにするために1つ以上の'パッド'オプションを含むかもしれません。 'sname'と'ファイル'分野('オプションオーバーロード'オプションで示される使用で)でのオプションを分野の最初の八重奏で始まらなければならなくて、'終わり'オプションで終えなければならなくて、'パッド'オプションはあとに続かなければなりません。
Droms [Page 21] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[21ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
to fill the remainder of the field. Any individual option in the 'options', 'sname' and 'file' fields MUST be entirely contained in that field. The options in the 'options' field MUST be interpreted first, so that any 'option overload' options may be interpreted. The 'file' field MUST be interpreted next (if the 'option overload' option indicates that the 'file' field contains DHCP options), followed by the 'sname' field.
分野の残りをいっぱいにするために。 その分野に'オプション'、'sname'、および'ファイル'分野でのどんな個人の選択も完全に保管しなければなりません。 最初に、どんな'オプションオーバーロード'オプションも解釈できるように'オプション'分野でのオプションを解釈しなければなりません。 次('オプションオーバーロード'オプションが、'ファイル'分野がDHCPオプションを含むのを示すなら)で、'sname'分野があとに続いた状態で、'ファイル'分野を解釈しなければなりません。
DHCP clients are responsible for all message retransmission. The client MUST adopt a retransmission strategy that incorporates a randomized exponential backoff algorithm to determine the delay between retransmissions. The delay before the first retransmission MUST be 4 seconds randomized by the value of a uniform random number chosen from the range -1 to +1. Clients with clocks that provide resolution granularity of less than one second may choose a non- integer randomization value. The delay before the next retransmission MUST be 8 seconds randomized by the value of a uniform number chosen from the range -1 to +1. The retransmission delay MUST be doubled with subsequent retransmissions up to a maximum of 64 seconds. The client MAY provide an indication of retransmission attempts to the user as an indication of the progress of the configuration process. The protocol specification in the remainder of this section will describe, for each DHCP message, when it is appropriate for the client to retransmit that message forever, and when it is appropriate for a client to abandon that message and attempt to use a different DHCP message.
DHCPクライアントはすべてのメッセージの再送に責任があります。 クライアントは「再-トランスミッション」の間の遅れを決定するためにランダマイズされた指数のbackoffアルゴリズムを取り入れる「再-トランスミッション」戦略を採用しなければなりません。 最初の「再-トランスミッション」の前の遅れは範囲-1から+1まで選ばれた一様乱数の値によってランダマイズされた4秒でなければなりません。 1秒未満の解決粒状を提供する時計をもっているクライアントは非整数の無作為化値を選ぶかもしれません。 次の「再-トランスミッション」の前の遅れは範囲-1から+1まで選ばれた背番号の値によってランダマイズされた8秒でなければなりません。 その後の「再-トランスミッション」で「再-トランスミッション」遅れを最大64秒まで倍にしなければなりません。 クライアントはコンフィギュレーションプロセスの進歩のしるしとして「再-トランスミッション」試みのしるしをユーザに供給するかもしれません。 このセクションの残りにおけるプロトコル仕様はそれぞれのDHCPメッセージのためにクライアントがいつまでもそのメッセージを再送するのが、いつ適切であるか、そして、クライアントが、そのメッセージを捨てて、異なったDHCPメッセージを使用するのを試みるのが、いつ適切であるかを説明するでしょう。
Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using unicast delivery. The IP destination address (in the IP header) is set to the DHCP 'yiaddr' address and the link-layer destination address is set to the DHCP 'chaddr' address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until the implementation has been configured with a valid IP address (leading to a deadlock in which the client's IP address cannot be delivered until the client has been configured with an IP address).
通常、DHCPサーバとBOOTP中継エージェントは、ユニキャスト配送を使用することで直接クライアントへのメッセージをDHCPOFFER、DHCPACK、およびDHCPNAKに提供するのを試みます。 受信者IPアドレス(IPヘッダーの)はDHCP'yiaddr'アドレスに設定されます、そして、リンクレイヤ送付先アドレスはDHCP'chaddr'アドレスに設定されます。 残念ながら、有効なIPアドレス(クライアントがIPアドレスによって構成されるまでクライアントのIPアドレスを提供できない行き詰まりに通じる)によって実装が構成されるまで、いくつかのクライアント実装はそのようなユニキャストIPデータグラムを受け取ることができません。
A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of the use of the BROADCAST bit [21].
プロトコル・ソフトウエアがIPアドレスSHOULDによって構成されるまでユニキャストIPデータグラムを受け取ることができないクライアントはクライアントが発信するというどんなDHCPDISCOVERやDHCPREQUESTメッセージでも1への'旗'分野にBROADCASTビットをはめ込みました。 BROADCASTビットは、クライアントのサブネットのクライアントにどんなメッセージも放送するためにDHCPサーバとBOOTP中継エージェントにヒントを提供するでしょう。 ユニキャストIPデータグラムをプロトコル・ソフトウエアの前に受け取ることができるクライアントはBROADCASTが0まで噛み付いたのが明確な構成されたSHOULDです。 明確化が記録するBOOTPはBROADCASTビット[21]の使用の分岐について議論します。
Droms [Page 22] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[22ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
A server or relay agent sending or relaying a DHCP message directly to a DHCP client (i.e., not to a relay agent specified in the 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags' field. If this bit is set to 1, the DHCP message SHOULD be sent as an IP broadcast using an IP broadcast address (preferably 255.255.255.255) as the IP destination address and the link-layer broadcast address as the link-layer destination address. If the BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP unicast to the IP address specified in the 'yiaddr' field and the link-layer address specified in the 'chaddr' field. If unicasting is not possible, the message MAY be sent as an IP broadcast using an IP broadcast address (preferably 255.255.255.255) as the IP destination address and the link-layer broadcast address as the link-layer destination address.
サーバ、中継エージェント送付または直接DHCPクライアント(すなわち、'giaddr'分野で中継エージェントに指定されない)に、SHOULDがBROADCASTビットを試験するというDHCPメッセージを'旗'がさばくリレーすること。 IPがIP放送演説を使用することで放送されたようにこのビットが1、DHCPメッセージにSHOULDを設定することであるなら送ってください。(望ましくは255.255に、IPの目的地としての.255が)扱う.255とリンクレイヤはリンクレイヤ送付先アドレスとしてアドレスを放送します。 ビットはBROADCASTであるなら0まできれいにされます、メッセージSHOULD。'yiaddr'分野で指定されたIPアドレスとリンクレイヤアドレスへのIPユニキャストが'chaddr'分野で指定したように、送ってください。 unicastingが可能でないなら、IP放送演説を使用するIP放送としてメッセージを送るかもしれません。(望ましくは255.255に、IPの目的地としての.255が)扱う.255とリンクレイヤはリンクレイヤ送付先アドレスとしてアドレスを放送します。
4.2 DHCP server administrative controls
4.2 DHCPサーバ運営管理コントロール
DHCP servers are not required to respond to every DHCPDISCOVER and DHCPREQUEST message they receive. For example, a network administrator, to retain stringent control over the hosts attached to the network, may choose to configure DHCP servers to respond only to hosts that have been previously registered through some external mechanism. The DHCP specification describes only the interactions between clients and servers when the clients and servers choose to interact; it is beyond the scope of the DHCP specification to describe all of the administrative controls that system administrators might want to use. Specific DHCP server implementations may incorporate any controls or policies desired by a network administrator.
DHCPサーバは、彼らが受け取るあらゆるDHCPDISCOVERとDHCPREQUESTメッセージに応じるのに必要ではありません。 例えば、ネットワーク管理者は、ネットワークに配属されるホストの上の緊縮調節を保有するために以前に何らかの外部のメカニズムを通して登録されたホストだけに応じるためにDHCPサーバを構成するのを選ぶかもしれません。 クライアントとサーバが、相互作用するのを選ぶと、DHCP仕様はクライアントとサーバとの相互作用だけについて説明します。 それは、システム管理者が使用したがっているかもしれない運営管理コントロールのすべてについて説明するためにDHCP仕様の範囲を超えています。 特定のDHCPサーバ実装はネットワーク管理者によって望まれていたどんなコントロールや方針も取り入れるかもしれません。
In some environments, a DHCP server will have to consider the values of the 'chaddr' field and/or the 'class-identifier' option included in the DHCPDISCOVER or DHCPREQUEST messages when determining the correct parameters for a particular client. For example, an organization might have a separate bootstrap server for each type of client it uses, requiring the DHCP server to examine the 'class- identifier' to determine which bootstrap server address to return in the 'siaddr' field of a DHCPOFFER or DHCPACK message.
いくつかの環境で、特定のクライアントのために正しいパラメタを決定するとき、DHCPサーバは、DHCPDISCOVERかDHCPREQUESTメッセージに'chaddr'分野、そして/または、'クラス識別子'オプションの値を含んでいると考えなければならないでしょう。 例えば、aが力で切り離す組織はそれが使用するクライアントの各タイプのためにサーバを独力で進みます、どれがDHCPOFFERかDHCPACKメッセージの'siaddr'分野で戻るためにサーバアドレスを独力で進むかを決定するために'クラス識別子'を調べるためにDHCPサーバを必要として。
A DHCP server must use some unique identifier to associate a client with its lease. The client may choose to explicitly provide the identifier through the 'client identifier' option. If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client.
DHCPサーバは、クライアントをリースに関連づけるのに何らかのユニークな識別子を使用しなければなりません。 クライアントは、'クライアント識別子'オプションで明らかに識別子を提供するのを選ぶかもしれません。 クライアントが'クライアント識別子'オプションを提供しないなら、サーバは、クライアントを特定するのに'chaddr'分野のコンテンツを使用しなければなりません。
DHCP clients are free to use any strategy in selecting a DHCP server among those from which the client receives a DHCPOFFER message. The client implementation of DHCP should provide a mechanism for the user
DHCPクライアントはクライアントがDHCPOFFERメッセージを受け取るそれらの中でDHCPサーバを選択する際に自由にどんな戦略も使用できます。 DHCPのクライアント実装はメカニズムをユーザに提供するべきです。
Droms [Page 23] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[23ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
to select directly the 'class-identifier' value.
直接'クラス識別子'値を選択するために。
4.3 DHCP server behavior
4.3 DHCPサーバの振舞い
A DHCP server processes incoming DHCP messages from a client based on the current state of the binding for that client. A DHCP server can receive the following messages from a client:
DHCPサーバはそのクライアントのために結合の現状に基づくクライアントから入って来るDHCPメッセージを処理します。 DHCPサーバはクライアントから以下のメッセージを受け取ることができます:
o DHCPDISCOVER
o DHCPDISCOVER
o DHCPREQUEST
o DHCPREQUEST
o DHCPDECLINE
o DHCPDECLINE
o DHCPRELEASE
o DHCPRELEASE
Table 3 gives the use of the fields and options in a DHCP message by a server. The remainder of this section describes the action of the DHCP server for each possible incoming message.
テーブル3はサーバでDHCPメッセージにおける分野とオプションの使用を与えます。このセクションの残りはそれぞれの可能な入力メッセージのためにDHCPサーバの動作について説明します。
4.3.1 DHCPDISCOVER message
4.3.1 DHCPDISCOVERメッセージ
When a server receives a DHCPDISCOVER message from a client, the server chooses a network address for the requesting client. If no address is available, the server may choose to report the problem to the system administrator and may choose to reply to the client with a DHCPNAK message. If the server chooses to respond to the client, it may include an error message in the 'message' option. If an address is available, the new address should be chosen as follows:
サーバがクライアントからDHCPDISCOVERメッセージを受け取るとき、サーバは要求しているクライアントのためのネットワーク・アドレスを選びます。 どんなアドレスも利用可能でないなら、サーバは、問題をシステム管理者に報告するのを選んで、DHCPNAKメッセージでクライアントに答えるのを選ぶかもしれません。 サーバが、クライアントに応じるのを選ぶなら、それは'メッセージ'オプションにエラーメッセージを含むかもしれません。 アドレスが利用可能であるなら、新しいアドレスは以下の通り選ばれるべきです:
o The client's previous address as recorded in the client's binding,
if that address is in the server's pool of available addresses and
not already allocated, else
o サーバの利用可能なアドレスのプールの中にそのアドレスがあるならクライアントが付くのに記録されて、既に割り当てられないでほかとしてのクライアントの旧住所
o The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, else
o そのアドレスが有効であるなら'要求されたIP Address'オプションで要求されて、ほかに既に割り当てられなかったアドレス
o A new address allocated from the server's pool of available
addresses.
o 新しいアドレスはサーバの利用可能のプールからアドレスを割り当てました。
Droms [Page 24] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[24ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
Field DHCPOFFER DHCPACK DHCPNAK ----- --------- ------- -------
分野DHCPOFFER DHCPACK DHCPNAK----- --------- ------- -------
'op' BOOTREPLY BOOTREPLY BOOTREPLY
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' 'xid' from client 'xid' from client 'xid' from client
DHCPDISCOVER DHCPREQUEST DHCPREQUEST
message message message
'secs' 0 0 0
'ciaddr' 0 'ciaddr' from 'ciaddr' from
DHCPREQUEST or 0 DHCPREQUEST or 0
'yiaddr' IP address offered IP address 0
to client assigned to client
'siaddr' IP address of next IP address of next 0
bootstrap server bootstrap server
'flags' if 'giaddr' is not 0 then 'flags' from client message else 0
'giaddr' 0 0 0
'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
client client DHCPREQUEST client DHCPREQUEST
DHCPDISCOVER message message
message
'sname' Server host name Server host name (unused)
or options or options
'file' Client boot file Client boot file (unused)
name or options name or options
'options' options options
'op' BOOTREPLY BOOTREPLY BOOTREPLY 'htype' (From "Assigned Numbers" RFC) 'hlen' (Hardware address length in octets) 'hops' 0 0 0 'xid' 'xid' from client 'xid' from client 'xid' from client DHCPDISCOVER DHCPREQUEST DHCPREQUEST message message message 'secs' 0 0 0 'ciaddr' 0 'ciaddr' from 'ciaddr' from DHCPREQUEST or 0 DHCPREQUEST or 0 'yiaddr' IP address offered IP address 0 to client assigned to client 'siaddr' IP address of next IP address of next 0 bootstrap server bootstrap server 'flags' if 'giaddr' is not 0 then 'flags' from client message else 0 'giaddr' 0 0 0 'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from client client DHCPREQUEST client DHCPREQUEST DHCPDISCOVER message message message 'sname' Server host name Server host name (unused) or options or options 'file' Client boot file Client boot file (unused) name or options name or options 'options' options options
Option DHCPOFFER DHCPACK DHCPNAK ------ --------- ------- -------
オプションDHCPOFFER DHCPACK DHCPNAK------ --------- ------- -------
Requested IP address MUST NOT MUST NOT MUST NOT IP address lease time MUST MUST MUST NOT Use 'file'/'sname' MAY MAY MUST NOT fields DHCP message type DHCPOFFER DHCPACK DHCPNAK Parameter request list MUST NOT MUST NOT MUST NOT Message SHOULD SHOULD SHOULD Client identifier MUST NOT MUST NOT MUST NOT Class identifier MUST NOT MUST NOT MUST NOT Server identifier MUST MAY MAY Maximum message size MUST NOT MUST NOT MUST NOT All others MAY MAY MUST NOT
IPアドレスがそうしなければならなくないよう要求する、NOTがそうしなければならない、時間がそうしなければならないIPアドレスリースがそうしなければならないNOTがそうしなければならない、Server識別子ではなく、識別子がそうしなければならなくないClassではなく、Message SHOULD SHOULD SHOULD Client識別子ではなく、リストがそうしなければならなくないDHCPOFFER DHCPACK DHCPNAK Parameter要求がそうしなければならなくないタイプがそうしなければならないDHCPメッセージがそうしなければならなくない分野ではなく、5月がそうしなければならない5月がそうしなければならなくない'sname'がそうしなければならない/がそうしなければならなくないUse'ファイル'がそうしなければならないNOTはAll他のものではなく、5月の5月のサイズがそうしなければならなくないMaximumメッセージがそうしなければならなくない5月がそうしなければならない5月にそうしなければなりません。
Table 3: Fields and options used by DHCP servers
テーブル3: DHCPサーバによって使用される分野とオプション
Droms [Page 25] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[25ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
As described in section 4.2, a server MAY, for administrative reasons, assign an address other than the one requested, or may refuse to allocate an address to a particular client even though free addresses are available.
セクション4.2で説明されるように、サーバは、管理理由で、要求されたものを除いて、アドレスを割り当てるか、または無料のアドレスが利用可能ですが、特定のクライアントにアドレスを割り当てるのを拒否するかもしれません。
While not required for correct operation of DHCP, the server should not reuse the selected network address before the client responds to the server's DHCPOFFER message. The server may choose to record the address as offered to the client.
DHCPの正しい操作に必要でない間、クライアントがサーバのDHCPOFFERメッセージに応じる前にサーバは選択されたネットワーク・アドレスを再利用するべきではありません。 サーバは、クライアントに提供するようにアドレスを記録するのを選ぶかもしれません。
The server must also choose an expiration time for the lease, as follows:
また、サーバは以下の通りリースのための満了時間を選ばなければなりません:
o IF the client has not requested a specific lease in the
DHCPDISCOVER message and the client already has an assigned network
address, the server returns the lease expiration time previously
assigned to that address (note that the client must explicitly
request a specific lease to extend the expiration time on a
previously assigned address), ELSE
o クライアントが、DHCPDISCOVERメッセージとクライアントの特定のリースには割り当てられたネットワーク・アドレスが既にあるよう要求していないなら、サーバは以前にそのアドレスに割り当てられたリース満了時間を返します(クライアントが以前に割り当てられたアドレスの満了時間を延ばすために明らかに特定のリースを要求しなければならないことに注意してください)、ELSE
o IF the client has not requested a specific lease in the
DHCPDISCOVER message and the client does not have an assigned
network address, the server assigns a locally configured default
lease time, ELSE
o クライアントが、DHCPDISCOVERメッセージとクライアントの特定のリースには割り当てられたネットワーク・アドレスがないよう要求していないなら、サーバは局所的に構成されたデフォルトリース時間を割り当てます、ELSE
o IF the client has requested a specific lease in the DHCPDISCOVER
message (regardless of whether the client has an assigned network
address), the server may choose either to return the requested
lease (if the lease is acceptable to local policy) or select
another lease.
o クライアントがDHCPDISCOVERメッセージ(クライアントに割り当てられたネットワーク・アドレスがあるかどうかにかかわらず)における特定のリースを要求したなら、サーバは、要求されたリース(リースがローカルの方針に許容できるなら)を返すか、または別のリースを選択するのを選ぶかもしれません。
Once the network address and lease have been determined, the server constructs a DHCPOFFER message with the offered configuration parameters. It is important for all DHCP servers to return the same parameters (with the possible exception of a newly allocated network address) to ensure predictable host behavior regardless of the which server the client selects. The configuration parameters MUST be selected by applying the following rules in the order given below. The network administrator is responsible for configuring multiple DHCP servers to ensure uniform responses from those servers. The server MUST return to the client:
ネットワーク・アドレスとリースがいったん決定するようになると、サーバは提供された設定パラメータでDHCPOFFERメッセージを構成します。 にかかわらず、すべてのDHCPサーバが予測できるホストの振舞いを確実にするために、同じパラメタ(新たに割り当てられたネットワーク・アドレスの可能な例外がある)を返すのが、重要である、クライアントがそれのサーバを選択する。 以下に与えられたオーダーにおける以下の規則を適用することによって、設定パラメータを選択しなければなりません。 ネットワーク管理者はそれらのサーバから一定の応答を確実にするために複数のDHCPサーバを構成するのに責任があります。 サーバはクライアントに戻らなければなりません:
Droms [Page 26] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[26ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
o The client's network address, as determined by the rules given
earlier in this section, and the subnet mask for the network to
which the client is connected,
o より早くこのセクションで与えられた規則、およびクライアントが関連しているネットワークのためのサブネットマスクはクライアントのネットワーク・アドレスで、断固としています。
o The expiration time for the client's lease, as determined by the
rules given earlier in this section,
o クライアントのリースのための、より早くこのセクションで与えられた規則で決定するような満了時間
o Parameters requested by the client, according to the following
rules:
o 以下の規則に従って、パラメタはクライアントから要求しました:
-- IF the server has been explicitly configured with a default
value for the parameter, the server MUST include that value
in an appropriate option in the 'option' field, ELSE
-- サーバがパラメタのためにデフォルト値によって明らかに構成されたなら、サーバは'オプション'分野での適切なオプションにその値を含まなければなりません、ELSE
-- IF the server recognizes the parameter as a parameter
defined in the Host Requirements Document, the server MUST
include the default value for that parameter as given in the
Host Requirements Document in an appropriate option in the
'option' field, ELSE
-- サーバが、パラメタがHost Requirements Documentで定義されたパラメタであると認めるなら、サーバはHost Requirements Documentで'オプション'分野での適切なオプションで与えるようにそのパラメタのためのデフォルト値を含まなければなりません、ELSE
-- The server MUST NOT return a value for that parameter,
-- サーバはそのパラメタのために値を返してはいけません。
o Any parameters from the existing binding that differ from the Host
Requirements documents defaults,
o それを縛る存在からのどんなパラメタもHost Requirementsドキュメントデフォルトと異なっています。
o Any parameters specific to this client (as identified by
the contents of 'chaddr' in the DHCPDISCOVER or DHCPREQUEST
message), e.g., as configured by the network administrator,
o ネットワーク管理者による例えば、このクライアント(DHCPDISCOVERかDHCPREQUESTメッセージで'chaddr'のコンテンツによって特定されるように)、構成にされるとして特定のどんなパラメタ
o Any parameters specific to this client's class (as identified
by the contents of the 'class identifier' option in the
DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by
the network administrator; the parameters MUST be identified
by an exact match between the client's 'client class' and the
client class identified in the server,
o ネットワーク管理者によるこのクライアントのクラス(DHCPDISCOVERかDHCPREQUESTメッセージにおける'クラス識別子'オプションのコンテンツによって特定されるように)、構成される例えば、として特定のどんなパラメタも。 クライアントの'クライアントのクラス'とサーバで特定されたクライアントのクラスとの完全な一致でパラメタを特定しなければなりません。
o Parameters with non-default values on the client's subnet.
o 非デフォルト値がクライアントのサブネットにあるパラメタ。
The server inserts the 'xid' field from the DHCPDISCOVER message into the 'xid' field of the DHCPOFFER message and sends the DHCPOFFER message to the requesting client.
サーバは、'xid'野原をDHCPDISCOVERメッセージからDHCPOFFERメッセージの'xid'分野に挿入して、DHCPOFFERメッセージを要求しているクライアントに送ります。
4.3.2 DHCPREQUEST message
4.3.2 DHCPREQUESTメッセージ
A DHCPREQUEST message may come from a client responding to a DHCPOFFER message from a server, or from a client verifying a previously allocated IP address. If the DHCPREQUEST message contains a 'server identifier' option, the message is in response to a
DHCPREQUESTメッセージはサーバからDHCPOFFERメッセージに応じているクライアント、または、以前に割り当てられたIPアドレスについて確かめるクライアントから来るかもしれません。 DHCPREQUESTメッセージが'サーバ識別子'オプションを含んでいるなら、メッセージはaに対応しています。
Droms [Page 27] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[27ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
DHCPOFFER message. Otherwise, the message is a request to renew or extend an existing lease.
DHCPOFFERメッセージ。 さもなければ、メッセージは既存のリースを更新するか、または広げるという要求です。
Consider first the case of a DHCPREQUEST message in response to a DHCPOFFER message. If the server is identified in the 'server identifier' option in the DHCPREQUEST message, the server checks to confirm that the requested parameters are acceptable. Usually, the requested parameters will match those returned to the client in the DHCPOFFER message; however, the client may choose to request a different lease duration. Also, there is no requirement that the server cache the parameters from the DHCPOFFER message. The server must simply check that the parameters requested in the DHCPREQUEST are acceptable. If the parameters are acceptable, the server records the new client binding and returns a DHCPACK message to the client.
DHCPOFFERメッセージに対応して1番目がDHCPREQUESTメッセージに関するケースであると考えてください。 サーバがDHCPREQUESTメッセージにおける'サーバ識別子'オプションで特定されるなら、サーバは、要求されたパラメタが許容できると確認するためにチェックします。 通常、要求されたパラメタはDHCPOFFERメッセージでクライアントに返されたものに合うでしょう。 しかしながら、クライアントは、異なったリース持続時間を要求するのを選ぶかもしれません。 また、サーバがDHCPOFFERメッセージからのパラメタをキャッシュするという要件が全くありません。 サーバは、DHCPREQUESTで要求されたパラメタが許容できるのを単にチェックしなければなりません。 パラメタが許容できるなら、サーバは、新しいクライアント結合を記録して、DHCPACKメッセージをクライアントに返します。
If the requested parameters are unacceptable, e.g., the requested lease time is unacceptable to local policy, the server sends a DHCPNAK message to the client. The server may choose to return an error message in the 'message' option.
要求されたパラメタが容認できないなら、例えば、要求されたリース時間がローカルの方針に容認できません、サーバはDHCPNAKメッセージをクライアントに送ります。 サーバは、'メッセージ'オプションにおけるエラーメッセージを返すのを選ぶかもしれません。
If a different server is identified in the 'server identifier' field, the client has selected a different server from which to obtain configuration parameters. The server may discard any information it may have cached about the client's request, and may free the network address that it had offered to the client.
異なったサーバが'サーバ識別子'分野で特定されるなら、クライアントは設定パラメータを得る異なったサーバを選択しました。 サーバは、それがクライアントの要求に関してキャッシュしたどんな情報も捨てて、それがクライアントに提供したネットワーク・アドレスを解放するかもしれません。
Note that the client may choose to collect several DHCPOFFER messages and select the "best" offer. The client indicates its selection by identifying the offering server in the DHCPREQUEST message. If the client receives no acceptable offers, the client may choose to try another DHCPDISCOVER message. Therefore, the servers may not receive a specific DHCPREQUEST from which they can decide whether or not the client has accepted the offer. Because the servers have not committed any network address assignments on the basis of a DHCPOFFER, servers are free to reuse offered network addresses in response to subsequent requests. As an implementation detail, servers should not reuse offered addresses and may use an implementation-specific timeout mechanism to decide when to reuse an offered address.
クライアントがいくつかのDHCPOFFERメッセージを集めて、「最も良い」申し出を選択するのを選ぶかもしれないことに注意してください。 クライアントは、DHCPREQUESTメッセージの提供サーバを特定することによって、選択を示します。 クライアントがどんな許容できる申し出も受けないなら、クライアントは、別のDHCPDISCOVERメッセージを試みるのを選ぶかもしれません。 したがって、サーバはそれらが、クライアントが申し出を受け入れたかどうか決めることができる特定のDHCPREQUESTを受けないかもしれません。 サーバがDHCPOFFERに基づいてどんなネットワーク・アドレス課題も遂行していないので、サーバは無料でその後の要求に対応して提供されたネットワーク・アドレスを再利用できます。 実装の詳細として、サーバは、提供されたアドレスを再利用するべきでなくて、いつ提供されたアドレスを再利用するかを決めるのに実装特有のタイムアウトメカニズムを使用するかもしれません。
In the second case, when there is no 'server identifier' option, the client is renewing or extending a previously allocated IP address. The server checks to confirm that the requested parameters are acceptable. If the parameters specified in the DHCPREQUEST message match the previous parameters, or if the request for an extension of the lease (indicated by an extended 'IP address lease time' option) is acceptable, the server returns a DHCPACK message to the requesting client. Otherwise, the server returns a DHCPNAK message to the
'サーバ識別子'オプションが全くないときの2番目の場合では、クライアントは、以前に割り当てられたIPアドレスを、更新するか、または広げています。 サーバは、要求されたパラメタが許容できると確認するためにチェックします。 DHCPREQUESTメッセージで指定されたパラメタが前のパラメタに合っているか、またはリース(拡張'IPアドレスリース時間'オプションで、示される)の拡大を求める要求が許容できるなら、サーバはDHCPACKメッセージを要求しているクライアントに返します。 さもなければ、サーバはDHCPNAKメッセージを返します。
Droms [Page 28] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[28ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
client. In particular, if the previously allocated network address in the 'ciaddr' field from the client does not match the network address recorded by the server for that client, the server sends a DHCPNAK to the client.
クライアント。 クライアントからの'ciaddr'分野の以前に割り当てられたネットワーク・アドレスがそのクライアントのためにサーバによって記録されたネットワーク・アドレスに合っていないなら、特に、サーバはDHCPNAKをクライアントに送ります。
A DHCP server chooses the parameters to return in a DHCPACK message according to the same rules as used in constructing a DHCPOFFER message, as given in section 4.3.1.
DHCPサーバは同じ規則に従ってDHCPOFFERメッセージを構成する際に使用されるようにDHCPACKメッセージで返すパラメタを選びます、セクション4.3.1で与えるように。
4.3.3 DHCPDECLINE message
4.3.3 DHCPDECLINEメッセージ
If the server receives a DHCPDECLINE message, the client has discovered through some other means that the suggested network address is already in use. The server MUST mark the network address as not allocated and SHOULD notify the local system administrator of a possible configuration problem.
サーバがDHCPDECLINEメッセージを受け取るなら、クライアントは、提案されたネットワーク・アドレスが既に使用中であるとある他の手段で発見しました。 サーバは、割り当てられないようにネットワークがアドレスであるとマークしなければなりません、そして、SHOULDは可能な設定問題についてローカルシステム管理者に通知します。
4.3.4 DHCPRELEASE message
4.3.4 DHCPRELEASEメッセージ
Upon receipt of a DHCPRELEASE message, the server marks the network address as not allocated. The server should retain a record of the client's initialization parameters for possible reuse in response to subsequent requests from the client.
DHCPRELEASEメッセージを受け取り次第、サーバは、割り当てられないようにネットワークがアドレスであるとマークします。 サーバはクライアントからのその後の要求に対応して可能な再利用のためのクライアントの初期化パラメタに関する記録を保有するべきです。
4.4 DHCP client behavior
4.4 DHCPクライアントの振舞い
Figure 5 gives a state-transition diagram for a DHCP client. A client can receive the following messages from a server:
図5はDHCPクライアントのために状態遷移ダイヤグラムを与えます。 クライアントはサーバから以下のメッセージを受け取ることができます:
o DHCPOFFER
o DHCPOFFER
o DHCPACK
o DHCPACK
o DHCPNAK
o DHCPNAK
Table 4 gives the use of the fields and options in a DHCP message by a client. The remainder of this section describes the action of the DHCP client for each possible incoming message. The description in the following section corresponds to the full configuration procedure previously described in section 3.1, and the text in the subsequent section corresponds to the abbreviated configuration procedure described in section 3.2.
テーブル4はクライアントでDHCPメッセージにおける分野とオプションの使用を与えます。 このセクションの残りはそれぞれの可能な入力メッセージのためにDHCPクライアントの動作について説明します。 以下のセクションの記述は以前にセクション3.1で説明された完全な構成手順に対応しています、そして、その後のセクションのテキストはセクション3.2で説明された簡略化された構成手順に一致しています。
4.4.1 Initialization and allocation of network address
4.4.1 ネットワーク・アドレスの初期設定と配分
The client begins in INIT state and forms a DHCPDISCOVER message. The client should wait a random time between one and ten seconds to desynchronize the use of DHCP at startup. The client sets 'ciaddr'
クライアントは、INIT状態で始まって、DHCPDISCOVERメッセージを形成します。 クライアントは始動でDHCPの使用を反連動させる1〜10秒の無作為の時間を待つべきです。 クライアントは'ciaddr'を設定します。
Droms [Page 29] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[29ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
to 0x00000000. The client MAY request specific parameters by including the 'parameter request list' option. The client MAY suggest a network address and/or lease time by including the 'requested IP address' and 'IP address lease time' options. The client MUST include its hardware address in the 'chaddr' field for use in delivery of DHCP reply messages. The client MAY include a different unique identifier in the 'client identifier' option. If the client does not include the 'client identifier' option, the server will use the contents of the 'chaddr' field to identify the client's lease.
0×00000000に。 クライアントは、'パラメタ要求リスト'オプションを含んでいることによって、特定のパラメタを要求するかもしれません。 クライアントは、'要求されたIPアドレス'と'IPアドレスリース時間'オプションを含んでいることによって、ネットワーク・アドレス、そして/または、リース時間を勧めるかもしれません。 クライアントは使用のための'chaddr'分野のDHCP応答メッセージの配送におけるハードウェア・アドレスを入れなければなりません。 クライアントは'クライアント識別子'オプションで異なったユニークな識別子を入れるかもしれません。 クライアントが'クライアント識別子'オプションを入れないと、サーバは、クライアントのリースを特定するのに'chaddr'分野のコンテンツを使用するでしょう。
The client generates and records a random transaction identifier and inserts that identifier into the 'xid' field. The client records its own local time for later use in computing the lease expiration. The client then broadcasts the DHCPDISCOVER on the local hardware broadcast address to 0xffffffff IP broadcast address and 'DHCP server' UDP port.
クライアントは、無作為のトランザクション識別子を生成して、記録して、'xid'分野にその識別子を挿入します。 クライアントは自分自身リース満了を計算することにおける後の使用のための現地時間ののを記録します。 そして、クライアントはローカルのハードウェア放送演説で0xffffffff IP放送演説と'DHCPサーバ'UDPポートにDHCPDISCOVERを放送します。
If the 'xid' of an arriving DHCPOFFER message does not match the 'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message must be silently discarded. Any arriving DHCPACK messages must be silently discarded.
到着しているDHCPOFFERメッセージの'xid'が最新のDHCPDISCOVERメッセージの'xid'に合っていないなら、静かにDHCPOFFERメッセージを捨てなければなりません。 静かにどんな到着しているDHCPACKメッセージも捨てなければなりません。
The client collects DHCPOFFER messages over a period of time, selects one DHCPOFFER message from the (possibly many) incoming DHCPOFFER messages (e.g., the first DHCPOFFER message or the DHCPOFFER message from the previously used server) and extracts the server address from the 'server identifier' option in the DHCPOFFER message. The time over which the client collects messages and the mechanism used to select one DHCPOFFER are implementation dependent. The client may perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender's hardware address, and 0 as the sender's IP address, to avoid confusing ARP caches in other hosts on the same subnet. If the network address appears to be in use, the client sends a DHCPDECLINE message to the server and waits for another DHCPOFFER. As the client does not have a valid network address, the client must broadcast the DHCPDECLINE message.
クライアントは、期間の間、DHCPOFFERメッセージを集めて、(ことによると多く)の入って来るDHCPOFFERメッセージ(例えば、最初のDHCPOFFERメッセージか以前中古のサーバからのDHCPOFFERメッセージ)から1つのDHCPOFFERメッセージを選択して、DHCPOFFERメッセージにおける'サーバ識別子'オプションからサーバアドレスを抜粋します。 クライアントが集めるタイム・オーバーは通信します、そして、あるDHCPOFFERを選択するのに使用されるメカニズムは実装に依存しています。 クライアントは、アドレスが確実に既に使用中にならないようにするために提案されたアドレスにチェックを実行するかもしれません。 例えば、クライアントがARPをサポートするネットワークの一員であるなら、クライアントは提案された要求に関するARP要求を出すかもしれません。 提案されたアドレスを求めるARP要求を放送するとき、クライアントは、同じサブネットで他のホストでARPキャッシュを混乱させるのを避けるために送付者のハードウェア・アドレスとしてそれ自身のハードウェア・アドレスに記入して、送付者のIPアドレスとして0に記入しなければなりません。 ネットワーク・アドレスが使用中であるように見えるなら、クライアントは、DHCPDECLINEメッセージをサーバに送って、別のDHCPOFFERを待ちます。 クライアントに有効なネットワーク・アドレスがないとき、クライアントはDHCPDECLINEメッセージを放送しなければなりません。
Droms [Page 30] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[30ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
-------- -------
| | +-------------------------->| |<-------------------+
| INIT/ | | +-------------------->| INIT | |
| REBOOT |DHCPNAK/ +---------->| |<---+ |
| |Restart| | ------- | |
-------- | DHCPNAK/ | | |
| Discard offer | -/Send DHCPDISCOVER |
-/Send DHCPREQUEST | | |
| | | DHCPACK v | |
----------- | (not accept.)/ ----------- | |
| | | Send DHCPDECLINE | | | |
| REBOOTING | | | | SELECTING | | |
| | | / | | | |
----------- | / ----------- | |
| | / | | |
DHCPACK/ | / +----------------+ | |
Record lease, | | v | |
set timers ------------ | |
| +----->| | DHCPNAK, Lease expired/ |
| | | REQUESTING | Halt network |
DHCPOFFER/ | | | |
Discard ------------ | |
| | | | ----------- |
| +--------+ DHCPACK/ | | |
| Record lease, set -----| REBINDING | |
| timers T1, T2 / | | |
| | DHCPACK/ ----------- |
| v Record lease, set ^ |
+----------------> ------- /Timers T1,T2 | |
+----->| |<---+ | |
| | BOUND |<---+ | |
DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/
DHCPNAK/Discard ------- | Broadcast Halt network
| | | | DHCPREQUEST |
+-------+ | DHCPACK/ | |
T1 expires/ Record lease, set | |
Send DHCPREQUEST timers T1, T2 | |
to leasing server | | |
| ---------- | |
| | |------------+ |
+->| RENEWING | |
| |----------------------------+
----------
-------- ------- | | +-------------------------->| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | イニット/| | +-------------------->| イニット| | | リブート|DHCPNAK/+---------->| | <、-、--+ | | |再開| | ------- | | -------- | DHCPNAK/| | | | 申し出を捨ててください。| -/はDHCPDISCOVERを送ります。| -/はDHCPREQUESTを送ります。| | | | | | DHCPACK v| | ----------- | (受け入れません。)/ ----------- | | | | | DHCPDECLINEを送ってください。| | | | | リブートします。| | | | 選択| | | | | | / | | | | ----------- | / ----------- | | | | / | | | DHCPACK/| / +----------------+ | | リースを記録してください。| | v| | タイマを設定してください。------------ | | | +----->|、| DHCPNAK、Leaseの満期の/| | | | 要求| 停止ネットワーク| DHCPOFFER/| | | | 破棄------------ | | | | | | ----------- | | +--------+ DHCPACK/| | | | 設定されて、リースを記録してください。-----| 縛り直すこと| | | タイマT1、T2/| | | | | DHCPACK/----------- | | Recordリースに対して、^を設定してください。| +---------------->。------- /タイマT1、T2| | +----->| | <、-、--+ | | | | 縛られます。| <、-、--+ | | DHCPOFFER、DHCPACK| | | T2は/DHCPNAK/DHCPNAK/破棄を吐き出します。------- | 放送Haltネットワーク| | | | DHCPREQUEST| +-------+ | DHCPACK/| | 設定されて、T1はリースを吐き出すか、または記録します。| | DHCPREQUESTタイマT1、T2を送ってください。| | サーバを賃貸するのに| | | | ---------- | | | | |------------+ | +->| 更新します。| | | |----------------------------+ ----------
Figure 5: State-transition diagram for DHCP clients
図5: DHCPクライアントのための状態遷移ダイヤグラム
Droms [Page 31] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[31ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPRELEASE
----- ------------ ----------- -----------
分野DHCPDISCOVER DHCPREQUEST DHCPDECLINE、DHCPRELEASE----- ------------ ----------- -----------
'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' selected by client selected by client selected by
client
'secs' (opt.) (opt.) 0
'flags' Set 'BROADCAST' Set 'BROADCAST'
flag if client flag if client
requires broadcast requires broadcast
reply reply
0
'オプアート'BOOTREQUEST BOOTREQUEST BOOTREQUEST'htype'(「規定番号」RFCからの)'hlen'(八重奏におけるハードウェア・アドレスの長さ)はクライアント'secs'によって選ばれたクライアントによって選ばれたクライアントによって選択された0 0 0'xid'を'飛び越す'(選んでください。)。 (選んでください。) 0 クライアントが放送を必要とするならクライアント旗が放送回答回答0を必要とするならSet'BROADCAST'Set'BROADCAST'が旗を揚げさせる'旗'
'ciaddr' 0 previously ciaddr
allocated newtork
address
'yiaddr' 0 0 0
'siaddr' 0 0 0
'giaddr' 0 0 0
'chaddr' client's hardware client's hardware client's
hardware
address address address
'sname' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'file' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
'generic' name or 'generic' name or
null null
'options' options options (unused)
''0 以前に、ciaddrはオプションであるなら示されるなら(未使用の)'sname/ファイル'で示されるところに'yiaddr'0 0 0'siaddr'0 0 0'giaddr'0 0 0'chaddr'クライアントのハードウェアクライアントのハードウェアクライアントのハードウェア・アドレスアドレスアドレス'sname'オプションをnewtorkアドレスに割り当てた'というciaddr sname/ファイル'オプション。 そうでなければ、オプション。 'オプションであるなら示されるなら(未使用の)'sname/ファイル'で示されるところに'オプションをファイルしてください'というそうでなければ、未使用の未使用のsname/ファイル'オプション。 そうでなければ、オプション。 そうでなければ、'ジェネリック'名か'ジェネリック'名かヌルヌル'オプション'オプションオプション(未使用)です。
Droms [Page 32] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[32ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPRELEASE
------ ------------ ----------- -----------
オプションDHCPDISCOVER DHCPREQUEST DHCPDECLINE、DHCPRELEASE------ ------------ ----------- -----------
Requested IP address MAY MUST NOT MUST NOT
IP address lease time MAY MAY MUST NOT
Use 'file'/'sname' fields MAY MAY MAY
DHCP message type DHCPDISCOVER DHCPREQUEST DHCPDECLINE/
DHCPRELEASE
Client identifier MAY MAY MAY
Class identifier SHOULD SHOULD MUST NOT
Server identifier MUST NOT MUST (after MUST
DHCPDISCOVER),
MUST NOT (when
renewing)
Parameter request list MAY MAY MUST NOT
Maximum message size MAY MAY MUST NOT
Message SHOULD NOT SHOULD NOT SHOULD
Site-specific MAY MAY MUST NOT
All others MUST NOT MUST NOT MUST NOT
Useではなく、5月の5月の時間がそうしなければならないIPアドレスリースが'ファイルされてはいけない'というMAY MAY MAY DHCPメッセージタイプDHCPDISCOVER DHCPREQUEST DHCPDECLINE/ DHCPRELEASE Client識別子5月の5月の5月のClass識別子SHOULD SHOULD MUST NOT Server識別子がそうしてはいけない/'sname'分野ではなく、5月がそうしなければならない要求されたIPアドレスはそうしなければなりません(MUST DHCPDISCOVERの後に); NOT(更新するとき)パラメタは、5月の5月がそうしてはいけないMessage SHOULD NOT SHOULD NOT SHOULD Site-詳細All他のものではなく、5月がそうしなければならない5月がそうしてはいけないサイズがそうしてはいけないMaximumメッセージではなく、5月の5月がそうしなければならないリストがそうしてはいけないよう要求しなければなりませんか?
Table 4: Fields and options used by DHCP clients
テーブル4: DHCPクライアントによって使用された分野とオプション
If the parameters are acceptable, the client records the address of the server that supplied the parameters from the 'server identifier' field and sends that address in the 'server identifier' field of a DHCPREQUEST broadcast message. Once the DHCPACK message from the server arrives, the client is initialized and moves to BOUND state. The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER message. The client records the lease expiration time as the sum of the time at which the original request was sent and the duration of the lease from the DHCPOFFER message. The client SHOULD broadcast an ARP reply to announce the client's new IP address and clear any outdated ARP cache entries in hosts on the client's subnet.
パラメタが許容できるなら、クライアントは'サーバ識別子'分野からパラメタを提供して、DHCPREQUEST同報メッセージの'サーバ識別子'分野でそのアドレスを送るサーバのアドレスを記録します。 サーバからのDHCPACKメッセージがいったん到着すると、クライアントは、初期化されて、BOUND状態に移行します。 DHCPREQUESTメッセージはDHCPOFFERメッセージと同じ'xid'を含んでいます。 クライアントはオリジナルの要求が送られた時の合計とリースの持続時間としてDHCPOFFERメッセージからリース満了時間を記録します。 クライアントSHOULDは、クライアントの新しいIPアドレスを発表して、クライアントのサブネットでホストのどんな時代遅れのARPキャッシュエントリーもクリアするためにARP回答を放送します。
4.4.2 Initialization with known network address
4.4.2 知られているネットワーク・アドレスによる初期設定
The client begins in INIT-REBOOT state and sends a DHCPREQUEST message with the 'ciaddr' field set to the client's network address. The client may request specific configuration parameters by including the 'parameter request list' option. The client generates and records a random transaction identifier and inserts that identifier into the 'xid' field. The client records its own local time for later use in computing the lease expiration. The client MUST NOT incldue a 'server identifier' in the DHCPREQUEST message. The client then broadcasts the DHCPREQUEST on the local hardware broadcast address to the 'DHCP server' UDP port.
クライアントは、'ciaddr'分野セットでクライアントのネットワーク・アドレスにINIT-REBOOT状態で始まって、DHCPREQUESTメッセージを送ります。 クライアントは、'パラメタ要求リスト'オプションを含んでいることによって、特定の設定パラメータを要求するかもしれません。 クライアントは、無作為のトランザクション識別子を生成して、記録して、'xid'分野にその識別子を挿入します。 クライアントは自分自身リース満了を計算することにおける後の使用のための現地時間ののを記録します。 クライアントはDHCPREQUESTメッセージの'サーバ識別子'をincldueしてはいけません。 そして、クライアントはローカルのハードウェア放送演説で'DHCPサーバ'UDPポートにDHCPREQUESTを放送します。
Droms [Page 33] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[33ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
Once a DHCPACK message with an 'xid' field matching that in the client's DHCPREQUEST message arrives from any server, the client is initialized and moves to BOUND state. The client records the lease expiration time as the sum of the time at which the DHCPREQUEST message was sent and the duration of the lease from the DHCPACK message.
'xid'分野がクライアントのDHCPREQUESTメッセージでそれに合っているDHCPACKメッセージがどんなサーバからもいったん到着すると、クライアントは、初期化されて、BOUND状態に移行します。 クライアントはDHCPREQUESTメッセージが送られた時の合計とリースの持続時間としてDHCPACKメッセージからリース満了時間を記録します。
4.4.3 Initialization with a known DHCP server address
4.4.3 知られているDHCPサーバアドレスによる初期設定
When the DHCP client knows the address of a DHCP server, in either INIT or REBOOTING state, the client may use that address in the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. If the client receives no response to DHCP messages sent to the IP address of a known DHCP server, the DHCP client reverts to using the IP broadcast address.
DHCPクライアントがINITかREBOOTING状態のどちらかでDHCPサーバのアドレスを知っているとき、クライアントはIP放送演説よりむしろDHCPDISCOVERかDHCPREQUESTのそのアドレスを使用するかもしれません。 クライアントが知られているDHCPサーバのIPアドレスに送られたDHCPメッセージへの応答を全く受けないなら、DHCPクライアントはIP放送演説を使用するのに先祖帰りをします。
4.4.4 Reacquisition and expiration
4.4.4 Reacquisitionと満了
The client maintains two times, T1 and T2, that specify the times at which the client tries to extend its lease on its network address. T1 is the time at which the client enters the RENEWING state and attempts to contact the server that originally issued the client's network address. T2 is the time at which the client enters the REBINDING state and attempts to contact any server.
クライアントは2回、T1、およびT2を維持して、それはクライアントがネットワーク・アドレスでリースを広げようとする回を指定します。 T1はクライアントがRENEWING状態に入って、元々クライアントのネットワーク・アドレスを発行したサーバに連絡するのを試みる時です。 T2はクライアントがREBINDING状態に入って、どんなサーバにも連絡するのを試みる時です。
At time T1 after the client accepts the lease on its network address, the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease. The client generates a random transaction identifier and inserts that identifier into the 'xid' field in the DHCPREQUEST. The client records the local time at which the DHCPREQUEST message is sent for computation of the lease expiration time. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message.
クライアントがネットワーク・アドレスでリースを受け入れた後に時間T1のときに、クライアントは、RENEWING状態に移行して、リースを広げるためにDHCPREQUESTメッセージをサーバに送ります(ユニキャストで)。 クライアントは、DHCPREQUESTの'xid'分野に無作為のトランザクション識別子を生成して、その識別子を挿入します。クライアントはDHCPREQUESTメッセージがリース満了時間の計算のために送られる現地時間を記録します。 クライアントはDHCPREQUESTメッセージで'サーバ識別子'を入れてはいけません。
Any DHCPACK messages that arrive with an 'xid' that does not match the 'xid' of the client's DHCPREQUEST message are silently discarded. When the client receives a DHCPACK from the server, the client computes the lease expiration time as the sum of the time at which the client sent the DHCPREQUEST message and the duration of the lease in the DHCPACK message. The client has successfully reacquired its network address, returns to BOUND state and may continue network processing.
クライアントのDHCPREQUESTメッセージの'xid'に合っていない'xid'と共に到着するどんなDHCPACKメッセージも静かに捨てられます。 クライアントがサーバからDHCPACKを受け取るとき、クライアントはクライアントがDHCPREQUESTメッセージを送った時の合計とDHCPACKメッセージにおけるリースの持続時間としてリース満了時間を計算します。 クライアントは、首尾よくネットワーク・アドレスを再取得して、BOUND状態に戻って、ネットワーク処理を続けるかもしれません。
If no DHCPACK arrives before time T2 (T2 > T1) before the expiration of the client's lease on its network address, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its current network address. The client MUST NOT
どんなDHCPACKもネットワーク・アドレスにおけるクライアントのリースの満了の前に時間T2(T2>T1)の前で到着しないなら、クライアントは、REBINDING状態に移行して、リースを広げるDHCPREQUESTメッセージを送ります(放送で)。 クライアントは'ciaddr'分野を現在のネットワーク・アドレスへのDHCPREQUESTにはめ込みます。 クライアントはそうしてはいけません。
Droms [Page 34] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[34ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
include a 'server identifier' in the DHCPREQUEST message.
DHCPREQUESTメッセージで'サーバ識別子'を含めてください。
Times T1 and T2 are configurable by the server through options. T1 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * duration_of_lease). Times T1 and T2 should be chosen with some random "fuzz" around a fixed value, to avoid synchronization of client reacquisition.
回のT1とT2はサーバでオプションで構成可能です。 T1は(_リースの0.5*持続時間_)をデフォルトとします。 T2は(_リースの0.875*持続時間_)をデフォルトとします。 一定の価値の周りにいくつかの無作為の「むく毛」がある状態で、回のT1とT2は、クライアント「再-獲得」の同期を避けるために選ばれるべきです。
In both RENEWING and REBINDING state, if the client receives no response to its DHCPREQUEST message, the client should wait one-half the remaining time until the expiration of T1 (in RENEWING state) and T2 (in REBINDING state) down to a minimum of 60 seconds, before retransmitting the DHCPREQUEST message.
RENEWINGとREBINDING状態の両方では、クライアントがDHCPREQUESTメッセージへの応答を全く受けないなら、クライアントは残っているT1(RENEWING状態の)の満了までの回とDHCPREQUESTメッセージを再送する最小最低60秒T2(REBINDING状態の)前の半分を待つべきです。
If the lease expires before the client receives a DHCPACK, the client moves to INIT state, MUST immediately stop any other network processing and requests network initialization parameters as if the client were uninitialized. If the client then receives a DHCPACK allocating that client its previous network address, the client SHOULD continue network processing. If the client is given a new network address, it MUST NOT continue using the previous network address and SHOULD notify the local users of the problem.
クライアントがDHCPACKを受け取る前にリースが期限が切れるなら、クライアントは、INIT状態に移行して、すぐに、いかなる他のネットワーク処理も止めなければならなくて、まるでクライアントが非初期化されるかのようにネットワーク初期化パラメタを要求します。 次に、クライアントが前のネットワーク・アドレスをそのクライアントに割り当てながらDHCPACKを受け取るなら、クライアントSHOULDはネットワーク処理を続けています。 新しいネットワーク・アドレスをクライアントに与えるなら、前のネットワーク・アドレスを使用し続けてはいけません、そして、SHOULDは問題について地元のユーザに通知します。
4.4.5 DHCPRELEASE
4.4.5 DHCPRELEASE
If the client no longer requires use of its assigned network address (e.g., the client is gracefully shut down), the client sends a DHCPRELEASE message to the server. Note that the correct operation of DHCP does not depend on the transmission of DHCPRELEASE messages.
クライアントがもう割り当てられたネットワーク・アドレスの使用を必要としないなら(例えばクライアントは優雅に止められます)、クライアントはDHCPRELEASEメッセージをサーバに送ります。DHCPの正しい操作がDHCPRELEASEメッセージの伝達によらないことに注意してください。
5. Acknowledgments
5. 承認
Greg Minshall, Leo McLaughlin and John Veizades have patiently contributed to the the design of DHCP through innumerable discussions, meetings and mail conversations. Jeff Mogul first proposed the client-server based model for DHCP. Steve Deering searched the various IP RFCs to put together the list of network parameters supplied by DHCP. Walt Wimer contributed a wealth of practical experience with BOOTP and wrote a document clarifying the behavior of BOOTP/DHCP relay agents. Jesse Walker analyzed DHCP in detail, pointing out several inconsistencies in earlier specifications of the protocol. Steve Alexander reviewed Walker's analysis and the fixes to the protocol based on Walker's work. And, of course, all the members of the Dynamic Host Configuration Working Group of the IETF have contributed to the design of the protocol through discussion and review of the protocol design.
グレッグMinshall、Leoマクラフリン、およびジョンVeizadesは無数の議論、ミーティング、およびメールの会話で我慢強くDHCPのデザインに貢献しました。 ジェフ・ムガール人は最初に、DHCPのためにクライアント/サーバに基づいているモデルを提案しました。 スティーブ・デアリングは、DHCPによって提供された回路パラメータのリストをまとめるために様々なIP RFCsを捜しました。 ウォルトWimerはBOOTPの豊富な実用的な経験を寄付して、BOOTP/DHCP中継エージェントの振舞いをはっきりさせるドキュメントを書きました。 プロトコルの以前の仕様に基づくいくつかの矛盾を指摘して、ジェシー・ウォーカーは詳細にDHCPを分析しました。 スティーブ・アレクサンダーはウォーカーの仕事に基づくプロトコルにウォーカーの分析とフィックスを見直しました。 もちろん、そして、IETFのDynamic Host Configuration作業部会のすべてのメンバーがプロトコルデザインの議論とレビューでプロトコルのデザインに貢献しました。
Droms [Page 35] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[35ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
6. References
6. 参照
[1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
1983.
[1]Acetta、M.、「リソース位置のプロトコル」、RFC887、米カーネギーメロン大学、1983年12月。
[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
University, October 1993.
[2] アレクサンダー、S.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC1533、ラックマン技術Inc.、Bucknell大学(1993年10月)。
[3] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, USC/Information Sciences
Institute, October 1989.
[3] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、科学が設けるUSC/情報、10月1989日
[4] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support, STD 3, RFC 1123, USC/Information
Sciences Institute, October 1989.
[4] ブレーデン、R.、エディタ、「インターネットホストのための要件--アプリケーションとサポート、STD3、RFC1123、USC/情報科学研究所(1989インチ年10月)。
[5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
(DRARP)", Work in Progress.
[5] ブラウネル、D、「ダイナミックな逆アドレス解決プロトコル(DRARP)」は進行中で働いています。
[6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
Communications Review), 20(4):50--59, 1990.
[6] 新来者、D.とR.Droms、「インターネットディレクトリサービスへの一定のアクセス」Proc20(4): 50--59、1990ACM SIGCOMM90年(コンピュータCommunications Reviewの増刊)、年について。
[7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
Stanford and SUN Microsystems, September 1985.
[7] 耕地、B.とJ.ギルモアと「プロトコル(BOOTP)を独力で進んでください」とRFC951とスタンフォードと太陽マイクロシステムズ、1985年9月。
[8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
PARC, September 1991.
[8] デアリング、S.、「ICMPルータ発見メッセージ」、RFC1256、ゼロックスPARC、1991年9月。
[9] Droms, D., "Interoperation between DHCP an BOOTP" RFC 1534,
Bucknell University, October 1993.
[9]Droms、D.、「Interoperation、RFC DHCPの間でBOOTP」1534、Bucknell大学、10月1993
[10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
Address Resolution Protocol", RFC 903, Stanford, June 1984.
[10] フィンリースンとR.とマンとT.とムガール人、J.とM.Theimer、「逆アドレス解決プロトコル」RFC903、スタンフォード、1984年6月。
[11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
Mechanism for Distributed File Cache Consistency", In Proc. of
the Twelfth ACM Symposium on Operating Systems Design, 1989.
[11] グレーC.、およびD.Cheritonは「以下を賃貸します」。 「分配されたファイルのための効率的なフォールトトレラントメカニズムは一貫性をキャッシュします」、Procで。. オペレーティングシステムデザイン、1989に関する第12ACMシンポジウムについて。
[12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[12]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日
[13] Mockapetris, P., "Domain Names -- Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[13]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日
Droms [Page 36] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[36ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
[14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[14] ムガール人J.、およびS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
Hosts", Work in Progress.
[15] モーガン、R.、「イーサネットの付属ホストのためのダイナミックなIPアドレス課題」が進行中で働いています。
[16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
USC/Information Sciences Institute, September 1981.
[16] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、科学が1981年9月に設けるUSC/情報。
[17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
USC/Information Sciences Institute, August 1993.
[17] レイノルズ、J.、「BOOTP売り主情報拡張子」、USC/情報科学が1993年8月に設けるRFC1497。
[18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[18] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。
[19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
Assignment of IP Addresses for use on an Ethernet. (Available
from the Athena Project, MIT), 1989.
[19] ジェフリー・シラーとマークローゼンスタイン。 イーサネットにおける使用のためのIP AddressesのDynamic Assignmentのためのプロトコル。 (アティナプロジェクト、MITから利用可能)です。, 1989.
[20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC,
June 1981.
[20]Sollins、K.、「TFTPプロトコル(改正2)」、RFC783、NIC、1981年6月。
[21] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, Carnegie Mellon University, October 1993.
[21]Wimer、W.、「明確化と拡大、プロトコルを独力で進んでください、」、RFC1542、カーネギメロン大学、10月1993
7. Security Considerations
7. セキュリティ問題
DHCP is built directly on UDP and IP which are as yet inherently insecure. Furthermore, DHCP is generally intended to make maintenance of remote and/or diskless hosts easier. While perhaps not impossible, configuring such hosts with passwords or keys may be difficult and inconvenient. Therefore, DHCP in its current form is quite insecure.
DHCPは直接本来まだ不安定なUDPとIPに造られます。 その上、一般に、DHCPがリモートな、そして/または、ディスクレスなホストのメインテナンスをより簡単にすることを意図します。 恐らく不可能でない間、パスワードかキーでそのようなホストを構成するのは、難しくて、不便であるかもしれません。 したがって、現在のフォームでのDHCPはかなり不安定です。
Unauthorized DHCP servers may be easily set up. Such servers can then send false and potentially disruptive information to clients such as incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses (such as spoof nameservers), and so on. Clearly, once this seed information is in place, an attacker can further compromise affected systems.
権限のないDHCPサーバは容易にセットアップされるかもしれません。 そのようなサーバは、次に、不正確であるように誤って潜在的に破壊的な情報をクライアントに送るか、またはIPアドレス、不正確なルーティング情報(パロディールータなどを含んでいる)、不正確なドメインネームサーバアドレス(パロディーネームサーバなどの)などをコピーできます。 明確に、この種子情報が適所にいったんあると、攻撃者はさらに影響を受けるシステムに感染することができます。
Malicious DHCP clients could masquerade as legitimate clients and retrieve information intended for those legitimate clients. Where dynamic allocation of resources is used, a malicious client could claim all resources for itself, thereby denying resources to legitimate clients.
悪意があるDHCPクライアントは、正統のクライアントのふりをして、それらの正統のクライアントのために意図する情報を検索できました。 リソースの動的割当てが使用されているところでは、悪意があるクライアントはすべてのリソースのそれ自体に代金を請求することができました、その結果、正統のクライアントに対してリソースを否定します。
Droms [Page 37] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[37ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
8. Author's Address
8. 作者のアドレス
Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837
ラルフDromsコンピュータ理学部323ダナ・工学Bucknell大学リューイスバーグ、PA 17837
Phone: (717) 524-1145 EMail: droms@bucknell.edu
以下に電話をしてください。 (717) 524-1145 メールしてください: droms@bucknell.edu
Droms [Page 38] RFC 1541 Dynamic Host Configuration Protocol October 1993
Droms[38ページ]RFC1541Dynamic Host Configuration Protocol1993年10月
A. Host Configuration Parameters
A。 ホスト設定パラメータ
IP-layer_parameters,_per_host:_
IP層_パラメタ、_ホストあたりの_: _
Be a router on/off HRC 3.1
Non-local source routing on/off HRC 3.3.5
Policy filters for
non-local source routing (list) HRC 3.3.5
Maximum reassembly size integer HRC 3.3.2
Default TTL integer HRC 3.2.1.7
PMTU aging timeout integer MTU 6.6
MTU plateau table (list) MTU 7
IP-layer_parameters,_per_interface:_
IP address (address) HRC 3.3.1.6
Subnet mask (address mask) HRC 3.3.1.6
MTU integer HRC 3.3.3
All-subnets-MTU on/off HRC 3.3.3
Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6
Perform mask discovery on/off HRC 3.2.2.9
Be a mask supplier on/off HRC 3.2.2.9
Perform router discovery on/off RD 5.1
Router solicitation address (address) RD 5.1
Default routers, list of:
router address (address) HRC 3.3.1.6
preference level integer HRC 3.3.1.6
Static routes, list of:
destination (host/subnet/net) HRC 3.3.1.2
destination mask (address mask) HRC 3.3.1.2
type-of-service integer HRC 3.3.1.2
first-hop router (address) HRC 3.3.1.2
ignore redirects on/off HRC 3.3.1.2
PMTU integer MTU 6.6
perform PMTU discovery on/off MTU 6.6
6 サブネットマスク(アドレスマスク)HRC3.3.1.6MTU整数HRC3.3.3AllサブネットMTUオンであるかオフなHRC3.3.3Broadcastは、HRC3.2.2.9Performルータ発見オンであるかオフなRD5.1Router懇願アドレス(アドレス)RD5.1Defaultルータで/で風味0×00000000/0xffffffff HRC3.3.6Performマスク発見オンであるかオフなHRC3.2.2.9Beがマスク供給者であると扱います、以下のリスト ルータアドレス(アドレス)HRC3.3.1.6好みのレベル整数HRC3.3.1.6のStaticルート、以下のリスト 目的地(ホスト/サブネット/ネット)のHRC3.3.1.2目的地マスク(アドレスマスク)HRC3.3.1.2サービスのタイプ整数HRC3.3.1.2が最初にルータ(アドレス)HRCを飛び越す、3.3、.1、.2、無視、/では、HRC3.3.1で/オフMTU6.6にMTU6.6がPMTU発見を実行する.2PMTU整数を向け直します。
Link-layer_parameters,_per_interface:_ Trailers on/off HRC 2.3.1 ARP cache timeout integer HRC 2.3.2.1 Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3
リンクレイヤ_パラメタ、_インタフェースあたりの_: _TrailersオンであるかオフなHRC2.3.1ARPキャッシュタイムアウト整数HRC2.3.2.1イーサネットカプセル化(RFC894/RFC1042)HRC2.3.3
TCP_parameters,_per_host:_ TTL integer HRC 4.2.2.19 Keep-alive interval integer HRC 4.2.3.6 Keep-alive data size 0/1 HRC 4.2.3.6
TCP_パラメタ、_ホストあたりの_: _TTL整数HRC4.2.2.19は間隔整数HRC4.2.3.6生きているKeepデータサイズ0/1HRC4.2.3.6を生かします。
Key:
キー:
MTU = Path MTU Discovery (RFC 1191, Proposed Standard) RD = Router Discovery (RFC 1256, Proposed Standard)
MTUは経路MTU発見(RFC1191、提案された標準)=ルータ第発見と等しいです。(RFC1256標準で提案されて、
Droms [Page 39]
Droms[39ページ]
一覧
スポンサーリンク
