RFC 機能に準拠した IKE フラグメンテーションから有効。IETF 標準フラグメンテーション方式のサポートが通知ペイロードとして IKE_SA_INIT メッセージに追加されました。一方、シスコ独自のフラグメンテーション方式は、同じ IKE_SA_INIT
メッセージ内で引き続きベンダー ID ペイロードを使用します。フラグメンテーションが有効な場合、両方の方式が show crypto ikev2 sa detail コマンドで適切と表示されます。最大伝送ユニット(MTU)はローカルで設定され、メッセージ間のネゴシエーションも交換も行いません。INIT 交換の後、いずれかの方式で設定されたネットワーク内のピアは、使用する必要がある認証方式と、AUTH メッセージをフラグメント化できるかどうかをを認識します。
次に、デバッグが有効で、INIT 要求メッセージでのネゴシエーション機能を表している場合のデバイスからの出力例を示します。
*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
上記の出力では、メッセージ内の IKEV2_FRAGMENTATION_SUPPORTED および VID 値によって、IETF 標準フラグメンテーション方式とシスコ独自のフラグメンテーション方式の両方をサポートすることを示す、発信側から応答側へのメッセージが
INIT 要求に含まれます。
次に、デバッグが有効で、INIT 応答メッセージでのネゴシエーション機能を表している場合のデバイスからの出力例を示します。
*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
上記の出力では、メッセージ内の IKEV2_FRAGMENTATION_SUPPORTED および VID 値によって、IETF 標準フラグメンテーション方式とシスコ独自のフラグメンテーション方式の両方をサポートすることを示す、応答側から発信側へのメッセージが応答要求に含まれます。