Network Working Group R. Koodli, Ed.
Request for Comments: 4068 Nokia Research Center
Category: Experimental July 2005
Fast Handovers for Mobile IPv6
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency.
モバイルIPv6は、別のアクセスルータから移動するとき、ハンドオーバと呼ばれるプロセスをインターネットへの接続性を維持するためにモバイルノードを可能にします。ハンドオーバ中に、モバイルノードがあるため、リンク切替遅延及びIPプロトコル動作のパケットを送信または受信することができない期間があります。標準のモバイルIPv6の手順から生じたこの「ハンドオーバ待ち時間」、つまり動き検出、アドレス構成の新しいケア、およびバインディングアップデートは、多くの場合、IP上の音声などのリアルタイムトラフィックに受け入れられません。ハンドオーバ待ち時間を減らすことだけでなく、非リアルタイム、スループット重視のアプリケーションに有益である可能性があります。この文書では、モバイルIPv6の手続きによるハンドオーバ待ち時間を改善するためのプロトコルを指定します。この文書では、リンクの切り替えの待ち時間を改善し対応していません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Addressing the Handover Latency. . . . . . . . . . . . . 5
3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 7
3.3. Protocol Operation of Network-initiated Handover . . . . 9
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 10
5. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Handover Capability Exchange . . . . . . . . . . . . . . 15
5.2. Determining New Care of Address. . . . . . . . . . . . . 15
5.3. Packet Loss. . . . . . . . . . . . . . . . . . . . . . . 15
5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 16
5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 16
6. Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. New Neighborhood Discovery Messages. . . . . . . . . . . 17
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) . . . . . . . . . . . . . . . . . . . . 17
6.1.2. Proxy Router Advertisement (PrRtAdv). . . . . . . 20
6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 23
6.2.1. Handover Initiate (HI). . . . . . . . . . . . . . 23
6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . 25
6.3. New Mobility Header Messages . . . . . . . . . . . . . . 27
6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . 27
6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . 28
6.3.3. Fast Neighbor Advertisement (FNA) . . . . . . . . 30
6.4. New Options. . . . . . . . . . . . . . . . . . . . . . . 31
6.4.1. IP Address Option . . . . . . . . . . . . . . . . 32
6.4.2. New Router Prefix Information Option. . . . . . . 33
6.4.3. Link-Layer Address (LLA) Option . . . . . . . . . 34
6.4.4. Mobility Header Link-Layer Address (MH-LLA)
Option. . . . . . . . . . . . . . . . . . . . . . 35
6.4.5. Neighbor Advertisement Acknowledgment (NAACK) . . 35
7. Configurable Parameters. . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 39
11. Normative References . . . . . . . . . . . . . . . . . . . . . 39
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39
Mobile IPv6 [3] describes the protocol operations for a mobile node to maintain connectivity to the Internet during its handover from one access router to another. These operations involve movement detection, IP address configuration, and location update. The combined handover latency is often sufficient to affect real-time applications. Throughput-sensitive applications can also benefit from reducing this latency. This document describes a protocol to reduce the handover latency.
モバイルIPv6 [3]別のアクセスルータからのハンドオーバの間、インターネットへの接続性を維持するために、移動ノードのプロトコル動作について説明します。これらの操作は、動き検出、IPアドレスの設定、および位置更新を伴います。組み合わせハンドオーバ待ち時間は、多くの場合、リアルタイム・アプリケーションに影響を与えるに十分です。スループット重視のアプリケーションにも、この待ち時間を短縮の恩恵を受けることができます。この文書では、ハンドオーバ待ち時間を短縮するためのプロトコルを記述します。
This specification addresses the following problem: how to allow a mobile node to send packets as soon as it detects a new subnet link, and how to deliver packets to a mobile node as soon as its attachment is detected by the new access router. The protocol defines IP protocol messages necessary for its operation regardless of link technology. It does this without depending on specific link-layer features while allowing link-specific customizations. By definition, this specification considers handovers that interwork with Mobile IP: once attached to its new access router, an MN engages in Mobile IP operations including Return Routability [3]. There are no special requirements for a mobile node to behave differently with respect to its standard Mobile IP operations.
この仕様は、次のような問題に対処します。それは新しいサブネットリンクを検出するとすぐに、移動ノードがパケットを送信できるようにする方法、及びその添付ファイルが新しいアクセスルータによって検出されるとすぐに、モバイルノードにパケットを配信する方法。プロトコルに関係なく、リンク技術のその動作に必要なIPプロトコルメッセージを定義します。これは、リンク固有のカスタマイズを可能にしながら、特定のリンク層の機能に依存することなく、これを行います。定義では、この仕様は、モバイルIPと相互作用ハンドオーバを考慮します。その新たなアクセスルータに接続後、MNは、往復経路を含むモバイルIP業務に従事し、[3]。その標準のモバイルIPの操作に関して異なる動作をするために、モバイルノードのための特別な要件はありません。
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 RFC 2119 [1]. The use of the term, "silently ignore" is not defined in RFC 2119. However, the term is used in this document and can be similarly construed.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。用語の使用は、「サイレント無視」は、RFC 2119で定義されていないが、この用語は、この文書で使用され、同様に解釈されることができます。
The following terminology and abbreviations are used in this document. The reference handover scenario is illustrated in Figure 1.
次の用語と略語が本文書で使用されています。参照ハンドオーバシナリオが図1に示されています。
Mobile Node (MN) A Mobile IPv6 host.
モバイルノード（MN）AモバイルIPv6ホスト。
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 MN's Care of Address valid on PAR's subnet.
前のCoA（PCOA）PARのサブネット上の有効なアドレスのMNのケア。
New CoA (NCoA) The MN's Care of Address valid on NAR's subnet.
新たなCoA（NCOA）NARのサブネット上の有効なアドレスのMNのケア。
Handover A process of terminating existing connectivity and obtaining new IP connectivity.
ハンドオーバ既存の接続を終了し、新しいIP接続を取得するプロセス。
Router Solicitation for Proxy Advertisement (RtSolPr) A message from the MN to the PAR requesting information for a potential handover.
プロキシ広告のためのルータ要請（RtSolPrを）潜在的ハンドオーバーのための情報を要求するMNからPARへのメッセージ。
Proxy Router Advertisement (PrRtAdv) A message from the PAR to the MN that provides information about neighboring links facilitating expedited movement detection. The message also acts as a trigger for network-initiated handover.
プロキシルータ広告（代理ルータ広告）迅速動き検出を容易にする隣接リンクに関する情報を提供してMNへPARからのメッセージ。メッセージはまた、ネットワーク開始のハンドオーバのためのトリガとして働きます。
(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-情報）タプルは（AP-IDによって識別される）アクセスポイントが接続されているインターフェイス上で有効なアクセスルータのL2およびIPアドレス、およびプレフィックスが含まれています。トリプレット[ルータのL2アドレスは、ルータのIPアドレス、プレフィックス]「AR-情報」と呼ばれています。
Assigned Addressing A particular type of NCoA configuration in which the NAR assigns an IPv6 address for the MN. The method by which NAR manages its address pool is not specified in this document.
NARは、MNのIPv6アドレスを割り当てたNCOA構成の特定のタイプに対処割り当て。 NARは、そのアドレスプールを管理する方法は、この文書で指定されていません。
Fast Binding Update (FBU) A message from the MN instructing its PAR to redirect its traffic (toward NAR).
高速そのPAR（NARに向かって）そのトラフィックをリダイレクトすることを指示MNからの更新（FBU）メッセージをバインディング。
Fast Binding Acknowledgment (FBack) A message from the PAR in response to an FBU.
高速バインディング応答（戻る）FBIに応じてPARからのメッセージ。
Fast Neighbor Advertisement (FNA) A message from the MN to the NAR to announce attachment, and to confirm the use of NCoA when the MN has not received an FBACK.
高速隣接広告（FNA）MNからNARへのメッセージの添付ファイルを発表すると、MNはFBACKを受信していないNCOAの使用を確認します。
Handover Initiate (HI) A message from the PAR to the NAR regarding an MN's handover.
ハンドオーバは、（HI）MNのハンドオーバに関するPARからNARへのメッセージを開始します。
Handover Acknowledge (HAck) A message from the NAR to the PAR as a response to HI.
ハンドオーバは、（上記ハンドオフ）HIに対する応答としてPARにNARからメッセージを確認します。
v +------------+
+-+ | Previous | <
| | ---------- | Access | ------ > ----\
+-+ | Router | < \
MN | (PAR) | \
| +------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +------------+ /
+-+ | New | < /
| | ---------- | Access | ------ > ----/
+-+ | Router | <
MN | (NAR) |
+------------+
Figure 1: Reference Scenario for Handover
図1：ハンドオーバのためのレファレンス・シナリオ
The ability to immediately send packets from a new subnet link depends on the "IP connectivity" latency, which in turn depends on the movement detection latency and new CoA configuration latency. Once an MN is IP-capable on the new subnet link, it can send a Binding Update to its Home Agent and one or more correspondents. Once its correspondents successfully process the Binding Update, which typically involves the Return Routability procedure, the MN can receive packets at the new CoA. So, the ability to receive packets from correspondents directly at its new CoA depends on the Binding Update latency as well as the IP connectivity latency.
すぐに新しいサブネットリンクからパケットを送信する機能は、順番に移動検出遅延と新しいCoAを設定待ち時間に依存し、「IP接続」の待ち時間に依存します。 MNは、新しいサブネットリンク上でIP-ことができたら、それはそのホームエージェントと1つ以上の特派へのバインディングアップデートを送信することができます。その特派が正常に一般的にリターンルータビリティ手順を伴うバインディング更新を処理すると、MNは、新たなCoAにパケットを受信することができます。だから、その新たなCoAに直接特派からパケットを受信する機能は、バインディング更新の待ち時間だけでなく、IP接続の待ち時間に依存します。
The protocol enables an MN to quickly detect that it has moved to a new subnet by providing the new access point and the associated subnet prefix information when the MN is still connected to its current subnet (i.e., PAR in Figure 1). For instance, an MN may discover available access points using link-layer specific mechanisms (i.e., a "scan" in WLAN) and then request subnet information corresponding to one or more of those discovered access points. The MN may do this after performing router discovery or at any time while connected to its current router. The result of resolving an identifier associated with an access point is a [AP-ID, AR-Info] tuple, which an MN can use in readily detecting movement: when attachment to an access point with AP-ID takes place, the MN knows the corresponding new router's coordinates including its prefix, IP address, and L2 address. The "Router Solicitation for Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement (PrRtAdv)" messages (see Section 6.1) are used for aiding movement detection.
プロトコルはすぐ新しいアクセスポイントとMNが依然として現在のサブネットに接続されている関連するサブネットプレフィックス情報を提供することによって、それが新しいサブネットに移動したことを検出するためにMNを可能にする（すなわち、図1におけるPAR）。例えば、MNは、リンク層特定のメカニズム（WLANですなわち「スキャン」）を使用して利用可能なアクセスポイントを発見すると、アクセスポイントを発見し、それらのうちの1つまたは複数に対応するサブネット情報を要求することができます。 MNは、ルータ検出を行った後、または、現在のルータに接続しながら、いつでもこれを行うことがあります。アクセスポイントに関連する識別子を解決した結果は、MNが容易に動きを検出するのに使用することができる[AP-ID、AR-INFO]タプルである：AP-IDを持つアクセスポイントへの取り付けが行われるとき、MNが知っていますその接頭辞、IPアドレス、およびL2アドレスを含む対応する新しいルータの座標。 「プロキシ広告のためのルーター要請（RtSolPrを）」と「プロキシルータ通知（代理ルータ広告）は、」メッセージ（セクション6.1を参照）動き検出を支援するために使用されています。
Through the RtSolPr and PrRtAdv messages, the MN also formulates a prospective new CoA (NCoA) when it is still present on the PAR's link. Hence, the latency due to new prefix discovery subsequent to handover is eliminated. Furthermore, this prospective address can be used immediately after attaching to the new subnet link (i.e., NAR's link) when the MN has received a "Fast Binding Acknowledgment (FBack)" message prior to its movement. If it moves without receiving an FBack, the MN can still start using NCoA after announcing its attachment through a "Fast Neighbor Advertisement (FNA)" message. NAR responds to FNA if the tentative address is already in use thereby reducing NCoA configuration latency. Under some limited conditions in which the probability of address collision is considered insignificant, it may be possible to use NCoA immediately after attaching to the new link. Even so, all implementations MUST support and SHOULD use the mechanism specified in this document to avoid potential address conflicts.
それはまだPARのリンク上に存在しているときRtSolPrをし、代理ルータ広告メッセージを介して、MNはまた、将来の新たなCoA（NCOA）を策定しています。したがって、ハンドオーバ後に新しいプレフィックス発見のために待ち時間が解消されます。さらに、この将来のアドレスは直ちにMNが前の動きに「ファストバインディング肯定応答（FBACK）」メッセージを受信したときに新しいサブネットリンク（すなわち、NARのリンク）に装着して使用することができます。それはFBACKを受けずに移動した場合、MNは、まだ「高速近隣広告（FNA）」メッセージを通じてその添付ファイルを発表した後NCOAを使い始めることができます。仮アドレスは、それによってNCOA設定待ち時間を低減既に使用されている場合NARは、FNAに応答します。アドレス衝突の確率が重要でないとみなされているいくつかの限られた条件の下で、すぐに新しいリンクに取り付けた後NCOAを使用することも可能です。たとえそうであっても、すべての実装がサポートしなければならないし、潜在的なアドレスの競合を避けるために、この文書で指定されたメカニズムを使用すべきです。
To reduce the Binding Update latency, the protocol specifies a tunnel between the Previous CoA (PCoA) and the NCoA. An MN sends a "Fast Binding Update" message to its Previous Access Router to establish this tunnel. When feasible, the MN SHOULD send an FBU from PAR's link. Otherwise, it should be sent immediately after attachment to NAR has been detected. Subsequent sections describe the protocol mechanics. As a result, PAR begins tunneling packets arriving for PCoA to NCoA. Such a tunnel remains active until the MN completes the Binding Update with its correspondents. In the opposite direction, the MN SHOULD reverse tunnel packets to PAR until it completes the Binding Update. PAR SHOULD forward the inner packet in the tunnel to its destination (i.e., to the MN's correspondent). Such a reverse tunnel ensures that packets containing PCoA as a source IP address are not dropped due to ingress filtering. Readers may observe that even though the MN is IP-capable on the new link, it cannot use NCoA directly with its correspondents without the correspondents first establishing a binding cache entry (for NCoA). Forwarding support for PCoA is provided through a reverse tunnel between the MN and the PAR.
バインディング更新の待ち時間を低減するために、プロトコルは、前のCoA（PCOA）とNCOA間トンネルを特定します。 MNは、このトンネルを確立するために、その前のアクセスルータへの「高速バインディングアップデート」メッセージを送信します。可能な場合、MNは、PARのリンクからFBUを送るべきです。それ以外の場合は、NARに添付ファイルが検出された直後に送られるべきです。後続のセクションでは、プロトコルの仕組みを説明しています。その結果、PARはNCOAにPCOAため到着トンネリングパケットを開始します。 MNはその特派との結合更新を完了するまで、このようなトンネルがアクティブのままになります。それはバインディング更新を完了するまで、反対方向に、MNがPARにトンネルパケットを逆べきです。 PAR（すなわち、MNの対応する）その宛先へのトンネルで内部パケットを転送すべきです。そのようなリバーストンネルは、送信元IPアドレスとしてPCOAを含むパケットが原因イングレスフィルタリングに低下していないことを保証します。読者は、MNは、新しいリンク上のIP対応であっても、それは最初の（NCOA用）バインディングキャッシュエントリを確立特派せずにその特派と直接NCOAを使用できないことを観察することができます。 PCOAの転送のサポートは、MNとPARとの間の逆方向トンネルを介して提供されます。
Setting up a tunnel alone does not ensure that the MN receives packets as soon as it is attached to a new subnet link, unless the NAR can detect the MN's presence. A neighbor discovery operation involving a neighbor's address resolution (i.e., Neighbor Solicitation and Neighbor Advertisement) typically results in considerable delay, sometimes lasting multiple seconds. For instance, when arriving packets trigger NAR to send Neighbor Solicitation before the MN attaches, subsequent retransmissions of address resolution are separated by a default period of one second each. To circumvent this delay, an MN announces its attachment through the FNA message that allows the NAR to consider MN to be reachable. If there is no existing entry, FNA allows NAR to create one. If NAR already has an entry, FNA updates the entry while taking potential address conflicts into consideration. Through tunnel establishment for PCoA and fast advertisement, the protocol provides expedited forwarding of packets to the MN.
NARは、MNの存在を検出することができない限り、単独のトンネルを設定すると、MNは、すぐにそれが新しいサブネットリンクに接続されるパケットを受信していることを確認していません。隣人のアドレス解決（すなわち、近隣要請と近隣広告）を含む近隣探索操作は、一般的に、時には複数秒続く、かなりの遅延につながります。例えば、到着するパケットは、MNがアドレス解決の後続の再送信を1秒毎の既定の期間によって分離されて、付着前に近隣要請を送信するNARをトリガします。この遅延を回避するために、MNは、NARは、MNが到達可能であることを考慮することができますFNAメッセージを通じてその添付ファイルを発表しました。既存のエントリが存在しない場合、FNAは、NARは1を作成することができます。 NARが、すでにエントリがある場合は、FNAを考慮に潜在的なアドレスの競合を服用中のエントリを更新します。 PCOAと高速広告のためのトンネル確立を介して、プロトコルは、MNへのパケットの優先転送を提供します。
The protocol also provides the following important functionalities. The access routers can exchange messages to confirm that a proposed NCoA is acceptable. For instance, when an MN sends an FBU from PAR's link, FBack can be delivered after the NAR considers the NCoA acceptable for use. This is especially useful when addresses are assigned by the access router. The NAR can also rely on its trust relationship with PAR before providing forwarding support for the MN. That is, it may create a forwarding entry for the NCoA subject to "approval" from PAR which it trusts. Finally, the access routers could transfer network-resident contexts, such as access control, QoS, and header compression, in conjunction with handover. For these operations, the protocol provides "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages. Both of these messages MUST be supported and SHOULD be used. The access routers MUST have necessary security association established by means outside the scope of this document.
また、このプロトコルは、次の重要な機能を提供します。アクセスルータは、提案NCOAが受け入れ可能であることを確認するためにメッセージを交換することができます。 MNがPARのリンクからFBUを送信するときにたとえば、FBACKはNARは使用が許容NCOAを考慮した後にお届けすることができます。アドレスはアクセスルータによって割り当てられている場合に特に便利です。 NARはまた、MNの転送のサポートを提供する前に、PARとの信頼関係に依存することができます。それは、それが信頼PARから「承認」をNCOA対象の転送エントリを作成すること、です。最後に、アクセスルータは、ハンドオーバに関連して、このようなアクセス制御、QoS、およびヘッダ圧縮のようなネットワーク常駐コンテキストを転送することができました。これらの操作のために、プロトコルが提供する「ハンドオーバを開始（HI）」およびメッセージ「ハンドオーバは、（ハック）肯定応答」。これらのメッセージの両方をサポートしなければなりませんし、使用されるべきです。アクセスルータは、この文書の範囲外の手段によって確立され、必要なセキュリティアソシエーションを持たなければなりません。
The protocol begins when an MN sends an RtSolPr to its access router to resolve one or more Access Point Identifiers to subnet-specific information. In response, the access router (e.g., PAR in Figure 1) sends a PrRtAdv message containing one or more [AP-ID, AR-Info] tuples. The MN may send a RtSolPr at any convenient time, for instance as a response to some link-specific event (a "trigger") or simply after performing router discovery. However, the expectation is that prior to sending RtSolPr, the MN will have discovered the available APs by link-specific methods. The RtSolPr and PrRtAdv messages do not establish any state at the access router; their packet formats are defined in Section 6.1.
MNがサブネット固有の情報を一つ以上のアクセスポイントの識別子を解決するために、そのアクセスルータにRtSolPrをを送信するときのプロトコルが開始されます。これに応答して、アクセスルータ（図1の例えば、PAR）は、1つ以上の[AP-ID、AR-INFO]タプルを含む代理ルータ広告メッセージを送信します。 MNは、いくつかのリンク固有のイベント（「トリガー」）への応答として、あるいは単にルータディスカバリを実行した後、たとえば、任意の都合のよい時間にRtSolPrをを送信することができます。しかし、期待は前RtSolPrをを送信し、MNは、リンク固有の方法で利用可能なAPを発見したということです。 RtSolPrをと代理ルータ広告メッセージは、アクセスルータのいずれかの状態を確立していません。そのパケットフォーマットは、6.1節で定義されています。
With the information provided in the PrRtAdv message, the MN formulates a prospective NCoA and sends an FBU message when a link-specific handover event occurs. The purpose of the FBU is to authorize PAR to bind PCoA to NCoA, so that arriving packets can be tunneled to the new location of the MN. Whenever feasible, the FBU SHOULD be sent from PAR's link. For instance, an internal link-specific trigger could enable FBU transmission from the previous link. When it is not feasible, the FBU is sent from the new link. Care must be taken to ensure that the NCoA used in FBU does not conflict with an address already in use by some other node on the link. For this, FBU encapsulation within FNA MUST be implemented and SHOULD be used (see below) when the FBU is sent from NAR's link.
代理ルータ広告メッセージに提供された情報を用いて、MNは、予想NCOAを定式化し、リンク固有のハンドオーバーイベントが発生したときにFBUメッセージを送信します。 FBUの目的は、到着するパケットは、MNの新しい位置にトンネリングすることができるように、NCOAにPCOAをバインドするためにPARを承認することです。たび実現可能な、FBUはPARのリンクから送信されます。例えば、内部リンクに固有のトリガは、前リンクからFBU伝送を可能にすることができます。それが不可能な場合は、FBUは、新しいリンクから送られてきます。ケアは、FBUに使用NCOAが、リンク上の他のノードですでに使用されたアドレスと競合しないように注意する必要があります。このために、FNA内のFBUのカプセル化は実装しなければならないとFBUは、NARのリンクから送信された場合（下記参照）を使用する必要があります。
The format and semantics of FBU processing are specified in Section 6.3.1.
FBU処理の形式と意味論はセクション6.3.1で指定されています。
Depending on whether an FBack is received on the previous link (which clearly depends on whether the FBU was sent in the first place), there are two modes of operation.
FBACKは（明確FBUは最初の場所に送信されたかどうかに依存する）前のリンク上で受信されたか否かに応じて、2つの動作モードがあります。
1. The MN receives an FBack on the previous link. This means that packet tunneling is already in progress by the time the MN handovers to NAR. The MN SHOULD send FNA immediately after attaching to NAR, so that arriving and buffered packets can be forwarded to the MN right away.
1. MNは、前のリンク上でFBACKを受けます。これは、パケットトンネリングがNARにMNは、ハンドオーバ時間ですでに進行中であることを意味します。到着とバッファリングされたパケットは、すぐにMNに転送することができるように、MNは、すぐにNARに取り付けた後にFNAを送るべきです。
Before sending an FBack to an MN, PAR can determine whether the NCoA is acceptable to the NAR through the exchange of HI and HAck messages. When assigned addressing (i.e., addresses are assigned by the router) is used, the proposed NCoA in the FBU is carried in HI, and the NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST be returned in HAck, and the PAR MUST in turn provide the assigned NCoA in the FBack. If there is an assigned NCoA returned in the FBack, the MN MUST use the assigned address (and not the proposed address in the FBU) upon attaching to NAR.
MNにFBACKを送信する前に、PARはNCOAがHIと上記ハンドオフメッセージの交換を通じてNARに受け入れられるかどうかを判断することができます。 （すなわち、アドレスはルータによって割り当てられた）アドレッシング割り当てを使用する場合、FBUに提案NCOAはHIで運ばれ、NARが提案NCOAを割り当てることができます。このような割り当てられたNCOAハックで戻らなければならない、と順番にPARのMUSTはFBACKに割り当てられたNCOAを提供しています。割り当てられたNCOAがFBACKであっ返された場合、MNは、NARへの取り付け時に割り当てられたアドレス（とないFBUで提案されているアドレス）を使用する必要があります。
2. The MN does not receive the FBack on the previous link because the MN has not sent the FBU or the MN has left the link after sending the FBU (which itself may be lost), but before receiving an FBack. Without receiving an FBack in the latter case, the MN cannot ascertain whether PAR has successfully processed the FBU. Hence, it (re)sends an FBU as soon as it attaches to NAR. To enable NAR to forward packets immediately (when FBU has been processed) and to allow NAR to verify whether NCoA is acceptable, the MN SHOULD encapsulate the FBU in the FNA. If NAR detects that NCoA is in use when processing the FNA, for instance while creating a neighbor entry, it MUST discard the inner FBU packet and send a Router Advertisement with the "Neighbor Advertisement Acknowledge (NAACK)" option in which NAR MAY include an alternate IP address for the MN to use. This discarding avoids the rare and undesirable outcome that results from address collision. Detailed FNA processing rules are specified in Section 6.3.3.
しかし、FBACKを受ける前に、MNがFBU送信していないか、MNは、（それ自体が失われる可能性があります）FBUを送信した後、リンクを残しているので、2 MNは、前のリンク上でFBACKを受信しません。後者の場合にはFBACKを受けることなく、MNがPARはFBUを正常に処理したかどうかを確かめることができません。したがって、それは（再）とすぐにそれがNARに接続するようFBUを送信します。 （FBUが処理されたときに）直ちにパケットを転送し、NARはNCOAが許容可能であるかどうかを確認できるようにNARを可能にするために、MNは、FNAにFBUをカプセル化するべきです。 NARは、ネイバーエントリを作成しながら、例えば、FNAを処理する際NCOAが使用中であることを検出した場合には、内側のFBUパケットを破棄し、NARには、可能性のある「隣人広告アクノリッジ（NAACK）」オプションを使用して、ルータ広告を送らなければなりませんMNが使用する代替IPアドレス。この廃棄は、アドレス衝突の結果で珍しいと望ましくない結果を避けることができます。詳細FNA処理ルールは、6.3.3項で規定されています。
The scenario in which an MN sends an FBU and receives an FBack on PAR's link is illustrated in Figure 2. For convenience, this scenario is characterized as "predictive" mode of operation. The scenario in which the MN sends an FBU from NAR's link is illustrated in Figure 3. For convenience, this scenario is characterized as a "reactive" mode of operation. Note that the reactive mode also includes the case in which an FBU has been sent from PAR's link but an FBack has not been received yet.
MNは、FBUを送信し、PARのリンク上FBACKを受信するシナリオでは、このシナリオは、動作の「予測」モードとして特徴付けられる、便宜上、図2に示されています。 MNがNARのリンクからFBUを送信するシナリオは、このシナリオでは、操作の「反応」モードとして特徴付けられる、便宜上、図3に示されています。反応性モードもFBUをPARのリンクから送られてきたが、FBACKがまだ受信されていない場合も含むことに注意してください。
Finally, the PrRtAdv message may be sent unsolicited (i.e., without the MN first sending a RtSolPr). This mode is described in Section 3.3.
最後に、代理ルータ広告メッセージが求められていない送信することができる（すなわち、第一RtSolPrをMNに送信せずに）。このモードは、3.3節に記載されています。
In some wireless technologies, the handover control may reside in the network even though the decision to undergo handover may be mutually arrived at between the MN and the network. In these networks, the PAR can send an unsolicited PrRtAdv containing the link layer address, IP address, and subnet prefixes of the NAR when the network decides that a handover is imminent. The MN MUST process this PrRtAdv to configure a new care of address on the new subnet, and MUST send an FBU to PAR prior to switching to the new link. After transmitting PrRtAdv, the PAR MUST continue to forward packets to the MN on its current link until the FBU is received. The rest of the operation is the same as that described in Section 3.2.
いくつかの無線技術では、ハンドオーバ制御、ハンドオーバを受ける決定が相互MNとネットワークとの間に到着することができるにもかかわらず、ネットワーク内に存在してもよいです。これらのネットワークでは、PARは、ネットワークがハンドオーバが差し迫っていると判断したときに、リンク層アドレス、IPアドレス、およびNARのサブネットプレフィックスを含む未承諾代理ルータ広告を送信することができます。 MNは、新しいサブネット上のアドレスの新しいケアを設定するには、この代理ルータ広告を処理しなければならない、と前に新しいリンクへの切り替えにPARにFBUを送らなければなりません。代理ルータ広告を送信した後、PARはFBUが受信されるまで、現在のリンク上のMNにパケットを転送し続けなければなりません。その他の動作は、3.2節で説明したものと同じです。
The unsolicited PrRtAdv also allows the network to inform the MN about geographically adjacent subnets without the MN having to explicitly request that information. This can reduce the amount of wireless traffic required for the MN to obtain a neighborhood topology map of links and subnets. Such usage of PrRtAdv is decoupled from the actual handover; see Section 6.1.2.
迷惑代理ルータ広告は、ネットワークがMNが明示的にその情報を要求することなく、地理的に隣接したサブネットについてMNに通知することができます。これは、リンクとサブネットの近所のトポロジマップを得るために、MNのために必要な無線トラフィックの量を減らすことができます。代理ルータ広告のそのような使用は、実際のハンドオーバから分離されます。 6.1.2項を参照してください。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: "Predictive" Fast Handover
図2：「予測」の高速ハンドオーバー
All descriptions refer to Figure 1.
すべての記述は、図1を参照してください。
After discovering one or more nearby access points, the MN sends RtSolPr to resolve access point identifiers to subnet router information. This is convenient to do after performing router discovery. However, the MN can send RtSolPr at any time, e.g., when one or more new access points are discovered. The MN can also send RtSolPr more than once during its attachment to PAR. The trigger for sending RtSolPr can originate from a link-specific event, such as the promise of a better signal strength from another access point coupled with fading signal quality with the current access point. Such events, often broadly referred to as "L2 triggers", are outside the scope of this document. Nevertheless, they serve as events that invoke this protocol. For instance, when a "link up" indication is obtained on the new link, protocol messages (e.g., FNA) can be immediately transmitted. Implementations SHOULD make use of such triggers whenever possible.
一つ以上の近くのアクセスポイントを発見した後、MNは、RtSolPrをルータ情報をサブネットするアクセスポイント識別子を解決するために送信します。これは、ルータディスカバリを実行した後に行うのが便利です。しかし、MNは、例えば、1つ以上の新しいアクセスポイントが発見されたときに、いつでもRtSolPrを送信することができます。 MNはまた、PARへの取り付けの際に複数回RtSolPrを送信することができます。 RtSolPrをを送信するためのトリガは、現在のアクセスポイントの信号品質フェージングと結合された別のアクセスポイントから良好な信号強度の約束として、リンク固有のイベントに由来し得ます。そのような事象は、しばしば広く「L2トリガー」と呼ばれる、この文書の範囲外です。それにもかかわらず、彼らはこのプロトコルを起動するイベントとしての役割を果たす。 「リンクアップ」表示が新しいリンク上で得られた場合、例えば、プロトコルメッセージ（例えば、FNA）直ちに送信することができます。実装は可能な限り、そのようなトリガの使用をしなければなりません。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|------FNA[FBU]-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| |
Figure 3: "Reactive" Fast Handover
図3：「反応性」高速ハンドオーバ
The RtSolPr message contains one or more AP-IDs. A wildcard requests all available tuples.
RtSolPrをメッセージは、一つ以上のAP-IDが含まれています。ワイルドカードは、利用可能なすべてのタプルを要求します。
As a response to RtSolPr, PAR sends a PrRtAdv message that indicates one of the following possible conditions.
RtSolPrをへの応答として、PARは、次の可能な条件のいずれかを示す代理ルータ広告メッセージを送信します。
1. If the PAR does not have an entry corresponding to the new access point, it MUST respond indicating that the new access point is unknown. The MN MUST stop fast handover protocol operations on the current link. The MN MAY send an FBU from its new link.
1. PARが新しいアクセスポイントに対応するエントリを持っていない場合は、新しいアクセスポイントが不明であることを示す応答しなければなりません。 MNは、現在のリンク上での高速ハンドオーバプロトコル動作を停止する必要があります。 MNは、その新しいリンクからFBUを送信することができます。
2. If the new access point is connected to the PAR's current interface (to which MN is attached), the PAR MUST respond with a Code value indicating that the new access point is connected to the current interface, but not send any prefix information. This scenario could arise, for example, when several wireless access points are bridged into a wired network. No further protocol action is necessary.
新しいアクセスポイントは、（MNが取り付けられている）PARの現在のインターフェイスに接続されている場合2.、PARは、新しいアクセスポイントは、現在のインターフェイスに接続されていることを示すコード値で応答しますが、任意のプレフィックス情報を送信してはなりません。このシナリオでは、いくつかの無線アクセスポイントは、有線ネットワークにブリッジされる場合、例えば、生じ得ます。これ以上のプロトコルの操作は必要ありません。
3. If the new access point is known and the PAR has information about it, then PAR MUST respond indicating that the new access point is known and supply the [AP-ID, AR-Info] tuple. If the new access point is known, but does not support fast handover, the PAR MUST indicate this with Code 3 (See Section 6.1.2).
3.新しいアクセスポイントが知られており、PARはそれについての情報を有している場合、PAR、新しいアクセスポイントが既知であることを示す応答し、[AP-ID、AR-INFO]タプルを供給しなければなりません。新しいアクセスポイントが知られているが、高速ハンドオーバをサポートしていない場合、PARは、コード3（6.1.2項を参照）でこれを示さなければなりません。
4. If a wildcard is supplied as an identifier for the new access point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples that are subject to path MTU restrictions (i.e., provide any `n' tuples without exceeding the link MTU).
前記ワイルドカードが新しいアクセスポイントの識別子として供給される場合、PAR（すなわち、超過することなく、任意の 'N」タプルを提供パスMTU制限の対象となっている近隣[AP-ID、AR-INFO]タプルを提供する必要がありリンクMTU）。
When further protocol action is necessary, some implementations MAY choose to begin buffering copies of incoming packets at the PAR. If such FIFO buffering is used, the PAR MUST continue forwarding the packets to PCoA (i.e., buffer and forward). Such buffering can be useful when the MN leaves without sending the FBU message from the PAR's link. The PAR SHOULD stop buffering after processing the FBU message. The size of the buffer is an implementation-specific consideration.
さらに、プロトコルの動作が必要な場合は、いくつかの実装は、PARで着信パケットのコピーをバッファリングを開始することを選択するかもしれません。そのようなFIFOバッファを使用する場合、PAR（すなわち、緩衝液および転送）PCOAにパケットを転送し続ける必要があります。 MNがPARのリンクからFBUメッセージを送信せずに離れたとき、そのようなバッファリングは便利です。 PARはFBUメッセージを処理した後、バッファリングを停止する必要があります。バッファのサイズは、実装固有の考慮事項です。
The method by which Access Routers exchange information about their neighbors, and thereby allow construction of Proxy Router Advertisements with information about neighboring subnets is outside the scope of this document.
隣人約によるアクセスルータ情報を交換する方法、およびそれによって隣接するサブネットに関する情報をプロキシルータ広告の構築を可能にするが、この文書の範囲外です。
The RtSolPr and PrRtAdv messages MUST be implemented by an MN and an access router that supports fast handovers. However, when the parameters necessary for the MN to send packets immediately upon attaching to the NAR are supplied by the link layer handover mechanism itself, use of above messages is optional on such links.
RtSolPrをと代理ルータ広告メッセージは、MNと高速ハンドオーバをサポートするアクセスルータによって実装されなければなりません。 NARに取り付けると直ちにパケットを送信するMNに必要なパラメータは、リンク層ハンドオーバ機構自体によって供給される場合しかし、上記メッセージの使用は、そのようなリンクのオプションです。
After a PrRtAdv message is processed, the MN sends an FBU at a time determined by link-specific events, and includes the proposed NCoA. The MN SHOULD send the FBU from PAR's link whenever "anticipation" of handover is feasible. When anticipation is not feasible or when it has not received an FBack, the MN sends an FBU immediately after attaching to NAR's link. This FBU SHOULD be encapsulated in an FNA message. The encapsulation allows the NAR to discard the (inner) FBU packet if an address conflict is detected as a result of (outer) FNA packet processing (see FNA processing below). In response to the FBU, the PAR establishes a binding between PCoA ("Home Address") and NCoA, and sends the FBack to the MN. Prior to establishing this binding, PAR SHOULD send an HI message to NAR, and receive HAck in response. To determine the NAR's address for the HI message, the PAR can perform the longest prefix match of NCoA (in FBU) with the prefix list of neighboring access routers. When the source IP address of the FBU is PCoA, i.e., the FBU is sent from the PAR's link, and the HI message MUST have a Code value set to 0; see Section 6.2.1. When the source IP address of the FBU is not PCoA, i.e., the FBU is sent from the NAR's link, the HI message MUST have a Code value of 1; see Section 6.2.1.
代理ルータ広告メッセージが処理された後に、MNは、リンク固有のイベントによって決定される時間でFBUを送信し、提案されたNCOAを含みます。ハンドオーバーの「見越し」は実現可能であるときは常にMNは、PARのリンクからFBUを送るべきです。見越しは現実的ではありませんか、それはFBACKを受信していないとき、MNはすぐにNARのリンクに取り付けた後FBUを送信するとき。このFBUは、FNAメッセージ内にカプセル化されるべきです。カプセル化は、アドレス競合が（外側）FNAパケット処理の結果として検出された場合は、NAR（内側）FBUパケットを破棄することを可能にする（以下FNA処理を参照）。 FBUに対応して、PARはPCOA（「ホームアドレス」）とNCOA間の結合を確立し、MNにFBACKを送信します。このバインディングを確立する前に、PARはNARにHIメッセージを送信し、それに応答してハック受けるべきです。 HIメッセージのNARのアドレスを決定するために、PARは、隣接アクセスルータのプレフィックスリストで（FBU中）NCOAの最長プレフィックス一致を実行することができます。 FBUの送信元IPアドレスがPCOAである場合、すなわち、FBUは、PARのリンクから送信され、HIメッセージが0に設定されたコード値を有していなければなりません。 6.2.1項を参照してください。 FBUの送信元IPアドレスがPCOAない場合、すなわち、FBUはNARのリンクから送信され、HIメッセージは、1のコード値を有していなければなりません。 6.2.1項を参照してください。
The HI message contains the PCoA, Link-Layer Address, and the NCoA of the MN. In response to processing an HI message with Code 0, the NAR
HIメッセージはPCOA、リンク層アドレス、およびMNのNCOAが含まれています。コード0、NARとHIメッセージを処理することに応答して
1. determines whether NCoA supplied in the HI message is a valid address for use. If it is, the NAR starts proxying [6] the address for PROXY_ND_LIFETIME during which the MN is expected to connect to the NAR. The NAR MAY use the Link-Layer Address to verify whether a corresponding IP address exists in its forwarding tables.
1. NCOAが使用するために有効なアドレスであるHIメッセージで供給されるかどうかを決定します。もしそうであれば、NARは、MNがNARに接続することが期待されている間PROXY_ND_LIFETIME [6]のアドレスをプロキシを開始します。 NARは、対応するIPアドレスが転送テーブルに存在するかどうかを確認するために、リンク層アドレスを使用するかもしれません。
2. allocates NCoA for the MN when assigned addressing is used, creates a proxy neighbor cache entry, and begins defending it. The NAR MAY allocate the NCoA proposed in HI.
2.割り当てられたアドレッシングを使用する場合、MNのためのNCOAを割り当て、プロキシ近隣キャッシュエントリを作成し、それを守る開始します。 NARはNCOAがHIに提案割り当てることができます。
3. MAY create a host route entry for PCoA in case NCoA cannot be accepted or assigned. This host route entry SHOULD be implemented such that until the MN's presence is detected, either through explicit announcement by the MN or by other means, arriving packets do not invoke neighbor discovery. The NAR MAY also set up a reverse tunnel to the PAR in this case.
3.受け入れまたは割り当てることができない場合NCOAにPCOAためのホストルートエントリを作成することができます。このホストルートエントリは、パケットが近隣探索を起動していない到着し、MNによる明示的な告知を介して、または他の手段のいずれかによって、MNの存在が検出されるまでのように実装する必要があります。 NARは、この場合もPARへの逆方向トンネルをセットアップすることができます。
4. provides the status of the handover request in the Handover Acknowledge (HAck) message.
4.ハンドオーバがアクノリッジ（上記ハンドオフ）メッセージにおけるハンドオーバ要求のステータスを提供します。
When the Code value in HI is 1, NAR MUST skip the above operations since it would have performed those operations during FNA processing. However, it SHOULD be prepared to process any other options that may be defined in the future. Sending an HI message with Code 1 allows NAR to validate the neighbor cache entry it creates for the MN during FNA processing. That is, NAR can make use of the knowledge that its trusted peer (i.e., PAR) has a trust relationship with the MN.
HIでコード値が1である場合、それはFNA処理中にこれらの操作を実行したことになるので、NARは、上記の操作をスキップしなければなりません。しかし、将来的に定義することができる他のオプションを処理するために準備されるべきです。コード1とHIメッセージを送信すると、NARは、それがFNA処理中にMNのために作成し、近隣キャッシュエントリを検証することができます。それは、NARはその信頼できるピア（すなわち、PAR）はMNとの信頼関係を持っているという知識を利用することが可能です。
If HAck contains an assigned NCoA, the FBack MUST include it, and the MN MUST use the address provided in the FBack. The PAR MAY send the FBack to the previous link to facilitate faster reception in the event that the MN is still present. The result of the FBU and FBack processing is that PAR begins tunneling the MN's packets to NCoA. If the MN does not receive an FBack message even after retransmitting the FBU for FBU_RETRIES, it must assume that fast handover support is not available and stop the protocol operation.
ハック割り当てられNCOAが含まれている場合は、FBACKはそれを含まなければならない、とMNはFBACKで提供されたアドレスを使用しなければなりません。 PARは、MNが依然として存在している場合にはより高速な受信を容易にするために、以前のリンクにFBACKを送信することができます。 FBUとFBACK処理の結果は、PARがNCOAにMNのパケットをトンネリング始まるということです。 MNもFBU_RETRIESためFBUを再送した後FBACKメッセージを受信しない場合、それは高速ハンドオーバのサポートが利用できないことを想定し、プロトコルの動作を停止する必要があります。
When the MN establishes link connectivity with the NAR, it SHOULD send a Fast Neighbor Advertisement (FNA) message (see 6.3.3). If the MN has not received an FBack by the time the FNA is being sent, it SHOULD encapsulate the FBU in the FNA and send them together.
MNは、NARとのリンク接続を確立すると、それは（6.3.3を参照）、高速近隣広告（FNA）メッセージを送信する必要があります。 MNは、FNAが送信されている時間によってFBACKを受信していない場合は、FNAでFBUをカプセル化し、それらを一緒に送るべきです。
When the NCoA corresponding to the FNA message is acceptable, the NAR MUST
FNAメッセージに対応するNCOAが許容可能である、NARのMUST
1. delete its proxy neighbor cache entry, if any is present.
いずれかが存在する場合は1、そのプロキシ近隣キャッシュエントリを削除します。
2. create a neighbor cache entry and set its state to REACHABLE without overwriting an existing entry for a different layer 2 address.
2.近隣キャッシュエントリを作成し、別のレイヤ2アドレスの既存のエントリを上書きせずにREACHABLEにその状態を設定します。
3. forward any buffered packets.
3.任意のバッファされたパケットを転送します。
4. enable the host route entry for PCoA, if any is present.
いずれかが存在する場合4. PCOAのためのホストルートエントリを可能にします。
When the NCoA corresponding to the FNA message is not acceptable, the NAR MUST
FNAメッセージに対応するNCOAが許容できない場合、NARは必須
1. discard the inner (FBU) packet.
1.内側（FBU）パケットを破棄する。
2. send a Router Advertisement with the NAACK option in which it MAY include an alternate NCoA for use. This message MUST be sent to the source IP address present in the FNA using the same Layer 2 address present in the FNA.
2.それは使用するための代替NCOAを含むことができるでNAACKオプションでルータ通知を送信します。このメッセージは、FNAで同じレイヤ2アドレスの存在を使用してFNAの送信元IPアドレスの存在に送らなければなりません。
If the MN receives a Router Advertisement with a NAACK option, it MUST use the IP address, if any, provided in the NAACK option. Otherwise, the MN should configure another NCoA. Subsequently, the MN SHOULD send an FBU using the new CoA. As a special case, the address supplied in NAACK could be PCoA itself, in which case the MN MUST NOT send any more FBUs.
MNはNAACKオプションでルータ広告を受信した場合、それはNAACKオプションで提供されるIPアドレスを、もしあれば、使用しなければなりません。それ以外の場合は、MNは別のNCOAを設定する必要があります。その後、MNは、新しいCoAを使用してFBUを送るべきです。特殊なケースとして、NAACKに供給されたアドレスは、MNがこれ以上FBUSを送ってはいけません、その場合にはPCOAそのものである可能性があります。
Once the MN has confirmed its NCoA, it SHOULD send a Neighbor Advertisement message. This message allows MN's neighbors to update their neighbor cache entries with the MN's addresses.
MNはそのNCOAを確認したら、それは近隣広告メッセージを送るべきです。このメッセージは、MNの隣人は、MNのアドレスとその近隣キャッシュエントリを更新することができます。
Just as in Mobile IPv6, the PAR sets the 'R' bit in the Prefix Information option, and includes its 128 bit global address in the router advertisements. This allows the mobile nodes to learn the PAR's global IPv6 address. The MN reverse tunnels its packets to the same global address of PAR. The tunnel end-point addresses must be configured accordingly. When PAR receives a reverse tunneled packet, it must verify if a secure binding exists for the MN identified by PCoA in the tunneled packet, before forwarding the packet.
ただ、モバイルIPv6のように、PARは、プレフィックス情報オプションに「R」ビットを設定し、ルータ広告での128ビットのグローバルアドレスを含んでいます。これは、モバイルノードはPARのグローバルIPv6アドレスを学習することができます。 MNの逆はPARの同じグローバルアドレスにそのパケットをトンネルします。トンネルエンドポイントアドレスはそれに応じて設定する必要があります。 PARが逆トンネリングされたパケットを受信した場合、安全な結合がパケットを転送する前に、トンネリングされたパケットにPCOAによって識別されるMNのために存在している場合、それは確認する必要があります。
The MN expects a PrRtAdv in response to its RtSolPr message. If the MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it must assume that PAR does not support the fast handover protocol and stop sending RtSolPr messages.
MNは、そのRtSolPrをメッセージに応じて代理ルータ広告を見込んでいます。 MNもRTSOLPR_RETRIES後に代理ルータ広告メッセージを受信しない場合、それはPARが高速ハンドオーバプロトコルをサポートし、RtSolPrをメッセージの送信を停止しないことを前提としなければなりません。
Even if an MN's current access router is capable of fast handover, the new access router to which the MN attaches may be incapable of fast handover. This is indicated to the MN during "runtime", through the PrRtAdv message with a Code value of 3 (see Section 6.1.2).
MNの現在のアクセスルータが高速ハンドオーバが可能な場合でも、新しいアクセスルータは、MNのアタッチは、高速ハンドオーバすることができないことがあるためにどの。これは、3のコード値（セクション6.1.2を参照）との代理ルータ広告メッセージを通じて、「ランタイム」時にMNに通知されます。
Typically, the MN formulates its prospective NCoA using the information provided in a PrRtAdv message and sends the FBU. The PAR MUST use the NCoA present in the FBU in its HI message. The NAR MUST verify if the NCoA present in HI is already in use. In any case, NAR MUST respond to HI using a HAck, in which it may include another NCoA to use, especially when assigned address configuration is used. If there is a CoA present in HAck, the PAR MUST include it in the FBack message.
典型的には、MNは、代理ルータ広告メッセージに提供された情報を使用して将来のNCOAを定式化し、FBUを送信します。 PARは、HIメッセージにFBUにNCOAの存在を使用しなければなりません。 HIでNCOAの存在が既に使用されている場合NARは確かめなければなりません。いずれの場合においても、NARは、割り当てられたアドレスの設定が使用されている場合は特に、それが使用する別のNCOAを含むことができるでは、ハック用いてHIに応答しなければなりません。上記ハンドオフ中のCoAが存在した場合、PARはFBACKメッセージにそれを含まなければなりません。
If a PrRtAdv message carries an NCoA, the MN MUST use it as its prospective NCoA.
代理ルータ広告メッセージはNCOAを運ぶ場合は、MNは、その将来のNCOAとしてそれを使用しなければなりません。
Handover involves link switching, which may not be exactly coordinated with fast handover signaling. Furthermore, the arrival pattern of packets is dependent on many factors, including application characteristics, network queuing behaviors, etc. Hence, packets may arrive at the NAR before the MN is able to establish its link there. These packets will be lost unless they are buffered by the NAR. Similarly, if the MN attaches to the NAR and then sends an FBU message, packets arriving at the PAR will be lost unless they are buffered. This protocol provides an option to indicate a request for buffering at the NAR in the HI message. When the PAR requests this feature (for the MN), it SHOULD also provide its own support for buffering.
ハンドオーバは、正確に、高速ハンドオーバシグナリングと調整されないことがあり、リンクの切り替えを伴います。また、パケットの到着パターンは、MNがそのリンクを確立することができる前に、したがって、パケットがNARに到達することができる等アプリケーションの特性、ネットワークキューイングの動作、を含む多くの要因に依存しています。彼らはNARでバッファリングされない限り、これらのパケットが失われます。 MNがNARにアタッチして、FBUメッセージを送信した場合、それらがバッファリングされていない限り、同様に、PARに到着するパケットが失われます。このプロトコルは、HIメッセージにNARにバッファリングするための要求を示すためのオプションを提供します。 PARは、（MN用）この機能を要求すると、それはまた、バッファリングのための独自のサポートを提供する必要があります。
Duplicate Address Detection (DAD) was defined in [7] to avoid address duplication on links when stateless address auto-configuration is used. The use of DAD to verify the uniqueness of an IPv6 address configured through stateless auto-configuration adds delays to a handover.
重複アドレス検出（DAD）がステートレスアドレス自動設定を使用する場合、[7]のリンク上のアドレスの重複を避けるために定義されました。ステートレス自動構成を使用して構成IPv6アドレスの一意性を確認するためにDADを使用することは、ハンドオーバ遅延を付加します。
The probability of an interface identifier duplication on the same subnet is very low, however it cannot be ignored. In this document, certain precautions are proposed to minimize the effects of a duplicate address occurrence.
同じサブネット上のインタフェース識別子の重複の可能性は、しかし、それは無視できない、非常に低いです。この文書では、一定の注意が重複アドレス発生の影響を最小限にするために提案されています。
In some cases, the NAR may already have the knowledge required to assess whether the MN's address is a duplicate before the MN moves to the new subnet. For example, the NAR can have a list of all nodes on its subnet, perhaps for access control, and by searching this list, it can confirm whether the MN's address is a duplicate. The result of this search is sent back to the PAR in the HAck message. If such knowledge is not available at the NAR, it may indicate this by not confirming the NCoA in the HAck message. The NAR may also indicate this in the NAACK option in response to the FNA message. In such cases, the MN would have to follow the address configuration procedure according to [6] after attaching to the NAR.
いくつかのケースでは、NARは、すでにMNが新しいサブネットに移動する前にMNのアドレスが重複しているかどうかを評価するために必要な知識を有することができます。たとえば、NARは、おそらく、アクセス制御のために、そのサブネット上のすべてのノードのリストを持つことができ、このリストを検索して、それはMNのアドレスが重複しているかどうかを確認することができます。この検索の結果は、ハックメッセージでPARに送り返されます。そのような知識は、NARで利用できない場合、それはハックメッセージにNCOAを確認していないことによってこれを示すかもしれません。 NARはまた、FNAメッセージに応答したNAACKオプションでこれを示すかもしれません。このような場合には、MNがNARに付着した後、[6]に記載のアドレス設定手順を実行しなければなりません。
Although this specification is for fast handover, the protocol is limited in terms of how fast an MN can move. Ping-Pong is a special case of fast movement, where an MN moves between the same two access points rapidly. Another instance of the same problem is erroneous movement, i.e., the MN receives information prior to a handover that it is moving to a new access point, but it is either moved to a different one or it aborts movement altogether. All of the above behaviors are usually the result of link layer idiosyncrasies and thus are often resolved at the link layer itself.
この仕様は、高速ハンドオーバのためですが、プロトコルは、MNが移動することができますどのくらいの速の面で制限されています。ピンポンは、MNが急速に同一の2つのアクセスポイント間を移動する高速移動、の特別な場合です。同じ問題の別のインスタンスが誤って移動され、すなわち、MNは、従来、それが新しいアクセスポイントに移動するハンドオーバー情報を受信し、それを別のものに移動するか、完全に運動を中止のいずれかです。上記の行動のすべては、通常、リンク層特異性の結果であり、したがって、多くの場合、リンク層自身で解決されます。
IP layer mobility, however, introduces its own limits. IP layer handovers should occur at a rate suitable for the MN to update the binding of, at least, its HA and preferably that of every CN with which it is in communication. An MN that moves faster than necessary for this signaling to complete, which may be a few seconds, may start losing packets. The signaling cost over the air interface and in the network may increase significantly, especially in the case of rapid movement between several access routers. To avoid the signaling overhead, the following measures are suggested.
IP層移動度は、しかし、独自の制限を紹介しています。 IPレイヤのハンドオーバは、少なくとも、そのHA、好ましくはすべてのCNのそれがどのとそれが通信している、の結合を更新するために、MNに適した速度で起こるべきです。数秒とすることができる、完了するために、このシグナリングのために速く必要以上に動くMNは、パケットを失って起動することがあります。エアインタフェースを介し、ネットワーク内のシグナリングコストは、特に、いくつかのアクセスルータ間の迅速な移動の場合に、有意に増加し得ます。シグナリングオーバーヘッドを回避するために、以下の対策が提案されています。
An MN returning to the PAR before updating the necessary bindings when present on the NAR MUST send a Fast Binding Update with the Home Address equal to the MN's PCoA and a lifetime of zero to the PAR. The MN should have a security association with the PAR since it performed a fast handover to the NAR. The PAR, upon receiving this Fast Binding Update, will check its set of outgoing (temporary fast handover) tunnels. If it finds a match, it SHOULD tear down that tunnel (i.e., stop forwarding packets for this MN and start delivering packets directly to the node instead). The MN SHOULD NOT attempt to use any of the fast handover mechanisms described in this specification and SHOULD revert back to standard Mobile IPv6.
NARに存在する場合に必要なバインディングを更新する前にPARに戻っMNは、MNのPCOAとPARにゼロの寿命に等しいホームアドレスを用いた高速バインディングアップデートを送らなければなりません。それはNARへの高速ハンドオーバを行ったので、MNはPARとのセキュリティアソシエーションを持つ必要があります。 PARは、この高速バインディングアップデートを受信すると、送信（一時的な高速ハンドオーバ）のトンネルのセットをチェックします。それが一致を見つけた場合、それは（すなわち、このMNのためのパケット転送を停止し、代わりにノードに直接パケットを配信開始）はトンネルを切断すべきです。 MNは、本明細書に記載された高速ハンドオーバメカニズムのいずれかを使用しようとするべきではなく、標準のモバイルIPv6に戻すべきです。
Temporary tunnels for the purpose of fast handovers should use short lifetimes (a small number of seconds or less). The lifetime of such tunnels should be enough to allow an MN to update all its active bindings. The default lifetime of the tunnel should be the same as the lifetime value in the FBU message.
高速のハンドオーバのために、一時的なトンネルは短い寿命（秒以下の小さな数）を使用する必要があります。そのようなトンネルの寿命は、そのすべてのアクティブなバインディングを更新するために、MNを可能にするのに十分でなければなりません。トンネルのデフォルトの寿命は、FBUメッセージ内のライフタイム値と同じでなければなりません。
The effect of erroneous movement is typically limited to the loss of packets since routing can change and the PAR may forward packets toward another router before the MN actually connects to that router. If the MN discovers itself on an unanticipated access router, a Fast Binding Update to the PAR SHOULD be sent. Since Fast Binding Updates are authenticated, they supercede the existing binding and packets MUST be redirected to the newly confirmed location of the MN.
ルーティングが変更することができ、MNが実際にそのルータに接続する前に、PARは、別のルータに向けてパケットを転送することができるので、誤った動きの影響は、典型的には、パケットの損失に限定されます。 MNは、予期せぬアクセスルータ上で自分自身を発見した場合、PARへの高速バインディングアップデートを送ってください。高速バインディングアップデートが認証されているので、彼らは既存の結合に取って代わると、パケットはMNの新たに確認された場所にリダイレクトする必要があります。
All the ICMPv6 messages have a common Type specified in [4]. The messages are distinguished based on the Subtype field (see below). The values for the Subtypes are specified in Section 9. For all the ICMPv6 messages, the checksum is defined in [2].
すべてのICMPv6メッセージは、[4]で指定された一般的なタイプがあります。メッセージは、サブタイプフィールドに基づいて区別されている（下記参照）。サブタイプの値が全てのICMPv6メッセージのセクション9で指定され、チェックサムは、[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 6.4.3.
モバイルノードは、プロキシルータ広告のためのルータを促すためにプロキシ広告のためのルータ要請を送信します。すべてのリンク層アドレスオプションは6.4.3で定義されたフォーマットを有します。
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 ... +-+-+-+-+-+-+-+-+-+-+-+-
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|コード|チェックサム| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サブタイプ|予約|識別子| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |オプション... + - + - + - + - + - + - + - + - + - + - + - + -
Figure 4: Router Solicitation for Proxy (RtSolPr) Message
図4：プロキシ（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.
目的地は、アクセスルータまたはすべてのルータマルチキャストアドレスのアドレス。
Hop Limit 255. See RFC 2461.
リミット255を参照してくださいRFC 2461をホップ。
Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. See RFC 2402 [5].
認証ヘッダーIP認証ヘッダのセキュリティアソシエーションが送信者と宛先アドレスの間に存在する場合、送信者はこのヘッダーを含むべきです。 RFC 2402 [5]を参照してください。
ICMP Fields:
ICMPフィールド：
Type The Experimental Mobility Protocol Type. See [4].
実験モビリティプロトコルタイプを入力します。 [4]を参照してください。
Code 0
コード0
Checksum The ICMPv6 checksum.
チェックサムザ・ICMPv6のチェックサム。
Subtype 2
サブタイプ2
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:
有効なオプション：
Source Link-Layer Address When known, the Link-Layer Address of the sender SHOULD be included using the Link-Layer Address option. See the LLA option format below.
ソースリンク層アドレスすると知られているが、送信者のリンク層アドレスは、リンク層アドレスオプションを使用して含まれるべきです。以下LLAオプションのフォーマットを参照してください。
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 with all bits set to zero.
新しいアクセスポイントのリンク層は、MNが広告ルーティング情報を要求するためのアクセスポイントのリンク層アドレスまたは識別アドレス。これは、すべてのRtSolPrをメッセージに含まれなければなりません。以上のようなアドレスまたは識別子が存在することができます。また、このフィールドはゼロに設定されたすべてのビットがワイルドカードアドレスにすることができます。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options that they do not recognize and continue processing the rest of the message.
このプロトコルの将来のバージョンでは、新しいオプションタイプを定義することもできます。受信機は、静かに彼らが認識し、メッセージの残りの部分の処理を継続していない任意のオプションを無視しなければなりません。
Including the source LLA option allows the receiver to record the sender's L2 address so that neighbor discovery can be avoided when the receiver needs to send packets back to the sender (of the RtSolPr message).
ソースLLAオプションを含めると、受信機は（RtSolPrをメッセージの）送信者に戻ってパケットを送信する必要があるときにその近隣探索を避けることができるので、受信機は、送信者のL2アドレスを記録することができます。
When a wildcard is used for a New Access Point LLA, no other New Access Point LLA options must be present.
ワイルドカードは、新しいアクセスポイントLLAのために使用されている場合は、他の新しいアクセスポイントLLAオプションは存在してはなりません。
A Proxy Router Advertisement (PrRtAdv) message should be received by the MN in response to a RtSolPr. If such a message is not received in a timely manner (no less than twice the typical round trip time (RTT) over the access link or 100 milliseconds if RTT is not known), it SHOULD resend the RtSolPr message. Subsequent retransmissions can be up to RTSOLPR_RETRIES, but MUST use an exponential backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled prior to each instance of retransmission. If Proxy Router Advertisement is not received by the time the MN disconnects from the PAR, the MN SHOULD send an FBU immediately after configuring a new CoA.
プロキシルータ広告（代理ルータ広告）メッセージは、RtSolPrをに応答してMNによって受信されるべきです。 （RTTが知られていない場合は、アクセスリンクまたは100ミリ秒以上の2倍以上、典型的な往復時間（RTT））このようなメッセージがタイムリーに受信されない場合は、RtSolPrをメッセージを再送信する必要があります。後続の再送信はRTSOLPR_RETRIESまでとすることができるが、タイムアウト期間（すなわち、2xRTTまたは100ミリ秒）が前の再送の各インスタンスに倍増された指数バックオフを使用しなければなりません。プロキシルータアドバタイズメントは、MNがPARから切断時までに受信されない場合、MNは、すぐに新しいCoAを設定した後FBUを送るべきです。
When RtSolPr messages are sent more than once, they MUST be rate limited with MAX_RTSOLPR_RATE per second. During each use of a RtSolPr, exponential backoff is used for retransmissions.
RtSolPrをメッセージが複数回送信されると、彼らは毎秒MAX_RTSOLPR_RATEにレート制限されなければなりません。 RtSolPrをそれぞれの使用時には、指数バックオフは、再送信のために使用されています。
Access routers send Proxy Router Advertisement messages gratuitously if the handover is network-initiated or as a response to a RtSolPr message from an MN, providing the Link-Layer Address, IP address, and subnet prefixes of neighboring routers. All the Link-Layer Address options have the format defined in Section 6.4.3.
ハンドオーバがネットワーク開始または隣接ルータのリンク層アドレス、IPアドレス、およびサブネットプレフィックスを提供するMNからRtSolPrをメッセージへの応答としてある場合は、アクセスルータは、無償プロキシルータ通知メッセージを送信します。すべてのリンク層アドレスオプションは、6.4.3項で定義されたフォーマットを有します。
IP Fields:
IPフィールド：
Source Address MUST be the Link-Local Address assigned to the interface from which this message is sent.
送信元アドレスは、このメッセージが送られるインタフェースに割り当てられたリンクローカルアドレスでなければなりません。
Destination Address The Source Address of an invoking Router Solicitation for a Proxy Advertisement or the address of the node the Access Router is instructing to handover.
目的地は、プロキシ広告のための呼び出しルーター要請やアクセスルータがハンドオーバするように指示されたノードのアドレスの送信元アドレス。
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 ... +-+-+-+-+-+-+-+-+-+-+-+-
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|コード|チェックサム| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サブタイプ|予約|識別子| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |オプション... + - + - + - + - + - + - + - + - + - + - + - + -
Figure 5: Proxy Router Advertisement (PrRtAdv) Message
図5：プロキシルータアドバタイズメント（代理ルータ広告）メッセージ
Hop Limit 255. See RFC 2461 [6].
ホップリミット255を参照のRFC 2461 [6]。
Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, the sender SHOULD include this header. See RFC 2402 [5].
認証ヘッダーIP認証ヘッダのセキュリティアソシエーションが送信者と宛先アドレスの間に存在する場合、送信者はこのヘッダーを含むべきです。 RFC 2402 [5]を参照してください。
ICMP Fields:
ICMPフィールド：
Type The Experimental Mobility Protocol Type. See RFC 4065 [4].
実験モビリティプロトコルタイプを入力します。 RFC 4065 [4]を参照してください。
Code 0, 1, 2, 3 or 4. See below.
コード0、1、2、3または4以下を参照してください。
Checksum The ICMPv6 checksum.
チェックサムザ・ICMPv6のチェックサム。
Subtype 3
サブタイプ3
Reserved MUST be set to zero by the sender and ignored by the receiver.
予約は、送信者によってゼロに設定し、受信機で無視しなければなりません。
Identifier Copied from the Router Solicitation for Proxy Advertisement or set to Zero if unsolicited.
識別子は、プロキシ広告のためのルーター要請からコピーまたは迷惑場合は、ゼロに設定します。
Valid Options in the following order:
次の順序で有効なオプション：
Source Link-Layer Address When known, the Link-Layer Address of the sender SHOULD be included using the Link-Layer Address option. See the LLA option format below.
ソースリンク層アドレスすると知られているが、送信者のリンク層アドレスは、リンク層アドレスオプションを使用して含まれるべきです。以下LLAオプションのフォーマットを参照してください。
New Access Point Link-Layer Address The Link-Layer Address or identification of the access point is copied from the RtSolPr message. This option MUST be present.
新しいアクセスポイントのリンク層アドレスリンク層アドレスまたはアクセスポイントの識別は、RtSolPrをメッセージからコピーされます。このオプションが存在しなければなりません。
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. Specifies the prefix of the Access Router for which the message is proxied and is used for address auto-configuration. This option MUST be included when Code is 0 or 1. However, when this prefix is the same as that used in the New Router's IP Address option (above), the Prefix Information option need not be present.
新しいルータのプレフィックス情報オプション。メッセージはプロキシされ、アドレスの自動設定に使用されているアクセスルータのプレフィックスを指定します。このプレフィックスは、プレフィックス情報オプションが存在する必要がない新しいルータのIPアドレスオプション（上記）で使用したものと同じであるとき、コードが、しかし、0または1である場合は、このオプションを含まなければなりません。
New CoA Option MAY be present when a PrRtAdv is sent unsolicited. PAR MAY compute a new CoA using NAR's prefix information and the MN's L2 address, or by any other means.
代理ルータ広告が迷惑送信されたときに、新たなCoAオプションが存在してもよいです。 PARは、NARのプレフィックス情報とMNのL2アドレスを使用して新しいCoAを計算し、または任意の他の手段によってもよい（MAY）。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
このプロトコルの将来のバージョンでは、新しいオプションタイプを定義することもできます。受信機は、静かに彼らが認識し、メッセージの処理を継続していない任意のオプションを無視しなければなりません。
Currently, Code values 0, 1, 2, 3 and 4 are defined.
現在、コードは0、1、2、3及び4が定義されている値。
A Proxy Router Advertisement with Code 0 means that the MN should use the [AP-ID, AR-Info] tuple (present in the options above) for movement detection and NCoA formulation. In this case, the Option-Code field in the New Access Point LLA option is 1, reflecting the LLA of the access point for which the rest of the options are related. Multiple tuples may be present.
コード0でプロキシルータ広告は、MNは、移動検出及びNCOA製剤について（上記のオプションに存在する）[AP-ID、AR-INFO]タプルを使用する必要があることを意味します。この場合は、新しいアクセスポイントLLAオプションでオプション-Codeフィールドは、オプションの残りの部分は関連しているアクセスポイントのLLAを反映し、1です。複数のタプルが存在してもよいです。
A Proxy Router Advertisement with Code 1 means that the message is sent unsolicited. If a New CoA option is present following the New Router Prefix Information option, 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; see Section 3.3. The Option-Code field in the New Access Point LLA option (see below) in this case is 1 reflecting the LLA of the access point for which the rest of the options are related.
コード1と代理ルータ広告メッセージが迷惑送信されることを意味します。新しいCoAオプションは、新しいルータのプレフィックス情報オプション以下存在する場合、MNは、付属のNCOAを使用すると、すぐにFBUを送信したり、他のサービスを失うことに立つべき。このメッセージは、ネットワーク開始ハンドオーバトリガとして働きます。 3.3節を参照してください。この場合、新しいアクセスポイントLLAオプションでオプション-Codeフィールドは、（下記参照）のオプションの残りの部分は関連しているアクセスポイントのLLAを反映して1です。
A Proxy Router Advertisement with Code 2 means that no new router information is present. Each New Access Point LLA option contains an Option-Code value (described below) that indicates a specific outcome.
コード2でプロキシルータ通知には新しいルータ情報が存在しないことを意味しています。それぞれの新しいアクセスポイントLLAオプションは、特定の結果を示している（後述）オプション・コード値が含まれています。
- When the Option-Code field in the New Access Point LLA option is 5, handover to that access point does not require a change of CoA. No other options are required in this case.
- 新しいアクセスポイントLLAオプションでオプション-Codeフィールドが5であるときは、そのアクセスポイントへのハンドオーバがCoAを変更する必要はありません。他のオプションは、この場合には必要ありません。
- When the Option-Code field in the New Access Point LLA option is 6, the PAR is not aware of the Prefix Information requested. The MN SHOULD attempt to send an FBU as soon as it regains connectivity with the NAR. No other options are required in this case.
- 新しいアクセスポイントLLAオプションでオプション-Codeフィールドが6である場合には、PARは、プレフィックス情報が要求を認識していません。 MNは、NARとの接続が回復するとすぐにFBUを送信しようとすべきです。他のオプションは、この場合には必要ありません。
- When the Option-Code field in the New Access Point LLA option is 7, it means that the NAR does not support fast handover. The MN MUST stop fast handover protocol operations. No other options are required in this case.
- 新しいアクセスポイントLLAオプションでオプション-Codeフィールドが7である場合は、NARは、高速ハンドオーバをサポートしていないことを意味します。 MNは、高速ハンドオーバプロトコルの動作を停止しなければなりません。他のオプションは、この場合には必要ありません。
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 field values (defined above including a value of 1) distinguish different outcomes for individual access points.
コード3とプロキシルータアドバタイズメントは新しいルータ情報が要求されたアクセスポイントのサブセットのためにのみ存在することを意味します。 （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 any `n' [Access Point Identifier, Link-Layer Address option, Prefix Information Option] tuples corresponding to the PAR's neighborhood.
ワイルドカードAP識別子がRtSolPrをメッセージに供給されると、代理ルータ広告メッセージは、[アクセスポイント識別子、リンク層アドレスオプション、プレフィックス情報オプション] PARの近所に対応するタプルを任意の `N」を含める必要があります。
The Handover Initiate (HI) is an ICMPv6 message sent by an Access Router (typically PAR) to another Access Router (typically NAR) to initiate the process of a MN's handover.
ハンドオーバ開始（HI）MNのハンドオーバ処理を開始するために別のアクセスルータ（典型的にはNAR）へのアクセスルータ（典型的にはPAR）によって送信されたICMPv6メッセージです。
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 ... +-+-+-+-+-+-+-+-+-+-+-+-
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|コード|チェックサム| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サブタイプ| S | U |予約|識別子| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |オプション... + - + - + - + - + - + - + - + - + - + - + - + -
Figure 6: Handover Initiate (HI) Message
図6：ハンドオーバ開始（HI）メッセージ
IP Fields:
IPフィールド：
Source Address The IP address of the PAR.
ソースは、PARのIPアドレス。
Destination Address The IP address of the NAR.
目的地は、NARのIPアドレス。
Hop Limit 255. See RFC 2461 [6].
ホップリミット255を参照のRFC 2461 [6]。
Authentication Header The authentication header MUST be used when this message is sent. See RFC 2402 [5].
このメッセージが送信されると、認証ヘッダは、認証ヘッダを使用しなければなりません。 RFC 2402 [5]を参照してください。
ICMP Fields:
ICMPフィールド：
Type The Experimental Mobility Protocol Type. See RFC 4065 [4].
実験モビリティプロトコルタイプを入力します。 RFC 4065 [4]を参照してください。
Code 0 or 1. See below
コード0または1以下を参照してください
Checksum The ICMPv6 checksum.
チェックサムザ・ICMPv6のチェックサム。
Subtype 4
サブタイプ4
S flag 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 flag Buffer flag. When set, the destination SHOULD buffer any packets moving toward 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 SHOULD be included so that a host route can be established if necessary.
アドレスの前のケア発信側ルータに接続しながら、MNが使用するIPアドレス。必要に応じて、ホストルートが確立できるように、このオプションが含まれるべきです。
New Care of Address The IP address the MN wishes to use when connected to the destination. When the `S' bit is set, the NAR MAY assign this address.
住所の新しいケアIPは、先に接続したときにMNが使用したい取り組みます。 `S」ビットが設定されている場合、NARは、このアドレスを割り当てることができます。
The PAR uses a Code value of 0 when it processes an FBU with PCoA as a source IP address. The PAR uses a Code value of 1 when it processes an FBU whose source IP address is not PCoA.
それは、ソースIPアドレスとしてPCOAとFBUを処理するときPAR 0のコード値を使用します。それは、ソースIPアドレスPCOAないFBUを処理するときPARは、1のコード値を使用します。
If a Handover Acknowledge (HAck) message is not received as a response in a short time period (no less than twice the typical RTT between source and destination, or 100 milliseconds if RTT is not known), the Handover Initiate SHOULD be resent. Subsequent retransmissions can be up to HI_RETRIES, but MUST use exponential backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled during each instance of retransmission.
ハンドオーバ（RTTが既知でない場合、送信元と宛先、または100ミリ秒の間には2倍未満、典型的なRTT）（上記ハンドオフ）メッセージが短時間で応答として受信されていない肯定応答場合、ハンドオーバは再送であるべきである開始します。後続の再送信はHI_RETRIESまでとすることができるが、タイムアウト期間（すなわち、2xRTTまたは100ミリ秒）は、再送の各インスタンス中に倍増された指数バックオフを使用しなければなりません。
The Handover Acknowledgment message is a new ICMPv6 message that MUST be sent (typically by NAR to PAR) as a reply to the Handover Initiate message.
ハンドオーバ肯定応答メッセージは、ハンドオーバに対する応答として（PAR典型的にNARによって）送信されたメッセージを開始しなければならない新しいICMPv6メッセージです。
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 ... +-+-+-+-+-+-+-+-+-+-+-+-
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|コード|チェックサム| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サブタイプ|予約|識別子| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |オプション... + - + - + - + - + - + - + - + - + - + - + - + -
Figure 7: Handover Acknowledge (HAck) Message
図7：ハンドオーバ肯定応答（上記ハンドオフ）メッセージ
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.
ハンドオーバの送信元アドレスからコピーされた宛先アドレスは、このメッセージが応答されたメッセージを開始します。
Hop Limit 255. See RFC 2461 [6].
ホップリミット255を参照のRFC 2461 [6]。
Authentication Header The authentication header MUST be used when this message is sent. See RFC 2402 [5].
このメッセージが送信されると、認証ヘッダは、認証ヘッダを使用しなければなりません。 RFC 2402 [5]を参照してください。
ICMP Fields:
ICMPフィールド：
Type The Experimental Mobility Protocol Type. See RFC 4065 [4].
実験モビリティプロトコルタイプを入力します。 RFC 4065 [4]を参照してください。
Code 0: Handover Accepted, NCoA valid 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 (used in Assigned addressing) 128: Handover Not Accepted, reason unspecified 129: Administratively prohibited 130: Insufficient resources
コード0：ハンドオーバ承認、有効NCOA 1：ハンドオーバ受け入れ、NCOAが有効でない2：ハンドオーバ承認、使用3 NCOA：（割り当てアドレッシングで使用される）を割り当てハンドオーバ受け入れ、NCOA 4：割り当てられていないハンドオーバ受け入れ、NCOAは、（割り当てアドレッシングに使用）128：ハンドオーバ不可、不特定の理由129：管理上130を禁止：リソースが不足し
Checksum The ICMPv6 checksum.
チェックサムザ・ICMPv6のチェックサム。
Subtype 5
サブタイプ5
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 to which this message is a response.
ハンドオーバに対応するフィールドからコピーされた識別子は、このメッセージが応答されたメッセージを開始します。
Valid Options:
有効なオプション：
New Care of Address If the S flag in the Handover Initiate 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 the `S' bit is not set, e.g., Code 2 above.
住所の新しいケアハンドオーバ中のSフラグは、メッセージが設定されて開始した場合、このオプションは、このルータに接続したときにMNが使用するNCOAを提供するために使用されなければなりません。このオプションは 'S」ビットは、例えば、コード2上、設定されていない場合でも、含まれるかもしれません。
Upon receiving an HI message, the NAR MUST respond with a Handover Acknowledge message. If the `S' flag is set in the HI message, the NAR SHOULD include the New Care of Address option and a Code 3.
HIメッセージを受信すると、NARは、メッセージを確認し、ハンドオーバで応じなければなりません。 `S」フラグはHIメッセージに設定されている場合は、NARは、アドレスオプションとコード3の新しいケアを含むべきです。
The NAR MAY provide support for PCoA (instead of accepting or assigning NCoA), establish a host route entry for PCoA, and set up a tunnel to the PAR to forward MN's packets sent with PCoA as a source IP address. This host route entry SHOULD be used to forward packets once the NAR detects that the particular MN is attached to its link.
NARは、（代わりNCOAを受け入れる又は割り当てる）PCOAをサポートするPCOAためのホストルートエントリを確立し、送信元IPアドレスとしてPCOAで送信され、MNのパケットを転送するためにPARにトンネルを設定してもよいです。 NARは、特定のMNは、そのリンクに接続されていることを検出すると、このホストルートエントリがパケットを転送するために使用されるべきです。
When responding to an HI message containing a Code value 1, the Code values 1, 2, and 4 in the HAck message are not relevant.
コード値1を含むHIメッセージに応答するとき、コードはハッキングメッセージ1、2、および4は関連しない値です。
Finally, the new access router can always refuse handover, in which case it should indicate the reason in one of the available Code values.
最後に、新しいアクセスルータは、常にそれが利用可能なコード値のいずれかに理由を示す必要があり、その場合には、ハンドオーバを拒否することができます。
Mobile IPv6 uses a new IPv6 header type called Mobility Header [3]. The Fast Binding Update, Fast Binding Acknowledgment, and Fast Neighbor Advertisement messages use the Mobility Header.
モバイルIPv6 [3]モビリティヘッダと呼ばれる新しいIPv6ヘッダーのタイプを使用します。高速バインディングアップデートは、高速謝辞をバインド、および高速近隣広告メッセージは、モビリティヘッダを使用しています。
The Fast Binding Update message is identical to the Mobile IPv6 Binding Update (BU) message. However, the processing rules are slightly different.
ファストバインディングアップデートメッセージは、モバイルIPv6バインディング更新（BU）メッセージと同一です。しかし、処理ルールは若干異なります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |シーケンス＃| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | A | H | L | K |予約|生涯| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | 。 。 。モビリティオプション。 。 。 | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 8: Fast Binding Update (FBU) Message
図8：高速バインディング更新（FBU）メッセージ
IP fields:
IPフィールド：
Source Address The PCoA or NCoA
ソースはPCOAまたはNCOAアドレス
Destination Address The IP address of the Previous Access Router
目的地は、前のアクセスルータのIPアドレス
A flag MUST be set to one to request that PAR send a Fast Binding Acknowledgment message.
フラグは、PARファストバインディング確認メッセージを送信することを要求するために1に設定しなければなりません。
H flag MUST be set to one. See RFC 3775 [3].
Hフラグは1に設定されなければなりません。 RFC 3775 [3]を参照してください。
L flag See RFC 3775 [3].
Lフラグは、RFC 3775 [3]を参照してください。
K flag See RFC 3775 [3].
Kフラグは、RFC 3775 [3]を参照してください。
Reserved This field is unused. MUST be set zero.
予約済みこのフィールドは未使用です。ゼロを設定しなければなりません。
Sequence Number See RFC 3775 [3].
シーケンス番号を参照してくださいRFC 3775 [3]。
Lifetime See RFC 3775 [3].
寿命はRFC 3775 [3]を参照してください。
Mobility Options MUST contain an alternate CoA option set to the NCoA when an FBU is sent from PAR's link.
FBUをPARのリンクから送信されたときモビリティオプションはNCOAに設定され、代替CoAオプションを含まなければなりません。
The MN sends an FBU message any time after receiving a PrRtAdv message. If the MN moves prior to receiving a PrRtAdv message, it SHOULD send an FBU to the PAR after configuring NCoA on the NAR according to Neighbor Discovery and IPv6 Address Configuration protocols.
MNは、代理ルータ広告メッセージを受信した後FBUメッセージをいつでも送信します。 MNは、代理ルータ広告メッセージを受信する前に移動した場合、それは近隣探索およびIPv6アドレスの設定プロトコルに従ってNARのNCOAを設定した後でPARにFBUを送るべきです。
The source IP address is PCoA when the FBU is sent from PAR's link, and the source IP address is NCoA when sent from NAR's link. When the FBU is sent from NAR's link, it SHOULD be encapsulated within an FNA.
FBUをPARのリンクから送信され、NARのリンクから送信されたときに送信元IPアドレスがNCOAでされたときに送信元IPアドレスがPCOAです。 FBUは、NARのリンクから送信されると、それはFNA内にカプセル化されるべきです。
The FBU MUST also include the Home Address Option, and the Home Address is PCoA. An FBU message MUST be protected so that PAR is able to determine that the FBU message is sent by a genuine MN.
FBUはまた、ホームアドレスオプションを含まなければならない、とホームアドレスはPCOAです。 PARは、FBUメッセージが本物MNによって送信されることを決定することができるようにFBUメッセージを保護しなければなりません。
The Fast Binding Acknowledgment message is sent by the PAR to acknowledge receipt of a Fast Binding Update message in which the 'A' bit is set. The Fast Binding Acknowledgment message SHOULD NOT be sent to the MN before the PAR receives a HAck message from the NAR. The Fast Binding Acknowledgment MAY also be sent to the MN on the old link.
高速Binding Acknowledgementメッセージは「」ビットが設定された高速バインディング更新メッセージの受信を確認するためにPARによって送信されます。 PARは、NARからハックメッセージを受信する前に速いBinding AcknowledgementメッセージをMNに送るべきではありません。高速結合確認も古いリンク上のMNに送ってもよいです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ステータス| K |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |シーケンス＃|生涯| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | 。 。 。モビリティオプション。 。 。 | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 9: Fast Binding Acknowledgment (FBack) Message
図9：ファストバインディング肯定応答（FBACK）メッセージ
IP fields:
IPフィールド：
Source Address The IP address of the Previous Access Router.
ソースは、前のアクセスルータのIPアドレス。
Destination Address
The NCoA
Status 8-bit unsigned integer indicating the disposition of the Fast Binding Update. Values of the Status field that are less than 128 indicate that the Binding Update was accepted by the receiving node. The following such Status values are currently defined:
ファストバインディングアップデートの配置を示すステータス8ビットの符号なし整数。 128未満のStatusフィールドの値は、結合更新が受信ノードによって受け入れられたことを示しています。以下、このようなステータス値は、現在定義されています。
0 Fast Binding Update accepted
1 Fast Binding Update accepted but NCoA is
invalid. Use NCoA supplied in "alternate" CoA
Values of the Status field that are greater than or equal to 128 indicate that the Binding Update was rejected by the receiving node. The following such Status values are currently defined:
128以上であるStatusフィールドの値は、結合更新が受信ノードによって拒否されたことを示しています。以下、このようなステータス値は、現在定義されています。
128 Reason unspecified 129 Administratively prohibited 130 Insufficient resources 131 Incorrect interface identifier length
128理由不特定129の管理上禁止130のリソース不足131不正インタフェース識別子の長さ
`K' flag See RFC 3775 [3].
'K」フラグは、RFC 3775 [3]を参照してください。
Reserved An unused field. MUST be set to zero.
未使用のフィールドを禁じます。ゼロに設定しなければなりません。
Sequence Number Copied from the FBU message for use by the MN in matching this acknowledgment with an outstanding FBU.
優れたFBUと、この確認応答をマッチングにMNが使用するためにFBUメッセージからコピーされたシーケンス番号。
Lifetime The granted lifetime in seconds for which the sender of this message will retain a binding for traffic redirection.
このメッセージの送信者がトラフィックリダイレクションのための結合を保持する対象の秒単位の寿命付与された寿命を。
Mobility Options MUST contain an "alternate" CoA if Status is 1.
ステータスが1であればモビリティオプションは、「代替」CoAを含まなければなりません。
A MN sends a Fast Neighbor Advertisement to announce itself to the NAR. When the Mobility Header Type is FNA, the Payload Proto field may be set to IPv6 to assist FBU encapsulation.
MNは、NARに自分自身を発表する高速近隣通知を送信します。モビリティヘッダタイプがFNAある場合は、ペイロードプロトフィールドがFBUカプセル化を支援するためのIPv6に設定することができます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +。 。 。モビリティオプション。 。 。 | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 10: Fast Neighbor Advertisement (FNA) Message
図10：高速近隣広告（FNA）メッセージ
IP fields:
IPフィールド：
Source Address NCoA
送信元アドレスNCOA
Destination Address NAR's IP Address
宛先アドレスNARのIPアドレス
Mobility Options MUST contain the Mobility Header Link-Layer Address of the MN in the MH-LLA option format. See Section 6.4.4.
モビリティオプションは、MH-LLAオプション形式のMNのモビリティヘッダリンク層アドレスを含まなければなりません。 6.4.4項を参照してください。
The MN sends a Fast Neighbor Advertisement to the NAR, as soon as it regains connectivity on the new link. Arriving or buffered packets can be immediately forwarded. If NAR is proxying NCoA, it creates a neighbor cache entry in REACHABLE state. If there is no entry, it creates one and sets it to REACHABLE. If there is an entry in the INCOMPLETE state without a Link-Layer Address, it sets it to
MNは、すぐにそれが新しいリンクに接続性を取り戻すよう、NARに高速近隣通知を送信します。到着またはバッファされたパケットは、直ちに転送することができます。 NARはNCOAをプロキシされている場合は、それが到達可能な状態にある近隣キャッシュエントリを作成します。エントリがない場合、1つを作成し、REACHABLEに設定します。リンク層アドレスのない不完全な状態でエントリがある場合は、それを設定し、
REACHABLE. During the process of creating a neighbor cache entry, NAR can also detect if NCoA is in use, thus avoiding address collisions. Since the FBU is encapsulated within the FNA when sent from NAR's link, NAR drops the FBU if it detects a collision.
REACHABLE。 NCOAは、このようにアドレスの衝突を回避、使用中の場合は近隣キャッシュエントリを作成する過程で、NARも検出することができます。 NARのリンクから送信されたときにFBUはFNA内にカプセル化されているので、それは衝突を検出した場合、NARはFBUをドロップ。
The combination of NCoA (present in source IP address) and the Link-Layer Address (present as a Mobility Option) SHOULD be used to distinguish the MN from other nodes.
NCOA（送信元IPアドレスに存在する）と（モビリティオプションとして存在する）リンク層アドレスの組み合わせは、他のノードからMNを識別するために使用されるべきです。
All the options are of the form shown in Figure 11.
すべてのオプションは、図11に示される形態のものです。
The Type values are defined from the Neighbor Discovery options space. The Length field is in units of 8 octets, except for the Mobility Header Link-Layer Address option, whose Length field is in units of octets in accordance with Section 6.2 in [3]. Option-Code provides additional information for each of the options (See individual options below).
タイプ値は、近隣探索オプション空間から定義されています。 Lengthフィールドは、長さフィールド[3]でセクション6.2に従ってオクテットの単位であるモビリティヘッダリンク層アドレスオプションを除き、8つのオクテットの単位です。オプションコード（以下個々のオプションを参照）の各オプションの追加情報を提供します。
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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ| Optionキーコード| | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜...〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 11: Option Format
図11：オプションのフォーマット
This option is sent in the Proxy Router Advertisement, the Handover Initiate, and Handover Acknowledge messages.
このオプションは、ハンドオーバが開始し、ハンドオーバがメッセージを確認し、プロキシルータアドバタイズメントに送信されます。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ| Optionキーコード|プレフィックス長| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | + + | | + IPv6アドレス+ | | + + | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 12: IPv6 Address Option
図12：IPv6のアドレスオプション
Type 17
タイプ17
Length The size of this option in 8 octets including the Type, Option-Code, and Length fields.
タイプ、オプション・コード、および長さフィールドを含む8つのオクテットの長さは、このオプションのサイズ。
Option-Code 1 Old Care-of Address 2 New Care-of Address 3 NAR's IP address
Optionキーコード1旧気付アドレス2新気付アドレス3 NARのIPアドレス
Prefix Length The Length of the IPv6 Address Prefix.
プレフィックス長IPv6アドレスのプレフィックスの長さ。
Reserved MUST be set to zero by the sender and MUST be ignored by the receiver.
予約は、送信者によってゼロに設定しなければならなくて、受信機で無視しなければなりません。
IPv6 Address The IP address for the unit defined by the Type field.
Typeフィールドで定義されたユニットのIPアドレスをIPv6アドレス。
This option is sent in the PrRtAdv message to provide the prefix information valid on the NAR.
このオプションは、NARの有効なプレフィックス情報を提供するために、代理ルータ広告メッセージで送信されます。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ| Optionキーコード|プレフィックス長| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | + + | | +プレフィックス+ | | + + | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 13: New Router Prefix Information Option
図13：新しいルータのプレフィックス情報オプション
Type 18
タイプ18
Length The size of this option in 8 octets including the Type, Option-Code, and Length fields.
タイプ、オプション・コード、および長さフィールドを含む8つのオクテットの長さは、このオプションのサイズ。
Option-Code 0
Optionキーコード0
Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128.
プレフィックス長8ビットの符号なし整数。有効な接頭辞の一流のビット数。値は0から128の範囲です。
Reserved MUST be set to zero by the sender and MUST be ignored by the receiver.
予約は、送信者によってゼロに設定しなければならなくて、受信機で無視しなければなりません。
Prefix An IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver.
IPアドレスまたはIPアドレスのプレフィックスを付けます。プレフィックス長フィールドはプレフィックスに有効な先行ビットの数が含まれています。プレフィックス長の後にプレフィックスのビットは予約されており、送信者によってゼロに初期化し、受信機で無視しなければなりません。
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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ| Optionキーコード| LLA ... + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 14: Link-Layer Address Option
図14：リンク層アドレスオプション
Type 19
タイプ19
Length The size of this option in 8 octets including the Type, Option-Code, and Length fields.
タイプ、オプション・コード、および長さフィールドを含む8つのオクテットの長さは、このオプションのサイズ。
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 (i.e., Proxied Originator) 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
（すなわち、プロキシさオリジネーター）NARの4リンク層アドレスのMN 3リンク層アドレスの新しいアクセスポイント2リンク層アドレスのすべての近くのアクセスポイント1リンク層アドレスのためのオプション・コード0ワイルドカード要求する決議LLAによって同定RtSolPrを又は代理ルータ広告メッセージ5アクセスポイントのソースは、7つのなし高速ハンドオーバにより識別されたアクセスポイントで利用可能なサポートしないLLAによって識別されたアクセスポイントで利用可能なルータ6なしプレフィックス情報の現在のインタフェースに属しLLA
LLA The variable length Link-Layer Address.
LLA可変長リンク層アドレス。
Depending on the size of the individual LLA option, appropriate padding MUST be used to ensure that the entire option size is a multiple of 8 octets.
個々のLLAオプションのサイズに応じて、適切なパディングはオプション全体のサイズは8つのオクテットの倍数であることを確認するために使用しなければなりません。
The New Access Point Link-Layer Address contains the Link-Layer Address of the access point for which handover is about to be attempted. This is used in the Router Solicitation for the Proxy Advertisement message.
新しいアクセスポイントのリンク層アドレスは、ハンドオーバが試みされようとしているアクセスポイントのリンク層アドレスが含まれています。これは、プロキシ広告メッセージのルータ要請に使用されています。
The MN Link-Layer Address option contains the Link-Layer Address of an MN. It is used in the Handover Initiate message.
MNリンク層アドレスオプションは、MNのリンク層アドレスが含まれています。これは、メッセージを開始するハンドオーバーに使用されています。
The NAR (i.e., Proxied Originator) Link-Layer Address option contains the Link-Layer Address of the Access Router to which the Proxy Router Solicitation message refers.
NAR（すなわち、プロキシさオリジネータ）リンク層アドレス・オプションは、プロキシルータ要請メッセージが参照するアクセス・ルータのリンク層アドレスを含んでいます。
This option is identical to the LLA option, but is carried in the Mobility Header messages (i.e., FNA). In the future, other Mobility Header messages may also make use of this option. For instance, including this option in FBU allows PAR to obtain the MN's LLA readily. The format of the option when the LLA is 6 bytes is shown in Figure 15. When the LLA size is different, the option MUST be aligned appropriately. See Section 6.2 in [3].
このオプションは、LLAオプションと同じですが、モビリティヘッダのメッセージ（すなわち、FNA）で行われます。将来的には、他のモビリティヘッダのメッセージも、このオプションを利用することができます。例えば、FBUでこのオプションを含めてPARが容易にMNのLLAを得ることができます。 LLAは6バイトであり、オプションのフォーマットはLLAサイズが異なる場合、オプションを適切に位置合わせされなければならない図15に示されています。 [3]でセクション6.2を参照してください。
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 | Pad0=0 | LLA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LLA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Optionキーコード| PAD0 = 0 | LLA | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | LLA | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 15: Mobility Header Link-Layer Address Option
図15：モビリティヘッダリンク層アドレスオプション
Type 7
タイプ7
Length The size of this option in octets not including the Type, Length, and Option-Code fields.
タイプ、長さ、およびオプション・コードフィールドを含まないオクテットの長さは、このオプションのサイズ。
Option-Code 2 Link-Layer Address of the MN
MNのオプション-コード2リンク層アドレス
LLA The variable length Link-Layer Address.
LLA可変長リンク層アドレス。
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 | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ| Optionキーコード|ステータス| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Figure 16: Neighbor Advertisement Acknowledgment Option
図16：近隣広告謝辞オプション
Type 20
タイプ20
Length 8-bit unsigned integer. Length of the option, in 8 octets. The length is 1 when NCoA is not supplied. The length is 3 when NCoA is supplied (immediately following the Reserved field).
長さ8ビットの符号なし整数。 8つのオクテット内のオプションの長さ。 NCOAが供給されないときの長さは1です。 NCOAを（直ちに予約フィールド以下）が供給されたときに長さが3です。
Option-Code 0
Optionキーコード0
Status 8-bit unsigned integer indicating the disposition of the Fast Neighbor Advertisement message. The following Status values are currently defined:
高速近隣広告メッセージの配置を示すステータス8ビットの符号なし整数。以下のステータス値が現在定義されています：
1 The New CoA is invalid.
2 The New CoA is invalid; use the supplied CoA.
The New CoA MUST be present following the
Reserved field.
128 Link Layer Address unrecognized.
Reserved MUST be set to zero by the sender and MUST be ignored by the receiver.
予約は、送信者によってゼロに設定しなければならなくて、受信機で無視しなければなりません。
The NAR responds to the FNA with the NAACK option to notify the MN to use a different NCoA if there is address collision. If the NCoA is invalid, the Router Advertisement MUST use the NCoA as the destination address but use the L2 address present in the FNA. The MN SHOULD use the NCoA if it is supplied with the NAACK option. If the NAACK indicates that the Link-Layer Address is unrecognized, the MN MUST NOT use the NCoA or PCoA and SHOULD start the process of acquiring an NCoA at the NAR immediately.
NARは、アドレス衝突がある場合は、別のNCOAを使用するには、MNに通知するNAACKオプションでFNAに応答します。 NCOAが無効である場合、ルータ通知は、宛先アドレスとしてNCOAを使用していますが、FNAにL2アドレス存在を使用しなければなりません。それはNAACKオプションで提供されている場合は、MN NCOAを使用すべきです。 NAACKは、リンク層アドレスが認識されないことを示している場合、MNはNCOAやPCOAを使用してはならないとすぐにNARでNCOAを取得する処理を開始する必要があります。
New option types may be defined in the future.
新しいオプションの種類は、将来的に定義されてもよいです。
Parameter Name Default Value Definition
------------------- ---------------------- -------
RTSOLPR_RETRIES 3 Section 6.1.1
MAX_RTSOLPR_RATE 3 Section 6.1.1
FBU_RETRIES 3 Section 4
PROXY_ND_LIFETIME 1.5 seconds Section 6.2.2
HI_RETRIES 3 Section 6.2.1
The following security vulnerabilities are identified, and suggested solutions are mentioned.
以下のセキュリティの脆弱性を特定し、解決策が記載されていることが示唆されています。
1. Insecure FBU: In this case, packets meant for one address could be stolen, or redirected to some unsuspecting node. This concern is the same as that in an MN and Home Agent relationship.
1.安全でないFBU：この場合、一つのアドレスのためのものパケットが盗まれる可能性があり、または何らかの疑いを持たないノードにリダイレクト。この懸念は、MNとホームエージェントとの関係と同じです。
Hence, the PAR MUST ensure that the FBU packet arrived from a node that legitimately owns the PCoA. The access router and its hosts may use any available mechanism to establish a security association that MUST be used to secure FBU. The current version of this protocol does not specify how this security association is established. However, future work may specify this security association establishment.
したがって、PARはFBUパケットが正当PCOAを所有するノードから到着したことを確認しなければなりません。アクセスルータとそのホストがFBUを保護するために使用されなければならないセキュリティアソシエーションを確立するために使用可能な任意のメカニズムを使用することができます。このプロトコルの現在のバージョンは、このセキュリティアソシエーションが確立される方法を指定しません。しかし、今後の作業は、このセキュリティアソシエーションの確立を指定することもできます。
If an access router can ensure that the source IP address in an arriving packet could only have originated from the node whose Link-Layer Address is in the router's neighbor cache, then a bogus node cannot use a victim's IP address for malicious redirection of traffic. Such an operation is recommended at least on neighbor discovery messages including the RtSolPr message.
アクセスルータは、到着したパケットの送信元IPアドレスのみがそのリンク層アドレスルーターの近隣キャッシュ内にあるノードから発信された可能性があることを保証することができた場合は、偽のノードは、トラフィックの悪質なリダイレクトのために、被害者のIPアドレスを使用することはできません。このような動作はRtSolPrをメッセージを含む近隣探索メッセージに少なくとも推奨されます。
2. Secure FBU, malicious or inadvertent redirection: In this case, the FBU is secured, but the target of binding happens to be an unsuspecting node due to inadvertent operation or malicious intent. This vulnerability can lead to an MN with a genuine security association with its access router redirecting traffic to an incorrect address.
2.セキュアFBU、悪意のあるまたは不注意なリダイレクション：この場合、FBUが確保されるが、結合の標的起因誤操作や悪意に疑いを持たないノードであることを起こります。この脆弱性は、そのアクセスルータが誤ったアドレスへのトラフィックをリダイレクトすると本物のセキュリティアソシエーションをMNにつながることができます。
However, the target of malicious traffic redirection is limited to an interface on an access router with which the PAR has a security association. The PAR MUST verify that the NCoA to which PCoA is being bound actually belongs to NAR's prefix. To do this, HI and HAck message exchanges are to be used. When NAR accepts NCoA in HI (with Code = 0), it proxies NCoA so that any arriving packets are not sent on the link until the MN attaches and announces itself through FNA. Therefore, any inadvertent or malicious redirection to a host is avoided. It is still possible to jam NAR's buffer with redirected traffic. However, since NAR's handover state corresponding to NCoA has a finite (and short) lifetime corresponding to a small multiple of anticipated handover latency, the extent of this vulnerability is arguably small.
しかし、悪意のあるトラフィックのリダイレクトのターゲットは、PARは、セキュリティ・アソシエーションを持っているアクセスルータ上のインターフェイスに限定されています。 PARはPCOAがバインドされているためにNCOAが実際にNARのプレフィックスに属していることを確かめなければなりません。これを行うには、HI及びHAck処理メッセージ交換が使用されるべきです。 NARは（コード= 0と）HIでNCOAを受け入れるとMNがアタッチして、FNAを通じて自分自身を発表するまで、すべての到着パケットがリンク上で送信されないように、それはNCOAをプロキシ。そのため、ホストへの不注意や悪意のあるリダイレクトが回避されます。リダイレクトされたトラフィックとNARのバッファをジャムすることも可能です。 NCOAに対応NARのハンドオーバ状態が予想ハンドオーバ待ち時間の小さな倍数に対応する有限の（及び短い）寿命を有しているので、この脆弱性の程度はおそらく小さいです。
3. Sending an FBU from NAR's link: A malicious node may send an FBU from NAR's link providing an unsuspecting node's address as NCoA. Since the FBU is encapsulated in the FNA, NAR should detect the collision with an address in use when processing the FNA, and then drop the FBU. When NAR is unable to detect address collisions, there is a vulnerability that redirection can affect an unsuspecting node.
3. NARのリンクからFBUを送信する：悪意のあるノードはNCOAとして疑うことを知らないノードのアドレスを提供するNARのリンクからFBUを送信することができます。 FBUはFNA中に封入されているので、NARは、FNAを処理するときに使用中のアドレスとの衝突を検出し、その後、FBUをドロップすべきです。 NARは、アドレス衝突を検出することができない場合は、リダイレクトが疑うことを知らないノードに影響を与えることができる脆弱性があります。
This document defines four new experimental ICMPv6 messages that use the Experimental Mobility Protocol ICMPv6 format [4]. These four new Subtype value assignments out of the Experimental Mobility Protocol Subtype Registry [4] have been assigned as follows:
この文書では、[4]実験モビリティプロトコルICMPv6の形式を使用4つの新しい実験ICMPv6メッセージを定義します。次のように実験モビリティプロトコルサブタイプレジストリ[4]のうち、これら4つの新しいサブタイプの値の割り当てが割り当てられています：
Subtype Description Reference
------- ----------- ---------
2 RtSolPr Section 6.1.1
3 PrRtAdv Section 6.1.2
4 HI Section 6.2.1
5 HAck Section 6.2.2
This document defines four new Neighbor Discovery [6] options that have received Type assignments from IANA.
このドキュメントは、IANAからタイプの割り当てを受けている4新しい近隣探索[6]オプションを定義します。
Option-Type Description Reference
----------- ----------- ---------
17 IP Address Option Section 6.4.1
18 New Router Prefix
Information Option Section 6.4.2
19 Link-Layer Address
Option Section 6.4.3
20 Neighbor Advertisement
Acknowledgment Option Section 6.4.5
This document defines three new Mobility Header messages that have received type allocations from the Mobility Header Types registry at http://www.iana.org/assignments/mobility-parameters:
このドキュメントは、http://www.iana.org/assignments/mobility-parametersでモビリティヘッダタイプレジストリからタイプの割り当てを受けた3つの新しいモビリティヘッダのメッセージを定義しています。
1. Fast Binding Update, described in Section 6.3.1
6.3.1項で説明1.高速バインディングアップデート、
2. Fast Binding Acknowledgment, described in Section 6.3.2, and
6.3.2項で説明2.高速バインディング確認、および
3. Fast Neighbor Advertisement, described in Section 6.3.3.
6.3.3項で説明3.高速近隣広告、。
This document defines a new Mobility Option which has received type assignments from the Mobility Options Type registry at http://www.iana.org/assignments/mobility-parameters:
このドキュメントは、http://www.iana.org/assignments/mobility-parametersでモビリティオプションタイプレジストリからタイプの割り当てを受けた新しいモビリティ・オプションを定義します。
1. Mobility Header Link-Layer Address option, described in Section 6.4.4.
6.4.4項で説明1.モビリティヘッダリンク層アドレスオプション、。
The editor would like to thank all those who have provided feedback on this specification, but can only mention a few here: Martin Andre, Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Suvidh Mathur, Koshiro Mitsuya, Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Domagoj Premec, and Jonathan Wood. The editor would like to acknowledge a contribution from James Kempf to improve this specification. The editor would also like to thank the [mipshop] working group chair Gabriel Montenegro and the erstwhile [mobile ip] working group chairs Basavaraj Patil and Phil Roberts for providing much support for this work.
エディタはこの仕様にフィードバックを提供してきたすべての人々に感謝したいと思いますが、唯一ここではいくつかを言及することができます：マーティン・アンドレ、ビジェイDevarapalli、ユン・喜漢、エミールIvov、Suvidhマートゥル、幸四郎三ツ矢、ガブリエルモンテネグロ、武小川、日鵬、YC鵬、Domagoj Premec、とジョナサン・ウッド。編集者は、この仕様を改善するために、ジェームズケンプからの貢献を認めるしたいと思います。エディタも感謝したい[mipshop]ワーキンググループの議長ガブリエルモンテネグロとかつての[モバイルIP]ワーキンググループは、この作品のために多くの支援を提供するためのBasavarajパティルとフィル・ロバーツの議長を務めます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[2]コンタ、A.、およびS.デアリングを、 "インターネット制御メッセージプロトコル（ICMPv6の）インターネットプロトコルバージョン6（IPv6）の仕様は、"、RFC 2463、1998年12月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[3]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[4] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[4]ケンプ、J.、RFC 4065、2005年7月 "Seamobyと実験モビリティプロトコルのIANAの割り当てのための手順"。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[5]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[6] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[6] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 2461、1998年12月。
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[7]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
This document originated in the fast handover design team effort. The members of this design team in alphabetical order were: Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis, and Alper Yegin.
この文書では、高速ハンドオーバ設計チームの努力で始まりました。アルファベット順に、この設計チームのメンバーは以下の通りであった。ゴパルDommety、カリム・エルMalki、モハメド・カリル、チャールズ・パーキンス、Heshamソリマン、ジョージ・Tsirtsis、及びアルパースYegin。
The design team member's contact information:
設計チームのメンバーの連絡先情報：
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ゴパルDommetyシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
Phone:+1 408 525 1404 EMail: gdommety@cisco.com
電話：+1 408 525 1404 Eメール：gdommety@cisco.com
Karim El Malki Ericsson Radio Systems AB LM Ericssons Vag. 8 126 25 Stockholm SWEDEN
カリム・エルMalki、エリクソン無線システムAB LM Ericssonのパス。 8 126 25スウェーデンストックホルム
Phone: +46 8 7195803 Fax: +46 8 7190170 EMail: Karim.El-Malki@era.ericsson.se
電話：+46 8 7195803ファックス：+46 8 7190170 Eメール：Karim.El-Malki@era.ericsson.se
Mohamed Khalil Nortel Networks
モハメド・カリル、ノーテルネットワークス
EMail: mkhalil@nortelnetworks.com
メールアドレス：mkhalil@nortelnetworks.com
Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンス通信システム研究所ノキア・リサーチセンター313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
Phone: +1-650 625-2986 Fax: +1 650 625-2502 EMail: charliep@iprg.nokia.com
電話：+ 1-650 625-2986ファックス：+1 650 625-2502 Eメール：charliep@iprg.nokia.com
Hesham Soliman Flarion Technologies
ヒシャムスレイマン・テクノロジーズフライヤー
EMail: H.Soliman@flarion.com
メールアドレス：H.Soliman@flarion.com
George Tsirtsis Flarion Technologies
ジョージTsirtsisフラリオン・テクノロジーズ
EMail: G.Tsirtsis@flarion.com
メールアドレス：G.Tsirtsis@flarion.com
Alper E. Yegin Samsung Advanced Institute of Technology 75 West Plumeria Drive San Jose, CA 95134 USA
アルパースE. Yeginサムスン先端技術研究所75西プルメリアドライブのサンノゼ、CA 95134 USA
Phone: +1 408 544 5656 EMail: alper.yegin@samsung.com
電話：+1 408 544 5656 Eメール：alper.yegin@samsung.com
Author's Address
著者のアドレス
Rajeev Koodli, Editor Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
ラジーブKoodli、エディタノキア・リサーチセンター313フェアチャイルドドライブマウンテンビュー、CA 94043 USA
Phone: +1 650 625 2359 Fax: +1 650 625 2502 EMail: Rajeev.Koodli@nokia.com
電話：+1 650 625 2359ファックス：+1 650 625 2502 Eメール：Rajeev.Koodli@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。