Network Working Group F. Adrangi, Ed.
Request for Comments: 4093 Intel
Category: Informational H. Levkowetz, Ed.
Ericsson
August 2005
Problem Statement: Mobile IPv4 Traversal of
Virtual Private Network (VPN) Gateways
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 (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions.
仮想プライベートネットワーク（VPN）ゲートウェイを介してインターネットに接続されたネットワークにおけるモバイルIP v4のを展開すると、現在よく説明するソリューションを持っていないいくつかの問題を提起します。この文書では説明し、これらの問題を説明し、可能な解決策のためのいくつかのガイドラインを提案することを目指しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Overview of the Problem ....................................3
1.2. Specification of Requirements ..............................3
1.3. Terminology ................................................3
2. MIP and VPN Deployment Scenarios ................................4
2.1. MIPv4 HA(s) Inside the Intranet behind a VPN Gateway .......5
2.2. VPN Gateway and MIPv4 HA(s) on the VPN Domain Border .......6
2.3. Combined VPN Gateway and MIPv4 HA ..........................7
2.4. MIPv4 HA(s) Outside the VPN Domain .........................8
2.5. Combined VPN Gateway and MIPv4 HA(s) on the Local Link .....9
3. Deployment Scenarios Selection ..................................9
4. Problem Statement ..............................................10
4.1. Registering in Co-Located Mode ............................11
4.2. Registering via an FA .....................................12
4.3. Summary: MIP Incompatibilities with IPsec-Based
VPN Gateways ..............................................13
5. Solution Guidelines ............................................14
5.1. Preservation of Existing VPN Infrastructure ...............14
5.2. Software Upgrades to Existing VPN Client and Gateways .....14
5.3. IPsec Protocol ............................................14
5.4. Multi-Vendor Interoperability .............................14
5.5. MIPv4 Protocol ............................................15
5.6. Handoff Overhead ..........................................15
5.7. Scalability, Availability, Reliability, and Performance ...15
5.8. Functional Entities .......................................15
5.9. Implications of Intervening NAT Gateways ..................15
5.10. Security Requirements ....................................16
6. Security Considerations ........................................16
7. Acknowledgements ...............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
Mobile IP [RFC3344] agents are being deployed in enterprise networks to enable mobility across wired and wireless LANs while roaming inside the enterprise Intranet. With the growing deployment of IEEE 802.11 access points ("hot spots") in public places such as hotels, airports, and convention centers, and with wireless WAN data networks such as General Packet Radio Service (GPRS), the need is increasing for enabling mobile users to maintain their transport connections and constant reachability while connecting back to their target "home" networks protected by Virtual Private Network (VPN) technology. This implies that Mobile IP and VPN technologies have to coexist and function together in order to provide mobility and security to the enterprise mobile users.
モバイルIP [RFC3344]エージェントは、企業イントラネットの内部にローミング中の有線および無線LANを横切って移動性を可能にするために、企業ネットワーク内に展開されています。こうしたホテル、空港、コンベンションセンターなどの公共の場所でのIEEE 802.11アクセスポイント（「ホットスポット」）の成長の展開では、そのような汎用パケット無線サービス（GPRS）などの無線WANデータネットワークで、必要ができるようにするために増加しています仮想プライベートネットワーク（VPN）技術によって保護された彼らの目標「ホーム」ネットワークに戻って接続している間彼らの交通機関の接続と一定の到達可能性を維持するために、モバイルユーザー。これは、モバイルIPやVPN技術は、企業のモバイルユーザーにモビリティとセキュリティを提供するために、一緒に共存し、機能していることを意味します。
The goal of this document is to:
このドキュメントの目標は、以下のとおりです。
o Identify and describe practical deployment scenarios for Mobile IP and VPN in enterprise and operator environments.
O企業オペレータ環境におけるモバイルIPとVPNのための実用的な展開シナリオを特定し、記述しています。
o Identify example usage scenarios for remote users roaming outside the "home" network protected by a VPN gateway.
O VPNゲートウェイによって保護「ホーム」ネットワークの外にローミングリモートユーザの使用例のシナリオを識別する。
o Articulate the problems resulting from Mobile IP and VPN coexistence.
OモバイルIPとVPNの共存起因する問題を明確に。
o Specify a set of framework guidelines to evaluate proposed solutions for supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN gateways.
O IPsecベースのVPNゲートウェイ間でのシームレスなマルチベンダーのIPv4モビリティをサポートするためのソリューション提案を評価するためのフレームワークのガイドラインのセットを指定します。
Access to the Intranet is typically guarded by both a firewall and a VPN device. The Intranet can only be accessed by respecting the security policies in the firewall and the VPN device.
イントラネットへのアクセスは、通常、ファイアウォールとVPNデバイスの両方によって守られています。イントラネットは、ファイアウォールやVPNデバイスのセキュリティポリシーを尊重してアクセスすることができます。
When MIP is deployed in a corporate Intranet (also referred to as a VPN domain), roaming between the Intranet (i.e., trusted domain) and the Internet (i.e., untrusted domain) becomes problematic. It would be desirable to have seamless session mobility between the two domains, because MIP was designed for session mobility regardless of the network point of attachment. Unfortunately, the current MIP standards fall short of this promise for an important customer segment: corporate users (using VPN for remote access) who desire to add mobility support because of a need to have continuous access to Intranet resources while roaming outside the Intranet from one subnet to another, or between the VPN domain and the Internet.
MIPは、イントラネット（すなわち、信頼されたドメイン）とインターネットとの間のローミング、（また、VPNドメインとも呼ばれる）、企業イントラネットに配備されたとき（すなわち、信頼できないドメイン）が問題となります。 MIPは関係なく、添付ファイルのネットワークポイントのセッションモビリティのために設計されたので、二つのドメイン間のシームレスなセッションモビリティを有することが望ましいであろう。残念ながら、現在のMIP基準は、重要な顧客セグメントのためのこの約束の短い秋：モビリティサポートを追加することを望む（リモートアクセスVPNを使用して）企業ユーザーなぜなら1からイントラネット外にローミングしながら、イントラネットリソースへの継続的なアクセスを持っている必要がありますの別のサブネット、またはVPNドメインとインターネットの間。
From the beginning, one explicitly stated restriction was that it was assumed that installed firewalls and VPN gateways had to be kept unchanged, rather than replaced or upgraded, because they have much wider deployments than MIP at the time of writing. Therefore, any solutions would need to minimize the impact on existing VPN and firewall deployments, related standards, and "de facto" standards.
当初から、1つの明示的に示した制限は、それは、彼らが書いている時点でMIPよりもはるかに広い展開を持っているので、ファイアウォールやVPNゲートウェイは、交換またはアップグレードしたのではなく、そのまま維持されなければならなかったインストールと仮定したということでした。したがって、任意のソリューションは、既存のVPNとファイアウォールの導入、関連規格、および「デファクト」スタンダードへの影響を最小限に抑える必要があります。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。これらの言葉は、多くの場合、資産計上されます。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
MIPv4 Mobile IP for IPv4 [RFC3344]
IPv4のMIPv4のモバイルIP [RFC3344]
MIPv6 Mobile IP for IPv6
IPv6のためのMIPv6のモバイルIP
VPN Virtual Private Network
VPN仮想プライベートネットワーク
GW Gateway
GWゲートウェイ
VPN Domain An Intranet protected by a VPN gateway.
VPNドメインアンイントラネットは、VPNゲートウェイによって保護されています。
DMZ (Demilitarized Zone) A small network inserted as a "neutral zone" between a company's private network and the outside public network to prevent outside users from getting direct access to the company's private network.
DMZ（非武装地帯）、企業のプライベートネットワークと企業のプライベートネットワークへの直接アクセスを得ることから外部のユーザーを防ぐために、外部のパブリックネットワークとの間に「中立地帯」として挿入小規模ネットワーク。
Home Network A network, possibly virtual, having a network prefix matching that of a mobile node's home address.
ホームネットワークのネットワーク、おそらく仮想、モバイルノードのホームアドレスのそれに一致するネットワークプレフィックスを持ちます。
Home Agent A router on a mobile node's home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node.
ホームエージェントそれがホームから離れているとき、移動ノードへの配信のためにデータグラムをトンネリングし、モバイルノードのための現在の位置情報を管理し、モバイルノードのホームネットワーク上のルータ。
MN Refers to a mobile node that runs both MIP and IPsec-based VPN client software.
MNは、MIPおよびIPsecベースのVPNクライアントソフトウェアの両方を実行しているモバイルノードを指します。
MIPv4 inside IPsec-ESP tunnel MIPv4 packets are encapsulated in an IPsec-ESP tunnel established between the Mobile Node and the VPN gateway.
IPsecでESPトンネルのMIPv4パケット内部のMIPv4移動ノードとVPNゲートウェイの間で確立されたIPsec-ESPトンネル内にカプセル化されています。
IPsec-ESP inside MIPv4 tunnel IPsec-ESP packets are encapsulated in a MIPv4 tunnel established between the Mobile Node and the home agent.
MIPv4トンネルのIPsec-ESPパケット内部のIPsec-ESPは、モバイルノードとホームエージェントの間で確立のMIPv4トンネルにカプセル化されています。
This section describes a set of deployment scenarios wherein MIP agents and VPN gateways have to coexist to provide mobility and security. The intention is to identify practical deployment scenarios for MIP and VPNs where MIP technology might be extended to solve problems resulting from the desire for co-existence.
このセクションでは、MIPエージェントとVPNゲートウェイは、モビリティとセキュリティを提供するために共存する必要が前記展開シナリオのセットを記述する。その意図は、MIP技術が共存への欲求から生じた問題を解決するために拡張されるかもしれないMIPとVPNのための実用的な展開シナリオを識別することです。
The network topology in the following diagrams consists of an Intranet connected to the public network (i.e., the Internet). Here, the word "Intranet" refers to a private network (where private addresses [RFC1918] are typically used) protected by a VPN gateway and perhaps by a layer-3 transparent or non-transparent firewall. When private addresses are used, the non-transparent firewall also functions as a Network Address Translator (NAT) or Network Address Port Translator (NAPT) bridging between the two address realms (i.e., the Intranet and the Internet).
以下の図におけるネットワークトポロジは、公衆ネットワーク（すなわち、インターネット）に接続されたイントラネットから成ります。ここで、単語「イントラネット」（プライベートアドレス[RFC1918]は、典型的に使用される）VPNゲートウェイによって、おそらくレイヤ3透明または不透明ファイアウォールによって保護されたプライベートネットワークを指します。プライベートアドレスが使用されている場合は、非透過ファイアウォールはまた、ネットワークアドレス変換（NAT）として機能またはネットワークアドレスポート翻訳（NAPT）は、2つのアドレスレルム（すなわち、イントラネットとインターネット）の間のブリッジ。
Firewalls may be placed on either side of the VPN gateway; these are referred to as inner and outer firewalls. The inner and outer firewalls typically inspect outbound traffic (i.e., from the Intranet to the Internet) and inbound traffic (i.e., from the Internet to the
ファイアウォールは、VPNゲートウェイのいずれかの側に配置されてもよいです。これらは、内側と外側のファイアウォールと呼ばれます。内側及び外側のファイアウォールは、典型的には、（イントラネットからインターネットへの、すなわち、）アウトバウンドトラフィックと、インターネットからの着信トラフィック（すなわちを検査します
Intranet), respectively. When a firewall is present, it MUST be configured to allow Mobile IP traffic (both control and tunneled data packets) to go through. As our focus here is the relationship between MIP and VPN, we have purposely omitted firewalls from the following scenarios in order to keep things simple.
イントラネット）、それぞれ。ファイアウォールが存在する場合、通過するために、モバイルIPトラフィック（制御およびデータ・パケットをトンネリングさの両方）を許可するように設定されなければなりません。ここで我々の焦点は、MIPとVPNの関係であるように、我々は故意に物事をシンプルに保つために、次のシナリオからファイアウォールを省略しています。
It is assumed that encryption is not enforced inside the VPN domain because: 1) the VPN domain (Intranet) is viewed as a trusted network, and users allowed inside the Intranet are also trusted, and 2) it is a common VPN deployment practice where the VPN is used to guard the Intranet resources from unauthorized users attached to an untrusted network, and to provide a secure communication channel for authorized users to access resources inside the Intranet from outside.
ので、暗号化は、VPNドメイン内で施行されていないものとする：1）VPNドメイン（イントラネット）は、信頼できるネットワークとして表示され、およびイントラネット内で許可されたユーザーにも信頼され、そして2）それは、共通のVPN展開の練習場所ですVPNは、信頼できないネットワークに接続されている権限のないユーザーからのイントラネット・リソースを保護するために、外部からイントラネット内部リソースにアクセスする権限のあるユーザーのための安全な通信チャネルを提供するために使用されます。
The following sub-sections introduce five representative combinations of MIPv4 HA and VPN gateway placement.
以下のサブセクションでは、のMIPv4 HAとVPNゲートウェイの配置の5つの代表的な組み合わせを導入します。
In order to give a reasonably complete survey of MIPv4 and VPN co-existence scenarios, those in Sections 2.3 and 2.5 are included even though, as covered in more detail below, there are no co-existence problems to be solved in these two cases.
以下で詳しく説明としてのMIPv4とVPNの共存シナリオの合理的に完全な調査を与えるためには、セクション2.3および2.5のものは、たとえ含まれており、これらの2つのケースで解決すべき共存の問題はありません。
MIPv4 HAs are deployed inside the Intranet protected by a VPN gateway, and are not directly reachable by the MNs outside the Intranet.
MIPv4のは、VPNゲートウェイによって保護イントラネット内に配置し、イントラネットの外部のMNによって直接到達されないが有しています。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. |MNs | | FA | . | VPN| | Router| | HA | .
. |away| | | .<=========>| | | 1..n | | 1..n | .
. +----+ +----+ . | GW | +-------+ +-------+ .
. . +----+ .
................... . +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 1
図1
Direct application of MIPv4 standards [RFC3344] is successfully used to provide mobility for users inside the Intranet. However, mobile users outside the Intranet can only access the Intranet resources (e.g., MIP agents) through the VPN gateway, which will allow only authenticated IPsec traffic inside. This implies that the MIPv4 traffic has to run inside IPsec, which leads to two distinct problems:
MIPv4の規格[RFC3344]の直接のアプリケーションが正常にイントラネット内部ユーザのモビリティを提供するために使用されます。しかし、イントラネットの外部モバイルユーザーは、内部のみ認証IPsecトラフィックを可能にするVPNゲートウェイを介してイントラネットリソース（例えば、MIPエージェント）にアクセスすることができます。これは、MIPv4のトラフィックは二つの別個の問題につながるのIPsec、内部で実行する必要があることを意味します
1. When the foreign network has an FA deployed (e.g., as in CDMA 2000), MIPv4 registration becomes impossible. This is because the MIPv4 traffic between MN and VPN gateway is encrypted, and the FA (which is likely in a different administrative domain) cannot inspect the MIPv4 headers needed for relaying the MIPv4 packets. Please see Section 4.2 for more details.
外部ネットワーク（例えば、CDMA 2000年のように）展開FAを有する場合1.、MIPv4の登録が不可能となります。 MNとVPNゲートウェイとの間のMIPv4トラフィックが暗号化され、（異なる管理ドメイン内の可能性がある）FAはMIPv4のパケットを中継するために必要なのMIPv4ヘッダーを検査することができないからです。詳細はセクション4.2を参照してください。
2. In co-located mode, successful registration is possible but the VPN tunnel has to be re-negotiated every time the MN changes its point of network attachment.
共同設置モードにおいては、成功した登録が可能であるが、VPNトンネルは、MNは、ネットワーク接続点を変更するたびに再ネゴシエートされなければなりません。
These problems are articulated in Section 4.
これらの問題はセクション4で連接されています。
This deployment scenario may not be common yet, but it is practical and is becoming important as there is an increasing need for providing corporate remote users with continuous access to the Intranet resources.
この展開シナリオはまだ一般的ではないかもしれないが、それは実用的で、イントラネットリソースへの継続的なアクセスと、企業のリモートユーザを提供するためのニーズが高まっているとして重要になってきています。
A MIPv4 HA is deployed on the VPN domain border (e.g., in the DMZ) together with the VPN gateway, and it is directly reachable by MNs inside or outside the Intranet.
MIPv4 HAは一緒にVPNゲートウェイと（例えば、DMZ内の）VPNドメイン境界上に展開し、それは、イントラネットの内部または外部のMNによって直接到達可能です。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<=========>| | | 1..n | .
. +----+ +----+ . /\ | GW | +-------+ .
. . || +----+ .
. . || +----+ +-------+ +-------+ .
. . ++====>| HA | | CN | | MNs | .
................... | | | 1..n | | home | .
+----+ +-------+ +-------+ .
. .
................................
Figure 2
図2
Please note that in deployments where the security policy prohibits direct communication between the MN (roaming outside the Intranet) and outside machines, the HA can be configured to forward only encrypted traffic from/to the MN.
セキュリティポリシーは、MN（イントラネット外にローミング）と外部のマシン間の直接通信を禁止展開で、HAは、MNに/からのみ暗号化されたトラフィックを転送するように設定することができますので、予めご了承ください。
The MIPv4 HA has a public interface connected to the Internet, and a private interface attached to the Intranet. Mobile users will most likely have a virtual home network associated with the MIPv4 HA's private interface, so that the mobile users are always away from home and thus registered with the MIPv4 HA. Furthermore, in deployments where the VPN gateway and the HA are placed in a corporate DMZ, this implies that MIPv4 traffic will always be routed through the DMZ (regardless of whether MNs are located outside or inside the Intranet), which may not be acceptable to IT departments in large corporations.
MIPv4のHAは、インターネットに接続されているパブリックインターフェイス、およびイントラネットに接続プライベートインターフェイスを持っています。モバイルユーザーが自宅から離れので、いつものMIPv4 HAに登録されているように、モバイルユーザーが最も可能性が高い、のMIPv4 HAのプライベートインターフェイスに関連付けられた仮想ホームネットワークを持っています。また、VPNゲートウェイとHAが企業DMZ内に配置されている展開で、これはMIPv4のトラフィックが常に許容されない可能性がDMZ（かかわらずのMNがイントラネットの外側又は内側に配置されているかどうか）を介してルーティングされることを意味します大企業のIT部門。
This deployment can be used with two different configurations: "MIPv4 inside IPsec-ESP tunnel" and "IPsec-ESP inside MIPv4 tunnel". The "MIPv4 inside IPsec-ESP tunnel" has the same problems as the scenario in Section 2.1. (Namely, MIPv4 registration becomes impossible when the registration is to be done via an FA, and furthermore, in co-located mode, the VPN tunnel has to be re-negotiated every time the MN changes its point of attachment.) The "IPsec-ESP inside MIPv4 tunnel" does not have the problems described in Section 2.1; however, it will require some modifications to the routing logic of the MIPv4 HA or the VPN gateway.
「IPsecでESPトンネル内のMIPv4」及び「のMIPv4トンネル内のIPsec-ESP」：この展開は、2つの異なる構成で使用することができます。 「IPsecでESPトンネル内部のMIPv4」は、セクション2.1でシナリオと同様の問題を有しています。 （登録がFAを介して行われるべきであり、また、同じ場所に配置モードでは、VPNトンネルを再ネゴシエートするMNは、接続点を変更するたびを有する場合すなわち、MIPv4の登録が不可能になる。）「のIPsec -ESPのMIPv4トンネル内」セクション2.1に記載された問題を有していません。しかしながら、MIPv4のHAまたはVPNゲートウェイのルーティングロジックにいくつかの変更を必要とします。
This is similar to the deployment scenario described in Section 2.2, with the exception that the VPN gateway and MIPv4 HA are running on the same physical machine.
これは、VPNゲートウェイとのMIPv4 HAは、同じ物理マシン上で実行されていることを除いて、セクション2.2で説明配備シナリオに類似しています。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<==========| GW | | 1..n | .
. +----+ +----+ . | + | +-------+ .
. . | HA | .
................... +----+ +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 3
図3
Running MIPv4 HA and VPN on the same machine resolves routing-related issues that exist in Section 2.2 when a "IPsec-ESP inside MIPv4 tunnel" configuration is used. However, it does not promote multi-vendor interoperability in environments where MIPv4 HA and VPN technologies must be acquired from different vendors.
同じマシン上のMIPv4 HAとVPNを実行すると、「IPsecでESPのMIPv4トンネル内部」構成が使用されている場合、セクション2.2に存在するルーティングに関連する問題を解決します。しかし、それはMIPv4のHAとVPN技術は、異なるベンダーから取得しなければならない環境では、マルチベンダーの相互運用性を促進しません。
In this scenario, MIPv4 HAs are deployed outside the Intranet (e.g., in an operator network), as depicted in Figure 4, below.
以下、図4に示すように、このシナリオでは、MIPv4のは、（オペレータネットワークにおいて、例えば、）イントラネットの外部に配備されているました。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<==========| GW | | 1..n | .
. +----+ +----+ . /\ | | +-------+ .
. . || | | .
................... || | | +-------+ +-------+ .
|| | | | CN | | MNs | .
.....MIPv4 Home.... || | | | 1..n | | home | .
. .<===++ | | +-------+ +-------+ .
. +------+ . +----+ .
. | HAs | . . .
. | 1..n | . ................................
. +------+ .
...................
Figure 4
図4
The IPsec tunnel endpoints will be the MN and the VPN gateway. The 'home network' will most likely be a virtual home network, located at the HA, through which authorized remote users (i.e., those that have successfully established a connection to the corporate VPN) can reach the Corporate Intranet and maintain their transport session connectivity while roaming outside the Intranet from one subnet to another. Please note that this deployment scenario does not support mobility inside the Intranet.
IPsecトンネルエンドポイントは、MNとVPNゲートウェイであろう。 「ホームネットワーク」は、最も可能性の高いリモートユーザーを承認し、それを通してHAに位置する仮想ホームネットワーク、になります（つまり、成功した企業のVPNへの接続を確立したもの）は企業イントラネットに到達し、それらの輸送セッションの接続を維持することができます別のサブネットからのイントラネット外にローミング中。この展開シナリオは、イントラネット内のモビリティをサポートしていないことに注意してください。
In this case, it is most practical to run IPsec-ESP inside a MIPv4 tunnel (i.e., the MIPv4 tunnel endpoints are the MN and the HA; the IPsec-ESP packet from the MN and to the VPN gateway is encapsulated in the MIPv4 tunnel). This is because the MNs can register with the HA without establishing an IPsec tunnel to the VPN gateway.
この場合、（のMIPv4トンネル内のIPsec-ESPを実行するのが最も実用的である、すなわち、のMIPv4トンネルエンドポイントは、MNとHAであり、MNから及びVPNゲートウェイへのIPsec-ESPパケットのMIPv4トンネル内にカプセル化され）。 MNがVPNゲートウェイにIPsecトンネルを確立することなくHAに登録することができるからです。
This is similar to the deployment scenario described in Section 2.3, with the difference that the VPN gateway/HA is sitting on the local link. In this case, the VPN gateway and HA would most naturally be co-located in the same box, although this is in no way a requirement.
これは、VPNゲートウェイ/ HAは、ローカルリンク上に座っていることの違いで、2.3節で説明した展開シナリオに似ています。これは決して要件であるが、この場合には、VPNゲートウェイとHAが最も自然に、同じボックス内に一緒に配置されることになります。
The VPN/HA is assumed to be reachable from the external network; i.e., it is assumed to have a public IP address, and the firewall is assumed to be configured to allow direct access to the VPN/HA from the external network.
VPN / HAは、外部ネットワークから到達可能であると仮定されます。すなわち、パブリックIPアドレスを持っていると仮定され、ファイアウォールは、外部ネットワークからのVPN / HAへの直接アクセスを許可するように構成されているものとします。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +------+ +-------+ +-------+ .
. |MNs | | FA | . | Fire | | Router| | VPN/HA| .
. |away| | | .<=======>| wall | | 1..n | | 1..n | .
. +----+ +----+ . | | +-------+ +-------+ .
. . | NAT | .
................... +------+ +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 5
図5
This deployment works today without any technical problems with IPsec-ESP running inside a MIPv4 tunnel. If you were to run MIPv inside the IPsec-ESP tunnel, it would have the same problems as in Section 2.1, so it is deployed with the IPsec-ESP running inside the MIPv4 tunnel. This deployment is not practical for large deployments (on the order of thousands of users) because of the large and distributed security perimeter.
この展開は、IPsec-ESPは、MIPv4のトンネル内で実行されているとの技術的な問題もなく今日に動作します。あなたはIPsecでESPトンネル内MIPvを実行した場合、それはセクション2.1と同じ問題を抱えているだろう、それはIPsecでESPがMIPv4のトンネル内で実行して展開されています。この展開は大きいため、分散セキュリティ境界の（数千のユーザーのために）大規模な導入のための実用的ではありません。
The deployment scenarios described in Section 2 were evaluated to identify those most in need of solving. The evaluation was done based on two main criteria: 1) Is the deployment scenario common and practical? and 2) Does the deployment scenario reveal any problems resulting from MIPv4 and VPN coexistence?
第2節で説明する展開シナリオは、解決が必要で、それらのほとんどを識別するために評価しました。評価は、2つの主要な基準に基づいて行った：1）一般的で実用的な展開シナリオですか？及び2）の展開シナリオは、MIPv4のとVPNの共存に起因するいかなる問題を明らかにしていますか？
The authors believe that the scenario in Section 2.1 is the most important and practical one because of a rising need for providing corporate remote users with continuous access to their Intranet resources. After analyzing each scenario, one realizes that problems occurring in scenarios in Sections 2.2 and 2.4 are either the same as those in the scenario in Section 2.1 or a subset of them. Therefore, solving the scenario in Section 2.1 will also solve the scenarios in Sections 2.2 and 2.4. The scenarios in Sections 2.3 and 2.5 do not introduce functional problems resulting from MIPv4 and VPN co-existence, and thus there is no need to seek a solution. A solution for the deployment scenario in Section 2.1 is therefore seen as essential, and this in turn can also be applied to solve problems in other scenarios. In subsequent sections, we will articulate the roaming scenarios, the problems, and the solution guidelines relevant to the scenario in Section 2.1.
著者は、2.1節でシナリオがあるため、そのイントラネットリソースへの継続的なアクセスと、企業のリモートユーザを提供するための上昇の必要性の最も重要かつ実用的なものであると信じています。各シナリオを分析した後、一つの問題は、セクション2.2および2.4でのシナリオで発生することを認識すると、いずれかのセクション2.1またはそれらのサブセットにおけるシナリオと同様です。そのため、2.1節でシナリオを解決することも、セクション2.2と2.4でのシナリオを解決します。セクション2.3と2.5でのシナリオはMIPv4のとVPNの共存から生じる機能上の問題を導入していないので、解決策を模索する必要はありません。 2.1節での展開シナリオのためのソリューションが不可欠と見られ、ひいてはこれは、他のシナリオでの問題を解決するために適用することができます。以降のセクションでは、我々は、2.1節では、シナリオに関連するローミングシナリオ、問題、および解決の指針を明確にします。
This section describes roaming scenarios corresponding to the deployment scenario in Section 2.1 where an MN needs to have continuous access to the Intranet resources regardless of whether it is roaming inside or outside the Intranet, and their associated problems. The scenarios are constructed based on a multi-subnetted, MIPv4-enabled Intranet (hereafter referred to as Intranet or VPN domain) protected by an IPsec-based VPN gateway as depicted in Figure 6.
このセクションでは、MNは関係なく、それはイントラネット内または外にローミングしているかどうかのイントラネットリソースへの継続的なアクセス、およびそれらに関連する問題を持っている必要があり、セクション2.1で導入シナリオに対応するローミングシナリオについて説明します。シナリオは、図6に示されるようにIPsecベースのVPNゲートウェイで保護された（以下、イントラネットまたはVPNドメインと呼ばれる）は、マルチサブネット、のMIPv4対応のイントラネットに基づいて構築されています。
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away| .<=========>| | | 1..n | | 1..n | .
. +----+ . | GW | +-------+ +-------+ .
. . +----+ .
................... . +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 6: Intranet protected by a VPN gateway
図6：イントラネットVPNゲートウェイによって保護さ
The Intranet, as depicted in Figure 6, may include both wired (IEEE 802.3) and IEEE 802.11 wireless LAN deployments. However, it is also possible to see IEEE 802.11 deployments outside the Intranet due to the perceived lack of current 802.11 security, as depicted in Figure 7.
イントラネットは、図6に示すように、両方の（IEEE 802.3）有線およびIEEE 802.11の無線LANの導入を含むことができます。しかし、図7に示すように、電流による802.11セキュリティの知覚不足のために、イントラネット外のIEEE 802.11の展開を見ることも可能です。
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away| .<=========>| | | 1..n | | 1..n | .
. +----+ . | GW | +-------+ +-------+ .
. . | | .
................... | | +-------+ +-------+ .
| | | CN | | MNs | .
..802.11 Wireless.. <====>| | | 1..n | | home | .
. Network . +----+ +-------+ +-------+ .
. . . .
................... ................................
Figure 7: IEEE 802.11 Wireless deployment outside the home network
図7：ホームネットワーク外のIEEE 802.11ワイヤレスの展開
In co-located mode, the IPsec tunnel endpoints would be at the MN and the VPN gateway, which (supposing we have the scenario described in Section 2.1) results in the mobile-ip tunnel from MN to HA being encapsulated inside the IPsec tunnel. See Figure 8 below. This scenario is still possible, but has some major drawbacks.
共同設置モードでは、IPsecトンネルエンドポイントは、（我々は、セクション2.1で説明したシナリオを持っていると仮定）は、MNとVPNゲートウェイであろうIPsecトンネル内部に封入されているMNからHAへのモバイルIPトンネルをもたらします。下の図8を参照してください。このシナリオはまだ可能ですが、いくつかの大きな欠点があります。
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away|<###################>| |-----| 1..n |->| 1..n | .
. +----+ . \ | GW | +-------+ +-------+ .
. . \ +----+ .
................... mip . +-------+ +-------+ .
inside . | CN | | MNs | .
IPsec . | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 8
図8
The MN obtains an address at its point of attachment (via DHCP [RFC2131] or some other means), and then sets up an IPsec tunnel to the VPN gateway, after which it can successfully register with its HA through the IPsec tunnel. The IPsec tunnel SA (Security Association) is identified by a triplet consisting of SPI (Security Parameter Index), MN's IP destination address (i.e., the address obtained at the point of attachment), and Security Protocol (AH or ESP) Identifier as described in [RFC2401]. This means that as the MN's IP
MNは、（DHCP [RFC2131]またはいくつかの他の手段を介して）接続ポイントのアドレスを取得し、それが正常にIPsecトンネルを介してHAに登録することができ、その後、VPNゲートウェイへのIPsecトンネルを設定します。記載されているようにIPSecトンネルSA（セキュリティアソシエーション）は、SPI（セキュリティパラメータインデックス）、MNのIP宛先アドレス（すなわち、結合点で得られたアドレス）、およびセキュリティプロトコル（AHまたはESP）識別子からなるトリプレットによって識別されます[RFC2401]インチこれは、MNのIPとして
destination address changes on each IP subnet handoff, the IPsec tunnel needs to be re-established. This could have noticeable performance implications on real-time applications and in resource-constrained wireless networks. In effect, we don't have mobility support for the tunnel endpoint changes associated with MN movements.
各IPサブネットのハンドオフの宛先アドレスの変更は、IPsecトンネルが再確立される必要があります。これは、リアルタイムアプリケーション上やリソースに制約無線ネットワークにおける顕著なパフォーマンスへの影響を持つことができます。実際に、我々は、MNの動きに関連付けられているトンネルエンドポイントの変更のためのモビリティをサポートしていません。
In the case where a mobile node is in a network where mobility support is provided through the use of an FA, and no DHCP allocated address and co-located mode is possible, we run into severe trouble. This is illustrated in Figure 9 and explained below:
モバイルノードがモビリティのサポートはモードが可能であるFAの使用、および無DHCP割り当てられたアドレスを通じて提供と同じ場所に配置されたネットワーク内にある場合には、我々は深刻なトラブルに実行します。これは、図9に示し、以下に説明されます。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. |MNs | | FA | . | VPN| | Router| | VPN/HA| .
. |away|<??| |<###########>| |-----| 1..n |->| 1..n | .
. +----+ \ +----+ . \ | GW | +-------+ +-------+ .
. \ . \ +----+ .
...........\....... mip . +-------+ +-------+ .
\ inside . | CN | | MNs | .
MN expects IPsec . | 1..n | | home | .
IPsec traffic . +-------+ +-------+ .
. .
................................
Figure 9
図9
When arriving at the visited network on the left in this figure, the MN has to reach the FA with registration requests in order to have the FA send them on to the HA. However, the MN in all likelihood cannot register with the FA because the registration requests will be sent encrypted, and the FA will not be able to decrypt them. If the MN would have a policy that allowed split tunneling so that it could reach the FA with clear text messages, then the FA would still not be able to get through the VPN gateway unless the HA is reachable from outside and the Intranet security policy allows MIP registration packets to bypass the VPN gateway.
この図では、左の訪問先ネットワークに到着すると、MNは、FAはHAにそれらを送る持つために登録要求をFAに到達することがあります。登録要求が暗号化されて送信され、FAはそれらを解読することはできませんので、しかし、すべての可能性でMNはFAに登録することはできません。 MNは、それがクリアテキストメッセージでFAに達することができるようにスプリットトンネリングを許可されたポリシーを持っているかどうHAは外部から到達可能であるとイントラネットのセキュリティポリシーが許可しない限り、その後、FAはまだVPNゲートウェイを介して取得することができませんMIP登録パケットは、VPNゲートウェイをバイパスします。
Even if the HA is reachable and the MIP registration succeeds, the FA (which is likely in a different administrative domain) will not be able to relay packets between the MN and the VPN gateway. Packets from the MN will be encapsulated by the FA with IP-in-IP [RFC2003], which the VPN gateway will drop, and packets from the VPN gateway will have ESP payloads (with IP-in-IP inside), which the FA will drop (as it expects IP-in-IP-encapsulated traffic to the MN).
HAが到達可能であり、MIP登録が成功した場合であっても、（異なる管理ドメイン内の可能性がある）FAは、MNとVPNゲートウェイとの間でパケットを中継することができません。 MNからのパケットは、VPNゲートウェイが低下すると、VPNゲートウェイからのパケットは、（IPインIP内部で）ESPペイロードを有することになるIPインIP [RFC2003]、FAとFAによってカプセル化されます（それはMNへのIP-で-IPカプセル化トラフィックを期待して）低下します。
The use of a 'trusted FA' has also been suggested in this scenario, meaning an FA that is actually a combined VPN GW and FA. The scenario will work fine in this case, as the tunnel end-points are at the FA and the VPN gateway as shown in Figure 10 below. However, we cannot expect that the FA in access networks (e.g., wireless hot-spots or CDMA 2000 networks) will have security associations with any given corporate network, so this is not particularly realistic in the general mobility case.
「FAを信頼できる」の使用は、実際に組み合わせたVPN GWとFAでFAを意味し、このシナリオでは示唆されています。以下、図10に示すように、トンネルエンドポイントは、FA及びVPNゲートウェイであるようなシナリオは、この場合には正常に動作します。しかし、我々は、アクセスネットワーク（例えば、無線ホットスポットまたはCDMA 2000のネットワーク）におけるFAは、任意の企業ネットワークとセキュリティアソシエーションを持つことを期待することはできませんので、これは一般的なモビリティ場合に特に現実的ではありません。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. | FA | | VPN| . | VPN| | Router| | VPN/HA| .
. | |<--| GW |<###########>| |-----| 1..n |->| 1..n | .
. +----+ +----+ . \ | GW | +-------+ +-------+ .
. | . \ +----+ .
. +----+ . mip . +-------+ +-------+ .
. |MNs | . inside . | CN | | MNs | .
. |away| . IPsec . | 1..n | | home | .
. +----+ . . +-------+ +-------+ .
................... . .
................................
Figure 10
図10
Furthermore, this solution would leave the traffic between FA and MN unprotected, and as this link in particular may be a wireless link, this is clearly undesirable.
さらに、この解決策は、保護されていないFAとMN間のトラフィックを残して、特にこのリンクは無線リンクであってもよいように、これは明らかに望ましくありません。
An MN roaming outside the Intranet has to establish an IPsec tunnel to its home VPN gateway first, in order to be able to register with its home agent. This is because the MN cannot reach its HA (inside the private protected network) directly from the outside. This implies that the MIPv4 traffic from the MN to a node inside the Intranet is forced to run inside an IPsec tunnel, and thus that it will not be in the clear. This in turn leads to two distinct problems depending on whether the MN uses co-located or non-co-located modes to register with its HA.
イントラネットの外部ローミングMNがそのホームエージェントに登録できるようにするために、最初のホームVPNゲートウェイへのIPsecトンネルを確立しなければなりません。 MNは、外部から直接そのHA（プライベート保護されたネットワークの内部）に達することができないためです。これは、イントラネット内のノードへのMNからのMIPv4トラフィックがIPsecトンネル内で実行するように強制されていること、したがって、それは明らかにならないことを意味します。これは、順番にMNは、そのHAに登録するモードを共同設置使用するか、または非同じ場所に配置するかどうかに応じて、2つの異なる問題が生じます。
In co-located mode, the IPsec tunnel needs to be re-established on each IP subnet handoff, which will have performance implications on real-time applications and resource-constrained wireless networks.
共同設置モードでは、IPsecトンネルは、リアルタイムのアプリケーションおよびリソース制約ワイヤレスネットワークのパフォーマンスへの影響を有することになる各IPサブネットのハンドオフ、上で再確立する必要があります。
In non-co-located mode (i.e., using an FA care-of address), the problem becomes severe, as the MN may be unable to register with its HA through the FA because the FA cannot understand MIPv4 registration requests if they are encrypted in the IPsec tunnel (i.e., split tunneling is not supported). Even if the MN could reach the FA with non-encrypted registration requests (i.e., split tunneling is supported), and the requests going from the FA to the HA can pass through the VPN gateway, there would still be a problem with routing of data packets between the Intranet and the internet. This is because the VPN will not allow IP-in-IP-encapsulated packets from the FA to go through. And furthermore, ESP-encapsulated packets from the VPN gateway to the MN will be dropped by the FA, as it expects IP-in-IP-encapsulated traffic to the MN.
彼らは暗号化されている場合はFAはMIPv4の登録要求を理解することはできませんので、MNがFAを通じてHAに登録することができない可能性がなどの非同じ場所に配置モード（すなわち、FAの気付アドレスを使用して）では、この問題は、深刻になりますIPsecトンネルで（つまり、スプリットトンネリングがサポートされていません）。 MNは、非暗号化された登録要求（すなわち、スプリットトンネリングがサポートされている）、およびVPNゲートウェイを通過することができHAにFAから行くのリクエストでFAに到達できたとしても、まだデータのルーティングに問題があるだろうイントラネットとインターネットの間のパケット。 VPNは、FAからIP-に-IPカプセル化パケットが通過を許可しないためです。それはMNにIP-に-IPカプセル化トラフィックを期待して、さらに、MNへのVPNゲートウェイからESP-カプセル化されたパケットは、FAによって破棄されます。
This section describes guidelines for a solution to MIPv4 traversal across VPN gateways.
このセクションでは、VPNゲートウェイ間のMIPv4トラバーサルを解決するためのガイドラインを説明します。
o The solution MUST work with currently deployed VPN gateways. This is the whole raison d'etre of this investigation: Finding a way to deploy Mobile-IP in cases where a VPN solution is already in place.
Oソリューションは、現在展開VPNゲートウェイと連携しなければなりません。 VPNソリューションは、場所にすでにある場合にモバイルIPを展開する方法を見つける：これは、この調査の全体の存在意義です。
o The solution SHOULD minimize changes to existing VPN client/gateway software.
Oソリューションは、既存のVPNクライアント/ゲートウェイソフトウェアへの変更を最小限に抑える必要があります。
o The solution SHOULD NOT require any changes to existing IPsec or key-exchange standard protocols implemented by VPN gateways.
Oソリューションは、VPNゲートウェイによって実装、既存のIPsecの変更やキー交換の標準的なプロトコルを必要とすべきではありません。
o The solution SHOULD NOT require that the VPN gateway or the VPN client implement any new protocols in addition to the existing standard protocols.
Oソリューションは、VPNゲートウェイまたはVPNクライアントは、既存の標準プロトコルに加えて、任意の新しいプロトコルを実装することを要求すべきではありません。
o The solution MUST provide multi-vendor interoperability, whereby MIPv4 mobility agents, mobility clients (MN), VPN server, and VPN client solutions may come from four different vendors. This is typical for medium and large enterprises that purchase and deploy best-of-breed multi-vendor solutions for IP routing, VPNs, firewalls, etc.
Oソリューションは、MIPv4のモビリティエージェント、モビリティクライアント（MN）、VPNサーバー、およびVPNクライアントソリューションは、4つの異なるベンダーから来るかもしれないことにより、マルチベンダーの相互運用性を提供しなければなりません。これは、購入し、IPルーティング、VPNの、ファイアウォールなどのための最善のマルチベンダー・ソリューションを展開中・大規模企業のための典型的なものです
o The solution MUST adhere to MIPv4 protocol [RFC3344]. That is, the solution MUST NOT impose any changes that violate MIPv4 protocol.
O溶液は、MIPv4のプロトコル[RFC3344]に準拠する必要があります。つまり、ソリューションは、MIPv4のプロトコルに違反するすべての変更を課してはなりません。
o The solution MAY introduce new extensions to MIPv4 nodes per guidelines specified in the MIPv4 protocol [RFC3344]. However, in order to overcome barriers to deployment, it is highly desirable to avoid any changes to MIPv4 mobility agents such as the FA and HA.
Oソリューションは、MIPv4のプロトコル[RFC3344]で指定されたガイドラインあたりのMIPv4ノードへの新しい拡張機能を導入することができます。しかし、導入への障壁を克服するために、このようなFAとHAなどのMIPv4モビリティエージェントへの変更を回避することが非常に望ましいです。
o The solution MAY require more than one instance of MIPv4 running in parallel (multiple encapsulation).
O溶液は、並列（複数のカプセル化）で実行されているのMIPv4の複数のインスタンスを必要とするかもしれません。
o It is imperative to keep the key management overhead down to a minimum, in order to support fast handoffs across IP subnets. Therefore, the solution MUST propose a mechanism to avoid or minimize IPsec tunnel SA renegotiation and IKE renegotiation as the MN changes its current point of network attachment.
O IPサブネット間の高速ハンドオフをサポートするために、最低限までの鍵管理オーバーヘッドを維持することが不可欠です。したがって、解決策は、MNは、ネットワーク接続の現在の点を変更するようにIPsecトンネルSAの再ネゴシエーションとIKEの再ネゴシエーションを回避または最小化するためのメカニズムを提案しなければなりません。
o The solution complexity MUST increase at most linearly with the number of MNs registered and accessing resources inside the Intranet.
Oソリューションの複雑さは、イントラネット内の登録のMNの数とアクセスするリソースで最大直線的に増加しなければなりません。
o The solution MAY introduce additional header or tunneling overhead if needed.
必要に応じてO溶液は、追加ヘッダまたはトンネリング・オーバヘッドを導入することができます。
o The solution MAY introduce new MIPv4-compliant functional entities.
Oソリューションは、新しいMIPv4の準拠の機能エンティティを導入することができます。
o The solution MUST be able to work with the existing MIPv4 and IPsec NAT traversal solutions [RFC3519] [RFC3715] [RFC3947].
O溶液は、既存のMIPv4とIPsec NATトラバーサルソリューション[RFC3519]、[RFC3715]、[RFC3947]で動作できなければなりません。
o The solution MUST provide security that is not inferior to what is already provided to existing "nomadic computing" remote access users; i.e., for confidentiality, authentication, message integrity, protection against replay attacks, and related security services.
Oソリューションは、既存の「遊牧コンピューティング」のリモートアクセスユーザに提供されるものよりも劣っていないセキュリティを提供しなければなりません。すなわち、機密性、認証、メッセージの整合性、リプレイ攻撃からの保護、および関連するセキュリティサービスのため。
This document describes an existing problem and proposes guidelines for possible solutions; as such, its security implications are indirect, through the guidelines it proposes for the solutions. Section 5.10 gives the relevant security requirements.
この文書では、既存の問題を説明し、可能な解決策のためのガイドラインを提案しています。など、そのセキュリティへの影響は、それが解決策を提案しているガイドラインを通じて、間接的です。 5.10節は、関連するセキュリティ要件を与えます。
The authors who contributed text to this document were, in no particular order: Farid Adrangi, Milind Kulkarni, Gopal Dommety, Eli Gelasco, Qiang Zhang, Sami Vaarala, Dorothy Gellert, Nitsan Baider, and Henrik Levkowetz.
ファリドAdrangi、本部Milind Kulkarniさん、ゴパルDommety、イーライGelasco、強張、サミVaarala、ドロシーゲラート、Nitsan Baider、とヘンリクLevkowetz：この文書にテキストを貢献した著者は、順不同でした。
The authors would like to thank other contributors, especially Prakash Iyer, Mike Andrews, Ranjit Narjala, Joe Lau, Kent Leung, Alpesh Patel, Phil Roberts, Hans Sjostrand, Serge Tessier, Antti Nuopponen, Alan O'Neill, Gaetan Feige, and Brijesh Kumar, for their feedback and help in improving this document.
著者は、他の貢献者、特にプラカシュアイヤル、マイク・アンドリュース、ランジットNarjala、ジョー・ラウ、ケントレオン、Alpeshパテル、フィル・ロバーツ、ハンスSjostrand、セルジュテッシェ、アンティNuopponen、アラン・オニール、ガエタンFeige、およびBrijeshに感謝したいと思いますクマール、彼らのフィードバックと、この文書の改善に役立つため。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, May 2003.
、RFC 3519、2003年5月、 "ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル" [RFC3519] Levkowetz、H.とS. Vaarala、。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B.とW.ディクソン、 "IPsecでネットワークアドレス変換（NAT）の互換性の要件"、RFC 3715、2004年3月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A.、およびV.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、RFC 3947、2005年1月。
Authors' Addresses
著者のアドレス
Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro OR USA
ファリドAdrangiインテルコーポレーション2111 N.E.第25回アベニューヒルズボロOR USA
Phone: +1 503-712-1791 EMail: farid.adrangi@intel.com
電話：+1 503-712-1791電子メール：farid.adrangi@intel.com
Henrik Levkowetz Ericsson Research Torshamsgatan 23 SE-164 80 Stockholm SWEDEN
ヘンリクLevkowetzエリクソンリサーチ木ハムの道23 SE-164 80ストックホルムスウェーデン
Phone: +46 7 08 32 16 08 EMail: henrik@levkowetz.com
電話：+46 7 08 32 16 08 Eメール：henrik@levkowetz.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書では、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機能のための基金は現在、インターネット協会によって提供されます。