RFC1520 日本語訳

Network Working Group                                         Y. Rekhter
Request for Comments: 1520        T.J. Watson Research Center, IBM Corp.
Category: Informational                                      C. Topolcic
                                                                    CNRI
                                                          September 1993

Rekhterがコメントのために要求するワーキンググループY.をネットワークでつないでください: 1520 T.J.ワトソン研究所、IBM社のカテゴリ: 情報のC.Topolcic CNRI1993年9月

       Exchanging Routing Information Across Provider Boundaries
                        in the CIDR Environment

CIDR環境におけるプロバイダー限界の向こう側に経路情報を交換します。

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

1.  Introduction

1. 序論

   Classless Inter-Domain Routing (CIDR) has been adopted as a solution
   to the scaling problem in the Internet. The overall CIDR architecture
   is described in [1]. The architecture for IP address assignment with
   CIDR is covered in [2] and [3]. The inter-domain routing protocols
   that are capable of supporting CIDR are covered in [4], [5], and [6].

階級のないInter-ドメインルート設定(CIDR)はインターネットのスケーリング問題の解決として採用されました。 総合的なCIDR構造は[1]で説明されます。 CIDRとのIPアドレス課題のための構造は[2]と[3]でカバーされています。 CIDRを支持できる相互ドメインルーティング・プロトコルは[4]、[5]、および[6]でカバーされています。

   The purpose of this document is twofold. First, it describes various
   alternatives for exchanging inter-domain routing information across
   domain boundaries, where one of the peering domain is CIDR-capable
   and another is not.  Second, it addresses the implications of running
   CIDR-capable inter-domain routing protocols (e.g., BGP-4, IDRP) on
   intra-domain routing.

このドキュメントの目的は二つです。 まず最初に、それはドメイン境界の向こう側に相互ドメインルーティング情報を交換するための様々な代替手段を説明します。そこでは、じっと見るドメインの1つがCIDRできて、別のものはできません。 2番目に、それはイントラドメインルーティングに走行のCIDRできる相互ドメインルーティング・プロトコル(例えば、BGP-4、IDRP)の含意を記述します。

   This document is not intended to cover all the cases (either real or
   imaginable). Rather, it focuses on what are viewed to be the most
   common cases.  We expect that individual service providers will use
   this document as guidelines in establishing their specific
   operational plans for the transition to CIDR.

このドキュメントがすべてのケース(本当の、または、想像可能な)をカバーすることを意図しません。 むしろ、それは何が最も一般的なケースになるように見られるかに集中します。 私たちは、個々のサービスプロバイダーがCIDRへの変遷にガイドラインとしてそれらの特定の操作上のプランを確立する際にこのドキュメントを使用すると予想します。

   The concepts of "network service provider" and "network service
   subscriber" were introduced in [3]. For the sake of brevity, we will
   use the term "provider"  or "service provider" here to mean either
   "network service provider" or "network service subscriber", since for
   the most part, the distinction is not important to this discussion.
   Furthermore, we use the same terms to refer to the network and to the
   organization that operates the network. We feel that the context
   makes it amply clear whether we are talking about hardware or people,
   and defining different terms would only make this paper harder to
   read.

「ネットワークサービスプロバイダー」と「ネットワーク・サービス加入者」の概念は[3]で紹介されました。 簡潔にするために、私たちは「ネットワークサービスプロバイダー」か「ネットワーク・サービス加入者」のどちらかを意味するのにここで「プロバイダー」か「サービスプロバイダー」という用語を使用するつもりです、区別がこの議論にだいたい重要でないので。 その上、私たちは、ネットワークとネットワークを経営する組織を参照するのに同じ用語を使用します。 ハードウェアか人々に関して話しているか否かに関係なく、私たちは、文脈が十分にそれを明らかにすると感じます、そして、異なった用語を定義するのがこの紙を読むのをより困難にするだけでしょう。

Rekhter & Topolcic                                              [Page 1]

RFC 1520           CIDR Provider Information Exchange     September 1993

Rekhter&Topolcic[1ページ]RFC1520CIDRプロバイダー情報交換1993年9月

   This document defines a CIDR-capable provider as the provider that
   can perform correct IP packet forwarding (both internally and to
   other adjacent providers) when the inter-domain routing information
   acquired by the provider is expressed solely in terms of IP address
   prefixes (with no distinction between A/B/C class of addresses).

