课题研究 IPv6演进安全 子课题05 · 第6页 / 共8页
05子课题 · IPv6扩展头与分片安全

IPv6扩展头与分片安全第06页：PMTUD信任模型与ICMPv6滥用

PMTUD是IPv6分片行为的"启动开关"，而其控制消息ICMPv6 Packet Too Big在协议上无认证——一个可被链路旁路者伪造的报文，直接决定发送方的报文尺寸与分片行为。本页给出PMTUD的精确机制语义（1280字节底线、PTB载荷引用规则、错误消息不得分片），剖析信任链上的三个脆弱假设，系统梳理四类操纵模式：压制MTU的隐蔽性能DoS、抑制PTB的经典黑洞、诱发原子分片（已被RFC 8021源头封堵的历史案例）、PTB×分片的资源耦合消耗。配套PMTUD黑洞诊断矩阵、PLPMTUD（RFC 4821）/DPLPMTUD（RFC 8899）验证式替代路径、DNS Flag Day 2019的集体教训，以及五组可落地的检测规则思路。

PMTUDPacket Too BigICMPv6伪造TCP黑洞RFC 1981RFC 4890RFC 5927RFC 8021PLPMTUDDPLPMTUDRFC 8899DNS Flag Day
所属专题互联网基础设施安全 › IPv6演进安全
目标受众网络与安全架构师、SOC与蓝队、红队与攻防演练团队、IPv6演进负责人
全文结构8页：总览 → 扩展头架构 → 分片机制 → 重叠与原子分片 → 中间设备基线 → PMTUD信任滥用 → 威胁建模清单 → 治理路线
‹ 上页：第05页 中间设备处理基线与一致性测试
子课题分页12345678
下页：第07页 威胁建模与攻击面清单 ›

01 · PMTUD协议机制：精确语义

路径MTU发现（RFC 1981配套RFC 8200 §5）的运行机制：①源节点以出接口MTU（或此前学到的路径MTU）发送报文；②路径某路由器发现报文超过出接口MTU时，丢弃报文并回送ICMPv6 Packet Too Big（Type 2，Code 0），报文载荷中携带"本机出接口MTU"值；③源节点收到后将该路径MTU记录于目的地址缓存并缩小后续报文尺寸；④若MTU降至最小值1280字节仍不通，协议放弃（IPv6不允许低于1280的分片）。

1.1 三个常被忽略的机制细节

  • 1280字节底线：所有链路必须支持1280字节；节点收到通告MTU<1280的Packet Too Big时，应将其视为无效并按1280处理——RFC 8021将此明确为拒绝原子分片生成的规范依据（第4页）；
  • PTB的载荷引用规则：RFC 4443要求ICMPv6错误消息尽可能多地引用引起错误的原始报文载荷（RFC 4884放宽了上限），使接收方能够将PTB与具体数据报关联——这一"引用"特征既是协议正确性的要求，也是伪造PTB时的鉴别素材；
  • PTB本身不得被分片：ICMPv6错误消息应以尽量小的报文发送（RFC 4443 §2.4），实践中不超过1280字节——观察被分片的ICMPv6错误消息本身即是异常信号。
# 观测路径MTU的常用诊断手段（诊断用途示例）
ping -6 -M do -s 1400  目标地址      # DF位等价物：IPv6下不分片位恒有效
tracepath6 目标地址                    # 路径MTU逐跳测量
tcpdump -ni 接口 'icmp6 and ip6[40] == 2'   # 捕获Packet Too Big（Type=2）

02 · 信任假设分析：无认证的报文如何驱动发送行为

PMTUD的安全困境是结构性的：一个无认证的、可被链路旁路者伪造的控制消息，直接决定发送方的报文尺寸与分片行为。信任链上有三个脆弱假设：

