Expiration of Fragmentation Timer

When the fragmentation timer expires, the host SHOULD start fragmenting the message that caused the timer to start. Note that the host does not need to buffer every message for fragmentation purposes because the IKE protocol has provisions for regenerating lost messages.<21>

The fragments MUST be constructed as follows:

  • The Fragment ID counter ADM element is incremented.

  • The IKE message is split into "n" fragments that are numbered 1 to n; the size of each fragment (after adding IP, UDP, and ISAKMP headers) is 576 bytes for IPv4 and 1,280 bytes for IPv6; however, the last fragment, which contains the remainder of the message, can be smaller.

  • IKE does not adjust packet size based on router MTU advertisement; it continues to send packets for IPv4 (576 bytes) and IPv6 (1,280 byes). Therefore, IP-level fragmentation is possible in this case.

  • For each fragment, a message MUST be constructed as follows:

    • The ISAKMP header of the original IKE message has the Next Payload field set to the Fragment payload and the Encrypted flag cleared (as specified in [RFC2408] section 3.1).

    • The Fragment payload header has the following values set:

      • The Fragment ID is set to the current value of the Fragment ID counter ADM element.

      • The Fragment number is set to the current Fragment number, which starts at 1 and is incremented for each fragment,

      • The Flags field is set to LAST_FRAGMENT in Fragment number n.

The fragments MUST be sent back-to-back to the peer.

The only messages that IKE fragments are those that contain the Identification payload, as specified in [RFC2408] section 3.8.