RFC4260 日本語訳
4260 Mobile IPv6 Fast Handovers for 802.11 Networks. P. McCann. November 2005. (Format: TXT=35276 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. McCann Request for Comments: 4260 Lucent Technologies Category: Informational November 2005
コメントを求めるワーキンググループP.マッキャン要求をネットワークでつないでください: 4260年のルーセントテクノロジーズカテゴリ: 情報の2005年11月
Mobile IPv6 Fast Handovers for 802.11 Networks
モバイルIPv6は802.11のために速くネットワークを引き渡します。
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications.
このドキュメントは仕様の802.11スイートに従いながらリンクレイヤでどうモバイルIPv6 Fast Handoverを実行できたかを説明します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Terminology .....................................................2
3. Deployment Architectures for Mobile IPv6 on 802.11 ..............3
4. 802.11 Handovers in Detail ......................................5
5. FMIPv6 Message Exchanges ........................................7
6. Beacon Scanning and NAR Discovery ...............................8
7. Scenarios .......................................................9
7.1. Scenario 1abcdef23456g .....................................9
7.2. Scenario ab123456cdefg ....................................10
7.3. Scenario 123456abcdefg ....................................10
8. Security Considerations ........................................10
9. Conclusions ....................................................12
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................13
11. Acknowledgements ..............................................13
1. 序論…2 1.1. このドキュメントで中古のコンベンション…2 2. 用語…2 3. 802.11のモバイルIPv6のための展開構造…3 4. 802.11 詳細に、引き渡します。5 5. FMIPv6交換処理…7 6. スキャンとNAR発見を照らしてください…8 7. シナリオ…9 7.1. シナリオ1abcdef23456g…9 7.2. シナリオab123456cdefg…10 7.3. シナリオ123456abcdefg…10 8. セキュリティ問題…10 9. 結論…12 10. 参照…13 10.1. 標準の参照…13 10.2. 有益な参照…13 11. 承認…13
McCann Informational [Page 1] RFC 4260 802.11 Fast Handover November 2005
[1ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
1. Introduction
1. 序論
The Mobile IPv6 Fast Handover protocol [2] has been proposed as a way to minimize the interruption in service experienced by a Mobile IPv6 node as it changes its point of attachment to the Internet. Without such a mechanism, a mobile node cannot send or receive packets from the time that it disconnects from one point of attachment in one subnet to the time it registers a new care-of address from the new point of attachment in a new subnet. Such an interruption would be unacceptable for real-time services such as Voice-over-IP.
モバイルIPv6 Fast Handoverプロトコル[2]は接着点をインターネットに変えるのでモバイルIPv6ノードによって経験されたサービスにおける中断を最小にする方法として提案されました。 可動のノードがそのようなメカニズムがなければ、パケットをある接着点からあるサブネットで連絡を断つ時間からそれが新しい状態でaを登録する時まで送ることができませんし、受けることができない、注意、-、新しいサブネットにおける新しい接着点からのアドレス。 Voice-over-IPなどの本当の時間指定サービスに、そのような中断は容認できないでしょう。
The basic idea behind a Mobile IPv6 fast handover is to leverage information from the link-layer technology to either predict or rapidly respond to a handover event. This allows IP connectivity to be restored at the new point of attachment sooner than would otherwise be possible. By tunneling data between the old and new access routers, it is possible to provide IP connectivity in advance of actual Mobile IP registration with the home agent or correspondent node. This allows real-time services to be reestablished without waiting for such Mobile IP registration to complete. Because Mobile IP registration involves time-consuming Internet round-trips, the Mobile IPv6 fast handover can provide for a smaller interruption in real-time services than an ordinary Mobile IP handover.
モバイルIPv6速い引き渡しの後ろの基本的な考え方は引き渡し出来事に予測するか、または急速に応じるリンクレイヤ技術からの情報に投機することです。 これで、IPの接続性はそうでなければ、可能であるだろうより早く、新しい接着点で回復します。 古くて新しいアクセスルータの間のトンネリングデータで、実際のモバイルIP登録の前に家のエージェントか通信員ノードにIPの接続性を提供するのは可能です。 これで、終了するそのようなモバイルIP登録を待たないで、リアルタイムのサービスは回復します。 モバイルIP登録が手間がかかったインターネット周遊旅行にかかわるので、モバイルIPv6速い引き渡しはリアルタイムのサービスにおける普通のモバイルIP引き渡しより小さい中断に備えることができます。
The particular link-layer information available, as well as the timing of its availability (before, during, or after a handover has occurred), differs according to the particular link-layer technology in use. This document gives a set of deployment examples for Mobile IPv6 Fast Handovers on 802.11 networks. We begin with a brief overview of relevant aspects of basic 802.11 [3]. We examine how and when handover information might become available to the IP layers that implement Fast Handover, both in the network infrastructure and on the mobile node. Finally, we trace the protocol steps for Mobile IPv6 Fast Handover in this environment.
引き渡しの前、または利用可能な特定のリンクレイヤ情報、および有用性のタイミング、(引き渡しか引き渡しの後、起こった、)、使用中の特定のリンクレイヤ技術によると、異なります。 このドキュメントは802.11のネットワークでモバイルIPv6 Fast Handoversのための1セットの展開の例を出します。 私たちは基本的な802.11[3]の関連局面の簡潔な概観で始めます。 私たちは、引き渡し情報がどのように、いつ利用可能になるかもしれないかをFast Handover(ネットワークインフラと、そして、可動のノードの上の両方)を実行するIP層に調べます。 最終的に、私たちはモバイルIPv6 Fast Handoverのためにこの環境でプロトコル階段をたどります。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
2. Terminology
2. 用語
This document borrows all of the terminology from Mobile IPv6 Fast Handovers [2], with the following additional terms from the 802.11 specification [3] (some definitions slightly modified for clarity):
このドキュメントはモバイルIPv6 Fast Handovers[2]から用語のすべてを借ります、802.11仕様[3](明快ためにわずかに変更されたいくつかの定義)からの次の追加用語で:
McCann Informational [Page 2] RFC 4260 802.11 Fast Handover November 2005
[2ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
Access Point (AP): Any entity that has station functionality and
provides access to the distribution services, via the
wireless medium (WM) for associated stations.
アクセスポイント(AP): 関連ステーションへの無線の媒体(WM)で、ステーションの機能性を持って、配布サービスへのアクセスを提供するどんな実体。
Association: The service used to establish access point/station
(AP/STA) mapping and enable STA access to the
Distribution System.
協会: サービスは、アクセスポイント/ステーション(AP/STA)マッピングを確立して、以前はよくDistribution SystemへのSTAアクセスを可能にしていました。
Basic Service Set (BSS): A set of stations controlled by a single
coordination function, where the coordination function
may be centralized (e.g., in a single AP) or
distributed (e.g., for an ad hoc network). The BSS
can be thought of as the coverage area of a single AP.
基本サービスはセットしました(BSS): 1セットのステーションはただ一つのコーディネート機能によって制御されました。そこでは、コーディネート機能は、集結されるか(例えば、独身のAPで)、または分配されるかもしれません(例えば、臨時のネットワークのために)。 独身のAPの適用範囲の地域としてBSSを考えることができます。
Distribution System (DS): A system used to interconnect a set of
basic service sets (BSSs) and integrated local area
networks (LANs) to create an extended service set
(ESS).
流通制度(DS): 1セットの基本サービスとインタコネクトするのに使用されるシステムは、(BSSs)と統合ローカル・エリア・ネットワーク(LAN)に拡張サービスセット(ESS)を創設するように設定します。
Extended Service Set (ESS): A set of one or more interconnected basic
service sets (BSSs) and integrated local area networks
(LANs) that appears as a single BSS to the logical
link control layer at any station associated with one
of those BSSs. The ESS can be thought of as the
coverage area provided by a collection of APs all
interconnected by the Distribution System. It may
consist of one or more IP subnets.
拡張サービスはセットしました(ESS): 論理的なリンク制御への独身のBSSがどんなステーションでも層にするとき現れる1セットの1つ以上のインタコネクトされた基本サービスセット(BSSs)と統合ローカル・エリア・ネットワーク(LAN)はそれらのBSSsの1つと交際しました。 Distribution SystemによってすべてインタコネクトされたAPsの収集で提供された適用範囲の地域としてESSを考えることができます。 それは1つ以上のIPサブネットから成るかもしれません。
Station (STA): Any device that contains an IEEE 802.11 conformant
medium access control (MAC) and physical layer (PHY)
interface to the wireless medium (WM).
駅(STA): IEEE802.11conformant媒体アクセス制御(MAC)を含むどんな装置と物理的な層(PHY)も無線の媒体(WM)に連結します。
3. Deployment Architectures for Mobile IPv6 on 802.11
3. 802.11のモバイルIPv6のための展開構造
In this section, we describe the two most likely relationships between Access Points (APs), Access Routers (ARs), and IP subnets that are possible in an 802.11 network deployment. In this document, our focus is mainly on the infrastructure mode [3] of 802.11. Usually, a given STA is associated with one and only one AP at any given instant; however, implementations are possible [4] where multiple associations per STA may be maintained as long as the APs are connected to disjoint DSs. An STA may be in communication with an AP only when radio propagation conditions permit. Note that, as with any layer-2 technology, handover from one layer-2 point of attachment (AP) to another does not necessarily mean a change of AR or subnet.
このセクションで、私たちは802.11ネットワーク展開で可能なAccess Points(APs)と、Access Routers(ARs)と、IPサブネットとの2つの最もありそうな関係について説明します。 本書では、私たちの焦点が主に802.11のインフラストラクチャモード[3]にあります。 通常、与えられたSTAはどんな与えられた瞬間にも唯一無二の1APに関連しています。 しかしながら、APsがDSsをばらばらにならせるように接続される限り、実現は複数の1STAあたりの協会が維持されるかもしれないところの可能な[4]です。 ラジオ伝播状態が可能にするときだけ、STAがAPとのコミュニケーションにあるかもしれません。 1層-2接着点(AP)から別の接着点までの引き渡しが必ずどんな層-2技術のようにもARかサブネットの変化を意味するというわけではないことに注意してください。
McCann Informational [Page 3] RFC 4260 802.11 Fast Handover November 2005
[3ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
AR AR
AR | AR AR | AR
\ | / \ | /
Subnet 1 Subnet 2
/ / | \ \ / / | \ \
/ / | \ \ / / | \ \
/ | | | \ / | | | \
AP1 AP2 AP3 AP4 AP5 AP6 AP7 AP8 AP9 AP10
アルゴンアルゴンアルゴン| アルゴンアルゴン| アルゴン、\| / \ | /サブネット1サブネット2//| \ \ / / | \ \ / / | \ \ / / | \ \ / | | | \ / | | | \AP1 AP2 AP3 AP4 AP5 AP6 AP7 AP8 AP9 AP10
Figure 1. An 802.11 deployment with relay APs.
図1。 リレーAPsとの802.11展開。
Figure 1 depicts a typical 802.11 deployment with two IP subnets, each with three Access Routers and five Access Points. Note that the APs in this figure are acting as link-layer relays, which means that they transport Ethernet-layer frames between the wireless medium and the subnet. Note that APs do not generally implement any particular spanning tree algorithm, yet are more sophisticated than simple bridges that would relay all traffic; only traffic addressed to STAs known to be associated on a given AP would be forwarded. Each subnet is on top of a single LAN or VLAN, and we assume in this example that APs 6-10 cannot reach the VLAN on which Subnet 1 is implemented. Note that a handover from AP1 to AP2 does not require a change of AR (here we assume the STA will be placed on the same VLAN during such a handoff) because all three ARs are link-layer reachable from an STA connected to any AP1-5. Therefore, such handoffs would not require IP-layer mobility management, although some IP-layer signaling may be required to determine that connectivity to the existing AR is still available. However, a handover from AP5 to AP6 would require a change of AR, because AP6 cannot reach the VLAN on which Subnet 1 is implemented and therefore the STA would be attaching to a different subnet. An IP-layer handover mechanism would need to be invoked in order to provide low-interruption handover between the two ARs.
図1は2つのIPサブネット、3Access Routers、およびそれぞれ5Access Pointsとの典型的な802.11展開について表現します。 この図のAPsがリンクレイヤリレーとして機能していて、どれが、イーサネット層を輸送することを意味するか無線の媒体とサブネットの間で縁どられることに注意してください。 APsが一般にどんな特定のスパニングツリーアルゴリズムも実行しませんが、すべての交通をリレーする簡単な橋より高性能であることに注意してください。 与えられたAPで関連しているのが知られているSTAsに記述された交通だけを進めるでしょう。 単一のLANかVLANの上に各サブネットがあります、そして、私たちはこの例でAPs6-10がSubnet1が実行されるVLANに達することができないと思います。 すべての3ARsがどんなAP1-5にも接続されたSTAから届いているリンクレイヤであるのでAP1からAP2までの引き渡しがAR(ここで、私たちは、STAがそのような移管の間同じVLANに置かれると思う)の変化を必要としないことに注意してください。 したがって、そのようなhandoffsはIP-層の移動性管理を必要としないでしょう、何らかのIP-層のシグナリングが既存のARへの接続性がまだ利用可能であることを決定するのに必要であるかもしれませんが。 しかしながら、AP5からAP6までの引き渡しはARの変化を必要とするでしょう、AP6がSubnet1が実行されて、したがって、STAが異なったサブネットに付いているVLANに達することができないので。 IP-層の引き渡しメカニズムは、低い中断引き渡しを2ARsの間に供給するために呼び出される必要があるでしょう。
Internet
/ | \
/ | \
/ | \
AR AR AR
AP1 AP2 AP3
インターネット/| \ / | \ / | \アルゴンアルゴンアルゴンAP1 AP2 AP3
Figure 2. An 802.11 deployment with integrated APs/ARs.
図2。 統合APs/ARsとの802.11展開。
Figure 2 depicts an alternative 802.11 deployment where each AP is integrated with exactly one AR on a disjoint VLAN. In this case, every change of AP would result in a necessary change of AR, which
統合された各APがちょうどaのあるARと共にVLANをばらばらにならせるところに図2は代替の802.11展開について表現します。 この場合APのあらゆる変化がARの必要な変化をもたらすだろう、どれ
McCann Informational [Page 4] RFC 4260 802.11 Fast Handover November 2005
[4ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
would require some IP-layer handover mechanism to provide for low- interruption handover between the ARs. Also, the AR shares a MAC- layer identifier with its attached AP.
ARsの間の低い中断引き渡しに備えるために何らかのIP-層の引き渡しメカニズムを必要とするでしょう。 また、ARはMAC層の識別子を付属APと共有します。
In the next section, we examine the steps involved in any 802.11 handover. Subsequent sections discuss how these steps could be integrated with an IP-layer handover mechanism in each of the above deployment scenarios.
次のセクションで、私たちはどんな802.11引き渡しにもかかわるステップを調べます。その後のセクションはどうそれぞれの上の展開シナリオのIP-層の引き渡しメカニズムとこれらのステップを統合できたかを論じます。
4. 802.11 Handovers in Detail
4. 802.11 詳細な身柄の引き渡し
An 802.11 handover takes place when an STA changes its association
from one AP to another ("re-association"). This process consists of
the following steps:
STAが協会を1APから別のもの(「再協会」)に変えると、802.11引き渡しは行われます。 この過程は以下のステップから成ります:
0. The STA realizes that a handoff is necessary due to degrading
radio transmission environment for the current AP.
0. STAは、移管が現在のAPのために無線環境を下げるので必要であるとわかります。
1. The STA performs a scan to see what APs are available. The
result of the scan is a list of APs together with physical layer
information, such as signal strength.
1. STAは、APsが何であるかを利用可能な状態で確認するためにスキャンを実行します。 スキャンの結果は信号強度などの物理的な層の情報に伴うAPsのリストです。
2. The STA chooses one of the APs and performs a join to
synchronize its physical and MAC-layer timing parameters with
the selected AP.
2. STAはAPsの1つを選んで、aを実行します。接合して、物理的でMAC層にしているタイミングパラメタを選択されたAPと同期させてください。
3. The STA requests authentication with the new AP. For an "Open
System", such authentication is a single round-trip message
exchange with null authentication.
3. STAは新しいAPとの認証を要求します。 「オープンシステム」に関しては、そのような認証はヌル認証があるただ一つの往復の交換処理です。
4. The STA requests association or re-association with the new AP.
A re-association request contains the MAC-layer address of the
old AP, while a plain association request does not.
4. STAは新しいAPと共に協会か再協会を要求します。 再協会要求は古いAPのMAC-層のアドレスを含んでいますが、明瞭な協会要求はそうしません。
5. If operating in accordance with 802.11i [6], the STA and AP
would execute 802.1X EAP-on-LAN procedures to authenticate the
association (step 3 would have executed in "Open System" mode).
5. 802.11i[6]によると、作動するなら、STAとAPは、協会を認証するためにLANの802.1X EAP手順を実行するでしょう(ステップ3は「オープンシステム」でモードを実行したでしょう)。
6. The new AP sends a Layer 2 Update frame on the local LAN segment
to update the learning tables of any connected Ethernet bridges.
6. 新しいAPは、どんな接続イーサネット橋の学習テーブルもアップデートするためにLayer2Updateフレームを地方のLANセグメントに送ります。
Although we preface step 1 with step 0 for illustration purposes, there is no standardized trigger for step 1. It may be performed as a result of decaying radio conditions on the current AP or at other times as determined by local implementation decisions. Some network interface cards (NICs) may do scanning in the background, interleaving scans between data packets. This decreases the time required to roam if the performance of the current AP proves
私たちはイラスト目的のためのステップ0でステップ1について前書きしますが、ステップ1のための標準化された引き金が全くありません。 現在のAPか他の時にローカルの実現決定で決定するようにラジオ状態を腐食することの結果、それは実行されるかもしれません。 データ・パケットの間のスキャンをはさみ込んで、いくつかのネットワーク・インターフェース・カード(NICs)がバックグラウンドでスキャンするかもしれません。 これはAPが立証する電流の性能であるなら移動するのに必要である時間を減少させます。
McCann Informational [Page 5] RFC 4260 802.11 Fast Handover November 2005
[5ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
unsatisfactory, but it imposes more of a burden on the AP, since typically the STA places it in power-save mode prior to the scan, then once the scan is complete, returns to the AP channel in order to pick up queued packets. This can result in buffer exhaustion on the AP and attendant packet loss.
不十分です、一層の負担をAPに課します、一度次に、STAがスキャンの前にパワーで節約しているモードにそれを通常置くので、スキャンは完全です、とAPへのリターンが列に並ばせられたパケットを拾うためにチャネルを開設します。 これはAPと付き添いのパケット損失のときにバッファ疲労困憊をもたらすことができます。
During step 2, the STA performs rate adjustment where it chooses the best available transmission rate. Rate adjustment can be quite time-consuming as well as unpredictable.
ステップ2の間、最も良い利用可能な通信速度を選ぶところでSTAは料金の調整を実行します。 料金の調整は、かなり手間がかかっていて予測できるはずがありません。
Note that in some existing 802.11 implementations, steps 1-4 are performed by firmware in rapid succession (note that even in these implementations step 3 is sometimes performed in a host driver, especially for newer implementations). This might make it impossible for the host to take any actions (including sending or receiving IP packets) before the handover is complete. In other 802.11 implementations, it is possible to invoke the scan (step 1) and join (step 2) operations independently. This would make it possible to, e.g., perform step 1 far in advance of the handover and perhaps in advance of any real-time traffic. This could substantially reduce the handover latency, as one study has concluded that the 802.11 beacon scanning function may take several hundred milliseconds to complete [8], during which time sending and receiving IP packets is not possible. However, scanning too far in advance may make the information out-of-date by the time of handover, which would cause the subsequent joint operation to fail if radio conditions have changed so much in the interim that the target AP is no longer reachable. So, a host may choose to do scanning based on, among other considerations, the age of the previously scanned information. In general, performing such subsequent scans is a policy issue that a given implementation of FMIPv6 over 802.11 must consider carefully.
既存の802.11の実現でありいくつかでは、ステップ1-4が矢つぎばやなファームウェアによって実行されることに注意してください(これらの実現ではさえ、ステップ3が特により新しい実現のためにホストドライバーで時々実行されることに注意してください)。 これで、引き渡しが完全になる前にホストがどんな行動(IPパケットを送るか、または受けるのを含んでいる)も取るのが不可能になるかもしれません。 他の802.11の実現では、独自にスキャン(ステップ1)を呼び出して、(ステップ2)操作に参加するのは可能です。 これで、可能になるでしょう、例えば、引き渡しのずっと前と恐らくどんなリアルタイムの交通の前にもステップ1を実行してください。 IPパケットを送って、受けるどの時間が可能でないか間、1つの研究が、802.11標識スキャン機能が[8]を完成するために数100ミリセカンドと同じくらい取るかもしれないと結論を下したのに従って、これは引き渡しレイテンシをかなり減少させるかもしれません。 しかしながら、あまりに遠くに早くスキャンするのに、情報は引き渡しまでに時代遅れになるかもしれません。(ラジオ状態がその間非常にたくさん変化しているので目標APがもう届かないなら、それは、その後の共同経営に失敗されるでしょう)。 それで、ホストは、他の問題の中で以前にスキャンされた情報の時代に基づくスキャンをするのを選ぶかもしれません。 一般に、そのようなその後のスキャンを実行するのは、FMIPv6より多くの802.11の与えられた実現が慎重に考えなければならない政策問題です。
Even if steps 1 and 2 are performed in rapid succession, there is no guarantee that an AP found during step 1 will be available during step 2 because radio conditions can change dramatically from moment to moment. The STA may then decide to associate with a completely different AP. Often, this decision is implemented in firmware and the attached host would have no control over which AP is chosen. However, tools such as the host AP driver [10] offer full control over when and to which AP the host needs to associate. Operation as an Independent BSS (IBSS) or "ad-hoc mode" [3] may also permit the necessary control, although in this latter case attachment to an infrastructure AP would be impossible. Implementers can make use of such tools to obtain the best combination of flexibility and performance.
ステップ1と2が矢つぎばやに実行されても、瞬間によってラジオ状態が劇的に変化できるのでステップ1の間に見つけられたAPがステップ2の間利用可能になるという保証が全くありません。 そして、STAは、完全に異なったAPと交際すると決めるかもしれません。 しばしば、この決定はファームウェアで実行されます、そして、付属ホストには、APが選ばれているコントロールが全くないでしょう。 しかしながら、ホストが、時の上と、そして、どのAPを関連づけるか必要なようにホストAPドライバー[10]などのツールは完全なコントロールを提供します。 また、無党派BSS(IBSS)か「アドホック・モード」[3]としての操作は必要なコントロールを可能にするかもしれません、APがインフラストラクチャへのこの後者のケース付属で不可能でしょうが。 Implementersは得る中で柔軟性と性能の組み合わせ最も良いそのようなツールを利用できます。
McCann Informational [Page 6] RFC 4260 802.11 Fast Handover November 2005
[6ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
The coverage area of a single AP is known as a Basic Service Set (BSS). An Extended Service Set (ESS) is formed from a collection of APs that all broadcast the same ESSID. Note that an STA would send a re-association (which includes both the old and new AP addresses) only if the ESSID of the old and new APs are the same.
独身のAPの適用範囲の地域はBasic Service Set(BSS)として知られています。 Extended Service Set(ESS)は同じESSIDを放送するAPsのすべて、収集から形成されます。 古くて新しいAPsのESSIDが同じである場合にだけSTAが再協会(両方の古くて新しいAPアドレスを含んでいる)を送ることに注意してください。
A change of BSS within an ESS may or may not require an IP-layer handover, depending on whether the APs can send packets to the same IP subnets. If an IP-layer handover is required, then FMIPv6 can decrease the overall latency of the handover. The main goal of this document is to describe the most reasonable scenarios for how the events of an 802.11 handover may interleave with the message exchanges in FMIPv6.
ESSの中のBSSの変化はIP-層の引き渡しを必要とするかもしれません、APsが同じIPサブネットにパケットを送ることができるかどうかによって。 IP-層の引き渡しが必要であるなら、FMIPv6は引き渡しの総合的な潜在を減少させることができます。中に交換処理がある状態で802.11引き渡しの出来事がどうFMIPv6をはさみ込むことができるように、このドキュメントの第一目的は最も妥当なシナリオについて説明することになっているか。
5. FMIPv6 Message Exchanges
5. FMIPv6交換処理
An FMIPv6 handover nominally consists of the following messages:
FMIPv6引き渡しは名目上は以下のメッセージから成ります:
a. The mobile node (MN) sends a Router Solicitation for Proxy
(RtSolPr) to find out about neighboring ARs.
a。 可動のノード(ミネソタ)は隣接しているARsを見つけるProxy(RtSolPr)のためにRouter Solicitationを送ります。
b. The MN receives a Proxy Router Advertisement (PrRtAdv)
containing one or more [AP-ID, AR-Info] tuples.
b。 1[AP-ID、AR-インフォメーション]tuplesを含んでいて、ミネソタはProxy Router Advertisement(PrRtAdv)を受けます。
c. The MN sends a Fast Binding Update (FBU) to the Previous Access
Router (PAR).
c。 ミネソタはFast Binding Update(FBU)をPrevious Access Router(PAR)に送ります。
d. The PAR sends a Handover Initiate (HI) message to the New Access
Router (NAR).
d。 PARはHandover Initiate(HI)メッセージをNew Access Router(NAR)に送ります。
e. The NAR sends a Handover Acknowledge (HAck) message to the PAR.
e。 NARはHandover Acknowledge(HAck)メッセージをPARに送ります。
f. The PAR sends a Fast Binding Acknowledgement (FBack) message to
the MS on the new link. The FBack is also optionally sent on
the previous link if the FBU was sent from there.
f。 PARはFast Binding Acknowledgement(FBack)メッセージを新しいリンクの上のMSに送ります。 また、そこからFBUを送ったなら、任意に前のリンクにFBackを送ります。
g. The MN sends Fast Neighbor Advertisement (FNA) to the NAR after
attaching to it.
g。 ミネソタはそれに付いた後に、Fast Neighbor Advertisement(FNA)をNARに送ります。
The MN may connect to the NAR prior to sending the FBU if the handover is unanticipated. In this case, the FNA (step g) would contain the FBU (listed as step c above) and then steps d, e, and f would take place from there.
引き渡しが思いがけないならFBUを送る前に、ミネソタはNARに接続するかもしれません。 この場合、FNA(ステップg)はFBU(ステップcが上であると記載する)を含むでしょう、そして、次に、ステップd、e、およびfはそこから行われるでしょう。
McCann Informational [Page 7] RFC 4260 802.11 Fast Handover November 2005
[7ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
6. Beacon Scanning and NAR Discovery
6. 標識スキャンとNAR発見
The RtSolPr message is used to request information about the router(s) connected to one or more APs. The APs are specified in the New Access Point Link-Layer Address option in the RtSolPr and associated IP-layer information is returned in the IP Address Option of the PrRtAdv [2]. In the case of an 802.11 link, the link-layer address is the BSSID of some AP.
RtSolPrメッセージは、ルータの情報が1APsに接続したよう要求するのに使用されます。 RtSolPrのNew Access Point Link-層のAddressオプションでAPsを指定します、そして、PrRtAdv[2]のIP Address Optionで関連IP-層の情報を返します。 802.11リンクの場合では、リンクレイヤアドレスはいくらかのAPのBSSIDです。
Beacon scanning (step 1 from Section 4) produces a list of available APs along with signal strength information for each. This list would supply the necessary addresses for the New Access Point Link-Layer Address option(s) in the RtSolPr messages. To obtain this list, the host needs to invoke the MLME-SCAN.request primitive (see Section 10.3.2.1 of the 802.11 specification [3]). The BSSIDs returned by this primitive are the link-layer addresses of the available APs.
標識スキャン(セクション4からのステップ1)はそれぞれのための信号強度情報に伴う利用可能なAPsのリストを作り出します。 このリストはRtSolPrメッセージにおけるNew Access Point Link-層のAddressオプションのための必要なアドレスを供給するでしょう。 セクション10.3を見てください。このリストを得るのに、ホストが、MLME-SCAN.request primitiveを呼び出す必要がある、(.2 .1の802.11仕様[3])。 これによって原始的に返されたBSSIDsは利用可能なAPsのリンクレイヤアドレスです。
Because beacon scanning takes on the order of a few hundred milliseconds to complete, and because it is generally not possible to send and receive IP packets during this time, the MN needs to schedule these events with care so that they do not disrupt ongoing real-time services. For example, the scan could be performed at the time the MN attaches to the network prior to any real-time traffic. However, if the interval between scanning and handover is too long, the neighbor list may be out of date. For example, the signal strengths of neighboring APs may have dramatically changed, and a handover directed to the apparently best AP from the old list may fail. If the handover is executed in firmware, the STA may even choose a new target AP that is entirely missing from the old list (after performing its own scan). Both cases would limit the ability of the MN to choose the correct NAR for the FBU in step c during an anticipated handover. Ongoing work in the IEEE 802.11k task group may address extensions that allow interleaving beacon scanning with data transmission/reception along with buffering at APs to minimize packet loss.
標識スキャンが完成する数100人のミリセカンドの注文を帯びて、この間にIPパケットを送って、受けるのが一般に可能でないので、ミネソタが、慎重にこれらの出来事の計画をする必要があるので、それらは進行中のリアルタイムのサービスを中断しません。 例えば、ミネソタがどんなリアルタイムの交通の前にもネットワークに付くとき、スキャンを実行できました。 しかしながら、スキャンと引き渡しの間隔が長過ぎるなら、隣人リストは時代遅れであるかもしれません。 例えば、隣接しているAPsの信号強度は劇的に変化したかもしれません、そして、古いリストから明らかに最も良いAPに向けられた引き渡しは失敗するかもしれません。 引き渡しがファームウェアで実行されるなら、STAは古いリスト(それ自身のスキャンを実行した後の)から完全に外れている新しい目標APを選びさえするかもしれません。 両方のケースはステップcにおけるFBUのために予期された引き渡しの間、ミネソタが正しいNARを選ぶ能力を制限するでしょう。IEEE 802.11k任務群における進行中の仕事はAPsでのバッファリングと共にデータ伝送/レセプションでスキャンされるインターリービング標識がパケット損失を最小にすることができる拡大を記述するかもしれません。
Note that, aside from physical layer parameters such as signal strength, it may be possible to obtain all necessary information about neighboring APs by using the wildcard form of the RtSolPr message. This would cause the current access router to return a list of neighboring APs and would not interrupt ongoing communication with the current AP. This request could be made at the time the MN first attaches to the access router and periodically thereafter. This would enable the MN to cache the necessary [AP-ID, AR-Info] tuples and might enable it to react more quickly when a handover becomes necessary due to a changing radio environment. However, because the information does not include up-to-date signal strength, it would not enable the MN to predict accurately the next AP prior to a handover.
RtSolPrメッセージのワイルドカードフォームを使用することによって隣接しているAPsに関するすべての必要事項を得るのが信号強度などの物理的な層のパラメタは別として可能であるかもしれないことに注意してください。 これは、現在のアクセスルータが隣接しているAPsのリストを返すことを引き起こして、現在のAPとの進行中のコミュニケーションを中断しないでしょう。 その後、ミネソタが最初にアクセスルータに付く時、定期的にこの要求をすることができました。 これは、ミネソタが必要な[AP-ID、AR-インフォメーション]tuplesをキャッシュするのを可能にして、引き渡しが変化しているラジオ環境のために必要になると、それが、より急速に反応するのを可能にするかもしれません。 しかしながら、情報が最新の信号強度を含んでいないので、それは、ミネソタが引き渡しの前に正確に次のAPを予測するのを可能にしないでしょう。
McCann Informational [Page 8] RFC 4260 802.11 Fast Handover November 2005
[8ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
Also, if the scale of the network is such that a given access router is attached to many APs, then it is possible that there may not be room to list all APs in the PrRtAdv.
また、与えられたアクセスルータがネットワークのスケールがそのようなものであるので多くのAPsに付けられるなら、すべてのAPsを記載する余地がPrRtAdvにないのも、可能です。
The time taken to scan for beacons is significant because it involves iteration through all 802.11 channels and listening on each one for active beacons. A more targeted approach would allow the STA to scan, e.g., only one or two channels of interest, which would provide for much shorter interruption of real-time traffic. However, such optimizations are currently outside the scope of 802.11 specifications.
すべての802.11個のチャンネルと聴取でアクティブな標識のためにそれぞれ上で繰り返しにかかわるので、標識のためにスキャンされるわざわざは重要です。 STAはさらに狙ったアプローチでスキャンできるでしょう、例えば、興味がある1か2個のチャンネルだけ、リアルタイムの交通のはるかに短い中断に備えるどれ。 しかしながら、802.11の仕様の範囲の外にそのような最適化が現在、あります。
7. Scenarios
7. シナリオ
In this section, we look at a few of the possible scenarios for using FMIPv6 in an 802.11 context. Each scenario is labeled by the sequence of events that take place, where the numbered events are from Section 4 and the lettered events are from Section 5. For example, "1abcde23456fg" represents step 1 from Section 4 followed by steps a-e from Section 5 followed by steps 2-6 from Section 4 followed by steps f and g from Section 5. This is the sequence where the MN performs a scan, then the MN executes the FMIPv6 messaging to obtain NAR information and send a binding update, then the PAR initiates HI/HAck exchange, then the 802.11 handover completes, and finally the HAck is received at the PAR and the MN sends an FNA.
このセクションでは、私たちは、802.11文脈でFMIPv6を使用するのを可能なシナリオのいくつかを見ます。 各シナリオは起こる出来事の系列によって分類されます。そこでは、番号付の出来事がセクション4から来ていて、文字入りの出来事はセクション5から来ています。 例えば、"1abcde23456fg"はセクション5からのステップfとgがあとに続いたセクション4からのステップ2-6があとに続いたセクション5からの1eのステップがあとに続いたセクション4からステップ1を代表します。 これはミネソタがスキャンを実行して、次に、ミネソタがNAR情報を得て、拘束力があるアップデートを送るためにFMIPv6メッセージングを実行する系列です、そして、次に、PARはHI/HAck交換、802.11引き渡しが完成するその時を開始します、そして、PARに最終的にHAckを受け取ります、そして、ミネソタはFNAを送ります。
Each scenario is followed by a brief description and discussion of the benefits and drawbacks.
簡単な説明と利益と欠点の議論は各シナリオのあとに続いています。
7.1. Scenario 1abcdef23456g
7.1. シナリオ1abcdef23456g
This scenario is the predictive mode of operation from the FMIPv6 specification. In this scenario, the host executes the scan sometime prior to the handover and is able to send the FBU prior to handover. Only the FNA is sent after the handover. This mode of operation requires that the scan and join operations (steps 1 and 2) can be performed separately and under host control, so that steps a-f can be inserted between 1 and 2. As mentioned previously, such control may be possible in some implementations [10] but not in others.
このシナリオはFMIPv6仕様からの予言の運転モードです。 そして、この運転モードがそれを必要とする、スキャン、それが別々にとホストコントロール1fで踏まれて、実行されて、1と2の間に挿入できるということであることができます。このシナリオでは、ホストは、引き渡しの前にいつか、スキャンを実行して、引き渡しの前にFBUを送ることができます。引き渡しの後にFNAだけを送ります。操作(ステップ1と2)に参加してください。 既述のとおり、そのようなコントロールは、いくつかの実現[10]で可能ですが、他のもので可能であるかもしれないというわけではありません。
Steps 1ab may be executed far in advance of the handover, which would remove them from the critical path. This would minimize the service interruption from beacon scanning and allow at least one RtSolPr/PrRtAdv exchange to complete so that the host has link-layer information about some NARs. Note that if steps ab were delayed until handover is imminent, there would be no guarantee that the RtSolPr/PrRtAdv exchange would complete especially in a radio environment where the connection to the old AP is deteriorating
ステップ1abは引き渡しの前に遠くに実行されるかもしれません。引き渡しはクリティカルパスからそれらを取り除くでしょう。 これは、標識スキャンから停電を最小にして、少なくとも1RtSolPr/PrRtAdvに終了する交換を許容するでしょう、したがって、ホストには、いくつかのNARsのリンクレイヤ情報があります。 引き渡しが差し迫るまで腹筋がステップであるなら遅れたというメモ、RtSolPr/PrRtAdv交換が特にラジオ環境で終了する保証が全く古いAPとの接続が悪化しているところにないでしょう。
McCann Informational [Page 9] RFC 4260 802.11 Fast Handover November 2005
[9ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
rapidly. However, if there were a long interval between the scan and the handover, then the FBU (step c) would be created with out-of-date information. There is no guarantee that the MN will actually attach to the desired new AP after it has sent the FBU to the oAR, because changing radio conditions may cause NAR to be suddenly unreachable. If this were the case, then the handover would need to devolve into one of the reactive cases given below.
急速に。 しかしながら、スキャンと引き渡しの間には、長い間隔があれば、FBU(ステップc)は古くさい情報で作成されるでしょうに。 FBUをoARに送った後にミネソタが実際に必要な新しいAPに付くという保証が全くありません、ラジオ状態を変えるのが、NARが突然手が届かないことを引き起こすかもしれないので。 これがそうであるなら、引き渡しは、以下に与えられた反応ケースの1つへ譲り渡す必要があるでしょうに。
7.2. Scenario ab123456cdefg
7.2. シナリオab123456cdefg
This is the reactive mode of operation from the FMIPv6 specification. This scenario does not require host intervention between steps 1 and 2.
これはFMIPv6仕様からの反応運転モードです。 このシナリオはステップ1と2の間のホスト介入を必要としません。
However, it does require that the MN obtain the link-layer address of NAR prior to handover, so that it has a link-layer destination address for outgoing packets (default router information). This would then be used for sending the FNA (with encapsulated FBU) when it reaches the new subnet.
しかしながら、ミネソタが引き渡しの前にNARのリンクレイヤアドレスを得るのが必要です、それには出発しているパケット(デフォルトルータ情報)のためのリンクレイヤ送付先アドレスがあるように。 そして、これは、それが新しいサブネットに達するとFNA(要約のFBUと)を送るのに使用されるでしょう。
7.3. Scenario 123456abcdefg
7.3. シナリオ123456abcdefg
In this scenario, the MN does not obtain any information about the NAR prior to executing the handover. It is completely reactive and consists of soliciting a router advertisement after handover and then sending an FNA with encapsulated FBU immediately.
このシナリオでは、引き渡しを実行する前に、ミネソタはNARの少しの情報も得ません。それは、完全に反応していて、引き渡しの後にルータ通知に請求して、次に、すぐにカプセル化されたFBUと共にFNAを送るのから成ります。
This scenario may be appropriate when it is difficult to learn the link-layer address of the NAR prior to handover. This may be the case, e.g., if the scan primitive is not available to the host and the wildcard PrRtAdv form returns too many results. It may be possible to skip the router advertisement/solicitation steps (ab) in some cases, if it is possible to learn the NAR's link-layer address through some other means. In the deployment illustrated in Figure 2, this would be exactly the new AP's MAC-layer address, which can be learned from the link-layer handover messages. However, in the case of Figure 1, this information must be learned through router discovery of some form. Also note that even in the case of Figure 2, the MN must somehow be made aware that it is in fact operating in a Figure 2 network and not a Figure 1 network.
引き渡しの前にNARのリンクレイヤアドレスを学ぶのが難しいときに、このシナリオは適切であるかもしれません。これはそうであるかもしれません、そして、ホストには、基関数は例えば、スキャンであるなら利用可能ではありません、そして、ワイルドカードPrRtAdvフォームはあまりに多くの結果を返します。 いくつかの場合、ルータ通知/懇願ステップ(腹筋)をサボるのは可能であるかもしれません、ある他の手段でNARのリンクレイヤアドレスを学ぶのが可能であるなら。 図2で例証された展開では、これはちょうど新しいAPのMAC-層のアドレスでしょう。(リンクレイヤ引き渡しメッセージからそのアドレスについて学習できます)。 しかしながら、図1の場合では、何らかの形式のルータ発見でこの情報について学習しなければなりません。 また、図2の場合ではさえ、ミネソタを事実上、それが図1ネットワークではなく、図2ネットワークで作動しているのを意識するようにどうにかしなければならないことに注意してください。
8. Security Considerations
8. セキュリティ問題
The security considerations applicable to FMIPv6 are described in the base FMIPv6 specification [2]. In particular, the PAR must be assured of the authenticity of the FBU before it begins to redirect user traffic. However, if the association with the new AP is not
FMIPv6に適切なセキュリティ問題はベースFMIPv6仕様[2]で説明されます。 ユーザトラフィックを向け直し始める前に特に、FBUの信憑性をPARを保証しなければなりません。 しかしながら、新しさとの協会であるなら、APはそうではありません。
McCann Informational [Page 10] RFC 4260 802.11 Fast Handover November 2005
[10ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
protected using mutual authentication, it may be possible for a rogue AP to fool the MN into sending an FBU to the PAR when it is not in its best interest to do so.
互いの認証を使用することで保護されて、凶暴なAPが、そうするのが、晴れ着を着て関心でないときに、ミネソタがFBUをPARに送るようにだますのは、可能であるかもしれません。
Note that step 6 from Section 4 installs layer-2 forwarding state that can redirect user traffic and cause disruption of service if it can be triggered by a malicious node.
セクション4からのステップ6が悪意があるノードでそれを引き起こすことができるならサービスのユーザトラフィックと原因分裂を向け直すことができる層-2推進州をインストールすることに注意してください。
Note that step 3 from Section 4 could potentially provide some security; however, due to the identified weaknesses in Wired Equivalent Privacy (WEP) shared key security [9] this should not be relied upon. Instead, the Robust Security Network [6] will require the STA to undergo 802.1X Port-Based Network Access Control [5] before proceeding to steps 5 or 6. 802.1X defines a way to encapsulate Extensible Authentication Protocol (EAP) on 802 networks (EAPOL, for "EAP over LANs"). With this method, the client and AP participate in an EAP exchange that itself can encapsulate any of the various EAP authentication methods. The EAPOL exchange can output a Master Session Key (MSK) and Extended Master Session Key (EMSK), which can then be used to derive transient keys, which in turn can be used to encrypt/authenticate subsequent traffic. It is possible to use 802.1X pre-authentication [6] between an STA and a target AP while the STA is associated with another AP; this would enable authentication to be done in advance of handover, which would allow faster resumption of service after roaming. However, because EAPOL frames carry only MAC-layer instead of IP-layer addresses, this is currently only specified to work within a single VLAN, where IP-layer handover mechanisms are not necessarily needed anyway. In the most interesting case for FMIPv6 (roaming across subnet boundaries), the 802.1X exchange would need to be performed after handover to the new AP. This would introduce additional handover delay while the 802.1X exchange takes place, which may also involve round-trips to RADIUS or Diameter servers. The EAP exchange could be avoided if a preexisting Pairwise Master Key (PMK) is found between the STA and the AP, which may be the case if the STA has previously visited that AP or one that shares a common back-end infrastructure.
セクション4からのステップ3が潜在的に何らかのセキュリティを提供するかもしれないことに注意してください。 しかしながら、WEP(WEP)の共有された主要なセキュリティにおける特定された弱点のため、[9] これを当てにするべきではありません。 代わりに、Robust Security Network[6]は、STAがステップ5か6に進む前にベースの802.1X Port Network Access Control[5]を受けるのを必要とするでしょう。 802.1 Xは802のネットワーク(「LANの上のEAP」のためのEAPOL)で拡張認証プロトコル(EAP)をカプセル化する方法を定義します。 このメソッドで、クライアントとAPは様々なEAP認証方法のいずれもカプセル化することができるEAP交換自体に参加します。 EAPOL交換はMaster Session Key(MSK)とExtended Master Session Key(EMSK)を出力できます。(次に、一時的なキーを引き出すのにExtended Master Session Keyを使用できます)。(順番に、その後のトラフィックを暗号化するか、または認証するのにキーを使用できます)。 STAは別のAPに関連していますが、STAと目標APの間で802.1Xプレ認証[6]を使用するのは可能です。 これは、引き渡しの前に認証するのを可能にするでしょう。引き渡しはローミングの後により速いサービスの再開を許すでしょう。 しかしながら、EAPOLフレームがIP-層のアドレスの代わりにMAC-層だけを運ぶので、これは現在、独身のVLANの中で働くために指定されるだけです。そこでは、IP-層の引き渡しメカニズムが必ずとにかく必要であるというわけではありません。 FMIPv6(サブネット境界の向こう側に移動する)に、最もおもしろい場合では、802.1X交換は、引き渡しの後に新しいAPに実行される必要があるでしょう。 802.1X交換(また、RADIUSかDiameterサーバに周遊旅行にかかわるかもしれない)が起こっている間、これは追加引き渡し遅れを導入するでしょう。 先在のPairwise Master Key(PMK)がSTAとAPの間で見つけられるなら、EAP交換は避けられるかもしれません。STAが以前に一般的なバックエンドインフラストラクチャを共有するそのAPかものを訪問したなら、APはケースであるかもしれません。
Perhaps faster cross-subnet authentication could be achieved with the use of pre-authentication using an IP-layer mechanism that could cross subnet boundaries. To our knowledge, this sort of work is not currently under way in the IEEE. The security considerations of these new approaches would need to be carefully studied.
恐らく、プレ認証の使用がサブネット境界に交差できたIP-層のメカニズムを使用している状態で、より速い交差しているサブネット認証を達成できました。 私たちが知っている限り、この種類の仕事は現在、IEEEで進行中ではありません。 これらの新しいアプローチのセキュリティ問題は、慎重に研究される必要があるでしょう。
McCann Informational [Page 11] RFC 4260 802.11 Fast Handover November 2005
[11ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
9. Conclusions
9. 結論
The Mobile IPv6 Fast Handover specification presents a protocol for shortening the period of service interruption during a change in link-layer point of attachment. This document attempts to show how this protocol may be applied in the context of 802.11 access networks.
モバイルIPv6 Fast Handover仕様は、リンクレイヤ接着点の変化の間、勤続期間中断を短くするためにプロトコルを提示します。 このドキュメントは、このプロトコルが802.11のアクセスネットワークの文脈でどう適用されるかもしれないかを示すのを試みます。
Implementation of FMIPv6 must be done in the context of a particular link-layer implementation, which must provide the triggers for the FMIPv6 message flows. For example, the host must be notified of such events as degradation of signal strength or attachment to a new AP.
FMIPv6メッセージが流れるので、特定のリンクレイヤ実装の文脈でFMIPv6の実装をしなければなりません。(それは、引き金を提供しなければなりません)。 例えば、信号強度の退行のようなイベントか新しいAPへの付属についてホストに通知しなければなりません。
The particular implementation of the 802.11 hardware and firmware may dictate how FMIPv6 is able to operate. For example, to execute a predictive handover, the scan request primitive must be available to the host and the firmware must execute join operations only under host control [10], not autonomously in response to its own handover criteria. Obtaining the desired PrRtAdv and sending an FBU immediately prior to handover requires that messages be exchanged over the wireless link during a period when connectivity is degrading. In some cases, the scenario given in Section 7.1 may not complete successfully or the FBU may redirect traffic to the wrong NAR. However, in these cases the handover may devolve to the scenario from Section 7.2 or the scenario from Section 7.3. Ultimately, falling back to basic Mobile IPv6 operation [7] and sending a Binding Update directly to the Home Agent can be used to recover from any failure of the FMIPv6 protocol.
802.11のハードウェアとファームウェアの特定の実装はFMIPv6がどう作動できるかを決めるかもしれません。 例えば、必須が実行する予言の引き渡し、ホストにとって、基関数が利用可能であるに違いないというスキャン要求、およびファームウェアを実行するには、それ自身の引き渡し評価基準に対応してホストコントロール[10]の下でだけ自主的でなく操作に参加してください。 必要なPrRtAdvを入手して、引き渡しのすぐ前にFBUを送るのは、メッセージが接続性が下がる期間ワイヤレスのリンクの上と交換されるのを必要とします。 いくつかの場合、7.1が首尾よく完成しないかもしれないセクションで与えられたシナリオかFBUが間違ったNARにトラフィックを向け直すかもしれません。 しかしながら、これらの場合では、引き渡しはセクション7.2かシナリオからセクション7.3からシナリオへ譲り渡されるかもしれません。 結局、FMIPv6プロトコルのどんな失敗からも回復するのに基本的なモバイルIPv6操作[7]へ後ろへ下がって、直接ホームのエージェントにBinding Updateを送るのを使用できます。
McCann Informational [Page 12] RFC 4260 802.11 Fast Handover November 2005
[12ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July
2005.
[2] Koodli(R.)は「速く、モバイルIPv6"、RFCのために、4068、2005年7月を引き渡します」。
[3] "Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications", ANSI/IEEE Std 802.11, 1999 Edition.
[3] 「ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様」、ANSI/IEEE Std802.11、1999版。
[4] Bahl, P., Bahl, P., and Chandra, R., "MultiNet: Enabling
Simultaneous Connections to Multiple Wireless Networks Using a
Single Radio", Microsoft Tech Report, MSR-TR-2003-46, June 2003.
[4]BahlとP.とBahl、P.とチャンドラ、R.、「MultiNet:」 「単一のラジオを使用することで複数のワイヤレス・ネットワークに同時接続を可能にします」、マイクロソフトの科学技術のレポート、MSR-TR-2003-46、2003年6月。
[5] "Port-Based Network Access Control", IEEE Std 802.1X-2004, July
2004.
[5] 「ポートベースのネットワークアクセスコントロール」、IEEE Std 802.1X-2004、2004年7月。
[6] "Medium Access Control (MAC) Security Enhancements", IEEE Std
802.11i-2004, July 2004.
[6] 「媒体アクセス制御(MAC)セキュリティ増進」、IEEE Std 802.11i-2004、2004年7月。
[7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[7] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
10.2. Informative References
10.2. 有益な参照
[8] Mitra, A., Shin, M., and Arbaugh, W., "An Empirical Analysis of
the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395,
University of Maryland Department of Computer Science, September
2002.
[8] ミトラとA.と向こうずね、M.とArbaugh、W.、「IEEE802.11MAC層の移管プロセスの実証的分析」Cs-TR-4395、メリーランド大学コンピュータサイエンス学部(2002年9月)。
[9] Borisov, N., Goldberg, I., and Wagner, D., "Intercepting Mobile
Communications: The Insecurity of 802.11", Proceedings of the
Seventh Annual International Conference on Mobile Computing and
Networking, July 2001, pp. 180-188.
[9] ボリーソフとN.とゴールドバーグ、I.とワグナー、D.、「移動通信を傍受します:」 「802.11のInsecurity」、モバイルComputingとNetworking、2001年7月、ページのSeventh Annualの国際コンファレンスのProceedings 180-188.
[10] Malinen, J., "Host AP driver for Intersil Prism2/2.5/3 and WPA
Supplicant", http://hostap.epitest.fi/, July 2004.
[10]Malinen、J.、「Intersil Prism2/2.5/3とWPA SupplicantのためのホストAPドライバー」、 http://hostap.epitest.fi/ 、2004年7月。
11. Acknowledgements
11. 承認
Thanks to Bob O'Hara for providing explanation and insight on the 802.11 standards. Thanks to James Kempf, Erik Anderlind, Rajeev Koodli, and Bernard Aboba for providing comments on earlier versions.
802.11の規格で説明と洞察をボブ・オハラに提供してくださってありがとうございます。 ジェームス・ケンフ、エリックAnderlind、Rajeev Koodli、およびバーナードAbobaに以前のバージョンのコメントを提供してくださってありがとうございます。
McCann Informational [Page 13] RFC 4260 802.11 Fast Handover November 2005
[13ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
Author's Address
作者のアドレス
Pete McCann Lucent Technologies Rm 9C-226R 1960 Lucent Lane Naperville, IL 60563
ナパービル、ピートマッキャンルーセントテクノロジーズRm9Cの226R1960の透明なLaneイリノイ 60563
Phone: +1 630 713 9359 Fax: +1 630 713 1921 EMail: mccap@lucent.com
以下に電話をしてください。 +1 630 713、9359Fax: +1 1921年の630 713メール: mccap@lucent.com
McCann Informational [Page 14] RFC 4260 802.11 Fast Handover November 2005
[14ページ]RFC4260 802.11の速い引き渡し2005年11月の情報のマッキャン
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
McCann Informational [Page 15]
マッキャンInformationalです。[15ページ]
一覧
スポンサーリンク
