[要約] 要約：RFC 2270は、単一のプロバイダにホームされたサイトに専用のASを使用する方法について説明しています。目的は、ネットワークの効率性と柔軟性を向上させるために、ASの使用方法を提案することです。
Network Working Group J. Stewart
Request for Comments: 2270 ISI
Category: Informational T. Bates
R. Chandra
E. Chen
Cisco
January 1998
Using a Dedicated AS for Sites Homed to a Single Provider
単一プロバイダーをホームとするサイトでの専用ASの使用
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）。全著作権所有。
Abstract
概要
With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC1930.
インターネットの成長に伴い、BGP4を使用する顧客の数は大幅に増加しています。 RFC1930は、ASが必要であり、ASを使用する必要がある場合の一連のガイドラインを概説しています。ただし、この結果、顧客およびサービスプロバイダー（ISP）には問題が残ります。ガイドラインに基づいて割り当てられたASは必要ありませんが、特定の条件では、BGP4の使用が非常に実用的で、おそらく唯一の方法です。単一のISPをホームとする顧客を接続します。このペーパーでは、RFC1930に記載されている推奨事項に沿って、この問題の解決策を提案します。
With the increased growth of the Internet, the number of customers using BGP4 [1],[2] has grown significantly. RFC1930 [4] outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. These conditions are as follows:
インターネットの成長に伴い、BGP4 [1]、[2]を使用する顧客の数は大幅に増加しました。 RFC1930 [4]は、ASが必要であり、ASを使用する必要がある場合の一連のガイドラインを概説しています。ただし、この結果、顧客およびサービスプロバイダー（ISP）には問題が残ります。ガイドラインに基づいて割り当てられたASは必要ありませんが、特定の条件では、BGP4の使用が非常に実用的で、おそらく唯一の方法です。単一のISPをホームとする顧客を接続します。これらの条件は次のとおりです。
1) Customers multi-homed to single provider Consider the scenario outlined in Figure 1 below.
1）単一プロバイダーへのマルチホームのお客様以下の図1で概説されているシナリオを検討してください。
+-------+ +-------+
+----+ | | |
+------+ | | ISP A +------+ ISP B |
| Cust.+---+ | | | |
| X +--------+ | | |
+------+ ++-----++\ +-------+
| | \
| | \ +--------+
++-----++ +-| |
| Cust. | | ISP C |
| Y | | |
+-------+ +--------+
Figure 1: Customers multi-home to a single provider
図1：顧客が単一のプロバイダーにマルチホームする
Here both customer X and customer Y are multi-homed to a single provider, ISP A. Because these multiple connections are "localized" between the ISP A and its customers, the rest of the routing system (ISP B and ISP C in this case) doesn't need to see routing information for a single multi-homed customer any differently than a singly-homed customer as it has the same routing policy as ISP A relative to ISP B and ISP C. In other words, with respect to the rest of the Internet routing system the organization is singly-homed, so the complexity of the multiple connections is not relevant in a global sense. Autonomous System Numbers (AS) are identifiers used in routing protocols and are needed by routing domains as part of the global routing system. However, as [4] correctly outlines, organizations with the same routing policy as their upstream provider do not need an AS.
ここでは、顧客Xと顧客Yの両方が単一のプロバイダーISP Aにマルチホーム化されています。これらの複数の接続はISP Aとその顧客の間で「ローカライズ」されているため、残りのルーティングシステム（この場合はISP BとISP C） ）は、シングルホームの顧客とは異なり、シングルホームの顧客のルーティング情報を見る必要はありません。ISPBとISP Cに対してISP Aと同じルーティングポリシーを持っているためです。つまり、組織がシングルホームであるインターネットルーティングシステムの残りの部分なので、複数の接続の複雑さはグローバルな意味では関係ありません。自律システム番号（AS）は、ルーティングプロトコルで使用される識別子であり、グローバルルーティングシステムの一部としてルーティングドメインに必要です。ただし、[4]が正しく概説しているように、アップストリームプロバイダーと同じルーティングポリシーを持つ組織には、ASは必要ありません。
Despite this fact, a problem exists in that many ISPs can only support the load-sharing and reliability requirements of a multi-homed customer if that customer exchanges routing information using BGP-4 which does require an AS as part of the protocol.
この事実にもかかわらず、顧客がプロトコルの一部としてASを必要とするBGP-4を使用してルーティング情報を交換する場合、マルチホーム顧客の負荷共有と信頼性の要件のみをサポートできるという問題が存在します。
2) Singly-homed customers requiring dynamic advertisement of NLRI's
2）NLRIの動的広告を必要とするシングルホームの顧客
While this is not a common case as static routing is generally used for this purpose, if a large amount of NLRI's need to be advertised from the customer to the ISP it is often administratively easier for these prefixes to be advertised using a dynamic routing protocol. Today, the only exterior gateway protocol (EGP) that is able to do this is BGP. This leads to the same problem outlined in condition 1 above.
静的ルーティングがこの目的で一般的に使用されるため、これは一般的なケースではありませんが、大量のNLRIを顧客からISPにアドバタイズする必要がある場合、動的ルーティングプロトコルを使用してこれらのプレフィックスをアドバタイズする方が管理上容易です。今日、これを実行できる唯一の外部ゲートウェイプロトコル（EGP）はBGPです。これにより、上記の条件1で概説した同じ問題が発生します。
As can be seen there is clearly a problem with the recommendations set forth in [4] and the practice of using BGP4 in the scenarios above. Section 2 proposes a solution to this problem with following sections describing the implications and application of the proposed solution.
見てわかるように、[4]で説明されている推奨事項と、上記のシナリオでBGP4を使用する方法には明らかに問題があります。セクション2では、この問題の解決策を提案します。次のセクションでは、提案された解決策の意味と応用について説明します。
It should also be noted that if a customer is multi-homed to more than one ISP then they are advised to obtain an official allocated AS from their allocation registry.
また、顧客が複数のISPにマルチホームしている場合は、割り当てレジストリから正式に割り当てられたASを取得することをお勧めします。
The solution we are proposing is that all BGP customers homed to the same single ISP use a single, dedicated AS specified by the ISP.
私たちが提案しているソリューションは、同じ単一のISPに所属するすべてのBGP顧客が、ISPによって指定された単一の専用ASを使用することです。
Logically, this solution results in an ISP having many peers with the same AS, although that AS exists in "islands" completely disconnected from one another.
論理的には、このソリューションの結果、ISPは同じASを持つ多くのピアを持つことになりますが、そのASは互いに完全に切り離された「アイランド」に存在します。
Several practical implications of this solution are discussed in the next section.
このソリューションのいくつかの実際的な影響については、次のセクションで説明します。
The solution precludes the ability for a BGP customer using the dedicated AS to receive 100% full routes. Because of routing loop detection of AS path, a BGP speaker rejects routes with its own AS number in the AS path. Imagine Customer X and Customer Y maintain BGP peers with Provider A using AS number N. Then, Customer X will not be able to received routes of Customer Y. We do not believe that this would cause a problem for Customer X, though, because Customer X and Customer Y are both stub networks so default routing is adequate, and the absence of a very small portion of the full routing table is unlikely to have a noticeable impact on traffic patterns guided by MEDs received.
このソリューションでは、専用ASを使用するBGP顧客が100％の完全なルートを受信することができません。 ASパスのルーティングループ検出のため、BGPスピーカーは、ASパスに独自のAS番号を持つルートを拒否します。お客様Xとお客様YがAS番号Nを使用してプロバイダーAとのBGPピアを維持していると想像してください。そうすると、お客様Xはお客様Yのルートを受信できなくなります。 XとカスタマーYはどちらもスタブネットワークであるため、デフォルトのルーティングで十分であり、完全なルーティングテーブルの非常に小さい部分がないことは、受信したMEDによって導かれるトラフィックパターンに顕著な影響を与える可能性は低いです。
A BGP customer using the dedicated AS must carry a default route (preferably receiving from its provider via BGP).
専用ASを使用するBGPカスタマーは、デフォルトルートを運ぶ必要があります（できればBGP経由でプロバイダーから受信する）。
The dedicated AS specified by a provider is purely for use in peering between its customers and the provider. When a customer using the dedicated AS changes its external connectivity, it may be necessary for the customer to reconfigure their network to use a different AS number (either a globally unique one if homed to multiple providers, or a dedicated AS of a different provider).
プロバイダーによって指定された専用ASは、純粋にその顧客とプロバイダー間のピアリングで使用するためのものです。専用ASを使用しているお客様が外部接続を変更した場合、別のAS番号（複数のプロバイダーに所属する場合はグローバルに一意の番号、または異なるプロバイダーの専用AS）を使用するようにネットワークを再構成する必要がある場合があります。 。
As BGP customers using this dedicated AS are only homed to one ISP, their routes allocated from its providers CIDR block do not need to be announced upstream by its provider as the providers will already be originating the larger block. [6].
この専用ASを使用するBGP顧客は1つのISPにのみホームしているため、プロバイダーCIDRブロックから割り当てられたルートは、プロバイダーがすでに大きなブロックを発信しているため、プロバイダーによってアップストリームにアナウンスされる必要はありません。 [6]。
The Internet Routing Registry (IRR) [5] is used by providers to generate route filtering lists. Such lists are derived primarily from the "origin" attribute of the route objects. The "origin" is the AS that originates the route. With multiple customers using the same AS, finer granularity will be necessary to generate the correct route filtering. For example, the "mntner" attribute or the "community" attribute of a route object can be used along with the "origin" attribute in generating the filtering lists.
インターネットルーティングレジストリ（IRR）[5]は、プロバイダーがルートフィルタリングリストを生成するために使用します。このようなリストは、主にルートオブジェクトの「origin」属性から取得されます。 「origin」はルートを発信するASです。複数の顧客が同じASを使用する場合、正しいルートフィルタリングを生成するには、より細かい粒度が必要になります。たとえば、ルートオブジェクトの「mntner」属性または「community」属性は、フィルタリングリストの生成で「origin」属性と一緒に使用できます。
The AS number specified by a provider can either be an AS from the private AS space (64512 - 65535) [4], or be an AS previously allocated to the provider. With the former, the dedicated AS like all other private AS's should be stripped from its AS path while the route is being propagated to the rest of the Internet routing system.
プロバイダーによって指定されたAS番号は、プライベートASスペース（64512-65535）[4]からのAS、または以前にプロバイダーに割り当てられたASのいずれかです。前者の場合、他のすべてのプライベートASと同様に専用ASは、ルートがインターネットルーティングシステムの残りの部分に伝播されている間に、そのASパスから取り除かれる必要があります。
The usage of AS numbers described in this document has no effective security impact. Acceptance and filtering of AS numbers from customers is an issue dealt with in other documents.
このドキュメントで説明されているAS番号の使用は、効果的なセキュリティへの影響はありません。顧客からのAS番号の受け入れとフィルタリングは、他のドキュメントで扱われている問題です。
The authors would like to thank Roy Alcala of MCI and Arpakorn Boonkongchuen for their input to this document. The members of the IDR Working Group also provided helpful comments.
著者は、このドキュメントへの入力について、MCIのロイアルカラとアルパコーンブーンコンチュエンに感謝します。 IDRワーキンググループのメンバーも役立つコメントを提供しました。
[1] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[1] Rekhter、Y。、およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[2] Rekhter, Y., and P. Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995.
[2] Rekhter、Y.、P。Gross、「Application in the Border Gateway Protocol in the Internet」、RFC 1772、1995年3月。
[3] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787, April 1995.
[3] Rekhter、Y。、「マルチプロバイダーインターネットでのルーティング」、RFC 1787、1995年4月。
[4] Hawkinson, J., and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996.
[4] Hawkinson、J。、およびT. Bates、「自律システム（AS）の作成、選択、および登録に関するガイドライン」、RFC 1930、1996年3月。
[5] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M, Karrenberg, D., Terpstra, M., and J. Yu., "Representation of IP Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, March 1995.
[5] Bates、T.、Gerich、E.、Joncheray、L.、Jouanigot、JM、Karrenberg、D.、Terpstra、M.、J。Yu。、「ルーティングレジストリでのIPルーティングポリシーの表現（ripe-81 + +） "、RFC 1786、1995年3月。
[6] Chen, E., and J. Stewart., "A Framework for Inter-Domain Route Aggregation", Work in Progress.
[6] Chen、E.、and J. Stewart。、 "A Framework for Inter-domain Route Aggregation"、Work in Progress。
John Stewart USC/ISI 4350 North Fairfax Drive Suite 620 Arlington, VA 22203
John Stewart USC / ISI 4350 North Fairfax Drive Suite 620 Arlington、VA 22203
EMail: jstewart@isi.edu
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
Ravi Chandra Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Ravi Chandra Cisco Systems、Inc. 170 West Tasman Drive San Jose、CA 95134
EMail: rchandra@cisco.com
Enke Chen Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Enke Chen Cisco Systems、Inc. 170 West Tasman Drive San Jose、CA 95134
EMail: enkechen@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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。