要約

  • draft-ietf-v6ops-ipv6-app-testing-03 は、IPv4-only、dual-stack、NAT64を伴うIPv6-only、関連するIPv4到達性を一切持たないIPv6-only-strictを分ける。dual-stackでの成功はIPv4への退避成功かもしれず、strict環境の証明にはならない。
  • 導入、ユーザーインターフェース、管理、更新は別々のライフサイクル面である。信頼できる対応宣言には、重要な有向フロー、適用条件、試験環境の成立証拠、通信結果とアプリケーション結果が必要になる。

一つの緑が未実行の経路まで代弁した

通常のユーザー操作が通るのは、システム全体の一部でしかない。Web画面はフロントエンド、認証サービス、主要APIを通っても、ライセンス確認、パッケージ取得、ログ転送、遠隔管理、バックアップ、復旧を一度も呼ばないことがある。その実行を製品全体の「IPv6対応」に集約すれば、観測済みの経路が未観測の経路に権威を貸す。

第03版の四つの基礎条件は、製品に貼る四つのシールではない。あるバージョンの、ある送信元からある受信先へのフローが、あるライフサイクル機能を果たすとき、どの条件で何を期待するかを定める軸である。

したがって証拠単位には、バージョン、有向フロー、機能、クライアント／サーバー役割、仲介者、接続条件、期待結果、実測結果が含まれる。抜けた要素は合格ではなく未確定である。

複雑なクラウドでは、端から端までの一試験が複数の辺に分解される。ロードバランサー、ゲートウェイ、認証、認可、データベース、ストレージ、監視がそれぞれ別の通信を持つ。一つのコンポーネントがある辺ではサーバー、別の辺ではクライアントになる。最後の画面が成功しても、全ての辺がIPv6だったとは限らない。

全ての理論的直積を機械的に回す必要はない。管理下の構成が一方を確実にdual-stackに固定しているなら、適用しない組合せを除外できる。ただし除外には版、所有者、検証可能な理由が要る。単に行が存在しないことは、設計判断ではない。

dual-stackの成功は退避の成功かもしれない

Happy Eyeballsは利用者の待ち時間を減らすために重要だが、試験結果を読み替える。IPv6がTCP接続後、TLS完了前に失敗し、その後IPv4で完了しても、最終画面は正常に見える。RFC 8305 は到達性競争を扱うのであって、敗れたアドレス族の健全性を証明しない。

RFC 6147 のDNS64、RFC 6052 の埋め込み形式、RFC 6877 の464XLATによってIPv4-only依存先へ到達することもある。それが意図した移行シナリオなら有効な結果である。しかしIPv6-only-strictを名乗るなら、CLAT、DNS64、NAT64、VPN、トンネル、プライバシー中継がIPv4を復活させていない証拠が必要だ。

受領記録は「成功」だけでは足りない。DNS応答、候補アドレス、選択されたアドレス族、各接続試行、退避時刻、代理や変換器、トランスポート結果、アプリ結果を残す。最後の成功だけを保存すると、見つけたかった不具合を自ら消してしまう。

逆に、厳格な試験台が自分の管理経路を壊す場合もある。IPv4無効化で仮想マシン管理や企業サインオンが止まれば、製品ではなく試験環境が故障している。禁止した経路を戻さずに試験台を観測できる仕組みが別に要る。

UI、導入、管理、更新は同じ試験ではない

ドラフトは導入、UI、管理、更新を別軸に置く。インストーラーはアクティベーション、パッケージリポジトリ、第三者サービスへ接続する。管理面にはAPI、SNMP、syslog、監視、遠隔支援が含まれうる。更新器は通常動作と異なる実行ファイル、証明書、ミラー、ロールバック先を使う。

UIが通ってもインストールは未検証である。管理APIが通ってもログにIPv6送信元が正しく残るとは限らない。手動更新が通っても無人更新が同じ経路を使うとは限らない。試験報告を画面一覧ではなく有向フロー一覧で構成する理由はここにある。

プロキシは第三の脚を加える。クライアントからプロキシまでIPv6でも、プロキシからオリジンがIPv4かもしれない。別DNS、アドレス変換、IPv4-only上流が存在しうる。TURNを利用するP2Pはさらに候補を増やす。RFC 8656 は中継動作を定めるが、特定製品が全候補と失敗分岐を試した証明ではない。

共有サービスでは影響が再帰する。共通エンドポイントにAAAAを追加すると、別製品の利用者が準備前のIPv6許可リストやログ経路に入ることがある。局所的に正しい変更が、利用者全体の運用契約を変える。フロー台帳は依存版と再利用関係に結び付けなければならない。

アドレスは輸送路であると同時にデータである

アプリケーションはアドレスを解析、表示、保存、比較し、権限判断にも使う。RFC 4291 が構造を、RFC 5952 が推奨表記を定めても、業務ロジックがIPv4形式だけを受け付けたり、文字列を切り詰めたり、等価表記を別主体として記録したりすることはある。

許可リストは典型的である。サーバーにAAAAを追加すると、対応クライアントはすぐIPv6で来る。アプリ層の許可規則にIPv6が無ければ、接続成立後に拒否される。Happy Eyeballsは輸送後の認可を修復できない。輸送成功と権限成功は別の受領記録だ。

IPv6を受けても、監査や不正対策で送信元を正確に検索できないなら、運用面の対応は未完成である。アドレスを通信だけでなく制御データとして試す必要がある。

追跡は見たものだけを証明する

strict環境が作れない場合、クライアントログ、サーバーログ、パケット捕捉は狭い結論を支える。だが捕捉にIPv4が無かったことは、対象インターフェース、フィルター、時間窓、既知のフロー集合についてしか言えない。遅延ジョブ、条件分岐、テナント固有経路、次版の依存は現れないことがある。

ドラフトがネットワーク追跡を最も誤りやすい代替とするのは、解釈者が通信パターンを既に理解していなければならないからだ。正しい報告は「台帳版Xの全フローを実行YでIPv6として観測した」であり、「隠れたIPv4依存は存在しない」ではない。

Last Callは稼働証明ではない

凍結した資料は2026年9月29日付の第03版で、2027年4月2日に失効する。DatatrackerではV6OPSのActive WG文書、I-D Exists、WG Last Callである。表紙はBest Current Practiceを意図すると記す一方、Datatrackerのintended-statusは空である。現在はRFCでもBCPでもない。

文書は比較可能な質問を作れるが、試験を実行しない。RFC 8504 のノード要件も、個々のアプリの機能試験を代行しない。RFC 8585 の企業導入シナリオも、依存関係の準備完了を保証しない。

Running-Code Primacyに従えば、順序は明確になる。文書が問いを定義し、台帳が分母を宣言し、試験台が条件を作り、計測が経路を記録し、アプリが結果を出し、本番が変化に耐えるかを示す。前の層が宣言だけで次の層を作ることはない。

情報源