[要約] RFC 5949は、プロキシモバイルIPv6における高速ハンドオーバーに関する要件と手法を提供しています。その目的は、モバイルデバイスが異なるアクセスポイント間でスムーズに切り替えるための効率的な手段を提供することです。
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
プロキシモバイル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（FMIPV6; RFC 5568）の高速ハンドオーバーの使用を指定します。モバイルノードに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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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のハンドオーバーレイテンシを減らすプロトコルを説明しています。そのアタッチメントは、新しいアクセスルーターによって検出されます。このドキュメントは、プロキシMIPV6操作のFMIPv6を拡張して、ハンドオーバー遅延とパケットの損失を最小限に抑え、PMIPv6ハンドオーバーのネットワーク居住コンテキストを転送します。[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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
Access Network（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.
New Access Network（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とAccessルーターが共同配置されています。
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とAccessルーター（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.
ハンドオーバーの表示：P-ANからPMAGに送信される一般的なシグナル伝達メッセージは、モバイルノードのハンドオーバーを示しています。このシグナリングはアクセステクノロジーに依存していますが、ハンドオーバー指標は、モバイルノードを識別し、モバイルノードがある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は、アクセスリンクとの間のモバイルノードの動きを検出し、モバイルノードのローカルモビリティアンカーへのバインディング登録を開始する責任があります。Magsが、低レイヤーシグナル伝達を介してタイムリーにモバイルノードの分離および/または付着を通知できる場合、新しいリンクで接続を確立することを伴うハンドオーバー手順を最適化することが可能になります。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）の間の双方向トンネルを指定します。NMAGがプロキシバインディングアップデート（PBU）を送信できるようにするために、[RFC5568]のハンドオーバー開始（HI）およびハンドオーバー（HACK）メッセージは、モバイルノードのネットワークアクセス識別子などのパラメーターをコンテキスト転送するために拡張されます。（NAI）、ホームネットワークプレフィックス（HNP）、およびIPv4ホームアドレスはPMAGから転送されます。新しいフラグ「P」と「F」は、HIおよびハックメッセージに対して定義され、[RFC5568]のものと区別し、パケット転送を要求します。
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と交換可能です。参照ネットワークを図1に示します。図のアクセスネットワーク（すなわち、P-ANおよびN-AN）は、[RFC5568]で定義されたアクセスポイント（AP）で構成されています。ネットワーク。
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モビリティプロトコル操作に直接関与していないため、モバイルノードも高速ハンドオーバー手順に直接関与していません。したがって、[RFC5568]のモバイルノードを含むメッセージは、PMIPv6が使用されている場合は使用されません。より具体的には、プロキシ広告（RTSOLPR）のルーター勧誘（RTSOLPR）、プロキシルーター広告（PRRTADV）、高速バインディングアップデート（FBU）、高速バインディング承認（FBAC）、および未承諾の近隣広告（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でモバイルノードのダウンリンクパケットをバッファリングする必要があります。実行されました。したがって、すべての雑誌には、それらが収容するモバイルノードのパケットをバッファリングする機能と十分なリソースが必要です。調製するバッファサイズとバッファーパケットが排出される速度は、[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
UL Uplink DLダウンリンクPBAプロキシバインディング承認
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はAccess固有の識別子を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から新しいモバイルアクセスゲートウェイ（NMAG）を導き出します。これは、[RFC5568]で[AP ID、AR-INFO]タプルを構築するプロセスと同様のプロセスです。以前の雑誌は、新しい雑誌にハンドオーバーイニシエイト（ハイ）メッセージを送信します。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) 新しい雑誌は、「P」フラグセットを使用して、ハンドオーバー（ハック）メッセージを以前の雑誌に送り返します。
(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.
(e) バッファリングまたは転送のタイミングがステップ（c）よりも遅くなることが推奨される場合、新しいMAGは、「u」フラグ[RFC5568を設定して、以前のMAGバッファーまたはフォワードパケットを遅くかつ適切な時期に要求することができます。]または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の間の接続がすでに確立されている場合、それらのパケットは新しいアクセスネットワークに転送され、それがそれらの責任を負う可能性があります（たとえば、モバイルノードの添付ファイルの条件に応じて、バッファリングまたは配信）;これはアクセステクノロジー固有です。
(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が新しいアクセスネットワークを介して有効な新しいMN LL-IDを取得し、ステップ（C）の前のMAGから有効な古いMN LL-IDを介して取得した場合、これらのIDを比較して、同じインターフェイスが前に使用されるかどうかを判断する必要があります。ハンドオーバー後。モバイルノードと新しいMAGとの接続がPPPであり、同じインターフェイスがハンドオーバーに使用される場合、新しいMAGはモバイルノードのリンクローカルアドレスに同じインターフェイス識別子が使用されていることを確認する必要があります（これは前のMAGから転送されますステップ（C）でMN LLA-IIDオプションを使用し、Configure-Request/ACK Exchange中にモバイルノードに送信されます）。
(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) ローカルモビリティアンカーは、プロキシバインディング確認（PBA）を新しい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）の間に結合を確立します。モバイルノードが到着する前に、NCOA用のこれらのパケットを受信するプロキシネイバーキャッシュエントリを作成します。ただし、PMIPv6の場合、モバイルノードで使用されるアドレスはモバイルノードのホームアドレス（MN-HOA）のみであるため、PMAGはモバイルノードのパケットをNCOAの代わりにNMAGに転送します。NMAGは、これらのパケットを単純に脱カプセル化し、モバイルノードに配信します。FMIPV4 [RFC4988]は、モバイルノードがホームアドレスをケアオブアドレスではなく、オンリンクアドレスとして使用するときに転送を指定します。PMIPv6の使用法は、モバイルノードで使用されるアドレス（ES）がHNPに基づいているFMIPv4の使用法と類似しています。NMAGは、HIメッセージ（モバイルノードのLink-Localアドレス（MN LLA-ID）のインターフェイス識別子（MN LLA-ID）を介してLink-Layerアドレス（MN LL-ID）とHNPを取得できるため、利用可能な場合は）モバイルノードが近隣の発見を実行する前であっても、Link-LocalアドレスとHNP全体のルートのネイバーキャッシュエントリを作成できます。ステップ（j）のハンドオーバー後のモバイルノードからのアップリンクパケットの場合、NMAGはステップ（F）に確立されたトンネルを介してPMAGにパケットを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およびハックメッセージの新しいフラグ「F」とオプションコード値は、転送を要求するように定義されます。バッファリングを要求するために、[u]フラグは[RFC5568]ですでに定義されています。PMAGが「F」フラグセットでHIメッセージを受信した場合、モバイルノードのパケットの転送を開始します。バッファリングのタイミングが転送のタイミングとは異なる場合、「u」フラグセットを使用したHIメッセージは、以前に送信される場合があります。パケット転送が完了した場合、PMAGは「F」フラグセットと2に設定されたオプションコード値を使用してHIメッセージを送信できます。このメッセージを介して、両端のARSは転送トンネルを同期して取り壊すことができます。
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,
- nmagから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 NMAG
外側のソースアドレス：NMAGのIPアドレス
Outer destination address: IP address of the PMAG
外側の宛先アドレス：PMAGのIPアドレス
- from the PMAG to the LMA,
- PMAGからLMAへ、
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.
PMIPv6のリアクティブハンドオーバーの場合、モバイルノードはFBUまたはUNAのいずれかを送信しないため、モバイルノードが新しいリンクに移動した後、NMAGがPMAGにHIメッセージを送信することがより自然になります。NMAGは、事前にPMAGの情報を取得する必要があります。このような情報は、たとえば、古いリンクでAP-IDを送信するモバイルノード、および/またはP-ANとN-ANの間の低層手順によって提供される可能性があります。正確な方法は、このドキュメントでは指定されていません。図3は、PMIPv6の反応性高速ハンドオーバー手順を示しています。ここでは、双方向トンネルの確立がNMAGによって開始されます。
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) 新しい雑誌は、ハイメッセージを以前の雑誌に送ります。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) 以前の雑誌は、「P」フラグセットでハックメッセージを新しいMagに送り返します。ハックメッセージには、HIメッセージのMN IDに対応するHNP（S）および/またはIPv4-MN-HOAを含める必要があります。現在、モバイルノードを提供しているローカルモビリティアンカーアドレス。新しい雑誌が要求するコンテキスト情報を含める必要があります。要求されたコンテキストが何らかの理由で利用できない場合、前の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.
(e) HIメッセージの「F」フラグがステップ（c）に設定されている場合、以前の雑誌と新しい雑誌の間に双方向トンネルが確立され、モバイルノードに向けたパケットが前の雑誌から新しい雑誌に転送されます。トンネル。脱カプセル化後、これらのパケットは新しいアクセスネットワークを介してモバイルノードに配信されます。
(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） - （h）は、予測高速ハンドオーバー手順のステップ（k） - （l）と同じです。
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アドレスをNMAGによって解決して、PMAGにHIメッセージを送信する必要があります。この情報は、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の間のトンネルに対しても定義されているユーザーパケットの次のカプセル化モードをサポートする必要があります。
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-Header UDPトンネル[RFC5845]
o Generic Routing Encapsulation (GRE) tunneling with or without GRE key(s) [RFC5845]
o GREキーの有無にかかわらず、一般的なルーティングカプセル化（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間トンネルは、ローカルモビリティアンカーとMAGSの間のPMIPV6トンネルのカプセル化メカニズムと同じカプセル化メカニズムを使用します。PMAGとNMAGは、雑誌上の特別な構成やそれらの間の動的なトンネルメカニズムの交渉を必要とせずに、同じカプセル化メカニズムの使用を自動的に開始します。
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.
2. MAGSの構成は、上記のシナリオ＃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. 雑誌間の暗黙的または明示的なトンネル交渉メカニズムは、上記のシナリオ＃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.
必要な情報は、Hi/Hackメッセージで転送され、モバイルノードのパケットをすぐに転送するか、後で転送するかを判断する必要があります。このような情報には、HNP（またはIPV4-MN-HOA）および/またはGREキーが含まれます。GREキーが使用されているGREトンネルの場合、各モビリティセッションで、NMAGはダウンリンクパケットのGREキーを選択し、PMAGはアップリンクパケットのGREキーを選択します。これらのGREキーは、[RFC5845]で説明されているように、GREキーオプションを使用してPMAGとNMAGの間で交換されます。たとえば、図3に示すように反応モードの場合、DL GREキーはHIメッセージで通信され、UL GREキーがハックメッセージに送信されます。ダウンリンクパケットの場合、PMAGはローカルモビリティアンカーからNMAGに向かってモバイルノードのパケットをリダイレクトし、モバイルノードがそれらのパケットを受信する準備ができている場合、またはN-ANがモバイルノードの状態に関係なくそれらを処理できる場合、nmagはすぐにそれらをn-anに送る必要があります。それ以外の場合は、モバイルノードの準備ができるまでバッファリングする必要があります。アップリンクパケットの場合、NMAGはモバイルノードからPMAGに向かってそれらを逆転させる必要があり、PMAGはそれらをローカルモビリティアンカーに送信します。
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メッセージを受け取った雑誌が誤った状況に遭遇する場合（例：バッファスペースが不十分）、すぐにエラーの原因でハックメッセージを送信し、すべてのトンネル操作をキャンセルする必要があります。
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
o IPv4ホームアドレスモビリティサポート、および
o IPv4 Transport Support.
o IPv4輸送サポート。
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はIPv4-MN-HOAをNMAGに転送する必要があります。ダウンリンクに転送されるパケットのアドレス。この目的のために、セクション6.2.7で説明したIPv4アドレスオプションが使用されます。IPv4トランスポートサポートを提供するために、NMAGは、IPv4トランスポートネットワークのローカルモビリティアンカーにPMIPv6シグナル伝達メッセージを送信するために、ローカルモビリティアンカー（IPv4-LMAA）のIPv4アドレスを知る必要があります。この目的のために、PMAGからNMAGにIPv4-LMAAを伝えるために、LMAアドレス（LMAA）オプションと呼ばれる新しいオプションがセクション6.2.2で定義されています。
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）または異なる無線アクセスシステムなど、さまざまな種類のインターフェイスが関係する可能性があります。この仕様は、単一の無線モードを備えたモバイルノードをサポートします。このモバイルは、いつでもアクティブなインターフェイスが1つだけです。割り当てられた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および/またはIPv4-MN-HOAは、コンテキスト転送を通じてNMAGが利用できるようになります。これにより、NMAGは有益な手順を実行できます。たとえば、NMAGは、リンク添付ファイルが検出されるとすぐに、モバイルノードにプレフィックス情報を含むルーター広告（RA）を送信する必要があります（例：ルーター勧誘メッセージの受信を介して）。このようなRAは、たとえば、モバイルノードがNMAGに接続しながら新しい無線インターフェイスを使用するシナリオで推奨されます。モバイルノードには新しいインターフェイスに関する情報がないため、最初にHNPを使用して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]を実行します。新しいルーターはNUDプローブに応答し、PMIPv6ドメインで一般的な勧誘された近隣広告にリンク層アドレスを提供する必要があります。実装により、モバイルノードは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
ピアマグのIPアドレス
Message Data:
メッセージデータ：
Sequence # Same as [RFC5568].
[RFC5568]と同じシーケンス＃。
'S' flag Defined in [RFC5568], and MUST be set to zero in this specification.
[RFC5568]で定義されている「S」フラグは、この仕様ではゼロに設定する必要があります。
'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]は、このフィールドとその値0と1を定義します。この仕様では、「P」フラグセットを使用して、このフィールドはデフォルトでゼロに設定するか、次の値に設定できます。
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は、必要なすべてのコンテキスト情報の転送がこのメッセージで完了するときに設定されます。このコード値は、コンテキスト情報がいくつかのピースに断片化され、最後のフラグメントがこのメッセージに含まれている場合、および情報全体が1つのピースで転送される場合の両方で使用されます。
Mobility options:
モビリティオプション：
This field contains one or more mobility options, whose encoding and formats are defined in [RFC3775].
このフィールドには、1つ以上のモビリティオプションが含まれており、そのエンコードとフォーマットは[RFC3775]で定義されています。
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.
転送されたコンテキストは、メッセージごとに1つのモバイルノードに対して必要です。さらに、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.
セクション6.1.1で定義されているのと同じ「u」フラグ。
'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.
セクション6.1.1で定義されているのと同じ「F」フラグ。
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および128〜130は[RFC5568]で定義されています。「P」フラグが設定されている場合、コード値0の意味はこの仕様で定義されています。128〜130が再利用されます。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.
このフィールドには、1つ以上のモビリティオプションが含まれており、そのエンコードとフォーマットは[RFC3775]で定義されています。ターゲットモバイルノードを一意に識別するモビリティオプションは、対応するHIメッセージからコピーする必要があり、転送されたコンテキストはメッセージごとに1つのモバイルノードに対して必要です。
Required option(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開始の高速ハンドオーバーの場合、PMAGがコンテキスト情報を使用してHIメッセージをNMAGに送信し、NMAGが正常に受信すると、NMAGはコード値5でハックメッセージを返します。NMAGがContext Requestオプションの有無にかかわらずPMAGにHIメッセージを送信すると、FASTハンドオーバーを開始しました。PMAGは、要求されたコンテキスト情報またはデフォルトのコンテキスト情報（ある場合）でハックメッセージを返します。利用可能なすべてのコンテキスト情報が転送された場合、PMAGはハックメッセージのコード値を6に設定します。より多くのコンテキスト情報が利用可能な場合、PMAGはハックメッセージのコード値を5に設定し、NMAGは新しいHIメッセージを送信する場合があります（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-type-n nth要求されたオプションのタイプ値。
Req-length-n The length of the nth requested option, excluding the Req-type-n and Req-length-n fields.
req-length-n req-type-nおよびreq-length-nフィールドを除く、nth要求されたオプションの長さ。
Req-option-n The optional data to uniquely identify the requested context for the nth requested option.
req-option-n nth要求されたオプションの要求されたコンテキストを一意に識別するオプションのデータ。
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:
req-type-nおよびreq-length-nフィールドのみがある場合、req-length-nの値はゼロに設定されます。要求されたコンテキストを一意に指定するためにREQタイプ-N以外の追加情報が必要な場合、そのような情報はREQ-Length-Nの後に続きます。たとえば、要求されたコンテキストがHNPオプション（Type = 22）、MN Link-Layer IDオプション（Type = 25）、およびベンダー固有のオプション（Type = 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-Lengthはゼロに設定されます。ただし、その後のベンダー固有のオプションでは、要求されたコンテキストを識別するためにベンダー-IDとサブタイプがさらに必要であるため、これらのパラメーターが続き、REQ-Lengthは5に設定されます。サブタイプは[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)
1ローカルモビリティアンカーのIPv6アドレス（LMAA）
2 IPv4 address of the local mobility anchor (IPv4-LMAA)
2ローカルモビリティアンカーの2IPv4アドレス（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.
オプションコードが1の場合、LMA IPv6アドレス（LMAA）が挿入されます。オプションコードが2の場合、LMA IPv4アドレス（IPv4-LMA）が挿入されます。
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リンクローカルアドレスのインターフェイス識別子を転送するために使用されます。インターフェイス識別子がネットワークによって割り当てられているか、ネットワークに既知の展開では、このオプションは、この識別子をPMAGからNMAGに転送するために使用されます。
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.
P-ANのモバイルノードのIPv6リンクローカルアドレスに使用されるインターフェイス識別子値。
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].
セクション4.3で説明したように、モバイルノードがIPv4のみのモードまたはデュアルスタックモードで実行される場合、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.
PMAGとNMAGの間で交換されるハンドオーバー開始（HI）およびハンドオーバー（ハック）メッセージは、整合性とデータ起源の認証を提供するエンドツーエンドのセキュリティ協会を使用して保護する必要があります。PMAGとNMAGは、HIとハックメッセージを保護するためにIPSEC [RFC4301]を実装する必要があります。IPSECは、積極性保護を備えた輸送モードのセキュリティペイロード（ESP）[RFC4303]を、信号メッセージの保護に使用する必要があります。モバイルノードに関連する機密コンテキストが転送される場合は、機密性保護を使用する必要があります。
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.
PMAGとNMAGの間のリンクが通常のルーティングパスに従っていた場合よりも多くの脅威にさらされている場合、トンネルモードのIPSEC ESP [RFC4303]は、転送時にモバイルノードのパケットを保護するために使用する必要があります。
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およびハックメッセージの新しいフラグとステータスコード、および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.
著者は、この文書の徹底的なレビューについて、Vijay DevarapalliとSri 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.
著者はまた、チャーリー・パーキンス、欲望のオウライ、アフマド・ムハンナ、ジアレッタ・ジェラルド、ドマゴジ・プレムク、マルコ・リーブシュ、ファン・ザオ、ジュリアン・ラガニエ、ピエリック・シーテに、ミップショップワーキンググループメーリングリストでの情熱的な議論に感謝します。
[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月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 Vendor Specific Option", RFC 5094, December 2007.
[RFC5094] Devarapalli、V.、Patel、A。、およびK. Leung、「モバイルIPv6ベンダー固有のオプション」、RFC 5094、2007年12月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 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、「Proxy Mobile 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、「汎用ルーティングカプセル化（GRE）プロキシモバイルIPv6の重要なオプション」、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.、Simpson、W。、およびH. Soliman、「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. Perkins、「Mobile IPv4 Fast Handovers」、RFC 4988、2007年10月。
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によってハンドオフタイプを決定する1つのアプローチを提案します。
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) モバイルノードの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と比較します。これらの2つのMN LL-IDが同じ場合、ハンドオフタイプはタイプ3（上記で定義）に分類され、ハンドオフインジケータ値は3に設定されます。（上記で定義）Hi/Hackメッセージ交換は、これがマルチホームではなくハンドオフであることを示唆しているため、ハンドオフインジケータ値は2に設定できます。N-ANのモバイルノードでは、NMAGはこれがマルチホームのケースであると推測し、ハンドオフインジケーター値を1に設定する場合があります。ハンドオフ状態が変更されていない場合、MAGは追加情報なしでHI値を5に設定できます。ハンドオフタイプを想定できない場合、または有効なMN LL-IDが利用可能でない場合、NMAGは値を4に設定する場合があります。
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に取り付けられている場合、それらの間のトラフィックはローカルでルーティングされる場合があります。1つのモバイルノードがこのMAG（PMAG）から別のMAG（NMAG）に移動し、PMAGがモバイルノードのデタッチメントを検出しない場合、パケットを常に永久に転送し続けます。この状況は、ワイヤレスローカルエリアネットワーク（WLAN）アクセスを使用したリアクティブな高速ハンドオーバーで発生する可能性が高く、これにはモバイルノードの剥離をタイムリーに検出する機能がありません。この仕様は、このケースを処理するために適用できます。モバイルノードがNMAGに接続すると、NMAGは「F」フラグセットでPMAGにHIメッセージを送信します。これにより、PMAGはモバイルノードの剥離を実現し、MAG間トンネルを確立します。PMAGはすぐにローカルルーティングを停止し、モバイルノードのパケットをそのトンネルを介してNMAGに送信します。パケットは、新しいリンクのモバイルノードに配信されます。
Authors' Addresses
著者のアドレス
Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama 356-8502 Japan
Hidetoshi Yokota Kddi Lab 2-1-15 Ohara、Fujimino Saitama 356-8502 Japan
EMail: yokota@kddilabs.jp
Kuntal Chowdhury Cisco Systems 30 International Place Tewksbury, MA 01876 USA
Kuntal Chowdhury Cisco Systems 30 International Place Tewksbury、MA 01876 USA
EMail: kchowdhu@cisco.com
Rajeev Koodli Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
Rajeev Koodli Cisco Systems 170 W. Tasman Drive San Jose、CA 95134 USA
EMail: rkoodli@cisco.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
Basavaraj Patil Nokia 6000 Connection Drive Irving、TX 75039 USA
EMail: basavaraj.patil@nokia.com
Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA
フランク・シア・ホーウェイUSA 1700 ALMA DR. SUITE 500 PLANO、TX 75075 USA
EMail: xiayangsong@huawei.com