このドキュメントは唯一IPアドレス接頭語(A/B/Cのクラスのアドレスでの区別のない)でプロバイダーによって取得された相互ドメインルーティング情報が言い表されるとき正しいIPパケット推進(内部的と他の隣接しているプロバイダーへの)を実行できるプロバイダーとCIDRできるプロバイダーを定義します。

   This document defines CIDR-capable forwarding as the ability of a
   router to maintain its forwarding table and to perform correct
   forwarding of IP packets without making any assumptions about the
   class of IP addresses.

このドキュメントはルータが推進テーブルを維持して、IPのクラスに関するどんな仮定もアドレスにしないでIPパケットの正しい推進を実行する能力とCIDRできる推進を定義します。

   This document defines CIDR reachability information as reachability
   information that may violate any assumptions about the class of IP
   addresses. For instance, a contiguous block of class C networks
   expressed as a single IP address prefix constitutes CIDR reachability
   information.

このドキュメントはIPアドレスのクラスに関するどんな仮定にも違反する可到達性情報とCIDR可到達性情報を定義します。 例えば、ただ一つのIPアドレス接頭語として表されたクラスCネットワークの隣接のブロックはCIDR可到達性情報を構成します。

2.  Taxonomy of Service Providers

2. サービスプロバイダーの分類学

   For the purpose of this document we partition all service providers
   into the following categories, based on the type and volume of
   inter-domain routing information a provider needs to acquire in order
   to meet its service requirements:

このドキュメントの目的のために、私たちはすべてのサービスプロバイダーを以下のカテゴリに仕切ります、プロバイダーがサービス要件を満たすために取得する必要がある相互ドメインルーティング情報のタイプとボリュームに基づいて:

      - Requirements imposed on a service provider preclude it from
        using Default inter-domain route(s) -- we'll refer to such a
        pqrovider as a Type 1 provider.

- サービスプロバイダーに課された要件はDefault相互ドメインルートを使用するので、それを排除します--私たちはType1プロバイダーのようなpqroviderについて言及するつもりです。

      - Requirements imposed on a service provider allow it to rely on
        using one or more Default routes for inter-domain routing, but
        this information must be supplemented by requiring the provider
        to acquire a large percentage of total Internet routing
        information -- we'll refer to such a provider as a Type 2
        provider.

- 総インターネット・ルーティング情報の大きな割合を取得するためにプロバイダーを必要とすることによって、この情報を補わなければなりません--それはサービスプロバイダーに課された要件によって相互ドメインルーティングに1つ以上のDefaultルートを使用するのを当てにされますが、私たちはType2プロバイダーのようなプロバイダーを示すつもりです。

      - Requirements imposed on a service provider allow it to rely on
        using one or more Default routes for inter-domain routing;
        however, to meet its service requirements the provider must
        supplement Default route(s) by acquiring a small percentage of
        total Internet routing information -- we'll refer to such a
        provider as a Type 3 provider.

- サービスプロバイダーに課された要件は相互ドメインルーティングに1つ以上のDefaultルートを使用するのを当てにさせます。 しかしながら、サービス要件を満たすために、プロバイダーはわずかな百分率の総インターネット・ルーティング情報を取得することによって、Defaultルートを補わなければなりません--私たちはType3プロバイダーのようなプロバイダーを示すつもりです。

      - Requirements imposed on a service provider allow it to rely
        solely on using one or more Default routes for inter-domain
        routing; no other inter-domain routing information need to be
        acquired -- we'll refer to such a provider as a Type 4 provider.

- サービスプロバイダーに課された要件は唯一相互ドメインルーティングに1つ以上のDefaultルートを使用するのを当てにさせます。 他の取得されるべき相互ドメインルーティング情報の必要性がありません--私たちはType4プロバイダーのようなプロバイダーを示すつもりです。

Rekhter & Topolcic                                              [Page 2]

RFC 1520           CIDR Provider Information Exchange     September 1993

Rekhter&Topolcic[2ページ]RFC1520CIDRプロバイダー情報交換1993年9月

3.  Assumptions on Deployment of CIDR in the Internet

3. インターネットでのCIDRの展開の仮定

   The document assumes that the CIDR deployment in the Internet will
   proceed as a three phase process.

ドキュメントは、インターネットでのCIDR展開が三相の過程として続くと仮定します。

   In the first phase all the major service providers will become CIDR-
   capable. Specifically, all the providers that can't rely on using
   Default route(s) for inter-domain routing (Type 1 providers) are
   expected to deploy BGP-4 and transition to CIDR during this phase. It
   is expected that CIDR reachability information will first appear in
   the Internet upon transition of all Type 1 service providers to CIDR.