脆弱假设现实防御含义
"PTB来自真实路径上的路由器"协议无源认证；旁路攻击者可伪造PTB（仅需猜测目标会话的五元组与序列特征，对UDP等无状态协议更易）主机侧校验PTB载荷引用是否与在途数据报匹配；边界侧监测PTB速率与来源分布
"PTB中的MTU值可信"伪造者任意填写；极小值（<1280）按规范应被忽略——但依赖实现合规核查协议栈对MTU<1280通告的处置（RFC 8021基线）
"过滤ICMPv6错误消息是安全的"过度过滤PTB＝制造PMTUD黑洞：TCP连接在发送大包时静默挂起（经典"TCP黑洞"在IPv6下同样成立）RFC 4890基线：PTB不得过滤；监测"PMTUD失败率"作为配置健康指标

TCP对ICMP错误的处理硬化是IPv4时代沉淀的通用经验（RFC 5927系统梳理过针对TCP的ICMP攻击面）：现代TCP实现对PTB中引用的载荷做一致性校验、对频繁MTU变化做速率限制，但UDP/QUIC以外的无状态协议缺乏同等保护——协议的受保护程度与其状态性成正比，这是评估具体业务PMTUD风险分级的实用标尺。

03 · 攻击谱系：四类PTB操纵模式

模式机理（概念层）典型后果
A1 压制MTU（性能DoS）向通信双方持续伪造PTB，将路径MTU压至1280底线连接仍可用但报文尺寸被强制减半以下，吞吐劣化——隐蔽、难以与真实路径问题区分
A2 抑制PTB（黑洞）攻击者丢弃路径上的真实PTB（或网络误配置过滤了PTB）TCP大包静默丢失、连接挂起；UDP大报文永久不通——"TCP黑洞"的IPv6形态
A3 诱发原子分片（已历史性封堵）伪造极小MTU的PTB，诱使实现进入原子分片生成路径（RFC 6946旧逻辑）开启分片注入攻击链（第4页）；合规实现（RFC 8021）在源头即免疫
A4 PTB×分片资源耦合伪造PTB迫使源端以小MTU分片发送，分片数量成倍增加，接收端重组资源消耗同步放大资源消耗型DoS的"合法流量外衣"——每个分片本身都符合规范
A1压制MTU攻击链（概念示意）
旁路攻击者只需伪造ICMPv6，即可持续劣化双向吞吐
说明：机理为RFC 1981信任模型的公开弱点与RFC 5927所述ICMP攻击面的交叉；检测依赖PTB来源核验与速率异常分析，而非协议本身提供认证。

与原子分片的关系：A3与第4页的原子分片注入链共享第一步（伪造PTB）。RFC 8021封堵了"生成侧"路径后，攻击重心转向A1/A2/A4——它们不需要协议栈漏洞，只需要网络对PTB的无鉴别接受。防御经济学因此从"打补丁"转向"行为监测与信任边界设计"。

04 · PMTUD黑洞诊断方法

症状排查动作根因判定
TCP小报文通、大包挂起ping -M do递增载荷尺寸定位阈值；tracepath6逐跳测量阈值小于预期＝路径MTU异常；大包无PTB回送＝PTB被过滤（A2/误配置）
UDP大报文单向不通双端抓包确认PTB是否生成与到达；检查边界ACL的ICMPv6策略PTB生成但被边界丢弃＝RFC 4890违规；PTB被伪造压制＝A1嫌疑
特定方向/特定时段劣化长期采样路径MTU变化曲线；比对物理链路MTU配置MTU曲线频繁震荡至1280＝A1压制嫌疑；恒定异常＝配置错误
隧道内业务黑洞测量隧道内外MTU差；核查隧道MTU配置与PMTUD联动（RFC 4459）内层PMTUD失效＝隧道未透传PTB或MTU未适配

