Network Working Group T. Ernst
Request for Comments: 4886 INRIA
Category: Informational July 2007
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).
著作権（C）IETFトラスト（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.
ネットワークモビリティは、インターネットにネットワークを接続するルータが動的にそれによって固定インターネットトポロジーに関連して変更されるべき前記ネットワークの到達可能性を引き起こすインターネットへの接続点を変更するときに生じます。ネットワークのようなタイプは、モバイルネットワークと呼ばれます。モバイルルータが接続点を変更した後の適切なメカニズムを用いて、モバイルネットワークとグローバルインターネット内のノード間で確立されたセッションを維持することができます。この文書では、ネットワークモビリティサポートから期待される目標を概説し、NEMOベーシックサポートソリューションによって満たされなければならない要件を定義します。
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
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つまたは複数のモバイルルータ（MRの）が含まれます。 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人（パーソナルエリアネットワークまたはのPAN）に接続されたネットワーク：1つのセルラーインターフェイスを備えた携帯電話と1つのBluetoothインターフェース一緒にBluetooth対応のPDAとは、モバイルネットワークの非常に単純なインスタンスを構成しています。 PDAは、Webブラウジングのために使用したり、個人のWebサーバーを実行している間に携帯電話は、モバイルルータです。
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（高度道路交通システム）の用途が提唱ように車両が増え、安全性及び運転理由を容易にするための処理ユニットの数が装備されている（[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アクセスネットワーク（バス、電車、タクシー、航空機）：彼らは乗客（ノートパソコン、カメラ、携帯電話）によって運ばれるIPデバイスへのインターネットアクセスを提供。ネットワークモビリティかのPAN内のモビリティを開催。ネットワークモビリティ、すなわち、ネストされたモビリティ内のネットワークモビリティ（ネストされた移動度の定義については、[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.
MRを介してインターネットに接続され、Oアドホックネットワーク：自分自身の中でアドホックネットワークをセットアップし、インターネットへの列車の接続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におけるMRの結果のモビリティは、インターネットへのアクセスを失い、グローバルなインターネットで任意の通信相手ノード（CNS）との間で進行中のセッションを破壊し、モバイルネットワーク内に配置されたものをMNNs。また、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].
具体的には、ネットワークモビリティに関係する用語は[1]で定義されているのに対し、本文書で使用モビリティ関連用語は、[2]で定義されています。次のようにこの文書は、構造化されています。第2節では、我々はラフな目標やネットワークモビリティの問題を処理するためにワーキンググループNEMOの方法論を定義し、我々はワーキンググループが従うことを決定した段階的なアプローチを強調する。望ましい設計目標は、第3節に記載されていますこれらの設計目標は、その後、基本的なネットワークモビリティサポートについては、セクション4に記載されている要件を定義するためのガイドラインとしての役割を果たすの番号[3]。
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 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.
NEMOワーキンググループ（WG）は（特にモバイルIPワーキンググループで）仕事はモビリティサポートに行って、その時点で2002年にIETFにして設定されたときに、ネットワークモビリティの問題は、IETF標準の中に欠けていた処理するために必要なメカニズムモバイルホストのみ（ホストモビリティサポート）への継続的なインターネット接続と最適なルーティングを提供します。モバイルIPv6 [5]で指定されたそのようなメカニズムは、ネットワークモビリティをサポートすることができません。 NEMOワーキンググループは、したがって、ネットワークモビリティに固有の問題に対処するように設定されています。
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.
NEMO作業の主な目的は、モバイルネットワークノード（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.
これらのタスクを完了するために、NEMOワーキンググループは、段階的なアプローチを取ることを決定しました。このアプローチにおける工程[6]を参照、セッション継続性（NEMOベーシックサポート、[3]参照）を維持するために塩基性溶液を標準化し、潜在的に階層型移動ネットワークと、より最適なルーティングを提供することの可能なアプローチと問題を研究（NEMO延長サポート含みます及び[7]マルチホーミング問題に関する議論については、最適化問題をルーティングし、[8]上の議論のため）。しかし、ワーキンググループは、実際にはこの時点で延長サポートのためのソリューションを標準化するためにチャーターされていません。必要と認められる場合は、ワーキンググループは、議論の結論に基づいてrecharteredされます。
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.
NEMOベーシックサポートのため、ワーキンググループは、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 (MHs), using Mobile IP. This approach allows nested mobile networks, since each MR will appear to its attachment point as a single node.
モバイルIPワーキンググループの努力は、すでにホストモビリティサポートの問題を解決したモバイルIPv4およびモバイルIPv6プロトコルをもたらしてきました。モバイルネットワークを有効にする課題が大幅にこの作業によって減少しているので、基本的なネットワークモビリティサポートは、モバイルIPで使用されるホストモビリティをサポートするための方法を採用しており、その目標を達成することができ、最も簡単な方法でそれらを拡張しました。基本的なサポートソリューションは、今、[3]本書の第4章で述べた要件を以下に定義されたホームエージェント（HA）を持っている、とのセッションを維持するためにMRとHA間の双方向トンネリングを使用するように各MRのためでありますMRが移動しながら、継続。 MRは、モバイルIPを使用して、モバイルホスト（のMH）のために行われているもののような多くのその取り付け点で気付アドレス（CoA）を取得します。各MRは、単一ノードとしてのアタッチメントポイントに表示されるので、このアプローチは、階層型移動ネットワークを可能にします。
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.
このセクションでは、ソリューションが実現していきます基本的な設計目標を詳述します。これらの設計目標は、問題を定義し、今後のソリューションのための要件のリストを課すのに役立ちます。 NEMOベーシックサポートの実際の要件は、第4節です。 NEMO延長サポートはまだこの記事の執筆時点では考慮されていません。
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アドレス経由で到達可能であることが予想されます。
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.
NEMOサポートが限られたシグナリングオーバーヘッドで提供されると、パケットロスや遅延の点でアプリケーションに対するハンドオーバの影響を最小化することが期待されます。ネットワークが変位するようMNNsとそれぞれのCN間の段変速機の遅延や損失が知覚することができるがしかし、それはパフォーマンスの透明性の欠如とは考えられません。
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は、インターネットトポロジのモバイルネットワークの変位の結果として、添付ファイルの独自の物理的な位置を変更しないでください。従って、NEMOサポートのみMR（単数または複数）によって実行されることが予想されます。 MR（S）以外の任意のノードに固有のサポート機能が良好に回避されることになります。
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.
NEMOのサポートは、IPレイヤのレベルで実装されます。任意の上位層プロトコルは、NEMOのサポートで拡張IP層の上にそのまま実行できるように、上位層に対して透過的であることが期待されます。
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 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.
IPデバイスの数が多いとサブネットのコレクションにいくつかのIPデバイスとの唯一のサブネットに至るまで、あらゆるサイズのモバイルネットワーク、O。
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マルチホームモバイルネットワーク：単一のMRは、インターネットに複数の添付ファイルを有するか、またはモバイルネットワークは、複数のMRを用いてインターネットに接続されている場合（[1]における定義と[8]で分析を参照）のいずれか。
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.
階層型移動ネットワーク（モバイルネットワークが他の移動ネットワークにアタッチ（[1]における定義を参照）O。これらのネストされたネットワークの複雑さの要件が明確ではないが、再帰ネットワークの任意のレベルをサポートすることが望ましい。溶液は、制限を課すべきですネスト上（例えば、パス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つのエンドポイント間で転送されることになるものです。スタブ・ネットワーク（リーフ・ネットワーク）が、一方、データ転送経路とはなりません。スタブ・ネットワーク上のデータを送信またはそのネットワーク内に位置するノードにアドレス指定されますか。
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.
異なる管理エンティティが所有するモバイルネットワークとモバイルノードがドメイン境界内またはドメインの境界との間で変位されることが期待されます。マルチホーミング、垂直方向と水平方向のハンドオフ、及びアクセス制御メカニズムは、この目標を達成することが望ましいです。このような移動度は、管理やセキュリティポリシー以外の検討のために制限されることを期待されていません。
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.
NEMOサポートシグナリングおよび処理は、移動にかかわらず、それらの構成のネットワーク、モビリティ周波数、大きさ、およびCNSの数の潜在的に大きな数まで拡張することが期待されます。
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:
NEMOのサポートは、確立された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.
MNNsを意図Oマルチキャストのサポートは、モバイルルータが接続ポイントを変更しながら維持されることが期待されます。
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).
訪問先ネットワークとモバイルネットワーク（ルーティングプロトコル、近隣探索、ICMP、ルータリナンバリング）の両方に配備ルータによって実行Oメカニズム。
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:
NEMOのサポートは、通常のIETFセキュリティポリシーと推奨事項を遵守する必要がありますし、その特定のセキュリティ上の問題が完全に解決が期待されます。実際には、ネットワークに送信されるすべてのNEMO支援制御メッセージは、アイデンティティを奪うからの侵入者を防ぎ、データを偽造するためのセキュリティの許容レベルで保護する必要があります。具体的には、以下の問題を考慮しなければなりません。
o Authentication of the sender to prevent identity usurpation.
O送信者の認証は、ID強奪を防ぐために。
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.
制御メッセージに含まれるデータの入出力機密。
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ヘッダの暗号化のいくつかの種類を必要とするであろう。一方、彼らのCNSへの彼らの本当の位相的な位置を隠すためにMNNsための手段を提供することが非常に少なくとも望ましいです。
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と共存する可能性があるので、NEMOのために開発された機構は、このような雲を通過することができるであろうことを確実にすることが望ましいです。
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.
いずれのNEMOソリューションのニーズは世界的なインターネットルーティングシステムに最小限の負の効果を持ちます。溶液は、従って、インターネットルーティングに注入しなければならない情報の量、ならびにグローバルルーティングシステムに注入された情報の動的変化の両方を制限しなければなりません。
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.
これが必要な理由の一例としては、BGPに各モバイルネットワークの接続性を宣伝して、すべての運動のために、古いルートを引き抜くと、新しいルートを注入するアプローチを検討します。十モバイルネットワークの何千ものがあった場合は、各広告と吸引経路には、例えば、航空機が別の地上局から移動できる速度で、BGPに対する潜在的な影響は非常に不幸なことができました。この例では、BGPにアドバタイズルーティング情報の合計量が許容されるかもしれないが、情報の動的不安定性（即ち、経時変化の数）は、受け入れられないであろう。
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 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.
基本的なネットワークモビリティサポートについては、NEMO WGは、以下「ソリューション」と呼ばれ、統一されたユニークな「ネットワークモビリティ（NEMO）基本サポート」ソリューションを、指定することです。このソリューションは、モバイルネットワーク内のすべてのノードが永久的なIPアドレスを経由して到達可能であるだけでなく、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.
NEMOワーキンググループは、代替案の一部調査した後、トンネル管理のための既存のモバイル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].
下記の要件のリストは、NEMOベーシックサポートソリューションに課されています。要件はほとんど今、[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は：すべてのトラフィックは、双方向MRHAトンネルを通じてグローバルなインターネット必見の輸送中にMNNとCN間で交換しました。
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：溶液がmrs（の1つ）のIPハンドオーバ後MNNsと任意のCNとの間の連続的なセッション（ユニキャストとマルチキャストの両方）を維持しなければなりません。
R06: The solution must not require modifications to any node other than MRs and HAs.
R06：溶液がmrs以外の任意のノードに変更を必要としたなりません。
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]).
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：ソリューションは、内部構成にとらわれないでなければなりません。これは、NEMOがネストされている場合解決策は同じように動作することを意味し、一つまたは複数のサブネットを含み、または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：[1]で定義されるように、溶液は、マルチホームのMRとマルチホームモバイルネットワークのために機能しなければなりません。
R13: NEMO support signaling over the bi-directional must be minimized.
R13：双方向の上にシグナルNEMOサポートは最小限に抑えなければなりません。
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：ソリューションは、双方向トンネル上でルーティング及び管理業務の透明継続を保証しなければならない（これは含まれ、例えば、ユニキャストおよびマルチキャストルーティングプロトコルは、ルータリナンバリング、動的ホスト構成プロトコル（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：ソリューションは、グローバルなインターネットルーティングシステムへの影響を最小限に抑える必要があります。
Security considerations of the NEMO Basic Support solution are addressed in [RFC3963].
NEMOベーシックサポートソリューションのセキュリティに関する考慮事項は、[RFC3963]で扱われています。
Section 3.9 of this document discusses the security goals for all forms of existing and forthcoming NEMO solutions.
このドキュメントのセクション3.9は、既存および今後のNEMOソリューションのすべての形態のためのセキュリティ目標について説明します。
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.
この文書で提示された資料は、議論やNEMOワーキンググループに提出し、前の文書から、テキストのほとんどを取ります。これはモトローラ、INRIA、エリクソン、ノキアからの最初の貢献が含まれています。我々は非常にNEMOワーキンググループを設置するのに役立ったHeshamソリマン（エリクソン）とIETFエリア取締役時（ADS）（エリックNordmarkと、トーマスNarten氏）、特に感謝しています。我々はまた、そのコメントが大幅に現在のドキュメントに貢献し、以下のすべての人々に感謝しています：T.J。 Kniveton（ノキア）、アレクサンドル・ペトレスク（モトローラ）、クリストフJanneteau（モトローラ）、パスカルThubert（シスコ）、ホン・ヨンLACH（モトローラ）、マティアスPetterson（エリクソン）、およびNEMOのメーリングリストに自分の意見を表明している他のすべて（旧MONETとして知られている）のリスト。特にクロードカステルッシア（INRIA）とホン・ヨンLACH（モトローラ） - - ティエリーエルンストは個人的には2001年にIETFにこの話題を持ち出すで彼らのサポートと方向のためのINRIAローヌ・アルプとモトローラLabsのパリを確認したいと彼の過去このドキュメントの以前のバージョンのtimelife中にIETFに関連するコストの大部分を支え、雇用主、慶應義塾大学、日本、。
[1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[1]エルンスト、T.とH. LACH、 "ネットワークモビリティサポート用語"、RFC 4885、2007年7月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[2]のようにして、J.とM.古城、 "モビリティ関連用語"、RFC 3753、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、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、2005年1月。
[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 - ミディアムとロングレンジ、高速、放送、ポイントツーポイント、車両への車両、およびITS分野での通信を指すように、車両用エアインターフェースパラメータとプロトコル - ネットワークプロトコル - 補足要素」、ISOドラフトISO / WD 21210、2005年2月。
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[5]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、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.趙、 "ネットワークモビリティ経路最適化問題に関する声明"、RFC 4888、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、 "ネットワークモビリティルート最適化ソリューションスペース解析"、RFC 4889、2007年7月。
[8] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", Work in Progress), February 2007.
[8]呉、C.、エルンスト、T.、パイク、E.、およびM. Bagnulo、 "ネットワークモビリティサポートにおけるマルチホーミングの分析"、作業中）、2007年2月。
[9] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility (NEMO) Home Network Models", RFC 4887, July 2007.
[9] tubert、フィル。、Vakikava、道路。、と判断。 Devarapalli、 "ネットワークモビリティ（NEMO）、世界のホームネットワーク"、rphak 4887、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ドメーヌ・デ・Voluceau PB 105 78153シェズネーセデックスフランス
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ファックス：+33 1 39 63 54 91 Eメール：thierry.ernst@inria.fr URI：http://www-rocq.inria.fr/imara
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機能のための基金は現在、インターネット協会によって提供されます。