LACNIC拟以80%有效ROA作为新增资源条件

摘要

8月12日列入讨论的LAC-2026-3拟规定：组织申请额外IPv4或IPv6资源时，其由LACNIC分配或下发的既有IPv4、IPv6资源至少应有80%得到有效ROA覆盖。
草案把未来的增长申请用作整改既有RPKI记录的杠杆；它没有规定低于80%的持有者立即失去现有资源，也尚未成为现行政策。
真正决定影响的不是“80”这个数字，而是按前缀还是地址量计算、两种地址族是否分别过线、如何补正，以及对争议结果由谁复核。

独立RIR提案索引将LAC-2026-3标为“Under discussion”，最近变更日期为2026年8月12日。草案不是又一次笼统呼吁部署RPKI，而是把要求接到具体交易上：向LACNIC申请更多IPv4或IPv6之前，先证明既有资源达到80%的有效ROA覆盖率。

这一时点决定了谁最先感到压力。没有新增需求的成熟持有者暂时不会碰到这道门。扩展接入区域、增加托管客户或建设新节点的网络会碰到。ROA维护因此从“有空再做”的安全事项，变成可能影响扩容日期的前置工作。

但目前不能把它写成已经发生的处罚。低于门槛不等于现有地址被收回，草案也没有获准实施。新闻事实是LACNIC社区正在讨论一项新的申请资格条件。

“覆盖80%”至少有两种直观算法。Cloudflare Radar的RPKI指标可以按已覆盖前缀占比统计，也可以按已覆盖地址空间占比统计，并把IPv4与IPv6分开显示。同一组织在两套算法中可能得到截然不同的成绩。

一个大地址块和多个小块，按前缀数计算时各占一票，按地址量计算时大块占主导。若只统计已宣告空间，备用但未宣告的地址是否应从分母删除？若统计全部登记资源，没有实时路由的地址为何又必须有起源授权？再遇到下游分配或客户起源，创建ROA的实际责任也未必落在同一主体。

IPv4和IPv6不能靠简单相加形成有意义的总量。草案需要说明是两者分别达到80%，还是只检查本次申请涉及的地址族，以及未持有其中一种资源时如何处理。数字越整齐，计算规则越应公开。

RFC 6482把ROA定义为经过签名的对象：地址块持有者授权一个自治系统起源一个或多个前缀，并可用maxLength约束更具体的宣告。Cloudflare的操作说明解释了它的用途——其他网络可以验证前缀与起源ASN的关系，并据此过滤路由。

这是一项有力但边界清楚的证据。有效ROA不保证每条实时路由都配置正确，也不保证所有验证器在同一秒取得完全相同的数据。没有ROA同样不自动证明路由劫持。新规则必须区分签名对象有效、资源得到覆盖和实时路由状态三个事实。

日常变更会使纠正期限变得必要。网络迁移可能更换起源ASN，更具体前缀可能超出旧maxLength，授权也可能在替换或仓库同步期间短暂缺失。若申请只在一个瞬间被打分，发布故障就可能被放大为扩容延误。

草案的吸引力并不难理解。培训与倡议往往排在紧急运维之后；一旦资源申请取决于RPKI清单，团队就有具体理由删除陈旧授权、补齐缺失ROA并核对起源ASN。更多准确授权也会帮助实施路由起源验证的其他网络。

然而，当分数可以暂停申请时，倡议就变成资格决定。NRS对LACNIC职责的独立介绍将号码资源分配、登记和区域政策列为核心职能。LAC-2026-3拟把这项分配职能与此前已发资源的路由安全状况连接起来。

两者技术相关，不代表程序问题可以省略。仪表盘上的误判只是数据瑕疵；作为申请条件的误判可能影响设备上线、客户合同和服务日期。

Lu Heng在《The Policy Mirror》中区分了保持登记准确的窄规则与借稀缺资源决定更广泛行为的厚规则。此草案正落在边界上：被检查的ROA确实与地址直接相关，但执行发生在下一次分配。因此，知晓、纠正和挑战计算结果并非法律附注，而是这项安全机制的组成部分。

下一版文本至少应公布分子、分母和完整算例，并标明验证快照的时间与来源。申请者应拿到拉低分数的资源清单和精确原因：缺少ROA、对象无效、起源ASN不符、前缀长度未覆盖，或登记归属存在争议。

纠正期内，申请的排队位置不应因可修复问题而丢失。由仓库或验证器造成的暂时故障不能算在申请者头上。确有理由无法创建ROA的资源应走狭窄、成文、可审计的例外，而不是临时协商。

复核者还必须能检查资源清单和采用的RPKI快照，而非原样重复首次评分。公开汇总的原因代码，则能帮助社区判断规则究竟在修复疏漏、暴露文本歧义，还是制造行政阻塞。

80%可能成为有用的维护底线，但今天仍只是提案。LAC-2026-3找到了一个很有力量的安全时点——组织想要增长之时。下一步要证明，这股力量最终通向可验证的整改，而不是无法解释的否决。