IPv6扩展头与分片安全第03页：分片机制与源端分片模型

01 · 源端分片模型：仅源节点可分片的全部含义

IPv6分片模型与IPv4存在根本差异（RFC 8200 §4.5）：中间路由器不得对转发的报文分片，遇到超过出接口MTU的报文时只能发送ICMPv6 Packet Too Big（Type 2）通知源节点。这一设计把分片节奏的控制权完全收归端系统，其安全含义需要完整理解，而非停留在"中间节点不分片所以更安全"的浅层结论：

• 分片决策的可见性转移：何时分片、按什么尺寸分片，完全由源主机依据其PMTUD状态决定——网络中观察到的分片行为直接反映源端的协议栈状态与路径认知，为指纹识别与异常检测提供了真实信号；
• 重组收敛于终端：重组必须发生在最终目的地，而重组是有状态、耗资源、带超时的操作——攻击面从"沿途所有路由器"收缩为"每个终端协议栈"，收敛不等于缩小，而是更集中的可利用目标；
• 每分片首部冗余：IPv6头＋逐跳选项头＋路由头必须出现在每个分片中，造成带宽开销并扩展了每个分片的解析面；
• 对ICMPv6的绝对依赖：源节点只有收到Packet Too Big才知道需要分片——抑制或伪造该消息直接操纵源节点的分片行为（第6页专论）。

02 · 分片算法与分片头的工程语义

2.1 源节点分片算法（规范级描述）

1. 确定报文的分片边界：每分片首部＝IPv6头＋逐跳选项头＋路由头（如有）；"可分片部分"＝其余扩展头＋上层头＋数据（RFC 8200 §4.5定义）；
2. 按出接口MTU（或PMTUD学到的路径MTU）切分可分片部分，每片（除最后一片）载荷为8字节整数倍；
3. 为所有分片生成相同的32位Identification；首分片偏移置0、M位置1；中间分片M=1；末分片M=0、偏移=前序字节数/8；
4. 每个分片获得独立的IPv6头（跳数限制等字段与原始报文一致）并分别发送。

2.2 分片头的字段级语义要点

• Next Header字段：标识分片头之后的头部类型；只有首分片该字段指向真正的上层头，后续分片指向的是"原报文在此偏移处的头部"——解析器必须结合偏移量理解，这是无状态设备最常见的误解析点；
• Fragment Offset（13位）：以8字节为单位编码，理论编码空间0—8191；受16位载荷长度（最大65535字节）约束，实际可构造的最大偏移量级为8190（本课题以约数表述，不将具体边界值视为规范事实），配合M位可覆盖约64KB（65535字节）载荷——含分片头自身8字节的开销；偏移与M位的组合构成测试矩阵的离散状态空间，每个状态都是一格；
• Identification（32位）：由源节点生成，同一数据报的所有分片共享。RFC 7739指出：若实现采用简单的逐目的或全局递增计数器，ID可被预测——攻击者观测若干分片后即可推测后续数据报的ID区间，为分片注入（第4页）创造先决条件；规范的缓解方向是随机化初始值并采用不可预测的选择机制；
• 保留字段：接收节点必须忽略——与IPv4"保留位必须为0"的演化史类似，保留位曾长期是"高灵敏探针"（IPv4记录路由/安全位历史上被用于指纹识别）。

03 · 重组状态机：有状态即有风险

3.1 状态机要素

重组以（源地址、目的地址、Identification）三元组关联分片。接收协议栈为每个进行中的数据报维护：分片到达位图（bit map，按8字节粒度标记已收区间）、数据缓存、最早分片到达时间（计时起点）、计数器（当前占用缓存的数据报数/总字节数）。状态机的每一步都有对应的资源语义，也各有对应的操纵手法：

3.2 超时参数的事实性说明

RFC 8200未规定重组超时值，常见实现采用数十秒量级（如Linux内核net.ipv6.ip6frag_time默认值为60秒；不同系统、不同内核版本存在差异，且多可通过内核参数调整）。因此：①任何声称"RFC规定60秒"的说法均不严谨；②测量研究在报告具体数值时必须指明系统版本与配置；③防御配置（如Linux的net.ipv6.ip6frag_*参数族——ip6frag_time/ip6frag_high_thresh/ip6frag_low_thresh，及分片ND报文丢弃开关suppress_frag_ndisc，见第2页RFC 6980；BSD系的net.inet6.ip6frag系列）应纳入主机加固基线——在网关/服务器上限制未完成数据报数量与占用字节数，是抵御重组资源耗尽的直接手段。

