摘要

  • RFC 5350 为 IPv4 建立 Router Alert 数值注册表，并修正 IPv6 表中的不一致。注册可以保证编号可查、用途不冲突，却不能证明某台路由器会解析选项、识别数值或把报文交给控制平面。
  • RFC 6398 记录了多种真实处理路径：硬件快速处理、转入慢速路径、忽略 Value、忽略整个选项、过滤、限速或隧道隔离。数值说明请求何种关注，本地政策决定是否付出稀缺处理资源。
  • RFC 9805 在 2025 年关闭 IPv6 Router Alert 数值的新分配，并禁止未来新标准协议采用该选项，同时允许列出的既有协议继续使用。注册表关闭不是既有报文消失，也不是全球设备行为一致。

统一编号并不等于统一执行

RFC 5350 面对的是一个具体的协调缺口。IPv6 已有 IANA 管理的 Router Alert 数值表；IPv4 虽有 RFC 2113 定义的数值零，并被 RFC 3175 用于聚合层级，却缺少完整注册机制与分配政策。两个地址族的表还出现层级数量与数值重复的问题。

文件为 IPv4 建表，列出初始用途，划出实验区间，把新增数值放入 IETF Review，并清理 IPv6 的重复条目。此后，规范作者可以先查表，审查者可以阻止两项稳定用途占用同一个数值，实施者也能追到对应 RFC。

这项工作有明确价值，但价值的边界同样明确。注册表维护的是共同符号。它不会把解析代码装进线路卡，不会开启 RSVP 或其他协议进程，不会配置 CPU 保护阈值，也不会授权外部发送者使用设备的控制资源。

因此，“IANA 已分配”只能成为证据链的第一环。它不能替代“该型号支持”“该版本启用”“该接口允许”“该来源可信”“该速率可接受”等本地事实。若监控系统把公共表格直接当成设备能力表，文档事实就被误写成运行事实。

“应当检查”后面还有参与条件

Router Alert 的原始设计目标，是让路由器在不深度检查每个报文的情况下，识别可能与自身有关的报文。RFC 2113 的简短语义容易被读成所有路由器都必须检查。RFC 7126 给出了更精确的限制：路由器在参与 Value 所表示功能时，才应更仔细地检查。

这意味着报文只能提出类型化请求，不能单方面征用沿途节点。某台路由器可能根本没有实现相应协议；可能只在域内接口启用；可能认识数值但因来源不受信任而拒绝；也可能让报文正常转发，同时忽略选项。

注册值没有携带发送者身份，也没有携带运营商同意。它说明“如果你参与这项功能，这个数值表达什么”，而不是“你已经参与，并必须把 CPU 交给我”。

这个区别对安全自动化尤为重要。策略引擎可以利用 IANA 信息解释数值，却不能把“已分配”直接映射成“合法”。合法性还要看入口、来源、流量速率、信任域、协议开关与当前政策。注册表是上下文，不是判决。

真正稀缺的是慢速路径和控制平面

16 位字段提供大量数值，但路由器内最紧张的资源通常不是编号，而是特殊解析、转入慢速路径的带宽、通往通用处理器的队列、协议进程容量与状态存储。

RFC 6398 说明，不同实现并不一致。有的设备能在快速路径处理 Router Alert；许多设备会把大部分或全部相关报文送往慢速路径，除非被配置为忽略或丢弃。还有报告称，一些 IPv4 实现不按 Value 精细分类，而是看到任何 Router Alert 都进行处理。

普通转发芯片与控制处理器的能力差异，使远端标记可能成为拒绝服务入口。发送者只需设置选项，就可能要求设备付出比普通报文更高的成本。若没有本地准入，这个成本由发送者决定、由运营商承担。

RFC 6398 因而要求运营商主动、强力保护网络。过滤、限速、隧道、只在边缘处理，以及提供“忽略 Router Alert”的配置，都不是违背注册表，而是把符号与资源消耗之间加上授权边界。

运行记录应保存具体处置：未知、已知但关闭、忽略后转发、限速、丢弃、受保护地送入控制平面，或被协议进程接受。只有“报文含有 Router Alert”这一项，无法解释实际风险与结果。

