Dynamic Host Configuration Protocol

このページは RFC1541 翻訳者の城戸正博（NEC） <kido@ccs.mt.nec.co.jp> さんに許可を頂いて、かわさき＠千葉大 <u-suke@kawa.net> がHTML化したものです。元となったテキストは RFC1541-JP-kido から参照してください。

Network Working Group
Request for Comments: 1541
Obsoletes: 1531
Category: Standards Track

R. Droms
Bucknell University
October 1993

Dynamic Host Configuration Protocol

本書について

本RFCでは、標準化過程にあるプロトコルについて記述しており、よりよいものとするための議論や提言は大いに歓迎する。本RFCで定義するプロトコルの標準化状態については最新の「プロトコル状態集（Internet Official Protocol Standards）」を参照されたい。本書は自由に配布してかまわない。

概要

DHCPはTCP/IPネットワークにおいてマシンにコンフィグレーション情報を伝達するための仕組みである。DHCPはBOOTP[7]をベースとし、アドレスやその他のコンフィグレーション情報[19]を動的に割り当てる機能が付加されている。 DHCPはBOOTPリレイエージェント[7,23]の機能を用いることもでき、またDHCP サーバ/クライアントはBOOTPサーバ/クライアントと相互に通信可能である[9]。 RFC1531の内容に誤りがあったので、誤りを正し、RFC1541とした。

   1.  導入. . . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   1.1 関連技術. . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2 問題提起. . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3 要求事項. . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.4 用語. . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.5 目標. . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2. プロトコル要約 . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.1 コンフィグレーション情報格納場所. . . . . . . . . . . . . . .  9
   2.2 アドレスの動的割り当て. . . . . . . . . . . . . . . . . . . .  9
   3. クライアント・サーバ間プロトコル . . . . . . . . . . . . . . . 10
   3.1 クライアント・サーバ - アドレスの割り当て . . . . . . . . . . 10
   3.2 クライアント・サーバ - アドレスの再利用 . . . . . . . . . . . 13
   3.3 リース期間の取り扱い. . . . . . . . . . . . . . . . . . . . . 15
   3.4 ホストパラメータ. . . . . . . . . . . . . . . . . . . . . . . 15
   3.5 複数のインタフェースを持つクライアントの運用. . . . . . . . . 16
   3.6 クライアントがDHCPを使用すべき場合. . . . . . . . . . . . . . 16
   4. DHCPプロトコル定義 . . . . . . . . . . . . . . . . . . . . . . 16
   4.1 DHCPメッセージの生成と送信. . . . . . . . . . . . . . . . . . 17
   4.2 DHCPサーバの管理. . . . . . . . . . . . . . . . . . . . . . . 18
   4.3 DHCPサーバの動作. . . . . . . . . . . . . . . . . . . . . . . 19
   4.3.1 DHCPDISCOVERメッセージ. . . . . . . . . . . . . . . . . . . 19
   4.3.2 DHCPREQUESTメッセージ . . . . . . . . . . . . . . . . . . . 22
   4.3.3 DHCPDECLINEメッセージ . . . . . . . . . . . . . . . . . . . 23
   4.3.4 DHCPRELEASEメッセージ . . . . . . . . . . . . . . . . . . . 23
   4.4 DHCPクライアントの動作. . . . . . . . . . . . . . . . . . . . 23
   4.4.1 初期化とネットワークアドレスの割り当て. . . . . . . . . . . 24
   4.4.2 既知のネットワークアドレスによる初期化. . . . . . . . . . . 27
   4.4.3 既知のDHCPサーバによる初期化. . . . . . . . . . . . . . . . 28
   4.4.4 更新と期限切れ. . . . . . . . . . . . . . . . . . . . . . . 28
   4.4.5 DHCPRELEASEメッセージ . . . . . . . . . . . . . . . . . . . 29
   5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 29
   6. 参考 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
   7. セキュリティに関する考察 . . . . . . . . . . . . . . . . . . . 31
   8. 著者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   A. ホストコンフィグレーションパラメータ . . . . . . . . . . . . . 33

図一覧

   1. DHCPフォーマット . . . . . . . . . . . . . . . . . . . . . . .  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. 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(Dynamic Host Configuration Protocol)はインターネットに接続されたホストにコンフィグレーションパラメータを与えるための仕組みです。DHCPは二つの機構からなりたっています。すなわち、ホストに依存するコンフィグレーションパラメータを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,23]を利用することができ、またDHCPサーバとBOOTPクライアントが共存することもできます。BOOTPリレイエージェントがあれば、個々のネットワークセグメントにDHCPサーバがなくともDHCPを運用することができます。

1.1 関連技術

動的ホストコンフィグレーションを解決するための仕組みやプロトコルはこれまでにもいくつかありました。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]。 Comer と Droms はARP(Address Resolution Protocol)をリソースのロケーションと選択情報を転送するために使用することを提案しています[6]。最後に、 Host Requirements RFC[3,4]でホストの再コンフィグレーションに対する要求とディスクレスホストの初期化に対する提案が行なわれています。

1.2 問題提起

DHCPはHost Requirements RFCで規定されるコンフィグレーションパラメータをホストに提供するために作られました。DHCPによりパラメータを受け取った後はホストは自由に通信できるようになります。DHCPにより提供されるパラメータを付録Aに示します。

初期化されるホストがこれら全てのパラメータを必要な訳ではありません。クライアントとサーバはクライアントやサブネットによって必要となるパラメータのみを送信するよう打ち合せるべきです。

DHCPでは、IPに直接関係の無いパラメータのコンフィグレーションも可能です。 DHCPはまた新規ホストをDNS(Domain Name System)[12,13]に登録することはありません。

DHCPはルータのコンフィグレーションに使用すべきではありません。

1.3 要求事項

本書で使用される表現についての規定。日本語訳の段階で意味を織り込んであるので省略する。

1.4 用語

本書で使用される用語についての規定。日本語訳の段階で意味を織り込んであるので省略する。

1.5 目標

DHCPの目標は以下の通りである。

DHCPはポリシーと言うよりは機構であるべきである。DHCPではローカルな管理者がパラメータを自由にコンフィグレーション可能でなくてはならない。すなわち、ローカルな管理者がローカルな運用ポリシーを堅持できるべきである。
ホストは手動コンフィグレーションされるべきではない。各ホストはユーザの介入無しに適切なコンフィグレーション情報を見つけるべきである。
ネットワークは各ホストに対して手動コンフィグレーションを要求すべきではない。通常の状態では、ネットワーク管理者は各ホストのコンフィグレーションに介入すべきではない。
DHCPのサーバは各サブネットにあるべきではない。規模的あるいは経済的観点から、DHCPはBOOTP/DHCPリレイエージェントを用い、ルータを越えて動作すべきである。
DHCPクライアントは要求に対する複数の回答があることを想定していなければならない。実装によっては、複数の重複するコンフィグレーション情報の受信による信頼性と性能の向上をねらうものもありうる。
DHCPは既存の静的コンフィグレーションホストや既存のプロトコルと共存できなければならない。
DHCPはRFC951と Wimer[21]に定められた通り、BOOTPリレイエージェントと協調動作できなければならない。
DHCPは既存のBOOTPクライアントにサービスを提供できなければならない。

