要約

  • Mark Smithの個人Internet-Draft第03版は、DHCPv4 Router Option 3を必要とする端末向けに、端末自身のDHCPアドレスまたは127.0.0.1を返す方法を追加した。
  • 草案は、どちらの値でも非ローカルIPv4通信が端末外へ出ず、ICMP Destination Unreachableが発生すると見込む。これは提案であり、公開された相互接続試験の結果ではない。
  • LACNICブログが10月2日に挙げたOS試験は第02版を対象にしており、今回追加された方法の検証にはならない。

分析

デフォルトゲートウェイは通常、別のネットワークへ通信を運ぶ。ところがDHCPv4の新しい草案改訂は、古いクライアントの一部では、ゲートウェイ欄が自分自身を指す可能性を示した。

Mark Smithは10月16日、「Nearly IPv6 Only Dual Stack Hosts」の第03版を公開した。第02版は6月15日に期限切れとなっていた。新版もRouter Option 3を受け取らない方式を基本に置くが、必須とするクライアントには別案を示す。DHCPで割り当てた端末自身のアドレスか、127.0.0.1をルーター値として返すというものだ。

これは一般的なゲートウェイ設定ではない。RFC 2132はOption 3を、DHCPサーバーが端末に渡すルーターの一覧と定める。草案は、/32マスクと組み合わせれば、この自己参照値によって外部IPv4宛てのパケットは端末内にとどまり、ICMPv4 Destination Unreachableが直ちに返ると説明する。問題はクライアントがその経路をどう解釈するかだ。どのOSがどちらの値を受け入れるか、どんな経路を登録するか、アプリケーションがIPv6へ再試行するかを示すテスト表は公開されていない。

既存のテスト報告を今回の変更の裏付けにはできない。Alejandro Acostaが10月2日にLACNICブログへ掲載した記事は第02版を参照し、Windows 11、Fedora 43、Debian TrixieベースのRaspberry Pi OS、Chromecast、Google Nestで試したと記す。スマートフォンは未試験で、追加テストが必要だとも述べている。これらは第03版より前の結果だ。

検証ではDHCPサーバーが値を送れたかだけでなく、端末側の挙動を記録する必要がある。二つの値を別々のケースとして、クライアント、OSの版、DHCPサーバーやリレーの構成ごとに比べたい。DHCP ACK、実際の経路表、端末外IPv4宛てのパケット、ICMPエラーのアプリケーションへの到達、IPv6への再試行を確認する。同一リンク上の通信も別に試すべきだ。ルーター経由の通信を止めても、ローカルの到達性まで消えたとは限らない。

この草案はDHCPv4 Option 108を置き換えるものでもない。RFC 8925のOption 108は、対応端末が一定期間IPv6のみを希望するとサーバーに伝える方式だ。今回の提案は、その機能を持たない、またはDHCPv4応答を求め続ける端末を想定する。第03版の焦点は新標準ではなく、古いクライアントとの互換性にある。

Datatrackerでは第03版は有効な個人Internet-Draftで、RFCストリームはなく、IESG状態は「I-D Exists」と表示される。文書自体もIETFの承認を得たものではなく、標準化手続き上の正式な地位はないと明記する。目標ステータスはInformational、期限は2027年4月19日だ。改訂が続いていることは提案が更新された証拠であって、IETFやOSベンダーが採用した証拠ではない。

ネットワーク担当者にとって、この変更は限定的な試験項目であり、直ちに広域展開できる設定ではない。端末自身のアドレスとループバックは分けて試し、経路とアプリのIPv6移行を観測してから判断したい。DHCP応答が返っただけでは、端末の挙動が草案どおりだとは言えない。

参考資料