要約

  • TEDの制御実験では、4.2秒間に送った35,029個のパケットのうち3万4000個以上が、管理下の受信先に250ミリ秒で届いた。
  • 2025年6月から2026年1月までの調査は、六つの隧道方式で条件を満たすホストを1,909,440件確認した。各ホストが現在も攻撃に使えるという意味ではない。

「180倍」は派手な数字だが、何の倍率かを先に読むべきだ。Le Gai、Jia、He、Cheng、Wei、Liuの論文は、20ミリ秒の受信窓で観測したピーク受信レートを、送信全体の平均レートと比べている。データ量が180倍になったのではなく、到着が短い時間に偏った。

仕組みの主役は、アプリケーションサービスではなく隧道だ。外側のヘッダーで次の転送先を決めながら、内側に別のIPパケットを運ぶ。複数の転送経路とIPv6拡張ヘッダー処理が遅延差を生み、送信時刻を調整するとパケットの到着をそろえられる。実験では平均毎秒約8,340個を4.2秒送り、250ミリ秒の区間に3万4000個超が届いた。

ここで守るべき境界は「IPv6かどうか」だけではない。隧道の入口が相手を認証するか、内側の送信元を検証するか、再帰的なカプセル化をどこまで許すかが効く。外側のヘッダーだけを見て内側の鎖をそのまま転送するなら、入口は通行証を読まずに荷物を配送している。

チームは2025年6月から2026年1月に44回のランダムなスキャンを行い、各回で約37億のIPv4アドレスと2,000万のIPv6 Hitlistアドレスを調べた。累計1,909,440件は六方式でテスト条件を満たしたホスト数である。攻撃効果の評価には、中国、日本、ドイツ、米国に置いた六台の管理下のデュアルスタックサーバーを使い、稼働中の外部サービスは標的にしていない。

論文の標準解釈には補足が要る。RFC 8200はHop-by-Hopオプションを経路上で調べる可能性を認め、明示的に設定されたノードだけが処理するとの期待を記す。RFC 9673はその手順を更新した。したがって「拡張ヘッダーは最終宛先だけが扱う」という一括りでは、現在の規則を正確に表せない。TEDが示す実務上の穴は、隧道の許可設定と、カプセル化を解いた後の検査にある。

運用者は、隧道ピアの認証、内側の送信元検証、入れ子の深さ制限、危険なヘッダー列の検査を組み合わせられる。全面遮断はVPNや移行用途も巻き込むため、どの例外が必要かを記録してから絞るべきだ。

論文の測定期間は2026年1月で終わる。対策後に同じ範囲を再測定すれば、残存する露出を数で示せる。そこが次の観測点だ。

出典：USENIX掲載ページ · USENIX Security 2026論文 · RFC 8200 · RFC 9673 · RFC 2473