18. DHCP Client-Initiated Configuration Exchange (DHCPクライアント開始構成交換)

クライアントは、1つ以上のサーバーとのメッセージ交換を開始して、関心のある構成情報を取得または更新します。クライアントは、オペレーティングシステム構成プロセスの一部として、アプリケーション層によって要求されたとき、ステートレスアドレス自動設定によって要求されたとき、またはアドレスの有効期間を延長する必要があるとき (更新およびリバドメッセージ) に構成交換を開始できます。

18.1. Client Behavior (クライアント動作)

クライアントは、アドレスの通常のライフサイクルでリクエスト、更新、リバド、リリース、および拒否メッセージを使用します。クライアントが新しいリンクに移動した可能性がある場合、クライアントは確認を使用してアドレスを検証します。クライアントが構成情報を必要とするがアドレスを必要としない場合、クライアントは情報要求メッセージを使用します。

クライアントが十分なスコープの送信元アドレスを持ち、サーバーが返信アドレスとして使用でき、クライアントがサーバーからサーバーユニキャストオプション (セクション22.12) を受信した場合、クライアントは任意のリクエスト、更新、リリース、および拒否メッセージをサーバーにユニキャストする必要があります。

討論:

ユニキャストの使用は、リレーエージェントによるメッセージのリレーによる遅延を回避し、クライアントメッセージを複数のサーバーに配信することによるサーバーのオーバーヘッドと重複応答を回避できます。クライアントがすべてのDHCPメッセージをリレーエージェントを介してリレーすることを要求すると、クライアントが送信するすべてのメッセージにリレーエージェントオプションを含めることができます。サーバーは、リレーエージェントオプションが使用されない場合にのみ、ユニキャストの使用を有効にする必要があります。

18.1.1. Creation and Transmission of Request Messages (リクエストメッセージの作成と送信)

クライアントは、リクエストメッセージを使用して、IAのアドレスを入力し、他の構成情報を取得します。クライアントは、リクエストメッセージに1つ以上のIAオプションを含めます。次に、サーバーは、リプライメッセージのIAオプション内でクライアントにアドレスとIAに関する他の情報を返します。

クライアントはトランザクションIDを生成し、この値を「トランザクションID」フィールドに挿入します。

クライアントは、サーバー識別子オプションに宛先サーバーの識別子を配置します。

クライアントは、サーバーに自分自身を識別するためにクライアント識別子オプションを含める必要があります。クライアントは、1つ以上のIAオプションを含む、他の適切なオプションを追加します (クライアントがサーバーにネットワークアドレスの割り当てを要求する場合)。

クライアントは、クライアントが受信することに関心のあるオプションを示すために、オプション要求オプション (セクション22.7を参照) を含める必要があります。クライアントは、クライアントが返されることを希望するパラメータ値についてサーバーへのヒントとして、データ値を持つオプションを含めることができます。

クライアントは、再構成受け入れオプション (セクション22.20を参照) を含めて、クライアントがサーバーからの再構成メッセージを受け入れる意思があるかどうかを示します。

クライアントは、セクション14に従ってメッセージを送信し、以下のパラメータを使用します:

IRT: REQ_TIMEOUT
MRT: REQ_MAX_RT
MRC: REQ_MAX_RC
MRD: 0

メッセージ交換が失敗した場合、クライアントはクライアントのローカルポリシーに基づいてアクションを実行します。クライアントが実行できるアクションの例には、以下が含まれます:

クライアントが認識しているサーバーのリストから別のサーバーを選択する。たとえば、アドバタイズメッセージで応答したサーバー。
セクション17で説明されているサーバー発見プロセスを開始する。
構成プロセスを終了し、失敗を報告する。

18.1.2. Creation and Transmission of Confirm Messages (確認メッセージの作成と送信)

クライアントが新しいリンクに移動した可能性がある場合、そのリンク上のインターフェースに割り当てられたアドレスのプレフィックスが、クライアントが接続されているリンクに適さなくなる可能性があります。クライアントが新しいリンクに移動した可能性がある場合の例には、以下が含まれます:

クライアントの再起動。
クライアントが有線接続に物理的に接続される。
クライアントがスリープモードから復帰する。
ワイヤレス技術を使用するクライアントがアクセスポイントを変更する。

