Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

The Internet Key Exchange Version 2 (IKEv2) fragmentation protocol splits large IKEv2 message into a set of smaller ones, called IKE Fragment Messages. The IKEv2 fragmentation methodology, implemented on Cisco IOS software through the IKEv2 Remote Access Headend feature, is a Cisco proprietary method, which restricts interoperability with non-Cisco peers. The fragmentation is performed only on an encrypted IKEv2 packet, and hence, a peer cannot decrypt or authenticate the message until the peer receives all fragments. The IKE Fragmentation adhering to RFC feature implements the IETF draft-ietf-ipsecme-ikev2-fragmentation-10 document by encrypting packets after fragmentation, enabling interoperability with non-Cisco peers while continuing to support the Cisco proprietary fragmentation method.

Note	By default, IKEv2 fragmentation is disabled, though show run all shows crypto ikev2 fragmentation mtu is 576 B.

Effective with the IKE Fragmentation adhering to RFC feature, the support for the IETF standard fragmentation method is added the IKE_SA_INIT message as a notify payload, while Cisco proprietary Fragmentation method continues to be indicated using the Vendor ID payload in the same IKE_SA_INIT message. When fragmentation is enabled, support for both methodologies is displayed as appropriate in the show crypto ikev2 sa detail command. The maximum transmission unit (MTU) is configured locally and is not negotiated or exchanged along with the messages. After the INIT exchange, the peers in a network configured with either methodology are aware of the authentication method that must be used and whether the AUTH message can be fragmented.

The following is a sample output from device when debug is enabled showing capability negotiation in INIT request message.

*Oct 14 08:45:24.732: IKEv2:(SESSION ID = 0,SA ID = 1):Next payload: SA, version: 2.0 Exchange type: IKE_SA_INIT, flags: INITIATOR Message id: 0, length: 524
Payload contents:
SA Next payload: KE, reserved: 0x0, length: 144
…
Security protocol id: IKE, spi size: 0, type: NAT_DETECTION_DESTINATION_IP
NOTIFY(IKEV2_FRAGMENTATION_SUPPORTED) Next payload: VID, reserved: 0x0, length: 8
Security protocol id: Unknown - 0, spi size: 0, type: IKEV2_FRAGMENTATION_SUPPORTED
VID Next payload: NONE, reserved: 0x0, length: 20

In the above output, the INIT request contains the intiator’s message to a responder indicating support for both IETF standard fragmentation method and Cisco proprietary fragmentation method through the IKEV2_FRAGMENTATION_SUPPORTED and VID values in the message.

The following is a sample output from device when debug is enabled showing capability negotiation in INIT response message.

*Oct 14 08:45:24.732: IKEv2:(SESSION ID = 0,SA ID = 1):Next payload: SA, version: 2.0 Exchange type: IKE_SA_INIT, flags: INITIATOR Message id: 0, length: 524
Payload contents:
SA Next payload: KE, reserved: 0x0, length: 144
last proposal: 0x0, reserved: 0x0, length: 140
…
NOTIFY(IKEV2_FRAGMENTATION_SUPPORTED) Next payload: VID, reserved: 0x0, length: 8
Security protocol id: Unknown - 0, spi size: 0, type: IKEV2_FRAGMENTATION_SUPPORTED <-------- Response, supporting both
VID Next payload: NONE, reserved: 0x0, length: 20 <-------- Response, supporting both

In the above output, the response request contains the responder’s message to the initiator indicating support for both IETF standard fragmentation method and Cisco proprietary fragmentation method through the IKEV2_FRAGMENTATION_SUPPORTED and VID values in the message.

To ensure fragmentation support for older releases having Cisco proprietary fragmentation method, IKEv2 continues to use the Vendor ID along with the IKEv2 notification payload type for the IETF standard fragmentation method. If both fragmentation methods are supported, IKEv2 prefers the IETF standard fragmentation method.

The following table indicates how the fragmentation type is determined based on the capability of peers. CISCO refers to Cisco proprietary fragmentation method and STD refers to the IETF standard fragmentation method.

