Network Working Group R. Koodli, Ed.
Request for Comments: 5268 Starent Networks
Obsoletes: 4068 June 2008
Category: Standards Track
Mobile IPv6 Fast Handovers
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
Mobile IPv6 enables a Mobile Node (MN) 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 (VoIP). 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は、別のアクセスルータから移動するとき、ハンドオーバと呼ばれるプロセスをインターネットへの接続性を維持するために、モバイルノード（MN）を可能にします。ハンドオーバ中に、モバイルノードがあるため、リンク切替遅延及びIPプロトコル動作のパケットを送信または受信することができない期間があります。標準のモバイルIPv6の手順から生じたこの「ハンドオーバ待ち時間」、つまり動き検出、新しい気付アドレスの設定、およびバインディングアップデートは、多くの場合、ボイスオーバーIP（VoIP）のようなリアルタイムトラフィックに受け入れられません。ハンドオーバ待ち時間を減らすことだけでなく、非リアルタイム、スループット重視のアプリケーションに有益である可能性があります。この文書では、モバイルIPv6の手続きによるハンドオーバ待ち時間を改善するためのプロトコルを指定します。この文書では、リンクの切り替えの待ち時間を改善し対応していません。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Protocol Overview ...............................................6
3.1. Addressing the Handover Latency ............................6
3.2. Protocol Operation .........................................8
3.3. Protocol Operation during Network-Initiated Handover ......11
4. Protocol Details ...............................................11
5. Other Considerations ...........................................15
5.1. Handover Capability Exchange ..............................15
5.2. Determining New Care-of Address ...........................16
5.3. Prefix Management .........................................16
5.4. Packet Loss ...............................................17
5.5. DAD Handling ..............................................18
5.6. Fast or Erroneous Movement ................................19
6. Message Formats ................................................20
6.1. New Neighborhood Discovery Messages .......................20
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) ..........................................20
6.1.2. Proxy Router Advertisement (PrRtAdv) ...............22
6.2. Inter - Access Router Messages ............................25
6.2.1. Handover Initiate (HI) .............................25
6.2.2. Handover Acknowledge (HAck) ........................27
6.3. New Mobility Header Messages ..............................28
6.3.1. Fast Binding Update (FBU) ..........................28
6.3.2. Fast Binding Acknowledgment (FBack) ................30
6.4. Unsolicited Neighbor Advertisement (UNA) ..................31
6.5. New Options ...............................................32
6.5.1. IP Address/Prefix Option ...........................33
6.5.2. Link-Layer Address (LLA) Option ....................34
6.5.3. Mobility Header Link-Layer Address (MH-LLA)
Option .............................................35
6.5.4. Binding Authorization Data for FMIPv6 (BADF) .......35
6.5.5. Neighbor Advertisement Acknowledgment (NAACK) ......36
7. Related Protocol and Device Considerations .....................37
8. Evolution from and Compatibility with RFC 4068 .................38
9. Configurable Parameters ........................................39
10. Security Considerations .......................................39
10.1. Peer Authorization Database Entries when Using IKEv2 .....41
10.2. Security Policy Database Entries .........................42
11. IANA Considerations ...........................................42
12. Acknowledgments ...............................................43
13. References ....................................................44
13.1. Normative References .....................................44
13.2. Informative References ...................................45
Appendix A. Contributors ..........................................46
Appendix B. Changes since RFC 4068 ................................46
Mobile IPv6 [RFC3775] 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 link-layer procedures, 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 [RFC3775]は別のアクセスルータからのハンドオーバ中に、インターネットへの接続を維持するために、移動ノードのプロトコル動作について説明します。これらの操作は、リンクレイヤ手順、動き検出、IPアドレスの設定、及び位置更新を含みます。組み合わせハンドオーバ待ち時間は、多くの場合、リアルタイム・アプリケーションに影響を与えるに十分です。スループット重視のアプリケーションにも、この待ち時間を短縮の恩恵を受けることができます。この文書では、ハンドオーバ待ち時間を短縮するためのプロトコルを記述します。
This specification addresses the following problems: 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 [RFC3775]. There are no special requirements for a mobile node to behave differently with respect to its standard Mobile IP operations.
この仕様は、次のような問題に対処します。それは新しいサブネットリンクを検出し、その添付ファイルが新しいアクセスルータによって検出されるとすぐに、モバイルノードにパケットを配信する方法とすぐに、移動ノードがパケットを送信できるようにする方法。プロトコルに関係なく、リンク技術のその動作に必要なIPプロトコルメッセージを定義します。これは、リンク固有のカスタマイズを可能にしながら、特定のリンク層の機能に依存することなく、これを行います。定義では、この仕様は、モバイルIPと相互作用ハンドオーバを考慮します。その新たなアクセスルータに接続したら、MNは、往復経路[RFC3775]を含むモバイルIP作業に従事しています。その標準のモバイルIPの操作に関して異なる動作をするために、モバイルノードのための特別な要件はありません。
This specification is applicable when a mobile node has to perform IP layer operations as a result of handovers. This specification does not address improving the link switching latency. It does not modify or optimize procedures related to signaling with the home agent of a mobile node. Indeed, while targeted for Mobile IPv6, it could be used with any mechanism that allows communication to continue despite movements. Finally, this specification does not address bulk movement of nodes using aggregate prefixes.
モバイルノードがハンドオーバの結果として、IP層動作を実行する必要があるときに、この仕様は適用可能です。この仕様は、リンクの切り替えの待ち時間を改善し対応していません。これは、モバイルノードのホームエージェントとのシグナリングに関連する手順を変更したり、最適化しません。モバイルIPv6を対象としながら、実際に、それは通信が動きにもかかわらず、継続することを可能にする任意の機構を使用することができます。最後に、本明細書では集約プレフィックスを使用してノードのバルク運動に対処していません。
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 [RFC2119]. 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 [RFC2119]に記載されているように解釈されます。用語の使用は、「サイレント無視」は、RFC 2119で定義されていないが、この用語は、この文書で使用され、同様に解釈されることができます。
The following terminology and abbreviations are used in this document in addition to those defined in [RFC3775]. The reference handover scenario is illustrated in Figure 1.
以下の用語および略語は、[RFC3775]で定義されたものに加えて、この文書で使用されています。参照ハンドオーバシナリオが図1に示されています。
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：ハンドオーバのためのレファレンス・シナリオ
Mobile Node (MN): A Mobile IPv6 host.
モバイルノード（MN）：モバイル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 the AP's L2 address. Sometimes, AP-ID is also referred to as a Basic Service Set IDentifier (BSSID).
アクセスポイント（AP）：MNに無線接続性を提供するIPサブネットに接続されているレイヤ2デバイス。アクセスポイント識別子（AP-ID）がAPのL2アドレスを指します。時には、AP-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 anticipated default router subsequent to its handover.
新アクセスルータ（NAR）：そのハンドオーバ後にMNの予想デフォルトルータ。
Previous CoA (PCoA): The MN's Care-of Address valid on PAR's subnet.
前のCoA（PCOA）：MNの気付アドレスの有効なPARのサブネット上にあります。
New CoA (NCoA): The MN's Care-of Address valid on NAR's subnet.
新たなCoA（NCOA）：MNの気付アドレスNARのサブネット上の有効な。
Handover: A process of terminating existing connectivity and obtaining new IP connectivity.
ハンドオーバ：既存の接続を終了し、新しいIP接続を取得するプロセス。
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 can also act as a trigger for network-initiated handover.
プロキシルータ広告（代理ルータ広告）：迅速な動き検出を容易にする隣接リンクに関する情報を提供してMNへPARからのメッセージ。メッセージはまた、ネットワーク開始ハンドオーバのトリガーとして機能することができます。
(AP-ID, AR-Info) tuple: Contains an access router's L2 and IP addresses, and 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, and Prefix] is called "AR-Info". See Section 5.3.
（AP-ID、AR-情報）タプル：（AP-IDによって識別される）アクセスポイントが接続されているインターフェイス上で有効なアクセスルータのL2およびIPアドレス、およびプレフィックスが含まれています。トリプレット[ルータのL2アドレス、ルーターのIPアドレス、およびプレフィックス]「AR-情報」と呼ばれています。 5.3節を参照してください。
Neighborhood Discovery: The process of resolving neighborhood AP-IDs to AR-Info.
近所の発見：AR-情報、近隣AP-IDを解決するプロセス。
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).
（NARに向かって）そのトラフィックをリダイレクトするために、そのPARを指示するMNからのメッセージ：ファストアップデート（FBU）を結合。
Fast Binding Acknowledgment (FBack): A message from the PAR in response to an FBU.
高速応答（裏）結合：PARからのメッセージをFBIに応じ。
Predictive Fast Handover: The fast handover in which an MN is able to send an FBU when it is attached to the PAR, which then establishes forwarding for its traffic (even before the MN attaches to the NAR).
予測高速ハンドオーバ：MNは、それが、その後（MNがNARに接続する前であっても）そのトラフィックの転送を確立PARに装着されたときにFBUを送信することがある、高速ハンドオーバ。
Reactive Fast Handover: The fast handover in which an MN is able to send the FBU only after attaching to the NAR.
反応性高速ハンドオーバ：MNのみNARに取り付けてからFBUを送信することがある、高速ハンドオーバ。
Unsolicited Neighbor Advertisement (UNA): The message in [RFC4861] with 'O' bit cleared.
求められていない近隣広告（UNA）：「O」ビットをクリアして、[RFC4861]にメッセージ。
Fast Neighbor Advertisement (FNA): This message from RFC 4068 [RFC4068] is deprecated. The UNA message above is the preferred message in this specification.
高速隣接広告（FNA）：RFC 4068 [RFC4068]からのこのメッセージは廃止されます。 UNAメッセージは、上記の本明細書における好ましいメッセージです。
Handover Initiate (HI): A message from the PAR to the NAR regarding an MN's handover.
ハンドオーバ（HI）開始：MNのハンドオーバに関するNARへのPARからのメッセージ。
Handover Acknowledge (HAck): A message from the NAR to the PAR as a response to HI.
ハンドオーバ（ハック）肯定応答：HIに対する応答としてPARにNARからメッセージを。
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 the 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 process the Binding Update successfully, 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 (e.g., a "scan" in Wireless Local Area Network (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 in 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)" (see Section 6.3.2) message prior to its movement. In the event it moves without receiving an FBack, the MN can still start using NCoA after announcing its attachment through an unsolicited Neighbor Advertisement message (with the 'O' bit set to zero) [RFC4861]; NAR responds to this UNA message in case it wishes to provide a different IP address to use. In this way, NCoA configuration latency is reduced.
それはまだPARのリンク上に存在しているときRtSolPrをし、代理ルータ広告メッセージを介して、MNはまた、将来の新たなCoA（NCOA）を策定しています。したがって、ハンドオーバ後に新しいプレフィックス発見のために待ち時間が解消されます。さらに、この将来のアドレスが新しいサブネットリンクに取り付けた後、すぐに使用することができます（つまり、NARのリンク）MNはその動きに先立って、「高速応答（FBACK）をバインド」（セクション6.3.2を参照）メッセージを受信したとき。それはFBACKを受信することなく移動させる場合には、MNが依然として求められていない近隣広告メッセージ（「O」がゼロに設定ビットが）[RFC4861]を介して添付ファイルを発表した後、NCOAを使用して開始することができます。 NARは、それが使用する別のIPアドレスを提供したい場合には、このUNAメッセージに応答します。このように、NCOA構成待ち時間が短縮されます。
The information provided in the PrRtAdv message can be used even when DHCP [RFC3315] is used to configure an NCoA on the NAR's link. In this case, the protocol supports forwarding using PCoA, and the MN performs DHCP once it attaches to the NAR's link. The MN still formulates an NCoA for FBU processing; however, it MUST NOT send data packets using the NCoA in the FBU.
DHCP [RFC3315]はNARのリンクをNCOAを設定するために使用された場合でも、代理ルータ広告メッセージで提供された情報を使用することができます。この場合、プロトコルはPCOAを使用して転送をサポートし、それがNARのリンクにアタッチしたら、MNは、DHCPを実行します。 MNは、まだFBUの処理のためのNCOAを策定します。しかし、それはFBUにNCOAを使用して、データ・パケットを送ってはいけません。
In order to reduce the Binding Update latency, the protocol specifies a binding between the Previous CoA (PCoA) and NCoA. An MN sends a "Fast Binding Update" (see Section 6.3.1) message to its Previous Access Router to establish this tunnel. When feasible, the MN SHOULD send an FBU from the PAR's link. Otherwise, the MN should send the FBU immediately after detecting attachment to the NAR. An FBU message MUST contain the Binding Authorization Data for FMIPv6 (BADF) option (see Section 6.5.4) in order to ensure that only a legitimate MN that owns the PCoA is able to establish a binding. Subsequent sections describe the protocol mechanics. In any case, the result is that the 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 the PAR, again until it completes Binding Update. And, PAR MUST 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 a PCoA as a source IP address are not dropped due to ingress filtering. Even though the MN is IP-capable on the new link, it cannot use the NCoA directly with its correspondents without the correspondents first establishing a binding cache entry (for the NCoA). Forwarding support for the PCoA is provided through a reverse tunnel between the MN and the PAR.
バインディング更新の待ち時間を低減するために、プロトコルは、前のCoA（PCOA）とNCOA間の結合を指定します。 MNは、このトンネルを確立するために、その前のアクセスルータに「高速バインディングアップデート」（6.3.1項を参照）メッセージを送信します。可能な場合、MNは、PARのリンクからFBUを送るべきです。それ以外の場合は、MNは、直ちにNARに添付ファイルを検出した後、FBUを送信する必要があります。 FBUメッセージはPCOAを所有する唯一の合法的なMNは、バインディングを確立することができることを確実にするために、FMIPv6のための結合認証データ（BADF）オプションを（6.5.4項を参照）を含まなければなりません。後続のセクションでは、プロトコルの仕組みを説明しています。いずれにせよ、結果は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 the NAR to send Neighbor Solicitation before the MN attaches, subsequent retransmissions of address resolution are separated by a default period of one second each. In order to circumvent this delay, an MN announces its attachment immediately with an UNA message that allows the NAR to forward packets to the MN right away. 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にパケットを転送することができますUNAメッセージですぐにその添付ファイルを発表しました。 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 the
また、このプロトコルは、次の重要な機能を提供します。アクセスルータは、提案NCOAが受け入れ可能であることを確認するためにメッセージを交換することができます。たとえば、ときMNからFBUを送ります
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 the PAR before providing forwarding support for the MN. That is, it may create a forwarding entry for the NCoA, subject to "approval" from the PAR, which it trusts. In addition, buffering for handover traffic at the NAR may be desirable. Even though the Neighbor Discovery protocol provides a small buffer (typically one or two packets) for packets awaiting address resolution, this buffer may be inadequate for traffic, such as VoIP, already in progress. The routers may also wish to maintain a separate buffer for servicing the handover traffic. Finally, the access routers could transfer network-resident contexts, such as access control, Quality of Service (QoS), and header compression, in conjunction with handover (although the context transfer process itself is not specified in this document). For all these operations, the protocol provides "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages (see Section 6.2). Both of these messages SHOULD be used. The access routers MUST have the necessary security association established by means outside the scope of this document.
PARのリンクは、FBACKはNARは使用が許容NCOAを考慮した後にお届けすることができます。アドレスはアクセスルータによって割り当てられている場合に特に便利です。 NARはまた、MNの転送のサポートを提供する前に、PARとの信頼関係に依存することができます。それは、それが信頼PARから「承認」を受けNCOAの転送エントリを作成すること、です。また、NARにハンドオーバートラフィックのバッファリングが望ましいかもしれません。近隣探索プロトコルは、アドレス解決を待っているパケットの小さなバッファ（典型的には、1つ又は2つのパケットを）提供するにもかかわらず、このバッファは、既に進行中で、VoIPなど、トラフィックのために不十分であり得ます。ルータは、ハンドオーバトラフィックにサービスを提供するための別のバッファを維持することを望むかもしれません。 （コンテキスト転送プロセス自体は、この文書で指定されていないが）最後に、アクセスルータは、ハンドオーバに関連して、このようなアクセス制御、サービスの品質（QoS）、およびヘッダ圧縮のようなネットワーク常駐コンテキストを転送することができました。すべてのこれらの操作のために、プロトコルが提供「ハンドオーバーを開始（HI）」とのメッセージ（セクション6.2を参照してください）「ハンドオーバは、（ハック）アクノリッジ」。これらのメッセージのどちらを使用する必要があります。アクセスルータは、この文書の範囲外の手段によって確立され、必要なセキュリティアソシエーションを持たなければなりません。
The protocol begins when an MN sends an RtSolPr message 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 an 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 an 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 to the PAR. The purpose of the FBU is to authorize the PAR to bind the PCoA to the NCoA, so that arriving packets can be tunneled to the new location of the MN. The FBU should be sent from the PAR's link whenever feasible. For instance, an internal link-specific trigger could enable FBU transmission from the previous link.
代理ルータ広告メッセージで提供された情報では、MNは、将来のNCOAを策定し、PARにFBUメッセージを送信します。 FBUの目的は、到着するパケットは、MNの新しい位置にトンネリングすることができるように、NCOAにPCOAをバインドするためにPARを承認することです。 FBUは、実現可能な時はいつでもPARのリンクから送られるべきです。例えば、内部リンクに固有のトリガは、前リンクからFBU伝送を可能にすることができます。
When it is not feasible, the FBU is sent from the new link.
それが不可能な場合は、FBUは、新しいリンクから送られてきます。
The format and semantics of FBU processing are specified in Section 6.3.1. The FBU message MUST contain the BADF option (see Section 6.5.4) to secure the message.
FBU処理の形式と意味論はセクション6.3.1で指定されています。 FBUメッセージは、メッセージを確保する（6.5.4項を参照）BADFオプションを含まなければなりません。
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 FBack on the previous link. This means that packet tunneling is already in progress by the time the MN handovers to the NAR. The MN SHOULD send the UNA immediately after attaching to the NAR, so that arriving as well as buffered packets can be forwarded to the MN right away. Before sending FBack to the MN, the 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 an HI message (from PAR to NAR), and NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST be returned in HAck (from NAR to PAR), and PAR MUST in turn provide the assigned NCoA in FBack. If there is an assigned NCoA returned in FBack, the MN MUST use the assigned address (and not the proposed address in FBU) upon attaching to NAR.
1. MNは、前のリンク上でFBACKを受けます。これは、パケットトンネリングがNARにMNは、ハンドオーバ時間ですでに進行中であることを意味します。到着と同様にバッファリングされたパケットは、すぐにMNに転送することができるように、MNは、すぐにNARに取り付けた後UNAを送るべきです。 MNにFBACKを送信する前に、PARはNCOAがHIと上記ハンドオフメッセージの交換を通じてNARに受け入れられるかどうかを判断することができます。 （すなわち、アドレスはルータによって割り当てられる）が使用されるアドレッシング割り当てられたとき、FBUに提案NCOAは、HIメッセージ（PARからNARへ）で運ばれ、NARが提案NCOAを割り当てることができます。そのような割り当てはNCOA（NARからPARへ）上記ハンドオフで戻らなければならない、およびPARは順番に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 the PAR has processed the FBU successfully. Hence, the MN (re)sends the FBU message to the PAR immediately after sending the UNA message. If the NAR chooses to supply a different IP address to use than the NCoA, it MAY send a Router Advertisement with "Neighbor Advertisement Acknowledge (NAACK)" option in which it includes an alternate IP address for the MN to use. Detailed UNA processing rules are specified in Section 6.4.
しかし、FBACKを受ける前に、MNがFBU送信していないか、MNは、（それ自体が失われる可能性があります）FBUを送信した後、リンクを残しているので、2 MNは、前のリンク上でFBACKを受信しません。後者の場合にはFBACKを受けることなく、MNがPARが正常FBUを処理したか否かを確認することができません。したがって、MNは、（再）直ちにUNAメッセージを送信した後にPARにFBUメッセージを送信します。 NARはNCOAよりも使用するように異なるIPアドレスを提供することを選択した場合、それはMNが使用する代替IPアドレスが含まれているオプション「（NAACK）を認める近隣広告」とルータ広告を送信することができます。詳細UNA処理ルールは、6.4節で指定されています。
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 the "predictive" mode of operation. The scenario in which the MN sends an FBU from the NAR's link is illustrated in Figure 3. For convenience, this scenario is characterized as the "reactive" mode of operation. Note that the reactive mode also includes the case in which an FBU has been sent from the PAR's link but an FBack has not yet been received. The figure is intended to illustrate that the FBU is forwarded through the NAR, but it is processed only by the PAR.
MNは、FBUを送信し、PARのリンク上FBACKを受信するシナリオでは、このシナリオでは、操作の「予測」モードとして特徴付けられる、便宜上、図2に示されています。 MNがNARのリンクからFBUを送信するシナリオは、このシナリオでは、操作の「反応」モードとして特徴付けられる、便宜上、図3に示されています。反応性モードもFBUをPARのリンクから送られてきたが、FBACKがまだ受信されていない場合も含むことに注意してください。図はFBUがNARを介して転送されていることを説明することを意図しているが、それだけPARによって処理されます。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|----------HI--------->|
| |<--------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets ===============>|
| | |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: Predictive Fast Handover
図2：予測の高速ハンドオーバー
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| |<-------FBU----------)|
| |----------HI--------->|
| |<-------HAck----------|
| |(HI/HAck if necessary)|
| forward |
| packets(including FBAck)=====>|
| | |
|<=================================== deliver packets
| |
Figure 3: Reactive Fast Handover
図3：反応性高速ハンドオーバ
Finally, the PrRtAdv message may be sent unsolicited, i.e., without the MN first sending an 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 such networks, the PAR can send an unsolicited PrRtAdv containing the link-layer address, IP address, and subnet prefix 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 the 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項を参照してください。
All descriptions refer to Figure 1.
すべての記述は、図1を参照してください。
After discovering one or more nearby access points, the MN sends RtSolPr to the PAR in order to resolve access point identifiers to subnet router information. A convenient time to do this is 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., UNA) can be transmitted immediately. Implementations SHOULD make use of such triggers whenever available.
一つ以上の近くのアクセスポイントを発見した後、MNは、ルータ情報をサブネットするアクセスポイント識別子を解決するためにPARにRtSolPrをを送信します。これを実行するのに便利な時間は、ルータディスカバリを実行した後です。しかし、MNは、例えば、1つ以上の新しいアクセスポイントが発見されたときに、いつでもRtSolPrを送信することができます。 MNはまた、PARへの取り付けの際に複数回RtSolPrを送信することができます。 RtSolPrをを送信するためのトリガは、現在のアクセスポイントの信号品質フェージングと結合された別のアクセスポイントから良好な信号強度の約束として、リンク固有のイベントに由来し得ます。そのような事象は、しばしば広く「L2トリガー」と呼ばれる、この文書の範囲外です。それにもかかわらず、彼らはこのプロトコルを起動するイベントとしての役割を果たす。 「リンクアップ」表示が新しいリンク上で得られた場合、例えば、プロトコルメッセージ（例えば、UNA）直ちに送信することができます。実装がいつでも利用可能なトリガの使用をしなければなりません。
The RtSolPr message contains one or more AP-IDs. A wildcard requests all available tuples.
RtSolPrをメッセージは、一つ以上のAP-IDが含まれています。ワイルドカードは、利用可能なすべてのタプルを要求します。
As a response to RtSolPr, the 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 the 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 First in First Out (FIFO) buffering is used, the PAR MUST continue forwarding the packets to the PCoA (i.e., buffer and forward). While the protocol does not forbid such an implementation support, care must be taken to ensure that the PAR continues forwarding packets to the PCoA (i.e., uses a buffer and forward approach). The PAR SHOULD stop buffering once it begins forwarding packets to the NCoA.
さらに、プロトコルの動作が必要な場合は、いくつかの実装は、PARで着信パケットのコピーをバッファリングを開始することを選択するかもしれません。そのような先入れ先出し（FIFO）バッファリングが使用される場合、PAR（すなわち、緩衝液および転送）PCOAにパケットを転送し続ける必要があります。プロトコルは、そのような実装のサポートを禁止しないが、注意がPAR（すなわち、緩衝液および前方アプローチを使用して）PCOAにパケットを転送し続けることを保証するために注意しなければなりません。それはNCOAにパケットを転送し始めるとPARは、バッファリングを停止する必要があります。
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 the 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 the 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. In response to the FBU, the PAR establishes a binding between the PCoA ("Home Address") and the NCoA, and sends the FBack to the MN. Prior to establishing this binding, the PAR SHOULD send an HI message to the NAR, and receive HAck in response. In order 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 the PCoA, i.e., the FBU is sent from the PAR's link, 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に対応して、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 the NCoA supplied in the HI message is unique before beginning to defend it. It sends a Duplicate Address Detection (DAD) probe [RFC4862] for NCoA to verify uniqueness. However, in deployments where the probability of address collisions is considered extremely low (and hence not an issue), the parameter DupAddrDetectTransmits (see [RFC4862]) is set to zero on the NAR, allowing it to avoid performing DAD on the NCoA. The NAR similarly sets DupAddrDetectTransmits to zero in other deployments where DAD is not a concern. Once the NCoA is determined to be unique, the NAR starts proxying [RFC4861] the address for PROXY_ND_LIFETIME during which the MN is expected to connect to the NAR. In case there is already an NCoA present in its data structure (for instance, it has already processed an HI message earlier), the NAR MAY verify if the LLA is the same as its own or that of the MN itself. If so, the NAR MAY allow the use of the NCoA.
1. NCOAがそれを守るために開始する前に、ユニークであるHIメッセージで供給されるかどうかを決定します。 NCOAは、一意性を確認することが重複アドレス検出（DAD）プローブ[RFC4862]を送信します。しかし、アドレス衝突の確率は（問題ひいてはない）非常に低いと考えられる展開で、パラメータDupAddrDetectTransmitsは（[RFC4862]を参照）、それはNCOAでDADを実行する回避することができ、NARにゼロに設定されています。 NARは、同様DADは問題ではない他の展開でゼロにDupAddrDetectTransmitsを設定します。 NCOAがユニークであると判断されたら、NARは、MNがNARに接続することが期待されている間PROXY_ND_LIFETIMEのアドレスを[RFC4861]をプロキシを開始します。場合に、そのデータ構造内NCOA存在は、既に存在するLLAは、独自またはMN自体のそれと同じである場合（例えば、それは既に以前HIメッセージを処理した）、NARは検証することができます。もしそうなら、NARはNCOAの使用を可能にすることができます。
2. allocates the 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 the PCoA (on the interface to which the MN is attaching to) in case the 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 SHOULD also set up a reverse tunnel to the PAR in this case.
NCOAが受け入れまたは割り当てることができない場合に3.（MNがに付着されたインターフェイス上の）PCOAためのホストルートエントリを作成することができます。このホストルートエントリは、パケットが近隣探索を起動していない到着し、MNによる明示的な告知を介して、または他の手段のいずれかによって、MNの存在が検出されるまでのように実装する必要があります。 NARは、この場合もPARへの逆方向トンネルを設定する必要があります。
4. provides the status of the handover request in the Handover Acknowledge (HAck) message to the PAR.
4. PARへのハンドオーバがアクノリッジ（上記ハンドオフ）メッセージにおけるハンドオーバ要求のステータスを提供します。
When the Code value in HI is 1, the NAR MUST skip the above operations. Sending an HI message with Code 1 allows the NAR to validate the neighbor cache entry it creates for the MN during UNA processing. That is, the NAR can make use of the knowledge that its trusted peer (i.e., the PAR) has a trust relationship with the MN.
HIでコード値が1である場合、NARは、上記の操作をスキップしなければなりません。コード1とHIメッセージを送信すると、NARが、それはUNA処理中に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 as well 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 the 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メッセージを受信しない場合、それは高速ハンドオーバのサポートが利用できないことを想定し、プロトコルの動作を停止する必要があります。
As soon as the MN establishes link connectivity with the NAR, it:
すぐにMNがNARとのリンク接続を確立して、それは：
1. sends an UNA message (see Section 6.4). If the MN has not received an FBack by the time UNA is being sent, it SHOULD send an FBU message following the UNA message.
1.（6.4節を参照）UNAメッセージを送信します。 MNはUNAが送信されている時間によってFBACKを受信していない場合は、UNAメッセージ次FBUメッセージを送るべきです。
2. joins the all-nodes multicast group and the solicited-node multicast group corresponding to the NCoA.
2.全ノードマルチキャストグループ及びNCOAに対応する要請ノードマルチキャストグループに参加します。
When a NAR receives an UNA message, it:
NARはUNAメッセージを受信した場合、それ：
1. deletes its proxy neighbor cache entry, if it exists, updates the state to STALE [RFC4861], and forwards arriving and buffered packets.
1.は、それが存在する場合、STALE [RFC4861]に状態を更新し、前方に到着し、バッファリングされたパケット、そのプロキシ近隣キャッシュエントリを削除します。
2. updates an entry in INCOMPLETE state [RFC4861], if it exists, to STALE and forwards arriving and buffered packets. This would be the case if NAR had previously sent a Neighbor Solicitation that went unanswered perhaps because the MN had not yet attached to the link.
それが存在する場合2が古いパケットの到着およびバッファ転送に、不完全な状態[RFC4861]のエントリを更新します。 NARは、以前にMNは、まだリンクに接続していなかったので、おそらく未解答に行った近隣要請を送っていた場合、これがケースになります。
The buffer for handover traffic should be linked to this UNA processing. The exact mechanism is implementation dependent.
ハンドオーバトラフィックのためのバッファは、このUNA処理にリンクされなければなりません。正確なメカニズムは実装依存です。
The NAR may choose to provide a different IP address other than the NCoA. This is possible if it is proxying the NCoA. In such a case, it:
NARはNCOA以外の異なるIPアドレスを提供することもできます。それはNCOAをプロキシされた場合、これは可能です。このような場合には、それは：
1. MAY send a Router Advertisement with the NAACK option in which it includes an alternate IP address for use. This message MUST be sent to the source IP address present in UNA using the same Layer 2 address present in UNA.
1.は、それが使用する代替IPアドレスが含まれているNAACKオプションでルータ広告を送信することができます。このメッセージは、UNAで同じレイヤ2アドレスの存在を使用してUNA内のソースIPアドレスの存在に送らなければなりません。
If the MN receives an IP address in the NAACK option, it MUST use it and send an FBU using the new CoA. As a special case, the address supplied in NAACK could be the PCoA itself, in which case the MN MUST NOT send any more FBUs. The Status codes for the NAACK option are specified in Section 6.5.5.
MNはNAACKオプションでIPアドレスを受信した場合、それはそれを使用して、新しいCoAを使用してFBUを送らなければなりません。特殊なケースとして、NAACKに供給されたアドレスは、MNがこれ以上FBUSを送ってはいけません、その場合には、PCOAそのものである可能性があります。 NAACKオプションのステータスコードは、6.5.5項で規定されています。
Once the MN has confirmed its NCoA (either through DAD or when provided for by the NAR), it SHOULD send a Neighbor Advertisement message with the 'O' bit set, to the all-nodes multicast address. This message allows MN's neighbors to update their neighbor cache entries.
MNがそのNCOAを（いずれかNARによって提供DAD又は介して）確認した後、それは全ノードマルチキャストアドレスに、「O」ビットが設定された近隣広告メッセージを送信するべきです。このメッセージは、MNの隣人が自分の近隣キャッシュエントリを更新することができます。
For data forwarding, the PAR tunnels packets using its global IP address valid on the interface to which the MN was attached. The MN reverse tunnels its packets to the same global address of PAR. The tunnel end-point addresses must be configured accordingly. When the PAR receives a reverse tunneled packet, it must verify if a secure binding exists for the MN identified by the PCoA in the tunneled packet, before forwarding the packet.
データ転送の場合、PARは、MNが接続されたインターフェイスに上で有効なグローバルIPアドレスを使用してパケットをトンネルします。 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 the PAR does not support the fast handover protocol and stop sending any more RtSolPr messages.
MNは、そのRtSolPrをメッセージに応じて代理ルータ広告を見込んでいます。 MNもRTSOLPR_RETRIES後に代理ルータ広告メッセージを受信しない場合、それはPARが高速ハンドオーバプロトコルをサポートし、任意のより多くのRtSolPrをメッセージの送信を停止しないことを前提としなければなりません。
Even if an MN's current access router is capable of providing fast handover support, 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, the 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. However, the MN itself does not have to wait on PAR's link for this exchange to take place. It can handover any time after sending the FBU message; sometimes it may be forced to handover without sending the FBU. In any case, it can still confirm using NCoA from NAR's link by sending the UNA message.
典型的には、MNは、代理ルータ広告メッセージに提供された情報を使用して将来のNCOAを定式化し、FBUを送信します。 PARは、HIメッセージにFBUにNCOAの存在を使用しなければなりません。 HIでNCOAの存在が既に使用されている場合NARは確かめなければなりません。いずれの場合においても、NARは、割り当てられたアドレスの設定が使用されている場合は特に、それが使用する別のNCOAを含むことができるでは、ハック用いてHIに応答しなければなりません。上記ハンドオフ中のCoAが存在した場合、PARはFBACKメッセージにそれを含まなければなりません。しかし、MN自体は場所を取るために、この交換のためのPARのリンクを待つ必要はありません。これは、ハンドオーバFBUメッセージを送信した後の任意の時間をすることができます。時にはそれがFBUを送信せずにハンドオーバーに強制することができます。いずれにせよ、それはまだUNAメッセージを送信することにより、NARのリンクからNCOAを使用して確認することができます。
If a PrRtAdv message carries an NCoA, the MN MUST use it as its prospective NCoA.
代理ルータ広告メッセージはNCOAを運ぶ場合は、MNは、その将来のNCOAとしてそれを使用しなければなりません。
When DHCP is used, the protocol supports forwarding for PCoA only. In this case, the MN MUST perform DHCP operations once it attaches to the NAR even though it formulates an NCoA for transmitting the FBU. This is indicated in the PrRtAdv message with Code = 5.
DHCPを使用する場合、プロトコルはPCOAのために転送をサポートしています。それがFBUを送信するためのNCOAを策定するにもかかわらず、NARにアタッチしたら、この場合には、MNは、DHCPの操作を実行しなければなりません。これは、コード= 5の代理ルータ広告メッセージ内に示されています。
As defined in Section 2, the Prefix part of "AR-Info" is the prefix valid on the interface to which the AP is attached. This document does not specify how this Prefix is managed, it's length and assignment policies. The protocol operation specified in this document works regardless of these considerations. Often, but not necessarily always, this Prefix may be the aggregate prefix (such as /48) valid on the interface. In some deployments, each MN may have its own per-mobile prefix (such as a /64) used for generating the NCoA. Some point-to-point links may use such a deployment.
第2節で定義されているように、「AR-情報」のプレフィックス部分は、APが接続されているインターフェイス上で有効な接頭辞です。この文書では、それは長さと割り当て方針だ、このプレフィックスが管理されている方法を指定しません。この文書で指定されたプロトコルの動作にかかわらず、これらの考慮事項の作品。多くの場合、必ずしも必要ではないが、常に、このプレフィックスは、インターフェイス上で有効な集計プレフィックスを（例えば/ 48）であってもよいです。いくつかの展開では、各MNが独自ごとモバイル接頭辞を有していてもよい（/ 64など）NCOAを生成するために使用されます。いくつかのポイントツーポイントリンクは、このような展開を使用することができます。
When per-mobile prefix assignment is used, the "AR-Info" advertised in PrRtAdv still includes the (aggregate) prefix valid on the interface to which the target AP is attached, unless the access routers communicate with each other (using HI and HAck messages) to manage the per-mobile prefix. The MN still formulates an NCoA using the aggregate prefix. However, an alternate NCoA based on the per-mobile prefix is returned by NAR in the HAck message. This alternate NCoA is provided to the MN in either the FBack message or in the NAACK option.
毎モバイルプレフィックスの割り当てを使用する場合、代理ルータ広告でアドバタイズ「AR-INFO」は依然としてアクセスルータはHI用いて（相互に通信し、ハックしない限り、ターゲットAPが、添付されたインターフェイス上で有効（総計）の接頭辞を含みますごとのモバイルプレフィックスを管理するためのメッセージ）。 MNはまだ集計接頭辞を使用してNCOAを策定します。しかし、毎モバイルプレフィックスに基づいて代替NCOAはハックメッセージでNARによって返されます。この代替NCOAいずれかFBACKメッセージまたはNAACKオプションでMNに提供されます。
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 until the FBU is processed will be lost unless they are buffered. This protocol provides an option to indicate 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メッセージを送信した場合、それらがバッファリングされていない限り、同様に、FBUが処理されるまでPARに到着するパケットが失われます。このプロトコルは、HIメッセージにNARにバッファリングするための要求を示すためのオプションを提供します。 PARは、（MN用）この機能を要求すると、それはまた、バッファリングのための独自のサポートを提供する必要があります。
Whereas buffering can enable a smooth handover, the buffer size and the rate at which buffered packets are eventually forwarded are important considerations when providing buffering support. There are a number of aspects to consider:
バッファリングは滑らかなハンドオーバを可能にすることができるのに対し、バッファリングのサポートを提供する場合、バッファサイズとバッファリングされたパケットが最終的に転送される速度は重要な考慮事項です。考慮すべき点がいくつかあります：
o Some applications transmit less data over a given period of data than others, and this implies different buffering requirements. For instance, Voice over IP typically needs smaller buffers compared to high-resolution streaming video, as the latter has larger packet sizes and higher arrival rates.
O一部のアプリケーションでは、他よりもデータの所定の期間にわたってより少ないデータを送信し、これは異なるバッファリング要件を意味しています。後者は、より大きなパケットサイズと高い到着率を持つよう例えば、ボイスオーバーIPは、一般的に、高解像度のストリーミングビデオに比べて小さいバッファを必要とします。
o When the mobile node appears on the new link, having the buffering router send a large number of packets in quick succession may overtax the resources of the router, the mobile node itself, or the path between these two.
Oモバイルノードがバッファリングルータはルータ、モバイルノード自体、またはこれら二つの間のパスのリソースを悪税も立て続けに大量のパケットを送信持つ、新しいリンクに表示されたら。
In particular, transmitting a large amount of buffered packets in succession can congest the path between the buffering router and the mobile node. Furthermore, nodes (such as a base station) on the path between the buffering router and the mobile node may drop such packets. If a base station buffers too many such packets, they may contribute to additional jitter for packets arriving behind them, which is undesirable for real-time communication.
具体的には、連続的にバッファされたパケットを大量に送信すること緩衝ルータとモバイルノードとの間の経路が混雑することができます。また、緩衝ルータとモバイルノードの間の経路上の（例えば基地局のような）ノードは、パケットをドロップすることができます。基地局は、あまりにも多く、このようなパケットをバッファした場合、彼らはリアルタイム通信のために望ましくない、その背後に到着するパケットのために追加のジッタに寄与することができます。
o Since routers are not involved in end-to-end communication, they have no knowledge of transport conditions.
ルータは、エンドツーエンドの通信に関与しないので、O、彼らは、輸送条件の知識がありません。
o The wireless connectivity of the mobile node may vary over time. It may achieve a smaller or higher bandwidth on the new link, signal strength may be weak at the time it just enters the area of this access point, and so on.
Oモバイルノードの無線接続は、時間の経過と共に変化してもよいです。これは、新しいリンク、信号強度の小さいまたはより高い帯域幅は、それがちょうどそうで、このアクセスポイントのエリアに入り、一度に弱いかもしれ達成することができます。
As a result, it is difficult to design an algorithm that would transmit buffered packets at appropriate spacing under all scenarios. The purpose of fast handovers is to avoid packet loss. Yet, draining buffered packets too fast can, by itself, cause loss of the packets, as well as blocking or loss of following packets meant for the mobile node.
その結果、すべてのシナリオの下で、適切な間隔でバッファリングされたパケットを送信するであろうアルゴリズムを設計することは困難です。高速のハンドオーバの目的は、パケット損失を避けるためです。しかし、あまりにも速くバッファされたパケットを排出することは、それ自体で、パケットの損失だけでなく、ブロックまたはパケットがモバイルノードのためのもの、以下の損失を引き起こす可能性があります。
This specification does not restrict implementations from providing specialized buffering support for any specific situation. However, attention must be paid to the rate at which buffered packets are forwarded to the MN once attachment is complete. Routers implementing this specification MUST implement at least the default algorithm, which is based on the original arrival rates of the buffered packets. A maximum of 5 packets MAY be sent one after another, but all subsequent packets SHOULD use a sending rate that is determined by metering the rate at which packets have entered the buffer, potentially using smoothing techniques such as recent activity over a sliding time window and weighted averages [RFC3290].
この仕様は、特定の状況のための特殊なバッファリングサポートを提供するから実装を制限するものではありません。ただし、注意が添付ファイルが完了すると、バッファリングされたパケットをMNに転送される速度に支払わなければなりません。この仕様を実装するルータは、バッファされたパケットの元到着率に基づいて、少なくともデフォルトのアルゴリズムを実装する必要があります。 5つのパケットの最大は、次々に送られてもよいが、後続のすべてのパケットは、パケットは、潜在的にスライディングタイムウィンドウにわたって、このような最近のアクティビティなどの平滑化技術を使用して、バッファに入っている速度を計測することによって決定される送信レートを使用すべきです加重平均[RFC3290]。
It should be noted, however, that this default algorithm is crude and may not be suitable for all situations. Future revisions of this specification may provide additional algorithms, once enough experience of the various conditions in deployed networks is attained.
このデフォルトのアルゴリズムは、粗であり、すべての状況に適していないかもしれないことに留意すべきです。展開されたネットワーク内の様々な条件の十分な経験が達成されれば、この仕様の今後の改正は、追加的なアルゴリズムを提供することができます。
Duplicate Address Detection (DAD) was defined in [RFC4862] 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. The probability of an interface identifier duplication on the same subnet is very low; however, it cannot be ignored. Hence, the protocol specified in this document SHOULD only be used in deployments where the probability of such address collisions is extremely low or it is not a concern (because of the address management procedure deployed). The protocol requires the NAR to send a DAD probe before it starts defending the NCoA. However, this DAD delay can be turned off by setting DupAddrDetectTransmits to zero on the NAR [RFC4862].
重複アドレス検出（DAD）がステートレスアドレス自動設定を使用する場合、リンク上のアドレスの重複を避けるために[RFC4862]で定義されました。ステートレス自動構成を使用して構成IPv6アドレスの一意性を確認するためにDADを使用することは、ハンドオーバ遅延を付加します。同じサブネット上のインタフェース識別子の重複の確率は非常に低いです。しかし、それは無視することはできません。したがって、この文書で指定されたプロトコルは、このようなアドレス衝突の確率は極めて低いか、（なぜなら展開アドレス管理手順の）問題ではない展開で使用されるべきです。プロトコルは、それがNCOAを守る開始する前に、DADプローブを送信するためにNARが必要です。しかし、このDAD遅延はNAR [RFC4862]をゼロにDupAddrDetectTransmitsを設定することによってオフにすることができます。
This document specifies messages that can be used to provide duplicate-free addresses, but the document does not specify how to create or manage such duplicate-free addresses. In some cases, the NAR may already have the knowledge required to assess whether or not the MN's address is a duplicate before the MN moves to the new subnet. For example, in some deployments, the NAR may maintain a pool of duplicate-free addresses in a list for handover purposes. In such cases, the NAR can provide this disposition in the HAck message (see Section 6.2.2) or in the NAACK option (see Section 6.5.5).
この文書では、重複のないアドレスを提供するために使用することができるメッセージを指定しますが、文書は、このような重複したフリーアドレスを作成したり、管理する方法を指定しません。いくつかのケースでは、NARは、すでにMNが新しいサブネットに移動する前にMNのアドレスが重複しているかどうかを評価するために必要な知識を有することができます。例えば、いくつかの展開で、NARは、ハンドオーバのために、リスト内の重複のないアドレスのプールを維持することができます。このような場合に、NARは、ハックメッセージにこの配置を提供することができる（セクション6.2.2を参照）またはNAACKオプションで（セクション6.5.5を参照）。
Although this specification is for fast handover, the protocol is limited in terms of how fast an MN can move. A special case of fast movement is ping-pong, 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 either moves 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 Home Agent 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 of the order of 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レイヤのハンドオーバは、少なくとも、そのホームエージェント好ましくはすべての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 terminate that tunnel; i.e., start delivering packets directly to the node instead. In order for the PAR to process such an FBU, the lifetime of the security association has to be at least that of the tunnel itself.
NARに存在する場合に必要なバインディングを更新する前にPARに戻っMNは、MNのPCOAとPARにゼロの寿命に等しいホームアドレスを用いた高速バインディングアップデートを送らなければなりません。それはNARへの高速ハンドオーバを行ったので、MNはPARとのセキュリティアソシエーションを持つ必要があります。 PARは、この高速バインディングアップデートを受信すると、送信（一時的な高速ハンドオーバ）のトンネルのセットをチェックします。それが一致を見つけた場合、そのトンネルを終了すべきです。即ち、代わりにノードに直接パケットを配信開始します。 PARは、FBUを処理するために、セキュリティアソシエーションの寿命は、トンネル自体の少なくともそれでなければなりません。
Temporary tunnels for the purposes of fast handovers should use short lifetimes (of the order of at most a few tens 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, it SHOULD send a new Fast Binding Update to the PAR. This FBU supersedes the existing binding at the PAR, and the packets will be redirected to the newly confirmed location of the MN.
ルーティングが変更することができ、MNが実際にそのルータに接続する前に、PARは、別のルータに向けてパケットを転送することができるので、誤った動きの影響は、典型的には、パケットの損失に限定されます。 MNは、予期せぬアクセスルータ上で自分自身を発見した場合、それはPARに新しい高速バインディングアップデートを送信すべきです。このFBUは、既存のPARに結合し、パケットはMNの新たに確認された場所にリダイレクトされます優先されます。
All the ICMPv6 messages have a common Type specified in [RFC4443]. The messages are distinguished based on the Subtype field (see below). For all the ICMPv6 messages, the checksum is defined in [RFC4443].
すべてのICMPv6メッセージは、[RFC4443]で指定された一般的なタイプがあります。メッセージは、サブタイプフィールドに基づいて区別されている（下記参照）。すべてのICMPv6メッセージのために、チェックサムは、[RFC4443]で定義されています。
Mobile Nodes send Router Solicitation for Proxy Advertisement in order to prompt routers for Proxy Router Advertisements. All the Link-Layer Address options have the format defined in Section 6.5.2.
モバイルノードは、プロキシルータ広告のためのルータを促すためにプロキシ広告のためのルータ要請を送信します。すべてのリンク層アドレスオプションは、6.5.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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Router Solicitation for Proxy Advertisement (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。
ICMP Fields:
ICMPフィールド：
Type: 154
タイプ：154
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 (LLA) option. See the LLA option format below.
ソースリンク層アドレス：知られている場合は、送信者のリンク層アドレスは、リンク層アドレス（LLA）オプションを使用して含まれるべきです。以下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. See the LLA option below.
新しいアクセスポイントのリンク層アドレス：MNは、ルーティング広告情報を要求するためのアクセスポイントのリンク層アドレスまたは識別。これは、すべてのRtSolPrをメッセージに含まれなければなりません。以上のようなアドレスまたは識別子が存在することができます。また、このフィールドはワイルドカードアドレスにすることができます。以下LLAオプションを参照してください。
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 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 an 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 an 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 an 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 6.4.3.
ハンドオーバがネットワークによって開始または隣接ルータのリンク層アドレス、IPアドレス、サブネットプレフィックスを提供MNからRtSolPrをメッセージに対する応答として、ある場合、アクセスルータは、無償プロキシルータ広告メッセージを送信します。すべてのリンク層アドレスオプションは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 ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Proxy Router Advertisement (PrRtAdv) Message
図5：プロキシルータアドバタイズメント（代理ルータ広告）メッセージ
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 Proxy Advertisement or the address of the node the access router is instructing to handover.
宛先アドレス：プロキシ広告のための呼び出しルーター要請やアクセスルータがハンドオーバするように指示されたノードのアドレスの送信元アドレス。
Hop Limit: 255. See RFC 2461.
ホップ制限：255を参照のRFC 2461。
ICMP Fields:
ICMPフィールド：
Type: 154
タイプ：154
Code: 0, 1, 2, 3, 4, or 5. See below.
コード：0、1、2、3、4、または5以下を参照してください。
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 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 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 for. This option MUST be included when the Code is 0 or 1.
新しいルータのリンク層アドレス：このメッセージがためにプロキシされたアクセスルータのリンク層アドレス。コードが0または1である場合は、このオプションを含まなければなりません。
New Router's IP Address: The IP address of the NAR. This option MUST be included when the Code is 0 or 1.
新しいルータのIPアドレス：NARのIPアドレス。コードが0または1である場合は、このオプションを含まなければなりません。
New Router Prefix Information Option: Specifies the prefix of the access router the message is proxied for and is used for address auto-configuration. This option MUST be included when the Code is 0 or 1. However, when this prefix is the same as what is 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 PrRtAdv is sent unsolicited. The PAR MAY compute a new CoA using the 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, 4, and 5 are defined.
現在、コードは0、1、2、3、4値、及び5が定義されます。
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. The Option-Code field in the New Access Point LLA option in this case 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 has been sent unsolicited. If a New CoA option is present following the New Router Prefix Information option, the MN MUST use the supplied NCoA and send an 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. This would be the case, for instance, when a number of access points are connected to the same router interface, or when network based mobility management mechanisms ensure that the specific mobile node always observes the same prefix regardless of whether there is a separate router attached to the target access point. 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の複数のタプルで送信された場合とは異なり、ハンドオーバトリガしないことを意味します。
A Proxy Router Advertisement with Code 5 means that the MN may use the new router information present for detecting movement to a new subnet, but the MN must perform DHCP [RFC3315] upon attaching to the NAR's link. The PAR and NAR will forward packets to the PCoA of the MN. The MN must still formulate an NCoA for transmitting FBU (using the information sent in this message), but that NCoA will not be used for forwarding packets.
コード5とプロキシルータ通知は、MNが新しいサブネットに移動を検出するための、本の新しいルータ情報を使用することができるが、MNがNARのリンクへの取り付け時にDHCP [RFC3315]を実行しなければならないことを意味します。 PARとNARは、MNのPCOAにパケットを転送します。 MNは、依然として（このメッセージで送信された情報を使用して）FBUを送信するためのNCOAを策定しなければならないが、NCOAは、パケットを転送するために使用されないこと。
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 an 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-
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アドレス
ICMP Fields:
ICMPフィールド：
Type: 154
タイプ：154
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 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 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 round trip time (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 the NAR to the 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-
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.
宛先アドレス：ハンドオーバの送信元アドレスからコピーは、このメッセージが応答されたメッセージを開始します。
ICMP Fields:
ICMPフィールド：
Type: 154
タイプ：154
Code:
コード：
0: Handover Accepted, NCoA valid 1: Handover Accepted, NCoA not valid or in use 2: Handover Accepted, NCoA assigned (used in Assigned addressing) 3: Handover Accepted, use PCoA 4: Message sent unsolicited, usually to trigger an HI message 128: Handover Not Accepted, reason unspecified 129: Administratively prohibited 130: Insufficient resources
0：ハンドオーバ承認、NCOA有効1：ハンドオーバ承認、NCOA有効または使用2ではない：ハンドオーバ承認、（割り当てアドレッシングに使用される）割り当てNCOA 3：ハンドオーバ承認、PCOA 4を使用：メッセージは、通常、HIメッセージをトリガするために、迷惑送信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 the PCoA (instead of accepting or assigning an NCoA), establish a host route entry for the PCoA, and set up a tunnel to the PAR to forward the MN's packets sent with the 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. The NAR indicates forwarding support for PCoA using Code value 3 in the HAck message. Subsequently, the PAR establishes a tunnel to the NAR in order to forward packets arriving for the PCoA.
NARは、（代わりNCOAを受け入れる又は割り当てる）PCOAをサポートするPCOAためのホストルートエントリを確立し、送信元IPアドレスとしてPCOAで送信され、MNのパケットを転送するためにPARにトンネルを設定してもよいです。 NARは、特定のMNは、そのリンクに接続されていることを検出すると、このホストルートエントリがパケットを転送するために使用されるべきです。 NARはPCOAがハックメッセージにコード値3を使用するためのサポートを転送示します。その後、PARはPCOAために到着するパケットを転送するためにNARへのトンネルを確立します。
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 [RFC3775]. The Fast Binding Update, Fast Binding Acknowledgment, and the (deprecated) Fast Neighbor Advertisement messages use the Mobility Header.
モバイルIPv6は、モビリティヘッダ[RFC3775]と呼ばれる新しいIPv6ヘッダのタイプを使用します。高速バインディングアップデートは、高速謝辞をバインド、および（非推奨）高速近隣広告メッセージは、モビリティヘッダを使用しています。
The Fast Binding Update message has a Mobility Header Type value of 8. The FBU is identical to the Mobile IPv6 Binding Update (BU) message. However, the processing rules are slightly different.
高速バインディング更新メッセージは、8の移動ヘッダタイプ値FBUは、モバイルIPv6バインディング更新（BU）メッセージと同一です。しかし、処理ルールは若干異なります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [RFC3775].
「H」フラグ：1に設定しなければなりません。 [RFC3775]を参照してください。
'L' flag: See [RFC3775].
'L' フラグ：[RFC3775]を参照してください。
'K' flag: See [RFC3775].
'K' フラグ：[RFC3775]を参照されたいです。
Reserved: This field is unused. MUST be set to zero.
予約：このフィールドは未使用です。ゼロに設定しなければなりません。
Sequence Number: See [RFC3775].
シーケンス番号：[RFC3775]を参照してください。
Lifetime: The requested time in seconds for which the sender wishes to have a binding.
生涯：送信者がバインディングを持つことを望むいる秒で要求された時間。
Mobility Options: MUST contain an alternate CoA option set to the NCoA when an FBU is sent from the PAR's link. MUST contain the Binding Authorization Data for the FMIP (BADF) option. See Section 6.5.4. MAY contain the Mobility Header LLA option (see Section 6.5.3).
モビリティオプション：FBUをPARのリンクから送信されたときにNCOAに、代替CoAオプションのセットを含まなければなりません。 FMIP（BADF）オプションのために結合認証データを含まなければなりません。 6.5.4項を参照してください。モビリティヘッダLLAオプション（第6.5.3項を参照）を含むことができます。
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 the NCoA on the NAR according to Neighbor Discovery and IPv6 Address Configuration protocols. When the MN moves without having received a PrRtAdv message, it cannot transmit an UNA message upon attaching to the NAR's link.
MNは、代理ルータ広告メッセージを受信した後FBUメッセージをいつでも送信します。 MNは、代理ルータ広告メッセージを受信する前に移動した場合、それは近隣探索およびIPv6アドレスの設定プロトコルに従ってNARのNCOAを設定した後でPARにFBUを送るべきです。 MNは、代理ルータ広告メッセージを受信せずに移動すると、それはNARのリンクへの取り付け時にUNAメッセージを送信することはできません。
The source IP address is the PCoA when the FBU is sent from the PAR's link, and the source IP address is the NCoA when the FBU sent from the NAR's link. When the source IP address is the PCoA, the MN MUST include the alternate CoA option set to NCoA. The PAR MUST process the FBU even though the address in the alternate CoA option is different from that in the source IP address, and ensure that the address in the alternate CoA option is used in the New CoA option in the HI message to the NAR.
FBUをPARのリンクから送信され、送信元IPアドレスがFBUは、NARのリンクから送信されたときにNCOAでされたときに送信元IPアドレスがPCOAです。送信元IPアドレスがPCOAある場合には、MNはNCOAに設定され、代替CoAオプションを含まなければなりません。 PARは、代替のCoAオプション内のアドレスは、送信元IPアドレスと異なる場合であってもFBUを処理し、代替CoAオプション内のアドレスがNARにHIメッセージ内の新たなCoAオプションで使用されていることを確認しなければなりません。
The FBU MUST also include the Home Address Option set to PCoA. An FBU message MUST be protected so that the PAR is able to determine that the FBU message is sent by an MN that legitimately owns the PCoA.
FBUもPCOAに設定するホームアドレスオプションを指定する必要があります。 PARは、FBUメッセージが正当PCOAを所有しているMNによって送信されたと判断することができるようにFBUメッセージを保護しなければなりません。
The Fast Binding Acknowledgment message has a Mobility Header Type value of 9. The FBack message is sent by the PAR to acknowledge receipt of a Fast Binding Update message in which the 'A' bit is set. If PAR sends an HI message to the NAR after processing an FBU, the FBack message SHOULD NOT be sent to the MN before the PAR receives a HAck message from the NAR. The PAR MAY send the FBack immediately in the reactive mode however. The Fast Binding Acknowledgment MAY also be sent to the MN on the old link.
高速Binding Acknowledgementメッセージは、9のモビリティヘッダタイプ値FBACKメッセージは「」ビットが設定されている高速バインディング更新メッセージの受信を確認するためにPARによって送信されています。 PARはFBUを処理した後、NARにHIメッセージを送信した場合、PARは、NARからハックメッセージを受信する前に、FBACKメッセージがMNに送るべきではありません。 PARは、しかし、反応モードですぐにFBACKを送信することができます。高速結合確認も古いリンク上のMNに送ってもよいです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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, and optionally the PCoA
宛先アドレス：NCOA、およびPCOA随意
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
0高速バインディングアップデートは受け入れ1つの高速バインディングアップデートを受け入れたが、NCOAは無効です。使用NCOAは、「代替」のCoAに供給しました
Values of the Status field 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：リソース不足131：不正のインタフェース識別子の長行政130禁止しました
'K' flag: See [RFC3775].
'K' フラグ：[RFC3775]を参照されたいです。
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. MUST contain the Binding Authorization Data for FMIP (BADF) option. See 6.4.5.
モビリティオプション：ステータスが1バインディングFMIPのための認証データ（BADF）オプションを含まなければならないである場合、「代替」CoAを含まなければなりません。 6.4.5を参照してください。
This is the same message as in [RFC4861] with the requirement that the 'O' bit is always set to zero. Since this is an unsolicited message, the 'S' bit is zero, and since this is sent by an MN, the 'R' bit is also zero.
これは、「O」ビットは常にゼロに設定されている要件に[RFC4861]と同様のメッセージです。これは迷惑メッセージであるので、「S」ビットはゼロであり、これは、MNによって送信されるので、「R」ビットもゼロです。
If the NAR is proxying the NCoA (as a result of HI and HAck exchange), then UNA processing has additional steps (see below). If the NAR is not proxying the NCoA (for instance, HI and HAck exchange has not taken place), then UNA processing follows the same procedure as specified in [RFC4861]. Implementations MAY retransmit UNA subject to the specification in Section 7.2.6 of [RFC4861] while noting that the default RetransTimer value is large for handover purposes.
NARは（HIとハック交換の結果として）NCOAをプロキシされた場合、UNA処理は、追加のステップ（下記参照）を有しています。 NARはNCOAをプロキシされていない場合（例えば、HI及びハッキング交換が行われていない）、次いでUNA処理は[RFC4861]で指定されたものと同じ手順に従います。デフォルトRetransTimer値は、ハンドオーバのために大きいことに注意しながら、実装は、[RFC4861]のセクション7.2.6に仕様にUNA対象を再送信することができます。
The Source Address in UNA MUST be the NCoA. The destination address is typically the all-nodes multicast address; however, some deployments may not prefer transmission to a multicast address. In such cases, the destination address SHOULD be the NAR's IP address.
UNAでの送信元アドレスはNCOAでなければなりません。宛先アドレスは、典型的には、全ノードマルチキャストアドレスです。しかし、いくつかの展開では、マルチキャストアドレスへの送信を好むかもしれません。このような場合には、宛先アドレスがNARのIPアドレスでなければなりません。
The Target Address MUST include the NCoA, and the Target link-layer address MUST include the MN's LLA.
ターゲットアドレスはMNのLLAを含まなければならないNCOA、およびターゲットのリンク層アドレスを含まなければなりません。
The MN sends an UNA message to the NAR, as soon as it regains connectivity on the new link. Arriving or buffered packets can be immediately forwarded. If the NAR is proxying the NCoA, it creates a neighbor cache entry in STALE state but forwards packets as it determines bidirectional reachability according to the standard Neighbor Discovery procedure. If there is an entry in INCOMPLETE state without a link-layer address, it sets it to STALE, again according to the procedure in [RFC4861].
MNは、すぐにそれが新しいリンクに接続性を取り戻すよう、NARにUNAメッセージを送信します。到着またはバッファされたパケットは、直ちに転送することができます。 NARはNCOAをプロキシされている場合、それが古い状態で近隣キャッシュエントリを作成し、それは、標準的な近隣探索手順に従って双方向の到達可能性を判断するようにパケットを転送します。リンク層アドレスを持たない不完全な状態にエントリがある場合は、再度[RFC4861]の手順に従って、STALEに設定します。
The NAR MAY wish to provide a different IP address to the MN than the one in the UNA message. In such a case, the NAR MUST delete the proxy entry for the NCoA and send a Router Advertisement with the NAACK option containing the new IP address.
NARはUNAメッセージ内の1つのよりMNに異なるIPアドレスを提供することを望むかもしれません。そのような場合には、NARはNCOAのプロキシエントリを削除しなければなりませんし、新しいIPアドレスを含むNAACKオプションでルータ通知を送信します。
The combination of the NCoA (present in source IP address) and the Link-Layer Address (present as a Target LLA) SHOULD be used to distinguish the MN from other nodes.
（送信元IPアドレスに存在する）NCOA及び（ターゲットLLAとして存在する）リンク層アドレスの組み合わせは、他のノードからMNを識別するために使用されるべきです。
All the options, with the exception of Binding Data Authorization for FMIPv6 (BADF) discussed in Section 6.5.4, use Type, Length, and Option-Code format shown in Figure 10.
セクション6.5.4で説明したFMIPv6とのデータ認可（BADF）を、結合を除くすべてのオプションは、図10に示すタイプ、長さ、及びオプションコードフォーマットを使用します。
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 [RFC3775]. And, Option-Code provides additional information for each of the options (see individual options below).
タイプ値は、近隣探索オプション空間から定義されています。 Lengthフィールドは、長さフィールド[RFC3775]でセクション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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Option Format
図10：オプションのフォーマット
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: IPv6 Address/Prefix Option
図11：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
4: NAR's Prefix, sent in PrRtAdv. 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.
Prefix Length: 8-bit unsigned integer that indicates the length of the IPv6 Address Prefix. The value ranges from 0 to 128.
プレフィックス長：IPv6アドレスプレフィックスの長さを示す8ビットの符号なし整数。値は0から128の範囲です。
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver.
予約：送信者によってゼロに設定しなければならなくて、受信機で無視しなければなりません。
IPv6 address: The IP address defined by the Option-Code field.
IPv6アドレス：オプション-Codeフィールドで定義された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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Link-Layer Address Option
図12：リンク層アドレスオプション
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 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
LLA: The variable length link-layer address.
LLA：可変長のリンク層アドレス。
The LLA option does not have a length field for the LLA itself. The implementations must consult the specific link layer over which the protocol is run in order to determine the content and length of the LLA.
LLAオプションは、LLA自体の長さフィールドを持っていません。実装は、プロトコルがLLAの内容と長さを決定するために実行され、その上、特定のリンク層に相談しなければなりません。
Depending on the size of 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 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, e.g., FBU. In the future, other Mobility Header messages may also make use of this option. The format of the option is shown in Figure 13. There are no alignment requirements for this option.
このオプションは、例えば、FBU LLAオプションと同じですが、モビリティヘッダのメッセージで運ばれます。将来的には、他のモビリティヘッダのメッセージも、このオプションを利用することができます。オプションのフォーマットは、このオプションには、アライメント要件はありません。図13に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Code | LLA ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Mobility Header Link-Layer Address Option
図13：モビリティヘッダリンク層アドレスオプション
Type: 7
タイプ：7
Length: The size of this option in octets not including the Type and Length fields.
長さ：タイプと長さフィールドを含めないオクテットでこのオプションのサイズ。
Option-Code: 2 Link-Layer Address of the MN.
オプション・コード：MNの2リンク層アドレス。
LLA: The variable length link-layer address.
LLA：可変長のリンク層アドレス。
This option MUST be present in FBU and FBack messages. The security association between the MN and the PAR is established by companion protocols [RFC5269]. This option specifies how to compute and verify a Message Authentication Code (MAC) using the established security association.
このオプションは、FBUとFBACKメッセージ中に存在しなければなりません。 MNとPARとの間のセキュリティアソシエーションは、コンパニオン・プロトコル[RFC5269]によって確立されます。このオプションは、確立されたセキュリティアソシエーションを使用してメッセージ認証コード（MAC）を計算し、検証する方法を指定します。
The format of this option is shown in Figure 14.
このオプションのフォーマットは図14に示されています。
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 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Binding Authorization Data for FMIPv6 (BADF) Option
図14：FMIPv6との権限データバインディング（BADF）オプション
Type: 21
タイプ：21
Option Length: The length of the Authenticator in bytes
オプションの長さ：バイト単位のオーセンティケータの長さ
SPI: Security Parameter Index. SPI = 0 is reserved for the Authenticator computed using SEND-based handover keys.
SPI：セキュリティパラメータインデックス。 SPI = 0は、送信ベースハンドオーバキーを使用して計算認証のために予約されています。
Authenticator: Same as in RFC 3775, with "correspondent" replaced by the PAR's IP address, and Kbm replaced by the shared key between the MN and the PAR.
オーセンティケータ：MNとPARの間で共有されたキーに置き換えPARのIPアドレスに置き換え、「特派員」、およびKbmを持つ、RFC 3775で同じ。
The default MAC calculation is done using HMAC_SHA1 with the first 96 bits used for the MAC. Since there is an Option Length field, implementations can use other algorithms such as HMAC_SHA256.
デフォルトMAC計算はMACに用いる第1の96ビットでHMAC_SHA1を用いて行われます。オプション長フィールドがあるので、実装は、HMAC_SHA256などの他のアルゴリズムを使用することができます。
This option MUST be the last Mobility Option present.
このオプションは、現在最後のモビリティのオプションでなければなりません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Neighbor Advertisement Acknowledgment Option
図15：近隣広告謝辞オプション
Type: 20
タイプ：20
Length: 8-bit unsigned integer. Length of the option, in 8 octets.
長さ：8ビットの符号なし整数。 8つのオクテット内のオプションの長さ。
The length is 1 when a new CoA is not supplied. The length is 3 when a new CoA is present (immediately following the Reserved field)
新たなCoAが供給されていないときの長さは1です。新たなCoAが存在するときに長さが（すぐに予約済みフィールド以下）3であります
Option-Code: 0
オプション・コード：0
Status: 8-bit unsigned integer indicating the disposition of the Unsolicited Neighbor Advertisement message. The following Status values are currently defined:
ステータス：迷惑近隣広告メッセージの配置を示す8ビットの符号なし整数。以下のステータス値が現在定義されています：
1: NCoA is invalid, perform address configuration
2: NCoA is invalid, use the supplied NCoA. The supplied NCoA
(in the form of an IP Address Option) MUST be present following
the Reserved field.
3: NCoA is invalid, use NAR's IP address as NCoA in FBU
4: PCoA supplied, do not send FBU
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 UNA with the NAACK option to notify the MN to use a different NCoA than the one that the MN has used. If the NAR proposes a different NCoA, the Router Advertisement MUST use the source IP address in the UNA message as the destination address, and use the L2 address present in UNA. The MN MUST use the NCoA if it is supplied with the NAACK option. If the NAACK indicates that the Link-Layer Address is unrecognized, for instance, if the MN uses an LLA valid on PAR's link but the same LLA is not valid on NAR's link due to a different access technology, the MN MUST NOT use the NCoA or the PCoA and SHOULD start immediately the process of acquiring a different NCoA at the NAR.
NARは、MNが使用したものとは異なるNCOAを使用するには、MNに通知するNAACKオプションでUNAに応答します。 NARは異なるNCOAを提案している場合、ルータ広告は、宛先アドレスとしてUNAメッセージの送信元IPアドレスを使用し、UNAにL2アドレス本を使用しなければなりません。それはNAACKオプションで提供されている場合は、MN NCOAを使用しなければなりません。 NAACKは、MNがPARのリンク上で有効なLLAを使用していますが、同じLLAが原因異なるアクセス技術にNARのリンク上で有効でない場合はリンク層アドレスは、例えば、認識されていないことを示している場合、MNはNCOAを使用してはなりませんまたはPCOAとすぐNARで異なるNCOAを取得する処理を開始する必要があります。
In the future, new option types may be defined.
将来的には、新しいオプションタイプを定義することができます。
The protocol specified here, as a design principle, introduces no or minimal changes to related protocols. For example, no changes to the base Mobile IPv6 protocol are needed in order to implement this protocol. Similarly, no changes to the IPv6 stateless address auto-configuration protocol [RFC4862] and DHCP [RFC3315] are introduced. The protocol specifies an optional extension to Neighbor Discovery [RFC4861] in which an access router may send a router advertisement as a response to the UNA message (see Section 6.4). Other than this extension, the specification does not modify Neighbor Discovery behavior (including the procedures performed when attached to the PAR and when attaching to the NAR).
ここで指定されたプロトコルは、設計原理として、関連プロトコルにないか、または最小限の変更を導入していません。例えば、ベースモバイルIPv6プロトコルへの変更は、このプロトコルを実装するために必要とされません。同様に、IPv6ステートレスアドレス自動設定プロトコル[RFC4862]とDHCP [RFC3315]への変更が導入されません。プロトコルは、アクセスルータは、UNAメッセージ（セクション6.4を参照）に対する応答として、ルータ広告を送信してもよいした近隣探索[RFC4861]に任意の拡張子を指定します。この拡張以外、仕様は（PARに結合した場合とNARに取り付ける際に行われる手順を含む）近隣探索の動作を変更しません。
The protocol does not require changes to any intermediate Layer 2 device between an MN and its access router that supports this specification. This includes the wireless access points, switches, snooping devices, and so on.
プロトコルは、この仕様をサポートしてMNとそのアクセスルータ間の任意の中間のレイヤ2デバイスへの変更を必要としません。これは、無線アクセスポイント、スイッチ、スヌーピングデバイスなどが含まれます。
This document has evolved from [RFC4068]. Specifically, a new handover key establishment protocol (see [RFC5269]) has been defined to enable a security association between a mobile node and its access router. This allows the secure update of the routing of packets during a handover. In the future, new specifications may be defined to establish such security associations depending on the particular deployment scenario.
この文書では、[RFC4068]から進化してきました。具体的には、新しいハンドオーバキー確立プロトコルは、移動ノードとアクセスルータ間のセキュリティアソシエーションを可能にするために定義されている（[RFC5269]を参照します）。これは、ハンドオーバ中にパケットのルーティングのセキュアな更新を可能にします。将来的には、新しい仕様は、特定の展開シナリオに応じて、このようなセキュリティアソシエーションを確立するように定義することができます。
The protocol has improved from the experiences in implementing [RFC4068], and from experimental usage. The input has improved the specification of parameter fields (such as lifetime, codepoints, etc.) as well as inclusion of new parameter fields in the existing messages. As of this writing, there are two publicly available implementations, [fmipv6] and [tarzan], and multiple proprietary implementations. Some experience suggests that the protocol meets the delay and packet loss requirements when used appropriately with particular radio access protocols. For instance, see [RFC5184] and [mip6-book]. Nevertheless, it is important to recognize that handover performance is a function of both IP layer operations, which this protocol specifies, and the particular radio access technology itself, which this protocol relies upon but does not modify.
プロトコルは、[RFC4068]を実装における経験から、および実験的使用から改善されています。入力は、（等寿命、コードポイント、など）パラメータフィールドの仕様ならびに既存のメッセージ内の新しいパラメータフィールドの包含を改善しました。これを書いているように、2つの公に利用可能な実装、[FMIPv6と]および[ターザン]、および複数の独自の実装が存在します。いくつかの経験は、特定の無線アクセスプロトコルと適切に使用される場合、プロトコルは、遅延やパケット損失要件を満たしていることを示唆しています。例えば、[RFC5184]と[MIP6-ブック]を参照してください。それにもかかわらず、そのハンドオーバー性能はこのプロトコルが依存しているが、変更されません。このプロトコルが指定するIPレイヤの操作、および特定の無線アクセス技術自体の両方の関数であり、認識することが重要です。
An existing implementation of [RFC4068] needs to be updated in order to support this specification. The primary addition is the establishment of a security association between an MN and its access router (i.e., MN and PAR). One way to establish such a security association is specified in [RFC5269]. An implementation that complies with the specification in this document is likely to also work with [RFC4068], except for the Binding Authorization Data for FMIPv6 option (see Section 6.5.4) that can only be processed when security association is in place between a mobile node and its access router. This specification deprecates the Fast Neighbor Advertisement (FNA) message. However, it is acceptable for a NAR to process this message from a mobile node as specified in [RFC4068].
[RFC4068]の既存の実装は、この仕様をサポートするために更新する必要があります。一次添加は、MNとそのアクセスルータ（すなわち、MNとPAR）の間のセキュリティ・アソシエーションの確立です。このようなセキュリティアソシエーションを確立するための一つの方法は、[RFC5269]で指定されています。このドキュメントでは仕様に準拠実装では、セキュリティアソシエーションは、モバイルとの間の所定の位置にあるときにのみ処理することができる（6.5.4項を参照）も、FMIPv6とオプションの結合認証データを除いて、[RFC4068]で動作する可能性がありますノードとそのアクセスルータ。この仕様は、高速近隣広告（FNA）メッセージを非難します。 [RFC4068]で指定されるようにNARは、モバイルノードがこのメッセージを処理するためしかし、それは許容されます。
Mobile nodes rely on configuration parameters shown in the table below. Each mobile node MUST have a configuration mechanism to adjust the parameters. Such a configuration mechanism may be either local (such as a command line interface) or based on central management of a number of mobile nodes.
モバイルノードは、以下の表に示す構成パラメータに依存しています。各モバイルノードはパラメータを調整する構成機構を持たなければなりません。このような構成の機構は、ローカル（例えば、コマンド・ライン・インターフェースなど）、またはモバイルノードの数の中央管理に基づいて、いずれであってもよいです。
+-------------------+---------------+---------------+
| Parameter Name | Default Value | Definition |
+-------------------+---------------+---------------+
| RTSOLPR_RETRIES | 3 | Section 6.1.1 |
| MAX_RTSOLPR_RATE | 3 | Section 6.1.1 |
| FBU_RETRIES | 3 | Section 6.3.1 |
| 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.
次のセキュリティ脆弱性が特定され、提案の解決策が記載されています。
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. 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 relies on a companion protocol [RFC5269] to establish such a security association. Using the shared handover key from [RFC5269], the Authenticator in BADF option (see Section 6.5.4) MUST be computed, and the BADF option included in FBU and FBack messages.
安全でないFBU：この場合には、一つのアドレスのために意味のパケットは、いくつかの疑いを持たないノードに盗まれたりリダイレクトすることができます。この懸念は、MNとホームエージェントとの関係と同じです。したがって、PARはFBUパケットが正当PCOAを所有するノードから到着したことを確認しなければなりません。アクセスルータとそのホストがFBUを保護するために使用されなければならないセキュリティアソシエーションを確立するために使用可能な任意のメカニズムを使用することができます。このプロトコルの現在のバージョンは、このようなセキュリティアソシエーションを確立するためのコンパニオンプロトコル[RFC5269]に依存しています。 [RFC5269]から共有ハンドオーバキーを使用して、BADFオプションでオーセンティケータ（セクション6.5.4を参照）が計算されなければならない、とBADFオプションがFBUとFBACKメッセージに含まれます。
Secure FBU, malicious or inadvertent redirection: in this case, the FBU is secured, but the target of binding happens to be an unsuspecting node either due to inadvertent operation or due to malicious intent. This vulnerability can lead to an MN with a genuine security association with its access router redirecting traffic to an incorrect address.
セキュア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. In order 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 UNA. Therefore, any inadvertent or malicious redirection to a host is avoided. It is still possible to jam a NAR's buffer with redirected traffic. However, since a NAR's handover state corresponding to an 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がアタッチして、UNAを通じて自分自身を発表するまで、すべての到着パケットがリンク上で送信されないように、それはNCOAをプロキシ。そのため、ホストへの不注意や悪意のあるリダイレクトが回避されます。リダイレクトされたトラフィックとNARのバッファをジャムすることも可能です。 NCOAに対応NARのハンドオーバ状態が予想ハンドオーバ待ち時間の小さな倍数に対応する有限の（及び短い）寿命を有しているので、この脆弱性の程度はおそらく小さいです。
Sending an FBU from a NAR's link: A malicious node may send an FBU from a NAR's link providing an unsuspecting node's address as an NCoA. This is similar to base Mobile IP where the MN can provide some other node's IP address as its CoA to its Home Agent; here the PAR acts like a "temporary Home Agent" having a security association with the Mobile Node and providing forwarding support for the handover traffic. As in base Mobile IP, this misdelivery is traceable to the MN that has a security association with the router. So, it is possible to isolate such an MN if it continues to misbehave. Similarly, an MN that has a security association with the PAR may provide the LLA of some other node on NAR's link, which can cause misdelivery of packets (meant for the NCoA) to an unsuspecting node. It is possible to trace the MN in this case as well.
NARのリンクからFBUを送信する：悪意のあるノードはNCOAとして疑うことを知らないノードのアドレスを提供するNARのリンクからFBUを送信することができます。これは、MNがそのホームエージェントにそのCoAとしていくつかの他のノードのIPアドレスを提供することができ、モバイルIPをベースに似ています。ここでのPARは「一時的なホームエージェント」は、モバイルノードとのセキュリティアソシエーションを有し、かつ、ハンドオーバトラフィックの転送のサポートを提供するように動作します。ベースのモバイルIPの場合と同様に、この誤配は、ルータとのセキュリティアソシエーションを持つMNにトレーサブルです。だから、不正な動作を継続した場合、そのようなMNを単離することが可能です。同様に、PARとのセキュリティアソシエーションを持っているMNは、疑うことを知らないノードに（NCOAのためのもの）パケットの誤配信が発生する可能性がありますNARのリンク上の他のノードのLLAを提供することができます。この場合にも、MNを追跡することが可能です。
Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv (Section 6.1.2) messages inherit the weaknesses of Neighbor Discovery protocol [RFC4861]. Specifically, when its access router is compromised, the MN's RtSolPr message may be answered by an attacker that provides a rogue router as the resolution. Should the MN attach to such a rogue router, its communication can be compromised. Similarly, a network-initiated PrRtAdv message (see Section 3.3) from an attacker could cause an MN to handover to a rogue router. Where these weaknesses are a concern, a solution such as Secure Neighbor Discovery (SEND) [RFC3971] SHOULD be considered.
上記とは別に、RtSolPrを（セクション6.1.1）と代理ルータ広告（セクション6.1.2）メッセージは、近隣探索プロトコル[RFC4861]の弱点を継承します。そのアクセスルータが危険にさらされたときに具体的には、MNのRtSolPrをメッセージには、解像度としてローグ・ルータを提供する攻撃者によって応答することができます。 MNは、このような不正なルータに接続する必要があり、その通信が損なわれる可能性があります。同様に、攻撃者からネットワーク開始代理ルータ広告メッセージは、（3.3節を参照）不正なルータへのハンドオーバにMNを引き起こす可能性があります。これらの弱点が懸念される場合、そのようなセキュア近隣探索（SEND）[RFC3971]のような解決策は、考慮されるべきです。
The protocol provides support for buffering packets during an MN's handover. This is done by securely exchanging the Handover Initiate (HI) and Handover Acknowledgment (HAck) messages in response to the FBU message from an MN. It is possible that an MN may fail, either inadvertently or purposely, to undergo handover to the NAR, which typically provides buffering support. This can cause the NAR to waste its memory containing the buffered packets, and in the worst case, could create resource exhaustion concerns. Hence, implementations must limit the size of the buffer as a local policy configuration, which may consider parameters such as the average handover delay, expected size of packets, and so on.
プロトコルは、MNのハンドオーバ時のバッファリングパケットのためのサポートを提供します。これは、確実にMNからFBUメッセージに応答してハンドオーバ開始（HI）及びハンドオーバ肯定応答（上記ハンドオフ）メッセージを交換することによって行われます。 MNは、典型的には、バッファリングサポートを提供NARにハンドオーバーを受けるように、いずれかの不注意または故意に、失敗する可能性があります。これは、NARは、バッファされたパケットを含むそのメモリを無駄にする可能性があり、最悪の場合には、資源枯渇の懸念を作成することができます。したがって、実装は、そのようなので、上の平均ハンドオーバ遅延、パケットの予想されるサイズ、などのパラメータを考慮することができるローカルポリシー構成、としてバッファのサイズを制限しなければなりません。
The Handover Initiate (HI) and Handover Acknowledgement (HAck) messages exchanged between the PAR and NAR MUST be protected using end-to-end security association(s) offering integrity and data origin authentication.
ハンドオーバは、（HI）開始し、ハンドオーバ肯定応答（上記ハンドオフ）メッセージをPARとNARとの間で交換完全性及びデータ発信元認証を提供し、エンドツーエンドのセキュリティアソシエーション（複数可）を使用して保護されなければなりません。
The PAR and the NAR MUST implement IPsec [RFC4301] for protecting the HI and HAck messages. IPsec Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. Confidentiality protection of these messages is not required.
PARとNARはHIと上記ハンドオフメッセージを保護するためにIPsec [RFC4301]を実装しなければなりません。 IPsecのカプセル化セキュリティペイロード（ESP）必須完全性保護とトランスポートモードでは、[RFC4303]はシグナリングメッセージを保護するために使用されるべきである（SHOULD）。これらのメッセージの機密性の保護が必要とされていません。
The security associations can be created by using either manual IPsec configuration or a dynamic key negotiation protocol such as Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306]. If IKEv2 is used, the PAR and the NAR can use any of the authentication mechanisms, as specified in RFC 4306, for mutual authentication. However, to ensure a baseline interoperability, the implementations MUST support shared secrets for mutual authentication. The following sections describe the Peer Authorization Database (PAD) and Security Policy Database (SPD) entries specified in [RFC4301] when IKEv2 is used for setting up the required IPsec security associations.
セキュリティアソシエーションは、手動IPsec構成やインターネット鍵交換プロトコルバージョン2（IKEv2の）[RFC4306]などの動的なキー交渉プロトコルのいずれかを使用して作成することができます。 IKEv2を使用する場合は、RFC 4306で指定されるように、PARとNARは、相互認証のために、認証メカニズムのいずれかを使用することができます。しかし、ベースラインの相互運用性を確保するために、実装は、相互認証のための共有秘密をサポートしなければなりません。次のセクションでは、ピア認証データベース（PAD）とIKEv2のが必要なのIPsecセキュリティアソシエーションを設定するために使用されている[RFC4301]で指定されたセキュリティポリシーデータベース（SPD）エントリを記述します。
This section describes PAD entries on the PAR and the NAR. The PAD entries are only example configurations. Note that the PAD is a logical concept and a particular PAR or NAR implementation can implement the PAD in any implementation specific manner. The PAD state may also be distributed across various databases in a specific implementation.
このセクションでは、PARとNARのパッドエントリについて説明します。 PADのエントリは、あくまでも一例の構成です。 PADが論理的な概念であり、特定のPARまたはNAR実装が任意の実装固有の方法でパッドを実装できることに注意してください。 PAD状態はまた、特定の実装に様々なデータベースに分散されてもよいです。
PAR PAD:
ポスト：
- IF remote_identity = nar_identity_1 THEN authenticate (shared secret/certificate/EAP) and authorize CHILD_SA for remote address nar_address_1
- remote_identity = nar_identity_1は、リモートアドレスnar_address_1ためCHILD_SAを（共有秘密キー/証明書/ EAP）の認証および承認IF
NAR PAD:
男性投稿：
- IF remote_identity = par_identity_1 THEN authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address par_address_1
- remote_identity = par_identity_1 THEN認証（共有秘密キー/証明書/ EAP）とリモートアドレスpar_address_1ためのCHILD_SAsを許可IF
The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD.
上記の例の認証メカニズムのリストは網羅的ではありません。パッド内に格納された認証のために使用される他の資格情報があるかもしれません。
This section describes the security policy entries on the PAR and the NAR required to protect the HI and HAck messages. The SPD entries are only example configurations. A particular PAR or NAR implementation could configure different SPD entries as long as they provide the required security.
このセクションでは、HIと上記ハンドオフメッセージを保護するために必要なPARとNARのセキュリティポリシーのエントリについて説明します。 SPDエントリは一例の構成です。特定のPARまたはNARの実装は、限り、彼らは、必要なセキュリティを提供するように異なるSPDエントリを設定することができます。
In the examples shown below, the identity of the PAR is assumed to be par_1, the address of the PAR is assumed to be par_address_1, and the address of the NAR is assumed to be nar_address_1.
以下に示す実施例では、PARのアイデンティティをpar_1であると仮定され、PARのアドレスがpar_address_1であると仮定され、そしてNARのアドレスがnar_address_1されているものとします。
PAR SPD-S:
SPD-S BY：
- IF local_address = par_address_1 & remote_address = nar_address_1 & proto = ICMPv6 & local_icmpv6_type = HI & remote_icmpv6_type = HAck THEN use SA ESP transport mode Initiate using IDi = par_1 to address nar_address_1
- IF local_address = par_address_1＆REMOTE_ADDRESS = nar_address_1＆プロト=のICMPv6＆local_icmpv6_type = HI＆remote_icmpv6_type =ハックTHEN nar_address_1に対処するためにIDiと= par_1を使用して開始SA ESPトランスポートモードを使用します
NAR SPD-S:
NAR SPD-S：
- IF local_address = nar_address_1 & remote_address = par_address_1 & proto = ICMPv6 & local_icmpv6_type = HAck & remote_icmpv6_type = HI THEN use SA ESP transport mode
- IF local_address = nar_address_1＆REMOTE_ADDRESS = par_address_1＆プロト=のICMPv6＆local_icmpv6_type =上記ハンドオフ＆remote_icmpv6_type = HI THEN SA ESPトランスポートモードを使用します
This document defines a new ICMPv6 message, which has been allocated from the ICMPv6 Type registry.
このドキュメントは、ICMPv6のタイプレジストリから割り当てられた新しいICMPv6メッセージを、定義されています。
154 FMIPv6 Messages
154件のFMIPv6とメッセージ
This document creates a new registry for the 'Subtype' field in the above ICMPv6 message, called the "FMIPv6 Message Types". IANA has assigned the following values.
この文書は、「FMIPv6とメッセージタイプ」と呼ばれる、上記のICMPv6メッセージの「サブタイプ」欄のための新しいレジストリを作成します。 IANAは、次の値を割り当てました。
+---------+-------------+---------------+
| 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 |
+---------+-------------+---------------+
The values '0' and '1' are reserved. The upper limit is 255. An RFC is required for new message assignment.
値「0」と「1」が予約されています。上限は、RFCは、新しいメッセージの割り当てのために必要とされる255です。
The document defines a new Mobility Option that has received Type assignment from the Mobility Options Type registry.
文書は、モビリティオプションタイプレジストリからタイプの割り当てを受けた新しいモビリティ・オプションを定義します。
1. Binding Authorization Data for FMIPv6 (BADF) option, described in Section 6.5.4
セクション6.5.4で説明1結合FMIPv6とするための認証データ（BADF）オプション
The document has received Type assignments for the following (see [RFC4068]):
文書には、次のタイプの割り当てを受けた（参照[RFC4068]）：
The document defines the following Neighbor Discovery [RFC4861] options that have received Type assignment from IANA.
文書は、IANAからのタイプの割当てを受けた次の近隣探索[RFC4861]オプションを定義します。
+---------+-----------------------------------------+---------------+
| Type | Description | Reference |
+---------+-----------------------------------------+---------------+
| 17 | IP Address/Prefix Option | Section 6.5.1 |
| 19 | Link-layer Address Option | Section 6.5.2 |
| 20 | Neighbor Advertisement Acknowledgment | Section 6.5.5 |
| | Option | |
+---------+-----------------------------------------+---------------+
The document defines the following Mobility Header messages that have received Type allocation from the Mobility Header Types registry.
文書には、モビリティヘッダタイプレジストリからタイプの割り当てを受けている、次のモビリティヘッダメッセージを定義します。
The document defines the following Mobility Option that has received Type assignment from the Mobility Options Type registry.
文書は、モビリティオプションタイプレジストリからタイプの割り当てを受けた次のモビリティ・オプションを定義します。
1. Mobility Header Link-Layer Address option, described in Section 6.5.3
6.5.3項で説明1.モビリティヘッダリンク層アドレスオプション、
The editor would like to thank all those who have provided feedback on this specification, but can only mention a few here: Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj Premec, Subba Reddy, K. Raghav, Ranjit Wable, and Jonathan Wood. Behcet Sarikaya and Frank Xia are acknowledged for the feedback on operation over point-to-point links. The editor would like to acknowledge a contribution from James Kempf to improve this specification. Vijay Devarapalli provided text for the security configuration between access routers in Section 10. Thanks to Jari Arkko for the detailed AD Review, which has improved this document. 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、Syam Madanapalli、Suvidhマートゥル、アンドレ・マーティン、ハビエル・マーティン、幸四郎三ツ矢、ガブリエルモンテネグロ、武小川、日鵬、YC鵬、アレックスペトレスク、Domagoj Premec、Subbaレディ、K.ラガフ、ランジットWable、とジョナサン・ウッド。ベーチェットSarikayaとフランク夏は、ポイントツーポイントリンク上での操作に関するフィードバックを認めています。編集者は、この仕様を改善するために、ジェームズケンプからの貢献を認めるしたいと思います。ビジェイDevarapalliは、セクションにアクセスルータ間でこの文書を改善した詳細なADの評価のためのヤリArkkoに感謝10をセキュリティ設定のためのテキストを提供します。エディタも感謝したい[mipshop]ワーキンググループの議長ガブリエルモンテネグロとかつての[モバイルIP]ワーキンググループは、この作品のために多くの支援を提供するためのBasavarajパティルとフィル・ロバーツの議長を務めます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5269] Kempf, J. and R. Koodli, "Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND)", RFC 5269, June 2008.
[RFC5269]ケンプ、J.及びR. Koodli、2008年6月、RFC 5269 "セキュア近隣探索を（SEND）を使用して対称高速モバイルIPv6（FMIPv6と）ハンドオーバキーの配布"。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、エド。、 "インターネット制御メッセージプロトコル（ICMPv6の）インターネットプロトコルバージョン6（IPv6）の仕様について"、RFC 4443、2006年3月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[fmipv6] "fmipv6.org : Home Page", <http://fmipv6.org>.
[FMIPv6と] "fmipv6.org：ホームページ"、<http://fmipv6.org>。
[mip6-book] Koodli, R. and C. Perkins, "Mobile Internetworking with IPv6, Chapter 22, John Wiley & Sons.", July 2007.
[MIP6-ブック] Koodli、R.とC.パーキンス、 "IPv6の、第22章、ジョン・ワイリー＆サンズとモバイルインターネットワーキング。"、2007年7月。
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.
[RFC3290] Bernet、Y.、ブレイク、S.、グロスマン、D.、およびA.スミス、 "Diffservのルータのための非公式の管理モデル"、RFC 3290、2002年5月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[RFC4068] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[RFC4068] Koodli、R.、エド。、 "モバイルIPv6のための高速ハンドオーバ"、RFC 4068、2005年7月。
[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover", RFC 5184, May 2008.
[RFC5184]寺岡、F.、午後、K.、三ツ矢、K.、渋井、R.、およびK.三谷、 "レイヤ3（L3）駆動型高速ハンドオーバの統合レイヤ2（L2）抽象"、RFC 5184 、2008年5月。
[tarzan] "Nautilus6 - Tarzan", <http://software.nautilus6.org/TARZAN/>.
[ターザン] "Nautilus6 - ターザン"、<http://software.nautilus6.org/TARZAN/>。
Appendix A. Contributors
付録A.協力者
This document has its origins in the fast handover design team in the erstwhile [mobile ip] working group. 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.
この文書では、かつての[モバイルIP]で高速ハンドオーバのデザインチームで、その起源ワーキンググループを持っています。アルファベット順に、この設計チームのメンバーでした。ゴパルDommety、カリム・エルMalki、モハメド・カリル、チャールズ・パーキンス、Heshamソリマン、ジョージ・Tsirtsis、及びアルパースYegin。
Appendix B. Changes since
付録B.からの変更点
Following are the major changes and clarifications:
主な変更点と説明は次のとおりです。
o Specified security association between the MN and its Access Router in the companion document [RFC5269].
Oコンパニオンドキュメント[RFC5269]でMNとアクセスルータ間でセキュリティアソシエーションを指定しました。
o Specified Binding Authorization Data for Fast Handovers (BADF) option to carry the security parameters used for verifying the authenticity of FBU and FBack messages. The handover key used for computing the Authenticator is specified in companion documents.
O FBUとFBACKメッセージの信憑性を検証するために使用されるセキュリティパラメータを運ぶために（BADF）オプションの高速ハンドオーバのための認証データをバインド指定。オーセンティケータを計算するために使用されるハンドオーバキーは、コンパニオン文書に指定されています。
o Specified the security configuration for inter - access router signaling (HI, HAck).
アクセスルータシグナリング（HI、HAck処理） - O間のセキュリティ設定を指定。
o Added a section on prefix management between access routers and illustrated protocol operation over point-to-point links.
Oポイントツーポイントリンクを介してアクセスルータ及び図示プロトコル動作の間プレフィックス管理上のセクションを追加しました。
o Deprecated FNA, which is a Mobility Header message. In its place, the Unsolicited Neighbor Advertisement (UNA) message from RFC 4861 is used.
モビリティヘッダのメッセージで推奨されないFNA、O。その代わりに、RFC 4861から迷惑近隣広告（UNA）メッセージが使用されます。
o Combined the IPv6 Address Option and IPv6 Prefix Option.
OのIPv6アドレスオプションとIPv6プレフィックスオプションを組み合わせます。
o Added description of DAD requirement on NAR when determining NCoA uniqueness in Section 4, "Protocol Details".
第4章、「プロトコルの詳細」でNCOAの一意性を決定する際にO NARにDADの要件の記述を追加しました。
o Added a new code value for gratuitous HAck message to trigger a HI message.
O HIメッセージをトリガするために無償ハックメッセージのための新しいコード値を追加しました。
o Added Option-Code 5 in PrRtAdv message to indicate NETLMM usage.
O代理ルータ広告メッセージに追加されたオプション・コード5はNETLMMの使用状況を示します。
o Clarified protocol usage when DHCP is used for NCoA formulation (Sections 6.1.2, 3.1, and 5.2). Added a new Code value (5) in PrRtAdv (Section 6.1.2).
DHCPはNCOA製剤（セクション6.1.2、3.1、5.2）のために使用されたときにOプロトコルの使用を明らかにしました。代理ルータ広告（6.1.2項）に新しいコード値（5）を追加しました。
o Clarified that IPv6 Neighbor Discovery operations are a must in Section 7, "Related Protocol and Device Considerations".
OのIPv6近隣探索操作はセクション7でなければならない「と関連プロトコルとデバイスの考慮事項」であることを明らかにしました。
o Clarified "PAR = temporary HA" for FBUs sent by a genuine MN to an unsuspecting CoA.
O疑うことを知らないのCoAに本物のMNによって送られFBUSは、「PAR =一時的なHA」を明らかにしました。
Editor's Address
編集者の住所
Rajeev Koodli Starent Networks USA
ネットワークラジーブKoodliスタレントUSA
EMail: rkoodli@starentnetworks.com
メールアドレス：rkoodli@starentnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。