この文書はRFC2260の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
Network Working Group T. Bates Request for Comments: 2260 Cisco Systems Category: Informational Y. Rekhter Cisco Systems January 1998 Scalable Support for Multi-homed Multi-provider Connectivity マルチホーム・マルチプロバイダ接続のスケーラブルな方法 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 (1998). All Rights Reserved. 2. Abstract 2. 概要 This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. この文書は、多数のインターネット・サービスプロバイダ(ISP)と接続する マルチホーム企業のために、グローバルなインターネットルーティングシステ ムでこれらの企業のためのルーティングオーバーヘッドを減らす事を意図した アドレスとルーティング作戦を記述します。 3. Motivations 3. 動機 An enterprise may acquire its Internet connectivity from more than one Internet Service Provider (ISP) for some of the following reasons. Maintaining connectivity via more than one ISP could be viewed as a way to make connectivity to the Internet more reliable. This way when connectivity through one of the ISPs fails, connectivity via the other ISP(s) would enable the enterprise to preserve its connectivity to the Internet. In addition to providing more reliable connectivity, maintaining connectivity via more than one ISP could also allow the enterprise to distribute load among multiple connections. For enterprises that span wide geographical area this could also enable better (more optimal) routing. 企業が次の理由のいくつかのために複数のインターネット・サービスプロバ イダ(ISP)からインターネット接続性を獲得するかもしれません。複数 のISPによって接続性を持続することはインターネットへの接続性をより 信頼できる方法と見なすことができました。ISPの1つを通しての接続性 が失敗する時、他のISPによる接続性が企業のインターネット接続性を維 持することになるでしょう。より信頼できる接続性を供給することに加えて、 複数のISPによって接続性を持続すると企業は多数の接続の間で負荷を分 散できます。広い地理的なエリアにかかる企業でこれはよりよい良い(より 最適な)ルーティングを可能にします。 The above considerations, combined with the decreasing prices for the Internet connectivity, motivate more and more enterprises to become multi-homed to multiple ISPs. At the same time, the routing overhead that such enterprises impose on the Internet routing system becomes more and more significant. Scaling the Internet, and being able to support a growing number of such enterprises demands mechanism(s) to contain this overhead. This document assumes that an approach where routers in the "default-free" zone of the Internet would be required to maintain a route for every multi-homed enterprise that is connected to multiple ISPs does not provide an adequate scaling. Moreover, given the nature of the Internet, this document assumes that any approach to handle routing for such enterprises should minimize the amount of coordination among ISPs, and especially the ISPs that are not directly connected to these enterprises. 上記の考慮は、インターネット接続性の価格低下により、ますます多くの企 業が多数のISPにマルチホームする動機を与えます。同時に、このような 企業がインターネットルーティングシステムに課すルーティングコストはよ りいっそう重要になります。インターネットの大きさと、このような企業需 要の増加はオーバーヘッドを含みます。この文書はインターネットの「デフォ ルトなし」ゾーンでルーターが多数のISPに関係しているすべてのマルチ ホーム企業の経路を保守するように要求されるのがスケールしないと想定し ます。さらに、インターネットの性質という条件下で、この文書はこのよう な企業のためにルーティングを処理するアプローチがISP間の調整を最小 化し、特に直接これらの企業に関係していないISPとの調整を最小にする べきであると想定します。 There is a difference of opinions on whether the driving factors behind multi-homing to multiple ISPs could be adequately addressed by multi-homing just to a single ISP, which would in turn eliminate the negative impact of multi-homing on the Internet routing system. Discussion of this topic is beyond the scope of this document. 1つのISPでマルチホームするより、多数のISPでマルチホームをする 推進要素について意見の相違があり、1つのISPでマルチホームすればイ ンターネットルーティングシステム上でのマルチホームの打撃的な影響を削 除するでしょう。このトピックの論議がこの文書の範囲を越えてます。 The focus of this document is on the routing and addressing strategies that could reduce the routing overhead due to multi-homed enterprises connected to multiple ISPs in the Internet routing system. この文書の焦点は、インターネットルーティングシステムで多数のISPに 接続したマルチホーム企業によるルーティングオーバーヘッドを減らすため の、ルーティングとアドレス作戦です。 The strategies described in this document are equally applicable to both IPv4 and IPv6. この文書で記述された作戦は等しくIPv4とIPv6両方に適用できます。 4. Address allocation and assignment 4. アドレス配分と割当て A multi-homed enterprise connected to a set of ISPs would be allocated a block of addresses (address prefix) by each of these ISPs (an enterprise connected to N ISPs would get N different blocks). The address allocation from the ISPs to the enterprise would be based on the "address-lending" policy [RFC2008]. The allocated addresses then would be used for address assignment within the enterprise. 複数のISPと接続したマルチホーム企業は各ISPからアドレスブロック (アドレスプレフィックス)を配布されます(N個のISPに接続した企業 が異なるN個のブロックNを得るでしょう)。アドレス配布はISPから企 業への「アドレス割当」ポリシー[RFC2008]に基づくでしょう。配布された アドレスは企業内内でアドレス割当てに使われるでしょう。 One possible address assignment plan that the enterprise could employ is to use the topological proximity of a node (host) to a particular ISP (to the interconnect between the enterprise and the ISP) as a criteria for selecting which of the address prefixes to use for address assignment to the node. A particular node (host) may be assigned address(es) out of a single prefix, or may have addresses from different prefixes. 企業が使用することができたる1つの可能なアドレス割当計画は、ノード (ホスト)と(企業と接続している)ISPのトポロジー的な距離をアドレ ス割当てのアドレスプレフィックスの選択基準とすることです。特定のノー ド(ホスト)が、ひとつのプレフィックスからアドレスを割り当てられたり、 異なったプレフィックスからアドレスを割当てられるかもしれません。 5. Routing information exchange 5. ルーティング情報交換 The issue of routing information exchange between an enterprise and its ISPs is decomposed into the following components: 企業とISP間のルーティング情報交換の問題は次の要素に分解できます: a) reachability information that an enterprise border router advertises to a border router within an ISP a) 企業境界ルータがISPの境界ルータに広告する到達可能性情報。 b) reachability information that a border router within an ISP advertises to an enterprise border router b) ISPの境界ルータが企業境界ルータに広告する到達可能性情報。 The primary focus of this document is on (a); (b) is covered only as needed by this document. この文書の主要なフォーカスは(a)です;(b)はこの書類で必要な所だ け記述します。 5.1. Advertising reachability information by enterprise border routers 5.1. 企業境界ルータによる到達可能性情報の広告 When an enterprise border router connected to a particular ISP determines that the connectivity between the enterprise and the Internet is up through all of its ISPs, the router advertises (to the border router of that ISP) reachability to only the address prefix that the ISP allocated to the enterprise. This way in a steady state routes injected by the enterprise into its ISPs are aggregated by these ISPs, and are not propagated into the "default-free" zone of the Internet. 特定のISPに接続した企業境界ルータが、企業とインターネット間の接続 が全ISPを通して可能と決定する時、ルーターはISPが企業に割り当て たアドレスプレフィックスだけの到達可能性を(そのISPの境界ルータ へ)広告します。このように堅実な状態で企業からISPに渡された経路は ISPで集約され、インターネットの「デフォルトなしの」ゾーン内に広ま りません。 When an enterprise border router connected to a particular ISP detemrines that the connectivity between the enterprise and the Internet through one or more of its other ISPs is down, the router starts advertising reachability to the address prefixes that was allocated by these ISPs to the enterprise. This would result in injecting additional routing information into the "default-free" zone of the Internet. However, one could observe that the probability of all multi-homed enterprises in the Internet concurrently losing connectivity to the Internet through one or more of their ISPs is fairly small. Thus on average the number of additional routes in the "default-free" zone of the Internet due to multi-homed enterprises is expected to be a small fraction of the total number of such enterprises. あるISPに接続する企業境界ルータが他のISPを通してのインターネッ ト接続が停止したと決定した時、ルーターは企業にこれらの他のISPによっ て割り当てられたアドレスプレフィックスへの到達可能性を広告し始めます。 これはインターネットの「デフォルトなしの」ゾーンに追加のルーティング 情報を導入する結果をもたらすでしょう。しかし、すべてのインターネット のマルチホーム企業が同時にいくつかのISPを通してのインターネット接 続性をで失う可能性は低いと考えられます。それで平均的にマルチホーム企 業のインターネットの「デフォルトなしの」ゾーン内の追加のルート数はこ のような企業の合計の数より小数であることが期待されます。 The approach described above is predicated on the assumption that an enterprise border router has a mechanism(s) by which it could determine (a) whether the connectivity to the Internet through some other border router of that enterprise is up or down, and (b) the address prefix that was allocated to the enterprise by the ISP connected to the other border router. One such possible mechanism could be provided by BGP [RFC1771]. In this case border routers within the enterprise would have an IBGP peering with each other. Whenever one border router determines that the intersection between the set of reachable destinations it receives via its EBGP (from its directly connected ISP) peerings and the set of reachable destinations it receives from another border router (in the same enterprise) via IBGP is empty, the border router would start advertising to its external peer reachability to the address prefix that was allocated to the enterprise by the ISP connected to the other border router. The other border router would advertise (via IBGP) the address prefix that was allocated to the enterprise by the ISP connected to that router. This approach is known as "auto route injection". 上記アプローチは企業境界ルータが、(a)他の企業境界ルータを通してのイン ターネット接続性があるかないかと、(b)他の境界ルータに接続したISPが 企業に割り当てたアドレスプレフィックスを、決定するメカニズムを持つと 仮定しています。1つの可能な機構はBGP[RFC1771]によって供給されま す。この場合企業の境界ルータがお互いにIBGPピアリングを持っている でしょう。1つの境界ルータが、(直接接続したISPとの)EBGPピアリ ングにより受信した到達可能な宛先と、IBGPによって(同じ企業の)他 の境界ルータから受け取る到達可能な宛先とに重複経路がないと決定した時 は、境界ルータは他の境界ルータに接続したISPから企業に割り当てられ たアドレスプレフィックスを外部ピアへ到達可能と広告し始めるでしょう。 他の境界ルータは自分に接続したISPによって企業に割り当てられたアド レスプレフィックスを(IBGPによって)広告するでしょう。このアプ ローチは「自動経路注入」として知られています。 As an illustration consider an enterprise connected to two ISPs, ISP-A and ISP-B. Denote the enterprise border router that connects the enterprise to ISP-A as BR-A; denote the enterprise border router that connects the enterprise to ISP-B as BR-B. Denote the address prefix that ISP-A allocated to the enterprise as Pref-A; denote the address prefix that ISP-B allocated to the enterprise as Pref-B. When the set of routes BR-A receives from ISP-A (via EBGP) has a non-empty intersection with the set of routes BR-A receives from BR-B (via IBGP), BR-A advertises to ISP-A only the reachability to Pref-A. When the intersection becomes empty, BR-A would advertise to ISP-A reachability to both Pref-A and Pref-B. This would continue for as long as the intersection remains empty. Once the intersection becomes non-empty, BR-A would stop advertising reachability to Pref-B to ISP-A (but would still continue to advertise reachability to Pref-A to ISP-A). Figure 1 below describes this method graphically. 例として企業が2つのISP、ISP-AとISP-Bに接続していると思ってくだ さい。ISP-Aと接続する企業ルータをBR-Aとします;ISP-Bと接続する企業境 界ルータをBR-Bとします。ISP-Aが企業に割り当てたアドレスプレフィック スをPref-Aとします;ISP-Bが企業に割り当てたアドレスプレフィックスを Pref-Bとします。ISP-Aから(EBGPによって)BR-Aが受け取る経路はBR-B から(IBGPで)受取る経路と重複する時、BR-AはISP-AにPref-Aだけを 広告します。重複がなくなる時、BR-AがISP-AにPref-AとPref-Bの両方の到 達可能性を広告します。これは重複がない限り継続します。重複が発生する と、BR-AがISP-AににPref-Bへの可到達性広告をやめるでしょう(しかし ISP-AにPref-Aへ到達可能性を広告し続けるでしょう)。下の図1がこの方法 を記述します。 +-------+ +-------+ +-------+ +-------+ ( ) ( ) ( ) ( ) ( ISP-A ) ( ISP-B ) ( ISP-A ) ( ISP-B ) ( ) ( ) ( ) ( ) +-------+ +-------+ +-------+ +-------+ | /\ | /\ | /\ | | || | || | Pref-A (connection | Pref-A | Pref-B | Pref-B broken) | || | || | || | +-----+ +-----+ +-----+ +-----+ | BR-A|------|BR-B | | BR-A|------|BR-B | +-----+ IBGP +-----+ +-----+ IBGP +-----+ non-empty intersection empty intersection 経路重複あり 経路重複なし Figure 1: Reachability information advertised 図1:到達可能性情報広告 Although strictly an implementation detail, calculating the intersection could potentially be a costly operation for a large set of routes. An alternate solution to this is to make use of a selected single (or more) address prefix received from an ISP (the ISP's backbone route for example) and configure the enterprise border router to perform auto route injection if the selected prefix is not present via IBGP. Let's suppose ISP-B has a well known address prefix, ISP-Pref-B for its backbone. ISP-B advertises this to BR-B and BR-B in turn advertises this via IBGP to BR-A. If BR-A sees a withdraw for ISP-Pref-B it advertises Pref-B to ISP-A. 実装に依存するが、重複を計算するのは潜在的に高価なオペレーションであ り得ます。これに対する代わりの解決がISPから選択されたアドレスプレ フィックス(例えばISPのバックボーンルート)だけを受取りから、もし 選択されたプレフィックスがIBGPに存在しないなら、企業ボーダールー ターがを自動経路注射を行うように設定することです。ISP-Bがバックボー ンの既知アドレスプレフィックス(ISP-Pref-B) を持っていると考えます。 ISP-BがBR-Bにこれを広告し、そしてBR-BがIBGPによってBR-Aにこれを広告し ます。もしBR-AがISP-Pref-Bの削除に気づけば、Pref-BをISP-Aに広告します。 The approach described in this section may produce less than the full Internet-wide connectivity in the presence of ISPs that filter out routes based on the length of their address prefixes. One could observe however, that this would be a problem regardless of how the enterprise would set up its routing and addressing. このセクションで記述されたアプローチは、アドレスプレフィックスの長さ に基づいて経路を除外するISPの存在によりインターネット全体での接続 性の低下を引き起こすかもしれません。しかしこれは企業がルーティングと アドレスを設定するかどうかにかかわらず、問題であると言う事もできます。 5.2. Further improvements 5.2. 将来の実装 The approach described in the previous section allows to significantly reduce the routing overhead in the "default-free" zone of the Internet due to multi-homed enterprises. The approach described in this section allows to completely eliminate this overhead. 前章で記述されたアプローチはマルチホーム企業によるインターネットの 「デフォルトなし」ゾーンでルーティングオーバーヘッドを減らします。こ の章で記述するアプローチは完全にこのコストを排除します。 An enterprise border router would maintain EBGP peering not just with the directly connected border router of an ISP, but with the border router(s) in one or more ISPs that have their border routers directly connected to the other border routers within the enterprise. We refer to such peering as "non-direct" EBGP. 企業境界ルータが、ISPの直接接続された境界ルータとではなく、企業の 他の境界ルータと直接接続した境界ルータを持つISPと、EBGPピアリ ングを保守します。このようなピアリングを「直接でない」 EBGPとい います。 An ISP that maintains both direct and non-direct EBGP peering with a particular enterprise would advertise the same set of routes over both of these peerings. An enterprise border router that maintains either direct or non-direct peering with an ISP advertises to that ISP reachability to the address prefix that was allocated by that ISP to the enterprise. Within the ISP routes received over direct peering should be preferred over routes received over non-direct peering. Likewise, within the enterprise routes received over direct peering should be preferred over routes received over non-direct peering. 特定の企業と直接と直接でないEBGPピアリングをするISPが両方の同 じ経路情報を送ります。ISPと直接と直接でないピアリングを実施する企 業境界ルータが、そのISPから企業に割り当てられたアドレスプレフィッ クスの到達可能性をISPに広告します。ISPで直接ピアリングにより受 け取った経路が直接出ないピアリングで受取った経路より優先されるべきで す。同じく、企業で直接ピアリングにより受け取った経路が直接でないピア リングの経路より優先するべきです。 Forwarding along a route received over non-direct peering should be accomplished via encapsulation [RFC1773]. 直接でないピアリングで受け取った経路の転送はカプセル化[RFC1773]によっ て達成されるべきです。 As an illustration consider an enterprise connected to two ISPs, ISP-A and ISP-B. Denote the enterprise border router that connects the enterprise to ISP-A as E-BR-A, and the ISP-A border router that is connected to E-BR-A as ISP-BR-A; denote the enterprise border router that connects the enterprise to ISP-B as E-BR-B, and the ISP-B border router that is connected to E-BR-B as ISP-BR-B. Denote the address prefix that ISP-A allocated to the enterprise as Pref-A; denote the address prefix that ISP-B allocated to the enterprise as Pref-B. E-BR-A maintains direct EBGP peering with ISP-BR-A and advertises reachability to Pref-A over that peering. E-BR-A also maintain a non-direct EBGP peering with ISP-BR-B and advertises reachability to Pref-B over that peering. E-BR-B maintains direct EBGP peering with ISP-BR-B, and advertises reachability to Pref-B over that peering. E-BR-B also maintains a non-direct EBGP peering with ISP-BR-A, and advertises reachability to Pref-A over that peering. 例として、企業が2つのISP、ISP-AとISP-Bに接続してると思ってくださ い。ISP-Aと接続する企業境界ルータをE-BR-Aとし、E-BR-Aに接続している ISP-A境界ルータをISP-BR-Aとします;ISP-Bと接続する企業境界ルータを E-BR-Bとし、E-BR-Bに接続しているISP-B境界ルータをISP-BR-Bとします。 ISP-Aが企業に割り当てたアドレスプレフィックスをPref-Aとし、ISP-Bが 企業に割り当てたアドレスプレフィックスをPref-Bとします。E-BR-Aは ISP-BR-Aとの直接EBGPピアリングを持続し、そのピアリング上でPref-Aの到 達可能性を広告します。同じくE-BR-AがISP-BR-Bへの非直接EBGPピアリング を持続し、そのピアリング上でPref-Bへの到達可能性を広告します。E-BR-B はISP-BR-Bとの直接EBGPピアリングを持続し、そのピアリング上でPref-Bへ の到達可能性を広告します。E-BR-BはISP-BR-Aへの非直接EBGPピアリングを 持続し、そのピアリング上でPref-Aへの到達可能性を広告します。 When connectivity between the enterprise and both of its ISPs (ISP-A and ISP-B is up, traffic destined to hosts whose addresses were assigned out of Pref-A would flow through ISP-A to ISP-BR-A to E-BR- A, and then into the enterprise. Likewise, traffic destined to hosts whose addresses were assigned out of Pref-B would flow through ISP-B to ISP-BR-B to E-BR-B, and then into the enterprise. Now consider what would happen when connectivity between ISP-BR-B and E-BR-B goes down. In this case traffic to hosts whose addresses were assigned out of Pref-A would be handled as before. But traffic to hosts whose addresses were assigned out of Pref-B would flow through ISP-B to ISP-BR-B, ISP-BR-B would encapsulate this traffic and send it to E- BR-A, where the traffic will get decapsulated and then be sent into the enterprise. Figure 2 below describes this approach graphically. 企業と両ISPの間に接続性である時(ISP-AとISP-Bが稼動)、Pref-Aから 割当てられたアドレスのホストに向かうトラフィックはISP-AとISP-BR-Aと E-BR-Aを通して企業に流れるでしょう。同じく、Pref-Bから割り当てられた アドレスのホストに向かうトラフィックがISP-BとISP-BR-BとE-BR-Bを通し て企業に流れるでしょう。ISP-BR-BとE-BR-Bの間の接続性が停止する時、何 が起きるか考えてください。この場合Pref-Aからアドレスを割り当てられた ホストへのトラフィックが前と同じように処理されるでしょう。けれども Pref-Bからアドレスを割り当てられたホストへのトラフィックが ISP-Bから ISP-BR-Bを通りISP-BR-Bでカプセル化されE-BR-Aに送られ、カプセル化が解 かれ企業にトラフィックが送られるでしょう。下記図2がこのアプローチを 記述します。 +---------+ +---------+ ( ) ( ) ( ISP-A ) ( ISP-B ) ( ) ( ) +---------+ +---------+ | | +--------+ +--------+ |ISP-BR-A| |ISP-BR-B| +--------+ +--------+ | /+/ | /\ | Pref-B /+/ | || | /+/ \./ Pref-A| /+/ non- /.\ || | /+/ direct | | /+/ EBGP | +------+ +-------+ |E-BR-A|-----------|E-BR-B | +------+ IBGP +-------+ Figure 2: Reachability information advertised via non-direct EBGP 図2:到達可能性情報の非直接EBGP広告 Observe that with this scheme there is no additional routing information due to multi-homed enterprises that has to be carried in the "default-free" zone of the Internet. In addition this scheme doesn't degrade in the presence of ISPs that filter out routes based on the length of their address prefixes. この案はインターネットの「デフォルトなし」ゾーンを運ばれなけれるマル チホーム企業のための追加の経路情報がないと言えます。加えてこの案は、 アドレスプレフィックスの長さに基づいて経路をフィルターするISPがあっ ても、質を落としません。 Note that the set of routers within an ISP that maintain non-direct peering with the border routers within an enterprise doesn't have to be restricted to the ISP's border routers that have direct peering with the enterprise's border routers. The non-direct peering could be maintained with any router within the ISP. Doing this could improve the overall robustness in the presence of failures within the ISP. 企業と直接でないピアリングをするISPの境界ルータは、企業の境界ルー タと直接ピアリングをするISPの境界ルータに制限されないことに注意し てください。直接でないピアリングはISPの中のどのルーターでも行えま す。これによりISP内での障害に対して全体的な安定を改善できます。 5.3. Combining the two 5.3. 2つの結合 One could observe that while the approach described in Section 5.2 allows to completely eliminate the routing overhead due to multi- homed enterprises in the "default-free" zone of the Internet, it may result in a suboptimal routing in the presence of link failures. The sub-optimality could be reduced by combining the approach described in Section 5.2 with a slightly modified version of the approach described in Section 5.1. The modification consists of constraining the scope of propagation of additional routes that are advertised by an enterprise border router when the router detects problems with the Internet connectivity through its other border routers. A way to constrain the scope is by using the BGP Community attribute [RFC1997]. 5.2章で記述されたアプローチがインターネットの「デフォルトなしの」 ゾーンでマルチホーム企業のためのルーティングオーバーヘッドを完全に削 除できますが、リンク障害時に次善のルーティングをもたらすかもしれない と言えます。下位の最適化はは5.2章で記述されたアプローチと5.1章で 記述されたアプローチのわずかな修正バージョンを一緒にすることで減らす ことができます。修正は、ルーターがその他の境界ルータを通してインター ネット接続性における問題を検出する時、企業境界ルータによって広告され る追加のルートの普及の範囲を制限することから成ります。範囲を制限する 方法がBGP共同体属性[RFC1997]を使うことによります。 5.4. Better (more optimal) routing in steady state 5.4. 堅実状態でより良い(より最適な)ルーティング The approach described in this document assumes that in a steady state an enterprise border router would advertise to a directly connected ISP border router only the reachability to the address prefix that this ISP allocated to the enterprise. As a result, traffic originated by other enterprises connected to that ISP and destined to the parts of the enterprise numbered out of other address prefixes would not enter the enterprise at this border router, resulting in potentially suboptimal paths. To improve the situation the border router may (in steady state) advertise reachability not only to the address prefix that was allocated by the ISP that the router is directly connected to, but to the address prefixes allocated by some other ISPs (directly connected to some other border routers within the enterprise). Distribution of such advertisements should be carefully constrained, or otherwise this may result in significant additional routing information that would need to be maintained in the "default-free" part of the Internet. A way to constrain the distribution of such advertisements is by using the BGP Community attribute [RFC1997]. この文書で記述されたアプローチは正常状態で企業境界ルータが直接接続さ れたISP境界ルータにただこのISPが企業に割り当てたアドレスプレフィッ クスへの到達性だけを広告すると想定します。結果としてこのISPに接続 している他の企業から、この企業の他のアドレスプレフィックスがついた部 分までのトラヒックが、この境界ルータから企業に入らず、潜在的に次善の パスになります。状態を改善するために、境界ルータは(正常状態で)ルー ターが直接接続したISPから割り当てられたアドレスプレフィックスにだ けではなく、他の(企業か他の境界ルータに直接接続した)ISPによって 割り当てられたアドレスプレフィックスへの到達性を広告してもよいです。 このような広告の配布は慎重に制限されあるべきで、さもなければこれはイ ンターネットの「デフォルトなし」部分で保守される必要がある重要な追加 の経路情報をもたらします。このような広告の配布を制限する方法がBGP コミュニティ属性[RFC1997]を使うことです。 6. Comparison with other approaches 6. 他のアプローチとの比較 CIDR [RFC1518] proposes several possible address allocation strategies for multi-homed enterprises that are connected to multiple ISPs. The following briefly reviews the alternatives being used today, and compares them with the approaches described above. CIDR[RFC1518]は多数のISPに接続するマルチホーム企業に対していくつか の可能なアドレス割当戦略を提案します。次が今日使われている選択の手短か な振り返りで、それらと上記アプローチを比較します。 6.1. Solution 1 6.1. 解決策1 One possible solution suggested in [RFC1518] is for each multi-homed enterprise to obtain its IP address space independently from the ISPs to which it is attached. This allows each multi-homed enterprise to base its IP assignments on a single prefix, and to thereby summarize the set of all IP addresses reachable within that enterprise via a single prefix. The disadvantage of this approach is that since the IP address for that enterprise has no relationship to the addresses of any particular ISPs, the reachability information advertised by the enterprise is not aggregatable with any, but default route. results in the routing overhead in the "default-free" zone of the Internet of O(N), where N is the total number of multi-homed enterprises across the whole Internet that are connected to multiple ISPs. [RFC1518]で示唆した可能な解決策が各マルチホーム企業が接続するISPと 独立にIPアドレス空間を得る事です。これは各マルチホーム企業がひとつ のプレフィックスに基づきIP割当をし、ひとつのプレフィックスによって すべてのその企業に到達可能なIPアドレスを集約することを許します。こ のアプローチの不利はその企業のIPアドレスが特定のISPのアドレスと の関係も持っていないので、企業によって広告された到達性情報がデフォル トルート以外と集約可能でないことです。これはO(N)のインターネット の「デフォルトなし」ゾーンのルーティングオーバーヘッドをもたらします、 Nが多数のISPに接続しているインターネット全体のマルチホーム企業の 合計数です。 As a result, this approach can't be viewed as a viable alternative for all, but the enterprises that provide high enough degree of addressing information aggregation. Since by definition the number of such enterprises is likely to be fairly small, this approach isn't viable for most of the multi-homed enterprises connected to multiple ISPs. 結果としてこのアプローチは、十分高い情報集約を行える企業を除き、すべ てのために可能な選択肢だと見なされることができません。定義にからこの ような企業の数がかなり小さい可能性が高いので、このアプローチは多数の ISPに接続したマルチホーム企業の大部分で実行可能ではありません。 6.2. Solution 2 6.2. 解決策2 Another possible solution suggested in [RFC1518] is to assign each multi-homed enterprise a single address prefix, based on one of its connections to one of its ISPs. Other ISPs to which the multi-homed enterprise is attached maintain a routing table entry for the organization, but are extremely selective in terms of which other ISPs are told of this route and would need to perform "proxy" aggregation. Most of the complexity associated with this approach is due to the need to perform "proxy" aggregation, which in turn requires t addiional inter-ISP coordination and more complex router configuration. もう1つの[RFC1518]で提案された可能な解決策がISPとの接続の1つに基 づいて各マルチホーム企業にひとつのアドレスプレフィックスを割り当てる 事です。マルチホーム企業に接続する他のISPがこの組織への経路表項目 を維持するが、どのISPがこの経路を広告するかを極端に制限し、「プロク シ」集約を行う必要があるでしょう。このアプローチに対する複雑さの大部 分が「プロクシ」集約を行う必要のためで、これはISP間の追加の調整と より複雑なルーター設定を必要とします。 7. Discussion 7. 論議 The approach described in this document assumes that addresses that an enterprise would use are allocated based on the "address lending" policy. Consequently, whenever an enterprise changes its ISP, the enterprise would need to renumber part of its network that was numbered out of the address block that the ISP allocated to the enterprise. However, these issues are not specific to multihoming and should be considered accepted practice in todays internet. The approach described in this document effectively eliminates any distinction between single-home and multi-homed enterprise with respect to the impact of changing ISPs on renumbering. この文書で記述されたアプローチは企業が使うアドレスが「アドレス貸し付 け」ポリシーに基づいて割り当てられると想定します。従って、企業がIS Pを変える時は、元のISPが企業に割り当てたアドレスブロックのアドレ スを付け直す必要があるでしょう。しかし、この問題はマルチホーム固有で はなく、今日のインターネットに対しての受け入れられた慣習と思われるべ きです。この文書で記述されたアプローチはISPを変える際のリナンバリ ングの影響に関してシングルホームとマルチホーム企業の間に区別がありま せん。 The approach described in this document also requires careful address assignment within an enterprise, as address assignment impacts traffic distribution among multiple connections between an enterprise and its ISPs. 同じくこの文書で記述されたアプローチは、アドレス割当てが企業とISP 間の多数の接続の間でのトラフィック分布に影響を与えるから、企業内で注 意深いアドレス割当てを必要とします。 Both the issue of address assignment and renumbering could be addressed by the appropriate use of network address translation (NAT). The use of NAT for multi-homed enterprises is the beyond the scope of this document. アドレス割当ての問題とリナンバリングの両方がネットワークアドレス翻訳 (NAT)の適切な使用によって扱うことができます。マルチホーム企業で のNATの使用はこの文書の範囲外です。 Use of auto route injection (as described in Section 5.1) increases the number of routers in the default-free zone of the Internet that could be affected by changes in the connectivity of multi-homed enterprises, as compared to the use of provider-independed addresses (as described in Section 6.1). Specifically, with auto route injection when a multi-homed enterprise loses its connectivity through one of its ISPs, the auto injected route has to be propagated to all the routers in the default-free zone of the Internet. In contrast, when an enterprise uses provider-independent addresses, only some (but not all) of the routers in the default-free zone would see changes in routing when the enterprise loses its connectivity through one of its ISPs. (5.1章で記述される)自動経路注入の使用がインターネットのデフォルト なしゾーンの経路数を増やし、(6.1章で記述されるように)経路数はプロ バイダ独立アドレスの使用と比較してマルチホーム接続企業の接続性の変更 に依存してます。特に、マルチホーム企業がISPの1つを通しす接続性を 失う時の自動経路注入で、自動注入経路はインターネットのデフォルトなし ゾーンのすべてのルーターに普及させられなければなりません。それと対照 的に、企業がプロバイダに依存しないアドレスを使い、企業がISPの1つ を通しての接続性を失う時、デフォルトなしゾーン内のルーターの若干数 (全部ではない)だけが経路変更になるでしょう。 To supress excessive routing load due to link flapping the auto injected route has to be advertised until the connectivity via the other connection (that was previously down and that triggered auto route injection) becomes stable. ばたつくリンクによる極端なルーティング負荷を抑制するために、自動的に 注入された経路は他の接続(前にダウンして自動車経路注入を引き起こした 接続)の接続が安定するまで、広告されなければなりません。 Use of the non-direct EBGP approach (as described in Section 5.2) allows to eliminate route flapping due to multi-homed enterprises in the default-free zone of the Internet. That is the non-direct EBGP approach has better properties with respect to routing stability than the use of provider-independent addresses (as described in Section 6.1). (5.2章で記述される)直接でないEBGPアプローチの使用がインター ネットのデフォルトなしゾーンでマルチホーム企業のばたつく経路の削除を 許します。これは直接でないEBGPアプローチが、(6.1章で記述される ように)ルーティング安定性に関してプロバイダに依存しないアドレスの使 用より良い特性を持っているということです。 8. Applications to multi-homed ISPs 8. マルチホームISPへの適用。 The approach described in this document could be applicable to a small to medium size ISP that is connected to several upstream ISPs. The ISP would acquire blocks of addresses (address prefixes) from its upstream ISPs, and would use these addresses for allocations to its customers. Either auto route injection, or the non-direct EBGP approach, or a combination of both could be used by the ISP when peering with its upstream ISPs. Doing this would provide routability for the customers of such ISP, without advertsely affecting the overall scalability of the Internet routing system. この文書で記述されたアプローチはいくつかの上流ISPに接続している中 小ISPに適用でき得ます。ISPは上流ISPからアドレスブロック(ア ドレスプレフィックス)を獲得し、顧客に配分するためこれらのアドレスを 使うでしょう。自動経路注入や直接でないRBGP接続や両方の組合わせが、 上流ISPとピアリングする時使うことができます。これをすることでこの ようなISPは、インターネットルーティングシステムの全体的なスケーラ ビリティに影響を与えないで、顧客に接続性を供給するでしょう。 9. Security Considerations 9. セキュリティの考察 Since the non-direct EBGP approach (as described in Section 5.2) requires EBGP sessions between routers that are more than one IP hop from each other, routers that maintain these sessions should use an appropriate authentication mechanism(s) for BGP peer authentication. (5.2章で記述されるように)直接でないEBGPアプローチが1を超え るホップ数のルーター間にEBGPセッションを必要とするので、これら のセッションを持続するルータがBGPピア認証のために適切な認証メカ ニズムを使うべきです。 Security issues related to the IBGP peering, as well as the EBGP peering between routers that are one IP hop from each other are outside the scope of this document. IPの1ホップであるルーターの間にのEBGPピアリングと同様の、I BGPピアリングと関係があるセキュリティ問題がこの文書の範囲外です。 10. Acknowledgments 10. 謝辞 The authors of this document do not make any claims on the originality of the ideas described in this document. Anyone who thought about these ideas before should be given all due credit. この文書の著者はこの文書で記述された考えの独創性の宣言をしません。 前にこれらの考えについて考えた誰でもすべての当然与えられるべき成 果を与えられるべきです。 11. References 11. 参考文献 [RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993. [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC1773] Hanks, S., Li, T., Farinacci, T., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1773, October 1994. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G.J., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC2008] Rekhter, Y., and T. Li, "Implications of Various Address Allocation Policies for Internet Routing", BCP 7, RFC 2008, October 1996. 12. Authors' Addresses 12. 著者のアドレス Tony Bates Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 EMail: tbates@cisco.com Yakov Rekhter Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 EMail: yakov@cisco.com 13. Full Copyright Statement 13. 著作権表示全文 Copyright (C) The Internet Society (1998). All Rights Reserved. 著作権(C)インターネット学会(1998)。すべての権利は保留される。 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. この文書とここに含む情報は無保証で供給され、そしてインターネット学会 とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情 報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で ある事の保障を含め、すべての保証を拒否します。