摘要

  • LACNIC 把两项具体能力接在一起：成员通过 MiLACNIC 创建、配置并发布 ASPA 对象，FORT 则增加了 ASPA 验证支持。
  • 到路由器的最后一段另有开关。FORT 1.7.0.experimental 加入 RTRv2 支持，但其最高 RTR 版本默认设为 0。

按钮已经上线。路由器不一定收到通知。

在 LACNIC 46 上，该注册机构宣布，持有 ASN 的成员可以直接在 MiLACNIC 创建、配置和发布 ASPA 对象。操作既可逐个进行，也可批量处理，还能查看状态并在发布前预览。LACNIC 同时宣布，其开源 RPKI 验证器 FORT 已支持验证 ASPA。成员门户和验证器因此各自进入同一条部署链。

这是实打实的进展，但故事并没有在“支持”两个字上结束。“ASPA 已启用”可能指不同时间点，每一步留下的凭据也不同。

第一步，资源持有人把获授权的转接服务商写入 ASPA 对象。MiLACNIC 的预览和状态功能让成员在发布前检查这份声明。随后对象进入 RPKI 的发布与获取流程，由验证器检查签名材料。LACNIC 称 FORT 的 ASPA 核心验证功能于 2026 年 7 月发布；1.7.0.experimental 版本记录列出 ASPA 与 RTRv2 支持，也提供可选的有效 ASPA JSON 输出。

然后才轮到路由器。FORT 发布说明写明，--server.max-rtr-version 默认值为 0。改为版本 2，等于主动启用仍在演进的 RTRv2 功能；发布说明直接把它标为 experimental。截至目前，IETF 的 ASPA 配置文件、AS_PATH 验证和 RTRv2 文件仍是 Internet-Draft，尚非正式发布的 RFC。FORT 可以验证 ASPA，而运营方的 RTR 服务仍维持默认设置。文件里有有效 ASPA，不等于路由器已经收到它。

因此，比起单一的“ASPA 已启用”绿灯，运营团队更需要一串问题：成员是否看到了预期对象及其发布状态？验证器能否取回并验证？ASPA 输出有没有开启？服务器提供哪个 RTR 版本？路由器是否完成协商并加载客户—服务商数据？BGP 策略是否查询这些数据，它对被评估的路由作了什么决定？

这次公开公告没有给出区域采用数量、路由器协商数量，也没有统计策略实际使用情况。值得报道的是 LACNIC 把哪些工具交到了成员和运营团队手里，以及工具之间仍有哪些接缝。入口已经打开；最里面那扇门还要看配置。

来源