摘要

  • RIPE 2026-02 提案规定：某个 IP 地址在滚动 30 天内累计 14 天出现在获批基础设施黑名单上，便可启动程序；资源持有人随后有 7 个工作日补救，限制须在核实合规后 1 个工作日内解除。
  • 第 3.4 条接受对涉事前缀采取经过核实的隔离措施；第 3.6 条却没有这一选项，只写了移出名单，或在涉及 RPKI 时删除相应 ROA。删除 ROA 会改变起源验证记录；撤回 BGP 路由与隔离前缀是另外的网络操作。

三个计时器，一条不一致的出口

RIPE NCC 的 2026-02 提案把程序拆成一份容易记住的日历。某个 IP 地址在滚动 30 天内累计 14 天出现在“获批基础设施黑名单”上，流程就可以启动。受影响的网络运营商或 National CERT 要通过 RIPE NCC Support 工单提交经过认证的通知，并附上自动遥测数据、时间戳或数字签名。RIPE NCC 随后向资源持有人必须维护的法律、行政和账务联系人发出可追踪送达的补救通知。7 个工作日开始倒数；核实合规后，限制须在 1 个工作日内解除。

日历很好读。麻烦出在最后一步：持有人究竟要证明什么，才能重新获得正常的登记操作权限？

补救时能隔离，恢复时却不算

第 3.4 条给出两种补救方式：涉事前缀从获批名单中移除，或者持有人采取经过核实的行政措施，将这些前缀隔离。第 3.6 条为恢复限制另写了一套判定：前缀已经从名单消失；或者在涉及 RPKI 时，适用的 Route Origin Authorization（ROA）已被删除。

第一条中的“隔离”在第二条里消失了。运营商可以在网络边缘隔离某个前缀，名单的公开历史记录却仍保留旧条目。第 3.4 条把这种措施算作合规，第 3.6 条没有把它列为恢复条件。于是，1 个工作日的恢复时钟缺少明确的启动依据。

删除 ROA 又是另一回事。RFC 9582 将 ROA 定义为一份带有签名的对象，用于授权某个 Autonomous System 宣告指定前缀。RFC 6811 规定，如果没有经过验证的 VRP 覆盖路由前缀，该路由会被标记为 NotFound。这是验证记录的状态。撤回 BGP 路由与隔离前缀需要分别执行网络操作；路由器策略决定验证状态是否改变路由选择或转发。

第 3.6 条的二元检查确实便于快速执行。但它可能得出与第 3.4 条认可的实际补救不同的结论。

黑名单也是执法装置的一部分

提案把获批名单的维护交给 Security Working Group。名单必须使用客观的自动遥测，明确排除住宅和动态用户地址段，并保留可公开核验的历史档案。这些边界有用，实际规程仍待补齐：名单怎样获批、误报如何申诉、计算 14 天时采用哪个历史版本、重叠记录如何合并。

第 3.5 条还让中间限制取决于持有人的注册架构。限制会削弱其登记操作灵活性，并在 RIPE Database 中公开显示“non-compliant abuse status”；同时，提案表示希望保留底层资源分配，避免相邻下游网络立即断连。提案自己的说明也承认，具体且清晰的限制措施还要写入另一份 RIPE 文件，否则容易出现含糊或无法运作的流程。这是权力如何落地的问题，不能留在脚注里。

该提案目前仍处于讨论阶段。RIPE NCC 的 10 月会员更新把意见截止日期定在 11 月 11 日；RIPE 93 的日程安排 Security Working Group 于 10 月 27 日讨论此案。下一版可以先统一恢复判定，再让这只钟开始走。

来源