摘要

  • APNIC 在 2025 年 10 月 24 日发布的技术文件中，把镜像放进“主仓库不可达、验证方尚无缓存”的场景。按照证书七天有效、两天后重签的假设，镜像约能维持五天的正常验证窗口；文件据此认为收益“非常有限”。
  • 2026 年 5 月 15 日签署的 APNIC–NNIX 意向书则提出在杭州试行 RPKI 仓库镜像，以降低时延。APNIC 的公告还列出验证速度、数据可用性和网络时延等拟观察指标。
  • 两份材料未必互相否定。前者测的是灾难期间静态副本能撑多久，后者拟测的是就近访问能否改善日常性能。把两者混成一句“镜像有效”或“镜像无效”，都会丢掉判定条件。
  • 目前查到的公开材料不能证明镜像已经上线，也没有给出指标定义、基线、目标、观察点、服务架构、控制边界、试点结果或意向书所要求的另行协议。最小的补强，是公开一张假设对照表。

先看两个动词：评估与试点

APNIC 的两份公开记录使用了相近的基础设施名词，却没有使用同一种证据动作。2025 年的文件是一次情景评估：设定仓库不可访问，比较已有缓存的依赖方与刚初始化、没有缓存的依赖方会发生什么，再判断镜像能否显著改变结果。2026 年的文件是试点意向：在一个指定地点部署或测试镜像，并观察若干性能维度。

这一区别决定了如何阅读“非常有限”与“加强 RPKI”两种表述。前者不是对所有镜像用途的永久判决；后者也不是已经推翻旧结论的实验结果。它们只有在问题、受益者、架构、指标和完成状态被逐项对齐后，才可能构成连续证据。

若不做这一步，公共讨论很容易在两个极端之间摆动：要么把 2025 年的结论扩张为“APNIC 反对镜像”，要么把 2026 年的合作公告当作“镜像价值已经得到证明”。公开记录都没有支持这两个命题。

五天来自证书时钟，不是服务承诺

2025 年 10 月 24 日的《RPKI availability concerns》由 Tom Harrison 撰写，并列在 APNIC 技术文件页面。它讨论的起点不是日常网页时延，而是 APNIC 的 RPKI 仓库无法访问。已有缓存的依赖方可以继续使用先前取得的数据；尚未完成初始化的依赖方则拿不到 APNIC 对象。文件同时提醒，在许多常见路由决策中，未知状态并不会像无效状态那样被拒绝。

文件举出现有分发条件，包括通过 Cloudflare 的 RRDP、遍布 62 个接入点的覆盖，以及从布里斯班提供的 rsync。它随后考虑一个由 APNIC 直接控制、位于“网络经济体”层面的镜像，并指出可通过 DNS 或 BGP 将依赖方引向该副本。这里的镜像仍是 APNIC 数据的另一个分发位置，不是另起一套签发权。

约五天的数字来自证书生命周期假设。若证书有效期为七天，并在签发两天后重新签发，那么仓库中一份刚更新的副本，在最有利的时点约有五天可继续正常验证。超过这个窗口，单纯保存副本不能阻止对象按自己的加密时钟过期。

因此，文件把镜像对所设长时中断场景的额外帮助评为“very marginal”。这不是五天可用性承诺，更不是任何镜像都只能工作五天。它是一个带条件的上界：对象更新节奏、镜像抓取时点和故障发生时刻改变，实际窗口也会改变。

杭州试点把测量移向日常路径

2026 年 5 月 15 日，APNIC 与 NNIX 在杭州签署谅解备忘录。备忘录写明双方拟探索 RPKI 与 IPv6 合作，其中一项是试行 RPKI 仓库镜像，以降低网络时延，并共同制定衡量网络流量时延的指标。APNIC 同日博客把拟观察的范围写得更具体：验证速度、数据可用性和网络时延，并提到若试点成功，可考虑在其他地点扩大。

这套语言的主要受益者不再只是“故障期间刚初始化的依赖方”。它更像是在问：距离更近的分发点，能否让一个观察集合中的验证器更快、更稳定地取得数据？这涉及往返路径、抓取完成时间、对象新鲜度、失败率以及试点所选网络，而不是只计算证书尚未过期的天数。