第1段階では、すべての主要サービスプロバイダーができるCIDRになるでしょう。 明確に、相互ドメインルーティング(1プロバイダーをタイプする)にDefaultルートを使用するのを当てにされることができるというわけではないすべてのプロバイダーがこの段階の間、BGP-4とCIDRへの変遷を配備すると予想されます。 CIDR可到達性情報がすべてのType1サービスプロバイダーのCIDRへの変遷のときに最初にインターネットに現れると予想されます。

   The second phase will commence upon completion of the first phase.
   During the second phase other service providers that are connected to
   the service providers that were transitioned to CIDR during the first
   phase will become CIDR-capable.  Specifically, during the second
   phase it is expected that most of the providers that need to acquire
   a large percentage of the total Internet routing information (Type 2
   provider) will become CIDR-capable.  In addition, during the second
   phase some of the Type 3 providers may become CIDR-capable as well.
   This plan was agreed to by a number of major providers [8]. NSFNET's
   steps to implement this plan are described in [9].

2番目のフェーズは第1段階の完成のときに始まるでしょう。 移行したサービスプロバイダーに接続される2番目のフェーズ他のサービスプロバイダーの間、第1段階の間のCIDRはCIDRできるようになるでしょう。 明確に、2番目の段階の間、合計の大きな割合に、インターネット・ルーティング情報(2プロバイダーをタイプする)を取得する必要があるプロバイダーの大部分がCIDRできるようになると予想されます。 また、さらに、2番目の段階の間、Type3プロバイダーのいくつかがCIDRできるようになるかもしれません。 このプランは多くの主要なプロバイダー[8]によって同意されました。 このプランを実行するNSFNETのステップは[9]で説明されます。

   Finally, during the third phase the rest of the Type 3 providers and
   most of the Type 4 providers will transition to CIDR.

最終的に、3番目の段階の間、Type3プロバイダーとType4プロバイダーの大部分の残りはCIDRへの変遷がそうするでしょう。

   It is expected that the duration of the first phase will be
   significantly shorter than duration of the second phase.  Likewise,
   the duration of the second phase is expected to be shorter than the
   duration of the third phase.

第1段階の持続時間が2番目のフェーズの持続時間よりかなり短くなると予想されます。 同様に、2番目のフェーズの持続時間が3番目のフェーズの持続時間より短いと予想されます。

   This document addresses the need for service providers to exchange
   inter-domain routing information during the second and third phases
   of this deployment. During these phases, some providers will be
   CIDR-capable, and others will not. Hence this document considers
   routing exchanges where one of the peers is CIDR-capable and the
   other is CIDR-incapable.

このドキュメントはサービスプロバイダーがこの展開の2番目と3番目の段階の間に相互ドメインルーティング情報を交換する必要性を記述します。 これらの段階の間、いくつかのプロバイダーがCIDRできるようになって、他のものはできないでしょう。 したがって、このドキュメントは、同輩のひとりがCIDRできて、もう片方がCIDR不可能であるところに交換を発送すると考えます。

4.  Implications of CIDR on Interior Routing

4. 内部のルート設定でのCIDRの含意

   A CIDR-capable service provider can use the following two techniques
   to distribute exterior routing information to all of its routers
   (both interior and border):

CIDRできるサービスプロバイダーはルータ(内部と境界の両方)のすべてに外のルーティング情報を分配するのに以下の2つのテクニックを使用できます:

      - utilize internal BGP/IDRP between all the routers

- すべてのルータの間で内部のBGP/IDRPを利用してください。

      - use CIDR-capable IGPs (e.g., OSPF, IS-IS, RIP2)

- CIDRできるIGPsを使用してください。(例えば、OSPF、-、RIP2)

Rekhter & Topolcic                                              [Page 3]

RFC 1520           CIDR Provider Information Exchange     September 1993

Rekhter&Topolcic[3ページ]RFC1520CIDRプロバイダー情報交換1993年9月

   The first technique doesn't impose any addition requirements on the
   IGP within the provider. Additional information on implementing the
   first option is presented in [5] (see Section A.2.4).

