要約

  • IPv6のみで動作できるクライアントは、DHCPv4のParameter Request Listにオプション108を入れる。IPv6-mostlyとして明示設定されたプールだけが有効な待機時間を返し、クライアントは提示されたIPv4アドレスを要求せずに済む。
  • 最短時間は300秒、RFCの既定値は1800秒である。時間の満了または新しいネットワーク接続イベントで状態は終わる。5分は素早く戻るための回路であって、IPv4を永久に削除した証明ではない。

DHCPv4で「アドレスはいらない」と伝える

DHCPOFFERは通常、アドレスの受け取りを促す応答である。オプション108では、同じ応答が受け取りを見送る合図になる。クライアントはDHCPDISCOVERまたはDHCPREQUESTの要求リストにコード108を含める。送るのはコードだけで、4バイトの待機値をクライアント側が指定するわけではない。

この要求は、端末全体についての普遍的な宣言でもない。RFC 8925が扱う能力はインターフェース単位である。その接続でNAT64を利用でき、必要ならCLATが動き、想定アプリケーションがIPv6のみの環境で働くなら、IPv4アドレスを任意とみなせる、という意味にとどまる。

サーバー側にも条件がある。クライアントがコード108を要求し、選ばれたプールがIPv6-mostlyに設定されていなければならない。どちらかを欠く応答にオプションを勝手に足してはならない。条件を満たす場合、サーバーはV6ONLY_WAITを返し、提示アドレスには0.0.0.0を使うことが推奨される。システム上それが難しければ実在の空きアドレスを示せるが、クライアントが要求しない前提なので予約はしない。

結果として、同じリンク上に異なる世代が残れる。オプションを知らない端末は通常どおりIPv4を取得する。対応端末だけが辞退する。SSIDやVLANを二重化し、認証基盤が各端末の全アプリを先回りして分類する必要はない。

この小ささが重要である。標準は端末の価値を判定せず、未採用を違反にもせず、特定のプールと特定の要求が出会ったときだけ状態を変える。

5分という復旧予算

V6ONLY_WAITは32ビットの秒数である。サーバー値が下限を下回る場合、クライアントはMIN_V6ONLY_WAIT、つまり300秒を使う。RFCの既定値は1800秒なので、5分を既定値と呼んではならない。

待機中、クライアントはDHCPv4設定を止めるべきで、該当インターフェースのIPv4スタックを止めてもよい。解除条件は時間満了または接続イベントである。別のWi-Fiへ移動した端末に、前のネットワークでの判断を持ち越さないための境界でもある。

2026年3月の6MOPS第07版は、初期導入で300秒から始めることを勧める。これは有効期限を持つInternet-Draftで、RFCでも最終標準でもない。ただし、運用仮説としては明快だ。問題が見つかったらサーバーのオプション送出を止め、タイマーまたは再接続後にIPv4を取り戻させる。

短い時間には負荷が伴う。多数の端末が5分ごとにDHCPDISCOVERを出せば、DHCP基盤に無視できない流量が生じる。迅速な復旧と制御トラフィック削減は同じ方向を向かない。端末数、再試行率、障害時間、サーバー余力を測ってから1800秒以上へ延ばす必要がある。

タイマーは移行への躊躇ではない。間違った能力宣言が利用者の長期障害になることを防ぐ、明示された復旧予算である。

「IPv4オフ」の裏にある六つの状態

管理画面の有効化表示だけでは、何が起きたか分からない。少なくとも六つを分けて記録する必要がある。

一つ目はインターフェース方針である。OSの既定値なのか、CLATの存在なのか、企業内テストなのか。誰が何を根拠にIPv6-only対応と宣言したかを残す。

二つ目は要求である。Parameter Request Listにコード108が実際に入っていたか。クライアントが求めていなければ、サーバー側の機能表示は同意の証拠にならない。

三つ目はサーバー範囲である。応答したプールが明示的にIPv6-mostlyだったか。別の通常プールから同じオプションが出れば、境界は壊れている。

四つ目はofferである。4バイト長は正しいか、待機値はいくつか、0.0.0.0か未予約の実アドレスか。制御されたパケット取得で確認できる。

五つ目はクライアント状態である。アドレス要求を本当に見送り、どれだけ停止し、INIT-REBOOT、更新、再接続でどう動いたか。サーバーが送った事実と端末が従った事実は別である。

六つ目は業務結果である。PREF64は間に合ったか。NAT64へ到達したか。IPv4ソケットしか使えないアプリにCLATが提供されたか。利用者の作業は完了したか。リースがないことは成功の証明ではない。

六つを一つのフラグにまとめると、障害点も需要も見えなくなる。「この条件で、この端末が、この時間だけ辞退し、これらのアプリが成功した」という記録なら次の判断に使える。

