[要約] 要約：RFC 4093は、モバイルIPv4がVPNゲートウェイをトラバースする際の問題を説明しています。 目的：このRFCの目的は、モバイルIPv4がVPNゲートウェイを効果的にトラバースできるようにするための問題の特定と解決策の提案です。
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
問題ステートメント：仮想プライベートネットワーク（VPN）ゲートウェイのモバイルIPv4トラバーサル
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).
Copyright（c）The Internet Society（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）ゲートウェイを介してインターネットに接続されているネットワークにMobile-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は、ネットワークポイントに関係なくセッションモビリティのために設計されたため、2つのドメイン間にシームレスなセッションモビリティを持つことが望ましいでしょう。残念ながら、現在のMIP標準は、重要な顧客セグメントに対するこの約束には至らない：モビリティサポートを追加したい企業ユーザー（リモートアクセスにVPNを使用）は、イントラネットの外側からイントラネットの外側を継続的にアクセスする必要があるため、モビリティサポートを追加する必要があるため、別のサブネット、または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].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉はしばしば大文字になります。「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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).
次の図のネットワークトポロジは、パブリックネットワーク（つまり、インターネット）に接続されたイントラネットで構成されています。ここでは、「イントラネット」という言葉は、VPNゲートウェイによって保護されているプライベートネットワーク（プライベートアドレス[RFC1918]が通常使用される）、そしておそらくレイヤー3透明または非透明なファイアウォールを指します。プライベートアドレスを使用する場合、非透明なファイアウォールは、2つのアドレス領域（つまり、イントラネットとインターネット）の間でネットワークアドレス翻訳者（NAT）またはネットワークアドレスポート翻訳者（NAPT）ブリッジングとしても機能します。
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 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.
ファイアウォールは、VPNゲートウェイの両側に配置できます。これらは内側および外側のファイアウォールと呼ばれます。内側と外側のファイアウォールは、通常、アウトバウンドトラフィック（つまり、イントラネットからインターネットまで）とインバウンドトラフィック（つまり、インターネットからイントラネットへ）をそれぞれ検査します。ファイアウォールが存在する場合、モバイル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.
1）VPNドメイン（イントラネット）は信頼できるネットワークと見なされ、イントラネット内で許可されているユーザーも信頼できるものであり、2）それは一般的なVPN展開慣行であるため、暗号化は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つのケースで解決すべき共存の問題はありませんが、セクション2.3および2.5のシナリオのシナリオが含まれています。
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ゲートウェイによって保護されているイントラネット内に展開されており、イントラネット外のMNSが直接到達可能ではありません。
..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]の直接適用は、イントラネット内のユーザーにモビリティを提供するために成功裏に使用されます。ただし、イントラネット外のモバイルユーザーは、VPNゲートウェイを介してイントラネットリソース（MIPエージェントなど）のみにアクセスすることができます。これにより、内部内に認証されたIPSECトラフィックのみが可能になります。これは、MIPV4トラフィックがIPSEC内で実行されなければならないことを意味し、2つの異なる問題につながります。
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.
1. 外国ネットワークにFAが展開されている場合（CDMA 2000のように）、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.
2. 共同配置モードでは、登録が成功する可能性がありますが、MNがネットワーク添付ファイルのポイントを変更するたびにVPNトンネルを再交渉する必要があります。
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ゲートウェイとともにVPNドメインの境界（DMZなど）に展開され、イントラネットの内側または外側のMNSが直接到達可能です。
..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を介してルーティングされることを意味します（MNSがイントラネットの外側または内側にあるかどうかに関係なく）。大企業の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.
この展開は、2つの異なる構成で使用できます：「IPSEC-ESPトンネル内」と「MIPV4トンネル内のIPSEC-ESP」の「MIPV4」。「IPSEC-ESPトンネル内のMIPV4」は、セクション2.1のシナリオと同じ問題を抱えています。（つまり、MIPV4登録はFAを介して登録を行うと不可能になり、さらに、共同配置モードでは、MNが添付ファイルを変更するたびにVPNトンネルを再交渉する必要があります。）-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を実行すると、セクション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.
このシナリオでは、MIPV4は、以下の図4に示すように、イントラネットの外側（例：オペレーターネットワーク）の外側に展開されています。
..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トンネルにカプセル化されています。）。これは、MNSが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.
これは、セクション2.3で説明されている展開シナリオに似ており、VPNゲートウェイ/HAがローカルリンクに座っているという違いがあります。この場合、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.
この展開は、MIPV4トンネル内で実行されているIPSEC-ESPに関する技術的な問題なしに今日機能します。IPSEC-ESPトンネル内でMIPVを実行する場合、セクション2.1と同じ問題があるため、MIPV4トンネル内で実行されているIPSEC-ESPが展開されます。この展開は、大規模で分散されたセキュリティ境界線のために、大規模な展開（数千人のユーザーのオーダー）には実用的ではありません。
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.
このセクションでは、セクション2.1の展開シナリオに対応するローミングシナリオについて説明します。ここでは、MNがイントラネットの内側または外側のローミングに関係なく、イントラネットリソースに継続的にアクセスする必要があります。シナリオは、図6に示すように、IPSECベースのVPNゲートウェイによって保護されている、マルチスブネットのMIPV4対応イントラネット（以下イントラネットまたはVPNドメインと呼ばれる）に基づいて構築されます。
....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トンネルのエンドポイントはMNとVPNゲートウェイにあります。これは、セクション2.1で説明されているシナリオがあると仮定して）MNからHAまでのモバイルIPトンネルをIPSECトンネル内にカプセル化します。以下の図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 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.
MNは、添付ファイルのポイント（DHCP [RFC2131]またはその他の手段を介して）でアドレスを取得し、VPNゲートウェイにIPSECトンネルをセットアップし、その後、IPSECトンネルを介してHAに正常に登録できます。IPSECトンネルSA（セキュリティ協会）は、SPI（セキュリティパラメーターインデックス）、MNのIP宛先アドレス（つまり、添付ファイルのポイントで取得されたアドレス）、および説明されているセキュリティプロトコル（AHまたはESP）識別子で構成されるトリプレットによって識別されます。[RFC2401]で。これは、MNのIP宛先アドレスが各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に到達できるように分割トンネリングを許可するポリシーを持っている場合、FAはHAが外部から到達可能であり、イントラネットセキュリティポリシーが許可されない限り、VPNゲートウェイを通過することができません。VPNゲートウェイをバイパスするためのMIP登録パケット。
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からのパケットは、IP-in-IP [RFC2003]を使用してFAによってカプセル化され、VPNゲートウェイがドロップされ、VPNゲートウェイからのパケットがESPペイロード（IP-in-IPが内部にあります）があります。ドロップします（MNへのIP-in-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を意味します。この場合、トンネルのエンドポイントはFAとVPNゲートウェイにあるため、この場合は正常に動作します。ただし、Access NetworksのFA（ワイヤレスホットスポットやCDMA 2000ネットワークなど）が特定の企業ネットワークとセキュリティ関連を持つことは期待できないため、これは一般的なモビリティケースでは特に現実的ではありません。
..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（プライベート保護ネットワーク内）に到達できないためです。これは、MIPV4イントラネット内のノードへのMIPV4トラフィックがIPSECトンネル内で実行されることを余儀なくされ、したがって明確にならないことを意味します。これにより、MNがCo-Located Modesを使用して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.
非Co-Locatedモード（つまり、FAのケアオブアドレスを使用する）では、FAが暗号化されている場合にMIPV4登録要求を理解できないため、MNがFAを介してHAに登録できないため、問題は深刻になります。IPSECトンネルでは（つまり、分割トンネルはサポートされていません）。MNが暗号化されていない登録要求でFAに到達できる（つまり、分割トンネリングがサポートされている場合）、FAからHAへのリクエストはVPNゲートウェイを通過できますが、データのルーティングにはまだ問題があります。イントラネットとインターネットの間のパケット。これは、VPNがFAからIP-in-IPカプセル化されたパケットを許可しないためです。さらに、VPNゲートウェイからMNへのESPエンコール化パケットは、MNへのIP-in-IPカプセル化されたトラフィックが予想されるため、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 ソリューションの複雑さは、登録されたMNSの数とイントラネット内のリソースにアクセスすると、最も直線的に増加する必要があります。
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.
この文書にテキストを提供した著者は、Farid Adrangi、Milind Kulkarni、Gopal Dommety、Eli Gelasco、Qiang Zhang、Sami Vaarala、Dorothy Gellert、Nitsan Baider、Henrik 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.
著者は、他の貢献者、特に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、およびBrijestに感謝したいと思います。Kumar、フィードバックとこのドキュメントの改善に役立ちます。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, May 2003.
[RFC3519] Levkowetz、H。およびS. Vaarala、「ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル」、RFC 3519、2003年5月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B。およびW. Dixon、「Ipsec-Networkアドレス翻訳（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. Volpe、「IKEにおけるNat-Traversalの交渉」、RFC 3947、2005年1月。
Authors' Addresses
著者のアドレス
Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro OR USA
ファリッド・アドラギ・インテル・コーポレーション2111 N.E.25番街ヒルズボロまたはアメリカ
Phone: +1 503-712-1791
EMail: farid.adrangi@intel.com
Henrik Levkowetz Ericsson Research Torshamsgatan 23 SE-164 80 Stockholm SWEDEN
Henrik Levkowetz Ericsson Research Torshamsgatan 23 Se-164 80 Stockholm Sweden
Phone: +46 7 08 32 16 08
EMail: henrik@levkowetz.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。