2.2.11.1 Notify Payload

The Initiator role of the IKEv2 protocol can indicate its support of IKEv2 fragmentation and that it allows its use, by including a Notify payload of type IKEV2_FRAGMENTATION_SUPPORTED in the IKE_SA_INIT request message. If the Responder role also supports the fragmentation extension and allows its use, the Responder also includes this notification in its response message. This Initiator/Responder negotiation sequence is specified in section 2.3 of [RFC7383].

The following diagram shows the structure of the Notify payload.


0


1


2


3


4


5


6


7


8


9

1
0


1


2


3


4


5


6


7


8


9

2
0


1


2


3


4


5


6


7


8


9

3
0


1

Next Payload

RESERVED

Payload_Length

Protocol ID

SPI Size

Notify_Message_Type

Next_Payload (1 byte): An identifier for the payload type of the next payload in the message. This field MUST be identical to the corresponding IKE field.

RESERVED (1 byte): This field MUST be set to zero. The responder (2) role MUST ignore this field on receipt. This is identical to IKE version 1 behavior.

Payload_Length (2 bytes): This field MUST be the length in bytes of the payload, including the Generic Payload header. This is identical in IKE version 1.

Protocol_ID_(=0) (1 byte): This field MUST be set to zero. The responder (2) role MUST ignore this field on receipt. This is identical to IKE version 1 behavior.

SPI_Size_(=0) (1 byte): This field MUST be set to zero, meaning that no Security Parameter Index (SPI) is present.

Notify_Message_Type (2 bytes): This field must be set to 16430, which is the value assigned for the IKEV2_FRAGMENTATION_SUPPORTED notification, per [RFC7383].