ここから先は、ネットワーク層のパラメータの転送に対する目標である。

ネットワークアドレスは常に一つのホストでのみ使用されなければならない。
ホストがリブートしても同様のコンフィグレーションが得られなければならない。ホストは可能な限り前回と同じコンフィグレーションパラメータが得られるべきである。
サーバがリブートしても同様のコンフィグレーションが得られなければならない。またホストは可能な限り前回と同じコンフィグレーションパラメータが得られるべきである。
新しいホストの手動コンフィグレーションを避けるために、新しいホストに自動的にコンフィグレーションパラメータを送信できなければならない。
特定のホストに対する固定、あるいは定常的なコンフィグレーションパラメータの割り当てができなければならない。

2. プロトコル要約

クライアントの観点からするとDHCPはBOOTPの拡張にすぎない。これはすなわち、既存のBOOTPクライアントは何の変更も無しにDHCPサーバに接続できることを意味する。別の文書[9]でBOOTPとDHCPのクライアントとサーバの関係について説明している。DHCPサーバとDHCPクライアント間には動作の最適化のためのいくつかの新しい、オプショナルな手続きがあり、3章と4章で解説する。

図1はDHCPメッセージのフォーマットを示しており、表1は個々のフィールドについて詳説している。図中の数字は各フィールドのサイズをオクテットで表したものである。フィールドにある名称は原文のままで、表1にて本文中での用語との対応を取っている。

   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)                        |
   +---------------------------------------------------------------+

図 1: DHCPメッセージのフォーマット

FIELD	OCTETS	DESCRIPTION
op	1	オペレーションコード。 1 = BOOTREQUEST, 2 = BOOTREPLY
htype	1	ハードウェア番号。詳細は"Assigned Numbers" RFCを参照のこと。ちなみに、'1' = 10Mイーサネット
hlen	1	ハードウェアアドレス長。（ちなみに、10Mイーサネットでは'6'）
hops	1	転送回数。クライアントが'0'に設定する。リレイエージェントを経由する場合に使用される。
xid	4	トランザクションID。クライアントが要求毎に用意するランダムな番号で、メッセージの対応を取るために使用される。
secs	2	経過時間。クライアントが初期化を始めてからの経過時間を設定する。
flags	2	フラグ（図2を参照のこと）。
ciaddr	4	クライアントIPアドレス。DHCPREQUESTでクライアントが以前に割り当てられたアドレスを設定する。
yiaddr	4	要求者IPアドレス。
siaddr	4	次回の初期化で使用すべきサーバのIPアドレス。 DHCPOFFER、DHCPACK、DHCPNAKでサーバが返答する。
giaddr	4	リレイエージェントIPアドレス。リレイエージェントを使用する時に使用される。
chaddr	16	クライアントハードウェアアドレス。
sname	64	サーバのホスト名。オプションで、ヌル文字で終わる文字列。
file	128	ブートファイル名。ヌル文字で終わる文字列。 DHCPDISCOVERで一般的な名称かヌル文字をいれると、 DHCPOFFERでフルパスに変換されて戻る。
options	312	オプション。詳細はオプションについて定めた文書を参照のこと。
表 1: DHCPメッセージの各フィールドの詳細

DHCPとBOOTPには二つの根本的な違いがある。一つ目は、DHCPにはクライアントが一定期間ネットワークアドレスをリースされるための仕組みがあることで、ネットワークアドレスを異るクライアントに順番に割り振ることができる。二つ目は、DHCPにはクライアントが必要とする全てのIPコンフィグレーションパラメータを提供するための仕組みがあることである。

DHCPではあるフィールドの意味を明確にするための名称の変更を行なっている。 BOOTPでベンダ拡張フィールドと呼ばれていたフィールドをDHCPではオプションフィールドと改名した。同様に、BOOTPベンダ拡張フィールドで使用され、ベンダ拡張と呼ばれていたタグ付きデータを単にオプションと呼ぶことにする。

DHCPでは、明示的にサーバにクライアントの識別子を渡すためにクライアント IDフィールドをオプションに新設した。これにより、BOOTPではクライアントのハードウェアドレスであり識別子でもあったクライアントハードウェアアドレスフィールドを本来のハードウェアアドレスとしてのみ使用することになる。クライアントIDフィールドはクライアントハードウェアアドレスフィールド同様クライアントのハードウェアアドレスを含んでも構わないし、DNS名のような別の識別子でも構わない。その他の識別子の種別は必要に応じて定めて構わない。新しい識別子のタイプはIANA[18]によって登録され、その後に発行されるAssigned Numbers文書に含まれると同時に、DHCPオプションを説明した文書 [2]の新しいバージョンで詳説される。

DHCPでは、サーバIPアドレスフィールドを次回のクライアントの初期化で使用するサーバのアドレスである、としている。次回も対応可能な場合、DHCPサーバは自らのアドレスをサーバIPアドレスフィールドに入れて返答しても構わない。これとは別にDHCPサーバはオプションフィールドのサーバIDフィールドに自らのアドレスを入れて返さなければならない。

オプションフィールドは最小サイズが312オクテットの可変長となった。これにより、DHCPメッセージの最小のサイズが576オクテット、ホストが受信しなければならない最小のIPパケットサイズ[3]となった。

新しいオプションのベンダ拡張情報フィールドがオプション拡張のために用意されている[2]。ベンダ拡張情報フィールドは、異るベンダどうしのサーバとクライアント間で問題を起こさないよう考慮して設計されなければならない。特に、ベンダ拡張情報フィールドを定義したベンダは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             |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B:  ブロードキャストフラグ
MBZ:  MUST BE ZERO (未使用)

図 2: フラグフィールド

DHCPではフラグフィールド[21]を使用する。左端のビットがブロードキャストフラグである。このフラグについては4.1で詳説する。残りの領域は将来の拡張のために取り置かれており、クライアントによって全て'0'に設定され、またサーバやリレイエージェントは無視しなければならない。図2にフラグフィールドのフォーマットを示す。

2.1 コンフィグレーション情報格納場所

DHCPが提供する第一のサービスがクライアントに対するコンフィグレーション情報の格納機能である。情報の保持モデルは、DHCPが個々のクライアントを識別するためのキー（例えば、IPサブネットアドレスとそのサブネット内での一意な識別子）を保持し、それに対応する形で個々のクライアントのコンフィグレーション情報を保持するというものである。

例えば、このキーはIPサブネットアドレスとハードウェアアドレスの組み合わせであっても良い。ハードウェアアドレスは他のサブネットで使用されているものを使用しても良いし、世界中で一意でなくても構わない。一方、キーはIP サブネットアドレスとホスト名の組み合わせであっても良い。この場合、他のサブネットに移動してしまったホストやハードウェアアドレスが変わってしまったホスト（ネットワークボードの障害等による交換など）にコンフィグレーション情報を割り当てても構わない。

クライアントはDHCPサービスからコンフィグレーション情報を受け取ることができる。クライアントがコンフィグレーション情報を引き出す方法は、コンフィグレーション情報を要求し、サーバが応答にコンフィグレーション情報を渡すというプロトコルメッセージによって実現される。

