摘要

一个位号，三道门

IANA 当前注册表写着第 6 位；2026 年 6 月 5 日的标志草案仍把位号写作 TBD，并向 IANA 提出分配请求。Datatracker显示该文进入 RFC Editor 队列，当前查到的文本仍是 Internet-Draft。这两份文件分别呈现登记状态和草案冻结时的措辞。不能从这个时间差推断某个网络已经启用，更不能编造分配发生的具体日期。

这个 S 是分类信号。SNAC 路由器把末梢网络接到相邻基础设施网络；收到 S=1 的路由器通告，表示发送者是 SNAC 路由器。标志草案同时规定，不理解该位的设备会忽略它，非 SNAC 设备不会把它置为一。这使旧设备仍按原有通告流程工作，也使新设备能辨别通告来源。至于发报设备什么时候置位，短草案自己不管。它把决定交给实际连接末梢网络的配套方案。

配套的第 13 版 SNAC simple 草案给出了第一道门：接口。SNAC 路由器在相邻基础设施链路上通告自己的适用在链前缀，S 必须为一；在末梢网络链路上发出的通告，附录 C 要求 S 为零。同一台路由器、两侧链路、两种标志值。只检查“设备支持 S”而不查通告从哪一侧发出，等于把楼内门牌当成街道通行证。

收到另一个前缀后，谁退场

设一台 SNAC 路由器正在相邻链路上通告自己的适用前缀，又收到另一份带有不同适用前缀的通告。如果收到的 S=0，第 13 版让本机接口进入 STATE-DEPRECATING，开始弃用自己原先通告的前缀。这条规则把非 SNAC 通告和 SNAC 通告区分开，避免靠先到先得决定链路上的前缀。

若收到的 S=1，裁决表就不再是一句“对方赢”。两个前缀相同，本机继续通告；本机通告的是 ULA，而收到的是非 ULA 适用前缀，本机弃用；双方都是 ULA，收到的前缀按 128 位无符号整数比较更小，本机弃用。其余列明情形，本机继续通告。S 把接收方带进一组明确分支，而不是给发送者一张无条件胜利的选票。

因此，前缀选择发生在接收设备里。它需要知道本机当前通告的前缀、收到的前缀是否适用、两者是否为 ULA、S 的值，以及报文到达的是哪条链路。IANA 只让这些设备对同一个位号达成共识，并不替它们比较前缀。运营者如果只拿注册表截图解释某次弃用，关键证据还没上桌。

过滤器可以抢先表决

标志草案的运行章节直接点出第二道门：如果 RA-Guard 的实现过滤 SNAC 路由器通告，传输网络上的设备就永远收不到 S=1 的报文。RFC 7113讨论 RA-Guard 的实现问题。发送端完全按规范发报、IANA 编号清清楚楚、邻居也具备处理逻辑，仍可能因为本地过滤规则而无法互相协调。

这不是一句泛泛的“网络环境复杂”。链路运营者具体决定哪些路由器通告可以通过交换设备。放行后，IPv6 邻居发现原有的安全问题仍由原有机制处理；短草案的安全章节明说新增 S 不改变 RFC 4861 的安全考量。S 是报文里的路由器类型信号，不是对端身份验证。把它当认证凭据，会把安全决策塞给一个为前缀协商而设的位。

这些官方文件缺少一条具名链路的 AIL 抓包、RA-Guard 决策记录和接收端状态变化；三项证据齐全才能证明一次实际部署如何执行这套规则。现在能够判断的是规范分支和注册状态，不能替某个现场报出成功率。

编号统一了词汇，现场仍要交卷

第六位的意义在于把协作拆得更清楚。IANA 管位号；短草案管信号含义；配套草案管何时从哪个接口发送以及收到后如何选前缀；链路运营者管过滤；接收路由器管执行。五个环节挤成一张“支持 SNAC”证书，任何一处失败都会像神秘的前缀漂移。分别记录它们，故障就能找到负责的一侧。

现场验收不需要宏大口号，只要一条完整的证据链：发送接口、S 值和前缀、过滤结果、接收报文、接收方状态。如果报文走错接口，修发送端；如果止步于过滤器，查本地策略；如果到达后选错分支，查前缀输入和实现。第六位给这些记录一个共同名字。哪条前缀留下，最终由它们共同决定。

来源