[要約] RFC 4260は、802.11ネットワークにおけるMobile IPv6の高速ハンドオーバーに関する規格です。このRFCの目的は、モバイルデバイスが異なるアクセスポイント間でスムーズに切り替えるための手法を提供することです。
Network Working Group P. McCann
Request for Comments: 4260 Lucent Technologies
Category: Informational November 2005
Mobile IPv6 Fast Handovers for 802.11 Networks
802.11ネットワーク用のモバイルIPv6ファストハンドオーバー
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）The Internet Society（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高速ハンドオーバーをどのように実装できるかについて説明します。
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つの添付ファイルのポイントから、新しいサブネットの新しい添付ポイントから新しいアドレスを登録するまでに切断されるまでのパケットを送信または受信できません。このような中断は、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高速ハンドオーバーの一連の展開例が提供されます。基本的な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].
「必須」、「必須」、「必須」、「「しなければ」、「そうしない」、「そうではない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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): Access Point (AP): Any entity that has station functionality and provides access to the distribution services, via the wireless medium (WM) for associated stations.
このドキュメントは、802.11仕様[3]（明確にわずかに変更された定義）からの次の追加項を使用して、モバイルIPv6ファストハンドオーバー[2]からすべての用語を借用しています。アクセスポイント（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）：一連の基本サービスセット（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のいずれかに関連する任意のステーションで論理リンク制御レイヤーに単一のBSSとして表示される1つ以上の相互接続された基本サービスセット（BSSS）と統合ローカルエリアネットワーク（LAN）のセット。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).
Station（STA）：IEEE 802.11を含む任意のデバイスは、ワイヤレス媒体（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.
このセクションでは、802.11ネットワークの展開で可能なアクセスポイント（APS）、アクセスルーター（ARS）、およびIPサブネット間の2つの最も可能性の高い関係について説明します。このドキュメントでは、主に802.11のインフラストラクチャモード[3]に焦点を当てています。通常、特定のSTAは、任意の瞬間に1つのAPと1つのAPに関連付けられています。ただし、APが隔離DSSに接続されている限り、STAあたりの複数の関連付けが維持される可能性がある[4]。STAは、無線伝播条件が許可されている場合にのみ、APと通信している可能性があります。レイヤー2テクノロジーと同様に、1つのレイヤー2ポイント（AP）から別のレイヤー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.リレー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サブネットを備えた典型的な802.11の展開を示しています。それぞれが3つのアクセスルーターと5つのアクセスポイントを備えています。この図のAPSはリンク層リレーとして作用していることに注意してください。つまり、ワイヤレスメディアとサブネット間でイーサネット層フレームを輸送することを意味します。APは一般に特定のスパニングツリーアルゴリズムを実装していませんが、すべてのトラフィックを中継する単純なブリッジよりも洗練されていることに注意してください。特定のAPに関連することが知られているSTAに宛てられたトラフィックのみが転送されます。各サブネットは単一のLANまたはVLANの上にあり、この例では、APS 6-10がサブネット1が実装されているVLANに到達できないと想定しています。AP1からAP2へのハンドオーバーは、ARの変更を必要としないことに注意してください（ここでは、3つのARすべてがAP1-5に接続されたSTAから到達可能なリンク層に到達可能であるため、このようなハンドオフ中にSTAが同じVLANに配置されると想定しています）。したがって、そのようなハンドオフはIP層のモビリティ管理を必要としませんが、既存のARへの接続がまだ利用可能であると判断するために一部のIP層シグナル伝達が必要になる場合があります。ただし、AP6がSubnet 1が実装されているVLANに到達できないため、STAが別のサブネットに付着するため、AP5からAP6への引き渡しにはARの変更が必要です。2つのARの間で低壊死のハンドオーバーを提供するために、IP層のハンドオーバーメカニズムを呼び出す必要があります。
Internet
/ | \
/ | \
/ | \
AR AR AR
AP1 AP2 AP3
Figure 2. An 802.11 deployment with integrated APs/ARs.
図2.統合されたAPS/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上の1つのARと正確に1つのARと統合される代替802.11の展開を示しています。この場合、APを変更するたびにARの必要な変更が生じ、ARS間の低壊死率のハンドオーバーを提供するために、IP層のハンドオーバーメカニズムが必要になります。また、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:
802.11のハンドオーバーは、STAがあるAPから別のAPに関連性を変更するときに行われます（「再アソシエーション」）。このプロセスは、次の手順で構成されています。
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つを選択し、JOINを実行して、選択した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で認証を要求します。「オープンシステム」の場合、このような認証は、Null認証を使用した単一の往復メッセージ交換です。
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は802.1x eap-on-lan手順を実行して協会を認証します（ステップ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.
ステップ1を図0で序文を序文目的で序文目的で序文にしますが、ステップ1の標準化されたトリガーはありません。現在のAPの無線条件が減衰した結果、または地域の実装決定によって決定された他の時間の結果として実行される場合があります。一部のネットワークインターフェイスカード（NICS）は、バックグラウンドでスキャンを行い、データパケット間のスキャンをインターリーブする場合があります。これにより、現在の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を実行することが可能になります。ある研究では、802.11ビーコンスキャン機能が数百ミリ秒かかる可能性があると結論付けたため、これにより、ハンドオーバーレイテンシが大幅に減少する可能性があります[8]。その間、IPパケットの送信と受信は不可能です。ただし、事前にスキャンしすぎると、引き渡しの時までに情報が日付が出る可能性があります。これにより、ターゲット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]などのツールは、Hostが関連付ける必要がある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と新しいAPのESSIDが同じである場合にのみ、再アソシエーション（古いAPアドレスと新しい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の変更は、APSが同じ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）は、プロキシ（RTSOLPR）のルーター勧誘を送信して、隣接するARについて調べます。
b. The MN receives a Proxy Router Advertisement (PrRtAdv) containing one or more [AP-ID, AR-Info] tuples.
b. MNは、1つ以上の[AP-ID、AR-INFO]タプルを含むプロキシルーター広告（PRRTADV）を受け取ります。
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.
e. NARは、ハンドオーバー承認（ハック）メッセージをパーに送信します。
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に高速バインディング確認（FBACK）メッセージを送信します。FBUがそこから送信された場合、FBUが以前のリンクでオプションで送信されます。
g. The MN sends Fast Neighbor Advertisement (FNA) to the NAR after attaching to it.
g. MNは、それに取り付けた後、高速隣接広告（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.
MNは、ハンドオーバーが予期しない場合、FBUを送信する前にNARに接続する場合があります。この場合、FNA（ステップG）にはFBU（上記のステップCとしてリスト）が含まれ、次にステップ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メッセージは、1つ以上のAPSに接続されたルーターに関する情報を要求するために使用されます。APは、RTSOLPRの新しいアクセスポイントリンク層アドレスオプションで指定されており、関連するIP層情報はPRRTADVのIPアドレスオプションで返されます[2]。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 Primitiveを呼び出す必要があります（802.11仕様[3]のセクション10.3.2.1を参照）。このプリミティブによって返される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タスクグループでの継続的な作業は、パケットの損失を最小限に抑えるために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メッセージのワイルドカード形式を使用して、隣接するAPに関する必要なすべての情報を取得することが可能かもしれません。これにより、現在のアクセスルーターが隣接するAPのリストを返し、現在のAPとの継続的な通信を中断しません。このリクエストは、MNが最初にアクセスルーターに接続し、その後定期的に取り付けられた時点で行うことができます。これにより、MNは必要な[AP-ID、AR-INFO]タプルをキャッシュでき、無線環境の変化によりハンドオーバーが必要になったときに、より迅速に反応できるようになります。ただし、情報には最新の信号強度が含まれていないため、MNが引き渡す前に次のAPを正確に予測することはできません。
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に接続されるようなものである場合、PRRTADVのすべての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チャネルを介したイテレーションを伴い、それぞれがアクティブなビーコンのためにリスニングするため、重要です。よりターゲットを絞ったアプローチを使用すると、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」はセクション4からのステップ1を表します。バインディングアップデート、その後、PARはHi/Hack Exchangeを開始し、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）を個別に、ホスト制御下で実行できるため、ステップA-Fを1〜2の間に挿入できるようにする必要があります。
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に関するリンク層情報を持つように、少なくとも1つのRTSOLPR/PRRTADV交換が完了します。ハンドオーバーが差し迫っているまでステップABが遅延した場合、特に古いAPへの接続が急速に劣化している無線環境では、RTSOLPR/PRRTADV交換が完了するという保証はないことに注意してください。ただし、スキャンとハンドオーバーの間に長い間隔があった場合、FBU（ステップC）が時代遅れの情報で作成されます。MNがFBUをOARに送信した後、MNが実際に目的の新しいAPに付着するという保証はありません。無線条件を変えると、NARが突然到達できなくなる可能性があるためです。この場合、ハンドオーバーは以下に示す反応性のあるケースの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のリンク層アドレスを学習することが困難な場合に適切な場合があります。これは、スキャンプリミティブがホストが利用できない場合、WildCard PRRTADVフォームがあまりにも多くの結果を返す場合、そうかもしれません。NARのリンク層アドレスを他の手段で学習できる場合、場合によってはルーターの広告/勧誘手順（AB）をスキップすることが可能かもしれません。図2に示す展開では、これはまさに新しいAPのMac層アドレスであり、リンク層のハンドオーバーメッセージから学ぶことができます。ただし、図1の場合、この情報は、何らかの形のルーター発見を通じて学習する必要があります。また、図2の場合でも、MNは、実際には、図1ネットワークではなく図2ネットワークで動作していることを何らかの形で認識させる必要があることに注意してください。
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がユーザートラフィックをリダイレクトし始める前に、FBUの信頼性を保証する必要があります。ただし、新しいAPとの関連が相互認証を使用して保護されていない場合、不正なAPがMNを欺いて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）が共有された主要なセキュリティ[9]の特定された弱点により、これは依存してはなりません。代わりに、堅牢なセキュリティネットワーク[6]は、ステップ5または6に進む前に、STAが802.1xポートベースのネットワークアクセス制御[5]を受ける必要があります。802.1xは、802ネットワーク（EAPOL、「EAP Over Lans」の拡張可能な認証プロトコル（EAP）をカプセル化する方法を定義します。この方法により、クライアントとAPは、さまざまなEAP認証方法のいずれかをカプセル化できるEAP交換に参加します。Eapol Exchangeは、マスターセッションキー（MSK）と拡張マスターセッションキー（EMSK）を出力できます。これは、過渡キーを導出するために使用できます。これは、後続のトラフィックを暗号化/認証するために使用できます。STAとSTAは別のAPに関連付けられている間、STAとターゲットAPの間で802.1xの事前認証[6]を使用することができます。これにより、ハンドオーバーの前に認証を行うことができ、ローミング後のサービスのより速い再開が可能になります。ただし、EapolフレームはIP層アドレスの代わりにMac層のみを搭載しているため、これは現在、IP層のハンドオーバーメカニズムが必ずしも必要ではない単一のVLAN内で動作するようにのみ指定されています。FMIPv6の最も興味深いケース（サブネットの境界を越えてローミング）では、新しいAPへの引き渡し後に802.1xの交換を実行する必要があります。これにより、802.1xの交換が行われている間に追加のハンドオーバー遅延が導入されます。これには、半径または直径サーバーへの往復が含まれる場合があります。EAP交換は、STAとAPの間に既存のペアワイズマスターキー（PMK）が見つかった場合に回避できます。これは、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で進行中ではありません。これらの新しいアプローチのセキュリティ上の考慮事項は、慎重に研究する必要があります。
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]に基づいて参加操作を実行する必要があります。目的のPRRTADVを取得し、ハンドオーバーの直前にFBUを送信するには、接続性が低下している期間中にメッセージをワイヤレスリンクで交換する必要があります。場合によっては、セクション7.1に記載されているシナリオが正常に完了しないか、FBUが間違ったNARにトラフィックをリダイレクトする場合があります。ただし、これらの場合、ハンドオーバーはセクション7.2のシナリオまたはセクション7.3のシナリオに委ねられる場合があります。最終的に、基本的なモバイルIPv6操作[7]に戻り、ホームエージェントにバインディングアップデートを直接送信することは、FMIPV6プロトコルの障害から回復するために使用できます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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 STD 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。、およびChandra、R。、「マルチネット：単一の無線を使用した複数のワイヤレスネットワークへの同時接続を有効にする」、Microsoft Tech Report、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] 「Medium Access Control（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] Johnson、D.、Perkins、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] Mitra、A.、Shin、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] Borisov、N.、Goldberg、I。、およびWagner、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。、「Intersil Prism2/2.5/3およびWPAサプリカントのホストAPドライバー」、http://hostap.epitest.fi/、2004年7月。
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の基準について説明と洞察を提供してくれたBob O'haraに感謝します。ジェームズ・ケンプフ、エリック・アンダーリン、ラジーエフ・クッドリ、バーナード・アボバに感謝します。
Author's Address
著者の連絡先
Pete McCann Lucent Technologies Rm 9C-226R 1960 Lucent Lane Naperville, IL 60563
Pete McCann Lucent Technologies RM 9C-226R 1960 Lucent Lane Naperville、IL 60563
Phone: +1 630 713 9359
Fax: +1 630 713 1921
EMail: mccap@lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。