17. DHCP Server Solicitation (DHCPサーバーソリシテーション)
17. DHCP Server Solicitation (DHCPサーバーソリシテーション)
このセクションでは、クライアントに属するIAにアドレスを割り当てるサーバーをクライアントがどのように特定するかを説明します。
クライアントは、IAを作成し、サーバーにIAにIPv6アドレスを割り当てることを要求する責任があります。クライアントは最初にIAを作成し、それにIAIDを割り当てます。次に、クライアントは、IAを記述するIAオプションを含むソリシットメッセージを送信します。IAにアドレスを割り当てることができるサーバーは、アドバタイズメッセージでクライアントに応答します。次に、クライアントは、セクション18で説明されている構成交換を開始します。
クライアントが、ソリシットメッセージに応答してコミットされたアドレス割り当てとその他のリソースを含むリプライメッセージを受け入れる場合、クライアントはソリシットメッセージにラピッドコミットオプション (セクション22.14を参照) を含めます。
17.1. Client Behavior (クライアント動作)
クライアントは、ソリシットメッセージを使用して、クライアントが接続されているリンク上でアドレスを割り当てるか、他の構成パラメータを返すように構成されたDHCPサーバーを発見します。
17.1.1. Creation of Solicit Messages (ソリシットメッセージの作成)
クライアントは、「メッセージタイプ」フィールドをSOLICITに設定します。クライアントはトランザクションIDを生成し、この値を「トランザクションID」フィールドに挿入します。
クライアントは、サーバーに自分自身を識別するためにクライアント識別子オプションを含める必要があります。クライアントは、サーバーにアドレスを割り当てることを希望する任意のIAのIAオプションを含めます。クライアントは、クライアントが優先するアドレスについてサーバーへのヒントとして、IA内にアドレスを含めることができます。クライアントは、個別のオプションの定義で特に許可されている場合を除き、ソリシットメッセージに他のオプションを含めてはなりません。
クライアントは、IA_NAオプションを使用して非一時アドレスの割り当てを要求し、IA_TAオプションを使用して一時アドレスの割り当てを要求します。IA_NAまたはIA_TAオプション、または両方の組み合わせを、DHCPメッセージに含めることができます。
クライアントは、クライアントが受信することに関心のあるオプションを示すために、オプション要求オプション (セクション22.7を参照) を含める必要があります。クライアントは、オプション要求オプションで識別されたオプションのインスタンスを追加で含めることができ、データ値は、クライアントが返されることを希望するパラメータ値についてサーバーへのヒントとして機能します。
クライアントがサーバーからの再構成メッセージを受け入れる意思がある場合、クライアントは再構成受け入れオプション (セクション22.20を参照) を含めます。
17.1.2. Transmission of Solicit Messages (ソリシットメッセージの送信)
インターフェース上のクライアントからの最初のソリシットメッセージは、0からSOL_MAX_DELAYの間のランダムな時間だけ遅延する必要があります。IPv6近隣探索によってDHCPが開始されたときにソリシットメッセージが送信される場合、遅延は、IPv6近隣探索がクライアントにステートフルアドレス自動設定プロトコル (RFC 2462のセクション5.5.3を参照) を呼び出すようにした後に待機する時間の量を示します。このランダム遅延は、同時に開始するクライアント (たとえば、停電後) を非同期化します。
クライアントは、セクション14に従ってメッセージを送信し、以下のパラメータを使用します:
- IRT: SOL_TIMEOUT
- MRT: SOL_MAX_RT
- MRC: 0
- MRD: 0
クライアントがソリシットメッセージにラピッドコミットオプションを含めた場合、クライアントは、ラピッドコミットオプションを含むリプライメッセージを受信するとすぐに待機プロセスを終了します。
クライアントがアドバタイズメッセージを待機している場合、セクション14のメカニズムは、ソリシットメッセージの送信で使用するために以下のように変更されます。メッセージ交換は、最初のRTが経過する前にアドバタイズを受信しても終了しません。むしろ、クライアントは最初のRTが経過するまでアドバタイズメッセージを収集します。また、最初のRTは、RANDを厳密に0より大きく選択することにより、IRTより厳密に大きく選択する必要があります。
クライアントは、優先値255のアドバタイズメッセージを受信しない限り、最初のRT秒間アドバタイズメッセージを収集する必要があります。優先値は、優先オプション (セクション22.8) で運ばれます。優先オプションを含まないアドバタイズは、優先値0を持つと見なされます。クライアントが優先値255の優先オプションを含むアドバタイズメッセージを受信した場合、クライアントは、アドバタイズメッセージを受信したサーバーにリクエストメッセージを送信することにより、すぐにクライアント開始メッセージ交換 (セクション18で説明) を開始します。クライアントが優先値255の優先オプションを含まないアドバタイズメッセージを受信した場合、クライアントは最初のRTが経過するまで待機を続けます。最初のRTが経過し、クライアントがアドバタイズメッセージを受信した場合、クライアントはリクエストメッセージを送信することにより、クライアント開始メッセージ交換を続ける必要があります。
クライアントが最初のRTが経過する前にアドバタイズメッセージを受信しない場合、セクション14で説明されている再送信メカニズムを開始します。クライアントは、アドバタイズメッセージを受信するとすぐに再送信プロセスを終了し、クライアントは追加のアドバタイズメッセージを待機せずに受信したアドバタイズメッセージに基づいて動作します。
DHCPクライアントは、MRCとMRDを0に選択する必要があります。DHCPクライアントがMRCまたはMRDを0以外の値に設定して構成されている場合、メッセージ交換が失敗した場合、インターフェースの構成を試みることを停止する必要があります。DHCPクライアントがインターフェースの構成を試みることを停止した後、クライアントは、ユーザー入力、システム再起動、またはクライアントが新しいリンクに接続されたときなど、何らかの外部イベントの後に再構成プロセスを再開する必要があります。
17.1.3. Receipt of Advertise Messages (アドバタイズメッセージの受信)
クライアントは、NoAddrsAvailの値を含むステータスコードオプションを含むアドバタイズメッセージを無視する必要があります。ただし、クライアントは、関連するステータスメッセージをユーザーに表示する場合があります。
1つ以上の有効なアドバタイズメッセージを受信すると、クライアントは以下の基準に基づいて1つ以上のアドバタイズメッセージを選択します。
-
最高のサーバー優先値を持つアドバタイズメッセージは、他のすべてのアドバタイズメッセージよりも優先されます。
-
同じサーバー優先値を持つアドバタイズメッセージのグループ内で、クライアントは、アドバタイズメッセージがクライアントに関心のある情報をアドバタイズするサーバーを選択する場合があります。たとえば、クライアントが関心のある構成オプションを含むアドバタイズを返したサーバーを選択できます。
-
クライアントは、そのサーバーがより良いアドバタイズパラメータセット (たとえば、IAでアドバタイズされた利用可能なアドレス) を持っている場合、優先度の低いサーバーを選択する場合があります。
クライアントがアドバタイズメッセージを選択すると、クライアントは通常、各サーバーに関する情報 (サーバー優先値、アドバタイズされたアドレス、アドバタイズが受信された時刻など) を保存します。
クライアントが選択したサーバーが応答しない場合に代替サーバーを選択する必要がある場合、クライアントは上記で与えられた基準に従って次のサーバーを選択します。
17.1.4. Receipt of Reply Message (リプライメッセージの受信)
クライアントがソリシットメッセージにラピッドコミットオプションを含めた場合、ラピッドコミットオプションを含むリプライメッセージを応答として期待します。クライアントは、ラピッドコミットオプションを含まない受信したリプライメッセージを破棄します。クライアントがラピッドコミットオプションを含む有効なリプライメッセージを受信した場合、クライアントはセクション18.1.8で説明されているようにメッセージを処理します。クライアントがそのようなリプライメッセージを受信せず、有効なアドバタイズメッセージを受信した場合、クライアントはセクション17.1.3で説明されているようにアドバタイズメッセージを処理します。
クライアントがその後ラピッドコミットオプションを含む有効なリプライメッセージを受信した場合、クライアントは次のいずれかを行います:
-
セクション18.1.8で説明されているようにリプライメッセージを処理し、リクエストメッセージに応答して受信したリプライメッセージを破棄する、または
-
リクエストメッセージに応答して受信したリプライメッセージを処理し、ラピッドコミットオプションを含むリプライメッセージを破棄する。
17.2. Server Behavior (サーバー動作)
サーバーは、受信した有効なソリシットメッセージに応答してアドバタイズメッセージを送信し、クライアントにサーバーの可用性を通知します。
17.2.1. Receipt of Solicit Messages (ソリシットメッセージの受信)
サーバーは、セクション11で説明されているように、クライアントとその場所に関する情報を決定し、クライアントへの応答に関する管理ポリシーを確認します。サーバーがクライアントに応答することを許可されていない場合、サーバーはソリシットメッセージを破棄します。たとえば、サーバーの管理ポリシーが、再構成メッセージを受け入れる意思があるクライアントにのみ応答できることである場合、クライアントがソリシットメッセージ内の再構成受け入れオプションで再構成メッセージを受け入れないことを示した場合、サーバーはソリシットメッセージを破棄します。
クライアントがソリシットメッセージにラピッドコミットオプションを含めた場合、サーバーがコミットされたアドレス割り当てとその他のリソースで応答するように構成されている場合、サーバーはセクション17.2.3で説明されているようにリプライメッセージでソリシットに応答します。それ以外の場合、サーバーはラピッドコミットオプションを無視し、ラピッドコミットオプションが存在しないかのようにメッセージの残りの部分を処理します。
17.2.2. Creation and Transmission of Advertise Messages (アドバタイズメッセージの作成と送信)
サーバーは、「メッセージタイプ」フィールドをADVERTISEに設定し、クライアントから受信したソリシットメッセージのトランザクションIDフィールドの内容をアドバタイズメッセージにコピーします。サーバーは、サーバー識別子オプションにサーバー識別子を含め、クライアント識別子をソリシットメッセージからアドバタイズメッセージにコピーします。
サーバーは、アドバタイズメッセージの優先値を運ぶために優先オプションを追加する場合があります。サーバー実装は、管理者によるサーバー優先値の設定を許可する必要があります。サーバー管理者によって別途構成されていない限り、サーバー優先値はデフォルトでゼロである必要があります。
サーバーがクライアントに再構成メッセージを受け入れることを要求する場合、サーバーは再構成受け入れオプションを含めます。
サーバーは、後続のリプライメッセージでクライアントに返されるオプションを含めます。クライアントが複数のアドバタイズメッセージを受信した場合、これらのオプション内の情報は、クライアントがサーバーを選択するために使用できます。クライアントがソリシットメッセージにオプション要求オプションを含めた場合、サーバーは、サーバーがクライアントに返すように構成されているオプション要求オプションで識別されたすべてのオプションの構成パラメータを含むオプションをアドバタイズメッセージに含めます。サーバーがそのように構成されている場合、サーバーはクライアントに追加のオプションを返す場合があります。サーバーは、RFC 2460のセクション5でのパケットサイズとフラグメンテーションの使用に関する推奨事項を認識している必要があります。
クライアントからのソリシットメッセージに1つ以上のIAオプションが含まれている場合、サーバーは、クライアントのソリシットメッセージに含まれるIAに割り当てられるアドレスを含むIAオプションをアドバタイズメッセージに含める必要があります。クライアントがソリシットメッセージ内のIAにアドレスを含めた場合、サーバーは、クライアントが受信することを希望するアドレスについてのヒントとしてこれらのアドレスを使用します。
サーバーがクライアントからの後続のリクエスト内の任意のIAにアドレスを割り当てない場合、サーバーは、サーバーのDUIDを含むサーバー識別子オプション、クライアントのDUIDを含むクライアント識別子オプション、およびコードNoAddrsAvailとユーザーへのステータスメッセージを含むステータスコードオプションのみを含むアドバタイズメッセージをクライアントに送信する必要があります。
サーバーがソリシットメッセージを直接受信した場合、サーバーは、ソリシットメッセージを受信したIPデータグラム内の送信元アドレスフィールドのアドレスを使用して、アドバタイズメッセージをクライアントに直接ユニキャストします。アドバタイズメッセージは、ソリシットメッセージを受信したリンク上でユニキャストする必要があります。
ソリシットメッセージがリレーフォワードメッセージ内で受信された場合、サーバーは、「リレーメッセージ」オプションのペイロード内にアドバタイズメッセージを含むリレーリプライメッセージを構築します。リレーフォワードメッセージにインターフェースIDオプションが含まれていた場合、サーバーはそのオプションをリレーリプライメッセージにコピーします。サーバーは、リレーフォワードメッセージを受信したIPデータグラム内の送信元アドレスフィールドのアドレスを使用して、リレーリプライメッセージをリレーエージェントに直接ユニキャストします。
17.2.3. Creation and Transmission of Reply Messages (リプライメッセージの作成と送信)
サーバーは、ソリシットメッセージに応答してクライアントにリプライメッセージを送信する前に、任意のアドレスまたはその他の構成情報メッセージの割り当てをコミットする必要があります。
討論:
ソリシット-リプライメッセージ交換を使用する場合、サーバーはリプライメッセージを送信する前に任意のアドレスの割り当てをコミットします。クライアントは、リプライメッセージ内のアドレスが割り当てられたと想定でき、これらのアドレスに対してリクエストメッセージを送信する必要はありません。
通常、ソリシット-リプライメッセージ交換を使用するように構成されたサーバーは、1つのサーバーのみがソリシットメッセージに応答するように展開されます。複数のサーバーが応答する場合、クライアントは1つのサーバーからのアドレスのみを使用し、他のサーバーからのアドレスはクライアントにコミットされますが、クライアントによって使用されません。
サーバーは、リプライメッセージにラピッドコミットオプションを含めて、リプライがソリシットメッセージに応答していることを示します。
サーバーがクライアントに再構成メッセージを受け入れることを要求する場合、サーバーは再構成受け入れオプションを含めます。
サーバーは、セクション18.2.1で説明されているように、リクエストメッセージを受信したかのようにリプライメッセージを生成します。サーバーは、セクション18.2.8で説明されているようにリプライメッセージを送信します。