5. クライアント/サーバ交換

この節では, メッセージ交換, リレー動作, DUID, IA_NA, IA_TA, IA_PD, DHCP オプション, RKAP 認証, IANA レジストリ, 規範的要件, 付録のオプション出現マトリクスを含む DHCPv6 に関する RFC 本文を保持する.

RFC 原文

5.  クライアント/サーバ交換

   クライアントとサーバは UDP を使用して DHCP メッセージを交換する
   ([RFC0768] および [BCP145] を参照).  クライアントは, DHCP
   メッセージの送受信に link-local source address または他の仕組みによって
   決定されたアドレスを使用する.

   DHCP クライアントは, 予約済みの link-scoped multicast destination
   address (All_DHCP_Relay_Agents_and_Servers - ff02::1:2) を使用して
   すべてのメッセージを送信する.  これにより, クライアントは DHCP
   サーバのアドレスを設定されている必要がない.

   DHCP クライアントが同じリンクに接続されていない DHCP サーバへ
   メッセージを送信できるようにするため, クライアントのリンク上の
   DHCP relay agent がクライアントとサーバの間でメッセージを中継する.
   relay agent の動作はクライアントに対して透過的である.  この節の残り
   におけるメッセージ交換の説明では, relay agent によるメッセージ中継の
   説明を省略する.

5.1.  2 つのメッセージを伴うクライアント/サーバ交換

   DHCP クライアントが DHCP サーバから IP アドレスまたは委任プレフィックス
   を割り当ててもらう必要がない場合, クライアントは DHCP サーバとの
   単一のメッセージおよび応答交換を通じて, 利用可能な DNS サーバ
   [RFC3646] または NTP サーバ [RFC5908] のリストなど, その他の構成情報
   を取得できる.  その他の構成情報を取得するため, クライアントはまず
   Information-request メッセージを
   All_DHCP_Relay_Agents_and_Servers multicast address に送信する.
   サーバは, クライアント向けのその他の構成情報を含む Reply メッセージで
   応答する.

   クライアントは, 次の節で説明する通常の 4 メッセージ交換の代わりに
   2 メッセージ交換を使用して, アドレス割り当ておよび/または
   プレフィックス委任を迅速化するようサーバに要求することもできる.
   迅速化された割り当てはクライアントが要求でき, サーバはその要求を
   受け入れる場合も受け入れない場合もある (詳細およびサーバがこの要求を
   受け入れない理由については Sections 18.3.1 および 21.14 を参照).
   クライアントは, あるリンク上で利用可能なサーバが 1 つだけであり,
   2 つ目のサーバが利用可能になる見込みがない環境, または構成プロセスを
   できるだけ速く完了することが優先される場合に, この迅速化サービスを
   要求できる.

   迅速化された 2 メッセージ交換を要求するため, クライアントは
   Solicit メッセージを All_DHCP_Relay_Agents_and_Servers multicast
   address に送信し, アドレスおよび/または委任プレフィックスならびに
   その他の構成情報の割り当てを要求する.  このメッセージには,
   クライアントがサーバからの即時 Reply メッセージを受け入れる意思が
   あることを示す指示 (Rapid Commit option; Section 21.14 を参照) が
   含まれる.  クライアントへのアドレスおよび/または委任プレフィックスの
   割り当てを即座に確定する意思のあるサーバは, Reply メッセージで応答
   する.  Reply メッセージ内の構成情報およびアドレスおよび/または
   委任プレフィックスは, その後すぐにクライアントが使用可能となる.

   クライアントに割り当てられる各アドレスまたは委任プレフィックスには,
   サーバが指定する preferred lifetime と valid lifetime が関連付けられる.
   アドレスまたは委任プレフィックスに割り当てられた lifetimes の延長を
   要求するため, クライアントは Renew メッセージをサーバに送信する.
   サーバは新しい lifetimes を含む Reply メッセージをクライアントに送信し,
   クライアントがアドレスまたは委任プレフィックスを中断なく使い続けられる
   ようにする.  サーバがアドレスまたは委任プレフィックスの lifetime を
   延長できない場合, lifetimes が 0 のアドレスまたは委任プレフィックスを
   返すことでそれを示す.  同時に, サーバは他のアドレスまたは
   委任プレフィックスを割り当てることができる.

   クライアントとサーバ間の追加の 2 メッセージ交換の説明については
   Section 18 を参照.

5.2.  4 つのメッセージを伴うクライアント/サーバ交換

   1 つ以上のアドレスおよび/または委任プレフィックスの割り当てを要求
   するため, クライアントはまず DHCP サーバを見つけ, 次にそのサーバに
   アドレスおよび/または委任プレフィックスならびにその他の構成情報の
   割り当てを要求する.  クライアントは利用可能な DHCP サーバを見つける
   ため, Solicit メッセージを
   All_DHCP_Relay_Agents_and_Servers multicast address に送信する.
   クライアントの要件を満たせるサーバは Advertise メッセージで応答する.
   その後, クライアントはサーバの 1 つを選択し, アドレスおよび/または
   委任プレフィックスならびにその他の構成情報の lease を求める Request
   メッセージをサーバに送信する.  サーバは, lease されたアドレス,
   委任プレフィックスおよび構成を含む Reply メッセージで応答する.

   前の節で説明したように, クライアントはアドレスまたは
   委任プレフィックスに割り当てられた lifetimes の延長を要求できる
   (これは 2 メッセージ交換である).

5.3.  サーバ/クライアント交換

   以前にクライアントと通信し, クライアントが Reconfigure メッセージを
   待ち受けることを交渉したサーバは, クライアントに Reconfigure
   メッセージを送信して, Information-request, Renew, または Rebind
   メッセージを送信することにより構成を更新するようクライアントに開始
   させることができる.  Reconfigure メッセージは Section 20.4 に従って
   認証される.  その後, クライアントは前述の 2 メッセージ交換を実行する.
   これは, ネットワークの renumbering が必要な場合など, クライアントへの
   構成変更を迅速化するために使用できる ([RFC6879] および [RFC9096] を
   参照).