[要約] RFC 4831は、ネットワークベースのローカライズドモビリティ管理（NETLMM）の目標を定めたものです。NETLMMの目的は、モバイルノードの移動時にネットワークの変更を最小限に抑え、モバイルノードの通信を継続的にサポートすることです。
Network Working Group J. Kempf, Ed.
Request for Comments: 4831 DoCoMo USA Labs
Category: Informational April 2007
Goals for Network-Based Localized Mobility Management (NETLMM)
ネットワークベースのローカライズされたモビリティ管理（NetLMM）の目標
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 IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed.
このドキュメントでは、ネットワークベースのローカライズされたモビリティ管理（NetLMM）プロトコルの設計目標について説明します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. NETLMM Functional Architecture ..................................3
3. Goals for the NETLMM Protocol ...................................3
3.1. Goal 1: Handover Performance Improvement ...................4
3.2. Goal 2: Reduction in Handover-Related Signaling Volume .....5
3.3. Goal 3: Location Privacy ...................................6
3.4. Goal 4: Limit Overhead in the Network ......................7
3.5. Goal 5: Simplify Mobile Node Mobility Management
Security by Deriving from IP Network Access and/or IP
Movement Detection Security ................................7
3.6. Goal 6: Link Technology Agnostic ...........................8
3.7. Goal 7: Support for Unmodified Mobile Nodes ................8
3.8. Goal 8: Support for IPv4 and IPv6 ..........................9
3.9. Goal 9: Reuse of Existing Protocols Where Sensible ........10
3.10. Goal 10: Localized Mobility Management
Independent of Global Mobility Management ................10
3.11. Goal 11: Configurable Data Plane Forwarding
between Local Mobility Anchor and Mobile Access Gateway ..11
4. Security Considerations ........................................11
5. Acknowledgements ...............................................11
6. Normative References ...........................................12
7. Informative References .........................................12
8. Contributors ...................................................13
In [1], the basic problems that occur when a global mobility protocol is used for managing local mobility are described, and two currently used approaches to localized mobility management -- the host-based approach that is used by most IETF protocols, and the proprietary Wireless LAN (WLAN) switch approach used between WLAN switches in different subnets -- are examined. The conclusion from the problem statement document is that none of the approaches has a complete solution to the problem. While the WLAN switch approach is most convenient for network operators and users because it requires no software on the mobile node other than the standard drivers for WiFi, the proprietary nature limits interoperability, and the restriction to a single last-hop link type and wired backhaul link type restricts scalability. The IETF host-based protocols require host software stack changes that may not be compatible with all global mobility protocols. They also require specialized and complex security transactions with the network that may limit deployability. The conclusion is that a localized mobility management protocol that is network based and requires no software on the host for localized mobility management is desirable.
[1]では、ローカルモビリティの管理にグローバルモビリティプロトコルが使用されるときに発生する基本的な問題と、現在使用されている2つのローカライズされたモビリティ管理へのアプローチ - ほとんどのIETFプロトコルで使用されるホストベースのアプローチ、および異なるサブネットのWLANスイッチ間で使用される独自のワイヤレスLAN（WLAN）スイッチアプローチを調べます。問題の文書の結論は、どのアプローチにも問題に対する完全な解決策がないということです。WLANスイッチアプローチは、WIFIの標準ドライバー以外のモバイルノード上にソフトウェアを必要としないため、ネットワークオペレーターとユーザーにとって最も便利ですが、独自の性質は相互運用性を制限し、単一のラストホップリンクタイプと有線バックホールの制限を制限しますリンクタイプはスケーラビリティを制限します。IETFホストベースのプロトコルには、すべてのグローバルモビリティプロトコルと互換性がない可能性のあるホストソフトウェアスタックの変更が必要です。また、展開可能性を制限する可能性のあるネットワークを使用した専門的で複雑なセキュリティトランザクションが必要です。結論は、ネットワークベースであり、ローカライズされたモビリティ管理のためにホストにソフトウェアを必要としないローカライズされたモビリティ管理プロトコルが望ましいということです。
This document develops a brief functional architecture and detailed goals for a network-based localized mobility management protocol (NETLMM). Section 2 describes the functional architecture of NETLMM. In Section 3, a list of goals that is desirable in the NETLMM protocol is presented. Section 4 briefly outlines Security Considerations. More discussion of security can be found in the threat analysis document [2].
このドキュメントは、ネットワークベースのローカライズされたモビリティ管理プロトコル（NetLMM）の簡単な機能アーキテクチャと詳細な目標を開発します。セクション2では、NetLMMの機能アーキテクチャについて説明します。セクション3では、NetLMMプロトコルで望ましい目標のリストが提示されています。セクション4は、セキュリティに関する考慮事項を簡単に概説します。セキュリティの詳細については、脅威分析文書[2]に記載されています。
Mobility terminology in this document follows that in RFC 3753 [10] and in [1]. In addition, the following terms are related to the functional architecture described in Section 2:
このドキュメントのモビリティ用語は、RFC 3753 [10]および[1]でそれに続きます。さらに、次の用語は、セクション2で説明した機能アーキテクチャに関連しています。
Localized Mobility Management Domain
ローカライズされたモビリティ管理ドメイン
An Access Network in the sense defined in [1] in which mobility is handled by the NETLMM protocol.
[1]で定義された意味でのアクセスネットワークでは、NetLMMプロトコルによってモビリティが処理されます。
Mobile Access Gateway
モバイルアクセスゲートウェイ
A Mobile Access Gateway (MAG) is a functional network element that terminates a specific edge link and tracks mobile node IP-level mobility between edge links, through NETLMM signaling with the Localized Mobility Anchor. The MAG also terminates host routed data traffic from the Localized Mobility Anchor for mobile nodes currently located within the edge link under the MAG's control, and forwards data traffic from mobile nodes on the edge link under its control to the Localized Mobility Anchor.
モバイルアクセスゲートウェイ（MAG）は、特定のエッジリンクを終了し、ローカライズされたモビリティアンカーを使用したNetLMMシグナル伝達を介して、エッジリンク間のモバイルノードIPレベルのモビリティを追跡する機能的なネットワーク要素です。MAGはまた、MAGの制御下にあるエッジリンク内にあるモバイルノードのローカライズされたモビリティアンカーからのホストルーティングデータトラフィックを終了し、制御下のエッジリンク上のモバイルノードからローカライズされたモビリティアンカーにデータトラフィックを転送します。
Local Mobility Anchor
ローカルモビリティアンカー
A Local Mobility Anchor (LMA) is a router that maintains a collection of host routes and associated forwarding information for mobile nodes within a localized mobility management domain under its control. Together with the MAGs associated with it, the LMA uses the NETLMM protocol to manage IP node mobility within the localized mobility management domain. Routing of mobile node data traffic is anchored at the LMA as the mobile node moves around within the localized mobility management domain.
ローカルモビリティアンカー（LMA）は、ホストルートのコレクションと、その制御下にあるローカライズされたモビリティ管理ドメイン内のモバイルノードの関連する転送情報のコレクションを維持するルーターです。それに関連するMAGとともに、LMAはNetLMMプロトコルを使用して、ローカライズされたモビリティ管理ドメイン内のIPノードモビリティを管理します。モバイルノードのルーティングは、モバイルノードがローカライズされたモビリティ管理ドメイン内で移動するため、LMAに固定されています。
The NETLMM architecture consists of the following components. Localized Mobility Anchors (LMAs) within the backbone network maintain a collection of routes for individual mobile nodes within the localized mobility management domain. The routes point to the Mobile Access Gateways (MAGs) managing the links on which the mobile nodes currently are located. Packets for a mobile node are routed to and from the mobile node through tunnels between the LMA and MAG. When a mobile node moves from one link to another, the MAG sends a route update to the LMA. While some mobile node involvement is necessary and expected for generic mobility functions such as movement detection and to inform the MAG about mobile node movement, no specific mobile-node-to-network protocol will be required for localized mobility management itself. Host stack involvement in mobility management is thereby limited to generic mobility functions at the IP layer, and no specialized localized mobility management software is required.
NetLMMアーキテクチャは、次のコンポーネントで構成されています。バックボーンネットワーク内のローカライズされたモビリティアンカー（LMA）は、ローカライズされたモビリティ管理ドメイン内の個々のモバイルノードのルートのコレクションを維持します。ルートは、モバイルノードが現在配置されているリンクを管理するモバイルアクセスゲートウェイ（MAGS）を指します。モバイルノードのパケットは、LMAとMAGの間のトンネルを介してモバイルノードとの間でルーティングされます。モバイルノードがあるリンクから別のリンクに移動すると、MAGはLMAにルートアップデートを送信します。移動検出などの一般的なモビリティ関数には、モバイルノードの関与が必要であり、モバイルノードの動きについてMAGに通知するために期待されますが、ローカライズされたモビリティ管理自体には、特定のモバイルノードからネットワーク間プロトコルは必要ありません。これにより、モビリティ管理へのホストスタックの関与は、IPレイヤーでのジェネリックモビリティ関数に限定されており、特殊なローカライズされたモビリティ管理ソフトウェアは必要ありません。
Section 2 of [1] describes three problems with using a global mobility management protocol for localized mobility management. Any localized mobility management protocol must naturally address these three problems. In addition, the side effects of introducing such a solution into the network need to be limited. In this section, we address goals for NETLMM, including both solving the basic problems (Goals 1, 2, and 3) and limiting the side effects (Goals 4+).
[1]のセクション2では、ローカライズされたモビリティ管理にグローバルモビリティ管理プロトコルを使用することに関する3つの問題について説明します。ローカライズされたモビリティ管理プロトコルは、これらの3つの問題に自然に対処する必要があります。さらに、このようなソリューションをネットワークに導入する副作用は制限する必要があります。このセクションでは、NetLMMの目標に対処します。これには、基本的な問題（目標1、2、および3）の解決と副作用の制限（目標4）の制限が含まれます。
Some basic goals of all IETF protocols are not discussed in detail here, but any solution is expected to satisfy them. These goals are fault tolerance, robustness, interoperability, scalability, and minimal specialized network equipment. A good discussion of their applicability to IETF protocols can be found in [4].
すべてのIETFプロトコルのいくつかの基本的な目標については、ここでは詳しく説明していませんが、どのソリューションでもそれらを満たすことが期待されています。これらの目標は、フォールトトレランス、堅牢性、相互運用性、スケーラビリティ、および最小限の特殊ネットワーク機器です。IETFプロトコルへの適用性についての良い議論は、[4]にあります。
Out of scope for the initial goals discussion are Quality of Service (QoS) and dormant mode/paging. While these are important functions for mobile nodes, they are not part of the base localized mobility management problem. In addition, mobility between localized mobility management domains is not covered here. It is assumed that this is covered by the global mobility management protocols.
最初の目標の範囲外では、サービス品質（QOS）と休眠モード/ページングがあります。これらはモバイルノードの重要な機能ですが、ベースローカライズされたモビリティ管理の問題の一部ではありません。さらに、ローカライズされたモビリティ管理ドメイン間のモビリティはここではカバーされていません。これは、グローバルなモビリティ管理プロトコルでカバーされていると想定されています。
Handover packet loss occurs because there is usually latency between when the link handover starts and when the IP subnet configuration and global mobility management signaling completes. During this time, the mobile node is unreachable at its former topological location on the old link where correspondents are sending packets. Such misrouted packets are dropped. This aspect of handover performance optimization has been the subject of much work, both in other Standards Development Organizations (SDOs) and in the IETF, in order to reduce the latency in IP handover. Many solutions to this problem have been proposed at the link layer and at the IP layer. One aspect of this goal for localized mobility management is that the processing delay for changing the forwarding after handover must approach as closely as possible the sum of the delay associated with link-layer handover and the delay required for active IP-layer movement detection, in order to avoid excessive packet loss. Ideally, if network-side link-layer support is available for handling movement detection prior to link handover or as part of the link handover process, the routing update should complete within the time required for link handover. This delay is difficult to quantify, but for voice traffic, the entire handover delay, including Layer 2 handover time and IP handover time should be between 40-70 ms to avoid any degradation in call quality. Of course, if the link-layer handover latency is too high, sufficient IP-layer handover performance for good real-time service cannot be matched.
ハンドオーバーパケットの損失は、通常、リンクのハンドオーバーが開始されるときとIPサブネット構成とグローバルモビリティ管理シグナリングが完了する時期との間に遅延があるために発生します。この間、モバイルノードは、特派員がパケットを送信している古いリンクの以前のトポロジカル位置では到達できません。このような誤った誤ったパケットは削除されます。ハンドオーバーパフォーマンスの最適化のこの側面は、IPハンドオーバーの遅延を減らすために、他の標準開発組織（SDO）とIETFの両方で多くの作業の対象となっています。この問題に対する多くの解決策が、リンク層とIPレイヤーで提案されています。ローカライズされたモビリティ管理のこの目標の1つの側面は、ハンドオーバー後の転送を変更するための処理遅延が、リンク層のハンドオーバーに関連する遅延の合計と、アクティブなIP層運動検出に必要な遅延の合計にできるだけ密接に近づく必要があることです。過度のパケット損失を避けるため。理想的には、リンクのハンドオーバーまたはリンクハンドオーバープロセスの一部として、ネットワーク側のリンク層サポートが移動検出を処理するために使用できる場合、リンクハンドオーバーに必要な時間内にルーティングアップデートが完了するはずです。この遅延を定量化することは困難ですが、音声トラフィックの場合、レイヤー2ハンドオーバー時間とIPハンドオーバー時間を含むハンドオーバー遅延全体が、コール品質の分解を避けるために40〜70ミリ秒でなければなりません。もちろん、リンク層のハンドオーバーレイテンシが高すぎる場合、優れたリアルタイムサービスのための十分なIP層ハンドオーバーパフォーマンスを一致させることはできません。
A goal of the NETLMM protocol -- in networks where the link-layer handover latency allows it -- is to reduce the amount of latency in IP handover, so that the combined IP-layer and link-layer handover latency is less than 70 ms.
NetLMMプロトコルの目標 - リンク層のハンドオーバーレイテンシが許可するネットワークでは、IPハンドオーバーのレイテンシの量を減らすことで、IP層とリンク層のハンドオーバーレイテンシが70ミリ秒未満になるようになります。。
Considering Mobile IPv6 [9] as the global mobility protocol (other mobility protocols require about the same or somewhat less), if a mobile node using address autoconfiguration is required to reconfigure on every move between links, the following signaling must be performed:
モバイルIPv6 [9]をグローバルモビリティプロトコル（他のモビリティプロトコルではほぼ同じまたはやや少ないものを必要とする）を考慮してください。アドレスを使用したモバイルノードがリンク間のあらゆる動きで再構成する必要がある場合、次のシグナルを実行する必要があります。
1) Link-layer signaling required for handover and reauthentication. For example, in 802.11 [7], this is the Reassociate message together with 802.1x [8] reauthentication using EAP.
1) ハンドオーバーと再認証に必要なリンク層シグナル伝達。たとえば、802.11 [7]では、これはEAPを使用した802.1x [8]の再認証とともに再ソシエートメッセージです。
2) Active IP-level movement detection, including router reachability. The Detecting Network Attachment (DNA) protocol [5] uses Router Solicitation/Router Advertisement for this purpose. In addition, if SEcure Neighbor Discovery (SEND) [3] is used and the mobile node does not have a certificate cached for the router, the mobile node must use Certification Path Solicitation/Certification Path Advertisement to obtain a certification path.
2) ルーターの到達可能性を含むアクティブなIPレベルの移動検出。検出ネットワークアタッチメント（DNA）プロトコル[5]は、この目的のためにルーターの勧誘/ルーター広告を使用します。さらに、Secure Neighbor Discovery（SEND）[3]が使用され、モバイルノードにルーターのキャッシュされた証明書がない場合、モバイルノードは認定パス勧誘/認定パス広告を使用して認定パスを取得する必要があります。
3) Two Multicast Listener Discovery (MLD) [14] REPORT messages, one for each of the solicited node multicast addresses corresponding to the link local address and the global address.
3) 2つのマルチキャストリスナーディスカバリー（MLD）[14]レポートメッセージ。1つは、リンクローカルアドレスとグローバルアドレスに対応する要請されたノードマルチキャストアドレスに1つ。
4) Two Neighbor Solicitation (NS) messages for duplicate address detection, one for the link local address and one for the global address. If the addresses are unique, no response will be forthcoming.
4) 2つの近隣勧誘（NS）メッセージを重複するアドレス検出用のメッセージ、1つはローカルアドレス用、もう1つはグローバルアドレス用です。アドレスが一意の場合、応答はありません。
5) Two NS messages from the router for address resolution of the link local and global addresses, and two Neighbor Advertisement messages in response from the mobile node.
5) リンクローカルおよびグローバルアドレスのアドレス解像度のためのルーターからの2つのNSメッセージと、モバイルノードからの応答した2つの近隣広告メッセージ。
6) Binding Update/Binding Acknowledgement between the mobile node and home agent to update the care of address binding.
6) モバイルノードとホームエージェントの間のバインディングアップデート/バインディングの確認は、アドレスバインディングのケアを更新します。
7) Return routability signaling between the correspondent node and mobile node to establish the binding key, consisting of one Home Test Init/Home Test and Care of Test Init/Care of Test.
7) 通信能力ノードとモバイルノードの間のルーティング可能性シグナル伝達を返して、1つのホームテストINIT/ホームテストとテストINIT/ケアのケアで構成されるバインディングキーを確立します。
8) Binding Update/Binding Acknowledgement between the correspondent node and mobile node for route optimization.
8) ルート最適化のための特派員ノードとモバイルノードの間のバインディングアップデート/バインディングの確認。
Note that Steps 1-2 may be necessary, even for intra-link mobility, if the last-hop link protocol doesn't provide much help for IP handover. Steps 3-5 will be different if stateful address configuration is used, since additional messages are required to obtain the address. Steps 6-8 are only necessary when Mobile IPv6 is used. The result is approximately 18 messages at the IP level, where the exact number depends on various specific factors, such as whether or not the mobile node has a router certificate cached before a mobile node can be ensured that it is established on a link and has full IP connectivity. In addition to handover related signaling, if the mobile node performs Mobile IPv6 route optimization, it may be required to renew its return routability key periodically (on the order of every 7 minutes), even if it is not moving, resulting in additional signaling.
ラストホップリンクプロトコルがIPハンドオーバーにあまり役に立たない場合、リンク内のモビリティであっても、ステップ1-2が必要になる場合があることに注意してください。ステップ3-5は、アドレスを取得するために追加のメッセージが必要であるため、Statefulアドレス構成が使用される場合、異なります。手順6-8は、モバイルIPv6を使用する場合にのみ必要です。結果は、IPレベルで約18のメッセージが生成されます。正確な数値は、モバイルノードにモバイルノードがリンク上で確立されていることを保証する前に、モバイルノードにルーター証明書がキャッシュされているかどうかなど、さまざまな特定の要因に依存します。完全なIP接続。ハンドオーバー関連のシグナリングに加えて、モバイルノードがモバイルIPv6ルートの最適化を実行する場合、移動していなくても（7分ごとに）定期的に（順序で）リターンルーティング可能性キーを更新する必要がある場合があります。
The signaling required has a large impact on the performance of handover, impacting Goal 1. Perhaps more importantly, the aggregate impact from many mobile nodes of such signaling on expensive shared links (such as wireless where the capacity of the link cannot easily be expanded) can result in reduced last-hop link capacity for data traffic. Additionally, in links where the end user is charged for IP traffic, IP signaling is not without cost.
必要なシグナル伝達は、ハンドオーバーのパフォーマンスに大きな影響を与え、目標1に影響を与えます。おそらく、さらに重要なことは、高価な共有リンク（リンクの容量を簡単に拡張できないワイヤレスなど）に対するこのようなシグナリングの多くのモバイルノードからの集約的な影響データトラフィックの最終ホップリンク容量が低下する可能性があります。さらに、エンドユーザーがIPトラフィックに対して請求されるリンクでは、IPシグナルはコストがないわけではありません。
To address the issue of signaling impact described above, the goal is that handover signaling volume from the mobile node to the network should be no more than what is needed for the mobile node to perform secure IP-level movement detection, in cases where no link-layer support exists. Furthermore, NETLMM should not introduce any additional signaling during handover beyond what is required for IP-level movement detection. If link-layer support exists for IP-level movement detection, the mobile node may not need to perform any additional IP-level signaling after link-layer handover.
上記のシグナル伝達の影響の問題に対処するために、目標は、モバイルノードからネットワークへのハンドオーバーシグナリングボリュームは、リンクがない場合に安全なIPレベルの移動検出を実行するためにモバイルノードが必要なものにすぎないことです。 - レイヤーサポートが存在します。さらに、NetLMMは、IPレベルの移動検出に必要なものを超えて、引き渡し中に追加のシグナル伝達を導入するべきではありません。IPレベルの移動検出にリンク層サポートが存在する場合、モバイルノードは、リンク層のハンドオーバー後に追加のIPレベルの信号を実行する必要がない場合があります。
In any IP network, there is a threat that an attacker can determine the physical location of a network node from the node's topological location. Depending on how an operator deploys their network, an operator may choose to assign subnet coverage in a way that is tightly bound to geography at some timescale, or it may choose to assign it in ways in which the threat of someone finding a node physically based on its IP address is smaller. Allowing the L2 attachment and L3 address to be less tightly bound is one tool for reducing this threat to location privacy.
任意のIPネットワークでは、攻撃者がノードのトポロジカル位置からネットワークノードの物理的位置を決定できるという脅威があります。オペレーターがネットワークを展開する方法に応じて、オペレーターは、あるタイムスケールで地理にしっかりと縛られている方法でサブネットカバレッジを割り当てることを選択できます。または、誰かが物理的に基づいているノードを見つける脅威の方法で割り当てることを選択できます。IPアドレスは小さくなっています。L2の添付ファイルとL3アドレスを密着させないようにすることは、この脅威を場所のプライバシーに減らすための1つのツールです。
Mobility introduces an additional threat. An attacker can track a mobile node's geographical location in real-time, if the victim mobile node must change its IP address as it moves from one subnet to another through the covered geographical area. If the granularity of the mapping between the IP subnets and geographical area is small for the particular link type in use, the attacker can potentially assemble enough information to find the victim in real time.
モビリティは追加の脅威を導入します。攻撃者は、被害者のモバイルノードがIPアドレスがカバーされた地理的領域を介して別のサブネットに移動するときにIPアドレスを変更する必要がある場合、モバイルノードの地理的位置をリアルタイムで追跡できます。IPサブネットと地理的領域の間のマッピングの粒度が使用されている特定のリンクタイプでは小さい場合、攻撃者は、被害者をリアルタイムで見つけるのに十分な情報を組み立てる可能性があります。
In order to reduce the risk from location privacy compromises as a result of IP address changes, the goal for NETLMM is to remove the need to change IP address as a mobile node moves across links in an access network. Keeping the IP address fixed over a large geographical region fuzzes out the resolution of the mapping between the IP subnets and geographical area, regardless of how small the natural deployment granularity may be. This reduces the chance that the attacker can deduce the precise geographic location of the mobile node.
IPアドレスの変更の結果としてのロケーションプライバシーの妥協からのリスクを減らすために、NetLMMの目標は、アクセスネットワーク内のリンク全体でモバイルノードが移動するときにIPアドレスを変更する必要性を削除することです。IPアドレスを大規模な地理的領域に固定することは、自然な展開の粒度がどれほど小さいかに関係なく、IPサブネットと地理的領域の間のマッピングの解像度を曖昧にします。これにより、攻撃者がモバイルノードの正確な地理的位置を推定できる可能性が低くなります。
Access networks, including both the wired and wireless parts, tend to have somewhat stronger bandwidth and router processing constraints than the backbone. In the wired part of the network, these constraints are a function of the cost of laying fiber or wiring to the wireless access points in a widely dispersed geographic area. In the wireless part of the network, these constraints are due to the limitation on the number of bits per Hertz imposed by the physical layer protocol. Therefore, any solutions for localized mobility management should minimize overhead within the access network.
有線部品とワイヤレス部品の両方を含むアクセスネットワークは、バックボーンよりも帯域幅とルーター処理の制約がやや強い傾向があります。ネットワークの有線部分では、これらの制約は、広く分散した地理的領域のワイヤレスアクセスポイントへのファイバーまたは配線の配線のコストの関数です。ネットワークのワイヤレス部分では、これらの制約は、物理層プロトコルによって課されるHERTZあたりのビット数の制限によるものです。したがって、ローカライズされたモビリティ管理のソリューションは、アクセスネットワーク内のオーバーヘッドを最小限に抑える必要があります。
3.5. Goal 5: Simplify Mobile Node Mobility Management Security by Deriving from IP Network Access and/or IP Movement Detection Security
3.5. 目標5：IPネットワークアクセスおよび/またはIP移動検出セキュリティから派生して、モバイルノードモビリティ管理セキュリティを簡素化する
Localized mobility management protocols that have host involvement may require an additional security association between the mobile node and the mobility anchor, and establishing this security association may require additional signaling between the mobile node and the mobility anchor (see [13] for an example). The additional security association requires extra signaling and therefore extra time to negotiate. Reducing the complexity of mobile-node-to-network security for localized mobility management can therefore reduce barriers to deployment and improve responsiveness. Naturally, such simplification must not come at the expense of maintaining strong security guarantees for both the network and mobile node.
ホストが関与するローカライズされたモビリティ管理プロトコルには、モバイルノードとモビリティアンカーの間に追加のセキュリティ関連が必要になる場合があり、このセキュリティ関連を確立するには、モバイルノードとモビリティアンカーの間の追加のシグナル伝達が必要になる場合があります（例については[13]を参照）。追加のセキュリティ協会には、追加のシグナリングが必要であり、したがって、交渉するための余分な時間が必要です。したがって、ローカライズされたモビリティ管理のためのモバイルノードからネットワークへのセキュリティの複雑さを削減すると、展開の障壁を減らし、応答性を向上させることができます。当然のことながら、このような単純化は、ネットワークノードとモバイルノードの両方の強力なセキュリティ保証を維持することを犠牲にして行われてはなりません。
In NETLMM, the network (specifically, the MAG) derives the occurrence of a mobility event, requiring a routing update for a mobile node from link-layer handover signaling, or IP-layer movement detection signaling from the mobile node. This information is used to update routing for the mobile node at the LMA. The handover, or movement detection signaling, must provide the network with proper authentication and authorization so that the network can definitively identify the mobile node and determine its authorization. The authorization may be at the IP level -- for example, using something like SEND [3] to secure IP movement detection signaling -- or it at the link level. Proper authentication and authorization must be implemented on link-layer handover signaling and/or IP-level movement detection signaling in order for the MAG to securely deduce mobile node movement events. Security threats to the NETLMM protocol are discussed in [2].
NetLMMでは、ネットワーク（具体的にはMAG）がモビリティイベントの発生を導き出し、リンク層ハンドオーバーシグナルからのモバイルノードのルーティングアップデート、またはモバイルノードからのIPレイヤー移動検出シグナルを必要とします。この情報は、LMAのモバイルノードのルーティングを更新するために使用されます。ハンドオーバー、または移動検出シグナリングは、ネットワークがモバイルノードを明確に識別し、その承認を決定できるように、ネットワークに適切な認証と承認を提供する必要があります。承認は、IPレベルである場合があります。たとえば、送信[3]のようなものを使用して、IP移動検出シグナル伝達を確保するか、リンクレベルでそれを保護します。MAGがモバイルノード運動イベントを安全に推測するためには、適切な認証と承認をリンク層のハンドオーバーシグナル伝達および/またはIPレベルの移動検出シグナリングに実装する必要があります。NetLMMプロトコルに対するセキュリティの脅威については、[2]で説明しています。
The goal is that security for NETLMM mobile node mobility management should derive from IP network access and/or IP movement detection security, such as SEND or network access authentication, and not require any additional security associations or additional signaling between the mobile node and the network.
目標は、NetLMMモバイルノードモビリティ管理のセキュリティは、送信やネットワークアクセス認証などのIPネットワークアクセスおよび/またはIP移動検出セキュリティから派生し、モバイルノードとネットワーク間の追加のセキュリティ関連または追加のシグナル伝達を必要としないことです。。
The number of wireless link technologies available is growing, and the growth seems unlikely to slow down. Since the standardization of a wireless link physical and medium access control layers is a time-consuming process, reducing the amount of work necessary to interface a particular wireless link technology to an IP network is necessary. When the last-hop link is a wireless link, a localized mobility management solution should ideally require minimal work to interface with a new wireless link technology.
利用可能なワイヤレスリンクテクノロジーの数は増加しており、成長が遅くなる可能性は低いようです。ワイヤレスリンクの標準化物理的および中アクセス制御レイヤーの標準化は時間のかかるプロセスであるため、特定のワイヤレスリンクテクノロジーをIPネットワークにインターフェイスするのに必要な作業量を減らすことが必要です。ラストホップリンクがワイヤレスリンクである場合、ローカライズされたモビリティ管理ソリューションは、理想的には、新しいワイヤレスリンクテクノロジーとのインターフェースに最小限の作業を必要とするはずです。
In addition, an edge mobility solution should provide support for multiple wireless link technologies. It is not required that the localized mobility management solution support handover from one wireless link technology to another without a change in the IP address, but this possibility should not be precluded.
さらに、エッジモビリティソリューションは、複数のワイヤレスリンクテクノロジーをサポートする必要があります。ローカライズされたモビリティ管理ソリューションは、IPアドレスを変更せずに、あるワイヤレスリンクテクノロジーから別のワイヤレスリンクテクノロジーへの引き渡しをサポートする必要はありませんが、この可能性を排除するべきではありません。
The goal is that the localized mobility management protocol should not use any wireless link specific information for basic routing management, though it may be used for other purposes, such as securely identifying a mobile node.
目標は、ローカライズされたモビリティ管理プロトコルは、モバイルノードを安全に識別するなど、他の目的に使用される場合がありますが、基本的なルーティング管理にワイヤレスリンク固有の情報を使用しないことです。
In the WLAN switching market, no modification of the software on the mobile node is required to achieve localized mobility management. Being able to accommodate unmodified mobile nodes enables a service provider to offer service to as many customers as possible, the only constraint being that the customer is authorized for network access.
WLANスイッチング市場では、ローカライズされたモビリティ管理を実現するために、モバイルノード上のソフトウェアの変更は必要ありません。変更されていないモバイルノードに対応できることにより、サービスプロバイダーはできるだけ多くの顧客にサービスを提供できます。唯一の制約は、顧客がネットワークアクセスを許可されていることです。
Another advantage of minimizing mobile node software for localized mobility management is that multiple global mobility management protocols can be supported. There are a variety of global mobility management protocols that might also need support, including proprietary or link technology-specific protocols needing support for backward compatibility reasons. Within the Internet, both Host Identity Protocol (HIP) [11] and IKEv2 Mobility and Multihoming (MOBIKE) [6] are likely to need support in addition to Mobile IPv6 [9], and Mobile IPv4 [12] support may also be necessary.
ローカライズされたモビリティ管理のためのモバイルノードソフトウェアを最小化するもう1つの利点は、複数のグローバルモビリティ管理プロトコルをサポートできることです。また、後方互換性の理由でサポートを必要とする独自やリンク技術固有のプロトコルなど、サポートも必要になる可能性のあるさまざまなグローバルモビリティ管理プロトコルがあります。インターネット内では、ホストIdentity Protocol（HIP）[11]とIKEV2 MobilityおよびMultihoming（Mobike）[6]の両方が、モバイルIPv6 [9]に加えてサポートを必要とする可能性が高く、モバイルIPv4 [12]サポートも必要になる場合があります。。
Note that this goal does NOT mean that the mobile node has no software at all associated with mobility. The mobile node must have some kind of global mobility protocol if it is to move from one domain of edge mobility support to another and maintain session continuity, although no global mobility protocol is required if the mobile node only moves within the coverage area of the localized mobility management protocol or no session continuity is required during global movement. Also, if the last-hop link is a wireless link, every wireless link protocol requires handover support on the mobile node in the physical and medium access control layers, typically in the wireless interface driver. Information passed from the medium access control layer to the IP layer on the mobile node may be necessary to trigger IP signaling for IP handover. Such movement detection support at the IP level may be required in order to determine whether the mobile node's default router is still reachable after the move to a new access point has occurred at the medium access control layer. Whether or not such support is required depends on whether the medium access control layer can completely hide link movement from the IP layer. For cellular type wireless link protocols, the mobile node and network undergo an extensive negotiation at the medium access control layer prior to handover, so it may be possible to trigger a routing update without any IP protocol involvement. However, for a wireless link protocol such as IEEE 802.11 [7] in which the decision for handover is entirely in the hands of the mobile node, IP-layer movement detection signaling from the mobile node may be required to trigger a routing update.
この目標は、モバイルノードにモビリティに関連するソフトウェアがまったくないことを意味するものではないことに注意してください。モバイルノードには、エッジモビリティサポートのドメインから別のドメインに移動し、セッションの継続性を維持する場合は、何らかのグローバルモビリティプロトコルが必要です。グローバルな移動中にモビリティ管理プロトコルまたはセッションなしの継続性が必要です。また、ラストホップリンクがワイヤレスリンクの場合、すべてのワイヤレスリンクプロトコルには、通常、ワイヤレスインターフェイスドライバーの物理的および中程度アクセス制御レイヤーのモバイルノードでのハンドオーバーサポートが必要です。IPハンドオーバーのIPシグナルをトリガーするために、中程度のアクセス制御レイヤーからモバイルノードのIPレイヤーに渡された情報が必要になる場合があります。モバイルノードのデフォルトルーターが中程度のアクセスポイントへの移動が中程度のアクセス制御レイヤーで発生した後、モバイルノードのデフォルトルーターがまだ到達可能かどうかを判断するために、IPレベルでのこのような移動検出サポートが必要になる場合があります。そのようなサポートが必要かどうかは、中程度のアクセス制御レイヤーがIPレイヤーからのリンクの動きを完全に隠すことができるかどうかによって異なります。セルラータイプのワイヤレスリンクプロトコルの場合、モバイルノードとネットワークは、ハンドオーバー前に中程度のアクセス制御レイヤーで広範な交渉を受けているため、IPプロトコルの関与なしにルーティングアップデートをトリガーすることができます。ただし、ハンドオーバーの決定が完全にモバイルノードの手にあるIEEE 802.11 [7]などのワイヤレスリンクプロトコルの場合、ルーティングアップデートをトリガーするためにモバイルノードからのIPレイヤー移動検出シグナリングが必要になる場合があります。
The goal is that the localized mobility management solution should be able to support any mobile node that joins the link and that has an interface that can communicate with the network, without requiring localized mobility management software on the mobile node.
目標は、ローカライズされたモビリティ管理ソリューションが、リンクに結合するモバイルノードをサポートできるはずであり、モバイルノードにローカライズされたモビリティ管理ソフトウェアを必要とせずに、ネットワークと通信できるインターフェイスを備えていることです。
While most of this document is written with IPv6 in mind, localized mobility management is a problem in IPv4 networks as well. A solution for localized mobility that works for both versions of IP is desirable, though the actual protocol may be slightly different due to the technical details of how each IP version works. From Goal 7 (Section 3.7), minimizing mobile node support for localized mobility means that ideally no IP version-specific changes should be required on the mobile node for localized mobility, and that global mobility protocols for both IPv4 and IPv6 should be supported. Any IP version-specific features should be confined to the network protocol.
このドキュメントのほとんどはIPv6を念頭に置いて記述されていますが、IPv4ネットワークでもローカライズされたモビリティ管理が問題です。IPの両方のバージョンで機能するローカライズされたモビリティのソリューションが望ましいですが、実際のプロトコルは、各IPバージョンの仕組みの技術的な詳細のためにわずかに異なる場合があります。ゴール7（セクション3.7）から、ローカライズされたモビリティのモバイルノードサポートを最小限に抑えることは、ローカライズされたモビリティのためにモバイルノードで理想的にはIPバージョン固有の変更を必要としないこと、およびIPv4とIPv6の両方のグローバルモビリティプロトコルをサポートする必要があることを意味します。IPバージョン固有の機能は、ネットワークプロトコルに限定する必要があります。
Many existing protocols are available as Internet Standards upon which the NETLMM protocol can be built. The design of the protocol should have a goal to reuse existing protocols where it makes architectural and engineering sense to do so. However, the design should not attempt to reuse existing protocols where there is no real architectural or engineering reason. For example, the suite of Internet Standards contains several good candidate protocols for the transport layer, so there is no real need to develop a new transport protocol specifically for NETLMM. Reuse is clearly a good engineering decision in this case, since backward compatibility with existing protocol stacks is important. On the other hand, the network-based, localized mobility management functionality being introduced by NETLMM is a new piece of functionality, and therefore any decision about whether to reuse an existing global mobility management protocol should carefully consider whether reusing such a protocol really meets the needs of the functional architecture for network-based localized mobility management. The case for reuse is not so clear in this case, since there is no compelling backward compatibility argument.
多くの既存のプロトコルは、NetLMMプロトコルを構築できるインターネット標準として利用できます。プロトコルの設計には、既存のプロトコルを再利用することを目標とする必要があります。ただし、設計は、実際の建築または工学的理由がない場合に既存のプロトコルを再利用しようとしてはなりません。たとえば、一連のインターネット標準には、輸送層用のいくつかの優れた候補プロトコルが含まれているため、NetLMM専用の新しいトランスポートプロトコルを開発する必要はありません。既存のプロトコルスタックとの後方互換性が重要であるため、この場合、再利用は明らかにエンジニアリング決定です。一方、NetLMMによって導入されているネットワークベースのローカライズされたモビリティ管理機能は、新しい機能性であるため、既存のグローバルモビリティ管理プロトコルを再利用するかどうかの決定は、そのようなプロトコルを再利用することが本当に満たされるかどうかを慎重に検討する必要があります。ネットワークベースのローカライズされたモビリティ管理のための機能アーキテクチャのニーズ。この場合、再利用の場合はそれほど明確ではありません。これは、説得力のある後方互換性の引数がないためです。
Localized mobility management should be implementable and deployable independently of any global mobility management protocol. This enables the choice of local and global mobility management to be made independently of particular protocols that are implemented and deployed to solve the two different sorts of mobility management problems. The operator can choose a particular localized mobility management protocol according to the specific features of their access network. It can subsequently upgrade the localized mobility management protocol on its own, without even informing the mobile nodes. Similarly, the mobile nodes can use a global mobility management protocol that best suits their requirements, or not use one at all. Also, a mobile node can move into a new access network without having to check that it understands the localized mobility management protocol being used there.
ローカライズされたモビリティ管理は、グローバルモビリティ管理プロトコルとは無関係に実装可能で展開可能である必要があります。これにより、2つの異なる種類のモビリティ管理の問題を解決するために実装および展開される特定のプロトコルとは独立してローカルおよびグローバルモビリティ管理の選択を行うことができます。オペレーターは、アクセスネットワークの特定の機能に従って、特定のローカライズされたモビリティ管理プロトコルを選択できます。その後、モバイルノードを通知することなく、ローカライズされたモビリティ管理プロトコルを単独でアップグレードできます。同様に、モバイルノードは、要件に最適なグローバルモビリティ管理プロトコルを使用できます。また、モバイルノードは、そこで使用されているローカライズされたモビリティ管理プロトコルを理解していることを確認することなく、新しいアクセスネットワークに移動できます。
The goal is that the implementation and deployment of the localized mobility management protocol should not restrict, or be restricted by, the choice of global mobility management protocol.
目標は、ローカライズされたモビリティ管理プロトコルの実装と展開は、グローバルモビリティ管理プロトコルの選択を制限したり、制限したりしないことです。
Different network operators may require different types of forwarding options between the LMA and the MAGs for mobile node data plane traffic. An obvious forwarding option that has been used in past IETF localized mobility management protocols is IP-IP encapsulation for bidirectional tunneling. The tunnel endpoints are the LMA and the MAGs. But other options are possible. Some network deployments may prefer routing-based solutions. Others may require security tunnels using IPsec Encapsulating Security Payload (ESP) encapsulation if part of the localized mobility management domain runs over a public access network and the network operator wants to protect the traffic.
ネットワークオペレーターごとに、モバイルノードデータプレーントラフィックには、LMAとMAGSの間に異なるタイプの転送オプションが必要になる場合があります。過去のIETFローカライズされたモビリティ管理プロトコルで使用されてきた明らかな転送オプションは、双方向トンネルのIP-IPカプセル化です。トンネルのエンドポイントはLMAと雑誌です。しかし、他のオプションが可能です。一部のネットワーク展開は、ルーティングベースのソリューションを好む場合があります。他の人は、ローカライズされたモビリティ管理ドメインの一部がパブリックアクセスネットワーク上で実行され、ネットワークオペレーターがトラフィックを保護したい場合、IPSECカプセル化セキュリティペイロード（ESP）カプセル化を使用してセキュリティトンネルを必要とする場合があります。
A goal of the NETLMM protocol is to allow the forwarding between the LMA and MAGs to be configurable depending on the particulars of the network deployment. Configurability is not expected to be dynamic, as in controlled by the arrival of a mobile node; but rather, configuration is expected to be similar in timescale to configuration for routing. The NETLMM protocol may designate a default forwarding mechanism. It is also possible that additional work may be required to specify the interaction between a particular forwarding mechanism and the NETLMM protocol, but this work is not in scope of the NETLMM base protocol.
NetLMMプロトコルの目標は、ネットワークの展開の詳細に応じて、LMAとMAGS間の転送を構成可能にすることです。モバイルノードの到着によって制御されるように、構成可能性は動的であるとは予想されません。むしろ、構成はタイムスケールでルーティングの構成と類似すると予想されます。NetLMMプロトコルは、デフォルトの転送メカニズムを指定する場合があります。また、特定の転送メカニズムとNetLMMプロトコルの間の相互作用を指定するために追加の作業が必要になる可能性もありますが、この作業はNetLMMベースプロトコルの範囲ではありません。
There are two kinds of security issues involved in network-based localized mobility management: security between the mobile node and the network, and security between network elements that participate in the NETLMM protocol. The security-related goals in this document, described in Section 3.3 and 3.5, focus on the former, because those are unique to network-based mobility management. The threat analysis document [2] contains a more detailed discussion of both kinds of threats, which the protocol design must address.
ネットワークベースのローカライズされたモビリティ管理には、モバイルノードとネットワーク間のセキュリティと、NetLMMプロトコルに参加するネットワーク要素間のセキュリティの2種類のセキュリティ問題があります。セクション3.3および3.5で説明されているこのドキュメントのセキュリティ関連の目標は、ネットワークベースのモビリティ管理に固有のものであるため、前者に焦点を当てています。脅威分析文書[2]には、プロトコル設計が対処する必要がある両方の種類の脅威のより詳細な議論が含まれています。
The authors would like to acknowledge the following people for particularly diligent reviewing: Vijay Devarapalli, Peter McCann, Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred Templin.
著者は、Vijay Devarapalli、Peter McCann、Gabriel Montenegro、Vidya Narayanan、Pekka Savola、およびFred Templinの特に勤勉なレビューのために、次の人々を認めたいと考えています。
[1] Kempf, J., Ed., "Problem Statement for Network-Based Localized Mobility Management (NETLMM)", RFC 4830, April 2007.
[1] Kempf、J.、ed。、「ネットワークベースのローカライズされたモビリティ管理（NetLMM）の問題ステートメント」、RFC 4830、2007年4月。
[2] Vogt, C., and Kempf, J., "Security Threats to Network-Based Localized Mobility Management (NETLMM)", RFC 4832, April 2007.
[2] Vogt、C。、およびKempf、J。、「ネットワークベースのローカライズされたモビリティ管理（NetLMM）に対するセキュリティの脅威」、RFC 4832、2007年4月。
[3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[3] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[4] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[4] カーペンター、B。、「インターネットの建築原則」、RFC 1958、1996年6月。
[5] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment in IPv6", RFC 4135, August 2005.
[5] チェ、JH。G. Daley、「IPv6のネットワーク添付ファイルを検出する目標」、RFC 4135、2005年8月。
[6] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[6] Eronen、P。、「IKEV2モビリティとマルチホミングプロトコル（MOBIKE）」、RFC 4555、2006年6月。
[7] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical Layer (PHY) specifications", IEEE Std. 802.11, 1999.
[7] IEEE、「ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様」、IEEE STD。802.11、1999。
[8] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x, June, 2001.
[8] IEEE、「ポートベースのアクセスコントロール」、IEEE LAN/MAN STARDAND 802.1X、2001年6月。
[9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[9] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[10] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[10] Mather、J。およびM. Kojo、「Mobility関連用語」、RFC 3753、2004年6月。
[11] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[11] Moskowitz、R。およびP. Nikander、「Host Identity Protocol（HIP）Architecture」、RFC 4423、2006年5月。
[12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[12] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
[13] Soliman、H.、Castelluccia、C.、El Malki、K。、およびL. Bellier、「階層モバイルIPv6モビリティ管理（HMIPV6）」、RFC 4140、2005年8月。
[14] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[14] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: kleung@cisco.com
Kent Leung Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134 USAメール：kleung@cisco.com
Phil Roberts Motorola Labs Schaumberg, IL USA EMail: phil.roberts@motorola.com
Phil Roberts Motorola Labs Schaumberg、IL USAメール：Phil.roberts@motorola.com
Katsutoshi Nishida NTT DoCoMo Inc. 3-5 Hikarino-oka, Yokosuka-shi Kanagawa, Japan Phone: +81 46 840 3545 EMail: nishidak@nttdocomo.co.jp
nishida ntt docomo Inc. 3-5 hikarino-oka、yokosuka-shi kanagawa、日本電話：81 46 840 3545電子メール：nishidak@nttdocomo.co.jp
Gerardo Giaretta Telecom Italia Lab via G. Reiss Romoli, 274 10148 Torino Italy Phone: +39 011 2286904 EMail: gerardo.giaretta@tilab.com
G. Reiss Romoli経由のGerardo Giaretta Telecom Italia Lab、274 10148 Torino Italy電話：39 011 2286904メール：gerardo.giaretta@tilab.com
Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221-90511-46 EMail: marco.liebsch@ccrle.nec.de
Marco Liebsch Nec Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Dermany電話：49 6221-90511-46メール：marco.liebsch@ccrle.nec.de
Editor's Address
編集者のアドレス
James Kempf DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA Phone: +1 408 451 4711 EMail: kempf@docomolabs-usa.com
James Kempf Docomo USA Labs 181 Metro Drive、Suite 300 San Jose、CA 95110 USA電話：1 408 451 4711メール：kempf@docomolabs-usa.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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://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エディター機能の資金は現在、インターネット協会によって提供されています。