RFC5268 日本語訳
5268 Mobile IPv6 Fast Handovers. R. Koodli, Ed.. June 2008. (Format: TXT=113090 bytes) (Obsoletes RFC4068) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Koodli, Ed. Request for Comments: 5268 Starent Networks Obsoletes: 4068 June 2008 Category: Standards Track
ワーキンググループR.Koodli、エドをネットワークでつないでください。コメントのために以下を要求してください。 5268のStarentネットワークが以下を時代遅れにします。 4068 2008年6月のカテゴリ: 標準化過程
Mobile IPv6 Fast Handovers
モバイルIPv6速い身柄の引き渡し
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency.
1Access Routerから別のAccess Routerまで移行するとき、モバイルIPv6は、モバイルNode(ミネソタ)がインターネットに接続性を維持するのを可能にします、引き渡しと呼ばれたプロセス。引き渡しの間、モバイルNodeがリンク切り換え遅れのためにパケットを送るか、または受けることができない期間とIPプロトコル操作があります。 すなわち、動き検出であって、新しい標準のモバイルIPv6手順から生じるこの「引き渡し潜在」、Care、-、Address構成、およびBinding Updateはしばしばボイス・オーバー IP(VoIP)などのリアルタイムのトラフィックに容認できません。 引き渡しレイテンシを減少させるのはまた、非リアルタイムで、スループット敏感なアプリケーションに有益であるかもしれません。 このドキュメントは、モバイルIPv6手順のため引き渡し潜在を改良するためにプロトコルを指定します。 このドキュメントは、向上がリンク切り換え潜在であると扱いません。
Koodli, Ed. Standards Track [Page 1] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[1ページ]RFC5268
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Protocol Overview ...............................................6
3.1. Addressing the Handover Latency ............................6
3.2. Protocol Operation .........................................8
3.3. Protocol Operation during Network-Initiated Handover ......11
4. Protocol Details ...............................................11
5. Other Considerations ...........................................15
5.1. Handover Capability Exchange ..............................15
5.2. Determining New Care-of Address ...........................16
5.3. Prefix Management .........................................16
5.4. Packet Loss ...............................................17
5.5. DAD Handling ..............................................18
5.6. Fast or Erroneous Movement ................................19
6. Message Formats ................................................20
6.1. New Neighborhood Discovery Messages .......................20
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) ..........................................20
6.1.2. Proxy Router Advertisement (PrRtAdv) ...............22
6.2. Inter - Access Router Messages ............................25
6.2.1. Handover Initiate (HI) .............................25
6.2.2. Handover Acknowledge (HAck) ........................27
6.3. New Mobility Header Messages ..............................28
6.3.1. Fast Binding Update (FBU) ..........................28
6.3.2. Fast Binding Acknowledgment (FBack) ................30
6.4. Unsolicited Neighbor Advertisement (UNA) ..................31
6.5. New Options ...............................................32
6.5.1. IP Address/Prefix Option ...........................33
6.5.2. Link-Layer Address (LLA) Option ....................34
6.5.3. Mobility Header Link-Layer Address (MH-LLA)
Option .............................................35
6.5.4. Binding Authorization Data for FMIPv6 (BADF) .......35
6.5.5. Neighbor Advertisement Acknowledgment (NAACK) ......36
7. Related Protocol and Device Considerations .....................37
8. Evolution from and Compatibility with RFC 4068 .................38
9. Configurable Parameters ........................................39
10. Security Considerations .......................................39
10.1. Peer Authorization Database Entries when Using IKEv2 .....41
10.2. Security Policy Database Entries .........................42
11. IANA Considerations ...........................................42
12. Acknowledgments ...............................................43
13. References ....................................................44
13.1. Normative References .....................................44
13.2. Informative References ...................................45
Appendix A. Contributors ..........................................46
Appendix B. Changes since RFC 4068 ................................46
1. 序論…3 2. 用語…3 3. 概要について議定書の中で述べてください…6 3.1. 引き渡しが潜在であると扱います…6 3.2. 操作について議定書の中で述べてください…8 3.3. ネットワークによって開始された引き渡しの間、操作について議定書の中で述べてください…11 4. 詳細について議定書の中で述べてください…11 5. 他の問題…15 5.1. 引き渡し能力交換…15 5.2. 決定新しい、注意、-、アドレス…16 5.3. 管理を前に置いてください…16 5.4. パケットの損失…17 5.5. おとうさんの取り扱い…18 5.6. 速いか誤った運動…19 6. メッセージ形式…20 6.1. 新しい近所発見メッセージ…20 6.1.1. プロキシ広告(RtSolPr)のためのルータ懇願…20 6.1.2. プロキシルータ通知(PrRtAdv)…22 6.2. 間--ルータが通信させるアクセス……25 6.2.1. 引き渡し開始(HI)…25 6.2.2. 引き渡しは(ハッキング)を承認します…27 6.3. 新しい移動性ヘッダーメッセージ…28 6.3.1. 速く付いて、(FBU)をアップデートしてください…28 6.3.2. 速く、承認(FBack)を縛ります…30 6.4. 求められていない隣人広告(UNA)…31 6.5. 新しいオプション…32 6.5.1. IPアドレス/接頭語オプション…33 6.5.2. リンクレイヤアドレス(LLA)オプション…34 6.5.3. 移動性ヘッダーリンクレイヤアドレス(MH-LLA)オプション…35 6.5.4. FMIPv6(BADF)のための拘束力がある承認データ…35 6.5.5. 隣人広告承認(NAACK)…36 7. プロトコルとデバイス問題を関係づけます…37 8. RFC4068との発展と互換性…38 9. 構成可能なパラメタ…39 10. セキュリティ問題…39 10.1. 同輩Authorization Database Entries、Using IKEv2であるときに…41 10.2. 安全保障政策データベースエントリー…42 11. IANA問題…42 12. 承認…43 13. 参照…44 13.1. 標準の参照…44 13.2. 有益な参照…45 付録A.貢献者…46 RFC4068以来付録B.は変化します…46
Koodli, Ed. Standards Track [Page 2] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[2ページ]RFC5268
1. Introduction
1. 序論
Mobile IPv6 [RFC3775] describes the protocol operations for a mobile node to maintain connectivity to the Internet during its handover from one access router to another. These operations involve link-layer procedures, movement detection, IP address configuration, and location update. The combined handover latency is often sufficient to affect real-time applications. Throughput-sensitive applications can also benefit from reducing this latency. This document describes a protocol to reduce the handover latency.
モバイルノードが1つのアクセスルータから別のルータまでの引き渡しの間、インターネットに接続性を維持するように、モバイルIPv6[RFC3775]はプロトコル操作について説明します。 これらの操作はリンクレイヤ手順、動き検出、IPアドレス構成、および位置のアップデートにかかわります。 結合した引き渡し潜在は、リアルタイムのアプリケーションに影響するようにしばしば十分です。 また、スループット敏感なアプリケーションはこのレイテンシを減少させるのから利益を得ることができます。 このドキュメントは、引き渡しレイテンシを減少させるためにプロトコルについて説明します。
This specification addresses the following problems: how to allow a mobile node to send packets as soon as it detects a new subnet link and how to deliver packets to a mobile node as soon as its attachment is detected by the new access router. The protocol defines IP protocol messages necessary for its operation regardless of link technology. It does this without depending on specific link-layer features while allowing link-specific customizations. By definition, this specification considers handovers that interwork with Mobile IP. Once attached to its new access router, an MN engages in Mobile IP operations including Return Routability [RFC3775]. There are no special requirements for a mobile node to behave differently with respect to its standard Mobile IP operations.
この仕様は以下のその問題を訴えます: 付属の次第新しいサブネットリンクとどうモバイルノードにパケットを提供するかを検出するとすぐに、モバイルノードがパケットを送るのをどう許容するかが新しいアクセスルータによって検出されます。 プロトコルはリンク技術にかかわらず操作に必要なIPプロトコルメッセージを定義します。 リンク特有の改造を許している間、特定のリンクレイヤ機能によらないで、それはこれをします。 定義上、この仕様はモバイルでIPを織り込む身柄の引き渡しを考えます。 いったん新しいアクセスルータに付けられると、ミネソタはReturn Routability[RFC3775]を含むモバイルIP操作に従事しています。 モバイルノードが標準のモバイルIP操作に関して異なって振る舞うというどんな特別な要件もありません。
This specification is applicable when a mobile node has to perform IP layer operations as a result of handovers. This specification does not address improving the link switching latency. It does not modify or optimize procedures related to signaling with the home agent of a mobile node. Indeed, while targeted for Mobile IPv6, it could be used with any mechanism that allows communication to continue despite movements. Finally, this specification does not address bulk movement of nodes using aggregate prefixes.
モバイルノードが身柄の引き渡しの結果、IP層の操作を実行しなければならないとき、この仕様は適切です。 この仕様は、向上がリンク切り換え潜在であると扱いません。 それは、モバイルノードのホームのエージェントと共にシグナリングに関連する手順を、変更もしませんし、最適化もしません。 本当に、モバイルIPv6のために狙っている間、それを動きにもかかわらず、コミュニケーションが続くどんなメカニズムと共にも、使用できました。 最終的に、この仕様は、集合接頭語を使用することでノードの大量の運動を扱いません。
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 [RFC2119]. The use of the term, "silently ignore" is not defined in RFC 2119. However, the term is used in this document and can be similarly construed.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか? 用語の使用、「静かに無視する、」 RFC2119では、定義されません。 しかしながら、用語を本書では使用して、同様に解釈できます。
The following terminology and abbreviations are used in this document in addition to those defined in [RFC3775]. The reference handover scenario is illustrated in Figure 1.
以下の用語と略語は本書では[RFC3775]で定義されたものに加えて使用されます。 参照引き渡しシナリオは図1で例証されます。
Koodli, Ed. Standards Track [Page 3] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[3ページ]RFC5268
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: 引き渡しのための参照シナリオ
Mobile Node (MN): A Mobile IPv6 host.
モバイルノード(ミネソタ): モバイルIPv6ホスト。
Access Point (AP): A Layer 2 device connected to an IP subnet that offers wireless connectivity to an MN. An Access Point Identifier (AP-ID) refers the AP's L2 address. Sometimes, AP-ID is also referred to as a Basic Service Set IDentifier (BSSID).
アクセスポイント(AP): Layer2デバイスはワイヤレスの接続性をミネソタに提供するIPサブネットに接続しました。 Access Point Identifier(AP-ID)はAPのL2アドレスを参照します。 また、時々、AP-IDはBasic Service Set IDentifier(BSSID)と呼ばれます。
Access Router (AR): The MN's default router.
ルータ(AR)にアクセスしてください: ミネソタのデフォルトルータ。
Previous Access Router (PAR): The MN's default router prior to its handover.
前のアクセスルータ(平価): 引き渡しの前のミネソタのデフォルトルータ。
New Access Router (NAR): The MN's anticipated default router subsequent to its handover.
新しいアクセスルータ(NAR): ミネソタは引き渡しへのその後のデフォルトルータを予期しました。
Previous CoA (PCoA): The MN's Care-of Address valid on PAR's subnet.
前のCoA(PCoA): ミネソタのもの、Care、-、PARのサブネットで有効なAddress。
New CoA (NCoA): The MN's Care-of Address valid on NAR's subnet.
新しいCoA(NCoA): ミネソタのもの、Care、-、NARのサブネットで有効なAddress。
Handover: A process of terminating existing connectivity and obtaining new IP connectivity.
引き渡し: 既存の接続性を終えて、新しいIPの接続性を得るプロセス。
Router Solicitation for Proxy Advertisement (RtSolPr): A message from the MN to the PAR requesting information for a potential handover.
プロキシ広告(RtSolPr)のためのルータ懇願: ミネソタから潜在的引き渡しのための情報を要求するPARまでのメッセージ。
Koodli, Ed. Standards Track [Page 4] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[4ページ]RFC5268
Proxy Router Advertisement (PrRtAdv): A message from the PAR to the MN that provides information about neighboring links facilitating expedited movement detection. The message can also act as a trigger for network-initiated handover.
プロキシルータ通知(PrRtAdv): PARから近所付き合いの情報を提供するミネソタまでのメッセージは、速められた動き検出を容易にしながら、リンクされます。 また、メッセージはネットワークによって開始された引き渡しのために引き金となることができます。
(AP-ID, AR-Info) tuple: Contains an access router's L2 and IP addresses, and prefix valid on the interface to which the Access Point (identified by AP-ID) is attached. The triplet [Router's L2 address, Router's IP address, and Prefix] is called "AR-Info". See Section 5.3.
(AR-インフォメーション) AP-ID、tuple: Access Point(AP-IDによって特定される)が付けているインタフェースで有効なアクセスルータのL2、IPアドレス、および接頭語を含んでいます。 三つ子[ルータのL2アドレス、RouterのIPアドレス、およびPrefix]は「AR-インフォメーション」と呼ばれます。 セクション5.3を見てください。
Neighborhood Discovery: The process of resolving neighborhood AP-IDs to AR-Info.
近所発見: 近所AP-IDを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アドレスを割り当てる特定のタイプのNCoA構成。 NARがアドレスプールを管理するメソッドは本書では指定されません。
Fast Binding Update (FBU): A message from the MN instructing its PAR to redirect its traffic (toward NAR).
速く付いて、(FBU)をアップデートしてください: トラフィック(NARに向かった)を向け直すようPARに命令するミネソタからのメッセージ。
Fast Binding Acknowledgment (FBack): A message from the PAR in response to an FBU.
速い拘束力がある承認(FBack): FBUに対応したPARからのメッセージ。
Predictive Fast Handover: The fast handover in which an MN is able to send an FBU when it is attached to the PAR, which then establishes forwarding for its traffic (even before the MN attaches to the NAR).
予言の速い引き渡し: それが次にトラフィックのために推進を確立するPARに付けられているとき(ミネソタがNARに付く前にさえ)ミネソタがFBUを送ることができる速い引き渡し。
Reactive Fast Handover: The fast handover in which an MN is able to send the FBU only after attaching to the NAR.
反応速い引き渡し: ミネソタがNARに付きながらFBUについて伝言を伝えることができるだけである速い引き渡し。
Unsolicited Neighbor Advertisement (UNA): The message in [RFC4861] with 'O' bit cleared.
求められていない隣人広告(UNA): 'O'ビットがある[RFC4861]のメッセージはクリアされました。
Fast Neighbor Advertisement (FNA): This message from RFC 4068 [RFC4068] is deprecated. The UNA message above is the preferred message in this specification.
速い隣人広告(FNA): RFC4068[RFC4068]からのこのメッセージは推奨しないです。 この仕様で上記のUNAメッセージは都合のよいメッセージです。
Handover Initiate (HI): A message from the PAR to the NAR regarding an MN's handover.
引き渡し開始(HI): ミネソタの引き渡しに関するPARからNARまでのメッセージ。
Handover Acknowledge (HAck): A message from the NAR to the PAR as a response to HI.
引き渡しは(ハッキング)を承認します: HIへの応答としてのNARからPARまでのメッセージ。
Koodli, Ed. Standards Track [Page 5] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[5ページ]RFC5268
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 the new CoA configuration latency. Once an MN is IP-capable on the new subnet link, it can send a Binding Update to its Home Agent and one or more correspondents. Once its correspondents process the Binding Update successfully, which typically involves the Return Routability procedure, the MN can receive packets at the new CoA. So, the ability to receive packets from correspondents directly at its new CoA depends on the Binding Update latency as well as the IP connectivity latency.
すぐに新しいサブネットリンクからパケットを送る能力は「IPの接続性」潜在に依存します。順番に、潜在は動き検出潜在と新しいCoA構成潜在によります。 ミネソタがいったん新しいサブネットリンクでIPできるようになると、それはホームのエージェントと1人以上の通信員にBinding Updateを送ることができます。 通信員がいったん首尾よくBinding Updateを処理すると、(Return Routability手順に通常かかわります)ミネソタは新しいCoAでパケットを受けることができます。 それで、直接新しいCoAの通信員からパケットを受ける能力はIP接続性潜在と同様にBinding Update潜在に依存します。
The protocol enables an MN to quickly detect that it has moved to a new subnet by providing the new access point and the associated subnet prefix information when the MN is still connected to its current subnet (i.e., PAR in Figure 1). For instance, an MN may discover available access points using link-layer specific mechanisms (e.g., a "scan" in Wireless Local Area Network (WLAN)) and then request subnet information corresponding to one or more of those discovered access points. The MN may do this after performing router discovery or at any time while connected to its current router. The result of resolving an identifier associated with an access point is a [AP-ID, AR-Info] tuple, which an MN can use in readily detecting movement. When attachment to an access point with AP-ID takes place, the MN knows the corresponding new router's coordinates including its prefix, IP address, and L2 address. The "Router Solicitation for Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement (PrRtAdv)" messages in Section 6.1 are used for aiding movement detection.
プロトコルは、ミネソタがすぐにそれを検出するのを可能にします。それは、ミネソタがいつまだ現在のサブネット(すなわち、図1のPAR)につなげられているかという情報を新しいアクセスポイントと関連サブネット接頭語に提供することによって、新しいサブネットに移行しました。 例えば、ミネソタは、リンクレイヤの特定のメカニズム(例えば、Wirelessローカル・エリア・ネットワーク(WLAN)における「スキャン」)を使用することで利用可能なアクセスポイントを発見して、次に、それらの1つ以上に対応するサブネット情報がアクセスポイントを発見したよう要求するかもしれません。 ミネソタはルータ発見を実行した後かいつでも、現在のルータに関連づけられている間、これをするかもしれません。 アクセスポイントに関連している識別子を決議するという結果は[AP-ID、AR-インフォメーション]tupleです。(ミネソタは容易に動きを検出する際にそのtupleを使用できます)。 AP-IDがあるアクセスポイントへの付属が行われると、ミネソタは接頭語、IPアドレス、およびL2アドレスを含む対応する新しいルータの座標を知っています。 「プロキシ広告(RtSolPr)のためのルータ懇願」とセクション6.1の「プロキシルータ通知(PrRtAdv)」メッセージは、動き検出を支援するのに使用されます。
Through the RtSolPr and PrRtAdv messages, the MN also formulates a prospective new CoA (NCoA) when it is still present on the PAR's link. Hence, the latency due to new prefix discovery subsequent to handover is eliminated. Furthermore, this prospective address can be used immediately after attaching to the new subnet link (i.e., NAR's link) when the MN has received a "Fast Binding Acknowledgment (FBack)" (see Section 6.3.2) message prior to its movement. In the event it moves without receiving an FBack, the MN can still start using NCoA after announcing its attachment through an unsolicited Neighbor Advertisement message (with the 'O' bit set to zero) [RFC4861]; NAR responds to this UNA message in case it wishes to provide a different IP address to use. In this way, NCoA configuration latency is reduced.
また、RtSolPrとPrRtAdvメッセージを通して、それがPARのリンクにまだ存在しているとき、ミネソタは将来の新しいCoA(NCoA)を定式化します。 したがって、引き渡しへのその後の新しい接頭語発見による潜在は根絶されます。 その上、ミネソタが動きの前に「速い拘束力がある承認(FBack)」(セクション6.3.2を見る)メッセージを受け取ったとき新しいサブネットリンク(すなわち、NARのリンク)に付く直後この将来のアドレスを使用できます。 それがFBackを受けないで動かすイベントでは、ミネソタは、まだ求められていないNeighbor Advertisementメッセージ(ゼロに設定された'O'ビットがある)[RFC4861]を通して付属を発表した後にNCoAを使用し始めることができます。 使用する異なったIPアドレスを提供したがっているといけないので、NARはこのUNAメッセージに応じます。 このように、NCoA構成レイテンシは減少します。
Koodli, Ed. Standards Track [Page 6] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[6ページ]RFC5268
The information provided in the PrRtAdv message can be used even when DHCP [RFC3315] is used to configure an NCoA on the NAR's link. In this case, the protocol supports forwarding using PCoA, and the MN performs DHCP once it attaches to the NAR's link. The MN still formulates an NCoA for FBU processing; however, it MUST NOT send data packets using the NCoA in the FBU.
DHCP[RFC3315]がNARのリンクの上のNCoAを構成するのに使用さえされるとき、PrRtAdvメッセージに提供された情報は使用できます。 この場合、プロトコルはPCoAを使用することで推進をサポートします、そして、いったんNARのリンクに付くと、ミネソタはDHCPを実行します。 ミネソタはFBU処理のためにまだNCoAを定式化しています。 しかしながら、FBUでNCoAを使用して、それはデータ・パケットを送ってはいけません。
In order to reduce the Binding Update latency, the protocol specifies a binding between the Previous CoA (PCoA) and NCoA. An MN sends a "Fast Binding Update" (see Section 6.3.1) message to its Previous Access Router to establish this tunnel. When feasible, the MN SHOULD send an FBU from the PAR's link. Otherwise, the MN should send the FBU immediately after detecting attachment to the NAR. An FBU message MUST contain the Binding Authorization Data for FMIPv6 (BADF) option (see Section 6.5.4) in order to ensure that only a legitimate MN that owns the PCoA is able to establish a binding. Subsequent sections describe the protocol mechanics. In any case, the result is that the PAR begins tunneling packets arriving for PCoA to NCoA. Such a tunnel remains active until the MN completes the Binding Update with its correspondents. In the opposite direction, the MN SHOULD reverse tunnel packets to the PAR, again until it completes Binding Update. And, PAR MUST forward the inner packet in the tunnel to its destination (i.e., to the MN's correspondent). Such a reverse tunnel ensures that packets containing a PCoA as a source IP address are not dropped due to ingress filtering. Even though the MN is IP-capable on the new link, it cannot use the NCoA directly with its correspondents without the correspondents first establishing a binding cache entry (for the NCoA). Forwarding support for the PCoA is provided through a reverse tunnel between the MN and the PAR.
Binding Updateレイテンシを減少させるために、プロトコルはPrevious CoA(PCoA)とNCoAの間の結合を指定します。 ミネソタは、このトンネルを証明するために「速い拘束力があるアップデート」(セクション6.3.1を見る)メッセージをPrevious Access Routerに送ります。 可能であるときに、MN SHOULDはPARのリンクからFBUを送ります。 さもなければ、付属を見つける直後ミネソタはFBUをNARに送るべきです。 FBUメッセージは、PCoAを所有している正統のミネソタだけが結合を確立できるのを確実にするためにFMIPv6(BADF)オプション(セクション6.5.4を見る)のためのBinding Authorization Dataを含まなければなりません。 その後のセクションはプロトコル整備士について説明します。 どのような場合でも、結果はPARがPCoAのためにNCoAに到着するパケットにトンネルを堀り始めるということです。 ミネソタが通信員と共にBinding Updateを完成するまで、そのようなトンネルはアクティブなままで残っています。 逆方向では、再びBinding Updateを完成するまで、MN SHOULDがトンネルパケットをPARに逆にします。 そして、PAR MUSTはトンネルで目的地(すなわち、ミネソタの通信員への)に内側のパケットを送ります。 そのような逆のトンネルは、ソースIPアドレスとしてPCoAを含むパケットがイングレスフィルタリングのため下げられないのを確実にします。 ミネソタは新しいリンクで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 the NAR to send Neighbor Solicitation before the MN attaches, subsequent retransmissions of address resolution are separated by a default period of one second each. In order to circumvent this delay, an MN announces its attachment immediately with an UNA message that allows the NAR to forward packets to the MN right away. Through tunnel establishment for PCoA and fast advertisement, the protocol provides expedited forwarding of packets to the MN.
単独でトンネルを設立するのは、それが新しいサブネットリンクに付けられているとすぐに、ミネソタがパケットを受けるのを確実にしません、NARがミネソタの存在を検出できないなら。 隣人のアドレス解決(すなわち、Neighbor SolicitationとNeighbor Advertisement)にかかわる隣人発見操作はかなりの遅延を通常もたらします、複数の秒が時々続いて。 例えば、到着パケットがミネソタが付く前にNeighbor Solicitationを送るNARの引き金となるとき、アドレス解決のその後の「再-トランスミッション」はそれぞれ1秒のデフォルトの期間までに切り離されます。 この遅れを回避するために、ミネソタはすぐNARがすぐパケットをミネソタに送ることができるUNAメッセージで付属を発表します。 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 the
また、プロトコルは以下の重要な機能性を提供します。 アクセスルータは提案されたNCoAが許容できると確認するメッセージを交換できます。 例えば、いつのミネソタはFBUを送るか。
Koodli, Ed. Standards Track [Page 7] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[7ページ]RFC5268
PAR's link, FBack can be delivered after the NAR considers the NCoA acceptable for use. This is especially useful when addresses are assigned by the access router. The NAR can also rely on its trust relationship with the PAR before providing forwarding support for the MN. That is, it may create a forwarding entry for the NCoA, subject to "approval" from the PAR, which it trusts. In addition, buffering for handover traffic at the NAR may be desirable. Even though the Neighbor Discovery protocol provides a small buffer (typically one or two packets) for packets awaiting address resolution, this buffer may be inadequate for traffic, such as VoIP, already in progress. The routers may also wish to maintain a separate buffer for servicing the handover traffic. Finally, the access routers could transfer network-resident contexts, such as access control, Quality of Service (QoS), and header compression, in conjunction with handover (although the context transfer process itself is not specified in this document). For all these operations, the protocol provides "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages (see Section 6.2). Both of these messages SHOULD be used. The access routers MUST have the necessary security association established by means outside the scope of this document.
PARのリンクであり、NARが、使用において、NCoAが許容できると考えた後にFBackを提供できます。 アドレスがアクセスルータによって割り当てられるとき、これは特に役に立ちます。 また、NARは提供する前のミネソタのサポートを進めるPARとの信頼関係を当てにすることができます。 すなわち、それはNCoAのためにそれが信じるPARからの「承認」を条件として推進エントリーを作成するかもしれません。 さらに、引き渡しのためにNARでトラフィックをバッファリングするのは望ましいかもしれません。 Neighborディスカバリープロトコルはアドレス解決を待つパケットのための小さいバッファ(通常1か2つのパケット)を提供しますが、このバッファはトラフィックに不十分であるかもしれません、VoIPなどのように、既に進行中で。 また、ルータは引き渡しトラフィックを修理するための別々のバッファを維持したがっているかもしれません。 最終的に、アクセスルータはネットワーク固有の関係を移すかもしれません、アクセスコントロールや、Service(QoS)のQualityや、ヘッダー圧縮などのように、引き渡しに関連して(文脈転送プロセス自体は本書では指定されませんが)。 これらのすべての操作のために、プロトコルは「引き渡し開始(HI)」と「引き渡しは(ハッキング)を承認すること」にメッセージを提供します(セクション6.2を見てください)。 これらのメッセージSHOULDでは両方の、使用されてください。 アクセスルータで、このドキュメントの範囲の外の手段で必要なセキュリティ協会を設立しなければなりません。
3.2. Protocol Operation
3.2. プロトコル操作
The protocol begins when an MN sends an RtSolPr message to its access router to resolve one or more Access Point Identifiers to subnet-specific information. In response, the access router (e.g., PAR in Figure 1) sends a PrRtAdv message containing one or more [AP-ID, AR-Info] tuples. The MN may send an RtSolPr at any convenient time, for instance as a response to some link-specific event (a "trigger") or simply after performing router discovery. However, the expectation is that prior to sending an RtSolPr, the MN will have discovered the available APs by link-specific methods. The RtSolPr and PrRtAdv messages do not establish any state at the access router; their packet formats are defined in Section 6.1.
ミネソタがサブネット特殊情報に1Access Point Identifiersを決議するためにRtSolPrメッセージをアクセスルータに送るとき、プロトコルは始まります。 応答では、アクセスルータ(例えば、図1のPAR)は1[AP-ID、AR-インフォメーション]tuplesを含むPrRtAdvメッセージを送ります。 例えば、何らかのリンク特有のイベント(「引き金」)かルータ発見を実行した単に後に、ミネソタは都合のよい時に応答としてRtSolPrを送るかもしれません。 しかしながら、期待は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 to the PAR. The purpose of the FBU is to authorize the PAR to bind the PCoA to the NCoA, so that arriving packets can be tunneled to the new location of the MN. The FBU should be sent from the PAR's link whenever feasible. For instance, an internal link-specific trigger could enable FBU transmission from the previous link.
PrRtAdvメッセージに情報を提供していて、ミネソタは、将来のNCoAを定式化して、FBUメッセージをPARに送ります。 FBUの目的はPARがNCoAにPCoAを縛るのを認可することです、到着パケットにミネソタの新しい位置までトンネルを堀ることができるように。 可能であるときはいつも、PARのリンクからFBUを送るべきです。 例えば、内部のリンク特有の引き金は前のリンクからFBUトランスミッションを可能にするかもしれません。
When it is not feasible, the FBU is sent from the new link.
それが可能でないときに、新しいリンクからFBUを送ります。
The format and semantics of FBU processing are specified in Section 6.3.1. The FBU message MUST contain the BADF option (see Section 6.5.4) to secure the message.
FBU処理の形式と意味論はセクション6.3.1で指定されます。 FBUメッセージはメッセージを保証するBADFオプション(セクション6.5.4を見る)を含まなければなりません。
Koodli, Ed. Standards Track [Page 8] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[8ページ]RFC5268
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 FBack on the previous link. This means that
packet tunneling is already in progress by the time the MN
handovers to the NAR. The MN SHOULD send the UNA immediately
after attaching to the NAR, so that arriving as well as
buffered packets can be forwarded to the MN right away.
Before sending FBack to the MN, the PAR can determine whether
the NCoA is acceptable to the NAR through the exchange of HI
and HAck messages. When assigned addressing (i.e., addresses
are assigned by the router) is used, the proposed NCoA in the
FBU is carried in an HI message (from PAR to NAR), and NAR MAY
assign the proposed NCoA. Such an assigned NCoA MUST be
returned in HAck (from NAR to PAR), and PAR MUST in turn
provide the assigned NCoA in FBack. If there is an assigned
NCoA returned in FBack, the MN MUST use the assigned address
(and not the proposed address in FBU) upon attaching to NAR.
1. ミネソタは前のリンクの上のFBackを受けます。 これは、パケットトンネリングがNARへのミネソタの身柄の引き渡しで既に進行していることを意味します。 NARに付く直後MN SHOULDはUNAを送ります、すぐバッファリングされたパケットと同様に到着するのをミネソタに送ることができるように。 FBackをミネソタに送る前に、PARは、NCoAがHIとHAckメッセージの交換を通してNARに許容できるかどうか決定できます。 割り当てられると、アドレシング(すなわち、アドレスはルータによって割り当てられる)は使用されています、そして、FBUの提案されたNCoAはHIメッセージ(PARからNARまでの)で運ばれます、そして、NAR MAYは提案されたNCoAを割り当てます。 HAck(NARからPARまでの)でそのような割り当てられた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 the PAR has processed
the FBU successfully. Hence, the MN (re)sends the FBU message
to the PAR immediately after sending the UNA message. If the
NAR chooses to supply a different IP address to use than the
NCoA, it MAY send a Router Advertisement with "Neighbor
Advertisement Acknowledge (NAACK)" option in which it includes
an alternate IP address for the MN to use. Detailed UNA
processing rules are specified in Section 6.4.
2. ミネソタは、ミネソタがFBUを送らないか、FBU(それ自体で失われるかもしれない)を送った後にリンクに出られますが、FBackを受ける前にミネソタが出られたので、前のリンクの上のFBackを受けません。 後者の場合でFBackを受けないで、ミネソタは、PARが首尾よくFBUを処理したかどうかを確かめることができません。 したがって、UNAメッセージを送る直後ミネソタ(re)はFBUメッセージをPARに送ります。 NARが、NCoAより異なったIPアドレスを使用に供給するのを選ぶなら、それは「隣人広告は(NAACK)を承認する」というミネソタが使用する代替のIPアドレスを含んでいるオプションでRouter Advertisementを送るかもしれません。 詳細なUNA処理規則はセクション6.4で指定されます。
The scenario in which an MN sends an FBU and receives an FBack on PAR's link is illustrated in Figure 2. For convenience, this scenario is characterized as the "predictive" mode of operation. The scenario in which the MN sends an FBU from the NAR's link is illustrated in Figure 3. For convenience, this scenario is characterized as the "reactive" mode of operation. Note that the reactive mode also includes the case in which an FBU has been sent from the PAR's link but an FBack has not yet been received. The figure is intended to illustrate that the FBU is forwarded through the NAR, but it is processed only by the PAR.
ミネソタがFBUを送って、PARのリンクの上のFBackを受けるシナリオは図2で例証されます。 便利において、このシナリオは「予言」の運転モードとして特徴付けられます。 ミネソタがNARのリンクからFBUを送るシナリオは図3で例証されます。 便利において、このシナリオは「反応している」運転モードとして特徴付けられます。 また、反応モードがPARのリンクからFBUを送りましたが、まだFBackを受け取っていない場合を含んでいることに注意してください。 図が、FBUがNARを通して進められるのを例証することを意図しますが、それは単にPARによって処理されます。
Koodli, Ed. Standards Track [Page 9] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[9ページ]RFC5268
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|----------HI--------->|
| |<--------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets ===============>|
| | |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
ミネソタ平価NAR| | | |------RtSolPr------->|、| | <、-、-、-、--PrRtAdv--------| | | | | |------FBU----------->|、-、-、-、-、-、-、-、-、--こんにちは--------->|、| | <、-、-、-、-、-、-、--ハッキング---------| | <--FBack---|--FBack--->|、|、|、| 前方に連絡を断ってください。| | パケット===============>|、|、|、|、|、|、| 接続してください。| | | | | |------------ウナ--------------------------->| |<================== パケットを届けてください。| |
Figure 2: Predictive Fast Handover
図2: 予言の速い引き渡し
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| |<-------FBU----------)|
| |----------HI--------->|
| |<-------HAck----------|
| |(HI/HAck if necessary)|
| forward |
| packets(including FBAck)=====>|
| | |
|<=================================== deliver packets
| |
ミネソタ平価NAR| | | |------RtSolPr------->|、| | <、-、-、-、--PrRtAdv--------| | | | | 分離| | | | | | | | 接続してください。| | |-------ウナ-----------|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |-------FBU-----------|---------------------)| | | <、-、-、-、-、-、--FBU----------)| | |----------こんにちは--------->|、| | <、-、-、-、-、-、--ハッキング----------| | |(HI/HAck、必要なら)| | 転送| | パケット(FBAckを含んでいます)=====>|、|、|、| |<================== パケットを届けてください。| |
Figure 3: Reactive Fast Handover
図3: 反応速い引き渡し
Koodli, Ed. Standards Track [Page 10] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[10ページ]RFC5268
Finally, the PrRtAdv message may be sent unsolicited, i.e., without the MN first sending an RtSolPr. This mode is described in Section 3.3.
最終的に、すなわち、ミネソタが最初にRtSolPrを送らないで求められていない状態でPrRtAdvメッセージを送るかもしれません。 このモードはセクション3.3で説明されます。
3.3. Protocol Operation during 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 such networks, the PAR can send an unsolicited PrRtAdv containing the link-layer address, IP address, and subnet prefix of the NAR when the network decides that a handover is imminent. The MN MUST process this PrRtAdv to configure a new Care-of Address on the new subnet, and MUST send an FBU to the PAR prior to switching to the new link. After transmitting PrRtAdv, the PAR MUST continue to forward packets to the MN on its current link until the FBU is received. The rest of the operation is the same as that described in Section 3.2.
いくつかの無線技術で、ミネソタとネットワークで互いに引き渡しを受けるという決定に達するかもしれませんが、引き渡しコントロールはネットワークであるかもしれません。 そのようなネットワークでは、PARはネットワークが、引き渡しが差し迫っていると決めるときNARのリンクレイヤアドレス、IPアドレス、およびサブネット接頭語を含む求められていないPrRtAdvを送ることができます。 ミネソタが新しい状態でaを構成するためにこのPrRtAdvを処理しなければならない、Care、-、新しいサブネットのAddress、新しいリンクに切り替わる前に、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を見てください。
4. Protocol Details
4. プロトコルの詳細
All descriptions refer to Figure 1.
すべての記述が図1を参照します。
After discovering one or more nearby access points, the MN sends RtSolPr to the PAR in order to resolve access point identifiers to subnet router information. A convenient time to do this is after performing router discovery. However, the MN can send RtSolPr at any time, e.g., when one or more new access points are discovered. The MN can also send RtSolPr more than once during its attachment to PAR. The trigger for sending RtSolPr can originate from a link-specific event, such as the promise of a better signal strength from another access point coupled with fading signal quality with the current access point. Such events, often broadly referred to as "L2 triggers", are outside the scope of this document. Nevertheless, they serve as events that invoke this protocol. For instance, when a "link up" indication is obtained on the new link, protocol messages (e.g., UNA) can be transmitted immediately. Implementations SHOULD make use of such triggers whenever available.
1つ以上の近いアクセスポイントを発見した後に、ミネソタは、サブネットルータ情報にアクセスポイント識別子を決議するためにRtSolPrをPARに送ります。 ルータ発見を実行した後に、これをする便利な時間があります。 しかしながら、例えば、1つ以上の新しいアクセスポイントがいつでも発見されるとき、ミネソタはRtSolPrを送ることができます。 また、ミネソタは付属の間の一度より多くのRtSolPrをPARに送ることができます。 送付RtSolPrのための引き金はリンク特有の出来事から発することができます、現在のアクセスポイントがあるフェージング信号品質に結びつけられた別のアクセスポイントからの、より良い信号強度の約束などのように。 このドキュメントの範囲の外に「L2引き金」としばしば広く呼ばれたそのような出来事があります。 それにもかかわらず、これを呼び出す出来事が議定書を作るとき、それらは役立ちます。 例えば、すぐに新しいリンクの上に「結び付いてください」という指示を得るとき、プロトコルメッセージ(例えば、UNA)を送ることができます。 利用可能であるときはいつも、実現SHOULDはそのような引き金を利用します。
The RtSolPr message contains one or more AP-IDs. A wildcard requests all available tuples.
RtSolPrメッセージは1つ以上のAP-IDを含んでいます。 ワイルドカードはすべての利用可能なtuplesを要求します。
Koodli, Ed. Standards Track [Page 11] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[11ページ]RFC5268
As a response to RtSolPr, the 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 the PAR MUST respond indicating that the new
access point is known and supply the [AP-ID, AR-Info] tuple.
If the new access point is known, but does not support fast
handover, the PAR MUST indicate this with Code 3 (see Section
6.1.2).
3. 新しいアクセスポイントが知られていて、PARにそれの情報があるなら、PAR MUSTは新しいアクセスポイントが知られているのを示しながら応じて、[AP-ID、AR-インフォメーション]tupleを供給します。 新しいアクセスポイントが知られていますが、速い引き渡しを支持しないなら、PAR MUSTはCode3と共にこれを示します(セクション6.1.2を見てください)。
4. If a wildcard is supplied as an identifier for the new access
point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info]
tuples that are subject to path MTU restrictions (i.e.,
provide any 'n' tuples without exceeding the link MTU).
4. '新しいアクセスポイントのための識別子としてワイルドカードを供給するなら、PAR 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 First in First Out (FIFO) buffering is used, the PAR MUST continue forwarding the packets to the PCoA (i.e., buffer and forward). While the protocol does not forbid such an implementation support, care must be taken to ensure that the PAR continues forwarding packets to the PCoA (i.e., uses a buffer and forward approach). The PAR SHOULD stop buffering once it begins forwarding packets to the NCoA.
さらなるプロトコル動作が必要であるときに、いくつかの実現が、PARで入って来るパケットのコピーをバッファリングし始めるのを選ぶかもしれません。 First Out(先入れ先出し法)バッファリングにおけるそのようなFirstが使用されているなら、PAR MUSTは、PCoA(すなわち、バッファとフォワード)にパケットを送り続けています。 プロトコルがそのような実現サポートを禁じない間、PARが、PCoA(すなわち、バッファと前進のアプローチを使用する)にパケットを送り続けているのを保証するために注意しなければなりません。 それがいったんパケットをNCoAに送り始めると、PAR SHOULDは、バッファリングするのを止めます。
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.
このドキュメントの範囲の外にアクセスルータが彼らの隣人に関して情報交換して、その結果隣接しているサブネットの情報でProxy Router Advertisementsの構造を許容する方法があります。
Koodli, Ed. Standards Track [Page 12] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[12ページ]RFC5268
The RtSolPr and PrRtAdv messages MUST be implemented by an MN and an access router that supports fast handovers. However, when the parameters necessary for the MN to send packets immediately upon attaching to the NAR are supplied by the link-layer handover mechanism itself, use of the above messages is optional on such links.
ミネソタと速い身柄の引き渡しを支持するアクセスルータでRtSolPrとPrRtAdvメッセージを実行しなければなりません。 しかしながら、リンクレイヤ引き渡しメカニズム自体でミネソタがすぐNARに付くときパケットを送るのに必要なパラメタを提供するとき、上記のメッセージの使用はそのようなリンクで任意です。
After a PrRtAdv message is processed, the MN sends an FBU at a time
determined by link-specific events, and includes the proposed NCoA.
The MN SHOULD send the FBU from the PAR's link whenever
"anticipation" of handover is feasible. When anticipation is not
feasible or when it has not received an FBack, the MN sends an FBU
immediately after attaching to NAR's link. In response to the FBU,
the PAR establishes a binding between the PCoA ("Home Address") and
the NCoA, and sends the FBack to the MN. Prior to establishing this
binding, the PAR SHOULD send an HI message to the NAR, and receive
HAck in response. In order to determine the NAR's address for the HI
message, the PAR can perform the longest prefix match of NCoA (in
FBU) with the prefix list of neighboring access routers. When the
source IP address of the FBU is the PCoA, i.e., the FBU is sent from
the PAR's link, the HI message MUST have a Code value set to 0; see
Section 6.2.1. When the source IP address of the FBU is not PCoA,
i.e., the FBU is sent from the NAR's link, the HI message MUST have a
Code value of 1; see Section 6.2.1.
PrRtAdvメッセージが処理された後に、ミネソタは、リンク特有の出来事で決定している時にFBUを送って、提案されたNCoAを含めます。 引き渡しの「予期」が可能であるときはいつも、MN SHOULDはPARのリンクからFBUを送ります。 予期が可能でないか、またはNARのリンクに付く直後それがFBackを受けていないのに、ミネソタは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を見てください。
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、リンクレイヤアドレス、およびミネソタのNCoAを含んでいます。 Code0、NARと共にHIメッセージを処理することに対応して:
1. determines whether the NCoA supplied in the HI message is
unique before beginning to defend it. It sends a Duplicate
Address Detection (DAD) probe [RFC4862] for NCoA to verify
uniqueness. However, in deployments where the probability of
address collisions is considered extremely low (and hence not
an issue), the parameter DupAddrDetectTransmits (see
[RFC4862]) is set to zero on the NAR, allowing it to avoid
performing DAD on the NCoA. The NAR similarly sets
DupAddrDetectTransmits to zero in other deployments where DAD
is not a concern. Once the NCoA is determined to be unique,
the NAR starts proxying [RFC4861] the address for
PROXY_ND_LIFETIME during which the MN is expected to connect
to the NAR. In case there is already an NCoA present in its
data structure (for instance, it has already processed an HI
message earlier), the NAR MAY verify if the LLA is the same as
its own or that of the MN itself. If so, the NAR MAY allow
the use of the NCoA.
1.、それを防御し始める前にHIメッセージで供給されたNCoAがユニークであるか否かに関係なく、決定します。 NCoAがユニークさについて確かめるように、それはDuplicate Address Detection(DAD)探測装置[RFC4862]を送ります。 しかしながら、展開では、パラメタDupAddrDetectTransmits([RFC4862]を見る)はNARでアドレス衝突の確率が非常に低いと(そして、したがって、問題でない)考えられるところでゼロに用意ができています、NCoAにDADを実行するのを避けるのを許容して。 NARはDADが関心でないところに他の展開で同様にゼロにDupAddrDetectTransmitsを設定します。 NCoAがいったん特有であると決心するようになると、NARは_PROXY_ノースダコタLIFETIMEへのミネソタがNARに接続すると予想されるアドレスをproxyingし始めます[RFC4861]。 データ構造における現在のNCoAが既にあるといけないので(例えば、それは、より早く既にHIメッセージを処理しました)、NAR MAYは、LLAがミネソタ自体のそれ自身かものと同じであるかどうか確かめます。 そうだとすれば、NAR MAYはNCoAの使用を許します。
Koodli, Ed. Standards Track [Page 13] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[13ページ]RFC5268
2. allocates the NCoA for the MN when assigned addressing is
used, creates a proxy neighbor cache entry and begins
defending it. The NAR MAY allocate the NCoA proposed in HI.
2.、割り当てられたアドレシングが使用されているとき、NCoAをミネソタに割り当てて、プロキシ隣人キャッシュエントリーを作成して、それを防御し始めます。 NAR MAYはHIで提案されたNCoAを割り当てます。
3. MAY create a host route entry for the PCoA (on the interface
to which the MN is attaching to) in case the NCoA cannot be
accepted or assigned. This host route entry SHOULD be
implemented such that until the MN's presence is detected,
either through explicit announcement by the MN or by other
means, arriving packets do not invoke neighbor discovery. The
NAR SHOULD also set up a reverse tunnel to the PAR in this
case.
3. PCoAのためにホストルートエントリーを作成するかもしれません。(インタフェースでは、ミネソタが付いているもの) 場合におけるNCoAに受け入れることができないか、割り当てることができません。 このホストルートエントリーSHOULDはミネソタの存在まで検出されるどちらかミネソタによる明白な発表による実行されたそのようなものであるか他の手段、到着しているパケットで隣人発見を呼び出しません。 また、NAR SHOULDはこの場合逆のトンネルをPARに設立します。
4. provides the status of the handover request in the Handover
Acknowledge (HAck) message to the PAR.
4.、Handover Acknowledge(HAck)メッセージにおける引き渡し要求の状態をPARに供給します。
When the Code value in HI is 1, the NAR MUST skip the above operations. Sending an HI message with Code 1 allows the NAR to validate the neighbor cache entry it creates for the MN during UNA processing. That is, the NAR can make use of the knowledge that its trusted peer (i.e., the PAR) has a trust relationship with the MN.
HIのCode値が1であるときに、NAR MUSTは上の操作をサボります。 Code1があるHIメッセージを送るのに、NARはそれがUNA処理の間にミネソタに作成する隣人キャッシュエントリーを有効にすることができます。 すなわち、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 as well to facilitate faster reception in the event that the MN is still present. The result of the FBU and FBack processing is that PAR begins tunneling the MN's packets to the NCoA. If the MN does not receive an FBack message even after retransmitting the FBU for FBU_RETRIES, it must assume that fast handover support is not available and stop the protocol operation.
HAckが割り当てられたNCoAを含んでいるなら、FBackはそれを含まなければなりません、そして、ミネソタはFBackに提供されたアドレスを使用しなければなりません。 ミネソタがまだ存在している場合、PAR MAYは、より速いレセプションを容易にするためにまた、前のリンクにFBackを送ります。 FBUとFBack処理の結果はPARがミネソタのパケットにNCoAにトンネルを堀り始めるということです。 FBU_RETRIESのためにFBUを再送さえした後にさえミネソタがFBackメッセージを受け取らないなら、それは、速い引き渡しサポートが利用可能でないと仮定して、プロトコル操作を止めなければなりません。
As soon as the MN establishes link connectivity with the NAR, it:
ミネソタがNARと共にリンクの接続性を確立するとすぐにそれ:
1. sends an UNA message (see Section 6.4). If the MN has not
received an FBack by the time UNA is being sent, it SHOULD
send an FBU message following the UNA message.
1.、UNAメッセージ(セクション6.4を見る)を送ります。 ミネソタが受信されていないなら、UNAまでにFBackを送ります、それ。SHOULDはFBUメッセージをUNAメッセージに従わせます。
2. joins the all-nodes multicast group and the solicited-node
multicast group corresponding to the NCoA.
2.、オールノードマルチキャストグループとNCoAに対応する請求されたノードマルチキャストグループに加わります。
3. starts a DAD probe for NCoA, see [RFC4862].
3. [RFC4862]は、スタートa DADがNCoAのために調べるのを見ます。
When a NAR receives an UNA message, it:
NARがUNAメッセージを受け取るときそれ:
1. deletes its proxy neighbor cache entry, if it exists, updates
the state to STALE [RFC4861], and forwards arriving and
buffered packets.
1.、存在しているならプロキシ隣人キャッシュエントリーを削除して、STALE[RFC4861]に状態をアップデートして、到着とバッファリングされたパケットを進めます。
Koodli, Ed. Standards Track [Page 14] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[14ページ]RFC5268
2. updates an entry in INCOMPLETE state [RFC4861], if it exists,
to STALE and forwards arriving and buffered packets. This
would be the case if NAR had previously sent a Neighbor
Solicitation that went unanswered perhaps because the MN had
not yet attached to the link.
2. INCOMPLETEのエントリーが述べるアップデート[RFC4861]、それは、STALEに存在していて、到着を送るか、そして、およびバッファリングされたパケット。 NARが以前にミネソタが恐らくまだリンクに付いていなかったので答えがなくなったNeighbor Solicitationを送ったなら、これはそうでしょう。
The buffer for handover traffic should be linked to this UNA processing. The exact mechanism is implementation dependent.
引き渡し交通のためのバッファはこのUNA処理にリンクされるべきです。 正確なメカニズムは実現に依存しています。
The NAR may choose to provide a different IP address other than the NCoA. This is possible if it is proxying the NCoA. In such a case, it:
NARは、NCoA以外の異なったIPアドレスを提供するのを選ぶかもしれません。 NCoAをproxyingしているなら、これは可能です。 このような場合にはそれ、:
1. MAY send a Router Advertisement with the NAACK option in which
it includes an alternate IP address for use. This message
MUST be sent to the source IP address present in UNA using the
same Layer 2 address present in UNA.
1. それが使用のための交互のIPアドレスを含んでいるNAACKオプションでRouter Advertisementを送るかもしれません。 UNAの現在の同じLayer2アドレスを使用して、UNAの現在のソースIPアドレスにこのメッセージを送らなければなりません。
If the MN receives an IP address in the NAACK option, it MUST use it and send an FBU using the new CoA. As a special case, the address supplied in NAACK could be the PCoA itself, in which case the MN MUST NOT send any more FBUs. The Status codes for the NAACK option are specified in Section 6.5.5.
ミネソタがNAACKオプションにおけるIPアドレスを受け取るなら、新しいCoAを使用して、それは、それを使用して、FBUを送らなければなりません。 特殊なものとして、NAACKで供給されたアドレスがPCoA自身であるかもしれない、その場合、ミネソタはそれ以上のFBUsを送ってはいけません。 NAACKオプションのためのStatusコードはセクション6.5.5で指定されます。
Once the MN has confirmed its NCoA (either through DAD or when provided for by the NAR), it SHOULD send a Neighbor Advertisement message with the 'O' bit set, to the all-nodes multicast address. This message allows MN's neighbors to update their neighbor cache entries.
かつて、ミネソタはNCoA(NARによって備えられたDADかいつまでの)を確認するか、そして、それはSHOULDです。'O'ビットがあるNeighbor Advertisementメッセージにセットを送ってください、オールノードマルチキャストアドレスに。 このメッセージで、ミネソタの隣人は彼らの隣人キャッシュエントリーをアップデートできます。
For data forwarding, the PAR tunnels packets using its global IP address valid on the interface to which the MN was attached. The MN reverse tunnels its packets to the same global address of PAR. The tunnel end-point addresses must be configured accordingly. When the PAR receives a reverse tunneled packet, it must verify if a secure binding exists for the MN identified by the PCoA in the tunneled packet, before forwarding the packet.
データ推進のために、ミネソタが付けられたインタフェースで有効なグローバルIPアドレスを使用することでPARはパケットにトンネルを堀ります。 ミネソタ逆はPARの同じグローバルアドレスにパケットにトンネルを堀ります。 それに従って、トンネルエンドポイントアドレスを構成しなければなりません。 PARが逆のトンネルを堀られたパケットを受けるとき、安全な結合がトンネルを堀られたパケットのPCoAによって特定されたミネソタに存在するかどうか確かめなければなりません、パケットを進める前に。
5. Other Considerations
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 the PAR does not support the fast handover protocol and stop sending any more RtSolPr messages.
ミネソタはRtSolPrメッセージに対応してPrRtAdvを予想します。 ミネソタがRTSOLPR_RETRIESの後にPrRtAdvメッセージを受け取らないなら、それは、PARが、速い引き渡しプロトコルをサポートして、それ以上のRtSolPrメッセージを送るのを止めないと仮定しなければなりません。
Koodli, Ed. Standards Track [Page 15] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[15ページ]RFC5268
Even if an MN's current access router is capable of providing fast handover support, the new access router to which the MN attaches may be incapable of fast handover. This is indicated to the MN during "runtime", through the PrRtAdv message with a Code value of 3 (see Section 6.1.2).
ミネソタの現在のアクセスルータが速い引き渡しサポートを提供できても、ミネソタが付く新しいアクセスルータは速い引き渡しで不可能であるかもしれません。これは「ランタイム」の間、ミネソタに示されます、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, the NAR MUST respond to HI using a HAck, in which it may include another NCoA to use, especially when assigned address configuration is used. If there is a CoA present in HAck, the PAR MUST include it in the FBack message. However, the MN itself does not have to wait on PAR's link for this exchange to take place. It can handover any time after sending the FBU message; sometimes it may be forced to handover without sending the FBU. In any case, it can still confirm using NCoA from NAR's link by sending the UNA message.
ミネソタは、通常、PrRtAdvメッセージに提供された情報を使用することで将来のNCoAを定式化して、FBUを送ります。 PAR MUSTはHIメッセージでFBUの現在のNCoAを使用します。 NAR MUSTは、HIの現在のNCoAが既に使用中であるかどうか確かめます。 どのような場合でも、NAR MUSTはそれが別のNCoAを使用に含むかもしれないHAckを使用することでHIに応じます、特に割り当てられたアドレス構成が使用されているとき。 HAckの現在のCoAがあれば、PAR MUSTはFBackメッセージにそれを含んでいます。 しかしながら、ミネソタ自体は、PARのリンクの上にこの交換が起こるのを待つ必要はありません。 それは何時でもFBUメッセージを送った後の引き渡しをそうすることができます。 FBUを送らないで、時々、それは引き渡しに強制されるかもしれません。 どのような場合でも、それは、NARのリンクからUNAメッセージを送ることによって、使用NCoAをまだ確認できます。
If a PrRtAdv message carries an NCoA, the MN MUST use it as its prospective NCoA.
PrRtAdvメッセージがNCoAを運ぶなら、ミネソタは将来のNCoAとしてそれを使用しなければなりません。
When DHCP is used, the protocol supports forwarding for PCoA only. In this case, the MN MUST perform DHCP operations once it attaches to the NAR even though it formulates an NCoA for transmitting the FBU. This is indicated in the PrRtAdv message with Code = 5.
DHCPが使用されているとき、プロトコルは、PCoAだけのために進めるのを支持します。 この場合、FBUを伝えるためにNCoAを定式化しますが、いったんNARに付くと、ミネソタはDHCP操作を実行しなければなりません。 これはPrRtAdvメッセージでCode=5で示されます。
5.3. Prefix Management
5.3. 接頭語管理
As defined in Section 2, the Prefix part of "AR-Info" is the prefix valid on the interface to which the AP is attached. This document does not specify how this Prefix is managed, it's length and assignment policies. The protocol operation specified in this document works regardless of these considerations. Often, but not necessarily always, this Prefix may be the aggregate prefix (such as /48) valid on the interface. In some deployments, each MN may have its own per-mobile prefix (such as a /64) used for generating the NCoA. Some point-to-point links may use such a deployment.
セクション2で定義されるように、「AR-インフォメーション」のPrefix部分はAPが付けているインタフェースで有効な接頭語です。 それは、このドキュメントがこのPrefixがどう管理されるかを指定しないで、長さと課題方針です。 本書では指定されたプロトコル操作はこれらの問題にかかわらず働いています。 必ずいつもであるというわけではない、しかし、しばしば、このPrefixはインタフェースで有効な集合接頭語であるかもしれません(/48などの)。 いくつかの展開では、各ミネソタは、NCoAを発生させるのに、それ自身の1モバイルあたりの接頭語(a/64などの)を使用させるかもしれません。 いくつかのポイントツーポイント接続がそのような展開を使用するかもしれません。
When per-mobile prefix assignment is used, the "AR-Info" advertised in PrRtAdv still includes the (aggregate) prefix valid on the interface to which the target AP is attached, unless the access routers communicate with each other (using HI and HAck messages) to
1モバイルあたりの接頭語課題が使用されている、PrRtAdvの広告に掲載された「AR-インフォメーション」はまだ目標APが付けているインタフェースで有効な(集合)の接頭語を含んでいます、アクセスルータが互いにコミュニケートしないなら(HIとHAckメッセージを使用して)いつまで
Koodli, Ed. Standards Track [Page 16] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[16ページ]RFC5268
manage the per-mobile prefix. The MN still formulates an NCoA using the aggregate prefix. However, an alternate NCoA based on the per-mobile prefix is returned by NAR in the HAck message. This alternate NCoA is provided to the MN in either the FBack message or in the NAACK option.
1モバイルあたりの接頭語を管理してください。 ミネソタは、集合接頭語を使用することでまだNCoAを定式化しています。 しかしながら、1モバイルあたりの接頭語に基づく交互のNCoAはHAckメッセージのNARによって返されます。 FBackメッセージかNAACKオプションでこの交互のNCoAをミネソタに提供します。
5.4. Packet Loss
5.4. パケット損失
Handover involves link switching, which may not be exactly coordinated with fast handover signaling. Furthermore, the arrival pattern of packets is dependent on many factors, including application characteristics, network queuing behaviors, etc. Hence, packets may arrive at the NAR before the MN is able to establish its link there. These packets will be lost unless they are buffered by the NAR. Similarly, if the MN attaches to the NAR and then sends an FBU message, packets arriving at the PAR until the FBU is processed will be lost unless they are buffered. This protocol provides an option to indicate request for buffering at the NAR in the HI message. When the PAR requests this feature (for the MN), it SHOULD also provide its own support for buffering.
引き渡しはリンクの切り換えにかかわります。(速い引き渡しが合図している状態で、それは、まさに調整されないかもしれません)。 その上、パケットの到着パターンはアプリケーションの特性、ネットワーク列を作りの振舞いなどを含む多くの要素に依存しています。 したがって、ミネソタがそこにリンクを設立できる前にパケットはNARに到着するかもしれません。 それらがNARによってバッファリングされないと、これらのパケットは失われるでしょう。 同様に、ミネソタがNARに付いて、次に、FBUメッセージを送って、それらがバッファリングされないと、FBUが処理されるまでPARに到着するパケットは失われるでしょう。 このプロトコルは、HIメッセージのNARでのバッファリングを求める要求を示すためにオプションを提供します。 PARはこの特徴(ミネソタへの)を要求して、それはSHOULDです。いつ、また、それ自身のバッファリングのサポートを提供してくださいか。
Whereas buffering can enable a smooth handover, the buffer size and the rate at which buffered packets are eventually forwarded are important considerations when providing buffering support. There are a number of aspects to consider:
バッファリングは滑らかな引き渡しを可能にすることができますが、サポートをバッファリングしながら提供するとき、バッファリングされたパケットが結局進められるバッファサイズとレートは重要な問題です。 考える多くの局面があります:
o Some applications transmit less data over a given period of data
than others, and this implies different buffering requirements.
For instance, Voice over IP typically needs smaller buffers
compared to high-resolution streaming video, as the latter has
larger packet sizes and higher arrival rates.
o いくつかのアプリケーションが与えられた期間に関するデータの上のデータより他のものを伝えます、そして、これは異なったバッファリング要件を含意します。 例えば、ボイス・オーバー IPは、通常より小さいバッファを高画質ストリーミング・ビデオと比較する必要があります、後者により大きいパケットサイズと、より高い到着率があるとき。
o When the mobile node appears on the new link, having the buffering
router send a large number of packets in quick succession may
overtax the resources of the router, the mobile node itself, or
the path between these two.
o 可動のノードが新しいリンクの上に現れると、バッファリングルータに多くのパケットを送らせると、ルータに関するリソース、可動のノード自体、またはこれらの2の間の経路が間断なく酷使されるかもしれません。
In particular, transmitting a large amount of buffered packets in
succession can congest the path between the buffering router and
the mobile node. Furthermore, nodes (such as a base station) on
the path between the buffering router and the mobile node may drop
such packets. If a base station buffers too many such packets,
they may contribute to additional jitter for packets arriving
behind them, which is undesirable for real-time communication.
特に、多量のバッファリングされたパケットを連続していて伝えるのはバッファリングルータと可動のノードの間の経路を充血させることができます。 その上、バッファリングルータと可動のノードの間の経路のノード(基地局などの)はそのようなパケットを落とすかもしれません。 基地局がまた、そのような多くのパケットをバッファリングするなら、それらはそれらの後ろで到着するパケットのための追加ジターに貢献するかもしれません。(リアルタイムのコミュニケーションに、それは、望ましくありません)。
o Since routers are not involved in end-to-end communication, they
have no knowledge of transport conditions.
o ルータがエンド・ツー・エンド通信にかかわらないので、それらには、輸送状態に関する知識が全くありません。
Koodli, Ed. Standards Track [Page 17] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[17ページ]RFC5268
o The wireless connectivity of the mobile node may vary over time.
It may achieve a smaller or higher bandwidth on the new link,
signal strength may be weak at the time it just enters the area of
this access point, and so on.
o 可動のノードの無線の接続性は時間がたつにつれて、異なるかもしれません。 それは新しいリンクにおけるより小さいか、より高い帯域幅を達成するかもしれなくて、ただこのアクセスポイントなどの領域に入るとき、信号強度は弱いかもしれません。
As a result, it is difficult to design an algorithm that would transmit buffered packets at appropriate spacing under all scenarios. The purpose of fast handovers is to avoid packet loss. Yet, draining buffered packets too fast can, by itself, cause loss of the packets, as well as blocking or loss of following packets meant for the mobile node.
その結果、すべてのシナリオの下の適切なスペースでバッファリングされたパケットを伝えるアルゴリズムを設計するのは難しいです。 速い身柄の引き渡しの目的はパケット損失を避けることです。 しかし、あまりに速くバッファリングされたパケットを排出するのがそれ自体でパケットの損失をもたらすことができます、可動のノードのために意味されたパケットに続くブロッキングか損失と同様に。
This specification does not restrict implementations from providing specialized buffering support for any specific situation. However, attention must be paid to the rate at which buffered packets are forwarded to the MN once attachment is complete. Routers implementing this specification MUST implement at least the default algorithm, which is based on the original arrival rates of the buffered packets. A maximum of 5 packets MAY be sent one after another, but all subsequent packets SHOULD use a sending rate that is determined by metering the rate at which packets have entered the buffer, potentially using smoothing techniques such as recent activity over a sliding time window and weighted averages [RFC3290].
この仕様はどんな特定の状況のサポートもバッファリングしながら専門にされた提供から実現を制限しません。 しかしながら、付属がいったん完全になるとバッファリングされたパケットがミネソタに送られるレートに注意を向けなければなりません。 この仕様を履行するルータは少なくともデフォルトアルゴリズムを実行しなければなりません。(それは、バッファリングされたパケットの元の到着率に基づいています)。 最大5つのパケットを相次いで送るかもしれませんが、すべてのその後のパケットSHOULDがパケットがバッファを入力したレートを計量することによって測定される送付レートを使用します、潜在的にフレックスタイムウィンドウと加重平均[RFC3290]の上の最近の活動などのスムージングのテクニックを使用して。
It should be noted, however, that this default algorithm is crude and may not be suitable for all situations. Future revisions of this specification may provide additional algorithms, once enough experience of the various conditions in deployed networks is attained.
しかしながら、このデフォルトアルゴリズムが粗雑であり、すべての状況に適しないかもしれないことに注意されるべきです。 この仕様の今後の改正は追加アルゴリズムを提供するかもしれません、様々な状態の配備されたネットワークの十分な経験にいったん達すると。
5.5. DAD Handling
5.5. おとうさんの取り扱い
Duplicate Address Detection (DAD) was defined in [RFC4862] to avoid address duplication on links when stateless address auto-configuration is used. The use of DAD to verify the uniqueness of an IPv6 address configured through stateless auto-configuration adds delays to a handover. The probability of an interface identifier duplication on the same subnet is very low; however, it cannot be ignored. Hence, the protocol specified in this document SHOULD only be used in deployments where the probability of such address collisions is extremely low or it is not a concern (because of the address management procedure deployed). The protocol requires the NAR to send a DAD probe before it starts defending the NCoA. However, this DAD delay can be turned off by setting DupAddrDetectTransmits to zero on the NAR [RFC4862].
写しAddress Detection(DAD)は、国がないアドレス自動構成が使用されているとき、リンクでアドレス重複を避けるために[RFC4862]で定義されました。 国がない自動構成を通して構成されたIPv6アドレスのユニークさについて確かめるDADの使用は引き渡しに遅れを加えます。同じサブネットにおけるインタフェース識別子複製の確率は非常に低いです。 しかしながら、それを無視できません。 したがって、プロトコルは中古のコネが展開であったならそのようなアドレス衝突の確率が非常に低いか、それが関心(管理手順が配備したアドレスによる)でないところで本書ではSHOULDだけを指定しました。 NCoAを防御し始める前にプロトコルは、NARがDAD探測装置を送るのを必要とします。 しかしながら、NARにゼロにDupAddrDetectTransmitsを設定することによって、このDAD遅れをオフにすることができます[RFC4862]。
Koodli, Ed. Standards Track [Page 18] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[18ページ]RFC5268
This document specifies messages that can be used to provide duplicate-free addresses, but the document does not specify how to create or manage such duplicate-free addresses. In some cases, the NAR may already have the knowledge required to assess whether or not the MN's address is a duplicate before the MN moves to the new subnet. For example, in some deployments, the NAR may maintain a pool of duplicate-free addresses in a list for handover purposes. In such cases, the NAR can provide this disposition in the HAck message (see Section 6.2.2) or in the NAACK option (see Section 6.5.5).
このドキュメントは無写しのアドレスを提供するのに使用できるメッセージを指定しますが、そのような無写しのアドレスを作成するか、または管理する方法をドキュメントは指定しません。 いくつかの場合、NARには、ミネソタが新しいサブネットに動く前にミネソタのアドレスが写しであるか否かに関係なく、評価するのに必要な知識が既にあるかもしれません。 例えば、いくつかの展開では、NARは引き渡し目的のためのリストの無写しのアドレスのプールを維持するかもしれません。 そのような場合、NARはHAckメッセージ(セクション6.2.2を見る)かNAACKオプションにこの気質を提供できます(セクション6.5.5を見てください)。
5.6. Fast or Erroneous Movement
5.6. 速いか誤った運動
Although this specification is for fast handover, the protocol is limited in terms of how fast an MN can move. A special case of fast movement is ping-pong, where an MN moves between the same two access points rapidly. Another instance of the same problem is erroneous movement, i.e., the MN receives information prior to a handover that it is moving to a new access point but it either moves to a different one or it aborts movement altogether. All of the above behaviors are usually the result of link-layer idiosyncrasies and thus are often resolved at the link layer itself.
この仕様は速い引き渡しのためのものですが、ミネソタがどれくらい速く動くことができるかに関してプロトコルは制限されます。 速い運動の特別なケースはピンポンです。(そこでは、ミネソタが同じ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 Home Agent and preferably that of every CN with which it is in communication. An MN that moves faster than necessary for this signaling to complete, which may be of the order of few seconds, may start losing packets. The signaling cost over the air interface and in the network may increase significantly, especially in the case of rapid movement between several access routers. To avoid the signaling overhead, the following measures are suggested.
しかしながら、IP層の移動性はそれ自身の限界を導入します。 IP層の身柄の引き渡しはミネソタが少なくともホームのエージェントの結合と望ましくはそれがコミュニケーションにあるあらゆるCNのものをアップデートするのにおいて適当な速度で起こるべきです。 完成する数秒の注文のものであるかもしれないこのシグナリングに必要とするより速く移行するミネソタは、パケットを失い始めるかもしれません。 空気インタフェースとネットワークにおけるシグナリング費用はかなり上がるかもしれません、特にいくつかのアクセスルータの間の急速な運動の場合で。 シグナリングオーバーヘッドを避けるために、以下の測定は示されます。
An MN returning to the PAR before updating the necessary bindings when present on the NAR MUST send a Fast Binding Update with the Home Address equal to the MN's PCoA and a lifetime of zero to the PAR. The MN should have a security association with the PAR since it performed a fast handover to the NAR. The PAR, upon receiving this Fast Binding Update, will check its set of outgoing (temporary fast handover) tunnels. If it finds a match, it SHOULD terminate that tunnel; i.e., start delivering packets directly to the node instead. In order for the PAR to process such an FBU, the lifetime of the security association has to be at least that of the tunnel itself.
存在しているときの必要な結合をアップデートして、NAR MUSTがミネソタのPCoAと等しいホームAddressとFast Binding Updateを送るPARへのゼロの生涯の前にPARに戻るミネソタ。 速い引き渡しをNARに実行したので、ミネソタには、PARとのセキュリティ協会があるべきです。 このFast Binding Updateを受けるとき、PARは出発している(一時的な速い引き渡し)トンネルのセットをチェックするでしょう。 掘り出し物のaはそれであるなら合って、それはSHOULDです。そのトンネルを終えてください。 すなわち、代わりに直接ノードにパケットを提供し始めてください。 PARがそのようなFBUを処理するように、セキュリティ協会の寿命は少なくともそれ自体でトンネルのものでなければなりません。
Koodli, Ed. Standards Track [Page 19] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[19ページ]RFC5268
Temporary tunnels for the purposes of fast handovers should use short lifetimes (of the order of at most a few tens of seconds or less). The lifetime of such tunnels should be enough to allow an MN to update all its active bindings. The default lifetime of the tunnel should be the same as the lifetime value in the FBU message.
速い身柄の引き渡しの目的のための一時的なトンネルは短い生涯(高々秒か以下の数10の注文の)を費やすはずです。 そのようなトンネルの寿命は、ミネソタがすべての活発な結合をアップデートするのを許容するために十分であるべきです。 トンネルの寿命が生涯と同じくらいがFBUメッセージの値であるならそうするデフォルト。
The effect of erroneous movement is typically limited to the loss of packets since routing can change and the PAR may forward packets toward another router before the MN actually connects to that router. If the MN discovers itself on an unanticipated access router, it SHOULD send a new Fast Binding Update to the PAR. This FBU supersedes the existing binding at the PAR, and the packets will be redirected to the newly confirmed location of the MN.
ルーティングが変化できて、ミネソタが実際にそのルータに接続する前にPARが別のルータに向かってパケットを送るかもしれないので、誤った運動の効果はパケットの損失に通常制限されます。 ミネソタは思いがけないアクセスルータでそれ自体を発見します、それ。SHOULDは新しいFast Binding UpdateをPARに送ります。 このFBUはPARで付きながら、存在に取って代わります、そして、パケットはミネソタの新たに確認された位置に向け直されるでしょう。
6. Message Formats
6. メッセージ・フォーマット
All the ICMPv6 messages have a common Type specified in [RFC4443]. The messages are distinguished based on the Subtype field (see below). For all the ICMPv6 messages, the checksum is defined in [RFC4443].
すべてのICMPv6メッセージで、[RFC4443]で一般的なTypeを指定します。 メッセージはSubtype分野に基づいて区別されます(以下を見てください)。 すべてのICMPv6メッセージに関しては、チェックサムは[RFC4443]で定義されます。
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 Section 6.5.2.
Proxy Router Advertisementsのためにルータをうながして、モバイルNodesはProxy AdvertisementのためにRouter Solicitationを送ります。 すべてのLink-層のAddressオプションには、セクション6.5.2で定義された書式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
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 Advertisement (RtSolPr)
Message
図4: プロキシ広告(RtSolPr)メッセージのためのルータ懇願
IP Fields:
IP分野:
Source Address: An IP address assigned to the sending interface.
ソースアドレス: 送付インタフェースに割り当てられたIPアドレス。
Destination Address: The address of the access router or the all
routers multicast address.
送付先アドレス: または、アクセスルータのアドレス、すべてのルータマルチキャストアドレス。
Koodli, Ed. Standards Track [Page 20] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[20ページ]RFC5268
Hop Limit: 255. See RFC 2461.
限界を飛び越してください: 255. RFC2461を見てください。
ICMP Fields:
ICMP分野:
Type: 154
以下をタイプしてください。 154
Code: 0
コード: 0
Checksum: The ICMPv6 checksum.
チェックサム: ICMPv6チェックサム。
Subtype: 2
Subtype: 2
Reserved: MUST be set to zero by the sender and ignored by the
receiver.
予約される: 送付者によってゼロに設定されて、受信機で無視しなければなりません。
Identifier: MUST be set by the sender so that replies can be
matched to this Solicitation.
識別子: 送付者は、このSolicitationに回答に合うことができるように設定しなければなりません。
Valid Options:
妥当な選択肢:
Source Link-Layer Address: When known, the link-layer address of
the sender SHOULD be included using the Link-Layer Address (LLA)
option. See the LLA option format below.
ソースリンクレイヤアドレス: 知られていると、Link-層のAddress(LLA)オプションを使用することで含まれていて、リンクレイヤは送付者にSHOULDを扱います。 以下のLLAオプション形式を見てください。
New Access Point Link-Layer Address: The link-layer address or
identification of the access point for which the MN requests
routing advertisement information. It MUST be included in all
RtSolPr messages. More than one such address or identifier can be
present. This field can also be a wildcard address. See the LLA
option below.
新しいアクセスポイントリンクレイヤアドレス: ミネソタがルーティング広告情報を要求するアクセスポイントのリンクレイヤアドレスか識別。 すべてのRtSolPrメッセージにそれを含まなければなりません。 アドレスかそのような識別子の1つ以上が、存在している場合があります。 また、この分野はワイルドカードアドレスであるかもしれません。 以下でのLLAオプションを見てください。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options that they do not recognize and continue processing the rest of the message.
このプロトコルの将来のバージョンは新しいオプションタイプを定義するかもしれません。 受信機は、静かに、彼らが認識しない少しのオプションも無視して、メッセージの残りを処理し続けなければなりません。
Including the source LLA option allows the receiver to record the sender's L2 address so that neighbor discovery can be avoided when the receiver needs to send packets back to the sender (of the RtSolPr message).
ソースLLAオプションを含んでいるのに、受信機は、受信機が、送付者(RtSolPrメッセージの)にパケットを送り返す必要があるとき、隣人発見を避けることができるように送付者のL2アドレスを記録できます。
When a wildcard is used for New Access Point LLA, no other New Access Point LLA options must be present.
ワイルドカードがNew Access Point LLAに使用されるとき、他のどんなNew Access Point LLAオプションも存在しているはずがありません。
Koodli, Ed. Standards Track [Page 21] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[21ページ]RFC5268
A Proxy Router Advertisement (PrRtAdv) message should be received by the MN in response to an RtSolPr. If such a message is not received in a timely manner (no less than twice the typical round trip time (RTT) over the access link or 100 milliseconds if RTT is not known), it SHOULD resend the RtSolPr message. Subsequent retransmissions can be up to RTSOLPR_RETRIES, but MUST use an exponential backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled prior to each instance of retransmission. If Proxy Router Advertisement is not received by the time the MN disconnects from the PAR, the MN SHOULD send an FBU immediately after configuring a new CoA.
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 an RtSolPr, exponential backoff is used for retransmissions.
一度以上をRtSolPrメッセージに送るとき、それらは1秒あたりマックス_RTSOLPR_RATEと共に制限されたレートであるに違いありません。 RtSolPrの各使用の間、指数のbackoffは「再-トランスミッション」に使用されます。
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 an RtSolPr message from an MN, providing the link-layer address, IP address, and subnet prefixes of neighboring routers. All the Link-Layer Address options have the format defined in 6.4.3.
アクセスルータは、ミネソタから引き渡しがネットワークによって開始されているなら無償でメッセージをProxy Router Advertisementに送るか、またはRtSolPrメッセージへの応答としてそうします、隣接しているルータのリンクレイヤアドレス、IPアドレス、およびサブネット接頭語を提供して。 すべてのLink-層のAddressオプションには、6.4で.3に定義された書式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype| 予約されます。| 識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Proxy Router Advertisement (PrRtAdv) Message
図5: プロキシルータ通知(PrRtAdv)メッセージ
IP Fields:
IP分野:
Source Address: MUST be the link-local address assigned to the
interface from which this message is sent.
ソースアドレス: このメッセージが送られるインタフェースに割り当てられたリンクローカルアドレスはそうであるに違いありませんか?
Destination Address: The Source Address of an invoking Router
Solicitation for Proxy Advertisement or the address of the node
the access router is instructing to handover.
送付先アドレス: Proxy Advertisementのための呼び出しRouter SolicitationのSource Addressかアクセスルータが引き渡しに命令しているノードのアドレス。
Hop Limit: 255. See RFC 2461.
限界を飛び越してください: 255. RFC2461を見てください。
Koodli, Ed. Standards Track [Page 22] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[22ページ]RFC5268
ICMP Fields:
ICMP分野:
Type: 154
以下をタイプしてください。 154
Code: 0, 1, 2, 3, 4, or 5. See below.
コード: 0、1、2、3、4、または5。 以下を見てください。
Checksum: The ICMPv6 checksum.
チェックサム: ICMPv6チェックサム。
Subtype: 3
Subtype: 3
Reserved: MUST be set to zero by the sender and ignored by the
receiver.
予約される: 送付者によってゼロに設定されて、受信機で無視しなければなりません。
Identifier: Copied from Router Solicitation for Proxy
Advertisement or set to zero if unsolicited.
識別子: Proxy AdvertisementかセットのためのRouter Solicitationからゼロまでコピーされていますが、求められていません。
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オプションを使用することで含まれていて、リンクレイヤは送付者にSHOULDを扱います。 以下のLLAオプション形式を見てください。
New Access Point Link-Layer Address: The link-layer address or
identification of the access point is copied from RtSolPr message.
This option MUST be present.
新しいアクセスポイントリンクレイヤアドレス: アクセスポイントのリンクレイヤアドレスか識別がRtSolPrメッセージからコピーされます。 このオプションは存在していなければなりません。
New Router's Link-Layer Address: The link-layer address of the
access router for which this message is proxied for. This option
MUST be included when the Code is 0 or 1.
新しいルータのリンクレイヤアドレス: このメッセージのためにproxiedされるアクセスルータのリンクレイヤアドレス。 Codeが0か1歳であるときに、このオプションを含まなければなりません。
New Router's IP Address: The IP address of the NAR. This option
MUST be included when the Code is 0 or 1.
新しいルータのIPアドレス: NARのIPアドレス。 Codeが0か1歳であるときに、このオプションを含まなければなりません。
New Router Prefix Information Option: Specifies the prefix of the
access router the message is proxied for and is used for address
auto-configuration. This option MUST be included when the Code is
0 or 1. However, when this prefix is the same as what is used in
the New Router's IP Address option (above), the Prefix Information
option need not be present.
新しいルータ接頭語情報オプション: メッセージがproxiedされるアクセスルータの接頭語を指定して、アドレス自動構成に使用されます。 Codeが0か1歳であるときに、このオプションを含まなければなりません。 しかしながら、この接頭語がNew RouterのIP Addressオプション(above)に使用されることと同じであるときに、Prefix情報オプションは存在している必要はありません。
New CoA Option: MAY be present when PrRtAdv is sent unsolicited.
The PAR MAY compute a new CoA using the NAR's prefix information
and the MN's L2 address or by any other means.
新しいCoAオプション: PrRtAdvが送られるプレゼントが求められていなかったなら、そうするかもしれません。 PAR MAYは、アドレスかいかなる他の手段でもNARの接頭語情報とミネソタのL2を使用することで新しいCoAを計算します。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
このプロトコルの将来のバージョンは新しいオプションタイプを定義するかもしれません。 受信機は、静かに彼らが認識しない少しのオプションも無視して、メッセージを処理し続けなければなりません。
Koodli, Ed. Standards Track [Page 23] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[23ページ]RFC5268
Currently, Code values 0, 1, 2, 3, 4, and 5 are defined.
現在、Code値0、1、2、3、4、および5は定義されます。
A Proxy Router Advertisement with Code 0 means that the MN should use the [AP-ID, AR-Info] tuple (present in the options above) for movement detection and NCoA formulation. The Option-Code field in the New Access Point LLA option in this case is 1 reflecting the LLA of the access point for which the rest of the options are related. Multiple tuples may be present.
Code0とProxy Router Advertisementは、ミネソタが動き検出とNCoA定式化に、[AP-ID、AR-インフォメーション]tuple(上のオプションで現在の)を使用するべきであることを意味します。 この場合、New Access Point LLAオプションにおけるOption-コード分野はオプションの残りが関係づけられるアクセスポイントのLLAを反映する1です。 複数のtuplesが存在しているかもしれません。
A Proxy Router Advertisement with Code 1 means that the message has been sent unsolicited. If a New CoA option is present following the New Router Prefix Information option, the MN MUST use the supplied NCoA and send an FBU immediately or else stand to lose service. This message acts as a network-initiated handover trigger; see Section 3.3. The Option-Code field in the New Access Point LLA option (see below) in this case is 1 reflecting the LLA of the access point for which the rest of the options are related.
Code1とProxy Router Advertisementは、メッセージを送ることを意味します。求められていません。 New Router Prefix情報オプションに続いて、New CoAオプションが存在しているなら、ミネソタは、供給された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.
This would be the case, for instance, when a number of access
points are connected to the same router interface, or when network
based mobility management mechanisms ensure that the specific
mobile node always observes the same prefix regardless of whether
there is a separate router attached to the target access point.
No other options are required in this case.
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. Standards Track [Page 24] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[24ページ]RFC5268
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が存在しているかもしれません。
A Proxy Router Advertisement with Code 5 means that the MN may use the new router information present for detecting movement to a new subnet, but the MN must perform DHCP [RFC3315] upon attaching to the NAR's link. The PAR and NAR will forward packets to the PCoA of the MN. The MN must still formulate an NCoA for transmitting FBU (using the information sent in this message), but that NCoA will not be used for forwarding packets.
Code5とProxy Router Advertisementは、ミネソタが新しいサブネットへの動きを検出するための現在の新しいルータ情報を使用するかもしれないことを意味しますが、ミネソタはDHCP[RFC3315]をNARのリンクに付くのに実行しなければなりません。 PARとNARはミネソタのPCoAにパケットを送るでしょう。 ミネソタはFBUを伝えるためにまだNCoAを定式化しなければなりませんが(情報を使用すると、このメッセージは送られました)、そのNCoAは推進パケットに使用されないでしょう。
When a wildcard AP identifier is supplied in the RtSolPr message, the PrRtAdv message should include any 'n' [Access Point Identifier, Link-Layer Address option, Prefix Information Option] tuples corresponding to the PAR's neighborhood.
'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 an MN's handover.
Handover Initiate(HI)はミネソタの引き渡しのプロセスを開始するために別のアクセスルータ(通常NAR)へのAccess Router(通常PAR)によって送られたICMPv6メッセージです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |S|U| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype|S|U| 予約されます。| 識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Handover Initiate (HI) Message
図6: 引き渡し開始(こんにちは)メッセージ
IP Fields:
IP分野:
Source Address: The IP address of the PAR
ソースアドレス: PARのIPアドレス
Destination Address: The IP address of the NAR
送付先アドレス: NARのIPアドレス
ICMP Fields:
ICMP分野:
Type: 154
以下をタイプしてください。 154
Koodli, Ed. Standards Track [Page 25] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[25ページ]RFC5268
Code: 0 or 1. See below
コード: 0か1。 以下を見てください。
Checksum: The ICMPv6 checksum.
チェックサム: ICMPv6チェックサム。
Subtype: 4
Subtype: 4
'S' flag: Assigned address configuration flag. When set, this
message requests a new CoA to be returned by the destination. May
be set when Code = 0. MUST be 0 when Code = 1.
''旗です: 割り当てられたアドレス構成旗。 設定されると、このメッセージは、目的地によって返されるよう新しいCoAに要求します。 Code=0であるのに、設定されるかもしれません。 0がいつCode=1であったかならそうしなければなりません。
'U' flag: Buffer flag. When set, the destination SHOULD buffer
any packets toward the node indicated in the options of this
message. Used when Code = 0, SHOULD be set to 0 when Code = 1.
'U'旗: 旗をバッファリングしてください。 設定されると、目的地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)に引き渡しを受けているミネソタのリンクレイヤアドレス。 目的地がミネソタを認識できるように、このオプションを含まなければなりません。
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アドレス。 必要なら、ホストルートを確立できるように含まれていて、これは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アドレス。 'いつ、'ビットは設定されて、NAR MAYはこのアドレスを割り当てるか。
The PAR uses a Code value of 0 when it processes an FBU with PCoA as source IP address. The PAR uses a Code value of 1 when it processes an FBU whose source IP address is not PCoA.
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 round trip time (RTT) between source and destination, or 100 milliseconds if RTT is not known), the Handover Initiate SHOULD be resent. Subsequent retransmissions can be up to HI_RETRIES, but MUST use exponential backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled during each instance of retransmission.
メッセージはHandover Acknowledge(HAck)であるなら短い期間に応答として受け取られません(少なくとも典型的なラウンドの2倍は、ソースと目的地の間で時間(RTT)をつまずかせるか、またはRTTが知られていないなら、100ミリセカンドと同じくらいつまずきます)、Handover Initiate SHOULD。再送します。 その後の「再-トランスミッション」は、HI_RETRIESまであることができますが、タイムアウト時間(すなわち、2xRTTか100ミリセカンド)が「再-トランスミッション」の各インスタンスの間に倍にされる指数のbackoffを使用しなければなりません。
Koodli, Ed. Standards Track [Page 26] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[26ページ]RFC5268
6.2.2. Handover Acknowledge (HAck)
6.2.2. 引き渡しは承認します。(ハッキング)
The Handover Acknowledgment message is a new ICMPv6 message that MUST be sent (typically by the NAR to the PAR) as a reply to the Handover Initiate message.
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の送付先アドレスから、コピーされます。
Destination Address: Copied from the source address of the
Handover Initiate Message to which this message is a response.
送付先アドレス: このメッセージが応答であるHandover Initiate Messageのソースアドレスから、コピーされます。
ICMP Fields:
ICMP分野:
Type: 154
以下をタイプしてください。 154
Code:
コード:
0: Handover Accepted, NCoA valid
1: Handover Accepted, NCoA not valid or in use
2: Handover Accepted, NCoA assigned (used in Assigned
addressing)
3: Handover Accepted, use PCoA
4: Message sent unsolicited, usually to trigger an HI message
128: Handover Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources
0: 引き渡しAccepted、NCoAの有効な1: 有効でなくAccepted、NCoAを引き渡すか、または中で2を使用してください: 引き渡しAccepted、NCoAは3を割り当てました(Assignedアドレシングで、使用されます): 引き渡しAccepted、PCoA4を使用してください: 通常引き金のHIに求められていない状態で送られたメッセージは128を通信させます: 引き渡しNot Accepted、不特定の129を推論してください: 行政上、130を禁止します: 不十分なリソース
Checksum: The ICMPv6 checksum.
チェックサム: ICMPv6チェックサム。
Subtype: 5
Subtype: 5
Reserved: MUST be set to zero by the sender and ignored by the
receiver.
予約される: 送付者によってゼロに設定されて、受信機で無視しなければなりません。
Koodli, Ed. Standards Track [Page 27] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[27ページ]RFC5268
Identifier: Copied from the corresponding field in the Handover
Initiate message to which this message is a response.
識別子: このメッセージが応答であるHandover Initiateメッセージの対応する分野から、コピーされます。
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.
新しさ、注意、-、アドレス: Handover InitiateメッセージのS旗が設定されるなら、このオプションは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がインクルードであるということである、New Care、-、AddressオプションとCode3
The NAR MAY provide support for the PCoA (instead of accepting or
assigning an NCoA), establish a host route entry for the PCoA, and
set up a tunnel to the PAR to forward the MN's packets sent with
the PCoA as a source IP address. This host route entry SHOULD be
used to forward packets once the NAR detects that the particular
MN is attached to its link. The NAR indicates forwarding support
for PCoA using Code value 3 in the HAck message. Subsequently,
the PAR establishes a tunnel to the NAR in order to forward
packets arriving for the PCoA.
NAR MAYは、PCoAと共にソースIPアドレスとして送られたミネソタのパケットを進めるためにPCoA(NCoAを受け入れるか、または割り当てることの代わりに)のサポートを供給して、PCoAのためにホストルートエントリーを設置して、PARにトンネルを設立します。 このホストはエントリーSHOULDを発送します。NARがいったんそれを検出したあとにパケットを進めるのに使用されて、特定のミネソタがリンクに付けられているということになってください。 NARは、HAckメッセージでCode値3を使用することでPCoAの推進サポートを示します。 次に、PARは、PCoAのために到着するパケットを進めるためにトンネルをNARに確立します。
When responding to an HI message containing a Code value 1, the
Code values 1, 2, and 4 in the HAck message are not relevant.
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.
最終的に、New Access Routerはいつも引き渡しを拒否できます、その場合、それが利用可能なCode値の1つにおける理由を示すべきです。
6.3. New Mobility Header Messages
6.3. 新しい移動性ヘッダーメッセージ
Mobile IPv6 uses a new IPv6 header type called Mobility Header [RFC3775]. The Fast Binding Update, Fast Binding Acknowledgment, and the (deprecated) Fast Neighbor Advertisement messages use the Mobility Header.
モバイルIPv6はMobility Header[RFC3775]と呼ばれる新しいIPv6ヘッダータイプを使用します。 Fast Binding Update、Fast Binding Acknowledgment、および(推奨しない)の速いNeighbor AdvertisementメッセージはMobility Headerを使用します。
6.3.1. Fast Binding Update (FBU)
6.3.1. 速く、アップデートを縛ります。(FBU)
The Fast Binding Update message has a Mobility Header Type value of 8. The FBU is identical to the Mobile IPv6 Binding Update (BU) message. However, the processing rules are slightly different.
Fast Binding Updateメッセージには、8のMobility Header Type値があります。 FBUはモバイルIPv6 Binding Update(BU)メッセージと同じです。 しかしながら、処理規則はわずかに異なっています。
Koodli, Ed. Standards Track [Page 28] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[28ページ]RFC5268
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
送付先アドレス: Previous Access RouterのIPアドレス
'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 [RFC3775].
'H'旗: 1つに設定しなければなりません。 [RFC3775]を見てください。
'L' flag: See [RFC3775].
'L'旗: [RFC3775]を見てください。
'K' flag: See [RFC3775].
'K'旗: [RFC3775]を見てください。
Reserved: This field is unused. MUST be set to zero.
予約される: この分野は未使用です。 ゼロに設定しなければなりません。
Sequence Number: See [RFC3775].
一連番号: [RFC3775]を見てください。
Lifetime: The requested time in seconds for which the sender
wishes to have a binding.
生涯: 送付者がそうしたがっている秒の要求された時に、結合を持ってください。
Mobility Options: MUST contain an alternate CoA option set to the
NCoA when an FBU is sent from the PAR's link. MUST contain the
Binding Authorization Data for the FMIP (BADF) option. See
Section 6.5.4. MAY contain the Mobility Header LLA option (see
Section 6.5.3).
移動性オプション: PARのリンクからFBUを送るとき、代替のCoAオプションセットをNCoAに含まなければなりません。 FMIP(BADF)オプションのためのBinding Authorization Dataを含まなければなりません。 セクション6.5.4を見てください。 Mobility Header LLAオプションを含むかもしれません(セクション6.5.3を見てください)。
Koodli, Ed. Standards Track [Page 29] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[29ページ]RFC5268
The MN sends an FBU message any time after receiving a PrRtAdv message. If the MN moves prior to receiving a PrRtAdv message, it SHOULD send an FBU to the PAR after configuring the NCoA on the NAR according to Neighbor Discovery and IPv6 Address Configuration protocols. When the MN moves without having received a PrRtAdv message, it cannot transmit an UNA message upon attaching to the NAR's link.
ミネソタは、PrRtAdvメッセージを受け取りながら、いつでもFBUメッセージについて伝言を伝えます。 ミネソタが受信の前に移行するなら、a PrRtAdvは通信します、それ。NeighborディスカバリーとIPv6 Address Configurationプロトコルによると、NARの上のNCoAを構成した後に、SHOULDはFBUをPARに送ります。 ミネソタがPrRtAdvメッセージを受け取っていなくて移行すると、それはNARのリンクに付くことに関するUNAメッセージを送ることができません。
The source IP address is the PCoA when the FBU is sent from the PAR's link, and the source IP address is the NCoA when the FBU sent from the NAR's link. When the source IP address is the PCoA, the MN MUST include the alternate CoA option set to NCoA. The PAR MUST process the FBU even though the address in the alternate CoA option is different from that in the source IP address, and ensure that the address in the alternate CoA option is used in the New CoA option in the HI message to the NAR.
PARのリンクからFBUを送るとき、ソースIPアドレスはPCoAです、そして、FBUがNARのリンクから発信したとき、ソースIPアドレスはNCoAです。 ソースIPアドレスがPCoAであるときに、ミネソタは代替のCoAオプションセットをNCoAに含めなければなりません。 PAR MUSTは、代替のCoAオプションにおけるアドレスがそれとソースIPアドレスにおいて異なっていますが、FBUを処理して、代替のCoAオプションにおけるアドレスがNARへのHIメッセージにおけるNew CoAオプションに使用されるのを確実にします。
The FBU MUST also include the Home Address Option set to PCoA. An FBU message MUST be protected so that the PAR is able to determine that the FBU message is sent by an MN that legitimately owns the PCoA.
また、FBU MUSTはAddress OptionがPCoAに設定するホームを含んでいます。 FBUメッセージを保護しなければならないので、PARは、FBUメッセージが合法的にPCoAを所有しているミネソタによって送られることを決定できます。
6.3.2. Fast Binding Acknowledgment (FBack)
6.3.2. 速く、承認を縛ります。(FBack)
The Fast Binding Acknowledgment message has a Mobility Header Type value of 9. The FBack message is sent by the PAR to acknowledge receipt of a Fast Binding Update message in which the 'A' bit is set. If PAR sends an HI message to the NAR after processing an FBU, the FBack message SHOULD NOT be sent to the MN before the PAR receives a HAck message from the NAR. The PAR MAY send the FBack immediately in the reactive mode however. The Fast Binding Acknowledgment MAY also be sent to the MN on the old link.
Fast Binding Acknowledgmentメッセージには、9のMobility Header Type値があります。 FBackメッセージは、'A'ビットが設定されるFast Binding Updateメッセージの領収書を受け取ったことを知らせるためにPARによって送られます。 PARがHIメッセージを送るなら、後にFBU、FBackメッセージSHOULD NOTを処理するNARに以前ミネソタに送って、PARがNARからHAckメッセージを受け取るということになってください。 しかしながら、PAR MAYはすぐ反応モードでFBackを送ります。また、古いリンクの上のミネソタにFast Binding Acknowledgmentを送るかもしれません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態|K| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Fast Binding Acknowledgment (FBack) Message
図9: 速く、承認(FBack)メッセージを縛ります。
Koodli, Ed. Standards Track [Page 30] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[30ページ]RFC5268
IP Fields:
IP分野:
Source address: The IP address of the Previous Access Router
ソースアドレス: Previous Access RouterのIPアドレス
Destination Address: The NCoA, and optionally the PCoA
送付先アドレス: NCoA、任意に、PCoA
Status: 8-bit unsigned integer indicating the disposition of the
Fast Binding Update. Values of the Status field that are less
than 128 indicate that the Binding Update was accepted by the
receiving node. The following such Status values are currently
defined:
状態: 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 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: 不特定の129を推論してください: 行政上、130を禁止します: 不十分なリソース131: 不正確なインタフェース識別子の長さ
'K' flag: See [RFC3775].
'K'旗: [RFC3775]を見てください。
Reserved: An unused field. MUST be set to zero.
予約される: 未使用の分野。 ゼロに設定しなければなりません。
Sequence Number: Copied from the FBU message for use by the MN in
matching this acknowledgment with an outstanding FBU.
一連番号: 使用へのFBUメッセージは傑出しているFBUにこの承認に合う際にミネソタによって回避されます。
Lifetime: The granted lifetime in seconds for which the sender of
this message will retain a binding for traffic redirection.
生涯: このメッセージの送付者がトラフィックリダイレクションのための結合を保有する秒の与えられた生涯。
Mobility Options: MUST contain an "alternate" CoA if Status is 1.
MUST contain the Binding Authorization Data for FMIP (BADF)
option. See 6.4.5.
移動性オプション: Statusが1歳であるなら「代替の」CoAを含まなければなりません。 FMIP(BADF)オプションのためのBinding Authorization Dataを含まなければなりません。 .5に6.4を見てください。
6.4. Unsolicited Neighbor Advertisement (UNA)
6.4. 求められていない隣人広告(ウナ)
This is the same message as in [RFC4861] with the requirement that the 'O' bit is always set to zero. Since this is an unsolicited message, the 'S' bit is zero, and since this is sent by an MN, the 'R' bit is also zero.
これは'O'ビットがいつもゼロに設定されるという要件がある[RFC4861]のように同じメッセージです。 'ビットをゼロであり、これ以来ミネソタ、'Rは送ること'。'以来これがお節介なメッセージである、また、ビットはゼロです。
Koodli, Ed. Standards Track [Page 31] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[31ページ]RFC5268
If the NAR is proxying the NCoA (as a result of HI and HAck exchange), then UNA processing has additional steps (see below). If the NAR is not proxying the NCoA (for instance, HI and HAck exchange has not taken place), then UNA processing follows the same procedure as specified in [RFC4861]. Implementations MAY retransmit UNA subject to the specification in Section 7.2.6 of [RFC4861] while noting that the default RetransTimer value is large for handover purposes.
NARがNCoA(HIとHAck交換の結果、)をproxyingしているなら、UNA処理には、追加ステップがあります(以下を見てください)。 NARがNCoAをproxyingしていないなら(例えば、HIとHAck交換は起こっていません)、UNA処理は[RFC4861]の指定されるのと同じ手順に従います。 デフォルトRetransTimer価値が引き渡し目的のために大きいことに注意している間、実装は.6セクション7.2[RFC4861]の仕様を条件としてUNAを再送するかもしれません。
The Source Address in UNA MUST be the NCoA. The destination address is typically the all-nodes multicast address; however, some deployments may not prefer transmission to a multicast address. In such cases, the destination address SHOULD be the NAR's IP address.
ウナのSource AddressはNCoAであるに違いありません。 通常、送付先アドレスはオールノードマルチキャストアドレスです。 しかしながら、いくつかの展開はマルチキャストアドレスほどトランスミッションを好まないかもしれません。 そのようなものでは、ケース、目的地はNARのものがIPアドレスであったならSHOULDを扱います。
The Target Address MUST include the NCoA, and the Target link-layer address MUST include the MN's LLA.
Target AddressはNCoAを含まなければなりません、そして、TargetリンクレイヤアドレスはミネソタのLLAを含まなければなりません。
The MN sends an UNA message to the NAR, as soon as it regains connectivity on the new link. Arriving or buffered packets can be immediately forwarded. If the NAR is proxying the NCoA, it creates a neighbor cache entry in STALE state but forwards packets as it determines bidirectional reachability according to the standard Neighbor Discovery procedure. If there is an entry in INCOMPLETE state without a link-layer address, it sets it to STALE, again according to the procedure in [RFC4861].
新しいリンクに関する接続性を取り戻すとすぐに、ミネソタはUNAメッセージをNARに送ります。 すぐに、到着かバッファリングされたパケットを進めることができます。 NARがNCoAをproxyingしているなら、それは、STALE状態で隣人キャッシュエントリーを作成しますが、標準のNeighborディスカバリー手順によると、双方向の可到達性を決定するとき、パケットを進めます。 エントリーがINCOMPLETE状態にリンクレイヤアドレスなしであれば、STALEにそれを設定します、再び[RFC4861]の手順によると。
The NAR MAY wish to provide a different IP address to the MN than the one in the UNA message. In such a case, the NAR MUST delete the proxy entry for the NCoA and send a Router Advertisement with the NAACK option containing the new IP address.
NAR MAYはUNAメッセージのものより異なったIPアドレスをミネソタに提供したがっています。 このような場合には、NAR MUSTはNCoAのためにプロキシエントリーを削除して、NAACKオプションが新しいIPアドレスを含んでいるRouter Advertisementを送ります。
The combination of the NCoA (present in source IP address) and the Link-Layer Address (present as a Target LLA) SHOULD be used to distinguish the MN from other nodes.
組み合わせ、NCoA(ソースIPアドレスで現在の)とAddress(Target LLAとして現在の)SHOULD Link-層に、使用されて、他のノードとミネソタを区別してください。
6.5. New Options
6.5. 新しいオプション
All the options, with the exception of Binding Data Authorization for FMIPv6 (BADF) discussed in Section 6.5.4, use Type, Length, and Option-Code format shown in Figure 10.
セクション6.5.4で議論したFMIPv6(BADF)のためのBinding Data Authorization以外のすべてのオプションがType、Length、および図10で見せられたOption-コード形式を使用します。
The Type values are defined from the Neighbor Discovery options space. The Length field is in units of 8 octets, except for the Mobility Header Link-Layer Address option, whose Length field is in units of octets in accordance with Section 6.2 in [RFC3775]. And, Option-Code provides additional information for each of the options (see individual options below).
Type値はNeighborディスカバリーオプションスペースから定義されます。 Length分野が8つの八重奏のユニットにあります、セクション6.2によると、Length分野がユニットの八重奏[RFC3775]で中であるMobility Header Link-層のAddressオプションを除いて。 そして、Option-コードはそれぞれのオプションのための追加情報を提供します(以下での個人の選択を見てください)。
Koodli, Ed. Standards Track [Page 32] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[32ページ]RFC5268
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 10: Option Format
図10: オプション形式
6.5.1. IP Address/Prefix Option
6.5.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 11: IPv6 Address/Prefix Option
図11: IPv6アドレス/接頭語オプション
Type: 17
以下をタイプしてください。 17
Length: The size of this option in 8 octets including the Type, Option-Code, and Length fields.
長さ: Typeを含む8つの八重奏における、このオプションのサイズ、Option-コード、およびLength分野。
Option-Code:
オプションコード:
1: Old Care-of Address
2: New Care-of Address
3: NAR's IP address
4: NAR's Prefix, sent in PrRtAdv. The Prefix Length field
contains the number of valid leading bits in the prefix. The
bits in the prefix after the prefix length are reserved and
MUST be initialized to zero by the sender and ignored by the
receiver.
1: 旧、注意、-、アドレス2: 新しさ、注意、-、アドレス3: NARのIPアドレス4: PrRtAdvで送られたNARのPrefix。 Prefix Length分野は接頭語の有効な主なビットの数を含んでいます。 接頭語の長さの後の接頭語のビットを予約されていて、送付者によってゼロに初期化されて、受信機で無視しなければなりません。
Koodli, Ed. Standards Track [Page 33] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[33ページ]RFC5268
Prefix Length: 8-bit unsigned integer that indicates the length of the IPv6 Address Prefix. The value ranges from 0 to 128.
長さを前に置いてください: IPv6 Address Prefixの長さを示す8ビットの符号のない整数。 値は0〜128まで及びます。
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver.
予約される: 送付者がゼロに設定しなければならなくて、受信機で無視しなければなりません。
IPv6 address: The IP address defined by the Option-Code field.
IPv6アドレス: Option-コード分野によって定義されたIPアドレス。
6.5.2. Link-Layer Address (LLA) Option
6.5.2. リンクレイヤアドレス(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 12: Link-Layer Address Option
図12: リンクレイヤアドレスオプション
Type: 19
以下をタイプしてください。 19
Length: The size of this option in 8 octets including the Type, Option-Code, and Length fields.
長さ: 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 RtSolPr or PrRtAdv
message
5: The access point identified by the LLA belongs to the
current interface of the router
6: No prefix information available for the access point
identified by the LLA
7: No fast handovers support available for the access point
identified by the LLA
0: すべての近いアクセスポイント1のための解決を要求するワイルドカード: 新しいアクセスポイント2のリンクレイヤアドレス: Mn3のリンクレイヤアドレス: NAR(すなわち、Proxied創始者)4つのもののリンクレイヤアドレス: RtSolPrかPrRtAdvメッセージ5の源のリンク層のAddress: LLAによって特定されたアクセスポイントはルータ6の現在のインタフェースに属します: LLA7によって特定されたアクセスポイントに利用可能な接頭語情報がありません: アクセスポイントに利用可能なサポートがLLAで特定した速い身柄の引き渡しがありません。
LLA: The variable length link-layer address.
LLA: 可変長リンクレイヤアドレス。
The LLA option does not have a length field for the LLA itself. The implementations must consult the specific link layer over which the protocol is run in order to determine the content and length of the LLA.
LLAオプションには、LLA自身のための長さの分野がありません。 実装はプロトコルがLLAの内容と長さを測定する命令に立候補することである特定のリンクレイヤに相談しなければなりません。
Depending on the size of individual LLA option, appropriate padding MUST be used to ensure that the entire option size is a multiple of 8 octets.
個々のLLAオプションのサイズによって、全体のオプションサイズが8つの八重奏の倍数であることを保証するのに適切な詰め物を使用しなければなりません。
Koodli, Ed. Standards Track [Page 34] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[34ページ]RFC5268
The New Access Point Link-Layer Address contains the link-layer address of the access point for which handover is about to be attempted. This is used in the Router Solicitation for Proxy Advertisement message.
Address New Access Point 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オプションはミネソタのリンクレイヤアドレスを含んでいます。 それは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メッセージが参照されるアクセスルータのリンクレイヤアドレスを含んでいます。
6.5.3. Mobility Header Link-Layer Address (MH-LLA) Option
6.5.3. 移動性ヘッダーリンクレイヤアドレス(MH-LLA)オプション
This option is identical to the LLA option, but is carried in the Mobility Header messages, e.g., FBU. In the future, other Mobility Header messages may also make use of this option. The format of the option is shown in Figure 13. There are no alignment requirements for this option.
このオプションは、LLAオプションと同じですが、Mobility Headerメッセージ、例えば、FBUで運ばれます。 また、将来、他のMobility Headerメッセージはこのオプションを利用するかもしれません。 オプションの書式は図13に示されます。 このオプションのための整列要求が全くありません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Code | LLA ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 13: Mobility Header Link-Layer Address Option
図13: 移動性ヘッダーリンクレイヤアドレスオプション
Type: 7
以下をタイプしてください。 7
Length: The size of this option in octets not including the Type and Length fields.
長さ: TypeとLength分野を含まない八重奏における、このオプションのサイズ。
Option-Code: 2 Link-Layer Address of the MN.
オプションコード: 2 ミネソタのリンクレイヤアドレス。
LLA: The variable length link-layer address.
LLA: 可変長リンクレイヤアドレス。
6.5.4. Binding Authorization Data for FMIPv6 (BADF)
6.5.4. FMIPv6のための拘束力がある承認データ(BADF)
This option MUST be present in FBU and FBack messages. The security association between the MN and the PAR is established by companion protocols [RFC5269]. This option specifies how to compute and verify a Message Authentication Code (MAC) using the established security association.
このオプションはFBUとFBackメッセージに存在していなければなりません。 ミネソタとPARとのセキュリティ協会は仲間プロトコル[RFC5269]によって設立されます。 このオプションは設立されたセキュリティ協会を使用することでどのように、メッセージ立証コード(MAC)を計算して、確かめるかを指定します。
The format of this option is shown in Figure 14.
このオプションの書式は図14に示されます。
Koodli, Ed. Standards Track [Page 35] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[35ページ]RFC5268
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| オプションの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | 固有識別文字| + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Binding Authorization Data for FMIPv6 (BADF) Option
図14: FMIPv6(BADF)オプションのための拘束力がある承認データ
Type: 21
以下をタイプしてください。 21
Option Length: The length of the Authenticator in bytes
オプションの長さ: バイトで表現されるAuthenticatorの長さ
SPI: Security Parameter Index. SPI = 0 is reserved for the Authenticator computed using SEND-based handover keys.
SPI: セキュリティパラメタインデックス。 SPI=0はSENDベースの引き渡しキーを使用することで計算されたAuthenticatorのために予約されます。
Authenticator: Same as in RFC 3775, with "correspondent" replaced by the PAR's IP address, and Kbm replaced by the shared key between the MN and the PAR.
固有識別文字: 「通信員」をPARのIPアドレスに取り替えていてRFC3775、KbmをミネソタとPARの間の共有されたキーに取り替えていて同じです。
The default MAC calculation is done using HMAC_SHA1 with the first 96 bits used for the MAC. Since there is an Option Length field, implementations can use other algorithms such as HMAC_SHA256.
デフォルトMAC計算はMACに使用される最初の96ビットと共にHMAC_SHA1を使用し終わっています。 Option Length分野があるので、実装はHMAC_SHA256などの他のアルゴリズムを使用できます。
This option MUST be the last Mobility Option present.
このオプションは最後のMobility Optionプレゼントであるに違いありません。
6.5.5. Neighbor Advertisement Acknowledgment (NAACK)
6.5.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 15: Neighbor Advertisement Acknowledgment Option
図15: 隣人広告承認オプション
Type: 20
以下をタイプしてください。 20
Length: 8-bit unsigned integer. Length of the option, in 8 octets.
長さ: 8ビットの符号のない整数。 8つの八重奏における、オプションの長さ。
Koodli, Ed. Standards Track [Page 36] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[36ページ]RFC5268
The length is 1 when a new CoA is not supplied. The length is 3 when a new CoA is present (immediately following the Reserved field)
新しいCoAが供給されないとき、長さは1です。 新しいCoAが存在しているとき、長さは3です。(すぐに、Reserved野原に続きます)
Option-Code: 0
オプションコード: 0
Status: 8-bit unsigned integer indicating the disposition of the Unsolicited Neighbor Advertisement message. The following Status values are currently defined:
状態: Unsolicited Neighbor Advertisementメッセージの気質を示す8ビットの符号のない整数。 以下のStatus値は現在、定義されます:
1: NCoA is invalid, perform address configuration
2: NCoA is invalid, use the supplied NCoA. The supplied NCoA
(in the form of an IP Address Option) MUST be present following
the Reserved field.
3: NCoA is invalid, use NAR's IP address as NCoA in FBU
4: PCoA supplied, do not send FBU
128: Link-Layer Address unrecognized
1: NCoAは無効であり、アドレス構成2を実行してください: NCoAは無効であり、使用は供給されたNCoAです。 Reserved野原に続いて、供給されたNCoA(IP Address Optionの形の)は存在していなければなりません。 3: NCoAは無効であり、使用はFBU4のNCoAとしてNARのIPアドレスです: PCoAを供給して、FBU128を送らないでください: リンク層のAddress認識されていません。
Reserved: MUST be set to zero by the sender and MUST be ignored by
the receiver.
予約される: 送付者がゼロに設定しなければならなくて、受信機で無視しなければなりません。
The NAR responds to UNA with the NAACK option to notify the MN to use a different NCoA than the one that the MN has used. If the NAR proposes a different NCoA, the Router Advertisement MUST use the source IP address in the UNA message as the destination address, and use the L2 address present in UNA. The MN MUST use the NCoA if it is supplied with the NAACK option. If the NAACK indicates that the Link-Layer Address is unrecognized, for instance, if the MN uses an LLA valid on PAR's link but the same LLA is not valid on NAR's link due to a different access technology, the MN MUST NOT use the NCoA or the PCoA and SHOULD start immediately the process of acquiring a different NCoA at the NAR.
NARは、ミネソタが異なったNCoAを使用するように通知するためにミネソタが使用したものよりNAACKオプションでUNAに応じます。 NARが異なったNCoAを提案するなら、Router Advertisementは送付先アドレスとしてUNAメッセージでソースIPアドレスを使用して、UNAの現在のL2アドレスを使用しなければなりません。 NAACKオプションをそれに供給するなら、ミネソタはNCoAを使用しなければなりません。 NAACKが、異なったアクセス技術のため例えば、ミネソタがPARのリンクで有効なLLAを使用しますが、同じLLAが有効でないならAddress Link-層がNARのリンクで認識されていないのを示すなら、ミネソタはNCoAかPCoAを使用してはいけません、そして、SHOULDはすぐに、NARで異なったNCoAを獲得するプロセスを始めます。
In the future, new option types may be defined.
将来、新しいオプションタイプは定義されるかもしれません。
7. Related Protocol and Device Considerations
7. 関連プロトコルとデバイス問題
The protocol specified here, as a design principle, introduces no or minimal changes to related protocols. For example, no changes to the base Mobile IPv6 protocol are needed in order to implement this protocol. Similarly, no changes to the IPv6 stateless address auto- configuration protocol [RFC4862] and DHCP [RFC3315] are introduced. The protocol specifies an optional extension to Neighbor Discovery [RFC4861] in which an access router may send a router advertisement as a response to the UNA message (see Section 6.4). Other than this extension, the specification does not modify Neighbor Discovery behavior (including the procedures performed when attached to the PAR and when attaching to the NAR).
設計原理としてここで指定されたプロトコルはいいえか最小量の変化を関連するプロトコルに紹介します。 例えば、モバイルIPv6が議定書の中で述べるベースへの変化は、全くこのプロトコルを実装するのに必要ではありません。 同様に、IPv6の状態がないアドレス自動構成プロトコルへの変化がなく[RFC4862]てDHCP[RFC3315]を導入します。 プロトコルはアクセスルータがUNAメッセージへの応答としてルータ通知を送るかもしれないNeighborディスカバリー[RFC4861]に任意の拡大を指定します(セクション6.4を見てください)。 この拡大以外に、仕様はNeighborディスカバリーの振舞い(NARに付きながらPARといつに付けられるかと実行された手順を含んでいる)を変更しません。
Koodli, Ed. Standards Track [Page 37] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[37ページ]RFC5268
The protocol does not require changes to any intermediate Layer 2 device between an MN and its access router that supports this specification. This includes the wireless access points, switches, snooping devices, and so on.
プロトコルはミネソタとそのアクセスルータの間のこの仕様をサポートするどんな中間的Layer2デバイスへの変化も必要としません。 これはワイヤレス・アクセスポイント、スイッチ、デバイスについて詮索して、などを含んでいます。
8. Evolution from and Compatibility with RFC 4068
8. RFC4068との発展と互換性
This document has evolved from [RFC4068]. Specifically, a new handover key establishment protocol (see [RFC5269]) has been defined to enable a security association between a mobile node and its access router. This allows the secure update of the routing of packets during a handover. In the future, new specifications may be defined to establish such security associations depending on the particular deployment scenario.
このドキュメントは[RFC4068]から発展しました。 明確に、新しい引き渡し主要な設立プロトコル([RFC5269]を見る)は、モバイルノードとそのアクセスルータとのセキュリティ協会を可能にするために定義されました。 これは引き渡しの間のパケットのルーティングの安全なアップデートに. Inを許容します。将来的で、新しい仕様は、特定の展開シナリオによって、そのようなセキュリティ協会を証明するために定義されるかもしれません。
The protocol has improved from the experiences in implementing [RFC4068], and from experimental usage. The input has improved the specification of parameter fields (such as lifetime, codepoints, etc.) as well as inclusion of new parameter fields in the existing messages. As of this writing, there are two publicly available implementations, [fmipv6] and [tarzan], and multiple proprietary implementations. Some experience suggests that the protocol meets the delay and packet loss requirements when used appropriately with particular radio access protocols. For instance, see [RFC5184] and [mip6-book]. Nevertheless, it is important to recognize that handover performance is a function of both IP layer operations, which this protocol specifies, and the particular radio access technology itself, which this protocol relies upon but does not modify.
プロトコルは[RFC4068]を実装する経験と、そして、実験用法から向上しました。 入力は既存のメッセージでの新しいパラメタ分野の包含と同様にパラメタ分野(生涯、codepointsなどの)の仕様を改良しました。 この書くこと現在、2つの公的に利用可能な実装、[fmipv6]、[tarzan]、および複数の独占実装があります。 何らかの経験が、特定のラジオアクセス・プロトコルと共に適切に使用されるとプロトコルが遅れとパケット損失必要条件を満たすのを示します。 例えば、[RFC5184]と[mip6-本]を見てください。 それにもかかわらず、引き渡し性能がこのプロトコルが指定するIP層の操作と特定のラジオアクセス技術自体の両方の機能であると認めるのは重要です。当てにしますが、このプロトコルは技術を変更しません。
An existing implementation of [RFC4068] needs to be updated in order to support this specification. The primary addition is the establishment of a security association between an MN and its access router (i.e., MN and PAR). One way to establish such a security association is specified in [RFC5269]. An implementation that complies with the specification in this document is likely to also work with [RFC4068], except for the Binding Authorization Data for FMIPv6 option (see Section 6.5.4) that can only be processed when security association is in place between a mobile node and its access router. This specification deprecates the Fast Neighbor Advertisement (FNA) message. However, it is acceptable for a NAR to process this message from a mobile node as specified in [RFC4068].
[RFC4068]の既存の実装は、この仕様をサポートするためにアップデートする必要があります。 プライマリ追加はミネソタとそのアクセスルータ(すなわち、ミネソタとPAR)とのセキュリティ協会の設立です。 そのようなセキュリティ協会を確立する1つの方法が[RFC5269]で指定されます。 また、仕様に従う実装も[RFC4068]と共に本書では働きそうです、モバイルノードとそのアクセスルータの間にセキュリティ協会が適所にあるときだけ処理できるFMIPv6オプション(セクション6.5.4を見る)のためのBinding Authorization Dataを除いて。 この仕様はFast Neighbor Advertisement(FNA)メッセージを非難します。 しかしながら、NARが[RFC4068]の指定されるとしてのモバイルノードからこのメッセージを処理するのは、許容できます。
Koodli, Ed. Standards Track [Page 38] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[38ページ]RFC5268
9. Configurable Parameters
9. 構成可能なパラメタ
Mobile nodes rely on configuration parameters shown in the table below. Each mobile node MUST have a configuration mechanism to adjust the parameters. Such a configuration mechanism may be either local (such as a command line interface) or based on central management of a number of mobile nodes.
モバイルノードは以下のテーブルに示された設定パラメータを当てにします。 それぞれのモバイルノードには、パラメタを調整する構成メカニズムがなければなりません。 そのような構成メカニズムは、多くのモバイルノードの主要な管理にローカルである(コマンドラインインタフェースなどの)、または基づいているかもしれません。
+-------------------+---------------+---------------+ | Parameter Name | Default Value | Definition | +-------------------+---------------+---------------+ | RTSOLPR_RETRIES | 3 | Section 6.1.1 | | MAX_RTSOLPR_RATE | 3 | Section 6.1.1 | | FBU_RETRIES | 3 | Section 6.3.1 | | PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.2 | | HI_RETRIES | 3 | Section 6.2.1 | +-------------------+---------------+---------------+
+-------------------+---------------+---------------+ | パラメタ名| デフォルト値| 定義| +-------------------+---------------+---------------+ | RTSOLPR_再試行| 3 | セクション6.1 .1| | マックス_RTSOLPR_レート| 3 | セクション6.1 .1| | FBU_再試行| 3 | セクション6.3 .1| | プロキシ_ノースダコタ_生涯| 1.5秒| セクション6.2 .2| | HI_再試行| 3 | セクション6.2 .1| +-------------------+---------------+---------------+
10. Security Considerations
10. セキュリティ問題
The following security vulnerabilities are identified and suggested solutions are mentioned.
以下のセキュリティの脆弱性は特定されます、そして、提案された解決法は言及されます。
Insecure FBU: in this case, packets meant for one address could be
stolen or redirected to some unsuspecting node. This concern is
the same as that in an MN and Home Agent relationship. Hence, the
PAR MUST ensure that the FBU packet arrived from a node that
legitimately owns the PCoA. The access router and its hosts may
use any available mechanism to establish a security association
that MUST be used to secure FBU. The current version of this
protocol relies on a companion protocol [RFC5269] to establish
such a security association. Using the shared handover key from
[RFC5269], the Authenticator in BADF option (see Section 6.5.4)
MUST be computed, and the BADF option included in FBU and FBack
messages.
不安定なFBU: この場合、パケットは、個人的には、何らかの疑わないノードにアドレスを盗むか、または転送できることを意味しました。 この関心は、ミネソタのそれと同じくらいとホームエージェント関係です。 したがって、PAR MUSTは、FBUパケットが合法的にPCoAを所有しているノードから到着したのを確実にします。 アクセスルータとそのホストは、FBUを固定するのに使用しなければならないセキュリティ協会を証明するのにどんな利用可能なメカニズムも使用するかもしれません。 このプロトコルの最新版は、そのようなセキュリティ協会を証明するために仲間プロトコル[RFC5269]を当てにします。 [RFC5269]から主要な共有された引き渡しを使用して、BADFオプション(セクション6.5.4を見る)におけるAuthenticatorを計算しなければなりませんでした、そして、BADFオプションはFBUとFBackにメッセージを含んでいました。
Secure FBU, malicious or inadvertent redirection: in this case,
the FBU is secured, but the target of binding happens to be an
unsuspecting node either due to inadvertent operation or due to
malicious intent. This vulnerability can lead to an MN with a
genuine security association with its access router redirecting
traffic to an incorrect address.
FBU、悪意があるか不注意なリダイレクションを機密保護してください: この場合、FBUは固定されていますが、不注意な操作のためか悪意がある意図のため結合の目標はたまたま疑わないノードです。 この脆弱性は不正確なアドレスにトラフィックを向け直すアクセスルータとの本物のセキュリティ関係があるミネソタに通じることができます。
However, the target of malicious traffic redirection is limited to
an interface on an access router with which the PAR has a security
association. The PAR MUST verify that the NCoA to which PCoA is
being bound actually belongs to NAR's prefix. In order to do
this, HI and HAck message exchanges are to be used. When NAR
しかしながら、悪意があるトラフィックリダイレクションの目標はPARにはセキュリティ協会があるアクセスルータでインタフェースに制限されます。 PAR MUSTは、PCoAが制限されている状態であるNCoAが実際にNARの接頭語に属すことを確かめます。 これをするために、HIとHAck交換処理は使用されていることです。 いつNAR
Koodli, Ed. Standards Track [Page 39] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[39ページ]RFC5268
accepts NCoA in HI (with Code = 0), it proxies NCoA so that any
arriving packets are not sent on the link until the MN attaches
and announces itself through UNA. Therefore, any inadvertent or
malicious redirection to a host is avoided. It is still possible
to jam a NAR's buffer with redirected traffic. However, since a
NAR's handover state corresponding to an NCoA has a finite (and
short) lifetime corresponding to a small multiple of anticipated
handover latency, the extent of this vulnerability is arguably
small.
NCoAがHIで受け入れる、(Codeが0と)等しく、それがプロキシNCoAであるので、ミネソタがUNAを通してそれ自体を付けて、発表するまで、どんな到着パケットもリンクに送られません。 したがって、ホストへのどんな不注意であるか悪意があるリダイレクションも避けられます。 NARのバッファを向け直されたトラフィックでふさぐのはまだ可能です。 しかしながら、NARのNCoAに対応する引き渡し州が有限で(短い)の生涯を予期された引き渡し潜在のわずかな倍数に対応するようにするので、この脆弱性の範囲は論証上わずかです。
Sending an FBU from a NAR's link: A malicious node may send an FBU
from a NAR's link providing an unsuspecting node's address as an
NCoA. This is similar to base Mobile IP where the MN can provide
some other node's IP address as its CoA to its Home Agent; here
the PAR acts like a "temporary Home Agent" having a security
association with the Mobile Node and providing forwarding support
for the handover traffic. As in base Mobile IP, this misdelivery
is traceable to the MN that has a security association with the
router. So, it is possible to isolate such an MN if it continues
to misbehave. Similarly, an MN that has a security association
with the PAR may provide the LLA of some other node on NAR's link,
which can cause misdelivery of packets (meant for the NCoA) to an
unsuspecting node. It is possible to trace the MN in this case as
well.
NARのものからFBUを送って、以下をリンクしてください。 悪意があるノードはNCoAとして疑わないノードのアドレスを提供するNARのリンクからFBUを送るかもしれません。 これはミネソタがCoAとしてある他のノードのIPアドレスをホームのエージェントに提供できるモバイルIPを基礎づけるために同様です。 ここで、PARは、「一時的なホームのエージェント」のように引き渡しトラフィックのサポートを進めるモバイルNodeと提供とのセキュリティ協会を持ちながら、行動します。 ベースのモバイルIPのように、この配達ミスはルータとのセキュリティ協会を持っているミネソタに起因しています。 それで、ふらちな事をし続けているなら、そのようなミネソタを隔離するのは可能です。 同様に、PARとのセキュリティ協会を持っているミネソタはNARのリンクの上のある他のノードのLLAを提供するかもしれません。リンクはパケット(NCoAのために、意味される)の配達ミスを疑わないノードに引き起こす場合があります。 また、この場合ミネソタをたどるのは可能です。
Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv (Section 6.1.2) messages inherit the weaknesses of Neighbor Discovery protocol [RFC4861]. Specifically, when its access router is compromised, the MN's RtSolPr message may be answered by an attacker that provides a rogue router as the resolution. Should the MN attach to such a rogue router, its communication can be compromised. Similarly, a network-initiated PrRtAdv message (see Section 3.3) from an attacker could cause an MN to handover to a rogue router. Where these weaknesses are a concern, a solution such as Secure Neighbor Discovery (SEND) [RFC3971] SHOULD be considered.
上記は別として、RtSolPr(セクション6.1.1)とPrRtAdv(セクション6.1.2)メッセージはNeighborディスカバリープロトコル[RFC4861]の弱点を引き継ぎます。 アクセスルータに感染されるとき、明確に、ミネソタのRtSolPrメッセージは解決として凶暴なルータを提供する攻撃者によって答えられるかもしれません。 ミネソタがそのような凶暴なルータに付くなら、コミュニケーションに感染することができます。 同様に、攻撃者からのネットワークによって開始されたPrRtAdvメッセージ(セクション3.3を見る)は凶暴なルータへの引き渡しようにミネソタを引き起こす場合がありました。 Secure Neighborディスカバリー(SEND)[RFC3971]SHOULDなどのソリューションはこれらの弱点がどこの関心であるか考えられます。
The protocol provides support for buffering packets during an MN's handover. This is done by securely exchanging the Handover Initiate (HI) and Handover Acknowledgment (HAck) messages in response to the FBU message from an MN. It is possible that an MN may fail, either inadvertently or purposely, to undergo handover to the NAR, which typically provides buffering support. This can cause the NAR to waste its memory containing the buffered packets, and in the worst case, could create resource exhaustion concerns. Hence, implementations must limit the size of the buffer as a local policy configuration, which may consider parameters such as the average handover delay, expected size of packets, and so on.
プロトコルはミネソタの引き渡しの間、パケットをバッファリングするサポートを提供します。しっかりとミネソタからのFBUメッセージに対応してHandover Initiate(HI)とHandover Acknowledgment(HAck)メッセージを交換することによって、これをします。 ミネソタが行き詰まるのは、引き渡しをNARに受けるためにうっかりかわざわざ可能です。(NARは、サポートをバッファリングしながら、通常提供します)。 これで、NARはバッファリングされたパケットを含むメモリを浪費できます、そして、最悪の場合には、リソース疲労困憊心配を引き起こすことができました。 したがって、実装は地方の方針構成としてバッファのサイズを制限しなければなりません。(それは、平均した引き渡し遅れ、パケットの予想されたサイズなどなどのパラメタを考えるかもしれません)。
Koodli, Ed. Standards Track [Page 40] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[40ページ]RFC5268
The Handover Initiate (HI) and Handover Acknowledgement (HAck) messages exchanged between the PAR and NAR MUST be protected using end-to-end security association(s) offering integrity and data origin authentication.
保護された使用が終わりから終わりへのセキュリティ協会であったなら発生源認証を保全とデータに提供しながらPARとNAR MUSTの間で交換されたHandover Initiate(HI)とHandover Acknowledgement(HAck)メッセージ。
The PAR and the NAR MUST implement IPsec [RFC4301] for protecting the HI and HAck messages. IPsec Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. Confidentiality protection of these messages is not required.
PARとNAR MUSTは、HIとHAckメッセージを保護するために、IPsec[RFC4301]を実装します。 義務的な保全保護SHOULDがシグナリングメッセージを保護するのに使用されている交通機関によるIPsec Encapsulating Security有効搭載量(超能力)[RFC4303]。 これらのメッセージの秘密性保護は必要ではありません。
The security associations can be created by using either manual IPsec configuration or a dynamic key negotiation protocol such as Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306]. If IKEv2 is used, the PAR and the NAR can use any of the authentication mechanisms, as specified in RFC 4306, for mutual authentication. However, to ensure a baseline interoperability, the implementations MUST support shared secrets for mutual authentication. The following sections describe the Peer Authorization Database (PAD) and Security Policy Database (SPD) entries specified in [RFC4301] when IKEv2 is used for setting up the required IPsec security associations.
インターネット・キー・エクスチェンジプロトコルバージョン2など(IKEv2)[RFC4306]の手動のIPsec構成かダイナミックな主要な交渉プロトコルのどちらかを使用することによって、セキュリティ協会を創設できます。 IKEv2が使用されているなら、PARとNARは認証機構のどれかを使用できます、RFC4306で指定されるように、互いの認証のために。 しかしながら、基線相互運用性を確実にするために、実装は互いの認証のための共有秘密キーをサポートしなければなりません。 以下のセクションはPeer Authorization Database(PAD)について説明します、そして、Security Policy Database(SPD)エントリーは[RFC4301]でIKEv2がいつ必要なIPsecセキュリティ協会を設立するのに使用されるかを指定しました。
10.1. Peer Authorization Database Entries when Using IKEv2
10.1. 同輩Authorization Database Entries、Using IKEv2です。
This section describes PAD entries on the PAR and the NAR. The PAD entries are only example configurations. Note that the PAD is a logical concept and a particular PAR or NAR implementation can implement the PAD in any implementation specific manner. The PAD state may also be distributed across various databases in a specific implementation.
このセクションはPARとNARでPADエントリーについて説明します。 PADエントリーは例の構成にすぎません。 PADが論理的な概念であり、特定のPARかNAR実装がどんな実装の特定の方法でもPADを実装することができることに注意してください。 また、PAD状態は特定の実装における様々なデータベースの向こう側に分配されるかもしれません。
PAR PAD:
平価パッド:
- IF remote_identity = nar_identity_1
THEN authenticate (shared secret/certificate/EAP) and authorize
CHILD_SA for remote address nar_address_1
- _リモート_のアイデンティティがnar_アイデンティティと等しいなら、1THENがリモートアドレスnar_アドレス_1のためにCHILD_SAを認証して(共有秘密キー/証明書/EAP)、認可します。
NAR PAD:
NARはそっと歩きます:
- IF remote_identity = par_identity_1
THEN authenticate (shared secret/certificate/EAP) and authorize
CHILD_SAs for remote address par_address_1
- _リモート_のアイデンティティが平価_アイデンティティと等しいなら、1THENがリモートアドレス平価_アドレス_1のためにCHILD_SAsを認証して(共有秘密キー/証明書/EAP)、認可します。
The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD.
上記の例の認証機構のリストは徹底的ではありません。 PADに保存された認証に使用される他の資格証明書があるかもしれません。
Koodli, Ed. Standards Track [Page 41] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[41ページ]RFC5268
10.2. Security Policy Database Entries
10.2. 安全保障政策データベースエントリー
This section describes the security policy entries on the PAR and the NAR required to protect the HI and HAck messages. The SPD entries are only example configurations. A particular PAR or NAR implementation could configure different SPD entries as long as they provide the required security.
このセクションはPARで安全保障政策エントリーについて説明します、そして、NARがHIとHAckメッセージを保護するのが必要です。 SPDエントリーは例の構成にすぎません。 必要なセキュリティを提供する限り、特定のPARかNAR実装が異なったSPDエントリーを構成するかもしれません。
In the examples shown below, the identity of the PAR is assumed to be par_1, the address of the PAR is assumed to be par_address_1, and the address of the NAR is assumed to be nar_address_1.
以下の例では、PARのアイデンティティは平価_1であると思われます、そして、PARのアドレスは平価_アドレス_1であると思われます、そして、NARのアドレスはnar_アドレス_1であると思われます。
PAR SPD-S:
平価SPD-S:
- IF local_address = par_address_1 & remote_address =
nar_address_1 & proto = ICMPv6 & local_icmpv6_type = HI &
remote_icmpv6_type = HAck
THEN use SA ESP transport mode Initiate using IDi = par_1 to
address nar_address_1
- IF local_address = par_address_1 & remote_address = nar_address_1 & proto = ICMPv6 & local_icmpv6_type = HI & remote_icmpv6_type = HAck THEN use SA ESP transport mode Initiate using IDi = par_1 to address nar_address_1
NAR SPD-S:
NAR SPD-S:
- IF local_address = nar_address_1 & remote_address =
par_address_1 & proto = ICMPv6 & local_icmpv6_type = HAck &
remote_icmpv6_type = HI
THEN use SA ESP transport mode
- IF local_address = nar_address_1 & remote_address = par_address_1 & proto = ICMPv6 & local_icmpv6_type = HAck & remote_icmpv6_type = HI THEN use SA ESP transport mode
11. IANA Considerations
11. IANA問題
This document defines a new ICMPv6 message, which has been allocated from the ICMPv6 Type registry.
このドキュメントは新しいICMPv6メッセージを定義します。(それは、ICMPv6 Type登録から割り当てられました)。
154 FMIPv6 Messages
154 FMIPv6メッセージ
This document creates a new registry for the 'Subtype' field in the above ICMPv6 message, called the "FMIPv6 Message Types". IANA has assigned the following values.
「FMIPv6メッセージタイプ」は、このドキュメントが上記のICMPv6メッセージの'Subtype'分野に新しい登録を作成すると呼びました。 IANAは以下の値を割り当てました。
+---------+-------------+---------------+ | Subtype | Description | Reference | +---------+-------------+---------------+ | 2 | RtSolPr | Section 6.1.1 | | 3 | PrRtAdv | Section 6.1.2 | | 4 | HI | Section 6.2.1 | | 5 | HAck | Section 6.2.2 | +---------+-------------+---------------+
+---------+-------------+---------------+ | Subtype| 記述| 参照| +---------+-------------+---------------+ | 2 | RtSolPr| セクション6.1 .1| | 3 | PrRtAdv| セクション6.1 .2| | 4 | こんにちは| セクション6.2 .1| | 5 | ハッキング| セクション6.2 .2| +---------+-------------+---------------+
Koodli, Ed. Standards Track [Page 42] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[42ページ]RFC5268
The values '0' and '1' are reserved. The upper limit is 255. An RFC is required for new message assignment.
値'0'と'1'は予約されています。 上限は255です。 RFCが新しいメッセージ課題に必要です。
The document defines a new Mobility Option that has received Type assignment from the Mobility Options Type registry.
ドキュメントはMobility Options Type登録からType課題を受け取った新しいMobility Optionを定義します。
1. Binding Authorization Data for FMIPv6 (BADF) option, described
in Section 6.5.4
1. セクション6.5.4で説明されたFMIPv6(BADF)オプションのための拘束力があるAuthorization Data
The document has received Type assignments for the following (see [RFC4068]):
ドキュメントは以下のためのType課題を受け取りました([RFC4068]を見てください):
The document defines the following Neighbor Discovery [RFC4861] options that have received Type assignment from IANA.
ドキュメントはIANAからType課題を受け取った以下のNeighborディスカバリー[RFC4861]オプションを定義します。
+---------+-----------------------------------------+---------------+ | Type | Description | Reference | +---------+-----------------------------------------+---------------+ | 17 | IP Address/Prefix Option | Section 6.5.1 | | 19 | Link-layer Address Option | Section 6.5.2 | | 20 | Neighbor Advertisement Acknowledgment | Section 6.5.5 | | | Option | | +---------+-----------------------------------------+---------------+
+---------+-----------------------------------------+---------------+ | タイプ| 記述| 参照| +---------+-----------------------------------------+---------------+ | 17 | IPアドレス/接頭語オプション| セクション6.5 .1| | 19 | リンクレイヤアドレスオプション| セクション6.5 .2| | 20 | 隣人広告承認| セクション6.5 .5| | | オプション| | +---------+-----------------------------------------+---------------+
The document defines the following Mobility Header messages that have received Type allocation from the Mobility Header Types registry.
ドキュメントはMobility Header Types登録からType配分を受けた以下の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
2. セクション6.3.2で説明された速いBinding Acknowledgment
The document defines the following Mobility Option that has received Type assignment from the Mobility Options Type registry.
ドキュメントはMobility Options Type登録からType課題を受け取った以下のMobility Optionを定義します。
1. Mobility Header Link-Layer Address option, described in
Section 6.5.3
1. セクション6.5.3で説明された移動性Header Link-層のAddressオプション
12. Acknowledgments
12. 承認
The editor would like to thank all those who have provided feedback on this specification, but can only mention a few here: Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj Premec, Subba Reddy, K. Raghav, Ranjit Wable, and Jonathan Wood. Behcet Sarikaya and Frank Xia are acknowledged for the feedback on operation over point-to-point links. The editor would like to acknowledge a contribution from James Kempf to improve this
エディタはこの仕様のフィードバックを提供しましたが、いくつかについてここに言及できるだけであるすべての人に感謝したがっています: ビジェイDevarapalli、Youn-ヒー・ハン、エミールIvov、Syam Madanapalli、Suvidhマートゥル、アンドレ・マーチン、ハビエル・マーチン、Koshiro三屋、ガブリエル・モンテネグロ、Takeshi小河、Sun Peng、YC Peng、アレックス・ペトレスク、Domagoj Premec、Subbaレディ、K.Raghav、ランジットWable、およびジョナサンWood。 Behcet Sarikayaとフランク・シャーはポイントツーポイント接続の上の操作のフィードバックのために承認されます。 エディタは、ジェームス・ケンフからの貢献がこれを改良すると認めたがっています。
Koodli, Ed. Standards Track [Page 43] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[43ページ]RFC5268
specification. Vijay Devarapalli provided text for the security configuration between access routers in Section 10. Thanks to Jari Arkko for the detailed AD Review, which has improved this document. The editor would also like to thank the [mipshop] working group chair Gabriel Montenegro and the erstwhile [mobile ip] working group chairs Basavaraj Patil and Phil Roberts for providing much support for this work.
仕様。 ビジェイDevarapalliはセクション10でアクセスルータの間のセキュリティ設定にテキストを提供しました。 詳細AD ReviewのためのヤリArkkoをありがとうございます。(Reviewはこのドキュメントを改良しました)。 また、エディタは、この仕事の多くのサポートを提供して頂いて、昔[モバイルip]のワーキンググループいすの[mipshop]ワーキンググループいすガブリエル・モンテネグロ、Basavarajパティル、およびフィル・ロバーツに感謝したがっています。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC5269] Kempf, J. and R. Koodli, "Distributing a Symmetric Fast
Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor
Discovery (SEND)", RFC 5269, June 2008.
[RFC5269] ケンフとJ.とR.Koodli、「安全な隣人発見(発信する)を使用することで左右対称の速いモバイルIPv6(FMIPv6)引き渡しキーを分配します」、RFC5269、2008年6月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
March 2006.
[RFC4443] コンタ、A.、デアリング、S.、およびM.グプタ(エド)、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC4443、2006年3月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T.,
Perkins, C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms(R.(エド))はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4306] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4861] Narten、T.、Nordmark、E.、シンプソン、W.、およびH.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] トムソンとS.とNarten、T.とT.Jinmei、「IPv6の状態がないアドレス自動構成」、RFC4862、2007年9月。
Koodli, Ed. Standards Track [Page 44] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[44ページ]RFC5268
13.2. Informative References
13.2. 有益な参照
[fmipv6] "fmipv6.org : Home Page", <http://fmipv6.org>.
[fmipv6]、「fmipv6.org:」 「ホームページ」、<http://fmipv6.org>。
[mip6-book] Koodli, R. and C. Perkins, "Mobile Internetworking with
IPv6, Chapter 22, John Wiley & Sons.", July 2007.
[mip6-本] KoodliとR.とC.パーキンス、「IPv6、第22章、ジョン・ワイリー、および息子がいるモバイルインターネットワーキング」、7月2007日
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC
3290, May 2002.
[RFC3290] Bernet、Y.、ブレーク、S.、グロースマン、D.、およびA.スミス、「非公式の管理はDiffservルータのためにモデル化します」、RFC3290、2002年5月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March
2005.
[RFC3971] Arkko、J.、エド、ケンフ、J.、Zill、B.、およびP.Nikander、「安全な隣人発見(発信する)」、RFC3971、3月2005日
[RFC4068] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC
4068, July 2005.
[RFC4068] Koodli、R.、エド、「速く、モバイルIPv6"、RFC4068、2005年7月に、引き渡します」。
[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.
Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3
(L3)-Driven Fast Handover", RFC 5184, May 2008.
[RFC5184]Teraoka、F.、精力的です、K.(三屋、K.、渋井、R.、およびK.Mitani)は「層の3(L3)の駆動速い引き渡しのための層2(L2)の抽象化を統一しました」、RFC5184、2008年5月。
[tarzan] "Nautilus6 - Tarzan",
<http://software.nautilus6.org/TARZAN/>.
[tarzan]、「Nautilus6--、ターザン、」、<http://software.nautilus6.org/TARZAN/>。
Koodli, Ed. Standards Track [Page 45] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[45ページ]RFC5268
Appendix A. Contributors
付録A.貢献者
This document has its origins in the fast handover design team in the erstwhile [mobile ip] working group. The members of this design team in alphabetical order were; Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis, and Alper Yegin.
このドキュメントは昔[モバイルip]のワーキンググループで速い引き渡しデザインチームで起源を発します。 このデザインチームのメンバーはアルファベット順にそうでした。 ゴパルDommety、カリム高架鉄道-Malki、モハメッド・カリル、チャールズ・パーキンス、Heshamソリマン、ジョージTsirtsis、およびAlper Yegin。
Appendix B. Changes since RFC 4068
RFC4068以来の付録B.変化
Following are the major changes and clarifications:
以下に、大きな変化と明確化があります:
o Specified security association between the MN and its Access
Router in the companion document [RFC5269].
o 仲間ドキュメント[RFC5269]のミネソタとそのAccess Routerとの指定されたセキュリティ協会。
o Specified Binding Authorization Data for Fast Handovers (BADF)
option to carry the security parameters used for verifying the
authenticity of FBU and FBack messages. The handover key used for
computing the Authenticator is specified in companion documents.
o Fast Handovers(BADF)オプションがセキュリティパラメタを運ぶ指定されたBinding Authorization Dataは、FBUとFBackの信憑性について確かめるのにメッセージを使用しました。 Authenticatorを計算するのに使用される引き渡しキーは仲間ドキュメントで指定されます。
o Specified the security configuration for inter - access router
signaling (HI, HAck).
o セキュリティ設定を指定する、アクセスルータが(HI、HAck)を示して、埋葬します。
o Added a section on prefix management between access routers and
illustrated protocol operation over point-to-point links.
o アクセスルータの間の接頭語管理でセクションを加えて、ポイントツーポイント接続の上でプロトコル操作を例証しました。
o Deprecated FNA, which is a Mobility Header message. In its place,
the Unsolicited Neighbor Advertisement (UNA) message from RFC 4861
is used.
o 推奨しないFNA。(そのFNAはMobility Headerメッセージです)。 場所では、RFC4861からのUnsolicited Neighbor Advertisement(UNA)メッセージが使用されています。
o Combined the IPv6 Address Option and IPv6 Prefix Option.
o IPv6アドレスオプションとIPv6接頭語オプションを結合しました。
o Added description of DAD requirement on NAR when determining NCoA
uniqueness in Section 4, "Protocol Details".
o セクション4でNCoAのユニークさを決定するときの「詳細について議定書の中で述べてください」というNARに関するDAD要件の記述を加えました。
o Added a new code value for gratuitous HAck message to trigger a HI
message.
o HIメッセージの引き金となる無料のHAckメッセージのために新法価値を高めました。
o Added Option-Code 5 in PrRtAdv message to indicate NETLMM usage.
o NETLMM用法を示すPrRtAdvメッセージでOption-コード5を加えました。
o Clarified protocol usage when DHCP is used for NCoA formulation
(Sections 6.1.2, 3.1, and 5.2). Added a new Code value (5) in
PrRtAdv (Section 6.1.2).
o DHCPがNCoA定式化(セクション6.1 .2、3.1、および5.2)に使用されるとき、プロトコル用法をはっきりさせました。 PrRtAdv(セクション6.1.2)で新しいCode価値(5)を高めました。
o Clarified that IPv6 Neighbor Discovery operations are a must in
Section 7, "Related Protocol and Device Considerations".
o はっきりさせられて、そのIPv6 Neighborディスカバリー操作はセクション7と、「関連プロトコルとデバイス問題」で絶対に必要なものです。
Koodli, Ed. Standards Track [Page 46] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[46ページ]RFC5268
o Clarified "PAR = temporary HA" for FBUs sent by a genuine MN to an
unsuspecting CoA.
o FBUsのためのはっきりさせられた「PAR=一時的なHA」は本物のミネソタのそばで疑わないCoAに発信しました。
Editor's Address
エディタのアドレス
Rajeev Koodli Starent Networks USA
Rajeev Koodli Starentネットワーク米国
EMail: rkoodli@starentnetworks.com
メール: rkoodli@starentnetworks.com
Koodli, Ed. Standards Track [Page 47] RFC 5268 MIP6 Fast Handovers June 2008
エドKoodli、MIP6が2008年6月に速く引き渡す標準化過程[47ページ]RFC5268
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を扱ってください。
Koodli, Ed. Standards Track [Page 48]
エドKoodli、標準化過程[48ページ]
一覧
スポンサーリンク
