[要約] RFC 4888は、ネットワークモビリティのルート最適化の問題を説明しています。このRFCの目的は、ネットワークモビリティのパフォーマンスを向上させるための問題の特定と解決策の提案です。
Network Working Group C. Ng
Request for Comments: 4888 Panasonic Singapore Labs
Category: Informational P. Thubert
Cisco Systems
M. Watari
KDDI R&D Labs
F. Zhao
UC Davis
July 2007
Network Mobility Route Optimization Problem Statement
ネットワークモビリティルート最適化問題ステートメント
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems and provides the motivation behind Route Optimization (RO) for NEMO.
現在のネットワークモビリティ（NEMO）の基本的なサポートにより、モバイルネットワークノードとの間のすべての通信は、モバイルネットワークが離れているときにモバイルルーターとホームエージェントの間に確立された双方向トンネルを通過する必要があります。この最適なルーティングは、パケット配信に関連するさまざまな非効率性をもたらします。たとえば、遅延の増加やボトルネックリンクの増加など、トラフィックの渋滞につながり、最終的にモバイルネットワークノードとの間のすべての通信を混乱させる可能性があります。さらに、モバイルネットワークのネスティングにより、これらの非効率性が悪化し、特定の処分で膠着状態の状態が発生する可能性があります。このドキュメントは、そのような問題を調査し、Nemoのルート最適化（RO）の背後にある動機を提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. NEMO Route Optimization Problem Statement . . . . . . . . . . 3
2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4
2.2. Bottleneck in the Home Network . . . . . . . . . . . . . . 6
2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 6
2.4. Sub-Optimality with Combined Mobile IPv6 Route
Optimization . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Security Policy Prohibiting Traffic from Visiting Nodes . 9
2.6. Instability of Communications within a Nested Mobile
Network . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 10
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 12
6.2. Informative Reference . . . . . . . . . . . . . . . . . . 12
Appendix A. Various Configurations Involving Nested Mobile
Networks . . . . . . . . . . . . . . . . . . . . . . 13
A.1. CN Located in the Fixed Infrastructure . . . . . . . . . . 13
A.1.1. Case A: LFN and Standard IPv6 CN . . . . . . . . . . . 14
A.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 14
A.1.3. Case C: VMN and Standard IPv6 CN . . . . . . . . . . . 14
A.2. CN Located in Distinct Nested NEMOs . . . . . . . . . . . 15
A.2.1. Case D: LFN and Standard IPv6 CN . . . . . . . . . . . 16
A.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16
A.2.3. Case F: VMN and Standard IPv6 CN . . . . . . . . . . . 16
A.3. MNN and CN Located in the Same Nested NEMO . . . . . . . . 17
A.3.1. Case G: LFN and Standard IPv6 CN . . . . . . . . . . . 18
A.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18
A.3.3. Case I: VMN and Standard IPv6 CN . . . . . . . . . . . 19
A.4. CN Located Behind the Same Nested MR . . . . . . . . . . . 19
A.4.1. Case J: LFN and Standard IPv6 CN . . . . . . . . . . . 20
A.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20
A.4.3. Case L: VMN and Standard IPv6 CN . . . . . . . . . . . 21
Appendix B. Example of How a Stalemate Situation Can Occur . . . 22
With current Network Mobility (NEMO) Basic Support [1], all communications to and from nodes in a mobile network must go through the bi-directional tunnel established between the Mobile Router and its Home Agent (also known as the MRHA tunnel) when the mobile network is away. Although such an arrangement allows Mobile Network Nodes to reach and be reached by any node on the Internet, limitations associated to the base protocol degrade overall performance of the network and, ultimately, can prevent all communications to and from the Mobile Network Nodes.
現在のネットワークモビリティ（NEMO）の基本的なサポート[1]により、モバイルネットワーク内のノードとの間のすべての通信は、モバイルルーターとそのホームエージェント（MRHAトンネルとも呼ばれる）の間に確立された双方向トンネルを通過する必要があります。モバイルネットワークは離れています。このような配置により、モバイルネットワークノードはインターネット上の任意のノードに到達して到達することができますが、ベースプロトコルに関連する制限はネットワークの全体的なパフォーマンスを低下させ、最終的にはモバイルネットワークノードとのすべての通信を防ぐことができます。
Some of these concerns already exist with Mobile IPv6 [4] and were addressed by the mechanism known as Route Optimization, which is part of the base protocol. With Mobile IPv6, Route Optimization mostly improves the end-to-end path between the Mobile Node and Correspondent Node, with an additional benefit of reducing the load of the Home Network, thus its name.
これらの懸念のいくつかはすでにモバイルIPv6 [4]に存在し、ベースプロトコルの一部であるルート最適化として知られるメカニズムによって対処されました。モバイルIPv6を使用すると、ルートの最適化により、モバイルノードと特派員ノードの間のエンドツーエンドパスが主に改善され、ホームネットワークの負荷を減らすという追加の利点、したがってその名前が改善されます。
NEMO Basic Support presents a number of additional issues, making the problem more complex, so it was decided to address Route Optimization separately. In that case, the expected benefits are more dramatic, and a Route Optimization mechanism could enable connectivity that would be broken otherwise. In that sense, Route Optimization is even more important to NEMO Basic Support than it is to Mobile IPv6.
Nemo Basic Supportは、多くの追加の問題を提示し、問題をより複雑にするため、ルートの最適化に個別に対処することが決定されました。その場合、予想される利点はより劇的であり、ルートの最適化メカニズムにより、それ以外の場合は破壊される接続性が可能になります。その意味で、ルートの最適化は、モバイルIPv6よりもNEMOの基本的なサポートにとってさらに重要です。
This document explores limitations inherent in NEMO Basic Support, and their effects on communications between a Mobile Network Node and its corresponding peer. This is detailed in Section 2. It is expected that readers are familiar with general terminologies related to mobility in [4][2], NEMO-related terms defined in [3], and NEMO goals and requirements [5].
このドキュメントでは、NEMOの基本的なサポートに固有の制限と、モバイルネットワークノードと対応するピアとの間の通信への影響を調査します。これはセクション2で詳しく説明されています。読者は、[4] [2]のモビリティ、[3]で定義されているNEMO関連用語、およびNEMOの目標と要件[5]のモビリティに関連する一般的な用語に精通していることが期待されています。
Given the NEMO Basic Support protocol, all data packets to and from Mobile Network Nodes must go through the Home Agent, even though a shorter path may exist between the Mobile Network Node and its Correspondent Node. In addition, with the nesting of Mobile Routers, these data packets must go through multiple Home Agents and several levels of encapsulation, which may be avoided. This results in various inefficiencies and problems with packet delivery, which can ultimately disrupt all communications to and from the Mobile Network Nodes.
NEMOの基本的なサポートプロトコルを考えると、モバイルネットワークノードとその特派員ノードの間に短いパスが存在する場合でも、モバイルネットワークノードとのすべてのデータパケットはホームエージェントを通過する必要があります。さらに、モバイルルーターのネストにより、これらのデータパケットは複数のホームエージェントといくつかのレベルのカプセル化を通過する必要があります。これにより、さまざまな非効率性とパケット配信の問題が発生し、最終的にモバイルネットワークノードとの間のすべての通信を混乱させる可能性があります。
In the following sub-sections, we will describe the effects of a pinball route with NEMO Basic Support, how it may cause a bottleneck to be formed in the Home Network, and how these get amplified with nesting of mobile networks. Closely related to nesting, we will also look into the sub-optimality even when Mobile IPv6 Route Optimization is used over NEMO Basic Support. This is followed by a description of security policy in the Home Network that may forbid transit traffic from Visiting Mobile Nodes in mobile networks. In addition, we will explore the impact of the MRHA tunnel on communications between two Mobile Network Nodes on different links of the same mobile network. We will also provide additional motivations for Route Optimization by considering the potential stalemate situation when a Home Agent is part of a mobile network.
次のサブセクションでは、NEMOの基本的なサポートを備えたピンボールルートの効果、ホームネットワークでボトルネットを形成する方法、およびこれらがモバイルネットワークのネストでどのように増幅するかについて説明します。ネスティングに密接に関連しているため、モバイルIPv6ルートの最適化がNEMOの基本サポートよりも使用されている場合でも、サブ最適性についても検討します。これに続いて、モバイルネットワークのモバイルノードへの訪問からの輸送トラフィックを禁止する可能性のあるホームネットワークのセキュリティポリシーの説明が続きます。さらに、同じモバイルネットワークの異なるリンク上の2つのモバイルネットワークノード間の通信に対するMRHAトンネルの影響を調査します。また、ホームエージェントがモバイルネットワークの一部である場合の潜在的な膠着状態の状況を考慮することにより、ルートの最適化のための追加の動機を提供します。
With NEMO Basic Support, all packets sent between a Mobile Network Node and its Correspondent Node are forwarded through the MRHA tunnel, resulting in a pinball route between the two nodes. This has the following sub-optimal effects:
NEMOの基本的なサポートにより、モバイルネットワークノードとその特派員ノードの間に送信されるすべてのパケットは、MRHAトンネルを介して転送され、2つのノード間のピンボールルートが行われます。これには、次の最適な効果があります。
o Longer Route Leading to Increased Delay and Additional Infrastructure Load
o 遅延の増加と追加のインフラストラクチャ負荷につながる長いルート
Because a packet must transit from a mobile network to the Home Agent then to the Correspondent Node, the transit time of the packet is usually longer than if the packet were to go straight from the mobile network to the Correspondent Node. When the Correspondent Node (or the mobile network) resides near the Home Agent, the increase in packet delay can be very small. However, when the mobile network and the Correspondent Node are relatively near to one another but far away from the Home Agent on the Internet, the increase in delay is very large. Applications such as real-time multimedia streaming may not be able to tolerate such increase in packet delay. In general, the increase in delay may also impact the performance of transport protocols such as TCP, since the sending rate of TCP is partly determined by the round-trip time (RTT) perceived by the communication peers.
パケットはモバイルネットワークからホームエージェントに移動する必要があるため、ポケットの通過時間は通常、パケットがモバイルネットワークから特派員ノードに直接移動する場合よりも長くなります。特派員ノード（またはモバイルネットワーク）がホームエージェントの近くに存在する場合、パケット遅延の増加は非常に少ない場合があります。ただし、モバイルネットワークと特派員ノードが互いに比較的近くにいるが、インターネット上のホームエージェントから遠く離れている場合、遅延の増加は非常に大きくなります。リアルタイムのマルチメディアストリーミングなどのアプリケーションは、パケット遅延のこのような増加を許容できない場合があります。一般に、TCPの送信率は通信ピアによって知覚される往復時間（RTT）によって部分的に決定されるため、遅延の増加はTCPなどの輸送プロトコルのパフォーマンスにも影響を与える可能性があります。
Moreover, by using a longer route, the total resource utilization for the traffic would be much higher than if the packets were to follow a direct path between the Mobile Network Node and Correspondent Node. This would result in additional load in the infrastructure.
さらに、より長いルートを使用することにより、パケットがモバイルネットワークノードと特派員ノードの間の直接的なパスをたどる場合よりも、トラフィックの合計リソース使用率がはるかに高くなります。これにより、インフラストラクチャに追加の負荷が発生します。
o Increased Packet Overhead
o パケットオーバーヘッドの増加
The encapsulation of packets in the MRHA tunnel results in increased packet size due to the addition of an outer header. This reduces the bandwidth efficiency, as an IPv6 header can be quite substantial relative to the payload for applications such as voice samples. For instance, given a voice application using an 8 kbps algorithm (e.g., G.729) and taking a voice sample every 20 ms (as in RFC 1889 [6]), the packet transmission rate will be 50 packets per second. Each additional IPv6 header is an extra 320 bits per packet (i.e., 16 kbps), which is twice the actual payload!
MRHAトンネルのパケットのカプセル化により、外側のヘッダーが追加されたため、パケットサイズが増加します。これにより、IPv6ヘッダーは音声サンプルなどのアプリケーションのペイロードに比べて非常に重要であるため、帯域幅の効率が低下します。たとえば、8 kbpsアルゴリズム（G.729など）を使用した音声アプリケーションを与えられ、20ミリ秒ごと（RFC 1889 [6]など）ごとに音声サンプルを使用すると、パケット伝送速度は毎秒50パケットになります。追加のIPv6ヘッダーは、パケットあたり320ビット（つまり、16 kbps）で、実際のペイロードの2倍です。
o Increased Processing Delay
o 処理遅延の増加
The encapsulation of packets in the MRHA tunnel also results in increased processing delay at the points of encapsulation and decapsulation. Such increased processing may include encryption/ decryption, topological correctness verifications, MTU computation, fragmentation, and reassembly.
MRHAトンネルのパケットのカプセル化は、カプセル化と脱カプセル化のポイントでの処理遅延の増加ももたらします。このような増加する処理には、暗号化/復号化、トポロジーの正確性の検証、MTU計算、断片化、および再組み立てが含まれる場合があります。
o Increased Chances of Packet Fragmentation
o パケットの断片化の可能性の増加
The augmentation in packet size due to packet encapsulation may increase the chances of the packet being fragmented along the MRHA tunnel. This can occur if there is no prior path MTU discovery conducted, or if the MTU discovery mechanism did not take into account the encapsulation of packets. Packet fragmentation will result in a further increase in packet delays and further reduction of bandwidth efficiency.
パケットのカプセル化によるパケットサイズの増強により、PacketがMRHAトンネルに沿って断片化される可能性が高まる可能性があります。これは、事前のパスMTU発見が行われていない場合、またはMTU発見メカニズムがパケットのカプセル化を考慮していない場合に発生する可能性があります。パケットの断片化により、パケットの遅延がさらに増加し、帯域幅の効率がさらに低下します。
o Increased Susceptibility to Link Failure
o 故障をリンクするための感受性の増加
Under the assumption that each link has the same probability of link failure, a longer routing path would be more susceptible to link failure. Thus, packets routed through the MRHA tunnel may be subjected to a higher probability of being lost or delayed due to link failure, compared to packets that traverse directly between the Mobile Network Node and its Correspondent Node.
各リンクにリンク障害の可能性が同じであるという仮定の下では、より長いルーティングパスはリンク障害をより影響を受けやすくなります。したがって、MRHAトンネルを介してルーティングされたパケットは、モバイルネットワークノードとその特派員ノードの間を直接通過するパケットと比較して、リンク障害により失われたり遅延したりする可能性が高い場合があります。
Apart from the increase in packet delay and infrastructure load, forwarding packets through the Home Agent may also lead to either the Home Agent or the Home Link becoming a bottleneck for the aggregated traffic from/to all the Mobile Network Nodes. A congestion at home would lead to additional packet delay, or even packet loss. In addition, Home Agent operations such as security check, packet interception, and tunneling might not be as optimized in the Home Agent software as plain packet forwarding. This could further limit the Home Agent capacity for data traffic. Furthermore, with all traffic having to pass through the Home Link, the Home Link becomes a single point of failure for the mobile network.
パケットの遅延とインフラストラクチャの負荷の増加とは別に、ホームエージェントを介したパケットを転送すると、ホームエージェントまたはホームリンクがすべてのモバイルネットワークノードからの集約されたトラフィックのボトルネックになる可能性があります。自宅での混雑は、追加のパケット遅延、またはパケット損失にさえつながります。さらに、セキュリティチェック、パケットインターセプト、トンネルなどのホームエージェントの操作は、ホームエージェントソフトウェアではプレーンパケット転送ほど最適化されていない場合があります。これにより、データトラフィックのホームエージェント容量をさらに制限する可能性があります。さらに、すべてのトラフィックがホームリンクを通過する必要があるため、ホームリンクはモバイルネットワークの単一の障害ポイントになります。
Data packets that are delayed or discarded due to congestion at the Home Network would cause additional performance degradation to applications. Signaling packets, such as Binding Update messages, that are delayed or discarded due to congestion at the Home Network may affect the establishment or update of bi-directional tunnels, causing disruption of all traffic flow through these tunnels.
ホームネットワークでの混雑により遅延または破棄されたデータパケットは、アプリケーションに追加のパフォーマンス劣化を引き起こします。バインディングアップデートメッセージなどのシグナルパケットは、ホームネットワークでの輻輳のために遅延または破棄される可能性があり、双方向トンネルの確立または更新に影響を与え、これらのトンネルを通るすべてのトラフィックフローの破壊を引き起こす可能性があります。
A NEMO Route Optimization mechanism that allows the Mobile Network Nodes to communicate with their Correspondent Nodes via a path that is different from the MRHA tunneling and thereby avoiding the Home Agent may alleviate or even prevent the congestion at the Home Agent or Home Link.
モバイルネットワークノードがMRHAトンネリングとは異なるパスを介して通信型ノードと通信できるようにするNEMOルート最適化メカニズムにより、ホームエージェントがホームエージェントまたはホームリンクの輻輳を軽減または防止することさえあります。
By allowing other mobile nodes to join a mobile network, and in particular mobile routers, it is possible to form arbitrary levels of nesting of mobile networks. With such nesting, the use of NEMO Basic Support further amplifies the sub-optimality of routing. We call this the amplification effect of nesting, where the undesirable effects of a pinball route with NEMO Basic Support are amplified with each level of nesting of mobile networks. This is best illustrated by an example shown in Figure 1.
他のモバイルノードがモバイルネットワーク、特にモバイルルーターに参加できるようにすることにより、モバイルネットワークの任意のレベルのネストを形成することができます。このようなネストにより、NEMOの基本的なサポートの使用は、ルーティングのサブ最適性をさらに増幅します。これをネストの増幅効果と呼びます。ここでは、NEMOの基本的なサポートを使用したピンボールルートの望ましくない効果が、モバイルネットワークのネストの各レベルで増幅されます。これは、図1に示す例で最もよく示されています。
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +------------------------------+
| MR1_HA |----| Internet |-----CN1
+--------+ +------------------------------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN2
Figure 1: An Example of a Nested Mobile Network
図1：ネストされたモバイルネットワークの例
Using NEMO Basic Support, the flow of packets between a Mobile Network Node, MNN, and a Correspondent Node, CN1, would need to go through three separate tunnels, illustrated in Figure 2 below.
NEMOの基本サポートを使用して、モバイルネットワークノード、MNN、および特派員ノードCN1の間のパケットのフローは、以下の図2に示す3つの別々のトンネルを通過する必要があります。
----------.
---------/ /----------.
-------/ | | /-------
MNN -----( - - | - - - | - - - | - - - | - - (------ CN1
MR3-------\ | | \-------MR3_HA
MR2--------\ \----------MR2_HA
MR1---------MR1_HA
Figure 2: Nesting of Bi-Directional Tunnels
図2：双方向トンネルの営巣
This leads to the following problems:
これは、次の問題につながります。
o Pinball Route
o ピンボールルート
Both inbound and outbound packets will flow via the Home Agents of all the Mobile Routers on their paths within the mobile network, with increased latency, less resilience, and more bandwidth usage. Appendix A illustrates in detail the packets' routes under different nesting configurations of the Mobile Network Nodes.
インバウンドパケットとアウトバウンドパケットの両方が、モバイルネットワーク内のパス上のすべてのモバイルルーターのホームエージェントを介して流れ、レイテンシの増加、回復力の低下、および帯域幅の使用量が増えます。付録Aは、モバイルネットワークノードのさまざまなネスト構成の下でのパケットのルートを詳細に示しています。
o Increased Packet Size
o パケットサイズの増加
An extra IPv6 header is added per level of nesting to all the packets. The header compression suggested in [7] cannot be applied because both the source and destination (the intermediate Mobile Router and its Home Agent) are different hop to hop.
すべてのパケットにネストのレベルごとに追加のIPv6ヘッダーが追加されます。[7]で提案されているヘッダー圧縮は、ソースと目的地（中間モバイルルーターとそのホームエージェント）の両方が異なるホップに異なるホップであるため、適用できません。
Nesting also amplifies the probability of congestion at the Home Networks of the upstream Mobile Routers. In addition, the Home Link of each upstream Mobile Router will also be a single point of failure for the nested Mobile Router.
ネストはまた、上流のモバイルルーターのホームネットワークでの混雑の可能性を増幅します。さらに、各アップストリームモバイルルーターのホームリンクは、ネストされたモバイルルーターの単一の障害のポイントにもなります。
When a Mobile IPv6 host joins a mobile network, it becomes a Visiting Mobile Node of the mobile network. Packets sent to and from the Visiting Mobile Node will have to be routed not only via the Home Agent of the Visiting Mobile Node, but also via the Home Agent of the Mobile Router in the mobile network. This suffers the same amplification effect of nested mobile network mentioned in Section 2.3.
モバイルIPv6ホストがモバイルネットワークに参加すると、モバイルネットワークの訪問モバイルノードになります。訪問するモバイルノードとの間で送信されるパケットは、訪問するモバイルノードのホームエージェントだけでなく、モバイルネットワークのモバイルルーターのホームエージェントを介してルーティングする必要があります。これは、セクション2.3に記載されているネストされたモバイルネットワークと同じ増幅効果に苦しんでいます。
In addition, although Mobile IPv6 [4] allows a mobile host to perform Route Optimization with its Correspondent Node in order to avoid tunneling with its Home Agent, the "optimized" route is no longer optimized when the mobile host is attached to a mobile network. This is because the route between the mobile host and its Correspondent Node is subjected to the sub-optimality introduced by the MRHA tunnel. Interested readers may refer to Appendix A for examples of how the routes will appear with nesting of Mobile IPv6 hosts in mobile networks.
さらに、モバイルIPv6 [4]により、モバイルホストはホームエージェントとのトンネルを避けるために、特派員ノードでルート最適化を実行できますが、モバイルホストがモバイルネットワークに接続されている場合、「最適化された」ルートは最適化されなくなりました。。これは、モバイルホストとその特派員ノードとの間のルートが、MRHAトンネルによって導入されたサブ最適性にさらされるためです。興味のある読者は、モバイルネットワークのモバイルIPv6ホストのネスティングとともにルートがどのように表示されるかの例については、付録Aを参照できます。
The readers should also note that the same sub-optimality would apply when the mobile host is outside the mobile network and its Correspondent Node is in the mobile network.
また、読者は、モバイルホストがモバイルネットワークの外側にあり、その特派員ノードがモバイルネットワークにある場合、同じサブオプティマリティが適用されることに注意する必要があります。
NEMO Basic Support requires all traffic from visitors to be tunneled to the Mobile Router's Home Agent. This might represent a breach in the security of the Home Network (some specific attacks against the Mobile Router's binding by rogue visitors have been documented in [8][9]). Administrators might thus fear that malicious packets will be routed into the Home Network via the bi-directional tunnel. As a consequence, it can be expected that in many deployment scenarios, policies will be put in place to prevent unauthorized Visiting Mobile Nodes from attaching to the Mobile Router.
NEMOの基本的なサポートには、訪問者からのすべてのトラフィックをモバイルルーターのホームエージェントにトンネルにする必要があります。これは、ホームネットワークのセキュリティの違反を表している可能性があります（不正な訪問者によるモバイルルーターの結合に対する特定の攻撃は、[8] [9]に文書化されています）。したがって、管理者は、悪意のあるパケットが双方向トンネルを介してホームネットワークにルーティングされることを恐れるかもしれません。結果として、多くの展開シナリオでは、不正な訪問モバイルノードがモバイルルーターに接続されないようにポリシーが導入されることが予想されます。
However, there are deployment scenarios where allowing unauthorized Visiting Mobile Nodes is actually desirable. For instance, when Mobile Routers attach to other Mobile Routers and form a nested NEMO, they depend on each other to reach the Internet. When Mobile Routers have no prior knowledge of one another (no security association, Authentication, Authorization, and Accounting (AAA), Public-Key Infrastructure (PKI), etc.), it could still be acceptable to forward packets, provided that the packets are not tunneled back to the Home Networks.
ただし、不正な訪問モバイルノードを許可することが実際に望ましい展開シナリオがあります。たとえば、モバイルルーターが他のモバイルルーターに取り付けられ、ネストされたNEMOを形成すると、インターネットに到達するために互いに依存します。モバイルルーターに互いに事前知識がない場合（セキュリティ協会、認証、認可、会計（AAA）、パブリックキーインフラストラクチャ（PKI）など）、パケットがパケットを転送することはまだ受け入れられる可能性があります。ホームネットワークにトンネルに戻されていません。
A Route Optimization mechanism that allows traffic from Mobile Network Nodes to bypass the bi-directional tunnel between a Mobile Router and its Home Agent would be a necessary first step towards a Tit for Tat model, where MRs would benefit from a reciprocal altruism, based on anonymity and innocuousness, to extend the Internet infrastructure dynamically.
モバイルネットワークノードからのトラフィックを可能にするルート最適化メカニズムは、モバイルルーターとそのホームエージェントとの間の双方向トンネルをバイパスすることです。TATモデルのTITに向けて必要な最初のステップであり、MRSは相互の利他主義の恩恵を受けます。インターネットインフラストラクチャを動的に拡張するための匿名性と無害性。
Within a nested mobile network, two Mobile Network Nodes may communicate with each other. Let us consider the previous example illustrated in Figure 1 where MNN and CN2 are sharing a communication session. With NEMO Basic Support, a packet sent from MNN to CN2 will need to be forwarded to the Home Agent of each Mobile Router before reaching CN2, whereas, a packet following the direct path between them need not even leave the mobile network. Readers are referred to Appendix A.3 for detailed illustration of the resulting routing paths.
ネストされたモバイルネットワーク内では、2つのモバイルネットワークノードが相互に通信する場合があります。MNNとCN2が通信セッションを共有している図1に示す前の例を考えてみましょう。NEMOの基本的なサポートにより、CN2に到達する前にMNNからCN2に送信されるパケットを各モバイルルーターのホームエージェントに転送する必要がありますが、それらの間の直接パスに続くパケットはモバイルネットワークを離れる必要さえありません。読者は、結果のルーティングパスの詳細な図については、付録A.3を参照してください。
Apart from the consequences of increased packet delay and packet size, which are discussed in previous sub-sections, there are two additional effects that are undesirable:
以前のサブセクションで説明されているパケットの遅延とパケットサイズの増加の結果とは別に、望ましくない2つの追加効果があります。
o when the nested mobile network is disconnected from the Internet (e.g., MR1 loses its egress connectivity), MNN and CN2 can no longer communicate with each other, even though the direct path from MNN to CN2 is unaffected;
o ネストされたモバイルネットワークがインターネットから切断されている場合（たとえば、MR1は出口接続を失います）、MNNからCN2への直接的な経路が影響を受けていない場合でも、MNNとCN2は互いに通信できなくなります。
o the egress link(s) of the root Mobile Router (i.e., MR1) becomes a bottleneck for all the traffic that is coming in and out of the nested mobile network.
o ルートモバイルルーター（つまり、MR1）の出力リンクは、ネストされたモバイルネットワークに出入りするすべてのトラフィックのボトルネックになります。
A Route Optimization mechanism could allow traffic between two Mobile Network Nodes nested within the same mobile network to follow a direct path between them, without being routed out of the mobile network. This may also off-load the processing burden of the upstream Mobile Routers when the direct path between the two Mobile Network Nodes does not traverse these Mobile Routers.
ルートの最適化メカニズムにより、同じモバイルネットワーク内にネストされた2つのモバイルネットワークノード間のトラフィックが、モバイルネットワークから外れずに外出することなく、それらの間の直接的なパスに従うことができます。これにより、2つのモバイルネットワークノード間の直接パスがこれらのモバイルルーターを横断しない場合、上流のモバイルルーターの処理負担をオフロードする場合があります。
Several configurations for the Home Network are described in [10]. In particular, there is a mobile home scenario where a (parent) Mobile Router is also a Home Agent for its mobile network. In other words, the mobile network is itself an aggregation of Mobile Network Prefixes assigned to (children) Mobile Routers.
ホームネットワークのいくつかの構成は[10]で説明されています。特に、（親）モバイルルーターがモバイルネットワークのホームエージェントでもあるモバイルホームシナリオがあります。言い換えれば、モバイルネットワーク自体は、（子供）モバイルルーターに割り当てられたモバイルネットワークプレフィックスの集約です。
A stalemate situation exists in the case where the parent Mobile Router visits one of its children. The child Mobile Router cannot find its Home Agent in the Internet and thus cannot establish its MRHA tunnel and forward the visitor's traffic. The traffic from the parent is thus blocked from reaching the Internet, and it will never bind to its own (grandparent) Home Agent. Appendix B gives a detailed illustration of how such a situation can occur.
親のモバイルルーターが子供の1人を訪問する場合には、膠着状態の状況が存在します。子供のモバイルルーターは、インターネットでホームエージェントを見つけることができないため、MRHAトンネルを確立して訪問者の交通を転送することはできません。したがって、親からのトラフィックはインターネットに到達することをブロックされ、それが独自の（祖父母の）ホームエージェントに拘束されることはありません。付録Bは、そのような状況がどのように発生するかについての詳細な図を示しています。
Then again, a Route Optimization mechanism that bypasses the nested tunnel might enable the parent traffic to reach the Internet and let it bind. At that point, the child Mobile Router would be able to reach its parent and bind in turn. Additional nested Route Optimization solutions might also enable the child to locate its Home Agent in the nested structure and bind regardless of whether or not the Internet is reachable.
繰り返しになりますが、ネストされたトンネルをバイパスするルート最適化メカニズムにより、親のトラフィックがインターネットに到達して縛られる可能性があります。その時点で、Child Mobileルーターは親に到達し、順番に結合することができます。追加のネストされたルート最適化ソリューションにより、子供はインターネットに到達可能かどうかに関係なく、ネストされた構造にホームエージェントを配置し、バインドすることもできます。
With current NEMO Basic Support, all communications to and from Mobile Network Nodes must go through the MRHA tunnel when the mobile network is away. This results in various inefficiencies associated with packet delivery. This document investigates such inefficiencies and provides the motivation behind Route Optimization for NEMO.
現在のNEMOの基本的なサポートにより、モバイルネットワークとのすべての通信とモバイルネットワークが離れている場合、MRHAトンネルを通過する必要があります。これにより、パケット配信に関連するさまざまな非効率性が生じます。このドキュメントは、このような非効率性を調査し、Nemoのルート最適化の背後にある動機を提供します。
We have described the sub-optimal effects of pinball routes with NEMO Basic Support, how they may cause a bottleneck to be formed in the Home Network, and how they get amplified with nesting of mobile networks. These effects will also be seen even when Mobile IPv6 Route Optimization is used over NEMO Basic Support. In addition, other issues concerning the nesting of mobile networks that might provide additional motivation for a NEMO Route Optimization mechanism were also explored, such as the prohibition of forwarding traffic from a Visiting Mobile Node through an MRHA tunnel due to security concerns, the impact of the MRHA tunnel on communications between two Mobile Network Nodes on different links of the same mobile network, and the possibility of a stalemate situation when Home Agents are nested within a mobile network.
NEMOの基本的なサポートを備えたピンボールルートの最適な効果、ホームネットワークでボトルネットを形成する方法、およびモバイルネットワークのネスティングで増幅する方法について説明しました。これらの効果は、モバイルIPv6ルートの最適化がNEMOの基本サポートよりも使用されている場合でも見られます。さらに、NEMOルート最適化メカニズムに追加の動機付けを提供する可能性のあるモバイルネットワークのネストに関する他の問題も検討されました。たとえば、セキュリティの懸念により、MRHAトンネルを介して訪問するモバイルノードからトラフィックを転送することを禁止するなど、同じモバイルネットワークの異なるリンク上の2つのモバイルネットワークノード間の通信に関するMRHAトンネルと、ホームエージェントがモバイルネットワーク内にネストされている場合の膠着状況の可能性。
This document highlights some limitations of NEMO Basic Support. In particular, some security concerns could prevent interesting applications of the protocol, as detailed in Section 2.5.
このドキュメントは、NEMOの基本的なサポートのいくつかの制限を強調しています。特に、いくつかのセキュリティ上の懸念は、セクション2.5で詳述されているように、プロトコルの興味深いアプリケーションを防ぐことができます。
Route Optimization for RFC 3963 [1] might introduce new threats, just as it might alleviate existing ones. This aspect will certainly be a key criterion in the evaluation of the proposed solutions.
RFC 3963 [1]のルート最適化は、既存の脅威を軽減する可能性があるように、新しい脅威を導入する可能性があります。この側面は、確かに提案されたソリューションの評価における重要な基準になるでしょう。
The authors wish to thank the co-authors of previous versions from which this document is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. Early work by Masafumi Watari on the extracted appendix was written while still at Keio University. In addition, sincere appreciation is also extended to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton, Henrik Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa, and Patrick Wetterwald for their various contributions.
著者は、この文書が導き出された以前のバージョンの共著者、マルコ・モルテニ、パイク・ウンキョン、オオニシ島、ティエリー・エルンスト、フェリックス・ウー、スワン・ジョンの共著者に感謝したいと考えています。抽出された付録に関するマサフミワタリによる初期の研究は、まだキオ大学で書かれていました。さらに、誠実な感謝は、Jari Arkko、Carlos Bernardos、Greg Daley、T.J。Kniveton、Henrik Levkowetz、Erik Nordmark、Alexandru Petrescu、Hesham Soliman、Ryuji Wakikawa、Patrick Wetterwaldのさまざまな貢献。
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[1] Devarapalli、V.、Wakikawa、R.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、RFC 3963、2005年1月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[2] Mather、J。およびM. Kojo、「Mobility関連用語」、RFC 3753、2004年6月。
[3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[3] Ernst、T。およびH. Lach、「ネットワークモビリティサポート用語」、RFC 4885、2007年7月。
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[4] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[5] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.
[5] エルンスト、T。、「ネットワークモビリティサポートの目標と要件」、RFC 4886、2007年7月。
[6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[6] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、1996年1月。
[7] Deering, S. and B. Zill, "Redundant Address Deletion when Encapsulating IPv6 in IPv6", Work in Progress, November 2001.
[7] Deering、S。およびB. Zill、「IPv6のIPv6をカプセル化するときの冗長なアドレスの削除」、2001年11月、進行中の作業。
[8] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach, "Threats for Basic Network Mobility Support (NEMO threats)", Work in Progress, January 2004.
[8] Petrescu、A.、Olivereau、A.、Janneteau、C。、およびH-Y。Lach、「基本的なネットワークモビリティサポート（NEMO脅威）の脅威」、2004年1月、進行中の作業。
[9] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat Analysis on NEMO Basic Operations", Work in Progress, July 2004.
[9] Jung、S.、Zhao、F.、Wu、S.、Kim、H-g。、およびS-W。Sohn、「Nemo Basic Operationsの脅威分析」、2004年7月、進行中の作業。
[10] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility Home Network Models", RFC RFC4887, July 2007.
[10] Thubert、P.、Wakikawa、R。、およびV. Devarapalli、「ネットワークモビリティホームネットワークモデル」、RFC RFC4887、2007年7月。
[11] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[11] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
In the following sections, we try to describe different communication models that involve a nested mobile network and to clarify the issues for each case. We illustrate the path followed by packets if we assume nodes only use Mobile IPv6 and NEMO Basic Support mechanisms. Different cases are considered where a Correspondent Node is located in the fixed infrastructure, in a distinct nested mobile network as the Mobile Network Node, or in the same nested mobile network as the Mobile Network Node. Additionally, cases where Correspondent Nodes and Mobile Network Nodes are either standard IPv6 nodes or Mobile IPv6 nodes are considered. As defined in [3], standard IPv6 nodes are nodes with no mobility functions whatsoever, i.e., they are not Mobile IPv6 or NEMO enabled. This means that they cannot move around keeping open connections and that they cannot process Binding Updates sent by peers.
以下のセクションでは、ネストされたモバイルネットワークを含むさまざまな通信モデルを説明し、各ケースの問題を明確にします。ノードがモバイルIPv6とNEMOの基本的なサポートメカニズムのみを使用していると仮定すると、パケットが続くパスを説明します。特に、特派員ノードが固定インフラストラクチャ、モバイルネットワークノードとは異なるネストされたモバイルネットワーク、またはモバイルネットワークノードと同じネストされたモバイルネットワークにある場合、さまざまなケースが考慮されます。さらに、特派員ノードとモバイルネットワークノードが標準のIPv6ノードまたはモバイルIPv6ノードのいずれかである場合が考慮されます。[3]で定義されているように、標準のIPv6ノードは、モビリティ関数がまったくないノードです。つまり、モバイルIPv6またはNEMOが有効になっているわけではありません。これは、オープンな接続を維持することができず、ピアが送信したバインディングの更新を処理できないことを意味します。
The most typical configuration is the case where a Mobile Network Node communicates with a Correspondent Node attached in the fixed infrastructure. Figure 3 below shows an example of such topology.
最も典型的な構成は、モバイルネットワークノードが固定インフラストラクチャに添付されている特派員ノードと通信する場合です。以下の図3は、そのようなトポロジの例を示しています。
+--------+ +--------+ +--------+
| MR1_HA | | MR2_HA | | MR3_HA |
+---+----+ +---+----+ +---+----+
| | |
+-------------------------+
| Internet |----+ CN
+-------------------------+
| |
+---+---+ +--+-----+
root-MR | MR1 | | VMN_HA |
+---+---+ +--------+
|
+---+---+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
----+----
MNN
Figure 3: CN Located at the Infrastructure
図3：インフラストラクチャにあるCN
The simplest case is where both MNN and CN are fixed nodes with no mobility functions. That is, MNN is a Local Fixed Node, and CN is a standard IPv6 node. Packets are encapsulated between each Mobile Router and its respective Home Agent (HA). As shown in Figure 4, in such a case, the path between the two nodes would go through:
最も単純なケースは、MNNとCNの両方がモビリティ関数のない固定ノードである場合です。つまり、MNNはローカル固定ノードであり、CNは標準のIPv6ノードです。パケットは、各モバイルルーターとそれぞれのホームエージェント（HA）の間にカプセル化されています。図4に示すように、そのような場合、2つのノード間のパスは次のとおりです。
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
LFN IPv6 Node
The digits represent the number of IPv6 headers.
数字はIPv6ヘッダーの数を表します。
Figure 4: MNN and CN Are Standard IPv6 Nodes
図4：MNNとCNは標準のIPv6ノードです
In this second case, both end nodes are Mobile IPv6-enabled mobile nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 Route Optimization may thus be initiated between the two and packets would not go through the Home Agent of the Visiting Mobile Node or the Home Agent of the Correspondent Node (not shown in the figure). However, packets will still be tunneled between each Mobile Router and its respective Home Agent, in both directions. As shown in Figure 5, the path between MNN and CN would go through:
この2番目のケースでは、両方のエンドノードはモバイルIPv6対応のモバイルノードです。つまり、MNNは訪問モバイルノードです。したがって、モバイルIPv6ルートの最適化は2つの間で開始される場合があり、パケットは訪問するモバイルノードのホームエージェントまたは特派員ノードのホームエージェントを通過しません（図には示されていません）。ただし、各モバイルルーターとそれぞれのホームエージェントの間に、両方向にパケットがトンネルされます。図5に示すように、MNNとCNの間のパスは次のとおりです。
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
VMN MIPv6
Figure 5: MNN and CN Are MIPv6 Mobile Nodes
図5：MNNとCNはMIPV6モバイルノードです
When the communication involves a Mobile IPv6 node either as a Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route Optimization cannot be performed because the standard IPv6 Correspondent Node cannot process Mobile IPv6 signaling. Therefore, MNN would establish a bi-directional tunnel with its HA, which causes the flow to go out the nested NEMO. Packets between MNN and CN would thus go through MNN's own Home Agent (VMN_HA). The path would therefore be as shown in Figure 6:
通信にモバイルIPv6ノードが訪問モバイルノードまたは特派員ノードとして含まれる場合、標準のIPv6特派員ノードがモバイルIPv6シグナリングを処理できないため、モバイルIPv6ルートの最適化を実行できません。したがって、MNNはHAを備えた双方向トンネルを確立し、流れがネモから外に出ます。したがって、MNNとCNの間のパケットは、MNN自身のホームエージェント（VMN_HA）を通過します。したがって、パスは図6に示すとおりです。
2 3 4 5 4
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA
VMN |
| 3
1 2 |
CN --- VMN_HA --- MR3_HA
IPv6 Node
Figure 6: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
図6：MNNはMIPV6モバイルノードであり、CNは標準のIPv6ノードです
Providing Route Optimization involving a Mobile IPv6 node may require optimization among the Mobile Routers and the Mobile IPv6 node.
モバイルIPv6ノードを含むルートの最適化を提供するには、モバイルルーターとモバイルIPv6ノード間で最適化が必要になる場合があります。
The Correspondent Node may be located in another nested mobile network, different from the one MNN is attached to, as shown in Figure 7. We define such configuration as "distinct nested mobile networks".
特派員ノードは、図7に示すように、1つのMNNとは異なる別のネストされたモバイルネットワークに配置される場合があります。「個別のネストされたモバイルネットワーク」と定義します。
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
| |
+---+---+ +---+---+
root-MR | MR1 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR2 | | MR5 |
+---+---+ +---+---+
| |
+---+---+ ----+----
sub-MR | MR3 | CN
+---+---+
|
----+----
MNN
Figure 7: MNN and CN Located in Distinct Nested NEMOs
図7：別個のネストされたネモにあるMNNとCN
Similar to Case A, we start off with the case where both end nodes do not have any mobility functions. Packets are encapsulated at every Mobile Router on the way out of the nested mobile network, decapsulated by the Home Agents, and then encapsulated again on their way down the nested mobile network.
ケースAと同様に、両方のエンドノードにモビリティ関数がない場合から始めます。ネストされたモバイルネットワークから出る途中のすべてのモバイルルーターにパケットがカプセル化され、ホームエージェントによって脱カプセル化され、ネストされたモバイルネットワークを下る途中で再びカプセル化されます。
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
IPv6 Node
Figure 8: MNN and CN Are Standard IPv6 Nodes
図8：MNNとCNは標準のIPv6ノードです
Similar to Case B, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6 Route Optimization. Again, packets will not go through the Home Agent of the MNN or the Home Agent of the Mobile IPv6 Correspondent Node (not shown in the figure). However, packets will still be tunneled for each Mobile Router to its Home Agent and vice versa. Therefore, the path between MNN and CN would go through:
ケースBと同様に、両方のエンドノードがモバイルIPv6ノードである場合、2つのノードはモバイルIPv6ルートの最適化を開始する場合があります。繰り返しますが、パケットはMNNのホームエージェントまたはモバイルIPv6特派員ノードのホームエージェントを通過しません（図には示されていません）。ただし、各モバイルルーターのパケットは、ホームエージェントに引き続きトンネルを施されており、その逆も同様です。したがって、MNNとCNの間のパスは以下を通過します。
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
MIPv6 Node
Figure 9: MNN and CN Are MIPv6 Mobile Nodes
図9：MNNとCNはMIPV6モバイルノードです
Similar to Case C, when the communication involves a Mobile IPv6 node either as a Visiting Mobile Node or as a Correspondent Node, MIPv6 Route Optimization cannot be performed because the standard IPv6 Correspondent Node cannot process Mobile IPv6 signaling. MNN would therefore establish a bi-directional tunnel with its Home Agent. Packets between MNN and CN would thus go through MNN's own Home Agent as shown in Figure 10:
ケースCと同様に、通信にモバイルIPv6ノードが訪問モバイルノードとして、または特派員ノードとして含まれる場合、標準のIPv6特派員ノードがモバイルIPv6シグナリングを処理できないため、MIPV6ルートの最適化は実行できません。したがって、MNNは、ホームエージェントとの双方向トンネルを確立します。したがって、MNNとCNの間のパケットは、図10に示すようにMNN自身のホームエージェントを通過します。
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
1 2 3 2 1 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA
IPv6 Node
Figure 10: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
図10：MNNはMIPV6モバイルノードで、CNは標準のIPv6ノードです
Figure 11 below shows the case where the two communicating nodes are connected behind different Mobile Routers that are connected in the same nested mobile network, and thus behind the same root Mobile Router. Route Optimization can avoid packets being tunneled outside the nested mobile network.
以下の図11は、2つの通信ノードが、同じネストされたモバイルネットワークで接続されているさまざまなモバイルルーターの後ろに接続されている場合、したがって同じルートモバイルルーターの後ろにある場合を示しています。ルートの最適化は、ネストされたモバイルネットワークの外側でトンネルを張られているパケットを避けることができます。
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN
Figure 11: MNN and CN Located in the Same Nested NEMO
図11：同じネストされたネモにあるMNNとCN
Again, we start off with the case where both end nodes do not have any mobility functions. Packets are encapsulated at every Mobile Router on the way out of the nested mobile network via the root Mobile Router, decapsulated and encapsulated by the Home Agents, and then make their way back to the nested mobile network through the same root Mobile Router. Therefore, the path between MNN and CN would go through:
繰り返しますが、両方の終了ノードにモビリティ関数がない場合から始めます。パケットは、ルートモバイルルーターを介してネストされたモバイルネットワークから出る途中のすべてのモバイルルーターにカプセル化され、ホームエージェントによって脱カプセル化され、カプセル化され、同じルートモバイルルーターを介してネストされたモバイルネットワークに戻ります。したがって、MNNとCNの間のパスは以下を通過します。
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
Figure 12: MNN and CN Are Standard IPv6 nodes
図12：MNNとCNは標準のIPv6ノードです
Similar to Case B and Case E, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6 Route Optimization, which will avoid the packets going through the Home Agent of MNN or the Home Agent of the Mobile IPv6 CN (not shown in the figure). However, packets will still be tunneled between each Mobile Router and its respective Home Agent in both directions. Therefore, the path would be the same as with Case G and go through:
ケースBとケースEと同様に、両方のエンドノードがモバイルIPv6ノードである場合、2つのノードはモバイルIPv6ルート最適化を開始する場合があります。これにより、MNNのホームエージェントまたはモバイルIPv6 CNのホームエージェントを通過するパケットが回避されます（図に示されています）。ただし、各モバイルルーターとそれぞれのホームエージェントの間にパケットが両方向にトンネルされます。したがって、パスはケースGと同じであり、以下を通過します。
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
MIPv6 Node
Figure 13: MNN and CN Are MIPv6 Mobile Nodes
図13：MNNとCNはMIPV6モバイルノードです
As for Case C and Case F, when the communication involves a Mobile IPv6 node either as a Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route Optimization cannot be performed. Therefore, MNN will establish a bi-directional tunnel with its Home Agent. Packets between MNN and CN would thus go through MNN's own Home Agent. The path would therefore be as shown in Figure 14:
ケースCおよびケースFについては、通信にモバイルIPv6ノードが訪問モバイルノードまたは特派員ノードとして含まれる場合、モバイルIPv6ルートの最適化は実行できません。したがって、MNNはホームエージェントとの双方向トンネルを確立します。したがって、MNNとCNの間のパケットは、MNN自身のホームエージェントを通過します。したがって、パスは図14に示すとおりです。
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
Figure 14: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
図14：MNNはMIPV6モバイルノードであり、CNは標準のIPv6ノードです
Figure 15 below shows the case where the two communicating nodes are connected behind the same nested Mobile Router. The optimization is required when the communication involves MIPv6-enabled nodes.
以下の図15は、2つの通信ノードが同じネストされたモバイルルーターの後ろに接続されている場合を示しています。通信にMIPV6対応ノードが含まれる場合、最適化が必要です。
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+---+---+
|
+-------+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
-+--+--+-
MNN CN
Figure 15: MNN and CN Located Behind the Same Nested MR
図15：同じネストされたMRの後ろにあるMNNとCN
If both end nodes are Local Fixed Nodes, no special function is necessary for optimization of their communications. The path between the two nodes would go through:
両方のエンドノードがローカル固定ノードである場合、通信を最適化するために特別な機能は必要ありません。2つのノード間のパスは次のようになります。
1 MNN --- CN LFN IPv6 Node
1 MNN --- CN LFN IPv6ノード
Figure 16: MNN and CN Are Standard IPv6 Nodes
図16：MNNとCNは標準のIPv6ノードです
Similar to Case H, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6 Route Optimization. Although few packets would go out the nested mobile network for the Return Routability initialization, however, unlike Case B and Case E, packets will not get tunneled outside the nested mobile network. Therefore, packets between MNN and CN would eventually go through:
ケースHと同様に、両方のエンドノードがモバイルIPv6ノードである場合、2つのノードはモバイルIPv6ルートの最適化を開始する場合があります。ただし、リターンルー上の初期化のためにネストされたモバイルネットワークを出すパケットはほとんどありませんが、ケースBやケースEとは異なり、パケットはネストされたモバイルネットワークの外でトンネルを取得しません。したがって、MNNとCNの間のパケットは最終的に経過します。
1 MNN --- CN VMN MIPv6 Node
1 MNN --- CN VMN MIPV6ノード
Figure 17: MNN and CN are MIPv6 Mobile Nodes
図17：MNNとCNはMIPV6モバイルノードです
If the root Mobile Router is disconnected while the nodes exchange keys for the Return Routability procedure, they may not communicate even though they are connected on the same link.
ルートモバイルルーターが切断されている場合、ノードがリターンルー上の手順と交換するキーを交換する場合、同じリンクで接続されている場合でも通信しない場合があります。
When the communication involves a Mobile IPv6 node either as a Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 Route Optimization cannot be performed. Therefore, even though the two nodes are on the same link, MNN will establish a bi-directional tunnel with its Home Agent, which causes the flow to go out the nested mobile network. The path between MNN and CN would require another Home Agent (VMN_HA) to go through for this Mobile IPv6 node:
通信にモバイルIPv6ノードが訪問モバイルネットワークノードとして、または特派員ノードとして含まれる場合、モバイルIPv6ルートの最適化は実行できません。したがって、2つのノードが同じリンク上にあるにもかかわらず、MNNはホームエージェントとの双方向トンネルを確立し、フローがネストされたモバイルネットワークから外に出ます。MNNとCNの間のパスでは、このモバイルIPv6ノードのために別のホームエージェント（VMN_HA）を通過する必要があります。
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
IPv6 Node
Figure 18: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
図18：MNNはMIPV6モバイルノードであり、CNは標準のIPv6ノードです
However, MNN may also decide to use its Care-of Address (CoA) as the source address of the packets, thus avoiding the tunneling with the MNN's Home Agent. This is particularly useful for a short-term communications that may easily be retried if it fails. Default Address Selection [11] provides some mechanisms for controlling the choice of the source address.
ただし、MNNは、パケットのソースアドレスとしてそのケアオブアドレス（COA）を使用することも決定する場合があり、MNNのホームエージェントとのトンネルを回避することもできます。これは、失敗した場合に簡単に再試行する可能性のある短期通信に特に役立ちます。デフォルトのアドレス選択[11]は、ソースアドレスの選択を制御するためのいくつかのメカニズムを提供します。
Section 2.7 describes the occurrence of a stalemate situation where a Home Agent of a Mobile Router is nested behind the Mobile Router. Here, we illustrate a simple example where such a situation can occur.
セクション2.7では、モバイルルーターのホームエージェントがモバイルルーターの後ろにネストされている膠着状態の発生について説明します。ここでは、そのような状況が発生する可能性のある簡単な例を示します。
Consider a mobility configuration depicted in Figure 19 below. MR1 is served by HA1/BR and MR2 is served by HA2. The 'BR' designation indicates that HA1 is a border router. Both MR1 and MR2 are at home in the initial step. HA2 is placed inside the first mobile network, thus representing a "mobile" Home Agent.
以下の図19に示すモビリティ構成を検討してください。MR1はHA1/BRによって提供され、MR2はHA2が提供します。「BR」の指定は、HA1がボーダールーターであることを示しています。MR1とMR2の両方が最初のステップで自宅にいます。HA2は最初のモバイルネットワーク内に配置されているため、「モバイル」ホームエージェントを表します。
/-----CN
+----------+
home link 1 +--------+ | |
----+-----------------| HA1/BR |---| Internet |
| +--------+ | |
| +----------+
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
-+--------+-- mobile net 1 / home link 2
|
+--+--+ +--+--+
| MR2 | | LFN |
+--+--+ +--+--+
| |
-+--------+- mobile net 2
Figure 19: Initial Deployment
図19：初期展開
In Figure 19 above, communications between CN and LFN follow a direct path as long as both MR1 and MR2 are positioned at home. No encapsulation intervenes.
上の図19では、CNとLFNの間の通信は、MR1とMR2の両方が自宅に配置されている限り、直接的な経路をたどります。カプセル化は介入しません。
In the next step, consider that the MR2's mobile network leaves home and visits a foreign network, under Access Router (AR) like in Figure 20 below.
次のステップでは、MR2のモバイルネットワークが家を出て、以下の図20のようにアクセスルーター（AR）の下で外国ネットワークを訪問することを検討してください。
/-----CN
+----------+
home link 1 +--------+ | |
--+-----------| HA1/BR |---| Internet |
| +--------+ | |
+--+--+ +-----+ +----------+
| MR1 | | HA2 | \
+--+--+ +--+--+ +-----+
| | | AR |
-+--------+- mobile net 1 +--+--+
home link 2 |
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
Figure 20: Mobile Network 2 Leaves Home
図20：モバイルネットワーク2は家を離れます
Once MR2 acquires a Care-of Address under AR, the tunnel setup procedure occurs between MR2 and HA2. MR2 sends a Binding Update to HA2 and HA2 replies with a Binding Acknowledgement to MR2. The bi-directional tunnel has MR2 and HA2 as tunnel endpoints. After the tunnel MR2HA2 has been set up, the path taken by a packet from CN towards LFN can be summarized as:
MR2がARの下でケアオブアドレスを取得すると、MR2とHA2の間でトンネルセットアップ手順が発生します。MR2は、結合アップデートをHA2に送信し、HA2応答はMR2への拘束力のある承認を得て送信します。双方向トンネルには、トンネルエンドポイントとしてMR2とHA2があります。トンネルMR2HA2がセットアップされた後、CNからLFNへのパケットによって採用されたパスは、次のように要約できます。
CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN.
cn-> br-> mr1-> ha2 => mr1 => br => ar => mr2-> lfn。
Non-encapsulated packets are marked "->" while encapsulated packets are marked "=>".
カプセル化されていないパケットは「 - >」とマークされ、カプセル化されたパケットは「=>」とマークされます。
Consider next the attachment of the first mobile network under the second mobile network, like in Figure 21 below.
次の図21のように、2番目のモバイルネットワークの下にある最初のモバイルネットワークの添付ファイルを次に考えてください。
After this movement, MR1 acquires a Care-of Address valid in the second mobile network. Subsequently, it sends a Binding Update (BU) message addressed to HA1. This Binding Update is encapsulated by MR2 and sent towards HA2, which is expected to be placed in mobile net 1 and expected to be at home. Once HA1/BR receives this encapsulated BU, it tries to deliver to MR1. Since MR1 is not at home, and a tunnel has not yet been set up between MR1 and HA1, HA1 is not able to route this packet and drops it. Thus, the tunnel establishment procedure between MR1 and HA1 is not possible, because the tunnel between MR2 and HA2 had been previously torn down (when the mobile net 1 moved from home). The communications between CN and LFN stops, even though both mobile networks are connected to the Internet.
この動きの後、MR1は2番目のモバイルネットワークで有効なケアアドレスを取得します。その後、HA1にアドレス指定されたバインディングアップデート（BU）メッセージを送信します。このバインディングアップデートはMR2によってカプセル化され、HA2に送られます。HA2はモバイルネット1に配置され、自宅にいると予想されます。HA1/BRがこのカプセル化されたBUを受信すると、MR1に配信しようとします。MR1は自宅にいないため、MR1とHA1の間にトンネルがまだ設定されていないため、HA1はこのパケットをルーティングすることができず、ドロップします。したがって、MR1とHA1の間のトンネルの確立手順は不可能です。これは、MR2とHA2の間のトンネルが以前に取り壊されていたためです（モバイルネット1が自宅から移動したとき）。両方のモバイルネットワークがインターネットに接続されていても、CNとLFNの間の通信は停止します。
/-----CN
+----------+
+--------+ | |
| HA1/BR |---| Internet |
+--------+ | |
+----------+
\
+-----+
| AR |
+--+--+
|
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
|
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
mobile net 1 -+--------+-
Figure 21: Stalemate Situation Occurs
図21：膠着状態の状況が発生します
If both tunnels between MR1 and HA1, and between MR2 and HA2, were up simultaneously, they would have "crossed over" each other. If the tunnels MR1-HA1 and MR2-HA2 were drawn in Figure 21, it could be noticed that the path of the tunnel MR1-HA1 includes only one endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two MR-HA tunnels are crossing over each other if the IP path between two endpoints of one tunnel includes one and only one endpoint of the other tunnel (assuming that both tunnels are up). When both endpoints of one tunnel are included in the path of the other tunnel, then tunnels are simply encapsulating each other.
MR1とHA1の間、およびMR2とHA2の間の両方のトンネルが同時に上昇した場合、それらは互いに「交差して」いたでしょう。トンネルMR1-HA1とMR2-HA2が図21に描かれている場合、トンネルMR1-HA1の経路には、トンネルMR2-HA2（MR2エンドポイント）の1つのエンドポイントのみが含まれていることに気付くことができます。1つのトンネルの2つのエンドポイント間のIPパスに、他のトンネルの1つのエンドポイントのみが1つだけ含まれている場合、2つのMR-HAトンネルが互いに交差しています（両方のトンネルが上がっていると仮定）。1つのトンネルの両方のエンドポイントが他のトンネルの経路に含まれている場合、トンネルは単に互いにカプセル化されています。
Authors' Addresses
著者のアドレス
Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate, Singapore 534415 SG
Chan-wah ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave＃06-3530 Tai Seng Industrial Estate、Singapore 534415 SG
Phone: +65 65505420
EMail: chanwah.ng@sg.panasonic.com
Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3, Biot - Sophia Antipolis 06410 FRANCE
Pascal Thubert Cisco Systems Village D'Entreprises Green Side 400、Avenue de Roumanille Batiment T3、Biot -Sophia Antipolis 06410 France
EMail: pthubert@cisco.com
Masafumi Watari KDDI R&D Laboratories Inc. 2-1-15 Ohara Fujimino, Saitama 356-8502 JAPAN
Masafumi Watari Kddi R＆D Laboratories Inc. 2-1-15 Ohara Fujimino、Saitama 356-8502 Japan
EMail: watari@kddilabs.jp
Fan Zhao UC Davis One Shields Avenue Davis, CA 95616 US
ファンZhao UC Davis One Shields Avenue Davis、CA 95616 US
Phone: +1 530 752 3128
EMail: fanzhao@ucdavis.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。