RFC1519 日本語訳
1519 Classless Inter-Domain Routing (CIDR): an Address Assignment andAggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September 1993. (Format: TXT=59998 bytes) (Obsoletes RFC1338) (Obsoleted by RFC4632) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group V. Fuller
Request for Comments: 1519 BARRNet
Obsoletes: 1338 T. Li
Category: Standards Track cisco
J. Yu
MERIT
K. Varadhan
OARnet
September 1993
コメントを求めるワーキンググループのV.の、よりふくよかな要求をネットワークでつないでください: 1519BARRNetは以下を時代遅れにします。 1338年のT.李カテゴリ: 規格、TrackコクチマスJ.ユーMERIT K.Varadhan OARnet1993年9月
Classless Inter-Domain Routing (CIDR):
an Address Assignment and Aggregation Strategy
階級のない相互ドメインルート設定(CIDR): アドレス課題と集合戦略
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はインターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers.
このメモはデフォルト無ルートのルータでテーブルを発送するIPアドレス空間がアドレス空間を保存して、爆発的成長を食い止める存在のアドレス課題のために戦略を検討します。
Table of Contents
目次
Acknowledgements ................................................. 2 1. Problem, Goal, and Motivation ................................ 2 2. CIDR address allocation ...................................... 3 2.1 Aggregation and its limitations ............................. 3 2.2 Distributed network number allocation ....................... 5 3. Cost-benefit analysis ........................................ 6 3.1 Present allocation figures .................................. 7 3.2 Historic growth rates ....................................... 8 3.3 Detailed analysis ........................................... 8 3.3.1 Benefits of new addressing plan ........................... 9 3.3.2 Growth rate projections ................................... 9 4. Changes to inter-domain routing protocols and practices ...... 11 4.1 Protocol-independent semantic changes ....................... 11 4.2 Rules for route advertisement ............................... 11 4.3 How the rules work .......................................... 13 4.4 Responsibility for and configuration of aggregation ......... 14 4.5 Intra-domain protocol considerations ........................ 15 5. Example of new allocation and routing ........................ 15
承認… 2 1. 問題、目標、および動機… 2 2. CIDRは配分を記述します… 3 2.1 集合とその制限… 2.2が分配した3は数の配分をネットワークでつなぎます… 5 3. 費用便益分析… 6 3.1 現在の配分は計算されます… 7 3.2の歴史的な成長率… 8 3.3 詳細な分析… 8 3.3 新しいアドレシングの.1の利益が計画されています… 9 3.3 .2 成長率映像… 9 4. 相互ドメインルーティング・プロトコルへの変化と習慣… 11 4.1 プロトコルから独立している意味変化… 11 4.2 ルート広告のために、統治します… 11 規則が利く4.3… … 13 集合の4.4の責任と構成… 14 4.5 イントラドメインプロトコル問題… 15 5. 新しい配分とルーティングに関する例… 15
Fuller, Li, Yu & Varadhan [Page 1] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[1ページ]RFC1519CIDRは1993年9月に戦略を記述します。
5.1 Address allocation .......................................... 15 5.2 Routing advertisements ...................................... 17 6. Extending CIDR to class A addresses .......................... 18 7. Domain Naming Service considerations ......................... 20 7.1 Procedural changes for class-C "supernets" ................... 20 7.2 Procedural changes for class-A subnetting .................... 21 8. Transitioning to a long term solution ........................ 22 9. Conclusions .................................................. 22 10. Recommendations ............................................. 22 11. References .................................................. 23 12. Security Considerations ..................................... 23 13. Authors' Addresses .......................................... 24
5.1 配分を記述してください… 15 5.2 ルート設定広告… 17 6. クラスAアドレスにCIDRを広げています… 18 7. ドメインNaming Service問題… 20 7.1 クラスC"「スーパー-ネット」"のための手続き上の変化… 20 7.2 クラスAサブネッティングのための手続き上の変化… 21 8. 長期解決策に移行します… 22 9. 結論… 22 10. 推薦… 22 11. 参照… 23 12. セキュリティ問題… 23 13. 作者のアドレス… 24
Acknowledgements
承認
The authors wish to express their appreciation to the members of the ROAD group with whom many of the ideas contained in this document were inspired and developed.
作者は本書では含まれた考えの多くが奮い立たせられて、開発されたROADグループのメンバーに彼らの感謝を申し上げたがっています。
1. Problem, Goal, and Motivation
1. 問題、目標、および動機
As the Internet has evolved and grown over in recent years, it has become evident that it is soon to face several serious scaling problems. These include:
近年インターネットが発展して、終わるようになるのに従って、すぐいくつかの重大なスケーリング問題これらのインクルードに直面していることになっているのは明白になりました:
1. Exhaustion of the class B network address space. One
fundamental cause of this problem is the lack of a network
class of a size which is appropriate for mid-sized
organization; class C, with a maximum of 254 host
addresses, is too small, while class B, which allows up to
65534 addresses, is too large for most organizations.
1. クラスBネットワークアドレス空間の疲労困憊。 この問題の1つの根本的要因が中型の組織に、適切なサイズのネットワークのクラスの不足です。 最大254のホスト・アドレスで、クラスCは小さ過ぎます、ほとんどの組織には、クラスB(最大65534のアドレスを許容します)は大き過ぎますが。
2. Growth of routing tables in Internet routers beyond the
ability of current software, hardware, and people to
effectively manage.
2. 事実上、現在のソフトウェア、ハードウェア、および人々が管理する能力を超えたインターネットルータにおける、経路指定テーブルの成長。
3. Eventual exhaustion of the 32-bit IP address space.
3. 32ビットのIPアドレス空間の最後の疲労困憊。
It has become clear that the first two of these problems are likely to become critical within the next one to three years. This memo attempts to deal with these problems by proposing a mechanism to slow the growth of the routing table and the need for allocating new IP network numbers. It does not attempt to solve the third problem, which is of a more long-term nature, but instead endeavors to ease enough of the short to mid-term difficulties to allow the Internet to continue to function efficiently while progress is made on a longer- term solution.
これらの2つの最初の問題が1〜3年以内に批判的になりそうであるのは明確になりました。 このメモは、経路指定テーブルの成長と新しいIPネットワーク・ナンバーを割り当てる必要性を遅くするためにメカニズムを提案することによってこれらの問題に対処するのを試みます。 それは、3番目の、より長期的に自然な問題を解決するのを試みませんが、短さでインターネットが、進歩が、より長い用語ソリューションで見られる間、効率的に機能し続けているのを許容できるくらい中期の困難の船首を風上に向けるよう代わりに努力します。
Fuller, Li, Yu & Varadhan [Page 2] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[2ページ]RFC1519CIDRは1993年9月に戦略を記述します。
The proposed solution is to topologically allocate future IP address assignment, by allocating segments of the IP address space to the transit routing domains.
提案された解決策は将来のIPアドレス課題を位相的に割り当てることです、IPアドレス空間のセグメントをトランジット経路ドメインに割り当てることによって。
This plan for allocating IP addresses should be undertaken as soon as possible. We believe that this will suffice as a short term strategy, to fill the gap between now and the time when a viable long term plan can be put into place and deployed effectively. This plan should be viable for at least three (3) years, after which time, deployment of a suitable long term solution is expected to occur.
IPアドレスを割り当てるためのこのプランはできるだけ早く、引き受けられるべきです。 私たちが、これが短期間戦略としてその欠陥を補うために現在の間で十分であると信じていて、実行可能な長期プランであるときに、時間を場所に入れて、有効に配備できます。 少なくとも3(3)に、このプランは年間実行可能であるべきです、どの時の後に適当な長期解決策の展開が起こると予想されるか。
This plan is primarily directed at the first two problems listed above. We believe that the judicious use of variable-length subnetting techniques should help defer the onset of the last problem problem, the exhaustion of the 32-bit address space. Note also that improved tools for performing address allocation in a "supernetted" and variably-subnetted world would greatly help the user community in accepting these sometimes confusing techniques. Efforts to create some simple tools for this purpose should be encouraged by the Internet community.
上に記載された最初の2つの問題が主としてこのプランに向けられます。 私たちは、可変長のサブネッティングのテクニックの賢明な使用が、最後の問題問題(32ビットのアドレスのスペースの疲労困憊)の開始を延期するのを助けるべきであると信じています。 また、"「スーパー-網で覆」い"の、そして、変化しやすく「副-網で覆」われた世界でアドレス配分を実行するための改良されたツールが、ユーザーコミュニティがテクニックを時々混乱させながらこれらを受け入れるのを大いに手伝うことに注意してください。 いくつかのツールは簡単な作成するためには努力がインターネットコミュニティによってこのために奨励されるべきです。
Note that this plan neither requires nor assumes that already assigned addresses will be reassigned, though if doing so were possible, it would further reduce routing table sizes. It is assumed that routing technology will be capable of dealing with the current routing table size and with some reasonably small rate of growth. The emphasis of this plan is on significantly slowing the rate of this growth.
このプランが、既に割り当てられたアドレスが再選任されると必要でない、また仮定しないことに注意してください、そうするのが可能であるなら、経路指定テーブルサイズをさらに減少させるでしょうにが。 ルーティング技術が現在の経路指定テーブルサイズに対処して、何らかの合理的にわずかな成長率でできると思われます。 このプランの強調がこの成長のレートをかなり遅くするところにあります。
Note that this plan does not require domains to renumber if they change their attached transit routing domain. Domains are encouraged to renumber so that their individual address allocations do not need to be advertised.
自己の付属トランジット経路ドメインを変えるならこのプランが、ドメインが番号を付け替えるのを必要としない注意。 ドメインは、彼らの個々のアドレス配分が広告を出される必要はないように、番号を付け替えます奨励される。
This plan will not affect the deployment of any specific long term plan, and therefore, this document will not discuss any long term plans for routing and address architectures.
このプランはどんな特定の長期プランの展開にも影響しないでしょう、そして、したがって、このドキュメントはルーティングとアドレス体系のためのどんな長期プランについても議論しないでしょう。
2. CIDR address allocation
2. CIDRアドレス配分
There are two basic components of this addressing and routing plan: one, to distribute the allocation of Internet address space and two, to provide a mechanism for the aggregation of routing information.
このアドレシングとルーティングプランの2つの基本的な成分があります: 1、インターネットの配分を広げるのはルーティング情報の集合にメカニズムを提供するためにスペースと2を記述します。
2.1 Aggregation and its limitations
2.1 集合とその制限
One major goal of this addressing plan is to allocate Internet address space in such a manner as to allow aggregation of routing
このアドレシングプランの1つの主要な目標はそのような方法でインターネット・アドレススペースをルーティングの集合を許容するほど割り当てることです。
Fuller, Li, Yu & Varadhan [Page 3] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[3ページ]RFC1519CIDRは1993年9月に戦略を記述します。
information along topological lines. For simple, single-homed clients, the allocation of their address space out of a transit routing domain's space will accomplish this automatically - rather than advertise a separate route for each such client, the transit domain may advertise a single aggregate route which describes all of the destinations connected to it. Unfortunately, not all sites are singly-connected to the network, so some loss of ability to aggregate is realized for the non-trivial cases.
位相的な線に沿った情報。 簡単である、シングル家へ帰る、クライアント、--トランジットからの彼らのアドレス空間の配分がスペースがこれほど自動的に達成するドメインのものを発送して、むしろ、トランジットドメインはそれぞれのそのようなクライアントのための別々のルートの広告を出すよりそれにつなげられた目的地のすべてについて説明するただ一つの集合ルートの広告を出すかもしれません。 残念ながら、すべてのサイトがどんな単独でネットワークに関連しているというわけではないので、集める能力のいくらかの損失が重要なケースに関して実感されます。
There are two situations that cause a loss of aggregation efficiency.
集合効率の損失をもたらす2つの状況があります。
o Organizations which are multi-homed. Because multi-homed
organizations must be advertised into the system by each of
their service providers, it is often not feasible to
aggregate their routing information into the address space
any one of those providers. Note that they still may receive
their address allocation out of a transit domain's address
space (which has other advantages), but their routing
information must still be explicitly advertised by most of
their service providers (the exception being that if the
site's allocation comes out of its least-preferable service
provider, then that service provider need not advertise the
explicit route - longest-match will insure that its
aggregated route is used to get to the site on a backup
basis). For this reason, the routing cost for these
organizations will typically be about the same as it is
today.
o そうする組織、マルチ、家へ帰り それぞれのそれらのサービスプロバイダーはシステムに組織の広告を出さなければならなくて、それらのルーティング情報に集めるのはしばしば可能であるというわけではありません。マルチ、家へ帰り、それらのプロバイダーのアドレス空間へのいずれも。 彼らがトランジットドメインのアドレス空間(他の利点を持っている)から自分達のアドレス配分をまだ受けているかもしれませんが、それらのサービスプロバイダーの大部分がまだ明らかにそれらのルーティング情報の広告を出さなければならないことに注意してください(サイトの配分が最も最少に望ましいサービスプロバイダーから出て来るなら、そのサービスプロバイダーは明白なルートの広告を出す必要はありません--最も長い間合ってくださいということである例外は、集められたルートがバックアップベースに関するサイトを始めるのに使用されるのを保障するでしょう)。 この理由で、これらの組織のためのルーティング費用は今日それと通常ほぼ同じくらいになるでしょう。
o Organizations which change service provider but do not
renumber. This has the effect of "punching a hole" in the
aggregation of the original service provider's advertisement.
This plan will handle the situation by requiring the newer
service provider to advertise a specific advertisement for
the new client, which is preferred by virtue of being the
longest match. To maintain efficiency of aggregation, it is
recommended that organizations which do change service
providers plan to eventually migrate their address
assignments from the old provider's space to that of the new
provider. To this end, it is recommended that mechanisms to
facilitate such migration, including improved protocols and
procedures for dynamic host address assignment, be developed.
o どれが、サービスプロバイダーを変えますが、するか。組織、番号を付け替えません。 これには、オリジナルのサービスプロバイダーの広告の集合における「穴を開けます」という効果があります。 より新しいサービスプロバイダーが最も長いマッチであることによって好まれる新しいクライアントのために特定の広告の広告を出すのを必要とすることによって、このプランは状況を扱うでしょう。 集合の効率を維持するために、結局、彼らの古いプロバイダーのスペースから新しいプロバイダーのものまでのアドレス課題が移動することがサービスプロバイダープランを変えるその組織に勧められます。 このために、ダイナミックなホスト・アドレス課題のための改良されたプロトコルと手順を含むそのような移動を容易にするメカニズムが開発されるのは、お勧めです。
Note that some aggregation efficiency gain can still be had for multi-homed sites (and, in general, for any site composed of multiple, logical IP network numbers) - by allocating a contiguous power-of-two block of network numbers to the client (as opposed to multiple, independent network numbers) the client's routing information may be aggregated into a single (net, mask) pair. Also,
まだ何らかの集合効率利得を持つことができることに注意してください、マルチ、家へ帰り、サイト(一般に、複数の、そして、論理的なIPで構成されたあらゆるサイトに数をネットワークでつなぐ)--クライアント(複数の、そして、独立しているネットワーク・ナンバーと対照的に)にネットワーク・ナンバーの隣接の2のパワーブロックを割り当てることによって、クライアントのルーティング情報は1(ネット、マスク)組に集められるかもしれません。 また
Fuller, Li, Yu & Varadhan [Page 4] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[4ページ]RFC1519CIDRは1993年9月に戦略を記述します。
since the routing cost associated with assigning a multi-homed site out of a service provider's address space is no greater than the current method of a random allocation by a central authority, it makes sense to allocate all address space out of blocks assigned to service providers.
aを割り当てると関連しているルーティング費用、マルチ、家へ帰り、サービスプロバイダーのアドレス空間からのサイトが主要な権威による無作為の配分の現在の、より方法以下である、それはサービスプロバイダーに配属されたブロックからすべてのアドレス空間を割り当てる感覚を作ります。
It is also worthwhile to mention that since aggregation may occur at multiple levels in the system, it may still be possible to aggregate these anomalous routes at higher levels of whatever hierarchy may be present. For example, if a site is multi-homed to two NSFNET regional networks both of whom obtain their address space from the NSFNET, then aggregation by the NSFNET of routes from the regionals will include all routes to the multi-homed site.
また、集合がシステムの複数のレベルで起こるかもしれないのでいかなる階層構造の、より高いレベルでもこれらの変則的なルートに集めるのが存在しているのが、まだ可能であるかもしれないと言及する価値があります。 サイトが例えばそうである、マルチ、家へ帰り、地域ネットワークのだれにNSFNETからそれらのアドレス空間を得てください、次に、地方版からのルートのNSFNETによる集合がすべてのルートを含むかに関する2つのNSFNET両方、マルチ、家へ帰り、サイト。
Finally, it should also be noted that deployment of the new addressing plan described in this document may (and should) begin almost immediately but effective use of the plan to aggregate routing information will require changes to some Inter-Domain routing protocols. Likewise, deploying classless Inter-Domain protocols without deployment of the new address plan will not allow useful aggregation to occur (in other words, the addressing plan and routing protocol changes are both required for supernetting, and its resulting reduction in table growth, to be effective.) Note, however, that during the period of time between deployment of the addressing plan and deployment of the new protocols, the size of routing tables may temporarily grow very rapidly. This must be considered when planning the deployment of the two plans.
また、最終的に、中のこのドキュメントが記述する説明されたプランを記述しますが、(and should)がほぼすぐに始まらせるルーティング情報に集める計画の有効な使用がそうする新しさの展開がいくつかのInter-ドメインルーティング・プロトコルへの変化を必要とすることに注意されるべきです。 同様に、新しいアドレスプランの展開なしで階級のないInter-ドメインプロトコルを配備するのに、役に立つ集合は起こらないでしょう(言い換えれば、アドレシングプランとルーティング・プロトコル変化は、スーパーネッティングに必要である両方と、テーブルの成長の有効になるためにはその結果として起こる減少です。)。 しかしながら、アドレシングプランの展開と新しいプロトコルの展開の間の期間の間経路指定テーブルのサイズが一時非常に急速に成長するかもしれないことに注意してください。 2つのプランの展開を計画しているとき、これを考えなければなりません。
Note: in the discussion and examples which follow, the network and mask notation is used to represent routing destinations. This is used for illustration only and does not require that routing protocols use this representation in their updates.
以下に注意してください。 従う議論と例では、ネットワークとマスク記法は、ルーティングの目的地を表すのに使用されます。 これは、イラストだけに使用されて、ルーティング・プロトコルが彼らのアップデートにおけるこの表現を使用するのを必要としません。
2.2 Distributed allocation of address space
2.2 アドレス空間の分配された配分
The basic idea of the plan is to allocate one or more blocks of Class C network numbers to each network service provider. Organizations using the network service provider for Internet connectivity are allocated bitmask-oriented subsets of the provider's address space as required.
プランの基本的な考え方は1ブロック以上のClass Cネットワーク・ナンバーをそれぞれのネットワークサービスプロバイダーに割り当てることです。 必要に応じてインターネットの接続性にネットワークサービスプロバイダーを使用する組織にプロバイダーのアドレス空間のビットマスク指向の部分集合を割り当てます。
It is also worthwhile to mention that once inter-domain protocols which support classless network destinations are widely deployed, the rules described by this plan generalize to permit arbitrary super/subnetting of the remaining class A and class B address space (the assumption being that classless inter-domain protocols will either allow for non-contiguous subnets to exist in the system or that all components of a sub-allocated class A/B will be contained
また、階級のないネットワークの目的地を支持する相互ドメインプロトコルがいったん広く配備されると、このプランによって説明された規則が残っているクラスAとクラスBアドレス空間の任意の最高の/サブネッティングを可能にするために広められると言及する価値がある、(階級のない相互ドメインプロトコルが、非隣接のサブネットがシステムに存在するのを許容するか、またはサブ割り当てられたクラスA/Bのすべてのコンポーネントが含まれるということである仮定
Fuller, Li, Yu & Varadhan [Page 5] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[5ページ]RFC1519CIDRは1993年9月に戦略を記述します。
within a single routing domain). This will allow this plan to continue to be used in the event that the class C space is exhausted before implementation of a long-term solution is deployed. This alternative is discussed further below in section 6.
中、ただ一つの経路ドメイン) 長期的な解決法の実現が配備される前にクラスCスペースが疲れ果てていると、これは使用され続けるこの計画を許すでしょう。 以下でセクション6でこの代替手段についてさらに議論します。
Hierarchical sub-allocation of addresses in this manner implies that clients with addresses allocated out of a given service provider are, for routing purposes, part of that service provider and will be routed via its infrastructure. This implies that routing information about multi-homed organizations, i.e., organizations connected to more than one network service provider, will still need to be known by higher levels in the hierarchy.
アドレスの階層的なサブ配分は、与えられたサービスプロバイダーからアドレスを割り当てているクライアントがルーティング目的のためのそのサービスプロバイダーの一部であり、インフラストラクチャで発送されるのをこの様に含意します。 これがそのルーティング情報を含意する、マルチ、家へ帰り、それでも、組織(すなわち、1つ以上のネットワークサービスプロバイダーに接続された組織)は、階層構造で、より高いレベルによって知られている必要があるでしょう。
The advantages of hierarchical assignment in this fashion are
階層的な課題の利点はこんなやり方でそうです。
a) It is expected to be easier for a relatively small number of
service providers to obtain addresses from the central
authority, rather than a much larger, and monotonically
increasing, number of individual clients. This is not to be
considered as a loss of part of the service providers' address
space.
a) 比較的少ない数のサービスプロバイダーがはるかに大きくて、単調に増加する数の個々のクライアントよりむしろ主要な権威からアドレスを得るのが、それが、より簡単であると予想されます。 サービスプロバイダーのアドレス空間の一部の損失であるとこれをみなしてはいけません。
b) Given the current growth of the Internet, a scalable and
delegatable method of future allocation of network numbers has
to be achieved.
b) インターネットの現在の成長を考えて、ネットワーク・ナンバーの今後の配分のスケーラブルで代表として派遣可能な方法は達成されなければなりません。
For these reasons, and in the interest of providing a consistent procedure for obtaining Internet addresses, it is recommended that most, if not all, network numbers be distributed through service providers. These issues are discussed in much greater length in [2].
これらの理由、インターネット・アドレスを得るための一貫した手順を提供することおよびのために、大部分、またはネットワーク・ナンバーがサービスプロバイダーを通して分配されるのは、お勧めです。 [2]のはるかに大きい長さでこれらの問題について議論します。
3. Cost-benefit analysis
3. 費用・便益分析
This new method of assigning address through service providers can be put into effect immediately and will, from the start, have the benefit of distributing the currently centralized process of assigning new addresses. Unfortunately, before the benefit of reducing the size of globally-known routing destinations can be achieved, it will be necessary to deploy an Inter-Domain routing protocol capable of handling arbitrary network and mask pairs. Only then will it be possible to aggregate individual class C networks into larger blocks represented by single routing table entries.
始めから、サービスプロバイダーを通してアドレスを割り当てるこの新しい方法は、すぐに、効果に入れることができて、新しいアドレスを割り当てる現在集結された過程を分配する利益を持つでしょう。 残念ながら、グローバルに知られているルーティングの目的地のサイズを減少させる利益を達成できる前に任意のネットワークとマスク組を扱うことができるInter-ドメインルーティング・プロトコルを配備するのが必要でしょう。 それはその時、単に単一の経路指定テーブルエントリーで表されたより大きいブロックへの個々のクラスCネットワークに集めるのにおいて可能になるでしょう。
This means that upon introduction, the new addressing allocation plan will not in and of itself help solve the routing table size problem. Once the new Inter-Domain routing protocol is deployed, however, an immediate drop in the number of destinations which clients of the new protocol must carry will occur. A detailed analysis of the magnitude
これは、序論のときに新しいアドレシング配分プランが、経路指定テーブルサイズ問題を解決するのをそういうものとして助けないことを意味します。 一度、新しいInter-ドメインルーティング・プロトコルは配備されて、しかしながら、新しいプロトコルのクライアントが運ばなければならない目的地の数の即座の低下は現れるでしょう。 大きさの詳細に渡る分析
Fuller, Li, Yu & Varadhan [Page 6] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[6ページ]RFC1519CIDRは1993年9月に戦略を記述します。
of this expected drop and the permanent reduction in rate of growth is given in the next section.
この予想された低下と永久的では、次のセクションで成長率の減少を与えます。
In should also be noted that the present method of flat address allocations imposes a large bureaucratic cost on the central address allocation authority. For scaling reasons unrelated to address space exhaustion or routing table overflow, this should be changed. Using the mechanism proposed in this paper will have the fortunate side effect of distributing the address allocation procedure, greatly reducing the load on the central authority.
また、コネは注意されるべきです。平坦なアドレス配分の現在の方法は主要なアドレス配分権威に大きい官僚の費用を課します。 アドレス空間疲労困憊に関係ないスケーリング理由か経路指定テーブルオーバーフローにおいて、これを変えるべきです。 この紙で提案されたメカニズムを使用するのにおいて、アドレス配分手順を分配する幸いな副作用があるでしょう、主要な権威で負荷を大いに減少させて。
3.1 Present Allocation Figures
3.1 現在の配分は計算されます。
An informal analysis of "network-contacts.txt" (available from the DDN NIC) indicates that as of 2/25/92, 46 of 126 class A network numbers have been allocated (leaving 81) and 5467 of 16382 class B numbers have been allocated, leaving 10915. Assuming that recent trends continue, the number of allocated class B's will continue to double approximately once a year. At this rate of growth, all class B's will be exhausted within about 15 months. As of 1/13/93, 52 class A network numbers have been allocated and 7133 class B's have been allocated. We suggest that the change in the class B allocation rate is due to the initial deployment of this address allocation plan.
「ネットワーク-contacts.txt」(DDN NICから利用可能な)の非公式の分析は2/25/92現在、46の126のクラスAネットワーク・ナンバーを割り当てて(81を残して)、5467の16382のクラスB番号を割り当てたのを示します、10915を残して。 最近の傾向が続くと仮定すると、割り当てられたクラスビーズの数は、1年におよそ一度倍増し続けるでしょう。 この成長率では、すべてのクラスビーズはおよそ15カ月以内に消耗するでしょう。 1/13/93現在、52のクラスAネットワーク・ナンバーを割り当てました、そして、7133年のクラスビーズを割り当てました。 私たちは、クラスB配分率における変化がこのアドレス配分プランの初期の展開のためであることを提案します。
Fuller, Li, Yu & Varadhan [Page 7] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[7ページ]RFC1519CIDRは1993年9月に戦略を記述します。
3.2 Historic growth rates
3.2 歴史的な成長率
MM/YY ROUTES MM/YY ROUTES
ADVERTISED ADVERTISED
------------------------ -----------------------
Dec-92 8561 Sep-90 1988
Nov-92 7854 Aug-90 1894
Oct-92 7354 Jul-90 1727
Sep-92 6640 Jun-90 1639
Aug-92 6385 May-90 1580
Jul-92 6031 Apr-90 1525
Jun-92 5739 Mar-90 1038
May-92 5515 Feb-90 997
Apr-92 5291 Jan-90 927
Mar-92 4976 Dec-89 897
Feb-92 4740 Nov-89 837
Jan-92 4526 Oct-89 809
Dec-91 4305 Sep-89 745
Nov-91 3751 Aug-89 650
Oct-91 3556 Jul-89 603
Sep-91 3389 Jun-89 564
Aug-91 3258 May-89 516
Jul-91 3086 Apr-89 467
Jun-91 2982 Mar-89 410
May-91 2763 Feb-89 384
Apr-91 2622 Jan-89 346
Mar-91 2501 Dec-88 334
Feb-91 2417 Nov-88 313
Jan-91 2338 Oct-88 291
Dec-90 2190 Sep-88 244
Nov-90 2125 Aug-88 217
Oct-90 2063 Jul-88 173
mm/YYは広告を出した状態で広告に掲載されたmm/YYルートを発送します。------------------------ ----------------------- 12月-92 8561 9月-90 1988 11月-92 7854 8月-90 1894 10月-92 7354 7月-90 1727 9月-92 6640 6月-90 1639 8月-92 6385 5月-90 1580 7月-92 6031 4月-90 1525 6月-92 5739 3月-90 1038 5月-92 5515 2月-90 997 4月-92 5291 1月-90 927 3月-92 4976 12月-89 897 2月-92 4740 11月-89 837 1月-92 4526 10月-89 809 12月-91 4305 9月-89 745 11月-91;
Table I : Growth in routing table size, total numbers
Source for the routing table size data is MERIT
テーブルI: 経路指定テーブルサイズにおける成長、経路指定テーブルサイズデータのための総数SourceはMERITです。
3.3 Detailed Analysis
3.3 詳細に渡る分析
There is a small technical cost and minimal administrative cost associated with deployment of the new address assignment plan. The administrative cost is basically that of convincing the NIC, the IANA, and the network service providers to agree to this plan, which is not expected to be too difficult. In addition, administrative cost for the central numbering authorities (the NIC and the IANA) will be greatly decreased by the deployment of this plan. To take advantage of aggregation of routing information, however, it is necessary that the capability to represent routes as arbitrary network and mask fields (as opposed to the current class A/B/C
新しいアドレス課題プランの展開に関連しているわずかな技術的な費用と最小量の管理費があります。 管理費は基本的にそれほど難しくないと予想されるこのプランに同意するようにNIC、IANA、およびネットワークサービスプロバイダーを説得するものです。 さらに、主要な付番当局(NICとIANA)のための管理費はこのプランの展開で大いに下がるでしょう。 現在のクラスA/B/Cと対照的にしかしながら、ルーティング情報の集合を利用するのに、任意であるとしてルートを表す能力が分野をネットワークでつないで、マスクをかけるのが必要である、(。
Fuller, Li, Yu & Varadhan [Page 8] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[8ページ]RFC1519CIDRは1993年9月に戦略を記述します。
distinction) be added to the common Internet inter-domain routing protocol(s). Thus, the technical cost is in the implementation of classless interdomain routing protocols.
区別) 一般的なインターネット相互ドメインルーティング・プロトコルに追加されてください。 したがって、技術的な費用は階級のないinterdomainルーティング・プロトコルの実現中です。
3.3.1 Benefits of the new addressing plan
3.3.1 新しいアドレシングプランの利益
There are two benefits to be had by deploying this plan:
このプランを配備することによって持つために、2つの利益があります:
o The current problem with depletion of the available class B
address space can be ameliorated by assigning more-
appropriately sized blocks of class C's to mid-sized
organizations (in the 200-4000 host range).
o 中型の組織(200-4000宿主域の)により多くの適切に大きさで分けられたクラスCを配属することによって、利用可能なクラスBアドレス空間の減少に関する現在の問題を改善できます。
o When the improved inter-domain routing protocol is deployed,
an immediate decrease in the number routing table entries
should occur, followed by a significant reduction in the rate
growth of routing table size (for default-free routers).
o 改良された相互ドメインルーティング・プロトコルが配備されるとき、数の経路指定テーブルエントリーの即座の減少は起こるべきです、経路指定テーブルサイズ(無デフォルトのルータのための)のレートの成長のかなりの減少があとに続いていて。
3.3.2 Growth rate projections
3.3.2 成長率映像
As of Jan '92, a default-free routing table (for example, the routing tables maintained by the routers in the NSFNET backbone) contained approximately 4700 entries. This number reflects the current size of the NSFNET routing database. Historic data shows that this number, on average, has doubled every 10 months between 1988 and 1991. Assuming that this growth rate is going to persist in the foreseeable future (and there is no reason to assume otherwise), we expect the number of entries in a default-free routing table to grow to approximately 30000 in two years time. In the following analysis, we assume that the growth of the Internet has been, and will continue to be, exponential.
1月の92年の時点で、無デフォルトの経路指定テーブル(例えばNSFNET背骨のルータによって維持された経路指定テーブル)はおよそ4700のエントリーを含みました。 この数はNSFNETルーティングデータベースの現在のサイズを反映します。 歴史的なデータは、この数が1988年と1991年の間に10カ月毎に平均的に倍増したのを示します。 この成長率がすぐに(別の方法で仮定する理由が全くない)持続すると仮定して、私たちは、無デフォルトの経路指定テーブルのエントリーの数が2年間の回におけるおよそ30000まで成長すると予想します。 以下の分析では、私たちは、インターネットの成長があったと思います、そして、意志は思い続けています。指数。
It should be stressed that these projections do not consider that the current shortage of class B network numbers may increase the number of instances where many class C's are used rather than a class B. Using an assumption that new organizations which formerly obtained class B's will now obtain somewhere between 4 and 16 class C's, the rate of routing table growth can conservatively be expected to at least double and probably quadruple. This means the number of entries in a default-free routing table may well exceed 10,000 entries within six months and 20,000 entries in less than a year.
これらの映像が、クラスBネットワーク・ナンバーの現在の不足が多くのクラスCがクラスB.よりむしろ使用される例の数を増加させるかもしれないと考えないと強調されるべきです。少なくとも倍にする保守的に以前クラスビーズを得た新しい組織が現在どこかで4〜16のクラスCを得るという仮定、経路指定テーブルの成長のレートを予想できるUsingとたぶん4倍。 これは、無デフォルトの経路指定テーブルのエントリーの数がここ1年以内でたぶん6カ月と2万のエントリーの中の1万のエントリーを超えているだろうことを意味します。
As of Dec '92, the routing table contains 8500 routes. The original growth curves would predict over 9400 routes. At this time, it is not clear if this would indicate a significant change in the rate of growth.
12月の92年現在、経路指定テーブルは8500のルートを含みます。 オリジナルの成長曲線は9400以上のルートを予測するでしょう。 このとき、これが成長率における著しい変化を示すかどうかは、明確ではありません。
Under the proposed plan, growth of the routing table in a default-
計画案、デフォルトにおける、経路指定テーブルの成長の下で
Fuller, Li, Yu & Varadhan [Page 9] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[9ページ]RFC1519CIDRは1993年9月に戦略を記述します。
free router is greatly reduced since most new address assignment will come from one of the large blocks allocated to the service providers. For the sake of this analysis, we assume prompt implementation of this proposal and deployment of the revised routing protocols. We make the initial assumption that any initial block given to a provider is sufficient to satisfy its needs for two years.
最も新しいアドレス課題がサービスプロバイダーに割り当てられた大量株の1つから来るので、自由なルータは大いに減少します。 この分析のために、私たちはこの提案の迅速な実現と改訂されたルーティング・プロトコルの展開を仮定します。 私たちはプロバイダーに与えられたどんな初期のブロックも2年間必要を満たすことができるくらいの初期の仮定をします。
Since under this plan, multi-homed networks must continue to be explicitly advertised throughout the system (according to Rule #1 described in section 4.2), the number multi-homed routes is expected to be the dominant factor in future growth of routing table size, once the supernetting plan is applied.
このプランの下でマルチ、家へ帰り、ネットワークは、システム(セクション4.2で説明されたRule#1、に従って)中に明らかに広告を出し続けなければなりません、数、マルチ、家へ帰り、ルートはテーブルのサイズを発送する今後の成長における支配的な要因であると予想されます、スーパーネッティングプランがいったん適用されていると。
Presently, it is estimated that there are fewer than 100 multi-homed organizations connected to the Internet. Each such organization's network is comprised of one or more network numbers. In many cases (and in all future cases under this plan), the network numbers used by an organization are consecutive, meaning that aggregation of those networks during route advertisement may be possible. This means that the number of routes advertised within the Internet for multi-homed networks may be approximated as the total number of multi-homed organizations. Assuming that the number of multi-homed organization will double every year (which may be a over-estimation, given that every connection costs money), the number of routes for multi-homed networks would be expected to grow to approximately 800 in three years.
現在100未満があると見積もられている、マルチ、家へ帰り、組織はインターネットに接続しました。 そのような各組織のネットワークは1つ以上のネットワーク・ナンバーから成ります。 多くの場合(そしてこのプランの下におけるすべての将来の場合で)、組織によって使用されたネットワーク・ナンバーは連続しています、ルート広告の間のそれらのネットワークの集合が可能であるかもしれないことを意味して。 ルートの数がインターネットの中に広告を出したこの手段、マルチ、家へ帰り、ネットワークが総数として近似されるかもしれない、マルチ、家へ帰り、組織。 それが数であると仮定する、マルチ、家へ帰り、組織が毎年(すべての接続が金がかかっているなら、過大評価であるかもしれない)、ルートの数を倍にするために望んでいる、マルチ、家へ帰り、ネットワークが3年後におよそ800まで成長すると予想されるでしょう。
If we further assume that there are approximately 100 service providers, then each service provider will also need to advertise its block of addresses. However, due to aggregation, these advertisements will be reduced to only 100 additional routes. We assume that after the initial two years, new service providers combined with additional requests from existing providers will require an additional 50 routes per year. Thus, the total is 4700 + 800 + 150 = 5650. This represents an annual growth rate of approximately 6%. This is in clear contrast to the current annual growth of 130%. This analysis also assumes an immediate deployment of this plan with full compliance. Note that this analysis assumes only a single level of route aggregation in the current Internet - intelligent address allocation should significantly improve this.
また、私たちが、およそ100のサービスプロバイダーがあるとさらに思うと、各サービスプロバイダーは、アドレスのブロックの広告を出す必要があるでしょう。 しかしながら、集合のため、これらの広告は100の追加ルートだけまで抑えられるでしょう。 私たちは、初期の2年の後に既存のプロバイダーからの追加要求に合併された新しいサービスプロバイダーが追加1年あたり50のルートを必要とすると思います。 したがって、合計は4700+800+150 = 5650です。 これはおよそ6%の年間成長率を表します。 これは130%の現在の年に一度の成長に対する明確な対照中です。 また、この分析は完全な承諾によるこのプランの即座の展開を仮定します。 この分析が現在のインターネットでただ一つのレベルのルート集合だけを仮定することに注意してください--知的なアドレス配分はこれをかなり改良するべきです。
Clearly, this is not a very conservative assumption in the Internet environment nor can 100% adoption of this proposal be expected. Still, with only a 90% participation in this proposal by service providers, at the end of the target three years, global routing table size will be "only" 4700 + 800 + 145 + 7500 = 13145 routes -- without any action, the routing table will grow to approximately 75000 routes during that time period.
明確に、これはインターネット環境で非常に保守的な仮定ではありません、そして、この提案の100%の採用は期待できません。 それでも、サービスプロバイダーによるこの提案への90%の参加だけで、3年間の目標の端では、グローバルな経路指定テーブルサイズは「単に」4700+800+145+7500 = 13145のルートになるでしょう--少しも動作がなければ、経路指定テーブルはその期間、およそ75000のルートまで成長するでしょう。
Fuller, Li, Yu & Varadhan [Page 10] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[10ページ]RFC1519CIDRは1993年9月に戦略を記述します。
4. Changes to inter-domain routing protocols and practices
4. 相互ドメインルーティング・プロトコルへの変化と習慣
In order to support supernetting efficiently, it is clear that some changes will need to be made to both routing protocols themselves and to the way in which routing information is interpreted. In the case of "new" inter-domain protocols, the actual protocol syntax changes should be relatively minor. This mechanism will not work with older inter-domain protocols such as EGP2; the only ways to interoperate with old systems using such protocols are either to use existing mechanisms for providing "default" routes or b) require that new routers talking to old routers "explode" supernet information into individual network numbers. Since the first of these is trivial while the latter is cumbersome (at best -- consider the memory requirements it imposes on the receiver of the exploded information), it is recommended that the first approach be used -- that older systems to continue to the mechanisms they currently employ for default handling.
効率的にスーパーネッティングを支持するために、どのルーティング情報が解釈されるかは、いくつかの変化が、両方のルーティング・プロトコル自体と、そして、入口に作られている必要であるのが明確です。 「新しい」相互ドメインプロトコルの場合では、実際のプロトコル構文変化は比較的小さい方であるべきです。 このメカニズムはEGP2などの、より古い相互ドメインプロトコルで動作しないでしょう。 古いシステムがそのようなプロトコルを使用していて共同利用する唯一の方法がルートかb)が必要とする「デフォルト」を提供するための新しいルータが古いルータと話して、supernet情報を個々のネットワーク・ナンバーに「爆発させる」既存のメカニズムを使用するどちらかです。 後者が厄介ですが(せいぜい、それが爆発している情報の受信機に課すメモリ要件を考えてください)、これらの第1が些細であるので、最初のアプローチが使用されるのは、お勧めです--それらが現在デフォルト取り扱いに使うメカニズムに続くそんなにより古いシステム。
Note that a basic assumption of this plan is that those organizations which need to import "supernet" information into their routing systems must run IGPs (such as OSPF [1]) which support classless routes. Systems running older IGPs may still advertise and receive "supernet" information, but they will not be able to propagate such information through their routing domains.
このプランの基本仮定が"supernet"情報をそれらのルーティングシステムに輸入する必要があるそれらの組織がIGPsを走らせなければならないということであることに注意してください。(階級のないルートを支えるOSPF[1])などのように。 システムの走行の、より古いIGPsはまだ"supernet"情報を広告を出して、受け取っているかもしれませんが、彼らは彼らの経路ドメインを通ってそのような情報を伝播できないでしょう。
4.1 Protocol-independent semantic changes
4.1 プロトコルから独立している意味変化
There are two fundamental changes which must be applied to Inter- Domain routing protocols in order for this plan to work. First, the concept of network "class" needs to be deprecated - this plan assumes that routing destinations are represented by network and mask pairs and that routing is done on a longest-match basis (i.e., for a given destination which matches multiple network+mask pairs, the match with the longest mask is used). Second, current inter-domain protocols generally do not support the concept of route aggregation, so the new semantics need to be implemented in a new set of inter-domain protocols. In particular, when doing aggregation, dealing with multi-homed sites or destinations which change service providers is difficult. Fortunately, it is possible to define several fairly simple rules for dealing with such cases.
働くこの計画において、整然としているInterドメインルーティング・プロトコルに適用しなければならない2回の根本的変化があります。 まず最初に、ネットワーク「クラス」の概念は、非難される必要があります--このプランはネットワークとマスク組がルーティングの目的地を表して、最も長いマッチベースでルーティングすると仮定します(すなわち、複数のネットワーク+マスク組に合っている与えられた目的地に関して、最も長いマスクとのマッチは使用されています)。 2番目に、現在の相互ドメインプロトコルが一般にルート集合の概念を支持しないので、新しい意味論は、新しいセットの相互ドメインプロトコルで実行される必要があります。 集合をするときの特に取扱う、マルチ、家へ帰り、サービスプロバイダーを変える遺跡か目的地が難しいです。 幸い、そのような場合に対処するためのいくつかのかなり簡単な規則を定義するのは可能です。
4.2. Rules for route advertisement
4.2. ルート広告のための規則
1. Routing to all destinations must be done on a longest-match
basis only. This implies that destinations which are multi-
homed relative to a routing domain must always be explicitly
announced into that routing domain - they cannot be summarized
(this makes intuitive sense - if a network is multi-homed, all
1. 最も長いマッチベースだけですべての目的地へのルート設定をしなければなりません。 ルーティングに比例して、いつも明らかにその経路ドメインにドメインを発表しなければなりません--それらをまとめることができません。これがそうするその目的地を含意する、マルチ、家へ帰り、(これは直感的な意味になります--、ネットワークがそうである、マルチ、家へ帰り、すべて。
Fuller, Li, Yu & Varadhan [Page 11] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[11ページ]RFC1519CIDRは1993年9月に戦略を記述します。
of its paths into a routing domain which is "higher" in the
hierarchy of networks must be known to the "higher" network).
「より高い」中では、「より高い」ネットワークにおいてネットワークの階層構造を知っていなければならないということである経路ドメインへの経路)
2. A routing domain which performs summarization of multiple
routes must discard packets which match the summarization but
do not match any of the explicit routes which makes up the
summarization. This is necessary to prevent routing loops in
the presence of less-specific information (such as a default
route). Implementation note - one simple way to implement
this rule would be for the border router to maintain a "sink"
route for each of its aggregations. By the rule of longest
match, this would cause all traffic destined to components of
the aggregation which are not explicitly known to be
discarded.
2. 複数のルートの総括を実行する経路ドメインは、総括に合っているパケットを捨てますが、明白なルートのどれかに合ってはいけません(総括を作ります)。 これが、より少ない特殊情報(デフォルトルートなどの)があるとき輪を発送するのを防ぐのに必要です。 実現注意--この規則を実行する1つの簡単な方法は境界ルータがそれぞれの集合のために「流し台」ルートを維持するだろうことです。 最も長いマッチの規則で、これは捨てられるのは明らかに知られない集合のコンポーネントに運命づけられたすべての交通を引き起こすでしょう。
Note that during failures, partial routing of traffic to a site which takes its address space from one service provider but which is actually reachable only through another (i.e., the case of a site which has change service providers) may occur because such traffic will be routed along the path advertised by the aggregated route. Rule #2 will prevent any real problem from occurring by forcing such traffic to be discarded by the advertiser of the aggregated route, but the output of "traceroute" and other similar tools will suggest that a problem exists within the service provider advertising the aggregate, which may be confusing to network operators (see the example in section 5.2 for details). Solutions to this problem appear to be challenging and not likely to be implementable by current Inter-Domain protocols within the time-frame suggested by this document. This decision may need to be revisited as Inter-Domain protocols evolve.
そのような交通が集められたルートで広告に掲載された経路に沿って発送されるので、失敗の間アドレス空間を取っていますが、実際に別のものだけを通して1つのサービスプロバイダーから届いているサイト(すなわち、変化サービスプロバイダーを持っているサイトに関するケース)への交通の部分的なルーティングが起こるかもしれないことに注意してください。 集められたルートの広告主はそのような交通を捨てさせられることによって、規則#2が、どんな実際の問題も起こるのを防ぐでしょうが、「トレースルート」と他の同様のツールの出力は、問題がネットワーク・オペレータに混乱させられているかもしれない集合の広告を出すサービスプロバイダーの中に存在するのを示すでしょう(詳細に関してセクション5.2の例を見てください)。 この問題の解決はやりがいがあってこのドキュメントによって示された時間枠の中の現在のInter-ドメインプロトコルで実行可能であることがありそうでないように見えます。 この決定は、Inter-ドメインプロトコルが発展するのに応じて再訪する必要があるかもしれません。
An implementation following these rules should also be generalized, so that an arbitrary network number and mask are accepted for all routing destinations. The only outstanding constraint is that the mask must be left contiguous. Note that the degenerate route 0.0.0.0 mask 0.0.0.0 is used as a default route and MUST be accepted by all implementations. Further, to protect against accidental advertisements of this route via the inter-domain protocol, this route should never be advertised unless there is specific configuration information indicating to do so.
また、これらの規則に従う実現は一般化されるべきです、任意のネットワーク・ナンバーとマスクをすべてのルーティングの目的地に受け入れるように。 唯一の傑出している規制は隣接でマスクを残さなければならないということです。 堕落が0.0.0.0マスクを発送することに注意してください、0.0、.0、.0、デフォルトルートとして使用されて、すべての実現で認めなければなりません。 さらに、相互ドメインプロトコルでこのルートの偶然の広告から守るために、そうするために示される特定の設定情報がない場合、決してこのルートの広告を出すべきではありません。
Systems which process route announcements must also be able to verify that information which they receive is correct. Thus, implementations of this plan which filter route advertisements must also allow masks in the filter elements. To simplify administration, it would be useful if filter elements automatically allowed more specific network numbers and masks to pass in filter elements given for a more general mask. Thus, filter elements which looked like:
また、ルート発表を処理するシステムは、彼らが受け取る情報が正しいことを確かめることができなければなりません。 したがって、またフィルタルート広告が許容しなければならないこのプランの実現はフィルタで要素にマスクをかけます。 管理を簡素化するために、より特定のネットワーク・ナンバーとマスクが、より一般的なマスクのために与えられたフィルタエレメントでフィルタエレメントで自動的に終わるなら、役に立つでしょうに。 したがって、似ていた要素をフィルターにかけてください:
Fuller, Li, Yu & Varadhan [Page 12] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[12ページ]RFC1519CIDRは1993年9月に戦略を記述します。
accept 128.32.0.0
accept 128.120.0.0
accept 134.139.0.0
deny 36.2.0.0
accept 36.0.0.0
128.32に、.0が128.120に受け入れる.0を受け入れてください、.0、.0が134.139に.0が36.2に、.0が36.0に受け入れる.0を否定する.0を受け入れる、.0、.0
would look something like:
何かに似ているでしょう:
accept 128.32.0.0 255.255.0.0
accept 128.120.0.0 255.255.0.0
accept 134.139.0.0 255.255.0.0
deny 36.2.0.0 255.255.0.0
accept 36.0.0.0 255.0.0.0
128.32.0.0 255.255 .0が受け入れる.0を受け入れてください、128.120.0.0 255.255 .0が受け入れる.0は36.0.0.0 255.0.0.0を受け入れます134.139.0.0 255.255.0.0が、36.2.0.0 255.255.0.0を否定する。
This is merely making explicit the network mask which was implied by the class A/B/C classification of network numbers.
これで、ネットワーク・ナンバーのクラスA/B/C分類で含意されたネットワークマスクは単に明白になっています。
4.3. How the rules work
4.3. 規則はどう利くか。
Rule #1 guarantees that the routing algorithm used is consistent across implementations and consistent with other routing protocols, such as OSPF. Multi-homed networks are always explicitly advertised by every service provider through which they are routed even if they are a specific subset of one service provider's aggregate (if they are not, they clearly must be explicitly advertised). It may seem as if the "primary" service provider could advertise the multi-homed site implicitly as part of its aggregate, but the assumption that longest-match routing is always done causes this not to work.
規則#1、は、使用されるルーティング・アルゴリズムが実現の向こう側に一致していて他のルーティング・プロトコルと一致しているのを保証します、OSPFなどのように。 マルチ、家へ帰り、ネットワークはいつもそれらが1つのサービスプロバイダーの集合の特定の部分集合(それらがそうでないなら、明確に明らかにそれらの広告を出さなければならない)であっても発送されるあらゆるサービスプロバイダーによって明らかに広告を出されます。 まるで「第一」のサービスプロバイダーが広告を出すことができるかのように見えるかもしれない、マルチ、家へ帰り、それとなく、しかし、集合、これがルーティングがいつも行われる最も長いマッチで働いていないという仮定の一部として、位置します。
Rule #2 guarantees that no routing loops form due to aggregation. Consider a mid-level network which has been allocated the 2048 class C networks starting with 192.24.0.0 (see the example in section 5 for more on this). The mid-level advertises to a "backbone" 192.24.0.0/255.248.0.0. Assume that the "backbone", in turn, has been allocated the block of networks 192.0.0.0/255.0.0.0. The backbone will then advertise this aggregate route to the mid-level. Now, if the mid-level loses internal connectivity to the network 192.24.1.0/255.255.255.0 (which is part of its aggregate), traffic from the "backbone" to the mid-level to destination 192.24.1.1 will follow the mid-level's advertised route. When that traffic gets to the mid-level, however, the mid-level *must not* follow the route 192.0.0.0/255.0.0.0 it learned from the backbone, since that would result in a routing loop. Rule #2 says that the mid-level may not follow a less-specific route for a destination which matches one of its own aggregated routes. Note that handling of the "default" route (0.0.0.0/0.0.0.0) is a special case of this rule - a network must not follow the default to destinations which are part of one of it's aggregated advertisements.
規則#2は、ルーティング輪が全く集合のため形成されないのを保証します。 192.24から始まって、2048年のクラスCネットワークに割り当てられた中間レベルのネットワークを考えてください。.0 .0 (これで以上でセクション5の例を見ます。) 中間レベルは「背骨」192.24.0.0/255.248.0に.0の広告を出します。 ネットワーク192.0.0.0/255.0.0のブロックが順番に.0に「背骨」に割り当てられたと仮定してください。 そして、背骨はこの集合ルートの中間レベルに広告を出すでしょう。 今、中間レベルがネットワーク192.24.1.0/255.255.255に内部の接続性を失うなら、目的地192.24.1への中間レベルへの「背骨」.1からの.0(集合の一部である)、交通は中間レベルが広告を出した尾行にルートを望んでいます。 しかしながら、交通が中間レベルを始めて、*ではなく、*が続かなければならない中間レベルがそれ以来それが背骨から学んだ.0が続くルート192.0.0.0/255.0.0に続くのがいつルーティング輪をもたらすか。 規則#2は、中間レベルがそれ自身のそれのマッチ1がルートに集められた目的地へのそれほど特定でないルートに従わないかもしれないと言います。 「デフォルト」ルートのその取り扱いに注意してください、(0.0、.0.0/、0.0 .0 .0は)この規則の特別なケースです--ネットワークはそれの1つの一部が広告に集められたということである目的地にデフォルトに従ってはいけません。
Fuller, Li, Yu & Varadhan [Page 13] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[13ページ]RFC1519CIDRは1993年9月に戦略を記述します。
4.4. Responsibility for and configuration of aggregation
4.4. 集合の責任と構成
The domain which has been allocated a range of addresses has the sole authority for aggregation of its address space. In the usual case, the AS will install manual configuration commands in its border routers to aggregate some portion of its address space. An domain can also delegate aggregation authority to another domain. In this case, aggregation is done in the other domain by one of its border routers.
さまざまなアドレスが割り当てられたドメインはアドレス空間の集合のための唯一の権威を持っています。 普通の場合では、ASは、アドレス空間の何らかの部分に集めるために手動の構成コマンドを境界ルータにインストールするでしょう。 また、ドメインは集合権威を別のドメインへ代表として派遣することができます。 この場合、もう片方のドメインで境界ルータの1つで集合をします。
When an inter-domain border router performs route aggregation, it needs to know the range of the block of IP addresses to be aggregated. The basic principle is that it should aggregate as much as possible but not to aggregate those routes which cannot be treated as part of a single unit due to multi-homing, policy, or other constraints.
相互ドメイン境界ルータがルート集合を実行するとき、それは、IPアドレスのブロックの範囲が集められるのを知る必要があります。 基本原理は集合で集めるのではなく、マルチホーミング、方針、または他の規制のため単一の単位の一部として扱うことができないそれらのルートをできるだけ集めるべきであるということです。
One mechanism is to do aggregation solely based on dynamically learned routing information. This has the danger of not specifying a precise enough range since when a route is not present, it is not always possible to distinguish whether it is temporarily unreachable or that it does not belong in the aggregate. Purely dynamic routing also does not allow the flexibility of defining what to aggregate within a range. The other mechanism is to do all aggregation based on ranges of blocks of IP addresses preconfigured in the router. It is recommended that preconfiguration be used, since it more flexible and allows precise specification of the range of destinations to aggregate.
1つのメカニズムは唯一ダイナミックに学習されたルーティング情報に基づく集合をすることです。 これには、それが一時手が届かないか否かに関係なく、区別するそれがルートが存在していないのがいつも可能であるというわけではない時以来の十分正確な範囲と、集合にはないと指定しないという危険があります。 純粋に、ダイナミックルーティングも範囲の中で何に集めるかを定義する柔軟性を許容しません。 もう片方のメカニズムはルータであらかじめ設定されたブロックのIPアドレスの範囲に基づくすべての集合をすることです。 前構成が、中古であって、それ以来、よりフレキシブルであり、目的地の範囲の正確な仕様が集められるのを許容するのは、お勧めです。
Preconfiguration does require some manually-maintained configuration information, but not excessively more so than what router administrators already maintain today. As an addition to the amount of information that must be typed in and maintained by a human, preconfiguration is just a line or two defining the range of the block of IP addresses to aggregate. In terms of gathering the information, if the advertising router is doing the aggregation, its administrator knows the information because the aggregation ranges are assigned to its domain. If the receiving domain has been granted the authority to and task of performing aggregation, the information would be known as part of the agreement to delegate aggregation. Given that it is common practice that a network administrator learns from its neighbor which routes it should be willing to accept, preconfiguration of aggregation information does not introduce additional administrative overhead.
Preconfigurationは何らかの手動で維持された設定情報を必要としますが、どんなルータより過度にそうであるどんな管理者も既に今日を維持しないか。 人間がタイプされて、維持しなければならない情報量への添加として、前構成は、ただ集めるためにIPアドレスのブロックの範囲を定義する1か2つの線です。 広告ルータが集合をしているなら情報を集めることに関して、集合範囲がドメインに割り当てられるので、管理者は情報を知っています。 受信ドメインに権威を与えて、集合を実行するタスク、情報が代表として派遣する、協定の一部として知られているだろう集合。 ネットワーク管理者が、隣人からどのルートを受け入れるかを構わないそれが、思うべきである学ぶのが、一般的な習慣であるなら、集合情報の前構成は追加管理オーバーヘッドを導入しません。
Implementation note: aggregates which encompass the class D address space (multicast addresses) are currently not well understood. At present, it appears that the optimal strategy is to consider
実現注意: クラスDアドレス空間(マルチキャストアドレス)を取り囲む集合が現在、よく理解されていません。 現在のところ、最適戦略が考えることであるように見えます。
Fuller, Li, Yu & Varadhan [Page 14] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[14ページ]RFC1519CIDRは1993年9月に戦略を記述します。
aggregates to never encompass class D space, even if they do so numerically.
それほど数の上で集めても、クラスDスペースを決して取り囲まないように集めます。
4.5 Intra-domain protocol considerations
4.5 イントラドメインプロトコル問題
While no changes need be made to internal routing protocols to support the advertisement of aggregated routing information between autonomous systems, it is often the case that external routing information is propagated within interior protocols for policy reasons or to aid in the propagation of information through a transit network. At the point when aggregated routing information starts to appear in the new exterior protocols, this practice of importing external information will have to be modified. A transit network which imports external information will have to do one of:
自律システムの間の集められたルーティング情報の広告を支持するのを変更を全く内部のルーティング・プロトコルにする必要はありませんが、しばしば、方針理由かトランジットネットワークを通した情報の伝播で支援するために内部のプロトコルの中で外部のルーティング情報を伝播します。 新しい外のプロトコルに現れるように情報始めを発送するポイントでは、集合であるなら外部の情報を輸入するこの習慣は変更されなければならないでしょう。 外部の情報がそれの輸入について1つをしなければならないトランジットネットワーク:
a) use an interior protocol which supports aggregated routing
a) 集められたルーティングを支持する内部のプロトコルを使用してください。
b) find some other method of propagating external information
which does not involve flooding it through the interior
protocol (i.e., by the use of internal BGP, for example).
b) 内部のプロトコル(例えばすなわち、内部のBGPの使用で)を通してそれをあふれさせることを伴わない外部の情報を伝播するある他の方法を見つけてください。
c) stop the importation of external information and flood a
"default" route through the internal protocol for discovery
of paths to external destinations.
c) 外部の情報の輸入を止めてください、そして、経路の発見のための内部のプロトコルを通して「デフォルト」ルートを外部の目的地へあふれさせてください。
For case (a), the modifications necessary to a routing protocol to allow it to support aggregated information may not be simple. For protocols such as OSPF and IS-IS, which represent routing information as either a destination+mask (OSPF) or as a prefix+prefix-length (IS-IS) changes to support aggregated information are conceptually fairly simple; for protocols which are dependent on the class-A/B/C nature of networks or which support only fixed-sized subnets, the changes are of a more fundamental nature. Even in the "conceptually simple" cases of OSPF and IS-IS, an implementation may need to be modified to support supernets in the database or in the forwarding table.
ケース(a)において、集められた情報を支持するのを許容するルーティング・プロトコルに必要な変更は簡単でないかもしれません。 そして、OSPFなどのプロトコル、-、どれが目的地+マスク(OSPF)として、または、接頭語接頭語+長さとしてルーティング情報を表すか、(-、)、集められた情報を支持する変化は概念的にかなり簡単です。 ネットワークのクラスA/B/C本質に依存しているか、または修理サイズのサブネットだけを支持するプロトコルのために、変化は、より基本的に自然です。 そして、OSPFの「概念的に簡単な」場合で同等である、-、実現は、データベースか推進テーブルで「スーパー-ネット」を支持するように変更される必要があるかもしれません。
5. Example of new allocation and routing
5. 新しい配分とルーティングに関する例
5.1 Address allocation
5.1 アドレス配分
Consider the block of 2048 class C network numbers beginning with 192.24.0.0 (0xC0180000 and ending with 192.31.255.0 (0xC01FFF00) allocated to a single network provider, "RA". A "supernetted" route to this block of network numbers would be described as 192.24.0.0 with mask of 255.248.0.0 (0xFFF80000).
.0が、192.24で.0を始める2048年のクラスCネットワーク・ナンバーのブロックであると考える、(0xC0180000と結末がネットワーク・ナンバーのこのブロックへの.0(0xC01FFF00)がただ一つのネットワーク内の提供者に割り当てた.255、"RA" Aが「「スーパー-網で覆」われた」という192.31ルートで192.24と説明されるだろう、.0、マスクがある.0、255.248 .0 .0 (0xFFF80000。)
Fuller, Li, Yu & Varadhan [Page 15] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[15ページ]RFC1519CIDRは1993年9月に戦略を記述します。
Assume this service provider connects six clients in the following order (significant because it demonstrates how temporary "holes" may form in the service provider's address space):
このサービスプロバイダーが以下のオーダー(一時的な「穴」がサービスプロバイダーのアドレス空間でどう形成されるかもしれないかを示すので重要な)における6人のクライアントに接すると仮定してください:
"C1" requiring fewer than 2048 addresses (8 class C networks)
「2048未満のアドレスを必要とするC1"」(8のクラスCネットワーク)
"C2" requiring fewer than 4096 addresses (16 class C networks)
「4096未満のアドレスを必要とするC2"」(16のクラスCネットワーク)
"C3" requiring fewer than 1024 addresses (4 class C networks)
「1024未満のアドレスを必要とするC3"」(4のクラスCネットワーク)
"C4" requiring fewer than 1024 addresses (4 class C networks)
「1024未満のアドレスを必要とするC4"」(4のクラスCネットワーク)
"C5" requiring fewer than 512 addresses (2 class C networks)
「512未満のアドレスを必要とするC5"」(2のクラスCネットワーク)
"C6" requiring fewer than 512 addresses (2 class C networks)
「512未満のアドレスを必要とするC6"」(2のクラスCネットワーク)
In all cases, the number of IP addresses "required" by each client is assumed to allow for significant growth. The service provider allocates its address space as follows:
すべての場合では、各クライアントによって「必要にされた」IPアドレスの数が重要な成長を考慮すると思われます。 サービスプロバイダーは以下のアドレス空間を割り当てます:
C1: allocate 192.24.0 through 192.24.7. This block of networks is
described by the "supernet" route 192.24.0.0 and mask
255.255.248.0
C1: .0〜192.24に.7に192.24を割り当ててください。 ネットワークのこのブロックは"supernet"ルート192.24の.0の.0とマスク255.255.248.0によって説明されます。
C2: allocate 192.24.16 through 192.24.31. This block is described
by the route 192.24.16.0, mask 255.255.240.0
C2: .16〜192.24に.31に192.24を割り当ててください。 このブロックがルート192.24.16によって説明される、.0、マスク255.255.240、.0
C3: allocate 192.24.8 through 192.24.11. This block is described
by the route 192.24.8.0, mask 255.255.252.0
C3: .8〜192.24に.11に192.24を割り当ててください。 このブロックがルート192.24.8によって説明される、.0、マスク255.255.252、.0
C4: allocate 192.24.12 through 192.24.15. This block is described
by the route 192.24.12.0, mask 255.255.252.0
C4: .12〜192.24に.15に192.24を割り当ててください。 このブロックがルート192.24.12によって説明される、.0、マスク255.255.252、.0
C5: allocate 192.24.32 and 192.24.33. This block is described by
the route 192.24.32.0, mask 255.255.254.0
C5: 192.24に.33に.32と192.24を割り当ててください。 このブロックがルート192.24.32によって説明される、.0、マスク255.255.254、.0
C6: allocate 192.24.34 and 192.24.35. This block is described by
the route 192.24.34.0, mask 255.255.254.0
C6: 192.24に.35に.34と192.24を割り当ててください。 このブロックがルート192.24.34によって説明される、.0、マスク255.255.254、.0
Note that if the network provider uses an IGP which can support classless networks, he can (but doesn't have to) perform "supernetting" at the point where he connects to his clients and therefore only maintain six distinct routes for the 36 class C network numbers. If not, explicit routes to all 36 class C networks will have to be carried by the IGP.
ネットワーク内の提供者が階級のないネットワークをサポートできるIGPを使用するなら、彼が彼がクライアントに接するポイントで「スーパーネッティング」を実行して(しかし、そうする必要はありません)、したがって、36のクラスCネットワーク・ナンバーのために6つの異なったルートしか維持できないことに注意してください。 そうでなければ、すべての36のクラスCネットワークへの明白なルートはIGPによって運ばれなければならないでしょう。
To make this example more realistic, assume that C4 and C5 are multi-homed through some other service provider, "RB". Further assume
この例をより現実的にするように、C4とC5がそうであると仮定してください、マルチ、家へ帰り、ある他のサービスプロバイダー、"RB"を通して。 さらに、仮定します。
Fuller, Li, Yu & Varadhan [Page 16] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[16ページ]RFC1519CIDRは1993年9月に戦略を記述します。
the existence of a client "C7" which was originally connected to "RB" but has moved to "RA". For this reason, it has a block of network numbers which are allocated out "RB"'s block of (the next) 2048 class C network numbers:
クライアントの存在「元々、"RB"に接続されましたが、"RA"に動いたC7"。」 この理由で、それには、出かけている"RB"の(次)2048のクラスCネットワーク・ナンバーのブロックが割り当てられる1ブロックのネットワーク・ナンバーがあります:
C7: allocate 192.32.0 through 192.32.15. This block is described
by the route 192.32.0, mask 255.255.240.0
C7: .0〜192.32に.15に192.32を割り当ててください。 このブロックがルート192.32.0、マスク255.255.240によって説明される、.0
For the multi-homed clients, we will assume that C4 is advertised as primary via "RA" and secondary via "RB"; C5 is primary via "RB" and secondary via "RA". To connect this mess together, we will assume that "RA" and "RB" are connected via some common "backbone" provider "BB".
マルチ、家へ帰り、クライアント、私たちはC4が"RA"を通した第一と"RB"を通した二次として広告を出すと思うつもりです。 C5は"RB"を通して第一であって"RA"を通して二次です。 この混乱を一緒に接続するために、私たちは、"RA"と"RB"がいくつかの一般的な「背骨」プロバイダー「掲示板」を通して接続されると思うつもりです。
Graphically, this simple topology looks something like this:
グラフィカルに、この簡単なトポロジーはこのように見えます:
C1
192.24.0.0 -- 192.24.7.0 \ _ 192.32.0.0 - 192.32.15.0
192.24.0.0/255.255.248.0 \ / 192.32.0.0/255.255.240.0
\ / C7
C2 +----+ +----+
192.24.16.0 - 192.24.31.0 \| | | |
192.24.16.0/255.255.240.0 | | _ 192.24.12.0 - 192.24.15.0 _ | |
| | / 192.24.12.0/255.255.252.0 \ | |
C3 -| |/ C4 \| |
192.24.8.0 - 192.24.11.0 | RA | | RB |
192.24.8.0/255.255.252.0 | |___ 192.24.32.0 - 192.24.33.0 ___| |
/| | 192.24.32.0/255.255.254.0 | |
C6 | | C5 | |
192.24.34.0 - 192.24.35.0 | | | |
192.24.34.0/255.255.254.0 | | | |
+----+ +----+
\\ \\
192.24.12.0/255.255.252.0 (C4) || 192.24.12.0/255.255.252.0 (C4) ||
192.32.0.0/255.255.240.0 (C7) || 192.24.32.0/255.255.254.0 (C5) ||
192.24.0.0/255.248.0.0 (RA) || 192.32.0.0/255.248.0.0 (RB) ||
|| ||
VV VV
+--------------- BACKBONE PEER BB ---------------+
C1 192.24.0.0 -- 192.24.7.0 \ _ 192.32.0.0 - 192.32.15.0 192.24.0.0/255.255.248.0 \ / 192.32.0.0/255.255.240.0 \ / C7 C2 +----+ +----+ 192.24.16.0 - 192.24.31.0 \| | | | 192.24.16.0/255.255.240.0 | | _ 192.24.12.0 - 192.24.15.0 _ | | | | / 192.24.12.0/255.255.252.0 \ | | C3、-| |/C4\| | 192.24.8.0 - 192.24.11.0 | RA| | RB| 192.24.8.0/255.255.252.0 | |___ 192.24.32.0 - 192.24.33.0 ___| | /| | 192.24.32.0/255.255.254.0 | | C6| | C5| | 192.24.34.0 - 192.24.35.0 | | | | 192.24.34.0/255.255.254.0 | | | | +----+ +----+ 192.24.12.0/255.255.252円の.0円の\\(C4)|| 192.24.12.0/255.255.252.0(C4)|| 192.32.0.0/255.255.240.0(C7)|| 192.24.32.0/255.255.254.0(C5)|| 192.24.0.0/255.248.0.0(RA)|| 192.32.0.0/255.248.0.0(RB)|| || || VV VV+--------------- 背骨同輩掲示板---------------+
5.2 Routing advertisements
5.2 ルート設定広告
To follow rule #1, RA will need to advertise the block of addresses that it was given and C7. Since C4 is multi-homed and primary through RA, it must also be advertised. C5 is multi-homed and primary through RB. It need not be advertised since longest match by BB will automatically select RB as primary and the advertisement of
規則#1に続くように、RAは、それが与えられたアドレスとC7のブロックの広告を出す必要があるでしょう。 そして、以来C4がそうである、マルチ、家へ帰り、RAを通して第一であり、また、それの広告を出さなければなりません。 C5がそうである、マルチ、家へ帰り、そして、RBを通して第一です。 最も長いマッチ以来意志が自動的に第一の同じくらいRBと広告を選択する掲示板はそれの広告を出す必要はありません。
Fuller, Li, Yu & Varadhan [Page 17] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[17ページ]RFC1519CIDRは1993年9月に戦略を記述します。
RA's aggregate will be used as a secondary.
RAの集合は2番目として使用されるでしょう。
Advertisements from "RA" to "BB" will be:
"RA"から「掲示板」までの広告は以下の通りになるでしょう。
192.24.12.0/255.255.252.0 primary (advertises C4)
192.32.0.0/255.255.240.0 primary (advertises C7)
192.24.0.0/255.248.0.0 primary (advertises remainder of RA)
192.24.12.0/255.255.252.0第一の(C4の広告を出します)192.32.0.0/255.255.240.0予備選挙(C7の広告を出す)192.24.0.0/255.248.0.0予備選挙(RAの残りの広告を出します)
For RB, the advertisements must also include C4 and C5 as well as it's block of addresses. Further, RB may advertise that C7 is unreachable.
また、RBに関しては、広告はC4とC5をそれがアドレスのブロックであるのと同じくらいよく含まなければなりません。 さらに、RBは、C7が手が届かないのは広告を出すかもしれません。
Advertisements from "RB" to "BB" will be:
"RB"から「掲示板」までの広告は以下の通りになるでしょう。
192.24.12.0/255.255.252.0 secondary (advertises C4)
192.24.32.0/255.255.254.0 primary (advertises C5)
192.32.0.0/255.248.0.0 primary (advertises remainder of RB)
192.24.12.0/255.255.252.0二次(C4の広告を出します)192.24.32.0/255.255.254.0予備選挙(C5の広告を出す)192.32.0.0/255.248.0.0予備選挙(RBの残りの広告を出します)
To illustrate the problem alluded to by the "note" in section 4.2, consider what happens if RA loses connectivity to C7 (the client which is allocated out of RB's space). In a stateful protocol, RA will announce to BB that 192.32.0.0/255.255.240.0 has become unreachable. Now, when BB flushes this information out of its routing table, any future traffic sent through it for this destination will be forwarded to RB (where it will be dropped according to Rule #2) by virtue of RB's less specific match 192.32.0.0/255.248.0.0. While this does not cause an operational problem (C7 is unreachable in any case), it does create some extra traffic across "BB" (and may also prove confusing to a network manager debugging the outage with "traceroute"). A mechanism to cache such unreachability information would help here, but is beyond the scope of this document (such a mechanism is also not implementable in the near-term).
「注意」によってセクション4.2で暗示された問題を例証するには、RAがC7(RBのスペースから割り当てられるクライアント)に接続性を失うなら何が起こるか考えてください。 statefulプロトコルで、RAはその192.32.0.0/255.255.240を掲示板に発表するでしょう。.0 手が届かなくなりました。 現在、掲示板が経路指定テーブルからこの情報を洗い流すと、RBのそれほど特定でないマッチ192.32.0.0/255.248.0によって.0にRB(Rule#2に応じてそれが落とされるところ)にそれを通してこの目的地に送られたどんな将来の交通も送るでしょう。 これは運転上の問題を引き起こしませんが(どのような場合でも、C7は手が届きません)、それは「掲示板」(そして、また、「トレースルート」でネットワークマネージャデバッグに混乱させるのが、供給停止であると立証するかもしれない)の向こう側に何らかの余分な交通を引き起こします。 そのような「非-可到達性」情報をキャッシュするメカニズムは、ここで助けるでしょうが、このドキュメントの範囲を超えています(また、そのようなメカニズムも短期間実行可能ではありません)。
6. Extending CIDR to class A addresses
6. クラスAアドレスにCIDRを広げています。
At some point, it is expected that this plan will eventually consume all of the remaining class C address space. As of this writing, the upper half of the class A address space has already been reserved for future expansion. This section describes how the CIDR plan can be used to utilize this portion of the class A space efficiently. It is expected that this contingency would only be used if no long term solution has become apparent by the time that the class C address space is consumed.
何らかのポイントでは、このプランが結局残っているクラスCアドレス空間のすべてを消費すると予想されます。 この書くこと現在、クラスAアドレス空間の上半分は今後の拡大のために既に予約されました。 このセクションは効率的にクラスAスペースのこの部分を利用するのにどうCIDRプランを使用できるかを説明します。 クラスCアドレス空間が消費される時までに長期解決策が全く明らかになっていない場合にだけこの偶然性が使用されると予想されます。
Fundamentally, there are two differences between using a class A address and a block of class C's. First, the configuration of DNS becomes somewhat more complicated than it is without the aggregation of class A subnets. The second difference is that the routers within
基本的に、クラスAアドレスとクラスCのブロックを使用するとき、2つの違いがあります。 まず最初に、DNSの構成はそれよりクラスAサブネットの集合なしでいくらか複雑になります。 2番目の違い、それは中のルータです。
Fuller, Li, Yu & Varadhan [Page 18] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[18ページ]RFC1519CIDRは1993年9月に戦略を記述します。
the class A address would need to support and use a classless IGP.
クラスAアドレスは、階級のないIGPを支持して、使用する必要があるでしょう。
Maintenance of DNS with a subnetted class A is somewhat painful. As part of the mechanism for providing reverse address lookups, DNS maintains a "IN-ADDR.ARPA" reverse domain. This is configured by reversing the dotted decimal network number, appending "IN-ADDR.ARPA" and using this as a type of pseudo-domain. Individual hosts then end up pointing back to a host name. Thus, for example, 131.108.1.111 has a DNS record "111.1.108.131.IN-ADDR.ARPA." Since the pseudo- domains can only be delegated on a byte boundary, this becomes painful if a stub domain receives a block of address space that does not fall on a byte boundary. The solution in this case is to enumerate all of the possible byte combinations involved. This is painful, but workable. This is discussed further below.
「副-網で覆」われたクラスAがあるDNSのメインテナンスはいくらか苦痛です。 逆のアドレスルックアップを提供するためのメカニズムの一部として、DNSは「ADDR.ARPA」の逆のドメインを維持します。 「ADDR.ARPA」を追加して、一種の疑似ドメインとしてこれを使用して、これは、ドット付き10進法ネットワーク・ナンバーを逆にすることによって、構成されます。 そして、個々のホストは結局、ホスト名を示します。 このようにして、そして、例えば、131.108 .1 .111 DNSに"111.1.108.131.IN-ADDR.ARPA"を記録させます。 バイト境界で疑似ドメインを代表として派遣することができるだけであるので、スタッブドメインがバイト境界の責任とならない1ブロックのアドレス空間を受けるなら、これは苦痛になります。 この場合、ソリューションは優に組み合わせがかかわった可能なバイトを列挙することです。 これは、苦痛ですが、実行可能です。 以下でさらにこれについて議論します。
Routing within a class A used for CIDR is also an interesting challenge. The usual case will be that a domain will be assigned a portion of the class A address space. The domain can either use an IGP which allows variable length subnets or it can pick a single subnet mask to be used throughout the domain. In the latter case, difficulties arise because other domains have been allocated other parts of the class A address space and may be using a different subnet mask. If the domain is itself a transit, it may also need to allocate some portion of its space to a client, which might also use a different subnet mask. The client would then need routing information about the remainder of the class A.
また、CIDRに使用されるクラスAの中のルート設定はおもしろい挑戦です。 普通のケースはクラスAアドレス空間の部分がドメインに割り当てられるということでしょう。 ドメインが可変長サブネットを許容するIGPを使用できますか、またはそれは、ドメイン中で使用されるために単一のサブネットマスクを選ぶことができます。 後者の場合では、他のドメインがクラスAアドレス空間の他の部品を割り当てて、異なったサブネットマスクを使用しているかもしれないので、困難は起こります。 また、ドメインがそれ自体でトランジットであるなら、それは、スペースの何らかの部分をクライアントに割り当てる必要があるかもしれません。(また、そのクライアントは、異なったサブネットマスクを使用するかもしれません)。 そして、クライアントは、クラスAの残りの情報を発送する必要があるでしょう。
If the client's IGP does not support variable length subnet masks, this could be done by advertising the remainder of the class A's address space in appropriately sized subnets. However, unless the client has a very large portion of the class A space, this is likely to result in a large number of subnets (for example, a mask of 255.255.255.0 would require a total of 65535 subnets, including those allocated to the client). For this reason, it may be preferable to simply use an IGP that supports variable length subnet masks within the client's domain.
クライアントのIGPが、可変長がサブネットマスクであるとサポートしないなら、適切に大きさで分けられたサブネットにおける、クラスAのアドレス空間の残りの広告を出すことによって、これをするかもしれません。 しかしながら、クライアントにクラスAスペースの非常に大きい部分がない場合、これが多くのサブネットをもたらしそうである、(例えば、255.255のマスク、.255、合計65535サブネットを必要として、それらを含んでいるとクライアントに割り当てられた.0) この理由で、単にクライアントのドメインの中で可変長がサブネットマスクであるとサポートするIGPを使用するのは望ましいかもしれません。
Similarly, if a transit has been assigned address space from a class A network number, it is likely that it was not assigned the entire class A, and that other transit domains will get address space from this class A. In this case, the transit would also have to inject routing information about the remainder of the class A into it's IGP. This is analogous to the situation above, with the same complications. For this reason, we recommend that the use of a class A for CIDR only be attempted if IGP's with variable length subnet mask support be used throughout the class A. Note that the IGP's need not support supernetting, as discussed above.
同様に、それはトランジットがクラスAネットワーク・ナンバーからの割り当てられたアドレススペースであるなら、クラス全員Aに配属されそうにはありませんでした、そして、他のトランジットドメインがこのクラスA.In本件からアドレス空間を得て、また、トランジットがクラスAの残りのルーティング情報をそれに注入しなければならないのは、IGPです。 これは同じ複雑さによる上の状況に類似しています。 この理由で、可変長サブネットマスクサポートがIGPのものがスーパーネッティングをサポートする必要はないクラスA.Note中で使用されている状態でIGPがあるなら、私たちは、クラスAのCIDRの使用が試みられるだけであることを勧めます、上で議論するように。
Fuller, Li, Yu & Varadhan [Page 19] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[19ページ]RFC1519CIDRは、戦略9月が1993であると扱います。
Note that the technique here could also apply to class B addresses. However, the limited number of available class B addresses and their usage for multihomed networks suggests that this address space should only be reserved for those large single organizations that warrant this type of address. [2]
また、クラスBアドレスにここのテクニックは適用できたことに注意してください。 しかしながら、利用可能なクラスBアドレスの限られた数と「マルチ-家へ帰」っているネットワークのためのそれらの用法は、このアドレス空間がこのタイプのアドレスを保証するそれらの大きい単純組織のために予約されるだけであるべきであると示唆します。 [2]
7. Domain Service considerations
7. ドメインService問題
One aspect of Internet services which will be notably affected by a move to either "supernetted" class-C network numbers or subdivided class-A's will be the mechanism used for address-to-name translation: the IN-ADDR.ARPA zone of the domain system. Because this zone is delegated on octet boundaries only, any address allocation plan which uses bitmask-oriented addressing will cause some degree of difficulty for those which maintain parts of the IN-ADDR.ARPA zone.
どちらかへの移動で著しく影響を受けるインターネットのサービスの1つの局面が、クラスCネットワーク・ナンバーが"「スーパー-網で覆」い"である、または命名するアドレスに使用されるメカニズムが翻訳であるつもりであったならクラスAのものを細分しました: ドメインシステムのIN-ADDR.ARPAゾーン。 八重奏境界だけでこのゾーンを代表として派遣するので、ビットマスク指向のアドレシングを使用するどんなアドレス配分プランもIN-ADDR.ARPAゾーンの部分を維持するもののために何らかの難易度を引き起こすでしょう。
7.1 Procedural changes for class-C "supernets"
7.1 クラスC"「スーパー-ネット」"のための手続き上の変化
At the present time, parts of the IN-ADDR.ARPA zone are delegated only on network boundaries which happen to fall on octet boundaries. To aid in the use of blocks of class-C networks, it is recommended that this policy be relaxed and allow the delegation of arbitrary, octet-oriented pieces of the IN-ADDR.ARPA zone.
現在では、たまたま八重奏境界に落ちるネットワーク限界だけでIN-ADDR.ARPAゾーンの部分を代表として派遣します。 ブロックのクラスCネットワークの使用で支援するために、この方針がリラックスして、IN-ADDR.ARPAゾーンの任意の、そして、八重奏指向の片の委譲を許容するのは、お勧めです。
As an example of this policy change, consider a hypothetical large network provider named "BigNet" which has been allocated the 1024 class-C networks 199.0.0 through 199.3.255. Under current policies, the root domain servers would need to have 1024 entries of the form:
この政策変更に関する例と、1024年のクラスCネットワークに割り当てられた"BigNet"という仮定している大きいネットワーク内の提供者を考えてください、199.0、.0、通じて、199.3、.255 通貨政策の下では、根のドメインサーバは形式の1024のエントリーを必要とするでしょう:
0.0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
ADDR.ARPAの0.0.199.。 ナノ秒NS1.BIG.NETで。
1.0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
ADDR.ARPAの1.0.199.。 ナノ秒NS1.BIG.NETで。
....
....
255.3.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
ADDR.ARPAの255.3.199.。 ナノ秒NS1.BIG.NETで。
By revising the policy as described above, this is reduced only four delegation records:
これによる減少して、4委譲だけが以下を記録するという上で説明されるように方針を改訂するのによる、ことです。
0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
ADDR.ARPAの0.199.。 ナノ秒NS1.BIG.NETで。
1.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
ADDR.ARPAの1.199.。 ナノ秒NS1.BIG.NETで。
2.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
ADDR.ARPAの2.199.。 ナノ秒NS1.BIG.NETで。
3.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
ADDR.ARPAの3.199.。 ナノ秒NS1.BIG.NETで。
Fuller, Li, Yu & Varadhan [Page 20] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[20ページ]RFC1519CIDRは、戦略9月が1993であると扱います。
The provider would then maintain further delegations of naming authority for each individual class-C network which it assigns, rather than having each registered separately. Note that due to the way the DNS is designed, it is still possible for the root nameservers to maintain the delegation information for individual networks for which the provider is unwilling or unable to do so. This should greatly reduce the load on the domain servers for the "top" levels of the IN-ADDR.ARPA domain. The example above illustrates only the records for a single nameserver. In the normal case, there are usually several nameservers for each domain, thus the size of the examples will double or triple in the common cases.
そして、プロバイダーはそれが割り当てるそれぞれの個々のクラスCネットワークのために別々にそれぞれを登録させるよりむしろ命名権威のさらなる委譲を維持するでしょう。 DNSが設計されている方法のために、根のネームサーバがプロバイダーが不本意であるか、またはそうすることができない個々のネットワークのための委譲情報を保守するのが、まだ可能であることに注意してください。 これはIN-ADDR.ARPAドメインの「最高」のレベルのためにドメインサーバで負荷を大いに減少させるべきです。 上記の例はただ一つのネームサーバのための記録だけを例証します。通常、正常な場合には、各ドメインへのいくつかのネームサーバがあって、その結果、例のサイズは、よくある例では、倍増するか、または3倍になるでしょう。
7.2 Procedural changes for class-A subnetting
7.2 クラスAサブネッティングのための手続き上の変化
Should it be the case the class-A network numbers are subdivided into blocks allocated to transit network providers, it will be similarly necessary to relax the restriction on how IN-ADDR.ARPA naming works for them. As an example, take a provider is allocated the 19-bit portion of address space which matches 10.8.0.0 with mask 255.248.0.0. This represents all addresses which begin with the prefixes 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, an 10.15 and requires the following IN-ADDR.ARPA delegations:
それがケースであるなら、クラスAネットワーク・ナンバーはトランジットネットワーク内の提供者に割り当てられたブロックに細分されて、IN-ADDR.ARPA命名はどうそれらに効き目があるかに関する規制を緩和するのが同様に必要でしょう。 例、19ビットの部分がプロバイダーに割り当てられる撮影、合っているアドレス空間、10.8、.0、.0、マスク、255.248、.0、.0 これは、接頭語10.8、10.9、10.10、10.11、10.12、10.13、10.14、10.15で始まるすべてのアドレスを表して、以下のIN-ADDR.ARPA委譲を必要とします:
8.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET.
ADDR.ARPAの8.10.。 ナノ秒NS1.MOBY.NETで。
9.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET.
ADDR.ARPAの9.10.。 ナノ秒NS1.MOBY.NETで。
....
....
15.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET.
ADDR.ARPAの15.10.。 ナノ秒NS1.MOBY.NETで。
To further illustrate how IN-ADDR.ARPA sub-delegation will work, consider a company named "FOO" connected to this provider which has been allocated the 14-bit piece of address space which matches 10.10.64.0 with mask 255.255.192.0. This represents all addresses in the range 10.10.64.0 through 10.10.127.255 and will require that the provider implement the following IN-ADDR.ARPA delegations:
さらにIN-ADDR.ARPA復委任がどう働くかを例証するために、合っている14ビットの片のアドレス空間が割り当てられたこのプロバイダーに関連づけられた"FOO"という会社を考えてください、10.10、.64、.0、マスク、255.255、.192、.0 これが範囲のすべてのアドレスを表す、10.10、.64、.0、10.10を通して、.127の.255と意志は、プロバイダーが以下のIN-ADDR.ARPA委譲を実装するのを必要とします:
64.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM.
ADDR.ARPAの64.10.10.。 ナノ秒NS1.FOO.COMで。
65.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM.
ADDR.ARPAの65.10.10.。 ナノ秒NS1.FOO.COMで。
....
....
127.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM.
ADDR.ARPAの127.10.10.。 ナノ秒NS1.FOO.COMで。
with the servers for "FOO.COM" containing the individual PTR records for all of the addresses on each of these subnets.
"FOO.COM"のためのサーバで、個々のPTRを含むのはアドレスのすべてのためにそれぞれのこれらのサブネットに記録します。
Fuller, Li, Yu & Varadhan [Page 21] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[21ページ]RFC1519CIDRは、戦略9月が1993であると扱います。
8. Transitioning to a long term solution
8. 長期ソリューションに移行します。
This solution does not change the Internet routing and addressing architectures. Hence, transitioning to a more long term solution is not affected by the deployment of this plan.
このソリューションはインターネット・ルーティングとアドレッシング体系を変えません。 したがって、より長い用語ソリューションに移行するのはこのプランの展開で影響を受けません。
9. Conclusions
9. 結論
We are all aware of the growth in routing complexity, and the rapid increase in allocation of network numbers. Given the rate at which this growth is being observed, we expect to run out in a few short years.
私たちは皆、ルーティングの複雑さにおける成長、およびネットワーク・ナンバーの配分の急速な増加を意識しています。 この成長が観測されているレートを考えて、私たちは、短い数年の後になくなると予想します。
If the inter-domain routing protocol supports carrying network routes with associated masks, all of the major concerns demonstrated in this paper would be eliminated.
相互ドメインルーティング・プロトコルが関連マスクでネットワークルートを携帯に支えるなら、この紙に示された主要な関心事のすべてが排除されるでしょう。
One of the influential factors which permits maximal exploitation of the advantages of this plan is the number of people who agree to use it.
このプランの利点の最大限度の攻略を可能にする有力な要因の1つはそれを使用するのに同意する人々の数です。
If service providers start charging networks for advertising network numbers, this would be a very great incentive to share the address space, and hence the associated costs of advertising routes to service providers.
サービスプロバイダーが広告ネットワーク・ナンバーのためにネットワークを請求し始めるなら、これはサービスプロバイダーとアドレス空間を共有して、したがって広告ルートの関連コストを共有する非常に大きい誘因でしょう。
10. Recommendations
10. 推薦
The NIC should begin to hand out large blocks of class C addresses to network service providers. Each block must fall on bit boundaries and should be large enough to serve the provider for two years. Further, the NIC should distribute very large blocks to continental and national network service organizations to allow additional levels of aggregation to take place at the major backbone networks. In addition, the NIC should modify its procedures for the IN-ADDR.ARPA domain to permit delegation along arbitrary octet boundaries.
NICは大量株のクラスCアドレスをネットワークサービスプロバイダーに与え始めるはずです。 それぞれのブロックは、ビット境界に落ちなければならなくて、2年間プロバイダーに役立つことができるくらい大きいはずです。 さらに、NICは、追加レベルの集合が主要なバックボーンネットワークで行われるのを許容するために自制的で国家のネットワーク・サービス組織に非常に大きいブロックを分配するはずです。 さらに、IN-ADDR.ARPAドメインが任意の八重奏境界に沿って委譲を可能にするように、NICは手順を変更するはずです。
Service providers will further allocate power-of-two blocks of class C addresses from their address space to their subscribers.
サービスプロバイダーはそれらのアドレス空間から彼らの加入者までさらにブロックのクラスCアドレスを2のパワーに割り当てるでしょう。
All organizations, including those which are multi-homed, should obtain address space from their provider (or one of their providers, in the case of the multi-homed). These blocks should also fall on bit boundaries to permit easy route aggregation.
そうするものを含むすべての組織、マルチ、家へ帰り、それらのプロバイダーからアドレス空間を得るべきである、(場合におけるそれらのプロバイダーの1つ、マルチ、家へ帰り、) また、これらのブロックは、簡単なルート集合を可能にするためにビット境界に落ちるはずです。
To allow effective use of this new addressing plan to reduce propagated routing information, appropriate IETF WGs will specify the modifications needed to Inter-Domain routing protocols.
減少するこの新しいアドレシング計画の有効な使用を許すのはルーティング情報を伝播して、適切なIETF WGsはInter-ドメインルーティング・プロトコルに必要である変更を指定するでしょう。
Fuller, Li, Yu & Varadhan [Page 22] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[22ページ]RFC1519CIDRは、戦略9月が1993であると扱います。
Implementation and deployment of these modifications should occur as quickly as possible.
これらの変更の実装と展開はできるだけ急速に起こるべきです。
11 References
11の参照箇所
[1] Moy, J, "The OSPF Specification Version 2", RFC 1247, Proteon,
Inc., January 1991.
[1]Moy、J、「OSPF仕様バージョン、2インチ、RFC1247、Proteon Inc.、1991インチ年1月。
[2] Rekhter, Y., and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, T.J. Watson Research Center, IBM
Corp., cisco Systems, September 1993.
[2]Rekhter、Y.、およびT.李、「CIDRとのIPアドレス配分のためのアーキテクチャ」、RFC1518、T.J.ワトソン研究所、IBM社、コクチマスSystems(1993年9月)。
12. Security Considerations
12. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Fuller, Li, Yu & Varadhan [Page 23] RFC 1519 CIDR Address Strategy September 1993
フラー、李、ユー、およびVaradhan[23ページ]RFC1519CIDRは、戦略9月が1993であると扱います。
13. Authors' Addresses
13. 作者のアドレス
Vince Fuller BARRNet Pine Hall 115 Stanford, CA, 94305-4122
ビンス・よりふくよかなBARRNet松のHall115スタンフォード、カリフォルニア、94305-4122
EMail: vaf@Stanford.EDU
メール: vaf@Stanford.EDU
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
Jessica (Jie Yun) Yu Merit Network, Inc. 1071 Beal Ave. Ann Arbor, MI 48109
ジェシカ(潔・ユン)ユー長所ネットワークInc.1071ビールAve。 アナーバー、MI 48109
EMail: jyy@merit.edu
メール: jyy@merit.edu
Kannan Varadhan Internet Engineer, OARnet 1224, Kinnear Road, Columbus, OH 43212
コロンブス、OH Kannan Varadhanインターネット技術者、OARnet1224、キネアRoad、43212
EMail: kannan@oar.net
メール: kannan@oar.net
Fuller, Li, Yu & Varadhan [Page 24]
フラー、李、ユー、およびVaradhan[24ページ]
一覧
スポンサーリンク
