摘要

  • AFRINIC 于 2019 年 11 月 4 日发布首份 RPKI AS0 提案 AFPUB-2019-GEN-006-DRAFT01，拟为其服务数据中记录为未分配的地址空间签发 AS0 ROA；现有证据只证明提案发布，不证明采纳、实施或产生任何实际路由效果。
  • 对确实未分配的空间，AS0 ROA 可以成为经过认证的负面信号，降低各网络分别维护未经认证、可能过时的清单所带来的成本；这是该提案最有力也最应被正视的善意理由。
  • 风险来自同一条技术链：错误或陈旧的登记状态被签名并发布后，验证器可能把合法普通来源判为 Invalid；ROA 本身不会删除 BGP 路由，但运营者可在本地选择拒绝、降权、监测或不采取行动，因此后果会因网络而异。
  • 合理边界不是把 AFRINIC 描述成执法者，而是把它限定为精确、可审计、可纠正的私人技术记账与协调服务：范围必须明确，冲突必须预先暴露，变更历史必须可见，合法状态变化前必须协调撤回，紧急纠错必须可用，并由独立观察确认依赖方已经看到新状态。
  • NRS、LARUS 与 BTW 在这条链上能提供的不是另一套主权，而是成员侧审视、运营连续性视角与机制化说明；资源记录、签名发布、争议判断和网络路由决定应保持分离。

一个登记状态，如何变成网络信号

这篇文章只讨论一个具体时点和一个具体制度动作：2019 年 11 月 4 日，AFRINIC 发布 AFPUB-2019-GEN-006-DRAFT01，即这一系列中的首份 RPKI AS0 提案。它拟由 AFRINIC 针对其服务数据中记录为未分配的地址空间发起 AS0 ROA。这里的关键动词是“发布提案”，不是“实施政策”。现有证据没有证明该草案获得共识、被董事会批准、投入生产或影响过任何一条路由；也没有证明某位持有人因此受损。把这些未获证明的后续结果写进 2019 年 11 月 4 日，会把一个可以精确分析的制度设计问题变成未经证实的事件叙述。

即便只停留在提案层面，它所触及的控制面仍然十分重要。未分配原本是登记服务中的一种记录状态。AS0 ROA 则会把这种状态编码为可由 RPKI 依赖方验证的负面来源声明：在覆盖范围内，普通可路由 ASN 不被预期为合格来源。于是，一个数据库分类不再只供后台查询，而可能经过证书链、RPKI 仓库和验证器抵达各网络的路由策略入口。

这不是法律命令，也不是路由删除指令。密码学验证能够说明对象在相应证书链内被签发，却不能把“登记为未分配”变成法律裁决，更不能证明某个来源有恶意。来源验证产生的是技术状态。网络运营者再依据自身配置决定怎样使用这个状态：拒绝、降低偏好、触发告警、进入调查，或者暂不改变路由选择。正因为最后一步仍是本地决定，AS0 信号既不会造成一个必然、同步的全球封锁，也不能被当成毫无现实力量的纯粹信息。

它的力量来自分布式采纳。一个运营者可能只监测，另一个可能降权，第三个可能拒绝；相同的 Invalid 在不同网络上形成不同效果。错误信号不需要拥有强制法权，便可能通过许多独立配置的叠加影响可达性。反过来，准确的信号也不需要获得所谓主权地位，便能帮助运营者识别异常来源。评价 Draft 1 的正确尺度因此不是“AFRINIC 是否有权统治路由”，而是“它能否准确、透明且可逆地提供一项运营者愿意采用的技术服务”。

先承认它为什么有用

对 AS0 提案最有力的辩护并不复杂。真正未分配的地址空间没有普通公共来源。若有人宣布其路由，运营者需要一个可信线索来判断该公告是否值得接受或调查。各网络当然可以自行维护清单，但分散的人工清单可能缺乏认证、更新不同步，且重复消耗监测资源。由维护相关分配状态的登记服务发布一项签名信号，能够把记录和来源验证置于同一套技术体系中，向依赖方提供更连贯的警示。

这也是为什么不能以“任何负面信号都是越权”草率结束讨论。路由安全确有实际任务：减少从确实未分配空间发起普通来源公告时的识别成本，向网络提供经过认证而非凭传闻形成的判断输入。AFRINIC 维护相关登记状态，因此在狭窄意义上，它可以成为这项信号服务的合理运营者。只要对象精确表达其实际掌握的记录状态，并且网络保留是否依赖及如何响应的选择，这项服务无需借用公共权力叙事也能成立。

但善意用途不是对设计缺陷的豁免。恰恰因为运营者可能相信签名对象，信号越有用，发布者越需要证明基础记录准确、状态转换协调、错误能够快速撤回。认证提高的是声明来源和对象完整性的可信度，不会自动提高被签名事实的真实性。若底层账本错了，签名只是让错误更稳定、更易分发、更可能被自动系统采用。

真正的考题在撤回路径

Draft 1 将“未分配”变为 AS0 覆盖，建立了一条从登记分类到网络响应的因果链。链的前半段很容易描述：AFRINIC 记录状态，按提案形成签名对象，仓库发布对象，验证器取回并计算来源验证结果。后半段更难，却更重要：当记录被挑战、地址空间出现合法状态变化，或者负面对象与现实使用发生冲突时，谁先发现，怎样证明，何时纠正，依赖方又在何时真正看到撤回？

若地址空间确实未分配，链条工作如预期，AS0 ROA 为运营者提供认证警示。若登记状态本来就错，或者原先正确却在随后合法使用前未及时撤回，普通来源就可能得不到覆盖 ROA 的授权而成为 Invalid。这里谈的是设计上的因果风险，不是声称 Draft 1 曾导致某次事故。现有记录没有给出受影响前缀、运营者、持有人、丢包数据或中断报告。

撤回之所以不能被视作发布后的行政收尾，是因为依赖方观察到的并非登记人员心中的新意图，而是仓库中可取得、验证器实际处理的对象状态。后台把地址空间从“未分配”改成另一状态，并不等于所有网络已经看见 AS0 对象消失。可信转换需要把登记更新、对象撤回或替换、仓库发布、验证器观察和运营者重新评估视作同一项连续性工作。任何一环延迟，都可能留下“账本已经改变，负面签名仍在被依赖”的时间差。

所以，Draft 1 留下的最重要问题不是应当选择一个缺乏现有证据支持的具体时限，而是设计原则：撤回必须在合法委派或其他合法使用开始之前完成协调，并且完成状态必须能够被外部观察。没有可见确认的“我们已经处理”，不能替代依赖方实际取得的新状态。越是准备把 Invalid 用于强力拒绝的网络，越需要知道发布者的撤回与纠错链条是否足够可靠。