什么是 ROA？Prefix、Origin ASN 和 maxLength 怎么填

ROA（Route Origin Authorization，路由起源授权）是一条经过 RPKI 签名验证的授权记录，用来说明哪个 ASN 可以作为某段 IP 前缀的 BGP 起源，以及允许宣告到多具体的前缀长度。ROA 填错后，合法路由也可能显示为 Invalid，因此创建前必须先确认真实的 BGP 宣告方案。

ROA 应贴合真实宣告范围：授权要够用，但不应为了省事放得过宽。

一条 ROA 包含什么

最需要关注三个字段：

字段	示例	含义
Prefix	2001:db8:1234::/48	被授权的地址块
Origin ASN	AS65001	可以起源该前缀的 ASN
maxLength	留空（等同 /48）	授权允许的最长前缀

如果只准备宣告完整的 IPv6 /48，可以使用：

Prefix: 2001:db8:1234::/48
Origin ASN: AS65001
maxLength: 留空

它表示 AS65001 可以宣告这个 /48，但没有被授权宣告该地址块下面更具体的 /49、/56 或 /64。

maxLength 为什么最容易出错

maxLength 不是“地址块大小”，而是这条授权允许实际 BGP 路由具体到什么程度。

假设你持有：

203.0.113.0/24

只宣告 /24

最严格的授权是让 maxLength 留空：

Prefix: 203.0.113.0/24
Origin ASN: AS65001
maxLength: 留空

还要宣告一个 /25

可以创建覆盖 /25 的授权，但不应为了方便直接把所有更具体前缀都放开。

更清楚的做法是按真实路由分别创建：

ROA 1: 203.0.113.0/24, AS65001, maxLength 留空
ROA 2: 203.0.113.0/25, AS65001, maxLength 留空

这样既能表达实际意图，也能减少误宣告被判定为 Valid 的范围。

原则只有一句：授权范围应尽量贴近真实准备宣告的路由。

Valid、Invalid 和 NotFound

路由验证器会把实际 BGP 路由与 ROA 比较。

Valid

前缀被 ROA 覆盖，Origin ASN 匹配，路由长度也没有超过 maxLength。

Invalid ASN

存在覆盖该前缀的 ROA，但实际 Origin ASN 没有被授权。

例如 ROA 授权 AS65001，上游却使用 AS65002 起源。

Invalid Length

Origin ASN 正确，但实际路由比 maxLength 更具体。

例如 ROA 只允许 /48，实际却宣告了 /56。

NotFound

没有任何 ROA 覆盖该前缀。它与 Invalid 不同，只表示没有授权数据。

多个 ASN 宣告同一前缀怎么办

Anycast、迁移或特定网络架构中，可能由多个 ASN 分别宣告同一前缀。

每个合法 Origin ASN 都需要相应授权。例如：

2001:db8:1234::/48 → AS65001
2001:db8:1234::/48 → AS65002

不能因为两个 ASN 属于同一家公司，就默认其中一个 ROA 会覆盖另一个。

切换 Origin ASN 时，建议：

1. 提前创建新 ASN 的 ROA；
2. 等待公开验证器显示授权；
3. 再开始 BGP 切换；
4. 确认旧路由完全撤回；
5. 最后评估是否删除旧 ROA。

PA 前缀的 ROA 由谁创建

如果使用 Sponsoring LIR 提供的 PA IPv6，资源证书通常由该 LIR 控制。客户可以使用和宣告前缀，但一般不能直接在 RIPE NCC Portal 中管理 ROA。

这时应向 LIR 提供：

• 精确前缀；
• Origin ASN；
• 所需 maxLength；
• 计划生效时间；
• 是否存在多个 Origin；
• 变更原因。

申请服务时就应确认正常修改和紧急修改的处理流程。不要等路由 Invalid 后才第一次寻找负责 ROA 的联系人。

ROA 和 IRR route6 对象不是一回事

两者都包含前缀和 ASN，看起来很像，但用途不同。

项目	ROA	IRR route/route6
主要用途	RPKI 起源验证	描述路由意图、生成过滤器
是否有加密验证链	有	取决于数据库和维护者机制
常见使用方	ROV 验证器和运营商策略	上游、Peering、过滤自动化
能否相互替代	不能	不能