04 · 分片的成本结构：带宽、CPU与状态

• 带宽开销：每个分片重复40字节IPv6头＋8字节分片头（若带逐跳/路由头则更多）。以路径MTU 1280、发送6000字节载荷为例：可分片部分约5960字节，切分为5片，头部开销总计约240字节——开销占比约4%；MTU越低或首部链越长，占比越高。隧道场景下内外两层头叠加，开销进一步放大（RFC 4459分析的对象）；
• CPU开销：发送端分片为O(n)内存拷贝操作；接收端重组涉及缓存管理、区间合并、校验——重组完成后才能上交上层，恶意高负载分片流可造成不成比例的CPU消耗；
• 状态开销：如3.1节所述，每个未完成数据报都是一份有生命周期的状态——这是分片与普通报文在防御经济学上的本质差异：处理一个分片流所需的状态资源，是其字节量的数倍；
• 丢包放大：任一分片丢失即整体重传（对TCP而言是整个数据报重传，不仅是丢失的分片），高丢包路径上分片传输效率显著恶化——这既是性能事实，也是"高丢包率环境分片率异常"可作为威胁狩猎线索的原因。

05 · 与上层协议的协同：TCP、UDP与DNS

5.1 TCP与MSS协商

TCP通过MSS（最大报文段长度）选项在三次握手时协商每个报文段的上限——MSS本质上就是"对端发送给本端的数据量上限"，合理设置MSS使TCP分段在源头即适配路径MTU，是避免IP分片的主要工程手段。常见实践包括按出接口MTU设置MSS（如1280−40−20）以及在边界实施MSS钳制（MSS Clamping）改写过大MSS——钳制动作本身属于防火墙/路由器的常规基线，但需注意：钳制改的是TCP载荷上限，无法约束UDP等无协商协议，也无法消除隧道叠加场景下的被动分片。

5.2 UDP、DNS与"避免分片"运动

UDP无协商机制，应用层缓冲区决定报文尺寸——DNS是UDP大报文的经典载体。RFC 8900（2020年）系统论证了避免IP分片的必要性并给出EDNS缓冲区建议值（如1232字节以适应隧道叠加的最常见场景）；DNS Flag Day 2019（由多家DNS软件厂商与运营商联合发起）清退了对"截断后回退TCP"的懒惰兼容，其背景正是分片DNS报文的不可靠性。对安全研究而言，DNS over UDP的大报文仍有诊断价值（如路径MTU测量），但应明确：任何依赖IP分片的应用协议设计都已被社区标记为反模式。

5.3 隧道与VPN：分片的二次方

隧道封装为报文追加外层头（IPv6-in-IPv6为40字节，ESP隧道为ESP头＋IV＋ICV等更可观的开销），原报文紧贴MTU时封装后即超限——源端PMTUD若未感知隧道真实MTU，由隧道出口回送的内层PTB（经RFC 4459讨论的信令路径）才能纠正；该过程中可能出现"外层再分片＋内层分片"的双重分片嵌套。RFC 4459（2006年）将此类问题归纳为网络内隧道化的通用MTU课题，其结论今天依然适用：隧道MTU管理（显式配置/PMTUD联动）是数据中心与VPN运营的直接安全事项。

06 · 合法分片的流量指纹：识别基线

上述指纹的检测落点：NetFlow/IPFIX可导出分片标记位与ID（字段依实现而异），逐包深度检测需Suricata/Snort类引擎或专用探针；对"合法形态"的刻画应以本组织真实流量为基准自学习，表中描述为通用参考而非阈值标准。

07 · 分片流量的监测思路（衔接第5、8页）

• 比例基线：分片报文占比、分片数据报平均片数、分片协议分布（TCP/UDP/ICMPv6）——偏离基线即告警；
• 异常模式匹配：微小分片、重叠偏移、多末片、首分片不完整——四类模式的检出规则可直接对应第4页滥用模式清单；
• 资源侧监测：终端/网关的重组槽位占用、分片丢弃计数、重组超时计数——资源耗尽攻击往往先在计数器上显形；
• 关联分析：分片风暴与PTB消息异常（第6页）的时序关联——伪造PTB诱发原子分片的攻击链在流量侧呈现"PTB突增→分片形态突变"的耦合特征。

本节参考来源（第3页）

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