摘要

  • GROW 工作组草案用 src-members 把一条 RPSL 集合引用绑定到指定 IRR 注册库，但明确规定这种限制不向子集合的后续递归查询传递。
  • 渐进部署会让识别新属性的解析器与只读取旧属性的工具对同一合法对象产生不同结果；上线审批需要保存逐跳解析来源、双轨结果差异与回滚权，而不只是最终前缀清单。

策略审批页面最容易展示的是结果：根集合名、展开后的成员数量、生成时间和一个成功标记。真正决定策略含义的过程却藏在标记下面。解析器在哪个 IRR 注册库里找到了同名对象？进入这个对象之后，它又按什么顺序搜索下一层集合？遇到未知注册库、环路或深度上限时，它是停止、跳过，还是换了一个来源？

draft-ietf-grow-rpsl-registry-scoped-members-00 试图修补其中一个关键缺口。草案给 RPSL 的 as-set 和 route-set 增加 src-members 属性。像 RIPE::AS-EXAMPLE 这样的值，不再只写集合主键，还写明应该在哪个注册库中查找。它把一次隐含选择变成显式选择，但没有把整个递归计算变成单一命名空间。

名字相同，不等于对象相同

RPSL 集合可以直接列出 AS 号或地址前缀，也可以引用其他集合；被引用的集合还能继续引用。IRR 由多个独立注册库组成，主键并不保证跨库唯一。聚合多库镜像的服务器，很可能同时看见两个同名 AS-EXAMPLE 或 RS-SECOND。

草案描述了两类后果。解析器可能从错误的注册库选中同名对象，把非预期成员编入策略；也可能没有找到预期对象，漏掉本应接受的路由。草案把这些风险与路由泄漏、劫持机会和可达性中断联系起来。这里必须守住证据边界：第 00 版没有证明一个新的具名事故，也没有统计全网有多少系统受影响。

对支持 src-members 的工具来说，解析规则很明确。集合引用必须同时匹配注册库名和主键。如果解析器根本不知道这个注册库，就没有匹配对象。此时若悄悄退回无前缀搜索，等于抹掉作者刚刚写明的选择。

但显式范围只覆盖眼前这一跳。找到 RIPE 中的 RS-SECOND 后，解析器要读取这个对象自己的属性。下一条引用若也使用 src-members，可以另行指定来源；若它仍是 members 或 mp-members，解析器就重新使用原来的来源选择算法。父节点的 RIPE:: 不会沿树传下去。

根查询也是如此。草案要求软件允许用户用注册库限制第一次查找，但明确禁止这项限制自动作用于后续查询。因此，从 RIPE::RS-FIRST 开始，不能被解释为“所有后代都来自 RIPE”。前缀命名的是下一对象，不是整条策略血缘。

向后兼容留下了另一种合法读法

草案没有删除 members 和 mp-members。原因很现实：旧工具不认识 src-members，旧对象也不会同时完成迁移。权威注册库收到含有 src-members 的对象时，必须核验每一项去掉注册库前缀后，也出现在旧属性中。这就给旧消费者留下一个无范围的兼容投影。

如果用户只提交 src-members，权威软件可以按建议自动生成旧属性，把注册库前缀去掉；若用户已经明确提交旧属性，软件不得覆盖。非权威镜像不得擅自生成这些字段。反方向更不可行：从 RS-SECOND 无法可靠推回 RIPE::RS-SECOND，因为丢失的正是来源信息。

同一个通过校验的对象于是可能有两种执行语义。新解析器看到 RIPE::RS-SECOND，选择 RIPE 中的对象；旧解析器只看到 RS-SECOND，按照自己的注册库优先级处理。校验只能证明去前缀后的名字一致，无法证明两个消费者取回的是同一个对象。

草案还禁止在一项 src-members 中同时出现 RIPE::AS-OTHER 与 ARIN::AS-OTHER。带前缀时它们是两个对象，去掉前缀后却都会变成 AS-OTHER，旧格式无法无歧义地表达。为了维持兼容，新格式主动放弃了这种表达能力。

这是部署策略，不是缺陷指控。它说明“注册库接受了对象”与“所有消费者计算出同一策略”是两种证据。

最终清单会擦除解析过程

成员数相同不能证明结果相同。结果集合完全相同，也不能证明下一次刷新仍会相同：两个工具可能依赖不同镜像快照、来源优先级或深度限制。若审批系统只保存最终前缀列表，差异出现后就无法定位是对象变了、镜像迟了、算法变了，还是兼容路径选中了另一个同名集合。

Daniel Kade 在本文提出“解析来源回执”。回执首先记录根主键和调用者为根查询指定的注册库；接着记录解析器实现与版本、是否启用 src-members、可见的注册库，以及每个镜像可验证的序列号、快照或内容哈希。

随后，递归树的每条边都留下证据：父对象的注册库和主键、读取的属性、原样引用、来源选择是显式还是隐式、实际选择的子对象及其哈希。未知注册库、缺失对象、同名冲突、环路、深度上限和结果规模上限都应成为结构化结果，不能只留在易失日志里。

迁移期间，回执至少保存两份输出哈希。一份来自识别 src-members 的解析；另一份复现生产链中仍然存在的旧工具行为。审批比较的是成员身份的精确差集，而不是总数。差异若被接受，必须有审阅者、理由、失效日期和回滚权。

回执最后要把解析结果绑定到策略编译器版本、过滤与归一化规则、生成配置哈希、变更单和部署目标。否则组织只证明了“曾经正确查询过一次”，却没有证明上线的是那次查询生成的制品。

可重现不等于权威

记录来源不会把任意 IRR 对象变成路由起源权威，也不会验证商业关系，更不能替代 RPKI。它解决的是决策可追溯性：谁用哪份数据、按哪套语义，把哪些成员变成了部署候选。

这也不要求公开机密策略、登录凭据或完整路由器配置。对象哈希、来源标识、角色、差异与变更引用，足以证明顺序而不暴露秘密。

双轨结果出现差异时，也不能机械认定新结果正确、旧结果错误。显式范围可能确实修复了旧歧义；但只要某个外包商、子网或旧流水线仍用旧解析器，它的结果就仍有机会进入网络。差异应触发一次明确决策：哪些消费者受影响，哪个结果符合意图，迁移窗口是什么，失败时由谁回退。

草案要求解析器发现循环引用，并建议限制递归深度或输出规模，以控制资源消耗。这些限制同样会改变结果，哪怕 RPSL 对象一个字也没变。因此它们也是回执中的策略输入。

src-members 的价值，在于把过去隐含的一次来源选择写出来。治理的下一步不是把这个选择再次压扁进一张清单，而是保留整条计算路径。注册库前缀只约束一跳；责任必须覆盖策略继续走完的所有跳。

来源

  1. 注册库范围成员草案 Datatracker 页面
  2. 当前草案历史
  3. 第 00 版 HTML
  4. 第 00 版文本
  5. 第 00 版 XML
  6. 前身草案记录
  7. 前身草案历史
  8. 前身草案第 01 版
  9. GROW 工作组职责
  10. GROW 工作组文档
  11. GROW 采纳公告
  12. 作者源代码仓库
  13. RFC 2622：路由策略规范语言
  14. RFC 4012：新一代 RPSL
  15. RFC 2725：路由策略系统安全
  16. RFC 2650：RPSL 实践
  17. RFC 7682：IRR 与路由策略配置考量
  18. RFC 7909：RPKI 路由起源验证问题定义
  19. Lu Heng：最低初始规范、本地化未来决策与自愿采纳
  20. Lu Heng：The Policy Mirror