2.2 アドレスの動的割り当て

DHCPの第二のサービスは、ネットワークアドレス（IPアドレス）の一時的、あるいは固定的な割り当てである。動的割り当ての仕組みは簡単で、クライアントが一定の期間アドレスを使用したい旨要求するだけである。この割り当ての仕組みではその期間内そのアドレスを別のホストに割り当てたりしないこと、クライアントが要求する度に可能なかぎり同じアドレスを割り当てるようにすることが保証されている。本書では、クライアントにアドレスが割り当てられている期間のことを「リース期間」と呼ぶことにする[11]。クライアントはリース期間の延長を要求することもできる。クライアントはアドレスが不要になればサーバに返納しても構わない。またリース期間を無限にすることによって固定的割り当てを要求することもできる。なお、たとえ固定的割り当てを要求しても、サーバはそのホストがネットワークから外された場合を考慮してリース期間を有限としても構わない。

時には、アドレスの枯渇によりネットワークアドレスの付け替えが必要になることがある。そのような場合、リース期間の切れたアドレスは再利用されます。サーバはアドレスの再利用に際し、保持するコンフィグレーション情報を如何様にでも利用すべきです。例えば、サーバはあまり頻繁に割り当てられていないアドレスを優先して再利用しても構いません。整合を取るために、割り当て前には再利用するアドレスをチェックしても構いません。すなわち、ICMPecho によるチェックやARPによるチェックなどです。

3. クライアント・サーバ間プロトコル

DHCPはRFC951に定められている、図1と表1にあるようなBOOTPと同じメッセージを使用している。クライアントからサーバに送られるメッセージではオペレーションコードはBOOTREQUESTになっており、サーバからクライアントに送られるメッセージではBOOTREPLYとなっている。
オプションフィールドの最初の4オクテットは、DHCPメッセージでは（RFC1497 にある"magic cookie"と同様）10進数の99、130、83、99となっている。オプションフィールドの残りの領域は、オプションと呼ばれるタグ付きパラメータのリストである。RFC1497のベンダ拡張の全てはDHCPではオプションと呼ばれることになっている。DHCPで使用されるオプションに付いては別に定める[2]。
ここまで、いくつかのオプションについて説明してきたが、あるオプション、即ちDHCPメッセージタイプオプションは全てのDHCPメッセージに含まれていなければならない。このオプションはDHCPメッセージの種類を特定するものである。その他のオプションはDHCPメッセージタイプにより必須であったり、オプションであったり、不要であったりする。
本書では、DHCPメッセージはDHCPメッセージタイプで呼ぶことにする。すなわち、DHCPメッセージタイプが'1'であるようなメッセージはDHCPDISCOVERと呼ぶ。

3.1 クライアント・サーバ - アドレスの割り当て

以下に、表2に示されるDHCPメッセージのやりとりについて簡単に説明する。その場合の典型的なフローチャートを図3に示す。クライアントが自分のアドレスをしっている場合には、いくつか手続きが省略されるが、その場合については3.2で詳説する。

クライアントがDHCPDISCOVERメッセージをローカルサブネットにブロードキャストする。DHCPDISCOVERメッセージにはネットワークアドレスとリース期間を示すオプションが含まれていても構わない。BOOTPリレイエージェントは別のサブネットにいるDHCPサーバにメッセージを転送しても構わない。
DHCPサーバは要求者IPアドレスや他のオプションを含むDHCPOFFERメッセージを応答する。サーバは、そうしないほうが効果的ではあるが、要求者IP アドレスとして応答したネットワークアドレスを取り置く必要はない。サーバは可能であればDHCPOFFERメッセージをクライアントに（必要に応じてリレイエージェントを介して）ダイレクトに送信する。そうでない場合はクライアントのサブネットでブロードキャスト（255.255.255.255）する。
クライアントは複数のサーバから一つ以上のDHCPOFFERメッセージを受信することになる。クライアントは複数の応答を受信するまで待っても構わない。クライアントはDHCPOFFERメッセージにあるコンフィグレーション情報をチェックして、そのうちからどれか一つのサーバを選択し、そのサーバを示すサーバID（と必要なコンフィグレーション情報を要求するためのオプション）を含むDHCPREQUESTメッセージをブロードキャストする。 DHCPREQUESTメッセージはリレイエージェントによって中継されるが、メッセージを同一のサーバに確実に到達させるためDHCPDISCOVERメッセージで使用した経過時間と同じ値を使用する。クライアントがDHCPOFFERメッセージの受信待ちでタイムアウトした場合、DHCPDISCOVERメッセージを再送する。
サーバはクライアントがブロードキャストしたDHCPREQUESTメッセージを受信するが、サーバIDにより指定されていないサーバはそのDHCPREQUESTメッセージによりクライアントが別のサーバを選択したことを知る。指定されたサーバはDHCPACKメッセージに、要求のあったコンフィグレーション情報を含めて応答する。クライアントハードウェアアドレスと割り当てたネットワークアドレスにより割り当てを受けたクライアントが一意に識別されるため、以後DHCPメッセージではこの組み合わせによりサーバ、クライアント双方が割り当て関係を認識する。DHCPACKメッセージの要求者IPアドレスフィールドには割り当てられたネットワークアドレスが挿入される。

指定されたサーバがDHCPREQUESTメッセージでの要求に応えられない場合（すなわち、要求されたネットワークアドレスが既に割り当てられてしまっている場合）、サーバはDHCPNAKメッセージで応答すべきである。

サーバはDHCPOFFERメッセージでクライアントに提供を申し出たネットワークアドレスを使用不可能にしておいても構わないが、DHCPREQUESTメッセージを受信しなかった場合は利用可能に戻しておくべきである。
クライアントは要求したコンフィグレーション情報の入ったDHCPACKメッセージを受信すると、パラメータのチェック（ARPで割り当てられたネットワークアドレスのチェックそするなど）を行ない、リース期間などを記録しておきます。これでクライアントのコンフィグレーションが終了したことになります。DHCPACKメッセージにより受信したコンフィグレーション情報に問題があった場合は、クライアントはDHCPDECLINEメッセージをサーバに送信してコンフィグレーションをやり直します。クライアントはメッセージループによるネットワークトラフィックの増大を避けるために、コンフィグレーションをやり直すまでに少なくとも10秒間待つべきです。クライアントがDHCPNAKメッセージを受信した場合、クライアントはコンフィグレーションをやり直します。 DHCPACKまたはDHCPNAKメッセージを待ってクライアントがタイムアウトした場合は、クライアントはDHCPREQUESTメッセージを4.1の再送アルゴリズムに従って再送します。再送の後もDHCPACKまたはDHCPNAKメッセージが受信できなかった場合は、クライアントは初期化をやり直します。クライアントはユーザに初期化が失敗してやり直すことを通知すべきでしょう。
クライアントはDHCPRELEASEメッセージをサーバに送付することによってネットワークアドレスのリースを放棄することができます。リースはクライアントIPアドレスとクライアントハードウェアアドレスにより識別されます。

                サーバ       クライアント       サーバ
          (指定されていない)                 (指定された)

                  v               v               v
                  |               |               |
                  |           初期化開始          |
                  |               |               |
                  | _____________/|\_____________ |
                  |/ DHCPDISCOVER | DHCPDISCOVER \|
                  |               |               |
         コンフィグレーション     |      コンフィグレーション         
                設定              |             設定
                  |               |               |
                  |\              |  ____________/|
                  | \_________    | /DHCPOFFER    |
                  |  DHCPOFFER\   |/              |
                  |            \  |               |
                  |            応答待ち           |
                  |              \|               |
                  |   コンフィグレーション選択    |
                  |               |               |
                  | _____________/|\_____________ |
                  |/ DHCPREQUEST  |  DHCPREQUEST \|
                  |               |               |
                  |               |     コンフィグレーション送付         
                  |               |               |
                  |               | _____________/|
                  |               |/ DHCPACK      |
                  |               |               |
                  |           初期化終了          |
                  |               |               |
                  .               .               .
                  .               .               .
                  |               |               |
                  |      正常なシャットダウン     |
                  |               |               |
                  |               |\_____________ |
                  |               |  DHCPRELEASE \|
                  |               |               |
                  |               |        リース情報放棄         
                  |               |               |
                  v               v               v

