トップページ - 翻訳ドキュメント - RFC 2131

原文：ftp://ftp.rfc-editor.org/in-notes/rfc2131.txt

2004/08/20 0.1.0 初版
2005/12/16 0.2.0 一年以上ぶりに全体的に見直し。意味が違っていた部分があったのでマイナーバージョンアップしました。
2016/03/27 0.2.1 誤記修正(セクション 4.3.2)

ソーシャルブックマーク：
サイト内関連リンク： RFC 3396 DHCPv4における長いオプションの符号化

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

R. Droms
Bucknell University
March 1997

動的ホスト構成プロトコル
Dynamic Host Configuration Protocol

この文書の位置付け

この文書はインターネットコミュニティの為のインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案とを求めている。このプロトコルの標準化の状態と状況は "Internet Official ProtocolStandards"(STD 1) を参照して欲しい。この文書の配布は無制限である。

要約

Dynamic Host Configuration Protocol (DHCP) は TCPIP ネットワーク上でホストに構成情報を渡す為の枠組みを提供する。DHCP は Bootstrap Protocol(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 DHCP におけるクライアントパラメータ
 3.6 複数インターフェイスを持つクライアントでの DHCP の利用
 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. 'flags' フィールドのフォーマット
 3. 新しいネットワークアドレスを割当てる際に DHCP クライアントとサーバーとの間で交換されるメッセージのタイムライン図
 4. 以前に割当てられていたネットワークアドレスを再利用する際に DHCP クライアントとサーバーの間で交換されるメッセージのタイムライン図
 5. DHCP クライアントの状態遷移図

表一覧

1. DHCP メッセージのフィールドの説明
 2. DHCP メッセージ
 3. DHCP サーバーによって使用されるフィールドとオプション
 4. 様々な状態でのクライアントメッセージ
 5. DHCP クライアントのフィールドとオプション

1. 導入

動的ホスト構成プロトコル(Dynamic Host Configuration Protocol : DHCP)はインターネットのホストに構成パラメータを提供する。DHCP は二つの構成要素から成る:DHCP サーバーからホストへホスト固有の構成パラメータを伝える為のプロトコル、そしてホストのネットワークアドレスを割当てるメカニズムである。

DHCP はクライアントサーバーモデルに基いている。DHCP サーバーは動的に構成されるホストにネットワークアドレスを割当て、構成パラメータを伝える。この文書のこれ以降、"サーバー" は DHCP を通して初期化パラメータを提供するホストを指し、"クライアント" は DHCP サーバーに初期化パラメータを要求するホストを指す。

システム管理者によって明示的に構成されない限り、ホストは DHCP サーバーとして振る舞うべきではない。もし任意のホストが DHCP リクエストへの応答を許可されれば、インターネット上のハードウェアとプロトコル実装との多様性は、信頼できるオペレーションを不可能にしてしまうだろう。例えば IP は、そのプロトコルを実装するソフトウェア内で多くのパラメータの設定を必要とする。これは、IP が多くの異なる種類のネットワークハードウェア上で利用できるので、それらのパラメータへの値に対して正しいデフォルト値を仮定/推測する事が出来ない為である。その上、配布されるアドレスを割当てる仕組みは、既に使用されているアドレスを見つけるポーリング/ディフェンスメカニズムに依存する。配布されるアドレスを割当てるこのような仕組みがネットワークアドレスの重複割当てを避けられる事を保証できない為、IP ホストは常にネットワークアドレスを守る事が出来るとは限らないだろう。

DHCP は IP アドレス割当ての為の３つの仕組みをサポートする。"自動割当"では、DHCP はクライアントに永続的な IP アドレスを割当てる。"動的割当" では、DHCP はクライアントに時間制限付き(または、クライアントが明示的にそのアドレスを破棄するまで)の IP アドレスを割当てる。"手動割当" では、クライアントの IP アドレスはネットワーク管理者によって割当てられ、DHCP は単純にクライアントにその割当てられたアドレスを伝える為に使用される。個々のネットワークはネットワーク管理者のポリシーに基いて、これらの仕組みの内の１つまたは複数を利用するだろう。

クライアントが必要としなくなったアドレスを自動的に再利用可能にする動的割当ては、３つの仕組みの中のひとつにすぎない。従って動的割当ては、固定 IP アドレスを必要としないクライアントグループ間で IP アドレスの限られたプールを共有する為に、またはそのネットワークに一時的に接続するクライアントにアドレスを割当てる為に有効である。また動的割当ては、IP アドレスが非常に乏しく、古いクライアントが退いた時に IP アドレスを開放する事が重要であるようなネットワークにおいて、次々と接続してくる新しいクライアントに IP アドレスを割当てる為にも良い選択であろう。手動割当ては、(理由は何であれ)DHCP メカニズム以外で IP アドレスの割当てを管理する事が必要な環境において、手動で IP アドレスを設定するという間違い易いプロセスを減らす為に利用可能である。

BOOTP 規約 [7,21] の一部として説明されている BOOTP リレーエージェントの動作を利用して既存の BOOTP クライアントと DHCP サーバーとの相互運用を可能にする為に、DHCP メッセージのフォーマットは BOOTP メッセージのフォーマットに基いている。BOOTP リレーエージェントを利用する事により、物理的なネットワークセグメント毎に DHCP サーバーを持つ必要性が無くなる。

1.1 RFC1541 への変更点

この文書は RFC1541 に書かれている DHCP プロトコル仕様を更新する。新しい DHCP メッセージタイプ DHCPINFORM が追加された(詳細はセクション 3.4、4.3、4.4 参照)。セクション 4.2 と 4.3 とで定義されるように、DHCP サーバーに DHCP クライアントを識別させる分類の仕組みが、"vendor" クラスを含むように拡張されている。最低リース時間の制約が削除された。最後に、DHCP の相互運用性のテストで得られた結果として、この文書を明確にする為に多くの編集上の変更が行われた。

1.2 関連作業

動的ホスト構成の問題の一部に付いて言及しているインターネットプロトコルと関連する仕組みとが存在する。Reverse Address Resolution Protocol(RARP)[10](Dynamic RARP(DRARP)[5] で拡張が定義されているが)は、明らかにネットワークアドレス発見の問題を示しており、自動 IP アドレス割当てメカニズムを含んでいる。Trivial File Transfer Protocol(TFTP)[20] は、ブートサーバーからのブートイメージの転送を提供している。Internet Control Message Protocol(ICMP)[16] は、"ICMP redirect" メッセージを経由してホストに追加のルータを知らせる方法を提供する。さらに ICMP は、"ICMP mask request" メッセージを通してサブネットマスク情報を、(時代遅れの)"ICMP information request" メッセージを通してその他の情報を提供出来る。ホストは ICMP のルータ探索メカニズム [8] を通してルータの位置を突き止める事が出来る。

BOOTP は構成情報の集合を転送するメカニズムである。また BOOTP は拡張可能であり、幾つかの構成パラメータ用に公式な拡張 [17] が定義されている。Morgan は動的な IP アドレス割当ての為の BOOTP への拡張を提案している[15]。MIT の Athena プロジェクトで利用されている Network Information Protocol(NIP) は、動的な IP アドレス割当ての為の配布メカニズムである。Resource Location Protocol RLP[1] は、より高レベルのサービスの位置情報を提供する。Sun Microsystems のディスクレスワークステーションは、構成情報とオペレーティングシステムのコードとをディスクレスホストに送る為に、RARP と TFTP と RPC との各メカニズムを使用する "bootparams" と呼ばれるブート手続きを使用する。(Sun Microsystems、Sun Workstation、SunOS は、Sun Microsystems, Inc の商標である) また一部の Sun ネットワークも、既存ネットワーク内の新しいホストの構成を自動化する為に、DRARP と自動インストールメカニズムとを使用する。

その他の関連作業では、経路最小伝送単位(path minimum transmission unit:MTU)発見アルゴリズムが任意のネットワーク間の経路の MTU を決定できる[14]。Address Resolution Protocol(ARP)は、リソースの位置付けと選択との為のトランスポートプロトコルとして提案されている[6]。最後に、Host Requirements RFC[3,4] は、ホストの再構成の為の特定のリクエストを説明し、ディスクレスホストの初期構成の為のシナリオを提供している。

1.3 問題定義と問題点

DHCP は、Host Requirements RFC で定義されている構成パラメータを DHCP クライアントに提供するように設計されている。DHCP クライアントは DHCP 経由でパラメータを取得した後、インターネットの任意の他のホストとパケット交換できるはずである。DHCP による TCP/IP スタックパラメータは付録 A に一覧で示されている。

新しく初期化されるクライアントにとって、これらのパラメータが全て必要なわけではない。クライアントとサーバーは、そのクライアント、または特定のサブネットによって要求されるパラメータだけを伝える為に交渉すれば良い。

DHCP は IP プロトコルに直接関連しないクライアントパラメータの構成も許可しているが、要求はしていない。また DHCP は、新しく構成されたクライアントの Domain Name System(DNS)[12,13] への登録については言及しない。

DHCP はルータを構成する用途には意図されていない。

1.4 要求

この文書全体を通して、個々の要求の重要性を定義する為に使用される単語は大文字で書かれている。それらの単語は以下の通り。

"MUST": この単語または形容詞 "REQUIRED" は、その項目がこの規約における絶対の必要事項である事を意味する。
"MUST NOT": この成句は、その項目がこの規約における絶対の禁止事項である事を意味する。
"SHOULD": この単語または形容詞 "RECOMMENDED" は、特定の状況ではその項目を無視する妥当な理由があるかもしれないという事を意味する。しかしながら完全な実装が理解されるべきであり、異なる方針を選ぶ前にそのケースを注意深く考えてみるべきである。
"SHOULD NOT": この成句は、特定の状況ではその振る舞いが受け入れられる、あるいは有用でさえあるような妥当な理由が存在するかもしれないという事を意味する。しかしながら完全な実装が理解されるべきであり、その成句付きで記述された如何なる振る舞いでも、実装する前にそのケースを注意深く考えてみるべきである。
"MAY": この単語または形容詞 "OPTIONAL" は、その項目が真に任意である事を意味する。例えば、製品を強化する、あるいは特定の市場がそれを必要としているという理由で、あるベンダーはその項目を含めても良いし、別のベンダーはその同じ項目を省略しても良い。

1.5 用語

この文書では以下の用語を使用する。

"DHCP クライアント": DHCP クライアントは、ネットワークアドレスのような構成パラメータを取得する為に DHCP を使用するインターネットホストである。
"DHCP サーバー": DHCP サーバーは、DHCP クライアントに構成パラメータを返すインターネットホストである。
"BOOTP リレーエージェント": BOOTP リレーエージェントまたはリレーエージェントは、DHCP クライアントと DHCP サーバーとの間の DHCP メッセージを通過させるインターネットホストまたはルータである。DHCP は BOOTP プロトコル規約で規定されているのと同じリレーエージェントの振る舞いを使用するように設計されている。
"バインディング": バインディングは、DHCP クライアントに対応または "バインドして" いる、少なくとも IP アドレスを含む構成パラメータの集合である。バインディングは DHCP サーバーによって管理される。

1.6 設計目標

以下のリストは DHCP の一般的な設計目標である。

DHCP はポリシーではなくメカニズムであるべきである。もし必要であれば、DHCP はローカルのシステム管理者が構成パラメータを制御する事を許可しなければならない。例えば必要であれば、ローカルシステムの管理者がローカルリソースへのアクセスと割当てとに関するローカルのポリシーを強制する事が出来るべきである。
クライアントは手動設定を必要とするべきではない。個々のクライアントは、ユーザーの介入無しに適切なローカルの構成パラメータを見つける事が可能であり、それらのパラメータを自分自身の設定に組み入れる事が出来るべきである。
ネットワークは個々のクライアントの為の手動設定を要求するべきではない。通常の環境では、クライアント毎のどの構成パラメータにもネットワーク管理者が介入する必要はないべきである。
DHCP は各サブネットにサーバーを必要とするべきではない。規模と経済性との為に、DHCP はルータを通して、または BOOTP リレーエージェントの介入を通して動作しなければならない。
DHCP クライアントは、構成パラメータのリクエストに対して複数の応答を受信する用意がなければならない。信頼性を高めたりパフォーマンスを増す為に、環境によっては複数の重複した DHCP サーバーを持っても良い。
DHCP は、静的に構成されている不参加のホストや、既存のネットワークプロトコル実装と共存するべきである。
DHCP は、RFC951 と RFC1542[21] とで説明されている BOOTP リレーエージェントと協調して動作しなければならない。
DHCP は既存の BOOTP クライアントへサービスを提供しなければならない。

以下のリストはネットワーク層パラメータの伝達の為の設計目標である。
DHCP は、

どのネットワークアドレスも、一度に２つ以上の DHCP クライアントによって利用されない事を保証しなければならない。
DHCP クライアントの再起動に対して、そのクライアントの構成を維持しなければならない。可能な場合にはいつでも、DHCP クライアントは各リクエストに対して同じ構成パラメータ(例ネットワークアドレス)を割当てられるべきである。
サーバーの再起動に対して、DHCP クライアントの構成を保たなければならない。たとえそれが DHCP メカニズムの再スタートであったとしても、可能な場合にはいつでも、DHCP クライアントは同じ構成パラメータを割当てられるべきである。
新しいクライアントに対する手作業での設定を避ける為、新しいクライアントに自動で構成パラメータを割当てられる事が可能でなければならない。
特定のクライアントに対し、固定または永続的な構成パラメータの割当てをサポートしなければならない。

2. プロトコル要約

クライアントの視点から見ると、DHCP は BOOTP メカニズムの拡張である。この振る舞いにより既存の BOOTP クライアントは、その初期化ソフトウェアに何の変更も必要とされる事なく、DHCP サーバーと協調して動作する事が可能となる。RFC1542 [2] は、BOOTP と DHCP とのクライアント・サーバー間の対話について詳述している。セクション 3 と 4 とで説明されている DHCP のクライアント・サーバー間の対話を最適化する為の、幾つかの新しいオプションの対話が存在する。

図 1 は DHCP メッセージのフォーマットであり、表 1 は DHCP メッセージの各フィールドの説明である。括弧内の数値は、各フィールドのサイズをオクテット単位で表したものである。図の中で与えられているフィールドの名前は、DHCP メッセージ内のフィールドを参照する為に、この文書全体を通して使用される。

DHCP と BOOTP との間には、二つの主要な相違が存在する。第一に、DHCP はクライアントに期限付きリースのネットワークアドレスを割当てる事ができ、異なるクライアントへの一連のネットワークアドレスの再割当てを可能にするメカニズムを定義している。第二に、DHCP はクライアントが作動する為に必要な全ての IP 構成パラメータを取得するメカニズムを提供している。

DHCP は、フィールドのひとつを明確にする意図で、用語に若干の変更を取り入れている。BOOTP の "vendor extensions" フィールドは、DHCP では "options" フィールドと改名された。同様に、BOOTP の "vendor extensions" フィールド内で使用されていたタグ付きデータ項目(以前は "vendor extensions" として参照されていた)は、現在、単に "options" と名付けられている。

   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 は、DHCP サーバーへ明示的にクライアント識別子を渡す為に使用される新しいオプション、 'client identifier' を定義している。この変更は BOOTP メッセージの 'chaddr' フィールドの負担を減らしている。'chaddr' は、BOOTP 応答メッセージ送信時のハードウェアアドレスとして、および、クライアント識別子として使用されている。'client identifier' は不明確なキーで、サーバーによって内容を解釈される事はなく、例えば 'chaddr' フィールドの内容と同じハードウェアアドレスを含んでも良いし、DNS 名のような別のタイプの識別子を含んでも良い。DHCP クライアントによって選択される 'client identifier' は、そのクライアントが接続しているサブネット内でユニークでなければならない(MUST)。全てのサーバーがクライアントを正しく識別する事を確実にする為に、ある 'client identifier' をあるメッセージで使用したクライアントは、その後に続く全てのメッセージで同じ識別子を使用しなければならない(MUST)。

クライアントの起動プロセスにおける次の段階で使用される為に、DHCP はサーバーのアドレスとして 'siaddr' フィールドの解釈を明確にしている。DHCP サーバーは、もし次の起動サービス(例オペレーティングシステムの実行イメージの引き渡し)を提供する準備をしているのなら、'siaddr' フィールドに自分自身のアドレスを返しても良い。DHCP サーバーは 'server identifier' オプションに常に自分自身のアドレスを返す。

フィールド	オクテット数	説明
op	1	メッセージ op コード / メッセージタイプ 1 = BOOTREQUEST, 2 = BOOTREPLY
htype	1	ハードウェアアドレスタイプ。"Assigned Number" RFC の ARP セクション参照。例:'1' = 10mb イーサネット
hlen	1	ハードウェアアドレス長 (例:10mb イーサネットは '6')
hops	1	クライアントがゼロをセットし、リレーエージェント経由でブートする時にリレーエージェントによって任意に使用される。
xid	4	トランザクション ID。クライアントによって無作為に選択される。クライアント・サーバー間のメッセージと応答とを対応づける為に、クライアントとサーバーとによって使用される。
secs	2	クライアントによって埋められる。クライアントがアドレスの取得または更新のプロセスを開始してからの経過秒数。
flags	2	フラグ (図2参照)
ciaddr	4	クライアント IP アドレス。クライアントが BOUND、RENEW、または REBINDING 状態で、かつ ARP リクエストに応えられる時にのみ埋められる。
yiaddr	4	'あなたの(your)'(クライアントの)IP アドレス。
siaddr	4	起動処理に使用される次のサーバーの IP アドレス。DHCPOFFER、DHCPACK の中でサーバーによって返される。
giaddr	4	リレーエージェントの IP アドレス。リレーエージェント経由でのブート時に使用される。
chaddr	16	クライアントのハードウェアアドレス。
sname	64	オプションのサーバーホスト名。ヌルで終わる文字列。
file	128	ブートファイル名。ヌルで終わる文字列。DHCPDISCOVER では "generic" またはヌル。DHCPDISCOVER では完全なディレクトリパス名。
options	var	オプションパラメータフィールド。定義済みオプション一覧の文書を参照して欲しい。

表 1: DHCP メッセージのフィールドの説明

'options' フィールドは可変長である。DHCP クライアントは、少なくとも 312 オクテット長の 'options' フィールドを持つ DHCP メッセージを受け取る準備が出来ていなければならない。この要求は DHCP クライアントに、576 オクテット(IP ホストが受信する用意をしなければならない最小の IP データグラムサイズ[3])までのメッセージを受け取る準備が出来ていなければならないという事を課している。DHCP クライアントは 'maximum DHCP message size' オプションを用いて、より大きな DHCP メッセージの使用を交渉しても良い。オプションフィールドはさらに 'file' と 'sname' フィールドとに拡張されても良い。

クライアントが初期構成時(クライアントと TCP/IP ソフトウェアとが完全に構成される前)に DHCP を使用する場合、DHCP はクライアント TCP/IP ソフトウェアの創造的な動作と、RFC1122 の寛大な解釈とを必要とする。TCP/IP ソフトウェアは、IPアドレスが構成される前にクライアントのハードウェアアドレスに届いた如何なる IP パケットでも受け取り、IP 層に転送するべきである(SHOULD)。DHCP サーバーと BOOTP リレーエージェントは、TCP/IP ソフトウェアが構成される前にハードウェアユニキャストデータグラムを受け取る事の出来ないクライアントに対して DHCP メッセージを伝える事が出来ないだろう。

前の段落で議論したような、TCP/IP ソフトウェアが構成される前に IP ユニキャストデータグラムを受け取る事の出来ないクライアントを回避する為に、DHCP は 'flags' フィールド[21] を使用する。その最も左のビットは BROADCAST(B) フラグとして定義されている。このフラグの意味についてはこの文書のセクション 4.1 で議論されている。flags フィールドの残りのビットは将来の為に予約されており、クライアントによって 0 がセットされ、サーバーとリレーエージェントとには無視されなければならない(MUST)。図2は、'flags' フィールドのフォーマットである。

                                    1 1 1 1 1 1
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |B|             MBZ             |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                B:  BROADCAST flag

                MBZ:  0 でなければならない (将来の為に予約されている)

図 2: 'flags' フィールドのフォーマット

2.1 構成パラメータリポジトリ

DHCP によって提供される第一のサービスは、ネットワーククライアントにネットワークパラメータの永続的な保管場所を提供する事である。DHCP の永続的保管のモデルは、DHCP サービスがクライアント毎にキー-値を保存する形であり、キーはユニークな識別子(例えば、IP サブネット番号とサブネット内でユニークな識別子)、値はそのクライアントの構成パラメータを含む。

例えばキーは、異なるサブネット上でのハードウェアアドレスの連続または同時の再利用、およびグローバルにはユニークでないかもしれないハードウェアアドレスを考慮したペア(IP サブネット番号、ハードウェアアドレス)で良い(複合メディアやブリッジされたネットワークでは、ビットオーダーの影響で起こり得るハードウェアアドレスの重複を許容する為に、"ハードウェアアドレス" はハードウェアの型によって分類されるべきである事に注意して欲しい)。あるいはキーは、異なるサブネットに移動したか、(おそらくネットワークインターフェイスが故障し置き換えられて)ハードウェアアドレスが変わった DHCP クライアントに対し、サーバーがうまくパラメータを割当てる事を可能にするペア(IP サブネット番号、ホスト名)でも良い。このプロトコルでは、クライアントが 'client identifier' オプションを使用して明示的に識別子を提供しない限り、キーが(IP サブネット番号、ハードウェアアドレス)になるように定義されている。クライアントは、自身の構成パラメータを取得する為に DHCP サービスに問合せる事が出来る。構成パラメータリポジトリへのクライアントインターフェイスは、構成パラメータを要求するプロトコルメッセージと、構成パラメータを伝えるサーバーからの応答とで構成される。

2.2 ネットワークアドレスの動的割当て

DHCP によって提供される第二のサービスは、クライアントに一時的または永続的なネットワーク(IP)アドレスを割当てる事である。ネットワークアドレスの動的割当ての基本メカニズムは単純である: クライアントが適当な間隔でアドレスの使用を要求する。割当てメカニズム(DHCP サーバーの集合)は、要求された時間内にはそのアドレスを再割当てしない事を保証し、クライアントがアドレスを要求する度に同じネットワークアドレスを返すよう試みる。この文書では、ネットワークアドレスがクライアントに割当てられている期間を "リース(lease)"[11] と言う。クライアントは後続のリクエストでそのリースを延長しても良い。アドレスが不要になれば、クライアントはそのアドレスをサーバーに戻して開放するためにメッセージを発行しても良い。クライアントは無期限のリースを求める事で、永続的な割当てを要求しても良い。"永続的な" アドレスを割当てる場合でも、クライアントが引退した事を検出できるように、サーバーは長時間だが無期限ではないリースを配布する事を選んでも良い。

一部の環境では、利用出来るアドレスの不足の為に、ネットワークアドレスの再割当てが必要とされるだろう。そのような環境において、割当てメカニズムはリースの期限が切れたアドレスを再利用するだろう。再利用するアドレスを選択する為に、サーバーは構成情報リポジトリ内で利用可能なあらゆる情報を利用するべきである。例えばサーバーは、最も最後に使用されたアドレスを選択しても良い。割当てを行うサーバーは、一貫性のチェックとして、例えば ICMP エコーリクエストを使って、再利用するアドレスを割当てる前にそのアドレスを調べるべきである(SHOULD)。クライアントは、例えば ARP を使って、新たに受け取ったアドレスを調べるべきである(SHOULD)。

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

DHCP は、RFC951 で定義され表 1 と図 1 とで示されている BOOTP メッセージフォーマットを使用する。クライアントからサーバーに送られる各 DHCP メッセージの 'op' フィールドは、BOOTREQUEST を含む。BOOTREPLY は、サーバーからクライアントに送られる各 DHCP メッセージの 'op' フィールドで使用される。

DHCP メッセージの 'option' フィールドの最初の 4 オクテットは、それぞれ 99、130、83、99 の値(10 進)を含む(これは RFC1497[17] で定義されているのと同じ、マジッククッキー(magic cookie)である)。'option' フィールドの残りは、"オプション" と呼ばれるタグ付きパラメータのリストを含む。RFC1497 でリストされている全ての "ベンダー拡張" も、同じく DHCP オプションである。RFC1533 は DHCP で使用されるために定義されているオプションの完全なセットを与える。

これまでに幾つかのオプションが定義されてきた。ひとつの特別なオプション - "DHCP message type" オプション - は、全ての DHCP メッセージに含まれなければならない。このオプションは DHCP メッセージの "タイプ" を定義する。追加の各オプションは、その DHCP メッセージタイプに従って、許可されたり要求されたり、あるいは許可されなかったりして良い。

この文書全体を通して、'DHCP message type' オプションを含む DHCP メッセージは、そのメッセージのタイプによって参照される。例えば 'DHCP message type' オプションタイプ 1 の DHCP メッセージは、"DHCPDISCOVER" メッセージとして参照される。

3.1 クライアント-サーバーの会話 - ネットワークアドレスを割当てる

クライアント - サーバー間のプロトコルのやり取りに関する以下の要約は、表 2 に記述されている DHCP メッセージについて言及している。図 3 のタイムラインは、典型的なサーバー - クライアントの対話の時間的関係を表している。もしクライアントが自身のアドレスを知っているのなら、幾つかのステップが省略されても良い。省略されている対話に付いてはセクション 3.2 で説明されている。

クライアントは、そのローカル物理サブネットに DHCPDISCOVER メッセージをブロードキャストする。DHCPDISCOVER メッセージは、ネットワークアドレスの値とリース期間の値とを示すオプションを含んでも良い(MAY)。BOOTP リレーエージェントは、そのメッセージを異なる物理サブネット上に存在する DHCP サーバーに伝えても良い。

各サーバーは、'yiaddr' フィールドに利用可能なネットワークアドレス(そして、DHCP オプションにその他の構成パラメータ)を含む DHCPOFFER メッセージを返して良い。サーバーが提供したネットワークアドレスを別のクライアントに割当てる事を避けるようにすればこのプロトコルはより能率的に動作するが、サーバーは提供したネットワークアドレスを予約する必要はない。新しいアドレスを割当てようとする時、サーバーはそのネットワークアドレスが既に使用されていないかどうか確認するべきである(SHOULD)。例えばサーバーは ICMP エコーリクエストを使って、提供したアドレスを調査しても良い。サーバーは、新しく割当てられるアドレスの調査をネットワーク管理者が無効にする選択をしても良い(MAY)ように実装されるべきである(SHOULD)。サーバーは、必要なら BOOTP リレーエージェントを使用して、DHCPOFFER メッセージをクライアントに送信する。

メッセージ	用途
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 クライアントとサーバーとの間で交換されるメッセージのタイムライン図

クライアントは、ひとつ以上のサーバーからひとつ以上の DHCPOFFER メッセージを受信する。クライアントは複数の応答を待つ事を選択しても良い。クライアントはDHCPOFFER メッセージの中で提供された構成パラメータに基いて、構成パラメータを要求するサーバーをひとつ選択する。クライアントは DHCPREQUEST メッセージをブロードキャストする。それにはどのサーバーが選択されたかを示す 'server identifier' オプションを含まなければならず(MUST)、望みの構成値を特定する他のオプションを含んでも良い(MAY)。'requested IP address' オプションには、サーバーからの DHCPOFFER メッセージに含まれる 'yiaddr' の値がセットされていなければならない(MUST)。この DHCPREQUEST メッセージはブロードキャストであり、DHCP/BOOTP リレーエージェントを通して中継される。どの BOOTP リレーエージェントも DHCPREQUEST メッセージを元の DHCPDISCOVER メッセージを受信した同じ DHCP サーバーの集合に転送する事を確実にする手助けとなるように、DHCPREQUEST メッセージは DHCP メッセージヘッダの 'secs' フィールドに同じ値を使用しなければならず(MUST)、元の DHCPDISCOVER メッセージと同じ IP ブロードキャストアドレスに送信されなければならない(MUST)。クライアントが DHCPOFFER メッセージを受信しなかった場合、そのクライアントはタイムアウトし、DHCPDISCOVER メッセージを再送信する。
サーバーはクライアントからの DHCPREQUEST ブロードキャストを受信する。DHCPREQUEST メッセージによって選択されなかったサーバーは、そのメッセージを、クライアントがそのサーバーの申し出を断った事の通知として使用する。DHCPREQUEST メッセージで選択されたサーバーは、永続的な保管場所にそのクライアントの為のバインディングを保存し、要求したクライアントに対して構成パラメータを含む DHCPACK メッセージで応答する。'identifier'、または 'chaddr' とネットワークアドレスとの組合わせは、クライアントのリースの為のユニークな識別子を構成し、全ての DHCP メッセージ内で参照されるリースを識別する為に、クライアントとサーバーの両方によって使用される。DHCPACK メッセージ内の如何なる構成パラメータも、最初にクライアントが応答した DHCPOFFER メッセージ内の構成パラメータと競合するべきではない(SHOULD NOT)。この時点では、サーバーは提供されたネットワークアドレスを調べるべきではない(SHOULD NOT)。DHCPACK メッセージ内の 'yiaddr' フィールドは選択されたネットワークアドレスで埋められている。
選択されたサーバーが DHCPREQUEST メッセージの要求を満足させる事が出来ない(例えば、要求されたネットワークアドレスが既に割当てられている)場合、サーバーは DHCPNAK メッセージを返すべきである(SHOULD)。

サーバーは、DHCPOFFER メッセージでクライアントに提供したアドレスを利用不可としてマークしても良い(MAY)。クライアントから DHCPREQUEST メッセージを受け取らなかった場合、サーバーは DHCPOFFER メッセージ内でクライアントに提供したアドレスを利用可能としてマークするべきである(SHOULD)。
クライアントは構成パラメータを含む DHCPACK メッセージを受け取る。クライアントは(例えば、割当てられるネットワークアドレスに対して ARP を用いて)パラメータの最終確認を実行し、DHCPACK メッセージ内で指定されているリース期間を記憶するべきである(SHOULD)。この時点で、クライアントは構成される。クライアントが(例えば、ARP を利用して)そのアドレスが既に使用されている事を検出した場合、クライアントはサーバーに DHCPDECLINE メッセージを送信し、構成プロセスを再スタートしなければならない(MUST)。ループによる過度のネットワークトラフィックを避ける為に、クライアントは構成プロセスのリスタートの前に最低 10 秒は待機するべきである(SHOULD)。
クライアントが DHCPNAK メッセージを受け取った場合、クライアントは構成プロセスをリスタートする。

クライアントが DHCPACK メッセージも DHCPNAK メッセージも受け取らなかった場合、クライアントはタイムアウトし、DHCPREQUEST メッセージを再送信する。クライアントは、セクション 4.1 の再送信アルゴリズムにしたがって DHCPREQUEST を再送信する。クライアントは、クライアント(とそのクライアントの利用者)があきらめる前に過度に長く待つことなく、サーバーと連絡する十分な可能性を与えるのに十分な回数だけ、DHCPREQUEST を再送信する事を選択するべきである。例えばセクション 4.1 で説明されるような再送信を行うクライアントは、初期化手続きの再開の前に、合計 60 秒の遅延で 4 回の DHCPREQUEST メッセージを再送して良い。クライアントが再送アルゴリズムを使用した後に DHCPACK メッセージも DHCPNAK メッセージも受信しなかった場合、そのクライアントは INIT 状態に戻り、初期化プロセスを再スタートする。クライアントは、初期化プロセスが失敗しリスタートする事を利用者に知らせるべきである(SHOULD)。
サーバーに DHCPRELEASE メッセージを送信する事で、クライアントはネットワークアドレスのリースを破棄する選択をしても良い。クライアントは、DHCPRELEASE メッセージ内の 'client identifier' によって、または 'chaddr' とネットワークアドレスとによって、開放するリースを識別する。クライアントがリースを取得する時に 'client identifier' を使用した場合、そのクライアントは DHCPRELEASE メッセージ内で同じ 'client identifier' を使用しなければならない(MUST)。

3.2 クライアント-サーバーの会話 - 以前に割当てられていたネットワークアドレスを再利用する

もしクライアントが以前に割当てられていたネットワークアドレスを記憶しており、それを再利用したいならば、そのクライアントは前のセクションで説明した幾つかのステップを省略することが出来る。図 4 のタイムラインは、クライアントが以前に割当てられていたネットワークアドレスを再利用する場合の、典型的なサーバー - クライアントの会話の時間的関係を表している。

クライアントは自身のローカルサブネットに DHCPREQUEST メッセージをブロードキャストする。そのメッセージは 'requested IP address' オプションにクライアントのネットワークアドレスを含む。クライアントは自身のネットワークアドレスを受信してはいないので、'ciaddr' フィールドを埋めてはならない(MUST NOT)。BOOTP リレーエージェントは、同一サブネット外の DHCP サーバーにそのメッセージを渡す。クライアントが以前にアドレスを取得する時に 'client identifier' を使用していた場合、クライアントはこの DHCPREQUEST メッセージ内でも同じ 'client identifier' を使用しなければならない(MUST)。
クライアントの構成パラメータを知っているサーバーは、そのクライアントに DHCPACK メッセージで応じる。サーバーは、クライアントのネットワークアドレスが既に使用中かどうかを確認するべきではない(SHOULD NOT)。クライアントはこの時点で ICMP エコーリクエストメッセージに応答しても良い。
```
               サーバー        クライアント     サーバー

                  v                v               v
                  |                |               |
                  |            初期化開始          |
                  |                |               |
                  |                |               |
                  |               /|\              |
                  |  ____________/ | \___________  |
                  | /DHCPREQUEST   |  DHCPREQUEST\ |
                  |/               |              \|
                  |                |               |
               構成を              |            構成を
                 位置付け          |              位置付け
                  |                |               |
                  |\               |              /|
                  | \              |  ___________/ |
                  |  \             | /  DHCPACK    |
                  |   \ _______    |/              |
                  |     DHCPACK\   |               |
                  |            初期化完了          |
                  |              \ |               |
                  |               \|               |
                  |                |               |
                  |           (後続の              |
                  |            DHCPACKは           |
                  |            無視される)         |
                  |                |               |
                  |                |               |
                  v                v               v
```
図 4: 以前に割当てられていたネットワークアドレスを再利用する際に DHCP クライアントと DHCP サーバーとの間で交換されるメッセージのタイムライン図

クライアントの要求が無効な場合(例えば、そのクライアントが新しいサブネットに移動していた場合)、サーバーはそのクライアントに DHCPNAK メッセージを返すべきである(SHOULD)。サーバーは、自分の情報が正しいと保証できない場合には応答するべきではない(SHOULD NOT)。例えば、別のサーバーが所有する期限切れのバインディングの要求を認識したサーバーは、サーバー間で一貫性を維持する為の明示的なメカニズムを利用しているのではない限り、DHCPNAK で応じるべきではない(SHOULD NOT)。

DHCPREQUEST メッセージ内の 'giaddr' が 0x0 の場合、クライアントはサーバーと同じサブネット内に存在する。サーバーはブロードキャストアドレス 0xffffffff に DHCPNAK メッセージをブロードキャストしなければならない(MUST)。なぜなら、クライアントは正しいネットワークアドレスやサブネットマスクを持っていないかも知れないし、ARP リクエストに応えないかもしれない為である。そうでない場合('giaddr' が 0x0 ではない場合)、サーバーは 'giaddr' に記録されている BOOTP リレーエージェントの IP アドレスに DHCPNAK メッセージを送信しなければならない(MUST)。その後リレーエージェントは、たとえクライアントが新しいネットワークに移動していたとしても DHCPNAK が伝えられるように、クライアントのハードウェアアドレスに直接そのメッセージを転送する。
クライアントは構成パラメータを含む DHCPACK メッセージを受け取る。クライアントは(セクション 3.1 の)パラメータの最終確認を行い、DHCPACK メッセージ内で指定されているリース期間を憶える。特定のリースは、'client identifier' によって、または 'chaddr' とネットワークアドレスとによって暗黙的に識別される。この時点でクライアントの構成は完了する。
DHCPACK メッセージ内の IP アドレスが既に使用されている事をクライアントが検出した場合、クライアントはサーバーに DHCPDECLINE メッセージを送り、新しいネットワークアドレスを要求する事で構成プロセスを再スタートしなければならない(MUST)。この動作はクライアントが DHCP 状態図の INIT 状態に移行する事と同じで、これに付いてはセクション 4.4 で説明されている。

DHCPNAK メッセージを受信した場合、クライアントは記憶しているネットワークアドレスを再利用する事は出来ない。代わりにクライアントは構成プロセスを再スタートする事で新しいアドレスを要求しなければならず、その際にはセクション 3.1 で説明されている(省略されていない)手続きを使用する。この動作も DHCP 状態図の INIT 状態に移行する事と同じである。

DHCPACK メッセージも DHCPNAK メッセージも受信しなかった場合、クライアントはタイムアウトし、DHCPREQUEST メッセージを再送信する。クライアントはセクション 4.1 の再送信アルゴリズムにしたがって DHCPREQUEST を再送信する。クライアントは、クライアント(と、そのクライアントの利用者)があきらめる前に過度に長く待つことなく、サーバーと連絡する十分な可能性を与えるのに十分な回数だけ、DHCPREQUEST を再送信する選択をするべきである。例えば、セクション 4.1 で説明されるような再送信を行うクライアントは、初期化手続きの再開の前に、合計 60 秒の遅延で 4 回の DHCPREQUEST メッセージを再送して良い。クライアントがこの再送アルゴリズムを使用した後に DHCPACK メッセージも CHCPNAK メッセージも受信しなかった場合、リース期限の残りの間、以前に割当てられていたネットワークアドレスと構成パラメータとを使用する事を選択をしても良い(MAY)。これは図 5 のクライアント状態遷移図における BOUND 状態に移行する事と同じである。
サーバーに DHCPRELEASE メッセージを送信する事で、クライアントはネットワークアドレスのリースを破棄する選択をしても良い。クライアントは DHCPRELEASE メッセージ内の 'client identifier' によって、または 'chaddr' とネットワークアドレスとによって、開放するリースを区別する。
クライアントがローカルにネットワークアドレスを保持する場合、通常、シャットダウン時にはそのリースを破棄しない事に注意して欲しい。クライアントが明示的なリースの破棄を必要とする場合(例えば、クライアントが異なるサブネットに移動しようとする場合)にだけ、クライアントは DHCPRELEASE メッセージを送信するだろう。

3.3 時間値の説明と表現

クライアントは一定期間(無期限でも良い)のネットワークアドレスのリースを取得する。プロトコル全体を通して、時間は秒単位で表現される。時間値 0xffffffff は "無期限(infinity)" を表す為に予約されている。

クライアントとサーバーとは同期した時刻を持っていなくても良い為、DHCP メッセージにおける時間はクライアントのローカルの時刻に注目した相対的な時間として表現される。符号無し 32 ビットの秒単位の相対時間表現は、0 からおよそ 100 年までの時間の範囲を与えられる。これは DHCP で使用される相対時間を計るには十分である。

前の段落で与えられたリース期間の解釈のアルゴリズムは、クライアントとサーバーとの時計が相対的に互いに安定していると仮定している。二つの時計の流れにずれがある場合、サーバーはクライアント側の期限が切れる前にリースが切れると考えても良い。サーバーは保証の為に、ローカルのクライアント情報データベースに保存した期間より短いリース期間をクライアントに返しても良い。

3.4 外部で構成されたネットワークアドレスと共に使用するパラメータを取得する

クライアントが何らかの別の手段(例えば手動設定)でネットワークアドレスを取得していた場合、その他のローカルの構成パラメータを取得する為に DHCPINFORM リクエストメッセージを使用しても良い。その DHCPINFORM メッセージを受信したサーバーは、新しいアドレスを割当てる事なく、既存のバインディングを確認する事もなく、'yiaddr' を埋めることもリース期間パラメータを含む事もなく、クライアントにとって適切な任意の構成パラメータを持つ DHCPACK メッセージを組み立てる。サーバーは DHCPINFORM メッセージの 'ciaddr' フィールドに与えられたアドレスに、DHCPACK 応答をユニキャストするべきである(SHOULD)。

一貫性の為にサーバーは DHCPINFORM メッセージ内のネットワークアドレスを確認するべき(SHOULD)だが、既存のリースを確認してはならない(MUST NOT)。サーバーは要求してきたクライアントの為の構成パラメータを含む DHCPACK メッセージを作成し、そのクライアントに直接 DHCPACK メッセージを送信する。

3.5 DHCP におけるクライアントパラメータ

付録 A にリストされている全てのパラメータの初期化を全てのクライアントが必要とするわけではない。サーバーからクライアントへ送信される多くのパラメータを削減する為に、二つの手法が利用される。第一に、大部分のパラメータは Host Requirements RFC で定義されているデフォルト値を持っている: クライアントはサーバーからデフォルト値を上書きするパラメータを受け取らなかった場合、これらのデフォルト値を使用する。第二に、DHCPDISCOVER メッセージまたは DHCPREQUEST メッセージ内で、クライアントは自分が関心を持っている特定のパラメータのリストをサーバーに提供することが出来る。クライアントが DHCPDISCOVER メッセージ内にパラメータのリストを含めた場合、後続の全ての DHCPREQUEST メッセージ内にもそのリストを含めなければならない(MUST)。

クライアントは、サーバーがどれほどの大きさの DHCP メッセージを作成するかを知らせる為に、'maximum DHCP message size' オプションを含めるべきである(SHOULD)。それでもクライアントに返されるパラメータは、DHCP メッセージのオプションに割当てられた領域を越えても良い。その場合、'file' フィールドと 'sname' フィールドとがオプションのために使用されている事を、二つの追加オプションフラグ(これはメッセージの 'options' フィールドに現れなければならない)が表す。

クライアントは 'parameter request list' オプションを含める事で、どの構成パラメータに関心があるのかをサーバーに知らせる事が出来る。このオプションのデータ部は、要求されるオプションをタグ番号によって明示的にリストする。

さらにクライアントは、DHCPDISCOVER メッセージ内でネットワークアドレスの値とリース時間の値とを示唆しても良い。クライアントは特定の IP アドレスが割当てられる事を示唆する為に 'requested IP address' オプションを含めても良いし、好みのリース時間を示唆する為に 'IP address lease time' オプションを含めても良い。構成パラメータでこのような "ヒント" を表すその他のオプションが、DHCPDISCOVER メッセージ内や DHCPREQUEST メッセージ内で許可されている。しかしながら追加のオプションはサーバーに無視されても良く、それゆえ、複数のサーバーが幾つかのオプションに対して同一の値を返さなくても良い。'requested IP address' オプションは、クライアントが以前に取得していたネットワークパラメータを確認する時に DHCPREQUEST メッセージ内でのみ埋められる。クライアントは、BOUND、RENEWING、またはREBINDING 状態でIPアドレスが正しく構成された時にのみ、'ciaddr' フィールドを埋める。

無効な 'requested IP address' を持つ DHCPREQUEST メッセージをサーバーが受信した場合、そのサーバーは DHCPNAK メッセージをクライアントに返すべき(SHOULD)であり、システム管理者にその問題を報告する事を選択しても良い。サーバーは 'messge' オプションにエラーメッセージを含めても良い。

3.6 複数インターフェイスを持つクライアントでの DHCP の利用

複数のネットワークインターフェイスを持つクライアントは、それらの独立したインターフェイスの為の構成情報パラメータを取得する為に、各インターフェイス毎に独立して DHCP を使用しなければならない。

3.7 クライアントはいつ DHCP を使用するべきか

ローカルのネットワークパラメータが変化した時(例えば、ローカルのネットワーク設定はクライアントやユーザーに知られることなく変化しても良いので、システム起動時やローカルネットワークからの切断後)にはいつでも、IP アドレスとネットワークパラメータとを再取得または確認する為に、クライアントは DHCP を使用するべきである(SHOULD)。

クライアントが以前のネットワークアドレスを記憶しており、かつローカルの DHCP サーバーと通信できない場合、クライアントは以前のネットワークアドレスをそのリースが切れるまで使用し続けても良い。クライアントが DHCP サーバーと通信できるようになる前にリースが切れた場合、クライアントは即座に以前のネットワークアドレスの利用を中止しなければならず、その問題をローカルのユーザーに知らせても良い。

4. DHCP クライアント・サーバープロトコルの規約

このセクションにおいて私達は、DHCP サーバーが新しいアドレスの要求を満たす為にネットワークアドレスのブロックを持っていると仮定する。さらに、各サーバーは割当て済みアドレスとリースとのデータベースをローカルの永続的な保存場所に保持しているものとする。

4.1 DHCP メッセージの構築と送信

DHCP のクライアントとサーバーとは共に、メッセージの固定形式の部分のフィールドと可変長のオプション領域のタグ付きデータ項目とを追加する事により、DHCP メッセージを構築する。オプション領域は最初に 4 オクテットの 'magic cookie' (これはセクション 3 で説明されている)を含み、その後にオプションが続く。最後のオプションは通常 'end' オプションでなければならない。

DHCP はトランスポートプロトコルとして UDP を使用する。クライアントからサーバーへの DHCP メッセージは 'DHCP server' ポート(67)に送られ、サーバーからクライアントへの DHCP メッセージは 'DHCP client' ポート(68)に送られる。複数のネットワークアドレスを持つサーバー(例えばマルチホームホスト)は、送信する DHCP メッセージにどのネットワークアドレスを使用しても良い(MAY)。

'server identifier' フィールドは、DHCP メッセージにおける DHCP サーバーを識別する為と、クライアントからサーバーへの目的アドレスとしてとの両方で使用される。複数のネットワークアドレスを持つサーバーは、DHCP メッセージ内で自分を識別するものとして、自身の持つ全てのネットワークアドレスを受け付ける用意が出来ていなければならない(MUST)。潜在的に不完全なネットワークの接続性に配慮して、サーバーは 'server identifier' のアドレスに、サーバーの知る限り最もクライアントから到達し易いアドレスを選択しなければならない(MUST)。例えば DHCP サーバーと DHCP クライアントとが同じサブネットに接続している場合(即ち、クライアントからのメッセージの 'giaddr' フィールドがゼロの場合)、そのサーバーは 'server identifier' としてそのサブネット上での通信に使用しているIPアドレスを選択するべきである(SHOULD)。もしサーバーがそのサブネット上で複数の IP アドレスを使用しているなら、それらの内どのアドレスを使用しても良い。サーバーが DHCP リレーエージェントを通してメッセージを受け取った場合、(サーバーが選択を決める為のその他のより良い情報を持っていない限り)サーバーは 'server identifier' として、そのメッセージを受け取ったインターフェイスのアドレスを選択するべきである(SHOULD)。DHCP クライアントは DHCP サーバーに対する全てのユニキャストリクエストに、'server identifier' オプションで提供された IP アドレスを使用しなければならない(MUST)。

IP アドレス取得前のクライアントによる DHCP メッセージのブロードキャストは、IP ヘッダの送信元アドレスフィールドに 0 がセットされていなければならない。

クライアントからの DHCP メッセージの 'giaddr' フィールドが非ゼロである場合、サーバーは 'giaddr' で表されている BOOTP リレーエージェントの 'DHCP server' ポートに全てのメッセージを送信する。'giaddr' フィールドがゼロで 'ciaddr' フィールドが非ゼロである場合、サーバーは 'ciaddr' のアドレスに DHCPOFFER メッセージと DHCPACK メッセージとをユニキャストする。'giaddr' がゼロ、'ciaddr' がゼロ、さらにブロードキャストビットがセットされている場合、サーバーは 0xffffffff に DHCPOFFER メッセージと DHCPACK メッセージとをブロードキャストする。ブロードキャストビットがセットされておらず、'giaddr' がゼロ、'ciaddr' がゼロの場合、サーバーはクライアントのハードウェアアドレスと 'yiaddr' アドレスに DHCPOFFER メッセージと DHCPACK メッセージとをユニキャストする。全ての場合において、'giaddr' がゼロの場合、サーバーは、どの DHCPNAK メッセージも 0xffffffff にブロードキャストする。

DHCP メッセージのオプションが 'sname' フィールドと 'file' フィールドとに延長される場合、RFC1533 で規定されている値１、２または３を持つ 'option overload' オプションが 'options' フィールドに現れなければならない(MUST)。'option overload' オプションが 'options' フィールドに現れる場合、'options' フィールド内のオプションは 'end' オプションで終了しなければならず(MUST)、オプションフィールドを埋める為にひとつ以上の 'pad' オプションを含んでも良い(MAY)。(もし 'options overload' オプションで指示されいるために使用中であれば)'sname' フィールド内と 'file' フィールド内とのオプションはフィールドの先頭のオクテットから始まらなければならず(MUST)、'end' オプションで終了しなければならず(MUST)、フィールドの残りを埋める 'pad' オプションが続かなければならない(MUST)。'options'、'sname'、'file' の各フィールド内のどの個々のオプションも、完全にそのフィールド内に含まれなければならない(MUST)。全ての 'option overload' オプションが解釈されるように、'options' フィールド内のオプションは最初に解釈されなければならない(MUST)。('option overload' オプションにより 'file' フィールドが DHCP オプションを含んでいることを示している場合)'file' フィールドが次に解釈されなければならず(MUST)、その次に 'sname' フィールドが続く。

ひとつの 'option' タグ内で渡される値は、単独のオプションに有効な 255 オクテットに収まるには大き過ぎても良い(例 'router' オプション [21] 内のルータのリスト)。オプションは、そのオプションに関する文書で別に指定されていない限り、一度だけ現れる事が許される。クライアントは構成の為の単独のリストの中に同じオプションの複数のインスタンス値を鎖状につなぐ。

DHCP クライアントは全てのメッセージの再送に責任を持つ。クライアントは再送信間隔の遅延を決定する為に、ランダムな指数関数的後退アルゴリズム(randomized exponential backoff algorithm)を組み入れた再送信戦略を採用しなければならない(MUST)。再送信間隔の遅延は、クライアントとサーバーとの間のネットワークの特性に基いて、サーバーから伝えられるのに十分な時間を与えるような選択をするべきである(SHOULD)。例えば 10Mb/秒のイーサネットでは、最初の再送信までの遅延は、4 秒に -1 から + 1の範囲で選択された均等な乱数値によって乱数化された秒数であるべきである(SHOULD)。一秒以下の精度の時計を持つクライアントは、非整数の乱数値を選択しても良い。その次の再送信までの遅延は、8 秒に -1 から +1 の範囲で選択された均等な乱数値によって乱数化された秒数であるべきである(SHOULD)。再送信の遅延は、後続の再送信では最大 64 秒まで倍増化させるべきである(SHOULD)。クライアントは構成プロセスの進度を示すものとして、再送信を試行している事をユーザーに示しても良い(MAY)。

'xid' フィールドは、未決定の要求に対する DHCP メッセージを検索する為にクライアントによって使用される。DHCP クライアントは、他のクライアントによって使用される 'xid' と同一の 'xid' を使用する可能性を最小にするような方法で 'xid' を選択しなければならない(MUST)。例えば、クライアントはリブートする毎にランダムな異なる初期 'xid' を選択し、それ以降、次のリブートまで連続した 'xid' を使用しても良い。再送信毎に新しい 'xid' を選択するかどうかは実装依存である。クライアントは再送するメッセージ毎に同じ 'xid' を再利用するか、新しい 'xid' を選ぶかを選択して良い。

通常、DHCP サーバーと BOOTP リレーエージェントとは、DHCPOFFER・DHCPACK・DHCPNAKの各メッセージを、ユニキャストを使用して直接クライアントに伝えようと試みる。(IP ヘッダの)IP 目的アドレスには DHCP の 'yiaddr' アドレスがセットされ、リンク層の目的アドレスは DHCP の'chaddr' アドレスがセットされる。不幸にも幾つかのクライアント実装は、有効な IP アドレスが設定されるまで IP ユニキャストデータグラムを受け取る事が出来ない(IP アドレスが設定されるまでそのクライアントの IP アドレスには配送されず、デッドロックになる)。

プロトコルソフトウェアが IP アドレスを設定されるまでユニキャストの IP データグラムを受け取る事の出来ないクライアントは、送信する全ての DHSPDISCOVER メッセージまたは DHCPREQUEST メッセージ内の 'flags' フィールドの BROADCAST ビットを 1 にセットするべきである(SHOULD)。BROADCAST ビットは、DHCP サーバーとBOOTP リレーエージェントとがそのクライアントへの任意のメッセージを、そのクライアントのサブネットにブロードキャストする為のヒントを与える。プロトコルソフトウェアが IP アドレスを設定される前にユニキャストの IP データグラムを受け取る事の出来るクライアントは、BROADCAST ビットを 0 にクリアするべきである(SHOULD)。BROADCAST ビットの使用に派生して起こる問題について、BOOTP を明らかにする文書[21]で議論されている。

DHCP クライアントに DHCP メッセージを直接送信または中継する(即ち、'giaddr' フィールドでリレーエージェントが指定されていない)サーバーまたはリレーエージェントは、'flags' フィールド内の BROADCAST ビットを調べるべきである(SHOULD)。このビットに 1 がセットされている場合、その DHCP メッセージは、IP 目的アドレスに IP ブロードキャストアドレス(通常 0xffffffff)を使用し、リンク層目的アドレスにリンク層ブロードキャストアドレスを使用する IP ブロードキャストとして送信されるべきである(SHOULD)。BROADCAST ビットが 0 にクリアされている場合、そのメッセージは、'yiaddr' フィールドで指定された IP アドレス、'chaddr' フィールドで指定されたリンク層アドレスへの IP ユニキャストとして送信されるべきである(SHOULD)。ユニキャストが利用不可能な場合、そのメッセージは、IP 目的アドレスとして IP ブロードキャストアドレス(通常 0xffffffff)、リンク層目的アドレスとしてリンク層ブロードキャストアドレスを使用する IP ブロードキャストとして送信されても良い(MAY)。

4.2 DHCP サーバーの管理制御

DHCP サーバーは、受け取った全ての DHCPDISCOVER と DHCPREQUEST とに応える必要はない。例えば、そのネットワークに接続しているクライアントへの厳しい制御を保ちたいネットワーク管理者は、何らかの方法で事前に登録済みのクライアントにのみ DHCP サーバーが応答するように設定する選択をしても良い。DHCP 仕様は、サーバーとクライアントとが対話する事を選択した時のクライアントとサーバーとの間の対話に関してのみ記述しており、システム管理者が使用する事を望む可能性のある全ての管理制御に関して記述する事は DHCP 仕様の範囲外である。特定の DHCP サーバーはネットワーク管理者が望む任意の制御やポリシーを組み込んでも良い。

一部の環境では、DHCP サーバーは特定のクライアントへの正しいパラメータを決定する際に、DHCPDISCOVER メッセージや DHCPREQUEST メッセージに含まれるベンダークラスのオプションの値を考慮する必要があるだろう。

DHCP サーバーはクライアントとそのリースとを対応させる為に何らかのユニークな識別子を使用する必要がある。クライアントは 'client identifier' オプションを使用して明示的に識別子を提供しても良い(MAY)。クライアントが 'client identifier' を提供する場合、そのクライアントは後に続く全てのメッセージ内で同じ 'client identifier' を使用しなければならず(MUST)、サーバーはそのクライアントを識別する為にその識別子を使用しなければならない(MUST)。クライアントが 'client identifier' オプションを提供しない場合、サーバーはそのクライアントを識別する為に 'chaddr' フィールドの内容を使用しなければならない(MUST)。DHCP クライアントが自身の接続しているサブネット内でユニークな識別子を 'client identifier' オプションに使用する事は重要である。クライアントのユニークな識別子として 'chaddr' を利用する事は、その識別子が新しいクライアントに移す事の出来るハードウェアインターフェイスと対応していても良い為、予期しない結果を引き起こすかもしれない。一部のサイトでは、コンピュータ間でのハードウェアインターフェイスの移動によってクライアントのネットワークアドレスが予期せず変更される事を避ける為に、'client identifier' として製造元のシリアル番号を使用する選択をしても良い。アドレスのリースを特定のハードウェアボックスではなく DNS 名と対応させるように、'client identifier' として DNS 名を使用する選択をしても良い。

DHCP クライアントは DHCPOFFER メッセージを受信した DHCP サーバーの中からひとつを選択するのにどのような戦略を取っても良い。DHCP のクライアント実装は、利用者が直接 'vendor class identifier' の値を選択出来るようなメカニズムを提供するべきである(SHOULD)。

4.3 DHCP サーバーの振る舞い

DHCP サーバーは、クライアントからの DHCP メッセージを、そのクライアントの為に保存しているバインディングの状態に基いて処理する。DHCP サーバーはクライアントから以下のメッセージを受け取る事が出来る。

DHCPDISCOVER
DHCPREQUEST
DHCPDECLINE
DHCPRELEASE
DHCPINFORM

表3は、サーバーによる DHCP メッセージのフィールドとオプションとの利用方法を示している。このセクションの残りでは、取り得る入力メッセージ毎の DHCP サーバーの動作に付いて記述する。

4.3.1 DHCPDISCOVER メッセージ

サーバーがクライアントから DHCPDISCOVER メッセージを受け取った時、そのサーバーは要求してきたクライアントの為のネットワークアドレスを選択する。利用可能なアドレスが無い場合、サーバーはその問題をシステム管理者に報告するという選択をしても良い。アドレスが利用可能な場合、新しいアドレスは次のように選択されるべきである(SHOULD)。

そのクライアントの現在のバインディングに記録されているアドレス。そうでなければ、
そのクライアントのバインディング(現在は期限切れまたは開放済み)に記録されている以前のアドレスがサーバーの利用可能なアドレスプール内に存在し、まだ割当てられていない場合はそのアドレス。そうでなければ、
'Requested IP Address' オプションで要求されているアドレスが利用可能で、まだ割当てられていない場合はそのアドレス。そうでなければ、
利用可能なサーバーのアドレスプールから割当てられる新しいアドレス。そのアドレスは、'giaddr' が 0 の場合はメッセージを受け取ったサブネットに基いて、'giaddr' が 0 ではない場合はそのメッセージを転送したリレーエージェントのアドレスに基いて選択される。

セクション 4.2 で説明されているように、管理上の理由からサーバーは要求されたアドレスとは別のアドレスを割当てても良い(MAY)し、空きアドレスが利用可能であっても特定のクライアントにアドレスを割当てる事を拒否しても良い。

一部のネットワークアーキテクチャ(例えば、ひとつの物理ネットワークセグメントに割当てられた二つ以上の IP サブネットを持つネットワーク間)では、DHCP クライアントは 'giaddr' に書かれたアドレスではなく、別のサブネットからのアドレスを割当てられる場合もある事に注意して欲しい。即ち DHCP は、クライアントが 'giaddr' 内のサブネットからアドレスを割当てられる事を要求はしていないと言う事である。サーバーが別のサブネットを選択する事も自由であり、割当て済み IP アドレスが選ばれる方法を記述する事は DHCP 仕様の範囲外である。

DHCP の正しいオペレーションとしては要求されないが、サーバーはクライアントがそのサーバーの DHCPOFFER メッセージに応える前に、選択したネットワークアドレスを再利用するべきではない(SHOULD)。サーバーはそのアドレスをそのクライアントに提供されたものとして記録する選択をしても良い。

さらにサーバーは、以下のようにリースの期限を選択しなければならない。

クライアントが DHCPDISCOVER メッセージで明確にリースを要求しておらず、かつそのクライアントが割当て済みネットワークアドレスを持っている場合、サーバーはそのアドレスに以前に割当てられていたリース期限を返す(以前に割当てられていたアドレスの期限を延長するには、クライアントは明示的に明確なリースを要求しなければならない事に注意して欲しい)。そうでなければ、
クライアントが DHCPDISCOVER メッセージで明確にリースを要求しておらず、かつそのクライアントが割当て済みネットワークアドレスを持っていない場合、サーバーはローカルで設定されたデフォルトのリース時間を割当てる。そうでなければ、
クライアントが DHCPDISCOVER メッセージで明確にリースを要求している場合(クライアントが割当て済みネットワークアドレスを持っているかどうかとは無関係)、サーバーは(そのリースがローカルのポリシーを満たすなら)要求されたリースを返すか、あるいは別のリースを選択して良い。

フィールド	DHCPOFFER	DHCPACK	DHCPNAK
'op'	BOOTREPLY	BOOTREPLY	BOOTREPLY
'htype'	("Assigned Numbers" RFCより)
'hlen'	(オクテット単位のハードウェアアドレス長)
'hops'	0	0	0
'xid'	クライアントの DHCPDISCOVER メッセージからの 'xid'	クライアントの DHCPREQUEST メッセージからの 'xid'	クライアントの DHCPREQUEST メッセージからの 'xid'
'secs'	0	0	0
'ciaddr'	0	DHCPREQUEST からの 'ciaddr'、または 0	0
'yiaddr'	クライアントに提案された IP アドレス	クライアントに割当てられた IP アドレス
'siaddr'	次のブートストラップサーバーの IP アドレス	次のブートストラップサーバーの IP アドレス	0
'flags'	クライアントの DHCPDISCOVER メッセージからの 'flags'	クライアントの DICPREQUEST メッセージからの 'flags'	クライアントの DICPREQUEST メッセージからの 'flags'
'giaddr'	クライアントの DHCPDISCOVER メッセージからの 'giaddr'	クライアントの DICPREQUEST メッセージからの 'giaddr'	クライアントの DICPREQUEST メッセージからの 'giaddr'
'chaddr'	クライアントの DHCPDISCOVER メッセージからの 'chaddr'	クライアントの DICPREQUEST メッセージからの 'chaddr'	クライアントの DICPREQUEST メッセージからの 'chaddr'
'sname'	サーバーホスト名またはオプション	サーバーホスト名またはオプション	(未使用)
'file'	クライアントのブートファイル名またはオプション	クライアントのブートファイル名またはオプション
'options'	オプション	オプション	(未使用)

オプション	DHCPOFFER	DHCPACK	DHCPNAK
Requested IP address	MUST NOT	MUST NOT	MUST NOT
IP address lease time	MUST	MUST (DHCPREQUEST) MUST NOT (DHCPINFORM)	MUST NOT
Use 'file'/'sname' fields	MAY	MAY	MUST NOT
DHCP message type	DHCPOFFER	DHCPACK	DHCPNAK
Parameter request list	MUST NOT	MUST NOT	MUST NOT
Message	SHOULD	SHOULD	SHOULD
Client identifier	MUST NOT	MUST NOT	MAY
Vendor class identifier	MAY	MAY	MAY
Server identifier	MUST	MUST	MUST
Maximum message size	MUST NOT	MUST NOT	MUST NOT
All others	MAY	MAY	MUST NOT

表3: DHCP サーバーによって使用されるフィールドとオプション

一旦ネットワークアドレスとリースとが決定されると、サーバーは提供された構成で DHCPOFFER メッセージを形成する。クライアントがどのサーバーを選択したかに関係なくクライアントの振る舞いを予測可能なものにする為に、全ての DHCP サーバーが同じパラメータを返す事は重要である(ただし、新たに割当てられるネットワークアドレスという例外はある)。構成パラメータは以下の順序で規則を適用して選択されなければならない(MUST)。ネットワーク管理者は、複数のサーバーが同一の応答を返す事を確実にするように、それらの DHCP サーバー群を設定する責任を持つ。サーバーはクライアントに以下の内容を返さなければならない(MUST)。

このセクションの最初の規則によって決定されたクライアントのネットワークアドレス
このセクションの最初の規則によって決定されたクライアントのリース期限
次の規則従って、クライアントから要求されたパラメータ:
- サーバーがそのパラメータに明示的にデフォルト値を設定した場合、サーバーは 'option' フィールド内の適切なオプションにその値を含めなければならない(MUST)。そうでなければ、
- サーバーが、そのパラメータが Host Requirements Document で定義されているパラメータであると認識した場合、サーバーは 'option' フィールド内の適切なオプションに Host Requirements Document で与えられるパラメータのデフォルト値を含めなければならない(MUST)。そうでなければ、
- サーバーはそのパラメータに値を返してはならない(MUST NOT)。
サーバーは可能な限り多くの要求されたパラメータを提供しなければならず(MUST)、提供出来ないパラメータは省略しなければならない(MUST)。サーバーは、DHCP Options and BOOTP Vendor Extensions document において明示的に許可されていない限り、各々の要求パラメータを一回だけ含めなければならない(MUST)。
Host Requirements Document のデフォルトとは異なるバインディングのパラメータ、
そのクライアント(DHCPDISCOVER メッセージまたは DHCPREQUEST メッセージ内の 'chaddr' または 'client identifier' の内容で識別される)に特有の任意のパラメータ。例えばネットワーク管理者によって設定されたもの、
そのクライアントのクラス(DHCPDISCOVER メッセージまたは DHCPREQUEST メッセージ内の 'vendor class identifier' の内容によって識別される)に特有の任意のパラメータ。例えば、ネットワーク管理者によって設定されたもの; パラメータはクライアントのベンダークラスとサーバー内で識別されたクライアントのクラスとの完全な一致により識別されなければならない(MUST)。
そのクライアントのサブネットにおいて非デフォルト値を持つパラメータ。

クライアントがどの DHCPOFFER を受け入れるかを選択するのを助ける為に、サーバーは DHCPOFFER メッセージ内のパラメータを決定する為に使用された 'vendor class identifier' を返す選択をしても良い(MAY)。サーバーは DHCPOFFER メッセージの 'xid' フィールドに DHCPDISCOVER メッセージの 'xid' フィールドを挿入し、要求してきたクライアントにその DHCPOFFER を送信する。

4.3.2 DHCPREQUEST メッセージ

DHCPREQUEST メッセージは、サーバーからの DHCPOFFER メッセージへ応える為に、または以前に割当てられていたIPアドレスを確認する為に、またはネットワークアドレスのリースを延長する為に、クライアントから送信されて良い。DHCPREQUEST メッセージが 'server identifier' オプションを含んでいる場合、そのメッセージは DHCPOFFER メッセージへの応答である。そうでなければ、そのメッセージは既存のリースの拡張または確認の要求である。クライアントが DHCPREQUEST メッセージ内で 'client identifier' を使用した場合、そのクライアントは後に続く全てのメッセージで同じ 'client identifier' を使用しなければならない(MUST)。クライアントが DHCPDISCOVER メッセージ内に要求パラメータのリストを含めた場合、そのクライアントは後に続く全てのメッセージにそのリストを含めなければならない(MUST)。

DHCPACK メッセージ内の如何なる構成パラメータも、そのクライアントが応答した元の DHCPOFFER メッセージ内のパラメータと競合するべきではない(SHOULD NOT)。クライアントは構成の為にその DHCPACK メッセージ内のパラメータを使用するべきである(SHOULD)。

クライアントは以下のように DHCPREQUEST メッセージを送信する。

SELECTING 状態中に生成される DHCPREQUEST:

クライアントは 'server identifier' に選択したサーバーのアドレスを挿入する。'ciaddr' はゼロでなければならない(MUST)。'requested IP address' は選択された DHCPOFFER の yiaddr の値で埋められなければならない(MUST)。

クライアントは幾つかの DHCPOFFER メッセージを収集し、"最も良い" 申し出を選択しても良い事に注意して欲しい。クライアントは DHCPREQUEST メッセージ内でサーバーを識別する事でその選択を示す。クライアントが受け入れられる申し出を受信しなかった場合、クライアントは別の DHCPDISCOVER メッセージを試すという選択をしても良い。故にサーバーは、クライアントがその申し出を受けたかどうかを表す明確な DHCPREQUEST を受け取らなくても良い。如何なるネットワークアドレスの割当ても DHCPOFFER に基いては確定しない為、提案されたネットワークアドレスを後続の要求への応答において再利用する事は、サーバーの自由である。実装の詳細では、サーバーは提案されたアドレスを再利用するべきではなく(SHOULD NOT)、提案したアドレスを再利用する時期を決定する為に実装特有のタイムアウトメカニズムを使用しても良い。
INIT-REBOOT 状態中に生成される DHCPREQUEST:
クライアントが以前に割当てられていたアドレスを要求するには、'server identifier' は埋められてはならず(MUST NOT)、'requested IP address' は埋められなければならない(MUST)。'ciaddr' はゼロでなくてはならない(MUST)。クライアントは以前に割当てられキャッシュされている構成を確かめようと努力する。'requested IP address' が不適切または間違ったネットワークに基いている場合、サーバーはクライアントに DHCPNAK メッセージを送信するべきである(SHOULD)。

INIT-REBOOT 状態にあるクライアントが正しいネットワーク上に存在するかどうかの決定は、'giaddr' の内容と 'requested IP address' オプションとが調べられた上で、データベースの検索によって行われる。クライアントが誤ったネット上にいる事を DHCP サーバーが検出した場合(即ち、('giaddr' が非ゼロの時に)ローカルのサブネットマスクまたはリモートのサブネットマスクを 'requested IP address' オプションの値に適用した結果が実際の値とは一致しない場合)、サーバーはクライアントに DHCPNAK メッセージを送信するべきである(SHOULD)。

ネットワークが正しい場合、次に DHCP サーバーはクライアントの意図する IP アドレスが正しいかどうかをチェックするべきである。もしそれが不正な場合、サーバーはクライアントに DHCPNAK メッセージを送信するべきである(SHOULD)。DHCP サーバーがそのクライアントの記録を持っていない場合、サーバーは何もしてはならず(MUST)、ネットワーク管理者に警告を出力しても良い(MAY)。この振る舞いは、互いに通信を行わない DHCP サーバーが同じネット上に安全に共存する為に必要である。

DHCPREQUEST メッセージ内の 'giaddr' が 0x0 の場合、クライアントはサーバーと同じサブネット上に存在する。クライアントは正しいネットワークアドレスやサブネットマスクを持たなくても良いし、ARP リクエストに応えられなくても良いので、サーバーはブロードキャストアドレス 0xffffffff に DHCPNAK メッセージをブロードキャストしなければならない(MUST)。

DHCPREQUEST メッセージ内の 'giaddr' に 0x0 以外の値がセットされている場合、クライアントは異なるサブネットに存在する。クライアントは正しいネットワークアドレスやサブネットマスクを持たなくても良いし、ARP リクエストに応えられなくても良いので、リレーエージェントがそのクライアントに DHCPNAK をブロードキャストする。その為にサーバーは、DHCPNAK メッセージ内のブロードキャストビットをセットしなければならない(MUST)。
RENEWING 状態中に生成される DHCPREQUEST:
'server identifier' は埋められてはならず(MUST NOT)、'requested IP address' オプションも埋められてはならず(MUST NOT)、'ciaddr' はクライアントのアドレスで埋められなければならない(MUST)。この状況においてクライアントは完全に構成され、そのリースを延長しようと試みる。このメッセージはユニキャストなので、その通信にリレーエージェントを必要としない。'giaddr' は埋められていない為、DHCP サーバーは 'ciaddr' の値を信頼し、クライアントに応答する際にそれを利用する。

T1 に先立って、クライアントはそのリースを延長または再開する選択をしても良い(MAY)。サーバーは(ネットワーク管理者によるポリシーにしたがって)そのリースを延長しない事を選択しても良いが、何れにしても DHCPACK メッセージを返すべきである。
REBINDING 状態中に生成される DHCPREQUEST:
'server identifier' は埋められてはならず(MUST NOT)、'requested IP address' オプションも埋められてはならず(MUST NOT)、'ciaddr' はクライアントのアドレスで埋められなければならない(MUST)。この状況においてクライアントは完全に構成され、そのリースを延長しようと試みる。このメッセージは IP ブロードキャストアドレス 0xffffffff にブロードキャストされなければならない(MUST)。DHCP サーバーは DHCPREQUEST に応える前に 'ciaddr' の正当性を確認するべきである(SHOULD)。

REBINDING 状態のクライアントからの DHCPREQUEST は、複数の DHCP サーバーと、それらよって管理されるリースの一貫性を維持するメカニズムとを持つサイトに適応する事を目的としている。DHCP サーバーは、それを実行する為のローカルの管理権限を持っている場合にのみ、クライアントのリースを延長しても良い(MAY)。

4.3.3 DHCPDECLINE メッセージ

サーバーが DHCPDECLINE メッセージを受信した場合、クライアントは何らかの別の手段によって、提示されたネットワークアドレスが既に利用されている事を発見している。サーバーはそのネットワークアドレスを利用不可としてマークしなければならず(MUST)、可能性のある構成上の問題をローカルのシステム管理者に知らせるべきである(SHOULD)。

4.3.4 DHCPRELEASE メッセージ

DHCPRELEASE メッセージを受信した場合、サーバーはそのネットワークアドレスを未割当てとしてマークしなければならない。後にそのクライアントからの要求に応じて起こり得る再利用の為に、サーバーはそのクライアントの初期化パラメータの記録を保持するべきである(SHOULD)。

4.3.5 DHCPINFORM メッセージ

DHCPINFORM メッセージに応える時、サーバーは DHCPINFORM メッセージ内の 'ciaddr' フィールドで与えられるアドレスに直接 DHCPACK メッセージを送信する。サーバーはクライアントにリースの期限切れ時間を送信してはならず(MUST NOT)、'yiaddr' は埋めるべきではない(SHOULD NOT)。サーバーは DHCPACK メッセージ内に、セクション 4.3.1 で定義されているその他のパラメータを含める。

4.3.6 クライアントメッセージ

表 4 は、様々な状態におけるクライアントからのメッセージ間の違いを示している。

	INIT-REBOOT	SELECTING	RENEWING	REBINDING
ブロードキャスト/ユニキャスト	ブロードキャスト	ブロードキャスト	ユニキャスト	ブロードキャスト
サーバーの IP	MUST NOT	MUST	MUST NOT	MUST NOT
要求する IP	MUST	MUST	MUST NOT	MUST NOT
ciaddr	ゼロ	ゼロ	IP アドレス	IP アドレス

表 4: 様々な状態でのクライアントメッセージ

4.4 DHCP クライアントの振る舞い

図 5 は DHCP クライアントの状態遷移図である。クライアントはサーバーから以下のメッセージを受け取る可能性がある。

DHCPOFFER
DHCPACK
DHCPNAK

図 5 に DHCPINFORM メッセージは示されていない。クライアントは単に DHCPINFORM メッセージを送信し、DHCPACK メッセージを待つ。一旦クライアントがそのパラメータを選択すると、構成プロセスは完了する。

図 5 はクライアントによる DHCP メッセージ内のフィールドとオプションとの利用に付いて示している。このセクションの残りでは、個々の有り得る入力メッセージに対する DHCP クライアントの動作を説明する。これ以降のセクションの説明は、セクション 3.1 で説明されている完全な構成手続きに対応しており、それに続くセクションの文章は、セクション 3.2 で説明されている省略された構成手続きに対応している。

 --------                               -------
|        | +-------------------------->|       |<-------------------+
| INIT-  | |     +-------------------->| INIT  |                    |
| REBOOT |DHCPNAK/         +---------->|       |<---+               |
|        |再開   |         |            -------     |               |
 --------  |  DHCPNAK/     |               |                        |
    |      破棄要請        |      -/DHCPDISCOVER送信                |
-/DHCPREQUEST送信          |               |                        |
    |      |     |      DHCPACK            v        |               |
 -----------     |    (否定)/         -----------   |               |
|           |    |  DHCPDECLINE送信  |           |                  |
| REBOOTING |    |         |         | SELECTING |<----+            |
|           |    |        /          |           |     |DHCPOFFER/  |
 -----------     |       /            -----------   |  |応答収集    |
    |            |      /                  |   |       |            |
DHCPACK/         |     /  +----------------+   +-------+            |
リースを記録、タ |    |   v   提案を選択/                           |
イマT1、T2セット------------  DHCPREQUEST送信       |               |
    |   +----->|            |             DHCPNAK, リース期限切れ/  |
    |   |      | REQUESTING |                  ネットワーク停止     |
    DHCPOFFER/ |            |                       |               |
    破棄        ------------                        |               |
    |   |        |        |                   -----------           |
    |   +--------+     DHCPACK/              |           |          |
    |              リースを記録、タ     -----| REBINDING |          |
    |              イマT1、T2セット    /     |           |          |
    |                     |        DHCPACK/   -----------           |
    |                     v     リースを記録、タ    ^               |
    +----------------> -------   /イマT1、T2セット  |               |
               +----->|       |<---+                |               |
               |      | BOUND |<---+                |               |
  DHCPOFFER, DHCPACK, |       |    |          T2期限切れ/      DHCPNAK/
   DHCPNAK/破棄        -------     |          DHCPREQUESTを    ネットワーク
               |       | |         |          ブロードキャスト 停止
               +-------+ |        DHCPACK/          |               |
                    T1期限切れ/   リースを記録、タ  |               |
                 リースしたサー   イマT1、T2セット  |               |
                 バーにDHCPREQUEST |                |               |
                 送信    |   ----------             |               |
                         |  |          |------------+               |
                         +->| RENEWING |                            |
                            |          |----------------------------+
                             ----------

図5: DHCP クライアントの状態遷移図

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

クライアントは INIT 状態で始まり、DHCPDISCOVER メッセージを形成する。スタートアップでの DHCP の利用を非同期化する為に、クライアントは 1 秒から 10 秒の間のランダムな時間だけ待機するべきである(SHOULD)。クライアントは 'ciaddr' に 0x00000000 をセットする。クライアントは 'parameter request list' オプションを含める事で特定のパラメータを要求しても良い(MAY)。クライアントは 'requested IP address' と 'IP address lease time' とを含める事で、ネットワークアドレスやリース時間を提案しても良い(MAY)。DHCP 応答メッセージが必要ならば、クライアントは 'chaddr' フィールドに自身のハードウェアアドレスを含めなければならない(MUST)。セクション 4.2 で議論したように、クライアントは 'client identifier' オプションにハードウェアアドレスとは異なる固有識別子を含めても良い(MAY)。クライアントが DHCPDISCOVER メッセージ内に要求パラメータのリストを含めた場合、そのクライアントは後続の全てのメッセージにそのリストを含めなければならない(MUST)。

クライアントはランダムなトランザクション識別子を生成・記録し、'xid' フィールドにその識別子を挿入する。後にリースの期限切れを計算する為に、クライアントは自身のローカル時間を記録する。クライアントは IP ブロードキャストアドレス 0xffffffff の 'DHCP server' UDPポートに DHCPDISCOVER をブロードキャストする。

到着した DHCPOFFER メッセージの 'xid' が最新の DHCPDISCOVER メッセージの 'xid' と一致しない場合、その DHCPOFFER メッセージは暗黙的に破棄されなければならない。到着した如何なる DHCPACK メッセージも暗黙的に破棄されなければならない。

クライアントは一定期間に渡って DHCPOFFER メッセージを収集し、(おそらく多くの)受け取った DHCPOFFER メッセージの中からひとつ(例えば最初の DHCPOFFER メッセージ、あるいは以前に利用したサーバーからの DHCPOFFER メッセージ)を選択し、DHCPOFFER メッセージ内の 'server identifier' オプションからサーバーのアドレスを抽出する。クライアントがメッセージを収集する時間と、そこからひとつの DHCPOFFER を選択するために使用される仕組みとは実装依存である。

フィールド	DHCPDISCOVER DHCPINFORM	DHCPREQUEST	DHCPDECLINE, DHCPRELEASE
'op'	BOOTREQUEST	BOOTREQUEST	BOOTREQUEST
'htype'	("Assigned Numbers" RFC から)
'hlen'	(オクテット単位のハードウェアアドレス長)
'hops'	0	0	0
'xid'	クライアントによって選択	サーバーの DHCPOFFER メッセージの 'xid	クライアントによって選択
'secs'	0 または DHCP プロセスが開始されてからの秒数	0 または DHCP プロセスが開始されてからの秒数	0
'flags'	クライアントがブロードキャストでの応答を要求する場合は 'BROADCAST' フラグをセット	クライアントがブロードキャストでの応答を要求する場合は 'BROADCAST' フラグをセット
'ciaddr'	0(DHCPDISCOVER) クライアントのネットワークアドレス(DHCPINFORM)	0 またはクライアントのネットワークアドレス(BOUND/RENEW/REBIND)	0(DHCPDECLINE) ネットワークアドレス(DHCPRELEASE)
'yiaddr'	0	0	0
'siaddr'	0	0	0
'giaddr'	0	0	0
'chaddr'	クライアントのハードウェアアドレス	クライアントのハードウェアアドレス	クライアントのハードウェアアドレス
'sname'	'sname/file' オプションが指定されている場合はオプション、それ以外では未使用	'sname/file' オプションが指定されている場合はオプション、それ以外では未使用	(未使用)
'file'	'sname/file' オプションが指定されている場合はオプション、それ以外では未使用	'sname/file' オプションが指定されている場合はオプション、それ以外では未使用	(未使用)
'options'	オプション	オプション	(未使用)

オプション	DHCPDISCOVER DHCPINFORM	DHCPREQUEST	DHCPDECLINE, DHCPRELEASE

要求 IP アドレス (Requested IP address)	MAY(DISCOVER) MUST NOT(INFORM)	MUST (SELECTING または INIT-REBOOT の時) MUST NOT (BOUND または RENEWING の時)	MUST (DHCPDECLINE), MUST NOT (DHCPRELEASE)
IP アドレスリース時間 (IP address lease time)	MAY(DISCOVER) MUST NOT(INFORM)	MAY	MUST NOT
'file'/'sname' フィールドの使用	MAY	MAY	MAY
DHCP メッセージタイプ (DHCP message type)	DHCPDISCOVER/ DHCPINFORM	DHCPREQUEST	DHCPDECLINE/ DHCPRELEASE
クライアント識別子 (Client identifier)	MAY	MAY	MAY
ベンダークラス識別子 (Vendor class identifier)	MAY	MAY	MUST NOT
サーバー識別子 (Server identifier)	MUST NOT	MUST (SELECTING の後) MUST NOT (INIT-REBOOT、BOUND、RENEWING、REBINDING の後)	MUST
パラメータ要求リスト (Parameter request list)	MAY	MAY	MUST NOT
最大メッセージサイズ (Maximum message size)	MAY	MAY	MUST NOT
メッセージ (Message)	SHOULD NOT	SHOULD NOT	SHOULD
サイト固有のオプション	MAY	MAY	MUST NOT
その他	MAY	MAY	MUST NOT

表5: DHCP クライアントのフィールドとオプション

パラメータが受け入れ可能な場合、クライアントは、パラメータを提供して来たサーバーのアドレスを 'server identifier' フィールドから読み取り、DHCPREQUEST ブロードキャストメッセージの 'server identifier' フィールドにそのアドレスを入れて送信する。一旦サーバーからの DHCPACK メッセージが到達すると、クライアントは初期化され、BOUND 状態に移行する。DHCPREQUEST メッセージは DHCPOFFER メッセージと同じ 'xid' を含む。クライアントは元の要求が送られた時刻と DHCPACK メッセージのリース間隔との合計をリース期限時刻として記録する。クライアントはそのアドレスが既に利用されていない事を確実にする為に、示されたアドレスの確認を実行するべきである(SHOULD)。例えばクライアントが ARP をサポートするネットワーク上に存在する場合、クライアントは提示された内容に対する ARP リクエストを発行しても良い。提示されたアドレスに対する ARP リクエストをブロードキャストする際、同一サブネット上の他のホストの ARP キャッシュの混乱を避ける為に、クライアントは送信元ハードウェアアドレスとして自身のハードウェアアドレスを埋め、送信元 IP アドレスとして 0 を設定しなければならない。そのネットワークアドレスが既に使用されている事が判明した場合、クライアントはサーバーに DHCPDECLINE メッセージを送信しなければならない(MUST)。新しい IP アドレスをアナウンスし、同一サブネット上のホストの全ての古い ARP キャッシュエントリーをクリアする為に、クライアントは ARP 応答をブロードキャストするべきである(SHOULD)。

4.4.2 既知のネットワークアドレスでの初期化

クライアントは INIT-REBOOT 状態で始まり、DHCPREQUEST メッセージを送信する。クライアントは DHCPREQUEST メッセージ内の 'requested IP address' オプションとして、自分の知っているネットワークアドレスを挿入しなければならない(MUST)。クライアントはランダムなトランザクション識別子を生成・記録し、'xid' フィールドにその識別子を挿入する。後にリースの期限切れを計算する為に、クライアントは自身のローカル時刻を記録する。クライアントは DHCPREQUEST メッセージ内に 'server identifier' を含めてはならない(MUST NOT)。その後クライアントは、ローカルのハードウェアブロードキャストアドレス上で、'DHCP server' UDP ポートに対して DHCPREQUEST をブロードキャストする。

一旦クライアントの DHCPREQUEST メッセージ内の 'xid' フィールドと一致する DHCPACK メッセージが任意のサーバーから到達すると、クライアントは初期化され、BOUND 状態に移行する。クライアントは、DHCPREQUEST メッセージが送られた時刻と DHCPACK メッセージのリース間隔との合計をリース期限時刻として記録する。

4.4.3 外部で割当てられたネットワークアドレスでの初期化

クライアントは DHCPINFORM メッセージ送信する。クライアントは、'parameter request list' オプションを含める事で特定の構成パラメータを要求しても良い。クライアントはランダムなトランザクション識別子を生成・記録し、'xid' フィールドにその識別子を挿入する。クライアントは 'ciaddr' フィールドに自分自身のネットワークアドレスを入れる。クライアントはリース時間パラメータを要求するべきではない(SHOULD NOT)。

次にクライアントは、もし DHCP サーバーのアドレスを知っていればそのサーバーに DHCPINFORM をユニキャストし、知らなければ限定的な(全て 1 の)ブロードキャストアドレスにメッセージをブロードキャストする。DHCPINFORM メッセージは 'DHCP server' UDP ポートに向けられなければならない(MUST)。

一旦クライアントの DHCPINFORM メッセージ内の 'xid' フィールドと一致する DHCPACK メッセージが任意のサーバーから到達すると、クライアントは初期化される。

クライアントが妥当な時間内(60 秒間、またはセクション 4.1で示されるタイムアウトを使用しているなら 4 回の再試行の間)に DHCPACK を受け取らなかった場合、その問題をユーザーに知らせるメッセージを表示し、付録 A の適当なデフォルト値をそれぞれ使用して、ネットワーク処理を開始するべきである(SHOULD)。

4.4.4 ブロードキャストとユニキャストの使用

DHCP サーバーのアドレスを知っているのではない限り、DHCP クライアントは DHCPDISCOVER、DHCPREQUEST、DHCPINRFORM の各メッセージをブロードキャストする。クライアントはサーバーに DHCPRELEASE メッセージをユニキャストする。クライアントがサーバーによって提供された IP アドレスを使用を拒否するなら、クライアントは DHCPDECLINE メッセージをブロードキャストする。

INIT 状態または REBOOTING 状態において DHCP クライアントが DHCP サーバーのアドレスを知っている場合、クライアントは DHCPDISCOVER や DHCPREQUEST で IP ブロードキャストアドレスではなく、そのユニキャストアドレスを使用しても良い。同様に既知の DHCP サーバーに DHCPINFORM メッセージを送信する場合にも、クライアントはユニキャストを使用しても良い。クライアントが既知の DHCP サーバーの IP アドレス宛て DHCP メッセージからの応答を受け取らなかった場合、DHCP クライアントは IP ブロードキャストアドレスを使用するという前の状態に戻っても良い。

4.4.5 再取得と期限切れ

クライアントは T1 と T2 との二回、ネットワークアドレスのリースの延長を試みる時期を指定する。T1 は、クライアントが RENEWING 状態に入り、そのクライアントのネットワークアドレスを発行したサーバーに連絡を試みる時である。T2 は、クライアントが REBINDING 状態に入り、任意のサーバーに連絡を試みる時である。T1 は T2 よりも先でなければならず(MUST)、それぞれクライアントのリースが期限切れになるよりも前でなければならない(MUST)。

時計の同期の必要性を避ける為に、オプション内で T1 と T2 とは相対時間として表現される[2]。

時刻 T1 になるとクライアントは RENEWING 状態に移行し、(ユニキャスト経由で)リースを延長する為に DHCPREQUEST メッセージをサーバーに送信する。クライアントは DHCPREQUEST の 'ciaddr' フィールドに自身の現在のネットワークアドレスをセットする。クライアントはリース期限時刻を計算する為に、DHCPREQUEST メッセージを送信した時のローカル時間を記録する。クライアントは DHCPREQUEST メッセージ内に 'server identifier' を含めてはならない(MUST NOT)。

'xid' を伴って到着し、クライアントの DHCPREQUEST メッセージの 'xid' とは一致しない全ての DHCPACK メッセージは、暗黙的に破棄される。クライアントがサーバーから DHCPACK を受信した時、クライアントは DHCPREQUEST メッセージを送信した時刻と DHCPACK メッセージ内のリース間隔との合計をリース期限時刻として計算する。クライアントが首尾よく自身のネットワークアドレスを取得した場合、BOUND 状態に戻り、ネットワーク処理を続けて良い。

時刻 T2 までに DHCPACK が到着しない場合、クライアントは REBINDING 状態に移行し、リースを延長する為に DHCPREQUEST メッセージを(ブロードキャスト経由で)送信する。クライアントは DHCPREQUEST 内の 'ciaddr' フィールドに自身の現在のネットワークアドレスをセットする。クライアントは DHCPREQUEST メッセージ内に 'server identifier' を含めてはならない(MUST NOT)。

時刻 T1 と T2 とは、オプションを通してサーバーによって構成可能である。T1 は (0.5 * duration_of_lease) がデフォルト、T2 は (0.875 * duration_of_lease) がデフォルトである。クライアントによる再取得の同期化を避ける為に、時刻 T1 と T2 とは固定値の近辺のランダムな "あいまいな値(fuzz)" が選ばれるべきである(SHOULD)。

T1 に先立って、クライアントは自身のリースを更新または延長する事を選択しても良い(MAY)。サーバーはネットワーク管理者によって設定されたポリシーにしたがって、クライアントのリースを延長する事を選択しても良い(MAY)。サーバーは T1 と T2 とを返すべき(SHOULD)であり、その値はリースの残りの時間を考慮してオリジナルの値から調整されるべきである(SHOULD)。

RENEWING 状態と REBINDING 状態とにおいてクライアントが DHCPREQUEST メッセージへの応答を受信しなかった場合、DHCPREQUEST を再送信する前に最低 60 秒で、(RENEWING 状態の場合)T2 までの残り時間の半分の時間、または(REBINDING 状態の場合)残りのリース時間の半分の時間、クライアントは待機するべきである(SHOULD)。

クライアントが DHCPACK を受信する前にリースが切れた場合、クライアントは INIT 状態に移行し、他の全てのネットワーク処理を即座に停止し、あたかもクライアントが初期化されていないかのようにネットワークパラメータを要求しなけらばならない(MUST)。その後、以前のネットワークアドレスを割当てる DHCPACK をそのクライアントが受け取った場合、クライアントはネットワーク処理を続けるべきである(SHOULD)。クライアントが新しいネットワークアドレスを与えられた場合、クライアントは以前のネットワークアドレスを使用し続けてはならず(MUST NOT)、その問題をローカルユーザーに知らせるべきである(SHOULD)。

4.4.6 DHCPRELEASE

クライアントが自分に割当てられたネットワークアドレスをもはや必要としなくなった場合(例えばクライアントがシャットダウンする場合)、クライアントはサーバーに DHCPRELEASE メッセージを送信する。DHCP の正しい動作は DHCPRELEASE メッセージの送信に依存しない事に注意して欲しい。

5. 謝辞

DHCP とこの文書との発展における DHC WG の多くのメンバー(名前を挙げるには多すぎる!)の疲れを知らない前向きな努力に著者は感謝している。

J Allard、そして Mike Carney、Dave Lapp、Fred Lien、John Mendonca の、DHCP 相互運用性分析会議の組織における努力に感謝し、礼を述べる。

この文書の発展の一部は、Corporation for National Research Initiatives (CNRI)、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 との上に築かれている。さらに DHCP は、一般にリモートのディスクレスホストのより簡単な維持を可能にする事を目的としている。おそらく不可能ではないだろうが、そのようなホストをパスワードや鍵によって構成する事は困難かつ不便であろう。それゆえに、現在の形の DHCP は全く安全ではない。

許可されない DHCP サーバーを簡単にセットアップできる。その様なサーバーは、間違ったあるいは重複した IP アドレスや、間違った(ルータスプーフィング等を含む)経路情報、間違ったドメインネームサーバーアドレス(ネームサーバースプーフィングなど)等のような、誤ったかつ根本的に分裂した情報を送信する事が出来る。この種の情報が使用されると、攻撃者は攻撃している組織を明らかにさらに傷つける事が出来る。

悪意のある DHCP クライアントは正しいクライアントになりすまし、正しいクライアントの為に意図されている情報を収集する事が出来るだろう。リソースの動的構成が使用されている場合、悪意のあるクライアントは自身の為に全てのリソースを要求する事ができ、それによって正しいクライアントの為のリソースを拒否させる事が出来るだろう。

8. 著者のアドレス

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

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

A. ホスト構成パラメータ

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 preference level	(address) integer	HRC 3.3.1.6 HRC 3.3.1.6
Static routes, list of: destination destination mask type-of-service first-hop router ignore redirects PMTU perform PMTU discovery	(host/subnet/net) (address mask) integer (address) on/off integer on/off	HRC 3.3.1.2 HRC 3.3.1.2 HRC 3.3.1.2 HRC 3.3.1.2 HRC 3.3.1.2 MTU 6.6 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)

トップページ - 翻訳ドキュメント - RFC 2131

動的ホスト構成プロトコル Dynamic Host Configuration Protocol

この文書の位置付け

要約

目次

図一覧

表一覧

動的ホスト構成プロトコル
Dynamic Host Configuration Protocol