最初のテクニックはプロバイダーの中でどんな添加要件もIGPに課しません。 第1の選択を実行する追加情報は[5]に提示されます(セクションA.2.4を見てください)。

   The second technique allows the provider to reduce the utilization of
   internal BGP/IDRP, but imposes specific requirements on the intra-
   domain routing. It also requires the ability to inject inter-domain
   routing information (acquired either via BGP or IDRP) into the
   intra-domain routing. Additional details on implementing the second
   option are provided in [7]. It is not expected that all the features
   enumerated in [7] will be widely needed. Therefore, it would be
   highly desirable to prioritize the features.

2番目のテクニックは、プロバイダーが内部のBGP/IDRPの利用を抑えるのを許容しますが、イントラドメインルーティングに決められた一定の要求を課します。 また、それは相互ドメインルーティング情報(BGPかIDRPを通して、取得する)をイントラドメインルーティングに注入する能力を必要とします。 2番目のオプションを実行することに関する追加詳細は[7]に明らかにされます。 [7]で列挙されたすべての特徴は広く必要でないと予想されます。 したがって、特徴を最優先させるのは非常に望ましいでしょう。

   Note that both of these techniques imply that all the routers within
   a CIDR-capable service provider need to be capable of CIDR-based
   forwarding.

これらのテクニックの両方が、CIDRできるサービスプロバイダーの中のすべてのルータが、CIDRベースの推進ができる必要であるのを含意することに注意してください。

   Discussion of which of the two techniques should be preferred is
   outside the scope of this document.

このドキュメントの範囲の外に2つのテクニックのどれが好まれるべきであるかに関する議論があります。

5.  Exchanging Inter-Domain Routing Information

5. 相互ドメイン経路情報を交換します。

   At each phase during the transition to CIDR one of the essential
   aspects of the Internet operations will be the exchange of inter-
   domain routing information between CIDR-capable providers and CIDR-
   incapable provider.

インターネットの不可欠の局面のCIDR1への変遷の間の各フェーズでは、操作はCIDRできるプロバイダーとCIDRの不可能なプロバイダーの間の相互ドメインルーティング情報の交換になるでしょう。

   When exchanging inter-domain routing information between a CIDR-
   capable provider and a CIDR-incapable provider, it is of utmost
   importance to take into account the view each side wants the other to
   present. This view has two distinct aspects:

CIDRのできるプロバイダーとCIDR不可能なプロバイダーの間で相互ドメインルーティング情報を交換するとき、それは、それぞれの側が、もう片方が提示する必要がある視点を考慮に入れるためには最重要性のものです。 この視点には、2つの異なった局面があります:

      - the type of routing information exchanged (i.e., Default route,
        traditional (non-CIDR) reachability information, CIDR
        reachability information)

- 情報が交換したルーティングのタイプ(すなわち、Defaultルート、伝統的な(非CIDRの)可到達性情報、CIDR可到達性情報)

      - routing information processing each side needs to do to maintain
        these views (e.g., ability to perform aggregation, ability to
        perform controlled de-aggregation)

- これらの視点を維持するためにそれぞれの側が必要とする情報処理を発送します。(例えば、履行能力集合、履行能力の制御反-集合)

   The exchange of inter-domain routing information is expected to be
   controlled by bilateral agreements between the directly connected
   service providers. Consequently, the views each side wants of the
   other are expected to form an essential component of such agreements.

直接接続されたサービスプロバイダーの間の二国間条約によって相互ドメインルーティング情報の交換が制御されると予想されます。 その結果、それぞれの側が必要とするもう片方の視点がそのような協定の必須成分を形成すると予想されます。

   To facilitate troubleshooting and problem isolation, the bilateral
   agreements should be made accessible to other providers.  One way to
   accomplish this is by placing them in a generally accessible

トラブルシューティングと問題孤立、二国間条約を容易にするのを他のプロバイダーにアクセスしやすくするべきです。 これを達成するある方法はそれらをaに一般に、アクセスしやすい状態で置くことです。

Rekhter & Topolcic                                              [Page 4]

RFC 1520           CIDR Provider Information Exchange     September 1993

Rekhter&Topolcic[4ページ]RFC1520CIDRプロバイダー情報交換1993年9月

   database. The details of how this can be implemented are outside the
   scope of this document. A possible way to accomplish this is
   described in [9].

データベース。 このドキュメントの範囲の外にどうこれを実行できるかに関する詳細があります。 これを達成する可能な方法は[9]に述べられます。

   Since the exchange of inter-domain routing information across
   provider boundaries occurs on a per peer basis, a border router is
   expected to provide necessary mechanisms (e.g., configuration) that
   will control exchange and processing of this information on a per
   peer basis.

