[要約] RFC 4881は、モバイルIPv4における低遅延のハンドオフに関する要件を定義しています。その目的は、モバイルデバイスがネットワーク間を移動する際に、通信の中断を最小限に抑えることです。
Network Working Group K. El Malki, Ed.
Request for Comments: 4881 Athonet
Category: Experimental June 2007
Low-Latency Handoffs in Mobile IPv4
モバイル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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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）が異なる外国人エージェント（FA）が提供するサブネット間でIPv4-レイヤーハンドオフを実行する方法を説明しています。特定の場合、ハンドオフに関与するレイテンシは、遅延に敏感なサービスまたはリアルタイムサービスのサポートに必要なしきい値を超える可能性があります。このドキュメントの目的は、FA間の移動中に低遅延のモバイルIPv4ハンドオフを達成するための2つの手法を提示することです。これら2つの手法のさらなる組み合わせも説明します。提示された手法により、モバイルIPv4登録プロセスの遅延によりMNがIPv4パケットを送信または受信できない期間を最小限に抑えることにより、モバイルIPv4ネットワーク上のリアルタイムサービスのサポートが高まります。これらの手法の1つ以上は、さまざまなワイヤレステクノロジー（WLAN、Cellular、Wimax、Flash-ofDMなど）にわたって高速モバイルIPv4ハンドオフを達成するために必要になる場合があります。各ワイヤレステクノロジーには異なるレイヤー2ハンドオフ手順があり、各シナリオに最適な低遅延技術を使用して、ハンドオフパフォーマンスを最適化する必要があります。実装とパフォーマンスの観点から、ワイヤレステクノロジーに最適な手法を決定するには、さらなる展開と実験が必要です。したがって、著者は、さらなるパフォーマンス測定を奨励し、異なるワイヤレスレイヤー2への適用性を説明するための適切なワイヤレステクノロジーと協力して、低遅延のフーフー仕様に取り組んでいます。
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.
ofa-古い外国人エージェント（FA）、レイヤー3（L3）ハンドオフの前にモバイルノード（MN）のケアオブアドレス（COA）の処理に関与するFA。
nFA - new Foreign Agent, the FA anticipated to be handling an MN's care-of address after completion of an L3 handoff.
NFA-新しい外国人エージェント、FAは、L3ハンドオフが完了した後、MNのケアのケアを処理することを期待していました。
aFA - anchor Foreign Agent, the FA that is currently handling the network end of the tunnel in POST-REGISTRATION.
AFA-登録後のトンネルのネットワークエンドを現在処理しているFAであるFAをアンカー外国人エージェント。
L2 handoff - Movement of an MN's point of layer 2 (L2) connection from one wireless access point to another.
L2ハンドオフ - MNのポイントオブレイヤー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 -MNで発生するL2トリガーは、特定のNFA（モバイルトリガー）への移動を通知します。
L2-ST or source trigger - An L2 trigger that occurs at oFA, informing the oFA that L2 handoff is about to occur.
L2 -STまたはソーストリガー-OFAで発生するL2トリガーは、L2ハンドオフが発生しようとしていることをOFAに通知します。
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またはターゲットトリガー - NFAで発生するL2トリガーは、NFAにNFAに引き渡されようとしていることをNFAに通知します。
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またはNFAで発生するL2トリガーは、MNとNFAの間の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 -OFAで発生するL2トリガーは、MNとOFAの間のL2リンクが失われていることをOFAに通知します。
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） - MNのCOAを変更することを要求することなく、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.
Ping-Pong- L2ハンドオフの障害により、2つのワイヤレスアクセスポイント間の迅速な前後の動き。古いアクセスポイントと新しいアクセスポイントの両方の無線条件がほぼ同等であり、優れた低エラーL2接続を確立するのに最適ではない場合に発生する可能性があります。
network-initiated handoff - L3 handoff in which oFA or nFA initiates the handoff.
ネットワーク開始ハンドオフ-L3ハンドオフOFAまたはNFAがハンドオフを開始します。
mobile-initiated handoff - L3 handoff in which the MN initiates the handoff.
モバイル開始ハンドオフ-L3ハンドオフMNがハンドオフを開始します。
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のIPv4アドレス、またはMNまたはFAのIPv4アドレスに解決できるL2識別子。識別子が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とのみ通信できます。これは、NFA（新しいFA）へのL2ハンドオフが完了した後に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.
- OFAに接続しながら、MNがNFAと通信できるようにします。
- Provide for data delivery to the MN at the nFA even before the formal registration process has completed.
- 正式な登録プロセスが完了する前であっても、NFAで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.
テクニックの最初のカテゴリにより、MNは、基礎となるL2ハンドオフの前に、NFAの登録状態を「事前に建設」することができます。テクニックの2番目のカテゴリにより、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:
このドキュメントには、低遅延のL3ハンドオフを達成するために3つの方法が示されています。1つは上記の各カテゴリに、もう1つは2つの組み合わせとして表示されます。
- PRE-REGISTRATION handoff method,
- 事前登録ハンドオフメソッド、
- POST-REGISTRATION handoff method, and
- 登録後のハンドオフメソッド、および
- 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は、L3ハンドオフを完了する前に、L3ハンドオフを実行する際にネットワークによって支援されます。L3ハンドオフは、ネットワーク開始またはモバイル開始のいずれかです。したがって、L2トリガーはMNとFAの両方で使用され、特定のL3ハンドオフイベントをトリガーします。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.
登録後のハンドオフメソッドは、モバイルIPv4プロトコルへの拡張機能を提案して、OFA（古いFA）とNFA（新しいFA）がL2トリガーを利用できるようにして、OFAとNFAの間に双方向トンネルを設定することができます。NFAのサブネットで。これにより、リアルタイムアプリケーションへの影響を最小限に抑える新しい添付ファイルでのサービスの迅速な確立が可能になります。MNは、新しいFAとのL2通信が確立された後、最終的に正式なモバイルIPv4登録を実行する必要がありますが、これはMNまたはFAの要求に応じて遅延することができます。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ハンドオフが完了する前に事前登録ハンドオフを実行できる場合、組み合わせたメソッドは登録前のハンドオフに解決します。ただし、アクセステクノロジーに依存する期間内に事前登録のハンドオフが完了しない場合、OFAは、登録後のハンドオフ法で指定されているように、MNのトラフィックをNFAに転送し始めます。これにより、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および1つのセルラーインターフェイスなど）を持つMNSに適用できることに注意する必要があります。ただし、このドキュメントに記載されているハンドオフ方法はすべての場合に必要ではないため、増殖したMNSのケースには特別な考慮が必要です（付録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ハンドオフプロセスに関連しています。可能なイベントの1つは、アクセスネットワークへのモバイルノードの添付のL2ポイントの今後の変更の早期通知です。もう1つの可能なイベントは、新しい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.
L2から適切に抽象化するために、3つのエンティティの1つであるMN、OFA、またはNFAは、L2ハンドオフの必要性を認識し、NFAまたはMNもオプションで作成できると想定されています。L2ハンドオフが完了したことを認識してください。特定のL2は、トリガーが受信され、どのエンティティが受信されるかを指示することがよくあります。特定のL2はネットワーク側でアドバンストリガーを提供し、他のL2はMNでアドバンストリガーを提供します。また、実際のL2ハンドオフに関するトリガーの特定のタイミングは、テクノロジーごとに異なる場合があります。たとえば、一部のワイヤレスリンクは、実際のハンドオフのかなり前にこのようなトリガーを提供する場合があります。対照的に、他のL2は、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、OFA、またはNFAによって受信されるかどうかに応じて分類できます。表1は、トリガーに含まれる情報とともに、このような分類を示しています。このドキュメントに示されている方法は、表1に示すように、さまざまなタイプのL2トリガーに基づいて動作します。L2トリガーが受信されると、以下に記載されているハンドオフプロセスが開始されます。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)
表1 -L2トリガー（次のページに続く）
+------------+----------------------+---------------+---------------+
| 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」、「optional」、「推奨」、「必要」、および「必要ではない」は、[2]で説明されているように解釈されるべきではありません。
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ハンドオフを開始することができ、ネットワーク開始ハンドオフまたはモバイル開始ハンドオフが発生するかどうかに応じて、FA側またはMN側のL2トリガーを使用できます。
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.
事前登録は、通常のモバイルIPv4モデル[1]、およびオプションでは地域登録モデル[11]もサポートします。特にホームエージェント（HA）がNFAから（遅延の観点から）距離にある場合、低遅延のハンドオフメカニズムと一緒に[11]を実装することには利点があります。[11]のゲートウェイ外部エージェント（GFA）と呼ばれるより近いローカルHAを使用することにより、ハンドオフ手順が完了するのに必要な時間を短縮できます。ただし、[11]の実装は、事前登録では必要ありません。事前登録は、新しいドメインでMNを認証するために新しい認証、承認、会計（AAA）トランザクションが発生する必要がある動きをサポートします。
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は、OFAからNFAへのプロキシルーター（エージェント）勧誘（PRRTSOL）です。これは、一般化されたリンク層とIPアドレス拡張機能のNFA（つまり、IPアドレスまたはL2アドレス）の識別子を含むモバイルIPエージェント勧誘です（セクション9を参照）。メッセージ1AがLLA拡張機能にNFAの正しい識別子を含むNFAによって受信される場合、NFAはメッセージ1Bのプロキシルーター広告（エージェント広告）を返す必要があります。メッセージ1Bは、一般化されたリンクレイヤーとIPアドレス（LLA）拡張機能のNFAレイヤー2アドレスを含むNFAのエージェント広告です（セクション9.3を参照）。メッセージ1Aと1Bは、ハンドオフを遅らせないように、事前登録ハンドオフの前に発生する必要があります。これを発生させるために、OFAはメッセージ1Aと1Bを使用して近隣のNFAから広告を求めてキャッシュする必要があり、したがって、この交換のタイミングを残りの登録前のハンドオフから切り離します。L3ハンドオフがNFA（L2-TT）でのターゲットL2トリガーによって開始されると、メッセージ1Bはメッセージ2Bに等しく、MN（NFAからMNを介してNFAからMNを通るトンネル）に直接送信されます。
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からOFAへのプロキシルーター勧誘（PRRTSOL）です。通常のルーター（エージェント）の勧誘とは異なります。これは、このメッセージを受信するルーターとは異なるルーターから広告を勧誘するためです。これは、一般化されたリンク層とIPアドレス拡張機能のNFA（つまり、IPアドレスまたはL2アドレス）の識別子を含むモバイルIPエージェント勧誘です（セクション9を参照）。メッセージ2Aの存在は、ハンドオフがモバイル開始であり、その不在はハンドオフがネットワーク開始であることを意味します。モバイル開始のハンドオフでは、MNにL2トリガーがある場合にメッセージ2Aが発生し、プロキシルーター広告（PRRTADV）を求めます。メッセージ2AがOFAによって受信される場合、メッセージ2bのプロキシルーター広告（エージェント広告）を返す必要があります。これは、一般化されたリンクレイヤーとIPアドレス（LLA）拡張機能のNFAレイヤー2アドレスを含む単純なNFAのエージェント広告です（セクション9.3を参照）。ネットワーク開始のソーストリガーハンドオフでは、L2トリガーはOFAで発生し、OFAはMNが勧誘する必要なく、メッセージ2Bのエージェント広告を中継する必要があります。また、NFAがネットワーク開始のターゲットトリガーされたケースで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.
3. MNは、勧誘または未承諾のエージェント広告を受け取ったときに移動検出を実行し、必要に応じて、メッセージ3の登録要求（REGREQ）メッセージ[1]をNFAに送信します。ローカルゲートウェイの外国人エージェント（GFA）が存在する場合、このメッセージはオプションで地域登録要求（Regregreq）になる可能性があります[11]。MNはL2ハンドオフの前にNFAに直接接続されていないため、メッセージ3はOFAをルーティングします。
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.
4. メッセージ4および5標準のモバイルIPv4登録[1]またはオプションでは、メッセージ3で開始された地域登録[11]を完了する必要があります。登録要求には、一般化されたリンクレイヤーとIPアドレスの拡張機能にMNのレイヤー2アドレスを含める必要があります（セクション3.7および9を参照してください。）。この識別子は、単純なイーサネットアドレスまたはワイヤレステクノロジーに固有の識別子である場合があります。MNがNFAにまだ接続されていない場合、メッセージ5の登録返信は、MNがNFAに接続するとすぐに、NFAによってMNオンリンクにユニキャストによってバッファリングされなければなりません（つまり、NFAでL2-LUトリガーを使用してください。MNがエージェントの勧誘を送信するか、オプションでこのドキュメントの範囲外の特別なレイヤー2手法を使用して実装されます）。これは、ワイヤレスL2接続のために、返信を受信する前に、MNがOFAから切り離さなければならない可能性があるため、必要です。MNのL2アドレスは、セクション3.7で説明されているように、セクション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.
5. 登録が成功した場合、MNのパケットはHA（またはGFA）からNFA、そして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がNFAから（遅延の観点から）距離にある場合、ローカル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トリガーがOFAまたはMNによって受信される時間、それにより、実際のL2ハンドオフが発生する時間と比較して、登録前のハンドオフをトリガーすることは、低遅延のハンドオフの最適なパフォーマンスに重要です。つまり、最適な場合には、L2トリガーが受信され、上記の事前登録の4つのメッセージングステップが完了します（つまり、MNが移動する前に登録要求がHAまたはGFAによって処理される時期まで）。最適に、登録返信とNFAにHA（またはGFA）によってリダイレクトされた最初のパケットは、NFAへのMNのL2リンクが完全に確立される瞬間にMNに到達します。したがって、MNはL3ハンドオフのために混乱を招きません。特定の実装手法が使用されない限り、これを常に保証することはできません。このタイミングの問題の一部を軽減するために、MNはMNが送信した低遅延登録要求にSビット[1]を設定する場合があります。これにより、MNは短いレイヤー2ハンドオフ時間中にOFAとNFAの両方でパケットを受信できます。L2テクニックやバッファリングなど、他の手法が必要になる場合がありますが、これらはこのドキュメントの範囲外です。さらに、MNが事前登録ハンドオフを実行する間、HA（またはGFA）とOFAの間でパケットの損失を防止するために、さらにハンドオフスムージングの考慮事項が必要になる場合があります。これらはまた、このドキュメントの範囲外です。
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で説明したように、ソーストリガーによってOFAまたはターゲットトリガーによってNFAで事前登録ハンドオフを開始できます。図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.
OFAでL2トリガーを受信して、OFAからNFAへの特定のMNの今後のムーブメントを通知するときに、ソーストリガーされたネットワーク開始ハンドオフが発生します。L2トリガーには、MNの識別子（つまり、IPv4アドレス自体またはIPv4アドレスに解決できる識別子）およびNFAの識別子を含む情報が含まれています。識別子は、IPv4アドレスまたはワイヤレステクノロジー（ベースステーションまたはアクセスポイント識別子など）に固有のものである場合があります。NFAでL2トリガーを受信して、OFAからの特定のMNの今後のムーブメントを通知するターゲットトリガーのネットワーク開始ハンドオフが発生します。このタイプのトリガーも表1に示されており、MNやOFAの識別子を含む情報が含まれています。
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)
図2-登録前のハンドオフメッセージタイミング図（ネットワーク開始、ソーストリガー）
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.
ソーストリガーされたハンドオフでは、OFAがトリガー（L2-ST）を受信すると、メッセージ2B、プロキシルーター広告（PRRTADV）をMNに送信する必要があります。PRRTADVはNFAのエージェント広告[1]であり、セクション9で説明されているリンクレイヤー拡張機能の1つです。この拡張子の内容の使用については、セクション3.7で説明します。メッセージ1Aおよび1Bは、L2トリガーを受信する前にOFAとNFAによって交換する必要があります（セクション3.4.1を参照）。メッセージ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)
図3-登録前のハンドオフメッセージタイミング図（ネットワーク開始、ターゲットトリガー）
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).
ターゲットトリガーされたハンドオフでは、NFAがトリガー（L2-TT）を受信すると、L3ハンドオフを開始するためにMNを通じてエージェント広告をMNにトンネルしなければなりません。内側の広告はNFAからMNのユニキャストであるため、NFAはターゲットトリガーをルーター（エージェント）勧誘として扱います。この広告はOFAにトンネルされており、これは通常のルーターとして機能し、広告を脱カプセル化してMNに転送します。このメッセージは、攻撃を防ぐために認証される必要があります（セクション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に示すように、MNでL2トリガーを受信したときにモバイル開始のハンドオフが発生し、まもなくNFAに移動することを通知します。L2トリガーには、NFAの識別子（つまり、NFAのIPv4アドレスまたはNFAの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)
図4-登録前のハンドオフメッセージタイミング図（モバイル開始）
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）を送信する必要があります。このメッセージは、プロキシルーター広告（PRRTADV）のUNACASTエージェントの勧誘です。この勧誘には、[1]のようにTTL = 1が必要です。OFAへのプロキシルーター広告勧誘は、特別な拡張機能を備えたエージェントの勧誘です。勧誘には、FA識別子（つまり、LLA拡張機能に含まれるIPv4アドレスまたはL2アドレス、セクション9を参照）を含む拡張機能が必要です。MNはOFAからの別の特定のFAの広告を求めているためです。この特定のFAはMNのNFAになります。識別子は、NFAのIPv4アドレスまたはNFAのIPv4アドレスに解決するためにOFAが使用できる別の識別子です。識別子がIPv4アドレスでない場合、それは基礎となるワイヤレステクノロジー、たとえば、セクションで説明されているようにNFA IPv4アドレスにOFAにマッピングできるアクセスポイントまたはベースステーション識別子（WLAN BSSIDなど）に固有の場合があります。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 Identifier Extension, and are described in Sections 9.5 and 9.6. These two extensions SHOULD NOT be present in the same PrRtSol message.
NFAのIPv4アドレスとアクセスポイント識別子を含むように、2つの拡張サブタイプが定義されています。それらは、勧誘されたエージェントIPv4アドレス拡張およびアクセスポイント識別子拡張と呼ばれ、セクション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.
OFAがPRRTSOLメッセージを受信した場合、プロキシルーター広告（PRRTADV、メッセージ2B）でMNに返信する必要があります。PRRTADVは、OFAによってプロキシ化された要求されたNFAのエージェント広告です。ハンドオフを促進するために、セクション3.5で指定されているように、メッセージ1Aおよび1Bに示されているNFAとの以前の交換に続いて、実際のNFA広告はOFAによってキャッシュされる必要があります。PRRTADVメッセージには、NFAの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の事前登録ハンドオフが完了するように、トリガータイミングを整理する必要があります。つまり、NFAへのMNの登録が実行された後、L2ハンドオフを完了する必要があります（メッセージ3のメッセージ3）。登録は、ワイヤレスリンクのエラーにより失われる確率を減らすために、複数のコピー（デフォルトの推奨：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).
この場合の事前登録ハンドオフでは、MNが古いワイヤレスアクセスポイントを介してNFAからエージェント広告を受信する必要があります。これを達成する方法については、次のサブセクションで説明します。FAS間で交換されるメッセージは、なりすまし攻撃を防ぐために認証される必要があります。最小限の要件は、低遅延のハンドオフに関与するすべてのFAが、共有キーと[1]のデフォルトアルゴリズムを含む他の隣接FASとのセキュリティ関連の手動の事前構成をサポートする必要があることです（このドキュメントのセキュリティに関する考慮事項を参照）。
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 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.
これは、ネットワーク開始のソーストリガー（L2-ST）およびモバイル開始（L2-MT）ケースのみに適用されます。FA間勧誘は、OFAがNFAのIPv4アドレスにアクセスできることを前提としています。NFAのIPv4アドレスは、ネットワーク開始の場合のOFAでのL2トリガー（セクション3.2を参照）またはモバイル開始ケースのMNからのプロキシルーター勧誘（PRRTSOL）への拡張によって取得されます（PRRTSOL）セクション3.3を参照）。PRRTSOLのこの拡張機能には、IPv4アドレスまたは別の識別子、たとえばWLAN BSSIDなどのワイヤレスベースステーションの識別子が含まれている場合があります。後者の場合、OFAは、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.
OFAがL2トリガーを受信し、特定のMNのNFAのアドレスを取得したら、広告をキャッシュしない場合（セクション3.5を参照）、NFAにユニキャストエージェント勧誘（PRRTSOL）を送信する必要があります。NFAは、適切な拡張機能（PRRTADV）を使用してエージェント広告をユニカストすることにより、OFAに返信します。このメソッドは、モバイルIPv4メッセージの[1]のTTL制限を削除します（つまり、TTL = 1はここでは適用されません）。OFAとNFAは1杯以上離れている可能性があり、安全なユニキャストメッセージには不要なため、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.
実際の問題として、OFAは、実際のハンドオフ手順中に勧誘を実行しないように、既知の隣接FASからの既知のFASの広告を事前にキャッシュする必要があります（セクション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）に続いて、NFAはトンネルエージェントの広告をMNにOFAを介して送信する必要があります。Tunneling NFA広告は、NFAがOFAおよびMNのIPv4アドレスを認識していることを前提としています。これらのIPv4アドレスは、ネットワーク開始の場合にNFAで受信されたL2トリガーに含まれるFAおよびMN識別子によって取得されます（セクション3.2を参照）。ただし、[1]では、TTLはNFAのエージェント広告の1でなければなりません。したがって、[1]のTTL制限が緩和されている場合、トンネリング広告が適用されます。この目的のために、このメッセージを認証し、TTLの制限を緩和するために、OFAとNFAの間の事前に確立されたセキュリティ協会が整っている必要があります。実装がこれを必要とする場合、FA間セキュリティ協会が確立されるときにトンネルを構成する必要があります。トンネル付きICMP広告は、NFAとOFAの間のトンネルモード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）で隣接するNFAを求めるために、OFAでプロセスを導入する必要があります。この間隔は、ネットワーク帯域幅とNFA処理リソースの不必要な消費を避けるために、小さすぎて設定してはなりません。min_solicitation_intervalの最小値は1秒です。[7]のFAチャレンジ/応答メカニズムを使用する場合、Min_Solicitation_intervalは、MNが登録要求を発行する前にNFAチャレンジが期限切れにならないように、チャレンジが有効な時間の窓よりも小さい値に設定する必要があります。したがって、OFAのmin_Solicitation_intervalの推奨デフォルト値は（0.5 * NFAのChallenge_Window * NFAのエージェント広告インターバル）です。Challenge_Windowおよびエージェント広告間隔は、それぞれ[7]と[1]で定義されています。最小要件は、min_solicitation_intervalが手動で構成可能である必要がありますが、可能なオートコンチュレーションメカニズムはこのドキュメントの範囲外であることです。特定の実装およびNFA広告間隔が非常に少ない場合の広告キャッシングを許可するには、NFAの実装がNFA-ofaインターフェイスの異なるChallenge_WindowおよびAgent Advertisementインターバル設定を許可する必要がある場合があります。
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.
OFAは、隣接するNFAから最新の広告をキャッシュする必要があります。この広告は、TTL = 1でメッセージ2BのMNに送信する必要があります。OFAには、隣接するNFAのリストを作成するためのメカニズムも設置されている必要があります。各FAの最小要件は、MNがL3ハンドオフを実行できるNFAアドレスのリストの手動構成を可能にする必要があることです。このリストのFAアドレスは、展開と無線のカバレッジに依存します。NFA発見を達成するために別のプロトコルを指定することもできますが、これはこのドキュメントの範囲外です。
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がMNに発見されたFAの使用を阻止するローカル定義のポリシーがない限り、MNが広告を受け取る新しい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は、デフォルトのルーターをOFAからNFAに変更する必要があります。MNは、[1]で説明されているように、事前登録手順が完了するとすぐに（つまり、登録返信がMNによって受信される）とすぐに、デフォルトのルーターをNFAに変更する必要があります。
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]で説明されているように、次の変更を行います。上記の指定された移動検出メカニズムと、L2-MTを使用して特別な拡張（PRRTSOL）でエージェントの勧誘を開始する能力。また、MNがL2-LUトリガー（つまり、新しいインターフェイスまたはリンクがアップされている）を受信した場合、そのインターフェイスですぐにエージェントの勧誘[1]を送信する必要があります。エージェントの勧誘[1]を受信するNFAは、それをL2-LUトリガーイベントとして使用し、[1]によれば、MNのIPv4/レイヤー2アドレス（つまり、アドレス解像度プロトコル（ARP）エントリ）を記録します。その時点で、NFAは、以前にバッファリングされた登録返信を含め、MNにデータの配信を開始します。NFAは、他のL2メカニズムを使用して、MNが新しいリンクに接続したことを以前に検出し、データへの転送を開始する場合があります。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はPRRTADVメッセージ（つまり、LLA拡張機能を備えたエージェント広告）を受信しなくなります。MNがまだL2-MTSを受信している場合、PrRTSOLメッセージを送信しようとします。通常のFAは、通常のエージェント広告[1]で返信します。MNがPRRTSOLに返信してPRRTADVを受け取らない場合、PRE_SOL_INTERVAL秒後にPRRTSOLメッセージを1回再送信し、その後、送信間隔の指数バックオフを使用して別のPRE_SOL_ATTEMPTを使用する場合があります。PRRTADVが最後の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トリガーまたはPRRTADVメッセージの受信を開始します。MNがL2-MTトリガーまたはPRRTADVメッセージを受信すると、事前登録手順に従う必要があります。
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は現在の最初のホップルーターではないFA（NFA）に登録しています。したがって、NFAに到達するMNの登録要求を含むイーサネットフレームのL2アドレスは、MNのアドレスではありません。したがって、FAは、[1]で指定されているように、受信登録要求のイーサネットアドレスをMNのL2アドレスとして使用してはなりません。これは、ワイヤレスアクセスポイントがブリッジまたはルーターである場合に適用され、FAがワイヤレスアクセスポイント自体に実装されているかどうかとは無関係です。この場合、MNの登録要求（または地域登録要求）は、登録メッセージにL2アドレス拡張機能を使用する必要があります。このようなL2アドレスは、MNが移動するにつれて一定のままであるL2アドレスと同じL2アドレス、またはNFAのMNのL2アドレスです。L2アドレスを通信するために、MNには、登録要求（または地域登録要求）メッセージを含む一般化されたリンクレイヤーとIPアドレス拡張（セクション9を参照）が含まれています。この拡張機能が存在する場合、FAは拡張機能に含まれるL2アドレスを使用してMNと通信する必要があります。特定のワイヤレスL2テクノロジーがワイヤレスネットワークへの特別なインターフェイスを定義した場合、FAは拡張機能を使用する必要なくMNのIPv4アドレスとそのL2アドレスのマッピングを解決できる場合、L2アドレス拡張コンテンツを破棄することができます。上記の同じ理由で、MNは、エージェント広告メッセージ（PRRTADV）のソースL2アドレスをデフォルトルーターのL2アドレスとして使用してはなりません。したがって、NFAには、一般化されたリンクレイヤーとIPアドレスの拡張機能（セクション9.3を参照）をエージェント広告（PRRTADV）メッセージを含める必要があります。
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ハンドオフの予測が必要な場合です。登録前のハンドオフ法のセキュリティは、AAAの使用を含む[1]と同じセキュリティモデルに基づいています。事前登録の前提条件は、FAまたはMNが保留中のL2ハンドオフ手順を通知するL2トリガーを取得できることです。L2ハンドオフのターゲットは、新しいFAのカバレッジエリアにある別のアクセスポイントまたは無線ネットワークです。L2トリガー情報は、ワイヤレスネットワークに固有のメソッドを使用してIPv4アドレスに解決する必要がある識別子の形である場合があります。たとえば、OFAまたはMNが、新しいFAのアドレスのIPv4アドレスを決定した場合、登録前のハンドオフを開始すべきではありません。
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が、たとえば同じまたは異なるテクノロジー内のサービスコストのために、あるアクセスの優先順位を決定するローカルで定義されたポリシーを持っている場合、したがって、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.
登録後のハンドオフ法は、双方向のエッジトンネル（BET）または単方向トンネルを使用して、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とOFAの間のモバイルIPv4登録が成功した後、OFAはアンカーFA（AFA）と呼ばれるMNのモビリティアンカーポイントになります。MNがOFAからNFAに移動すると、ワイヤレスリンク上でシグナリングを実行してNFAに登録する場合、MNはL3ハンドオフを延期し、AFAを使用し続けることができます（つまり、この場合はOFA）。NFAに登録する前にMNが3番目のFAに移動した場合、特定のケースでは後述する場合、3番目のFAはAFAを信号し、BETのワイヤレスリンクエンドをNFAからITに移動します。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.
OFA/AFAとNFAの間のメッセージは認証する必要があります。最小限の要件は、低遅延のハンドオフに関与するすべてのFAが、共有キーと[1]のデフォルトアルゴリズムを含む他の隣接するFAとのセキュリティ関連の手動の事前構成をサポートする必要があることです。登録後のFAは、[11]で指定されたFA間認証拡張機能（FA-FA認証拡張機能）を実装する必要があり、さらに他のセキュリティメカニズムを使用する場合があります。
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.
2パーティのハンドオフは、MNがOFAからNFAに移動すると発生します。通常、この動きはNFAで新しいモバイルIPv4登録をもたらします。ただし、登録後、MNとNFAはこれを遅らせる可能性がありますが、OFAとNFAの間の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-ツーパーティハンドオフ（登録後）
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.
以下は、2パーティのハンドオフの進捗について説明しています。番号付き項目は、図6の手順を指します。トンネル作成のためのソーストリガーHRQST/HRplyメッセージ、トンネル作成のためのターゲットトリガーHRQST/HRplyメッセージ、およびBET（または単方向トンネル）を拡張または終了するためのHRQST/HRplyそれぞれ接尾辞、（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) OFAまたはNFAのいずれかがL2トリガーを受け取り、特定のMNがOFAからNFAに移動しようとしていることを通知します。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トリガーは、OFAのソーストリガー（L2-ST）です。トリガーには、NFAのMNのL2アドレスと識別子が含まれます（IPv4アドレス自体またはNFAの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トリガーは、NFAのターゲットトリガー（L2-TT）です。トリガーには、OFAのMNのL2アドレスと識別子（IPv4アドレス自体またはOFAの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は、ハンドオフ要求（HRQST）を他のFAに送信します。2つのケースがあります。A）OFAがHRQSTを送信している場合、Hビットが設定され、Nビットが設定されていて、HRQSTであることを示します。HRQSTには、OFAが喜んでサポートするトンネルの寿命、MNのIPv4ホームアドレス、MNのHAアドレス、およびMNのL2アドレスを備えたLLAオプションが含まれています。寿命がゼロであり、tビットが設定されていない場合、OFAはMN用のパケットをトンネルにしようとしません。ポジティブな寿命とセットTビットは、OFAが指定された時間のためにトンネルを喜んでトンネルにしていることを示しています。セクション4.5では、HRQST（S）とセクション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) NFAがHRQSTを送信している場合、Nビットが設定され、Hビットが設定されており、HRQST（T）であることを示します。Tビットが設定されている場合、NFAは逆トンネルを要求し、HRQST（T）にはNFAが要求しているトンネルの寿命が含まれています。HRQST（T）には、MNのL2アドレスを含むLLAオプションも含まれています。MNのIPv4ホームアドレスとHAアドレスは、このドキュメントの範囲外の何らかの手段で発見されない限り（たとえば、L2-TTの一部として）送信されません。セクション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).
a) OFAがHRを送信している場合、Nビットが設定され、HおよびRビットが設定されています。これは、応答がHRQST（t）に応答していることを示しています。つまり、HRply（t）です。tビットが設定されている場合、HRply（t）にはトンネルの寿命が含まれています。それ以外の場合、トンネルの寿命はゼロに設定されており、OFAがトンネルサービスを提供する意思がないことを示しています。HRply（T）とHRQST（T）の両方がTビットセットと非ゼロの寿命を持っている場合、賭けが確立されます。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).
b) NFAがHRplyを送信すると、Hビットが設定され、NおよびRビットが設定されており、これがHRQSTへの応答であることを示しています。つまり、HRply（s）です。Tビットが設定されている場合、NFAは逆トンネルを要求することを示し、寿命フィールドは要求されたトンネルの寿命とともに設定されます。Tビットは、OFAが対応するHRQSTにTビットを設定した場合のみ、またはNFAがイングレスフィルタリングがネットワーク上で有効になっているため、トンネル入降りパケットをOFAに逆転させる必要がある場合にのみ、HRplyに設定できます。これは賭けを確立します。NFAが要求するトンネル寿命は、HRQSTでOFAが提供するトンネル寿命以下でなければなりません。セクション4.6では、HRPLY（S）について説明します。
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ハンドオフ中のポイントは、OFAおよびMNでのL2-LDトリガーによってシグナルになります。L2ハンドオフの完了は、NFAおよびMNでのL2-LUトリガーによって通知されます。トリガーは次のように処理されます。
a) When oFA receives the L2-LD trigger, it begins forwarding MN-bound packets through the forward tunnel to nFA.
a) OFAがL2-LDトリガーを受信すると、フォワードトンネルを介してNFAに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.
b) NFAがL2-LUトリガーを受信すると、OFAからMNにトンネルされたパケットの配信を開始し、通常のルーティングメカニズムを使用して、またはOFAまたはHAへの逆トンネルを使用してMNからアウトバウンドパケットを転送します。この時点でのNFAは、まだMNのデフォルトルーターではない場合があります（セクション4.4を参照）。したがって、MNからすべてのアウトバウンドパケットを受信するには、NFAはL2-LUトリガーを受信したときにUnicast Proxy ARPメッセージ（[1]で使用されている）をMNに送信する必要があります。このプロキシARPメッセージは、OFAに代わってNFAによって送信されたARP返信[5]であるため、送信者ハードウェアアドレスフィールドにNFAリンクレイヤーアドレスと、ターゲットプロトコルアドレスフィールドにOFA IPv4アドレスを提供します。
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).
c) MNがL2-LUを受信すると、[1]に記載されているようにエージェント広告を求めることにより、モバイルIPv4登録プロセスを開始する場合があります。登録が成功した場合、NFAはOFAからアンカー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.
5) MNがNFAとのモバイルIPv4登録を実行する前に、MNが3番目のFAに移動する場合、OFAは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のハンドオフがステップ4で失敗した場合（L2の理由により）、Ping-Pongの状況が発生した場合、OFAはトリガーメカニズムを介してこのケースを決定できる可能性があります（つまり、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.
OFAがHRQST/HRPLYでBビットを設定し、NFAがTビットを設定して逆トンネルを要求していない場合、NFAはMNからHAに発信パケットをトンネルする必要があります。NFAは、NFAとMNのHAの間にセキュリティが不要な場合、または既存のNFA-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トリガーに依存します。OFAからNFAへの前方トンネルは、[1]に記載されているトンネル手順の1つを使用して構築され、トンネルの端がそれぞれOFAとNFAにあるという違いがあります。NFAからOFAへの逆トンネルは、[3]に記載されているように構築され、トンネルのネットワーク端がHAの代わりにOFAにあるという違いがあります。前方トンネルと逆トンネルの両方が確立されている場合、ベットが確立されています。上記のように最適なL2トリガー情報を使用すると、FASはL2ハンドオフを開始するときにすぐにBETを設定できます。MNへのリンクがダウンしたときにMNバウンドデータを開始し、NFAがリンクアップトリガーを使用できます。パケットの配信を開始します。最適な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.
図7と8は、ソーストリガー（L2-ST）とターゲットトリガー（L2-TT）の2つのパーティハンドオフのタイミング図をそれぞれ示しています。
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-二パーティのソーストリガーハンドオフタイミング
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登録を実行することにより、プロセスを完了します。これは、[1]のように、エージェント広告を送信するFAまたはエージェント広告を求めるMNによって開始される場合があります。
3) The MN moves to a third FA (see Section 4.2)
3) MNは3番目の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.
3パーティのハンドオフは、すでに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).
3パーティのハンドオフ関数の必要性は、登録後のワイヤレスシステムに依存します。MNがあるFAから別のFAに非常に迅速に移動できるラジオL2プロトコルの場合、MNとのモバイルIPv4登録が完了しない確率が存在する可能性が存在するため、HTT（3番目へのハンドオフ）は実装。特定のワイヤレスシステムと実装では、FAS間のこのような速い動きを許可しないため、L2ハンドオフ直後にモバイルIPv4登録が発生する可能性があります。この場合、3パーティのハンドオフは適用されません。この3パーティのハンドオフ機能が実装されていない場合、FAはL2ハンドオフが完了した後（NFAでL2-LU）、および/またはMNがL2ハンドオフ後のエージェント広告（L2-LU（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ハンドオフは、MN/FAによる決定のために延期できます（つまり、MNはエージェントの勧誘を送信しない、FAはエージェント広告を送信しません）、または十分に許されないNFAの間の急速な動きに起因する場合があります。登録が完了する時間。このシナリオを図9に示します。この場合、OFAはNFA（つまり、3番目のFA）に、トンネルの無線端を移動することについてAFAに連絡するように通知する必要があります。これは、HTTメッセージで実行されます。3パーティのハンドオフ手順の背後にある一般的な考え方は、OFAがAFAからNFAにハンドオフが発生した場合、L2-TTを介して取得したのと同じ情報をNFAに提供するということです。次に、NFAは、BETをNFAに移動するために、AFAでHRQST（T）/HRply（T）シーケンスを実行します。L2ハンドオフが完了した場合、OFAは以前のベットを終了するためにHRQST（R）をAFAに送信します。
The following describes the progress of a three-party handoff. The numbered items refer to steps in Figure 9.
以下は、3人のハンドオフの進捗状況について説明しています。番号付きアイテムは、図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) OFAまたはNFAのいずれかがL2トリガーを受け取り、特定のMNが移動しようとしていることを通知します。2つのケースは次のとおりです。a）L2トリガーは、OFAのソーストリガー（L2-ST）です。トリガーには、NFAのMNのL2アドレスと識別子が含まれています（IPv4アドレス自体またはNFAの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トリガーは、NFAのターゲットトリガー（L2-TT）です。トリガーには、OFAのMNのL2アドレスと識別子（IPv4アドレス自体またはOFAの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) OFAとNFAは、HTT/HRPLYまたはHRQST/HTTペアを交換します。HTTは、HRQSTまたはHRplyにHビットとNビットの両方を設定することによって示されます。トンネルはOFAとNFAではなくAFAとNFAの間で交渉されているため、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です。OFAは、MNのホームIPv4アドレス、MNのHAアドレス、AFAのIPv4アドレスを含むLLA、およびMNのL2アドレスを含むLLAを含むNFAにHTTを送信します。これは、NFAがAFAでターゲットトリガーされたハンドオフを実行するのに十分な情報です。NFAはHRplyで応答します。セクション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です。NFAは、2パーティのハンドオフが発生しているかのように、HRQST（T）をOFAに送信します。OFAは、a）上記と同じ情報を含むHTTで応答します。これは、NFAが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を受け取ると、NFAは最初に訪問者キャッシュをチェックして、MNのトンネルが既にトンネリングされているかどうかを確認します。その場合、ステップ6が実行されます。そうでない場合、NFAは、セクション4.1とまったく同じように、AFAでターゲットトリガーされたハンドオフを実行し、HRQST（T）/HRply（T）ペアを交換します。AFAは、L2ハンドオフがいつ開始されるかを示すL2トリガーを受け取らないため、HRPLY（T）の伝達時にNFAへのトンネルを開始する可能性があります。
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がL2で切断されると、AFAとOFAの交換メッセージがAFAとOFAの間のトンネルサービスをキャンセルし、AFAがNFAでトンネルを開始できるようにします。
a) The point in the L2 handoff process where the MN gets disconnected from oFA is signaled at oFA by L2-LD.
a) MNがOFAから切断されるL2ハンドオフプロセスのポイントは、L2-LDによってOFAで通知されます。
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は、AFAと寿命ゼロを持つHRQST（R）/HRply（R）ペアを交換します。これは、OFAとAFAの間のトンネルサービスをキャンセルします。AFAがNFAへのトンネルをまだ確立していない場合、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ハンドオフの完了は、NFAおよび/またはMNでのL2-LUトリガーによって通知されます。NFAとMNは、次のようにトリガーを処理します。
a) The nFA provides packet delivery service to the MN exactly as described in Section 4.1, Step 4b.
a) NFAは、セクション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) NFAとAFAが同じ（つまり、MNが元のアンカーFAに戻っている）という特別なケースでは、AFAは、ステップ3で訪問者キャッシュをチェックするときにOFAにトンネリングしていることを認識しています。この場合、この場合、AFAが手順3でHRQST（T）/HRply（T）を送信する必要はありません。L2-LUトリガーがハンドオフ完了時に受信すると、AFAはパケットのルーティングを開始し、NFAへのトンネルが取り壊されます。OFAは、AFAとNFAが同じであるが冗長であるという先験的なことを知ることができないため、ステップ4BのHRQST（R）/HRply（R）をステップ4BのAFAとまだ交換しています。
Figures 10 and 11 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) three-party handoff, respectively.
図10と11は、ソーストリガー（L2-ST）とターゲットトリガー（L2-TT）の3パーティのハンドオフのタイミング図をそれぞれ示しています。
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:
2パーティのハンドオフとは異なり、AFAとNFAの間のBET確立のタイミングは、L2トリガーシグナリングL2ハンドオフを受け取らないため、L2トリガー情報の可用性に完全に依存することはできません。AFAがNFAに賭けをすることができる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は、ターゲットトリガーされたハンドオフの要求に応じてHRply（T）をNFAに送信した後、NFAへの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は、NFAへのBETを使用してトンネルパケットを開始し、OFAからHRQST（R）を受信したときにOFAでBETを取り壊し、MNが切断されていることを示します。
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.
さらに、HRQST（R）が受信されるまで、AFAが選択された場合、OFAへのトンネリングを継続する場合があります。この場合、MNは切断されるまで（L2-LD）を古いL2のパケットを通過するため、MNで結果が複製される可能性があります。2）が選択されている場合、追加のレイテンシはMNのL3サービス破壊期間に追加されます。もちろん、AFAは、L2-ST/L2-TTからMNの切断（L2-LD）の間の期間に信頼できる境界が利用可能な場合、1）から2）の間に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".
寿命がなくなったときに賭けが期限切れないようにするために、MNの現在のFAはAFAに賭けを更新または終了するように信号を送ります。これは、MNがモバイルIPv4登録をdefする場合の場合があります。そのような信号が受信されない場合、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（1）に指定）と他のFA（図のFA（2）に指定）の間で発生するメッセージ交換を示しています。HRQST（R）/HRPLY（R）は、HRQST/HRPLYメッセージにRビットを設定することにより示されます。HRQST（R）が賭けを更新している場合、ゼロ以外の寿命が含まれています。それ以外の場合、寿命がゼロに設定されている場合、トンネルの終了を示します。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登録を延期することを決定する場合がありますが、3つの可能なイベントはトンネリングサービスを終了する必要性につながる可能性があります。これが発生した場合、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) 賭けの終末は保留中であり、現在のFAからの更新のためのAFAへの要求は拒否されました。あるいは、現在の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自体は、[1]のようにエージェントの勧誘を送信することにより、モバイルIPv4登録を実行することを決定し、それを開始します。
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) ソーストリガーのハンドオフ中、OFAはベットハンドオフを実行しようとしますが、NFAはそれを実行することができません。この場合のFAは、[1]のようにMNをエージェント広告を送信することにより、モバイルIPv4登録を開始する必要があります。HRQST（T）は、登録後をサポートしないNFAによってOFAに送信されないため、ターゲットトリガーのハンドオフ中にこの状況が発生しないことに注意してください。
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に関連するいくつかの詳細なシナリオについては、今後説明されます。[1]によると、FAのケアオブアドレスを使用する場合、MNはFAをデフォルトルーターとして使用する場合があります。それ以外の場合は、エージェント広告のICMPルーター広告部分に宣伝されているものからデフォルトのルーターを選択する必要があります。ここでは、FAルーターもMNのデフォルトルーターであると仮定します。登録後、OFAとNFAの間にトンネルが確立され、MNがNFAに移動した場合、OFAはエージェント広告をMNに送信してはなりません。この場合、MNは長期間エージェント広告を受け取らない可能性があります。[8]によると、ホストはルーター広告の寿命が期限切れになり、それ以上の広告が受信されない場合、デフォルトのルーターエントリを削除します。ICMPルーター広告のライフタイムは、モビリティエージェント広告拡張機能の登録寿命とは関係ないことに注意してください[1]。この混乱を回避するために、MNは、アクティブなデフォルトルーターエントリの寿命がなくなる前に、デフォルトのルーター（つまり、FA）を求める必要があります。）。これは、ICMPルーター広告で構成されているように、Active Default Routerの残りの寿命である限り、MNがせいぜいモバイルIPv4登録を延期できることを事実上意味します。MNは、登録後のハンドオフ後にエージェント広告を受信したときにモバイルIPv4登録[1]を実行する必要があります。
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）[1]に掲載された新しいモバイルIPv4メッセージです。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ビットが設定されていない場合、リクエストがOFAの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ビットが設定されていない場合、要求がNFAでの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 HRQSTを発行するFAは、トンネルの[1,5]で定義されている最小限のカプセル化を使用します。
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.
g HRQSTを発行するFAは、トンネルの[1,5]で定義されているように、一般的なルーティングカプセル化（GRE）[4]を使用します。GREタイプとキーフィールドを含むHRQSTの拡張は、このドキュメントの範囲外です。
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.
Tの場合、HRQSTは、OFAが前方トンネルサービスの両方をサポートすることをいとわないことを示しています。HRQST（T）の場合、NFAが逆トンネルサービスを要求していることを示します。
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で送信された場合、MNがHAへの逆トンネルを要求したこと、およびNFAがOFAへの逆トンネルにならない場合は、NFAが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）の場合、寿命はNFAによる逆トンネルの要求を表します。これがHRQSTである場合、寿命は、OFAが前方トンネルと逆トンネルの両方を維持することをいとわない最大時間を表します。これがHRQST（R）の場合、生涯はトンネルの生涯を更新するための時間の要求を表します。HRQSTの値は、OFAがトンネルサービスを付与したくないことを示しています。HRQST（T）の0の値は、NFAが逆トンネルサービスを必要としないことを示します。HRQST（r）の値0は、トンネルを終了する必要があることを示します。0xffffの値は無限を示します。
MN Home Address For HRqst(s), the home address of the MN.
MNのHRQSTのホームアドレス、MNのホームアドレス。
HA Addr For HRqst(s), the HA address of the mobile node.
HRQSTのHAアドレス、モバイルノードの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.
拡張メッセージには、FAのIPv4アドレスにマッピングできるMNのL2アドレスとL2アドレスを含むLLA（セクション9を参照）を含める必要があります。このメッセージには、HRQSTメッセージを保護するために使用されるFA-FA認証拡張機能[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）[1]に掲載された新しいモバイルIPv4メッセージです。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である場合、寿命はNFAの要求を表し、HRQSTで送信される最大値までの値になる可能性があります。より大きな値は、OFAの最大値にデフォルトであると想定されます。これがHRply（t）の場合、寿命はOFAがNFAに付与する最大時間を表します。これがHRply（R）の場合、寿命はトンネルの寿命が延長される時間を表します。コードフィールドがハンドオフが失敗したことを示した場合、寿命フィールドは無視され、ゼロに設定する必要があります。hrply（t）での値は、OFAがサービスを許可したくないことを示しています。hrplyの値は、NFAがサービスを必要としないことを示します。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に応答していることを示します。
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.
r返信がHRply（r）の場合は設定します。HもNビットも設定されていません。
M The FA issuing the HRqst will use Minimal Encapsulation as defined in [1,5] for the tunnel.
M HRQSTを発行するFAは、トンネルの[1,5]で定義されている最小限のカプセル化を使用します。
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.
g HRQSTを発行するFAは、トンネルの[1,5]で定義されている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.
tの場合、HRply（S）は、NFAがトンネルサービスを逆転させることを要求していることを示します。HRply（t）の場合、OFAが前方トンネルサービスの両方を喜んで提供していることを示します。
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への逆トンネルを要求したこと、およびNFAがOFAへの逆トンネルにならない場合は、NFAがHAの逆トンネルを使用することを示します。対応するHRQST（T）でTビットが設定されていない場合にのみ、HRply（t）で設定できます。
MN Home Address For HRply(t), the home IPv4 address of the MN.
MNのHRPLY（T）のMNホームアドレス、MNのホームIPv4アドレス。
HA Addr For HRply(t), the HA IPv4 address of the MN.
Hrply（t）のha addr、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.
拡張このメッセージには、HRplyメッセージを保護するために使用されるFA-FA認証拡張機能[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ハンドオフ要求とハンドオフ応答メッセージと同じ形式を持っています。ただし、HビットとNビットの両方が設定されています。HTTメッセージがL2-STに応じて送信され、ハンドオフを開始するために送信される場合、HおよびNビットを除き、メッセージには同じフィールドセットがあり、HRQSTと同じ拡張機能が含まれます。。HTTメッセージがHRQST（T）に応じて送信される場合、HおよびNビットを除き、メッセージには同じフィールドが設定されており、HRPly（T）と同じ拡張機能が含まれます。BET構造はOFAとNFAの間で交渉されないため、トンネルビットをHTTメッセージに設定してはなりません。それは、その後のHRQST（T）/HRply（T）でNFAと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.
登録後のハンドオフアプローチにより、FAは保留中のハンドオフについて直接通信することができ、L2ハンドオフイベントの前にMNとの間でIPv4層メッセージを送信する必要はありません。したがって、ハンドオフレイテンシの可能なソースを排除します。これは、MNがラジオカバレッジエリアから急速に移動している場合など、リンクレイヤーがハンドオフが発生しなければならない時期にハード締め切りを課す場合に必要になる場合があります。その結果、登録後は、主に同じラジオアクセステクノロジーをサポートするFA間のハンドオフに関心があります。不均一な無線技術間のハンドオフは、必然的に、MNとネットワーク間の相互作用を必要とするため、登録後の適用性の領域ではありません。
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ハンドオフが保留中であることをOFAまたはNFAに通知する不特定のメカニズムによってトリガーされるため、登録後のアプローチは、そのようなメカニズムが利用可能なネットワークにのみ適用されます。たとえば、L2は、OFAまたはNFAが登録後のハンドオフメッセージを送信する原因となる無線信号品質の兆候を提供する場合があります。また、そのような適応症は、メッセージを適切な場所に送信できるように、ハンドオフに関与する各FAを相手のアイデンティティと提供する必要があります。これには、L2情報をFA IPv4アドレスにマッピングすることが含まれます。また、ハンドオフに関与するFASには、登録後のメッセージを認証できるように、事前に解決されたセキュリティの取り決めが必要です。登録後のメッセージングの結果としてハンドオフが完了する場合、L2ハンドオフの適応症も安全に認証される必要があります。
POST-REGISTRATION handoff is appropriate in the following cases:
登録後のハンドオフは、次の場合に適切です。
- 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.
結合された方法では、登録前と登録後の両方のハンドオフの両方を使用します。NFAのタイマーの有効期限の前に事前登録が完了しない場合、登録後のメカニズムを使用して、OFAとNFAの間にトンネルを作成します。これにより、モバイル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).
NFAがターゲットトリガーを受信すると、登録前の手順に従います。結合されたメソッドを使用する場合、NFAはターゲットトリガーを受信したときにタイマーも起動する必要があります。タイマーは小さな値に設定する必要があります（ターゲットトリガーケースのデフォルト：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).
事前登録によると、NFAはMNから登録要求を受け取ります。結合された方法を使用する場合、MNから送信されたこの登録要求は、FA IPv4アドレスLLA拡張機能にOFAのIPv4アドレスを含める必要があります（セクション9.7を参照）。この同じ登録リクエストメッセージには、事前登録について説明されているように、LLA拡張機能にMNのレイヤー2アドレスも含まれるため、複数のLLA拡張機能が含まれます（セクション3.7および9を参照）。NFAがターゲットトリガーを使用してハンドオフ手順を開始していない場合（つまり、モバイル開始またはネットワーク開始ターゲットトリガーケース）、NFAは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.
すべての場合において、登録返信メッセージがNFAによって受信されるときにタイマーをリセットする必要があります。登録返信が受信される前にタイマーが期限切れになった場合、NFAは登録後の手順を開始する必要があります。NFAは、NFAとOFAの間にトンネルを作成するために、登録後のHRQSTメッセージの宛先としてOFA IPv4アドレス（以前に登録要求メッセージの延長で受信）を使用します。NFAは、そのMNの成功した登録返信を受け取って転送するときにこのトンネルを取り壊す可能性があります。
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.
登録前と登録後のハンドオフで考慮される最適なケースでは、接続の直後にパケットをNFAを介してMNに配信できるようにタイムリーなL2トリガーが受信されると想定されました。このようにして、MNはL3ハンドオフのために混乱を招くことはありません。ただし、実際のL2ハンドオフイベントに関するL2トリガーとハンドオフメカニズムのこのような正確なタイミングは、すべてのワイヤレスシステムでは不可能であり、特定の実装手法に依存する可能性があります。したがって、MNとNFAの間のL2接続が完全に確立され、L3トラフィックに使用できるように、L3にはいくつかの不確実性が存在する可能性があります。特定の実装では、MNとNFAの接続が完全に確立される瞬間に関して、トラフィックが早すぎるか遅すぎる可能性があります。この問題を解決し、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]を要求する場合があります。登録後の場合、MNがOFAで以前に逆トンネリングを要求していた場合、OFAからのハンドオフメッセージ（セクション4を参照）には、訪問者のエントリの賭けを確立するためにNFAに通知できる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.
1) 空気リンクでのメッセージの紛失PRRTSOLおよびPRRTADV。
2) Loss of the solicitation by an FA to obtain another neighboring FA's Advertisement or loss of the neighboring FA's advertisement.
2) FAによる勧誘の喪失により、別の近隣のFAの広告または隣接するFAの広告の喪失を取得します。
3) Failure of the standard Mobile IPv4 Registration.
3) 標準のモバイルIPv4登録の障害。
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）に応じてOFAによって送信されたPRRTADVまたはターゲットトリガー（L2-TT）に応じてNFAが送信した広告がMNに到達できなかった場合、事前登録ハンドオフはネットワーク開始ハンドオフで失敗する可能性があります。。MNから送信されたPRRTSOLまたはOFAから送信されたPRRTADVの返品のいずれかが削除された場合、モバイル開始ハンドオフでは、事前登録ハンドオフも失敗する可能性があります。prrtadvとprrtsolが失われる確率を減らすために、MNとFAはこれらのメッセージの複数のコピーを送信する可能性があります。とにかくこれらのメッセージが失敗した場合、どちらの場合も、MNは事前のシグナルを受け取っていない場合はNFAに接続します。この場合、MNは、セクション3.6で説明されているように、L2（L2-LU）でNFAに接続するときにFA広告を求め、[1]で指定されているようにNFAとの標準的なモバイル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からの対応する広告が失われる可能性があります。これらのメッセージが失われる可能性を減らすために、FAはこれらのメッセージの複数のコピーを送信する場合があります。とにかく障害が発生した場合、Agent Advertisementを勧誘するFAは、ソーストリガーまたはモバイル開始のPRRTSOLに応じてPRRTADVを送信できません。これらの場合、MNが事前登録ハンドオフの通知または確認を受け取らない場合、MNはセクション8.1.1で説明されているように、NFA（L2-LU）に接続するとすぐに標準のモバイル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メッセージで応答することはありません。ハンドオフがソースがトリガーされている場合、NFAはハンドオフを決して学習せず、OFAは確認を受けません。ハンドオフがターゲットトリガーされている場合、OFAはハンドオフを決して学習せず、NFAは確認を受けません。
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).
この場合の回復手順は次のとおりです。OFAは、MNがソーストリガーされている場合、MNがオフリンク（L2-LD）を移動するときに前方トンネルを構築してはなりません。ターゲットがトリガーされています。NFAがHRQSTメッセージによるハンドオフを通知されなかった場合（ソーストリガーされたハンドオフの障害に対応）、またはHRPLYメッセージによってハンドオフが確認されなかった場合（ターゲットトリガーハンドオフの障害に対応）、NFAはユニカストしなければなりません。L2接続が確立されるとすぐにMNへのエージェント広告（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.
ターゲットトリガーされたハンドオフで、OFAは、HRplyを送信したためにハンドオフが確認されていると想定していますが、NFAはそれを受け取っていないため、確認がありません。OFAは、MNがリンク（L2-LD）から移動すると、NFAにパケットをトンネリングします。NFAは、L2リンクがアップ（NFAでL2-LU）が増えるとすぐにFA広告をMNに送信し、トンネルパケットをドロップする必要があります。NFAは、ICMP宛先を到達不可能な[9]メッセージにOFAに送信する必要があります。OFAがこのメッセージを受信すると、トンネルを終了し、パケットの転送を停止します。逆トンネルが要求された場合、NFAはハンドオフ確認を受けていないため、トンネルを逆転させてはなりません。
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.
ソーストリガーハンドオフでは、NFAはHRplyを送信したためにハンドオフが確認されていると想定していますが、OFAはそれを受け取っていないため、確認がありません。障害の回復がなければ、MNはMNのパケットのフォワードトンネルを開始できずにNFAに移動することができ、MNはハンドオフが失敗したことがわからないため、モバイルIPv4登録を開始できません。この状況では、OFAは、MNがリンク（L2-LD）を離れるとすぐに、生涯ゼロでNFAにHRQSTメッセージを送信する必要があります。OFAは、config-hfail秒の指数バックオフを使用して、またはトンネルをキャンセルするリクエストを明確に確認するまで、HRQSTメッセージを再送信し続ける必要があります。config-hfailのデフォルト値は10秒です。NFAがHRQSTを受信した場合、トンネルがキャンセルされるたびにある場合のように、すぐにエージェント広告をMNに送信する必要があります。さらに、OFAは、NFAから逆トンネルから受信したパケットをドロップする必要があります。OFAは、NFAがHRQSTメッセージによって通知されてトンネルをキャンセルするため、ICMP宛先の到達不可能なメッセージをNFAに送信するべきではありません。ただし、NFAがHRQSTを受信する前にトンネルのICMP宛先の到達不可能なメッセージを受信した場合、Tunnelをキャンセルする場合は、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アドレス（LLA）拡張機能を定義します。これは、リンクレイヤーとIPv4アドレスを通信する必要があるノードで使用されます。拡張機能の形式はサブタイプに依存しており、各サブタイプは独自のサブ構造を定義します。このドキュメントでは、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（skippable）[1] - 登録リクエストで使用した場合140（skippable）[1] - エージェント広告で使用する場合
Length
長さ
The length of the Link Layer Address + the one-octet Sub-Type field
リンクレイヤーの長さは、One-OCTETサブタイプフィールドにアドレスしています
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リンクレイヤーアドレス拡張には、国際的なモバイルステーションID（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フィールドの長さワンオクテットサブタイプフィールド
Sub-Type
サブタイプ
1
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>：<接続id>ここで、<imsi>は国際モバイルステーションのアイデンティティのASCIIベースの表現であり、最も重要な数字最初の "："はASCII 0x3a、接続IDが含まれています。同じモバイルデバイスと異なるリンク層接続を区別するために使用される小型の小数の小数のASCII表現です。
The IMSI Link Layer Address Extension contains the International Mobile Station Identity.
IMSIリンクレイヤーアドレス拡張には、国際的なモバイルステーションのIDが含まれています。
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フィールドの長さワンオクテットサブタイプフィールド
Sub-Type
サブタイプ
2
2
IMSI
imsi
Contains the IMSI, a number composed of 15 digits or less, coded as described in [15].
[15]で説明されているように、15桁以下で構成される数字であるIMSIが含まれています。
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
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].
64ビットグローバル識別子（EUI-64）アドレス拡張には、[6]で定義されている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
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アドレス拡張には、勧誘されているエージェント（FA）のIPv4アドレスが含まれています。この拡張機能は、セクション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
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
6
AP ID
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で説明されているようにOFAを識別する登録要求メッセージに存在する場合があります。
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
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制御メッセージの1つの新しい拡張機能と、すでにIANAが維持しているモバイルIPv4ルーターディスカバリーメッセージへの1つの新しい拡張機能を定義しています。このドキュメントでは、FAS間で使用する新しいモバイルIPv4コントロールメッセージタイプも定義されています。この仕様に基づいて正しい相互操作を確保するには、IANAは2つの新しい拡張機能と1つの新しいメッセージタイプのモバイルIPv4番号スペースに値を予約する必要があります。IANAは、2つの新しい拡張機能、メッセージタイプ、および関連するコードフィールドによって作成された番号付けスペースも管理する必要があります。
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 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).
ルーターディスカバリーメッセージの一般化リンクレイヤーとIPv4アドレス（LLA）拡張メッセージ：モバイルIPv4 ICMPルーターディスカバリーメッセージ（モバイルIPエージェント広告など）の後に続く新しいモバイルIPv4拡張機能。この拡張機能のタイプ値は、IANAが管理するルーター発見メッセージのモバイルIPv4番号スペースに属します。IANAによって割り当てられた値は140です。この新しい拡張機能は、IANA管理を必要とするリンクレイヤーとIPv4アドレス識別子（LLA）サブタイプ番号スペースを使用します（セクション10.2を参照）。
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です。この新しい拡張機能では、IANA管理を必要とするリンクレイヤーおよびIPアドレス識別子（LLA）サブタイプの番号付けスペースを使用します（セクション10.2を参照）。
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
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で説明したように、事前登録方法の場合、OFAとNFAは、それらの間で輸送されるメッセージを認証および整合性保護するためにセキュリティ協会を共有する必要があります。さらに、OFAは、セキュリティ協会に基づいてNFAを勧誘することを許可する必要があります。FA間のセキュリティ関連を確立するための最小限の要件は、両方のFASが共有キーを含むセキュリティ協会のマニュアルの事前構成をサポートすることです。共有された秘密またはパブリックキーに基づいて、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.
登録後、モバイルIPv4に新しい変更が導入されます。これは、MNがモバイルIPv4登録をまだ実行していないFAからパケットを受信する可能性がある可能性があります。MNは、不明なFASからパケットをドロップすることをお勧めしません。これは、登録後の利点を効果的に排除するためです。セキュリティの観点から、不明なFAからパケットを落とすことは、攻撃からMNを大幅に保護することはできません。これは、悪意のあるホストがMNのホームアドレスを使用して、現在の既知のFAを介して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.
事前登録と同様の方法で、登録後、OFAとNFAは、ハンドオフリクエストと返信メッセージを保護するために必要なセキュリティ協会を共有する必要があります。FAS間のセキュリティ関連を確立するための最小限の要件は、FASサポートマニュアルが共有キーを含むセキュリティ協会の事前構成をサポートすることです。共有された秘密またはパブリックキーに基づいて、IKE [16]を使用してセキュリティ協会を確立する他のメカニズムも使用できます。[7]で指定されたデフォルトのアルゴリズムを使用するFA-FA認証拡張機能[11]を使用して、ハンドオフ要求と返信メッセージを認証する必要があります。このセキュリティがないと、なりすまし攻撃とサービス拒否攻撃が可能になります。
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が、共有秘密を含むピアツーピアセキュリティ関連のマニュアルの事前構成をサポートする必要があり、[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セキュリティへの影響は2つの手法で異なります。
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トリガーは、モバイルまたは有線ネットワーク内の悪意のあるノードによる改ざんに対して保護する必要があります。MNのL2アドレスまたはIPv4アドレスは、L2トリガーに表示されるFASがハンドオフに参加している実際のノードに対応する必要があります。改ざんが発生する可能性がある場合、L2トリガーの受信者はL2情報を認証する何らかの方法を持たなければなりません。そのような機能を提供しないワイヤレスネットワークは、偽装攻撃の対象となります。悪意のあるノードにより、FAはMNが他のサービスエリアに移動したと信じることができます。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 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トリガーのセキュリティには異なる意味があります。事前登録手法は、MNとFA間のモバイルIPv4セキュリティに依存するため、[1]の同じセキュリティ上の考慮事項が適用されます。悪意のあるノードがL2トリガー情報（つまり、L2-STまたはL2-TT）を生成または変更できる場合、これにより広告がMNに送信されます。彼らはMNでワイヤレスリソースと処理を消費しますが、なりすまし攻撃を許可しません。このようなサービス拒否攻撃を防ぐために、L2トリガーの受信の結果としてFA（OFA）が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.
著者は、文書全体に関する貴重なコメントと提案について、Lennart Bang、Bryan Hartwell、Joel Hortelius、Gianluca Verin、Jonathan Woodに感謝したいと考えています。著者はまた、モバイルIPv4 WGチェア、フィルロバーツ、バサバラジパティルの入力に感謝します。
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[1] Perkins、C.、ed。、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[3] Montenegro、G.、ed。、「モバイル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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、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] Plummer、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] IEEE、「64ビットグローバル識別子（EUI-64）登録局のガイドライン」、http：//standards.ieee.org/regauth/oui/tutorials/eui64.html、1997年3月。
[7] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[7] Perkins、C.、Calhoun、P。、およびJ. Bharatia、「Mobile IPv4 Challenge/Response Extensions（改訂）」、RFC 4721、2007年1月。
[8] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[8] Deering、S.、ed。、「ICMPルーターディスカバリーメッセージ」、RFC 1256、1991年9月。
[9] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[9] Postel、J。、「インターネットコントロールメッセージプロトコル」、STD 5、RFC 792、1981年9月。
[10] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[10] Kent、S。、「セキュリティペイロード（ESP）のカプセル化IP」、RFC 4303、2005年12月。
[11] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 Regional Registration", RFC 4857, June 2007.
[11] Fogelstroem、E.、Jonsson、A。、およびC. Perkins、「モバイル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。and R. Glenn、「ESPおよびAH内のHMAC-SHA-1-96の使用」、RFC 2404、1998年11月。
[13] TIA/EIA/IS-2000.
[13] TIA/EIA/IS-2000。
[14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[14] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[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] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
Appendix A - Gateway Foreign Agents
付録A-ゲートウェイ外国人エージェント
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つのFASが共通するモビリティエージェントとして、ゲートウェイ外国エージェント（GFA）を導入します。図A.1は、GFAを介したMNの最初の登録の例を示しています。これが最初の登録メッセージである場合、メッセージはHAに転送する必要があります。MNに送信されたすべてのパケットがGFAに配信され、GFAがMNにサービスを提供するFAにパケットを転送します。
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がOFAに共通するGFAによってサービスされるNFAに移動する場合、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-複数インターフェイスMNSの低遅延ハンドオフ
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.
同じワイヤレスネットワークまたは異なるワイヤレスL2テクノロジーを備えたワイヤレスネットワーク上の2つのワイヤレスネットワークインターフェイスを持つMNSの場合、MNのモバイルIPv4スタックがインターフェース間でIPv4アドレスバインディングを切り替えることができる場合、このドキュメントで説明する技術は不要になる可能性があります。。この付録では、複数のワイヤレスインターフェイスが低遅延のハンドオフにどのように役立つかについて説明します。
+------+ +---------+
| 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）に接続されており、トラフィックを受信しているOFAに登録されていると仮定します。MNがRN2とNFAのカバレッジエリアに入力し、このドキュメントの範囲を超えた理由でこのネットワークへの接続を好むと仮定します（例：ユーザーの好み、コスト、QOなど）。MNはインターフェイスをRN2にアクティブにしますが、RN1を介して通信を続けます。MNは、RN1に接続されたインターフェイスを介してNFAからの広告を求めて、TTL制限がない場合、または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がNFAに登録され、新しいネットワークを介して正常に受信して送信すると、インターフェイスを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/NFA）との接続の障害の可能性をサポートするために、MNはモバイルIPv4登録要求でSビットを使用して、既存の両方で同時バインディングを維持することができます（HAまたはGFA）OFAとの結合とNFAとの新しいバインディング。
Appendix C - PRE-REGISTRATION Message Summary
付録C-登録前のメッセージの概要
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:
プロキシルーター広告（PRRTADV）これは、次の特性を備えた標準のルーター/エージェント広告[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アドレス：NFA IPv4アドレスソースレイヤー2アドレス：OFA L2アドレス宛先IPv4アドレス：MN IPv4アドレス（PRRTSOLから）宛先レイヤー2アドレス2アドレス：MN L2アドレス（PRRTSOLから）LLA拡張（この仕様で定義）：NFAレイヤーを含む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アドレス：OFAアドレス（以前のルーター広告またはPRRTADVのソースアドレスから）宛先レイヤー2アドレス：Ofaアドレス（以前のルーター広告またはPRRTADV LLAのソースアドレスから）LLA拡張機能（この仕様で定義）：レイヤー2テクノロジーに依存します（たとえば、通常WLANの場合、これは新しいWLANアクセスポイントのBSSIDです）
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) 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.
ソースIPv4アドレス：MNアドレスソースレイヤー2アドレス：MNアドレス宛先IPv4アドレス：NFAアドレス（PRRTADVのソースADDRから）宛先レイヤー2アドレス：デフォルトルーター（つまり、OFAアドレス）LLA拡張（この仕様で定義）：NFAが使用する必要がある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の実装は、登録要求メッセージにSビット（セクション6を参照）を設定して、ハンドオフを改善し、2つのベースステーション間のレイヤー2ハンドオフとレイヤー2ピンポン効果による問題を回避する場合があります。
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アドレス：NFAアドレスソースレイヤー2アドレス：OFAアドレス宛先IPv4アドレス：MNアドレス（登録リクエストから）宛先レイヤー2アドレス：MNアドレス（登録リクエストのソースから）
Contributing Authors
貢献している著者
Pat Calhoun Cisco Systems EMail: pcalhoun@cisco.com
PAT Calhoun Cisco Systems Email：pcalhoun@cisco.com
Tom Hiller Lucent Technologies EMail: tom.hiller@lucent.com
Tom Hiller Lucent Technologies Email：tom.hiller@lucent.com
James Kempf NTT DoCoMo USA Labs EMail: kempf@docomolabs-usa.com
James Kempf NTT Docomo USA Labsメール：kempf@docomolabs-usa.com
Peter J. McCann Motorola Labs EMail: pete.mccann@motorola.com
Peter J. McCann Motorola Labsメール：Pete.McCann@motorola.com
Ajoy Singh Motorola EMail: asingh1@email.mot.com
Ajoy Singh Motorolaメール：asingh1@email.mot.com
Hesham Soliman Elevate Technologies EMail: Hesham@elevatemobile.com
Hesham Soliman Elevate Technologies Email：hesham@elevatemobile.com
Sebastian Thalanany US Cellular EMail: Sebastian.thalanany@uscellular.com
Sebastian Thalanany米国の携帯電話メール：sebastian.thalanany@uscellular.com
Editor's Address
編集者のアドレス
Karim El Malki Athonet EMail: karim@athonet.com
Karim El Malki Athonetメール：karim@athonet.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。