A packet is fragmented either based on the maximum transmission unit (MTU) value specified in the crypto ikev2 fragmentation command or the default MTU value. IKE messages that only contain the encrypted payload are fragmented. A new payload type—Encrypted and Authenticated Fragment—in the announcement message indicates the fragment number out of the total fragments. This payload is annotated as SKF and the value is 53.

Before the outgoing packet is encrypted, the packet length is checked. The security association established is also verified if the SA is enabled with the IETF standard fragmentation method. The following is a sample output from device displaying the transmission of fragmented packets.

*Oct 16 10:31:22.221: IKEv2:(SESSION ID = 0,SA ID = 3):Next payload: SKF, version: 2.0 Exchange type: INFORMATIONAL, flags: INITIATOR Message id: 1, length: 244
Payload contents:
SKF Next payload: COOP, reserved: 0x90, length: 216 
SKF Fragment number: 1 OF Total Fragments: 3
*Oct 16 10:31:22.222: IKEv2:(SESSION ID = 0,SA ID = 3):Next payload: SKF, version: 2.0 Exchange type: INFORMATIONAL, flags: INITIATOR Message id: 1, length: 244
Payload contents:
SKF Next payload: COOP, reserved: 0x90, length: 216
SKF Fragment number: 2 OF Total Fragments: 3 
*Oct 16 10:31:22.222: IKEv2:(SESSION ID = 0,SA ID = 3):Next payload: SKF, version: 2.0 Exchange type: INFORMATIONAL, flags: INITIATOR Message id: 1, length: 244
Payload contents:
SKF Next payload: COOP, reserved: 0x90, length: 216
SKF Fragment number: 3 OF Total Fragments: 3

The line “SKF Next payload: COOP, reserved: 0x90, length: 216” and “SKF Fragment number: 1 OF Total Fragments: 3” indicate that the message is a Cooperative key server announcement (ANN) packet fragmented into three fragments.

When incoming fragments are received on a responder, each fragment is decrypted and stored temporarily. During defragmentation (assembling the fragments to the original pack), duplicate fragments, fragment numbers outside of total fragment number, and fragments having an entirely different fragment number are dropped. The fragments are added in ascending order of fragment number and not according to the received order), that way, packet assembly is faster. However, out of order fragments are allowed and processed. Each fragment is verified to ensure that all fragments that pertain to a message are received. If all fragments are received, the packet is assembled from the fragments and processed as a newly received message. Acknowledgment (ACK) message is sent when the original packet is assembled, and not for each fragment.

IKEv2 retransmissions happen as prompted by IKEv2 retransmission timers. The fragments once constructed and sent out for the first time, are held in a list, ready to be resent when the retransmission timers are triggered. When a retransmitted request is received, IKEv2 resends the response. The response is resent when the first fragment (#1) retransmission is received. The remaining fragment numbers are ignored, thereby allowing faster processing of the response.

Use the crypto ikev2 fragmentation command to globally enable fragmentation per security association (SA). Fragmentation is enabled on SA when both peers indicate support for fragmentation after INIT exchange on each peers, to be used for IKE_AUTH exchange.

Note	This command was introduced through IKEv2 Remote Access Headend feature and has not changed.

You can specify the maximum transmission unit (MTU), in bytes, using the mtu mtu-size keyword-argument pair. The MTU size refers to the IP or UDP encapsulated IKEv2 packets. The MTU range is from 68 to 1500 bytes. The default MTU size is 576 for IPv4 packets and 1280 bytes for IPv6 packets.

Effective with the IKE Fragmentation adhering to RFC feature, the crypto ikev2 fragmentation command:

• Affects future SAs only and does not affect the existing, old SAs.

• Supports Cisco proprietary fragmentation method and the IETF standard fragmentation method.

The show crypto ikev2 sa detail command displays the following information:

• The fragmentation method enabled on the peer. If the enabled fragmentation method is IETF standard fragmentation, the output displays the MTU, which is in use.

• Whether fragmentation is enabled on both peers or enabled on the local peer only.

The IKE Fragmentation adhering to RFC feature adds support for fragmenting IPv6 packets in IPv6 IKE endpoints when the IETF standard fragmentation method is used. The default MTU value is 1280 bytes and is used when the MTU is not specified in the crypto ikev2 fragmentation command. The MTU used in fragmentation is displayed in the output of the show crypto ikev2 sa detail command.