2. IKE プロトコルの詳細とバリエーション
IKE は通常 UDP ポート 500 で待ち受けおよび送信を行うが、IKE メッセージはわずかに異なる形式で UDP ポート 4500 でも受信されることがある（2.23 節参照）。UDP はデータグラム（信頼できない）プロトコルであるため、IKE はその定義に送信エラー（パケットロス、パケットリプレイ、パケット偽造を含む）からの復旧を含んでいる。IKE は、以下の条件が満たされている限り機能するように設計されている。(1) タイムアウトする前に、一連の再送パケットの少なくとも 1 つが宛先に到達すること。および (2) チャネルが、いずれかのエンドポイントのネットワークまたは CPU 能力を使い果たすほどの偽造およびリプレイパケットで満たされていないこと。これらの最小限の性能要件が満たされない場合でも、IKE は（ネットワークが切断されたかのように）きれいに失敗するように設計されている。
IKEv2 メッセージは本来短いことが意図されているが、サイズに厳密な上限のない構造（特にデジタル証明書）を含んでおり、IKEv2 自体には大きなメッセージを断片化する仕組みがない。IP は過大な UDP メッセージを断片化する仕組みを定義しているが、実装によってサポートされる最大メッセージサイズは異なる。さらに、IP 断片化の使用は実装をサービス拒否（DoS）攻撃 [DOSUDPPROT] にさらす。最後に、一部の NAT および/またはファイアウォール実装は IP 断片をブロックする場合がある。
すべての IKEv2 実装は、最大 1280 オクテットの長さの IKE メッセージを送信、受信、および処理できなければならず（MUST）、また最大 3000 オクテットの長さのメッセージを送信、受信、および処理できればよい（SHOULD）。IKEv2 実装はサポートされる最大 UDP メッセージサイズを認識する必要があり、メッセージを最大値以下に保てる場合は、一部の証明書や暗号スイートの提案を省略することでメッセージを短くしてもよい（MAY）。可能な場合は、交換に証明書を含める代わりに "Hash and URL" 形式を使用することで、ほとんどの問題を回避できる。ただし、実装と設定は、URL の参照が Child SA の確立後にのみ可能な場合、再帰の問題によってこの手法が機能しなくなる可能性があることを留意する必要がある。
ポート 4500 で送信される IKE メッセージを含むすべてのパケットの UDP ペイロードは、4 つのゼロのプレフィックスで始まらなければならない（MUST）。そうでない場合、受信側はそれをどう処理すべきかわからない。