[要約] RFC 6612は、Proxy Mobile IPv6（PMIPv6）とMobile IPv6（MIPv6）の相互作用に関するシナリオと関連する問題について説明しています。このRFCの目的は、PMIPv6とMIPv6の統合に関するガイドラインを提供することです。
Internet Engineering Task Force (IETF) G. Giaretta, Ed.
Request for Comments: 6612 Qualcomm
Category: Informational May 2012
ISSN: 2070-1721
Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues
プロキシモバイルIPv6（PMIPv6）とモバイルIPv6（MIPv6）間の相互作用：シナリオと関連する問題
Abstract
概要
The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care. This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms. Solutions and recommendations to enable these scenarios are also described.
同じネットワークでプロキシモバイルIPv6（PMIPv6）とモバイルIPv6（MIPv6）を使用するには、注意が必要です。このドキュメントでは、このような混合使用が適切であるシナリオについて説明し、2つのメカニズム間の相互作用の必要性を指摘します。これらのシナリオを有効にするためのソリューションと推奨事項についても説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6612.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6612で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview of the Scenarios and Related Issues ....................4
3.1. Issues Related to Scenario A.1 .............................8
3.2. Issues Related to Scenario A.2 .............................8
3.3. Issues Related to Scenario B ..............................10
4. Analysis of Possible Solutions .................................11
4.1. Solutions Related to Scenario A.1 .........................11
4.2. Solutions Related to Scenario A.2 .........................13
4.2.1. Mobility from a PMIPv6 Domain to a
Non-PMIPv6 Domain ..................................14
4.2.2. Mobility from a Non-PMIPv6 Domain to a
PMIPv6 Domain ......................................15
4.3. Solutions Related to Scenario B ...........................15
5. Security Considerations ........................................16
6. Contributors ...................................................16
7. Acknowledgements ...............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network-based IP mobility protocol standardized by the IETF. In some deployment scenarios, this protocol will be deployed together with Mobile IPv6 (MIPv6) [RFC6275], for example, with PMIPv6 as local mobility protocol and MIPv6 as global mobility protocol. While the usage of a local mobility protocol should not have implications on how global mobility is managed, since PMIPv6 is partially based on MIPv6 signaling and data structure, some considerations are needed to understand how the protocols interact and how the different scenarios can be enabled.
プロキシモバイルIPv6（PMIPv6）[RFC5213]は、IETFによって標準化されたネットワークベースのIPモビリティプロトコルです。一部の展開シナリオでは、このプロトコルはモバイルIPv6（MIPv6）[RFC6275]とともに展開されます。たとえば、ローカルモビリティプロトコルとしてPMIPv6、グローバルモビリティプロトコルとしてMIPv6が使用されます。ローカルモビリティプロトコルの使用は、グローバルモビリティの管理方法に影響を与えるべきではありませんが、PMIPv6は部分的にMIPv6シグナリングとデータ構造に基づいているため、プロトコルがどのように相互作用し、さまざまなシナリオを有効にすることができるかを理解するには、いくつかの考慮事項が必要です。
Some standardization fora are also investigating more complex scenarios where the mobility of some nodes is handled using Proxy Mobile IPv6, while other nodes use Mobile IPv6; or the mobility of a node is managed in turn by a host-based and a network-based mechanism. This also needs to be analyzed as a possible deployment scenario.
一部の標準化フォーラムでは、一部のノードのモビリティがプロキシモバイルIPv6を使用して処理され、他のノードがモバイルIPv6を使用する、より複雑なシナリオも調査しています。または、ノードのモビリティは、ホストベースおよびネットワークベースのメカニズムによって管理されます。これも可能な展開シナリオとして分析する必要があります。
This document provides a taxonomy of the most common scenarios that require direct interaction between MIPv6 and PMIPv6. The list is not meant to be exhaustive. Moreover, this document presents and identifies most of the issues pertaining to these scenarios and discusses possible means and mechanisms that are recommended to enable them.
このドキュメントでは、MIPv6とPMIPv6間の直接の相互作用を必要とする最も一般的なシナリオの分類法を提供します。このリストは完全なものではありません。さらに、このドキュメントでは、これらのシナリオに関連するほとんどの問題を提示および識別し、それらを有効にするために推奨される可能な手段とメカニズムについて説明します。
General mobility terminology can be found in [RFC3753]. The following acronyms are used in this document:
一般的なモビリティ用語は、[RFC3753]にあります。このドキュメントでは、次の頭字語が使用されています。
o AR (Access Router): first hop router
o AR（アクセスルーター）：ファーストホップルーター
o BCE (Binding Cache Entry): an entry of the MIPv6 or PMIPv6 binding cache
o BCE（バインディングキャッシュエントリ）：MIPv6またはPMIPv6バインディングキャッシュのエントリ
o LMA (Local Mobility Anchor): the PMIPv6 mobility anchor as specified in [RFC5213]
o LMA（ローカルモビリティアンカー）：[RFC5213]で指定されているPMIPv6モビリティアンカー
o MAG (Mobility Access Gateway): the PMIPv6 client as specified in [RFC5213]
o MAG（Mobility Access Gateway）：[RFC5213]で指定されているPMIPv6クライアント
o MN-HoA: the Home Address (HoA) of a Mobile Node (MN) in a PMIPv6 domain
o MN-HoA：PMIPv6ドメイン内のモバイルノード（MN）のホームアドレス（HoA）
o MN-HNP: the IPv6 prefix that is always present in the Router Advertisements that the MN receives when it is attached to any of the access links in that PMIPv6 domain (MN-HoA always belongs to this prefix.)
o MN-HNP：MNがそのPMIPv6ドメインのアクセスリンクのいずれかに接続されたときにMNが受信するルーターアドバタイズメントに常に存在するIPv6プレフィックス（MN-HoAは常にこのプレフィックスに属します。）
o MIPv6-HoA: the HoA the MN includes in MIPv6 Binding Update messages
o MIPv6-HoA：MNがMIPv6バインディング更新メッセージに含めるHoA
o MIPv6-CoA: the Care-of Address the MN includes in MIPv6 Binding Update messages
o MIPv6-CoA：MNがMIPv6バインディング更新メッセージに含める気付アドレス
Several scenarios can be identified where MIPv6 and PMIPv6 are deployed in the same network. This document not only focuses on scenarios where the two protocols are used by the same MN to manage local and global mobility but also investigates more complex scenarios where the protocols are more tightly integrated or where there is a coexistence of nodes that do or do not implement MIPv6.
MIPv6とPMIPv6が同じネットワークに展開されているいくつかのシナリオを特定できます。このドキュメントでは、ローカルとグローバルのモビリティを管理するために同じMNが2つのプロトコルを使用するシナリオに焦点を当てるだけでなく、プロトコルがより緊密に統合されている、または実装するノードと実装しないノードが共存するより複雑なシナリオについても調査しますMIPv6。
In particular, the scenario space can be split into hierarchical deployments and alternative deployments of Mobile IP (MIP) and Proxy Mobile IP (PMIP). Hierarchical deployments are scenarios where the two mobility protocols are used in the same network in a hierarchical manner for global and local mobility management. Alternative deployments are scenarios where only one of the two protocols is used for mobility management of a given MN.
特に、シナリオ空間は、モバイルIP（MIP）とプロキシモバイルIP（PMIP）の階層配置と代替配置に分割できます。階層展開は、2つのモビリティプロトコルがグローバルおよびローカルのモビリティ管理のために階層的に同じネットワークで使用されるシナリオです。代替展開は、2つのプロトコルのうち1つだけが特定のMNのモビリティ管理に使用されるシナリオです。
The following hierarchical scenarios are identified:
次の階層シナリオが識別されます。
Scenario A.1: In this scenario, PMIPv6 is used as a network-based local mobility management protocol whereas MIPv6 is used as a global mobility management protocol. This interaction is very similar to the interaction between Hierarchical Mobile IPv6 (HMIPv6) and MIPv6 [RFC5380]; MIPv6 is used to manage mobility among different access networks, while the mobility within the access network is handled by PMIPv6. The address managed by PMIPv6 (i.e., the MN-HoA) is registered as the Care-of Address by the MN at the Home Agent (HA). This means that the HA has a BCE for MIPv6-HoA that points to the MN-HoA.
シナリオA.1：このシナリオでは、ネットワークベースのローカルモビリティ管理プロトコルとしてPMIPv6が使用され、グローバルモビリティ管理プロトコルとしてMIPv6が使用されます。この相互作用は、階層型モバイルIPv6（HMIPv6）とMIPv6 [RFC5380]の間の相互作用と非常によく似ています。 MIPv6はさまざまなアクセスネットワーク間のモビリティを管理するために使用されますが、アクセスネットワーク内のモビリティはPMIPv6によって処理されます。 PMIPv6によって管理されるアドレス（つまり、MN-HoA）は、MNによってホームエージェント（HA）で気付アドレスとして登録されます。これは、HAにMN-HoAを指すMIPv6-HoAのBCEがあることを意味します。
The following figure illustrates this scenario.
次の図は、このシナリオを示しています。
+----+
| HA | MIPv6-HoA -> MN-HoA
+----+
/\
/ \
+-------------/----\--------------+
( / \ ) Global Mobile IPv6
( / \ ) Domain
+----------/----------\-----------+
/ \
+----+ +----+
MN-HoA -> MAG1 |LMA1| |LMA2|
+----+ +----+
//\\ \\
+----//--\\---+ +-----\\------+
( // \\ ) ( \\ ) Local Mobility Network
( // \\ ) ( \\ ) PMIPv6 domain
+-//--------\\+ +--------\\---+
// \\ \\
// \\ \\
// \\ \\
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
| | |
[MN]
Figure 1: Scenario A.1
図1：シナリオA.1
Scenario A.2: In this scenario, the MN is moving across different access networks, some of them supporting PMIPv6 and some others not supporting it. Therefore, the MN is roaming from an access network where the mobility is managed through a network-based solution to an access network where a host-based management (i.e., Mobile IPv6) is needed. This scenario may have different sub-scenarios depending on the relations between the MIPv6 home network and the PMIPv6 domain. The following figure illustrates an example of this scenario, where the MN is moving from an access network where PMIPv6 is supported (i.e., MAG functionality is supported) to a network where PMIPv6 is not supported (i.e., MAG functionality is not supported by the AR). This implies that the home link of the MN is actually a PMIPv6 domain. In this case, the MIPv6-HoA is equal to the MN-HoA (i.e., the address managed by PMIPv6).
シナリオA.2：このシナリオでは、MNは、PMIPv6をサポートしているものとサポートしていないものがあるさまざまなアクセスネットワーク間を移動しています。したがって、MNは、モビリティがネットワークベースのソリューションを通じて管理されているアクセスネットワークから、ホストベースの管理（つまり、モバイルIPv6）が必要なアクセスネットワークにローミングしています。このシナリオには、MIPv6ホームネットワークとPMIPv6ドメイン間の関係に応じて、異なるサブシナリオが含まれる場合があります。次の図は、このシナリオの例を示しています。MNは、PMIPv6がサポートされている（つまり、MAG機能がサポートされている）アクセスネットワークから、PMIPv6がサポートされていない（つまり、MAG機能がARでサポートされていない）ネットワークに移動しています。 ）。これは、MNのホームリンクが実際にはPMIPv6ドメインであることを意味します。この場合、MIPv6-HoAはMN-HoA（つまり、PMIPv6によって管理されるアドレス）と同じです。
MIPv6-HoA == MN-HoA -> MAG1
+------+
|HA/LMA|-----------------------+
+------+ |
//\\ |
+-------//--\\--------+ |
( // \\ PMIPv6 ) |
( // \\ domain) +--------------+
+----//--------\\-----+ ( Non-PMIPv6 )
// \\ ( domain )
// \\ +--------------+
// \\ |
+----+ +----+ +----+
|MAG1| |MAG2| | AR |
+----+ +----+ +----+
| | |
[MN]
Figure 2: Scenario A.2
図2：シナリオA.2
In the scenario illustrated in Figure 2, the non-PMIPv6 domain can actually also be a different PMIPv6 domain that handles a different MN_HoA. The following figure illustrates this sub-case: the MIPv6- HoA is equal to the MN_HoA; however, when the MN hands over to MAG3, it gets a different IP address (managed by LMA2 using PMIPv6) and registers it as a MIPv6 CoA.
図2に示すシナリオでは、非PMIPv6ドメインは、実際には、異なるMN_HoAを処理する別のPMIPv6ドメインにすることもできます。次の図は、このサブケースを示しています。MIPv6-HoAはMN_HoAと同じです。ただし、MNがMAG3にハンドオーバーすると、別のIPアドレス（PMIPv6を使用してLMA2によって管理される）を取得し、それをMIPv6 CoAとして登録します。
MIPv6-HoA == MN-HoA -> MAG_1
+-------+
|HA/LMA1|-----------------------+
+-------+ |
//\\ +----+
+-------//--\\--------+ |LMA2|
( // \\ home ) +----+
( // \\ PMIPv6) +------||------+
( // \\domain) ( ||visited)
+---//----------\\----+ ( ||PMIPv6 )
// \\ ( ||domain )
// \\ +------||------+
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
| | |
[MN]
(a)
（a）
MIPv6-HoA -> MN_CoA
+-------+
|HA/LMA1|-----------------------+
+-------+ |
//\\ +----+
+-------//--\\--------+ |LMA2| MN_CoA -> MAG3
( // \\ home ) +----+
( // \\ PMIPv6) +------||------+
( // \\domain) ( ||visited)
+---//----------\\----+ ( ||PMIPv6 )
// \\ ( ||domain )
// \\ +------||------+
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
| | |
[MN]
(b)
（b）
Figure 3: Scenario A.2 with Visited PMIPv6 Domain
図3：PMIPv6ドメインにアクセスしたシナリオA.2
The following alternative deployment has been identified:
次の代替展開が確認されています。
Scenario B: In this scenario, some MNs use MIPv6 to manage their
movements while others rely on a network-based mobility solution
provided by the network as they don't support Mobile IPv6. There may
be a common mobility anchor that acts as MIPv6 Home Agent and PMIPv6
LMA, depending on the type of the node as depicted in the figure.
However, the LMA and HA can also be separated, and this has no impact
on the mobility of the nodes.
+--------+
| HA/LMA |
+--------+
+------+ +------+
| MAG1 | | MAG2 |
+------+ +------+
+-----------+
| IPv6 host | ----------------->
+-----------+ movement
+----------+
| MIPv6 MN | ----------------->
+----------+ movement
Figure 4: Scenario B
図4：シナリオB
Note that some of the scenarios can be combined. For instance, Scenario B can be combined with Scenario A.1 or Scenario A.2.
一部のシナリオは組み合わせることができることに注意してください。たとえば、シナリオBはシナリオA.1またはシナリオA.2と組み合わせることができます。
The following sections describe some possible issues for each scenario. Respective recommendations are described in Section 4.3. The specifications considered as a baseline for the analysis are the following: [RFC6275], [RFC4877], and [RFC5213].
次のセクションでは、各シナリオで発生する可能性のある問題について説明します。それぞれの推奨事項については、セクション4.3で説明します。分析のベースラインと見なされる仕様は、[RFC6275]、[RFC4877]、および[RFC5213]です。
This scenario is very similar to other hierarchical mobility schemes, including an HMIPv6-MIPv6 scheme. No issues have been identified in this scenario. Note that a race condition where the MN registers the CoA at the HA before the CoA is actually bound to the MAG at the LMA is not possible. The reason is that per the PMIPv6 specification [RFC5213], the MAG does not forward any packets sent by the MN until the PMIPv6 tunnel is up, regardless the mechanism used for address allocation.
このシナリオは、HMIPv6-MIPv6スキームを含む他の階層モビリティスキームに非常に似ています。このシナリオでは問題は確認されていません。 CoAが実際にLMAでMAGにバインドされる前に、MNがHAでCoAを登録する競合状態は不可能であることに注意してください。その理由は、PMIPv6仕様[RFC5213]に従い、MAGは、アドレス割り当てに使用されるメカニズムに関係なく、PMIPv6トンネルが起動するまで、MNから送信されたパケットを転送しないためです。
Section 4.1 describes one message flow in case PMIPv6 is used as a local mobility protocol and MIPv6 is used as a global mobility protocol.
セクション4.1では、PMIPv6がローカルモビリティプロトコルとして使用され、MIPv6がグローバルモビリティプロトコルとして使用される場合の1つのメッセージフローについて説明します。
This section highlights some considerations that are applicable to scenario A.2.
このセクションでは、シナリオA.2に適用できるいくつかの考慮事項について説明します。
1. HoA management and lookup key in the binding cache
1. バインディングキャッシュ内のHoA管理とルックアップキー
* In MIPv6 [RFC6275], the lookup key in the binding cache is the HoA of the MN. In particular, the base specification [RFC6275] doesn't require the MN to include any identifier, such as the MN-ID [RFC4283], in the Binding Update message other than its HoA. As described in [RFC4877], the identifier of the MN is known by the Home Agent after the Internet Key Exchange Protocol (IKEv2) exchange, but this is not used in the MIPv6 signaling or as a lookup key for the binding cache. On the other hand, as specified in [RFC5213], a Proxy Binding Update contains the home prefix of the MN, the MN-ID and does not include the HoA of the MN (since it may not be known by the MAG and consequently by the HA/LMA). The lookup key in the binding cache of the LMA is either the home prefix or the MN-ID. This implies that lookup keys for MIPv6 and PMIPv6 registrations are different. Because of that, when the MN moves from its home network (i.e., from the PMIPv6 domain) to the foreign link, the Binding Update sent by the MN is not identified by the HA as an update of the Proxy BCE containing the home prefix of the MN, but a new binding cache entry is created. Therefore, PMIPv6 and MIPv6 will always create two different BCEs in the HA/LMA, which implies that the HA and LMA are logically separated. How to handle the presence of the two BCEs for the same MN is described in Section 4.2.
* MIPv6 [RFC6275]では、バインディングキャッシュの検索キーはMNのHoAです。特に、基本仕様[RFC6275]では、MNがHoA以外のバインディングアップデートメッセージにMN-ID [RFC4283]などの識別子を含める必要はありません。 [RFC4877]で説明されているように、MNの識別子はインターネットキー交換プロトコル（IKEv2）交換後にHAによって認識されますが、これはMIPv6シグナリングやバインディングキャッシュのルックアップキーとしては使用されません。一方、[RFC5213]で指定されているように、Proxy Binding UpdateにはMNのホームプレフィックスとMN-IDが含まれており、MNのHoAは含まれていません（MAGによって認識されないため、 HA / LMA）。 LMAのバインディングキャッシュ内のルックアップキーは、ホームプレフィックスまたはMN-IDのいずれかです。これは、MIPv6とPMIPv6登録のルックアップキーが異なることを意味します。そのため、MNがホームネットワークから（つまり、PMIPv6ドメインから）外部リンクに移動すると、MNによって送信されたバインディングアップデートは、HAによって、ホームプレフィックスを含むプロキシBCEのアップデートとして識別されません。 MN、ただし新しいバインディングキャッシュエントリが作成されます。したがって、PMIPv6とMIPv6は常にHA / LMAに2つの異なるBCEを作成します。これは、HAとLMAが論理的に分離されていることを意味します。同じMNの2つのBCEの存在を処理する方法については、セクション4.2で説明します。
2. MIPv6 de-registration Binding Update deletes PMIPv6 binding cache entry
2. MIPv6登録解除バインディング更新はPMIPv6バインディングキャッシュエントリを削除します
* When the MN moves from a MIPv6 foreign network to the PMIPv6 home domain, the MAG registers the MN at the LMA by sending a Proxy Binding Update. Subsequently, the LMA updates the MN's BCE with the MAG address and the MAG emulates the MN's home link. Upon detection of the home link, the MN will send a de-registration Binding Update to its home agent. It is necessary to make sure that the de-registration of the MIPv6 Binding Update does not change the PMIPv6 BCE just created by the MAG.
* MNがMIPv6外部ネットワークからPMIPv6ホームドメインに移動すると、MAGはプロキシバインディングアップデートを送信して、MNをLMAに登録します。その後、LMAはMNのBCEをMAGアドレスで更新し、MAGはMNのホームリンクをエミュレートします。ホームリンクが検出されると、MNは登録解除バインディングアップデートをホームエージェントに送信します。 MIPv6バインディングアップデートの登録解除が、MAGによって作成されたばかりのPMIPv6 BCEを変更しないことを確認する必要があります。
3. Race condition between Binding Update and Proxy Binding Update messages (Sequence Numbers and Timestamps)
3. バインディング更新メッセージとプロキシバインディング更新メッセージ（シーケンス番号とタイムスタンプ）間の競合状態
* MIPv6 and PMIPv6 use different mechanisms for handling re-ordering of registration messages and they are sent by different entities. In MIPv6, Binding Update messages that are sent by the MN to the home agent are ordered by the sequence numbers. The other side, in PMIPv6, Proxy Binding Update messages that are sent by the MAG to the LMA are ordered by a timestamp option. When the MN moves from one access where Mobile IP is used to another access when Proxy Mobile IP is used, delay in the mobility signaling sent may imply adverse situations. For example, if the MN sends a Mobile IP Binding Update from access A before moving to access B and this Binding Update gets delayed (e.g., a refresh Binding Update), the Binding Update may reach the combined LMA/HA after the Proxy Binding Update sent by the MAG, re-directing packets to access A even after the MN has moved to access B.
* MIPv6とPMIPv6は、登録メッセージの並べ替えを処理するために異なるメカニズムを使用し、それらは異なるエンティティによって送信されます。 MIPv6では、MNからホームエージェントに送信されるBinding Updateメッセージは、シーケンス番号順になっています。一方、PMIPv6では、MAGからLMAに送信されるProxy Binding Updateメッセージは、タイムスタンプオプションによって順序付けされます。 MNがモバイルIPが使用されている1つのアクセスから、プロキシモバイルIPが使用されている別のアクセスに移動する場合、送信されるモビリティシグナリングの遅延により、不利な状況が発生する可能性があります。たとえば、MNがアクセスAからモバイルIPバインディング更新を送信してからアクセスBに移動し、このバインディング更新が遅延した場合（バインディング更新の更新など）、バインディング更新はプロキシバインディング更新後にLMA / HAの組み合わせに到達する可能性があります。 MAGによって送信され、MNがアクセスBに移動した後でも、パケットをアクセスAにリダイレクトします。
4. Threat of compromised MAG
4. MAGの侵害の脅威
* In the MIPv6 base specification [RFC6275], there is a strong binding between the HoA registered by the MN and the Security Association (SA) used to modify the corresponding BCE.
* MIPv6基本仕様[RFC6275]では、MNによって登録されたHoAと、対応するBCEを変更するために使用されるセキュリティアソシエーション（SA）の間に強いバインディングがあります。
* In the PMIPv6 specification [RFC5213], the MAG sends Proxy Binding Updates on behalf of a MN to update the BCE that corresponds to the MN's HoA. Since the MAG sends the Binding Updates, PMIPv6 requires SAs between each MAG and the LMA.
* PMIPv6仕様[RFC5213]では、MAGはMNの代わりにプロキシバインディング更新を送信して、MNのHoAに対応するBCEを更新します。 MAGはバインディングアップデートを送信するため、PMIPv6は各MAGとLMAの間にSAを必要とします。
* As described in [RFC4832], in PMIPv6, MAG compromise or impersonation is an issue. [RFC4832], Section 2.2, describes how a compromised MAG can harm the functionality of an LMA, e.g., manipulating the LMA's routing table (or binding cache).
* [RFC4832]で説明されているように、PMIPv6では、MAGの侵害または偽装が問題です。 [RFC4832]のセクション2.2は、侵害されたMAGがLMAの機能に害を及ぼす方法（LMAのルーティングテーブル（またはバインディングキャッシュ）の操作など）について説明しています。
* In this mixed scenario, both host-based and network-based SAs are used to update the same binding cache entry at the HA/LMA (but see the first bullet of this list, as the entry may not be the same). Based on this consideration, the threat described in [RFC4832] is worse as it also affects hosts that are using the LMA/HA as MIPv6 HA and not using PMIPv6.
* この混合シナリオでは、ホストベースのSAとネットワークベースのSAの両方を使用して、HA / LMAで同じバインディングキャッシュエントリを更新します（ただし、エントリが同じでない場合があるため、このリストの最初の箇条書きを参照してください）。この考慮事項に基づいて、[RFC4832]で説明されている脅威は、LMV / HAをMIPv6 HAとして使用しており、PMIPv6を使用していないホストにも影響を与えるため、より深刻です。
In this scenario, there are two types of nodes in the access network: some nodes support MIPv6 while some others do not. The rationale behind such a scenario is that the nodes implementing MIPv6 manage their own mobility to achieve better performance, e.g., for inter-technology handovers. Obviously, nodes that do not implement MIPv6 must rely on the network to manage their mobility; therefore, Proxy MIPv6 is used for those nodes.
このシナリオでは、アクセスネットワークには2種類のノードがあります。MIPv6をサポートするノードとサポートしないノードがあります。このようなシナリオの背後にある理論的根拠は、MIPv6を実装するノードが独自のモビリティを管理して、テクノロジー間ハンドオーバーなどのパフォーマンスを向上させることです。明らかに、MIPv6を実装しないノードは、モビリティを管理するためにネットワークに依存する必要があります。したがって、これらのノードにはプロキシMIPv6が使用されます。
Based on the current PMIPv6 solution described in [RFC5213], in any link of the PMIPv6 domain, the MAG emulates the MN's home link, advertising the home link prefix to the MN in a unicast Router Advertisement message. This ensures that the IP address of the MN is still considered valid by the MN itself. The home network prefix (and any other information needed to emulate the home link) is included in the MN's profile that is obtained by the MAG via context transfer or via a policy store.
[RFC5213]で説明されている現在のPMIPv6ソリューションに基づいて、MAGはPMIPv6ドメインの任意のリンクでMNのホームリンクをエミュレートし、ユニキャストルーターアドバタイズメッセージでMNにホームリンクプレフィックスをアドバタイズします。これにより、MNのIPアドレスがMN自体によって引き続き有効であると見なされます。ホームネットワークプレフィックス（およびホームリンクをエミュレートするために必要なその他の情報）は、コンテキスト転送またはポリシーストアを介してMAGによって取得されるMNのプロファイルに含まれています。
However, in case there are nodes that implement MIPv6 and want to use this protocol, the network must offer MIPv6 service to them. In such a case, the MAG should not emulate the home link. Instead of advertising the MN-HNP, the MAG should advertise the topologically correct local IP prefix, i.e., the prefix belonging to the MAG, so that the MN detects an IP movement, configures a new CoA, and sends a MIPv6 Binding Update based on [RFC6275].
ただし、MIPv6を実装し、このプロトコルを使用したいノードがある場合、ネットワークはそれらにMIPv6サービスを提供する必要があります。このような場合、MAGはホームリンクをエミュレートしないでください。 MN-HNPをアドバタイズする代わりに、MAGはトポロジ的に正しいローカルIPプレフィックス、つまりMAGに属するプレフィックスをアドバタイズする必要があります。これにより、MNはIPの移動を検出し、新しいCoAを構成し、以下に基づいてMIPv6バインディングアップデートを送信します。 [RFC6275]。
As mentioned in Section 3.1, there are no significant issues in this scenario.
セクション3.1で述べたように、このシナリオでは重大な問題はありません。
Figures 5 and 6 show a scenario where an MN is moving from one PMIPv6 domain to another, based on the scenario of Figure 1. In Figure 5, the MN moves from an old MAG to MAG2 in the same PMIPv6 domain: this movement triggers a PBU to LMA1 and the updating of the binding cache at the LMA1. There is no MIPv6 signaling as the CoA_1 registered at the HA is the HoA for the PMIPv6 session. In Figure 6, the MN moves from MAG2 in the LMA1 PMIPv6 domain to MAG3 in a different PMIPv6 domain: this triggers the PMIPv6 signaling and the creation of a binding at the LMA2. On the other hand, the local address of the mobile node is changed, as the LMA has changed; therefore, the MN sends a MIPv6 Binding Update to the HA with the new CoA_2.
図5および6は、図1のシナリオに基づいて、MNがあるPMIPv6ドメインから別のドメインに移動するシナリオを示しています。図5では、MNは同じPMIPv6ドメイン内の古いMAGからMAG2に移動します。この移動は、 LMA1へのPBUおよびLMA1でのバインディングキャッシュの更新。 HAに登録されているCoA_1はPMIPv6セッションのHoAであるため、MIPv6シグナリングはありません。図6では、MNはLMA1 PMIPv6ドメインのMAG2から別のPMIPv6ドメインのMAG3に移動します。これにより、PMIPv6シグナリングがトリガーされ、LMA2でバインディングが作成されます。一方、LMAが変更されると、モバイルノードのローカルアドレスが変更されます。したがって、MNは新しいCoA_2を使用してMIPv6バインディングアップデートをHAに送信します。
+----+ +------+ +------+ +----+
| MN | | MAG2 | | LMA1 | | HA |
+----+ +------+ +------+ +----+
| | | |
| | | +-----------------+
| | | | HoA -> CoA_1 |
| | | | binding present |
| | | +-----------------+
| | | |
| CoA conf/confirm | PBU(CoA_1,MAG_2) | |
| <--------------->| ----------------->| |
| | +-----------------+|
| | | CoA_1 -> MAG_2 ||
| | | binding updated ||
| | +-----------------+|
| | PBA | |
| | <----------------| |
| | | |
Figure 5: Local Mobility Message Flow
図5：ローカルモビリティメッセージフロー
+----+ +------+ +------+ +----+
| MN | | MAG3 | | LMA2 | | HA |
+----+ +------+ +------+ +----+
| CoA config | PBU(CoA_2,MAG_3) | |
|<---------------->|------------------->| |
| | +-----------------+ |
| | | CoA_2 -> MAG_3 | |
| | | binding created | |
| | +-----------------+ |
| | PBA | |
| |<-------------------| |
| | | |
| | BU (HoA, CoA_2) | |
|---------------------------------------------------->|
| | | |
| | | +-----------------+
| | | | HoA -> CoA_2 |
| | | | binding updated |
| | | +-----------------+
| | BA | |
|<----------------------------------------------------|
Figure 6: Global Mobility Message Flow
図6：グローバルモビリティメッセージフロー
As described in Section 3.2, in this scenario, the MN relies on PMIPv6 as long as it is in the PMIPv6 domain. The MN then uses MIPv6 whenever it moves out of the PMIPv6 domain, which basically implies that the MIPv6 home link is a PMIPv6 domain.
セクション3.2で説明したように、このシナリオでは、MNはPMIPv6ドメイン内にある限り、PMIPv6に依存します。次に、MNは、PMIPv6ドメインの外に移動するたびにMIPv6を使用します。これは、基本的に、MIPv6ホームリンクがPMIPv6ドメインであることを意味します。
Analyzing the issues described in Section 3.2, it is clear that most of them are applicable only to the case where there is a common BCE for the PMIPv6 registration and the MIPv6 registration. Issue 1, on how the two protocols identify the BCE, is valid only in the case in which we assume that a PMIPv6 message has any value for a MIPv6 BCE. Also, Issues 2 and 3 are not applicable in the case in which different logical BCEs are used by the LMA and the HA. For this reason, it is recommended that when the MIPv6 home link is implemented as a PMIPv6 domain, the HA/LMA implementation treat the two protocols as independent.
セクション3.2で説明した問題を分析すると、それらのほとんどは、PMIPv6登録とMIPv6登録に共通のBCEがある場合にのみ適用できることが明らかです。 2つのプロトコルがBCEを識別する方法に関する問題1は、PMIPv6メッセージにMIPv6 BCEの値があると想定する場合にのみ有効です。また、問題2と3は、LMAとHAが異なる論理BCEを使用する場合には適用されません。このため、MIPv6ホームリンクがPMIPv6ドメインとして実装されている場合、HA / LMA実装は2つのプロトコルを独立したものとして扱うことをお勧めします。
In more detail, the following principles should be followed by the HA/LMA implementation:
より詳細には、次の原則に従ってHA / LMAを実装する必要があります。
o PMIPv6 signaling does not overwrite any MIPv6 BCE. In particular, when a PMIPv6 BCE is created for an MN that has previously created a MIPv6 BCE, the MIPv6 BCE of the MN is not overwritten, and a new PMIPv6 BCE is created.
o PMIPv6シグナリングは、MIPv6 BCEを上書きしません。特に、以前にMIPv6 BCEを作成したMNに対してPMIPv6 BCEが作成される場合、MNのMIPv6 BCEは上書きされず、新しいPMIPv6 BCEが作成されます。
o The downlink packets in the case where both the MIPv6 BCE and PMIPv6 BCE exist are processed as follows:
o MIPv6 BCEとPMIPv6 BCEの両方が存在する場合のダウンリンクパケットは、次のように処理されます。
1. The MIPv6 BCE is processed first. If the destination address of the received downlink packet matches the BCE of the HA, the packet is forwarded by encapsulating it with the CoA contained in the BCE.
1. MIPv6 BCEが最初に処理されます。受信したダウンリンクパケットの宛先アドレスがHAのBCEと一致する場合、パケットはBCEに含まれるCoAでカプセル化することによって転送されます。
2. If the destination address does not match the MIPv6 BCE, the BCE created by PMIPv6 is applied, and the packets are encapsulated to the registered MAG.
2. 宛先アドレスがMIPv6 BCEと一致しない場合、PMIPv6によって作成されたBCEが適用され、パケットは登録されたMAGにカプセル化されます。
The following subsections provide a description of the procedures that will be followed by the MN and HA/LMA based on the above principles. The analysis is performed in two different subsections, depending on whether the MN moves from a PMIPv6 domain to a non-PMIPv6 domain or vice versa.
以下のサブセクションでは、上記の原則に基づいてMNおよびHA / LMAが実行する手順について説明します。分析は、MNがPMIPv6ドメインから非PMIPv6ドメインに移動するか、その逆かによって、2つの異なるサブセクションで実行されます。
Let's assume the MN is attached to a PMIPv6 domain and there is a valid Proxy BCE at the LMA. Then, the MN moves to a different access network and starts using MIPv6 (e.g., because PMIPv6 is not supported). The MN needs to bootstrap MIPv6 parameters and send a MIPv6 Binding Update in order to have service continuity. Therefore, the following steps must be performed by the User Equipment (UE):
MNがPMIPv6ドメインに接続されていて、LMAに有効なプロキシBCEがあると仮定します。次に、MNは別のアクセスネットワークに移動し、MIPv6の使用を開始します（たとえば、PMIPv6がサポートされていないため）。 MNは、サービスを継続させるために、MIPv6パラメータをブートストラップし、MIPv6バインディングアップデートを送信する必要があります。したがって、次の手順はユーザー機器（UE）で実行する必要があります。
o HA/LMA address discovery: the MN needs to discover the IP address of the LMA that has a valid BCE for its home network prefix. This is described in Section 3.2 as Issue 4.
o HA / LMAアドレス検出：MNは、ホームネットワークプレフィックスに有効なBCEを持つLMAのIPアドレスを検出する必要があります。これについては、セクション3.2で第4号として説明されています。
o SA establishment: the MN needs to establish an IPsec Security Association with the HA/LMA as described in [RFC4877].
o SAの確立：MNは、[RFC4877]で説明されているように、HA / LMAとのIPsecセキュリティアソシエーションを確立する必要があります。
o HoA or home network prefix assignment: as part of the MIPv6 bootstrapping procedure, the HA assigns a MIPv6 HoA to the MN. This address must be the same the MN was using in the PMIPv6 domain.
o HoAまたはホームネットワークプレフィックスの割り当て：MIPv6ブートストラップ手順の一部として、HAはMIPv6 HoAをMNに割り当てます。このアドレスは、MNがPMIPv6ドメインで使用していたものと同じである必要があります。
Since all these steps must be performed by the MN before sending the Binding Update, they have an impact on the handover latency experienced by the MN. For this reason, it is recommended that the MN establish the IPsec SA (and, consequently, be provided by the HA/ LMA with a MIPv6-HoA) when it is initialized. This implies that the MN has MIPv6 stack active while in the PMIPv6 domain, but as long as it is attached to the same PMIPv6 domain, it will appear to the MN as if it is attached to the home link.
これらのステップはすべて、Binding Updateを送信する前にMNが実行する必要があるため、MNが経験するハンドオーバーのレイテンシに影響を与えます。このため、MNは初期化時にIPsec SAを確立することをお勧めします（その結果、HA / LMAからMIPv6-HoAが提供されます）。これは、MNがPMIPv6ドメイン内にある間にMIPv6スタックがアクティブであることを意味しますが、同じPMIPv6ドメインに接続されている限り、MNにはホームリンクに接続されているかのように見えます。
In order to establish the SA with the HA/LMA, the MN needs to discover the IP address of the LMA/HA while in the PMIPv6 domain. This can be done either based on DNS or based on DHCPv6, as described in [RFC5026] and [RFC6611]. The network should be configured so that the MN discovers or gets assigned the same HA/LMA that was serving as the LMA in the PMIPv6 domain. Details of the exact procedure are out of scope of this document.
HA / LMAを使用してSAを確立するために、MNはPMIPv6ドメイン内でLMA / HAのIPアドレスを検出する必要があります。これは、[RFC5026]および[RFC6611]で説明されているように、DNSまたはDHCPv6に基づいて実行できます。ネットワークは、MNがPMIPv6ドメインでLMAとして機能していたのと同じHA / LMAを検出または割り当てるように構成する必要があります。正確な手順の詳細は、このドキュメントの範囲外です。
When the MN establishes the SA, it acquires an HoA based on [RFC5026]. However, based on PMIPv6 operations, the LMA knows only the home network prefix used by the MN and does not know the MN-HoA. For this reason, the MN must be configured to propose the MN-HoA as the HoA in the IKEv2 INTERNAL_IP6_ADDRESS attribute during the IKEv2 exchange with the HA/LMA. Alternatively, the HA/LMA can be configured to provide the entire home network prefix via the MIP6_HOME_LINK attribute to the MN as specified in [RFC5026]; based on this home network prefix, the MN can configure an HoA. Note that the SA must be bound to the MN-HoA used in the PMIPv6 domain as per
MNはSAを確立すると、[RFC5026]に基づいてHoAを取得します。ただし、PMIPv6動作に基づいて、LMAはMNによって使用されるホームネットワークプレフィックスのみを認識し、MN-HoAを認識しません。このため、MNは、HA / LMAとのIKEv2交換中に、IKEv2 INTERNAL_IP6_ADDRESS属性でMN-HoAをHoAとして提案するように構成する必要があります。あるいは、HA / LMAは、[RFC5026]で指定されているように、MIP6_HOME_LINK属性を介してホームネットワーク全体のプレフィックスをMNに提供するように構成できます。このホームネットワークプレフィックスに基づいて、MNはHoAを構成できます。 SAは、PMIPv6ドメインで使用されるMN-HoAにバインドする必要があることに注意してください。
[RFC4877]. Note that the home network prefix is shared between the LMA and HA, and this implies that there is an interaction between the LMA and the HA in order to assign a common home network prefix when triggered by PMIPv6 and MIPv6 signaling.
[RFC4877]。ホームネットワークプレフィックスはLMAとHAの間で共有されることに注意してください。これは、PMIPv6およびMIPv6シグナリングによってトリガーされたときに共通のホームネットワークプレフィックスを割り当てるために、LMAとHAの間に相互作用があることを意味します。
When the MN hands over to an access network that does not support Proxy Mobile IPv6, it sends a Binding Update to the HA. The MN may set the R bit defined in the Network Mobility (NEMO) specification (implicit mode) [RFC3963] in order to indicate that the entire HNP is moved to the new CoA. A MIPv6 BCE is created irrespective of the existing PMIPv6 BCE. Packets matching the MIPv6 BCE are sent to the CoA present in the MIPv6 BCE. The PMIPv6 BCE will expire in the case in which the MAG does not send a refresh PBU.
MNがプロキシモバイルIPv6をサポートしないアクセスネットワークにハンドオーバーすると、MNはバインディングアップデートをHAに送信します。 MNは、HNP全体が新しいCoAに移動されたことを示すために、ネットワークモビリティ（NEMO）仕様（暗黙モード）[RFC3963]で定義されたRビットを設定できます。 MIPv6 BCEは、既存のPMIPv6 BCEに関係なく作成されます。 MIPv6 BCEに一致するパケットは、MIPv6 BCEに存在するCoAに送信されます。 MAGがリフレッシュPBUを送信しない場合、PMIPv6 BCEは期限切れになります。
In this section, it is assumed that the MN is in a non-PMIPv6 access network, and it has bootstrapped MIPv6 operations based on [RFC5026]; therefore, there is valid binding cache for its MIPv6-HoA (or HNP in case of NEMO) at the HA. Then, the MN moves to a PMIPv6 domain that is configured to be the home link for the MIPv6-HoA the MN has been assigned.
このセクションでは、MNが非PMIPv6アクセスネットワーク内にあり、[RFC5026]に基づいてMIPv6操作がブートストラップされていると想定しています。したがって、HAにはMIPv6-HoA（NEMOの場合はHNP）の有効なバインディングキャッシュがあります。次に、MNは、MNが割り当てられているMIPv6-HoAのホームリンクになるように構成されたPMIPv6ドメインに移動します。
In order to provide session continuity, the MAG needs to send a PBU to the HA/LMA that was serving the MN. The MAG needs to discover the HA/LMA; however, [RFC5213] assumes that the LMA is assigned to the MAG or discovered by the MAG when the MN attaches to the MAG. The exact mechanism is not specified in [RFC5213]. A detailed description of the necessary procedure is out of the scope of this document. Note that the MAG may also rely on static configuration or lower-layer information provided by the MN in order to select the correct HA/LMA.
セッションの継続性を提供するために、MAGは、MNにサービスを提供していたHA / LMAにPBUを送信する必要があります。 MAGはHA / LMAを検出する必要があります。ただし、[RFC5213]は、MNがMAGに接続するときに、LMAがMAGに割り当てられているか、MAGによって発見されていると想定しています。正確なメカニズムは[RFC5213]で指定されていません。必要な手順の詳細な説明は、このドキュメントの範囲外です。 MAGは、正しいHA / LMAを選択するために、MNによって提供される静的構成または下位層情報にも依存する場合があることに注意してください。
The PBU sent by the MAG creates a PMIPv6 BCE for the MN that is independent of the MIPv6 BCE. Traffic destined to the MIPv6-HoA (or to the HNP in case the MN had set the flag R in the last BU) is still forwarded to the CoA present in the MIPv6 BCE. When the MN wants to use the HoA directly from the home link, it sends a de-registration message and, at that point only, the PMIPv6 BCE is present.
MAGから送信されたPBUは、MIPv6 BCEから独立したMNのPMIPv6 BCEを作成します。 MIPv6-HoA（または、MNが最後のBUでフラグRを設定した場合はHNP）宛てのトラフィックは、MIPv6 BCEに存在するCoAに転送されます。 MNがホームリンクから直接HoAを使用したい場合、MNは登録解除メッセージを送信し、その時点でのみ、PMIPv6 BCEが存在します。
The solution for this scenario depends on the access network being able to determine that a particular MN wants to use Mobile IPv6. This requires a solution at the system level for the access network and may require knowledge of the detailed configuration and software capabilities of every MN in the system. These issues are out of the scope of this document.
このシナリオの解決策は、特定のMNがモバイルIPv6の使用を希望していると判断できるアクセスネットワークに依存しています。これには、アクセスネットワークのシステムレベルでのソリューションが必要であり、システム内のすべてのMNの詳細な設定とソフトウェア機能の知識が必要になる場合があります。これらの問題は、このドキュメントの範囲外です。
Scenario A.1 does not introduce any new security issues in addition to those described in [RFC5213] or [RFC6275].
シナリオA.1では、[RFC5213]または[RFC6275]で説明されている問題に加えて、新しいセキュリティ問題は導入されていません。
For Scenario A.2, this document requires that the a home agent that also implements the PMIPv6 LMA functionality should allow both the MN and the authorized MAGs to modify the BCEs for the MN. Note that the compromised MAG threat described in [RFC4832] also applies here in a more severe form as explained in Section 3.2. Scenario B relies on the secure identification of MNs and their capabilities so that the right service can be provided for the right MNs. For instance, a malicious MN should not get the HoA of some other node assigned to it, and a MN that desires to employ its own mobility management should be able to do so. The ability to identify nodes is already a requirement in [RFC5213], but Scenario B adds a requirement on identification of node capabilities.
シナリオA.2の場合、このドキュメントでは、PMIPv6 LMA機能も実装するホームエージェントが、MNと許可されたMAGの両方がMNのBCEを変更できるようにする必要があります。 [RFC4832]で説明されている侵害されたMAG脅威は、セクション3.2で説明されているように、より深刻な形でここにも適用されます。シナリオBは、MNとその機能の安全な識別に依存しているため、適切なサービスを適切なMNに提供できます。たとえば、悪意のあるMNには他のノードのHoAが割り当てられてはならず、独自のモビリティ管理を採用したいMNはそれを行うことができるはずです。ノードを識別する機能は[RFC5213]ですでに要件ですが、シナリオBはノード機能の識別に関する要件を追加します。
Kuntal Chowdhury - kuntal@hotmail.com
Kuntal Chowdhury-kuntal@hotmail.com
Vijay Devarapalli - vijay.devarapalli@azairenet.com
Vijay Devarapally-Vijay.Devarapally@Agerent.com
Sri Gundavelli - sgundave@cisco.com
スリガンダベリ-sgundave@cisco.com
Suresh Krishnan - suresh.krishnan@ericsson.com
Suresh Krishnan-suresh.krishnan@ericsson.com
Ahmad Muhanna - amuhanna@nortel.com
アフマドムハンナ-amuhanna@nortel.com
Hesham Soliman - Hesham@elevatemobile.com
Hisham Suleiman-Hisham@alfatmpel.com
George Tsirtsis - tsirtsis@googlemail.com
George Tsirtsis-tsirtsis@googlemail.com
Genadi Velev - Genadi.Velev@eu.panasonic.com
Gennady Zhelev-Gennady.Velev@eu.panasonits.tsum
Kilian Weniger - Kilian.Weniger@googlemail.com
Kilian Less-Kilian.Weniger@googlemail.com
This document is a merge of four different documents: "Proxy Mobile IPv6 and Mobile IPv6 interworking issues" (April 2007), "Proxy Mobile IPv6 and Mobile IPv6 interworking" (April 2007), "Behavior of Collocated HA/LMA" (October 2008), and "Interactions between PMIPv6 and MIPv6: scenarios and related issues" (November 2007). Thanks to the authors and editors of those documents.
このドキュメントは、「プロキシモバイルIPv6とモバイルIPv6のインターワーキングの問題」（2007年4月）、「プロキシモバイルIPv6とモバイルIPv6のインターワーキング」（2007年4月）、「配置されたHA / LMAの動作」（2008年10月）の4つの異なるドキュメントをまとめたものです。 ）、および「PMIPv6とMIPv6間の相互作用：シナリオと関連する問題」（2007年11月）。これらのドキュメントの作成者と編集者に感謝します。
The authors would also like to thank Jonne Soininen and Vidya Narayanan, NETLMM WG chairs, for their support.
著者はまた、NETLMM WGの議長であるJonne SoininenとVidya Narayananの支援に感謝します。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[Raffsey] Devarapalli、W。、脇川、R.、Petresque、A。、およびp。 Tubert、「Network Mobility（Nemo）Basic Support Protocol」、RFAC1、2009年1月。
[RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based Localized Mobility Management (NETLMM)", RFC 4832, April 2007.
[RFC4832] Vogt、C。およびJ. Kempf、「ネットワークベースのローカライズされたモビリティ管理（NETLMM）に対するセキュリティの脅威」、RFC 4832、2007年4月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877] Devarapalli、V。およびF. Dupont、「Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture」、RFC 4877、2007年4月。
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026]ジャレッタ、G。、ケンプ、J。、およびV.デバラパリ、「スプリットシナリオでのモバイルIPv6ブートストラップ」、RFC 5026、2007年10月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Rufsey1] Gundavelli、S.、Leunji、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile Ipp 1」、Rfak 2、2009年8月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380] Soliman、H.、Castelluccia、C.、ElMalki、K.、およびL. Bellier、「Hierarchical Mobile IPv6（HMIPv6）Mobility Management」、RFC 5380、2008年10月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。
[RFC6611] Chowdhury, K., Ed. and A. Yegin, "Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario", RFC 6611, May 2012.
[RFC6611]チョードリー、K。、エド。およびA. Yegin、「統合シナリオのモバイルIPv6（MIPv6）ブートストラップ」、RFC 6611、2012年5月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753] Manner、J。およびM. Kojo、「Mobility Related Terminology」、RFC 3753、2004年6月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6のモバイルノード識別子オプション（MIPv6）」、RFC 4283、2005年11月。
Author's Address
著者のアドレス
Gerardo Giaretta (editor) Qualcomm
ジェラルド・ジャレッタ（編集者）クアルコム
EMail: gerardog@qualcomm.com