要約

  • Option 108はIPv6-onlyで動ける端末がIPv4アドレスを辞退する意思を示す。DHCPサーバーが応答するのは設定済みのIPv6-mostlyプールだけだ。
  • 草案は共通の対応判定を定めない。端末の指定、退出手段、IPv4が隠していた障害は運用者の責任になる。

DHCPサーバーは、ノートPCのアプリを調べて「IPv4なしでも今日は大丈夫」と保証してくれない。Option 108もそんな仕事をしない。対応端末がIPv4アドレスを受け取らなくてもよいと伝える手段を用意するだけだ。その信号をどのネットワークで受け入れるかは、運用者が決める。

これがIETFのIPv6-mostly草案第12版の分岐点だ。草案は10月29日に更新され、11月12日までIESG最終コメント期間にある。IPv4端末とIPv6-only端末を同じセグメントに置き、Option 108を要求してDHCPOFFERで受け取った端末には、提示されたIPv4アドレスを要求しないよう求める。Option 108に対応しない端末には、IPv6-mostly用に設定されたプールからIPv4を引き続き割り当てられる。

Option 108は信号であって、互換性試験ではない。草案は「IPv6-only-capable」に厳密な技術定義がないと明記する。意味するのは、ネイティブIPv4なしでも動き、利用者に同じ体験を提供できる端末だ。アプリがIPv6ソケットを使いIPv6宛先だけに接続する場合もあれば、NAT64経由でIPv4-only宛先に届く場合もある。古いIPv4アプリのために端末側でCLATを動かす方法もある。RFC 6877はCLATを定義する。RFC 8925も、インターフェースをIPv6-only対応と宣言することを方針上の判断としている。草案第12版も同じ前提だ。DHCPのやり取りだけでは端末の準備状況は分からない。どの端末、インターフェース、利用者グループにその宣言を許すのか、誰かが決める必要がある。

サーバーの役割は限定的だ。RFC 8925では、端末がオプションを要求し、選択されたプールがIPv6-mostlyとして明示設定されている場合にだけ、サーバーはOption 108を返す。4バイトの値はDHCPv4を停止する秒数を示す。設定済みのV6ONLY_WAITを返し、未設定なら0を返す。アドレスを引き上げる場所を決めるのは、端末の自己申告ではなくプール設定だ。

IPv4-only宛先への道も残さなければならない。草案はNAT64を使い、RFC 8781のRouter Advertisement、RFC 6147のDNS64、または両方でNAT64プレフィックスを知らせる。IPv6を扱えないアプリにはCLATが必要になる場合がある。端末、DNS、変換器、接続ネットワークのどこかが誤れば、以前は障害を隠していたデュアルスタックへの逃げ道が消える。

だから移行手順は、オプション番号より重い。第12版は希望者による試験網を勧め、その後PREF64通知とOption 108を順次有効にする退出可能フェーズを提案する。問題を報告しないと退出できない設計も想定している。それは障害の手掛かりを増やす一方、影響を受けた利用者を最初の試験装置にする。草案はACLでIPv4を遮断する方法を暫定策と呼ぶ。端末が移動する環境では、どの端末を止めるかという運用者の意図を保守し続けるからだ。

草案には導入数や実測障害データがなく、アドレス削減や利用者体験は確認できない。論点は構成にある。共通ネットワークでもIPv4が不要な端末への割当てを止め、必要な端末には残せるという構成だ。残る運用課題は、アプリが一つずつ壊れてサポート窓口が答えを学ぶ前に、どう「準備完了」を確かめるかである。

Sources · RFC 8925 · RFC 6877 · RFC 8781 · RFC 6147