The four documents that matter
An IKEv2 post-quantum migration touches four specifications. Knowing which does what removes most of the confusion in vendor documentation.
RFC 7296 defines IKEv2 itself. It is the baseline. RFC 9370 updates it by renaming Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)", which is why older and newer documentation use different names for the same field.
RFC 8784 (June 2020) defines post-quantum preshared keys. An out-of-band symmetric key is mixed into SK_d and the authentication subkeys via a PRF construction. It is an interim mechanism, and the RFC says so in its own abstract.
RFC 9242 (May 2022) defines the IKE_INTERMEDIATE exchange — a general-purpose exchange that runs between IKE_SA_INIT and IKE_AUTH. On its own it does nothing post-quantum. It is the vehicle.
RFC 9370 (May 2023) defines multiple key exchanges, carried in that intermediate exchange. This is the mechanism that lets IKEv2 negotiate a hybrid key establishment without out-of-band key distribution.
The dependency chain matters for assessment: RFC 9370 needs RFC 9242. A platform that has not implemented the intermediate exchange cannot implement additional key exchanges, whatever its release notes imply.
Choosing a mechanism per tunnel
The decision is per tunnel, because it is constrained by the weaker of the two peers.
| Situation | Usual target |
|---|---|
| Both peers support RFC 9370 and RFC 9242 | Additional key exchange, hybrid classical plus ML-KEM |
| Both peers support only RFC 8784 | Preshared key mixing, with a managed distribution and rotation process |
| One peer supports RFC 9370, the other only RFC 8784 | RFC 8784, or upgrade the weaker peer first |
| One peer supports neither, and can be upgraded | Upgrade first, then migrate; two waves |
| One peer supports neither, and cannot be upgraded | Overlay gateway, replacement, or defer and track |
| Peer is partner-controlled | Establish their capability before committing to any target |
| Tunnel is still IKEv1 | Migrate to IKEv2 first. None of these mechanisms exist for IKEv1 |
That last row deserves emphasis. IKEv1 has no post-quantum path. A tunnel still running IKEv1 needs a migration to IKEv2 before post-quantum key establishment is even a question, and that is a separate change with its own risk and its own rollback plan. In most estates a handful of IKEv1 tunnels survive precisely because they terminate on the devices nobody wants to touch.
What "supported" has to mean before a change is approved
A vendor-level statement of support is not sufficient to approve a production change. Before a tunnel goes into a migration wave, five things need to be true and evidenced:
- The exact release on this device implements the mechanism — not the product family, not the latest release.
- The licence in force permits it, where the vendor gates cryptographic features by licence.
- The configuration path the estate actually uses can express it. A setting reachable only by a local CLI edit is not viable across a centrally managed estate of two hundred devices.
- The peer implements the same mechanism, and where the peer belongs to another organisation, their change process is part of your timeline.
- The intended mode can be shown to negotiate, in a lab or on a canary tunnel, before the wave runs.
Any one of those failing turns a routine change into an incident. The fifth is the one most often skipped, and it is the one that catches configuration that is syntactically valid and operationally inert.
Failure modes worth designing against
These are the ones that recur:
- Fragmentation. Post-quantum key material makes IKE messages substantially larger. On paths with reduced MTU, or where an intermediate device mishandles fragments, tunnels establish intermittently rather than failing cleanly. Confirm IKE fragmentation support on both peers before the wave.
- Silent downgrade. A misconfigured proposal that still contains the classical-only option will negotiate the classical option and come up healthy. Nothing alerts. This is why verification reads the negotiated SA rather than the configuration.
- Asymmetric HA members. A cluster whose members run different releases will behave differently after failover. Verify both members, not the active one.
- Rekey behaviour. RFC 9370 introduces IKE_FOLLOWUP_KE for rekeys and additional Child SAs. A tunnel that establishes correctly and then rekeys incorrectly fails hours after the change window closed, when nobody is watching.
Where to go next
To see how this maps onto specific platforms, start with the compatibility matrix. To plan the change sequence, see the post-quantum VPN migration guide. To confirm the result, see verifying a post-quantum VPN migration.