この文書はRFC3178の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
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. 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(内部ゲートウェイプロトコル)ルーティングテーブルの大きさにも 影響を与えません。このメカニズムはいっそう洗練されている(あるいは複 雑な)マルチホームサポートメカニズムと共存ができて、他のメカニズムの 土台に使うことができます。文書は主にトニー・ベーツによるRFC2260に基 づきます。 1. Problem 1. 問題 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]は デフォルトなしのゾーンで経路の数を減らすために集約ルーティング広告を 利用するよう意図されます。同じく、(IPv6ネットワーク運営のために現 在実践されたガイドラインである)6bone運営ガイドライン[Rockell, 2000]はASは、ピア間で特別な合意がなければ、デフォルトなしのゾーンに 非集約広告を出さないように示唆します。 In IPv4, a multihomed site uses either of the following techniques to achieve better reachability: IPv4のマルチホームサイトが良い到達可能性を成し遂げるため次のテク ニックのいずれかを使います: o Obtain a portable IPv4 address prefix, and announce it from multiple upstream providers. 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の1つから1つの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. この文書は主にトニー・ベーツによるRFC 2260 [Bates, 1998]に基づい ています。 2. Goals and non-goals 2. 目標と目標でないもの 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の破壊に対処する。 3. Basic mechanisms 3. 基本的なメカニズム。 We use the technique described in RFC 2260 section 5.2 in our configuration. To summarize, for IPv4-only networks, RFC 2260 says that: 我々はRFC2260の5.2章で記述されるテクニックを使います。要約すると、 IPv4のみのネットワークで、RFC2260は以下を言います: 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アドレスプレフィックス、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-BR-Aと、サイトルーターE-BR-A間の「主リンク」 によって、ISP-Aとサイトの間は結ばれます。ISP-BのルーターISP-BR-B と、サイトルーターE-BR-B間の主リンクによって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のそれぞれの間で第2のリンク を確立してます。第2のリンクは通常IP-over-IPトンネルです。主リン クと異なるメディア上で第2のリンクを持つことは重要で、これで1つ のリンクが故障しても生き残ります。例えば、ISP-BR-AとE-BR-B間の第 2リンクはISP-BR-AとE-BR-A間の主リンクと異なるメディアを通るべき です。もし第2リンクがIPv4-over-IPv4トンネルなら、E-BR-A側のトン ネル終端のアドレスがPref-BではなくPref-Aでなければならなりません (トンネルパケットは、 ISP-BR-AからE-BR-Aへの主リンク上で、ISP-BR-B からE-BR-Aに転送されます)。 (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 へPref-Aを(2)第2リンク上で弱い優先でISP-BR-BへPref-Bを、広告し ます。同様に、E-BR-Aは内行きパケットのために、(1)主リンク上で強く 優先してISP-BR-BへPref-Bを、(2)第2リンク上で弱い優先でISP-BR-A へPref-Aを、広告します。 Note that we always announce Pref-A to ISP-BR-A, and Pref-B to ISP-BR-B. 我々が常にISP-BR-AにPref-Aを、ISP-BR-BにPref-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に向かう主リンク上で強い 優先でデフォルトルート(あるいは特定ルート)を、E-BR-Bに向かう第2 リンク上で弱い優先でデフォルトルート(あるいは特定ルート)を、広告 するでしょう。同様に、外行きパケットのために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. この設定下で、内行きと外行きのパケットが共にいずれかの側のリンク障害か ら生き残ることができます。弱い優先を持つルーティング情報はバックアップ として、内行きと外行きの場合両方で利用可能であるでしょう。 4. Extensions for IPv6 4. IPv6のための拡張 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. RFC2260はIPv4とBGPのために書かれています。IPv6とBGP4+ あるいはIPv6とRIPngを使ってグローバルIPv6ルーティングテーブ ル大きさに影響を与えないで、類似の結果を成し遂げることができます。 4.1. IPv6 rule conformance 4.1. 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. RFC2260で、我々はPref-AをISP-BR-Aだけに、Pref-BをISP-BR-Bだけに広 告するとしています。それ故、サイトの外部に余分のルーティング広告がない でしょう。これは6bone集約ガイドライン[Rockell, 2000]の示唆にかな います。同じく、RFC 2260がポータブルアドレスを必要としません。 4.2. Address assignment to the nodes 4.2. ノードへのアドレス割当 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で、ノードが1つのIPv4アドレスを割り当てられるであろうと通 常想定されます。それ故に、RFC2260は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つのノードに(1)Pref-Aから1つアドレスを割当 てる(2)Pref-Bから1つアドレスを割当てる(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. 単純なアプローチの1つは、サイトのインターネットホストを別のサブネッ トに置き、1つはPref-AのアドレスでE- BR-Aに接続し、他はPref-Bのア ドレスでE-BR-に接続する事です。このアプローチはE-BR-AとE-BR-Bが異 なったサイトにあり、サイトAとサイトBがインターネットへと、相互接続 のリンクを持っていると一般化できます。 4.3. Configuration of links 4.3. リンクの形状 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ネイティブの接続か、RFC2893[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: もしトンネルベースの接続が主リンクで使われるなら、管理者が第2リンク で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への主リンクはRFC2893の 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. 第2リンクをIPv6-over-IPv6にすると、これは実際にはIPv6-over-IPv6- over-IPv4トンネルになるので、これは意味がありません。この場合IPv6- over-IPv4トンネルが第2リンクに使われるべきです。第2リンクが主リン クと同じパスMTUを持つことが可能であるので、IPv6-over-IPv4設定が IPv6-over-IPv6-over-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の両方がPref-Aの内行きトラフィックの障害ポ イントです。これは主リンクとバックアップリンクで異なったルーターを使 うことで修復できます。 4.4. Using RFC 2260 with IPv6 and BGP4+ 4.4. IPv6やBGP4+と共にRFC2260を使用 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の頂上でのRFC2260のアプローチは、RFC2260で文書化されるように よく動くでしょう。余分のねじりが必要ないでしょう。マルチホームサイトが 中継をしないので、パブリックAS番号を持つ必要がありません。 4.5. Using RFC 2260 with IPv6 and RIPng 4.5. IPv6とRIPngと共にRFC2260を使用。 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]をRFC2260のような 設定で運営することは可能です。図のルーターで第2のリンク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メトリックを metric(R1, R2)とするなら、以下の不等式を満たさなければなりません: o metric(E-BR-A, ISP-BR-A) < metric(E-BR-B, ISP-BR-A) o metric(E-BR-B, ISP-BR-B) < metric(E-BR-A, ISP-BR-B) o metric(ISP-BR-A, E-BR-A) < metric(ISP-BR-A, E-BR-B) o metric(ISP-BR-B, E-BR-B) < metric(ISP-BR-B, E-BR-A) Note that smaller metric means stronger route in RIPng. 小さいメトリックがRIPngで優先経路を意味することに注意してください。 5. Issues with ingress filters in ISP 5. ISPでの侵入フィルターの問題 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と交渉して、Pref-BとPref-Aの両方をソー スアドレスとして用いることを許すことです。このアプローチは、もし ISP-Aの上流のISPが侵入フィルタを課すなら、うまくいきません。ISP-A の頂上のISPまで多数レベルがあるだろうから、どの上流ISPがフィル ターを課すか理解することは難しいでしょう。侵入フィルターが小さいIS Pが下に接続されている大きい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: もう1つの可能性はE-BR-AとE- BR-Bにおいてソースベースのルーティング を使うことです。ここでIPv6-over-IPv6トンネルが第2リンクに使われると 想定します。外行きパケットがPref-BのソースアドレスでE-BR-Aに到着す る時、E-BR-Aがパケットをソースベースルーティング決定に基づいて第2リ ンク(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のPref-Aのアドレス、宛先ISP-BR-B。 o Inner IPv6 header: source = address in Pref-B, dest = final dest o 中のIPv6ヘッダー:ソース=Rref-Bのアドレス、宛先=最終宛先。 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-AからISP-BR-Bに向かって移動するでしょう。 パケットの外側のソースアドレスはPref-Aに含まれるので、ISP-BR-Aの侵 入フィルターをパケットは通過します。パケットはISP-BR-Bに届いて、侵 入フィルタが適用される前にカプセルを解かれるでしょう。カプセルを解か れたパケットは、(奥のIPv6ヘッダーの)ソースアドレスがPref-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)において、トンネル出口処理とフィルター規則の間 の対話はルーター実装とフィルター設定よって変化します。 6. Observations 6. 観察 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(2^N)のトンネルが必要なので、すべてのISPを相互にバッ クアップにしないでしょう。どちらかと言うと、N/2のISPペアを作り、 それぞれに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の間でこ のテクニックを使うと、第2リンクのパケットはとても長いパスを通る、例 えばUSホストから日本の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つが長期間ダウンしているなら、管理者が第2のリンクが 使われる可能性が低くなるように、エンドホストのソースアドレス選択を管 理することを望むかもしれません。これは、抑制プレフィックスを指定する ことで成し遂げることができます。ISP-Aに向かう主リンクがダウンしてい ると考えてください。望ましい寿命を0にしたPref-Aのプレフィックス情報 オプションを設定したルータ広告パケット[Thomson, 1998; Narten, 1998] を生成できます。エンドホストがPref-Aのアドレスを抑制したいと考え、新 たな接続でそれらをソースアドレスとして用いないでしょう。もしサイトの エンドホストが外への新しい接続をするなら、ホストはPref-Bのアドレスを ソースアドレスとして用いるでしょう、そしてエンドホストへの応答パケッ トはISP-BR-BからE-BR-Bへの主リンクを通るでしょう。もしルータリナンバ リングプロトコル[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]でしょう。 7. Operational experiences 7. 運用経験 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の保留時間で経路は第 2リンクに切り替わりました、すなわちおよそ以下の通りです: 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. これは生存確認時間と保留時間がそれぞれ最小3秒と10秒で、最大60秒 と180秒でテストされました。 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プレフィックスを割り当てられます。多くの 場合人々が多数のアドレスプレフィックスから生成されたグローバルIPv 6アドレスを割り当てます。そこでソースアドレス選択の複雑な問題につい てほとんど問題になりませんでした。 8. Security Considerations 8. セキュリティの考察 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へ向かう主リンクに異なるセキュリティの特性があるなら (例えば暗号化リンクとそうでないリンクとか)、管理者は第2リンクのトン ネルの準備に注意深くする必要があります。もし第2のリンクが危険な構成な ら、パケットが望まれないパスを通るかもしれません。 References 参考文献 [Bates, 1998] Bates, T. and Y. Rekhter, "Scalable Support for Multi-homed Multi-provider Connectivity", RFC 2260, January 1998. [Hinden, 1998] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [Rockell, 2000] Rockell, R. and B. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000. [Draves, 2001] Draves, R., "Default Address Selection for IPv6", Work in Progress. [Gilligan, 2000] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [Carpenter, 2000] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [Malkin, 1997] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. [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. [Thomson, 1998] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [Narten, 1998] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [Crawford, 2000] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000. 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マルチホーム研究会(1999)に参加した人々と、 ipngwgマルチホームデザインチームの人々と、WIDE/KAMEプロジェクトの人 々と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 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 Phone: +1-312-360-8245 EMail: 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エディタ機能のための資金供給が現在インターネット学会によって 供給されます。