he functionalities defined in IKEv1 and Internet security association and key management protocol (ISAKMP) while removing unnecessary processes. It eliminates the generic character of the previous version, integrating the domain of interpretation (DOI) function, which defines the parameters specific to the ESP/AH security association. Each IKEv2 message is composed of a header (HDR) and a sequence of blocks. The IKEv2 message is encapsulated by a UDP header with source and destination port values of 500 or 4500. When the 4500 port is used, the IKEv2 message is preceded by four bytes at ZERO. Wi-Fi Integration to the 4G Mobile Network 7.1.2.1. Message header The header of the IKE message contains the following fields (Figure 7.5): IKE SA Initiator's SPI IKE SA Responder's SPI Next Payload MnVer Exchange Type Flags Message ID Length Figure 7.5. IKE message header format Initiator's SPI: this field, coded on eight bytes, incorporates a value chosen by the initiator. It initializes identification of the IKE security association. Responder's SPI: this field, coded on eight bytes, incorporates a value chosen by the responder. It completes the identification of the IKE security association. Next Payload: this field, coded on one byte, incorporates the indication of the type of block following the header (Table 7.1). Major Version: this field, coded on four bits, indicates the maximum value of the IKE protocol version that can be used. This value is equal to 2 for the implementation of the IKEv2 protocol. Minor Version: this field, coded on four bits, indicates the minimum value of the IKE protocol version. This value is equal to 0 for the implementation of the IKEv2 protocol. SWu Tunnel Establishment Exchange Type: this field, coded on one byte, indicates the type of exchange to which the message belongs: - IKE_SA_INIT: this exchange concerns the first phase of the establishment of the IKE security association; - IKE AUTH: this exchange concerns the second phase of the establishment of the security association; - CREATE