摘要

  • APNIC 把“Route management alignment”列为 2026 年第三季度 Registry 项目，准备在转移、回收和系统变更之后，自动协调路由管理、资源持有权、Whois 与 RPKI。
  • 这些记录并不是同一事实的四个副本：持有权确认谁有登记权限，IRR 路由对象表达策略或意图，ROA 授权某个源 AS，BGP 则呈现网络实际观察到的通告。
  • 目前公开条目没有说明冲突优先级、事务边界、部分成功后的状态、通知方式与回滚证据。这只能证明公开合同尚不完整，不能证明 APNIC 内部没有设计。
  • 更稳妥的交付物应包括按记录类型划分的裁决矩阵，以及每次任务的版本化凭据，让自动化减少手工操作，却不把合理差异误删成“一致”。

“对齐”究竟在对齐什么

APNIC 的产品路线图中，这个项目只有几行。项目名是“Route management alignment”，归属 Registry 团队，目标是 2026 年第三季度，产品标签包括 ARMS、RPKI 和 Whois。摘要说，要自动对齐路由管理、资源持有权、Whois 与 RPKI；预期收益是减少繁琐、容易出错的人工核对，并在资源转移、回收和系统变更后保持路由与登记信息一致。

方向没有问题。一个网络运营者不该为了表达同一个业务意图，在多个界面反复输入前缀、源 AS 和维护者信息。转移窗口越紧，手工步骤越多，遗漏和错序的概率越大。自动化本来就应该承担这部分工作。

问题藏在“同一个业务意图”里面。四套记录并不承担同一种证明责任。它们发生冲突时，程序必须决定保留谁、延迟谁、删除谁，或者把决定交回给人。这个选择会影响谁还能修改资源记录、哪些路由对象会进入运营者的过滤器、哪些通告会在 RPKI 验证中成为 Valid、Invalid 或 NotFound。看似后台的同步规则，实际上是在分配控制权。

目前捕获的结构化路线图条目列出了年份、季度、团队、产品、摘要和方案，changelog 为空。条目没有公开写明优先顺序、跨系统事务到哪里结束、部分失败如何表示、回滚留下什么记录、何时通知成员，也没有说明 NIR 或外部 IRR 的边界。APNIC 可能已经在内部讨论甚至完成了其中一些设计；现有证据不能否定这一点。可以确定的只是：公众从这个条目里还看不到答案。

资源持有权不是路由通告

资源持有记录首先回答登记问题：APNIC 目前承认哪个账户或组织持有一段地址或一个 ASN，谁因此有权管理相关服务。资源转移发生时，这层权威会改变。它并不自动回答“此刻应该由哪个 AS 通告每个前缀”。

IRR 路由对象回答的是策略问题。APNIC 把 Internet Routing Registry 描述为一组分布式数据库，运营者在其中发布路由策略与通告，其他网络可以据此生成过滤器和配置。RFC 2725 要求创建 route 对象时，同时验证对地址前缀和源 AS 的授权。这个标准还明确容纳多宿主、相同前缀的多个源 AS、重叠的更具体前缀、供应商变更和重编号宽限期。

因此，两个源并存不一定是错误。它可能是冗余安排，也可能是迁移阶段的有意状态。若自动对齐默认要求“一前缀一来源”，就有可能把可用性设计修成单点故障。若它看到 BGP 中只有一个源便删除另一个对象，还可能抹去尚未启用的备份计划。

RPKI 的 ROA 又回答另一类问题。RFC 9582 规定，ROA 是地址空间持有者签署的对象，用于授权一个 AS 为指定前缀发起路由。需要授权多个 AS，就应有多个 ROA。它证明的是许可及其证书链，不证明这个 AS 此刻一定在通告，也不证明路径可达、流量正常或某个路由器会接受它。

BGP 记录的是观察。RFC 6483 说明，依赖方把收到的前缀和源 AS 与有效 ROA 对比，从而得到 Valid、Invalid 或 Unknown。对于 Unknown 或 Invalid 路由采取什么动作，仍然属于每个网络的本地路由政策。注册机构可以发布授权，不能替全网作出选路决定。

更重要的是，各层时钟不一致。RFC 6483 特别提醒，RPKI 对象的传播时间可能不同于路由传播时间。新的 ROA 已经发布，不等于每个验证缓存都已看到；新的 BGP 通告先出现，也不等于授权永远缺失。短暂差异可能是安全切换的正常形状，而不是应该立即覆盖的数据污点。

所以，持有权、IRR 对象、ROA 与 BGP 不能被压缩成一个“真值”。它们各自对权限、意图、许可和行为作证。

