Network Working Group B. Aboba
Request for Comments: 3715 W. Dixon
Category: Informational Microsoft
March 2004
IPsec-Network Address Translation (NAT) Compatibility Requirements
IPsecでネットワークアドレス変換（NAT）互換性の要件
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document describes known incompatibilities between Network Address Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses.
この文書では、ネットワークアドレス変換（NAT）とIPsecの間の既知の非互換性について説明し、それらに対処するための要件について説明します。おそらく、IPsecのの最も一般的な用途は、仮想プライベートネットワーク機能を提供することです。仮想プライベートネットワーク（VPN）の1つの非常に人気のある用途は、企業のイントラネットへの在宅勤務者のアクセスを提供することです。今日では、NATのは、広くだけでなく、ホテルなどの在宅勤務者によって使用される可能性が高い他の場所で、ホームゲートウェイに配備されています。その結果は、IPsec NAT-の非互換性は、その主要な用途の一つのIPsecの展開に大きな障壁となっているということです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language. . . . . . . . . . . . . . . . . . 2
2. Known Incompatibilities between NA(P)T and IPsec . . . . . . . 3
2.1. Intrinsic NA(P)T Issues. . . . . . . . . . . . . . . . . 3
2.2. NA(P)T Implementation Weaknesses . . . . . . . . . . . . 7
2.3. Helper Incompatibilities . . . . . . . . . . . . . . . . 8
3. Requirements for IPsec-NAT Compatibility . . . . . . . . . . . 8
4. Existing Solutions . . . . . . . . . . . . . . . . . . . . . . 12
4.1. IPsec Tunnel Mode. . . . . . . . . . . . . . . . . . . . 12
4.2. RSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
9 . Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
Perhaps the most common use of IPsec [RFC2401] is in providing virtual private networking (VPN) capabilities. One very popular use of VPNs is to provide telecommuter access to the corporate Intranet. Today, Network Address Translations (NATs) as described in [RFC3022] and [RFC2663], are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses. This document describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them.
おそらく、IPsecの[RFC2401]の最も一般的な用途は、仮想プライベートネットワーク（VPN）機能を提供することです。 VPNの1つの非常に人気のある用途は、企業のイントラネットへの在宅勤務者のアクセスを提供することです。今日では、ネットワークアドレス変換器（NAT）[RFC3022]と[RFC2663]で説明したように、幅広くホテルなど在宅で使用される可能性がホームゲートウェイでは、だけでなく、他の場所に配備されています。その結果は、IPsec NAT-の非互換性は、その主要な用途の一つのIPsecの展開に大きな障壁となっているということです。この文書では、NATとIPsecとの間の既知の非互換性について説明し、それらに対処するための要件について説明します。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" はならない、[RFC2119]に記載されているように解釈されるべきです。
Please note that the requirements specified in this document are to be used in evaluating protocol submissions. As such, the requirements language refers to capabilities of these protocols; the protocol documents will specify whether these features are required, recommended, or optional. For example, requiring that a protocol support confidentiality is not the same thing as requiring that all protocol traffic be encrypted.
この文書で指定された要件は、プロトコルの提出を評価するのに使用されることに注意してください。そのため、要件の言語は、これらのプロトコルの能力を指し、プロトコルドキュメントは、これらの機能は、必要な推奨、またはオプションされているかどうかを指定します。例えば、プロトコルサポートの機密性は、すべてのプロトコルのトラフィックを暗号化することを要求することと同じものではないことを要求します。
A protocol submission is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the capabilities that it implements. A protocol submission that satisfies all the MUST, MUST NOT, SHOULD, and SHOULD NOT requirements for its capabilities is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT requirements, but not all the SHOULD or SHOULD NOT requirements for its protocols is said to be "conditionally compliant."
それはMUSTの一つ以上を満たすために失敗したか、それが実装する機能のためにはならない要件場合は、プロトコルの提出は準拠していません。すべてのMUSTを満たすプロトコル提案は、と、その機能のための要件は、「無条件に準拠した」と言われてすべきでないてはなりません。すべてのMUSTを満たし、要件はならず、すべてではないSHOULDまたはそのプロトコルのためにはならない要件があると言われて一つの「条件付きで準拠しています。」
The incompatibilities between NA(P)T and IPsec can be divided into three categories:
NA（P）TとIPsecの間の非互換性は、次の3つのカテゴリに分けることができます。
1) Intrinsic NA(P)T issues. These incompatibilities derive directly from the NA(P)T functionality described in [RFC3022]. These incompatibilities will therefore be present in any NA(P)T device.
1）極限NA（P）Tの問題。これらの非互換性は、[RFC3022]に記載のNA（P）Tの機能から直接導き出します。これらの非互換性は、したがって、任意のNA（P）Tデバイス中に存在するであろう。
2) NA(P)T implementation weaknesses. These incompatibilities are not intrinsic to NA(P)T, but are present in many NA(P)T implementations. Included in this category are problems in handling inbound or outbound fragments. Since these issues are not intrinsic to NA(P)T, they can, in principle, be addressed in future NA(P)T implementations. However, since the implementation problems appear to be wide spread, they need to be taken into account in a NA(P)T traversal solution.
2）NA（P）Tの実装の弱点。これらの非互換性は、NA（P）Tに固有ではなく、多くのNA（P）Tの実装で存在します。インバウンドまたはアウトバウンドの断片を処理する際の問題は、このカテゴリーに含まれます。これらの問題は、NA（P）Tに固有ではありませんので、彼らは、原則的に、将来のNA（P）Tの実装で対処することができます。実装上の問題が広く普及ように見えるので、しかし、彼らは、NA（P）T越え溶液中で考慮に入れる必要があります。
3) Helper issues. These incompatibilities are present in NA(P)T devices which attempt to provide for IPsec NA(P)T traversal. Ironically, this "helper" functionality creates further incompatibilities, making an already difficult problem harder to solve. While IPsec traversal "helper" functionality is not present in all NA(P)Ts, these features are becoming sufficiently popular that they also need to be taken into account in a NA(P)T traversal solution.
3）ヘルパーの問題。これらの非互換性は、IPsec NA（P）Tトラバーサルを提供しようとするNA（P）Tのデバイスに存在します。皮肉なことに、この「ヘルパー」機能は、解決することが、すでに困難な問題が難しくなって、さらに非互換性を作成します。 IPsecのトラバーサル「ヘルパー」機能は、すべてのNA（P）Tsの中に存在していないが、これらの機能は、彼らはまた、NA（P）T越え溶液中で考慮する必要があることを十分に普及してきています。
Incompatibilities that are intrinsic to NA(P)T include:
NA（P）Tに固有の非互換性は、次のとおり
a) Incompatibility between IPsec AH [RFC2402] and NAT. Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT or reverse NAT devices making changes to address fields will invalidate the message integrity check. Since IPsec ESP [RFC2406] does not incorporate the IP source and destination addresses in its keyed message integrity check, this issue does not arise for ESP.
A）にIPsec AH [RFC2402]とNATとの間の非互換性を。 AHヘッダが鍵付きメッセージの整合性チェック、NATでIPソースと宛先アドレスを組み込むか、フィールドに対処するために変更を加えるNATデバイスを逆にするので、メッセージの整合性チェックを無効にします。 IPsecのESP [RFC2406]はその鍵付きメッセージの整合性チェックでIPソースと宛先アドレスを組み込んでいないので、この問題は、ESPのために発生しません。
b) Incompatibility between checksums and NAT. TCP and UDP checksums have a dependency on the IP source and destination addresses through inclusion of the "pseudo-header" in the calculation. As a result, where checksums are calculated and checked upon receipt, they will be invalidated by passage through a NAT or reverse NAT device.
b）のチェックサムとNATとの互換性がありません。 TCPとUDPチェックサム計算における「擬似ヘッダ」の包含を介してIP送信元および宛先アドレスに依存しています。チェックサムが計算され、受信時にチェックされ、結果として、それらは、NATを通過させることによって無効化またはNATデバイスを逆転します。
As a result, IPsec Encapsulating Security Payload (ESP) will only pass through a NAT unimpeded if TCP/UDP protocols are not involved (as in IPsec tunnel mode or IPsec protected GRE), or checksums are not calculated (as is possible with IPv4 UDP). As described in [RFC793], TCP checksum calculation and verification is required in IPv4. UDP/TCP checksum calculation and verification is required in IPv6.
TCP / UDPプロトコルは（IPsecトンネルモードやIPsecのようGRE保護）関与しない、またはIPv4 UDPで可能であるようにチェックサムは（計算されない場合、結果として、IPsecのカプセル化セキュリティペイロード（ESP）は、唯一スムーズNATを通過します）。 [RFC793]に記載されているように、TCPチェックサムの計算および検証は、IPv4で必要とされます。 UDP / TCPチェックサムの計算と検証は、IPv6に必要とされます。
Stream Control Transmission Protocol (SCTP), as defined in [RFC2960] and [RFC3309], uses a CRC32C algorithm calculated only on the SCTP packet (common header + chunks), so that the IP header is not covered. As a result, NATs do not invalidate the SCTP CRC, and the problem does not arise.
IPヘッダが覆われないように、ストリーム制御伝送プロトコル（SCTP）は、[RFC2960]及び[RFC3309]で定義されるように、のみSCTPパケット（共通ヘッダ+チャンク）で計算CRC32Cアルゴリズムを使用します。その結果、NATはSCTP CRCを無効にしていない、との問題が生じません。
Note that since transport mode IPsec traffic is integrity protected and authenticated using strong cryptography, modifications to the packet can be detected prior to checking UDP/TCP checksums. Thus, checksum verification only provides assurance against errors made in internal processing.
トランスポートモードのIPsecトラフィックは整合性が強力な暗号化を使用して保護し、認証されているので、パケットへの変更はUDP / TCPチェックサムをチェックする前に検知することができることに注意してください。したがって、チェックサム検証は、内部処理で行われたエラーに対する保証を提供します。
c) Incompatibility between IKE address identifiers and NAT. Where IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the IP source or destination addresses by NATs or reverse NATs will result in a mismatch between the identifiers and the addresses in the IP header. As described in [RFC2409], IKE implementations are required to discard such packets.
IKEアドレス識別子とNAT間c）の非互換性。 IPアドレスは、インターネット鍵交換プロトコル（IKE）フェーズ1 [RFC2409]またはフェーズ2のNATによるIPソースまたは宛先アドレスの変更またはNATの逆は、内の識別子とアドレスとの間の不整合をもたらすで識別子として使用される場合IPヘッダー。 [RFC2409]に記載されているように、IKEの実装は、そのようなパケットを廃棄するために必要とされます。
In order to avoid use of IP addresses as IKE Phase 1 and Phase 2 identifiers, userIDs and FQDNs can be used instead. Where user authentication is desired, an ID type of ID_USER_FQDN can be used, as described in [RFC2407]. Where machine authentication is desired, an ID type of ID_FQDN can be used. In either case, it is necessary to verify that the proposed identifier is authenticated as a result of processing an end-entity certificate, if certificates are exchanged in Phase 1. While use of USER_FQDN or FQDN identity types is possible within IKE, there are usage scenarios (e.g. Security Policy Database (SPD) entries describing subnets) that cannot be accommodated this way.
IKEフェーズ1とフェーズ2の識別子のユーザーIDとFQDNの代わりに使用することができるようにIPアドレスの使用を避けるために。ユーザ認証が望まれる場合、ID_USER_FQDNのIDタイプは、[RFC2407]に記載されているように、使用することができます。マシン認証が望まれる場合、ID_FQDNのIDタイプを使用することができます。いずれの場合においても、それが提案されている識別子が、証明書がフェーズ1で交換されている場合USER_FQDNまたはFQDN同一タイプの使用は、IKE内で可能であるが、エンドエンティティ証明書を処理した結果として認証されていることを確認する必要があり、使用がありますこの方法を収容することができないシナリオ（サブネットを記述する例えばセキュリティポリシーデータベース（SPD）エントリ）。
Since the source address in the Phase 2 identifier is often used to form a full 5-tuple inbound SA selector, the destination address, protocol, source port and destination port can be used in the selector so as not to weaken inbound SA processing.
フェーズ2の識別子の送信元アドレスは、しばしばフル5タプルインバウンドSAセレクタ、宛先アドレス、プロトコル、送信元ポートおよび宛先ポートを形成するために使用されているので、インバウンドSAの処理を弱めないように選択して使用することができます。
d) Incompatibility between fixed IKE source ports and NAPT. Where multiple hosts behind the NAPT initiate IKE SAs to the same responder, a mechanism is needed to allow the NAPT to demultiplex the incoming IKE packets from the responder. This is typically accomplished by translating the IKE UDP source port on outbound packets from the initiator. Thus responders must be able to accept IKE traffic from a UDP source port other than 500, and must reply to that port. Care must be taken to avoid unpredictable behavior during re-keys. If the floated source port is not used as the destination port for the re-key, the NAT may not be able to send the re-key packets to the correct destination.
D）固定されたIKEソースポートとNAPTの間の非互換性を。 NAPTの背後にある複数のホストが同じレスポンダにIKE SAを開始する場合、機構は、NAPTは、レスポンダからの着信IKEパケットを逆多重化することを可能にするために必要とされます。これは、典型的には、イニシエータからの発信パケットにIKE UDP送信元ポートを変換することによって達成されます。したがって、応答は500以外のUDPソースポートからのIKEトラフィックを受け入れることができなければならない、そしてそのポートに返信しなければなりません。ケアは、再キーの間に予期しない動作を避けるようにしなければなりません。浮上ソースポートが再キーの宛先ポートとして使用されていない場合、NATは、正しい宛先に再キーパケットを送信することができないかもしれません。
e) Incompatibilities between overlapping SPD entries and NAT. Where initiating hosts behind a NAT use their source IP addresses in Phase 2 identifiers, they can negotiate overlapping SPD entries with the same responder IP address. The responder could then send packets down the wrong IPsec SA. This occurs because to the responder, the IPsec SAs appear to be equivalent, since they exist between the same endpoints and can be used to pass the same traffic.
e）の重複SPDエントリとNAT間の非互換性。 NATの背後にあるホストが開始フェーズ2つの識別子にそのソースIPアドレスを使用する場合、これらは同じ応答のIPアドレスとSPDエントリを重複し交渉することができます。応答者は、間違ったIPsec SA下りパケットを送信することができます。レスポンダに、IPsecのSAは、彼らが同じエンドポイント間に存在し、同じトラフィックを渡すために使用することができるため、同等であると思われるので、これが発生します。
f) Incompatibilities between IPsec SPI selection and NAT. Since IPsec ESP traffic is encrypted and thus opaque to the NAT, the NAT must use elements of the IP and IPsec header to demultiplex incoming IPsec traffic. The combination of the destination IP address, security protocol (AH/ESP), and IPsec SPI is typically used for this purpose.
f）はIPsecのSPIの選択とNAT間の非互換性。 IPsec ESPトラフィックが暗号化され、NATすることが不透明であるため、NATは、着信IPsecトラフィックを分離するためにIPとIPsecヘッダの要素を使用しなければなりません。宛先IPアドレス、セキュリティプロトコル（AH / ESP）、およびIPSec SPIの組み合わせは、典型的には、この目的のために使用されます。
However, since the outgoing and incoming SPIs are chosen independently, there is no way for the NAT to determine what incoming SPI corresponds to what destination host merely by inspecting outgoing traffic. Thus, were two hosts behind the NAT to attempt to create IPsec SAs at the same destination simultaneously, it is possible that the NAT will deliver the incoming IPsec packets to the wrong destination.
送信および受信のSPIは、独立して選択されるので、NAT着信SPIは単に発信トラフィックを調べてどの宛先ホストに対応するかを決定するための方法はありません。このように、同時に同じ目的地でのIPsec SAを作成しようとするNATの背後にある二つのホストだった、NATが誤った宛先に入ってくるのIPsecパケットを配信することが可能です。
Note that this is not an incompatibility with IPsec per se, but rather with the way it is typically implemented. With both AH and ESP, the receiving host specifies the SPI to use for a given SA, a choice which is significant only to the receiver. At present, the combination of Destination IP, SPI, and Security Protocol (AH, ESP) uniquely identifies a Security Association. Also, SPI values in the range 1-255 are reserved to IANA and may be used in the future. This means that, when negotiating with the same external host or gateway, the internal hosts behind the same NAPT can select the same SPI value, such that one host inbound SA is (SPI=470, Internal Dest IP=192.168.0.4) and a different host inbound SA is (SPI=470, Internal Dest IP=192.168.0.5). The receiving NAPT will not be able to determine which internal host an inbound IPsec packet with SPI=470 should be forwarded to.
これは、それ自体のIPsecとの互換性ではなく、途中でそれが一般的に実装されていることに注意してください。 AHとESPの両方で、受信ホストが与えられたSA、受信機のみに重要である選択のために使用するSPIを指定します。現時点では、送信先IP、SPI、およびセキュリティプロトコル（AH、ESP）の組み合わせは一意にセキュリティアソシエーションを識別します。また、範囲1-255にSPI値はIANAに予約されており、将来的に使用することができます。これは、同じ外部のホストまたはゲートウェイと交渉するとき、同じNAPTの背後にある内部ホストは、1つのホストインバウンドSAは（SPI = 470、内部取引先IP = 192.168.0.4）であり、同じSPI値を選択することができる、ということを意味します別のホストインバウンドSAは（SPI = 470、内部取引先IP = 192.168.0.5）です。受信NAPTは、SPI = 470とのインバウンドIPsecパケットが転送されるべき内部どのホストを決定することができません。
It is also possible for the receiving host to allocate a unique SPI to each unicast Security Association. In this case, the Destination IP Address need only be checked to see if it is "any valid unicast IP for this host", not checked to see if it is the specific Destination IP address used by the sending host. Using this technique, the NA(P)T can be assured of a low but non-zero chance of forwarding packets to the wrong internal host, even when two or more hosts establish SAs with the same external host.
受信ホストは、各ユニキャストセキュリティアソシエーションにユニークなSPIを割り当てることも可能です。この場合、送信先IPアドレスのみが、それは「このホストの任意の有効なユニキャストIP」であるかどうかを確認するためにチェックする必要が、それは送信ホストによって使用される特定の宛先IPアドレスであるかどうかを確認するためにチェックされません。この技術を用い、NA（P）Tは、2つの以上のホストが同じ外部ホストとSAを確立する場合であっても、間違った内部ホストにパケットを転送するの低いがゼロでない機会を保証することができます。
This approach is completely backwards compatible, and only requires the particular receiving host to make a change to its SPI allocation and IPsec_esp_input() code. However, NA(P)T devices may not be able to detect this behavior without problems associated with parsing IKE payloads. And a host may still be required to use a SPI in the IANA reserved range for the assigned purpose.
このアプローチは、完全に下位互換性があり、そして唯一のSPI割り当ておよびIPsec_esp_input（）コードを変更するために特定の受信側ホストを必要とします。しかし、NA（P）Tデバイスは、IKEペイロードを解析することに関連する問題なしに、この動作を検出することができないかもしれません。そして、ホストがまだ割り当て目的のためにIANA予約範囲でSPIを使用する必要があります。
g) Incompatibilities between embedded IP addresses and NAT. Since the payload is integrity protected, any IP addresses enclosed within IPsec packets will not be translatable by a NAT. This renders ineffective Application Layer Gateways (ALGs) implemented within NATs. Protocols that utilize embedded IP addresses include FTP, IRC, SNMP, LDAP, H.323, SIP, SCTP (optionally), and many games. To address this issue, it is necessary to install ALGs on the host or security gateway that can operate on application traffic prior to IPsec encapsulation and after IPsec decapsulation.
g）に埋め込まれたIPアドレスとNAT間の非互換性。ペイロードが完全性保護されているので、IPsecパケット内に封入された任意のIPアドレスがNATによって翻訳可能ではありません。これは、NATの内に実装無効アプリケーション層ゲートウェイ（のALG）をレンダリングします。埋め込まれたIPアドレスを利用するプロトコルはFTP、IRC、SNMP、LDAP、H.323、SIP、SCTP（オプション）、および多くのゲームが含まれます。この問題に対処するには、前のIPsecカプセル化およびIPsecのカプセル化解除後のアプリケーショントラフィック上で動作することができ、ホストまたはセキュリティゲートウェイ上のALGをインストールする必要があります。
h) Implicit directionality of NA(P)T. NA(P)Ts often require an initial outbound packet to flow through them in order to create an inbound mapping state. Directionality prohibits unsolicited establishment of IPsec SAs to hosts behind the NA(P)T.
H）NA（P）Tの暗黙的な方向。 NA（P）Tsは、多くの場合、インバウンドマッピング状態を作成するためにそれらを介して流れるように、最初の発信パケットを必要としています。方向性はNA（P）Tの背後にあるホストへのIPsec SAの迷惑設立を禁止します。
i) Inbound SA selector verification. Assuming IKE negotiates phase 2 selectors, inbound SA processing will drop the decapsulated packet, since [RFC2401] requires a packet's source address match the SA selector value, which NA(P)T processing of an ESP packet would change.
ⅰ）インバウンドSAセレクタ検証。 [RFC2401]は、パケットの送信元アドレスがESPパケットのNA（P）T処理が変化するSAのセレクタ値と一致必要とするので、IKEは、位相2つのセレクタをネゴシエートすると仮定すると、インバウンドSA処理は、デカプセル化パケットをドロップします。
Implementation problems present in many NA(P)Ts include:
多くのNA（P）TSに存在インプリメンテーションの問題は、次のとおりです。
j) Inability to handle non-UDP/TCP traffic. Some NA(P)Ts discard non-UDP/TCP traffic or perform address-only translation when only one host is behind the NAT. Such NAPTs are unable to enable SCTP, ESP (protocol 50), or AH (protocol 51) traffic.
j）ができないことは、非UDP / TCPトラフィックを処理します。いくつかのNA（P）Tsの非UDP / TCPトラフィックを破棄するか、1つのホストのみがNATの背後にある場合、アドレスのみの変換を行います。そのようなNAPTsはSCTP、ESP（プロトコル50）、またはAH（プロトコル51）トラフィックを有効にすることができません。
k) NAT mapping timeouts. NA(P)Ts vary in the time for which a UDP mapping will be maintained in the absence of traffic. Thus, even where IKE packets can be correctly translated, the translation state may be removed prematurely.
k）はNATマッピングのタイムアウト。 NA（P）TsはUDPマッピングは、トラフィックが存在しない状態で維持される時間で変化します。このように、IKEパケットを正しく翻訳することができる場合であっても、変換状態が早期に除去することができます。
l) Inability to handle outgoing fragments. Most NA(P)Ts can properly fragment outgoing IP packets in the case where the IP packet size exceeds the MTU on the outgoing interface. However, proper translation of outgoing packets that are already fragmented is difficult and most NAPTs do not handle this correctly. As noted in Section 6.3 of [RFC3022], where two hosts originate fragmented packets to the same destination, the fragment identifiers can overlap. Since the destination host relies on the fragmentation identifier and fragment offset for reassembly, the result will be data corruption. Few NA(P)Ts protect against identifier collisions by supporting identifier translation. Identifier collisions are not an issue when NATs perform the fragmentation, since the fragment identifier need only be unique within a source/destination IP address pair.
リットル）できないことは、発信断片を処理します。最もNA（P）Tsが正しくIPパケットサイズが発信インターフェースのMTUを超えた場合に、発信IPパケットを断片化することができます。しかし、すでに断片化されている発信パケットの適切な翻訳が困難であり、ほとんどのNAPTsはこれを正しく処理しません。 2つのホストが同じ宛先に断片化されたパケットを発信[RFC3022]のセクション6.3で述べたように、フラグメント識別子が重複することができます。宛先ホストが再構成のためのオフセットフラグメンテーション識別子及びフラグメントに依存しているので、結果は、データの破損であろう。いくつかのNA（P）Tsの識別子の変換をサポートすることにより、識別子の衝突から保護します。 NATのフラグメンテーションを実行するときに断片識別子は唯一のソース/宛先IPアドレス対内で一意である必要があるため、識別子の衝突は、問題ではありません。
Since a fragment can be as small as 68 octets [RFC791], there is no guarantee that the first fragment will contain a complete TCP header. Thus, a NA(P)T looking to recalculate the TCP checksum may need to modify a subsequent fragment. Since fragments can be reordered, and IP addresses can be embedded and possibly even split between fragments, the NA(P)T will need to perform reassembly prior to completing the translation. Few NA(P)Ts support this.
断片は、68オクテット[RFC791]と小さくすることができるので、最初のフラグメントが完全なTCPヘッダを含むであろうという保証はありません。したがって、TCPチェックサムを再計算するために探してNA（P）Tは、後続の断片を変更する必要があるかもしれません。断片を並べ替えることができ、およびIPアドレスが埋め込まれており、可能性も断片に分割することができますので、NA（P）Tは、前の翻訳を完了し再構築を実行する必要があります。いくつかのNA（P）Tsと、これをサポートしています。
m) Inability to handle incoming fragments. Since only the first fragment will typically contain a complete IP/UDP/SCTP/TCP header, NAPTs need to be able to perform the translation based on the source/dest IP address and fragment identifier alone. Since fragments can be reordered, the headers to a given fragment identifier may not be known if a subsequent fragment arrives prior to the initial one, and the headers may be split between fragments. As a result, the NAPT may need to perform reassembly prior to completing the translation. Few NAPTs support this. Note that with NAT, the source/dest IP address is enough to determine the translation so that this does not arise. However, it is possible for the IPsec or IKE headers to be split between fragments, so that reassembly may still be required.
入ってくるフラグメントを処理するためメートル）できないこと。最初のフラグメントは、典型的には、完全なIP / UDP / SCTP / TCPヘッダを含むので、NAPTs単独でソース/ DEST IPアドレスとフラグメント識別子に基づいて変換を実行できるようにする必要があります。フラグメントは並べ替えることができるので、後続の断片より前初期一つに到着した場合、所与のフラグメント識別子にヘッダは知られていないかもしれない、とヘッダはフラグメント間で分割されてもよいです。その結果、NAPTは、前の翻訳を完了し再構築を実行する必要があるかもしれません。少数NAPTsはこれをサポートしています。 NATで、ソース/ destのIPアドレスが、これが生じないように、翻訳を決定するのに十分であることに注意してください。 IPSecまたはIKEヘッダーが断片に分割されるために再構築がまだ必要とすることができるように、しかし、それは、可能です。
Incompatibilities between IPsec and NAT "helper" functionality include:
IPsecとNAT間の非互換性は、「ヘルパー」機能が含まれます：
n) Internet Security Association and Key Management Protocol (ISAKMP) header inspection. Today some NAT implementations attempt to use IKE cookies to de-multiplex incoming IKE traffic. As with source-port de-multiplexing, IKE cookie de-multiplexing results in problems with re-keying, since Phase 1 re-keys typically will not use the same cookies as the earlier traffic.
n）はインターネットSecurity AssociationとKey Managementプロトコル（ISAKMP）ヘッダ検査。今日、いくつかのNATの実装は、デマルチプレクスし、着信IKEトラフィックをIKEクッキーを使用しようとします。送信元ポートの逆多重化と同様に、フェーズ1の再鍵以来の再入力に問題におけるIKEクッキー逆多重化の結果は、一般的に、以前のトラフィックと同じクッキーを使用しません。
o) Special treatment of port 500. Since some IKE implementations are unable to handle non-500 UDP source ports, some NATs do not translate packets with a UDP source port of 500. This means that these NATs are limited to one IPsec client per destination gateway, unless they inspect details of the ISAKMP header to examine cookies which creates the problem noted above.
O）ポート500の特別な治療いくつかのIKE実装は非500 UDPソースポートを扱うことができないのでは、500本のUDPソースポートにパケットを変換していないいくつかのNATはこれらのNATは、宛先ごとに1つのIPsecクライアントに限定されていることを意味しゲートウェイ、それらは上述の問題を作成するクッキーを調べるためにISAKMPヘッダの内容を検査しない限り。
p) ISAKMP payload inspection. NA(P)T implementations that attempt to parse ISAKMP payloads may not handle all payload ordering combinations, or support vendor_id payloads for IKE option negotiation.
P）ISAKMPペイロード検査。 IKEオプション交渉のためのすべてのペイロード発注の組み合わせ、またはサポートVENDOR_IDペイロードを処理できませんISAKMPペイロードを解析しようとするとNA（P）Tの実装。
The goal of an IPsec-NAT compatibility solution is to expand the range of usable IPsec functionality beyond that available in the NAT-compatible IPsec tunnel mode solution described in Section 2.3.
IPsecでNAT互換性溶液の目標は、セクション2.3で説明NAT互換IPsecトンネルモード溶液で入手可能なものを超えて使用可能なIPsecの機能の範囲を拡張することです。
In evaluating a solution to IPsec-NAT incompatibility, the following criteria should be kept in mind:
IPsecでNAT非互換性の解決策を評価するには、以下の基準を念頭に置いておく必要があります。
Deployment
配備
Since IPv6 will address the address scarcity issues that frequently lead to use of NA(P)Ts with IPv4, the IPsec-NAT compatibility issue is a transitional problem that needs to be solved in the time frame prior to widespread deployment of IPv6. Therefore, to be useful, an IPsec-NAT compatibility solution MUST be deployable on a shorter time scale than IPv6.
IPv6は頻繁にIPv4のとNA（P）TSの使用につながるアドレス不足の問題に対処しますので、IPsecでNAT互換性の問題は、前のIPv6の広範な展開に時間枠内で解決される必要があり、移行の問題があります。そのため、有用であることが、IPsecでNATとの互換性ソリューションは、IPv6よりも短い時間スケールで展開可能でなければなりません。
Since IPv6 deployment requires changes to routers as well as hosts, a potential IPsec-NAT compatibility solution, which requires changes to both routers and hosts, will be deployable on approximately the same time scale as IPv6. Thus, an IPsec-NAT compatibility solution SHOULD require changes only to hosts, and not to routers.
IPv6展開は、ルータならびにホストへの変更を必要とするため、ルータとホストの両方の変更を必要とする可能性のIPsec-NAT互換性溶液は、IPv6のとほぼ同じ時間スケールで展開であろう。したがって、IPsecでNAT互換性溶液は、ホストだけにはなく、ルータに変更を要求すべきです。
Among other things, this implies that communication between the host and the NA(P)T SHOULD NOT be required by an IPsec-NAT compatibility solution, since that would require changes to the NA(P)Ts, and interoperability testing between the host and NA(P)T implementations. In order to enable deployment in the short term, it is necessary for the solution to work with existing router and NA(P)T products within the deployed infrastructure.
とりわけ、このことは、NA（P）Tsの変更を必要とするので、ホスト間の通信及びNA（P）Tは、IPsecでNAT互換性溶液によって要求されるべきではないことを意味する、とホストとの間の相互運用性テスト、およびNA（P）Tの実装。溶液が展開インフラストラクチャ内の既存のルータおよびNA（P）T製品で動作するために短期的に配備を可能にするために、それが必要です。
Protocol Compatibility
プロトコルの互換性
An IPsec NAT traversal solution is not expected to resolve issues with protocols that cannot traverse NA(P)T when unsecured with IPsec. Therefore, ALGs may still be needed for some protocols, even when an IPsec NAT traversal solution is available.
IPsecのNATトラバーサルソリューションは、IPSecで保護されていないNA（P）Tを通過することはできませんプロトコルの問題を解決することが期待されていません。したがって、のALGはまだのIPsec NATトラバーサルソリューションが利用可能な場合でも、いくつかのプロトコルのために必要とすることができます。
Security
セキュリティ
Since NA(P)T directionality serves a security function, IPsec NA(P)T traversal solutions should not allow arbitrary incoming IPsec or IKE traffic from any IP address to be received by a host behind the NA(P)T, although mapping state should be maintained once bidirectional IKE and IPsec communication is established.
NA（P）Tの方向性は、セキュリティ機能を果たすので、IPsecのNA（P）Tトラバーサルソリューションは、NA（P）Tの後ろにホストによって受信される任意のIPアドレスからの任意の着信IPSecまたはIKEトラフィックを許可しないもののべきマッピング状態双方向IKEとIPsec通信が確立されると維持されるべきです。
Telecommuter Scenario
在宅勤務のシナリオ
Since one of the primary uses of IPsec is remote access to corporate Intranets, a NA(P)T traversal solution MUST support NA(P)T traversal, via either IPsec tunnel mode or L2TP over IPsec transport mode [RFC3193]. This includes support for traversal of more than one NA(P)T between the remote client and the VPN gateway.
IPsecの主な用途の一つは、企業イントラネットへのリモートアクセスであるので、NA（P）Tトラバーサルソリューションは、IPsecトランスポート・モード[RFC3193]上のIPsecトンネルモードまたはL2TPのいずれかを介して、NA（P）Tトラバーサルをサポートしなければなりません。これは、リモートクライアントとVPNゲートウェイの間に複数のNA（P）Tのトラバーサルのためのサポートを含みます。
The client may have a routable address and the VPN gateway may be behind at least one NA(P)T, or alternatively, both the client and the VPN gateway may be behind one or more NA(P)Ts. Telecommuters may use the same private IP address, each behind their own NA(P)T, or many telecommuters may reside on a private network behind the same NA(P)T, each with their own unique private address, connecting to the same VPN gateway. Since IKE uses UDP port 500 as the destination, it is not necessary to enable multiple VPN gateways operating behind the same external IP address.
クライアントは、ルーティング可能なアドレス及びVPNゲートウェイの背後に少なくとも一つのNA（P）Tであってもよい、または代替的に、クライアントとVPNゲートウェイの両方は、1つ以上のNA（P）Tsの背後にあってもよい。有していてもよいです在宅勤務は、自分のNA（P）T、または多くの在宅勤務者の背後には、それぞれ同じVPNに接続して、同じNA（P）T、独自のプライベートアドレスを持つ各背後にあるプライベートネットワーク上に存在することができる、同じプライベートIPアドレスを使用することができますゲートウェイ。 IKEは、宛先としてUDPポート500を使用しているので、同じ外部IPアドレスの後ろに動作する複数のVPNゲートウェイを有効にする必要はありません。
Gateway-to-Gateway Scenario
ゲートウェイ間のシナリオ
In a gateway-gateway scenario, a privately addressed network (DMZ) may be inserted between the corporate network and the Internet. In this design, IPsec security gateways connecting portions of the corporate network may be resident in the DMZ and have private addresses on their external (DMZ) interfaces. A NA(P)T connects the DMZ network to the Internet.
ゲートウェイゲートウェイのシナリオでは、個人宛ネットワーク（DMZ）は、企業ネットワークとインターネットとの間に挿入されてもよいです。この設計では、企業ネットワークの接続部のIPsecセキュリティゲートウェイは、DMZに常駐することができ、その外部（DMZ）インターフェイス上のプライベートアドレスを持っています。 NA（P）Tは、インターネットへのDMZネットワークを接続します。
End-to-End Scenario
エンドツーエンドのシナリオ
A NAT-IPsec solution MUST enable secure host-host TCP/IP communication via IPsec, as well as host-gateway communications. A host on a private network MUST be able to bring up one or multiple IPsec-protected TCP connections or UDP sessions to another host with one or more NA(P)Ts between them. For example, NA(P)Ts may be deployed within branch offices connecting to the corporate network, with an additional NA(P)T connecting the corporate network to the Internet. Likewise, NA(P)Ts may be deployed within a corporate network LAN or WAN to connect wireless or remote location clients to the corporate network. This may require special processing of TCP and UDP traffic on the host.
NAT-IPsecの溶液は、セキュアにIPsecを介してホスト - ホストTCP / IP通信、ならびにホストゲートウェイ通信を有効にする必要があります。プライベートネットワーク上のホストは、それらの間に1つ以上のNA（P）Tsの持つ別のホストに1または複数のIPsecで保護されたTCP接続またはUDPセッションを起動することができなければなりません。例えば、NA（P）Tsがインターネットに企業ネットワークに接続する追加のNA（P）Tを用いて、企業ネットワークに接続するブランチオフィス内に配備されてもよいです。同様に、NA（P）Tsは、企業ネットワークへの無線またはリモート・ロケーションクライアントを接続するために、企業ネットワークLANまたはWAN内に配置されてもよいです。これは、ホスト上のTCPおよびUDPトラフィックの特別な処理が必要な場合があります。
Bringing up SCTP connections to another host with one or more NA(P)Ts between them may present special challenges. SCTP supports multi-homing. If more than one IP address is used, these addresses are transported as part of the SCTP packet during the association setup (in the INIT and INIT-ACK chunks). If only single homed SCTP end-points are used, [RFC2960] section 3.3.2.1 states:
それらの間に1つ以上のNA（P）Tsとして別のホストにSCTP接続を育てることは、特別な課題を提示することができます。 SCTPはマルチホーミングをサポートしています。複数のIPアドレスが使用される場合、これらのアドレスは、（INITとINIT-ACKチャンク内の）アソシエーションのセットアップ中にSCTPパケットの一部として搬送されます。単一のホームSCTPエンドポイントが使用される場合、[RFC2960]セクション3.3.2.1状態：
Note that not using any IP address parameters in the INIT and
INIT-ACK is an alternative to make an association more likely
to work across a NAT box.
This implies that IP addresses should not be put into the SCTP packet unless necessary. If NATs are present and IP addresses are included, then association setup will fail. Recently [AddIP] has been proposed which allows the modification of the IP address once an association is established. The modification messages have also IP addresses in the SCTP packet, and so will be adversely affected by NATs.
これは、必要な場合を除き、IPアドレスは、SCTPパケットに入れるべきではないことを意味します。 NATのが存在し、IPアドレスが含まれている場合には、協会のセットアップは失敗します。最近[AddIP]アソシエーションが確立されると、IPアドレスの変更を可能にすることが提案されています。修正メッセージは、SCTPパケットでもIPアドレスを持っていて、その悪のNATによって影響を受けることになります。
Firewall Compatibility
ファイアウォールの互換性
Since firewalls are widely deployed, a NAT-IPsec compatibility solution MUST enable a firewall administrator to create simple, static access rule(s) to permit or deny IKE and IPsec NA(P)T traversal traffic. This implies, for example, that dynamic allocation of IKE or IPsec destination ports is to be avoided.
ファイアウォールが広く展開されているので、NAT-のIPsec互換性ソリューションは、IKEおよびIPsec NA（P）Tトラバーサルトラフィックを許可または拒否するために、単純な、スタティックアクセスルール（複数可）を作成するために、ファイアウォール管理者を有効にする必要があります。これは、IKEやIPsec宛先ポートの動的割り当てが回避されるべきであること、例えば、を意味します。
Scaling
スケーリング
An IPsec-NAT compatibility solution should be capable of being deployed within an installation consisting of thousands of telecommuters. In this situation, it is not possible to assume that only a single host is communicating with a given destination at a time. Thus, an IPsec-NAT compatibility solution MUST address the issue of overlapping SPD entries and de-multiplexing of incoming packets.
IPsecでNAT互換性溶液は、在宅勤務の数千から成るインストール内に配置されることが可能であるべきです。このような状況では、それだけで単一のホストを一度に所定の宛先と通信していることを前提とすることはできません。したがって、IPsecでNAT互換性溶液はSPDエントリと着信パケットの逆多重化を重複の問題に対処しなければなりません。
Mode Support
モードのサポート
At a minimum, an IPsec-NAT compatibility solution MUST support traversal of the IKE and IPsec modes required for support within [RFC2409] and [RFC2401]. For example, an IPsec gateway MUST support ESP tunnel mode NA(P)T traversal, and an IPsec host MUST support IPsec transport mode NA(P)T traversal. The purpose of AH is to protect immutable fields within the IP header (including addresses), and NA(P)T translates addresses, invalidating the AH integrity check. As a result, NA(P)T and AH are fundamentally incompatible and there is no requirement that an IPsec-NAT compatibility solution support AH transport or tunnel mode.
最低でも、IPsecでNAT互換性溶液は[RFC2409]及び[RFC2401]内に支持するために必要なIKEおよびIPsecモードのトラバーサルをサポートしなければなりません。例えば、IPsecゲートウェイは、ESPトンネルモードNA（P）Tトラバーサルをサポートしなければならない、とのIPsecホストは、IPsecトランスポート・モードNA（P）Tトラバーサルをサポートしなければなりません。 AHの目的は、（アドレスを含む）は、IPヘッダ内の不変のフィールドを保護することであり、NA（P）Tは、AH整合性チェックを無効、アドレスを変換します。結果として、NA（P）T及びAHは、基本的に非相溶性であり、そのIPsecでNAT互換性溶液サポートAH輸送またはトンネルモード必要はありません。
Backward Compatibility and Interoperability
下位互換性と相互運用性
An IPsec-NAT compatibility solution MUST be interoperable with existing IKE/IPsec implementations, so that they can communicate where no NA(P)T is present. This implies that an IPsec-NAT compatibility solution MUST be backwards-compatible with IPsec as defined in [RFC2401] and IKE as defined in [RFC2409]. In addition, it SHOULD be able to detect the presence of a NA(P)T, so that NA(P)T traversal support is only used when necessary. This implies that it MUST be possible to determine that an existing IKE implementation does not support NA(P)T traversal, so that a standard IKE conversation can occur, as described in [RFC2407], [RFC2408], and [RFC2409]. Note that while this implies initiation of IKE to port 500, there is no requirement for a specific source port, so that UDP source port 500 may or may not be used.
何NA（P）Tが存在しない場合、それらが通信できるようにIPsec-NAT互換性溶液は、既存のIKE / IPsec実装と相互運用していなければなりません。これは[RFC2409]で定義されるように[RFC2401]とIKEで定義されたIPsec-NAT互換性溶液は、IPSecとの下位互換性がなければならないことを意味します。 NA（P）T横断サポートが必要な場合にのみ使用されるように、また、NA（P）Tの存在を検出することができるべきです。標準IKE会話が発生することができるように、[RFC2407]、[RFC2408]及び[RFC2409]に記載されているように既存のIKE実装は、NA（P）Tのトラバーサルをサポートしていないと判断することが可能でなければならないことを意味します。これはポート500にIKEの開始を意味しつつUDPソースポート500は用いても用いなくてもよいように、特定のソース・ポートのための必要はないことに留意されたいです。
Security
セキュリティ
An IPsec-NAT compatibility solution MUST NOT introduce additional IKE or IPsec security vulnerabilities. For example, an acceptable solution must demonstrate that it introduces no new denial of service or spoofing vulnerabilities. IKE MUST be allowed to re-key in a bi-directional manner as described in [RFC2408].
IPsecでNAT互換性ソリューションは、追加のIKEまたはIPsecのセキュリティの脆弱性を導入してはなりません。たとえば、受け入れ可能な解決策は、それがサービスやなりすましの脆弱性の新たな否定を導入していないことを証明しなければなりません。 [RFC2408]に記載されているように、IKEは、双方向の様式で再キーを許可されなければなりません。
In a limited set of circumstances, it is possible for an IPsec tunnel mode implementation, such as that described in [DHCP], to traverse NA(P)T successfully. However, the requirements for successful traversal are sufficiently limited so that a more general solution is needed:
状況の限られたセットにおいて、それが正常にNA（P）Tを横断するように、そのような[DHCP]に記載されているように、IPsecトンネルモード実装のために可能です。より一般的な解決策が必要とされているように、しかし、成功したトラバーサルのための要件は十分に制限されています：
1) IPsec ESP. IPsec ESP tunnels do not cover the outer IP header within the message integrity check, and so will not suffer Authentication Data invalidation due to address translation. IPsec tunnels also need not be concerned about checksum invalidation.
1）IPsecのESP。 IPsecのESPトンネルは、メッセージの整合性チェック内の外側のIPヘッダーをカバーしていない、ので、アドレス変換による認証データの無効化を被ることはありません。 IPsecトンネルはまた、チェックサムの無効化を心配する必要はありません。
2) No address validation. Most current IPsec tunnel mode implementations do not perform source address validation so that incompatibilities between IKE identifiers and source addresses will not be detected. This introduces security vulnerabilities as described in Section 5.
2）いいえアドレス検証ません。 IKE識別子と送信元アドレスの間の非互換性が検出されないように、現在のほとんどのIPsecトンネルモードの実装では、送信元アドレスの検証を行いません。第5節で説明したようにこれは、セキュリティの脆弱性を紹介します。
3) "Any to Any" SPD entries. IPsec tunnel mode clients can negotiate "any to any" SPDs, which are not invalidated by address translation. This effectively precludes use of SPDs for the filtering of allowed tunnel traffic.
3）SPDエントリ「どれにどれ」。 IPsecトンネルモードのクライアントがアドレス変換によって無効化されていないのSPD、「いずれかに何らかの」を交渉することができます。これは、効果的に許可され、トンネルトラフィックのフィルタリングのためのSPDの使用を排除します。
4) Single client operation. With only a single client behind a NAT, there is no risk of overlapping SPDs. Since the NAT will not need to arbitrate between competing clients, there is also no risk of re-key mis-translation, or improper incoming SPI or cookie de-multiplexing.
4）シングルクライアント操作。 NATの背後にあるだけで、単一のクライアントでは、のSPDの重複の危険性はありません。 NATは、競合するクライアントの間で調停する必要はありませんので、何の再キーの誤翻訳のリスク、または不適切なの着信SPIやクッキーのデマルチプレクスもありません。
5) No fragmentation. When certificate authentication is used, IKE fragmentation can be encountered. This can occur when certificate chains are used, or even when exchanging a single certificate if the key size, or the size of other certificate fields (such as the distinguished name and other extensions), is large enough. However, when pre-shared keys are used for authentication, fragmentation is less likely.
5）いいえフラグメンテーションありません。証明書認証を使用する場合、IKEの断片化が発生することができます。これは、証明書チェーンを使用する場合に発生、またはキーサイズ、または（例えば、識別名と他の拡張機能のような）他の証明書フィールドのサイズは、十分な大きさである場合、単一の証明書を交換する場合でもすることができます。事前共有キーを認証に使用されている場合しかし、断片化は可能性が低いです。
6) Active sessions. Most VPN sessions typically maintain ongoing traffic flow during their lifetime so that UDP port mappings are less likely be removed due to inactivity.
6）アクティブなセッション。 UDPポートマッピングが少ない非アクティブのために削除されるように、ほとんどのVPNセッションは、典型的には、その生涯の間に継続的な交通の流れを維持します。
RSIP, described in [RSIP] and [RSIPFrame], includes mechanisms for IPsec traversal, as described in [RSIPsec]. By enabling host-NA(P)T communication, RSIP addresses issues of IPsec SPI de-multiplexing, as well as SPD overlap. It is thus suitable for use in enterprises, as well as home networking scenarios. By enabling hosts behind a NAT to share the external IP address of the NA(P)T (the RSIP gateway), this approach is compatible with protocols including embedded IP addresses.
RSIP、[RSIP]に記載の[RSIPsec]に記載されているように[RSIPFrame]、IPsecのトラバーサルのための機構を含みます。ホスト-NA（P）Tの通信を可能にすることによって、RSIPは、IPsec SPI逆多重化の問題、ならびにSPD重複に対処します。したがって、企業での使用に適した、だけでなく、ホームネットワーキングのシナリオです。 NA（P）T（RSIPゲートウェイ）の外部IPアドレスを共有するNATの背後のホストを可能にすることにより、このアプローチは、埋め込まれたIPアドレスを含むプロトコルと互換性があります。
By tunneling IKE and IPsec packets, RSIP avoids changes to the IKE and IPsec protocols, although major changes are required to host IKE and IPsec implementations to retrofit them for RSIP-compatibility. It is thus compatible with all existing protocols (AH/ESP) and modes (transport and tunnel).
主要な変更はRSIP互換性のためにそれらを改造するIKEおよびIPsec実装をホストするために必要とされるものの、IKEおよびIPsecパケットをトンネリングすることによって、RSIPは、IKEおよびIPsecプロトコルへの変更を回避します。これは、すべての既存のプロトコル（AH / ESP）とモード（トランスポートおよびトンネル）と、したがって互換性があります。
In order to handle de-multiplexing of IKE re-keys, RSIP requires floating of the IKE source port, as well as re-keying to the floated port. As a result, interoperability with existing IPsec implementations is not assured.
鍵を再IKEの逆多重化を処理するために、RSIPはフローティングポートに再キーイングIKEソースポートの浮き、ならびに必要とします。その結果、既存のIPsec実装との相互運用性は保証されません。
RSIP does not satisfy the deployment requirements for an IPsec-NAT compatibility solution because an RSIP-enabled host requires a corresponding RSIP-enabled gateway in order to establish an IPsec SA with another host. Since RSIP requires changes only to clients and routers and not to servers, it is less difficult to deploy than IPv6. However, for vendors, implementation of RSIP requires a substantial fraction of the resources required for IPv6 support. Thus, RSIP solves a "transitional" problem on a long-term time scale, which is not useful.
RSIP対応ホストが別のホストでのIPsec SAを確立するために、対応するRSIP対応ゲートウェイを必要とするため、RSIPは、IPsec NAT-互換性ソリューションの展開要件を満たしていません。 RSIPが唯一のクライアントおよびルータにはなく、サーバへの変更を必要とするので、IPv6よりも展開するあまり困難です。しかし、ベンダーのために、RSIPの実装は、IPv6をサポートするために必要なリソースのかなりの部分を必要とします。したがって、RSIPは有用ではありません長期的な時間スケール、上の「過渡的」問題を解決します。
6to4, as described in [RFC3056] can form the basis for an IPsec-NAT traversal solution. In this approach, the NAT provides IPv6 hosts with an IPv6 prefix derived from the NAT external IPv4 address, and encapsulates IPv6 packets in IPv4 for transmission to other 6to4 hosts or 6to4 relays. This enables an IPv6 host using IPsec to communicate freely to other hosts within the IPv6 or 6to4 clouds.
6to4の、[RFC3056]に記載されているようにIPsecでNATトラバーサルソリューションのための基礎を形成することができます。このアプローチでは、NATは、IPv6は、NAT外部のIPv4アドレスから派生したIPv6プレフィックスを持つホスト提供し、他の6to4ホストまたは6to4のリレーへの送信のためにIPv4のIPv6パケットをカプセル化します。これは、IPv6の6to4またはクラウド内の他のホストに自由に通信するためにIPsecを使用して、IPv6ホストを可能にします。
While 6to4 is an elegant and robust solution where a single NA(P)T separates a client and VPN gateway, it is not universally applicable. Since 6to4 requires the assignment of a routable IPv4 address to the NA(P)T in order to allow formation of an IPv6 prefix, it is not usable where multiple NA(P)Ts exist between the client and VPN gateway. For example, an NA(P)T with a private address on its external interface cannot be used by clients behind it to obtain an IPv6 prefix via 6to4.
6to4のは、単一のNA（P）Tは、クライアントとVPNゲートウェイを分離エレガントで堅牢なソリューションであるが、それは普遍的に適用できません。 6to4は、IPv6プレフィックスの形成を可能にするためにNA（P）Tにルーティング可能なIPv4アドレスの割り当てを必要とするので、複数のNA（P）Tsは、クライアントとVPNゲートウェイの間に存在する場合、それは使用できません。例えば、その外部インターフェイス上のプライベートアドレスをNA（P）Tは、6to4を介してIPv6プレフィックスを取得するためにその背後にあるクライアントで使用することができません。
While 6to4 requires little additional support from hosts that already support IPv6, it does require changes to NATs, which need to be upgraded to support 6to4. As a result, 6to4 may not be suitable for deployment in the short term.
6to4のは、すでにIPv6をサポートするホストからの少しの追加サポートが必要ですが、それは、6to4をサポートするようにアップグレードする必要があるのNATへの変更を必要としません。その結果、6to4のは、短期的に展開するための適切ではないかもしれません。
By definition, IPsec-NAT compatibility requires that hosts and routers implementing IPsec be capable of securely processing packets whose IP headers are not cryptographically protected. A number of issues arise from this that are worth discussing.
定義により、IPsecでNATとの互換性は、IPsecを実装するホスト及びルータが確実にそのIPヘッダを暗号で保護されていないパケットを処理することが可能であることを必要とします。多くの問題は議論する価値があるというこのことから生じます。
Since IPsec AH cannot pass through a NAT, one of the side effects of providing an IPsec-NAT compatibility solution may be for IPsec ESP with null encryption to be used in place of AH where a NAT exists between the source and destination. However, it should be noted that ESP with null encryption does not provide the same security properties as AH. For example, there are security risks relating to IPv6 source routing that are precluded by AH, but not by ESP with null encryption.
IPsec AHは、NATを通過できないので、IPsecでNAT互換性溶液を提供する副作用の一つがNATがソースと宛先との間に存在するAHの代わりに使用されるヌル暗号化のIPsec ESPためのものであってもよいです。しかし、ヌル暗号化とESPは、AHと同じセキュリティ特性を提供しないことに留意すべきです。例えば、ヌル暗号化でESPによってAHによって除外されていませんが、IPv6ソースルーティングに関連するセキュリティ上のリスクがあります。
In addition, since ESP with any transform does not protect against source address spoofing, some sort of source IP address sanity checking needs to be performed. The importance of the anti-spoofing check is not widely understood. There is normally an anti-spoofing check on the Source IP Address as part of IPsec_{esp,ah}_input(). This ensures that the packet originates from the same address as that claimed within the original IKE Phase 1 and Phase 2 security associations. When a receiving host is behind a NAT, this check might not strictly be meaningful for unicast sessions, whereas in the Global Internet this check is important for tunnel-mode unicast sessions to prevent a spoofing attack described in [AuthSource], which can occur when access controls on the receiver depend upon the source IP address of verified ESP packets after decapsulation. IPsec-NAT compatibility schemes should provide anti-spoofing protection if it uses source addresses for access controls.
また、ESPので、任意の変換では、送信元アドレスのスプーフィングに対して実行する必要性をチェックする送信元IPアドレス正気のいくつかの並べ替えを保護しません。アンチスプーフィングチェックの重要性が広く理解されていません。アンチスプーフィングIPsec_の一部として送信元IPアドレスをチェック{ESP、ああ} _input（）は、通常存在します。これは、それが元のIKEフェーズ1とフェーズ2セキュリティアソシエーション内記載のパケットが同じアドレスに由来することを確実にします。受信ホストがNATの背後にある場合、グローバルインターネットにこのチェックが重要である一方、トンネルモードのユニキャストセッションが発生することができ、[認証発信元]に記載のスプーフィング攻撃を防止するために、このチェックは、厳密に、ユニキャストセッションのために有意義ではないかもしれません受信機でのアクセス制御は、カプセル化解除後に検証ESPパケットの送信元IPアドレスに依存しています。それはアクセス制御のための送信元アドレスを使用する場合のIPsec NAT-互換性スキームは、アンチスプーフィング保護を提供する必要があります。
Let us consider two hosts, A and C, both behind (different) NATs, who negotiate IPsec tunnel mode SAs to router B. Hosts A and C may have different privileges; for example, host A might belong to an employee trusted to access much of the corporate Intranet, while C might be a contractor only authorized to access a specific web site.
私たちは2つのホストAとC、Bのは、AとCが異なる権限を有することができるホストルータにIPsecトンネルモードSAをネゴシエート（異なる）NATの、後ろの両方を考えてみましょう。例えば、ホストAはCのみが特定のWebサイトへのアクセスを許可さ請負人であるかもしれない一方で、企業のイントラネットの多くにアクセスするには、信頼できる従業員に属している可能性があります。
If host C sends a tunnel mode packet spoofing A's IP address as the source, it is important that this packet not be accorded the privileges corresponding to A. If authentication and integrity checking is performed, but no anti-spoofing check (verifying that the originating IP address corresponds to the SPI) then host C may be allowed to reach parts of the network that are off limits. As a result, an IPsec-NAT compatibility scheme MUST provide some degree of anti-spoofing protection.
ホストCは、ソースとしてトンネルモードのパケットスプーフィングAのIPアドレスを送信した場合、認証と整合性チェックが実行された場合、このパケットはAに対応する権限を与えられるべきではないが、ないアンチスプーフィングチェックが（発信することを確認していないことが重要ですIPアドレス）SPIに対応次いでCが限界外にあるネットワークの部分に到達させることができるホスト。その結果、IPsecでNAT互換方式は、アンチスプーフィングある程度の保護を提供しなければなりません。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]アトキンソン、R.とS.ケント、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC2406] Kent,S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S。そして、R.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
"ISAKMPのための解釈のインターネットIPセキュリティー領域" [RFC2407]パイパー、D.、RFC 2407、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2663] Srisuresh, P. and M. Holdredge, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.とM. Holdredge、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]モーガン、D.、Schertler、M.、シュナイダー、M.とJ.ターナー、 "インターネットセキュリティ協会と鍵管理プロトコル（ISAKMP）"、RFC 2408、1998年11月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, M. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、M.およびV.パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193]パテル、B.、Aboba、B.、ディクソン、W.、ゾルン、G.及びS.ブース、 "IPsecを使用してセキュリティ保護L2TP"、RFC 3193、2001年11月。
[RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309]ストーン、J.、スチュワート、R.とD.オーティス、 "ストリーム制御伝送プロトコル（SCTP）チェックサムの変更"、RFC 3309、2002年9月。
[RSIPFrame] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
【RSIPFrame]ボレッラ、M.、ロー、J.、Grabelsky、D.およびG.モンテネグロ、 "レルム特定IP：フレームワーク"、RFC 3102、2001年10月。
[RSIP] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
[RSIP]ボレッラ、M.、Grabelsky、D.、ロー、J.及びK.谷口、 "レルム特定IP：プロトコル仕様"、RFC 3103、2001年10月。
[RSIPsec] Montenegro, G. and M. Borella, "RSIP Support for End-to-End IPsec", RFC 3104, October 2001.
[RSIPsec]モンテネグロ、G.およびM.ボレッラ、 "エンドツーエンドIPsecのRSIPサポート"、RFC 3104、2001年10月。
[DHCP] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[DHCP]パテル、B.、Aboba、B.、ケリー、S.とV.グプタ、 "IPsecのトンネルモードの動的ホスト構成プロトコル（DHCPv4の）設定"、RFC 3456、2003年1月。
[AuthSource] Kent, S., "Authenticated Source Addresses", IPsec WG Archive (ftp://ftp.ans.net/pub/archive/IPsec), Message-Id: <v02130517ad121773c8ed@[128.89.0.110]>, January 5, 1996.
[認証発信元]ケント、S.、 "認証ソースアドレス"、IPsecのWGアーカイブ（ftp://ftp.ans.net/pub/archive/IPsec）、メッセージ-ID：<v02130517ad121773c8ed @ [128.89.0.110]> 1月5、1996。
[AddIP] Stewart, R., et al., "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", Work in Progress.
【AddIP]スチュワート、R.、ら。、「ストリーム制御伝送プロトコル（SCTP）動的アドレス再構成」は、進行中の作業。
Thanks to Steve Bellovin of AT&T Research, Michael Tuexen of Siemens, Peter Ford of Microsoft, Ran Atkinson of Extreme Networks, and Daniel Senie for useful discussions of this problem space.
AT＆T研究所のスティーブBellovin氏、シーメンスのマイケルTuexenのおかげで、マイクロソフトのピーター・フォードは、この問題空間の有益な議論のためのエクストリームネットワークスのアトキンソン、ダニエルSenie蘭。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
Phone: +1 425 706 6605 Fax: +1 425 936 7329 EMail: bernarda@microsoft.com
電話：+1 425 706 6605ファックス：+1 425 936 7329 Eメール：bernarda@microsoft.com
William Dixon V6 Security, Inc. 601 Union Square, Suite #4200-300 Seattle, WA 98101
ウィリアム・ディクソンV6 Security、Inc.の601ユニオンスクエア、スイート＃4200から300シアトル、WA 98101
EMail: ietf-wd@v6security.com
メールアドレス：ietf-wd@v6security.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。