摘要

  • Usama Ejaz 与 Antonis Chariton 对齐了 2026 年 8 月 8 日至 14 日的 BGP 通告、IRR 对象和 RPKI 状态。RIPE 93 原始摘要称，一周内观测到的前缀—源 AS 配对中，64.4% 有精确 IRR 对象。
  • 在这些精确匹配中，786 个整周保持 RPKI Invalid：371 个超过 ROA 允许的最长前缀，415 个使用了 ROA 未授权的源 AS。

凭条与红灯同在

运营者制作路由过滤器，查到同前缀、同源 AS 的 IRR 对象，便容易以为手续齐了。Ejaz 在官方逐字记录里把四件事排在一起：BGP 实际通告、IRR 精确对象、RPKI 验证状态、AS-SET 成员关系。任何一项单独取出，都不足以解释其它三项为何冲突。

研究覆盖 2026 年 8 月 8 日至 14 日。团队使用 57 个 RIPE RIS 与 RouteViews 收集器所见的公开前缀—源 AS 配对，对照 19 个 IRR 来源与整周可用的 17 个 RPKI 验证视角。一周观测合集的 64.4% 有精确 IRR 匹配；其中 79.9% 只见于一个 IRR 来源。自动化系统若把“查到了”直接当成“准许了”，就会把单一资料源抬成裁判。

最刺眼的是持续整周的 786 个冲突。RIPE NCC 的源验证指南说明两种机制：371 个通告的前缀比 ROA 的 maxLength 更具体；415 个由覆盖它们的 ROA 未授权的 AS 发出。要修正某一条，缺的是资源持有人当前究竟要授权哪个前缀、哪个源 AS、允许多长的前缀。两类错误不能交给同一张修改单。

老对象不会自己退场

团队另保留 140,360 个更宽泛 IRR 对象的候选情况。新的具体前缀出现后，旧的覆盖对象仍可留在系统里。RIPE 数据库的对象创建规则还揭示权责差异：创建 route(6) 对象需要针对地址资源认证，却不必由对象写明的源 AS 持有人认证。IRR 行与 ROA 来自不同授权路径。

另一次 AS-SET 递归重放保留了 99.27% 的精确 IRR 匹配，但无法完整展开的部分仍需人工查清。Ejaz 给出的是核对顺序：先看通告，再看对象，再看 ROA，最后找到能纠正冲突记录的资源持有人。

原始资料：RIPE 93 研究摘要；官方逐字记录；RIPE NCC 源验证指南；RIPE route 对象规则。