IPv6扩展头与分片安全第02页：扩展头架构与解析面深度解构

01 · 基本报头与扩展头链的结构语义

1.1 40字节基本报头：解析面的"锚点"

IPv6基本报头固定为40字节，由8个字段构成：版本（4位，恒为6）、流量类别（8位）、流标签（20位，RFC 6437修订了其使用语义，规定中间节点不应仅依据流标签做转发决策）、载荷长度（16位，不含基本报头自身，包含全部扩展头与上层数据）、下一头部（8位）、跳数限制（8位）、源地址（128位）、目的地址（128位）。取消报头校验和是重要设计决策：链路层错误检测已足够可靠，且中间节点不再需要因TTL递减而重算校验和，代价是中间设备失去了一个"廉价损坏报文判别"信号——校验失败的判断被推给了端到端校验（TCP/UDP校验和、ESP认证）。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                       Source Address (128b)                   |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                    Destination Address (128b)                 |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1.2 Next Header链：类型化遍历协议

扩展头通过Next Header字段串成链：每个头部的第一字节（或等价字段）声明其后继类型，直到遇到一个"非扩展头"的IANA协议号（如TCP=6、UDP=17、ICMPv6=58）或特殊值59（No Next Header，表示其后无任何内容）。IANA维护专门的"IPv6 Extension Header Types"注册表（RFC 8200 §4引用），当前登记的扩展头包括：逐跳选项（0）、路由（43）、分片（44）、认证AH（51）、目的选项（60）、ESP（50，注意ESP载荷为密文，其后的"Next Header"位于ESP尾部，属于特例）、移动头（135，RFC 6275）等。解析器必须沿链遍历——链每多一跳，中间设备的解析状态就深一层，这是所有"链长类"歧义与拒绝服务面的结构性根源。

1.3 推荐顺序与容错要求的张力

RFC 8200 §4.1给出推荐顺序：IPv6头→逐跳选项头→（路由头前的）目的选项头→路由头→分片头→AH→ESP→（最终目的）目的选项头→上层头。每种扩展头至多出现一次，目的选项头至多两次（路由头前后各一次）。但紧接着规范要求：节点"必须接受并尝试处理任意顺序、任意次数出现的扩展头"（仅逐跳选项头被限制必须紧跟IPv6头）。这一组合的实际含义是：发送端有推荐约束，接收端有容错义务——攻击者发出的乱序/重复链虽不"合规"，却必须被设备认真处理，设备之间的认真程度差异即解析差异。

02 · 逐跳选项头（Hop-by-Hop Options，NH=0）

逐跳选项头是唯一要求路径上每个节点处理的扩展头（RFC 8200 §4.3），格式为Next Header（8位）＋Hdr Ext Len（8位，以8字节为单位、不含首8字节）＋TLV选项区。其结构与前述"中间设备免解析"的转发模型直接冲突：规范要求处理，而工程上多数路由器为避免慢路径转发，对普通逐跳选项采取跳过策略（仅少数选项如Router Alert进入慢路径）。这一"规范—实现"落差本身即是研究对象。

2.1 现实承载的选项

03 · 路由头（Routing Header，NH=43）：从RH0废弃到SRv6复活

3.1 家族谱系与废弃史

路由头允许源节点指定报文途经的一个或多个中间目的地址（松散源路由的IPv6形态），由Segments Left字段驱动逐跳更新。其类型0（RH0）支持任意地址列表，2007年被发现可构造路由环路放大攻击（报文在两个节点间反复转发，每轮均向目标发回流量）——Biondi与Ebalard在CanSecWest 2007披露后，IETF以RFC 5095（2007年12月）将其废弃，RFC 5871（2010年5月，《IANA Allocation Guidelines for the IPv6 Routing Header》）收紧了路由头类型的分配规则。随后移动IPv6引入类型2路由头（RH2，RFC 6275），仅允许单个家乡地址且限定使用场景。

3.2 SRv6：路由头的当代形态

段路由架构SRv6（RFC 8402，2018年）令路由头重新成为主流载荷：段路由头SRH（RFC 8754，2020年）定义为路由头类型4，携带SID栈与标签。安全关注点随之更新：①SID栈即攻击面清单——栈深度、最后条目语义、SRH与分段/ESP的组合处理；②中间设备对SRH的解析深度决定其对SRv6流量的可见性；③RFC 8754 §4.3专门讨论了SRH相关的安全考虑（如未认证模式下对SID的篡改与重定向）。对未部署SRv6的组织，路由头类型4应整体评估后过滤——这是"按业务白名单"原则的直接应用。

04 · 分片头（Fragment Header，NH=44）

分片头为固定8字节结构，是分片机制的载体，详见第3页的机制剖析。此处强调其解析语义：每个分片都携带完整分片头；重组以（源地址、目的地址、Identification）三元组关联。由于分片头按推荐顺序位于路由头之后、AH/ESP之前，其前可以叠加逐跳/路由头——"每分片首部"要求这些头部在每个分片中重复出现，这是IPv6分片与IPv4的关键结构差异，也是中间设备提取五元组前必须完成的解析工作量来源。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Identification (32b)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

