[要約] RFC 5568は、Mobile IPv6における高速なハンドオーバーの実現を目指したものであり、モバイルデバイスの移動中に通信の中断を最小限に抑えることを目的としています。
Network Working Group R. Koodli, Ed.
Request for Comments: 5568 Starent Networks
Obsoletes: 5268 July 2009
Category: Standards Track
Mobile IPv6 Fast Handovers
モバイルIPv6高速ハンドオーバー
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手順（つまり、移動検出、新しいアドレスの構成、およびバインディングアップデート）に起因するこの「ハンドオーバーレイテンシ」は、Voice over IP（VoIP）などのリアルタイムトラフィックに容認できないことがよくあります。ハンドオーバーレイテンシを削減することは、非現実的なスループットに敏感なアプリケーションにとっても有益です。このドキュメントは、モバイルIPv6手順によりハンドオーバーレイテンシを改善するプロトコルを指定します。このドキュメントでは、リンクスイッチングレイテンシの改善に対応していません。
This document updates the packet formats for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages to the Mobility Header Type.
このドキュメントでは、モビリティヘッダータイプへのハンドオーバー開始（HI）およびハンドオーバー（ハック）メッセージのパケット形式を更新します。
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
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 ...............................................12
5. Other Considerations ...........................................16
5.1. Handover Capability Exchange ..............................16
5.2. Determining New Care-of Address ...........................16
5.3. Prefix Management .........................................17
5.4. Packet Loss ...............................................17
5.5. DAD Handling ..............................................19
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. New Mobility Header Messages ..............................26
6.2.1. Inter - Access Router Messages .....................26
6.2.2. Fast Binding Update (FBU) ..........................29
6.2.3. Fast Binding Acknowledgment (FBack) ................31
6.3. Unsolicited Neighbor Advertisement (UNA) ..................33
6.4. New Options ...............................................34
6.4.1. IP Address/Prefix Option ...........................34
6.4.2. Mobility Header IP Address/Prefix Option ...........35
6.4.3. Link-Layer Address (LLA) Option ....................36
6.4.4. Mobility Header Link-Layer Address (MH-LLA)
Option .............................................37
6.4.5. Binding Authorization Data for FMIPv6 (BADF) .......38
6.4.6. Neighbor Advertisement Acknowledgment (NAACK) ......39
7. Related Protocol and Device Considerations .....................40
8. Evolution from and Compatibility with RFC 4068 .................40
9. Configurable Parameters ........................................41
10. Security Considerations .......................................42
10.1. Peer Authorization Database Entries When Using IKEv2 .....44
10.2. Security Policy Database Entries .........................44
11. IANA Considerations ...........................................45
12. Acknowledgments ...............................................47
13. References ....................................................47
13.1. Normative References .....................................47
13.2. Informative References ...................................48
Appendix A. Contributors ..........................................50
Appendix B. Changes since RFC 5268 ................................50
Appendix C. Changes since RFC 4068 ................................50
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を対象としていますが、動きにもかかわらず通信を継続できるメカニズムとともに使用できます。最後に、この仕様では、集約プレフィックスを使用してノードのバルク移動に対処しません。
This document updates the protocol header format for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages defined in [RFC5268]. Both the Proxy Mobile IPv6 (PMIPv6) protocol [RFC5213] and the Mobile IPv6 protocol use Mobility Header (MH) as the type for carrying signaling related to route updates. Even though the Fast Handover protocol uses the Mobility Header for mobile node signaling purposes, it has used ICMP for inter - access router communication. Specifying Mobility Header for the HI and HAck messages enables deployment of the protocol alongside PMIP6 and MIP6 protocols; the reasons that led to this change are captured in Appendix B. Hence, this document specifies the Mobility Header formats for HI and HAck messages (Section 6.2.1) and the Mobility Header option format for the IPv6 Address/Prefix option (Section 6.4.2), and deprecates the use of ICMP for HI and HAck messages. Implementations of this specification MUST NOT send ICMPv6 HI and HAck messages as defined in
このドキュメントは、[RFC5268]で定義されているハンドオーバーイニシエート（HI）およびハンドオーバー（ハック）メッセージのプロトコルヘッダー形式を更新します。プロキシモバイルIPv6（PMIPV6）プロトコル[RFC5213]とモバイルIPv6プロトコルは、ルートの更新に関連するシグナル伝達を携帯するタイプとしてモビリティヘッダー（MH）を使用します。高速ハンドオーバープロトコルはモバイルノードシグナリングの目的でモビリティヘッダーを使用していますが、ICMPを使用してインターアクセスルーター通信を使用しています。HIおよびハックメッセージのモビリティヘッダーを指定すると、PMIP6およびMIP6プロトコルとともにプロトコルの展開が可能になります。この変更につながった理由は付録Bに記載されているため、このドキュメントは、HIおよびハックメッセージのモビリティヘッダー形式（セクション6.2.1）とIPv6アドレス/プレフィックスオプションのモビリティヘッダーオプション形式を指定します（セクション6.4。2）、HIおよびハッキングメッセージにICMPの使用を非難します。この仕様の実装は、icmpv6 hiおよびハッキングメッセージを送信してはなりません。
[RFC5268]. If implementations of this specification receive ICMPv6 HI and HAck messages as defined in [RFC5268], they MAY interpret the messages as defined in [RFC5268].
[RFC5268]。この仕様の実装が[RFC5268]で定義されているICMPv6 HIおよびハックメッセージを受信した場合、[RFC5268]で定義されているメッセージを解釈する場合があります。
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.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [RFC2119]に記載されているように解釈される。「Silently Ingrore」という用語の使用は、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.
アクセスルーター（AR）：MNのデフォルトルーター。
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.
New Access Router（NAR）：ハンドオーバー後のMNの予想されるデフォルトルーター。
Previous CoA (PCoA): The MN's Care-of Address valid on PAR's subnet.
以前のCOA（PCOA）：PARのサブネットで有効なMNのケアアドレス。
New CoA (NCoA): The MN's Care-of Address valid on NAR's subnet.
New COA（NCOA）：NARのサブネットで有効なMNのケアアドレス。
Handover: A process of terminating existing connectivity and obtaining new IP connectivity.
ハンドオーバー：既存の接続を終了し、新しいIP接続を取得するプロセス。
Router Solicitation for Proxy Advertisement (RtSolPr): A message from the MN to the PAR requesting information for a potential handover.
Router Solicitation for Proxy Advertisement（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.
プロキシルーター広告（PRRTADV）：PARからMNへのメッセージは、迅速な動きの検出を促進する隣接するリンクに関する情報を提供します。メッセージは、ネットワークが開始するハンドオーバーのトリガーとして機能することもあります。
[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 also Section 5.3.
[AP-ID、AR-INFO] TUPLE：アクセスルーターのL2アドレスとIPアドレスが含まれており、アクセスポイント（AP-IDで識別）が添付されているインターフェイスに有効なプレフィックスが含まれています。トリプレット[ルーターのL2アドレス、ルーターのIPアドレス、プレフィックス]は「AR-INFO」と呼ばれます。セクション5.3も参照してください。
Neighborhood Discovery: The process of resolving neighborhood AP-IDs to AR-Info.
近隣の発見：近隣のAP-IDをAR-IDに解決するプロセス。
Assigned Addressing: A particular type of NCoA configuration in which the NAR assigns an IPv6 address for the MN. The method by which the 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).
高速バインディングアップデート（FBU）：MNからのメッセージがPARに指示し、トラフィック（NARに向かって）をリダイレクトするように指示します。
Fast Binding Acknowledgment (FBack): A message from the PAR in response to an FBU.
高速バインディング承認（FBACK）：FBUに応じたPARからのメッセージ。
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がPARに取り付けられたときにFBUを送信できる高速ハンドオーバーで、その後、交通の転送を確立します（MNがNARに付着する前であっても）。
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 '' bitがクリアされた[rfc4861]のメッセージ。
Fast Neighbor Advertisement (FNA): This message from RFC 4068 [RFC4068] is deprecated. The UNA message above is the preferred message in this specification.
Fast Neighbor Advertisement（FNA）：RFC 4068 [RFC4068]からのこのメッセージは非推奨です。上記のUNAメッセージは、この仕様の優先メッセージです。
Handover Initiate (HI): A message from the PAR to the NAR regarding an MN's handover.
ハンドオーバーイニシエート（HI）：MNのハンドオーバーに関するPARからNARへのメッセージ。
Handover Acknowledge (HAck): A message from the NAR to the PAR as a response to HI.
ハンドオーバー謝辞（ハック）：HIへの応答としてのNARからPARへのメッセージ。
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.
新しいサブネットリンクからパケットをすぐに送信する機能は、「IP接続」のレイテンシに依存します。これは、移動検出レイテンシと新しいCOA構成遅延に依存します。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 a 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 an [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は、ルーターの発見を実行した後、または現在のルーターに接続している間、いつでもこれを行うことがあります。アクセスポイントに関連付けられた識別子を解決した結果は、[AP-ID、AR-INFO]タプルであり、MNは動きを容易に検出できることです。AP-IDを使用してアクセスポイントに添付されると、MNは、プレフィックス、IPアドレス、L2アドレスを含む対応する新しいルーターの座標を知っています。セクション6.1の「プロキシ広告（RTSOLPR）のルーター勧誘（RTSOLPR）」および「プロキシルーター広告（PRRTADV）」メッセージは、動きの検出を支援するために使用されます。
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.2.3) 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.
RTSOLPRおよびPRRTADVメッセージを介して、MNは、PARのリンクにまだ存在する場合に、前向きな新しいCOA（NCOA）も定式化します。したがって、ハンドオーバー後の新しいプレフィックスの発見によるレイテンシは排除されます。さらに、MNが「高速拘束力のある承認（FBACK）」を受け取ったときに、この見込みのある住所は、新しいサブネットリンク（つまり、NARのリンク）に接続した直後に使用できます（その動き前の「セクション6.2.3を参照）メッセージ。Fbackを受信せずに移動した場合でも、MNは、未承諾のNeighbor広告メッセージ（ '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.
PRRTADVメッセージで提供される情報は、DHCP [RFC3315]を使用してNARのリンクでNCOAを構成する場合でも使用できます。この場合、プロトコルはPCOAを使用した転送をサポートし、MNはNARのリンクに接続すると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.2.2) 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.4.5) 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 the 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.2.2を参照）メッセージを以前のアクセスルーターに送信して、このトンネルを確立します。実行可能な場合、MNはPARのリンクからFBUを送信する必要があります。それ以外の場合、MNはNARへの付着を検出した直後にFBUを送信する必要があります。FBUメッセージには、PCOAを所有する正当なMNのみがバインディングを確立できることを確認するために、FMIPv6（BADF）オプションのバインディング認証データを含める必要があります（セクション6.4.5を参照）。後続のセクションでは、プロトコルメカニズムについて説明します。いずれにせよ、PARはPCOAにNCOAに到着するトンネリングパケットを開始します。このようなトンネルは、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が新しいサブネットリンクに取り付けられたらすぐにパケットを受信することは保証されません。隣人のアドレス解決（つまり、隣人の勧誘と隣人の広告）を含む隣人の発見操作は、通常、かなりの遅延をもたらし、時には数秒続くこともあります。たとえば、到着するパケットがNARをトリガーしてMNが付着する前に近隣勧誘を送信すると、その後のアドレス解像度の再送信は、それぞれ1秒のデフォルト期間によって分離されます。この遅延を回避するために、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 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.1). 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.
プロトコルは、次の重要な機能も提供します。アクセスルーターはメッセージを交換して、提案されたNCOAが許容できることを確認できます。たとえば、MNがPARのリンクからFBUを送信すると、NARがNCOAを使用することができると考えると、FBAUを配信できます。これは、アドレスがアクセスルーターによって割り当てられる場合に特に便利です。NARは、MNの転送サポートを提供する前に、PARとの信頼関係に依存することもできます。つまり、NCOAの転送エントリを作成する可能性があります。これは、PARからの「承認」の対象となります。さらに、NARでのハンドオーバートラフィックのバッファリングが望ましい場合があります。Neighbor Discoveryプロトコルは、アドレス解像度を待っているパケットに小さなバッファ（通常1つまたは2つのパケット）を提供しますが、このバッファーはVoIPなどのトラフィックに不十分である可能性があります。ルーターは、ハンドオーバートラフィックにサービスを提供するための個別のバッファーを維持することもできます。最後に、アクセスルーターは、ハンドオーバーと組み合わせて、アクセス制御、サービス品質（QOS）、ヘッダー圧縮などのネットワーク居住コンテキストを転送できます（ただし、コンテキスト転送プロセス自体はこのドキュメントでは指定されていません）。これらすべての操作について、プロトコルは「ハンドオーバーイニシエート（HI）」および「ハンドオーバー確認（ハック）」メッセージを提供します（セクション6.2.1を参照）。これらのメッセージはどちらも使用する必要があります。アクセスルーターは、このドキュメントの範囲外の手段によって必要なセキュリティ協会を確立する必要があります。
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つ以上のアクセスポイント識別子をサブネット固有の情報に解決するときに始まります。これに応じて、アクセスルーター（図1のPAR）は、1つ以上の[AP-ID、AR-INFO]タプルを含むPRRTADVメッセージを送信します。MNは、リンク固有のイベント（「トリガー」）への応答として、または単にルーターの発見を実行した後、いつでも都合の良い時間にRTSOLPRを送信する場合があります。ただし、RTSOLPRを送信する前に、MNはリンク固有の方法で利用可能なAPを発見することを期待しています。RTSOLPRおよびPRRTADVメッセージは、アクセスルーターの状態を確立しません。それらのパケット形式は、セクション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.
PRRTADVメッセージに記載されている情報を使用して、MNは将来のNCOAを策定し、FBUメッセージをPARに送信します。FBUの目的は、PARがPCOAをNCOAにバインドすることを許可することです。そうすれば、到着するパケットをMNの新しい場所にトンネル化できます。FBUは、実行可能なときはいつでもパーのリンクから送信する必要があります。たとえば、内部リンク固有のトリガーは、前のリンクから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.2.2. The FBU message MUST contain the BADF option (see Section 6.4.5) to secure the message.
FBU処理の形式とセマンティクスは、セクション6.2.2で指定されています。FBUメッセージには、メッセージを保護するには、BADFオプション（セクション6.4.5を参照）を含める必要があります。
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を受け取ります。これは、MN HandoversがNARに到達するまでに、パケットトンネリングがすでに進行中であることを意味します。MNは、NARに接続した直後にUNAを送信する必要があります。そうすれば、到着とバッファーパケットをすぐにMNに転送できます。MNにFBACKを送信する前に、PARは、HIとハックメッセージの交換を通じてNARにNARに受け入れられるかどうかを判断できます。アドレス指定（つまり、アドレスがルーターによって割り当てられます）が使用されると、FBUで提案されているNCOAがHIメッセージ（PARからNARまで）に運ばれ、NARは提案されたNCOAを割り当てることができます。このような割り当てられたNCOAは（NARからPARまで）ハックで返品する必要があり、PARは順番に割り当てられたNCOAをFBACKで提供する必要があります。割り当てられた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 the "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.3.
2. MNはFBUを送信していないか、MNがFBU（それ自体が失われる可能性がある）を送信した後ではなく、FBACを受信する前にリンクを離れたため、MNは前のリンクでFBACKを受け取りません。後者の場合にFBACKを受け取らずに、MNはPARがFBUを正常に処理したかどうかを確認することはできません。したがって、MN（RE）はUNAメッセージを送信した直後にFBUメッセージをPARに送信します。NARがNCOAとは異なるIPアドレスを使用することを選択した場合、MNが使用する代替IPアドレスが含まれる「Neighbor Advertisement Aumponledy（NAACK）」オプションでルーター広告を送信する場合があります。詳細なUNA処理ルールは、セクション6.3で指定されています。
The scenario in which an MN sends an FBU and receives an FBack on PAR's link is illustrated in Figure 2. For convenience, this scenario is characterized as 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のリンクでFBACを受信するシナリオを図2に示します。便利なため、このシナリオは「予測」動作モードとして特徴付けられます。MNがNARのリンクからFBUを送信するシナリオを図3に示します。利便性のために、このシナリオは「反応的」動作モードとして特徴付けられます。反応モードには、PARのリンクからFBUが送信されたが、FBACがまだ受信されていない場合も含まれています。この図は、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.
最後に、PRRTADVメッセージは未承諾、つまりMNが最初にRTSOLPRを送信することなく送信される場合があります。このモードは、セクション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は、ネットワークがハンドオーバーが差し迫っていると判断したときに、NARのリンク層アドレス、IPアドレス、およびサブネットプレフィックスを含む未承諾PRRTADVを送信できます。MNは、このPRRTADVを処理して新しいサブネットで新しいアドレスを構成する必要があり、新しいリンクに切り替える前にFBUをPARに送信する必要があります。PRRTADVを送信した後、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.
また、未承諾のPRRTADVにより、ネットワークは、MNがその情報を明示的に要求する必要なく、地理的に隣接するサブネットについてMNに通知することができます。これにより、MNがリンクとサブネットの近隣トポロジマップを取得するために必要なワイヤレストラフィックの量を減らすことができます。このようなPRRTADVの使用は、実際のハンドオーバーから切り離されています。セクション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.
1つ以上の近くのアクセスポイントを発見した後、MNはRTSOLPRをPARに送信して、サブネットルーター情報にアクセスポイント識別子を解決します。これを行うのに便利な時間は、ルーターの発見を行った後です。ただし、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メッセージには、1つ以上のAP-IDが含まれています。ワイルドカードは、利用可能なすべてのタプルを要求します。
As a response to RtSolPr, the PAR sends a PrRtAdv message that indicates one of the following possible conditions.
RTSOLPRへの応答として、PARは、次の可能な条件のいずれかを示すPRRTADVメッセージを送信します。
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 the 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.
2. 新しいアクセスポイントがPARの現在のインターフェイス（MNが添付されている）に接続されている場合、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).
4. ワイルドカードが新しいアクセスポイントの識別子として供給されている場合、PARはPATH MTU制限の対象となる近隣[AP-ID、AR-INFO]タプルを提供する必要があります（つまり、リンクMTUを超えることなく 'n'タプルを提供します）。
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で着信パケットのコピーのバッファリングを開始することを選択する場合があります。最初のOut（FIFO）バッファリングで最初に使用される場合、PARはパケットをPCOA（つまり、バッファとフォワード）に転送し続ける必要があります。プロトコルはそのような実装サポートを禁止していませんが、PARがパケットをPCOAに転送し続けるように注意する必要があります（つまり、バッファーとフォワードアプローチを使用します）。PARは、NCOAへのパケットの転送を開始すると、バッファリングを停止する必要があります。
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およびPRRTADVメッセージは、MNおよび高速の携帯電話をサポートするアクセスルーターによって実装する必要があります。ただし、MNがNARに接続するとすぐにパケットを送信するために必要なパラメーターがリンク層ハンドオーバーメカニズム自体によって提供される場合、上記のメッセージの使用はそのようなリンクでオプションです。
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 a 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.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.1.
PRRTADVメッセージが処理された後、MNはリンク固有のイベントによって決定される時間にFBUを送信し、提案されたNCOAを含みます。MNは、ハンドオーバーの「予想」が実行可能な場合はいつでも、PARのリンクからFBUを送信する必要があります。予想が実行不可能な場合、またはFBACKを受け取っていない場合、MNはNARのリンクに接続した直後にFBUを送信します。FBUに応じて、PARはPCOA（「ホームアドレス」）とNCOAの間に結合を確立し、FBACKをMNに送信します。このバインディングを確立する前に、PARはNARにHIメッセージを送信し、それに応じてハックを受信する必要があります。HIメッセージのNARのアドレスを決定するために、PARは、隣接するアクセスルーターのプレフィックスリストを使用して、NCOA（FBU）の最長のプレフィックスマッチを実行できます。FBUのソースIPアドレスがPCOAである場合、つまりFBUがPARのリンクから送信される場合、HIメッセージには0に設定されたコード値が必要です。セクション6.2.1.1を参照してください。FBUのソースIPアドレスがPCOAではない場合、つまりFBUがNARのリンクから送信される場合、HIメッセージにはコード値が1の必要があります。セクション6.2.1.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: 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.
HIメッセージには、MNのPCOA、リンクレイヤーアドレス、NCOAが含まれています。コード0でHIメッセージを処理することに応じて、NAR：1。HIメッセージで提供されたNCOAが防御を開始する前に一意であるかどうかを判断します。NCOA用の重複したアドレス検出（DAD）プローブ[RFC4862]を送信して、一意性を検証します。ただし、アドレス衝突の確率が非常に低い（したがって問題ではない）と見なされる展開では、パラメーターのdupaddrdeTecttransmits（[rfc4862]を参照）がNARでゼロに設定されており、NCOAでパパの実行を避けることができます。同様に、NARは、父親が心配していない他の展開では、dupaddrdeTecttransmitsをゼロに設定します。NCOAが一意であると判断されると、NARは、MNがNARに接続すると予想されるproxy_nd_lifetimeのアドレスをプロキシ[rfc4861]のプロキシを開始します。データ構造に既にNCOAが存在する場合（たとえば、以前はHIメッセージをすでに処理しています）、NARはLLAが独自のものと同じかMN自体と同じかどうかを確認できます。その場合、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は、HIで提案されているNCOAを割り当てる場合があります。
3. MAY create a host route entry for the PCoA (on the interface to which the MN is attaching) 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.
3. NCOAを受け入れたり割り当てられたりできない場合に備えて、PCOAのホストルートエントリ（MNが付着しているインターフェイスに）を作成する場合があります。このホストルートエントリは、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に対して作成されるNeighbor Cacheエントリを検証できます。つまり、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 the 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がMNのパケットをNCOAにトンネル化し始めたことです。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.3). 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. UNAメッセージを送信します（セクション6.3を参照）。MNがUNAが送信されるまでにFBACKを受信していない場合、UNAメッセージに従ってFBUメッセージを送信する必要があります。
2. joins the all-nodes multicast group and the solicited-node multicast group corresponding to the NCoA.
2. NCOAに対応するAll-NodesマルチキャストグループとSolicited-Nodeマルチキャストグループに参加します。
3. starts a DAD probe for NCoA; see [RFC4862].
3. NCOAのお父さんプローブを開始します。[RFC4862]を参照してください。
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. 存在する場合、プロキシネイバーキャッシュエントリを削除し、状態を古く[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が以前に隣人の勧誘を送信した場合に当てはまります。
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.4.6.
MNがNAACKオプションでIPアドレスを受信した場合、それを使用して新しいCOAを使用してFBUを送信する必要があります。特別なケースとして、NAACKで提供される住所はPCOA自体である可能性があります。その場合、MNはこれ以上FBUを送信してはなりません。NAACKオプションのステータスコードは、セクション6.4.6で指定されています。
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 the MN's neighbors to update their neighbor cache entries.
MNがNCOAを確認したら（お父さんを介して、またはNARが提供する場合）、「O」ビットセットで近隣の広告メッセージを、All-Nodesマルチキャストアドレスに送信する必要があります。このメッセージを使用すると、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.
データ転送の場合、MNが添付されているインターフェイスで有効なグローバルIPアドレスを使用して、PAR Tunnelsパケットを使用します。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メッセージに応じてPRRTADVを期待しています。MNがRTSOLPR_RETRIESの後でもPRRTADVメッセージを受信しない場合、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 Code 3 (see Section 6.1.2).
MNの現在のアクセスルーターが迅速なハンドオーバーサポートを提供できる場合でも、MNが取り付けた新しいアクセスルーターは、迅速なハンドオーバーができない場合があります。これは、コード3を使用したPRRTADVメッセージを介して、「ランタイム」中のMNに示されます（セクション6.1.2を参照）。
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 the HAck, the PAR MUST include it in the FBack message. However, the MN itself does not have to wait on the 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 the NCoA from the NAR's link by sending the UNA message.
通常、MNは、PRRTADVメッセージで提供された情報を使用して、FBUを送信して、将来のNCOAを策定します。PARは、FBUに存在するNCOAをHIメッセージで使用する必要があります。NARは、HIに存在するNCOAがすでに使用されているかどうかを確認する必要があります。いずれにせよ、NARはハックを使用してHIに応答する必要があります。この場合、特に割り当てられたアドレス構成が使用される場合、使用する別のNCOAが含まれる場合があります。ハックに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.
PRRTADVメッセージにNCOAが搭載されている場合、MNはそれを将来のNCOAとして使用する必要があります。
When DHCP is used, the protocol supports forwarding for the 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の転送のみをサポートします。この場合、MNは、FBUを送信するためにNCOAを定式化する場合でも、NARに付着するとDHCP操作を実行する必要があります。これは、コード5のPRRTADVメッセージに示されています。
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, its length, or its 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-INFO」のプレフィックス部分は、APが接続されているインターフェイスで有効なプレフィックスです。このドキュメントでは、このプレフィックスの管理方法、その長さ、または割り当てポリシーを指定しません。このドキュメントで指定されたプロトコル操作は、これらの考慮事項に関係なく機能します。多くの場合、必ずしも常にではありませんが、このプレフィックスは、インターフェイスで有効な集計プレフィックス（ /48など）である可能性があります。いくつかの展開では、各MNには、NCOAの生成に使用される独自のモバイルごとのプレフィックス（A /64など）がある場合があります。一部のポイントツーポイントリンクは、このような展開を使用する場合があります。
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.
モバイルごとのプレフィックス割り当てが使用される場合、PRRTADVで宣伝されている「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 a request for buffering at the NAR in the HI message. When the PAR requests this feature (for the MN), it SHOULD also provide its own support for buffering.
ハンドオーバーには、リンクスイッチングが含まれます。これは、高速ハンドオーバーシグナル伝達と正確に調整されない場合があります。さらに、パケットの到着パターンは、アプリケーションの特性、ネットワークキューイングの動作などを含む多くの要因に依存しています。したがって、MNがそこにリンクを確立できる前に、パケットがNARに到着する場合があります。これらのパケットは、NARによってバッファリングされない限り失われます。同様に、MNがNARに接続してからFBUメッセージを送信すると、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 一部のアプリケーションは、特定のデータを他のデータよりも少ないデータを送信します。これは、さまざまなバッファリング要件を意味します。たとえば、Voice over 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 モバイルノードが新しいリンクに表示されると、バッファリングルーターが多数のパケットを迅速に連続して送信すると、ルーター、モバイルノード自体、またはこれら2つの間のパスを締めすぎる可能性があります。
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]).
ステートレスアドレスの自動構成が使用されている場合のリンクのアドレスの重複を避けるために、[RFC4862]で複製アドレス検出（DAD）が定義されました。Stateless Auto Configurationで構成されたIPv6アドレスの一意性を検証するためにDADを使用すると、ハンドオーバーが遅延が追加されます。同じサブネットでの界面識別子の重複の確率は非常に低いです。ただし、無視することはできません。したがって、このドキュメントで指定されているプロトコルは、そのようなアドレス衝突の確率が非常に低いか、それが懸念事項ではない展開でのみ使用する必要があります（アドレス管理手順のため）。プロトコルでは、NARがNCOAの防御を開始する前にDADプローブを送信する必要があります。ただし、このお父さんの遅延は、dupaddrddetecttransmitsをNARでゼロに設定することでオフにすることができます（[RFC4862]）。
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.1.2) or in the NAACK option (see Section 6.4.6).
このドキュメントは、複製なしのアドレスを提供するために使用できるメッセージを指定しますが、ドキュメントでは、このような複製なしのアドレスを作成または管理する方法を指定していません。場合によっては、NARは、MNが新しいサブネットに移動する前に、MNのアドレスが重複しているかどうかを評価するために必要な知識をすでに持っている場合があります。たとえば、一部の展開では、NARは、ハンドオーバーの目的でリストに重複のないアドレスのプールを維持する場合があります。そのような場合、NARはこの処分をハックメッセージ（セクション6.2.1.2を参照）またはNAACKオプション（セクション6.4.6を参照）で提供できます。
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がどれだけ速く移動できるかという点で制限されています。速い動きの特別なケースはPing-Pongで、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 correspondent node (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 a few seconds) may start losing packets. The signaling cost over the air interface and in the network may increase significantly, especially in the case of rapid movement between several access routers. To avoid the signaling overhead, the following measures are suggested.
ただし、IPレイヤーモビリティは独自の制限を導入します。IP層の拳銃は、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に等しいホームアドレスで高速バインディングアップデートを送信し、寿命はゼロに額を送信する必要があります。MNは、NARへの迅速なハンドオーバーを実行したため、PARとセキュリティ関連を持つ必要があります。PARは、この高速バインディングアップデートを受信すると、発信（一時的な高速ハンドオーバー）トンネルのセットを確認します。一致が見つかった場合、そのトンネルを終了する必要があります。つまり、代わりにノードに直接パケットの配信を開始します。PARがそのようなFBUを処理するためには、セキュリティ協会の寿命は少なくともトンネル自体の寿命でなければなりません。
Temporary tunnels for the purposes of fast handovers should use short lifetimes (of the order of tens of seconds). 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.
誤った動きの効果は、通常、ルーティングが変更され、PARがMNが実際にそのルーターに接続する前にパケットを別のルーターに向けることができるため、パケットの損失に限定されます。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 messages in order to prompt routers for Proxy Router Advertisements. All the Link-Layer Address options have the format defined in Section 6.4.3.
モバイルノードは、プロキシルーター広告のルーターをプロンプトするために、プロキシ広告メッセージのルーター勧誘を送信します。すべてのリンク層アドレスオプションには、セクション6.4.3で定義された形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
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オプションを含めることで、受信者が送信者のL2アドレスを記録できるため、レシーバーが（RTSOLPRメッセージの）送信者にパケットを送信する必要がある場合に近隣発見を回避できます。
When a wildcard is used for the 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がプロキシルーター広告（PRRTADV）メッセージを受信する必要があります。そのようなメッセージがタイムリーに受信されていない場合（アクセスリンクの2倍の典型的な往復時間（RTT）、またはRTTが不明な場合は100ミリ秒）、RTSOLPRメッセージを再送信する必要があります。その後の再送信はRTSOLPR_RETRIESまでのものになる可能性がありますが、再送信の各インスタンスの前にタイムアウト期間（つまり、2XRTTまたは100ミリ秒）が2倍になる指数関数的なバックオフを使用する必要があります。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.
アクセスルーターは、ハンドオーバーがネットワーク開始されている場合、またはMNからのRTSOLPRメッセージへの応答として、プロキシルーター広告メッセージを無償で送信し、隣接するルーターのリンク層アドレス、IPアドレス、およびサブネットプレフィックスを提供します。すべてのリンク層アドレスオプションには、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：プロキシルーター広告（PRRTADV）メッセージ
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 the Router Solicitation for Proxy Advertisement or set to zero if unsolicited.
識別子：プロキシ広告のルーター勧誘からコピーするか、未承諾の場合はゼロに設定します。
Valid Options in the following order:
次の順序で有効なオプション：
Source Link-Layer Address: When known, the link-layer address of the sender SHOULD be included using the Link-Layer Address option. See the LLA option format below.
ソースリンク層アドレス：既知の場合、送信者のリンク層アドレスをリンク層アドレスオプションを使用して含める必要があります。以下のLLAオプション形式を参照してください。
New Access Point Link-Layer Address: The link-layer address or identification of the access point is copied from RtSolPr message. This option MUST be present.
新しいアクセスポイントリンク層アドレス：リンク層アドレスまたはアクセスポイントの識別は、RTSOLPRメッセージからコピーされます。このオプションは存在する必要があります。
New Router's Link-Layer Address: The link-layer address of the access router for which this message is proxied. This option MUST be included when 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 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.
新しいルータープレフィックス情報オプションオプション：アクセスルーターのプレフィックスを指定します。メッセージがプロにされ、アドレスの自動構成に使用されます。このオプションは、コードが0または1の場合は含める必要があります。ただし、このプレフィックスが新しいルーターのIPアドレスオプション（上記）で使用されているものと同じ場合、プレフィックス情報オプションは存在する必要はありません。
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オプション：PRRTADVが未承諾の送信されたときに存在する場合があります。PARは、NARのプレフィックス情報とMNのL2アドレスを使用して、または他の手段で新しいCOAを計算する場合があります。
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. In this case, the Option-Code field in the New Access Point LLA option is 1 to reflect 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] Tuple（上記のオプションに存在する）を使用する必要があることを意味します。この場合、新しいアクセスポイントLLAオプションのオプションコードフィールドは、残りのオプションが関連しているアクセスポイントの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. In this case, the Option-Code field in the New Access Point LLA option (see below) is 1 to reflect the LLA of the access point for which the rest of the options are related.
コード1を使用したプロキシルーター広告は、メッセージが未承諾で送信されたことを意味します。新しいルータープレフィックス情報オプションに従って新しいCOAオプションが存在する場合、MNは付属のNCOAを使用してすぐにFBUを送信するか、サービスを失うためにスタンドを送信する必要があります。このメッセージは、ネットワーク開始のハンドオーバートリガーとして機能します。セクション3.3を参照してください。この場合、新しいアクセスポイントLLAオプションのオプションコードフィールド（以下を参照）は、残りのオプションが関連しているアクセスポイントの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.
新しいアクセスポイントLLAオプションのオプションコードフィールドが5の場合、そのアクセスポイントへのハンドオーバーはCOAの変更を必要としません。たとえば、多くのアクセスポイントが同じルーターインターフェイスに接続されている場合、またはネットワークベースのモビリティ管理メカニズムが、特定のモバイルノードが個別のルーターがあるかどうかに関係なく常に同じプレフィックスを観察することを保証する場合に当てはまります。ターゲットアクセスポイントに添付されています。
No other options are required in this case.
この場合、他のオプションは必要ありません。
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オプションのオプションコードフィールドが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オプションのオプションコードフィールドが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 (those defined above, as well as the 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.
WildCard AP識別子がRTSOLPRメッセージに提供される場合、PRRTADVメッセージには、PARの近隣に対応する「n」[アクセスポイント識別子、リンクレイヤーアドレスオプション、プレフィックス情報オプション]タプルを含める必要があります。
Mobile IPv6 uses a new IPv6 header type called Mobility Header [RFC3775]. The Handover Initiate, Handover Acknowledge, Fast Binding Update, Fast Binding Acknowledgment, and the (deprecated) Fast Neighbor Advertisement messages use the Mobility Header.
モバイルIPv6は、モビリティヘッダー[RFC3775]と呼ばれる新しいIPv6ヘッダータイプを使用します。ハンドオーバーの開始、ハンドオーバーの承認、高速拘束力のある更新、高速拘束力のある承認、および（非推奨）隣接する迅速な広告メッセージは、モビリティヘッダーを使用します。
The Handover Initiate (HI) is a Mobility Header message sent by an Access Router (typically a PAR) to another access router (typically a NAR) to initiate the process of an MN's handover.
ハンドオーバー開始（HI）は、MNのハンドオーバーのプロセスを開始するために、アクセスルーター（通常はPAR）から別のアクセスルーター（通常はNAR）に送信されるモビリティヘッダーメッセージです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|U| Reserved | Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Handover Initiate (HI) Message
図6：ハンドオーバー開始（ハイ）メッセージ
IP Fields:
IPフィールド：
Source Address: The IP address of the PAR
ソースアドレス：PARのIPアドレス
Destination Address: The IP address of the NAR
宛先アドレス：NARのIPアドレス
Sequence #: MUST be set by the sender so replies can be matched to this message.
シーケンス＃：送信者によって設定する必要があるため、このメッセージに返信を一致させることができます。
'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が宛先によって返されるように要求します。Code = 0の場合に設定される場合があります。Code= 1の場合は0でなければなりません。
'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」フラグ：バッファフラグ。設定すると、宛先は、このメッセージのオプションに示されているノードにパケットをバッファリングする必要があります。Code = 0の場合に使用すると、Code = 1の場合は0に設定する必要があります。
Code: 0 or 1. See below
コード：0または1。以下を参照してください
Reserved: MUST be set to zero by the sender and ignored by the receiver.
予約済み：送信者によってゼロに設定され、受信機が無視する必要があります。
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.
新しい住所：MNが宛先に接続するときに使用したいIPアドレス。「S」ビットが設定されている場合、NARはこのアドレスを割り当てることができます。
The PAR uses a Code value of 0 when it processes an FBU with the PCoA as source IP address. The PAR uses a Code value of 1 when it processes an FBU whose source IP address is not the PCoA.
PARは、PCOAをソースIPアドレスとしてPCOAで処理するときに0のコード値を使用します。PARは、ソースIPアドレスがPCOAではないFBUを処理する場合、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）の2倍以上、またはRTTが不明な場合は100ミリ秒）で応答として受信されない場合、ハンドオーバーは開始しますresする必要があります。その後の再送信はhi_retriesまでのものになる可能性がありますが、再送信の各インスタンス中にタイムアウト期間（つまり、2xRTTまたは100ミリ秒）が2倍になる指数関数的なバックオフを使用する必要があります。
The Handover Acknowledge message is a new Mobility Header message that MUST be sent (typically by the NAR to the PAR) as a reply to the Handover Initiate message.
ハンドオーバー確認メッセージは、ハンドオーバー開始メッセージへの返信として（通常はnarによって）送信されなければならない新しいモビリティヘッダーメッセージです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| |
. .
. Mobility 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.
宛先アドレス：ハンドオーバーのソースアドレスからコピーされたメッセージは、このメッセージが応答であるメッセージを開始します。
Sequence #: Copied from the corresponding field in the HI message to which this message is a response, to enable the receiver to match this HAck message with an outstanding HI message.
シーケンス＃：このメッセージが応答であるHIメッセージの対応するフィールドからコピーされ、受信者がこのハックメッセージを未解決のHIメッセージと一致させることができます。
Code:
コード：
0: Handover Accepted, NCoA valid
0：ハンドオーバーが受け入れ、NCOA有効
1: Handover Accepted, NCoA not valid or in use
1：ハンドオーバーが受け入れ、NCOAが無効または使用中
2: Handover Accepted, NCoA assigned (used in Assigned Addressing)
2：受け入れられたハンドオーバー、NCOAが割り当てられた（割り当てられたアドレス指定で使用）
3: Handover Accepted, use PCoA
3：受け入れられて、PCOAを使用します
4: Message sent unsolicited, usually to trigger an HI message
4：メッセージは承認されていません。通常はhiメッセージをトリガーするために
128: Handover Not Accepted, reason unspecified
128：ハンドオーバーは受け入れられていない、理由がない理由
129: Administratively prohibited
129：管理上禁止
130: Insufficient resources
130：リソースが不十分です
Reserved: MUST be set to zero by the sender and ignored by the receiver.
予約済み：送信者によってゼロに設定され、受信機が無視する必要があります。
Valid Options:
有効なオプション：
New Care-of Address: If the 'S' flag in the Handover Initiate message is set, this option MUST be used to provide the NCoA that 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 the 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のホストルートエントリを確立し、PARにトンネルを設定して、送信されたMNのパケットをソースIPアドレスとして転送することができます。このホストルートエントリは、NARが特定のMNがリンクに接続されていることを検出すると、パケットを転送するために使用する必要があります。NARは、ハックメッセージのコード値3を使用してPCOAの転送サポートを示しています。その後、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 MUST indicate the reason in one of the available Code values.
最後に、新しいアクセスルーターは常に引き渡しを拒否できます。その場合、利用可能なコード値の1つで理由を示す必要があります。
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. Furthermore, additional flags (as part of the Reserved field below) defined by other related protocols are not relevant in this message, and MUST be set to zero.
高速バインディングアップデートメッセージのモビリティヘッダータイプ値は8です。FBUは、モバイルIPv6バインディングアップデート（BU）メッセージと同じです。ただし、処理ルールはわずかに異なります。さらに、他の関連するプロトコルによって定義される追加のフラグ（下の予約済みフィールドの一部）は、このメッセージでは関連せず、ゼロに設定する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
'A'フラグ：速い拘束力のある確認メッセージを送信することを要求するために、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.4.5. MAY contain the Mobility Header LLA option (see Section 6.4.4).
モビリティオプション：FBUがPARのリンクから送信されたときに、NCOAに設定された代替COAオプションを含める必要があります。FMIP（BADF）オプションの拘束力のある承認データを含める必要があります。セクション6.4.5を参照してください。モビリティヘッダーLLAオプションが含まれる場合があります（セクション6.4.4を参照）。
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は、PRRTADVメッセージを受信した後でもFBUメッセージを送信します。PRRTADVメッセージを受信する前にMNが移動する場合、NARISのNARでNCOAを構成した後、FBUをPARに送信する必要があります。MNがPRRTADVメッセージを受信せずに移動すると、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.
ソースIPアドレスは、FBUがPARのリンクから送信されるときのPCOAであり、SOURCE IPアドレスはNARのリンクから送信されるFBUの場合のNCOAです。ソースIPアドレスがPCOAの場合、MNにはNCOAに設定された代替COAオプションを含める必要があります。PARは、代替COAオプションのアドレスがソースIPアドレスのアドレスとは異なる場合でもFBUを処理する必要があり、NARへのHIメッセージの新しいCOAオプションで代替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がPCOAを合法的に所有するMNによってFBUメッセージが送信されることを判断できるように、FBUメッセージを保護する必要があります。
The FBack message format is identical to the Mobile IPv6 Binding Acknowledgment (BAck) message. However, the processing rules are slightly different. Furthermore, additional flags (as part of the Reserved field below) defined by other related protocols are not relevant in this message, and MUST be set to zero.
FBACKメッセージ形式は、モバイルIPv6バインディング確認（バック）メッセージと同一です。ただし、処理ルールはわずかに異なります。さらに、他の関連するプロトコルによって定義される追加のフラグ（下の予約済みフィールドの一部）は、このメッセージでは関連せず、ゼロに設定する必要があります。
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.
高速バインディングの確認メッセージのモビリティヘッダータイプ値は9です。Fバックメッセージは、「A」ビットが設定されている高速バインディングアップデートメッセージの受信を確認するためにPARによって送信されます。PARがFBUを処理した後にHIメッセージをNARに送信した場合、PARがNARからハックメッセージを受信する前に、FBACHメッセージをMNに送信しないでください。ただし、PARは反応モードですぐにFBACKを送信する場合があります。高速拘束力のある承認は、古いリンクのMNに送信することもできます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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未満のステータスフィールドの値は、バインディングアップデートが受信ノードによって受け入れられたことを示しています。以下のそのようなステータス値は現在定義されています。
0: Fast Binding Update accepted
0：高速バインディングアップデートが受け入れられました
1: Fast Binding Update accepted but NCoA is invalid. Use NCoA supplied in "alternate" CoA
1：高速バインディングアップデートは受け入れられますが、NCOAは無効です。「代替」COAで提供されたNCOAを使用します
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以上のステータスフィールドの値は、バインディングアップデートが受信ノードによって拒否されたことを示しています。以下のそのようなステータス値は現在定義されています。
128: Reason unspecified
128：不特定の理由
129: Administratively prohibited
129：管理上禁止
130: Insufficient resources
130：リソースが不十分です
131: Incorrect interface identifier length
131：誤ったインターフェイス識別子長
'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.
シーケンス番号：MNが使用するためのFBUメッセージからコピーされ、この承認を優れたFBUと一致させます。
Lifetime: The granted lifetime in seconds for which the sender of this message will retain a binding for traffic redirection.
Lifetime：このメッセージの送信者がトラフィックリダイレクトの拘束力を保持する秒での生涯を許可された生涯。
Mobility Options: MUST contain an "alternate" CoA if Status is 1. MUST contain the Binding Authorization Data for FMIP (BADF) option. See Section 6.4.5.
モビリティオプション：ステータスが1である場合、「代替」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.
これは[rfc4861]と同じメッセージであり、「o」ビットが常にゼロに設定されるという要件があります。これは未承諾メッセージであるため、「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 UNAs subject to the specification in Section 7.2.6 of [RFC4861] while noting that the default RetransTimer value is large for handover purposes.
NARがNCOAをプロキシしている場合（HIおよびハック交換の結果として）、UNA処理には追加の手順があります（以下を参照）。NARがNCOAをプロキシしていない場合（たとえば、HIとハックの交換は行われていません）、UNA処理は[RFC4861]で指定されたものと同じ手順に従います。実装は、[RFC4861]のセクション7.2.6の仕様の対象となり、デフォルトのRetranstimer値がハンドオーバーの目的で大きいことに注意してください。
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.
ターゲットアドレスにはNCOAを含める必要があり、ターゲットリンク層アドレスにはMNのLLAを含める必要があります。
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, the NAR sets it to STALE, again according to the procedure in [RFC4861].
MNは、新しいリンクの接続性を取り戻すとすぐに、UNAメッセージをNARに送信します。到着またはバッファーされたパケットは、すぐに転送できます。NARがNCOAをプロキシしている場合、古い状態に近隣キャッシュエントリを作成しますが、標準的な隣接発見手順に従って双方向の到達可能性を決定するため、パケットを転送します。リンク層アドレスのない不完全な状態にエントリがある場合、NARは[RFC4861]の手順に従って、それを古くするように設定します。
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 a NAACK option containing the new IP address.
NARは、UNAメッセージのものとは異なるIPアドレスをMNに提供したい場合があります。そのような場合、NARはNCOAのプロキシエントリを削除し、新しいIPアドレスを含むNAACKオプションを使用してルーター広告を送信する必要があります。
The combination of the NCoA (present in the source IP address) and the Link-Layer Address (present as a Target LLA) SHOULD be used to distinguish the MN from other nodes.
NCOA（ソースIPアドレスに存在する）とリンク層アドレス（ターゲットLLAとして存在する）の組み合わせを使用して、MNを他のノードと区別する必要があります。
All the options, with the exception of Binding Data Authorization for FMIPv6 (BADF) discussed in Section 6.4.5, use the Type, Length, and Option-Code format shown in Figure 10.
セクション6.4.5で説明されているFMIPv6（BADF）のバインディングデータ認証を除いて、すべてのオプションは、図10に示すタイプ、長さ、およびオプションコード形式を使用します。
The Type values are defined from the Neighbor Discovery options space and Mobility Header options space. The Length field is in units of 8 octets for Neighbor Discovery options, and is in units of octets for Mobility Header options. And, Option-Code provides additional information for each of the options (see individual options below).
タイプの値は、近隣発見オプションスペースとモビリティヘッダーオプションスペースから定義されます。長さのフィールドは、近隣発見オプションのために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 message.
このオプションは、プロキシルーター広告メッセージで送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 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
1：古い住所
2: New Care-of Address
2：新しい住所
3: NAR's IP address
3：NARのIPアドレス
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.
4：Prrtadvで送信されたNARのプレフィックス。プレフィックスの長さフィールドには、プレフィックス内の有効な先頭ビットの数が含まれています。プレフィックスの長さの後にプレフィックス内のビットは予約されており、送信者によってゼロに初期化され、受信機が無視する必要があります。
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アドレス：オプションコードフィールドで定義されたIPアドレス。
This option is sent in the Handover Initiate and Handover Acknowledge messages. This option has an alignment requirement of 8n+4.
このオプションは、ハンドオーバーイニシエートとハンドオーバー確認メッセージで送信されます。このオプションには、8N 4のアライメント要件があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address/Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Mobility Header IPv6 Address/Prefix Option
図12：モビリティヘッダーIPv6アドレス/プレフィックスオプション
Type: 17
タイプ：17
Length: The size of this option in octets excluding the Type and Length fields.
長さ：タイプと長さのフィールドを除くオクテットのこのオプションのサイズ。
Option-Code:
オプションコード：
1: Old Care-of Address
1：古い住所
2: New Care-of Address
2：新しい住所
3: NAR's IP address
3：NARのIPアドレス
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.
4：Prrtadvで送信されたNARのプレフィックス。プレフィックスの長さフィールドには、プレフィックス内の有効な先頭ビットの数が含まれています。プレフィックスの長さの後にプレフィックス内のビットは予約されており、送信者によってゼロに初期化され、受信機が無視する必要があります。
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です。
IPv6 address/prefix: The IP address/prefix defined by the Option-Code field.
IPv6アドレス/プレフィックス：Option-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 13: Link-Layer Address Option
図13：リンク層アドレスオプション
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
0：近くのすべてのアクセスポイントの解像度を要求するワイルドカード
1: Link-Layer Address of the New Access Point
1：新しいアクセスポイントのリンク層アドレス
2: Link-Layer Address of the MN 3: Link-Layer Address of the NAR (i.e., Proxied Originator)
2：MN 3のリンク層アドレス：NARのリンク層アドレス（つまり、プロキシオリジネーター）
4: Link-Layer Address of the source of RtSolPr or PrRtAdv message
4：RTSOLPRまたはPRRTADVメッセージのソースのリンク層アドレス
5: The access point identified by the LLA belongs to the current interface of the router
5：LLAによって識別されるアクセスポイントは、ルーターの現在のインターフェイスに属します
6: No prefix information available for the access point identified by the LLA
6：LLAによって識別されたアクセスポイントに利用可能なプレフィックス情報はありません
7: No fast handover support available for the access point identified by the LLA
7：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 Link-Layerアドレスオプションには、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 14. There are no alignment requirements for this option.
このオプションはLLAオプションと同一ですが、Mobilityヘッダーメッセージ（たとえばFBU）に掲載されています。将来的には、他のモビリティヘッダーメッセージもこのオプションを使用する可能性があります。オプションの形式を図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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Code | LLA ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Mobility Header Link-Layer Address Option
図14：モビリティヘッダーリンク層アドレスオプション
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 15.
このオプションの形式を図15に示します。
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 15: Binding Authorization Data for FMIPv6 (BADF) Option
図15：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.
オプションの長さ：BYTES SPIの認証器の長さ：セキュリティパラメーターインデックス。SPI = 0は、送信ベースのハンドオーバーキーを使用して計算された認証器用に予約されています。
Authenticator: Same as in RFC 3775, with "correspondent" replaced by the PAR's IP address, and Kbm (binding management key) replaced by the shared key between the MN and the PAR.
Authenticator：RFC 3775と同じ、「特派員」がPARのIPアドレスに置き換えられ、KBM（バインディング管理キー）はMNとPARの間の共有キーに置き換えられました。
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に使用される最初の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 16: Neighbor Advertisement Acknowledgment Option
図16：近隣の広告承認オプション
Type: 20
タイプ：20
Length: 8-bit unsigned integer. Length of the option, in 8 octets. The length is 1 when a new CoA is not supplied. The length is 3 when a new CoA is present (immediately following the Reserved field)
長さ：8ビットの符号なし整数。オプションの長さ、8オクテット。新しい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
1：NCOAは無効で、アドレス構成を実行します
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.
2：NCOAは無効で、付属のNCOAを使用します。提供されたNCOA（IPアドレスオプションの形式）は、予約済みフィールドに従って存在する必要があります。
3: NCoA is invalid, use NAR's IP address as NCoA in FBU
3：NCOAは無効です。NARのIPアドレスをFBUでNCOAとして使用します
4: PCoA supplied, do not send FBU 128: Link-Layer Address unrecognized
4：PCOAが提供し、FBU 128を送信しないでください：リンク層アドレスは認識されていません
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver.
予約済み：送信者はゼロに設定する必要があり、受信機は無視する必要があります。
The NAR responds to an 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は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.3). 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).
ここで指定されたプロトコルは、設計原則として、関連するプロトコルにNOまたは最小限の変更を導入します。たとえば、このプロトコルを実装するためには、ベースモバイルIPv6プロトコルの変更は必要ありません。同様に、IPv6 Stateless Address Auto-Configuration Protocol [RFC4862]およびDHCP [RFC3315]の変更は導入されていません。プロトコルは、UNAメッセージへの応答としてアクセスルーターがルーター広告を送信する可能性があるNeighbor Discovery [RFC4861]へのオプションの拡張機能を指定します（セクション6.3を参照）。この拡張機能以外に、仕様は近隣発見の動作を変更しません（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]と[Tarzan]、および複数の独自の実装があります。一部の経験では、特定の無線アクセスプロトコルで適切に使用すると、プロトコルが遅延およびパケット損失要件を満たしていることが示唆されています。たとえば、[rfc5184]および[mip6-book]を参照してください。それにもかかわらず、ハンドオーバーパフォーマンスは、このプロトコルが指定する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.4.5) that can only be processed when a 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）との間のセキュリティ関連の確立です。このようなセキュリティ協会を確立する1つの方法は、[RFC5269]に指定されています。このドキュメントの仕様に準拠する実装は、[RFC4068]でも機能する可能性がありますが、FMIPv6オプションの拘束力のある認証データ（セクション6.4.5を参照）を除き、セキュリティ協会が配置されている場合にのみ処理できます。モバイルノードとそのアクセスルーター。この仕様は、Fast Neighbor Advertisement（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.2.2 |
| PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.1.2 |
| HI_RETRIES | 3 | Section 6.2.1.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.
不安定なFBU：この場合、1つのアドレスを対象としたパケットは、疑いを持たないノードに盗まれたり、リダイレクトされたりする可能性があります。この懸念は、MNとホームエージェントの関係と同じです。
Hence, the PAR MUST ensure that the FBU packet arrived from a node that legitimately owns the PCoA. The access router and its hosts may use any available mechanism to establish a security association that MUST be used to secure FBU. The current version of this protocol 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.4.5) MUST be computed, and the BADF option included in FBU and FBack messages.
したがって、PARは、PCOAを合法的に所有するノードからFBUパケットが到着したことを確認する必要があります。アクセスルーターとそのホストは、利用可能なメカニズムを使用して、FBUを保護するために使用する必要があるセキュリティ協会を確立することができます。このプロトコルの現在のバージョンは、コンパニオンプロトコル[RFC5269]に依存して、このようなセキュリティ協会を確立します。[RFC5269]の共有ハンドオーバーキーを使用して、BADFオプションの認証因子（セクション6.4.5を参照）を計算し、FBUおよびFBACHメッセージに含まれるBADFオプションを計算する必要があります。
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 the PCoA is being bound actually belongs to the NAR's prefix. In order to do this, HI and HAck message exchanges are to be used. When the NAR accepts the NCoA in HI (with Code = 0), it proxies the NCoA so that any arriving packets are not sent on the link until the MN attaches and announces itself through the 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とハッキングメッセージの交換を使用します。NARがHIでNCOAを受け入れると（Code = 0）、NCOAをプロキシして、MNがUNAを介して自分自身を取り付けて発表するまで、到着するパケットがリンクに送信されません。したがって、ホストへの不注意または悪意のあるリダイレクトは回避されます。リダイレクトされたトラフィックで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を送信する：悪意のあるノードは、NARのリンクからFBUを送信して、疑いを持たないノードのアドレスをNCOAとして提供する場合があります。これは、MNがホームエージェントにCOAとして他のノードのIPアドレスを提供できるベースモバイルIPに似ています。ここでは、PARはモバイルノードとセキュリティ関連があり、ハンドオーバートラフィックの転送サポートを提供する「一時的なホームエージェント」のように機能します。ベースモバイルIPと同様に、この誤配信は、ルーターとセキュリティ関連があるMNに追跡可能です。したがって、それが不正行為を続けている場合、そのようなMNを分離することが可能です。同様に、PARとセキュリティ関連があるMNは、NARのリンク上の他のノードのLLAを提供する場合があります。これにより、疑いを持たないノードへのパケット（NCOA向け）の誤配信を引き起こす可能性があります。この場合、MNを追跡することも可能です。
Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv (Section 6.1.2) messages inherit the weaknesses of the 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）およびPRRTADV（セクション6.1.2）メッセージは、近隣発見プロトコル[RFC4861]の弱点を継承します。具体的には、アクセスルーターが侵害されると、MNのRTSOLPRメッセージは、解像度として不正なルーターを提供する攻撃者によって回答される場合があります。MNがそのような不正なルーターに付着した場合、その通信は妥協することができます。同様に、攻撃者からのネットワーク開始PRRTADVメッセージ（セクション3.3を参照）は、MNが不正なルーターに引き渡す可能性があります。これらの弱点が懸念事項である場合、安全な近隣発見（送信）[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 Acknowledge (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 that 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 Acknowledge (HAck) messages exchanged between the PAR and NAR MUST be protected using end-to-end security association(s) offering integrity and data origin authentication.
PARとNARの間で交換されるハンドオーバー開始（HI）およびハンドオーバー（ハック）メッセージは、整合性とデータの起源認証を提供するエンドツーエンドのセキュリティ協会を使用して保護する必要があります。
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]を使用して、信号メッセージを保護するために使用する必要があります。これらのメッセージの機密保護は必要ありません。
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構成またはInternet Key Exchange Protocolバージョン2（IKEV2）[RFC4306]などの動的なキーネゴシエーションプロトコルのいずれかを使用して作成できます。IKEV2を使用すると、PARとNARは、RFC 4306で指定されているように、相互認証のために認証メカニズムを使用できます。ただし、ベースラインの相互運用性を確保するには、実装は相互認証のための共有秘密をサポートする必要があります。次のセクションでは、必要なIPSECセキュリティ協会を設定するためにIKEV2を使用した場合、[RFC4301]で指定されたPEER Authorizationデータベース（PAD）およびセキュリティポリシーデータベース（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のパッドエントリについて説明します。パッドエントリは、構成の例のみです。パッドは論理的な概念であり、特定のPARまたはNARの実装は、任意の実装固有の方法でパッドを実装できることに注意してください。パッド状態は、特定の実装でさまざまなデータベースに配布される場合があります。
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を認証し（共有secret/certificate/eap）認証し、
NAR PAD:
NARパッド：
- 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の場合、リモートアドレスpar_address_1のchild_sasを認証し（共有secret/certificate/eap）認証し、
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:
PAR SPD-S：
- IF local_address = par_address_1 & remote_address = nar_address_1 & proto = MH & local_mh_type = HI & remote_mh_type = HAck THEN use SA ESP transport mode Initiate using IDi = par_1 to address nar_address_1
- local_address = par_address_1＆remote_address = nar_address_1＆proto = mh＆local_mh_type = hi＆remote_mh_type = hackを使用してからsa espトランスポートモードを使用してidi = par_1を使用してnar_address_1に対処する
NAR SPD-S:
NAR SPD-S：
- IF local_address = nar_address_1 & remote_address = par_address_1 & proto = MH & local_mh_type = HAck & remote_mh_type = HI THEN use SA ESP transport mode
- local_address = nar_address_1＆remote_address = par_address_1＆proto = mh＆local_mh_type = hack＆remote_mh_type = hiを使用してからsa espトランスポートモードを使用します
This document defines two new Mobility Header messages that have received Type assignment from the Mobility Header Type registry.
このドキュメントでは、モビリティヘッダータイプレジストリからタイプの割り当てを受信した2つの新しいモビリティヘッダーメッセージを定義します。
14 Handover Initiate Message (Section 6.2.1.1)
14ハンドオーバー開始メッセージ（セクション6.2.1.1）
15 Handover Acknowledge Message (Section 6.2.1.2)
15ハンドオーバー謝辞メッセージ（セクション6.2.1.2）
This document defines a new Mobility Option that has received Type assignment from the Mobility Options Type registry.
このドキュメントでは、モビリティオプションタイプレジストリからタイプの割り当てを受信した新しいモビリティオプションを定義します。
1. Mobility Header IPv6 Address/Prefix option (34), described in Section 6.4.2
1. モビリティヘッダーIPv6アドレス/プレフィックスオプション（34）、セクション6.4.2で説明されています
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 - Deprecated | Section 6.2.1.1 |
| 5 | HAck - Deprecated | Section 6.2.1.2 |
+---------+-------------------+-----------------+
The values '0' and '1' are reserved. The upper limit is 255. An RFC is required for new message assignment. The Subtype values 4 and 5 are deprecated but marked as unavailable for future allocations.
値「0」と「1」は予約されています。上限は255です。新しいメッセージ割り当てにはRFCが必要です。サブタイプの値4と5は非推奨ですが、将来の割り当てでは利用できないとマークされています。
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 (21), described in Section 6.4.5
1. セクション6.4.5で説明するFMIPv6（BADF）オプション（21）の拘束力のある承認データ
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.4.1 |
| 19 | Link-layer Address Option | Section 6.4.3 |
| 20 | Neighbor Advertisement Acknowledgment | Section 6.4.6 |
| | Option | |
+------+--------------------------------------------+---------------+
The document defines the following Mobility Header messages that have received Type allocation from the Mobility Header Types registry.
このドキュメントでは、Mobility Header Typesレジストリからタイプ割り当てを受信した次のモビリティヘッダーメッセージを定義します。
1. Fast Binding Update (8), described in Section 6.2.2
1. セクション6.2.2で説明されている高速バインディングアップデート（8）
2. Fast Binding Acknowledgment (9), described in Section 6.2.3
2. セクション6.2.3で説明されている高速拘束力のある承認（9）
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 (7), described in Section 6.4.4
1. セクション6.4.4で説明するモビリティヘッダーリンク層アドレスオプション（7）
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.
編集者は、この仕様に関するフィードバックを提供したすべての人に感謝したいが、ここではここでしか言及できません：Vijay Devarapalli、Youn-Hee Han、Emil Ivov、Syam Madanapalli、Suvidh Mathur、Andre Martin、Javier Martin、Koshiro Mitsuya、ガブリエル・モンテネグロ、オカワ、サン・ペン、YCペン、アレックス・ペトレシュ、ドマゴジ・プレムク、サブバ・レディ、K。ラガフ、ランジット・ウェーブル、ジョナサン・ウッド。Behcet SarikayaとFrank Xiaは、ポイントツーポイントリンク上の操作に関するフィードバックについて認められています。編集者は、この仕様を改善するために、James Kempfからの貢献を認めたいと考えています。Vijay Devarapalliは、セクション10のアクセスルーター間のセキュリティ構成のテキストを提供しました。このドキュメントが改善された詳細な広告レビューについては、Jari Arkkoに感謝します。編集者はまた、Mipshopワーキンググループの椅子Gabriel Montenegroと、かつてのモバイルIPワーキンググループチェアのBasavaraj PatilとPhil Robertsに、この作業に多くのサポートを提供してくれたことにも感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3315] Droms, R., 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.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）、RFC 4443、2006年3月。
[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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
[RFC5268] Koodli、R。、「モバイルIPv6ファストハンドオーバー」、RFC 5268、2008年6月。
[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] Kempf、J。およびR. Koodli、「セキュアネイバーディスカバリー（送信）を使用した対称高速モバイルIPv6（FMIPV6）ハンドオーバーキーの配布」、RFC 5269、2008年6月。
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.
[RFC3290] Bernet、Y.、Blake、S.、Grossman、D。、およびA. Smith、「Diffservルーターの非公式管理モデル」、RFC 3290、2002年5月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC4068] Koodli, R., "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] Teraoka、F.、Gogo、K.、Mitsuya、K.、Shibui、R。、およびK. Mitani、 "Unified Layer 2（l2）abstractions for Layer 3（L3）駆動高ファーストハンドオーバー"、RFC 5184、2008年5月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555] Soliman、H.、ed。、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、2009年6月。
[fmipv6] "fmipv6.org : Home Page", <http://fmipv6.org>.
[fmipv6] "fmipv6.org：ホームページ"、<http://fmipv6.org>。
[mip6-book] Koodli, R. and C. Perkins, "Mobile Inter-networking with IPv6", Chapter 22, John Wiley & Sons, Inc., 2007.
[MIP6-Book] Koodli、R。およびC. Perkins、「IPv6とのモバイルインターネットワーキング」、第22章、John Wiley＆Sons、Inc.、2007。
[pfmipv6] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", Work in Progress, May 2009.
[PFMIPV6] Yokota、H.、Chowdhury、K.、Koodli、R.、Patil、B。、およびF. Xia、「プロキシモバイルIPv6用の高速ハンドオーバー」、2009年5月の作業。
[tarzan] "Nautilus6 - Tarzan", <http://software.nautilus6.org/TARZAN/>.
[Tarzan] "Nautilus6 -Tarzan"、<http://software.nautilus6.org/tarzan/>。
[x.s0057] 3GPP2, "E-UTRAN - eHRPD Connectivity and Interworking: Core Network Aspects", 3GPP2 X.S0057-0, April 2009, <http://www.3gpp2.org/Public_html/Specs/ X.S0057-0_v1.0_090406.pdf>.
[X.S0057] 3GPP2、「E-UTRAN-EHRPD接続とインターワーキング：コアネットワークの側面」、3GPP2 X.S0057-0、2009年4月、<http://www.3gpp2.org/public_html/specs/ x.s005777-0_V1.0_090406.pdf>。
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ワーキンググループの高速ハンドオーバーデザインチームに起源があります。このデザインチームのメンバーは、アルファベット順の順序でした。GopalDommety、Karim El-Malki、Mohammed Khalil、Charles Perkins、Hesham Soliman、George Tsirtsis、Alper Yegin。
This document specifies the Mobility Header format for HI and HAck messages, and the Mobility Header Option format for IPv6 Address/ Prefix option. The use of ICMP for HI and HAck messages is deprecated. The following developments led the WG to adopt this change:
このドキュメントは、HIおよびハッキングメッセージのモビリティヘッダー形式と、IPv6アドレス/プレフィックスオプションのモビリティヘッダーオプション形式を指定します。HIおよびハックメッセージにICMPを使用することは非推奨です。次の開発により、WGはこの変更を採用するようになりました。
o The Proxy Mobile IPv6 protocol [RFC5213] has been adopted for the deployment of fourth-generation mobile networks. This has established Mobility Header as the default type for critical IP mobility signaling.
o プロキシモバイルIPv6プロトコル[RFC5213]は、第4世代モバイルネットワークの展開に採用されています。これにより、重要なIPモビリティシグナル伝達のデフォルトタイプとしてモビリティヘッダーが確立されました。
o The Mobile IPv6 protocol [RFC3775] (particularly, the Dual-stack MIP6 or DSMIP6 [RFC5555]) protocol, which is also expected to be deployed in the fourth-generation mobile networks, similarly relies on Mobility Header for critical IP mobility signaling.
o モバイルIPv6プロトコル[RFC3775]（特に、デュアルスタックMIP6またはDSMIP6 [RFC5555]）プロトコルは、第4世代のモバイルネットワークにも展開されると予想されています。
o The Fast Handover protocol specified in this document is used as the basis for the Fast Handover for Proxy MIP6 [pfmipv6], which is adopted by the "enhanced HRPD" (CDMA) networks [x.s0057]. Hence, the Fast Handover protocol, when used in deployments using either PMIP6 or MIP6, needs to support the Mobility Header for all its critical mobility signaling messages. At the same time, use of ICMP, primarily due to legacy, is unlikely to facilitate critical IP mobility signaling without a non-trivial departure from deploying the new Mobility Header signaling protocols.
o このドキュメントで指定された高速ハンドオーバープロトコルは、プロキシMIP6 [PFMIPV6]の高速ハンドオーバーの基礎として使用されます。これは、「強化されたHRPD」（CDMA）ネットワーク[X.S0057]によって採用されています。したがって、PMIP6またはMIP6のいずれかを使用して展開で使用される場合、高速ハンドオーバープロトコルは、すべての重要なモビリティシグナリングメッセージのモビリティヘッダーをサポートする必要があります。同時に、主にレガシーによるICMPの使用は、新しいモビリティヘッダーシグナル伝達プロトコルの展開を妨げることなく、重要なIPモビリティシグナル伝達を促進する可能性は低いです。
Therefore, it follows that specifying the Mobility Header for the HI and HAck messages is necessary for the deployment of the protocol along-side PMIP6 and MIP6 protocols.
したがって、HIおよびハックメッセージのモビリティヘッダーを指定することが、PMIP6およびMIP6プロトコルに沿ったプロトコルの展開に必要であることになります。
The 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およびFBACの信頼性を検証するために使用されるセキュリティパラメーターを携帯するための高速ハンドオーバー（BADF）オプションの指定されたバインディング認証データ。Authenticatorの計算に使用されるハンドオーバーキーは、コンパニオンドキュメントで指定されています。
o Specified the security configuration for inter - access router signaling (HI, HAck).
o Inter -Accessルーターシグナリングのセキュリティ構成を指定しました（こんにちは、ハック）。
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.
o Mobility HeaderメッセージであるFNAを非推奨。その代わりに、RFC 4861からの未承諾の近隣広告（UNA）メッセージが使用されています。
o Combined the IPv6 Address Option and IPv6 Prefix Option.
o IPv6アドレスオプションとIPv6プレフィックスオプションを組み合わせました。
o Added description of the DAD requirement on NAR when determining NCoA uniqueness in Section 4, "Protocol Details".
o セクション4「プロトコルの詳細」でNCOAの一意性を決定する際に、NARに関するDAD要件の説明を追加しました。
o Added a new code value for a gratuitous HAck message to trigger a HI message.
o HIメッセージをトリガーするために、無償のハックメッセージに新しいコード値を追加しました。
o Added Option-Code 5 in PrRtAdv message to indicate NETLMM (Network-based Localized Mobility Management) usage.
o NetLMM（ネットワークベースのローカライズされたモビリティ管理）の使用を示すために、PRRTADVメッセージにオプションコード5を追加しました。
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).
o DHCPがNCOA製剤に使用される場合、プロトコルの使用を承認しました（セクション6.1.2、3.1、および5.2）。PRRTADV（セクション6.1.2）に新しいコード値（5）を追加しました。
o Clarified that IPv6 Neighbor Discovery operations are a must in Section 7, "Related Protocol and Device Considerations".
o セクション7「関連プロトコルとデバイスの考慮事項」では、IPv6近隣発見操作が必須であることを明らかにしました。
o Clarified "PAR = temporary HA" for FBUs sent by a genuine MN to an unsuspecting CoA.
o 本物のMNから疑いを持たないCOAに送られたFBUの「PAR =一時的なHA」を明確にしました。
Author's Address
著者の連絡先
Rajeev Koodli (editor) Starent Networks USA
Rajeev Koodli（編集者）Starent Networks USA
EMail: rkoodli@starentnetworks.com