05 · 加固与替代：从信任到验证

  • PLPMTUD（RFC 4821，2007年）：分组化层路径MTU发现——TCP/传输层主动探测真实可通尺寸，不依赖ICMPv6：以探测报文的实际成败判定PMTU，天然免疫伪造PTB的压制与抑制两类攻击。代价是探测开销与收敛速度，TCP实现普遍具备；
  • DPLPMTUD（RFC 8899，2020年）：将PLPMTUD思想推广至UDP类数据报应用（如QUIC内建等效机制），提供标准化的探测算法与状态机——无状态协议的PMTUD加固主路径；
  • MSS钳制与缓冲区基线：边界按路径最小MTU改写TCP MSS、按RFC 8900建议约束DNS等UDP应用缓冲区（1232字节量级）——从源头减少触发PMTUD的需求；
  • PTB透传与核验基线：边界不得过滤PTB（RFC 4890）；同时对PTB实施速率限制与来源分析；主机侧启用对PTB引用载荷的一致性校验（现代TCP默认具备的方向）；
  • 隧道MTU治理：显式配置隧道MTU、确保PTB跨隧道正确传递（RFC 4459）、对隧道内外分片嵌套实施基线监测。

06 · 集体教训：DNS Flag Day 2019与"分片不可靠"共识

2019年2月，多家DNS软件厂商与运营商联合发起"DNS Flag Day"，停止对不规范EDNS实现的迁就——其直接背景之一，正是DNS over UDP依赖IP分片时的普遍不可靠（中间设备对分片与ICMP错误的粗放处置）。RFC 8900（2020年）随后将经验固化为标准建议：DNS实现应主动避免IP分片（EDNS缓冲区建议值1232字节），并在必须传输大响应时优先TCP。对本课题的启示：当一种传输机制的现实可靠性低于协议设计预期时，生态会以"弃用机制"而非"修复中间设备"作为终局答案——PMTUD/分片的治理窗口，正是在此类生态共识形成之前。

07 · 检测规则思路（衔接第8页监测基线）

  • PTB速率与分布基线：按源/目的/接口统计PTB速率，突增即告警；PTB来源地址与宣称MTU值分布建档；
  • MTU行为异常：监测主机路径MTU缓存的长期变化曲线，非物理变更导致的下行跳变（尤其压至1280）标记为A1嫌疑；
  • PTB载荷引用校验：抽样核查PTB引用载荷与内网在途数据报的匹配性——不匹配=伪造强信号；
  • 分片形态耦合：PTB突增与分片形态突变（第3页指纹）的时序关联分析；
  • 黑洞健康指标："PMTUD失败率"（大包重传率、TCP stuck会话占比）纳入网络健康仪表盘，其长期非零即提示A2或误配置存在。

本节参考来源（第6页）

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

[1]

IETF RFC 1981《Path MTU Discovery for IPv6》（1996年8月）：rfc-editor.org/rfc/rfc1981；RFC 8200（2017年7月）§5最小MTU与PTB处理：rfc-editor.org/rfc/rfc8200。

[2]

IETF RFC 4443《ICMPv6》（2006年3月，§2.4错误消息生成规则）：rfc-editor.org/rfc/rfc4443；RFC 4884《Extended ICMP to Support Multi-Part Messages》（2007年4月）。

[3]

IETF RFC 4890《Recommendations for Filtering ICMPv6 Messages in Firewalls》（2007年5月）：rfc-editor.org/rfc/rfc4890；RFC 5927《ICMP Attacks against TCP》（2010年7月）：rfc-editor.org/rfc/rfc5927。

[4]

IETF RFC 8021《Generation of IPv6 Atomic Fragments Considered Harmful》（2017年1月）：rfc-editor.org/rfc/rfc8021；RFC 6946（2013年5月）：rfc-editor.org/rfc/rfc6946。

[5]

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。

[6]

IETF RFC 8900《Avoiding IP Fragmentation in the DNS》（2020年9月）：rfc-editor.org/rfc/rfc8900；DNS Flag Day 2019官方网站：dnsflagday.net/2019。

[7]

IETF RFC 4459《MTU and Fragmentation Issues with In-the-Network Tunneling》（2006年3月）：rfc-editor.org/rfc/rfc4459。

‹ 上页：第05页 中间设备处理基线与一致性测试
子课题分页12345678
下页：第07页 威胁建模与攻击面清单 ›