摘要

  • RFC 9805 禁止未来新标准化的协议使用 IPv6 Router Alert 选项，并关闭 IANA 的 Router Alert 取值注册表；但附录 A 穷举列出的既有协议仍可继续使用，包括这些协议的未来版本。
  • “注册表关闭”只证明标准制定与号码分配的入口已经关闭。某张网络是否仍接收、深度检查、限速、忽略或丢弃相关报文，必须由实际配置、抓包、计数器、控制平面遥测和迁移测试分别证明。

假设一台路由器每秒转发数以亿计的普通报文，其中极少一部分带着一句特殊请求：虽然目的地址不是你，也请再看我一眼。这句话就是 Router Alert 的权力核心。它不要求报文停在本机，却试图让沿途设备把报文从高速转发的背景中挑出来。

RFC 9805 在 2025 年 6 月以 IETF 标准跟踪文件发布，并更新 RFC 2711。它没有删除这种请求，而是给标准体系装上一道单向棘轮：已经使用 IPv6 Router Alert 的协议可以继续使用，甚至可在后续版本中保留；未来新标准化的协议不得再采用它。附录 A 是可以继续使用者的穷举清单。

IANA 已在其权限范围内完成相应动作。IPv6 参数注册表把选项类型 0x05 标为“Router Alert (DEPRECATED for New Protocols)”。独立的 IPv6 Router Alert Option Values 注册表显示“Registry closed”；原先用于实验的 65503 至 65534 被保留，MPLS OAM 使用的取值 69 标为弃用。

这些登记事实不会向全网下发一条过滤规则。0x05 并未从报文格式中消失，旧协议也没有因注册表状态而失效。注册表无法证明一台真实路由器是否在硬件里识别该选项、是否把报文送到控制平面、是否按接口限速，或者是否把整个 Hop-by-Hop Options 流量都挡在边界。

这一区别解释了为何标题中的“关闭”不能被写成“清除”。标准机构能够停止创造新的依赖，却不能用一页文本同步改变所有已部署设备、业务假设和现场配置。RFC 9805 管的是未来规范的选择空间；既有网络里的效果仍由运行中的代码和操作者的本地决定构成。

Router Alert 最初是一次性能优化。RFC 2711 于 1999 年定义 IPv6 Router Alert 选项。当某个过境报文携带路由器感兴趣的控制信息时，沿途路由器可能需要比处理普通数据报更深入地检查它。但让每个设备对所有报文做高层解析代价过大，于是选项在 Hop-by-Hop Options 头部提供一个小标记：这个报文值得额外处理。

优化同时创造了权力不对称。发送者几乎不付成本就能写入标记，沿途路由器却必须花资源判断这个请求是否合理。RFC 2711 当时已经警告，无节制地使用 Router Alert 会带来性能问题，伪造或无意义的标记报文可能形成洪泛；过境路由器因此可以按速率或其他办法限制它们。

二十多年后，问题没有变成一个可轻易匹配的黑白名单。RFC 6398 指出，Router Alert 报文的源与目的可以多样，无法像一个已知控制邻居那样，仅凭固定地址或端口就普遍区分“需要的”与“不需要的”流量。标记还可能让核心路径上的设备承担检查，而非只影响某个管理边界。

硬件结构放大了这种不对称。RFC 6192 将路由器的高速转发面与较通用的控制平面分开讨论。前者通常依靠专用硬件处理巨量报文；后者运行路由、管理等复杂逻辑，可用处理资源相对有限。一小股被转送到错误处理路径的流量，可能对控制平面造成远高于其带宽占比的压力。

理想的保护会尽量靠近转发硬件完成分类与限速。但 RFC 9805 点出 Router Alert 的特殊成本：访问控制表匹配固定位置的字段较容易；要在可变的 Hop-by-Hop Options 头部中寻找某个选项，则需要更复杂的解析。一个原本用来避免普遍深度检查的标志，到了防护阶段反而要求设备为识别它而做额外工作。

运营者面对的不是一道统一选择题。网络可以精细识别合法取值，并为每类预期流量设置速率和作用域；这样保留功能，却增加配置、测试和跨平台一致性的负担。网络也可以让设备忽略 Router Alert，或在边界丢弃、严厉限速包含 Hop-by-Hop 头部的报文；这样保护资源，却可能破坏仍依赖它的协议。RFC 9805 没有宣称其中一种策略适合所有网络。

