摘要

  • RFC 2113 定义了四字节的 IPv4 Router Alert 选项，让过境路由器只对被标记的数据包做进一步检查。
  • RFC 6398 后来明确：开放互联网中的独立管理域不应依赖这种端到端处理；在有过滤、限速和信任约束的网络内，它仍可使用。

快速路径旁边的一扇门

转发中的数据包并不以沿途路由器为目的地。可是 RSVP、IGMP 等协议有时需要路径上的路由器参与。若让设备深查所有流量，正常快速路径也会承担代价。RFC 2113 的办法，是把“这是例外”直接写进数据包。

该选项共四个八位组。类型 148 由复制位、控制类和选项号 20 组成；第二字节把长度定为 4，最后两字节保存取值。最初只有零有定义，意思是路由器应检查这个数据包；1 到 65535 保留。

“检查”不是“照办”。识别该选项的路由器可以再看 IP Protocol 字段，判断是否真的需要进一步处理。主机忽略它；不识别该选项的路由器也忽略它；无法识别的取值则被静默忽略。四字节里没有发送者身份、许可或资源配额。

RFC 2113 已经写下双向代价：该用而未用，依赖它的协议会受影响；不该用却设置，数据包可能离开快速路径而变慢。它用一扇显式的门保护普通流量，却没有单独解决谁有资格推门。

从开放信号到受控信任

RFC 6398 讨论了这扇门的运营后果。部分实现会把大多数甚至全部 Router Alert 流量送入共享的慢速路径。大量伪造或不受欢迎的标记数据包可能耗尽这部分能力，连带导致其他控制平面应用丢包，形成拒绝服务。

精确分流并不容易。下一层协议号无法区分共用同一传输协议的不同应用；Router Alert 的取值注册表也只能提供较粗的分类，而且实现行为并不一致。因此，标记本身无法成为“值得关注”的通用证明。

后来的规范没有把 Router Alert 全面废止，而是缩小了适合依赖它的范围。RFC 6398 建议：应用不应跨开放互联网的独立管理域，端到端依赖 Router Alert。单一管理域内则不同——可信来源、过滤和限速可以约束入口；隧道可以让标记穿过运营商核心而不触发核心路由器；密闭或受控泄漏的覆盖网络可以明确规定哪些设备参与。

RFC 2711 所定义的 IPv6 Router Alert 是 Hop-by-Hop 选项，在本文中只用于划清比较边界；它不决定 IPv4 的类型、长度和复制行为。两者共同提出的问题是：数据包能否请求关注是一回事，网络是否允许它消耗资源是另一回事。

来源