IKE 分片在加密之前把内容切开，再给每一片单独做加密和完整性保护。片号与总片数各占 16 位，片号从 1 开始，载荷类型是 53。两端都声明支持之后才能用。IKE_SA_INIT 自身不能这样分。规范是 2014 年 11 月的 RFC 7383。这不是 IP 分片。
两端都声明了，才能切
一个可独立引用的定义句：除非两端都表示支持，否则不得使用 IKE 分片。发起方在 IKE_SA_INIT 请求里放入通知 IKEV2_FRAGMENTATION_SUPPORTED；响应方也支持并愿意用时，在应答里放同一条通知（RFC 7383 第 2.3 节、第 2.4 节）。
这条通知没有数据。协议号必须是 0，SPI 长度必须是 0，通知类型必须是 16430。之后，每一次交换是否分片，由该次交换的发起方决定。响应方通常按请求的形式回答，别的考虑可以盖过这一条。
关键词按 RFC 2119 解释。下文的「必须」和「不得」对应原文的大写词。第 2.4 节的几条使用建议是 SHOULD：估计会在 IP 层被拆开时应当使用；本条 IKE SA 上已经用过、且消息大于当前阈值时应当继续用；请求和应答都不像会被 IP 分片时不应当用，例子是存活检查。都不适用时，响应方应当使用与请求相同的形式。原文写，多数情况用在 IKE_AUTH，尤其带证书时。这是 2014 年文本里的「多数情况」，不是 2026 年 10 月对某一客户端的测量。
只有含有加密载荷的消息可以做 IKE 分片。第 2.2 节用小写 must 写：分片消息受密码保护，因此 SK_a 和 SK_e 必须已经算好。由此，IKE_SA_INIT 的消息不能分片。原文补充，这些消息通常不大，但算法列表很长或 MODP 群很大时，仍可能在 IP 层被拆开，这时本文这份机制帮不上。
第 3 节还写了两条例外，依据的是它点名的扩展，这两份扩展的正文本文没有重读。IKE 会话恢复（RFC 5723）的 IKE_SESSION_RESUME 消息不含加密载荷，不能分片。与高可用有关的消息编号同步（RFC 6311）不得以分片发送，原文的理由是这些消息故意共用消息编号 0，接收方要靠内容认重放。
类型号 53 和通知 16430 写在第 6 节的 IANA 考虑里。2026 年 10 月 22 日没有再打开 IKEv2 登记表，核对这两行后来有没有被改掉。
片号和总片数在初始化向量前面
一个可独立引用的定义句：加密分片载荷记作 SKF{…}，类型是 53，也叫加密且已认证的分片。片号和总片数各 16 位，都不得为 0。片号从 1 起，并且必须小于或等于总片数（RFC 7383 第 2.5 节）。
切开的是加密载荷里尚未加密的内容。内容被当成一串字节，不按内层载荷的边界断开。每一块再单独加密和认证。密码处理与 RFC 7296 第 3.14 节相同，算法或模式的更新例如 RFC 5282。这两份的正文本文没有重读，因此不重写初始化向量、填充和完整性校验值各占多少字节。图里的 C 位属于通用载荷头。第 2.5 节的条目没有给它另写一个取值。
若 SKF 出现，它必须是消息里的最后一个载荷。每一片都必须有它。第 2.5.3 节用小写 must 写：极端情况下它可以没有数据，但仍要出现，因为接收方靠它判断对方用了 IKE 分片。未受保护的载荷若将来出现，必须全部放在片号为 1 的那一片里。原文写明，当时没有定义这种同时带两类载荷的交换，IKEv2 也没有禁止。
两处 Next Payload 不是同一个字段：
| 字段 | 片号为 1 | 其余片 |
|---|---|---|
| IKE 头里的 Next Payload | 这一片第一个载荷的类型，多数情况下是 53 | 同样是这一片第一个载荷的类型 |
| SKF 自己的 Next Payload | 必须是原来第一个内层载荷的类型 | 必须是 0 |
| 片号 | 1 | 2 到总片数 |
| 总片数 | 各片相同，不得为 0 | 与第一片相同 |
| 消息编号 | 从原消息原样拿来 | 与第一片相同 |
除了长度和 Next Payload，IKE 头从原消息原样拿来。例子把每一片都写成 HDR(MID=n)。同一条逻辑消息因此共用一个消息编号，再用片号把各片分开。
接收方靠 SKF 的存在认出分片消息。片号或总片数为 0、片号大于总片数，或者重组已经开始而新来的总片数小于已经收下的总片数，都必须静默丢掉。同一消息编号、同一片号、同一总片数已经在队列里，视为重放，也必须静默丢掉。完整性校验值失败，必须静默丢掉。总片数变大且重组尚未完成时，必须丢掉已收下的全部分片，只从这一片重新开始。全部到齐后，把各片解密后的内容拼回原来的加密载荷内容，再按普通 IKE 消息处理。第 2.1 节的顺序是收集、核验、解密、合并。
某一片在超时前没有到齐，必须丢掉这次交换已经收下的全部分片。发起方接着按 RFC 7296 第 2.1 节，或者重传这条已经分片的请求，或者认定 IKE SA 失败并删除。超时次数和长度指向第 2.4 节。响应方则当作没收到请求，不把这当成 IKE SA 失败。响应方的重组超时建议等于它自己当发起方时最终放弃的间隔，也可以更短以省内存。这两节的秒数本文没有重读，因此不引用一个数字。
响应方已经处理完请求并发出应答之后，又收到重传的分片：只有片号为 1 时，这件事才引起应答的重传，而且引起的只能是应答重传；其余片号必须忽略。分片没有逐片确认。应答的各片要等请求的全部分片到齐、拼回并处理成功之后，一起送回。丢掉任意一片，接收方就拼不回原消息。第 4 节因此写，使用分片一般会提高整条消息送不到的概率，实现可以用更长的超时和更多的重传。这是 MAY。
总片数还用来区分下一轮更小的片
路径 MTU 发现在 IKE 里是可选的。原文认为第 2.5.1 节的阈值在多数情况下够用，探测从大往小，和它指向的 RFC 4821 方向相反。本文没有重读 RFC 4821，不把两套步骤合成一套。路径 MTU 探包 写的是用确认试出包长。IKE 这一份只在实现选择做探测时才出现。
探测时，总片数用来区分不同阈值切出来的几套片。后一次更小的阈值必须让总片数真正变大。接收方收到总片数更大的有效分片，就要丢弃旧的一套，重新开始，不能把两套混在一起。
没有路径 MTU 信息时，发往 IPv6 的消息建议把 IP 数据报上限取 1280 字节，引用的是 RFC 2460；发往 IPv4 的建议是 576 字节。两句都是 RECOMMENDED。实现在当前环境合适时可以用别的值。本文没有重读 RFC 2460。同日重读的 RFC 8200 第 5 节仍要求每条链路的 MTU 至少 1280 个八位组，并写明它取代 RFC 2460。RFC 8200 里「引用 2460 的文档应改读本文」只约束它自己引用到的文档，本文不把它自动套到 RFC 7383 的那条引用上。
这里的 576 和 1280 是选择 IKE 分片阈值时对整个 IP 数据报的建议，不是隧道接口要配置的 MTU。隧道那一个数见 VPN 的 MTU。RFC 791 保证下游不再拆开的 IPv4 最小数据报是 68 字节。第 2.2 节写，即使最小的 IKE 分片消息，IP 数据报也大约 100 字节，视算法而定，因此在极小的路径 MTU 上仍可能被 IP 分片。原文把这种路径写成现实中很少见。附录 B 把 IP 数据报长度和加密载荷内容长度对照，本文没有抄那张表。
IP 层怎样认片、在哪重组，见 IP 分片。那一篇的标识和偏移不出现在 SKF 里。
2026 年 10 月 22 日读了 RFC 9242 的摘要，没有读正文。摘要说，中间交换可以使用现有的 IKE 分片机制，而该机制不能用于最初的 IKEv2 交换，从而在 IKEv2 SA 建立之前帮助避免大消息的 IP 分片。元数据里 RFC 9242 没有把 RFC 7383 列为被它更新的文件。本文不描述中间交换的报文格式，也不判断它有没有改写第 2.2 节。
它不改 4500 上的四个 0
非 ESP 标记 写的是：UDP 4500 上，IKE 以四个 0 开头，ESP 直接从 SPI 开始。RFC 7383 没有讨论这四个 0，也没有讨论端口 4500。本文不把 SKF 写成会取消或替代那四个 0，也不把看见类型 53 写成已经发现了 NAT。
重放保护 把 IKE 的消息编号和 ESP 的序列号写成两个计数器。分片加上的是第三组数字：片号和总片数，并且只出现在带 SKF 的 IKE 消息上。ESP 的窗口不读这两个 16 位字段。
第 5 节写了一种占满重组队列的可能：对端在 IKE_AUTH 上送来一大组能通过完整性校验、但始终不齐的分片。建议接收方限制队列里已解密内容的合计长度；不建议这个上限超过 64 KB，因为分片前的 IKE 消息多半短于这个值。超过时应当丢掉连接和已收分片。原文还写，在分片尚未到齐时就按已经拼出的开头采取行动是危险的，必须等全部分片到齐再解析。本文不提供构造这种不完整队列的步骤。
同日的元数据把 RFC 7383 标成 Proposed Standard，没有更新者，也没有把它标成已被取代。勘误检索没有列出条目。
现象对照
| 现象 | 更可能先看什么 |
|---|---|
| IKE_SA_INIT 被 IP 层拆开 | 第 2.2 节写明这一交换不能用 IKE 分片。SK_a 和 SK_e 还没有 |
| 载荷类型 53，片号为 0 | 与「片号不得为 0」不符，必须静默丢掉 |
| 各片消息编号相同，片号从 1 递增 | 符合例子。片号不是另一条 IKE 请求 |
| 总片数突然变大 | 探测下一档更小阈值时应当变大。接收方丢掉旧的一套 |
| 只有片号 2 的重传，应答却又发了一遍 | 与「只有片号 1 才触发应答重传」不符 |
| 目的端口 4500 且前四个字节为 0 | 那是非 ESP 标记一文的范围。RFC 7383 没有写这四个字节 |
核对清单
- 先看有没有 SKF：类型 53 才是 IKE 分片。它必须是最后一个载荷。这不是 IP 分片的标识和偏移；
- 片号从 1 起，总片数不为 0。第一片的 SKF Next Payload 是内层类型，其余片必须是 0。各片共用原消息的消息编号；
- 没有双方的通知 16430 就不得使用。IKE_SA_INIT 不能这样分。576 和 1280 是建议的 IP 数据报上限，不是隧道 MTU；
- 丢一片就拼不回。重传的应答只由片号 1 触发。完整性校验失败必须静默丢掉；
- 四个 0 不在这份规范里。RFC 5723、6311、7296 第 3.14 节和 RFC 9242 的正文没有读。勘误页当日没有条目。