摘要

  • RFC 9837 定义实验性 IPv6 目的选项；其中 32 位数值指向出口 PE 的 FIB 条目，是服务选择器，不是发送者凭证。
  • 经过全球互联网时必须用 AH 或 ESP；在有限域内部署则依赖每个边界节点的 ACL，而 RFC 明确说这种防护是 fail-open。
  • 处理功能必须默认关闭。部署成本、代码点冲突、ACL 效果、规模、互操作与 OAM 都要由公开实验结果证明。

真正危险的报文往往不是格式错误，而是每个字段都正确、服务号也真实，却来自一个无权进入 VPN 的设备。

RFC 9837 于 2025 年 8 月以 Experimental 发布。出版页 证明 IETF 审议与 IESG 批准，不证明任何生产部署。RFC 7841 所保留的文档状态差异，在这里就是风险标签。

按照 RFC 8200，入口 PE 把客户数据封装进 IPv6，在上层数据之前放入一个 0x5E 目的选项。长度为四字节，值用来查找出口 PE 的 FIB；命中后决定向哪个 CE 转发，未命中就丢弃。

选择器不是身份证

如果域外设备能够冒充参与实验的 PE，它就能填写完全合法的服务值。语法检查甚至会帮助它到达真正的 FIB 条目。因此全球传输必须用 AH 或 ESP 保护。此时有效回执是对端身份、安全关联、算法政策、密钥时限与验证结果，而不是看见 0x5E。

有限域采取另一条路：每个边界节点都必须用 ACL 丢弃携带该选项、目的地又是域内接口的外来报文。RFC 8799 解释有限域边界；Safe(r) Limited Domains 草案 讨论 fail-open，但它仍是工作草案。

“只在内网使用”不是控制。控制是完整边界清单、每个节点的 ACL 版本与安装回执，以及从外部逐一发起的拒绝测试。新增专线、维护口或并购网络都可能让旧边界失真。RFC 6169 还提醒，隧道能绕过放错层次的检查。

FIB 也有自己的授权链

RFC 9837 允许运维人员用 CLI 写 FIB，也允许控制器通过 PCEP 或 NETCONF 写入，还可由路由协议生成；路由扩展不在本文范围内。

因此同一个服务号可能没有条目、指向过期条目，或在变更后属于另一客户。RFC 8342 区分请求、预期与运行状态。控制器成功返回不等于硬件已经应用；硬件里存在条目也不等于写入者获得了授权。

BGP/MPLS VPN、EVPN 与 SRv6 用不同方式携带服务语义，它们不是 RFC 9837 的部署证明。RFC 2473 解释通用 IPv6 隧道，也没有替代准入判断。

实验编号必须允许退出

IANA IPv6 参数表 提供实验性代码点。另一项实验也可能使用 0x5E，出口设备便可能在错误上下文中解释报文。RFC 因此要求处理默认关闭，只能显式开启。

文档还要求参与者公开部署工作量、同步与硬件需求、ACL 成本和效果、FIB 来源、规模、互操作，以及 PING、TRACEROUTE、Wireshark、TCPDUMP 的可见性。这份清单说明 RFC 发布的是可检验问题，不是生产合格证。

Heng Lu 的最小初始规范与本地未来决策正适合这里：共享四字节的解释，不替运营商决定准入。运行代码优先要求用观测回答实验问题；现实优先则要求明确：本文没有验证任何厂商、运营商或事故。

来源