摘要

  • RFC 8950 允许 BGP 用 IPv6 下一跳发布 IPv4 与 VPN-IPv4 可达性。Capability code 5 只说明某个 NLRI AFI、NLRI SAFI、下一跳 AFI 三元组得到支持；它既不启用该地址族，也不证明下一跳可达。
  • 接收方依靠 next-hop length 判断下一跳类型。Route reflector 必须保留继承来的编码，不能把相应 NLRI 分发给未声明支持该编码的 client。
  • 可靠迁移要逐级证明：双方 OPEN、精确的 MP_REACH_NLRI、入站策略结果、IPv6 递归、选路、FIB 编程、邻接或封装，以及真实 IPv4 数据包。绿色 session 只是第一层证词。

凌晨 1:40，一个汇聚站点开始把传输核心迁到统一的 IPv6 underlay。客户仍然使用 IPv4，业务前缀也仍然是 IPv4；改变的是核心里指向出口的坐标。运营者希望减少每条传输链路上的两套地址、两套 IGP 状态与两套故障处理。

两台 route reflector 和大多数 client 已支持这种做法。一台新替换的 client 在 OPEN 中同时声明 IPv4 unicast 的 Multiprotocol 能力和 Extended Next Hop Encoding；另一台旧设备只声明前者。两条 BGP session 都进入 Established。

新 client 收到 IPv4 路由，BGP 也选中了它，显示的下一跳是一个 IPv6 地址。但数据包仍然失败，因为 resolver 到管理 VRF 中查找该地址，最后落到错误接口。旧 client 则根本不应收到这种编码：reflector 没有权替它把 IPv6 下一跳“翻译”成 IPv4。只看 session 的面板会显示两个健康邻居，只看 reflector 的面板会显示完整路由表；二者都没有回答服务是否可用。

这个场景是合成的，边界却来自规范本身。RFC 8950 没把 IPv4 和 IPv6 融成一种协议。它让一条路由同时携带两个类型明确、却彼此独立的陈述：目的地属于 IPv4；到达广告点的下一步由 IPv6 地址指示。

目的地与下一跳不是同一个事实

NLRI 回答“哪些目的地可达”。Next hop 回答“接收者为了使用这项可达性，应向哪个地址递归并转发”。两者经常属于同一地址族，久而久之，工具和人都容易把这种常见组合当成不可分割的规则。

MP-BGP 恰恰把这层结构暴露出来。MP_REACH_NLRI 中有 AFI、SAFI、下一跳长度、下一跳字节和 NLRI。RFC 4760 提供容器；早期 IPv4 与 VPN-IPv4 定义只给 IPv4 形态的下一跳留下位置。当运营者想保留 IPv4 服务、却不再在核心运行 IPv4 传输时，这个约束就成了障碍。

RFC 8950 扩充的是合法组合。AFI 1 仍表示 IPv4 NLRI；在指定 SAFI 中，next-hop AFI 可以是 2，也就是 IPv6。客户地址没有被转换，IPv4 的业务责任也没有消失。路由只是经由另一地址族寻找转发锚点。

这种设计的价值正在于克制。运营者可以只在一个域内、某组 peer 或某类业务中采用；另一方不采用，并不因此“不合规”。双方只是处于不同 compatibility set。标准给出可互操作的最小语法，不替本地网络做迁移决定。

同样要克制的是商业叙事。IPv6 underlay 可能减少核心的重复地址与运维状态，却不会自动消除 IPv4 需求、客户合同、地址资源价值、支持成本和故障责任。“IPv6-only core”描述的是传输层选择，不是整项服务已经不再依赖 IPv4。

六个字节只承诺一个精确组合

Extended Next Hop Encoding 在 IANA 中登记为 capability code 5。其 value 由一个或多个六字节三元组组成：NLRI AFI 两字节、NLRI SAFI 两字节、next-hop AFI 两字节。RFC 8950 关心的形式是 NLRI AFI 1、SAFI 1、2、4、128 或 129，以及 next-hop AFI 2。

三元组不能省略。支持 IPv4 unicast 配 IPv6 下一跳，不等于支持 labeled unicast、multicast 或 VPN-IPv4。相同产品的不同 release、line card 或 address family 也可能覆盖不同子集。把所有信息压成一个 extended-nexthop=true，就抹掉了真正协商的对象。

Capability code 5 也不是 Multiprotocol capability 的替代品。前者只说明：在已经获准交换的某个 AFI/SAFI 上，接收方理解哪种 next-hop encoding。后者才决定该 AFI/SAFI 能否在邻居之间使用。