クライアントが新しいリンクに移動した可能性がある状況では、クライアントは確認/リプライメッセージ交換を開始する必要があります。クライアントは、確認メッセージに、新しいリンクに移動した可能性があるインターフェースに割り当てられた任意のIAと、それらのIAに関連付けられたアドレスを含めます。応答するサーバーは、クライアントに返されるリプライメッセージ内のステータスによって、これらのアドレスがクライアントが接続されているリンクに適切であるかどうかを示します。

クライアントは、「メッセージタイプ」フィールドをCONFIRMに設定します。クライアントはトランザクションIDを生成し、この値を「トランザクションID」フィールドに挿入します。

クライアントは、サーバーに自分自身を識別するためにクライアント識別子オプションを含める必要があります。クライアントは、確認メッセージが送信されるインターフェースに割り当てられたすべてのIAのIAオプションを含めます。IAオプションには、クライアントが現在それらのIAに関連付けているすべてのアドレスが含まれます。クライアントは、サーバーがこれらのフィールドを無視するため、任意のIA_NAオプション内のT1およびT2フィールドと、IAアドレスオプション内の優先有効期間および有効期間フィールドを0に設定する必要があります。

インターフェース上のクライアントからの最初の確認メッセージは、0からCNF_MAX_DELAYの間のランダムな時間だけ遅延する必要があります。クライアントは、セクション14に従ってメッセージを送信し、以下のパラメータを使用します:

IRT: CNF_TIMEOUT
MRT: CNF_MAX_RT
MRC: 0
MRD: CNF_MAX_RD

クライアントがメッセージ送信プロセスが終了する前に応答を受信しない場合 (セクション14で説明されているように)、クライアントは、それらのアドレスの最後に既知の有効期間を使用して任意のIPアドレスの使用を続ける必要があり、以前に取得した他の構成パラメータの使用を続ける必要があります。

18.1.3. Creation and Transmission of Renew Messages (更新メッセージの作成と送信)

IAに関連付けられたアドレスの有効および優先有効期間を延長するために、クライアントは、クライアントがIAを含むIAオプションのアドレスを取得したサーバーに更新メッセージを送信します。クライアントは、IAに関連付けられたアドレスのIAオプション内にIAアドレスオプションを含めます。サーバーは、サーバーの管理構成に従って、IA内のアドレスの新しい有効期間を決定します。サーバーは、IAに新しいアドレスを追加することもできます。サーバーは、それらのアドレスの優先および有効期間をゼロに設定することにより、IAからアドレスを削除できます。

サーバーは、IAに割り当てられたT1およびT2パラメータを通じて、クライアントが割り当てられたアドレスの有効期間を延長するためにサーバーに連絡する時間を制御します。

IAの時間T1で、クライアントは、IA内の任意のアドレスの有効期間を延長するために更新/リプライメッセージ交換を開始します。クライアントは、更新メッセージに、現在IAに割り当てられているすべてのアドレスを含むIAオプションを含めます。

サーバーがT1またはT2を0に設定した場合 (IA_NAの場合) またはT1またはT2の時間がない場合 (IA_TAの場合)、クライアントは、それぞれクライアントの裁量で更新またはリバドメッセージを送信できます。

クライアントは、「メッセージタイプ」フィールドをRENEWに設定します。クライアントはトランザクションIDを生成し、この値を「トランザクションID」フィールドに挿入します。

クライアントは、サーバー識別子オプションに宛先サーバーの識別子を配置します。

クライアントは、サーバーに自分自身を識別するためにクライアント識別子オプションを含める必要があります。クライアントは、1つ以上のIAオプションを含む、他の適切なオプションを追加します。クライアントは、更新メッセージに、クライアントが現在IAに関連付けているアドレスのリストを含める必要があります。

クライアントは、セクション14に従ってメッセージを送信し、以下のパラメータを使用します:

IRT: REN_TIMEOUT
MRT: REN_MAX_RT
MRC: 0
MRD: T2までの残り時間

メッセージ交換は、時間T2に達したときに終了します (セクション18.1.4を参照)。この時点で、クライアントはリバドメッセージ交換を開始します。

