RFC4886 日本語訳
4886 Network Mobility Support Goals and Requirements. T. Ernst. July 2007. (Format: TXT=29083 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Ernst Request for Comments: 4886 INRIA Category: Informational July 2007
コメントを求めるワーキンググループT.エルンストの要求をネットワークでつないでください: 4886年のINRIAカテゴリ: 情報の2007年7月
Network Mobility Support Goals and Requirements
ネットワーク移動性サポート目標と要件
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
要約
Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such a type of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution.
ダイナミックにネットワークをインターネットに接続するルータが接着点をその結果、インターネットに変えると、前述のネットワークの可到達性が固定インターネットトポロジーと関連して変えられることを引き起こしながら、ネットワークの移動性は起こります。 そのような一種のネットワークがモバイルネットワークと呼ばれます。 適切な手段で、モバイルルータが接着点を変えた後にノードの間でモバイルネットワークに確立されたセッションと世界的なインターネットを維持できます。 このドキュメントは、ネットワーク移動性サポートから予想された目標について概説して、ネモBasic Supportソリューションで満たさなければならない必要条件を定義します。
Ernst Informational [Page 1] RFC 4886 NEMO Goals July 2007
[1ページ]RFC4886ネモ目標2007年7月の情報のエルンスト
Table of Contents
目次
1. Introduction ....................................................2
2. NEMO Working Group Objectives and Methodology ...................3
3. NEMO Support Design Goals .......................................5
3.1. Migration Transparency .....................................5
3.2. Performance Transparency and Seamless Mobility .............5
3.3. Network Mobility Support Transparency ......................5
3.4. Operational Transparency ...................................5
3.5. Arbitrary Configurations ...................................5
3.6. Local Mobility and Global Mobility .........................6
3.7. Scalability ................................................7
3.8. Backward Compatibility .....................................7
3.9. Secure Signaling ...........................................7
3.10. Location Privacy ..........................................8
3.11. IPv4 and NAT Traversal ....................................8
3.12. Minimal Impact on Internet Routing ........................8
4. NEMO Basic Support One-Liner Requirements .......................8
5. Security Considerations ........................................10
6. Acknowledgments ................................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
1. 序論…2 2. ネモワーキンググループObjectivesと方法論…3 3. ネモサポートデザイン目標…5 3.1. 移行透明…5 3.2. パフォーマンス透明とシームレスの移動性…5 3.3. 移動性サポート透明をネットワークでつないでください…5 3.4. 操作上の透明…5 3.5. 任意の構成…5 3.6. 地方の移動性とグローバルな移動性…6 3.7. スケーラビリティ…7 3.8. 後方の互換性…7 3.9. シグナリングを保証してください…7 3.10. 位置のプライバシー…8 3.11. IPv4とNAT縦断…8 3.12. インターネットルート設定での最小量の影響…8 4. ネモBasicのサポート寸言要件…8 5. セキュリティ問題…10 6. 承認…11 7. 参照…11 7.1. 標準の参照…11 7.2. 有益な参照…11
1. Introduction
1. 序論
Network mobility support (see [1] for the related terminology) is concerned with managing the mobility of an entire network, viewed as a single unit that changes its point of attachment to the Internet and thus its reachability in the Internet topology. Such a network is referred to as a mobile network and includes one or more mobile routers (MRs), which connect it to the global Internet. Nodes behind the MR(s) (MNNs) are both fixed (LFNs) and mobile (VMNs or LMNs). In most cases, the internal structure of the mobile network will be relatively stable (no dynamic change of the topology), but this is not always true.
それがインターネットトポロジーで接着点をインターネットとその結果、その可到達性に変えることをネットワーク移動性サポート(関連用語のための[1]を見る)を単一の単位として見なされた全体のネットワークの移動性を管理するのに心配させます。 そのようなネットワークは、世界的なインターネットにモバイルネットワークと呼ばれて、1つ以上のモバイルルータ(MRs)を含んでいます。(ルータはそれを接続します)。 MR(s)(MNNs)の後ろのノード、固定されていて、かつ(LFNs)モバイルです(VMNsかLMNs)。 多くの場合、モバイルネットワークの内部の構造は比較的堅固になるでしょうが(トポロジーのダイナミックな変化がありません)、これはいつも本当であるというわけではありません。
Cases of mobile networks include, for instance:
例えば、モバイルネットワークに関するケースは以下を含んでいます。
o Networks attached to people (Personal Area Networks or PANs): a
cell phone with one cellular interface and one Bluetooth interface
together with a Bluetooth-enabled PDA constitute a very simple
instance of a mobile network. The cell phone is the mobile router
while the PDA is used for web browsing or runs a personal web
server.
o ネットワークは人々(パーソナル・エリア・ネットワークかPANs)に付きました: 1つのセルインタフェースがある携帯電話と1つのブルートゥースインタフェースがブルートゥースで可能にされたPDAと共にモバイルネットワークの非常に簡単なインスタンスを構成します。 PDAは、ウェブ閲覧に使用されるか、または個人的なウェブサーバーを実行しますが、携帯電話はモバイルルータです。
Ernst Informational [Page 2] RFC 4886 NEMO Goals July 2007
[2ページ]RFC4886ネモ目標2007年7月の情報のエルンスト
o Networks of sensors and computers deployed in vehicles: vehicles
are increasingly equipped with a number of processing units for
safety and ease of driving reasons, as advocated by ITS
(Intelligent Transportation Systems) applications ([4]).
o センサとコンピュータのネットワークは車で展開しました: 車両は安全のためにますます多くの処理装置を備えています、そして、運転する容易さは推論します、ITS(知的なTransportation Systems)アプリケーション([4])で提唱されるように。
o Access networks deployed in public transportation (buses, trains,
taxis, aircrafts): they provide Internet access to IP devices
carried by passengers (laptop, camera, mobile phone); host
mobility within network mobility or PANs; network mobility within
network mobility, i.e., nested mobility (see [1] for the
definition of nested mobility).
o アクセスネットワークは、輸送が(バス、列車、タクシー、aircrafts)であると公然と配布しました: 彼らは乗客(ラップトップ、カメラ、モバイル電話)によって運ばれたIPデバイスへのインターネット・アクセスを提供します。 ネットワークの移動性かPANsの中で移動性を接待してください。 すなわち、ネットワークの移動性、入れ子にされた移動性の中で移動性をネットワークでつないでください(入れ子にされた移動性の定義のための[1]を見てください)。
o Ad-hoc networks connected to the Internet via an MR: for instance,
students in a train who need to both set up an ad-hoc network
among themselves and get Internet connectivity through the MR
connecting the train to the Internet.
o 臨時のネットワークはMRを通してインターネットに接続しました: 例えば、列車の必要がある学生の両方が、自分たちの中に臨時のネットワークを設立して、列車をインターネットに接続するMRにインターネットの接続性を通します。
Mobility of networks does not cause MNNs to change their own physical point of attachment; however, they do change their topological location with respect to the global Internet. If network mobility is not explicitly supported by some mechanisms, the mobility of the MR results in MNNs losing Internet access and breaking ongoing sessions between arbitrary correspondent nodes (CNs) in the global Internet and those MNNs located within the mobile network. In addition, the communication path between MNNs and correspondent nodes becomes sub- optimal, and multiple levels of mobility will cause extremely sub- optimal routing.
ネットワークの移動性で、MNNsはそれら自身の物理的な接着点を変えません。 しかしながら、彼らは世界的なインターネットに関して自分達の位相的な位置を変えます。 ネットワークの移動性がいくつかのメカニズムによって明らかにサポートされないなら、世界的なインターネットとそれらのMNNsの任意の通信員ノードの間のMNNsの損をしているインターネット・アクセスと壊れている進行中のセッション(CNs)における、MR結果の移動性はモバイルネットワークの中で場所を見つけられました。 さらに、MNNsと通信員ノードの間の通信路はサブ最適になります、そして、複数のレベルの移動性は非常にサブ最適ルーティングで引き起こされるでしょう。
Mobility-related terms used in this document are defined in [2], whereas terms specifically pertaining to network mobility are defined in [1]. This document is structured as follows: in Section 2, we define the rough objectives and methodology of the NEMO working group to handle network mobility issues and we emphasize the stepwise approach the working group has decided to follow. A number of desirable design goals are listed in Section 3. Those design goals then serve as guidelines to define the requirements listed in Section 4 for basic network mobility support [3].
本書では使用される移動性関連の用語は[2]で定義されますが、明確にネットワークの移動性に関係する用語が[1]で定義されます。 このドキュメントは以下の通り構造化されます: セクション2では、私たちはネットワーク移動性問題を扱うためにネモワーキンググループの荒い目的と方法論を定義します、そして、ワーキンググループが続くと決めた徐々にアプローチを強調します。 多くの望ましいデザイン目標がセクション3に記載されています。 そして、要件を定義するガイドラインがリストアップされたようにそれらのデザイン目標は基本的なネットワーク移動性サポート[3]のためのセクション4に勤めます。
2. NEMO Working Group Objectives and Methodology
2. ネモワーキンググループObjectivesと方法論
The mechanisms required for handling network mobility issues were lacking within the IETF standards when the NEMO working group (WG) was set up at the IETF in 2002. At that time, work conducted on mobility support (particularly in the Mobile IP working group) was to provide continuous Internet connectivity and optimal routing to mobile hosts only (host mobility support). Such mechanisms specified
ネモワーキンググループ(WG)が2002年にIETFに設定されたとき、メカニズムが問題がIETF規格の中で欠いていた取り扱いネットワークの移動性に必要です。 その時、移動性サポート(特にモバイルIPワーキンググループにおける)のときに行われた仕事はモバイルホストだけ(ホスト移動性サポート)に連続したインターネットの接続性と最適ルーティングを提供することでした。 そのようなメカニズムは指定しました。
Ernst Informational [Page 3] RFC 4886 NEMO Goals July 2007
[3ページ]RFC4886ネモ目標2007年7月の情報のエルンスト
in Mobile IPv6 [5] are unable to support network mobility. The NEMO working group has therefore been set up to deal with issues specific to network mobility.
モバイルでは、IPv6[5]はネットワークの移動性をサポートすることができません。 したがって、ネモワーキンググループは、ネットワークの移動性に特定の問題に対処するために設立されました。
The primary objective of the NEMO work is to specify a solution that allows mobile network nodes (MNNs) to remain connected to the Internet and continuously reachable while the mobile router serving the mobile network changes its point of attachment. The secondary goal of the work is to investigate the effects of network mobility on various aspects of Internet communication such as routing protocol changes, implications of real-time traffic and fast handovers, and optimizations. This should support the primary goal of reachability for mobile network nodes. Security is an important consideration too, and efforts should be made to use existing security solutions if they are appropriate. Although a well-designed solution may include security inherent in other protocols, mobile networks also introduce new challenges.
ネモ仕事の主目的はモバイルネットワークに役立つモバイルルータが接着点を変えますが、モバイルネットワークノード(MNNs)がインターネットに関連していて絶え間なく届いたままで残ることができるソリューションを指定することです。 仕事のセカンダリ目標はインターネット通信のルーティング・プロトコル変化などの種々相、リアルタイムのトラフィック、速い身柄の引き渡し、および最適化の含意へのネットワークの移動性の効果を調査することです。 これはモバイルネットワークノードのために可到達性のプライマリ目標をサポートするべきです。 また、セキュリティは重要な考慮すべき事柄です、そして、それらが適切であるなら、取り組みは既存のセキュリティソリューションを使用させられるべきです。 よく設計されたソリューションは他のプロトコルに固有のセキュリティを含むかもしれませんが、また、モバイルネットワークは新しい挑戦を導入します。
To complete these tasks, the NEMO working group has decided to take a stepwise approach. The steps in this approach include standardizing a basic solution to preserve session continuity (NEMO Basic Support, see [3]) and studying the possible approaches and issues with providing more optimal routing with potentially nested mobile networks (NEMO Extended Support, see [6] and [7] for a discussion on routing optimization issues and [8] for a discussion on multihoming issues). However, the working group is not chartered to actually standardize a solution for Extended Support at this point in time. If deemed necessary, the working group will be rechartered based on the conclusions of the discussions.
これらのタスクを完成するために、ネモワーキンググループは、徐々にアプローチを取ると決めました。 このアプローチにおけるステップは、セッションの連続を保存するために基本解決法を標準化するのを含んでいます。(ネモBasic Support、[3])と潜在的に入れ子にされたモバイルネットワークをより最適のルーティングに提供する可能なアプローチと問題を研究するのを見てください(ネモExtended Support、議論のためのルーティング最適化問題の[6]と[7]と議論のためのマルチホーミング問題の[8]を見てください)。 しかしながら、ワーキンググループは、この時点でExtended Supportのために実際にソリューションを標準化するためにチャーターされません。 必要であると考えられると、ワーキンググループは議論の結論に基づいて「再-特許」でしょう。
For NEMO Basic Support, the working group assumes that none of the nodes behind the MR is aware of the network's mobility; thus, the network's movement needs to be completely transparent to the nodes inside the mobile network. This assumption accommodates nodes inside the network that are not generally aware of mobility.
ネモBasic Supportに関しては、ワーキンググループは、MRの後ろのノードのいずれもネットワークの移動性を意識していないと仮定します。 したがって、ネットワークの動きは、モバイルネットワークの中でノードに完全に透明である必要があります。 この仮定はネットワークにおける一般に、移動性を意識していないノードに対応します。
The efforts of the Mobile IP working group have resulted in the Mobile IPv4 and Mobile IPv6 protocols, which have already solved the issue of host mobility support. Since challenges to enabling mobile networks are vastly reduced by this work, basic network mobility support has adopted the methods for host mobility support used in Mobile IP and has extended them in the simplest way possible to achieve its goals. The Basic Support solution, now defined in [3] following the requirements stated in Section 4 of the present document, is for each MR to have a Home Agent (HA), and use bi- directional tunneling between the MR and HA to preserve session continuity while the MR moves. The MR acquires a Care-of Address (CoA) at its attachment point much like what is done for mobile hosts
モバイルIPワーキンググループの取り組みはモバイルIPv4とモバイルIPv6プロトコルをもたらしました。(既に、プロトコルはホスト移動性サポートの問題を解決しました)。 モバイルネットワークを可能にすることへの挑戦がこの仕事で広大に抑えられるので、基本的なネットワーク移動性サポートは、サポートがモバイルIPに使用したホストの移動性のために方法を採って、目的を果たすために可能な最も簡単な方法でそれらを広げました。 現在のドキュメントのセクション4に述べられた要件に続いて、現在[3]で定義されたBasic Supportソリューションは、MRが移行している間、各MRが保護区セッションの連続にホームエージェント(HA)を持って、MRとHAの間の両性愛者の方向のトンネリングを使用することです。 MRがaを取得する、Care、-、モバイルホストのために行われることのような付着点のAddress(CoA)
Ernst Informational [Page 4] RFC 4886 NEMO Goals July 2007
[4ページ]RFC4886ネモ目標2007年7月の情報のエルンスト
(MHs), using Mobile IP. This approach allows nested mobile networks, since each MR will appear to its attachment point as a single node.
モバイルIPを使用する(MHs。) 各MRがただ一つのノードとして付着点に見えるので、このアプローチは入れ子にされたモバイルネットワークを許容します。
3. NEMO Support Design Goals
3. ネモサポートデザイン目標
This section details the fundamental design goals the solutions will intend to achieve. Those design goals serve to define the issues and to impose a list of requirements for forthcoming solutions. Actual requirements for NEMO Basic Support are in Section 4; NEMO Extended Support is not yet considered at the time of this writing.
このセクションはソリューションが達成するつもりである基本的なデザイン目標を詳しく述べます。 それらのデザイン目標は争点を明確にして、今度のソリューションのための要件のリストを課すのに役立ちます。 ネモBasic Supportのための実需がセクション4にあります。 ネモExtended Supportはこの書くこと時点で、まだ考えられていません。
3.1. Migration Transparency
3.1. 移動透過性
Permanent connectivity to the Internet has to be provided to all MNNs, since continuous sessions are expected to be maintained as the mobile router changes its point of attachment. For maintaining those sessions, MNNs are expected to be reachable via their permanent IP addresses.
インターネットへの永久的な接続性をすべてのMNNsに提供しなければなりません、モバイルルータが接着点を変えるので継続的商いが維持されると予想されて。 それらのセッションを維持するのにおいて、MNNsが彼らの永久的なIPアドレスで届くと予想されます。
3.2. Performance Transparency and Seamless Mobility
3.2. パフォーマンス透明とシームレスの移動性
NEMO support is expected to be provided with limited signaling overhead and to minimize the impact of handovers on applications, in terms of packet loss or delay. However, although variable delays of transmission and losses between MNNs and their respective CNs could be perceived as the network is displaced, it would not be considered a lack of performance transparency.
ネモサポートは、限られたシグナリングオーバーヘッドを提供して、アプリケーションのときに身柄の引き渡しの影響を最小にすると予想されます、パケット損失か遅れに関して。 しかしながら、ネットワークが置き換えられるのに従って、MNNsと彼らのそれぞれのCNsの間のトランスミッションと損失の可変遅れを知覚できましたが、それは性能透明の不足であると考えられないでしょう。
3.3. Network Mobility Support Transparency
3.3. ネットワーク移動性サポート透明
MNNs behind the MR(s) do not change their own physical point of attachment as a result of the mobile network's displacement in the Internet topology. Consequently, NEMO support is expected to be performed only by the MR(s). Specific support functions on any node other than the MR(s) would better be avoided.
MR(s)の後ろのMNNsはインターネットトポロジーのモバイルネットワークの置換えの結果、それら自身の物理的な接着点を変えません。 その結果、ネモサポートは単にMR(s)によって実行されると予想されます。 MR(s)以外のどんなノードの特定の支援機能も避けられるほうがよいでしょう。
3.4. Operational Transparency
3.4. 操作上の透明
NEMO support is to be implemented at the level of IP layer. It is expected to be transparent to upper layers so that any upper-layer protocol can run unchanged on top of an IP layer extended with NEMO support.
ネモサポートはIP層のレベルで実装されることです。 それがどんな上側の層のプロトコルもネモサポートで広げられたIP層の上で変わりがない状態で稼働できるくらい上側の層に透明であると予想されます。
3.5. Arbitrary Configurations
3.5. 任意の構成
The formation of a mobile network can occur in various levels of complexity. In the simplest case, a mobile network contains just a mobile router and a host. In the most complicated case, a mobile
モバイルネットワークの構成は様々なレベルの複雑さで起こることができます。 最も簡単な場合では、モバイルネットワークはまさしくモバイルルータとホストを含みます。 最も複雑なケース、モバイルで
Ernst Informational [Page 5] RFC 4886 NEMO Goals July 2007
[5ページ]RFC4886ネモ目標2007年7月の情報のエルンスト
network is multihomed and is itself a multi-level aggregation of mobile networks with collectively thousands of mobile routers and hosts. While the list of potential configurations of mobile networks cannot be limited, at least the following ones are desirable:
ネットワークが「マルチ-家へ帰」って、それ自体でモバイルネットワークのマルチレベル集合である、まとめ、何千人ものモバイルルータとホスト。 モバイルネットワークの潜在的構成のリストを制限できませんが、少なくとも以下のものは望ましいです:
o Mobile networks of any size, ranging from a sole subnet with a few
IP devices to a collection of subnets with a large number of IP
devices.
o いくつかのIPデバイスがある唯一のサブネットから多くのIPデバイスによるサブネットの収集まで及ぶどんなサイズのモバイルネットワーク。
o Nodes that change their point of attachment within the mobile
network.
o モバイルネットワークの中でそれらの接着点を変えるノード。
o Foreign mobile nodes that attach to the mobile network.
o モバイルネットワークに付く外国モバイルノード。
o Multihomed mobile network: either when a single MR has multiple
attachments to the internet, or when the mobile network is
attached to the Internet by means of multiple MRs (see definition
in [1] and the analysis in [8]).
o Multihomedモバイルネットワーク: 独身のMRであるときに、どちらかがインターネットかそれともモバイルネットワークがいつ複数のMRsによってインターネットに付けられるかに複数の付属を持っています。([8])で[1]との定義と分析を見てください。
o Nested mobile networks (mobile networks attaching to other mobile
networks (see definition in [1]). Although the complexity
requirements of these nested networks are not clear, it is
desirable to support arbitrary levels of recursive networks. The
solution should only impose restrictions on nesting (e.g., path
MTU) when this is impractical and protocol concerns preclude such
support.
o モバイルは他のモバイルネットワークへの付けをネットワークでつなぎます。[1])との定義を見てください。これらの入れ子にされたネットワークの複雑さ要件は明確ではありませんが、任意のレベルの再帰的なネットワークをサポートするのは望ましいです。モバイルネットワークが入れ子にした、((ソリューションはこれが非実用的であり、プロトコル関心がそのようなサポートを排除する巣篭もり(例えば、経路MTU)に制限を課すだけであるべきです。
o Distinct mobility frequencies (see mobility factor in [2]).
o 異なった移動性頻度、([2])の移動性要素を見てください。
o Distinct access media.
o 異なったアクセスメディア。
In order to keep complexity minimal, transit networks are excluded from this list. A transit network is one in which data would be forwarded between two endpoints outside of the network, so that the network itself simply serves as a transitional conduit for packet forwarding. A stub network (leaf network), on the other hand, does not serve as a data forwarding path. Data on a stub network is either sent by or addressed to a node located within that network.
複雑さを最小量に保つために、輸送網はこのリストから除かれます。 トランジットネットワークはデータがネットワークの外で2つの終点の間に転送されるものです、ネットワーク自体がパケット推進のための過渡的な経路として単に機能するように。 他方では、スタッブネットワーク(葉のネットワーク)はデータ推進経路として機能しません。 スタッブネットワークに関するデータはネットワークに、発信するか、またはそれの中に位置したノードに演説します。
3.6. Local Mobility and Global Mobility
3.6. 地方の移動性とグローバルな移動性
Mobile networks and mobile nodes owned by different administrative entities are expected to be displaced within a domain boundary or between domain boundaries. Multihoming, vertical and horizontal handoffs, and access control mechanisms are desirable to achieve this goal. Such mobility is not expected to be limited for any consideration other than administrative and security policies.
異なった管理実体によって所有されていたモバイルネットワークとモバイルノードによってドメイン境界以内かドメイン境界の間に置き換えられると予想されます。 マルチホーミング、垂直で水平なhandoffs、およびアクセス管理機構はこの目標を達成するのにおいて望ましいです。 管理を除いたどんな考慮と安全保障政策のためにもそのような移動性が制限されないと予想されます。
Ernst Informational [Page 6] RFC 4886 NEMO Goals July 2007
[6ページ]RFC4886ネモ目標2007年7月の情報のエルンスト
3.7. Scalability
3.7. スケーラビリティ
NEMO support signaling and processing is expected to scale to a potentially large number of mobile networks irrespective of their configuration, mobility frequency, size, and number of CNs.
ネモサポートシグナリングと処理がCNsのそれらの構成、移動性頻度、サイズ、および数の如何にかかわらず潜在的に多くのモバイルネットワークに比例すると予想されます。
3.8. Backward Compatibility
3.8. 後方の互換性
NEMO support will have to co-exist with established IPv6 standards and not interfere with them. Standards defined in other IETF working groups have to be reused as much as possible and extended only if deemed necessary. For instance, the following mechanisms defined by other working groups are expected to function without modification:
ネモサポートは、確立したIPv6規格と共存して、それらを妨げる必要はないでしょう。 必要であると考えられる場合にだけ、他のIETFワーキンググループで定義された規格は、できるだけ再利用されて、広げられなければなりません。 例えば、他のワーキンググループによって定義された以下のメカニズムが変更なしで機能すると予想されます:
o Address allocation and configuration mechanisms.
o 配分と構成メカニズムを扱ってください。
o Host mobility support: mobile nodes and correspondent nodes,
either located within or outside the mobile network, are expected
to continue operating protocols defined by the Mobile IP working
group. This includes mechanisms for host mobility support (Mobile
IPv6) and seamless mobility (FMIPv6).
o 移動性サポートを主催してください: モバイルネットワーク以内かモバイルネットワークの外に位置しているモバイルノードと通信員ノードが、モバイルIPワーキンググループによって定義されたプロトコルを操作し続けていると予想されます。 これはホスト移動性サポート(モバイルIPv6)とシームレスの移動性(FMIPv6)のためのメカニズムを含んでいます。
o Multicast support intended for MNNs is expected to be maintained
while the mobile router changes its point of attachment.
o モバイルルータが接着点を変えている間、MNNsのために意図するマルチキャストサポートが維持されると予想されます。
o Access control protocols and mechanisms used by visiting mobile
hosts and routers to be authenticated and authorized, gaining
access to the Internet via the mobile network infrastructure
(MRs).
o 認証されて、認可されるためにモバイルホストとルータを訪問することによって使用される制御プロトコルとメカニズムにアクセスしてください、モバイルネットワークインフラストラクチャ(MRs)でインターネットへのアクセスを得て。
o Security protocols and mechanisms.
o セキュリティプロトコルとメカニズム。
o Mechanisms performed by routers deployed in both visited networks
and mobile networks (routing protocols, Neighbor Discovery, ICMP,
Router Renumbering).
o 両方で配布されたルータによって実行されたメカニズムはネットワークとモバイルネットワーク(ルーティング・プロトコル、Neighborディスカバリー、ICMP、Router Renumbering)を訪問しました。
3.9. Secure Signaling
3.9. 安全なシグナリング
NEMO support will have to comply with the usual IETF security policies and recommendations and is expected to have its specific security issues fully addressed. In practice, all NEMO support control messages transmitted in the network will have to be protected with an acceptable level of security to prevent intruders from usurping identities and forge data. Specifically, the following issues have to be considered:
ネモサポートは、普通のIETF安全保障政策と推薦に従わなければならなくて、特定の安全保障問題を完全に扱わせると予想されます。 実際には、ネットワークで送られたすべてのネモサポートコントロールメッセージが合格水準のセキュリティで保護されて、侵入者がアイデンティティを僣称するのを防いで、データを作り出さなければならないでしょう。 明確に、以下の問題は考えられなければなりません:
o Authentication of the sender to prevent identity usurpation.
o アイデンティティ強奪を防ぐ送付者の認証。
Ernst Informational [Page 7] RFC 4886 NEMO Goals July 2007
[7ページ]RFC4886ネモ目標2007年7月の情報のエルンスト
o Authorization, to make sure the sender is granted permission to
perform the operation as indicated in the control message.
o コントロールメッセージにみられるように操作を実行する許可を承認、念のため送付者に与えます。
o Confidentiality of the data contained in the control message.
o コントロールメッセージに含まれたデータの秘密性。
3.10. Location Privacy
3.10. 位置のプライバシー
Location privacy means hiding the actual location of MNN to third parties other than the HA are desired. It is not clear to which extend this has to be enforced, since it is always possible to determine the topological location by analyzing IPv6 headers. It would thus require some kind of encryption of the IPv6 header to prevent third parties from monitoring IPv6 addresses between the MR and the HA. On the other hand, it is at the very least desirable to provide a means for MNNs to hide their real topological location to their CNs.
HA以外の第三者にMNNの実際の場所を隠す位置のプライバシー手段が望まれています。 これがどれが広がっているかに実施されなければならないかは、明確ではありません、IPv6ヘッダーを分析することによって位相的な位置を決定するのがいつも可能であるので。 その結果、第三者がMRとHAの間のIPv6アドレスをモニターするのを防ぐのがIPv6ヘッダーのある種の暗号化を必要とするでしょう。 他方では、MNNsが彼らの全く位相的な位置を彼らのCNsに隠す手段を提供するのは少なくとも望ましいです。
3.11. IPv4 and NAT Traversal
3.11. IPv4とNAT縦断
IPv4 clouds and NAT are likely to co-exist with IPv6 for a long time, so it is desirable to ensure that mechanisms developed for NEMO will be able to traverse such clouds.
IPv4雲とNATが長い間IPv6と共存しそうであるので、ネモのために開発されたメカニズムがそのような雲を横断できるのを保証するのは望ましいです。
3.12. Minimal Impact on Internet Routing
3.12. インターネットルート設定での最小量の影響
Any NEMO solution needs have minimal negative effect on the global Internet routing system. The solution must therefore limit both the amount of information that must be injected into Internet routing, as well as the dynamic changes in the information that is injected into the global routing system.
どんなネモソリューションの必要性も世界的なインターネットルーティングシステムに最小量のマイナスの効果を持っています。 したがって、ソリューションはインターネット・ルーティングに注がなければならない情報量とグローバルなルーティングシステムに注がれる情報におけるダイナミックな変化の両方を制限しなければなりません。
As one example of why this is necessary, consider the approach of advertising each mobile network's connectivity into BGP and, for every movement, withdrawing old routes and injecting new routes. If there were tens of thousands of mobile networks each advertising and withdrawing routes, for example, at the speed that an airplane can move from one ground station to another, the potential effect on BGP could be very unfortunate. In this example, the total amount of routing information advertised into BGP may be acceptable, but the dynamic instability of the information (i.e., the number of changes over time) would be unacceptable.
これが必要である理由に関する1つの例と、あらゆる動きのために各モバイルネットワークの接続性のBGPに広告を出して、古いルートを引っ込めて、新しいルートを注入するアプローチを考えてください。 例えば、飛行機が1つの地上局から別の地上局まで動かすことができる速度でそれぞれルートを広告を出して、引っ込める何万ものモバイルネットワークがあれば、BGPへの潜在的効果は非常に不運であるかもしれないでしょうに。 この例では、BGPに広告に掲載されたルーティング情報の総量は許容できるかもしれませんが、情報(すなわち、時間がたつにつれての変化の数)の慣性不安定は容認できないでしょう。
4. NEMO Basic Support One-Liner Requirements
4. ネモBasicのサポート寸言要件
For basic network mobility support, the NEMO WG is to specify a unified and unique "Network Mobility (NEMO) Basic Support" solution, hereafter referred to as "the solution". This solution is to allow all nodes in the mobile network to be reachable via permanent IP
基本的なネットワーク移動性サポートとして、NEMO WGは今後「ソリューション」と呼ばれた統一されてユニークな「ネットワークの移動性(ネモ)の基本的なサポート」ソリューションを指定することになっています。 このソリューションはモバイルネットワークにおけるすべてのノードが永久的なIPを通して届いているのを許容することです。
Ernst Informational [Page 8] RFC 4886 NEMO Goals July 2007
[8ページ]RFC4886ネモ目標2007年7月の情報のエルンスト
addresses, as well as maintain ongoing sessions as the MR changes its point of attachment to the Internet topology. This is to be done by maintaining a bi-directional tunnel between an MR and its Home Agent.
また、MRが接着点をインターネットトポロジーに変えるとき進行中のセッションを維持するとき、扱います。 MRとそのホームのエージェントの間の双方向のトンネルを維持することによって、これをすることになっています。
The NEMO Working Group, after some investigation of alternatives, has decided to reuse and extend the existing Mobile IPv6 [5] mechanisms for tunnel management.
ネモ作業部会は、代替手段の何らかの調査の後にトンネル管理のために既存のモバイルIPv6[5]メカニズムを再利用して、広げると決めました。
The list of requirements below has been imposed on the NEMO Basic Support solution. The requirements have mostly been met by the resulting specification, which can now be found in [3]. Associated deployment issues are discussed in [9].
以下の要件のリストはネモBasic Supportソリューションに課されました。 結果として起こる仕様で必要条件をほとんど満たしました。(今、[3]でそれを見つけることができます)。 [9]で関連展開問題について議論します。
R01: The solution must be implemented at the IP layer level.
R01: IP層のレベルでソリューションを実現しなければなりません。
R02: The solution must set up a bi-directional tunnel between a
mobile router and its Home Agent (MRHA tunnel).
R02: ソリューションはモバイルルータとそのホームのエージェントの間の双方向のトンネルを設立しなければなりません(MRHAはトンネルを堀ります)。
R03: All traffic exchanged between an MNN and a CN in the global
Internet must transit through the bi-directional MRHA tunnel.
R03: 世界的なインターネットのMNNとCNの間で交換されたすべてのトラフィックは双方向のMRHAトンネルを通るトランジットがそうしなければなりません。
R04: MNNs must be reachable at a permanent IP address and name.
R04: MNNsは永久的なIPアドレスと名前で届いているに違いありません。
R05: The solution must maintain continuous sessions (both unicast and
multicast) between MNNs and arbitrary CNs after IP handover of
(one of) the MRs.
R05: ソリューションが、IP引き渡しの後に継続的商いがMNNsと任意のCNsの間の(ユニキャストとマルチキャストの両方)であると主張しなければならない、(1つ、)、MRs。
R06: The solution must not require modifications to any node other
than MRs and HAs.
R06: ソリューションはMRsとHAs以外のどんなノードへの変更も必要としてはいけません。
R07: The solution must support fixed nodes, mobile hosts, and mobile
routers in the mobile network.
R07: ソリューションはモバイルネットワークで固定ノード、モバイルホスト、およびモバイルルータをサポートしなければなりません。
R08: The solution must allow MIPv6-enabled MNNs to use a mobile
network link as either a home link or a foreign link.
R08: ソリューションで、MIPv6によって可能にされたMNNsはホームのリンクか外国リンクのどちらかとしてモバイルネットワークリンクを使用できなければなりません。
R09: The solution must ensure backward compatibility with other
standards defined by the IETF. In particular, this includes the
following:
R09: ソリューションはIETFによって定義される他の規格との後方の互換性を確実にしなければなりません。 特に、これは以下を含んでいます:
R09.1: The solution must not prevent the proper operation of
Mobile IPv6 (i.e., the solution must allow MIPv6-enabled
MNNs to operate either the CN, HA, or MN operations
defined in [5]).
R09.1: ソリューションはモバイルIPv6の適切な操作を防いではいけません。(すなわち、ソリューションは、MIPv6によって可能にされたMNNsが[5])で定義されたCN、HA、またはミネソタの操作を操作するのを許容しなければなりません。
Ernst Informational [Page 9] RFC 4886 NEMO Goals July 2007
[9ページ]RFC4886ネモ目標2007年7月の情報のエルンスト
R10: The solution must be agnostic to the internal configuration.
This means the solution will behave the same way if NEMO is
nested, comprises one or several subnets, or comprises MNNs that
are LFNs, VMNs, LFNs or a mixture of them.
R10: ソリューションは内部の構成に不可知論者であるに違いありません。 これは、ソリューションがネモが入れ子にされると同じように振る舞うか、1かいくつかのサブネットを含むか、または彼らのLFNs、VMNs、LFNsまたは混合物であるMNNsを包括することを意味します。
R11: The solution must support at least 2 levels of nested mobile
networks, while, in principle, arbitrary levels of recursive
mobile networks should be supported.
R11: ソリューションは少なくとも2つのレベルの入れ子にされたモバイルネットワークをサポートしなければなりません、任意のレベルの再帰的なモバイルネットワークが原則としてサポートされるべきですが。
R12: The solution must function for multihomed MRs and multihomed
mobile networks as defined in [1].
R12: ソリューションはmultihomed MRsと「マルチ-家へ帰」っているモバイルネットワークのために[1]で定義されるように機能しなければなりません。
R13: NEMO support signaling over the bi-directional must be
minimized.
R13: 双方向の上で合図するネモサポートを最小にしなければなりません。
R14: Signaling messages between the HA and the MR must be secured:
R14: HAとMRの間のシグナリングメッセージを保証しなければなりません:
R14.1: The receiver must be able to authenticate the sender.
R14.1: 受信機は送付者を認証できなければなりません。
R14.2: The function performed by the sender must be authorized
for the content carried.
R14.2: 運ばれた内容のために送付者によって実行された機能を認可しなければなりません。
R14.3: Anti-replay must be provided.
R14.3: 反再生を提供しなければなりません。
R14.4: The signaling messages may be encrypted.
R14.4: シグナリングメッセージは暗号化されるかもしれません。
R15: The solution must ensure transparent continuation of routing and
management operations over the bi-directional tunnel (this
includes, e.g., unicast and multicast routing protocols, router
renumbering, Dynamic Host Configuration Protocol (DHCPv6)).
R15: ソリューションは双方向のトンネル(このインクルードと例えば、ユニキャストとマルチキャストルーティング・プロトコル、ルータの番号を付け替えるDynamic Host Configuration Protocol(DHCPv6))の上のルーティングと管理操作のわかりやすい継続を確実にしなければなりません。
R16: When one egress interface fails, the solution may preserve
sessions established through another egress interface.
R16: 1つの出口のインタフェースが失敗すると、ソリューションは別の出口のインタフェースを通して確立されたセッションを保存するかもしれません。
R17: The solution should have a minimal impact on the global Internet
routing system.
R17: ソリューションは世界的なインターネットルーティングシステムの上に最小量の影響力を持つべきです。
5. Security Considerations
5. セキュリティ問題
Security considerations of the NEMO Basic Support solution are addressed in [RFC3963].
ネモBasic Supportソリューションのセキュリティ問題は[RFC3963]で扱われます。
Section 3.9 of this document discusses the security goals for all forms of existing and forthcoming NEMO solutions.
このドキュメントのセクション3.9はすべてのフォームの存在と今度のネモソリューションのセキュリティ目標について論じます。
Ernst Informational [Page 10] RFC 4886 NEMO Goals July 2007
[10ページ]RFC4886ネモ目標2007年7月の情報のエルンスト
6. Acknowledgments
6. 承認
The material presented in this document takes most of its text from discussions and previous documents submitted to the NEMO working group. This includes initial contributions from Motorola, INRIA, Ericsson, and Nokia. We are particularly grateful to Hesham Soliman (Ericsson) and the IETF Area Directors (ADs) at the time (Erik Nordmark and Thomas Narten), who greatly helped to set up the NEMO working group. We are also grateful to all the following people whose comments greatly contributed to the present document: T.J. Kniveton (Nokia), Alexandru Petrescu (Motorola), Christophe Janneteau (Motorola), Pascal Thubert (Cisco), Hong-Yon Lach (Motorola), Mattias Petterson (Ericsson), and all the others who have expressed their opinions on the NEMO mailing lists (formerly known as MONET). Thierry Ernst wishes to personally acknowledge INRIA Rhone-Alpes and Motorola Labs Paris for their support and direction in bringing up this topic to the IETF in 2001--particularly Claude Castelluccia (INRIA) and Hong-Yon Lach (Motorola)--and his past employer, Keio University, Japan, which supported most of the costs associated with the IETF during the timelife of previous versions of this document.
本書では寄贈された材料はネモワーキンググループに提出された議論と前のドキュメントからテキストの大部分取ります。 これはモトローラ、INRIA、エリクソン、およびノキアからの最初の出資を含んでいます。 私たちは特にHeshamソリマン(エリクソン)と当時IETF Areaディレクター(ADs)(エリックNordmarkとトーマスNarten)に感謝しています。(そのディレクターは、ネモワーキンググループを設立するのを大いに助けました)。 また、私たちもコメントが現在のドキュメントに大いに貢献した以下のすべての人々に感謝しています: T.J.Kniveton(ノキア)、Alexandruペトレスク(モトローラ)、クリストフJanneteau(モトローラ)、パスカルThubert(シスコ)、Hong-Yonラック(モトローラ)、マティアス・ペッテルソン(エリクソン)、およびネモメーリングリスト(以前、モネとして知られている)で意見を言ったすべての他のもの。 ティエリー・エルンストは個人的にこのドキュメントの旧バージョンのtimelifeの間、IETFに関連しているコストの大部分をサポートした2001年(特にクロードCastelluccia(INRIA)とHong-Yonラック(モトローラ))にこの話題をIETFに持って来る彼らのサポートと方向と彼の元の雇い主、慶応義塾大学、日本にINRIAローヌアルプとモトローラLabsパリを承認したがっています。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
RFC 4885, July 2007.
[1] エルンストとT.とH.ラック、「ネットワーク移動性サポート用語」、RFC4885、2007年7月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[2] 方法とJ.とM.Kojo、「移動性関連用語」、RFC3753、2004年6月。
[3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[3]Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP.Thubert、「ネットワークの移動性(ネモ)の基本的なサポートプロトコル」、RFC3963、2005年1月。
7.2. Informative References
7.2. 有益な参照
[4] "CALM - Medium and Long Range, High Speed, Air Interfaces
parameters and protocols for broadcast, point to point, vehicle
to vehicle, and vehicle to point communication in the ITS sector
- Networking Protocol - Complementary Element", ISO Draft ISO/WD
21210, February 2005.
[4] 「CALM--媒体とLong Range(放送のためのHigh Speed、Air Interfacesパラメタ、およびプロトコル)はITSセクター--ネットワークプロトコル--補足的なElementのコミュニケーションを指すためにポイント、乗り物への乗り物、および乗り物を示します」、ISO Draft ISO/WD21210、2005年2月。
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[6] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility
Route Optimization Problem Statement", RFC 4888, July 2007.
[6] ウンとC.とThubertとP.と亘理、M.とF.チャオ、「ネットワーク移動性経路最適化問題声明」、RFC4888、2007年7月。
Ernst Informational [Page 11] RFC 4886 NEMO Goals July 2007
[11ページ]RFC4886ネモ目標2007年7月の情報のエルンスト
[7] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility
Route Optimization Solution Space Analysis", RFC 4889, July
2007.
[7] ウン、C.、チャオ、F.、亘理、M.、およびP.Thubertは「移動性経路最適化ソリューション宇宙分析をネットワークでつなぎます」、RFC4889、2007年7月。
[8] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of
Multihoming in Network Mobility Support", Work in Progress),
February 2007.
「ネットワーク移動性サポートにおける、マルチホーミングの分析」というBagnuloが進行中で働かせる[8]ウン、C.、エルンスト、T.、パク、E.、およびM.)、2月2007日
[9] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility
(NEMO) Home Network Models", RFC 4887, July 2007.
[9]Thubert、P.、Wakikawa、R.、およびV.Devarapalli、「ネットワークの移動性(ネモ)ホームネットワークモデル」、RFC4887、2007年7月。
Author's Address
作者のアドレス
Thierry Ernst INRIA INRIA Rocquencourt Domaine de Voluceau B.P. 105 78 153 Le Chesnay Cedex France
ティエリーエルンストINRIA INRIA Rocquencourtドメーヌde Voluceau B.P.105 78 153Le Chesnay Cedexフランス
Phone: +33 1 39 63 59 30 Fax: +33 1 39 63 54 91 EMail: thierry.ernst@inria.fr URI: http://www-rocq.inria.fr/imara
以下に電話をしてください。 +33 1 39 63 59 30、Fax: +33 1 39 63 54 91はメールされます: thierry.ernst@inria.fr ユリ: http://www-rocq.inria.fr/imara
Ernst Informational [Page 12] RFC 4886 NEMO Goals July 2007
[12ページ]RFC4886ネモ目標2007年7月の情報のエルンスト
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機能のための基金は現在、インターネット協会によって提供されます。
Ernst Informational [Page 13]
エルンストInformationalです。[13ページ]
一覧
スポンサーリンク