因此，OPEN 阶段至少要核对两列：双方是否协商了相关 MP-BGP family？接收方是否声明了精确的 extended-next-hop 三元组？BGP session 可以 Established，但其中任何一项仍可能缺失。发送方只有确认第二项后，才可向该 peer 发送携带 IPv6 下一跳的 IPv4 NLRI。

这正符合 Heng Lu 的 Minimum Initial Specification：共同层只有稳定 code、确定三元组和本地可验证结果。它不设中央迁移许可者。缺少三元组时，本地 speaker 不向该邻居发送这种编码；承担风险的边界自己决定兼容性。

管理系统也应保留这种精度。库存至少包括 BGP instance、两端地址、软件与硬件版本、session epoch、双方的 AFI/SAFI，以及收到和发出的每个 capability 5 三元组。“设备支持 RFC 8950”只是采购资料，不是正在运行的 session 事实。

长度是类型的一部分

对 AFI 1、SAFI 1、2 或 4，IPv6 下一跳长度为 16 或 32 字节。16 字节携带一个 IPv6 地址；32 字节可以按 RFC 2545 的构造携带 global 地址，后接 link-local 地址。

对 SAFI 128 或 129 的 VPN-IPv4，IPv6 形态占 24 或 48 字节。每个地址都按 VPN-IPv6 next hop 表示，前置的八字节 RD 设为零。RFC 8950 调整了 RFC 5549 的旧 VPN 编码，使规范与已部署、可互通的实现一致，并处理已记录的 erratum。

接收方必须在 AFI/SAFI 允许的集合内，根据 length 判断下一跳属于哪个网络层协议。Length 不是 UI 可以随手丢弃的展示字段，而是类型系统的一部分。解析器、telemetry exporter 或 policy engine 若把所有字节归一成一个无类型字符串，后续就无法证明它按正确语义处理了路由。

Global 与 link-local 地址的权威也不同。Global 地址可经 routing table 递归；link-local 地址只有结合 interface 和本地链路才有意义。两个接口上的 fe80::1 不是同一个全局下一跳。只保存地址、不保存 peer、interface 与 VRF 的证据，可能把两个独立对象错误地拼成一条历史。

在 unnumbered 或 link-local eBGP 中，这一点尤其尖锐。BGP transport 可以正常，某些实现也可能自动打开相关 capability，但 FIB 仍需一个带 interface scope 的 adjacency。设备重启、接口替换或 peer-group 继承可以保留地址文本，却改变让它真正可用的上下文。

VPN 形式再增加一层 scope。Next-hop encoding 里的零 RD 不会消除 NLRI 自身的 service RD 与 route target。把屏幕上的零解释成“租户上下文已经消失”，就是把 next-hop 表示和 VPN route identity 混为一谈。

Reflector 是转述者，不是翻译器

Route reflection 暴露了最容易被忽略的兼容边界。Reflector 若原样传递下一跳，就必须保留收到的 encoding。某 client 无法处理这种 encoding 时，相应 NLRI 不能分发给它。

这条规则阻止 reflector 静默创造新的转发点。把 IPv6 next hop 换成 IPv4 地址并非格式整理，而是把递归与转发权威交给另一个地址，可能引入新的路径、policy 与 failure domain。

后果会扩散到拓扑层面：只要某个 client 能生成其他 client 需要经共同 reflector 接收的编码，相关 client 集合就可能都要支持它。一台升级后的边缘设备可以暴露另一台设备的能力缺口，而 reflector 自身完全没有故障。

这种“有意不发送”很容易被误判。旧 client 仍 Established，也可能继续收到采用 IPv4 next hop 的其他 IPv4 路由；reflector 自己仍保有那条被扣留的路由。简单的 prefix-count alarm 只会看到差异，看不到差异是由 client 的 capability 声明决定的。

正确证据要在同一 session epoch 连接四个视图：起源 client 的 UPDATE、reflector 接受后的路由、目标 client 的 OPEN capability、reflector 对它的 Adj-RIB-Out。缺少路由时，事件应写明 encoding unsupported for client，而不是笼统的“prefix missing”。

Route server、confederation 或显式 next-hop-self 会产生不同权责，必须单独测试。关键不是宣称下一跳永远不能改变，而是不能把 unchanged reflection 说成自动翻译；主动改写就必须作为一项新的本地路由决定接受审计。

递归才是语法接上现实的地方

接收方解析并接受 UPDATE 后，还要解析 IPv6 next hop。Resolver 选择 routing table 或 VRF，查找通往该地址的路由，继续必要递归，绑定 adjacency 或 tunnel，再把结果交给 FIB。