18.1.4. Creation and Transmission of Rebind Messages (リバドメッセージの作成と送信)

IAの時間T2で (時間T1で更新メッセージが送信されたサーバーが応答しなかった場合にのみ到達)、クライアントは、利用可能な任意のサーバーとのリバド/リプライメッセージ交換を開始します。クライアントは、リバドメッセージに、現在IAに割り当てられているすべてのアドレスを含むIAオプションを含めます。

クライアントは、「メッセージタイプ」フィールドをREBINDに設定します。クライアントはトランザクションIDを生成し、この値を「トランザクションID」フィールドに挿入します。

クライアントは、サーバーに自分自身を識別するためにクライアント識別子オプションを含める必要があります。クライアントは、1つ以上のIAオプションを含む、他の適切なオプションを追加します。クライアントは、リバドメッセージに、クライアントが現在IAに関連付けているアドレスのリストを含める必要があります。

クライアントは、セクション14に従ってメッセージを送信し、以下のパラメータを使用します:

IRT: REB_TIMEOUT
MRT: REB_MAX_RT
MRC: 0
MRD: すべてのアドレスの有効期間が期限切れになるまでの残り時間

メッセージ交換は、IAに割り当てられたすべてのアドレスの有効期間が期限切れになったときに終了します (セクション10を参照)。この時点で、クライアントには選択できるいくつかの代替アクションがあります。たとえば:

クライアントは、ソリシットメッセージを使用して新しいDHCPサーバーを特定し、期限切れのIAに対して新しいサーバーにリクエストを送信することを選択できます。
クライアントは他のIAに他のアドレスを持っている可能性があるため、クライアントは期限切れのIAを破棄し、他のIA内のアドレスを使用することを選択できます。

18.1.5. Creation and Transmission of Information-request Messages (情報要求メッセージの作成と送信)

クライアントは、情報要求メッセージを使用して、アドレスが割り当てられることなく構成情報を取得します。

クライアントは、「メッセージタイプ」フィールドをINFORMATION-REQUESTに設定します。クライアントはトランザクションIDを生成し、この値を「トランザクションID」フィールドに挿入します。

クライアントは、サーバーに自分自身を識別するためにクライアント識別子オプションを含める必要があります。クライアントがクライアント識別子オプションを含めない場合、サーバーはクライアント固有のオプションをクライアントに返すことができません。または、サーバーはメッセージにまったく応答しないことを選択できます。情報要求メッセージが認証される場合、クライアントはクライアント識別子オプションを含める必要があります。

インターフェース上のクライアントからの最初の情報要求メッセージは、0からINF_MAX_DELAYの間のランダムな時間だけ遅延する必要があります。クライアントは、セクション14に従ってメッセージを送信し、以下のパラメータを使用します:

IRT: INF_TIMEOUT
MRT: INF_MAX_RT
MRC: 0
MRD: 0

18.1.6. Creation and Transmission of Release Messages (リリースメッセージの作成と送信)

1つ以上のアドレスをリリースするために、クライアントはサーバーにリリースメッセージを送信します。

クライアントは、「メッセージタイプ」フィールドをRELEASEに設定します。クライアントはトランザクションIDを生成し、この値を「トランザクションID」フィールドに配置します。

クライアントは、サーバー識別子オプションにアドレスを割り当てたサーバーの識別子を配置します。

クライアントは、サーバーに自分自身を識別するためにクライアント識別子オプションを含める必要があります。クライアントは、「オプション」フィールドに、リリースしているアドレスのIAを含むオプションを含めます。リリースされるアドレスは、IAに含める必要があります。クライアントが継続して使用することを希望するIAのアドレスは、IAに追加してはなりません。

クライアントは、リリースしているアドレスのいずれも、リリースメッセージまたは後続の送信メッセージ内の送信元アドレスとして使用してはなりません。

リリースメッセージが失われる可能性があるため、クライアントは応答を受信しない場合、リリースを再送信する必要があります。ただし、クライアントが諦める前に通常の再送信タイムアウトを待機したくないシナリオ (たとえば、電源オフ時) があります。実装は1回以上再送信する必要がありますが、再送信プロセスを早期に終了することを選択できます。

