SKNK 中文技术指南
如何通过 BGP 宣告 IPv6 /48？ROA、IRR 与上游核对清单
拿到 IPv6 /48 不等于全网可达。宣告前要确认资源归属、上游接受条件、ROA 与 IRR 记录、本地路由和 BGP 会话，最后从多个视角验证可见性。
技术内容
由 Shikanoko Networks 编写与维护
一个 IPv6 /48 被分配给你，不代表它就全网可达。要通过 BGP 宣告它，你需要：一个 ASN、一个你被授权使用的前缀、一条支持 IPv6 的上游、一台路由表里有这个前缀的路由器，以及匹配的路由登记记录。然后还要验证别的网络到底能不能看到它。
宣告一个 IPv6 /48——通过 eBGP 会话把你的前缀发布给上游，让互联网上的其他网络知道"这段地址空间从这里可达"。宣告成功 = 资源、授权、BGP 策略、上游路径四件事全部对齐。
本文走一遍完整的宣告流程：确认资源 → 准备上游 → 建 RPKI 和 IRR 记录 → 建立 eBGP → 导出前缀 → 从多个视角检查结果。示例使用文档保留前缀 2001:db8:1234::/48 和文档保留 ASN AS64496、AS64497（RFC 5398），不是真实资源，绝不能上公网。
分配到的前缀只有在资源、授权、BGP 策略和上游路径对齐后，才会成为公共路由。
一句话答案
按顺序确认七件事：
- ASN 和 IPv6 前缀已分配给你、或被授权使用
- 上游接受客户 IPv6 BGP 宣告
- 为前缀和将要宣告它的 ASN 创建匹配的 RPKI ROA
- 如果上游或对端用 IRR 过滤，创建 IRR
route6对象 - 确保 /48 出现在路由器本地路由表里
- 建立 eBGP 会话，只导出意图宣告的前缀
- 检查本地路由、上游接受情况、RPKI 状态、IRR 对象和公网可见性
BGP 会话 Established 不代表 /48 正在被宣告。路由还可能被你的路由器宣告出去、却被上游的过滤器拒绝。这是两个独立的检查。
"宣告 /48"有七种状态
| 状态 | 含义 |
|---|---|
| /48 已分配 | 存在一个地址资源，注明用途 |
| /48 在本地 RIB | 你的路由器有一条指向该前缀的活动路由 |
| BGP 会话 Established | 你的路由器和上游能交换 BGP 消息 |
| 前缀已导出 | 你的路由器已把路由发给上游 |
| 上游已接受 | 上游通过了自身的过滤器并装入路由表 |
| 公网可见 | 其他网络或路由采集点能看到宣告 |
| RPKI Valid | 路由与已发布的起源授权匹配 |
这些状态不会自动互相产生。前缀可以已分配但没在跑；会话可以 Established 但没导出前缀；RPKI Valid 的路由也可能被上游或对端的过滤器拦下、可见性有限。
开始前要确认什么
| 要素 | 为什么重要 | 要确认什么 |
|---|---|---|
| ASN | 标识宣告路由的网络 | 哪个 ASN 会出现在公网 origin |
| IPv6 前缀 | 定义要宣告的地址空间 | 前缀长度、资源持有者、允许的用途 |
| IPv6 上游 | 提供到达其他网络的路径 | BGP 支持、过滤策略、运营联系人 |
| BGP 路由器 | 建会话、发更新 | IPv6 可达性、导出策略支持 |
| RPKI 权限 | 授权起源 ASN 和前缀长度 | 谁能创建或修改 ROA |
| IRR 权限 | 在需要的地方登记路由对象 | 谁能创建或维护 route6 对象 |
| 验证工具 | 查看路由器之外的可见性 | 本地 BGP 状态、RPKI、IRR、公网采集点 |
动手配置之前，先确定资源持有者和实际起源 ASN。同一个前缀、起源 ASN、前缀长度，必须在资源记录、ROA、IRR 对象、BGP 策略和上游申请里保持一致。
现行 ASN 政策（2026 年 8 月核对）
政策状态核对日期：2026 年 8 月 2 日。
现行已发布的 RIPE-679 ASN 分配政策 要求：网络必须多宿主（Multihomed）才有资格申请 ASN，且申请必须描述自治系统新的外部路由策略。
2026 年 7 月 7 日，RIPE 社区发布了 2026-01 "简化首个 ASN 分配"提案。该提案在特定情况下（持有 RIPE NCC 直接分配前缀的持有人）可能取消首个 ASN 的需求论证，但页面当前标注为讨论阶段。它不是现行政策。
现在申请 ASN，按现行政策和 RIPE NCC 或你的 Sponsoring LIR 要求的材料办。不要把开放提案当成已生效的政策。
第一步：确认前缀和起源 ASN
把前缀和将要宣告它的 ASN 的关系写死：
前缀： 2001:db8:1234::/48
起源 ASN： AS64496
下面这些值应该描述同一条公网路由：
- 分配给你或被授权使用的 IPv6 前缀
- BGP 里配置的起源 ASN
- ROA 里的 Origin ASN
- IRR
route6对象的origin:值 - 上游过滤器允许的前缀
这些值不一致时，结果取决于在哪一层：上游可能因为 IRR 或手动过滤器拒绝路由；路由可能因为起源 ASN 或前缀长度与覆盖 ROA 不匹配而变成 RPKI Invalid。
还在纠结资源怎么申请？读 如何申请自己的 ASN 和 如何获得 IPv6 /48。
PA 和 PI 不是一回事
PA（服务商聚合地址）和 PI（独立地址）的登记关系和运营关系不同。
PA 空间属于某家 LIR 的分配，其使用、可携带性、RPKI 流程和生命周期取决于资源持有者和适用协议。PA 默认不能被描述为可携带。
PI 空间分配给终端用户组织，在 RIPE NCC 服务区通过 Sponsoring LIR 申请。RIPE NCC 文档把 /48 列为 IPv6 PI 分配的最小规模。当前申请路径见 RIPE NCC：How to Request an IPv6 PI Assignment。
SKNK 的 IPv6 PA /48 服务：前缀来自 SKNK 的 PA 分配，SKNK 控制并维护该资源的 RPKI ROA；客户选择上游并自己运行 BGP 配置。Sponsoring LIR 服务不包含 BGP 配置、Transit、IRR 管理、DNS 管理和 7×24 路由运维。服务边界以 资源生命周期页面 为准。
第二步：确认上游接受这条路由
你需要一个能建 IPv6 eBGP 会话、并且愿意接受你前缀的上游。让上游确认这些参数：
| 参数 | 示例 |
|---|---|
| 你的 ASN | AS64496 |
| 上游 ASN | AS64497 |
| 你的 BGP 邻居地址 | 2001:db8:ffff::2 |
| 上游邻居地址 | 2001:db8:ffff::1 |
| 要宣告的前缀 | 2001:db8:1234::/48 |
| 认证方式 | 是否需要 TCP MD5 或其他方法 |
| 前缀上限 | 会话上允许的最大路由数 |
| IRR 要求 | 是否需要 route6 对象 |
| RPKI 要求 | 路由必须 Valid，还是只要不是 Invalid |
| 运营联系人 | 服务的 NOC 或路由联系人 |
还要确认：服务或隧道上是否启用 IPv6；会话用直连地址还是多跳；是否要求 LOA 或其他授权文件；提供哪些 BGP Community；接受哪些 IPv6 前缀长度。
Transit、Peering、IXP 和隧道连接不可互换。选上游关系之前，先读 Transit 与 Peering。
BGP 会话只是路由器和上游之间的运输通道；会话正常，并不等于每条路由都已宣告。
第三步：创建匹配的 ROA
ROA（路由起源授权）是一个签名的 RPKI 对象，声明哪个 ASN 有权宣告一个前缀、允许宣告多具体。RIPE NCC 的 BGP 起源验证文档 说明了 ROA 与路由验证的关系。
只宣告聚合 /48 的设计，一个示例 ROA：
前缀： 2001:db8:1234::/48
起源 ASN： AS64496
maxLength： /48
你只打算宣告 /48 的话，maxLength 保持 /48 就是最窄的匹配授权。不要为了"以后可能用到更具体的路由"而放宽 maxLength——更宽的值会授权更具体的宣告。
以后要宣告 /52 或 /56：先和资源持有者及每个相关上游确认路由设计，在改 BGP 策略之前，同步更新 ROA 和 IRR 对象。
RPKI 验证状态定义见 RFC 6811：
| 状态 | 含义 |
|---|---|
| Valid | 存在覆盖 ROA，授权了该起源 ASN 和前缀长度 |
| Invalid | 存在覆盖 ROA，但 ASN 或前缀长度不匹配 |
| NotFound | 验证器看不到覆盖 ROA |
ROA 里的 Origin ASN 必须是公网 BGP 路由里实际出现的起源 ASN。如果上游用自己的 ASN 宣告你的前缀，只授权你的 ASN 不会匹配那条路由。
ROA 不会创建 BGP 会话、不会往路由器加路由、也不会逼上游接受前缀。它只是为做 RPKI 验证的网络提供起源授权数据。单独的 ROA 解释，读 什么是 ROA？。
第四步：创建 IRR route6 对象
IRR 和 RPKI 描述的是不同种类的路由信息：
- ROA 是密码学签名的起源授权
route6对象在互联网路由注册库里登记 IPv6 路由意图- 上游可能用 IRR 数据生成或更新前缀过滤器
- 上游也可能用 RPKI 数据验证路由起源
一个简化的 route6 对象：
route6: 2001:db8:1234::/48
descr: 示例 IPv6 聚合前缀
origin: AS64496
mnt-by: YOUR-MAINTAINER
这是示例模板，不是直接复制的对象。正确的 maintainer 和授权路径取决于数据库源和资源持有者。RIPE Database 文档把 route6 描述为互联网上宣告的 IPv6 路由，见 RIPE Database route6 文档。
记录应该描述同一条意图路由：
route6 前缀 = BGP 前缀
route6 origin = BGP 起源 ASN
ROA 前缀 = BGP 前缀
ROA origin = BGP 起源 ASN
上游用 IRR 过滤时，正确的 ROA 替代不了 IRR 对象；IRR 对象也提供不了 RPKI 的密码学起源验证。两者是不同系统。
ROA 和 IRR 描述的是同一条预期宣告的不同属性。
第五步：把 /48 放进本地路由表
BGP 一般只导出本地路由表里存在的路由。前缀在 IRR 里登记过、被 RPKI 授权了，都不会自动在路由器上生成可用路由。
建会话之前，确认 /48 在本地 RIB 里且处于活动状态。路由可以来自：环回或服务接口、被路由的服务器网络、覆盖内部子网的聚合、指向内部路由器的静态路由，或者"丢弃路由 + 单独路由更具体前缀"的刻意聚合设计。
最后一种要小心：丢弃路由能保住聚合在 RIB 里的存在，但如果底层更具体的路由不可用，它会把流量黑洞。只能作为有文档记录的路由设计的一部分使用。
不要因为 RIPE Database 里有个对象就宣告前缀。前缀必须被授权给你使用，并且在你网络里被刻意路由。规划 /48、/56、/64 边界用 IPv6 子网计算器，但子网规划和 BGP 宣告是两件事，分开做。
第六步：建立 eBGP，只导出意图前缀
按和上游约定的值配置 eBGP 会话：本地 ASN、远端 ASN、本地和远端 IPv6 邻居地址、IPv6 地址族激活、需要的认证、直连或多跳传输设置，以及一条限定在授权前缀内的导出策略。
导出策略应该是一条窄规则：
如果路由是活动的
并且前缀是授权前缀
那么导出到目标上游
否则拒绝
这是策略描述，不是路由器语法。BIRD、FRRouting、Junos、IOS-XR 等平台的配置格式不同，用你实际运营平台的文档。
不要一开始就用"导出本地表所有路由"的策略——宽策略会泄漏内部路由、学习路由、管理路由或默认路由。用多个上游时，每个会话单独配置、单独验证。同一个 /48 可以通过多个上游宣告，但资源持有者、上游合同、ROA 设计、过滤策略和流量工程计划都要支持这种安排。
更完整的申请后流程，读 拿到 ASN 之后。
第七步：四层验证
1. 本地路由器
确认：BGP 会话 Established、IPv6 地址族活动、/48 在本地 RIB、前缀出现在 advertised-routes 视图、导出策略没有拒绝这条路由。具体命令取决于平台。
2. 上游
让上游确认：两边会话都 Established、前缀已收到、通过了提供商过滤器、按服务策略在传播。
路由可能出现在本地 advertised-routes 视图里、却被上游当场拒绝。
3. RPKI 和 IRR
用 SKNK 的只读工具检查：RPKI 与 BGP 查询、IRR Route Object 查询、BGP 与 IRR 一致性审计。确认：前缀正确、起源 ASN 正确、预期 ROA 可见、路由 RPKI Valid（当意图路由被匹配 ROA 覆盖时）、route6 对象与前缀和起源匹配、没有过期 ROA 授权给其他起源、maxLength 覆盖实际宣告的路由。
4. 公网可见性
用多个独立的公网路由数据源，比如 RIPEstat、公共 Looking Glass 和路由采集点。不同采集点更新时间不同、看到的路径可能不同。一个阳性结果不是全网可达的证明，一个阴性结果可能是采集延迟或策略差异。
最后的问题不是"我的路由器发出去了吗"，而是：
独立的网络能看到这个前缀带着预期的起源 ASN 吗？路由被对目标用户重要的那些策略接受了吗？
本地已经发出的路由，还要通过上游接受、授权匹配和公网可见性检查。
常见排障
| 症状 | 大概率区域 | 查什么 |
|---|---|---|
| BGP 停在 Idle | 传输或邻居配置 | IPv6 可达性、TCP/179、防火墙、本地和远端 ASN |
| BGP 停在 Active | 对端地址、多跳或认证 | 对端地址、TTL、密码、提供商设置 |
| 会话 Established 但 /48 不出现 | 本地路由或导出策略 | 本地 RIB 和 advertised-routes 视图 |
| 上游拒绝前缀 | 提供商过滤器或缺少授权 | 精确前缀、IRR 对象、LOA、提供商策略 |
| 路由 RPKI Invalid | 起源 ASN 或前缀长度不匹配 | 实际公网起源、ROA、maxLength |
| 路由 RPKI NotFound | 看不到覆盖 ROA | ROA 是否存在、是否已发布、是否到达验证器 |
| 只在一个采集点可见 | 传播延迟或策略过滤 | 更多采集点、上游确认、前缀长度 |
| 路由存在但流量不通 | 数据面或回程问题 | 下一跳、内部路由、防火墙、服务绑定、回程路径 |
不要同时改 ROA、IRR 对象和 BGP 配置，除非你先记录旧状态——否则很难判断是哪个变更导致或修复了结果。排障时一层一层查：资源记录、路由策略、公网观测，一次一层。
资源记录、路由策略和公网观测分层检查，排障才不会把多个变量混在一起。
你需要自己的 ASN 和 IPv6 /48 吗
可能不需要，如果：你只用一家云或 Transit 提供商；提供商用自己的 ASN 宣告路由；你不需要自己的外部路由策略；你接受提供商的寻址和路由生命周期。
需要自己的 ASN 的场景：需要独立的路由身份、多个外部网络、或控制自己前缀的宣告方式。注意在 RIPE NCC 服务区，现行政策仍包含多宿主要求；前面提到的 2026 首个 ASN 提案还没有替代它。
申请路径评估，读 什么是多宿主？ 和 如何申请自己的 ASN。需要 ASN 和 IPv6 资源赞助而不是 BGP 配置服务，看当前 赞助 LIR 价格 和 资源生命周期。除非另有书面服务约定，客户负责选择上游并运营网络路由。
常见问题
没有 ROA 能宣告 IPv6 前缀吗
技术上可以。看不到覆盖 ROA 时，路由通常会被分类为 RPKI NotFound（部分文档写作 UNKNOWN）。但运营者可能偏好 Valid 路由，或对 NotFound 路由施加自己的策略，所以生产宣告建议配置匹配的 ROA。
ROA 能让我的路由全网可见吗
不能。ROA 授权起源 ASN 和前缀长度，不会创建 BGP 会话、不会把前缀加进路由器、也不会逼上游接受路由。
ROA 和 route6 对象都要吗
它们是不同系统。ROA 支撑 RPKI 起源验证，route6 对象在 IRR 登记路由意图。很多上游仍然用 IRR 数据做过滤器，另一些也用 RPKI，按每个上游的要求办。
能宣告 IPv6 /64 吗
BGP 协议可以承载 /64，但公网可达性取决于每个上游和对端的过滤策略。/64 通常是更大分配或指派内部的一个子网，不是可靠的全球宣告单位。围绕它设计服务之前，先确认上游接受的前缀长度。
一个 PA /48 能通过两个上游宣告吗
可能可以，但取决于 PA 资源持有者、Sponsoring LIR 协议和每个上游的路由策略。先确认谁控制 ROA、资源是否被授权通过两家提供商宣告。
IPv6 BGP 传播要多久
没有统一的传播时间。会话可能立刻 Established，但路由采集点和其他网络之后才更新。别依赖固定时间估算，从多个公网观测点检查路由。
小结
宣告 IPv6 /48 不是一个配置命令，而是五个层的对齐：
资源授权
↓
ROA 与 IRR 记录
↓
本地路由
↓
BGP 导出策略
↓
上游接受与公网可见性
前缀、起源 ASN、ROA、route6 对象、本地路由和 BGP 导出策略描述的如果是同一条宣告，排障会容易得多。上线前：本地验证、和上游确认、查 RPKI 和 IRR、从多个公网源观测。
参考资料
- RIPE-679：Autonomous System Number Assignment Policies
- 2026-01：Simplify assignment of first ASN（讨论阶段）
- RIPE NCC：BGP Origin Validation
- RIPE Database：route6 对象文档
- RFC 6811：BGP Prefix Origin Validation
- RFC 5398：Documentation ASN 保留
- RFC 7454：BGP Operations and Security
- RFC 9319：The Use of maxLength in RPKI