分片头格式（RFC 8200 §4.5）：偏移量以8字节为单位（13位）、M位标记后续是否还有分片、32位Identification用于关联同一数据报的所有分片。所有分片（除最后一片）的载荷必须是8字节整数倍——这一对齐约束是构造微小分片时必须绕开的边界条件。

05 · 目的选项头（Destination Options，NH=60）与双重身份

目的选项头有两种位置语义（RFC 8200 §4.1注1/注3）：位于路由头之前时，由"IPv6目的地址字段中的第一个目的节点＋路由头列出的后续目的节点"处理；位于最终上层头之前时，仅由最终目的处理。同一类型号承载两种语义，是解析歧义的典型来源——中间设备若不做位置感知，对同一选项的合法性判定可能出错。当前最重要的现实承载是RDNSS/DNSSL选项（RFC 8106，2017年）：递归DNS服务器地址通过目的选项头在RA报文中下发——RA报文与目的选项的组合，使得"NDP报文完整性"与"扩展头解析"两条安全线在RA入口处交汇（CVE-2020-16898正是ICMPv6 RA携带RDNSS选项时的解析缺陷）。

5.1 ND报文分片禁令与RA-Guard绕过史（RFC 6980/7113）

扩展头×分片的组合还直接冲击链路层安全机制：RFC 7113（2013年2月）系统记录了以超大目的选项头/分片头绕过RA-Guard的实现缺陷——攻击者构造大尺寸目的选项头将ICMPv6 RA载荷推入后续分片，使执行首分片检查的设备无法识别RA类型，该技法在成文时对现有实现普遍有效；RFC 6980（2013年8月，Gont）从根源封堵：节点不得对NS/NA/RS/RA/Redirect等ND消息使用IPv6分片，且必须静默丢弃任何携带分片头的ND消息——"分片ND报文"从此成为标准定义的非法形态。Linux内核以net.ipv6.conf.*.suppress_frag_ndisc参数落地该禁令（默认开启）。本子课题将"分片ND报文出现率"列为接入层监测信号，与子课题02的RA-Guard/SAVI基线联动核查。

06 · AH/ESP与分片先后次序：加密可见性的终止线

认证头AH（RFC 4302）与封装安全载荷ESP（RFC 4303）虽以IPsec为载体，在报文结构中扮演扩展头角色，其次序规则直接塑造中间可见性：分片只针对"每分片首部"之后的部分——IPv6中隧道模式下ESP封装产生的报文若需再分片，分片发生在ESP处理之后（先封装后分片）；接收端则先重组后解密。次序规则的安全含义：①中间设备对ESP保护的流量只能解析到ESP头，后续内容不可见——IPS/审计设备的可见性边界即在此；②隧道叠加导致外层分片与内层分片嵌套（RFC 4459分析的场景），两层分片的状态机交错，重组复杂度和被操纵空间同步上升；③AH对整个IPv6头链（除可变字段）提供认证，篡改扩展头链将被检出——这既是完整性保障，也意味着AH处理顺序错误（先验后重组/先重组后验的实现差异）本身会成为解析差异源。

07 · 选项类型编码语义：TLV处置的四分岔

逐跳选项头与目的选项头内的TLV选项，其类型字节的最高两位编码了"节点不认识该选项时"的处置动作（RFC 8200 §4.2）：

第三高位指示选项数据是否会在传输途中被修改（改变时需重新计算认证）——AH实现若忽略该位，认证完整性将被破坏。四分岔＋可变位＝选项处理差异的完整类型学空间，一致性测试用例矩阵（第5页）按此展开。

08 · 解析歧义面汇总：六类结构性分歧点

09 · 新兴载荷形态与检测思路

• SRv6/SRH：路由头类型4在运营商骨干真实承载业务流量——"过滤所有路由头"的简单基线已不可行，需转向"按类型白名单＋栈深度上限＋SID语义校验"的组合策略。
• IOAM：带内遥测以逐跳/目的选项承载，路径设备被新增强制解析义务——逐跳面的治理范围从"历史包袱"扩展为"运营依赖"，检测基线需覆盖IOAM字段的合法形态。
• 加密传输普及：QUIC/TLS广泛应用后，扩展头+分片组合成为中间设备对流量进行"元数据级"理解的主要窗口——其解析正确性的战略价值上升，同时构造畸形EH/分片组合作为"流量操纵探针"的动机也上升。

9.1 本页检测基线建议（衔接第5、8页）

• 边界设备对Next Header值43（路由头）按类型白名单处置：未部署MIPv6/SRv6则丢弃类型0/2/4并记录告警；
• 对逐跳选项头实施最小集合策略：仅放行组织确认依赖的选项类型，其余记录并按速率限制；
• 对含目的选项头的非NDP流量记录源地址与选项类型分布，作为测绘与异常检测输入；
• 对扩展头链解析设置明确深度上限（建议与设备能力匹配并在文档化基线中声明），超限报文按"丢弃＋计数"处置并纳入一致性测试。

本节参考来源（第2页）

以下均为真实可查的权威来源，用于支撑本页事实性表述。