クライアントは、セクション14に従ってメッセージを送信し、以下のパラメータを使用します:

IRT: REL_TIMEOUT
MRT: 0
MRC: REL_MAX_RC
MRD: 0

クライアントは、クライアントがリリースメッセージ交換プロセスを開始するとすぐに、リリースされているすべてのアドレスの使用を停止する必要があります。アドレスがリリースされたが、DHCPサーバーからのリプライが失われた場合、クライアントはリリースメッセージを再送信し、サーバーはNoBindingのステータスを示すリプライで応答する場合があります。したがって、クライアントは、リリースメッセージ交換でNoBindingのステータスを持つリプライメッセージを、エラーを示すものとして扱いません。

クライアントがアドレスをリリースできない場合、IAに割り当てられた各アドレスは、そのアドレスの有効期間が期限切れになったときにサーバーによって回収されることに注意してください。

18.1.7. Creation and Transmission of Decline Messages (拒否メッセージの作成と送信)

クライアントが、サーバーによって割り当てられたアドレスの1つ以上が別のノードによって既に使用されていることを検出した場合、クライアントはサーバーに拒否メッセージを送信して、アドレスが疑わしいことを通知します。

クライアントは、「メッセージタイプ」フィールドをDECLINEに設定します。クライアントはトランザクションIDを生成し、この値を「トランザクションID」フィールドに配置します。

クライアントは、サーバー識別子オプションにアドレスを割り当てたサーバーの識別子を配置します。

クライアントは、サーバーに自分自身を識別するためにクライアント識別子オプションを含める必要があります。クライアントは、「オプション」フィールドに、拒否しているアドレスのIAを含むオプションを含めます。拒否されるアドレスは、IAに含める必要があります。クライアントが継続して使用することを希望するIAのアドレスは、IAに追加されるべきではありません。

クライアントは、拒否しているアドレスのいずれも、拒否メッセージまたは後続の送信メッセージ内の送信元アドレスとして使用してはなりません。

クライアントは、セクション14に従ってメッセージを送信し、以下のパラメータを使用します:

IRT: DEC_TIMEOUT
MRT: 0
MRC: DEC_MAX_RC
MRD: 0

アドレスが拒否されたが、DHCPサーバーからのリプライが失われた場合、クライアントは拒否メッセージを再送信し、サーバーはNoBindingのステータスを示すリプライで応答する場合があります。したがって、クライアントは、拒否メッセージ交換でNoBindingのステータスを持つリプライメッセージを、エラーを示すものとして扱いません。

18.1.8. Receipt of Reply Messages (リプライメッセージの受信)

ソリシット (ラピッドコミットオプション付き)、リクエスト、確認、更新、リバド、または情報要求メッセージに応答して有効なリプライメッセージを受信すると、クライアントはリプライに含まれる構成情報を抽出します。クライアントは、リプライメッセージ内のステータスコードオプションから任意のステータスコードまたはメッセージを報告することを選択できます。

クライアントは、リプライメッセージで受信した任意のIA内の各アドレスに対して、トラフィックにそのアドレスを使用する前に、重複アドレス検出 [17] を実行する必要があります。アドレスのいずれかがリンク上で使用されていることが判明した場合、クライアントはセクション18.1.7で説明されているようにサーバーに拒否メッセージを送信します。

リプライがソリシット (ラピッドコミットオプション付き)、リクエスト、更新、またはリバドメッセージに応答して受信された場合、クライアントは、リプライメッセージに含まれるIAオプションから記録したIAに関する情報を更新します:

T1およびT2の時間を記録します。
IAオプション内の新しいアドレスを、クライアントによって記録されたIAに追加します。
クライアントが既にIAに記録しているIAオプション内のアドレスの有効期間を更新します。
IAアドレスオプションで有効期間が0のアドレスを、クライアントによって記録されたIAから破棄します。
クライアントがIAに記録しているが、サーバーがIAに含めなかったアドレスに関する情報を変更しないままにします。

特定の構成情報の管理は、セクション22の各オプションの定義で詳しく説明されています。