図 3:

クライアント・サーバ間でネットワークアドレスを
割り当てる際のDHCPメッセージのフローチャート

Message	Use
DHCPDISCOVER	サーバを見つけるためにクライアントがブロードキャストする。
DHCPOFFER	DHCPDISCOVERメッセージへの応答として、コンフィグレーション情報を入れてサーバからクライアントに送信される。
DHCPREQUEST	クライアントがサーバに提供されたコンフィグレーション情報の割り当てを要求するためと、その他のサーバに別のサーバを選択したことを知らせるためにブロードキャストする。
DHCPACK	サーバからクライアントに送られる、割り当てられたネットワークアドレスを含むコンフィグレーション情報。
DHCPNAK	サーバからクライアントに送られる、要求の拒否（要求されたネットワークアドレスが既に割り当てられているなど）
DHCPDECLINE	クライアントからサーバに送られる、無効なコンフィグレーション情報（ネットワークアドレスなど）を含むメッセージ。
DHCPRELEASE	クライアントからサーバに送られる、ネットワークアドレスの開放とリースのキャンセルメッセージ。

表 2: DHCPメッセージ

3.2 クライアント・サーバ - アドレスの再利用

クライアントが先に割り当てられた（DHCPによるものであっても、別の仕組みによるものであっても構わない）ネットワークアドレスを再び利用したい場合、前節のいくつかのステップを省略することができます。図4にその場合の典型的なクライアント・サーバ間のフローチャートを示します。

クライアントはローカルサブネットでクライアントIPアドレスフィールドに先に使用していたネットワークアドレスを含むDHCPREQUESTメッセージをブロードキャストします。リレイエージェントは別のサブネットのDHCPサーバに転送します。

このクライアントに心当たりのあるサーバはDHCPACKメッセージで返答します。

                サーバ       クライアント       サーバ

                  v               v               v
                  |               |               |
                  |           初期化開始          |
                  |               |               |
                  |              /|\              |
                  |  ___________/ | \___________  |
                  | /DHCPREQUEST  |  DHCPREQUEST\ |
                  |/              |              \|
                  |               |               |
         コンフィグレーション     |      コンフィグレーション
                設定              |             設定
                  |               |               |
                  |\              |              /|
                  | \             |  ___________/ |
                  |  \            | /  DHCPACK    |
                  |   \________   |/              |
                  |     DHCPACK\  |               |
                  |           初期化完了          |
                  |              \|               |
                  |               |               |
                  |       （後続のDHCPACK         |
                  |         メッセージは          |
                  |           無視される）        |
                  |               |               |
                  |               |               |
                  v               v               v

     図 4: 先に割り当てられたネットワークアドレスを再利用する場合の
           DHCPサーバとクライアント間のメッセージのフローチャート

クライアントの要求が無効になっている場合（例えばクライアントが別のサブネットに移動してしまっている場合）はDHCPNAKメッセージで応答します。

コンフィグレーション情報入りのDHCPACKメッセージを受信したクライアントは（3.1にあるように）パラメータのチェックを行ない、リース期間などを記録し、コンフィグレーションが終了します。

クライアントが受信したコンフィグレーション情報に問題があった場合はクライアントはサーバにDHCPDECLINEメッセージを送信し、コンフィグレーションをやり直します。これは4.4のDHCP状態遷移図でクライアントが初期化状態に移行したことに対応します。

クライアントがDHCPNAKメッセージを受信した場合は先に割り当てられていたネットワークアドレスが利用できないことになるので、コンフィグレーションをやり直すことによって新しいネットワークアドレスを要求しなければなりません。この場合は3.1の手続きを踏むことになります。これも DHCP状態遷移図でクライアントが初期化状態に移行したことに対応します。

クライアントがDHCPACKまたはDHCPNAKメッセージを受信せずにタイムアウトした場合、クライアントはDHCPREQUESTメッセージを再送しますが、再送までの間隔は4.1の再送アルゴリズムに従う必要があります。クライアントが4回DHCPREQUESTメッセージを送信しても返事がなかった場合はクライアントはリース期間が残っている間は前回使用したネットワークアドレスやコンフィグレーション情報を使用しても構いません。これは図5の状態遷移図でクライアントがリース状態に移行したことに対応します。
クライアントはサーバにDHCPRELEASEメッセージを送ることによってネットワークアドレスのリースを放棄することができます。リースはクライアントIPアドレスとクライアントハードウェアアドレスにより識別されます。

クライアントがローカルにネットワークアドレスを得ている場合は、クライアントが通常のシャットダウンでアドレスを放棄することはありません。クライアントがアドレスを放棄する必要があるのは例えばクライアントが別のサブネットに移動する場合などだけです。

3.3 リース期間の取り扱い

クライアントはネットワークアドレスの有限時間（無限という場合もあり得る）のリースを得るが、本プロトコルにおいては時間は秒単位で取り扱われ、 '0xffffffff'をもって無限時間と見なす。なお、最小のリース期間は1時間とする。

サーバとクライアントは同期した時計を持っているわけではないので、DHCPメッセージで扱われる時間はクライアントのローカルな時計を基準とする。時間は32ビットの秒表記で0からほぼ100年間までの値を取り、DHCPで取り扱うには十分な時間であろう。

上記ではサーバとクライアントの時計は同じように動作するとしているが、二つの時計に時差がある場合は、サーバはクライアントよりも先にリース期間が終了したと思うかもしれない。時間の補償のために、サーバはリース期間として記録してあるよりも短い期間をクライアントに返答しても構わない。

3.4 ホストパラメータ

全てのクライアントが付録Aにあるパラメータの全てを要求するわけではない。サーバからクライアントに送付されるパラメータの数を減らすために、以下の二つの方式が使用される。一つは、ほとんどのパラメータがHost Requirements RFCでデフォルト値が定義されているため、デフォルト値でいいパラメータについては要求しないというものである。もう一つは、最初の DHCPDISCOVERまたはDHCPREQUESTメッセージにおいてクライアントが要求するパラメータのリストをサーバに送付する方式である。

