摘要

  • APNIC 的 2026 年第三季度产品路线图拟在 REx 中展示单项互联网号码资源当前及历史的 VRP 信息；公开条目尚未说明字段、采样节奏、验证实现或历史保存边界。
  • 已签名的 ROA、依赖方软件导出的 VRP、某条 BGP 路由的 Valid／Invalid／NotFound 判断，以及运营商依据本地策略采取的动作，并不是同一个“状态”。
  • REx 应为每段历史附上一条精简的来源说明：查询资源与覆盖关系、前缀—maxLength—起源 ASN 元组、观测时刻、数据版本、导出方法、获取完整性，以及“不代表特定网络策略和转发结果”的明确边界。

一条漂亮的时间线会替读者补上因果关系。星期一的绿条结束，星期二的红条开始，于是人们自然认为：有人在两天之间改变了授权，系统发现了变化，路由器随即改变了流量。

这个故事可能正确，也可能只是界面制造的语法。

APNIC 当前产品路线图列出一项第三季度工作：“在 REx 中展示单项 INR 的 RPKI VRP 信息”。条目归属 Information 团队，涉及 REx 与 RPKI 两个产品。它给出的目标很克制：让互联网社群更容易取得 RPKI 状态信息，并为单项互联网号码资源提供历史背景。拟议方案同样简短，即展示当前和历史的 RPKI VRP 状态信息。

路线图不是界面规格书。抓取时，机器可读条目的 changelog 为空，公开文字没有列出未来字段、观测频率、使用的验证器、信任锚集合、源对象标识、比较规则或保留期限。这不能证明 APNIC 内部没有设计；它只说明公共承诺尚未界定读者将看到哪一种“历史”。

这个定义不能留到发布之后。REx 页面一旦上线，就会迅速离开产品语境。安全团队会把截图放进工单，研究人员会统计颜色变化，网络工程师会将时间段与事故时钟对齐，地址交易的尽调文件也可能引用它。一个方便查询的页面，转眼就会成为证据来源。

同一前缀旁边有四种事实

RPKI 的多个记录共享前缀和 ASN，因此很容易被压成一个状态。共享标识并不代表共享权限。

第一种事实是 ROA。APNIC 将 Route Origin Authorization 解释为一份数字签名对象：它说明哪个自治系统获准为某个 IP 前缀发起路由，包含被授权 ASN、前缀与最大前缀长度。RFC 9582 则要求依赖方在用 ROA 验证路由通告前，先完成签名对象与 ROA 专属检查；任何必要检查失败，整份 ROA 都应视为无效。

第二种事实是 VRP。它不是 ROA 文件的另一个名字。APNIC 的技术文章描述了依赖方软件如何获取并以密码学方式验证 RPKI 对象，再从有效内容中导出 ASN、ROA 前缀、前缀长度和 maxLength 元组。这份 Validated ROA Payload 已经经过特定验证流程。它保留起源验证需要的授权语义，却不再等同于签名容器，也不能证明另一个依赖方在同一时刻导出了相同集合。

第三种事实属于一条具体 BGP 路由。RFC 6811 的计算需要路由前缀与起源 ASN：若至少一个 VRP 覆盖该前缀、允许其长度并匹配起源，则为 Valid；若存在覆盖但没有匹配，则为 Invalid；若没有 VRP 覆盖，则为 NotFound。离开被评估的路由，“Valid”便失去了语法主语。

第四种事实属于网络运营商。RFC 7115 明确把验证结果如何进入路由选择交给本地策略。有人拒绝 Invalid，有人先观察，有人将结果与其他属性及例外结合。验证标签不会自动携带一个全球一致的执行命令。BGP 控制平面也不能证明数据包实际走过同一条路径。

因此，一枚状态徽章可能偷偷混合四句话：签名对象通过验证；某套软件导出了这个元组；某条路由相对于该集合得到这个分类；某个网络据此采取了动作。REx 最多可以权威描述自己的观测，不能因为同一前缀贯穿各层，就替其他参与方发言。

最需要克制的是“没有”

当元组存在时，页面可以把前缀、maxLength 与起源 ASN 摆出来。元组消失时，界面却很容易把空白写成原因。

某次 REx 观测中没有相关 VRP，可能因为持有者撤回授权，也可能因为对象或证书过期、签名或清单验证失败、发布点获取延迟、缓存重置、历史档案缺口、处理方法变化，或者查询资源与覆盖前缀的关系没有被界面纳入。仅凭空白区间，不能判断其中哪一种发生了。

更可靠的公开表述是：“本次 REx 快照未导出适用 VRP。”它没有“持有者停止授权”那样戏剧化，却清楚标出主语、数据集和时间。后一种说法将原因和意图归给某个主体，必须有另外的证据。

这种克制不会削弱排障。恰恰相反，成员若看到异常，可以用快照标识、方法版本和前一元组复现差异；研究者也能区分真实变化与档案变化。单独一块空白只会让讨论先花时间拆除界面暗示。

日期不是观测点

