摘要

  • RFC 7872 测量的是 2014—15 年两组历史地址样本上三种明确构造的 IPv6 探针。表中的百分比不是 2026 年全网扩展头丢包率。
  • 研究能够估计部分丢包是否发生在目的 AS 之外，却无法消除路径、接口地址与组织归属的不确定性，更不能证明过滤意图、厂商合规性或某家运营者的动机。

真正的问题不是数字，而是谁有权让报文通过

IPv6 的目的端可以选择使用分片、Destination Options 或 Hop-by-Hop Options，但这不代表目的端拥有最终决定权。若中途网络先行丢包，目的网络连执行自己策略的机会都没有。RFC 7872 把这个控制权错位变成了可以观察的问题。

先要把时间钉牢。RFC 7872 于 2016 年 6 月以 Informational RFC 发布，正文报告的测量最初发生在 2014 年 8 月，随后在 2015 年 6 月复测并得到相近结果。网页后来更新、规范后来演进，都不会自动刷新这批观测。因此，“报告曾经测到什么”与“今天的互联网正在发生什么”必须分开。

研究使用两个历史域名来源：World IPv6 Launch 名单和 Alexa Top 1 Million。每个来源又派生三类 IPv6 地址：网站的 AAAA 记录；邮件域名通过 MX 再解析到 AAAA；权威域名服务器通过 NS 再解析到 AAAA。重复地址、非全球单播地址和被判定不可达的地址在试验前被剔除。

探针也不是泛泛的“带扩展头报文”。DO8 是一个以 PadN 填充到 8 字节的 Destination Options 头；HBH8 是同样为 8 字节的 Hop-by-Hop Options 头；FH512 则让 IPv6 报文形成大约两个 512 字节分片。所有试验的上层协议都是 TCP，目的端口与服务相匹配，例如网站使用 80 端口。

所以这份研究并未穷尽所有选项类型、扩展头顺序、链长、报文尺寸、传输协议、端口、源地区或设备策略。它回答的是：在既定日期、地址集合和探针构造下，预期响应有多大比例没有出现。

一格里有两个不同问题

RFC 7872 的每个表格单元先给出总丢包率，再用括号给出一个“最佳情形／最差情形”范围。括号内的数值只针对已经丢失的报文，估计其中有多少是在目的 AS 之外被丢弃。它不是第二个总丢包率。

以 World IPv6 Launch 派生的网站为例，DO8 总丢包率为 11.88%；括号中的 17.60%／20.80% 表示：在这些已丢失的 DO8 报文中，按两种归属规则估计有如此比例发生在非目的 AS。相同网站集合上，HBH8 为 40.70%，非目的 AS 范围为 31.43%／40.00%；FH512 为 30.51%，对应范围为 5.08%／6.78%。

跨越网站、邮件和域名服务器三类目标后，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 网站样本中，已丢失 DO8 报文的非目的 AS 占比估计为 46.52%／53.23%，FH512 为 53.64%／61.43%；Alexa 域名服务器的 HBH8 范围达到 50.64%／81.00%。而 World IPv6 Launch 邮件样本的 FH512 范围只有 2.91%／12.73%。

这些差异说明，“IPv6 扩展头丢包率”不是一个应被压成单值的对象。地址来源、服务类型、探针形态和推断出的控制位置都会改变结果。同样重要的是，81.00% 不能被写成“全体 HBH8 探针有 81% 在传输网被丢弃”；它只是某个样本里、已丢失报文中的最差情形归属估计。

从最后一个应答跳点到责任主体，中间隔着数次推断

定位方法把携带扩展头的 traceroute 与不携带扩展头的 traceroute 配对。研究把扩展头路径上最后应答的节点称为 M，随后讨论 M+1。但若设备在作出转发决定前过滤，丢包节点更可能是 M+1；若先决定转发再过滤，则可能是 M。论文采用了前者假设。

第二个假设是两次 traceroute 走同一条路径。RFC 明确承认它们可能不同。负载分担、路由变化和返回路径差异都可能破坏这一前提。

即使节点判断正确，从接口地址到组织仍不是一一映射。对等互联地址可能由任一方提供；交换中心地址可能归 IXP 而非成员；真正运行 M+1 的组织可能对应 M+1 或 M+2 的 AS 归属；同一个组织也可能经营多个 ASN，而研究模型把不同 ASN 当成不同组织。

最佳情形把模糊案例归到目的 AS，最差情形则归到其他 AS，于是形成范围。这个范围不是研究者掩盖缺口，而是把“从包到跳点、从跳点到 AS、从 AS 到组织”的证据边界公开出来。

丢包观测不能替代动机证明

研究无法分辨一次丢包来自明确的人工策略、不适当的设备默认值、解析或慢路径资源上限、软件缺陷，还是其他原因。目的 AS 内部丢包可能更容易由目标组织修改，但并不天然无害；传输 AS 丢包则可能剥夺目的组织部署该机制的选择权。

后来的 RFC 能解释可能机制，却不能为历史样本补上因果。RFC 9098 讨论了中间设备对可变长度解析、资源消耗、规避风险和慢路径处理的困难。RFC 9288 把设备能力与运营保护措施带入传输过滤建议。RFC 9673 又更新了 Hop-by-Hop Options 的处理程序，强调可配置且有界的工作量。

这些材料说明“为什么运营者可能作出某种选择”，不说明“2014 年这一次包为什么消失”。RFC 7045 的转发要求不能证明当时某台设备遵循或违反了它；RFC 8200 定义协议，也不是部署普查。

准确的故障语言需要分级：“这个 HBH8 探针没有得到控制探针所得到的响应”是观测；“在给定路径相同和过滤时序假设下，故障可能始于这个边界”是推断；“某个传输 AS 有意封锁 IPv6 扩展头”同时主张主体、原因和动机，RFC 7872 无法支持。

今天的部署判断必须重做今天的测量

新的试验应先写明要部署的准确报文：扩展头链和顺序、选项类型、长度、传输协议、端口、报文尺寸与分片方式。为它构造相同端点和时间窗口的无扩展头控制探针，再从多个获授权的观测点成对发送。

保存原始探针字节、时间戳、源和目的、响应、路径观测和当时的路由快照。若能控制端点，应加入抓包和接口计数器。配对 traceroute 可以缩小边界，但报告必须保留“路径可能不同”和“过滤发生在转发决定前还是后”的不确定性。

在样本允许时，按客户、对等、传输、交换中心和目的路径拆分结果；路由或策略变化后重测；DO、HBH 与分片分别计算。疑似传输边界应先携带包级证据交给相关运营者复现，之后再谈责任。

最终结论应窄到可证：某种具体构造，在这些源、这些路径和这段时间内，对某项服务成功或失败。它足以支持局部部署、回退、例外或升级沟通，却不能为整个互联网颁发证书。