クライアントがUnspecFailを含むステータスコードのリプライメッセージを受信した場合、サーバーは、未指定の失敗条件のためにメッセージを処理できなかったことを示しています。クライアントが同じサーバーに元のメッセージを再送信して目的の操作を再試行する場合、クライアントはメッセージを再送信する速度を制限し、メッセージを再送信する期間を制限する必要があります。

クライアントがUseMulticastの値を持つステータスコードオプションのリプライメッセージを受信した場合、クライアントはメッセージの受信を記録し、メッセージが受信されたインターフェースを介してマルチキャストを使用してサーバーに後続のメッセージを送信します。クライアントは、マルチキャストを使用して元のメッセージを再送信します。

クライアントが確認メッセージに応答してサーバーからNotOnLinkステータスを受信した場合、クライアントはセクション17で説明されているようにDHCPサーバーソリシテーションを実行し、セクション18で説明されているようにクライアント開始構成を実行します。クライアントがNotOnLinkステータスを示さないリプライメッセージを受信した場合、クライアントはIA内のアドレスを使用でき、NotOnLinkステータスを示すメッセージを無視できます。

クライアントがリクエストに応答してサーバーからNotOnLinkステータスを受信した場合、クライアントは、アドレスを指定せずにリクエストを再発行するか、DHCPサーバー発見プロセスを再開できます (セクション17を参照)。

クライアントは、各IA内のステータスコードを個別に調べます。ステータスコードがNoAddrsAvailの場合、クライアントはIA内で使用可能なアドレスを受信しておらず、別のサーバーからIAのアドレスを取得しようとすることを選択できます。クライアントは、NoAddrsAvailコードを持つステータスコードオプションを含まない任意のIAからのアドレスとその他の情報を使用します。クライアントが任意のIA内でアドレスを受信しない場合、クライアントは別のサーバーを試すか (おそらくDHCPサーバー発見プロセスを再開する)、または情報要求メッセージを使用して他の構成情報のみを取得できます。

クライアントが更新またはリバドメッセージに応答してリプライメッセージを受信した場合、クライアントは各IAを個別に調べます。元の更新またはリバドメッセージ内の各IAについて、クライアントは:

IAにNoBindingステータスを持つステータスコードオプションが含まれている場合、リクエストメッセージを送信します (追加の更新/リバドメッセージは送信しません)
IAがリプライメッセージにない場合、更新/リバドを送信します
それ以外の場合、IA内の情報を受け入れます

クライアントがリリースメッセージに応答して有効なリプライメッセージを受信した場合、クライアントは、サーバーによって返されたステータスコードオプションに関係なく、リリースイベントが完了したと見なします。

クライアントが拒否メッセージに応答して有効なリプライメッセージを受信した場合、クライアントは、サーバーによって返されたステータスコードオプションに関係なく、拒否イベントが完了したと見なします。

18.2. Server Behavior (サーバー動作)

この討論では、サーバーは、クライアントにとって関心のある構成で実装固有の方法で構成されていると想定されています。

ほとんどの場合、サーバーはクライアントメッセージに応答してリプライを送信します。このリプライメッセージには、常にサーバーのDUIDを含むサーバー識別子オプションと、クライアントメッセージからのクライアント識別子オプション (存在する場合) を含める必要があります。

ほとんどのリプライメッセージで、サーバーはクライアントの構成情報を含むオプションを含めます。サーバーは、RFC 2460のセクション5でのパケットサイズとフラグメンテーションの使用に関する推奨事項を認識している必要があります。クライアントがメッセージにオプション要求オプションを含めた場合、サーバーは、サーバーがクライアントに返すように構成されているオプション要求オプションで識別されたすべてのオプションの構成パラメータを含むオプションをリプライメッセージに含めます。サーバーがそのように構成されている場合、サーバーはクライアントに追加のオプションを返す場合があります。

18.2.1. Receipt of Request Messages (リクエストメッセージの受信)

サーバーが、サーバーがユニキャストオプションを送信していないクライアントからユニキャストでリクエストメッセージを受信した場合、サーバーはリクエストメッセージを破棄し、UseMulticastの値を持つステータスコードオプション、サーバーのDUIDを含むサーバー識別子オプション、クライアントメッセージからのクライアント識別子オプション、および他のオプションを含まないリプライメッセージで応答します。

