摘要

  • RFC 9673 更新 RFC 8200，为现代路由器与主机规定可选择、可配置的 Hop-by-Hop 处理程序，并把整体转发能力放在资源边界内。
  • 路由器可以继续转发数据包，同时跳过无法处理或没有启用的选项；因此终点收到包不等于每一跳都执行了选项。
  • 完整证据要分别绑定平台与 build、启用选项表、选项顺序和长度、路径与时间、逐节点观察、整体转发影响和业务结果，且不能杜撰统一预算。

源端做了一次很漂亮的 A/B racing：一个包带 Hop-by-Hop 选项，一个包不带，两者都得到终点确认。报告随即写下“全路径支持该选项”。真正被验证的只有传输。哪台中间路由器读了选项、哪台执行了动作、哪台按本地策略跳过，报告一项也答不出来。

RFC 9673 的价值，正是把这种不确定性从暗处搬到规则里。它更新 RFC 8200，目标不是强迫每台高速路由器做同样工作，而是让 Hop-by-Hop 选项能够在现实设备中逐步部署，同时保护整体转发和控制面。

最小共同规则不再假装每一跳都会执行

早期 IPv6 设计要求所有节点检查并处理 Hop-by-Hop 头。高速转发让这项要求变得不切实际：某些选项可以在 fast path 完成，某些会把包送到 slow path，某些甚至会竞争路由协议与管理协议所需的控制面资源。

RFC 7045记录了扩展头在真实网络中的处理现实；RFC 7872报告过多类扩展头的路径丢弃测量；RFC 9098与 RFC 9288分别整理运营影响和 transit router 过滤建议。这些资料说明风险为何存在，却不能被拿来声称今天某条未命名路径一定丢包。

RFC 9673 明确：路由器即使不处理 Hop-by-Hop 头，通常仍必须依据后续头部正常转发，不能只因该头存在就丢包。为保护不能遵守该规范的下游设备，运营者可以配置有限例外。

这条规则把“运输”和“处理”拆开了。一个包可以因为选项被执行而到达，也可以因为选项被安全跳过而到达；还可能只有少数节点做了动作。终点确认是包的收据，不是沿途 CPU、ASIC 或网络处理器的集体签名。

规范没有发放一个全球统一预算

RFC 9673 所说的 Full Forwarding Rate，是指处理行为不会损害聚合转发速率。它没有规定所有设备必须处理几个选项、多少字节，也没有给一条可复制到采购表的统一数字。

真正的开销取决于硬件结构、parser 可达范围、微码或软件版本、选项语义、顺序、包速率、流量组合以及限速策略。规范建议：如果处理第一个选项会伤害整体转发，就不应把路由器配置成处理它；更多选项只有在同样不损害聚合能力时才应处理。它还提出一种可能实现——维护一张可在全速转发下处理的 Option Type 查询表，并让运营者配置其动作。

这张表值得保存，但必须有主体。它可以证明某型号、某 build、某策略代次声明支持某个 type；不能证明全网设备都装了这张表，不能证明流量经过这些设备，也不能证明观测到的那一个包真正触发了动作。

企业可以把“处理预算”作为运营术语，但必须同时写下维度：设备、版本、接口、type、位置、总长度、速率、fast/slow/control plane、限流与观察窗口。否则一个绿色能力标签会把多种现实重新压成符号。

顺序本身就是控制权

源端可以只放一个选项，也可以限制多选项的总长度。RFC 9673 鼓励按重要性递减排序，因为某些路由器只会处理第一个，或只处理有限数量。

假设诊断选项在前，业务关键选项在后。一台只处理一个选项的路由器完全可能符合自身能力和策略，却没有执行服务真正依赖的动作。交换顺序便改变结果，而两个 type 在 IANA IPv6 参数注册表中的地位没有任何变化。

注册表负责标识分配和规范指针，不负责证明产品实现、运营启用或现场执行。另有文章已经讨论未知 Option Type 高位 action bits 的语义；本文不重复那条边界。RFC 9673 在相关情况下把 router 的丢弃与 ICMP 行为改为受配置影响，本文关注的是谁有权决定是否花费处理资源。

没有 ICMP，不等于沿途同意

RFC 4443定义 ICMPv6 错误。RFC 9673 说明：源端若收到 Parameter Problem，可以知道至少有一个节点没有识别选项。但反过来不成立。节点可能识别并执行，可能识别但未启用，可能不识别却继续转发，也可能发送了错误而返回路径没有把它交给源端。

因此静默不是肯定确认。终点 ACK 也不是逐跳确认。更强证据可以是绑定节点、接口、type、build、策略代次和时间的计数器或 trace；若服务关心实际效果，还要再证明选项动作确实带来预期结果。

Router Alert 说明为什么资源保护不能省略。RFC 6398讨论把包引向 slow path 的风险。RFC 9673 把 Router Alert 保留为控制面例外，但要求处理它的节点使用可信来源控制、限速或其他保护。它不是本文主角；它只是提醒：包里的请求不能自行征用路由器资源。

路径探测有保质期

RFC 9673 支持渐进部署：应用可以先发一枚带选项的测试包，等待确认，再决定是否继续；也可以将带选项与不带选项的流量 racing。如果失败，服务应回到不依赖该选项的模式。RFC 8799所说的 limited domain 可以让运营者共同配置节点；开放互联网没有这种统一控制。

Racing 的优点是用观测替代想象。它的限制是观测会过期。路由收敛、ECMP 选择、维护、更换镜像或策略更新，都可能换掉实际主体。昨天成功的路径不能替今天签字。

一份可复核记录至少保存：精确包字节、选项 type 与顺序、扩展头总长度、源与目的、流标识、观察到的 route、时间、确认条件、ICMP、逐跳遥测和整体转发指标。如果服务必须依赖某台中间节点执行，就必须取得 node-bound processing receipt；否则就应设计成节点跳过时仍有用。

RFC 9673 真正保护的不是一个功能徽章，而是可持续采用。新选项应简单、可在全速转发中处理、短小、可以被跳过，并能承受部分路径拒绝。规范把“安全不做”纳入协议；运营者要把“不做”从绿色状态里辨认出来。

来源