RFC4831 日本語訳
4831 Goals for Network-Based Localized Mobility Management (NETLMM).J. Kempf, Ed.. April 2007. (Format: TXT=35232 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Kempf, Ed. Request for Comments: 4831 DoCoMo USA Labs Category: Informational April 2007
ワーキンググループのJ.ケンフ、エドをネットワークでつないでください。コメントのために以下を要求してください。 4831年のDoCoMo米国研究室カテゴリ: 情報の2007年4月
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).
IETFが信じる著作権(C)(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
1. 序論…2 1.1. 用語…2 2. NETLMM機能的な建築…3 3. NETLMMの目標は議定書を作ります…3 3.1. 目標1: 引き渡しパフォーマンス改良…4 3.2. 目標2: 引き渡し関連のシグナリングボリュームの減少…5 3.3. 目標3: 位置のプライバシー…6 3.4. 目標4: ネットワークがオーバーヘッドを制限してください…7 3.5. 目標5: IPネットワークアクセス、そして/または、IP運動から検出セキュリティを引き出すことによって、モバイルノード移動性管理セキュリティを簡素化してください…7 3.6. 目標6: 技術不可知論者をリンクしてください…8 3.7. 目標7: 変更されていないモバイルノードのために、サポートします。8 3.8. 目標8: IPv4とIPv6のために、サポートします。9 3.9. 目標9: 既存のプロトコルの再利用、分別があるところ…10 3.10. 目標10: グローバルな移動性管理の如何にかかわらず移動性が管理であるとローカライズします…10 3.11. 目標11: 地元の移動性アンカーとモバイルアクセスゲートウェイの間の構成可能なデータ飛行機推進。11 4. セキュリティ問題…11 5. 承認…11 6. 標準の参照…12 7. 有益な参照…12 8. 貢献者…13
Kempf Informational [Page 1] RFC 4831 NETLMM Goals April 2007
[1ページ]RFC4831NETLMM目標2007年4月の情報のケンフ
1. Introduction
1. 序論
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スイッチの間で異なったサブネットに使用される独占Wireless LAN(WLAN)スイッチアプローチ)が調べられます。 問題声明ドキュメントからの結論はアプローチのいずれにはも問題の完全解がないということです。 WLANは切り替わりますが、それがWiFiのための標準のドライバー以外のモバイルノードの上のソフトウェアを全く必要としないので、ネットワーク・オペレータとユーザはアプローチが最も都合がよく、独占自然限界は相互運用性です、そして、単独の最後のホップリンク型とワイヤードな逆送リンク型への制限はスケーラビリティを制限します。 IETFのホストベースのプロトコルはすべてのグローバルな移動性プロトコルと互換性がないかもしれないホストソフトウェア・スタック変化を必要とします。 また、彼らはdeployabilityを制限するかもしれないネットワークがある専門化していて複雑なセキュリティトランザクションを必要とします。 結論は基づくネットワークであり、ローカライズしている移動性管理のホストの上でソフトウェアを全く必要としないローカライズしている移動性管理プロトコルが望ましいということです。
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は簡潔にSecurity Considerationsについて概説します。 脅威解析書[2]でセキュリティの、より多くの議論を見つけることができます。
1.1. Terminology
1.1. 用語
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:
移動性用語はRFC3753[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]で定義された意味におけるAccess Networkは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
モバイルAccessゲートウェイ(MAG)は縁のリンクの間で特定の縁のリンクを終えて、モバイルノードIP-レベルの移動性を追跡する機能的ネットワーク要素です、Localized Mobility Anchorと共に合図するNETLMMを通して。 また、MAGはモバイルノードのためのLocalized Mobility Anchorからのホストの発送されたデータ通信量を終えます。
Kempf Informational [Page 2] RFC 4831 NETLMM Goals April 2007
[2ページ]RFC4831NETLMM目標2007年4月の情報のケンフ
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のコントロールの下における縁のリンク、以内と前方で縁のリンクの上のコントロールの下におけるモバイルノードからLocalized Mobility Anchorまでのデータ通信量の場所を見つけました。
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.
Local Mobility Anchor(LMA)はローカライズしている移動性管理ドメインの中のコントロールの下におけるモバイルノードのためのホストルートと関連推進情報の収集を維持するルータです。 それに関連しているMAGsと共に、LMAは、ローカライズしている移動性管理ドメインの中でIPノードの移動性を管理するのにNETLMMプロトコルを使用します。 モバイルノードがローカライズしている移動性管理ドメインの中を動き回るとき、モバイルノードデータ通信量のルート設定はLMAに据えつけられます。
2. NETLMM Functional Architecture
2. NETLMM機能的な建築
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アーキテクチャは以下のコンポーネントから成ります。 バックボーンネットワークの中のローカライズしているMobility Anchors(LMAs)は個々のモバイルノードのためにローカライズしている移動性管理ドメインの中でルートの収集を維持します。 ルートは、モバイルノードが現在見つけられているリンクを管理しながら、モバイルAccess Gateways(MAGs)を示します。 モバイルノードのためのパケットはノードとモバイルノードからLMAとMAGの間のトンネルまで発送されます。 モバイルノードが別のものへの1個のリンクから移行すると、MAGはルートアップデートをLMAに送ります。 何らかのモバイルノードかかわり合いが必要であり、動き検出などのジェネリック移動性機能、モバイルノード運動に関してMAGに知らせると予想されている間、特定のモバイルノードからどんなネットワーク・プロトコルもローカライズしている移動性管理自体に必要でないでしょう。 その結果、移動性管理におけるホストスタックかかわり合いはIP層でのジェネリック移動性機能に制限されます、そして、どんな専門化しているローカライズしている移動性管理ソフトウェアも必要ではありません。
3. Goals for the NETLMM Protocol
3. NETLMMプロトコルの目標
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+)を制限して。
Kempf Informational [Page 3] RFC 4831 NETLMM Goals April 2007
[3ページ]RFC4831NETLMM目標2007年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プロトコルのいくつかの基本的な目標について議論しませんが、どんなソリューションもそれらを満たすと予想されます。 これらの目標は、耐障害性と、丈夫さと、相互運用性と、スケーラビリティと、最小量の専門化しているネットワーク装置です。 [4]でIETFプロトコルへの彼らの適用性の良い議論を見つけることができます。
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.
当初の目標議論のための範囲の外にService(QoS)と眠っているモード/ページングのQualityがあります。 これらはモバイルノードのための重要な機能ですが、それらは移動性管理問題であるとローカライズされたベースの一部ではありません。 さらに、ローカライズしている移動性管理ドメインの間の移動性はここにカバーされていません。 これがグローバルな移動性管理プロトコルでカバーされていると思われます。
3.1. Goal 1: Handover Performance Improvement
3.1. 目標1: 引き渡しパフォーマンス改良
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があるかので、引き渡しパケット損失は起こります。 この間に、モバイルノードは通信員がパケットを送る古いリンクで前の位相的な位置で手が届きません。 そのようなmisroutedパケットは下げられます。 引き渡しパフォーマンスの最適化のこの局面は多くの仕事の対象です、他のStandards Development Organizations(SDOs)とIETFの両方、IP引き渡しにおけるレイテンシを減少させるために。この問題への多くの解決がリンクレイヤにおいてIP層で提案されました。 ローカライズしている移動性管理のこの目標の1つの局面は引き渡しにアプローチしなければならなかった後に推進を変えるための遅れの合計がリンクレイヤ引き渡しと交際したのが密接同じくらい可能な処理遅れと遅れが活発なIP-層の動き検出に必要であるということです、過度のパケット損失を避けるために。 ネットワークサイドリンクレイヤサポートがリンク引き渡しの前かLayer2引き渡し時間を含んでいて、業務引き継ぎ作業、ルーティングアップデートがリンクに必要であることで、引き渡しこの遅れが定量化しますが、音声トラヒック、全体の引き渡し遅らせるのが難しい時代中に完成するべきであり、IP引き渡し時間がどんな退行も避けるためには40-70 msの間のものであるはずであるリンクの一部として取り扱い動き検出に利用可能であるなら、理想的に、品質に電話をしてください。 もちろん、リンクレイヤ引き渡し潜在が高過ぎるなら、良いリアルタイムのサービスのための十分な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未満原稿であるように
Kempf Informational [Page 4] RFC 4831 NETLMM Goals April 2007
[4ページ]RFC4831NETLMM目標2007年4月の情報のケンフ
3.2. Goal 2: Reduction in Handover-Related Signaling Volume
3.2. 目標2: 引き渡し関連のシグナリングボリュームの減少
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]再認証と共にこれはReassociateメッセージです。
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-レベル動き検出。 Detecting Network Attachment(DNA)プロトコル[5]はこのためにRouter Solicitation/ルータAdvertisementを使用します。 追加SEcure Neighborディスカバリー(SEND)です。 [3]は使用されています、そして、ルータのためにモバイルノードで証明書をキャッシュしません、そして、モバイルノードは証明経路を得るのにCertification Path Solicitation/証明Path Advertisementを使用しなければなりません。
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) 写しへの2Neighbor Solicitation(NS)メッセージは検出、リンクローカルアドレスのためのもの、およびグローバルアドレスのための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つのNeighbor Advertisementメッセージ。
6) Binding Update/Binding Acknowledgement between the mobile node and
home agent to update the care of address binding.
6) アドレス結合の注意をアップデートするためにモバイルノードとホームのエージェントの間でUpdate/拘束力があるAcknowledgementを縛ります。
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) 通信員ノードとモバイルノードの間で拘束力があるキーを設立すると合図するroutabilityを返してください、TestのTest Init/注意の1つのホームのTest Init/ホームのTestとCareから成って。
8) Binding Update/Binding Acknowledgement between the correspondent
node and mobile node for route optimization.
8) 経路最適化のための通信員ノードとモバイルノードの間でUpdate/拘束力があるAcknowledgementを縛ります。
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
Steps1-2がイントラリンクの移動性にさえ必要であるかもしれないことに注意してください、最後のホップリンク・プロトコルがIP引き渡しのための多くの助けを提供しないなら。statefulアドレス構成が使用されていると、ステップ3-5は異なるでしょう、追加メッセージがアドレスを得るのに必要であるので。 モバイルIPv6が必要であるときにだけ、ステップ6-8が必要です。
Kempf Informational [Page 5] RFC 4831 NETLMM Goals April 2007
[5ページ]RFC4831NETLMM目標2007年4月の情報のケンフ
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の接続性を持っているときIPのおよそ18のメッセージがはっきりした数が様々な特殊生産要素によるところのそのようなものを平らにするということです。 モバイルノードがモバイルIPv6経路最適化を実行するなら合図する関係づけられた引き渡しに加えて、それが定期的(7分毎の注文に関して)にリターンroutabilityキーを取り替えるのに必要であるかもしれません、移行していなくても、追加シグナリングをもたらして。
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.
Goal1に影響を与えて、必要であるシグナリングは引き渡しの性能に大きい影響力を持っています。 恐らくより重要に、高価な共有されたリンク(容易にリンクの容量を広げることができないワイヤレスなどの)の上に合図するのがもたらすことができるそのようなものの多くのモバイルノードからの集合影響はデータ通信量の最後のホップリンク容量を減少させました。 さらに、エンドユーザが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-レベルも実行する必要はないかもしれません。
3.3. Goal 3: Location Privacy
3.3. 目標3: 位置のプライバシー
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.
移動性は追加脅威を導入します。 攻撃者はリアルタイムで状態でモバイルノードの地理的な位置を歩いて持ち込むことができます、カバーされた地理的な領域を通って1つのサブネットから別のサブネットまで移行するとき犠牲者モバイルノードがIPアドレスを変えなければならないなら。 使用中の特定のリンク型にとって、IPサブネットと地理的な領域の間のマッピングの粒状が小さいなら、攻撃者は潜在的にリアルタイムで犠牲者を見つけることができるくらいの情報を組み立てることができます。
Kempf Informational [Page 6] RFC 4831 NETLMM Goals April 2007
[6ページ]RFC4831NETLMM目標2007年4月の情報のケンフ
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サブネットと地理的な領域の間のマッピングの解決からfuzzesされます、自然な展開粒状がどれくらい小さいかもしれないかにかかわらず。 これは攻撃者がモバイルノードの正確な地理的な位置を推論できるという可能性を小さくします。
3.4. Goal 4: Limit Overhead in the Network
3.4. 目標4: ネットワークにおける限界オーバーヘッド
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.
両方のワイヤードでワイヤレスの部品を含むアクセスネットワークは、バックボーンよりいくらか強い帯域幅とルータ処理規制を持っている傾向があります。 ネットワークのワイヤードな部分では、これらの規制が広く分散している地理的な領域のワイヤレス・アクセスポイントにファイバーか配線を横たえる費用の関数です。 ネットワークのワイヤレスの部分に、これらの規制が1物理的な層のプロトコルによって課された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
NETLMMでは、ネットワーク(明確にMAG)は移動性イベントの発生を引き出します、モバイルノードからリンクレイヤ引き渡しシグナリング、またはIP-層の動き検出シグナリングからのモバイルノードのためのルーティングアップデートを必要として。 この情報は、LMAのモバイルノードのためにルーティングをアップデートするのに使用されます。 引き渡し、または動き検出シグナリングが、ネットワークが決定的にモバイルノードを特定して、承認を決定できるように、適切な認証と承認をネットワークに提供しなければなりません。 承認が例えば、IP運動が検出シグナリングであると機密保護するのに何かSEND[3]のようなものを使用するというIPレベルかそれにあるかもしれません。
Kempf Informational [Page 7] RFC 4831 NETLMM Goals April 2007
[7ページ]RFC4831NETLMM目標2007年4月の情報のケンフ
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-レベル動き検出のときに適切な認証と承認を実装しなければなりません。 [2]でNETLMMプロトコルへの軍事的脅威について議論します。
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運動からSENDかネットワークアクセス認証などの検出セキュリティを引き出して、モバイルノードとネットワークの間で少しの追加担保協会や追加シグナリングも必要とするべきでないということです。
3.6. Goal 6: Link Technology Agnostic
3.6. 目標6: リンク技術不可知論者
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アドレスにおける変化なしで1つのワイヤレスのリンク技術から別の技術までの引き渡しをサポートするのが必要ではありませんが、この可能性を排除するべきではありません。
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.
目標はローカライズしている移動性管理プロトコルが基本的なルーティング管理に少しのワイヤレスのリンク特殊情報も使用するべきでないということです、それが他の目的に使用されるかもしれませんが、しっかりとモバイルノードを特定するのなどように。
3.7. Goal 7: Support for Unmodified Mobile Nodes
3.7. 目標7: 変更されていないモバイルノードのサポート
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
ローカライズしている移動性管理のためのモバイルノードソフトウェアを最小にする別の利点は複数のグローバルな移動性管理プロトコルをサポートできるということです。 後方の互換性理由でまた、独占である状態でサポート、包含を必要とするか、またはサポートを必要とする技術特有のプロトコルをリンクするかもしれないさまざまなグローバルな移動性管理プロトコルがあります。 インターネットの中で両方、Host
Kempf Informational [Page 8] RFC 4831 NETLMM Goals April 2007
[8ページ]RFC4831NETLMM目標2007年4月の情報のケンフ
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.
また、モバイルIPv4[12]サポートも必要であるかもしれませんアイデンティティプロトコル(HIP)[11]とIKEv2 MobilityとMultihoming(MOBIKE)[6]がモバイルIPv6[9]に加えてサポートが必要でありそうです、そして、。
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.
この目標が、モバイルノードでソフトウェアが全く移動性に全く関連するようにならないことを意味しないことに注意してください。 モバイルノードは、縁の移動性サポートの1つのドメインから別のドメインまで移行するつもりであるならある種のグローバルな移動性を議定書の中で述べさせて、セッションの連続を主張しなければなりません、モバイルノードがローカライズしている移動性管理プロトコルの適用範囲の地域の中で移行するだけであるか、またはセッションの連続は全く世界的動向の間、必要でないなら、どんなグローバルな移動性プロトコルも必要ではありませんが。 また; 最後のホップリンクがワイヤレスのリンクであるなら、あらゆるワイヤレスのリンク・プロトコルが物理的で中型のアクセス制御層のモバイルノードの上で引き渡しサポートを必要とします、通常ワイヤレスインターフェースドライバーで。モバイルノードで媒体アクセス制御層からIP層まで通過された情報が、IP引き渡しのために合図するIPの引き金となるのに必要であるかもしれません; IPレベルにおけるそのような動き検出サポートが、新しいアクセスポイントへの移動が媒体アクセス制御層に起こった後にモバイルノードのデフォルトルータがまだ届いているかどうか決定するのに必要であるかもしれません。 そのようなサポートが必要であるかどうかが媒体アクセス制御層がIP層からリンク運動を完全に隠すことができるかどうかによります。 細胞型ワイヤレスリンク・プロトコルのために、モバイルノードとネットワークが引き渡しの前に媒体アクセス制御層で大規模な交渉を受けるので、少しもIPプロトコルかかわり合いなしでルーティングアップデートの引き金となるのは可能であるかもしれません。 しかしながら、引き渡しのための決定が完全なモバイルノードの手にあるIEEE802.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.
目標はローカライズしている移動性運営方法がリンクを接合して、ネットワークとコミュニケートできるインタフェースを持っているどんなモバイルノードもサポートできるべきであるということです、モバイルノードの上の移動性管理ソフトウェアであるとローカライズされた必要さなしで。
3.8. Goal 8: Support for IPv4 and IPv6
3.8. 目標8: IPv4とIPv6のサポート
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バージョンがどう働くかに関する技術的詳細でわずかに異なるかもしれませんが。 Goal7(セクション3.7)から、ローカライズしている移動性のモバイルノードサポートを最小にするのは、ローカライズしている移動性のためのモバイルノードの上で理想的にどんなIPのバージョン特有の変化も必要とするべきでなくて、IPv4とIPv6の両方のためのグローバルな移動性プロトコルをサポートするべきであることを意味します。 どんなIPのバージョン特有の特徴もネットワーク・プロトコルに限定されるべきです。
Kempf Informational [Page 9] RFC 4831 NETLMM Goals April 2007
[9ページ]RFC4831NETLMM目標2007年4月の情報のケンフ
3.9. Goal 9: Reuse of Existing Protocols Where Sensible
3.9. 目標9: 既存のプロトコルの再利用、分別があるところ
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が議定書を作るインターネットStandardsを造ることができるので、利用可能です。 プロトコルのデザインには、それがそうする建築していて設計している意味になる既存のプロトコルを再利用する目標があるべきです。 しかしながら、デザインは、全く建築しているノーがある既存のプロトコルか工学理由を再利用するのを試みるべきではありません。 例えば、インターネットStandardsのスイートがトランスポート層のためのいくつかの良い候補プロトコルを含んでいるので、特に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.
移動性管理であるとローカライズされているのは、どんなグローバルな移動性管理プロトコルの如何にかかわらず実装可能と配布可能であるべきです。 これは、異なった2種類の移動性管理問題を解決するために実装されて、配布される特定のプロトコルの如何にかかわらず地方の、そして、グローバルな移動性管理の選択をするのを可能にします。それらのアクセスネットワークの特定の特徴に従って、オペレータは特定のローカライズしている移動性管理プロトコルを選ぶことができます。 モバイルノードを知らせていなくてさえいなくて、それは次に、それ自身のところでローカライズしている移動性管理プロトコルをアップグレードさせることができます。 同様に、モバイルノードは、それらの要件に最もよく合うグローバルな移動性管理プロトコルを使用できませんし、また全く1つを使用できません。 また、ローカライズしている移動性管理プロトコルを理解しているのをチェックする必要はなくて、モバイルノードは、そこで使用されることで新しいアクセスネットワークに移行できます。
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.
ローカライズしている移動性管理プロトコルの実装と展開が制限するべきではありませんし、制限されるべきでない目標は、あります、グローバルな移動性管理プロトコルの選択。
Kempf Informational [Page 10] RFC 4831 NETLMM Goals April 2007
[10ページ]RFC4831NETLMM目標2007年4月の情報のケンフ
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とMAGsの間にオプションを送るのを異なったタイプに要求するかもしれません。 移動性管理プロトコルであるとローカライズされた過去のIETFで使用された明白な推進オプションは双方向のトンネリングのためのIP-IPカプセル化です。 トンネル終点は、LMAとMAGsです。 しかし、別の選択肢は可能です。 いくつかのネットワーク展開がルーティングベースのソリューションを好むかもしれません。 他のものは、ローカライズしている移動性管理ドメインの一部がパブリックアクセスネットワークをひいて、ネットワーク・オペレータがトラフィックを保護したいならIPsec Encapsulating Security有効搭載量(超能力)カプセル化を使用することでセキュリティトンネルを必要とするかもしれません。
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の間の推進が構成可能であることを許容することです。 モバイルノードの到着によって制御されて、Configurabilityがダイナミックでないと予想されます。 しかし、むしろ、構成がスケールにおいてルーティングに構成と同様であると予想されます。 NETLMMプロトコルはデフォルト推進メカニズムを指定するかもしれません。 また、追加仕事が特定の推進メカニズムとNETLMMプロトコルとの相互作用を指定するのに必要であるのも、可能ですが、この仕事はNETLMMベースプロトコルの範囲にありません。
4. Security Considerations
4. セキュリティ問題
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.
ネットワークを拠点とするローカライズしている移動性管理にかかわる2種類の安全保障問題があります: モバイルノードとネットワークの間のセキュリティ、およびNETLMMプロトコルに参加するネットワーク要素の間のセキュリティ。 セクション3.3と3.5で説明されたこのドキュメントのセキュリティ関連の目標は前者に焦点を合わせます、それらがネットワークを拠点とする移動性管理にユニークであるので。 脅威解析書[2]は両方の種類の脅威の、より詳細な議論を含んでいます。(プロトコルデザインは脅威を扱わなければなりません)。
5. Acknowledgements
5. 承認
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、およびフレッド・テンプリン。
Kempf Informational [Page 11] RFC 4831 NETLMM Goals April 2007
[11ページ]RFC4831NETLMM目標2007年4月の情報のケンフ
6. Normative References
6. 引用規格
[1] Kempf, J., Ed., "Problem Statement for Network-Based Localized
Mobility Management (NETLMM)", RFC 4830, April 2007.
[1] ケンフ、J.、エド、「ネットワークを拠点とするローカライズしている移動性管理(NETLMM)のための問題声明」、RFC4830、4月2007日
[2] Vogt, C., and Kempf, J., "Security Threats to Network-Based
Localized Mobility Management (NETLMM)", RFC 4832, April 2007.
2007年4月の[2] フォークト、C.とケンフ、J.、「ネットワークを拠点とするローカライズしている移動性管理(NETLMM)への軍事的脅威」RFC4832。
7. Informative References
7. 有益な参照
[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、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
[4] Carpenter, B., "Architectural Principles of the Internet", RFC
1958, June 1996.
[4] 1996年6月、大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
[5] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
in IPv6", RFC 4135, August 2005.
[5] JHチェ、G.デイリー、「検出の目標は2005年8月にIPv6"、RFC4135で付属をネットワークでつなぎます」。
[6] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
RFC 4555, June 2006.
[6]Eronen、2006年6月のP.、「IKEv2移動性とマルチホーミングプロトコル(MOBIKE)」RFC4555。
[7] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical
Layer (PHY) specifications", IEEE Std. 802.11, 1999.
[7]IEEE、「無線LAN Medium Access Control(MAC)とPhysical Layer(PHY)仕様」、IEEE Std。 802.11, 1999.
[8] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x,
June, 2001.
[8]IEEE、「ポートベースのアクセスコントロール」、IEEE LAN/男性の標準の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"、RFC3775、2004年6月の移動性サポート。」
[10] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[10] 方法とJ.とM.Kojo、「移動性関連用語」、RFC3753、2004年6月。
[11] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.
[11] マスコウィッツ、R.、およびP.Nikander(「ホストのアイデンティティのプロトコルの(クール)のアーキテクチャ」、RFC4423)は2006がそうするかもしれません。
[12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[12] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
4140, August 2005.
[13] ソリマン、H.、Castelluccia、C.、高架鉄道Malki、K.、およびL.Bellier、「階層的なモバイルIPv6移動性管理(HMIPv6)」、RFC4140 2005年8月。
[14] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
そして、[14] ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
Kempf Informational [Page 12] RFC 4831 NETLMM Goals April 2007
[12ページ]RFC4831NETLMM目標2007年4月の情報のケンフ
8. Contributors
8. 貢献者
Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: kleung@cisco.com
レオンシスコシステムズInc.170の西タスマン・Driveケントカリフォルニア95134サンノゼ(米国)はメールされます: kleung@cisco.com
Phil Roberts Motorola Labs Schaumberg, IL USA EMail: phil.roberts@motorola.com
フィルロバーツモトローラ研究室Schaumberg、不-米国はメールされます: 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
勝利西田NTTドコモ株式会社3-5Hikarino-oka、横須賀市神奈川(日本)は以下に電話をします。 +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.ライス・ロモリを通したヘラルドGiarettaテレコムイタリアLab、274 10148トリノイタリア電話: +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
マルコLiebsch NECネットワーク研究所Kurfuersten-原基36 69115ハイデルベルグドイツ電話: +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
ジェームスケンフDoCoMo米国研究室181地下鉄ドライブ、Suite300サンノゼ、カリフォルニア95110米国は以下に電話をします。 +1 4711年の408 451メール: kempf@docomolabs-usa.com
Kempf Informational [Page 13] RFC 4831 NETLMM Goals April 2007
[13ページ]RFC4831NETLMM目標2007年4月の情報のケンフ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kempf Informational [Page 14]
ケンフInformationalです。[14ページ]
一覧
スポンサーリンク
