摘要

  • 10 月 29 日的一份个人 Internet-Draft 提出用 RDAP 查询六类 IRR 数据；其中三类 SET 对象和路由策略字段仍可由实现者选择。
  • RIPE NCC 当前的 RDAP /help 响应没有列出草案使用的扩展标识 irr0。要退役 Whois，运营者仍需逐个服务器核实对象覆盖。

退出按钮还带着星号

在 RIPE 93，一位运营者把 RIR 路由注册对象的 RDAP 支持称为自己放下 Whois 前最后缺少的一项功能。六个新路径名还不足以让这扇门自动打开。

Datatracker 于 10 月 29 日发布 draft-aggarwal-regext-rdap-irr-00。四位作者中包括 RIPE NCC 的 Mahesh Aggarwal 和 ARIN 的 Jasdip Singh。草案要做的是把 Internet Routing Registry（IRR）数据放进 RDAP：用 HTTPS 传输结构化 JSON，与 RDAP 现有的注册信息并列。

方案列出了六个查询路径：irr0_route、irr0_routeSet、irr0_autnumSet、irr0_rtrSet、irr0_peeringSet 和 irr0_filterSet。route 查询由前缀和起源 ASN 定位；SET 对象可以把成员以数组返回。autnum 响应也可以按顺序携带导入和导出策略，包括多协议字段以及 import-via、export-via。

限制也写在同一份草案里：peering-set、rtr-set、filter-set 是否支持，由实现者自行决定。irr0_policies 同样是可选字段。客户端即使会说这套新接口，也可能从服务器那里拿不到过滤器实际依赖的对象。纸面上的六扇门，不等于六项服务都已开放。

这不是抽象的接口之争。ARIN 说明，其 IRR 与公开 Whois 信息分属两个数据库。资源持有人提交 RPSL 对象，其他 IRR 再取用这些对象作网络路由决策。ARIN 提供 NRTM、文件下载和 43 端口 Whois 查询。ARIN 还把自家 NRTM 流中的对象称为“authorized”，并说明这类记录要经过登记关系和协议状态核验。迁移要保住这些运行细节，不能只把文本换个 JSON 外壳。

RIPE Database 当前的 RDAP 文档列出四种类型：autnum、domain、ip 和 entity。我直接读取其 /help 响应，看到若干已公布扩展，却没有 irr0。这只说明 RIPE 当前服务的状态；但足以看出新草案与实际部署之间仍有距离。

草案状态也很明确。Datatracker 将它标为个人 Internet-Draft，注明 IETF 尚未认可它，而且它在标准流程中没有正式地位；IESG 状态是 I-D Exists。下一步需要的是实现证据，而不是另一张漂亮的架构图。

JSON 只解决了半道题

草案做了具体工作：把 RPSL 的 route、route-set 等概念映射到 RDAP 对象，给查询路径起稳定名称，并按顺序携带策略字段。软件可以少维护一种专属解析器。但转换必须保留对象原意。策略字符串是一项声明，不是 BGP 观测；RDAP 返回 route 对象，也不能证明网络正在通告或接受这条路由。

可选项又把决定权放回每台服务器。每个 RIR 都要选择开放哪些 SET 类型和策略数据。分步部署因此更容易，却也让 irr0 无法成为“数据完整”的通用徽章。草案要求支持该扩展的服务器在 rdapConformance 中公布 irr0，帮助响应也要列出。客户端可以检查这个标志，还得逐类测试自家过滤器和自动化真正使用的对象。

草案的隐私章节还指出，查询可能影响登记数据中的个人。统一 JSON 格式不会替服务器决定哪些联系人资料应该公开；每个实现都要把这道边界讲清楚。

迁移清单应回答一组可重复核验的问题：/help 是否公布 irr0？哪些类能查到？成员数组和策略顺序是否保留？缺失对象会怎样返回？注册及最后修改事件是否仍在？客户端能否把响应与当前 RPSL 对象和镜像数据逐项比对？

草案尚未提供跨 RIR 的已部署覆盖矩阵。若能逐个服务器查询并按字段对照现有 RPSL 输出，再公开版本化结果，判断才会改变。

RIPE 93 那位运营者要求同行核对日常使用的对象，方向是对的。迁移从具体对象开始。“我们有 RDAP”回答的是数据怎么传。等关键记录完整抵达，Whois 才有真正的退场条件。

来源