摘要

  • 实验中，35,029 个数据包在 4.2 秒内均匀发出，超过 34,000 个在 250 毫秒内抵达受控接收端。
  • 研究团队在 2025 年 6 月至 2026 年 1 月间扫描出 1,909,440 个符合测试条件的隧道主机；这不是实时、永久可用的中继清单。

Le Gai、Zedong Jia、Lin He、Daguo Cheng、Chentian Wei 和 Ying Liu 在 USENIX Security 2026 发表的 TED 研究，讲的是网络如何把时间变成攻击工具。隧道主机和 IPv6 扩展头链条提供不同的转发延迟；发送端据此安排数据包，让原本分散到数秒的流量在目标附近聚拢。

最醒目的“180 倍”容易被误读。论文把 20 毫秒接收窗口里的峰值接收速率，除以整个发送阶段的平均速率。它说明流量被压缩在时间上，不是字节数放大 180 倍。一次实验里，团队以约每秒 8,340 个包的均匀速率发送 35,029 个包；250 毫秒内，受控接收端收到超过 34,000 个。

关键并非所有 IPv6 路由器都要解析每个扩展头，而是隧道端点究竟验证什么。外层头决定隧道转发，内层包则随封装一起穿过设备。端点如果接受任意对端、放过伪造的内层来源，并让多层封装继续向前，路径延迟便可能被用来安排到达顺序。只检查外层地址，等于只查快递袋，不看里面的收件路线。

研究团队在 2025 年 6 月至 2026 年 1 月执行了 44 轮随机扫描；每轮覆盖约 37 亿个 IPv4 地址和 2,000 万个 IPv6 Hitlist 地址，六种隧道协议累计识别出 1,909,440 个主机。对脉冲效果的测试使用六台自有控制的双栈服务器，分布在中国、日本、德国和美国。论文明确称没有把线上运营服务作为攻击目标。

标准文本也要说准。论文把 RFC 8200 概括为“扩展头只由最终目的节点处理”，但对 Hop-by-Hop 选项，RFC 8200 允许路径节点在显式配置后检查或处理，RFC 9673 又更新了相关程序。标准细节不能替隧道入口的验证缺口背书，也不能被简化成“中间路由器一律不处理”。实际防线是验证隧道对端和内层源地址、限制嵌套封装，并在解封装后检查包体。

这些控制会影响合法 VPN、过渡网络和其他封装流量，不能靠一个“全拦”规则交差。运营团队应记录允许的对端、内层来源和封装深度，让例外有责任人，也能复核误拦。

论文的测量止于 2026 年 1 月。若要知道风险降了多少，需要在这些入口控制上线后重做同口径扫描；没有这组新数，190 万仍是有日期的研究结果，而不是今天的在线资产表。

来源：USENIX 论文页面 · USENIX Security 2026 论文 · RFC 8200 · RFC 9673 · RFC 2473