这使新试点具有合理的独立价值。即使 2025 年的五天结论完全成立，本地镜像仍可能在正常运行时减少某类延迟；反过来，即使杭州测得延迟改善，也不会自动延长对象的加密有效期，更不能证明其能在长时间失去主仓库后维持授权状态。

真正需要避免的，是用一个维度的结果替代另一个维度。毫秒改善不能回答第五天之后会怎样；五天窗口也不能回答每天数次抓取是否更快。

意向书没有跨过上线门槛

签署文本对当前状态给出了重要限制。备忘录称其为非约束性、意向性的安排；双方没有转移资金，也没有义务投入资源。第 9.1 条还写明，开展活动须由双方另行书面同意。这样的文本可以授权探索、会议与设计，但本身不是生产部署证据。

APNIC 执行委员会 2026 年 5 月 13 至 14 日会议纪要记录了相关更新，并称委员会“注意到”该事项；纪要没有给出批准上线或确认完成的决议。APNIC 当前的成员与伙伴页面仍以面向未来的语言描述合作，并链接该备忘录。

查阅的公开材料中，没有发现启动日期、运行状态、服务地址、观察窗口、基线、目标或结果报告。APNIC 当前的 RPKI 认证实践声明列出既有仓库角色和端点；在本次核对的相关段落中，没有看到杭州端点或新的信任锚。这里必须区分“公开材料未说明”和“内部不存在”：前者可由证据支持，后者不能从沉默中推出。

因此，最准确的状态不是“已部署”，也不是“未开展”，而是“公开记录显示试点意向，尚不足以判定执行与结果”。

镜像复制数据，不复制信任权

RPKI 中的仓库镜像可以改变数据从哪里被取到，却不会因距离更近就自动产生新的信任锚。授权对象的签发者、证书链和有效期仍然决定验证结果。公开材料也没有把 NNIX 描述为新的认证机构，或把 APNIC 的签发权转交给 NNIX。

同样，仓库镜像不等于面向公众的 RTR 缓存。依赖方先从仓库取得并验证对象，再把验证后的有效载荷提供给路由器；这与直接改变路由器所连的验证服务不是同一层。若试点包含额外组件，公开记录尚需明确；在没有说明前，不应把它们填进报道。

控制面仍然值得说明。谁决定镜像抓取频率，谁控制 DNS 或 BGP 引流，谁监测新鲜度，谁能下线节点，谁保留日志，谁发布事故说明？这些问题不是怀疑合作方，而是判定“同一份数据的就近副本”究竟处在何种责任边界。

用问题卡而不是成功口号收口

APNIC 可以用一张紧凑的公开对照表，让旧评估与新试点形成累积知识：

项目 2025 年可用性评估 2026 年 NNIX 试点
问题 APNIC 主仓库不可达时，什么能帮助验证方？ 本地镜像能否改善明确的访问与性能指标？
主要受益者 中断期间尚无缓存的依赖方 杭州试点观察集合中的网络与验证器
已公开架构 APNIC 直接控制的经济体级镜像，可考虑 DNS 或 BGP 引流 APNIC 与 NNIX 合作的仓库镜像；具体服务和控制设计未见于所查公开材料
已公开指标 在证书有效期和重签假设下，约五天有效窗口 验证速度、数据可用性、网络时延；定义与目标尚未公开
决策状态 分析文件未建议所审视的变更 非约束、意向性试点，活动须另行书面同意

试点一栏随后应补入基线、目标、分母、观察点、时间窗、数据新鲜度测试、开始与结束状态、结果和不确定性。结项说明还应回答：结果是保留、缩小、替代 2025 年结论，还是根本没有检验那一结论。

这不是给实验增加文书，而是在实验开始前固定成功定义。若时延下降，公众可以知道究竟哪一步变快、哪些风险没有变化；若没有改善，也能区分可信的负面结果、部署故障、观察点选择不当和指标定义缺失。

资料来源