IKE đã được cập nhật lên phiên bản hai (giao thức IKEv2) vào tháng năm 2005 trong ấn phẩm RFC 4306. Một số chi tiết mở được làm rõ vào tháng 10 năm 2006 của RFC 4718. Hai văn bản cộng với làm rõ thêm được kết hợp vào các giao thức IKEv2 cập nhật RFC 5996 được xuất bản vào tháng 9 năm 2010.
Phiên bản 2 của IKE không tương thích với phiên bản 1, nhưng nó có đủ của các định dạng tiêu đề chung mà cả hai phiên bản có thể rõ ràng chạy trên cùng một cổng UDP.
Giao thức IKEv2 được cải tiến hơn so với IKE phiên bản 1. Với IKEv2 các vấn đề sau đây được giải quyết:
• Fewer RFCs: Các chi tiết kỹ thuật cho IKE đã được bảo hiểm trong ít nhất baRFC, nhiều hơn nếu một trong NAT duyệt qua đưa vào tài khoản vàcác phần mở rộng khác được sử dụng phổ biến. IKEv2 kết hợp trong một rfc cũng như cải tiến để hỗ trợ cho NAT traversal và firewall traversal.
• Tiêu chuẩn vận động hỗ trợ: Có một phần mở rộng tiêu chuẩn chocác giao thức IKEv2 (tên MOBIKE) được sử dụng để hỗ trợ di độngvà multihoming cho nó và ESP. Bằng cách sử dụng giao thức IKEv2 này mở rộng và IPsec có thể được sử dụng bởi người dùngdi động và multihomed.
• NAT traversal: Việc đóng gói của IKE và ESP trên UDP port 4500 cho phép các giao thức này đi qua một thiết bị hoặc tường lửa NAT thực hiện.
• SCTP hỗ trợ: các giao thức IKEv2 cho phép cho giao thức SCTP được sử dụng trong điện thoại Internet VoIP.
• Trao đổi thông điệp đơn giản: các giao thức IKEv2 có một trongbốn cơ chế trao đổi thông điệp đầu tiên chứa IKE tám cơ chế trao đổi cung cấp khác biệt ban đầu, mỗi một trong số đó đã có chút lợi thế và bất lợi.
• Ít cơ chế mã hóa: các giao thức IKEv2 sử dụng cơ chế mã hóa đểbảo vệ các gói tin của nó mà rất giống với những gì IPsec
Encapsulating Security Payload (ESP) sử dụng để bảo vệ các góiIPsec. Điều này dẫn đến việc triển khai đơn giản và chứng nhận chochung Tiêu chuẩn và FIPS 140-2, đòi hỏi mỗi thực hiện được mật mã xác nhận một cách riêng biệt .
• Độ tin cậy và quản lý nhà nước: các giao thức IKEv2 sử dụng sốthứ tự và sự thừa nhận để cung cấp độ tin cậy và một số nhiệm vụhậu cần xử lý lỗi và quản lý nhà nước được chia sẻ. IKE có thể kết thúc trong tình trạng đã chết do thiếu các biện pháp tin cậy như vậy,nơi mà cả hai bên đã hy vọng khác để bắt đầu một hành động - màkhông bao giờ eventuated. Công việc ở quanh (nhưDead-Peer-Detection) đã được phát triển nhưng không được chuẩn hóa. Điều này có nghĩa là thực hiện khác nhau của công việcở quanh đã không luôn luôn tương thích
• Khả năng phục hồi khi bị tấn công từu chối dịch vụ DoS: các giao thức IKEv2 không thực hiện nhiều chế biến cho đến khi nó quyết định nếubên yêu cầu thực sự tồn tại. Điều này giải quyết một số vấn đề DOSbị bởi IKE mà sẽ thực hiện nhiều chế biến mật mã đắt tiền từ cácđịa điểm bị giả mạo.