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
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.
著作権（C）インターネット協会（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マルチホーミングとは異なり、この技術はIGP（インテリアゲートウェイプロトコル）ルーティングテーブルのサイズは、上流のISPに世界中のルーティングテーブルのサイズに影響を与え、またありません。機構は、支持機構マルチホーミングより洗練された（または複合体）と組み合わせることができ、そして他のメカニズムの基礎として使用することができます。文書は、主にトニー・ベイツによって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の運用ガイドライン（IPv6ネットワーク操作のため、現在練習ガイドラインである）[ロッケル、2000]はピアとの特別な合意がない場合のASは、デフォルト・フリーゾーンへの非集約アナウンスを発表していないことを示唆しています。
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.
上記の二つの方法が効果的に世界中のルーティングテーブルに追加ルートを注入するので、世界中のルーティングテーブルサイズの問題に悪影響を与えます。彼らはまた、現在の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.
この文書は、主にトニー・ベイツによってRFC 2260 [ベイツ、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 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私達は私達のサイトは2つのISPは、ISP-AとISP-Bに接続されていることを前提としています。
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アドレスプレフィックス、県-A及び県-Bが割り当てられています。 ISP-Aに近いホストは、県-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.
県-A及び県-Bサイトに、我々ローカル交換経路、サイト内のホストは、外部リンクを使用せずに相互に通信できるように、O。
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トンネルです。そのうちの一つが、リンク障害を生き残るようにプライマリリンクとは異なる媒体上に二次のリンクを有することが重要です。例えば、ISP-BR-AおよびE-BR-Bとの間の二次リンクは、ISP-BR-AおよびE-BR-Aとの間の主リンクとは異なる媒体を介して行く必要があります。二次リンクは、IPv4オーバーIPv4トンネルである場合、E-BR-Aにおけるトンネルエンドポイントは県-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が強い嗜好上の一次リンクとISP-BR-Aに向かって（1）県-Aをアドバタイズし、オーバー弱い嗜好とISP-BR-Bに向かって（2）県-Bについて二次リンク。同様に、E-BR-Bは、二次リンク上で弱い優先とISP-BR-Aに向かって強力な一次リンクを介して嗜好、及び（2）県-Aと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-BにISP-BR-A、および県-Bに県-Aを発表することに注意してください。
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は、一次リンク上で強い嗜好を有するE-BR-Aに向かって（1）デフォルトルート（または特定のルート）をアドバタイズし、（2）デフォルトルート（または特定の経路）E-向かっ二次リンク上で弱い優先とBR-B。同様に、ISP-BR-Bは、（1）デフォルトルート（または特定の経路）E-BR-Bに向かって一次リンク上で強い嗜好を有する、及びE-BR-Aに向かって（2）デフォルトルート（または特定のルート）をアドバタイズします二次リンク上で弱い優先順位を持ちます。
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に向かっ県-Aを発表し、県-BのみのISP-BR-Bに向けました。そのため、サイトの外に余分なルーティングの発表はありません。これは6boneの集約ガイドライン[ロッケル、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が県-AからアドレスがE-BR-A周辺ノード、およびその逆（前のセクションの第二弾）に割り当てられると仮定する。
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アドレスはノードに割り当てることができます。そこで、サイト内の単一のノードに、両方のプレフィクスから県-A（1）から一つのアドレス、県-B（2）から一つのアドレス、または（3）アドレスを割り当てることができます。これは、ノード構成でより柔軟にできるようになります。
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.
一つの簡素化のアプローチは、別のサブネット上のサイトのインターネットホストを配置することである県-Aのアドレスを持つ1とE-BR-Aに接続され、県-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 [ギリガン、2000]のIPv6オーバーIPv4の構成トンネルの6to4 [カーペンター、2000]のIPv6オーバーの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オーバー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オーバー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オーバーのIPv6オーバーのIPv4トンネルであろうので、これは、IPv6のオーバーIPv6トンネルによって、二次リンクを設定する意味がありません。この場合、IPv6-over-IPv4トンネルは、二次リンクのために使用されるべきです。二次リンクが主リンクと同じパスMTUを有することができるであろうようにIPv6のオーバーIPv4の構成は、IPv6のオーバーのIPv6オーバーIPv4の構成に対して大きな利点を有します。
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は、県-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.
RFC 2260に記載されているようにIPv6のの上のRFC 2260のアプローチが正常に動作します必要な余計なねじれはありません。マルチホームサイトがトランジットをやっていないので、バリエーションが可能であるAS番号のパブリックを持って、それを必要としません。
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の[マルキン、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:
私たちはルータR2に向けて、ルータR1、メトリックとして（R1、R2）からのルートの発表のためのRIPngメトリックを、表した場合、保持しなければならない不変条件は以下のとおりです。
o metric(E-BR-A, ISP-BR-A) < metric(E-BR-B, ISP-BR-A)
Oメトリック（E-BR-A、ISP-BR-A）<メトリック（E-BR-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が発信トラフィックに侵入フィルタ[ファーガソン、1998]を課した場合、話はもっと複雑になります。県-Aから取られた送信元アドレスを持つパケットは、ISP-BR-Aから出て行かなければなりません。同様に、県-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.
一つの可能な方法は県-Bと県-Aの両方が、送信元アドレスとして使用することができるように、両方のISPと交渉することです。 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オーバーIPv6トンネルは、二次リンクに使用されていることを前提としています。アウトバウンドパケットは県-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ヘッダ：ソース= E-BR-Aのアドレス県-Aにおいて、DEST = ISP-BR-B
o Inner IPv6 header: source = address in Pref-B, dest = final dest
O内部IPv6ヘッダ：ソース=県-Bのアドレス、DEST =最終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-Aを横切って移動します。それは県-Aにおける外側のIPv6ソースアドレスを持っているので、パケットは、ISP-BR-Aで入口フィルタを介して行くことができます。パケットがISP-BR-Bに到達すると入口フィルタが適用される前にデカプセル化します。それは今（インナーIPv6ヘッダから）県-Bのソースアドレスを有するので、デカプセル化パケットは、ISP-BR-Bに入口フィルタを通過することができます。これを設定する場合は、次の事実に注意してください：
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）のトンネルを必要として、あなたは、それぞれ他のすべてのISPのバックアップをすることはないだろう。むしろ、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リンクBにおけるISPリンクAとの間で、この技術を使用する場合は、二次リンクは中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に向けて、プライマリリンクがダウンしていると仮定します。あなたは、ルータ広告[トムソン、1998を発行します。県-Aのプレフィックス情報オプションで0に設定好適寿命のNarten氏、1998]ルータからパケット。エンドホストは非推奨として県-Aにアドレスを検討し、今後の接続の送信元アドレスとしてそれらのいずれかを使用することはありません。サイト内のエンドホストが外部への新しい接続を行った場合、ホストは送信元アドレスとして県-B内のアドレスを使用すると、エンドホストへの応答パケットはE-に向けてISP-BR-Bからプライマリリンクを移動しますBR-B。あなたはプロトコル[クロフォード、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.
（例えば、「最良の」出口リンクの選択など）非目標のいくつかは、いくつかの他の技術と、本書に記載の技術を組み合わせることにより達成することができます。技術の一例は、エンドノードに送信元/宛先アドレスの選択[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スナイダー2 RFC（合計4つのトンネル内）それらのそれぞれに2893のIPv6オーバーIPv4トンネルを使用して、2つの上流のISP（lava.netとiijlab）と、技術を実行しており、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時間<キープアライブ時間
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秒まで、それぞれ3秒と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.
（全世界の6boneに接続されている）既存のIPv6ネットワークの多くは、複数のアップストリームから複数の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.
[ベイツ、1998]ベイツ、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.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[Rockell, 2000] Rockell, R. and B. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000.
[ロッケル、2000]ロッケル、R.とB.フィンク、 "6boneのバックボーンルーティングガイドライン"、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.
[ギリガン、2000]ギリガン、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.
[カーペンター、2000]大工、B.およびK.ムーア、 "IPv4の雲を介したIPv6ドメインの接続"、RFC 3056、2001年2月。
[Malkin, 1997] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[マルキン、1997]マルキン、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.
[ファーガソン、1998]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス妨害Attacksを破り"、RFC 2267、1998年1月。
[Thomson, 1998] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[トムソン、1998]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、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.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[Crawford, 2000] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[クロフォード、2000]クロフォード、M.、 "IPv6のルータリナンバリング"、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.
文書は、人々の協力によって可能となったWIDE / KAMEプロジェクトとジョージTsirtsisの人々、ipngwgマルチホーミングの設計チームの人々、JEPG-IP IPv6のマルチホーミング研究会（1999）に参加しました。
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
じゅんーいちろ いとじゅん はぎの れせあｒｃｈ ぁぼらとｒｙ、 いんてｒねｔ いにちあちゔぇ じゃぱん いんｃ。 たけばし やすだ Ｂｌｄｇ。、 ３ー１３ かんだ にしきーちょ、 ちよだーく、 ときょ １０１ー００５４、 じゃぱん
Phone: +81-3-5259-6350 Fax: +81-3-5259-6351 EMail: itojun@iijlab.net
電話：+ 81-3-5259-6350ファックス：+ 81-3-5259-6351 Eメール：itojun@iijlab.net
Hal Snyder Vail Systems, Inc. 570 Lake Cook Rd, Ste 408 Deerfield, IL 60015, US
ハル・スナイダーベイルSystems、Inc.の570湖クックRdを、サント408ディアフィールド、IL 60015、米国
Phone: +1-312-360-8245 EMail: hal@vailsys.com
電話：+ 1-312-360-8245 Eメール：hal@vailsys.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。