要約

  • RFC 7872の数値は、World IPv6 LaunchとAlexaの履歴リストから作ったアドレス集合に対するDO8、HBH8、FH512の測定結果であり、2026年のインターネット全体の損失率ではない。
  • 宛先AS以外で失われた割合は、すでに失われたパケットを分母とする最良／最悪ケースの推定である。経路や組織帰属の曖昧さが残り、運用者の意図やベンダーの適合性は証明できない。

宛先が許可しても、途中で選択肢を奪われる

拡張ヘッダーを使うかどうかをアプリケーションと宛先が決めても、パケットが途中で落ちれば、その決定は実行されない。RFC 7872が扱った核心は単なる互換性ではなく、第三者のネットワークが宛先の利用可能性を左右する制御境界である。

ただし観測には日付がある。RFCはInformationalとして2016年6月に公開され、2014年8月の測定と、2015年6月に行われた類似結果の再測定を記録している。文書ページの更新や後続RFCの発行は、この標本を現代化しない。

対象はWorld IPv6 LaunchとAlexa Top 1 Millionの二つの履歴リストから作られた。各リストについて、AAAAからWebサーバー、MXからAAAAを引いてメールサーバー、NSからAAAAを引いてネームサーバーを得た。重複、グローバルユニキャスト以外、到達不能と判断されたアドレスは除外された。

試験パケットは三種類だった。DO8はPadNで8バイトにしたDestination Options、HBH8は同じく8バイトのHop-by-Hop Options、FH512は概ね二つの512バイトIPv6フラグメントを生成する。上位プロトコルは常にTCPで、ポートはWebなら80のように対象サービスへ合わせた。

したがって「拡張ヘッダーを試した」という表現だけでは粗すぎる。すべてのオプション、ヘッダー順序、長さ、トランスポート、経路、装置や地域を網羅した実験ではない。

括弧内の数字は、全パケットを分母にしない

各セルの先頭は観測された総損失率である。括弧内は、失われたパケットのうち宛先AS以外で落ちたと推定される割合を、帰属の最良ケースと最悪ケースで示す。

World IPv6 Launch由来のWeb集合では、DO8の損失率は11.88%で、失われたDO8のうち宛先外と推定される比率は17.60%／20.80%だった。同じ集合でHBH8は40.70%と31.43%／40.00%、FH512は30.51%と5.08%／6.78%だった。

Web、メール、ネームサーバーを通じ、World IPv6 Launch集合のDO8は11.88～17.07%、HBH8は40.70～48.86%、FH512は30.51～39.17%だった。Alexa集合ではそれぞれ10.91～21.33%、39.03～54.12%、28.26～55.23%である。

帰属幅も一定ではない。Alexa Web集合で宛先外とされた推定はDO8が46.52%／53.23%、FH512が53.64%／61.43%。AlexaネームサーバーのHBH8では50.64%／81.00%に達した。一方、World IPv6 Launchメール集合のFH512は2.91%／12.73%だった。

81.00%を「HBH8全体の81%がトランジットで落ちた」と読むのは誤りである。標本、サービス、プローブを限定したうえで、すでに失われた部分集合に対する最悪ケースの帰属値だからだ。

最後に返答したルーターは、責任者の名札ではない

RFC 7872は、拡張ヘッダー付きと無しのtracerouteを比較した。前者で最後に応答したノードをM、次をM+1とする。装置が転送判断の前にフィルターを適用するなら破棄点はM+1、後ならMになり得る。測定は前者を仮定した。

さらに、二つのtracerouteが同じ経路を通ると仮定する。RFC自身が、これは成立しない場合があると述べる。ロードバランシングや経路変化があれば、見かけの境界はずれる。

インターフェースアドレスから組織への変換も曖昧だ。ピアリング用アドレスはどちらの参加者が提供した空間かもしれず、IXPの空間かもしれない。M+1を運用する主体が次のASに対応する場合もある。一つの組織が複数ASNを運用する一方、研究は異なるASNを異なる組織として扱った。

曖昧な事例を宛先へ寄せた値が最良ケース、宛先外へ寄せた値が最悪ケースである。この幅は責任者を決めるためではなく、責任者を決められない範囲を記録するためにある。

後続の文書は原因候補を増やすが、動機を確定しない

RFC 7872は、意図したポリシー、不適切な既定値、バグ、解析限界、その他の原因を区別できない。宛先AS内の損失なら修正権限が近い可能性はあるが、問題が小さいとは限らない。トランジットの損失なら、宛先が選んだ機能を第三者が成立させなくなる。

RFC 9098は可変解析、スローパス、資源消費、回避の懸念を説明する。RFC 9288は装置能力を踏まえたトランジットフィルタリングを勧告する。RFC 9673はHop-by-Hop処理を有界で設定可能にする手続きを更新した。いずれも機構や運用上の選択を理解する材料だが、2014年の一つの損失原因を証明しない。

RFC 7045の転送要件やRFC 8200のIPv6仕様も、特定装置の実装証明ではない。「対照には応答したがHBH8には応答しなかった」は観測、「この境界付近で失われた可能性がある」は条件付き推論、「この運用者が意図的に遮断した」は証拠のない動機帰属である。

現在の判断は現在のパケットで作る

導入対象のヘッダー列、順序、オプション、長さ、トランスポート、ポート、パケットサイズ、断片化を固定する。同じ宛先と時間帯で拡張ヘッダー無しの対照を作り、複数の許可された観測点から送る。

送信バイト列、時刻、応答、経路観測、ルーティング状態を保存する。端点を管理できるならキャプチャとカウンターも使う。tracerouteによる境界推定には、経路同一性とフィルター時点の不確実性を添える。

結果はDO、HBH、断片化を分け、可能なら顧客、ピア、トランジット、IXP、宛先経路ごとに集計する。BGP、ポリシー、ソフトウェア、ハードウェア、アプリケーションが変われば再測定する。外部境界が疑われるなら、責任を宣言する前にパケット証拠を相手の運用者と共有する。

結論は「この構成が、このサービスについて、この送信元と経路で、この期間に成功または失敗した」までに留める。その狭さこそ、導入、フォールバック、例外、エスカレーションを実際に支える。