RFC 7383
1. Introduction
▶IKEv2 messages can exceed typical path MTU sizes when carrying certificate chains, multiple proposals, or vendor-specific payloads. IP fragmentation of UDP-encapsulated IKEv2 messages is unreliable — many firewalls and NATs drop IP fragments.
This RFC defines IKEv2-level fragmentation, where the IKE implementation splits encrypted payloads into fragment payloads that fit within the MTU. This is particularly important for 3GPP NDS/IP where certificate chains from operator PKI hierarchies (TS 33.310) can be large.
2. Fragment Format
▶Each IKEv2 fragment is an Encrypted Fragment Payload (SKF) containing:
| Field | Size | Description |
|---|---|---|
| Fragment Number | 2 bytes | 1-based fragment index |
| Total Fragments | 2 bytes | Total number of fragments |
| Fragment Data | Variable | Encrypted fragment of original message |
3. Negotiation
▶IKEv2 fragmentation is negotiated via the IKEV2_FRAGMENTATION_SUPPORTED notification in IKE_SA_INIT:
- Both peers MUST include IKEV2_FRAGMENTATION_SUPPORTED notification to enable fragmentation
- Fragment size SHOULD be set to avoid IP fragmentation (typically 1280 bytes for IPv6, ~1400 bytes for IPv4)
- Only Encrypted Payload (SK) messages are fragmented — IKE_SA_INIT is NOT fragmented
- Fragments are individually encrypted and authenticated using the IKE SA keys
4. 3GPP Relevance
▶IKEv2 fragmentation is important for 3GPP NDS/IP deployments because:
- Large certificate chains: Operator PKI per TS 33.310 may include root CA, intermediate CAs, and end-entity certificates
- Multiple proposals: SEGs may offer many cipher suite combinations for interoperability
- Cross-network paths: Za interface between operators may traverse firewalls that drop IP fragments
- IPv6 adoption: IPv6 path MTU discovery issues make IKEv2 fragmentation essential