Why is IKEv2 better than IKEv1? Give concrete differences.
Show the answer
Say this first
IKEv2 does the job in four messages instead of six plus three. NAT traversal and dead peer detection are built in instead of bolted on. It has cookies against DoS floods, EAP for remote-access user authentication, asymmetric authentication (each side may use a different method), reliable request-response exchanges, and traffic selector narrowing. Lifetimes are not negotiated, each peer rekeys on its own timer, which removes a class of mismatches.
Go deeper
| Topic | IKEv1 | IKEv2 |
|---|---|---|
| Messages to the first IPsec SA | 9 (main + quick) or 6 (aggressive + quick) | 4 |
| NAT traversal | extension, RFC 3947 | built in |
| Dead peer detection | extension, RFC 3706 | built in liveness check |
| Remote-access user auth | XAUTH, vendor extension | EAP, standard |
| Authentication method | same on both sides | can differ per side |
| DoS protection | none | cookies |
| Lifetimes | proposed in negotiation | local only |
| Selector mismatch | fails | responder can narrow |
| Mobility | none | MOBIKE (RFC 4555) |
Both use UDP 500 and 4500. They are different protocols: a v1 peer and a v2 peer cannot form a tunnel with each other, so both ends must be configured for the same version.
They will ask next
What is traffic selector narrowing?
The initiator proposes a range and the responder may answer with a smaller subset it accepts, instead of failing. IKEv1 has no clean way to do this, which is why mismatched proxy IDs fail hard there.
Does IKEv2 ever run over TCP?
The standard transport is UDP. RFC 9329 (which replaced RFC 8229) defines carrying IKE and ESP over TCP for networks that block UDP, and some vendors support it as an option, but it is the exception.
Traps
- Saying IKEv2 is "IKEv1 with stronger ciphers". The ciphers are the same; the protocol design is what changed.