摘要

  • ARIN 在 2026 年 4 月把 RPKI 信任锚约束列入计划中的公共服务改进，但相关 IETF 文档目前仍是工作组互联网草案，现有材料不能证明已经生产部署。
  • 真正生效的控制面是依赖方本地加载的 .constraints 文件。注册局数据、可能的 NRO 签名状态、编译器、软件仓库和安装节奏都会改变最终边界。
  • 一张记录来源、版本、哈希、转移阶段和本地决策的交付收据，可以提高可追责性，同时保留每个网络自行决定路由策略的权力。

半年并不发生在注册局里

这项设计里最值得运营团队警觉的数字不是前缀数量，而是六个月。当前 IETF 草案提醒：如果约束列表通过操作系统或第三方软件包分发，维护者应当按用户可能延迟六个月更新来设计。这个数字不是对真实安装率的测量，更不是说每个网络都会落后半年；它是对软件交付现实的保守假设。

也正因为如此，注册局端的“每日更新”无法回答本地控制是否新鲜。某次跨 RIR 转移在周一进入新阶段，资源记录在周二更新，编译者周三生成新列表，软件仓库周五发布。使用滚动发行版的网络可能当天安装，使用长期支持镜像的网络或许等到下一季度，另一个网络也可能因事件响应而主动冻结旧版。这三个网络都可以诚实地说自己启用了信任锚约束，却在同一时刻拥有不同的信任边界。

所以，判断一项约束是否“当前”，不能只看 ARIN 网站上最新文件的时间。应当沿着完整链条追问：用了哪些源文件，源文件对应哪个转移阶段，由谁按哪一版规则编译，哪个软件包把结果送出，运营商何时安装，验证器实际加载的哈希是什么，是否存在本地覆盖。缺少任何一环，签名正确也不等于运行状态可解释。

ARIN 57 真正承诺了什么

2026 年 4 月举行的 ARIN 57 上，工程报告把信任锚约束列入计划中的公共 RPKI 改进，时间取决于 IETF 标准工作。紧接着的一页把支撑工作放在 Number Resource Organization 框架下：扩展统计用于说明各注册局持有哪些资源，仍在制定规范的扩展转移日志用于说明资源如何在 RIR 之间移动，这些材料将支持 IETF 的约束草案；rpki-client 已经有实现。

会议记录用更直观的话说明这套机制：为每个区域注册局形成一份获准位于其下的网络资源清单，好比 RPKI 内部的访问控制列表。发言者说草案和可运行代码都在推进。这些信息证明了工程协调，却不是部署凭证。它没有给出生产启用日期、已安装网络数量、软件包版本或实际加载的约束哈希。

截至研究截止日，核心文档 draft-ietf-sidrops-constraining-rpki-trust-anchors-01 日期为 2026 年 8 月 9 日，失效日为 2027 年 2 月 10 日。IETF Datatracker 将它列为 SIDROPS 工作组的活跃互联网草案，IESG 状态为 “I-D Exists”，不是 RFC。NRO 关于构建和签署约束状态的文档同样还是草案。代码先于标准成熟并不反常，但公开说明必须把“有代码”“有设计”和“已配置生产控制”分开。

宽信任锚是一次有意的连续性选择

约束要解决的风险，部分来自九年前为了避免中断而作出的决定。2017 年 9 月，ARIN 与其他 RIR 协调，把自己的信任锚证书改成覆盖所有资源的形式；公告用 0/0 作简写，TAL 没有变化。目的不是扩大行政管辖，而是避免跨 RIR 转移期间短暂的登记不一致，引发下游大量 RPKI 产品失效。

当前草案明确写道，五个 RIR 的信任锚证书都列出全部 IPv4、IPv6 和 ASN 资源。这种宽度为转移提供了密码学连续性，却也意味着一个信任锚在技术上能够为当前持有范围之外的资源签发产品。本地约束的任务，就是把这种宽能力收窄为依赖方“预期该信任锚会签发”的资源集合。

这是一种建立在连续性例外之上的最小权限设计，不应被包装成对某起已知 ARIN 滥用事件的补救。RFC 8211 分析认证机构和仓库管理者可能采取的不利行动，RFC 6480 则确认每个依赖方自行选择信任锚。现有证据展示的是架构暴露面和防护机制，而不是已发生事故。

一份本地文件怎样产生拒绝

SIDROPS 草案把约束定义为一组本地资源并集，包括 IP 前缀或范围，以及 AS 号码或范围；它们代表依赖方运营者预期某个信任锚覆盖的内容。语法采用 allow 和 deny。拒绝项优先，同类条目不能重叠，先后次序无关，未被明确允许的资源会被隐式拒绝。

检查发生在终端实体证书层。如果证书列出的资源不能完全落入相应信任锚的本地约束，验证器应停止处理并把证书视为无效。影响范围包括 ROA、ASPA、RPKI Signed Checklist、BGPsec 路由器证书和 geofeed，因为它们的终端实体证书明确列举资源。使用继承资源的清单、Ghostbusters 记录和签名 TAL 不按同一种方式接受检查。