翻訳経路は別の契約である

RFC 8925は、IPv6のみの端末がIPv4のみの宛先へ行くためにNAT64を使えることを前提とする。だがオプション108自体は翻訳方式を交渉せず、NAT64プレフィックスも教えず、経路の健全性も確かめない。

Linkovaが共同著者であるRFC 8781は、Router AdvertisementでPREF64を通知する選択肢を定義した。2025年のRFC 9872は、新規導入でこのRA方式を優先し、RAが使えない、または端末が未対応のときにDNSによる発見をフォールバックとして残す。PREF64を得るまで、IPv4のみのアプリや宛先への通信は損なわれ得ると明記している。

464XLATは別の穴を埋める。端末側のCLATが旧来アプリにIPv4の面を見せ、IPv6上でネットワーク側翻訳器へ運ぶ。しかしRFC 6877は、これを完全なIPv4の一対一代替とは呼ばない。着信IPv4やあらゆるピア間通信を再現するものではない。

したがって、オプション108が正しく働いても利用者は失敗し得る。RAにPREF64がない。プレフィックスは正しいがNAT64の経路がない。翻訳は動くがVPNがIPv6拡張ヘッダーを拒む。ブラウザーはネイティブIPv6で成功する一方、IPv4リテラルを持つ業務アプリはCLATがなく失敗する。

これらをまとめて「IPv6が壊れた」と書けば、修理対象を失う。DHCPの選択と、その後のサービス鎖は別々に検証すべきである。

デュアルスタックが隠していたもの

Happy Eyeballsは、悪いIPv6経路を避けてIPv4へ切り替え、利用者を守る。その成功は同時に、IPv6障害を長く見えなくすることがある。IPv4アドレスを外した瞬間、以前から存在した問題が初めて表面化する。

6MOPS草案は、PREF64通知、DHCPv4サーバー側のオプション108、管理端末の個別有効化という順序を提案する。OSによってはオプション処理が最初から有効で、無効化設定を持たない。そうした端末は、サーバーがオプションを返し始めた瞬間にIPv6のみとなる。サーバーの小変更がサブネット全体の変更になり得る。

IETF 118でLinkovaが示した資料は、Googleオフィスでの試験、複数拠点への展開、割合を段階的に増やす運用を説明している。DHCP利用の低下や回収見込みのアドレス数も示したが、これはその発表に帰属する特定環境の主張であり、独立した世界共通値ではない。

一般化できるのは数字ではなく手順である。小さく開始し、障害を観測し、範囲を広げ、戻り道を維持する。標準文書はこの試験を可能にするが、実装結果の代わりにはならない。

辞退した一件から読める需要

リースを辞退すれば、アドレスは別の端末に残せる。端末へパブリックIPv4を直接割り当てる網では消費削減につながる。RFC 1918の私設空間でも、内部枯渇や多段NATを避けられる場合がある。新しいセグメントなら最初から小さなIPv4プールを選べるが、既存網では空きを実際に再利用するために再番号付けが必要かもしれない。

ただし証拠は条件付きである。この端末、このインターフェース、このソフトウェア、このネットワーク、この翻訳環境で、この時間はIPv4アドレスを取らなかった。それ以上でも以下でもない。全アプリの成功、別の接続先での辞退、残る端末の需要の不当性までは示さない。

IPv4の希少性を消す証拠でもない。むしろ、辞退できない用途に需要が集中し得る。経済的な意味は、慣習的な全員配布から条件付き需要を切り離せる点にある。

監視すべき値は一つではない。コード108を要求した端末数、有効な応答、回避できたリース、その後の再試行、アプリ別障害、NAT64/CLATの状態、そしてプール縮小や再配分まで完了したアドレス数を分ける。空いた欄がすぐ使える資源とは限らない。

5分の時計は、結論を永続化しない。いったん「不要」を記録し、結果を観測し、次には違う答えを許す。

Jen Linkovaの役割を正確に置く

RFC 8925の著者はLorenzo Colitti、Jen Linkova、Michael C. Richardson、Tomek Mrugalskiである。LinkovaはRFC 8781、RFC 9872、現行6MOPS草案にも複数の著者の一人として名を連ねる。関連するIPv6運用技術への継続的な寄与は確認できるが、単独発明や実装・配備の支配は意味しない。

標準の権威と稼働の証拠も分ける必要がある。文書は共通の意味を定め、端末は要求するかを選び、運用者はプールを設定する。相互運用するコードが実際の結果を作る。未対応端末は通常のDHCPv4を続けるだけで、制度的に罰せられない。

この仕組みの価値は、IPv4の終わりを宣言したことではない。大きすぎる問いを「今、この条件なら、5分間はこのアドレスを待機させられるか」という小さな検証へ変えたことにある。

出典