[要約] RFC 4886は、ネットワークの移動性をサポートするための目標と要件を定義しています。このRFCの目的は、モバイルネットワークの設計と実装において、ネットワークの移動性を効果的にサポートするためのガイドラインを提供することです。
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）The IETF Trust（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 Basic Support Solutionによって満たされなければならない要件を定義します。
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つ以上のモバイルルーター（MRS）が含まれており、グローバルインターネットに接続しています。MR（S）（MNNS）の背後にあるノードは、固定（LFN）とモバイル（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 人に添付されたネットワーク（パーソナルエリアネットワークまたはパン）：Bluetooth対応のPDAとともに、1つのセルラーインターフェイスと1つのBluetoothインターフェイスを備えた携帯電話は、モバイルネットワークの非常にシンプルなインスタンスを構成します。携帯電話はモバイルルーターであり、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 車両に展開されたセンサーとコンピューターのネットワーク：車両には、（インテリジェント輸送システム）アプリケーションで提唱されているように、安全性と運転上の理由を容易にするために、多くの処理ユニットがますます装備されています（[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デバイス（ラップトップ、カメラ、携帯電話）にインターネットアクセスを提供します。ネットワークモビリティまたはパン内のホストモビリティ。ネットワークモビリティ内のネットワークモビリティ、つまりネストされたモビリティ（ネストされたモビリティの定義については[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：MR：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.
ネットワークのモビリティは、MNNが独自の物理的な添付ファイルを変更することはありません。ただし、グローバルインターネットに関してトポロジカル位置を変更します。ネットワークのモビリティがいくつかのメカニズムによって明示的にサポートされていない場合、MRのモビリティは、MNNSがインターネットアクセスを失い、グローバルインターネットで任意の特派員ノード（CNS）とモバイルネットワーク内にあるMNNとの間の継続的なセッションを破壊する結果です。さらに、MNNと特派員ノード間の通信パスは最適になり、複数のレベルのモビリティが非常に準最適なルーティングを引き起こします。
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では、ネットワークモビリティの問題を処理するために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.
ネットワークモビリティの問題の取り扱いに必要なメカニズムは、2002年にIETFにNEMOワーキンググループ（WG）が設定されたときにIETF標準内で欠けていました。当時、モビリティサポート（特にモバイルIPワーキンググループ）で実施された作業は継続的なインターネット接続とモバイルホストのみに最適なルーティングを提供するため（ホストモビリティサポート）。モバイル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ワーキンググループは段階的なアプローチを取ることを決定しました。このアプローチの手順には、セッションの継続性を維持するための基本的なソリューション（NEMO基本サポート、[3]を参照）を標準化し、潜在的にネストされたモバイルネットワークを備えたより最適なルーティングを提供する可能性のあるアプローチと問題を研究することが含まれます（NEMO拡張サポート、[6]を参照[7]ルーティングの最適化の問題に関する議論については、[8]は多語の問題に関する議論について。ただし、ワーキンググループは、この時点で拡張サポートのソリューションを実際に標準化するためにチャーターされていません。必要と思われる場合、ワーキンググループは議論の結論に基づいて充電されます。
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プロトコルが生まれました。これは、ホストモビリティサポートの問題をすでに解決しています。この作業により、モバイルネットワークを有効にするための課題は大幅に削減されているため、Basic Network Mobility Supportは、モバイルIPで使用されるホストモビリティサポートの方法を採用し、目標を達成するために可能な限り簡単に拡張しました。現在の文書のセクション4に記載されている要件に従って[3]で定義されている基本的なサポートソリューションは、各MRがホームエージェント（HA）を持つことであり、MRとHAの間の双方向トンネリングを使用してセッションを保存することです。連続性氏が動きます。MRは、モバイルIPを使用して、モバイルホスト（MHS）に対して行われているものと同じように、その添付のポイントでケアオブアドレス（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.
モバイルルーターが添付ファイルのポイントを変更するため、継続的なセッションが維持されると予想されるため、インターネットへの永続的な接続をすべてのMNNに提供する必要があります。これらのセッションを維持するために、MNNは永続的な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サポートには、限られたシグナリングオーバーヘッドが提供され、パケットの損失または遅延の観点から、アプリケーションへのハンドオーバーの影響を最小限に抑えることが期待されています。ただし、MNNとそれぞれの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の背後にあるMNNは、インターネットトポロジにおけるモバイルネットワークの変位の結果として、独自の物理的な愛着点を変更しません。したがって、NEMOサポートはMR（S）によってのみ実行されると予想されます。MR以外のノード上の特定のサポート機能は、回避する方がよいでしょう。
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.
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 Mobile Network：単一のMRがインターネットに複数の添付ファイルを持っている場合、または複数のMRSによってモバイルネットワークがインターネットに接続されている場合（[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.
o ネストされたモバイルネットワーク（他のモバイルネットワークに接続するモバイルネットワーク（[1]の定義を参照）。これらのネストされたネットワークの複雑さの要件は明確ではありませんが、任意のレベルの再帰ネットワークをサポートすることが望ましいです。ソリューションは、制限を課すだけです。ネスト（例：Path 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.
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 訪問ネットワークとモバイルネットワークの両方で展開されたルーターによって実行されるメカニズム（ルーティングプロトコル、近隣発見、ICMP、ルーターの変更）。
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 アイデンティティの奪取を防ぐための送信者の認証。
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 コントロールメッセージに含まれるデータの機密性。
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ヘッダーの何らかの暗号化が必要になります。一方、MNNが実際のトポロジカル位置をCNSに隠す手段を提供することは、少なくとも望ましいことです。
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.
これが必要な理由の1つの例として、各モバイルネットワークの接続性を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：グローバルインターネットで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：ソリューションは、MRSのIPハンドオーバー後のMNNと任意の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]).
R09.1：ソリューションは、モバイルIPv6の適切な動作を防止してはなりません（つまり、ソリューションは、[5]で定義されたCN、HA、またはMN操作のいずれかを動作させる必要があります）。
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がネストされている場合、1つまたは複数のサブネットを含む場合、またはLFN、VMN、LFN、またはそれらの混合物であるMNNで構成されている場合、ソリューションが同じように動作することを意味します。
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]で定義されているように、マルチホームMRSおよびマルチホームモバイルネットワークのソリューションは機能する必要があります。
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ワーキンググループに提出した以前のドキュメントから採用しています。これには、Motorola、Inria、Ericsson、Nokiaからの初期貢献が含まれます。Hesham Soliman（Ericsson）とIETFエリアディレクター（ADS）（Erik NordmarkとThomas Narten）に特に感謝しています。また、現在の文書にコメントが大いに貢献した次のすべての人々にも感謝しています。T.J。Kniveton（Nokia）、Alexandru Petrescu（Motorola）、Christophe Janneteau（Motorola）、Pascal Thubert（Cisco）、Hong-Yon Lach（Motorola）、Mattias Petterson（Ericsson）などリスト（以前はMonetとして知られています）。ティエリー・エルンストは、2001年にこのトピックをIETFに持ち込む際のサポートと方向性について、インリア・ローヌ・アルペスとモトローラ・ラボ・パリを個人的に認めたいと考えています - 特にクロード・カステルッチア（INRIA）とホン・ヨン・ラッハ（モトローラ）と彼の過去雇用主、キオ大学、日本、このドキュメントの以前のバージョンのタイムライフ中にIETFに関連するコストのほとんどをサポートしました。
[1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[1] Ernst、T。およびH. Lach、「ネットワークモビリティサポート用語」、RFC 4885、2007年7月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[2] Mather、J。およびM. Kojo、「Mobility関連用語」、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.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、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] 「穏やかな - 中程度と長距離、高速、空気インターフェイスパラメーターと放送用のプロトコル、ポイントツーポイント、車両への車両、および車両セクター - ネットワーキングプロトコル - 補完要素 - ISOドラフトISO/WD 21210、2005年2月。
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[5] Johnson、D.、Perkins、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] Ng、C.、Thubert、P.、Watari、M。、およびF. Zhao、「ネットワークモビリティルート最適化問題ステートメント」、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] Ng、C.、Zhao、F.、Watari、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] Ng、C.、Ernst、T.、Paik、E。、およびM. Bagnulo、「ネットワークモビリティサポートにおけるマルチホミングの分析」、進行中の作業）、2007年2月。
[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、「ネットワークモビリティ（NEMO）ホームネットワークモデル」、RFC 4887、2007年7月。
Author's Address
著者の連絡先
Thierry Ernst INRIA INRIA Rocquencourt Domaine de Voluceau B.P. 105 78 153 Le Chesnay Cedex France
Thierry Ernst Inria Inria Rocquencourt Domaine de Voluceau B.P.105 78 153 Le Chesnay Cedex France
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。