プロバイダー限界の向こう側の相互ドメインルーティング情報の交換が同輩基礎あたりのaに起こるので、境界ルータが同輩基礎あたりのaにおけるこの情報の交換と処理を制御する必要なメカニズム(例えば、構成)を提供すると予想されます。

   In the following sections we describe possible scenarios for
   exchanging inter-domain routing information. It is always assumed
   that one side is CIDR-capable and the other is not.

以下のセクションで、私たちは、相互ドメインルーティング情報を交換するために可能なシナリオについて説明します。 いつも半面がCIDRできると思われて、もう片方はそのように思われません。

5.1  Exchanging Inter-Domain Routing Information between CIDR-capable
     providers and CIDR-incapable Type 2 (default with large proportion
     of explicit routes) providers

5.1 CIDRできるプロバイダーとCIDR不可能なType2(明白なルートの大部分があるデフォルト)プロバイダーの間でInter-ドメイン経路情報を交換すること。

   We expect the border router(s) within a CIDR-capable provider to be
   capable of aggregating inter-domain routing information they receive
   from a CIDR-incapable Type 2 provider.  The aggregation is expected
   to be governed and controlled via a bilateral agreement.
   Specifically, the CIDR capable provider is expected to aggregate only
   the information the other side (the CIDR-incapable provider)
   requests. In other words, the aggregation shall be done by the CIDR-
   capable provider (the receiver) and only when agreed to by the CIDR-
   incapable provider (the sender).

私たちは、CIDRできるプロバイダーの中の境界ルータが彼らがCIDR不可能なType2プロバイダーから受け取る相互ドメインルーティング情報に集めることができると予想します。 集合は、二国間条約で治められて、制御されると予想されます。 明確に、CIDRのできるプロバイダーが反対側(CIDR不可能なプロバイダー)が要求する情報だけに集めると予想されます。 言い換えれば、CIDRのできるプロバイダー(受信機)とCIDRの不可能なプロバイダーによる(送付者)に同意するいつだけまでに集合をするものとするか。

   Passing inter-domain routing information from a CIDR-capable provider
   to a CIDR-incapable Type 2 provider will require an agreement between
   the two that would cover the following items:

CIDRできるプロバイダーからCIDR不可能なType2プロバイダーまで相互ドメインルーティング情報を通過するのは以下の項目をカバーする2つの間の協定を必要とするでしょう:

      - under what conditions the CIDR-capable provider can pass an
        inter-domain Default route to the CIDR-incapable provider

- CIDRできるプロバイダーはどんな条件のもとで相互ドメインDefaultルートをCIDR不可能なプロバイダーに渡すことができますか。

      - exchange of specific non-CIDR reachability information

- 特定の非CIDR可到達性情報の交換

      - controlled de-aggregation of CIDR reachability information

- CIDR可到達性情報の制御反-集合

   Agreements that cover the first two items are already implemented
   within the Internet. Thus, the only additional factor introduced by
   CIDR is controlled de-aggregation. A CIDR-capable provider may decide
   not to de-aggregate any CIDR reachability information, or to de-
   aggregate some or all of the CIDR reachability information.

最初の2つの項目をカバーする協定がインターネットの中で既に履行されます。 したがって、CIDRによって紹介された唯一の追加要素が制御反-集合です。 CIDRできるプロバイダーは、反-どんなCIDR可到達性情報にも集めないまたは反-CIDR可到達性情報のいくつかかすべてに集めると決めるかもしれません。

   If a CIDR-capable provider does not de-aggregate CIDR reachability
   information, then its non-CIDR Type 2 peer can obtain reachability
   information from it either as non-CIDR reachability information

CIDRできるプロバイダーが反-CIDR可到達性情報に集められないなら、非CIDR Type2同輩は非CIDR可到達性情報としてそれから可到達性情報を得ることができます。

Rekhter & Topolcic                                              [Page 5]

RFC 1520           CIDR Provider Information Exchange     September 1993

Rekhter&Topolcic[5ページ]RFC1520CIDRプロバイダー情報交換1993年9月

   (explicit Class A/B/C network advertisement) or as an inter-domain
   Default route.  Since most of the current reachability information in
   the Internet is non-CIDR, a Type 2 provider would be able to acquire
   this information as explicit Class A/B/C network advertisements from
   the CIDR-capable provider, as it does now.  Further, it is expected
   that at least on a temporary basis (until the completion of the
   second phase of the transition) in a majority of cases, Type 2
   providers should be able to use an inter-domain Default route
   (acquired from the CIDR-capable provider) as a way of dealing with
   forwarding to destinations covered by CIDR reachability information.

