IKEv2 is not IKEv1 with a bigger version number. It is a different protocol, defined in a different RFC, with a different exchange, different state machine, different show commands, and a completely different philosophy about defaults. If you learned IPsec on IKEv1 and you carry those habits across, the first thing that happens is you type show crypto isakmp sa on a working IKEv2 tunnel and get nothing back, and you spend ten minutes convinced the tunnel is down when it has been up the whole time.
This article is part of the PingLabz IPsec VPN cluster. It walks through what actually changed between the two versions, using real output captured from a live CML lab (cat8000v running IOS XE 17.18.02) rather than a spec summary. If you have not read the IKEv1 model yet, start with IPsec explained: the IKE phases, because most of what follows is a comparison against it.
The Exchange: 4 Messages Instead of 9
IKEv1's negotiation is two phases and a lot of packets. Main Mode is six messages to build the IKE SA (three request/response pairs: policy proposal, Diffie-Hellman exchange, then authentication). Then Quick Mode is another three messages to build the IPsec SA that actually carries data. That is nine packets before a single user byte moves, and if you are unlucky enough to be using Aggressive Mode to cut that down, you have traded round trips for a pre-hashed identity sent in the clear.
IKEv2 collapses all of it into two exchanges, four messages total:
The headline is fewer round trips, which matters most on high-latency paths and on hubs terminating thousands of spokes. But the structural wins are the ones you feel in production.
DoS protection is built in. IKEv1 will happily perform an expensive Diffie-Hellman computation for anyone who sends it a packet, which makes it trivially cheap to attack. IKEv2 has a cookie challenge: when the responder is under load and sees half-open SAs stacking up, it replies to IKE_SA_INIT with a stateless cookie and refuses to allocate any state until the initiator echoes it back. A spoofed source address cannot echo anything, so the flood dies at the door.
Delivery is reliable and windowed. Every IKEv2 message carries a message ID, and every request must be acknowledged. That is not decoration, it is visible in the SA. Look at the real output from our lab hub:
HUB#show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 203.0.113.1/500 198.51.100.2/500 none/none READY
Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:19, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/6 sec
CE id: 1001, Session-id: 1
Local spi: 006A65307FBECC85 Remote spi: E0055D1CB14CC870
Status Description: Negotiation done
Local id: 203.0.113.1
Remote id: 198.51.100.2
Local req msg id: 2 Remote req msg id: 0
Local next msg id: 2 Remote next msg id: 0
Local window: 5 Remote window: 5
DPD configured for 0 seconds, retry 0
Fragmentation not configured.
Dynamic Route Update: enabled
Extended Authentication not configured.
NAT-T is not detected
Initiator of SA : Yes
PEER TYPE: IOS-XELocal req msg id, Local next msg id and Local window: 5 are the reliability machinery showing itself. The window means this router can have up to five requests outstanding at once instead of stalling on a strict one-at-a-time lockstep. IKEv1 has no equivalent because IKEv1 has no reliable delivery layer, it just retransmits and hopes.
State Names: QM_IDLE Is Gone, READY Is the New Normal
This is the single most common trip-up when engineers move over, so it gets its own section. IKEv1's healthy steady state is QM_IDLE, meaning "Quick Mode finished and the IKE SA is sitting idle". Here it is from our IKEv1 build:
EDGE1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
198.51.100.2 203.0.113.1 QM_IDLE 1001 ACTIVEIKEv2 has no Quick Mode, so there is nothing to be idle about. Its healthy steady state is READY:
HUB#show crypto ikev2 sa
Tunnel-id Local Remote fvrf/ivrf Status
1 203.0.113.1/500 198.51.100.2/500 none/none READY
Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:19, Auth sign: PSK, Auth verify: PSK
Tunnel-id Local Remote fvrf/ivrf Status
2 203.0.113.1/500 198.51.100.6/500 none/none READY
Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:19, Auth sign: PSK, Auth verify: PSKTwo separate commands, two separate state machines. show crypto isakmp sa only ever shows IKEv1 SAs, and on an IKEv2-only router it returns an empty table. That empty table is not a fault, it is the wrong command. Burn show crypto ikev2 sa into muscle memory, and reach for show crypto session when you want a version-agnostic answer to "is this tunnel up".
Lifetime: 86400 Instead of 3600
The lifetime numbers change too. Our IKEv1 policy pins the IKE SA at an hour:
crypto isakmp policy 10
encryption aes 256
hash sha256
authentication pre-share
group 14
lifetime 3600Our IKEv2 tunnel, with no lifetime configured at all, reports:
Life/Active Time: 86400/6 secThat is 24 hours of SA lifetime and 6 seconds of active time, straight from the detailed SA output above. IKEv2 rekeys are also cheaper than IKEv1's, because CREATE_CHILD_SA can refresh a Child SA (with or without a fresh Diffie-Hellman for perfect forward secrecy) without disturbing the parent IKE SA. In IKEv1, an ISAKMP SA rekey is a full renegotiation.
AEAD and the Mystery of Hash: None
Look again at the SA line: Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None. Engineers see Hash: None and reach for the phone. No integrity? On a VPN?
It is fine. AES-GCM is an AEAD cipher (Authenticated Encryption with Associated Data). It performs encryption and integrity verification in a single pass, producing an authentication tag as part of the ciphertext. There is no separate hash because there is nothing left for a separate hash to do, and bolting an HMAC on top would be wasted CPU. The same thing shows in the Child SA, where the ESP transform reports no HMAC at all:
Child sa:
local selector -> remote_selector
10.20.10.0/0 - 10.20.10.255/65535 -> 10.30.10.0/0 - 10.30.10.255/65535
ESP spi in/out: 0xDC114E8E/0x854355BF
Encr: AES-GCM, keysize: 256, esp_hmac: None
ah_hmac: None, comp: IPCOMP_NONE, mode tunnelYou do not have to take my word for it, because IOS enforces the rule and will tell you so. Configure an incomplete IKEv2 proposal and the router prints this validation hint:
IKEv2 proposal MUST either have a set of an encryption algorithm other than aes-gcm, an
integrity algorithm and a DH group configured or
encryption algorithm aes-gcm, a prf algorithm and a DH group configuredRead that carefully, because it is the AEAD rule stated by the router itself. Two valid shapes for a proposal, and only two:
The PRF becomes mandatory with GCM precisely because the integrity algorithm normally doubles as the key-derivation function. Remove integrity and you have to name a PRF explicitly, which is why our lab proposal reads encryption aes-gcm-256 / prf sha256 / group 19 and nothing else.
The Smart Defaults: IKEv2 Ships Ready to Go
This is the change that most people never notice, and it is the biggest quality-of-life improvement in the protocol. IKEv2 on IOS XE comes with a working default proposal and a working default policy already in the box. You can build a functioning tunnel without ever typing the word "proposal". Here is what is actually sitting there on a fresh router:
HUB#show crypto ikev2 proposal default
IKEv2 proposal: default
Encryption : AES-CBC-256
Integrity : SHA512 SHA384
PRF : SHA512 SHA384
DH Group : DH_GROUP_256_ECP/Group 19 DH_GROUP_2048_MODP/Group 14 DH_GROUP_521_ECP/Group 21
HUB#show crypto ikev2 policy default
IKEv2 policy : default
Match fvrf : any
Match address local : any
Proposal : defaultStop and appreciate that. AES-CBC-256. SHA-512 and SHA-384 for integrity and PRF. Diffie-Hellman groups 19, 14 and 21 (a 256-bit elliptic curve, 2048-bit MODP, and a 521-bit elliptic curve). That is a modern, defensible crypto set that would pass most audits unchanged. The default policy matches any front-door VRF and any local address, which means it applies to every interface without you scoping anything.
Now compare with IKEv1, where there was no default policy worth the name. IKEv1's fallback values were DES for encryption, MD5 for hashing, and Diffie-Hellman group 1 (768-bit). Every one of those is dead. If you forgot to write a policy in IKEv1, the router did not help you, it quietly negotiated garbage. IKEv2 inverted that: the out-of-the-box behaviour is safe, and you have to work at it to be insecure.
The caveat, and it matters. "Good defaults" is not the same as "pin nothing in production". The default proposal is defined by the software image, and a software image changes when you upgrade. If you never write an explicit proposal, then a code upgrade can silently change your negotiated crypto, and on the day a peer at the other end of a partner tunnel does the same thing you get a very confusing outage. The right posture is: rely on the defaults in the lab and for quick proofs of concept, pin an explicit proposal and policy in production so your crypto is a decision you made rather than a decision your vendor made for you. That is exactly what we do in the IKEv2 site-to-site with crypto maps build.
Traffic Selectors: Proxy IDs, Renamed and Rethought
IKEv1 calls the negotiated "what traffic goes in the tunnel" definition a proxy ID, and it is derived from your crypto ACL. A mismatch between the two ends produces one of the great IPsec time-wasters: Phase 1 comes up perfectly, Phase 2 refuses, and the logs mumble about an invalid proposal.
IKEv2 calls the same thing a traffic selector, and prints it plainly in the Child SA:
Child sa:
local selector -> remote_selector
10.20.10.0/0 - 10.20.10.255/65535 -> 10.30.10.0/0 - 10.30.10.255/65535Read that as a range, not a mask: local addresses 10.20.10.0 through 10.20.10.255 (with the port range 0 to 65535 hanging off the end) to remote addresses 10.30.10.0 through 10.30.10.255. Traffic selectors are ranges of addresses, ports and protocols, and IKEv2 lets the responder narrow a selector it cannot fully accept rather than rejecting the whole proposal outright, which removes a whole class of IKEv1 configuration standoffs.
The cleanest way to sidestep selectors entirely is a route-based tunnel, where the selector becomes 0.0.0.0/0 to 0.0.0.0/0 and the routing table decides what gets encrypted. See IKEv2 SVTI configuration for that build.
The Other Wins
DPD configured for 0 seconds, meaning we did not turn the timer on in this lab.NAT-T is not detected without any NAT-T configuration existing. In IKEv1 it was a bolt-on you could disable and break.authentication local pre-share and authentication remote pre-share are two separate lines. The hub can use a certificate while the spoke uses a PSK.Config Anatomy: Four Blocks Instead of Two Lines
IKEv1's crypto config is famously terse: an isakmp policy and an isakmp key, both global. IKEv2 splits the same job into four named objects that you stitch together. It is more typing, and it is worth it, because each object is reusable and scoped instead of global. Here is the mapping, using our lab config:
crypto ikev2 proposalcrypto isakmp policycrypto ikev2 policycrypto isakmp policycrypto ikev2 keyringcrypto isakmp key ... address ...crypto ikev2 profileIn practice the whole thing looks like this, straight from our hub:
crypto ikev2 proposal PLZ-IKEV2-PROP
encryption aes-gcm-256
prf sha256
group 19
crypto ikev2 policy PLZ-IKEV2-POL
proposal PLZ-IKEV2-PROP
crypto ikev2 keyring PLZ-KEYRING
peer SPOKE1
address 198.51.100.2
pre-shared-key PingLabz-IKEv2-PSK-01
crypto ikev2 profile PLZ-IKEV2-PROF
match identity remote address 198.51.100.2 255.255.255.255
identity local address 203.0.113.1
authentication local pre-share
authentication remote pre-share
keyring local PLZ-KEYRINGThe profile is the object that makes IKEv2 scale. It is where identity matching lives (match on an address, an FQDN, a certificate DN), it is where the keyring is bound, and it is what you attach to a crypto map, an IPsec profile, or a virtual-template. IKEv1 had no such abstraction, which is why IKEv1 remote-access designs collapse into a pile of global commands the moment you have more than one class of peer.
Should You Still Run IKEv1?
Only if a peer forces you to. IKEv1 is deprecated, it cannot do AEAD ciphers cleanly, its defaults are dangerous, its NAT handling is an afterthought, and it has no way to push configuration to a peer. Every current Cisco VPN design (FlexVPN, SD-WAN, most modern DMVPN builds) assumes IKEv2. Treat IKEv1 as an interop compatibility mode for old third-party gear, not as a design choice.
Key Takeaways
- IKEv2 is a new protocol, not a revision. Different exchange, different state machine, different show commands, different config objects.
- Four messages, not nine. IKE_SA_INIT plus IKE_AUTH replaces Main Mode plus Quick Mode, with cookie-based DoS protection and reliable, windowed delivery (
Local window: 5in the real SA output). - The state name is READY, not QM_IDLE. And the command is
show crypto ikev2 sa, notshow crypto isakmp sa. An empty ISAKMP table on an IKEv2 router is normal, not broken. - Default IKE SA lifetime is 86400 seconds. Our IKEv1 policy pinned 3600; the IKEv2 SA reports
Life/Active Time: 86400/6 secwith nothing configured. Hash: Nonewith AES-GCM is correct. GCM is AEAD, so encryption and integrity happen in one pass. IOS enforces it: with aes-gcm you must configure a PRF and you must not configure an integrity algorithm.- The defaults are genuinely good. AES-CBC-256, SHA-512/384, DH 19/14/21, matching any fvrf and any local address. You can build a tunnel with zero proposal config. Still pin an explicit proposal in production so a software upgrade cannot change your crypto behind your back.
- Traffic selectors replace proxy IDs, they are ranges rather than ACL-derived masks, and the responder can narrow them instead of rejecting outright.
- The config payload is the sleeper feature. Pushing addresses and routes over IKEv2 is what makes FlexVPN work without a routing protocol.
Next in the cluster: build it for real with IKEv2 site-to-site using crypto maps, move to route-based tunnels with IKEv2 SVTI configuration, then see what the config payload unlocks in FlexVPN explained. For the full picture on tunnel modes, ESP, AH and the rest of the stack, head back to the IPsec VPN pillar.
