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）IETFトラスト（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ルート最適化手法のセットによって軽減することができネットワークモビリティ（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]、およびで定義されたNEMO関連用語[6]。また、以下のルート最適化特有の用語が本書で使用されています。
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)
特派エンティティ（EC）
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つのエンドノード間のデータトラフィックの待ち時間を改善するはずです。こうした減少し、ジッタやパケット損失などのサービス特性の優れた全体的な品質へのターンリードでこの5月。
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ルート最適化のための実際のソリューションに応じて、データパケットは、NEMOベーシックサポートの場合とカプセル化のように多くのレベルを必要としない2つのエンドノード間で交換しました。これは、より少ないパケットのオーバーヘッドと高いデータ効率を意味します。特に、トンネルの複数のレベルによって誘導され得る回避パケットの断片化は、バッファリングおよびトランスポートプロトコルの観点からエンドツーエンドの効率のために重要です。
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.
ネストされていないNEMOルート最適化は、コレスポンデントエンティティにバインディング情報を送信するモバイルルータを必要とします。これは、モバイルルータまたは訪問モバイルノードのネストを必要としません。特派エンティティは通信員ノードまたはコレスポンデントルータことができます。特派エンティティはコレスポンデントルータであるとき、興味深いケースがあります。コレスポンデントルータを使用すると、ルート最適化セッションが相手ノードの代わりにコレスポンデントルータで終端されます。限りコレスポンデントルータがモバイルルータのホームエージェントよりも相手ノードに「近い」位置していますように、モバイルネットワークノードとコレスポンデントノードとの間の経路が最適化されると言うことができます。この目的のために、通信先ルータは、図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:
最適化のこの形式は両方向にまたは独立して、トラフィックの両方向のトラフィックを運ぶことができます。
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）との確立されたトンネルを有し、モバイルルータが管理するモバイルネットワークプレフィックス（複数可）を認識しています。コレスポンデントルータは、このようにモバイルネットワークに向かうパケットを傍受し、確立されたトンネルを介してモバイルルータに転送することができます。
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における経路最適化への直接的なアプローチがあります。これは、モバイルルータが、コレスポンデントエンティティへの1つ以上のモバイルネットワークプレフィックスオプションを含むバインディングアップデートを送信しNEMOベーシックサポートへの論理的な拡張とみなすことができます。特派エンティティは、バインディング更新を受信し、現在のモバイルルータの気付アドレスにモバイルルータとの双方向トンネルを設定することができ、そのルーティングテーブルにルートを注入するようにアドレス宛のパケットモバイルネットワークプレフィックスは、双方向トンネルを経由してルーティングされます。
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ベーシックサポートプロトコルとして、手つかずのモバイルネットワーク・ノードを残すための要件で提起されているため、モバイルルータは、モバイルネットワークノードに代わって最適化管理を扱います。このような相互作用は、モバイル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
MNN1 Oへ/ 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対応のホストまたは1階層型移動ネットワークを作成する別の背後に取り付ける複数のモバイルルータ）を標的とします。モバイル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.
目的は、複数のモバイルノードとそのホームエージェントの間で確立された複数のトンネルに起因するパスの準最適を除去することです。そのような解決策は、元のパスからホームエージェント（S）の一部をバイパスすることによって、経路に沿ってホーム・エージェントの数を最小限にしよう。何のネスティングが形成されていないと、単一のホームエージェントがまだ有効であることができる多くのホームエージェントの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.
インフラベースの最適化は、最適化は、インフラストラクチャに完全に行われるアプローチです。それらの間のルートを最適化するためのHMIPv6 [13]で定義されるような1つの例は、モビリティアンカーポイント（地図）を利用することです。別の例は、ホームエージェントにグローバルホームエージェント（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.
一つは（セクション3.2を参照）。図3において、例えば、MNN1は、対応ノードとして扱われ、イントラNEMOの最適化、のような種類を提供するために、「ネストされたモビリティ最適化」のために適切に設計されたNEMOルート最適化を拡張することができるかもしれません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.
別の可能性は、ここで適用される「非入れ子のNEMOルート最適化」技術（3.1節を参照）です。 MNN1とMNN2との間の通信の同じ例を使用して、MR3とMR2の両方がMNN2ため特派ルータとしてMR5を扱うことができ、そしてMR5はMNN1ため特派ルータとしてMR3とMR2を扱います。このアプローチの例は、モバイルルータが同一の階層型移動ネットワーク内の他のモバイルルータへのモバイルネットワークプレフィックスを通知有する、[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の問題に特化した、MANETの新しいタイプを開発するNEMO（MANEMO）のためにMANETを有用であることが分かるかもしれません。 MANEMOは、ネストされたNEMOの形成を最適化し、インフラストラクチャへの接続を確立できるかどうか、内部接続性を維持します。
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.
ハンドオフ中に別の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の高速ハンドオーバとしてモバイルIPv6のためのソリューションの一部[17]は、ハンドオフ遅延の増大を緩和することができるかもしれません。
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ベーシックサポートの利点の一つは、モバイルネットワークノードは、モバイルネットワークの実際の位置と移動性を意識する必要がないことです。ルート最適化のためのいくつかのアプローチと、モバイルネットワークノードへのモバイルルータの結合点を明らかにする必要がある場合があります。これは、移動性、透明性とルート最適化との間のトレードオフを意味するかもしれません。
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ルート最適化の広大な解空間を分析しようとすると：
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と比較すると、ここでのスケーラビリティの問題を改善することができます。また、モバイルルータは、ルート最適化を処理し、新しい機能を実装するためのモバイルネットワークノードの必要はありません。しかし、新しい機能は、相手ノード上で必要とされる可能性があります。考察の追加点は、モバイルルータが維持するために必要とされる状態情報の量です。伝統的に、それは一般的に通信ピアの対の数に比例して増加するようにルータ状態情報を有する回避されました。
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.
コレスポンデントエンティティは、通信相手ノードが、コレスポンデントルータでない場合には、即時の質問は、その存在を検出する方法です。一つのアプローチは、すべての特派ルータのために予約周知のエニーキャストアドレスへの通信先ノードのアドレスを含むインターネット制御メッセージプロトコル（ICMP）メッセージを送信するイニシエータのためのものである[7] [8]。コレスポンデントノードに代わってルート最適化セッションを終了することのできる唯一のコレスポンデントルータが応答します。別の方法は、[9]通信先ノードに送信されるパケットにルータ警告オプション（RAO）を挿入することです。途中の任意のコレスポンデントルータは、ルータアラートオプションを処理し、モバイルルータへの応答を送信します。
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.
これは、モバイルルータが、コレスポンデントエンティティへの1つ以上のモバイルネットワークプレフィックスオプションを含むバインディングアップデートを送信しますNEMOベーシックサポートへの論理的な拡張とみなすことができます。特派エンティティは、バインディング更新を受信し、次にモバイルルータの現在の気付アドレスにモバイルルータとの双方向トンネルを設定することができ、そのルーティングテーブルにルートを注入するようにアドレス宛のパケットモバイルネットワークプレフィックスは、双方向トンネルを経由してルーティングされるだろう。
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]参照）。この代表団では、客員モバイルネットワークノードやモバイルルータのどちらかが相手ノードとリターンルータビリティ手順を開始することができます。リターンルータビリティ手順を訪問モバイルノードによって開始された場合には、モバイルルータが訪問ノードに通信相手ノードから送信されたパケットは、ケアにルーティングされるように透過的に往復経路シグナリングメッセージの内容を変更する必要がありますモバイルルータの-ofアドレスは一度ルート最適化が確立されています。リターンルータビリティ手順は、モバイルルータによって開始された場合は、モバイルネットワークノードがローカル固定ノードである場合と同様です。
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特派同じ特派エンティティの機能を維持し、一方、新機能は、コレスポンデントエンティティで必要とされ、「モバイルネットワークプレフィックスとのバインディング更新」と「親モバイルルータの情報を送信する」ためのノード。しかし、これは「プロキシとしてモバイルルータ」であるため、モバイルルータを犠牲にして行われ、モバイルルータは、そのモバイルネットワークノードが持っているすべてのルート最適化セッションの状態情報を維持する必要があります。さらに、いくつかのケースでは、モバイルルータ（これはエンドツーエンドの完全性に影響を与える可能性があり、5.8.2参照）入力および出力パケットのための標準のIPv6ヘッダを越えて見て、適宜パケットの内容を変更する必要があります。
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).
ここに記載されているすべてのアプローチで共有する一つの利点は、唯一のモビリティプロトコルが影響を受けているということです。言い換えれば、修飾は、（近隣探索のような）他の既存のプロトコルに必要とされません。 （アクセス・ネットワークなど）既存のインフラストラクチャに追加の要件もありません。
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).
すぐに思い浮かぶ一つの疑問は、モバイルネットワークノードは、その上流モバイルルータの場所の一連のホールドを取得する方法です。これは、通常、上流モバイルルータによって広告Router Advertisementメッセージに特別なオプションとして挿入されたそのような情報を有することによって達成されます。モバイルルータは、そのモバイル・ネットワーク・ノードに現在の場所を公示しなければならないだけでなく、そうするために、それはまた、その上流のモバイルルータから受信したルータ通知メッセージに埋め込まれた情報を中継しなければなりません。これは、モバイルネットワークの移動性、透明性の妥協を意味するものではありかもしれません（セクション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.
第三のアプローチに関係なく、モバイルネットワークノードは、階層型移動ネットワーク内でどのように深くネストの、ルート移動ルータの位置に移動ネットワークノードのアドレスをバインドすることです。特派エンティティは、モバイルネットワークノードにパケットを転送する必要があるときはいつでも、それだけで添付ファイルのこのポイントにパケットを転送する必要があります。モバイルネットワークは、それ自体で、モバイルネットワークノードにパケットを転送する方法を見つけ出すだろう。この種のアプローチは、モバイルネットワーク内のすべてのノードが同じネットワークセグメントにインターネットに接続されている特派エンティティに思われるように、入れ子になったモバイルネットワークの構造を平坦化とみなすことができます。
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近隣探索プロキシ
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.
このようなアプローチの一つの形態は、ルート移動ルータはモビリティアンカーポイントとして機能階層モバイル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.
上記のすべてのアプローチに共通する一つの利点は、ネストされたモバイルネットワーク内のモバイルネットワークノードのローカルモビリティが特派エンティティから隠されているということです。
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層に渡されることができます。このような機構の一例は、バインディング情報を中継するセッション開始プロトコル（SIP）を使用する、[34]です。
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.
最適化されたパスを介してパケットをルーティングするための一つの方法は、IPイン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
最適化されたパスを介してパケットをルーティングする2番目の方法は、ルーティングヘッダを使用することです。ルーティングヘッダができるので、これは、（セクション5.5.2を参照）、特にコレスエンティティが上流モバイルルータの位置の配列を知っている場合に有用です
contain multiple intermediate destinations. Each intermediate destination corresponds to a point of attachment bound to the address of the Mobile Network Node.
複数の中間の宛先が含まれています。各中間宛先は、モバイルネットワークノードのアドレスにバインドされた結合点に相当します。
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.
さらにもう1つの方法は、ルートのルートが最も可能性の高いソースアドレスルーティングに基づいて、異なったパケットを最適化します自分のルーティングテーブルのエントリをルーティングインストールするには、親のためのモバイルルータです。これは通常、セクション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-サービス拒否（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
例えば、モバイルルータは、コレスポンデントエンティティへのモバイルネットワークプレフィックス情報を含むバインディングアップデートを送信する場合を考える（5.5.1項を参照してください）。リターンが、
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.
ルータビリティ手順は、コレスポンデントエンティティは、モバイルネットワークプレフィックスの有効性を検証することはできませんが、コレスポンデントエンティティは、モバイルルータのケアのホームアドレスが実際に一緒に配置されていることを確認することができます。特派エンティティは、検証せずに結合を受け入れる場合、それはモバイル攻撃（スヌーピング）へのネットワークや被害者（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項では、登録シグナリングは、一つ以上の上流のモバイルルータに関する情報を送信することを含みます。特派エンティティ（またはホームエージェント）も、そのような情報を確認する手段を持っている必要があります。上流のルータのシリーズにわたってアドレスの到達可能性を検証するために設計されていないとして、再び、[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
アドレスの信頼の上にすべてのこれらの懸念は、おそらくより過激かつ堅牢なアプローチが必要であることを示唆しているかもしれません。これは、IETFのさまざまなワーキンググループに鋭意検討中である、と多くの関連文書はここに興味があるかもしれません。例えば、セキュア近隣にディスカバリー（SEND）[40]、暗号化生成アドレス（CGAs）[41]を確立するために使用することができます
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.
気付アドレスの所有権。 [42]特派エンティティは、指定されたモバイルネットワークプレフィックスの正当性を確認するための方法を提供するために、モバイルルータによって送信されたシグナリングメッセージをチェックするホームエージェントを採用しています。 [18]そのようなドキュメント特派エンティティが関連付けられた証明書を検証することによって、特定のオペレータのホームエージェントを認証することを可能にする[43]、ならびにNEMOルート最適化に適用されるかもしれないモバイルIPv6ルート最適化メカニズムに様々な提案の拡張、。エンドホストモビリティ考慮[45]とホストアイデンティティプロトコル（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.
また、興味のある読者は、安全なNEMOにルート最適化を行うことの一般的な問題を議論し、いくつかの可能な解決策のスキームを模索[46]を参照したい場合があります。モバイルネットワークに代わってルート最適化セッションを確立するときに、モバイルルータは、コレスポンデントエンティティへのauthenticitiesを証明できるようにするために使用することができる彼らのモバイルルータへのいくつかの権利を委任するために、モバイルネットワークノードのための[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]を参照してください。代わりに、我々は、位置プライバシーに次の三つの側面を考慮してください。
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.
ネットワークモビリティと、位置暴露の程度は、1つの階層型移動ネットワークを考慮する場合は特に、変化します。例えば、ルート移動ルータの位置に移動ネットワークノードのアドレスをバインドするためのアプローチ、モバイルネットワークの取り付けのみ最上点は、コレスポンデントエンティティに明らかにされる（セクション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ルート最適化の解空間を解析し、情報提供文書です。異なるアプローチのセキュリティの考慮事項は、この文書全体で関連セクションで説明されています。特に、一般的には経路最適化に関して、様々なルート最適化手法のより詳細な分析については、セクション5.8でセキュリティ上の懸念の簡単な説明については、セクション4.9を参照してください。
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.
マルコMolteni、パイクウン・ヘギョン、博之大西、フェリックス・ウー、およびSouhwanユング：著者は、この文書が由来する以前のバージョンの共著者に感謝したいです。また、心からの感謝もヤリArkko、カルロス・イエスBernardos、グレッグ・デイリー、ティエリーエルンスト、T.J.に拡張され彼らの様々な貢献のためKniveton、エリックNordmarkと、アレクサンドル・ペトレスク、Heshamソリマン、竜二Wakikawa、そしてパトリックWetterwald。
[1] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007.
[1]呉、C.、Thubert、P.、亘理、M.、およびF.趙、 "ネットワークモビリティ経路最適化問題に関する声明"、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.、ペトレスク、A.、およびP. Thubert、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、2005年1月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[3]ジョンソン、D.、パーキンス、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]マナー、J.とM.古城、 "モビリティ関連用語"、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.、小柴、S.、上原、K.、およびJ.村井、 "ORC：ネットワークモビリティのために最適化された経路キャッシュ管理プロトコル"、通信に関する第10回国際会議、第2巻、頁1194年から1200年、 2003年2月。
[8] Wakikawa, R. and M. Watari, "Optimized Route Cache Protocol (ORC)", Work in Progress, November 2004.
[8] Wakikawa、R.とM.亘理、 "最適なルートキャッシュプロトコル（ORC）"、進歩、2004年11月に作業。
[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.
、進捗状況、2004年4月の作業 "パス制御ヘッダに基づいて、ルート最適化スキーム" [9]のNa、J.、チョー、S.、キム、C.、リー、S.、カン、H.、およびC.クー、 。
[10] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", Work in Progress, February 2007.
[10] Thubert、P.とM. Molteni、「IPv6のリバースルーティングヘッダおよびモバイルネットワークへの応用」、進歩、2007年2月での作業。
[11] Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization with Access Router Option", Work in Progress, July 2004.
[11]ン、C.およびT.田中、進歩、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.、チョー、S.、キム、C.、リー、S.、カン、H.、およびC.クー、 "ネストされたパス情報を使用して、ネストされたトンネルの最適化を固定"、進歩、2003年9月の作業。
[13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
[13]ソリマン、H.、カステルッシア、C.、エルMalki、K.、およびL. Bellier、 "階層型Mobile 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、 "グローバルHA HAのプロトコル" が進歩、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、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[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]ペク、S.、ユ、J.、クォン、T.、パイク、E.、およびM.ナム、 "同じ階層型移動ネットワークにおけるルーティングの最適化"、進歩、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]フォークト、C.およびJ. Arkko、RFC 4651 "モバイルIPv6ルート最適化の拡張の分類と分析" 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.、オーラ、T.、モンテネグロ、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.カルデロン、 "Miron氏：NEMOのためのMIPv6ルート最適化"、ワイヤレスネットワーク、オンラインでのアプリケーションとサービスの第4回ワークショップ：のhttp：//www.it.uc3m。 ES / cjbc /論文/ 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]カルデロン、M.、Bernardos、C.、Bagnulo、M.、ソト、I.、およびA.オリバ、コミュニケーションにおける選択された領域の "NEMOのためのルート最適化ソリューションの設計と実験的評価"、IEEEジャーナル（ J-SAC）、第24巻、無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.、カルデロン、M.、およびI.ソト、 "ネットワークモビリティのモバイル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 /ワークショップ/ ylitalo.pdf、2005年2月。
[24] Perera, E., Lee, K., Kim, H., and J. Park, "Extended Network Mobility Support", Work in Progress, July 2003.
[24]ペレラ、E.、リー、K.、キム、H.、およびJ.パーク、進歩、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]リー、K.、公園、J.、およびH.キム、「プレフィックス委任に基づいてモバイルネットワーク内の移動ノードの経路最適化」、第58回IEEE乗物技術会議、第3巻、頁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]リー、K.、チョン、J.、公園、J.、およびH.キム、「プレフィックス委任に基づいてモバイルネットワーク内の移動ノードの経路最適化」、進歩、2004年2月に作業。
[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]チョン、J.、リー、K.、公園、J.、およびH.キム、「IPv6のモバイルネットワークにおけるモバイルノードのND-プロキシに基づくルート最適化」、第59回IEEE乗物技術会議、第5巻、頁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]チョン、J.、リー、K.、キム、H.、およびJ.パーク、「モバイルネットワーク内の移動ノードのNDプロキシベースのルート最適化」、進歩、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.シンプソン、 "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]カン、H.、キム、K.、漢、S.、リー、K.、およびJ.パーク、「ホームエージェントとトップレベルモバイルルータとの間の双方向を利用したモバイルネットワークの経路最適化」、仕事進捗状況6月2003インチ
[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]リー、D.、リム、K.、およびアドバンス情報ネットワークとアプリケーション、第1巻、頁225-229、2004年第18回国際コンファレンスM.キム、「ネストされたモバイルネットワークのための階層的FRouteの最適化」、。
[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.、大西、H.、Sakitani、K.、馬場、K.、およびS.下條、 "モバイルIPv6によるネットワークモビリティのための経路最適化方法"、電子情報通信学会トランス。途切れに、巻E87-B、ノー3頁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]大西、H.、Sakitani、K.、およびY.高木、 "モバイルネットワークにおける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]リー、C.、鄭、J.、およびC.黄、 "SIPベースのネットワークモビリティ（SIP-NEMO）ルート最適化（RO）"、進歩、2006年10月に作業。
[35] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[35]コンタ、A.、およびS.デアリング、 "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]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（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]ヨンソン、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.、パイク、E.、Toutain、L.、及びJ. Bonnin、 "NEMOネットワーク内のROHC（ロバストヘッダ圧縮）"、進歩、2005年7月ワーク。
[39] Ng, C. and J. Hirano, "Extending Return Routability Procedure for Network Prefix (RRNP)", Work in Progress, October 2004.
[39]ン、C.および「ネットワークプレフィックス（RRNP）のリターンルータビリティ手順を拡張する」J.平野、進捗状況、2004年10月に作業。
[40] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[40] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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]趙、F.、呉、F.、およびS.ユング、 "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]バオ、F.、トウ、R.、秋、Y.、およびJ.周、 "証明書ベースのバインディング更新プロトコル（CBU）"、進歩、2005年3月に働いています。
[44] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", Work in Progress, April 2007.
[44]モスコウィッツ、R.、Nikander、P.、Jokela、P.、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、進歩、2007年4月に作業。
[45] Henderson, T., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, March 2007.
[45]ヘンダーソン、T.、進歩、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.
モバイル、アドホック、およびワイヤレスネットワーク、WIOPT 2005年の[46]カルデロン、M.、Bernardos、C.、Bagnulo、M.、およびI.ソト、 "NEMOでルート最適化の確保"、第3回国際シンポジウムモデリングのと最適化、頁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
チャン・ワウ呉パナソニックシンガポール研究所Pte株式会社BLK 1022タイセンアベニュー＃06から3530タイセン工業団地、シンガポール534415 SG
Phone: +65 65505420 EMail: chanwah.ng@sg.panasonic.com
電話：+65 65505420 Eメール：chanwah.ng@sg.panasonic.com
Fan Zhao University of California Davis One Shields Avenue Davis, CA 95616 US
カリフォルニア州デービスのファン趙大学の一つシールズアベニューデイビス、CA 95616米国
Phone: +1 530 752 3128 EMail: fanzhao@ucdavis.edu
電話：+1 530 752 3128 Eメール：fanzhao@ucdavis.edu
Masafumi Watari KDDI R&D Laboratories Inc. 2-1-15 Ohara Fujimino, Saitama 356-8502 JAPAN
まさふみ わたり Ｋっぢ Ｒ＆Ｄ ぁぼらとりえｓ いんｃ。 ２ー１ー１５ おはら ふじみの、 さいたま ３５６ー８５０２ じゃぱん
EMail: watari@kddilabs.jp
メールアドレス：watari@kddilabs.jp
Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3, Biot - Sophia Antipolis 06410 FRANCE
パスカルThubertシスコシステムズエンタープライズヴィレッジグリーンサイド400アベニューRoumanilleビルT3、ビオ - ソフィアアンティポリス06410 FRANCE
EMail: pthubert@cisco.com
メールアドレス：pthubert@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。