摘要

  • RIPE NCC 在 9 月 10 日加入的测试把 AS64495-AS131071 与 AS131070-AS131072 都判为保留；前者比测试中的保留区间低一个号码，后者则高一个号码。
  • 实现检查的是“是否存在重叠”，RDAP 映射器再把布尔结果压成对象级状态。因此，reserved 说明这个区块碰到了保留空间，并不证明其中每个 ASN 都有相同的 IANA 属性。

这组测试从两端各跨出一步。配置给出的保留区间是 64496-131071。完全相同的区间返回真并不意外；真正说明规则的是另外两个输入：AS64495-AS131071 向下多出一个号码，AS131070-AS131072 向上多出一个号码，它们仍然返回真。完全位于区间之外的 AS131072-AS131073 才返回假。

IANA 的现行登记表让这一步跨越有了实际含义。AS64495 是分配给 RIPE NCC 的一段号码的末端，AS64496 开始进入文档示例保留段。另一端，AS131071 仍为保留，AS131072 已进入分配给 APNIC 的下一段。也就是说，测试故意把不同登记属性的号码放进同一个 AS-BLOCK，再要求得到统一的保留状态。

代码没有隐藏这种选择。ReservedResources.isReservedAsBlock 先解析候选区间，然后检查任一配置的保留区间是否与它重叠。它不要求候选区间被完整包含，也不逐个判断区块内的 ASN。RdapObjectMapper 随后根据这个结果，在 AS-BLOCK 对象上选择 RESERVED 或 ACTIVE。

作为保护条件，这种偏向并非没有道理。若改成“完全包含”才算保留，一个很大的活动区块即使吞进了一小段保留号码，也可能被简单标成活动。重叠规则宁可多提醒一次，也不漏掉那段保留核心。问题出在这个结果离开判定现场之后：一个词不再携带究竟重叠了哪里、占了多少，以及依据哪一版规则。

谨慎的 RDAP 使用者会同时保存对象类型、起止边界和状态，并在需要时重新与 IANA 登记表连接。另一种数据管道可能先把区块拆成逐个 ASN 的记录，再把对象的 reserved 批量复制下去。这样一来，AS64495 或 AS131072 会因为邻近区间而继承“保留”，尽管 IANA 把它们放在已分配区间。现有证据没有显示某个具名产品已经这样做；这里揭示的是一条可测试的信息损失路径，而不是一次已经发生的事故。

RIPE Database 的文档也限定了 AS-BLOCK 的角色：它把一段 AS 号码委派给某个 RIR，或者把该段标记为保留；这类对象只由数据库管理员创建，其父级维护者还参与控制下层 aut-num 对象的创建。这个管理背景能解释为什么系统倾向保守，但 RDAP 映射出的状态仍不是 IANA 分配动作，不是 BGP 起源验证，也不说明某个 ASN 是否正在通告。

“新”也需要准确界定。Edward Shryane 9 月 10 日的提交只新增一个 53 行测试文件，没有修改 ReservedResources 或 RdapObjectMapper。本次取证时最新的标签版 WHOIS 1.124.1 发布于 8 月 31 日，早于测试提交。这只能证明测试在该标签之后，不能证明既有判定何时进入生产、这次提交是否已经部署，或线上是否存在跨越 IANA 边界的混合 AS-BLOCK。

因此，真正值得记录的新闻是：一项原本容易被误读的边界语义，现在被写成了可执行的契约——只要重叠，就算保留。下一步不必贸然把门放宽，而应把触发结果的交集一起交付：候选区间、命中的保留区间、登记表版本和映射器版本。这样，下游才能把“对象触及保留空间”与“对象内所有 ASN 均为保留”分开。

来源