Network Working Group R. Droms Request for Comments: 2131 Bucknell University Obsoletes: 1541 March 1997 Category: Standards Track Dynamic Host Configuration Protocol 本書について 本RFCでは、標準化過程にあるプロトコルについて記述しており、よりよいも のとするための議論や提言は大いに歓迎します。本RFCで定義するプロトコル の標準化状態については最新の「Internet Official Protocol Standards（ STD1）」を参照してください。本書は自由に配布してかまいません。 概要 DHCPはTCP/IPネットワークに接続されているホストにコンフィグレーション情 報を伝達するための仕組みです。DHCPはBOOTP[7]をベースとし、アドレスやそ の他のコンフィグレーション情報[19]を動的に割り当てる機能が付加されてい ます。DHCPはBOOTPリレイエージェント[7,21]の機能を用いることもでき、ま たDHCPサーバ/クライアントはBOOTPサーバ/クライアントと相互に通信可能で す[9]。 目次 1. 導入 1.1 RFC1541からの変更点 1.2 関連技術 1.3 問題点 1.4 要求事項 1.5 用語 1.6 目標 2. プロトコル要約 2.1 コンフィグレーション情報の保持 2.2 アドレスの動的割り当て 3. クライアント・サーバ間プロトコル 3.1 クライアント・サーバ - アドレスの割り当て 3.2 クライアント・サーバ - アドレスの再利用 3.3 リース期間の取り扱い 3.4 ネットワークアドレス以外のパラメータの取得 3.5 クライアントパラメータ 3.6 複数のインタフェースを持つクライアントの運用 3.7 クライアントがDHCPを使用すべき場合 4. DHCPプロトコル定義 4.1 DHCPメッセージの生成と送信 4.2 DHCPサーバの管理 4.3 DHCPサーバの動作 4.4 DHCPクライアントの動作 5. 謝辞 6. 参考文献 7. セキュリティに関する考察 8. 著者 A. ホストコンフィグレーションパラメータ 図一覧 1. DHCPメッセージのフォーマット 2. 「フラグ」フォーマット 3. クライアント・サーバ間でネットワークアドレスを割り当てる際のDHCP メッセージのフローチャート 4. クライアント・サーバ間でネットワークアドレスの再割り当てを行う際 のDHCPメッセージのフローチャート 5. クライアントの状態遷移図 表一覧 1. DHCPメッセージの各フィールドの詳細 2. DHCPメッセージ一覧 3. サーバからのDHCPメッセージのパラメータ 4. 各状態にあるクライアントからのメッセージ 5. クライアントからのDHCPメッセージのパラメータ 1. 導入 DHCP(Dynamic Host Configuration Protocol)はインターネットに接続された ホストにコンフィグレーションパラメータを与えるための仕組みです。DHCPは 二つの機構からなりたっています。すなわち、ホストに依存するコンフィグレ ーションパラメータをDHCPサーバからホストに運ぶためのプロトコルと、ホス トにネットワークアドレスを割り当てるための仕組みです。 DHCPはクライアント・サーバ方式で、指定されたDHCPサーバがネットワークア ドレスを動的に割り当て、コンフィグレーションパラメータとともにホストに 送信します。以下、「サーバ」とはDHCPサーバのことであり、「クライアント」 とはDHCPサーバからコンフィグレーションデータを受け取るホストのことです。 ホストは管理者によって設定されないかぎりサーバになってはいけません。 インターネットに接続されるホストのハードウェアやプロトコルの実装がまち まちであることを考慮すると、全てのホストがDHCPによる要求に応えることは できません。例えば、IPを運用するためには様々な設定が必要です。IPはさま ざまな種類のネットワークで運用されるため、適切なデフォルト値というのが 定めにくいからです。また、ポーリングにより既に使用されているアドレスを 見つける仕組みも存在します。そのような仕組みがアドレスの重複を必ずしも 起こさない保証がないため、あるIPアドレスがいつまでもそのホストによって 独占されるとは限りません。 DHCPでは、IPアドレスの割り当てに3種類の仕組みを用意しています。「自動 割り当て」では、DHCPはそのクライアントがずっと使用していいアドレスを割 り当てます。「動的割り当て」では、DHCPはクライアントにアドレスを一定期 間（もしくは、クライアントがアドレスを返納するまで）リース（貸し出し） します。「手動割り当て」では、クライアントのIPアドレスはネットワーク管 理者によって予め割り当てられ、DHCPは単にクライアントにアドレスを配布す るためにだけ使用されます。ネットワーク管理者のポリシーにより、これらの 仕組みが適宜組み合わされてネットワークが運用されることになります。 これらの三つの仕組みのうち、動的割り当てだけは不用となったアドレスを自 動的に再利用することができます。したがって、ネットワークに一時的に接続 され、その間だけIPアドレスを必要とするようなクライアントや、いくつかの クライアントでその数よりも少ない数のIPアドレスを共有するような場合には 動的割り当ては非常に有用です。また、動的割り当てはIPアドレスが希少で、 旧いクライアントがネットワークから外された時にそのIPアドレスを再利用す ることが必要であるようなネットワークに接続された新しいクライアントにア ドレスを割り当てる際にも有効です。手動割り当ては、動的割り当てが使用で きないようなネットワークで、クライアントのコンフィグレーションデータを 手動で行なわなければならない場合に、ヒューマンエラーを避けるために使用 することもできます。 DHCPメッセージのフォーマットはBOOTPのそれを基にしており、BOOTPのリレイ エージェント[7,21]を利用することができ、またDHCPサーバとBOOTPクライア ントが共存することもできます。BOOTPリレイエージェントがあれば、個々の ネットワークセグメントにDHCPサーバがなくともDHCPを運用することができま す。 1.1 RFC1541からの変更点 本書では、RFC1541で規定したプロトコル仕様を更新しています。新たに DHCPINFORMというメッセージタイプが追加されています（詳細は3.4、4.3、 4.4の各節を参照してください）。また4.2節ならびに4.3節で規定したベンダ クラスの導入による、サーバのためのクライアントのクライアントクラスによ る識別方法も追加されました。一方、最短リース期間についての規定は削除さ れています。その他、DHCPの相互接続テストで指摘された実装上のあいまいな 点が多数明確化されています。 1.2 関連技術 動的ホストコンフィグレーションを解決するための仕組みやプロトコルはこれ までにもいくつかありました。RARP(Reverse Address Resolution Protocol)[10]（さらに拡張されたDARAP(Dynamic RARP)[5]）ではネットワー ク上で使用されているアドレスの発見とアドレスの自動割り当てが可能です。 TFTP(Trivial File Transfer Protocol)[20]ではブートイメージをブートサー バから配布することをかのうとします。ICMP(Internet Control Message Protocol)[16]は"ICMP redirect"メッセージによりルータの存在をホストに通 知することができます。またICMPでは"ICMP mask request"メッセージにより ネットワークマスクを、"ICMP information request"メッセージによりその他 の情報を通知することができます。ホストはICMPルータ発見によりルータの存 在を知ることができます。 BOOTPはコンフィグレーション情報の転送機構です。また、BOOTPは拡張可能で あり、公認の拡張がいくつかのコンフィグレーションパラメータに対し定めら れています[17]。Morgan はBOOTPによる動的IPアドレス割り当てのための拡張 を提案しています[15]。MITのAthenaプロジェクトで使用されたNIP(Network Information Protocol)はIPアドレスの動的割り当てのための仕組みです[19]。 RLP(Resource Location Protocol)[1]は上位層のサービスのロケーション情報 を提供します。Sun Microsystems のディスクレスワークステーションはRARP とTFTP、それに"bootparams"というRPCを用いてコンフィグレーション情報と OSのコードを配布する仕組みを採用しています（Sun Microsystems、Sun Workstation、SunOSはSun Microsystemsの商標です）。またSunではDRARPを用 いて新しくネットワークにつながれたホストの自動インストールを実現してい ます。 他の関連技術としては、MTU(path Minimum Transmission Unit)発見アルゴリ ズムにより、任意のインターネットのMTUを発見することができます[14]。ま たARP(Address Resolution Protocol)をリソースのロケーションと選択情報を 転送するために使用することが提案されています[6]。最後に、Host Requirements RFC[3,4]でホストの再コンフィグレーションに対する要求とデ ィスクレスホストの初期化に対する提案が行なわれています。 1.3 問題点 DHCPはHost Requirements RFCで規定されるコンフィグレーションパラメータ をクライアントに提供するために作られました。DHCPによりパラメータを受け 取った後はクライアントは自由に通信できるようになります。DHCPにより提供 されるTCP/IPに関するパラメータを付録Aに示します。 初期化されるクライアントがこれら全てのパラメータを必要な訳ではありませ ん。クライアントとサーバはクライアントやサブネットによって必要となるパ ラメータのみを送信するよう打ち合せるべきです。 DHCPでは、IPに直接関係の無いパラメータのコンフィグレーションも可能です。 DHCPはまた新規クライアントをDNS(Domain Name System)[12,13]に登録するこ とはありません。 DHCPはルータのコンフィグレーションに使用すべきではありません。 1.4 要求事項 本書で使用される表現についての規定。日本語訳の段階で意味を織り込んであ るので省略します。 1.5 用語 本書では次の単語を使用する。 ・DHCPクライアント DHCPを使用して、ネットワークアドレスなどのコンフィグレーションパラメ ータを取得するインタネット上のホスト。 ・DHCPサーバ DHCPクライアントにコンフィグレーションパラメータを提供するインタネッ ト上のホスト。 ・BOOTPリレイエージェント DHCPサーバとDHCPクライアント間でやりとりされるDHCPメッセージを中継す るルータ、もしくはインタネット上のホストで稼働するエージェント。DHCP では、BOOTPで規定されているリレイエージェントと同様の動作をするリレ イエージェントを使用する。 ・登録リスト（binding） クライアント毎に割り当てたコンフィグレーションパラメータ（少なくとも IPアドレスが含まれています）のリスト。登録リストはサーバが管理してい る。 1.5' 訳語 日本語化にあたって、以下の訳語は原文では下記のように表記されています。 訳語 原文表記 意味 「初期化」状態 INIT 初期起動 「再初期化」状態 REBOOTING リブート 「再/初期化」状態 INIT-REBOOT ブート全般 「選択中」状態 SELECTING サーバの選択中 「リース」状態 BOUND リソースを割り当てられて正常に 動作している状態 「延長」状態 RENEWING リースの延長（サーバは変わらず） 「再割り当て」状態 REBINDING リースの更新（サーバは変わるか もしれない） 1.6 目標 DHCPの目標は以下の通りです。 ・DHCPはポリシーと言うよりは機構であるべきである。DHCPではローカルな管 理者がパラメータを自由にコンフィグレーション可能でなくてはならない。 すなわち、ローカルな管理者がローカルな運用ポリシーを堅持できるべきで ある。 ・クライアントは手動コンフィグレーションされるべきではない。各クライア ントはユーザの介入無しに適切なコンフィグレーション情報を見つけるべき である。 ・ネットワークは各クライアントに対して手動コンフィグレーションを要求す べきではない。通常の状態では、ネットワーク管理者は各クライアントのコ ンフィグレーションに介入すべきではない。 ・DHCPのサーバは各サブネットにあるべきではない。規模的あるいは経済的観 点から、DHCPはBOOTPリレイエージェントを用い、ルータを越えて動作すべ きである。 ・クライアントは要求に対する複数の回答があることを想定していなければな らない。実装によっては、複数の重複するコンフィグレーション情報の受信 による信頼性と性能の向上をねらうものもありうる。 ・DHCPは既存の静的コンフィグレーションホストや既存のプロトコルと共存で きなければならない。 ・DHCPはRFC951とRFC1542[21]に定められた通り、BOOTPリレイエージェントと 協調動作できなければならない。 ・DHCPは既存のBOOTPクライアントにサービスを提供できなければならない。 ここから先は、ネットワーク層のパラメータの転送に対する目標です。 ・ネットワークアドレスは常に一つのクライアントでのみ使用されなければな らない。 ・クライアントがリブートしても同様のコンフィグレーションが得られなけれ ばならない。クライアントは可能な限り前回と同じコンフィグレーションパ ラメータが得られるべきである。 ・サーバがリブートしても同様のコンフィグレーションが得られなければなら ない。その場合でもクライアントは可能な限り前回と同じコンフィグレーシ ョンパラメータが得られるべきである。 ・新しいクライアントの手動コンフィグレーションを避けるために、新しいク ライアントに自動的にコンフィグレーションパラメータを送信できなければ ならない。 ・特定のクライアントに対する固定、あるいは定常的なコンフィグレーション パラメータの割り当てができなければならない。 2. プロトコル要約 クライアントの観点からするとDHCPはBOOTPの拡張にすぎません。これはすな わち、既存のBOOTPクライアントは何の変更も無しにサーバに接続できること を意味しています。RFC1542[2]では、BOOTPとDHCPのクライアントとサーバの 関係[9]について詳説しています。サーバとクライアント間には動作の最適化 のためのいくつかの新しい、オプショナルな手続きがあり、3章と4章で解説し ます。 図1はDHCPメッセージのフォーマットを示しており、表1は個々のフィールドに ついて詳説しています。図中の数字は各フィールドのサイズをオクテットで表 したものです。フィールドにある名称は原文のままで、表1にて本文中での用 語との対応を取っています。 DHCPとBOOTPには二つの根本的な違いがあります。一つ目は、DHCPにはクライ アントが一定期間ネットワークアドレスをリースされるための仕組みがあるこ とで、ネットワークアドレスを異るクライアントに順番に割り振ることができ ること。二つ目は、DHCPにはクライアントが必要とする全てのIPコンフィグレ ーションパラメータを提供するための仕組みがあることです。 DHCPではあるフィールドの意味を明確にするための名称の変更を行なっていま す。BOOTPで「ベンダ拡張」と呼ばれていたフィールドをDHCPでは「オプショ ン」と改名しました。同様に、BOOTP「ベンダ拡張」フィールドで使用され、 ベンダ拡張と呼ばれていたタグ付きデータを単にオプションと呼ぶことにしま す。 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 (可変長) | +---------------------------------------------------------------+ 図 1: DHCPメッセージのフォーマット DHCPでは、サーバにクライアントの識別子を渡すために「クライアントID」と いうオプションを新設しました。これにより、BOOTPではクライアントのハー ドウェアドレスであり識別子でもあった「クライアントハードウェアアドレス」 を本来のハードウェアアドレスとしてのみ使用することになります。「クライ アントID」には規定はなく、またサーバが解釈することもありません。「クラ イアントID」は、例えば「クライアントハードウェアアドレス」同様、クライ アントのハードウェアアドレスを含んでいてもかまわないし、DNS名のような 別の識別子でもかまいません。「クライアントID」は、そのクライアントが属 するサブネット内で一意でなくてはなりません。一旦、クライアントが「クラ イアントID」をどれかのメッセージで使用した場合、全てのサーバがそのクラ イアントを正しく認識できるように、クライアントは一連のメッセージでその 識別子を使い続けなければなりません。 DHCPでは、「サーバIPアドレス」を次回のクライアントの初期化で使用するサ ーバのアドレスである、としています。次回も対応可能な場合、サーバは自ら のアドレスを「サーバIPアドレス」に入れて返答してもかまいません。これと は別にサーバは「オプション」の「サーバID」に自らのアドレスを入れて返さ なければなりません。 FIELD OCTETS DESCRIPTION ----- ------ ----------- op 1 「オペレーションコード」 1 = BOOTREQUEST, 2 = BOOTREPLY htype 1 「ハードウェア番号」 詳細は"Assigned Numbers" RFCのARPに関する部分 を参照のこと。ちなみに、'1' = 10Mイーサネット hlen 1 「ハードウェアアドレス長」 （10Mイーサネットでは'6'） hops 1 「転送回数」 クライアントが'0'に設定する。リレイエージェン トを経由する場合に使用される。 xid 4 「トランザクションID」 クライアントが要求毎に用意するランダムな数字で、 メッセージの対応を取るために使用される。 secs 2 「経過時間」 クライアントが初期化を始めてからの経過時間を設 定する。 flags 2 「フラグ」（図2を参照のこと） ciaddr 4 「クライアントIPアドレス」 クライアントが「リース」、「延長」、「再割り当 て」のいずれかの状態の時に、ARPに返答できる場 合にのみ設定される。 yiaddr 4 「割り当てIPアドレス」 siaddr 4 「サーバIPアドレス」 次回の初期化で使用すべきサーバのIPアドレス。 DHCPOFFER、DHCPACKでサーバが返答する。 giaddr 4 「リレイエージェントIPアドレス」 リレイエージェントを使用する時に使用される。 chaddr 16 「クライアントハードウェアアドレス」 sname 64 「サーバ名」 サーバのホスト名。オプション。ヌル文字で終わる 文字列。 file 128 「ブートファイル名」 ヌル文字で終わる文字列。DHCPDISCOVERで一般的な 名称かヌル文字をいれると、DHCPOFFERでフルパス に変換されて戻る。 options 可変長 「オプション」 詳細はオプションについて定めた文書を参照のこと。 表 1: DHCPメッセージの各フィールドの詳細 「オプション」は可変長になりました。クライアントは312オクテットまでの 「オプション」を持つDHCPメッセージが受信できなければなりません。これは、 クライアントは、IPホストが受信できなければならない最小のIPパケットサイ ズ[3]である576オクテットまでのサイズのメッセージを受信できなければなら ない、という規定によります。より大きなメッセージを使用する場合は、「最 大DHCPメッセージ長」オプションにより、クライアントとサーバの間で合意を 形成します。「オプション」は「ブートファイル名」と「サーバ名」の各フィ ールドに拡張定義することができます。 DHCPを初期設定の一部として（クライアントのTCP/IPソフトウェアの初期化が 終了する前に）使用しているクライアントの場合は、TCP/IPソフトウェアの独 創的な使用とRFC1122の自由奔放な解釈が必要です（訳者註:この部分皮肉のよ うです）。このTCP/IPソフトウェアはIPアドレスが設定される前であっても、 クライアントのハードウェアアドレス宛に送信されたIPパケットを受信し、IP 層に渡せるべきです。またサーバやBOOTPリレイエージェントは、TCP/IPソフ トウェアの初期化が完了するまでハードウェアアドレス宛のパケットを受信で きないクライアントへのメッセージは送信できなくてもかまいません。 前述のTCP/IPソフトウェアの初期化が完了するまでハードウェアアドレス宛の パケットを受信できないクライアントが居るような場合は、「フラグ」[21]を 使用します。左端のビットは「ブロードキャストフラグ」で、このフラグにつ いては4.1節で詳説します。残りの領域は将来の拡張のために取り置かれてお り、クライアントによって全て'0'に設定され、またサーバやリレイエージェ ントは無視しなければなりません。図2に「フラグ」のフォーマットを示しま す。 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: ブロードキャストフラグ MBZ: MUST BE ZERO (未使用) 図 2: 「フラグ」フォーマット 2.1 コンフィグレーション情報の保持 DHCPが提供する第一のサービスがクライアントに対するコンフィグレーション 情報の保持機能です。情報の保持モデルは、DHCPが個々のクライアントを識別 するためのキー（例えば、IPサブネットアドレスとそのサブネット内での一意 な識別子）を保持し、それに対応する形で個々のクライアントのコンフィグレ ーション情報を保持するというものです。 例えば、このキーはIPサブネットアドレスとハードウェアアドレスの組み合わ せであってもかまいません（ハードウェアアドレスは、異るメディアのネット ワーク間ではビットオーダー問題によるアドレスの重複を避けるために、ハー ドウェアの種類毎に区別されるべきであることに注意）。ハードウェアアドレ スは他のサブネットで使用されていた、あるいは使用されているものを使用し ても良いし、世界中で一意でなくてもかまいません。一方、キーはIPサブネッ トアドレスとホスト名の組み合わせであってもかまいません。この場合、他の サブネットに移動してしまったクライアントやハードウェアアドレスが変わっ てしまったクライアント（ネットワークボードの障害等による交換など）にコ ンフィグレーション情報を割り当ててもかまいません。DHCPでは、クライアン トが「クライアントID」で別の識別子を使用しないかぎり、IPサブネットアド レスとハードウェアアドレスの組み合わせをキーとして使用します。クライア ントはDHCPサービスからコンフィグレーション情報を受け取ることができます。 クライアントがコンフィグレーション情報を引き出す方法は、コンフィグレー ション情報を要求し、サーバが応答にコンフィグレーション情報を渡すという プロトコルメッセージによって実現されます。 2.2 アドレスの動的割り当て DHCPの第二のサービスは、ネットワークアドレス（IPアドレス）の一時的、あ るいは固定的な割り当てです。動的割り当ての仕組みは簡単で、クライアント が一定の期間アドレスを使用したい旨要求するだけです。この割り当ての仕組 みではその期間内そのアドレスを別のホストに割り当てたりしないこと、クラ イアントが要求する度に可能なかぎり同じアドレスを割り当てるようにするこ とが保証されています。本書では、クライアントにアドレスが割り当てられて いる期間のことを『リース期間』と呼ぶことにします[11]。クライアントはリ ース期間の延長を要求することもできます。クライアントはアドレスが不要に なればサーバに返納してもかまいません。またリース期間を無限にすることに よって固定的割り当てを要求することもできます。なお、たとえクライアント が固定的割り当てを要求しても、サーバはそのクライアントがネットワークか ら外された場合を考慮してリース期間を有限としてもかまいません。 時には、アドレスの枯渇によりネットワークアドレスの付け替えが必要になる ことがあります。そのような場合、リース期間の切れたアドレスは再利用され ます。サーバはアドレスの再利用に際し、保持するコンフィグレーション情報 を如何様にでも利用すべきです。例えば、サーバはあまり頻繁に割り当てられ ていないアドレスを優先して再利用してもかまいません。整合を取るために、 サーバは割り当て前には再利用するアドレスをチェック（ICMPechoによるチェ ック）すべきですし、またクライアントも割り当てられたアドレスをチェック （ARPによるチェック）すべきです。 3. クライアント・サーバ間プロトコル DHCPはRFC951に定められている、図1と表1にあるようなBOOTPと同じメッセー ジを使用しています。クライアントからサーバに送られるメッセージでは「オ ペレーションコード」はBOOTREQUESTになっており、サーバからクライアント に送られるメッセージではBOOTREPLYとなっています。 「オプション」の最初の4オクテットは、DHCPメッセージでは（RFC1497[17]に ある"magic cookie"と同様に）10進数の99、130、83、99となっています。「 オプション」の残りの領域は、タグ付きパラメータのリストです。RFC1497の 「ベンダ拡張」の全てはDHCPでは「オプション」と呼ばれることになっていま す。DHCPで使用されるオプションについてはRFC1533を参照してください。 ここまで、いくつかのオプションについて説明してきましたが、あるオプショ ン、即ち「DHCPメッセージタイプ」は全てのDHCPメッセージに含まれていなけ ればなりません。このオプションはDHCPメッセージの種類を特定するものです。 その他のオプションは「DHCPメッセージタイプ」により必須であったり、必須 ではなかったり、不要であったりします。 本書では、DHCPメッセージは「DHCPメッセージタイプ」で呼ぶことにします。 すなわち、「DHCPメッセージタイプ」が'1'であるようなメッセージは DHCPDISCOVERと呼びます。 3.1 クライアント・サーバ - アドレスの割り当て 表2に示されるDHCPメッセージのやりとりについて簡単に説明します。この場 合の典型的なフローチャートは図3のようになります。クライアントが自分の アドレスを知っている場合には、いくつか手続きが省略されますが、その場合 については3.2で詳説します。 1. クライアントがDHCPDISCOVERをローカルサブネットにブロードキャストす る。DHCPDISCOVERにはネットワークアドレスとリース期間を示すオプショ ンが含まれていてもかまわない。BOOTPリレイエージェントは別のサブネッ トにいるサーバにメッセージを転送してもかまわない。 2. サーバは「割り当てIPアドレス」や他のオプションを含むDHCPOFFERを応答 する。サーバは、「割り当てIPアドレス」として応答したネットワークア ドレスを取り置く必要はない（取り置いていたほうが効果的ではあるが）。 サーバは、アドレスの割り当て時に、そのアドレス宛にICMP-Echo Request パケットを送るなどして、そのアドレスがすでに使用中であるかどうかを チェックすべきである。また、サーバはネットワーク管理者の設定により このチェックを無効にできるように実装されるべきである。サーバは DHCPOFFERを、必要に応じてリレイエージェントを介して、クライアントに 送信する。 Message Use ------- --- DHCPDISCOVER - サーバを見つけるためにクライアントがブロードキャス トする。 DHCPOFFER - DHCPDISCOVERへの応答として、コンフィグレーション情 報を入れてサーバからクライアントに送信される。 DHCPREQUEST - クライアントが、(a)サーバに提供されたコンフィグレー ション情報の割り当てを要求するためと、その他のサー バに別のサーバを選択したことを知らせるために、また は(b)システムのリブートの後などに、以前割り当てられ たアドレスの割り当て正当性の確認のために、もしくは (c)アドレス割り当て期間の延長のために、サーバに送信 する。 DHCPACK - 割り当てられたネットワークアドレスを含むコンフィグ レーション情報とともにサーバからクライアントに送ら れる。 DHCPNAK - サーバからクライアントに送られる、（クライアントが 新しいサブネットに移動したことなどによる）正しくな いネットワークアドレスをクライアントが指定したこと や、リソースリース期間切れなどの指摘。 DHCPDECLINE - クライアントからサーバに送られる、アドレスがすでに 使用されていることの指摘。 DHCPRELEASE - クライアントからサーバに送られる、ネットワークアド レスの開放とリースのキャンセルメッセージ。 DHCPINFORM - クライアントからサーバに送られる、コンフィグレーシ ョン情報のみを問い合わせるメッセージ。クライアント は別途ネットワークアドレスを割り当てられている。 表 2: DHCPメッセージ一覧 サーバ クライアント サーバ (指定されていない) (指定された) v v v | | | | 初期化開始 | | | | | _____________/|\_____________ | |/ DHCPDISCOVER | DHCPDISCOVER \| | | | コンフィグレーション | コンフィグレーション 設定 | 設定 | | | |\ | ____________/| | \_________ | /DHCPOFFER | | DHCPOFFER\ |/ | | \ | | | 応答待ち | | \| | | コンフィグレーション選択 | | | | | _____________/|\_____________ | |/ DHCPREQUEST | DHCPREQUEST \| | | | | | コンフィグレーション送付 | | | | | _____________/| | |/ DHCPACK | | | | | 初期化終了 | | | | . . . . . . | | | | 正常なシャットダウン | | | | | |\_____________ | | | DHCPRELEASE \| | | | | | リース情報放棄 | | | v v v 図 3: クライアント・サーバ間でネットワークアドレスを割り当てる際 のDHCPメッセージのフローチャート 3. クライアントは複数のサーバから一つ以上のDHCPOFFERを受信することにな る。クライアントは複数の応答を受信するまで待ってもかまわない。クラ イアントはDHCPOFFERにあるコンフィグレーション情報をチェックして、そ れをもとにどれか一つのサーバを選択し、そのサーバが選択されたことを 示すため「サーバID」を含めたDHCPREQUESTをブロードキャストする。この 時、必要なコンフィグレーション情報を要求するためのオプションを添付 してもかまわない。DHCPOFFERにおける「要求IPアドレス（requested IP address）」オプションは「割り当てIPアドレス」と同じでなくてはならな い。DHCPREQUESTはDHCP/BOOTPリレイエージェントによって中継されるが、 DHCPREQUESTをおおもとのDHCPDISCOVERを受信したのと同じサーバに確実に 到達させるために、DHCPREQUESTの「経過時間」にはDHCPDISCOVERで使用し た「経過時間」と同じ値を使用し、おおもとのDHCPDISCOVERを発行したの と同じブロードキャストアドレスに送信する。クライアントがDHCPOFFERの 受信待ちでタイムアウトした場合、DHCPDISCOVERを再送する。 4. サーバはクライアントがブロードキャストしたDHCPREQUESTを受信するが、 「サーバID」により指定されていないサーバはそのDHCPREQUESTによりクラ イアントが別のサーバを選択したことを知る。指定されたサーバは、リソ ースを取り置くとともに、DHCPACKに要求のあったコンフィグレーション情 報を含めて応答する。「クライアントID」または「クライアントハードウ ェアアドレス」と、割り当てたネットワークアドレスにより割り当てを受 けたクライアントが一意に識別されるため、以後DHCPメッセージではこの 組み合わせによりサーバ、クライアント双方が割り当て関係を認識する。 DHCPACKに含まれるパラメータは、それに先立つDHCPOFFERに含まれるパラ メータと矛盾すべきではない。サーバはこの時点では提供するネットワー クアドレスのチェックをすべきではない。DHCPACKの「割り当てIPアドレス」 には割り当てられたネットワークアドレスが設定される。 指定されたサーバがDHCPREQUESTでの要求に応えられない場合（すなわち、 要求されたネットワークアドレスが既に割り当てられてしまっている場合）、 サーバはDHCPNAKで応答すべきである。 サーバはDHCPOFFERでクライアントに提供を申し出たネットワークアドレス を使用不可能にしておいてもかまわないが、DHCPREQUESTを受信しなかった 場合は利用可能に戻しておくべきである。 5. クライアントは要求したコンフィグレーション情報の入ったDHCPACKを受信 すると、パラメータのチェック（ARPで割り当てられたネットワークアドレ スのチェックそするなど）を行ない、リース期間などを記録しておく。こ れでクライアントのコンフィグレーションが終了したことになる。DHCPACK により受信したコンフィグレーション情報に問題があった場合（アドレス がすでに使用されていた、など）は、クライアントはDHCPDECLINEをサーバ に送信してコンフィグレーションをやり直す。クライアントはメッセージ ループによるネットワークトラフィックの増大を避けるために、コンフィ グレーションをやり直すまでに少なくとも10秒間待つべきである。 クライアントがDHCPNAKを受信した場合、クライアントはコンフィグレーシ ョンをやり直す。 DHCPACKまたはDHCPNAKを待ってクライアントがタイムアウトした場合は、 クライアントはDHCPREQUESTを4.1節の再送アルゴリズムに従って再送する。 クライアントは、クライアント（ならびにそのユーザ）にとってタイムア ウトまでの時間があまり長くならない程度に、すなわち4.1節にあるように コンフィグレーションをやり直すまでのDHCPREQUESTの再送は4回まででそ の再送にかかる時間も60秒までの範囲内で、サーバにメッセージが到達す るのに十分なように再送回数を設定すべきである。再送の後もDHCPACKまた はDHCPNAKが受信できなかった場合は、クライアントは初期化をやり直す。 クライアントはユーザに初期化が失敗してやり直すことを通知すべきでし ょう。 6. クライアントはDHCPRELEASEをサーバに送付することによってネットワーク アドレスのリースを放棄できる。リースは「クライアントID」もしくは「 クライアントハードウェアアドレス」と、DHCPRELEASEで指定されるネット ワークアドレスにより識別される。もし、クライアントがリースを受ける 際に「クライアントID」を指定していた場合、DHCPRELEASEでも同じ「クラ イアントID」を指定していなければならない。 3.2 クライアント・サーバ - アドレスの再割り当て クライアントが先に割り当てられたネットワークアドレスの再割り当てを受け たい場合、前節のいくつかのステップを省略することができます。図4にその 場合の典型的なクライアント・サーバ間のフローチャートを示します。 1. クライアントはローカルサブネットで「要求IPアドレス」オプションに先 に使用していたネットワークアドレスを含むDHCPREQUESTをブロードキャス トする。クライアントはそのアドレスの割り当てをまだ受けていないので、 「クライアントIPアドレス」にアドレスを設定してはいけない。リレイエ ージェントはそのメッセージを別のサブネットのサーバに転送する。もし、 クライアントが先にアドレスの割り当てを受ける際に「クライアントID」 を指定していた場合、DHCPREQUESTでも同じ「クライアントID」を指定して いなければならない。 2. このクライアントのリソースに心当たりのあるサーバはDHCPACKで返答する。 サーバはクライアントのネットワークアドレスが使用中であるかどうかを チェックすべきではない。この時点では、このクライアントがICMP Echo Requestメッセージに返答してしまうかもしれないからである。 サーバ クライアント サーバ v v v | | | | 初期化開始 | | | | | /|\ | | ___________/ | \___________ | | /DHCPREQUEST | DHCPREQUEST\ | |/ | \| | | | コンフィグレーション | コンフィグレーション 設定 | 設定 | | | |\ | /| | \ | ___________/ | | \ | / DHCPACK | | \________ |/ | | DHCPACK\ | | | 初期化完了 | | \| | | | | | （後続のDHCPACK | | メッセージは | | 無視される） | | | | | | | v v v 図 4: クライアント・サーバ間でネットワークアドレスの再割り当てを 行う際のDHCPメッセージのフローチャート クライアントの要求が無効になっている場合（例えばクライアントが別の サブネットに移動してしまっている場合）はDHCPNAKで応答すべきである。 サーバは、自分が持つ情報が正確である保証がなければ応答すべきではな い。例えば、あるサーバが、あるクライアントの要求がリース切れになっ ているリソースに対するものであると認識したとしても、そのリースが別 のサーバによってなされたものであり、サーバ間で情報を共有する仕組み がないのであれば、DHCPNAKで応答すべきではない。 もし、DHCPREQUESTで「リレイエージェントIPアドレス」が'0'だった場合、 クライアントはサーバと同じサブネット上にいることになる。クライアン トが正しいネットワークアドレスやサブネットマスクを持っていないかも しれないし、ARPにも応答しないかもしれないので、サーバはDHCPNAKを 0xffffffff宛にブロードキャストしなければならない。そうでない場合は、 サーバはDHCPNAKを「リレイエージェントIPアドレス」を持つBOOTPリレイ エージェントに直接送付しなければならない。リレイエージェントはクラ イアントのハードウェアアドレス宛に直接メッセージを転送する。これに よりDHCPNAKはクライアントが新しいネットワークに移動した場合でも配送 されるのである。 3. コンフィグレーション情報入りのDHCPACKを受信したクライアントは（3.1 にあるように）パラメータのチェックを行ない、リース期間などを記録す る。このリースは「クライアントID」もしくは「クライアントハードウェ アアドレス」とネットワークアドレスの組で識別される。この時点でコン フィグレーションが終了したことになる。 DHCPACKのIPアドレスがすでに使用されていることをクライアントが検知し た場合、クライアントはサーバにDHCPDECLINEを送信し、コンフィグレーシ ョンをやり直す。これは4.4のDHCP状態遷移図でクライアントが「初期化」 状態に移行したことに対応する クライアントがDHCPNAKを受信した場合は先に割り当てられていたネットワ ークアドレスが利用できないことになるので、コンフィグレーションをや り直すことによって新しいネットワークアドレスを要求しなければならな い。この場合は3.1の手続きを踏むことになる。これもDHCP状態遷移図でク ライアントが「初期化」状態に移行したことに対応する。 クライアントがDHCPACKまたはDHCPNAKを受信せずにタイムアウトした場合、 クライアントは4.1の再送アルゴリズムに従ってDHCPREQUESTメッセージを 再送する。クライアントは、クライアント（ならびにそのユーザ）にとっ てタイムアウトまでの時間があまり長くならない程度に、すなわち4.1節に あるようにコンフィグレーションをやり直すまでのDHCPREQUESTの再送は4 回まででその再送にかかる時間も60秒までの範囲内で、サーバにメッセー ジが到達するのに十分なように再送回数を設定すべきである。再送の後も DHCPACKまたはDHCPNAKが受信できなかった場合は、クライアントはリース 期間が残っている間は前回使用したネットワークアドレスやコンフィグレ ーション情報を使用してもかまわない。これは図5の状態遷移図でクライア ントがリース状態に移行したことに対応する。 4. クライアントはサーバにDHCPRELEASEを送ることによってネットワークアド レスのリースを放棄できる。リースはDHCPRELEASEの「クライアントID」ま たは「クライアントハードウェアアドレス」と、ネットワークアドレスに より識別される。 クライアントがローカルにネットワークアドレスを得ている場合は、クラ イアントが通常のシャットダウンでアドレスを放棄することはない。クラ イアントがアドレスを放棄する必要があるのは例えばクライアントが別の サブネットに移動する場合などだけである。 3.3 リース期間の取り扱い クライアントはネットワークアドレスの有限時間（無限という場合もあり得る） のリースを得ますが、本プロトコルにおいては時間は秒単位で取り扱われ、 '0xffffffff'をもって無限時間と見なします。なお、最小のリース期間は1時 間とします。 サーバとクライアントは同期した時計を持っているわけではないので、DHCPメ ッセージで扱われる時間はクライアントのローカルな時計を基準とします。時 間は32ビットの秒表記で0からほぼ100年間までの値を取り、DHCPで取り扱うに は十分な時間でしょう。 ここではサーバとクライアントの時計は同じように動作するとしていますが、 二つの時計に時差がある場合は、サーバはクライアントよりも先にリース期間 が終了したと思うかもしれません。時間の保証のために、サーバはリース期間 として記録してあるよりも短い期間をクライアントに返答してもかまいません。 3.4 ネットワークアドレス以外のパラメータの取得 クライアントが（手動でのコンフィグレーションなどの）DHCP以外の方法でネ ットワークアドレスを取得した場合に、他のローカルパラメータを取得するた めには、DHCPINFORMを使用することができます。DHCPINFORMメッセージを受信 したサーバは、アドレスの割り当てや既存のリースのチェックや「割り当てIP アドレス」や「リース期間」の設定をすることなく、クライアントに適したロ ーカルパラメータをDHCPACKに含めて応答します。サーバはDHCPINFORMの「ク ライアントIPアドレス」にダイレクトにDHCPACKメッセージを送付すべきです。 サーバは整合性確保のためにDHCPINFORMのネットワークアドレスをチェックす べきですが、既存のリースとしてチェックしてはなりません。サーバはパラメ ータを含むDHCPACKを生成し、クライアントにダイレクトにDHCPACKを送付しま す。 3.5 クライアントパラメータ 全てのクライアントが付録Aにあるパラメータの全てを要求するわけではあり ません。サーバからクライアントに送付されるパラメータの数を減らすために、 以下の二つの方式が使用されます。一つは、ほとんどのパラメータがHost Requirements RFCでデフォルト値が定義されているため、デフォルト値でいい パラメータについては要求しないというものです。もう一つは、最初の DHCPDISCOVERまたはDHCPREQUESTにおいてクライアントが要求するパラメータ のリストをサーバに送付する方式です。クライアントがDHCPDISCOVERにパラメ ータリストを添付していた場合、後続のDHCPREQUESTにもそれが含まれていな ければなりません。 クライアントは「最大DHCPメッセージサイズ」オプションによってサーバが生 成できる最大のDHCPメッセージのサイズを規定すべきです。クライアントに返 答すべきオプションのサイズだけでもこのサイズを越えてしまうかもしれませ ん。その場合はオプションフラグ（「オプション」にある）によって「ブート ファイル名」と「サーバファイル名」を追加の「オプション」として使用でき るようにします。 クライアントは「要求パラメータリスト」オプションによって大事なコンフィ グレーション情報をサーバに通知することができます。このリストはその大事 なオプションのタグ番号からなっています。 クライアントはDHCPDISCOVERで、「要求IPアドレス」オプションで特定のIPア ドレスを、「リース期間」オプションでリース期間を指定してもかまいません。 その他のオプションもDHCPDISCOVERやDHCPREQUESTでは許されていますが、サ ーバはそれらのオプションを無視してもかまわないし、またいくつかのオプシ ョンについて複数のサーバが同じ返答をしてもかまいません。「要求IPアドレ ス」は、クライアントがすでに割り当てられているパラメータの確認をする際 のDHCPREQUESTでのみ使用されます。「クライアントIPアドレス」は、「リー ス」、「延長」、「再割り当て」の各状態で、IPアドレスが正当に割り当てら れている場合にのみ使用されます。 不正な「要求IPアドレス」を持つDHCPREQUESTを受信したサーバは、DHCPNAKで 応答すべきですし、またシステム管理者にレポートしてもかまいません。サー バは「メッセージ」オプションを使用してエラーメッセージを通知してもかま いません。 3.6 複数のインタフェースを持つクライアントの運用 複数のネットワークインタフェースを持つクライアントは、個々のインタフェ ースごとのコンフィグレーション情報を得るために、独立してDHCPにアクセス しなければなりません。 3.7 クライアントがDHCPを使用すべき場合 クライアントは、ネットワークパラメータに変動があった際、例えばシステム のリブート、ネットワークに再接続された時などにシステムやユーザによらず にネットワークのコンフィグレーションが変更されてしまった場合には、IPア ドレスの確認あるいは新しいアドレスを知るためにDHCPを使用すべきです。 クライアントが先に割り当てられたネットワークアドレスを覚えていて、サー バにアクセスできなくなった場合、クライアントはリース期間が終了するまで はそのアドレスを使用してもかまいません。クライアントがサーバにアクセス できるまでにリース期間が終了した場合は、直ちにアドレスの使用をやめなけ ればなりません。またその場合ユーザに問題が発生したことを通知してもかま いません。 4. DHCPプロトコル定義 この章では、DHCPはアドレスの要求に応えて割り当てるべきネットワークアド レスを保持し、それらの割り当て状況やリース期間を管理しているものとしま す。 4.1 DHCPメッセージの生成と送信 クライアントとサーバは固定長のフィールドとオプションデータを組み合わせ てDHCPメッセージを生成します。「オプション」の最初の4オクテットは "magic cookie"であり、その後ろに実際のオプションが続きます。「オプショ ン」の最後は必ず「終了」オプションでなければなりません。 DHCPはUDPプロトコルを用い、クライアントからサーバに送信する際はDHCPサ ーバポート（67）に、サーバからクライアントに送信する際はDHCPクライアン トポート（68）に送信します。複数のネットワークアドレスを持つサーバは送 出するDHCPメッセージのネットワークアドレスとして、どのアドレスを使用し てもかまいません。 「サーバID」は、DHCPメッセージ中でサーバの識別とクライアントからサーバ にメッセージが送信される際の宛先として使用されます。複数のネットワーク アドレスを持つサーバは、DHCPメッセージ中で、複数のネットワークアドレス のうちのいずれのアドレスを指定されても受信できなくてはなりません。ネッ トワークの接続に問題があるかもしれないことを考え、サーバはクライアント から見て最も確実に接続できると考えられるアドレスを「サーバID」として選 択しなければなりません。例えば、サーバとクライアントが同一のサブネット に接続されている場合（すなわち、クライアントからのメッセージの「ゲート ウェイIPアドレス」が0の場合）、サーバは「サーバID」として、そのサブネ ットでの通信に使用しているIPアドレスを設定すべきです。サーバがそのサブ ネットで複数のIPアドレスを使用している場合は、どのアドレスを設定しても かまいません。サーバがリレイエージェントからのメッセージを受信した場合、 （サーバが別のアドレスを設定すべきであるとする根拠がないかぎり）サーバ はそのメッセージを受信したインタフェースのアドレスを「サーバID」として 選択すべきです。クライアントはサーバへのダイレクトな通信の宛先として「 サーバID」を使用しなければなりません。 クライアントが最初にブロードキャストするDHCPメッセージのソースIPアドレ スは'0'でなければなりません。 クライアントからのDHCPメッセージの「ゲートウェイIPアドレス」に値が設定 されている場合は、サーバは「ゲートウェイIPアドレス」を持つリレイエージ ェントのDHCPサーバポートに送信します。「ゲートウェイIPアドレス」が'0' で「クライアントIPアドレス」が'0'でない場合は、サーバはDHCPOFFERメッセ ージとDHCPACKを「クライアントIPアドレス」にダイレクトに送信します。「 ゲートウェイIPアドレス」と「クライアントIPアドレス」の双方が'0'で「ブ ロードキャストビット」が立っている場合は、サーバはDHCPOFFERとDHCPACKを 0xffffffffにブロードキャストします。もし「ブロードキャストビット」が立 っておらず、「ゲートウェイIPアドレス」と「クライアントIPアドレス」の双 方が'0'の場合は、サーバはDHCPOFFERとDHCPACKをクライアントのハードウェ アアドレスと「割り当てIPアドレス」を指定してダイレクトに送信します。全 ての場合で、「ゲートウェイIPアドレス」が'0'の場合、サーバはDHCPNAKを 0xffffffffにブロードキャストします。 DHCPメッセージの「オプション」が「サーバ名」や「ブートファイル名」のフ ィールドにまで拡張されている場合、RFC1533にあるように、1,2または3の値 を持った「オプション拡張」オプションが「オプション」になければなりませ ん。「オプション」が拡張された場合、オプションは「終了」オプションで終 わっていなければなりません。また、「オプション」の余った領域を埋めるた めに、「埋め草」オプションを使用してもかまいません。（「オプション拡張」 オプションによる拡張が行われた場合）「サーバ名」や「ブートファイル名」 はそのフィールドの先頭から使用され、「終了」オプションで終了し、残りの 領域は「埋め草」オプションで埋められていなければなりません。「オプショ ン」、「サーバ名」、「ブートファイル名」の各々のフィールドにあるオプシ ョンはそのフィールド内に閉じていなければなりません（訳者注：一つのオプ ションが、分割されて複数のフィールドにまたがって定義されてはいけない、 ということ）。オプションの解釈は「オプション」フィールドが必ず優先され、 その後に他のフィールドが解釈されなければなりませんが、残りのフィールド のうち「ブートファイル名」フィールドが優先され、最後が「サーバ名」フィ ールドとなります。 （「ルータ」オプションにあるルータリストのように）オプションのデータが 長くてタグで表現できる255オクテットを超えることはあるかもしれません。 オプションの定義で規定されている場合を除き、あるオプションは一度だけし か出てこないことになっています。クライアントは「オプション」の複数のパ ラメータ定義をまとめてコンフィグレーションのためのパラメータリストにし ます。 クライアントにはメッセージの再送機能がなければなりません。この再送機能 には再送間の時間をランダムな2の累乗で変化させることのできる機能が組み 込まれていなければなりません。送信の間隔は、クライアント・サーバ間のネ ットワークの特性に応じて応答に十分な時間を選択すべきです。例えば、10M イーサでは最初の再送までの待ち時間は4秒に-1から+1までのランダムな数字 を加えた時間とすべきです。1秒以下の精度の時間を利用できるクライアント は非整数の値を利用してかまいません。その次の再送までの待ち時間は8秒に- 1から+1までのランダムな数字を加えた時間とすべきです。再送間隔は最大64 秒まで再送ごとに倍にしてゆくべきです。クライアントはユーザに初期化の進 み具合を知らせるために再送していることを知らせてもかまいません。 クライアントは「トランザクションID」により要求に対する応答を識別します。 クライアントは、他のクライアントがつける「トランザクションID」と重複す ることのないように自らの「トランザクションID」を選択しなければなりませ ん。たとえば、クライアントはリブート毎にランダムで異る「トランザクショ ンID」を選択し、次のリブートまでは順次カウントアップした「トランザクシ ョンID」を付けてもかまいません。再送毎に「トランザクションID」を新たに するかどうかは実装に依存します。クライアントは再送メッセージに前のメッ セージと同じ「トランザクションID」を使用してもいいし、新しい「トランザ クションID」を付けてもかまいません。通常、サーバやリレイエージェントは DHCPOFFER、DHCPACK、DHCPNAKをクライアントにダイレクトに送信しようとし ます。「受信者IPアドレス」は「割り当てIPアドレス」と同じ値に設定され、 イーサアドレスはクライアントハードウェアアドレスと同じに設定されます。 しかしながら、クライアントの実装によっては、適切なコンフィグレーション が終了するまでそのようなユニキャストパケットを受信できない場合がありま す（あるIPアドレスによるコンフィグレーションが行なわれるまでは、そのIP アドレス宛のパケットを受信できないというデッドロックに陥ってしまうため）。 IPアドレスによるコンフィグレーションが行なわれなければ、そのIPアドレス 宛のパケットが受信できないようなクライアントは、送信するDHCPDISCOVERや DHCPREQUESTの「ブロードキャストフラグ」を'1'に設定すべきです。「ブロー ドキャストフラグ」によってサーバやリレイエージェントに、クライアントに はブロードキャストしか受信できないことを知らせることができます。そうで ないクライアントは「ブロードキャストフラグ」は'0'にしておくべきです。 「ブロードキャストフラグ」を使用する場合のBOOTPとの関係については、関 連文書[21]にまとめてあります。 DHCPメッセージをクライアントに直接送信するサーバやリレイエージェント（ すなわち「リレイエージェントIPアドレス」にあるリレイエージェントに送信 する場合以外）は「ブロードキャストフラグ」をチェックすべきです。もし「 ブロードキャストフラグ」が立っていればDHCPメッセージはブロードキャスト （受信者IPアドレス、受信者イーサアドレスともにブロードキャストアドレス） されるべきです。「ブロードキャストフラグ」が立っていなければ「割り当て IPアドレス」と「クライアントハードウェアアドレス」宛のダイレクトメッセ ージとなるべきです。もし、ダイレクトに送信できない場合はブロードキャス トしてもかまいません。 4.2 DHCPサーバの管理 サーバは受信した全てのDHCPDISCOVERやDHCPREQUESTに応答しなければならな いわけではありません。例えば、ネットワークの管理を強化したいネットワー ク管理者の場合、DHCPを利用できるクライアントを制限してもかまいません。 DHCPでは、それを望むサーバとクライアント間の動作を規定しているのであっ て、管理者の望む全ての操作について規定しているわけではないのです。サー バの実装によっては、ネットワーク管理者の望む機能を入れてもかまいません。 場合によっては、サーバは特定のクライアントに割り当てるパラメータを 特定するためにDHCPDISCOVERやDHCPREQUESTの「ベンダクラス」オ プションをチェックしなければなりません。 サーバはクライアントと通信する際に、幾つかの一意な識別子を用いる必要が あります。クライアントは「クライアントID」オプションを用いて識別子を渡 すことができます。クライアントが「クライアントID」オプションを用いた場 合は、その後の全てのメッセージで同じ「クライアントID」を用いなければな りませんし、サーバはその「クライアントID」をもってクライアントを識別し なければなりません。クライアントが「クライアントID」オプションを用いな かった場合は、サーバは「クライアントハードウェアアドレス」をもってクラ イアントを識別しなければなりません。クライアントにとって、「クライアン トID」として、そのクライアントが接続されているサブネットの中で一意な識 別子を選択できるかどうかは重要な問題です。クライアントの一意な識別子と して「クライアントハードウェアアドレス」を使用することは、インタフェー スボードが別のクライアントに移植されてしまった場合などに予期せぬ問題を 引き起こすかもしれません。このようなインタフェースボードの移植によるク ライアントのネットワークアドレスの変更を避けるために、「クライアントID」 としてそのハードウェアの製造番号を使用するサイトもあります。特定のハー ドウェアよりはDNS名とリースを関連付けた方がいいとして、「クライアント ID」としてDNS名を選択してもかまいません。 クライアントはDHCPOFFERを発したサーバのどれを選ぶかは自由です。クライ アントはユーザが直接「ベンダクラスID」を指定できるように実装すべきです。 4.3 DHCPサーバの動作 サーバは、現在の状態とクライアントとの関係に応じて受信したDHCPメッセー ジを処理します。サーバはクライアントからの以下のメッセージを受信します。 ・DHCPDISCOVER ・DHCPREQUEST ・DHCPDECLINE ・DHCPRELEASE ・DHCPINFORM 表3にサーバが発するDHCPメッセージの各フィールドを説明します。以下では サーバが受信したメッセージに対してどのように振る舞うかを説明します。 4.3.1 DHCPDISCOVER サーバがクライアントからのDHCPDISCOVERを受信した場合、サーバはそのクラ イアント用のネットワークアドレスを割り当てます。もし、割り当てるべきア ドレスがない場合はシステム管理者に問題をレポートしてもかまいません。も し割り当て可能なアドレスがある場合は、以下のように選定すべきです。 ・現在クライアントに割り当てていると記録されているアドレスを ・そのクライアントに先に割り当てていたアドレスが利用可能であればそのア ドレスを ・「要求IPアドレス」オプションに指定されたアドレスが有効なもので、利用 可能であればそのアドレスを ・いずれでもない場合は割り当て可能なアドレスを。このアドレスはメッセー ジを受信したサブネット（「リレイエージェントIPアドレス」が'0'の場合） かリレイエージェントがメッセージを転送したアドレス（「リレイエージェ ントIPアドレス」が'0'ではない場合）に基づいて選択される。 サーバは4.2節にあるように、管理上の理由から、要求されたものではないア ドレスを割り当ててもいいし、割り当て可能なアドレスがあっても特定のクラ イアントからの割り当て要求を拒絶してもかまいません。 （一つのセグメントに複数のサブネットが混在するようなネットワークなど） ネットワークのアーキテクチャによっては、「リレイエージェントIPアドレス」 とは異るサブネットのアドレスがクライアントに割り当てられるべき場合があ るかもしれないことに注意してください。これにより、DHCPではクライアント に「ゲートウェイIPアドレス」と同じサブネットのアドレスを割り当てる必然 性はないことになります。サーバは他のサブネット（のアドレス）を選択する のも自由ですし、どのように割り当てられるIPアドレスが選択されるかは本書 の規定するところではありません。 サーバは、クライアントがDHCPOFFERに応答するまでは、DHCPとしての正当な 手続き無しに割り当てようとしているネットワークアドレスを（別のクライア ントに）割り当てるべきではありません。サーバはそのアドレスがクライアン トに割り当てられたと記録しておいてもかまいません。 サーバは以下のようにリース期間を定めなければなりません。 ・クライアントがDHCPDISCOVERで特にリース期間を要求せず、すでにネットワ ークアドレスの割り当てを受けている場合は、サーバは以前そのクライアン トに設定したリース期間を通知する（クライアントは、以前のリース期間よ りも長いリース期間を欲する場合は、その旨要求しなければならないことに 注意）。 ・クライアントがDHCPDISCOVERでリース期間を要求せず、またネットワークア ドレスの割り当てを受けていない場合は、サーバはローカルに設定されてい るデフォルトのリース期間を通知する。 ・クライアントがDHCPDISCOVERでリース期間を指定した場合（クライアントが ネットワークアドレスの割り当てを受けているかどうかは関係ない）、サー バは指定のリース期間を通知する（その期間で問題がない場合）か別のリー ス期間を通知する。 Field DHCPOFFER DHCPACK DHCPNAK ----- --------- ------- ------- オペレーション BOOTREPLY(2) BOOTREPLY(2) BOOTREPLY(2) コード ハードウェア番号 (From "Assigned Numbers" RFC) ハードウェア (ハードウェアアドレスの長さ、オクテット数) アドレス長 転送回数 0 0 0 トランザクションID クライアントが以下のメッセージで使用した「トランザ クションID」 DHCPDISCOVER DHCPREQUEST DHCPREQUEST 経過時間 0 0 0 クライアント 0 DHCPREQUESTの 0 IPアドレス 「クライアントIP アドレス」か'0' 割り当てIPアドレス クライアントに割 クライアントに割 0 り当てを申し出た り当てたIPアドレ IPアドレス ス サーバIPアドレス 次回使用するサー 次回使用するサー 0 バのIPアドレス バのIPアドレス フラグ クライアントが以下のメッセージで使用した「フラグ」 DHCPDISCOVER DHCPREQUEST DHCPREQUEST リレイエージェント クライアントが以下のメッセージで使用した「リレイエ IPアドレス ージェントIPアドレス」 DHCPDISCOVER DHCPREQUEST DHCPREQUEST クライアントハード クライアントが以下のメッセージで使用した「クライア ウェアアドレス ントハードウェアアドレス」 DHCPDISCOVER DHCPREQUEST DHCPREQUEST サーバ名 サーバの名前また サーバの名前また (使用しない) は「オプション」 は「オプション」 ブートファイル名 クライアントのブ クライアントのブ (使用しない) ートファイル名ま ートファイル名ま たは「オプション」 たは「オプション」 オプション オプション オプション オプション DHCPOFFER DHCPACK DHCPNAK ---------- --------- ------- ------- 要求IPアドレス × × × リース期間 ◎ ◎(DHCPREQUEST) × ×(DHCPINFORM) オプション拡張 △ △ × DHCPメッセージタイプ DHCPOFFER DHCPACK DHCPNAK 要求パラメータリスト × × × コメント ○ ○ ○ クライアントID × × △ ベンダクラスID △ △ △ サーバID ◎ ◎ ◎ 最大メッセージ長 × × × その他 △ △ × ◎:必須（MUST）、○:要（SHOULD）、△:可（MAY）、×:不可（MUST NOT） 表 3: サーバからのDHCPメッセージのパラメータ ネットワークアドレスとリースの内容が決ってしまえば、サーバはコンフィグ レーション情報をもとにDHCPOFFERを作成することができます。全てのサーバ にとって、クライアントがどのサーバを選択してもその動作が変わらなくてす むように、（ネットワークアドレスが変わる場合を除き）同じコンフィグレー ション情報を返答することが重要です。コンフィグレーション情報は以下の条 件を満たすように選択されなければなりません。ネットワーク管理者は、全て のサーバが同一の返答をするように設定すべきです。 ・サーバは先に定めたルールにしたがい決定されたネットワークアドレスを通 知しなければならない。 ・サーバは先に定めたルールにしたがい決定されたリース期間をクライアント に通知しなければならない。 ・サーバは次のルールにしたがい、要求されたパラメータを通知しなければな らない。 - サーバにそのパラメータに関する設定があれば、その設定を返さなければ ならない。 - サーバが、そのパラメータがHost Requirements Documentで定義されるパ ラメータであると認識すれば、Host Requirements Documentでのデフォル ト値を返さなければならない。 - 上記以外の場合は、サーバはパラメータを返答してはならない。 サーバは要求されたパラメータのうち可能なかぎり多くを提供しなければな らないし、提供できないものは省略しなければならない。サーバは、DHCPの オプションとBOOTPのベンダ拡張部に関する文書で特に規定されている場合 を除き、一つのパラメータは一度だけ記述して提供しなければならない。 ・サーバは、Host Requirements Documentでのデフォルトとは異っても、既存 のリースで使用されているパラメータの値を通知しなければならない。 ・サーバは（DHCPDISCOVERやDHCPREQUESTにある「クライアントハードウェア アドレス」または「クライアントID」から識別した）そのクライアントに特 有のパラメータを返さなければならない。すなわち、ネットワーク管理者に よって設定された値である。 ・サーバは（DHCPDISCOVERやDHCPREQUESTにある「ベンダクラスID」から識別 した）そのクライアントが属するクラスに特有のパラメータを返さなければ ならない。すなわち、ネットワーク管理者によって設定された値である。な お、クライアントが送信した「ベンダクラスID」とサーバが保持する「ベン ダクラスID」が厳密に一致した場合のみとする。 ・サーバはクライアントのサブネットでのデフォルト値と違う値を持つパラメ ータを通知しなければならない。 サーバは、クライアントがどのDHCPOFFERを選択するかの参考になるように DHCPOFFERの中にパラメータを決定するのに使用された「ベンダクラスID」を 入れてもかまいません。サーバはDHCPDISCOVERの「トランザクションID」を DHCPOFFERでもそのまま使用してクライアントにメッセージを送信します。 4.3.2 DHCPREQUEST DHCPREQUESTは、クライアントからDHCPOFFERへの返答として、または先に割り 当てられたIPアドレスの再割り当ての際に、あるいはクライアントがリースを 延長する際に送信されます。もし、DHCPREQUESTに「サーバID」が含まれてい る場合は、そのメッセージはDHCPOFFERへの返答です。そうでないメッセージ はリースの確認や延長の要求です。クライアントがDHCPREQUESTで「クライア ントID」を使用した場合、そのクライアントはその後の全てのメッセージで同 じ「クライアントID」を使用しなければなりません。クライアントが DHCPDISCOVERで「要求パラメータリスト」を使用した場合、そのクライアント はやはりその後の全てのメッセージに「要求パラメータリスト」を含めなけれ ばなりません。 DHCPACKに含まれるパラメータは、それに先立つDHCPOFFERに含まれるパラメー タと矛盾すべきではありません。クライアントはDHCPACKに含まれるパラメー タをコンフィグレーションに使用すべきです。 クライアントは以下の要領でDHCPREQUESTを送信します。 ・「選択中」状態中に作成するDHCPREQUEST クライアントは「サーバID」に選択したサーバのアドレスを、「クライアン トIPアドレス」を'0'を、「要求IPアドレス」にサーバからのDHCPOFFERにあ った「割り当てIPアドレス」を設定しなければならない。 ここで、クライアントは複数のサーバからのDHCPOFFERを受信し、その中で 最も適切と思われるものを選んでかまわないのである。クライアントは自分 の選択をDHCPREQUESTによりサーバに通知する。クライアントが適切な申し 出を得られなかった場合は、再度DHCPDISCOVERを送信してサーバを募る。し たがって、サーバはクライアントが自分の申し出を受諾したかどうかを判断 するためのDHCPREQUESTを得られないこともある。サーバはDHCPOFFERの発行 によってネットワークアドレスを割り当てるわけではないので、別の要求に 対してそのネットワークアドレスを割り当ててしまってもかまわない。実装 としては、サーバは申し出たネットワークアドレスをすぐ他のクライアント に割り当てることはすべきではないが、何らかのタイムアウトを設けてその 後に再利用することはかまわない。 ・「再/初期化」状態中に作成するDHCPREQUEST 「サーバID」は設定してはいけないが、「要求IPアドレス」オプションには クライアントが先に割り当てられていたアドレスが設定されなければならな い。「クライアントIPアドレス」は'0'でなければならない。クライアント は先に割り当てられ、保存されている設定情報の確認を行う。サーバは「要 求IPアドレス」が不正であるか、誤ったネットワークのものであった場合に は、クライアントにDHCPNAKを送信すべきである。 「再/初期化」状態にあるクライアントが正しいネットワークに接続されて いるかどうかは、「リレイエージェントIPアドレス」と「要求IPアドレス」、 それにデータベースの検索によりチェックする。サーバが、クライアントが 誤ったネットワークに接続されていると判断した場合（すなわち、ローカル サブネットマスクかリモートサブネットマスク（「リレイエージェントIPア ドレス」が'0'でない場合）が「要求IPアドレス」と不整合を起こした場合）、 サーバはクライアントにDHCPNAKを送信すべきである。 クライアントが正しいネットワークに接続されている場合、サーバはクライ アントが要求するIPアドレスが正しいものかどうかをチェックすべきである。 もし不正なものであるならば、サーバはクライアントにDHCPNAKを送信すべ きである。サーバに、そのクライアントについての情報が登録されていない 場合、サーバは応答してはいけない。また、ネットワーク管理者に警告メッ セージを表示してかまわない。これは、同一ネットワーク上に協調動作して いないサーバがあった場合の共存のために必要な動作である。 DHCPREQUESTの「リレイエージェントIPアドレス」が'0'の場合、クライアン トはサーバと同一のネットワークに接続されている。サーバは、クライアン トが正しいネットワークアドレスやサブネットマスクを持っていないかもし れないし、ARPにも応答できないかもしれないので、0xffffffffにDHCPNAKを ブロードキャストしなければならない。 DHCPREQUESTの「リレイエージェントIPアドレス」が'0'ではない場合、クラ イアントはサーバと違うネットワークに接続されている。クライアントが正 しいネットワークアドレスやサブネットマスクを持っていないかもしれない し、ARPにも応答できないかもしれないので、サーバはDHCPNAKの「ブロード キャストビット」を立てなければならない。それによりリレイエージェント はリモートネットワークでDHCPNAKをブロードキャストする。 ・「延長」状態中に作成するDHCPREQUEST 「サーバID」は設定されてはならない。「要求IPアドレス」オプションも設 定されてはならない。「クライアントIPアドレス」にはクライアントのIPア ドレスが設定されていなければならない。この状態ではクライアントは正し くコンフィグレーションされ、リースを延長しようとしている。このメッセ ージはダイレクトに送信されるため、リレイエージェントが関与することは ない。「リレイエージェントIPアドレス」が設定されることもないので、サ ーバは「クライアントIPアドレス」を正しいものとし、そこ宛に返答する。 クライアントはT1になる前にリースを延長してもいい。サーバは（ネットワ ーク管理者のポリシーに従い）リースの延長を拒否してもいいが、どちらに しろDHCPACKを返答すべきである。（訳者註:この文、文法的に意味を通せば 技術的に問題があり、技術的に意味を通せば文法としてはおかしなものにな る。誤記か？） ・「再割り当て」状態中に作成するDHCPREQUEST 「サーバID」は設定されてはならない。「要求IPアドレス」オプションも設 定されてはならない。「クライアントIPアドレス」にはクライアントのIPア ドレスが設定されていなければならない。この状態ではクライアントは正し くコンフィグレーションされ、リースの再割り当てをしようとしている。こ のメッセージは0xffffffffにブロードキャストされなければならない。サー バはDHCPREQUESTに返答する前に、正確を期して「クライアントIPアドレス」 をチェックすべきである。 「再割り当て」中のクライアントからのDHCPREQUESTは複数のサーバを持つ サイトにおける調整と、複数のサーバ間でのリースの整合性をとることを意 図して行われる。サーバはクライアントのリースの再割り当てを行う際は、 （そのクライアントまたはリースに関する）管理権限を持っている場合にの み行うのが好ましい。 4.3.3 DHCPDECLINE サーバがDHCPDECLINEを受信した場合、クライアントが何らかの方法でそのネ ットワークアドレスがすでに使用されていることを発見したことを意味してい ます。サーバはそのネットワークアドレスが割り当てできないようにしなけれ ばなりません。またシステム管理者に問題が発生したことを通知すべきです。 4.3.4 DHCPRELEASE DHCPRELEASEを受信したサーバは、対応するネットワークアドレスを割り当て られていない状態に戻します。サーバはそのクライアントからの次回の要求に 応えるために、そのクライアントのパラメータ設定を記録しておくべきです。 4.3.5 DHCPINFORM サーバは、DHCPINFORMの「クライアントIPアドレス」にダイレクトにDHCPACK を送付することをもって、DHCPINFORMへの返答とします。サーバは、リース期 間をクライアントに教えてはいけないし、「割り当てIPアドレス」を教えるべ きでもありません。サーバは、その他の4.3.1節にある、DHCPACKで返答したパ ラメータを通知します。 4.3.6 クライアントからのメッセージ 表4は、各々の状態にあるクライアントからのメッセージの相違一覧です。 -------------------------------------------------------------------- | |再/初期化 |選択中 |延長 |更新 | -------------------------------------------------------------------- |宛先 |ブロード |ブロード |ダイレクト |ブロード | | | キャスト | キャスト |ダイレクト | キャスト | |サーバ |不要 |必須 |不要 |不要 | | IPアドレス | | | | | |要求IPアドレス|必須 |必須 |不要 |不要 | |クライアント |'0' |'0' |IPアドレス |IPアドレス | | IPアドレス | | | | | -------------------------------------------------------------------- Table 4: 各状態にあるクライアントからのメッセージ 4.4 DHCPクライアントの動作 クライアントの状態遷移を図5に示します。クライアントはサーバからの次の メッセージを受信します。 ・DHCPOFFER ・DHCPACK ・DHCPNAK 図5にはDHCPINFORMは示されていません。クライアントは、単にDHCPINFORMを 送付し、DHCPACKを待つだけです。一旦クライアントがパラメータを選択すれ ば、それでコンフィグレーションは終了したことになります。 表5にクライアントが発するDHCPメッセージの各フィールドの説明を示します。 以下ではクライアントが受信したメッセージに対してどのように振る舞うかを 説明します。なお、詳細説明は3.1節の状況に、その後の説明は3.2節の状況に 相当します。 -------- ------- | | +-------------------------->| |<-------------------+ |再/初 | | +-------------------->|初期化 | | | 期化 |DHCPNAK/ +---------->| |<---+ | | |再起動 | | ------- | | -------- | DHCPNAK/ | | | | | 提案の破棄 | -/DHCPDISCOVER 送信 | -/DHCPREQUEST 送信 | | | | | | DHCPACK v | | ----------- | (受信せず)/ ----------- | | | | | DHCPDECLINE 送信 | | | |再初期化 | | | | 選択中 |<----+ | | | | / | | |DHCPOFFER/ | ----------- | / ----------- | |応答の収集 | | | / | | | | DHCPACK/ | / +----------------+ +-------+ | リースの記録、 | | v 提案を選択/ | T1,T2の設定 ------------ DHCPREQUEST 送信 | | | +----->| | DHCPNAK, リース切れ/ | | | | 応答待ち | ネットワークの停止 | DHCPOFFER/ | | | | | 破棄 ------------ | | | | | | ----------- | | +--------+ DHCPACK/ | | | | リースの記録、 -----|再割り当て | | | T1,T2の設定 / | | | | | DHCPACK/ ----------- | | v リースの記録、 ^ | +----------------> ------- / T1,T2の設定 | | +----->| |<---+ | | | |リース |<---+ | | DHCPOFFER, DHCPACK, | | | T2 時間切れ/ DHCPNAK/ DHCPNAK/破棄 ------- | DHCPREQUEST の ネットワークの | | | | ブロードキャスト 停止 +-------+ | DHCPACK/ | | T1 時間切れ/ リースの記録、 | | リース元サーバへの T1,T2の設定 | | DHCPREQUEST 送信 | | | | ---------- | | | | |------------+ | +->|リース延長| | | |----------------------------+ ---------- 図 5: クライアントの状態遷移図 （"/"の前がサーバの動作、後がクライアントの動作） 4.4.1 初期化とネットワークアドレスの割り当て クライアントの状態は「初期化」状態からはじまり、DHCPDISCOVERを生成しま す。クライアントはブート時には衝突を避けるために1〜10秒、ランダムにウ ェイトをいれるべきです。クライアントは「クライアントIPアドレス」を "0x00000000"に設定します。クライアントは「パラメータ要求リスト」オプシ ョンにより特定のパラメータを要求してもかまいません。また「要求IPアドレ ス」オプションや「リース期間」オプションによって特定のネットワークアド レスやリース期間を要求してもかまいません。クライアントは、応答が必要な 場合は「クライアントハードウェアアドレス」に自分のハードウェアアドレス を設定しなければなりません。クライアントは、4.2節に述べたように、「ク ライアントID」オプションに自分を一意に識別する識別子を設定してもかまい ません。クライアントがDHCPDISCOVERに「要求パラメータリスト」オプション を使用した場合、その後の全てのメッセージにリストを含めなければなりませ ん。 クライアントはランダムな番号を生成し、「トランザクションID」に設定しま す。クライアントはリース期限の計算のために現在の時間を記録しておきます。 その後、クライアントはDHCPDISCOVERをDHCPサーバポートにブロードキャスト します。 受信したDHCPOFFERの「トランザクションID」が、最後に送出した DHCPDISCOVERのそれと一致しなかった場合は、DHCPOFFERは破棄されます。ま たDHCPACKも破棄されます。 クライアントは一定時間DHCPOFFERを収集し、それを参考に（例えば、最初の メッセージであるとか以前アクセスしたサーバからのメッセージ）サーバを選 択し、「サーバID」オプションからサーバアドレスを抜き出します。クライア ントがメッセージを収集する時間やサーバを選択する方法は実装に依存します。 Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE, DHCPRELEASE ----- ------------ ----------- ----------- オペレーション BOOTREQUEST(1) BOOTREQUEST(1) BOOTREQUEST(1) コード ハードウェア番号 (From "Assigned Numbers" RFC) ハードウェア (ハードウェアアドレスの長さ、オクテット数) アドレス長 転送回数 0 0 0 トランザクションID クライアントが設 クライアントが クライアント 定する DHCPOFFERで使用 が設定する した「トランザ クションID」 経過時間 '0'またはDHCP使 '0'またはDHCP使 0 用開始からの秒数 用開始からの秒数 フラグ ブロードキャスト ブロードキャスト 0 を要求する場合は を要求する場合は 「ブロードキャス 「ブロードキャス トビット」を立て トビット」を立て る る クライアント 0(DHCPDISCOVER) '0'またはクライ '0'(DHCPDECLINE) IPアドレス クライアントのア アントのアドレス クライアントの ドレス(DHCPINFORM) (「リース」「延 アドレス 長」「再割り当 (DHCPRELEASE) て」状態) 割り当てIPアドレス 0 0 0 サーバIPアドレス 0 0 0 リレイエージェント 0 0 0 IPアドレス クライアントハード クライアントのハードウェアアドレス ウェアアドレス サーバ名 「オプション」ま 「オプション」ま (使用しない) たは使用しない たは使用しない ブートファイル名 「オプション」ま 「オプション」ま (使用しない) たは使用しない たは使用しない オプション オプション オプション (使用しない) オプション DHCPDISCOVER DHCPREQUEST DHCPDECLINE, DHCPINFORM DHCPRELEASE ---------- --------- ------- ------- 要求IPアドレス △(DHCPDISCOVER) ◎（「選択中」 ◎(DHCPDECLINE) ×(DHCPINFORM) または「再/初 ×(DHCPRELEASE) 期化」状態） ×（「リース」 または「延長 」状態） リース期間 △(DHCPDISCOVER) △ × ×(DHCPINFORM) オプション拡張 △ △ △ DHCPメッセージタイプ DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/ DHCPINFORM DHCPRELEASE クライアントID △ △ △ ベンダクラスID △ △ × サーバID × ◎（「選択中」 ◎ 状態以後） ×（その他の状 態以後） 要求パラメータリスト △ △ × 最大メッセージ長 △ △ × コメント − − ○ サイトローカル情報 △ △ × その他 △ △ × ◎:必須（MUST）、○:要（SHOULD）、△:可（MAY）、−:不要（SHOULD NOT）、 ×:不可（MUST NOT） 表 5: クライアントからのDHCPメッセージのパラメータ パラメータに問題がなければ、クライアントは「サーバID」からサーバのアド レスを抜き出して記録し、そのサーバにDHCPREQUESTをブロードキャストしま す。サーバからのDHCPACKを受信すると、クライアントは初期化を終了し「リ ース」状態へ移行します。DHCPREQUESTにはDHCPOFFERと同じトランザクション IDが入っていなければなりません。クライアントは最初に要求を出した時から 起算してリース期間分を経た時間をリース終了時間として記録しておきます。 クライアントは、割り当てられたアドレスが使用中でないかどうかチェックす べきです。例えば、クライアントがARPが使えるネットワークに接続されてい る場合、クライアントは割り当てられたアドレスに対してARPrequestを発行し てかまいません。割り当てられたアドレスに対してARPrequestを発行する場合、 そのサブネットに接続されている他のホストのARPキャッシュを混乱させない ように、クライアントは発行者のハードウェアアドレスとして自らのハードウ ェアアドレスを設定し、発行者のIPアドレスには'0'を設定しなければなりま せん。割り当てられたアドレスが使用されていた場合、クライアントはサーバ にDHCPDECLINEを送信しなければなりません。クライアントは新しいIPアドレ スを得たことを示すためにARPreplyをブロードキャストし、他のホストのARP キャッシュを更新すべきです。 4.4.2 ネットワークアドレスを保持しての初期化 クライアントは「再/初期化」状態からスタートし、DHCPREQUESTを送信する。 クライアントはDHCPREQUESTの「要求IPアドレス」オプションに先に割り当て られたネットワークアドレスを入れて送信しなければなりません。クライアン トは「パラメータ要求リスト」オプションにより特定のパラメータを要求して もかまいません。クライアントはランダムな番号を生成し、「トランザクショ ンID」にします。クライアントはリース終了時間を計算するために、ローカル な時間を記録しておきます。クライアントはDHCPREQUESTに「サーバID」を入 れてはいけません。これらの後にクライアントはDHCPサーバポートに DHCPREQUESTをブロードキャストします。 クライアントが発行したDHCPREQUESTと同じ「トランザクションID」を持つ DHCPACKを受信したら、その発行サーバがどれであれクライアントは初期化を 終了し「リース」状態へ移行します。クライアントは最初に要求を出した時か ら起算してリース期間分を経た時間をリース終了時間として記録しておきます。 4.4.3 DHCP外で割り当てられたアドレスを保持しての初期化 クライアントはDHCPINFORMを送信しますが、その際、「要求パラメータリスト」 オプションで幾つかのパラメータを要求してもかまいません。「トランザクシ ョンID」にはランダムな番号を設定します。また「クライアントIPアドレス」 にはクライアントのIPアドレスを設定します。クライアントはリース期間を要 求すべきではありません。 クライアントは、サーバのアドレスを知っている場合はDHCPINFORMをダイレク トに送信しますが、そうでない場合は（0xffffffffに）ブロードキャストしま す。DHCPINFORMはDHCPサーバポート宛に送信されなければなりません。 サーバから、クライアントが送信したDHCPINFORMの「トランザクションID」と 同じ「トランザクションID」を持つDHCPACKが到着すれば、クライアントの初 期化は完了です。 一定時間（60秒、もしくは4.1節のタイムアウト4回分）待ってもサーバから DHCPACKが戻ってこない場合は、ユーザにこの問題を知らせるメッセージを表 示すべきですし、付録Aにあるような適切なデフォルト値で初期化を開始すべ きです。 4.4.4 ブロードキャストとダイレクト送信 クライアントは、サーバのアドレスを知らない場合、DHCPDISCOVER、 DHCPREQUEST、およびDHCPINFORMをブロードキャストします。クライアントは DHCPRELEASEをダイレクトにサーバに送信します。DHCPDECLINEは、クライアン トが割り当てられたアドレスの使用を拒否するので、ブロードキャストされま す。 クライアントがサーバのアドレスを知っている場合、状態が「初期化」、「リ ブート」のいずれであっても、クライアントはDHCPDISCOVERやDHCPREQUESTで、 ブロードキャストするよりはそのアドレスにダイレクトに送信してかまいませ ん。またDHCPINFORMも既知のサーバにダイレクトに送信してもかまいません。 サーバからの応答がない場合は、通常のブロードキャストでやり直します。 4.4.5 更新とリース切れ クライアントはリースの期限として二つの時間を管理しています。T1はクライ アントが「延長」状態にはいる時間で、クライアントはアドレスを割り当てて くれたサーバにアクセスします。T2はクライアントが「再割り当て」状態には いる時間で、どのサーバにアクセスしてもかまいません。T1はT2よりも時間的 に先に来なければならず、またT2もリース切れよりは時間的に先に来なければ なりません。 時計を同期させなくともいいように、T1とT2は相対時間で表記されます[2]。 リースが開始されてからT1時間経つと、クライアントは「延長」状態にはいり、 サーバにリース延長を求めるDHCPREQUESTをダイレクトに送信します。クライ アントはネットワークアドレスをDHCPREQUESTの「クライアントIPアドレス」 に設定するとともに、リース期限切れ時間を計算するためにDHCPREQUESTを発 行した時間を記録しておきます。クライアントはDHCPREQUESTで「サーバID」 を指定してはなりません。 クライアントが送信したDHCPREQUESTの「トランザクションID」に一致しない 「トランザクションID」を持つDHCPACKを受信しても、破棄されます。サーバ からのDHCPACKを受信したクライアントはDHCPREQUESTを出した時から起算して DHCPACKの「リース期間」分を経た時間をリース終了時間として記録しておき ます。ネットワークアドレスの割り当てを受けたクライアントは「リース」状 態に戻ります。 リース開始からT2時間経ってもDHCPACKが受信できなかった場合、クライアン トは「再割り当て」状態に移行し、リースを更新すべくDHCPREQUESTをブロー ドキャストします。クライアントはDHCPREQUESTメッセージの「クライアント IPアドレス」に現在使用しているネットワークアドレスを設定しますが、「サ ーバID」は指定してはいけません。 T1とT2はオプションによってコンフィグレーション可能です。T1のデフォルト 値はリース期間の半分（0.5×リース期間）で、T2のデフォルト値はリース期 間の5/8（0.875×リース期間）です。両者とも、クライアント間での輻輳を避 けるために、このデフォルト値を前後に散らした値を取ります。 クライアントはT1に達する前にリースを更新または延長してもかまいません。 サーバは、ネットワーク管理者のポリシーにしたがって、クライアントのリー スを延長するかどうかを決めてかまいません。サーバはT1とT2を返答すべきで あり、それらの値はリースの残り時間を計算できるようにオリジナルの値から 修正されているべきです。 「延長」、「再割り当て」両方の状態において、クライアントがDHCPREQUEST への応答を受信できなかった場合、DHCPREQUESTを再送するまでに最低でも60 秒間、最大T2間での時間の半分（更新状態）または残りのリース時間の半分（ 再割り当て状態）まで待ちます。 DHCPACKを受信するまでにリース期間が終了してしまった場合、クライアント は「初期化」状態に戻り、全ての通信を中断し、初期化作業をやり直します。 ただし、ここで先に割り当てられたネットワークアドレスを指示するDHCPACK を受信した場合は元通り通信を続けるべきです。クライアントが新しいネット ワークアドレスを割り当てられた場合は、先に割り当てられたネットワークア ドレスを使用してはいけません。クライアントはこのことをユーザに通知すべ きです。 4.4.6 DHCPRELEASE クライアントがシャットダウンするなどでネットワークアドレスを必要としな くなった場合、クライアントはサーバにDHCPRELEASEを送信します。ただし、 DHCPRELEASEがなくともDHCPは問題無く運用されることに注意してください。 5. 謝辞 DHCPの開発およびドキュメンテーションにかけられた、DHCワーキンググルー プの多くのメンバーの協力に感謝します。 J Allard、Mike Carney、Dave Lapp、Fred Lien、John MendoncaらがDHCPの相 互接続性評価を取りまとめてくれたことにはとても感謝しています。 この文書をまとめるにあたってはCNRI(the Corporation for National Research Initiatives)、Bucknell University、Sun Microsystemsの協力があ ったことを記しておきます。 6. 参考文献 [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December 1983. [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 1533, Lachman Technology, Inc., Bucknell University, October 1993. [3] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989. [4] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support, STD 3, RFC 1123, USC/Information Sciences Institute, October 1989. [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol (DRARP)", Work in Progress. [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. [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford and SUN Microsystems, September 1985. [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991. [9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534, Bucknell University, October 1993. [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", RFC 903, Stanford, June 1984. [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. [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [13] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached Hosts", Work in Progress. [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981. [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, USC/Information Sciences Institute, August 1993. [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [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. [20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, June 1981. [21] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, Carnegie Mellon University, October 1993. 7. セキュリティに関する考察 DHCPはUDP/IP直上のプロトコルですが、UDP,IPともにセキュリティ不足です。 さらに、DHCPはディスクレスホストのリモートメンテナンス用のプロトコルで、 パスワードをつけたりすることは不可能ではありませんが、難しいし面倒です。 結局、現状のDHCPはかなりセキュリティ不足といえます。 オーソライズされていないDHCPサーバも簡単に立ち上げることができます。そ のようなサーバは不正なIPアドレスや重複したIPアドレス、不正なルーティン グ情報、不正なDNSサーバアドレスなど、間違った情報を送信することができ ます。一旦このような誤った情報でセットアップされてしまうと、アタッカー の侵入を許すことになります。 悪意のあるDHCPクライアントも、正常なクライアントのふりをして、正常なク ライアントに提供されるべき情報を取得することができます。リソースの動的 割り当てを行なっている場合、悪意のあるクライアントがリソースを一人占め してしまい、正常なクライアントに割り当てられないこともあり得ます。 8. 著者 Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (717) 524-1145 EMail: droms@bucknell.edu 城戸 正博（日本語訳） 日本電気株式会社 Email: kido@ccs.mt.nec.co.jp A. Host Configuration Parameters IP-layer_parameters,_per_host:_ 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 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 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 Key: MTU = Path MTU Discovery (RFC 1191, Proposed Standard) RD = Router Discovery (RFC 1256, Proposed Standard)