[要約] 要約：RFC 3178は、IPv6マルチホーミングをサポートするためのサイト出口ルーターに関するガイドラインです。 目的：このRFCの目的は、IPv6ネットワークにおいてサイト出口ルーターでのマルチホーミングをサポートするための手法とプロトコルを提供することです。
Network Working Group J. Hagino
Request for Comments: 3178 Research Laboratory, IIJ
Category: Informational H. Snyder
Vail Systems
October 2001
IPv6 Multihoming Support at Site Exit Routers
サイト出口ルーターでのIPv6マルチホームサポート
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. Unlike currently-practiced IPv4 multihoming, the technique does not impact the worldwide routing table size, nor IGP (Interior Gateway Protocol) routing table size in upstream ISPs. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC 2260 by Tony Bates.
このドキュメントは、基本的なIPv6マルチホームサポートのメカニズムとその運用要件について説明しています。現在実践されているIPv4マルチホミングとは異なり、この手法は世界的なルーティングテーブルサイズに影響を与えません。また、上流のISPでテーブルサイズをルーティングするIGP（インテリアゲートウェイプロトコル）もありません。このメカニズムは、より洗練された（または複雑な）マルチホームサポートメカニズムと組み合わせることができ、他のメカニズムの基礎として使用できます。このドキュメントは、主にTony BatesによるRFC 2260に基づいています。
Routing table size has been a major issue for both IPv4 and IPv6. As IPv6 addresses are 4 times larger in bit width than IPv4, the routing table size issue would have more serious negative effects on router memory usage, as well as routing table lookup performance. To cope with this problem, the IPv6 addressing architecture [Hinden, 1998] is designed to take advantage of aggregated routing announcements to reduce the number of routes in default-free zone. Also, 6bone operation guideline [Rockell, 2000] (which is the currently-practiced guideline for IPv6 network operation) suggests that ASes not announce non-aggregatable announcements to the default-free zone, if there is no special agreement with the peer.
ルーティングテーブルサイズは、IPv4とIPv6の両方にとって大きな問題です。IPv6アドレスはIPv4のビット幅が4倍大きいため、ルーティングテーブルサイズの問題は、ルーターメモリの使用量とルーティングテーブルルックアップのパフォーマンスに深刻な悪影響を及ぼします。この問題に対処するために、IPv6アドレス指定アーキテクチャ[Hinden、1998]は、デフォルトのないゾーンのルート数を減らすために集約されたルーティングアナウンスを活用するように設計されています。また、6bone運用ガイドライン[Rockell、2000]（これは、IPv6ネットワーク操作の現在実践されているガイドラインです）は、ASEがピアとの特別な合意がない場合、デフォルトのないゾーンへの凝集不可能な発表を発表しないことを示唆しています。
In IPv4, a multihomed site uses either of the following techniques to achieve better reachability: o Obtain a portable IPv4 address prefix, and announce it from multiple upstream providers.
IPv4では、マルチホームのサイトが次の手法のいずれかを使用して、より良い到達可能性を実現します。oポータブルIPv4アドレスプレフィックスを取得し、複数の上流プロバイダーから発表します。
o Obtain a single IPv4 address prefix from ISP A, and announce it from multiple upstream providers the site is connected to.
o ISP Aから単一のIPv4アドレスプレフィックスを取得し、サイトが接続されている複数の上流プロバイダーから発表します。
Since the above two methodologies effectively inject additional routes to the worldwide routing table, they have negative impact on the worldwide routing table size issue. They also are not compatible with current IPv6 operational practice.
上記の2つの方法論は、世界のルーティングテーブルに追加のルートを効果的に注入するため、世界的なルーティングテーブルサイズの問題に悪影響を及ぼします。また、現在のIPv6運用慣行と互換性がありません。
This document provides a way to configure site exit routers and ISP routers, so that the site can achieve better reachability from multihomed connectivity, without impacting worldwide routing table size issues. The technique uses multiple distinct IPv6 address prefixes, assigned from multiple upstream ISPs. The technique uses an already-defined routing protocol (BGP or RIPng) and tunneling of IPv6 packets; therefore, this document introduces no new protocol standard (the document describes how to operate the configuration).
このドキュメントは、サイトの出口ルーターとISPルーターを構成する方法を提供します。そうすれば、世界のルーティングテーブルサイズの問題に影響を与えることなく、マルチホームの接続からより良い到達可能性を実現できます。この手法では、複数の上流ISPから割り当てられた複数の異なるIPv6アドレスプレフィックスを使用します。この手法は、すでに定義されているルーティングプロトコル（BGPまたはRIPNG）とIPv6パケットのトンネルを使用します。したがって、このドキュメントでは新しいプロトコル標準は導入されません（ドキュメントでは、構成の操作方法について説明します）。
This document is largely based on RFC 2260 [Bates, 1998] by Tony Bates.
このドキュメントは、主にTony BatesによるRFC 2260 [Bates、1998]に基づいています。
The goal of this document is to achieve better packet delivery from a site to the outside, or from the outside to the site, even when some of the site exit links are down.
このドキュメントの目標は、サイトの出口リンクの一部がダウンしている場合でも、サイトから外側、または外側から外側からサイトへのより良いパケット配信を実現することです。
Non goals are:
非目標は次のとおりです。
o Choose the "best" exit link as possible. Note that there can be no common definition of the "best" exit link.
o 可能な限り「最適な」出口リンクを選択します。「最良の」出口リンクの一般的な定義はないことに注意してください。
o Achieve load-balancing between multiple exit links.
o 複数の出口リンク間の負荷分散を達成します。
o Cope with breakage of any of the upstream ISPs.
o 上流ISPのいずれかの破損に対処します。
We use the technique described in RFC 2260 section 5.2 in our configuration. To summarize, for IPv4-only networks, RFC 2260 says that:
構成のRFC 2260セクション5.2で説明されている手法を使用します。要約すると、IPv4のみのネットワークの場合、RFC 2260は次のように述べています。
o We assume that our site is connected to 2 ISPs, ISP-A and ISP-B.
o 私たちのサイトは、ISP-AとISP-Bの2つのISPに接続されていると仮定します。
o We are assigned IP address prefixes, Pref-A and Pref-B, from ISP-A and ISP-B respectively. Hosts near ISP-A will get an address from Pref-A, and vice versa.
o ISP-AとISP-Bから、それぞれIPアドレスプレフィックス、Pref-AおよびPref-Bが割り当てられています。ISP-Aの近くのホストは、Pref-Aからアドレスを取得し、その逆も同様です。
o In the site, we locally exchange routes for Pref-A and Pref-B, so that hosts in the site can communicate with each other without using external link.
o サイトでは、Pref-AとPref-Bとローカルでルートを交換しているため、サイト内のホストが外部リンクを使用せずに相互に通信できます。
o ISP-A and our site are connected by a "primary link" between ISP router ISP-BR-A and our router E-BR-A. ISP B and our site are connected by a primary link between ISP router ISP-BR-B and our router E-BR-B.
o ISP-Aと当社のサイトは、ISPルーターISP-BR-AとルーターE-BR-Aの間の「一次リンク」で接続されています。ISP Bと当社のサイトは、ISPルーターISP-BR-BとルーターE-BR-Bの間の主要なリンクによって接続されています。
(ISP A) (ISP B)
（ISP A）（ISP B）
ISP-BR-A ISP-BR-B
| |
|Primary link |
| |
| |
+---|-----------------------------|--+
| E-BR-A E-BR-B |
| |
| Pref-A <----------> Pref-B |
+------------------------------------+
o Establish a secondary link, between ISP-BR-A and E-BR-B, and ISP-BR-B and E-BR-A, respectively. The secondary link usually is an IP-over-IP tunnel. It is important to have the secondary link on top of a different medium than the primary link, so that one of them survives link failure. For example, the secondary link between ISP-BR-A and E-BR-B should go through a different medium than the primary link between ISP-BR-A and E-BR-A. If the secondary link is an IPv4-over-IPv4 tunnel, the tunnel endpoint at E-BR-A needs to be an address in Pref-A, not in Pref-B (tunneled packet needs to travel from ISP-BR-B to E-BR-A, over the primary link between ISP-BR-A and E-BR-A).
o ISP-Br-AとE-Br-B、およびISP-Br-BとE-Br-Aの間にそれぞれ二次リンクを確立します。セカンダリリンクは通常、IPオーバーIPトンネルです。プライマリリンクとは異なる媒体の上にセカンダリリンクを置くことが重要です。そうすれば、そのうちの1つがリンクの障害に耐えることができます。たとえば、ISP-BR-AとE-BR-Bの間の二次リンクは、ISP-BR-AとE-BR-Aの間の主要なリンクとは異なる媒体を通過する必要があります。セカンダリリンクがIPv4-over-IPV4トンネルである場合、e-br-aのトンネルエンドポイントは、プリフェートBではなく、プリフェイのアドレスである必要があります（トンネルパケットはISP-br-bから移動する必要があります。E-BR-A、ISP-BR-AとE-BR-Aの間の主要なリンク上。
(ISP A) (ISP B)
（ISP A）（ISP B）
ISP-BR-A ISP-BR-B
| | | |
| \-----------------------+ | |
| Secondary link | | |
| +----------------------|-/ |
| | | |
| | | |
| | | |
| | | |
+---|--|----------------------|---|--+
| E-BR-A E-BR-B |
| |
| |
+------------------------------------+
o For inbound packets, E-BR-A will advertise (1) Pref-A toward ISP-BR-A with strong preference the over primary link, and (2) Pref-B toward ISP-BR-B with weak preference over the secondary link. Similarly, E-BR-B will advertise (1) Pref-B toward ISP-BR-B with strong preference over the primary link, and (2) Pref-A toward ISP-BR-A with weak preference over the secondary link.
o インバウンドパケットの場合、e-br-aは（1）プリマーリンクよりも強い好みを持つISP-br-aに対して（1）プレフ-aを宣伝し、（2）ISP-bに対するプリフ-Bに対して、セカンダリよりも弱い優先度を持つリンク。同様に、E-BR-Bは、ISP-BR-Bに向かって（1）プリフ-Bを主要なリンクよりも強い好みで宣伝します。
Note that we always announce Pref-A to ISP-BR-A, and Pref-B to ISP-BR-B.
ISP-Br-AからPREF-A、およびPREF-BからISP-Br-Bに常に発表することに注意してください。
o For outbound packets, ISP-BR-A will advertise (1) default route (or specific routes) toward E-BR-A with strong preference over the primary link, and (2) default route (or specific routes) toward E-BR-B with weak preference over the secondary link. Similarly, ISP-BR-B will advertise (1) default route (or specific routes) toward E-BR-B with strong preference over the primary link, and (2) default route (or specific routes) toward E-BR-A with weak preference over the secondary link.
o アウトバウンドパケットの場合、ISP-BR-Aは（1）プライマリリンクよりも強い好みを持つデフォルトルート（または特定のルート）をE-BR-Aに宣伝し、（2）E-BRへのデフォルトルート（または特定のルート）を宣伝します。-bセカンダリリンクよりも好みが弱い。同様に、ISP-BR-Bは、（1）プライマリリンクよりも強い優先度を持つ（1）デフォルトルート（または特定のルート）をE-BR-Bに向けて宣伝し、（2）E-BR-Aへのデフォルトルート（または特定のルート）を宣伝します。セカンダリリンクよりも弱い好みがあります。
Under this configuration, both inbound and outbound packets can survive link failure on either side. Routing information with weak preference will be available as backup, for both inbound and outbound cases.
この構成では、インバウンドパケットとアウトバウンドパケットの両方が、両側のリンク障害に耐えることができます。嗜好が弱いルーティング情報は、インバウンドとアウトバウンドの両方の場合に対して、バックアップとして利用できます。
RFC 2260 is written for IPv4 and BGP. With IPv6 and BGP4+, or IPv6 and RIPng, similar results can be achieved, without impacting worldwide IPv6 routing table size.
RFC 2260は、IPv4およびBGP用に記述されています。IPv6およびBGP4、またはIPv6およびRIPNGでは、世界中のIPv6ルーティングテーブルサイズに影響を与えることなく、同様の結果を達成できます。
In RFC 2260, we announce Pref-A toward ISP-BR-A only, and Pref-B toward ISP-BR-B only. Therefore, there will be no extra routing announcement to the outside of the site. This meets the suggestions in 6bone aggregation guidelines [Rockell, 2000]. Also, RFC 2260 does not require portable addresses.
RFC 2260では、ISP-Br-Aのみに向けて、ISP-BR-Bのみにプリフェを発表します。したがって、サイトの外側への追加のルーティングアナウンスはありません。これは、6bone集合ガイドラインの提案を満たしています[Rockell、2000]。また、RFC 2260はポータブルアドレスを必要としません。
In IPv4, it is usually assumed that a node will be assigned a single IPv4 address. Therefore, RFC 2260 assumed that addresses from Pref-A will be assigned to nodes near E-BR-A, and vice versa (second bullet in the previous section).
IPv4では、通常、ノードに単一のIPv4アドレスが割り当てられると想定されています。したがって、RFC 2260は、Pref-AのアドレスがE-BR-A近くのノードに割り当てられ、その逆（前のセクションの2番目の弾丸）が割り当てられると仮定しました。
With IPv6, multiple IPv6 addresses can be assigned to a node. So we can assign (1) one address from Pref-A, (2) one address from Pref-B, or (3) addresses from both prefixes, to a single node in the site. This will allow more flexibility in node configuration.
IPv6を使用すると、複数のIPv6アドレスをノードに割り当てることができます。したがって、（1）pref-a、（2）pref-bの1つのアドレス、または（3）両方のプレフィックスからの1つのアドレス、サイト内の単一のノードに1つのアドレスを割り当てることができます。これにより、ノード構成の柔軟性が向上します。
When multiple IPv6 global addresses are assigned to an IPv6 node, source address selection must take place on packet transmissions. Source address selection itself is out of scope of the document. Refer to a separate draft [Draves, 2001] for more discussions.
複数のIPv6グローバルアドレスがIPv6ノードに割り当てられている場合、パケット送信でソースアドレスの選択を行う必要があります。ソースアドレスの選択自体は、ドキュメントの範囲外です。詳細については、別のドラフト[Draves、2001]を参照してください。
One simplifying approach is to place the site's Internet hosts on separate subnets, one with addresses in Pref-A and connected to E-BR-A, the other having addresses in Pref-B and connected to E-BR-B. This approach generalizes to having E-BR-A and E-BR-B at different sites, where site A and site B have links to the Internet and to each other.
単純化されたアプローチの1つは、サイトのインターネットホストを別々のサブネットに配置することです。1つはPref-Aにアドレスを備え、E-BR-Aに接続され、もう1つはPref-Bにアドレスを持ち、E-BR-Bに接続します。このアプローチは、サイトAとサイトBがインターネットと互いにリンクを持っているさまざまなサイトでE-BR-AとE-BR-Bを持つことに一般的です。
With IPv6, the primary link can be IPv6 native connectivity, RFC 2893 [Gilligan, 2000] IPv6-over-IPv4 configured tunnel, 6to4 [Carpenter, 2000] IPv6-over-IPv4 encapsulation, or some others.
IPv6を使用すると、主要なリンクはIPv6ネイティブ接続、RFC 2893 [Gilligan、2000] IPv6-Over-IPV4構成トンネル、6to4 [Carpenter、2000] IPv6-over-IPV4エンカプセーションなどです。
If tunnel-based connectivity is used in some of primary links, administrators may want to avoid IPv6-over-IPv6 tunnels for secondary links. For example, if:
トンネルベースの接続性がいくつかの主要なリンクで使用されている場合、管理者は二次リンクのためにIPv6-over-IPv6トンネルを避けたい場合があります。たとえば、場合：
o primary links to ISP-A and ISP-B are RFC 2893 IPv6-over-IPv4 tunnels, and
o ISP-AおよびISP-Bへの主要なリンクは、RFC 2893 IPv6-Over-IPV4トンネルであり、
o ISP-A, ISP-B and the site have IPv4 connectivity with each other.
o ISP-A、ISP-B、およびサイトには、互いにIPv4接続があります。
It makes no sense to configure a secondary link by IPv6-over-IPv6 tunnel, since it will actually be IPv6-over-IPv6-over-IPv4 tunnel. In this case, IPv6-over-IPv4 tunnel should be used for secondary link. IPv6-over-IPv4 configuration has a big advantage against IPv6-over-IPv6-over-IPv4 configuration, as secondary link will be able to have the same path MTU than the primary link.
IPv6-over-IPv6トンネルによってセカンダリリンクを構成することは意味がありません。これは、実際にはIPv6-over-ipv6-over-ipv4トンネルになるためです。この場合、IPv6-Over-IPV4トンネルは、セカンダリリンクに使用する必要があります。IPv6-over-IPV4構成は、IPv6-over-ipv6-over-ipv4構成に対して大きな利点があります。これは、セカンダリリンクがプライマリリンクと同じパスMTUを持つことができるためです。
In the figure, ISP-BR-A and E-BR-A are both single points of failure for inbound traffic to Pref-A. This could be remedied by using different routers for primary vs. backup links.
図では、ISP-BR-AとE-BR-Aはどちらも、PREF-Aへのインバウンドトラフィックの単一の障害点です。これは、プライマリとバックアップリンクに異なるルーターを使用することで改善できます。
The RFC 2260 approach on top of IPv6 will work fine as documented in RFC 2260. There will be no extra twists necessary. Since the multihomed site is not doing transit, variations are possible that do not require it to have a public AS number.
IPv6の上にあるRFC 2260アプローチは、RFC 2260で文書化されているように正常に動作します。追加のひねりは必要ありません。マルチホームのサイトはトランジットを行っていないため、バリエーションが可能である可能性があります。
It is possible to run an RFC 2260-like configuration with RIPng [Malkin, 1997] , with careful control of metric. Routers in the figure need to increase RIPng metric on the secondary link, to make the primary link a preferred path.
メトリックを慎重に制御して、RIPNG [Malkin、1997]を使用してRFC 2260のような構成を実行することができます。図のルーターは、プライマリリンクを優先パスにするために、セカンダリリンクのRIPNGメトリックを増やす必要があります。
If we denote the RIPng metric for route announcement, from router R1 toward router R2, as metric(R1, R2), the invariants that must hold are:
ルーターR1からルーターR2へのルートアナウンスのRIPNGメトリックを指標（R1、R2）として示す場合、保持しなければならない不変剤は次のとおりです。
o metric(E-BR-A, ISP-BR-A) < metric(E-BR-B, ISP-BR-A)
o メトリック（ESBR-A、ISP-BR-AO）<メトリック（ESBR-B、ISP-BR-A）
o metric(E-BR-B, ISP-BR-B) < metric(E-BR-A, ISP-BR-B)
o メトリック（e-br-b、ISP-br-b）<メトリック（e-br-a、isp-br-b）
o metric(ISP-BR-A, E-BR-A) < metric(ISP-BR-A, E-BR-B)
o メトリック（ISP-BR-A、E-BR-A）<メトリック（ISP-BR-A、E-BR-B）
o metric(ISP-BR-B, E-BR-B) < metric(ISP-BR-B, E-BR-A)
o メトリック（ISP-BR-B、E-BR-B）<メトリック（ISP-BR-B、E-BR-A）
Note that smaller metric means stronger route in RIPng.
メトリックが小さいことは、RIPNGのより強いルートを意味することに注意してください。
If the upstream ISP imposes ingress filters [Ferguson, 1998] to outbound traffic, the story becomes much more complex. A packet with source address taken from Pref-A must go out from ISP-BR-A. Similarly, a packet with source address taken from Pref-B must go out from ISP-BR-B. Since none of the routers in the site network will route packets based on source address, packets can easily be routed to incorrect border router.
アップストリームISPがイングレスフィルターを課し[Ferguson、1998]、ストーリーがはるかに複雑になります。Pref-aから取得したソースアドレスを備えたパケットは、ISP-BR-Aから出て行く必要があります。同様に、Pref-Bから取得したソースアドレスを備えたパケットは、ISP-BR-Bから出て行く必要があります。サイトネットワーク内のルーターは、ソースアドレスに基づいてパケットをルーティングするものではないため、パケットを簡単にルーティングしてボーダールーターを誤ってルーターにすることはできません。
One possible way is to negotiate with both ISPs, to allow both Pref-B and Pref-A to be used as source address. This approach does not work if upstream ISP of ISP-A imposes ingress filtering. Since there will be multiple levels of ISP on top of ISP-A, it will be hard to understand which upstream ISP imposes the filter. In reality, this problem will be very rare, as ingress filter is not suitable for use in large ISPs where smaller ISPs are connected beneath.
可能な方法の1つは、両方のISPと交渉し、FREG-BとPREF-Aの両方をソースアドレスとして使用できるようにすることです。ISP-Aの上流ISPが侵入フィルタリングを課す場合、このアプローチは機能しません。ISP-Aの上にISPの複数のレベルがあるため、どのアップストリームISPがフィルターを課すかを理解することは困難です。現実には、この問題は非常にまれです。イングレスフィルターは、より小さなISPが下に接続されている大きなISPで使用するのに適していないからです。
Another possibility is to use source-based routing at E-BR-A and E-BR-B. Here we assume that IPv6-over-IPv6 tunnel is used for secondary links. When an outbound packet arrives to E-BR-A with source address in Pref-B, E-BR-A will forward it to the secondary link (tunnel to ISP-BR-B) based on source-based routing decision. The packet will look like this:
別の可能性は、e-br-aおよびe-br-bでソースベースのルーティングを使用することです。ここでは、IPv6-Over-IPV6トンネルがセカンダリリンクに使用されると仮定します。Pref-Bのソースアドレスを使用して、アウトバウンドパケットがe-Br-Aに到着すると、e-br-aはソースベースのルーティング決定に基づいてセカンダリリンク（ISP-BR-Bへのトンネル）に転送します。パケットは次のようになります：
o Outer IPv6 header: source = address of E-BR-A in Pref-A, dest = ISP-BR-B
o 外側のIPv6ヘッダー：Source = e-br-aのアドレスpref-a、dest = isp-br-b
o Inner IPv6 header: source = address in Pref-B, dest = final dest
o 内側のIPv6ヘッダー：Source =アドレスプリフェ-B、dest = final dest
A tunneled packet will travel across ISP-BR-A toward ISP-BR-B. The packet can go through ingress filter at ISP-BR-A, since it has outer IPv6 source address in Pref-A. The packet will reach ISP-BR-B and be decapsulated before ingress filter is applied. Decapsulated packet can go through ingress filter at ISP-BR-B, since it now has source address in Pref-B (from inner IPv6 header). Notice the following facts when configuring this:
トンネルパケットは、ISP-Br-Bに向かってISP-Br-Bに向かって移動します。パケットは、ISP-BR-Aのイングレスフィルターを通過できます。これは、Pref-Aに外側のIPv6ソースアドレスを備えているためです。パケットはISP-BR-Bに到達し、イングレスフィルターが適用される前に脱カプセル化されます。脱カプセル化パケットは、ISP-BR-Bのイングレスフィルターを通過できます。これは、Pref-B（内側のIPv6ヘッダーから）にソースアドレスがあるためです。これを構成する際には、次の事実に注意してください。
o Not every router implements source-based routing.
o すべてのルーターがソースベースのルーティングを実装するわけではありません。
o The interaction between normal routing and source-based routing at E-BR-A (and/or E-BR-B) varies by router implementations.
o E-BR-A（および/またはE-BR-B）での通常のルーティングとソースベースのルーティングとの相互作用は、ルーターの実装によって異なります。
o At ISP-BR-B (and/or ISP-BR-A), the interaction between tunnel egress processing and filtering rules varies by router implementations and filter configurations.
o ISP-BR-B（および/またはISP-BR-A）では、トンネル出力処理とフィルタリングルールの相互作用は、ルーターの実装とフィルター構成によって異なります。
The document discussed the cases where a site has two upstream ISPs. The document can easily be extended to the cases where there are 3 or more upstream ISPs.
このドキュメントでは、サイトに2つの上流ISPがある場合について説明しました。このドキュメントは、3つ以上の上流のISPがある場合に簡単に拡張できます。
If you have many upstream providers, you would not make all ISPs backup each other, as it requires O(N^2) tunnels for N ISPs. Rather, it is better to make N/2 pairs of ISPs, and let each pair of ISPs backup each other. It is important to pick pairs which are unlikely to be down simultaneously. In this way, number of tunnels will be O(N).
多くの上流のプロバイダーがいる場合、N ISPにO（n^2）トンネルが必要なため、すべてのISPSをバックアップするわけではありません。むしろ、ISPのn/2ペアを作成し、ISPの各ペアを互いにバックアップする方が良いでしょう。同時にダウンする可能性が低いペアを選択することが重要です。このようにして、トンネルの数はO（n）になります。
Suppose that the site is very large and it has ISP links in very distant locations, such as in the United States and in Japan. In such a case, it is wiser to use this technique only among ISP links in the US, and only among ISP links in Japan. If you use this technique between ISP link A in the US and ISP link B in Japan, the secondary link makes packets travel a very long path, for example, from a host in the site in the US, to E-BR-B in Japan, to ISP-BR-B (again in Japan), and then to the final destination in the US. This may not make sense for actual use, due to excessive delay.
サイトが非常に大きく、米国や日本などの非常に遠い場所にISPリンクがあると仮定します。そのような場合、この手法は、米国のISPリンクの間でのみ、日本のISPリンク間でのみ使用することが賢明です。米国のISPリンクAと日本のISPリンクBの間でこの手法を使用する場合、セカンダリリンクにより、パケットは、たとえば、米国のサイトのホストからE-BR-Bの非常に長いパスになります。日本、ISP-BR-B（再び日本）、そして米国の最終目的地へ。これは、過度の遅延のため、実際の使用には意味がない場合があります。
Similarly, in a large site, addresses must be assigned to end nodes with great care, to minimize delays due to extra path packets may travel. It may be wiser to avoid assigning an address in a prefix assigned from Japanese ISP, to an end node in the US.
同様に、大きなサイトでは、追加のパスパケットが移動する可能性のある遅延を最小限に抑えるために、エンドノードにアドレスを割り当てる必要があります。日本のISPから割り当てられた接頭辞のアドレスを米国のエンドノードに割り当てないようにすることは賢明かもしれません。
If one of the primary links is down for a long time, administrators may want to control source address selection on end hosts so that secondary link is less likely to be used. This can be achieved by marking the unwanted prefix as deprecated. Suppose the primary link toward ISP-A has been down. You will issue router advertisement [Thomson, 1998; Narten, 1998] packets from routers, with preferred lifetime set to 0 in prefix information option for Pref-A. End hosts will consider addresses in Pref-A as deprecated, and will not use any of them as source address for future connections. If an end host in the site makes a new connection to outside, the host will use an address in Pref-B as source address, and the reply packet to the end host will travel the primary link from ISP-BR-B toward E-BR-B. A great care must be taken when you try to automate this by using router renumbering protocols [Crawford, 2000] , as the approach could lead your site into very unstable state if any of the links flap. The author does not recommend to automate it.
主要なリンクの1つが長い間ダウンしている場合、管理者は、セカンダリリンクを使用する可能性が低くなるように、エンドホストのソースアドレスの選択を制御することをお勧めします。これは、不要なプレフィックスを非推奨にマークすることで実現できます。ISP-Aへの主要なリンクがダウンしているとします。ルーター広告[Thomson、1998;Narten、1998]ルーターからのパケット、Pref-Aのプレフィックス情報オプションで優先寿命が0に設定されています。End Hostsは、Pref-Aのアドレスを非推奨と見なし、それらのいずれも将来の接続のソースアドレスとして使用しません。サイトのエンドホストが外部に新しい接続を行う場合、ホストはソースアドレスとしてPref-Bのアドレスを使用し、エンドホストへの返信パケットはISP-BR-BからE-へのプライマリリンクを移動しますすぐに戻る。アプローチがリンクフラップのいずれかである場合、サイトを非常に不安定な状態に導く可能性があるため、ルーターの変更プロトコル[Crawford、2000]を使用してこれを自動化しようとする場合は、細心の注意を払う必要があります。著者はそれを自動化することをお勧めしません。
Some of non-goals (such as "best" exit link selection) can be achieved by combining the technique described in this document, with some other techniques. One example of the technique would be the source/destination address selection [Draves, 2001] on the end nodes.
このドキュメントに記載されている手法を他の手法と組み合わせることで、一部の非ゴアル（「ベスト」出口リンク選択など）を実現できます。この手法の1つの例は、エンドノードのソース/宛先アドレスの選択[Draves、2001]です。
Hal Snyder has been running the technique, with two upstream ISPs (lava.net and iijlab), using 2 RFC 2893 IPv6-over-IPv4 tunnels to each of them (in total 4 tunnels), and BGP4+ peering over them.
Hal Snyderは、2つの上流ISP（lava.netとiijlab）を使用して、2つのRFC 2893 IPv6-Over-IPV4トンネル（合計4つのトンネル）に、BGP4を使用して、そのテクニックを実行しています。
As expected, when the primary links goes down the routing switches to the secondary link within BGP hold time, i.e., we see approximately the relations:
予想どおり、プライマリリンクがルーティングスイッチを下ってBGP保持時間内のセカンダリリンクへのスイッチ、つまり、ほぼ関係が表示されます。
o (hold time - keepalive time) < failover time
o （保留時間 - キープライブ時間）<フェールオーバー時間
o failover time < hold time
o フェールオーバー時間<保持時間
o failback time < keepalive time
o 失敗時間<Keepalive Time
This has been tested with keepalive and hold times from as low as 3 and 10 seconds respectively, up to 60 and 180 seconds respectively.
これは、それぞれ最大60秒と180秒まで、それぞれ低い時間と10秒までの時間と保持時間でテストされています。
The routing change will affect ISP-BR-A (or B) only. Because route instability is not propagated beyond one ISP, it should be feasible to use lower hold and keepalive times than in a conventional IPv4 setting. If primary and backup links terminate on the same router at the ISP, then failover from primary to backup link need not affect reachability information upstream of that router.
ルーティングの変更は、ISP-BR-A（またはb）のみに影響します。ルートの不安定性は1つのISPを超えて伝播されないため、従来のIPv4設定よりも低いホールドおよびキープタイムを使用することが可能です。プライマリとバックアップリンクがISPの同じルーターで終了する場合、プライマリからバックアップリンクへのフェールオーバーは、そのルーターの上流の到達可能性情報に影響しません。
Many of the existing IPv6 networks (connected to worldwide 6bone) are assigned multiple IPv6 prefixes from multiple upstreams. In many cases people assign global IPv6 addresses generated from multiple address prefixes. There has been almost no problems raised about complication due to source address selection.
既存のIPv6ネットワークの多く（Worldwide 6boneに接続）には、複数の上流から複数のIPv6プレフィックスが割り当てられています。多くの場合、人々は複数のアドレスプレフィックスから生成されたグローバルIPv6アドレスを割り当てます。ソースアドレスの選択により、合併症についてはほとんど問題が発生していません。
The configuration described in the document introduces no new security problem.
ドキュメントで説明されている構成は、新しいセキュリティの問題を導入しません。
If primary links toward ISP-A and ISP-B have different security characteristics (like encrypted link and non-encrypted link), administrators need to be careful setting up secondary links tunneled on them. Packets may travel an unwanted path, if secondary links are configured without care.
ISP-AおよびISP-Bへの主要なリンクが異なるセキュリティ特性（暗号化されたリンクや非暗号化リンクなど）の場合、管理者はそれらにトンネルを絞った二次リンクを慎重に設定する必要があります。セカンダリリンクが注意せずに構成されている場合、パケットは不要なパスを移動する場合があります。
References
参考文献
[Bates, 1998] Bates, T. and Y. Rekhter, "Scalable Support for Multi-homed Multi-provider Connectivity", RFC 2260, January 1998.
[Bates、1998] Bates、T。およびY. Rekhter、「マルチホームマルチプロバイダー接続のためのスケーラブルなサポート」、RFC 2260、1998年1月。
[Hinden, 1998] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[Hinden、1998] Hinden、R。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
[Rockell, 2000] Rockell, R. and B. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000.
[Rockell、2000] Rockell、R。およびB. Fink、「6bone Backbone Routing Guidelines」、RFC 2772、2000年2月。
[Draves, 2001] Draves, R., "Default Address Selection for IPv6", Work in Progress.
[Draves、2001] Draves、R。、「IPv6のデフォルトアドレス選択」、進行中の作業。
[Gilligan, 2000] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[Gilligan、2000] Gilligan、R。およびE. Nordmark、「IPv6ホストとルーターの遷移メカニズム」、RFC 2893、2000年8月。
[Carpenter, 2000] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[Carpenter、2000] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[Malkin, 1997] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[Malkin、1997] Malkin、G。およびR. Minnear、「IPv6のRIPNG」、RFC 2080、1997年1月。
[Ferguson, 1998] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998.
[Ferguson、1998] Ferguson、P。and D. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、RFC 2267、1998年1月。
[Thomson, 1998] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[Thomson、1998] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[Narten, 1998] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[Narten、1998] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[Crawford, 2000] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[Crawford、2000] Crawford、M。、「IPv6のためのRouter Renumbering」、RFC 2894、2000年8月。
Acknowledgements
謝辞
The document was made possible by cooperation from people participated in JEPG-IP IPv6 multihoming study meeting (1999), people in ipngwg multihoming design team, people in WIDE/KAME project and George Tsirtsis.
この文書は、JEPG-IP IPv6 Multihoming Study Meeting（1999）、IPNGWG Multihoming Design Teamの人々、Wide/Kame Project、George Tsirtsisの人々に参加した人々からの協力によって可能になりました。
Authors' Addresses
著者のアドレス
Jun-ichiro itojun Hagino Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku, Tokyo 101-0054, JAPAN
Jun-Ithiro Itojun Hagino Research Laboratory、Internet Initiative Japan Inc. Takebashi Yasuda Bldg。、3-13 Kanda Nishiki-Cho、Chiyoda-Ku、Tokyo 101-0054、日本
Phone: +81-3-5259-6350
Fax: +81-3-5259-6351
EMail: itojun@iijlab.net
Hal Snyder Vail Systems, Inc. 570 Lake Cook Rd, Ste 408 Deerfield, IL 60015, US
Hal Snyder Vail Systems、Inc。570 Lake Cook Rd、STE 408 Deerfield、IL 60015、米国
Phone: +1-312-360-8245
EMail: hal@vailsys.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。