サーバーが有効なリクエストメッセージを受信した場合、サーバーはサーバーのポリシーと構成情報に従ってそのクライアントのバインディングを作成し、クライアントによって要求されたIAとその他の情報を記録します。

サーバーは、「メッセージタイプ」フィールドをREPLYに設定し、トランザクションIDをリクエストメッセージからトランザクションIDフィールドにコピーすることにより、リプライメッセージを構築します。

サーバーは、リプライメッセージにサーバーのDUIDを含むサーバー識別子オプションと、リクエストメッセージからのクライアント識別子オプションを含める必要があります。

サーバーが、クライアントメッセージ内の任意のIA内の1つ以上のIPアドレスのプレフィックスがクライアントが接続されているリンクに適切でないことを発見した場合、サーバーは、NotOnLinkの値を持つステータスコードオプションでIAをクライアントに返す必要があります。

サーバーがクライアントメッセージ内のIAに任意のアドレスを割り当てることができない場合、サーバーは、IA内にアドレスがなく、IA内にステータスコードNoAddrsAvailを含むステータスコードオプションを含むIAをリプライメッセージに含める必要があります。

サーバーがアドレスを割り当てることができる任意のIAについて、サーバーはアドレスとその他の構成パラメータを含むIAを含め、IAを新しいクライアントバインディングとして記録します。

サーバーがクライアントに再構成メッセージを受け入れることを要求する場合、サーバーは再構成受け入れオプションを含めます。

サーバーは、セクション18.2で説明されているように、クライアントに返される構成情報を含む他のオプションを含めます。

サーバーが、クライアントがリクエストメッセージに含めたIAについて、サーバーが既にIAをクライアントに関連付けるバインディングを持っていることを発見した場合、クライアントはリプライメッセージを受信しなかったリクエストメッセージを再送信しています。サーバーは、以前にキャッシュされたリプライメッセージを再送信するか、新しいリプライメッセージを送信します。

18.2.2. Receipt of Confirm Messages (確認メッセージの受信)

サーバーが確認メッセージを受信した場合、サーバーは確認メッセージ内のアドレスがクライアントが接続されているリンクに適切であるかどうかを判断します。確認メッセージ内のすべてのアドレスがこのテストに合格した場合、サーバーは成功のステータスを返します。アドレスのいずれかがこのテストに合格しない場合、サーバーはNotOnLinkのステータスを返します。サーバーがこのテストを実行できない場合 (たとえば、サーバーがクライアントが接続されているリンク上のプレフィックスに関する情報を持っていない場合)、またはクライアントによって送信された任意のIA内にアドレスがない場合、サーバーはクライアントにリプライを送信してはなりません。

サーバーは、IAオプション内のT1およびT2フィールドと、IAアドレスオプション内の優先有効期間および有効期間フィールドを無視します。

サーバーは、「メッセージタイプ」フィールドをREPLYに設定し、トランザクションIDを確認メッセージからトランザクションIDフィールドにコピーすることにより、リプライメッセージを構築します。

サーバーは、リプライメッセージにサーバーのDUIDを含むサーバー識別子オプションと、確認メッセージからのクライアント識別子オプションを含める必要があります。サーバーは、確認メッセージのステータスを示すステータスコードオプションを含めます。

18.2.3. Receipt of Renew Messages (更新メッセージの受信)

サーバーが、サーバーがユニキャストオプションを送信していないクライアントからユニキャストで更新メッセージを受信した場合、サーバーは更新メッセージを破棄し、UseMulticastの値を持つステータスコードオプション、サーバーのDUIDを含むサーバー識別子オプション、クライアントメッセージからのクライアント識別子オプション、および他のオプションを含まないリプライメッセージで応答します。

サーバーがクライアントからのIAオプションを含む更新メッセージを受信した場合、サーバーはクライアントのバインディングを特定し、クライアントからのIA内の情報がそのクライアントに対して保存された情報と一致することを確認します。

サーバーがIAのクライアントエントリを見つけることができない場合、サーバーは、NoBindingに設定されたステータスコードオプションを含むアドレスを含まないIAをリプライメッセージに返します。

