4. Existing Solutions (既存のソリューション)

4.1. IPsec Tunnel Mode (IPsec トンネルモード)

限られた状況では, [DHCP] で説明されているような IPsec トンネルモード実装が NA(P)T を正常にトラバースすることが可能です。ただし, 正常なトラバーサルの要件は十分に制限されているため, より一般的なソリューションが必要です:

IPsec ESP。IPsec ESP トンネルはメッセージ完全性チェック内で外部 IP ヘッダーをカバーしないため, アドレス変換による認証データの無効化に悩まされません。IPsec トンネルもチェックサムの無効化を心配する必要はありません。
アドレス検証なし。現在のほとんどの IPsec トンネルモード実装は送信元アドレス検証を実行しないため, IKE 識別子と送信元アドレスの間の非互換性は検出されません。これはセクション 5 で説明されているセキュリティ脆弱性を導入します。
"Any to Any" SPD エントリ。IPsec トンネルモードクライアントは "any to any" SPD をネゴシエートでき, これはアドレス変換によって無効になりません。これにより, 許可されたトンネルトラフィックのフィルタリングに SPD を使用することが事実上排除されます。
シングルクライアント動作。NAT の背後に1つのクライアントのみがある場合, SPD の重複のリスクはありません。NAT は競合するクライアント間で調停する必要がないため, 鍵の再生成の誤変換や不適切な着信 SPI またはクッキーの逆多重化のリスクもありません。
フラグメンテーションなし。証明書認証が使用される場合, IKE フラグメンテーションに遭遇する可能性があります。これは証明書チェーンが使用される場合, または鍵サイズまたは他の証明書フィールド (識別名や他の拡張など) のサイズが十分に大きい場合に単一の証明書を交換する場合でも発生する可能性があります。ただし, 認証に事前共有鍵が使用される場合, フラグメンテーションの可能性は低くなります。
アクティブセッション。ほとんどの VPN セッションは通常, その生涯中に継続的なトラフィックフローを維持するため, UDP ポートマッピングが非アクティブのために削除される可能性は低くなります。

4.2. RSIP

[RSIP] および [RSIPFrame] で説明されている RSIP には, [RSIPsec] で説明されているように IPsec トラバーサルのメカニズムが含まれています。ホスト-NA(P)T 通信を可能にすることで, RSIP は IPsec SPI の逆多重化および SPD の重複の問題に対処します。したがって, 企業およびホームネットワークシナリオでの使用に適しています。NAT の背後にあるホストが NA(P)T (RSIP ゲートウェイ) の外部 IP アドレスを共有できるようにすることで, このアプローチは埋め込み IP アドレスを含むプロトコルと互換性があります。

IKE および IPsec パケットをトンネリングすることで, RSIP は IKE および IPsec プロトコルへの変更を回避しますが, ホスト IKE および IPsec 実装を RSIP 互換性のために改造するには大きな変更が必要です。したがって, すべての既存のプロトコル (AH/ESP) およびモード (トランスポートおよびトンネル) と互換性があります。

IKE 鍵の再生成の逆多重化を処理するために, RSIP は IKE 送信元ポートのフロートとフロートされたポートへの鍵の再生成を必要とします。その結果, 既存の IPsec 実装との相互運用性は保証されません。

RSIP は IPsec-NAT 互換性ソリューションの展開要件を満たしていません。これは, RSIP 対応ホストが別のホストと IPsec SA を確立するために対応する RSIP 対応ゲートウェイを必要とするためです。RSIP はクライアントとルーターのみへの変更を必要とし, サーバーへの変更を必要としないため, IPv6 よりも展開が困難ではありません。ただし, ベンダーにとって RSIP の実装には IPv6 サポートに必要なリソースのかなりの部分が必要です。したがって, RSIP は長期的な時間スケールで "過渡的な" 問題を解決しますが, これは有用ではありません。

4.3. 6to4

[RFC3056] で説明されている 6to4 は, IPsec-NAT トラバーサルソリューションの基礎を形成できます。このアプローチでは, NAT は IPv6 ホストに NAT 外部 IPv4 アドレスから派生した IPv6 プレフィックスを提供し, 他の 6to4 ホストまたは 6to4 リレーへの送信のために IPv6 パケットを IPv4 にカプセル化します。これにより, IPsec を使用する IPv6 ホストが IPv6 または 6to4 クラウド内の他のホストと自由に通信できます。

6to4 は単一の NA(P)T がクライアントと VPN ゲートウェイを分離する場合にエレガントで堅牢なソリューションですが, 普遍的に適用できるわけではありません。6to4 は IPv6 プレフィックスの形成を許可するために NA(P)T にルーティング可能な IPv4 アドレスの割り当てを必要とするため, クライアントと VPN ゲートウェイの間に複数の NA(P)T が存在する場合は使用できません。たとえば, 外部インターフェイスにプライベートアドレスを持つ NA(P)T は, その背後のクライアントが 6to4 を介して IPv6 プレフィックスを取得するために使用できません。

6to4 はすでに IPv6 をサポートしているホストからの追加サポートをほとんど必要としませんが, 6to4 をサポートするためにアップグレードする必要がある NAT への変更を必要とします。その結果, 6to4 は短期的な展開には適していない可能性があります。