要約

  • RFC 9915は2026年1月発行のIETF Internet Standard、STD 102であり、RFC 8415を廃止する。DHCPv6を単純なアドレス応答ではなく、クライアント/サーバー交換、識別子、Identity Association（IA）、ライフタイム、更新、再バインドの連鎖として扱う。
  • 移行判断は初回割り当てだけで行えない。サーバーの継続性、リレー経路、マルチキャスト到達性、Reconfigure、複数IA、Prefix Delegation、障害切替とロールバックを、実際の失敗条件で検証する必要がある。

仕組み：リースは時間と経路を持つ

クライアントはSolicit、Request、Renewなどの交換を通じてサーバー状態を形成する。DUIDはクライアントを識別し、Server Identifierはサーバーを識別する。IA_NAは非一時アドレス、IA_PDは委任プレフィックスを保持し、preferred lifetimeとvalid lifetimeがそれぞれの有効性を制約する。クライアントは通常、先に元のサーバーへRenewを送り、応答を得られなければRebindで対象サーバーの範囲を広げる。このため、アドレス取得の成功は最初の状態の成立を示すだけで、その後の更新や再バインドを保証しない。

リレーエージェントはクライアントとサーバーの間にインターフェース、転送、到達性の境界を持ち込む。サーバーのReconfigureも、単なる通知として観測してはいけない。クライアントが受信し、リレー経路を通じて処理し、必要な交換を再実行できるかが重要である。Prefix Delegationでは、カスタマーエッジルーターがプレフィックスを受け取るだけでは不十分だ。リース更新、サーバー切替、下流ネットワークでの利用まで、プレフィックス状態が連続していなければならない。RFC 7084はカスタマーエッジの要件文脈を与えるが、各ネットワークの安全な閾値を決めるものではない。

RFC 9915はIA_TAによる一時アドレス割り当てと、Server Unicast機能を削除した。後者にはServer UnicastオプションとUseMulticastステータスコードも含まれる。これは旧来の機能を狭める変更だが、IPv6のプライバシーアドレスが消えたことを意味しない。SLAACとRFC 8981の一時アドレスは別の仕組みとして残り、DHCPv6がすべてのネットワークでSLAACを置き換えるわけでもない。

RFC 7550が示すように、複数のステートフルDHCPv6オプションや複数IAでは、あるIAの成功が別のIAやIA_PDの成功を意味しない。RFC 8415相当の挙動とRFC 9915の挙動が混在する場合も、安全な互換性を文書だけから推定できない。実装、オプション処理、切戻しを検証する必要がある。ここでの分析はTheo Marchによる分析であり、ベンダー対応や普遍的な導入を主張するものではない。

主張とRFCの証拠台帳

主張 根拠
RFC 9915はSTD 102、2026年1月のInternet StandardでRFC 8415を廃止する RFC 9915、RFC 8415
交換、識別子、IA、ライフタイム、Renew、Rebindが状態を構成する RFC 9915
Prefix Delegationはカスタマーエッジでの継続性と結び付く RFC 9915、RFC 7084
複数IAは独立した失敗境界を作る RFC 7550
IA_TA、Server Unicast、そのオプション、UseMulticastを削除した RFC 9915
SLAACとプライバシー用一時アドレスは存続する RFC 4862、RFC 8981

出典