[要約] RFC 6705は、Proxy Mobile IPv6におけるローカライズドルーティングに関する仕様です。その目的は、モバイルノードの通信を最適化し、ネットワークの負荷を軽減することです。
Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6705 Ericsson
Category: Standards Track R. Koodli
ISSN: 2070-1721 Cisco Systems
P. Loureiro
NEC
Q. Wu
Huawei
A. Dutta
NIKSUN
September 2012
Localized Routing for Proxy Mobile IPv6
プロキシモバイルIPv6のローカライズされたルーティング
Abstract
概要
Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) attached to the same or different Mobile Access Gateways (MAGs) to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization, and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism.
プロキシモバイルIPv6（PMIPv6）は、モビリティ関連のシグナリングに参加することなく、ホストのIPモビリティを可能にするネットワークベースのモビリティ管理プロトコルです。 PMIPv6では、すべての通信がローカルモビリティアンカーを経由する必要があります。これは最適ではない可能性があるため、ローカライズドルーティング（LR）では、同じまたは異なるモバイルアクセスゲートウェイ（MAG）に接続されたモバイルノード（MN）が、ローカライズされた転送またはゲートウェイ間の直接トンネルを使用してトラフィックをルーティングできます。このドキュメントは、プロキシモバイルIPv6ドメイン内のモバイルアクセスゲートウェイ間のローカライズされたルーティングの開始、利用、および終了メカニズムを提案します。このメカニズムを実現するために使用される、ローカライズされたルーティング開始（LRI）とローカルルーティング確認（LRA）という2つの新しいシグナリングメッセージが定義されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6705.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6705で入手できます。
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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Initiation of Localized Routing .................................3
3.1. MAG Behavior ...............................................4
3.2. LMA Behavior ...............................................4
4. Teardown of Localized Routing ...................................4
5. Scenario A11: Two MNs Attached to the Same MAG and LMA ..........4
5.1. Handover Considerations ....................................6
6. Scenario A21: Two MNs Attached to Different MAGs but the
Same LMA ........................................................7
6.1. Handover Considerations ....................................9
6.2. Tunneling between the MAGs .................................9
7. Scenario A12: Two MNs Attached to the Same MAG with
Different LMAs .................................................10
7.1. Handover Considerations ...................................12
8. Scenario A22: Two MNs Attached to Different MAGs with
Different LMAs .................................................13
9. IPv4 Support in Localized Routing ..............................13
10. Message Formats ...............................................13
10.1. Localized Routing Initiation (LRI) .......................14
10.2. Localized Routing Acknowledgment (LRA) ...................15
11. New Mobility Option ...........................................16
11.1. MAG IPv6 Address .........................................16
12. Configuration Variables .......................................17
13. Security Considerations .......................................17
14. IANA Considerations ...........................................17
15. Contributors ..................................................18
16. Acknowledgments ...............................................18
17. References ....................................................19
17.1. Normative References .....................................19
17.2. Informative References ...................................19
Proxy Mobile IPv6 [RFC5213] describes the protocol operations to maintain reachability and session persistence for a Mobile Node (MN) without the explicit participation from the MN in signaling operations at the Internet Protocol (IP) layer. In order to facilitate such network-based mobility, the PMIPv6 protocol defines a Mobile Access Gateway (MAG), which acts as a proxy for the Mobile IPv6 [RFC6275] signaling, and the Local Mobility Anchor (LMA), which acts similar to a Home Agent. The LMA and the MAG establish a bidirectional tunnel for forwarding all data traffic belonging to the Mobile Nodes. In the case where both endpoints are located in the same PMIPv6 domain, this can be suboptimal and result in increased delay and congestion in the network. Moreover, it increases transport costs and traffic load at the LMA.
プロキシモバイルIPv6 [RFC5213]は、インターネットプロトコル（IP）層でのシグナリング操作にMNが明示的に参加することなく、モバイルノード（MN）の到達可能性とセッションの永続性を維持するプロトコル操作について説明しています。そのようなネットワークベースのモビリティを促進するために、PMIPv6プロトコルは、モバイルIPv6 [RFC6275]シグナリングのプロキシとして機能するモバイルアクセスゲートウェイ（MAG）と、同様に機能するローカルモビリティアンカー（LMA）を定義します。ホームエージェント。 LMAとMAGは、モバイルノードに属するすべてのデータトラフィックを転送するための双方向トンネルを確立します。両方のエンドポイントが同じPMIPv6ドメインにある場合、これは最適とは言えず、ネットワークの遅延と輻輳が増加する可能性があります。さらに、LMAでの輸送コストと交通負荷が増加します。
To overcome these issues, localized routing can be used to allow nodes attached to the same or different MAGs to directly exchange traffic by using localized forwarding or a direct tunnel between the gateways. [RFC6279] defines the problem statement for PMIPv6 localized routing. This document describes a solution for PMIPv6 localized routing between two MNs in the same PMIPv6 domain. The protocol specified here assumes that each MN is attached to a MAG and that each MN's MAG has established a binding for the attached MN at its selected LMA according to [RFC5213]. The protocol builds on the scenarios defined in [RFC6279].
これらの問題を克服するために、ローカライズされたルーティングを使用して、同じまたは異なるMAGに接続されたノードが、ゲートウェイ間のローカライズされた転送または直接トンネルを使用してトラフィックを直接交換できるようにすることができます。 [RFC6279]は、PMIPv6ローカライズドルーティングの問題ステートメントを定義しています。このドキュメントでは、同じPMIPv6ドメイン内の2つのMN間のPMIPv6ローカライズルーティングのソリューションについて説明します。ここで指定されるプロトコルは、各MNがMAGに接続され、各MNのMAGが[RFC5213]に従って選択されたLMAで接続されたMNのバインディングを確立していることを前提としています。プロトコルは、[RFC6279]で定義されたシナリオに基づいて構築されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document also uses the terminology defined in Section 2 of [RFC6279].
このドキュメントでは、[RFC6279]のセクション2で定義された用語も使用しています。
Since the traffic to be localized passes through both the LMA and the MAGs, it is possible, at least in some scenarios, for either of them to initiate Localized Routing (LR). In order to eliminate ambiguity, the protocol described in this document selects the initiator of LR based on the rules below.
ローカライズされるトラフィックはLMAとMAGの両方を通過するため、少なくとも一部のシナリオでは、どちらかがローカライズドルーティング（LR）を開始することが可能です。あいまいさを排除するために、このドキュメントで説明されているプロトコルは、以下のルールに基づいてLRのイニシエーターを選択します。
The MAG MUST initiate LR if both of the communicating MNs are attached to it and the MNs are anchored at different LMAs. The MAG MUST NOT initiate LR in any other case.
通信しているMNの両方が接続されていて、MNが異なるLMAにアンカーされている場合、MAGはLRを開始する必要があります。その他の場合、MAGはLRを開始してはなりません。
The LMA MUST initiate LR if both of the communicating MNs are anchored to it. The LMA MUST NOT initiate LR in any other case.
通信しているMNの両方がアンカーされている場合、LMAはLRを開始する必要があります。 LMAは、他のいかなる場合でもLRを開始してはなりません。
The use of localized routing is not persistent. Localized routing has a defined lifetime as specified by the initiator; upon expiry, the forwarding MUST revert to using bidirectional tunneling. When localized routing ceases, the corresponding Localized Routing Entries (LREs) MUST be removed.
ローカライズされたルーティングの使用は永続的ではありません。ローカライズされたルーティングには、イニシエーターによって指定されたライフタイムが定義されています。有効期限が切れると、転送は双方向トンネリングの使用に戻らなければなりません（MUST）。ローカライズされたルーティングが停止したら、対応するローカライズされたルーティングエントリ（LRE）を削除する必要があります。
If the initiator of LR wishes to terminate localized routing before the expiry of the lifetime specified in the LRI message, it MUST do so by sending a new LRI message with the lifetime set to zero.
LRのイニシエーターが、LRIメッセージで指定された存続期間の満了前にローカライズされたルーティングを終了したい場合は、存続期間がゼロに設定された新しいLRIメッセージを送信することによって終了する必要があります。
In this scenario, the two Mobile Nodes involved in communication are attached to a single MAG and both are anchored at the same LMA as shown in Figure 1.
このシナリオでは、図1に示すように、通信に関与する2つのモバイルノードが1つのMAGに接続され、両方が同じLMAにアンカーされます。
Internet
:
|
|
+-----+
| LMA |
+-----+
|
|
|
+-----+
| MAG |
+-----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 1
図1
The LMA initiates a localized routing session by detecting traffic between two MNs attached to the same MAG. The exact traffic identification mechanism is not specified in this document and is left open for implementations and specific deployments. An example trigger could be that an application-layer signaling entity detects the possibility of localized routing and notifies the LMA about the two endpoints, and the LMA determines that the two endpoints are attached to the same MAG. Such a trigger mechanism offers localized routing at the granularity of an individual application session, providing flexibility in usage. It is also possible that one of the mobility entities (LMA or MAG) could decide to initiate localized routing based on configured policy. Please note that a MAG implementing the protocol specified in this document will not dynamically initiate LR in the same LMA case (i.e., by sending an LRI), but can statically initiate LR based on the EnableMAGLocalRouting configuration variable specified in [RFC5213].
LMAは、同じMAGに接続された2つのMN間のトラフィックを検出することにより、ローカライズされたルーティングセッションを開始します。正確なトラフィック識別メカニズムはこのドキュメントでは指定されておらず、実装および特定の展開のために開いたままになっています。トリガーの例としては、アプリケーション層のシグナリングエンティティがローカライズされたルーティングの可能性を検出し、LMAに2つのエンドポイントについて通知し、LMAが2つのエンドポイントが同じMAGに接続されていると判断することがあります。このようなトリガーメカニズムは、個々のアプリケーションセッションの粒度でローカライズされたルーティングを提供し、使用の柔軟性を提供します。モビリティエンティティの1つ（LMAまたはMAG）が、構成されたポリシーに基づいてローカライズされたルーティングを開始することを決定する可能性もあります。このドキュメントで指定されているプロトコルを実装するMAGは、同じLMAケースで（つまり、LRIを送信することで）LRを動的に開始しませんが、[RFC5213]で指定されているEnableMAGLocalRouting構成変数に基づいて静的にLRを開始できます。
+----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |LMA |
+----+ +----+ +----+ +----+
| | | |
| data | data |
|<--------------------->|<------------->|
| | | |
| | data | data |
| |<--------->|<------------->|
| | | LR decision
| | | LRI(Opt1) |
| | |<--------------|
| | | |
| | | LRA(Opt2) |
| | |-------------->|
| | | |
| data | |
|<--------------------->| |
| | | |
| | data | |
| |<--------->| |
| | | |
| | | |
Opt1: MN1-ID,MN1-HNP,MN2-ID,MN2-HNP Opt2: U=0,MN1-ID,MN1-HNP,MN2-ID,MN2-HNP
Opt1：MN1-ID、MN1-HNP、MN2-ID、MN2-HNP Opt2：U = 0、MN1-ID、MN1-HNP、MN2-ID、MN2-HNP
where U is the flag defined in Section 10.2.
ここで、Uはセクション10.2で定義されたフラグです。
Figure 2
図2
After detecting a possibility for localized routing, the LMA SHOULD construct an LRI message that is used to signal the intent to initiate localized routing and to convey parameters for the same. This is a Mobility Header message and it MUST contain the MN-Identifier (MN-ID) and the Home Network Prefix (HNP) (as Mobility Header options) for each of the MNs involved. The LMA MUST then send the LRI message to the MAG (MAG1) where the two MNs are attached. The initiation of the LR procedure is shown in Figure 2.
ローカライズされたルーティングの可能性を検出した後、LMAは、ローカライズされたルーティングを開始し、そのためのパラメーターを伝達する意図を伝えるために使用されるLRIメッセージを構築する必要があります（SHOULD）。これはモビリティヘッダーメッセージであり、関与する各MNのMN識別子（MN-ID）およびホームネットワークプレフィックス（HNP）（モビリティヘッダーオプションとして）を含んでいる必要があります。次に、LMAは2つのMNが接続されているMAG（MAG1）にLRIメッセージを送信する必要があります。 LRプロシージャの開始を図2に示します。
The MAG (MAG1) MUST verify the attachment status of the two MNs locally by checking the binding cache. The MAG MUST then verify if the EnableMAGLocalRouting flag is set to 1. If it is not, the MAG has not been configured to allow localized routing, and it MUST reject the LRI and MUST send an LRA with Status code "Localized Routing Not Allowed". Please note that this does not update behavior specified in [RFC5213] but merely implements the LMA enforcement specified in Section 6.10.3 of [RFC5213]. If the MAG is configured to allow localized routing, it MUST then create LREs for each direction of the communication between the two MNs. The exact form of the forwarding entries is left for the implementations to decide; however, they SHOULD contain the HNP corresponding to the destination IP address and a next-hop identifier (e.g., the layer-2 address of the next hop). These LREs MUST override the Binding Update List (BUL) entries for the specific HNPs identified in the LRI message. Hence, all traffic matching the HNPs is forwarded locally.
MAG（MAG1）は、バインディングキャッシュをチェックして、2つのMNの接続ステータスをローカルで確認する必要があります。次に、MAGはEnableMAGLocalRoutingフラグが1に設定されているかどうかを検証する必要があります。設定されていない場合、MAGはローカライズされたルーティングを許可するように構成されておらず、LRIを拒否する必要があり、ステータスコード "Localized Routing Not Allowed"でLRAを送信する必要があります。これは[RFC5213]で指定された動作を更新するのではなく、[RFC5213]のセクション6.10.3で指定されたLMA強制を実装するだけであることに注意してください。 MAGがローカライズされたルーティングを許可するように構成されている場合、2つのMN間の通信の各方向に対してLREを作成する必要があります。転送エントリの正確な形式は、実装によって決定されます。ただし、それらは、宛先IPアドレスに対応するHNPとネクストホップ識別子（たとえば、ネクストホップのレイヤー2アドレス）を含む必要があります（SHOULD）。これらのLREは、LRIメッセージで識別された特定のHNPのバインディングアップデートリスト（BUL）エントリをオーバーライドする必要があります。したがって、HNPに一致するすべてのトラフィックはローカルに転送されます。
If the MAG is unable to deliver packets using the LREs, it is possible that one of the MNs is no longer attached to the MAG. Hence, the MAG MUST fall back to using the BUL entry, and the LMA MUST forward the received packets using its Binding Cache Entry (BCE).
MAGがLREを使用してパケットを配信できない場合、MNの1つがMAGに接続されていない可能性があります。したがって、MAGはBULエントリの使用にフォールバックする必要があり、LMAはバインディングキャッシュエントリ（BCE）を使用して受信したパケットを転送する必要があります。
After processing the LRI message, the MAG MUST respond with a Local Routing Acknowledgment (LRA) message. This Mobility Header message MUST also include the MN-ID and the HNP for each of the communicating MNs, as well as an appropriate Status code indicating the outcome of LRI processing. Status code 0 indicates localized routing was successfully offered by the MAG. Any other value for Status code indicates the reason for the failure to offer localized routing service. When Status code is 0, the LMA sets a flag in the BCE corresponding to the HNPs to record that localized routing is in progress for that HNP.
LRIメッセージを処理した後、MAGはローカルルーティング確認（LRA）メッセージで応答する必要があります。このモビリティヘッダーメッセージには、通信している各MNのMN-IDとHNP、およびLRI処理の結果を示す適切なステータスコードも含める必要があります。ステータスコード0は、MAGによってローカライズされたルーティングが正常に提供されたことを示します。ステータスコードの他の値は、ローカライズされたルーティングサービスを提供できない理由を示します。ステータスコードが0の場合、LMAはHNPに対応するBCEにフラグを設定し、そのHNPのローカライズされたルーティングが進行中であることを記録します。
If one of the MNs, say MN1, detaches from the MAG and attaches to another MAG (say nMAG), the localized routing state needs to be re-established. When the LMA receives the PBU from nMAG for MN1, it will see that localized routing is active for MN1. The LMA MUST hence initiate LR at nMAG and update the LR state of pMAG. After the handover completes, LR will resemble Scenario A21. The pMAG MUST follow the forwarding rules described in Section 6.10.5 of [RFC5213] and decide that it will no longer perform LR for MN1.
MNの1つ、たとえばMN1がMAGから切り離され、別のMAG（たとえばnMAG）に接続する場合、ローカライズされたルーティング状態を再確立する必要があります。 LMAがMN1のnMAGからPBUを受信すると、MN1のローカライズされたルーティングがアクティブであることがわかります。したがって、LMAはnMAGでLRを開始し、pMAGのLR状態を更新する必要があります。ハンドオーバーが完了すると、LRはシナリオA21のようになります。 pMAGは[RFC5213]のセクション6.10.5で説明されている転送ルールに従い、MN1に対してLRを実行しないことを決定する必要があります。
The LMA may choose to support local forwarding to Mobile Nodes attached to two different MAGs within a single PMIPv6 domain.
LMAは、単一のPMIPv6ドメイン内の2つの異なるMAGに接続されたモバイルノードへのローカル転送をサポートすることを選択できます。
Internet
:
|
|
+-----+
| LMA |
+-----+
|
|
+----+-----+
| |
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 3
図3
As earlier, the LMA initiates LR as a response to some trigger mechanism. In this case, however, it MUST send two separate LRI messages to the two MAGs. In addition to the MN-ID and the HNP options, each LRI message MUST contain the IP address of the counterpart MAG. When the MAG IP address option is present, each MAG MUST create a local forwarding entry such that the packets for the MN attached to the remote MAG are sent over a tunnel associated with that remote MAG. The tunnel between the MAGs is assumed to be established following the considerations mentioned in Section 6.2.
以前と同様に、LMAは何らかのトリガーメカニズムへの応答としてLRを開始します。ただし、この場合は、2つの別々のLRIメッセージを2つのMAGに送信する必要があります。 MN-IDおよびHNPオプションに加えて、各LRIメッセージには、対応するMAGのIPアドレスを含める必要があります。 MAG IPアドレスオプションが存在する場合、各MAGは、リモートMAGに接続されたMNのパケットがそのリモートMAGに関連付けられたトンネルを介して送信されるように、ローカル転送エントリを作成する必要があります。 MAG間のトンネルは、セクション6.2で述べた考慮事項に従って確立されていると想定されます。
+----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |MAG2| |LMA |
+----+ +----+ +----+ +----+ +----+
| | | | |
| data | data |
|<--------------------->|<----------------------->|
| | | | |
| | data | data |
| |<--------------------->|<----------->|
| | | | |
| | | | |
| | | LRI(Opt1) |
| | |<------------------------|
| | | | |
| | | | LRI(Opt2) |
| | | |<------------|
| | | | |
| | | LRA(Opt3) |
| | |------------------------>|
| | | | |
| | | | LRA(Opt4) |
| | | |------------>|
| | | | |
| | | | |
| | | | |
| data | data | |
|<--------------------->|<--------->| |
| | | | |
| | data | |
| |<--------------------->| |
| | | | |
| | | | |
Opt1: MN1-ID,MN1-HNP,MAG2-IPv6-Address
Opt2: MN2-ID,MN2-HNP,MAG1-IPv6-Address
Opt3: U=0,MN1-ID,MN1-HNP,MAG2-IPv6-Address
Opt4: U=0,MN2-ID,MN2-HNP,MAG1-IPv6-Address
where U is the flag defined in Section 10.2.
ここで、Uはセクション10.2で定義されたフラグです。
Figure 4
図4
In this case, each MAG responds to the LRI with an LRA message. All subsequent packets are routed between the MAGs locally, without traversing the LMA. If one of the MAGs (say MAG1) responds with a successful LRA (Status value is zero) and the other (say MAG2) responds with an error (Status value is non-zero), LR will still be performed in one direction (MN1->MAG1->MAG2->MN2), but the packets flowing the other way will take the LMA path (MN2->MAG2->LMA->MAG1->MN1).
この場合、各MAGはLRIにLRAメッセージで応答します。後続のすべてのパケットは、LMAを経由せずに、MAG間でローカルにルーティングされます。 MAGの1つ（たとえばMAG1）が成功したLRA（ステータス値がゼロ）で応答し、もう1つ（たとえばMAG2）がエラー（ステータス値がゼロ以外）で応答する場合でも、LRは一方向で実行されます（MN1 -> MAG1-> MAG2-> MN2）ですが、逆方向に流れるパケットはLMAパスを経由します（MN2-> MAG2-> LMA-> MAG1-> MN1）。
The protocol does not require any synchronization between the MAGs before local forwarding begins. Each MAG begins its local forwarding independent of the other.
プロトコルは、ローカル転送が始まる前にMAG間の同期を必要としません。各MAGは、互いに独立してローカル転送を開始します。
No synchronization between the MAGs is required because each MAG initiates LR in one direction. After the LMA instructs MAG1 to initiate LR, packets from MN1 to MN2 will take the path MN1->MAG1->MAG2->MN2 while those from MN2 to MN1 will take the path MN2->MAG2->LMA->MAG1->MN1 until the LMA instructs MAG2 to initiate LR as well. A MAG will forward a packet towards either another MAG or its own LMA; therefore, there would be no duplication of packets.
各MAGはLRを一方向に開始するため、MAG間の同期は必要ありません。 LMAがMAG1にLRの開始を指示した後、MN1からMN2へのパケットはMN1-> MAG1-> MAG2-> MN2の経路をたどりますが、MN2からMN1へのパケットはMN2-> MAG2-> LMA-> MAG1->の経路をたどります。 MN1は、LMAがMAG2にLRも開始するように指示するまで続きます。 MAGは別のMAGまたは独自のLMAのいずれかにパケットを転送します。したがって、パケットの重複はありません。
If one of the MNs, say MN1, detaches from its current MAG (in this case MAG1) and attaches to another MAG (say nMAG1), the localized routing state needs to be re-established. When the LMA receives the PBU from nMAG1 for MN1, it will see that localized routing is active for MN1. The LMA MUST then initiate LR at nMAG1 and update the LR state of MAG2 to use nMAG1 instead of MAG1.
MNの1つ、たとえばMN1が現在のMAG（この場合はMAG1）から切り離され、別のMAG（たとえばnMAG1）に接続された場合、ローカライズされたルーティング状態を再確立する必要があります。 LMAがMN1のnMAG1からPBUを受信すると、MN1のローカライズされたルーティングがアクティブであることがわかります。次に、LMAはnMAG1でLRを開始し、MAG2のLR状態を更新して、MAG1ではなくnMAG1を使用する必要があります。
In order to support localized routing, both MAGs SHOULD support the following encapsulation modes for the user packets, which are also defined for the tunnel between the LMA and MAG:
ローカライズされたルーティングをサポートするために、両方のMAGは、LMAとMAGの間のトンネルにも定義されているユーザーパケットの次のカプセル化モードをサポートする必要があります（SHOULD）。
o IPv4-or-IPv6-over-IPv6 [RFC5844]
o IPv4-or-IPv6-over-IPv6 [RFC5844]
o IPv4-or-IPv6-over-IPv4 [RFC5844]
o IPv4-or-IPv6-over-IPv4 [RFC5844]
o IPv4-or-IPv6-over-IPv4-UDP [RFC5844]
o IPv4-or-IPv6-over-IPv4-UDP [RFC5844]
o TLV-header UDP tunneling [RFC5845]
o TLVヘッダーUDPトンネリング[RFC5845]
o Generic Routing Encapsulation (GRE) tunneling with or without GRE key(s) [RFC5845]
o GREキーの有無にかかわらずGeneric Routing Encapsulation（GRE）トンネリング[RFC5845]
MAG1 and MAG2 MUST use the same tunneling mechanism for the data traffic tunneled between them. The encapsulation mode to be employed SHOULD be configurable. It is RECOMMENDED that: 1. As the default behavior, the inter-MAG tunnel uses the same encapsulation mechanism as that being used for the PMIPv6 tunnel between the LMA and the MAGs. MAG1 and MAG2 automatically start using the same encapsulation mechanism without a need for a special configuration on the MAGs or a dynamic tunneling mechanism negotiation between them.
MAG1とMAG2は、それらの間でトンネリングされるデータトラフィックに同じトンネリングメカニズムを使用する必要があります。採用されるカプセル化モードは設定可能である必要があります。 1.デフォルトの動作として、MAG間トンネルは、LMAとMAGの間のPMIPv6トンネルに使用されているのと同じカプセル化メカニズムを使用します。 MAG1とMAG2は自動的に同じカプセル化メカニズムを使用して起動します。MAGに特別な設定をしたり、MAG間の動的なトンネリングメカニズムのネゴシエーションを行う必要はありません。
2. Configuration on the MAGs can override the default mechanism specified in Option 1 above. MAG1 and MAG2 MUST be configured with the same mechanism, and this configuration is most likely to be uniform throughout the PMIPv6 domain. If the packets on the PMIPv6 tunnel cannot be uniquely mapped onto the configured inter-MAG tunnel, this scenario is not applicable, and Option 3 below SHOULD directly be applied.
2. MAGの設定は、上記のオプション1で指定されたデフォルトのメカニズムを上書きできます。 MAG1とMAG2は同じメカニズムで構成する必要があり、この構成はPMIPv6ドメイン全体で均一である可能性が最も高いです。 PMIPv6トンネルのパケットを設定されたMAG間トンネルに一意にマッピングできない場合、このシナリオは適用されず、以下のオプション3を直接適用する必要があります。
3. An implicit or explicit tunnel negotiation mechanism between the MAGs can override the default mechanism specified in Option 1 above. The employed tunnel negotiation mechanism is outside the scope of this document.
3. MAG間の暗黙的または明示的なトンネルネゴシエーションメカニズムは、上記のオプション1で指定されたデフォルトのメカニズムを上書きできます。採用されているトンネルネゴシエーションメカニズムは、このドキュメントの範囲外です。
In this scenario, both the MNs are attached to the same MAG, but are
anchored at two different LMAs. MN1 is anchored at LMA1, and MN2 is
anchored at LMA2. Note that the two LMAs are part of the same
Provider Domain.
Internet
: :
+------------------+
| |
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
| |
| |
+------------------+
|
|
|
+-----+
| MAG |
+-----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 5
図5
Hence, neither LMA has a means to determine that the two Mobile Nodes are attached to the same MAG. Only the MAG can possibly determine that the two Mobile Nodes involved in communication are attached to it. Therefore, localized routing MUST be initiated by the MAG.
したがって、どちらのLMAにも、2つのモバイルノードが同じMAGに接続されていると判断する手段がありません。 MAGのみが、通信に関与する2つのモバイルノードが接続されていると判断できる可能性があります。したがって、ローカライズされたルーティングはMAGによって開始される必要があります。
The MAG sends an LRI message containing the MN-ID, HNP, and the counterpart LMA address to each LMA. Each LMA makes a decision to support local forwarding independently based on configured policy for the corresponding LMA. Each LMA MUST respond to the LRI message with an LRA message. If the initiation of LR on the LMA was successful, the Status value in the received LRA would be set to zero. After the MAG receives both the LRA messages, each with the Status value set to zero (success) from the two different LMAs, the MAG will conclude that it can provide local forwarding support for the two Mobile Nodes.
MAGは、MN-ID、HNP、および対応するLMAアドレスを含むLRIメッセージを各LMAに送信します。各LMAは、対応するLMAの構成済みポリシーに基づいて、ローカル転送を個別にサポートすることを決定します。各LMAは、LRAメッセージでLRIメッセージに応答する必要があります。 LMAでのLRの開始が成功した場合、受信したLRAのステータス値はゼロに設定されます。 MAGが両方のLRAメッセージを受信し、それぞれが2つの異なるLMAからステータス値がゼロ（成功）に設定された後、MAGは2つのモバイルノードにローカル転送サポートを提供できると結論付けます。
+----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG | |LMA1| |LMA2|
+----+ +----+ +----+ +----+ +----+
| | | | |
| data | data | data |
|<--------------------->|<--------->|<----------->|
| | | | |
| | data | data |
| |<--------->|<----------------------->|
| | | | |
| | | | |
| | | LRI(Opt1) | |
| | |---------->| |
| | | | |
| | | LRI(Opt2) |
| | |------------------------>|
| | | | |
| | | LRA(Opt3) | |
| | |<----------| |
| | | | |
| | | LRA(Opt4) |
| | |<------------------------|
| | | | |
| | | | |
| | | | |
| data | | |
|<--------------------->| | |
| | | | |
| | data | | |
| |<--------->| | |
| | | | |
| | | | |
Opt1: MN1-ID,MN1-HNP
Opt2: MN2-ID,MN2-HNP
Opt3: U=0,MN1-ID,MN1-HNP
Opt4: U=0,MN2-ID,MN2-HNP
where U is the flag defined in Section 10.2.
ここで、Uはセクション10.2で定義されたフラグです。
Figure 6
図6
If one of the MNs, say MN1, detaches from its current MAG (in this case MAG1) and attaches to another MAG (say nMAG1), the current MAG MUST immediately stop using the LRE and MUST send all packets originated by the other MN (MN2) towards its LMA (in this case LMA2).
MNの1つ、たとえばMN1が現在のMAG（この場合はMAG1）から切り離され、別のMAG（たとえば、nMAG1）に接続する場合、現在のMAGはLREの使用を直ちに停止し、他のMNが発信したすべてのパケットを送信する必要があります（ MN2）LMA（この場合はLMA2）に向けて。
This scenario will not be covered in this document since PMIPv6 does not define any form of inter-LMA communication. When a supported scenario, such as Scenario A12, morphs into Scenario A22, the node that initiated the localized routing session MUST tear it down in order to prevent lasting packet loss. This can result in transient packet loss when routing switches between the localized path into the normal path through the LMAs. In applications that are loss sensitive, this can lead to observable service disruptions. In deployments where Scenario A22 is possible, the use of localized routing is NOT RECOMMENDED when packet-loss-sensitive applications are in use.
PMIPv6はどのような形式のLMA間通信も定義しないため、このシナリオではこのドキュメントでは扱いません。サポートされているシナリオ（シナリオA12など）がシナリオA22に変化すると、ローカライズされたルーティングセッションを開始したノードは、持続的なパケット損失を防ぐためにそれを破棄する必要があります。これにより、LMAを介してローカライズされたパスから通常のパスにスイッチをルーティングするときに、一時的なパケット損失が発生する可能性があります。損失の影響を受けやすいアプリケーションでは、これは観察可能なサービスの中断につながる可能性があります。シナリオA22が可能な展開では、パケット損失の影響を受けやすいアプリケーションが使用されている場合、ローカライズされたルーティングの使用は推奨されません。
PMIPv6 MNs can use an IPv4 Home Address (HoA) as described in [RFC5844]. In order to support the setup and maintenance of localized routes for these IPv4 HoAs in PMIPv6, the MAGs MUST add the IPv4 HoAs into their LREs. The MAGs MUST also support encapsulation of IPv4 packets as described in [RFC5844]. The localized routing protocol messages MUST include an IPv4 HoA option in their signaling messages in order to support IPv4 addresses for localized routing.
PMIPv6 MNは、[RFC5844]で説明されているように、IPv4ホームアドレス（HoA）を使用できます。 PMIPv6でこれらのIPv4 HoAのローカライズされたルートのセットアップとメンテナンスをサポートするために、MAGはLREにIPv4 HoAを追加する必要があります。 MAGは、[RFC5844]で説明されているように、IPv4パケットのカプセル化もサポートする必要があります。ローカライズされたルーティングのIPv4アドレスをサポートするには、ローカライズされたルーティングプロトコルメッセージのシグナリングメッセージにIPv4 HoAオプションを含める必要があります。
If the transport network between the PMIPv6 entities involved in localized routing is IPv4-only, the LRI and LRA messages MUST be encapsulated similar to the PBU/PBA messages as specified in [RFC5844]. The encapsulation mode used SHOULD be identical to the one used to transport PBU and PBA messages.
ローカライズされたルーティングに関与するPMIPv6エンティティ間のトランスポートネットワークがIPv4のみの場合、LRIおよびLRAメッセージは、[RFC5844]で指定されているPBU / PBAメッセージと同様にカプセル化する必要があります。使用されるカプセル化モードは、PBUおよびPBAメッセージの転送に使用されるものと同じである必要があります（SHOULD）。
The localized routing messages use two new Mobility Header types (17 and 18). The LRI message requests creation or deletion of the localized routing state, and the LRA message acknowledges the creation or deletion of such localized routing state.
ローカライズされたルーティングメッセージは、2つの新しいモビリティヘッダータイプ（17および18）を使用します。 LRIメッセージはローカライズされたルーティング状態の作成または削除を要求し、LRAメッセージはそのようなローカライズされたルーティング状態の作成または削除を確認します。
The LRI messages use a new Mobility Header type (17). The LMA sends an LRI message to a MAG to request local forwarding for a pair of MNs. The MAG may also send this message to request the two LMAs for offering local forwarding as described in Section 7.
LRIメッセージは新しいモビリティヘッダータイプ（17）を使用します。 LMAはLRIメッセージをMAGに送信して、MNのペアのローカル転送を要求します。 MAGは、このメッセージを送信して、セクション7で説明されているように、ローカル転送を提供するように2つのLMAを要求することもできます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number: A monotonically increasing integer. Set by a sending node in a request message and used to match a reply to the request.
シーケンス番号：単調に増加する整数。要求メッセージの送信ノードによって設定され、要求への応答を照合するために使用されます。
Reserved: This field is unused and MUST be set to zero.
予約済み：このフィールドは未使用であり、ゼロに設定する必要があります。
Lifetime: The requested time, in seconds, for which the sender wishes to have local forwarding. A value of 0xffff (all ones) indicates an infinite lifetime. When set to 0, indicates a request to stop localized routing.
存続期間：送信者がローカル転送を希望する要求時間（秒単位）。値0xffff（すべて1）は、寿命が無限であることを示します。 0に設定されている場合、ローカライズされたルーティングを停止する要求を示します。
Mobility Options: MUST contain two separate MN-ID options, followed by one or more HNPs for each of the MNs. For instance, for Mobile Nodes MN1 and MN2 with identifiers MN1-ID and MN2-ID, and Home Network Prefixes MN1-HNP and MN2-HNP, the following tuple MUST be present in the following order: [MN1-ID, MN1-HNP], [MN2-ID, MN2-HNP]. The MN-ID and HNP options are the same as in [RFC5213]. The LRI MAY contain the remote MAG IPv6 address option, which is formatted identically to the HNP option, except that it uses a different Type code and the Prefix Length is always equal to 128 bits (see Section 10.1).
モビリティオプション：2つの個別のMN-IDオプションを含み、その後に各MNの1つ以上のHNPが含まれる必要があります。たとえば、識別子がMN1-IDおよびMN2-IDのモバイルノードMN1およびMN2、およびホームネットワークプレフィックスMN1-HNPおよびMN2-HNPの場合、次のタプルが次の順序で存在する必要があります。[MN1-ID、MN1-HNP ]、[MN2-ID、MN2-HNP]。 MN-IDおよびHNPオプションは[RFC5213]と同じです。 LRIはリモートMAG IPv6アドレスオプションを含むことができます。これは、異なるタイプコードを使用し、プレフィックス長が常に128ビットに等しいことを除いて、HNPオプションと同じ形式です（セクション10.1を参照）。
The LRI message SHOULD be re-transmitted if a corresponding LRA message is not received within LRA_WAIT_TIME time units, up to a maximum of LRI_RETRIES, each separated by LRA_WAIT_TIME time units.
対応するLRAメッセージがLRA_WAIT_TIME時間単位内で受信されない場合、最大LRI_RETRIESまでLRIメッセージを再送信する必要があります（それぞれLRA_WAIT_TIME時間単位で区切られます）。
The LRA messages use a new Mobility Header type (18). A MAG sends an LRA message to the LMA as a response to the LRI message. An LMA may also send this message to a MAG as a response to the LRI message as described in Section 7.
LRAメッセージは新しいモビリティヘッダータイプ（18）を使用します。 MAGはLRIメッセージへの応答としてLRAメッセージをLMAに送信します。セクション7で説明するように、LMAはこのメッセージをLRIメッセージへの応答としてMAGに送信することもできます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Reserved | Status | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number: Copied from the sequence number field of the LRI message being responded to.
シーケンス番号：応答されるLRIメッセージのシーケンス番号フィールドからコピーされます。
'U' flag: When set to 1, the LRA message is sent unsolicited.
「U」フラグ：1に設定されている場合、LRAメッセージは非送信請求で送信されます。
The Lifetime field indicates a new requested value. The MAG MUST wait for the regular LRI message to confirm that the request is acceptable to the LMA.
Lifetimeフィールドは、新しい要求された値を示します。 MAGは、要求がLMAに受け入れ可能であることを確認するために、通常のLRIメッセージを待つ必要があります。
Reserved: This field is unused and MUST be set zero.
予約済み：このフィールドは未使用であり、ゼロに設定する必要があります。
Status: 8-bit unsigned integer indicating the result of processing the Localized Routing Acknowledgment message. Values of the Status field less than 128 indicate that the Localized Routing Acknowledgment was processed successfully by the mobility entities(LMA or MAG). Values greater than or equal to 128 indicate that the Localized Routing Acknowledgment was rejected by the mobility entities. The following Status values are currently defined:
ステータス：Localized Routing Acknowledgementメッセージの処理結果を示す8ビットの符号なし整数。ステータスフィールドの値が128未満の場合、ローカライズされたルーティングの確認がモビリティエンティティ（LMAまたはMAG）によって正常に処理されたことを示します。 128以上の値は、ローカライズされたルーティング確認がモビリティエンティティによって拒否されたことを示します。現在、次のステータス値が定義されています。
0: Success 128: Localized Routing Not Allowed 129: MN Not Attached
0：成功128：ローカライズされたルーティングは許可されません129：MNが接続されていません
Lifetime: The time, in seconds, for which local forwarding is supported. It is typically copied from the corresponding field in the LRI message.
ライフタイム：ローカル転送がサポートされる時間（秒単位）。通常、LRIメッセージの対応するフィールドからコピーされます。
Mobility Options: When Status code is 0, MUST contain the [MN-ID, HNP] tuples in the same order as in the LRI message. When Status code is not 0, MUST contain only those [MN-ID, HNP] tuples for which local forwarding is supported. The MN-ID and HNP options are the same as those described in [RFC5213].
モビリティオプション：ステータスコードが0の場合、LRIメッセージと同じ順序で[MN-ID、HNP]タプルを含める必要があります。ステータスコードが0でない場合、ローカル転送がサポートされている[MN-ID、HNP]タプルのみを含める必要があります。 MN-IDおよびHNPオプションは、[RFC5213]で説明されているものと同じです。
The MAG IPv6 address mobility option contains the IPv6 address of a MAG involved in localized routing. The MAG IPv6 address option has an alignment requirement of 8n+4.
MAG IPv6アドレスモビリティオプションには、ローカライズされたルーティングに関与するMAGのIPv6アドレスが含まれています。 MAG IPv6アドレスオプションには、8n + 4のアライメント要件があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MAG IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
51
５１
Length
長さ
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 18.
タイプおよび長さフィールドを除く、オクテットでオプションの長さを示す8ビットの符号なし整数。このフィールドは18に設定する必要があります。
Reserved (R)
予約済み（R）
This 8-bit field is unused. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
この8ビットのフィールドは未使用です。値は送信者によって0に初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。
Address Length
アドレス長
This field MUST be set to 128.
このフィールドは128に設定する必要があります。
MAG IPv6 Address
MAG IPv6アドレス
A 16-byte field containing the MAG's IPv6 address.
MAGのIPv6アドレスを含む16バイトのフィールド。
The LMA and the MAG must allow the following variables to be configurable:
LMAとMAGでは、以下の変数を構成可能にする必要があります。
LRA_WAIT_TIME: This variable is used to set the time interval, in seconds, between successive retransmissions of an LRI message. The default value is 3 seconds.
LRA_WAIT_TIME：この変数は、LRIメッセージの連続する再送信間の時間間隔を秒単位で設定するために使用されます。デフォルト値は3秒です。
LRI_RETRIES: This variable indicates the maximum number of times the initiator retransmits an LRI message before stopping. The default value for this variable is 3.
LRI_RETRIES：この変数は、イニシエーターが停止する前にLRIメッセージを再送信する最大回数を示します。この変数のデフォルト値は3です。
The protocol inherits the threats to [RFC5213] that are identified in [RFC4832]. The protocol specified in this document uses the same security association as defined in [RFC5213] for use between the LMA and the MAG to protect the LRI and LRA messages. This document also assumes the preexistence of a MAG-MAG security association if LR needs to be supported between them. Support for integrity protection using IPsec is REQUIRED, but support for confidentiality is OPTIONAL. The MAGs MUST perform ingress filtering on the MN-sourced packets before encapsulating them into MAG-MAG tunnels in order to prevent address spoofing.
プロトコルは、[RFC4832]で特定されている[RFC5213]への脅威を継承します。このドキュメントで指定されているプロトコルは、LMAとMAGの間で使用するために[RFC5213]で定義されているものと同じセキュリティアソシエーションを使用して、LRIおよびLRAメッセージを保護します。このドキュメントでは、それらの間でLRをサポートする必要がある場合に、MAG-MAGセキュリティアソシエーションが存在していることも前提としています。 IPsecを使用した整合性保護のサポートは必須ですが、機密性のサポートはオプションです。 MAGは、MNから送信されたパケットをMAG-MAGトンネルにカプセル化する前に、それらのパケットに対して入力フィルタリングを実行して、アドレススプーフィングを防止する必要があります。
The Localized Routing Initiation (described in Section 10.1) and the Localized Routing Acknowledgment (described in Section 10.2) have each been assigned a Mobility Header type (17 and 18, respectively) from the "Mobility Header Types - for the MH Type field in the Mobility Header" registry at http://www.iana.org/assignments/mobility-parameters.
ローカライズドルーティングの開始（セクション10.1で説明）とローカライズドルーティングの確認応答（セクション10.2で説明）には、それぞれ「モビリティヘッダータイプ-のMHタイプフィールドのモビリティヘッダータイプ」からモビリティヘッダータイプ（それぞれ17と18）が割り当てられています。 http://www.iana.org/assignments/mobility-parametersにある「モビリティヘッダー」レジストリ。
The MAG IPv6 Address has been assigned a Mobility Option type (51) from the "Mobility Options" registry at http://www.iana.org/assignments/mobility-parameters.
MAG IPv6アドレスには、http：//www.iana.org/assignments/mobility-parametersの「モビリティオプション」レジストリからモビリティオプションタイプ（51）が割り当てられています。
This document merges ideas from five different draft documents addressing the PMIP localized routing problem. The authors of these drafts are listed below (in alphabetical order).
このドキュメントは、PMIPのローカライズされたルーティングの問題に対処する5つの異なるドラフトドキュメントからのアイデアをマージします。これらのドラフトの作成者を以下に示します（アルファベット順）。
Kuntal Chowdhury <kchowdhury@starentnetworks.com>
Ashutosh Dutta <adutta@niksun.com>
Rajeev Koodli <rkoodli@starentnetworks.com>
Suresh Krishnan <suresh.krishnan@ericsson.com>
Marco Liebsch <marco.liebsch@nw.neclab.eu>
Paulo Loureiro <loureiro@neclab.eu>
Desire Oulai <desire.oulai@videotron.com>
Behcet Sarikaya <sarikaya@ieee.org>
Qin Wu <sunseawq@huawei.com>
Hidetoshi Yokota <yokota@kddilabs.jp>
The authors would like to thank Sri Gundavelli, Julien Abeille, Tom Taylor, Kent Leung, Mohana Jeyatharan, Jouni Korhonen, Glen Zorn, Ahmad Muhanna, Zoltan Turanyi, Dirk von Hugo, Pete McCann, Xiansong Cui, Carlos Bernardos, Basavaraj Patil, Jari Arkko, Mary Barnes, Les Ginsberg, Russ Housley, Carl Wallace, Ralph Droms, Adrian Farrel, and Stephen Farrell for their comments and suggestions.
著者は、スリガンダベリ、ジュリアンアベイユ、トムテイラー、ケントレオン、モハナジェヤタラン、ジョウニコロホネン、グレンゾーン、アフマドムハンナ、ゾルタントゥラニイ、ダークフォンヒューゴ、ピートマッキャン、シアンソンクイ、カルロスベルナルドス、バサヴァラジパティルArkko、Mary Barnes、Les Ginsberg、Russ Housley、Carl Wallace、Ralph Droms、Adrian Farrel、Stephen Farrellのコメントと提案。
[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月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Rufsey1] Gundavelli、S.、Ed。、Leunji、K.、Devarapalli、V.、Chowdhury、K.、and B. Patil、 "Proxy Mobile Ipp 1"、Rfak 2、August 2006。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]脇川、R.、S。ガンダベリ、「プロキシモバイルIPv6のIPv4サポート」、RFC 5844、2010年5月。
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010.
[RFC5845] Muhanna、A.、Khalil、M.、Gundavelli、S。、およびK. Leung、「Generic Routing Encapsulation（GRE）Key Option for Proxy Mobile IPv6」、RFC 5845、2010年6月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、Ed。、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。
[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月。
[RFC6279] Liebsch, M., Ed., Jeong, S., and Q. Wu, "Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement", RFC 6279, June 2011.
[RFC6279] Liebsch、M.、Ed。、Jeong、S。、およびQ. Wu、「Proxy Mobile IPv6（PMIPv6）Localized Routing Problem Statement」、RFC 6279、2011年6月。
Authors' Addresses
著者のアドレス
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal、Quebec Canada
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Rajeev Koodli Cisco Systems
Rajiv Coodley Cisco Systems
EMail: rkoodli@cisco.com
Paulo Loureiro NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
Paulo Loureiro NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36ハイデルベルクドイツ
EMail: loureiro@neclab.eu
Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, Jiangsu 21001 China
Wuhu AのQはテクノロジー株式会社です。101ソフトウェアアベニュー、Y U塗装区NaN京、江蘇21001中国
Phone: +86-25-56623633
EMail: sunseawq@huawei.com
Ashutosh Dutta NIKSUN
アシュトシュ・デュタ・ニクソン
EMail: adutta@niksun.com