RPKI 是一个分布式系统，所谓“当前”必然带着时钟。RFC 8210 把向路由器提供数据的缓存定义为定期获取的全球 RPKI 发布数据集合，序列号代表缓存的逻辑版本。刷新、重试和过期时间决定路由器何时再查询、失败后何时重试，以及旧数据能够继续使用多久。若缓存无法提供增量记录，它可以要求重置并重新传送完整集合。

同一 RFC 也承认，分布式缓存不可能严格同步。所以 REx 在某一时刻看到的集合，不必与马尼拉、东京或奥克兰的一台验证器在同一秒完全一致。短时差异本身不是失信或故障证据；它说明观测位置与观测时间属于结果的一部分。

APNIC 博客刊载的依赖方同步研究把系统分成发布、缓存和执行三层，并指出不完整或陈旧的发布视图可能导致错误的验证或判无效。更重要的是，研究者为自己的测量定义了“足够新鲜”的标准，而不是把“新鲜”当成无需解释的形容词。

REx 的历史也应这样工作。每个区间除了起止日期，还要有实际 observed-at 时间、时区与数据发布标识。如果以后更换验证实现、相关信任配置、历史重建逻辑或比较规则，页面应出现方法边界。否则，测量工具的变化会伪装成被测对象的变化。

注明观测视角并不要求公开服务器拓扑、凭据或内部防护。它只要求把公开判断写完整：此 REx 数据集依照已记录方法，在这个时间得到该结果；如获取不完整或历史无法重建，则如实标注。

“单项资源”仍然有三种查询关系

读者输入一个 /24，可能是在问三个不同问题：是否存在前缀恰好等于该 /24 的 VRP；是否存在覆盖它的 /16，并由 maxLength 允许 /24；或者这个 /24 范围内是否还有更具体的授权。三种视图都合理，却不能互相代替。

RFC 6811 的覆盖规则依赖前缀位与长度，maxLength 随后限制更具体通告能否匹配。如果界面只给颜色，不说明适用授权来自精确元组还是覆盖元组，真正决定结果的字段就被隐藏了。

REx 应把查询关系列为一级字段：精确、覆盖、更具体，或者按公开定义生成的聚合视图。多个 VRP 同时适用时，应保留整个集合，不要挑一条作为代表。集合变化时，要说明哪一个元组出现、消失或改变。相同总数可能掩盖起源 ASN 替换、maxLength 收紧或冗余授权清理，计数无法讲清这些差异。

一条来源说明足以改变证据质量

未来页面不需要再造一座复杂仪表盘，只要为当前状态和每段历史附上十项小记录：

  1. 用户输入的互联网号码资源，以及它与显示前缀之间的精确、覆盖、更具体或聚合关系。
  2. 当前行展示的是签名 ROA、导出 VRP，还是针对一条已注明路由的验证结果。
  3. VRP 的完整元组：前缀、maxLength、起源 ASN。
  4. 区间起止时间、实际观测时刻与时区；开放区间只能说“截至最近一次观测仍为当前”。
  5. 可稳定引用的 REx 快照、数据版本或等效标识。
  6. 在影响可比性时，注明验证器或导出方法与版本。
  7. 信任锚范围及获取完整性说明，对不可用来源给出有限警告。
  8. 方法改变或档案缺口标记，让“没有数据”不会冒充“没有 VRP”。
  9. 当前定义与下一次观测的链接，使截图不成为唯一残存记录。
  10. 清楚写出：此页面不展示特定运营商缓存、本地路由策略、最终选路或实际数据包路径。

这些字段描述公共声明，不触及私钥、成员凭据、未公开事故、内部采集拓扑或敏感安全细节。公开的是证据边界，不是系统内部。

它能证明什么，不能证明什么

完成上述设计后，REx 可以作出很强但很窄的判断：在某次有标识的观测中，已记录的方法导出了这个前缀—maxLength—ASN 集合；某个元组连续存在；一个元组消失而另一个出现；某段历史因为采集缺口或方法改变而不可直接比较。第三方可以复算计数，运营商可以将其与本地视图并列。

它不能仅凭第一处空白断言持有者在那个时刻主动撤销授权；不能证明所有依赖方同步看到了变化；不能在未注明路由前缀与起源的情况下宣称某条路由 Invalid；不能证明某网络拒绝了该通告；更不能证明发生了劫持、中断、流量迁移或业务损失。

APNIC 关于 ROA 与 ROV 测量的文章给出一个很好的类比。若上游网络过滤 Invalid 路由，所有单宿主下游都可能在单一观测点上表现得像自行启用了 ROV。现象是真实的，动作归属却可能错误。问题不在测量存在，而在观测点被隐藏后，人们为结果换了主语。

未来的 REx 历史应成为一名可靠证人，而不是全知叙述者。事故团队可以把它与 BGP 观测、本地验证器导出、路由器日志、持有者说明及数据平面测量拼接。研究者可以引用它的快照，而非从颜色猜原因。成员可以针对一条可复现记录提出异议。

APNIC 承诺的是更容易取得信息和获得历史背景，并未承诺代表整个互联网裁决。只要来源说明与时间线一起出现，这份克制就会成为产品最有价值的部分。

来源