OpenBSD 的 rpki-client 手册把控制面落到了磁盘：一个 .constraints 文件可以和对应 .tal 使用相同的基本名。TAL 指向信任锚，约束文件表达运营商对该锚签发范围的本地预期。它们挨在一起，却可能来自不同的更新链。只记录 TAL 而不记录约束版本，无法解释某个对象为何从接受变成拒绝。

约束也不是把资源表机械复制一遍。草案指出，ARIN 社群放弃了关于跨区 IPv6 转移的 ARIN-2019-4，因此 ARIN 分配的 IPv6 资源通常不应出现在另一个 RIR 的信任锚下。私有用途、文档用途和某些保留资源也不应位于任何 RIR 锚下。编译者必须把政策范围、保留资源和例外都转化为明确集合。

“每日”只是输入的刷新频率

ARIN 每天更新扩展委派统计，以 NRO 格式报告 IPv4、IPv6 和 ASN 的分配情况。ARIN 同时明确说明：报告不包含再分配和再委派数据。把各 RIR 报告合并，可以发现重叠与空洞，显示已转移地址的状态，也能说明未分配资源的行政责任。这是很有价值的证据输入，却不是已经安装的 .constraints 文件。

每日更新时间不能说明每个上游事件何时发生，也不能说明编译者何时取数、软件仓库何时构建、运营商何时安装。持有量快照和转移过程记录也不是一回事。ARIN 57 正因为认识到这一点，才把现有扩展统计与仍在制定规范的扩展转移日志并列。

如果约束在接收方真正准备好之前就把资源完全切过去，源锚下仍然合法的对象可能被拒绝；如果切换过晚，已经结束的临时许可会继续存在。全资源信任锚原本用于避免转移过程中的大规模连续性问题，一份失去时间语义的本地约束，可能从另一层重新引入中断。

转移途中允许两个锚，可能才是正确答案

draft-nro-sidrops-ta-constraints-00 提出签名的 Resource Distribution State、Event 和 Consensus 对象，参与者的初始资源集合应彼此不重叠。一项转移依次经历发起、接收方接受、来源方最终确认。

在接受之后、最终确认之前，两个信任锚都可以被视为持有这项资源。这个临时重叠让接收方先创建匹配的签名对象，避免可用性空档。最终确认完成后，接收方成为约束验证中的唯一持有者。如果最终确认有误，草案并不把历史直接抹掉，而是允许用一笔补偿性转移把资源送回。

因此，周二编译的列表和周四编译的列表即使不同，也可能各自忠实于当时状态。前者可能允许两个锚，后者只允许接收方。仅看软件包版本，调查者不知道差异来自源数据时间、共识处理、编译规则、发布延迟还是本地改动。转移标识、阶段和各层哈希必须一起保存。

如果 NRO 的签名状态最终投入使用，它会改善上游来源证明，却不会取消依赖方的选择。IETF 草案只把 NRO 状态视为可能的输入，明确每个依赖方按自己的标准、时间表和配置作决定。注册局可以共同说明它们认定的行政状态，不能因此自动取得所有网络的最终路由权。

一张不夺权的交付收据

收据的第一段记录源文件、时间戳与哈希，并写明规范版本、数据模式版本、编译器身份和可复现构建参考。如果使用 NRO 签名状态，还要记录签名方和验证结果。对每个信任锚，应分别公布 IPv4、IPv6、ASN 资源集哈希。

转移中的资源要带上转移标识和阶段，包括允许双锚的短暂窗口。随后记录软件包名称、版本、构建时间、分发渠道、安装时间和本地覆盖来源。验证器实现和版本、实际加载的约束哈希，则把文件和运行实例连接起来。

最后一段记录效果：按对象类型区分，有多少对象因约束而接受或拒绝；何时触发陈旧告警；最后一个已知良好状态是什么；回退和回滚方案是否经过测试；本地运营商在何时作出什么决定。哈希与汇总计数足以支持比较，不必公开敏感的路由器配置。

这张收据还会改善责任用语。“ARIN 拒绝了这个 ROA”常常是不准确的，因为实际停止处理证书的可能是本地验证器，而它使用的文件由其他人编译和打包。注册局提供记录，NRO 可能签署共同状态，维护者生成列表，软件执行检查，运营商决定路由动作。收据让每一个动词都有正确的主语。

证据边界

现有材料不能证明 ARIN 已经为依赖方部署约束，也不能证明所有验证器会使用相同的 NRO 列表，更不能证明陈旧软件包导致过路由事件。六个月是规划假设，不是实测中位数；每日统计有公开的范围限制；ARIN 57 提到的转移日志仍在制定规范。

约束导致证书处理停止，也不自动等于路由撤销。RPKI 验证向运营商提供状态，运营商如何把状态写入本地路由策略，才决定最终结果。本文提出的收据是制度建议，不是 ARIN 或 IETF 的现行要求。它的价值在于把可能出错的最后一公里变成可以核对、比较和撤回的证据链。

来源