01 · 研究背景与意义
1.1 设计哲学的双刃剑：报头简化与解析复杂度外移
IPv6基本报头被固定为40字节（RFC 8200）：取消中间节点分片、取消报头校验和、取消IPv4式选项字段，可选功能全部移交"扩展头链"（Extension Header Chain）。这一设计为高速转发带来了真实的工程收益——路由器对绝大多数扩展头只需读取Next Header字段继续转发，无需深度解析——但同时把复杂性转移到了报文解析语义上：链中每种扩展头有自己的处理规则、长度编码与顺序约束，链的组合空间在理论上是开放的。安全后果是：不同设备（终端协议栈、防火墙、IPS、负载均衡、NAT64翻译器）对同一条异常报文的解析结论可能不一致，而"解析不一致"正是绕过类攻击（evasion attack）赖以生存的土壤。RFC 8200 §4.1给出了推荐顺序（IPv6头→逐跳选项→[路由头前的]目的选项→路由头→分片头→AH→ESP→[最终目的]目的选项→上层头），并规定每种扩展头至多出现一次（目的选项头至多两次），但同时又要求节点"必须接受并尝试处理任意顺序、任意次数出现的扩展头"——推荐与容错要求之间的张力，是本领域大量歧义面的规范根源。
1.2 三个结构性放大器
- 解析差异放大器：扩展头链长度无协议级上限（Hdr Ext Len字段为8位，但链可嵌套增长）、未知Next Header值的处置（RFC 8200规定应丢弃并发回ICMPv6 Parameter Problem，码1）、未知选项按选项类型最高两位决定"跳过/丢弃/丢弃并报告"——这些分叉点在每一台中间设备上由实现者自行取舍。RFC 7872（2016年，Gont等）对真实互联网的大规模测量证实：携带扩展头的报文遭遇显著高于普通报文的丢弃率，说明"透传"在现实中远未统一实现。
- 重组状态机放大器：IPv6仅源节点可分片（RFC 8200 §4.5），接收方重组。重组是有状态操作：需要缓存分片、维护计时、合并字节区间。有状态即意味着资源消耗与状态操纵空间——重组缓存耗尽、重叠区间合并策略差异、超时语义差异，每一环都可被攻击者直接或间接利用。叠加32位Identification字段在部分实现中的可预测性（RFC 7739，2016年，Gont），离线攻击者注入伪造分片的门槛被进一步降低。
- 信任依赖放大器：分片与路径MTU发现（PMTUD）强耦合——IPv6报文超过路径MTU时，源节点依赖ICMPv6 Packet Too Big（Type 2）消息感知并重新分片，而ICMPv6错误消息在协议上无认证、可被链路旁路伪造。RFC 4890（2007年）因此将"不得过度过滤ICMPv6"列为基线，但这也让伪造的Packet Too Big成为可靠的攻击注入面（详见第6页）。历史包袱"原子分片"（Atomic Fragment）正是这一信任链失衡的产物，其生成行为已被RFC 8021（2017年）宣告有害并废弃。
1.3 与IPv4选项/分片的对比定位
| 维度 | IPv4 | IPv6 | 安全研究含义 |
|---|---|---|---|
| 选项承载方式 | 报头内选项字段（最多40字节，实践中极少使用） | 独立扩展头链（每种头长度8字节整数倍，链长开放） | 选项从"稀缺"变为"常态容器"，解析面显著扩大 |
| 分片发起方 | 源节点与中间路由器均可分片 | 仅源节点（中间节点只发Packet Too Big） | 分片节奏完全由端系统决定；路由器不背重组/再分片状态 |
| 最小MTU | 576字节（IPv4规范底线） | 1280字节（RFC 8200 §5强制） | 收到低于1280的MTU通告应按1280处理（RFC 8021明确） |
| 分片标识 | 16位Identification | 32位Identification | 空间扩大但可预测性仍是问题（RFC 7739） |
| 分片偏移粒度 | 8字节单位（13位字段） | 8字节单位（13位字段） | 设计同源；重叠/微小分片类攻击模式在IPv6同样成立 |
| 重组强制性 | 重组普遍实现 | 中间节点不应重组（逐跳选项与路由头构成"每分片首部"必须出现在每个分片中） | 重组集中在终端，终端协议栈成为攻击收敛点 |
| 校验和 | 报头有校验和 | 报头无校验和（依赖链路层与上层校验） | 的中间设备做"损坏报文丢弃"判断的依据减少 |
02 · 事实勘误与高危误配置认知
勘误立场说明：以下五条说法在工程实践中反复出现，其中部分源于对规范的片面阅读，部分源于对IPv4经验的直接平移。本课题以RFC原文为唯一事实依据；凡与下表冲突的二手资料均应视为不可靠来源。另需特别指出：部分网络资料将"RFC 8820"引为"IPv6扩展头发送约束"——经核验，RFC 8820实为《URI Design and Ownership》（BCP 190，与IPv6无关），扩展头处理要求的正确依据是RFC 7045（Transmission and Processing of IPv6 Extension Headers，2013年）。本课题全部页面已按此更正。
| 流传说法 | 事实与依据 |
|---|---|
| "IPv6中间节点不分片，所以分片攻击不存在了" | 错误。RFC 8200只是把分片发起权收归源节点，重组仍然在每个终端协议栈发生；重叠分片、微小分片（Tiny Fragment类）、重组缓存耗尽等攻击模式在IPv6下依然成立，且重组状态集中在端系统使其成为攻击收敛点。RFC 5722（2009年）专门为此禁止重叠分片并要求整包丢弃——恰恰证明该风险真实存在。 |
| "收到Packet Too Big通告MTU小于1280时，应继续按通告值缩小报文" | 错误。1280字节是IPv6最小MTU（RFC 8200 §5）；RFC 8021明确：节点应将低于1280的MTU通告视为无效并忽略，协议栈不得据此生成"原子分片"。原子分片的生成机制已被宣告有害（RFC 8021标题即"Generation of IPv6 Atomic Fragments Considered Harmful"）。 |
| "扩展头是端到端的，中间设备一律透传即可" | 片面且危险。RFC 7045要求传输路由"不因扩展头存在而丢弃报文"，但明确不禁止安全设备按策略过滤；逐跳选项头（Next Header=0）按规范要求路径上每个节点处理——无差别透传等于放弃对已知滥用模式（如RH0残留、异常分片组合）的治理。 |
| "分片头后面的分片不含端口信息，防火墙无法过滤，只能放行" | 错误，属于典型的有状态检查缺失。中间设备应通过Identification字段＋源/目的地址关联同一数据报的所有分片，以首分片提取五元组并建立会话状态，对后续分片执行一致性检查。对"无法提取五元组即放行"的设备，分片即成为标准的过滤绕过通道。 |
| "ICMPv6 Packet Too Big消息应当全部放行，否则PMTUD会失效" | 半对半错，需分级处理。方向上：主机发出的Packet Too Big（作为对收到的超大报文的响应）与进入内网的Packet Too Big（来自外部路由器）性质不同。RFC 4890的基线是不得过滤转发路径上的必要ICMPv6，但并不意味着对伪造的PTB毫无校验——防御方应在边界校验PTB的合法性（载荷引用、源地址为单播且路径可信、速率限制），并监测异常压MTU行为，而非简单"全放行"或"全丢弃"两个极端。 |
实操影响：在基线核查与攻防演练中，"ICMPv6处理一刀切""分片后续包无状态放行""扩展头组合无解析深度限制"长期属于检出率最高的问题类别（定性观察，各组织应以自有核查结果为准）。本课题第8页将上述勘误转化为可核查的配置项。
03 · 研究目标与关键问题
- 机制完备性目标：对扩展头链、分片头、重组状态机、PMTUD信任链建立逐字段、逐分支的规范级语义档案（第2、3、6页），所有结论可回溯至RFC条款。
- 滥用模式覆盖目标：系统覆盖重叠分片、原子分片注入、微小分片、首分片缺失上层头、重组资源耗尽、PTB伪造/抑制、扩展头解析混淆、SRH操纵等滥用模式（第4、6页），每条目含先决条件与检测思路。
- 设备一致性目标：建立中间设备（防火墙/IPS/负载均衡/NAT64/路由器）对异常扩展头与分片组合的处理一致性测试方法学与用例矩阵（第5页），输出可执行的核查清单。
- 落地目标：输出16条目攻击面清单（第7页）、分层治理基线、六步实施路线与6项成熟度评估指标（第8页），服务IPv6规模部署与IPv6-only演进的安全前置。
3.1 三个关键研究问题（KQ）
| 编号 | 关键问题 | 内涵说明 | 对应章节 |
|---|---|---|---|
| KQ-1 | 重组策略多样性测量 | 主流操作系统（Windows/Linux/BSD系）与嵌入式栈对重叠分片、乱序分片、原子分片的重组策略存在哪些可观测差异？这些差异能否构成稳定的远程指纹，或成为绕过特定设备的构造依据？ | 第4、5页 |
| KQ-2 | 中间设备一致性量化 | "异常报文→设备处置（转发/丢弃/告警/重组）"的映射在不同类别设备间的一致率如何测量？一致率低下时，攻击者构造"绕过某设备而触发下游设备误判"的报文矩阵有多大理论空间？ | 第5页 |
| KQ-3 | PMTUD信任链治理有效性 | 在保留必要ICMPv6（RFC 4890基线）的前提下，如何检测并缓解伪造PTB注入与PTB抑制两类攻击？PLPMTUD（RFC 4821）/DPLPMTUD（RFC 8899）在现网的可部署性与兼容性边界如何？ | 第6、8页 |
04 · 生态参与方与领域演进时间线
4.1 生态参与方与职责
| 角色 | 职责/产出 | 代表（均可公开查证） |
|---|---|---|
| 标准组织 | 扩展头与分片机制的本体规范、滥用模式治理、废弃决策 | IETF 6man工作组；RFC 8200/5722/6946/7112/7045/8021/7872/7739 |
| 操作系统厂商 | 协议栈实现质量直接决定解析面与重组面的安全性 | Microsoft TCP/IP栈（MSRC漏洞档案）、Linux内核、各BSD系、嵌入式TCP/IP栈（lwIP等） |
| 网络设备厂商 | 中间设备对EH/分片的转发、过滤、重组、告警行为 | 主流路由交换与安全设备厂商的IPv6特性基线文档（如Cisco关于利用UDF用户定义字段实现IPv6扩展头过滤的技术文档） |
| 安全研究社区 | 滥用模式发现、攻击工具、测量研究 | Fernando Gont（SI6 Networks）系列研究、THC-IPv6工具包（fragment6等）、Chiron IPv6安全评估框架、Scapy社区 |
| 学术测量社区 | EH丢弃率、分片行为、重组策略的大规模测量 | RFC 7872（2016，Gont等）、CAIDA、IMC等学术会议相关论文 |
| 应用与运营商实践方 | SRv6、IOAM等新载荷形态引入新的EH处理需求；DNS运维侧分片规避实践 | SRv6（RFC 8402/8754）、IOAM（RFC 9197）、DNS Flag Day 2019、RFC 8900 |
4.2 领域演进关键时间线
| 时间 | 事件（均可公开查证） |
|---|---|
| 1998 | RFC 2460发布：确立"简化报头+扩展头链+源端分片"架构；定义路由头类型0（RH0）与分片头——RH0的分片叠加滥用隐患随标准一同诞生 |
| 1996—2006 | PMTUD规范RFC 1981（1996年8月）确立IPv6路径MTU发现机制并长期运行；隧道MTU问题分析RFC 4459（2006年3月）系统讨论"网络内隧道化"的分片叠加场景 |
| 2007 | RFC 5095因路由环路放大攻击（Biondi与Ebalard在CanSecWest 2007披露）废弃RH0；RFC 4890给出ICMPv6过滤基线——扩展头与分片的安全治理正式起步 |
| 2009—2010 | RFC 5722（2009）禁止重叠分片并要求整包丢弃；RFC 5927（2010）系统梳理针对TCP的ICMP攻击——分片重组与ICMP信任两条线汇合 |
| 2013 | RFC 6946引入原子分片概念以缓解翻译器场景的PMTUD问题；RFC 7112要求首分片必须包含完整头链与上层头；RFC 7045明确中间设备透传要求；RFC 7113记录RA-Guard的分片绕过并给出实施建议；RFC 6980禁止ND报文使用分片并要求静默丢弃分片ND报文；RFC 7739前的分片ID可预测性研究推进（后于2016年成文） |
| 2016 | RFC 7739（2月）系统论证分片Identification可预测性的攻击含义；RFC 7872（6月）实测真实互联网中携带EH报文的丢弃现象；RFC 8021（1月）宣告原子分片生成有害并废弃——治理重心从"引入新机制"转向"收敛有害机制" |
| 2017 | RFC 8200取代RFC 2460：整合5095/5871/5722/6946/7112/8021全部更新——重叠分片禁止、原子分片不生成、RH0移除成为现行标准的一部分 |
| 2018—2022 | SRv6架构（RFC 8402，2018）与段路由头（RFC 8754，2020）落地，路由头重新成为活跃载荷形态；IOAM（RFC 9197，2022）以逐跳/目的选项承载遥测；DNS侧RFC 8900（2020）系统论证避免IP分片的必要——扩展头从"被治理对象"部分转变为"被运营依赖的基础设施" |
| 2020—2021 | Windows TCP/IP栈因报文解析缺陷连续曝出高危漏洞——IPv6侧：CVE-2020-16898（RDNSS选项解析RCE）、CVE-2021-24086（分片重组路径DoS）；IPv4侧：CVE-2021-24074（源路由选项RCE）——实现解析面风险获得公开实证 |
| 2024 | CVE-2024-38063（Windows TCP/IP IPv6处理整数下溢致堆溢出，CVSS 9.8，无需认证与用户交互）再度印证"扩展头×分片"解析面是内核高危攻击面；IETF 6man工作组推进扩展头处理限值草案（draft-ietf-6man-eh-limits），链长治理进入量化阶段 |
05 · 术语速查与常见误区
5.1 核心术语
| 术语 | 释义（依据RFC 8200及相关规范） |
|---|---|
| 扩展头链（EH Chain） | 位于IPv6基本报头与上层协议头之间的可选头部序列，每个扩展头以Next Header字段（8位）指向下一个头部；IANA"IPv6 Extension Header Types"注册表维护编号 |
| 每分片首部（Per-Fragment Headers） | 分片时原报文中"IPv6头+逐跳选项头+路由头（如有）"的统称，必须出现在每个分片中（RFC 8200 §4.5） |
| 可分片部分（Fragmentable Part） | 其余全部内容（其余扩展头+上层头+数据），由源节点按MTU切分 |
| 原子分片（Atomic Fragment） | 带分片头但偏移=0且M=0的报文（未真正分片）；RFC 6946定义接收处理规则，RFC 8021废弃其生成，RFC 8200不再要求生成 |
| 重叠分片（Overlapping Fragments） | 两个分片覆盖原数据报同一字节区间且内容不同；RFC 5722禁止生成并要求接收方整包丢弃 |
| 微小分片（Tiny Fragment类） | 首分片仅含上层头极少量字节的构造模式，历史上用于让过滤设备无法提取完整五元组（IPv6下受RFC 7112约束） |
| PMTUD | 路径MTU发现：源节点依据ICMPv6 Packet Too Big消息逐跳降低报文尺寸的机制（RFC 8200 §5配套RFC 1981） |
| PLPMTUD / DPLPMTUD | 分组化层PMTUD（RFC 4821）及其数据报演进版（RFC 8899）：不依赖ICMPv6，由传输/应用层主动探测路径MTU |
| 解析一致性（Parsing Consistency） | 两台以上设备对同一异常报文得出一致解析结论（协议识别、五元组、动作）的属性；一致性的缺失即绕过空间 |
| SRH（Segment Routing Header） | 路由头类型4（RFC 8754），SRv6架构（RFC 8402）的报文载体——路由头家族自RH0废弃后最重要的复活形态 |
5.2 常见误区辨析
| 误区 | 辨析 |
|---|---|
| "分片重组超时由RFC规定为60秒" | RFC 8200并未规定重组超时值；常见实现采用数十秒量级（如Linux内核net.ipv6.ip6frag_time默认值为60秒），具体数值依实现、版本与内核参数而异，测量时应以目标环境实测为准，本课题不将任何单一数值视为规范事实。 |
| "32位Identification让分片注入成为不可能" | RFC 7739指出：若实现使用可预测的全局或逐目的计数器，32位空间并不能提供实质保护；建议随机化初始值并避免简单递增模式。攻击可行性取决于实现的ID生成策略，而非字段宽度本身。 |
| "首分片包含完整头链后，防火墙就高枕无忧" | RFC 7112约束的是接收节点行为；中间设备是否实施该约束、是否以首分片五元组建立会话状态并校验后续分片一致性，是设备实现质量的问题——大量设备对分片的处理仍停留在"放行或全丢"的粗放模式。 |
| "扩展头都是历史的包袱，现代网络已经不用了" | 与直觉相反，SRv6（RFC 8754）与IOAM（RFC 9197）使路由头与逐跳/目的选项重新成为运营商网络的活跃载荷；加密传输普及后，扩展头恰是中间设备可见性最高的元数据通道之一——研究价值不降反升。 |
06 · 研究范围与合规边界
- 对象范围：面向企业网、校园网、数据中心与运营商网络的IPv6扩展头与分片处理安全；覆盖终端协议栈、路由器、中间安全设备（防火墙/IPS/WAF/负载均衡）、翻译设备（NAT64/SIIT）四类网络元素。
- 深度边界：做到"机制解构＋滥用模式识别＋一致性测试方法＋治理基线"层面；具体渗透测试操作、无线侧分片（6LoWPAN/RPL逐跳选项的链路层细节）仅作概念性引用，不在本子课题展开。
- 协同边界：NDP/RA层面的报文伪造属子课题02，过渡技术整体治理属子课题03，地址测绘属子课题04，IPv6-only基线属子课题06——本子课题聚焦扩展头与分片本体，跨域攻击链仅作衔接说明。
- 时效声明：所引RFC均为现行有效版本；数据类表述标注来源与统计口径；"约"字数据为区间或约数，不虚构精确测量值。
合规与伦理声明：①本课题为防御研究，遵守《网络安全法》《数据安全法》《个人信息保护法》及相关测评规范；②文中攻击链路仅在概念层面描述原理、先决条件与检测思路，不提供可直接复用的攻击配置与工具操作指引；③主动探测与异常报文测试活动应限定于自有或获得书面授权的网络环境，并控制测试流量速率避免影响生产；④对具体产品/实现的归因结论均标注公开来源（CVE/MSRC等），不构成商业评价。
07 · 与课题体系的协同关系
| 协同子课题 | 数据/方法交换内容 |
|---|---|
| 01 IPv6攻击面与威胁建模 | 对方输出IPv6攻击面清单框架（六大域42条目）与STRIDE适配规范；本子课题的16条清单按其编号规范挂接（AS-EH-xx），并向其"协议解析面"域回填扩展头/分片条目 |
| 02 邻居发现协议（NDP）安全与防护 | RA/NS/NA报文本身可携带目的选项与分片——本子课题的重组与解析基线为其"NDP报文完整性校验"提供报文层输入；对方输出RA-Guard/SAVI部署状态，影响本分片过滤策略设计 |
| 03 双栈与过渡技术安全 | 隧道叠加分片（RFC 4459）、NAT64/SIIT对分片的翻译语义（RFC 7915）属双方交叉区：本子课题定义报文层正确性要求，对方定义部署治理基线 |
| 04 IPv6地址空间测绘与态势感知 | 分片与EH探测是IPv6活跃测量（含指纹推断）的基本报文构造单元；本子课题输出的"合法分片指纹"（第3页）供其探测工具链与识别规则使用 |
| 06 IPv6-only演进安全实践与评估 | 本子课题的一致性测试方法（第5页）与治理基线（第8页）并入其IPv6-only分场景基线；其成熟度框架为本课题成熟度指标提供对齐口径 |
08 · 预期成果与交付物
- 《扩展头与分片机制语义档案》（第2、3、6页：字段级、分支级规范语义，逐条RFC可回溯）
- 《IPv6分片与扩展头滥用模式集》（第4、6页：8类滥用模式，含先决条件/影响/检测思路）
- 《中间设备处理一致性测试用例矩阵》v1.0（第5页：6类差异维度×4级用例分级，含双端验证方法）
- 《IPv6扩展头与分片攻击面清单》v1.0（第7页：16条目AS-EH-01…16＋资产-威胁-控制矩阵）
- 《扩展头与分片治理基线及六步实施路线》（第8页：分层基线、工具生态、成熟度6指标）
本节参考来源（第1页）
以下均为真实可查的权威来源（IETF RFC官方档案、NIST、厂商安全响应中心、权威统计机构），用于支撑本页事实性表述。
IETF RFC 8200《Internet Protocol, Version 6 (IPv6) Specification》（2017年7月，STD 86），§3报头、§4扩展头、§4.5分片、§5最小MTU：rfc-editor.org/rfc/rfc8200。
IETF RFC 5722《Handling of Overlapping IPv6 Fragments》（2009年12月）：rfc-editor.org/rfc/rfc5722；RFC 7112《Implications of Oversized IPv6 Header Chains》（2013年1月）：rfc-editor.org/rfc/rfc7112。
IETF RFC 6946《Processing of IPv6 "Atomic" Fragments》（2013年5月）：rfc-editor.org/rfc/rfc6946；RFC 8021《Generation of IPv6 Atomic Fragments Considered Harmful》（2017年1月）：rfc-editor.org/rfc/rfc8021。
IETF RFC 7045《Transmission and Processing of IPv6 Extension Headers》（2013年12月）：rfc-editor.org/rfc/rfc7045；RFC 5095《Deprecation of Type 0 Routing Headers in IPv6》（2007年12月）：rfc-editor.org/rfc/rfc5095。
IETF RFC 7872《Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World》（2016年6月，Gont等）：rfc-editor.org/rfc/rfc7872；RFC 7739《Security Implications of Predictable Fragment Identification Values》（2016年2月，Gont）：rfc-editor.org/rfc/rfc7739。
IETF RFC 4443《ICMPv6》（2006年3月）：rfc-editor.org/rfc/rfc4443；RFC 4890《Recommendations for Filtering ICMPv6 Messages in Firewalls》（2007年5月）：rfc-editor.org/rfc/rfc4890；RFC 1981《Path MTU Discovery for IPv6》：rfc-editor.org/rfc/rfc1981。
IETF RFC 4821《Packetization Layer Path MTU Discovery》（2007年3月）：rfc-editor.org/rfc/rfc4821；RFC 8899《Datagram Packetization Layer Path MTU Discovery (DPLPMTUD)》（2020年9月）：rfc-editor.org/rfc/rfc8899；RFC 8900《Avoiding IP Fragmentation in the DNS》（2020年9月）：rfc-editor.org/rfc/rfc8900。
IETF RFC 4459《MTU and Fragmentation Issues with In-the-Network Tunneling》（2006年3月）：rfc-editor.org/rfc/rfc4459；RFC 8754《IPv6 Segment Routing Header (SRH)》（2020年3月）：rfc-editor.org/rfc/rfc8754；RFC 8402《Segment Routing Architecture》（2018年7月）：rfc-editor.org/rfc/rfc8402；RFC 9197《In Situ Operations, Administration, and Maintenance (IOAM) Data Fields》（2022年5月）：rfc-editor.org/rfc/rfc9197。
Microsoft安全响应中心（MSRC）：CVE-2020-16898（ICMPv6 RDNSS"Bad Neighbor"，2020年10月修复）、CVE-2021-24074与CVE-2021-24086（2021年2月TCP/IP栈RCE/DoS）：msrc.microsoft.com；CVE官方档案：cve.org。
SI6 Networks技术博客（Fernando Gont）：《A Tale of Bad Decisions, Weird Packets, and DoS Attacks》（2017年1月，原子分片与EH丢弃综合分析）：si6networks.com。