(明白なClass A/B/Cネットワーク広告)か相互ドメインDefaultルートとして。 インターネットの現在の可到達性情報の大部分が非CIDRであるので、明白なClass A/B/CがCIDRできるプロバイダーからの広告をネットワークでつなぐとき、Type2プロバイダーはこの情報を取得できるでしょう、現在するように。 さらに、そんなに少なくともケースの大部分、Typeの一時的ベース(変遷の2番目のフェーズの完成までの)で2つのプロバイダーがCIDR可到達性情報で覆われた目的地に推進に対処する方法として相互ドメインDefaultルート(CIDRできるプロバイダーから、取得する)を使用できるべきであると予想されます。

   Thus, it is expected that most of the cases involving a CIDR-capable
   Type 2 provider and a CIDR-capable provider that does not perform
   de-aggregation could be addressed by a combination of exchanging
   specific non-CIDR reachability information and an inter-domain
   Default route. Any inconvenience to a CIDR-incapable provider due to
   the use of an inter-domain Default route will be removed once the
   provider transitions to CIDR.

したがって、特定の非CIDR可到達性情報と相互ドメインDefaultルートを交換する組み合わせでCIDRできるType2プロバイダーと反-集合を実行しないCIDRできるプロバイダーにかかわるケースの大部分を記述できるだろうと予想されます。 プロバイダーがいったんCIDRに移行すると、相互ドメインDefaultルートの使用によるCIDR不可能なプロバイダーへのどんな不便も取り除くでしょう。

   On the other hand, a CIDR-capable provider may decide to perform
   controlled de-aggregation of CIDR reachability information.
   Additional information on performing controlled de-aggregation can be
   found in [5] (Section 8).  Special care must be taken when de-
   aggregating CIDR reachability information carried by a route with the
   ATOMIC_AGGREGATE path attribute.  It is worth while pointing out that
   due to the nature of Type 2 provider (it needs to acquire a large
   percentage of total inter-domain routing information) it is expected
   that the controlled de-aggregation would result in substantial
   configuration at the border router that performs the de-aggregation.

他方では、CIDRできるプロバイダーは、CIDR可到達性情報の制御反-集合を実行すると決めるかもしれません。 [5](セクション8)で制御反-集合を実行する追加情報を見つけることができます。 反-集合CIDR可到達性情報がATOMIC_AGGREGATE経路属性があるルートで運ばれたとき、特別な注意を払わなければなりません。 Type2プロバイダー(それは、総相互ドメインルーティング情報の大きな割合を取得する必要がある)の本質のため、制御反-集合が反-集合を実行する境界ルータにおけるかなりの構成をもたらすと予想されると指摘する価値があります。

5.2  Exchanging Inter-Domain Routing Information between CIDR-capable
     providers and CIDR-incapable Type 3 (Default with few explicit
     routes) providers

5.2 CIDRできるプロバイダーとCIDR不可能なType3(わずかな明白なルートがあるデフォルト)プロバイダーの間でInter-ドメイン経路情報を交換すること。

   In this case, as in the case described in Section 5.1, it is expected
   that a border router in a CIDR-capable provider would be able to
   aggregate routing information it receives from a CIDR-incapable Type
   3 provider. The aggregation is expected to be governed and controlled
   via a bilateral agreement.  Specifically, the CIDR capable provider
   is expected to aggregate only the information the CIDR-incapable
   provider requests.

この場合、セクション5.1で説明されたケースのように、CIDRできるプロバイダーにおける境界ルータがそれがCIDR不可能なType3プロバイダーから受け取るルーティング情報に集めることができると予想されます。 集合は、二国間条約で治められて、制御されると予想されます。 明確に、CIDRのできるプロバイダーがCIDR不可能なプロバイダーが要求する情報だけに集めると予想されます。

   The only difference between this case and the case described in
   Section 5.1 is the fact that a CIDR-incapable provider requires just
   a small percentage of total inter-domain routing information. If this
   information falls into a non-CIDR category, then a Type 3 provider
   would be able to acquire it from a CIDR-capable provider. If this is
   CIDR reachability information, then in a majority of cases it is

セクション5.1で説明された本件とケースの唯一の違いがCIDR不可能なプロバイダーがまさしくわずかな百分率の総相互ドメインルーティング情報を必要とするという事実です。 この情報が非CIDRカテゴリになるなら、Type3プロバイダーはCIDRできるプロバイダーからそれを取得できるでしょう。 これがそして、ケースの大部分のCIDR可到達性情報であるなら