クライアントは最大DHCPメッセージサイズオプションによってサーバが生成すべき最大のDHCPメッセージのサイズを規定すべきである。クライアントに返答すべきオプションのサイズだけでもこのサイズを越えてしまうかもしれない。その場合はオプションフラグ（オプションフィールドにある）によってブートファイル名フィールドとサーバファイル名フィールドを追加のオプションフィールドとして使用できるようにする。

クライアントは要求パラメータリストオプションによって大事なコンフィグレーション情報をサーバに通知することができる。このリストは大事なオプションのタグ番号からなる。

クライアントはDHCPDISCOVERメッセージで、要求IPアドレスオプションで特定のIPアドレスを、リース期間オプションでリース期間を指定しても構わない。その他のオプションはDHCPDISCOVERやDHCPREQUESTメッセージでは許されていない。クライアントが先に割り当てられたIPアドレスを使用したい場合は、 DHCPREQUESTメッセージでのみクライアントIPアドレスフィールドを使用すべきである。

不正なクライアントIPアドレスフィールドを持つDHCPREQUESTメッセージを受信したサーバは、DHCPNAKメッセージで応答すべきであり、またシステム管理者にレポートしてもよい。サーバはメッセージオプションを使用してエラーメッセージを通知しても構わない。

3.5 複数のインタフェースを持つクライアントの運用

複数のネットワークインタフェースを持つホストは、個々のインタフェースごとのコンフィグレーション情報を得るために、独立してDHCPにアクセスしなければならない。

3.6 クライアントがDHCPを使用すべき場合

ホストは、ネットワークパラメータに変動があった際、例えばシステムのリブート、ネットワークに再接続された時などにシステムやユーザによらずにネットワークのコンフィグレーションが変更されてしまった場合、にはIPアドレスの確認あるいは新しいものを知るためにDHCPを使用すべきである。

ホストが先に割り当てられたネットワークアドレスを覚えていて、DHCPサーバにアクセスできなくなった場合、ホストはリース期間が終了するまではそのアドレスを使用しても構わない。ホストがDHCPにアクセスできるまでにリース期間が終了した場合は、直ちにアドレスの使用をやめなければならない、またその場合ユーザに問題が発生したことを通知して構わない。

4. DHCPプロトコル定義

この章では、DHCPはアドレスの要求に応えて割り当てるべきネットワークアドレスを保持し、それらの割り当て状況やリース期間を管理しているものとする。

4.1 DHCPメッセージの生成と送信

DHCPクライアントとDHCPサーバは固定長のフィールドとオプションデータを組み合わせてDHCPメッセージを生成する。オプションフィールドの最初の4オクテットは"magic cookie"であり、その後ろにオプションが続く。オプションの最後は必ず終了オプションでなければならない。

DHCPはUDPプロトコルを用い、クライアントからサーバに送信する際はDHCPサーバポート（67）に、サーバからクライアントに送信する際はDHCPクライアントポート（68）に送信する。

クライアントが最初にブロードキャストするDHCPメッセージのソースIPアドレスは'0'でなければならない。

クライアントからのDHCPメッセージのゲートウェイIPアドレスフィールドに値が設定されている場合は、サーバはゲートウェイIPアドレスを持つリレイエージェントのDHCPサーバポートに送信する。ゲートウェイIPアドレスフィールドが'0'の場合はクライアントが同一サブネットにあることを意味するので、サーバはメッセージをクライアントIPアドレスフィールドにあるクライアントのネットワークアドレスかクライアントのハードウェアアドレスにダイレクトに送信するか、ブロードキャストする。

DHCPメッセージのオプションフィールドがサーバ名フィールドやブートファイル名フィールドにまで拡張されている場合、適切な値[2]を持ったオプション拡張オプションがオプションフィールドになければならない。オプションフィールドが拡張された場合、本来のオプションフィールドは終了オプションで終わっていなければならない。また、オプションフィールドの隙間を埋めるために、埋め草オプションを使用しても構わない。サーバ名フィールドやブートファイル名フィールドはフィールドの先頭から使用され、終了オプションで終了し、残りの領域は埋め草オプションで埋められていなければならない。各々のフィールドにあるオプションはそのフィールド内に閉じていなければならない。解釈は本来のオプションフィールドが必ず優先され、その後に他のフィールドが解釈されなければならないが、残りのフィールドのうちブートファイル名フィールドが優先され、最後がサーバ名フィールドとなる。

DHCPクライアントにはメッセージの再送機能がなければならない。この再送機能には再送間の時間をランダムな2の累乗で変化させることのできる機能が組み込まれていなければならない。最初の再送までの待ち時間は4秒に-1から+1 までのランダムな数字を加えた時間とする。1秒以下の精度の時間を利用できるクライアントは非整数の値を利用して構わない。その次の再送までの待ち時間は8秒に-1から+1までのランダムな数字を加えた時間とする。再送間隔は最大64秒まで再送ごとに倍にしてゆく。クライアントはユーザに初期化の進み具合を知らせるために再送していることを知らせても構わない。以下、この節ではクライアントがどういう時には再送を繰り返し、どういう時には破棄すべきかをメッセージごとに説明する。

通常、DHCPサーバやリレイエージェントはDHCPOFFER、DHCPACK、DHCPNAKメッセージをクライアントにダイレクトに送信しようとする。受信者IPアドレスは要求者IPアドレスと同じ値に設定され、イーサアドレスはクライアントハードウェアアドレスと同じに設定される。しかしながら、クライアントの実装によっては、適切なコンフィグレーションが終了するまでそのようなユニキャストパケットを受信できない場合がある（あるIPアドレスによるコンフィグレーションが行なわれるまでは、そのIPアドレスあてのパケットを受信できないというデッドロックに陥ってしまう）。

IPアドレスによるコンフィグレーションが行なわれなければ、そのIPアドレス宛のパケットが受信できないようなクライアントは、送信するDHCPDISCOVERや DHCPREQUESTメッセージのフラグフィールドのブロードキャストフラグを'1'に設定すべきである。ブロードキャストフラグによってDHCPサーバやリレイエージェントにクライアントにはブロードキャストしか受信できないことを知らせることができる。そうでないクライアントはブロードキャストフラグは'0'にしておくべきである。ブロードキャストフラグを使用する場合のBOOTPとの関係については、関連文書[21]にまとめておく。

DHCPメッセージをクライアントに直接送信するサーバやリレイエージェント（すなわちゲートウェイIPアドレスにあるリレイエージェントに送信する場合以外）はフラグフィールドのブロードキャストフラグをチェックすべきである。もしブロードキャストフラグが立っていればDHCPメッセージはブロードキャスト（受信者IP、受信者イーサアドレスともにブロードキャストアドレス）されるべきである。ブロードキャストフラグが立っていなければ要求者IPアドレスとクライアントハードウェアアドレス宛のダイレクトメッセージとなるべきである。もし、ダイレクトに送信できない場合はブロードキャストしても構わない。

4.2 DHCPサーバの管理

