RFC5266 日本語訳
5266 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2Mobility and Multihoming (MOBIKE). V. Devarapalli, P. Eronen. June 2008. (Format: TXT=33186 bytes) (Also BCP0136) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group V. Devarapalli
Request for Comments: 5266 Wichorus
BCP: 136 P. Eronen
Category: Best Current Practice Nokia
June 2008
Devarapalliがコメントのために要求するワーキンググループV.をネットワークでつないでください: 5266Wichorus BCP: 136P.Eronenカテゴリ: 最も良い現在の練習ノキア2008年6月
Secure Connectivity and Mobility Using Mobile IPv4 and
IKEv2 Mobility and Multihoming (MOBIKE)
安全な接続性、モバイルIPv4を使用する移動性、IKEv2の移動性、およびマルチホーミング(MOBIKE)
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Abstract
要約
Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility.
彼らが企業で提供されたサービスに移動して、接続するとき、エンタープライズユーザは移動性と安全な接続性を必要とします。 ユーザが信頼されていないネットワークから企業に接続すると、安全な接続性が必要です。 ユーザが企業網の中、または、企業網の外で移行して、新しいIPアドレスを習得するとき、移動性は有益です。 このドキュメントは、安全な接続性と移動性を提供するのにモバイルIPv4(MIPv4)と移動性拡張子をIKEv2(MOBIKE)に使用することでソリューションについて説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Access Modes . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Access Mode: 'c' . . . . . . . . . . . . . . . . . . . 6
3.1.2. Access Mode: 'f' . . . . . . . . . . . . . . . . . . . 6
3.1.3. Access Mode: 'mc' . . . . . . . . . . . . . . . . . . 6
3.2. Mobility within the Enterprise . . . . . . . . . . . . . . 7
3.3. Mobility When outside the Enterprise . . . . . . . . . . . 7
3.4. Crossing Security Boundaries . . . . . . . . . . . . . . . 7
3.4.1. Operation When Moving from an Untrusted Network . . . 8
3.4.2. Operation When Moving from a Trusted Network . . . . . 9
4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Applicability to a Mobile Operator Network . . . . . 13
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 ソリューション概要. . . . . . . . . . . . . . . . . . . . . . 4 3.1。 モード. . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1にアクセスしてください。 モードにアクセスしてください: 'c'. . . . . . . . . . . . . . . . . . . 6 3.1.2。 モードにアクセスしてください: 'f'. . . . . . . . . . . . . . . . . . . 6 3.1.3。 モードにアクセスしてください: 'mc'. . . . . . . . . . . . . . . . . . 6 3.2。 エンタープライズ. . . . . . . . . . . . . . 7 3.3の中の移動性。 エンタープライズ. . . . . . . . . . . 7 3.4の外の移動性When。 セキュリティ境界. . . . . . . . . . . . . . . 7 3.4.1に交差しています。 信頼されていないネットワーク. . . 8 3.4.2から移行するときの操作。 信じられたネットワーク. . . . . 9 4から移行するときの操作。 NAT縦断. . . . . . . . . . . . . . . . . . . . . . . . 10 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 10 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 10 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 11 7.2。 携帯電話会社ネットワーク. . . . . 13への有益な参照. . . . . . . . . . . . . . . . . . 11付録A.の適用性
Devarapalli & Eronen Best Current Practice [Page 1] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[1ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
1. Introduction
1. 序論
A typical enterprise network consists of users connecting to the services from a trusted network (intranet), and from an untrusted network (Internet). The trusted and untrusted networks are typically separated by a demilitarized zone (DMZ). Access to the intranet is controlled by a firewall and a Virtual Private Network (VPN) gateway in the DMZ.
典型的な企業網は信じられたネットワーク(イントラネット)と、そして、信頼されていないネットワーク(インターネット)からサービスに接続するユーザから成ります。 非武装地帯(DMZ)によって信じられて信頼されていないネットワークは通常切り離されます。 イントラネットへのアクセスはDMZでファイアウォールとVirtual兵士のNetwork(VPN)ゲートウェイによって制御されます。
Enterprise users, when roaming on untrusted networks, most often have to authenticate themselves to the VPN gateway and set up a secure tunnel in order to access the intranet. The use of IPsec VPNs is very common to enable such secure connectivity to the intranet. When the user is on the trusted network, VPNs are not used. However, the users benefit tremendously when session mobility between subnets, through the use of Mobile IPv4, is available.
信頼されていないネットワークを移動するとき、エンタープライズユーザは、イントラネットにアクセスするためにたいていVPNゲートウェイに自分たちを認証して、安全なトンネルを設立しなければなりません。 IPsec VPNsの使用は、そのような安全な接続性をイントラネットに可能にするために非常に一般です。 ユーザが信じられたネットワークの一員であるときに、VPNsは使用されていません。 しかしながら、サブネットの間のセッションの移動性がモバイルIPv4の使用で利用可能であるときに、ユーザはものすごく利益を得ます。
There has been some work done on using Mobile IPv4 and IPsec VPNs to provide roaming and secure connectivity to an enterprise [RFC5265] [RFC4093]. The solution described in [RFC5265] was designed with certain restrictions, including requiring no modifications to the VPN gateways, and involves the use of two layers of MIPv4, with one home agent inside the intranet and one in the Internet or in the DMZ before the VPN gateway. The per-packet overhead is very high in this solution. It is also challenging to implement and have two instances of MIPv4 active at the same time on a mobile node. However, the solution described here is only applicable when Internet Key Exchange Protocol version 2 (IKEv2) IPsec VPNs are used.
企業[RFC5265][RFC4093]にローミングと安全な接続性を提供するのにモバイルIPv4とIPsec VPNsを使用するとき行われたいくらかの仕事がありました。 [RFC5265]で説明されたソリューションは、VPNゲートウェイへの変更を全く必要とするのを含まないある制限で設計されて、MIPv4の2つの層の使用にかかわります、イントラネットにおける1人のホームのエージェントとVPNゲートウェイの前の1がインターネットかDMZにある状態で。 1パケットあたりのオーバーヘッドはこのソリューションで非常に高いです。 また、同時にモバイルノードの上でMIPv4の2つのインスタンスをアクティブに実装して、するのもやりがいがあります。 しかしながら、インターネット・キー・エクスチェンジプロトコルバージョン2(IKEv2)IPsec VPNsが使用されているときだけ、ここで説明されたソリューションは適切です。
This document describes an alternate solution that does not require two layers of MIPv4. The solution described in this document uses Mobile IPv4 when the mobile node is on the trusted network and MOBIKE-capable IPsec VPNs when the mobile node is on the untrusted network. The mobile node uses the tunnel inner address (TIA) given out by the IPsec VPN gateway as the co-located care-of address (CoA) for MIPv4 registration. This eliminates the need for using an external MIPv4 home agent and the need for encapsulating the VPN tunnel inside a MIPv4 tunnel.
このドキュメントはMIPv4の2つの層を必要としない代替策について説明します。 モバイルノードが信頼されていないネットワークにあるとき、モバイルノードが信じられたネットワークとMOBIKEできるIPsec VPNsにあるとき、本書では説明されたソリューションはモバイルIPv4を使用します。 モバイルノードが共同見つけられるとしてIPsec VPNゲートウェイによって配られたトンネルの内側のアドレス(TIA)を使用する、注意、-、MIPv4登録のために(CoA)を扱ってください。 これは外部のMIPv4ホームのエージェントを使用する必要性とMIPv4トンネルの中でVPNトンネルをカプセル化する必要性を排除します。
The following assumptions are made for the solution described in this document.
以下の仮定は本書では説明されたソリューションのためにされます。
o IKEv2 [RFC4306] and IPsec [RFC4301] are used to set up the VPN
tunnels between the mobile node and the VPN gateway.
o IKEv2[RFC4306]とIPsec[RFC4301]は、モバイルノードとVPNゲートウェイの間のVPNトンネルを設立するのに使用されます。
o The VPN gateway and the mobile node support MOBIKE extensions as
defined in [RFC4555].
o VPNゲートウェイとモバイルノードは[RFC4555]で定義されるようにMOBIKEに拡大を支えます。
Devarapalli & Eronen Best Current Practice [Page 2] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[2ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
o When the mobile node is on the trusted network, traffic should not
go through the DMZ. Current deployments of firewalls and DMZs
consider the scenario where only a small amount of the total
enterprise traffic goes through the DMZ. Routing through the DMZ
typically involves stateful inspection of each packet by the
firewalls in the DMZ. Moreover, the DMZ architecture assumes that
the DMZ is less secure than the internal network. Therefore, the
DMZ-based architecture allows the least amount of traffic to
traverse the DMZ, that is, only traffic between the trusted
network and the external network. Requiring all normal traffic to
the mobile nodes to traverse the DMZ would negate this
architecture.
o モバイルノードが信じられたネットワークにあるとき、トラフィックはDMZを通るべきではありません。 ファイアウォールとDMZsの現在の展開は少量の総企業トラフィックだけがDMZを通るシナリオを考えます。 DMZを通したルート設定はDMZのファイアウォールのそばでそれぞれのパケットのステートフルインスペクションに通常かかわります。 そのうえ、DMZアーキテクチャは、DMZが内部のネットワークほど安全でないと仮定します。 したがって、DMZベースのアーキテクチャは信じられたネットワークと外部のネットワークの間にDMZを横断するトラフィック、すなわち、最少の量のトラフィックだけを許容します。 DMZを横断するためにすべての正常なトラフィックをモバイルノードに必要とすると、このアーキテクチャは否定されるでしょう。
o When the mobile node is on the trusted network and uses a wireless
access technology, confidentiality protection of the data traffic
is provided by the particular access technology. In some
networks, confidentiality protection MAY be available between the
mobile node and the first hop access router, in which case it is
not required at layer 2.
o モバイルノードが信じられたネットワークにあって、ワイヤレス・アクセス技術を使用すると、特定のアクセス技術でデータ通信量の秘密性保護を提供します。 いくつかのネットワークでは、秘密性保護がモバイルノードと最初のホップアクセスルータの間で利用可能であるかもしれない、その場合、それは層2で必要ではありません。
This document also presents a solution for the mobile node to detect when it is on a trusted network, so that the IPsec tunnel can be dropped and the mobile node can use Mobile IP in the intranet.
また、このドキュメントはいつ、それが信じられたネットワークにあるかを検出するためにモバイルノードのためのソリューションを提示します、モバイルノードがIPsecトンネルを下げることができて、イントラネットにモバイルIPを使用できるように。
IPsec VPN gateways that use IKEv1 [RFC2409] are not addressed in this document.
IKEv1[RFC2409]を使用するIPsec VPNゲートウェイが本書では扱われません。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Many of the following terms are defined in [RFC5265], but are repeated here to make this document self-contained.
次の用語の多くが、[RFC5265]で定義されますが、このドキュメントを自己充足的にするようにここで繰り返されます。
FA: Mobile IPv4 foreign agent.
ファ: モバイルIPv4外国人のエージェント。
Co-CoA: co-located care-of address.
ココア: 共同見つけられている、注意、-、アドレス。
FA-CoA: foreign agent care-of address.
ファ-CoA: 外国人のエージェント、注意、-、アドレス。
FW: firewall.
fw: ファイアウォール。
i-FA: Mobile IPv4 foreign agent residing in the trusted (intranet)
network.
i-ファ: 信じられた(イントラネット)ネットワークで住んでいるモバイルIPv4外国人のエージェント。
Devarapalli & Eronen Best Current Practice [Page 3] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[3ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
i-HA: Mobile IPv4 home agent residing in the trusted (intranet)
network.
i、-、ハ、: 信じられた(イントラネット)ネットワークで住んでいるモバイルIPv4ホームのエージェント。
i-MIP: The mobile node uses the home agent in the internal network.
i-MIP: モバイルノードは内部のネットワークにホームのエージェントを使用します。
VPN-TIA: VPN tunnel inner address. This address is given out by the
VPN gateway during IKE negotiation and is routable in the trusted
network.
VPN-ティア: VPNは内側のアドレスにトンネルを堀ります。 このアドレスは、IKE交渉の間、VPNゲートウェイによって配られていて、信じられたネットワークで発送可能です。
mVPN: VPN with MOBIKE functionality.
mVPN: MOBIKEの機能性があるVPN。
The following access modes are used in explaining the protocol. The access modes are explained in more detail in [RFC5265].
以下のアクセス・モードはプロトコルについて説明する際に使用されます。 アクセス・モードはさらに詳細に[RFC5265]で説明されます。
f: i-MIP with FA-CoA
f: ファ-CoAとi-MIP
c: i-MIP with Co-CoA
c: ココアがあるi-MIP
mc: i-MIP with MOBIKE-enabled VPN, with VPN-TIA as Co-CoA
mc: MOBIKEによって可能にされたVPN、ココアとしてのVPN-TIAとi-MIP
3. Solution Overview
3. ソリューション概要
The mobile node is configured with a home address that remains the same irrespective of whether the mobile node is inside or outside the enterprise network. The mobile node is also reachable at the same home address irrespective of its current point of attachment. When the mobile node is connected to the intranet directly, it uses Mobile IP for internal mobility.
モバイルノードは企業網の中、または、企業網の外にモバイルノードがあることの如何にかかわらず同じままで残っているホームアドレスによって構成されます。 また、現在の接着点の如何にかかわらずモバイルノードも同じホームアドレスで届いています。 モバイルノードが直接イントラネットに接続されるとき、それは内部の移動性にモバイルIPを使用します。
When the mobile node roams and connects to an untrusted network outside the enterprise, it sets up a VPN tunnel to the VPN gateway. However, it still maintains a valid binding cache entry at the i-HA. It uses the VPN-TIA, allocated by the VPN gateway, as the co-located CoA for registration with the i-HA. If the VPN-TIA changes or if the mobile node moves and connects to another VPN gateway, then it sends a Registration Request to the i-HA using the new co-located CoA.
モバイルノードが企業の外で信頼されていないネットワークに移動して、接続するとき、それはVPNトンネルをVPNゲートウェイに設立します。 しかしながら、それはi-HAでまだ有効な拘束力があるキャッシュエントリーを維持しています。 それはi-HAとの登録に共同見つけられたCoAとしてVPNゲートウェイによって割り当てられたVPN-TIAを使用します。 モバイルノードが別のVPNゲートウェイにVPN-TIAが変化するか、移行して、または接続するなら、それは、新しい共同見つけられたCoAを使用することでRegistration Requestをi-HAに送ります。
If the mobile node moves while outside the enterprise and its access network changes, it uses the MOBIKE protocol to update the VPN gateway of its current address. The internal home agent is not aware of the mobile node's movement as long as the mobile node is attached to the same VPN gateway and the TIA remains the same.
企業とそのアクセスがネットワークでつなぐ外部が変化しますが、モバイルノードが移行するなら、それは、現在のアドレスのVPNゲートウェイをアップデートするのにMOBIKEプロトコルを使用します。 モバイルノードが同じVPNゲートウェイに添付されて、TIAが同じままで残っている限り、内部のホームのエージェントはモバイルノードの動きを意識していません。
Figure 1 depicts the network topology assumed for the solution. It also shows the possible mobile node locations and access modes.
図1はソリューションのために想定されたネットワーク形態について表現します。 また、それは可能なモバイルノード位置とアクセス・モードを示しています。
Devarapalli & Eronen Best Current Practice [Page 4] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[4ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
{home} (MN) [i-HA]
\ /
.-+---+-.
( )
[mVPN] `--+----'
! !
.--+--. [R]
( DMZ ) !
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {mc} (MN) {c} (MN) {f}
家へ帰ってください、(ミネソタ)[i、-、ハ、]、\/.-+---+ ( )[mVPN]、'、--、+、'----'[R](非武装地帯)! . . --+--.-+'-------+--. `--+--' .-----+------. ( ) ! ( ) (外部が+--[R]を網で覆う、-、-、--、[FW] ----[R]--+ 内部のネット) ( ) ( ) `--+---------' `---+---+----'//\[DHCP][R][DHCP][R][R][i-ファ]\/\/\/+--+'---. .-+-+--. .--+--+-. ( ) ( ) ( ) `---+---' `--+---' `---+---'、(Mn)mc(ミネソタ)c(ミネソタ)、'f
Figure 1: Network Topology Using MIPv4 and MOBIKE
図1: MIPv4とMOBIKEを使用するネットワーク形態
The solution described above results in a Mobile IP tunnel inside an IPsec tunnel. The Mobile IP tunnel is between the mobile node and the home agent, and the IPsec tunnel is between the mobile node (MN) and the mVPN gateway. The mobile node MUST reverse tunnel through the home agent [RFC3024] when the Mobile IP tunnel is inside an IPsec tunnel.
ソリューションはモバイルIPトンネル内部で結果を超えてIPsecトンネルについて説明しました。 モバイルノードとホームのエージェントの間には、モバイルIPトンネルがあります、そして、モバイルノード(ミネソタ)とmVPNゲートウェイの間には、IPsecトンネルがあります。 IPsecトンネルの中にモバイルIPトンネルがあるとき、モバイルノードはホームのエージェント[RFC3024]を通してトンネルを逆にしなければなりません。
The overhead of running a Mobile IP tunnel inside an IPsec tunnel can be avoided by having the Mobile IP foreign agent functionality on the VPN gateway. This is out of scope for this document and is further described in [MEGHANA].
VPNゲートウェイに関するモバイルIP外国エージェントの機能性を持っていることによって、IPsecトンネルの中でモバイルIPトンネルを動かすオーバーヘッドを避けることができます。 これは、このドキュメントのための範囲の外にあって、[MEGHANA]でさらに説明されます。
Whenever the mobile node attaches to a new link, it may encounter a foreign agent. The mobile node MUST not use the foreign agent care-of address with the i-HA when attached to an untrusted access network. The default behavior for the mobile node is to always configure an address from the access link using DHCP. The mobile node then checks if it is attached to a trusted access network by sending a Registration Request to the i-HA in the co-located care-of address mode. If the mobile node discovers that it is attached to a trusted access network, then it MAY start using a foreign agent care-of address with the i-HA. In order to do this, the mobile node has to perform a new registration with the i-HA.
モバイルノードが新しいリンクに付くときはいつも、それは外国人のエージェントに遭遇するかもしれません。 モバイルノードが外国人のエージェントを使用してはいけない、注意、-、信頼されていないアクセスネットワークに付けられると、i-HAと共に扱います。 モバイルノードのためのデフォルトの振舞いはDHCPを使用することでアクセスリンクからのアドレスをいつも構成することです。 次に、モバイルノードが、それが共同見つけられるところのi-HAにRegistration Requestを送ることによって信じられたアクセスネットワークに付けられているかどうかチェックする、注意、-、モードを扱ってください。 モバイルノードが、それが信じられたアクセスネットワークに付けられていると発見するなら外国人のエージェントを使用し始めるかもしれない、注意、-、i-HAとのアドレス。 これをするために、モバイルノードはi-HAとの新規登録を実行しなければなりません。
Devarapalli & Eronen Best Current Practice [Page 5] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[5ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
The mobile node can use a foreign agent on a untrusted access network, if there is an external home agent that the mobile node is able to use. The use of an external home agent in the untrusted access network and a home agent in the trusted access network at the same time is described in detail in [RFC5265].
モバイルノードは信頼されていないアクセスネットワークで外国人のエージェントを使用できます、モバイルノードが使用できる外部のホームのエージェントがいれば。 同時にの信じられたアクセスネットワークの信頼されていないアクセスネットワークとホームのエージェントにおける外部のホームのエージェントの使用は[RFC5265]で詳細に説明されます。
Some IPsec VPN implementations allow a host to send traffic directly to the Internet when attached to an untrusted network. This traffic bypasses the IPsec tunnel with the VPN gateway. This document does not prevent such traffic from being sent out from the host, but there will be no mobility or session continuity for the traffic. Any data traffic that is sent through the Mobile IP tunnel with the home agent is always sent through the VPN gateway.
いくつかのIPsec VPN実装で、信頼されていないネットワークに付けられると、ホストは直接インターネットにトラフィックを送ることができます。 このトラフィックはVPNゲートウェイでIPsecトンネルを迂回させます。 このドキュメントは、そのようなトラフィックがホストから出されるのを防ぎませんが、トラフィックのためのどんな移動性もセッションの連続もないでしょう。 VPNゲートウェイを通していつもホームのエージェントがいるモバイルIPトンネルを通して送られるどんなデータ通信量も送ります。
3.1. Access Modes
3.1. アクセス・モード
The following access modes are used in the solution described in this document.
以下のアクセス・モードは本書では説明されたソリューションに使用されます。
3.1.1. Access Mode: 'c'
3.1.1. モードにアクセスしてください: 'c'
This access mode is standard Mobile IPv4 [RFC3344] with a co-located care-of address. The mobile node must detect that it is connected to an internal trusted network before using this mode. The co-located care-of address is assigned by the access network to which the mobile node is attached.
このアクセス・モードがaが共同見つけられている標準のモバイルIPv4[RFC3344]である、注意、-、アドレス。 これを使用する前に、それが接続される必須が検出するモバイルノードはモードをネットワークでつなぎますインターナルが、信じた。 共同見つけられる、注意、-、アドレスはモバイルノードが付けているアクセスネットワークによって割り当てられます。
3.1.2. Access Mode: 'f'
3.1.2. モードにアクセスしてください: 'f'
This access mode is standard Mobile IPv4 [RFC3344] with a foreign agent care-of address. The mobile node can use this mode only when it detects that it is connected to an internal trusted network and also detects a foreign agent on the access network.
このアクセス・モードが外国人のエージェントがいる標準のモバイルIPv4[RFC3344]である、注意、-、アドレス。 モバイルノードはそれがそれを検出するこのモードしか使用できません。それは、内部の信じられたネットワークに接続されて、また、アクセスネットワークに外国人のエージェントを検出します。
3.1.3. Access Mode: 'mc'
3.1.3. モードにアクセスしてください: 'mc'
This access mode involves using both Mobile IPv4 and a MOBIKE-enabled IPsec VPN gateway, resulting in a Mobile IP tunnel inside an IPsec tunnel. The mobile node uses the VPN-TIA as the co-located CoA for registering with the home agent. This mode is used only when the mobile node is attached to an untrusted network and is required to set up an IPsec tunnel with a VPN gateway to gain access to the trusted network.
このアクセス・モードは、モバイルIPv4とMOBIKEによって可能にされたIPsec VPNゲートウェイの両方を使用することを伴います、IPsecトンネルの中でモバイルIPトンネルをもたらして。 モバイルノードは、ホームのエージェントとともに記名するのに共同見つけられたCoAとしてVPN-TIAを使用します。 モバイルノードが信頼されていないネットワークに添付されて、信じられたネットワークへのアクセスを得るためにVPNゲートウェイでIPsecトンネルを設立しなければならないときだけ、このモードは使用されています。
Devarapalli & Eronen Best Current Practice [Page 6] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[6ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
3.2. Mobility within the Enterprise
3.2. エンタープライズの中の移動性
When the mobile node is inside the enterprise network and attached to the intranet, it uses Mobile IPv4 [RFC3344] for subnet mobility. The mobile node always configures a care-of address through DHCP on the access link and uses it as the co-located care-of address. The mobile node MAY use a foreign agent care-of address, if a foreign agent is available. However, the foreign agent care-of address is used only when the mobile node is attached to the trusted access network. The mobile node attempts Foreign Agent discovery and CoA address acquisition through DHCP simultaneously in order to avoid the delay in discovering a foreign agent when there is no foreign agent available. The mobile node maintains a valid binding cache entry at all times at the home agent mapping the home address to the current CoA. Whenever the mobile node moves, it sends a Registration Request to update the binding cache entry.
モバイルノードがイントラネットに企業網の中にあって、付属しているとき、それはサブネットの移動性に、モバイルIPv4[RFC3344]を使用します。 モバイルノードがいつも構成する、注意、-、アドレス、アクセスでのDHCPを通してリンクして、共同位置としてそれを使用する、注意、-、アドレス。 モバイルノードが外国人のエージェントを使用するかもしれない、注意、-、外国人のエージェントが手があくなら、扱います。 しかしながら、外国人のエージェント、注意、-、モバイルノードが信じられたアクセスネットワークに添付されるときだけ、アドレスは使用されています。 モバイルノードは、同時に、手があいているどんな外国人のエージェントもいないとき外国人のエージェントを発見する遅れを避けるためにDHCPを通したForeignエージェント発見とCoAアドレス獲得を試みます。 モバイルノードは現在のCoAにホームアドレスを写像するホームのエージェントでいつも有効な拘束力があるキャッシュエントリーを維持します。 モバイルノードが移行するときはいつも、それは、拘束力があるキャッシュエントリーをアップデートするためにRegistration Requestを送ります。
The Mobile IP signaling messages between the mobile node and the home agent are authenticated as described in [RFC3344].
モバイルノードとホームのエージェントの間のモバイルIPシグナリングメッセージは[RFC3344]で説明されるように認証されます。
The mobile node maintains a valid binding cache entry at the home agent even when it is outside the enterprise network.
企業網の外にそれがありさえするときさえ、モバイルノードはホームのエージェントで有効な拘束力があるキャッシュエントリーを維持します。
3.3. Mobility When outside the Enterprise
3.3. エンタープライズの外の移動性When
When the mobile node is attached to an untrusted network, it sets up an IPsec VPN tunnel with the VPN gateway to gain access to the enterprise network. If the mobile node moves and its IP address changes, it initiates the MOBIKE protocol [RFC4555] to update the address on the VPN gateway.
モバイルノードが信頼されていないネットワークに添付されるとき、それは、企業網へのアクセスを得るためにVPNゲートウェイでIPsec VPNトンネルを設立します。 モバイルノード移動とそのIPが変化を扱うなら、それは、VPNゲートウェイに関するアドレスをアップデートするために、MOBIKEプロトコル[RFC4555]を開始します。
The mobile node maintains a binding at the home agent even when it is outside the enterprise network. If the TIA changes due to the mobile node re-connecting to the VPN gateway or attaching to a different VPN gateway, the mobile node should send a Registration Request to its home agent to update the binding cache with the new TIA.
企業網の外にそれがありさえするときさえ、モバイルノードはホームのエージェントで結合を維持します。 TIAがVPNゲートウェイに再接続するか、または異なったVPNゲートウェイに付くモバイルノードのため変化するなら、モバイルノードは、新しいTIAと共に拘束力があるキャッシュをアップデートするためにホームのエージェントにRegistration Requestを送るはずです。
3.4. Crossing Security Boundaries
3.4. セキュリティ境界に交差しています。
Security boundary detection is based on the reachability of the i-HA from the mobile node's current point of attachment. Whenever the mobile node detects a change in network connectivity, it sends a Registration Request to the i-HA without any VPN encapsulation. If the mobile node receives a Registration Reply with the Trusted Networks Configured (TNC) extension from the i-HA, then it assumes that it is on a trusted network. The TNC extension is described in [RFC5265]. The mobile node MUST check that the Registration Reply is integrity protected using the mobile node-home agent mobility
セキュリティ境界検出はモバイルノードの現在の接着点からのi-HAの可到達性に基づいています。 モバイルノードがネットワークの接続性における変化を検出するときはいつも、それは少しもVPNカプセル化なしでRegistration Requestをi-HAに送ります。 モバイルノードがi-HAからTrusted Networks Configured(TNC)拡張子があるRegistration Replyを受けるなら、それは、信じられたネットワークにあると仮定します。 TNC拡張子は[RFC5265]で説明されます。 モバイルノードは、Registration Replyがモバイルノードホームエージェントの移動性を使用することで保護された保全であることをチェックしなければなりません。
Devarapalli & Eronen Best Current Practice [Page 7] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[7ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
security association before concluding it is attached to a trusted network. This security boundary detection is based on the mechanism described in [RFC5265] to detect attachment to the internal trusted network. The mobile node should re-transmit the Registration Request if it does not receive the Registration Reply within a timeout period. The number of times the mobile node should re-transmit the Registration Request and the timeout period for receiving the Registration Reply are configurable on the mobile node.
それを結論づける前のセキュリティ協会は信じられたネットワークに付けられています。 このセキュリティ境界検出は内部の信じられたネットワークへの付属を見つけるために[RFC5265]で説明されたメカニズムに基づいています。 タイムアウト時間以内にRegistration Replyを受けないなら、モバイルノードはRegistration Requestを再送するはずです。 モバイルノードがRegistration Replyを受けるためにRegistration Requestとタイムアウト時間を再送するはずであるという回の数はモバイルノードで構成可能です。
When the mobile node is attached to an untrusted network and is using an IPsec VPN to the enterprise network, the ability to send a Registration Request to the i-HA without VPN encapsulation would require some interaction between the IPsec and MIPv4 modules on the mobile node. This is local to the mobile node and out of scope for this document.
モバイルノードが信頼されていないネットワークに取り付けられて、企業網にIPsec VPNを使用しているとき、VPNカプセル化なしでRegistration Requestをi-HAに送る能力はモバイルノードの上でIPsecとMIPv4モジュールとのいくつかの相互作用を必要とするでしょう。 このドキュメントにおいて、これはモバイルノードと範囲から地方です。
If the mobile node has an existing VPN tunnel to its VPN gateway, it MUST send a MOBIKE message at the same time as the registration request to the i-HA whenever the IP address changes. If the mobile node receives a response from the VPN gateway, but not from the i-HA, it assumes it is outside the enterprise network. If it receives a response from the i-HA, then it assumes it is inside the enterprise network.
モバイルノードが既存のVPNトンネルをVPNゲートウェイに持っているなら、それはi-HAへの登録要求と同時にIPアドレスが変化するときはいつも、MOBIKEメッセージを送らなければなりません。 モバイルノードがVPNゲートウェイから応答を受けますが、i-HAから受けるというわけではないなら、それは、企業網の外にあると仮定します。 i-HAから応答を受けるなら、それは、企業網の中にあると仮定します。
There could also be some out-of-band mechanisms that involve configuring the wireless access points with some information that the mobile node can recognize as access points that belong to the trusted network in an enterprise network. Such mechanisms are beyond the scope of this document.
また、モバイルノードがアクセスポイントとしてそれを認識できるという何らかの情報があるワイヤレス・アクセスポイントが企業網で信じられたネットワークのもの、を構成することを伴ういくつかのバンドで出ているメカニズムがあるかもしれません。 そのようなメカニズムはこのドキュメントの範囲を超えています。
The mobile node should not send any normal traffic while it is trying to detect whether it is attached to the trusted or untrusted network. This is described in more detail in [RFC5265].
それが、信じられたか信頼されていないネットワークに付けられているかどうか検出していようとしている間、モバイルノードは少しの正常なトラフィックも送るはずがありません。 これはさらに詳細に[RFC5265]で説明されます。
3.4.1. Operation When Moving from an Untrusted Network
3.4.1. 信頼されていないネットワークから移行するときの操作
When the mobile node is outside the enterprise network and attached to an untrusted network, it has an IPsec VPN tunnel with its mobility aware VPN gateway, and a valid registration with a home agent on the intranet with the VPN-TIA as the care-of address.
いつとしてモバイルノードが信頼されていないネットワークに企業網の外にあって、付属していて、移動性の意識しているVPNゲートウェイでIPsec VPNトンネルを持っていて、VPN-TIAがあるイントラネットのホームのエージェントと共に有効な登録を持っているか、注意、-、アドレス
If the mobile node moves and its IP address changes, it performs the following steps:
モバイルノード移動とそのIPが変化を扱うなら、以下のステップを実行します:
1a. Initiate an IKE mobility exchange to update the VPN gateway with
the current address. If the new network is also untrusted, this
will be enough for setting up the connectivity. If the new
network is trusted, and if the VPN gateway is reachable, this
1a。 IKE移動性交換を起こして、現在のアドレスでVPNゲートウェイをアップデートしてください。 また、新しいネットワークも信頼されていないなら、これは接続性をセットアップするのに十分になるでしょう。 新しいネットワークが信じられて、VPNゲートウェイが届くならこれ
Devarapalli & Eronen Best Current Practice [Page 8] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[8ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
exchange will allow the mobile node to keep the VPN state alive
while on the trusted side. If the VPN gateway is not reachable
from inside, then this exchange will fail.
交換で、モバイルノードは信じる側にある間、VPN状態を生かすことができるでしょう。 VPNゲートウェイが内部から届かないと、この交換は失敗するでしょう。
1b. At the same time as step 1, send a Mobile IPv4 Registration
Request to the internal home agent without VPN encapsulation.
1b。 ステップ1と同時に、VPNカプセル化なしで内部のホームのエージェントにモバイルIPv4 Registration Requestを送ってください。
2. If the mobile node receives a Registration Reply to the request
sent in step 1b, then the current subnet is a trusted subnet,
and the mobile node can communicate without VPN tunneling. The
mobile node MAY tear down the VPN tunnel.
2. モバイルノードがステップ1bで送られた要求にRegistration Replyを受けるなら、現在のサブネットは信じられたサブネットです、そして、モバイルノードはVPNトンネリングなしで交信できます。 モバイルノードはVPNトンネルを取りこわすかもしれません。
3.4.2. Operation When Moving from a Trusted Network
3.4.2. 信じられたネットワークから移行するときの操作
When the mobile node is inside the enterprise and attached to the intranet, it does not use a VPN tunnel for data traffic. It has a valid binding cache entry at its home agent. If the VPN gateway is reachable from the trusted network, the mobile node MAY have valid IKEv2 security associations with its VPN gateway. The IPsec security associations can be created when required. The mobile node may have to re-negotiate the IKEv2 security associations to prevent them from expiring.
モバイルノードがイントラネットに企業の中にあって、付属しているとき、それはデータ通信量にVPNトンネルを使用しません。 それはホームのエージェントに有効な拘束力があるキャッシュエントリーを持っています。 VPNゲートウェイが信じられたネットワークから届くなら、モバイルノードには、VPNゲートウェイとの有効なIKEv2セキュリティ協会があるかもしれません。 必要であると、IPsecセキュリティ協会を創設できます。 モバイルノードはそれらが期限が切れるのを防ぐIKEv2セキュリティ協会を再交渉しなければならないかもしれません。
If the mobile node moves and its IP address changes, it performs the following steps:
モバイルノード移動とそのIPが変化を扱うなら、以下のステップを実行します:
1. Initiate an IKE mobility exchange to update the VPN gateway with
the current address, or if there is no VPN connection, then
establish a VPN tunnel with the gateway from the new local IP
address. If the new network is trusted, and if the VPN gateway
is reachable, this exchange will allow the mobile node to keep
the VPN state alive, while in the trusted side. If the new
network is trusted and if the VPN gateway is not reachable from
inside, then this exchange will fail.
1. 現在のアドレスでVPNゲートウェイをアップデートするためにIKE移動性交換を起こすか、またはVPN接続が全くなければ、新しいローカルアイピーアドレスからゲートウェイがあるVPNトンネルを確立してください。 新しいネットワークが信じられて、VPNゲートウェイが届くと、モバイルノードはこの交換でVPN状態を生かすことができるでしょう、信じる側で。 新しいネットワークが信じられて、VPNゲートウェイが内部から届かないと、この交換は失敗するでしょう。
2. At the same time as step 1, send a Mobile IPv4 Registration
Request to the internal home agent without VPN encapsulation.
2. ステップ1と同時に、VPNカプセル化なしで内部のホームのエージェントにモバイルIPv4 Registration Requestを送ってください。
3. If the mobile node receives a Registration Reply to the request
sent in step 2, then the current subnet is a trusted subnet, and
the mobile node can communicate without VPN tunneling, using only
Mobile IP with the new care-of address.
3. モバイルノードがステップ2で送られた要求にRegistration Replyを受けるなら、現在のサブネットは信じられたサブネットです、そして、モバイルノードはVPNトンネリングなしで交信できます、新しさがあるモバイルIPだけを使用して注意、-、アドレス。
4. If the mobile node didn't receive the response in step 3, and if
the VPN tunnel is successfully established and registered in step
1, then the mobile node sends a Registration Request over the VPN
tunnel to the internal home agent. After receiving a
Registration Reply from the home agent, the mobile node can start
4. VPNトンネルがモバイルノードがステップ3で応答を受けないで、首尾よく確立されて、ステップ1に登録されるなら、モバイルノードは内部のホームのエージェントへのVPNトンネルの上にRegistration Requestを送ります。 ホームのエージェントからRegistration Replyを受けた後に、モバイルノードは始まることができます。
Devarapalli & Eronen Best Current Practice [Page 9] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[9ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
communicating over the VPN tunnel with the Mobile IP home
address.
VPNトンネルの上でモバイルIPホームアドレスで交信します。
4. NAT Traversal
4. NAT縦断
There could be a Network Address Translation (NAT) device between the mobile node and the home agent in any of the access modes, 'c', 'f', and 'mc', and between the mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 NAT traversal, as described in [RFC3519], should be used by the mobile node and the home agent in access modes 'c' or 'f', when there is a NAT device present. When using access mode, 'mc', IPsec NAT traversal [RFC3947] [RFC3948] should be used by the mobile node and the VPN gateway, if there is a NAT device present. Typically, the TIA would be a routable address inside the enterprise network. But in some cases, the TIA could be from a private address space associated with the VPN gateway. In such a case, Mobile IPv4 NAT traversal should be used in addition to IPsec NAT traversal in the 'mc' mode.
アクセス・モード、'c'、'f'、および'mc'のどれかにおけるモバイルノードとホームのエージェントの間と、そして、モバイルノードとVPNゲートウェイの間には、アクセス・モード'mc'にNetwork Address Translation(NAT)デバイスがあるかもしれません。 [RFC3519]で説明されるモバイルIPv4NAT縦断はアクセス・モード'c'か'f'でモバイルノードとホームのエージェントによって使用されるべきです、存在しているNATデバイスがあるとき。 アクセス・モード、'mc'を使用するとき、IPsec NAT縦断[RFC3947][RFC3948]はモバイルノードとVPNゲートウェイによって使用されるべきです、存在しているNATデバイスがあれば。 TIAは企業網で通常、発送可能アドレスでしょう。 しかし、いくつかの場合、TIAはVPNゲートウェイに関連しているプライベート・アドレススペースから来ているかもしれません。 このような場合には、モバイルIPv4NAT縦断は'mc'モードにおけるIPsec NAT縦断に加えて使用されるべきです。
5. Security Considerations
5. セキュリティ問題
Enterprise connectivity typically requires very strong security, and the solution described in this document was designed keeping this in mind.
エンタープライズの接続性は非常に強いセキュリティを通常必要とします、そして、本書では説明されたソリューションは、これを覚えておきながら、設計されました。
Security concerns related to the mobile node detecting that it is on a trusted network and thereafter dropping the VPN tunnel are described in [RFC5265].
VPNトンネルを下げる信じられたネットワークとその後モバイルノード検出に関連した安全上の配慮が[RFC5265]で説明されます。
When the mobile node sends a Registration Request to the i-HA from an untrusted network that does not go through the IPsec tunnel, it will reveal the i-HA's address, its own identity including the NAI and the home address, and the Authenticator value in the authentication extensions to the untrusted network. This may be a concern in some deployments.
モバイルノードが行かない信頼されていないネットワークからIPsecトンネルまでRegistration Requestをi-HAに送るとき、それはi-HAのアドレス、認証拡大でNAI、ホームアドレス、およびAuthenticator値を信頼されていないネットワークに含むそれ自身のアイデンティティを明らかにするでしょう。 これはいくつかの展開で関心であるかもしれません。
Please see [RFC4555] for MOBIKE-related security considerations, and [RFC3519], [RFC3947] for security concerns related to the use of NAT traversal mechanisms for Mobile IPv4 and IPsec.
MOBIKE関連のセキュリティ問題に関して[RFC4555]を見て、NAT縦断メカニズムのモバイルIPv4とIPsecの使用に関連する安全上の配慮のために[RFC3519]、[RFC3947]を見てください。
6. Acknowledgments
6. 承認
The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval Shah, and John Cruz for their participation in developing this solution.
作者はこの解決策を見いだすことへの彼らの参加についてヘンリーHaverinen、サンドロスグレッチ、Dhavalシャー、およびジョン・クルスに感謝したがっています。
Devarapalli & Eronen Best Current Practice [Page 10] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[10ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
The authors would also like to thank Henrik Levkowetz, Jari Arkko, TJ Kniveton, Vidya Narayanan, Yaron Sheffer, Hans Sjostrand, Jouni Korhonen, and Sami Vaarala for reviewing the document.
また、作者は、ドキュメントを再検討して頂いて、Henrik Levkowetz、ヤリArkko、TJ Kniveton、Vidyaナラヤナン、ヤロン・シェーファー、ハンス・シェストランド、Jouni Korhonen、およびサミVaaralaに感謝したがっています。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3344] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC4555]Eronen、2006年6月のP.、「IKEv2移動性とマルチホーミングプロトコル(MOBIKE)」RFC4555。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across
IPsec-Based VPN Gateways", RFC 5265, June 2008.
[RFC5265] VaaralaとS.とE.Klovning、「IPsecベースのVPNゲートウェイの向こう側のモバイルIPv4縦断」、RFC5265、2008年6月。
7.2. Informative References
7.2. 有益な参照
[RFC4093] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile
IPv4 Traversal of Virtual Private Network (VPN) Gateways",
RFC 4093, August 2005.
[RFC4093] Adrangi、F.、およびH.Levkowetz、「問題声明:」 「仮想私設網(VPN)ゲートウェイのモバイルIPv4縦断」、RFC4093、2005年8月。
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, January 2001.
[RFC3024]モンテネグロ、G. RFC3024、「モバイルIPのためにTunnelingを逆にして、改訂され」て、2001年1月。
[MEGHANA] Sahasrabudhe, M. and V. Devarapalli, "Optimizations to
Secure Connectivity and Mobility", Work in Progress,
February 2008.
[MEGHANA] 「安全な接続性と移動性への最適化」というSahasrabudhe、M.、およびV.Devarapalliは進歩、2008年2月に働いています。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519,
April 2003.
[RFC3519]LevkowetzとH.とS.Vaarala、「ネットワークアドレス変換(NAT)デバイスのモバイルIP縦断」、RFC3519、2003年4月。
[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縦断の交渉」、RFC3947、2005年1月。
Devarapalli & Eronen Best Current Practice [Page 11] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[11ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC3948]HuttunenとA.とSwanderとB.とボルペとV.とDiBurro、L.とM.Stenberg、「IPsec超能力パケットのUDPカプセル化」RFC3948(2005年1月)。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
Devarapalli & Eronen Best Current Practice [Page 12] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[12ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
Appendix A. Applicability to a Mobile Operator Network
携帯電話会社ネットワークへの付録A.の適用性
The solution described in this document can also be applied to a Mobile Operator's network when the Operator deploys heterogeneous access networks and some of the access networks are considered as trusted networks and others as untrusted networks. Figure 2 illustrates such a network topology.
アクセスネットワークの中にはまた、Operatorが、異種のアクセスがネットワークであると配布するとき本書では説明されたソリューションはモバイルOperatorのネットワークに適用できて、信頼されていないネットワークとしての信じられたネットワークと他のものであるとみなされるものもあります。 図2はそのようなネットワーク形態を例証します。
+----------------------+
| +----+ |
+----------------+ | |i-HA| |
| | | +----+ |
(MN)----+ trusted +---+ |
| access network | | internal network |
+----------------+ | |
| |
+----------+-----------+
|
|
|
[mVPN]
+----------------+ |
| | |
(MN)----+ untrusted +--------------+
{mc} | access network |
+----------------+
+----------------------+ | +----+ | +----------------+ | |i、-、ハ。| | | | | +----+ | (ミネソタ)----+は+を信じました。---+ | | アクセスネットワーク| | 内部のネットワーク| +----------------+ | | | | +----------+-----------+ | | | [mVPN] +----------------+ | | | | (ミネソタ)----+ 信頼されていない+--------------+ mc| アクセスネットワーク| +----------------+
Figure 2: Network Topology of a Mobile Operator with Trusted and
Untrusted Networks
図2: 信じられて信頼されていないネットワークの携帯電話会社のネットワーク形態
An IPsec VPN gateway provides secure connectivity to the Operator's internal network for mobile nodes attached to an untrusted access network. The VPN gateway supports MOBIKE extensions so that the IPsec tunnels survive any IP address change when the mobile node moves while attached to the untrusted access networks.
IPsec VPNゲートウェイは信頼されていないアクセスネットワークに添付されたモバイルノードのためにOperatorの内部のネットワークに安全な接続性を提供します。 VPNゲートウェイがMOBIKEに拡大をサポートするので、モバイルノードが信頼されていないアクセスネットワークに付けられている間、移行すると、IPsecトンネルはどんなIPアドレス変化も乗り切っています。
When the mobile node is attached to the trusted access network, it uses Mobile IP with the i-HA. It uses the IP address obtained from the trusted access network as the co-located care-of address to register with the i-HA. If a foreign agent is available in the trusted access network, the mobile node may use a foreign agent care-of address. If the mobile node moves and attaches to an untrusted access network, it sets up an IPsec tunnel with the VPN gateway to access the Operator's internal network. It uses the IPsec TIA as the co-located care-of address to register with the i-HA thereby creating a Mobile IP tunnel inside an IPsec tunnel.
モバイルノードが信じられたアクセスネットワークに添付されるとき、それはi-HAとモバイルIPを使用します。 共同見つけられるとして信じられたアクセスネットワークから得られたIPアドレスを使用する、注意、-、i-HAに登録するアドレス。 外国人のエージェントが信じられたアクセスネットワークで手があくなら、モバイルノードが外国人のエージェントを使用するかもしれない、注意、-、アドレス。 モバイルノードが信頼されていないアクセスネットワークに移行して、付くなら、それは、Operatorの内部のネットワークにアクセスするためにVPNゲートウェイでIPsecトンネルを設立します。 共同見つけられるとしてIPsec TIAを使用する、注意、-、その結果IPsecトンネルの中でモバイルIPトンネルを作成するi-HAに登録するアドレス。
Devarapalli & Eronen Best Current Practice [Page 13] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[13ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
When the mobile node is attached to the trusted access network, it can either be attached to a foreign link in the trusted network or to the home link directly. This document does not impose any restrictions.
モバイルノードが信じられたアクセスネットワークに添付されるとき、直接信じられたネットワークにおける外国リンク、または、ホームのリンクにそれを付けることができます。 このドキュメントは少しの制限も課しません。
Authors' Addresses
作者のアドレス
Vijay Devarapalli Wichorus 3590 North First Street San Jose, CA 95134 USA
ビジェイDevarapalli Wichorus3590の北の最初に、通りサンノゼ、カリフォルニア95134米国
EMail: vijay@wichorus.com
メール: vijay@wichorus.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
パシEronenノキアリサーチセンター私書箱407フィン-00045Nokia Groupフィンランド
EMail: pasi.eronen@nokia.com
メール: pasi.eronen@nokia.com
Devarapalli & Eronen Best Current Practice [Page 14] RFC 5266 MIPv4 and MOBIKE interworking June 2008
Devarapalli&Eronen Best Current Practice[14ページ]RFC5266MIPv4と6月が2008であると織り込むMOBIKE
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Devarapalli & Eronen Best Current Practice [Page 15]
Devarapalli&Eronenの最も良い現在の習慣[15ページ]
一覧
スポンサーリンク