Rekhter & Topolcic                                              [Page 6]

RFC 1520           CIDR Provider Information Exchange     September 1993

Rekhter&Topolcic[6ページ]RFC1520CIDRプロバイダー情報交換1993年9月

   expected that forwarding to destinations covered by this information
   could be handled via an inter-domain Default route.

相互ドメインDefaultルートでこの情報で覆われた目的地への推進を扱うことができるだろうと予想しました。

   It is still expected that a border router in a CIDR-capable provider
   would be able to aggregate routing information it receives from a
   CIDR-incapable Type 3 provider. The aggregation is expected to be
   governed and controlled via a bilateral agreement.  Specifically, the
   CIDR capable provider is expected to aggregate only the information
   the other side (the CIDR-incapable provider) requests.

CIDRできるプロバイダーにおける境界ルータがそれがCIDR不可能なType3プロバイダーから受け取るルーティング情報に集めることができるとまだ予想されています。 集合は、二国間条約で治められて、制御されると予想されます。 明確に、CIDRのできるプロバイダーが反対側(CIDR不可能なプロバイダー)が要求する情報だけに集めると予想されます。

5.3  Exchanging Inter-Domain Routing Information between CIDR-capable
     providers and CIDR-incapable Type 4 (Default only) providers

5.3 CIDRできるプロバイダーとCIDR不可能なType4(デフォルト専用)プロバイダーの間でInter-ドメイン経路情報を交換すること。

   Again, it is still expected that a border router in a CIDR-capable
   provider would be able to aggregate routing information it receives
   from a CIDR-incapable Type 4 provider. The aggregation is expected to
   be governed and controlled via a bilateral agreement.  Specifically,
   the CIDR capable provider is expected to aggregate only the
   information the CIDR-incapable provider requests.

一方、CIDRできるプロバイダーにおける境界ルータがそれがCIDR不可能なType4プロバイダーから受け取るルーティング情報に集めることができるとまだ予想されています。 集合は、二国間条約で治められて、制御されると予想されます。 明確に、CIDRのできるプロバイダーがCIDR不可能なプロバイダーが要求する情報だけに集めると予想されます。

   The only difference between this case and the case described in
   Section 5.1 is the fact that CIDR-incapable provider would not
   require any inter-domain routing information, other than the Default
   inter-domain route. Therefore, controlled de-aggregation of CIDR
   reachability information is not an issue.

セクション5.1で説明された本件とケースの唯一の違いがCIDR不可能なプロバイダーが少しの相互ドメインルーティング情報も必要としないだろうという事実です、Default相互ドメインルートを除いて。 したがって、CIDR可到達性情報の制御反-集合は問題ではありません。

6. Conclusions

6. 結論

   It is expected that the reduction in the global volume of routing
   information will begin immediately upon completion of the first phase
   of the transition to CIDR. The second phase will allow simpler
   bilateral arrangements between connected service providers by
   shifting the responsibility for routing information aggregation
   towards the parties that are better suitable for it, and by
   significantly reducing the need for routing information de-
   aggregation. Thus, most of the gain achieved during the second phase
   will come from simplifying bilateral agreements. The third phase it
   intended to complete the goals and objectives of the second phase.

ルーティング情報のグローバルなボリュームの減少がすぐCIDRへの変遷の第1段階の完成のときに始まると予想されます。2番目のフェーズは、ルーティング情報集合のためにそれにより十分適当なパーティーに向かって責任を押しつけて、ルーティング情報反-集合の必要性をかなり減少させることによって、接続サービスプロバイダーの間の、より簡単な双方のアレンジメントを許容するでしょう。 したがって、2番目の段階の間に獲得された利得の大部分は二国間条約を簡素化するのから来るでしょう。 目標を完成するつもりであり、2番目の目的が位相を合わせる3番目のフェーズ。

7.  Acknowledgments

7. 承認

   This document was largely stimulated by the discussion that took
   place during the Merit/NSFNET Regional Tech Meeting in Boulder,
   January 21-22, 1993.  We would like specifically acknowledge
   contributions by Peter Ford (Los Alamos National Laboratory), Elise
   Gerich (NSFNET/Merit), Susan Hares (NSFNET/Merit), Mark Knopper
   (NSFNET/Merit), Bill Manning (Sesquinet/Rice University), and John
   Scudder (NSFNET/Merit).

