摘要

  • RFC 10075 将路由器通告扩展标志选项的第 6 位分配给 SNAC 路由器标记。
  • 这一位可以给发送者分类，却不能验证身份，也不会自动授予发送权限。
  • RA-Guard 可能过滤掉恰好承载这一区分的通告。

IPv6 路由器通告现在多了一句只有一位长的自我介绍：发送者是 SNAC 路由器。RFC 10075 把 RA 扩展标志选项的第 6 位分配给这个用途。收到通告的 SNAC 路由器可以据此区分另一台 SNAC 路由器与转发流量的 transit router。IANA 当前注册表已经把该位列为 S - SNAC Router Flag。

这是一种分类信号，不是证件。RFC 没有规定 SNAC 路由器究竟在什么条件下必须把这位设为 1。不认识该标志的设备会静默忽略它；非 SNAC 设备不得把它设为 1。接收方看到的只是发送者声称自己属于哪一类，无法据此确认设备由谁部署、声明是否真实，也不能判断这条路由信息是否值得接收。

IPv6 邻居发现协议早已把授权边界写得很清楚：它没有机制判断哪些邻居获准发送特定消息，例如 Router Advertisement。标志可以改变消息的处理方式，却不能替代接收网络按链路、端口、配置和安全政策作出的准入决定。

交换机可能在信号到达读者之前将它抹掉。RFC 10075 明确指出，如果 RA-Guard 会过滤 SNAC 路由器发出的通告，transit 网络上的设备就永远收不到置位为 1 的那条 RA。RA-Guard 是二层过滤机制，通常按入端口控制路由器通告。把所有此类通告一律挡掉的网络，可能在 transit 设备读取新标志之前就把它删掉；没有明确规则就放行的网络，则可能让更多自己并不打算信任的消息通过。规则设在一个端口，影响却落到另一段网络。

因此，这一位带来的不是部署完成，而是一项具体的协调工作：哪些接口可以发出 SNAC 通告，面向 transit 的设备是否需要收到它，RA-Guard 如何处理扩展选项。“标准里已经有标志”不等于部署方案。真正要回答的是：哪台设备、从哪个端口看见它，随后又获准做什么。

现有来源证明了标准文本和 IANA 注册记录，没有给出设备支持清单、互操作测试或现场故障。多厂商抓包记录或公开支持矩阵会改变这个证据边界；这里缺少这两类事实。

来源