[要約] RFC 4980は、ネットワークモビリティサポートにおけるマルチホーミングの分析に関するものであり、モビリティ管理の改善とネットワークの信頼性向上を目的としています。
Network Working Group C. Ng
Request for Comments: 4980 Panasonic Singapore Labs
Category: Informational T. Ernst
INRIA
E. Paik
KT
M. Bagnulo
UC3M
October 2007
Analysis of Multihoming in Network Mobility Support
ネットワークモビリティサポートにおけるマルチホームの分析
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues.
このドキュメントは、IPv6のネットワークモビリティ（NEMO）のコンテキストでのマルチホームの分析です。モバイルネットワークをマルチホームにする可能性のある多くの状況があるため、可能な構成を分類するために分類が提案されています。マルチホームモバイルネットワークの可能な展開シナリオは、ネットワークモビリティがRFC 3963（NEMO Basic Support）によってサポートされている場合、関連する問題と一緒に説明されています。これらの問題に対処する方法について推奨事項が提供されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 6
2.2. (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 6
2.3. (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 7
2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 8
2.5. (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 8
2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 9
2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 9
2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 10
3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 11
3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 11
3.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13
4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 15
4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 16
4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 17
4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 19
4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 21
4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 22
4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 23
4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 23
4.7. Source Address Selection . . . . . . . . . . . . . . . . . 23
4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 24
4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 24
4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 25
5. Recommendations to the Working Group . . . . . . . . . . . . . 26
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Alternative Classifications Approach . . . . . . . . 32
A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 32
A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 32
A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 33
A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 34
Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 35
B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 35
B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 36
B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 36
B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 36
B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 37
B.4. Points of Considerations . . . . . . . . . . . . . . . . . 37
The design goals and objectives of Network Mobility (NEMO) support in IPv6 are identified in [1], while the terminology is described in [2] and [3]. NEMO Basic Support (RFC 3963) [4] is the solution proposed by the NEMO Working Group to provide continuous Internet connectivity to nodes located in an IPv6 mobile network, e.g., like in an in-vehicle embedded IP network. The NEMO Basic Support solution does so by setting up bi-directional tunnels between the mobile routers (MRs) connecting the mobile network (NEMO) to the Internet and their respective home agents (HAs), much like how this is done in Mobile IPv6 [5], the solution for host mobility support. NEMO Basic Support is transparent to nodes located behind the MR (i.e., the mobile network nodes, or MNNs), and as such, does not require MNNs to take any action in the mobility management.
IPv6のネットワークモビリティ（NEMO）サポートの設計目標と目的は[1]で特定されていますが、用語は[2]および[3]で説明されています。Nemo Basic Support（RFC 3963）[4]は、IPv6モバイルネットワークにあるノードに連続的なインターネット接続を提供するためにNEMOワーキンググループによって提案されたソリューションです。NEMO Basic Supportソリューションは、モバイルネットワーク（NEMO）をインターネット（NEMO）とそれぞれのホームエージェント（持っている）に接続するモバイルルーター（MRS）の間に双方向トンネルをセットアップすることにより、これがモバイルIPv6で行われる方法と同じです[5]、ホストモビリティサポートのソリューション。NEMOの基本的なサポートは、MRの背後にあるノード（つまり、モバイルネットワークノード、またはMNNS）に対して透過的であるため、MNNSにモビリティ管理においてアクションを実行する必要はありません。
However, mobile networks are typically connected by means of wireless and thus less reliable links; there could also be many nodes behind the MR. A loss of connectivity or a failure to connect to the Internet has thus a more significant impact than for a single mobile node. Scenarios illustrated in [6] demonstrate that providing a permanent access to mobile networks typically require the use of several interfaces and technologies. For example, this is particularly useful for Intelligent Transport Systems (ITS) applications since vehicles are moving across distant geographical locations. Access would be provided through different access technologies (e.g., Wimax, Wifi, 3G) and through different access operators.
ただし、通常、モバイルネットワークはワイヤレスで接続されているため、信頼性の低いリンクによって接続されます。MRの背後には多くのノードがある可能性もあります。したがって、接続性の喪失またはインターネットへの接続に失敗すると、単一のモバイルノードよりも大きな影響があります。[6]に示されているシナリオは、モバイルネットワークへの永続的なアクセスを提供することで、通常、いくつかのインターフェイスとテクノロジーの使用が必要であることを示しています。たとえば、これは、車両が遠い地理的場所を横切って移動しているため、インテリジェント輸送システム（ITS）アプリケーションに特に役立ちます。アクセスは、さまざまなアクセステクノロジー（Wimax、WiFi、3Gなど）および異なるアクセスオペレーターを通じて提供されます。
As specified in Section 5 of the NEMO Basic Support Requirements [1] (R.12), the NEMO WG must ensure that NEMO Basic Support does not prevent mobile networks to be multihomed, i.e., when there is more than one point of attachment between the mobile network and the Internet (see definitions in [3]). This arises either:
NEMO基本サポート要件[1]（R.12）のセクション5で指定されているように、NEMO WGは、NEMOの基本サポートがモバイルネットワークをマルチホームにしないようにしなければなりません。モバイルネットワークとインターネット（[3]の定義を参照）。これはどちらも発生します：
o when an MR has multiple egress interfaces, or
o MRに複数の出口インターフェイスがある場合
o the mobile network has multiple MRs, or
o モバイルネットワークには複数のMRSがあります
o the mobile network is associated with multiple HAs, or
o モバイルネットワークは複数に関連付けられています。
o multiple global prefixes are available in the mobile network.
o モバイルネットワークで複数のグローバルプレフィックスを利用できます。
Using NEMO Basic Support, this would translate into having multiple bi-directional tunnels between the MR(s) and the corresponding HA(s), and may result in multiple Mobile Network Prefixes (MNPs) available to the MNNs. However, NEMO Basic Support does not specify any particular mechanism to manage multiple bi-directional tunnels. The objectives of this memo are thus multifold:
NEMOの基本的なサポートを使用すると、これはMR（S）と対応するHA（S）の間に複数の双方向トンネルを持つことにつながり、MNNSが利用できる複数のモバイルネットワークプレフィックス（MNP）をもたらす可能性があります。ただし、NEMOの基本的なサポートは、複数の双方向トンネルを管理するための特定のメカニズムを指定していません。したがって、このメモの目的は多面的です。
o to determine all the potential multihomed configurations for a NEMO, and then to identify which of these may be useful in a real-life scenario;
o NEMOのすべての潜在的なマルチホーム構成を決定し、実際のシナリオでこれらのどれが役立つかを特定するため。
o to capture issues that may prevent some multihomed configurations to be supported under the operation of NEMO Basic Support. It does not necessarily mean that the ones not supported will not work with NEMO Basic Support, as it may be up to the implementors to make it work (hopefully this memo will be helpful to these implementors);
o NEMO基本サポートの操作の下でサポートされるマルチホーム構成を妨げる可能性のある問題をキャプチャするため。サポートされていないものがNEMOの基本的なサポートで動作しないことを必ずしも意味しません。それを機能させるのは実装者次第である可能性があるためです（このメモがこれらの実装者に役立つことを願っています）。
o to decide which issues are worth solving and to determine which WG is the most appropriate to address these;
o どの問題が解決する価値があるかを決定し、これらに対処するのに最も適切なWGを決定する。
o to identify potential solutions to the previously identified issues.
o 以前に特定された問題に対する潜在的な解決策を特定する。
In order to reach these objectives, a taxonomy for classifying the possible multihomed configurations is described in Section 2. Deployment scenarios, their benefits, and requirements to meet these benefits are illustrated in Section 3. Following this, the related issues are studied in Section 4. The issues are then summarized in a matrix for each of the deployment scenario, and recommendations are made on which of the issues should be worked on and where in Section 5. This memo concludes with an evaluation of NEMO Basic Support for multihomed configurations. Alternative classifications are outlined in the Appendix.
これらの目的に到達するために、可能なマルチホーム構成を分類するための分類法について、セクション2で説明します。これらの利点を満たすための展開シナリオ、それらの利点、および要件をセクション3に示します。次に、各展開シナリオのマトリックスに問題が要約され、セクション5の問題のどの問題と場所について推奨が行われます。このメモは、マルチホーム構成のNEMO基本サポートの評価で終わります。代替分類については、付録に概説しています。
The readers should note that this document considers multihoming only from the point of view of an IPv6 environment. In order to understand this memo, the reader is expected to be familiar with the above cited documents, i.e., with the NEMO terminology as defined in [2] (Section 3) and [3], Motivations and Scenarios for Multihoming [6], Goals and Requirements of Network Mobility Support [1], and the NEMO Basic Support specification [4]. Goals and benefits of multihoming as discussed in [6], are applicable to fixed nodes, mobile nodes, fixed networks, and mobile networks.
読者は、この文書がIPv6環境の観点からのみマルチホームを考慮していることに注意する必要があります。このメモを理解するために、読者は上記の引用文書、つまり[2]（セクション3）および[3]で定義されているNEMO用語、マルチホミングの動機とシナリオに精通していることが期待されています[6]、ネットワークモビリティサポート[1]の目標と要件、およびNEMO基本サポート仕様[4]。[6]で説明したマルチホームの目標と利点は、固定ノード、モバイルノード、固定ネットワーク、およびモバイルネットワークに適用できます。
As there are several configurations in which mobile networks are multihomed, there is a need to classify them into a clearly defined taxonomy. This can be done in various ways. A Configuration-Oriented taxonomy is described in this section. Two other taxonomies, namely, the Ownership-Oriented Approach and the Problem-Oriented Approach, are outlined in Appendix A.1 and Appendix A.2.
モバイルネットワークがマルチホームされているいくつかの構成があるため、それらを明確に定義された分類法に分類する必要があります。これはさまざまな方法で実行できます。このセクションでは、構成指向の分類法について説明します。他の2つの分類法、すなわち、所有権指向のアプローチと問題指向のアプローチは、付録A.1と付録A.2に概説されています。
Multihomed configurations can be classified depending on how many MRs are present, how many egress interfaces, Care-of Address (CoA), and Home Addresses (HoA) the MRs have, how many prefixes (MNPs) are available to the mobile network nodes, etc. We use three key parameters to differentiate the multihomed configurations. Using these parameters, each configuration is referred by the 3-tuple (x,y,z), where 'x', 'y', 'z' are defined as follows:
マルチホーム構成は、MRSの数、出口インターフェイス、ケアオブアドレス（COA）、およびMRSが持っているホームアドレス（HOA）の数、モバイルネットワークノードで利用可能なプレフィックス（MNP）の数に応じて分類できます。など。3つの重要なパラメーターを使用して、マルチホーム構成を区別します。これらのパラメーターを使用して、各構成は3タプル（x、y、z）によって参照されます。ここで、「x」、 'y'、 'z'は次のように定義されます。
o 'x' indicates the number of MRs where:
o 'x'はMRSの数を示します。
x=1 implies that a mobile network has only a single MR, presumably multihomed.
X = 1は、モバイルネットワークには単一のMRのみがあることを意味します。おそらくマルチホームです。
x=n implies that a mobile network has more than one MR.
x = nは、モバイルネットワークに複数のMRがあることを意味します。
o 'y' indicates the number of HAs associated with the entire mobile network, where:
o 「Y」は、モバイルネットワーク全体に関連付けられていることを示しています。
y=1 implies that a single HA is assigned to the mobile network.
y = 1は、単一のHAがモバイルネットワークに割り当てられていることを意味します。
y=n implies that multiple HAs are assigned to the mobile network.
y = nは、複数がモバイルネットワークに割り当てられていることを意味します。
o 'z' indicates the number of MNPs available within the NEMO, where:
o 「Z」は、NEMO内で利用可能なMNPの数を示します。
z=1 implies that a single MNP is available in the NEMO.
Z = 1は、NEMOで単一のMNPが利用可能であることを意味します。
z=N implies that multiple MNPs are available in the NEMO.
z = nは、複数のMNPがNEMOで利用可能であることを意味します。
It can be seen that the above three parameters are fairly orthogonal with one another. Thus, different values of 'x', 'y', and 'z' result in different combinations of the 3-tuple (x,y,z).
上記の3つのパラメーターは、互いにかなり直交していることがわかります。したがって、「x」、「y」、および「z」の異なる値は、3タプル（x、y、z）の異なる組み合わせをもたらします。
As will be described in the sub-sections below, a total of 8 possible configurations can be identified. One thing the reader has to keep in mind is that in each of the following 8 cases, the MR may be multihomed if either (i) multiple prefixes are available (on the home link, or on the foreign link), or (ii) the MR is equipped with multiple interfaces. In such a case, the MR would have multiple (HoA,CoA) pairs. Issues pertaining to a multihomed MR are also addressed in [7]. In addition, the readers should also keep in mind that when "MNP(s) is/are available in the NEMO", the MNP(s) may either be explicitly announced by the MR via router advertisement, or made available through Dynamic Host Configuration Protocol (DHCP) [8].
以下のサブセクションで説明するように、合計8つの可能な構成を識別できます。読者が留意しなければならないことの1つは、次の8つのケースのそれぞれで、（i）複数の接頭辞（ホームリンク、または外国リンクで）または（ii）のいずれかを使用できる場合、MRはマルチホームになる可能性があることです。MRには複数のインターフェイスが装備されています。そのような場合、MRには複数の（HOA、COA）ペアがあります。マルチホームのMRに関連する問題も[7]で対処されています。さらに、読者はまた、「MNPがNEMOで利用できる/利用可能である」場合、MNPがMR Bia Router Advertisementによって明示的に発表されるか、動的ホスト構成を介して利用可能になることを覚えておく必要があります。プロトコル（DHCP）[8]。
The (1,1,1) configuration has only one MR, it is associated with a single HA, and a single MNP is available in the NEMO. The MR and the AR are connected to the Internet via a single Access Router (AR). To fall into a multihomed configuration, at least one of the following conditions must hold:
（1,1,1）構成にはMRが1つしかなく、単一のHAに関連付けられており、NEMOで1つのMNPが利用可能です。MRとARは、単一のアクセスルーター（AR）を介してインターネットに接続されています。マルチホームの構成に分類するには、次の条件の少なくとも1つを保持する必要があります。
o The MR has multiple interfaces and thus it has multiple CoAs;
o MRには複数のインターフェイスがあるため、複数のCOAがあります。
o Multiple global prefixes are available on the foreign link, and thus it has multiple CoAs; or
o 複数のグローバルプレフィックスが外国リンクで利用可能であるため、複数のCOAがあります。また
o Multiple global prefixes are available on the home link, and thus the MR has more than one path to reach the HA.
o ホームリンクで複数のグローバルプレフィックスを使用できます。したがって、MRにはHAに到達するための複数のパスがあります。
Note that the case where multiple prefixes are available on the foreign link does not have any bearing on the MNPs. MNPs are independent of prefixes available on the link where the MR is attached to, thus prefixes available on the foreign link are not announced on the NEMO link. For the case where multiple prefixes are available on the home link, these are only announced on the NEMO link if the MR is configured to do so. In the present (1,1,1) configuration, only one MNP is announced.
外部リンクで複数の接頭辞が利用可能な場合は、MNPには関係がないことに注意してください。MNPは、MRが取り付けられているリンクで使用可能なプレフィックスから独立しているため、外部リンクで使用可能なプレフィックスはNEMOリンクで発表されていません。複数のプレフィックスがホームリンクで使用できる場合、これらはMRがそうするように構成されている場合にのみNEMOリンクで発表されます。現在（1,1,1）構成では、1つのMNPのみが発表されます。
A bi-directional tunnel would then be established between each (HoA,CoA) pair.
次に、それぞれ（HOA、COA）ペアの間に双方向トンネルが確立されます。
Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to.
MNNについては、添付されているリンクで使用可能な単一のMNPから単一のグローバルアドレスを構成するため、（通常）マルチホームではありません。
_____
_ p _ | |
|_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-|
|
MNNs MR AR Internet AR HA
Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP
図1：（1,1,1）：1 MR、1 HA、1 MNP
The (1,1,n) configuration has only one MR, it is associated with a single HA, and two or more MNPs are available in the NEMO.
（1,1、n）構成には1つのMRのみがあり、単一のHAに関連付けられており、NEMOで2つ以上のMNPが利用可能です。
The MR may itself be multihomed, as detailed in Section 2.1. In such a case, a bi-directional tunnel would be established between each (HoA,CoA) pair.
MRは、セクション2.1で詳述されているように、マルチホームである可能性があります。そのような場合、各（HOA、COA）ペアの間に双方向トンネルが確立されます。
Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address from each MNP available on the link.
MNNについては、添付されているリンクでいくつかのMNPが利用可能であるため、それらはマルチホームです。MNNSは、リンクで使用可能な各MNPからグローバルアドレスを構成します。
_____
_ p1,p2 _ | |
|_|-|<-_ |-|_|-| |-| _
_ |-|_|=| |_____| | _ |-|_|
|_|-| | |-|_|-|
|
MNNs MR AR Internet AR HA
Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs
図2：（1,1、n）：1 MR、1 HA、複数のMNP
The (1,n,1) configuration has only one MR and a single MNP is available in the NEMO. The MR, however, is associated with multiple HAs.
（1、n、1）構成には1つのMRが1つしかなく、NEMOで使用可能な単一のMNPがあります。ただし、MRは複数のHASに関連付けられています。
The NEMO is multihomed since it has multiple HAs, but in addition, the conditions detailed in Section 2.1 may also hold for the MR. A bi-directional tunnel would then be established between each (HoA,CoA) pair.
Nemoは複数のHasを持っているため、マルチホームですが、さらに、セクション2.1で詳述されている条件もMRについても保持される場合があります。次に、それぞれ（HOA、COA）ペアの間に双方向トンネルが確立されます。
Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to.
MNNについては、添付されているリンクで使用可能な単一のMNPから単一のグローバルアドレスを構成するため、（通常）マルチホームではありません。
AR HA2
_ |
|-|_|-| _
_____ | |-|_|
_ p _ | |-|
|_|-|<-_ |-|_|-| |
_ |-|_|=| |_____|-| _
|_|-| | | _ |-|_|
|-|_|-|
|
MNNs MR AR Internet AR HA1
Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP
図3：（1、n、1）：1 MR、倍数は、1 MNPを持っています
The (1,n,n) configuration has only one MR. However, the MR is associated with multiple HAs and more than one MNP is available in the NEMO.
（1、n、n）構成には、MRが1つしかありません。ただし、MRは複数のHASに関連付けられており、NEMOで複数のMNPが利用可能です。
The MR is multihomed since it has multiple HAs, but in addition, the conditions detailed in Section 2.1 may also hold. A bi-directional tunnel would then be established between each (HoA,CoA) pair.
MRは複数のHASがあるため、マルチホームですが、さらに、セクション2.1で詳述されている条件も保持される場合があります。次に、それぞれ（HOA、COA）ペアの間に双方向トンネルが確立されます。
Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address with each MNP available on the link.
MNNについては、添付されているリンクでいくつかのMNPが利用可能であるため、それらはマルチホームです。MNNSは、リンクで各MNPを使用できるグローバルアドレスを構成します。
AR HA2
_ | _
_____ |-|_|-|-|_|
_ p1,p2 _ | |-| |
|_|-|<-_ |-|_|-| | _
_ |-|_|=| |_____|-| _ |-|_|
|_|-| | |-|_|-|
| |
MNNs MR AR Internet AR HA1
Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs
図4：（1、n、n）：1 MR、倍数は、複数のMNPを持っています
The (n,1,1) configuration has more than one MR advertising global routes. However, the MR(s) are associated with a single HA, and there is a single MNP available in the NEMO.
（n、1,1）構成には、複数のMR Advertisingグローバルルートがあります。ただし、MRは単一のHAに関連付けられており、NEMOで利用可能な単一のMNPがあります。
The NEMO is multihomed since it has multiple MRs, but in addition the conditions detailed in Section 2.1 may also hold for each MR. A bi-directional tunnel would then be established between each (HoA,CoA) pair.
Nemoには複数のMRSがあるため、Nemoはマルチホームされていますが、さらに、セクション2.1で詳述されている条件もMRごとに保持される場合があります。次に、それぞれ（HOA、COA）ペアの間に双方向トンネルが確立されます。
Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to.
MNNについては、添付されているリンクで使用可能な単一のMNPから単一のグローバルアドレスを構成するため、（通常）マルチホームではありません。
MR2
p<-_ |
_ |-|_|-| _____
|_|-| |-| |
_ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
p<- | |
MNNs MR1 Internet AR HA
Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP
図5：（n、1,1）：複数のMRS、1 ha、1 mnp
The (n,1,n) configuration has more than one MR; multiple global routes are advertised by the MRs and multiple MNPs are available within the NEMO.
（n、1、n）構成には複数のMRがあります。MRSによって複数のグローバルルートが宣伝されており、NEMO内で複数のMNPが利用できます。
The NEMO is multihomed since it has multiple MRs, but in addition, the conditions detailed in Section 2.1 may also hold for each MR. A bi-directional tunnel would then be established between each (HoA,CoA) pair.
Nemoには複数のMRSがあるため、Nemoはマルチホームですが、さらに、セクション2.1で詳述されている条件もMRごとに保持される場合があります。次に、それぞれ（HOA、COA）ペアの間に双方向トンネルが確立されます。
Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address with each MNP available on the link.
MNNについては、添付されているリンクでいくつかのMNPが利用可能であるため、それらはマルチホームです。MNNSは、リンクで各MNPを使用できるグローバルアドレスを構成します。
MR2
p2<-_ |
_ |-|_|-| _____
|_|-| |-| |
_ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
p1<- | |
MNNs MR1 Internet AR HA
Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs
図6：（n、1、n）：複数のMRS、1 ha、複数のmnps
The (n,n,1) configuration has more than one MR advertising multiple global routes. The mobile network is simultaneously associated with multiple HAs and a single MNP is available in the NEMO.
（n、n、1）構成には、複数のグローバルルートが複数のMR広告を掲載しています。モバイルネットワークは複数のHASに同時に関連付けられており、NEMOで単一のMNPが利用可能です。
The NEMO is multihomed since it has multiple MRs and HAs, but in addition, the conditions detailed in Section 2.1 may also hold for each MR. A bi-directional tunnel would then be established between each (HoA,CoA) pair.
Nemoは複数のMRSを持ち、さらに、セクション2.1で詳述されている条件もMRごとに保持されるため、マルチホームです。次に、それぞれ（HOA、COA）ペアの間に双方向トンネルが確立されます。
Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to.
MNNについては、添付されているリンクで使用可能な単一のMNPから単一のグローバルアドレスを構成するため、（通常）マルチホームではありません。
MR2 AR HA2
p _ |
<-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_|
|_|-| |-| |-|
_ | | |
|_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_|
<- | |-|_|-|
p |
MNNs MR1 Internet AR HA1
Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP
図7：（n、n、1）：複数のMRS、倍数、1 MNP
The (n,n,n) configuration has multiple MRs advertising different global routes. The mobile network is simultaneously associated with more than one HA and multiple MNPs are available in the NEMO.
（n、n、n）構成には、さまざまなグローバルルートを宣伝する複数のMRSがあります。モバイルネットワークは同時に複数のHAに関連付けられており、NEMOで複数のMNPが利用可能です。
The NEMO is multihomed since it has multiple MRs and HAs, but in addition, the conditions detailed in Section 2.1 may also hold for each MR. A bi-directional tunnel would then be established between each (HoA,CoA) pair.
Nemoは複数のMRSを持ち、さらに、セクション2.1で詳述されている条件もMRごとに保持されるため、マルチホームです。次に、それぞれ（HOA、COA）ペアの間に双方向トンネルが確立されます。
Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address with each MNP available on the link.
MNNについては、添付されているリンクでいくつかのMNPが利用可能であるため、それらはマルチホームです。MNNSは、リンクで各MNPを使用できるグローバルアドレスを構成します。
MR2 AR HA2
p2 _ |
<-_ | |-|_|-| _
_ |-|_|-| _____ | |-|_|
|_|-| |-| |-|
_ | | |
|_|-| _ |-|_____|-| _
|-|_|-| | _ |-|_|
<- | |-|_|-|
p1 |
MNNs MR1 Internet AR HA1
Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs
図8：（n、n、n）：複数のMRS、has、およびmnps
The following generic goals and benefits of multihoming are discussed in [6]:
マルチホミングの次の一般的な目標と利点については、[6]で説明しています。
1. Permanent and Ubiquitous Access
1. 永続的でユビキタスなアクセス
2. Reliability
2. 信頼性
3. Load Sharing
3. 負荷共有
4. Load Balancing/Flow Distribution
4. バランス/フロー分布を積み込みます
5. Preference Settings
5. 設定設定
6. Aggregate Bandwidth
6. 集計帯域幅
These benefits are now illustrated from a NEMO perspective with a typical instance scenario for each case in the taxonomy. We then discuss the prerequisites to fulfill these.
これらの利点は、分類法の各ケースの典型的なインスタンスシナリオを備えたNEMOの観点から示されています。次に、これらを満たすために前提条件について説明します。
x=1: Multihomed mobile networks with a single MR
X = 1：単一のMRを備えたマルチホームモバイルネットワーク
o Example 1:
o 例1：
MR with dual/multiple access interfaces (e.g., 802.11 and GPRS capabilities). This is a (1,1,*) if a single HA is used for both. If two independent HAs are used, this is a (1,n,n) configuration.
MR Dual/Multiple Accessインターフェイス（802.11およびGPRS機能など）。これは、両方に単一のHAが使用される場合、（1,1、*）です。2つの独立したものが使用されている場合、これは（1、n、n）構成です。
Benefits: Ubiquitous Access, Reliability, Load Sharing, Preference Settings, Aggregate Bandwidth.
利点：ユビキタスアクセス、信頼性、負荷共有、好みの設定、集計帯域幅。
x=n: Multihomed mobile networks with multiple MRs
x = n：複数のMRSを持つマルチホームモバイルネットワーク
o Example 1:
o 例1：
Train with one MR in each car, all served by the same HA, thus a (n,1,*) configuration. Alternatively, the train company might use different HAs, in different countries, thus a (n,n,n) configuration.
各車に1つのMRと一緒にトレーニングします。すべて同じHAで提供されるため、（n、1、*）構成。あるいは、列車会社は、異なる国で異なる国を使用している場合があります。
Benefits: Ubiquitous Access, Reliability, Load Sharing, Aggregate Bandwidth.
利点：ユビキタスアクセス、信頼性、負荷共有、集約帯域幅。
o Example 2:
o 例2：
Wireless personal area network with a GPRS-enabled phone and a WiFi-enabled PDA. This is a (n,n,n) configuration if different HAs are also used.
GPRS対応の電話とWiFi対応PDAを備えたワイヤレスパーソナルエリアネットワーク。これは、異なる場合も（n、n、n）構成です。
Benefits: Ubiquitous Access, Reliability, Preference Settings, Aggregate Bandwidth.
利点：ユビキタスアクセス、信頼性、優先設定、集約帯域幅。
y=1: Multihomed mobile networks with a single HA
y = 1：単一のhaのマルチホームモバイルネットワーク
o Example:
o 例：
Most single HA cases in above examples.
上記の例では、ほとんどの単一HAケース。
y=n: Multihomed mobile networks with multiple HAs
y = n：複数のマルチホームモバイルネットワークがあります
o Example 1:
o 例1：
Most multiple HAs cases in above examples.
ほとんどの複数は、上記の例でケースがあります。
o Example 2:
o 例2：
Transatlantic flight with a HA in each continent. This is a (1,n,1) configuration if there is only one MR.
各大陸にHAを備えた大西洋横断飛行。これは、MRが1つしかない場合、（1、n、1）構成です。
Benefits: Ubiquitous Access, Reliability, Preference Settings (reduced delay, shortest path).
利点：ユビキタスアクセス、信頼性、優先設定（遅延の減少、最短パス）。
z=1: Multihomed mobile networks with a single MNP
Z = 1：単一のMNPを備えたマルチホームモバイルネットワーク
o Example:
o 例：
Most single HA cases in above examples.
上記の例では、ほとんどの単一HAケース。
z=n: Multihomed mobile networks with multiple MNPs
z = n：複数のMNPを備えたマルチホームモバイルネットワーク
o Example 1:
o 例1：
Most multiple HAs cases in above examples.
ほとんどの複数は、上記の例でケースがあります。
o Example 2:
o 例2：
Car with a prefix taken from home (personal traffic is transmitted using this prefix and is paid by the owner) and one that belongs to the car manufacturer (maintenance traffic is paid by the car manufacturer). This will typically be a (1,1,n) or a (1,n,n,) configuration.
自宅から撮影した接頭辞を備えた車（個人のトラフィックはこのプレフィックスを使用して送信され、所有者によって支払われます）と自動車メーカーに属するもの（メンテナンストラフィックは自動車メーカーによって支払われます）。これは通常、a（1,1、n）またはa（1、n、n、）構成になります。
Benefits: Preference Settings
利点：設定設定
In this section, requirements are stated in order to comply with the expected benefits of multihoming as detailed in [6].
このセクションでは、[6]で詳述されているように、マルチホミングの予想される利点を遵守するために要件を記載しています。
At least one bi-directional tunnel must be available at any point in time between the mobile network and the fixed network to meet all expectations. But for most goals to be effective, multiple tunnels must be maintained simultaneously:
すべての期待を満たすには、モバイルネットワークと固定ネットワークの間の任意の時点で、少なくとも1つの双方向トンネルを利用できる必要があります。しかし、ほとんどの目標が効果的であるためには、複数のトンネルを同時に維持する必要があります。
o Permanent and Ubiquitous Access:
o 永続的でユビキタスなアクセス：
At least one bi-directional tunnel must be available at any point in time.
少なくとも1つの双方向トンネルは、いつでも利用できる必要があります。
o Reliability:
o 信頼性：
Both the inbound and outbound traffic must be transmitted or diverted over another bi-directional tunnel once a bi-directional tunnel is broken or disrupted. It should be noted that the provision of fault tolerance capabilities does not necessarily require the existence of multiple bi-directional tunnels simultaneously.
インバウンドトラフィックとアウトバウンドトラフィックの両方を、双方向トンネルが破損または破壊されると、別の双方向トンネルに送信または迂回する必要があります。断層許容能力の提供は、必ずしも複数の双方向トンネルの存在を同時に必要としないことに注意する必要があります。
o Load Sharing and Load Balancing:
o 負荷共有とロードバランシング：
Multiple tunnels must be maintained simultaneously.
複数のトンネルを同時に維持する必要があります。
o Preference Settings:
o
Implicitly, multiple tunnels must be maintained simultaneously if preferences are set for deciding which of the available bi-directional tunnels should be used. To allow user/application to set the preference, a mechanism should be provided to the user/ application for the notification of the availability of multiple bi-directional tunnels, and perhaps also to set preferences. A similar mechanism should also be provided to network administrators to manage preferences.
暗黙的に、利用可能な双方向トンネルのどれを使用するかを決定するために設定が設定されている場合、複数のトンネルを同時に維持する必要があります。ユーザー/アプリケーションが優先権を設定できるようにするには、複数の双方向トンネルの可用性を通知するために、およびおそらく設定を設定するために、ユーザー/アプリケーションにメカニズムを提供する必要があります。好みを管理するために、ネットワーク管理者にも同様のメカニズムを提供する必要があります。
o Aggregate Bandwidth:
o 集計帯域幅：
Multiple tunnels must be maintained simultaneously in order to increase the total aggregated bandwidth available to the mobile network.
モバイルネットワークで利用可能な総帯域幅を増やすために、複数のトンネルを同時に維持する必要があります。
As discussed in the previous section, multiple bi-directional tunnels need to be maintained either sequentially (e.g., for fault tolerance) or simultaneously (e.g., for load sharing).
前のセクションで説明したように、複数の双方向トンネルは、連続的に（断層トレランスなど）または同時に（荷重共有の場合）、同時に維持する必要があります。
In some cases, it may be necessary to divert packets from a (perhaps failed) bi-directional tunnel to an alternative (perhaps newly established) bi-directional tunnel (i.e., for matters of fault recovery, preferences), or to split traffic between multiple tunnels (load sharing, load balancing).
場合によっては、パケットを（おそらく失敗した）双方向トンネルから代替の（おそらく新しく確立された）双方向トンネル（つまり、障害回復の問題、好みの問題）、またはトラフィックを分割する必要がある場合があります。複数のトンネル（負荷共有、負荷分散）。
So, depending on the configuration under consideration, the issues discussed below may need to be addressed sometimes dynamically. For each issue, potential ways to solve the problem are investigated.
したがって、検討中の構成に応じて、以下で説明する問題に動的に対処する必要がある場合があります。各問題について、問題を解決する潜在的な方法が調査されます。
One of the goals of multihoming is the provision of fault tolerance capabilities. In order to provide such features, a set of tasks need to be performed, including: failure detection, alternative available path exploration, path selection, and re-homing of established communications. These are also discussed in [9] by the Shim6 WG. In the following sub-sections, we look at these issues in the specific context of NEMO, rather than the general Shim6 perspective in [9]. In addition, in some scenarios, it may also be required to provide the mechanisms for coordination between different HAs (see Section 4.3) and also the coordination between different MRs (see Section 4.4).
マルチホミングの目標の1つは、フォールトトレランス機能の提供です。このような機能を提供するには、障害検出、代替の利用可能なパス探索、パス選択、確立された通信の再ホーミングなど、一連のタスクを実行する必要があります。これらについては、[9]でSHIM6 WGによって説明されています。次のサブセクションでは、[9]の一般的なSHIM6の視点ではなく、NEMOの特定のコンテキストでこれらの問題を検討します。さらに、いくつかのシナリオでは、異なるHAS（セクション4.3を参照）と異なるMRの調整（セクション4.4を参照）の間の調整のメカニズムを提供する必要がある場合があります。
It is expected for faults to occur more readily at the edge of the network (i.e., the mobile nodes) due to the use of wireless connections. Efficient fault detection mechanisms are necessary to recover in timely fashion.
ワイヤレス接続の使用により、ネットワークの端（つまり、モバイルノード）で障害がより容易に発生することが予想されます。タイムリーに回復するには、効率的な障害検出メカニズムが必要です。
Depending on the NEMO configuration considered, the failure protection domain greatly varies. In some configurations, the protection domain provided by NEMO multihoming is limited to the links between the MR(s) and the HA(s). In other configurations, the protection domain allows to recover from failures in other parts of the path, so an end-to-end failure detection mechanism is required.
考慮されるNEMO構成に応じて、障害保護ドメインは大きく異なります。一部の構成では、Nemo Multihomingによって提供される保護ドメインは、MR（S）とHA（S）の間のリンクに限定されています。他の構成では、保護ドメインにより、パスの他の部分の障害から回復できるため、エンドツーエンドの故障検出メカニズムが必要です。
The failure detection capabilities required for each configuration are detailed below:
各構成に必要な障害検出機能については、以下に詳しく説明します。
o For the (1,1,*) cases, multiple paths are available between a single MR and a single HA. All the traffic to and from the NEMO flows through the MR and HA. Failure detection mechanisms need only to be executed between these two devices. This is a NEMO-/ MIPv6-specific issue.
o （1,1、*）の場合、単一のMRと単一のHAの間で複数のパスが使用できます。ネモとの間のすべてのトラフィックは、MRとHAを流れます。障害検出メカニズムは、これら2つのデバイス間で実行するだけです。これはNEMO-/ MIPV6固有の問題です。
o For the (n,1,*) cases, there is a single HA, so all the traffic to and from the NEMO will flow through it. The failure detection mechanisms need to be able to detect failure in the path between the used MR and the only HA. Hence, the failure detection mechanism needs only to involve the HA and the MRs. This is a NEMO/MIPv6 specific issue.
o （n、1、*）の場合、単一のHAがあります。したがって、Nemoとの間のすべてのトラフィックがそれを通過します。障害検出メカニズムは、使用済みのMRと唯一のHAの間のパスの障害を検出できる必要があります。したがって、故障検出メカニズムは、HAとMRSに関与するだけで済みます。これは、NEMO/MIPV6固有の問題です。
o For the (n,n,*) cases, there are multiple paths between the different HAs and the different MRs. Moreover, the HAs may be located in different networks, and have different Internet access links. This implies that changing the HA used may not only allow recovering from failures in the link between the HA and the MR, but also from other failure modes, affecting other parts of the path. In this case, an end-to-end failure detection mechanism would provide additional protection. However, a higher number of failures is likely to occur in the link between the HA and the MR, so it may be reasonable to provide optimized failure detection mechanisms for this failure mode. The (n,n,n) case is hybrid, since selecting a different prefix results in a change of path. For this case, the Shim6 protocols (such as those discussed in [9]) may be useful.
o （n、n、*）の場合、異なるHASと異なるMRSの間に複数のパスがあります。さらに、HASは異なるネットワークに配置され、異なるインターネットアクセスリンクがある場合があります。これは、使用されるHAを変更すると、HAとMRの間のリンクの障害から回復するだけでなく、パスの他の部分に影響を与える他の障害モードからも回復することができることを意味します。この場合、エンドツーエンドの故障検出メカニズムが追加の保護を提供します。ただし、HAとMRの間のリンクでより多くの障害が発生する可能性が高いため、この障害モードに最適化された障害検出メカニズムを提供することが合理的かもしれません。（n、n、n）ケースはハイブリッドです。これは、異なるプレフィックスを選択すると、パスの変更が発生するためです。この場合、SHIM6プロトコル（[9]で説明したものなど）が役立つ場合があります。
Most of the above cases involve the detection of tunnel failures between HA(s) and MR(s). This is no different from the case of failure detection between a mobile host and its HA(s). As such, a solution for MIPv6 should apply to NEMO as well. For case (n,*,*), an MR synchronization solution (see Section 4.4) should be able to complement a MIPv6 failure detection solution to achieve the desired functionality for NEMO.
上記のケースのほとんどは、HA（S）とMRの間のトンネル障害の検出を伴います。これは、モバイルホストとそのHA（S）の間の障害検出の場合と違いはありません。そのため、MIPV6のソリューションもNEMOに適用する必要があります。ケース（n、*、*）の場合、MR同期ソリューション（セクション4.4を参照）は、NEMOの望ましい機能を実現するためにMIPV6障害検出ソリューションを補完できるはずです。
In order for fault recovery to work, the MRs and HAs must first possess a means to detect failures:
障害回復が機能するためには、MRSと持っている人は、まず障害を検出する手段を持たなければなりません。
o On the MR's side, the MR can rely on router advertisements from access routers, or other layer-2 trigger mechanisms to detect faults, e.g., [10] and [11].
o MRの側では、MRはアクセスルーターまたはその他のレイヤー-2トリガーメカニズムからのルーター広告に依存して、断層を検出します[10]および[11]。
o On the HA's side, it is more difficult to detect tunnel failures. For an ISP deployment model, the HAs and MRs can use proprietary methods (such as constant transmission of heartbeat signals) to detect failures and check tunnel liveness. In the subscriber model (see Appendix A.2: S/P model), a lack of standardized "tunnel liveness" protocol means that it is harder to detect failures.
o HAの側では、トンネルの故障を検出することがより困難です。ISP展開モデルの場合、HASおよびMRSは独自の方法（ハートビート信号の一定の伝達など）を使用して障害を検出し、トンネルのlivenivesを確認できます。サブスクライバーモデル（付録A.2：S/Pモデルを参照）では、標準化された「トンネルライベン」プロトコルの欠如は、障害を検出するのが難しいことを意味します。
A possible method is for the MRs to send binding updates more regularly with shorter Lifetime values. Similarly, HAs can return binding acknowledgment messages with smaller Lifetime values, thus forcing the MRs to send binding updates more frequently. These binding updates can be used to emulate "tunnel heartbeats". This, however, may lead to more traffic and processing overhead, since binding updates sent to HAs must be protected (and possibly encrypted) with security associations.
考えられる方法は、MRSがより短い寿命の値でより定期的にバインディングアップデートを送信することです。同様に、寿命の値が小さい拘束力のある確認メッセージを返すことができるため、MRSにバインディングの更新をより頻繁に送信することを余儀なくされます。これらのバインディングの更新は、「トンネルハートビート」をエミュレートするために使用できます。ただし、これは、送信された拘束力のある更新をセキュリティ関連で保護する（そしておそらく暗号化された）ため、トラフィックと処理のオーバーヘッドを増やす可能性があります。
Once a failure in the currently used path is detected, alternative paths have to be explored in order to identify an available one. This process is closely related to failure detection in the sense that paths being explored need to be alternative paths to the one that has failed. There are, however, subtle but significant differences between path exploration and failure detection. Failure detection occurs on the currently used path while path exploration occurs on the alternative paths (not on the one currently being used for exchanging packets). Although both path exploration and failure detection are likely to rely on a reachability or keepalive test exchange, failure detection also relies on other information, such as upper layer information (e.g., positive or negative feedback from TCP), lower layer information (e.g., an interface is down), and network layer information (e.g., as an address being deprecated or ICMP error message).
現在使用されているパスで障害が検出されると、利用可能なパスを識別するために代替パスを調査する必要があります。このプロセスは、探索されるパスが失敗したパスへの代替パスである必要があるという意味での障害検出に密接に関連しています。ただし、パス探索と障害検出の間には、微妙だが大きな違いがあります。故障検出は現在使用されているパスで発生し、パス探索は代替パスで発生します（現在パケットの交換に使用されているものではありません）。パスの調査と故障検出の両方が到達可能性またはキープライブテスト交換に依存する可能性が高いが、障害検出は、上層情報（たとえば、TCPからの肯定的または負のフィードバック）などの他の情報にも依存しているが、下層情報（例えば、インターフェイスがダウンしています）、およびネットワークレイヤー情報（たとえば、アドレスが非推奨またはICMPエラーメッセージとして）。
Basically, the same cases as in the analysis of the failure detection (Section 4.1.1) issue are identified:
基本的に、障害検出（セクション4.1.1）の問題の分析と同じケースが特定されています。
o For the (1,1,*) cases, multiple paths are available between a single MR and a single HA. The existing paths between the HA and the MR have to be explored to identify an available one. The mechanism involves only the HA and the MR. This is a NEMO-/ MIPv6-specific issue.
o （1,1、*）の場合、単一のMRと単一のHAの間で複数のパスが使用できます。HAとMRの間の既存のパスを調査して、利用可能なパスを特定する必要があります。メカニズムには、HAとMRのみが含まれます。これはNEMO-/ MIPV6固有の問題です。
o For the (n,1,*) cases, there is a single HA, so all the traffic to and from the NEMO will flow through it. The available alternative paths are the different ones between the different MRs and the HA. The path-exploration mechanism only involves the HA and the MRs. This is a NEMO/MIPv6 specific issue.
o （n、1、*）の場合、単一のHAがあります。したがって、Nemoとの間のすべてのトラフィックがそれを通過します。利用可能な代替パスは、異なるMRSとHAの間の異なるパスです。パス探索メカニズムには、HAとMRSのみが関与します。これは、NEMO/MIPV6固有の問題です。
o For the (n,n,*) cases, there are multiple paths between the different HAs and the different MRs. In this case, alternative paths may be routed completely independent from one another. An end-to-end path-exploration mechanism would be able to discover if any of the end-to-end paths is available. The (n,n,1) case, however, seems to be pretty NEMO specific, because of the absence of multiple prefixes. The (n,n,n) case is hybrid, since selecting a different prefix results in a change of path. For this case, the Shim6 protocols (such as those discussed in [9]) may be useful.
o （n、n、*）の場合、異なるHASと異なるMRSの間に複数のパスがあります。この場合、代替パスは互いに完全に独立してルーティングされる場合があります。エンドツーエンドのパス探索メカニズムは、エンドツーエンドパスのいずれかが利用可能かどうかを発見できます。ただし、（n、n、1）ケースは、複数の接頭辞がないため、かなりネモ固有のようです。（n、n、n）ケースはハイブリッドです。これは、異なるプレフィックスを選択すると、パスの変更が発生するためです。この場合、SHIM6プロトコル（[9]で説明したものなど）が役立つ場合があります。
Most of the above cases involve the path exploration of tunnels between HA(s) and MR(s). This is no different from the case of path exploration between a mobile host and its HA(s). As such, a solution for MIPv6 should apply to NEMO as well. For case (n,*,*), an MR synchronization solution (see Section 4.4) should be able to complement an MIPv6 path-exploration solution to achieve the desired functionality for NEMO.
上記のケースのほとんどは、HA（S）とMR（S）の間のトンネルの経路探索を含んでいます。これは、モバイルホストとそのHA（s）の間のパス探索の場合と違いはありません。そのため、MIPV6のソリューションもNEMOに適用する必要があります。ケース（n、*、*）の場合、MR同期ソリューション（セクション4.4を参照）は、NEMOの望ましい機能を実現するために、MIPV6パスエクスポレーションソリューションを補完できる必要があります。
In order to perform path exploration, it is sometimes also necessary for the MR to detect the availability of network media. This may be achieved using layer 2 triggers [10], or other mechanism developed/ recommended by the Detecting Network Attachment (DNA) Working Group [11]. This is related to Section 4.1.1, since the ability to detect media availability would often imply the ability to detect media unavailability.
パス探索を実行するためには、MRがネットワークメディアの可用性を検出するためにも必要です。これは、レイヤー2トリガー[10]、または検出ネットワークアタッチメント（DNA）ワーキンググループ[11]によって開発/推奨される他のメカニズムを使用して達成できます。これはセクション4.1.1に関連しています。これは、メディアの可用性を検出する能力は、多くの場合、メディアの利用不能を検出する能力を意味するためです。
A path-selection mechanism is required to select among the multiple available paths. Depending on the NEMO multihoming configuration involved, the differences between the paths may affect only the part between the HA and the MR, or they may affect the full end-to-end path. In addition, depending on the configuration, path selection may be performed by the HA(s), the MR(s), or the hosts themselves through address selection, as will be described in detail next.
複数の使用可能なパスを選択するには、パス選択メカニズムが必要です。関連するNemoマルチホーム構成に応じて、パス間の違いは、HAとMRの間の部分のみに影響する場合があります。または、エンドツーエンドの完全なパスに影響を与える可能性があります。さらに、構成によっては、次に詳細に説明されるように、HA（s）、MR（s）、またはアドレス選択を通じてホストによってパス選択を実行できます。
The multiple available paths may differ on the tunnel between the MR and the HA used to carry traffic to/from the NEMO. In this case, path selection is performed by the MR and the intra-NEMO routing system for traffic flowing from the NEMO, and path selection is performed by the HA and intra-Home Network routing system for traffic flowing to the NEMO.
複数の利用可能なパスは、NEMOとの間の交通を運ぶために使用されるMRとHAの間のトンネルで異なる場合があります。この場合、PATH選択は、NEMOから流れるトラフィックのためのMRおよびNEMOルーティングシステムによって実行され、PATH選択は、NEMOに流れるトラフィックのためにHAおよび在宅ネットワークルーティングシステムによって実行されます。
Alternatively, the multiple paths available may differ in more than just the tunnel between the MR and the HA, since the usage of different prefixes may result in using different providers; hence, in completely different paths between the involved endpoints. In this case, besides the mechanisms presented in the previous case, additional mechanisms for the end-to-end path selection may be needed. This mechanism may be closely related to source address selection mechanisms within the hosts, since selecting a given address implies selecting a given prefix, which is associated with a given ISP serving one of the home networks.
あるいは、さまざまな接頭辞を使用すると異なるプロバイダーを使用する可能性があるため、利用可能な複数のパスはMRとHAの間のトンネルだけでは異なる場合があります。したがって、関係するエンドポイント間のまったく異なるパスで。この場合、前のケースで提示されたメカニズムに加えて、エンドツーエンドパス選択の追加メカニズムが必要になる場合があります。このメカニズムは、特定のアドレスを選択すると、特定のプレフィックスを選択することを意味するため、ホストのソースアドレス選択メカニズムに密接に関連している可能性があります。
A dynamic path-selection mechanism is thus needed so that this path could be selected by:
したがって、このパスを以下で選択できるように、動的なパス選択メカニズムが必要です。
o The HA: it should be able to select the path based on some information recorded in the binding cache.
o HA：バインディングキャッシュに記録された情報に基づいてパスを選択できるはずです。
o The MR: it should be able to select the path based on router advertisements received on both its egress interfaces or on its ingress interfaces for the (n,*,*) case.
o MR：出力インターフェイスの両方で受信したルーター広告または（n、*、*）ケースの侵入インターフェイスの両方に基づいてパスを選択できるはずです。
o The MNN: it should be able to select the path based on "Default Router Selection" (see [Section 6.3.6 Default Router Selection] [12]) in the (n,*,*) case or based on "Source Address Selection" in the (*,*,n) cases (see Section 4.7 of the present memo).
o MNN：（デフォルトルーターの選択」に基づいてパスを選択できるはずです（n、*、*、*、*、*、*、*、*、*、*、*）の場合、または「ソースアドレスの選択に基づいて）「（*、*、n）の場合（現在のメモのセクション4.7を参照）。
o The user or the application: e.g., in case where a user wants to select a particular access technology among the available technologies for reasons, e.g., of cost or data rate.
o ユーザーまたはアプリケーション：たとえば、ユーザーが利用可能なテクノロジーから特定のアクセステクノロジーを選択したい場合、理由やデータレートなど。
o A combination of any of the above: a hybrid mechanism should be also available, e.g., one in which the HA, the MR, and/or the MNNs are coordinated to select the path.
o 上記のいずれかの組み合わせ：ハイブリッドメカニズムも利用できる必要があります。たとえば、HA、MR、および/またはMNNを調整してパスを選択するために調整されます。
When multiple bi-directional tunnels are available and possibly used simultaneously, the mode of operation may be either primary-secondary (one tunnel is precedent over the others and used as the default tunnel, while the other serves as a backup) or peer-to-peer (no tunnel has precedence over one another, they are used with the same priority). This questions which of the bi-directional tunnels would be selected, and based on which of the parameters (e.g., type of flow that goes into/out of the mobile network).
複数の双方向トンネルが利用可能であり、同時に使用される場合、動作モードはプライマリセコン（1つのトンネルが他のトンネルよりも先例であり、デフォルトのトンネルとして使用され、もう1つはバックアップとして機能します）またはピアツーのいずれかです。-peer（トンネルは互いに優先されず、同じ優先事項で使用されます）。これは、どのパラメーター（モバイルネットワークに出入りするフローの種類）に基づいて、双方向トンネルのどれが選択されるかを疑問視します。
The mechanisms for the selection among the different tunnels between the MR(s) and the HA(s) seem to be quite NEMO/MIPv6 specific.
MR（S）とHA（S）の間の異なるトンネル間の選択のメカニズムは、非常にNEMO/MIPV6固有のようです。
For (1,*,*) cases, they are no different from the case of path selection between a mobile host and its HA(s). As such, a solution for MIPv6 should apply to NEMO as well. For the (n,*,*) cases, an MR synchronization solution (see Section 4.4) should be able to complement an MIPv6 path-selection solution to achieve the desired functionality for NEMO.
（1、*、*）の場合、モバイルホストとそのHAの間のパス選択の場合と違いはありません。そのため、MIPV6のソリューションもNEMOに適用する必要があります。（n、*、*）の場合、MR同期ソリューション（セクション4.4を参照）は、NEMOの望ましい機能を達成するためにMIPV6パス選択ソリューションを補完することができるはずです。
The mechanisms for selecting among different end-to-end paths based on address selection are similar to the ones used in other multihoming scenarios, as those considered by Shim6 (e.g., [13]).
アドレス選択に基づいて異なるエンドツーエンドパスを選択するためのメカニズムは、SHIM6（例えば[13]）で考慮されているものと同様に、他のマルチホームシナリオで使用されているシナリオと類似しています。
After an outage has been detected and an available alternative path has been identified, a re-homing event takes place, diverting the existing communications from one path to the other. Similar to the previous items involved in this process, the re-homing procedure heavily varies depending on the NEMO multihoming configuration.
停止が検出され、利用可能な代替パスが特定された後、既存の通信をあるパスから別のパスに迂回させて、再ホミングイベントが行われます。このプロセスに関係した以前のアイテムと同様に、再ホーミング手順は、Nemoマルチホーム構成によって大きく異なります。
o For the (*,*,1) configurations, the re-homing procedure involves only the MR(s) and the HA(s). The re-homing procedure may involve the exchange of additional BU messages. These mechanisms are shared between NEMO Basic Support and MIPv6.
o （*、*、1）構成の場合、再ホーミング手順にはMR（s）とHA（s）のみが含まれます。再ホーミング手順には、追加のブーメッセージの交換が含まれる場合があります。これらのメカニズムは、Nemo Basic SupportとMipv6の間で共有されます。
o For the (*,*,n) cases, in addition to the previous mechanisms, end-to-end mechanisms may be required. Such mechanisms may involve some form of end-to-end signaling or may simply rely on using different addresses for the communication. The involved mechanisms may be similar to those required for re-homing Shim6 communications (e.g., [13]).
o （*、*、n）の場合、以前のメカニズムに加えて、エンドツーエンドのメカニズムが必要になる場合があります。このようなメカニズムには、何らかの形のエンドツーエンドのシグナル伝達が含まれる場合があるか、単に通信に異なるアドレスを使用することに依存する場合があります。関係するメカニズムは、再ホーミングSHIM6通信に必要なメカニズムと類似している可能性があります（例[13]）。
Ingress filtering mechanisms [14][15] may drop the outgoing packets when multiple bi-directional tunnels end up at different HAs. This could particularly occur if different MNPs are handled by different HAs. If a packet with a source address configured from a specific MNP is tunneled to a HA that does not handle that specific MNP, the packet may be discarded either by the HA or by a border router in the home network.
イングレスフィルタリングメカニズム[14] [15]は、複数の双方向トンネルが異なるHASで終わると、発信パケットをドロップする可能性があります。これは、異なるMNPが異なるHASによって処理される場合に特に発生する可能性があります。特定のMNPから構成されたソースアドレスを備えたパケットが、特定のMNPを処理しないHAにトンネル化されている場合、パケットはHAまたはホームネットワークのボーダールーターのいずれかによって破棄される場合があります。
The ingress filtering compatibility issue is heavily dependent on the particular NEMO multihoming configuration:
Ingressフィルタリングの互換性の問題は、特定のNemoマルチホーム構成に大きく依存しています。
o For the (*,*,1) cases, there is not such an issue, since there is a single MNP.
o （*、*、1）の場合、単一のMNPがあるため、そのような問題はありません。
o For the (1,1,*) and (n,1,1) cases, there is not such a problem, since there is a single HA, accepting all the MNPs.
o （1,1、*）および（n、1,1）の場合、すべてのMNPを受け入れる単一のHAがあるため、そのような問題はありません。
o For the (n,1,n) case, though ingress filtering would not occur at the HA, it may occur at the MRs, when each MR is handling different MNPs.
o （n、1、n）の場合、侵入フィルタリングはHAでは発生しませんが、各MRが異なるMNPを処理している場合にMRSで発生する可能性があります。
o (*,n,n) are the cases where the ingress filtering presents some difficulties. In the (1,n,n) case, the problem is simplified because all the traffic to and from the NEMO is routed through a single MR. Such configuration allows the MR to properly route packets respecting the constraints imposed by ingress filtering. In this case, the single MR may face ingress filtering problems that a multihomed mobile node may face, as documented in [7]. The more complex case is the (n,n,n) case. A simplified case occurs when all the prefixes are accepted by all the HAs, so that no problems occur with the ingress filtering. However, this cannot be always assumed, resulting in the problem described below.
o （*、n、n）は、侵入フィルタリングがいくつかの困難をもたらす場合です。（1、n、n）の場合、Nemoとの間のすべてのトラフィックが単一のMRを介してルーティングされるため、問題は簡素化されます。このような構成により、MRは、イングレスフィルタリングによって課される制約を尊重するパケットを適切にルーティングできます。この場合、単一のMRは、[7]で文書化されているように、マルチホームのモバイルノードが直面する可能性のある侵入フィルタリングの問題に直面します。より複雑なケースは（n、n、n）ケースです。すべての接頭辞がすべてのHASによって受け入れられている場合、単純化されたケースが発生するため、侵入フィルタリングで問題は発生しません。ただし、これは常に想定することはできず、以下で説明する問題が発生します。
As an example of how this could happen, consider the deployment scenario illustrated in Figure 9: the mobile network has two mobile routers MR1 and MR2, with home agents HA1 and HA2, respectively. Two bi-directional tunnels are established between the two pairs. Each MR advertises a different MNP (P1 and P2 respectively). MNP P1 is registered to HA1, and MNP P2 is registered to HA2. Thus, MNNs should be free to auto-configure their addresses on any of P1 or P2. Ingress filtering could thus happen in two cases:
これがどのように発生するかの例として、図9に示す展開シナリオを考慮してください。モバイルネットワークには、ホームエージェントHA1とHA2を備えた2つのモバイルルーターMR1とMR2があります。2つのペアの間に2つの双方向トンネルが確立されています。各MRは、異なるMNP（それぞれP1とP2）を宣伝しています。MNP P1はHA1に登録され、MNP P2はHA2に登録されています。したがって、MNNは、P1またはP2のいずれかでアドレスを自動構成できるようにする必要があります。したがって、イングレスフィルタリングは2つの場合に発生する可能性があります。
o If the two tunnels are available, MNN cannot forward packet with source address equals P1.MNN to MR2. This would cause ingress filtering at HA2 to occur (or even at MR2). This is contrary to normal Neighbor Discovery [12] practice that an IPv6 node is free to choose any router as its default router regardless of the prefix it chooses to use.
o 2つのトンネルが利用可能な場合、MNNはソースアドレスでパケットを転送できません。これにより、HA2でのイングレスフィルタリングが発生します（またはMR2でも）。これは、IPv6ノードが使用することを選択した接頭辞に関係なく、IPv6ノードがデフォルトルーターとして任意のルーターを自由に選択できるという通常の隣接発見[12]の慣行に反します。
o If the tunnel to HA1 is broken, packets that would normally be sent through the tunnel to HA1 should be diverted through the tunnel to HA2. If HA2 (or some border router in HA2's domain) performs ingress filtering, packets with source address configured from MNP P1 may be discarded.
o HA1へのトンネルが壊れている場合、通常トンネルを介してHA1に送信されるパケットは、トンネルを介してHA2に転用する必要があります。HA2（またはHA2のドメインの一部のボーダールーター）がイングレスフィルタリングを実行すると、MNP P1から構成されたソースアドレスを備えたパケットが破棄される場合があります。
Prefix: P1 +-----+ +----+ +----------+ +-----+
+--| MR1 |--| AR |--| |---| HA1 |
| +-----+ +----+ | | +-----+
IP: +-----+ | | | Prefix: P1
P1.MNN or | MNN |--+ | Internet |
P2.MNN +-----+ | | | Prefix: P2
| +-----+ +----+ | | +-----+
+--| MR2 |--| AR |--| |---| HA2 |
Prefix: P2 +-----+ +----+ +----------+ +-----+
Figure 9: An (n,n,n) mobile network
図9：（n、n、n）モバイルネットワーク
Possible solutions to the ingress filtering incompatibility problem may be based on the following approaches:
イングレスフィルタリングの非互換性の問題の可能な解決策は、次のアプローチに基づいている可能性があります。
o Some form of source address-dependent routing, whether host-based and/or router-based where the prefix contained in the source address of the packet is considered when deciding which exit router to use when forwarding the packet.
o パケットのソースアドレスに含まれるプレフィックスがパケットを転送する際に使用する出口ルーターを決定するときに、ホストベースおよび/またはルーターベースの場合、何らかの形のソースアドレス依存ルーティング。
o The usage of nested tunnels for (*,n,n) cases. Appendix B describes one such approach.
o （*、n、n）ケースのネストされたトンネルの使用。付録Bでは、そのようなアプローチの1つについて説明しています。
o Deprecating those prefixes associated to non-available exit routers.
o 利用できない出口ルーターに関連付けられたこれらのプレフィックスを非難します。
The ingress filtering incompatibilities problems that appear in some NEMO multihoming configurations are similar to those considered in Shim6 (e.g., see [16]).
いくつかのNemoマルチホーム構成に表示されるイングレスフィルタリングの非互換性の問題は、SHIM6で考慮されるものと類似しています（例：[16]を参照）。
In the (*,n,*) configuration, a single MNP would be registered at different HAs. This gives rise to the following cases:
（*、n、*）構成では、単一のMNPが異なるHASで登録されます。これにより、次のケースが生じます。
o Only one HA may actively advertise a route to the MNP,
o MNPへのルートを積極的に宣伝できるのは1つだけです。
o Multiple HAs at different domains may advertise a route to the same MNP.
o 複数のドメインには、同じMNPへのルートを宣伝する場合があります。
This may pose a problem in the routing infrastructure as a whole if the HAs are located in different administrative domains. The implications of this aspect needs further exploration. A certain level of HA coordination may be required. A possible approach is to adopt an HA synchronization mechanism such as that described in [17] and [18]. Such synchronization might also be necessary in a (*,n,*) configuration, when an MR sends binding update messages to only one HA (instead of all HAs). In such cases, the binding update information might have to be synchronized between HAs. The mode of synchronization may be either primary-secondary or peer-to-peer. In addition, when a MNP is delegated to the MR (see Section 4.5), some level of coordination between the HAs may also be necessary.
これは、異なる管理ドメインにある場合、ルーティングインフラストラクチャ全体に問題をもたらす可能性があります。この側面の意味は、さらなる調査が必要です。一定レベルのHA調整が必要になる場合があります。考えられるアプローチは、[17]および[18]に記載されているようなHA同期メカニズムを採用することです。このような同期は、MRがバインディングアップデートメッセージを1つのHAのみに送信する場合、（*、n、*）構成でも必要になる場合があります（すべてのHAではなく）。そのような場合、Binging Update情報をHAS間で同期する必要がある場合があります。同期モードは、一次系列またはピアツーピアのいずれかです。さらに、MNPがMRに委任される場合（セクション4.5を参照）、HAS間のある程度の調整も必要になる場合があります。
This issue is a general mobility issue that will also have to be dealt with by Mobile IPv6 (see Section 6.2.3 in [7]) as well as NEMO Basic Support.
この問題は、モバイルIPv6（[7]のセクション6.2.3を参照）とNEMOの基本的なサポートでも対処する必要がある一般的なモビリティの問題です。
In the (n,*,*) configurations, there are common decisions that may require synchronization among different MRs [19], such as:
（n、*、*）構成には、次のような異なるMR [19]の間で同期を必要とする可能性のある一般的な決定があります。
o advertising the same MNP in the (n,*,1) configurations (see also "prefix delegation" in Section 4.5);
o
o one MR relaying the advertisement of the MNP from another failed MR in the (n,*,n) configuration; and
o
o relaying between MRs everything that needs to be relayed, such as data packets, creating a tunnel from the ingress interface, etc., in the (n,*,*) configuration.
o （n、*、*）構成で、データパケットなど、データパケットなどのすべてのものを中継する必要があるすべてのものを中継します。
However, there is no known standardized protocol for this kind of router-to-router synchronization. Without such synchronization, it may not be possible for a (n,*,*) configuration to achieve various multihoming goals, such as fault tolerance.
ただし、この種のルーター間同期については、既知の標準化されたプロトコルはありません。このような同期がなければ、（n、*、*）構成がフォールトトレランスなどのさまざまなマルチホームの目標を達成することは不可能かもしれません。
Such a synchronization mechanism can be primary-secondary (i.e., a master MR, with the other MRs as backup) or peer-to-peer (i.e., there is no clear administrative hierarchy between the MRs). The need for such mechanism is general in the sense that a multi-router site in the fixed network would require the same level of router synchronization.
このような同期メカニズムは、一次系列（つまり、マスターMR、他のMRSはバックアップとして）またはピアツーピア（つまり、MRSの間に明確な管理階層はありません）です。このようなメカニズムの必要性は、固定ネットワーク内のマルチルーターサイトが同じレベルのルーター同期を必要とするという意味で一般的です。
Thus, this issue is not specific to NEMO Basic Support, though there is a more pressing need to develop an MR-to-MR synchronization scheme for proving fault tolerances and failure recovery in NEMO configurations due to the higher possibility of links failure.
したがって、この問題はNEMOの基本的なサポートに固有のものではありませんが、リンク障害の可能性が高いため、NEMO構成での断層許容度と障害回復を証明するためのMR-MR同期スキームを開発する必要があります。
In conclusion, it is recommended to investigate a generic solution to this issue although the solution would first have to be developed for NEMO deployments.
結論として、この問題に対する一般的なソリューションを調査することをお勧めしますが、ソリューションは最初にNEMOの展開用に開発する必要があります。
In the (*,*,1) configurations, the same MNP must be advertised to the MNNs through different paths. There is, however, no synchronization mechanism available to achieve this. Without a synchronization mechanism, MR may end up announcing incompatible MNPs. Particularly,
（*、*、1）構成では、同じMNPを異なるパスを介してMNNに宣伝する必要があります。ただし、これを達成するために利用できる同期メカニズムはありません。同期メカニズムがなければ、MRは互換性のないMNPを発表することになります。特に、
o for the (*,n,1) cases, how can multiple HAs delegate the same MNP to the mobile network? For doing so, the HAs may be somehow configured to advertise the same MNP (see also "HA Synchronization" in Section 4.3).
o （*、n、1）の場合、複数は同じMNPをモバイルネットワークにどのように委任することができますか？そのためには、同じMNPを宣伝するように何らかの形で構成されている可能性があります（セクション4.3の「HA同期」も参照）。
o for the (n,*,1) cases, how can multiple MRs be synchronized to advertise the same MNP down the NEMO-link? For doing so, the MRs may be somehow configured to advertise the same MNP (see also "MR Synchronization" in Section 4.4).
o （n、*、1）ケースの場合、複数のMRを同期して、同じMNPをNemo-linkで宣伝するにはどうすればよいですか？そうするために、MRSは、同じMNPを宣伝するように何らかの形で構成されている可能性があります（セクション4.4の「MR同期」も参照）。
Prefix delegation mechanisms [20][21][22] could be used to ensure all routers advertise the same MNP. Their applicability to a multihomed mobile network should be considered.
プレフィックス委任メカニズム[20] [21] [22]を使用して、すべてのルーターが同じMNPを宣伝するようにすることができます。マルチホームモバイルネットワークへの適用性を考慮する必要があります。
When an MR is configured with multiple CoAs, it is often necessary for it to bind these CoAs to the same MNP.
MRが複数のCOAで構成されている場合、これらのCOAを同じMNPに結合することがしばしば必要です。
This is a generic mobility issue, since Mobile IPv6 nodes face a similar problem. This issue is discussed in [7]. It is sufficient to note that solutions like [23] can solve this for both Mobile IPv6 and NEMO Basic Support. This issue is being dealt with in the Monami6 WG.
モバイルIPv6ノードは同様の問題に直面しているため、これは一般的なモビリティの問題です。この問題は[7]で議論されています。[23]のようなソリューションは、モバイルIPv6とNEMOの基本サポートの両方でこれを解決できることに注意するだけで十分です。この問題は、Monami6 WGで対処されています。
In the (*,*,n) configurations, MNNs would be configured with multiple addresses. Source address selection mechanisms are needed to decide which address to choose from.
（*、*、n）構成では、MNNは複数のアドレスで構成されます。ソースアドレスの選択メカニズムは、どのアドレスから選択するかを決定するために必要です。
However, currently available source address selection mechanisms do not allow MNNs to acquire sufficient information to select their source addresses intelligently (such as based on the traffic condition associated with the home network of each MNP). It may be desirable for MNNs to be able to acquire "preference" information on each MNP from the MRs. This would allow default address selection mechanisms, such as those specified in [24], to be used. Further exploration on setting such "preference" information in Router Advertisement based on performance of the bi-directional tunnel might prove to be useful. Note that source address selection may be closely related to path selection procedures (see Section 4.1.3) and re-homing techniques (see Section 4.1.4).
ただし、現在利用可能なソースアドレスの選択メカニズムでは、MNNがソースアドレスをインテリジェントに選択するのに十分な情報を取得することができません（各MNPのホームネットワークに関連するトラフィック条件に基づくなど）。MNNSがMRSから各MNPの「優先」情報を取得できることが望ましい場合があります。これにより、[24]で指定されているものなど、デフォルトのアドレス選択メカニズムを使用することができます。双方向トンネルのパフォーマンスに基づいて、ルーター広告にこのような「選好」情報を設定することに関するさらなる調査は、有用であることが証明されるかもしれません。ソースアドレスの選択は、パス選択手順（セクション4.1.3を参照）および再ホーミング手法（セクション4.1.4を参照）に密接に関連している場合があることに注意してください。
This is a general issue faced by any node when offered multiple prefixes.
これは、複数のプレフィックスが提供された場合、任意のノードが直面する一般的な問題です。
When a multihomed mobile network is nested within another mobile network, it can result in very complex topologies. For instance, a nested mobile network may be attached to two different root-MRs, thus the aggregated network no longer forms a simple tree structure. In such a situation, infinite loop within the mobile network may occur.
マルチホームモバイルネットワークが別のモバイルネットワーク内にネストされると、非常に複雑なトポロジが生じる可能性があります。たとえば、ネストされたモバイルネットワークは2つの異なるルートMRに接続される可能性があるため、集約されたネットワークはもはや単純なツリー構造を形成しなくなります。このような状況では、モバイルネットワーク内の無限ループが発生する可能性があります。
This problem is specific to NEMO Basic Support. However, at the time of writing, more research is recommended to assess the probability of loops occurring in a multihomed mobile network. For related work, see [25] for a mechanism to avoid loops in nested NEMO.
この問題は、NEMOの基本的なサポートに固有です。ただし、執筆時点では、マルチホームモバイルネットワークで発生するループの確率を評価するために、さらに調査をお勧めします。関連する作業については、ネおよびネモのループを避けるためのメカニズムについては[25]を参照してください。
When a (n,*,1) network splits, (i.e., the two MRs split themselves up), MRs on distinct links may try to register the only available MNP. This cannot be allowed, as the HA has no way to know which node with an address configured from that MNP is attached to which MR. Some mechanism must be present for the MNP to either be forcibly removed from one (or all) MRs, or the implementors must not allow a (n,*,1) network to split.
a（n、*、1）ネットワークが分割されると（つまり、2人の夫人が自分自身を分割する）、別のリンクのMRSは、利用可能な唯一のMNPを登録しようとする場合があります。HAには、そのMNPから構成されたアドレスを持つどのノードが添付されているかを知る方法がないため、これは許可できません。MNPが1つの（またはすべての）MRSから強制的に削除されるか、実装者が（n、*、1）ネットワークが分割されてはならないか、いくつかのメカニズムを存在する必要があります。
A possible approach to solving this problem is described in [26].
この問題を解決するための可能なアプローチは[26]で説明されています。
This problem is specific to NEMO Basic Support. However, it is unclear whether there is a sufficient deployment scenario for this problem to occur.
この問題は、NEMOの基本的なサポートに固有です。ただし、この問題が発生するのに十分な展開シナリオがあるかどうかは不明です。
It is recommended that the NEMO WG standardize a solution to solve this problem if there is sufficient vendor/operator interest, or specify that the split of a (n,*,1) network cannot be allowed without router renumbering.
NEMO WGは、十分なベンダー/オペレーターの関心がある場合にこの問題を解決するためのソリューションを標準化することをお勧めします。または、ルーターの変更なしでは（n、*、1）ネットワークの分割を許可できないことを指定することをお勧めします。
When a mobile network is multihomed, the MNNs may be able to benefit from this configuration, such as to choose among the available paths based on cost, transmission delays, bandwidth, etc. However, in some cases, such a choice is not made available to the MNNs. Particularly:
モバイルネットワークがマルチホームの場合、MNNは、コスト、送信の遅延、帯域幅などに基づいて利用可能なパスを選択するなど、この構成から利益を得ることができます。ただし、場合によっては、そのような選択は利用可能になりませんMNNSに。特に：
o In the (*,*,n) configuration, the MNNs can influence the path by source address selection (see Section 4.1.3 and Section 4.7).
o （*、*、n）構成では、MNNSはソースアドレスの選択によってパスに影響を与える可能性があります（セクション4.1.3およびセクション4.7を参照）。
o In the (n,*,*) configuration, the MNNs can influence the path by default router selection (see Section 4.1.3).
o （n、*、*）構成では、MNNSはデフォルトのルーターの選択によりパスに影響を与える可能性があります（セクション4.1.3を参照）。
o In the (1,n,1) configuration, the MNNs cannot influence the path selection.
o （1、n、1）構成では、MNNSはパス選択に影響を与えることができません。
One aspect of preference setting is that the preference of the MNN (e.g., application or transport layer configuration) may not be the same as the preference used by MR. Thus, forwarding choices made by the MR may not be the best for a particular flow, and may even be detrimental to some transport control loops (i.e., the flow control algorithm for TCP may be messed up when MR unexpectedly performs load balancing on a TCP flow). A mechanism that allows the MNN to indicate its preference for a given traffic might be helpful here.
設定の設定の1つの側面は、MNN（アプリケーションまたは輸送層の構成など）の選好がMRが使用する選好と同じではない可能性があることです。したがって、MRが行った転送の選択は特定のフローに最適ではなく、一部の輸送制御ループに有害である場合があります（つまり、MRがTCPで予期せずに負荷バランスを実行すると、TCPのフロー制御アルゴリズムが台無しになる可能性があります。フロー）。MNNが特定のトラフィックに対する好みを示すことを可能にするメカニズムは、ここで役立つかもしれません。
Another aspect of preference setting is that the MNN may not even be aware of the existence of multiple forwarding paths, e.g., the (1,n,1) configuration. A mechanism for the MR to advertise the availability of multiple tunneling paths would allow the MNN to take advantage of this, coupled with the previously mentioned mechanism that allows the MNN to indicate its preference for a given traffic.
優先設定のもう1つの側面は、MNNが複数の転送パス、たとえば（1、n、1）構成の存在を認識していないことです。MRが複数のトンネルパスの可用性を宣伝するメカニズムにより、MNNはこれを活用することができます。これは、MNNが特定のトラフィックの好みを示すことができる前述のメカニズムと相まってです。
This problem is general in the sense that IPv6 nodes may wish to influence the routing decision done by the upstream routers. Such a mechanism is currently being explored by various WGs, such as the NSIS and IPFIX WGs. It is also possible that the Shim6 layer in the MNNs may possess such a capability. It is recommended for vendors or operators to investigate into the solutions developed by these WGs when providing multihoming capabilities to mobile networks.
この問題は、IPv6ノードが上流のルーターによって行われるルーティング決定に影響を与えることを望んでいるという意味で一般的です。このようなメカニズムは現在、NSISやIPFIX WGSなどのさまざまなWGSによって調査されています。MNNSのSHIM6層がそのような能力を持っている可能性もあります。ベンダーまたはオペレーターが、モバイルネットワークにマルチホーム機能を提供する際にこれらのWGSによって開発されたソリューションを調査することをお勧めします。
In addition, the Monami6 WG is currently developing a flow filtering solution for mobile nodes to indicate how flows should be forwarded by a filtering agent [27] (such as HA and mobile anchor points). It is recommended that the Monami6 WG consider the issues described here so that flow filtering can be performed by the MNN to indicate how flows should be forwarded by the MR.
さらに、Monami6 WGは現在、モバイルノードのフローフィルタリングソリューションを開発しており、フィルタリング剤[27]（HAやモバイルアンカーポイントなど）によってフローを転送する方法を示しています。MONAMI6 WGは、MNNによってフローフィルタリングを実行してMRがどのように転送するかを示すことができるように、ここで説明する問題を考慮することをお勧めします。
Several issues that might impact the deployment of NEMO with multihoming capabilities were identified in Section 4. These are shown in the matrix below, for each of the eight multihoming configurations, together with indications from which WG(s) a solution to each issue is most likely to be found.
NEMOの展開に影響を与える可能性のあるいくつかの問題は、セクション4で特定されました。これらは、8つのマルチホーム構成のそれぞれについて、以下のマトリックスに示されており、WG（s）が各問題の解決策が最も多くある適応とともに見つかる可能性があります。
+=================================================================+
| # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n |
| # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n |
| # of Prefixes: | 1 | n | 1 | n | 1 | n | 1 | n |
+=================================================================+
| Fault Tolerance | * | * | * | * | * | * | * | * |
+---------------------------------+---+---+---+---+---+---+---+---+
| Failure Detection |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Path Exploration |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Path Selection | N |S/M| M |S/M| N |S/N| N |S/N|
+---------------------------------+---+---+---+---+---+---+---+---+
| Re-Homing |N/M| S |N/M| S |N/M| S |N/M| S |
+---------------------------------+---+---+---+---+---+---+---+---+
| Ingress Filtering | . | . | . | t | . | . | . | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| HA Synchronization | . | . |N/M|N/M| . | . |N/M|N/M|
+---------------------------------+---+---+---+---+---+---+---+---+
| MR Synchronization | . | . | . | . | G | G | G | G |
+---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Delegation | . | . | N | N | N | N | N | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| Multiple Binding/Registrations | M | M | M | M | M | M | M | M |
+---------------------------------+---+---+---+---+---+---+---+---+
| Source Address Selection | . | G | . | G | . | G | . | G |
+---------------------------------+---+---+---+---+---+---+---+---+
| Loop Prevention in Nested NEMO | N | N | N | N | N | N | N | N |
+---------------------------------+---+---+---+---+---+---+---+---+
| Prefix Ownership | . | . | . | . | N | . | N | . |
+---------------------------------+---+---+---+---+---+---+---+---+
| Preference Settings | G | G | G | G | G | G | G | G |
+=================================================================+
N - NEMO Specific M - MIPv6 Specific G - Generic IPv6
S - SHIM6 WG D - DNA WG
. - Not an Issue t - trivial
* - Fault Tolerance is a combination of Failure Detection, Path
Exploration, Path Selection, and Re-Homing
Figure 10: Matrix of NEMO Multihoming Issues
図10：Nemo Multihomingの問題のマトリックス
The above matrix serves to identify which issues are NEMO-specific, and which are not. The readers are reminded that this matrix is a simplification of Section 4 as subtle details are not represented in Figure 10.
上記のマトリックスは、どの問題がNEMO固有で、どの問題がそうでないかを特定するのに役立ちます。読者は、微妙な詳細が図10に示されていないため、このマトリックスはセクション4の単純化であることを思い出します。
As can be seen from Figure 10, the following are some concerns that are specific to NEMO: Failure Detection, Path Exploration, Path Selection, Re-Homing, Ingress Filtering, HA Synchronization, Prefix Delegation, Loop Prevention in Nested NEMO, and Prefix Ownership. Based on the authors' best knowledge of the possible deployments of NEMO, it is recommended that:
図10からわかるように、以下はNEMOに固有の懸念事項です。故障検出、パス探索、パス選択、再ホーミング、イングレスフィルタリング、HA同期、接頭辞委任、ネットネモのループ予防、およびプレフィックスの所有権。NEMOの展開の可能性に関する著者の最善の知識に基づいて、次のことをお勧めします。
o A solution for Failure Detection, Path Exploration, Path Selection, and Re-Homing be solicited from other WGs.
o 障害検出、パス探索、パス選択、および再ホーミングのソリューションを他のWGSから募集します。
Although Path Selection is reflected in Figure 10 as NEMO-Specific, the technical consideration of the problem is believed to be quite similar to the selection of multiple paths in mobile nodes. As such, we would recommend vendors to solicit a solution for these issues from other WGs in the IETF; for instance, the Monami6 or Shim6 WG.
PATH選択は図10にNEMO固有のものとして反映されていますが、問題の技術的な考慮事項は、モバイルノードの複数のパスの選択と非常に似ていると考えられています。そのため、IETFの他のWGSからこれらの問題の解決策を求めるようにベンダーをお勧めします。たとえば、Monami6またはShim6 WG。
o Ingress Filtering on the (n,n,n) configuration can be solved by the NEMO WG.
o （n、n、n）構成のイングレスフィルタリングは、nemo WGによって解決できます。
This problem is clearly defined, and can be solved by the WG. Deployment of the (n,n,n) configuration can be envisioned on vehicles for mass transportation (such as buses, trains) where different service providers may install their own MRs on the vehicle/vessel.
この問題は明確に定義されており、WGによって解決できます。（n、n、n）構成の展開は、さまざまなサービスプロバイダーが車/容器に自分のMRSを設置できる大量輸送（バス、列車など）の車両で想定できます。
It should be noted that the Shim6 WG may be developing a mechanism for overcoming ingress filtering in a more general sense. We thus recommend that the NEMO WG concentrate only on the (n,n,n) configuration should the WG decide to work on this issue.
SHIM6 WGは、より一般的な意味で入り込みフィルターを克服するためのメカニズムを開発している可能性があることに注意する必要があります。したがって、NEMO WGは、WGがこの問題に取り組むことを決定した場合にのみ（n、n、n）構成に濃縮することをお勧めします。
o A solution for HA Synchronization can be looked at in a mobility-specific WG, taking into consideration both mobile hosts operating Mobile IPv6 and MRs operating NEMO Basic Support.
o HA同期のソリューションは、モバイルホストとMRSの動作NEMO基本サポートを操作するモバイルホストの両方を考慮して、モビリティ固有のWGで検討できます。
o A solution for Multiple Bindings/Registrations is presently being developed by the Monami6 WG.
o 複数のバインディング/登録のソリューションは、現在Monami6 WGによって開発されています。
o Prefix Delegation should be reviewed and checked by the NEMO WG.
o 接頭辞委任は、Nemo WGによってレビューおよびチェックする必要があります。
The proposed solutions [22] and [21] providing prefix delegation functionality to NEMO Basic Support should be reviewed in order to make sure concerns, as discussed in Section 4.5, are properly handled.
セクション4.5で説明したように、懸念が適切に処理されることを確認するために、NEMOの基本的なサポートにプレフィックス委任機能を提供する提案されたソリューション[22]および[21]をレビューする必要があります。
o Loop Prevention in Nested NEMO should be investigated.
o ネストされたNEMOのループ予防を調査する必要があります。
Further research is recommended to assess the risk of having a loop in the nesting of multihomed mobile networks.
マルチホームモバイルネットワークのネスティングにループを持つリスクを評価するために、さらなる研究が推奨されます。
o Prefix Ownership should be considered by the vendors and operators.
o 接頭辞の所有権は、ベンダーとオペレーターが考慮する必要があります。
The problem of Prefix Ownership only occurs when a mobile network with multiple MRs and a single MNP can arbitrarily join and split. Vendors and operators of mobile networks are encouraged to input their views on the applicability of deploying such kind of mobile networks.
接頭辞の所有権の問題は、複数のMRSと単一のMNPを持つモバイルネットワークが任意に結合して分割できる場合にのみ発生します。モバイルネットワークのベンダーとオペレーターは、このような種類のモバイルネットワークを展開するという適用性に関する意見を入力することをお勧めします。
This memo presented an analysis of multihoming in the context of network mobility under the operation of NEMO Basic Support (RFC 3963). The purpose was to investigate issues related to such a bi-directional tunneling mechanism where mobile networks are multihomed and multiple bi-directional tunnels are established between Home Agent and Mobile Router pairs. For doing so, mobile networks were classified into a taxonomy comprising eight possible multihomed configurations. Issues were explained one by one and then summarized into a table showing the multihomed configurations where they apply, suggesting the most relevant IETF working group where they could be solved. This analysis will be helpful to extend the existing standards to support multihoming and to implementors of NEMO Basic Support and multihoming-related mechanisms.
このメモは、NEMO Basic Support（RFC 3963）の操作中のネットワークモビリティのコンテキストでのマルチホームの分析を提示しました。目的は、モバイルネットワークがマルチホームであり、ホームエージェントとモバイルルーターペアの間に複数の双方向トンネルが確立されるこのような双方向トンネルメカニズムに関連する問題を調査することでした。そのために、モバイルネットワークは、8つの可能なマルチホーム構成を含む分類法に分類されました。問題は1つずつ説明され、それらが適用されるマルチホーム構成を示すテーブルに要約され、それらを解決できる最も関連性の高いIETFワーキンググループを示唆しています。この分析は、既存の標準を拡張して、MultihomingおよびNemo Basic SupportおよびMultihoming関連のメカニズムの実装者をサポートするのに役立ちます。
This is an informational document where the multihoming configurations under the operation of NEMO Basic Support are analyzed. Security considerations of these multihoming configurations, should they be different from those that concern NEMO Basic Support, must be considered by forthcoming solutions. For instance, an attacker could try to use the multihomed device as a means to access another network that would not be normally reachable through the Internet. Even when forwarding to another network is turned off by configuration, an attacker could compromise a system to enable it.
これは、NEMO基本サポートの操作中のマルチホーム構成が分析される情報文書です。これらのマルチホーム構成のセキュリティ上の考慮事項は、NEMOの基本的なサポートに関係するものとは異なる場合は、今後のソリューションによって考慮する必要があります。たとえば、攻撃者は、通常、インターネットを介して到達できない別のネットワークにアクセスする手段としてマルチホームデバイスを使用しようとすることができます。別のネットワークへの転送が構成によってオフになる場合でも、攻撃者はシステムを妥協してそれを有効にする可能性があります。
The authors would like to thank people who have given valuable comments on various multihoming issues on the mailing list, and also those who have suggested directions in the 56th - 61st IETF Meetings. The initial evaluation of NEMO Basic Support on multihoming configurations is a contribution from Julien Charbon.
著者は、メーリングリストのさまざまな多語の問題について貴重なコメントを与えた人々、そして第61回IETFミーティングで指示を提案した人々に感謝したいと思います。マルチホーム構成に関するNEMO基本サポートの最初の評価は、Julien Charbonからの貢献です。
[1] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.
[1] エルンスト、T。、「ネットワークモビリティサポートの目標と要件」、RFC 4886、2007年7月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[2] Mather、J。およびM. Kojo、「Mobility関連用語」、RFC 3753、2004年6月。
[3] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[3] エルンスト、T。、およびH-Y。Lach、「ネットワークモビリティサポート用語」、RFC 4885、2007年7月。
[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[4] Devarapalli、V.、Wakikawa、R.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、RFC 3963、2005年1月。
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[5] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[6] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", Work in Progress, October 2006.
[6] Ernst、T.、Montavont、N.、Wakikawa、R.、Ng、C。、およびK. Kuladinithi、「複数のインターフェイスとグローバルアドレスを使用するための動機とシナリオ」、2006年10月の作業。
[7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in Progress, February 2006.
[7] Montavont、N.、Wakikawa、R.、Ernst、T.、Ng、C。、およびK. Kuladinithi、「モバイルIPv6におけるマルチホミングの分析」、2006年2月の進行中。
[8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[8] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6（DHCPV6）の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[9] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Work in Progress, December 2006.
[9] Arkko、J。およびI. Beijnum、「IPv6 Multihomingの障害検出およびロケーターペア探査プロトコル」、2006年12月、進行中の作業。
[10] Krishnan, S., Montavont, N., Yegin, A., Veerepalli, S., and A. Yegin, "Link-layer Event Notifications for Detecting Network Attachments", Work in Progress, November 2006.
[10] Krishnan、S.、Montavont、N.、Yegin、A.、Veerepalli、S。、およびA. Yegin、「ネットワーク添付ファイルを検出するためのリンクレイヤーイベント通知」、2006年11月の作業。
[11] Narayanan, S., "Detecting Network Attachment in IPv6 Networks (DNAv6)", Work in Progress, October 2006.
[11] Narayanan、S。、「IPv6ネットワーク（DNAV6）のネットワーク添付ファイルの検出」、2006年10月、進行中の作業。
[12] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[12] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6の近隣発見（IPv6）」、RFC 2461、1998年12月。
[13] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim protocol", Work in Progress, November 2006.
[13] Nordmark、E。およびM. Bagnulo、「レベル3マルチホミングシムプロトコル」、2006年11月、進行中の作業。
[14] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[14] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[15] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[15] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[16] Huitema, C. and M. Marcelo, "Ingress filtering compatibility for IPv6 multihomed sites", Work in Progress, October 2006.
[16] Huitema、C。and M. Marcelo、「IPv6マルチホームサイトの互換性のフィルタリング」、2006年10月、進行中の作業。
[17] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home Agents Protocol (HAHA)", Work in Progress, February 2004.
[17] Wakikawa、R.、Devarapalli、V。、およびP. Thubert、「Inter Home Agents Protocol（haha）」、2004年2月、進行中の作業。
[18] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent Protocol", Work in Progress, July 2004.
[18] Koh、B.、Ng、C。、およびJ. Hirano、「Dynamic Inter Home Agent Protocol」、2004年7月の作業。
[19] Tsukada, M., "Analysis of Multiple Mobile Routers Cooperation", Work in Progress, October 2005.
[19] Tsukada、M。、「複数のモバイルルーター協力の分析」、2005年10月、進行中の作業。
[20] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004.
[20] 宮川、S。およびR.ドロム、「IPv6プレフィックス委任の要件」、RFC 3769、2004年6月。
[21] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", Work in Progress, September 2006.
[21] Droms、R。and P. Thubert、「Dhcpv6プレフィックス委任のNemo」、2006年9月、進行中の作業。
[22] Thubert, P. and TJ. Kniveton, "Mobile Network Prefix Delegation", Work in Progress, November 2006.
[22] Thubert、P。およびTJ。Kniveton、「モバイルネットワークプレフィックス代表団」、2006年11月、進行中の作業。
[23] Wakikawa, R., "Multiple Care-of Addresses Registration", Work in Progress, June 2006.
[23] Wakikawa、R。、「複数の住所登録」、2006年6月、進行中の作業。
[24] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[24] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[25] Thubert, P., Bontous, C., and N. Nicolas, "Nested Nemo Tree Discovery", Work in Progress, November 2006.
[25] Thubert、P.、Bontous、C。、およびN. Nicolas、「ネストされたネモツリーディスカバリー」、2006年11月、作業中。
[26] Kumazawa, M., "Token based Duplicate Network Detection for split mobile network (Token based DND)", Work in Progress, July 2005.
[26] Kumazawa、M。、「トークンベースのモバイルネットワーク（トークンベースのDND）のトークンベースの重複ネットワーク検出」、2005年7月、進行中の作業。
[27] Soliman, H., "Flow Bindings in Mobile IPv6 and NEMO Basic Support", Work in Progress, March 2007.
[27] Soliman、H。、「モバイルIPv6およびNemo Basic Supportのフローバインディング」、2007年3月、進行中の作業。
An alternative approach to classifying a multihomed mobile network was proposed by Erik Nordmark (Sun Microsystems) by breaking the classification of multihomed network based on ownership. This is more of a tree-like, top-down classification. Starting from the control and ownership of the HA(s) and MR(s), there are two different possibilities: either (i) the HA(s) and MR(s) are controlled by a single entity, or (ii) the HA(s) and MR(s) are controlled by separate entities. We called the first possibility the 'ISP Model', and the second the 'Subscriber/Provider Model'.
The case of the HA(s) and MR(s) are controlled by the same entity can be best illustrated as an Internet Service Provider (ISP) installing MRs on trains, ships, or planes. It is up to the ISP to deploy a certain configuration of mobile network; all 8 configurations, as described in the Configuration-Oriented Approach, are possible. In the remaining portion of this document, when specifically referring to a mobile network configuration that is controlled by a single entity, we will add an 'ISP' prefix; for example, ISP-(1,1,1) or ISP-(1,n,n).
HA（s）とMRの場合は、同じエンティティによって制御されている場合は、列車、船、または飛行機にMRSを設置するインターネットサービスプロバイダー（ISP）として最もよく示すことができます。モバイルネットワークの特定の構成を展開するのはISP次第です。構成指向のアプローチで説明されているように、8つの構成すべてが可能です。このドキュメントの残りの部分では、単一のエンティティによって制御されるモバイルネットワーク構成を具体的に参照する場合、「ISP」プレフィックスを追加します。たとえば、ISP-（1,1,1）またはISP-（1、n、n）。
When the HA(s) and MR(s) are controlled by a single entity (such as an ISP), the ISP can decide whether it wants to assign one or multiple MNPs to the mobile network just like it can make the same decision for any other link in its network (wired or otherwise). In any case, the ISP will make the routing between the mobile networks and its core routers (such as the HAs) work. This includes not introducing any aggregation between the HAs, which will filter out routing announcements for the MNP(s).
HA（S）とMRが単一のエンティティ（ISPなど）によって制御される場合、ISPは、同じ決定を下すことができるのと同じように、1つまたは複数のMNPをモバイルネットワークに割り当てるかどうかを決定できます。ネットワーク内の他のリンク（有線またはその他）。いずれにせよ、ISPはモバイルネットワークとそのコアルーター（HASなど）の間のルーティングを機能させます。これには、HAS間に集約を導入しないことが含まれます。これにより、MNPのルーティングアナウンスが除外されます。
To such ends, the ISP has various means and mechanisms. For one, the ISP can run its Interior Gateway Protocol (IGP) over bi-directional tunnels between the MR(s) and HA(s). Alternatively, static routes may be used with the tunnels. When static routes are used, a mechanism to test "tunnel liveness" might be necessary to avoid maintaining stale routes. Such "tunnel liveness" may be tested by sending heartbeats signals from MR(s) to the HA(s). A possibility is to simulate heartbeats using Binding Updates messages by controlling the "Lifetime" field of the Binding Acknowledgment message to force the MR to send Binding Update messages at regular intervals. However, a more appropriate tool might be the Binding Refresh Request message, though conformance to the Binding Refresh Request message may be less strictly enforced in implementations since it serves a somewhat secondary role when compared to Binding Update messages.
そのような目的に、ISPにはさまざまな手段とメカニズムがあります。1つは、ISPは、MR（S）とHA（S）の間の双方向トンネルでインテリアゲートウェイプロトコル（IGP）を実行できます。あるいは、トンネルとともに静的ルートを使用することもできます。静的ルートを使用する場合、古いルートの維持を避けるために「トンネルのlivening」をテストするメカニズムが必要になる場合があります。このような「トンネルのlivenives」は、MRからHA（s）にハートビート信号を送信することでテストできます。可能性は、バインディングアップデートメッセージの「寿命」フィールドを制御して、MRに定期的にバインディングアップデートメッセージを送信するように強制することにより、バインディングアップデートメッセージを使用してハートビートをシミュレートすることです。ただし、より適切なツールはバインディングリフレッシュリクエストメッセージである可能性がありますが、バインディングされた更新メッセージと比較してやや二次的な役割を果たすため、バインディングリフレッシュリクエストメッセージへの適合性は実装では厳密に施行されていない場合があります。
The case of the HA(s) and MR(s) controlled by the separate entities can be best illustrated with a subscriber/provider model, where the MRs belongs to a single subscriber and subscribes to one or more ISPs for HA services. There is two sub-categories in this case: when the subscriber subscribes to a single ISP, and when the subscriber subscribes to multiple ISPs. In the remaining portion of this document, when specifically referring to a mobile network configuration that is in the subscriber/provider model where the subscriber subscribes to only one ISP, we will add an 'S/P' prefix; for example, S/P-(1,1,1) or S/P-(1,n,n). When specifically referring to a mobile network configuration that is in the subscriber/provider model where the subscriber subscribes to multiple ISPs, we will add an 'S/mP' prefix; for example, S/mP-(1,1,1) or S/mP-(1,n,n).
別々のエンティティによって制御されるHA（S）とMR（S）の場合は、MRSが単一のサブスクライバーに属し、HAサービスの1つ以上のISPを購読するサブスクライバー/プロバイダーモデルで最もよく示すことができます。この場合、2つのサブカテゴリがあります。サブスクライバーが単一のISPにサブスクライブする場合、およびサブスクライバーが複数のISPを購読する場合。このドキュメントの残りの部分では、サブスクライバーが1つのISPのみをサブスクライブするサブスクライバー/プロバイダーモデルにあるモバイルネットワーク構成を具体的に参照する場合、「S/P」プレフィックスを追加します。たとえば、s/p-（1,1,1）またはs/p-（1、n、n）。サブスクライバーが複数のISPをサブスクライブするサブスクライバー/プロバイダーモデルにあるモバイルネットワーク構成を具体的に参照する場合、「S/MP」プレフィックスを追加します。たとえば、s/mp-（1,1,1）またはs/mp-（1、n、n）。
Not all 8 configurations are likely to be deployed for the S/P and S/mP models. For instance, it is unlikely to foresee a S/mP-(*,1,1) mobile network where there is only a single HA. For the S/P model, the following configurations are likely to be deployed:
8つの構成すべてがS/PおよびS/MPモデル用に展開されるわけではありません。たとえば、S/MP-（*、1,1）モバイルネットワークがある場合は、単一のHAしかないモバイルネットワークを予測することはほとんどありません。S/Pモデルの場合、次の構成が展開される可能性があります。
o S/P-(1,1,1): Single Provider, Single MR, Single HA, Single MNP
o S/P-（1,1,1）：シングルプロバイダー、シングルMR、シングルHA、シングルMNP
o S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple MNPs
o s/p-（1,1、n）：シングルプロバイダー、シングルMR、シングルHA、複数のMNP
o S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single MNP
o s/p-（1、n、1）：シングルプロバイダー、シングルMR、倍数があり、単一のMNPがあります
o S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple MNPs
o s/p-（1、n、n）：シングルプロバイダー、シングルMR、倍数があり、複数のMNP
o S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single MNP
o s/p-（n、n、1）：シングルプロバイダー、複数のMRS、シングルHA、シングルMNP
o S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple MNPs
o s/p-（n、1、n）：シングルプロバイダー、複数のMRS、単一HA、複数のMNP
o S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single MNP
o s/p-（n、n、1）：シングルプロバイダー、複数のmrs、倍数、単一のmnp
o S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple MNPs
o s/p-（n、n、n）：シングルプロバイダー、複数のMRS、複数のMultion、複数のMNP
For the S/mP model, the following configurations are likely to be deployed:
S/MPモデルの場合、次の構成が展開される可能性があります。
o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single MNP
o s/mp-（1、n、1）：複数のプロバイダー、シングルMR、倍数があり、単一のMNPがあります
o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs, Multiple MNPs
o s/mp-（1、n、n）：複数のプロバイダー、シングルMR、倍数があり、複数のMNPがあります
o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs, Multiple MNPs
o s/mp-（n、n、n）：複数のプロバイダー、複数のMRS、複数のMUNT、複数のMNP
When the HA(s) and MR(s) are controlled by different entities, it is more likely that the MR is controlled by one entity (i.e., the subscriber), and the MR is establishing multiple bi-directional tunnels to one or more HA(s) provided by one or more ISP(s). In such cases, it is unlikely that the ISP will run IGP over the bi-directional tunnel, since the ISP will most certainly wish to retain full control of its routing domain.
HA（S）とMRが異なるエンティティによって制御される場合、MRが1つのエンティティ（つまり、加入者）によって制御される可能性が高く、MRは1つ以上の複数の双方向トンネルを確立しています1つ以上のISPが提供するHA（s）。そのような場合、ISPはルーティングドメインの完全な制御を保持したいため、ISPが双方向トンネル上でIGPを実行する可能性は低いです。
A third approach was proposed by Pascal Thubert (Cisco Systems). This focused on the problems of multihomed mobile networks rather than the configuration or ownership. With this approach, there is a set of 4 categories based on two orthogonal parameters: the number of HAs, and the number of MNPs advertised. Since the two parameters are orthogonal, the categories are not mutually exclusive. The four categories are:
3番目のアプローチは、Pascal Thubert（Cisco Systems）によって提案されました。これは、構成や所有権ではなく、マルチホームのモバイルネットワークの問題に焦点を当てています。このアプローチを使用すると、2つの直交パラメーターに基づいた4つのカテゴリのセットがあります：HASの数と宣伝されているMNPの数。2つのパラメーターは直交であるため、カテゴリは相互に排他的ではありません。4つのカテゴリは次のとおりです。
o Tarzan: Single HA for Different CoAs of Same MNP
o ターザン：同じMNPの異なるCOASのシングルハ
This is the case where one MR registers different CoAs to the same HA for the same subnet prefix. This is equivalent to the case of y=1, i.e., the (1,1,*) mobile network.
これは、同じサブネットプレフィックスに対して、1つの氏が同じHAに異なるCOASを登録する場合です。これは、y = 1の場合、つまり（1,1、*）モバイルネットワークの場合と同等です。
o JetSet: Multiple HAs for Different CoAs of Same MNP
o ジェットセット：同じMNPの異なるCOASに対して複数のものがあります
This is the case where the MR registers different CoAs to different HAs for the same subnet prefix. This is equivalent to the case of y=n, i.e., the (1,n,*) mobile network.
これは、MRが異なるCOASを異なるサブネットプレフィックスに対して登録する場合です。これは、y = n、つまり（1、n、*）モバイルネットワークの場合と同等です。
o Shinkansen: Single MNP Advertised by MR(s)
o Shinkansen：MRが宣伝する単一のMNP
This is the case where one MNP is announced by different MRs. This is equivalent to the case of x=n and z=1, i.e., the (n,*,1) mobile network.
これは、1つのMNPが異なるMRSによって発表される場合です。これは、x = nおよびz = 1の場合、つまり（n、*、1）モバイルネットワークの場合と同等です。
o DoubleBed: Multiple MNPs Advertised by MR(s)
o ダブルベッド：MRによって宣伝されている複数のMNP
This is the case where more than one MNPs are announced by the different MRs. This is equivalent to the case of x=n and z=n, i.e., the (n,*,n) mobile network.
これは、異なるMRSによって複数のMNPが発表される場合です。これは、x = nおよびz = n、つまり（n、*、n）モバイルネットワークの場合と同等です。
In order to utilize the additional robustness provided by multihoming, MRs that employ bi-directional tunneling with their HAs should dynamically change their tunnel exit points depending on the link status. For instance, if an MR detects that one of its egress interface is down, it should detect if alternate routes to the global Internet exists. This alternate route may be provided by any other MRs connected to one of its ingress interfaces that has an independent route to the global Internet, or by another active egress interface the MR itself possesses. If such an alternate route exists, the MR should re-establish the bi-directional tunnel using this alternate route.
Multihomingが提供する追加の堅牢性を活用するために、Mrsはbi方向トンネリングを使用して使用することで、リンクのステータスに応じてトンネル出口ポイントを動的に変更するはずです。たとえば、MRがその出口インターフェイスの1つがダウンしていることを検出した場合、グローバルインターネットへの代替ルートが存在するかどうかを検出する必要があります。この代替ルートは、グローバルインターネットへの独立したルートを持つその侵入インターフェイスの1つに接続されている他のMRSによって提供される場合があります。このような代替ルートが存在する場合、MRはこの代替ルートを使用して双方向トンネルを再確立する必要があります。
In the remaining part of this Appendix, we will attempt to investigate methods of performing such re-establishment of bi-directional tunnels. This method of tunnel re-establishment is particularly useful for the (*,n,n) NEMO configuration. The method described is by no means complete and merely serves as a suggestion on how to approach the problem. It is also not the objective to specify a new protocol specifically tailored to provide this form of re-establishments. Instead, we will limit ourselves to currently available mechanisms specified in Mobile IPv6 [5] and Neighbor Discovery in IPv6 [12].
この付録の残りの部分では、双方向トンネルのそのような再確立を実行する方法を調査しようとします。このトンネルの再確立の方法は、（*、n、n）NEMO構成に特に役立ちます。説明されている方法は決して完全ではなく、問題にアプローチする方法に関する提案として単に役立つだけです。また、この形式の再確立を提供するように特別に調整された新しいプロトコルを指定することは目的ではありません。代わりに、モバイルIPv6 [5]で指定されている現在利用可能なメカニズムとIPv6 [12]で隣接するメカニズムに自分自身を制限します。
To actively utilize the robustness provided by multihoming, an MR must first be capable of detecting alternate routes. This can be manually configured into the MR by the administrators if the configuration of the mobile network is relatively static. It is however highly desirable for MRs to be able to discover alternate routes automatically for greater flexibility.
マルチホミングによって提供される堅牢性を積極的に利用するには、MRは最初に代替ルートを検出できる必要があります。これは、モバイルネットワークの構成が比較的静的である場合、管理者によってMRに手動で構成できます。ただし、MRSが柔軟性を高めるために自動的に代替ルートを発見できることは非常に望ましいものです。
The case where an MR possesses multiple egress interface (bound to the same HA or otherwise) should be trivial, since the MR should be able to "realize" it has multiple routes to the global Internet.
MRが複数の出口インターフェイスを所有する場合（同じHA以外にバインドされています）、MRはグローバルインターネットへの複数のルートを「実現」できるはずです。
In the case where multiple MRs are on the mobile network, each MR has to detect the presence of other MR. An MR can do so by listening for Router Advertisement message on its *ingress* interfaces. When an MR receives a Router Advertisement message with a non-zero Router Lifetime field from one of its ingress interfaces, it knows that another MR that can provide an alternate route to the global Internet is present in the mobile network.
複数のMRSがモバイルネットワーク上にいる場合、各MRは他のMRの存在を検出する必要があります。MRは、その *侵入 *インターフェイスでルーター広告メッセージを聞くことでそうすることができます。MRが、インターフェースの1つからゼロ以外のルーターライフタイムフィールドを使用してルーター広告メッセージを受信すると、グローバルインターネットへの代替ルートを提供できる別のMRがモバイルネットワークに存在することを知っています。
When an MR detects that the link by which its current bi-directional tunnel with its HA is using is down, it needs to re-establish the bi-directional tunnel using an alternate route detected. We consider two separate cases here: firstly, the alternate route is provided by another egress interface that belongs to the MR; secondly, the alternate route is provided by another MR connected to the mobile network. We refer to the former case as an alternate route provided by an alternate egress interface, and the latter case as an alternate route provided by an alternate MR.
MRが、HAを使用している現在の双方向トンネルがダウンしているリンクがダウンしていることを検出する場合、検出された代替ルートを使用して双方向トンネルを再確立する必要があります。ここでは、2つの別々のケースを検討します。まず、代替ルートは、MRに属する別の出力インターフェイスによって提供されます。第二に、代替ルートは、モバイルネットワークに接続された別のMRによって提供されます。前者のケースは、代替出力インターフェイスによって提供される代替ルートと、後者のケースを代替MRによって提供される代替ルートと呼びます。
When an egress interface of an MR loses the connection to the global Internet, the MR can make use of its alternate egress interface should it possess multiple egress interfaces. The most direct way to do so is for the MR to send a binding update to the HA of the failed interface using the CoA assigned to the alternate interface in order to re-establish the bi-directional tunneling using the CoA on the alternate egress interface. After a successful binding update, the MR encapsulates outgoing packets through the bi-directional tunnel using the alternate egress interface.
MRの出口インターフェイスがグローバルインターネットへの接続を失うと、MRは複数の出口インターフェイスを持っている場合に代替の出口インターフェイスを利用できます。これを行う最も直接的な方法は、MRが代替インターフェイスに割り当てられたCOAを使用して故障したインターフェイスのHAにバインディングアップデートを送信することです。。バインディングアップデートが成功した後、MRは、代替Egressインターフェイスを使用して、双方向トンネルを介して発信パケットをカプセル化します。
The idea is to use the global address (most likely a CoA) assigned to an alternate egress interface as the new (back-up) CoA of the MR to re-establish the bi-directional tunneling with its HA.
アイデアは、HAで双方向のトンネルを再確立するために、MRの新しい（バックアップ）COAとして代替Egressインターフェイスに割り当てられたグローバルアドレス（おそらくCOA）を使用することです。
When the MR loses a connection to the global Internet, the MR can utilize a route provided by an alternate MR (if one exists) to re-establish the bi-directional tunnel with its HA. First, the MR has to obtain a CoA from the alternate MR (i.e., attach itself to the alternate MR). Next, it sends binding update to its HA using the CoA obtained from the alternate MR. From then on, the MR can encapsulate outgoing packets through the bi-directional tunnel via the alternate MR.
MRがグローバルインターネットとの接続を失うと、MRは代替MR（存在する場合）が提供するルートを利用して、HAで双方向トンネルを再確立します。まず、MRは代替MRからCOAを取得する必要があります（つまり、代替MRに付着します）。次に、代替MRから取得したCOAを使用して、HAにバインディングアップデートを送信します。それ以降、MRは、代替MRを介して双方向トンネルを介して発信パケットをカプセル化することができます。
The idea is to obtain a CoA from the alternate MR and use this as the new (back-up) CoA of the MR to re-establish the bi-directional tunneling with its HA.
アイデアは、代替MRからCOAを取得し、これをMRの新しい（バックアップ）COAとして使用して、HAで双方向トンネリングを再確立することです。
Note that every packet sent between MNNs and their correspondent nodes will experience two levels of encapsulation. The first level of tunneling occurs between an MR that the MNN uses as its default router and the MR's HA. The second level of tunneling occurs between the alternate MR and its HA.
MNNとその特派員ノードの間で送信されるすべてのパケットには、2つのレベルのカプセル化が発生することに注意してください。トンネルの最初のレベルは、MNNがデフォルトのルーターとして使用するMRとMRのHAの間で発生します。トンネリングの第2レベルは、代替MRとそのHAの間で発生します。
The method of re-establishing the bi-directional tunnel as described in Appendix B.2 may lead to infinite loops of tunneling. This happens when two MRs on a mobile network lose connection to the global Internet at the same time and each MR tries to re-establish bi-directional tunnel using the other MR. We refer to this phenomenon as tunneling loop.
付録B.2に記載されているように、双方向トンネルを再確立する方法は、トンネルの無限のループにつながる可能性があります。これは、モバイルネットワーク上の2人のMRSが同時にグローバルインターネットへの接続を失い、各MRが他のMRを使用して双方向トンネルを再確立しようとすると起こります。この現象をトンネルループと呼びます。
One approach to avoid tunneling loop is for an MR that has lost connection to the global Internet to insert an option into the Router Advertisement message it broadcasts periodically. This option serves to notify other MRs on the link that the sender no longer provides global connection. Note that setting a zero Router Lifetime field will not work well since it will cause MNNs that are attached to the MR to stop using the MR as their default router too (in which case, things are back to square one).
トンネリングループを避けるための1つのアプローチは、グローバルインターネットとの接続を失ったMRが、定期的に放送されるルーター広告メッセージにオプションを挿入することです。このオプションは、送信者がグローバル接続を提供しなくなったというリンクで他のMRSに通知するのに役立ちます。ゼロルーターのライフタイムフィールドを設定すると、MRに取り付けられたMNNがデフォルトのルーターとしてMRの使用を停止するようになるため、うまく機能しないことに注意してください（その場合、物事は正方形に戻ります）。
This method of using tunnel re-establishments is by no means a complete solution. There are still points to consider in order to develop it into a fully functional solution. For instance, in Appendix B.1, it was suggested that MR detects the presence of other MRs using Router Advertisements. However, Router Advertisements are link scoped, so when there is more than one link, some information may be lost. For instance, suppose a case where there are three MRs and three different prefixes and each MR is in a different link with regular routers in between. Suppose now that only a single MR is working; how do the other MRs identify which prefix they have to use to configure the new CoA? In this case, there are three prefixes being announced, and an MR whose link has failed knows that its prefix is not to be used, but it does not have enough information to decide which one of the other two prefixes to use to configure the new CoA. In such cases, a mechanism is needed to allow an MR to withdraw its own prefix when it discovers that its link is no longer working.
トンネルの再確立を使用するこの方法は、決して完全な解決策ではありません。それを完全に機能的なソリューションに開発するために、まだ考慮すべき点があります。たとえば、付録B.1では、ルーター広告を使用して他のMRSの存在を検出することが示唆されました。ただし、ルーター広告はリンクスコープであるため、複数のリンクがある場合、一部の情報が失われる可能性があります。たとえば、3つのMRSと3つの異なるプレフィックスがあり、各MRが通常のルーターとの異なるリンクにある場合を想定してください。今、1人のMRだけが機能していると仮定します。他の夫人は、新しいCOAを構成するために使用するプレフィックスをどのように識別しますか？この場合、3つのプレフィックスが発表されています。リンクが失敗したMRは、そのプレフィックスを使用しないことを知っていますが、新しい2つのプレフィックスのいずれかを決定するのに十分な情報がありません。COA。そのような場合、MRがリンクが機能しなくなったことを発見したときに、MRが独自のプレフィックスを撤回できるようにするためにメカニズムが必要です。
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
Thierry Ernst INRIA INRIA Rocquencourt Domaine de Voluceau B.P. 105 Le Chesnay 78153 France
Thierry Ernst Inria Inria Rocquencourt Domaine de Voluceau B.P.105 Le Chesnay 78153フランス
Phone: +33-1-39-63-59-30
Fax: +33-1-39-63-54-91
EMail: thierry.ernst@inria.fr
URI: http://www.nautilus6.org/~thierry
Eun Kyoung Paik KT KT Research Center 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea
Eun Kyoung Paik Kt Kt Research Center 17 Woomyon-Dong、Seocho-gu Seoul 137-792 Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5200
EMail: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
Marcelo Bagnulo Universidad Carlos III de Madrid av。Universidad、30 Leganes、Madrid 28911スペイン
Phone: +34 91624 8837
EMail: marcelo@it.uc3m.es
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への情報をお問い合わせください。