摘要

  • IRR Auto-Manager可以在创建ROA时生成或关联IRR路由对象，但系统仍允许两类记录此后独立删除、保留或脱离托管。
  • ACSP 2026.9要求让IRR操作拥有与ROA相当的可见日志。两份对称日志会改善排查，却仍不能自动证明哪些行来自同一次意图。
  • 一份边界明确的跨记录操作回执，可以记录操作前状态、选择、映射关系、操作后状态和纠错谱系，同时保留ROA授权与RPSL声明的语义差异。

IRR Auto-Manager解决的是一个很具体的问题。过去，资源持有者往往要在不同系统里分别维护Route Origin Authorization和IRR路由对象。两次录入意味着两次遗漏的机会，也意味着同一组前缀和起源AS可能在两处慢慢走向不同状态。ARIN把这项工作收拢到同一条操作路径：创建ROA时，用户可以让系统同时生成匹配的route或route6对象，并把它们关联起来。

评价这项功能，应该先承认它做对的部分。它减少重复维护，却没有把自动化变成强制。IRR Auto-Manager可以按Org ID关闭；即使全局设置为开启，用户仍能在某次ROA创建中拒绝生成IRR对象。如果系统发现已有匹配、但尚未由Auto-Manager托管的对象，用户可以选择替换，也可以保持原样。对于先前已经存在的ROA，Sync Up工具还可以补建缺失对象，或者关联已存在但未关联的对象。

这套设计也保留了退出。IRR对象可以单独删除，而不会影响ROA。删除ROA时，界面会列出相关的自动托管对象，并让用户选择一并删除，或者把它们留下、转为未托管状态。一个含有多个前缀的ROA，会为每个前缀生成一个IRR对象。换句话说，关联关系既不是永久绑定，也未必是一对一。

两类记录的含义本来就不同。ROA是经过签名的起源授权，能够带有maxLength，规定被授权通告可以具体到什么长度。IRR路由对象是RPSL中的前缀与起源AS声明。Auto-Manager不会把maxLength机械展开成一组更具体的IRR对象，而是使用ROA中的前缀条目。这不是系统少复制了一个字段，而是有意维护两种证据的边界。

API把这条边界表达得很清楚。创建时，roaSpec:autoLink控制是否为ROA中的资源寻找或创建相应的route或route6对象；响应里的autoLinked只是说明结果。另一方面，IRR REST API仍能独立执行查看、创建、修改和删除。自动关联发生在一次受控操作中，但两类对象并没有因此被压进同一个数据模型。把它们的日志做成完全相同的字段，反而可能掩盖谁是授权、谁是路由策略声明，以及哪一侧能够独立变化。

因此，现有设计的最佳辩护并不困难：ARIN用有限自动化减少了漂移，保留了用户选择，也没有假装两个记录完全相同。真正值得追问的是，操作证据是否跟上了这条跨系统路径。

ROA一侧已经能看到什么

ARIN现行文档说明，Origin AS/Prefix Pair Change Log会列出一个组织过去365天内新增和修改的ROA。超过100条时，日志会分页。表格字段包括时间戳、操作、来源、起源AS、前缀、最大长度和Changed By。操作显示为Added或Removed；来源则区分Web User、API User和ARIN System。用户还可以通过工单申请完整CSV。ARIN表示会在两个工作日内审核并回复，随后文件可供下载90天。

这比当前状态列表更有用。它不仅告诉用户“现在有什么”，还告诉用户某个起源AS与前缀组合何时被加入或移除、动作来自网页、API还是系统。文档所说的“修改”，可以通过被移除和被加入的组合来呈现；没有必要把它误写成另一个公开的Modified操作值。

公开文档没有描述IRR对象侧与之相当的可见操作历史。2026年5月11日，Randal Kohutek通过ACSP 2026.9提出了这项建议。他的用词很克制：IRR对象系统“看起来没有”类似日志。这个观察并不等于ARIN内部没有数据库历史、安全审计或支持工具，也不能据此判断内部控制不足。

ARIN在5月19日回复，认同该功能会帮助需要跟踪IRR对象操作的客户。它把建议加入路由安全路线图，交给内部优先级与实施规划流程，然后关闭建议。八天内承认需求并给出归属，是一个建设性的处理结果。但“进入路线图”不是上线公告，也没有给出版本、日期或最终字段设计。

