要約

  • RFC 3315は、通常のSolicit–Advertise–Request–ReplyをSolicit–Replyに短縮するようDHCPv6クライアントが求められる仕組みを定めた。ただし、サーバーは自らの方針や設定に従って応じないことができる。
  • Rapid CommitではサーバーがReply送信前にリースを確定する。複数サーバーが応答すれば、クライアントが一つだけ使う間に複数のアドレスが確保され得る。Replyが届かなければ、サーバー記録とクライアントが利用できる状態も食い違う。

四つのメッセージは、単に昔ながらの遠回りだったわけではない。クライアントはSolicitを送り、各サーバーからAdvertiseを受け取り、候補を選んでRequestを出す。Replyは選択後に届く。この一段階が、どのサーバーから何を受け取るかを明示する役割を持っていた。2003年7月のRFC 3315は、IPv6のステートフルなアドレス設定を定義しながら、条件付きでこの順序を短くする方法も設けた。

クライアントはSolicitに長さゼロのRapid Commitオプションを入れ、直ちにReplyを受け取る用意があると知らせる。これは希望であって、サーバーへの強制命令ではない。サーバーは応答ポリシーと設定を確認し、コミット済みの割り当てを返すよう構成されている場合だけRapid Commitを受け入れる。そうでなければオプションを無視し、Advertiseを返して通常の選択手順に戻せる。受け入れるサーバーはReplyを送る前にアドレスを確保する。

この順序がトレードオフの核心だ。有効なRapid Commit付きReplyを受信したクライアントは、Requestを送らずにそこに含まれるアドレスを使える。しかし、Replyがクライアントに届いたことをサーバーが後から確認するメッセージはない。RFC 3315はその結果を明記する。同じSolicitに複数のサーバーがReplyすれば、それぞれが割り当てを確定し、クライアントはそのうち一つのサーバーのリースだけを使うことがある。残りは確保済みでも利用されない。Replyが通信途中で失われた場合も、クライアントが使えない割り当てがサーバー側に残り得る。

したがって二つのメッセージに減らしても不確実性は消えず、置き場所が変わる。通常のAdvertise–Requestでは、割り当て確定前にクライアントが候補を選ぶ。Rapid Commitではサーバーが先に確定し、誰が応答するかがアドレスプールへの負担を左右する。仕様はRapid Commitを使う構成では通常一台だけが応答するようにし、未使用アドレスを減らすため初期リースを短くする方法も挙げる。これは設計上の緩和策であり、常に単一サーバーであることや状態共有の保証ではない。

2005年のRFC 4039はDHCPv4にもRapid Commitを導入し、接続地点が頻繁に変わる高モビリティ環境で、すばやい設定が有用になり得ると説明した。同時に、通常の四メッセージ方式なら複数サーバーのOfferをクライアントが選ぶまで暫定状態にできるという冗長性も示した。2018年にDHCPv6を統合したRFC 8415を経て、2026年のRFC 9915でも、クライアントは高速交換を求められるが、サーバーはコミット済みリースを返す設定でなければ応じなくてよいという境界は保たれた。

Rapid Commitの歴史は、パケット数だけの話ではない。サーバーはいつ資源を確保し、何台が確保でき、クライアントは受け取ったかをどの証拠で分かるのか。往復を一つ省くと、選択と到達確認の機会も一つ減る。

出典：RFC 3315、RFC 4039、RFC 8415、RFC 9915。