RFC4068 日本語訳
4068 Fast Handovers for Mobile IPv6. R. Koodli, Ed.. July 2005. (Format: TXT=93591 bytes) (Obsoleted by RFC5268) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Koodli, Ed. Request for Comments: 4068 Nokia Research Center Category: Experimental July 2005
ワーキンググループR.Koodli、エドをネットワークでつないでください。コメントのために以下を要求してください。 4068年のノキアリサーチセンターカテゴリ: 実験的な2005年7月
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non-real- time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency.
1Access Routerから別のAccess Routerまで動くとき、モバイルIPv6は、モバイルNodeがインターネットに接続性を維持するのを可能にします、引き渡しと呼ばれた過程。引き渡しの間、モバイルNodeがリンク切り換え遅れのためにパケットを送るか、または受けることができない期間とIPプロトコル操作があります。 標準のモバイルIPv6手順、すなわち、動き検出から生じるこの「引き渡し潜在」(Address構成の新しいCare、およびBinding Update)は、しばしばボイス・オーバー IPなどのリアルタイムの交通に容認できません。 引き渡しレイテンシを減少させるのが有益であるかもしれない、非、-、リアルタイム、また、スループット敏感なアプリケーション。 このドキュメントは、モバイルIPv6手順のため引き渡し潜在を改良するためにプロトコルを指定します。 このドキュメントはリンク切り換え潜在をアドレス向上でないのにします。
Koodli, Ed. Experimental [Page 1] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[1ページ]RFC4068の速い身柄の引き渡し
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語。 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 概観について議定書の中で述べてください。 . . . . . . . . . . . . . . . . . . . . . . 5 3.1. 引き渡し潜在を記述します。 . . . . . . . . . . . . 5 3.2. 操作. . . . . . . . . . . . . . . . . . . 7 3.3について議定書の中で述べてください。 ネットワークによって開始された引き渡. . . . 9 4しの操作について議定書の中で述べてください。 詳細. . . . . . . . . . . . . . . . . . . . . . . 10 5について議定書の中で述べてください。 その他。 . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. 引き渡し能力交換. . . . . . . . . . . . . . 15 5.2。 アドレスの新しい注意を決定します。 . . . . . . . . . . . . 15 5.3. パケット損失。 . . . . . . . . . . . . . . . . . . . . . . 15 5.4. おとうさんの取り扱. . . . . . . . . . . . . . . . . . . . . . 16 5.5い。 速いか誤った運動. . . . . . . . . . . . . . . 16 6。 メッセージ・フォーマット。 . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. 新しい近所発見メッセージ。 . . . . . . . . . . 17 6.1.1. プロキシ広告(RtSolPr). . . . . . . . . . . . . . . . . . . . 17 6.1.2のためのルータ懇願。 プロキシルータ通知(PrRtAdv)。 . . . . . . 20 6.2. 相互ルータメッセージ. . . . . . . . . . . . . . 23 6.2.1にアクセスしてください。 引き渡し開始(HI。) . . . . . . . . . . . . . 23 6.2.2. 引き渡しは(ハッキング). . . . . . . . . . . 25 6.3を承認します。 新しい移動性ヘッダーメッセージ. . . . . . . . . . . . . . 27 6.3.1。 速く、アップデート(FBU). . . . . . . . . . . . 27 6.3.2を縛ります。 速く、承認(FBack). . . . . . . 28 6.3.3を縛ります。 速い隣人広告(FNA。). . . . . . . . 30 6.4 新しいオプション。 . . . . . . . . . . . . . . . . . . . . . . 31 6.4.1. IPアドレスオプション. . . . . . . . . . . . . . . . 32 6.4.2。 新しいルータ接頭語情報オプション。 . . . . . . 33 6.4.3. リンクレイヤアドレス(LLA)オプション. . . . . . . . . 34 6.4.4。 移動性ヘッダーリンクレイヤアドレス(MH-LLA)オプション。 . . . . . . . . . . . . . . . . . . . . . 35 6.4.5. 隣人広告承認(NAACK。). . 35 7 構成可能なパラメタ。 . . . . . . . . . . . . . . . . . . . 36 8. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 37 9. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 38 10. 承認。 . . . . . . . . . . . . . . . . . . . . . . . 39 11. 引用規格. . . . . . . . . . . . . . . . . . . . . 39 12。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 39
Koodli, Ed. Experimental [Page 2] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[2ページ]RFC4068の速い身柄の引き渡し
1. Introduction
1. 序論
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.
可動のノードが1つのアクセスルータから別のルータまでの引き渡しの間、インターネットに接続性を維持するように、モバイル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を織り込む身柄の引き渡しであると考えます: いったん新しいアクセスルータに付けられると、ミネソタはReturn Routability[3]を含むモバイルIP操作に従事しています。 可動のノードが標準のモバイルIP操作に関して異なって振る舞うというどんな特別な要件もありません。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. The use of the term, "silently ignore" is not defined in RFC 2119. However, the term is used in this document and can be similarly construed.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか? 用語の使用、「静かに無視する、」 RFC2119では、定義されません。 しかしながら、用語を本書では使用して、同様に解釈できます。
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.
モバイルNode(ミネソタ)のAモバイルIPv6ホスト。
Access Point (AP)
A Layer 2 device connected to an IP subnet that offers
wireless connectivity to an MN. An Access Point Identifier
(AP-ID) refers to the AP's L2 address. Sometimes, AP-ID is
also referred to as a Base Station Subsystem ID (BSSID).
Layer2装置が無線の接続性をミネソタに提供するIPサブネットに接続したPoint(AP)にアクセスしてください。 Access Point Identifier(AP-ID)はAPのL2アドレスを示します。 また、時々、AP-IDは基地の駅のSubsystem ID(BSSID)と呼ばれます。
Access Router (AR)
The MN's default router.
Router(AR)ミネソタのデフォルトルータにアクセスしてください。
Koodli, Ed. Experimental [Page 3] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[3ページ]RFC4068の速い身柄の引き渡し
Previous Access Router (PAR)
The MN's default router prior to its handover.
引き渡しの前の前のAccess Router(PAR)ミネソタのデフォルトルータ。
New Access Router (NAR)
The MN's default router subsequent to its handover.
新しいAccess Router(NAR)ミネソタの引き渡しへのその後のデフォルトルータ。
Previous CoA (PCoA)
The MN's Care of Address valid on PAR's subnet.
前のCoA(PCoA)ミネソタのPARのサブネットで有効なAddressのCare。
New CoA (NCoA)
The MN's Care of Address valid on NAR's subnet.
新しいCoA(NCoA)ミネソタのNARのサブネットで有効なAddressのCare。
Handover
A process of terminating existing connectivity and obtaining
new IP connectivity.
既存の接続性を終えて、新しいIPの接続性を得る引き渡しAの過程。
Router Solicitation for Proxy Advertisement (RtSolPr)
A message from the MN to the PAR requesting information for
a potential handover.
Proxy Advertisement(RtSolPr)AのためのルータSolicitationはミネソタから潜在的引き渡しのための情報を要求するPARまで通信します。
Proxy Router Advertisement (PrRtAdv)
A message from the PAR to the MN that provides information
about neighboring links facilitating expedited movement
detection. The message also acts as a trigger for network-
initiated handover.
PARから近所付き合いの情報を提供するミネソタまでのプロキシRouter Advertisement(PrRtAdv)Aメッセージは、速められた動き検出を容易にしながら、リンクされます。 また、メッセージはネットワークの開始している引き渡しのために引き金となります。
(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-インフォメーション) アクセスルータのL2とIPが記述するtuple Contains、およびAccess Point(AP-IDによって特定される)が付けているインタフェースで有効な接頭語。 三つ子[ルータのL2アドレス、RouterのIPアドレス、Prefix]は「AR-インフォメーション」と呼ばれます。
Assigned Addressing
A particular type of NCoA configuration in which the NAR
assigns an IPv6 address for the MN. The method by which NAR
manages its address pool is not specified in this document.
NARがミネソタへのIPv6アドレスを割り当てるAddressingのA特定のタイプのNCoA構成を割り当てました。 NARがアドレスプールを管理する方法は本書では指定されません。
Fast Binding Update (FBU)
A message from the MN instructing its PAR to redirect its
traffic (toward NAR).
速く、Binding Update(FBU)Aは交通(NARに向かった)を向け直すようPARに命令するミネソタから通信します。
Fast Binding Acknowledgment (FBack)
A message from the PAR in response to an FBU.
速く、Binding Acknowledgment(FBack)AはFBUに対応してPARから通信します。
Koodli, Ed. Experimental [Page 4] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[4ページ]RFC4068の速い身柄の引き渡し
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.
速く、Neighbor Advertisement(FNA)Aは、付属を発表して、ミネソタがFBACKを受けていないときのNCoAの使用を確認するためにミネソタからNARまで通信します。
Handover Initiate (HI)
A message from the PAR to the NAR regarding an MN's
handover.
ミネソタの引き渡しに関してPARからNARまでInitiate(HI)Aメッセージを引き渡してください。
Handover Acknowledge (HAck)
A message from the NAR to the PAR as a response to HI.
引き渡しAcknowledge(HAck)AはHIへの応答としてNARからPARまで通信します。
v +------------+
+-+ | Previous | <
| | ---------- | Access | ------ > ----\
+-+ | Router | < \
MN | (PAR) | \
| +------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +------------+ /
+-+ | New | < /
| | ---------- | Access | ------ > ----/
+-+ | Router | <
MN | (NAR) |
+------------+
+に対して------------+ +-+ | 戻る| <|| ---------- | アクセス| ------ >。----\ +-+ | ルータ| <\ミネソタ| (平価) | \ | +------------+ +---------------+ | ^IP| 通信員| | | ネットワーク| ノード| V| +---------------+ v/v+------------+ / +-+ | 新しい| </| | ---------- | アクセス| ------ >。----/ +-+ | ルータ| <ミネソタ| (NAR) | +------------+
Figure 1: Reference Scenario for Handover
図1: 引き渡しのための参照シナリオ
3. Protocol Overview
3. プロトコル概観
3.1. Addressing the Handover Latency
3.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構成潜在によります。 ミネソタがいったん新しいサブネットリンクでIPできるようになると、それはホームのエージェントと1人以上の通信員にBinding Updateを送ることができます。 通信員がいったん、首尾よく、Binding Update(Return Routability手順に通常かかわる)を処理すると、ミネソタは新しいCoAでパケットを受けることができます。 それで、直接新しいCoAの通信員からパケットを受ける能力はIP接続性潜在と同様にBinding Update潜在に依存します。
Koodli, Ed. Experimental [Page 5] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[5ページ]RFC4068の速い身柄の引き渡し
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.
プロトコルは、ミネソタがすぐにそれを検出するのを可能にします。それは、ミネソタがいつまだ現在のサブネット(すなわち、図1のPAR)につなげられているかという情報を新しいアクセスポイントと関連サブネット接頭語に提供することによって、新しいサブネットに動きました。 例えば、ミネソタは、リンクレイヤの特定のメカニズム(すなわち、WLANの「スキャン」)を使用することで利用可能なアクセスポイントを発見して、次に、それらの1つ以上に対応するサブネット情報がアクセスポイントを発見したよう要求するかもしれません。 ミネソタはルータ発見を実行した後かいつでも、現在のルータに関連づけられている間、これをするかもしれません。 アクセスポイントに関連している識別子を決議するという結果は[AP-ID、AR-インフォメーション]tupleです:(ミネソタは容易に動きを検出する際にtupleを使用できます)。 AP-IDがあるアクセスポイントへの付属が行われると、ミネソタは接頭語、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メッセージを通して、それがPARのリンクにまだ存在しているとき、ミネソタは将来の新しいCoA(NCoA)を定式化します。 したがって、引き渡しへのその後の新しい接頭語発見による潜在は根絶されます。 その上、ミネソタが動きの前に「速い拘束力がある承認(FBack)」メッセージを受け取ったとき新しいサブネットリンク(すなわち、NARのリンク)に付く直後この将来のアドレスを使用できます。 FBackを受けないで動くなら、ミネソタは、まだ「速い隣人広告(FNA)」メッセージを通して付属を発表した後にNCoAを使用し始めることができます。 一時的なアドレスがその結果、NCoA構成レイテンシを減少させるのにおいて既に使用中であるなら、NARはFNAに応じます。 いくつかの限られた状態のアドレス衝突の確率が無意味にであると考えられる下では、新しいリンクに付く直後NCoAを使用するのは可能であるかもしれません。 たとえそうだとしても、実現が支持しなければならないすべてとSHOULDは潜在的アドレス闘争を避けるために本書では指定されたメカニズムを使用します。
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
Binding Updateレイテンシを減少させるために、プロトコルはPrevious CoA(PCoA)とNCoAの間のトンネルを指定します。 ミネソタは、このトンネルを証明するために「速い拘束力があるアップデート」メッセージをPrevious Access Routerに送ります。 可能であるときに、MN SHOULDはPARのリンクからFBUを送ります。 さもなければ、NARへの付属が見つけられた直後それを送るべきです。 その後のセクションはプロトコル整備士について説明します。 その結果、PARはPCoAのためにNCoAに到着するパケットにトンネルを堀り始めます。 ミネソタが通信員と共にBinding Updateを完成するまで、そのようなトンネルはアクティブなままです。 逆方向では、Binding Updateを完成するまで、MN SHOULDがトンネルパケットをPARに逆にします。 PAR SHOULDはトンネルで目的地(すなわち、ミネソタの通信員への)に内側のパケットを送ります。 そのような逆のトンネルは、ソースIPアドレスとしてPCoAを含むパケットがイングレスフィルタリングのため落とされないのを確実にします。 読者
Koodli, Ed. Experimental [Page 6] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[6ページ]RFC4068の速い身柄の引き渡し
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.
ミネソタが新しいリンクでIPできますが、それが直接通信員のいない最初に拘束力があるキャッシュエントリーを設置する(NCoAのために)通信員と共にNCoAを使用できないのを観測するかもしれません。 ミネソタとPARの間の逆のトンネルを通してPCoAの推進サポートを提供します。
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がミネソタの存在を検出できないなら。 隣人のアドレス解決(すなわち、Neighbor SolicitationとNeighbor Advertisement)にかかわる隣人発見操作はかなりの遅延を通常もたらします、複数の秒が時々続いて。 例えば、到着パケットがミネソタが付く前にNeighbor Solicitationを送るNARの引き金となるとき、アドレス解決のその後の「再-トランスミッション」はそれぞれ1秒のデフォルトの期間までに切り離されます。 この遅れを回避するために、ミネソタはNARがミネソタが届いていると考えることができるFNAメッセージを通して付属を発表します。 どんな既存のエントリーもなければ、FNAはNARに1つを作成させます。 NARにエントリーが既にあるなら、FNAは潜在的アドレス闘争を考慮に入れている間、エントリーをアップデートします。 PCoAのためのトンネル設立と速い広告で、プロトコルはパケットの完全優先転送をミネソタに提供します。
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が許容できると確認するメッセージを交換できます。 例えば、ミネソタがPARのリンクからFBUを送るとき、NARが、使用において、NCoAが許容できると考えた後にFBackを届けることができます。 アドレスがアクセスルータによって割り当てられるとき、これは特に役に立ちます。 また、NARは提供する前のミネソタのサポートを進めるPARとの信用関係を当てにすることができます。 すなわち、それはNCoAのためにそれが信じるPARからの「承認」を条件として推進エントリーを作成するかもしれません。 最終的に、アクセスルータはネットワーク固有の関係を移すかもしれません、アクセス管理や、QoSや、ヘッダー圧縮などのように、引き渡しに関連して。これらの操作のために、プロトコルは「引き渡し開始(HI)」と「引き渡しは(ハッキング)を承認すること」にメッセージを提供します。 これらのメッセージの両方を支持しなければならない、SHOULD、使用されてください。 アクセスルータで、このドキュメントの範囲の外の手段で必要なセキュリティ協会を設立しなければなりません。
3.2. Protocol Operation
3.2. プロトコル操作
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
ミネソタがサブネット特殊情報に1Access Point Identifiersを決議するためにアクセスルータにRtSolPrを送るとき、プロトコルは始まります。 応答では、アクセスルータ(例えば、図1のPAR)は1[AP-ID、AR-インフォメーション]tuplesを含むPrRtAdvメッセージを送ります。 または例えば、ミネソタが都合のよい時にいくつかのリンク特有の出来事(「引き金」)への応答としてRtSolPrを送るかもしれない。
Koodli, Ed. Experimental [Page 7] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[7ページ]RFC4068の速い身柄の引き渡し
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.
ルータ発見を実行した単に後に。 しかしながら、期待は送付RtSolPrの前では、ミネソタがリンク特有の方法で利用可能なAPsを発見してしまうだろうということです。 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メッセージに情報を提供していて、リンクの特定の引き渡し出来事が起こると、ミネソタは、将来のNCoAを定式化して、FBUメッセージを送ります。 FBUの目的はPARがNCoAにPCoAを縛るのを認可することです、到着パケットにミネソタの新しい位置までトンネルを堀ることができるように。 可能であるときはいつも、FBU SHOULD、PARのリンクから、送ってください。 例えば、内部のリンク特定の引き金は前のリンクからFBUトランスミッションを可能にするかもしれません。 それが可能でないときに、新しいリンクからFBUを送ります。 FBUで使用されるNCoAがリンクの上のある他のノードで既に使用中のアドレスと衝突しないのを保証するために注意しなければなりません。 これ、FNA MUSTの中のFBUカプセル化、実行されてください、SHOULD、NARのリンクからFBUを送るときには使用してください(以下を見ます)。
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.
前のリンク(明確に第一にFBUを送ったかどうかによる)の上にFBackを受け取るかどうかによって、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. ミネソタは前のリンクの上のFBackを受けます。 これは、パケットトンネリングがNARへのミネソタの身柄の引き渡しで既に進行していることを意味します。 NARに付く直後MN SHOULDはFNAを送ります、すぐ到着とバッファリングされたパケットをミネソタに送ることができるように。
Before sending an FBack to an MN, PAR can determine whether the
NCoA is acceptable to the NAR through the exchange of HI and HAck
messages. When assigned addressing (i.e., addresses are assigned
by the router) is used, the proposed NCoA in the FBU is carried in
HI, and the NAR MAY assign the proposed NCoA. Such an assigned
NCoA MUST be returned in HAck, and the PAR MUST in turn provide
the assigned NCoA in the FBack. If there is an assigned NCoA
returned in the FBack, the MN MUST use the assigned address (and
not the proposed address in the FBU) upon attaching to NAR.
FBackをミネソタに送る前に、PARは、NCoAがHIとHAckメッセージの交換を通してNARに許容できるかどうか決定できます。 割り当てられると、アドレシング(すなわち、アドレスはルータによって割り当てられる)は使用されています、そして、FBUの提案されたNCoAはHIで運ばれます、そして、NAR MAYは提案されたNCoAを割り当てます。 HAckでそのような割り当てられたNCoAを返さなければなりません、そして、PAR MUSTは順番に割り当てられたNCoAをFBackに供給します。 FBackで返された割り当てられたNCoAがあれば、ミネソタは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
2. ミネソタは、ミネソタがFBUを送らないか、FBU(それ自体で失われるかもしれない)を送った後にリンクに出られますが、FBackを受ける前にミネソタが出られたので、前のリンクの上のFBackを受けません。 後者の場合でFBackを受けないで、ミネソタは、PARが首尾よくFBUを処理したかどうかを確かめることができません。 したがって、NARに付くとすぐに、それ(re)はFBUを送ります。 NARを有効にするために
Koodli, Ed. Experimental [Page 8] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[8ページ]RFC4068の速い身柄の引き渡し
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.
すぐに(FBUが処理されたとき)、パケットを進めて、NARが、NCoAが許容できるかどうか確かめるのを許容するために、MN SHOULDはFNAでFBUを要約します。 FNAを処理するとき、NARがそれを検出するならNCoAが使用中であり、例えば、隣人エントリーを作成している間、それは、「隣人広告は(NAACK)を承認する」というNAR MAYがミネソタが使用する交互のIPアドレスを含んでいるオプションで内側のFBUパケットを捨てて、Router Advertisementを送らなければなりません。 この捨てるのはアドレス衝突から生じるまれで望ましくない結果を避けます。 詳細な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.
ミネソタがFBUを送って、PARのリンクの上のFBackを受けるシナリオは図2で例証されます。 便利において、このシナリオは「予言」の運転モードとして特徴付けられます。 ミネソタがNARのリンクからFBUを送るシナリオは図3で例証されます。 便利において、このシナリオは「反応している」運転モードとして特徴付けられます。 また、反応モードがPARのリンクからFBUを送りましたが、まだFBackを受け取っていない場合を含んでいることに注意してください。
Finally, the PrRtAdv message may be sent unsolicited (i.e., without the MN first sending a RtSolPr). This mode is described in Section 3.3.
最終的に、求められていない状態で(すなわち、ミネソタが最初にRtSolPrを送ることのない)PrRtAdvメッセージを送るかもしれません。 このモードはセクション3.3で説明されます。
3.3. Protocol Operation of Network-initiated Handover
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.
いくつかの無線技術で、ミネソタとネットワークで互いに引き渡しを受けるという決定に達するかもしれませんが、引き渡しコントロールはネットワークであるかもしれません。 これらのネットワークでは、PARはネットワークが、引き渡しが差し迫っていると決めるときNARのリンクレイヤアドレス、IPアドレス、およびサブネット接頭語を含む求められていないPrRtAdvを送ることができます。 ミネソタは、新しいサブネットにおけるアドレスの新しい注意を構成するためにこのPrRtAdvを処理しなければならなくて、新しいリンクに切り替わる前に、FBUをPARに送らなければなりません。 PrRtAdvを伝えた後に、PAR MUSTは、FBUが受け取られているまで現在のリンクの上のミネソタにパケットを送り続けています。 操作の残りはセクション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は地理的に隣接しているサブネットに関して明らかにその情報を要求しなければならないミネソタなしでネットワークをミネソタに知らせさせます。 これはミネソタがリンクとサブネットの近所トポロジー地図を入手するのに必要である無線の交通の量を減少させることができます。 PrRtAdvのそのような使用法は実際の引き渡しから衝撃を吸収されます。 セクション6.1.2を見てください。
Koodli, Ed. Experimental [Page 9] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[9ページ]RFC4068の速い身柄の引き渡し
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FNA --------------------------->|
|<=================================== deliver packets
| |
ミネソタ平価NAR| | | |------RtSolPr------->|、| | <、-、-、-、--PrRtAdv--------| | | | | |------FBU----------->|、-、-、-、-、-、-、--こんにちは--------->|、| | <、-、-、-、-、--ハッキング---------| | <--FBack---|--FBack--->|、|、|、| 前方に連絡を断ってください。| | パケット===============>|、|、|、|、|、|、| 接続してください。| | | | | |--------- FNA--------------------------->| |<================== パケットを届けてください。| |
Figure 2: "Predictive" Fast Handover
図2: 速い「予言」の引き渡し
4. Protocol Details
4. プロトコルの詳細
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つ以上の近いアクセスポイントを発見した後に、ミネソタは、サブネットルータ情報にアクセスポイント識別子を決議するためにRtSolPrを送ります。 これは、ルータ発見を実行した後にするのに便利です。 しかしながら、例えば、1つ以上の新しいアクセスポイントがいつでも発見されるとき、ミネソタはRtSolPrを送ることができます。 また、ミネソタは付属の間の一度より多くのRtSolPrをPARに送ることができます。 送付RtSolPrのための引き金はリンク特有の出来事から発することができます、現在のアクセスポイントがあるフェージング信号品質に結びつけられた別のアクセスポイントからの、より良い信号強度の約束などのように。 このドキュメントの範囲の外に「L2引き金」としばしば広く呼ばれたそのような出来事があります。 それにもかかわらず、これを呼び出す出来事が議定書を作るとき、それらは役立ちます。 例えば、すぐに新しいリンクの上に「結び付いてください」という指示を得るとき、プロトコルメッセージ(例えば、FNA)を送ることができます。 可能であるときはいつも、実現SHOULDはそのような引き金を利用します。
Koodli, Ed. Experimental [Page 10] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[10ページ]RFC4068の速い身柄の引き渡し
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|------FNA[FBU]-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| |
ミネソタ平価NAR| | | |------RtSolPr------->|、| | <、-、-、-、--PrRtAdv--------| | | | | 分離| | | | | | | | 接続してください。| | |------FNA[FBU]-------|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| | <、-、-、-、--FBU-----------| | |------FBack-------->|、| 転送| | パケット===============>|、|、|、| |<================== パケットを届けてください。| |
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を含んでいます。 ワイルドカードはすべての利用可能なtuplesを要求します。
As a response to RtSolPr, PAR sends a PrRtAdv message that indicates one of the following possible conditions.
RtSolPrへの応答として、PARは以下の可能な条件の1つを示す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がエントリーを新しいアクセスポイントに対応するようにしないなら、新しいアクセスポイントが未知であることを示して、それは応じなければなりません。 ミネソタは現在のリンクで速い引き渡しプロトコル操作を止めなければなりません。 ミネソタは新しいリンクから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の現在のインタフェース(ミネソタが付けている)につなげられるなら、PAR MUSTはCode値が、新しいアクセスポイントが現在のインタフェースにつなげられるのを示していて応じますが、少しの接頭語情報も送りません。 数個のワイヤレス・アクセスポイントが有線ネットワークに橋を架けられるとき、例えば、このシナリオは起こることができました。 さらなるどんなプロトコル動作も必要ではありません。
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 MUSTは新しいアクセスポイントが知られているのを示しながら応じて、[AP-ID、AR-インフォメーション]tupleを供給します。 新しいアクセスポイントが知られていますが、速い引き渡しを支持しないなら、PAR MUSTはCode3と共にこれを示します(セクション6.1.2を見てください)。
Koodli, Ed. Experimental [Page 11] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[11ページ]RFC4068の速い身柄の引き渡し
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 SHOULDは経路MTU制限を受けることがある近所[AP-ID、AR-インフォメーション]tuplesを供給します(すなわち、リンクMTUを超えていなくて、'いずれとtuplesを提供してください)。
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で入って来るパケットのコピーをバッファリングし始めるのを選ぶかもしれません。 そのような先入れ先出し法バッファリングが使用されているなら、PAR MUSTは、PCoA(すなわち、バッファとフォワード)にパケットを送り続けています。 ミネソタがPARのリンクからFBUメッセージを送らないでいなくなるとき、そのようなバッファリングは役に立つ場合があります。 PAR SHOULDは、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.
このドキュメントの範囲の外にAccess Routersが彼らの隣人に関して情報交換して、その結果隣接しているサブネットの情報でProxy Router Advertisementsの構造を許容する方法があります。
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メッセージを実行しなければなりません。 しかしながら、リンクレイヤ引き渡しメカニズム自体でミネソタがすぐ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メッセージが処理された後に、ミネソタは、リンク特有の出来事で決定している時にFBUを送って、提案されたNCoAを含めます。 引き渡しの「予期」が可能であるときはいつも、MN SHOULDはPARのリンクからFBUを送ります。 予期が可能でないか、またはNARのリンクに付く直後それがFBackを受けていないのに、ミネソタはFBUを送ります。 このFBU SHOULD、FNAメッセージで要約されてください。 カプセル化で、アドレス闘争が(外側)のFNAパケット処理の結果、検出されるなら(以下でのFNA処理を見てください)、NARは(内側)のFBUパケットを捨てることができます。 FBUに対応して、PARはPCoA(「ホームアドレス」)とNCoAの間で結合を確立して、FBackをミネソタに送ります。 この結合を確立する前に、PAR SHOULDはHIメッセージをNARに送って、応答でHAckを受けます。 HIメッセージのためのNARのアドレスを決定するために、PARは隣接しているアクセスルータの接頭語リストでNCoA(FBUの)の最も長い接頭語マッチを実行できます。 FBUのソースIPアドレスがPCoAであるときに、PARのリンクからすなわち、FBUを送ります、そして、HIメッセージで、Code値を0に設定しなければなりません。 セクション6.2.1を見てください。 HIメッセージには、FBUのソースIPアドレスがPCoAでないときに、NARのリンクからすなわち、FBUを送って、1のCode値がなければなりません。 セクション6.2.1を見てください。
Koodli, Ed. Experimental [Page 12] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[12ページ]RFC4068の速い身柄の引き渡し
The HI message contains the PCoA, Link-Layer Address, and the NCoA of the MN. In response to processing an HI message with Code 0, the NAR
HIメッセージはPCoA、Link-層のAddress、およびミネソタのNCoAを含んでいます。 Code0、NARと共にHIメッセージを処理することに対応して
1. determines whether NCoA supplied in the HI message is a valid
address for use. If it is, the NAR starts proxying [6] the
address for PROXY_ND_LIFETIME during which the MN is expected to
connect to the NAR. The NAR MAY use the Link-Layer Address to
verify whether a corresponding IP address exists in its forwarding
tables.
1.、HIメッセージで供給されたNCoAが使用のための有効なアドレスであるか否かに関係なく、決定します。 それがそうなら、NARは[6] _PROXY_ノースダコタLIFETIMEへのミネソタがNARに接続すると予想されるアドレスをproxyingし始めます。 NAR MAYは、対応するIPアドレスが推進テーブルに存在するかどうか確かめるのにAddress Link-層を使用します。
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.、割り当てられたアドレシングが使用されているとき、NCoAをミネソタに割り当てて、プロキシ隣人キャッシュエントリーを作成して、それを防御し始めます。 NAR MAYは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のためにホストルートエントリーを作成するかもしれません。 このホストルートエントリーSHOULDはミネソタの存在まで検出されるどちらかミネソタによる明白な発表による実行されたそのようなものであるか他の手段、到着しているパケットで隣人発見を呼び出しません。 また、NAR MAYはこの場合逆のトンネルをPARに設立します。
4. provides the status of the handover request in the Handover
Acknowledge (HAck) message.
4.、Handover Acknowledge(HAck)メッセージにおける引き渡し要求の状態を提供します。
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.
FNA処理の間、それらの操作を実行したでしょう、したがって、HIのCode値が1であるときに、NAR MUSTは上の操作をサボります。 しかしながら、それ、SHOULD、将来定義されるかもしれないいかなる他のオプションも処理するように用意してください。 Code1があるHIメッセージを送るのに、NARはそれがFNA処理の間にミネソタに作成する隣人キャッシュエントリーを有効にすることができます。 すなわち、NARは信じられた同輩(すなわち、PAR)にはミネソタとの信用関係があるという知識を利用できます。
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.
HAckが割り当てられたNCoAを含んでいるなら、FBackはそれを含まなければなりません、そして、ミネソタはFBackに提供されたアドレスを使用しなければなりません。 ミネソタがまだ存在している場合、PAR MAYは、より速いレセプションを容易にするために前のリンクにFBackを送ります。 FBUとFBack処理の結果はPARがミネソタのパケットにNCoAにトンネルを堀り始めるということです。 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.
ミネソタがNARと共にリンクの接続性を確立して、それがSHOULDである、Fast Neighbor Advertisement(FNA)メッセージを送ってください、(見る、6.3、.3、) ミネソタが受信されていないなら、FNAまでにFBackを送ります、それ。SHOULDはFNAでFBUを要約して、それらを一緒に送ります。
Koodli, Ed. Experimental [Page 13] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[13ページ]RFC4068の速い身柄の引き渡し
When the NCoA corresponding to the FNA message is acceptable, the NAR MUST
FNAメッセージに対応するNCoAが許容できるときNAR MUST
1. delete its proxy neighbor cache entry, if any is present.
1. いずれか存在しているなら、プロキシ隣人キャッシュエントリーを削除してください。
2. create a neighbor cache entry and set its state to REACHABLE
without overwriting an existing entry for a different layer 2
address.
2. 2が記述する異なった層のための既存のエントリーを上書きしないで、隣人キャッシュエントリーを作成してください、そして、REACHABLEに状態を設定してください。
3. forward any buffered packets.
3. あらゆるバッファリングされたパケットを進めてください。
4. enable the host route entry for PCoA, if any is present.
4. いずれか存在しているなら、PCoAのためにホストルートエントリーを可能にしてください。
When the NCoA corresponding to the FNA message is not acceptable, the NAR MUST
FNAメッセージに対応するNCoAが許容できないときNAR MUST
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オプションでRouter Advertisementを送ってください。 FNAの現在の同じLayer2アドレスを使用して、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.
ミネソタがNAACKオプションでRouter Advertisementを受けるなら、それはもしあればNAACKオプションに提供されたIPアドレスを使用しなければなりません。 さもなければ、ミネソタは別のNCoAを構成するべきです。 次に、MN SHOULDは、新しいCoAを使用することでFBUを送ります。 特殊なものとして、NAACKで供給されたアドレスがPCoA自身であるかもしれない、その場合、ミネソタはそれ以上のFBUsを送ってはいけません。
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.
かつて、ミネソタはNCoAを確認して、それはSHOULDです。Neighbor Advertisementメッセージを送ってください。 このメッセージで、ミネソタの隣人はミネソタのアドレスで彼らの隣人キャッシュエントリーをアップデートできます。
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'ビットをPrefix情報オプションにはめ込んで、ルータ通知で128ビットのグローバルアドレスを含めます。 これで、可動のノードはPARのグローバルなIPv6アドレスを学ぶことができます。 ミネソタ逆はPARの同じグローバルアドレスにパケットにトンネルを堀ります。 それに従って、トンネルエンドポイントアドレスを構成しなければなりません。 PARが逆のトンネルを堀られたパケットを受けるとき、安全な結合がトンネルを堀られたパケットのPCoAによって特定されたミネソタに存在するかどうか確かめなければなりません、パケットを進める前に。
Koodli, Ed. Experimental [Page 14] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[14ページ]RFC4068の速い身柄の引き渡し
5. Miscellaneous
5. その他
5.1. Handover Capability Exchange
5.1. 引き渡し能力交換
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.
ミネソタはRtSolPrメッセージに対応してPrRtAdvを予想します。 ミネソタが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).
ミネソタの現在のアクセスルータは速い引き渡しができても、ミネソタが付く新しいアクセスルータが速い引き渡しで不可能であるかもしれません。これは「ランタイム」の間、ミネソタに示されます、3のCode値があるPrRtAdvメッセージを通して(セクション6.1.2を見てください)。
5.2. Determining New Care of Address
5.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.
ミネソタは、通常、PrRtAdvメッセージに提供された情報を使用することで将来のNCoAを定式化して、FBUを送ります。 PAR MUSTはHIメッセージでFBUの現在のNCoAを使用します。 NAR MUSTは、HIの現在のNCoAが既に使用中であるかどうか確かめます。 どのような場合でも、NAR MUSTはそれが別のNCoAを使用に含むかもしれないHAckを使用することでHIに応じます、特に割り当てられたアドレス構成が使用されているとき。 HAckの現在のCoAがあれば、PAR MUSTはFBackメッセージにそれを含んでいます。
If a PrRtAdv message carries an NCoA, the MN MUST use it as its prospective NCoA.
PrRtAdvメッセージがNCoAを運ぶなら、ミネソタは将来のNCoAとしてそれを使用しなければなりません。
5.3. Packet Loss
5.3. パケット損失
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.
引き渡しはリンクの切り換えにかかわります。(速い引き渡しが合図している状態で、それは、まさに調整されないかもしれません)。 その上、パケットの到着パターンはアプリケーションの特性、ネットワーク列を作りの振舞いなどを含む多くの要素に依存しています。 したがって、ミネソタがそこにリンクを設立できる前にパケットはNARに到着するかもしれません。 それらがNARによってバッファリングされないと、これらのパケットは失われるでしょう。 同様に、ミネソタがNARに付いて、次に、FBUメッセージを送って、それらがバッファリングされないと、PARに到着するパケットは失われるでしょう。 このプロトコルは、HIメッセージのNARでのバッファリングを求める要求を示すためにオプションを提供します。 PARはこの特徴(ミネソタへの)を要求して、それはSHOULDです。いつ、また、それ自身のバッファリングのサポートを提供してくださいか。
Koodli, Ed. Experimental [Page 15] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[15ページ]RFC4068の速い身柄の引き渡し
5.4. DAD Handling
5.4. おとうさんの取り扱い
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.
写しAddress Detection(DAD)は、国がないアドレス自動構成が使用されているとき、リンクでアドレス重複を避けるために[7]で定義されました。 国がない自動構成を通して構成されたIPv6アドレスのユニークさについて確かめるDADの使用は引き渡しに遅れを加えます。
The probability of an interface identifier duplication on the same subnet is very low, however it cannot be ignored. In this document, certain precautions are proposed to minimize the effects of a duplicate address occurrence.
同じサブネットにおけるインタフェース識別子複製の確率が非常に低い、しかしながら、それを無視できません。 本書では、ある注意は、写しアドレス発生の効果を最小にするために提案されます。
In some cases, the NAR may already have the knowledge required to assess whether the MN's address is a duplicate before the MN moves to the new subnet. For example, the NAR can have a list of all nodes on its subnet, perhaps for access control, and by searching this list, it can confirm whether the MN's address is a duplicate. The result of this search is sent back to the PAR in the HAck message. If such knowledge is not available at the NAR, it may indicate this by not confirming the NCoA in the HAck message. The NAR may also indicate this in the NAACK option in response to the FNA message. In such cases, the MN would have to follow the address configuration procedure according to [6] after attaching to the NAR.
いくつかの場合、NARには、ミネソタが新しいサブネットに動く前にミネソタのアドレスが写しであるか否かに関係なく、評価するのに必要な知識が既にあるかもしれません。 例えば、NARはサブネットと、恐らくアクセス管理と、このリストを捜すことによって、すべてのノードのリストを持つことができます、とそれはミネソタのアドレスが写しであるか否かに関係なく、確認できます。 HAckメッセージのPARはこの検索の結果に送り返されます。 そのような知識がNARで利用可能でないなら、それは、HAckメッセージでNCoAを確認しないことによって、これを示すかもしれません。 また、NARはFNAメッセージに対応してNAACKオプションでこれを示すかもしれません。 そのような場合、[6]によると、ミネソタはNARに付いた後に、アドレス構成手順に従わなければならないでしょう。
5.5. Fast or Erroneous Movement
5.5. 速いか誤った運動
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.
この仕様は速い引き渡しのためのものですが、ミネソタがどれくらい速く動くことができるかに関してプロトコルは制限されます。 ピング悪臭は速い運動の特別なケースです。(そこでは、ミネソタが同じ2つのアクセスポイントの間を急速に動きます)。 同じ問題の別の例が誤った運動である、すなわち、ミネソタは新しいアクセスポイントに動いていますが、それが異なったものに動かされるか、または全体で動きを中止するという引き渡しの前の情報を受け取ります。 上の振舞いのすべてが、通常リンクレイヤ特異性の結果であり、その結果、リンクレイヤ自体でしばしば決議されています。
IP layer mobility, however, introduces its own limits. IP layer handovers should occur at a rate suitable for the MN to update the binding of, at least, its HA and preferably that of every CN with which it is in communication. An MN that moves faster than necessary for this signaling to complete, which may be a few seconds, may start losing packets. The signaling cost over the air interface and in the network may increase significantly, especially in the case of rapid movement between several access routers. To avoid the signaling overhead, the following measures are suggested.
しかしながら、IP層の移動性はそれ自身の限界を導入します。 IP層の身柄の引き渡しはミネソタが少なくともHAの結合と望ましくはそれがコミュニケーションにあるあらゆるCNのものをアップデートするのにおいて適当な速度で起こるべきです。 完成する数秒であるかもしれないこのシグナリングに必要とするより速く動くミネソタは、パケットを失い始めるかもしれません。 空気インタフェースとネットワークにおけるシグナリング費用はかなり上がるかもしれません、特にいくつかのアクセスルータの間の急速な運動の場合で。 シグナリングオーバーヘッドを避けるために、以下の測定は示されます。
Koodli, Ed. Experimental [Page 16] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[16ページ]RFC4068の速い身柄の引き渡し
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 MUSTがミネソタのPCoAと等しいホームAddressとFast Binding Updateを送るPARへのゼロの生涯の前にPARに戻るミネソタ。 速い引き渡しをNARに実行したので、ミネソタには、PARとのセキュリティ協会があるべきです。 このFast Binding Updateを受けるとき、PARは出発している(一時的な速い引き渡し)トンネルのセットをチェックするでしょう。 それであるなら、掘り出し物のaは合って、それはそのトンネル(すなわち、代わりにこれのためのパケットにミネソタを転送して、直接パケットを配達する始めにノードを転送するのを止める)の下側へのSHOULD裂け目です。 MN SHOULD NOTは、この仕様で説明されたメカニズムとSHOULDが標準のモバイル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.
速い身柄の引き渡しの目的のための一時的なトンネルは短い生涯(少ない数の秒か以下)を費やすはずです。 そのようなトンネルの寿命は、ミネソタがすべての活発な結合をアップデートするのを許容するために十分であるべきです。 トンネルの寿命が生涯と同じくらいが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が別のルータに向かってパケットを送るかもしれないので、誤った運動の効果はパケットの損失に通常制限されます。 ミネソタ自体が、思いがけないアクセスルータ、PAR SHOULDへのFast Binding Updateで送られるように発見するなら。 以来Fast Binding Updatesは認証されて、彼らは存在結合とパケットがそうしなければならないsupercedeです。ミネソタの新たに確認された位置に向け直されます。
6. Message Formats
6. メッセージ・フォーマット
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]で一般的なTypeを指定します。 メッセージはSubtype分野に基づいて区別されます(以下を見てください)。 Subtypesのための値はセクション9で指定されます。 すべてのICMPv6メッセージに関しては、チェックサムは[2]で定義されます。
6.1. New Neighborhood Discovery Messages
6.1. 新しい近所発見メッセージ
6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr)
6.1.1. プロキシ広告のためのルータ懇願(RtSolPr)
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.
Proxy Router Advertisementsのためにルータをうながして、モバイルNodesはProxy AdvertisementのためにRouter Solicitationを送ります。 すべてのLink-層のAddressオプションには、6.4で.3に定義された書式があります。
Koodli, Ed. Experimental [Page 17] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[17ページ]RFC4068の速い身柄の引き渡し
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype| 予約されます。| 識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Router Solicitation for Proxy (RtSolPr) Message
図4: プロキシ(RtSolPr)メッセージのためのルータ懇願
IP Fields:
IP分野:
Source Address
An IP address assigned to the sending interface.
送付インタフェースに割り当てられたソースAddress An IPアドレス。
Destination Address
The address of the Access Router or the all routers
multicast address.
または、目的地Address、Access Routerのアドレス、すべてのルータマルチキャストアドレス。
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 Authentication Headerのための認証Header If a Security Associationは送付者と送付先アドレスの間に存在していて、次に、送付者SHOULDはこのヘッダーを含んでいます。 RFC2402[5]を見てください。
ICMP Fields:
ICMP分野:
Type The Experimental Mobility Protocol Type. See [4].
実験移動性プロトコルタイプをタイプしてください。 [4]を見てください。
Code 0
コード0
Checksum The ICMPv6 checksum.
チェックサム、ICMPv6チェックサム。
Subtype 2
Subtype2
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.
送付者は、このSolicitationに回答に合うことができるように識別子を設定しなければなりません。
Koodli, Ed. Experimental [Page 18] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[18ページ]RFC4068の速い身柄の引き渡し
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.
ソースは含まれている使用がLink-層のAddressオプションであったなら知られているAddress When、送付者SHOULDのAddress Link-層をLink層にします。 以下の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.
新しいAccess Point Link-層のAddress Address Link-層かミネソタがルーティング広告情報を要求するアクセスポイントの識別。 すべてのRtSolPrメッセージにそれを含まなければなりません。 アドレスかそのような識別子の1つ以上が、存在している場合があります。 また、この分野はゼロに設定されたすべてのビットがあるワイルドカードアドレスであるかもしれません。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options that they do not recognize and continue processing the rest of the message.
このプロトコルの将来のバージョンは新しいオプションタイプを定義するかもしれません。 受信機は、静かに、彼らが認識しない少しのオプションも無視して、メッセージの残りを処理し続けなければなりません。
Including the source LLA option allows the receiver to record the sender's L2 address so that neighbor discovery can be avoided when the receiver needs to send packets back to the sender (of the RtSolPr message).
ソースLLAオプションを含んでいるのに、受信機は、受信機が、送付者(RtSolPrメッセージの)にパケットを送り返す必要があるとき、隣人発見を避けることができるように送付者のL2アドレスを記録できます。
When a wildcard is used for a New Access Point LLA, no other New Access Point LLA options must be present.
ワイルドカードがNew Access Point LLAに使用されるとき、他のどんなNew Access Point 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.
Proxy Router Advertisement(PrRtAdv)メッセージはRtSolPrに対応してミネソタによって受け取られるべきです。 メッセージはそのようなものであるなら直ちに受け取られません(少なくともアクセスリンクか100ミリセカンドの上の典型的な周遊旅行時間(RTT)の2倍はRTTであるなら知られていません)、それ。SHOULDはRtSolPrメッセージを再送します。 その後の「再-トランスミッション」は、RTSOLPR_RETRIESまであることができますが、タイムアウト時間(すなわち、2xRTTか100ミリセカンド)が「再-トランスミッション」の各例の前に倍にされる指数のbackoffを使用しなければなりません。 Proxy Router AdvertisementがPARからのミネソタの分離で受け取られないなら、新しいCoAを構成する直後MN SHOULDは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メッセージに送るとき、それらは1秒あたりマックス_RTSOLPR_RATEと共に制限されたレートであるに違いありません。 RtSolPrの各使用の間、指数のbackoffは「再-トランスミッション」に使用されます。
Koodli, Ed. Experimental [Page 19] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[19ページ]RFC4068の速い身柄の引き渡し
6.1.2. Proxy Router Advertisement (PrRtAdv)
6.1.2. プロキシルータ通知(PrRtAdv)
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.
アクセスルータは、ミネソタから引き渡しがネットワークによって開始されているなら無償でメッセージをProxy Router Advertisementに送るか、またはRtSolPrメッセージへの応答としてそうします、隣接しているルータのAddress Link-層、IPアドレス、およびサブネット接頭語を提供して。 すべてのLink-層のAddressオプションには、セクション6.4.3で定義された書式があります。
IP Fields:
IP分野:
Source Address
MUST be the Link-Local Address assigned to the
interface from which this message is sent.
ソースAddressはこのメッセージが送られるインタフェースに割り当てられたLink地方のAddressであるに違いありません。
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.
Proxy Advertisementのための呼び出しRouter Solicitationの目的地Address Source AddressかAccess Routerが引き渡しに命令しているノードのアドレス。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype| 予約されます。| 識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
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 Authentication Headerのための認証Header If a Security Associationは送付者と送付先アドレスの間に存在していて、送付者SHOULDはこのヘッダーを含んでいます。 RFC2402[5]を見てください。
ICMP Fields:
ICMP分野:
Type The Experimental Mobility Protocol Type. See RFC
4065 [4].
実験移動性プロトコルタイプをタイプしてください。 RFC4065[4]を見てください。
Code 0, 1, 2, 3 or 4. See below.
0、1、2、3または4をコード化してください。 以下を見てください。
Koodli, Ed. Experimental [Page 20] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[20ページ]RFC4068の速い身柄の引き渡し
Checksum The ICMPv6 checksum.
チェックサム、ICMPv6チェックサム。
Subtype 3
Subtype3
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.
Proxy AdvertisementかセットのためのRouter SolicitationからZeroまでの識別子Copied、求められていません。
Valid Options in the following order:
以下の有効な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.
ソースは含まれている使用がLink-層のAddressオプションであったなら知られているAddress When、送付者SHOULDのAddress Link-層をLink層にします。 以下の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.
新しいAccess Point Link-層のAddress Address Link-層かアクセスポイントの識別が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.
新しいRouterはこのメッセージがproxiedされるAccess RouterのLink-層のAddress Address Link-層です。 Codeが0か1歳であるときに、このオプションを含まなければなりません。
New Router's IP Address
The IP address of NAR. This option MUST be
included when Code is 0 or 1.
IPが扱う新しいRouterのNARのIP Address。 Codeが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.
新しいルータ接頭語情報オプション。 メッセージがproxiedされて、アドレス自動構成に使用されるAccess Routerの接頭語を指定します。 Codeが0か1歳であるときに、このオプションを含まなければなりません。 しかしながら、この接頭語がNew RouterのIP Addressオプション(above)に使用されるそれと同じであるときに、Prefix情報オプションは存在している必要はありません。
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 Optionはそうするかもしれません。 PAR MAYはNARの接頭語情報とミネソタのL2アドレスを使用することで新しいCoAを計算するか、またはいかなる他の手段でもそうします。
Koodli, Ed. Experimental [Page 21] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[21ページ]RFC4068の速い身柄の引き渡し
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.
現在、Code値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.
Code0とProxy Router Advertisementは、ミネソタが動き検出とNCoA定式化に、[AP-ID、AR-インフォメーション]tuple(上のオプションで現在の)を使用するべきであることを意味します。 この場合、New Access Point LLAオプションにおけるOptionコード分野は1です、オプションの残りが関係づけられるアクセスポイントのLLAを反映して。 複数のtuplesが存在しているかもしれません。
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.
Code1とProxy Router Advertisementは、メッセージが送られることを意味します。求められていません。 New Router Prefix情報オプションに続いて、New CoAオプションが存在しているなら、MN SHOULDは、供給されたNCoAを使用して、すぐに、FBUを送るか、またはサービスを失うのをおごります。 このメッセージはネットワークによって開始された引き渡し引き金として機能します。 セクション3.3を見てください。 この場合、New Access Point LLAオプション(以下を見る)におけるOption-コード分野はオプションの残りが関係づけられるアクセスポイントの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.
Code2とProxy Router Advertisementは、どんな新しいルータ情報も存在していないことを意味します。 それぞれのNew Access Point LLAオプションは特定の結果を示すOption-コード値(以下で、説明される)を含んでいます。
- 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.
- New Access Point LLAオプションにおけるOption-コード分野が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.
- New Access Point LLAオプションにおけるOption-コード分野が6であるときに、PARは情報が要求したPrefixを意識していません。 それの次第FBUを送るMN SHOULD試みはNARと共に接続性を取り戻します。 別の選択肢は全くこの場合必要ではありません。
- 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.
- New Access Point LLAオプションにおけるOption-コード分野が7であるときに、それは、NARが速い引き渡しをサポートしないことを意味します。ミネソタは速い引き渡しプロトコル操作を止めなければなりません。 別の選択肢は全くこの場合必要ではありません。
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.
Code3とProxy Router Advertisementは、新しいルータ情報が単に要求されたアクセスポイントの部分集合のために存在していることを意味します。 Option-コード分野値(1の値を含んでいる上で定義される)は異なった結果を個々のアクセスポイントに区別します。
Koodli, Ed. Experimental [Page 22] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[22ページ]RFC4068の速い身柄の引き渡し
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.
Code4とProxy Router Advertisementは、Code1と共に隣接しているアクセスポイントのサブネット情報が送って、求められていなくて、唯一のメッセージがメッセージが送られる時と異なった引き渡し引き金でないということであることを意味します。 複数のtuplesが存在しているかもしれません。
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.
'RtSolPrメッセージでワイルドカードAP識別子を提供するとき、PrRtAdvメッセージは'いずれとPARの近所に対応する[Point Identifierにアクセスしてください、Link-層のAddressオプション、Prefix情報Option]tuplesを含むべきです。
6.2. Inter-Access Router Messages
6.2. 相互アクセスルータメッセージ
6.2.1. Handover Initiate (HI)
6.2.1. 引き渡し開始(HI)
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.
Handover Initiate(HI)はミネソタの引き渡しのプロセスを開始するためにAccess Router(通常PAR)によって別のAccess Router(通常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 ...
+-+-+-+-+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype|S|U| 予約されます。| 識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Handover Initiate (HI) Message
図6: 引き渡し開始(こんにちは)メッセージ
IP Fields:
IP分野:
Source Address
The IP address of the PAR.
IPが扱うPARのソースAddress。
Destination Address
The IP address of the NAR.
IPが扱うNARの目的地Address。
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].
認証、このメッセージを送るとき、認証ヘッダーのHeaderを使用しなければなりません。 RFC2402[5]を見てください。
Koodli, Ed. Experimental [Page 23] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[23ページ]RFC4068の速い身柄の引き渡し
ICMP Fields:
ICMP分野:
Type The Experimental Mobility Protocol Type. See RFC
4065 [4].
実験移動性プロトコルタイプをタイプしてください。 RFC4065[4]を見てください。
Code 0 or 1. See below
0か1をコード化してください。 以下を見てください。
Checksum The ICMPv6 checksum.
チェックサム、ICMPv6チェックサム。
Subtype 4
Subtype4
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旗のAssignedは構成旗を扱います。 設定されると、このメッセージは、目的地によって返されるよう新しいCoAに要求します。 Code=0であるのに、設定されるかもしれません。 0がいつCode=1であったかならそうしなければなりません。
U flag Buffer flag. When set, the destination SHOULD
buffer any packets moving toward the node indicated
in the options of this message. Used when Code =
0, SHOULD be set to 0 when Code = 1.
U旗のBufferは弛みます。 設定されると、目的地SHOULDはこのメッセージのオプションで示されたノードに近づくどんなパケットもバッファリングします。 Code=1であるのに、Codeが0、SHOULDと等しいと使用されているのは、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.
目的地(すなわち、NAR)に引き渡しを受けているミネソタのミネソタAddress Link-層のリンク層のAddress。 目的地がミネソタを認識できるように、このオプションを含まなければなりません。
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.
IPアドレスが起因するルータに付けられている間にミネソタで使用したAddressの前のCare。 必要なら、ホストルートを確立できるように含まれていて、これはSHOULDにゆだねます。
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アドレスミネソタが使用したがっているAddressの新しいCare。 'いつ、'ビットは設定されて、NAR MAYはこのアドレスを割り当てるか。
Koodli, Ed. Experimental [Page 24] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[24ページ]RFC4068の速い身柄の引き渡し
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.
PCoAと共にソースIPアドレスとしてFBUを処理するとき、PARは0のCode値を使用します。 ソースIPアドレスがPCoAでないFBUを処理するとき、PARは1のCode値を使用します。
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.
メッセージはHandover Acknowledge(HAck)であるなら短い期間に応答として受け取られません(ソースと目的地の間の典型的なRTTの2倍ほど少なくないミリセカンドか100ミリセカンドがRTTであるなら知られていません)、Handover Initiate SHOULD。再送します。 その後の「再-トランスミッション」は、HI_RETRIESまであることができますが、タイムアウト時間(すなわち、2xRTTか100ミリセカンド)が「再-トランスミッション」の各インスタンスの間に倍にされる指数のbackoffを使用しなければなりません。
6.2.2. Handover Acknowledge (HAck)
6.2.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.
Handover Acknowledgmentメッセージは回答としてHandover Initiateメッセージに送らなければならない(通常PARへのNAR)新しいICMPv6メッセージです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype| 予約されます。| 識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
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.
このメッセージが応答であるHandover Initiate Messageの送付先アドレスからのソースAddress Copied。
Destination Address
Copied from the source address of the Handover
Initiate Message to which this message is a
response.
このメッセージが応答であるHandover Initiate Messageのソースアドレスからの目的地Address Copied。
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].
認証、このメッセージを送るとき、認証ヘッダーのHeaderを使用しなければなりません。 RFC2402[5]を見てください。
Koodli, Ed. Experimental [Page 25] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[25ページ]RFC4068の速い身柄の引き渡し
ICMP Fields:
ICMP分野:
Type The Experimental Mobility Protocol Type. See RFC
4065 [4].
実験移動性プロトコルタイプをタイプしてください。 RFC4065[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: 引き渡しAccepted、NCoAの有効な1: 有効な2ではなく引き渡しAccepted、NCoA: 引き渡しAccepted、使用3でのNCoA: 引き渡しAccepted、NCoAは4を割り当てました(Assignedアドレシングで、使用されます): 引き渡しAccepted、NCoAは128を割り当てませんでした(Assignedアドレシングで、使用されます): 引き渡しNot Accepted、不特定の129を推論してください: 行政上、130を禁止します: 不十分なリソース
Checksum The ICMPv6 checksum.
チェックサム、ICMPv6チェックサム。
Subtype 5
Subtype5
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.
このメッセージが応答であるHandover Initiateメッセージの対応する分野からの識別子Copied。
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.
Address If Sの新しいCareは弛みます。Handover Initiateメッセージに、セットがあって、このオプションはNCoAを提供するのに使用されて、ミネソタがこのルータに関連づけられたいつを使用するべきであるかということであるに違いありません。 'このオプションが含まれさえするかもしれない、いつ、'噛み付かれているのは、セット、例えば、上のCode2であるか。
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 MUSTはHandover Acknowledgeメッセージで応じます。 '、'旗がHIメッセージに設定されて、NAR SHOULDがAddressオプションのNew CareとCode3を含んでいるということです。
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 MAYは、PCoAと共にソースIPアドレスとして送られたミネソタのパケットを進めるためにPCoA(NCoAを受け入れるか、または割り当てることの代わりに)のサポートを供給して、PCoAのためにホストルートエントリーを設置して、PARにトンネルを設立します。 このホストはエントリーSHOULDを発送します。NARがいったんそれを検出したあとにパケットを進めるのに使用されて、特定のミネソタがリンクに付けられているということになってください。
Koodli, Ed. Experimental [Page 26] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[26ページ]RFC4068の速い身柄の引き渡し
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.
Code値1を含むHIメッセージに応じるとき、HAckメッセージのCode値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.
最終的に、新しいアクセスルータはいつも引き渡しを拒否できます、その場合、それが利用可能なCode値の1つにおける理由を示すべきです。
6.3. New Mobility Header Messages
6.3. 新しい移動性ヘッダーメッセージ
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はMobility Header[3]と呼ばれる新しいIPv6ヘッダータイプを使用します。 Fast Binding Update、Fast Binding Acknowledgment、およびFast Neighbor AdvertisementメッセージはMobility Headerを使用します。
6.3.1. Fast Binding Update (FBU)
6.3.1. 速く、アップデートを縛ります。(FBU)
The Fast Binding Update message is identical to the Mobile IPv6 Binding Update (BU) message. However, the processing rules are slightly different.
Fast Binding UpdateメッセージはモバイルIPv6 Binding Update(BU)メッセージと同じです。 しかしながら、処理規則はわずかに異なっています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K| 予約されます。| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Fast Binding Update (FBU) Message
エイト環: 速く、アップデート(FBU)メッセージを縛ります。
IP fields:
IP分野:
Source Address
The PCoA or NCoA
ソースアドレスのPCoAかNCoA
Destination Address
The IP address of the Previous Access Router
IPが扱うPrevious Access Routerの目的地Address
A flag MUST be set to one to request that PAR send a Fast
Binding Acknowledgment message.
1つにPARがFast Binding Acknowledgmentメッセージを送るよう要求するように旗を設定しなければなりません。
H flag MUST be set to one. See RFC 3775 [3].
H旗を1つに設定しなければなりません。 RFC3775[3]を見てください。
L flag See RFC 3775 [3].
L旗のSee RFC3775[3]。
Koodli, Ed. Experimental [Page 27] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[27ページ]RFC4068の速い身柄の引き渡し
K flag See RFC 3775 [3].
K旗のSee RFC3775[3]。
Reserved This field is unused. MUST be set zero.
予約されたThis分野は未使用です。 セットがゼロであったならそうしなければなりません。
Sequence Number
See RFC 3775 [3].
一連番号はRFC3775[3]を見ます。
Lifetime See RFC 3775 [3].
寿命はRFC3775[3]を見ます。
Mobility Options
MUST contain an alternate CoA option set to the
NCoA when an FBU is sent from PAR's link.
PARのリンクからFBUを送るとき、移動性Optionsは代替のCoAオプションセットをNCoAに含まなければなりません。
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.
ミネソタは、PrRtAdvメッセージを受け取りながら、いつでもFBUメッセージについて伝言を伝えます。 ミネソタが受信の前に移行するなら、a PrRtAdvは通信します、それ。NCoAを構成した後に、NeighborディスカバリーとIPv6 Address Configurationプロトコルに応じて、SHOULDはNARで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.
PARのリンクからFBUを送るとき、ソースIPアドレスはPCoAです、そして、NARのリンクから送ると、ソースIPアドレスはNCoAです。 いつNARのものからFBUを送るかはリンクされて、それはSHOULDです。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 MUSTはホームAddress Optionを含んでいます、そして、ホームAddressはPCoAです。 FBUメッセージを保護しなければならないので、PARは、FBUメッセージが本物のミネソタによって送られることを決定できます。
6.3.2. Fast Binding Acknowledgment (FBack)
6.3.2. 速く、承認を縛ります。(FBack)
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.
Fast Binding Acknowledgmentメッセージは、'A'ビットが設定されるFast Binding Updateメッセージの領収書を受け取ったことを知らせるためにPARによって送られます。 Fast Binding AcknowledgmentはSHOULD NOTを通信させます。PARがNARからHAckメッセージを受け取る前にミネソタに送ります。 また、古いリンクの上のミネソタにFast Binding Acknowledgmentを送るかもしれません。
Koodli, Ed. Experimental [Page 28] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[28ページ]RFC4068の速い身柄の引き渡し
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態|K| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Fast Binding Acknowledgment (FBack) Message
図9: 速く、承認(FBack)メッセージを縛ります。
IP fields:
IP分野:
Source Address
The IP address of the Previous Access Router.
IPが扱うPrevious Access RouterのソースAddress。
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:
状態、Fast Binding Updateの気質を示す8ビットの符号のない整数。 128未満であるStatus分野の値は、Binding Updateが受信ノードによって受け入れられたのを示します。 そのようなStatusが評価する以下は現在、定義されます:
0 Fast Binding Update accepted
1 Fast Binding Update accepted but NCoA is
invalid. Use NCoA supplied in "alternate" CoA
0 速く、Binding Updateは、1Fast Binding Updateが受け入れられると受け入れましたが、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以上であるStatus分野の値は、Binding Updateが受信ノードによって拒絶されたのを示します。 そのようなStatusが評価する以下は現在、定義されます:
128 Reason unspecified
129 Administratively prohibited
130 Insufficient resources
131 Incorrect interface identifier length
128 不特定の129Administrativelyが130のInsufficientリソース131Incorrectインタフェース識別子の長さを禁止した理由
`K' flag See RFC 3775 [3].
'K'旗のSee RFC3775[3]。
Reserved An unused field. MUST be set to zero.
予約されたAn未使用の分野。 ゼロに設定しなければなりません。
Koodli, Ed. Experimental [Page 29] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[29ページ]RFC4068の速い身柄の引き渡し
Sequence Number
Copied from the FBU message for use by the MN in
matching this acknowledgment with an outstanding
FBU.
傑出しているFBUにこの承認に合うことにおけるミネソタによる使用へのFBUメッセージからの系列Number Copied。
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.
移動性OptionsはStatusが1歳であるなら「代替の」CoAを含まなければなりません。
6.3.3. Fast Neighbor Advertisement (FNA)
6.3.3. 速い隣人広告(FNA)
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.
ミネソタは、それ自体をNARに発表するためにFast Neighbor Advertisementを送ります。 Mobility Header TypeがFNAであるときに、IPv6に有効搭載量プロト分野がFBUカプセル化を補助するように設定されるかもしれません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
移動性OptionsはMH-LLAオプション形式のミネソタのAddress Mobility Header Link-層を含まなければなりません。 セクション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
新しいリンクに関する接続性を取り戻すとすぐに、ミネソタはFast Neighbor AdvertisementをNARに送ります。 すぐに、到着かバッファリングされたパケットを進めることができます。 NARがproxying NCoAであるなら、それはREACHABLE状態で隣人キャッシュエントリーを作成します。 エントリーが全くなければ、それは、1つを作成して、REACHABLEにそれを設定します。 エントリーがINCOMPLETE状態にAddress Link-層なしであれば、それはそれを設定します。
Koodli, Ed. Experimental [Page 30] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[30ページ]RFC4068の速い身柄の引き渡し
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.
届く。 また、隣人キャッシュエントリーを作成するプロセスの間、NARは、NCoAが使用中であるかどうか検出できます、その結果、アドレス衝突を避けます。 NARのリンクから送るとFNAの中でFBUをカプセル化するので、衝突を検出するなら、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アドレスで現在の)とLinkの組み合わせはAddress(Mobility Optionとして現在の)SHOULDを層にします。使用されて、他のノードとミネソタを区別してください。
6.4. New Options
6.4. 新しいオプション
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).
Type値はNeighborディスカバリーオプションスペースから定義されます。 Length分野が8つの八重奏のユニットにあります、セクション6.2によると、Length分野がユニットの八重奏[3]で中であるMobility Header Link-層のAddressオプションを除いて。 オプションコードはそれぞれのオプションのための追加情報を提供します(以下での個人の選択を見てください)。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| オプションコード| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Option Format
図11: オプション形式
Koodli, Ed. Experimental [Page 31] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[31ページ]RFC4068の速い身柄の引き渡し
6.4.1. IP Address Option
6.4.1. IPアドレスオプション
This option is sent in the Proxy Router Advertisement, the Handover Initiate, and Handover Acknowledge messages.
Proxy Router Advertisement、Handover Initiate、およびHandover Acknowledgeメッセージでこのオプションを送ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| オプションコード| 接頭語の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | IPv6が+であると扱う+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: IPv6 Address Option
図12: IPv6アドレスオプション
Type 17
17をタイプしてください。
Length The size of this option in 8 octets including the
Type, Option-Code, and Length fields.
Typeを含む8つの八重奏における、このオプションのサイズ、Option-コード、およびLengthがさばく長さ。
Option-Code 1 Old Care-of Address
2 New Care-of Address
3 NAR's IP address
オプションコード1、Old Care、-、Address2、New Care、-、Address3NARの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.
ユニット単位でIPアドレスがType分野で定義したIPv6 Address。
Koodli, Ed. Experimental [Page 32] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[32ページ]RFC4068の速い身柄の引き渡し
6.4.2. New Router Prefix Information Option
6.4.2. 新しいルータ接頭語情報オプション
This option is sent in the PrRtAdv message to provide the prefix information valid on the NAR.
NARで有効な接頭語情報を提供するPrRtAdvメッセージでこのオプションを送ります。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Option-Code | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| オプションコード| 接頭語の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 接頭語+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Typeを含む8つの八重奏における、このオプションのサイズ、Option-コード、およびLengthがさばく長さ。
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.
Lengthを前に置いてください。8ビットの符号のない整数。 有効なPrefixの主なビットの数。 値は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.
An IPアドレスかIPアドレスの接頭語を前に置いてください。 Prefix Length分野は接頭語の有効な主なビットの数を含んでいます。 接頭語の長さの後の接頭語のビットを予約されていて、送付者によってゼロに初期化されて、受信機で無視しなければなりません。
Koodli, Ed. Experimental [Page 33] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[33ページ]RFC4068の速い身柄の引き渡し
6.4.3. Link-Layer Address (LLA) Option
6.4.3. リンクレイヤアドレス(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 | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| オプションコード| 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.
Typeを含む8つの八重奏における、このオプションのサイズ、Option-コード、およびLengthがさばく長さ。
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
またはRtSolPrの源のNAR(すなわち、Proxied Originator)4Address Link-層のミネソタ3Address Link-層のNew Access Point2Address Link-層のすべての近いアクセスポイントの1つのLink-層のAddressに解決を要求するオプションコード0ワイルドカード; アクセスポイントがLLAで特定した5がアクセスポイントに利用可能なサポートがLLAで特定したLLA7のいいえの速い身柄の引き渡しで特定されたアクセスポイントに利用可能なルータ6いいえ接頭語情報の現在のインタフェースに属すというPrRtAdvメッセージ
LLA The variable length Link-Layer Address.
可変長さのLLAはAddressをLink層にします。
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.
Address New Access Point Link-層は引き渡しが試みられようとしているアクセスポイントのAddress Link-層を含んでいます。 これはProxy AdvertisementメッセージにRouter Solicitationで使用されます。
The MN Link-Layer Address option contains the Link-Layer Address of an MN. It is used in the Handover Initiate message.
ミネソタのLink-層のAddressオプションはミネソタのAddress Link-層を含んでいます。 それはHandover Initiateメッセージで使用されます。
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(すなわち、Proxied Originator)リンク層のAddressオプションはProxy Router Solicitationメッセージが参照されるAccess RouterのAddress Link-層を含んでいます。
Koodli, Ed. Experimental [Page 34] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[34ページ]RFC4068の速い身柄の引き渡し
6.4.4. Mobility Header Link-Layer Address (MH-LLA) Option
6.4.4. 移動性ヘッダーリンクレイヤアドレス(MH-LLA)オプション
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オプションと同じですが、Mobility Headerメッセージ(すなわち、FNA)で運ばれます。 また、将来、他のMobility Headerメッセージはこのオプションを利用するかもしれません。 例えば、FBUのこのオプションを含んでいるのに、PARは容易にミネソタの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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションコード| 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.
Typeを含まない八重奏における、このオプションのサイズ、Length、およびOption-コードがさばく長さ。
Option-Code 2 Link-Layer Address of the MN
ミネソタのオプションコード2リンクレイヤアドレス
LLA The variable length Link-Layer Address.
可変長さのLLAはAddressをLink層にします。
6.4.5. Neighbor Advertisement Acknowledgment (NAACK)
6.4.5. 隣人広告承認(NAACK)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| オプションコード| 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Neighbor Advertisement Acknowledgment Option
図16: 隣人広告承認オプション
Type 20
20をタイプしてください。
Koodli, Ed. Experimental [Page 35] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[35ページ]RFC4068の速い身柄の引き渡し
Length 8-bit unsigned integer. Length of the option, in 8
octets. The length is 1 when NCoA is not supplied.
The length is 3 when NCoA is supplied (immediately
following the Reserved field).
長さ、8ビットの符号のない整数。 8つの八重奏における、オプションの長さ。 NCoAが供給されないとき、長さは1です。 NCoAを供給するとき(すぐにReserved野原に続いて)、長さは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:
Fast Neighbor Advertisementの気質が通信させる状態の8ビットの符号のない整数表示。 以下のStatus値は現在、定義されます:
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 New CoAは無効です。 2 New CoAは無効です。 供給されたCoAを使用してください。 Reserved野原に続いて、New CoAは存在していなければなりません。 128 リンクLayer Address認識されていません。
Reserved MUST be set to zero by the sender and MUST be
ignored by the receiver.
予約されているのが、送付者によるゼロへのセットであるに違いなく、受信機で無視しなければなりません。
The NAR responds to the FNA with the NAACK option to notify the MN to use a different NCoA if there is address collision. If the NCoA is invalid, the Router Advertisement MUST use the NCoA as the destination address but use the L2 address present in the FNA. The MN SHOULD use the NCoA if it is supplied with the NAACK option. If the NAACK indicates that the Link-Layer Address is unrecognized, the MN MUST NOT use the NCoA or PCoA and SHOULD start the process of acquiring an NCoA at the NAR immediately.
アドレス衝突があれば、NARは、ミネソタが異なったNCoAを使用するように通知するためにNAACKオプションでFNAに応じます。 NCoAが無効であるなら、Router Advertisementは送付先アドレスとしてNCoAを使用しますが、FNAの現在のL2アドレスを使用しなければなりません。 NAACKオプションをそれに供給するなら、MN SHOULDはNCoAを使用します。 NAACKが、Address Link-層が認識されていないのを示すなら、ミネソタはNCoAかPCoAを使用してはいけません、そして、SHOULDはすぐにNARでNCoAを獲得するプロセスを始めます。
New option types may be defined in the future.
新しいオプションタイプは将来、定義されるかもしれません。
7. Configurable Parameters
7. 構成可能なパラメタ
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
パラメタ名前デフォルト値定義------------------- ---------------------- ------- RTSOLPR_RETRIES3セクション6.1.1マックス_RTSOLPR_RATE3セクション6.1.1FBU_RETRIES3のセクション4 _1.5秒セクション6.2.2HI_RETRIES3のセクション6.2.1のPROXY_ノースダコタLIFETIME
Koodli, Ed. Experimental [Page 36] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[36ページ]RFC4068の速い身柄の引き渡し
8. Security Considerations
8. セキュリティ問題
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: この場合、パケットは、個人的には、何らかの疑わないノードにアドレスを盗むか、または転送できることを意味しました。 この関心は、ミネソタのそれと同じくらいとホームエージェント関係です。
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 MUSTは、FBUパケットが合法的にPCoAを所有しているノードから到着したのを確実にします。 アクセスルータとそのホストは、FBUを固定するのに使用しなければならないセキュリティ協会を証明するのにどんな利用可能なメカニズムも使用するかもしれません。 このプロトコルの最新版はこのセキュリティ協会がどう設立されるかを指定しません。 しかしながら、今後の活動はこのセキュリティ協会設立を指定するかもしれません。
If an access router can ensure that the source IP address in an
arriving packet could only have originated from the node whose
Link-Layer Address is in the router's neighbor cache, then a bogus
node cannot use a victim's IP address for malicious redirection of
traffic. Such an operation is recommended at least on neighbor
discovery messages including the RtSolPr message.
アクセスルータが、到着パケットのソースIPアドレスがルータの隣人キャッシュにはLink-層のAddressがあるノードから発するだけであったかもしれないのを確実にすることができるなら、にせのノードはトラフィックの悪意があるリダイレクションに犠牲者の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は固定されていますが、不注意な操作か悪意がある意図のために結合の目標はたまたま疑わないノードです。 この脆弱性は不正確なアドレスにトラフィックを向け直すアクセスルータとの本物のセキュリティ関係があるミネソタに通じることができます。
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 MUSTは、PCoAが制限されている状態であるNCoAが実際にNARの接頭語に属すことを確かめます。 これ、HI、およびHAckをするために、交換処理は使用されていることです。 ミネソタがFNAを通してそれ自体を付けて、発表するまでどんな到着パケットもNARがHI(Code=0がある)でNCoAを受け入れて、それがプロキシNCoAであるのでリンクに送られないとき。 したがって、ホストへのどんな不注意であるか悪意があるリダイレクションも避けられます。 NARのバッファを向け直されたトラフィックでふさぐのはまだ可能です。 しかしながら、NARのNCoAに対応する引き渡し州が有限で(短い)の生涯を予期された引き渡し潜在のわずかな倍数に対応するようにするので、この脆弱性の範囲は論証上わずかです。
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
3. NARのものからFBUを送って、以下をリンクしてください。 悪意があるノードはNCoAとして疑わないノードのアドレスを提供するNARのリンクからFBUを送るかもしれません。 FBUがFNAでカプセル化されるので、NARは検出するはずです。
Koodli, Ed. Experimental [Page 37] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[37ページ]RFC4068の速い身柄の引き渡し
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.
中のアドレスとの衝突は、FNAを処理しながらいつを使用するか、そして、次に、FBUを下げます。 NARがそこにアドレス衝突を検出できないとき、リダイレクションが影響できる脆弱性は疑わないノードですか?
9. IANA Considerations
9. IANA問題
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:
このドキュメントはExperimental MobilityプロトコルICMPv6形式[4]を使用する4つの新しい実験ICMPv6メッセージを定義します。 以下の通りExperimental MobilityプロトコルSubtype Registry[4]からのこれらの4つの新しいSubtype値の課題を割り当ててあります:
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
Subtype記述参照------- ----------- --------- 2 RtSolPrセクション6.1.1 3PrRtAdvセクション6.1.2 4HIセクション6.2.1 5ハッキング部6.2の.2
This document defines four new Neighbor Discovery [6] options that have received Type assignments from IANA.
このドキュメントはIANAからType課題を受け取った4つの新しいNeighborディスカバリー[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
オプション型記述参照----------- ----------- --------- 17 新しいIPのオプションセクション6.4.3 20隣人広告承認オプションアドレスオプションセクション6.4.1 18ルータ接頭語情報オプションセクション6.4.2 19リンクレイヤアドレス部分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: でのMobility Header Types登録からタイプ配分を受けた3つの新しいMobility Headerメッセージを定義します。
1. Fast Binding Update, described in Section 6.3.1
1. セクション6.3.1で説明された速いBinding Update
2. Fast Binding Acknowledgment, described in Section 6.3.2, and
2. そしてセクション6.3.2で説明された速いBinding Acknowledgment。
3. Fast Neighbor Advertisement, described in Section 6.3.3.
3. セクション6.3.3で説明された速いNeighbor Advertisement。
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: でのMobility Options Type登録からタイプ課題を受け取った新しいMobility Optionを定義します。
1. Mobility Header Link-Layer Address option, described in Section
6.4.4.
1. セクション6.4.4で説明された移動性Header Link-層のAddressオプション。
Koodli, Ed. Experimental [Page 38] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[38ページ]RFC4068の速い身柄の引き渡し
10. Acknowledgments
10. 承認
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のDevarapalli、Youn-ヒー・ハン、エミールIvov、Suvidhマートゥル、Koshiro三屋、ガブリエル・モンテネグロ、Takeshi小河、Peng、YC Peng、Domagoj Premec、およびジョナサンが植林するビジェイ)。 エディタは、ジェームス・ケンフからの貢献がこの仕様を改良すると認めたがっています。 また、エディタは、この仕事の多くのサポートを提供して頂いて、昔[モバイルip]のワーキンググループいすの[mipshop]ワーキンググループいすガブリエル・モンテネグロ、Basavarajパティル、およびフィル・ロバーツに感謝したがっています。
11. Normative References
11. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] コンタ、A.、およびS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC2463、1998年12月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[4] Kempf, J., "Instructions for Seamoby and Experimental Mobility
Protocol IANA Allocations", RFC 4065, July 2005.
[4] ケンフ、J.、「Seamobyと実験的な移動性プロトコルIANA配分のための指示」、RFC4065、2005年7月。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[5] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[6] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[6]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[7] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
12. Contributors
12. 貢献者
This document originated in the fast handover design team effort. The members of this design team in alphabetical order were: Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis, and Alper Yegin.
このドキュメントは速い引き渡しデザイン協力してする仕事で起こりました。 このデザインチームのメンバーはアルファベット順に以下の通りでした。 ゴパルDommety、カリム高架鉄道-Malki、モハメッド・カリル、チャールズ・パーキンス、Heshamソリマン、ジョージTsirtsis、およびAlper Yegin。
Koodli, Ed. Experimental [Page 39] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[39ページ]RFC4068の速い身柄の引き渡し
The design team member's contact information:
デザインチームメンバーの問い合わせ先:
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ゴパルDommetyシスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア 95134
Phone:+1 408 525 1404 EMail: gdommety@cisco.com
電話: +1 1404年の408 525メール: gdommety@cisco.com
Karim El Malki Ericsson Radio Systems AB LM Ericssons Vag. 8 126 25 Stockholm SWEDEN
カリム高架鉄道MalkiエリクソンラジオシステムAB LMエリクソンVag。 8 126 25ストックホルムスウェーデン
Phone: +46 8 7195803 Fax: +46 8 7190170 EMail: Karim.El-Malki@era.ericsson.se
以下に電話をしてください。 +46 8 7195803Fax: +46 8 7190170 メール: Karim.El-Malki@era.ericsson.se
Mohamed Khalil Nortel Networks
モハメドカリルノーテルネットワーク
EMail: mkhalil@nortelnetworks.com
メール: mkhalil@nortelnetworks.com
Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンス通信網研究室ノキアリサーチセンター313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1-650 625-2986 Fax: +1 650 625-2502 EMail: charliep@iprg.nokia.com
以下に電話をしてください。 +1-650 625-2986Fax: +1 650 625-2502 メールしてください: charliep@iprg.nokia.com
Hesham Soliman Flarion Technologies
HeshamソリマンFlarion Technologies
EMail: H.Soliman@flarion.com
メール: H.Soliman@flarion.com
Koodli, Ed. Experimental [Page 40] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[40ページ]RFC4068の速い身柄の引き渡し
George Tsirtsis Flarion Technologies
ジョージTsirtsis Flarion Technologies
EMail: G.Tsirtsis@flarion.com
メール: G.Tsirtsis@flarion.com
Alper E. Yegin Samsung Advanced Institute of Technology 75 West Plumeria Drive San Jose, CA 95134 USA
西Plumeria Drive Alper E.Yegin三星高度先端技術研究所75カリフォルニア95134サンノゼ(米国)
Phone: +1 408 544 5656 EMail: alper.yegin@samsung.com
以下に電話をしてください。 +1 5656年の408 544メール: alper.yegin@samsung.com
Author's Address
作者のアドレス
Rajeev Koodli, Editor Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
Rajeev Koodli、エディタノキアリサーチセンター313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 625 2359 Fax: +1 650 625 2502 EMail: Rajeev.Koodli@nokia.com
以下に電話をしてください。 +1 650 625、2359Fax: +1 2502年の650 625メール: Rajeev.Koodli@nokia.com
Koodli, Ed. Experimental [Page 41] RFC 4068 Fast Handovers for Mobile IPv6 July 2005
エドKoodli、モバイルIPv6 July 2005のための実験的な[41ページ]RFC4068の速い身柄の引き渡し
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Koodli, Ed. Experimental [Page 42]
Koodli、エド、実験的[42ページ]
一覧
スポンサーリンク
