摘要

  • draft-ietf-spring-sid-as-source-address-00 于 2026 年 9 月 7 日发布，并成为 SPRING 工作组文档；这表示工作组接手研究，不表示它已成为 RFC，也不验证其中的实现声明。
  • 草案建议把与 VPN 业务对应的 SID 写入外层 IPv6 源地址，使往返两向的外层地址关系能够被有状态防火墙配成同一会话。
  • 源地址由设备定位符变成业务分类符后，匹配成功只能证明报文符合当前会话规则；它不能单独证明物理来源、客户身份、使用资格或地址真实性。

先看原来的不对称从何而来。入口 PE 为客户报文加上 SRv6 外层头时，常以自己的环回地址作为源地址。另一端的 VPN 业务 SID 则代表最终目的：在尽力转发中直接位于 IPv6 目的字段，在 SR Policy 中可由 SRH 的最后一个条目表达。理解 SRv6 的防火墙能够取出这个最终目的，再据此建立三元组或五元组状态。

回程时，另一台 PE 的环回地址成为源地址，而第一台 PE 的业务 SID 成为最终目的。两个方向并没有把外层地址原样互换。若防火墙要求回程源等于去程目的、回程目的等于去程源，它就可能把同一次客户通信拆成两个会话，进而丢弃正常回包或 ICMP 错误。

9 月 7 日的工作组草案把解决方案写得很直接：入口 PE 先判断报文属于哪个 L3 VPN，再选择对端所期待的业务 SID，把它放入外层源地址。反向由对端做同样的事。于是业务 SID 在两向报文的源、目的角色之间对换，防火墙终于看到一组对称的键。SID 出现在源字段时只按普通 IPv6 地址处理，并不会在那里触发端点行为。

关键代价也由此产生。过去的源地址至少指向入口 PE；新的源地址首先表达业务上下文。防火墙看到的“源”不再天然对应一台设备，更不对应一个客户。它可以据此确认某个回包与已存在的状态项相符，却无法仅凭这个字段确认哪台机箱发包、哪个接入电路触发、该节点是否有权使用该 SID，或者内部是否有人仿冒。

草案用三种粒度展示了成本分配。按 VRF 分配的 SID 无需额外查找，操作最简单，但同一 VRF 下的多个客户边缘会共用一个可见来源。按接入电路分配可在不增加查找的情况下细分到 AC。按前缀分配最精细，却要求入口 PE 根据客户报文源地址再做一次 VRF 内查表，可能影响转发性能。草案要求优先使用可得到的最细粒度，一般依次为前缀、AC、VRF；这不是取消取舍，而是明确取舍发生在哪一层。

安全章节没有把“对称”包装成“可信”。SRv6 定位符前缀通常在域内可路由，内部节点可能构造看似合法的 SID 源地址，借此绕过把某些前缀当成可信来源的访问规则。可编程 SID 如果频繁变化，还可能加速会话创建和老化，消耗防火墙表项并造成溢出。草案因此要求严格限制哪些业务流可以使用 SID 作源。防伪、来源授权、SID 生命周期和容量预算必须另行建立。

ICMP 的价值也需要限定。SRv6 Ping 可以用 End SID 作外层源，测试回程可达性；中转节点生成错误时，可以用发生处理问题的那个 SID 作源，让头端更快找到相关节点和段。若错误由 VPN 流量触发，入口 PE 仍须按 RFC 8986 处理嵌入报文的上层头，才能把内层 ICMP 送到客户边缘。一个更好用的故障位置不是对报告节点的密码学认证，也不是根因裁决。

压缩又带来解析依赖。RFC 9800 允许压缩段列表，使路由头最后元素与最终端实际收到的地址不同，也可能在没有 SRH 时把压缩信息放进目的地址。新草案建议保留最终目的的完整形式，并把它放在 SRH 最后一个条目，便于防火墙恢复一致的目的语义。两台 PE 即使都选对源 SID，中间设备若还原出不同的最终目的，会话对称依然失败。

实现状态同样不能越权。草案称 New H3C 的 CR16000、CR19000 系列在 7.1.119 及以上版本实现了全部条款，并把成熟度标作生产；但该记录仍写着前身 Draft-13，且“实现经验”栏没有具体内容。依照 RFC 7942，草案也明确说明，这类由贡献者提供的声明未经 IETF 核验，不构成认可。它是值得关注的运行代码线索，不是独立适配、互通、部署规模或性能证明。

这正对应 Heng Lu 关于现实层与运行代码的纪律。工作组状态属于协调事实；PE 配置属于预期状态；抓包与会话表属于观察证据；客户是否收到业务、事后能否追责属于结果。每一层都真实，却没有哪一层能替下一层作证。

因此，这次接纳值得报道的不是又多了一个 SRv6 功能，而是标准化工作开始正面处理一个语义交换：为了让防火墙少误杀，网络把“源地址”改造成业务标识。可接受的证据链必须同时保存 SID 分配、允许发起者、选择粒度、防火墙解析版本、状态表命中、实际报文与客户结果。只有这样，“回程流匹配成功”才不会被误写成“来源身份已经确定”。

来源

  1. IETF Datatracker：SID as source address in SRv6
  2. 工作组草案 00
  3. Datatracker：前身草案
  4. 前身草案第 13 版
  5. SRv6 安全考虑第 16 版
  6. RFC 8402：段路由架构
  7. RFC 8754：IPv6 段路由头
  8. RFC 8986：SRv6 网络编程
  9. RFC 9252：基于 SRv6 的 BGP 覆盖业务
  10. RFC 9259：SRv6 运维管理
  11. RFC 9800：压缩 SRv6 段列表
  12. RFC 7942：实现状态章节
  13. Heng Lu：Running-Code Primacy
  14. Heng Lu：Minimum Initial Specification
  15. Heng Lu：Reality Layers