2. プロトコル概要 (Protocol Summary)
クライアントの観点から見ると、DHCPはBOOTPメカニズムの拡張です。この動作により、既存のBOOTPクライアントは、クライアントの初期化ソフトウェアに変更を加えることなく、DHCPサーバーと相互運用できます。RFC 1542 [2]は、BOOTPとDHCPクライアント間およびサーバー間の相互作用を詳述しています [9]。DHCPクライアントとサーバー間の相互作用を最適化する、いくつかの新しいオプションのトランザクションがセクション3および4で説明されています。
図1はDHCPメッセージの形式を示し、表1はDHCPメッセージ内の各フィールドを説明しています。括弧内の数字は、各フィールドのオクテット単位のサイズを示しています。図に示されているフィールド名は、本文書全体でDHCPメッセージ内のフィールドを参照するために使用されます。
DHCPとBOOTPの間には2つの主な違いがあります。第一に、DHCPは、クライアントに有限のリース期間のネットワークアドレスを割り当てることができるメカニズムを定義し、異なるクライアントへのネットワークアドレスの連続的な再割り当てを可能にします。第二に、DHCPは、クライアントが動作するために必要なすべてのIP構成パラメータを取得するためのメカニズムを提供します。
DHCPは、フィールドの1つの意味を明確にすることを目的とした小さな用語の変更を導入しました。BOOTPの「ベンダー拡張 (Vendor Extensions)」フィールドは、DHCPでは「オプション (Options)」フィールドに名称変更されました。同様に、BOOTP「ベンダー拡張」フィールド内で使用されていたタグ付きデータ項目（以前は「ベンダー拡張」と呼ばれていた）は、現在単に「オプション」と呼ばれています。
DHCPメッセージのフォーマット (Format of a DHCP message)
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 (variable) |
+---------------------------------------------------------------+
図1: DHCPメッセージのフォーマット
DHCPは、DHCPサーバーに明示的なクライアント識別子を渡すために使用される新しい「クライアント識別子 (Client Identifier)」オプションを定義します。この変更により、BOOTPメッセージ内の「chaddr」フィールドの過負荷使用が排除されます。「chaddr」は、BOOTP応答メッセージの送信用のハードウェアアドレスとクライアント識別子の両方として使用されていました。「クライアント識別子」は不透明なキーであり、サーバーによって解釈されません。例えば、「クライアント識別符」には、「chaddr」フィールドの内容と同一のハードウェアアドレスが含まれる場合もあれば、DNS名などの別のタイプの識別子が含まれる場合もあります。DHCPクライアントが選択した「クライアント識別子」は、クライアントが接続されているサブネット内でそのクライアントに固有でなければなりません (MUST)。クライアントが1つのメッセージで「クライアント識別子」を使用する場合、すべてのサーバーがクライアントを正しく識別できるように、すべての後続メッセージで同じ識別子を使用しなければなりません (MUST)。
DHCPは、「siaddr」フィールドの解釈を、クライアントのブートストラッププロセスの次のステップで使用するサーバーのアドレスとして明確化します。DHCPサーバーは、次のブートストラップサービス（例えば、オペレーティングシステムの実行可能イメージの配信）を提供する準備ができている場合、「siaddr」フィールドに独自のアドレスを返すことができます (MAY)。DHCPサーバーは常に「サーバー識別子 (Server Identifier)」オプションに独自のアドレスを返します。
DHCPメッセージ内のフィールドの説明 (Description of fields in a DHCP message)
| フィールド | オクテット | 説明 |
|---|---|---|
| op | 1 | メッセージ操作コード / メッセージタイプ。 1 = BOOTREQUEST, 2 = BOOTREPLY |
| htype | 1 | ハードウェアアドレスタイプ、「Assigned Numbers」RFCのARPセクションを参照。例: '1' = 10mb ethernet。 |
| hlen | 1 | ハードウェアアドレス長（例: 10mb ethernetの場合'6'）。 |
| hops | 1 | クライアントがゼロに設定。リレーエージェント経由でブートする際にリレーエージェントがオプションで使用。 |
| xid | 4 | トランザクションID、クライアントが選択した乱数。クライアントとサーバーがクライアントとサーバー間のメッセージと応答を関連付けるために使用。 |
| secs | 2 | クライアントが入力。クライアントがアドレス取得または更新プロセスを開始してから経過した秒数。 |
| flags | 2 | フラグ（図2参照）。 |
| ciaddr | 4 | クライアントIPアドレス。クライアントがBOUND、RENEW、またはREBINDING状態にあり、ARP要求に応答できる場合にのみ入力。 |
| yiaddr | 4 | 'あなたの'（クライアント）IPアドレス。 |
| siaddr | 4 | ブートストラップで次に使用するサーバーのIPアドレス。DHCPOFFERおよびDHCPACKでサーバーによって返される。 |
| giaddr | 4 | リレーエージェントIPアドレス、リレーエージェント経由でブートする際に使用。 |
| chaddr | 16 | クライアントハードウェアアドレス。 |
| sname | 64 | オプションのサーバーホスト名、ヌル終端文字列。 |
| file | 128 | ブートファイル名、ヌル終端文字列。DHCPDISCOVERでは「汎用」名またはnull、DHCPOFFERでは完全修飾ディレクトリパス名。 |
| options | var | オプションパラメータフィールド。定義されたオプションのリストについては、オプションドキュメントを参照。 |
表1: DHCPメッセージ内のフィールドの説明
「options」フィールドは現在可変長です。DHCPクライアントは、少なくとも312オクテット長の「options」フィールドを持つDHCPメッセージを受信する準備をしなければなりません (MUST)。この要件は、DHCPクライアントが最大576オクテットのメッセージを受信する準備をしなければならないことを意味します。これは、IPホストが受け入れる準備をしなければならない最小のIPデータグラムサイズです [3]。DHCPクライアントは、「最大DHCPメッセージサイズ (Maximum DHCP Message Size)」オプションを通じて、より大きなDHCPメッセージの使用を交渉できます (MAY)。optionsフィールドは、「file」および「sname」フィールドにさらに拡張できます。
クライアントが初期構成にDHCPを使用する場合（クライアントのTCP/IPソフトウェアが完全に構成される前）、DHCPはクライアントのTCP/IPソフトウェアの創造的な使用とRFC 1122の自由な解釈を必要とします。TCP/IPソフトウェアは、IPアドレスが構成される前にクライアントのハードウェアアドレスに配信されたすべてのIPパケットを受け入れ、IP層に転送すべきです (SHOULD)。DHCPサーバーとBOOTPリレーエージェントは、TCP/IPソフトウェアが構成される前にハードウェアユニキャストデータグラムを受け入れることができないクライアントにDHCPメッセージを配信できない場合があります。
前の段落で説明したように、TCP/IPソフトウェアが構成される前にIPユニキャストデータグラムを受け入れることができない一部のクライアントを回避するために、DHCPは「flags」フィールドを使用します [21]。最左ビットはBROADCAST (B) フラグとして定義されています。このフラグのセマンティクスは、本文書のセクション4.1で説明されています。flagsフィールドの残りのビットは、将来の使用のために予約されています。これらはクライアントによってゼロに設定されなければならず (MUST)、サーバーとリレーエージェントによって無視されなければなりません (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フラグ
MBZ: ゼロでなければならない (MUST BE ZERO)（将来の使用のために予約）
図2: 'flags'フィールドのフォーマット
2.1 構成パラメータリポジトリ (Configuration parameters repository)
DHCPが提供する最初のサービスは、ネットワーククライアントにネットワークパラメータの永続ストレージを提供することです。DHCPの永続ストレージのモデルは、DHCPサービスが各クライアントのキーバリューエントリを格納するというものです。ここで、キーは何らかの一意の識別子（例えば、IPサブネット番号とサブネット内の一意の識別子）であり、値はクライアントの構成パラメータを含みます。
例えば、キーはペア (IP-subnet-number, hardware-address) である可能性があります（「ハードウェアアドレス」は、混合メディアブリッジネットワークでビット順序の問題によりハードウェアアドレスが重複する可能性があるため、ハードウェアタイプによって型付けされるべきであることに注意してください）。これにより、異なるサブネット上でのハードウェアアドレスの連続または同時再利用、およびグローバルに一意でない可能性があるハードウェアアドレスが可能になります。あるいは、キーはペア (IP-subnet-number, hostname) である可能性があり、サーバーが別のサブネットに移動したり、ハードウェアアドレスを変更したりしたDHCPクライアント（おそらくネットワークインターフェースの障害とハードウェアの交換のため）にインテリジェントにパラメータを割り当てることができます。プロトコルは、クライアントが「クライアント識別子」オプションを使用して明示的に識別子を提供しない限り、キーが (IP-subnet-number, hardware-address) になることを定義しています。クライアントは、DHCPサービスに問い合わせて構成パラメータを取得できます。構成パラメータリポジトリへのクライアントインターフェースは、構成パラメータを要求するプロトコルメッセージと、構成パラメータを運ぶサーバーからの応答で構成されます。
2.2 ネットワークアドレスの動的割り当て (Dynamic allocation of network addresses)
DHCPが提供する2番目のサービスは、クライアントへの一時的または永続的なネットワーク（IP）アドレスの割り当てです。ネットワークアドレスの動的割り当ての基本的なメカニズムは単純です。クライアントは一定期間アドレスの使用を要求します。割り当てメカニズム（DHCPサーバーのセット）は、要求された時間内にそのアドレスを再割り当てしないことを保証し、クライアントがアドレスを要求するたびに同じネットワークアドレスを返そうとします。本文書では、ネットワークアドレスがクライアントに割り当てられる期間を「リース (Lease)」と呼びます [11]。クライアントは、後続の要求でリースを延長できます (MAY)。クライアントは、アドレスが不要になったときにアドレスをサーバーに解放するメッセージを発行できます (MAY)。クライアントは、無限のリースを要求することで永続的な割り当てを要求できます (MAY)。「永続的な」アドレスを割り当てる場合でも、サーバーは、クライアントが廃止されたという事実の検出を可能にするために、長いが無限ではないリースを提供することを選択できます (MAY)。
一部の環境では、利用可能なアドレスの枯渇により、ネットワークアドレスを再割り当てする必要があります。このような環境では、割り当てメカニズムは、リースが期限切れになったアドレスを再利用します。サーバーは、再利用するアドレスを選択するために、構成情報リポジトリで利用可能なあらゆる情報を使用すべきです (SHOULD)。例えば、サーバーは最近割り当てられたアドレスを選択できます。整合性チェックとして、割り当てサーバーは、アドレスを割り当てる前に、例えばICMPエコー要求を使用して再利用されるアドレスを調査すべきであり (SHOULD)、クライアントは、例えばARPを使用して新しく受信したアドレスを調査すべきです (SHOULD)。