DHCPサーバは受信した全てのDHCPDISCOVERやDHCPREQUESTメッセージに応答しなければならないわけではない。例えば、ネットワークの管理を強化したいネットワーク管理者の場合、DHCPを利用できるホストを制限しても構わない。 DHCPでは、それを望むサーバとクライアント間の動作を規定しているのであって、管理者の望む全ての操作について規定しているわけではない。DHCPサーバの実装によっては、ネットワーク管理者の望む機能を入れても構わない。

場合によっては、DHCPサーバはクライアントを特定するためにDHCPDISCOVERや DHCPREQUESTメッセージのクライアントハードウェアアドレスやクラスIDオプションをチェックしなければならない。例えば、複数のサーバがあり、クライアントがサーバによって分けられているような場合、DHCPOFFERやDHCPACKメッセージに設定するサーバIPアドレスを知るためにクラスIDをサーバがチェックしなければならないかもしれない。

サーバはクライアントと通信する際に、幾つかのユニークな識別子を用いなければならない。クライアントはクライアントIDオプションを用いて識別子を渡すことができる。クライアントがクライアントIDオプションを用いなかった場合は、サーバはクライアントハードウェアアドレスフィールドの内容をもってクライアントの識別子としなければならない。

DHCPクライアントはDHCPOFFERメッセージを発したサーバのどれを選ぶかは自由である。DHCPクライアントはユーザが直接クラスIDを指定できるように実装すべきである。

4.3 DHCPサーバの動作

DHCPサーバは、現在の状態とクライアントとの関係によって受信したDHCPメッセージを処理する。DHCPサーバはクライアントからの以下のメッセージを受信できる。

DHCPDISCOVERメッセージ
DHCPREQUESTメッセージ
DHCPDECLINEメッセージ
DHCPRELEASEメッセージ

表3にサーバが発するDHCPメッセージの各フィールドの説明を示す。以下では DHCPサーバが受信したメッセージに対してどのように振る舞うかを説明する。

4.3.1 DHCPDISCOVERメッセージ

サーバがクライアントからのDHCPDISCOVERメッセージを受信した場合、サーバはそのクライアント用のネットワークアドレスを割り当てる。もし、割り当てるべきアドレスがない場合はシステム管理者に問題をレポートし、クライアントにDHCPNAKメッセージを送信して構わない。この時、エラーメッセージをメッセージオプションにいれても構わない。もし割り当て可能なアドレスがある場合は、以下のように選定する。

そのクライアントに先に割り当てていたアドレスが利用可能であればそのアドレスを。
要求IPアドレスオプションに指定されたアドレスが有効なもので、利用可能であればそのアドレスを。
いずれでもない場合は割り当て可能なアドレスを。

サーバは4.2節にあるように、管理上の理由から、要求されたものではないアドレスを割り当てても良いし、割り当て可能なアドレスがあっても特定のクライアントからの割り当て要求を拒絶しても構わない。

サーバは、クライアントがDHCPOFFERメッセージに応答するまでは、DHCPとしての正当な手続き無しに割り当てようとしているネットワークアドレスを（別のクライアントに）割り当てるべきではない。サーバはそのアドレスがクライアントに割り当てられたと記録しておいても構わない。

  Field      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

  Option                   DHCPOFFER        DHCPACK          DHCPNAK
  ------                   ---------        -------          -------

  要求IPアドレス           不要             不要             不要
  リース期間               必須             必須             不要
  オプション拡張           オプション       オプション       不要
  DHCPメッセージタイプ     DHCPOFFER        DHCPACK          DHCPNAK
  要求パラメータリスト     不要             不要             不要
  コメント                 あるべき         あるべき         あるべき
  クライアントID           不要             不要             不要
  クラスID                 不要             不要             不要
  サーバID                 必須             オプション       オプション
  最大メッセージ長         不要             不要             不要
  その他                   オプション       オプション       不要

           表 3:  DHCPサーバが作成するパラメータ

サーバは以下のようにリース期間を定めなければならない。

クライアントがDHCPDISCOVERメッセージで特にリース期間を要求せず、すでにネットワークアドレスの割り当てを受けている場合は、サーバは以前そのクライアントに設定したリース期間を通知する（クライアントは、以前のリース期間よりも長いリース期間を欲する場合は、その旨要求しなければならないことに注意）。
クライアントがDHCPDISCOVERメッセージでリース期間を要求せず、またネットワークアドレスの割り当てを受けていない場合は、サーバはローカルに設定されているデフォルトのリース期間を通知する。
クライアントがDHCPDISCOVERメッセージでリース期間を指定した場合（クライアントがネットワークアドレスの割り当てを受けているかどうかは関係ない）、サーバは指定のリース期間を通知する（その期間で問題がない場合）か別のリース期間を通知する。

ネットワークアドレスとリースの内容が決ってしまえば、サーバはコンフィグレーション情報をもとにDHCPOFFERメッセージを作成することができる。全てのサーバにとって、クライアントがどのサーバを選択してもその動作が変わらないために、（ネットワークアドレスが変わる場合を除き）同じコンフィグレーション情報を返答することは重要なことである。コンフィグレーション情報は以下の条件を満たすように選択されなければならない。ネットワーク管理者は、全てのDHCPサーバが同一の返答をするように設定すべきである。

サーバは先に定めたルールにしたがい決定されたネットワークアドレスとクライアントが接続されているサブネットのネットマスクを通知しなければならない。
サーバは先に定めたルールにしたがい決定されたリース期間をクライアントに通知しなければならない。
サーバは次のルールにしたがい、要求されたパラメータを通知しなければならない。
- サーバにそのパラメータに関する設定があれば、その設定を返さなければならない。
- サーバが、そのパラメータがHost Requirements Documentで定義されるパラメータであると認識すれば、Host Requirements Documentでのデフォルト値を返さなければならない。
- 上記以外の場合は、サーバはパラメータを返答してはならない。
サーバは、Host Requirements Documentでのデフォルトとは異っても、既存のリースで使用されているパラメータの値を通知しなければならない。
サーバは（DHCPDISCOVERやDHCPREQUESTメッセージにあるクライアントハードウェアアドレスから識別した）そのクライアントに特有のパラメータを返さなければならない。すなわち、ネットワーク管理者によって設定された値である。
サーバは（DHCPDISCOVERやDHCPREQUESTメッセージにあるクラスIDから識別した）そのクライアントが属するクラスに特有のパラメータを返さなければならない。すなわち、ネットワーク管理者によって設定された値である。なお、クライアントが送信したクラスIDとサーバが保持するクラスIDが厳密に一致した場合のみとする。
サーバはクライアントのサブネットでのデフォルト値と違う値を持つパラメータを通知しなければならない。

サーバはDHCPDISCOVERメッセージのトランザクションIDをDHCPOFFERメッセージでもそのまま使用してクライアントにメッセージを送信する。

4.3.2 DHCPREQUESTメッセージ

DHCPREQUESTメッセージは、クライアントからDHCPOFFERへの返答として、または先に割り当てられたIPアドレスの再割り当ての際に送信される。もし、 DHCPREQUESTメッセージにサーバIDが含まれている場合は、そのメッセージは DHCPOFFERメッセージへの返答である。そうでないメッセージはリースの更新や延長の要求である。

