摘要

  • RFC 5175 用类型 26 的扩展标志选项增加了 48 个位置，同时规定长度校验、未知位忽略、只处理第一个实例以及选项顺序。
  • 注册表中的位置和抓包中的置位都不是功能已经执行的证明。完整证据还要覆盖过滤结果、接收端版本、关联选项、本地策略、状态变化和最终流量。

把网络能力画成一排开关很有诱惑力：0 表示没有，1 表示具备。但路由通告里的比特并不是设备资产表。它首先是发送方在链路上发出的符号。RFC 5175 把基本头部的 8 个位置扩展到 56 个可编号位置，其中 8 至 55 位放在扩展选项中。标准建立了坐标系，却没有替未来规范完成实现。

兼容性的代价，是允许“不理解”

扩展选项的 Length 以 8 字节为单位。当前格式发送值 1，接收端仍须检查长度，为将来更长的格式保留跳过未知数据的能力。长度小于 1 的选项被忽略，未知标志位也被忽略。

这正是渐进部署能够成立的原因。老系统不必因为新比特而拒绝整个路由通告。但同一规则也说明，抓到相同报文的两台主机可能有不同结果：新版本识别并继续处理，旧版本安静地略过。沉默既不能证明功能生效，也不能证明报文未到达。

IANA 注册表解决的是位置冲突与引用归属。研究冻结时，表中 S 位指向一个仍在推进的 Internet-Draft。这个时间点上的记录不能被写成已经发布的 RFC，更不能被写成全网部署率。注册、实现和启用必须分栏记录。

第一个实例才是接收端的事实

扩展标志选项只能出现在 Router Advertisement 中。发送方至多放一个；没有任何已定义扩展位需要置位时，应当省略。若报文里出现多个实例，接收端只处理第一个，其余全部忽略。

因此，把多个实例合并成“所有看见过的标志”会制造一种协议没有要求接收端采用的状态。偏爱最后一个实例也同样错误。取证系统必须保留完整字节顺序、被选中的第一个实例、声明长度和实际捕获长度。

顺序还连接了标志与参数。扩展标志选项必须位于与这些标志有关的后续选项之前。只摘出一个比特，却丢掉后面的关联选项，相当于保留结论标签而抛弃形成结论的材料。

从临时类型到 26，只完成了协调

RFC 5075 已描述了近乎相同的结构，但类型值仍是临时位置。RFC 5175 写入正式分配的 26，并删除因此不再需要的文字。这个变化让不同实现能在同一线格式上相遇，却不会自动把解析器装进现有设备。

运营记录至少需要六种状态：注册表证明“已分配”，报文证明“已发送”，接收端构建版本证明“可识别”，SEND 或本地策略证明“获授权”，配置差异证明“已应用”，流量观测证明“产生效果”。任何一项都不能替下一项发言。

RA-Guard 也只是链条的一环。RFC 6105 明确其效果依赖二层拓扑和报文是否经过执行策略的设备；RFC 7113 又记录了一些实现曾被绕过，并要求更完整地解析 IPv6 头链。产品页上的安全功能名称，不能代替针对某个报文的放行或丢弃回执。

当前 SNAC 标志草案提供了清楚的现实例子：不理解该位的设备会静默忽略，过滤策略也可能让下游根本看不到该通告。发送端的一次置位，可以在不同位置分别成为已识别信号、未知符号或从未到达的报文。

来源