Network Working Group K. El Malki, Ed.
Request for Comments: 4881 Athonet
Category: Experimental June 2007
Low-Latency Handoffs in Mobile IPv4
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process.
モバイルIPv4は、モバイルノードが異なる外国人のエージェントによって提供されるサブネット間のIPv4-層ハンドオフを実行する方法について説明します。特定の例では、これらのハンドオフに関与レイテンシは遅延に敏感なまたはリアルタイムサービスのサポートに必要な閾値を超えることができます。このドキュメントの目的は、低遅延モバイルIPv4ハンドオフを達成するために2つの方法を提示することです。加えて、これらの2つの方法の組み合わせが記載されています。記載された技術は、モバイルノードが原因モバイルIPv4登録プロセスにおける遅延にIPv4パケットを送信または受信することができない期間を最小にすることによって、モバイルIPv4ネットワーク上のリアルタイムサービスのためのより大きな支持を可能にします。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. The Techniques .............................................5
1.3. L2 Triggers ................................................7
1.4. Requirements Language ......................................9
2. Requirements ....................................................9
3. The PRE-REGISTRATION Handoff Method ............................10
3.1. Operation .................................................11
3.2. Network-Initiated Handoff .................................13
3.3. Mobile-Initiated Handoff ..................................15
3.4. Obtaining and Proxying nFA Advertisements .................17
3.4.1. Inter-FA Solicitation ..............................17
3.4.2. Tunneled nFA Advertisements ........................18
3.5. Caching Router Advertisements .............................19
3.6. Movement Detection, MN, and FA Considerations .............19
3.7. L2 Address Considerations .................................21
3.8. Applicability of PRE-REGISTRATION Handoff .................21
4. The POST-REGISTRATION Handoff Method ...........................23
4.1. Two-Party Handoff .........................................24
4.2. Three-Party Handoff .......................................28
4.3. Renewal or Termination of Tunneling Service ...............34
4.4. When Will the MN Perform a Mobile IPv4 Registration? ......34
4.5. Handoff Request (HRqst) Message Format ....................36
4.6. Handoff Reply (HRply) Message Format ......................38
4.7. Handoff to Third (HTT) Message Format .....................40
4.8. Applicability of POST-REGISTRATION Handoff Method .........40
5. Combined Handoff Method ........................................41
6. Layer 2 and Layer 3 Handoff Timing Considerations ..............42
7. Reverse Tunneling Support ......................................42
8. Handoff Signaling Failure Recovery .............................43
8.1. PRE-REGISTRATION Signaling Failure Recovery ...............43
8.1.1. Failure of PrRtSol and PrRtAdv .....................43
8.1.2. Failure of Inter-FA Solicitation and
Advertisement ......................................44
8.2. POST-REGISTRATION Signaling Failure Recovery ..............44
8.2.1. HRqst Message Dropped ..............................44
8.2.2. HRply Message Dropped ..............................45
9. Generalized Link Layer and IPv4 Address (LLA) Extension ........46
9.1. 3GPP2 IMSI Link Layer Address and Connection ID
Extension .................................................47
9.2. 3GPP IMSI Link Layer Address Extension ....................48
9.3. Ethernet Link Layer Address Extension .....................49
9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension ..50
9.5. Solicited IPv4 Address Extension ..........................51
9.6. Access Point Identifier Extension .........................52
9.7. FA IPv4 Address Extension .................................53
10. IANA Considerations ...........................................53
10.1. New Extension Values .....................................53
10.2. Generalized Link Layer and IP Address Identifier (LLA) ...54
10.3. New Message Type and Code ................................54
11. Security Considerations .......................................55
12. Acknowledgements ..............................................57
13. References ....................................................57
13.1. Normative References .....................................57
13.2. Informative References ...................................58
Appendix A - Gateway Foreign Agents................................59
Appendix B - Low Latency Handoffs for Multiple-Interface MNs.......60
Appendix C - PRE_REGISTRATION Message Summary......................61
Mobile IPv4 [1] describes how a Mobile Node (MN) can perform IPv4- layer handoff between subnets served by different Foreign Agents (FAs). In certain cases, the latency involved in handoff can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two techniques to achieve low-latency Mobile IPv4 handoff during movement between FAs. A further combination of these two techniques is also described. The presented techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time during which an MN is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process. One or more of these techniques may be required to achieve fast Mobile IPv4 handoffs over different wireless technologies (e.g., WLAN, Cellular, WiMAX, Flash-OFDM, etc.). Each wireless technology has different layer 2 handoff procedures, and the best low-latency technique for each scenario should be used to optimize the handoff performance. Further deployment and experimentation are required to determine which technique is best suited to the wireless technologies in terms of implementation and performance. Therefore, the authors encourage further performance measurements and work on low-latency-over-foo specifications in collaboration with the appropriate wireless technology fora to describe the applicability to different wireless layer 2s.
モバイルIPv4 [1]モバイルノード（MN）が異なる外国エージェント（FAS）によってサービスサブネット間IPv4-層ハンドオフを実行する方法について説明します。特定の場合には、ハンドオフに関与レイテンシが遅延に敏感なまたはリアルタイムサービスのサポートに必要な閾値を超えることができます。この文書の目的は、Fasとの間の移動中に低遅延モバイルIPv4ハンドオフを達成するために2つの手法を提示することです。これら二つの技術のさらなる組み合わせも記載されています。提示技術は、MNが原因モバイルIPv4登録プロセスの遅れにIPv4パケットを送受信することができません、その間の時間を最小化することによって、モバイルIPv4ネットワーク上のリアルタイムサービスのための大きなサポートを可能にします。これらの技術のうちの1つ以上は、異なる無線技術（例えば、WLAN、セルラー、WiMAXのは、Flash-OFDM、等）を介して高速モバイルIPv4ハンドオフを達成するために必要とされてもよいです。各無線技術は、異なるレイヤ2ハンドオフ手順を有し、各シナリオのための最良の低レイテンシの技術は、ハンドオフ性能を最適化するために使用されるべきです。さらに展開と実験を実施し、性能面でのワイヤレス技術に最も適している手法を決定するために必要とされています。そこで、著者らは、さらにパフォーマンス測定を奨励し、異なる無線層2Sへの適用性を記述するために適切な無線技術フォーラムと共同で低遅延・オーバー・fooの仕様に取り組んでいます。
In the rest of this section, terminology used throughout the document is presented, the handoff techniques are briefly described, and the use of link-layer information is outlined. In Section 2, a brief description of requirements is presented. Section 3 describes the details of the PRE-REGISTRATION handoff technique, and Section 4 describes the details of the POST-REGISTRATION handoff technique. In Section 5, a combined method using the two handoff techniques together is presented. Section 6 discusses layer 2 and layer 3 handoff timing considerations. Section 7 discusses reverse tunneling support, Section 8 describes mechanisms to recover from message failures, and Section 9 describes protocol extensions required by the handoff techniques. Sections 10 and 11 discuss IANA and security considerations. Finally, the three appendices discuss additional material related to the handoff techniques. Appendix A gives a short introduction to Regional Registrations [11], which can be used together with low-latency handoffs. Appendix B discusses low-latency handoff when an MN has multiple wireless L2 interfaces, in which case the techniques in this document may not be necessary. Appendix C provides a summary of the messages used in PRE-REGISTRATION.
このセクションの残りの部分では、文書全体を通して使用される用語は、ハンドオフ技術が簡単に説明され、提示され、リンク層情報の使用が概説されています。第2節では、要件の簡単な説明が提示されます。セクション3は、事前登録ハンドオフ技術の詳細について説明し、セクション4は、後登録ハンドオフ技術の詳細について説明します。 5章では、2つのハンドオフ技術を用いて結合する方法が提示されています。セクション6は、レイヤ2およびレイヤ3ハンドオフタイミング考慮事項について説明します。セクション7で説明トンネリングサポートを逆、セクション8は、メッセージの失敗から回復するメカニズムを説明し、セクション9は、ハンドオフ技術によって必要なプロトコル拡張を記述しています。セクション10と11は、IANAとセキュリティの考慮事項について説明します。最後に、3つの付録は、ハンドオフ技術に関連する追加の材料を議論します。付録Aは、低遅延ハンドオフと一緒に使用することができる地域の登録[11]に短い導入を与えます。付録Bは、MNは、この文書に記載されている技術は必要ないかもしれない、その場合、複数の無線L2インタフェースを有する低遅延ハンドオフを論じています。付録Cには、事前登録に使用されるメッセージの要約を提供します。
This section presents a few terms used throughout the document.
このセクションでは、文書全体で使用されるいくつかの用語を提示します。
oFA - old Foreign Agent (FA), the FA involved in handling the care-of address (CoA) of a Mobile Node (MN) prior to a layer 3 (L3) handoff.
旧FA - 旧外部エージェント（FA）、FA前レイヤ3（L3）ハンドオフに気付アドレス（CoA）モバイルノード（MN）の取り扱いに関わります。
nFA - new Foreign Agent, the FA anticipated to be handling an MN's care-of address after completion of an L3 handoff.
新FA - 新しい外部エージェント、FAは、L3ハンドオフが完了した後にMNの気付アドレスを処理することが予想されます。
aFA - anchor Foreign Agent, the FA that is currently handling the network end of the tunnel in POST-REGISTRATION.
AFA - アンカー外部エージェント、現在登録後におけるトンネルのネットワーク側を処理しているFA。
L2 handoff - Movement of an MN's point of layer 2 (L2) connection from one wireless access point to another.
L2ハンドオフ - 別の無線アクセスポイントからレイヤ2（L2）接続の人の点の移動。
L3 handoff - Movement of an MN between FAs that involves changing the care-of address at Layer 3 (L3).
L3ハンドオフ - レイヤ3（L3）に気付アドレスを変更することを含むのFA間のMNの移動。
L2 trigger - Information from L2 that informs L3 of particular events before and after L2 handoff. The descriptions of L2 triggers in this document are not specific to any particular L2, but rather represent generalizations of L2 information available from a wide variety of L2 protocols.
L2トリガ - L2ハンドオフの前と後に、特定のイベントのL3を知らせるL2からの情報。 L2の説明は、本文書にトリガ任意の特定のL2に特異的ではなく、むしろL2プロトコルの様々なから入手可能なL2情報の一般化を表します。
L2-MT - An L2 trigger that occurs at the MN, informing of movement to a certain nFA (Mobile Trigger).
L2-MT - 特定の新FA（モバイルトリガ）への移動を知らせる、MNで発生L2トリガー。
L2-ST or source trigger - An L2 trigger that occurs at oFA, informing the oFA that L2 handoff is about to occur.
L2-STまたはソース・トリガ - L2ハンドオフが発生しようとしていることを旧FAを知らせる、旧FAで発生L2トリガー。
L2-TT or target trigger - An L2 trigger that occurs at nFA, informing the nFA that an MN is about to be handed off to nFA.
L2-TTまたはターゲット・トリガ - MNは、新FAにハンドオフされようとしていることを新FAを知らせる、新FAで発生L2トリガー。
L2-LU - An L2 trigger that occurs at the MN or nFA, informing that the L2 link between MN and nFA is established.
L2-LU - MNと新FAとの間のL2リンクが確立されていることを知らせる、MN又は新FAで発生L2トリガー。
L2-LD - An L2 trigger that occurs at the oFA, informing the oFA that the L2 link between MN and oFA is lost.
L2-LD - MNと旧FAとのL2リンクが失われた旧FAを知らせる、旧FAで発生L2トリガー。
low-latency handoff - L3 handoff in which the period of time during which the MN is unable to receive packets is minimized.
低レイテンシハンドオフ - L3ハンドオフMNがパケットを受信できないいる期間が最小となります。
low-loss handoff - L3 handoff in which the number of packets dropped or delayed is minimized. Low-loss handoff is often called smooth handoff.
低損失ハンドオフ - パケットの数がドロップ又は遅延したL3ハンドオフが最小化されます。低損失のハンドオフは、多くの場合、スムーズなハンドオフと呼ばれています。
seamless handoff - L3 handoff that is both low latency and low loss.
シームレスハンドオフ - 低遅延、低損失の両方でL3ハンドオフ。
bidirectional edge tunnel (BET) - A bidirectional tunnel established between two FAs for purposes of temporarily routing an MN's traffic to/from it on a new subnet without requiring the MN to change CoA.
双方向エッジトンネル（BET） - 一時的にCoAを変更するためにMNを必要とすることなく、新たなサブネット上に/それからのMNのトラフィックをルーティングする目的のために2つのFA間で確立双方向トンネル。
ping-pong - Rapid back-and-forth movement between two wireless access points often due to failure of L2 handoff. Ping-pong can occur if radio conditions for both the old and new access points are about equivalent and less than optimal for establishing a good, low-error L2 connection.
ピンポン - L2ハンドオフの失敗に起因することが多い2つの無線アクセスポイント間の迅速な前後運動。古いものと新しいアクセスポイントの両方の無線状態が良い、低エラーL2接続を確立するための最適よりも同等と少ない程度であればピンポンが発生する可能性があります。
network-initiated handoff - L3 handoff in which oFA or nFA initiates the handoff.
ネットワーク開始のハンドオフ - 旧FA又は新FAがハンドオフを開始するL3ハンドオフ。
mobile-initiated handoff - L3 handoff in which the MN initiates the handoff.
モバイル主導のハンドオフ - MNがハンドオフを開始したL3ハンドオフ。
MN or FA identifier - An IPv4 address of an MN or FA, or an L2 identifier that can be resolved to the IPv4 address of an MN or FA. If the identifier is an L2 identifier, it may be specific to the L2 technology.
MNまたはFA識別子 - MN又はFA、又はMN又はFAのIPv4アドレスに解決することができるL2識別子のIPv4アドレス。識別子がL2識別子である場合、それはL2技術に特異的であってもよいです。
Mobile IPv4 was originally designed without any assumptions about the underlying link layers over which it would operate so that it could have the widest possible applicability. This approach has the advantage of facilitating a clean separation between L2 and L3 of the protocol stack, but it has negative consequences for handoff latency. The strict separation between L2 and L3 results in the following built-in sources of delay:
モバイルIPv4はもともとそれが可能な限り広範な適用性を持っていることができるように動作する、その上根底にあるリンク層についての仮定なしに設計されました。このアプローチは、プロトコルスタックのL2とL3との間の明確な分離を容易にするという利点を有するが、それは、ハンドオフの待ち時間のために負の影響を有しています。遅延の次のビルトイン源でL2とL3の結果との間の厳密な分離。
- The MN may only communicate with a directly connected FA. This implies that an MN may only begin the registration process after an L2 handoff to nFA (new FA) has completed.
- MNは、直接接続されたFAと通信することができます。これは、新FAへのL2ハンドオフ（新FA）が完了した後にMNが唯一の登録プロセスを開始してよいことを意味します。
- The registration process takes some non-zero time to complete as the Registration Requests propagate through the network. During this period of time, the MN is not able to send or receive IPv4 packets.
- 登録プロセスは、登録要求をネットワークを介して伝播として完了するためのいくつかの非ゼロの時間がかかります。この期間中、MNは、IPv4パケットを送信または受信することができません。
This document presents techniques for reducing these built-in delay components of Mobile IPv4. The techniques can be divided into two general categories, depending on which of the above problems they are attempting to address:
この文書では、モバイルIPv4のこれらの組み込み遅延成分を低減するための技術を提供します。技術は、それらが対処しようとしている上記の問題のどれに応じて、2つの一般的なカテゴリーに分けることができます。
- Allow the MN to communicate with the nFA while still connected to the oFA.
- まだ旧FAに接続しながら、MNが新FAと通信できるようにします。
- Provide for data delivery to the MN at the nFA even before the formal registration process has completed.
- 正式な登録プロセスが完了する前であっても、新FAでMNへのデータ配信のために提供します。
The first category of techniques allows the MN to "pre-build" its registration state on the nFA prior to an underlying L2 handoff. The second category of techniques allows for service to continue uninterrupted while the handoff is being processed by the network without requiring the MN's involvement.
技術の最初のカテゴリは、基礎となるL2ハンドオフに新FAへの登録状態は前MNは、「プレビルド」することができます。技術の第二のカテゴリーは、ハンドオフがMNの関与を必要とせずにネットワークによって処理されている間、サービスが中断なく継続することが可能になります。
Three methods are presented in this document to achieve low-latency L3 handoff, one for each category described above and one as a combination of the two:
3つの方法が二つの組み合わせのような低レイテンシーL3ハンドオフ、上述した各カテゴリの1つずつを達成するために、本書で提示されています。
- PRE-REGISTRATION handoff method,
- 事前登録ハンドオフ方法、
- POST-REGISTRATION handoff method, and
- POST登録ハンドオフ方法、および
- combined handoff method.
- 合成ハンドオフ方法。
The PRE-REGISTRATION handoff method allows the MN to be involved in an anticipated IPv4-layer handoff. The MN is assisted by the network in performing an L3 handoff before it completes the L2 handoff. The L3 handoff can be either network-initiated or mobile-initiated. Accordingly, L2 triggers are used both in the MN and in the FA to trigger particular L3 handoff events. The PRE-REGISTRATION method coupled with L2 mobility helps to achieve seamless handoffs between FAs. The basic Mobile IPv4 concept involving advertisement followed by registration is supported, and the PRE-REGISTRATION handoff method relies on Mobile IPv4 security. No new messages are proposed, except for an extension to the Agent Solicitation message in the mobile-initiated case.
事前登録ハンドオフ方法は、MNが予想されるIPv4の層ハンドオフに関与することを可能にします。 MNは、それがL2ハンドオフを完了する前にL3ハンドオフを実行する際に、ネットワークによって支援されます。 L3ハンドオフは、ネットワーク開始またはモバイル主導のいずれかになります。したがって、L2トリガーは、特定のL3ハンドオフ・イベントをトリガするためにMN及びFAの両方で使用されています。 L2の移動と相まって事前登録の方法は、FAの間のシームレスなハンドオフを達成するのに役立ちます。登録に続い広告に関わる基本的なモバイルIPv4概念がサポートされており、事前登録のハンドオフ方法は、モバイルIPv4のセキュリティに依存しています。新しいメッセージは、モバイルが開始した場合のエージェント要請メッセージへの拡張を除いて、提案されていません。
The POST-REGISTRATION handoff method proposes extensions to the Mobile IPv4 protocol to allow the oFA (old FA) and nFA (new FA) to utilize L2 triggers to set up a bidirectional tunnel between oFA and nFA that allows the MN to continue using its oFA while on nFA's subnet. This enables a rapid establishment of service at the new point of attachment, which minimizes the impact on real-time applications. The MN must eventually perform a formal Mobile IPv4 Registration after L2 communication with the new FA is established, but this can be delayed as required by the MN or FA. Until the MN performs registration, the FAs will set up and move bidirectional tunnels as required to give the MN continued connectivity.
POST登録ハンドオフ方法は、旧FA（旧FA）と新FA（新FA）は、L2を利用することを可能にするモバイルIPv4プロトコルに拡張を提案しているMNが旧FAを使用し続けることができ旧FAと新FAとの間の双方向トンネルを設定するトリガ新FAのサブネット上にいる間。これは、リアルタイムアプリケーションへの影響を最小限に抑え新しい接続点、でサービスの迅速な確立を可能にします。新FAとのL2通信が確立されていますが、MNまたはFAで必要とされる、これが遅延することができた後、MNは、最終的には、正式なモバイルIPv4登録を行う必要があります。 MNは、登録を行うまでは、FASが設定され、MNに継続的な接続性を与えるために、必要に応じて、双方向のトンネルを移動します。
The combined method involves running a PRE-REGISTRATION and a POST-REGISTRATION handoff in parallel. If the PRE-REGISTRATION handoff can be performed before the L2 handoff completes, the combined method resolves to a PRE-REGISTRATION handoff. However, if the PRE-REGISTRATION handoff does not complete within an access technology dependent time period, the oFA starts forwarding traffic for the MN to the nFA as specified in the POST-REGISTRATION handoff method. This provides for a useful backup mechanism when completion of a PRE-REGISTRATION handoff cannot always be guaranteed before the L2 handoff completion.
合成方法は、事前登録と並行してレジ後ハンドオフを実行することを含みます。 L2ハンドオフが完了する前に事前登録ハンドオフを行うことができれば、組み合わされた方法は、事前登録ハンドオフに解決します。事前登録ハンドオフがアクセス技術に依存する期間内に完了しない場合は、旧FAはPOST登録ハンドオフ方法で指定された新FAへのMNのためのトラフィックの転送を開始します。これは、事前登録ハンドオフの完了は常にL2ハンドオフの完了前に保証することはできません便利なバックアップメカニズムを提供します。
It should be noted that the methods described in this document may be applied to MNs having a single interface (e.g., Wireless LAN interface) or multiple interfaces (e.g., one WLAN and one cellular interface). However, the case of multiply-interfaced MNs needs special consideration, since the handoff methods described in this document may not be required in all cases (see Appendix B).
なお、この文書に記載された方法は、単一のインタフェース（例えば、無線LANインタフェース）または複数のインタフェース（例えば、1つのWLANと一つセルラインタフェース）を有するのMNに適用されてもよいことに留意すべきです。この文書に記載されたハンドオフ方法は、すべての場合に必要とされないかもしれないので、多重インターフェースのMNの場合は、特別な配慮を必要とする（付録Bを参照）。
An L2 trigger is a signal of an L2 event. In this document, the L2 events relate to the L2 handoff process. One possible event is early notice of an upcoming change in the L2 point of attachment of the mobile node to the access network. Another possible event is the completion of relocation of the mobile node's L2 point of attachment to a new L2 access point. This information may come explicitly from L2 in a solicited or unsolicited manner, or it may be derived from L2 messages. Although the protocols outlined in this document make use of specific L2 information, Mobile IPv4 should be kept independent of any specific L2. L2 triggers are an abstraction mechanism for a technology-specific trigger. Therefore, an L2 trigger that is made available to the Mobile IPv4 stack is assumed to be generic and technology independent. The precise format of these triggers is not covered in this document, but the information required to be contained in the L2 triggers for low-latency handoffs is specified.
L2トリガは、L2イベントの信号です。この文書では、L2のイベントは、L2ハンドオフ・プロセスに関連します。一つの可能性のあるイベントは、アクセスネットワークへのモバイルノードの接続のL2点が今後の変化を早期にお知らせです。別の可能性のあるイベントは、新しいL2アクセスポイントへの接続のモバイルノードのL2ポイントの移転の完了です。この情報は、要請や迷惑な方法で明示的にL2から来るかもしれない、またはそれはL2メッセージから誘導することができます。本文書で概説したプロトコルは、特定のL2情報を利用しているが、モバイルIPv4は、任意の特定L2とは無関係に維持されるべきです。 L2トリガーは、技術特有のトリガーのための抽象化メカニズムです。したがって、モバイルIPv4スタックに利用可能にされるL2トリガは、独立した汎用技術であると仮定されます。これらのトリガーの正確な形式は、この文書で覆われていないが、L2に含まれるために必要な情報は、低遅延ハンドオフのトリガが指定されています。
In order to properly abstract from the L2, it is assumed that one of the three entities -- the MN, oFA, or nFA -- is made aware of the need for an L2 handoff and that the nFA or MN can optionally also be made aware that an L2 handoff has completed. A specific L2 will often dictate when a trigger is received and which entity will receive it. Certain L2s provide advance triggers on the network side, while others provide advance triggers on the MN. Also, the particular timing of the trigger with respect to the actual L2 handoff may differ from technology to technology. For example, some wireless links may provide such a trigger well in advance of the actual handoff. In contrast, other L2s may provide little or no information in anticipation of the L2 handoff.
MN、旧FA、又は新FA - - L2ハンドオフの必要性を認識して作られ、新FAまたはMNも行うことを任意にできることであるL2から適切に抽象化するためには、3つのエンティティのいずれかがいるとしますL2ハンドオフが完了したことを認識。トリガを受信したときに、特定のL2は、多くの場合、口述し、その実体は、それを受け取ることになります。特定のL2Sは、他の人が事前にMNにトリガを提供しながら、事前には、ネットワーク側でトリガーを提供します。また、実際のL2ハンドオフに対してトリガの特定のタイミングは、技術技術と異なっていてもよいです。例えば、いくつかの無線リンクは、実際のハンドオフの事前にそのようなトリガーを提供することができます。対照的に、他のL2Sは、L2ハンドオフを予期してほとんどまたは全く情報を提供してもよいです。
An L2 trigger may be categorized according to whether it is received by the MN, oFA, or nFA. Table 1 gives such a categorization along with information contained in the trigger. The methods presented in this document operate based on different types of L2 triggers as shown in Table 1. Once the L2 trigger is received, the handoff processes described hereafter are initiated. The three triggers, L2-ST, L2-TT, and L2-MT, are independent of each other and are not expected to occur together since each will trigger a different type of handoff behaviour.
L2トリガは、それがMN、旧FA、又は新FAにより受信されたか否かに応じて分類することができます。表1は、トリガーに含まれる情報と一緒に、このような分類を与えます。この文書で提示される方法は、L2の異なるタイプに基づいて動作L2トリガが受信されると、後述のハンドオフ・プロセスが開始され、表1に示すようにトリガします。 3つのトリガー、L2-ST、L2-TT、およびL2-MTは、互いに独立して、それぞれハンドオフ挙動の異なるタイプをトリガするので、一緒に発生すると予想されていません。
+-------------+----------------------+------------------------------+
| L2 Trigger | Mobile | Source |
| | Trigger | Trigger |
| | (L2-MT) | (L2-ST) |
+-------------+----------------------+------------------------------+
| Recipient | MN | oFA |
+-------------+----------------------+--------------+---------------+
| Method | PRE | PRE | POST |
| | mobile-initiated | network- | source |
| | | initiated | trigger |
+-------------+----------------------+--------------+---------------+
| When? | sufficiently before | sufficiently | sufficiently |
| | the L2 handoff | before L2 | before L2 |
| | so that MN can | handoff for | handoff for |
| | solicit PrRtAdv | FA to send | oFA & nFA to |
| | from oFA | PrRtAdv | exchange |
| | | to MN | HRqst/HRply |
+-------------+----------------------+--------------+---------------+
| Parameters | nFA identifier | nFA identifier, MN identifier|
+-------------+----------------------+------------------------------+
Table 1 - L2 Trigger
(continued on next page)
+------------+----------------------+---------------+---------------+
| L2 Trigger | Target | Link-Up | Link-Down |
| | Trigger | (L2-LU) | (L2-LD) |
| | (L2-TT) | | |
|------------+----------------------+---------------+---------------+
| Recipient | nFA | MN or nFA | oFA |
|------------+-----------+----------+---------------+---------------+
| Method | PRE | POST | PRE & POST | POST |
| | network- | target | | |
| | initiated | trigger | | |
|------------+----------------------+---------------+---------------+
| When? | | when radio | when radio |
| | same as | link between | link between |
| | source trigger | MN & nFA is | MN and oFA |
| | | established | is lost |
|------------+----------------------+---------------+---------------+
| Parameters | oFA identifier | @MN: nFA IPv4 | MN identifier |
| | MN identifier | or L2 addr. | |
| | | @nFA: MN IPv4 | |
| | | or L2 addr. | |
+------------+----------------------+---------------+---------------+
Table 1 - L2 Trigger
表1 - L2トリガ
In this document, the key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [2].
この文書に記載されている、キーワード "MAY"、 "MUST"、 "MUST NOT"、 "任意の"、 "RECOMMENDED"、 "SHOULD"、及び[2]に記載のように解釈されるべきである "SHOULD NOT"。
The following requirements are applicable to low-latency handoff techniques and are supported by the methods in this document:
次の要件は、低遅延ハンドオフ技術に適用可能であり、この文書に記載されている方法によってサポートされています。
- to provide low-latency and low-loss handoff for real-time services,
- リアルタイムサービスのための低遅延および低損失のハンドオフを提供するために、
- to have no dependence on a wireless L2 technology,
- 無線L2技術には依存性がないように、
- to support inter- and intra-access technology handoffs, and
- インターイントラアクセス技術のハンドオフをサポートするため、および
- to limit wireless bandwidth usage.
- 無線帯域幅の使用を制限します。
The PRE-REGISTRATION handoff method is based on the normal Mobile IPv4 handoff procedure specified in [1], according to which:
事前登録ハンドオフ方法は、それによれば、[1]で指定された通常のモバイルIPv4ハンドオフ手順に基づいています。
- an advertisement for an FA is received by an MN,
- FAの広告は、MNによって受信され、
- the advertisement allows the MN to perform movement detection, and
- 広告がMNは、動き検出を行うことができ、かつ
- the MN registers with the FA.
- MNは、FAに登録されます。
The basic messages specified in [1] are extended to carry information required to achieve fast handoffs. The PRE-REGISTRATION method allows both the MN and FA to initiate the layer 3 handoff and it can make use of L2 triggers on either the FA or MN side, depending on whether network-initiated or mobile-initiated handoff occurs.
[1]で指定された基本的なメッセージは、高速ハンドオフを達成するために必要な情報を運ぶように拡張されています。事前登録の方法は、MNとFAの両方がレイヤ3ハンドオフを開始すると、それはL2の使用は、ネットワーク起動または移動開始ハンドオフが発生したかどうかに依存して、FAまたはMN側のいずれかにトリガすることができる可能にします。
PRE-REGISTRATION supports the normal Mobile IPv4 model [1] and optionally also the Regional Registration model [11]. There can be advantages in implementing [11] together with low-latency handoff mechanisms, in particular in cases where the Home Agent (HA) is at a distance (in terms of delay) from the nFA. The time required for the handoff procedure to complete can be reduced by using a closer local HA, called Gateway Foreign Agent (GFA) in [11]. However, implementation of [11] is not required by PRE-REGISTRATION. PRE-REGISTRATION also supports movement where a new Authentication, Authorization, and Accounting (AAA) transaction must occur to authenticate the MN with a new domain.
事前登録は、[1]と、任意に、通常のモバイルIPv4モデルをサポートする地域登録モデル[11]。ホームエージェント（HA）は、新FAから（遅延の点で）離れている場合には、特に、低レイテンシハンドオフメカニズムと一緒に[11]を実施する際に利点があり得ます。完了するためにハンドオフ手順のために必要な時間は、[11]にゲートウェイ外部エージェント（GFA）と呼ば近い地元のHAを使用することによって減少させることができます。しかしながら、[11]の実装は、事前登録によって必要とされません。事前登録は、新しい認証、認可、アカウンティング（AAA）トランザクションは、新しいドメインでMNを認証するために行わなければならないの動きをサポートしています。
The PRE-REGISTRATION handoff mechanism is summarized in Figure 1.
事前登録ハンドオフ機構を図1に要約されています。
+---------+
| HA (GFA)|<---------+
+---------+ | 4. (Reg)RegReq
| 5. (Reg)RegReply
v
+-----+ 1a. PrRtSol +-----+
| | -----------------> | nFA |
| oFA | 1b. PrRtAdv | |
+-----+ <----------------- +-----+
^ | ^
(2a. PrRtSol)| | 2b |
| | PrRtAdv | 3. (Reg)RegReq
| | |
| v --------------------+
+-----+ /
| MN |
+-----+ - - - - - ->
Movement
Figure 1 - PRE-REGISTRATION Handoff Protocol
図1 - 事前登録ハンドオフプロトコル
The following steps provide more detail on the protocol:
次の手順は、プロトコルの詳細を提供します。
1. Message 1a is a Proxy Router (Agent) Solicitation (PrRtSol) from oFA to nFA. It is a Mobile IP agent solicitation containing an identifier for the nFA (i.e., IP address or L2 address) in a Generalized Link Layer and IP Address Extension (see Section 9). When message 1a is received by the nFA containing nFA's correct identifier in the LLA extension, the nFA MUST return the Proxy Router Advertisement (Agent Advertisement) in message 1b. Message 1b is simply nFA's Agent Advertisement containing the nFA layer 2 address in a Generalized Link Layer and IP Address (LLA) Extension (see Section 9.3). Messages 1a and 1b SHOULD occur in advance of the PRE-REGISTRATION handoff in order not to delay the handoff. For this to occur, oFA SHOULD solicit and cache advertisements from neighboring nFAs using messages 1a and 1b, thus decoupling the timing of this exchange from the rest of the PRE-REGISTRATION handoff. When the L3 handoff is initiated by a target L2 trigger at nFA (L2-TT), message 1b equals message 2b and is sent unsolicited directly to MN (tunneled by nFA to MN through oFA) instead of being relayed by oFA.
1.メッセージ1aは、旧FAから新FAへのプロキシルータ（エージェント）要請（PrRtSol）です。これは、一般化リンクレイヤとIPアドレス拡張（9章を参照）新FA（すなわち、IPアドレス又はL2アドレス）の識別子を含むモバイルIPエージェント勧誘あります。メッセージ1aはLLA拡張に新FAの正しい識別子を含む新FAによって受信されると、新FAは、メッセージ1bにプロキシルータ通知（エージェント広告）を返さなければなりません。メッセージ1bは、単純に一般化リンクレイヤとIPアドレス（LLA）拡張（第9.3節を参照）で、新FAレイヤ2アドレスを含む新FAのエージェント広告です。メッセージ1a及び1bは、ハンドオフを遅延させないために事前登録ハンドオフの前に起こるべきです。これが発生するため、旧FAは、このように事前登録ハンドオフの残りの部分からこの交換のタイミングをデカップリング、メッセージ1aおよび1bを用いて隣接NFASから広告を要求し、キャッシュすべきです。 L3ハンドオフは、新FA（L2-TT）の目標L2トリガによって開始されたとき、メッセージ1bはメッセージ2Bに等しく、代わりに、旧FAによって中継されるのMN（OFA介してMNに新FAによってトンネリング）に直接迷惑送られます。
2. Message 2a is a Proxy Router Solicitation (PrRtSol) from MN to oFA. It is different from a normal Router (Agent) Solicitation since it is soliciting an advertisement from a router different from the one receiving this message. It is a Mobile IP Agent Solicitation containing an identifier for the nFA (i.e., IP address or L2 address) in a Generalized Link Layer and IP Address Extension (see Section 9). The presence of message 2a indicates that the handoff is mobile-initiated and its absence means that the handoff is network-initiated. In mobile-initiated handoff, message 2a occurs if there is an L2 trigger in the MN to solicit for a Proxy Router Advertisement (PrRtAdv). When message 2a is received by the oFA, it MUST return the Proxy Router Advertisement (Agent Advertisement) in message 2b. This is simply nFA's Agent Advertisement containing the nFA layer 2 address in a Generalized Link Layer and IP Address (LLA) Extension (see Section 9.3). In network-initiated source-triggered handoff, the L2 trigger occurs at oFA, and oFA MUST relay the Agent Advertisement in message 2b without the need for the MN to solicit. Note that it is also possible for nFA to advertise directly to the MN in the network-initiated target-triggered case (see Section 3.2).
2.メッセージ2aは、MNから旧FAにプロキシルータ要請（PrRtSol）です。それは、このメッセージを受信したものとは異なるルータから広告を募集しているので、それは通常のルータ（エージェント）勧誘は異なっています。これは、一般化リンクレイヤとIPアドレス拡張（9章を参照）新FA（すなわち、IPアドレス又はL2アドレス）の識別子を含むモバイルIPエージェント要請です。メッセージ2aの存在は、ハンドオフがモバイル開始であることを示し、その不在は、ハンドオフがネットワーク開始であることを意味します。プロキシルータ広告（代理ルータ広告）のために勧誘するMNにL2トリガがある場合、モバイルによって開始ハンドオフにおいて、メッセージ2aが発生します。メッセージ2aが旧FAによって受信されると、それはメッセージ2bにプロキシルータ通知（エージェント広告）を返さなければなりません。これは、単純に一般化リンクレイヤとIPアドレス（LLA）拡張（第9.3節を参照）で、新FAレイヤ2アドレスを含む新FAのエージェント広告です。ネットワーク起動ソーストリガハンドオフでは、L2トリガが旧FAで発生し、旧FAは、MNが勧誘するために必要とすることなく、メッセージ2bにエージェント広告を中継しなければなりません。新FAは、ネットワーク開始ターゲットトリガの場合におけるMNに直接宣伝することも可能であることに注意してください（3.2節を参照してください）。
3. The MN performs movement detection upon receipt of a solicited or unsolicited Agent Advertisement and, if required, it sends a Registration Request (RegReq) message [1] in message 3 to nFA. When a local Gateway Foreign Agent (GFA) is present, this message can optionally be a Regional Registration Request (RegRegReq) [11]. Message 3 is routed through oFA since the MN is not directly connected to nFA prior to the L2 handoff.
前記MNは、要請または迷惑エージェント広告を受信すると、移動検出を実行し、必要な場合、それが新FAにメッセージ3の登録要求（REGreqの）メッセージ[1]を送信します。ローカルゲートウェイ外部エージェント（GFA）が存在する場合、このメッセージは、必要に応じて地域の登録要求（RegRegReq）[11]であることができます。 MNが直接前L2ハンドオフに新FAに接続されていないので、メッセージ3は、旧FAを介してルーティングされます。
4. Messages 4 and 5 complete the standard Mobile IPv4 Registration [1] or optionally Regional Registration [11] initiated with message 3. The Registration Request MUST contain the MN's layer 2 address in a Generalized Link Layer and IP Address Extension (see Sections 3.7 and 9). This identifier may be a plain Ethernet address or an identifier specific to the wireless technology. If the MN is not already connected to nFA, the Registration Reply in message 5 MUST be buffered by the nFA and unicast to the MN on-link as soon as the MN connects to nFA (i.e., L2-LU trigger at nFA, which can be implemented by the MN sending an Agent Solicitation or optionally using special layer 2 techniques, which are outside the scope of this document). This is necessary since the MN may have to detach from oFA, due to the wireless L2 connection, before it receives the reply. The MN's L2 address is obtained using the extensions in Section 9, as described in Section 3.7. Figures 2 and 3 illustrate this procedure.
[1]または必要に応じて地域登録[11]メッセージ3で開始一般化リンクレイヤとIPアドレス拡張のMNのレイヤ2アドレスを含まなければならない登録要求（セクション3.7を参照。4.メッセージ4および図5は、標準のモバイルIPv4登録を完了しますおよび9）。この識別子は、プレーンイーサネットアドレスや無線技術に固有の識別子であってもよいです。 MNがすでに新FAに接続されていない場合、メッセージ5における登録応答はすぐにMNが新FAに接続するように、リンクMNに新FAとユニキャストでバッファリングされなければならない（すなわち、L2-LUトリガ新FAで、そのことができますMNエージェント要請を送信するか、必要に応じて特別な層にこの文書の範囲外である2つの技術を）を使用して実現すること。それが応答を受け取る前に、MNは、無線L2接続のために、旧FAから切り離すする必要がありますので、これは必要です。 3.7節で説明したようにMNのL2アドレスは、第9節で拡張機能を使用して取得されます。図2および図3は、この手順を示します。
5. If the registration is successful, packets for the MN are tunneled from the HA (or GFA) to the nFA and then to the MN.
新FAへ5.登録が成功した場合、MNのためのパケットはHA（またはGFA）からトンネルされ、その後、MNへ。
PRE-REGISTRATION is not dependent on [11]. However, if the HA is at a distance (in terms of delay) from the nFA, the use of a local GFA may reduce the time required for the handoff procedure to complete.
事前登録は、[11]に依存しません。 HAは、新FAから（遅延の点で）離れている場合は、ローカルGFAの使用が完了するハンドオフ手順に必要な時間を減らすことができます。
The time at which the L2 trigger is received by the oFA or MN, thereby triggering the PRE-REGISTRATION handoff, compared to the time at which the actual L2 handoff occurs is important for the optimal performance of the low-latency handoff. That is, in the optimal case, the L2 trigger will be received and the four messaging steps of PRE-REGISTRATION described above will be completed (i.e., up to when the Registration Request is processed by HA or GFA) before the MN moves. Optimally, the Registration Reply and the first packet redirected by the HA (or GFA) to nFA will reach the MN at the moment in which the MN's L2 link to nFA is fully established. The MN would therefore not suffer any disruption due to the L3 handoff. This cannot always be guaranteed unless particular implementation techniques are used. To alleviate a part of this timing problem, the MN MAY set the S bit [1] in low-latency Registration Requests sent by the MN. This allows the MN to receive packets at both oFA and nFA during the short layer 2 handoff time. Other techniques may be required, such as L2 techniques or buffering, but these are outside the scope of this document. In addition, further handoff smoothing considerations may be required to prevent the loss of packets in-flight between HA (or GFA) and oFA while the MN performs a PRE-REGISTRATION handoff. These are also outside the scope of this document.
L2トリガが実際のL2ハンドオフが発生する時間に比べて、それにより、事前登録ハンドオフをトリガする、旧FA又はMNによって受信される時間は、低レイテンシハンドオフの最適な性能のために重要です。すなわち、最適な場合には、L2トリガが受信されている、上記の事前登録の4つのメッセージングステップが完了される（すなわち、登録要求がHAまたはGFAによって処理されるときまで）MNが移動前。最適には、新FAに登録応答およびHA（またはGFA）によってリダイレクトされた最初のパケットは、新FAとMNのL2リンクが完全に確立されている現時点ではMNに到達します。 MNは、そのためによりL3ハンドオフに任意の混乱を受けないでしょう。特定の実装技術が使用されていない限り、これは常に保証することはできません。このタイミングの問題の一部を軽減するために、MNは、MNによって送信された低レイテンシ登録要求に[1] Sビットを設定することができます。これは、MNが短いレイヤ2ハンドオフ時に旧FAと新FAの両方でパケットを受信することを可能にします。他の技術は、L2技術または緩衝として、必要とされ得るが、これらはこの文書の範囲外です。 MNは、事前登録ハンドオフを実行しながら加え、さらにハンドオフ平滑考察は、インフライトHA（又はGFA）と旧FAとの間のパケットの損失を防ぐために必要とされ得ます。これらは、この文書の範囲外でもあります。
Figures 2, 3, and 4 contain message timing diagrams for the network-initiated and mobile-initiated PRE-REGISTRATION handoff procedures.
図2、図3、及び図4は、ネットワーク起動およびモバイル開始事前登録ハンドオフ手順のためのメッセージのタイミング図を含みます。
As described in Table 1, a PRE-REGISTRATION handoff can be initiated at oFA by a source trigger or at nFA by a target trigger. Figures 2 and 3 contain message timing diagrams for PRE-REGISTRATION network-initiated handoff for source and target triggers.
表1に記載されているように、事前登録ハンドオフは、ターゲット・トリガによりソーストリガによって又は新FAに旧FAで開始することができます。図2及び図3は、トリガソースおよびターゲットのための事前登録のネットワーク開始のハンドオフのためのメッセージのタイミング図を含みます。
A source-triggered, network-initiated handoff occurs when an L2 trigger is received at the oFA informing it of a certain MN's upcoming movement from oFA to nFA. The L2 trigger contains information including the MN's identifier (i.e., the IPv4 address itself or an identifier that can be resolved to the IPv4 address) and the nFA's identifier. An identifier may be an IPv4 address or something specific to the wireless technology (e.g., Base Station or Access Point Identifier). A target-triggered, network-initiated handoff occurs when an L2 trigger is received at the nFA informing it of a certain MN's upcoming movement from oFA. This type of trigger is also shown in Table 1 and contains information including the MN's and the oFA's identifier.
L2トリガが新FAへ旧FAから特定のMNの今後の動きをそれに知らせる旧FAで受信されるときに、ソーストリガ、ネットワーク開始のハンドオフが生じます。 L2トリガはMNの識別子（すなわち、IPv4アドレス自体またはIPv4アドレスに解決することができる識別子）と新FAの識別子を含む情報を含みます。識別子は、IPv4アドレスまたは無線技術（例えば、基地局またはアクセスポイント識別子）に固有のものであってもよいです。 L2トリガが旧FAから特定のMNの今後の動きのそれを知らせる新FAで受信されたときに目標トリガ、ネットワーク開始のハンドオフが生じます。このタイプのトリガーは、表1に示され、MNのと旧FAの識別子を含む情報を含んでいます。
MN oFA nFA HA/GFA
| |<~~~~~~ L2-Source | |
| | Trigger | |
|<--------------------| | |
| PrRtAdv | | |
| | | |
|---------------------------------------->| |
| RegReq or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
Figure 2 - PRE-REGISTRATION Handoff Message Timing Diagram
(Network-Initiated, Source Trigger)
In a source-triggered handoff, when oFA receives the trigger (L2-ST), it MUST send message 2b, the Proxy Router Advertisement (PrRtAdv), to the MN. The PrRtAdv is nFA's Agent Advertisement [1] with one of the link-layer extensions described in Section 9. The use of the contents of this extension is described in Section 3.7. Messages 1a and 1b SHOULD be exchanged by oFA and nFA before the L2 trigger is received (see Section 3.4.1). Message 2a is not used.
旧FAは、トリガ（L2-ST）を受信すると、ソーストリガハンドオフにおいては、MNに、メッセージ2B、プロキシルータ広告（代理ルータ広告）を送信しなければなりません。代理ルータ広告は、セクション9この拡張の内容の使用で説明したリンクレイヤの拡張機能の一つで、[1]新FAのエージェント広告は、3.7節で説明されています。 L2トリガが受信される前にメッセージ1a及び1bは、（セクション3.4.1参照）旧FAと新FAによって交換されるべきです。メッセージ2aは使用されません。
MN oFA nFA HA/GFA
| | L2-Target~~~~~~~~>| |
| | Trigger | |
| |...................| |
|<--------------------------------------- | |
| (PrRtAdv) |...................| |
| | Tunneled Agent Advertisement |
| | | |
|---------------------------------------->| |
| RegReq. or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram
(Network-Initiated, Target Trigger)
In a target-triggered handoff, when nFA receives the trigger (L2-TT), it MUST tunnel an Agent Advertisement to the MN through oFA to initiate the L3 handoff. The inner advertisement is unicast by nFA to MN, thus nFA treats the target trigger as a Router (Agent) Solicitation. This advertisement is tunneled to oFA, which functions as a normal router, decapsulating the advertisement and forwarding it to the MN. This message MUST be authenticated to prevent attacks (see Section 3.4.2).
新FAトリガ（L2-TT）を受信すると、ターゲットトリガハンドオフでは、それは旧FAを介してMNへトンネルエージェント広告L3ハンドオフを開始する必要があります。内広告は、このように新FAルータ（エージェント）勧誘としてターゲットトリガを扱い、MNに新FAによってユニキャストです。この広告は、広告をデカプセル化し、MNに転送、通常のルータとして機能旧FAにトンネリングされます。このメッセージは、（3.4.2項を参照）攻撃を防ぐために認証されなければなりません。
As shown in Table 1, a mobile-initiated handoff occurs when an L2 trigger is received at the MN informing that it will shortly move to nFA. The L2 trigger contains information such as the nFA's identifier (i.e., nFA's IPv4 address or an identifier that can be resolved to the nFA's IPv4 address). As an example, a Wireless LAN MN may perform a scan to obtain the Base Station Identifier (BSSID) of the access point that is a potential handoff target (i.e., its signal is becoming stronger). The message timing diagram is shown in Figure 4.
表1に示すように、L2トリガが、それはすぐに新FAへ移動することを知らせるMNで受信された場合、移動開始ハンドオフが生じます。 L2トリガは、新FAの識別子（すなわち、新FAのIPv4アドレスまたは新FAのIPv4アドレスに解決することができる識別子）等の情報が含まれています。一例として、無線LAN MNは、潜在的なハンドオフターゲット（すなわち、その信号が強くなってきている）であるアクセスポイントの基地局識別子（BSSID）を得るためにスキャンを実行することができます。メッセージのタイミング図は図4に示されています。
MN oFA nFA HA/GFA
|<~~~~~ L2-Trigger | | |
| | | |
|-------------------->| | |
| PrRtSol | | |
| | | |
|<--------------------| | |
| PrRtAdv | | |
| | | |
|---------------------------------------->| |
| RegReq or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram
(Mobile-Initiated)
As a consequence of the L2 trigger (L2-MT), the MN MUST send message 1a, the Proxy Router Solicitation (PrRtSol). This message is a unicast Agent Solicitation to oFA for a Proxy Router Advertisement (PrRtAdv). This solicitation MUST have a TTL=1 as in [1]. The Proxy Router Advertisement Solicitation unicast to oFA is an Agent Solicitation with a special extension. The solicitation MUST have an extension containing an FA identifier (i.e., IPv4 address or L2 address contained in an LLA extension, see Section 9) because the MN is soliciting another specific FA's advertisement from the oFA. This specific FA will be the MN's nFA. The identifier is the IPv4 address of the nFA or another identifier that can be used by the oFA to resolve to nFA's IPv4 address. If the identifier is not an IPv4 address, it MAY be specific to the underlying wireless technology, for example, an access point or Base Station Identifier (e.g., WLAN BSSID) that can be mapped by oFA to the nFA IPv4 address as described in Section 3.4.1. The extension containing the identifier is a sub-type of the Generalized Link Layer Address Extension described in Section 9.
L2トリガ（L2-MT）の結果として、MNは、メッセージ1A、プロキシルータ要請（PrRtSol）を送信しなければなりません。このメッセージは、プロキシルータ通知（代理ルータ広告）のために旧FAへのユニキャストエージェント要請です。この要請は、のようにTTL = 1を持たなければならない[1]。旧FAにプロキシルータ通知要請ユニキャストは、特別な拡張子を持つエージェント要請です。 MNは旧FAから別の特定のFAの広告を募集されているため、勧誘がFA識別子を含む拡張機能を持たなければならない（すなわち、IPv4アドレスまたはLLA拡張子に含まれるL2アドレスは、セクション9を参照します）。この特定のFAは、MNの新FAになります。識別子は、新FAのIPv4アドレスまたは新FAのIPv4アドレスに解決するために旧FAで使用することができます別の識別子です。識別子は、IPv4アドレスでない場合、それは、基礎となる無線技術に対して特異的であってもよい、例えば、アクセス・ポイントまたは基地局識別子（例えば、WLANのBSSID）セクションで説明したように新FA IPv4アドレスに旧FAによってマッピングすることができます3.4.1。識別子を含む拡張は、セクション9に記載の一般化リンクレイヤアドレス拡張のサブタイプです。
Two extension sub-types have been defined to contain the nFA's IPv4 address and an access point identifier. They are called the Solicited Agent IPv4 Address Extension and the Access Point
2つの拡張サブタイプが新FAのIPv4アドレスとアクセスポイントの識別子を含むように定義されています。彼らは要請エージェントのIPv4アドレス拡張とアクセスポイントと呼ばれています
Identifier Extension, and are described in Sections 9.5 and 9.6. These two extensions SHOULD NOT be present in the same PrRtSol message.
識別子拡張、およびは、セクション9.5および9.6に記載されています。これらの2つの拡張は、同じPrRtSolメッセージ内に存在すべきではありません。
When oFA receives the PrRtSol message, it MUST reply to the MN with the Proxy Router Advertisement (PrRtAdv, message 2b). The PrRtAdv is simply the Agent Advertisement for the requested nFA, proxied by oFA. In order to expedite the handoff, the actual nFA advertisement SHOULD be cached by the oFA following a previous exchange with nFA, shown in messages 1a and 1b, as specified in Section 3.5. The PrRtAdv message MUST contain the nFA's L2 address (using the LLA extension in Section 9.3). This is further described in Section 3.7.
旧FAはPrRtSolメッセージを受信すると、プロキシルータ広告（代理ルータ広告メッセージ2B）を用いてMNへ返信しなければなりません。代理ルータ広告は、単に旧FAによってプロキシ要求された新FAのためのエージェント広告です。セクション3.5で指定されるようにハンドオフを促進するために、実際のNFA広告は、メッセージ1aおよび1bに示す新FAとの以前の交換は、次の旧FAによってキャッシュされるべきです。代理ルータ広告メッセージは、新FAのL2アドレス（セクション9.3でLLA拡張子を使用して）を含まなければなりません。これは、さらに、3.7節に記述されています。
Since L2 triggers are involved in initiating PRE-REGISTRATION handoff, the trigger timing SHOULD be arranged such that a full L3 PRE-REGISTRATION handoff can complete before the L2 handoff process completes. That is, the L2 handoff should be completed after the MN's registration with the nFA is performed (message 3 in Figure 1). The registration MAY be transmitted in more than one copy (default recommendation: 2) to reduce the probability that it is lost due to errors on the wireless link. This would not apply to reliable wireless links where retransmissions are performed at layer 2 in case of error to guarantee packet delivery.
L2トリガが事前登録ハンドオフの開始に関与しているので、トリガタイミングは、L2ハンドオフ・プロセスが完了する前に完全なL3事前登録ハンドオフを完了することができるように配置する必要があります。新FAとMNの登録が（図1のメッセージ3）が行われた後すなわち、L2ハンドオフが完了しなければならないれます。無線リンク上のエラーのためにそれが失われる可能性を減らすために：登録は複数のコピー（2デフォルトの勧告）に伝送することができます。これは、再送信は、パケットの配信を保証するためにエラーが発生した場合にはレイヤ2で実行されている信頼性の高い無線リンクには適用されません。
A PRE-REGISTRATION handoff in this case requires the MN to receive an Agent Advertisement from the nFA through the old wireless access point. How to achieve this is discussed in the following subsections. Messages exchanged between FAs MUST be authenticated to prevent impersonation attacks. The minimal requirement is that all FAs involved in low-latency handoffs MUST support manual pre-configuration of security associations with other neighboring FAs, involving shared keys and the default algorithms of [1] (see the Security Considerations of this document).
この場合、事前登録のハンドオフは、古い無線アクセスポイントを介して新FAからのエージェント広告を受信するMNが必要です。どのようにこれを達成するために、以下のサブセクションで説明します。 FAの間で交換されるメッセージは、偽装攻撃を防ぐために認証されなければなりません。最小要件は、低遅延ハンドオフに関与する全てのFA（この文書のセキュリティの考慮事項を参照）共有鍵と[1]のデフォルトのアルゴリズムを含む、他の隣接のFAとのセキュリティアソシエーションの手動の事前設定をサポートしなければならないということです。
This applies to the network-initiated source-triggered (L2-ST) and mobile-initiated (L2-MT) cases only. Inter-FA solicitation assumes that oFA has access to the IPv4 address of the nFA. The IPv4 address of nFA is obtained by means of an L2 trigger at oFA in the network-initiated case (see Section 3.2) or by means of the extension to the Proxy Router Solicitation (PrRtSol) from the MN in the mobile-initiated case (see Section 3.3). This extension to the PrRtSol may contain an IPv4 address or another identifier, for example, an identifier of a Wireless Base Station such as the WLAN BSSID. In the latter case, the oFA must implement a mechanism to resolve the Base
これは、ネットワーク開始ソーストリガ（L2-ST）とモバイルで開始さ（L2-MT）の場合のみに適用されます。インターFAの勧誘は、旧FAは新FAのIPv4アドレスへのアクセスを持っていることを前提としています。新FAのIPv4アドレスは、ネットワーク起動の場合には旧FAにおけるL2トリガによって得られる又は移動が開始場合にMNからプロキシルータ要請（PrRtSol）の拡張によって、（（3.2節を参照） ）3.3節を参照してください。 PrRtSolこの拡張は、例えば、IPv4アドレスまたは他の識別子を含んでいてもよく、そのようなWLANのBSSIDの無線基地局の識別子。後者の場合には、旧FAは、Baseを解決するための機構を実装する必要があります
Station Identifier to an IPv4 address. The default mechanism is to use a configured table of neighboring Base Station Identifiers (e.g., BSSID) to FA IPv4 address mappings in each FA. Other automated discovery mechanisms may also be used.
IPv4アドレスへの局識別子。デフォルト機構は、各FAにおけるFA IPv4アドレスマッピングに隣接基地局識別子（例えば、BSSID）の構成表を使用することです。他の自動検出メカニズムを使用することもできます。
If oFA does not cache advertisements (see Section 3.5) once it receives an L2 trigger and obtains the address of the nFA for a specific MN, it MUST send a unicast Agent Solicitation (PrRtSol) to nFA. The nFA replies to the oFA by unicasting an Agent Advertisement with appropriate extensions (PrRtAdv). This method removes the TTL limitation of [1] for Mobile IPv4 messages (i.e., TTL=1 is not applicable here). The TTL limitation cannot be applied since oFA and nFA may be more than one hop away and since it is unnecessary for a secured unicast message. The ICMP solicitations and advertisements MUST be authenticated and integrity protected. These messages MUST be protected using Encapsulating Security Payload (ESP) [10] to prevent attacks (see the Security Considerations section of this document). An FA MUST NOT accept ICMP solicitations or advertisements from sources that are not authenticated.
旧FAがキャッシュ広告（3.5節を参照）をしない場合、それはL2トリガを受信して、特定のMNのための新FAのアドレスを取得したら、それは新FAにユニキャストエージェント要請（PrRtSol）を送らなければなりません。新FAは、適切な拡張子（代理ルータ広告）とエージェント広告をユニキャストによって、旧FAに応答します。この方法は、モバイルIPv4メッセージ（即ち、TTL = 1がここでは適用されない）のための[1]のTTLの制限を除去します。旧FAと新FAは、複数のホップ離れて、それが保護されたユニキャストメッセージには不要であるためであってもよいので、TTLの制限が適用できません。 ICMPの勧誘や広告は、認証と完全性を保護しなければなりません。これらのメッセージは、（この文書のセキュリティについての考慮事項のセクションを参照）攻撃を防ぐためにカプセル化セキュリティペイロード（ESP）[10]を使用して保護しなければなりません。 FAは、認証されていないソースからのICMPの勧誘または広告を受け入れてはいけません。
As a practical matter, oFA SHOULD pre-solicit and cache advertisements from known neighboring FAs (see section 3.5) to avoid performing the solicitation during an actual handoff procedure.
実際問題として、旧FAは、予め求めるべきであり、既知の近隣のFA（セクション3.5を参照）からのキャッシュ広告は実際のハンドオフ手順中に勧誘を行うことを回避します。
This applies to the network-initiated target-triggered (L2-TT) case only. Following a target trigger (L2-TT) the nFA MUST send a tunneled Agent Advertisement to the MN through oFA. Tunneling nFA advertisements assumes that the nFA is aware of the IPv4 address for oFA and the MN. These IPv4 addresses are obtained by means of the FA and MN identifiers contained in an L2 trigger received at nFA in the network-initiated case (see Section 3.2). However, in [1] the TTL must be 1 on Agent Advertisements from the nFA. Therefore, tunneling advertisements is applicable if the TTL limitation of [1] is relaxed. For this purpose, a pre-established security association between oFA and nFA MUST be in place to authenticate this message and relax the TTL limitation. If the implementation requires this, a tunnel SHOULD be configured when the inter-FA security association is established. The tunneled ICMP advertisement MUST be secured using tunnel mode ESP [10] between nFA and oFA. An FA MUST NOT accept tunneled ICMP packets destined to it from sources that are not authenticated.
これは、ネットワークが開始目標トリガ（L2-TT）の場合に適用されます。ターゲット・トリガ（L2-TT）に続き、新FAは、旧FAを通じてMNにトンネルエージェント広告を送らなければなりません。新FA広告をトンネリングすることは、新FAは、旧FAとMNのIPv4アドレスを認識していることを前提としています。これらのIPv4アドレスは、ネットワーク起動の場合に新FAで受信L2トリガに含まれているFAの手段とMN識別子によって得られる（セクション3.2を参照）。しかし、[1] TTLは、新FAからエージェント広告に1でなければなりません。 [1]のTTLの制限が緩和される場合したがって、トンネル広告が適用可能です。この目的のために、旧FAと新FAとの間の予め確立されたセキュリティアソシエーションは、このメッセージを認証し、TTLの制限を緩和する場所になければなりません。実装はこれを必要とする場合インターFAセキュリティアソシエーションが確立されると、トンネルは構成されるべきです。トンネリングICMP広告は、新FAと旧FAとの間のトンネルモードESP [10]を使用して保護されなければなりません。 FAは、認証されていないソースから宛てトンネリングさICMPパケットを受け入れてはいけません。
In the mobile-initiated (L2-MT) case and the network-initiated source-triggered (L2-ST) case, the message exchange 1 in Figure 1 could impose an additional latency on the L3 handoff process if done as part of the handoff procedure. In order to remove this source of latency, the inter-FA Router (Agent) Solicitation and Advertisement exchange SHOULD be performed in advance of handoff. A process SHOULD be in place at the oFA to solicit its neighboring nFAs at a predefined time interval (MIN_SOLICITATION_INTERVAL). This interval SHOULD NOT be set too small to avoid unnecessary consumption of network bandwidth and nFA processing resources. The minimum value of MIN_SOLICITATION_INTERVAL is 1 second. If the FA Challenge/Response mechanism in [7] is used, then the MIN_SOLICITATION_INTERVAL MUST be set to a value smaller then the window of time in which a challenge remains valid so that the nFA challenge does not expire before the MN issues the Registration Request. Therefore, the recommended default value for the MIN_SOLICITATION_INTERVAL in oFA is (0.5 * nFA's CHALLENGE_WINDOW * nFA's Agent Advertisement interval). The CHALLENGE_WINDOW and Agent Advertisement interval are defined in [7] and [1] respectively. The minimum requirement is that the MIN_SOLICITATION_INTERVAL MUST be manually configurable, while possible autoconfiguration mechanisms are outside the scope of this document. To allow advertisement caching in certain implementations and in cases where the nFA advertisement interval is very small, it MAY be necessary for the implementation in nFA to allow different CHALLENGE_WINDOW and Agent Advertisement interval settings for its nFA-oFA interface.
ハンドオフの一部として行われた場合、移動が開始（L2-MT）ケース及びネットワーク開始ソーストリガ（L2-ST）場合には、図1におけるメッセージ交換1は、L3ハンドオフのプロセスの追加待ち時間を課すことができ手順。待ち時間のこのソースを除去するために、インターFAルータ（エージェント）要請と広告交換局は、ハンドオフに先立って行われるべきです。プロセスは、所定の時間間隔（MIN_SOLICITATION_INTERVAL）でその隣接NFASを求めるために旧FAに場所にあるべきです。この間隔は、ネットワーク帯域幅と新FA処理リソースの無駄な消費を避けるためには小さすぎる設定しないでください。 MIN_SOLICITATION_INTERVALの最小値は1秒です。 [7]でFAチャレンジ/レスポンスメカニズムを使用する場合、MIN_SOLICITATION_INTERVALは、MNが登録要求を発行する前に新FAチャレンジの期限が切れないように、課題は依然として有効である時間の窓より小さい値に設定する必要があります。そのため、旧FAでMIN_SOLICITATION_INTERVALのための推奨されるデフォルト値は（0.5 *新FAのCHALLENGE_WINDOW *新FAのエージェント広告間隔）です。 CHALLENGE_WINDOW及びエージェント広告間隔で定義されている[7]と[1]は、それぞれ。最小要件は、可能な自動メカニズムはこの文書の範囲外であるがMIN_SOLICITATION_INTERVALは、手動で設定しなければならないことです。特定の実装で広告キャッシュを可能にし、新FA広告間隔が非常に小さい場合には、それはその新FA-旧FAインターフェイスに異なるCHALLENGE_WINDOWとエージェント広告間隔の設定を可能にするために、新FAに実装するために必要な場合があります。
The oFA SHOULD cache the most recent advertisement from its neighboring nFAs. This advertisement MUST be sent to the MN in message 2b with a TTL=1. The oFA SHOULD also have a mechanism in place to create a list of neighboring nFAs. The minimum requirement for each FA is that it SHOULD allow manual configuration of a list of nFA addresses that an MN could possibly perform an L3 handoff to. The FA addresses in this list will depend on deployment and radio coverage. It is also possible to specify another protocol to achieve nFA discovery, but this is outside the scope of this document.
旧FAは、その隣接NFASから最新の広告をキャッシュすべきです。この広告はTTL = 1とメッセージ2bにMNに送信されなければなりません。旧FAはまた、隣接するNFASのリストを作成するための場所でのメカニズムを持っているべきです。各FAの最小要件は、それが新FAのリストの手動設定がMNはおそらくにL3ハンドオフを行うことができることに対処可能にしなければならないということです。このリスト内のFAアドレスが展開し、無線カバレッジに依存します。新FAの発見を達成するために別のプロトコルを指定することも可能ですが、これはこの文書の範囲外です。
When the MN receives an Agent Advertisement with a Mobility Agent extension, it performs actions according to the following movement detection mechanism: the MN SHOULD be "Eager" to perform new bindings. This means that the MN SHOULD perform registrations with any new FA from which it receives an advertisement (i.e., MN is Eager), as long as there are no locally-defined policies in the MN that discourage the use of the discovered FA. For example, the MN could have a policy based on the cost of service. The method by which the MN determines whether the FA is a new FA is described in [1] and MAY use an FA-NAI extension [11]. By being "Eager" to perform registrations, the MN reduces latency times.
MNは、モビリティエージェントの拡張子を持つエージェント広告を受信すると、次の動き検出メカニズムに応じたアクションを実行します。MNは、新たなバインディングを実行するために「イーガー」であるべきです。これは、MNは限り発見FAの使用を思いとどまらミネソタ州ノーローカルに定義されたポリシーがあるとして、それは広告を受け取り、そこから新たなFA（すなわち、MNが熱望している）で登録を行う必要があることを意味します。例えば、MNは、サービスのコストに基づいてポリシーを持つことができます。 MNはFAが新しいFAであるか否かを判断する方法は、[1]に記載されており、FA-NAI拡張[11]を使用するかもしれ。登録を実行するために、「イーガー」であることによって、MNは、待ち時間を短縮します。
The MN also needs to change its default router from oFA to nFA. The MN MUST change its default router to nFA as soon as the PRE-REGISTRATION procedure has completed (i.e., Registration Reply is received by MN) as described in [1].
MNはまた、旧FAから新FAへのデフォルトルータを変更する必要があります。事前登録手順が完了したように記載されているようにMN（すなわち、登録応答は、MNによって受信される）とすぐに新FAへのデフォルト・ルータを変更しなければならない[1]。
Overall, the MN behaves as described in [1] with the following changes: the specified movement detection mechanism mentioned above and the ability to use the L2-MT to initiate an Agent Solicitation with a special extension (PrRtSol). Also, when the MN receives an L2-LU trigger (i.e., new interface or link is up), it MUST immediately send an Agent Solicitation [1] on that interface. An nFA that receives an Agent Solicitation [1] will use it as an L2-LU trigger event, and according to [1] it will record the MN's IPv4/layer 2 addresses (i.e., the Address Resolution Protocol (ARP) entry). At that point, the nFA starts delivering data to the MN including the previously buffered Registration Reply. The nFA MAY also use other L2 mechanisms to detect earlier that the MN has attached to the new link and to start forwarding data to it. The MN SHOULD NOT attempt to retransmit a low-latency Registration Request (i.e., Registration Request containing an LLA extension described in Section 9.) when it does not receive the Registration Reply.
全体として、MNは、に記載されているように振る舞う[1]以下の変更を有する：上記指定された動き検出機構及び特殊拡張（PrRtSol）とエージェント要請を開始するためにL2-MTを使用する能力。 MN（すなわち、新しいインターフェイスまたはリンクがアップしている）、L2-LUトリガを受信した場合にも、それは直ちにそのインターフェイスの[1]エージェント要請を送信しなければなりません。エージェント要請を受信新FA [1] L2-LUトリガイベントとして使用し、上記[1]それはMNのIPv4 /レイヤ2つのアドレス（すなわち、アドレス解決プロトコル（ARP）エントリ）を記録します。その時点で、新FAは、以前にバッファリング登録応答を含むMNにデータを配信開始します。新FAはまた、MNが新しいリンクに接続しており、そこにデータを転送を開始することを早く検出するために、他のL2メカニズムを使用するかもしれません。 MNは、低遅延登録要求を再送信するように試みるべきではありません（すなわち、第9節で説明LLA拡張を含む登録要求）が登録応答を受信しないとき。
When moving from a PRE-REGISTRATION network to a normal Mobile IPv4 [1] network, the MN will no longer receive PrRtAdv messages (i.e., Agent Advertisements with the LLA extension). If the MN still receives L2-MTs, it will attempt to send PrRtSol messages. The normal FA will reply with a normal Agent Advertisement [1]. If the MN does not receive a PrRtAdv in reply to its PrRtSol, it MAY retransmit the PrRtSol message once after PRE_SOL_INTERVAL seconds and then for another PRE_SOL_ATTEMPTS times with exponential backoff of the transmission interval. If a PrRtAdv is not received within PRE_SOL_INTERVAL seconds after the last PrRtSol attempt, the MN MUST stop sending PrRtSol messages until after a registration with a new FA is performed. The default value for PRE_SOL_ATTEMPTS is 2, and for PRE_SOL_INTERVAL, it is 1 second. It should be noted that the performance of the movement detection mechanism mandated in PRE-REGISTRATION (i.e., eager to register) may have sub-optimal behaviour in a standard Mobile IPv4 [1] network. Therefore, standard movement detection mechanisms [1] should be used in plain Mobile IPv4 networks. Instead, when the MN moves from a normal Mobile IPv4 [1] network to a PRE-REGISTRATION network, the MN starts receiving L2-MT triggers or PrRtAdv messages. When the MN receives L2-MT triggers or PrRtAdv messages, it SHOULD follow the PRE-REGISTRATION procedure.
通常のモバイルIPv4 [1]ネットワークへの事前登録ネットワークから移動するとき、MNはもはや代理ルータ広告メッセージを受信しないであろう（すなわち、LLA拡張子を持つエージェント広告）。 MNはまだL2-のMTを受信した場合、それはPrRtSolメッセージを送信しようとします。通常のFAは、通常のエージェント広告に返信します[1]。 MNはそのPrRtSolに回答して代理ルータ広告を受信しない場合は、送信間隔の指数バックオフを持つ別のPRE_SOL_ATTEMPTS回に一回PRE_SOL_INTERVAL秒後、その後PrRtSolメッセージを再送信することができます。代理ルータ広告が最後PrRtSol試行後PRE_SOL_INTERVAL秒以内に受信されない場合、MNは、新FAへの登録が行われた後まで、PrRtSolメッセージの送信を停止しなければなりません。 PRE_SOL_ATTEMPTSのデフォルト値は2であり、そしてPRE_SOL_INTERVALために、それは1秒です。事前登録（登録する即ち、熱心）に義務付け動き検出機構の性能は、標準的なモバイルIPv4 [1]ネットワークにおいて、最適挙動を有していてもよいことに留意すべきです。したがって、標準の動き検出機構[1]無地モバイルIPv4ネットワークで使用されるべきです。 MNは、事前登録のネットワークに正常モバイルIPv4 [1]ネットワークから移動した場合、代わりに、MNは、L2-MTトリガまたは代理ルータ広告メッセージの受信を開始します。 MNは、L2-MTのトリガーまたは代理ルータ広告メッセージを受信すると、事前登録の手順に従ってください。
If there is uncertainty as to which mode to choose (e.g., MN receives messages from both PRE-REGISTRATION and normal FAs), the MN decides based on its registration status with the current FA. If the MN already has a valid normal Mobile IPv4 Registration [1] with the advertising FA, it SHOULD give priority to the PRE-REGISTRATION procedure. Otherwise it SHOULD give priority to normal Mobile IPv4 [1] Registration procedure. The MN SHOULD NOT attempt to perform PRE-REGISTRATION and standard Mobile IPv4 [1] Registrations in parallel.
モードを選択するように不確実性が存在する場合、MNは、現在のFAとの登録状況に基づいて決定する（例えば、MNは、事前登録し、通常のFAの両方からメッセージを受信します）。 MNは、すでに有効な通常のモバイルIPv4登録されている場合、[1]広告FAと、それは事前登録手続きを優先すべきです。それ以外の場合は、通常のモバイルIPv4 [1]登録手順に優先度を与えるべきです。 MNは、並列に事前登録し、標準モバイルIPv4 [1]の登録を実行しないでください。
Some special considerations should be taken with respect to the wireless system on which this handoff method is being implemented. Consider an Ethernet-like system such as IEEE 802.11, for example. In PRE-REGISTRATION, the MN is registering with an FA (nFA) that is not its current first-hop router; therefore, the L2 address of the Ethernet frame containing the MN's Registration Request reaching the nFA is not the MN's address. Therefore, the FA MUST NOT use the Ethernet address of the incoming Registration Request as the MN's L2 address as specified in [1]. This applies to the cases where the wireless access points are bridges or routers and independently of whether the FA is implemented in the wireless access points themselves. In this case, the MN's Registration Request (or Regional Registration Request) MUST use an L2 address extension to the registration message. Such an L2 address is either the same L2 address that remains constant as the MN moves, or it is the MN's L2 address at nFA. To communicate its L2 address, the MN includes a Generalized Link Layer and IP Address Extension (see Section 9) with its Registration Request (or Regional Registration Request) message. If this extension is present, the FA MUST use the L2 address contained in the extension to communicate with the MN. If a particular wireless L2 technology has defined a special interface to the wireless network that allows the FA to resolve the mapping between an MN's IPv4 address and its L2 address without the need to use the extension, the L2 address extension contents may be discarded. For the same reasons above, the MN MUST NOT use the source L2 address of the Agent Advertisement message (PrRtAdv) as its default router's L2 address. Therefore, the nFA MUST include a Generalized Link Layer and IP Address Extension (see Section 9.3) with its Agent Advertisement (PrRtAdv) messages.
いくつかの特別な考慮事項は、このハンドオフ方法が実装された無線システムに関連して解釈されるべきです。例えば、IEEE 802.11、イーサネットのようなシステムを考えます。事前登録では、MNは、現在の第1ホップルータはないFA（NFA）に登録されています。そのため、新FAに到達したMNの登録リクエストを含むイーサネットフレームのL2アドレスは、MNのアドレスではありません。 [1]で指定されているようしたがって、FAはMNのL2アドレスとして入ってくる登録要求のイーサネットアドレスを使用してはなりません。これは、無線アクセスポイントは、ブリッジまたはルータであり、独立して、FAは、無線アクセスポイント自体に実装されているかどうかの場合に適用されます。この場合、MNの登録要求（または地域の登録要求）が登録メッセージにL2アドレス拡張を使用しなければなりません。このようなL2アドレスは、MNが移動、またはそれが新FAにMNのL2アドレスであるとして一定のまま同じL2アドレスのいずれかです。そのL2アドレスを通信するには、MNは、その登録要求（または地域のRegistration Request）メッセージを一般化リンクレイヤとIPアドレス拡張（セクション9を参照）が含まれます。この拡張が存在する場合、FAは、MNと通信する拡張に含まれているL2アドレスを使用しなければなりません。特定の無線L2技術は、FAは拡張子を使用することなく、MNのIPv4アドレスとそのL2アドレス間のマッピングを解決することを可能にするワイヤレスネットワークへの特別なインタフェースを定義している場合は、L2アドレス拡張の内容は破棄されることがあります。上記と同じ理由により、MNは、そのデフォルトルータのL2アドレスとしてエージェント広告メッセージ（代理ルータ広告）の元L2アドレスを使用してはなりません。そのため、新FAは、そのエージェント広告（代理ルータ広告）のメッセージで一般化リンクレイヤとIPアドレス拡張（9.3項を参照）を含める必要があります。
The PRE-REGISTRATION handoff method is applicable to scenarios where a period of service disruption due to layer 3 is not acceptable, for example, when performing real-time communications, and therefore where an anticipation of the layer 3 handoff is required. Security for the PRE-REGISTRATION handoff method is based on the same security model as [1] including the use of AAA. A prerequisite for PRE-REGISTRATION is that the FA or MN is able to obtain an L2 trigger informing it of a pending L2 handoff procedure. The target of the L2 handoff is another access point or radio network that is in the coverage area of a new FA. The L2 trigger information may be in the form of identifiers that need to be resolved to IPv4 addresses using methods that may be specific to the wireless network and are not considered here. If, for example, the oFA or MN determines that the IPv4 address of the new FA matches oFA's address, then the PRE-REGISTRATION handoff SHOULD NOT be initiated.
事前登録ハンドオフ方法は、リアルタイム通信を行う際に起因層3へのサービス中断の期間は、例えば、許容されないので、レイヤ3ハンドオフの予想が必要とされるシナリオに適用可能です。事前登録のハンドオフ方法のセキュリティは、[1] AAAの使用を含むと同じセキュリティモデルに基づいています。事前登録のための前提条件は、FAまたはMNが保留L2ハンドオフ手順のそれを知らせるL2トリガを得ることができるということです。 L2ハンドオフの目標は、新しいFAのカバレッジエリア内にある別のアクセスポイントまたは無線ネットワークです。 L2トリガ情報は、無線ネットワークに特有であってもよく、ここでは考慮されない方法を使用してIPv4アドレスに解決する必要のある識別子の形態であってもよいです。例えば、旧FAまたはMNが新しいFAのIPv4アドレスが旧FAのアドレスが一致すると判断した場合には、事前登録ハンドオフが開始されるべきではありません。
The L2 trigger must allow enough time for the PRE-REGISTRATION handoff procedure to be performed. In many wireless L2 technologies, the L2 handoff procedure involves a number of message exchanges before the effective L2 handoff is performed. For such technologies, PRE-REGISTRATION handoff can be initiated at the beginning of the L2 handoff procedure and completed before the L2 handoff is completed. It is efficient to engineer the network such that this succession of events is ensured.
L2トリガーは事前登録ハンドオフ手順を実行するのに十分な時間をかけなければなりません。有効なL2ハンドオフが実行される前に多くの無線L2技術では、L2ハンドオフ手順は、メッセージ交換の数を含みます。このような技術については、事前登録のハンドオフは、L2ハンドオフ手順の初めに開始され、L2ハンドオフが完了する前に完了することができます。このイベントの連続性が確保されるようにネットワークを設計することが効率的です。
The PRE-REGISTRATION handoff method is applicable in the following cases:
事前登録のハンドオフ方法は、次の場合に適用されます。
- when the MN has locally defined policies that determine a preference for one access over another, for example, due to service cost within the same or different technology, and therefore where it is necessary to allow the MN to select the appropriate FA with which to connect.
- MNは、ローカルに起因し、同一または異なる技術内のサービス費用に、例えば、別の上で1回のアクセスのための優先度を決定し、したがって、それが必要である場合は、MNは、適切なFAれるのを選択することを可能にするポリシーを定義したとき接続します。
- when L2 security between the MN and the FA is either not present or cannot be relied upon to provide adequate security.
- MNとFAとの間のL2セキュリティがないか存在しているか、十分なセキュリティを提供するために頼ることはできません。
- when the trigger to initiate the handoff is received at the MN.
- ハンドオフを開始する際にトリガーがMNで受信されます。
In the first case, it is necessary to involve eventual local MN policies in the movement detection procedure as described in Section 3.6.
最初の場合には、第3.6節で説明したように動き検出手順で最終的なローカルMNポリシーを含むことが必要です。
The POST-REGISTRATION handoff method uses bidirectional edge tunnels (BETs) or unidirectional tunnels to perform low-latency change in the L2 point of attachment for the MN without requiring any involvement by the MN. Figure 5 illustrates the basic POST-REGISTRATION handoff.
POST登録ハンドオフ方法は、MNによって任意の関与を必要とすることなく、MNのためのアタッチメントのL2点における低遅延の変化を実行するために、双方向エッジトンネル（ベット）又は一方向トンネルを使用します。図5は、基本的なレジ後ハンドオフを示します。
+------+
| CN |
+------+
|
...
|
+------+ BET +------+
| aFA |==========| nFA |
+------+ +------+
| wireless link
|
movement +------+
---------> | MN |
+------+
Figure 5 - POST-REGISTRATION Concept
図5 - 登録後コンセプト
Following a successful Mobile IPv4 Registration between MN and oFA, the oFA becomes the mobility anchor point for the MN, called the anchor FA (aFA). When the MN moves from oFA to nFA, rather than performing signaling over the wireless link to register with the nFA, the MN can defer the L3 handoff and continue to use its aFA (i.e., oFA in this case). If the MN moves to a third FA before registering with the nFA, in certain cases described later, the third FA signals aFA to move the wireless link end of the BET from nFA to it. The network end of the BET remains anchored at aFA until the MN performs the Mobile IPv4 Registration.
MNと旧FAとの間に成功したモバイルIPv4登録に続き、旧FAは、MNのモビリティアンカーポイントとなり、アンカーFA（AFA）と呼ばれます。 MNはむしろ新FAに登録するために、無線リンクを介してシグナリングを実行するよりも、新FAと旧FAから移動するとき、MNはL3ハンドオフを延期し、そのAFA（この場合、すなわち、旧FA）を使用し続けることができます。 MNは、新FAに登録する前に、第三のFAへ移動する場合、後述する特定の場合において、第三のFAは、それに新FAからBETの無線リンク端を移動させるAFAに信号を送ります。 MNは、モバイルIPv4登録を行うまで、BETのネットワーク側は、AFAに固定されたままです。
Messages between oFA/aFA and nFA MUST be authenticated. The minimal requirement is that all FAs involved in low-latency handoffs MUST support manual pre-configuration of security associations with other neighboring FAs, involving shared keys and the default algorithms of [1]. POST-REGISTRATION FAs MUST implement the inter-FA authentication extension (FA-FA authentication extension) specified in [11] and MAY additionally use other security mechanisms.
旧FA / AFAと新FAとの間のメッセージを認証する必要があります。最小要件は、低遅延ハンドオフに関与するすべてのFAを共有キーおよび[1]のデフォルトのアルゴリズムを含む、他の隣接のFAとのセキュリティアソシエーションの手動の事前設定をサポートしなければならないということです。レジ後のFAは、インターFA認証拡張（FA-FA認証拡張）[11]で指定され、さらに他のセキュリティ・メカニズムを使用するかもしれを実装しなければなりません。
Two-party handoff occurs when the MN moves from oFA to nFA. Normally, this movement would result in a new Mobile IPv4 Registration at nFA. However, in POST-REGISTRATION, the MN and nFA MAY delay this but maintain connectivity using the BET (or alternatively unidirectional tunnel) between oFA and nFA. The protocol is shown in Figure 6.
MNは、新FAに旧FAから移動したときに二者のハンドオフが発生します。通常、この動きは、新FAに新しいモバイルIPv4登録につながります。しかし、後登録で、MNと新FAは、この遅延が、旧FAと新FAとの間のBET（あるいは一方向トンネル）を使用して接続を維持することができます。プロトコルは、図6に示されています。
1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT
| oFA |<-------->| nFA |
4a) L2-LD~> +------+ 3) HRply +------+ <~~~ 4b) L2-LU
^ ^
old L2 | | new L2
+-------+ +-----+
| |
| |
V V
+------+ movement
4c) L2-LU ---> | MN | --------->
+------+
Figure 6 - Two-Party Handoff (POST-REGISTRATION)
図6 - 2党ハンドオフ（登録後）
The following describes the progress of a two-party handoff. The numbered items refer to steps in Figure 6. The source-triggered HRqst/HRply message for tunnel creation, the target-triggered HRqst/HRply message for tunnel creation, and the HRqst/HRply to extend or terminate a BET (or unidirectional tunnel) are identified using the suffixes (s), (t), and (r), respectively.
以下は、二大政党のハンドオフの進捗状況を説明しています。番号付き項目は、図6のトンネルを作成するためのソーストリガHRqst / HRplyメッセージ、BET（又は一方向トンネル）を延長または終了するトンネル生成のためのターゲットトリガHRqst / HRplyメッセージ、及びHRqst / HRplyの手順を参照しますそれぞれ、サフィックス（S）、（T）、及び（R）を使用して同定されます。
1) Either the oFA or nFA receives an L2 trigger informing it that a certain MN is about to move from oFA to nFA. The two cases are:
1）旧FA又は新FAのいずれかが特定のMNが新FAに旧FAから移動しようとしていることを知らせるL2トリガを受信します。 2例は以下のとおりです。
a) The L2 trigger is a source trigger (L2-ST) at oFA. The trigger contains the MN's L2 address and an identifier for the nFA (the IPv4 address itself or an L2 address that can be resolved to the IPv4 address of the nFA).
A）L2トリガが旧FAのソーストリガ（L2-ST）です。トリガは、MNのL2アドレスと新FA（IPv4アドレス自体または新FAのIPv4アドレスに解決することができるL2アドレス）のための識別子を含みます。
b) The L2 trigger is a target trigger (L2-TT) at nFA. The trigger contains the MN's L2 address and an identifier for the oFA (the IPv4 address itself or an L2 address that can be resolved to the IPv4 address of the oFA).
B）L2トリガが新FAの目標トリガ（L2-TT）です。トリガは、MNのL2アドレスと旧FA（IPv4アドレス自体または旧FAのIPv4アドレスに解決することができるL2アドレス）のための識別子を含みます。
2) The FA receiving the trigger sends a Handoff Request (HRqst) to the other FA. There are two cases: a) If oFA is sending the HRqst, the H bit is set and the N bit is unset, indicating it is an HRqst(s). The HRqst(s) contains the lifetime of the tunnel the oFA is willing to support, the MN's IPv4 home address, the MN's HA address, and an LLA option with the MN's L2 address. If the lifetime is zero and the T bit is not set, the oFA is not willing to tunnel any packets for MN. A positive lifetime and a set T bit indicate that the oFA is willing to tunnel for the indicated time. Section 4.5 describes the HRqst(s) and Section 9 describes the LLA option.
2）トリガを受信FAは、他のFAへのハンドオフ要求（HRqst）を送信します。 2つのケースがある：a）は旧FAは、HRqstを送信しているHビットがセットされ、Nビットが設定されていないが、それはHRqst（S）であることを示す場合。 HRqst（複数可）旧FAは、MNのIPv4ホーム・アドレス、MNのHAアドレス、MNのL2アドレスでLLAオプションをサポートしていく所存ですトンネルの寿命が含まれています。寿命がゼロであり、Tビットが設定されていない場合、旧FAは、MNのための任意のパケットトンネルに望んでいません。正の寿命と集合Tビットは、旧FAは、示された時間のためにトンネルする意思があることを示しています。 4.5節はHRqst（複数可）を説明し、第9節は、LLAオプションを説明します。
b) If nFA is sending the HRqst, the N bit is set and the H bit is unset, indicating that it is an HRqst(t). If the T bit is set, nFA has requested a reverse tunnel and the HRqst(t) contains the lifetime of the tunnel the nFA is requesting. The HRqst(t) also contains an LLA option with the MN's L2 address. The MN's IPv4 home address and HA address are not sent, unless they are discovered by some means outside the scope of this document (for example, as part of the L2-TT). Section 4.5 describes the HRqst(t).
B）新FAは、HRqstを送信しているNビットがセットされ、Hビットが設定されていないが、それはHRqst（T）であることを示す場合。 Tビットが設定されている場合、新FAは、リバーストンネルを要求しているとHRqst（t）は、新FAが要求しているトンネルの寿命を含有します。 HRqst（t）はまた、MNのL2アドレスでLLAオプションが含まれています。それらは（例えば、L2-TTの一部として）この文書の範囲外の何らかの手段によって発見されない限り、MNのIPv4ホームアドレスとHAアドレスは、送信されません。 4.5節はHRqst（t）を記述する。
3) The FA receiving the HRqst sends a Handoff Reply (HRply) to the other FA. There are two cases:
3）HRqstを受信FAは、他のFAへのハンドオフ応答（HRply）を送信します。 2つのケースがあります。
a) If oFA is sending the HRply, the N bit is set and the H and R bits are unset, indicating that the reply is in response to a HRqst(t), i.e., it is an HRply(t). If the T bit is set, the HRply(t) contains the tunnel lifetime the oFA is willing to provide; otherwise, the tunnel lifetime is set to zero indicating that the oFA is not willing to provide tunnel service. If both HRply(t) and HRqst(t) have the T bit set and non-zero lifetime, a BET is established. The HRply(t) also contains the MN's home subnet IPv4 address, the MN's HA address, and an LLA option containing the MN's L2 address. Section 4.6 describes the HRply(t).
旧FAはHRplyを送信している場合a）に示すように、Nビットがセットされ、H及びRビットが解除されている、応答がHRqst（T）に対応していることを示し、すなわち、それは）HRply（Tです。 Tビットが設定されている場合、HRply（t）は、旧FAを提供する意思があるトンネルの寿命を含有します。そうでなければ、トンネル寿命は旧FAトンネルサービスを提供する意思がないことを示すゼロに設定されます。両方HRply（t）とHRqst（t）はTが設定され、非ゼロの寿命ビットがある場合は、BETが確立されます。 HRply（t）はまた、MNのホームサブネットIPv4アドレス、MNのHAアドレス、MNのL2アドレスを含むLLAオプションが含まれています。 4.6節はHRply（t）を記述する。
b) If nFA sends the HRply, the H bit is set and the N and R bits are unset, indicating that this is a response to HRqst(s), i.e., it is an HRply(s). If the T bit is set, the nFA indicates that it requests a reverse tunnel, and the lifetime field is set with the requested tunnel lifetime. The T bit can be set in HRply only if the oFA had set the T bit in the corresponding HRqst or if the nFA is required to reverse tunnel incoming packets to oFA because ingress filtering is enabled on its network. This establishes a BET. The tunnel lifetime requested by the nFA must be less than or equal to the tunnel lifetime offered by oFA in the HRqst(s). Section 4.6 describes the HRply(s).
新FAがHRplyを送信した場合b）に示すように、Hビットがセットされ、NとRビットが解除され、これはHRqst（S）に対する応答であることを示している、すなわち、それはHRply（S）です。 Tビットが設定されている場合、新FAは、リバーストンネルを要求することを示し、寿命フィールドは、要求されたトンネルの寿命が設定されています。 Tビットは、旧FAは、対応するHRqstにTビットを設定していたか、イングレスフィルタリングは、そのネットワーク上で有効になっているため、新FAは、旧FAにトンネル着信パケットを反転する必要がある場合にのみ、HRplyに設定することができます。これは、BETを確立します。新FAによって要求されたトンネル寿命はHRqst（S）に旧FAが提供トンネル寿命以下でなければなりません。 4.6節はHRply（複数可）を記述する。
4) The point during the L2 handoff in which the MN is no longer connected on a given link is signaled by an L2-LD trigger at oFA and MN. Completion of L2 handoff is signaled by an L2-LU trigger at nFA and MN. The trigger is handled as follows:
4）MNがもはや所与のリンク上で接続されたL2ハンドオフ中の点は、旧FAとMNでL2-LDトリガによってシグナリングされます。 L2ハンドオフの完了は、新FAとMNでL2-LUトリガによってシグナリングされます。次のようにトリガが処理されます。
a) When oFA receives the L2-LD trigger, it begins forwarding MN-bound packets through the forward tunnel to nFA.
旧FAは、L2-LDトリガを受信すると、A）、それが新FAに転送トンネルを介してMNに結合したパケットの転送を開始します。
b) When the nFA receives the L2-LU trigger, it begins delivering packets tunneled from oFA to MN and forwards outbound packets from MN using normal routing mechanisms or through a reverse tunnel to oFA or HA. The nFA at this point may not yet be the default router of the MN (see Section 4.4); therefore, to receive all outbound packets from the MN the nFA must send a unicast proxy ARP message (used in [1]) to the MN upon receiving an L2-LU trigger. This proxy ARP message is an ARP Reply [5] sent by the nFA on behalf of oFA, therefore supplying the nFA link-layer address in the Sender Hardware Address field and the oFA IPv4 address in the Target Protocol Address field.
新FAは、L2-LUトリガを受信すると、B）は、通常のルーティングメカニズムを使用するか、旧FA又はHAへのリバーストンネルを介してMNからMNへ旧FAからトンネルパケット及び転送アウトバウンドパケットを配信開始します。この時点で新FAはまだMNのデフォルトルータではないかもしれない（4.4節を参照）。従って、ユニキャストプロキシARPメッセージを送信しなければならないMN新FAからのすべてのアウトバウンドパケットを受信する（で使用される[1]）L2-LUトリガを受信すると、MNへ。このプロキシARPメッセージは、ARP [5]したがって、送信者ハードウェアアドレスフィールドに新FAリンク層アドレスとターゲットプロトコルアドレスフィールドに、旧FA IPv4アドレスを供給し、旧FAの代わりに新FAによって送信された応答です。
c) When the MN receives the L2-LU, it MAY initiate the Mobile IPv4 Registration process by soliciting an Agent Advertisement as described in [1]. If the registration is successful, the nFA takes over the role of anchor FA (aFA) from the oFA. Alternatively, the MN MAY defer the Mobile IPv4 Registration (see Section 4.4).
MNは、L2-LUを受信すると、C）は、[1]に記載のようにエージェント広告を募集することによりモバイルIPv4登録プロセスを開始することができます。登録が成功した場合、新FAは、旧FAからアンカーFA（AFA）の役割を引き継ぎます。また、MNは、モバイルIPv4登録（セクション4.4を参照）を延期するかもしれません。
5) The oFA becomes an aFA if the MN moves to a third FA before having performed a Mobile IPv4 Registration with nFA.
MNは、新FAとモバイルIPv4登録を行った前に、第三のFAへ移動した場合5）旧FAは、AFAなります。
6) Should L2 handoff fail in Step 4 (due to L2 reasons) and a ping-pong situation arise, the oFA may be able to determine this case through the trigger mechanism (i.e., FA sees successive L2-ST/L2-TT followed by L2-LD and then L2-LU). The FA that originated the HRqst can in this case cancel the tunnel by sending an HRqst(r) to the other FA with lifetime zero. It will then simply continue delivering packets to MN exactly as if no handoff had been pending. Section 4.5 describes the HRqst(r).
6）L2ハンドオフが原因L2の理由に（ステップ4で障害が発生した場合）とピンポン状況が生じ、旧FAは、（トリガー機構を介してこのケースを決定することができる、すなわち、FAは、連続L2-ST / L2-TTが続く見その後、L2-LDとL2-LU）によります。 HRqst、この場合には寿命がゼロで他のFAにHRqst（r）を送信することによってトンネルをキャンセルすることができ発信FA。それは、単にハンドオフが保留されていなかったかのように正確MNにパケットを提供し続けます。 4.5節はHRqst（r）を記述する。
If the oFA sets the B bit in HRqst/HRply and the nFA has not requested a reverse tunnel by setting the T bit, the nFA SHOULD tunnel outgoing packets from the MN to the HA because the MN has requested this service from the oFA. The nFA SHOULD offer this service only if no security between the nFA and the MN's HA is required, or if there is an existing nFA-HA security association.
旧FAが設定した場合、MNは旧FAからこのサービスを要求したためHRqst / HRplyと新FAのBビットは、MNからHAへの発信パケットは、Tビットを設定することにより、新FA SHOULDトンネルをリバーストンネルを要求していません。新FAとMNのHAとの間にはセキュリティが必要とされない場合にのみ、新FAは、このサービスを提供する必要があり、または既存の新FA-HAセキュリティアソシエーションが存在する場合。
The actual timing of BET or unidirectional tunnel placement depends on the available L2 triggers. The forward tunnel from oFA to nFA is constructed using one of the tunneling procedures described in [1] for the HA to FA tunnel with the difference that the ends of the tunnel are at the oFA and nFA, respectively. The reverse tunnel from nFA to oFA is constructed as described in [3] with the difference that the network end of the tunnel is at the oFA instead of the HA. If both forward and reverse tunnels are established, then a BET has been established. With optimal L2 trigger information, as described above, the FAs can set up the BET immediately when the L2 handoff is initiated, start tunneling MN-bound data when the link to the MN goes down, and the nFA can use the link-up trigger to start delivering packets. In the absence of optimal L2 trigger information, the HRply can act as the trigger to start tunneling MN-bound data, but in this case, the period of packet delivery disruption to the MN could still be present and additional measures may be required to provide uninterrupted service. Particular implementation and deployment scenarios could require techniques to smooth the handoff by providing a means to convey packets arriving during the L2 handoff. The exact techniques are outside the scope of this document.
BET又は一方向トンネルの配置の実際のタイミングは、利用可能なL2トリガに依存します。旧FAから新FAに転送トンネルは、トンネルの両端は、それぞれ、旧FAと新FAであるという点は相違させて、FAトンネルにHA [1]に記載のトンネリング手順のいずれかを用いて構成されています。記載のように新FAから旧FAへの逆方向トンネルが構築されている[3]トンネルのネットワーク側は、旧FAの代わりにHAであること差。両方のフォワードおよびリバーストンネルが確立されている場合には、BETが確立されています。最適なL2トリガー情報により、前述したように、FASが、L2ハンドオフが開始されたときに、すぐにBETを設定MNへのリンクがダウンしたときのトンネルMN-バインドされたデータを開始し、新FAは、リンクアップトリガーを使用することができますすることができますパケットの配信を開始します。最適L2トリガー情報の非存在下で、HRplyはトンネルMN結合データを開始するトリガーとして機能することができ、この場合には、MNへのパケット配信中断の期間は依然として存在し、追加の対策が提供することが要求されてもよいことができ中断のないサービス。特定の実装および展開シナリオは、L2ハンドオフ中に到着したパケットを伝えるための手段を提供することにより、ハンドオフを滑らかにする技術を必要とする可能性があります。正確な技術は、この文書の範囲外です。
Figures 7 and 8 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) two-party handoffs, respectively.
ソーストリガ（L2-ST）及びターゲット・トリガ（L2-TT）二者間ハンドオフのための図7および図8のタイミング図。
MN nFA oFA
| | |
| | HRqst(s) |<~~~ L2-ST
| |<------------------|
| | HRply(s) |
| |------------------>|
| | |
--------------------------------------------<~~~ L2-LD
L2 Handoff
--------------------------------------------<~~~ L2-LU
| | |
|<------------------->| |
| MN's traffic | |
Figure 7 - Two-Party Source Trigger Handoff Timing
図7 - 2党ソーストリガハンドオフのタイミング
MN nFA oFA
| | |
| L2-TT ~~~>| HRqst(t) |
| |------------------>|
| | HRply(t) |
| |<------------------|
| | |
--------------------------------------------<~~~ L2-LD
L2 Handoff
--------------------------------------------<~~~ L2-LU
| | |
|<------------------->| |
| MN's traffic | |
Figure 8 - Two-Party Target Trigger Handoff Timing
図8 - 二・パーティ・ターゲットトリガーハンドオフのタイミング
Once the tunnel between aFA and the current FA is in place, it is torn down by one of the following events:
AFAと現在のFAとの間のトンネルが適所にあると、それは次のイベントのいずれかによって取り壊されます。
1) The aFA decides to stop tunneling because the lifetime it sent expires and was not renewed, or the aFA or current FA decide to terminate tunnel service prematurely for some other reason (refer to Section 4.3).
1）AFAは、それが送信された寿命が満了し、更新されなかった、またはAFAまたは現在のFAが他の理由（4.3節参照）のための早期のトンネルサービスを終了することを決定するためのトンネルを停止することを決定します。
2) The MN completes the process by performing a Mobile IPv4 Registration with the current FA. This may be initiated by the FA that sends an Agent Advertisement or by the MN that solicits for an Agent Advertisement as in [1].
2）MNは、現在のFAでモバイルIPv4登録を行うことにより、処理を終了します。これは、エージェント広告を送信FAによって、または、[1]のようにエージェント広告のための勧誘MNによって開始することができます。
3) The MN moves to a third FA (see Section 4.2)
3）MNは、第三のFAへ移動する（セクション4.2を参照）
Three-party handoff is applicable when an MN, which has already established an aFA and is receiving tunneled packets through its current FA, moves to a new FA without performing a Mobile IPv4 Registration.
すでにAFAを確立しており、その現在のFAを介してトンネリングパケットを受信しているMNは、モバイルIPv4登録を行うことなく、新しいFAに移動したとき。三者のハンドオフが適用されます
The need for the three-party handoff function depends on the wireless system in which POST-REGISTRATION is being implemented. For radio L2 protocols in which it is possible for the MN to move so rapidly from one FA to another such that a probability exists that the Mobile IPv4 Registration with nFA will not complete before the MN moves on, HTT (Handoff to Third) SHOULD be implemented. Certain wireless systems and implementations do not allow such fast movement between FAs and may force the Mobile IPv4 Registration to occur soon after L2 handoff, in which case three-party handoff is not applicable. If this three-party handoff feature is not implemented, the FA SHOULD send an Agent Advertisement to the MN after L2 handoff has completed (L2-LU at nFA) and/or the MN SHOULD solicit an Agent Advertisement after L2 handoff (L2-LU at MN).
三者のハンドオフ機能の必要性はPOST-登録が実施されている無線システムに依存します。 MNは、確率は、MNが進む前に、新FAとのモバイルIPv4登録が完了しないことが存在することを別のそのような1つのFAから急速に移動することが可能である無線L2プロトコルは、HTT（第3へのハンドオフ）があるべきです実装されています。特定の無線システムと実装がFAの間、このような高速な動きを可能にしていないと三者のハンドオフが適用されない場合にはL2ハンドオフ、直後に発生するモバイルIPv4登録を強制することがあります。この三者のハンドオフ機能が実装されていない場合はL2ハンドオフが完了した後、FAは（NFAでL2-LU）MNにエージェント広告を送るべきであるおよび/またはMNは、L2-LU（L2ハンドオフ後にエージェント広告を求めるべきですMNで）。
+------+
+--->| aFA |<---+
| +------+ |
4b) HRqst(r) | | 3) HRqst(t)
HRply(r) | | HRply(t)
| |
v 2a) HRqst v
1a) L2-ST ~~~> +------+ HTT +------+ <~~~ 1b) L2-TT
| oFA |<-------->| nFA |
4a) L2-LD ~~~> +------+ 2b) HTT +------+ <~~~ 5a) L2-LU
^ HRply ^
old L2 | | new L2
+-------+ +-----+
| |
| |
V V
+------+ movement
5b) L2-LU ~~~> | MN | --------->
+------+
Figure 9 - Three-Party Handoff
図9 - 三者ハンドオフ
The L3 handoff can be deferred either because of a decision by the MN/FA (i.e., MN does not send Agent Solicitations and FA does not send Agent Advertisements), or it may result from rapid movement between oFA and nFA that does not allow enough time for the registration to complete. This scenario is shown in Figure 9. In this case, oFA must inform nFA (i.e., the third FA) to contact aFA about moving the radio end of the tunnel. This is performed with the HTT message. The general idea behind the three-party handoff procedure is that the oFA supplies nFA with the same information it would have obtained via an L2-TT if handoff had occurred from aFA to nFA; then, the nFA performs an HRqst(t)/HRply(t) sequence with aFA in order to move the BET to nFA. When the L2 handoff is complete, oFA sends an HRqst(r) to aFA to terminate the previous BET.
L3ハンドオフは、/ FA（すなわち、MNはエージェント広告を送信しないエージェント要請及びFAを送信しません）ので、MNによる決定のいずれか延期することができ、またはそれは十分を許可していません旧FAと新FAとの間に急速な動きに起因します登録が完了するまでの時間。このシナリオでは、この場合には図9に示されている、旧FAは、トンネルの無線端を移動についてAFAに接触する新FA（すなわち、第三のFA）を通知しなければなりません。これは、HTTメッセージを用いて行われます。三者のハンドオフ手順の背後にある一般的な考え方は、旧FAがハンドオフがAFAから新FAに発生していた場合、それはL2-TTを介して取得しているのと同じ情報で新FAを提供することです。次いで、新FAは、新FAにBETを移動させるためにAFAとHRqst（T）/ HRply（T）シーケンスを実行します。 L2ハンドオフが完了すると、旧FAは、以前のBETを終了するAFAにHRqst（r）を送信します。
The following describes the progress of a three-party handoff. The numbered items refer to steps in Figure 9.
以下は、三者のハンドオフの進捗状況を説明しています。番号付き項目は、図9の手順を指します。
1) Either the oFA or nFA receives an L2 trigger informing it that a certain MN is about to be moved. The two cases are: a) The L2 trigger is a source trigger (L2-ST) at oFA. The trigger contains the MN's L2 address and an identifier for the nFA (the IPv4 address itself or an L2 address that can be mapped to the IPv4 address of the nFA).
1）旧FA又は新FAのいずれかが特定のMNが移動されようとしていることを知らせるL2トリガを受信します。 2つのケースがある：a）L2トリガが旧FAのソーストリガ（L2-ST）です。トリガは、MNのL2アドレスと新FA（IPv4アドレス自体または新FAのIPv4アドレスにマッピングすることができるL2アドレス）のための識別子を含みます。
b) The L2 trigger is a target trigger (L2-TT) at nFA. The trigger contains the MN's L2 address and an identifier for the oFA (the IPv4 address itself or an L2 address that can be resolved to the IPv4 address of the oFA).
B）L2トリガが新FAの目標トリガ（L2-TT）です。トリガは、MNのL2アドレスと旧FA（IPv4アドレス自体または旧FAのIPv4アドレスに解決することができるL2アドレス）のための識別子を含みます。
2) The oFA and nFA exchange an HTT/HRply or HRqst/HTT pair. HTT is indicated by setting both the H and N bits in the HRqst or HRply. The HTT message MUST NOT have any tunnel flag bits set, because the tunnel is negotiated between the aFA and nFA, not oFA and nFA. There are two cases:
2）旧FAと新FAはHTT / HRply又はHRqst / HTTペアを交換します。 HTTはHRqst又はHRplyにおけるHとNビットの両方を設定することによって示されています。トンネルがない旧FAと新FA、AFAと新FAとの間でネゴシエートされるので、HTTメッセージは、設定されたトンネルのフラグビットを有してはなりません。 2つのケースがあります。
a) The L2 trigger is an L2-ST. The oFA sends HTT to nFA containing the MN's home IPv4 address, the MN's HA address, an LLA containing the aFA's IPv4 address, and an LLA containing the L2 address of the MN. This is enough information for nFA to perform a target-triggered handoff with aFA. The nFA responds with an HRply(s). Section 4.7 describes the HTT.
A）L2トリガがL2-STです。旧FAは新FAは、MNのホームIPv4アドレス、MNのHAアドレス、AFAのIPv4アドレスを含むLLA、およびMNのL2アドレスを含むLLAを含むにHTTを送信します。これは、新FAはAFAで、ターゲット・トリガハンドオフを実行するための十分な情報です。新FAはHRply（S）で応答します。 4.7節ではHTTを説明しています。
b) The L2 trigger is an L2-TT. The nFA sends HRqst(t) to oFA, exactly as if a two-party handoff were occurring. The oFA responds with HTT containing the same information as in a) above. This is enough information for nFA to perform a target-triggered handoff with aFA.
B）L2トリガがL2-TTです。新FAは、二大政党のハンドオフが発生しているかのように、旧FAにHRqst（t）を送信します。旧FAは、HTTは、上記）と同様の情報を含んで応答します。これは、新FAはAFAで、ターゲット・トリガハンドオフを実行するための十分な情報です。
3) Upon receipt of the HTT, the nFA first checks its Visitor Cache to see whether it is already tunneling for MN. If so, Step 6 is performed. If not, nFA performs a target-triggered handoff with aFA, exactly as in Section 4.1, exchanging an HRqst(t)/HRply(t) pair. Because aFA receives no L2 trigger indicating when L2 handoff starts, it may start tunneling to nFA upon transmission of the HRply(t).
3）HTTを受信すると、新FAは、まず、それがすでにMNのためのトンネリングされているかどうかを確認するためにそのビジターキャッシュをチェックします。その場合は、ステップ6が実行されます。そうでない場合、新FAはHRqst（T）/ HRply（T）対を交換する、正確に4.1節と同様に、AFAと目標トリガハンドオフを行います。 AFAは、L2ハンドオフが開始したときを示すないL2トリガを受信しないので、HRply（T）の送信時に新FAへのトンネリングを開始してもよいです。
4) Once the L2 handoff is under way and the MN gets disconnected at L2, aFA and oFA exchange messages canceling tunnel service between aFA and oFA and allowing aFA to start the tunnel with nFA.
4）一旦L2ハンドオフが進行中であり、MNは、AFAと旧FAとの間のトンネルサービスをキャンセルし、AFAは、新FAとのトンネルを開始することを可能L2、AFAと旧FA交換メッセージで切断されます。
a) The point in the L2 handoff process where the MN gets disconnected from oFA is signaled at oFA by L2-LD.
A）MNが旧FAから切断されL2ハンドオフ処理のポイントはL2-LDによって旧FAにシグナリングされます。
b) The oFA exchanges an HRqst(r)/HRply(r) pair having lifetime zero with aFA. This cancels tunnel service between oFA and aFA. If aFA has not already established a tunnel to nFA, it must do so immediately upon receipt of the HRqst(r). The aFA provides tunneling service exactly as described in Section 4.1, Step 4a.
B）のOFA交換HRqst（R）/ HRply（R）ペアはAFAと寿命ゼロを有します。これは、旧FAとAFA間のトンネルサービスをキャンセルします。 AFAは、すでに新FAへのトンネルを確立していない場合は、すぐにHRqst（R）の受信時に行う必要があります。 AFAは、セクション4.1、手順4aで説明どおりにトンネリングサービスを提供しています。
5) Completion of L2 handoff is signaled by an L2-LU trigger at nFA and/or MN. The nFA and MN handle the trigger as follows:
5）L2ハンドオフの完了は、新FA及び/又はMNにL2-LUトリガによってシグナリングされます。次のように新FAとMNは、トリガを処理します。
a) The nFA provides packet delivery service to the MN exactly as described in Section 4.1, Step 4b.
a）は、新FAは、セクション4.1、ステップ4bで説明したとおりにMNへのパケット配信サービスを提供します。
b) The MN either defers or initiates Mobile IPv4 Registration when it receives the L2-LU, as in Section 4.1.
B）MNは、セクション4.1のように、L2-LUを受信するモバイルIPv4登録を延期または開始のいずれか。
6) In the special case where nFA and aFA are the same (i.e., the MN is moving back to the original anchor FA), aFA recognizes that it is tunneling to oFA when it checks its Visitor Cache in Step 3. In this case, there is no need for aFA to send the HRqst(t)/HRply(t) in Step 3. Upon receipt of the L2-LU trigger on handoff completion, the aFA begins routing packets to MN and the tunnel to nFA is torn down. The oFA still exchanges the HRqst(r)/HRply(r) with aFA in Step 4b because oFA cannot know a priori that aFA and nFA are the same, but they are redundant.
6）新FAとAFAが同一である特別な場合（すなわち、MNが元のアンカーFA）、AFAが、この場合には、ステップ3で、そのビジターキャッシュをチェックするとき、それは旧FAにトンネルであることを認識するに移動して、 AFAは、ハンドオフ完了時にL2-LUトリガを受信すると、ステップ3でHRqst（T）/ HRply（t）を送信する必要がない、AFAは、MNにパケットの経路指定を開始し、新FAへトンネルは解体されます。旧FAは、AFAと新FAが同じであることを事前に知ることはできないが、これらは冗長であるので、旧FAは、依然としてステップ4bでAFAとHRqst（R）/ HRply（r）を交換します。
Figures 10 and 11 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) three-party handoff, respectively.
それぞれ、ソーストリガ（L2-ST）とターゲット・トリガ（L2-TT）三者ハンドオフ10及び図11に示すタイミング図を図。
MN nFA oFA aFA
| | L2-ST ~~~> | |
| | | |
| |<-------------| |
| | HTT | |
| |------------->| |
| | HRply(s) | |
| |------------------------------>|
| | HRqst(t) | |
| |<------------------------------|
| | HRply(t) | |
| | | |
----------------------------------<~~~ L2-LD |
|--------------->|
L2 Handoff | HRqst(r) |
| |
|<---------------|
| HRply(r) |
| |
----------------------------------<~~~ L2-LU |
| MN's traffic | | |
|<-------------->| | |
Figure 10 - Three-Party Source Trigger Handoff Timing
図10 - 三者ソーストリガハンドオフのタイミング
MN nFA oFA aFA
| | | |
| |<~~~ L2-TT | |
| |------------->| |
| | HRqst(t) | |
| |<-------------| |
| | HTT | |
| |------------------------------>|
| | HRqst(t) | |
| |<------------------------------|
| | HRply(t) | |
| | | |
----------------------------------<~~~ L2-LD |
|--------------->|
L2 Handoff | HRqst(r) |
| |
|<---------------|
| HRply(r) |
| |
----------------------------------<~~~ L2-LU |
| MN's traffic | | |
|<-------------->| | |
Figure 11 - Three-Party Target Trigger Handoff Timing
図11 - 三者ターゲットトリガーハンドオフのタイミング
Unlike two-party handoff, the timing of BET establishment between aFA and nFA cannot fully depend on the availability of L2 trigger information because aFA does not receive an L2 trigger signaling L2 handoff. The two timing extremes at which aFA can place the BET with nFA are:
AFAは、L2ハンドオフをシグナリングL2トリガを受信しないので、二者間ハンドオフとは異なり、AFAと新FAとの間のBET確立のタイミングは完全L2トリガ情報の利用可能性に依存することができません。 AFAは、新FAとBETを配置することができた2つのタイミングの両極端は、次のとおりです。
1) At the earliest, aFA MAY start tunneling packets using the BET to nFA after sending the HRply(t) to nFA in response to the request for target-triggered handoff.
1）最も早い場合で、AFAは目標トリガハンドオフのための要求に応じて新FAにHRply（t）を送信した後、新FAにBETを用いてトンネリングパケットを開始してもよいです。
2) At the latest, aFA MAY start tunneling packets using the BET to nFA and tear down the BET with oFA when receiving the HRqst(r) from oFA indicating that the MN has disconnected.
2）最近では、AFAは、新FAにBETを用いてトンネリングパケットを開始し、MNが切断したことを示す旧FAからHRqst（r）を受信した場合旧FAとのBETを取り壊すMAY。
In addition, aFA MAY continue tunneling to oFA if 1) is selected, until the HRqst(r) is received. In this case, the result may be duplicated packets at the MN because the MN will receive packets through oFA on the old L2 until it disconnects (L2-LD). If 2) is selected, the additional latency will add to the MN's L3 service disruption period. Of course, aFA can choose to place the BET sometime between 1) and 2) if reliable bounds are available on the duration of time between L2-ST/L2-TT and the MN's disconnection (L2- LD). The exact selection of when to establish the BET is likely to be influenced by network engineering and implementation considerations, including whether a handoff smoothing solution is used, and is beyond the scope of this specification.
1）選択された場合HRqst（R）が受信されるまで加え、AFAは、旧FAにトンネルを継続することができます。それは（L2-LD）を切断するまで、MNは古いL2に旧FAを介してパケットを受信することになるので、この場合には、結果は、MNにパケットを複製してもよいです。 2）選択されている場合は、追加の待ち時間は、MNのL3サービス中断期間に追加されます。もちろん、AFAは1の間のいつかBETを配置するように選択することができます）と2）信頼性の境界はL2-ST / L2-TTとMNの断線（L2- LD）の間の時間の長さで利用可能である場合。 BETを確立する際の正確な選択は、ハンドオフの平滑化溶液が使用されているかどうかなど、ネットワークエンジニアリングおよび実装の考慮に影響されやすく、この仕様の範囲を超えています。
To prevent a BET from expiring when its lifetime runs out, the MN's current FA signals the aFA to either renew or terminate the BET. This may be the case when the MN defers Mobile IPv4 Registration. If no such signal is received, the aFA will terminate the BET when the lifetime expires. In addition, the current FA or aFA may need to terminate the BET prior to the lifetime expiring. In order to avoid error conditions in which tunnels do not expire even though the MN to which they apply is no longer reachable, FAs SHOULD set the tunnel lifetime field to some value other that 0xffff, which indicates "good until canceled".
その寿命が尽きたときに期限切れBETを防ぐために、MNの現在のFAは、BETを更新または終了するかAFAを知らせます。これは、MNは、モバイルIPv4登録を延期する場合があり得ます。そのような信号が受信されない場合、寿命が満了したとき、AFAはBETを終了します。加えて、現在のFA又はAFAは生涯切れる前BETを終了する必要があるかもしれません。 MNは、それらがもはや到達可能で適用されないためにもかかわらず、トンネルは有効期限が切れないようなエラー状態を避けるために、FASが「取り消されるまでは良い」を示す0xffffと、他のいくつかの値にトンネル寿命フィールドを設定する必要があります。
Figure 12 illustrates the message exchange that occurs between the FA needing to terminate or extend the tunnel (designated FA(1) in the figure) and the other FA (designated FA(2) in the figure). The HRqst(r)/HRply(r) is indicated by setting the R bit in the HRqst/HRply messages. If the HRqst(r) is renewing a BET, then it contains a non-zero lifetime; otherwise, if the lifetime is set to zero, it indicates tunnel termination. The aFA has complete control over whether a tunnel is extended or terminated, and it MAY reply to a request for extension with a shorter lifetime than was requested.
図12は、FAが終了するか及び（FA（2）図に示される）他のFA（FA（1）図に示される）トンネルを拡張する必要の間で発生するメッセージ交換を示します。 HRqst（r）は/ HRply（R）はHRqst / HRplyメッセージにRビットを設定することによって示されています。 HRqst（r）はBETを更新された場合、それは非ゼロの存続期間を含み、寿命がゼロに設定されている場合はそうでなければ、それはトンネル終端を示します。 AFAは、トンネルが延長または終了しているかどうかを完全に制御を持っており、それが要求されたより短い寿命と拡張のための要求に応答することができます。
HRqst(r)
+------+ <-------- +------+
| FA(2)| ---------> | FA(1)|
+------+ HRply(r) +------+
Figure 12 - BET Renewal or Termination
図12 - BETリニューアルまたは終了
The MN/FA have control over when to perform the Mobile IPv4 Registration. Although the MN/FA may decide to defer Mobile IPv4 Registration for a certain period, three possible events can lead to the need to terminate tunneling service. If this occurs, the MN MUST perform the Mobile IPv4 Registration. These events are:
MN / FAは、モバイルIPv4登録を実行するときを制御することができます。 MN / FAは、一定期間のモバイルIPv4登録を延期することを決定するかもしれないが、三つの可能なイベントは、トンネリングサービスを終了する必要性につながることができます。この問題が発生した場合、MNは、モバイルIPv4登録を実行しなければなりません。これらのイベントは以下のとおりです。
1) The end of life for the BET is pending and a request by the current FA to aFA for renewal has been denied, or alternatively the current FA or aFA needs to terminate the BET prematurely. The FA in this case MUST initiate the Mobile IPv4 Registration by sending an Agent Advertisement to the MN as in [1].
1）BETの生活の端部が保留され、更新のためのAFAに電流FAによって要求が拒否されたか、あるいは現在のFA又はAFAが途中BETを終了する必要があります。この場合、FA [1]のようにMNにエージェント広告を送信することによって、モバイルIPv4登録を開始しなければなりません。
2) The MN itself decides to perform a Mobile IPv4 Registration and initiates it by sending an Agent Solicitation as in [1].
2）MN自身がモバイルIPv4登録を実行することを決定し、[1]のようにエージェント要請を送信することによって、それを開始します。
3) During a source-triggered handoff, the oFA attempts to perform BET handoff but nFA is not capable of performing it. The FA in this case MUST initiate the Mobile IPv4 Registration by sending the MN an Agent Advertisement as in [1]. Note that this situation will never arise during target-triggered handoff because an HRqst(t) will not be sent to oFA by an nFA that doesn't support POST-REGISTRATION.
3）ソーストリガハンドオフ中に、旧FAは、BETハンドオフを実行しようとするが、新FAは、それを行うことができません。この場合、FAは、のようにMNのエージェント広告を送信することによって、モバイルIPv4登録を開始しなければならない[1]。 HRqst（t）はPOST登録をサポートしていない新FAによる旧FAに送信されませんので、このような状況は、ターゲット・トリガ・ハンドオフ中に発生しないことに注意してください。
Some detailed scenarios relating to case 2) will be described hereafter. According to [1], when using an FA care-of address, the MN MAY use the FA as its default router. Otherwise, it MUST choose its default router from those advertised in the ICMP Router Advertisement portion of the Agent Advertisement. Here we assume that the FA router is also the MN's default router. In POST-REGISTRATION, when a tunnel is established between oFA and nFA and the MN has moved to nFA, the oFA MUST NOT send Agent Advertisements to the MN. In this case, it is possible that the MN will not receive Agent Advertisements for extended periods of time. According to [8], hosts will remove default router entries if the lifetime of the Router Advertisement expires and no further advertisements are received. Note that the ICMP Router Advertisement lifetime is not related to the Registration Lifetime in the Mobility Agent Advertisement extension [1]. To avoid this disruption, the MN MUST solicit the default router (i.e., FA) before the lifetime of its active default router entry runs out, or alternatively, the FA MUST advertise as soon as the MN-nFA link is up (L2-LU). This effectively means that the MN will at most be able to defer Mobile IPv4 Registration for as long as the remaining lifetime of the active default router, as configured in the ICMP Router Advertisements. The MN MUST perform a Mobile IPv4 Registration [1] when it receives an Agent Advertisement following a POST-REGISTRATION handoff.
ケース2に関連するいくつかの詳細なシナリオは）以下に説明します。 FAの気付アドレスを使用している場合、[1]によると、MNは、そのデフォルトルータとしてFAを使用するかもしれません。それ以外の場合は、エージェント広告のICMPルータアドバタイズメントの部分に広告を出したものから、そのデフォルトルータを選択する必要があります。ここでは、FAルータもMNのデフォルトルータであることを前提としています。トンネルが新FAへ移動した旧FAと新FAとMNとの間で確立されたときにレジ後に、旧FAは、MNにエージェント広告を送信してはいけません。この場合、MNは、長時間のエージェント広告を受信しない可能性があります。ルータアドバタイズメントのライフタイムが満了し、それ以上の広告が受信されない場合は、[8]によると、ホストはデフォルトルータエントリを削除します。 ICMPルータアドバタイズメントの寿命はモビリティエージェント広告拡張[1]への登録の有効期間に関連していないことに注意してください。そのアクティブなデフォルトルータエントリの寿命が交互になくなる、または前にこの混乱を避けるために、MNは、デフォルトルータ（すなわち、FA）を勧誘しなければならない、FAはすぐMN-新FAリンクがアップしているよう宣伝しなければならない（L2-LU ）。これは、効果的にMNがほとんどでICMPルータ広告で構成されているように、アクティブなデフォルトルータの残りの寿命限り、モバイルIPv4登録を延期することができることを意味します。 MNは、[1]それはPOST登録ハンドオフ、次のエージェント広告を受信したときにモバイルIPv4登録を実行しなければなりません。
This is a new Mobile IPv4 message carried on UDP (destination port 434) [1]. The UDP header is followed by the fields below.
これは、UDP（宛先ポート434）上に担持された新しいモバイルIPv4メッセージである[1]。 UDPヘッダは、以下のフィールドが続きます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |H|N|R|M|G|T|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 16 (Handoff Request)
タイプ16（ハンドオフ要求）
H Source-triggered handoff request. When set and the N bit is unset, indicates that the request was the result of an L2-ST at oFA.
Hソーストリガハンドオフ要求。セットとNビットが設定されていない場合、要求は旧FAでL2-STの結果であったことを示しています。
N Target triggered handoff request. When set and the H bit is unset, indicates that the request was the result of an L2-TT at nFA.
Nターゲットは、ハンドオフ要求を引き起こしました。セットとHビットが設定されていない場合、要求は新FAでL2-TTの結果であったことを示しています。
R Set if the request is an HRqst(r) (i.e., a request to renew the tunnel, H and N bits must be unset).
Rセット要求はHRqst（R）（即ち、トンネル、HおよびNのビットを更新するための要求を解除する必要があります）である場合。
M The FA issuing the HRqst will use Minimal Encapsulation as defined in [1,5] for the tunnel.
MザFAは、トンネルの[1,5]で定義されるようHRqstが最小カプセル化を使用する発行します。
G The FA issuing the HRqst will use Generic Routing Encapsulation (GRE) [4] as defined in [1,5] for the tunnel. Extensions of HRqst containing GRE type and key Fields are outside the scope of this document.
HRqst発行GザFAは、トンネルの総称ルーティングカプセル化（GRE）[4] [1,5]で定義されるように使用されます。 HRqst含むGREタイプとキーフィールドの拡張機能は、この文書の範囲外です。
T For an HRqst(s), indicates that the oFA is willing to support both forward and reverse tunnel service. For an HRqst(t), indicates that the nFA is requesting reverse tunnel service.
HRqst（S）についてTは、旧FAが前方の両方をサポートし、トンネルサービスを逆転する意思があることを示しています。 HRqst（T）のために、新FAは、リバーストンネルサービスを要求していることを示しています。
B When sent in an HRqst(s), indicates that the MN has requested a reverse tunnel to the HA and that the nFA SHOULD use a reverse tunnel to the HA if it will not be reverse tunneling to the oFA.
B HRqst（S）で送信された場合、MNは、HAへのリバーストンネルを要求し、それが旧FAに逆トンネリングしない場合新FAは、HAへ逆方向トンネルを使用するようにしたことを示します。
Lifetime The lifetime of the tunnel in seconds. If this is an HRqst(t), then the lifetime represents a request by nFA for a reverse tunnel. If this is an HRqst(s), then the lifetime represents the maximum amount of time that oFA is willing to maintain both forward and reverse tunnels. If this is an HRqst(r), then the lifetime represents a request for the amount of time to renew the tunnel's lifetime. A value of 0 on an HRqst(s) indicates that the oFA is unwilling to grant tunnel service. A value of 0 on an HRqst(t) indicates that the nFA does not require reverse tunnel service. A value of 0 on an HRqst(r) indicates that the tunnel should be terminated. A value of 0xffff indicates infinity.
生涯秒でトンネルの寿命。これはHRqst（T）である場合には、寿命は、逆方向トンネルの新FAによる要求を表します。これはHRqst（S）である場合には、寿命は旧FAが前方の両方を維持し、トンネルを逆ても構わないと思っている時間の最大量を表します。これはHRqst（R）である場合には、寿命は、トンネルの寿命を更新する時間量に対する要求を表します。 HRqst（S）上の0の値は、旧FAは、トンネルサービスを与えるために不本意であることを示しています。 HRqst（t）に0の値は、新FAは、リバーストンネルサービスを必要としないことを示しています。 HRqst（R）に0の値は、トンネルを終了すべきことを示しています。値0xffffは、無限大を示しています。
MN Home Address For HRqst(s), the home address of the MN.
HRqstについてはMNのホームアドレス（複数可）、MNのホームアドレス。
HA Addr For HRqst(s), the HA address of the mobile node.
HRqstのHA ADDR（S）、移動ノードのHAアドレス。
Identification As defined in [1].
[1]で定義されるように同定。
Extensions The message MUST include an LLA (see Section 9) containing the MN's L2 address and an L2 address that can be mapped to an IPv4 address for the FA. This message MUST contain the FA-FA Authentication Extension [11] that is used to secure the HRqst message.
拡張機能は、メッセージは、MNのL2アドレス及びFAのIPv4アドレスにマッピングすることができるL2アドレスを含む（セクション9を参照）LLAを含まなければなりません。このメッセージは、FA-FA認証拡張HRqstメッセージを保護するために使用されている[11]を含まなければなりません。
This is a new Mobile IPv4 message carried on UDP (destination port 434) [1]. The UDP header is followed by the fields below.
これは、UDP（宛先ポート434）上に担持された新しいモバイルIPv4メッセージである[1]。 UDPヘッダは、以下のフィールドが続きます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |H|N|R|M|G|T|B| Reserved | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 17 (Handoff Reply)
タイプ17（ハンドオフ返信）
Code A value indicating the result of the Handoff Request. Only two codes are currently supported, 0, indicating success, and 1, indicating that the handoff cannot be performed. The remaining values are for future use.
コードハンドオフ要求の結果を表す値。唯一の2つのコードは、現在のハンドオフを行うことができないことを示す、成功を示す0、サポート、および1れます。残りの値は、将来の使用のためのものです。
Lifetime The lifetime, in seconds, for which the bidirectional tunnel for the MN will be maintained. If this is an HRply(s), then the lifetime represents a request by nFA, and it can be any value up to the maximum value sent in the HRqst(s). Larger values are assumed to default to oFA's maximum. If this is an HRply(t), then the lifetime represents the maximum amount of time that the oFA will grant to the nFA. If this is an HRply(r), then the lifetime represents the amount of time by which the tunnel life will be extended. If the Code field indicates that handoff failed, the Lifetime field will be ignored and SHOULD be set to zero. A value of 0 on an HRply(t) indicates that the oFA is unwilling to grant service. A value of 0 on an HRply(s) indicates that the nFA does not require service. A value of 0 on an HRply(r) indicates that the tunnel lifetime will be terminated. A value of 0xffff indicates an infinite lifetime.
MNのために双方向トンネルが維持されるための秒生涯寿命、。これはHRply（単数または複数）であれば、寿命は新FAによる要求を表し、それはHRqst（S）で送信された最大値までの任意の値とすることができます。より大きな値は、旧FAの最大にデフォルト設定を想定しています。これはHRply（T）である場合には、寿命は、旧FAは、新FAに付与する時間の最大量を表します。これはHRply（R）である場合には、寿命は、トンネルの寿命が延長されることにより、時間の量を表します。 Codeフィールドは、ハンドオフが失敗したことを示している場合、Lifetimeフィールドは無視され、ゼロに設定する必要があります。 HRply（t）に0の値は、旧FAがサービスを許可することが不本意であることを示しています。 HRply（S）上の0の値は、新FAがサービスを必要としないことを示しています。 HRply（R）に0の値は、トンネル寿命が終了することを示しています。 0xFFFFの値は、無限寿命を示しています。
H Source-triggered handoff reply. When set and the N bit is unset, indicates that the reply is in response to an HRqst(s).
Hソーストリガハンドオフ応答。セットとNビットが設定されていない場合、応答がHRqst（S）に応答していることを示しています。
N Target-triggered handoff reply. When set and the H bit is unset, indicates that the reply is in response to an HRqst(t).
Nターゲット・トリガハンドオフ応答。セットとHビットが設定されていない場合、応答がHRqst（T）に対応していることを示しています。
R Set if the reply is an HRply(r). Neither the H nor the N bit are set.
応答がHRply（R）である場合にRがセット。どちらもHもNビットがセットされていません。
M The FA issuing the HRqst will use Minimal Encapsulation as defined in [1,5] for the tunnel.
MザFAは、トンネルの[1,5]で定義されるようHRqstが最小カプセル化を使用する発行します。
G The FA issuing the HRqst will use GRE [4] Encapsulation as defined in [1,5] for the tunnel. When this flag bit is set, the HRply may require extensions containing the GRE type and key fields, but they are outside the scope of this document.
トンネルの[1,5]で定義されるようHRqstを発行GザFAはGRE [4]カプセル化を使用します。このフラグビットがセットされている場合、HRplyはGREタイプとキーフィールドを含む拡張を必要とするかもしれないが、彼らは、この文書の範囲外です。
T For an HRply(s), indicates that the nFA is requesting to reverse tunnel service. For an HRply(t), indicates that the oFA is willing to provide both forward and reverse tunnel service.
HRply（S）についてTは、新FAトンネルサービスを逆に要求していることを示しています。 HRply（T）のために、旧FAが前方の両方を提供し、トンネルサービスを逆転する意思があることを示しています。
B When sent in an HRply(t), indicates that the MN has requested a reverse tunnel to the HA and that the nFA SHOULD use a reverse tunnel to the HA if it will not be reverse tunneling to the oFA. It can be set in HRply(t) only if the T bit was unset in the corresponding HRqst(t).
B HRply（T）で送信された場合、MNは、HAへのリバーストンネルを要求し、それが旧FAに逆トンネリングしない場合新FAは、HAへ逆方向トンネルを使用するようにしたことを示します。 Tビットは、対応するHRqst（T）に設定解除された場合にのみHRply（T）に設定することができます。
MN Home Address For HRply(t), the home IPv4 address of the MN.
HRply（t）は、MNのホームIPv4アドレスについてはMNのホームアドレス。
HA Addr For HRply(t), the HA IPv4 address of the MN.
HRplyのためにHA ADDR（t）は、MNのHAのIPv4アドレス。
Identification As defined in [1].
[1]で定義されるように同定。
Extensions This Message MUST contain the FA-FA Authentication Extension [11] that is used to secure the HRply message.
拡張機能は、このメッセージは、FA-FA認証拡張HRplyメッセージを保護するために使用されている[11]を含まなければなりません。
The Handoff to Third message has the same format as the Handoff Request and Handoff Reply messages, except both the H and N bits are set. If the HTT message is in response to an L2-ST and is sent to initiate a handoff, then, with the exception of the H and N bits, the message has the same fields set and includes the same extensions as an HRqst(s). If the HTT message is sent in response to an HRqst(t), then, with the exception of the H and N bits, the message has the same fields set and includes the same extensions as an HRply(t). The tunnel bits MUST NOT be set in the HTT message because BET construction is not negotiated between oFA and nFA; it is negotiated between nFA and aFA in the ensuing HRqst(t)/HRply(t).
第3のメッセージへのハンドオフは、ハンドオフ要求と同じフォーマットを有しており、ハンドオフは、HとNビットが設定されているの両方を除き、メッセージ返信。 HTTメッセージはL2-STに応答し、ハンドオフを開始するために送信される場合、次いで、HおよびNビットを除いて、メッセージは、設定された同じフィールドを有し、HRqst（S）と同じ拡張子を含みます。 HTTメッセージがHRqst（t）に応答して送信される場合、次いで、HおよびNビットを除いて、メッセージは、設定された同じフィールドを有し、HRply（T）と同様の拡張を含みます。 BET構造は旧FAと新FAとの間でネゴシエートされていないため、トンネルビットはHTTメッセージに設定してはいけません。それはその後HRqst（T）/ HRply（T）に新FAとAFAの間で交渉されます。
In addition, the HTT MUST contain the following extensions in the specified order:
また、HTTは、指定された順序で以下の拡張子を含まなければなりません：
Solicited IPv4 Address Option: containing aFA's Address
要請されたIPv4アドレスオプション：AFAの住所を含みます
LLA Option: containing the L2 address of the MN.
LLAオプション：MNのL2アドレスを含みます。
The POST-REGISTRATION handoff approach allows FAs to communicate directly about a pending handoff, and does not require any IPv4-layer messages to be sent to or from an MN prior to the L2 handoff event. Therefore, it eliminates a possible source of handoff latency. This may be required when the link layer imposes hard deadlines on the time at which a handoff must occur, such as when an MN is rapidly moving out of a radio coverage area. Consequently, POST-REGISTRATION is primarily of interest in handoff between FAs that support the same radio access technology. Handoff between heterogeneous radio technologies will, of necessity, require interaction between the MN and the network, and so is not a domain of applicability for POST-REGISTRATION.
後登録ハンドオフアプローチは、Fasが保留ハンドオフについて直接通信することができ、およびまたはL2ハンドオフ・イベントに先立ってMNから送信される任意のIPv4層のメッセージを必要としません。したがって、ハンドオフ遅延の可能性のあるソースを排除します。リンク層は、MNが急速に無線カバレッジエリアの外に移動しているときのように、ハンドオフが発生しなければならない時点でハード期限を課す場合に必要とされ得ます。そのため、POST-登録は、主に、同じ無線アクセス技術をサポートするFAの間のハンドオフで重要です。異種無線技術間のハンドオフは、必然的に、MNとネットワーク間の相互作用を必要とし、そのPOST-登録のための適用のドメインではありません。
Because a POST-REGISTRATION handoff is triggered by an unspecified mechanism that informs the oFA or nFA that an L2 handoff is pending, the POST-REGISTRATION approach is only applicable to networks where such a mechanism is available. For example, an L2 may provide indications of radio signal quality that cause the oFA or nFA to send the POST-REGISTRATION handoff messages. Any such indications must also provide each FA involved in the handoff with the identity of the other, so that messages can be sent to the right place. This may involve mapping L2 information onto FA IPv4 addresses. Also, the FAs involved in a handoff must have pre-provisioned security arrangements so that the POST-REGISTRATION messages can be authenticated. If a handoff is to be completed as a result of the POST-REGISTRATION messaging, any L2 handoff indications must also be securely authenticated so that traffic to the old point of attachment is not improperly halted.
レジ後ハンドオフがL2ハンドオフが保留されている旧FA又は新FAを知らせる不特定のメカニズムによってトリガーされるので、レジ後アプローチは、そのような機構が利用可能であるネットワークにのみ適用可能です。たとえば、L2は、旧FA又は新FAがレジ後ハンドオフ・メッセージを送信させる無線信号の品質の指標を提供することができます。メッセージは適切な場所に送ることができるように、そのような兆候はまた、他のアイデンティティとハンドオフに関係する各FAを提供する必要があります。これは、FA、IPv4アドレスにマッピングL2情報を含むことができます。また、ハンドオフに関与のFAは、登録後のメッセージを認証することができるように、事前にプロビジョニングされた安全保障体制を持っている必要があります。ハンドオフがPOST登録メッセージングの結果として完成される場合添付ファイルの古いポイントへのトラフィックが不適切に停止されないように、任意のL2ハンドオフの兆候も安全に認証される必要があります。
POST-REGISTRATION handoff is appropriate in the following cases:
POST登録ハンドオフは、次の場合に適しています。
- L2 triggers are available on the network to indicate that L2 handoff is pending.
- L2トリガーは、L2ハンドオフが保留されていることを示すために、ネットワーク上で利用可能です。
- Pre-provisioned security mechanisms are in place to allow fast and secure messaging between the FAs and between the MN and an FA.
- プレプロビジョニングのセキュリティメカニズムは、Fasの間とMNとFAの間で高速かつセキュアなメッセージングを可能にするために整備されています。
- Access point choice by the MN is not a concern or the choice requires user intervention and therefore is not on the critical path for handoff.
- MNによるアクセスポイントの選択は重要ではないかの選択は、ユーザーの介入を必要とし、従って、ハンドオフのためのクリティカルパス上にありません。
The combined method uses both PRE-REGISTRATION and POST-REGISTRATION handoff. If PRE-REGISTRATION does not complete prior to the expiration of a timer on the nFA, the POST-REGISTRATION mechanism is used to create the tunnel between oFA and nFA. This protects the MN from delays caused by errors such as loss of the Mobile IPv4 Registration Reply message involved in PRE-REGISTRATION for the mobile-initiated and network-initiated source-triggered cases. It also protects the MN from delays caused by errors or the loss of any of the Mobile IPv4 messages involved in PRE-REGISTRATION for the network-initiated target-triggered case.
合成方法は、事前登録および後登録ハンドオフの両方を使用します。事前登録は、新FA上のタイマーの満了前に完了しない場合、レジ後機構は旧FAと新FAとの間のトンネルを作成するために使用されます。これは、移動開始及びネットワーク開始源トリガケースについて事前登録に関与するモバイルIPv4登録応答メッセージの損失などのエラーによる遅延からMNを保護します。また、エラーやネットワーク開始ターゲットトリガの場合の事前登録に関わるモバイルIPv4メッセージのいずれかの損失によって引き起こされる遅延からMNを保護します。
When the nFA receives a target trigger, it will follow the PRE-REGISTRATION procedure. When the combined method is used, the nFA MUST also start a timer when it receives a target trigger. The timer should be set to a small value (default for target trigger case: 1 second).
新FAは、ターゲット・トリガを受信すると、事前登録の手順に従います。合わせ方法が使用される場合、ターゲットトリガを受信した場合、新FAはまた、タイマーを開始しなければなりません。タイマーが小さな値に設定されるべきである（標的トリガ場合のデフォルト：1秒）。
According to PRE-REGISTRATION, the nFA will receive the Registration Request from the MN. When the combined method is used, this Registration Request sent by the MN MUST contain the IPv4 address of the oFA in an FA IPv4 address LLA extension (see Section 9.7). This same Registration Request message will contain multiple LLA extensions, since it will also contain the MN's layer 2 address in an LLA extension as described for PRE-REGISTRATION (see Sections 3.7 and 9). When the nFA has not started the handoff procedure using a target trigger (i.e., mobile-initiated or network-initiated target-triggered cases), the nFA MUST start a timer as soon as it receives the low-latency Registration Request from the MN. This timer should be set to a small value (default: 1 second).
事前登録によると、新FAは、MNからの登録要求を受信します。合成法を用いる場合、MNによって送信され、この登録要求がFAのIPv4アドレスLLA拡張における旧FAのIPv4アドレスを含まなければなりません（セクション9.7を参照）。事前登録で説明したように、それはまた、（セクション3.7および9を参照）LLA拡張のMNのレイヤ2アドレスが含まれていますので、これと同じ登録要求メッセージは、複数のLLAの拡張が含まれています。新FAは、ターゲット・トリガー（すなわち、モバイル-開始されるか、またはネットワーク開始ターゲットトリガの場合）を使用して、ハンドオフ手順を開始していない場合は、新FAはすぐにそれがMNから低レイテンシ登録リクエストを受信すると、タイマーを起動する必要があります。このタイマーは小さな値に設定する必要があります（デフォルト：1秒）。
In all cases, the timer MUST be reset when the Registration Reply message is received by nFA. If the timer expires before the Registration Reply is received, the nFA MUST initiate the POST-REGISTRATION procedure. The nFA utilizes the oFA IPv4 address (previously received in the extension to the Registration Request message) as the destination of the POST-REGISTRATION HRqst message to create the tunnel between nFA and oFA. The nFA MAY tear down this tunnel when it receives and forwards a successful Registration Reply for that MN.
登録応答メッセージを新FAによって受信されたときに、すべてのケースでは、タイマーをリセットする必要があります。登録応答が受信される前にタイマーが満了した場合は、新FAは、登録後の手続きを開始しなければなりません。新FAは、新FAと旧FAとの間にトンネルを作成するためにレジ後HRqstメッセージの宛先として（以前に登録要求メッセージへの拡張で受信した）旧FA IPv4アドレスを利用します。それが受信し、そのMNのための成功した登録応答を転送する際に、新FAは、このトンネルを取り壊す場合があります。
In the optimal cases considered in the PRE-REGISTRATION and POST-REGISTRATION handoffs, it was assumed that a timely L2 trigger would be received in such a way that packets could be delivered to the MN via its nFA immediately upon connection. In this way, the MN does not suffer disruption due to the L3 handoff. However, such precise timing of the L2 trigger and handoff mechanism with respect to the actual L2 handoff event will not be possible in all wireless systems and may depend on particular implementation techniques. Therefore, some uncertainty may exist at L3 as to exactly when the L2 connection between the MN and the nFA becomes fully established and can be used for L3 traffic. It is possible that in certain implementations traffic will be re-routed too early or too late with respect to the moment when the connection between the MN and the nFA becomes fully established. The techniques that may solve this problem and allow the MN to receive traffic independently of the timing of the L2 handoff event include buffering and simultaneous bindings (i.e., bicasting: setting the S bit [1] in Registration Requests). However, these are optional and are not mandated.
事前登録および登録後ハンドオフにおいて考慮最適な場合には、適時L2トリガパケットが接続直後にその新FAを介してMNへ送達することができるような方法で受信されると仮定しました。このように、MNはL3ハンドオフによる中断を受けません。しかし、実際のL2ハンドオフ・イベントに対するL2トリガーとハンドオフ機構のような正確なタイミングは、全ての無線システムでは可能ではないであろうと、特定の実装技術に依存してもよいです。したがって、いくつかの不確実性は、MNと新FAとの間のL2接続が完全に確立になり、L3のトラフィックのために使用することができる正確場合のようにL3で存在してもよいです。特定の実装では、トラフィックがMNと新FAとの間の接続が完全に確立状態になる瞬間に関して早すぎるか遅すぎる再ルーティングされる可能性があります。この問題を解決し、MNは、L2ハンドオフ事象のタイミングとは無関係に、トラフィックを受信することを可能にする技術がバッファリングと同時バインディングを含む（すなわち、バイキャスト：Sビットをセット[1]登録要求で）。しかし、これらはオプションであり、義務化されていません。
The handoff methods all support reverse tunneling. The MN may request reverse tunneling [3] by setting the T bit in its Registration Request. In the case of POST-REGISTRATION, if the MN had requested reverse tunneling previously at oFA, the handoff message from oFA (see Section 4) includes the T bit enabled to inform nFA to establish a BET for the visitor entry. Typically, the T bit will always be set to ensure that any delays in the MN receiving its new care-of address do not result in any delay in uplink packet transmission from the MN, but local policies and particular L2 technologies may allow the reverse tunnel to be turned off.
ハンドオフ方法は全て、リバーストンネリングをサポートしています。 MNは、その登録要求にTビットを設定することにより、[3]リバーストンネリングを要求することができます。 （セクション4を参照）後登録の場合には、MNは旧FA、旧FAからハンドオフメッセージで以前にリバーストンネリングを要求した場合は、訪問者のエントリのBETを確立するために、新FAを知らせるために有効にTビットを含みます。典型的には、Tビットは、常に新たな気付アドレスを受信MNの任意の遅延がMNからのアップリンクパケット伝送における任意の遅延を生じないことを確実にするために設定されるが、ローカルポリシー及び特定のL2技術は、リバーストンネルを可能にすることができますオフにします。
In general and to a greater extent in wireless networks, packets carrying handoff signaling may be dropped or lost due to errors on the link. In this section, we consider mechanisms for recovery from handoff signaling failures.
一般的な無線ネットワークにおいてより大きな程度では、ハンドオフ・シグナリングを搬送するパケットが原因リンク上のエラーに低下または消失してもよいです。このセクションでは、ハンドオフのシグナリングの障害からの回復のための仕組みを検討してください。
Failure of PRE-REGISTRATION signaling breaks down into three cases:
ダウン3例に事前登録シグナル切断の失敗：
1) Loss of messages PrRtSol and PrRtAdv on the air link.
エアリンク上のメッセージPrRtSolと代理ルータ広告の1）損失。
2) Loss of the solicitation by an FA to obtain another neighboring FA's Advertisement or loss of the neighboring FA's advertisement.
隣接する他のFAの広告や近隣のFAの広告の損失を取得するFAによって勧誘の2）損失。
3) Failure of the standard Mobile IPv4 Registration.
標準のモバイルIPv4登録の3）故障。
Of these, case 3) is handled by standard Mobile IPv4 mechanisms described in [1]. Case 2) is expected to be a rare event because spontaneous packet drop rates on the fixed network are caused by congestion or router failure. Since bit error rates on wireless links are higher than on fixed links, case 1) is more likely to occur. In the following subsections, cases 1) and 2) are considered.
これらのうち、ケース3）は、[1]に記載の標準的なモバイルIPv4メカニズムによって処理されます。ケース2）固定ネットワーク上の自発的なパケットドロップ率が輻輳やルータの障害によって引き起こされているため稀な事象であると期待されています。無線リンクのビットエラーレートが固定されたリンクよりも高いので、ケース1）が発生しやすくなります。以下のサブセクションにおいて、ケース1）及び2）が考えられます。
PRE-REGISTRATION handoff can fail in network-initiated handoff when the PrRtAdv sent by oFA in response to the source trigger (L2-ST) or the advertisement sent by nFA in response to the target trigger (L2- TT) fails to reach the MN. PRE-REGISTRATION handoff can also fail in mobile-initiated handoff when either the PrRtSol sent from the MN or return PrRtAdv sent from the oFA is dropped. To reduce the probability that PrRtAdv and PrRtSol are lost, the MN and FA MAY transmit multiple copies of these messages. Should these messages fail anyway, in both cases the MN connects to the nFA without having received any prior signaling. In this case, the MN solicits an FA Advertisement when it connects to nFA at L2 (L2-LU), as described in Section 3.6, and performs a standard Mobile IPv4 Registration with the nFA as specified in [1].
ソーストリガ（L2-ST）またはターゲット・トリガー（L2- TT）に対応して新FAにより送信された広告に応じて、旧FAにより送信された代理ルータ広告がMNに到達するために失敗したときに事前登録ハンドオフは、ネットワーク開始ハンドオフに失敗する可能性があります。事前登録ハンドオフも、どちらかPrRtSolは、MNから送信されたときに、モバイル主導のハンドオフに失敗したり、代理ルータ広告が削除された旧FAから送ら戻ることができます。代理ルータ広告とPrRtSolが失われる確率を減らすために、MNとFAは、これらのメッセージの複数のコピーを送信してもよいです。これらのメッセージは、MNが、事前のシグナリングを受信せずに新FAに接続し、両方のケースでは、とにかく失敗する必要があります。セクション3.6で説明したように、L2で新FA（L2-LU）に接続したとき、この場合には、MNはFA広告を勧誘し、[1]で指定されるように新FAと標準モバイルIPv4登録を行います。
The solicitation from an FA to another neighboring FA may fail or the corresponding advertisement from the neighboring FA may be lost. To reduce the probability that these messages are lost, the FAs MAY transmit multiple copies of these messages. If a failure occurs anyway, the FA soliciting the Agent Advertisement is unable to send a PrRtAdv in response to a source trigger or to a mobile-initiated PrRtSol. In these cases, when the MN does not receive a notification or confirmation of a PRE-REGISTRATION handoff, the MN MUST perform a standard Mobile IPv4 Registration as soon as it connects to the nFA (L2-LU) as described in Section 8.1.1.
別の隣接FAのFAから要請が失敗する可能性があり、または隣接FAから対応する広告が失われる可能性があります。これらのメッセージが失われる確率を減らすために、FASがこれらのメッセージの複数のコピーを送信してもよいです。障害が発生した場合は、とにかく、エージェント広告を募集FAは、ソース・トリガーまたはモバイル開始PrRtSolに応じて代理ルータ広告を送信することができません。 MNは、通知または事前登録ハンドオフの確認を受信しない場合、セクション8.1.1で説明したように、新FA（L2-LU）に接続するようにこれらのケースでは、MNはすぐ標準モバイルIPv4登録を実行しなければなりません。
Failure occurs in POST-REGISTRATION when either the HRqst or HRply message is dropped. The effects of the failure and the recovery procedure depend on which message is dropped, and whether the handoff is source or target triggered. Since all of the POST-REGISTRATION signaling is going over the fixed network, it can be expected that spontaneous dropping of packets in the absence of congestion and router failure should be a relatively rare event. Nevertheless, failure recovery mechanisms SHOULD be implemented.
HRqstまたはHRplyメッセージのいずれかがドロップされたときに失敗すると、登録後に発生します。障害と回復手順の効果は、廃棄されたメッセージに依存し、ハンドオフがソースまたはターゲットトリガであるかどうか。全ての事後登録シグナリングは、固定ネットワーク上で起こっているので、輻輳ルータ障害の非存在下でのパケットの自発的滴下は比較的稀な事象であることが期待できます。それにもかかわらず、障害回復メカニズムを実装する必要があります。
If the HRqst message is dropped, the effect is the same for both source- and target-triggered handoffs. In either case, the FA to which the HRqst was destined will never respond with an HRply message. If the handoff is source triggered, then the nFA never learns of the handoff, and the oFA never receives confirmation. If the handoff is target-triggered, then the oFA never learns of the handoff, and the nFA never receives confirmation.
HRqstメッセージがドロップされる場合、効果は、両方のソース - ターゲット・トリガハンドオフについても同様です。いずれの場合も、HRqstが運命づけられた先のFAはHRplyメッセージで応答することはありません。ハンドオフがソーストリガされた場合、その後、新FAがハンドオフで学習したことがない、と旧FAは確認を受けることはありません。ハンドオフがターゲットトリガの場合は、旧FAは、ハンドオフを知ったことがない、と新FAは、確認を受けることはありません。
The recovery procedure in this case is as follows: the oFA MUST NOT construct a forward tunnel when the MN moves off-link (L2-LD) if the handoff is source-triggered, and the nFA MUST NOT construct a reverse tunnel if the handoff is target triggered. If the nFA was not informed of the handoff by an HRqst message (corresponding to failure of source-triggered handoff) or if the handoff was not confirmed by an HRply message (corresponding to failure of target-triggered handoff), the nFA MUST unicast an Agent Advertisement to the MN as soon as its L2 connection is established (L2-LU at nFA).
ハンドオフがソーストリガされた場合、MNは、オフリンク（L2-LD）を移動させるときに旧FAが前方にトンネルを構築してはいけません、そして新FAがハンドオフする場合、逆方向トンネルを構築してはいけません：以下のように、この場合の復旧手順でありますターゲットがトリガされます。新FAは、（ソーストリガハンドオフの故障に対応する）HRqstメッセージによってハンドオフを通知又はハンドオフがHRplyメッセージによって確認されなかった場合（目標トリガハンドオフの故障に対応する）されなかった場合は、新FAは、ユニキャストしなければなりませんMNへのエージェント広告とすぐにそのL2接続が（NFAでL2-LU）確立されています。
If the HRply message is dropped, the FA sending the HRply will assume that the handoff has been confirmed, but the FA that is expecting to receive the HRply does not receive confirmation. In this case, the failure recovery procedure is different for source-triggered and target-triggered handoffs.
HRplyメッセージがドロップされる場合は、HRplyを送るFAがハンドオフが確認されていることを前提としていますが、HRplyを受け取るために期待しているFAは確認を受信しません。この場合、障害回復手順は、ソーストリガとターゲット・トリガハンドオフのために異なっています。
In a target-triggered handoff, the oFA assumes that the handoff is confirmed because it has sent the HRply, but the nFA has not received it so it does not have confirmation. The oFA starts tunneling packets to the nFA when the MN moves from its link (L2-LD). The nFA MUST send an FA Advertisement to the MN as soon as its L2 link is up (L2-LU at nFA) and MAY drop the tunneled packets. The nFA SHOULD send an ICMP Destination Unreachable [9] message to the oFA. When the oFA receives this message, it will terminate the tunnel and stop forwarding packets. If reverse tunneling was requested, the nFA MUST NOT reverse tunnel because it has not received handoff confirmation.
ターゲットトリガハンドオフでは、旧FAは、それがHRplyを送ったが、それは確認していないので、新FAがそれを受信していないので、ハンドオフが確認されていることを前提としています。 MNは、そのリンク（L2-LD）から移動したときに旧FAは、新FAへトンネルパケットを開始します。新FAとすぐにそのL2リンクがアップしているようMNに（NFAでL2-LU）をFA広告を送らなければなりませんし、トンネリングされたパケットを廃棄するかもしれません。新FAは、旧FAにICMP宛先到達不能[9]メッセージを送信する必要があります。旧FAは、このメッセージを受信すると、トンネルを終端し、パケットの転送を停止します。リバーストンネリングが要求された場合は、ハンドオフ確認を受信していないため、新FAは、トンネルを逆にしてはなりません。
In source-triggered handoff, the nFA assumes that the handoff is confirmed because it has sent the HRply, but the oFA has not received it so it does not have confirmation. Without failure recovery, the MN could move to the nFA without the oFA being able to start the forward tunnel for the MN's packets, and the MN would not be able to initiate a Mobile IPv4 Registration because it does not know that the handoff has failed. In this situation, the oFA MUST send out an HRqst message to the nFA with lifetime zero as soon as the MN leaves its link (L2-LD). The oFA SHOULD continue to retransmit the HRqst message, with exponential backoff for CONFIG-HFAIL seconds or until it receives an HRply acknowledging the request to cancel the tunnel. The default value for CONFIG-HFAIL is 10 seconds. When the nFA receives the HRqst, it MUST immediately send an Agent Advertisement to the MN, as is the case whenever a tunnel is canceled. In addition, the oFA MUST also drop any packets received through the reverse tunnel from the nFA. The oFA SHOULD NOT send the ICMP Destination Unreachable message to the nFA because the nFA has been informed by the HRqst message to cancel the tunnel. However, if the nFA receives an ICMP Destination Unreachable message for the tunnel prior to receiving the HRqst canceling the tunnel, it MUST send an FA Advertisement to the MN and cancel the tunnel.
ソーストリガハンドオフでは、新FAは、それがHRplyを送ったが、それは確認していないので、旧FAがそれを受信していないので、ハンドオフが確認されていることを前提としています。障害回復がなければ、MNは旧FAは、MNのパケットに対して前方にトンネルを開始できずに新FAに移動することができ、そしてそれは、ハンドオフが失敗したことを知らないので、MNは、モバイルIPv4登録を開始することができません。 MNは、そのリンク（L2-LD）を離れると、このような状況では、旧FAとすぐに寿命がゼロで新FAにHRqstメッセージを送らなければなりません。旧FAは、CONFIG-HFAIL秒間またはそれがトンネルを解除する要求を認めるHRplyを受信するまで、指数バックオフで、HRqstメッセージを再送信し続けるべきです。 CONFIG-HFAILのデフォルト値は10秒です。新FAはHRqstを受信すると、トンネルが解除されたときにケースがあるとして、それはすぐに、MNへのエージェント広告を送らなければなりません。また、旧FAはまた、新FAからリバーストンネルを介して受信したパケットをドロップしなければなりません。新FAは、トンネルをキャンセルするHRqstメッセージによって通知されたので、旧FAは新FAにICMP宛先到達不能メッセージを送るべきではありません。新FAは、トンネルをキャンセルHRqstを受信する前にICMP宛先トンネルの到達不能メッセージを受信した場合しかし、それはMNにFA広告を送信し、トンネルをキャンセルする必要があります。
This section defines the Generalized Link Layer and IPv4 Address (LLA) Extension, used by any node that needs to communicate link layer and IPv4 addresses. The format of the extension relies on sub-types, where each sub-type defines its own sub-structure. This document defines six sub-types. Future RFCs should allocate their own sub-type and define their own address formats.
このセクションでは、一般化リンク層とリンク層とIPv4アドレスを通信する必要がある任意のノードによって使用されるIPv4アドレス（LLA）拡張を定義します。拡張のフォーマットは、各サブタイプは、それ自身のサブ構造を定義するサブタイプに依存しています。この文書では、6つのサブタイプを定義します。将来のRFCは、独自のサブタイプを割り当て、自分のアドレス形式を定義する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
138 (skippable) [1] - when used in Registration Requests 140 (skippable) [1] - when used in Agent Advertisements
エージェント広告で使用する場合 - 138（スキップ可能）[1] - 登録に使用される[1] 140（スキップ可能）を要求します
Length
長さ
The length of the Link Layer Address + the one-octet Sub-Type field
リンク層アドレス+ 1オクテットサブタイプフィールドの長さ
Sub-Type
サブタイプ
This field contains the Link Layer sub-type identifier
このフィールドは、リンク層のサブタイプ識別子が含まれています
LLA
LLA
Contains the Link Layer Address
リンク層アドレスが含まれています
In this document, seven sub-types are defined:
この文書では、7サブタイプが定義されています。
1 3GPP2 International Mobile Station Identity and
Connection ID [13]
2 3GPP International Mobile Subscriber Identity [15]
3 Ethernet 48-bit MAC address [5]
4 64-bit Global ID, EUI-64 [6]
5 Solicited IPv4 Address
6 Access Point Identifier
7 FA IPv4 Address
The following subsections describe the extensions.
以下のサブセクションでは、機能拡張について説明します。
The IMSI Link Layer Address Extension contains the International Mobile Station Identity (IMSI).
IMSIリンクレイヤアドレス拡張は、国際移動局アイデンティティ（IMSI）が含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1 (skippable) [1]
1（スキップ可能）[1]
Length
長さ
The length of the IMSI field + the one-octet Sub-Type field
IMSIフィールドの長さ+ 1オクテットサブタイプフィールド
Sub-Type
サブタイプ
1
１
IMSI
IMSI
Contains the IMSI, in the form: <IMSI>:<Connection Id> Where the <IMSI> is an ASCII-based representation of the International Mobile Station Identity, most significant digit first, ":" is ASCII 0x3a, and the Connection ID is the ASCII representation of a small, decimal number used for distinguishing different link-layer connections from the same mobile device.
IMSIは、フォームに含まれています。<IMSI>：<接続ID> <IMSI>は、最初の最上位桁、国際移動局アイデンティティのASCIIベースの表現である「：」のASCII 0x3aで、接続ID同じモバイルデバイスから別のリンク層接続を区別するために使用される小型の10進数のASCII表現です。
The IMSI Link Layer Address Extension contains the International Mobile Station Identity.
IMSIリンクレイヤアドレス拡張は、国際移動局アイデンティティが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
2 (skippable) [1]
2（スキップ可能）[1]
Length
長さ
The length of the IMSI field + the one-octet Sub-Type field
IMSIフィールドの長さ+ 1オクテットサブタイプフィールド
Sub-Type
サブタイプ
2
２
IMSI
IMSI
Contains the IMSI, a number composed of 15 digits or less, coded as described in [15].
IMSIが含まれて[15]に記載されているように、15桁以下からなる数は、符号化されました。
The Ethernet Link Layer Address Extension contains the 48-bit Ethernet MAC Address, as defined in [5].
[5]で定義されているイーサネットリンクレイヤアドレス拡張は、48ビットのイーサネットMACアドレスが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
3 (skippable) [1]
3（スキップ可能）[1]
Length
長さ
7 (includes the Sub-Type field)
7（サブタイプフィールドを含みます）
Sub-Type
サブタイプ
3
３
MAC
マック
Contains the 48-bit Ethernet MAC Address.
48ビットのイーサネットMACアドレスが含まれています。
The 64-bit Global Identifier (EUI-64) Address Extension contains the 64-bit address, as defined in [6].
[6]で定義されるように、64ビットのグローバル識別子（EUI-64）は、拡張は、64ビット・アドレスを含むアドレス。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
4 (skippable) [1]
4（スキップ可能）[1]
Length
長さ
9 (includes the Sub-Type field)
9（サブタイプフィールドを含みます）
Sub-Type
サブタイプ
4
４
MAC
マック
Contains the 64-bit Global Identifier Address.
64ビットのグローバル識別子のアドレスが含まれています。
The 32-bit Solicited IPv4 Address Extension contains the IPv4 address of the agent (FA) being solicited. This extension MAY be present in an ICMP Agent Solicitation as explained in Section 3.3.
32ビット要請IPv4アドレス拡張が要請されているエージェントのIPv4アドレス（FA）を含みます。 3.3節で説明したように、この拡張機能は、ICMPエージェント要請に存在してもよいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | IPv4 addr ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
5 (skippable) [1]
5（スキップ可能）[1]
Length
長さ
5 (includes the Sub-Type field)
5（サブタイプフィールドを含みます）
Sub-Type
サブタイプ
5
５
IPv4 Address
IPv4アドレス
Contains the 32-bit IPv4 Address of the solicited node.
募集ノードの32ビットのIPv4アドレスが含まれています。
The 32-bit Access Point Identifier Extension contains an identifier of the access point to which the MN will move. This may be a wireless L2 identifier. The MN is able to solicit an advertisement from the FA servicing a certain access point by using this extension with Agent Solicitations as explained in Section 3.3.
32ビットアクセスポイント識別子拡張は、MNが移動先のアクセスポイントの識別子を含みます。これは、無線L2の識別子であってもよいです。 MNは、3.3節で説明したように、エージェント要請でこの拡張機能を使用して、特定のアクセスポイントにサービスを提供するFAからの広告を募集することができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | AP ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
6 (skippable) [1]
6（スキップ可能）[1]
Length
長さ
5 (includes the Sub-Type field)
5（サブタイプフィールドを含みます）
Sub-Type
サブタイプ
6
６
AP ID
あなたは思います
Contains the 32-bit Access Point Identifier.
32ビットアクセスポイント識別子が含まれています。
The 32-bit FA IPv4 Address Extension contains the IPv4 address of the agent (FA). This extension MAY be present in a Registration Request message to identify the oFA as explained in Section 5.
32ビットFA IPv4アドレス拡張エージェント（FA）のIPv4アドレスを含んでいます。 5章で説明したように、この拡張は、旧FAを識別するための登録要求メッセージ中に存在してもよいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | IPv4 addr ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
7 (skippable) [1]
7（スキップ可能）[1]
Length
長さ
5 (includes the Sub-Type field)
5（サブタイプフィールドを含みます）
Sub-Type
サブタイプ
7
７
IPv4 Address
IPv4アドレス
Contains the 32-bit IPv4 Address of the FA node.
FAノードの32ビットのIPv4アドレスを含んでいます。
This document defines one new extension to Mobile IPv4 Control messages and one new extension to Mobile IPv4 Router Discovery messages already maintained by IANA. This document also defines a new Mobile IPv4 Control message type to be used between FAs. To ensure correct interoperation based on this specification, IANA must reserve values in the Mobile IPv4 number space for two new extensions and one new message type. IANA must also manage the numbering spaces created by the two new extensions, the message type, and its associated Code field.
この文書では、モバイルIPv4制御メッセージにつの新しい拡張と、すでにIANAによって維持モバイルIPv4ルーター発見メッセージへの1つの新しい拡張機能を定義します。この文書はまた、のFAとの間で使用される新しいモバイルIPv4制御メッセージ・タイプを定義します。この仕様に基づいて正しい相互運用性を確保するために、IANAは、2つの新しい拡張機能や1つの新しいメッセージタイプのモバイルIPv4番号空間内の値を確保する必要があります。 IANAは、2つの新しい拡張機能、メッセージタイプ、およびそれに関連するCodeフィールドによって作成された番号のスペースを管理する必要があります。
Section 9 introduces two extensions.
第9節は、2つの拡張を導入しています。
Generalized Link Layer and IPv4 Address (LLA) Extension for Router Discovery messages: A new Mobile IPv4 extension that follows after Mobile IPv4 ICMP Router Discovery messages (e.g., Mobile IP Agent Advertisements). The type value of this extension belongs to the
一般リンク層とルーター発見メッセージのIPv4アドレス（LLA）拡張子：モバイルIPv4 ICMPルーター発見メッセージ（例えば、モバイルIPエージェント広告）の後に、次の新しいモバイルIPv4拡張。この拡張機能のタイプの値はに属し
Mobile IPv4 number space for Router Discovery messages maintained by IANA. The value assigned by IANA is 140. This new extension uses the Link Layer and IPv4 Address Identifier (LLA) sub-type numbering space that requires IANA management (see Section 10.2).
IANAによって維持ルーター検出メッセージのモバイルIPv4番号空間。 IANAによって割り当てられた値は、この新しい拡張機能は、IANAの管理を（10.2節を参照）を必要とリンク層とIPv4アドレス識別子（LLA）サブタイプ番号スペースを使用し140です。
Generalized Link Layer and IPv4 Address (LLA) Extension for Mobile IP Control messages: A new Mobile IPv4 extension appended to Mobile IP Control messages (e.g., Registration Request). The type value of this extension belongs to the Mobile IPv4 number space for extensions to Mobile IPv4 Control messages maintained by IANA. It MUST be in the skippable (128-255) range as defined in [1]. The value assigned is 138 by IANA. This new extension uses the Link Layer and IP Address Identifier (LLA) sub-type numbering space that requires IANA management (see Section 10.2).
一般リンクレイヤとモバイルIP制御メッセージのためのIPv4アドレス（LLA）拡張子：モバイルIP制御メッセージ（例えば、登録要求）に追加新しいモバイルIPv4拡張。この拡張のタイプ値は、IANAによって維持モバイルIPv4制御メッセージへの拡張のためのモバイルIPv4番号空間に属します。これは、[1]で定義されるように範囲（128-255）スキップ可能でなければなりません。割り当てられた値は、IANAによって138です。この新しい拡張機能は、リンク層とIPアドレス識別子IANA管理が必要です（LLA）サブタイプ番号スペースを（10.2節を参照）を使用しています。
10.2. Generalized Link Layer and IP Address Identifier (LLA) Sub-type Values
10.2. 一般リンクレイヤとIPアドレス識別子（LLA）サブタイプの値
This section describes the sub-type values that are applicable to both the Generalized LLA Extensions for Mobile IP Control and Router Discovery messages. This specification makes use of the sub-type values 1-7, and all other values other than zero (reserved) are available for assignment via IETF consensus [14]. The seven sub-type values defined in this specification are:
このセクションでは、モバイルIP制御とルーター検出メッセージのための一般化LLA拡張機能の両方に適用されているサブタイプの値を示します。この仕様は、サブタイプの使用は1~7値になり、ゼロ（予約済み）以外の他のすべての値は、IETFコンセンサス[14]を介して、割り当てのために利用可能です。本明細書で定義される7サブタイプの値は次のとおりです。
1 3GPP2 International Mobile Station Identity and
Connection ID [13]
2 3GPP International Mobile Subscriber Identity [15]
3 Ethernet 48-bit MAC address [5]
4 64-bit Global ID, EUI-64 [6]
5 Solicited IPv4 Address
6 Access Point Identifier
7 FA IPv4 Address
Sections 4.5 and 4.6 define two new Mobile IPv4 message types: Handoff Request and Handoff Reply. These require two type numbers to be assigned by IANA from the Mobile IPv4 Control message type address space. The Handoff Reply message also introduces its own Code field that requires IANA to manage a new Code address space. This specification makes use of the Code values 0-1, where 0 identifies a successful handoff and 1 defines a generic handoff failure. All other values are available for assignment via IETF consensus [14].
ハンドオフ要求とハンドオフ返信：セクション4.5および4.6は、2つの新しいモバイルIPv4メッセージタイプを定義します。これらは、モバイルIPv4コントロールメッセージタイプアドレス空間からIANAによって割り当てられるべき2つのタイプ番号を必要とします。ハンドオフ応答メッセージは、新しいコードのアドレス空間を管理するために、IANAが必要で、独自のコードフィールドを紹介します。この仕様は、コード0は成功したハンドオフを識別し、1は、一般的なハンドオフの失敗を定義0-1、値を利用します。他のすべての値は、IETFコンセンサス[14]を介して、割り当てのために利用可能です。
Code Values for Mobile IP Handoff Reply Messages
モバイルIPハンドオフのためのコード値は、メッセージの返信
0 Successful Handoff 1 Generic Handoff Failure 2-255 Unallocated
0ハンドオフの成功1一般的なハンドオフの失敗2-255未割り当て
For the PRE-REGISTRATION method, as discussed in Section 3.8, the oFA and nFA MUST share a security association to authenticate and integrity protect messages transported between them. In addition, oFA must be authorized to solicit nFA based on the security association. The minimal requirement to establish a security association between FAs is that both FAs support manual pre-configuration of security associations involving shared keys. Other mechanisms to establish security associations using IKE [16] based on shared secrets or public keys may also be used. The inter-FA ICMP messages (solicitations and advertisements) MUST be authenticated and integrity protected using ESP [10]. The default ESP authentication algorithm for use in this specification is HMAC-SHA1-96 [12]. The absence of this security would allow denial-of-service attacks from malicious nodes at any distance from the FA. To secure Registration Request and Reply messages, PRE-REGISTRATION uses the security mechanisms already described in [1] and optionally [11].
事前登録の方法については、3.8節で述べたように、旧FAと新FAは、認証と整合性がそれらの間で転送メッセージを保護するためのセキュリティアソシエーションを共有しなければなりません。また、旧FAは、セキュリティアソシエーションに基づいて新FAを勧誘することを許可しなければなりません。 FAの間のセキュリティアソシエーションを確立するための最小限の要件は、両方のFAが共有鍵を含むセキュリティアソシエーションの手動事前設定をサポートしていることです。共有秘密または公開鍵に基づいて、IKE [16]を使用してセキュリティアソシエーションを確立するための他の機構を使用してもよいです。インターFA ICMPメッセージ（勧誘、広告）が認証され、完全性がESP [10]を使用して保護されなければなりません。この仕様で使用するデフォルトのESP認証アルゴリズムはHMAC-SHA1-96 [12]です。このセキュリティの欠如は、FAからの任意の距離で、悪意のあるノードからサービス拒否攻撃が可能になります。登録要求を確保し、メッセージを返信し、事前登録はすでに[1]および必要に応じて[11]に記載のセキュリティ・メカニズムを使用します。
POST-REGISTRATION introduces a new change to Mobile IPv4, which is the possibility that an MN may receive packets from an FA with which it has not yet performed a Mobile IPv4 Registration. It is not recommended that the MN drop packets from unknown FAs since it would effectively eliminate the advantages of POST-REGISTRATION. From a security viewpoint, dropping packets from unknown FAs would not provide significant protection for an MN from any attack. This is because any malicious host may use the MN's home address to send packets to the MN through its current known FA; therefore, processing packets received from unknown FAs would not provide worse security than with normal Mobile IPv4.
登録後は、MNは、それがまだモバイルIPv4登録を行わなかったとFAからパケットを受信する可能性があるモバイルIPv4、新しい変化を導入します。未知のFAからMNドロップパケットは、それが効果的にPOST登録の利点を排除するため、ことが推奨されていません。セキュリティの観点から、不明のFAからのパケットをドロップすると任意の攻撃からMNのための重要な保護を提供しないであろう。悪意のあるホストが現在知られているFAを通じてMNにパケットを送信するためにMNのホーム・アドレスを使用する可能性があるからです。従って、未知のFAから受信した処理パケットは、通常のモバイルIPv4を用いた場合よりも悪いセキュリティを提供しないであろう。
In a similar way to PRE-REGISTRATION, in POST-REGISTRATION, oFA and nFA MUST share a security association required to protect the Handoff Request and Reply messages. The minimal requirement to establish a security association between FAs is that the FAs support manual pre-configuration of security associations involving shared keys. Other mechanisms to establish security associations using IKE [16] based on shared secrets or public keys may also be used. The Handoff Request and Reply messages MUST be authenticated using the FA-FA authentication extension [11] that uses the default algorithm specified in [7]. The absence of this security would allow impersonation attacks and denial-of-service attacks.
登録を事前に同様の方法で、登録後に、旧FAと新FAは、ハンドオフ要求を保護するために必要なセキュリティアソシエーションを共有し、メッセージを返信しなければなりません。 FAの間のセキュリティアソシエーションを確立するための最小限の要件は、Fasが共有鍵を含むセキュリティアソシエーションの手動事前設定をサポートしていることです。共有秘密または公開鍵に基づいて、IKE [16]を使用してセキュリティアソシエーションを確立するための他の機構を使用してもよいです。ハンドオフ要求と応答メッセージは、[7]で指定されたデフォルトのアルゴリズムを使用してFA-FA認証拡張[11]を使用して認証されなければなりません。このセキュリティの欠如は、なりすまし攻撃やDoS攻撃が可能になります。
The minimal requirement is that all FAs involved in low latency handoffs MUST support manual pre-configuration of peer-to-peer security associations with neighboring FAs, involving shared secrets and are already required to support the default algorithms of [1]. Other mechanisms to establish security associations using IKE [16] based on shared or public keys may also be used.
最小要件は、低レイテンシハンドオフに関与するすべてのFAは、共有秘密を含む、近隣のFAとのピアツーピアセキュリティアソシエーションの手動の事前設定をサポートしなければならないことであると既に[1]のデフォルトのアルゴリズムをサポートするために必要とされます。共有または公開鍵に基づいて、IKE [16]を使用してセキュリティアソシエーションを確立するための他の機構を使用してもよいです。
Since the techniques outlined in this document depend on particular L2 information (triggers) to optimize performance, some level of L2 security is assumed. Both PRE- and POST-REGISTRATION techniques depend on L2 triggers, but the L2 security implications are different for the two techniques.
本文書で概説した技術は、パフォーマンスを最適化するために、特定のL2情報（トリガー）に依存するため、L2セキュリティのいくつかのレベルが想定されます。前後の登録技術の両方は、L2トリガーに依存するが、L2セキュリティ含意は二つの技術のために異なっています。
In particular, in POST-REGISTRATION, the L2 triggers initiate the establishment of tunnels that route IPv4 packets for the MN to its new location. Therefore, the L2 triggers MUST be secured against any tampering by malicious nodes, either mobile or within the wired network. The L2 addresses or IPv4 addresses for the MN and the FAs that appear in the L2 triggers MUST correspond to the actual nodes that are participating in the handoff. If there is any possibility that tampering may occur, the recipient of an L2 trigger MUST have some way of authenticating the L2 information. Wireless networks that do not provide such features will be subject to impersonation attacks, where malicious nodes could cause FAs to believe that an MN has moved to other service areas or to allow a bogus MN to obtain unauthorized service from an FA prior to performing a Mobile IPv4 Registration. In POST-REGISTRATION, the L2 triggers would typically be sent between a wireless base station and the FA. No standard protocol exists at this time to communicate the L2 trigger information, but it is important that any future protocol used for this purpose provides adequate security. If the wireless base station and FA were integrated, then this security threat would not apply. Also the layer 2 control messages on the wireless link must be secured appropriately to prevent a malicious node from running impersonation attacks and causing unwanted L2 triggers to be generated. Integrity and replay protection would be required to avoid impersonation threats and resource consumption threats where a malicious node replays old messages to cause resource consumption. This depends on the type of L2 security of the wireless link. For example, in cellular technologies, the control messages are secured, although the type of security varies depending on the cellular standard, but this is not typically the case in WLAN IEEE 802.11 networks.
具体的には、レジ後に、L2トリガーは、その新しい場所にMNのためのルートIPv4パケットトンネルの確立を開始します。したがって、L2トリガは、モバイルまたは有線ネットワーク内のいずれかで、悪意のあるノードによって任意改竄から保護されなければなりません。 L2トリガに表示さL2アドレス又はMNのIPv4アドレスおよびFASは、ハンドオフに参加している実際のノードに対応しなければなりません。起こり得る改ざん任意の可能性がある場合、L2トリガの受信者は、L2情報を認証するいくつかの方法がなければなりません。このような機能を提供していないワイヤレスネットワークは、悪意のあるノードは、FAのは、MNが他のサービスエリアに移動したことを信じることやモバイルを実行する前に偽のMNは、FAからの不正なサービスを得ることができるように引き起こす可能性が偽装攻撃の対象となりますIPv4の登録。後登録では、L2トリガーは、典型的には、無線基地局とFAとの間で送信されます。標準的なプロトコルは、L2トリガ情報を通信するためにこの時点では存在しないが、この目的のために使用される任意の将来のプロトコルは、十分なセキュリティを提供することが重要です。無線基地局とFAが統合された場合、このセキュリティ上の脅威は適用されません。また、無線リンク上のレイヤ2つの制御メッセージは、なりすまし攻撃を実行し、不要なL2を生成するトリガ原因悪意のあるノードを防止するために適切に固定されなければなりません。整合性および再生保護は、偽装の脅威や悪意のあるノードは、リソース消費を引き起こすために古いメッセージを再生資源消費の脅威を回避するために必要とされるであろう。これは、無線リンクのL2セキュリティの種類によって異なります。例えば、セルラー技術では、制御メッセージは、セキュリティのタイプは、セルラー規格によって異なり、これは、典型的には、WLAN IEEE 802.11ネットワークにおける場合ではないが、固定されています。
In PRE-REGISTRATION, the security of L2 triggers has different implications. The PRE-REGISTRATION technique depends on Mobile IPv4 security between MN and FA, so the same security considerations in [1] apply. Should malicious nodes be able to generate or modify L2
事前登録では、L2トリガーのセキュリティは異なる意味を持ちます。事前登録の技術は、MNとFAとの間のモバイルIPv4のセキュリティに依存し、そうで同じセキュリティ上の考慮事項[1]が適用されます。悪意のあるノードは、L2を生成または変更することができるはずです
trigger information (i.e., L2-ST or L2-TT), this would cause advertisements to be sent to the MN. They would consume wireless resources and processing in the MN, but would not allow an impersonation attack. In order to prevent such denial-of-service attacks, there should be a limit on the number of advertisements that an FA (oFA) will relay to the MN as a result of the reception of L2 triggers. This number will depend on the L2 technology, and the default limit is 10 per second.
情報（即ち、L2-ST又はL2-TT）をトリガし、これが原因となる広告がMNに送信されます。彼らは、MNに無線リソースや処理を消費することになるが、なりすまし攻撃を許可しないでしょう。そのようなサービス拒否攻撃を防止するために、FA（OFA）がL2トリガの受信の結果として、MNに中継する広告の数に制限があるべきです。この数は、L2技術に依存し、デフォルトの制限値は、毎秒10です。
The authors want to thank Lennart Bang, Bryan Hartwell, Joel Hortelius, Gianluca Verin, and Jonathan Wood for valuable comments and suggestions on the whole document. The authors also thank the Mobile IPv4 WG chairs, Phil Roberts and Basavaraj Patil, for their input.
著者は、文書全体の貴重な意見や提案のためのレナート・バン、ブライアン・ハートウェル、ジョエルHortelius、Gianlucaさんベリン、とジョナサン・ウッドに感謝したいと思います。著者はまた、彼らの入力のために、モバイルIPv4 WGチェア、フィル・ロバーツとBasavarajパティルに感謝します。
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[1]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[3]モンテネグロ、G.編、 "モバイルIPのためのリバーストンネリング、改訂版"、RFC 3024、2001年1月。
[4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[4]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[5] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[5]プラマー、D.、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルは、イーサネットハードウェア上での伝送のためのイーサネットアドレスを48ビットにアドレス変換」、STD 37、RFC 826、1982年11月。
[6] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997.
[6]、http://standards.ieee.org/regauth/oui/tutorials/EUI64.html、1997年3月IEEE、 "64ビットのグローバル識別子（EUI-64）登録機関のガイドライン"。
[7] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[7]パーキンス、C.、カルフーン、P.、およびJ. Bharatia、 "モバイルIPv4チャレンジ/レスポンス拡張（改訂版）"、RFC 4721、2007年1月を。
[8] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[8]デアリング、S.、エド。、 "ICMPルータ発見メッセージ"、RFC 1256、1991年9月。
[9] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[9]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[10] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[10]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[11] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 Regional Registration", RFC 4857, June 2007.
[11] Fogelstroem、E.、ヨンソン、A.、およびC.パーキンス、 "モバイルIPv4地域登録"、RFC 4857、2007年6月。
[12] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[12] Madson、C.とR.グレン、 "ESPおよびAH内のHMAC-SHA-1-96の使用"、RFC 2404、1998年11月。
[13] TIA/EIA/IS-2000.
[13] IS-2000 /である/でした。
[14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[14] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[15] 3GPP TS 23.003 (www.3gpp.org).
[15] 3GPP TS 23.003（www.3gpp.org）。
[16] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[16]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
Appendix A - Gateway Foreign Agents
付録A - Gatewayの外国人のエージェント
The Mobile IPv4 Regional Registration specification [11] introduces the Gateway Foreign Agent (GFA), as a mobility agent that two FAs providing service to an MN have in common. Figure A.1 provides an example of an MN's initial registration through the GFA. If this is the first registration message, the message MUST be forwarded to the HA. All packets sent to the MN will be delivered to the GFA, which in turn will forward the packets to the FA servicing the MN.
モバイルIPv4地域の登録仕様[11] MNにサービスを提供する2つのFAが共通に持っているモビリティエージェントとして、ゲートウェイ外部エージェント（GFA）を紹介します。図A.1は、GFAを通してMNの初期登録の例を提供します。これは最初の登録メッセージである場合は、メッセージがHAに転送されなければなりません。 MNに送信されたすべてのパケットが順番にMNにサービスを提供するFAにパケットを転送しますGFA、に配信されます。
RegReq +-----+ RegReq
+----------->| oFA |--------------+
| +-----+ |
| v
+----+ +-----+ RegReq +----+
| MN | | GFA |<------->| HA |
+----+ +-----+ +----+
+-----+
| nFA |
+-----+
Figure A.1 - Initial Registrations through GFA
図A.1 - GFAによる初期登録
If the MN moves to an nFA that is serviced by a GFA common with oFA, the MN MAY issue a Regional Registration Request (see Figure A.2). The Regional Registration message does not need to be forwarded to the HA, since the MN's traffic can still be delivered to the same GFA. This optimized approach effectively reduces the latency involved in the registration process.
MNは旧FAと共通GFAによってサービスされる新FAに移動した場合、MNは、地域の登録要求（図A.2を参照）を発行することができます。 MNのトラフィックはまだ同じGFAに配信することができますので、地域の登録メッセージは、HAに転送する必要はありません。この最適化されたアプローチが効果的に登録プロセスに関与し、レイテンシを低減します。
+-----+
| oFA |
+-----+
+----+ +-----+ +----+
| MN | | GFA | | HA |
+----+ +-----+ +----+
| ^
| +-----+ |
+------------>| nFA |-------------+
RegRegReq +-----+ RegRegReq
Figure A.2 - Regional Registration through GFA
図A.2 - GFAによる地域登録
Note that the GFA may also be the MN's first-hop router.
GFAはまた、MNの最初のホップルータであってもよいことに注意してください。
Appendix B - Low-Latency Handoffs for Multiple-Interface MNs
付録B - 複数のインタフェースのMNのための低遅延ハンドオフ
For MNs that have two wireless network interfaces, either on the same wireless network or on wireless networks having different wireless L2 technologies, the techniques discussed in this document may be unnecessary if the Mobile IPv4 stack on the MN allows switching an IPv4 address binding between interfaces. This Appendix discusses how multiple wireless interfaces can aid low-latency handoff.
MNにモバイルIPv4スタックがインターフェイス間の結合IPv4アドレスを切り替えることができた場合のいずれかで同じ無線ネットワーク上または異なる無線L2技術を有する無線ネットワーク上で、2つの無線ネットワークインターフェースを有しているMNのため、この文書で説明した技術は、不要とすることができます。この付録では、複数の無線インタフェースは、低遅延ハンドオフを支援する方法について説明します。
+------+ +---------+
| HA |--------| (GFA) |
+------+ +---------+
/ \
... ...
/ \
/ \
+------+ +------+
| oFA | | nFA |
+------+ +------+
| |
+------+ +------+
| RN1 | | RN2 |
+------+ +------+
+------+
| MN | --------->
+------+
Movement
Figure B.1 - Network Model for Mobile IPv4 with Multi-Access
図B.1 - マルチアクセスとモバイルIPv4のためのネットワークモデル
Figure B.1 illustrates the normal and hierarchical MIPv4 models. As shown in the figure, assume that the MN is connected to Radio Network 1 (RN1) and is registered with oFA through which it is receiving traffic. Suppose MN enters the coverage area of RN2 and nFA and that it prefers connectivity to this network for reasons beyond the scope of this document (e.g., user preferences, cost, QoS available, etc.). The MN activates the interface to RN2 but continues communicating through RN1. The MN may solicit advertisements from nFA through the interface connected to RN1 to speed up the handoff process, provided there is no TTL restriction, or it can solicit advertisements through the interface connected to RN2 if it has been configured for IPv4 traffic.
図B.1は、通常、階層のMIPv4モデルを示す図です。同図に示すように、MNは、無線ネットワーク1（RN1）に接続され、それがトラフィックを受信し、それを通して旧FAに登録されていると仮定する。 MNはRN2と新FAのカバレッジエリアに入ると、それは（例えば、ユーザの好み、コスト、利用可能なQoS、等）は、この文書の範囲を超えた理由により、このネットワークへの接続を好むと仮定する。 MNはRN2へのインタフェースを活性化させるが、RN1を介して通信し続けます。 MNにはTTLの制限がありません、ハンドオフプロセスをスピードアップするためにRN1に接続されたインターフェースを介して新FAから広告を要請することができる、又はそれは、IPv4トラフィック用に構成されている場合には、RN2に接続されたインターフェースを介して広告を求めることができます。
Once the MN is registered with nFA and is successfully receiving and transmitting through the new network, it tears down the interface to RN1. If the MN has enough time to complete this procedure without incurring degraded service or disconnection, the MN would experience a seamless multi-access handoff, but it may not be possible in all cases, due to network coverage or for other reasons. Should multiple interface handoff be possible, then the low-latency methods described in this document are not necessary.
MNは、新FAに登録され、正常に受信し、新しいネットワーク経由で送信されると、それはRN1にインタフェースを切断します。 MNが劣化したサービスや断線を招くことなく、この手順を完了するのに十分な時間を持っている場合、MNは、シームレスなマルチアクセスハンドオフを経験するだろうが、それは、ネットワークのカバレッジにまたは他の理由のために、すべてのケースではできないことがあります。複数のインタフェースのハンドオフが可能であるべきで、この文書に記載された低レイテンシ方法が必要とされません。
In order to support the possible failure of the connectivity with the new network (RN2/nFA) in the short period following handoff, the MN may use the S bit in its Mobile IPv4 Registration Request to maintain simultaneous bindings with both its existing (HA or GFA) binding with oFA and a new binding with nFA.
ハンドオフの後の短い期間で新たなネットワーク（RN2 /新FA）との接続が失敗する可能性をサポートするために、MNは、その既存の（HAの両方との同時バインディングを維持するために、そのモバイルIPv4登録要求にSビットを使用してもよく、または旧FAと新FAとの新しいバインディングと結合GFA）。
Appendix C - PRE-REGISTRATION Message Summary
付録C - PRE-登録メッセージの概要
This appendix contains a quick reference for IPv4 and layer 2 addresses to be used in PRE-REGISTRATION messages.
この付録では、事前登録メッセージで使用されるIPv4およびレイヤ2つのアドレスのクイックリファレンスが含まれています。
Proxy Router Advertisement (PrRtAdv) This is a standard Router/Agent Advertisement [1] with the following characteristics:
プロキシルータ広告（代理ルータ広告）これは、[1]次の特性を持つ標準ルータ/エージェント広告です。
Source IPv4 Address: nFA IPv4 Address Source Layer 2 Address: oFA L2 Address Destination IPv4 Address: MN IPv4 Address (from PrRtSol) Destination Layer 2 Address: MN L2 Address (from PrRtSol) LLA Extension (defined in this spec): containing nFA Layer 2 Address.
送信元IPv4アドレス：新FAのIPv4アドレスソースレイヤ2つのアドレス：旧FA L2アドレスの宛先IPv4アドレス：MNのIPv4アドレス（PrRtSolから）宛先レイヤ2つのアドレス：LLA拡張（この仕様で定義されている）（PrRtSolから）MNのL2住所：含む新FAレイヤー2つの住所。
Proxy Router Solicitation (PrRtSol) This is a standard Router/Agent Solicitation [1] with the following characteristics:
プロキシルータ要請（PrRtSol）これは次の特性を持つ標準のルータ/エージェント要請[1]です。
Source IPv4 Address: MN Address Source Layer 2 Address: MN Address Destination IPv4 Address: oFA Address (from source address of previous Router Advertisement or PrRtAdv) Destination Layer 2 Address: oFA Address (from source address of previous Router Advertisement or PrRtAdv LLA) LLA Extension (defined in this spec): depends on the layer 2 technology (e.g., typically for WLAN, this would be the BSSID of the new WLAN Access Point)
送信元IPv4アドレス：MNアドレスソースレイヤ2つのアドレス：MNアドレス宛先IPv4アドレス：（以前のルータ通知または代理ルータ広告LLAの送信元アドレスからの）旧FA住所LLA：宛先レイヤ2つのアドレス（以前のルータ通知または代理ルータ広告の送信元アドレスからの）旧FA住所拡張（この仕様で定義される）（例えば、一般的にWLANのために、これは新しいWLANアクセスポイントのBSSIDなります）レイヤ2の技術に依存
Registration Request (as seen on MN-oFA link) This is a Mobile IPv4 Registration Request message [1] with the following characteristics:
登録要求（MN-のOFAリンク上で見られるように）これは、モバイルIPv4登録要求メッセージである[1]次の特性を持ちます。
Source IPv4 Address: MN Address Source Layer 2 Address: MN Address Destination IPv4 Address: nFA Address (from source addr of PrRtAdv)
送信元IPv4アドレス：MNアドレスソースレイヤ2アドレス：MNアドレス宛先IPv4アドレス：（代理ルータ広告の送信元アドレスから、）新FA住所
Destination Layer 2 Address: Default Router (i.e., oFA Address) LLA Extension (defined in this spec): containing the MN's L2 address that must be used by nFA. This will typically be an Ethernet MAC address but other types can be used as specified in Section 9 of this document.
宛先レイヤ2つのアドレス：デフォルトルータ（すなわち、旧FAアドレス）LLA拡張（この仕様で定義されている）：新FAで使用されている必要がありMNのL2アドレスを含みます。これは通常、イーサネットMACアドレスになりますが、このドキュメントのセクション9で指定されている他のタイプを使用することができます。
Although this is not mandated, an MN implementation may set the S bit (see Section 6) in Registration Request messages to improve the handoff and avoid problems due to failed layer 2 handoffs and layer 2 ping-pong effects between two base stations.
これが義務化されていないが、MNの実装では、ハンドオフを改善し、失敗したレイヤ2つのハンドオフ及び2つの基地局との間の層2ピンポン効果に起因する問題を回避するために、登録要求メッセージに（セクション6を参照）Sビットを設定することがあります。
Registration Reply (as seen on oFA-MN link) This is a Mobile IPv4 Registration Reply message [1] with the following characteristics:
登録応答（OFA-MNのリンクで見られるように）これは以下の特性を有するモバイルIPv4登録応答メッセージ[1]です。
Source IPv4 Address: nFA Address Source Layer 2 Address: oFA Address Destination IPv4 Address: MN Address (from source of Registration Request) Destination Layer 2 Address: MN Address (from source of Registration Request)
送信元IPv4アドレス：新FAアドレスソースレイヤ2つのアドレス：旧FAアドレス宛先IPv4アドレス：（登録要求の送信元からの）MNアドレス宛先レイヤ2つのアドレス：（登録要求の送信元からの）MN住所
Contributing Authors
共著
Pat Calhoun Cisco Systems EMail: pcalhoun@cisco.com
パットカルフーンシスコシステムズ電子メール：pcalhoun@cisco.com
Tom Hiller Lucent Technologies EMail: tom.hiller@lucent.com
トム・ヒラールーセント・テクノロジーズEメール：tom.hiller@lucent.com
James Kempf NTT DoCoMo USA Labs EMail: kempf@docomolabs-usa.com
ジェームズ・ケンプNTTドコモUSA研究所Eメール：kempf@docomolabs-usa.com
Peter J. McCann Motorola Labs EMail: pete.mccann@motorola.com
ピーター・J.マッキャンモトローラLabsのEメール：pete.mccann@motorola.com
Ajoy Singh Motorola EMail: asingh1@email.mot.com
AjoyシンモトローラEメール：asingh1@email.mot.com
Hesham Soliman Elevate Technologies EMail: Hesham@elevatemobile.com
ヒシャムスレイマン・テクノロジーズエミール害虫：هشام@الفاطمبل.كوم
Sebastian Thalanany US Cellular EMail: Sebastian.thalanany@uscellular.com
セバスチャンThalanany米国の携帯メール：Sebastian.thalanany@uscellular.com
Editor's Address
編集者の住所
Karim El Malki Athonet EMail: karim@athonet.com
カリム・エルMalki Athonet Eメール：karim@athonet.tsum
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。