まず、DHCPOFFERメッセージへの返答の場合について考えてみる。DHCPREQUEST メッセージのサーバIDオプションに一致するサーバが受信した場合は、サーバは要求されたパラメータに問題がないかチェックする。通常、要求されるパラメータはDHCPOFFERメッセージで通知したそれと同じものであるが、クライアントは異るリース期間を要求しても構わない。サーバには、DHCPOFFERメッセージに設定したパラメータを覚えておく必要はなく、単にDHCPREQUESTメッセージで要求されるパラメータに問題がないかどうかだけをチェックするのみである。パラメータに問題がなければ、サーバは新しいリースとして記録し、クライアントにDHCPACKメッセージを返す。

要求されたパラメータに問題があった場合、例えば要求されたリース期間が運用上容認できないような場合には、サーバはクライアントにDHCPNAKメッセージを送信する。この時、サーバはコメントオプションにエラーメッセージを入れても構わない。

サーバIDオプションに一致しないサーバが受信した場合は、クライアントが間違ったサーバに要求したことになるので、サーバはこれまでそのクライアントの要求に対応して保持していた情報や、クライアントに割り当てていたネットワークアドレスをもとに戻す。

ここで、クライアントは複数のサーバからのDHCPOFFERメッセージを受信し、その中で最も適切と思われるものを選んでかまわないのである。クライアントは自分の選択をDHCPREQUESTの中でサーバに通知する。クライアントが適切な申し出を得られなかった場合は、再度DHCPDISCOVERメッセージを送信してサーバを募る。したがって、サーバはクライアントが自分の申し出を受諾したかどうかを判断するためのDHCPREQUESTメッセージを得られないこともある。サーバはDHCPOFFERメッセージの発行によってネットワークアドレスを割り当てるわけではないので、別の要求に対してそのネットワークアドレスを割り当ててしまっても構わない。実装としては、サーバは申し出たネットワークアドレスをすぐ他のクライアントに割り当てることはせずに、何らかのタイムアウトを設けてその後に再利用すべきである。

メッセージにサーバIDオプションがない場合、クライアントは先に割り当てられたIPアドレスを更新するかそのリースを延長しようとしている。サーバは要求されたパラメータに問題がないかどうかチェックし、パラメータが先に通知したものと同じであるか、または（IPアドレスリース期間オプションによる）リース期間の延長が妥当である場合、クライアントにDHCPACKメッセージを送信する。それ以外の場合は、サーバはクライアントにDHCPNAKメッセージを送信する。特に、先に割り当てたアドレスであるクライアントIPアドレスがサーバの記録と一致しない場合、サーバはクライアントにDHCPNAKメッセージを送信する。

サーバは、4.3.1でふれたDHCPOFFERメッセージを作成する際と同じルールにしたがってDHCPACKメッセージに含めるパラメータを選択する。

4.3.3 DHCPDECLINEメッセージ

サーバがDHCPDECLINEメッセージを受信した場合、クライアントが何らかの方法でそのネットワークアドレスがすでに使用されていることを発見したことを意味する。サーバはそのネットワークアドレスが割り当てられていないことにしなければならない。またシステム管理者に問題が発生したことを通知すべきである。

4.3.4 DHCPRELEASEメッセージ

DHCPRELEASEメッセージを受信したサーバは、対応するネットワークアドレスを割り当てられていない状態に戻す。サーバはそのクライアントからの次回の要求に応えるために、そのクライアントのパラメータ設定を記録しておくべきである。

4.4 DHCPクライアントの動作

DHCPクライアントの状態遷移を図5に示す。クライアントはサーバからの次のメッセージを受信する。

DHCPOFFERメッセージ
DHCPACKメッセージ
DHCPNAKメッセージ

表4にクライアントが発するDHCPメッセージの各フィールドの説明を示す。以下ではクライアントが受信したメッセージに対してどのように振る舞うかを説明する。なお、詳細説明は3.1節の状況に、その後の説明は3.2節の状況に相当する。

4.4.1 初期化とネットワークアドレスの割り当て

クライアントの状態は初期化状態からはじまり、DHCPDISCOVERメッセージを生成する。クライアントはブート時には衝突を避けるために1～10秒、ランダムにウェイトをいれるべきである。クライアントはクライアントIPアドレスを "0x00000000"に設定する。クライアントはパラメータ要求リストオプションにより特定のパラメータを要求しても構わない。また要求IPアドレスオプションやリース期間オプションによって特定のネットワークアドレスやリース期間を要求しても構わない。クライアントは応答が送信できるようにクライアントハードウェアアドレスに自分のハードウェアアドレスを設定しなければならない。クライアントはクライアントIDオプションに自分を一意に識別する識別子を設定しても構わない。クライアントがクライアントIDオプションを使用しなかった場合、サーバはクライアントハードウェアアドレスをクライアントの識別子として使用する。

クライアントはランダムなトランザクションIDを生成し、トランザクションID フィールドに設定する。クライアントはリース期限の計算のために現在の時間を記録しておく。その後、クライアントはDHCPDISCOVERメッセージを"DHCPサーバ"UDPポートにブロードキャストする。

受信したDHCPOFFERメッセージのトランザクションIDが、最後に送出した DHCPDISCOVERメッセージのそれと一致しなかった場合は、DHCPOFFERメッセージは破棄される。またDHCPACKメッセージが受信されても破棄される。

クライアントは一定時間DHCPOFFERメッセージを収集し、そのうちの一つを選択して（例えば、最初のメッセージであるとか以前アクセスしたサーバからのメッセージ）サーバIDオプションからサーバアドレスを抜き出す。クライアントがメッセージを収集する時間や一つのDHCPOFFERメッセージを抜き出す方法は実装に依存する。クライアントは提供されたアドレスが現在使用されていないことをチェックしても構わない。例えば、もしクライアントのネットワークでARPがサポートされていれば、そのアドレスに対してARPを発行しても構わない。他のホストのARPキャッシュに混乱を与えないために、ARPパケットの発行時には、送信者ハードウェアアドレスに自分のハードウェアアドレスを、送信者IPアドレスには"0"を設定する。ネットワークアドレスが使用されているようだと、クライアントはDHCPDECLINEメッセージをサーバに送信し、たの DHCPOFFERメッセージを待つ。クライアントは有効なアドレスを割り当てられていないので、DHCPDECLINEメッセージはブロードキャストされる。

   desynchronize the use of DHCP at startup.  The client sets 'ciaddr'

 --------                               -------
|        | +-------------------------->|       |<-------------------+
|リブート| |     +-------------------->|初期化 |                    |
|        |DHCPNAK/         +---------->|       |<---+               |
|        |Restart|         |            -------     |               |
 --------  |  DHCPNAK/     |               |                        |
    |      Discard offer   |      -/Send DHCPDISCOVER               |
-/Send DHCPREQUEST         |               |                        |
    |      |     |      DHCPACK            v        |               |
 -----------     |   (not accept.)/   -----------   |               |
|           |    |  Send DHCPDECLINE |           |  |               |
|リブート中 |    |         |         | 選択中    |  |               |
|           |    |        /          |           |  |               |
 -----------     |       /            -----------   |               |
    |            |      /                  |        |               |
