摘要

  • 从 RFC 1883 开始，IPv6 TLV 选项类型的最高两位就规定了“处理节点不认识该类型”时的后果：越过它继续、丢弃数据包，或者丢弃并返回指向具体类型字节的 ICMPv6 错误。
  • 第三高位另行声明选项数据是否可能在途中改变。这三位约束的是无知的处置方式，不保证每台路由器都会处理该头部、每个中间盒都会放行，也不证明选项值得信任。

旧程序可以不懂含义，却不能不知道边界

设想一个 IPv6 目的节点：它认识 Destination Options 头，也会读取 Type、Length、Value，却第一次见到其中某个类型。它无法解释 Option Data，但仍能知道这段未知内容有多长。

1995 年 12 月发布的第一份 IPv6 规范 RFC 1883，进一步把处置规则放进八位 Option Type。最高两位回答“不认识时怎么办”，下一位回答“数据能否在到达最终目的地之前改变”，其余五位参与标识类型。

这是一种克制的扩展权。新选项的设计者可以公开声明不兼容时的安全后果，却不能要求旧程序理解它的私有语义。旧程序只需遵守共同外壳，不必猜测 Value 的意义。

两位编码了四种无知后果

00 表示跳过该选项，继续处理同一头部；长度字段给出下一个边界。01 表示丢弃数据包。10 表示丢弃，并向源地址发送 ICMPv6 Parameter Problem Code 2，指针落在无法识别的 Option Type。11 同样丢弃并报告，但目的地址是 multicast 时不发送这条错误。

这四个值不是风险等级。00 不等于内容安全，11 也不等于恶意；它们只说明缺少解析器时还能采取哪一种动作。必须理解才能保留语义的合法选项，完全可能选择丢弃类。

ICMP 指针把模糊的“IPv6 不通”缩小到一个字节，但它仍只是一条可能丢失、限速或被过滤的数据包。收到它，只能证明某个节点在某次处理里报告了该类型；没收到，不能证明所有节点都选择了跳过。

multicast 让报告边界显式可见

10 与 11 的差别只落在 multicast 目的地址上：前者仍要报告，后者抑制报告。于是，是否可能为 multicast 失败产生返回流量，不再由每种实现临时猜测，而成为类型的一部分。

运营者仍掌握 ICMP 限速与资源保护，也必须看真实发包计数。类型位揭示应有语义，不会把 multicast 判成攻击，也不会保证错误一定抵达源端。

第三位避免认证一个会变化的假象

第三高位处理的是另一件事。零表示 Option Data 在途中不变，一表示它可能改变。当数据包含有 Authentication Header 时，被标为可变的 Option Data 在计算或验证认证值时按全零字节处理。

这样，协议不会一面允许合法的途中更新，一面又把更新后的字段当作遭到篡改。被排除的范围也很窄：只有声明可变的 Option Data。该位并没有授权任意路由器改写内容；究竟谁能写、如何写，仍由具体选项规范决定。

三个位不是附注，而是完整类型的一部分

RFC 2460 在 1998 年明确指出，最高三位不能从低五位标识中剥离。完整八位共同构成 Option Type。低五位相同、最高位不同的两个编码，不是“同一种选项加不同策略”，而是不同类型。

Hop-by-Hop Options 与 Destination Options 共用这套类型空间，不过具体规范可以限制某个类型出现在哪里。头部中的选项还必须按出现顺序处理；接收端不能跳过前面的未知选项，先执行后面熟悉的选项，再回头决定前者。

顺序保存了因果。如果较早的选项要求丢弃，后面出现一个熟悉字段，不能追认整个数据包为有效。

未知选项不等于未知扩展头

这条边界最容易被写错。处置位存在于已被识别的 Hop-by-Hop Options 或 Destination Options 头内部的 TLV 选项。Next Header 链上出现一个节点完全不认识的扩展头类型，并不会自动获得这些 TLV 语义。

RFC 6564 因此要求：能够用现有 Destination Options 表达的新信息，应优先做成选项；只有确有必要才创建新扩展头。它还给未来扩展头规定了带长度的统一格式，却没有追溯改造所有旧格式。

RFC 7045 又区分了角色。目的主机遇到无法识别的扩展头，应丢弃数据包；普通转发节点不应仅因自己不认识新扩展头就擅自丢弃。若中间设备选择深入检查，它就要持续更新所认识的已注册类型。这与在“已知头部”里读取未知选项的处置位，是两份不同的合同。

中间盒暴露了自描述的极限

防火墙、负载均衡器与高速路由器常要寻找传输层端口或其他字段。较长的头链、新类型与 Hop-by-Hop 处理，可能触发 recirculation、慢路径或控制面负担。

RFC 8200 保留四种动作和可变位，同时不再要求所有转发节点默认处理 Hop-by-Hop Options；节点可以显式配置处理。RFC 9098 记录了设备找不到所需字段时的现实选择：在缺少预期检查的情况下放行、丢弃，或把流量送到更昂贵的处理路径。

三个位无法替设备增加解析深度与芯片预算。它们只保证：一个已经到达该 TLV、并按规范处理它的节点，不必发明未知的后果。

这些位从未授予什么

00 不是放行权，11 不是恶意判决，可变位不是任意改写许可。类型得到注册，不证明整条路径已经支持；返回 ICMP，也不认证发送者身份或意图。

它之所以能协调陌生系统，恰恰因为权限很窄：标准给出共同后果，节点在本地执行，运营者控制资源，运行中的数据包证明真实部署。

来源与证据边界

原始规则见 RFC 1883，完整类型说明见 RFC 2460，现行核心文本见 RFC 8200。新扩展头格式与转发边界见 RFC 6564、7045，运营限制见 RFC 9098。这些文档不证明今天每种产品或网络的支持率与丢包率。