Network Working Group P. McCann
Request for Comments: 4260 Lucent Technologies
Category: Informational November 2005
Mobile IPv6 Fast Handovers for 802.11 Networks
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).
著作権（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.
この文書では、モバイルIPv6高速ハンドオーバが仕様の802.11スイートに準拠したリンク層の上に実装する方法について説明します。
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
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高速ハンドオーバプロトコル[2]、インターネットへの接続点を変更するようにモバイルIPv6ノードが経験するサービスの中断を最小限にする方法として提案されています。そのような機構がないと、モバイルノードは、それが新しいサブネットで新しい接続点から新たな気付アドレスを登録する時、1つのサブネット内の1つの結合点から切断時刻からパケットを送信または受信することができません。このような中断は、このようなボイスオーバー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高速ハンドオーバの展開例のセットを提供します。私たちは、基本的な802.11の関連する側面の概要で始まる[3]。私たちは、いつ、どのようにハンドオーバー情報は、ネットワークインフラストラクチャに移動ノードの両方で、高速ハンドオーバを実現するIP層に利用可能になるかもしれません調べます。最後に、私たちは、この環境では、モバイルIPv6高速ハンドオーバのためのプロトコルステップをトレースします。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
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):
この文書では、802.11仕様から次の追加の用語と、[2]モバイルIPv6高速ハンドオーバの用語の全てを借り[3]（いくつかの定義を少し明確にするために修飾されました）。
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）のマッピングを確立し、流通システムへの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）：調整機能は、集中（例えば、単一のAP）、または（例えば、アドホックネットワークのために）分散させることができる単一の調整機能によって制御局のセット。 BSSは、単一のAPのカバレッジエリアと考えることができます。
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）：拡張サービスセット（ESS）を作成する基本サービスセット（のBSS）と統合されたローカルエリアネットワーク（LAN）のセットを相互接続するために使用されるシステム。
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の）と統合されたローカルエリアネットワーク（LAN）のセットこれらのBSSのうちの1つに関連するすべての駅で論理リンク制御層に単一BSSとして表示されます。 ESSは、ディストリビューションシステムによって相互接続されたAPのすべてのコレクションによって提供されるカバレッジエリアとして考えることができます。これは、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）：無線媒体（WM）にIEEE 802.11準拠の媒体アクセス制御（MAC）及び物理層（PHY）インターフェースを含む任意のデバイス。
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.
このセクションでは、アクセスポイント（AP）、アクセスルータ（ARS）、および802.11ネットワークの展開が可能であるIPサブネット間の二つの最も可能性の高い関係を記述する。この文書では、我々の焦点は、802.11のインフラストラクチャモード[3]に主にあります。任意の所与の瞬間に、通常、所与のSTAは1つに関連付けられる、唯一のAP。しかし、実装が可能である[4] STAごとに複数の関連付けがあればAPがのDSをばらばらに接続されているように維持され得ます。 STAは、無線伝搬状況が許す場合にのみ、APと通信することができます。なお、任意のレイヤ2技術と同様に、アタッチメントのレイヤ2ポイント（AP）から別へのハンドオーバは必ずしもARまたはサブネットの変化を意味するものではありません。
AR AR
AR | AR AR | AR
\ | / \ | /
Subnet 1 Subnet 2
/ / | \ \ / / | \ \
/ / | \ \ / / | \ \
/ | | | \ / | | | \
AP1 AP2 AP3 AP4 AP5 AP6 AP7 AP8 AP9 AP10
Figure 1. An 802.11 deployment with relay APs.
図1.リレーAPとの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サブネット、3つのアクセスルータと5つのアクセスポイントとのそれぞれに、典型的な802.11の展開を示しています。彼らは無線媒体とサブネット間のイーサネット層フレームを転送することを意味し、この図のAPはリンク層のリレーとして動作していることに注意してください。 APは、一般的に、特定のスパニングツリーアルゴリズムを実装し、まだすべてのトラフィックを中継します簡単な橋よりも洗練されていないことに注意してください。トラフィックのみが与えられたAPに関連することが知られているのSTA宛に転送されます。各サブネットは、単一のLANまたはVLANの上にあり、そして我々は、APS 6-10サブネット1が実装されているVLANに到達できないことを、この例では想定しています。 AP2へAP1からのハンドオーバは、3つのすべてのARがどのAP1-に接続STAから到達可能なリンク層であるため、（私たちはSTAは、そのようなハンドオフ中に同じVLANに配置されますと仮定し、ここで）ARの変更を必要としないことに注意してください5。いくつかのIP層シグナリングは、既存のARへの接続性を決定するために必要とされるかもしれないので、そのようなハンドオフは、IPレイヤモビリティ管理を必要としない、まだ使用可能です。 AP6は、サブネット1が実装され、したがって、STAが異なるサブネットに取り付けることになるたVLANに達することができないのでしかし、AP6にAP5からハンドオーバは、ARの変化を必要とするであろう。 IP層ハンドオーバメカニズムは、2つのAR間の低割り込みハンドオーバーを提供するために呼び出される必要があるだろう。
Internet
/ | \
/ | \
/ | \
AR AR AR
AP1 AP2 AP3
Figure 2. An 802.11 deployment with integrated APs/ARs.
図2.統合されたAP / ARを持つ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 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.
図2は、各APがばらばらVLAN上の正確に一つのARと一体化されている別の802.11の展開を示します。この場合には、APのすべての変更は、アクセスルータ間の低割り込みハンドオーバーを提供するために、いくつかのIP層ハンドオーバ機構を必要とするARの必要な変化をもたらすであろう。また、ARは、添付のAPとMACレイヤ識別子を共有します。
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レイヤのハンドオーバメカニズムと統合することができる方法について説明します。
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は、別の（「再会合」）、1つのAPからの関連付けを変更する場合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は、利用可能なAPを確認するためにスキャンを実行します。スキャンの結果は、信号強度などの物理層情報、とともにAPのリストです。
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.
前記STAは、APのいずれかを選択し、選択したAPとの物理的及びMACレイヤタイミングパラメータを同期させるように結合を実行します。
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).
802.11i規格に従って動作する、[6]、STAとAPは、アソシエーションを認証する802.1X EAP-オンLAN手順を実行することになる場合5.（ステップ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は、任意の接続されたイーサネットブリッジの学習テーブルを更新するために、ローカルLANセグメント上のレイヤ2更新フレームを送信します。
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 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.
我々は、例示目的のために、ステップ0とステップ1はじめたが、これは、ローカルな実装の決定によって決定されるように、現在のAPまたは他の時間に無線条件を減衰の結果として実行されてもよいステップ1のための標準化されたトリガが存在しません。一部のネットワークインタフェースカード（NIC）は、データパケット間のスキャンをインターリーブ、バックグラウンドで走査を行うことができます。これは、現在のAPのパフォーマンスが不十分で判明した場合にローミングするために必要な時間を減少させるが、それは通常、STAは、スキャン前に省電力モードにそれを配置するので、APに負担のより課し、その後、スキャンが完了すると、 、キューされたパケットを拾うために、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パケットの送受信が可能とされていない時に、[8] 802.11ビーコン・スキャン機能を完了するのに数百ミリ秒を取ることができると結論付けているので、これは実質的に、ハンドオーバ待ち時間を減らすことができます。しかし、事前にすぎスキャンは、無線状態がターゲットAPは、もはや到達可能であることを暫定的にあまり変化しなかった場合は、その後の共同作戦が失敗する原因と思われる、ハンドオーバーの時点でアウトの最新情報を行うことができます。だから、ホストは、他の考慮事項の中で、に基づいてスキャンを実行するために以前にスキャン情報の年齢を選んでもよいです。一般に、このような後続のスキャンを行うことが802.11以上FMIPv6との所与の実施は慎重に検討しなければならない政策課題です。
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ドライバなどのツール[10]とAPは、ホストがアソシエートする必要のあるのを完全に制御を提供します。この後者の場合にはインフラストラクチャAPへの結合は不可能であるが独立BSS（IBSS）または「アドホックモード」として動作[3]また、必要な制御を可能にすることができます。実装者は、柔軟性とパフォーマンスの最適な組み合わせを得るために、そのようなツールを利用することができます。
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のカバレッジエリアは、基本サービスセット（BSS）として知られています。拡張サービスセット（ESS）は、すべて同じESSIDをブロードキャストAPのコレクションから形成されています。 STAは、古いものと新しいAPのESSIDが同じである場合にのみ、（古いものと新しい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の変化またはAPが同一のIPサブネットにパケットを送信できるかどうかに応じて、IPレイヤのハンドオーバを必要としなくてもよいです。 IP層ハンドオーバが必要な場合は、FMIPv6とは、ハンドオーバーの全体的な待ち時間を減少させることができます。このドキュメントの主な目標は、802.11ハンドオーバーのイベントが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。モバイルノード（MN）は、近隣のARを知るためにプロキシ（RtSolPrを）のためのルーター要請を送信します。
b. The MN receives a Proxy Router Advertisement (PrRtAdv) containing one or more [AP-ID, AR-Info] tuples.
B。 MNは、一つ以上の[AP-ID、AR-INFO]タプルを含むプロキシルータ広告（代理ルータ広告）を受信します。
c. The MN sends a Fast Binding Update (FBU) to the Previous Access Router (PAR).
C。 MNは、前のアクセスルータ（PAR）への高速バインディングアップデート（FBU）を送信します。
d. The PAR sends a Handover Initiate (HI) message to the New Access Router (NAR).
D。 PARは、新しいアクセスルータ（NAR）へのハンドオーバ開始（HI）メッセージを送信します。
e. The NAR sends a Handover Acknowledge (HAck) message to the PAR.
電子。 NARが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は、新しいリンク上のMSへの高速バインディング確認（バック）メッセージを送信します。 FBUは、そこから送信された場合バックはまた、必要に応じて、前のリンク上で送信されます。
g. The MN sends Fast Neighbor Advertisement (FNA) to the NAR after attaching to it.
グラム。 MNは、それに取り付けた後NARへの高速近隣広告（FNA）を送信します。
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.
MNは、ハンドオーバが予期しないであればFBUを送信する前にNARに接続することができます。この場合、FNA（ステップg）は（上記ステップcと記載）FBUを含み、次いでD、Eステップ、fはそこから場所を取るであろう。
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をメッセージは、一台の以上のAPに接続されたルータ（複数可）に関する情報を要求するために使用されます。 APはRtSolPrをの新しいアクセスポイントリンク層アドレスオプションで指定され、関連するIPレイヤの情報は、代理ルータ広告[2]の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）それぞれに対する信号強度情報と共に利用可能なAPのリストを生成します。このリストは、RtSolPrをメッセージに新しいアクセスポイントのリンク層アドレスオプション（複数可）に必要なアドレスを提供します。このリストを取得するために、ホストはMLME-SCAN.requestプリミティブを起動する必要がある（802.11仕様のセクション10.3.2.1 [3]を参照）。このプリミティブによって返されるのBSSIDは、利用可能なAPのリンクレイヤアドレスです。
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.
ビーコンスキャンが完了するまでに数百ミリ秒のオーダーを取り、そしてそれはこの時間の間にIPパケットを送受信することは一般に不可能であるため、MNは、彼らが継続的に実を妨害しないように注意して、これらのイベントをスケジュールする必要があるためタイムサービスを提供しています。例えば、スキャン前の任意のリアルタイムトラフィックにMNは、ネットワークに接続するときに実行することができます。スキャニングとハンドオーバーの間の間隔が長すぎる場合には、隣接リストが古い可能性があります。例えば、近隣のAPの信号強度は劇的に変化している可能性があり、古いリストから明らかに最良のAPに向けハンドオーバが失敗することがあります。ハンドオーバがファームウェアで実行された場合、STAはさえ完全に（独自のスキャンを実行した後に）旧リストから欠落している新しいターゲットAPを選択することができます。どちらの場合には、予測されたハンドオーバ中、ステップcにおけるFBUの正しいNARを選択するMNの能力を制限します。 IEEE 802.11kタスクグループで進行中の作業は、パケット損失を最小限にするためのAPでバッファリングと共に、データ送信/受信にビーコンスキャンをインターリーブできるよう拡張に対処することができます。
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をメッセージのワイルドカード形式を使用して隣接APに関するすべての必要な情報を取得することが可能です。これは、現在のアクセスルータが近隣APのリストを返すために、原因となると現在のAPとの継続的な通信を中断しないでしょう。この要求は、MNが最初その後定期的にアクセスルータに接続すると、一度に行うことができます。これは、必要に応じて、[AP-ID、AR-情報]タプルをキャッシュするMNを可能にし、ハンドオーバが変化による無線環境に必要になったときに、より迅速に対応することを可能にするかもしれません。情報が最新の信号強度が含まれていないので、しかし、それはハンドオーバの前に正確に次のAPを予測するMNを有効にしないでしょう。
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.
ネットワークの規模が与えられたアクセスルータは、多くのAPに接続されているようなものである場合も、代理ルータ広告内のすべてのAPをリストする余地がない可能性があります。
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チャネルを通じて反復を含み、アクティブビーコンをそれぞれ1に聴くためのビーコンをスキャンするのにかかる時間は重要です。よりターゲットを絞ったアプローチは、例えば、STAは、スキャンするリアルタイムトラフィックのはるかに短い中断のために提供するの関心の1つまたは2つのチャンネルを、可能になります。しかし、このような最適化は、802.11規格の範囲外で、現在あります。
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節からAE工程が続く第4ステップ1を表します。これは、MNは、スキャンを行う配列である項5からFおよびGの手順に続いて第4のステップ2-6によって、その後MNは、バインディングアップデートをNAR情報を取得し、送信するために、次にPARが開始をFMIPv6とメッセージングを実行しますHI /ハック交換、その後、802.11ハンドオーバが完了し、最終的にはハックがPARで受信され、MNはFNAを送信します。
Each scenario is followed by a brief description and discussion of the benefits and drawbacks.
各シナリオには利点と欠点の簡単な説明と議論が続いています。
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と仕様から動作の予測モードです。このシナリオでは、ホストは、ハンドオーバーにいつか前にスキャンを実行し、ハンドオーバの前にFBUを送信することができます。のみFNAは、ハンドオーバ後に送信されます。この動作モードは、スキャンおよび操作（工程1及び2）前述したようにステップがAFこのような制御は、いくつかの実装形態では可能であってもよい、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 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.
ステップ1ABは、クリティカルパスからそれらを削除することになる、ハンドオーバーの前に遠くに実行することができます。これは、ビーコンスキャンからサービスの中断を最小限にし、ホストはいくつかのNARに関するリンク層情報を持っているように完了するために、少なくとも一つのRtSolPrを/代理ルータ広告交換を可能にします。ハンドオーバが差し迫っているまでの手順ABが遅れた場合、RtSolPrを/代理ルータ広告の交換は、古いAPへの接続が急速に悪化している無線環境で特に完成しまうという保証はないであろうことに注意してください。スキャンおよびハンドオーバの間に長い間隔があった場合は、その後、FBU（工程c）が期限切れの情報を使用して作成されるであろう。無線条件を変更するとNARが突然到達不能にさせる可能性があるため、それは、旧ARにFBUを送信した後にMNが実際に希望する新しいAPに接続するという保証はありません。これが事実であれば、その後のハンドオーバーは下記の反応例1に委譲する必要があります。
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.
しかし、それは発信パケット（デフォルトルータの情報）のためのリンク層宛先アドレスを持つように、MNは、ハンドオーバ前にNARのリンク層アドレスを取得することを必要としません。これは、それが新しいサブネットに到達した場合（カプセル化されたFBUで）FNAを送信するために使用されるであろう。
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.
このシナリオでは、MNは、ハンドオーバを実行する前に、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のリンク層アドレスを学習することは困難であるとき、このシナリオは適切かもしれません。プリミティブスキャンがホストに利用可能ではなく、ワイルドカード代理ルータ広告形態は、あまりにも多くの結果を返す場合、これは、例えば、場合であってもよいです。いくつかの他の手段を通じてNARのリンク層アドレスを学習することが可能であるならば、いくつかのケースでは、ルータ広告/勧誘ステップ（AB）をスキップすることも可能です。図2に示した配置では、これはリンク層ハンドオーバメッセージから学ぶことができ、新たなAPのMAC層アドレスは、正確になります。しかし、図1の場合には、この情報は、何らかの形のルータ検出を通じて学習する必要があります。またしても、図2の場合には、MNは何とかそれは、図2のネットワークで動作している事実はなく、図1のネットワークであることを認識させる必要があることに注意してください。
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 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.
FMIPv6とに適用可能なセキュリティ問題は、ベースFMIPv6との明細書に記載されている[2]。それはユーザトラフィックをリダイレクトするために開始する前に、特に、PARはFBUの信憑性を保証しなければなりません。新しいAPとの関連が相互認証を使用して保護されていない場合、それはそうするために最善の利益ではない場合、不正なAPがPARにFBUを送ることにMNをばかにするためにしかし、それは可能かもしれません。
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に注意してください。しかし、原因のWired Equivalentプライバシー（WEP）共有キーセキュリティで識別弱点に[9]これは、依拠すべきではありません。その代わりに、ロバストセキュリティネットワーク[6] 802.1Xポートベースのネットワークアクセス制御を受けるようにSTAを必要とする[5]ステップ5または6 802.1Xに進む前に、802のネットワークに拡張認証プロトコル（EAP）をカプセル化する方法を定義します（ "LAN上EAP" のEAPOL）。この方法では、クライアントとAPは、自身が様々なEAP認証方法のいずれかをカプセル化することができますEAP交換に参加しています。 EAPOL交換を出力することができるマスターセッションキー（MSK）、その後、順番に、後続のトラフィックを認証/暗号化するために使用することができ、過渡キーを導出するために使用することができるマスターセッションキー（EMSK）を、拡張。 STAが他のAPに関連付けられている間にSTAとターゲットAPの間で[6] 802.1X事前認証を使用することが可能です。これは、ローミング後にサービスのより高速な再開を可能にする認証ハンドオーバーの前にやるべきことを、可能にします。 EAPOLフレームのみがMAC層の代わりに、IP層アドレスを運ぶしかし、これは現在、IPレイヤのハンドオーバメカニズムは必ずしもとにかく必要とされない単一のVLAN内で動作するように指定されています。 FMIPv6と（サブネットの境界を越えてローミング）のための最も興味深いケースでは、802.1X交換は、新たなAPへのハンドオーバ後に実行する必要があります。 802.1X交換はまた、RADIUSまたはDIAMETERサーバへのラウンドトリップを含むことができる場所をとりながら、これは追加のハンドオーバ遅延を導入します。既存のペアワイズマスターキー（PMK）はSTAが以前APまたは共通のバックエンドインフラストラクチャを共有する1ことを訪問した場合場合があり得るSTAとAPの間に発見された場合、EAP交換は回避することができます。
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で現在進行中ではありません。これらの新しいアプローチのセキュリティの考慮事項を慎重に検討する必要があるだろう。
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高速ハンドオーバの仕様は、添付ファイルのリンク層ポイントの変更の際のサービス中断の期間を短縮するためのプロトコルを提示します。この文書は、このプロトコルは、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]プリミティブスキャン要求は、ホストに利用可能でなければならず、ファームウェアは、ホストの制御下で結合操作を実行しなければなりません。所望の代理ルータ広告を取得し、ハンドオーバ前に直ちにFBUを送信すると、メッセージは接続が劣化である期間中に、無線リンクを介して交換されることを必要とします。いくつかのケースでは、7.1節で与えられたシナリオが正常に完了しなかったり、FBUは間違っNARにトラフィックをリダイレクトすることがあります。しかしながら、これらの場合に、ハンドオーバは、セクション7.2または7.3からシナリオからシナリオに委譲してもよいです。最終的に、[7]バック基本的なモバイルIPv6動作に落下してホームエージェントに直接結合更新を送信することFMIPv6とプロトコルのいずれかの障害から回復するために使用することができます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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規格802.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 802.1X STD-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におけるモビリティサポート"、RFC 3775、2004年6月。
[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.、 "IEEE 802.11 MACレイヤハンドオフプロセスの実証分析"、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の不安」、モバイルコンピューティングとネットワーキングの第7回国際会議、2001年7月、頁の議事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.、http://hostap.epitest.fi/ 2004年7月 "インターシルPrism2 / 2.5 / 3およびWPAサプリカントのホストAPドライバ"。
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、ラジーブKoodli、およびバーナードAbobaに感謝します。
Author's Address
著者のアドレス
Pete McCann Lucent Technologies Rm 9C-226R 1960 Lucent Lane Naperville, IL 60563
ピートマッキャンルーセント・テクノロジーズRmの9C-226R 1960ルーセントレーンネーパーヴィル、IL 60563
Phone: +1 630 713 9359 Fax: +1 630 713 1921 EMail: mccap@lucent.com
電話：+1 630 713 9359ファックス：+1 630 713 1921 Eメール：mccap@lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。