サーバーが、アドレスのいずれかがクライアントが接続されているリンクに適切でないことを発見した場合、サーバーは有効期間0でアドレスをクライアントに返します。

サーバーがクライアントのIA内のアドレスを見つけた場合、サーバーは新しい有効期間とT1/T2の時間でIAをクライアントに送り返します。サーバーは、クライアントに返されるIA内のアドレスのリストとアドレスの有効期間を変更することを選択できます。

サーバーは、「メッセージタイプ」フィールドをREPLYに設定し、トランザクションIDを更新メッセージからトランザクションIDフィールドにコピーすることにより、リプライメッセージを構築します。

サーバーは、リプライメッセージにサーバーのDUIDを含むサーバー識別子オプションと、更新メッセージからのクライアント識別子オプションを含める必要があります。

サーバーは、セクション18.2で説明されているように、クライアントに返される構成情報を含む他のオプションを含めます。

18.2.4. Receipt of Rebind Messages (リバドメッセージの受信)

サーバーがクライアントからのIAオプションを含むリバドメッセージを受信した場合、サーバーはクライアントのバインディングを特定し、クライアントからのIA内の情報がそのクライアントに対して保存された情報と一致することを確認します。

サーバーがIAのクライアントエントリを見つけることができず、サーバーがサーバーの明示的な構成情報に従ってIA内のアドレスがクライアントのインターフェースが接続されているリンクに適切でないと判断した場合、サーバーは、IA内のアドレスの有効期間をゼロに設定したクライアントのIAを含むリプライメッセージをクライアントに送信する場合があります。このリプライは、IA内のアドレスがもはや有効でないことをクライアントに明示的に通知します。この状況では、サーバーがリプライメッセージを送信しない場合、サーバーはリバドメッセージを静かに破棄します。

サーバーが、アドレスのいずれかがクライアントが接続されているリンクに適切でなくなったことを発見した場合、サーバーは有効期間0でアドレスをクライアントに返します。

サーバーがクライアントのIA内のアドレスを見つけた場合、サーバーは新しい有効期間とT1/T2の時間でIAをクライアントに送り返す必要があります。

サーバーは、「メッセージタイプ」フィールドをREPLYに設定し、トランザクションIDをリバドメッセージからトランザクションIDフィールドにコピーすることにより、リプライメッセージを構築します。

サーバーは、リプライメッセージにサーバーのDUIDを含むサーバー識別子オプションと、リバドメッセージからのクライアント識別子オプションを含める必要があります。

サーバーは、セクション18.2で説明されているように、クライアントに返される構成情報を含む他のオプションを含めます。

18.2.5. Receipt of Information-request Messages (情報要求メッセージの受信)

サーバーが情報要求メッセージを受信した場合、クライアントは任意のアドレスの割り当てを含まない構成情報を要求しています。サーバーは、サーバーが認識しているサーバー構成ポリシーに基づいて、クライアントに適切なすべての構成パラメータを決定します。

サーバーは、「メッセージタイプ」フィールドをREPLYに設定し、トランザクションIDを情報要求メッセージからトランザクションIDフィールドにコピーすることにより、リプライメッセージを構築します。

サーバーは、リプライメッセージにサーバーのDUIDを含むサーバー識別子オプションを含める必要があります。クライアントが情報要求メッセージにクライアント識別オプションを含めた場合、サーバーはそのオプションをリプライメッセージにコピーします。

サーバーは、セクション18.2で説明されているように、クライアントに返される構成情報を含むオプションを含めます。

クライアントから受信した情報要求メッセージにクライアント識別子オプションが含まれていない場合、サーバーは、クライアントのアイデンティティによって決定されない構成パラメータを含むリプライメッセージで応答する必要があります。サーバーが応答しないことを選択した場合、クライアントは無期限に情報要求メッセージを再送信し続ける可能性があります。

18.2.6. Receipt of Release Messages (リリースメッセージの受信)

サーバーが、サーバーがユニキャストオプションを送信していないクライアントからユニキャストでリリースメッセージを受信した場合、サーバーはリリースメッセージを破棄し、UseMulticastの値を持つステータスコードオプション、サーバーのDUIDを含むサーバー識別子オプション、クライアントメッセージからのクライアント識別子オプション、および他のオプションを含まないリプライメッセージで応答します。

