RFC1518 日本語訳
1518 An Architecture for IP Address Allocation with CIDR. Y. Rekhter,T. Li. September 1993. (Format: TXT=72609 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Y. Rekhter
Request for Comments: 1518 T.J. Watson Research Center, IBM Corp.
Category: Standards Track T. Li
cisco Systems
Editors
September 1993
Rekhterがコメントのために要求するワーキンググループY.をネットワークでつないでください: 1518 T.J.ワトソン研究所、IBM社のカテゴリ: 規格、Track T.李コクチマスSystemsエディターズ1993年9月
An Architecture for IP Address Allocation with CIDR
CIDRとのIPアドレス配分のための構造
Status of this Memo
このMemoの状態
This RFC specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはインターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
1. Introduction
1. 序論
This paper provides an architecture and a plan for allocating IP addresses in the Internet. This architecture and the plan are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy outlined in [1].
この紙はインターネットにIPアドレスを割り当てるための構造とプランを提供します。 この構造とプランがインターネットを[1]に概説されたAddress AssignmentとAggregating Strategyに導く際に重要な役割を果たすことを意図します。
The IP address space is a scarce shared resource that must be managed for the good of the community. The managers of this resource are acting as its custodians. They have a responsibility to the community to manage it for the common good.
IPアドレス空間は共同体の利益のために管理しなければならない不十分な共用資源です。 このリソースのマネージャは管理人として務めています。 彼らは、公益のためにそれを管理するために共同体に責任を持っています。
2. Scope
2. 範囲
The global Internet can be modeled as a collection of hosts interconnected via transmission and switching facilities. Control over the collection of hosts and the transmission and switching facilities that compose the networking resources of the global Internet is not homogeneous, but is distributed among multiple administrative authorities. Resources under control of a single administration form a domain. For the rest of this paper, "domain" and "routing domain" will be used interchangeably. Domains that share their resources with other domains are called network service providers (or just providers). Domains that utilize other domain's resources are called network service subscribers (or just subscribers). A given domain may act as a provider and a subscriber simultaneously.
トランスミッションと施設を切り換えることを通してホストの収集がインタコネクトしたように世界的なインターネットをモデル化できます。 世界的なインターネットに関するネットワークリソースを構成するホストの収集、トランスミッション、および切り換え施設のコントロールは、均質ではありませんが、複数の職務権限の中に広げられます。 ただ一つの管理で制御されたリソースはドメインを形成します。 この紙の残りのために、「ドメイン」と「経路ドメイン」は互換性を持って使用されるでしょう。 他のドメインとそれらのリソースを共有するドメインはネットワークサービスプロバイダー(または、まさしくプロバイダー)と呼ばれます。 他のドメインのリソースを利用するドメインはネットワーク・サービス加入者(または、まさしく加入者)と呼ばれます。 与えられたドメインは同時に、プロバイダーと加入者として機能するかもしれません。
Rekhter & Li [Page 1] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[1ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
There are two aspects of interest when discussing IP address allocation within the Internet. The first is the set of administrative requirements for obtaining and allocating IP addresses; the second is the technical aspect of such assignments, having largely to do with routing, both within a routing domain (intra-domain routing) and between routing domains (inter-domain routing). This paper focuses on the technical issues.
インターネットの中でIPアドレス配分について議論するとき、興味がある2つの局面があります。 1番目はIPアドレスを得て、割り当てるための管理要件のセットです。 2番目はそのような課題の技術的側面です、ルーティングと主に関係があるので、経路ドメイン(イントラドメインルーティング)と経路ドメイン(相互ドメインルーティング)の間の両方。 この紙は専門的な問題に焦点を合わせます。
In the current Internet many routing domains (such as corporate and campus networks) attach to transit networks (such as regionals) in only one or a small number of carefully controlled access points. The former act as subscribers, while the latter act as providers.
現在のインターネットでは、多くの経路ドメイン(法人とキャンパスネットワークなどの)が1だけの輸送網(地方版などの)か慎重に制御されたアクセスポイントの少ない数に付きます。 前者は加入者として機能しますが、後者はプロバイダーとして機能します。
The architecture and recommendations provided in this paper are intended for immediate deployment. This paper specifically does not address long-term research issues, such as complex policy-based routing requirements.
この紙に提供された構造と推薦は即座の展開のために意図します。 この論文は明確に複雑な方針ベースのルーティング要件などの長期の研究課題を記述しません。
Addressing solutions which require substantial changes or constraints on the current topology are not considered.
現在のトポロジーで大きな変化か規制を必要とするアドレシング解決が考えられません。
The architecture and recommendations in this paper are oriented primarily toward the large-scale division of IP address allocation in the Internet. Topics covered include:
この紙における構造と推薦はインターネットで主としてIPアドレス配分の大規模な分割に向かって向けられます。 カバーされた話題は:
- Benefits of encoding some topological information in IP
addresses to significantly reduce routing protocol overhead;
- ルーティングをかなり減少させるためにIPアドレスの何らかの位相的な情報をコード化する利益はオーバーヘッドについて議定書の中で述べます。
- The anticipated need for additional levels of hierarchy in
Internet addressing to support network growth;
- インターネットアドレシングによる追加レベルの階層構造がネットワークの成長を支持する予期された必要性。
- The recommended mapping between Internet topological entities
(i.e., service providers, and service subscribers) and IP
addressing and routing components;
- インターネットの位相的な実体(すなわち、サービスプロバイダー、およびサービス加入者)と、IPアドレシングとルーティングコンポーネントの間のお勧めのマッピング。
- The recommended division of IP address assignment among service
providers (e.g., backbones, regionals), and service subscribers
(e.g., sites);
- IPのお勧めの師団はサービスプロバイダー(例えば、背骨、地方版)、およびサービス加入者(例えば、サイト)の中に課題を記述します。
- Allocation of the IP addresses by the Internet Registry;
- IPの配分はインターネットのそばにRegistryを記述します。
- Choice of the high-order portion of the IP addresses in leaf
routing domains that are connected to more than one service
provider (e.g., backbone or a regional network).
- IPの高位一部の選択は葉に1つ以上のサービスプロバイダー(例えば、背骨か地域ネットワーク)につなげられる経路ドメインを記述します。
It is noted that there are other aspects of IP address allocation, both technical and administrative, that are not covered in this paper. Topics not covered or mentioned only superficially include:
この紙でカバーされていない技術的で管理の両方のIPアドレス配分の他の局面があることに注意されます。 表面的にカバーされなかったか、または言及されなかった話題は:だけ
Rekhter & Li [Page 2] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[2ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
- Identification of specific administrative domains in the
Internet;
- インターネットでの特定の管理ドメインの識別。
- Policy or mechanisms for making registered information known to
third parties (such as the entity to which a specific IP address
or a portion of the IP address space has been allocated);
- 第三者(特定のIPアドレスかIPアドレス空間の部分が割り当てられた実体などの)に登録された情報を明らかにするための方針かメカニズム。
- How a routing domain (especially a site) should organize its
internal topology or allocate portions of its IP address space;
the relationship between topology and addresses is discussed,
but the method of deciding on a particular topology or internal
addressing plan is not; and,
- 経路ドメイン(特にサイト)は、内部のトポロジーを組織化するべきであるか、またはどうIPアドレス空間の部分を割り当てるべきであるか。 トポロジーとアドレスとの関係について議論しますが、特定のトポロジーか内部のアドレシングプランを決める方法は議論するというわけではありません。 そして
- Procedures for assigning host IP addresses.
- ホストIPにアドレスを配属するための手順。
3. Background
3. バックグラウンド
Some background information is provided in this section that is helpful in understanding the issues involved in IP address allocation. A brief discussion of IP routing is provided.
このIPアドレス配分にかかわる問題を理解する際に役立っているセクションに何らかの基礎的な情報を提供します。 IPルーティングの簡潔な議論を提供します。
IP partitions the routing problem into three parts:
IPはルーティング問題を3つの部品に仕切ります:
- routing exchanges between end systems and routers (ARP),
- ルーティングはエンドシステムとルータの間で(ARP)を交換します。
- routing exchanges between routers in the same routing domain
(interior routing), and,
- そして、同じ経路ドメイン(内部のルーティング)のルータの間の交換を発送します。
- routing among routing domains (exterior routing).
- 経路ドメイン(外のルーティング)の中で掘ります。
4. IP Addresses and Routing
4. IPアドレスとルート設定
For the purposes of this paper, an IP prefix is an IP address and some indication of the leftmost contiguous significant bits within this address. Throughout this paper IP address prefixes will be expressed as <IP-address IP-mask> tuples, such that a bitwise logical AND operation on the IP-address and IP-mask components of a tuple yields the sequence of leftmost contiguous significant bits that form the IP address prefix. For example a tuple with the value <193.1.0.0 255.255.0.0> denotes an IP address prefix with 16 leftmost contiguous significant bits.
この紙の目的のために、IP接頭語は、このアドレスの中の一番左隣接の重要なビットのIPアドレスといくつかのしるしです。 aはあらゆる点で、<IP-アドレスIP-マスク>がtuplesされるとき、IPアドレスが前に置くこの紙が急送されるでしょう、そのようなものによってIP-アドレスで論理的なAND演算をbitwiseします、そして、tupleのIP-マスクの部品はIPアドレス接頭語を形成する一番左隣接の重要なビットの系列をもたらします。 例えば、値<193.1.0.0 255.255.0の.0>とtupleは一番左隣接の重要な16ビットでIPアドレス接頭語を指示します。
When determining an administrative policy for IP address assignment, it is important to understand the technical consequences. The objective behind the use of hierarchical routing is to achieve some level of routing data abstraction, or summarization, to reduce the cpu, memory, and transmission bandwidth consumed in support of routing.
IPアドレス課題のための施政方針を決定するとき、技術的な結果を理解しているのは重要です。 階層型ルーティングの使用の後ろの目的は帯域幅がルーティングを支持して消費したcpu、メモリ、およびトランスミッションを減らすために何らかのレベルのルーティングデータ抽象化、または総括を達成することです。
Rekhter & Li [Page 3] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[3ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
While the notion of routing data abstraction may be applied to various types of routing information, this paper focuses on one particular type, namely reachability information. Reachability information describes the set of reachable destinations. Abstraction of reachability information dictates that IP addresses be assigned according to topological routing structures. However, administrative assignment falls along organizational or political boundaries. These may not be congruent to topological boundaries and therefore the requirements of the two may collide. It is necessary to find a balance between these two needs.
ルーティングデータ抽象化の概念は様々なタイプのルーティング情報に適用されるかもしれませんが、この紙はすなわち、1つの特定のタイプ、可到達性情報に焦点を合わせます。 可到達性情報は届いている目的地のセットについて説明します。 可到達性情報の抽象化は、位相的なルーティング構造に従ってIPアドレスが割り当てられると決めます。 しかしながら、管理課題は組織的であるか政治上の境界に沿って下がります。 これらは位相的な境界に一致していないかもしれません、そして、したがって、2つのものの要件は衝突するかもしれません。 これらの2の間のバランスに必要性を見つけるのが必要です。
Routing data abstraction occurs at the boundary between hierarchically arranged topological routing structures. An element lower in the hierarchy reports summary routing information to its parent(s).
データ抽象化が階層的に境界に起こるルート設定は位相的なルーティング構造をアレンジしました。 要素は階層構造レポート概要ルーティング情報で親に下げられます。
At routing domain boundaries, IP address information is exchanged (statically or dynamically) with other routing domains. If IP addresses within a routing domain are all drawn from non-contiguous IP address spaces (allowing no abstraction), then the boundary information consists of an enumerated list of all the IP addresses.
ルーティングドメイン境界では、他の経路ドメインでIPアドレス情報を交換します(静的かダイナミックに)。 非隣接のIPアドレス空間から経路ドメインの中のIPアドレスをすべて得るなら(抽象化を全く許さないで)、境界情報はすべてのIPアドレスの列挙されたリストから成ります。
Alternatively, should the routing domain draw IP addresses for all the hosts within the domain from a single IP address prefix, boundary routing information can be summarized into the single IP address prefix. This permits substantial data reduction and allows better scaling (as compared to the uncoordinated addressing discussed in the previous paragraph).
あるいはまた境界ルーティング情報を経路ドメインがすべてのホストのためにドメインの中でただ一つのIPアドレス接頭語からIPアドレスを作成するならただ一つのIPアドレス接頭語へまとめることができます。 これは、かなりのデータ整理を許可して、比例するほうがよいのを許容します(前のパラグラフで議論した非調整されたアドレシングと比べて)。
If routing domains are interconnected in a more-or-less random (i.e., non-hierarchical) scheme, it is quite likely that no further abstraction of routing data can occur. Since routing domains would have no defined hierarchical relationship, administrators would not be able to assign IP addresses within the domains out of some common prefix for the purpose of data abstraction. The result would be flat inter-domain routing; all routing domains would need explicit knowledge of all other routing domains that they route to. This can work well in small and medium sized internets. However, this does not scale to very large internets. For example, we expect growth in the future to an Internet which has tens or hundreds of thousands of routing domains in North America alone. This requires a greater degree of the reachability information abstraction beyond that which can be achieved at the "routing domain" level.
すなわち、経路ドメインがaで多少無作為の状態でインタコネクトされる、(非、階層的である、)、計画、ルーティングデータのさらなる抽象化は全くかなり起こりそうであることができません。 経路ドメインには、定義された上下関係が全くないでしょう、したがって、管理者がデータ抽象化の目的のためにドメインの中で何らかの一般的な接頭語からIPアドレスを割り当てることができないでしょう。 結果は平坦な相互ドメインルーティングでしょう。 ドメインがそれらが発送する他のすべての経路ドメインの形式知を必要とするすべてのルーティング。 これは小さくて中型の大きさで分けられたインターネットでうまくいくことができます。 しかしながら、これは非常に大きいインターネットに比例しません。 例えば、私たちは将来、10か北アメリカの何十万もの経路ドメインを単独にするインターネットに成長を予測します。 これは「経路ドメイン」レベルで達成できるそれを超えて可到達性情報抽象化の、より大きい度合いを必要とします。
In the Internet, however, it should be possible to significantly constrain the volume and the complexity of routing information by taking advantage of the existing hierarchical interconnectivity, as discussed in Section 5. Thus, there is the opportunity for a group of
しかしながら、インターネットでは、既存の階層的な相互接続性を利用することによってルーティング情報のボリュームと複雑さをかなり抑制するのは可能であるべきです、セクション5で議論するように。 したがって、グループの機会があります。
Rekhter & Li [Page 4] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[4ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
routing domains each to be assigned an address prefix from a shorter prefix assigned to another routing domain whose function is to interconnect the group of routing domains. Each member of the group of routing domains now has its (somewhat longer) prefix, from which it assigns its addresses.
アドレス接頭語が経路ドメインのグループとインタコネクトする機能がことである別の経路ドメインに割り当てられたより短い接頭語から割り当てられるためにそれぞれドメインを発送します。 経路ドメインのグループの各メンバーには、現在、(いくらか長い)の接頭語があります。(それはそれからアドレスを割り当てます)。
The most straightforward case of this occurs when there is a set of routing domains which are all attached to a single service provider domain (e.g., regional network), and which use that provider for all external (inter-domain) traffic. A small prefix may be given to the provider, which then gives slightly longer prefixes (based on the provider's prefix) to each of the routing domains that it interconnects. This allows the provider, when informing other routing domains of the addresses that it can reach, to abbreviate the reachability information for a large number of routing domains as a single prefix. This approach therefore can allow a great deal of hierarchical abbreviation of routing information, and thereby can greatly improve the scalability of inter-domain routing.
ただ一つのサービスプロバイダードメイン(例えば、地域ネットワーク)にすべて付けられていて、すべての外部(相互ドメイン)の交通にそのプロバイダーを使用する1セットの経路ドメインがあるとき、この最も簡単なケースは現れます。 小さい接頭語をプロバイダーに与えるかもしれません。(次に、それは、わずかに長い接頭語(プロバイダーの接頭語に基づいている)をそれがインタコネクトするそれぞれの経路ドメインに与えます)。 それにただ一つの接頭語を多くの経路ドメインのための可到達性情報を簡略化するために達することができることをアドレスの他の経路ドメインに知らせるとき、これはプロバイダーを許容します。 このアプローチは、したがって、多くのルーティング情報の階層的な略語を許容できて、その結果、相互ドメインルーティングのスケーラビリティを大いに改良できます。
Clearly, this approach is recursive and can be carried through several iterations. Routing domains at any "level" in the hierarchy may use their prefix as the basis for subsequent suballocations, assuming that the IP addresses remain within the overall length and structure constraints.
明確に、このアプローチは、再帰的であり、いくつかの繰り返しで運ぶことができます。 階層構造のどんな「レベル」でも経路ドメインはその後の細分割当ての基礎としてそれらの接頭語を使用するかもしれません、IPアドレスが全長と構造規制に残っていると仮定して。
At this point, we observe that the number of nodes at each lower level of a hierarchy tends to grow exponentially. Thus the greatest gains in the reachability information abstraction (for the benefit of all higher levels of the hierarchy) occur when the reachability information aggregation occurs near the leaves of the hierarchy; the gains drop significantly at each higher level. Therefore, the law of diminishing returns suggests that at some point data abstraction ceases to produce significant benefits. Determination of the point at which data abstraction ceases to be of benefit requires a careful consideration of the number of routing domains that are expected to occur at each level of the hierarchy (over a given period of time), compared to the number of routing domains and address prefixes that can conveniently and efficiently be handled via dynamic inter-domain routing protocols.
ここに、私たちは、階層構造の各下のレベルにおけるノードの数が、指数関数的に成長する傾向があるのを観測します。 したがって、可到達性情報集合が階層構造の葉の近くに起こると、可到達性情報抽象化(階層構造のすべての、より高いレベルの利益のための)における最大級の利得は起こります。 利得はそれぞれのより高いレベルで著しく低下します。 したがって、収穫逓減の法則は、何らかのポイントデータ抽象化におけるそれが、重要な利益を生産するのをやめるのを示します。 データ抽象化が有益であることをやめるポイントの決断は階層構造(与えられた期間の間の)の各レベルで起こると予想される経路ドメインの数の熟慮を必要とします、ダイナミックな相互ドメインルーティング・プロトコルで便利に効率的に扱うことができる経路ドメインとアドレス接頭語の数と比べて。
4.1 Efficiency versus Decentralized Control
4.1 効率対分散制御
If the Internet plans to support a decentralized address administration [4], then there is a balance that must be sought between the requirements on IP addresses for efficient routing and the need for decentralized address administration. A proposal described in [3] offers an example of how these two needs might be met.
インターネットが、分散アドレス管理[4]を支持するのを計画しているなら、効率的なルーティングのためのIPアドレスに関する要件と分散アドレス管理の必要性の間で求めなければならないバランスがあります。 提案は[3] 申し出でこれらの2つの需要がどう満たされるかもしれないかに関する例について説明しました。
Rekhter & Li [Page 5] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[5ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
The IP address prefix <198.0.0.0 254.0.0.0> provides for administrative decentralization. This prefix identifies part of the IP address space allocated for North America. The lower order part of that prefix allows allocation of IP addresses along topological boundaries in support of increased data abstraction. Clients within North America use parts of the IP address space that is underneath the IP address space of their service providers. Within a routing domain addresses for subnetworks and hosts are allocated from the unique IP prefix assigned to the domain.
IPアドレス接頭語<198.0.0.0 254.0.0.0>は行政の地方分権に備えます。 この接頭語は北アメリカに割り当てられたIPアドレス空間の一部を特定します。 その接頭語の下層階級部分は位相的な境界に沿って増加するデータ抽象化を支持してIPアドレスの配分を許します。 北アメリカの中のクライアントはそれらのサービスプロバイダーのIPアドレス空間の下にあるIPアドレス空間の部品を使用します。 経路ドメインの中では、そのドメインに割り当てられたユニークなIP接頭語からサブネットワークとホストのためのアドレスを割り当てます。
5. IP Address Administration and Routing in the Internet
5. インターネットのIPアドレス管理とルート設定
The basic Internet routing components are service providers (e.g., backbones, regional networks), and service subscribers (e.g., sites or campuses). These components are arranged hierarchically for the most part. A natural mapping from these components to IP routing components is that providers and subscribers act as routing domains.
基本的なインターネット・ルーティングコンポーネントは、サービスプロバイダー(例えば、背骨、地域ネットワーク)と、サービス加入者(例えば、サイトかキャンパス)です。 これらのコンポーネントは階層的にだいたい配置されます。 自然なこれらのコンポーネントからIPルーティングコンポーネントまでのマッピングはプロバイダーと加入者がドメインを発送するとして務めるということです。
Alternatively, a subscriber (e.g., a site) may choose to operate as a part of a domain formed by a service provider. We assume that some, if not most, sites will prefer to operate as part of their provider's routing domain. Such sites can exchange routing information with their provider via interior routing protocol route leaking or via an exterior routing protocol. For the purposes of this discussion, the choice is not significant. The site is still allocated a prefix from the provider's address space, and the provider will advertise its own prefix into inter-domain routing.
あるいはまた、加入者(例えば、サイト)は、ドメインの一部がサービスプロバイダーによって形成されたので作動するのを選ぶかもしれません。 私たちは、いくつか、または大部分、サイトが、それらのプロバイダーの経路ドメインの一部として作動するのを好むと思います。 そのようなサイトは内部のルーティング・プロトコルルート漏出を通して外のルーティング・プロトコルでそれらのプロバイダーとルーティング情報を交換できます。 この議論の目的のために、選択は重要ではありません。 接頭語をプロバイダーのアドレス空間からサイトにまだ割り当てています、そして、プロバイダーは相互ドメインルーティングにそれ自身の接頭語の広告を出すでしょう。
Given such a mapping, where should address administration and allocation be performed to satisfy both administrative decentralization and data abstraction? The following possibilities are considered:
そのようなマッピングを考えて、アドレス管理と配分は、行政の地方分権とデータ抽象化の両方を満たすためにどこで実行されるべきですか? 以下の可能性は考えられます:
- at some part within a routing domain,
- いくつかでは、経路ドメインの中で離れてください。
- at the leaf routing domain,
- 葉の経路ドメインで
- at the transit routing domain (TRD), and
- そしてトランジット経路ドメイン(TRD)で。
- at the continental boundaries.
- 大陸の境界で。
A point within a routing domain corresponds to a subnetwork. If a
domain is composed of multiple subnetworks, they are
interconnected via routers. Leaf routing domains correspond to
sites, where the primary purpose is to provide intra-domain
routing services. Transit routing domains are deployed to carry
transit (i.e., inter-domain) traffic; backbones and providers are
TRDs.
経路ドメインの中のポイントはサブネットワークに対応しています。 ドメインが複数のサブネットワークで構成されるなら、それらはルータでインタコネクトされます。 葉の経路ドメインはサイトに対応しています。そこでは、第一の目的はイントラドメインルーティングサービスを提供することです。 トランジット経路ドメインはトランジット(すなわち、相互ドメイン)交通を運ぶために配備されます。 背骨とプロバイダーはTRDsです。
Rekhter & Li [Page 6] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[6ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
The greatest burden in transmitting and operating on routing
information is at the top of the routing hierarchy, where routing
information tends to accumulate. In the Internet, for example,
providers must manage the set of network numbers for all networks
reachable through the provider. Traffic destined for other
providers is generally routed to the backbones (which act as
providers as well). The backbones, however, must be cognizant of
the network numbers for all attached providers and their
associated networks.
ルーティング情報が伝わって、作動するのにおいて最も大きい負担がルーティング階層構造の最上部にあります。(そこでは、ルーティング情報が蓄積する傾向があります)。 インターネットでは、例えば、プロバイダーはプロバイダーを通して届いているすべてのネットワークのネットワーク・ナンバーのセットを経営しなければなりません。 一般に、他のプロバイダーのために運命づけられた交通は背骨(また、プロバイダーとしてのどの行為)に発送されるか。 しかしながら、背骨はすべての付属プロバイダーとそれらの関連ネットワークのネットワーク・ナンバーを認識していなければなりません。
In general, the advantage of abstracting routing information at a
given level of the routing hierarchy is greater at the higher
levels of the hierarchy. There is relatively little direct benefit
to the administration that performs the abstraction, since it must
maintain routing information individually on each attached
topological routing structure.
一般に、階層構造の、より高いレベルではルーティング階層構造の与えられたレベルでルーティング情報を抜き取る利点は、より大きいです。 抽象化を実行する管理への比較的少ない直接利益があります、それぞれの付属位相的なルーティング構造の上で個別にルーティング情報を保守しなければならないので。
For example, suppose that a given site is trying to decide whether
to obtain an IP address prefix directly from the IP address space
allocated for North America, or from the IP address space
allocated to its service provider. If considering only their own
self-interest, the site itself and the attached provider have
little reason to choose one approach or the other. The site must
use one prefix or another; the source of the prefix has little
effect on routing efficiency within the site. The provider must
maintain information about each attached site in order to route,
regardless of any commonality in the prefixes of the sites.
例えば、与えられたサイトが、直接北アメリカに割り当てられたIPアドレス空間、または、サービスプロバイダーに割り当てられたIPアドレス空間からIPアドレス接頭語を得るかどうか決めようとしていると仮定してください。 それら自身の私利だけを考えるなら、サイト自体と付属プロバイダーには、1つのアプローチかもう片方を選ぶ理由がほとんどありません。 サイトは何らかの接頭語を使用しなければなりません。 接頭語の源はサイトの中でほとんどルーティング効率に影響を与えません。 プロバイダーは、いずれもにかかわらずサイトの接頭語の共通点を発送するためにそれぞれの添付のサイトの情報を保守しなければなりません。
However, there is a difference when the provider distributes
routing information to other providers (e.g., backbones or TRDs).
In the first case, the provider cannot aggregate the site's
address into its own prefix; the address must be explicitly listed
in routing exchanges, resulting in an additional burden to other
providers which must exchange and maintain this information.
しかしながら、プロバイダーが他のプロバイダー(例えば、背骨かTRDs)にルーティング情報を分配するとき、違いがあります。 前者の場合、プロバイダーはそれ自身の接頭語へのサイトのアドレスに集められることができません。 ルーティング交換で明らかにアドレスを記載しなければなりません、この情報を交換して、保守しなければならない他のプロバイダーへの追加負担をもたらして。
In the second case, each other provider (e.g., backbone or TRD)
sees a single address prefix for the provider, which encompasses
the new site. This avoids the exchange of additional routing
information to identify the new site's address prefix. Thus, the
advantages primarily accrue to other providers which maintain
routing information about this site and provider.
2番目の場合でプロバイダー(例えば、背骨かTRD)が、ただ一つのアドレスがプロバイダー(新しいサイトを包含するもの)のために前に置くのを見る互い これは、新しいサイトのアドレス接頭語を特定するために追加ルーティング情報の交換を避けます。 したがって、利点は主としてこのサイトとプロバイダーのルーティング情報を保守する他のプロバイダーに生じます。
One might apply a supplier/consumer model to this problem: the
higher level (e.g., a backbone) is a supplier of routing services,
while the lower level (e.g., a TRD) is the consumer of these
services. The price charged for services is based upon the cost of
providing them. The overhead of managing a large table of
addresses for routing to an attached topological entity
1つは供給者/消費者モデルをこの問題に適用するかもしれません: より高いレベル(例えば、背骨)はルーティングサービスの供給者です、下のレベル(例えば、TRD)はこれらのサービスの消費者ですが。 サービスに課される価格はそれらを提供する費用に基づいています。 ルーティングのためのアドレスの大きいテーブルを付属位相的な実体に管理するオーバーヘッド
Rekhter & Li [Page 7] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[7ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
contributes to this cost.
この費用に貢献します。
The Internet, however, is not a market economy. Rather, efficient
operation is based on cooperation. The recommendations discussed
below describe simple and tractable ways of managing the IP
address space that benefit the entire community.
しかしながら、インターネットは市場経済ではありません。 むしろ、効率的な操作は協力に基づいています。 以下で議論した推薦は全体の共同体のためになるIPアドレス空間を管理する簡単で御しやすい方法を述べます。
5.1 Administration of IP addresses within a domain
5.1 ドメインの中のIP運営アドレス
If individual subnetworks take their IP addresses from a myriad of
unrelated IP address spaces, there will be effectively no data
abstraction beyond what is built into existing intra-domain
routing protocols. For example, assume that within a routing
domain uses three independent prefixes assigned from three
different IP address spaces associated with three different
attached providers.
個々のサブネットワークが関係ないIPアドレス空間の無数からそれらのIPアドレスを取ると、データ抽象化は全く有効に既存のイントラドメインルーティング・プロトコルが組み込まれることを超えていないでしょう。 例えば、経路ドメインの中のそれが3つの異なった付属プロバイダーに関連している3つの異なったIPアドレス空間から割り当てられた3つの独立している接頭語を使用すると仮定してください。
This has a negative effect on inter-domain routing, particularly
on those other domains which need to maintain routes to this
domain. There is no common prefix that can be used to represent
these IP addresses and therefore no summarization can take place
at the routing domain boundary. When addresses are advertised by
this routing domain to other routing domains, an enumerated list
of the three individual prefixes must be used.
これは相互ドメインルーティングでマイナスの影響があります、特にこのドメインにルートを維持する必要があるそれらの他のドメインで。 これらのIPアドレスを表すのに使用できるどんな一般的な接頭語もありません、そして、したがって、総括は全くルーティングドメイン境界で行われることができません。 アドレスがこの経路ドメインによって他の経路ドメインに広告に掲載されるとき、3つの個々の接頭語の列挙されたリストを使用しなければなりません。
This situation is roughly analogous to the present dissemination
of routing information in the Internet, where each domain may have
non-contiguous network numbers assigned to it. The result of
allowing subnetworks within a routing domain to take their IP
addresses from unrelated IP address spaces is flat routing at the
A/B/C class network level. The number of IP prefixes that leaf
routing domains would advertise is on the order of the number of
attached network numbers; the number of prefixes a provider's
routing domain would advertise is approximately the number of
network numbers attached to the client leaf routing domains; and
for a backbone this would be summed across all attached providers.
This situation is just barely acceptable in the current Internet,
and as the Internet grows this will quickly become intractable. A
greater degree of hierarchical information reduction is necessary
to allow continued growth in the Internet.
この状況はインターネットでルーティング情報の現在の普及におよそ類似しています。各ドメインで、そこでは、非隣接のネットワーク・ナンバーをそれに割り当てるかもしれません。 経路ドメインの中のサブネットワークが関係ないIPアドレス空間からそれらのIPアドレスを取るのを許容するという結果はA/B/Cクラスネットワークレベルにおいて平坦なルーティングです。 付属ネットワーク・ナンバーの数の注文には葉の経路ドメインが広告を出すIP接頭語の数があります。 プロバイダーの経路ドメインが広告を出す接頭語の数はクライアント葉の経路ドメインに付けられたネットワーク・ナンバーのおよそ数です。 そして、背骨において、これはすべての付属プロバイダーの向こう側にまとめられるでしょう。 この状況は現在のインターネットでちょうどほとんど許容できません、そして、インターネットが発展するのに従って、これは急速に手に負えなくなるでしょう。 より大きい度の階層的な情報減少が、インターネットの継続成長を許容するのに必要です。
5.2 Administration at the Leaf Routing Domain
5.2 葉の経路ドメインの政権
As mentioned previously, the greatest degree of data abstraction
comes at the lowest levels of the hierarchy. Providing each leaf
routing domain (that is, site) with a prefix from its provider's
prefix results in the biggest single increase in abstraction. From
outside the leaf routing domain, the set of all addresses
既述のとおり、最大級の度のデータ抽象化は階層構造の最も低いレベルで来ます。 それぞれの葉の経路ドメイン(すなわち、サイト)をプロバイダーの接頭語から接頭語に提供すると、抽象化の最も大きいただ一つの増加はもたらされます。 葉の外から経路ドメイン、すべてのアドレスのセット
Rekhter & Li [Page 8] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[8ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
reachable in the domain can then be represented by a single
prefix. Further, all destinations reachable within the provider's
prefix can be represented by a single prefix.
届く、そして、そのドメインでは、ただ一つの接頭語は表すことができます。 さらに、ただ一つの接頭語はプロバイダーの接頭語の中で届いているすべての目的地を表すことができます。
For example, consider a single campus which is a leaf routing
domain which would currently require 4 different IP networks.
Under the new allocation scheme, they might instead be given a
single prefix which provides the same number of destination
addresses. Further, since the prefix is a subset of the
provider's prefix, they impose no additional burden on the higher
levels of the routing hierarchy.
例えば、現在4つの異なったIPネットワークを必要とする葉の経路ドメインである単一のキャンパスを考えてください。 新しい配分体系の下では、代わりに同じ数の送付先アドレスを提供するただ一つの接頭語をそれらに与えるかもしれません。 さらに、彼らは、接頭語がプロバイダーの接頭語の部分集合であるので、ルーティング階層構造の、より高いレベルにどんな追加負担も課しません。
There is a close relationship between subnetworks and routing
domains implicit in the fact that they operate a common routing
protocol and are under the control of a single administration. The
routing domain administration subdivides the domain into
subnetworks. The routing domain represents the only path between
a subnetwork and the rest of the internetwork. It is reasonable
that this relationship also extend to include a common IP
addressing space. Thus, the subnetworks within the leaf routing
domain should take their IP addresses from the prefix assigned to
the leaf routing domain.
それらは一般的なルーティング・プロトコルを操作して、ただ一つの管理のコントロールの下にあるという事実に内在しているサブネットワークと経路ドメインの間には、密接な関係があります。 経路ドメイン管理はサブネットワークにドメインを分筆します。 経路ドメインはサブネットワークとインターネットワークの残りの間の唯一の経路を表します。 また、この関係がスペースを記述する一般的なIPを含むように広がるのは、妥当です。 したがって、葉の経路ドメインの中のサブネットワークは葉の経路ドメインに割り当てられた接頭語からそれらのIPアドレスを取るはずです。
5.3 Administration at the Transit Routing Domain
5.3 トランジット経路ドメインの政権
Two kinds of transit routing domains are considered, direct
providers and indirect providers. Most of the subscribers of a
direct provider are domains that act solely as service subscribers
(they carry no transit traffic). Most of the subscribers of an
indirect provider are domains that, themselves, act as service
providers. In present terminology a backbone is an indirect
provider, while a TRD is a direct provider. Each case is discussed
separately below.
2種類のトランジット経路ドメインは、考えられて、ダイレクトなプロバイダーと間接的なプロバイダーです。 ダイレクトプロバイダーの加入者の大部分は唯一サービス加入者として機能するドメイン(彼らはトランジット交通を全く運ばない)です。 間接的なプロバイダーの加入者の大部分はそれ(自分たち)がサービスプロバイダーとして務めるドメインです。 現在の用語では、背骨は間接的なプロバイダーですが、TRDはダイレクトプロバイダーです。 別々に以下で各ケースについて議論します。
5.3.1 Direct Service Providers
5.3.1 直航プロバイダー
It is interesting to consider whether direct service providers'
routing domains should use their IP address space for assigning IP
addresses from a unique prefix to the leaf routing domains that
they serve. The benefits derived from data abstraction are greater
than in the case of leaf routing domains, and the additional
degree of data abstraction provided by this may be necessary in
the short term.
直航プロバイダーの経路ドメインがユニークな接頭語からそれらが役立つ葉の経路ドメインまでIPアドレスを割り当てるのにそれらのIPアドレス空間を使用するべきであるかどうか考えるのはおもしろいです。 データ抽象化から得られた利益は葉の経路ドメインに関するケースよりすばらしいです、そして、これによって提供された追加度のデータ抽象化が短期で必要であるかもしれません。
As an illustration consider an example of a direct provider that
serves 100 clients. If each client takes its addresses from 4
independent address spaces then the total number of entries that
are needed to handle routing to these clients is 400 (100 clients
イラストと、100人のクライアントに役立つダイレクトプロバイダーに関する例を考えてください。 各クライアントが4つの独立しているアドレス空間からアドレスを取るならこれらのクライアントにルーティングを扱うのに必要であるエントリーの総数が400である、(100人のクライアント
Rekhter & Li [Page 9] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[9ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
times 4 providers). If each client takes its addresses from a
single address space then the total number of entries would be
only 100. Finally, if all the clients take their addresses from
the same address space then the total number of entries would be
only 1.
回4のプロバイダー) 各クライアントがただ一つのアドレス空間からアドレスを取るなら、エントリーの総数は100にすぎないでしょう。 最終的に、すべてのクライアントが同じアドレス空間から彼らのアドレスを取る場合にだけ、エントリーの総数は1でしょう。
We expect that in the near term the number of routing domains in
the Internet will grow to the point that it will be infeasible to
route on the basis of a flat field of routing domains. It will
therefore be essential to provide a greater degree of information
abstraction.
We expect that in the near term the number of routing domains in the Internet will grow to the point that it will be infeasible to route on the basis of a flat field of routing domains. It will therefore be essential to provide a greater degree of information abstraction.
Direct providers may give part of their address space (prefixes)
to leaf domains, based on an address prefix given to the provider.
This results in direct providers advertising to backbones a small
fraction of the number of address prefixes that would be necessary
if they enumerated the individual prefixes of the leaf routing
domains. This represents a significant savings given the expected
scale of global internetworking.
Direct providers may give part of their address space (prefixes) to leaf domains, based on an address prefix given to the provider. This results in direct providers advertising to backbones a small fraction of the number of address prefixes that would be necessary if they enumerated the individual prefixes of the leaf routing domains. This represents a significant savings given the expected scale of global internetworking.
Are leaf routing domains willing to accept prefixes derived from
the direct providers? In the supplier/consumer model, the direct
provider is offering connectivity as the service, priced according
to its costs of operation. This includes the "price" of obtaining
service from one or more indirect providers (e.g., backbones). In
general, indirect providers will want to handle as few address
prefixes as possible to keep costs low. In the Internet
environment, which does not operate as a typical marketplace, leaf
routing domains must be sensitive to the resource constraints of
the providers (both direct and indirect). The efficiencies gained
in inter-domain routing clearly warrant the adoption of IP address
prefixes derived from the IP address space of the providers.
Are leaf routing domains willing to accept prefixes derived from the direct providers? In the supplier/consumer model, the direct provider is offering connectivity as the service, priced according to its costs of operation. This includes the "price" of obtaining service from one or more indirect providers (e.g., backbones). In general, indirect providers will want to handle as few address prefixes as possible to keep costs low. In the Internet environment, which does not operate as a typical marketplace, leaf routing domains must be sensitive to the resource constraints of the providers (both direct and indirect). The efficiencies gained in inter-domain routing clearly warrant the adoption of IP address prefixes derived from the IP address space of the providers.
The mechanics of this scenario are straightforward. Each direct
provider is given a unique small set of IP address prefixes, from
which its attached leaf routing domains can allocates slightly
longer IP address prefixes. For example assume that NIST is a
leaf routing domain whose inter-domain link is via SURANet. If
SURANet is assigned an unique IP address prefix <198.1.0.0
255.255.0.0>, NIST could use a unique IP prefix of <198.1.0.0
255.255.240.0>.
The mechanics of this scenario are straightforward. Each direct provider is given a unique small set of IP address prefixes, from which its attached leaf routing domains can allocates slightly longer IP address prefixes. For example assume that NIST is a leaf routing domain whose inter-domain link is via SURANet. If SURANet is assigned an unique IP address prefix <198.1.0.0 255.255.0.0>, NIST could use a unique IP prefix of <198.1.0.0 255.255.240.0>.
If a direct service provider is connected to another provider(s)
(either direct or indirect) via multiple attachment points, then
in certain cases it may be advantageous to the direct provider to
exert a certain degree of control over the coupling between the
attachment points and flow of the traffic destined to a particular
subscriber. Such control can be facilitated by first partitioning
If a direct service provider is connected to another provider(s) (either direct or indirect) via multiple attachment points, then in certain cases it may be advantageous to the direct provider to exert a certain degree of control over the coupling between the attachment points and flow of the traffic destined to a particular subscriber. Such control can be facilitated by first partitioning
Rekhter & Li [Page 10] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhter & Li [Page 10] RFC 1518 CIDR Address Allocation Architecture September 1993
all the subscribers into groups, such that traffic destined to all
the subscribers within a group should flow through a particular
attachment point. Once the partitioning is done, the address space
of the provider is subdivided along the group boundaries. A leaf
routing domain that is willing to accept prefixes derived from its
direct provider gets a prefix from the provider's address space
subdivision associated with the group the domain belongs to. Note
that the advertisement by the direct provider of the routing
information associated with each subdivision must be done with
care to ensure that such an advertisement would not result in a
global distribution of separate reachability information
associated with each subdivision, unless such distribution is
warranted for some other purposes (e.g., supporting certain
aspects of policy-based routing).
all the subscribers into groups, such that traffic destined to all the subscribers within a group should flow through a particular attachment point. Once the partitioning is done, the address space of the provider is subdivided along the group boundaries. A leaf routing domain that is willing to accept prefixes derived from its direct provider gets a prefix from the provider's address space subdivision associated with the group the domain belongs to. Note that the advertisement by the direct provider of the routing information associated with each subdivision must be done with care to ensure that such an advertisement would not result in a global distribution of separate reachability information associated with each subdivision, unless such distribution is warranted for some other purposes (e.g., supporting certain aspects of policy-based routing).
5.3.2 Indirect Providers (Backbones)
5.3.2 Indirect Providers (Backbones)
There does not appear to be a strong case for direct providers to
take their address spaces from the the IP space of an indirect
provider (e.g., backbone). The benefit in routing data abstraction
is relatively small. The number of direct providers today is in
the tens and an order of magnitude increase would not cause an
undue burden on the backbones. Also, it may be expected that as
time goes by there will be increased direct interconnection of the
direct providers, leaf routing domains directly attached to the
backbones, and international links directly attached to the
providers. Under these circumstances, the distinction between
direct and indirect providers may become blurred.
There does not appear to be a strong case for direct providers to take their address spaces from the the IP space of an indirect provider (e.g., backbone). The benefit in routing data abstraction is relatively small. The number of direct providers today is in the tens and an order of magnitude increase would not cause an undue burden on the backbones. Also, it may be expected that as time goes by there will be increased direct interconnection of the direct providers, leaf routing domains directly attached to the backbones, and international links directly attached to the providers. Under these circumstances, the distinction between direct and indirect providers may become blurred.
An additional factor that discourages allocation of IP addresses
from a backbone prefix is that the backbones and their attached
providers are perceived as being independent. Providers may take
their long- haul service from one or more backbones, or may switch
backbones should a more cost-effective service be provided
elsewhere. Having IP addresses derived from a backbone is
inconsistent with the nature of the relationship.
An additional factor that discourages allocation of IP addresses from a backbone prefix is that the backbones and their attached providers are perceived as being independent. Providers may take their long- haul service from one or more backbones, or may switch backbones should a more cost-effective service be provided elsewhere. Having IP addresses derived from a backbone is inconsistent with the nature of the relationship.
5.4 Multi-homed Routing Domains
5.4 Multi-homed Routing Domains
The discussions in Section 5.3 suggest methods for allocating IP
addresses based on direct or indirect provider connectivity. This
allows a great deal of information reduction to be achieved for
those routing domains which are attached to a single TRD. In
particular, such routing domains may select their IP addresses
from a space delegated to them by the direct provider. This allows
the provider, when announcing the addresses that it can reach to
other providers, to use a single address prefix to describe a
large number of IP addresses corresponding to multiple routing
The discussions in Section 5.3 suggest methods for allocating IP addresses based on direct or indirect provider connectivity. This allows a great deal of information reduction to be achieved for those routing domains which are attached to a single TRD. In particular, such routing domains may select their IP addresses from a space delegated to them by the direct provider. This allows the provider, when announcing the addresses that it can reach to other providers, to use a single address prefix to describe a large number of IP addresses corresponding to multiple routing
Rekhter & Li [Page 11] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhter & Li [Page 11] RFC 1518 CIDR Address Allocation Architecture September 1993
domains.
domains.
However, there are additional considerations for routing domains
which are attached to multiple providers. Such "multi-homed"
routing domains may, for example, consist of single-site campuses
and companies which are attached to multiple backbones, large
organizations which are attached to different providers at
different locations in the same country, or multi-national
organizations which are attached to backbones in a variety of
countries worldwide. There are a number of possible ways to deal
with these multi-homed routing domains.
However, there are additional considerations for routing domains which are attached to multiple providers. Such "multi-homed" routing domains may, for example, consist of single-site campuses and companies which are attached to multiple backbones, large organizations which are attached to different providers at different locations in the same country, or multi-national organizations which are attached to backbones in a variety of countries worldwide. There are a number of possible ways to deal with these multi-homed routing domains.
One possible solution is for each multi-homed organization to
obtain its IP address space independently from the providers to
which it is attached. This allows each multi-homed organization
to base its IP assignments on a single prefix, and to thereby
summarize the set of all IP addresses reachable within that
organization via a single prefix. The disadvantage of this
approach is that since the IP address for that organization has no
relationship to the addresses of any particular TRD, the TRDs to
which this organization is attached will need to advertise the
prefix for this organization to other providers. Other providers
(potentially worldwide) will need to maintain an explicit entry
for that organization in their routing tables.
One possible solution is for each multi-homed organization to obtain its IP address space independently from the providers to which it is attached. This allows each multi-homed organization to base its IP assignments on a single prefix, and to thereby summarize the set of all IP addresses reachable within that organization via a single prefix. The disadvantage of this approach is that since the IP address for that organization has no relationship to the addresses of any particular TRD, the TRDs to which this organization is attached will need to advertise the prefix for this organization to other providers. Other providers (potentially worldwide) will need to maintain an explicit entry for that organization in their routing tables.
For example, suppose that a very large North American company
"Mega Big International Incorporated" (MBII) has a fully
interconnected internal network and is assigned a single prefix as
part of the North American prefix. It is likely that outside of
North America, a single entry may be maintained in routing tables
for all North American destinations. However, within North
America, every provider will need to maintain a separate address
entry for MBII. If MBII is in fact an international corporation,
then it may be necessary for every provider worldwide to maintain
a separate entry for MBII (including backbones to which MBII is
not attached). Clearly this may be acceptable if there are a small
number of such multi-homed routing domains, but would place an
unacceptable load on routers within backbones if all organizations
were to choose such address assignments. This solution may not
scale to internets where there are many hundreds of thousands of
multi-homed organizations.
For example, suppose that a very large North American company "Mega Big International Incorporated" (MBII) has a fully interconnected internal network and is assigned a single prefix as part of the North American prefix. It is likely that outside of North America, a single entry may be maintained in routing tables for all North American destinations. However, within North America, every provider will need to maintain a separate address entry for MBII. If MBII is in fact an international corporation, then it may be necessary for every provider worldwide to maintain a separate entry for MBII (including backbones to which MBII is not attached). Clearly this may be acceptable if there are a small number of such multi-homed routing domains, but would place an unacceptable load on routers within backbones if all organizations were to choose such address assignments. This solution may not scale to internets where there are many hundreds of thousands of multi-homed organizations.
A second possible approach would be for multi-homed organizations
to be assigned a separate IP address space for each connection to
a TRD, and to assign a single prefix to some subset of its
domain(s) based on the closest interconnection point. For example,
if MBII had connections to two providers in the U.S. (one east
coast, and one west coast), as well as three connections to
A second possible approach would be for multi-homed organizations to be assigned a separate IP address space for each connection to a TRD, and to assign a single prefix to some subset of its domain(s) based on the closest interconnection point. For example, if MBII had connections to two providers in the U.S. (one east coast, and one west coast), as well as three connections to
Rekhter & Li [Page 12] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhter & Li [Page 12] RFC 1518 CIDR Address Allocation Architecture September 1993
national backbones in Europe, and one in the far east, then MBII
may make use of six different address prefixes. Each part of MBII
would be assigned a single address prefix based on the nearest
connection.
national backbones in Europe, and one in the far east, then MBII may make use of six different address prefixes. Each part of MBII would be assigned a single address prefix based on the nearest connection.
For purposes of external routing of traffic from outside MBII to a
destination inside of MBII, this approach works similarly to
treating MBII as six separate organizations. For purposes of
internal routing, or for routing traffic from inside of MBII to a
destination outside of MBII, this approach works the same as the
first solution.
For purposes of external routing of traffic from outside MBII to a destination inside of MBII, this approach works similarly to treating MBII as six separate organizations. For purposes of internal routing, or for routing traffic from inside of MBII to a destination outside of MBII, this approach works the same as the first solution.
If we assume that incoming traffic (coming from outside of MBII,
with a destination within MBII) is always to enter via the nearest
point to the destination, then each TRD which has a connection to
MBII needs to announce to other TRDs the ability to reach only
those parts of MBII whose address is taken from its own address
space. This implies that no additional routing information needs
to be exchanged between TRDs, resulting in a smaller load on the
inter-domain routing tables maintained by TRDs when compared to
the first solution. This solution therefore scales better to
extremely large internets containing very large numbers of multi-
homed organizations.
If we assume that incoming traffic (coming from outside of MBII, with a destination within MBII) is always to enter via the nearest point to the destination, then each TRD which has a connection to MBII needs to announce to other TRDs the ability to reach only those parts of MBII whose address is taken from its own address space. This implies that no additional routing information needs to be exchanged between TRDs, resulting in a smaller load on the inter-domain routing tables maintained by TRDs when compared to the first solution. This solution therefore scales better to extremely large internets containing very large numbers of multi- homed organizations.
One problem with the second solution is that backup routes to
multi-homed organizations are not automatically maintained. With
the first solution, each TRD, in announcing the ability to reach
MBII, specifies that it is able to reach all of the hosts within
MBII. With the second solution, each TRD announces that it can
reach all of the hosts based on its own address prefix, which only
includes some of the hosts within MBII. If the connection between
MBII and one particular TRD were severed, then the hosts within
MBII with addresses based on that TRD would become unreachable via
inter-domain routing. The impact of this problem can be reduced
somewhat by maintenance of additional information within routing
tables, but this reduces the scaling advantage of the second
approach.
One problem with the second solution is that backup routes to multi-homed organizations are not automatically maintained. With the first solution, each TRD, in announcing the ability to reach MBII, specifies that it is able to reach all of the hosts within MBII. With the second solution, each TRD announces that it can reach all of the hosts based on its own address prefix, which only includes some of the hosts within MBII. If the connection between MBII and one particular TRD were severed, then the hosts within MBII with addresses based on that TRD would become unreachable via inter-domain routing. The impact of this problem can be reduced somewhat by maintenance of additional information within routing tables, but this reduces the scaling advantage of the second approach.
The second solution also requires that when external connectivity
changes, internal addresses also change.
The second solution also requires that when external connectivity changes, internal addresses also change.
Also note that this and the previous approach will tend to cause
packets to take different routes. With the first approach, packets
from outside of MBII destined for within MBII will tend to enter
via the point which is closest to the source (which will therefore
tend to maximize the load on the networks internal to MBII). With
the second solution, packets from outside destined for within MBII
will tend to enter via the point which is closest to the
Also note that this and the previous approach will tend to cause packets to take different routes. With the first approach, packets from outside of MBII destined for within MBII will tend to enter via the point which is closest to the source (which will therefore tend to maximize the load on the networks internal to MBII). With the second solution, packets from outside destined for within MBII will tend to enter via the point which is closest to the
Rekhter & Li [Page 13] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhter & Li [Page 13] RFC 1518 CIDR Address Allocation Architecture September 1993
destination (which will tend to minimize the load on the networks
within MBII, and maximize the load on the TRDs).
destination (which will tend to minimize the load on the networks within MBII, and maximize the load on the TRDs).
These solutions also have different effects on policies. For
example, suppose that country "X" has a law that traffic from a
source within country X to a destination within country X must at
all times stay entirely within the country. With the first
solution, it is not possible to determine from the destination
address whether or not the destination is within the country. With
the second solution, a separate address may be assigned to those
hosts which are within country X, thereby allowing routing
policies to be followed. Similarly, suppose that "Little Small
Company" (LSC) has a policy that its packets may never be sent to
a destination that is within MBII. With either solution, the
routers within LSC may be configured to discard any traffic that
has a destination within MBII's address space. However, with the
first solution this requires one entry; with the second it
requires many entries and may be impossible as a practical matter.
These solutions also have different effects on policies. For example, suppose that country "X" has a law that traffic from a source within country X to a destination within country X must at all times stay entirely within the country. With the first solution, it is not possible to determine from the destination address whether or not the destination is within the country. With the second solution, a separate address may be assigned to those hosts which are within country X, thereby allowing routing policies to be followed. Similarly, suppose that "Little Small Company" (LSC) has a policy that its packets may never be sent to a destination that is within MBII. With either solution, the routers within LSC may be configured to discard any traffic that has a destination within MBII's address space. However, with the first solution this requires one entry; with the second it requires many entries and may be impossible as a practical matter.
There are other possible solutions as well. A third approach is to
assign each multi-homed organization a single address prefix,
based on one of its connections to a TRD. Other TRDs to which the
multi-homed organization are attached maintain a routing table
entry for the organization, but are extremely selective in terms
of which other TRDs are told of this route. This approach will
produce a single "default" routing entry which all TRDs will know
how to reach (since presumably all TRDs will maintain routes to
each other), while providing more direct routing in some cases.
There are other possible solutions as well. A third approach is to assign each multi-homed organization a single address prefix, based on one of its connections to a TRD. Other TRDs to which the multi-homed organization are attached maintain a routing table entry for the organization, but are extremely selective in terms of which other TRDs are told of this route. This approach will produce a single "default" routing entry which all TRDs will know how to reach (since presumably all TRDs will maintain routes to each other), while providing more direct routing in some cases.
There is at least one situation in which this third approach is
particularly appropriate. Suppose that a special interest group of
organizations have deployed their own backbone. For example, lets
suppose that the U.S. National Widget Manufacturers and
Researchers have set up a U.S.-wide backbone, which is used by
corporations who manufacture widgets, and certain universities
which are known for their widget research efforts. We can expect
that the various organizations which are in the widget group will
run their internal networks as separate routing domains, and most
of them will also be attached to other TRDs (since most of the
organizations involved in widget manufacture and research will
also be involved in other activities). We can therefore expect
that many or most of the organizations in the widget group are
dual-homed, with one attachment for widget-associated
communications and the other attachment for other types of
communications. Let's also assume that the total number of
organizations involved in the widget group is small enough that it
is reasonable to maintain a routing table containing one entry per
organization, but that they are distributed throughout a larger
There is at least one situation in which this third approach is particularly appropriate. Suppose that a special interest group of organizations have deployed their own backbone. For example, lets suppose that the U.S. National Widget Manufacturers and Researchers have set up a U.S.-wide backbone, which is used by corporations who manufacture widgets, and certain universities which are known for their widget research efforts. We can expect that the various organizations which are in the widget group will run their internal networks as separate routing domains, and most of them will also be attached to other TRDs (since most of the organizations involved in widget manufacture and research will also be involved in other activities). We can therefore expect that many or most of the organizations in the widget group are dual-homed, with one attachment for widget-associated communications and the other attachment for other types of communications. Let's also assume that the total number of organizations involved in the widget group is small enough that it is reasonable to maintain a routing table containing one entry per organization, but that they are distributed throughout a larger
Rekhter & Li [Page 14] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhter & Li [Page 14] RFC 1518 CIDR Address Allocation Architecture September 1993
internet with many millions of (mostly not widget-associated)
routing domains.
internet with many millions of (mostly not widget-associated) routing domains.
With the third approach, each multi-homed organization in the
widget group would make use of an address assignment based on its
other attachment(s) to TRDs (the attachments not associated with
the widget group). The widget backbone would need to maintain
routes to the routing domains associated with the various member
organizations. Similarly, all members of the widget group would
need to maintain a table of routes to the other members via the
widget backbone. However, since the widget backbone does not
inform other general worldwide TRDs of what addresses it can reach
(since the backbone is not intended for use by other outside
organizations), the relatively large set of routing prefixes needs
to be maintained only in a limited number of places. The addresses
assigned to the various organizations which are members of the
widget group would provide a "default route" via each members
other attachments to TRDs, while allowing communications within
the widget group to use the preferred path.
With the third approach, each multi-homed organization in the widget group would make use of an address assignment based on its other attachment(s) to TRDs (the attachments not associated with the widget group). The widget backbone would need to maintain routes to the routing domains associated with the various member organizations. Similarly, all members of the widget group would need to maintain a table of routes to the other members via the widget backbone. However, since the widget backbone does not inform other general worldwide TRDs of what addresses it can reach (since the backbone is not intended for use by other outside organizations), the relatively large set of routing prefixes needs to be maintained only in a limited number of places. The addresses assigned to the various organizations which are members of the widget group would provide a "default route" via each members other attachments to TRDs, while allowing communications within the widget group to use the preferred path.
A fourth solution involves assignment of a particular address
prefix for routing domains which are attached to precisely two (or
more) specific routing domains. For example, suppose that there
are two providers "SouthNorthNet" and "NorthSouthNet" which have a
very large number of customers in common (i.e., there are a large
number of routing domains which are attached to both). Rather than
getting two address prefixes these organizations could obtain
three prefixes. Those routing domains which are attached to
NorthSouthNet but not attached to SouthNorthNet obtain an address
assignment based on one of the prefixes. Those routing domains
which are attached to SouthNorthNet but not to NorthSouthNet would
obtain an address based on the second prefix. Finally, those
routing domains which are multi-homed to both of these networks
would obtain an address based on the third prefix. Each of these
two TRDs would then advertise two prefixes to other TRDs, one
prefix for leaf routing domains attached to it only, and one
prefix for leaf routing domains attached to both.
A fourth solution involves assignment of a particular address prefix for routing domains which are attached to precisely two (or more) specific routing domains. For example, suppose that there are two providers "SouthNorthNet" and "NorthSouthNet" which have a very large number of customers in common (i.e., there are a large number of routing domains which are attached to both). Rather than getting two address prefixes these organizations could obtain three prefixes. Those routing domains which are attached to NorthSouthNet but not attached to SouthNorthNet obtain an address assignment based on one of the prefixes. Those routing domains which are attached to SouthNorthNet but not to NorthSouthNet would obtain an address based on the second prefix. Finally, those routing domains which are multi-homed to both of these networks would obtain an address based on the third prefix. Each of these two TRDs would then advertise two prefixes to other TRDs, one prefix for leaf routing domains attached to it only, and one prefix for leaf routing domains attached to both.
This fourth solution is likely to be important when use of public
data networks becomes more common. In particular, it is likely
that at some point in the future a substantial percentage of all
routing domains will be attached to public data networks. In this
case, nearly all government-sponsored networks (such as some
current regionals) may have a set of customers which overlaps
substantially with the public networks.
This fourth solution is likely to be important when use of public data networks becomes more common. In particular, it is likely that at some point in the future a substantial percentage of all routing domains will be attached to public data networks. In this case, nearly all government-sponsored networks (such as some current regionals) may have a set of customers which overlaps substantially with the public networks.
There are therefore a number of possible solutions to the problem
of assigning IP addresses to multi-homed routing domains. Each of
There are therefore a number of possible solutions to the problem of assigning IP addresses to multi-homed routing domains. Each of
Rekhter & Li [Page 15] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhter & Li [Page 15] RFC 1518 CIDR Address Allocation Architecture September 1993
these solutions has very different advantages and disadvantages.
Each solution places a different real (i.e., financial) cost on
the multi-homed organizations, and on the TRDs (including those to
which the multi-homed organizations are not attached).
these solutions has very different advantages and disadvantages. Each solution places a different real (i.e., financial) cost on the multi-homed organizations, and on the TRDs (including those to which the multi-homed organizations are not attached).
In addition, most of the solutions described also highlight the
need for each TRD to develop policy on whether and under what
conditions to accept addresses that are not based on its own
address prefix, and how such non-local addresses will be treated.
For example, a somewhat conservative policy might be that non-
local IP address prefixes will be accepted from any attached leaf
routing domain, but not advertised to other TRDs. In a less
conservative policy, a TRD might accept such non-local prefixes
and agree to exchange them with a defined set of other TRDs (this
set could be an a priori group of TRDs that have something in
common such as geographical location, or the result of an
agreement specific to the requesting leaf routing domain). Various
policies involve real costs to TRDs, which may be reflected in
those policies.
In addition, most of the solutions described also highlight the need for each TRD to develop policy on whether and under what conditions to accept addresses that are not based on its own address prefix, and how such non-local addresses will be treated. For example, a somewhat conservative policy might be that non- local IP address prefixes will be accepted from any attached leaf routing domain, but not advertised to other TRDs. In a less conservative policy, a TRD might accept such non-local prefixes and agree to exchange them with a defined set of other TRDs (this set could be an a priori group of TRDs that have something in common such as geographical location, or the result of an agreement specific to the requesting leaf routing domain). Various policies involve real costs to TRDs, which may be reflected in those policies.
5.5 Private Links
5.5 Private Links
The discussion up to this point concentrates on the relationship
between IP addresses and routing between various routing domains
over transit routing domains, where each transit routing domain
interconnects a large number of routing domains and offers a
more-or-less public service.
The discussion up to this point concentrates on the relationship between IP addresses and routing between various routing domains over transit routing domains, where each transit routing domain interconnects a large number of routing domains and offers a more-or-less public service.
However, there may also exist a number of links which interconnect
two routing domains in such a way, that usage of these links may
be limited to carrying traffic only between the two routing
domains. We'll refer to such links as "private".
However, there may also exist a number of links which interconnect two routing domains in such a way, that usage of these links may be limited to carrying traffic only between the two routing domains. We'll refer to such links as "private".
For example, let's suppose that the XYZ corporation does a lot of
business with MBII. In this case, XYZ and MBII may contract with a
carrier to provide a private link between the two corporations,
where this link may only be used for packets whose source is
within one of the two corporations, and whose destination is
within the other of the two corporations. Finally, suppose that
the point-to-point link is connected between a single router
(router X) within XYZ corporation and a single router (router M)
within MBII. It is therefore necessary to configure router X to
know which addresses can be reached over this link (specifically,
all addresses reachable in MBII). Similarly, it is necessary to
configure router M to know which addresses can be reached over
this link (specifically, all addresses reachable in XYZ
Corporation).
For example, let's suppose that the XYZ corporation does a lot of business with MBII. In this case, XYZ and MBII may contract with a carrier to provide a private link between the two corporations, where this link may only be used for packets whose source is within one of the two corporations, and whose destination is within the other of the two corporations. Finally, suppose that the point-to-point link is connected between a single router (router X) within XYZ corporation and a single router (router M) within MBII. It is therefore necessary to configure router X to know which addresses can be reached over this link (specifically, all addresses reachable in MBII). Similarly, it is necessary to configure router M to know which addresses can be reached over this link (specifically, all addresses reachable in XYZ Corporation).
Rekhter & Li [Page 16] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhter & Li [Page 16] RFC 1518 CIDR Address Allocation Architecture September 1993
The important observation to be made here is that the additional
connectivity due to such private links may be ignored for the
purpose of IP address allocation, and do not pose a problem for
routing. This is because the routing information associated with
such connectivity is not propagated throughout the Internet, and
therefore does not need to be collapsed into a TRD's prefix.
The important observation to be made here is that the additional connectivity due to such private links may be ignored for the purpose of IP address allocation, and do not pose a problem for routing. This is because the routing information associated with such connectivity is not propagated throughout the Internet, and therefore does not need to be collapsed into a TRD's prefix.
In our example, let's suppose that the XYZ corporation has a
single connection to a regional, and has therefore uses the IP
address space from the space given to that regional. Similarly,
let's suppose that MBII, as an international corporation with
connections to six different providers, has chosen the second
solution from Section 5.4, and therefore has obtained six
different address allocations. In this case, all addresses
reachable in the XYZ Corporation can be described by a single
address prefix (implying that router M only needs to be configured
with a single address prefix to represent the addresses reachable
over this link). All addresses reachable in MBII can be described
by six address prefixes (implying that router X needs to be
configured with six address prefixes to represent the addresses
reachable over the link).
In our example, let's suppose that the XYZ corporation has a single connection to a regional, and has therefore uses the IP address space from the space given to that regional. Similarly, let's suppose that MBII, as an international corporation with connections to six different providers, has chosen the second solution from Section 5.4, and therefore has obtained six different address allocations. In this case, all addresses reachable in the XYZ Corporation can be described by a single address prefix (implying that router M only needs to be configured with a single address prefix to represent the addresses reachable over this link). All addresses reachable in MBII can be described by six address prefixes (implying that router X needs to be configured with six address prefixes to represent the addresses reachable over the link).
In some cases, such private links may be permitted to forward
traffic for a small number of other routing domains, such as
closely affiliated organizations. This will increase the
configuration requirements slightly. However, provided that the
number of organizations using the link is relatively small, then
this still does not represent a significant problem.
In some cases, such private links may be permitted to forward traffic for a small number of other routing domains, such as closely affiliated organizations. This will increase the configuration requirements slightly. However, provided that the number of organizations using the link is relatively small, then this still does not represent a significant problem.
Note that the relationship between routing and IP addressing
described in other sections of this paper is concerned with
problems in scaling caused by large, essentially public transit
routing domains which interconnect a large number of routing
domains. However, for the purpose of IP address allocation,
private links which interconnect only a small number of private
routing domains do not pose a problem, and may be ignored. For
example, this implies that a single leaf routing domain which has
a single connection to a "public" backbone, plus a number of
private links to other leaf routing domains, can be treated as if
it were single-homed to the backbone for the purpose of IP address
allocation. We expect that this is also another way of dealing
with multi-homed domains.
Note that the relationship between routing and IP addressing described in other sections of this paper is concerned with problems in scaling caused by large, essentially public transit routing domains which interconnect a large number of routing domains. However, for the purpose of IP address allocation, private links which interconnect only a small number of private routing domains do not pose a problem, and may be ignored. For example, this implies that a single leaf routing domain which has a single connection to a "public" backbone, plus a number of private links to other leaf routing domains, can be treated as if it were single-homed to the backbone for the purpose of IP address allocation. We expect that this is also another way of dealing with multi-homed domains.
5.6 Zero-Homed Routing Domains
5.6 Zero-Homed Routing Domains
Currently, a very large number of organizations have internal
communications networks which are not connected to any service
providers. Such organizations may, however, have a number of
Currently, a very large number of organizations have internal communications networks which are not connected to any service providers. Such organizations may, however, have a number of
Rekhter & Li [Page 17] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhter & Li [Page 17] RFC 1518 CIDR Address Allocation Architecture September 1993
private links that they use for communications with other
organizations. Such organizations do not participate in global
routing, but are satisfied with reachability to those
organizations with which they have established private links.
These are referred to as zero-homed routing domains.
private links that they use for communications with other organizations. Such organizations do not participate in global routing, but are satisfied with reachability to those organizations with which they have established private links. These are referred to as zero-homed routing domains.
Zero-homed routing domains can be considered as the degenerate
case of routing domains with private links, as discussed in the
previous section, and do not pose a problem for inter-domain
routing. As above, the routing information exchanged across the
private links sees very limited distribution, usually only to the
routing domain at the other end of the link. Thus, there are no
address abstraction requirements beyond those inherent in the
address prefixes exchanged across the private link.
無、家へ帰り、経路ドメインは、前項で議論するように個人的なリンクがある経路ドメインの堕落したケースであるとみなすことができて、相互ドメインルーティングのために問題を設定しません。 同じくらい上では、個人的なリンクの向こう側に交換されたルーティング情報が非常に限られた分配を見ます、通常リンクのもう一方の端の経路ドメインだけに。 したがって、アドレス抽象化要件は全く個人的なリンクの向こう側に交換されたアドレス接頭語に固有のそれらを超えていません。
However, it is important that zero-homed routing domains use valid
globally unique IP addresses. Suppose that the zero-homed routing
domain is connected through a private link to a routing domain.
Further, this routing domain participates in an internet that
subscribes to the global IP addressing plan. This domain must be
able to distinguish between the zero-homed routing domain's IP
addresses and any other IP addresses that it may need to route to.
The only way this can be guaranteed is if the zero-homed routing
domain uses globally unique IP addresses.
しかしながら、それが重要である、それ、無、家へ帰り、経路ドメインは有効なグローバルにユニークなIPアドレスを使用します。 それを仮定してください、無、家へ帰り、経路ドメインは経路ドメインへの個人的なリンクを通してつなげられます。 さらに、この経路ドメインはグローバルなIPアドレシングプランに加入するインターネットに参加します。 このドメインが見分けることができなければならない、無、家へ帰り、ドメインのIPアドレスとそれが発送する必要があるかもしれないいかなる他のIPアドレスも発送します。 これを保証できる唯一の方法がそうである、無、家へ帰り、経路ドメインはグローバルにユニークなIPアドレスを使用します。
5.7 Continental aggregation
5.7 大陸の集合
Another level of hierarchy may also be used in this addressing
scheme to further reduce the amount of routing information
necessary for inter-continental routing. Continental aggregation
is useful because continental boundaries provide natural barriers
to topological connection and administrative boundaries. Thus, it
presents a natural boundary for another level of aggregation of
inter-domain routing information. To make use of this, it is
necessary that each continent be assigned an appropriate subset of
the address space. Providers (both direct and indirect) within
that continent would allocate their addresses from this space.
Note that there are numerous exceptions to this, in which a
service provider (either direct or indirect) spans a continental
division. These exceptions can be handled similarly to multi-
homed routing domains, as discussed above.
また、別のレベルの階層構造は、大陸間ルーティングのためにルーティング必要情報の量をさらに減少させるのにこのアドレシング計画に使用されるかもしれません。 大陸の境界が位相的な接続と管理境界に天然バリアを提供するので、大陸の集合は役に立ちます。 したがって、それは別のレベルの相互ドメインルーティング情報の集合のために固有の境界を提示します。 これを利用するために、アドレス空間の適切な部分集合が各大陸に割り当てられるのが必要です。 その大陸の中のプロバイダー(ダイレクトものと同様に間接的な)はこのスペースからそれらのアドレスを割り当てるでしょう。 これへの多数の例外があることに注意してください。(そこでは、サービスプロバイダー(直接の、または、間接的な)は大陸の分割にかかります)。 同様にこれらの例外を扱うことができる、マルチ、家へ帰り、上で議論するようにドメインを発送します。
Note that, in contrast to the case of providers, the aggregation
of continental routing information may not be done on the
continent to which the prefix is allocated. The cost of inter-
continental links (and especially trans-oceanic links) is very
high. If aggregation is performed on the "near" side of the link,
then routing information about unreachable destinations within
プロバイダーに関するケースと対照して接頭語が割り当てられる大陸で大陸のルーティング情報の集合をしないかもしれないことに注意してください。 相互大陸のリンク(そして、特に移-海洋のリンク)の費用は非常に高いです。 集合であるなら、リンクの「近い」側面に実行されて、次に、手の届かない目的地に関して情報を発送するのが中にありますか?
Rekhter & Li [Page 18] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[18ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
that continent can only reside on that continent. Alternatively,
if continental aggregation is done on the "far" side of an inter-
continental link, the "far" end can perform the aggregation and
inject it into continental routing. This means that destinations
which are part of the continental aggregation, but for which there
is not a corresponding more specific prefix can be rejected before
leaving the continent on which they originated.
その大陸はその大陸に住むことができるだけです。 あるいはまた、相互大陸のリンクの「遠い」側面で大陸の集合をするなら、「遠い」終わりは、集合を実行して、大陸のルーティングにそれを注ぐことができます。 これは、それらが由来した大陸を出る前に大陸の集合の一部ですが、どれが対応するより特定の接頭語がないか一部である目的地は拒絶できることを意味します。
For example, suppose that Europe is assigned a prefix of
<194.0.0.0 254.0.0.0>, such that European routing also contains
the longer prefixes <194.1.0.0 255.255.0.0> and <194.2.0.0
255.255.0.0>. All of the longer European prefixes may be
advertised across a trans-Atlantic link to North America. The
router in North America would then aggregate these routes, and
only advertise the prefix <194.0.0.0 255.0.0.0> into North
American routing. Packets which are destined for 194.1.1.1 would
traverse North American routing, but would encounter the North
American router which performed the European aggregation. If the
prefix <194.1.0.0 255.255.0.0> is unreachable, the router would
drop the packet and send an ICMP Unreachable without using the
trans-Atlantic link.
例えば、<194.0.0.0 254.0.0.0>の接頭語がそのヨーロッパに割り当てられるなら、また、ヨーロッパのルーティングが、より長い含んでいるようなものは<194.1.0.0 255.255.0の.0>と<194.2.0.0 255.255.0.0>を前に置きます。 北アメリカへの大西洋横断のリンクの向こう側により長いヨーロッパの接頭語のすべての広告を出すかもしれません。 北アメリカのルータは、次に、これらのルートに集めて、接頭語<194.0.0.0 255.0.0.0>の北米のルーティングに広告を出すだけでしょう。 どれが194.1のために運命づけられているか。パケット、.1 ヨーロッパの集合を実行した北米のルータに遭遇するだろうというのを除いて、.1は北米のルーティングを横断するでしょう。 接頭語<194.1.0.0 255.255.0.0>が手が届かないなら、大西洋横断のリンクを使用しないで、ルータは、パケットを落として、ICMP Unreachableを送るでしょう。
5.8 Transition Issues
5.8 変遷問題
Allocation of IP addresses based on connectivity to TRDs is
important to allow scaling of inter-domain routing to an internet
containing millions of routing domains. However, such address
allocation based on topology implies that in order to maximize the
efficiency in routing gained by such allocation, certain changes
in topology may suggest a change of address.
TRDsへの接続性に基づくIPアドレスの配分は、インターネットに掘られる相互ドメイン含有のスケーリングに何百万もの経路ドメインを許容するために重要です。 しかしながら、トポロジーに基づくそのようなアドレス配分は、トポロジーのある変化がそのような配分で獲得されたルーティングで効率を最大にするために住所の変更を示すかもしれないのを含意します。
Note that an address change need not happen immediately. A domain
which has changed service providers may still advertise its prefix
through its new service provider. Since upper levels in the
routing hierarchy will perform routing based on the longest
prefix, reachability is preserved, although the aggregation and
scalability of the routing information has greatly diminished.
Thus, a domain which does change its topology should change
addresses as soon as convenient. The timing and mechanics of such
changes must be the result of agreements between the old service
provider, the new provider, and the domain.
アドレス変化がすぐに起こる必要はないことに注意してください。 サービスプロバイダーを変えたドメインは新しいサービスプロバイダーを通してまだ接頭語の広告を出しているかもしれません。 ルーティング階層構造の上側のレベルが最も長い接頭語に基づくルーティングを実行するので、可到達性は保存されます、ルーティング情報の集合とスケーラビリティは大いに減少しましたが。 したがって、トポロジーを変えるドメインは都合のつき次第アドレスを変えるべきです。 そのような変化のタイミングと整備士は古いサービスプロバイダーと、新しいプロバイダーと、ドメインとの協定の結果であるに違いありません。
This need to allow for change in addresses is a natural,
inevitable consequence of routing data abstraction. The basic
notion of routing data abstraction is that there is some
correspondence between the address and where a system (i.e., a
routing domain, subnetwork, or end system) is located. Thus if the
system moves, in some cases the address will have to change. If it
アドレスにおける変化を考慮するこの必要性はルーティングデータ抽象化の自然で、必然の結果です。 ルーティングデータ抽象化の基本的な概念はアドレスの間と、そして、システム(すなわち、経路ドメイン、サブネットワーク、またはエンドシステム)が位置しているところに何らかの通信があるということです。 したがって、システムが動くと、いくつかの場合、アドレスは変化しなければならないでしょう。 それです。
Rekhter & Li [Page 19] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[19ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
were possible to change the connectivity between routing domains
without changing the addresses, then it would clearly be necessary
to keep track of the location of that routing domain on an
individual basis.
経路ドメインの間でアドレス(個々ベースのその経路ドメインの位置のその時動向をおさえるのが明確に必要である)を変えないで接続性を変えるのにおいて、可能でした。
In the short term, due to the rapid growth and increased
commercialization of the Internet, it is possible that the
topology may be relatively volatile. This implies that planning
for address transition is very important. Fortunately, there are a
number of steps which can be taken to help ease the effort
required for address transition. A complete description of address
transition issues is outside of the scope of this paper. However,
a very brief outline of some transition issues is contained in
this section.
短期で、急速な成長と増加するインターネットの商用化のために、トポロジーが比較的不安定であることは、可能です。 これは、アドレス変遷の計画を立てるのが非常に重要であることを含意します。 幸い、努力がアドレス変遷のために必要とした容易さを助けるために取ることができる多くの方法があります。 アドレス変遷問題の完全な記述がこの紙の範囲の外にあります。 しかしながら、いくつかの変遷問題の非常に簡潔なアウトラインはこのセクションに含まれています。
Also note that the possible requirement to transition addresses
based on changes in topology imply that it is valuable to
anticipate the future topology changes before finalizing a plan
for address allocation. For example, in the case of a routing
domain which is initially single-homed, but which is expecting to
become multi-homed in the future, it may be advantageous to assign
IP addresses based on the anticipated future topology.
また、トポロジーの変化に基づく変遷アドレスへの可能な要件が、アドレス配分のために計画を仕上げる前に将来のトポロジー変化を予期するのが貴重であることを含意することに注意してください。 例えば、経路ドメインの場合では、初めはどれがそうかがシングル家へ帰りましたが、どれがなるようにおめでたの予定であるか、マルチ、家へ帰り、将来、予期された将来のトポロジーに基づくIPアドレスを割り当てるのは有利であるかもしれません。
In general, it will not be practical to transition the IP
addresses assigned to a routing domain in an instantaneous "change
the address at midnight" manner. Instead, a gradual transition is
required in which both the old and the new addresses will remain
valid for a limited period of time. During the transition period,
both the old and new addresses are accepted by the end systems in
the routing domain, and both old and new addresses must result in
correct routing of packets to the destination.
一般に、それはIPアドレスが「真夜中にアドレスを変えてください」という瞬時に起こっている方法で経路ドメインに割り当てた変遷に実用的にならないでしょう。 代わりに、時間の限定期間の間老人と新しいアドレスの両方が有効なままで残っているゆるやかな変遷が必要です。 過渡期の間、経路ドメインのエンドシステムで両方の古くて新しいアドレスを受け入れます、そして、古いものと同様に新しいアドレスは目的地へのパケットの正しいルーティングをもたらさなければなりません。
During the transition period, it is important that packets using
the old address be forwarded correctly, even when the topology has
changed. This is facilitated by the use of "longest match"
inter-domain routing.
過渡期の間、正しく旧住所を使用するパケットを進めるのは重要です、トポロジーが変化さえしたとき。 これは「最も長いマッチ」相互ドメインルーティングの使用で容易にされます。
For example, suppose that the XYZ Corporation was previously
connected only to the NorthSouthNet regional. The XYZ Corporation
therefore went off to the NorthSouthNet administration and got an
IP address prefix assignment based on the IP address prefix value
assigned to the NorthSouthNet regional. However, for a variety of
reasons, the XYZ Corporation decided to terminate its association
with the NorthSouthNet, and instead connect directly to the
NewCommercialNet public data network. Thus the XYZ Corporation now
has a new address assignment under the IP address prefix assigned
to the NewCommercialNet. The old address for the XYZ Corporation
would seem to imply that traffic for the XYZ Corporation should be
例えば、XYZ社が以前にNorthSouthNetだけに地方で接続されたと仮定してください。 XYZ社は、したがって、NorthSouthNet管理へ去って、NorthSouthNetに割り当てられたIPアドレス接頭語価値に基づくIPアドレス接頭語課題を地方にしました。 しかしながら、さまざまな理由で、XYZ社は、NorthSouthNetと共に協会を終えて、代わりに直接NewCommercialNet公衆データネットワークに接続すると決めました。 したがって、XYZ社は現在、NewCommercialNetに割り当てられたIPアドレス接頭語の下で新しいアドレス課題を持っています。 XYZ社のための旧住所はXYZ社のための交通がそうであるべきであることを含意するように思えるでしょう。
Rekhter & Li [Page 20] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[20ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
routed to the NorthSouthNet, which no longer has any direct
connection with XYZ Corporation.
NorthSouthNetに、掘りました。(もう、NorthSouthNetはXYZ社との少しのダイレクト接続もいません)。
If the old TRD (NorthSouthNet) and the new TRD (NewCommercialNet)
are adjacent and cooperative, then this transition is easy to
accomplish. In this case, packets routed to the XYZ Corporation
using the old address assignment could be routed to the
NorthSouthNet, which would directly forward them to the
NewCommercialNet, which would in turn forward them to XYZ
Corporation. In this case only NorthSouthNet and NewCommercialNet
need be aware of the fact that the old address refers to a
destination which is no longer directly attached to NorthSouthNet.
古いTRD(NorthSouthNet)と新しいTRD(NewCommercialNet)が隣接していて協力的であるなら、この変遷は達成しやすいです。 この場合、旧住所課題を使用することでXYZ社に発送されたパケットはNorthSouthNetに発送できました。(直接、NorthSouthNetはそれらをNewCommercialNetに送るでしょう)。(順番に、NewCommercialNetはXYZ社にそれらを送るでしょう)。 この場合、NorthSouthNetとNewCommercialNetだけが旧住所がもう直接NorthSouthNetに付けられていない目的地について言及するという事実を知っていなければなりません。
If the old TRD and the new TRD are not adjacent, then the
situation is a bit more complex, but there are still several
possible ways to forward traffic correctly.
古いTRDと新しいTRDが隣接していないなら、状況はもう少し複雑ですが、正しく交通を進めるいくつかの可能な方法がまだあります。
If the old TRD and the new TRD are themselves connected by other
cooperative transit routing domains, then these intermediate
domains may agree to forward traffic for XYZ correctly. For
example, suppose that NorthSouthNet and NewCommercialNet are not
directly connected, but that they are both directly connected to
the BBNet backbone. In this case, all three of NorthSouthNet,
NewCommercialNet, and the BBNet backbone would need to maintain a
special entry for XYZ corporation so that traffic to XYZ using the
old address allocation would be forwarded via NewCommercialNet.
However, other routing domains would not need to be aware of the
new location for XYZ Corporation.
古いTRDと新しいTRDが他の協力的なトランジット経路ドメインによって接続されるなら、これらの中間的ドメインは、XYZのために正しく交通を進めるのに同意するかもしれません。 例えば、NorthSouthNetとNewCommercialNetが直接接続されませんが、それらがともに直接BBNet背骨に接続されると仮定してください。 この場合、NorthSouthNet、NewCommercialNet、およびすべての3つのBBNet背骨が、NewCommercialNetを通して旧住所配分を使用するXYZへの交通を進めて、XYZ会社のために特別なエントリーを維持する必要があるでしょう。 しかしながら、他の経路ドメインはXYZ社において新しい位置を意識している必要はないでしょう。
Suppose that the old TRD and the new TRD are separated by a non-
cooperative routing domain, or by a long path of routing domains.
In this case, the old TRD could encapsulate traffic to XYZ
Corporation in order to deliver such packets to the correct
backbone.
古いTRDと新しいTRDが非協力的な経路ドメイン、または経路ドメインの長い経路によって切り離されると仮定してください。 この場合、古いTRDは、そのようなパケットを正しい背骨に届けるためにXYZ社に交通を要約できました。
Also, those locations which do a significant amount of business
with XYZ Corporation could have a specific entry in their routing
tables added to ensure optimal routing of packets to XYZ. For
example, suppose that another commercial backbone
"OldCommercialNet" has a large number of customers which exchange
traffic with XYZ Corporation, and that this third TRD is directly
connected to both NorthSouthNet and NewCommercialNet. In this case
OldCommercialNet will continue to have a single entry in its
routing tables for other traffic destined for NorthSouthNet, but
may choose to add one additional (more specific) entry to ensure
that packets sent to XYZ Corporation's old address are routed
correctly.
また、XYZ社と共に重要な取引高をするそれらの位置はパケットの最適ルーティングをXYZに確実にするために加えられたそれらの経路指定テーブルに特定のエントリーを持っているかもしれません。 例えば、別の商業背骨"OldCommercialNet"にはXYZ社と交通を交換する顧客の多くがあって、この第3TRDが直接NorthSouthNetとNewCommercialNetの両方に接続されると仮定してください。 この場合、OldCommercialNetは、NorthSouthNetのために運命づけられた他の交通のための経路指定テーブルに単一のエントリーを持ち続けますが、XYZ社の旧住所に送られたパケットが正しく発送されるのを保証するために1つの追加している(より特定の)エントリーを加えるのを選ぶかもしれません。
Rekhter & Li [Page 21] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[21ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
Whichever method is used to ease address transition, the goal is
that knowledge relating XYZ to its old address that is held
throughout the global internet would eventually be replaced with
the new information. It is reasonable to expect this to take
weeks or months and will be accomplished through the distributed
directory system. Discussion of the directory, along with other
address transition techniques such as automatically informing the
source of a changed address, are outside the scope of this paper.
アドレス変遷を緩和するのに使用される方法、目標は結局グローバルなインターネット中に保持される旧住所にXYZに関連する知識を新情報に取り替えるだろうということです。 それは、これが何週間も何カ月もかかると予想するのが妥当であり、分配されたディレクトリシステムを通して熟達するでしょう。 この紙の範囲の外にディレクトリの議論が変えられたアドレスについて自動的にソースに知らせなどなどの他のアドレス変遷のテクニックと共にあります。
Another significant transition difficulty is the establishment of
appropriate addressing authorities. In order not to delay the
deployment of this addressing scheme, if no authority has been
created at an appropriate level, a higher level authority may
allocated addresses instead of the lower level authority. For
example, suppose that the continental authority has been allocated
a portion of the address space and that the service providers
present on that continent are clear, but have not yet established
their addressing authority. The continental authority may foresee
(possibly with information from the provider) that the provider
will eventually create an authority. The continental authority
may then act on behalf of that provider until the provider is
prepared to assume its addressing authority duties.
別の重要な変遷困難は適切なアドレシング当局の設立です。 このアドレシング計画の展開を遅らせない命令では、権威が全く適正水準で作成されていないなら、より高い平らな権威は下のレベル権威の代わりに割り当てられたアドレスを作成されます。 例えば、その大陸の現サービスプロバイダーが、アドレス空間の部分を大陸の権威に割り当てて、明確ですが、権威を記述するのをまだ確立していないと仮定してください。 大陸の権威は、プロバイダーが結局権威を作成するのを見通すかもしれません(ことによるとプロバイダーからの情報で)。 そして、プロバイダーが権威義務を記述すると仮定するように準備されるまで、大陸の権威はそのプロバイダーを代表して行動するかもしれません。
Finally, it is important to emphasize, that a change of addresses
due to changes in topology is not mandated by this document. The
continental level addressing hierarchy, as discussed in Section
5.7, is intended to handle the aggregation of reachability
information in the cases where addresses do not directly reflect
the connectivity between providers and subscribers.
最終的に、それが強調するために重要である、トポロジーの変化によるアドレスのそのa変化はこのドキュメントによって強制されません。 セクション5.7で議論する大陸の平らなアドレシング階層構造がアドレスが直接プロバイダーと加入者の間の接続性を反映しない場合における、可到達性情報の集合を扱うことを意図します。
5.9 Interaction with Policy Routing
5.9 方針ルート設定との相互作用
We assume that any inter-domain routing protocol will have
difficulty trying to aggregate multiple destinations with
dissimilar policies. At the same time, the ability to aggregate
routing information while not violating routing policies is
essential. Therefore, we suggest that address allocation
authorities attempt to allocate addresses so that aggregates of
destinations with similar policies can be easily formed.
私たちは、どんな相互ドメインルーティング・プロトコルも異なった方針で複数の目的地に集めようとするのに苦労すると思います。 同時に、ルーティング方針に違反していない間にルーティング情報に集める能力は不可欠です。 したがって、私たちは、アドレス配分当局が、容易に同様の方針がある目的地の集合を形成できるようにアドレスを割り当てるのを試みることを提案します。
6. Recommendations
6. 推薦
We anticipate that the current exponential growth of the Internet
will continue or accelerate for the foreseeable future. In
addition, we anticipate a rapid internationalization of the
Internet. The ability of routing to scale is dependent upon the
use of data abstraction based on hierarchical IP addresses. As
CIDR [1] is introduced in the Internet, it is therefore essential
私たちは、インターネットの現在の急激な増加が予見できる未来に続くか、または加速すると予期します。 さらに、私たちはインターネットの急速な国際化を予期します。 ルーティングが比例する能力は階層的なIPアドレスに基づくデータ抽象化の使用に依存しています。 したがって、それがCIDR[1]がインターネットで導入されるのが不可欠であるので
Rekhter & Li [Page 22] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[22ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
to choose a hierarchical structure for IP addresses with great
care.
IPアドレスのための階層構造を細心の注意を払って選ぶために。
It is in the best interests of the internetworking community that
the cost of operations be kept to a minimum where possible. In the
case of IP address allocation, this again means that routing data
abstraction must be encouraged.
インターネットワーキング共同体の利益のためでは、操作の費用が可能であるところで最小限に保たれるのは、そうです。 IPアドレス配分の場合では、これは、再びルーティングデータ抽象化を奨励しなければならないことを意味します。
In order for data abstraction to be possible, the assignment of IP
addresses must be accomplished in a manner which is consistent
with the actual physical topology of the Internet. For example, in
those cases where organizational and administrative boundaries are
not related to actual network topology, address assignment based
on such organization boundaries is not recommended.
データ抽象化が可能であるように、インターネットの実際の物理的なトポロジーと一致した方法でIPアドレスの課題を実行しなければなりません。 例えば、組織的で管理の境界が実際のネットワーク形態に関連しないそれらの場合では、そのような組織境界に基づくアドレス課題は推薦されません。
The intra-domain routing protocols allow for information
abstraction to be maintained within a domain. For zero-homed and
single-homed routing domains (which are expected to remain zero-
homed or single-homed), we recommend that the IP addresses
assigned within a single routing domain use a single address
prefix assigned to that domain. Specifically, this allows the set
of all IP addresses reachable within a single domain to be fully
described via a single prefix.
イントラドメインルーティング・プロトコルは、情報抽象化がドメインの中で維持されるのを許容します。 無、家へ帰り、ドメインを発送しながらシングル家へ帰る、(残っていると予想される、無、家へ帰り、シングル家へ帰る、)、私たちは、IPアドレスがただ一つの経路ドメイン使用の中でそのドメインに割り当てられたただ一つのアドレス接頭語を割り当てたことを勧めます。 明確に、これは、単一領域の中で届いているすべてのIPアドレスのセットがただ一つの接頭語で完全に説明されるのを許容します。
We anticipate that the total number of routing domains existing on
a worldwide Internet to be great enough that additional levels of
hierarchical data abstraction beyond the routing domain level will
be necessary.
私たちは、経路ドメインを超えた階層データ抽象化の追加レベルが平らにする十分すばらしくなるように世界的なインターネットに存在する経路ドメインの総数が必要になると予期します。
In most cases, network topology will have a close relationship
with national boundaries. For example, the degree of network
connectivity will often be greater within a single country than
between countries. It is therefore appropriate to make specific
recommendations based on national boundaries, with the
understanding that there may be specific situations where these
general recommendations need to be modified.
多くの場合、ネットワーク形態には、国境との密接な関係があるでしょう。 例えば、ネットワークの接続性の度合いは国より単一の国の中でしばしばさらに大きくなるでしょう。 したがって、国境に基づく特定の推薦状をするのは適切です、特定の状況がこれらの一般的な推薦が変更される必要があるところにあるかもしれないという条件で。
6.1 Recommendations for an address allocation plan
アドレス配分のための6.1の推薦状が計画されています。
We anticipate that public interconnectivity between private
routing domains will be provided by a diverse set of TRDs,
including (but not necessarily limited to):
私たちは個人的な経路ドメインの間の公共の相互接続性にTRDsのさまざまのセットによって提供されて、含むのと(必ず有限であるというわけではない)であると予期します:
- backbone networks (Alternet, ANSnet, CIX, EBone, PSI,
SprintLink);
- 背骨は(Alternet、ANSnet、CIX、EBone、PSI、SprintLink)をネットワークでつなぎます。
- a number of regional or national networks; and,
- 多くの地方の、または、国家のネットワーク。 そして
Rekhter & Li [Page 23] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[23ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
- a number of commercial Public Data Networks.
- 多くの商業Public Data Networks。
These networks will not be interconnected in a strictly hierarchical manner (for example, there is expected to be direct connectivity between regionals, and all of these types of networks may have direct international connections). However, the total number of such TRDs is expected to remain (for the foreseeable future) small enough to allow addressing of this set of TRDs via a flat address space. These TRDs will be used to interconnect a wide variety of routing domains, each of which may comprise a single corporation, part of a corporation, a university campus, a government agency, or other organizational unit.
これらのネットワークは厳密に階層的な方法でインタコネクトされないでしょう(例えば、地方版の間でダイレクト接続性があると予想されます、そして、これらのタイプのネットワークのすべてには、ダイレクト国際的な接続があるかもしれません)。 しかしながら、そのようなTRDsの総数がフラットアドレス空間を通して記述するのをTRDsのこのセットを許容できるくらい小さいままで残っている(予見できる未来に)と予想されます。 これらのTRDsは、さまざまな経路ドメインとインタコネクトするのに使用されるでしょう。それはそれぞれ単一の会社、会社の一部、大学構内、政府機関、または他の組織的なユニットを包括するかもしれません。
In addition, some private corporations may be expected to make use of dedicated private TRDs for communication within their own corporation.
さらに、いくつかの私法人がコミュニケーションにそれら自身の会社の中で専用個人的なTRDsを利用すると予想されるかもしれません。
We anticipate that the great majority of routing domains will be attached to only one of the TRDs. This will permit hierarchical address aggregation based on TRD. We therefore strongly recommend that addresses be assigned hierarchically, based on address prefixes assigned to individual TRDs.
私たちは、経路ドメインの大多数がTRDsの1つだけに付けられると予期します。 これはTRDに基づく階層的なアドレス集合を可能にするでしょう。 したがって、私たちは、アドレスが個々のTRDsに割り当てられたアドレス接頭語に基づいて階層的に割り当てられることを強く勧めます。
To support continental aggregation of routes, we recommend that all addresses for TRDs which are wholly within a continent be taken from the continental prefix.
ルートの大陸の集合を支持するために、私たちは、完全に大陸の中にあるTRDsのためのすべてのアドレスが大陸の接頭語から取られることを勧めます。
For the proposed address allocation scheme, this implies that portions of IP address space should be assigned to each TRD (explicitly including the backbones and regionals). For those leaf routing domains which are connected to a single TRD, they should be assigned a prefix value from the address space assigned to that TRD.
提案されたアドレス配分体系のために、これは、IPアドレス空間の部分が各TRDに割り当てられるべきであるのを含意します(明らかに背骨と地方版を含んでいて)。 独身のTRDにつなげられるそれらの葉の経路ドメインにおいて、接頭語値はそのTRDに割り当てられたアドレス空間からそれらに割り当てられるべきです。
For routing domains which are not attached to any publically available TRD, there is not the same urgent need for hierarchical address abbreviation. We do not, therefore, make any additional recommendations for such "isolated" routing domains. Where such domains are connected to other domains by private point-to-point links, and where such links are used solely for routing between the two domains that they interconnect, again no additional technical problems relating to address abbreviation is caused by such a link, and no specific additional recommendations are necessary.
どんなpublicallyに利用可能なTRDにも付けられていない経路ドメインには、階層的なアドレス略語の同じ緊急の必要がありません。 したがって、私たちはそのような「孤立している」経路ドメインのための少しの追加推薦状もしません。 そのようなドメインがどこで個人的なポイントツーポイント接続によって他のドメインにつなげられるか、そして、唯一再びそれらがインタコネクトする2つのドメインと、アドレス略語に関連するのがそのようなリンクによって引き起こされる追加技術的問題がなくて、特定の追加推薦の間のルーティングにおいて、そのようなリンクがどこで使用されているかが必要です。
Further, in order to allow aggregation of IP addresses at national and continental boundaries into as few prefixes as possible, we further recommend that IP addresses allocated to routing domains should be assigned based on each routing domain's connectivity to national and continental Internet backbones.
さらに、国家の、そして、大陸の境界にできるだけわずかしかIPアドレスの集合を接頭語に許容しないように、私たちは、経路ドメインに割り当てられたIPアドレスが国家の、そして、大陸のインターネットの基幹への各経路ドメインの接続性に基づいて割り当てられるべきであることをさらに勧めます。
Rekhter & Li [Page 24] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[24ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
6.2 Recommendations for Multi-Homed Routing Domains
6.2の推薦、マルチ、家へ帰り、経路ドメイン
There are several possible ways that these multi-homed routing domains may be handled, as described in Section 5.4. Each of these methods vary with respect to the amount of information that must be maintained for inter-domain routing and also with respect to the inter-domain routes. In addition, the organization that will bear the brunt of this cost varies with the possible solutions. For example, the solutions vary with respect to:
いくつかの可能な道がある、それ、これら、マルチ、家へ帰り、経路ドメインはセクション5.4で説明されるように扱われるかもしれません。 それぞれのこれらの方法は相互ドメインルーティングと相互ドメインルートに関しても維持しなければならない情報量に関して異なります。 さらに、この費用のほこさきに堪える組織は可能な解決策で異なります。 例えば、解決策は以下に関して異なります。
- resources used within routers within the TRDs;
- TRDsの中のルータの中の運用資金。
- administrative cost on TRD personnel; and,
- TRD人員の管理費。 そして
- difficulty of configuration of policy-based inter-domain routing
information within leaf routing domains.
- 葉の経路ドメインの中の方針ベースの相互ドメインルーティング情報の構成の困難。
Also, the solution used may affect the actual routes which packets follow, and may effect the availability of backup routes when the primary route fails.
また、使用される解決策は、パケットが従う実際のルートに影響して、幹線道路が失敗すると、バックアップルートの有用性に作用するかもしれません。
For these reasons it is not possible to mandate a single solution for all situations. Rather, economic considerations will require a variety of solutions for different routing domains, service providers, and backbones.
これらの理由で、すべての状況のただ一つの解決策を強制するのは可能ではありません。 むしろ、経済上の考慮は異なった経路ドメイン、サービスプロバイダー、および背骨のさまざまな解決策を必要とするでしょう。
6.3 Recommendations for the Administration of IP addresses
6.3 IP政権アドレスのための推薦
A companion document [3] provides recommendations for the administrations of IP addresses.
仲間ドキュメント[3]はIPアドレスの政権に推薦を提供します。
7. Acknowledgments
7. 承認
The authors would like to acknowledge the substantial contributions made by the authors of RFC 1237 [2], Richard Colella, Ella Gardner, and Ross Callon. The significant concepts (and a large portion of the text) in this document are taken directly from their work.
作者はRFC1237[2]、リチャードColella、エラ・ガードナー、およびロスCallonの作者によってされた多大な貢献を承諾したがっています。 直接彼らの仕事から重要な概念(そして、テキストの大半)を本書では、取ります。
The authors would like to acknowledge the substantial contributions made by the members of the following two groups, the Federal Engineering Planning Group (FEPG) and the International Engineering Planning Group (IEPG). This document also reflects many concepts expressed at the IETF Addressing BOF which took place in Cambridge, MA in July 1992.
作者は、多大な貢献が以下のメンバーのそばで2つのグループ、連邦政府のEngineering Planning Group(FEPG)、および国際Engineering Planning Groupを(IEPG)にしたと認めたがっています。 また、このドキュメントは1992年7月にケンブリッジ(MA)で行われたIETF Addressing BOFで言い表された多くの概念を反映します。
We would also like to thank Peter Ford (Los Alamos National Laboratory), Elise Gerich (MERIT), Steve Kent (BBN), Barry Leiner (ADS), Jon Postel (ISI), Bernhard Stockman (NORDUNET/SUNET), Claudio
クラウディオ、また、ピーター・フォード(ロスアラモス国立研究所)、エリーズGerich(MERIT)、スティーブ・ケント(BBN)、バリーLeiner(ADS)、ジョン・ポステル(ISI)、バーンハードStockman(NORDUNET/SUNET)に感謝申し上げます。
Rekhter & Li [Page 25] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[25ページ]RFC1518CIDRは構造1993年9月に配分を記述します。
Topolcic (CNRI), and Kannan Varadhan (OARnet) for their review and constructive comments.
Topolcic(CNRI)、および彼らのレビューと建設的なコメントのためのKannan Varadhan(OARnet)。
8. References
8. 参照
[1] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an
Address Assignment and Aggregation Strategy", RFC 1338, BARRNet,
cicso, Merit, OARnet, June 1992.
[1] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「スーパーネッティング:」 Merit、OARnet、「Address AssignmentとAggregation Strategy」(RFC1338、BARRNet)がcicsoする、6月1992日
[2] Colella, R., Gardner, E, and R. Callon, "Guidelines for OSI NSAP
Allocation in the Internet", RFC 1237, JuNIST, Mitre, DEC, July
1991.
[2]Colella、R.、ガードナー、E、およびR.Callon、「インターネットのオウシNSAP Allocationのためのガイドライン」、RFC1237、JuNIST、斜め継ぎ、12月(1991年7月)。
[3] Gerich, E., "Guidelines for Management of IP Address Space", RFC
1466, Merit, May 1993.
[3]Gerich、「IP管理アドレス空間のためのガイドライン」(RFC1466)が1993年5月に値するE.。
[4] Cerf, V., "IAB Recommended Policy on Distributing Internet
Identifier Assignment and IAB Recommended Policy Change to
Internet "Connected" Status", RFC 1174, CNRI, August 1990.
[4] サーフ、V.、「インターネット識別子課題を広げることに関するIABのお勧めの方針とインターネットへのIABのお勧めの政策変更は状態を「接続」でした」、RFC1174、CNRI、1990年8月。
9. Security Considerations
9. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Rekhter & Li [Page 26] RFC 1518 CIDR Address Allocation Architecture September 1993
Rekhterと李[26ページ]RFC1518CIDRは構造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
Tony Li cisco Systems, Inc. 1525 O'Brien Drive Menlo Park, CA 94025
トニー李コクチマスSystems Inc.1525オブライエン・Driveメンローパーク、カリフォルニア 94025
EMail: tli@cisco.com
メール: tli@cisco.com
Rekhter & Li [Page 27]
Rekhterと李[27ページ]
一覧
スポンサーリンク