2017 年的旧工具已经知道差异需要解释

APNIC 2017 年的 Route Management Guide 提供了一段有价值的产品历史。它太旧，不能当作 2026 年项目的现行规格，也不能用来断言新系统必然沿用同一机制。但它展示了 APNIC 过去如何处理管理意图与公开对象的分离。

旧指南把 MyAPNIC 中的“route”定义为创建 Whois route object 的模板。两者可以分开存在：可以有模板而没有 Whois 对象，也可以有 Whois 对象而没有 MyAPNIC 模板。当 Whois 对象通过别的途径被修改时，模板不会静默跟随。界面会显示 conflict，让用户选择接受外部变更，或把 Whois 对象恢复为模板的状态。

这是一项重要设计。系统没有把差异马上消灭，而是把它转化成一件可见事件：另一个渠道动过公开记录，原有管理意图和新的公开状态需要比较。用户面对的是一个明确选择，而不是事后发现数据已经被“纠正”。

指南还描述了批量同步时的 pending 状态。具备权限并开启选项的用户，可以在创建路由时同时创建匹配的 ROA。在其中一个删除路径中，如果关闭一个已管理且启用 ROA 的子路由，相应 ROA 也会被删除。这些细节说明，早期工具已经涉及独立状态、不同权限、后台任务以及可选的跨系统耦合。

新项目可能会替换这套旧逻辑。真正值得保留的不是旧界面的按钮，而是它承认冲突本身有信息价值。一次外部修改有可能是紧急修正，也有可能是过时残留；如果机器在记录原因之前便选定赢家，差异所携带的证据就消失了。

“在可能时采用事务”需要后半句话

APNIC 在 2024 年推出 Registry API 时，已经公开了一部分现代执行模型。API 可以取得委派信息，并管理 Whois、反向 DNS、ROA 和路由对象。APNIC 举例说，成员增加一个 BGP 通告时，可以通过 API 自动创建 ROA 和 route object，不必逐项登录 MyAPNIC 操作。

公告对事务作了限定。Whois 支持单对象读取和更新；反向 DNS 与抽象路由管理支持批量请求，这些批次“在可能时以事务方式生效”。所有更新都由异步 task object 管理：提交后取得任务链接，查询状态，完成后查看结果细节。

“在可能时”不是一句可以忽略的保留语。它准确指出，多系统操作并不存在一只覆盖全网的事务。单一数据库里的几次写入可以共同提交或回滚；RPKI 对象进入仓库并被独立缓存看到，是另一条时间线；外部 IRR、另一家 RIR 或 NIR 属于另一管理域；BGP 选择更不受 APNIC 的数据库事务支配。

因此，路线对齐项目必须补出后半句：不可能形成同一事务的步骤有哪些？如果 Whois 写入成功而预定的 RPKI 发布失败，任务应处于什么状态？再次提交会不会重复执行已经成功的部分？最后一个安全状态在哪里？是否需要补偿操作或隔离？

一个笼统的 Failed 不足以指导运营。失败必须拆分到每个步骤，注明已经提交的对象、尚未发布的对象和可安全重试的条件。反过来，一个 Completed 也不应暗示所有外部验证缓存、过滤器与 BGP 观察已经同步。

这里没有测试或指控 APNIC 现有 API 出现了上述故障。2024 年公告的意义是，它已经提供了批次、有限事务、异步任务和结果对象这组公开词汇。新项目完全可以用同一词汇，说明自动化到底完成了什么。

资源转移让优先级变成运营问题

APNIC 当前转移条件说明，在向另一家 RIR 转出的场景中，与资源相关的子分配、route object 和 domain object 会从 APNIC Whois 数据库删除。转移完成后，原实体不再享有这些 IP 地址或 ASN 的权利，资源登记到接收方名下。

这段规则清楚说的是 Whois 关联对象。它没有说明 ROA 怎么处理，不能把沉默改写成“APNIC 会删除 ROA”。恰恰因为这道边界存在，新的自动对齐才需要说明步骤。

持有权变更决定谁不再有管理权限。Whois 清理处理源注册机构所发布的对象。接收方要使用哪个源 AS，是新的运营意图；由谁签署新的 ROA，是新的授权行为；路由何时切换，又受传播和网络政策影响。它们相关，但不存在一条字段复制可以替代这些决定。