它真正改变的是未来成本的分配。若新协议还能不断加入，运营者必须持续扩大需要识别和维护的例外集，宽泛丢弃也越来越难采用。RFC 9805 让未来协议设计者不能再把这种解析与保护成本交给所有后来的路由运营者。新设计必须选择别的机制，而不是为 Router Alert 清单再添一项。

RFC 9673 提供了关键背景。该文件重订 IPv6 Hop-by-Hop 选项处理方式，通常不要求节点默认把这类选项送到控制平面处理。Router Alert 却因为本意就是请求额外检查而构成例外。RFC 9805 没有假装例外不存在，而是限制其时间方向：历史用途继续，新标准用途归零。

附录 A 的“穷举”性质十分重要。它防止未来把“旧用途”变成一只可以随意装入新项目的口袋。RFC 9805 表示，清单中只有 Multicast Listener Discovery Version 2（MLDv2）和 Multicast Router Discovery（MRD）得到广泛部署。其他项目或用途有限，或属于实验，或没有已知 IPv6 实现，或已经弃用，例如 MPLS Ping 对 Router Alert 的使用。

但这段标准文字不是部署普查。它不能证明某个具名运营者部署了 MLDv2 或 MRD，不能证明某型号设备如何处置报文，也不能证明其他用途在所有地方都已退出。它只是解释标准为何无法立刻取消整项机制，以及为何替代工作必须准确面对最难迁移的依赖。

RFC 9805 也明确没有设计 MLDv2 与 MRD 的替代版本。禁止新的标准依赖可以在标准流程内即时生效；替换已经广泛部署的协议则需要新规范、实现、互操作、共存期、回退、采用和实网验证。把两件事合并为一个截止日，看似果断，实际上可能让标准写下无法兑现的结果，或让运营者用业务中断来证明“服从”。

因此，围绕 Router Alert 的证据必须分层保存：

  1. RFC 9805 证明未来新标准不得采用它，并界定历史例外；
  2. IANA 注册表证明选项和取值的行政状态；
  3. 某个历史协议规范证明该协议如何解释特定取值；
  4. 设备当前运行配置证明本地选择的是识别、限速、忽略还是丢弃；
  5. 抓包与分类计数器证明哪些带标记报文实际抵达及如何处置；
  6. 控制平面 CPU、队列、丢弃和稳定性遥测证明资源后果；
  7. 业务测试证明 MLD、MRD 或其他合法功能是否正常；
  8. 迁移测试证明替代路径已覆盖真实部署，旧依赖可以撤走。

任何上一层都不能冒充下一层。“Registry closed”不等于现场计数为零；一份期望配置不等于所有设备已加载；没有事故工单不等于没有额外解析；发布替代草案也不等于协议迁移完成。RFC Editor 的 RFC 9805 资料页可证明文件日期、状态与更新关系，勘误页可确认后续正式修订，但它们都不观察某张网络的报文。

RFC 4286 记录 MRD 的具体协议背景，RFC 9777 则属于近期多播规范环境。引用它们有助于理解例外来自哪里，却仍不能把规范存在写成部署事实。若要对某个运营者作判断，还需要设备、路径和业务层面的独立凭据。

Heng Lu 在最小初始规范、本地化未来决定与自愿采用中给出的治理模型，正好解释了 RFC 9805 的克制。共同层只冻结必要边界：新用途禁止，旧例外穷举。未来决定则留给必须发明替代机制的协议设计者，以及了解自身设备、流量和义务的网络运营者。

运行代码优先要求再问一步：文本是否已经变成机器执行的选择？只有已加载的配置、真实硬件路径、计数器、抓包和故障演练，才能证明某项本地政策存在。只有端点和中间网络在替代机制下产生正确结果，才能证明迁移，而不是仅证明有人写了一份计划。

现实层则阻止组织把象征性完成放大成技术完成。RFC 是规范约束，IANA 是行政登记，设备配置是技术状态，报文处理是运行行为，业务结果是最终效果。这些层之间有因果关系，却没有等号。

所以，RFC 9805 既不是一张安全证书，也不是无力的象征动作。它是一只棘轮：标准体系停止沿着一个危险方向增加齿牙，而安装基础仍会转动，直到设计者、实现者和运营者用新的运行代码及可验证凭据承担剩下的工作。

来源