摘要

  • ACSP建议2026.3报告了一个明确边界：已有/16、maxLength /24的ROA时，同一Origin AS下/16至/24会被视为冗余，而/25至/32据报告仍可另行创建。
  • ARIN修改FAQ后将建议标记为完成；现行示例却只说“any prefix covered”，没有保留上述区间和允许反例，公开文字不足以单独证明产品判定式。
  • 最小补救不是公开代码，而是发布一张带版本的五行语义测试回执，分别记录网页、REST与OT&E的输入、预期结果和稳定原因码。

先承认一次有效回应

2026年1月13日，Chris Woodfield提交了ACSP建议2026.3。这不是一句“文档看不懂”的泛泛抱怨。提交者抄出原例，描述测试结果，指出哪一段表述过宽，还给出一版可以直接采用的替代文字。

2月18日，ARIN答复称已经更新FAQ，以处理该用户遇到的混淆，并把建议结案为“已完成”。从提交到结案约五周。对于一个公开建议流程，这是积极结果：问题有署名、有回应、有状态，机构也没有把具体反馈稀释成一项无期限的内部计划。

限制重复ROA本身也有合理的产品逻辑。ARIN托管ROA已经自动续期，运营者不再需要在旧对象临近到期时先造一个同权副本来维持连续性。如果两个对象没有增加新的起源授权，少一个对象意味着更简洁的清单、更少的删除误会，也可能减少日后维护时选错记录的风险。面向普通用户的FAQ保持简短，同样是合理目标。

因此，本文并不质疑ARIN能否在托管服务中采用比RPKI对象格式更严格的准入规则，也不否定这次回应的速度。要问的是另一件事：既然公开状态已经写成“完成”，什么证据能够证明被接受的那项精确歧义确实得到解决？

建议原本自带验收用例

建议页所引用的旧例从一个/16前缀、maxLength /24的ROA开始。旧文字声称，只要新ROA仍在该/16范围内并使用同一个Origin AS，就不能创建。提交者说，实测行为并没有那么宽。

他报告的分界点是/24。当新前缀长度位于/16至/24，且Origin AS相同时，现有ROA已经授予相应权限，新对象不会增加权力，因而被拒为冗余。若新前缀位于/25至/32，它虽然在地址空间上仍包含于/16之内，却超出现有maxLength；据该次测试，新ROA仍可创建。

被建议的改写把“overlapping”换成“redundant”，并同时保留阻止区间和允许反例。这两部分缺一不可。只写“位于/16之内”，读者很容易把地址包含当成授权包含；明确写出/25反例，才能让人知道应当在maxLength的哪一侧测试。

现行RPKI FAQ保留了部分改动。它说自动续期已经消除了重复ROA的必要，也说ROA不能再相互重叠。示例仍是/16与maxLength /24，条件仍包括同一Origin AS，但结果被概括成：现有ROA会阻止“any prefix covered in the existing ROA”。/16至/24不再出现，/25至/32这个允许反例也没有出现。

这只能证明文字差异，不能证明当前系统错误。本文没有登录客户账户，也没有在生产环境重新提交请求。2026年1月的行为是建议提交者的报告，不是我们在9月进行的独立复现实验。ARIN完全可能拥有正确而一致的内部测试；“covered in”也可能只是“已被授权”的简写。公开页面的问题，是它没有留下足以排除其他理解的边界。

“覆盖”与“匹配”在RPKI里是两道判断

RFC 6811提供了关键区分。一个路由前缀被VRP Covered，条件是VRP前缀与它相同或更不具体，并且相关地址位一致。这一步不检查最大长度。只有在此基础上，路由长度不超过VRP的最大长度，而且Origin ASN相同，才是 Matched。

FAQ并没有把“covered”大写，也没有宣称它在使用RFC定义。它也许只是自然语言。但对熟悉RPKI的人而言，两种读法会自然相遇。/16之下的/25在地址意义上确实被覆盖；然而面对maxLength /24的VRP，它不会匹配，即便Origin ASN相同。被省略的/25反例，正是区分两者的最短办法。

RFC 6482从签名对象一侧定义maxLength：它是指定AS获准通告的最长前缀；若字段缺失，只授权精确前缀。该RFC还明确允许一个有效ROA包含被另一项涵盖的前缀，甚至可以包含相同前缀的两项；只是当较短的maxLength不增加任何权限时，这样做不受推荐。

这不表示ARIN违反标准。对象在RFC下是否合法、一个VRP如何影响路由验证、ARIN产品是否接受一项创建请求，是三层不同控制。托管服务可以只接受更整洁的子集。但也正因为这是产品选择，而不是对象语法自动推导出的结论，边界才应以产品规则的方式公开。

三个公开界面都没有写出完整判定式

ARIN的ROA指南把ROA拆为Origin AS、前缀和最大长度三个部分，随后再次说明重复及重叠ROA不再允许，并让读者到FAQ查看详情。该页没有给出边界矩阵。

RPKI REST API指南对载荷结构写得更具体：同一统一事务可以创建、修改和删除ROA，还可以与ASPA操作组成原子事务，要么全部成功，要么全部失败。资源项公开startAddress、cidrLength及可选maxLength。页面把错误处理指向通用错误码说明，但在本次冻结的页面里，没有“重复”或“重叠”的完整判定规则。

原子事务使问题多了一层。假设客户端在同一请求中删除旧ROA并创建替代项，冗余检查应当针对事务之前的状态、预期的最终状态，还是某个内部中间状态？实现必然选了一种一致模型。客户端若想在本地预检，就必须知道同一模型；否则，一项误判足以让整笔事务失败。

ARIN的OT&E环境适合安全试验。ARIN称其功能集合与生产服务相同，但不与生产相连；用户可以创建测试ROA，也可以在改动实时配置前验证RPKI事务载荷。与此同时，OT&E每月用生产快照刷新，不支持邮件交互，也不由ARIN员工主动监控。

OT&E能提供复现地点，却不会自动变成耐久规范。刷新会改变初始数据，软件版本也会改变行为。若不保存输入元组、预期结果、环境版本与日期，一次成功测试很快又退回成口述经验。

五行回执就能封闭证据链

结案回执可以很薄。表头记录建议编号、文档修订号、服务规则版本和生效日期。每一行记录测试渠道、已有Origin AS、前缀、maxLength、拟提交的AS与前缀长度、预期接受或拒绝，以及稳定的机器可读原因码。再加OT&E构建版本、执行日期和后续替代链接，就足以复验。

五个测试分别是：同一前缀与同一AS；在maxLength以内的更具体前缀；超出maxLength的更具体前缀；相同地址范围但不同Origin AS；在一个原子事务中删除旧授权并增加替代授权。使用文档保留网段和保留ASN即可，不需要客户数据、生产密钥或源代码。

FAQ不必因此变长。简短说明负责入口，版本化矩阵负责精度。它还能把三类事实分开：页面发生过编辑；服务会按某种方式处理元组；“完成”状态确实交付了最初请求的澄清。三者相关，却不是同一件事。