このドキュメントはMerit/NSFNET Regional Tech Meetingの間にボウルダー(1993年1月21日〜22日)で行われた議論で主に刺激されました。 私たちは好きでしょう。明確にピーター・フォード(ロスアラモス国立研究所)、エリーズGerich(NSFNET/長所)、スーザンHares(NSFNET/長所)、マークKnopper(NSFNET/長所)、ビル・マニング(Sesquinet/ライス大学)、およびジョンScudder(NSFNET/長所)による貢献を承諾してください。

Rekhter & Topolcic                                              [Page 7]

RFC 1520           CIDR Provider Information Exchange     September 1993

Rekhter&Topolcic[7ページ]RFC1520CIDRプロバイダー情報交換1993年9月

8.  References

8. 参照

   [1] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
       Domain Routing (CIDR): An Address Assignment and Aggregation
       Strategy", RFC 1519, BARRNet, cisco, Merit, and OARnet, September
       1993.

[1] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「Address AssignmentとAggregation Strategy」、RFC1519、BARRNet、コクチマス、Merit、およびOARnet、9月1993

   [2] Gerich, E., "Guidelines for Management of IP Address Space", RFC
       1466, Merit, May 1993.

[2]Gerich、「IP管理アドレス空間のためのガイドライン」(RFC1466)が1993年5月に値するE.。

   [3] Rekhter, Y., and T. Li, "An Architecture for IP Address
       Allocation with CIDR", RFC 1518, T.J. Watson Research Center, IBM
       Corp., cisco Systems, September 1993.

[3]Rekhter、Y.、およびT.李、「CIDRとのIPアドレス配分のための構造」、RFC1518、T.J.ワトソン研究所、IBM社、コクチマスSystems(1993年9月)。

   [4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
       Work in Progress, June 1993.

[4] Y.、およびT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」というRekhterは進歩、1993年6月に働いています。

   [5] Rekhter, Y., and P. Gross, "Application of the Border Gateway
       Protocol in the Internet", Work in Progress, September 1992.

[5] Y.、およびP.グロス、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」というRekhterは進歩、1992年9月に働いています。

   [6] Hares, S., "IDRP for IP", Work in Progress, March 1993.

[6] S.、「IPのためのIDRP」という野兎は進歩、1993年3月に働いています。

   [7] Varadhan, K., "BGP4 OSPF Interaction", Work in Progress, March
       1993.

[7] K.、「BGP4 OSPF相互作用」というVaradhanは進歩、1993年3月に働いています。

   [8] Topolcic, C., "Notes on BGP-4/CIDR Coordination Meeting of 11
       March 93", Informal Notes, March 1993.

Topolcic(C.)が「1993年3月11日のBGP-4/CIDR調整会議では注意する」[8]、非公式の注意、1993年3月。

   [9] Knopper, M., "Aggregation Support in the NSFNET Policy Routing
       Database", RFC 1482, Merit, June 1993.

[9]Knopper、「NSFNET方針ルート設定データベースにおける集合サポート」、RFC1482が1993年6月に値するM.。

9.  Security Considerations

9. セキュリティ問題

       Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Rekhter & Topolcic                                              [Page 8]

RFC 1520           CIDR Provider Information Exchange     September 1993

Rekhter&Topolcic[8ページ]RFC1520CIDRプロバイダー情報交換1993年9月

10.  Authors' Addresses

10. 作者のアドレス

       Yakov Rekhter
       T.J. Watson Research Center, IBM Corporation
       P.O. Box 218
       Yorktown Heights, NY 10598

ニューヨーク ヤコフRekhter T.J.ワトソン研究所、IBM社の私書箱218ヨークタウンの高さ、10598

       Phone: (914) 945-3896
       EMail: yakov@watson.ibm.com

以下に電話をしてください。 (914) 945-3896 メールしてください: yakov@watson.ibm.com

       Claudio Topolcic
       Corporation for National Research Initiatives
       1895 Preston White Drive, Suite 100
       Suite 100
       Reston, VA 22091

レストン、スイート100Suite100ヴァージニア 国家の研究イニシアチブ1895のプレストンの白いドライブ、22091へのクラウディオTopolcic社

       Phone: (703) 620-8990
       EMail: topolcic@CNRI.Reston.VA.US

以下に電話をしてください。 (703) 620-8990 メールしてください: topolcic@CNRI.Reston.VA.US

Rekhter & Topolcic                                              [Page 9]

Rekhter&Topolcic[9ページ]