要約

  • IETFの仕様は、相互運用可能な状態機械、セキュリティ上の依存関係、障害回復の手順を定義する。しかし、仕様の標準化段階だけでは、採用規模、容量制約、障害時の性能は分からない。
  • 継続性は、標準化機関、実装者、ネットワーク事業者、権威・検証系の運用者、そして外部測定基盤の間に分散する。RIPE Atlas、RIPE RIS、CAIDA、APNIC Labsは検証可能な手掛かりを提供するが、観測地点の範囲を超えた世界全体の結論にはならない。

仕様はネットワークを運用しないが、運用の境界を決める

IETFの文書が提供するのは、ネットワーク事業者そのものではなく、異なる実装が同じ条件で動くための共通の機械である。RFC 9000は、UDP上で動く安全な多重化トランスポートとしてQUICを定義し、接続移行、フロー制御、輻輳制御、損失回復を含める（RFC 9000）。RFC 9114はHTTPの意味論をQUICへ対応付け、HTTP/3の接続、ストリーム、リクエスト処理を定める（RFC 9114）。RFC 9364がQUIC version 1をIETF Proposed Standardとして記録したことは、実験段階から標準化されたプロトコル群への移行を示す（RFC 9364）。

ここから直ちに「インターネットの大半がQUICに依存する」とは言えない。標準化の地位は、普遍的な実装やトラフィック比率の証明ではない。運用依存が生じるのは、事業者が実装を導入し、端末やアプリケーションが利用し、途中のネットワークがUDP通信を許容し、障害時の切り替えを実装する時点である。つまり、標準は依存関係を直接所有するのではなく、依存関係が接続される接点を定義する。

Google ResearchはQUICの性能と従来のインターネット輸送との違いを評価する研究を公開しているが、その結果は研究環境やGoogleの展開条件に依存し得る（Google Research）。CloudflareもHTTP/3の展開について、UDP上のQUIC、互換性、HTTP/2 over TCPとの差異を事業者の視点から説明している（Cloudflare）。これらは運用の具体性を加えるが、すべての事業者に同じ性能や回復時間を約束するものではない。

継続性は「仕様」ではなく、複数の制御点の連鎖である

QUICの接続移行は、経路が変わってもセッションを維持するための機構を仕様に組み込む。しかし、実際に継続性が保たれるかは、実装が機構を正しく処理するか、ネットワークがUDPをどう扱うか、経路変更がどの頻度で起きるか、輻輳制御と損失回復が現実の容量条件に適合するかに左右される。IETFは機構の意味を定めるが、各事業者の設備容量、フィルタリング規則、障害対応要員を管理しない。

BGPでは、この分散がさらに明確になる。RFC 4271は、自律システム間で到達性情報を交換するBGP-4の動作、経路広告、撤回、セッションの振る舞いを定める（RFC 4271）。しかし、どの経路を広告するか、いつ撤回するか、障害後にどの経路を再広告するかは、ネットワーク事業者の設定と判断に属する。標準文書から、現在の経路漏えいリスク、障害頻度、復旧時間、世界全体の影響範囲を算出することはできない。

RIPE RISは分散したルートコレクターから歴史的なBGP情報を収集し、広告、撤回、可視性の変化、回復パターンの分析を可能にする（RIPE RIS）。CAIDAの歴史的BGPデータも、経路変化、不安定性、撤回、広告、回復を研究する材料になる（CAIDA）。ただし、いずれも選択された観測地点から見た経路であり、世界全体への影響や事業者の意図を確定するものではない。測定は責任を可視化するが、責任主体そのものを自動的に決めない。

DNSSECは検証の責任を分散させる

DNSSECは、単にDNSへ署名を追加する機能ではない。RFC 4033は、デジタル署名と信頼の連鎖によってDNSデータを認証する枠組みを説明する（RFC 4033）。その結果、名前解決の信頼性は、署名鍵、鍵の更新、信頼アンカー、検証器、認証された否定応答などの複数の管理点に依存する。

