Internet Engineering Task Force (IETF) H. Yokota
Request for Comments: 5949 KDDI Lab
Category: Standards Track K. Chowdhury
ISSN: 2070-1721 R. Koodli
Cisco Systems
B. Patil
Nokia
F. Xia
Huawei USA
September 2010
Fast Handovers for Proxy Mobile IPv6
Abstract
抽象
Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility when it performs a handover from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the handover performance in terms of latency and packet loss. While MIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6; RFC 5213) provides IP mobility to nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of MIPv6.
モバイルIPv6（MIPv6のは、RFC 3775）は、それが別のアクセスルータからハンドオーバを行う場合、IPモビリティとモバイルノードを提供し、モバイルIPv6（FMIPv6と）のための高速ハンドオーバ待ち時間及びパケット損失の点でハンドオーバー性能を向上させるために指定されています。 MIPv6の（とFMIPv6と同様に）は、モビリティ関連のシグナリングプロキシモバイルIPv6（PMIPv6の; RFC 5213）におけるモバイルノードの参加を必要とするいずれか持っているか、またはそのような関与なしにMIPv6の機能を持っていないノードにIPモビリティを提供します。それにも関わらず、ハンドオーバ待ち時間やパケットロスの面でのPMIPv6の基本性能は、MIPv6のとは全く異なると考えられていません。
When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of fast handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations.
高速ハンドオーバは、このような環境の中で考えた場合、いくつかの変更は、ネットワークベースのモビリティ管理に適応するためにFMIPv6のに必要とされています。プロキシモバイルIPv6をモビリティ管理プロトコルとして使用する場合、この文書は、モバイルIPv6（RFC 5568 FMIPv6と）のための高速ハンドオーバの使用を指定します。必要な拡張は、モバイルノードがIPモビリティの機能を持っていないので、どちらかのMIPv6またはFMIPv6の操作に関与していないシナリオをサポートするために、FMIPv6のために指定されています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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）の製品です。これは、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/rfc5949.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5949で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Notation ...........................................4
3. Terminology .....................................................4
4. Proxy-Based FMIPv6 Protocol Overview ............................5
4.1. Protocol Operation .........................................7
4.2. Inter-AR Tunneling Operation ..............................14
4.3. IPv4 Support Considerations ...............................16
5. PMIPv6-Related Fast Handover Issues ............................16
5.1. Manageability Considerations ..............................16
5.2. Expedited Packet Transmission .............................17
6. Message Formats ................................................18
6.1. Mobility Header ...........................................18
6.1.1. Handover Initiate (HI) .............................18
6.1.2. Handover Acknowledge (HAck) ........................20
6.2. Mobility Options ..........................................22
6.2.1. Context Request Option .............................22
6.2.2. Local Mobility Anchor Address (LMAA) Option ........23
6.2.3. Mobile Node Link-Local Address Interface
Identifier (MN LLA-IID) Option .....................24
6.2.4. Home Network Prefix Option .........................25
6.2.5. Link-Local Address Option ..........................25
6.2.6. GRE Key Option .....................................25
6.2.7. IPv4 Address Option ................................25
6.2.8. Vendor-Specific Mobility Option ....................25
7. Security Considerations ........................................26
8. IANA Considerations ............................................26
9. Acknowledgments ................................................28
10. References ....................................................28
10.1. Normative References .....................................28
10.2. Informative References ...................................29
Appendix A. Applicable Use Cases ..................................30
A.1. PMIPv6 Handoff Indication .................................30
A.2. Local Routing .............................................31
Proxy Mobile IPv6 (PMIPv6) [RFC5213] provides IP mobility to a mobile node that does not support Mobile IPv6 (MIPv6) [RFC3775] mobile node functionality. A proxy agent in the network performs the mobility management signaling on behalf of the mobile node. This model transparently provides mobility for nodes within a PMIPv6 domain. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of Mobile IPv6.
プロキシモバイルIPv6（PMIPv6の）[RFC5213]はモバイルIPv6（MIPv6の）[RFC3775]モバイルノードの機能をサポートしていないモバイルノードにIPモビリティを提供します。ネットワーク内のプロキシエージェントは、モバイルノードの代わりにモビリティ管理シグナリングを行います。このモデルは、透過的にPMIPv6ドメイン内のノードのモビリティを提供します。それにも関わらず、ハンドオーバ待ち時間やパケットロスの面でのPMIPv6の基本性能は、モバイルIPv6とは全く異なると考えられていません。
Fast handovers for Mobile IPv6 (FMIPv6) [RFC5568] describes the protocol to reduce the handover latency for Mobile IPv6 by allowing a mobile node to send packets as soon as it detects a new subnet link and by delivering packets to the mobile node as soon as its attachment is detected by the new access router. This document extends FMIPv6 for Proxy MIPv6 operation to minimize handover delay and packet loss as well as to transfer network-resident context for a PMIPv6 handover. [RFC5568] is normative for this document, except where this document specifies new or revised functions and messages.
モバイルIPv6（FMIPv6と）[RFC5568]のための高速ハンドオーバはできるだけ早くそれが新しいサブネットリンクを検出すると、移動ノードは、すぐにパケットを送信することを可能にすることによって、モバイルノードにパケットを送達することによって、モバイルIPv6のハンドオーバ待ち時間を低減するためのプロトコルを記述しその添付ファイルは新しいアクセスルータによって検出されます。この文書では、ハンドオーバ遅延およびパケット損失を最小化するために、並びにのPMIPv6ハンドオーバーのためのネットワークに常駐するコンテキストを転送するプロキシMIPv6の動作のためFMIPv6とが延びています。 [RFC5568]は、この文書は、新規または改訂された機能とメッセージを指定する場合を除いて、このドキュメントのための規範です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document reuses terminology from [RFC5213], [RFC5568], and [RFC3775]. The following terms and abbreviations are additionally used in this document.
このドキュメントは[RFC5213]、[RFC5568]及び[RFC3775]から用語を再利用します。以下の用語および略語は、さらに、このドキュメントで使用されています。
Access Network (AN): A network composed of link-layer access devices such as access points or base stations providing access to a Mobile Access Gateway (MAG) connected to it.
アクセスネットワーク（AN）：例えば、それに接続されたモバイル・アクセス・ゲートウェイ（MAG）へのアクセスを提供するアクセスポイントまたは基地局のようなリンク層のアクセス装置から構成されるネットワーク。
Previous Access Network (P-AN): The access network to which the Mobile Node (MN) is attached before handover.
前アクセスネットワーク（P-AN）：モバイルノード（MN）がハンドオーバ前に装着されたアクセスネットワーク。
New Access Network (N-AN): The access network to which the Mobile Node (MN) is attached after handover.
新アクセスネットワーク（N-AN）：アクセスネットワークへのモバイル・ノード（MN）がハンドオーバ後に装着されています。
Previous Mobile Access Gateway (PMAG): The MAG that manages mobility-related signaling for the mobile node before handover. In this document, the MAG and the Access Router are co-located.
以前のモバイル・アクセス・ゲートウェイ（PMAG）：ハンドオーバ前にモバイルノードのためのモビリティ関連シグナリングを管理するMAG。この文書では、MAGとアクセスルータは、同じ場所に配置されています。
New Mobile Access Gateway (NMAG): The MAG that manages mobility-related signaling for the mobile node after handover. In this document, the MAG and the Access Router (AR) are co-located.
新しいモバイルアクセスゲートウェイ（NMAG）：ハンドオーバ後、移動ノードのためのモビリティ関連シグナリングを管理MAG。この文書では、MAG及びアクセスルータ（AR）が同じ場所に配置されています。
Local Mobility Anchor (LMA): The topological anchor point for the mobile node's home network prefix(es) and the entity that manages the mobile node's binding state. This specification does not alter any capability or functionality defined in [RFC5213].
ローカルモビリティアンカー（LMA）：モバイルノードのホームネットワーク接頭語（es）とモバイルノードの結合状態を管理するエンティティのためのトポロジカルアンカーポイント。この仕様は、[RFC5213]で定義された任意の能力や機能を変更しません。
Handover indication: A generic signaling message, sent from the P-AN to the PMAG, that indicates a mobile node's handover. While this signaling is dependent on the access technology, it is assumed that Handover indication can carry the information to identify the mobile node and to assist the PMAG in resolving the NMAG (and the new access point or base station) to which the mobile node is moving. The details of this message are outside the scope of this document.
ハンドオーバ指示：PMAGにP-ANから送信された一般的なシグナリングメッセージは、それがモバイルノードのハンドオーバを示します。このシグナリングは、アクセス技術に依存しているが、ハンドオーバ指示は、モバイルノードを識別するために、モバイルノードがされるNMAG（および新しいアクセスポイントまたは基地局）を解決するPMAGを支援するための情報を運ぶことができることが想定されます移動。このメッセージの詳細は、このドキュメントの範囲外です。
This specification describes fast handover protocols for the network-based mobility management protocol called Proxy Mobile IPv6 (PMIPv6) [RFC5213]. The core functional entities defined in PMIPv6 are the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The LMA is the topological anchor point for the mobile node's home network prefix(es). The MAG acts as an access router (AR) for the mobile node and performs the mobility management procedures on its behalf. The MAG is responsible for detecting the mobile node's movements to and from the access link and for initiating binding registrations to the mobile node's local mobility anchor. If the MAGs can be informed of the detachment and/or attachment of the mobile node in a timely manner via, e.g., lower-layer signaling, it will become possible to optimize the handover procedure, which involves establishing a connection on the new link and signaling between mobility agents, compared to the baseline specification of PMIPv6.
この仕様は、プロキシ・モバイルIPv6（PMIPv6の）と呼ばれるネットワーク・ベースのモビリティ管理プロトコル[RFC5213]のための高速ハンドオーバプロトコルを記述する。 PMIPv6に定義されているコア機能エンティティは、ローカル・モビリティ・アンカー（LMA）とモバイル・アクセス・ゲートウェイ（MAG）です。 LMAは、モバイルノードのホームネットワーク接頭語（es）のためのトポロジカルアンカーポイントです。 MAGは、モバイルノードのアクセスルータ（AR）として機能し、その代わりにモビリティ管理手順を実行します。 MAGは、リンクとアクセスリンクからモバイルノードの動きを検出すると、移動ノードのローカル・モビリティ・アンカーに結合登録を開始するための責任があります。 MAGを介してタイムリーに移動ノードの剥離および/または付着を知ることができれば、例えば、下位レイヤシグナリングは、それが新しいリンクに接続を確立することを含むハンドオーバ手順を最適化することが可能になり、 PMIPv6のベースライン仕様に比べ、モビリティエージェント間のシグナリング。
In order to further improve the performance during the handover, this document specifies a bidirectional tunnel between the Previous MAG (PMAG) and the New MAG (NMAG) to tunnel packets meant for the mobile node. In order to enable the NMAG to send the Proxy Binding Update (PBU), the Handover Initiate (HI) and Handover Acknowledge (HAck) messages in [RFC5568] are extended for context transfer, in which parameters such as the mobile node's Network Access Identifier (NAI), Home Network Prefix (HNP), and IPv4 Home Address are transferred from the PMAG. New flags, 'P' and 'F', are defined for the HI and HAck messages to distinguish from those in [RFC5568] and to request packet forwarding, respectively.
さらに、ハンドオーバ時の性能を向上させるために、この文書は、モバイルノードのためのものトンネルパケットに前のMAG（PMAG）及び新MAG（NMAG）との間の双方向トンネルを指定します。 、更新（PBU）に結合ハンドオーバをプロキシを送信するNMAGを可能にするために、[RFC5568]に（ハック）肯定応答メッセージは、移動ノードのネットワークアクセス識別子などのパラメータたコンテキスト転送のために拡張される（HI）開始し、ハンドオーバ（NAI）、ホームネットワークプレフィックス（HNP）、およびIPv4のホームアドレスはPMAGから転送されています。新しいフラグ「P」と「F」は、[RFC5568]のものと区別するために、それぞれのパケット転送を要求するためにHI及びHAck処理メッセージに対して定義されています。
In this document, the Previous Access Router (PAR) and New Access Router (NAR) are interchangeable with the PMAG and NMAG, respectively. The reference network is illustrated in Figure 1. The access networks in the figure (i.e., P-AN and N-AN) are composed of Access Points (APs) defined in [RFC5568], which are often referred to as base stations in cellular networks.
この文書では、前のアクセスルータ（PAR）と新アクセスルータ（NAR）は、それぞれ、PMAGとNMAGと交換可能です。基準ネットワーク図（すなわち、P-AN及びN-AN）内のアクセスネットワークは、多くの場合、細胞内の基地局と呼ばれている[RFC5568]で定義されたアクセスポイント（AP）、から構成され、図1に示されています。ネットワーク。
Since a mobile node is not directly involved with IP mobility protocol operations, it follows that the mobile node is not directly involved with fast handover procedures either. Hence, the messages involving the mobile node in [RFC5568] are not used when PMIPv6 is in use. More specifically, the Router Solicitation for Proxy Advertisement (RtSolPr), the Proxy Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack), and the Unsolicited Neighbor Advertisement (UNA) messages are not applicable in the PMIPv6 context. A MAG that receives a RtSolPr or FBU message from a mobile node SHOULD behave as if they do not implement FMIPv6 as defined in [RFC5568] at all -- continuing to operate according to this specification within the network -- or alternatively, start serving that particular mobile node as specified in [RFC5568].
モバイルノードが直接IPモビリティプロトコル操作に関与しないので、移動ノードが直接的に高速ハンドオーバ手順に関与しないことになります。 PMIPv6の使用時したがって、[RFC5568]での移動ノードを含むメッセージが使用されません。具体的には、プロキシ広告（RtSolPrを）、高速更新（FBU）に結合するプロキシルータアドバタイズメント（代理ルータ広告）、高速応答（FBACK）を結合するためのルーター要請、および迷惑近隣広告（UNA）のメッセージは、PMIPv6のでは適用されません状況。こと配信開始、代替的にまたは - ネットワーク内でこの仕様に従って動作を継続 - 移動ノードからRtSolPrを又はFBUメッセージを受信したMAGは、[RFC5568]で定義されるように、彼らは全くFMIPv6とを実装していないかのように振る舞うべき[RFC5568]で指定されるように、特定の移動ノード。
+----------+
| LMA |
| |
+----------+
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PMAG |()_______)| NMAG | .
. | (PAR) | . . | (NAR) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference Network for Fast Handover
図1：高速ハンドオーバのためのリファレンスネットワーク
There are two modes of operation in FMIPv6 [RFC5568]. In the predictive mode of fast handover, a bidirectional tunnel between the PMAG (PAR) and NMAG (NAR) is established prior to the mobile node's attachment to the NMAG. In the reactive mode, this tunnel establishment takes place after the mobile node attaches to the NMAG. In order to alleviate the packet loss during a mobile node's handover (especially when the mobile node is detached from both links), the downlink packets for the mobile node need to be buffered either at the PMAG or NMAG, depending on when the packet forwarding is performed. It is hence REQUIRED that all MAGs have the capability and enough resources to buffer packets for the mobile nodes accommodated by them. The buffer size to be prepared and the rate at which buffered packets are drained are addressed in Section 5.4 of [RFC5568]. Note that the protocol operation specified in the document is transparent to the local mobility anchor (LMA); hence there is no new functional requirement or change on the LMA.
FMIPv6と[RFC5568]で2つの動作モードがあります。高速ハンドオーバの予測モードでは、PMAG（PAR）とNMAG間の双方向トンネル（NAR）はNMAGにモバイルノードの取り付けの前に確立されています。モバイルノードがNMAGにアタッチした後、反応モードでは、このトンネルの確立が行われます。 （移動ノードが両方のリンクから取り外された場合は特に）モバイルノードのハンドオーバ時のパケットロスを軽減するために、モバイルノードのためのダウンリンクパケットは、パケット転送である場合に応じて、いずれかPMAG又はNMAGでバッファリングする必要があります行きました。したがって、すべてのMAGは、それらが収容するモバイルノードに対してパケットをバッファリングする機能と十分なリソースを持っていることが必要とされます。調製されるべきパケットをバッファリングする速度が排出されるバッファサイズは、[RFC5568]のセクション5.4で扱われています。文書に指定されたプロトコルの動作は、ローカル・モビリティ・アンカー（LMA）に対して透明であることに留意されたいです。したがって、LMAには、新たな機能要件や変更はありません。
Unlike MIPv6, the mobile node in the PMIPv6 domain is not involved with IP mobility signaling; therefore, in order for the predictive fast handover to work effectively, it is REQUIRED that the mobile node is capable of reporting lower-layer information to the AN at a short enough interval, and that the AN is capable of sending the Handover indication to the PMAG at an appropriate timing. The sequence of events for the predictive fast handover is illustrated in Figure 2.
MIPv6のとは異なり、PMIPv6ドメイン内のモバイルノードはIPモビリティシグナリングに関与していません。従って、効果的に機能する予測高速ハンドオーバのためには、モバイルノードが十分に短い間隔でANに下位層情報を報告することが可能であること、およびANは、ハンドオーバ指示を送信することが可能であることが要求されます適切なタイミングでPMAG。予測高速ハンドオーバのためのイベントのシーケンスは、図2に示されています。
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) |--Report-->| | | | |
| | | | | |
| | Handover | | |
(b) | |------indication------>| | |
| | | | | |
| | | | | |
(c) | | | |----HI---->| |
| | | | | |
| | | | | |
(d) | | | |<---HAck---| |
| | | | | |
| | | | | |
| | | |HI/HAck(optional) |
(e) | | | |<- - - - ->| |
| | | #=|<===================|
(f) | | | #====DL data=>| |
| Handover | Handover | | |
(g) |<-command--|<------command---------| | |
~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(h) |<---establishment---->|<----establishment----->| |
| | | (substitute for UNA) | |
| | | | | |
(i) |<==================DL data=====================| |
| | | | | |
(j) |===================UL data====================>|=# |
| | | #=|<============# |
| | | #=====================>|
/ | | | | | | \
|(k) | | | | |--PBU-->| |
| | | | | | | |
|(l) | | | | |<--PBA--| |
| |<==================DL data=====================|<=======| |
| | | | | | | |
\ |===================UL data====================>|=======>| /
UL Uplink
DL Downlink
PBA Proxy Binding Acknowledgment
Figure 2: Predictive Fast Handover for PMIPv6 (Initiated by PMAG)
図2のPMIPv6のための予測高速ハンドオーバー（PMAGによって開始されます）
The detailed descriptions are as follows:
次のように詳細な説明は、次のとおりです。
(a) The mobile node detects that a handover is imminent and reports its identifier (MN ID) and the New Access Point Identifier (New AP ID) [RFC5568] to which the mobile node is most likely to move. The MN ID could be the NAI, link-layer address, or any other suitable identifier, but the MAG SHOULD be able to map any access-specific identifier to the NAI as the MN ID. In some cases, the previous access network (P-AN) will determine the New AP ID for the mobile node. This step is access technology specific, and details are outside the scope of this document.
（a）は、モバイルノードは、ハンドオーバが差し迫っていると、モバイルノードが移動する可能性が最も高いであるために、その識別子（MNのID）と新しいアクセスポイント識別子（新AP ID）[RFC5568]を報告することを検出します。 MN IDがNAI、リンク層アドレス、または任意の他の適切な識別子とすることができるが、MAGは、MNのIDとしてNAIへのアクセス固有の識別子をマッピングすることができるべきです。いくつかのケースでは、以前のアクセスネットワーク（P-AN）は、移動ノードの新しいAPのIDを決定します。このステップでは、特定のアクセス技術であり、その詳細は、このドキュメントの範囲外です。
(b) The previous access network, to which the mobile node is currently attached, indicates the handover of the mobile node to the previous mobile access gateway (PMAG), with the MN ID and New AP ID. Detailed definition and specification of this message are outside the scope of this document.
（b）は、モバイルノードが現在接続された前のアクセスネットワークは、MNのIDと新しいAPのIDと、前回のモバイルアクセスゲートウェイ（PMAG）へのモバイルノードのハンドオーバを示します。このメッセージの詳細な定義および仕様この文書の範囲外です。
(c) The previous MAG derives the new mobile access gateway (NMAG) from the New AP ID, which is a similar process to that of constructing an [AP ID, AR-Info] tuple in [RFC5568]. The previous MAG then sends the Handover Initiate (HI) message to the new MAG. The HI message MUST have the 'P' flag set and include the MN ID, the HNP(s), and the address of the local mobility anchor that is currently serving the mobile node. If there is a valid (non-zero) MN Link-layer Identifier (MN LL-ID), that information MUST also be included. With some link layers, the MN Link-local Address Interface Identifier (MN LLA-IID) can also be included (see Section 6.2.3).
（C）前のMAGは、[AP ID、AR-INFO]は[RFC5568]をタプル構築と同様の処理である新しいAP ID、より新しいモバイル・アクセス・ゲートウェイ（NMAG）を導出します。前のMAGは、新しいMAGへのハンドオーバが開始（HI）メッセージを送信します。 HIメッセージは、「P」フラグセットを有し、MNのID、HNP（S）、現在モバイルノードにサービスを提供しているローカル・モビリティ・アンカーのアドレスを含まなければなりません。有効な（非ゼロ）MNのリンク層識別子（MNのLL-ID）がある場合、その情報も含まなければなりません。いくつかのリンク層では、MNリンクローカルアドレスインタフェース識別子（MN-LLA IID）も（6.2.3項を参照）を含めることができます。
(d) The new MAG sends the Handover Acknowledge (HAck) message back to the previous MAG with the 'P' flag set.
（D）新しいMAGは、ハンドオーバが「P」フラグを設定して戻る前MAGに（上記ハンドオフ）メッセージを確認し送信します。
(e) If it is preferred that the timing of buffering or forwarding should be later than step (c), the new MAG MAY optionally request that the previous MAG buffer or forward packets at a later and appropriate time, by setting the 'U' flag [RFC5568] or the 'F' flag in the HI message, respectively.
それはバッファリングまたは転送のタイミングは、後工程（c）よりであることが好ましい場合には（E）、新しいMAGは「U」を設定することにより、後、適切な時間に要求前MAGバッファまたは順方向パケットのことを、任意にそれぞれフラグ[RFC5568]またはHIメッセージ内の「F」フラグ。
(f) If the 'F' flag is set in the previous step, a bidirectional tunnel is established between the previous MAG and new MAG, and packets destined for the mobile node are forwarded from the previous MAG to the new MAG over this tunnel. After decapsulation, those packets MAY be buffered at the new MAG. If the connection between the new access network and new MAG has already been established, those packets MAY be forwarded towards the new access network, which then becomes responsible for them (e.g., buffering or delivering, depending on the condition of the mobile node's attachment); this is access technology specific.
「F」フラグが前のステップで設定されていれば（F）、双方向トンネルは、前のMAGと新しいMAGとの間で確立され、モバイルノード宛のパケットは、このトンネルを介して新しいMAGに前MAGから転送されています。カプセル解除した後、これらのパケットは、新たなMAGでバッファリングされてもよいです。新しいアクセス・ネットワークと新しいMAGとの間の接続がすでに確立されている場合は、それらのパケットは、それらの責任となり、新たなアクセスネットワークに向けて転送されてもよい（例えば、バッファリングまたはモバイルノードの接続の状態に応じて、提供） ;これは、特定のアクセス技術です。
(g) When handover is ready on the network side, the mobile node is triggered to perform handover to the new access network. This step is access technology specific, and details are outside the scope of this document.
ハンドオーバがネットワーク側の準備が整うと（G）、モバイルノードは、新しいアクセス・ネットワークへのハンドオーバを実行するようにトリガされます。このステップでは、特定のアクセス技術であり、その詳細は、このドキュメントの範囲外です。
(h) The mobile node establishes a physical-layer connection with the new access network (e.g., radio channel assignment), which in turn triggers the establishment of a link-layer connection between the new access network and new MAG if not yet established. An IP-layer connection setup may be performed at this time (e.g., PPP IPv6 Control Protocol) or at a later time (e.g., stateful or stateless address autoconfiguration). This step can be a substitute for the Unsolicited Neighbor Advertisement (UNA) in [RFC5568]. If the new MAG acquires a valid new MN LL-ID via the new access network and a valid old MN LL-ID from the previous MAG at step (c), these IDs SHOULD be compared to determine whether the same interface is used before and after handover. When the connection between the mobile node and new MAG is PPP and the same interface is used for the handover, the new MAG SHOULD confirm that the same interface identifier is used for the mobile node's link-local address (this is transferred from the previous MAG using the MN LLA-IID option at step (c), and sent to the mobile node during the Configure-Request/Ack exchange).
（H）モバイルノードは、次に、新しいアクセス・ネットワークとまだ確立されていない場合は、新しいMAGとの間のリンク層接続の確立をトリガする新しいアクセス・ネットワーク（例えば、無線チャネル割り当て）と物理層の接続を確立します。 IP層の接続のセットアップは、この時間（例えば、PPPのIPv6制御プロトコル）または後で（例えば、ステートフルまたはステートレスアドレス自動設定）で行ってもよいです。このステップは、[RFC5568]に迷惑近隣広告（UNA）の代用とすることができます。新しいMAGは、新しいアクセス・ネットワークと工程（c）で前MAGからの有効な古いMN LL-IDを介して有効な新しいMN LL-IDを取得した場合、これらのIDは、同じインタフェースが前に使用されているかどうかを決定するために比較されるべきであるとハンドオーバ後。モバイルノードと新しいMAGとの間の接続は、PPPと同じインタフェースがハンドオーバに使用される場合、新しいMAGは、同一のインタフェース識別子は（これは、前のMAGから転送された移動ノードのリンクローカルアドレスに使用されていることを確認してください工程（c）におけるMN LLA-IIDオプションを使用して、）設定要求/ ACK交換の間にモバイルノードに送信されます。
(i) The new MAG starts to forward packets destined for the mobile node via the new access network.
（I）新しいMAGは、新しいアクセス・ネットワークを介してモバイルノード宛てのパケットの転送を開始します。
(j) The uplink packets from the mobile node are sent to the new MAG via the new access network, and the new MAG forwards them to the previous MAG. The previous MAG then sends the packets to the local mobility anchor that is currently serving the mobile node.
（J）モバイルノードからの上りパケットが新しいアクセスネットワークを介して新しいMAGに送信され、そして新しいMAGはMAG前に転送されます。前のMAGは、現在、移動ノードにサービスを提供しているローカルモビリティアンカーにパケットを送信します。
(k) The new MAG sends the Proxy Binding Update (PBU) to the local mobility anchor, whose address is provided in step (c). Steps (k) and (l) are not part of the fast handover procedure but are shown for reference.
（k）が新しいMAGは、プロキシ・バインディング更新（PBU）は、アドレスが工程（c）で提供されるローカル・モビリティ・アンカーに送信します。工程（k）及び（l）は高速ハンドオーバ手順の一部ではなく、参照のために示されています。
(l) The local mobility anchor sends back the Proxy Binding Acknowledgment (PBA) to the new MAG. From this time on, the packets to/from the mobile node go through the new MAG instead of the previous MAG.
（L）ローカル・モビリティ・アンカーは、新しいMAGにプロキシバインディング確認応答（PBA）を返信します。上のこの時から、モバイルノードへ/からのパケットではなく、前のMAGの新しいMAGを通過します。
According to Section 4 of [RFC5568], the previous MAG establishes a binding between the Previous Care-of Address (PCoA) and New Care-of Address (NCoA) to forward packets for the mobile node to the new MAG, and the new MAG creates a proxy neighbor cache entry to receive those packets for the NCoA before the mobile node arrives. In the case of PMIPv6, however, the only address that is used by the mobile node is the Mobile Node's Home Address (MN-HoA), so the PMAG forwards the mobile node's packets to the NMAG instead of the NCoA. The NMAG then simply decapsulates those packets and delivers them to the mobile node. FMIPv4 [RFC4988] specifies forwarding when the mobile node uses the home address as its on-link address rather than the care-of address. The usage in PMIPv6 is similar to that in FMIPv4, where the address(es) used by the mobile node is/are based on its HNP(s). Since the NMAG can obtain the link-layer address (MN LL-ID) and HNP(s) via the HI message (also the interface identifier of the mobile node's link-local address (MN LLA-ID), if available), it can create a neighbor cache entry for the link-local address and the routes for the whole HNP(s), even before the mobile node performs Neighbor Discovery. For the uplink packets from the mobile node after handover in step (j), the NMAG forwards the packets to the PMAG through the tunnel established in step (f). The PMAG then decapsulates and sends them to the local mobility anchor.
[RFC5568]のセクション4によれば、以前のMAGは、新しいMAGへのモバイルノードのためにパケットを転送する前のアドレスのケア（PCOA）と新気付アドレス（NCOA）との間の結合、及び新しいMAG確立しますモバイルノードが到着する前にNCOAためにそれらのパケットを受信するために、プロキシ近隣キャッシュエントリを作成します。 PMIPv6の場合には、しかしながら、モバイルノードによって使用されている唯一のアドレスは、モバイルノードのホームアドレス（MN-HoAが）なので、PMAGはNMAG代わりのNCOAにモバイルノードのパケットを転送します。 NMAGは、単にこれらのパケットのカプセル化を解除し、モバイルノードに配信します。 FMIPv4 [RFC4988]モバイルノードがオンリンクのアドレスではなく、気付けアドレスとしてホームアドレスを使用している場合、転送を指定します。 PMIPv6における用法は、モバイルノードによって使用されるアドレス（複数可）は/そのHNP（S）に基づいてされるFMIPv4、と同様です。 NMAGは、HIメッセージを介してリンク層アドレス（MN LL-ID）とHNP（S）（モバイルノードのリンクローカルアドレス（MN LLA-ID）の、インタフェース識別子を、可能な場合）を得ることができるので、それを移動ノードは近隣探索を実行する前であっても、リンクローカルアドレスの近隣キャッシュ・エントリ全体HNP（S）のためのルートを作成することができます。ステップ（J）においてハンドオーバ後、移動ノードからの上りパケットについて、NMAGステップ（F）は確立されたトンネルを介してPMAGへパケットを転送します。 PMAGは、カプセル化を解除し、ローカル・モビリティ・アンカーに送信します。
The timing of the context transfer and that of packet forwarding may be different. Thus, a new flag 'F' and Option Code values for it in the HI and HAck messages are defined to request forwarding. To request buffering, the 'U' flag has already been defined in [RFC5568]. If the PMAG receives the HI message with the 'F' flag set, it starts forwarding packets for the mobile node. The HI message with the 'U' flag set MAY be sent earlier if the timing of buffering is different from that of forwarding. If packet forwarding is completed, the PMAG MAY send the HI message with the 'F' flag set and the Option Code value set to 2. Via this message, the ARs on both ends can tear down the forwarding tunnel synchronously.
パケット転送のコンテキスト転送のタイミングと、それは異なっていてもよいです。従って、HI及びHAck処理メッセージでそれのための新しいフラグ「F」とオプション・コード値は転送を要求するために定義されています。バッファリングを要求するために、「U」フラグが既に[RFC5568]で定義されています。 PMAGが「F」フラグが設定されたHIメッセージを受信した場合、それはモバイルノードのためにパケットの転送を開始します。バッファリングのタイミングは転送と異なる場合「U」フラグが設定されたHIメッセージは、以前送信されるかもしれません。パケット転送が完了すると、PMAGは、「F」フラグが設定し、このメッセージを介して2に設定オプションコード値とHIメッセージを送信することができる、両端のARは同期転送トンネルを切断することができます。
The IP addresses in the headers of those user packets are summarized below:
これらのユーザパケットのヘッダ内のIPアドレスは以下のとおりであります：
In step (f),
ステップ（F）において、
Inner source address: IP address of the correspondent node
インナー元アドレス：コレスポンデントノードのIPアドレス
Inner destination address: HNP or Mobile Node's IPv4 Home Address (IPv4-MN-HoA)
インナー宛先アドレス：HNPまたはモバイルノードのIPv4ホームアドレス（IPv4-MN-HoAで）
Outer source address: IP address of the PMAG
外側の送信元アドレス：PMAGのIPアドレス
Outer destination address: IP address of the NMAG
外側の宛先アドレス：NMAGのIPアドレス
In step (i),
工程（i）において、
Source address: IP address of the correspondent node
ソースアドレス：コレスポンデントノードのIPアドレス
Destination address: HNP or IPv4-MN-HoA
宛先アドレス：HNPまたはIPv4-MN-HoAを
In step (j),
ステップ（J）において、
- from the mobile node to the NMAG,
- モバイルノードからNMAGに、
Source address: HNP or IPv4-MN-HoA
ソースアドレス：HNPまたはIPv4-MN-HoAを
Destination address: IP address of the correspondent node
送信先アドレス：コレスポンデントノードのIPアドレス
- from the NMAG to the PMAG,
- PMAGへNMAGから、
Inner source address: HNP or IPv4-MN-HoA
インナー元アドレス：HNPまたはIPv4-MN-HoAを
Inner destination address: IP address of the correspondent node
インナー宛先アドレス：コレスポンデントノードのIPアドレス
Outer source address: IP address of the NMAG
外側の送信元アドレス：NMAGのIPアドレス
Outer destination address: IP address of the PMAG
外側の宛先アドレス：PMAGのIPアドレス
- from the PMAG to the LMA,
- LMAへPMAGから、
Inner source address: HNP or IPv4-MN-HoA
インナー元アドレス：HNPまたはIPv4-MN-HoAを
Inner destination address: IP address of the correspondent node
インナー宛先アドレス：コレスポンデントノードのIPアドレス
Outer source address: IP address of the PMAG
外側の送信元アドレス：PMAGのIPアドレス
Outer destination address: IP address of the LMA
外側の宛先アドレス：LMAのIPアドレス
In the case of the reactive handover for PMIPv6, since the mobile node does not send either the FBU or UNA, it would be more natural that the NMAG send the HI message to the PMAG after the mobile node has moved to the new link. The NMAG then needs to obtain the information of the PMAG beforehand. Such information could be provided, for example, by the mobile node sending the AP-ID on the old link and/or by the lower-layer procedures between the P-AN and N-AN. The exact method is not specified in this document. Figure 3 illustrates the reactive fast handover procedures for PMIPv6, where the bidirectional tunnel establishment is initiated by the NMAG.
モバイルノードがFBUやUNAのいずれかを送信しませんので、PMIPv6のための反応性のハンドオーバ、の場合は、モバイルノードが新しいリンクに移動した後NMAGはPMAGにHIメッセージを送信することがより自然になります。 NMAGは、次いで予めPMAGの情報を取得する必要があります。そのような情報は、古いリンク上および/またはP-AN及びN-ANとの間の下層手順によってAP-IDを送信するモバイルノードによって、例えば、提供することができます。正確な方法は、この文書で指定されていません。図3は、双方向トンネルの確立がNMAGによって開始されるのPMIPv6のための反応高速ハンドオーバ手順を示す図です。
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) ~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(b) |<--establishment-->|<-------establishment------>| |
| | |(substitute for UNA and FBU)| |
| | | | | |
| | | | | |
(c) | | | |<-----HI-------| |
| | | | | |
| | | | | |
(d) | | | |-----HAck----->| |
| | | | | |
| | | | | |
(e) | | | #=|<=======================|
| | | #================>|=# |
|<====================DL data======================# |
| | | | | |
(f) |=====================UL data===================>|=# |
| | | #=|<================# |
| | | #=========================>|
| | | | | |
/ | | | | | | \
|(g) | | | | |--PBU-->| |
| | | | | | | |
|(h) | | | | |<--PBA--| |
| |<====================DL data====================|<=======| |
| | | | | | | |
\ |=====================UL data===================>|=======>| /
Figure 3: Reactive Fast Handover for PMIPv6 (Initiated by NMAG)
図3：PMIPv6のための反応の高速ハンドオーバ（NMAGによって開始されます）
The detailed descriptions are as follows:
次のように詳細な説明は、次のとおりです。
(a) The mobile node undergoes handover from the previous access network to the new access network.
（a）は、移動ノードは、前のアクセスネットワークから新たなアクセスネットワークへのハンドオーバを受けます。
(b) The mobile node establishes a connection (e.g., radio channel) with the new access network, which triggers the establishment of the connection between the new access network and new MAG. The MN ID is transferred to the new MAG at this step for the subsequent procedures. The AP-ID on the old link (Old AP ID), which will be provided by either the mobile node or the new access network, is also transferred to the new MAG to help identify the previous MAG on the new link. This can be regarded as a substitute for the UNA and FBU.
（b）は、モバイルノードは、新しいアクセス・ネットワークと新しいMAGとの間の接続の確立をトリガする新しいアクセス・ネットワークとの接続（例えば、無線チャネル）を確立します。 MNのIDは、その後の手順については、この段階で新しいMAGに転送されます。モバイルノードまたは新しいアクセス・ネットワークのいずれかによって提供されます古いリンク上のAP-ID（旧AP ID）が、また新しいリンク上で、以前のMAGを識別しやすくするために、新しいMAGに転送されます。これはUNAおよびFBUの代用とみなすことができます。
(c) The new MAG sends the HI message to the previous MAG. The HI message MUST have the 'P' flag set and include the MN ID. The Context Request option MAY be included to request additional context information on the mobile node to the previous MAG.
（C）新しいMAGは、前のMAGにHIメッセージを送信します。 HIメッセージは、「P」フラグセットを有し、MNのIDを含まなければなりません。コンテキスト要求オプションは、以前のMAGへのモバイルノードに追加のコンテキスト情報を要求するために含まれるかもしれません。
(d) The previous MAG sends the HAck message back to the new MAG with the 'P' flag set. The HAck message MUST include the HNP(s) and/or IPv4-MN-HoA that corresponds to the MN ID in the HI message and SHOULD include the MN LL-ID, only if it is valid (non-zero), and the local mobility anchor address that is currently serving the mobile node. The context information requested by the new MAG MUST be included. If the requested context is not available for some reason, the previous MAG MUST return the HAck message with the Code value 131. If the 'F' flag is set in the HI message at step (c) and forwarding is nevertheless not executable for some reason, the previous MAG MUST return the HAck message with the Code value 132.
（d）の前MAG「がP」フラグを設定してバック新しいMAGにハックメッセージを送信します。ハックメッセージは、それが有効な（非ゼロ）である場合にのみ、HIメッセージにMNのIDに対応し、MN LL-IDを含むべきであるHNP（単数または複数）および/またはIPv4-MN-HoAとを含み、MUST現在、モバイルノードにサービスを提供しているローカル・モビリティ・アンカーアドレス。新しいMAGによって要求されたコンテキスト情報を含まなければなりません。要求されたコンテキストが何らかの理由で利用できない場合は「F」フラグがステップ（c）にHIメッセージに設定され、転送がそれにもかかわらず、いくつかの実行可能でない場合、前のMAGは、コード値131とハックメッセージを返さなければなりません理由は、以前のMAGは、コード値132でハックメッセージを返さなければなりません。
(e) If the 'F' flag in the HI message is set at step (c), a bidirectional tunnel is established between the previous MAG and new MAG, and packets destined for the mobile node are forwarded from the previous MAG to the new MAG over this tunnel. After decapsulation, those packets are delivered to the mobile node via the new access network.
HIメッセージ内の「F」フラグがステップ（c）に設定されている場合（e）は、双方向トンネルは、前のMAGと新しいMAGとの間で確立され、モバイルノード宛てのパケットが新たに前MAGから転送されますこのトンネル上MAG。カプセル解除した後、これらのパケットは、新たなアクセスネットワークを介してモバイルノードに配信されます。
(f) The uplink packets from the mobile node are sent to the new MAG via the new access network, and the new MAG forwards them to the previous MAG. The previous MAG then sends the packets to the local mobility anchor that is currently serving the mobile node.
（f）は、モバイルノードからの上りパケットが新しいアクセスネットワークを介して新しいMAGに送信され、そして新しいMAGはMAG前に転送されます。前のMAGは、現在、移動ノードにサービスを提供しているローカルモビリティアンカーにパケットを送信します。
Steps (g)-(h) are the same as steps (k)-(l) in the predictive fast handover procedures.
工程（G） - 予測高速ハンドオーバ手順における（L） - （h）は、ステップ（K）と同じです。
In step (c), the IP address of the PMAG needs to be resolved by the NMAG to send the HI message to the PMAG. This information may come from the N-AN or some database that the NMAG can access.
工程（c）において、PMAGのIPアドレスはPMAGにHIメッセージを送信するNMAGによって解決される必要があります。この情報は、N-ANまたはNMAGがアクセスできるいくつかのデータベースから来るかもしれません。
When the PMAG (PAR) or NMAG (NAR), depending on the fast handover mode, receives the HI message with the 'F' flag set, it prepares to send/receive the mobile node's packets to/from the other MAG and returns the HAck message with the same sequence number. Both MAGs SHOULD support the following encapsulation modes for the user packets, which are also defined for the tunnel between the local mobility anchor and MAG: o IPv4-or-IPv6-over-IPv6 [RFC5844]
PMAG（PAR）またはNMAG（NAR）は、高速ハンドオーバモードに応じて、「F」フラグを設定してHIメッセージを受信すると、それは他のMAGへ/から移動ノードのパケットを送信/受信するために準備し、戻り同じシーケンス番号でメッセージをハック。両方のMAGはまた、ローカル・モビリティ・アンカーとMAGとの間のトンネルのために定義されたユーザパケットは、次のカプセル化モードをサポートする必要がありますOのIPv4またはIPv6の-オーバーのIPv6 [RFC5844]
o IPv4-or-IPv6-over-IPv4 [RFC5844]
OのIPv4またはIPv6の-オーバーのIPv4 [RFC5844]
o IPv4-or-IPv6-over-IPv4-UDP [RFC5844]
OのIPv4またはIPv6の-オーバーの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]
GREキー（S）を伴うまたは伴わないO総称ルーティングカプセル化（GRE）トンネル[RFC5845]
The PMAG and the NMAG 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:
PMAGとNMAGは、それらの間でトンネリングされたデータトラフィックに同じトンネリングメカニズムを使用しなければなりません。採用されるカプセル化モードは設定可能であるべきです。これは、することをお勧めします。
1. As the default behavior, the inter-MAG tunnel uses the same encapsulation mechanism as that for the PMIPv6 tunnel between the local mobility anchor and the MAGs. The PMAG and NMAG 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.
デフォルトの動作として1は、インターMAGトンネルは、ローカル・モビリティ・アンカーとのMAGとの間のPMIPv6トンネルと同様のカプセル化メカニズムを使用します。 PMAGとNMAGは自動的のMAGに特別な設定や、それらの間の動的なトンネリングメカニズムの交渉を必要とせずに同じカプセル化メカニズムを使用して開始します。
2. Configuration on the MAGs can override the default mechanism specified in scenario #1 above. The PMAG and NMAG 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 on to the configured inter-MAG tunnel, this scenario is not applicable, and scenario #3 below SHOULD directly be applied.
MAG 2.上記の設定は、シナリオ＃1で指定したデフォルトのメカニズムを無効にすることができます。 PMAGとNMAGは同じメカニズムで構成されなければならないが、この構成では、PMIPv6ドメインにわたって均一である可能性が最も高いです。 PMIPv6トンネルにパケットを一意に構成されたインターMAGトンネルへマッピングすることができない場合、このシナリオは適用されない、シナリオ＃3は、以下に直接適用されるべきです。
3. An implicit or explicit tunnel negotiation mechanism between the MAGs can override the default mechanism specified in scenario #1 above. The employed tunnel negotiation mechanism is outside the scope of this document.
3のMAGとの間の暗黙的または明示的なトンネルネゴシエーション機構は、シナリオ＃1上で指定されたデフォルトの機構をオーバーライドすることができます。使用トンネルネゴシエーション機構は、この文書の範囲外です。
The necessary information MUST be transferred in the HI/HAck messages
to determine whether a mobile node's packets should be forwarded
immediately or at a later time. Such information includes the HNP(s)
(or IPv4-MN-HoA) and/or GRE key(s). In the case of GRE tunneling
with GRE keys being used, for each mobility session, the NMAG selects
the GRE key for the downlink packets, and the PMAG selects the GRE
key for the uplink packets. These GRE keys are exchanged between the
PMAG and the NMAG using the GRE Key option as described in [RFC5845];
e.g., in the case of the reactive mode as shown in Figure 3, the DL
GRE key is communicated in the HI message while the UL GRE key is
sent in the HAck message. In the case of downlink packets, the PMAG
redirects the mobile node's packets from the local mobility anchor
towards the NMAG, and if the mobile node is ready to receive those packets or the N-AN can handle them regardless of the state of the
mobile node, the NMAG SHOULD immediately send them towards the N-AN;
otherwise, it SHOULD buffer them until the mobile node is ready. In
the case of uplink packets, the NMAG SHOULD reverse-tunnel them from
the mobile node towards the PMAG, and the PMAG will then send them to
the local mobility anchor.
When the PMAG or NMAG receives the HI message with the 'U' flag set, it prepares to buffer the mobile node's packets and returns the HAck message with the same sequence number. It MUST be followed by another HI message with the 'F' flag set at an appropriate time to forward the buffered packets.
PMAGまたはNMAGは「U」フラグが設定されたHIメッセージを受信すると、移動ノードのパケットをバッファリングするための準備と同じシーケンス番号とハックメッセージを返します。これは、バッファされたパケットを転送するために適切な時間に設定「F」フラグを別のHIメッセージが続かなければなりません。
If the MAG that received the HI message encounters an erroneous situation (e.g., insufficient buffer space), it SHOULD immediately send the HAck message with the cause of the error and cancel all tunneling operations.
HIメッセージを受信したMAGが誤っ状況（例えば、不十分なバッファスペース）を検出した場合、それはすぐにエラーの原因とハックメッセージを送信し、すべてのトンネリング操作を取り消すべきです。
The motivation and usage scenarios of IPv4 protocol support by PMIPv6 are described in [RFC5844]. The scope of IPv4 support covers the following two features:
PMIPv6によってIPv4プロトコルサポートの動機および使用シナリオは、[RFC5844]に記載されています。 IPv4サポートの範囲は、次の2つの機能について説明します。
o IPv4 Home Address Mobility Support, and
IPv4のホームOモビリティサポートアドレス、および
o IPv4 Transport Support.
IPv4の輸送支援O。
As for IPv4 Home Address Mobility Support, the mobile node acquires the IPv4 Home Address (IPv4-MN-HoA), and in the case of handover, the PMAG needs to transfer IPv4-MN-HoA to the NMAG, which is the inner destination address of the packets forwarded on the downlink. For this purpose, the IPv4 Address option described in Section 6.2.7 is used. In order to provide IPv4 Transport Support, the NMAG needs to know the IPv4 address of the local mobility anchor (IPv4-LMAA) to send PMIPv6 signaling messages to the local mobility anchor in the IPv4 transport network. For this purpose, a new option called the LMA Address (LMAA) option is defined in Section 6.2.2 so as to convey IPv4-LMAA from the PMAG to the NMAG.
IPv4のホームアドレスモビリティサポートのように、モバイルノードは、IPv4ホームアドレス（IPv4-MN-のHoA）を取得し、ハンドオーバの場合には、PMAGは、内側宛先であるNMAG、へのIPv4-MN-のHoAを転送する必要がありますダウンリンク上で転送されたパケットのアドレス。このためには、6.2.7項で説明したIPv4アドレスのオプションが使用されています。 IPv4の交通のサポートを提供するために、NMAGは、IPv4トランスポートネットワーク内のローカル・モビリティ・アンカーへのPMIPv6シグナリングメッセージを送信するためにローカル・モビリティ・アンカー（IPv4の-LMAA）のIPv4アドレスを知っている必要があります。この目的のために、新しいオプションがそうNMAGにPMAGからのIPv4-LMAAを伝えるように（LMAA）オプションは、セクション6.2.2で定義されているLMAアドレスと呼ばれます。
This specification does not require any additional IP-level functionality on the local mobility anchor and the mobile node running in the PMIPv6 domain. A typical network interface that the mobile node could be assumed to have is one with the cellular network, where the network controls the movement of the mobile node. Different types of interfaces could be involved, such as different generations (3G and 3.9G) or different radio access systems. This specification supports a mobile node with the single radio mode, where only one interface is active at any given time. The assigned IP address is preserved whether the physical interface changes or not, and the mobile node can identify which interface should be used if there are multiple ones.
この仕様は、ローカル・モビリティ・アンカーとPMIPv6ドメインで実行しているモバイルノード上の任意の追加のIPレベルの機能を必要としません。移動ノードが持っていると仮定することができる代表的なネットワークインターフェースは、ネットワークが、移動ノードの移動を制御するセルラーネットワーク、を有するものです。インターフェイスの異なるタイプは、異なる世代（3Gおよび3.9G）または異なる無線アクセスシステムとして、関与し得ます。この仕様は、唯一のインタフェースが任意の時点でアクティブである単一無線モードを有する移動ノードをサポートします。割り当てられたIPアドレスは、物理インターフェイスの変更か否かの保存され、モバイルノードは、複数のものが存在する場合に使用すべきインタフェースを識別することができます。
The protocol specified in this document enables the NMAG to obtain parameters that would otherwise be available only by communicating with the local mobility anchor. For instance, the HNP(s) and/or IPv4-MN-HoA of a mobile node are made available to the NMAG through context transfer. This allows the NMAG to perform some procedures that may be beneficial. The NMAG, for example, SHOULD send a Router Advertisement (RA) with prefix information to the mobile node as soon as its link attachment is detected (e.g., via receipt of a Router Solicitation message). Such an RA is recommended, for example, in scenarios where the mobile node uses a new radio interface while attaching to the NMAG; since the mobile node does not have information regarding the new interface, it will not be able to immediately send packets without first receiving an RA with HNP(s). Especially in the reactive fast handover, the NMAG gets to know the HNP(s) assigned to the mobile node on the previous link at step (d) in Figure 3. In order to reduce the communication disruption time, the NMAG SHOULD expect the mobile node to keep using the same HNP and to send uplink packets before that step upon the mobile node's request. However, if the HAck message from the PMAG returns a different HNP or the subsequent PMIPv6 binding registration for the HNP fails for some reason, then the NMAG MUST withdraw the advertised HNP by sending another RA with zero prefix lifetime for the HNP in question. This operation is the same as that described in Section 6.12 of [RFC5213].
本書で指定されたプロトコルは、そうでなければ、ローカル・モビリティ・アンカーと通信することによって利用可能となるパラメータを取得するためにNMAGを可能にします。例えば、HNP（S）および/またはモバイルノードのIPv4の-MN-HoAがコンテキスト転送を介しNMAGに利用可能にされます。これはNMAGが有益であり得るいくつかの手順を実行することを可能にします。そのリンクアタッチメントを（たとえば、ルータ要請メッセージの受信を介して）検出されるNMAGは、例えば、できるだけ早くモバイルノードにプレフィックス情報をルータ広告（RA）を送信すべきです。そのようなRAはNMAGに付着しながら移動ノードが新しい無線インタフェースを使用するシナリオでは、例えば、推奨されます。モバイルノードは、新しいインタフェースに関する情報を持っていないので、直ちに最初のHNP（S）とのRAを受信せずにパケットを送信することができません。特に反応高速ハンドオーバにおいて、NMAG通信中断時間を短縮するために、図3のステップ（d）に前のリンク上のモバイルノードに割り当てられたHNP（単数または複数）を知ることを得る、NMAGは、移動を期待するべきです同じHNPを使用して維持するために、モバイルノードの要求に応じて、そのステップの前にアップリンク・パケットを送信するノード。 PMAGからハックメッセージが異なるHNPを返すか、HNPに対する後続のPMIPv6バインディング登録が何らかの理由で失敗した場合は、その後、NMAGは、問題のHNPゼロプレフィックス寿命を持つ別のRAを送信することにより、広告を出してHNPを撤回しなければなりません。この操作は、[RFC5213]のセクション6.12に記載したものと同じです。
The protocol specified in this document is applicable regardless of whether link-layer addresses are used between a mobile node and its MAG. A mobile node should be able to continue sending packets on the uplink even when it changes link. When link-layer addresses are used, the mobile node performs Neighbor Unreachability Detection (NUD) [RFC4861], after attaching to a new link, probing the reachability of its default router. The new router should respond to the NUD probe, providing its link-layer address in the solicited Neighbor Advertisement, which is common in the PMIPv6 domain. Implementations should allow the mobile node to continue to send uplink packets while it is performing NUD.
本書で指定されたプロトコルに関係なく、リンク層アドレスは、移動ノードとMAGとの間で使用されているかどうかに適用可能です。モバイルノードは、リンクを変更しても、アップリンク上でパケットを送信し続けることができるはずです。リンク層アドレスが使用される場合、モバイルノードは、そのデフォルトルータの到達可能性をプロービング、新しいリンクに取り付けた後、近隣到達不能検出（NUD）[RFC4861]を実行します。新しいルータは、PMIPv6ドメインでは一般的です募集近隣広告、でそのリンク層アドレスを提供し、NUDプローブに応答する必要があります。実装は、モバイルノードがNUDを実行している間、アップリンクパケットを送信し続けることを可能にすべきです。
This document defines new Mobility Header messages for the extended HI and HAck, and new mobility options for conveying context information.
この文書では、コンテキスト情報を搬送するための拡張HIとハックと新しいモビリティオプションのための新しいモビリティヘッダのメッセージを定義します。
This section defines extensions to the HI message in [RFC5568]. The format of the Message Data field in the Mobility Header is as follows:
このセクションでは、[RFC5568]にHIメッセージへの拡張を定義します。次のように移動ヘッダのメッセージデータフィールドの形式は次のとおりです。
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 # |
+-+-+-+-+-------+---------------+-------------------------------+
|S|U|P|F|Resv'd | Code | |
+-+-+-+-+-------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
(Note: P=1)
IP Fields:
IPフィールド：
Source Address
送信元アドレス
The IP address of the PMAG or NMAG
PMAGまたはNMAGのIPアドレス
Destination Address
宛先アドレス
The IP address of the peer MAG
ピアMAGのIPアドレス
Message Data:
メッセージデータ：
Sequence # Same as [RFC5568].
[RFC5568]と同じ配列番号。
'S' flag Defined in [RFC5568], and MUST be set to zero in this specification.
「S」フラグは[RFC5568]で定義され、そして本明細書中でゼロに設定しなければなりません。
'U' flag Buffer flag. Same as [RFC5568].
「U」フラグバッファフラグ。 [RFC5568]と同じです。
'P' flag Proxy flag. Used to distinguish the message from that defined in [RFC5568], and MUST be set in all new message formats defined in this document when using this protocol extension.
「P」フラグプロキシフラグ。 [RFC5568]で定義されたものからのメッセージを区別するために使用され、このプロトコル拡張を使用する場合、この文書で定義されたすべての新しいメッセージの形式で設定しなければなりません。
'F' flag Forwarding flag. Used to request to forward the packets for the mobile node.
「F」フラグ転送フラグ。モバイルノードに対してパケットを転送するために要求するために使用されます。
Reserved Same as [RFC5568].
[RFC5568]と同じに予約されています。
Code [RFC5568] defines this field and its values, 0 and 1. In this specification, with the 'P' flag set, this field can be set to zero by default, or to the following values:
コード[RFC5568]は「P」フラグが設定され、このフィールドは、デフォルトでゼロに設定することができ、または次の値に、このフィールドおよびその値、本明細書では0と1を定義します。
2: Indicate the completion of forwarding
2：転送の完了を示します
3: All available context transferred
3：転送可能なすべてのコンテキスト
Code value 3 is set when the transfer of all necessary context information is completed with this message. This Code value is used both in cases where the context information is fragmented into several pieces and the last fragment is contained in this message, and where the whole information is transferred in one piece.
必要なすべてのコンテキスト情報の転送は、このメッセージで完了したときに、コード値3が設定されています。このコード値は、コンテキスト情報は、いくつかの断片に断片化され、最後のフラグメントは、このメッセージに含まれて、全体情報を一体的に転送される場合の両方で使用されています。
Mobility options:
モビリティオプション：
This field contains one or more mobility options, whose encoding and formats are defined in [RFC3775].
このフィールドは、その符号化及びフォーマット[RFC3775]で定義される1つ以上のモビリティオプションを含んでいます。
Required option
必要なオプション
In order to uniquely identify the target mobile node, the mobile node identifier MUST be contained in the Mobile Node Identifier option.
一意ターゲットモバイルノードを識別するために、モバイルノード識別子は、モバイルノード識別子オプションに含まれなければなりません。
The transferred context MUST be for one mobile node per message. In addition, the NMAG can request necessary mobility options via the Context Request option defined in this document.
転送コンテキストは、メッセージごとにモバイルノードのためでなければなりません。また、NMAGは、この文書で定義されたコンテキスト要求オプションを使用して、必要なモビリティオプションを要求することができます。
Context Request Option
コンテキスト要求オプション
This option MAY be present to request context information, typically by the NMAG to the PMAG in the NMAG-initiated fast handover.
このオプションは、通常NMAG-開始高速ハンドオーバにおけるPMAGにNMAGによって、コンテキスト情報を要求するために存在することができます。
This section defines extensions to the HAck message in [RFC5568]. The format of the Message Data field in the Mobility Header is as follows:
このセクションでは、[RFC5568]にハックメッセージへの拡張を定義します。次のように移動ヘッダのメッセージデータフィールドの形式は次のとおりです。
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|P|F|Reserved | Code | |
+-+-+-+---------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
(Note: P=1)
IP Fields:
IPフィールド：
Source Address
送信元アドレス
Copied from the destination address of the Handover Initiate message to which this message is a response.
ハンドオーバの宛先アドレスからコピーされ、このメッセージが応答されたメッセージを開始します。
Destination Address
宛先アドレス
Copied from the source address of the Handover Initiate message to which this message is a response.
ハンドオーバのソースアドレスからコピーされ、このメッセージが応答されたメッセージを開始します。
Message Data:
メッセージデータ：
The usages of Sequence # and Reserved fields are exactly the same as those in [RFC5568].
シーケンス＃と予約フィールドの用途は、[RFC5568]のものと全く同じです。
'U' flag Same as defined in Section 6.1.1.
同じ「U」フラグは、セクション6.1.1で定義されています。
'P' flag Same as defined in Section 6.1.1. Used to distinguish the message from that defined in [RFC5568], and MUST be set in all new message formats defined in this document when using this protocol extension.
セクション6.1.1で定義したものと同じ「P」フラグ。 [RFC5568]で定義されたものからのメッセージを区別するために使用され、このプロトコル拡張を使用する場合、この文書で定義されたすべての新しいメッセージの形式で設定しなければなりません。
'F' flag Same as defined in Section 6.1.1.
同じ「F」フラグは、セクション6.1.1で定義されています。
Code Code values 0 through 4 and 128 through 130 are defined in [RFC5568]. When the 'P' flag is set, the meaning of Code value 0 is as defined in this specification; 128 through 130 are reused; and 5, 6, 131, and 132 are newly defined.
コードのコードは、0〜4及び130を介して128 [RFC5568]で定義される値。 「P」フラグが設定されている場合、コード値0の意味は、本明細書で定義した通りです。 130スルー128は、再利用されます。 5、6、131、及び132は、新たに定義されています。
0: Handover Accepted or Successful
0：ハンドオーバ受け入れられるか、または成功しました
5: Context Transfer Accepted or Successful
5：コンテキスト転送受け入れられるか、または成功しました
6: All available Context Transferred
6：転送されるすべての可能なコンテキスト
128: Handover Not Accepted, reason unspecified
128：ハンドオーバ不可、不特定の理由
129: Administratively prohibited
129：管理上禁止
130: Insufficient resources
130：リソースが不足
131: Requested Context Not Available
131：要求されたコンテキストは使用できません
132: Forwarding Not Available
132：転送不可
Mobility options:
モビリティオプション：
This field contains one or more mobility options, whose encoding and formats are defined in [RFC3775]. The mobility option that uniquely identifies the target mobile node MUST be copied from the corresponding HI message, and the transferred context MUST be for one mobile node per message.
このフィールドは、その符号化及びフォーマット[RFC3775]で定義される1つ以上のモビリティオプションを含んでいます。一意ターゲットモバイルノードを識別するモビリティオプションは、対応するHIメッセージからコピーしなければなりません、そして転送コンテキストは、メッセージごとにモバイルノードのためでなければなりません。
Required option(s)
必要なオプション（S）
All the context information requested by the Context Request option in the HI message SHOULD be present in the HAck message. The other cases are described below.
HIメッセージにコンテキスト要求オプションによって要求されたすべてのコンテキスト情報はハックメッセージ中に存在すべきです。他の例は、以下に記載されています。
In the case of the PMAG-initiated fast handover, when the PMAG sends the HI message to the NMAG with the context information and the NMAG successfully receives it, the NMAG returns the HAck message with Code value 5. In the case of the NMAG-initiated fast handover, when the NMAG sends the HI message to the PMAG with or without the Context Request option, the PMAG returns the HAck message with the requested or default context information (if any). If all available context information is transferred, the PMAG sets the Code value in the HAck message to 6. If more context information is available, the PMAG sets the Code value in the HAck message to 5, and the NMAG MAY send new HI message(s) to retrieve the rest of the available context information. If none of the requested context information is available, the PMAG returns the HAck message with Code value 131 without any context information.
PMAGコンテキスト情報とNMAGにHIメッセージを送信し、NMAGが正常に受信した場合PMAG-開始高速ハンドオーバの場合には、NMAGはNMAG-の場合にコード値5とハックメッセージを返します高速ハンドオーバを開始し、NMAGは、コンテキスト要求オプションの有無にかかわらずPMAGにHIメッセージを送信するときに、PMAGは、要求された、またはデフォルトのコンテキスト情報（もしあれば）をハックメッセージを返します。利用可能なすべてのコンテキスト情報が転送されている場合は、PMAGは、より多くのコンテキスト情報が利用可能な場合、PMAGは5にハックメッセージ内のコード値を設定し、NMAGは（新しいHIメッセージを送るかもしれ6にハックメッセージ内のコード値を設定し、 sが）可能なコンテキスト情報の残りの部分を取得します。要求コンテキスト情報のいずれもが利用可能でない場合、PMAGは、どのようなコンテキスト情報なしでコード値131とハックメッセージを返します。
This option is sent in the HI message to request context information on the mobile node. If a default set of context information is defined and always sufficient, this option is not used. This option is more useful to retrieve additional or dynamically selected context information.
このオプションは、モバイルノードのコンテキスト情報を要求するためにHIメッセージで送信されます。コンテキスト情報のデフォルトセットが必ずしも十分に定義されている場合、このオプションは使用されません。このオプションは、追加または動的に選択されたコンテキスト情報を取得するために、より有用です。
The Context Request option is typically used for the reactive (NMAG-initiated) fast handover mode to retrieve the context information from the PMAG. When this option is included in the HI message, all the requested context information SHOULD be included in the HAck message in the corresponding mobility option(s) (e.g., HNP, LMAA, or MN LL-ID mobility options).
コンテキスト要求オプションは通常、PMAGからのコンテキスト情報を取得するために、反応性（NMAG-開始）高速ハンドオーバモードのために使用されています。このオプションは、HIメッセージに含まれている場合、すべての要求されたコンテキスト情報は、対応するモビリティオプション（複数可）（例えば、HNP、LMAA、又はMN LL-IDモビリティオプション）におけるハックメッセージに含まれるべきです。
The default context information to request is the Home Network Prefix option. If the Mobile Node link layer is available and used, the Mobile Node Link-layer Identifier option MUST also be requested.
要求に対するデフォルトのコンテキスト情報は、ホームネットワークプレフィックスオプションです。モバイルノードのリンクレイヤが使用可能と使用している場合、モバイルノードのリンクレイヤ識別子オプションも要求されなければなりません。
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
+---------------+---------------+---------------+---------------+
| Option-Type | Option-Length | Reserved |
+---------------+---------------+-------------------------------+
| Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 |
+---------------------------------------------------------------+
| Req-type-3 | Req-length-3 | Req-option-3 |
+---------------------------------------------------------------+
| ... |
Option-Type 40
オプション型40
Option-Length The length in octets of this option, not including the Option Type and Option Length fields.
オプション長オプションタイプとオプション長フィールドを含まない、このオプションのオクテットの長さ。
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約済みこのフィールドは未使用です。これは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Req-type-n The type value for the nth requested option.
REQ-型のn番目の要求されたオプションのタイプの値。
Req-length-n The length of the nth requested option, excluding the Req-type-n and Req-length-n fields.
REQ-長さN REQ型-NとREQ-長さNのフィールドを除いたn番目の要求されたオプションの長さ。
Req-option-n The optional data to uniquely identify the requested context for the nth requested option.
REQ-オプション-nは任意のデータを一意にn番目の要求されたオプションのために要求されたコンテキストを識別することができます。
In the case where there are only Req-type-n and Req-length-n fields, the value of Req-length-n is set to zero. If additional information besides Req-type-n is necessary to uniquely specify the requested context, such information follows after Req-length-n. For example, when the requested contexts start with the HNP option (type=22), the MN Link-layer ID option (type=25), and the Vendor-Specific option (type=19), the required option format looks as follows:
唯一の必須型-NとREQ-長さNのフィールドがある場合には、REQ-長さnの値はゼロに設定されています。 REQ-タイプ-Nに加えて、追加の情報を一意に要求されたコンテキストを指定する必要がある場合、そのような情報は、REQ-長さNの後に続きます。例えば、以下のように要求されたコンテキストがHNPオプションで開始する（タイプ= 22）、MNのリンク層IDオプション（タイプ= 25）、およびベンダー固有のオプション（タイプ= 19）は、必要なオプション形式が見えます：
| ... |
+---------------+---------------+---------------+---------------+
|Option-Type=CRO| Option-Length | Reserved |
+---------------+---------------+---------------+---------------+
| Req-type-n=22 | Req-length-n=0| Req-type-n=25 | Req-length-n=0|
+---------------+---------------+-------------------------------+
| Req-type-n=19 | Req-length-n=5| Vendor-ID |
+-------------------------------+---------------+---------------+
| Vendor-ID | Sub-Type | |
+-----------------------------------------------+ |
| ... |
Note: CRO = Context Request Option
注：CROは、コンテキスト要求オプションを=
The first two options can uniquely identify the requested contexts (i.e., the HNP and MN Link-layer ID) by the Req-type, so the Req-length is set to zero; however, the subsequent Vendor-Specific option further needs the Vendor-ID and Sub-Type to identify the requested context, so these parameters follow, and the Req-length is set to 5. Note that the exact values in the Vendor-ID and Sub-Type follow [RFC5094].
最初の2つのオプションが一意REQ-タイプにより要求コンテキスト（すなわち、HNPとMNのリンク層ID）を識別することができるので、REQ-長さはゼロに設定されます。しかし、さらに後続のベンダー固有オプションが要求されたコンテキストを識別するために、ベンダーID及びサブタイプを必要とするので、これらのパラメータは、次のとおりとREQ-長さは5ノートに設定されているベンダーIDの正確な値およびサブタイプは、[RFC5094]を実行します。
This option is used to transfer the Local Mobility Anchor IPv6 Address (LMAA) or its IPv4 Address (IPv4-LMAA) with which the mobile node is currently registered. The detailed definition of the LMAA is described in [RFC5213].
このオプションは、モバイルノードが現在登録されているローカル・モビリティ・アンカーIPv6アドレス（LMAA）またはそのIPv4アドレス（IPv4にLMAA）を転送するために使用されます。 LMAAの詳細な定義は、[RFC5213]に記載されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Mobility Anchor Address ... |
Option-Type 41
オプション型41
Option-Length 18 or 6
オプション長18又は6
Option-Code 0 Reserved
オプション・コード0予約
1 IPv6 address of the local mobility anchor (LMAA)
ローカル・モビリティ・アンカー（LMAA）の1つのIPv6アドレス
2 IPv4 address of the local mobility anchor (IPv4-LMAA)
ローカル・モビリティ・アンカーの2つのIPv4アドレス（IPv4-LMAA）
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約済みこのフィールドは未使用です。これは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Local Mobility Anchor Address
ローカルモビリティアンカー住所
If the Option-Code is 1, the LMA IPv6 address (LMAA)
is inserted. If the Option-Code is 2, the LMA IPv4
address (IPv4-LMA) is inserted.
6.2.3. Mobile Node Link-Local Address Interface Identifier (MN LLA-IID) Option
6.2.3. モバイルノードリンクローカルアドレスインタフェース識別子（MN-LLA IID）オプション
This option is used to transfer the interface identifier of the mobile node's IPv6 Link-local Address that is used in the P-AN. In deployments where the interface identifier is assigned by the network or is known to the network, this option is used to transfer this identifier from the PMAG to the NMAG.
このオプションは、P-ANに使用されているモバイルノードのIPv6リンクローカルアドレスのインタフェース識別子を転送するために使用されます。インターフェース識別子がネットワークによって割り当てられた、またはネットワークに知られている展開では、このオプションはNMAGにPMAGから識別子を転送するために使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option-Type 42
オプション型42
Option-Length 10
オプション長10
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約済みこのフィールドは未使用です。これは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Interface Identifier
インタフェース識別子
The Interface Identifier value used for the mobile
node's IPv6 Link-local address in the P-AN.
This option, as defined in [RFC5213], is used to transfer the home network prefix that is assigned to the mobile node in the P-AN.
このオプションは、[RFC5213]で定義されるように、P-ANにモバイルノードに割り当てられたホーム・ネットワーク・プレフィクスを転送するために使用されます。
This option, as defined in [RFC5213], is used to transfer the link-local address of the PMAG.
このオプションは、[RFC5213]で定義されるように、PMAGのリンクローカルアドレスを転送するために使用されます。
This option is used to transfer the GRE Key for the mobile node's data flow over the bidirectional tunnel between the PMAG and NMAG. The message format of this option follows that of the GRE Key option defined in [RFC5845]. The GRE Key value uniquely identifies each flow, and the sender of this option expects to receive packets of the flow from the peer AR with this value.
このオプションはPMAGとNMAG間の双方向トンネルを介し、移動ノードのデータフローのためのGREキーを転送するために使用されます。このオプションのメッセージフォーマットは、[RFC5845]で定義されたGREキーオプションのことに従います。 GREキー値は一意に各フローを識別し、このオプションの送信者はこの値を持つピアARからのフローのパケットを受信することを期待します。
As described in Section 4.3, if the mobile node runs in IPv4-only mode or dual-stack mode, it requires the IPv4 home address (IPv4-MN-HoA). This option is used to transfer the IPv4 home address if assigned on the previous link. The format of this option follows that of the IPv4 Home Address Request option defined in [RFC5844].
モバイルノードがIPv4専用モードまたはデュアルスタックモードで実行されている場合、4.3節で説明したように、それは、IPv4ホームアドレス（IPv4-MN-のHoA）が必要です。前のリンクに割り当てられている場合、このオプションは、IPv4のホームアドレスを転送するために使用されます。このオプションの形式は、[RFC5844]で定義されたIPv4アドレスのホーム・リクエスト・オプションのことを次の。
This option is used to transfer any other information defined in this document. The format and used values of this option follow those of the Vendor-Specific Mobility option defined in [RFC5094].
このオプションは、この文書で定義された他の情報を転送するために使用されます。このオプションのフォーマットと使用される値は、[RFC5094]で定義されたベンダー固有のモビリティオプションのものに従います。
Security issues for this document follow those for PMIPv6 [RFC5213] and FMIPv6 [RFC5568]. In PMIPv6, the MAG and local mobility anchor are assumed to share security associations. In FMIPv6, the access routers (i.e., the PMAG and NMAG in this document) are assumed to share security associations.
このドキュメントのためのセキュリティ問題は、PMIPv6の[RFC5213]とFMIPv6の[RFC5568]のものに従ってください。 PMIPv6のでは、MAGおよびローカル・モビリティ・アンカーは、セキュリティアソシエーションを共有することを想定しています。 FMIPv6とでは、アクセスルータ（この文書に記載されている、すなわち、PMAGとNMAG）がセキュリティアソシエーションを共有することが想定されます。
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages exchanged between the PMAG and NMAG MUST be protected using end-to-end security association(s) offering integrity and data origin authentication. The PMAG and the NMAG MUST implement IPsec [RFC4301] for protecting the HI and HAck messages. IPsec Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. Confidentiality protection SHOULD be used if sensitive context related to the mobile node is transferred.
ハンドオーバ（HI）開始し、ハンドオーバ肯定応答（HAck処理）メッセージはPMAGとNMAG間で交換は、整合性とデータ発信元認証を提供し、エンドツーエンドのセキュリティアソシエーション（複数可）を使用して保護されなければなりません。 PMAGとNMAGはHIと上記ハンドオフメッセージを保護するためにIPsec [RFC4301]を実装しなければなりません。 IPsecのカプセル化セキュリティペイロード（ESP）必須完全性保護とトランスポートモードでは、[RFC4303]はシグナリングメッセージを保護するために使用されるべきである（SHOULD）。モバイルノードに関連する感受性コンテキストが転送される場合に機密保護が使用されるべきです。
IPsec ESP [RFC4303] in tunnel mode SHOULD be used to protect the mobile node's packets at the time of forwarding if the link between the PMAG and NMAG exposes the mobile node's packets to more threats than if they had followed their normal routed path.
トンネルモードのIPsec ESP [RFC4303]はPMAGとNMAG間のリンクが、彼らは、通常のルーテッドパスをたどっていた場合よりも多くの脅威に移動ノードのパケットを公開する場合は、転送時にモバイルノードのパケットを保護するために使用されるべきです。
This document defines new flags and status codes in the HI and HAck messages, as well as three new mobility options. The Type values for these mobility options are assigned from the same numbering space as that allocated for the other mobility options defined in [RFC3775]. Those for the flags and status codes are assigned from the corresponding numbering space defined in [RFC5568], and have been created as new tables in the IANA registry (marked with asterisks). New values for these registries can be allocated by Standards Action or IESG approval [RFC5226].
この文書は、新しいフラグとHI及びHAck処理メッセージにステータスコードだけでなく、3つの新しいモビリティ・オプションを定義します。これらの移動性オプションのタイプ値は[RFC3775]で定義された他のモビリティオプションのために割り当てられたものと同じ番号空間から割り当てられます。フラグとステータスコードについてのものは[RFC5568]で定義された対応するナンバリング空間から割り当てられ、（アスタリスク印）IANAレジストリに新しいテーブルとして作成されています。これらのレジストリのための新しい値は、標準アクションまたはIESGの承認[RFC5226]で割り当てることができます。
Mobility Options
Value Description Reference
----- ------------------------------------- -------------
40 Context Request Option Section 6.2.1
41 Local Mobility Anchor Address Option Section 6.2.2
42 Mobile Node Link-local Address
Interface Identifier Option Section 6.2.3
Handover Initiate Flags (*)
Registration Procedures: Standards Action or IESG Approval
Flag Value Description Reference
---- ----- ----------------------------------- -------------
S 0x80 Assigned Address Configuration flag [RFC5568]
U 0x40 Buffer flag [RFC5568]
P 0x20 Proxy flag Section 6.1.1
F 0x10 Forwarding flag Section 6.1.1
Handover Acknowledge Flags (*)
Registration Procedures: Standards Action or IESG Approval
Flag Value Description Reference
---- ----- ------------------------------- -------------
U 0x80 Buffer flag Section 6.1.2
P 0x40 Proxy flag Section 6.1.2
F 0x20 Forwarding flag Section 6.1.2
Handover Initiate Status Codes (*)
Registration Procedures: Standards Action or IESG Approval
Code Description Reference
---- -------------------------------------- -------------
0 FBU with the PCoA as source IP address [RFC5568]
1 FBU whose source IP address is not PCoA [RFC5568]
2 Indicate the completion of forwarding Section 6.1.1
3 All available context transferred Section 6.1.1
4-255 Unassigned
Handover Acknowledge Status Codes (*)
Registration Procedures: Standards Action or IESG Approval
Code Description Reference
---- --------------------------------------- -------------
0 Handover Accepted or Successful
(when 'P' flag is set) Section 6.1.2
Handover Accepted with NCoA valid [RFC5568]
1 Handover Accepted, NCoA not valid [RFC5568]
2 Handover Accepted, NCoA assigned [RFC5568]
3 Handover Accepted, use PCoA [RFC5568]
4 Message sent unsolicited [RFC5568]
5 Context Transfer Accepted or Successful Section 6.1.2
6 All available Context Transferred Section 6.1.2
7-127 Unassigned
128 Handover Not Accepted, reason unspecified [RFC5568]
129 Administratively prohibited [RFC5568]
130 Insufficient resources [RFC5568]
131 Requested Context Not Available Section 6.1.2
132 Forwarding Not Available Section 6.1.2
133-255 Unassigned
The authors would like to specially thank Vijay Devarapalli and Sri Gundavelli for their thorough reviews of this document.
作者は特別に、このドキュメントの彼らの徹底的なレビューのためのビジェイDevarapalliとスリGundavelliに感謝したいと思います。
The authors would also like to thank Charlie Perkins, Desire Oulai, Ahmad Muhanna, Giaretta Gerardo, Domagoj Premec, Marco Liebsch, Fan Zhao, Julien Laganier, and Pierrick Seite for their passionate discussions in the MIPSHOP working group mailing list.
著者らはまた、MIPSHOPワーキンググループのメーリングリストでの情熱的な議論のためにOulai、アフマドMuhanna、Giarettaヘラルド、Domagoj Premec、マルコLiebsch、ファン趙、ジュリアンLaganier、とPierrick Seite欲望、チャーリーパーキンスに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 Vendor Specific Option", RFC 5094, December 2007.
[Ramphsi 5094] devarapalli、VEの。、パテル、B。、ゴール。 Leunji、 "モバイルベンダー固有のオプション20 6"、rphak 5094、2007年12月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Ramphsi 5213] gundavelli、S。、Leunjiは、K.、Devarapalliは、VEの。、Chaudhuriの、K.、aとb。パティル、 "プロキシモバイル20 6"、rphak 5213、2008年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568] Koodli、R.、 "モバイルIPv6高速ハンドオーバ"、RFC 5568、2009年7月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844] Wakikawa、R.およびS. Gundavelli、 "プロキシモバイル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.、カリル、M.、Gundavelli、S.、およびK.レオン、 "プロキシモバイルIPv6の総称ルーティングカプセル化（GRE）キーオプション"、RFC 5845、2010年6月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", RFC 4988, October 2007.
[RFC4988] Koodli、R.とC.パーキンス、 "モバイルIPv4高速ハンドオーバ"、RFC 4988、2007年10月。
Appendix A. Applicable Use Cases
付録A.適用ユースケース
A.1. PMIPv6 Handoff Indication
A.1。 PMIPv6のハンドオフ表示
PMIPv6 [RFC5213] defines the Handoff Indicator option and also describes the type of handoff and values that can be set for this option. This document proposes one approach to determining the handoff type by the NMAG when the handoff of the mobile node is executed.
PMIPv6 [RFC5213]はハンドオフインジケータオプションを定義し、また、このオプションを設定することができ、ハンドオフと値のタイプを記述する。この文書では、モバイルノードのハンドオフが実行されたときNMAGによってハンドオフ・タイプを決定する一の手法を提案しています。
According to [RFC5213], the following handoff types are defined:
[RFC5213]によれば、次のハンドオフのタイプが定義されています。
0) Reserved
0）予約
1) Attachment over a new interface
新しいインタフェースを介して1）アタッチメント
2) Handoff between two different interfaces of the mobile node
モバイルノードの二つの異なるインターフェース間の2）ハンドオフ
3) Handoff between mobile access gateways for the same interface
同じインターフェイスのためのモバイルアクセスゲートウェイの間3）ハンドオフ
4) Handoff state unknown
4）ハンドオフ状態不明
5) Handoff state not changed (Re-registration)
5）ハンドオフ状態が変化していない（再登録）
Assuming that there is a valid MN Link-layer Identifier (MN LL-ID), the following solution can be considered. When the NMAG receives the MN LL-ID from the PMAG in the MN LL-ID option via the HI or HAck message, the NMAG compares it with the new MN LL-ID that is obtained from the mobile node in the N-AN. If these two MN LL-IDs are the same, the handoff type falls into type 3 (defined above) and the Handoff Indicator value is set to 3. If these two MN LL-IDs are different, the handoff is likely to be type 2 (defined above) since the HI/HAck message exchange implies that this is a handoff rather than a multihoming, and therefore the Handoff Indicator value can be set to 2. If there is no HI/HAck exchange performed prior to the network attachment of the mobile node in the N-AN, the NMAG may infer that this is a multi-homing case and set the Handoff Indicator value to 1. In the case of re-registration, the MAG, to which the mobile node is attached, can determine if the handoff state is not changed, so the MAG can set the HI value to 5 without any additional information. If no handoff type can be assumed or if there is no valid MN LL-ID available, the NMAG may set the value to 4.
有効なMNのリンク層識別子（MNのLL-ID）が存在すると仮定すると、以下の解決策を考えることができます。 NMAGはHIまたは上記ハンドオフメッセージを介してMN LL-IDオプションでPMAGからMN LL-IDを受信すると、NMAGはN-ANにモバイルノードから得られる新しいMNのLL-IDと比較します。これら二つのMNのLL-IDが同じである場合、ハンドオフ・タイプは、タイプ3（上記で定義した）に該当し、ハンドオフ指標値は、これら2つのMNのLL-IDが異なる場合、ハンドオフは2型である可能性がある3に設定されています（上記で定義）HI /ハックメッセージ交換は、これは、ハンドオフなくマルチホーミングであることを意味し、いかなるHI /ハック交換前のネットワーク接続を行うがない場合したがって、ハンドオフ指示値が2に設定することができるのでN-ANにモバイルノード、NMAGこれはマルチホーミングケースであることを推測し、再登録の場合には1にハンドオフ指標値を設定することができる、モバイルノードが接続されているMAGは、決定することができますハンドオフ状態が変更されていない場合、MAGは、追加情報なしで5 HI値を設定できるように。ハンドオフ・タイプを想定することができない、または利用可能な有効なMN LL-IDが存在しない場合、NMAG 4に値を設定することができる場合。
A.2. Local Routing
A.2。ローカルルーティング
As described in Section 6.10.3 of [RFC5213], if the EnableMAGLocalRouting flag is set, when two mobile nodes are attached to one MAG, the traffic between them may be locally routed. If one mobile node moves from this MAG (PMAG) to another MAG (NMAG) and if the PMAG does not detect the mobile node's detachment, it will continue to forward packets locally forever. This situation is more likely to happen in the reactive fast handover with Wireless Local Area Network (WLAN) access, which does not have the capability to detect the detachment of the mobile node in a timely manner. This specification can be applied to handle this case. When the mobile node attaches to the NMAG, the NMAG sends the HI message to the PMAG with the 'F' flag set, which makes the PMAG realize the detachment of the mobile node and establish the inter-MAG tunnel. The PMAG immediately stops the local routing and sends the packets for the mobile node to the NMAG via that tunnel; the packets are then delivered to the mobile node on the new link.
[RFC5213]のセクション6.10.3に記載されているようのEnableMAGLocalRoutingフラグが設定されている場合、2つのモバイルノードは、1つのMAGに接続されている場合、それらの間のトラフィックは、ローカルにルーティングすることができます。一つの移動ノードは、別のMAG（NMAG）にこのMAG（PMAG）から移動しPMAGは、モバイルノードの離脱を検出しない場合、それはローカルに永遠にパケットを転送し続ける場合。この状況は、タイムリーに、移動ノードの離脱を検出する能力を持っていないワイヤレスローカルエリアネットワーク（WLAN）アクセス、と反応性高速ハンドオーバで発生する可能性が高いです。この仕様は、このケースを処理するために適用することができます。モバイルノードがNMAGにアタッチするとき、NMAGはPMAGは、モバイルノードの分離を実現し、インターMAGトンネルを確立することができる「F」フラグセットとPMAGにHIメッセージを送信します。 PMAGは直ちにローカルルーティングを停止し、そのトンネルを介しNMAGにモバイルノードのためのパケットを送信します。パケットは、新しいリンク上のモバイルノードに配信されます。
Authors' Addresses
著者のアドレス
Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama 356-8502 Japan
ひでとし よこた Ｋっぢ ぁｂ ２ー１ー１５ おはら、 ふじみの さいたま ３５６ー８５０２ じゃぱん
EMail: yokota@kddilabs.jp
メールアドレス：yokota@kddilabs.jp
Kuntal Chowdhury Cisco Systems 30 International Place Tewksbury, MA 01876 USA
Kuntalチョードリーシスコシステムズ30・インターナショナル・プレイステュークスベリー、MA 01876 USA
EMail: kchowdhu@cisco.com
メールアドレス：kchowdhu@cisco.com
Rajeev Koodli Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
ラジーブKoodliシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134 USA
EMail: rkoodli@cisco.com
メールアドレス：rkoodli@cisco.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
Basavarajパティルノキア6000接続のドライブアーヴィング、TX 75039 USA
EMail: basavaraj.patil@nokia.com
メールアドレス：basavaraj.patil@nokia.com
Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA
フランク・ξああUA USA 1700アルマ博士スイート500プラノ、TX 75075 USAについて
EMail: xiayangsong@huawei.com
メールアドレス：xiayangsong@huawei.com