[要約] RFC 2260は、複数のホームネットワークと複数のプロバイダーの接続をサポートするためのスケーラブルな方法を提案しています。この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.
Copyright（C）The Internet Society（1998）。全著作権所有。
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）に接続されたマルチホームエンタープライズのアドレス指定とルーティング戦略について説明します。
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.
複数のISPへのマルチホーミングの背後にある推進要因を、単一の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の両方に等しく適用できます。
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個の異なるブロックを取得します）。 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（企業とISP間の相互接続）へのノード（ホスト）のトポロジ的な近接度を、使用するアドレスプレフィックスの選択基準として使用することです。ノードへのアドレス割り当て。特定のノード（ホスト）には、単一の接頭辞からアドレスが割り当てられる場合や、異なる接頭辞のアドレスが割り当てられる場合があります。
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）このドキュメントで必要な場合にのみカバーされます。
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によって企業に割り当てられたアドレスプレフィックスへの到達可能性のアドバタイズを開始します。これにより、追加のルーティング情報がインターネットの「デフォルトフリー」ゾーンに挿入されます。ただし、インターネット内のすべてのマルチホーム企業が1つ以上の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つの境界ルーターが、EBGP（直接接続されたISPから）ピアリングを介して受信する一連の到達可能な宛先と、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として示します。 BR-AがISP-Aから（EBGP経由で）受信するルートのセットに、BR-AがBR-Bから（IBGP経由で）受信するルートのセットと空でない交差がある場合、BR-AはISP-Aにのみアドバタイズします。 Pref-Aへの到達可能性。交差点が空になると、BR-AはISP-A到達可能性をPref-AとPref-Bの両方にアドバタイズします。これは、交差点が空のままである限り続きます。交差点が空でなくなると、BR-AはPref-Bへの到達可能性のISP-Aへのアドバタイズを停止します（ただし、引き続きPref-Aへの到達可能性のISP-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の撤回を検出した場合、BR-Aは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が存在する場合、インターネット全体の完全な接続よりも少ない可能性があります。ただし、企業がどのようにルーティングとアドレッシングを設定するかに関係なく、これが問題になることを観察することができます。
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の直接接続されたボーダールーターだけでなく、ボーダールーターがエンタープライズ内の他のボーダールーターに直接接続されている1つ以上の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に流れます。同様に、アドレスが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に送信します。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内で障害が発生した場合の全体的な堅牢性を向上させることができます。
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]を使用することです。
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]を使用することです。
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に接続されているマルチホーム企業向けに、いくつかの可能なアドレス割り当て戦略を提案しています。以下は、現在使用されている代替案を簡単にレビューし、それらを上記のアプローチと比較します。
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]で提案されている解決策の1つは、各マルチホーム企業が、接続先の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に接続されているほとんどのマルチホーム企業では実行できません。
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.
[RFC1518]で提案されている別の可能なソリューションは、ISPへの接続の1つに基づいて、各マルチホームエンタープライズに単一のアドレスプレフィックスを割り当てることです。マルチホームエンタープライズが接続されている他のISPは、組織のルーティングテーブルエントリを維持しますが、このルートについて他のISPに通知し、 "プロキシ"集約を実行する必要があるという点で非常に選択的です。このアプローチに関連する複雑さのほとんどは、「プロキシ」集約を実行する必要があるためです。これには、さらに追加のISP間の調整とより複雑なルーター構成が必要です。
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.
このドキュメントで説明するアプローチは、企業が使用するアドレスが「アドレス貸与」ポリシーに基づいて割り当てられることを前提としています。その結果、企業がISPを変更するたびに、企業は、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).
非セクションEBGPアプローチ（セクション5.2で説明）を使用すると、インターネットのデフォルトフリーゾーンにあるマルチホームエンタープライズによるルートフラッピングを排除できます。つまり、非直接EBGPアプローチは、プロバイダーに依存しないアドレスを使用するよりもルーティングの安定性に関して優れた特性を持っています（セクション6.1で説明）。
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からアドレスブロック（アドレスプレフィックス）を取得し、これらのアドレスを使用して顧客に割り当てます。自動ルートインジェクション、非直接EBGPアプローチ、または両方の組み合わせのいずれかが、上流のISPとピアリングするときにISPによって使用される可能性があります。これを行うと、インターネットルーティングシステムの全体的なスケーラビリティに悪影響を与えることなく、そのようなISPの顧客にルーティング可能性を提供します。
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.
非セクションEBGPアプローチ（セクション5.2で説明）は、相互に複数のIPホップであるルーター間の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.
IBGPピアリング、および相互に1つのIPホップであるルーター間のEBGPピアリングに関連するセキュリティの問題は、このドキュメントの範囲外です。
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.
このドキュメントの作成者は、このドキュメントに記載されているアイデアの独創性については一切主張しません。以前にこれらのアイデアについて考えた人は、すべての正当な信用を与えられるべきです。
[RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[RFC1518] Rekhter、Y。、およびT. Li、「CIDRを使用したIPアドレス割り当てのアーキテクチャ」、RFC 1518、1993年9月。
[RFC1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y。、およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[RFC1773] Hanks, S., Li, T., Farinacci, T., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1773, October 1994.
[RFC1773] Hanks、S.、Li、T.、Farinacci、T。、およびP. Traina、「IPv4ネットワーク上のジェネリックルーティングカプセル化」、RFC 1773、1994年10月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G.J., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot G.J.、およびE. Lear、「プライベートインターネットのアドレス割り当て」、RFC 1918、1996年2月。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997] Chandra、R.、Traina、P。、およびT. Li、「BGP Communities Attribute」、RFC 1997、1996年8月。
[RFC2008] Rekhter, Y., and T. Li, "Implications of Various Address Allocation Policies for Internet Routing", BCP 7, RFC 2008, October 1996.
[RFC2008] Rekhter、Y。、およびT. Li、「インターネットルーティングのさまざまなアドレス割り当てポリシーの影響」、BCP 7、RFC 2008、1996年10月。
Tony Bates Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
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
Yakov Rekhter Cisco Systems、Inc. 170 West Tasman Drive San Jose、CA 95134 Eメール：yakov@cisco.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。