DHCPACK/         |     /  +----------------+        |               |
Record lease,    |    |   v                         |               |
set timers      ------------                        |               |
    |   +----->|            |             DHCPNAK, Lease expired/   |
    |   |      | 応答待ち   |                  Halt network         |
    DHCPOFFER/ |            |                       |               |
    Discard     ------------                        |               |
    |   |        |        |                   -----------           |
    |   +--------+     DHCPACK/              |           |          |
    |              Record lease, set    -----|再割り当て |          |
    |                timers T1, T2     /     |           |          |
    |                     |        DHCPACK/   -----------           |
    |                     v     Record lease, set   ^               |
    +----------------> -------      /Timers T1,T2   |               |
               +----->|       |<---+                |               |
               |      |リース |<---+                |               |
  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 |                |               |
                         |   ----------             |               |
                         |  |          |------------+               |
                         +->|リース延長|                            |
                            |          |----------------------------+
                             ----------

          図 5:  DHCPクライアントの状態遷移図
                 （"/"の前がサーバの動作、後がクライアントの動作）


  Field      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
  '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)


  Option                     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

           表 4:  Fields and options used by DHCP clients

パラメータに問題がなければ、クライアントはサーバIDフィールドからサーバのアドレスを抜き出して記録し、そのサーバにDHCPREQUESTメッセージをブロードキャストする。サーバからのDHCPACKメッセージを受信すると、クライアントは初期化を終了しリース状態へ移行する。DHCPREQUESTメッセージには DHCPOFFERメッセージと同じトランザクションIDが入っていなければならない。クライアントは最初に要求を出した時から起算してリース期間分を経た時間をリース終了時間として記録しておく。クライアントは新しいIPアドレスを得たことを示すためにARPリプライをブロードキャストし、他のホストのARPキャッシュを更新すべきである。

4.4.2 ネットワークアドレスを保持しての初期化

クライアントはリブート状態からスタートし、DHCPREQUESTメッセージにクライアントIPアドレスを設定して送信する。クライアントはパラメータ要求リストオプションにより特定のパラメータを要求しても構わない。クライアントはランダムな番号を生成し、トランザクションIDとする。クライアントはリース終了時間を計算するために、ローカルな時間を記録しておく。クライアントは DHCPREQUESTにサーバIDを入れてはいけない。これらの後にクライアントは "DHCPサーバ"UDPポートにDHCPREQUESTをブロードキャストする。

クライアントが発行したDHCPREQUESTメッセージと同じトランザクションIDを持つDHCPACKメッセージを受信したら、その発行サーバがどれであれクライアントは初期化を終了しリース状態へ移行する。クライアントは最初に要求を出した時から起算してリース期間分を経た時間をリース終了時間として記録しておく。

4.4.3 サーバ指定の初期化

クライアントがDHCPサーバのアドレスを知っている場合、初期化、リブートに関わらずクライアントはDHCPDISCOVERやDHCPREQUESTメッセージでそのアドレスを使用して構いません。そのサーバからの応答がない場合は、通常のブロードキャストでやり直します。

4.4.4 更新と期限切れ

クライアントはリースの期限として二つの時間を管理している。T1はクライアントがリース延長状態にはいる時間で、クライアントはアドレスを割り当ててくれたサーバにアクセスする。T2はクライアントが更新状態にはいる時間で、どのサーバにアクセスしても構わない。

リースが開始されてからT1時間経つと、クライアントはリース延長状態にはいり、サーバにリース延長を求めるDHCPREQUESTメッセージをダイレクトに送信する。クライアントはランダムな番号を生成してトランザクションIDとするとともに、リース期限切れ時間を計算するために要求を発行した時間を記録しておく。クライアントはDHCPREQUESTメッセージでサーバIDを指定してはいけない。

クライアントが送信したDHCPREQUESTメッセージのトランザクションIDに一致しないトランザクションIDを持つDHCPACKメッセージを受信しても、破棄される。DHCPACKメッセージを受信したクライアントは最初に要求を出した時から起算してリース期間分を経た時間をリース終了時間として記録しておく。ネットワークアドレスの割り当てを受けたクライアントはリース状態に戻る。

リース開始からT2時間（T2 > T1）経ってもDHCPACKメッセージが受信できなかった場合、クライアントは再割り当て状態に移行し、リースを更新すべく DHCPREQUESTメッセージをブロードキャストする。クライアントはDHCPREQUEST メッセージのクライアントIPアドレスに現在使用しているネットワークアドレスを設定するが、サーバIDは指定してはいけない。

T1とT2はオプションによってコンフィグレーション可能である。T1のデフォルト値はリース期間の半分（0.5×リース期間）で、T2のデフォルト値はリース期間の5/8（0.875×リース期間）である。両者とも、クライアント間での輻輳を避けるために、このデフォルト値を前後に散らした値を取る。

リース延長、再割り当て両方の状態において、クライアントがDHCPREQUESTメッセージへの応答を受信できなかった場合、DHCPREQUESTメッセージを再送するまでに最低60秒、残り時間の半分（リース延長状態ではT2になるまで、再割り当て状態ではリース切れになるまで）待つ。

DHCPACKメッセージを受信するまでにリース期間が終了してしまった場合、クライアントは初期化状態に戻り、全ての通信を中断し、初期化をやり直す。ただし、ここで先に割り当てられたネットワークアドレスを指示するDHCPACKメッセージを受信した場合は元通り通信を続けるべきである。クライアントが新しいネットワークアドレスを割り当てられた場合は、先に割り当てられたネットワークアドレスを使用してはいけない。クライアントはこのことをユーザに通知すべきである。

4.4.5 DHCPRELEASEメッセージ

クライアントがシャットダウンするなどでネットワークアドレスを必要としなくなった場合、クライアントはサーバにDHCPRELEASEメッセージを送信する。ただし、DHCPRELEASEメッセージがなくともDHCPは問題無く運用されることに注意されたい。

5. 謝辞

Greg Minshall、Leo McLaughlin、John Veizadesは長期にわたる議論に付合い、 DHCPの設計に協力してくれた。Jeff Mogulは最初にDHCPにクライアント・サーバモデルを適用し、Steve Deeringは多くのRFCを調査し、DHCPが提供すべきリソースをリストアップしてくれた。Walt WimerはBOOTPでの豊富な経験を活かし、BOOTP/DHCP共通のリレイエージェントの動作を明確化するドキュメントを作成してくれた。Jesse WalkerはDHCPを解析し、初期の規格にあった不整合を指摘してくれた。Steve AlexanderはWalkerの解析結果を検討し、それに基づく修正を行った。最後に、IETFのダイナミックホストコンフィグレーションワーキンググループでDHCPについての議論とレビューに参加してくれた全てのメンバーに感謝する。

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 an 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 1340, USC/Information Sciences Institute, July 1992.
[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. Author's Address

   Ralph Droms
   Computer Science Department
   323 Dana Engineering
   Bucknell University
   Lewisburg, PA 17837

   Phone: (717) 524-1145
   EMail: droms@bucknell.edu


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)