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ベーシックサポート）によってサポートされている関連する問題と併せて説明します。勧告は、これらの問題に対処する方法で提供されています。
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ベーシックサポート（RFC 3963）は、[4]車載埋め込まれたIPネットワークのように、例えば、IPv6の移動網に位置するノードに連続インターネット接続を提供するためにNEMOワーキンググループによって提案された解決策です。 NEMOベーシックサポートソリューションは、非常にこれはモバイルIPv6 [で行われているかのように、インターネットにモバイルネットワーク（NEMO）を接続するモバイルルータ（MRS）と、それぞれのホームエージェント（HAS）との間で双方向トンネルを設定することによって、そうします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の、無線LAN、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
モバイルネットワークは、複数のMRを有する、またはO
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;
NEMOのためのすべての潜在的なマルチホームの構成を決定するために、次に現実のシナリオにおいて有用であり得るこれらのかを識別するためにOであり;
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);
NEMOベーシックサポートの操作でサポートされるように、いくつかのマルチホーム構成を妨げる可能性のある問題を捕捉するために、O。それは必ずしも、（うまくいけば、このメモは、これらの実装に役立つであろう）、それはそれを動作させるために実装までであり得るとしてサポートされていないものは、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.
これらの目的を達成するためには、可能なマルチホーム構成を分類するための分類は、この次のセクション3に例示されている第2に導入シナリオ、その利点、およびこれらの利点を満たすための要件を説明し、関連する問題は、第4節で検討されています。問題はその後の展開シナリオごとにマトリクス状に要約され、および推奨事項は、このメモは、マルチホーム構成のNEMOベーシックサポートの評価と結論第5節ではどこで働いていたとされなければならない課題のどの作られています。代替の分類は、付録に記載されています。
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.
モバイルネットワークがマルチホームされているいくつかの構成があるとして、明確に定義された分類にそれらを分類する必要があります。これは、様々な方法で行うことができます。コンフィギュ指向の分類は、このセクションで説明されています。他の二つの分類法、すなわち、所有権指向のアプローチと問題指向のアプローチは、付録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:
マルチホームの構成は、MRのモバイルネットワークノードに利用可能であるどのように多くのプレフィックス（MNPの）、持ってどのように多くの出力インターフェイス、気付アドレス（CoA）とホームアドレス（HoAと）、存在するどのように多くのMRに応じて分類することができます。など我々は、マルチホーム構成を区別するために、3つの主要なパラメータを使用します。これらのパラメータを使用して、各構成は以下のように「X」、「Y」、「Z」が定義されている3組（X、Y、Z）によって参照されます。
o 'x' indicates the number of MRs where:
O「X」のMR場所の数を示します。
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は、単一のMNP NEMOが使用可能であることを意味します。
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つのパラメータは互いにかなり直交していることがわかります。したがって、3タプル（x、y、z）の異なる組合せで '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つの可能な構成の総数を識別することができます。読者が心に留めておく必要があり一つのことは、以下の8例それぞれに、MRがマルチホームすることができることである場合は、（i）複数のプレフィックスは、（ホームリンク上、または外部リンクで）入手可能であるか、または（ⅱ） MRは、複数のインタフェースを備えています。このような場合には、MRは、複数（のHoA、CoAの）ペアを有するであろう。マルチホームMRに関連する問題は、[7]で扱われています。 「MNP（s）は/ NEMOで利用可能である」、MNP（複数可）のいずれかを明示的ルータ広告を経由してMRが発表した、または動的ホスト構成を通じて利用できるようにすることができるときまた、読者もいることを覚えておいてくださいプロトコル（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を有し、それは、単一のHAに関連した、単一のMNPは、NEMOで利用可能です。 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は、このように、外部リンク上で利用可能なプレフィックスは、NEMOリンクに発表されていない、MRが接続されているリンク上で利用可能なプレフィックスとは無関係です。 MRがそうするように構成されている場合、複数のプレフィックスがホームリンク上で利用可能な場合のために、これらは、NEMOリンク上でのみ発表されています。現在（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.
MNNsについて、彼らは、彼らがに接続されているリンク上で利用できる単一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、HA 1、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）の構成は、唯一のMRは、それが単一のHAに関連付けられており、二つ以上のMNPは、NEMOで利用可能です。
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.
セクション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 from each MNP available on the link.
いくつかのMNPは、それらが結合されているリンク上で利用可能ですのでMNNsについては、それらがマルチホームしています。 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、HA 1、複数の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と単一MNPはNEMOで提供されています。 MRは、しかしながら、複数と関連付けられました。
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がマルチホームされ、それに加えて、セクション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.
MNNsについて、彼らは、彼らがに接続されているリンク上で利用できる単一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）の構成は、唯一のMRを有します。しかしながら、MRが有し、複数のMNP NEMOが使用可能である複数に関連付けられています。
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がマルチホームであるが、加えて、セクション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.
いくつかのMNPは、それらが結合されているリンク上で利用可能ですのでMNNsについては、それらがマルチホームしています。 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を有します。しかし、MR（S）は、単一の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.
それは複数のMRを有するので、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.
MNNsについて、彼らは、彼らがに接続されているリンク上で利用できる単一MNPから単一のグローバルアドレスを設定しますので、（通常は）マルチホームではありません。
MR2
p<-_ |
_ |-|_|-| _____
|_|-| |-| |
_ | | |-| _
|_|-| _ |-|_____| | _ |-|_|
|-|_|-| |-|_|-|
p<- | |
MNNs MR1 Internet AR HA
Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP
図5：（N、1,1）：複数のMR、HA 1、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によってアドバタイズされ、複数のMNPがNEMO内で利用可能です。
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.
それは複数のMRを有するので、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.
いくつかのMNPは、それらが結合されているリンク上で利用可能ですのでMNNsについては、それらがマルチホームしています。 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）：複数のMR、HA 1、複数のMNP
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を有します。同時に複数の関連付けられているモバイルネットワークが有し、単一のMNPは、NEMOで利用可能です。
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.
それは複数のMRを有したので、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.
MNNsについて、彼らは、彼らがに接続されているリンク上で利用できる単一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）複数のMR、複数が有する、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）構成が異なるグローバルルートをアドバタイズする複数のMRを有します。モバイルネットワークは、同時に複数のHAと関連付けられ、複数のMNPは、NEMOで利用可能です。
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.
それは複数のMRを有したので、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.
いくつかのMNPは、それらが結合されているリンク上で利用可能ですのでMNNsについては、それらがマルチホームしています。 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）：複数のMR有し、及びのMNP
The following generic goals and benefits of multihoming are discussed in [6]:
以下の一般的な目標とマルチホーミングの利点は、[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:
例1 O：
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.
デュアル/複数のアクセスインタフェース（例えば、802.11およびGPRS機能）とMR。単一のHAの両方のために使用される場合、これは（1,1、*）です。二つの独立したが、使用されている場合、これは（1、N）の設定です。
Benefits: Ubiquitous Access, Reliability, Load Sharing, Preference Settings, Aggregate Bandwidth.
利点：ユビキタスなアクセス、信頼性、負荷分散、好み設定、総帯域幅。
x=n: Multihomed mobile networks with multiple MRs
X = N：複数のMRを有するマルチホームモバイルネットワーク
o Example 1:
例1 O：
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、*）構成で電車。また、鉄道会社は、このように（N、N、N）の構成、さまざまな国で、HAS異なる使用する場合があります。
Benefits: Ubiquitous Access, Reliability, Load Sharing, Aggregate Bandwidth.
利点：ユビキタスなアクセス、信頼性、負荷分散、総帯域幅。
o Example 2:
例2 O：
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対応携帯電話と無線LAN対応の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:
例1 O：
Most multiple HAs cases in above examples.
ほとんどの倍数は上記の例の場合があります。
o Example 2:
例2 O：
Transatlantic flight with a HA in each continent. This is a (1,n,1) configuration if there is only one MR.
各大陸でのHAとの大西洋横断飛行。唯一のMRが存在する場合、これは（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:
例1 O：
Most multiple HAs cases in above examples.
ほとんどの倍数は上記の例の場合があります。
o Example 2:
例2 O：
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.
自宅から取られた接頭辞を持つカー（個人的なトラフィックは、この接頭辞を使用して送信され、所有者によって支払われる）（保守トラフィックが自動車メーカーによって支払われる）自動車メーカーに属し、1。これは、典型的には、（1,1、N）または（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:
少なくとも一つの双方向トンネルは、すべての期待を満たすためにモバイルネットワークと固定ネットワークとの間の任意の時点で利用可能でなければなりません。ほとんどの目標が有効であるためしかし、複数のトンネルを同時に維持する必要があります。
o Permanent and Ubiquitous Access:
O常設とユビキタスアクセス：
At least one bi-directional tunnel must be available at any point in time.
少なくとも一つの双方向トンネルは、任意の時点で利用可能でなければなりません。
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).
マルチホーミングの目標の一つは、フォールトトレランス機能を提供することです。障害検出、別の利用可能な経路の探索、経路選択、および確立された通信の再ホーミング：そのような機能を提供するために、一連のタスクには、実行する必要があります。これらはまた、SHIM6 WGによって[9]に記載されています。次のサブセクションでは、我々はむしろ一般SHIM6の観点より、NEMOの特定の文脈において、これらの問題を見ている[9]。加えて、いくつかのシナリオでは、また、さらに別のMR（セクション4.4を参照）との間の調整（第4.3節を参照）を有する別間の調整のための機構を提供するために必要とされ得ます。
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マルチホーミングによって提供される保護ドメインは、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との間の単一利用可能です。 NEMOへとからのすべてのトラフィックは、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とのMRが関与する必要があります。これは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異なると異なるMRの間に複数の経路が存在します。また、異なるネットワークに位置し、異なるインターネットアクセスリンクを有していてもよいました。これは、使用されるHAを変更するパスの他の部分に影響を与え、HAとMRとの間のリンクで障害からだけでなく、他の故障モードから回復することを可能にするだけでなく、ことを意味します。この場合、エンド・ツー・エンドの障害検出メカニズムは、追加の保護を提供するであろう。しかし、障害のより高い数は、HAとMRとの間のリンクで発生する可能性があるので、この故障モードのための最適化された故障検出機構を提供することが合理的であってもよいです。 （N、N、N）の場合は、パスの変更に異なるプレフィックス結果を選択するため、ハイブリッドです。この場合、（例えば、[9]で説明したものなど）SHIM6プロトコルは有用であり得ます。
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（S）との間のトンネルの障害の検出を含みます。これは、モバイルホストとそのHAとの間の障害検出の場合と変わりません。そのため、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:
仕事への障害回復、MRのためには最初の障害を検出する手段を持っている必要がありました：
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展開モデルのために、有しており、MRは障害を検出し、トンネルの生存性をチェックするために（例えば、ハートビート信号の一定の伝送のような）独自の方法を使用することができます。加入者モデルにおいて（付録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.
MRには、短い生涯値で、より定期的にバインディングアップデートを送信するための可能な方法があります。同様に、これより頻繁にバインディングアップデートを送信するためのMRを強制的に、より小さな寿命値との結合肯定応答メッセージを返すことができました。これらの結合の更新は、「トンネルハートビート」をエミュレートするために使用することができます。送られた結合更新が保護された（そしておそらく暗号化）されている必要がありましたので、これは、しかし、セキュリティアソシエーションで、より多くのトラフィックと処理のオーバーヘッドにつながる可能性があります。
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へ及びからのすべてのトラフィックは、それを通って流れます。利用可能な代替経路が異なるのMRとHAの間で異なるものです。パス - 探査メカニズムはHAとのMRを伴います。これは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異なると異なるMRの間に複数の経路が存在します。この場合には、代替パスは、互いに完全に独立してルーティングすることができます。エンドツーエンド経路探査メカニズムは、エンドツーエンドのパスのいずれかが利用可能である場合に発見することができるであろう。 （N、N、1）の場合は、しかし、複数のプレフィックスが存在しない、かなりNEMO特異的であると思われます。 （N、N、N）の場合は、パスの変更に異なるプレフィックス結果を選択するため、ハイブリッドです。この場合、（例えば、[9]で説明したものなど）SHIM6プロトコルは有用であり得ます。
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との間の経路探索の場合と変わりません。そのため、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は、ネットワークメディアの利用可能性を検出するための経路探索を行うために、それはまた、時々必要です。これは、検出/ネットワークアタッチメント（DNA）ワーキンググループ[11]によって推奨開発レイヤ2つのトリガー[10]、または他の機構を用いて達成することができます。メディアの可用性を検出する能力は、多くの場合、メディアが利用できないを検出する能力を暗示するので、これは、セクション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.
パス選択機構は、複数の利用可能なパスの中から選択する必要があります。関与ネモマルチホーミング構成に応じて、パスの違いは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.
複数の利用可能なパスは、MRとHAの間のトンネルに異なる場合がNEMOから/へのトラフィックを運ぶために使用。この場合、経路選択は、MR及びNEMOから流れるトラフィックのイントラNEMOルーティングシステムによって行われ、経路選択は、HA及びNEMOに流れるトラフィックのイントラホームネットワークルーティングシステムによって実行されます。
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との間だけトンネル以上が異なっていてもよいです。したがって、関与するエンドポイントとの間の完全に異なるパスです。この場合、前のケースで提示機構に加えて、エンド・ツー・エンドの経路選択のための追加のメカニズムが必要とされ得ます。指定されたアドレスを選択すると、指定されたISPはホームネットワークのサービス提供に関連付けられた所定のプレフィクスを、選択を意味するので、このメカニズムは、ホスト内のソースアドレス選択メカニズムに密接に関連してもよいです。
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.
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.
MR（O）は、（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).
（nは、*、*）場合（[6.3.6デフォルトルータの選択] [12]を参照）には、「デフォルトルータの選択」に基づいてパスを選択することができるはずまたは送信元アドレス」に基づいて：MNN O （*、*、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、および/またはMNNsパスを選択するように調整され、また、利用可能であるべきです。
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つのトンネルが、他のものより先行し、デフォルトのトンネルとして使用される）またはピア・ツー：ピア（何トンネルが互いによりも優先されていない、それらは同一で優先的に使用されています）。双方向トンネルのこの質問は、選択され、そして基づくことになるパラメータのその上に（例えば、モバイルネットワークのうち/に入るフローのタイプ）。
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との間の異なるトンネルの間で選択するためのメカニズムはかなり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.
障害が検出され、利用可能な代替経路が同定された後、再ホーミングイベントは、他の1本のパスからの既存の通信を流用、行われます。このプロセスに関与する前のアイテムと同様、再ホーミング手順は重く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（単数または複数）を含みます。再ホーミング手順は、追加のBUメッセージの交換を含み得ます。これらのメカニズムは、NEMOベーシックサポートおよび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
複数の双方向トンネルが異なる時た終わるときにイングレスフィルタリングメカニズム[14] [15]は、発信パケットをドロップすることができます。異なるのMNPは異なるが持っているによって処理されている場合、これは特に発生する可能性があります。送信元アドレスを持つパケットを特定から構成されている場合
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.
MNPは、その特定のMNPに対応していないHAにトンネルされ、パケットはHAによって、またはホームネットワーク内の境界ルータのいずれかによって破棄されることがあります。
The ingress filtering compatibility issue is heavily dependent on the particular NEMO multihoming configuration:
イングレスフィルタリングの互換性の問題は、特定のNEMOのマルチホーミングの設定に大きく依存しています：
o For the (*,*,1) cases, there is not such an issue, since there is a single MNP.
単一のMNPがあるため、O（*、*、1）の場合、このような問題は存在しません。
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.
イングレスフィルタリングがHAで発生しないであろうけれども、各MRは異なるのMNPを処理しているときにはO（n、1、n）のケースでは、それは、MRので起こり得ます。
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）イングレス・フィルタリングは、いくつかの困難をもたらす場合もあります。およびNEMOからのすべてのトラフィックが単一のMRを介してルーティングされているため（1、N）の場合に、問題が簡略化されます。このような構成は、MRは、イングレスフィルタリングによって課される制約を尊重正しくパケットをルーティングすることを可能にします。 〔7〕に記載されているように、この場合、単一のMRは、マルチホーム移動ノードが直面することがイングレスフィルタリングの問題に直面してもよいです。より複雑な場合は、（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組の間で確立されています。各MR（それぞれP1及びP2）異なるMNPをアドバタイズ。 MNP P1はHA1に登録されており、MNP P2はHA2に登録されています。 P1またはP2のいずれかに自分のアドレスを自動設定するには、このように、MNNsは自由でなければなりません。イングレスフィルタリングは、このように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.
2つのトンネルが利用可能な場合は、O、MNNは、送信元アドレスを持つパケットを転送することはできませんMR2にP1.MNNに等しいです。これは、HA2のイングレスフィルタリングを発生させる（あるいはMR2で）でしょう。これは、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.
HA1へのトンネルが切断された場合はO、通常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.
（*、N、N）の場合のためのネストされたトンネルの利用O。付録Bは、そのようなアプローチを説明します。
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マルチホーミング構成で現れるイングレスフィルタリングの非互換性の問題が（例えば、[16]参照）SHIM6において考慮されたものと同様です。
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つだけHAは積極的に、MNPへのルートをアドバタイズします
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は、（代わりに持っているすべての）唯一のHAにバインディングアップデートメッセージを送信する（*、N *）の構成に必要かもしれません。このような場合には、バインディングアップデート情報を持っている間で同期化する必要があるかもしれません。同期のモードは、一次、二次又はピア・ツー・ピアのいずれであってもよいです。 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だけでなく、NEMOベーシックサポート（[7]でセクション6.2.3を参照）によって対処されなければならない一般的なモビリティの問題です。
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（n、*、1）構成（4.5節にも「プレフィックス委任」を参照）で同じMNPを広告します。
o one MR relaying the advertisement of the MNP from another failed MR in the (n,*,n) configuration; and
O別のMNPの広告を中継する1つのMRは、（N、*、n）の構成でMRに失敗しました。そして
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.
（N、*、*）構成では、等入力インターフェイスからトンネルを作成する、そのようなデータパケットとして中継される必要のMRSすべて、間に中継O。
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を有するマスターMR）又はピア・ツー・ピア（すなわち、MRの間には明確な管理階層が存在しません）。そのようなメカニズムの必要性は、固定ネットワークにおけるマルチルータ部位がルータ同期の同じレベルを必要とするであろうという意味で一般的です。
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の構成で障害公差および障害回復を証明するためのMR-に-MR同期スキームを開発するより差し迫った必要性があるもののしたがって、この問題は、NEMOベーシックサポートに固有ではありません。
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は、異なる経路を介してMNNsに通知しなければなりません。これを達成するために利用可能な同期メカニズムは、しかし、ありません。同期メカニズムがなければ、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はNEMOリンクダウン同じMNPを宣伝するために同期させることができますか？そうするために、MRは何とか同じ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を使用して構成されている場合、それは同じMNPにこれらのCoAをバインドすることがしばしば必要です。
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）の構成では、MNNsは複数のアドレスで構成されることになります。ソースアドレス選択メカニズムは、から選択するためにどのアドレスを決めるために必要とされています。
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).
しかし、現在利用可能なソースアドレス選択メカニズムはMNNsがインテリジェントに（例えば、各MNPのホームネットワークに関連するトラフィック条件に基づいて）その送信元アドレスを選択するために十分な情報を取得することはできません。 MNNsはのMRから各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.
マルチホームのモバイルネットワークは、他のモバイルネットワーク内にネストされている場合、それは非常に複雑なトポロジになります。例えば、階層型移動ネットワークは、このように集約ネットワークは、もはや単純なツリー構造を形成して、二つの異なるルートの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ベーシックサポートに固有のものです。しかし、書き込みの際に、より多くの研究は、マルチホームのモバイルネットワークで発生するループの確率を評価することをお勧めします。関連する作業のために、ネストされた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.
場合（N、*、1）ネットワーク分割は、（すなわち2つのMRは、それ自体を分割）、異なるリンク上のMRは、利用可能なMNPを登録しようとすることができます。 HAは、MNPがどのMRに接続されていることから構成されたアドレスを持つノードを知る方法がないので、これは、許容することができません。 MNPは、いずれかの強制1つ（または全て）のMRから除去するためのいくつかのメカニズムが存在しなければならない、または実装は、（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:
モバイルネットワークがマルチホームである場合、MNNsは、この構成から利益を得ることができるかもしれない、等コスト、伝送遅延、帯域幅に基づいて、使用可能なパスの中から選択するようにしかし、いくつかのケースでは、そのような選択が利用可能にされていません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.
優先設定の一の態様は、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.
優先設定の別の態様は、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のWGのような種々のWGによって検討されています。 MNNsでSHIM6層は、このような能力を有することも可能です。これは、モバイルネットワークにマルチホーミング機能を提供するときに、これらのWGによって開発されたソリューションに調査するベンダーや事業者のために推奨されます。
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は、現在（例えばHAおよびモバイルアンカーポイントとして）[27]フローがフィルタリングエージェントによって転送されるべき方法を指示するモバイルノードに関するフローフィルタリングソリューションを開発しています。フローフィルタリングは、フローがMRによって転送されるべきかを示すために、MNNにより行うことができるようにMonami6 WGは、ここで説明する問題を検討することをお勧めします。
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の展開に影響を与える可能性があるいくつかの問題は、これらが一緒にWG（s）は、各問題の解決策が最もされた適応症で、8つのマルチホーミング構成のそれぞれのために、下記のマトリックスに示されている第4節で同定されました見つけられそう。
+=================================================================+
| # 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マルチホーミング問題のマトリックス
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:
障害検出、パスの探査、パス選択、再ホーミング、イングレスフィルタリング、HA同期、プレフィックス委任、ネストされたNEMO、および接頭辞所有権のループ防止：図10からわかるように、次はNEMOに固有のいくつかの懸念されています。 NEMOの可能な展開の作者の最良の知識に基づいて、それをすることをお勧めします。
o A solution for Failure Detection, Path Exploration, Path Selection, and Re-Homing be solicited from other WGs.
O障害検出、パスの探査、パス選択、および再ホーミングのためのソリューションは、他のWGから募集します。
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.
パス選択は、NEMO固有として図10に反映されているが、問題の技術的検討は、モバイルノードに複数の経路の選択に非常に類似していると考えられています。そのため、私たちは、IETF内の他のWGから、これらの問題に対する解決策を勧誘するためにベンダーをお勧めします。例えば、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）構成が異なるサービスプロバイダが、車両/船舶に自分ののMRをインストールすることができる（例えば、バス、電車など）の質量輸送用車両に想定することができます。
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.
HA同期のO溶液は、モバイルIPv6とのMRを操作両方のモバイルホストは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.
複数のMRおよび単一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ベーシックサポート（RFC 3963）の動作の下でネットワークモビリティのコンテキストでマルチホーミングの分析を発表しました。目的は、モバイルネットワークがマルチホームされ、複数の双方向トンネルがホームエージェントとモバイルルータのペア間で確立され、このような双方向トンネリング機構に関連する問題を調査することでした。そうするために、モバイルネットワークは、8つの可能なマルチホーム構成を備えた分類に分類しました。問題は、一つ一つを説明し、その後、彼らは解決できる最も関連IETFワーキンググループを示唆し、それが適用され、マルチホーム構成を示す表にまとめました。この分析は、マルチホーミングとNEMOベーシックサポートとマルチホーミングに関連するメカニズムの実装にをサポートするために、既存の標準を拡張すると便利でしょう。
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.
著者は、メーリングリストでの様々なマルチホーミング問題についての貴重なコメントを与えている人たちに感謝したいと思い、また、それらの第56回で方向を示唆している人 - 第61回IETFミーティング。マルチホーミング構成にNEMOベーシックサポートの初期評価は、ジュリアン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]のようにして、J.とM.古城、 "モビリティ関連用語"、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.、ペトレスク、A.、およびP. Thubert、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、2005年1月。
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[5]ジョンソン、D.、パーキンス、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]エルンスト、T.、Montavont、N.、Wakikawa、R.、呉、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.、エルンスト、T.、呉、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニーを、 "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マルチホーミングのためのロケータペア探索プロトコル」、進歩、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]クリシュナン、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]ナラヤナン、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.シンプソン、 "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]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス拒否攻撃を破り"、BCP 38、RFC 2827、2000年5月。
[15] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[15]ベイカー、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.とM.マルセロは、進歩、2006年10月に、仕事を "IPv6のイングレスフィルタリングの互換性は、サイトをマルチホーム"。
[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、 "インターホームエージェントプロトコル（HAHA）"、進歩、2004年2月に作業。
[18] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent Protocol", Work in Progress, July 2004.
[18]コ、B.、呉、C.、およびJ.平野、 "ダイナミック・インターホームエージェントプロトコル"、進歩、2004年7月の作業。
[19] Tsukada, M., "Analysis of Multiple Mobile Routers Cooperation", Work in Progress, October 2005.
[19]塚田、M.、「複数のモバイルルータ協力の分析」、進歩、2005年10月に働いています。
[20] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004.
[20]宮川、S.とR. Droms、 "IPv6のプレフィックス委任のための要件"、RFC 3769、2004年6月。
[21] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", Work in Progress, September 2006.
[21] Droms、R.とP. Thubert、 "NEMOのためのDHCPv6のプレフィックス委譲"、進歩、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.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、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.ニコラス、 "ネストニモツリーディスカバリー"、進歩、2006年11月に作業。
[26] Kumazawa, M., "Token based Duplicate Network Detection for split mobile network (Token based DND)", Work in Progress, July 2005.
[26]熊澤、M.、「スプリットモバイルネットワーク（トークンベースのDND）のトークンベースの重複ネットワーク検出」、進行、2005年7月ワーク。
[27] Soliman, H., "Flow Bindings in Mobile IPv6 and NEMO Basic Support", Work in Progress, March 2007.
[27]ソリマン、H.、「モバイルIPv6とNEMOベーシックサポートで流れバインディング」、進歩、2007年3月に作業。
Appendix A. Alternative Classifications Approach
付録A.代替分類アプローチ
A.1. Ownership-Oriented Approach
A.1。所有権指向のアプローチ
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'.
マルチホームのモバイルネットワークを分類するための別のアプローチは、所有権に基づくマルチホームネットワークの分類を壊すことにより、エリックNordmarkと（サン・マイクロシステムズ）によって提案されました。これは、ツリー状、トップダウンの分類の詳細です。 HA（S）およびMR（S）の制御及び所有権から出発して、二つの異なる可能性がある：（i）HA（S）およびMR（複数可）は、単一のエンティティによって制御されているか、または（II）のHA（S）およびMR（S）は別々のエンティティによって制御されます。私たちは、第一の可能性「ISPモデル」、および2番目の「加入者/プロバイダーモデル」と呼ばれます。
A.1.1. ISP Model
A.1.1。 ISPモデル
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（S）の場合、同じエンティティによって制御される最高の列車、船舶、又は平面上のMRを設置するインターネットサービスプロバイダ（ISP）のように示すことができます。これは、モバイルネットワークの特定の構成を展開するISP次第です。すべての8つの構成は、コンフィギュレーション指向のアプローチで説明したように、可能です。この文書の残りの部分では、具体的には単一のエンティティによって制御されるモバイルネットワークの構成に言及するとき、我々は、「ISP」接頭辞を追加します。例えば、ISP-（1,1,1）又はISP-（1、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は、それがために同じ決定をすることができると同じように、モバイルネットワークに一つまたは複数のMNPを割り当てることを望んでいるかどうかを決定することができますそのネットワーク内の他のリンク（あるいは有線又は）。いずれの場合においても、ISPは、ワーク（例えばているように）モバイルネットワークとコア・ルータ間のルーティングを行います。これは、MNP（S）のルーティングアナウンスメントを除外しますたとの間の任意の集合を、導入しないことを含みます。
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）を実行することができます。あるいは、静的ルートはトンネルで使用されてもよいです。スタティックルートが使用される場合、「トンネルライブネス」をテストするメカニズムは、古いルートを維持回避するために必要かもしれません。そのような「トンネルライブネスは」HA（単数または複数）にMR（S）からのハートビート信号を送信することによって試験することができます。可能性は、定期的にバインディング更新メッセージを送信するためにMRを強制的にBinding Acknowledgementメッセージの「寿命」フィールドを制御することによって、バインディングアップデートメッセージを使用してハートビートをシミュレートすることです。それがバインディング更新メッセージに比べて幾分二役割を果たすので、バインディングリフレッシュ要求メッセージへの適合性がより少ない厳密な実装に適用することができるもののしかし、より適切なツールは、バインディングリフレッシュ要求メッセージであるかもしれません。
A.1.2. Subscriber/Provider Model
A.1.2。加入者/プロバイダーモデル
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）の場合は、最良のMRは、単一の加入者に属し、HAサービスのための1つ以上のISPに加入する加入者/プロバイダモデルを用いて示すことができます。加入者が複数のISPに加入するとき、加入者は、単一のISPに加入し、そして場合：この場合、2つのサブカテゴリーがあります。この文書の残りの部分で、具体的に加入者が一つだけISP、我々は「S / P」プレフィックスを追加するために加入する加入者/プロバイダモデルにあるモバイルネットワークの構成に言及する場合、例えば、S / P-（1,1,1）又はS / P-（1、N）。具体的には、加入者が複数のISPに加入する加入者/プロバイダモデルにあるモバイルネットワークの構成に言及するとき、我々は、「S / MP」プレフィックスを追加します。例えば、S / MP-（1,1,1）又はS / MP-（1、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モデルのために配備される可能性が高いわけではありません。単一のHAがある（*、1,1）モバイルネットワーク - 例えば、S / MPを予測しにくいです。 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）：シングルプロバイダ、単一MR、複数が有する、複数のMNP
o S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single MNP
O S / P-（N、N、1）：シングルプロバイダ、複数のMR、シングルHA、シングルMNP
o S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple MNPs
O S / P-（N、1、N）：シングルプロバイダ、複数のMR、シングルHA、複数のMNP
o S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single MNP
O S / P-（N、N、1）：シングルプロバイダ、複数のMR有する複数のシングルMNP
o S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple MNPs
O S / P-（N、N、N）：シングルプロバイダ、複数のMR、複数有し、複数の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）：複数のプロバイダ、単一MR、複数有し、複数のMNP
o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs, Multiple MNPs
O S / MP-（N、N、N）：複数のプロバイダ、複数のMR、複数有し、複数の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（S）は異なるエンティティによって制御される場合には、MRは、1つのエンティティ（すなわち、加入者）によって制御される可能性が高い、そしてMRは1つまたは複数に複数の双方向トンネルを確立しています一つ以上のISP（S）によって提供されるHA（S）。このような場合には、ISPが最も確かにそのルーティングドメインの完全な制御を保持したいだろうので、ISPは、双方向トンネルの上にIGPを実行することはほとんどありません。
A.2. Problem-Oriented Approach
A.2。問題指向のアプローチ
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:
第三のアプローチは、パスカルThubert（シスコシステムズ）によって提案されました。これは、マルチホームのモバイルネットワークの問題ではなく、設定や所有権に焦点を当てました。 HASの数、およびアドバタイズのMNPの数：このアプローチでは、二つの直交するパラメータに基づいて、4つのカテゴリのセットがあります。 2つのパラメータは直交しているので、カテゴリは相互に排他的ではありません。 4つのカテゴリがあります。
o Tarzan: Single HA for Different CoAs of Same MNP
Oターザン：同じMNPの異なるCoAを用シングルHA
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人のMRが同一のサブネットプレフィックスの同じHAに別のCoAを登録する場合です。これは、Y = 1、すなわち、（1,1、*）モバイルネットワークの場合に相当します。
o JetSet: Multiple HAs for Different CoAs of Same MNP
JETSET O：複数の同じMNPの異なるCoAをためています
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は異なるのCoAを登録する場合です。これは、Y = N、即ち、（1、N、*）モバイルネットワークの場合に相当します。
o Shinkansen: Single MNP Advertised by MR(s)
O新幹線：MRによる単一MNPアドバタイズ（S）
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が異なるのMRが発表された場合です。これは、x = nおよびZ = 1、すなわち、（N、*、1）モバイルネットワークの場合に相当します。
o DoubleBed: Multiple MNPs Advertised by MR(s)
O DoubleBed：MRによってアドバタイズ複数のMNPを（S）
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.
これは、複数ののMNPが異なるのMRが発表されている場合です。これは、x = nおよびZ = N、即ち、（N、*、n）はモバイルネットワークの場合に相当します。
Appendix B. Nested Tunneling for Fault Tolerance
フォールトトレランスのための付録B.入れ子のトンネル
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.
マルチホーミングによって提供される追加の堅牢性を利用するために、それらのHASとの双方向トンネリングを使用するMRは、動的にリンク状態に応じて、そのトンネルの出口点を変更しなければなりません。 MRは、その出力インターフェイスのいずれかがダウンしていることを検出した場合、例えば、それは世界的なインターネットへの代替ルートが存在するかどうかを検出すべきです。この代替ルートは、グローバルなインターネットへの独立経路を有し、その入力インターフェイスの一つ、又はMR自身が所有する別のアクティブなイグレスインタフェースによって接続された他のMRによって提供されてもよいです。そのような代替経路が存在する場合、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]。
B.1. Detecting Presence of Alternate Routes
B.1。代替経路の存在を検出します
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に構成することができます。 MRは、柔軟性のために自動的に代替ルートを発見できるようにするためしかし非常に望ましいです。
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は、それがグローバルなインターネットへの複数の経路を有する「実現」することができなければならないので、MRは、（そうでなければ、同じHAまたはに結合した）複数のイグレスインタフェースを有している場合は、自明であるべきです。
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
複数のMRは、モバイルネットワーク上にある場合には、各MRは、他のMRの存在を検出しなければなりません。 MRは、その*の侵入*インターフェイス上でルータアドバタイズメントメッセージを聞くことによってそれを行うことができます。 MRは、非ゼロのルータにルータ広告メッセージを受信した場合
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.
その入力インターフェイスのいずれかからライフタイムフィールドは、それがグローバルなインターネットへの代替経路を提供することができる別のMRが移動ネットワーク内に存在することを知っています。
B.2. Re-Establishment of Bi-Directional Tunnels
B.2。再確立双方向トンネルの
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によって提供される代替経路として後者のケースとして前者の場合を指します。
B.2.1. Using Alternate Egress Interface
B.2.1。代替出口インタフェースの使用
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は、その代替イグレスインタフェースを利用することができます。そうするための最も直接的な方法は、別の出力インターフェイス上でのCoAを使用して、双方向トンネリングを再確立するために、別のインターフェイスに割り当てられたCoAを使用して失敗したインターフェイスのHAにバインディングアップデートを送信するMRのためであります。成功したバインディング更新した後、MRは、代替イグレスインタフェースを使用して、双方向トンネルを介して送信パケットをカプセル化します。
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）のCoAを使用することです。
B.2.2. Using Alternate Mobile Router
B.2.2。代替モバイルルータを使用して
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は、そのHAとの双方向トンネルを再確立するために（存在する場合）の代替MRによって提供される経路を利用することができます。まず、MRは、代替MR（即ち、交互のMRにそれ自体をアタッチ）からCoAを取得しなければなりません。次に、代替の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.
アイデアは、そのHAとの双方向トンネルを再確立するためにMRのCoAを代替MRからCoAを取得し、新しい（バックアップ）としてこれを使用することです。
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.
MNNsとその通信員ノードの間で送信されるすべてのパケットをカプセル化の二つのレベルを経験することに注意してください。トンネリングの最初のレベルはMNNがデフォルトルータとMRのHAとして使用するMRとの間で発生します。トンネルの第二のレベルは、代替MRとHAとの間で発生します。
B.3. To Avoid Tunneling Loop
B.3。トンネリングループを避けるために、
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人のMRが同時にグローバルなインターネットへの接続を失い、各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).
トンネリングループを回避するための一つのアプローチは、それが定期的に放送するRouter Advertisementメッセージにオプションを挿入するためにグローバルなインターネットへの接続を失ったMRのためです。このオプションは、送信者は、もはや世界的な接続を提供するリンク上の他のMRを通知するのに役立ちます。それはあまりにも彼らのデフォルトルータとしてMRの使用を停止するMRに添付されているMNNsの原因となりますので、ゼロルータ寿命フィールドを設定するとうまく動作しないことに注意してください（その場合には、物事は振り出しに戻っています）。
B.4. Points of Considerations
B.4。検討事項のポイント
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では、MRは、ルータ広告を使用して、他のMRの存在を検出することが示唆されました。しかし、ルータ広告リンクがスコープであるため、複数のリンクがある場合、一部の情報が失われることがあります。例えば、そこ3つのMR 3つの異なるプレフィックスであり、各MRは、間に正規のルータと異なるリンクである場合を考えます。今だけ、単一のMRが動作していると仮定。他のMRは、彼らが新しいCoAを構成するために使用する必要がどのプレフィックスかを識別していますか？この場合、発表されている3つの接頭辞があり、そしてそのリンク失敗したMRは、その接頭辞が使用されるようにされていないことを知っているが、それは新しいを設定するために使用する他の2つのプレフィックスのどちらかを決定するのに十分な情報を持っていませんアシルCoA。このような場合には、この機構は、そのリンクがもはや機能していることを発見していないとき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
チャン・ワウ呉パナソニックシンガポール研究所Pte株式会社BLK 1022タイセンアベニュー＃06から3530タイセン工業団地シンガポール534415 SG
Phone: +65 65505420 EMail: chanwah.ng@sg.panasonic.com
電話：+65 65505420 Eメール：chanwah.ng@sg.panasonic.com
Thierry Ernst INRIA INRIA Rocquencourt Domaine de Voluceau B.P. 105 Le Chesnay 78153 France
ティエリーエルンストINRIA INRIA Rocquencourtドメーヌ・デ・Voluceau PB 105 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
電話：+ 33-1-39-63-59-30ファックス：+ 33-1-39-63-54-91 Eメール：URI thierry.ernst@inria.fr：http://www.nautilus6.org/~ティエリー
Eun Kyoung Paik KT KT Research Center 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea
恩京パイクKT KT研究センター17 Woomyeon洞、瑞草区ソウル137から792韓国
Phone: +82-2-526-5233 Fax: +82-2-526-5200 EMail: euna@kt.co.kr URI: http://mmlab.snu.ac.kr/~eun/
電話：+ 82-2-526-5233ファックス：+ 82-2-526-5200 Eメール：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
マドリードのマルセロBagnuloチャールズIII大学のAv。大学、30のレガネス、マドリード28911スペイン
Phone: +34 91624 8837 EMail: marcelo@it.uc3m.es
電話：+34 91624 8837 Eメール：marcelo@it.uc3m.es
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。