[要約] RFC 4889は、ネットワークモビリティのルート最適化ソリューションの分析を提供しています。このRFCの目的は、ネットワークモビリティの問題を解決するためのソリューションの範囲を明確にすることです。
Network Working Group C. Ng
Request for Comments: 4889 Panasonic Singapore Labs
Category: Informational F. Zhao
UC Davis
M. Watari
KDDI R&D Labs
P. Thubert
Cisco Systems
July 2007
Network Mobility Route Optimization Solution Space Analysis
ネットワークモビリティルート最適化ソリューションスペース分析
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
概要
With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the Mobile Router and Home Agent (MRHA) tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization.
現在のネットワークモビリティ（NEMO）の基本的なサポートにより、モバイルネットワークが離れているときは、モバイルネットワークノードとのすべての通信がモバイルルーターとホームエージェント（MRHA）トンネルを通過する必要があります。これにより、ほとんどの場合、パケットルートの長さが増加し、パケット遅延が増加します。これらの制限を克服するには、NEMOのルート最適化（RO）に頼る必要がある場合があります。このメモは、NEMOのさまざまなタイプのルート最適化を文書化し、NEMOルート最適化のさまざまな側面での利点とトレードオフを調査します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Benefits of NEMO Route Optimization . . . . . . . . . . . . . 4
3. Different Scenarios of NEMO Route Optimization . . . . . . . . 6
3.1. Non-Nested NEMO Route Optimization . . . . . . . . . . . . 6
3.2. Nested Mobility Optimization . . . . . . . . . . . . . . . 8
3.2.1. Decreasing the Number of Home Agents on the Path . . . 8
3.2.2. Decreasing the Number of Tunnels . . . . . . . . . . . 9
3.3. Infrastructure-Based Optimization . . . . . . . . . . . . 9
3.4. Intra-NEMO Optimization . . . . . . . . . . . . . . . . . 10
4. Issues of NEMO Route Optimization . . . . . . . . . . . . . . 11
4.1. Additional Signaling Overhead . . . . . . . . . . . . . . 11
4.2. Increased Protocol Complexity and Processing Load . . . . 12
4.3. Increased Delay during Handoff . . . . . . . . . . . . . . 12
4.4. Extending Nodes with New Functionalities . . . . . . . . . 13
4.5. Detection of New Functionalities . . . . . . . . . . . . . 14
4.6. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Mobility Transparency . . . . . . . . . . . . . . . . . . 14
4.8. Location Privacy . . . . . . . . . . . . . . . . . . . . . 15
4.9. Security Consideration . . . . . . . . . . . . . . . . . . 15
4.10. Support of Legacy Nodes . . . . . . . . . . . . . . . . . 15
5. Analysis of Solution Space . . . . . . . . . . . . . . . . . . 16
5.1. Which Entities Are Involved? . . . . . . . . . . . . . . . 16
5.1.1. Mobile Network Node and Correspondent Node . . . . . . 16
5.1.2. Mobile Router and Correspondent Node . . . . . . . . . 17
5.1.3. Mobile Router and Correspondent Router . . . . . . . . 17
5.1.4. Entities in the Infrastructure . . . . . . . . . . . . 18
5.2. Who Initiates Route Optimization? When? . . . . . . . . . 18
5.3. How Is Route Optimization Capability Detected? . . . . . . 19
5.4. How is the Address of the Mobile Network Node
Represented? . . . . . . . . . . . . . . . . . . . . . . . 20
5.5. How Is the Mobile Network Node's Address Bound to
Location? . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5.1. Binding to the Location of Parent Mobile Router . . . 21
5.5.2. Binding to a Sequence of Upstream Mobile Routers . . . 23
5.5.3. Binding to the Location of Root Mobile Router . . . . 24
5.6. How Is Signaling Performed? . . . . . . . . . . . . . . . 26
5.7. How Is Data Transmitted? . . . . . . . . . . . . . . . . . 27
5.8. What Are the Security Considerations? . . . . . . . . . . 28
5.8.1. Security Considerations of Address Binding . . . . . . 28
5.8.2. End-to-End Integrity . . . . . . . . . . . . . . . . . 30
5.8.3. Location Privacy . . . . . . . . . . . . . . . . . . . 30
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 33
Network Mobility Route Optimization Problem Statement [1] describes operational limitations and overheads incurred in a deployment of Network Mobility (NEMO) Basic Support [2], which could be alleviated by a set of NEMO Route Optimization techniques to be defined. The term "Route Optimization" is used in a broader sense than already defined for IPv6 Host Mobility in [3] to loosely refer to any approach that optimizes the transmission of packets between a Mobile Network Node and a Correspondent Node.
ネットワークモビリティルート最適化問題ステートメント[1]は、ネットワークモビリティ（NEMO）の基本サポート[2]の展開で発生した運用上の制限とオーバーヘッドについて説明します。「ルート最適化」という用語は、[3]のIPv6ホストモビリティですでに定義されているよりも広い意味で使用され、モバイルネットワークノードと特派員ノード間のパケットの送信を最適化するアプローチを大まかに参照します。
Solutions that would fit that general description were continuously proposed since the early days of NEMO, even before the Working Group was formed. Based on that long-standing stream of innovation, this document classifies, at a generic level, the solution space of the possible approaches that could be taken to solve the Route Optimization-related problems for NEMO. The scope of the solutions, the benefits, and the impacts to the existing implementations and deployments are analyzed. This work should serve as a foundation for the NEMO WG to decide where to focus its Route Optimization effort, with a deeper understanding of the relative strengths and weaknesses of each approach.
その一般的な説明に適合するソリューションは、ワーキンググループが形成される前であっても、NEMOの初期から継続的に提案されていました。その長年のイノベーションの流れに基づいて、このドキュメントは、NEMOのルート最適化関連の問題を解決するために取られる可能性のあるアプローチのソリューション空間を一般的なレベルで分類します。ソリューションの範囲、利点、既存の実装と展開への影響が分析されます。この作業は、各アプローチの相対的な長所と短所をより深く理解して、ルート最適化の取り組みに焦点を合わせる場所を決定するためのNemo WGの基盤として機能するはずです。
It should be beneficial for readers to keep in mind the design requirements of NEMO [4]. A point to note is that since this document discusses aspects of Route Optimization, the reader may assume that a mobile network or a mobile host is away when they are mentioned throughout this document, unless it is explicitly specified that they are at home.
読者がNEMOの設計要件を念頭に置いておくことは有益です[4]。注意すべき点は、このドキュメントではルートの最適化の側面について説明しているため、読者は、自宅にいることを明示的に指定しない限り、このドキュメント全体で言及されているときにモバイルネットワークまたはモバイルホストが離れていると想定する場合があります。
It is expected that readers are familiar with terminologies related to mobility in [3] and [5], and NEMO-related terms defined in [6]. In addition, the following Route Optimization-specific terms are used in this document:
読者は、[3]および[5]のモビリティに関連する用語、および[6]で定義されているNEMO関連の用語に精通していることが期待されています。さらに、このドキュメントでは、次のルート最適化固有の用語が使用されています。
Correspondent Router (CR)
特派員ルーター（CR）
This refers to the router that is capable of terminating a Route Optimization session on behalf of a Correspondent Node.
これは、特派員ノードに代わってルート最適化セッションを終了できるルーターを指します。
Correspondent Entity (CE)
特派員エンティティ（CE）
This refers to the entity that a Mobile Router or Mobile Network Node attempts to establish a Route Optimization session with. Depending on the Route Optimization approach, the Correspondent Entity may be a Correspondent Node or Correspondent Router.
これは、モバイルルーターまたはモバイルネットワークノードがルート最適化セッションを確立しようとするエンティティを指します。ルート最適化アプローチに応じて、特派員エンティティは、特派員ノードまたは特派員ルーターである場合があります。
NEMO Route Optimization addresses the problems discussed in [1]. Although a standardized NEMO Route Optimization solution has yet to materialize, one can expect it to show some of the following benefits:
NEMOルート最適化は、[1]で説明されている問題に対処します。標準化されたNEMOルート最適化ソリューションはまだ実現していませんが、次の利点の一部を示すことが期待できます。
o Shorter Delay
o より短い遅延
Route Optimization involves the selection and utilization of a lesser-cost (thus generally shorter and faster) route to be taken for traffic between a Mobile Network Node and its Correspondent Node. Hence, Route Optimization should improve the latency of the data traffic between the two end nodes. This may in turn lead to better overall Quality of Service characteristics, such as reduced jitter and packet loss.
ルートの最適化には、モバイルネットワークノードとその特派員ノード間のトラフィックのために、より低いコスト（したがって、一般的に短くて高速な）ルートの選択と利用が含まれます。したがって、ルートの最適化は、2つのエンドノード間のデータトラフィックの遅延を改善するはずです。これにより、ジッターの減少やパケット損失など、サービスの全体的な品質が向上する可能性があります。
o Reduced Consumption of Overall Network Resources
o ネットワークリソース全体の消費の削減
Through the selection of a shorter route, the total link utilization for all links used by traffic between the two end nodes should be much lower than that used if Route Optimization is not carried out. This would result in a lighter network load with reduced congestion.
より短いルートの選択を通じて、2つのエンドノード間のトラフィックで使用されるすべてのリンクの合計リンク使用率は、ルート最適化が実行されない場合に使用されるものよりもはるかに低くする必要があります。これにより、渋滞が軽減されたネットワークの負荷が軽減されます。
o Reduced Susceptibility to Link Failure
o 故障をリンクするための感受性が低下しました
If a link along the bi-directional tunnel is disrupted, all traffic to and from the mobile network will be affected until IP routing recovers from the failure. An optimized route would conceivably utilize a smaller number of links between the two end nodes. Hence, the probability of a loss of connectivity due to a single point of failure at a link should be lower as compared to the longer non-optimized route.
双方向トンネルに沿ったリンクが破壊された場合、モバイルネットワークとの間のすべてのトラフィックは、IPルーティングが障害から回復するまで影響を受けます。最適化されたルートは、おそらく2つのエンドノード間の少数のリンクを利用する可能性があります。したがって、リンクでの単一の障害点による接続が失われる可能性は、最適化されていないルートと比較して低くする必要があります。
o Greater Data Efficiency
o データ効率の向上
Depending on the actual solution for NEMO Route Optimization, the data packets exchanged between two end nodes may not require as many levels of encapsulation as that in NEMO Basic Support. This would mean less packet overheads and higher data efficiency. In particular, avoiding packet fragmentation that may be induced by the multiple levels of tunneling is critical for end-to-end efficiency from the viewpoints of buffering and transport protocols.
NEMOルートの最適化の実際のソリューションに応じて、2つのエンドノード間で交換されるデータパケットは、NEMO基本サポートのレベルほど多くのレベルのカプセル化を必要としない場合があります。これは、パケットオーバーヘッドが少なく、データ効率が高いことを意味します。特に、バッファリングおよび輸送プロトコルの視点からのエンドツーエンドの効率にとって、複数のレベルのトンネルによって誘導される可能性のあるパケット断片化を回避することは重要です。
o Reduced Processing Delay
o 処理遅延の減少
In a nested mobile network, the application of Route Optimization may eliminate the need for multiple encapsulations required by NEMO Basic Support, which may result in less processing delay at the points of encapsulation and decapsulation.
ネストされたモバイルネットワークでは、ルートの最適化を適用すると、NEMOの基本的なサポートが必要とする複数のカプセルが必要になる可能性があり、その結果、カプセル化と脱カプセル化のポイントでの処理遅延が少なくなる可能性があります。
o Avoiding a Bottleneck in the Home Network
o ホームネットワークでボトルネットを避ける
NEMO Route Optimization allows traffic to bypass the Home Agents. Apart from having a more direct route, this also avoids routing traffic via the home network, which may be a potential bottleneck otherwise.
NEMOルートの最適化により、トラフィックはホームエージェントをバイパスできます。より直接的なルートを持っていることとは別に、これはホームネットワークを介してトラフィックをルーティングすることも避けます。
o Avoid the Security Policy Issue
o セキュリティポリシーの問題を避けてください
Security policy may forbid a Mobile Router from tunneling traffic of Visiting Mobile Nodes into the home network of the Mobile Router. Route Optimization can be used to avoid this issue by forwarding traffic from Visiting Mobile Nodes directly to their destinations without going through the home network of the Mobile Router.
セキュリティポリシーは、モバイルノードの訪問のトンネルトラフィックをモバイルルーターのホームネットワークにトンネリングすることを禁止する場合があります。ルートの最適化は、モバイルノードの訪問から宛先に直接訪問するトラフィックをモバイルルーターのホームネットワークを通過せずに転送することにより、この問題を回避するために使用できます。
However, it should be taken into consideration that a Route Optimization mechanism may not be an appropriate solution since the Mobile Router may still be held responsible for illegal traffic sent from its Mobile Network Nodes even when Route Optimization is used. In addition, there can be a variety of different policies that might conflict with the deployment of Route Optimization for Visiting Mobile Nodes. Being a policy issue, solving this with a protocol at the policy plane might be more appropriate.
ただし、ルートの最適化が使用されている場合でもモバイルネットワークノードから送信される違法なトラフィックの責任を負う可能性があるため、ルート最適化メカニズムは適切なソリューションではない可能性があることを考慮する必要があります。さらに、モバイルノードにアクセスするためのルート最適化の展開と矛盾する可能性のあるさまざまなポリシーがあります。ポリシーの問題であるため、ポリシープレーンでプロトコルでこれを解決する方が適切かもしれません。
o Avoid the Instability and Stalemate
o 不安定性と膠着状態を避けてください
[1] described a potential stalemate situation when a Home Agent is nested within a mobile network. Route Optimization may circumvent such stalemate situations by directly forwarding traffic upstream. However, it should be noted that certain Route Optimization schemes may require signaling packets to be first routed via the Home Agent before an optimized route can be established. In such cases, a Route Optimization solution cannot avoid the stalemate.
[1] ホームエージェントがモバイルネットワーク内にネストされている場合、潜在的な膠着状態の状況を説明しました。ルートの最適化は、トラフィックを上流に直接転送することにより、このような膠着状態の状況を回避する可能性があります。ただし、最適化されたルートを確立する前に、特定のルート最適化スキームでは、ホームエージェントを介して最初にルーティングすることを信号パケットにする必要があることに注意する必要があります。そのような場合、ルート最適化ソリューションは膠着状態を回避できません。
There are multiple proposals for providing various forms of Route Optimization in the NEMO context. In the following sub-sections, we describe the different scenarios that would require a Route Optimization mechanism and list the potential solutions that have been proposed in that area.
NEMOコンテキストでさまざまな形式のルート最適化を提供するための複数の提案があります。次のサブセクションでは、ルート最適化メカニズムを必要とするさまざまなシナリオを説明し、その分野で提案されている潜在的なソリューションをリストします。
The Non-Nested NEMO Route Optimization involves a Mobile Router sending binding information to a Correspondent Entity. It does not involve nesting of Mobile Routers or Visiting Mobile Nodes. The Correspondent Entity can be a Correspondent Node or a Correspondent Router. The interesting case is when the Correspondent Entity is a Correspondent Router. With the use of Correspondent Router, Route Optimization session is terminated at the Correspondent Router on behalf of the Correspondent Node. As long as the Correspondent Router is located "closer" to the Correspondent Node than the Home Agent of the Mobile Router, the route between Mobile Network Node and the Correspondent Node can be said to be optimized. For this purpose, Correspondent Routers may be deployed to provide an optimal route as illustrated in Figure 1.
非ネモルートの最適化には、特派員エンティティにバインディング情報を送信するモバイルルーターが含まれます。モバイルルーターのネストやモバイルノードの訪問は含まれません。特派員エンティティは、特派員ノードまたは特派員ルーターにすることができます。興味深いケースは、特派員エンティティが特派員ルーターである場合です。特派員ルーターを使用すると、通信者ノードに代わって、ルート最適化セッションが特派員ルーターで終了します。特派員ルーターがモバイルルーターのホームエージェントよりも、特派員ノードに「近い」配置されている限り、モバイルネットワークノードと特派員ノードの間のルートは最適化されていると言えます。この目的のために、図1に示すように、最適なルートを提供するために、特派員ルーターを展開することができます。
************************** HAofMR
* #*#
* #*# +---------------------+
CN #*# | LEGEND |
o #*# +---------------------+
o ############### #*# | #: Tunnel |
CR ooooooooooooooo MR | *: NEMO Basic route |
############### | | o: Optimized route |
MNN +---------------------+
Figure 1: MR-CR Optimization
図1：MR-CRの最適化
This form of optimization can carry traffic in both directions or independently for the two directions of traffic:
この形式の最適化は、トラフィックの2つの方向に対して、両方向または独立してトラフィックを運ぶことができます。
o From MNN to CN
o MNNからCNへ
The Mobile Router locates the Correspondent Router, establishes a tunnel with that Correspondent Router and sets up a route to the Correspondent Node via the Correspondent Router over the tunnel. Traffic to the Correspondent Node would no longer flow through the Home Agent anymore.
モバイルルーターは、特派員ルーターを見つけ、その特派員ルーターとトンネルを確立し、トンネル上の特派員ルーターを介して特派員ノードへのルートをセットアップします。特派員ノードへのトラフィックは、もはやホームエージェントを介して流れなくなります。
o From CN to MNN
o CNからMNNへ
The Correspondent Router is on the path of the traffic from the Correspondent Node to the Home Agent. In addition, it has an established tunnel with the current Care-of Address (CoA) of the Mobile Router and is aware of the Mobile Network Prefix(es) managed by the Mobile Router. The Correspondent Router can thus intercept packets going to the mobile network, and forward them to the Mobile Router over the established tunnel.
特派員ルーターは、特派員ノードからホームエージェントへのトラフィックのパスにあります。さらに、モバイルルーターの現在のケアアドレス（COA）を備えた確立されたトンネルがあり、モバイルルーターが管理するモバイルネットワークプレフィックス（ES）を認識しています。したがって、特派員のルーターは、モバイルネットワークに送られるパケットを傍受し、確立されたトンネルを介してモバイルルーターに転送できます。
A straightforward approach to Route Optimization in NEMO is for the Mobile Router to attempt Route Optimization with a Correspondent Entity. This can be viewed as a logical extension to NEMO Basic Support, where the Mobile Router would send Binding Updates containing one or more Mobile Network Prefix options to the Correspondent Entity. The Correspondent Entity, having received the Binding Update, can then set up a bi-directional tunnel with the Mobile Router at the current Care-of Address of the Mobile Router, and inject a route to its routing table so that packets destined for addresses in the Mobile Network Prefix will be routed through the bi-directional tunnel.
NEMOでのルート最適化への簡単なアプローチは、モバイルルーターが特派員エンティティとのルート最適化を試みることです。これは、NEMO Basic Supportの論理的拡張機能と見なすことができます。ここでは、モバイルルーターが1つ以上のモバイルネットワークプレフィックスオプションを含むバインディングアップデートを特派員エンティティに送信します。バインディングアップデートを受け取った特派員エンティティは、モバイルルーターの現在のケアアドレスにモバイルルーターを備えた双方向トンネルを設定し、ルーティングテーブルへのルートを注入して、モバイルネットワークのプレフィックスは、双方向トンネルを介してルーティングされます。
The definition of Correspondent Router does not limit it to be a fixed router. Here we consider the case where the Correspondent Router is a Mobile Router. Thus, Route Optimization is initiated and performed between a Mobile Router and its peer Mobile Router. Such solutions are often posed with a requirement to leave the Mobile Network Nodes untouched, as with the NEMO Basic Support protocol, and therefore Mobile Routers handle the optimization management on behalf of the Mobile Network Nodes. Thus, providing Route Optimization for a Visiting Mobile Node is often out of scope for such a scenario because such interaction would require extensions to the Mobile IPv6 protocol. This scenario is illustrated in Figure 2.
特派員ルーターの定義は、固定ルーターに制限されません。ここでは、特派員ルーターがモバイルルーターである場合を検討します。したがって、ルートの最適化が開始され、モバイルルーターとそのピアモバイルルーターの間で実行されます。このようなソリューションには、NEMO Basic Support Protocolと同様に、モバイルネットワークノードを触れられないままにするための要件でしばしば提起されます。したがって、モバイルルーターは、モバイルネットワークノードに代わって最適化管理を処理します。したがって、訪問するモバイルノードのルート最適化を提供することは、このような相互作用にはモバイルIPv6プロトコルの拡張が必要なため、このようなシナリオの範囲外であることがよくあります。このシナリオを図2に示します。
HAofCR ********************************** HAofMR
#*# #*#
#*# #*# +---------------------+
#*# #*# | LEGEND |
#*# #*# +---------------------+
#*# ############### #*# | #: Tunnel |
CR ooooooooooooooo MR | *: NEMO Basic route |
| ############### | | o: Optimized route |
MNN2 MNN1 +---------------------+
Figure 2: MR-MR Optimization
図2：MR-MR最適化
This form of optimization can carry traffic for both directions identically:
この形式の最適化は、両方向のトラフィックを同じように運ぶことができます。
o MNN1 to/from MNN2
o mnn1からmnn2から
The Mobile Router locates the Correspondent Router, establishes a tunnel with that Correspondent Router, and sets up a route to the Mobile Network Node via the Correspondent Router over the tunnel. Traffic to the Mobile Networks Nodes would no longer flow through the Home Agents.
モバイルルーターは、特派員ルーターを見つけ、その特派員ルーターを備えたトンネルを確立し、トンネル上の特派員ルーターを介してモバイルネットワークノードへのルートをセットアップします。モバイルネットワークへのトラフィックは、ホームエージェントを介して流れなくなります。
Examples of this approach include Optimized Route Cache (ORC) [7][8] and Path Control Header (PCH) [9].
このアプローチの例には、最適化されたルートキャッシュ（ORC）[7] [8]およびパス制御ヘッダー（PCH）[9]が含まれます。
Optimization in Nested Mobility targets scenarios where a nesting of mobility management protocols is created (i.e., Mobile IPv6-enabled host inside a mobile network or multiple Mobile Routers that attach behind one another creating a nested mobile network). Note that because Mobile IPv6 defines its own Route Optimization mechanism in its base protocol suite as a standard, collaboration between this and NEMO protocols brings various complexities.
ネストされたモビリティの最適化は、モビリティ管理プロトコルのネストが作成されるシナリオをターゲットにします（つまり、モバイルネットワーク内のモバイルIPv6対応ホストまたはネストされたモバイルネットワークを作成する複数のモバイルルーター）。モバイルIPv6は、基本プロトコルスイートの独自のルート最適化メカニズムを標準として定義するため、このコラボレーションとNEMOプロトコルはさまざまな複雑さをもたらします。
There are two main aspects in providing optimization for Nested Mobility, and they are discussed in the following sub-sections.
ネストされたモビリティの最適化を提供することには2つの主要な側面があり、それらは次のサブセクションで議論されています。
The aim is to remove the sub-optimality of paths caused by multiple tunnels established between multiple Mobile Nodes and their Home Agents. Such a solution will seek to minimize the number of Home Agents along the path, by bypassing some of the Home Agent(s) from the original path. Unlike the scenario where no nesting is formed and only a single Home Agent exists along the path, bypassing one of the many Home Agents can still be effective.
目的は、複数のモバイルノードとそのホームエージェントの間に確立された複数のトンネルによって引き起こされるパスのサブ最適性を削除することです。このようなソリューションは、元の経路からホームエージェントの一部をバイパスすることにより、パスに沿ったホームエージェントの数を最小限に抑えようとします。ネストが形成されず、パスに沿って単一のホームエージェントのみが存在するシナリオとは異なり、多くのホームエージェントの1つをバイパスすることはまだ効果的です。
Solutions for Nested Mobility scenarios can usually be divided into two cases based on whether the nesting involves Mobile IPv6 hosts or only involves Mobile Routers. Since Mobile IPv6 defines its own Route Optimization mechanism, providing an optimal path for such hosts will require interaction with the protocol and may require an altering of the messages exchanged during the Return Routability procedure with the Correspondent Node.
ネストされたモビリティシナリオのソリューションは、通常、ネストにモバイルIPv6ホストが含まれるか、モバイルルーターのみが関与するかに基づいて、2つのケースに分割できます。モバイルIPv6は独自のルート最適化メカニズムを定義するため、そのようなホストに最適なパスを提供するには、プロトコルとの相互作用が必要であり、特派員ノードとの返品ルー上の手順中に交換されるメッセージの変更が必要になる場合があります。
An example of this approach include Reverse Routing Header (RRH) [10].
このアプローチの例には、逆ルーティングヘッダー（RRH）[10]が含まれます。
The aim is to reduce the amplification effect of nested tunnels due to the nesting of tunnels between the Visiting Mobile Node and its Home Agent within the tunnel between the parent Mobile Router and the parent Mobile Router's Home Agent. Such a solution will seek to minimize the number of tunnels, possibly by collapsing the amount of tunnels required through some form of signaling between Mobile Nodes, or between Mobile Nodes and their Home Agents, or by using routing headers to route packets through a discovered path. These limit the consequences of the amplification effect of nested tunnels, and at best, the performance of a nested mobile network will be the same as though there were no nesting at all.
目的は、親モバイルルーターと親モバイルルーターのホームエージェントの間のトンネル内の訪問モバイルノードとそのホームエージェントの間のトンネルのネストにより、ネストされたトンネルの増幅効果を減らすことです。このようなソリューションは、モバイルノード間、モバイルノードとそのホームエージェント間の何らかの形のシグナリングを介して必要なトンネルの量を崩壊させることにより、トンネルの数を最小限に抑えようとします。。これらは、ネストされたトンネルの増幅効果の結果を制限し、せいぜいネストされたモバイルネットワークの性能は、ネストがまったくないのと同じです。
Examples of this approach include the Reverse Routing Header (RRH) [10], Access Router Option (ARO) [11], and Nested Path Info (NPI) [12].
このアプローチの例には、リバースルーティングヘッダー（RRH）[10]、アクセスルーターオプション（ARO）[11]、およびネストされたパス情報（NPI）[12]が含まれます。
An infrastructure-based optimization is an approach where optimization is carried out fully in the infrastructure. One example is to make use of Mobility Anchor Points (MAPs) such as defined in HMIPv6 [13] to optimize routes between themselves. Another example is to make use of proxy Home Agent such as defined in the global Home Agent to Home Agent (HAHA) protocol [14]. A proxy Home Agent acts as a Home Agent for the Mobile Node, and acts as a Mobile Node for the Home Agent, Correspondent Node, Correspondent Router, and other proxies. In particular, the proxy Home Agent terminates the MRHA tunnel and the associated encryption, extracts the packets, and re-encapsulates them to the destination. In this case, proxy Home Agents are distributed in the infrastructure and each Mobile Router binds to the closest proxy. The proxy, in turn, performs a primary binding with a real Home Agent for that Mobile Router. Then, the proxy might establish secondary bindings with other Home Agents or proxies in the infrastructure, in order to improve the end-to-end path. In this case, the proxies discover each other using some form of Next Hop Resolution Protocol, establish a tunnel and exchange the relevant Mobile Network Prefix information in the form of explicit prefix routes.
インフラストラクチャベースの最適化は、インフラストラクチャで最適化が完全に実行されるアプローチです。1つの例は、HMIPv6 [13]で定義されているようなモビリティアンカーポイント（マップ）を使用して、自分自身の間のルートを最適化することです。別の例は、グローバルホームエージェントからホームエージェント（HAHA）プロトコル[14]で定義されているようなプロキシホームエージェントを使用することです。プロキシホームエージェントは、モバイルノードのホームエージェントとして機能し、ホームエージェント、特派員ノード、特派員ルーター、およびその他のプロキシのモバイルノードとして機能します。特に、プロキシホームエージェントは、MRHAトンネルと関連する暗号化を終了し、パケットを抽出し、それらを宛先に再エンコールします。この場合、プロキシホームエージェントはインフラストラクチャに配布され、各モバイルルーターは最も近いプロキシにバインドします。このプロキシは、そのモバイルルーターの実際のホームエージェントとの主要なバインディングを実行します。その後、プロキシは、エンドツーエンドのパスを改善するために、インフラストラクチャの他のホームエージェントまたはプロキシとの二次的なバインディングを確立する可能性があります。この場合、プロキシは何らかの形の次のホップ解像度プロトコルを使用して互いに発見し、トンネルを確立し、関連するモバイルネットワークプレフィックス情報を明示的なプレフィックスルートの形で交換します。
Alternatively, another approach is to use prefix delegation. Here, each Mobile Router in a nested mobile network is delegated a Mobile Network Prefix from the access router using DHCP Prefix Delegation [15]. Each Mobile Router also autoconfigures its Care-of Address from this delegated prefix. In this way, the Care-of Addresses of each Mobile Router are all formed from an aggregatable address space starting from the access router. This may be used to eliminate the multiple tunnels caused by nesting of Mobile Nodes.
または、別のアプローチがプレフィックス委任を使用することです。ここでは、ネストされたモバイルネットワーク内の各モバイルルーターは、DHCPプレフィックス委任[15]を使用して、アクセスルーターからモバイルネットワークプレフィックスを委任されます。また、各モバイルルーターは、この委任されたプレフィックスからそのケアのケアを自動構成します。このようにして、各モバイルルーターのケアアドレスはすべて、アクセスルーターから始まる集計可能なアドレススペースから形成されます。これは、モバイルノードのネストによって引き起こされる複数のトンネルを排除するために使用できます。
A Route Optimization solution may seek to improve the communications between two Mobile Network Nodes within a nested mobile network. This would avoid traffic being injected out of the nested mobile network and route them within the nested mobile network. An example is the optimized route taken between MNN1 and MNN2 in Figure 3 below.
ルート最適化ソリューションは、ネストされたモバイルネットワーク内の2つのモバイルネットワークノード間の通信を改善しようとする場合があります。これにより、ネストされたモバイルネットワークからトラフィックが注入され、ネストされたモバイルネットワーク内にルーティングされます。例としては、以下の図3にMNN1とMNN2の間で撮影された最適化されたルートがあります。
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +------------------------------+
| MR1_HA |----| Internet |-----CN
+--------+ +--------------+---------------+
|
+----+----+
| MR1 |
+----+----+
|
---+-----------+-----------+---
| | |
+---+---+ +---+---+ +---+---+
| MR5 | | MR2 | | MR4 |
+---+---+ +---+---+ +---+---+
| | |
---+--- +---+---+ ---+---
MNN2 | MR3 | MNN3
+---+---+
|
----+----
MNN1
Figure 3: An Example of a Nested Mobile Network
図3：ネストされたモバイルネットワークの例
One may be able to extend a well-designed NEMO Route Optimization for "Nested Mobility Optimization" (see Section 3.2) to provide for such kind of Intra-NEMO optimization, where, for example in Figure 3, MNN1 is treated as a Correspondent Node by MR5/MNN2, and MNN2 is treated as a Correspondent Node by MR3/MNN1.
「ネストされたモビリティの最適化」のための適切に設計されたNEMOルート最適化を拡張して（セクション3.2を参照）、このような種類のネモ最適化を提供することができます。MR5/MNN2およびMNN2は、MR3/MNN1によって特派員ノードとして扱われます。
Another possibility is for the "Non-Nested NEMO Route Optimization" technique (see Section 3.1) to be applied here. Using the same example of communication between MNN1 and MNN2, both MR3 and MR2 can treat MR5 as Correspondent Routers for MNN2, and MR5 treats MR3 and MR2 as Correspondent Routers for MNN1. An example of this approach is [16], which has the Mobile Routers announce their Mobile Network Prefixes to other Mobile Routers in the same nested Mobile Network.
もう1つの可能性は、「ネモ以外のNEMOルート最適化」手法（セクション3.1を参照）をここに適用することです。MNN1とMNN2の間の通信の同じ例を使用して、MR3とMR2の両方がMR5をMNN2の特派員ルーターとして扱うことができ、MR5はMR3とMR2をMNN1の特派員ルーターとして扱います。このアプローチの例は[16]です。これは、モバイルルーターが同じネストされたモバイルネットワークの他のモバイルルーターにモバイルネットワークのプレフィックスを発表しています。
Yet another approach is to flatten any nested Mobile Network so that all nested Mobile Network Nodes appear to be virtually on the same link. Examples of such approaches include delegating a single prefix to the nested Mobile Network, having Mobile Routers to perform Neighbor Discovery on behalf of their Mobile Network Nodes, and exposing a single prefix over the entire mobile network using a Mobile Ad-Hoc (MANET) protocol. In particular, it might prove useful to develop a new type of MANET, specialized for the NEMO problem, a MANET for NEMO (MANEMO). The MANEMO will optimize the formation of the nested NEMO and maintain inner connectivity, whether or not a connection to the infrastructure can be established.
さらに別のアプローチは、ネストされたモバイルネットワークをフラット化して、ネストされたすべてのモバイルネットワークノードがほぼ同じリンク上にあるように見えることです。このようなアプローチの例には、ネストされたモバイルネットワークに単一のプレフィックスを委任すること、モバイルネットワークノードに代わって近隣発見を実行するためのモバイルルーターがあること、モバイルアドホック（MANET）プロトコルを使用してモバイルネットワーク全体に単一のプレフィックスを公開することが含まれます。。特に、Nemoの問題、Nemo（Manemo）のマネに特化した新しいタイプのマネを開発することが有用であることが証明されるかもしれません。マネモは、インフラストラクチャへの接続を確立できるかどうかにかかわらず、ネストされたネモの形成を最適化し、内部の接続性を維持します。
Although Route Optimization can bring benefits as described in Section 2, the scenarios described in Section 3 do so with some tradeoffs. This section explores some general issues that may impact a NEMO Route Optimization mechanism.
セクション2で説明されているように、ルートの最適化は利点をもたらすことができますが、セクション3で説明されているシナリオは、いくつかのトレードオフでそうしています。このセクションでは、NEMOルート最適化メカニズムに影響を与える可能性のある一般的な問題を調査します。
The nodes involved in performing Route Optimization would be expected to exchange additional signaling messages in order to establish Route Optimization. The required amount of signaling depends on the solution, but is likely to exceed the amount required in the home Binding Update procedure defined in NEMO Basic Support. The amount of signaling is likely to increase with the increasing number of Mobile Network Nodes and/or Correspondent Nodes, and may be amplified with nesting of mobile networks. It may scale to unacceptable heights, especially to the resource-scarce mobile node, which typically has limited power, memory, and processing capacity.
ルート最適化の実行に伴うノードは、ルートの最適化を確立するために追加のシグナル伝達メッセージを交換することが期待されます。必要な量のシグナル伝達はソリューションに依存しますが、NEMOの基本的なサポートで定義されているホームバインディングアップデート手順に必要な量を超える可能性があります。シグナリングの量は、モバイルネットワークノードおよび/または特派員ノードの数が増加すると増加する可能性が高く、モバイルネットワークのネスティングで増幅される可能性があります。通常、電力、メモリ、処理能力が制限されているリソーススカースモバイルノード、特にリソーススカースモバイルノードに焦点を当てることができません。
This may lead to an issue that impacts NEMO Route Optimization, known as the phenomenon of "Binding Update Storm", or more generally, "Signaling Storm". This occurs when a change in point of attachment of the mobile network is accompanied with a sudden burst of signaling messages, resulting in temporary congestion, packet delays, or even packet loss. This effect will be especially significant for wireless environment where bandwidth is relatively limited.
これは、「バインディングアップデートストーム」の現象として知られるNEMOルートの最適化に影響を与える問題につながる可能性があります。これは、モバイルネットワークのアタッチメントのポイントの変更に、シグナル伝達メッセージの突然のバーストが伴い、一時的な混雑、パケットの遅延、またはパケット損失をもたらすと発生します。この効果は、帯域幅が比較的限られているワイヤレス環境では特に重要です。
It is possible to moderate the effect of Signaling Storm by incorporating mechanisms such as spreading the transmissions burst of signaling messages over a longer period of time, or aggregating the signaling messages.
長期間にわたってシグナル伝達メッセージの伝達バーストを広めるか、シグナリングメッセージの集計などのメカニズムを組み込むことにより、シグナリングストームの効果を緩和することが可能です。
Even so, the amount of signaling required might be overwhelming, since large mobile networks (such as those deployed on a train or plane) may potentially have a large number of flows with a large number of Correspondent Nodes. This might suggest a need to have some adaptive behavior that depends on the amount of signaling required versus the effort needed to tunnel home.
それでも、大規模なモバイルネットワーク（列車や飛行機に展開されているものなど）が多数の特派員ノードを備えた多数のフローがある可能性があるため、必要なシグナリングの量は圧倒的である可能性があります。これは、必要なシグナルの量と家に帰宅するために必要な努力に依存する適応行動が必要であることを示唆するかもしれません。
It is expected that NEMO Route Optimization will be more complicated than NEMO Basic Support. Thus, complexity of nodes that are required to incorporate new functionalities to support NEMO Route Optimization would be higher than those required to provide NEMO Basic Support.
NEMOルートの最適化は、NEMOの基本的なサポートよりも複雑になると予想されます。したがって、NEMOルートの最適化をサポートするために新しい機能を組み込むために必要なノードの複雑さは、NEMOの基本的なサポートを提供するために必要なものよりも高くなります。
Coupled with the increased complexity, nodes that are involved in the establishment and maintenance of Route Optimization will have to bear the increased processing load. If such nodes are mobile, this may prove to be a significant cost due to the limited power and processing resources such devices usually have.
複雑さの増加と相まって、ルートの最適化の確立とメンテナンスに関与するノードは、処理荷重の増加を負担する必要があります。そのようなノードがモバイルである場合、これは、そのようなデバイスが通常持っている電力と処理のリソースが限られているため、かなりのコストであることが判明する可能性があります。
Due to the diversity of locations of different nodes that Mobile Network Node may signal with and the complexity of NEMO Route Optimization procedure that may cause several rounds of signaling messages, a NEMO Route Optimization procedure may take a longer time to finish its handoff than that in NEMO Basic Support. This may exacerbate the overall delay during handoffs and further cause performance degradation of the applications running on Mobile Network Nodes.
モバイルネットワークノードが信号を送る可能性のあるさまざまなノードの場所の多様性と、数回のシグナリングメッセージを引き起こす可能性のあるNemoルート最適化手順の複雑さにより、Nemoルート最適化手順は、ハンドオフを終了するのに時間がかかる場合があります。NEMOの基本的なサポート。これにより、ハンドオフ中の全体的な遅延が悪化し、モバイルネットワークノードで実行されているアプリケーションのパフォーマンスのパフォーマンス劣化がさらに悪化する可能性があります。
Another NEMO-specific delay during handoff is that in a nested mobile network, a child Mobile Network Node may need to detect or be notified of the handoff of its parent Mobile Router so that it can begin signaling its own Correspondent Entities. Apart from the compromise of mobility transparency and location privacy (see Section 4.7 and Section 4.8), this mechanism also increases the delay during handoffs.
ハンドオフ中のもう1つのNEMO固有の遅延は、ネストされたモバイルネットワークでは、子のモバイルネットワークノードが親モバイルルーターのハンドオフを検出または通知する必要があるため、独自の特派員エンティティの合図を開始できることです。モビリティの透明性と場所のプライバシーの妥協とは別に（セクション4.7およびセクション4.8を参照）、このメカニズムはハンドオフ中の遅延も増加させます。
Some of the solutions for Mobile IPv6, such as Fast Handovers for Mobile IPv6 [17], may be able to alleviate the increase in handoff delay.
モバイルIPv6 [17]の高速ハンドオーバーなど、モバイルIPv6のソリューションの一部は、ハンドオフ遅延の増加を軽減できる可能性があります。
In order to support NEMO Route Optimization, some nodes need to be changed or upgraded. Smaller number of nodes required to be changed will allow for easier adoption of the NEMO Route Optimization solution in the Internet and create less impact on existing Internet infrastructure. The number and the types of nodes involved with new functionalities also affect how much of the route is optimized. In addition, it may also be beneficial to reuse existing protocols (such as Mobile IPv6) as much as possible.
NEMOルートの最適化をサポートするには、一部のノードを変更またはアップグレードする必要があります。変更する必要があるノードの数が少ないと、インターネットでNEMOルート最適化ソリューションを採用しやすくなり、既存のインターネットインフラストラクチャへの影響が少なくなります。新しい機能に関係するノードの数とタイプは、ルートの最適化にも影響します。さらに、既存のプロトコル（モバイルIPv6など）を可能な限り再利用することも有益かもしれません。
Possible nodes that may be required to change include the following:
変更に必要な可能性のあるノードには、以下が含まれます。
o Local Fixed Nodes
o ローカル固定ノード
It may prove to be difficult to introduce new functionalities at Local Fixed Nodes, since by definition, any IPv6 node can be a Local Fixed Node. This might mean that only those Local Fixed Nodes that are modified can enjoy the benefits of Route Optimization.
定義上、どのIPv6ノードもローカル固定ノードになる可能性があるため、ローカル固定ノードで新しい機能を導入することは困難であることが証明される場合があります。これは、変更されたローカル固定ノードのみがルート最適化の利点を享受できることを意味する場合があります。
o Visiting Mobile Nodes
o モバイルノードにアクセスします
Visiting Mobile Nodes in general should already implement Mobile IPv6 functionalities, and since Mobile IPv6 is a relatively new standard, there is still a considerable window to allow mobile devices to implement new functionalities.
一般的にモバイルノードにアクセスすると、モバイルIPv6機能を既に実装する必要があります。モバイルIPv6は比較的新しい標準であるため、モバイルデバイスが新しい機能を実装できるようにするためのかなりのウィンドウがまだあります。
o Mobile Routers
o モバイルルーター
It is expected that Mobile Routers will implement new functionalities in order to support Route Optimization.
ルートの最適化をサポートするために、モバイルルーターが新しい機能を実装することが期待されています。
o Access Routers
o アクセスルーター
Some approaches require access routers, or nodes in the access network, to implement some new functionalities. It may prove to be difficult to do so, since access routers are, in general, standard IPv6 routers.
いくつかのアプローチでは、いくつかの新しい機能を実装するために、アクセスルーターまたはアクセスネットワーク内のノードが必要です。アクセスルーターは一般に標準のIPv6ルーターであるため、そうするのが難しいことが証明される場合があります。
o Home Agents
o ホームエージェント
It is relatively easier for new functionalities to be implemented in Home Agents.
新しい機能がホームエージェントで実装されるのは比較的簡単です。
o Correspondent Nodes
o 特派員ノード
It may prove to be difficult to introduce new functionalities at Correspondent Nodes, since by definition, any IPv6 node can be a Correspondent Node. This might mean that only those Correspondent Nodes that are modified can enjoy the benefits of Route Optimization.
定義上、すべてのIPv6ノードが特派員ノードになる可能性があるため、特派員ノードに新しい機能を導入することは困難であることが証明される場合があります。これは、変更された特派員ノードのみがルート最適化の利点を享受できることを意味する場合があります。
o Correspondent Routers
o 特派員ルーター
Correspondent Routers are new entities introduced for the purpose of Route Optimization, and therefore new functionalities can be defined as needed.
特派員ルーターは、ルートの最適化を目的として導入された新しいエンティティであるため、必要に応じて新しい機能を定義できます。
One issue that is related to the need for new functionalities as described in Section 4.4 is the need to detect the existence of such functionalities. In these cases, a detection mechanism might be helpful to allow the initiator of Route Optimization to detect whether support for the new functionalities is available. Furthermore, it might be advantageous to have a graceful fall back procedure if the required functionalities are unavailable.
セクション4.4で説明されている新しい機能の必要性に関連する1つの問題は、そのような機能の存在を検出する必要性です。これらの場合、ルート最適化の開始剤が新しい機能のサポートが利用可能かどうかを検出できるように、検出メカニズムが役立つ場合があります。さらに、必要な機能が利用できない場合、優雅なフォールバック手順を持つことが有利かもしれません。
Given the same number of nodes, the number of Route Optimization sessions would usually be more than the number of NEMO Basic Support tunnels. If all Route Optimization sessions of a mobile network are maintained by a single node (such as the Mobile Router), this would mean that the single node has to keep track of the states of all Route Optimization sessions. This may lead to scalability issues especially when that single node is a mobile device with limited memory and processing resources.
同じ数のノードを考えると、ルート最適化セッションの数は通常、NEMO基本サポートトンネルの数を超えます。モバイルネットワークのすべてのルート最適化セッションが単一のノード（モバイルルーターなど）によって維持されている場合、これは単一ノードがすべてのルート最適化セッションの状態を追跡する必要があることを意味します。これにより、特にその単一ノードがメモリと処理リソースが限られているモバイルデバイスである場合、スケーラビリティの問題につながる可能性があります。
A similar scalability issue may be faced by a Correspondent Entity as well if it maintains many route-optimized sessions on behalf of a Correspondent Node(s) with a large number of Mobile Routers.
同様のスケーラビリティの問題は、特派員ノードに代わって多数のモバイルルーターを使用して多くのルートを最適化したセッションを維持している場合、特派員エンティティが直面する可能性があります。
One advantage of NEMO Basic Support is that the Mobile Network Nodes need not be aware of the actual location and mobility of the mobile network. With some approaches for Route Optimization, it might be necessary to reveal the point of attachment of the Mobile Router to the Mobile Network Nodes. This may mean a tradeoff between mobility transparency and Route Optimization.
NEMOの基本的なサポートの利点の1つは、モバイルネットワークノードがモバイルネットワークの実際の位置とモビリティに注意する必要がないことです。ルート最適化のためのいくつかのアプローチを使用すると、モバイルネットワークノードへのモバイルルーターのアタッチメントのポイントを明らかにする必要があるかもしれません。これは、モビリティの透明性とルートの最適化とのトレードオフを意味する場合があります。
Without Route Optimization, the Correspondent Nodes are not aware of the actual location and mobility of the mobile network and its Mobile Network Nodes. To achieve Route Optimization, it might be necessary to reveal the point of attachment of the Mobile Router to the Correspondent Nodes. This may mean a tradeoff between location privacy [18] and Route Optimization.
ルートの最適化がなければ、特派員ノードは、モバイルネットワークとそのモバイルネットワークノードの実際の位置とモビリティを認識していません。ルートの最適化を実現するには、特派員ノードへのモバイルルーターのアタッチメントのポイントを明らかにする必要があるかもしれません。これは、ロケーションプライバシー[18]とルートの最適化との間のトレードオフを意味する場合があります。
In Mobile IPv6, a mobile node can decide whether or not to perform Route Optimization with a given Correspondent Node. Thus, the mobile node is in control of whether to trade location privacy for an optimized route. In NEMO Route Optimization, if the decision to perform Router Optimization is made by the Mobile Router, it will be difficult for Mobile Network Nodes to control the decision of having this tradeoff.
モバイルIPv6では、モバイルノードは、特定の特派員ノードでルート最適化を実行するかどうかを決定できます。したがって、モバイルノードは、最適化されたルートとロケーションプライバシーを交換するかどうかを制御しています。NEMOルートの最適化では、ルーターの最適化を実行する決定がモバイルルーターによって行われた場合、モバイルネットワークノードがこのトレードオフの決定を制御することは困難です。
As Mobile Router and Home Agent usually belong to the same administration domain, it is likely that there exists a security association between them, which is leveraged by NEMO Basic Support to conduct the home Binding Update in a secure way. However, NEMO Route Optimization usually involves nodes from different domains (for example, Mobile Router and Correspondent Entity); thus, the existence of such a security association is not a valid assumption in many deployment scenarios. For this reason, the security protection of NEMO Route Optimization signaling message is considered "weaker" than that in NEMO Basic Support. It is expected that some additional security mechanisms are needed to achieve the same or similar level of security as in NEMO Basic Support.
モバイルルーターとホームエージェントは通常同じ管理ドメインに属しているため、それらの間にセキュリティ関連が存在する可能性があります。これは、安全な方法でホームバインディングアップデートを実施するためにNEMOの基本的なサポートによって活用されています。ただし、NEMOルートの最適化には、通常、異なるドメイン（モバイルルーターや特派員エンティティなど）からのノードが含まれます。したがって、このようなセキュリティ協会の存在は、多くの展開シナリオでは有効な仮定ではありません。このため、NEMOルート最適化シグナル伝達メッセージのセキュリティ保護は、NEMO基本サポートよりも「弱い」と見なされます。NEMOの基本サポートと同じレベルまたは類似のセキュリティを達成するためには、いくつかの追加のセキュリティメカニズムが必要であることが期待されています。
When considering security issues of NEMO Route Optimization, it might be useful to keep in mind some of the security issues considered when Mobile IPv6 Route Optimization was designed as documented in [19].
NEMOルートの最適化のセキュリティ問題を検討する場合、[19]で文書化されているようにモバイルIPv6ルートの最適化が設計されたときに考慮されるセキュリティ問題の一部に留意することが有用かもしれません。
NEMO Basic Support is designed so that all legacy Mobile Network Nodes (such as those that are not aware of the mobility of the network they are in, and those that do not understand any mobility protocols) can still reach and be reached from the Internet. Some Route Optimization schemes, however, require that all Mobile Routers implement the same Route Optimization scheme in order for them to operate. Thus, a nested Mobile Router may not be able to achieve Route Optimization if it is attached to a legacy Local Fixed Router.
NEMOの基本サポートは、すべてのレガシーモバイルネットワークノード（自分がいるネットワークのモビリティを認識していないもの、モビリティプロトコルを理解していないもの）がインターネットから到達して届くように設計されています。ただし、一部のルート最適化スキームでは、すべてのモバイルルーターが動作するために同じルート最適化スキームを実装する必要があります。したがって、ネストされたモバイルルーターは、レガシーローカル固定ルーターに接続されている場合、ルートの最適化を実現できない場合があります。
As described in Section 3, there are various different approaches to achieve Route Optimization in Network Mobility Support. In this section, we attempt to analyze the vast solution space of NEMO Route Optimization by asking the following questions:
セクション3で説明されているように、ネットワークモビリティサポートでルート最適化を実現するためのさまざまなアプローチがあります。このセクションでは、次の質問をすることにより、NEMOルート最適化の広大なソリューションスペースを分析しようとします。
1. Which entities are involved?
1. どのエンティティが関与していますか？
2. Who initiates Route Optimization? When?
2. 誰がルートの最適化を開始しますか？いつ？
3. How is Route Optimization capabilities detected?
3. ルート最適化機能はどのように検出されますか？
4. How is the address of the Mobile Network Node represented?
4. モバイルネットワークノードのアドレスはどのように表されていますか？
5. How is the Mobile Network Node's address bound to location?
5. モバイルネットワークノードのアドレスはどのように場所に縛られていますか？
6. How is signaling performed?
6. シグナリングはどのように実行されますか？
7. How is data transmitted?
7. データはどのように送信されますか？
8. What are the security considerations?
8. セキュリティ上の考慮事項は何ですか？
There are many combinations of entities involved in Route Optimization. When considering the role each entity plays in Route Optimization, one has to bear in mind the considerations described in Section 4.4 and Section 4.5. Below is a list of combinations to be discussed in the following sub-sections:
ルートの最適化に関与するエンティティの多くの組み合わせがあります。各エンティティがルート最適化で果たす役割を検討する場合、セクション4.4およびセクション4.5で説明した考慮事項を念頭に置く必要があります。以下は、次のサブセクションで説明する組み合わせのリストです。
o Mobile Network Node and Correspondent Node
o モバイルネットワークノードと特派員ノード
o Mobile Router and Correspondent Node
o モバイルルーターと特派員ノード
o Mobile Router and Correspondent Router
o モバイルルーターと特派員ルーター
o Entities in the Infrastructure
o インフラストラクチャのエンティティ
A Mobile Network Node can establish Route Optimization with its Correspondent Node, possibly the same way as a Mobile Node establishes Route Optimization with its Correspondent Node in Mobile IPv6. This would achieve the most optimal route, since the entire end-to-end path is optimized. However, there might be scalability issues since both the Mobile Network Node and the Correspondent Node may need to maintain many Route Optimization sessions. In addition, new functionalities would be required for both the Mobile Network Node and Correspondent Node. For the Mobile Network Node, it needs to be able to manage its mobility, and possibly be aware of the mobility of its upstream Mobile Router(s). For the Correspondent Node, it needs to be able to maintain the bindings sent by the Mobile Network Nodes.
モバイルネットワークノードは、モバイルノードがモバイルIPv6の特派員ノードを使用してルート最適化を確立するのと同じように、特派員ノードを使用してルート最適化を確立できます。これは、エンドツーエンドのパス全体が最適化されるため、最も最適なルートを実現します。ただし、モバイルネットワークノードと特派員ノードの両方が多くのルート最適化セッションを維持する必要がある場合があるため、スケーラビリティの問題がある可能性があります。さらに、モバイルネットワークノードと特派員ノードの両方に新しい機能が必要です。モバイルネットワークノードの場合、モビリティを管理し、上流のモバイルルーターのモビリティを認識できる必要があります。特派員ノードの場合、モバイルネットワークノードから送信されるバインディングを維持できる必要があります。
Alternatively, the Mobile Router can establish Route Optimization with a Correspondent Node on behalf of the Mobile Network Node. Since all packets to and from the Mobile Network Node must transit the Mobile Router, this effectively achieves an optimal route for the entire end-to-end path as well. Compared with Section 5.1.1, the scalability issue here may be remedied since it is possible for the Correspondent Node to maintain only one session with the Mobile Router if it communicates with many Mobile Network Nodes associated with the same Mobile Router. Furthermore, with the Mobile Router handling Route Optimization, there is no need for Mobile Network Nodes to implement new functionalities. However, new functionality is likely to be required on the Correspondent Node. An additional point of consideration is the amount of state information the Mobile Router is required to maintain. Traditionally, it has been generally avoided having state information in the routers to increase proportionally with the number of pairs of communicating peers.
または、モバイルルーターは、モバイルネットワークノードに代わって、特派員ノードを使用してルート最適化を確立できます。モバイルネットワークノードとの間のすべてのパケットは、モバイルルーターをトランジットする必要があるため、これはエンドツーエンドパス全体に最適なルートを効果的に実現します。セクション5.1.1と比較して、ここのスケーラビリティの問題は、同じモバイルルーターに関連付けられた多くのモバイルネットワークノードと通信する場合、特派員ノードがモバイルルーターと1つのセッションのみを維持できるため、改善される可能性があります。さらに、モバイルルーター処理ルートの最適化により、新しい機能を実装するためのモバイルネットワークノードは必要ありません。ただし、特派員ノードでは新しい機能が必要になる可能性があります。考慮事項は、モバイルルーターが維持するために必要な状態情報の量です。伝統的に、通信仲間のペアの数に比例して増加するために、ルーターに状態情報があることは一般に避けられてきました。
Approaches involving Mobile Routers and Correspondent Routers are described in Section 3.1. The advantage of these approaches is that no additional functionality is required for the Correspondent Node and Mobile Network Nodes. In addition, location privacy is relatively preserved, since the current location of the mobile network is only revealed to the Correspondent Router and not to the Correspondent Node (please refer to Section 5.8.3 for more discussions). Furthermore, if the Mobile Router and Correspondent Router exchange prefix information, this approach may scale well since a single Route Optimization session between the Mobile Router and Correspondent Router can achieve Route Optimization between any Mobile Network Node in the mobile network, and any Correspondent Node managed by the Correspondent Router.
モバイルルーターと特派員ルーターを含むアプローチについては、セクション3.1で説明します。これらのアプローチの利点は、特派員ノードとモバイルネットワークノードに追加の機能が必要ないことです。さらに、モバイルネットワークの現在の場所は特派員のルーターにのみ明らかにされており、特派員ノードではないため、場所のプライバシーは比較的保存されています（詳細については、セクション5.8.3を参照してください）。さらに、モバイルルーターと特派員ルーター交換プレフィックス情報が情報を使用すると、モバイルルーターと特派員ルーター間の単一のルート最適化セッションがモバイルネットワーク内の任意のモバイルネットワークノードと、管理された任意の特派員ノード間のルート最適化を実現できるため、このアプローチが十分に拡大する場合があります。特派員ルーターによって。
The main concern with this approach is the need for a mechanism to allow the Mobile Router to detect the presence of the Correspondent Router (see Section 5.3 for details), and its security impact. Both the Mobile Router and the Correspondent Router need some means to verify the validity of each other. This is discussed in greater detail in Section 5.8.
このアプローチの主な関心事は、モバイルルーターが特派員ルーターの存在を検出できるようにするメカニズムの必要性です（詳細については、セクション5.3を参照）、およびそのセキュリティインパクトです。モバイルルーターと特派員ルーターの両方が、互いの妥当性を検証するための何らかの手段が必要です。これについては、セクション5.8で詳しく説明します。
A deployment consideration with respect to the use of Correspondent Router is the location of the Correspondent Router relative to the Correspondent Node. On one hand, deploying the Correspondent Router nearer to the Correspondent Node would result in a more optimal path. On the other hand, a Correspondent Router that is placed farther away from the Correspondent Node can perform Route Optimization on behalf of more Correspondent Nodes.
特派員ルーターの使用に関する展開の考慮事項は、特派員ノードに対する特派員ルーターの位置です。一方では、特派員のルーターを特派員ノードの近くに展開すると、より最適なパスが発生します。一方、特派員ノードから遠く離れて配置された特派員ルーターは、より多くの特派員ノードに代わってルート最適化を実行できます。
Approaches using entities in the infrastructure are described in Section 3.3. The advantages of this approach include, firstly, not requiring new functionalities to be implemented on the Mobile Network Nodes and Correspondent Nodes, and secondly, having most of the complexity shifted to nodes in the infrastructure. However, one main issue with this approach is how the Mobile Router can detect the presence of such entities, and why the Mobile Router should trust these entities. This may be easily addressed if such entity is a Home Agent of the Mobile Router (such as in the global Home Agent to Home Agent protocol [14]). Another concern is that the resulting path may not be a true optimized one, since it depends on the relative positions of the infrastructure entities with respect to the mobile network and the Correspondent Node.
インフラストラクチャ内のエンティティを使用したアプローチについては、セクション3.3で説明します。このアプローチの利点には、第一に、モバイルネットワークノードと特派員ノードに新しい機能を実装する必要がないこと、および第二に、ほとんどの複雑さがインフラストラクチャのノードにシフトしたことが含まれます。ただし、このアプローチの主な問題の1つは、モバイルルーターがそのようなエンティティの存在を検出する方法と、モバイルルーターがこれらのエンティティを信頼する理由です。これは、そのようなエンティティがモバイルルーターのホームエージェントである場合（ホームエージェントプロトコルのグローバルホームエージェント[14]など）、簡単に対処できます。別の懸念は、結果として得られるパスは、モバイルネットワークおよび特派員ノードに関するインフラストラクチャエンティティの相対的な位置に依存するため、真のパスではない可能性があることです。
Having determined the entities involved in the Route Optimization in the previous sub-section, the next question is which of these entities should initiate the Route Optimization session. Usually, the node that is moving (i.e., Mobile Network Node or Mobile Router) is in the best position to detect its mobility. Thus, in general, it is better for the mobile node to initiate the Route Optimization session in order to handle the topology changes in any kind of mobility pattern and achieve the optimized route promptly. However, when the mobile node is within a nested mobile network, the detection of the mobility of upstream Mobile Routers may need to be conveyed to the nested Mobile Network Node. This might incur longer signaling delay as discussed in Section 4.3.
以前のサブセクションのルート最適化に関与するエンティティを決定した場合、次の問題は、これらのエンティティのどれがルート最適化セッションを開始するかです。通常、移動しているノード（つまり、モバイルネットワークノードまたはモバイルルーター）は、モビリティを検出するのに最適な位置にあります。したがって、一般に、モバイルノードは、あらゆる種類のモビリティパターンのトポロジの変更を処理し、最適化されたルートを迅速に達成するために、ルート最適化セッションを開始する方が良いです。ただし、モバイルノードがネストされたモバイルネットワーク内にある場合、アップストリームモバイルルーターのモビリティの検出は、ネストされたモバイルネットワークノードに伝える必要がある場合があります。これにより、セクション4.3で説明したように、より長いシグナル伝達遅延が発生する可能性があります。
Some solution may enable the node on the correspondent side to initiate the Route Optimization session in certain situations. For instance, when the Route Optimization state that is already established on the Correspondent Entity is about to expire but the communication is still active, depending on the policy, the Correspondent Entity may initiate a Route Optimization request with the mobile node side.
一部のソリューションにより、特派員側のノードが特定の状況でルート最適化セッションを開始できるようにする場合があります。たとえば、特派員エンティティですでに確立されているルート最適化状態が期限切れになっているが、ポリシーに応じて通信が依然としてアクティブである場合、特派員エンティティはモバイルノード側でルート最適化要求を開始する場合があります。
There is also the question of when Route Optimization should be initiated. Because Route Optimization would certainly incur tradeoffs of various forms, it might not be desirable for Route Optimization to be performed for any kind of traffic. This is, however, implementation specific and policy driven.
また、ルートの最適化をいつ開始するかという問題もあります。ルートの最適化は確かにさまざまな形式のトレードオフが発生するため、あらゆる種類のトラフィックに対してルートの最適化を実行することは望ましくないかもしれません。ただし、これは実装固有のポリシー駆動型です。
A related question is how often signaling messages should be sent to maintain the Route Optimization session. Typically, signaling messages are likely to be sent whenever there are topological changes. The discussion in Section 4.1 should be considered. In addition, a Lifetime value is often used to indicate the period of validity for the Route Optimization session. Signaling messages would have to be sent before the Lifetime value expires in order to maintain the Route Optimization session. The choice of Lifetime value needs to balance between different considerations. On one hand, a short Lifetime value would increase the amount of signaling overhead. On the other hand, a long Lifetime value may expose the Correspondent Entity to the risk of having an obsolete binding cache entry, which creates an opportunity for an attacker to exploit.
関連する質問は、ルート最適化セッションを維持するために、信号メッセージを送信する頻度です。通常、シグナリングメッセージは、トポロジカルの変更がある場合はいつでも送信される可能性があります。セクション4.1の議論を考慮する必要があります。さらに、ルート最適化セッションの妥当性の期間を示すために、寿命の価値がよく使用されます。ルート最適化セッションを維持するために、生涯値が失効する前に信号メッセージを送信する必要があります。生涯価値の選択は、さまざまな考慮事項のバランスをとる必要があります。一方では、短い寿命の値は、オーバーヘッドのシグナリング量を増やします。一方、長い寿命の価値は、特派員のエンティティを廃止されたバインディングキャッシュエントリを持つリスクにさらされる可能性があり、攻撃者が悪用する機会を生み出します。
The question here is how the initiator of Route Optimization knows whether the Correspondent Entity supports the functionality required to established a Route Optimization session. The usual method is for the initiator to attempt Route Optimization with the Correspondent Entity. Depending on the protocol specifics, the initiator may receive (i) a reply from the Correspondent Entity indicating its capability, (ii) an error message from the Correspondent Entity, or (iii) no response from the Correspondent Entity within a certain time period. This serves as an indication of whether or not the Correspondent Entity supports the required functionality to establish Route Optimization. This form of detection may incur additional delay as a penalty when the Correspondent Entity does not have Route Optimization capability, especially when the Route Optimization mechanism is using in-band signaling.
ここでの問題は、ルート最適化のイニシエーターが、通信事業体がルート最適化セッションを確立するために必要な機能をサポートするかどうかをどのように知っているかです。通常の方法は、イニシエーターが特派員エンティティとのルート最適化を試みることです。プロトコルの詳細に応じて、イニシエーターは（i）その能力を示す特派員のエンティティからの返信、（ii）特派員のエンティティからのエラーメッセージ、または（iii）特定の期間内の特派員エンティティからの応答を受け取ることができます。これは、通信事業体が必要な機能をサポートしてルートの最適化を確立するかどうかの兆候として機能します。この形式の検出は、特にルート最適化メカニズムがインバンドシグナリングを使用している場合、特別なエンティティがルート最適化機能を持たない場合、ペナルティとして追加の遅延を発生する可能性があります。
When the Correspondent Entity is not the Correspondent Node but a Correspondent Router, an immediate question is how its presence can be detected. One approach is for the initiator to send an Internet Control Message Protocol (ICMP) message containing the address of the Correspondent Node to a well-known anycast address reserved for all Correspondent Routers [7][8]. Only the Correspondent Router that is capable of terminating the Route Optimization session on behalf of the Correspondent Node will respond. Another way is to insert a Router Alert Option (RAO) into a packet sent to the Correspondent Node [9]. Any Correspondent Router en route will process the Router Alert Option and send a response to the Mobile Router.
特派員のエンティティが特派員ノードではなく、特派員ルーターである場合、即時の質問は、その存在をどのように検出できるかです。1つのアプローチは、イニシエーターが、すべての特派員ルーター[7] [8]に予約されている有名なAnycastアドレスに特派員ノードのアドレスを含むインターネットコントロールメッセージプロトコル（ICMP）メッセージを送信することです。特派員ノードに代わってルート最適化セッションを終了できる特派員ルーターのみが応答します。別の方法は、ルーターアラートオプション（RAO）を特派員ノードに送信したパケットに挿入することです[9]。途中の特派員ルーターは、ルーターアラートオプションを処理し、モバイルルーターへの応答を送信します。
Both approaches need to consider the possibility of multiple Correspondent Routers responding to the initiator, and both approaches will generate additional traffic or processing load to other routers. Furthermore, both approaches have yet to consider how the initiator can verify the authenticity of the Correspondent Routers that responded.
どちらのアプローチでも、複数の特派員ルーターがイニシエーターに応答する可能性を考慮する必要があり、どちらのアプローチも他のルーターに追加のトラフィックまたは処理負荷を生成します。さらに、両方のアプローチでは、イニシエーターが応答した特派員ルーターの信頼性をどのように検証できるかをまだ検討していません。
Normally, Route Optimization would mean that a binding between the address of a Mobile Network Node and the location of the mobile network is registered at the Correspondent Entity. Before exploring different ways of binding (see Section 5.5), one must first ask how the address of the Mobile Network Node is represented. Basically, there are two ways to represent the Mobile Network Node's address:
通常、ルートの最適化は、モバイルネットワークノードのアドレスとモバイルネットワークの場所の間の拘束力が、特派員エンティティに登録されていることを意味します。さまざまなバインド方法を調査する前に（セクション5.5を参照）、まずモバイルネットワークノードのアドレスがどのように表現されるかを尋ねる必要があります。基本的に、モバイルネットワークノードのアドレスを表す方法は2つあります。
o inferred by the use of the Mobile Network Prefix, or
o モバイルネットワークプレフィックスの使用によって推測される、または
o explicitly specifying the address of the Mobile Network Node.
o モバイルネットワークノードのアドレスを明示的に指定します。
Using the Mobile Network Prefix would usually mean that the initiator is the Mobile Router, and has the benefit of binding numerous Mobile Network Nodes with one signaling. However, it also means that if location privacy is compromised, the location privacy of an entire Mobile Network Prefix would be compromised.
モバイルネットワークのプレフィックスを使用すると、通常、イニシエーターがモバイルルーターであることを意味し、1つのシグナル伝達で多数のモバイルネットワークノードをバインドする利点があります。ただし、場所のプライバシーが損なわれた場合、モバイルネットワークプレフィックス全体のロケーションプライバシーが損なわれることも意味します。
On the other hand, using the Mobile Network Node's address would mean that either the initiator is the Mobile Network Node itself or the Mobile Router is initiating Route Optimization on behalf of the Mobile Network Node. Initiation by the Mobile Network Node itself means that the Mobile Network Node must have new functionalities implemented, while initiation by the Mobile Router means that the Mobile Router must maintain some Route Optimization states for each Mobile Network Node.
一方、モバイルネットワークノードのアドレスを使用すると、イニシエーターがモバイルネットワークノード自体であるか、モバイルルーターがモバイルネットワークノードに代わってルート最適化を開始していることを意味します。モバイルネットワークノード自体による開始は、モバイルネットワークノードに新しい機能を実装する必要があることを意味しますが、モバイルルーターによる開始は、モバイルルーターが各モバイルネットワークノードのルート最適化状態を維持する必要があることを意味します。
In order for route to be optimized, it is generally necessary for the Correspondent Entity to create a binding between the address and the location of the Mobile Network Node. This can be done in the following ways:
ルートを最適化するためには、一般に、特派員エンティティがアドレスとモバイルネットワークノードの場所の間に拘束力を発揮する必要があります。これは、次の方法で行うことができます。
o binding the address to the location of the parent Mobile Router,
o アドレスを親モバイルルーターの場所にバインドし、
o binding the address to a sequence of upstream Mobile Routers, and
o アドレスを上流のモバイルルーターのシーケンスに結合し、
o binding the address to the location of the root Mobile Router.
o アドレスをルートモバイルルーターの位置にバインドします。
These are described in the following sub-sections.
これらは、次のサブセクションで説明されています。
By binding the address of Mobile Network Node to the location of its parent Mobile Router, the Correspondent Entity would know how to reach the Mobile Network Node via the current location of the parent Mobile Router. This can be done by:
モバイルネットワークノードのアドレスを親モバイルルーターの位置にバインドすることにより、特派員エンティティは、親モバイルルーターの現在の場所を介してモバイルネットワークノードに到達する方法を知っています。これは以下で行うことができます：
o Binding Update with Mobile Network Prefix
o モバイルネットワークプレフィックスによるバインディングアップデート
This can be viewed as a logical extension to NEMO Basic Support, where the Mobile Router would send binding updates containing one or more Mobile Network Prefix options to the Correspondent Entity. The Correspondent Entity having received the Binding Update, can then set up a bi-directional tunnel with the Mobile Router at the current Care-of Address of the Mobile Router, and inject a route to its routing table so that packets destined for addresses in the Mobile Network Prefix would be routed through the bi-directional tunnel.
これは、NEMO Basic Supportの論理的拡張機能と見なすことができます。ここでは、モバイルルーターが1つ以上のモバイルネットワークプレフィックスオプションを含むバインディングアップデートを特派員エンティティに送信します。バインディングアップデートを受け取った特派員エンティティは、モバイルルーターの現在のケアアドレスにモバイルルーターを備えた双方向トンネルを設定し、ルーティングテーブルへのルートを注入して、モバイルネットワークのプレフィックスは、双方向トンネルを介してルーティングされます。
Note that in this case, the address of the Mobile Network Node is implied by the Mobile Network Prefix (see Section 5.4).
この場合、モバイルネットワークノードのアドレスはモバイルネットワークのプレフィックスによって暗示されていることに注意してください（セクション5.4を参照）。
o Sending Information of Parent Mobile Router
o 親モバイルルーターの情報を送信します
This involves the Mobile Network Node sending the information of its Mobile Router to the Correspondent Entity, thus allowing the Correspondent Entity to establish a binding between the address of the Mobile Network Node to the location of the parent Mobile Router. An example of such an approach would be [11].
これには、モバイルネットワークノードがモバイルルーターの情報を特派員エンティティに送信するため、特派員エンティティがモバイルネットワークノードのアドレス間の親モバイルルーターの場所への拘束力を確立できるようにします。このようなアプローチの例は[11]です。
o Mobile Router as a Proxy
o プロキシとしてのモバイルルーター
Another approach is for the parent Mobile Router to act as a "proxy" for its Mobile Network Nodes. In this case, the Mobile Router uses the standard Mobile IPv6 Route Optimization procedure to bind the address of a Mobile Network Node to the Mobile Router's Care-of Address. For instance, when the Mobile Network Node is a Local Fixed Node without Mobile IPv6 Route Optimization functionality, the Mobile Router may initiate the Return Routability procedure with a Correspondent Node on behalf of the Local Fixed Node. An example of such an approach would be [20][21][22].
別のアプローチは、親モバイルルーターがモバイルネットワークノードの「プロキシ」として機能することです。この場合、モバイルルーターは標準のモバイルIPv6ルート最適化手順を使用して、モバイルネットワークノードのアドレスをモバイルルーターのケアアドレスに結合します。たとえば、モバイルネットワークノードがモバイルIPv6ルート最適化機能のないローカル固定ノードである場合、モバイルルーターは、ローカル固定ノードに代わって特派員ノードを使用して返品ルー上の手順を開始する場合があります。このようなアプローチの例は[20] [21] [22]です。
On the other hand, if the Mobile Network Node is a Visiting Mobile Node, it might be necessary for the Visiting Mobile Node to delegate the rights of Route Optimization signaling to the Mobile Router (see [23] for an example of such delegation). With this delegation, either the Visiting Mobile Network Node or the Mobile Router can initiate the Return Routability procedure with the Correspondent Node. For the case where the Return Routability procedure is initiated by the Visiting Mobile Node, the Mobile Router will have to transparently alter the content of the Return Routability signaling messages so that packets sent from the Correspondent Node to the Visiting Node will be routed to the Care-of Address of the Mobile Router once Route Optimization is established. The case where the Return Routability procedure is initiated by the Mobile Router is similar to the case where the Mobile Network Node is a Local Fixed Node.
一方、モバイルネットワークノードが訪問モバイルノードである場合、訪問するモバイルノードがルート最適化の権利をモバイルルーターに委任する必要があるかもしれません（そのような委任の例については[23]を参照）。この委任により、訪問するモバイルネットワークノードまたはモバイルルーターのいずれかが、特派員ノードで返品ルー上の手順を開始できます。訪問するモバイルノードによって返品ルー上の手順が開始される場合、モバイルルーターは、クレスコンテントノードから訪問ノードに送信されたパケットがケアにルーティングされるように、リターンルー上のルーティング可能性シグナリングメッセージのコンテンツを透過的に変更する必要があります。 - ルート最適化が確立された後のモバイルルーターのアドレス。モバイルルーターによって返品ルー上の手順が開始される場合は、モバイルネットワークノードがローカル固定ノードである場合に似ています。
For all of the approaches listed above, when the Mobile Network Node is deeply nested within a Mobile Network, the Correspondent Entity would need to gather Binding Updates from all the upstream Mobile Routers in order to build the complete route to reach the Mobile Network Node. This increases the complexity of the Correspondent Entity, as the Correspondent Entity may need to perform multiple binding cache look-ups before it can construct the complete route.
上記のすべてのアプローチについて、モバイルネットワークノードがモバイルネットワーク内に深くネストされている場合、特派員エンティティは、モバイルネットワークノードに到達するための完全なルートを構築するために、すべての上流のモバイルルーターからバインディングアップデートを収集する必要があります。これにより、特派員エンティティが完全なルートを構築する前に複数のバインディングキャッシュルックアップを実行する必要がある可能性があるため、特派員エンティティの複雑さが高まります。
Other than increasing the complexity of the Correspondent Entity, these approaches may incur extra signaling overhead and delay for a nested Mobile Network Node. For instance, every Mobile Router on the upstream of the Mobile Network Node needs to send Binding Updates to the Correspondent Entity. If this is done by the upstream Mobile Routers independently, it may incur additional signaling overhead. Also, since each Binding Update takes a finite amount of time to reach and be processed by the Correspondent Entity, the delay from the time an optimized route is changed till the time the change is registered on the Correspondent Entity will increase proportionally with the number of Mobile Routers on the upstream of the Mobile Network Node (i.e., the level of nesting of the Mobile Network Node).
特派員エンティティの複雑さを増やす以外に、これらのアプローチは、ネストされたモバイルネットワークノードの追加のシグナリングオーバーヘッドと遅延が発生する可能性があります。たとえば、モバイルネットワークノードの上流にあるすべてのモバイルルーターは、特派員エンティティにバインディングアップデートを送信する必要があります。これがアップストリームモバイルルーターによって独立して行われた場合、追加のシグナリングオーバーヘッドが発生する可能性があります。また、各バインディングアップデートには、特派員エンティティによって到達して処理されるのに有限の時間がかかるため、最適化されたルートが変更されるまでの遅延は、特派員エンティティの変更が登録されるまでに変更されます。モバイルネットワークノードの上流のモバイルルーター（つまり、モバイルネットワークノードのネストレベル）。
For "Binding Update with Mobile Network Prefix" and "Sending Information of Parent Mobile Router", new functionality is required at the Correspondent Entity, whereas "Mobile Router as a Proxy" keeps the functionality of the Correspondent Entity the same as a Mobile IPv6 Correspondent Node. However, this is done at an expense of the Mobile Routers, since in "Mobile Router as a Proxy", the Mobile Router must maintain state information for every Route Optimization session its Mobile Network Nodes have. Furthermore, in some cases, the Mobile Router needs to look beyond the standard IPv6 headers for ingress and egress packets, and alter the packet contents appropriately (this may impact end-to-end integrity, see 5.8.2).
「モバイルネットワークプレフィックスによるバインディングアップデート」および「親モバイルルーターの情報の送信」の場合、特派員エンティティで新しい機能が必要であり、「プロキシとしてのモバイルルーター」は、特派員エンティティの機能をモバイルIPv6特派員と同じに保ちますノード。ただし、これはモバイルルーターの費用で行われます。これは、モバイルルーターがモバイルネットワークノードが持っているすべてのルート最適化セッションの状態情報を維持する必要があるため、モバイルルーターを維持する必要があるためです。さらに、場合によっては、モバイルルーターは、標準のIPv6ヘッダーをイングレスパケットと出口パケットのヘッダーを超えて検索し、パケットのコンテンツを適切に変更する必要があります（これは、エンドツーエンドの完全性に影響を与える可能性があります。5.8.2を参照）。
One advantage shared by all the approaches listed here is that only mobility protocol is affected. In other words, no modification is required on other existing protocols (such as Neighbor Discovery). There is also no additional requirement on existing infrastructure (such as the access network).
ここにリストされているすべてのアプローチで共有される利点の1つは、モビリティプロトコルのみが影響を受けることです。言い換えれば、他の既存のプロトコル（近隣発見など）では変更は必要ありません。既存のインフラストラクチャ（アクセスネットワークなど）には追加の要件もありません。
In addition, having upstream Mobile Routers send Binding Updates independently means that the Correspondent Entity can use the same binding cache entries of upstream Mobile Routers to construct the complete route to two Mobile Network Nodes that have common upstream Mobile Routers. This may translate to lower memory consumption since the Correspondent Entity need not store one complete route per Mobile Network Node when it is having Route Optimization sessions with multiple Mobile Network Nodes from the same mobile network.
さらに、アップストリームモバイルルーターがバインディングアップデートを独立して送信することは、特派員エンティティがアップストリームモバイルルーターの同じバインディングキャッシュエントリを使用して、共通のアップストリームモバイルルーターを持つ2つのモバイルネットワークノードへの完全なルートを構築できることを意味します。これは、同じモバイルネットワークから複数のモバイルネットワークノードを使用してルート最適化セッションを備えている場合、特派員エンティティがモバイルネットワークノードごとに1つの完全なルートを保存する必要がないため、メモリ消費量を削減することになります。
For a nested Mobile Network Node, it might be more worthwhile to bind its address to the sequence of points of attachment of upstream Mobile Routers. In this way, the Correspondent Entity can build a complete sequence of points of attachment from a single transmission of the binding information. Examples using this approach are [10] and [12].
ネストされたモバイルネットワークノードの場合、そのアドレスをアップストリームモバイルルーターのアタッチメントのシーケンスにバインドする価値があるかもしれません。このようにして、特派員のエンティティは、拘束力のある情報の単一の送信からの完全な添付ポイントの完全なシーケンスを構築できます。このアプローチを使用した例は[10]と[12]です。
Different from Section 5.5.1, this approach constructs the complete route to a specific Mobile Network Node at the mobile network side, thus offering the opportunity to reduce the signaling overhead. Since the complete route is conveyed to the Correspondent Entity in a single transmission, it is possible to reduce the delay from the time an optimized route is changed till the time the change is registered on the Correspondent Entity to its minimum.
セクション5.5.1とは異なるこのアプローチは、モバイルネットワーク側の特定のモバイルネットワークノードへの完全なルートを構築し、信号のオーバーヘッドを減らす機会を提供します。完全なルートは単一の送信で特派員エンティティに伝達されるため、最適化されたルートが変更されるまでの遅延を減らすことができます。
One question that immediately comes to mind is how the Mobile Network Node gets hold of the sequence of locations of its upstream Mobile Routers. This is usually achieved by having such information inserted as special options in the Router Advertisement messages advertised by upstream Mobile Routers. To do so, not only must a Mobile Router advertise its current location to its Mobile Network Nodes, it must also relay information embedded in Router Advertisement messages it has received from its upstream Mobile Routers. This might imply a compromise of the mobility transparency of a mobile network (see Section 4.7). In addition, it also means that whenever an upstream Mobile Router changes its point of attachment, all downstream Mobile Network Nodes must perform Route Optimization signaling again, possibly leading to a "Signaling Storm" (see Section 4.1).
すぐに思い浮かぶ質問の1つは、モバイルネットワークノードが上流のモバイルルーターの位置をどのように保持するかです。これは通常、上流のモバイルルーターによって宣伝されているルーター広告メッセージに特別なオプションとしてそのような情報を挿入することによって達成されます。そのためには、モバイルルーターが現在の場所をモバイルネットワークノードに宣伝するだけでなく、上流のモバイルルーターから受け取ったルーター広告メッセージに埋め込まれた情報も中継する必要があります。これは、モバイルネットワークのモビリティ透明性の妥協を意味する可能性があります（セクション4.7を参照）。さらに、上流のモバイルルーターがアタッチメントポイントを変更するたびに、すべての下流のモバイルネットワークノードが再びルート最適化シグナリングを実行し、「シグナリングストーム」につながる可能性があることを意味します（セクション4.1を参照）。
A different method of conveying locations of upstream Mobile Routers is (such as used in [10]) where upstream Mobile Routers insert their current point of attachment into a Reverse Routing Header embedded within a packet sent by the Mobile Network Node. This may raise security concerns that will be discussed later in Section 5.8.2.
上流のモバイルルーターの位置を伝達する別の方法は（[10]で使用されるなど）、上流のモバイルルーターがモバイルネットワークノードによって送信されたパケットに埋め込まれた逆ルーティングヘッダーに現在のアタッチメントポイントを挿入する場合です。これにより、セクション5.8.2で後述するセキュリティの懸念が生じる可能性があります。
In order for a Correspondent Entity to bind the address of a Mobile Network Node to a sequence of locations of upstream Mobile Routers, new functionalities need to be implemented on the Correspondent Entity. The Correspondent Entity also needs to store the complete sequence of locations of upstream Mobile Routers for every Mobile Network Node. This may demand more memory compared to Section 5.5.1 if the same Correspondent Entity has a lot of Route Optimization sessions with Mobile Network Nodes from the same nested Mobile Network. In addition, some amount of modifications or extension to existing protocols is also required, such as a new type of IPv6 routing header or a new option in the Router Advertisement message.
特派員エンティティがモバイルネットワークノードのアドレスを上流のモバイルルーターの一連の場所にバインドするには、特派員エンティティに新しい機能を実装する必要があります。特派員エンティティは、すべてのモバイルネットワークノードの上流のモバイルルーターの場所の完全なシーケンスを保存する必要があります。同じ特派員エンティティが同じネストされたモバイルネットワークからのモバイルネットワークノードを使用して多くのルート最適化セッションを持っている場合、セクション5.5.1と比較してより多くのメモリが必要になる場合があります。さらに、新しいタイプのIPv6ルーティングヘッダーやルーター広告メッセージの新しいオプションなど、既存のプロトコルのいくつかの変更または拡張も必要です。
A third approach is to bind the address of the Mobile Network Node to the location of the root Mobile Router, regardless of how deeply nested the Mobile Network Node is within a nested Mobile Network. Whenever the Correspondent Entity needs to forward a packet to the Mobile Network Node, it only needs to forward the packet to this point of attachment. The mobile network will figure out how to forward the packet to the Mobile Network Node by itself. This kind of approach can be viewed as flattening the structure of a nested Mobile Network, so that it seems to the Correspondent Entity that every node in the Mobile Network is attached to the Internet at the same network segment.
3番目のアプローチは、モバイルネットワークノードがネストされたモバイルネットワーク内にどれだけ深くネストされているかに関係なく、モバイルネットワークノードのアドレスをルートモバイルルーターの位置にバインドすることです。特派員エンティティがパケットをモバイルネットワークノードに転送する必要があるときはいつでも、この添付ファイルにパケットを転送するだけです。モバイルネットワークは、パケットを単独でモバイルネットワークノードに転送する方法を把握します。この種のアプローチは、ネストされたモバイルネットワークの構造を平らにすると見なすことができます。そのため、モバイルネットワーク内のすべてのノードが同じネットワークセグメントのインターネットに接続されていると思われます。
There are various approaches to achieve this:
これを達成するためのさまざまなアプローチがあります：
o Prefix Delegation
o プレフィックス委任
Here, each Mobile Router in a nested mobile network is delegated a Mobile Network Prefix from the access router (such as using Dynamic Host Configuration Protocol (DHCP) Prefix Delegation [15]). Each Mobile Router also autoconfigures its Care-of Address from this delegated prefix. In this way, the Care-of Addresses of Mobile Routers are all from an aggregatable address space starting from the access router. A Mobile Network Node with Mobile IPv6 functionality may also autoconfigure its Care-of Address from this delegated prefix, and use standard Mobile IPv6 mechanism's to bind its Home Address to this Care-of Address.
ここでは、ネストされたモバイルネットワーク内の各モバイルルーターは、アクセスルーター（ダイナミックホスト構成プロトコル（DHCP）プレフィックス委任[15]を使用するなど）からモバイルネットワークプレフィックスを委任されます。また、各モバイルルーターは、この委任されたプレフィックスからそのケアのケアを自動構成します。このようにして、モバイルルーターのケアアドレスはすべて、アクセスルーターから始まる集計可能なアドレススペースからのものです。モバイルIPv6機能を備えたモバイルネットワークノードは、この委任されたプレフィックスからそのケアのケアを自動化し、標準のモバイルIPv6メカニズムを使用して、自宅の住所をこの住所に結合することもできます。
Examples of this approach include [24], [25], and [26].
このアプローチの例には、[24]、[25]、[26]が含まれます。
This approach has the advantage of keeping the implementations of Correspondent Nodes unchanged. However, it requires the access router (or some other entity within the access network) and Mobile Router to possess prefix delegation functionality, and also maintain information on what prefix is delegated to which node. How to efficiently assign a subset of Mobile Network Prefix to child Mobile Routers could be an issue because Mobile Network Nodes may dynamically join and leave with an unpredictable pattern. In addition, a change in the point of attachment of the root Mobile Router will also require every nested Mobile Router (and possibly Visiting Mobile Nodes) to change their Care-of Addresses and delegated prefixes. These will cause a burst of Binding Updates and prefix delegation activities where every Mobile Router and every Visiting Mobile Node start sending Binding Updates to their Correspondent Entities.
このアプローチには、特派員ノードの実装を変更しておくという利点があります。ただし、接頭辞委任機能を所有するには、アクセスルーター（またはアクセスネットワーク内の他のエンティティ）とモバイルルーターが必要であり、どのノードに委任されるかに関する情報も維持します。モバイルネットワークノードが動的に結合して予測不可能なパターンを残す可能性があるため、モバイルネットワークのプレフィックスのサブセットを子供モバイルルーターに効率的に割り当てる方法は問題になる可能性があります。さらに、ルートモバイルルーターのアタッチメントのポイントを変更するには、すべてのネストされたモバイルルーター（およびモバイルノードにアクセスする可能性が高い）には、アドレスの世話と委任されたプレフィックスを変更する必要があります。これらは、すべてのモバイルルーターとすべての訪問するモバイルノードが特派員エンティティにバインディングアップデートの送信を開始するバインディングの更新とプレフィックス委任アクティビティのバーストを引き起こします。
o Neighbor Discovery Proxy
o Neighbor Discovery Proxy
This approach (such as [27] and [28]) achieves Route Optimization by having the Mobile Router act as a Neighbor Discovery [29] proxy for its Mobile Network Nodes. The Mobile Router will configure a Care-of Address from the network prefix advertised by its access router, and also relay this prefix to its subnets. When a Mobile Network Node configures an address from this prefix, the Mobile Router will act as a Neighbor Discovery proxy on its behalf. In this way, the entire mobile network and its access network form a logical multilink subnet, thus eliminating any nesting.
このアプローチ（[27]や[28]など）は、モバイルルーターをモバイルネットワークノードの近隣発見[29]プロキシとして機能させることにより、ルートの最適化を実現します。モバイルルーターは、アクセスルーターによって宣伝されているネットワークプレフィックスからアドレスのケアを構成し、このプレフィックスをサブネットに中継します。モバイルネットワークノードがこのプレフィックスからアドレスを構成すると、モバイルルーターはその代わりに近隣発見プロキシとして機能します。このようにして、モバイルネットワーク全体とそのアクセスネットワークが論理的なマルチリンクサブネットを形成し、ネストを排除します。
This approach has the advantage of keeping the implementations of Correspondent Nodes unchanged. However, it requires the root Mobile Router to act as a Neighbor Discovery proxy for all the Mobile Network Nodes that are directly or indirectly attached to it. This increases the processing load of the root Mobile Router. In addition, a change in the point of attachment of the root Mobile Router will require every nested Mobile Router (and possibly Visiting Mobile Nodes) to change their Care-of Addresses. Not only will this cause a burst of Binding Updates where every Mobile Router and every Visiting Mobile Node start sending Binding Updates to their Correspondent Entities, it will also cause a burst of Duplicate Address Discovery messages to be exchanged between the mobile network and the access network. Furthermore, Route Optimization for Local Fixed Nodes is not possible without new functionalities implemented on the Local Fixed Nodes.
このアプローチには、特派員ノードの実装を変更しておくという利点があります。ただし、ルートモバイルルーターは、直接または間接的に接続されているすべてのモバイルネットワークノードの近隣発見プロキシとして機能する必要があります。これにより、ルートモバイルルーターの処理荷重が増加します。さらに、ルートモバイルルーターのアタッチメントのポイントを変更するには、すべてのネストされたモバイルルーター（およびモバイルノードにアクセスする可能性が高い）には、アドレスのケアを変更する必要があります。これにより、すべてのモバイルルーターとすべての訪問モバイルノードが特派員エンティティにバインディングアップデートの送信を開始するバインディングアップデートのバーストを引き起こすだけでなく、モバイルネットワークとアクセスネットワーク間で複製アドレスディスカバリーメッセージのバーストが交換されます。。さらに、ローカル固定ノードに新しい機能が実装されていない場合、ローカル固定ノードのルート最適化は不可能です。
o Hierarchical Registrations
o 階層登録
Hierarchical Registration involves Mobile Network Nodes (including nested Mobile Routers) registering themselves with either their parent Mobile Routers or the root Mobile Router itself. After registrations, Mobile Network Nodes would tunnel packets directly to the upstream Mobile Router they register with. At the root Mobile Router, packets tunneled from sub-Mobile Routers or Mobile Network Nodes are tunneled directly to the Correspondent Entities, thus avoiding nested tunneling.
階層登録には、親モバイルルーターまたはルートモバイルルーター自体に登録するモバイルネットワークノード（ネストされたモバイルルーターを含む）が含まれます。登録後、モバイルネットワークノードは、登録する上流のモバイルルーターに直接パケットをトンネルします。ルートモバイルルーターでは、サブモービルルーターまたはモバイルネットワークノードからトンネルされたパケットが特派員エンティティに直接トンネル化されているため、ネストされたトンネリングが回避されます。
One form of such an approach uses the principle of Hierarchical Mobile IPv6 [13], where the root Mobile Router acts as a Mobility Anchor Point. It is also possible for each parent Mobile Router to act as Mobility Anchor Points for its child Mobile Routers, thus forming a hierarchy of Mobility Anchor Points. One can also view these Mobility Anchor Points as local Home Agents, thus forming a cascade of mobile Home Agents. In this way, each Mobile Router terminates its tunnel at its parent Mobile Router. Hence, although there are equal numbers of tunnels as the level of nestings, there is no tunnel encapsulated within another.
このようなアプローチの1つの形式は、階層モバイルIPv6 [13]の原理を使用します。ここで、ルートモバイルルーターはモビリティアンカーポイントとして機能します。また、各親モバイルルーターが子供のモバイルルーターのモビリティアンカーポイントとして機能し、モビリティアンカーポイントの階層を形成することも可能です。また、これらのモビリティアンカーポイントを地元のホームエージェントと見なすことができ、モバイルホームエージェントのカスケードを形成することもできます。このようにして、各モバイルルーターは、親モバイルルーターでトンネルを終了します。したがって、ネストのレベルと同数のトンネルがありますが、別のものにカプセル化されたトンネルはありません。
Examples of this approach include [30], [31], [32], and [33].
このアプローチの例には、[30]、[31]、[32]、および[33]が含まれます。
An advantage of this approach is that the functionalities of the Correspondent Nodes are unchanged.
このアプローチの利点は、特派員ノードの機能が変更されていないことです。
o Mobile Ad-Hoc Routing
o モバイルアドホックルーティング
It is possible for nodes within a mobile network to use Mobile Ad-hoc routing for packet-forwarding between nodes in the same mobile network. An approach of doing so might involve a router acting as a gateway for connecting nodes in the mobile network to the global Internet. All nodes in the mobile network would configure their Care-of Addresses from one or more prefixes advertised by that gateway, while their parent Mobile Routers use Mobile Ad-hoc routing to forward packets to that gateway or other destinations inside the mobile network.
モバイルネットワーク内のノードは、同じモバイルネットワーク内のノード間のパケットフォワードにモバイルアドホックルーティングを使用することができます。そうするアプローチには、モバイルネットワーク内のノードをグローバルインターネットに接続するためのゲートウェイとして機能するルーターが含まれる場合があります。モバイルネットワーク内のすべてのノードは、そのゲートウェイによって宣伝されている1つ以上のプレフィックスからのケアアドレスを構成し、親モバイルルーターはモバイルアドホックルーティングを使用して、モバイルネットワーク内のそのゲートウェイまたは他の宛先にパケットを転送します。
One advantage that is common to all the approaches listed above is that local mobility of a Mobile Network Node within a nested mobile network is hidden from the Correspondent Entity.
上記のすべてのアプローチに共通する利点の1つは、ネストされたモバイルネットワーク内のモバイルネットワークノードのローカルモビリティが特派員エンティティから隠されていることです。
In general, Route Optimization signaling can be done either in-plane, off-plane, or both. In-plane signaling involves embedding signaling information into headers of data packets. A good example of in-plane signaling would be Reverse Routing Header [10]. Off-plane signaling uses dedicated signaling packets rather than embedding signaling information into headers of data packets. Proposals involving the sending of Binding Updates fall into this category.
一般に、ルート最適化シグナリングは、面内、オフプレーン、またはその両方で実行できます。面内シグナリングには、シグナリング情報をデータパケットのヘッダーに埋め込むことが含まれます。面内シグナル伝達の良い例は、逆ルーティングヘッダーです[10]。オフプレーンシグナリングは、信号情報をデータパケットのヘッダーに埋め込むのではなく、専用のシグナリングパケットを使用します。拘束力のある更新の送信を含む提案は、このカテゴリに分類されます。
The advantage of in-plane signaling is that any change in the mobile network topology can be rapidly propagated to the Correspondent Entity as long as there is a continuous stream of data to be transmitted. However, this might incur a substantial overhead on the data packets. Off-plane signaling, on the other hand, sends signaling messages independently from the data packet. This has the advantage of reducing the signaling overhead in situations where there are relatively fewer topological changes to the mobile network. However, data packet transmission may be disrupted while off-plane signaling takes place.
面内シグナル伝達の利点は、モバイルネットワークトポロジの変更が、伝達されるデータの連続ストリームがある限り、特派員エンティティに急速に伝播できることです。ただし、これにより、データパケットにかなりのオーバーヘッドが発生する可能性があります。一方、オフプレーンシグナルは、データパケットから独立して信号メッセージを送信します。これには、モバイルネットワークへのトポロジカルな変化が比較的少ない状況で、シグナリングオーバーヘッドを減らすという利点があります。ただし、プレーン外のシグナル伝達が行われている間、データパケット伝送が破壊される場合があります。
An entirely different method of signaling makes use of upper-layer protocols to establish the bindings between the address of a Mobile Network Node and the location of the mobile network. Such binding information can then be passed down to the IP layer to insert the appropriate entry in the Binding Cache or routing table. An example of such a mechanism is [34], which uses the Session Initiation Protocol (SIP) to relay binding information.
まったく異なるシグナリング方法では、上層層プロトコルを使用して、モバイルネットワークノードのアドレスとモバイルネットワークの場所の間にバインディングを確立します。そのようなバインディング情報をIPレイヤーに渡して、バインディングキャッシュまたはルーティングテーブルに適切なエントリを挿入できます。このようなメカニズムの例は[34]であり、セッション開始プロトコル（SIP）を使用してバインディング情報を中継します。
With Route Optimization established, one remaining question to be answered is how data packets can be routed to follow the optimized route. There are the following possible approaches:
ルートの最適化が確立されているため、回答すべき残りの質問の1つは、最適化されたルートに従うためにデータパケットをどのようにルーティングできるかです。次の可能なアプローチがあります：
o Encapsulations
o カプセル化
One way to route packets through the optimized path is to use IP-in-IP encapsulations [35]. In this way, the original packet can be tunneled to the location bound to the address of the Mobile Network Node using the normal routing infrastructure. Depending on how the location is bound to the address of the Mobile Network Node, the number of encapsulations required might vary.
最適化されたパスを介してパケットをルーティングする1つの方法は、IP-in-IPカプセルを使用することです[35]。このようにして、元のパケットは、通常のルーティングインフラストラクチャを使用して、モバイルネットワークノードのアドレスにバインドされた場所にトンネリングできます。場所がモバイルネットワークノードのアドレスに拘束される方法に応じて、必要なカプセルの数は異なる場合があります。
For instance, if the Correspondent Entity knows the full sequence of points of attachment, it might be necessary for there to be multiple encapsulations in order to forward the data packet through each point of attachment. This may lead to the need for multiple tunnels and extra packet header overhead. It is possible to alleviate this by using Robust Header Compression techniques [36][37][38] to compress the multiple tunnel packet headers.
たとえば、特派員エンティティが添付ファイルの完全なシーケンスを知っている場合、添付ファイルの各ポイントを介してデータパケットを転送するために複数のカプセルがあることが必要になる場合があります。これにより、複数のトンネルと余分なパケットヘッダーが頭上で必要になる可能性があります。堅牢なヘッダー圧縮技術[36] [37] [38]を使用して、複数のトンネルパケットヘッダーを圧縮することにより、これを軽減することができます。
o Routing Headers
o ルーティングヘッダー
A second way to route packets through the optimized path is to use routing headers. This is useful especially for the case where the Correspondent Entity knows the sequence of locations of upstream Mobile Routers (see Section 5.5.2), since a routing header can contain multiple intermediate destinations. Each intermediate destination corresponds to a point of attachment bound to the address of the Mobile Network Node.
最適化されたパスを介してパケットをルーティングする2番目の方法は、ルーティングヘッダーを使用することです。これは、特に、応答者のエンティティが、ルーティングヘッダーに複数の中間宛先を含めることができるため、上流のモバイルルーターの位置を知っている場合に役立ちます（セクション5.5.2を参照）。各中間宛先は、モバイルネットワークノードのアドレスにバインドされた添付ファイルに対応しています。
This requires the use of a new Routing Header type, or possibly an extension of the Type 2 Routing Header as defined by Mobile IPv6 to contain multiple addresses instead of only one.
これには、新しいルーティングヘッダータイプの使用、またはモバイルIPv6によって定義されたタイプ2ルーティングヘッダーの拡張機能が必要です。
o Routing Entries in Parent Mobile Routers
o 親モバイルルーターのルーティングエントリ
Yet another way is for parent Mobile Routers to install routing entries in their routing table that will route Route Optimized packets differently, most likely based on source address routing. This usually applies to approaches described in Section 5.5.3. For instance, the Prefix Delegation approach [24][25][26] would require parent Mobile Routers to route packets differently if the source address belongs to the prefix delegated from the access network.
さらに別の方法は、親モバイルルーターがルーティングテーブルにルーティングエントリをインストールすることです。これは、可能性が高いソースアドレスルーティングに基づいて、最適化されたパケットを異なる方法でルーティングすることです。これは通常、セクション5.5.3で説明されているアプローチに適用されます。たとえば、プレフィックス委任アプローチ[24] [25] [26]では、ソースアドレスがアクセスネットワークから委任されたプレフィックスに属している場合、親のモバイルルーターを異なる方法でルーティングする必要があります。
The most important security consideration in Route Optimization is certainly the security risks a Correspondent Entity is exposed to by creating a binding between the address of a Mobile Network Node and the specified location(s) of the mobile network. Generally, it is assumed that the Correspondent Entity and Mobile Network Node do not share any pre-existing security association. However, the Correspondent Entity must have some ways of verifying the authenticity of the binding specified, else it will be susceptible to various attacks described in [19], such as snooping (sending packets meant for a Mobile Network Node to an attacker) or denial-of-service (DoS) (flooding a victim with packets meant for a Mobile Network Node) attacks.
ルートの最適化における最も重要なセキュリティの考慮事項は、確かに、モバイルネットワークノードのアドレスとモバイルネットワークの指定された場所との間に拘束力のある拘束力を作成することにより、特派員エンティティがさらされるセキュリティリスクです。一般に、特派員エンティティとモバイルネットワークノードは、既存のセキュリティ協会を共有していないと想定されています。ただし、特派員エンティティには、指定されたバインディングの信頼性を検証する方法が必要です。そうでなければ、[19]で説明されているさまざまな攻撃（モバイルネットワークノードを対象としたパケットを攻撃者に送信）や拒否など、さまざまな攻撃を受けやすくなります。-of-service（dos）（モバイルネットワークノード向けのパケットで被害者に浸水）攻撃。
When the binding is performed between the address of the Mobile Network Node and one Care-of Address (possibly of the Mobile Router; see Section 5.5.1 and Section 5.5.3), the standard Return Routability procedure specified in Mobile IPv6 might be sufficient to provide a reasonable degree of assurance to the Correspondent Entity. This also allows the Correspondent Entity to re-use existing implementations. But in other situations, an extension to the Return Routability procedure might be necessary.
モバイルネットワークノードのアドレスと1つのアドレス（おそらくモバイルルーターのケア、セクション5.5.1およびセクション5.5.3を参照）の間でバインディングが実行されると、モバイルIPv6で指定された標準の返品ルーティング可能性手順で十分である可能性があります。特派員エンティティに合理的な程度の保証を提供する。これにより、特派員エンティティが既存の実装を再利用することもできます。しかし、他の状況では、返品ルー上の手順の拡張が必要になる場合があります。
For instance, consider the case where the Mobile Router sends a Binding Update containing Mobile Network Prefix information to the Correspondent Entity (see Section 5.5.1). Although the Return Routability procedure allows the Correspondent Entity to verify that the Care-of and Home Addresses of the Mobile Router are indeed collocated, it does not allow the Correspondent Entity to verify the validity of the Mobile Network Prefix. If the Correspondent Entity accepts the binding without verification, it will be exposed to attacks where the attacker tricks the Correspondent Entity into forwarding packets destined for a mobile network to the attacker (snooping) or victim (DoS); [39] discusses this security threat further.
たとえば、モバイルルーターがモバイルネットワークプレフィックス情報を含むバインディングアップデートを特派員エンティティに送信する場合を検討してください（セクション5.5.1を参照）。返品ルー上の手順では、特派員エンティティがモバイルルーターのケアアドレスとホームアドレスが実際に衝突していることを確認することができますが、特派員エンティティがモバイルネットワークのプレフィックスの有効性を確認することはできません。特派員のエンティティが検証なしで拘束力を受け入れる場合、攻撃者が特派員エンティティを攻撃者（スヌーピング）または被害者（DOS）にモバイルネットワークに向けた転送パケットに転送する攻撃にさらされます。[39]このセキュリティの脅威についてさらに議論しています。
The need to verify the validity of network prefixes is not constrained to Correspondent Entities. In approaches that involve the Correspondent Routers (see Section 5.1.3), there have been suggestions for the Correspondent Router to advertise the network prefix(es) of Correspondent Nodes that the Correspondent Router is capable of terminating Route Optimization on behalf of to Mobile Network Nodes. In such cases, the Mobile Network Nodes also need a mechanism to check the authenticity of such claims. Even if the Correspondent Routers do not advertise the network prefix, the Mobile Network Nodes also have the need to verify that the Correspondent Router is indeed a valid Correspondent Router for a given Correspondent Node.
ネットワークプレフィックスの妥当性を確認する必要性は、特派員のエンティティに制約されていません。特派員ルーターを含むアプローチ（セクション5.1.3を参照）では、特派員ルーターがモバイルネットワークに代わってルート最適化を終了できるという特派員ノードのネットワークプレフィックス（ES）を宣伝するための特派員ルーターに提案がありました。ノード。そのような場合、モバイルネットワークノードには、そのようなクレームの信頼性を確認するメカニズムも必要です。特派員ルーターがネットワークのプレフィックスを宣伝していない場合でも、モバイルネットワークノードは、特派員ルーターが実際に特定の特派員ノードの有効な特派員ルーターであることを確認する必要があります。
In Section 5.5.2, the registration signaling involves sending the information about one or more upstream Mobile Routers. The Correspondent Entity (or Home Agent) must also have the means to verify such information. Again, the standard Return Routability procedure as defined in [3] is inadequate here, as it is not designed to verify the reachability of an address over a series of upstream routers. An extension such as attaching a routing header to the Care-of Test (CoT) message to verify the authenticity of the locations of upstream Mobile Routers is likely to be needed. The risk, however, is not confined to Correspondent Entities. The Mobile Network Nodes are also under the threat of receiving false information from their upstream Mobile Routers, which they might pass to Correspondent Entities (this also implies that Correspondent Entities cannot rely on any security associations they have with the Mobile Network Nodes to establish the validity of address bindings). There are some considerations that this kind of on-path threat exists in the current Internet anyway especially when no (or weak) end-to-end protection is used.
セクション5.5.2では、登録信号には、1つ以上の上流のモバイルルーターに関する情報を送信します。特派員エンティティ（またはホームエージェント）には、そのような情報を検証する手段も必要です。繰り返しますが、[3]で定義されている標準の返品ルーティング可能性手順は、一連のアップストリームルーターのアドレスの到達可能性を検証するために設計されていないため、ここでは不十分です。ルーティングヘッダーをテスト（COT）メッセージに接続して、上流のモバイルルーターの位置の信頼性を確認するなどの拡張機能が必要になる可能性があります。ただし、リスクは特派員エンティティに限定されません。また、モバイルネットワークノードは、上流のモバイルルーターから誤った情報を受信するという脅威にさらされており、これを特派員エンティティに渡す可能性があります（これは、特派員がモバイルネットワークノードとのセキュリティ関連に依存して有効性を確立することができないことも意味します。アドレスバインディングの）。とにかく、この種のオンパスの脅威がとにかく現在のインターネットに存在するといういくつかの考慮事項があります。
All these concerns over the authenticity of addresses might suggest that perhaps a more radical and robust approach is necessary. This is currently under extensive study in various Working Groups of the IETF, and many related documents might be of interest here. For instance, in Secure Neighbor Discovery (SEND) [40], Cryptographically Generated Addresses (CGAs) [41] could be used to establish the ownership of Care-of Addresses. [42] employs the Home Agent to check the signaling messages sent by Mobile Routers to provide a way for Correspondent Entities to verify the authenticity of Mobile Network Prefixes specified. [18] documents various proposed enhancements to the Mobile IPv6 Route Optimization mechanism that might be applied to NEMO Route Optimization as well, such as [43], which allows the Correspondent Entity to authenticate a certain operator's Home Agent by verifying the associated certificate. The Host Identity Protocol (HIP) [44] with end-host mobility considerations [45] may be extended for NEMO Route Optimization as well.
アドレスの真正性に関するこれらの懸念はすべて、おそらくより根本的で堅牢なアプローチが必要であることを示唆するかもしれません。これは現在、IETFのさまざまなワーキンググループで広範な調査中であり、ここでは多くの関連文書が興味深いかもしれません。たとえば、安全な近隣発見（SEND）[40]では、暗号化されたアドレス（CGA）[41]を使用して、住所の世話の所有権を確立できます。[42]ホームエージェントを採用して、モバイルルーターから送信された信号メッセージをチェックして、指定されたモバイルネットワークプレフィックスの信頼性を確認する方法を提供します。[18]は、[43]などのNEMOルート最適化にも適用される可能性のあるモバイルIPv6ルート最適化メカニズムに提案されたさまざまな拡張機能を文書化します。ホストホストモビリティに関する考慮事項[45]を備えたホストIDプロトコル（HIP）[44]も、NEMOルートの最適化のために拡張される場合があります。
In addition, interested readers might want to refer to [46], which discussed the general problem of making Route Optimization in NEMO secure and explored some possible solution schemes. There is also a proposed mechanism in [23] for Mobile Network Node to delegate some rights to their Mobile Routers, which may be used to allow the Mobile Routers to prove their authenticities to Correspondent Entities when establishing Route Optimization sessions on behalf of the Mobile Network Nodes.
さらに、興味のある読者は[46]を参照したいと思うかもしれません。これは、NEMOのルート最適化を安全にするという一般的な問題について議論し、いくつかの可能なソリューションスキームを調査しました。また、モバイルネットワークノードには[23]に提案されたメカニズムもあります。モバイルルーターに何らかの権利を委任します。これは、モバイルネットワークに代わってルート最適化セッションを確立する際に、モバイルルーターが特派員エンティティに認証を証明できるようにするために使用できます。ノード。
In some of the approaches, such as "Mobile Router as a Proxy" in Section 5.5.1, the Mobile Router sends messages using the Mobile Network Node's address as the source address. This is done mainly to achieve zero new functionalities required at the Correspondent Entities and the Mobile Network Nodes. However, adopting such a strategy may interfere with existing or future protocols, most particularly security-related protocols. This is especially true when the Mobile Router needs to make changes to packets sent by Mobile Network Nodes. In a sense, these approaches break the end-to-end integrity of packets. A related concern is that this kind of approach may also require the Mobile Router to inspect the packet contents sent to/by Mobile Network Nodes. This may prove to be difficult or impossible if such contents are encrypted.
セクション5.5.1の「プロキシとしてのモバイルルーター」などのいくつかのアプローチでは、モバイルルーターはソースアドレスとしてモバイルネットワークノードのアドレスを使用してメッセージを送信します。これは、主に、特派員エンティティとモバイルネットワークノードで必要なゼロの新しい機能を達成するために行われます。ただし、このような戦略を採用すると、既存または将来のプロトコル、特にセキュリティ関連のプロトコルに干渉する可能性があります。これは、モバイルルーターがモバイルネットワークノードから送信されたパケットを変更する必要がある場合に特に当てはまります。ある意味では、これらのアプローチはパケットのエンドツーエンドの完全性を破ります。関連する懸念は、この種のアプローチでは、モバイルネットワークノードに送信されるパケットコンテンツを検査するためにモバイルルーターが必要になる場合もあります。これは、そのような内容が暗号化されている場合、困難または不可能であることが判明する可能性があります。
The concern over end-to-end integrity arises for the use of a Reverse Routing Header (see Section 5.5.2) too, since Mobile Routers would insert new contents to the header of packets sent by downstream Mobile Network Nodes. This makes it difficult for Mobile Network Nodes to protect the end-to-end integrity of such information with security associations.
モバイルルーターが下流のモバイルネットワークノードによって送信されたパケットのヘッダーに新しいコンテンツを挿入するため、逆ルーティングヘッダーを使用するためにエンドツーエンドの完全性に対する懸念が生じます（セクション5.5.2を参照）。これにより、モバイルネットワークノードは、そのような情報のエンドツーエンドの整合性をセキュリティ協会と保護することが困難になります。
Another security-related concern is the issue of location privacy. This document currently does not consider the location privacy threats caused by an on-path eavesdropper. For more information on that aspect, please refer to [18]. Instead, we consider the following three aspects to location privacy:
別のセキュリティ関連の懸念は、ロケーションプライバシーの問題です。現在、このドキュメントでは、オンパス盗聴者によって引き起こされる場所のプライバシーの脅威を考慮していません。その側面の詳細については、[18]を参照してください。代わりに、ロケーションのプライバシーについて次の3つの側面を検討します。
o Revelation of Location to Correspondent Entity
o 特派員エンティティへの場所の啓示
Route optimization is achieved by creating a binding between the address of the Mobile Network Node and the current location of the Mobile Network. It is thus inevitable that the location of the Mobile Network Node be revealed to the Correspondent Entity. The concern may be alleviated if the Correspondent Entity is not the Correspondent Node, since this implies that the actual traffic end point (i.e., the Correspondent Node) would remain ignorant of the current location of the Mobile Network Node.
ルートの最適化は、モバイルネットワークノードのアドレスとモバイルネットワークの現在の位置との間にバインディングを作成することで実現されます。したがって、モバイルネットワークノードの場所を特派員エンティティに明らかにすることは避けられません。これは、実際のトラフィックエンドポイント（すなわち、特派員ノード）がモバイルネットワークノードの現在の場所について無知なままであることを意味するため、特派員エンティティが特派員ノードではない場合、懸念が軽減される可能性があります。
o Degree of Revelation
o 啓示の程度
With network mobility, the degree of location exposure varies, especially when one considers nested mobile networks. For instance, for approaches that bind the address of the Mobile Network Node to the location of the root Mobile Router (see Section 5.5.3), only the topmost point of attachment of the mobile network is revealed to the Correspondent Entity. For approaches such as those described in Section 5.5.1 and Section 5.5.2, more information (such as Mobile Network Prefixes and current locations of upstream Mobile Routers) is revealed. Techniques such as exposing only locally-scoped addresses of intermediate upstream mobile routers to Correspondent Entities may be used to reduce the degree of revelation.
ネットワークのモビリティでは、特にネストされたモバイルネットワークを考慮すると、場所の露出の程度は異なります。たとえば、モバイルネットワークノードのアドレスをルートモバイルルーターの位置に結合するアプローチ（セクション5.5.3を参照）の場合、モバイルネットワークの最上位点のみが特派員エンティティに明らかになります。セクション5.5.1やセクション5.5.2で説明したアプローチなどのアプローチでは、詳細情報（モバイルネットワークのプレフィックスや上流のモバイルルーターの現在の場所など）が明らかになります。中間上流のモバイルルーターのローカルスコープアドレスのみを特派員エンティティに公開するなどの手法を使用して、啓示の程度を減らすことができます。
o Control of the Revelation
o 啓示のコントロール
When Route Optimization is initiated by the Mobile Network Node itself, it is in control of whether or not to sacrifice location privacy for an optimized route. However, if it is the Mobile Router that initiates Route Optimization (e.g., "Binding Update with Mobile Network Prefix" and "Mobile Router as a Proxy" in Section 5.5.1), then control is taken away from the Mobile Network Node. An additional signaling mechanism between the Mobile Network Node and its Mobile Router can be used in this case to prevent the Mobile Router from attempting Route Optimization for a given traffic stream.
ルートの最適化がモバイルネットワークノード自体によって開始される場合、最適化されたルートの位置プライバシーを犠牲にするかどうかを制御します。ただし、ルートの最適化（セクション5.5.1のプロキシとしての「モバイルネットワークプレフィックスによるバインディングアップデート」および「モバイルルーター」）を開始するのがモバイルルーターである場合、コントロールはモバイルネットワークノードから除外されます。この場合、モバイルネットワークノードとそのモバイルルーターの間の追加のシグナル伝達メカニズムを使用して、モバイルルーターが特定のトラフィックストリームのルート最適化を試みることを防ぐことができます。
The problem space of Route Optimization in the NEMO context is multifold and can be split into several work areas. It will be critical, though, that the solution to a given piece of the puzzle be compatible and integrated smoothly with others. With this in mind, this document attempts to present a detailed and in-depth analysis of the NEMO Route Optimization solution space by first describing the benefits a Route Optimization solution is expected to bring, then illustrating the different scenarios in which a Route Optimization solution applies, and next presenting some issues a Route Optimization solution might face. We have also asked ourselves some of the basic questions about a Route Optimization solution. By investigating different possible answers to these questions, we have explored different aspects to a Route Optimization solution. The intent of this work is to enhance our common understanding of the Route Optimization problem and solution space.
NEMOコンテキストでのルート最適化の問題空間は多様化であり、いくつかの作業領域に分割できます。ただし、パズルの特定のピースの解決策が互換性があり、他の人とスムーズに統合されることが重要です。これを念頭に置いて、このドキュメントは、最初にルート最適化ソリューションがもたらすことが期待される利点を最初に説明し、ルート最適化ソリューションが適用されるさまざまなシナリオを説明することにより、NEMOルート最適化ソリューションソリューションスペースの詳細かつ詳細な分析を提示しようとします。、そして次に、ルート最適化ソリューションが直面する可能性のあるいくつかの問題を提示します。また、ルート最適化ソリューションに関する基本的な質問のいくつかを自問しました。これらの質問に対するさまざまな可能な答えを調査することにより、ルート最適化ソリューションのさまざまな側面を調査しました。この作業の目的は、ルートの最適化問題とソリューションスペースの共通の理解を高めることです。
This is an informational document that analyzes the solution space of NEMO Route Optimization. Security considerations of different approaches are described in the relevant sections throughout this document. Particularly, please refer to Section 4.9 for a brief discussion of the security concern with respect to Route Optimization in general, and Section 5.8 for a more detailed analysis of the various Route Optimization approaches.
これは、NEMOルートの最適化のソリューションスペースを分析する情報文書です。さまざまなアプローチのセキュリティ上の考慮事項は、このドキュメント全体の関連セクションで説明されています。特に、さまざまなルート最適化アプローチのより詳細な分析については、一般的なルート最適化に関するセキュリティの懸念に関する簡単な議論については、セクション4.9を参照してください。セクション5.8を参照してください。
The authors wish to thank the co-authors of previous versions from which this document is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki Ohnishi, Felix Wu, and Souhwan Jung. In addition, sincere appreciation is also extended to Jari Arkko, Carlos Jesus Bernardos, Greg Daley, Thierry Ernst, T.J. Kniveton, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa, and Patrick Wetterwald for their various contributions.
著者は、この文書が導き出された以前のバージョンの共著者、マルコ・モルテニ、パイク・ウンキョン、裕子、フェリックス・ウー、スーワン・ジョンの共著者に感謝したいと考えています。さらに、誠実な感謝は、ジャリ・アークコ、カルロス・イエス・バーナルドス、グレッグ・デイリー、ティエリー・エルンスト、T.J。Kniveton、Erik Nordmark、Alexandru Petrescu、Hesham Soliman、Ryuji Wakikawa、Patrick Wetterwaldのさまざまな貢献をしています。
[1] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007.
[1] Ng、C.、Thubert、P.、Watari、M。、およびF. Zhao、「ネットワークモビリティルート最適化問題ステートメント」、RFC 4888、2007年7月。
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[2] Devarapalli、V.、Wakikawa、R.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、RFC 3963、2005年1月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[3] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[4] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.
[4] エルンスト、T。、「ネットワークモビリティサポートの目標と要件」、RFC 4886、2007年7月。
[5] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[5] Mather、J。およびM. Kojo、「Mobility関連用語」、RFC 3753、2004年6月。
[6] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[6] エルンスト、T。、およびH-Y。Lach、「ネットワークモビリティサポート用語」、RFC 4885、2007年7月。
[7] Wakikawa, R., Koshiba, S., Uehara, K., and J. Murai, "ORC: Optimized Route Cache Management Protocol for Network Mobility", 10th International Conference on Telecommunications, vol 2, pp 1194-1200, February 2003.
[7] Wakikawa、R.、Koshiba、S.、Uehara、K。、およびJ. Murai、「ORC：Network Mobilityの最適化されたルートキャッシュ管理プロトコル」、第10回電気通信に関する国際会議、Vol 2、pp 1194-1200、2003年2月。
[8] Wakikawa, R. and M. Watari, "Optimized Route Cache Protocol (ORC)", Work in Progress, November 2004.
[8] Wakikawa、R。およびM. Watari、「最適化されたルートキャッシュプロトコル（ORC）」、2004年11月、Work in Progress。
[9] Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo, "Route Optimization Scheme based on Path Control Header", Work in Progress, April 2004.
[9] Na、J.、Cho、S.、Kim、C.、Lee、S.、Kang、H。、およびC. Koo、「Path Control Headerに基づくルート最適化スキーム」、2004年4月の作業。
[10] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", Work in Progress, February 2007.
[10] Thubert、P。and M. Molteni、「IPv6リバースルーティングヘッダーとモバイルネットワークへのアプリケーション」、2007年2月、Work in Progress。
[11] Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization with Access Router Option", Work in Progress, July 2004.
[11] Ng、C。、およびT. Tanaka、「アクセスルーターオプションを使用したネストされたトンネルの最適化の保護」、2004年7月、作業中。
[12] Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo, "Secure Nested Tunnels Optimization using Nested Path Information", Work in Progress, September 2003.
[12] Na、J.、Cho、S.、Kim、C.、Lee、S.、Kang、H。、およびC. Koo、「ネストされたパス情報を使用した安全なネストされたトンネルの最適化」、2003年9月、作業進行中。
[13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
[13] Soliman、H.、Castelluccia、C.、El Malki、K。、およびL. Bellier、「階層モバイルIPv6モビリティ管理（HMIPV6）」、RFC 4140、2005年8月。
[14] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA to HA protocol", Work in Progress, September 2006.
[14] Thubert、P.、Wakikawa、R。、およびV. Devarapalli、「Global Ha to HA Protocol」、2006年9月、進行中の作業。
[15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[15] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[16] Baek, S., Yoo, J., Kwon, T., Paik, E., and M. Nam, "Routing Optimization in the same nested mobile network", Work in Progress, October 2005.
[16] Baek、S.、Yoo、J.、Kwon、T.、Paik、E。、およびM. Nam、「同じネストされたモバイルネットワークでのルーティング最適化」、2005年10月の作業。
[17] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[17] Koodli、R。、「モバイルIPv6用の高速ハンドオーバー」、RFC 4068、2005年7月。
[18] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
[18] Vogt、C。およびJ. Arkko、「モバイルIPv6ルート最適化の強化の分類と分析」、RFC 4651、2007年2月。
[19] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[19] Nikander、P.、Arkko、J.、Aura、T.、Montenegro、G。、およびE. Nordmark、「モバイルIPバージョン6ルート最適化セキュリティデザイン背景」、RFC 4225、2005年12月。
[20] Bernardos, C., Bagnulo, M., and M. Calderon, "MIRON: MIPv6 Route Optimization for NEMO", 4th Workshop on Applications and Services in Wireless Network, Online: http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf, August 2004.
[20] Bernardos、C.、Bagnulo、M。、およびM. Calderon、「Miron：Mipv6 Route Optimization for Nemo」、ワイヤレスネットワークのアプリケーションとサービスに関する第4回ワークショップ、オンライン：http：//www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf、2004年8月。
[21] Calderon, M., Bernardos, C., Bagnulo, M., Soto, I., and A. Oliva, "Design and Experimental Evaluation of a Route Optimisation Solution for NEMO", IEEE Journal on Selected Areas in Communications (J-SAC), vol 24, no 9, September 2006.
[21] Calderon、M.、Bernardos、C.、Bagnulo、M.、Soto、I。、およびA. Oliva、「Nemoのルート最適化ソリューションの設計と実験的評価」、Communicationsの選択された領域に関するIEEEジャーナル（J-Sac）、Vol 24、No 9、2006年9月。
[22] Bernardos, C., Bagnulo, M., Calderon, M., and I. Soto, "Mobile IPv6 Route Optimisation for Network Mobility (MIRON)", Work in Progress, July 2005.
[22] Bernardos、C.、Bagnulo、M.、Calderon、M。、およびI. Soto、「ネットワークモビリティのモバイルIPv6ルート最適化（Miron）」、2005年7月、作業進行中。
[23] Ylitalo, J., "Securing Route Optimization in NEMO", Workshop of 12th Network and Distributed System Security Syposuim, NDSS Workshop 2005, online: http://www.isoc.org/isoc/conferences/ ndss/05/workshop/ylitalo.pdf, February 2005.
[23] Ylitalo、J。、「NEMOのルート最適化の保護」、第12ネットワークおよび分散システムセキュリティSyposuim、NDSSワークショップ2005のワークショップ、オンライン：http：//www.isoc.org/isoc/conferences/ ndss/05/workshop/ylitaloo.pdf、2005年2月。
[24] Perera, E., Lee, K., Kim, H., and J. Park, "Extended Network Mobility Support", Work in Progress, July 2003.
[24] Perera、E.、Lee、K.、Kim、H。、およびJ. Park、「拡張ネットワークモビリティサポート」、2003年7月の作業。
[25] Lee, K., Park, J., and H. Kim, "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", 58th IEEE Vehicular Technology Conference, vol 3, pp 2035-2038, October 2003.
[25] Lee、K.、Park、J。、およびH. Kim、「プレフィックス委任に基づくモバイルネットワークのモバイルノードのルート最適化」、第58回IEEE車両技術会議、Vol 3、PP 2035-2038、2003年10月。
[26] Lee, K., Jeong, J., Park, J., and H. Kim, "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", Work in Progress, February 2004.
[26] Lee、K.、Jeong、J.、Park、J。、およびH. Kim、「プレフィックス代表団に基づくモバイルネットワークのモバイルノードのルート最適化」、2004年2月、Work in Progress。
[27] Jeong, J., Lee, K., Park, J., and H. Kim, "Route Optimization based on ND-Proxy for Mobile Nodes in IPv6 Mobile Network", 59th IEEE Vehicular Technology Conference, vol 5, pp 2461-2465, May 2004.
[27] Jeong、J.、Lee、K.、Park、J。、およびH. Kim、「IPv6モバイルネットワークのモバイルノードのND-プロキシに基づくルート最適化」、59th IEEE Vehicular Technology Conference、Vol 5、PP 2461-2465、2004年5月。
[28] Jeong, J., Lee, K., Kim, H., and J. Park, "ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network", Work in Progress, February 2004.
[28] Jeong、J.、Lee、K.、Kim、H。、およびJ. Park、「モバイルネットワークのモバイルノードのND-Proxyベースのルート最適化」、2004年2月の作業。
[29] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[29] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6の近隣発見（IPv6）」、RFC 2461、1998年12月。
[30] Kang, H., Kim, K., Han, S., Lee, K., and J. Park, "Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router", Work in Progress, June 2003.
[30] Kang、H.、Kim、K.、Han、S.、Lee、K。、およびJ. Park、「ホームエージェントとトップレベルのモバイルルーター間の双方向を使用して、モバイルネットワークのルート最適化」、進行中の作業、2003年6月。
[31] Lee, D., Lim, K., and M. Kim, "Hierarchical FRoute Optimization for Nested Mobile Network", 18th Int'l Conf on Advance Information Networking and Applications, vol 1, pp 225-229, 2004.
[31] Lee、D.、Lim、K。、およびM. Kim、「ネストされたモバイルネットワークの階層的なFroute最適化」、事前情報ネットワーキングおよびアプリケーションに関する第18回int'l conf、Vol 1、pp 225-229、2004。
[32] Takagi, Y., Ohnishi, H., Sakitani, K., Baba, K., and S. Shimojo, "Route Optimization Methods for Network Mobility with Mobile IPv6", IEICE Trans. on Comms, vol E87-B, no 3, pp 480- 489, March 2004.
[32] 高木、Y。、Ohnishi、H.、Sakitani、K.、Baba、K。、およびS. Shimojo、「モバイルIPv6を使用したネットワークモビリティのルート最適化方法」、Ieice Trans。Comms、Vol E87-B、No 3、pp 480-489、2004年3月。
[33] Ohnishi, H., Sakitani, K., and Y. Takagi, "HMIP based Route optimization method in a mobile network", Work in Progress, October 2003.
[33] Ohnishi、H.、Sakitani、K。、およびY. Takagi、「HMIPベースのモバイルネットワークでのルート最適化方法」、2003年10月の作業。
[34] Lee, C., Zheng, J., and C. HUang, "SIP-based Network Mobility (SIP-NEMO) Route Optimization (RO)", Work in Progress, October 2006.
[34] Lee、C.、Zheng、J。、およびC. Huang、「SIPベースのネットワークモビリティ（SIP-Nemo）ルート最適化（RO）」、2006年10月の作業。
[35] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[35] Conta、A。and S. Deering、「IPv6仕様における一般的なパケットトンネル」、RFC 2473、1998年12月。
[36] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[36] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-E。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Z。、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "Robust Header圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[37] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[37] Jonsson、L-E。、「堅牢なヘッダー圧縮（ROHC）：用語とチャネルマッピングの例」、RFC 3759、2004年4月。
[38] Minaburo, A., Paik, E., Toutain, L., and J. Bonnin, "ROHC (Robust Header Compression) in NEMO network", Work in Progress, July 2005.
[38] Minaburo、A.、Paik、E.、Toutain、L。、およびJ. Bonnin、「Nemo NetworkのRohc（堅牢なヘッダー圧縮）」、2005年7月、作業進行中。
[39] Ng, C. and J. Hirano, "Extending Return Routability Procedure for Network Prefix (RRNP)", Work in Progress, October 2004.
[39] Ng、C。、およびJ. Hirano、「ネットワークプレフィックス（RRNP）の返品ルー上の手順の拡張」、2004年10月、進行中の作業。
[40] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[40] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[41] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[41] オーラ、T。、「暗号化されたアドレス（CGA）」、RFC 3972、2005年3月。
[42] Zhao, F., Wu, F., and S. Jung, "Extensions to Return Routability Test in MIP6", Work in Progress, February 2005.
[42] Zhao、F.、Wu、F。、およびS. Jung、「MIP6でのルーティング可能性テストを返すための拡張」、2005年2月の作業。
[43] Bao, F., Deng, R., Qiu, Y., and J. Zhou, "Certificate-based Binding Update Protocol (CBU)", Work in Progress, March 2005.
[43] Bao、F.、Deng、R.、Qiu、Y。、およびJ. Zhou、「証明書ベースのバインディングアップデートプロトコル（CBU）」、2005年3月、進行中の作業。
[44] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", Work in Progress, April 2007.
[44] Moskowitz、R.、Nikander、P.、Jokela、P。、およびT. Henderson、「Host Identity Protocol」、2007年4月、進行中の作業。
[45] Henderson, T., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, March 2007.
[45] ヘンダーソン、T。、「ホストIDプロトコルを使用したエンドホストモビリティとマルチホミング」、2007年3月、進行中の作業。
[46] Calderon, M., Bernardos, C., Bagnulo, M., and I. Soto, "Securing Route Optimization in NEMO", Third International Symposium on Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks, WIOPT 2005, pages 248-254, April 2005.
[46] Calderon、M.、Bernardos、C.、Bagnulo、M.、およびI. Soto、「Nemoのルート最適化の保護」、モバイル、アドホック、ワイヤレスネットワークのモデリングと最適化に関する第3回国際シンポジウム、Wiopt 2005、248ページ-254、2005年4月。
Authors' Addresses
著者のアドレス
Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate, Singapore 534415 SG
Chan-wah ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave＃06-3530 Tai Seng Industrial Estate、Singapore 534415 SG
Phone: +65 65505420
EMail: chanwah.ng@sg.panasonic.com
Fan Zhao University of California Davis One Shields Avenue Davis, CA 95616 US
ファンZhao大学カリフォルニア大学デイビスワンシールドアベニューデイビス、カリフォルニア州95616米国
Phone: +1 530 752 3128
EMail: fanzhao@ucdavis.edu
Masafumi Watari KDDI R&D Laboratories Inc. 2-1-15 Ohara Fujimino, Saitama 356-8502 JAPAN
Masafumi Watari Kddi R＆D Laboratories Inc. 2-1-15 Ohara Fujimino、Saitama 356-8502 Japan
EMail: watari@kddilabs.jp
Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3, Biot - Sophia Antipolis 06410 FRANCE
Pascal Thubert Cisco Systems Village D'Entreprises Green Side 400、Avenue de Roumanille Batiment T3、Biot -Sophia Antipolis 06410 France
EMail: pthubert@cisco.com
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エディター機能の資金は現在、インターネット協会によって提供されています。