Summary

  • draft-ietf-rtgwg-dst-src-routing-revive-06 把源前缀纳入路由身份和查找过程；它不是目的路由旁边的一条备注。
  • 混合部署中，本机路由表出现这条记录，并不能证明下一跳理解源约束。设计必须保持能力连续、证明经过旧节点仍向目的地前进，或者明确丢弃，否则可能形成持久环路。

设想 A 与 B 两台相邻路由器。A 根据“目的 D、来源 S”把包交给 B；B 只按 D 查表，又把包送回 A。两张表各自在自己的规则里都像是正确的，组合起来却给同一个数据包赋予了两种“最佳匹配”。

这正是 RTGWG 草案第 06 版最值得领导者关注的部分。文件日期为 2026 年 9 月 16 日，仍是 Internet-Draft，不是 RFC。它要求每条路由在语义上都带有源前缀；普通路由等同于源范围 ::/0。查找先选择最长的目的前缀，再在这个目的前缀下选择最长的源匹配；若没有源匹配，则退到较短的目的前缀继续，而不是直接结束。

因此，真正的运行对象不是“D 已装入”，而是目的、来源、递归解析、下一跳、能力拓扑与转发动作的组合。

收到路由，不等于会按它转发

不支持新语义的节点未必报错。它可能顺利处理数据包，只是使用更粗的规则。这样的降级比明确拒绝更难发现。

草案要求协议扩展保证无环，并给出三类办法：下一跳必须留在支持目的/源查找的拓扑内；若下一跳不支持，则度量或相同下一跳关系必须证明数据包仍朝目的地前进；否则把路由视为不可达并丢弃。

显式黑洞看起来难看，却把失败限制在清楚的边界。环路会消耗带宽与设备资源，还会让已知的不兼容在负载变化时变成不稳定故障。

距离矢量协议按邻居逐跳传播，能力协商或“不理解就不传播”可以帮助维持边界，但前提是控制路径与数据路径一致。链路状态协议则不同：节点能够扩散自己不会用于转发的信息。参加 flooding 不是转发能力证明。支持新语义的路由器必须把跨越旧节点的路径改成黑洞，或者只在支持节点组成的独立拓扑上计算 SPF。

先铺能力，再激活路由

第 06 版把两个变更拆开：一是安装能执行目的/源查找的软件，二是开始使用真正的源限定路由。没有这类路由时，新路由器与旧路由器行为相同，所以可以先完成全域能力部署与验证，再激活新语义。草案对此给出强烈建议。

“版本支持”只是产品陈述。有效回执还要记录实际运行 build、功能状态、表项上限、邻居能力和转发测试。回滚必须反向排序：先撤销源限定路由，再移除理解它的能力，否则恢复动作本身会切断兼容集合。

实现状态附录提到 Linux 的 CONFIG_IPV6_SUBTREES、FRRouting、babeld、一个四路由器实验网，以及 CERNET 最近升级的 20 台路由器。这些是草案作者的状态陈述，不是独立的生产测量，也不能证明普遍互通。

路由表只是证据链的起点

草案建议把目的/源路由与相关的普通路由并排显示。这能减少误读，却仍只证明本地控制面状态。它不证明递归下一跳正确考虑 S，不证明硬件已经编程，不证明后续每一跳都留在能力岛内，也不证明 S 到 D 的包已送达。

完整证据链应分别保存：规范版本；运行软件与资源上限；邻居或拓扑能力；已装入路由与策略纪元；递归结果和 FIB 动作；连续能力路径或计划内丢弃；针对具体 S–D 的数据包观察；限定时间内的服务结果。任何一项都不能替下一项作证。若探测没有记录所用源地址，它甚至可能问了另一个路由问题。

Heng Lu 的“最小初始规范、未来决策本地化、自愿采用”框架在这里很实用。共同层只需固定互通所必需的语义：源前缀属于路由身份、查找顺序确定、协议必须无环。是否激活由运营者本地决定；但跨设备的兼容性，必须由运行代码与实际转发证明，不能靠一方宣布。

Sources