| Internet-Draft | IKEv2 Fragments 32 | December 2025 |
| Antony | Expires 11 June 2026 | [Page] |
This document defines an extension to the Internet Key Exchange Protocol Version 2 (IKEv2) that enables the use of a larger number of fragments for IKEv2 messages sent over UDP. The extension allows IKE peers to transmit significantly larger IKEv2 messages during the IKE_AUTH exchange and in any subsequent exchanges where IKEv2 Fragmentation is used. Support for this capability is negotiated using a new Notify Message Status Type during IKE_SA_INIT. When negotiated, peers may exchange additional fragmentation-related notifications, including fragment acknowledgments, to support reliable delivery of larger messages. This extension is intended to facilitate the use of very large IKEv2 payloads, such as those required for post-quantum cryptography (PQC) algorithms, and to improve IKEv2’s ability to support emerging cryptographic methods.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 June 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] uses an unreliable transport (UDP) for message exchange.¶
Originally, IKEv2 messages were small — typically a few hundred bytes to a few kilobytes — such that a simple fragmentation [RFC7383] and retransmission mechanism operating over UDP, without congestion control or partial acknowledgments, was practically sufficient. However, with the introduction of post-quantum cryptographic (PQC) algorithms into IKEv2 [RFC9370], IKE peers are now required to exchange much larger messages than those produced by classical algorithms, often tens of kilobytes and sometimes approaching 64 kilobytes in size.¶
There are also several proposals to extend IKEv2 beyond the 64-kilobyte payload limitation [I-D.nir-ipsecme-big-payload], [I-D.smyslov-ipsecme-ikev2-extended-pld], [I-D.tjhai-ikev2-beyond-64k-limit].¶
This document uses the following terms defined in [RFC7296]: IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, SK_e, SK_a.¶
This document also uses the following terms defined in [RFC9242]: IKE_INTERMEDIATE.¶
This document also uses the following terms defined in [RFC7383]: IKEv2 Fragmentation, Total Fragments,¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Fragments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted content ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Payload (1 octet) - in the very first fragment (with Fragment Number equal to 1), this field MUST be set to the payload type of the first inner payload (the same as for the Encrypted payload). In the rest of the Fragment messages (with Fragment Number greater than 1), this field MUST be set to zero.¶
Fragment Number (4 octets, unsigned integer) - current Fragment message number, starting from 1. This field MUST be less than or equal to the next field (Total Fragments). This field MUST NOT be zero.¶
Total Fragments (4 octets, unsigned integer) - number of Fragment messages into which the original message was divided. This field MUST NOT be zero. With PMTU discovery, this field plays an additional role.¶
This document defines one new registration for the IANA "IKEv2 Notify Message Status Types" registry.¶
| Value | Notify Message Status Type | Reference |
|---|---|---|
| [TBD1] | IKEV2_FRAGMENTATION32_SUPPORTED | [this document] |
ACKs TBD¶
TBD¶
TBD¶