IKEv2引入的新特性
在IKE_SA_INIT交换阶段，发起方采用“猜”的办法，猜一个响应方最可能使用的DH组携带在第一条消息中发送。响应方根据发起方“猜”的DH组来响应发起方。如果发起方猜测成功，则这样通过两条消息就可以完成IKE_SA_INIT交换。如果发起方猜测错误，则响应方会回应一个INVALID_KE_PAYLOAD消息，并在该消息中指明将要使用的DH组。之后，发起方采用响应方指定的DH组重新发起协商。这种DH猜想机制，使得发起方的DH组配置更为灵活，可适应不同的响应方。
- IKEv2支持cookie-challenge机制
在IKE_SA_INIT交换中消息是明文传输的，响应方接收到第一个消息后无法确认该消息是否来自一个仿冒的地址。如果此时一个网络攻击者伪造大量地址向响应方发送IKE_SA_INIT请求，根据IKEv1协议，响应方需要维护这些半开的IKE会话信息，从而耗费大量响应方的系统资源，造成对响应方的DoS攻击。
IKEv2使用cookie-challenge机制来解决这类DoS攻击问题。当响应方发现存在的半开IKE SA超过指定的数目时，就启用cookie-challenge机制。响应方收到IKE_SA_INIT请求后，构造一个Cookie通知载荷并响应发起方，若发起方能够正确携带收到的Cookie通知载荷向响应方重新发起IKE_SA_INIT请求，则可以继续后续的协商过程。
半开状态的IKEv2 SA是指那些正在协商过程中的IKEv2 SA。若半开状态的IKEv2 SA数目减少到阈值以下，则cookie-challenge功能将会停止工作。
为了保证安全，IKE SA和IPsec SA都有一个生命周期，超过生命周期的SA需要重新协商，即SA 的重协商。与IKEv1不同的是，IKEv2 SA的生命周期不需要协商，由各自的配置决定，重协商总是由生命周期较小的一方发起，可尽量避免两端同时发起重协商造成冗余SA的生成，导致两端SA状态不一致。
与IKEv1不同，IKEv2中所有消息都是以“请求–响应”对的形式出现，IKEv2通过消息头中的一个Message ID字段来标识一个“请求–响应”对。发起方发送的每一条消息都需要响应方给予确认，例如建立一个IKE SA一般需要两个“请求-响应”对。如果发起方在规定时间内没有接收到确认报文，则需要对该请求消息进行重传。IKEv2消息的重传只能由发起方发起，且重传消息的Message ID必须与原始消息的Message ID一致。