两份相似日志仍缺少一条连接

假设今后的IRR日志也列出时间、来源、用户和动作，最直观的不对称就会消失。用户可以分别查看ROA和IRR时间线。不过，最关键的排查问题仍然存在：两边的哪些行属于同一次选择？

创建ROA时，系统可能发现一个已有的未托管对象。用户可以替换它，也可以不动它。一个多前缀ROA可能产生多个IRR对象。之后，IRR对象可以独立删除，ROA继续存在。删除ROA时，相关IRR对象可能一并删除，也可能被保留为未托管。Sync Up既可能新建，也可能只做关联。每一个分支都可能产生表面相似、来历不同的最终状态。

时间相近不能自动证明因果关系。两条同一秒出现的记录可能来自不同请求；间隔更久的两条记录也可能属于一个需要人工确认的流程。某个对象不再存在，并不能说明当时选择了哪一个删除路径。某个IRR对象仍在，也不能说明它是意外遗留，还是用户明确要求保留。

这种不确定性并不需要真实事故才会产生价值。ROA可能被RPKI验证器用于起源有效性判断；IRR数据可能被网络或工具用于生成、审核路由策略过滤器。两者都不能证明真实BGP通告过什么，也不能证明某台路由器实际接受了什么。但当两个记录出现差异时，工程师仍需要回答：这是明确拒绝自动化、沿用已有对象、独立删除、一对多映射、部分失败，还是一次后来完成的纠正？

还要注意，“没有差异”也不等于证据充分。两个记录当前看起来一致，只能说明可见字段在检查时相符，不能说明它们一直由同一操作维护。一个对象可能先被独立删除，随后又由Sync Up重建；最终页面恢复一致，却丢失了中间的控制选择。对值进行比较可以发现状态，对操作谱系进行记录才能解释状态。两者承担的任务不同。

需要的不是面向全社会的无限活动流，而是交给获授权组织的一份有限回执。其字段可以公开，内容则应按权限披露。

让回执跟随操作，而不是跟随某一个数据库

回执首先需要一个不承载个人信息的操作ID和时间戳。它应说明入口是ARIN Online、RPKI API、IRR API、Sync Up还是ARIN System，并记录行为者类别和获授权组织，而不是无条件公开个人姓名。意图也要明确：创建或修改ROA、删除ROA、创建或关联IRR对象、替换未托管对象、删除IRR对象、保留为未托管状态，或者重新同步。

下一部分是操作前与操作后状态。ROA一侧应包括句柄、起源AS、前缀和maxLength；IRR一侧应包括route或route6键、前缀、起源、托管状态和关联状态。一个ROA对应多个前缀时，回执需要展示映射数量。已有对象被复用、替换或保持不动，也应成为明确结果，而不是留给用户从最终列表反推。

退出选择尤其值得单独记录。“删除ROA并删除关联对象”与“删除ROA但保留对象、转为未托管”是两种不同意图。对象缺席不应成为唯一证据。操作失败或只完成一部分时，应有结果分类。后来纠错时，新回执应指向被更正的旧回执，而不是让当前状态悄悄覆盖历史说明。

回执还应明确证据时点。操作已被系统接受、对象已经写入、关联已经建立、导出已经生成，是几个不同状态。若一次调用在ROA成功后、IRR写入前失败，只给一个笼统的“成功”或“失败”都会误导排查。更好的表达是列出每一侧的结果，并说明整个操作是否达到预期终态。这样既不夸大局部故障，也不会把部分成功藏进最终页面。

这里没有理由公开API密钥、长期暴露个人姓名，或让一个组织查看另一个组织的历史。ARIN可以在内部安全日志中保存更详细的信息，同时向获授权资源持有者提供结构化回执，并公开字段定义、保留期限、导出方式和版本变化。透明度在这里是一种受控关系的可验证性，不是把全部后台活动搬到公共网页。

ARIN已经在产品层面做出了正确的制度选择：协调，但不吞并；自动化，但保留拒绝和退出。ACSP 2026.9指向下一步。最有价值的实现不只是让IRR表格拥有和ROA表格一样的列，而是让用户能够证明两次变化是否来自同一次操作，不再要求时间戳承担它没有能力证明的因果关系。

来源