RFC4988 日本語訳
4988 Mobile IPv4 Fast Handovers. R. Koodli, C. Perkins. October 2007. (Format: TXT=57921 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Koodli
Request for Comments: 4988 C. Perkins
Category: Experimental Nokia Siemens Networks
October 2007
Koodliがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4988年のC.パーキンスカテゴリ: 実験的なノキアシーメンスは2007年10月をネットワークでつなぎます。
Mobile IPv4 Fast Handovers
モバイルIPv4速い身柄の引き渡し
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address.
このドキュメントは、モバイルIPv4引き渡し操作から生じる遅れとパケット損失を向上させるためにモバイルIPv6 Fast Handoversを適合させます。 明確に、このドキュメントは、引き渡しの間、動きが検出と、IPアドレス構成と、位置のアップデート潜在であると扱います。IPアドレス構成レイテンシを減少させるために、ドキュメントがそれを提案する、新しさ、Care、-、Addressは新しいアクセスルータのIPアドレスであることがいつも作られています。
Koodli & Perkins Experimental [Page 1] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[1ページ]のRFC4988
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Factors Affecting Handover ......................................5
4. Protocol ........................................................6
4.1. Overview ...................................................6
4.2. Operation ..................................................7
5. Message Formats ................................................10
5.1. Fast Binding Update (FBU) .................................10
5.2. Fast Binding Acknowledgment (FBAck) .......................12
5.3. Router Solicitation for Proxy Advertisement (RtSolPr) .....13
5.4. Proxy Router Advertisement (PrRtAdv) ......................14
5.5. Handover Initiate (HI) ....................................17
5.6. Handover Acknowledge (HAck) ...............................19
6. Option Formats .................................................20
6.1. Link-Layer Address Option Format ..........................20
6.2. New IPv4 Address Option Format ............................22
6.3. New Router Prefix Information Option ......................22
7. Security Considerations ........................................23
8. IANA Considerations ............................................24
9. Acknowledgments ................................................25
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................26
1. 序論…3 2. 用語…4 3. 引き渡しに影響する要素…5 4. 議定書を作ってください…6 4.1. 概要…6 4.2. 操作…7 5. メッセージ形式…10 5.1. 速く付いて、(FBU)をアップデートしてください…10 5.2. 速く、承認(FBAck)を縛ります…12 5.3. プロキシ広告(RtSolPr)のためのルータ懇願…13 5.4. プロキシルータ通知(PrRtAdv)…14 5.5. 引き渡し開始(HI)…17 5.6. 引き渡しは(ハッキング)を承認します…19 6. オプション形式…20 6.1. リンクレイヤアドレスオプション形式…20 6.2. 新しいIPv4は、オプションが形式であると扱います…22 6.3. 新しいルータ接頭語情報オプション…22 7. セキュリティ問題…23 8. IANA問題…24 9. 承認…25 10. 参照…25 10.1. 標準の参照…25 10.2. 有益な参照…26
Koodli & Perkins Experimental [Page 2] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[2ページ]のRFC4988
1. Introduction
1. 序論
This document adapts the fast handover specification [rfc4068] to IPv4 networks. The fast handover protocol specified in this document is particularly interesting for operation over links such as IEEE 802 wireless links. Fast handovers are not typically needed for wired media due to the relatively large delays attributable to establishing new connections in today's wired networks. Mobile IPv4 [rfc3344] registration messages are reused (with new type numbers) in this document to enable faster implementation using existing Mobile IPv4 software. This document does not require link-layer triggers for protocol operation, but performance will typically be enhanced by using the appropriate triggers when they are available. This document assumes that the reader is familiar with the basic operation and terminology of Mobile IPv4 [rfc3344] and Fast Handovers for Mobile IPv6 [rfc4068].
このドキュメントは速い引き渡し仕様[rfc4068]をIPv4ネットワークに適合させます。 本書では指定された速い引き渡しプロトコルはIEEE802のワイヤレスのリンクなどのリンクの上の操作によって特におもしろいです。 速い身柄の引き渡しは新しい接続を今日の有線ネットワークに確立するのに起因する比較的大きい遅れのためワイヤードなメディアに通常必要ではありません。 モバイルIPv4[rfc3344]登録メッセージは、既存のモバイルIPv4ソフトウェアを使用することで、より速い実装を可能にするために本書では再利用されます(新しい形式数で)。 このドキュメントはプロトコル操作のためのリンクレイヤ引き金を必要としませんが、性能は、それらが利用可能であるときに適切な引き金を使用することによって、通常高められるでしょう。 このドキュメントは、モバイルIPv6[rfc4068]に、読者がモバイルIPv4[rfc3344]とFast Handoversの基本的な操作と用語に詳しいと仮定します。
The active agents that enable continued packet delivery to a mobile node (MN) are the access routers on the networks that the mobile node connects to. Handover means that the mobile node changes its network connection, and we consider the scenario in which this change means change in access routers. The mobile node utilizes the access routers as default routers in the normal sense, but also as partners in mobility management. Thus, when the mobile node moves to a new network, it processes handover-related signaling in order to identify and develop a relationship with a new access router. In this document, we call the previous access router PAR and the new access router NAR, consistent with the terminology in [rfc4068]. Unless otherwise mentioned, a PAR is also a Previous Foreign Agent (PFA) and a NAR is also a New Foreign Agent (NFA).
モバイルノード(ミネソタ)に継続的なパケット配信を可能にする活発なエージェントはモバイルノードが接続するネットワークのアクセスルータです。 引き渡しは、モバイルノードがネットワーク接続を変えることを意味します、そして、私たちはこの変化がアクセスルータで変化することを意味するシナリオを考えます。 モバイルノードは、デフォルトルータとして正常な意味でアクセスルータを利用しますが、移動性管理のパートナーとしても利用します。 したがって、モバイルノードが新しいネットワークに移行すると、それは、新しいアクセスルータとの関係を特定して、育むために引き渡し関連のシグナリングを処理します。 本書では、私たちは、前のアクセスルータPARと新しいアクセスルータをNARと呼びます、[rfc4068]の用語と一致しています。 別の方法で言及されない場合、また、PARはPrevious Foreignエージェント(PFA)です、そして、また、NARはNew Foreignエージェント(NFA)です。
On a particular network, a mobile node may obtain its IP address via DHCP [rfc2131] (i.e., Co-located Care-of Address) or use the Foreign Agent CoA. During a handover, the new CoA (NCoA) is always made to be that of NAR. This allows a mobile node to receive and send packets using its previous CoA (PCoA), so that delays resulting from IP configuration (such as DHCP address acquisition delay) subsequent to attaching to the new link are disengaged from affecting the existing sessions.
モバイルノードがDHCP[rfc2131]を通して特定のネットワークでは、IPアドレスを得るかもしれない、(すなわち、Coによって見つけられる、Care、-、Address、)、ForeignエージェントCoAを使用してください。 引き渡しの間、新しいCoA(NCoA)はNARのものであることがいつも作られています。 これで、モバイルノードは、パケットを受けて、前のCoA(PCoA)を使用することで送ります、新しいリンクに付くことへのその後のIP構成(DHCPアドレス獲得遅れなどの)から生じる遅れが既存のセッションに影響するので解放されるように。
Unlike in Mobile IPv6, a Mobile IPv4 host may rely on its Foreign Agent to provide a Care-of Address. Using the protocol specified in this document, the binding at the PAR is always established between the on-link address the mobile node is using and a new CoA that it can use on the NAR's link. When FA-CoA is used, the on-link address is the MN's home address, not the FA-CoA itself, which needs to be
モバイルIPv6で異なって、モバイルIPv4ホストがaを提供するためにForeignエージェントに頼るかもしれない、Care、-、Address。 本書では指定されたプロトコルを使用して、PARでの結合はモバイルノードが使用しているオンリンクアドレスとそれがNARのリンクの上に使用できる新しいCoAの間でいつも確立されます。 FA-CoAが使用されているとき、オンリンクアドレスはFA-CoAではなく、必要があるミネソタのホームアドレス自体です。
Koodli & Perkins Experimental [Page 3] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[3ページ]のRFC4988
bound to the NCoA. So, when we say "a binding is established between PCoA and NCoA", it is actually the home address of the mobile node that is bound to the NCoA in the FA-CoA mode.
NCoAにバウンドしてください。 それで、「結合はPCoAとNCoAの間で確立されます」と、私たちが言うとき、それは実際にFA-CoAモードでNCoAに縛られるモバイルノードに関するホームアドレスです。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Terminology
2. 用語
The terminology used in this document in based on [rfc4068] and [rfc3344]. We provide some definitions below for convenience.
用語は中で中で[rfc4068]と[rfc3344]に基づいたこのドキュメントを使用しました。 私たちは以下でのいくつかの定義を便利に提供します。
Mobile Node (MN): A Mobile IPv4 host.
モバイルノード(ミネソタ): モバイルIPv4ホスト。
Access Point (AP): A Layer 2 device connected to an IP subnet that
offers wireless connectivity to an MN. An Access Point Identifier
(AP-ID) refers to the AP's L2 address. Sometimes, AP-ID is also
referred to as a Base Station Subsystem ID (BSSID).
アクセスポイント(AP): Layer2デバイスはワイヤレスの接続性をミネソタに提供するIPサブネットに接続しました。 Access Point Identifier(AP-ID)はAPのL2アドレスを示します。 また、時々、AP-IDは基地の駅のSubsystem ID(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 default router subsequent to its
handover.
新しいアクセスルータ(NAR): ミネソタの引き渡しへのその後のデフォルトルータ。
Previous CoA (PCoA): The IP address of the MN valid on PAR's
subnet.
前のCoA(PCoA): PARのサブネットで有効なミネソタのIPアドレス。
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の接続性を得るプロセス。
(AP-ID, AR-Info) tuple: Contains an access router's L2 and IP
addresses, and the prefix valid on the interface to which the
Access Point (identified by AP-ID) is attached. The triplet
[Router's L2 address, Router's IP address, Prefix] is called
"AR-Info".
(AR-インフォメーション) AP-ID、tuple: Access Point(AP-IDによって特定される)が付けているインタフェースで有効なアクセスルータのL2、IPアドレス、および接頭語を含んでいます。 三つ子[ルータのL2アドレス、RouterのIPアドレス、Prefix]は「AR-インフォメーション」と呼ばれます。
Koodli & Perkins Experimental [Page 4] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[4ページ]のRFC4988
3. Factors Affecting Handover
3. 引き渡しに影響する要素
Both link-layer operations and IP-layer procedures affect the perceived handover performance. However, the overall performance is also (always) a function of specific implementation of the technology as well as the system configuration. This document only specifies IP layer protocol operations. The purpose of this section is to provide an illustration of events that affect handover performance, but it is purely informative.
リンクレイヤ操作とIP-層の手順の両方が知覚された引き渡し性能に影響します。 しかしながら、また(いつも)、総合的な性能はシステム構成と同様に技術の特定の実装の機能です。 このドキュメントはIP層のプロトコル操作を指定するだけです。 このセクションの目的が引き渡し性能に影響するイベントのイラストを提供することですが、それは純粋に有益です。
The IP-layer handover delay and packet loss are influenced by latencies due to movement detection, IP address configuration, and the Mobile IP registration procedure. Movement detection latency comes from the need to reliably detect movement to a new subnet. This is a function of the frequency of router advertisements as well as default agent reachability. IP address configuration latency depends on the particular IP CoA being used. If co-located mode with DHCP is used, the latency is quite likely going to be higher and potentially unacceptable for real-time applications such as Voice over IP. Finally, the Mobile IP registration procedure introduces a round-trip of delay between the Mobile Node and its Home Agent over the Internet. This delay is incurred after the mobile node performs movement detection and IP configuration.
IP-層の引き渡し遅れとパケット損失は動き検出、IPアドレス構成、およびモバイルIP登録手順のため潜在によって影響を及ぼされます。 動き検出潜在は動きを確かに検出する必要性から新しいサブネットに来ます。 これはデフォルトエージェントの可到達性と同様にルータ通知の頻度の関数です。 IPアドレス構成潜在は使用される特定のIP CoAによります。 DHCPがある共同見つけられたモードが使用されているなら、潜在は、より高くて、ボイス・オーバー IPなどのリアルタイムのアプリケーションには潜在的に容認できなくしに全くありそうな行くことです。 最終的に、モバイルIP登録手順はインターネットの上でモバイルNodeとそのホームのエージェントの間に遅れにおける往復のaを紹介します。 モバイルノードが動き検出とIP構成を実行した後にこの遅れは被られます。
Underlying the IP operations are link-layer procedures. These are technology-specific. For instance, in IEEE 802.11, the handover operation typically involves scanning access points over all available channels, selecting a suitable access point, and associating with it. It may also involve performing access control operations such as those specified in IEEE 802.1X [ieee-802.1x]. These delays contribute to the handover performance. See [fh-ccr] and Chapters 20 and 22 in [mi-book]. Optimizations are being proposed for standardization in IEEE; for instance, see [ieee-802.11r] and [ieee-802.21]. Together with appropriate implementation techniques, these optimizations can provide the required level of delay support at the link-layer for real-time applications.
IPの基礎となって、操作はリンクレイヤ手順です。 これらは技術特有です。 例えば、IEEE802.11に、引き渡し操作は、すべての利用可能なチャンネルの上にアクセスポイントをスキャンすることを通常伴います、適当なアクセスポイントを選択して、それと交際して。 また、それは、IEEE 802.1X[ieee-802.1x]で指定されたものなどのアクセス制御機能を実行することを伴うかもしれません。 これらの遅れは引き渡し性能に貢献します。 [ミ本]で[fh-ccr]と第20章と第22章を参照してください。 最適化はIEEEでの標準化のために提案されています。 例えば、[ieee-802.11r]と[ieee-802.21]を見てください。 適切な実装のテクニックと共に、これらの最適化はリンクレイヤで必要なレベルの遅れサポートをリアルタイムのアプリケーションに提供できます。
Koodli & Perkins Experimental [Page 5] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[5ページ]のRFC4988
4. Protocol
4. プロトコル
4.1. Overview
4.1. 概要
The design of the protocol is the same as for Mobile IPv6 [rfc4068]. Readers should consult [rfc4068] for details; here we provide a summary.
プロトコルのデザインはモバイルIPv6[rfc4068]のように同じです。 読者は詳細のために[rfc4068]に相談するべきです。 ここに、私たちは概要を提供します。
The protocol avoids the delay due to movement detection and IP configuration and disengages Mobile IP registration delay from the time-critical path. The protocol provides the surrounding network neighborhood information so that a mobile node can determine whether it is moving to a new subnet even before the handover. The information provided and the signaling exchanged between the local mobility agents allow the mobile node to send and receive packets immediately after handover. In order to disengage the Mobile IP registration latency, the protocol provides routing support for the continued use of a mobile node's previous CoA.
プロトコルは、動き検出とIP構成のため遅れを避けて、時間クリティカルパスからモバイルIP登録遅れを解放します。 プロトコルは、モバイルノードが、それが引き渡しの前にさえ新しいサブネットに移行しているかどうか決定できるように、周囲のネットワーク近所情報を前提とします。モバイルノードは、引き渡し直後地元の移動性エージェントの間で交換されたシグナリングで、パケットを情報が前提とされて、送って、受けます。モバイルIP登録潜在を解放するために、プロトコルはモバイルノードの前のCoAの継続的な使用のルーティングサポートを前提とします。
After a mobile node obtains its IPv4 Care-of Address, it builds a neighborhood access point and subnet map using the Router Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router Advertisement (PrRtAdv) messages. The mobile node may scan for access points (APs) based on the configuration policy in operation for its wireless network interface. If a scan detects a new AP, the mobile node resolves the corresponding AP Identifier to subnet information using the RtSolPr and PrRtAdv messages mentioned above.
aモバイル後ノードが得る、それ、IPv4 Care、-、Address、それはProxy Advertisement(RtSolPr)とProxy Router Advertisement(PrRtAdv)メッセージにRouter Solicitationを使用することで近所アクセスポイントとサブネット地図を造ります。 モバイルノードはワイヤレス・ネットワークインタフェースのために稼働中である構成方針に基づくアクセスポイント(APs)にスキャンするかもしれません。 スキャンが新しいAPを検出するなら、モバイルノードは、前記のようにRtSolPrとPrRtAdvメッセージを使用することでサブネット情報に対応するAP Identifierを決議します。
At some point, the mobile node decides to undergo handover. It sends a Fast Binding Update (FBU) message to PAR from the previous link or from the new link. An FBU message enables creation of a binding between the mobile node's previous CoA and the new CoA.
何らかのポイントでは、モバイルノードは、引き渡しを受けると決めます。それはFast Binding Update(FBU)メッセージを前のリンク、または、新しいリンクからPARに送ります。 FBUメッセージはモバイルノードの前のCoAと新しいCoAの間の結合の作成を可能にします。
The coordination between the access routers is done by way of the Handover Initiate (HI) and Handover Acknowledge (HAck) messages defined in [rfc4068]. After these signals have been exchanged between the previous and new access routers (PAR and NAR), data arriving at PAR will be tunneled to NAR for delivery to the newly arrived mobile node. The purpose of HI is to securely deliver the routing parameters for establishing this tunnel. The tunnel is created by the access routers in response to the delivery of the FBU from the mobile node.
[rfc4068]で定義されたHandover Initiate(HI)とHandover Acknowledge(HAck)メッセージを通してアクセスルータの間でコーディネートします。 前の、そして、新しいアクセスルータ(PARとNAR)の間でこれらの信号を交換した後に、新たに到着したモバイルノードへの配送のためにPARに到着するデータにNARにトンネルを堀るでしょう。 HIの目的はしっかりとこのトンネルを確立するためのルーティングパラメタを提供することです。 トンネルはアクセスルータによってFBUの配送に対応してモバイルノードから作成されます。
Koodli & Perkins Experimental [Page 6] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[6ページ]のRFC4988
4.2. Operation
4.2. 操作
In response to a handover trigger or indication, the mobile node sends a Fast Binding Update message to the Previous Access Router (PAR) (see Section 5.1). Depending on the Mobile IP mode of operation, the source IP address is either the Home Address (in FA CoA mode) or co-located CoA (in CCoA mode). The FBU message SHOULD (when possible) be sent while the mobile node is still connected to PAR. When sent in this "predictive" mode, the fields in the FBU MUST be set as follows:
引き渡し引き金か指示に対応して、モバイルノードはPrevious Access Router(PAR)にFast Binding Updateメッセージを送ります(セクション5.1を見てください)。 操作のモバイルIPモードによって、ソースIPアドレスは、ホームAddress(FA CoAモードによる)か共同見つけられたCoA(CCoAモードによる)のどちらかです。 FBUはSHOULDを通信させます(可能であるときに)。まだモバイルノードをPARに接続している間、送ってください。 いつが、この「予言」のモード、FBU MUSTの分野が以下の通り以下を設定することであることを送りましたか?
The Home Address field is either the Home Address or the co-
located CoA whenever the mobile node has a co-located CoA.
モバイルノードに共同見つけられたCoAがあるときはいつも、ホームAddress分野は、ホームAddressか共同見つけられたCoAのどちらかです。
The Home Agent field is set to PAR's IP address.
ホームエージェント分野はPARのIPアドレスに設定されます。
The Care-of Address field is the NAR's IP address (as discovered
via a PrRtAdv message).
Care、-、Address分野はNARのIPアドレス(PrRtAdvメッセージで発見されるように)です。
The fields in the IP header MUST be set as follows:
以下の通りIPヘッダーの分野を設定しなければなりません:
The Destination IP address is PAR's IP address.
Destination IPアドレスはPARのIPアドレスです。
The Source IP address is either the Home Address or the co-located
CoA whenever the mobile node has a co-located CoA.
モバイルノードに共同見つけられたCoAがあるときはいつも、Source IPアドレスは、ホームAddressか共同見つけられたCoAのどちらかです。
As a result of processing the FBU, PAR creates a binding between the address given by the mobile node in the Home Address field and NAR's IP address in its routing table. The PAR sends an FBack message (see Section 5.2) as a response to the mobile node.
FBUを処理することの結果、PARは経路指定テーブルのホームAddress分野でモバイルノードによって与えられたアドレスとNARのIPアドレスの間で結合を作成します。 PARはモバイルノードへの応答としてFBackメッセージ(セクション5.2を見る)を送ります。
The timeline for the predictive mode of operation (adapted from [rfc4068]) is shown in Figure 1.
操作([rfc4068]から、適合させられる)の予言のモードのためのスケジュールは図1に示されます。
Koodli & Perkins Experimental [Page 7] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[7ページ]のRFC4988
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FBU --------------------------->|
|<=================================== deliver packets
| | (including FBack)
| |<-----FBU-----------|
ミネソタ平価NAR| | | |------RtSolPr------->|、| | <、-、-、-、--PrRtAdv--------| | | | | |------FBU----------->|、-、-、-、-、-、-、--こんにちは--------->|、| | <、-、-、-、-、--ハッキング---------| | <--FBack---|--FBack--->|、|、|、| 前方に切断してください。| | パケット===============>|、|、|、|、|、|、| 接続してください。| | | | | |--------- FBU--------------------------->| |<================== パケットを提供してください。| | (FBackを含んでいます) | | <、-、-、-、--FBU-----------|
Figure 1: Predictive Fast Handover
図1: 予言の速い引き渡し
The mobile node sends the FBU, regardless of its previous transmission, when attachment to a new link is detected. This minimally allows NAR to detect the mobile node's attachment, but also the retransmission of FBU when an FBack has not been received yet. When sent in this "reactive" mode, the Destination IP address in the IP header MUST be NAR's IP address; the rest of the fields in the FBU are the same as in the "predictive" case.
新しいリンクへの付属が見つけられるとき、モバイルノードは前のトランスミッションにかかわらずFBUを送ります。 これで、NARはモバイルノードの付属を最少量で見つけることができますが、FBackであるときに、FBUの「再-トランスミッション」はまだまた受け取られていません。 この「反応している」モードで送ると、IPヘッダーのDestination IPアドレスはNARのIPアドレスであるに違いありません。 FBUの分野の残りは「予言」のケースと同じです。
When NAR receives FBU, it may already have processed the HI message and created a host route entry for the mobile node, using either the home address or the co-located care-of address as provided by PAR. In that case, NAR SHOULD immediately forward arriving and buffered packets as well as the FBAck message. In any case, NAR MUST forward the contents of the FBU message, starting from the Type field, to PAR; the Source and Destination IP addresses in the new packet now contain the IP addresses of NAR and PAR, respectively.
NARがFBUを受けるとき、モバイルノードのために既にHIメッセージを処理して、ホストルートエントリーを作成したかもしれません、ホームアドレスか共同見つけのどちらかにされるのを使用して注意、-、PARによって提供されるアドレス。 その場合、NAR SHOULDはすぐに、FBAckメッセージと同様に到着とバッファリングされたパケットを進めます。 どのような場合でも、Type分野からPARまで始まって、NAR MUSTはFBUメッセージのコンテンツを進めます。 IPが現在新しいパケットで扱うSourceとDestinationはそれぞれNARとPARのIPアドレスを含んでいます。
The reactive mode of operation (adapted from [rfc4068]) is illustrated in Figure 2. Even though the Figure does not show the HI and HAck messages illustrated in Figure 1, these messages could already have been exchanged (in the case when the PAR has already processed the FBU sent from the previous link); if not, the PAR sends a HI message to the NAR. The FBack packet is forwarded by the NAR to the MN along with the data packets.
反応運転モード([rfc4068]から、適合させられる)は図2で例証されます。 図は、メッセージが図1で例証したのをHIとHAckに案内しませんが、既にこれらのメッセージを交換したかもしれません(PARが既に前のリンクから送られたFBUを処理したときの場合で)。 そうでなければ、PARはHIメッセージをNARに送ります。 FBackパケットはNARによってデータ・パケットに伴うミネソタに送られます。
Koodli & Perkins Experimental [Page 8] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[8ページ]のRFC4988
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-----------FBU-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| (including FBack)
| |
ミネソタ平価NAR| | | |------RtSolPr------->|、| | <、-、-、-、--PrRtAdv--------| | | | | 分離| | | | | | | | 接続してください。| | |-----------FBU-------|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| | <、-、-、-、--FBU-----------| | |------FBack-------->|、| 転送| | パケット===============>|、|、|、| |<================== パケットを提供してください。| (FBackを含んでいます) | |
Figure 2: Reactive Fast Handover
図2: 反応速い引き渡し
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages serve to establish a bidirectional tunnel between the routers to support packet forwarding for PCoA. The tunnel itself is established as a response to the FBU message. The PAR sends the HI message with Code = 0 when it receives FBU with source IP address set to PCoA. The PAR sends HI with Code = 1 when it receives FBU with source IP address not set to PCoA (i.e., when received from NAR). This allows NAR to disambiguate HI message processing sent as a response to predictive and reactive modes of operation. If NAR receives a HI message with Code = 1, and it has already set up a host route entry and a reverse tunnel for PCoA, it SHOULD still respond with a HAck message, using an appropriate Code value defined in Section 5.6.
Handover Initiate(HI)とHandover Acknowledge(HAck)メッセージは、PCoAのためにパケット推進をサポートするためにルータの間の双方向のトンネルを確立するのに役立ちます。 トンネル自体はFBUメッセージへの応答と書き立てられます。 それがPCoAに設定されたソースIPアドレスでFBUを受けるとき、PARはCode=0があるHIメッセージを送ります。 それがPCoAに設定されなかったソースIPアドレスでFBUを受けるとき(すなわち、NARから受け取ると)、PARはCode=1があるHIを送ります。 これで、NARは予言的で反応している運転モードへの応答として送られたHIメッセージ処理のあいまいさを除くことができます。 NARがCode=1でHIメッセージを受け取って、PCoAのために既にホストルートエントリーと逆のトンネルを設立して、それがスチール写真がHAckメッセージで反応させるSHOULDであるなら、適切なCode値を使用すると、セクション5.6は中で定義されました。
The protocol provides an option for NAR to return NCoA for use by the mobile node. When NAR can provide an NCoA for exclusive use of the mobile node, the address is supplied in the HAck message. The PAR includes this NCoA in FBack. Exactly how NAR manages the address pool from which it supplies NCoA is not specified in this document. Nevertheless, the MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address.
NARが使用のためにモバイルノードでNCoAを返すように、プロトコルはオプションを提供します。 NARがモバイルノードの専用にNCoAを提供できるとき、HAckメッセージでアドレスを供給します。 PARはFBackにこのNCoAを含んでいます。 NARがちょうど、どう、それがNCoAを供給するアドレスプールを管理するかは本書では指定されません。 それにもかかわらず、ミネソタはIPv4アドレスを得るためにDHCPか同様の操作を実行することの代わりにこのアドレスを使用するように準備されるべきです。
Even though the mobile node can obtain this NCoA from the NAR, it is unaware of the address at the time it sends an FBU. Hence, it binds PCoA to NAR's IP address as before.
モバイルノードはNARからこのNCoAを入手できますが、FBUを送るとき、それはアドレスに気づきません。 したがって、それは従来と同様NARのIPアドレスにPCoAを縛ります。
Koodli & Perkins Experimental [Page 9] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[9ページ]のRFC4988
5. Message Formats
5. メッセージ・フォーマット
This section specifies the formats for messages used in this protocol. The Code values below are the same as those in [rfc4068], and do not require any assignment from IANA.
このセクションはこのプロトコルに使用されるメッセージに形式を指定します。 以下のCode値は、[rfc4068]のそれらと同じであり、IANAからどんな課題も必要としません。
5.1. Fast Binding Update (FBU)
5.1. 速く、アップデートを縛ります。(FBU)
The FBU format is bitwise identical to the Registration Request format in [rfc3344]. The same destination port number, 434, is used, but the FBU and FBAck messages in this specification have new message type numbers.
FBU形式は[rfc3344]のRegistration Request形式と同じ状態でbitwiseすることです。 同じ目的地ポートナンバー(434)は使用されていますが、この仕様によるFBUとFBAckメッセージには、新しいメッセージ形式数があります。
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 |x|x|D|M|G|r|T|x| reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ|x|x|D|M|G|r|T|x| 予約されます。| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームのエージェント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 注意、-、アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 識別+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大… +-+-+-+-+-+-+-+-
Figure 3: Fast Binding Update (FBU) Message
図3: 速く、アップデート(FBU)メッセージを縛ります。
IP Fields:
IP分野:
Source address: The interface address from which the message is
sent. Either PCoA (co-located or Home Address), or NAR's IP
address (when forwarded from NAR to PAR).
ソースアドレス: メッセージが送られるインターフェース・アドレス。 PCoA(共同見つけられるかホームAddress)かNARのどちらかのIPアドレス(NARからPARまで進めると)。
Destination Address: The IP address of the Previous Access
Router (PAR) or the New Access Router (NAR).
送付先アドレス: Previous Access Router(PAR)かNew Access Router(NAR)のIPアドレス。
Source Port: variable
ソースポート: 変数
Destination port: 434
仕向港: 434
Koodli & Perkins Experimental [Page 10] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[10ページ]のRFC4988
Message Fields:
メッセージ分野:
Type: 20
以下をタイプしてください。 20
Flags: See [rfc3344]. The 'S' and 'B' flags in [rfc3344] are
sent as zero, and ignored on reception.
旗: [rfc3344]を見てください。 '、'ゼロとして送られて、レセプションで無視された[rfc3344]の'B'旗はそうです。
reserved: Sent as zero, ignored on reception
予約される: レセプションで無視されたゼロとして、発信します。
Lifetime: The number of seconds remaining before the binding
expires. This value MUST NOT exceed 10 seconds.
生涯: 結合の前に残っている秒数は期限が切れます。 この値は10秒を超えてはいけません。
Home Address: MUST be either the co-located CoA or the Home
Address itself (in FA-CoA mode)
ホームアドレス: 共同見つけられたCoAかホームAddressのどちらかがそれ自体であったならそうしなければなりません。(FA-CoAモードによる)
Home Agent: The Previous Access Router's global IP address
ホームのエージェント: Previous Access RouterのグローバルIPアドレス
Care-of Address: The New Access Router's global IP address.
Even when a New CoA is provided to the MN (see Section 5.4),
NAR's IP address MUST be used for this field.
注意、-、アドレス: New Access RouterのグローバルIPアドレス。 New CoAをミネソタに提供さえするとき(セクション5.4を見てください)、この分野にNARのIPアドレスを使用しなければなりません。
Identification: a 64-bit number used for matching an FBU with
FBack. Identical to usage in [rfc3344]
識別: 64ビットの数はマッチングにFBackとFBUを使用しました。 中の用法と同じです。[rfc3344]
Extensions: MUST contain the MN-PAR Authentication Extension
(see Section 8)
拡大: ミネソタ-PAR Authentication Extensionを含まなければなりません。(セクション8を見ます)
The MN-PAR Authentication Extension is the Generalized Mobile IP Authentication Extension in [rfc4721] with a new Subtype for MN-PAR Authentication. The Authenticator field in the Generalized Mobile IP Authentication Extension is calculated using a shared key between the MN and the PAR. However, the key distribution itself is beyond the scope of this document, and is assumed to be performed by other means (for example, using [rfc3957]).
ミネソタ-PAR Authentication Extensionはミネソタ-PAR Authenticationのための新しいSubtypeがある[rfc4721]のGeneralizedのモバイルIP Authentication Extensionです。 GeneralizedのモバイルIP Authentication ExtensionのAuthenticator分野は、ミネソタとPARの間の共有されたキーを使用することで計算されます。 しかしながら、主要な分配自体は、このドキュメントの範囲を超えていて、他の手段で実行されると思われます(例えば、[rfc3957]を使用します)。
Koodli & Perkins Experimental [Page 11] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[11ページ]のRFC4988
5.2. Fast Binding Acknowledgment (FBAck)
5.2. 速く、承認を縛ります。(FBAck)
The FBAck format is bitwise identical to the Registration Reply format in [rfc3344].
FBAck形式は[rfc3344]のRegistration Reply形式と同じ状態でbitwiseすることです。
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 | reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
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 4: Fast Binding Acknowledgment (FBAck)
図4: 速く、承認を縛ります。(FBAck)
IP Fields:
IP分野:
Message Source address: Typically copied from the destination
address of the FBU message
メッセージSourceアドレス: FBUメッセージの送付先アドレスから通常コピーされます。
Destination Address: Copied from the Source IP address in FBU
message
送付先アドレス: FBUメッセージのSource IPアドレスから、コピーされます。
Source Port: variable
ソースポート: 変数
Destination port: Copied from the source port in FBU message
仕向港: FBUメッセージのソースポートから、コピーされます。
Message Fields:
メッセージ分野:
Type: 21
以下をタイプしてください。 21
Code: Indicates the result of processing FBU message.
コード: 処理FBUメッセージの結果を示します。
0: FBU Accepted
1: FBU Accepted, NCoA supplied
128: FBU Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources
0: FBUは1を受け入れました: FBU Accepted、NCoAは128を供給しました: FBU Not Accepted、不特定の129を推論してください: 行政上、130を禁止します: 不十分なリソース
reserved: Sent as zero, ignored on reception
予約される: レセプションで無視されたゼロとして、発信します。
Koodli & Perkins Experimental [Page 12] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[12ページ]のRFC4988
Lifetime: The granted number of seconds remaining before
binding expires.
生涯: 結合の前に残っている与えられた秒数は期限が切れます。
Home Address: either the co-located CoA or the Home Address
itself (in FA-Coa mode)
ホームアドレス: 共同見つけられたCoAかホームAddress自身のどちらか(FA-コア川モードによる)
Home Agent: The Previous Access Router's global IP address
ホームのエージェント: Previous Access RouterのグローバルIPアドレス
Identification: a 64-bit number used for matching FBU. Copied
from the field in FBU for which this FBack is a reply.
識別: 64ビットの数はマッチングにFBUを使用しました。 このFBackが回答であるFBUの分野から、コピーされます。
Extensions: The MN-PAR Authentication extension MUST be present
(see Section 8). In addition, a New IPv4 Address Option, with
Option-Code 2, MUST be present when NAR supplies the NCoA (see
Section 6.2).
拡大: ミネソタ-PAR Authentication拡張子は存在していなければなりません(セクション8を見てください)。 NARがNCoAを供給するとき(セクション6.2を見てください)、さらに、New IPv4 Address OptionはOption-コード2について存在していなければなりません。
5.3. Router Solicitation for Proxy Advertisement (RtSolPr)
5.3. プロキシ広告のためのルータ懇願(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.1. The message format and processing rules are identical to those defined in [rfc4068].
Proxy Router Advertisementsのためにルータをうながして、モバイルNodesはProxy AdvertisementのためにRouter Solicitationを送ります。 すべてのリンクレイヤアドレスオプションには、セクション6.1で定義された書式があります。 メッセージ・フォーマットと処理規則は[rfc4068]で定義されたものと同じです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype| 予約されます。| 識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Router Solicitation for Proxy Advertisement (RtSolPr)
Message
図5: プロキシ広告(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.
送付先アドレス: または、Access Routerのアドレス、すべてのルータマルチキャストアドレス。
Time-to-Live: At least 1. See [rfc1256].
生きる時間: 少なくとも1。 [rfc1256]を見てください。
Koodli & Perkins Experimental [Page 13] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[13ページ]のRFC4988
ICMP Fields:
ICMP分野:
Type: 41. See Section 3 in [rfc4065].
以下をタイプしてください。 41. [rfc4065]でセクション3を見てください。
Code: 0
コード: 0
Checksum: The 16-bit one's complement of the one's complement
sum of the ICMP message, starting with the ICMP Type. For
computing the checksum, the Checksum and the Reserved fields
are set to 0. See [rfc1256].
チェックサム: ICMP TypeをきっかけにICMPメッセージの1の補数合計の16ビットの1の補数。 チェックサムを計算するのにおいて、ChecksumとReserved分野は0に用意ができています。 [rfc1256]を見てください。
Subtype: 6
Subtype: 6
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:
妥当な選択肢:
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
Section 6.1).
新しいアクセスポイントリンクレイヤアドレス: ミネソタがルーティング広告情報を要求するアクセスポイントのリンクレイヤアドレスか識別。 すべてのRtSolPrメッセージにそれを含まなければなりません。 アドレスかそのような識別子の1つ以上が、存在している場合があります。 また、この分野はワイルドカードアドレスであるかもしれません(セクション6.1を見てください)。
5.4. Proxy Router Advertisement (PrRtAdv)
5.4. プロキシルータ通知(PrRtAdv)
Access routers send out a Proxy Router Advertisement message gratuitously if the handover is network-initiated or as a response to RtSolPr message from a mobile node, providing the link-layer address, IP address, and subnet prefixes of neighboring access routers. All the link-layer address options have the format defined in Section 6.1.
引き渡しがネットワークによって開始されているなら、アクセスルータが無償でProxy Router Advertisementメッセージを出すか、またはモバイルノードからのRtSolPrメッセージへの応答、リンクレイヤアドレスを提供する、IPアドレス、およびサブネットとして、近所付き合いの接頭語はルータにアクセスします。 すべてのリンクレイヤアドレスオプションには、セクション6.1で定義された書式があります。
The message format and processing rules are identical to those defined in [rfc4068].
メッセージ・フォーマットと処理規則は[rfc4068]で定義されたものと同じです。
Koodli & Perkins Experimental [Page 14] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[14ページ]のRFC4988
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 6: Proxy Router Advertisement (PrRtAdv) Message
図6: プロキシルータ通知(PrRtAdv)メッセージ
IP Fields:
IP分野:
Source Address: An IP address assigned to the sending interface
ソースアドレス: 送付インタフェースに割り当てられたIPアドレス
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かAccess Routerが引き渡しに命令しているノードのアドレス。
Time-to-Live: At least 1. See [rfc1256].
生きる時間: 少なくとも1。 [rfc1256]を見てください。
ICMP Fields:
ICMP分野:
Type: 41. See Section 3 in [rfc4065].
以下をタイプしてください。 41. [rfc4065]でセクション3を見てください。
Code 0, 1, 2, 3, or 4. See below.
0、1、2、3、または4をコード化してください。 以下を見てください。
Checksum: The 16-bit one's complement of the one's complement
sum of the ICMP message, starting with the ICMP Type. For
computing the checksum, the Checksum and the Reserved fields
are set to 0. See [rfc1256].
チェックサム: ICMP TypeをきっかけにICMPメッセージの1の補数合計の16ビットの1の補数。 チェックサムを計算するのにおいて、ChecksumとReserved分野は0に用意ができています。 [rfc1256]を見てください。
Subtype: 7
Subtype: 7
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からZeroまでコピーされていますが、求められていません。
Valid Options in the following order:
以下の有効なOptionsは注文します:
New Access Point Link-layer Address: The link-layer address
(LLA) or identification of the access point. When there is no
wildcard in RtSolPr, this is copied from the LLA (for which the
router is supplying the [AP-ID, AR-Info] tuple) present in
新しいアクセスポイントリンクレイヤアドレス: アクセスポイントのリンクレイヤアドレス(LLA)か識別。 いつワイルドカードが全くRtSolPrになくて、これはLLA(ルータが[AP-ID、AR-インフォメーション]tupleを供給している)プレゼントからコピーされますか。
Koodli & Perkins Experimental [Page 15] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[15ページ]のRFC4988
RtSolPr. When a wildcard is present in RtSolPr, PAR uses its
neighborhood information to populate this field. This option
MUST be present.
RtSolPr。 ワイルドカードがRtSolPrに存在しているとき、PARは、この分野に居住するのに近所情報を使用します。 このオプションは存在していなければなりません。
New Router's Link-layer Address: The link-layer address of the
Access Router for which this message is proxied. This option
MUST be included when Code is 0 or 1.
新しいルータのリンクレイヤアドレス: このメッセージがproxiedされるAccess Routerのリンクレイヤアドレス。 Codeが0か1歳であるときに、このオプションを含まなければなりません。
New Router's IP Address: The IP address of NAR. This option
MUST be included when Code is 0 or 1.
新しいルータのIPアドレス: NARのIPアドレス。 Codeが0か1歳であるときに、このオプションを含まなければなりません。
New Router Prefix Information Option: The number of leading
bits that define the network number of the corresponding
Router's IP Address option (see above).
新しいルータ接頭語情報オプション: 対応するRouterのIP Addressオプション(上を見る)のネットワーク・ナンバーを定義する主なビットの数。
New CoA Option: MAY be present, typically when PrRtAdv is sent
unsolicited. PAR MAY compute new CoA by communicating with the
NAR or by means not specified in this document. In any case,
the MN should be prepared to use this address instead of
performing DHCP or similar operations to obtain an IPv4
address. Even when it uses the New CoA provided, the MN MUST
bind its current on-link address (PCoA) to that of NAR in the
FBU message.
新しいCoAオプション: プレゼント、通常いつPrRtAdvを送るかということであるかもしれません。求められていません。 PAR MAYはNARとコミュニケートするか、本書では指定されなかった手段で新しいCoAを計算します。 どのような場合でも、ミネソタはIPv4アドレスを得るためにDHCPか同様の操作を実行することの代わりにこのアドレスを使用するように準備されるべきです。 提供されたNew CoAを使用すると、ミネソタはFBUメッセージでリンクアドレスの現在の(PCoA)をNARのものに縛らなければなりません。
A PrRtAdv with Code 0 means that the MN should use the [AP-ID, AR-Info] tuple present in the options above. In this case, the Option-Code field (see Section 6.1) in the New AP LLA option is 1, reflecting the LLA of the access point for which the rest of the options are related, and the Option-Code for the New Router's LLA option is 3. Multiple tuples may be present.
Code0とPrRtAdvは、ミネソタが上のオプションに[AP-ID、AR-インフォメーション]tupleプレゼントを使用するべきであることを意味します。 この場合、New AP LLAオプションにおけるOption-コード分野(セクション6.1を見る)はオプションの残りが関係づけられるアクセスポイントのLLAを反映します、そして、1、New RouterのLLAオプションのためのOption-コードは3です。 複数のtuplesが存在しているかもしれません。
A PrRtAdv with Code 1 means that the message is sent unsolicited. If a New IPv4 option (see Figure 10) is present following the New Router Prefix Information option (see Section 6.3), the MN SHOULD use the supplied NCoA and send the FBU immediately or else stand to lose service. This message acts as a network-initiated handover trigger. The Option-Code field (see Section 6.1) in the New AP LLA option in this case is 1 reflecting the LLA of the access point for which the rest of the options are related.
Code1とPrRtAdvは、メッセージが送られることを意味します。求められていません。 New Router Prefix情報オプションに続いて、New IPv4オプション(図10を見る)が存在しているなら(セクション6.3を見てください)、MN SHOULDは、供給されたNCoAを使用して、すぐに、FBUを送るか、またはサービスを失うのをおごります。 このメッセージはネットワークによって開始された引き渡し引き金として機能します。 この場合、New AP LLAオプションにおけるOption-コード分野(セクション6.1を見る)はオプションの残りが関係づけられるアクセスポイントのLLAを反映する1です。
A Proxy Router Advertisement with Code 2 means that no new router information is present. The LLA option contains an Option-Code value that indicates a specific reason (see Section 6.1).
Code2とProxy Router Advertisementは、どんな新しいルータ情報も存在していないことを意味します。 LLAオプションは特定の理由を示すOption-コード値を含んでいます(セクション6.1を見てください)。
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 values in the LLA option distinguish different outcomes (see Section 6.1).
Code3とProxy Router Advertisementは、新しいルータ情報が単に要求されたアクセスポイントの部分集合のために存在していることを意味します。 LLAオプションにおけるOption-コード値は異なった結果を区別します(セクション6.1を見てください)。
Koodli & Perkins Experimental [Page 16] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[16ページ]のRFC4988
A Proxy Router Advertisement with Code 4 means that the subnet information regarding neighboring access points is sent unsolicited, but the message is not a handover trigger, unlike when the message is sent with Code 1. Multiple tuples may be present.
Code4とProxy Router Advertisementは、Code1と共に隣接しているアクセスポイントのサブネット情報が送って、求められていなくて、唯一のメッセージがメッセージが送られる時と異なった引き渡し引き金でないということであることを意味します。 複数のtuplesが存在しているかもしれません。
When a wildcard AP identifier is supplied in the RtSolPr message, the PrRtAdv message should include all available [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を含むべきです。
The New CoA option may also be used when the PrRtAdv is sent as a response to a RtSolPr message. However, the solicited RtSolPr and PrRtAdv exchange for neighborhood discovery is logically decoupled from the actual handover phase involving the FBU and FBack messages (above) as well as HI and HAck messages (see below). This means the access routers have to carefully manage the supplied address due to the relative scarcity of addresses in IPv4.
また、RtSolPrメッセージへの応答としてPrRtAdvを送るとき、New CoAオプションを使用するかもしれません。 しかしながら、近所発見への請求されたRtSolPrとPrRtAdv交換は論理的にHIとHAckメッセージと同様にFBUとFBackメッセージ(above)にかかわる実際の引き渡しフェーズから衝撃を吸収されます(以下を見てください)。 これは、アクセスルータがアドレスへのIPv4の相対的な不足のため慎重に供給されたアドレスを管理しなければならないことを意味します。
5.5. Handover Initiate (HI)
5.5. 引き渡し開始(HI)
The Handover Initiate (HI) is an ICMP message sent by an Access Router (typically PAR) to another Access Router (typically NAR) to initiate the process of a mobile node's handover.
Handover Initiate(HI)はモバイルノードの引き渡しのプロセスを開始するためにAccess Router(通常PAR)によって別のAccess Router(通常NAR)に送られたICMPメッセージです。
The message format and processing rules are identical to those defined in [rfc4068].
メッセージ・フォーマットと処理規則は[rfc4068]で定義されたものと同じです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |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 7: Handover Initiate (HI) Message
図7: 引き渡し開始(こんにちは)メッセージ
IP Fields:
IP分野:
Source Address: The IP address of the PAR
ソースアドレス: PARのIPアドレス
Destination Address: The IP address of the NAR
送付先アドレス: NARのIPアドレス
Time-to-Live: At least 1. See [rfc1256].
生きる時間: 少なくとも1。 [rfc1256]を見てください。
Koodli & Perkins Experimental [Page 17] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[17ページ]のRFC4988
ICMP Fields:
ICMP分野:
Type: 41. See Section 3 in [rfc4065].
以下をタイプしてください。 41. [rfc4065]でセクション3を見てください。
Code: 0 or 1. See below
コード: 0か1。 以下を見てください。
Checksum: The 16-bit one's complement of the one's complement
sum of the ICMP message, starting with the ICMP Type. For
computing the checksum, the Checksum and the Reserved fields
are set to 0. See [rfc1256].
チェックサム: ICMP TypeをきっかけにICMPメッセージの1の補数合計の16ビットの1の補数。 チェックサムを計算するのにおいて、ChecksumとReserved分野は0に用意ができています。 [rfc1256]を見てください。
Subtype: 8
Subtype: 8
S: Assigned address configuration flag. When set, this message
requests a new CoA to be returned by the destination. May be
set when Code = 0. MUST be 0 when Code = 1.
S: 割り当てられたアドレス構成旗。 設定されると、このメッセージは、目的地によって返されるよう新しいCoAに要求します。 Code=0であるのに、設定されるかもしれません。 0がいつCode=1であったかならそうしなければなりません。
U: Buffer flag. When set, the destination SHOULD buffer any
packets towards 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 MUST be
included so that a host route can be established on the NAR.
前である、注意、-、アドレス: 起因するルータに付けられている間にミネソタによって使用されたIPアドレス。 NARでホストルートを確立できるようにこのオプションを含まなければなりません。
New Care-of Address: This option MAY be present when the MN
wishes to use a new IP address when connected to the
destination. When the 'S' bit is set, NAR MAY provide this
address in HAck, in which case the MN should be prepared to use
this address instead of performing DHCP or similar operations
to obtain an IPv4 address.
新しさ、注意、-、アドレス: 目的地に接続されるとミネソタが新しいIPアドレスを使用したがっているとき、このオプションは存在しているかもしれません。 'いつ、'ビットは設定されます、とNAR MAYがHAck(ミネソタが準備されるべきであるそれのケースがIPv4アドレスを得るためにDHCPか同様の操作を実行することの代わりにこのアドレスを使用するコネ)のこのアドレスを前提とするということであるか。
PAR uses Code = 0 when it processes the FBU received with PCoA as source IP address. PAR uses Code = 1 when the FBU is received with NAR's IP address as the source IP address.
PCoAと共にソースIPアドレスとして受け取られたFBUを処理するとき、PARはCode=0を使用します。 ソースIPアドレスとしてNARのIPアドレスでFBUを受け取るとき、PARはCode=1を使用します。
Koodli & Perkins Experimental [Page 18] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[18ページ]のRFC4988
5.6. Handover Acknowledge (HAck)
5.6. 引き渡しは承認します。(ハッキング)
The Handover Acknowledgment message is a new ICMP message that MUST be sent (typically by NAR to PAR) as a reply to the Handover Initiate (HI) (see Section 5.5) message.
Handover Acknowledgmentメッセージは回答としてHandover Initiate(HI)(セクション5.5を見る)メッセージに送らなければならない(通常PARへのNAR)新しいICMPメッセージです。
The message format and processing rules are identical to those defined in [rfc4068].
メッセージ・フォーマットと処理規則は[rfc4068]で定義されたものと同じです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype| 予約されます。| 識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
Figure 8: Handover Acknowledge (HAck) Message
エイト環: 引き渡しは(ハッキング)メッセージを承認します。
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のソースアドレスから、コピーされます。
Time-to-Live: At least 1. See [rfc1256].
生きる時間: 少なくとも1。 [rfc1256]を見てください。
ICMP Fields:
ICMP分野:
Type: 41. See Section 3 in [rfc4065].
以下をタイプしてください。 41. [rfc4065]でセクション3を見てください。
Code:
コード:
0: Handover Accepted
1: Handover Accepted, NCoA not valid
2: Handover Accepted, NCoA in use
3: Handover Accepted, NCoA assigned (used in Assigned
addressing)
4: Handover Accepted, NCoA not assigned
128: Handover Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources
0: 引き渡しは1を受け入れました: 有効な2ではなく引き渡しAccepted、NCoA: 引き渡しAccepted、使用3でのNCoA: 引き渡しAccepted、NCoAは4を割り当てました(Assignedアドレシングで、使用されます): 引き渡しAccepted、NCoAは128を割り当てませんでした: 引き渡しNot Accepted、不特定の129を推論してください: 行政上、130を禁止します: 不十分なリソース
Koodli & Perkins Experimental [Page 19] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[19ページ]のRFC4988
Checksum: The 16-bit one's complement of the one's complement
sum of the ICMP message, starting with the ICMP Type. For
computing the checksum, the Checksum and the Reserved fields
are set to 0. See [rfc1256].
チェックサム: ICMP TypeをきっかけにICMPメッセージの1の補数合計の16ビットの1の補数。 チェックサムを計算するのにおいて、ChecksumとReserved分野は0に用意ができています。 [rfc1256]を見てください。
Subtype: 9
Subtype: 9
Reserved: MUST be set to zero by the sender and ignored by the
receiver.
予約される: 送付者によってゼロに設定されて、受信機で無視しなければなりません。
Identifier: Copied from the corresponding field in the Handover
Initiate message this message is in response to.
識別子: このメッセージに対応しているHandover Initiateメッセージの対応する分野から、コピーされます。
Valid Options:
妥当な選択肢:
New Care-of Address: If the 'S' flag in the HI 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 'S' bit is not set, e.g., Code 2 above. The MN should be
prepared to use this address instead of performing DHCP or
similar operations to obtain an IPv4 address.
新しさ、注意、-、アドレス: '、'HIメッセージの旗が設定している、このオプションはNCoAを提供するのに使用されて、ミネソタがこのルータに関連づけられたいつを使用するべきであるかということであるに違いありません。 'このオプションは含まれていて、いつが'ビットでさえあるか設定されないということであるかもしれなく、例えば、Codeは上の2です。 ミネソタはIPv4アドレスを得るためにDHCPか同様の操作を実行することの代わりにこのアドレスを使用するように準備されるべきです。
The Code 0 is the expected average case of a handover being accepted and the routing support provided for the use of PCoA. The rest of the Code values pertain to the use of NCoA (which is common in [rfc4068]). Code values 1 and 2 are for cases when the MN proposes an NCoA and the NAR provides a response. Code 3 is when the NAR provides NCoA (which could be the same as that proposed by the MN). Code 4 is when the NAR does not provide NCoA, but instead provides routing support for PCoA.
Code0は受け入れられる引き渡しの予想された平均したケースです、そして、ルーティングサポートはPCoAの使用に備えました。 値がNCoA([rfc4068]で一般的である)の使用に関係させるCodeの残り。 ミネソタがNCoAを提案して、NARが応答を提供するとき、コード値1と2はケースのためのものです。 コード3はNARがNCoAを提供する(どれがそれと同じであるかもしれないかはミネソタのそばで提案しました)時です。 コード4はNARがNCoAを提供しませんが、代わりにPCoAのルーティングサポートを提供する時です。
6. Option Formats
6. オプション形式
The options in this section are specified as extensions for the HI and HAck messages, as well as for the PrRtSol and PrRtAdv messages. The Option-Code values below are the same as those in [rfc4068], and do not require any assignment from IANA.
このセクションのオプションはHIとHAckメッセージのための拡大として指定されます、よくPrRtSolとPrRtAdvメッセージのように。 以下のOption-コード値は、[rfc4068]のそれらと同じであり、IANAからどんな課題も必要としません。
6.1. Link-Layer Address Option Format
6.1. リンクレイヤアドレスオプション形式
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 9: Link-Layer Address Option Format
図9: リンクレイヤアドレスオプション形式
Koodli & Perkins Experimental [Page 20] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[20ページ]のRFC4988
Fields:
分野:
Type: 20
以下をタイプしてください。 20
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
4: Link-Layer Address of the source of the RtSolPr or
PrRtAdv message
5: The access point identified by the LLA belongs to the
current interface of the router
6: No prefix information available for the access point
identified by the LLA
7: No fast handovers support available for the access point
identified by the LLA
0: すべての近いアクセスポイント1のための解決を要求するワイルドカード: 新しいアクセスポイント2のリンクレイヤアドレス: Mn3のリンクレイヤアドレス: NAR4のリンクレイヤアドレス: RtSolPrかPrRtAdvメッセージ5の源のリンク層のAddress: LLAによって特定されたアクセスポイントはルータ6の現在のインタフェースに属します: LLA7によって特定されたアクセスポイントに利用可能な接頭語情報がありません: アクセスポイントに利用可能なサポートがLLAで特定した速い身柄の引き渡しがありません。
Length: The length of the option (including the Type, Length
and Option-Code fields) in units of 8 octets.
長さ: 8つの八重奏のユニットのオプション(Type、Length、およびOption-コード分野を含んでいる)の長さ。
Link-Layer Address: The variable-length link-layer address.
The content and format of this field (including byte and bit
ordering) depends on the specific link-layer in use.
リンクレイヤアドレス: 可変長のリンクレイヤアドレス。 この分野(バイトと噛み付いている注文を含んでいる)の内容と形式は使用中の特定のリンクレイヤに依存します。
There is no length field for the LLA itself. Implementations MUST determine the length of the LLA based on the specific link technology where the protocol is run. The total size of the LLA option itself MUST be a multiple of 8 octets. Hence, padding may be necessary depending on the size of the LLA used. In such a case, the padN option [rfc2460] MUST be used. As an example, when the LLA is 6 bytes (meaning 7 bytes of padding is necessary to bring the LLA option length to 2), the padN option will have a length field of 5 and 5 bytes of zero-valued octets (see [rfc2460]).
LLA自身のための長さの分野が全くありません。 実装は、LLAの長さが、プロトコルがどこに実行されるかを特定のリンク技術に基礎づけたことを決定しなければなりません。 LLAオプション自体の総サイズは8つの八重奏の倍数であるに違いありません。 したがって、使用されるLLAのサイズによって、詰め物が必要であるかもしれません。 このような場合には、padNオプション[rfc2460]を使用しなければなりません。 LLAが6バイト(意味している7バイトの詰め物がLLAオプションの長さを2にもたらすのに必要である)であるときに、例として、padNオプションには、5と5バイトの無評価された八重奏の長さの分野があるでしょう([rfc2460]を見てください)。
Koodli & Perkins Experimental [Page 21] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[21ページ]のRFC4988
6.2. New IPv4 Address Option Format
6.2. 新しいIPv4アドレスオプション形式
This option is used to provide the new router's IPv4 address or the NCoA in PrRtAdv, as well as PCoA and NCoA in HI and HAck messages.
このオプションは新しいルータのIPv4アドレスかNCoAをPrRtAdvに供給するのに使用されます、HIのPCoAとNCoAとHAckメッセージと同様に。
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New IPv4 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| オプションコード| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 新しいIPv4アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: New IPv4 Address Option Format
図10: 新しいIPv4アドレスオプション形式
Fields:
分野:
Type: 21
以下をタイプしてください。 21
Length: The length of the option (including the Type, Length
and Option-Code fields) in units of 8 octets.
長さ: 8つの八重奏のユニットのオプション(Type、Length、およびOption-コード分野を含んでいる)の長さ。
Option-Code:
オプションコード:
1: Previous CoA
2: New CoA
3: NAR's IP Address
1: 前のCoA2: 新しいCoA3: NARのIPアドレス
Reserved: Set to zero.
予約される: ゼロにセットしてください。
New IPv4 Address: NAR's IPv4 address or the NCoA assigned by
NAR.
新しいIPv4アドレス: NARのIPv4アドレスかNARによって割り当てられたNCoA。
6.3. New Router Prefix Information Option
6.3. 新しいルータ接頭語情報オプション
This option is used in the PrRtAdv message.
このオプションはPrRtAdvメッセージで使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| オプションコード| 接頭語長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: New Router Prefix Information Option Format
図11: 新しいルータ接頭語情報オプション形式
Koodli & Perkins Experimental [Page 22] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[22ページ]のRFC4988
Fields:
分野:
Type: 22
以下をタイプしてください。 22
Length: The length of the option (including the Type, Length
and Option-Code fields) in units of 8 octets.
長さ: 8つの八重奏のユニットのオプション(Type、Length、およびOption-コード分野を含んでいる)の長さ。
Option-Code: 0
オプションコード: 0
Prefix-Length The number of leading bits that define the
network number of the corresponding Router's IP Address option.
接頭語長さ、対応するRouterのIP Addressオプションのネットワーク・ナンバーを定義する主なビットの数。
Reserved: Set to zero.
予約される: ゼロにセットしてください。
7. Security Considerations
7. セキュリティ問題
As outlined in [rfc4068], the following vulnerabilities are identified and the solutions mentioned.
[rfc4068]に概説されているように、以下の脆弱性は、特定されていて言及されたソリューションです。
Insecure FBU:
不安定なFBU:
Failure to protect the FBU message could result in packets meant for an address being stolen or redirected to some unsuspecting node. This concern is similar to that in Mobile Node and Home Agent relationship.
FBUメッセージを保護しない場合、盗まれて、アドレスのために意味されるか、または何らかの疑わないノードに向け直されたパケットをもたらすかもしれません。 この関心はモバイルNodeとホームエージェント関係においてそれと同様です。
Hence, the FBU and FBack messages MUST be protected using a security association shared between a mobile node and its access router. In particular, the MN-PAR Authentication Extension MUST be present in each of these messages. This document does not specify how the security association is established between an MN and the AR/FA.
したがって、モバイルノードとそのアクセスルータの間で共有されたセキュリティ協会を使用して、FBUとFBackメッセージを保護しなければなりません。 ミネソタ-PAR Authentication Extensionはそれぞれに関するこれらのメッセージに特に、存在していなければなりません。 このドキュメントはセキュリティ協会がミネソタとAR/FAの間にどう設立されるかを指定しません。
Secure FBU, malicious or inadvertent redirection:
FBU、悪意があるか不注意なリダイレクションを機密保護してください:
Even if the MN-PAR authentication extension is present in an FBU, an MN may inadvertently or maliciously attempt to bind its PCoA to an unintended address on NAR's link, and cause traffic flooding to an unsuspecting node.
ミネソタ-PAR認証拡張子がFBUに存在していても、ミネソタは、NARのリンクに関する故意でないアドレスにPCoAを縛って、原因トラフィック氾濫を疑わないノードに縛るのをうっかりか陰湿に試みるかもしれません。
This vulnerability is avoided by always binding the PCoA to the NAR's IP address, even when the NAR supplies an NCoA to use for the MN. It is still possible to jam NAR's buffer with redirected traffic. However, the handover state corresponding to the MN's PCoA has a finite lifetime, and can be configured to be a few multiples of the anticipated handover latency. Hence, the extent of this vulnerability is small. It is possible to trace the culprit MN with an established security association at the access router.
この脆弱性はいつもNARのIPアドレスにPCoAを縛ることによって、避けられます、NARがミネソタの使用にNCoAを供給さえするとき。 NARのバッファを向け直されたトラフィックでふさぐのはまだ可能です。 しかしながら、ミネソタのPCoAに対応する引き渡し状態は、有限生涯を持って、予期された引き渡し潜在のいくつかの倍数になるように構成できます。 したがって、この脆弱性の範囲はわずかです。 アクセスルータにおける設立されたセキュリティ関係と共に罪人ミネソタをたどるのは可能です。
Koodli & Perkins Experimental [Page 23] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[23ページ]のRFC4988
Communication between the access routers:
アクセスルータのコミュニケーション:
The access routers communicate using HI and HAck messages in order to establish a temporary routing path for the MN undergoing handover. This message exchange needs to be secured to ensure routing updates take place as intended.
アクセスルータは、一時的なルーティング経路を引き渡しを受けるミネソタに確立するのにHIとHAckメッセージを使用することで交信します。この交換処理は、ルーティングアップデートが意図されるとして行われるのを保証するために機密保護される必要があります。
The HI and HAck messages need to be secured using a preexisting security association between the access routers to ensure at least message integrity and authentication, and SHOULD also include encryption. IPsec ESP SHOULD be used.
HIとHAckメッセージは、少なくともメッセージの保全を確実にするアクセスルータの間の先在のセキュリティ協会を使用して、認証であると機密保護される必要があります、そして、また、SHOULDは暗号化を含んでいます。 IPsec ESP SHOULD、使用されてください。
8. IANA Considerations
8. IANA問題
The IANA assignments made for messages, extensions, and options specified in this document are described in the following paragraphs.
課題が本書では指定されたメッセージ、拡大、およびオプションのために作ったIANAは以下のパラグラフで説明されます。
This document defines two new messages that use the Mobile IPv4 control message format [rfc3344]. These message details are as follows:
このドキュメントはモバイルIPv4コントロールメッセージ・フォーマット[rfc3344]を使用する2つの新しいメッセージを定義します。 これらのメッセージの詳細は以下の通りです:
+------+-------------+-------------+
| Type | Description | Reference |
+------+-------------+-------------+
| 20 | FBU | Section 5.1 |
| 21 | FBAck | Section 5.2 |
+------+-------------+-------------+
+------+-------------+-------------+ | タイプ| 記述| 参照| +------+-------------+-------------+ | 20 | FBU| セクション5.1| | 21 | FBAck| セクション5.2| +------+-------------+-------------+
This document defines four new experimental ICMP messages that use the ICMP Type 41 for IPv4. See Section 3 in [rfc4065]. The new messages specified in this document have been assigned Subtypes from the registry in [rfc4065]:
このドキュメントはIPv4にICMP Type41を使用する4つの新しい実験ICMPメッセージを定義します。 [rfc4065]でセクション3を見てください。 Subtypesは[rfc4065]での登録から本書では指定された新しいメッセージに割り当てられました:
+---------+-------------+-------------+
| Subtype | Description | Reference |
+---------+-------------+-------------+
| 6 | RtSolPr | Section 5.3 |
| 7 | PrRtAdv | Section 5.4 |
| 8 | HI | Section 5.5 |
| 9 | HAck | Section 5.6 |
+---------+-------------+-------------+
+---------+-------------+-------------+ | Subtype| 記述| 参照| +---------+-------------+-------------+ | 6 | RtSolPr| セクション5.3| | 7 | PrRtAdv| セクション5.4| | 8 | こんにちは| セクション5.5| | 9 | ハッキング| セクション5.6| +---------+-------------+-------------+
This document defines three new options that have been assigned Types from the Mobile IP Extensions for ICMP Router Discovery messages [rfc3344]. These options are as follows:
このドキュメントはTypesがICMP Routerディスカバリーメッセージ[rfc3344]のためにモバイルIP Extensionsから割り当てられた3つの新しいオプションを定義します。 これらのオプションは以下の通りです:
Koodli & Perkins Experimental [Page 24] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[24ページ]のRFC4988
+------+------------------+-------------+
| Type | Description | Reference |
+------+------------------+-------------+
| 20 | LLA | Section 6.1 |
| 21 | New IPv4 Address | Section 6.2 |
| 22 | NAR Prefix Info | Section 6.3 |
+------+------------------+-------------+
+------+------------------+-------------+ | タイプ| 記述| 参照| +------+------------------+-------------+ | 20 | LLA| セクション6.1| | 21 | 新しいIPv4アドレス| セクション6.2| | 22 | NAR接頭語インフォメーション| セクション6.3| +------+------------------+-------------+
The MN-PAR Authentication Extension described in Sections 5.1 and 5.2 is a Generalized Mobile IP Authentication Extension defined in Section 5 of [rfc4721]. The MN-PAR Authentication has been assigned a Subtype from the registry specified in [rfc4721]. The Extension details are as follows:
セクション5.1と5.2で説明されたミネソタ-PAR Authentication Extensionは[rfc4721]のセクション5で定義されたGeneralizedのモバイルIP Authentication Extensionです。 Subtypeは[rfc4721]で指定された登録からミネソタ-PAR Authenticationに割り当てられました。 Extensionの詳細は以下の通りです:
+---------+-----------------------+--------------------------+
| Subtype | Description | Reference |
+---------+-----------------------+--------------------------+
| 4 | MN-PAR Auth Extension | Section 5.1 |
+---------+-----------------------+--------------------------+
+---------+-----------------------+--------------------------+ | Subtype| 記述| 参照| +---------+-----------------------+--------------------------+ | 4 | ミネソタ-平価Auth拡張子| セクション5.1| +---------+-----------------------+--------------------------+
9. Acknowledgments
9. 承認
Thanks to all those who expressed interest in having a Fast Handovers for Mobile IPv4 protocol along the lines of [rfc4068]. Thanks to Vijay Devarapalli, Kent Leung, and Domagoj Premec for their review and input. Kumar Viswanath and Uday Mohan implemented an early version of this protocol. Many thanks to Alex Petrescu for his thorough review that improved this document. Thanks to Pete McCann for the proofreading, and to Jari Arkko for the review, which have helped improve this document. Thanks to Francis Dupont and Hannes Tschofenig for the GEN-ART and TSV-DIR reviews.
おかげに、モバイルIPv4のためにFast Handoversを持っていることへの関心を示したすべてのものが[rfc4068]の系列に沿って議定書を作ります。 彼らのレビューと入力をビジェイDevarapalli、ケントのレオン、およびDomagoj Premecをありがとうございます。 クマーViswanathとウダイ・モハンはこのプロトコルの早めのバージョンを実装しました。 このドキュメントを改良した彼の徹底的なレビューのためにアレックス・ペトレスクをありがとうございます。 校正のためのピートマッキャンと、そして、レビューのためのヤリArkkoをありがとうございます。Arkkoはこのドキュメントを改良するのを助けました。 GEN-ARTとTSV-DIRレビューをフランシス・デュポンとハンネスTschofenigをありがとうございます。
Sending FBU from the new link (i.e., reactive mode) is similar to using the extension defined in [mip4-ro]; however, this document also addresses movement detection and router discovery latencies.
新しいリンク(すなわち、反応モード)からFBUを送るのは[mip4-ro]で定義された拡張子を使用するのと同様です。 しかしながら、また、このドキュメントは、動き検出とルータ発見が潜在であると扱います。
10. References
10. 参照
10.1. Normative References
10.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月。
[rfc1256] Deering, S., Ed., "ICMP Router Discovery Messages",
RFC 1256, September 1991.
[rfc1256] デアリング、S.、エド、「ICMPルータ発見メッセージ」、RFC1256、9月1991日
[rfc2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[rfc2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
Koodli & Perkins Experimental [Page 25] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[25ページ]のRFC4988
[rfc3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
3344, August 2002.
[rfc3344] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[rfc4065] Kempf, J., "Instructions for Seamoby and Experimental
Mobility Protocol IANA Allocations", RFC 4065, July
2005.
[rfc4065] ケンフ、J.、「Seamobyと実験的な移動性プロトコルIANA配分のための指示」、RFC4065、2005年7月。
[rfc4068] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC
4068, July 2005.
[rfc4068] Koodli、R.、エド、「速く、モバイルIPv6"、RFC4068、2005年7月に、引き渡します」。
[rfc4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile
IPv4 Challenge/Response Extensions (Revised)", RFC
4721, January 2007.
[rfc4721] パーキンス、C.、カルフーン、P.、およびJ.Bharatia、「モバイルIPv4挑戦/応答拡大(改訂される)」、RFC4721、2007年1月。
10.2. Informative References
10.2. 有益な参照
[fh-ccr] R. Koodli and C. E. Perkins, "Fast Handovers and
Context Transfers in Mobile Networks", ACM Computer
Communications Review Special Issue on Wireless
Extensions to the Internet, October 2001.
[fh-ccr]R.KoodliとC.E.パーキンス、「速い身柄の引き渡しと背景はモバイルネットワークで移します」、インターネットへのワイヤレスの拡大のACMコンピュータコミュニケーションレビュー増刊、2001年10月。
[ieee-802.11r] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Fast Roaming/Fast BSS Transition, IEEE Std
802.11r", September 2006.
[ieee-802.11r]IEEE、「地方とメトロポリタンエリアネットワークのIEEE規格:」 2006年9月の「速く、/速いBSS変遷、IEEE Std 802.11rに移動します。」
[ieee-802.1x] IEEE, "IEEE Standards for Local and Metropolitan Area
Networks: Port-based Network Access Control, IEEE Std
802.1X-2001", June 2001.
[ieee-802.1x]IEEE、「地方とメトロポリタンエリアネットワークのIEEE規格:」 2001年6月に「IEEE Std 802.1X-2001、ポートベースのネットワークアクセスは制御します」。
[ieee-802.21] The IEEE 802.21 group, http://www.ieee802.org/21.
[ieee-802.21] IEEE802.21グループ、 http://www.ieee802.org/21 。
[mi-book] R. Koodli and C. E. Perkins, "Mobile Internetworking
with IPv6: Concepts, Principles and Practices", John
Wiley & Sons, June 2007.
[ミ本] R.KoodliとC.E.パーキンス、「IPv6があるモバイルインターネットワーキング:」 「概念、原則、および習慣」、ジョンワイリーと息子、6月2007日
[mip4-ro] Perkins, C. and D. Johnson, "Route Optimization in
Mobile IP", Work in Progress, September 2001.
[mip4-ro] 「モバイルIPにおける経路最適化」というパーキンス、C.、およびD.ジョンソンは進歩、2001年9月に働いています。
[rfc2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[rfc2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[rfc3957] Perkins, C. and P. Calhoun, "Authentication,
Authorization, and Accounting (AAA) Registration Keys
for Mobile IPv4", RFC 3957, March 2005.
[rfc3957] パーキンスとC.とP.カルフーン、「モバイルIPv4"、RFC3957、2005年3月のための認証、承認、および会計(AAA)登録キー。」
Koodli & Perkins Experimental [Page 26] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[26ページ]のRFC4988
Authors' Addresses
作者のアドレス
Rajeev Koodli Nokia Siemens Networks 313 Fairchild Driive Mountain View, CA 94043 USA
Rajeev Koodliノキアジーメンスネットワーク313フェアチャイルド・Driiveカリフォルニア94043マウンテンビュー(米国)
EMail: rajeev.koodli@nokia.com
メール: rajeev.koodli@nokia.com
Charles Perkins Nokia Siemens Networks 313 Fairchild Driive Mountain View, CA 94043 USA
チャールズパーキンスノキアジーメンスネットワーク313フェアチャイルド・Driiveカリフォルニア94043マウンテンビュー(米国)
EMail: charles.perkins@nokia.com
メール: charles.perkins@nokia.com
Koodli & Perkins Experimental [Page 27] RFC 4988 MIP4 Fast Handovers October 2007
KoodliとMIP4が2007年10月に速く引き渡すパーキンスExperimental[27ページ]のRFC4988
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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 & Perkins Experimental [Page 28]
KoodliとパーキンスExperimentalです。[28ページ]
一覧
スポンサーリンク