有効なリリースメッセージを受信すると、サーバーはIAとIA内のアドレスの有効性を調べます。メッセージ内のIAがクライアントのバインディング内にあり、IA内のアドレスがサーバーによってそれらのIAに割り当てられている場合、サーバーはIAからアドレスを削除し、アドレスを他のクライアントへの割り当てに利用可能にします。サーバーは、IAに割り当てられていないアドレスを無視しますが、エラーをログに記録することを選択できます。

すべてのアドレスが処理された後、サーバーはリプライメッセージを生成し、Successの値を持つステータスコードオプション、サーバーのDUIDを含むサーバー識別子オプション、およびクライアントのDUIDを含むクライアント識別子オプションを含めます。サーバーにバインディング情報がないリリースメッセージ内の各IAについて、サーバーはリリースメッセージからのIAIDを使用してIAオプションを追加し、IAオプション内にNoBindingの値を持つステータスコードオプションを含めます。IAオプションには他のオプションは含まれません。

サーバーは、アドレスの有効期間が期限切れになった後も、割り当てられたアドレスとIAの記録を保持することを選択できます。これにより、サーバーは以前に割り当てられたアドレスをクライアントに再割り当てできます。

18.2.7. Receipt of Decline Messages (拒否メッセージの受信)

サーバーが、サーバーがユニキャストオプションを送信していないクライアントからユニキャストで拒否メッセージを受信した場合、サーバーは拒否メッセージを破棄し、UseMulticastの値を持つステータスコードオプション、サーバーのDUIDを含むサーバー識別子オプション、クライアントメッセージからのクライアント識別子オプション、および他のオプションを含まないリプライメッセージで応答します。

有効な拒否メッセージを受信すると、サーバーはIAとIA内のアドレスの有効性を調べます。メッセージ内のIAがクライアントのバインディング内にあり、IA内のアドレスがサーバーによってそれらのIAに割り当てられている場合、サーバーはIAからアドレスを削除します。サーバーは、IAに割り当てられていないアドレスを無視します (そのようなアドレスを見つけた場合、エラーをログに記録することを選択できます)。

クライアントは、拒否メッセージ内の任意のアドレスがそのリンク上で既に使用されていることを発見しました。したがって、サーバーは、クライアントによって拒否されたアドレスをマークして、それらのアドレスが他のクライアントに割り当てられないようにする必要があり、アドレスが拒否されたことを通知することを選択できます。サーバー上のローカルポリシーは、拒否メッセージで識別されたアドレスが割り当てに利用可能になる時期を決定します。

すべてのアドレスが処理された後、サーバーはリプライメッセージを生成し、Successの値を持つステータスコードオプション、サーバーのDUIDを含むサーバー識別子オプション、およびクライアントのDUIDを含むクライアント識別子オプションを含めます。サーバーにバインディング情報がない拒否メッセージ内の各IAについて、サーバーはリリースメッセージからのIAIDを使用してIAオプションを追加し、IAオプション内にNoBindingの値を持つステータスコードオプションを含めます。IAオプションには他のオプションは含まれません。

18.2.8. Transmission of Reply Messages (リプライメッセージの送信)

元のメッセージがサーバーによって直接受信された場合、サーバーは、元のメッセージを受信したIPデータグラム内の送信元アドレスフィールドのアドレスを使用して、リプライメッセージをクライアントに直接ユニキャストします。リプライメッセージは、元のメッセージを受信したインターフェースを介してユニキャストする必要があります。

元のメッセージがリレーフォワードメッセージ内で受信された場合、サーバーは、リレーメッセージオプション (セクション22.10を参照) のペイロード内にリプライメッセージを含むリレーリプライメッセージを構築します。リレーフォワードメッセージにインターフェースIDオプションが含まれていた場合、サーバーはそのオプションをリレーリプライメッセージにコピーします。サーバーは、リレーフォワードメッセージを受信したIPデータグラム内の送信元アドレスフィールドのアドレスを使用して、リレーリプライメッセージをリレーエージェントに直接ユニキャストします。