この構造では、権威サーバーが応答できるだけでは十分でない。署名が期限切れになった場合、鍵が正しく更新されない場合、検証器が異なる設定を持つ場合、利用者から見える結果は変わる。APNIC Labsは、複数のネットワークと地点にまたがるDNSSEC検証挙動を測定している（APNIC Labs）。しかし、ダッシュボード上の検証観測は、すべての権威ゾーンが完全に展開されていることや、特定の障害がどの利用者にどれだけの費用を生じさせたかを意味しない。

ここで標準化が生む運用依存は、単一の組織による所有ではなく、失敗が連鎖する順序に現れる。鍵の管理者、ゾーン運用者、検証器の提供者、アクセス事業者、監視担当者がそれぞれ異なる場合、障害からの回復は「DNSSECを標準化した機関」が実行する作業ではない。誰がどの状態を保持し、誰が変更を承認し、誰が外部から結果を確認するかが、継続性の実質的な境界になる。

測定基盤は外部から見える証拠をつくる

RIPE Atlasは、分散配置されたプローブを使い、到達性、遅延、DNS挙動、経路変化、サービス継続性を調べる能動測定基盤である（RIPE Atlas）。その価値は、仕様や事業者の説明を、特定の地点と時間における観測可能な結果と比較できる点にある。

ただし、プローブの配置、測定方法、期間は結果の意味を制約する。ある地点からの到達性が維持されたことは、別の地域、別のアクセス事業者、別の時間帯でも同じだったことを証明しない。逆に、ある地点で失敗が観測された場合も、それだけで世界規模の障害や単一の原因を確定できない。

この制約は弱点であると同時に、適切な調査単位を示す。測定を使うときは「インターネットはどうだったか」ではなく、「この観測地点から、この期間に、このプロトコル動作がどう見えたか」と問うべきである。BGPの可視性、DNSSECの検証、QUICの接続挙動は、それぞれ異なる観測窓を持つ。複数の窓を重ねても、観測されていない場所の事実が自動的に補われるわけではない。

PIM-SMが示す、回復手順への依存

RFC 7761が定めるPIM Sparse Modeは、制御プレーンの状態、ランデブーポイント、タイマー、トポロジーへの到達性に依存するマルチキャストの例を示す（RFC 7761）。ここでも、仕様は状態遷移と制御の仕組みを定義するが、実際のトポロジー、冗長性、タイマー設定、監視、復旧手順は運用側に残る。

この例は、標準の運用依存をHTTPやDNSだけの問題にしない。プロトコルが複雑な状態を持つほど、継続性は「その仕様が正しいか」だけでなく、「各実装が同じ状態をどの程度正確に維持し、失敗後に再収束できるか」に移る。障害時の容量余力や回復の順序は、仕様書の中に一括して保存されていない。

誰が継続性を支配するのか

この調査で確認できる最も強い結論は、IETFやW3Cがこれらのネットワークを直接運用しているということではない。標準化機関は、相互運用のためのルール、状態機械、セキュリティ依存、実装上の選択肢を定める。実装者はそのルールをコードに落とし込み、ネットワーク事業者は設備とポリシーの中で採用し、運用担当者は鍵、経路、容量、監視、復旧を管理する。測定基盤は、その結果を部分的に外部から検証する。

したがって、障害時の支配点はプロトコルごとに違う。QUICではUDPの扱い、実装品質、経路変更と回復の処理が重要になる。BGPでは広告・撤回の判断と経路選択、DNSSECでは鍵と信頼アンカー、PIM-SMでは状態とトポロジーの回復が重要になる。標準化されたことは、これらの責任を消すのではなく、異なる組織間で接続可能にする。その接続が、運用上の依存関係になる。

公開資料から、採用率、容量制約、障害時の性能、回復時間を一般化することはできない。そうした主張には、対象イベントを定め、複数の観測地点、事業者記録、時間系列、影響範囲を組み合わせる必要がある。RFCは機構の根拠、事業者の記録は実装経験、測定基盤は部分的な外部観測であり、三者を同じ種類の証拠として扱ってはならない。