SKNK 中文技术指南
什么是 IRR Route Object？route、route6、RPKI 和 ROA 怎么配合
解释 IRR、RPSL、route、route6、aut-num 与 AS-SET 的作用，以及 IRR 和 RPKI 为什么不能互相替代，如何避免上游过滤错误。
技术内容
由 Shikanoko Networks 编写与维护
IRR Route Object 是公开登记的路由意图：它说明某个 IP 前缀计划由哪个 ASN 在 BGP 中起源。IPv4 使用 route 对象，IPv6 使用 route6 对象。很多上游和 Peer 会根据这些记录生成前缀过滤器，因此对象缺失或内容错误时，BGP Session 可能正常建立，路由却不会被接受。
IRR 与 RPKI 经常被写在同一张上线清单里，但两者不是同一个系统，也不能互相替代。
IRR 登记公开的路由意图，ROA 提供地址持有方的加密授权；两边都要与真实公告一致。
IRR 是什么
IRR（Internet Routing Registry）是一组由不同机构运营的互联网路由登记数据库。网络运营者使用 RPSL 形式公开描述：
- 哪个 ASN 起源哪些前缀；
- 一个 ASN 对外声明的 Import 和 Export Policy；
- 一个 AS-SET 包含哪些 ASN；
- 一个 Route-set 包含哪些前缀；
- 谁可以维护这些记录。
RIPE Database 中包含 RIPE Routing Registry。其他运营机构也维护自己的 IRR 数据源。上游采用哪个数据源、是否合并多个 IRR，以及是否额外使用 RPKI 数据，由它自己的过滤政策决定。
Route Object 记录什么
一个简化的 IPv4 route 对象：
route: 192.0.2.0/24
origin: AS64496
mnt-by: EXAMPLE-MNT
source: RIPE
一个简化的 IPv6 route6 对象：
route6: 2001:db8:1200::/48
origin: AS64496
mnt-by: EXAMPLE-MNT
source: RIPE
这里使用的地址和 ASN 都来自文档保留范围。
最关键的是前两项：
route或route6：被登记的前缀；origin：计划起源该前缀的 ASN。
在 RIPE Database 中，前缀与 Origin ASN 共同构成 route 或 route6 对象的组合主键。因此，同一个前缀在特殊场景下可以存在多个不同 Origin 的对象，但每一组前缀与 Origin 组合是独立记录。
为什么上游要检查 IRR
如果一个客户告诉上游“我要发布 2001:db8:1200::/48”，上游不能只靠邮件内容决定是否接受。
常见自动化流程是：
- 从客户 ASN 或 AS-SET 开始；
- 查询受信任 IRR 数据；
- 找到与客户相关的
route和route6对象； - 生成允许的前缀清单；
- 把清单下发到边界路由器；
- 拒绝清单之外的客户公告。
这种做法可以减少客户误发其他前缀或完整路由表的风险。
但 IRR 数据质量并不完全一致。不同 IRR 的认证方式、历史数据和清理政策不同，上游可能只信任特定来源，也可能用 RPKI 对 IRR 结果进一步筛选。
RPSL 是什么
RPSL（Routing Policy Specification Language）是描述路由策略的语言。RIPE Database 中的 aut-num、route、route6、as-set 等对象都使用 RPSL 或其扩展形式。
常见属性包括：
import：从某个邻接关系接收什么；export：向某个邻接关系发布什么；mp-import、mp-export：用于多协议地址族；members：集合的直接成员；mbrs-by-ref：按维护者引用成员；mnt-by、mnt-routes：维护和路由对象创建权限。
RPSL 可以表达复杂策略，但现实中并不是每个网络都完整、及时地维护所有策略属性。运维时应把它当作公开路由登记和自动过滤数据的一部分，而不是把数据库文本当成路由器当前配置的绝对镜像。
route 和 route6 有什么区别
两者作用相同，地址族不同：
| 对象 | 地址族 | 示例 |
|---|---|---|
route |
IPv4 | 192.0.2.0/24 |
route6 |
IPv6 | 2001:db8:1200::/48 |
不能用 IPv4 route 对象代表 IPv6 前缀，也不能只维护其中一类就期待另一类自动生成。
如果网络同时发布 IPv4 和 IPv6，应分别核对两种对象。
aut-num 对象做什么
aut-num 对象代表一个自治系统的登记和路由策略信息。它可能包含：
- ASN；
- 组织与联系信息；
- Import 和 Export Policy；
- Peering 关系；
- 维护者；
- 状态和更新时间。
ASN 获批后，aut-num 对象通常由相应注册体系建立。网络运营者需要确认联系信息和可维护字段符合实际，并在上游关系变化后更新公开策略。
aut-num 不是 BGP 配置文件。路由器不会因为数据库里写了 export 就自动建立 Session，除非运营者另外部署了读取 RPSL 并生成配置的自动化系统。
AS-SET 为什么重要
如果一个网络只发布自己的少量前缀，上游可以直接根据 Origin ASN 建立过滤器。
如果它还有多个下游客户，逐个告诉所有上游“这些客户 ASN 也属于我的客户锥”会很难维护。这时可以用 AS-SET 表示一组 ASN。
简化示例：
as-set: AS64496:AS-CUSTOMERS
members: AS64496, AS64497, AS64498
mnt-by: EXAMPLE-MNT
source: RIPE
上游可以展开该集合，再查询成员 ASN 对应的路由对象。
需要注意：
- AS-SET 名称应明确归属，避免与其他 IRR 中同名对象混淆；
- 成员必须及时维护；
- 不应把不再是客户的 ASN 长期留在集合中；
- 递归集合可能膨胀，必须设置合理的展开限制；
- 对方是否接受某个 AS-SET，取决于它的 IRR 政策。
IRR 和 RPKI 分别回答什么
可以用一张表区分：
| 问题 | IRR Route Object | RPKI ROA |
|---|---|---|
| 主要表达 | 公开路由意图和策略登记 | 地址持有方对 Origin 的加密授权 |
| 核心字段 | Prefix + Origin ASN | Prefix + Origin ASN + maxLength |
| 信任基础 | IRR 运营方与对象认证机制 | RIR 资源证书体系 |
| 常见用途 | 生成前缀和 AS_PATH 过滤器 | Route Origin Validation |
| 能否验证完整 AS_PATH | 可用于构建策略数据，但不提供完整加密路径证明 | 不能，只验证 Origin |
| 两者是否自动同步 | 否 | 否 |
RIPE Database 的要求文档明确指出，Route Origin 信息可以同时存在于 RIPE Routing Registry 和 RPKI Database，但两套数据库之间没有直接关联。
这意味着：
- 在 RIPE
source: RIPE中创建 ROA，不会替你建立可维护的route6对象； - 一些查询服务或运营商会把 ROA 转换成派生的 IRR 记录，但这不等于原始 IRR 对象已经创建；
- 新建
route6不会自动创建 ROA； - 删除其中一个，也不能假定另一个会同步删除；
- 两边不一致时，上游可能得到不同判断。
四种常见状态
假设网络准备发布：
2001:db8:1200::/48
Origin AS64496
IRR 正确，ROA 正确
这是最理想的状态。上游 IRR 过滤和 RPKI Origin Validation 都有一致依据。
IRR 正确，没有 ROA
上游可能允许该前缀通过 IRR 过滤，但 RPKI 状态通常是 NotFound。不同网络可以采用不同处理策略。
IRR 正确，ROA 不匹配
路由可能通过 IRR 过滤，但 RPKI 状态为 Invalid，例如 ROA 写成另一个 ASN，或者 maxLength 不允许实际公告长度。执行严格 ROV 的网络可能拒绝该路由。
ROA 正确，没有 IRR
路由在 RPKI 中可以是 Valid，但依赖 IRR 白名单的上游仍可能拒绝，因为它的客户过滤器里没有该前缀。
因此，实际操作不是“IRR 和 RPKI 二选一”，而是让两边与真实 BGP 公告保持一致。
谁负责创建 Route Object
这取决于地址资源的维护关系，而不只取决于谁拥有 ASN。
route 或 route6 关联的是地址前缀和 Origin ASN。创建时通常需要通过地址对象、维护者或 mnt-routes 相关的认证规则。
常见情况：
- 自己持有并维护 PI 地址：由资源持有方按权限建立；
- 使用上游 PA 地址：由地址持有方或其授权维护者处理；
- 使用 LIR 管理的 PA 前缀：由 LIR 按合同和实际 Origin 协助建立；
- 地址来自另一个 RIR：需要使用对应 RIR 或上游接受的 IRR 体系，不能假设 RIPE Database 会接受所有外部资源的新路由对象。
ASN 属于你，并不自动意味着你有权为任意地址前缀创建 Route Object。
创建前需要准备什么
- 精确的 Prefix；
- 实际 Origin ASN；
- 地址对象所在数据库；
- 地址资源的维护者关系；
- 上游信任哪些 IRR 来源；
- 是否需要 AS-SET；
- 对应 ROA 是否已存在；
- 实际计划发布的最具体前缀长度。
如果这些问题没有确定，不要先创建多个“试试看”的对象。错误记录可能进入运营商缓存或自动化系统，清理比创建更麻烦。
怎么检查现有对象
可以使用 RIPE Database Web UI、REST API 或 Whois 查询。
检查时不要只搜索 ASN，还应分别搜索：
- 精确前缀；
- Origin ASN；
- 前缀与 Origin 组合；
- 更具体和更宽泛的覆盖对象；
- AS-SET 展开结果；
last-modified；mnt-by和mnt-routes。
还要确认上游实际采用的是哪个 IRR 数据集。你在某个公开数据库里看到了对象，不代表每个运营商都会信任和导入它。
Route Object 更新后的生效时间
IRR 数据库中的对象更新后，上游过滤器未必立即刷新。
可能经过：
- IRR 数据同步；
- 上游自动化任务读取；
- 前缀清单生成；
- 配置审核；
- 路由器策略下发。
因此，上线变更应提前协调，不要在维护窗口开始后才临时创建对象，也不要在几分钟内重复删除、重建。
常见错误
Prefix 写错
把 /48 写成 /44，或者输入了内部使用的 /64，都可能导致过滤器和真实公告不一致。
Origin ASN 写成上游 ASN
Origin 应是实际起源前缀的 ASN，不是路径中第一个上游。
只建 IRR，不建 ROA
IRR 记录不能提供 RPKI 加密授权。
只建 ROA，不建 IRR
使用 IRR 白名单的上游仍可能拒绝路由。
更换上游后完全不检查对象
即使 Prefix 与 Origin 不变，aut-num 策略、AS-SET、联系人和上游侧过滤登记仍可能需要更新。
删除前缀后留下旧对象
陈旧记录会误导其他运营商，也可能扩大错误过滤清单。停止发布或退出资源时，应明确由谁清理 IRR 与 ROA。
上线检查清单
- Prefix 与真实公告完全一致
- Origin ASN 正确
- IPv4 使用
route，IPv6 使用route6 - 对象位于上游采信的 IRR
- 维护者和联系人有效
- AS-SET 成员准确
- ROA Prefix、Origin 和
maxLength一致 - 上游已刷新过滤器
- 外部 Looking Glass 能看到正确 Origin
- 停用和迁移时有清理负责人
常见问题
有了 ROA，还必须有 Route Object 吗
协议层面不是同一项强制要求，但很多上游仍依据 IRR 生成客户过滤器。是否必须由你的上游政策决定。实际部署中应在上线前同时核对两者。
Route Object 能防止 BGP 劫持吗
它可以帮助运营商建立过滤器，但本身不是加密授权。安全效果取决于对象认证、数据质量和运营商是否使用。ROA 和 ROV 提供的是另一层 Origin 授权验证。
一个前缀可以有两个 Origin ASN 吗
某些 Anycast、迁移或多 Origin 场景可能需要多个授权组合。每个 Prefix 与 Origin 组合需要分别评估 IRR 对象和 ROA，不能简单复制配置。
IRR 对象会自动配置我的上游吗
不会。上游可能有自动化系统读取，也可能需要工单和人工审核。应直接确认。
PA 前缀的对象能由客户自己修改吗
取决于地址对象和维护者权限。使用 LIR 或上游 PA 地址时，通常需要地址持有方或其授权维护者操作。
小结
IRR Route Object 解决的是“公开登记这条前缀计划由谁起源”，ROA 解决的是“地址持有方是否以加密方式授权这个 Origin”。两者都要与真实 BGP 公告一致。
最稳妥的检查方法不是问“我有没有 IRR 或 RPKI”，而是同时核对：
Prefix、Origin ASN、公告长度、维护权限和上游过滤器，是否都指向同一个真实网络方案。
参考资料
- RIPE Database：route6 对象与完整文档
- RIPE NCC：Requirements for the RIPE Database（RIPE-767）
- RIPE NCC：Routing Policy Specification Language
- RFC 2622：Routing Policy Specification Language
- RFC 4012：RPSL Extensions for IPv6