Network Working Group R. Koodli
Request for Comments: 4988 C. Perkins
Category: Experimental Nokia Siemens Networks
October 2007
Mobile IPv4 Fast Handovers
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Abstract
抽象
This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address.
この文書では、モバイルIPv4ハンドオーバ動作に起因する遅延やパケットロスを改善するために、モバイルIPv6高速ハンドオーバを適応させます。具体的には、この文書は、ハンドオーバ中の移動検出、IPアドレスの設定、及び位置更新の待ち時間に対処します。 IPアドレスの設定の待ち時間を短縮するために、文書は、新しい気付アドレスは、常に新しいアクセスルータのIPアドレスとしていることを提案しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Factors Affecting Handover ......................................5
4. Protocol ........................................................6
4.1. Overview ...................................................6
4.2. Operation ..................................................7
5. Message Formats ................................................10
5.1. Fast Binding Update (FBU) .................................10
5.2. Fast Binding Acknowledgment (FBAck) .......................12
5.3. Router Solicitation for Proxy Advertisement (RtSolPr) .....13
5.4. Proxy Router Advertisement (PrRtAdv) ......................14
5.5. Handover Initiate (HI) ....................................17
5.6. Handover Acknowledge (HAck) ...............................19
6. Option Formats .................................................20
6.1. Link-Layer Address Option Format ..........................20
6.2. New IPv4 Address Option Format ............................22
6.3. New Router Prefix Information Option ......................22
7. Security Considerations ........................................23
8. IANA Considerations ............................................24
9. Acknowledgments ................................................25
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................26
This document adapts the fast handover specification [rfc4068] to IPv4 networks. The fast handover protocol specified in this document is particularly interesting for operation over links such as IEEE 802 wireless links. Fast handovers are not typically needed for wired media due to the relatively large delays attributable to establishing new connections in today's wired networks. Mobile IPv4 [rfc3344] registration messages are reused (with new type numbers) in this document to enable faster implementation using existing Mobile IPv4 software. This document does not require link-layer triggers for protocol operation, but performance will typically be enhanced by using the appropriate triggers when they are available. This document assumes that the reader is familiar with the basic operation and terminology of Mobile IPv4 [rfc3344] and Fast Handovers for Mobile IPv6 [rfc4068].
この文書では、IPv4ネットワークへの高速ハンドオーバー仕様[rfc4068]を適応します。この文書で指定された高速ハンドオーバプロトコルは、IEEE 802無線リンクのようなリンク上の操作のために特に興味深いです。高速ハンドオーバは、一般的に起因する、今日の有線ネットワークに新しい接続を確立するに起因する比較的大きな遅延に有線媒体には必要ありません。モバイルIPv4 [RFC3344]登録メッセージは、既存のモバイルIPv4のソフトウェアを使用してより高速な実装を可能にするために、この文書で（新しいタイプの番号で）再利用されます。この文書では、リンク層のプロトコルの動作のためにトリガを必要としないが、性能は一般的に、彼らが利用可能な場合、適切なトリガを使用することによって強化されます。この文書は、読者がモバイルIPv4 [RFC3344]及びモバイルIPv6 [rfc4068]の高速ハンドオーバの基本的な操作や用語に精通していることを前提としています。
The active agents that enable continued packet delivery to a mobile node (MN) are the access routers on the networks that the mobile node connects to. Handover means that the mobile node changes its network connection, and we consider the scenario in which this change means change in access routers. The mobile node utilizes the access routers as default routers in the normal sense, but also as partners in mobility management. Thus, when the mobile node moves to a new network, it processes handover-related signaling in order to identify and develop a relationship with a new access router. In this document, we call the previous access router PAR and the new access router NAR, consistent with the terminology in [rfc4068]. Unless otherwise mentioned, a PAR is also a Previous Foreign Agent (PFA) and a NAR is also a New Foreign Agent (NFA).
モバイルノード（MN）に続き、パケットの配信を有効に活性な薬剤は、モバイルノードが接続するネットワークのアクセスルータです。ハンドオーバは、モバイルノードがネットワーク接続を変更することを意味し、我々は、この変更は、アクセスルータの変化を意味するシナリオを検討してください。モバイルノードは、通常の意味でのデフォルトルータとしてアクセスルータを利用するだけでなく、移動性管理のパートナーとして。モバイルノードが新しいネットワークに移動したときしたがって、それは新たなアクセスルータとの関係を特定し、開発するためにハンドオーバ関連のシグナリングを処理します。この文書では、我々は[rfc4068]で専門用語と一致し、以前のアクセスルータPARと新しいアクセスルータNARを呼び出します。特に断りのない限り、PARも前のフォーリンエージェント（PFA）であるとNARも新外部エージェント（NFA）です。
On a particular network, a mobile node may obtain its IP address via DHCP [rfc2131] (i.e., Co-located Care-of Address) or use the Foreign Agent CoA. During a handover, the new CoA (NCoA) is always made to be that of NAR. This allows a mobile node to receive and send packets using its previous CoA (PCoA), so that delays resulting from IP configuration (such as DHCP address acquisition delay) subsequent to attaching to the new link are disengaged from affecting the existing sessions.
特定のネットワーク上で、モバイルノードは、DHCP [RFC2131]（すなわち、共存気付アドレス）を介してIPアドレスを取得または外部エージェントCoAを使用することができます。ハンドオーバー時には、新たなCoA（NCOA）は常にNARのものとされています。これは、新しいリンクへの取り付けの後にIP構成から生じる遅延が（たとえば、DHCPアドレス取得遅延など）既存のセッションに影響を与えることから解放されるように、受信およびその前のCoA（PCOA）を使用してパケットを送信するために、モバイルノードが可能になります。
Unlike in Mobile IPv6, a Mobile IPv4 host may rely on its Foreign Agent to provide a Care-of Address. Using the protocol specified in this document, the binding at the PAR is always established between the on-link address the mobile node is using and a new CoA that it can use on the NAR's link. When FA-CoA is used, the on-link address is the MN's home address, not the FA-CoA itself, which needs to be bound to the NCoA. So, when we say "a binding is established between PCoA and NCoA", it is actually the home address of the mobile node that is bound to the NCoA in the FA-CoA mode.
モバイルIPv6とは異なり、モバイルIPv4ホストは、気付アドレスを提供するために、その外国人のエージェントに依拠することができます。この文書で指定されたプロトコルを使用して、PARでの結合は常に、モバイルノードが使用しているオンリンクのアドレスと、それはNARのリンク上で使用することができ、新たなCoAの間で確立されます。 FA-CoAのを使用する場合は、上のリンクアドレスはNCOAにバインドする必要がMNのホームアドレスではなく、FA-CoAの自体、です。私たちが言うときに、「結合がPCOAとNCOA間で確立された」、それが実際にFA-CoAのモードでNCOAにバインドされているモバイルノードのホームアドレスです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The terminology used in this document in based on [rfc4068] and [rfc3344]. We provide some definitions below for convenience.
[rfc4068]と[RFC3344]に基づいて、この文書で使用される用語。私たちは、便宜のために、以下のいくつかの定義を提供しています。
Mobile Node (MN): A Mobile IPv4 host.
モバイルノード（MN）：モバイルIPv4ホスト。
Access Point (AP): A Layer 2 device connected to an IP subnet that offers wireless connectivity to an MN. An Access Point Identifier (AP-ID) refers to the AP's L2 address. Sometimes, AP-ID is also referred to as a Base Station Subsystem ID (BSSID).
アクセスポイント（AP）：MNに無線接続性を提供するIPサブネットに接続されているレイヤ2デバイス。アクセスポイント識別子（AP-ID）がAPのL2アドレスを指します。時々、AP-IDはまた、基地局サブシステムID（BSSID）と呼ばれます。
Access Router (AR): The MN's default router.
アクセスルータ（AT）：MENのデフォルトルータ。
Previous Access Router (PAR): The MN's default router prior to its handover.
前のアクセスルータ（PAR）：そのハンドオーバ前にMNのデフォルトルータ。
New Access Router (NAR): The MN's default router subsequent to its handover.
新アクセスルータ（NAR）：そのハンドオーバ後にMNのデフォルトルータ。
Previous CoA (PCoA): The IP address of the MN valid on PAR's subnet.
前のCoA（PCOA）：PARのサブネット上の有効なMNのIPアドレス。
New CoA (NCoA): The MN's Care-of Address valid on NAR's subnet.
新たなCoA（NCOA）：MNの気付アドレスNARのサブネット上の有効な。
Handover: A process of terminating existing connectivity and obtaining new IP connectivity.
ハンドオーバ：既存の接続を終了し、新しいIP接続を取得するプロセス。
(AP-ID, AR-Info) tuple: Contains an access router's L2 and IP addresses, and the prefix valid on the interface to which the Access Point (identified by AP-ID) is attached. The triplet [Router's L2 address, Router's IP address, Prefix] is called "AR-Info".
（AP-ID、AR-情報）タプル：アクセス・ルータのL2およびIPアドレスが含まれていて、（AP-IDによって識別される）アクセスポイントが接続されているインターフェイス上で有効な接頭辞。トリプレット[ルータのL2アドレスは、ルータのIPアドレス、プレフィックス]「AR-情報」と呼ばれています。
Both link-layer operations and IP-layer procedures affect the perceived handover performance. However, the overall performance is also (always) a function of specific implementation of the technology as well as the system configuration. This document only specifies IP layer protocol operations. The purpose of this section is to provide an illustration of events that affect handover performance, but it is purely informative.
リンク層の操作とIP層の手続きの両方が認識されるハンドオーバー性能に影響を与えます。しかし、全体的なパフォーマンスも（常に）技術の具体的な実装の機能だけでなく、システム構成です。この文書では、IPレイヤのプロトコル動作を指定します。このセクションの目的は、ハンドオーバー性能に影響を与える事象の例示を提供することであるが、それは純粋に有益です。
The IP-layer handover delay and packet loss are influenced by latencies due to movement detection, IP address configuration, and the Mobile IP registration procedure. Movement detection latency comes from the need to reliably detect movement to a new subnet. This is a function of the frequency of router advertisements as well as default agent reachability. IP address configuration latency depends on the particular IP CoA being used. If co-located mode with DHCP is used, the latency is quite likely going to be higher and potentially unacceptable for real-time applications such as Voice over IP. Finally, the Mobile IP registration procedure introduces a round-trip of delay between the Mobile Node and its Home Agent over the Internet. This delay is incurred after the mobile node performs movement detection and IP configuration.
IP層ハンドオーバ遅延やパケットロスは動き検出、IPアドレスの設定、およびモバイルIP登録手順による待ち時間の影響を受けています。動き検出待ち時間は確実に新しいサブネットに動きを検出する必要性から来ています。これは、ルータ広告の周波数の関数としてだけでなく、デフォルトのエージェントの到達可能性です。 IPアドレスの設定待ち時間は、特定のIP CoAが使用されているに依存します。 DHCPと同じ場所に配置モードを使用する場合は、待ち時間がかなりありそうなボイスオーバーIPなどのリアルタイムアプリケーションのための高く、潜在的に受け入れられないことになるだろう。最後に、モバイルIP登録手順は、インターネットを介してモバイルノードとそのホームエージェントの間の遅延の往復を紹介します。この遅延は、移動ノードが移動検出とIPコンフィギュレーションを実行した後に発生されます。
Underlying the IP operations are link-layer procedures. These are technology-specific. For instance, in IEEE 802.11, the handover operation typically involves scanning access points over all available channels, selecting a suitable access point, and associating with it. It may also involve performing access control operations such as those specified in IEEE 802.1X [ieee-802.1x]. These delays contribute to the handover performance. See [fh-ccr] and Chapters 20 and 22 in [mi-book]. Optimizations are being proposed for standardization in IEEE; for instance, see [ieee-802.11r] and [ieee-802.21]. Together with appropriate implementation techniques, these optimizations can provide the required level of delay support at the link-layer for real-time applications.
IPオペレーション基盤となるリンク層手順があります。これらは、技術固有のものです。例えば、IEEE 802.11に、ハンドオーバ動作は、典型的には、利用可能なすべてのチャネルを介してアクセスポイントをスキャンする適切なアクセスポイントを選択し、それに関連付けることを含みます。それはまた、IEEE 802.1X [IEEE-802.1X]に指定されたもののようなアクセス制御動作を行うことを含むことができます。これらの遅延は、ハンドオーバー性能に貢献します。 [MI-ブック]で参照してください[FH-CCR]および章20と22。最適化は、IEEEで標準化のために提案されています。例えば、参照[IEEE-802.11rの]と[IEEE-802.21]。一緒に適切な実装技術を用いて、これらの最適化は、リアルタイムアプリケーションのためのリンク層での遅延のサポートの必要なレベルを提供することができます。
The design of the protocol is the same as for Mobile IPv6 [rfc4068]. Readers should consult [rfc4068] for details; here we provide a summary.
プロトコルの設計は、モバイルIPv6 [rfc4068]と同じです。読者は詳細については、[rfc4068]を相談してください。ここでは要約を提供します。
The protocol avoids the delay due to movement detection and IP configuration and disengages Mobile IP registration delay from the time-critical path. The protocol provides the surrounding network neighborhood information so that a mobile node can determine whether it is moving to a new subnet even before the handover. The information provided and the signaling exchanged between the local mobility agents allow the mobile node to send and receive packets immediately after handover. In order to disengage the Mobile IP registration latency, the protocol provides routing support for the continued use of a mobile node's previous CoA.
プロトコルは、動き検出とIP構成に起因する遅延を回避し、タイムクリティカルパスからのモバイルIP登録の遅延を解除します。モバイルノードは、それがあっても、ハンドオーバ前に新しいサブネットに移動しているかどうかを決定することができるように、プロトコルは、周囲のネットワーク近隣情報を提供します。情報提供とローカル移動エージェントの間で交換シグナリングは、モバイルノードが送信し、ハンドオーバ直後のパケットを受信することを可能にします。モバイルIP登録待ち時間を解除するために、プロトコルは、モバイルノードの以前のCoAの継続的な使用のためのルーティングのサポートを提供します。
After a mobile node obtains its IPv4 Care-of Address, it builds a neighborhood access point and subnet map using the Router Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router Advertisement (PrRtAdv) messages. The mobile node may scan for access points (APs) based on the configuration policy in operation for its wireless network interface. If a scan detects a new AP, the mobile node resolves the corresponding AP Identifier to subnet information using the RtSolPr and PrRtAdv messages mentioned above.
モバイルノードがIPv4の気付アドレスを取得した後、それはプロキシ広告（RtSolPrを）およびプロキシルータアドバタイズメント（代理ルータ広告）メッセージのためのルータ要請を使用して近所のアクセスポイントとサブネットマップを構築します。モバイルノードは、その無線ネットワークインターフェースのための操作で設定ポリシーに基づいてアクセスポイント（AP）をスキャンすることができます。スキャンが新しいAPを検出した場合、モバイルノードは、上記RtSolPrをと代理ルータ広告メッセージを使用して情報をサブネットに対応するAP識別子を解決します。
At some point, the mobile node decides to undergo handover. It sends a Fast Binding Update (FBU) message to PAR from the previous link or from the new link. An FBU message enables creation of a binding between the mobile node's previous CoA and the new CoA.
ある時点で、移動ノードは、ハンドオーバーを受けることにしました。これは、前のリンクから、または新しいリンクからPARに高速バインディングアップデート（FBU）メッセージを送信します。 FBUメッセージは、モバイルノードの以前のCoAと新たなCoAとの間の結合の作成が可能になります。
The coordination between the access routers is done by way of the Handover Initiate (HI) and Handover Acknowledge (HAck) messages defined in [rfc4068]. After these signals have been exchanged between the previous and new access routers (PAR and NAR), data arriving at PAR will be tunneled to NAR for delivery to the newly arrived mobile node. The purpose of HI is to securely deliver the routing parameters for establishing this tunnel. The tunnel is created by the access routers in response to the delivery of the FBU from the mobile node.
アクセスルータ間の調整は、ハンドオーバーの方法によって行われる（HI）開始し、ハンドオーバが[rfc4068]で定義された（上記ハンドオフ）メッセージをアクノリッジ。これらの信号は以前と新しいアクセスルータ（PARとNAR）の間で交換された後に、PARに到着するデータは、新たに到着したモバイルノードに配信するためにNARにトンネルされます。 HIの目的は、確実にこのトンネルを確立するためのルーティングパラメータを提供することです。トンネルがモバイルノードからFBUの送達に応答して、アクセスルータによって作成されます。
In response to a handover trigger or indication, the mobile node sends a Fast Binding Update message to the Previous Access Router (PAR) (see Section 5.1). Depending on the Mobile IP mode of operation, the source IP address is either the Home Address (in FA CoA mode) or co-located CoA (in CCoA mode). The FBU message SHOULD (when possible) be sent while the mobile node is still connected to PAR. When sent in this "predictive" mode, the fields in the FBU MUST be set as follows:
ハンドオーバトリガまたは表示に応答して、モバイルノードが前のアクセスルータ（PAR）へ高速バインディング更新メッセージを送信する（セクション5.1を参照）。操作のモバイルIPモードに応じて、送信元IPアドレスは、（FA CoAのモードで）ホームアドレスであるか、または（CCoAのモード）のCoA共同設置します。モバイルノードがまだPARに接続されている間にFBUメッセージは、（可能な場合）が送信されるべきです。この「予測」モードで送信すると、以下のように、FBUのフィールドを設定する必要があります。
The Home Address field is either the Home Address or the co-located CoA whenever the mobile node has a co-located CoA.
ホームアドレスフィールドには、ホームアドレスまたはモバイルノードがCoAを同じ場所に配置されるたびに同じ場所に配置CoAのいずれかです。
The Home Agent field is set to PAR's IP address.
ホームエージェントフィールドは、PARのIPアドレスに設定されています。
The Care-of Address field is the NAR's IP address (as discovered via a PrRtAdv message).
（代理ルータ広告メッセージを介して発見されたとして）気付アドレスのフィールドには、NARのIPアドレスです。
The fields in the IP header MUST be set as follows:
次のようにIPヘッダ内のフィールドを設定しなければなりません。
The Destination IP address is PAR's IP address.
送信先IPアドレスは、PARのIPアドレスです。
The Source IP address is either the Home Address or the co-located CoA whenever the mobile node has a co-located CoA.
送信元IPアドレスはホームアドレスまたはモバイルノードがCoAを同じ場所に配置されるたびに同じ場所に配置CoAのいずれかです。
As a result of processing the FBU, PAR creates a binding between the address given by the mobile node in the Home Address field and NAR's IP address in its routing table. The PAR sends an FBack message (see Section 5.2) as a response to the mobile node.
FBUの処理結果として、PARは、モバイルホームアドレスフィールド内のノードとそのルーティングテーブル内NARのIPアドレスで指定されたアドレス間のバインディングを作成します。 PARは、モバイルノードに対する応答として（セクション5.2を参照）FBACKメッセージを送信します。
The timeline for the predictive mode of operation (adapted from [rfc4068]) is shown in Figure 1.
（[rfc4068]から適合）動作の予測モードのタイムラインは、図1に示されています。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FBU --------------------------->|
|<=================================== deliver packets
| | (including FBack)
| |<-----FBU-----------|
Figure 1: Predictive Fast Handover
図1：予測の高速ハンドオーバー
The mobile node sends the FBU, regardless of its previous transmission, when attachment to a new link is detected. This minimally allows NAR to detect the mobile node's attachment, but also the retransmission of FBU when an FBack has not been received yet. When sent in this "reactive" mode, the Destination IP address in the IP header MUST be NAR's IP address; the rest of the fields in the FBU are the same as in the "predictive" case.
新しいリンクへの結合が検出された場合、モバイルノードは、その前の送信、に関係なく、FBUを送信します。この最低限のNARは、モバイルノードの接続を検出することを可能にするだけでなく、FBUの再送がFBACKはまだ受信されていないとき。この「反応性」モードで送信すると、IPヘッダ内の送信先IPアドレスは、NARのIPアドレスでなければなりません。 FBU内のフィールドの残りの部分は、「予測」場合と同様です。
When NAR receives FBU, it may already have processed the HI message and created a host route entry for the mobile node, using either the home address or the co-located care-of address as provided by PAR. In that case, NAR SHOULD immediately forward arriving and buffered packets as well as the FBAck message. In any case, NAR MUST forward the contents of the FBU message, starting from the Type field, to PAR; the Source and Destination IP addresses in the new packet now contain the IP addresses of NAR and PAR, respectively.
NARはFBUを受信すると、それはすでにHIメッセージを処理していることと、PARによって提供されるように自宅の住所または共同設置の気付アドレスのいずれかを使用して、モバイルノードのホストルートエントリを作成しました。その場合に、NARはすぐにパケットを転送並びにするFBAckメッセージが到着し、緩衝すべきです。いずれの場合においても、NARがPARに、タイプフィールドから開始し、FBUメッセージの内容を転送しなければなりません。新しいパケットの送信元と送信先のIPアドレスは現在、それぞれ、NARとPARのIPアドレスが含まれています。
The reactive mode of operation (adapted from [rfc4068]) is illustrated in Figure 2. Even though the Figure does not show the HI and HAck messages illustrated in Figure 1, these messages could already have been exchanged (in the case when the PAR has already processed the FBU sent from the previous link); if not, the PAR sends a HI message to the NAR. The FBack packet is forwarded by the NAR to the MN along with the data packets.
（[rfc4068]から適合）動作反応モードはPARがある場合、図は、図1に示すHI及びHAck処理メッセージが表示されないにもかかわらず、これらのメッセージが既に場合（交換された可能性が図2に示されていますすでに前のリンクから送られたFBU）を処理し;ない場合、PARはNARにHIメッセージを送信します。 FBACKパケットは、データパケットと一緒にMNにNARによって転送されます。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-----------FBU-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| (including FBack)
| |
Figure 2: Reactive Fast Handover
図2：反応性高速ハンドオーバ
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages serve to establish a bidirectional tunnel between the routers to support packet forwarding for PCoA. The tunnel itself is established as a response to the FBU message. The PAR sends the HI message with Code = 0 when it receives FBU with source IP address set to PCoA. The PAR sends HI with Code = 1 when it receives FBU with source IP address not set to PCoA (i.e., when received from NAR). This allows NAR to disambiguate HI message processing sent as a response to predictive and reactive modes of operation. If NAR receives a HI message with Code = 1, and it has already set up a host route entry and a reverse tunnel for PCoA, it SHOULD still respond with a HAck message, using an appropriate Code value defined in Section 5.6.
ハンドオーバは、（HI）開始し、ハンドオーバ（上記ハンドオフ）メッセージをアクノリッジPCOAためのパケット転送をサポートするために、ルータ間の双方向トンネルを確立するのに役立ちます。トンネル自体は、FBUメッセージに対する応答として確立されています。それはPCOAに設定されたソースIPアドレスとFBUを受信したときPARは、コード= 0とHIメッセージを送信します。それはPCOAに設定されていない送信元IPアドレス（すなわち、NARから受信した場合）でFBUを受信した場合は、PARコード= 1とHIを送信します。これは、NARが動作の予測と反応モードへの応答として送信されたHIメッセージ処理を明確にすることを可能にします。 NARは、コード= 1 HIメッセージを受信し、それが既にホストルートエントリとPCOAのリバーストンネルを設定している場合、それはまだセクション5.6で定義された適切なコード値を使用して、ハッキングメッセージで応答する必要があります。
The protocol provides an option for NAR to return NCoA for use by the mobile node. When NAR can provide an NCoA for exclusive use of the mobile node, the address is supplied in the HAck message. The PAR includes this NCoA in FBack. Exactly how NAR manages the address pool from which it supplies NCoA is not specified in this document. Nevertheless, the MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address.
プロトコルは、モバイルノードが使用するためNCOAを返すNARのためのオプションを提供します。 NARは、モバイルノードの排他的使用のためのNCOAを提供することができる場合、アドレスは、ハックメッセージで供給されます。 PARはFBACKでこのNCOAが含まれています。正確NARは、この文書で指定されていないNCOAを供給するから、アドレスプールを管理する方法。それにもかかわらず、MNの代わりにIPv4アドレスを取得するためにDHCPまたは類似の動作を実行する、このアドレスを使用するように用意されるべきです。
Even though the mobile node can obtain this NCoA from the NAR, it is unaware of the address at the time it sends an FBU. Hence, it binds PCoA to NAR's IP address as before.
モバイルノードは、NARからこのNCOAを得ることができたとしても、それはFBUを送信時にアドレスを認識しません。したがって、それは以前のようにNARのIPアドレスにPCOAをバインドします。
This section specifies the formats for messages used in this protocol. The Code values below are the same as those in [rfc4068], and do not require any assignment from IANA.
このセクションでは、このプロトコルで使用されるメッセージのためのフォーマットを指定します。コード値は、以下の[rfc4068]と同じであり、IANAから任意の割り当てを必要としません。
The FBU format is bitwise identical to the Registration Request format in [rfc3344]. The same destination port number, 434, is used, but the FBU and FBAck messages in this specification have new message type numbers.
FBUフォーマットは、[RFC3344]に登録要求のフォーマットと同じビット単位です。同じ宛先ポート番号、434は、使用されているが、この仕様でFBUとするFBAckメッセージは、新しいメッセージタイプ番号を持っています。
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 |x|x|D|M|G|r|T|x| reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Figure 3: Fast Binding Update (FBU) Message
図3：高速バインディング更新（FBU）メッセージ
IP Fields:
IPフィールド：
Source address: The interface address from which the message is sent. Either PCoA (co-located or Home Address), or NAR's IP address (when forwarded from NAR to PAR).
ソースアドレス：メッセージが送られるインタフェースアドレス。どちらのPCOA（共同設置やホームアドレス）、またはNARのIPアドレス（PARへNARから転送）。
Destination Address: The IP address of the Previous Access Router (PAR) or the New Access Router (NAR).
宛先アドレス：前のアクセスルータ（PAR）、または新しいアクセスルータ（NAR）のIPアドレス。
Source Port: variable
送信元ポート：変数
Destination port: 434
宛先ポート：434
Message Fields:
メッセージフィールド：
Type: 20
タイプ：20
Flags: See [rfc3344]. The 'S' and 'B' flags in [rfc3344] are sent as zero, and ignored on reception.
フラグ：[RFC3344]を参照してください。 「S」と[RFC3344]に「B」フラグはゼロとして送信され、受信時には無視されます。
reserved: Sent as zero, ignored on reception
予約：ゼロとして送信され、受信時に無視
Lifetime: The number of seconds remaining before the binding expires. This value MUST NOT exceed 10 seconds.
生涯：結合の有効期限が切れるまでの残りの秒数。この値は、10秒を超えてはなりません。
Home Address: MUST be either the co-located CoA or the Home Address itself (in FA-CoA mode)
ホーム住所：共同設置のCoAまたは（FA-CoAのモードで）ホームアドレス自体のいずれかでなければなりません
Home Agent: The Previous Access Router's global IP address
ホームエージェント：前のアクセスルータのグローバルIPアドレス
Care-of Address: The New Access Router's global IP address. Even when a New CoA is provided to the MN (see Section 5.4), NAR's IP address MUST be used for this field.
気付アドレス：新アクセスルータのグローバルIPアドレスを。新たなCoAがMNに提供された場合でも、NARのIPアドレスが、このフィールドを使用しなければなりません（セクション5.4を参照）。
Identification: a 64-bit number used for matching an FBU with FBack. Identical to usage in [rfc3344]
識別：戻るとFBIの照合に使用される64ビット数。 [RFC3344]での使用と同じ
Extensions: MUST contain the MN-PAR Authentication Extension (see Section 8)
拡張機能：MN-PAR認証拡張を含まなければならない（セクション8を参照します）
The MN-PAR Authentication Extension is the Generalized Mobile IP Authentication Extension in [rfc4721] with a new Subtype for MN-PAR Authentication. The Authenticator field in the Generalized Mobile IP Authentication Extension is calculated using a shared key between the MN and the PAR. However, the key distribution itself is beyond the scope of this document, and is assumed to be performed by other means (for example, using [rfc3957]).
MN-PAR認証拡張は、MN-PAR認証のための新しいサブタイプを持つ[rfc4721]で汎用モバイルIP認証拡張機能です。汎用モバイルIP認証拡張における認証フィールドは、MNとPARとの間で共有されるキーを使用して計算されます。しかし、鍵配布自体は、この文書の範囲を超えて、そして（例えば、[rfc3957]を使用して）他の手段によって行うことが想定されます。
The FBAck format is bitwise identical to the Registration Reply format in [rfc3344].
するFBAckフォーマットは、[RFC3344]に登録応答形式と同一ビット単位です。
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 | Code | reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Figure 4: Fast Binding Acknowledgment (FBAck)
図4：ファストバインディング肯定応答（裏面）
IP Fields:
IPフィールド：
Message Source address: Typically copied from the destination address of the FBU message
メッセージソースアドレス：一般的にFBUメッセージの送信先アドレスからコピー
Destination Address: Copied from the Source IP address in FBU message
宛先アドレス：FBUメッセージ内の送信元IPアドレスからコピー
Source Port: variable
送信元ポート：変数
Destination port: Copied from the source port in FBU message
宛先ポート：FBUメッセージの送信元ポートからコピー
Message Fields:
メッセージフィールド：
Type: 21
タイプ：21
Code: Indicates the result of processing FBU message.
コード：FBUメッセージを処理した結果を示します。
0: FBU Accepted 1: FBU Accepted, NCoA supplied 128: FBU Not Accepted, reason unspecified 129: Administratively prohibited 130: Insufficient resources
0：FBU受理1：FBU受け入れられ、NCOAは128を供給：FBU不可、不特定の理由129：管理上130を禁止：リソースが不足し
reserved: Sent as zero, ignored on reception
予約：ゼロとして送信され、受信時に無視
Lifetime: The granted number of seconds remaining before binding expires.
生涯：バインディングの有効期限が切れるまでの残りの秒の付与数。
Home Address: either the co-located CoA or the Home Address itself (in FA-Coa mode)
ホーム住所：共同設置のCoAまたは（FA-COAモードでの）ホームアドレス自体のいずれか
Home Agent: The Previous Access Router's global IP address
ホームエージェント：前のアクセスルータのグローバルIPアドレス
Identification: a 64-bit number used for matching FBU. Copied from the field in FBU for which this FBack is a reply.
識別：FBUを一致させるために使用64ビット数。このFBACKが返信されたFBUのフィールドからコピーされました。
Extensions: The MN-PAR Authentication extension MUST be present (see Section 8). In addition, a New IPv4 Address Option, with Option-Code 2, MUST be present when NAR supplies the NCoA (see Section 6.2).
拡張機能：MN-PAR認証拡張は（セクション8を参照）存在しなければなりません。 NARはNCOAを供給するとき加えて、新しいIPv4アドレスオプションは、オプション・コード2で、（6.2節を参照）存在しなければなりません。
Mobile Nodes send Router Solicitation for Proxy Advertisement in order to prompt routers for Proxy Router Advertisements. All the link-layer address options have the format defined in Section 6.1. The message format and processing rules are identical to those defined in [rfc4068].
モバイルノードは、プロキシルータ広告のためのルータを促すためにプロキシ広告のためのルータ要請を送信します。すべてのリンク層アドレスオプションは、セクション6.1で定義されたフォーマットを有します。メッセージ・フォーマットおよび処理規則は[rfc4068]で定義されたものと同一です。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Router Solicitation for Proxy Advertisement (RtSolPr) Message
図5：プロキシ広告（RtSolPrを）メッセージのためのルーター勧誘
IP Fields:
IPフィールド：
Source Address: An IP address assigned to the sending interface
送信元アドレス：送信インタフェースに割り当てられたIPアドレス
Destination Address: The address of the Access Router or the all routers multicast address.
宛先アドレス：アクセスルータまたはすべてのルータマルチキャストアドレスのアドレス。
Time-to-Live: At least 1. See [rfc1256].
タイム・ツー・ライブ：少なくとも1参照[rfc1256]。
ICMP Fields:
ICMPフィールド：
Type: 41. See Section 3 in [rfc4065].
タイプ：[rfc4065]で41節を参照してください3。
Code: 0
コード：0
Checksum: The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum and the Reserved fields are set to 0. See [rfc1256].
チェックサム：ICMPメッセージの1の補数の和の16ビットの1の補数は、ICMPタイプから始まります。チェックサムを計算するために、チェックサムと予約フィールドが0参照[rfc1256]に設定されています。
Subtype: 6
サブタイプ：6
Reserved: MUST be set to zero by the sender and ignored by the receiver.
予約：送信者によってゼロに設定し、受信機で無視しなければなりません。
Identifier: MUST be set by the sender so that replies can be matched to this Solicitation.
識別子：返信がこの勧誘に合わせることができるように、送信者が設定しなければなりません。
Valid Options:
有効なオプション：
New Access Point Link-layer Address: The link-layer address or identification of the access point for which the MN requests routing advertisement information. It MUST be included in all RtSolPr messages. More than one such address or identifier can be present. This field can also be a wildcard address (see Section 6.1).
新しいアクセスポイントのリンク層アドレス：MNは、ルーティング広告情報を要求するためのアクセスポイントのリンク層アドレスまたは識別。これは、すべてのRtSolPrをメッセージに含まれなければなりません。以上のようなアドレスまたは識別子が存在することができます。このフィールドは、ワイルドカードアドレスを指定できます（6.1節を参照してください）。
Access routers send out a Proxy Router Advertisement message gratuitously if the handover is network-initiated or as a response to RtSolPr message from a mobile node, providing the link-layer address, IP address, and subnet prefixes of neighboring access routers. All the link-layer address options have the format defined in Section 6.1.
ハンドオーバがネットワークによって開始又は隣接アクセスルータのリンク層アドレス、IPアドレス、サブネットプレフィックスを提供する移動ノードからRtSolPrをメッセージに対する応答として、ある場合、アクセスルータは、無償プロキシルータ広告メッセージを送信します。すべてのリンク層アドレスオプションは、セクション6.1で定義されたフォーマットを有します。
The message format and processing rules are identical to those defined in [rfc4068].
メッセージ・フォーマットおよび処理規則は[rfc4068]で定義されたものと同一です。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Proxy Router Advertisement (PrRtAdv) Message
図6：プロキシルータ広告（代理ルータ広告）メッセージ
IP Fields:
IPフィールド：
Source Address: An IP address assigned to the sending interface
送信元アドレス：送信インタフェースに割り当てられたIPアドレス
Destination Address: The Source Address of an invoking Router Solicitation for Proxy Advertisement or the address of the node the Access Router is instructing to handover.
宛先アドレス：プロキシ広告のための呼び出しルーター要請やアクセスルータがハンドオーバするように指示されたノードのアドレスの送信元アドレス。
Time-to-Live: At least 1. See [rfc1256].
タイム・ツー・ライブ：少なくとも1参照[rfc1256]。
ICMP Fields:
ICMPフィールド：
Type: 41. See Section 3 in [rfc4065].
タイプ：[rfc4065]で41節を参照してください3。
Code 0, 1, 2, 3, or 4. See below.
コード0、1、2、3、または4以下を参照してください。
Checksum: The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum and the Reserved fields are set to 0. See [rfc1256].
チェックサム：ICMPメッセージの1の補数の和の16ビットの1の補数は、ICMPタイプから始まります。チェックサムを計算するために、チェックサムと予約フィールドが0参照[rfc1256]に設定されています。
Subtype: 7
サブタイプ：7
Reserved: MUST be set to zero by the sender and ignored by the receiver.
予約：送信者によってゼロに設定し、受信機で無視しなければなりません。
Identifier: Copied from Router Solicitation for Proxy Advertisement or set to Zero if unsolicited.
識別子：プロキシ広告のためのルーター要請からコピーまたは迷惑場合は、ゼロに設定します。
Valid Options in the following order:
次の順序で有効なオプション：
New Access Point Link-layer Address: The link-layer address (LLA) or identification of the access point. When there is no wildcard in RtSolPr, this is copied from the LLA (for which the router is supplying the [AP-ID, AR-Info] tuple) present in
新しいアクセスポイントのリンク層アドレス：リンク層アドレス（LLA）またはアクセスポイントの識別。 RtSolPrをにはワイルドカードがない場合、これは中に存在する（ルータは、[AP-ID、AR-INFO]タプルを供給されている）LLAからコピーされ
RtSolPr. When a wildcard is present in RtSolPr, PAR uses its neighborhood information to populate this field. This option MUST be present.
RtSolPrを。ワイルドカードは、RtSolPrを中に存在する場合、PARは、このフィールドを移入するためにその近傍の情報を使用しています。このオプションが存在しなければなりません。
New Router's Link-layer Address: The link-layer address of the Access Router for which this message is proxied. This option MUST be included when Code is 0 or 1.
新しいルータのリンク層アドレス：このメッセージは、プロキシされたアクセスルータのリンク層アドレス。コードが0または1である場合は、このオプションを含まなければなりません。
New Router's IP Address: The IP address of NAR. This option MUST be included when Code is 0 or 1.
新しいルータのIPアドレス：NARのIPアドレス。コードが0または1である場合は、このオプションを含まなければなりません。
New Router Prefix Information Option: The number of leading bits that define the network number of the corresponding Router's IP Address option (see above).
新しいルータのプレフィックス情報オプション：（上記参照）、対応するルータのIPアドレスオプションのネットワーク番号を定義する有数のビット数。
New CoA Option: MAY be present, typically when PrRtAdv is sent unsolicited. PAR MAY compute new CoA by communicating with the NAR or by means not specified in this document. In any case, the MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address. Even when it uses the New CoA provided, the MN MUST bind its current on-link address (PCoA) to that of NAR in the FBU message.
新しいCoAオプション：代理ルータ広告が迷惑送信され、通常時に存在することができます。 PARはNARと通信することによって、または、この文書で指定されていない手段によって、新たなCoAを計算することができます。いずれの場合においても、MNの代わりにIPv4アドレスを取得するためにDHCPまたは類似の動作を実行する、このアドレスを使用するように用意されるべきです。それが提供する新しいCoAを使用した場合でも、MNは、FBUメッセージにNARのものと現在のオンリンクのアドレス（PCOA）をバインドする必要があります。
A PrRtAdv with Code 0 means that the MN should use the [AP-ID, AR-Info] tuple present in the options above. In this case, the Option-Code field (see Section 6.1) in the New AP LLA option is 1, reflecting the LLA of the access point for which the rest of the options are related, and the Option-Code for the New Router's LLA option is 3. Multiple tuples may be present.
コード0を有する代理ルータ広告は、MNは、上記のオプションに存在する[AP-ID、AR-INFO]タプルを使用する必要があることを意味します。この場合は、Option-Codeフィールドは、オプションの残りが関連しているため、アクセスポイントのLLAを反映して、新しいAPのLLAオプションである1における（6.1節を参照）、および新ルータのLLA用オプション・コードオプションは3.複数のタプルが存在していてもよいです。
A PrRtAdv with Code 1 means that the message is sent unsolicited. If a New IPv4 option (see Figure 10) is present following the New Router Prefix Information option (see Section 6.3), the MN SHOULD use the supplied NCoA and send the FBU immediately or else stand to lose service. This message acts as a network-initiated handover trigger. The Option-Code field (see Section 6.1) in the New AP LLA option in this case is 1 reflecting the LLA of the access point for which the rest of the options are related.
コード1と代理ルータ広告メッセージが迷惑送信されることを意味します。新しいIPv4のオプションは、（図10を参照）新しいルータのプレフィックス情報オプション（6.3節を参照）、以下の存在であるならば、他の付属NCOAを使用すると、すぐにFBUを送信したりすべきであるMNがサービスを失うことに立ちます。このメッセージは、ネットワーク開始ハンドオーバトリガとして働きます。オプション-Codeフィールド（6.1節を参照）。この場合、新しいAPのLLAオプションでは、オプションの残りの部分は関連しているアクセスポイントのLLAを反映して1です。
A Proxy Router Advertisement with Code 2 means that no new router information is present. The LLA option contains an Option-Code value that indicates a specific reason (see Section 6.1).
コード2でプロキシルータ通知には新しいルータ情報が存在しないことを意味しています。 LLAオプションは、特定の理由を（6.1節を参照）を示している。オプション・コード値が含まれています。
A Proxy Router Advertisement with Code 3 means that new router information is only present for a subset of access points requested. The Option-Code values in the LLA option distinguish different outcomes (see Section 6.1).
コード3とプロキシルータアドバタイズメントは新しいルータ情報が要求されたアクセスポイントのサブセットのためにのみ存在することを意味します。 LLAオプションでオプション・コード値が異なる結果を（6.1節を参照）を区別します。
A Proxy Router Advertisement with Code 4 means that the subnet information regarding neighboring access points is sent unsolicited, but the message is not a handover trigger, unlike when the message is sent with Code 1. Multiple tuples may be present.
コード4とプロキシルータ広告は、隣接するアクセスポイントについてのサブネット情報が迷惑送信されるが、メッセージは、メッセージが存在することができるコード1の複数のタプルで送信された場合とは異なり、ハンドオーバトリガしないことを意味します。
When a wildcard AP identifier is supplied in the RtSolPr message, the PrRtAdv message should include all available [Access Point Identifier, Link-Layer Address option, Prefix Information Option] tuples corresponding to the PAR's neighborhood.
ワイルドカードAP識別子がRtSolPrをメッセージに供給されると、代理ルータ広告メッセージは、PARの近所に対応するすべての利用可能な[アクセスポイント識別子、リンク層アドレスオプション、プレフィックス情報オプション]タプルを含める必要があります。
The New CoA option may also be used when the PrRtAdv is sent as a response to a RtSolPr message. However, the solicited RtSolPr and PrRtAdv exchange for neighborhood discovery is logically decoupled from the actual handover phase involving the FBU and FBack messages (above) as well as HI and HAck messages (see below). This means the access routers have to carefully manage the supplied address due to the relative scarcity of addresses in IPv4.
代理ルータ広告がRtSolPrをメッセージへの応答として送信されたときに新しいCoAオプションを使用することもできます。しかしながら、近隣発見のための要請RtSolPrを代理ルータ広告と交換は、論理的に、実際の（上記）FBUとFBACKメッセージを含むハンドオーバ相ならびにHI及びHAck処理メッセージ（下記参照）から切り離されます。これは、アクセスルータは慎重にIPv4のアドレスの相対的な希少性のために供給されたアドレスを管理しなければならないことを意味します。
The Handover Initiate (HI) is an ICMP message sent by an Access Router (typically PAR) to another Access Router (typically NAR) to initiate the process of a mobile node's handover.
ハンドオーバ開始（HI）モバイルノードのハンドオーバのプロセスを開始するために別のアクセスルータ（典型的にはNAR）へのアクセスルータ（典型的にはPAR）によって送信されたICMPメッセージです。
The message format and processing rules are identical to those defined in [rfc4068].
メッセージ・フォーマットおよび処理規則は[rfc4068]で定義されたものと同一です。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |S|U| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 7: Handover Initiate (HI) Message
図7：ハンドオーバ開始（HI）メッセージ
IP Fields:
IPフィールド：
Source Address: The IP address of the PAR
ソースアドレス：PARのIPアドレス
Destination Address: The IP address of the NAR
宛先アドレス：NARのIPアドレス
Time-to-Live: At least 1. See [rfc1256].
タイム・ツー・ライブ：少なくとも1参照[rfc1256]。
ICMP Fields:
ICMPフィールド：
Type: 41. See Section 3 in [rfc4065].
タイプ：[rfc4065]で41節を参照してください3。
Code: 0 or 1. See below
コード：0または1以下を参照してください
Checksum: The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum and the Reserved fields are set to 0. See [rfc1256].
チェックサム：ICMPメッセージの1の補数の和の16ビットの1の補数は、ICMPタイプから始まります。チェックサムを計算するために、チェックサムと予約フィールドが0参照[rfc1256]に設定されています。
Subtype: 8
サブタイプ：8
S: Assigned address configuration flag. When set, this message requests a new CoA to be returned by the destination. May be set when Code = 0. MUST be 0 when Code = 1.
S：割り当てられたアドレス設定フラグ。設定すると、このメッセージは、宛先によって返される新しいCoAを要求します。コード= 0は、0コード= 1でなければならないときに設定することができます。
U: Buffer flag. When set, the destination SHOULD buffer any packets towards the node indicated in the options of this message. Used when Code = 0, SHOULD be set to 0 when Code = 1.
U：バッファフラグ。設定した場合、宛先は、このメッセージのオプションに示されているノードに向かうすべてのパケットをバッファリングするべきです。コード= 0は、0コード= 1に設定されるべき時に使用します。
Reserved: MUST be set to zero by the sender and ignored by the receiver.
予約：送信者によってゼロに設定し、受信機で無視しなければなりません。
Identifier: MUST be set by the sender so replies can be matched to this message.
識別子：応答がこのメッセージに一致させることができるように、送信者によって設定されなければなりません。
Valid Options:
有効なオプション：
Link-layer address of MN: The link-layer address of the MN that is undergoing handover to the destination (i.e., NAR). This option MUST be included so that the destination can recognize the MN.
MNのリンク層アドレス：宛先（すなわち、NAR）へのハンドオーバを行っているMNのリンク層アドレス。宛先がMNを認識できるように、このオプションを含まなければなりません。
Previous Care-of Address: The IP address used by the MN while attached to the originating router. This option MUST be included so that a host route can be established on the NAR.
前の気付アドレス：発信側ルータに接続しながら、MNが使用するIPアドレス。ホストルートがNARに確立することができるように、このオプションを含まなければなりません。
New Care-of Address: This option MAY be present when the MN wishes to use a new IP address when connected to the destination. When the 'S' bit is set, NAR MAY provide this address in HAck, in which case the MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address.
新気付アドレス：MNは、先に接続したときに新しいIPアドレスを使用したい場合、このオプションが存在してもよいです。 「S」ビットが設定されている場合、NARは、MNの代わりにIPv4アドレスを取得するためにDHCPまたは類似の動作を実行する、このアドレスを使用するように準備する必要があり、その場合にハックでこのアドレスを提供してもよいです。
PAR uses Code = 0 when it processes the FBU received with PCoA as source IP address. PAR uses Code = 1 when the FBU is received with NAR's IP address as the source IP address.
それはFBUは、ソースIPアドレスとしてPCOAで受信処理するとき、PARは、コード= 0を使用します。 PARはFBUは、ソースIPアドレスとしてNARのIPアドレスで受信されたコード= 1を使用しています。
The Handover Acknowledgment message is a new ICMP message that MUST be sent (typically by NAR to PAR) as a reply to the Handover Initiate (HI) (see Section 5.5) message.
ハンドオーバ肯定応答メッセージは、ハンドオーバに対する応答として（PARとNARによって、典型的に）送信されなければならない新たなICMPメッセージである（HI）（セクション5.5参照）メッセージを開始します。
The message format and processing rules are identical to those defined in [rfc4068].
メッセージ・フォーマットおよび処理規則は[rfc4068]で定義されたものと同一です。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 8: Handover Acknowledge (HAck) Message
図8：ハンドオーバ肯定応答（上記ハンドオフ）メッセージ
IP Fields:
IPフィールド：
Source Address: Copied from the destination address of the Handover Initiate Message to which this message is a response.
ソースアドレス：ハンドオーバの宛先アドレスからコピーは、このメッセージが応答されたメッセージを開始します。
Destination Address: Copied from the source address of the Handover Initiate Message to which this message is a response.
宛先アドレス：ハンドオーバの送信元アドレスからコピーは、このメッセージが応答されたメッセージを開始します。
Time-to-Live: At least 1. See [rfc1256].
タイム・ツー・ライブ：少なくとも1参照[rfc1256]。
ICMP Fields:
ICMPフィールド：
Type: 41. See Section 3 in [rfc4065].
タイプ：[rfc4065]で41節を参照してください3。
Code:
コード：
0: Handover Accepted 1: Handover Accepted, NCoA not valid 2: Handover Accepted, NCoA in use 3: Handover Accepted, NCoA assigned (used in Assigned addressing) 4: Handover Accepted, NCoA not assigned 128: Handover Not Accepted, reason unspecified 129: Administratively prohibited 130: Insufficient resources
0：ハンドオーバ承認1：ハンドオーバ承認、NCOA無効2：使用3におけるハンドオーバ受け入れ、NCOA：（割り当てアドレッシングで使用される）を割り当てハンドオーバ受け入れ、NCOA 4：ハンドオーバ不可、不特定129理由：128が割り当てられていないハンドオーバ承認、NCOA ：不十分なリソース：管理上130を禁止
Checksum: The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum and the Reserved fields are set to 0. See [rfc1256].
チェックサム：ICMPメッセージの1の補数の和の16ビットの1の補数は、ICMPタイプから始まります。チェックサムを計算するために、チェックサムと予約フィールドが0参照[rfc1256]に設定されています。
Subtype: 9
サブタイプ：9
Reserved: MUST be set to zero by the sender and ignored by the receiver.
予約：送信者によってゼロに設定し、受信機で無視しなければなりません。
Identifier: Copied from the corresponding field in the Handover Initiate message this message is in response to.
識別子：ハンドオーバ中の対応するフィールドからコピーされ、このメッセージは、に応答するメッセージを開始します。
Valid Options:
有効なオプション：
New Care-of Address: If the 'S' flag in the HI message is set, this option MUST be used to provide NCoA the MN should use when connected to this router. This option MAY be included even when 'S' bit is not set, e.g., Code 2 above. The MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address.
新気付アドレスは：HIメッセージに「S」フラグが設定されている場合、このオプションは、このルータに接続したときにMNが使用するNCOAを提供するために使用されなければなりません。このオプションは、「S」のビットが、セットされていない場合でも、含まれるかもしれません、例えば、上記のコード2。 MNは、代わりにIPv4アドレスを取得するためにDHCPまたは類似の動作を実行する、このアドレスを使用するように用意されるべきです。
The Code 0 is the expected average case of a handover being accepted and the routing support provided for the use of PCoA. The rest of the Code values pertain to the use of NCoA (which is common in [rfc4068]). Code values 1 and 2 are for cases when the MN proposes an NCoA and the NAR provides a response. Code 3 is when the NAR provides NCoA (which could be the same as that proposed by the MN). Code 4 is when the NAR does not provide NCoA, but instead provides routing support for PCoA.
コード0は受け入れられハンドオーバの予想される平均的なケースおよびPCOAの使用のために設けられたルーティング支持体です。コード値の残りはNCOAの使用に関連する（[rfc4068]で一般的です）。 MNはNCOAを提案し、NARは、応答を提供するときにコード値1および2は、ケースのためのものです。コード3 NARは（MNによって提案されたものと同じであってもよい）NCOAを提供する場合です。コード4 NARはNCOAを提供しない場合であり、その代わりにPCOAのルーティングサポートを提供します。
The options in this section are specified as extensions for the HI and HAck messages, as well as for the PrRtSol and PrRtAdv messages. The Option-Code values below are the same as those in [rfc4068], and do not require any assignment from IANA.
このセクションのオプションはPrRtSolと代理ルータ広告メッセージのためだけでなく、HI及びHAck処理メッセージ用の拡張機能として指定されています。以下のオプションコードの値が[rfc4068]と同じであり、IANAから任意の割り当てを必要としません。
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 | Option-Code | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Link-Layer Address Option Format
図9：リンク層アドレスオプションフォーマット
Fields:
フィールド：
Type: 20
タイプ：20
Option-Code:
オプションコード：
0: Wildcard requesting resolution for all nearby access points 1: Link-Layer Address of the New Access Point 2: Link-Layer Address of the MN 3: Link-Layer Address of the NAR 4: Link-Layer Address of the source of the RtSolPr or PrRtAdv message 5: The access point identified by the LLA belongs to the current interface of the router 6: No prefix information available for the access point identified by the LLA 7: No fast handovers support available for the access point identified by the LLA
0：のソースのリンク層アドレス：NAR 4のリンク層アドレス：MN 3のリンク層アドレス：新アクセスポイント2のリンク層アドレス：ワイルドカードは、すべての近くのアクセスポイントの1のための解決を要求しますRtSolPrを又は代理ルータ広告メッセージ5：LLA 7によって識別されたアクセスポイントのために利用可能なプレフィックス情報：LLAによって識別されたアクセスポイントは、ルータ6の現在のインタフェースに属するなし高速ハンドオーバがLLAによって識別されたアクセスポイントのために利用可能なサポートしません
Length: The length of the option (including the Type, Length and Option-Code fields) in units of 8 octets.
長さ：8つのオクテットの単位で（タイプ、長さ、およびオプションコードフィールドを含む）オプションの長さ。
Link-Layer Address: The variable-length link-layer address. The content and format of this field (including byte and bit ordering) depends on the specific link-layer in use.
リンク層アドレス：可変長リンク層アドレス。 （バイトとビット順序を含む）このフィールドの内容と形式は、使用中の特定のリンク層に依存します。
There is no length field for the LLA itself. Implementations MUST determine the length of the LLA based on the specific link technology where the protocol is run. The total size of the LLA option itself MUST be a multiple of 8 octets. Hence, padding may be necessary depending on the size of the LLA used. In such a case, the padN option [rfc2460] MUST be used. As an example, when the LLA is 6 bytes (meaning 7 bytes of padding is necessary to bring the LLA option length to 2), the padN option will have a length field of 5 and 5 bytes of zero-valued octets (see [rfc2460]).
LLA自体には長さフィールドはありません。実装は、プロトコルが実行される特定のリンク技術に基づいLLAの長さを決定する必要があります。 LLAオプション自体の合計サイズは8つのオクテットの倍数でなければなりません。従って、パディングは使用LLAの大きさに応じて必要とすることができます。このような場合には、PADNオプション[RFC2460]は使用しなければなりません。 LLAは6バイト（パディングの7つのバイトを意味する2にLLAオプションの長さをもたらすために必要である）である場合の例として、PADNオプションは、ゼロ値のオクテットの5,5バイトの長さフィールドを持っています（[RFC2460参照]）。
This option is used to provide the new router's IPv4 address or the NCoA in PrRtAdv, as well as PCoA and NCoA in HI and HAck messages.
このオプションは、HI及びHAck処理メッセージに新しいルータのIPv4アドレスまたは代理ルータ広告でNCOAだけでなく、PCOAとNCOAを提供するために使用されます。
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 | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: New IPv4 Address Option Format
図10：新規のIPv4アドレスオプションのフォーマット
Fields:
フィールド：
Type: 21
タイプ：21
Length: The length of the option (including the Type, Length and Option-Code fields) in units of 8 octets.
長さ：8つのオクテットの単位で（タイプ、長さ、およびオプションコードフィールドを含む）オプションの長さ。
Option-Code:
オプションコード：
1: Previous CoA 2: New CoA 3: NAR's IP Address
1：前のCoA 2：新しいCoAを3：NARのIPアドレス
Reserved: Set to zero.
予約：ゼロに設定してください。
New IPv4 Address: NAR's IPv4 address or the NCoA assigned by NAR.
新しいIPv4アドレス：NARのIPv4アドレスまたはNARによって割り当てられNCOA。
This option is used in the PrRtAdv message.
このオプションは、代理ルータ広告メッセージで使用されています。
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 | Option-Code | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: New Router Prefix Information Option Format
図11：新しいルータのプレフィックス情報オプションフォーマット
Fields:
フィールド：
Type: 22
タイプ：22
Length: The length of the option (including the Type, Length and Option-Code fields) in units of 8 octets.
長さ：8つのオクテットの単位で（タイプ、長さ、およびオプションコードフィールドを含む）オプションの長さ。
Option-Code: 0
オプション・コード：0
Prefix-Length The number of leading bits that define the network number of the corresponding Router's IP Address option.
プレフィックス長、対応するルータのIPアドレスオプションのネットワーク番号を定義する有数のビット数。
Reserved: Set to zero.
予約：ゼロに設定してください。
As outlined in [rfc4068], the following vulnerabilities are identified and the solutions mentioned.
[rfc4068]で概説されるように、以下の脆弱性が識別され、解決策が記載されています。
Insecure FBU:
安全でないFBU：
Failure to protect the FBU message could result in packets meant for an address being stolen or redirected to some unsuspecting node. This concern is similar to that in Mobile Node and Home Agent relationship.
アドレスのために意味のパケットが生じる可能性がFBUメッセージを保護するために失敗すると、盗まれたり、いくつかの疑いを持たないノードにリダイレクトされています。この懸念は、モバイルノードとホームエージェントとの関係と同様です。
Hence, the FBU and FBack messages MUST be protected using a security association shared between a mobile node and its access router. In particular, the MN-PAR Authentication Extension MUST be present in each of these messages. This document does not specify how the security association is established between an MN and the AR/FA.
したがって、FBUとFBACKメッセージは、モバイルノードとアクセスルータとの間で共有セキュリティアソシエーションを使用して保護されなければなりません。具体的には、MN-PAR認証拡張は、これらのメッセージの各々に存在していなければなりません。この文書では、セキュリティアソシエーションは、MNとAR / FA間で確立された方法を指定しません。
Secure FBU, malicious or inadvertent redirection:
セキュアFBU、悪意のあるまたは不注意によるリダイレクト：
Even if the MN-PAR authentication extension is present in an FBU, an MN may inadvertently or maliciously attempt to bind its PCoA to an unintended address on NAR's link, and cause traffic flooding to an unsuspecting node.
MN-PAR認証拡張がFBUに存在する場合であっても、MNは、不注意または故意NARのリンク上の意図しないアドレスにそのPCOAをバインドしようとし、疑いを持たないノードへのトラフィックの洪水を引き起こす可能性があります。
This vulnerability is avoided by always binding the PCoA to the NAR's IP address, even when the NAR supplies an NCoA to use for the MN. It is still possible to jam NAR's buffer with redirected traffic. However, the handover state corresponding to the MN's PCoA has a finite lifetime, and can be configured to be a few multiples of the anticipated handover latency. Hence, the extent of this vulnerability is small. It is possible to trace the culprit MN with an established security association at the access router.
この脆弱性は、NARは、MNに使用するNCOAを供給しても、常にNARのIPアドレスへのPCOAを結合することによって回避されます。リダイレクトされたトラフィックとNARのバッファをジャムすることも可能です。しかし、MNのPCOAに対応するハンドオーバ状態は有限の寿命を持ち、かつ予想されるハンドオーバ待ち時間の数倍になるように構成することができます。したがって、この脆弱性の程度は小さいです。アクセスルータで確立されたセキュリティ協会と犯人のMNを追跡することが可能です。
Communication between the access routers:
アクセスルータ間の通信：
The access routers communicate using HI and HAck messages in order to establish a temporary routing path for the MN undergoing handover. This message exchange needs to be secured to ensure routing updates take place as intended.
アクセスルータは、ハンドオーバ中のMNのための一時的なルーティングパスを確立するために、HI及びHAck処理メッセージを使用して通信します。このメッセージ交換は意図したとおりにルーティングアップデートが行われることを確認するために確保する必要があります。
The HI and HAck messages need to be secured using a preexisting security association between the access routers to ensure at least message integrity and authentication, and SHOULD also include encryption. IPsec ESP SHOULD be used.
HI及びHAck処理メッセージは、少なくともメッセージの整合性と認証を確保するために、アクセスルータ間の既存のセキュリティアソシエーションを使用して確保する必要があり、また、暗号化を含むべきです。 IPsecのESPを使用する必要があります。
The IANA assignments made for messages, extensions, and options specified in this document are described in the following paragraphs.
メッセージ、拡張機能、およびこの文書で指定されたオプションのために作られたIANAの割り当ては、以下の段落で説明されています。
This document defines two new messages that use the Mobile IPv4 control message format [rfc3344]. These message details are as follows:
この文書では、モバイルIPv4制御メッセージフォーマット[RFC3344]を使用する2つの新しいメッセージを定義します。次のようにこれらのメッセージの詳細は以下のとおりです。
+------+-------------+-------------+
| Type | Description | Reference |
+------+-------------+-------------+
| 20 | FBU | Section 5.1 |
| 21 | FBAck | Section 5.2 |
+------+-------------+-------------+
This document defines four new experimental ICMP messages that use the ICMP Type 41 for IPv4. See Section 3 in [rfc4065]. The new messages specified in this document have been assigned Subtypes from the registry in [rfc4065]:
この文書では、IPv4のICMPタイプ41を使用する4つの新しい実験ICMPメッセージを定義します。 [rfc4065]でセクション3を参照してください。この文書で指定された新しいメッセージは[rfc4065]でレジストリからサブタイプを割り当てられています：
+---------+-------------+-------------+
| Subtype | Description | Reference |
+---------+-------------+-------------+
| 6 | RtSolPr | Section 5.3 |
| 7 | PrRtAdv | Section 5.4 |
| 8 | HI | Section 5.5 |
| 9 | HAck | Section 5.6 |
+---------+-------------+-------------+
This document defines three new options that have been assigned Types from the Mobile IP Extensions for ICMP Router Discovery messages [rfc3344]. These options are as follows:
この文書では、ICMPルーター発見メッセージ[RFC3344]のためのモバイルIP拡張機能からのタイプが割り当てられている3つの新しいオプションを定義します。次のようにこれらのオプションは以下のとおりです。
+------+------------------+-------------+
| Type | Description | Reference |
+------+------------------+-------------+
| 20 | LLA | Section 6.1 |
| 21 | New IPv4 Address | Section 6.2 |
| 22 | NAR Prefix Info | Section 6.3 |
+------+------------------+-------------+
The MN-PAR Authentication Extension described in Sections 5.1 and 5.2 is a Generalized Mobile IP Authentication Extension defined in Section 5 of [rfc4721]. The MN-PAR Authentication has been assigned a Subtype from the registry specified in [rfc4721]. The Extension details are as follows:
MN-PAR認証拡張は、セクション5.1に記載されており、5.2 [rfc4721]のセクション5で定義された一般化されたモバイルIP認証拡張です。 MN-PAR認証[rfc4721]で指定されたレジストリからサブタイプが割り当てられています。次のように拡張の詳細は以下のとおりです。
+---------+-----------------------+--------------------------+
| Subtype | Description | Reference |
+---------+-----------------------+--------------------------+
| 4 | MN-PAR Auth Extension | Section 5.1 |
+---------+-----------------------+--------------------------+
Thanks to all those who expressed interest in having a Fast Handovers for Mobile IPv4 protocol along the lines of [rfc4068]. Thanks to Vijay Devarapalli, Kent Leung, and Domagoj Premec for their review and input. Kumar Viswanath and Uday Mohan implemented an early version of this protocol. Many thanks to Alex Petrescu for his thorough review that improved this document. Thanks to Pete McCann for the proofreading, and to Jari Arkko for the review, which have helped improve this document. Thanks to Francis Dupont and Hannes Tschofenig for the GEN-ART and TSV-DIR reviews.
[rfc4068]の線に沿ってモバイルIPv4プロトコルの高速ハンドオーバを有するに関心を表明すべての人に感謝。彼らのレビューと入力のためのビジェイDevarapalli、ケントレオン、とDomagoj Premecに感謝します。クマールViswanathとウダイモハンは、このプロトコルの初期バージョンを実装しました。この文書を改善し、彼の徹底的な見直しのためのアレックスペトレスクに感謝します。このドキュメントを改善する助けたレビューのための校正のために、とヤリArkkoにピートマッキャンに感謝します。 GEN-ARTとTSV-DIRレビューのためのフランシスデュポンとハンネスTschofenigに感謝します。
Sending FBU from the new link (i.e., reactive mode) is similar to using the extension defined in [mip4-ro]; however, this document also addresses movement detection and router discovery latencies.
新しいリンク（すなわち、反応性モード）からFBUを送信する[MIP4-RO]で定義された拡張機能を使用することに類似しています。しかし、この文書はまた、動き検出およびルータディスカバリの待ち時間に対応しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[rfc1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[rfc1256]デアリング、S.、エド。、 "ICMPルータ発見メッセージ"、RFC 1256、1991年9月。
[rfc2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[rfc3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[rfc4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[rfc4065]ケンプ、J.、RFC 4065、2005年7月 "Seamobyと実験モビリティプロトコルのIANAの割り当てのための手順"。
[rfc4068] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[rfc4068] Koodli、R.、エド。、 "モバイルIPv6のための高速ハンドオーバ"、RFC 4068、2005年7月。
[rfc4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[rfc4721]パーキンス、C.、カルフーン、P.、およびJ. Bharatia、 "モバイルIPv4チャレンジ/レスポンス拡張（改訂版）"、RFC 4721、2007年1月。
[fh-ccr] R. Koodli and C. E. Perkins, "Fast Handovers and Context Transfers in Mobile Networks", ACM Computer Communications Review Special Issue on Wireless Extensions to the Internet, October 2001.
[FH-CCR] R. Koodli及びC. E.パーキンス、「モバイルネットワークにおける高速ハンドオーバとコンテキスト転送」、インターネットへのワイヤレス拡張機能にACMコンピュータコミュニケーションレビュー特集、2001年10月。
[ieee-802.11r] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Fast Roaming/Fast BSS Transition, IEEE Std 802.11r", September 2006.
[IEEE-802.11rの] IEEE、 "地方とメトロポリタンエリアネットワークのIEEE標準：高速ローミング/高速BSSの移行、IEEE STDの802.11rの"、2006年9月。
[ieee-802.1x] IEEE, "IEEE Standards for Local and Metropolitan Area Networks: Port-based Network Access Control, IEEE Std 802.1X-2001", June 2001.
[IEEE-802.1X] IEEE、 "地方とメトロポリタンエリアネットワークのIEEE規格：ポートベースのネットワークアクセスコントロール、IEEE 802.1X STD-2001"、2001年6月。
[ieee-802.21] The IEEE 802.21 group, http://www.ieee802.org/21.
[IEEE-802.21] IEEE 802.21基、http://www.ieee802.org/21。
[mi-book] R. Koodli and C. E. Perkins, "Mobile Internetworking with IPv6: Concepts, Principles and Practices", John Wiley & Sons, June 2007.
[MI-ブック] R. Koodli及びC. E.パーキンス、 "IPv6でのモバイルインターネットワーキング：概念、原理と実践"、ジョン・ワイリー・アンド・サンズ、2007年6月。
[mip4-ro] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress, September 2001.
[MIP4-RO]パーキンス、C.およびD.ジョンソン、 "モバイルIPにおける経路最適化"、進歩、2001年9月の作品。
[rfc2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[rfc3957] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
[rfc3957]パーキンス、C.とP.カルフーン、 "モバイルIPv4のための認証、許可、アカウンティング（AAA）の登録キー"、RFC 3957、2005年3月。
Authors' Addresses
著者のアドレス
Rajeev Koodli Nokia Siemens Networks 313 Fairchild Driive Mountain View, CA 94043 USA
ラジーブKoodliノキア・シーメンス・ネットワーク313フェアチャイルドDriiveマウンテンビュー、CA 94043 USA
EMail: rajeev.koodli@nokia.com
メールアドレス：rajeev.koodli@nokia.com
Charles Perkins Nokia Siemens Networks 313 Fairchild Driive Mountain View, CA 94043 USA
チャールズ・パーキンスノキア・シーメンス・ネットワーク313フェアチャイルドDriiveマウンテンビュー、CA 94043 USA
EMail: charles.perkins@nokia.com
メールアドレス：charles.perkins@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。