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）IETFトラスト（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ベーシックサポートは、問題がより複雑になって、追加的な多くの問題を提示し、それは別にルート最適化に対処することを決定しました。その場合には、期待される利益は、より劇的であり、ルート最適化メカニズムは、それ以外の場合は壊れてしまうの接続を可能にすることができます。その意味で、ルート最適化は、それがモバイル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]で定義されたNEMO関連用語[3]、及び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ベーシックサポートと、モバイルネットワークノードとその通信先ノード間で送信されるすべてのパケットは、2つのノード間のピンボールの経路をもたらす、MRHAトンネルを介して転送されます。これは、次のサブ最適な効果があります。
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ヘッダは、音声サンプルのような用途のためにペイロードに極めて実質的な相対的であることができる、これは、帯域幅の効率を低下させます。例えば、（RFC 1889のように[6]）毎に20ミリ秒を8 Kbpsのアルゴリズム（例えば、G.729）を用いて、音声サンプルを採取音声アプリケーションを考えると、パケット送信速度は、毎秒50のパケットであろう。各追加のIPv6ヘッダーは二倍実際のペイロードであるパケット当たり余分320ビット（すなわち、16 kbpsの）、です！
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.
パケットのカプセル化によるパケットサイズの増大は、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.
ホームネットワークの輻輳に遅れたり、破棄されたデータパケットは、アプリケーションに追加のパフォーマンスの低下を引き起こします。ホームネットワークの輻輳に遅れたり、破棄されるようにBinding Updateメッセージとしてシグナリングパケットは、これらのトンネルを通過するすべてのトラフィックフローの混乱を引き起こして、双方向トンネルの確立や更新に影響を与える可能性があります。
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ベーシックサポートは、来場者からのすべてのトラフィックは、モバイルルータのホームエージェントにトンネルすることが必要です。これは、（[9]不正な訪問者によってモバイルルータのバインディングに対していくつかの特定の攻撃はで文書化されている[8]）ホームネットワークのセキュリティに違反を表すことができます。管理者は、このように悪意のあるパケットが双方向トンネルを経由してホームネットワークにルーティングされることを恐れるかもしれません。結果として、多くの展開シナリオでは、ポリシーはモバイルルータに付着する不正訪問モバイルノードを防ぐために、所定の位置に置かれることを期待することができます。
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.
モバイルネットワークノードからのトラフィックは、モバイルルータとそのホームエージェントとの間の双方向トンネルのMRが相互利他恩恵を受けるTatのモデルのための乳首に向かって必要な最初のステップであろうバイパスすることを可能にするルート最適化メカニズムに基づきます匿名性と無害性は、動的にインターネットインフラストラクチャを拡張します。
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:
離れた前のサブセクションで説明しているが増加パケット遅延およびパケットサイズの結果から、望ましくない二つの追加効果があります。
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;
階層型移動ネットワークが（例えば、MR1は、その出力接続を失う）、インターネットから切断されたときにO、MNNとCN2はもはやCN2へMNNからの直接経路が影響を受けない場合であっても、互いに通信することができません。
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.
ルート移動ルータ（すなわち、MR1）の出口リンク（S）O階層型移動ネットワークの内外来ているすべてのトラフィックのボトルネックとなります。
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.
その後、再び、ネストされたトンネルを迂回ルート最適化メカニズムは、インターネットに到達し、それが結合できるように、親トラフィックを有効かもしれません。その時点で、子モバイルルータは、その親に到達し、順番に結合することができるだろう。追加のネストされたルート最適化ソリューションはまた、入れ子構造にそのホームエージェントを見つけ、関係なく、インターネットが到達可能であるかどうかをバインドするために子を有効かもしれません。
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.
マルコMolteni、パイクウン・ヘギョン、博之大西、ティエリーエルンスト、フェリックス・ウー、およびSouhwanユング：著者は、この文書が由来する以前のバージョンの共著者に感謝したいです。抽出された付録に雅文亘理による初期の作品は、慶應義塾大学でしばらくはまだ書かれていました。また、心からの感謝もヤリArkko、カルロスBernardos、グレッグ・デイリー、T.J.に拡張され彼らの様々な貢献のためKniveton、ヘンリクLevkowetz、エリックNordmarkと、アレクサンドル・ペトレスク、Heshamソリマン、竜二Wakikawa、そしてパトリック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.、ペトレスク、A.、およびP. Thubert、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、2005年1月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[2]のようにして、J.とM.古城、 "モビリティ関連用語"、RFC 3753、2004年6月。
[3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[3]エルンスト、T.とH. LACH、 "ネットワークモビリティサポート用語"、RFC 4885、2007年7月。
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[4]ジョンソン、D.、パーキンス、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.、フレデリック、R.、およびV.ヤコブソン、 "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]デアリング、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]ペトレスク、A.、Olivereau、A.、Janneteau、C.、およびH-Y。 、進捗状況、2004年1月の作業LACH、「基本的なネットワークモビリティサポート（NEMOの脅威）のための脅威」。
[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]ユング、S.、趙、F.、ウー、S.、金、H-G。、およびS-W。孫、「NEMO基本操作上の脅威分析」、進歩、2004年7月に作業。
[10] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility Home Network Models", RFC RFC4887, July 2007.
[10] tubert、フィル。、Vakikava、道路。、と判断。 Devarapalli、 "ネットワークモビリティホームネットワークモデル"、rphakのrphsi 4887、2007年7月。
[11] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[11] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
Appendix A. Various Configurations Involving Nested Mobile Networks
ネストされたモバイルネットワークを伴う付録A.さまざまな構成
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が有効になっていない、一切のモビリティ機能を有するノードです。これは、彼らが開いている接続を維持し、彼らは仲間によって送られた結合更新を処理できないことを動き回ることができないことを意味します。
A.1. CN Located in the Fixed Infrastructure
A.1。固定インフラストラクチャに位置CN
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インフラストラクチャに位置
A.1.1. Case A: LFN and Standard IPv6 CN
A.1.1。ケースA：LFNと標準のIPv6 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ノード
A.1.2. Case B: VMN and MIPv6 CN
A.1.2。ケースB：VMNとMIPv6のCN
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:
この第二の場合では、両方のエンドノードがモバイル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のモバイルノードです
A.1.3. Case C: VMN and Standard IPv6 CN
A.1.3。ケースC：VMNと標準のIPv6 CN
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は、ネストされたNEMOを外出する流れが発生し、その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ノード間の最適化が必要な場合があります。
A.2. CN Located in Distinct Nested NEMOs
A.2。個別ネストされたNEMOsに位置CN
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に示すように、通信先ノードは、に付着されたもの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：個別ネストNEMOsに位置MNNとCN
A.2.1. Case D: LFN and Standard IPv6 CN
A.2.1。ケースD：LFNと標準のIPv6 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ノード
A.2.2. Case E: VMN and MIPv6 CN
A.2.2。ケースE：VMNとMIPv6のCN
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:
両方のエンドノードがモバイルIPv6ノードである場合ケースBと同様に、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のモバイルノードです
A.2.3. Case F: VMN and Standard IPv6 CN
A.2.3。ケースF：VMNと標準のIPv6 CN
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:
標準のIPv6対応ノードがモバイルIPv6シグナリングを処理できないため、通信が訪問モバイルノードとして、または対応ノード、MIPv6の経路最適化のいずれかとモバイルIPv6ノードを伴うケースCと同様に行うことができません。 MNNは、したがって、そのホームエージェントとの双方向トンネルを確立します。図10に示すように、MNNとCN間のパケットは、このように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ノードであります
A.3. MNN and CN Located in the Same Nested NEMO
A.3。同じネストされたNEMOに位置MNNとCN
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：同じネストされたNEMOに位置MNNとCN
A.3.1. Case G: LFN and Standard IPv6 CN
A.3.1。ケースG：LFNと標準のIPv6 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ノード
A.3.2. Case H: VMN and MIPv6 CN
A.3.2。ケースH：VMNとMIPv6のCN
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:
両方のエンドノードがモバイルIPv6ノードがあるケースBとケースEと同様に、MNNのホームエージェントまたはモバイルIPv6 CNのホームエージェント（ない通過するパケットを避けるためであろう、モバイルIPv6経路最適化を開始することができる二つのノード図に示されています）。ただし、パケットはまだ両方の方向に各モバイルルータとそのそれぞれのホームエージェントとの間でトンネルされます。したがって、パスケース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のモバイルノードです
A.3.3. Case I: VMN and Standard IPv6 CN
A.3.3。ケースI：VMNと標準のIPv6 CN
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:
通信が訪問モバイルノードとして、または対応ノードのいずれかとモバイルIPv6ノードを伴うケースCとケースF、として、モバイル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ノードであります
A.4. CN Located Behind the Same Nested MR
A.4。同じネストされたMRの背後にあるCN
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
A.4.1. Case J: LFN and Standard IPv6 CN
A.4.1。ケースJ：LFNと標準のIPv6 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
Figure 16: MNN and CN Are Standard IPv6 Nodes
図16：MNNとCNされている標準的なIPv6ノード
A.4.2. Case K: VMN and MIPv6 CN
A.4.2。ケースK：VMNとMIPv6のCN
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:
両方のエンドノードがモバイルIPv6ノードである場合にケースHと同様に、2つのノードはモバイルIPv6ルート最適化を開始することができます。いくつかのパケットが往復経路の初期化のために、ネストされたモバイルネットワークを出て行くだろうが、しかし、ケースBとケースEとは異なり、パケットは、ネストされたモバイルネットワークの外にトンネリングされません。したがって、MNNとCN間のパケットは最終的に通過します：
1
MNN --- CN
VMN MIPv6 Node
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.
ルート移動ルータがリターンルータビリティ手順のためのノード交換鍵ながら切断された場合、それらは、それらが同じリンク上に接続されていても通信できないことがあります。
A.4.3. Case L: VMN and Standard IPv6 CN
A.4.3。ケースL：VMNと標準のIPv6 CN
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もこれMNNのホームエージェントとのトンネリングを避け、パケットの送信元アドレスとしてその気付アドレス（CoA）を使用することもできます。これは、失敗した場合に容易に再試行することができる短期の通信のために特に有用です。デフォルトのアドレス選択[11]は送信元アドレスの選択を制御するためのいくつかのメカニズムを提供します。
Appendix B. Example of How a Stalemate Situation Can Occur
手詰まりの状況がどのように発生するかを付録B.例
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が設定された後、LFN向かっCNからのパケットによって取られる経路は、以下のように要約することができます。
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は、ケアの第二のモバイルネットワークで有効なアドレスを取得します。その後、それは、バインディングアップデート（BU）メッセージがHA1宛に送信します。このバインディング更新はMR2によってカプセル化され、モバイルネット1に入れて、家であることが予想されると予想されるHA2に向けて送信されます。 HA1 / BRは、このカプセル化されたBUを受信すると、それはMR1に配信しよう。 MR1は自宅ではなく、トンネルがまだMR1とHA1間に設定されていないので、HA1は、このパケットをルーティングすることができず、それを削除します。 （モバイルネット1が自宅から移動する場合）MR2とHA2との間のトンネルが以前に取り壊されていたので、このように、MR1とHA1との間のトンネル確立手順は、不可能です。 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つのトンネルの2つのエンドポイント間のIPパスが一方及び他方のトンネル（両方のトンネルが起動していると仮定して）のいずれか一方のみのエンドポイントを含む場合、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
チャン・ワウ呉パナソニックシンガポール研究所Pte株式会社BLK 1022タイセンアベニュー＃06から3530タイセン工業団地、シンガポール534415 SG
Phone: +65 65505420 EMail: chanwah.ng@sg.panasonic.com
電話：+65 65505420 Eメール：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
パスカルThubertシスコシステムズエンタープライズヴィレッジグリーンサイド400アベニューRoumanilleビルT3、ビオ - ソフィアアンティポリス06410 FRANCE
EMail: pthubert@cisco.com
メールアドレス：pthubert@cisco.com
Masafumi Watari KDDI R&D Laboratories Inc. 2-1-15 Ohara Fujimino, Saitama 356-8502 JAPAN
まさふみ わたり Ｋっぢ Ｒ＆Ｄ ぁぼらとりえｓ いんｃ。 ２ー１ー１５ おはら ふじみの、 さいたま ３５６ー８５０２ じゃぱん
EMail: watari@kddilabs.jp
メールアドレス：watari@kddilabs.jp
Fan Zhao UC Davis One Shields Avenue Davis, CA 95616 US
ファン趙UCデービス一つシールズアベニューデイビス、CA 95616米国
Phone: +1 530 752 3128 EMail: fanzhao@ucdavis.edu
電話：+1 530 752 3128 Eメール：fanzhao@ucdavis.edu
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機能のための基金は現在、インターネット協会によって提供されます。