要約

  • IETF V6OPS の IPv6 アプリ試験草案は、9 月 29 日付の -03 で、内部フローが通常は独立しているという説明に「プロトコル内で接続先を通知しない限り」という条件を加えた。-02 にはなかった文言だ。
  • 通常のアプリ操作をユーザーインターフェース機能の試験に含め、IPv4 専用網の表を NAT の有無で分けていないことも明確にした。現在も作業部会の Internet-Draft であり、承認済み RFC ではない。

アプリの IPv6 対応を判断するとき、最初の接続成功は分かりやすい証拠に見える。しかし、そこから先の挙動を説明できるとは限らない。例えば、ある通信で受けたメッセージの中に別の接続先が書かれ、アプリがその宛先へ次の通信を始める構成を考える。両方の経路を別々に試して成功しても、その受け渡しまで確認したことにはならない。これは設計上の例であり、実際の製品障害を報告するものではない。

改訂された Testing Applications for IPv6 Readiness の焦点は、試験の数を増やすことそのものではない。第 3.7 節は、複数の内部データフローを個別に調べれば、あらゆるネットワーク条件とフローの組合せを総当たりする必要を避けられるという考え方を維持する。その一方で -03 は、フローの独立性を期待できる条件を明文化した。接続先がプロトコルの中で通知されるなら、一方の結果が他方の前提になる。草案は全組合せ試験を命じてはいない。どの依存関係が存在するかを先に知ることが、効率的な試験を成立させる。

第 3.6 節の追加も実務に近い。ユーザーインターフェース機能に通常のアプリ操作が含まれることを示し、非ウェブ型インターフェース特有の通信にも触れる。起動画面や一度のログインだけを通しても、日々の作業で呼ばれる機能は残る。インストール、管理・記録、更新が別の宛先へ向かうこともある。そうした経路を確認するという方向性であり、特定のサービスが IPv6 で動かないという調査結果ではない。

試験環境の読み方にも注記が増えた。第 3.1 節の一覧は、IPv4 専用網について NAT がある場合とない場合を別行にしていない。NAT を前提にしたアプリは、それがない環境で問題を起こし得るが、草案は列挙した IPv6 シナリオでもその種の問題を見つけられると述べる。464XLAT や IPv6-Mostly に関する MTU の論点は第 3.4 節に置かれている。一つの試験結果を全ての NAT 条件やパケットサイズの保証へ拡大せず、実際に用いた環境を記録することが肝心だ。

リリース判定で作るべきものは巨大なチェック表とは限らない。フローごとに開始契機、宛先の取得方法、利用するライフサイクル上の操作、実行したネットワーク条件とビルドを残す。宛先がメッセージに埋め込まれる箇所だけ、関連するフローを連ねて試す。この整理は本稿の運用上の提案で、IETF が指定する認証手続きではない。独立している経路には簡素な試験を使い、独立していない経路には根拠のある追加確認を置くためのものだ。

Datatracker 上では、文書は WG Last Call にある作業部会草案だ。当初の募集期間は 9 月 4 日から 18 日で、議長は著者が意見に対応する間に一週間延長すると伝えた。この経緯から、最終募集の完了や標準化の承認を推定してはならない。今回の変化は、IPv6 対応を判定する試験の「省略できる条件」が前より明瞭になった点にある。

出典