摘要

  • RIPE NCC 托管的 NRO 11 月 2 日冲突文件有七组双行记录；3 日文件有十四组。新增七组均为 ARIN 与 RIPE NCC 的 IPv4 行相对，其中 187.78.192.0/18 两边的起点和地址数量完全相同。
  • 七组中 RIPE NCC 的每个区间，都能在其11 月 2 日扩展委派原始文件找到精确行；ARIN 的2 日与3 日完整原始文件，对这七个区间都没有重叠 IPv4 行。合并报告与当前来源并未讲同一件事。

最值得盯的是清单从七变十四的瞬间。一个数字翻倍，足以让监控面板变红；可“冲突组数”既不是受影响地址数，也不是已确认的重复分配数。新增七组有共同模式：一侧写 ARIN，另一侧写 RIPE NCC，资源类型都是 IPv4。若把文件名当成结论，调查会从错误的起点出发。

拿 187.78.192.0/18 作显微镜。3 日清单给 ARIN 标 US、assigned、2025 年 2 月 20 日，给 RIPE NCC 标 RO、assigned、同月 25 日。两行同从 187.78.192.0 起，各为 16,384 个地址。它们不是相邻的两块，而是纸面上重合的一整块 /18。

然而，ARIN 2 日原始文件与3 日原始文件都没有覆盖该 /18 的 IPv4 行。RIPE NCC 的2 日原始文件确实含有这段地址，状态写作 allocated；RIPE NCC RDAP也返回起止范围一致的 RO-M247RO-20250225。连 RIPE NCC 这一侧，合并清单的 assigned 与当期原始文件的 allocated 都不一致。文件里的红字需要来源版本，不能靠声量补齐。

其余六组的 RIPE NCC 起点分别是 64.254.88.0、140.184.8.0、140.184.28.0、140.184.96.0、153.52.128.0 与 208.90.252.0。RIPE NCC 原始文件逐一有精确区间；ARIN 两天的完整原始文件逐一没有重叠行。有些合并清单中的 ARIN 行是比 RIPE NCC 区间更大的父块；当期 ARIN 文件里也没有那些覆盖父块。这不是挑一个反例：七个都核过。

原有七组仍留在清单中，其中包含 IANA 保留的文档与协议资源。它们与这次新增的跨 RIR IPv4 组不是同一批问题。把十四组统称为“当前双重持有”，会把合并输出中的旧行抬升为现实中的新争议。现在能确定的是：3 日合并输出出现七条 ARIN 侧记录，而连续两天的 ARIN 当期委派文件都不支持这些重叠。

尚缺合并任务使用的 ARIN 输入版本清单与逐行处理轨迹；这两项会指出旧行从哪里进入结果。没有它们，就不能把文件失配写成真实的地址权属冲突，也不能替合并流程编造故障原因。