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)
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）IETFトラスト（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）スイッチのアプローチは、 - 検査されます。問題文文書からの結論は、アプローチのいずれが問題の完全な解決策を持っていないということです。それは無線LAN、独自の自然の限界の相互運用性のための標準ドライバー以外の移動ノードには何のソフトウェアを必要とせず、かつので、WLANスイッチアプローチは、ネットワーク事業者とユーザーのための最も便利であるが、単一の最終ホップリンクタイプと有線バックホールへの制限リンクタイプは、スケーラビリティが制限されます。 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は、ローカライズされたモビリティ管理ドメイン内のIPノードのモビリティを管理するためにNETLMMプロトコルを使用しています。モバイルノードは、ローカライズされたモビリティ管理ドメイン内の周りに移動するモバイルノードのデータトラフィックのルーティングは、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）は、ローカライズされたモビリティ管理ドメイン内の個々のモバイルノードのためのルートのコレクションを維持します。ルートは、モバイルノードが現在配置されているリンクを管理するモバイルアクセスゲートウェイ（MAG群）を指します。モバイルノードのためにパケットが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+).
セクション2は、[1]局在モビリティ管理のためのグローバルモビリティ管理プロトコルを用いて三つの問題を記載しています。任意の局所モビリティ管理プロトコルは、当然これらの三つの問題に対処しなければなりません。また、ネットワークにそのような溶液を導入する副作用が制限される必要があります。このセクションでは、我々は両方の基本的な問題（目標1、2、および3）を解くと、副作用（目標を4+）制限を含むNETLMMの目標を、対処します。
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層で提案されています。ローカライズされたモビリティ管理のためのこの目標の一つの態様は、ハンドオーバ後に転送を変更するための処理遅延ができるだけ近くに、リンク層ハンドオーバとアクティブIP層移動検出に要する遅延に関連する遅延の和に接近しなければならないことです過度のパケット損失を避けるために。ネットワーク側リンク層支持体は、前リンクハンドオーバまたはリンクハンドオーバープロセスの一部として動き検出を処理するために利用可能である場合、理想的には、ルーティング更新は、リンクハンドオーバーに必要な時間内に完了すべきです。この遅延は、定量化が困難であるが、通話品質の悪化を回避するためには40〜70ミリ秒の間である必要があり、レイヤ2ハンドオーバ時間とIPハンドオーバ時間を含む音声トラフィック、全体のハンドオーバ遅延のため。リンク層ハンドオーバ待ち時間が高すぎる場合はもちろん、優れたリアルタイムサービスのための十分な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層とリンク層ハンドオーバー待ち時間未満70ミリ秒であるように、IPハンドオーバにおける待ち時間の量を低減することです。
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レベルの移動検出、。 [5]検出ネットワークアタッチメント（DNA）プロトコルは、この目的のためにルータ要請/ルータ広告を使用します。また、セキュア近隣探索（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] REPORTメッセージ、リンクローカルアドレスとグローバルアドレスに対応する要請ノードマルチキャストアドレスごとに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）重複アドレス検出、リンクローカルアドレスとグローバルアドレスのための1のための1つのための二つの近隣要請（NS）メッセージを。アドレスが一意である場合は、応答が来ることはないだろう。
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）通信相手ノードとモバイルノードとの間の帰路経路シグナル伝達を試験/ケア試験開始のホーム試験開始/ホーム試験およびケアからなる、結合キーを確立します。
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は、異なるものになります。モバイルIPv6を使用する場合は、手順6-8にのみ必要です。結果は、それがリンクを確立し、有していることを保証することができる正確な数は、移動ノードは、移動ノードの前にキャッシュされたルータの証明書を持っているか否かなどの様々な特定の要因に依存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レベルの移動検出を実行するために、モバイルノードのために必要とされるものよりも多くないはずです-layerサポートが存在します。さらに、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サブネットと地域との間のマッピングの粒度は、使用中の特定のリンクタイプのために小さい場合、攻撃者が潜在的にリアルタイムで被害者を見つけるための十分な情報を集めることができます。
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.
有線と無線の両方の部分を含むアクセスネットワークは、バックボーンよりもやや強い帯域幅とルータの処理制約を持っている傾向があります。ネットワークの有線部分では、これらの制約は、広く分散した地理的エリア内の無線アクセスポイントへの繊維や配線を敷設するコストの関数です。ネットワークの無線部分では、これらの制約は、物理層プロトコルによって課さヘルツ当たりのビット数の制限によるものです。そのため、ローカライズされた移動性管理のためのすべてのソリューションは、アクセスネットワーク内のオーバーヘッドを最小限に抑える必要があります。
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
NETLMMにおいて、ネットワークは、（具体的には、MAG）は、モバイルノードからのリンク層ハンドオーバシグナリング、またはIP層移動検出シグナリングからモバイルノードのルーティングアップデートを必要とする、モビリティイベントの発生を導出します。この情報は、LMAにおける移動ノードのルーティングを更新するために使用されます。ネットワークは決定的にモバイルノードを識別し、その承認を決定できるように、ハンドオーバ、または動き検出シグナリングは、適切な認証および認可をネットワークに提供しなければなりません。 [3] IP移動検出シグナルを確保するSENDのようなものを使用して、例えば - - 認可はIPレベルであってもよく、またはそれは、
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].
リンクレベル。適切な認証及び認可は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モバイルノードの移動性管理のためのセキュリティは、SENDまたはネットワークアクセス認証などの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.
アイデンティティプロトコル（HIP）[11]とのIKEv2モビリティ及びマルチホーミング（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によって導入されたネットワークベースの、局所モビリティ管理機能は、機能の新しい作品であるため、既存のグローバルモビリティ管理プロトコルを再利用するかどうかについての決定は慎重にそのようなプロトコルを再利用することは本当に満たしているかどうかを検討すべきですネットワークベースのローカライズされたモビリティ管理のための機能アーキテクチャのニーズ。何の説得力の後方互換性の引数が存在しないため、再利用のためのケースでは、この場合にはそれほど明確ではありません。
3.10. Goal 10: Localized Mobility Management Independent of Global Mobility Management
3.10. 目標10：グローバル・モビリティ・マネジメントのローカライズされたモビリティ・マネジメントの独立
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.
ローカライズされたモビリティ管理は、独立して、任意のグローバルモビリティ管理プロトコルの実装可能と展開可能でなければなりません。これは、ローカルおよびグローバルモビリティ管理の選択は独立して実装され、モビリティ管理の問題の二つの異なる種類を解決するために配備されている特定のプロトコルで構成することができます。オペレータは、そのアクセスネットワークの特定の機能に応じて特定の局所モビリティ管理プロトコルを選択することができます。これは、その後も、モバイルノードに通知することなく、独自にローカライズされたモビリティ管理プロトコルをアップグレードすることができます。同様に、モバイルノードは、最高の自分の要件に合ったグローバルモビリティ管理プロトコルを使用することができ、またはまったくものを使用していません。また、モバイルノードは、それが使用されている局所モビリティ管理プロトコルを理解していることを確認することなく、新しいアクセス・ネットワークに移動することができます。
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.
目標は、局所モビリティ管理プロトコルの実装と展開が制限べきではない、またはグローバルモビリティ管理プロトコルの選択によって制限されるということです。
3.11. Goal 11: Configurable Data Plane Forwarding between Local Mobility Anchor and Mobile Access Gateway
3.11. 目標11：ローカルモビリティアンカーとモバイルアクセスゲートウェイの間で設定可能なデータプレーンフォワーディング
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とモバイルノードのデータプレーントラフィック用のMAGとの間の転送オプションの種類を必要とし得ます。過去のIETF局所モビリティ管理プロトコルで使用されている明白な転送オプションは、双方向トンネリング用IP-IPカプセル化です。トンネルエンドポイントは、LMAとのMAGです。しかし、他のオプションが可能です。一部のネットワークの展開は、ルーティングベースのソリューションを好むかもしれません。その他には、ローカライズされたモビリティ管理ドメインの一部は、パブリックアクセスネットワーク上で動作し、ネットワークオペレータは、トラフィックを保護したい場合の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とのMAG間の転送がネットワーク展開の詳細に応じて設定できるようにできるようにすることです。構成可能性は、移動ノードの到着によって制御と同様に、動的であることが期待されていません。むしろ、構成をルーティングするための構成とタイムスケールにおいて類似であると予想されます。 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.
ビジェイDevarapalli、ピーター・マッキャン、ガブリエルモンテネグロ、Vidyaナラヤナン、ペッカSavola、およびフレッド・テンプリン：著者は、特に勤勉な審査のために以下の方々に感謝します。
[1] Kempf, J., Ed., "Problem Statement for Network-Based Localized Mobility Management (NETLMM)", RFC 4830, April 2007.
[1]ケンプ、J.、エド。、 "ネットワークベース局所モビリティ管理（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]フォークト、C.、およびケンプ、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.、ケンプ、J.、Zill、B.、およびP. Nikanderを、 "セキュア近隣探索（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.デイリー、「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標準802.1X、2001年6月。
[9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[9]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[10] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[10]ようにして、J.とM.古城、 "モビリティ関連用語"、RFC 3753、2004年6月。
[11] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[11]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[12]パーキンス、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]ソリマン、H.、カステルッシア、C.、エルMalki、K.、およびL. Bellier、 "階層型Mobile 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]ヴィーダ、R.とL.コスタ、 "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
ケントレオンシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 USA Eメール：kleung@cisco.com
Phil Roberts Motorola Labs Schaumberg, IL USA EMail: phil.roberts@motorola.com
フィル・ロバーツモトローラ研究所Schaumberg、IL USA Eメール：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
かつとし にしだ んっｔ どこも いんｃ。 ３ー５ ひかりのーおか、 よこすかーし かながわ、 じゃぱん Ｐほね： ＋８１ ４６ ８４０ ３５４５ えまいｌ： にしだｋ＠んっｔどこも。こ。ｊｐ
Gerardo Giaretta Telecom Italia Lab via G. Reiss Romoli, 274 10148 Torino Italy Phone: +39 011 2286904 EMail: gerardo.giaretta@tilab.com
G.ライスRomoli経由ヘラルドGiarettaテレコムイタリア・ラボ、274 10148トリノイタリア電話：+39 011 2286904 Eメール：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
マルコLiebsch NECネットワーク研究所Kurfuersten所36ハイデルベルクドイツ電話：+49 6221-90511-46 Eメール：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
ジェームズ・ケンプドコモUSA Labsの181メトロドライブ、スイート300サンノゼ、CA 95110 USA電話：+1 408 451 4711 Eメール：kempf@docomolabs-usa.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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機能のための基金は現在、インターネット協会によって提供されます。