许多网络仍会同时检查 IRR 和 RPKI。因此，ROA 正确不代表上游一定放行，IRR 对象存在也不代表路由会显示 Valid。

IPv6 更具体前缀的实际限制

即使 ROA 允许宣告 /56 或 /64，全球很多网络仍会过滤长于 /48 的 IPv6 路由。

RPKI 回答“有没有授权”，运营商过滤回答“我接不接受”。两者不是同一个问题。

如果确实需要 IPv6 更具体前缀做流量工程：

• 先与所有上游确认过滤政策；
• 不要只依赖单一 Looking Glass；
• 不要为了方便把 maxLength 一次放到 /64；
• 准备聚合 /48 作为稳定路由；
• 上线后持续观察不同地区的可见性。

创建 ROA 的正确顺序

1. 列出实际路由

不要先进入门户随手填写。先从路由器配置、设计文档和上游工单中整理：

Prefix	Origin ASN	实际宣告长度	用途

2. 确认资源管理权限

确认由公司自己、Sponsoring LIR 还是上游创建 ROA。

3. 采用最小必要授权

maxLength 只覆盖真实使用的前缀，不为“以后可能用”预先放宽。

4. 发布后独立验证

至少使用两个公开数据源查看结果，避免只看资源门户中的“创建成功”。

5. 再调整 BGP

确认 ROA 已传播后再修改 Origin ASN 或新增更具体路由。

路由 Invalid 时怎么排查

按照这个顺序检查：

1. 实际 Origin ASN 是多少；
2. ROA 授权的是哪个 ASN；
3. 实际路由长度是多少；
4. maxLength 是多少；
5. 是否存在另一条覆盖范围更大的 ROA；
6. 是否刚做过资源转移或 Sponsor 变更；
7. 验证器数据是否已经刷新；
8. 上游看到的路由是否与本地配置一致。

“ROA 有问题”和“路由与 ROA 不匹配”不是一回事。一条签名和格式都正确的 ROA，也可能因为内容与实际路由不一致而让路由变成 Invalid。

上线检查清单

• 每个准备宣告的前缀都有对应授权；
• Origin ASN 与路由器实际配置一致；
• maxLength 没有过度放宽；
• 多 Origin 场景为每个 ASN 单独授权；
• IRR 对象符合上游要求；
• 上游已经更新 Prefix Filter；
• 公开验证器显示预期状态；
• 多个 Looking Glass 能看到正确 Origin；
• 已记录 ROA 管理人和紧急变更流程。

常见问题

maxLength 留空可以吗？

可以，而且在只授权完整前缀时应优先留空。按照现行 RFC 9582，省略 maxLength 就表示最长长度等于 Prefix 本身：/48 只授权 /48，/24 只授权 /24。如果 maxLength 与 Prefix 长度相同，不应重复编码这个字段。

不同门户可能显示为“留空”“Exact Prefix”或自动带出相同长度，但最终语义应一致。只有确实需要授权更具体前缀时，才设置更大的 maxLength；更稳妥的做法通常是为真实使用的更具体前缀创建单独、精确的 ROA。

一个 ROA 可以授权多个 ASN 吗？

一条 ROA 中的 Origin ASN 是一个具体 ASN。多个 Origin 通常需要分别建立授权。

ROA Valid 后多久全球生效？

没有统一的瞬时生效时间。资料库发布、验证器抓取和运营商缓存刷新都需要时间。

删除错误 ROA 是否会立刻修复路由？

不会保证立刻。还要等待数据同步，并确认不存在其他冲突授权。

小结

ROA 的作用很窄，却非常关键：明确哪一个 ASN 可以起源哪一段地址，以及允许宣告到什么长度。

最可靠的做法不是追求“一条 ROA 覆盖所有情况”，而是按照真实路由建立尽可能精确的授权，并把 ROA 变更放在 BGP 变更之前。

参考资料

• RIPE NCC：Hosted RPKI 与 ROA 管理
• RFC 9582：ROA 格式与 maxLength 语义
• RFC 9319：RPKI 中 maxLength 的使用建议

继续阅读

• 什么是 RPKI？它如何降低错误路由和劫持风险
• IPv6 /48 怎么选？PA、PI 和运营商地址的区别
• 如何申请自己的 ASN？条件、材料和完整流程