每一步都可独立失败。IPv6 地址可能不在 IGP 中；它可能只存在于 global table，而 BGP instance 使用 service table；递归链自身可能未解析；neighbor discovery、label、SID 或 tunnel 状态可能缺失；小型控制包可以通过，但封装后的业务包超过 MTU；control plane 正确时，line card 仍可能尚未完成编程。

所以证据必须分层：

  1. Peer 声明 MP-BGP family。
  2. Peer 声明正确的 extended-next-hop tuple。
  3. Sender 发出预期的 MP_REACH_NLRI。
  4. Receiver 正确解析 next-hop 类型。
  5. Import policy 接受路由。
  6. Decision process 选中或保留它。
  7. IPv6 next hop 在预期上下文完成递归。
  8. FIB 把 IPv4 destination 指向预期 adjacency 或 tunnel。
  9. IPv4 数据包到达并能返回。

任何一层都不能替下一层作证。“BGP 里有路由”对跨地址族设计而言过于粗糙。监控系统可以汇总，但必须保留每次跃迁究竟由谁、在何时、以什么 observation 证明。

Rollback 也要同样具体。恢复 IPv4 next hop 可能需要恢复旧 underlay、原来的 next-hop-self、旧 peer capability 和 advertisement 顺序。只关闭 code 5、却没有恢复旧 resolver path，会把语法上的回退变成更长的业务中断。

安全控制面也跨入 IPv6

RFC 8950 不认证路由。受保护的 TCP session 仍可携带未经授权的 UPDATE。RPKI origin validation 可以判断某 origin AS 是否获准起源一个 IPv4 prefix，却无法证明 IPv6 next hop 安全或可达。

旧工具还可能隐含“IPv4 route 必有 IPv4 next hop”。只盘点 IPv4 下一跳的 policy 将漏掉新对象；ACL 可能允许 BGP session，却没有覆盖 IPv6 underlay；检测系统可能只在 destination 与 next hop 同族时识别 diversion。

RFC 8950 明确指出，IPv6 next hop 增加了一条可经中间 IPv6 基础设施转移流量的路径，可能造成 hijacking 或 denial of service。它还提醒运营者注意不常见但允许出现的 IPv4-mapped IPv6 地址，安全检查不能把这种值当作普通 global IPv6 处理。

合理做法不是把跨地址族 route 一律判恶，而是扩充授权对象：哪些 peer 可为哪些 service family 发布 IPv6 next hop；允许哪些 prefix 或 scope；哪些 resolver table、tunnel 与 underlay 可满足它；哪些 IPv4 destination 可以依赖这条路径。

Transport authentication、GTSM、prefix policy、RPKI、next-hop authorization、underlay security 和 packet validation 仍是不同控制。联合判断有价值，混淆含义没有。

Canary 必须走完两个地址族

启用 capability 前，先选择一个受限 IPv4 prefix 和预期 IPv6 next hop，记录现有 route、FIB、packet path、peer 与 resolver context，并列出传播路径上每台 speaker 应声明的 capability tuple。

建立新的 BGP session epoch 后，抓取双方 OPEN，分别核对 Multiprotocol 与 code 5。不要根据本地 config 猜测远端已经收到；使用 wire 或远端 readback。

随后检查 UPDATE：AFI 1、正确 SAFI、预期的 16/32 或 24/48 length、精确 IPv6 字节和未改变的 NLRI。涉及 reflector 时，证明它是否保持 next hop，以及每个目标 client 是否声明支持。

在每个接收节点保存 pre-policy、post-policy、selected path、recursive lookup、output table、adjacency/tunnel 与 FIB。IPv4 prefix 必须指向预测的 IPv6 path，而不只是碰巧找到某条 default route。

最后发送真实 IPv4 traffic，记录 source、destination、方向、返回路径、包长与 route epoch。若架构涉及封装与 MTU，ping 只能是一条信号，不能替代代表性业务包。

撤销 canary 后，还要证明 downstream Adj-RIB-Out、RIB、递归与 FIB 都完成清理，并演练旧 encoding 的恢复。Version control 里存在旧配置，并不等于回退可用；旧路径在当前网络里重新运送数据包，才叫可逆。

这种证据模型保持得很具体：RFC 提供确定的共同语言，厂商负责实现，运营者选择部署范围，网络运行结果决定它是否成立。Prefix 没有因为穿过 IPv6 core 就变成 IPv6；capability 也没有因为双方 OPEN 出现同一个数字就成为转发权威。只有类型、policy、递归、硬件与数据包一致时，这条路由才真正可信。