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