设想接收方继续使用同一个源 AS：登记主体改变，路由意图却未必改变。再设想接收方准备更换源 AS：为了连续性，它可能希望新授权先可用，再撤掉旧路径。若跨 RIR 操作中，源侧 Whois 对象先消失，目标侧记录稍后才可见，两个注册机构的时钟便形成空档。这些只是用于检验设计的情景，不是对真实事故的陈述。

“先全部删除”可能造成可避免的 Invalid 或 NotFound 窗口。“无限期保留”可能让旧状态继续存在。“按照当前 BGP 自动生成 ROA”则把观察误当成持有者授权。没有一个简单动作适合所有场景。

机器必须学会保留三种“不一致”

第一种是合法的多源。IRR 与 RPKI 都可以容纳多个被授权的源。对齐引擎不能仅因集合不等长，便把一个备份 AS 当成垃圾。它应检查授权、前缀范围和意图，而不是追求单值。

第二种是传播中的时间差。一次变更可以先在数据库 committed，再进入公开仓库 published，随后被独立验证器 observed。每个状态都有不同证据。如果系统把它们统称为 synced，就无法区分“仍在传播”和“已经持久冲突”，也容易在等待期间错误重跑。

第三种是其他合法渠道的修改。旧工具让用户接受或撤销外部 Whois 变更。新工具至少要问：修改者是否拥有 maintainer 权限？这个变更是否比模板更新？它是否真的要求 ROA 同步改变？紧急操作应否先执行再审计？永远让模板获胜，会覆盖有效修复；永远让外部变更获胜，会让管理计划失控。

路线图还点名 deallocation，却没有展开其时序。资源权威终止可以触发撤销，但怎样通知、保留多久、如何处理争议以及 NIR 管理资源，不能从一个词推导出来。外部 IRR 中的对象也不在 APNIC 的本地写入权限内。

不要寻找唯一真相，要指定每个问题的权威

“单一事实来源”在这里是个危险口号。持有记录可以是“谁有权行动”的权威。经过认证的请求可以是“运营者想要什么”的权威。IRR 对象是可供过滤器使用的策略声明。ROA 是来源授权。BGP 是网络行为的观察。若让任何一层统治全部问题，就会把行政状态、意图、许可和现实混为一谈。

APNIC 可以发布一张并不复杂的矩阵。行是转移、回收、直接 Whois 修改、路由模板修改、ROA 修改和系统迁移；列是有权发起的角色、前置状态、可能被改变的记录、允许存在的差异、自动步骤、必须人工审查的条件与申诉窗口。

矩阵还应增加事务列：哪些写入真正共同提交，哪些属于异步发布，哪些需要外部机构配合，在哪个阶段运营者可以安全切换通告或重建过滤器。如果只有一部分完成，系统隔离什么、保留什么、通知谁。

最关键的一条，是把“撤销旧权限”和“创建新意图”分开。持有权转移可以取消原账户的操作能力，不代表 APNIC 可以代替接收方猜测新的源 AS。BGP 中看见一条路由可以触发告警，不应自动变成授权。记录之间的连接应由明确的决策产生，而不是由字段相似产生。

一份能经得起回滚的对齐凭据

每个重要任务都应产生版本化凭据。开头记录事件和任务 ID、触发类型、时间，以及用于确认请求者权限的资源持有快照。然后分别展示路由模板、Whois 路由对象和 ROA 的前后状态。每一处变更都带有记录类型、优先规则和原因码。

凭据必须画出事务边界：哪些步骤共同提交，哪些发布仍在等待，哪些系统不受 APNIC 控制。部分失败时，它应写明成功步骤、失败步骤、最后安全状态、可重复提交条件、隔离措施和补偿动作。所谓 rollback 不应删除历史，而应新增一条“服务状态已退回”的结果。

可见性也需要单独时间戳：Whois 何时可查询，RPKI 对象何时发布，独立验证何时看到，任务何时停止等待。BGP 可以作为观察证据附上，但不能作为命令或可达性保证。

跨 RIR、NIR、deallocation 与外部 IRR 应成为明确范围标记。通知、确认、复核路径和服务负责人需要留痕，但无须公开个人凭证和密钥。稳定的历史指针则保证当前记录被修正后，争议者仍能找回当时的状态与理由。

这是本文提出的治理控制，不是 APNIC 已宣布的产品功能。它也不是要求 APNIC 公开所有内部日志。它只要求受影响者能够分辨：一致是如何形成的，差异是否有意，哪一步尚未完成，谁批准了结果，以及怎样回到最后的安全位置。

自动化本身值得欢迎。真正需要警惕的是，自动化把制度判断伪装成管道细节。APNIC 在减少手工核对之前，应先让冲突的比赛规则与赛果可见。

来源