摘要

  • RFC 9631 实验性定义 CRH-16 与 CRH-32；短 SID 只是本地 CRH-FIB 的索引，表项还要给出 IPv6 地址、拓扑函数及可选参数。
  • 同一个数值在不同节点或不同表版本中可以触发不同动作。合法头部与成功查表不能证明控制器意图、ACL 判定、下一跳选择和包的实际去向一致。
  • 完整凭证必须把包与逐节点安装状态、表版本、信任判定、目的地址改写、出口观测、下游接收和应用结果连接起来。

抓包里只有一个很短的编号。第一台路由器把它解释为最低成本路径，第二台却用旧表把它解释为指定出口。两台设备都成功查表，也都正确递减了 Segments Left。

相同的 SID 没有带来相同的路径。

这不是 RFC 9631 的自相矛盾，而是其压缩方式的基本边界。CRH-16 与 CRH-32 让源节点用更少字节排列路径节点，但短编号的操作含义保存在包外的本地状态中。

编号只负责找到抽屉

CRH 以逆序保存 SID。节点先递减 Segments Left，再用它定位当前 SID，并在 CRH-FIB 中检索。返回的表项包括 IPv6 地址、拓扑函数和可选参数。函数可以要求沿最低成本路径到达某个接口地址，也可以要求从指定接口转发。

因此，SID 并不是一条被压缩完整的转发指令。它更像抽屉号码：抽屉里的地址、函数和参数才决定后续动作。

RFC 9631 允许 SID 只具节点本地意义。每个 SID 只由一个目的地址与当前包相符的 CRH 节点处理。路由器甲的 2 无需等于路由器乙的 2；同一台路由器的 2 也可能在 CLI 变更、控制器下发或分布式路由更新后改变。

要解释一次查表，记录至少要包括处理节点、时间、已安装 CRH-FIB 版本、具体表项、函数、参数和配置来源。缺少这些坐标时，抓包只能证明源端写入了哪个数，不能证明网络赋予了它什么权力。

通过格式检查仍未进入数据平面

处理规则很明确：超出实现能力的头部要丢弃；节点根据 Routing Type 与剩余段数计算最小长度；不可能的长度、没有表项的 SID，以及在最后一段之前出现的组播地址都要被拒绝，并按规则产生 ICMPv6 Parameter Problem。

这些检查证明输入满足一组局部条件。查表成功后，节点还要把表项中的 IPv6 地址复制到目的地址，再将包、函数和参数交给 IPv6 模块。下一跳、指定接口和物理发送都发生在 CRH 校验之后。

没有看到 ICMPv6 错误更不能证明成功。错误可能丢失、过滤或限速；合法表项也可能指向失效链路；出口发出后，下游仍可丢包；终点收到后，应用仍可拒绝。

所以应把头部校验、查表、地址改写、下一跳选择、出口发送、下游观察和应用接收分成不同凭证。把它们合并为一个“CRH 成功”状态，只会让故障责任失去位置。

被移出包外的版本历史必须有人保管

CRH-FIB 可以由运维人员通过 CLI 填充，也可以由 PCEP、NETCONF 控制器或分布式路由协议产生。RFC 9631 不规定这些机制。这保留了部署自由，同时把一致性责任留给本地运营者。

控制器接受请求不等于硬件已编程。NETCONF 成功响应可能早于 ASIC 安装。分布式更新在不同节点的生效时间不同。回滚可能恢复 SID，却没有恢复函数参数。部分更新甚至会把新函数与旧参数拼在一起。

包里没有 CRH-FIB epoch。要重建路径，必须把控制意图、候选配置、安装状态、数据平面实现与包观测放在同一时间轴上。时钟偏差会让两份都正确的前后快照错误地认领中间那个包。

互操作也不能只验证字段解析。RFC 要求实验报告说明不同实现是否支持相同的拓扑函数与参数，以及语义是否一致。共同识别一个短编号，却执行两种动作，只是位级兼容，不是路径级兼容。

看起来可信的源地址仍可能是伪造输入

RFC 9631 把信任定义为“由同一方运营”，接收节点通过源地址判断这种关系。面向本地地址的 CRH 若来自非可信源，必须被 ACL 丢弃。

源地址可以伪造。EFP-uRPF 能减少一部分伪造包，却不能消除全部风险。因此，每个边缘节点还必须阻断从外部进入、却冒充可信节点接口地址的 CRH 流量。

“可信源”由此不是包内事实，而是一条本地判定链：入口接口、前缀集合、ACL 版本、命中规则、计数或逐包记录、uRPF 所用路由状态和最终处置。还要证明规则在所有相关边界上及时安装。

IPv6 Authentication Header 的兼容性也不会补齐这条链。AH 可以在自身密钥上下文内保护包，但不会签署运维方的历史 FIB，也不会证明某条 ACL 位于正确边界，更不会给实际路径背书。

字段更短，不等于已经测得性能收益

CRH 的动机很具体：部分 ASIC 要把头部从缓冲存储复制到有限的片上存储；而 Path MTU Discovery 在现实中并不完全可靠，许多主机会避开超过 IPv6 最小 1280 字节的包，使大头部成本更明显。

这能形成实验假设，却不能直接形成收益结论。实际结果取决于芯片解析方式、头部深度、段数、载荷大小、链路 MTU、ICMPv6 可达性、软件慢路径和流量分布。更短的编码仍可能落入慢路径，或在不支持的节点上失败。

性能声明需要基线、相同流量、软硬件版本、包长分布、计数定义、丢包与延迟。16 位是规范事实；成本下降是运行测量。

实验性文档列出的正是尚未完成的证明

RFC 9631 不是 Internet Standards Track 规范。它要求参与者报告部署是渐进还是全网、是否需要同步配置、是否升级硬件、SID 是全域还是本地、安全实施成本、性能、ACL 效果与成本、FIB 填充机制、规模、互操作以及 OAM 是否充分。

这些项目不是附录里的礼仪，而是从“格式可实现”走到“方案可运营”仍欠下的证据。Ping、traceroute、tcpdump 与 Wireshark 能识别 CRH，有助于观察；它们不能自动证明函数语义、边界防护和应用交付。

最可靠的结论按证据分层：解析器证明理解字段，FIB 快照证明某时刻的本地状态，出口抓包证明一次发送，下一跳证明一次到达，终端应用证明一次使用。只有连接后的记录，才有资格描述路径。

来源