[要約] RFC 4988は、モバイルIPv4の高速ハンドオーバーに関する仕様です。その目的は、モバイルデバイスが異なるアクセスポイント間でスムーズに切り替えるための手順とプロトコルを提供することです。
Network Working Group R. Koodli
Request for Comments: 4988 C. Perkins
Category: Experimental Nokia Siemens Networks
October 2007
Mobile IPv4 Fast Handovers
モバイル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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
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.
このドキュメントは、モバイルIPv6ハンドオーバーを適応させて、モバイルIPv4ハンドオーバー操作に起因する遅延とパケット損失を改善します。具体的には、このドキュメントは、ハンドオーバー中の移動検出、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].
このドキュメントは、高速ハンドオーバー仕様[RFC4068]をIPv4ネットワークに適応させます。このドキュメントで指定された高速ハンドオーバープロトコルは、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のCOA（NCOA）が作られています。これにより、モバイルノードは以前のCOA（PCOA）を使用してパケットを受信および送信できるため、新しいリンクに接続することに続くIP構成（DHCPアドレス取得遅延など）が既存のセッションに影響を与えることから解放されます。
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を使用する場合、オンリンクアドレスはMNのホームアドレスであり、NCOAにバインドする必要がある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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
アクセスルーター（AR）：MNのデフォルトルーター。
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.
New COA（NCOA）：NARのサブネットで有効なMNのケアアドレス。
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-INFO）TUPLE：アクセスルーターのL2およびIPアドレスが含まれており、アクセスポイント（AP-IDで識別）が添付されているインターフェイスで有効なプレフィックスが含まれています。トリプレット[ルーターのL2アドレス、ルーターのIPアドレス、プレフィックス]は「ar-info」と呼ばれます。
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との共同配置モードを使用すると、LaTeがより高くなり、Voice over 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]で指定されているようなアクセス制御操作を実行することも含まれます。これらの遅延は、ハンドオーバーパフォーマンスに貢献します。[FH-CCR]および[MI-Book]の第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）およびプロキシルーター広告（PRRTADV）メッセージのルーター勧誘を使用して、近隣アクセスポイントとサブネットマップを構築します。モバイルノードは、ワイヤレスネットワークインターフェイスの動作中の構成ポリシーに基づいて、アクセスポイント（APS）をスキャンできます。スキャンが新しいAPを検出すると、モバイルノードは、上記のRTSOLPRおよびPRRTADVメッセージを使用して、対応する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.
アクセスルーター間の調整は、[RFC4068]で定義されているハンドオーバー開始（HI）とハンドオーバー確認（ハック）メッセージによって行われます。これらの信号が以前のアクセスルーターと新しいアクセスルーター（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モード）または共同配置COA（CCOAモード）のいずれかです。モバイルノードがまだ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アドレスです（PRRTADVメッセージで発見されています）。
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は、モバイルノードへの応答としてFBACKメッセージ（セクション5.2を参照）を送信します。
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
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の再送信もまだ受信していない場合はFBUの再送信も可能になります。この「リアクティブ」モードで送信される場合、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はFBUメッセージの内容を、タイプフィールドからPARに転送する必要があります。新しいパケットのソースおよび宛先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]から適応）を図2に示します。図が図1に示されているHIとハックのメッセージを示していませんが、これらのメッセージはすでに交換されている可能性があります（PARがPARが持っている場合前のリンクから送信されたFBUをすでに処理しています）;そうでない場合、PARはNARにハイメッセージを送信します。FBACKパケットは、NARによってデータパケットとともにMNに転送されます。
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メッセージへの応答として確立されます。PARは、PCOAに設定されたソースIPアドレスを使用してFBUを受信したときにCode = 0でHIメッセージを送信します。PARは、PCOAに設定されていないソースIPアドレスを使用してFBUを受信した場合（つまり、NARから受信した場合）、CODE = 1でHIを送信します。これにより、NARは、予測および反応性の動作モードへの応答として送信されたHIメッセージ処理を乱します。NARがCode = 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.
このプロトコルは、NARがモバイルノードで使用するためにNCOAを返すオプションを提供します。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.
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およびFBATメッセージには新しいメッセージタイプ番号があります。
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アドレス（NARからPARに転送される場合）のいずれか。
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]を参照してください。[RFC3344]の「S」と「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に提供されている場合でも（セクション5.4を参照）、NARのIPアドレスをこのフィールドに使用する必要があります。
Identification: a 64-bit number used for matching an FBU with FBack. Identical to usage in [rfc3344]
識別：FBUとFBACHの一致に使用される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：高速バインディングの確認（FBACK）
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ビット番号。FBUのフィールドからコピーされたこのFbackは返信です。
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を供給する場合、オプションコード2を備えた新しいIPv4アドレスオプションが存在する必要があります（セクション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].
タイプ：41。[RFC4065]のセクション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タイプから始まるICMPメッセージの補完合計を16ビットの補完。チェックサムを計算するには、チェックサムと予約フィールドを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.
アクセスルーターは、ハンドオーバーがネットワーク開始されている場合、またはモバイルノードからのRTSOLPRメッセージへの応答として、プロキシルーター広告メッセージを無償で送信し、近隣のアクセスルーターのリンク層アドレス、IPアドレス、およびサブネットプレフィックスを提供します。すべてのリンク層アドレスオプションには、セクション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：プロキシルーター広告（PRRTADV）メッセージ
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].
タイプ：41。[RFC4065]のセクション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タイプから始まるICMPメッセージの補完合計を16ビットの補完。チェックサムを計算するには、チェックサムと予約フィールドを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 RtSolPr. When a wildcard is present in RtSolPr, PAR uses its neighborhood information to populate this field. This option MUST be present.
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オプション：通常、PRRTADVが承認されていない場合に存在する場合があります。PARは、NARと通信するか、このドキュメントで指定されていない手段によって新しいCOAを計算することができます。いずれにせよ、MNは、IPv4アドレスを取得するためにDHCPまたは同様の操作を実行する代わりに、このアドレスを使用する準備をする必要があります。提供された新しいCOAを使用する場合でも、MNはFBUメッセージの現在のオンリンクアドレス（PCOA）をNARのアドレスにバインドする必要があります。
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のPRRTADVは、MNが上記のオプションに存在する[AP-ID、AR-INFO]タプルを使用する必要があることを意味します。この場合、新しいAP LLAオプションのオプションコードフィールド（セクション6.1を参照）は1で、残りのオプションが関連しているアクセスポイントのLLAと、新しいルーターの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を備えたPRRTADVは、メッセージが未承諾で送信されることを意味します。新しいルータープレフィックス情報オプション（セクション6.3を参照）に従って新しいIPv4オプション（図10を参照）が存在する場合、MNは付属のNCOAを使用してすぐにFBUを送信するか、サービスを失うことができます。このメッセージは、ネットワーク開始のハンドオーバートリガーとして機能します。この場合の新しいAP LLAオプションのオプションコードフィールド（セクション6.1を参照）は、残りのオプションが関連しているアクセスポイントの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.
WildCard AP識別子がRTSOLPRメッセージに提供される場合、PRRTADVメッセージには、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.
新しいCOAオプションは、RTSOLPRメッセージへの応答としてPRRTADVが送信される場合にも使用できます。ただし、近隣発見のための勧誘されたRTSOLPRおよびPRRTADV交換は、FBUおよびFBACEメッセージ（上記）、およびHIおよびハックメッセージ（以下を参照）を含む実際のハンドオーバーフェーズから論理的に分離されています。これは、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）は、モバイルノードのハンドオーバーのプロセスを開始するために、アクセスルーター（通常はPAR）から別のアクセスルーター（通常はNAR）に送信される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].
タイプ：41。[RFC4065]のセクション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タイプから始まるICMPメッセージの補完合計を16ビットの補完。チェックサムを計算するには、チェックサムと予約フィールドを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が宛先によって返されるように要求します。Code = 0の場合に設定される場合があります。Code= 1の場合は0でなければなりません。
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：バッファフラグ。設定すると、宛先は、このメッセージのオプションに示されているノードに向かってパケットをバッファリングする必要があります。Code = 0の場合に使用すると、Code = 1の場合は0に設定する必要があります。
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はDHCPまたは同様の操作を実行してIPv4アドレスを取得する代わりにこのアドレスを使用する準備をする必要があります。
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.
PARは、ソースIPアドレスとしてPCOAで受信したFBUを処理するときにコード= 0を使用します。PARは、FBUがNARのIPアドレスをソースIPアドレスとして受信したときにcode = 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.
ハンドオーバー謝辞メッセージは、ハンドオーバー開始（HI）（セクション5.5を参照）の返信として送信する必要がある新しいICMPメッセージ（通常はNARからPARによって）を送信する必要があります。
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].
タイプ：41。[RFC4065]のセクション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：ハンドオーバーが受け入れられ、NCOAが使用されている3：ハンドオーバーが受け入れられ、NCOAが割り当てられた（割り当てられたアドレス指定で使用）4：ハンドオーバーが受け入れられ、NCOAが割り当てられていない128：理由は認識されていない1299：管理上禁止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タイプから始まるICMPメッセージの補完合計を16ビットの補完。チェックサムを計算するには、チェックサムと予約フィールドを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」フラグが設定されている場合、このオプションを使用して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]で一般的です）。コード値1と2は、MNがNCOAを提案し、NARが応答を提供する場合の場合です。コード3は、NARがNCOAを提供する場合（MNによって提案されたものと同じである可能性があります）。コード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.
このセクションのオプションは、HIおよびハッキングメッセージの拡張機能、およびPRRTSOLおよびPRRTADVメッセージの拡張機能として指定されています。以下のオプションコード値は[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：近くのすべてのアクセスポイントの解像度の要求RTSOLPRまたはPRRTADVメッセージ5：LLAによって識別されるアクセスポイントは、ルーター6の現在のインターフェイスに属します：LLA 7によって識別されるアクセスポイントに利用可能なプレフィックス情報はありません：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.
リンク層アドレス：可変長リンク層アドレス。このフィールドのコンテンツと形式（BYTEおよびBIT順序付けを含む）は、使用中の特定のリンク層に依存します。
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バイトの場合（LLAオプションの長さを2にするために7バイトのパディングが必要です）、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.
このオプションは、PRRTADVの新しいルーターのIPv4アドレスまたはNCOA、およびHIおよびハックメッセージの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.
このオプションは、PRRTADVメッセージで使用されます。
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:
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.
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は不注意または悪意のあるPCOAをNARのリンクの意図しないアドレスにバインドし、トラフィックを疑いを持たないノードに浸しようとする場合があります。
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を供給している場合でも、PCOAをNARのIPアドレスに常に結合することにより回避されます。NARのバッファーをリダイレクトトラフィックでジャムすることはまだ可能です。ただし、MNのPCOAに対応するハンドオーバー状態は有限の寿命を持ち、予想されるハンドオーバーレイテンシの数倍に構成できます。したがって、この脆弱性の程度は小さいです。Accessルーターで、Culprit 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.
アクセスルーターは、HIとハッキングメッセージを使用して通信して、ハンドオーバーを受けるMNの一時的なルーティングパスを確立します。このメッセージ交換は、ルーティングの更新が意図したとおりに行われるように保護する必要があります。
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およびハックメッセージは、アクセスルーター間の既存のセキュリティアソシエーションを使用して保護する必要があり、少なくともメッセージの整合性と認証を確保する必要があります。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ルーター発見メッセージのモバイルIP拡張機能からタイプが割り当てられた3つの新しいオプションを定義します[RFC3344]。これらのオプションは次のとおりです。
+------+------------------+-------------+
| 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:
セクション5.1および5.2で説明されているMN-PAR認証拡張機能は、[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プロトコルの高速な拳銃を持っていることに関心を示してくれたすべての人に感謝します。Vijay Devarapalli、Kent Leung、およびDomagoj Premecのレビューと入力に感謝します。Kumar ViswanathとUday Mohanは、このプロトコルの初期バージョンを実装しました。この文書を改善した徹底的なレビューをしてくれたAlex Petrescuに感謝します。校正をしてくれたピート・マッキャンと、この文書の改善に役立ったレビューのためのJari Arkkoに感謝します。Gen-ArtおよびTSV-Dirのレビューについては、Francis DupontとHannes 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[rfc1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256] Deering、S.、ed。、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
[rfc2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[rfc3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[rfc4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[RFC4065] Kempf、J。、「Seamoby and Experimental Mobility Protocol Ianaの割り当ての指示」、RFC 4065、2005年7月。
[rfc4068] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[RFC4068] Koodli、R.、ed。、「モバイルIPv6用の高速ハンドオーバー」、RFC 4068、2005年7月。
[rfc4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[RFC4721] Perkins、C.、Calhoun、P。、およびJ. Bharatia、「Mobile IPv4 Challenge/Response Extensions（改訂）」、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. Perkins、「モバイルネットワークでの高速ハンドオーバーとコンテキスト転送」、ACM Computer Communications Review Review Issue Wireless Extensions to the Internet、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 STD 802.1x-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-Book] R. KoodliおよびC. E. Perkins、「IPv6を使用したモバイルインターネットワーク：概念、原則、実践」、John Wiley＆Sons、2007年6月。
[mip4-ro] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress, September 2001.
[MIP4-RO] Perkins、C。およびD. Johnson、「モバイル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] Perkins、C。およびP. Calhoun、「認証、認可、および会計（AAA）モバイルIPv4の登録キー」、RFC 3957、2005年3月。
Authors' Addresses
著者のアドレス
Rajeev Koodli Nokia Siemens Networks 313 Fairchild Driive Mountain View, CA 94043 USA
Rajeev Koodli Nokia Siemens Networks 313 Fairchild Driive Mountain View、CA 94043 USA
EMail: rajeev.koodli@nokia.com
Charles Perkins Nokia Siemens Networks 313 Fairchild Driive Mountain View, CA 94043 USA
チャールズパーキンスノキアシーメンスネットワーク313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
EMail: charles.perkins@nokia.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への情報をお問い合わせください。