从表格到业务结果至少隔着九张收据

完整调查应分别证明：

  1. 当时 IANA 已分配或保留该数值；
  2. 报文确实携带正确格式与数值；
  3. 目标节点在特定接口收到报文；
  4. 解析器读取了选项，而非忽略或提前丢弃；
  5. 节点认识数值，并参与对应功能；
  6. 本地政策允许检查或受保护的控制平面转交；
  7. 上层协议完成自身校验与授权；
  8. 预期的预留、成员或信令状态发生改变；
  9. 后续转发或用户可见服务体现了该状态。

前一张收据不能自动推出后一张。IANA 页面不能证明报文到达；上游抓包不能证明下游解析；CPU punt 计数不能证明协议接受；协议状态也不能单独证明最终业务质量。

失败分析的正确问题不是“数值是否注册”，而是“第一张缺失的收据在哪里”。过滤、平台不支持、限速、协议校验失败、状态未建立与后续转发故障，都可能产生相同的最终症状。

这种分层还避免责任错配。IANA 对编号协调负责；设备厂商对实现负责；运营商对本地政策负责；协议对验证负责；业务系统对结果负责。任何一方都不应凭一项证据被描述成控制整条链。

实验数值只在约定范围内有同一含义

RFC 5350 留出实验区间，同时提醒生产网络未必支持 IP 选项中的实验代码。不同管理域还可能独立使用同一个实验数值，跨域后便发生语义碰撞。

在单一域内，管理员可以统一数值、设备、限速、持续时间与退出条件。报文越过域边界时，这份约定不会自动同行。外部网络可能把它看成未知值，另一个实验，或需要整体阻断的异常流量。

所以“可用于实验”不是全球通行证。实验记录至少要写清参与设备、接口、邻居、含义、入口限制、泄漏防护、回退方式与到期日期。若只记录一个数值，实验停止后仍可能留下无法归属的配置。

回退路径也必须真实。选项被忽略后，报文能否按普通流量继续？若被过滤，是否有另一种信令？如果实验必须依赖未签约的外部域消耗控制资源，它从一开始就把本地协调误当成外部授权。

IPv6 注册表关闭，是对未来关门

冻结的当前 IANA 记录显示，IPv4 Router Alert 数值仍采用 IETF Review；IPv6 表则标注“Registry closed”。后者来自 RFC 9805。

RFC 9805 允许已有列名协议继续使用 IPv6 Router Alert，但要求未来新标准协议不得采用。文件指出，Router Alert 可能使不受欢迎的流量接触控制平面，Hop-by-Hop 解析成本高，相关报文常被丢弃，而且跨越本地网络的实际用途有限。

它把 MLDv2 与 MRD 描述为清单中广泛部署的用途，把其他项目描述为有限、实验性或没有已知实现。这是标准文件对设计空间的判断，不是实时全球普查。

注册表关闭改变的是未来分配权。它不会向所有既有设备下发配置，不会自动移除旧报文，也不会保证旧协议在所有路径仍可工作。一张关闭的表与多样的运行状态可以长期并存。

因此不能说“弃用等于消失”，也不能说“遗留允许等于端到端可用”。新协议的规范边界与旧协议的路径证据，需要分别处理。

最小协调，才能保留本地责任

Lu Heng 关于最小初始规范的笔记可以作为后来的分析视角：中心层只定义必要的共同对象，未来决定由实际参与者作出。它不是 RFC 5350 的历史来源，也不代表 IETF 的解释。

在这里，必要共同对象是唯一数值、引用与分配程序。是否支持、在哪些接口支持、为谁开放、允许多少处理成本，都由运营者决定。把这些权力留在本地，并不会削弱协调；相反，它让承担损失的一方保有退出与保护能力。

关于现实层次的笔记提供另一项纪律。注册表行是符号事实；报文位是观测事实；路由器处置是运行事实；协议状态与业务结果又是不同层次。把它们压缩成“标准支持”会让报表简洁，却让故障无法解释。

管理层需要掌握的是依赖图：哪些协议仍依赖 Router Alert，哪些设备和版本支持，哪些接口启用，哪些策略保护，硬件替换后默认行为是否改变。注册表给出名称，组织必须补齐执行证据。