3. クライアント-サーバープロトコル (The Client-Server Protocol)
DHCPは、RFC 951で定義され、表1および図1に示されているBOOTPメッセージフォーマットを使用します。クライアントからサーバーに送信される各DHCPメッセージの「op」フィールドにはBOOTREQUESTが含まれます。BOOTREPLYは、サーバーからクライアントに送信される各DHCPメッセージの「op」フィールドで使用されます。
DHCPメッセージの「options」フィールドの最初の4オクテットには、それぞれ(10進数の)値99、130、83、99が含まれます(これはRFC 1497 [17]で定義されているものと同じマジッククッキーです)。「options」フィールドの残りの部分は、「オプション」と呼ばれるタグ付きパラメータのリストで構成されます。RFC 1497にリストされているすべての「ベンダー拡張」もDHCPオプションです。RFC 1533は、DHCPで使用するために定義された完全なオプションセットを示しています。
これまでにいくつかのオプションが定義されています。特定のオプション(「DHCPメッセージタイプ (DHCP Message Type)」オプション)は、すべてのDHCPメッセージに含まれなければなりません (MUST)。このオプションは、DHCPメッセージの「タイプ」を定義します。DHCPメッセージタイプに応じて、追加のオプションが許可、必須、または許可されない場合があります。
本文書全体を通して、「DHCPメッセージタイプ」オプションを含むDHCPメッセージは、メッセージのタイプによって参照されます。例えば、「DHCPメッセージタイプ」オプションタイプ1を持つDHCPメッセージは、「DHCPDISCOVER」メッセージと呼ばれます。
3.1 クライアント-サーバー相互作用 - ネットワークアドレスの割り当て (Client-server interaction - allocating a network address)
クライアントとサーバー間のプロトコル交換の以下の要約は、表2で説明されているDHCPメッセージを参照しています。図3のタイムライン図は、典型的なクライアント-サーバー相互作用におけるタイミング関係を示しています。クライアントが既にそのアドレスを知っている場合、これらのステップの一部は省略される可能性があります。この簡略化された相互作用はセクション3.2で説明されています。
1. クライアントは、ローカル物理サブネット上でDHCPDISCOVERメッセージをブロードキャストします。DHCPDISCOVERメッセージには、ネットワークアドレスとリース期間の値を提案するオプションが含まれる場合があります (MAY)。BOOTPリレーエージェントは、同じ物理サブネット上にないDHCPサーバーにメッセージを渡す場合があります。
2. 各サーバーは、「yiaddr」フィールドに利用可能なネットワークアドレスを含むDHCPOFFERメッセージで応答できます (MAY)(およびDHCPオプション内の他の構成パラメータ)。サーバーは提供されたネットワークアドレスを予約する必要はありませんが、サーバーが提供されたネットワークアドレスを別のクライアントに割り当てることを避けると、プロトコルはより効率的に動作します。新しいアドレスを割り当てる際、サーバーは提供されたネットワークアドレスがまだ使用されていないことを確認すべきです (SHOULD)。例えば、サーバーはICMPエコー要求で提供されたアドレスを調査できます。サーバーは、ネットワーク管理者が新しく割り当てられたアドレスの調査を無効にすることを選択できるように実装されるべきです (SHOULD)。サーバーは、必要に応じてBOOTPリレーエージェントを使用して、DHCPOFFERメッセージをクライアントに送信します。
DHCPメッセージ (DHCP messages)
| メッセージ | 用途 |
|---|---|
| DHCPDISCOVER | 利用可能なサーバーを見つけるためにクライアントがブロードキャスト。 |
| DHCPOFFER | DHCPDISCOVERに応答して、構成パラメータの提供とともにサーバーがクライアントに送信。 |
| DHCPREQUEST | クライアントがサーバーに送信するメッセージ。次のいずれか: (a) 1つのサーバーから提供されたパラメータを要求し、他のすべてのサーバーからの提供を暗黙的に拒否、(b) 例えばシステムの再起動後に以前に割り当てられたアドレスの正確性を確認、または (c) 特定のネットワークアドレスのリースを延長。 |
| DHCPACK | コミットされたネットワークアドレスを含む構成パラメータをサーバーがクライアントに送信。 |
| DHCPNAK | クライアントのネットワークアドレスの概念が正しくないことをサーバーがクライアントに示す(例: クライアントが新しいサブネットに移動した)、またはクライアントのリースが期限切れ。 |
| DHCPDECLINE | ネットワークアドレスが既に使用中であることをクライアントがサーバーに示す。 |
| DHCPRELEASE | ネットワークアドレスを放棄し、残りのリースをキャンセルすることをクライアントがサーバーに通知。 |
| DHCPINFORM | ローカル構成パラメータのみを要求するクライアントからサーバーへ。クライアントは既に外部で構成されたネットワークアドレスを持っている。 |
表2: DHCPメッセージ
タイムライン図 (Timeline diagram)
Server Client Server
(not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/ |
| \________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\____________ |
|/ DHCPREQUEST | DHCPREQUEST\ |
| | |
| | Commits configuration
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\ ____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
図3: 新しいネットワークアドレスを割り当てる際のDHCPクライアントと
サーバー間で交換されるメッセージのタイムライン図
3. クライアントは、1つ以上のサーバーから1つ以上のDHCPOFFERメッセージを受信します。クライアントは複数の応答を待つことを選択できます (MAY)。クライアントは、DHCPOFFERメッセージで提供された構成パラメータに基づいて、構成パラメータを要求する1つのサーバーを選択します。クライアントは、選択したサーバーを示すために「サーバー識別子」オプションを含まなければならず (MUST)、望ましい構成値を指定する他のオプションを含むことができる (MAY) DHCPREQUESTメッセージをブロードキャストします。「要求されたIPアドレス」オプションは、サーバーからのDHCPOFFERメッセージの「yiaddr」の値に設定されなければなりません (MUST)。このDHCPREQUESTメッセージは、DHCP/BOOTPリレーエージェントを介してブロードキャストおよび中継されます。BOOTPリレーエージェントが元のDHCPDISCOVERメッセージを受信したのと同じDHCPサーバーのセットにDHCPREQUESTメッセージを転送することを確実にするために、DHCPREQUESTメッセージはDHCPメッセージヘッダーの「secs」フィールドで同じ値を使用しなければならず (MUST)、元のDHCPDISCOVERメッセージと同じIPブロードキャストアドレスに送信されなければなりません (MUST)。クライアントがDHCPOFFERメッセージを受信しない場合、クライアントはタイムアウトしてDHCPDISCOVERメッセージを再送信します。
4. サーバーは、クライアントからのDHCPREQUESTブロードキャストを受信します。DHCPREQUESTメッセージによって選択されなかったサーバーは、クライアントがそのサーバーの提供を拒否したという通知としてメッセージを使用します。DHCPREQUESTメッセージで選択されたサーバーは、クライアントのバインディングを永続ストレージにコミットし、要求しているクライアントの構成パラメータを含むDHCPACKメッセージで応答します。「クライアント識別子」または「chaddr」と割り当てられたネットワークアドレスの組み合わせは、クライアントのリースの一意の識別子を構成し、DHCPメッセージで参照されるリースを識別するためにクライアントとサーバーの両方によって使用されます。DHCPACKメッセージ内の構成パラメータは、クライアントが応答している以前のDHCPOFFERメッセージ内のパラメータと競合してはなりません (SHOULD NOT)。サーバーは、この時点で提供されたネットワークアドレスを確認すべきではありません (SHOULD NOT)。DHCPACKメッセージの「yiaddr」フィールドには、選択されたネットワークアドレスが入力されます。
選択されたサーバーがDHCPREQUESTメッセージを満たすことができない場合(例えば、要求されたネットワークアドレスが既に割り当てられている場合)、サーバーはDHCPNAKメッセージで応答すべきです (SHOULD)。
サーバーは、DHCPOFFERメッセージでクライアントに提供されたアドレスを使用不可としてマークすることを選択できます (MAY)。サーバーは、そのクライアントからDHCPREQUESTメッセージを受信しない場合、DHCPOFFERメッセージでクライアントに提供されたアドレスを使用可能としてマークすべきです (SHOULD)。
5. クライアントは、構成パラメータを含むDHCPACKメッセージを受信します。クライアントは、パラメータの最終チェックを実行すべきであり (SHOULD)(例えば、割り当てられたネットワークアドレスのARP)、DHCPACKメッセージで指定されたリース期間を記録します。この時点で、クライアントは構成されています。クライアントがアドレスが既に使用中であることを検出した場合(例えば、ARPの使用を通じて)、クライアントはサーバーにDHCPDECLINEメッセージを送信しなければならず (MUST)、構成プロセスを再開します。クライアントは、ループの場合の過度のネットワークトラフィックを避けるために、構成プロセスを再開する前に最低10秒待つべきです (SHOULD)。
クライアントがDHCPNAKメッセージを受信した場合、クライアントは構成プロセスを再開します。
クライアントがDHCPACKもDHCPNAKメッセージも受信しない場合、クライアントはタイムアウトし、セクション4.1の再送信アルゴリズムに従ってDHCPREQUESTメッセージを再送信します。クライアントは、あきらめる前にクライアント(およびそのクライアントのユーザー)が過度に長く待つことなく、サーバーに連絡する適切な確率を提供するために、DHCPREQUESTを十分な回数再送信することを選択すべきです (SHOULD)。例えば、セクション4.1で説明されているように再送信を行うクライアントは、初期化手順を再開する前に、合計60秒の遅延でDHCPREQUESTメッセージを4回再送信する可能性があります。再送信アルゴリズムを使用した後、クライアントがDHCPACKもDHCPNAKメッセージも受信しない場合、クライアントはINIT状態に戻り、初期化プロセスを再開します。クライアントは、初期化プロセスが失敗し、再開していることをユーザーに通知すべきです (SHOULD)。
6. クライアントは、サーバーにDHCPRELEASEメッセージを送信することにより、ネットワークアドレス上のリースを放棄することを選択できます (MAY)。クライアントは、DHCPRELEASEメッセージ内の「クライアント識別子」または「chaddr」とネットワークアドレスで、解放されるリースを識別します。クライアントがリースを取得したときに「クライアント識別子」を使用した場合、DHCPRELEASEメッセージで同じ「クライアント識別子」を使用しなければなりません (MUST)。
3.2 クライアント-サーバー相互作用 - 以前に割り当てられたネットワークアドレスの再利用 (Client-server interaction - reusing a previously allocated network address)
クライアントが以前に割り当てられたネットワークアドレスを覚えていて再利用したい場合、クライアントは前のセクションで説明されたステップの一部を省略することを選択できます (MAY)。図4のタイムライン図は、以前に割り当てられたネットワークアドレスを再利用するクライアントの典型的なクライアント-サーバー相互作用におけるタイミング関係を示しています。
1. クライアントは、ローカルサブネット上でDHCPREQUESTメッセージをブロードキャストします。メッセージには、「要求されたIPアドレス」オプションにクライアントのネットワークアドレスが含まれます。クライアントはまだネットワークアドレスを受信していないため、「ciaddr」フィールドに入力してはなりません (MUST NOT)。BOOTPリレーエージェントは、同じサブネット上にないDHCPサーバーにメッセージを渡します。クライアントがアドレスを取得するために「クライアント識別子」を使用した場合、クライアントはDHCPREQUESTメッセージで同じ「クライアント識別子」を使用しなければなりません (MUST)。
2. クライアントの構成パラメータの知識を持つサーバーは、クライアントにDHCPACKメッセージで応答します。サーバーは、クライアントのネットワークアドレスが既に使用中であることを確認すべきではありません (SHOULD NOT)。この時点で、クライアントはICMPエコー要求メッセージに応答する可能性があります。
Server Client Server
v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| _________ __/ | \__________ |
| /DHCPREQUEST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \ _______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v v
図4: 以前に割り当てられたネットワークアドレスを再利用する際の
DHCPクライアントとサーバー間で交換されるメッセージのタイムライン図
クライアントの要求が無効な場合(例えば、クライアントが新しいサブネットに移動した場合)、サーバーはクライアントにDHCPNAKメッセージで応答すべきです (SHOULD)。サーバーの情報が正確であることが保証されていない場合、サーバーは応答すべきではありません (SHOULD NOT)。例えば、別のサーバーが所有する期限切れのバインディングの要求を識別するサーバーは、サーバー間の一貫性を維持するための明示的なメカニズムを使用していない限り、DHCPNAKで応答すべきではありません (SHOULD NOT)。
DHCPREQUESTメッセージの「giaddr」が0x0の場合、クライアントはサーバーと同じサブネット上にあります。クライアントは正しいネットワークアドレスまたはサブネットマスクを持っていない可能性があり、クライアントはARP要求に応答していない可能性があるため、サーバーはDHCPNAKメッセージを0xffffffffブロードキャストアドレスにブロードキャストしなければなりません (MUST)。それ以外の場合、サーバーは、「giaddr」に記録されているように、BOOTPリレーエージェントのIPアドレスにDHCPNAKメッセージを送信しなければなりません (MUST)。リレーエージェントは、クライアントが新しいネットワークに移動した場合でもDHCPNAKを配信できるように、順番にメッセージをクライアントのハードウェアアドレスに直接転送します。
3. クライアントは、構成パラメータを含むDHCPACKメッセージを受信します。クライアントは、パラメータの最終チェックを実行し(セクション3.1と同様)、DHCPACKメッセージで指定されたリース期間を記録します。特定のリースは、「クライアント識別子」または「chaddr」とネットワークアドレスによって暗黙的に識別されます。この時点で、クライアントは構成されています。
クライアントがDHCPACKメッセージのIPアドレスが既に使用中であることを検出した場合、クライアントはサーバーにDHCPDECLINEメッセージを送信しなければならず (MUST)、新しいネットワークアドレスを要求することにより構成プロセスを再開します。このアクションは、セクション4.4で説明されているDHCP状態図のINIT状態にクライアントが移動することに対応します。
クライアントがDHCPNAKメッセージを受信した場合、記憶されたネットワークアドレスを再利用できません。代わりに、セクション3.1で説明されている(非簡略化)手順を使用して、今回は構成プロセスを再開することにより、新しいアドレスを要求しなければなりません。このアクションも、DHCP状態図のINIT状態にクライアントが移動することに対応します。
クライアントがDHCPACKもDHCPNAKメッセージも受信しない場合、クライアントはタイムアウトし、セクション4.1の再送信アルゴリズムに従ってDHCPREQUESTメッセージを再送信します。クライアントは、あきらめる前にクライアント(およびそのクライアントのユーザー)が過度に長く待つことなく、サーバーに連絡する適切な確率を提供するために、DHCPREQUESTを十分な回数再送信することを選択すべきです (SHOULD)。例えば、セクション4.1で説明されているように再送信を行うクライアントは、初期化手順を再開する前に、合計60秒の遅延でDHCPREQUESTメッセージを4回再送信する可能性があります。再送信アルゴリズムを使用した後、クライアントがDHCPACKもDHCPNAKメッセージも受信しない場合、クライアントは、未期限リースの残り時間の間、以前に割り当てられたネットワークアドレスと構成パラメータを使用することを選択できます (MAY)。これは、図5に示すクライアント状態遷移図のBOUND状態に移動することに対応します。
4. クライアントは、サーバーにDHCPRELEASEメッセージを送信することにより、ネットワークアドレス上のリースを放棄することを選択できます (MAY)。クライアントは、DHCPRELEASEメッセージ内の「クライアント識別子」または「chaddr」とネットワークアドレスで、解放されるリースを識別します。
この場合、クライアントはネットワークアドレスをローカルに保持するため、クライアントは通常、正常なシャットダウン中にリースを放棄しないことに注意してください。クライアントが明示的にリースを放棄する必要がある場合(例えば、クライアントが別のサブネットに移動しようとしている場合)にのみ、クライアントはDHCPRELEASEメッセージを送信します。
3.3 時間値の解釈と表現 (Interpretation and representation of time values)
クライアントは、固定期間(永久である可能性があります)のネットワークアドレスのリースを取得します。プロトコル全体を通して、時間は秒単位で表されます。時間値0xffffffffは「無限」を表すために予約されています。
クライアントとサーバーには同期されたクロックがない可能性があるため、DHCPメッセージでは時間は相対時間として表され、クライアントのローカルクロックに関して解釈されます。符号なし32ビットワードで秒単位で相対時間を表すと、0から約100年までの相対時間の範囲が得られ、これはDHCPを使用して測定される相対時間に十分です。
前の段落で示されたリース期間解釈アルゴリズムは、クライアントとサーバーのクロックが互いに対して安定していることを前提としています。2つのクロック間にドリフトがある場合、サーバーはクライアントよりも前にリースが期限切れになったと見なす可能性があります。補償するために、サーバーは、サーバーがクライアント情報のローカルデータベースにコミットするリース期間よりも短いリース期間をクライアントに返す場合があります (MAY)。
3.4 外部で構成されたネットワークアドレスでのパラメータの取得 (Obtaining parameters with externally configured network address)
クライアントが他の手段(例えば、手動構成)を通じてネットワークアドレスを取得した場合、DHCPINFORMリクエストメッセージを使用して他のローカル構成パラメータを取得できます (MAY)。DHCPINFORMメッセージを受信したサーバーは、新しいアドレスの割り当て、既存のバインディングの確認、「yiaddr」の入力、またはリース時間パラメータの含みなしに、クライアントに適した任意のローカル構成パラメータを含むDHCPACKメッセージを構築します。サーバーは、DHCPINFORMメッセージの「ciaddr」フィールドに示されたアドレスにDHCPACK応答をユニキャストすべきです (SHOULD)。
サーバーは、DHCPINFORMメッセージ内のネットワークアドレスの一貫性を確認すべきですが (SHOULD)、既存のリースを確認してはなりません (MUST NOT)。サーバーは、要求しているクライアントの構成パラメータを含むDHCPACKメッセージを形成し、DHCPACKメッセージをクライアントに直接送信します。
3.5 DHCPでのクライアントパラメータ (Client parameters in DHCP)
すべてのクライアントが附属書Aにリストされているすべてのパラメータの初期化を必要とするわけではありません。サーバーからクライアントに送信されるパラメータの数を減らすために、2つの技術が使用されます。第一に、ほとんどのパラメータはホスト要件RFCで定義されたデフォルト値を持っています。クライアントがデフォルトを上書きするパラメータをサーバーから受信しない場合、クライアントはそれらのデフォルト値を使用します。第二に、初期のDHCPDISCOVERまたはDHCPREQUESTメッセージで、クライアントはクライアントが関心を持つ特定のパラメータのリストをサーバーに提供できます (MAY)。クライアントがDHCPDISCOVERメッセージにパラメータのリストを含める場合、後続のDHCPREQUESTメッセージにそのリストを含めなければなりません (MUST)。
クライアントは、サーバーがDHCPメッセージをどれだけ大きくできるかをサーバーに知らせるために、「最大DHCPメッセージサイズ」オプションを含めるべきです (SHOULD)。クライアントに返されるパラメータは、DHCPメッセージのオプションに割り当てられたスペースを超える可能性があります。この場合、2つの追加のオプションフラグ(メッセージの「options」フィールドに表示されなければなりません)は、「file」および「sname」フィールドがオプションに使用されることを示します。
クライアントは、「パラメータ要求リスト (Parameter Request List)」オプションを含めることにより、クライアントが関心を持つ構成パラメータをサーバーに通知できます (MAY)。このオプションのデータ部分は、タグ番号によって要求されたオプションを明示的にリストします。
さらに、クライアントは、DHCPDISCOVERメッセージでネットワークアドレスとリース時間の値を提案できます (MAY)。クライアントは、特定のIPアドレスが割り当てられることを提案するために「要求されたIPアドレス」オプションを含めることができ (MAY)、希望するリース時間を提案するために「IPアドレスリース時間」オプションを含めることができます (MAY)。構成パラメータの「ヒント」を表す他のオプションは、DHCPDISCOVERまたはDHCPREQUESTメッセージで使用できます。ただし、追加のオプションはサーバーによって無視される可能性があり、複数のサーバーが一部のオプションに対して同じ値を返さない場合があります。「要求されたIPアドレス」オプションは、クライアントが以前に取得したネットワークパラメータを検証しているときにのみ、DHCPREQUESTメッセージに入力されます。クライアントは、BOUND、RENEWING、またはREBINDING状態でIPアドレスで正しく構成されている場合にのみ、「ciaddr」フィールドに入力します。
サーバーが無効な「要求されたIPアドレス」を持つDHCPREQUESTメッセージを受信した場合、サーバーはクライアントにDHCPNAKメッセージで応答すべきであり (SHOULD)、システム管理者に問題を報告することを選択できます (MAY)。サーバーは、「メッセージ」オプションにエラーメッセージを含めることができます (MAY)。
3.6 複数のインターフェースを持つクライアントでのDHCPの使用 (Use of DHCP in clients with multiple interfaces)
複数のネットワークインターフェースを持つクライアントは、それらの個別のインターフェースの構成情報パラメータを取得するために、各インターフェースを介して独立してDHCPを使用しなければなりません (MUST)。
3.7 クライアントがDHCPを使用すべき時 (When clients should use DHCP)
ローカルネットワークパラメータが変更された可能性がある場合は常に、クライアントはDHCPを使用してIPアドレスとネットワークパラメータを再取得または検証すべきです (SHOULD)。例えば、システム起動時またはローカルネットワークから切断された後は、ローカルネットワーク構成がクライアントまたはユーザーの知らないうちに変更されている可能性があるためです。
クライアントが以前のネットワークアドレスの知識を持ち、ローカルDHCPサーバーに連絡できない場合、クライアントはそのアドレスのリースが期限切れになるまで、以前のネットワークアドレスを使い続けることができます (MAY)。クライアントがDHCPサーバーに連絡できる前にリースが期限切れになった場合、クライアントは以前のネットワークアドレスの使用を直ちに中止しなければならず (MUST)、ローカルユーザーに問題を通知できます (MAY)。