Network Working Group V. Fuller
Request for Comments: 4632 Cisco Systems
BCP: 122 T. Li
Obsoletes: 1519 Tropos Networks
Category: Best Current Practice August 2006
Classless Inter-domain Routing (CIDR):
The Internet Address Assignment and Aggregation Plan
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described.
このメモは、アドレス空間を節約し、グローバルルーティング状態の成長速度を制限するに向かって眺めを既存の32ビットのIPv4アドレス空間のアドレス割り当てのための戦略を議論します。この文書では、両方のは、それが導入され、12年以上後に、記載された技術を導入した結果に、インターネットコミュニティを更新するための概念を明確にするために行われた変更で、RFC 1519で、元のクラスレスドメイン間ルーティング（CIDR）仕様を廃止します。
Table of Contents
目次
1. Introduction ....................................................3
2. History and Problem Description .................................3
3. Classless Addressing as a Solution ..............................4
3.1. Basic Concept and Prefix Notation ..........................5
4. Address Assignment and Routing Aggregation ......................8
4.1. Aggregation Efficiency and Limitations .....................8
4.2. Distributed Assignment of Address Space ...................10
5. Routing Implementation Considerations ..........................11
5.1. Rules for Route Advertisement .............................11
5.2. How the Rules Work ........................................12
5.3. A Note on Prefix Filter Formats ...........................13
5.4. Responsibility for and Configuration of Aggregation .......13
5.5. Route Propagation and Routing Protocol Considerations .....15
6. Example of New Address Assignments and Routing .................15
6.1. Address Delegation ........................................15
6.2. Routing Advertisements ....................................17
7. Domain Name Service Considerations .............................18
8. Transition to a Long-Term Solution .............................18
9. Analysis of CIDR's Effect on Global Routing State ..............19
10. Conclusions and Recommendations ...............................20
11. Status Updates to CIDR Documents ..............................21
12. Security Considerations .......................................23
13. Acknowledgements ..............................................24
14. References ....................................................25
14.1. Normative References .....................................25
14.2. Informative References ...................................25
This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original CIDR spec [RFC1519], with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described.
このメモは、アドレス空間を節約し、グローバルルーティング状態の成長速度を制限するに向かって眺めを既存の32ビットのIPv4アドレス空間のアドレス割り当てのための戦略を議論します。この文書では、両方のは、それが導入され、12年以上後に、記載された技術を導入した結果に、インターネットコミュニティを更新するための概念を明確にするために行われた変更で、オリジナルのCIDR仕様[RFC1519]を廃止します。
What is now known as the Internet started as a research project in the 1970s to design and develop a set of protocols that could be used with many different network technologies to provide a seamless, end-to-end facility for interconnecting a diverse set of end systems. When it was determined how the 32-bit address space would be used, certain assumptions were made about the number of organizations to be connected, the number of end systems per organization, and total number of end systems on the network. The end result was the establishment (see [RFC791]) of three classes of networks: Class A (most significant address bits '00'), with 128 possible networks each and 16777216 end systems (minus special bit values reserved for network/broadcast addresses); Class B (MSB '10'), with 16384 possible networks each with 65536 end systems (less reserved values); and Class C (MSB '110'), and 2097152 possible networks each and 254 end systems (256 bit combinations minus the reserved all-zeros and all-ones patterns). The set of addresses with MSB '111' was reserved for future use; parts of this were eventually defined (MSB '1110') for use with IPv4 multicast and parts are still reserved as of the writing of this document.
今何インターネットとして知られていることは終わりの多様なセットを相互接続するためのシームレスな、エンドツーエンドの機能を提供するために、多くの異なるネットワーク技術を使用することができプロトコルのセットを設計し、開発するために1970年代に研究プロジェクトとしてスタートしましたシステム。それは32ビットのアドレス空間が使用される方法を決定した場合、一定の仮定を接続する組織の数、組織当たりのエンドシステムの数、およびネットワーク上のエンドシステムの数について行われました。最終結果は、ネットワーク3つのクラスの確立（[RFC791]参照）であった：クラスA 128台の可能なネットワークそれぞれ16777216のエンドシステムとの（最上位アドレスビット「00」）、（マイナスネットワーク/ブロードキャストアドレス用に予約特別なビット値）; 16384の可能ネットワーク65536のエンドシステム（以下予約値）とのそれぞれにクラスB（MSB「10」）。およびクラスC（MSB「110」）、及び2097152の可能なネットワークそれぞれ254羽のエンドシステム（256ビットの組合せマイナス予約すべてゼロとすべてのものパターン）。 MSB「111」とアドレスのセットは、将来の使用のために予約されていました。このの部品結局のIPv4マルチキャストおよび部品で使用するために（MSB「1110」）定義されていたが、まだ、この文書の執筆のように予約されています。
In the late 1980s, the expansion and commercialization of the former research network resulted in the connection of many new organizations to the rapidly growing Internet, and each new organization required an address assignment according to the Class A/B/C addressing plan. As demand for new network numbers (particularly in the Class B space) took what appeared to be an exponential growth rate, some members of the operations and engineering community started to have concerns over the long-term scaling properties of the class A/B/C system and began thinking about how to modify network number assignment policy and routing protocols to accommodate the growth. In November, 1991, the Internet Engineering Task Force (IETF) created the ROAD (Routing and Addressing) group to examine the situation. This group met in January 1992 and identified three major problems:
1980年代後半には、かつての研究ネットワークの拡大と商品化が急速に成長しているインターネットに多くの新しい組織の接続が生じ、それぞれの新組織は、クラスA / B / Cのアドレッシング計画に従ってアドレスの割り当てを要求しました。 （特に、クラスB空間での）新しいネットワーク番号の需要は指数関数的な成長率のように見えるもの取ったとして、いくつかの操作のメンバーとエンジニアリングのコミュニティは、クラスA / B /の長期的なスケーリング性質の懸念を持っているし始めましたCシステムや成長に対応するために、ネットワーク番号の割り当てポリシーおよびルーティングプロトコルを変更する方法について考え始めました。 11月、1991年には、IETF（Internet Engineering Task Force）は、状況を調べるためにROAD（ルーティングとアドレッシング）グループを作成しました。このグループは、1992年1月に会って、三つの主要な問題を特定しました。
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 that is appropriate for mid-sized organization. Class C, with a maximum of 254 host addresses, is too small, whereas Class B, which allows up to 65534 host addresses, is too large for most organizations but was the best fit available for use with subnetting.
クラスBネットワークアドレス空間の枯渇1。この問題の1つの基本的な原因は、中規模組織に適しているサイズのネットワーククラスの欠如です。クラスCは、254のホストアドレスの最大で、65534のホストアドレスを最大ことができますほとんどの組織のためには大きすぎるが、サブネットで使用可能なベストフィットしたクラスB、一方、小さすぎます。
2. Growth of routing tables in Internet routers beyond the ability of current software, hardware, and people to effectively manage.
効果的に管理するために、現在のソフトウェア、ハードウェア、および人々の能力を超えたインターネットルータのルーティングテーブルの2の成長。
It was clear that then-current rates of Internet growth would
cause the first two problems to become critical sometime between
1993 and 1995. Work already in progress on topological
assignment of addressing for Connectionless Network Service
(CLNS), which was presented to the community at the Boulder IETF
in December of 1990, led to thoughts on how to re-structure the
32-bit IPv4 address space to increase its lifespan. Work in the
ROAD group followed and eventually resulted in the publication of
[RFC1338], and later, [RFC1519].
The design and deployment of CIDR was intended to solve these problems by providing a mechanism to slow the growth of global routing tables and to reduce the rate of consumption of IPv4 address space. It did not and does not attempt to solve the third problem, which is of a more long-term nature; instead, it 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.
CIDRの設計と展開は、グローバルルーティングテーブルの成長を遅くすると、IPv4アドレス空間の消費率を低減するためのメカニズムを提供することにより、これらの問題を解決することを意図していました。それはしませんでしたし、より長期的な性質のものである第三の問題点を解決しようとしません。その代わり、それは進歩は長期的なソリューションで行われている間、インターネットが効率的に機能し続けることができるように、中期的な困難に短期の十分を緩和しようと努力しています。
More historical background on this effort and on the ROAD group may be found in [RFC1380] and at [LWRD].
この努力に、道路のグループの詳細歴史的背景は、[RFC1380]及び[LWRD]で見つけることができます。
The solution that the community created was to deprecate the Class A/B/C network address assignment system in favor of using "classless", hierarchical blocks of IP addresses (referred to as prefixes). The assignment of prefixes is intended to roughly follow the underlying Internet topology so that aggregation can be used to facilitate scaling of the global routing system. One implication of this strategy is that prefix assignment and aggregation is generally done according to provider-subscriber relationships, since that is how the Internet topology is determined.
コミュニティが作成した溶液は、「クラスレス」使用を支持してIPアドレス（プレフィックスと呼ばれる）の階層ブロックを、クラスA / B / Cのネットワークアドレス割当システムを廃止することでした。プレフィックスの割り当ては、その凝集がグローバルルーティングシステムのスケーリングを容易にするために使用することができるように、概ね基礎をなすインターネットトポロジーに従うことを意図しています。この戦略の成果の一つは、それがインターネットトポロジを決定する方法であるため、プレフィックスの割り当てと凝集は、一般的に、プロバイダの加入者との関係に基づいて行われていることです。
When originally proposed in [RFC1338] and [RFC1519], this addressing plan was intended to be a relatively short-term response, lasting approximately three to five years, during which a more permanent addressing and routing architecture would be designed and implemented. As can be inferred from the dates on the original documents, CIDR has far outlasted its anticipated lifespan and has become the mid-term solution to the problems described above.
元々[RFC1338]と[RFC1519]で提案されている場合は、このアドレス指定の計画は、より恒久的なアドレッシングとルーティングアーキテクチャを設計・実装されるであろう中に約3〜5年を、持続的な、比較的短期的な応答であることを意図していました。元の文書の日付から推測できるとおり、CIDRは、はるかにその予想寿命を長持ちしており、上述した課題への中期的なソリューションとなっています。
Note that in the following text we describe the current policies and procedures that have been put in place to implement the allocation architecture discussed here. This description is not intended to be interpreted as direction to IANA.
次のテキストに、我々はここで説明割り当てアーキテクチャを実装するための場所に置かれている現在の方針と手順を説明していることに注意してください。この説明は、IANAの方向として解釈されるものではありません。
Coupled with address management strategies implemented by the Regional Internet Registries (see [NRO] for details), the deployment of CIDR-style addressing has also reduced the rate at which IPv4 address space has been consumed, thus providing short- to medium-term relief to problem #3, described above.
（詳細については[NRO]参照）地域インターネットレジストリによって実装アドレス管理戦略と相まって、CIDRスタイルアドレッシングの展開はまた、このように短期の、中期救済を提供し、IPv4アドレス空間が消費された速度が低下しています問題＃3に、前述しました。
Note that, as defined, this plan neither requires nor assumes the re-assignment of those parts of the legacy "Class C" space that are not amenable to aggregation (sometimes called "the swamp"). Doing so would somewhat reduce routing table sizes (current estimate is that "the swamp" contains approximately 15,000 entries), though at a significant renumbering cost. Similarly, there is no hard requirement that any end site renumber when changing transit service provider, but end sites are encouraged do so to eliminate the need for explicit advertisement of their prefixes into the global routing system.
定義されているように、この計画は（時には「沼」と呼ばれる）の集約に適していないレガシー「クラスC」のスペースの部分の再割り当てを必要としないも想定しているどちらも、あることに注意してください。ややしかし重要なリナンバリングのコストで、（現在の推定値は、「沼」は約15,000エントリが含まれていることである）、ルーティングテーブルのサイズを削減するそう。同様に、そこにトランジットサービスプロバイダを変更する際に任意のエンドサイトは、番号変更なしハード要件はありませんが、エンドサイトが奨励されているグローバルルーティングシステムにそのプレフィックスを明示的に広告の必要性を排除するためにそうします。
In the simplest sense, the change from Class A/B/C network numbers to classless prefixes is to make explicit which bits in a 32-bit IPv4 address are interpreted as the network number (or prefix) associated with a site and which are the used to number individual end systems within the site. In CIDR notation, a prefix is shown as a 4-octet quantity, just like a traditional IPv4 address or network number, followed by the "/" (slash) character, followed by a decimal value between 0 and 32 that describes the number of significant bits.
最も単純な意味で、クラスレスプレフィックスのクラスA / B / Cのネットワーク番号からの変化は、32ビットのIPv4アドレスのビットがネットワーク番号（または接頭辞）として解釈され、明示的にすることであるサイトに関連付けられているされていますサイト内の個々のエンドシステムに番号を付けるために使用されます。 CIDR表記では、プレフィックスはの数を表す0と32との間の小数値が続く「/」（スラッシュ）文字、続いて、ちょうど従来のIPv4アドレスまたはネットワーク番号のような、4オクテットの数として示されています上位ビット。
For example, the legacy "Class B" network 172.16.0.0, with an implied network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16, the "/16" indicating that the mask to extract the network portion of the prefix is a 32-bit value where the most significant 16 bits are ones and the least significant 16 bits are zeros. Similarly, the legacy "Class C" network number 192.168.99.0 is defined as the prefix 192.168.99.0/24; the most significant 24 bits are ones and the least significant 8 bits are zeros.
例えば、255.255.0.0の暗黙のネットワークマスクを持つレガシー「クラスB」ネットワーク172.16.0.0は、マスクのネットワーク部分を抽出することを示す接頭辞172.16.0.0/16、「/ 16」と定義されますプレフィックスは、上位16ビットがのものであり、最下位16ビットがゼロである32ビット値です。同様に、従来の「クラスC」ネットワーク番号192.168.99.0は、プレフィックス192.168.99.0/24のように定義されます。最上位24ビットがのものであり、最下位8ビットはゼロです。
Using classless prefixes with explicit prefix lengths allows much more flexible matching of address space blocks according to actual need. Where formerly only three network sizes were available, prefixes may be defined to describe any power of two-sized block of between one and 2^32 end system addresses. In practice, the unallocated pool of addresses is administered by the Internet Assigned Numbers Authority ([IANA]). The IANA makes allocations from this pool to Regional Internet Registries, as required. These allocations are made in contiguous bit-aligned blocks of 2^24 addresses (a.k.a. /8 prefixes). The Regional Internet Registries (RIRs), in turn, allocate or assign smaller address blocks to Local Internet Registries (LIRs) or Internet Service Providers (ISPs). These entities may make direct use of the assignment (as would commonly be the case for an ISP) or may make further sub-allocations of addresses to their customers. These RIR address assignments vary according to the needs of each ISP or LIR. For example, a large ISP might be allocated an address block of 2^17 addresses (a /15 prefix), whereas a smaller ISP may be allocated an address block of 2^11 addresses (a /21 prefix).
明示的なプレフィックス長とクラスレスプレフィックスを使用すると、実際の必要に応じてアドレス空間のブロックの一層柔軟なマッチングを可能にします。以前は3つのだけのネットワークサイズが利用可能であった場合、プレフィックスは1〜2 ^ 32のエンドシステムアドレスの二サイズのブロックのいずれかの電源を記述するために定義されてもよいです。実際には、アドレスの未割り当てプールは、インターネット割り当て番号機関（[IANA]）によって投与されます。必要に応じて、IANAは、地域インターネットレジストリにこのプールから割り当てを行います。これらの割り当ては、2 ^ 24のアドレス（別名/ 8プレフィックス）の連続するビット整列ブロックで作られています。地域インターネットレジストリ（RIRは）、今度は、割り当てまたはローカルインターネットレジストリ（のLIR）、またはインターネットサービスプロバイダ（ISP）に小さなアドレスブロックを割り当てます。これらのエンティティは、（一般的にISPのための場合のように）割り当てを直接利用することができるか、顧客にアドレスをさらに再割り振りを行うことができます。これらのRIRアドレスの割り当ては、各ISPやLIRのニーズに応じて異なります。小さなISPは、2 ^ 11のアドレス（/ 21プレフィックス）のアドレスブロックを割り当てることができるのに対し、例えば、大規模なISPは、2 ^ 17のアドレス（/ 15プレフィックス）のアドレスブロックを割り当てられるかもしれません。
Note that the terms "allocate" and "assign" have specific meaning in the Internet address registry system; "allocate" refers to the delegation of a block of address space to an organization that is expected to perform further sub-delegations, and "assign" is used for sites that directly use (i.e., number individual hosts) the block of addresses received.
用語は「割り当て」とインターネットアドレスレジストリシステムに特定の意味を持つ「割り当てる」ことに注意してください。さらにサブ委任を実行すると予想される組織へのアドレス空間のブロックの代表団を意味し、「割り当て」に直接（すなわち、番号個々のホスト）を使用するサイトのために使用される「割り当て」アドレスのブロックが受信されました。
The following table provides a convenient shortcut to all the CIDR prefix sizes, showing the number of addresses possible in each prefix and the number of prefixes of that size that may be numbered in the 32-bit IPv4 address space:
次の表は、各プレフィックスと32ビットのIPv4アドレス空間に番号付けされてもよい、そのサイズのプレフィクスの数の可能なアドレスの数を示し、すべてのCIDRプレフィックスのサイズに便利なショートカットを提供します。
notation addrs/block # blocks
-------- ----------- ----------
n.n.n.n/32 1 4294967296 "host route"
n.n.n.x/31 2 2147483648 "p2p link"
n.n.n.x/30 4 1073741824
n.n.n.x/29 8 536870912
n.n.n.x/28 16 268435456
n.n.n.x/27 32 134217728
n.n.n.x/26 64 67108864
n.n.n.x/25 128 33554432
n.n.n.0/24 256 16777216 legacy "Class C"
n.n.x.0/23 512 8388608
n.n.x.0/22 1024 4194304
n.n.x.0/21 2048 2097152
n.n.x.0/20 4096 1048576
n.n.x.0/19 8192 524288
n.n.x.0/18 16384 262144
n.n.x.0/17 32768 131072
n.n.0.0/16 65536 65536 legacy "Class B"
n.x.0.0/15 131072 32768
n.x.0.0/14 262144 16384
n.x.0.0/13 524288 8192
n.x.0.0/12 1048576 4096
n.x.0.0/11 2097152 2048
n.x.0.0/10 4194304 1024
n.x.0.0/9 8388608 512
n.0.0.0/8 16777216 256 legacy "Class A"
x.0.0.0/7 33554432 128
x.0.0.0/6 67108864 64
x.0.0.0/5 134217728 32
x.0.0.0/4 268435456 16
x.0.0.0/3 536870912 8
x.0.0.0/2 1073741824 4
x.0.0.0/1 2147483648 2
0.0.0.0/0 4294967296 1 "default route"
n is an 8-bit decimal octet value. Point-to-point links are discussed in more detail in [RFC3021].
nが8ビットの10進オクテット値です。ポイントツーポイントリンクは、[RFC3021]で詳しく説明されています。
x is a 1- to 7-bit value, based on the prefix length, shifted into the most significant bits of the octet and converted into decimal form; the least significant bits of the octet are zero.
Xオクテットの最上位ビットにシフトし、小数点形式に変換し、プレフィックス長に基づいて、1〜7ビットの値です。オクテットの最下位ビットはゼロです。
In practice, prefixes of length shorter than 8 have not been allocated or assigned to date, although routes to such short prefixes may exist in routing tables if or when aggressive aggregation is performed. As of the writing of this document, no such routes are seen in the global routing system, but operator error and other events have caused some of them (i.e., 128.0.0.0/1 and 192.0.0.0/2) to be observed in some networks at some times in the past.
積極的な凝集が行われた場合、または場合そのような短いプレフィックスへのルートがルーティングテーブルに存在するかもしれないが、実際には、8よりも短い長さのプレフィックスが割り当てられていない、または日付に割り当てられました。この文書の執筆時点では、このようなルートは、グローバルルーティングシステムに見られないが、オペレータエラーやその他のイベントは、そのうちのいくつか（すなわち、128.0.0.0/1及び192.0.0.0/2）の一部において観察される原因となっています過去のある時点におけるネットワーク。
Classless addressing and routing was initially developed primarily to improve the scaling properties of routing on the global Internet. Because the scaling of routing is very tightly coupled to the way that addresses are used, deployment of CIDR had implications for the way in which addresses were assigned.
クラスレスアドレッシングとルーティングは当初、主にグローバルなインターネット上でのルーティングのスケーリング特性を改善するために開発されました。ルーティングのスケーリングは非常に緊密にアドレスが使用されている方法に結合されているので、CIDRの展開は、アドレスが割り当てされた方法に影響を持っていました。
The only commonly understood method for reducing routing state on a packet-switched network is through aggregation of information. For CIDR to succeed in reducing the size and growth rate of the global routing system, the IPv4 address assignment process needed to be changed to make possible the aggregation of routing information along topological lines. Since, in general, the topology of the network is determined by the service providers who have built it, topologically significant address assignments are necessarily service-provider oriented.
パケット交換ネットワーク上でルーティング状態を低減するための唯一の一般的に理解方法は、情報の集合によるものです。 CIDRは、グローバルルーティングシステムのサイズおよび成長速度を減少させるのに成功するために、IPv4アドレス割当処理は、トポロジカル線に沿ってルーティング情報の集約を可能にするために変更する必要がありました。以来、一般的には、ネットワークのトポロジがそれを構築しているサービスプロバイダーによって決定された位相幾何学的に重要なアドレス割り当ては、必ずしもサービスプロバイダー指向です。
Aggregation is simple for an end site that is connected to one service provider: it uses address space assigned by its service provider, and that address space is a small piece of a larger block allocated to the service provider. No explicit route is needed for the end site; the service provider advertises a single aggregate route for the larger block. This advertisement provides reachability and routeability for all the customers numbered in the block.
凝集は、一つのサービスプロバイダに接続されるエンドサイトの単純である：それは、そのサービスプロバイダによって割り当てられたアドレス空間を使用し、そのアドレス空間は、サービスプロバイダに割り当てられた大きなブロックの小片です。明示的なルートは、エンドサイトのために必要ありません。サービス・プロバイダは、より大きなブロックのための単一の集約ルートをアドバタイズ。この広告はブロックに番号をすべての顧客のための到達可能性およびルート機能を提供します。
There are two, more complex, situations that reduce the effectiveness of aggregation:
集約の有効性を減らす2、より複雑な、状況があります：
o An organization that is multi-homed. Because a multi-homed organization must be advertised into the system by each of its service providers, it is often not feasible to aggregate its routing information into the address space of any one of those providers. Note that the organization still may receive its address assignment out of a service provider's address space (which has other advantages), but that a route to the organization's prefix is, in the most general case, explicitly advertised by all of its service providers. For this reason, the global routing cost for a multi-homed organization is generally the same as it was prior to the adoption of CIDR. A more detailed consideration of multi-homing practices can be found in [RFC4116].
マルチホームである組織O。マルチホームの組織がそのサービスプロバイダの各によってシステムに公示しなければならないので、これらのプロバイダのいずれかのアドレス空間にそのルーティング情報を集約することはしばしば現実的ではありません。組織はまだ（他の利点を持っている）、サービスプロバイダーのアドレス空間のうち、そのアドレスの割り当てを受けることができるが、組織の接頭語へのルートがあることを、最も一般的な場合には、明示的にそのサービスプロバイダーのすべてによってアドバタイズことに注意してください。この理由のために、マルチホーム組織のグローバルルーティングコストは、一般的にはCIDRの採用に先立ったものと同じです。マルチホーミング慣行のより詳細な考察は、[RFC4116]に見出すことができます。
o An organization that changes service provider but does not renumber. This has the effect of "punching a hole" in one of the original service provider's aggregated route advertisements. CIDR handles this situation by requiring that the newer service provider to advertise a specific advertisement for the re-homed organization; this advertisement is preferred over provider aggregates because it is a longer match. To maintain efficiency of aggregation, it is recommended that an organization that changes service providers plan eventually to migrate its network into a an prefix assigned from its new provider's address space. To this end, it is recommended that mechanisms to facilitate such migration, such as dynamic host address assignment that uses [RFC2131]), be deployed wherever possible, and that additional protocol work be done to develop improved technology for renumbering.
サービスプロバイダを変更しますが、番号を付け直すしません組織O。これは、元のサービスプロバイダの集約ルートの広告の1つに「穴パンチ」の効果があります。 CIDRは、新しいサービスプロバイダが再ホーム組織の特定の広告を広告することを要求することによって、この状況を処理します。それは長いマッチであるため、この広告は、プロバイダの集合体よりも好ましいです。集計の効率を維持するためには、最終的には、サービスプロバイダの計画を変更し、組織がその新しいプロバイダーのアドレス空間から割り当てられたプレフィックスにそのネットワークを移行することをお勧めします。この目的のために、そのような[RFC2131]）を使用して、動的ホストアドレスの割り当てとして、メカニズムがそのような移動を容易にすることが推奨され、可能な限り展開すること、及びその付加的なプロトコル作業がリナンバリングのための改良された技術を開発するために行われます。
Note that some aggregation efficiency gain can still be had for multi-homed sites (and, in general, for any site composed of multiple, logical IPv4 networks); by allocating a contiguous power-of-two block address space to the site (as opposed to multiple, independent prefixes), the site's routing information may be aggregated into a single prefix. Also, since the routing cost associated with assigning a multi-homed site out of a service provider's address space is no greater than the old method of sequential number assignment by a central authority, it makes sense to assign all end-site address space out of blocks allocated to service providers.
いくつかの凝集効率利得は依然として（及び、一般的に、複数の論理的なIPv4ネットワークからなる任意のサイトの）マルチホームサイトのために持っていたことができることに留意されたいです。 （複数の独立したプレフィックスとは対照的）部位に隣接する、2のべき乗のブロックアドレス空間を割り当てることにより、サイトのルーティング情報は、単一のプレフィックスに集約することができます。サービスプロバイダーのアドレス空間のうち、マルチホームのサイトを割り当てるに関連付けられたルーティングコストは、中央当局によるシーケンシャル番号の割り当ての古い方法よりも大きくないので、また、それは外のすべてのエンドサイトのアドレススペースを割り当てることが理にかなっていますサービスプロバイダに割り当てられたブロック。
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 relatively small providers that both obtain connectivity and address space from the same large provider, then aggregation by the large provider of routes from the smaller networks will include all routes to the multi-homed site. The feasibility of this sort of second-level aggregation depends on whether topological hierarchy exists among a site, its directly-connected providers, and other providers to which they are connected; it may be practical in some regions of the global Internet but not in others.
凝集は、システム内の複数のレベルで起こり得るので、まだ存在していてもよいどんな階層の高いレベルでこれらの異常な経路を集約することが可能であることに言及することも価値があります。サイトが両方とも同じ大プロバイダから接続アドレス空間を取得する2つの比較的小さなプロバイダにマルチホームされた場合、例えば、より小さいネットワークからのルートの大プロバイダによって凝集がマルチホームサイトへのすべてのルートが含まれ。第二レベルの凝集のこの種の可能性は、トポロジカル階層は、それらが接続される部位、その直接接続プロバイダ、および他のプロバイダの間で存在するかどうかに依存します。それは、グローバルなインターネットのいくつかの地域ではなく、他に実用的な場合があります。
Note: In the discussion and examples that follow, prefix 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.
注：議論および以下の実施例では、接頭表記は、ルーティング先を表すために使用されます。これは説明のためのみに使用され、ルーティングプロトコルが彼らのアップデートでこの表現を使用する必要はありません。
In the early days of the Internet, IPv4 address space assignment was performed by the central Network Information Center (NIC). Class A/B/C network numbers were assigned in essentially arbitrary order, roughly according to the size of the organizations that requested them. All assignments were recorded centrally, and no attempt was made to assign network numbers in a manner that would allow routing aggregation.
インターネットの黎明期には、IPv4アドレス空間の割り当ては、中央ネットワークインフォメーションセンター（NIC）によって行われました。クラスA / B / Cのネットワーク番号は、概ね、それらを要求された組織の大きさに応じて、本質的に任意の順序で割り当てました。すべての割り当ては、中央記録し、そして試みは、ルーティング集約を可能にするようにネットワーク番号を割り当てるようになされませんでした。
When CIDR was originally deployed, the central assignment authority continued to exist but changed its procedures to assign large blocks of "Class C" network numbers to each service provider. Each service provider, in turn, assigned bitmask-oriented subsets of the provider's address space to each customer. This worked reasonably well, as long as the number of service providers was relatively small and relatively constant, but it did not scale well, as the number of service providers grew at a rapid rate.
CIDRが最初に配備されたときに、中央の割り当て権限は存在し続けたが、各サービスプロバイダに「クラスC」ネットワーク番号の大きなブロックを割り当てるために、その手順を変更しました。各サービスプロバイダは、順番に、各顧客に、プロバイダのアドレス空間のビットマスク指向のサブセットを割り当てられます。これは、限りのサービスプロバイダの数は急速に成長するにつれ、サービスプロバイダーの数が比較的小さく、比較的一定であったが、それはうまくスケールなかったとして、合理的にうまくいきました。
As the Internet started to expand rapidly in the 1990s, it became clear that a single, centralized address assignment authority was problematic. This function began being de-centralized when address space assignment for European Internet sites was delegated in bit-aligned blocks of 16777216 addresses (what CIDR would later define as a /8) to the RIPE NCC ([RIPE]), effectively making it the first of the RIRs. Since then, address assignment has been formally distributed as a hierarchical function with IANA, the RIRs, and the service providers. Removing the bottleneck of a single organization having responsibility for the global Internet address space greatly improved the efficiency and response time for new assignments.
インターネットは、1990年代に急速に拡大し始めたので、それは単一の集中アドレス割り当て権限が問題であることが明らかとなりました。ヨーロッパのインターネットサイトのアドレス空間の割り当ては、RIPE NCC（[RIPE]）へ16777216のアドレスのビットアラインブロック（後/ 8として何CIDRを定義します）に委譲されたときに、この機能は解除集中され始めた、効果的に作りますRIRの最初の。それ以来、アドレスの割り当てが正式にIANA、のRIR、およびサービスプロバイダーとの階層的な機能として配布されています。グローバルなインターネットアドレス空間の責任を有する単一の組織のボトルネックを削除すると、大幅に新しい割り当ての効率性と応答時間を改善しました。
Hierarchical delegation of addresses in this manner implies that sites with addresses assigned 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.
このようにアドレスの階層的な代表団は、与えられたサービスプロバイダから割り当てられたアドレスを持つサイトは、ルーティングの目的のために、そのサービスプロバイダの一部であり、そのインフラを経由してルーティングされることを意味します。これは、マルチホーム組織（複数のネットワークサービスプロバイダに接続され、すなわち、組織）に関するルーティング情報がまだ階層の高いレベルで知られる必要があることを意味します。
A historical perspective on these issues is described in [RFC1518]. Additional discussion may also be found in [RFC3221].
これらの問題に関する歴史的観点は、[RFC1518]に記載されています。追加の議論はまた、[RFC3221]で見つけられるかもしれません。
With the change from classful network numbers to classless prefixes, it is not possible to infer the network mask from the initial bit pattern of an IPv4 address. This has implications for how routing information is stored and propagated. Network masks or prefix lengths must be explicitly carried in routing protocols. Interior routing protocols, such as OSPF [RFC2328], Intermediate System to Intermediate System (IS-IS) [RFC1195], RIPv2 [RFC2453], and Cisco Enhanced Interior Gateway Routing Protocol (EIGRP), and the BGP4 exterior routing protocol [RFC4271], all support this functionality, having been developed or modified as part of the deployment of classless inter-domain routing during the 1990s.
クラスレスプレフィックスのクラスフルネットワーク番号からの変化と、IPv4アドレスの最初のビットパターンからネットワークマスクを推測することは不可能です。これは保存され、伝播される方法ルーティング情報に影響を与えています。ネットワークマスクまたはプレフィックス長は、明示的なルーティングプロトコルで運ばなければなりません。例えばOSPF [RFC2328]、中間システム（IS-IS）[RFC1195]、RIPv2の[RFC2453]の中間システム、およびCiscoエンハンストインテリアゲートウェイルーティングプロトコル（EIGRP）、およびBGP4外部ルーティングプロトコル[RFC4271]などの内部ルーティングプロトコル、 、すべてがこの機能をサポートし、1990年代のクラスレスドメイン間ルーティングの展開の一部として開発されたまたは修飾されました。
Older interior routing protocols, such as RIP [RFC1058], HELLO, and Cisco Interior Gateway Routing Protocol (IGRP), and older exterior routing protocols, such as Exterior Gateway Protocol (EGP) [RFC904], do not support explicit carriage of prefix length/mask and thus cannot be effectively used on the Internet other than in very limited stub configurations. Although their use may be appropriate in simple legacy end-site configurations, they are considered obsolete and should NOT be used in transit networks connected to the global Internet.
このようRIP [RFC1058]、ハロー、およびCiscoインテリアゲートウェイルーティングプロトコル（IGRP）、および、そのようなエクステリアゲートウェイプロトコル（EGP）などの古い外部ルーティングプロトコルなどの古い内部ルーティングプロトコル、[RFC904]は、プレフィックス長の明示的なキャリッジをサポートしていません。 /マスクと効果的に非常に限られたスタブの構成以外のインターネット上で使用することができません。それらの使用は、単純なレガシーエンドサイト構成で適切であるかもしれないが、彼らは時代遅れとみなされ、世界的なインターネットに接続トランジットネットワークでは使用しないでください。
Similarly, routing and forwarding tables in layer-3 network equipment must be organized to store both prefix and prefix length or mask. Equipment that organizes its routing/forwarding information according to legacy Class A/B/C network/subnet conventions cannot be expected to work correctly on networks connected to the global Internet; use of such equipment is not recommended. Fortunately, very little such equipment is in use today.
同様に、レイヤ3ネットワーク装置におけるルーティングおよび転送テーブルは、プレフィックスとプレフィックス長またはマスクの両方を格納するように編成されなければなりません。レガシークラスA / B / Cのネットワークに応じてそのルーティング/転送情報を編成機器/サブネット規則がグローバルなインターネットに接続されたネットワーク上で正しく動作するように期待することはできません。このような機器の使用が推奨されていません。幸いなことに、非常に少ないような機器が使用中で、今日です。
1. Forwarding in the Internet is done on a longest-match basis. This implies that destinations that are multi-homed relative to a routing domain must always be explicitly announced into that routing domain (i.e., they cannot be summarized). If a network is multi-homed, all of its paths into a routing domain that is "higher" in the hierarchy of networks must be known to the "higher" network).
インターネット1.転送は最長一致に基づいて行われます。これは、マルチホームのルーティングドメインに関連している先は、常に明示的にルーティングドメイン（すなわち、彼らはまとめることができない）に発表しなければならないことを意味します。ネットワークがマルチホームである場合、ネットワークの階層において「より高い」であるルーティングドメインへのその経路の全てが「高い」ネットワーク）に知られていなければなりません。
2. A router that generates an aggregate route for multiple, more-specific routes must discard packets that match the aggregate route, but not any of the more-specific routes. In other words, the "next hop" for the aggregate route should be the null destination. This is necessary to prevent forwarding loops when some addresses covered by the aggregate are not reachable.
2.集約ルートと一致するパケットを廃棄しなければならない多数の、より具体的なルートの集約ルートを生成するルータではなく、より具体的なルートのいずれか。換言すれば、集約経路のための「ネクストホップ」がnullの宛先であるべきです。これは、集約によってカバーされ、いくつかのアドレスが到達可能でないとき、転送ループを防止する必要があります。
Note that during failures, partial routing of traffic to a site that takes its address space from one service provider but that is actually reachable only through another (i.e., the case of a site that has changed service providers) may occur because such traffic will be forwarded along the path advertised by the aggregated route. Rule #2 will prevent packet misdelivery by causing 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 that network rather than in the network that is no longer advertising the more-specific prefix. This may be confusing to those trying to diagnose connectivity problems; see the example in Section 6.2 for details. A solution to this perceived "problem" is beyond the scope of this document; it lies with better education of the user/operator community, not in routing technology.
そのようなトラフィックがなるので故障の際に、1つのサービスプロバイダからそのアドレス空間を取りますが、それが唯一の別によって実際に到達可能である（すなわち、サービスプロバイダを変更したサイトの場合）サイトへのトラフィックの部分的なルーティングが発生する可能性があることに注意してください集約経路によってアドバタイズ経路に沿って転送されます。ルール＃2は、集約ルートの広告主によって破棄されるように、このようなトラフィックを引き起こすことによって、パケットの誤配信を防止しますが、「トレースルート」および他の同様のツールの出力には問題はありません、そのネットワーク内ではなく、あるネットワーク内に存在することを示唆しているだろう長く、より固有のプレフィックスを広告します。これは、接続の問題を診断しようとするものに混乱を招くことがあり、詳細については、6.2節の例を参照してください。これを解決するには、「問題」は、このドキュメントの範囲を超えて、知覚しました。それはないルーティング技術では、ユーザ/オペレータコミュニティのよりよい教育にあります。
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 to prefix 0.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 only be advertised to another routing domain when a router is explicitly configured to do so, never as a non-configured, "default" option.
任意のネットワーク番号とマスクがすべてのルーティング宛先に受け入れられるように、これらのルールを次の実装はまた、一般化されなければなりません。唯一の優秀な制約は、マスクが連続したままにしなければならないということです。接頭0.0.0.0/0への縮退ルートがデフォルトルートとして使用され、すべての実装で受け入れなければならないことに注意してください。ルータが明示的にそうするように構成されている場合、さらに、ドメイン間のプロトコルを介して、このルートの偶然の広告から保護するために、このルートは唯一の非構成された、「デフォルト」のオプションとして、別のルーティングドメインに決して広告してはなりません。
Rule #1 guarantees that the forwarding algorithm used is consistent across routing protocols and implementations. 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 longest-match forwarding causes this not to work. More details are provided in [RFC4116].
使用される転送アルゴリズムは、ルーティングプロトコルと実装間一貫していることをルール＃1が保証。マルチホームネットワークは常に明示的に（そうでない場合、彼らははっきりと明示的に宣伝しなければならない）、彼らは一つのサービスプロバイダの集合体の特定のサブセットであっても、それらを送信する際に経由するすべてのサービスプロバイダによってアドバタイズされています。 「プライマリ」、サービスプロバイダがその集合体の一部として暗黙的にマルチホームのサイトを宣伝することができかのように見えるかもしれませんが、最長一致の転送は、これが機能しない原因となります。詳細は[RFC4116]で提供されます。
Rule #2 guarantees that no routing loops form due to aggregation. Consider a site that has been assigned 192.168.64/19 by its "parent" provider, which has 192.168.0.0/16. The "parent" network will advertise 192.168.0.0/16 to the "child" network. If the "child" network were to lose internal connectivity to 192.168.65.0/24 (which is part of its aggregate), traffic from the "parent" to the to the "child" destined for 192.168.65.1 will follow the "child's" advertised route. When that traffic gets to the "child", however, the child *must not* follow the route 192.168.0.0/16 back up to the "parent", since that would result in a forwarding loop. Rule #2 says that the "child" may not follow a less-specific route for a destination that matches one of its own aggregated routes (typically, this is implemented by installing a "discard" or "null" route for all aggregated prefixes that one network advertises to another). Note that handling of the "default" route (0.0.0.0/0) is a special case of this rule; a network must not follow the default to destinations that are part of one of its aggregated advertisements.
何のルーティングループが凝集による形成しないことをルール＃2が保証されます。 192.168.0.0/16を持っているその「親」プロバイダによって192.168.64 / 19が割り当てられているサイトを考えてみましょう。 「親」のネットワークは、「子」ネットワークに192.168.0.0/16をアドバタイズします。 「子」ネットワークは、（その集合体の一部である）192.168.65.0/24への内部接続を失った場合は、「親」から192.168.65.1宛ての「子」へのトラフィックは、「子供の」を従いますアドバタイズされたルート。そのトラフィックは、「子」になるとそれはフォワーディングループになるであろうから、しかし、子*は、バックアップ「親」への経路192.168.0.0/16に従わないでなければなりません。ルール＃2は、「子」は、（典型的には、これはその全て集約プレフィクスの「廃棄」または「ヌル」ルートをインストールすることによって実現されている独自の集約ルートの1つに一致する宛先の少ない特定のルートに従わないことを言います1ネットワーク）は別のものにアドバタイズします。 「デフォルト」ルート（0.0.0.0/0）このルールの特殊なケースがあるの取り扱いに注意してください。ネットワークは、その集約された広告の1つの一部である宛先へのデフォルトに従ってはいけません。
Systems that process route announcements must be able to verify that information that they receive is acceptable according to policy rules. Implementations that filter route advertisements must allow masks or prefix lengths in filter elements. Thus, filter elements that formerly were specified as
ルートアナウンスを処理するシステムは、それらがポリシールールに従って許容される受け取ること、その情報を確認することができなければなりません。フィルタルートアドバタイズメントは、フィルタエレメントにマスクまたはプレフィックス長を許可する必要があります実装。したがって、以前のように指定された要素をフィルタリングします
accept 172.16.0.0 accept 172.25.120.0.0 accept 172.31.0.0 deny 10.2.0.0 accept 10.0.0.0
172.25.120.0.0受け入れる受け入れ172.16.0.0を受け入れる172.31.0.0 10.2.0.0が10.0.0.0を受け入れ拒否
now look something like this:
今、このような何かを見て：
accept 172.16.0.0/16 accept 172.25.0.0/16 accept 172.31.0.0/16 deny 10.2.0.0/16 accept 10.0.0.0/8
172.16.0.0/16が172.25.0.0/16が受け入れる受け入れる受け入れ172.31.0.0/16 10.2.0.0/16は10.0.0.0/8を受け入れ拒否
This is merely making explicit the network mask that was implied by the Class A/B/C classification of network numbers. It is also useful to enhance filtering capability to allow the match of a prefix and all more-specific prefixes with the same bit pattern; fortunately, this functionality has been implemented by most vendors of equipment used on the Internet.
これは、単にネットワーク番号のクラスA / B / C分類によって暗示された明示的なネットワークマスクを作っています。プレフィックスと同一のビットパターンを持つすべてのより特異的プレフィクスの一致を可能にするために、フィルタリング機能を強化するためにも有用です。幸いなことに、この機能は、インターネット上で使用される機器のほとんどのベンダーによって実装されています。
Under normal circumstances, a routing domain (or "Autonomous System") that has been allocated or assigned a set of prefixes has sole responsibility for aggregation of those prefixes. In the usual case, the AS will install configuration in one or more of its routers to generate aggregate routes based on more-specific routes known to its internal routing system. These aggregate routes are advertised into the global routing system by the border routers for the routing domain. The more-specific internal routes that overlap with the aggregate routes should not be advertised globally. In some cases, an AS may wish to delegate aggregation responsibility to another AS (for example, a customer may wish for its service provider to generate aggregated routing information on its behalf); in such cases, aggregation is performed by a router in the second AS according to the routes that it receives from the first, combined with configured policy information describing how those routes should be aggregated.
通常の状況下では、プレフィクスのセットを割り当てまたは割り当てられているルーティングドメイン（または「自律システム」）は、それらの接頭語の集合のために責任を有しています。通常の場合、ASは、内部ルーティングシステムに既知のより具体的なルートに基づいて、集約ルートを生成するために、そのルータの1つまたは複数の構成でインストールされます。これらの集約ルートは、ルーティングドメインの境界ルータによってグローバルルーティングシステムに通知されます。集約ルートと重なるより具体的な内部のルートは、グローバルにアドバタイズされるべきではありません。いくつかのケースでは、ASは、別のAS（たとえば、顧客がその代わりに集約ルーティング情報を生成するために、そのサービスプロバイダの希望することができる）に集約責任を委任することを望むかもしれません。そのような場合には、凝集が、それがそれらのルートを集約する方法を説明設定されたポリシー情報と組み合わされ、最初から受信する経路に従って第二のAS内のルータによって実行されます。
Note that one provider may choose to perform aggregation on the routes it receives from another without explicit agreement; this is termed "proxy aggregation". This can be a useful tool for reducing the amount of routing state that an AS must carry and propagate to its customers and neighbors. However, proxy aggregation can also create unintended consequences in traffic engineering. Consider what happens if both AS 2 and 3 receive routes from AS 1 but AS 2 performs proxy aggregation while AS 3 does not. Other ASes that receive transit routing information from both AS 2 and AS 3 will see an inconsistent view of the routing information originated by AS 1. This may cause an unexpected shift of traffic toward AS 1 through AS 3 for AS 3's customers and any others receiving transit routes from AS 3. Because proxy aggregation can cause unanticipated consequences for parts of the Internet that have no relationship with either the source of the aggregated routes or the party providing aggregation, it should be used with extreme caution.
1つのプロバイダは、それが明示的な同意なしに他から受ける経路に集約を実行することを選択することができることに留意されたいです。これは、「プロキシ集合」と呼ばれています。これはASが運ぶとその顧客と隣人に伝播しなければならない状態のルーティングの量を減少させるのに有用なツールとなります。ただし、プロキシ集約はまた、トラフィックエンジニアリングにおける意図しない結果を作成することができます。 3 ASがないまま2 ASと3の両方がプロキシ集約1 ASが、2つの行うASから経路を受信した場合どうなるかを考えます。他の2の両方からのトランジットルーティング情報を受け取るのASと3 ASこれはAS 3の顧客のためのAS〜3 AS 1に向けて、トラフィックの予想外のシフトを引き起こす可能性があり、任意の他の人が受けAS 1によって発信ルーティング情報の一貫性のないビューが表示されますAS 3からの輸送ルートがプロキシ凝集が集約されたルートのソースまたは集約を提供するいずれかの当事者とは関係を持たないインターネットの部分のために予期しない結果を引き起こす可能性がありますので、細心の注意を払って使用する必要があります。
Configuration of the routes to be combined into aggregates is an implementation of routing policy and requires some manually maintained information. As an addition to the information that must be maintained for a set of routeable prefixes, aggregation configuration is typically just a line or two defining the range of the block of IPv4 addresses to be aggregated. A site performing its own aggregation is doing so for address blocks that it has been assigned; a site performing aggregation on behalf of another knows this information because of an agreement to delegate aggregation. Assuming that the best common practice for network administrators is to exchange lists of prefixes to accept from each other, configuration of aggregation information does not introduce significant additional administrative overhead.
凝集体に結合する経路の構成は、ポリシールーティングの実装であり、いくつか手動で維持される情報を必要とします。ルーティング可能なプレフィクスのセットのために維持されなければならない情報への追加として、集約構成は、典型的にはIPv4のブロックの範囲を集約するアドレス定義だけ行または2です。独自の集計を実行するサイトでは、それが割り当てられたアドレスブロックのためにそうされます。他に代わって集約を実行するサイトがあるため凝集を委譲する契約を、この情報を知っています。ネットワーク管理者のための最良の慣行が互いに受け入れるように接頭辞のリストを交換することであると仮定すると、集約情報の設定は重要な追加管理オーバーヘッドを導入しません。
The generation of an aggregate route is usually specified either statically or in response to learning an active dynamic route for a prefix contained within the aggregate route. If such dynamic aggregate route advertisement is done, care should be taken that routes are not excessively added or withdrawn (known as "route flapping"). In general, a dynamic aggregate route advertisement is added when at least one component of the aggregate becomes reachable and it is withdrawn only when all components become unreachable. Properly configured, aggregated routes are more stable than non-aggregated routes and thus improve global routing stability.
集約経路の生成は、通常、静的または集約ルート内に含まれるプレフィックスのアクティブな動的経路の学習に応答して指定されています。このような動的集約経路広告が行われている場合、注意がルートが過剰（「ルートフラッピング」として知られている）を添加し、または撤回されないことを注意すべきです。一般的に、動的集約経路広告は、集合の少なくとも1つの成分が到達可能になったときに追加され、すべてのコンポーネントが到達不能になった場合にのみ引き出されます。適切に設定、集約ルートは非凝集経路よりも安定であり、従って、グローバルルーティング安定性を向上させます。
Implementation note: Aggregation of the "Class D" (multicast) address space is beyond the scope of this document.
実装上の注意：「クラスD」（マルチキャスト）のアドレス空間の集約は、このドキュメントの範囲を超えています。
Prior to the original deployment of CIDR, common practice was to propagate routes learned via exterior routing protocols (i.e., EGP or BGP) through a site's interior routing protocol (typically, OSPF, IS-IS, or RIP). This was done to ensure that consistent and correct exit points were chosen for traffic to be sent to a destination learned through those protocols. Four evolutionary effects -- the advent of CIDR, explosive growth of global routing state, widespread adoption of BGP4, and a requirement to propagate full path information -- have combined to deprecate that practice. To ensure proper path propagation and prevent inter-AS routing inconsistency (BGP4's loop detection/prevention mechanism requires full path propagation), transit networks must use internal BGP (iBGP) for carrying routes learned from other providers both within and through their networks.
前CIDRの元の配置に、一般的な方法は、サイトの内部のルーティングプロトコル（典型的には、OSPFは、IS-IS、またはRIP）を介して外部ルーティングプロトコル（すなわち、EGPまたはBGP）を介して学習されたルートを伝播することでした。これは、トラフィックがこれらのプロトコルを介して学習の宛先に送信するための一貫した、正しい出口点が選ばれたことを確認するために行われました。四の進化の効果 - CIDRの到来、グローバルルーティング状態の爆発的な成長、BGP4の普及、および完全なパス情報を伝播するための要件は - その実践を廃止するために結合しています。適切なパス伝搬を保証し、相互ASルーティング矛盾を防ぐために、トランジットネットワークは内およびそのネットワークを介して両方の他のプロバイダから学習したルートを運ぶための内部BGP（iBGPの）を使用する必要があり（BGP4のループ検知/防御機構は、完全パス伝搬を必要とします）。
Consider the block of 524288 (2^19) addresses, beginning with 10.24.0.0 and ending with 10.31.255.255, allocated to a single network provider, "PA". This is equivalent in size to a block of 2048 legacy "Class C" network numbers (or /24s). A classless route to this block would be described as 10.24.0.0 with a mask of 255.248.0.0 and the prefix 10.24.0.0/13.
単一のネットワークプロバイダに割り当てられている524288（2 ^ 19）アドレス、10.24.0.0で始まり10.31.255.255で終わる、「PA」のブロックを考えてみましょう。これは、2048レガシー「クラスC」ネットワーク番号（または/ 24S）のブロックのサイズに相当します。このブロックのクラスレスルートが255.248.0.0のマスク及び接頭10.24.0.0/13と10.24.0.0として記載されるであろう。
Assume that this service provider connects six sites in the following order (significant because it demonstrates how temporary "holes" may form in the service provider's address space): o "C1", requiring fewer than 2048 addresses (/21 or 8 x /24)
「C1」O、未満2048のアドレス（/ 21または8×/ 24を必要とする：（それはサービスプロバイダーのアドレス空間内に形成することができる方法一時的な「穴」を示しているので重要）このサービスプロバイダは、次の順序の6つのサイトを接続することを前提としてい）
o "C2", requiring fewer than 4096 addresses (/20 or 16 x /24)
未満4096のアドレス（/ 20または16 X / 24）を必要とO "C2"、
o "C3", requiring fewer than 1024 addresses (/22 or 4 x /24)
1024未満のアドレス（/ 22又は4×/ 24）を必要とO "C3"、
o "C4", requiring fewer than 1024 addresses (/22 or 4 x /24)
1024未満のアドレス（/ 22又は4×/ 24）を必要とO "C4"、
o "C5", requiring fewer than 512 addresses (/23 or 2 x /24)
512未満のアドレス（/ 23または2×/ 24）を必要とO "C5"、
o "C6", requiring fewer than 512 addresses (/23 or 2 x /24)
512未満のアドレス（/ 23または2×/ 24）を必要とO "C6"、
In all cases, the number of IPv4 addresses "required" by each site is assumed to allow for significant growth. The service provider delegates its address space as follows:
すべての場合において、各サイトで「必要」のIPv4アドレスの数は大幅な成長を可能と想定されます。サービスプロバイダーの代表者にそのアドレス空間次のように：
o C1. assign 10.24.0 through 10.24.7. This block of networks is described by the route 10.24.0.0/21 (mask 255.255.248.0).
C1 O。 10.24.7を通じて10.24.0を割り当てます。ネットワークのこのブロックは、ルート10.24.0.0/21（マスク255.255.248.0）によって記載されています。
o C2. Assign 10.24.16 through 10.24.31. This block is described by the route 10.24.16.0/20 (mask 255.255.240.0).
C2 O。 10.24.31を通じて10.24.16を割り当てます。このブロックは、ルート10.24.16.0/20（マスク255.255.240.0）によって記載されています。
o C3. Assign 10.24.8 through 10.24.11. This block is described by the route 10.24.8.0/22 (mask 255.255.252.0).
C3 O。 10.24.11を通じて10.24.8を割り当てます。このブロックは、ルート10.24.8.0/22（マスク255.255.252.0）によって記載されています。
o C4. Assign 10.24.12 through 10.24.15. This block is described by the route 10.24.12.0/22 (mask 255.255.252.0).
C4 O。 10.24.15を通じて10.24.12を割り当てます。このブロックは、ルート10.24.12.0/22（マスク255.255.252.0）によって記載されています。
o C5. Assign 10.24.32 and 10.24.33. This block is described by the route 10.24.32.0/23 (mask 255.255.254.0).
C5 O。 10.24.32と10.24.33を割り当てます。このブロックは、ルート10.24.32.0/23（マスク255.255.254.0）によって記載されています。
o C6. Assign 10.24.34 and 10.24.35. This block is described by the route 10.24.34.0/23 (mask 255.255.254.0).
C6 O。 10.24.34と10.24.35を割り当てます。このブロックは、ルート10.24.34.0/23（マスク255.255.254.0）によって記載されています。
These six sites should be represented as six prefixes of varying size within the provider's IGP. If, for some reason, the provider uses an obsolete IGP that doesn't support classless routing or variable-length subnets, then explicit routes for all /24s will have to be carried.
これらの6つのサイトは、プロバイダのIGP内のサイズを変えるの6つのプレフィックスとして表現されなければなりません。 、何らかの理由で、プロバイダは全て、次いでクラスレスルーティングまたは可変長サブネット、明示的なルートをサポートしていない時代遅れのIGPを使用している場合/ 24Sを搭載しなければなりません。
To make this example more realistic, assume that C4 and C5 are multi-homed through some other service provider, "PB". Further assume the existence of a site, "C7", that was originally connected to "RB" but that has moved to "PA". For this reason, it has a block of network numbers that are assigned out PB's block of (the next) 2048 x /24.
この例では、より現実的にするために、「PB」、C4とC5は、いくつかの他のサービスプロバイダを介してマルチホームされていることを前提としています。さらに、サイトの存在を前提とし「C7」、つまり、もともと「RB」に接続されていたが、それが「PA」に移動しました。このため、（次）2048×/ 24のPBのブロックを割り当てられているネットワーク番号のブロックを有しています。
o C7. Assign 10.32.0 through 10.32.15. This block is described by the route 10.32.0.0/20 (mask 255.255.240.0).
C7 O。 10.32.15を通じて10.32.0を割り当てます。このブロックは、ルート10.32.0.0/20（マスク255.255.240.0）によって記載されています。
For the multi-homed sites, assume that C4 is advertised as primary via "RA" and secondary via "RB"; and that C5 is primary via "RB" and secondary via "RA". In addition, assume that "RA" and "RB" are both connected to the same transit service provider, "BB".
マルチホームサイトの場合、C4は、「RB」を介して「RA」を介して、一次および二次として宣伝されているものとします。そのC5は、「RA」を経由して「RB」を経由してプライマリとセカンダリです。また、「BB」、「RA」および「RB」は両方とも同じトランジット・サービス・プロバイダに接続されていると仮定する。
Graphically, this topology looks something like this:
グラフィカルに、このトポロジは次のようになります。
10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0
C1: 10.24.0.0/21 \ / C7: 10.32.0.0/20
\ /
+----+ +----+
10.24.16.0 - 10.24.31.0_ | | | |
C2: 10.24.16.0/20 \ | | _10.24.12.0 - 10.24.15.0__ | |
\| | / C4: 10.24.12.0/20 \ | |
| |/ \| |
10.24.8.0 - 10.24.11.0___/| PA |\ | PB |
C3: 10.24.8.0/22 | | \__10.24.32.0 - 10.24.33.0___| |
| | C5: 10.24.32.0/23 | |
| | | |
10.24.34.0 - 10.24.35.0__/| | | |
C6: 10.24.34.0/23 | | | |
+----+ +----+
|| ||
routing advertisements: || ||
|| ||
10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) ||
10.32.0.0/20 (C7) || 10.24.32.0/23 (C5) ||
10.24.0.0/13 (PA) || 10.32.0.0/13 (PB) ||
|| ||
VV VV
+---------- BACKBONE NETWORK BB ----------+
To follow rule #1, PA will need to advertise the block of addresses that it was given and C7. Since C4 is multi-homed and primary through PA, it must also be advertised. C5 is multi-homed and primary through PB. In principle (and in the example above), it need not be advertised, since longest match by PB will automatically select PB as primary and the advertisement of PA's aggregate will be used as a secondary. In actual practice, C5 will normally be advertised via both providers.
ルール＃1に従うには、PAは、それが与えられたとC7たアドレスのブロックを宣伝する必要があります。 C4は、ホーム・マルチおよびPAを通して主であるので、それはまた、公示しなければなりません。 C5はPBを介してマルチホームと主要です。 PBによって最長一致が自動的にプライマリとしてPBを選択しますので、原則的には（上記の例では）、それは、宣伝する必要はなく、PAの集計の広告は二次として使用されます。実際には、C5は、通常、両方のプロバイダ経由でアドバタイズされます。
Advertisements from "PA" to "BB" will be
「BB」から「PA」からの広告になります
10.24.12.0/22 primary (advertises C4) 10.32.0.0/20 primary (advertises C7) 10.24.0.0/13 primary (advertises remainder of PA)
（PAの残りをアドバタイズ）（C7をアドバタイズ）10.32.0.0/20プライマリ10.24.0.0/13プライマリ（C4をアドバタイズ）主要10.24.12.0/22
For PB, the advertisements must also include C4 and C5, as well as its block of addresses.
PBのために、広告はまた、C4及びC5、並びにアドレスのそのブロックを含まなければなりません。
Advertisements from "PB" to "BB" will be
「BB」から「PB」からの広告になります
10.24.12.0/22 secondary (advertises C4) 10.24.32.0/23 primary (advertises C5) 10.32.0.0/13 primary (advertises remainder of RB)
（RBの残りをアドバタイズ）（C4をアドバタイズ）10.24.12.0/22二次（C5をアドバタイズ）10.24.32.0/23プライマリ10.32.0.0/13プライマリー
To illustrate the problem diagnosis issue mentioned in Section 5.1, consider what happens if PA loses connectivity to C7 (the site that is assigned out of PB's space). In a stateful protocol, PA will announce to BB that 10.32.0.0/20 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 PB (where it will be dropped according to Rule #2) by virtue of PB's less-specific match, 10.32.0.0/13. Although 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 someone trying to debug the outage with "traceroute"). A mechanism to cache such unreachable state might be nice, but it is beyond the scope of this document.
5.1節で述べた問題の診断の問題を説明するために、PAはC7（PBの空間から割り当てられたサイト）への接続を失った場合に何が起こるかを検討してください。ステートフルなプロトコルでは、PAは10.32.0.0/20が到達不能になったことをBBに発表する予定。 BBは、そのルーティングテーブルからこの情報をフラッシュするとき、今、この宛先のためにそれを介して送信された将来のトラフィックはPBの少ない特異的一致によって（それが＃2のルールに従って廃棄されます）PB、10.32に転送されます。 0.0 / 13。これは、（C7は、どのような場合には到達できない）動作上の問題を引き起こすことはありませんが、それは「BB」全体にいくつかの余分なトラフィックを作成しない（とも「トレースルート」で停電をデバッグしようとしている誰かに混乱なるかもしれません）。そのような到達不能状態をキャッシュする仕組みがいいかもしれませんが、それはこのドキュメントの範囲を超えています。
One aspect of Internet services that was notably affected by the move to CIDR was 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, the move to an address assignment plan that uses bitmask-oriented addressing caused some increase in work for those who maintain parts of the IN-ADDR.ARPA zone.
ドメインシステムのIN-ADDR.ARPAゾーン：特にCIDRへの移動の影響を受けたインターネットサービスの一の態様は、アドレスから名前変換のために使用されるメカニズムでした。このゾーンは、唯一のオクテット境界に委任されているので、アドレッシングビットマスク指向を使用してアドレス割り当て計画への移行はIN-ADDR.ARPAゾーンの部分を維持する人のための仕事でいくつかの増加を引き起こしました。
A description of techniques to populate the IN-ADDR.ARPA zone when and used address that blocks that do not align to octet boundaries is described in [RFC2317].
技法の説明はオクテット境界に整列していないブロックは[RFC2317]に記載されているIN-ADDR.ARPAゾーンと使用されるアドレスを移入します。
CIDR was designed to be a short-term solution to the problems of routing state and address depletion on the IPv4 Internet. It does not change the fundamental Internet routing or addressing architectures. It is not expected to affect any plans for transition to a more long-term solution except, perhaps, by delaying the urgency of developing such a solution.
CIDRは、IPv4インターネット上の状態とアドレス枯渇のルーティングの問題への短期的な解決策になるように設計されました。これは、基本的なインターネットルーティングやアドレス指定のアーキテクチャを変更しません。このようなソリューションを開発することの緊急性を遅延させることによって、おそらく、を除いて、より長期的なソリューションへの移行のための計画に影響を与えると予想されていません。
When CIDR was first proposed in the early 1990s, the original authors made some observations about the growth rate of global routing state and offered projections on how CIDR deployment would, hopefully, reduce what appeared to be exponential growth to a more sustainable rate. Since that deployment, an ongoing effort, called "The CIDR Report" [CRPT], has attempted to quantify and track that growth rate. What follows is a brief summary of the CIDR report as of March 2005, with an attempt to explain the various patterns and changes of growth rate that have occurred since measurements of the size of global routing state began in 1988.
CIDRは、最初に1990年代初期に提案された場合には、オリジナルの作者はグローバルルーティング状態の成長率について、いくつかの観測を行い、CIDRの展開は、うまくいけば、より持続可能なレートに指数関数的な成長のように見えるもの削減する方法についての予測を提供しました。その展開以来、「CIDRレポート」と呼ばれる継続的な努力、[CRPT]は、その成長率を定量化し、追跡しようとしています。以下は、グローバルルーティング状態の大きさの測定は1988年に始まって以来、発生した様々なパターンと成長率の変化を説明するための試みで、2005年3月のようCIDRレポートの要約です。
When the graph of "Active BGP Table Entries" [CBGP] is examined, there appear to be several different growth trends with distinct inflection points reflecting changes in policy and practice. The trends and events that are believed to have caused them were as follows:
「アクティブBGPテーブルエントリ」のグラフ[CBGP]が検討されている場合、ポリシーと実践の変化を反映する別個の変曲点を有する複数の異なる成長傾向があるように思われます。次のようにそれらを引き起こしたと考えられているのトレンドやイベントは以下の通りでした。
1. Exponential growth at the far left of the graph. This represents the period of early expansion and commercialization of the former research network, from the late 1980s through approximately 1994. The major driver for this growth was a lack of aggregation capability for transit providers, and the widespread use of legacy Class C allocations for end sites. Each time a new site was connected to the global Internet, one or more new routing entries were generated.
これまでのグラフの左側に1指数関数的成長。これは、この成長の主要なドライバはトランジットプロバイダーのための集約機能の欠如、および終了のため、従来のクラスCの割り当ての普及した1980年代後半から約1994年を通じて、かつての研究ネットワークの早期拡大と商品化の期間を表し、サイト。新しいサイトは、グローバルなインターネットに接続されていたたびに、1つまたは複数の新しいルーティングエントリが生成されました。
2. Acceleration of the exponential trend in late 1993 and early 1994 as CIDR "supernet" blocks were first assigned by the NIC and routed as separate legacy class-C networks by service provider.
CIDR「スーパーネット」ブロックは最初のNICによって割り当てられ、サービスプロバイダによって別々のレガシークラスCのネットワークとしてルーティングされたとして、1993年後半と初期の1994年の指数トレンドの2加速。
3. A sharp drop in 1994 as BGP4 deployment by providers allowed aggregation of the "supernet" blocks. Note that the periods of largest declines in the number of routing table entries typically correspond to the weeks following each meeting of the IETF CIDR Deployment Working Group.
3.「スーパーネット」のブロックの凝集を許さプロバイダによるBGP4の展開として、1994年に急落。ルーティングテーブルのエントリの数の最大減少の期間が、通常、IETF CIDR展開ワーキンググループの各会議以下週に相当します。
4. Roughly linear growth from mid-1994 to early 1999 as CIDR-based address assignments were made and aggregated routes added throughout the network.
CIDRベースのアドレス割り当てには早く1999年半ば1994年4おおよそ線形成長が行われ、集約ルートは、ネットワーク全体を加えました。
5. A new period of exponential growth again from early 1999 until 2001 as the "high-tech bubble" fueled both rapid expansion of the Internet, as well as a large increase in more-specific route advertisements for multi-homing and traffic engineering.
5.「ハイテクバブル」早くも1999年から2001年まで再び指数関数的な成長の新しい時代は、インターネットの急速な拡大だけでなく、マルチホーミングおよびトラフィックエンジニアリングのためのより具体的なルート通知の大幅な増加の両方を煽っ。
6. Flattening of growth through 2001 caused by a combination of the "dot-com bust", which caused many organizations to cease operations, and the "CIDR police" [CPOL] work aimed at improving aggregation efficiency.
6.多くの組織が業務を停止させ、「ドットコム・バスト」の組み合わせによって引き起こされる2001年までの成長の平坦化、および「CIDR警察」の集約効率の向上を目的とした[CPOL]仕事。
7. Roughly linear growth through 2002 and 2003. This most likely represents a resumption of the "normal" growth rate observed before the "bubble", as well as an end to the "CIDR Police" effort.
これは、最も可能性の高い「バブル」のほか、「CIDR警察」の努力の末までに観測され、「正常な」成長率の再開を表し、2002年と2003年を通じて7およそ直線的な成長。
8. A more recent trend of exponential growth beginning in 2004. The best explanation would seem to be an improvement of the global economy driving increased expansion of the Internet and the continued absence of the "CIDR Police" effort, which previously served as an educational tool for new providers to improve aggregation efficiency. There have also been some cases where service providers have deliberately de-aggregated prefixes in an attempt to mitigate security problems caused by conflicting route advertisements (see Section 12). Although this behavior may solve the short-term problems seen by such providers, it is fundamentally non-scalable and quite detrimental to the community as a whole. In addition, there appear to be many providers advertising both their allocated prefixes and all the /24 components thereof, probably due to a lack of consistent current information about recommended routing configuration.
8.最良の説明はインターネットの増加拡大し、以前の教育を務めた「CIDR警察」の努力の継続的な不在を駆動する世界経済の改善であるように見えるでしょう2004年に始まり、指数関数的な成長のより多くの最近の傾向集約効率を改善するための新しいプロバイダのためのツール。また、サービスプロバイダーは（セクション12を参照）ルート通知の競合に起因するセキュリティ上の問題を軽減する試みで、意図的にデ集計プレフィックスを持ついくつかのケースがありました。この動作は、このようなプロバイダーによって見短期的な問題を解決することがありますが、それは基本的に非スケーラブルかつ全体として社会に非常に有害です。また、おそらく推奨ルーティング構成に関する一貫した現在の情報の不足のために、その割り当てられたプレフィックスとそのすべての/ 24のコンポーネントの両方を広告する多くのプロバイダがあるように思われます。
In 1992, when CIDR was first developed, there were serious problems facing the continued growth of the Internet. Growth in routing state complexity and the rapid increase in consumption of address space made it appear that one or both problems would preclude continued growth of the Internet within a few short years.
CIDRが最初に開発された1992年には、インターネットの継続的な成長が直面する深刻な問題がありました。状態の複雑さとアドレス空間の消費量が急速に増加し、ルーティングの成長は、1つのまたは両方の問題は、数年以内に、インターネットの継続的な成長を妨げるように見える作られました。
Deployment of CIDR, in combination with BGP4's support for carrying classless prefix routes, alleviated the short-term crisis. It was only through a concerted effort by both the equipment manufacturers and the provider community that this was achieved. The threat (and, perhaps in some cases, actual implementation of) charging networks for advertising prefixes may have offered an additional incentive to share the address space, and thus the associated costs of advertising routes to service providers.
CIDRの展開は、クラスレスプレフィックスルートを運ぶためのBGP4のサポートと組み合わせて、短期的な危機を緩和します。これは、これが達成されたことを機器メーカーやプロバイダのコミュニティの両方による協調努力を通じてのみでした。脅威（とは、おそらくいくつかのケースでは、実際の実装）の広告プレフィックスのためのネットワークを充電するには、アドレス空間を共有するための追加のインセンティブを提供していること、およびサービス・プロバイダへのルートのアドバタイズのため、関連するコスト。
The IPv4 routing system architecture carries topology information based on aggregate address advertisements and a collection of more-specific advertisements that are associated with traffic engineering, multi-homing, and local configuration. As of March 2005, the base aggregate address load in the routing system has some 75,000 entries.
IPv4ルーティングシステムアーキテクチャは、集約アドレス広告およびトラフィックエンジニアリング、マルチホーミング、およびローカルコンフィギュレーションに関連付けられているより多くの固有の広告の収集に基づいて、トポロジ情報を運びます。 2005年3月の時点で、ルーティングシステムの基地集約アドレスの負荷は、いくつかの75,000のエントリがあります。
Approximately 85,000 additional entries are more specific entries of this base "root" collection. There is reason to believe that many of these additional entries exist to solve problems of regional or even local scope and should not need to be globally propagated.
約85,000の追加のエントリは、このベースは「root」コレクションのより具体的なエントリです。これらの追加項目の多くは、地域、あるいはローカルスコープの問題を解決するために存在しており、世界的に伝播する必要はないことを信じる理由があります。
An obvious question to ask is whether CIDR can continue to be a viable approach to keeping global routing state growth and address space depletion at sustainable rates. Recent measurements indicate that exponential growth has resumed, but further analysis suggests that this trend can be mitigated by a more active effort to educate service providers as to efficient aggregation strategies and proper equipment configuration. Looking farther forward, there is a clear need for better multi-homing technology that does not require global routing state for each site and for methods of performing traffic load balancing that do not require adding even more state. Without such developments and in the absence of major architectural change, aggregation is the only tool available for making routing scale in the global Internet.
依頼する明白な疑問は、CIDRは、持続可能なレートでグローバルルーティング状態の成長とアドレス空間の枯渇を維持する実行可能なアプローチであり続けることができるかどうかです。最近の測定値は、指数関数的な成長が再開したことを示しているが、さらなる分析は、この傾向は、効率的な集約戦略と適切な機器構成にように、サービスプロバイダを教育するためのより積極的な努力によって緩和することができることを示唆しています。遠く楽しみにして、各サイトのために、さらに状態を追加する必要はありませんトラフィックの負荷分散を行う方法のためのグローバルルーティング状態を必要としない優れたマルチホーミング技術が明らかに必要です。こうした進展がなければ、主要なアーキテクチャの変更がない場合には、集約は、グローバルなインターネットにルーティングスケールを作るために利用できる唯一のツールです。
This memo renders obsolete and requests re-classification as Historic the following RFCs describing CIDR usage and deployment:
このメモは時代遅れレンダリングとCIDRの使用状況や展開を記述する歴史次のRFCとして再分類を要求します。
o RFC 1467: Status of CIDR Deployment in the Internet
O RFC 1467：インターネットでのCIDR展開の状況
This Informational RFC described the status of CIDR deployment in 1993. As of 2005, CIDR has been thoroughly deployed, so this status note only provides a historical data point.
この情報のRFCは、2005年、1993年にCIDR展開の状況を説明し、CIDRは徹底的に展開されているので、この状態のノートは過去のデータポイントを提供します。
o RFC 1481: IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling
OのRFC 1481：スケーリングの問題に対処するために、中間の戦略のためのIAB勧告
This very short Informational RFC described the IAB's endorsement of the use of CIDR to address scaling issues. Because the goal of RFC 1481 has been achieved, it is now only of historical value.
この非常に短い情報のRFCは、スケーリングの問題に対処するためにCIDRの使用のIABの承認を説明しました。 RFC 1481の目標が達成されたので、それが唯一の歴史的な価値が今です。
o RFC 1482: Aggregation Support in the NSFNET Policy-Based Routing Database
OのRFC 1482：NSFNETポリシーベースルーティングデータベースの集約サポート
This Informational RFC describes plans for support of route aggregation, as specified by CIDR, on the NSFNET. Because the NSFNET has long since ceased to exist and CIDR has been ubiquitously deployed, RFC 1482 now only has historical relevance.
NSFNETに、CIDRで指定されたように、この情報のRFCは、ルート集約をサポートするための計画を説明しています。 NSFNETが長く以来消滅したとCIDRは、普遍的に展開されているので、RFC 1482には、今は歴史的な関連性を持っています。
o RFC 1517: Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)
OのRFC 1517：クラスレスドメイン間ルーティング（CIDR）の実装のための適用性に関する声明
This Standards Track RFC described where CIDR was expected to be required and where it was expected to be (strongly) recommended. With the full deployment of CIDR on the Internet, situations where CIDR is not required are of only historical interest.
この標準化過程のRFCは、CIDRが必要とされることが期待された場合について説明し、それがあることが予想された場所（強く）お勧めします。インターネット上のCIDRの完全な展開では、CIDRが必要とされていない状況では、唯一の歴史的な関心があります。
o RFC 1518: An Architecture for IP Address Allocation with CIDR
OのRFC 1518：CIDRとのIPアドレス割り当てのためのアーキテクチャ
This Standards Track RFC discussed routing and address aggregation considerations at some length. Some of these issues are summarized in this document in section Section 3.1. Because address assignment policies and procedures now reside mainly with the RIRs, it is not appropriate to try to document those practices in a Standards Track RFC. In addition, [RFC3221] also describes many of the same issues from point of view of the routing system.
この標準化過程のRFCは、いくつかの長さで、ルーティングおよびアドレス集約考慮事項について議論しました。これらの問題のいくつかは、セクション3.1節で、この文書にまとめられています。アドレス割り当て方針と手順は、現在のRIRで主に存在するため、標準化過程のRFCでこれらのプラクティスを文書化しようとすることは適切ではありません。また、[RFC3221]は、ルーティングシステムの観点から同じ問題の多くを説明しています。
o RFC 1520: Exchanging Routing Information Across Provider Boundaries in the CIDR Environment
OのRFC 1520：CIDR環境でのプロバイダの境界を越えてルーティング情報を交換します
This Informational RFC described transition scenarios where CIDR was not fully supported for exchanging route information between providers. With the full deployment of CIDR on the Internet, such scenarios are no longer operationally relevant.
この情報のRFCは、CIDRが完全プロバイダ間の経路情報を交換するためにサポートされなかった遷移シナリオを記載しました。インターネット上のCIDRの完全な展開では、このようなシナリオは、もはや運用関連していません。
o RFC 1817: CIDR and Classful Routing
OのRFC 1817：CIDRとクラスフルルーティング
This Informational RFC described the implications of CIDR deployment in 1995; it notes that formerly-classful addresses were to be allocated using CIDR mechanisms and describes the use of a default route for non-CIDR-aware sites. With the full deployment of CIDR on the Internet, such scenarios are no longer operationally relevant.
この情報のRFCは1995年にCIDR展開の意味を説明しました。それは、以前は、クラスフルアドレスがCIDRのメカニズムを使用して割り当てられ、非CIDR対応のサイトのデフォルトルートを使用することを記載するようにしたことを指摘しています。インターネット上のCIDRの完全な展開では、このようなシナリオは、もはや運用関連していません。
o RFC 1878: Variable Length Subnet Table For IPv4
O RFC 1878：IPv4の可変長サブネット表
This Informational RFC provided a table of pre-calculated subnet masks and address counts for each subnet size. With the incorporation of a similar table into this document (see Section 3.1), it is no longer necessary to document it in a separate RFC.
この情報のRFCは、各サブネットのサイズのために事前に計算されたサブネットマスクとアドレス数のテーブルを提供します。このドキュメント（セクション3.1を参照）に類似したテーブルの取り込みと、別のRFCでそれを文書化する必要がなくなりました。
o RFC 2036: Observations on the use of Components of the Class A Address Space within the Internet
OのRFC 2036：アドレス空間インターネット内のクラスのコンポーネントの使用に関する考察
This Informational RFC described several operational issues associated with the allocation of classless prefixes from previously-classful address space. With the full deployment of CIDR on the Internet and more than half a dozen years of experience making classless prefix allocations out of historical "Class A" address space, this RFC now has only historical value.
この情報のRFCは、以前にクラスフルアドレス空間からクラスレスプレフィックスの割り当てに関連するいくつかの操作上の問題を説明しました。完全なインターネット上のCIDRの展開と経験の半分以上十数年は、歴史的な「クラスA」のアドレス空間のうち、クラスレスプレフィックスの割り当てを行うことで、このRFCは現在、唯一の歴史的価値を持っています。
The introduction of routing protocols that support classless prefixes and a move to a forwarding model that mandates that more-specific (longest-match) routes be preferred when they overlap with routes to less-specific prefixes introduces at least two security concerns:
クラスレスプレフィックスをサポートするルーティングプロトコルの導入と、それらがルートと重なる場合に、より特異的（最長一致）ルートが好まれることが義務付け転送モデルに移動するあまり特異的プレフィクスは、少なくとも2つのセキュリティ上の懸念が導入されています。
1. Traffic can be hijacked by advertising a prefix for a given destination that is more specific than the aggregate that is normally advertised for that destination. For example, assume that a popular end system with the address 192.168.17.100 is connected to a service provider that advertises 192.168.16.0/20. A malicious network operator interested in intercepting traffic for this site might advertise, or at least attempt to advertise, 192.168.17.0/24 into the global routing system. Because this prefix is more specific than the "normal" prefix, traffic will be diverted away from the legitimate end system and to the network owned by the malicious operator. Prior to the advent of CIDR, it was possible to induce traffic from some parts of the network to follow a false advertisement that exactly matched a particular network number; CIDR makes this problem somewhat worse, since longest-match routing generally causes all traffic to prefer more-specific routes over less-specific routes. The remedy for the CIDR-based attack, though, is the same as for a pre-CIDR-based attack: establishment of trust relationships between providers, coupled with and strong route policy filters at provider borders. Unfortunately, the implementation of such filters is difficult in the highly de-centralized Internet. As a workaround, many providers do implement generic filters that set upper bounds, derived from RIR guidelines for the sizes of blocks that they allocate, on the lengths of prefixes that are accepted from other providers. Note that "spammers" have been observed using this sort of attack to hijack address space temporarily in order to hide the origin of the traffic ("spam" email messages) that they generate.
1.トラフィックは通常、その先のために宣伝されて集計より具体的である特定の宛先のプレフィックスを広告することでハイジャックすることができます。例えば、アドレス192.168.17.100に人気のエンドシステムが192.168.16.0/20をアドバタイズし、サービスプロバイダに接続されていることを前提としています。このサイトのトラフィックを傍受することに興味悪意のあるネットワークオペレータは、広告を掲載、またはグローバルルーティングシステムに広告を掲載するには、少なくとも試み、192.168.17.0/24かもしれません。このプレフィックスは、「通常の」接頭辞よりも具体的であるため、トラフィックは、正当なエンドシステムから悪意のあるオペレータが所有するネットワークに離れ転用されます。 CIDRの到来する前に、正確に特定のネットワーク番号と一致したことを虚偽広告を追跡するために、ネットワークのいくつかの部分からのトラフィックを誘導することが可能でした。最長一致ルーティングは一般的にあまり固有の経路をより固有のルートを好むために、すべてのトラフィックが発生するので、CIDRは、この問題はやや悪化させます。プロバイダの境界でと相まってプロバイダ、および強力なルートポリシーフィルタの間の信頼関係の確立：CIDRベースの攻撃のための救済策は、しかし、事前にCIDRベースの攻撃の場合と同じです。残念ながら、このようなフィルタの実装は非常にデ集中型のインターネットでは困難です。回避策として、多くのプロバイダは、他のプロバイダーから受け入れられるプレフィックスの長さに、彼らは割り当てブロックのサイズのRIRガイドライン由来上限を、設定、一般的なフィルタを実装します。 「スパマーは」彼らが生成するトラフィック（「スパム」電子メールメッセージ）の起源を隠すために、一時的なアドレス空間をハイジャックするために、この種の攻撃を使用して観察されていることに注意してください。
2. Denial-of-service attacks can be launched against many parts of the Internet infrastructure by advertising a large number of routes into the system. Such an attack is intended to cause router failures by overflowing routing and forwarding tables. A good example of a non-malicious incident that caused this sort of failure was the infamous "AS 7007" event [7007], where a router mis-configuration by an operator caused a huge number of invalid routes to be propagated through the global routing system. Again, this sort of attack is not really new with CIDR; using legacy Class A/B/C routes, it was possible to advertise a maximum of 16843008 unique network numbers into the global routing system, a number that is sufficient to cause problems for even the most modern routing equipment made in 2005. What is different is that the moderate complexity of correctly configuring routers in the presence of CIDR tends to make accidental "attacks" of this sort more likely. Measures to prevent this sort of attack are much the same as those described above for the hijacking, with the addition that best common practice is also to configure a reasonable maximum number of prefixes that a border router will accept from its neighbors.
2.サービス拒否攻撃は、システムに多数のルートを広告することにより、インターネットインフラストラクチャの多くの部分に対して起動することができます。このような攻撃は、ルーティングおよび転送テーブルをオーバーフローにより、ルータの障害を引き起こすことを意図しています。故障のこの種の原因となった悪意のない入射の好例であった悪名高いオペレータによるルータの設定ミスが無効経路の膨大な数は、グローバルルーティングを伝搬させるイベント[7007]、「7007 AS」システム。ここでも、この種の攻撃は本当にCIDRと新しいものではありません。レガシークラスA / B / Cのルートを使用して、グローバルルーティングシステムに16843008のユニークなネットワーク番号の最大値を宣伝することができた、十分な数とは何が違う2005年に作られたとしても最も近代的なルーティング機器に問題が発生します正しくCIDRの存在下でルータの設定の適度な複雑さは、この種の偶然の「攻撃は」可能性が高いにする傾向があるということです。この種の攻撃を防ぐための対策は、最高の一般的な方法は、境界ルータはそのネイバーから受け入れるプレフィックスの合理的な最大数を設定することもあるほかに、ハイジャックと同様のものくらいです。
Note that this is not intended to be an exhaustive analysis of the sorts of attacks that CIDR makes easier; a more comprehensive analysis of security vulnerabilities in the global routing system is beyond the scope of this document.
これは、CIDRが容易になり、攻撃の種類の網羅解析することを意図するものではないことに注意してください。グローバルルーティングシステムにおけるセキュリティの脆弱性のより包括的な分析は、このドキュメントの範囲を超えています。
The authors wish to express appreciation to the other original authors of RFC 1519 (Kannan Varadhan, Jessica Yu); to the ROAD group, with whom many of the ideas behind CIDR were inspired and developed; and to the early reviewers of this re-spun version of the document (Barry Greene, Danny McPherson, Dave Meyer, Eliot Lear, Bill Norton, Ted Seely, Philip Smith, Pekka Savola), whose comments, corrections, and suggestions were invaluable. We would especially like to thank Geoff Huston for contributions well above and beyond the call of duty.
著者らは、RFC 1519（Kannan Varadhan、ジェシカ・ユー）の他の元の作者に感謝の意を表したいです。 CIDRの背後にあるアイデアの多くが触発して開発された誰とROADグループ、へ。そして、コメント、修正、および提案は非常に貴重だった文書（バリー・グリーン、ダニー・マクファーソン、デイブ・マイヤー、エリオット・リア、ビル・ノートン、テッド・シーリー、フィリップ・スミス、ペッカSavola）、この再紡糸バージョンの早期審査します。私たちは、特によく上記と義務の呼び出しを超えた貢献のためのジェフ・ヒューストンに感謝したいと思います。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[7007] "NANOG mailing list discussion of the "AS 7007" incident", <http://www.merit.edu/mail.archives/nanog/1997-04/ msg00340.html>.
7007 AS "事件 " <http://www.merit.edu/mail.archives/nanog/1997-04/ msg00340.html> [7007]" のNANOGメーリングリストの議論"。
[CBGP] "Graph: Active BGP Table Entries, 1988 to Present", <http://bgp.potaroo.net/as4637/>.
[CBGP] "グラフ：アクティブBGPテーブルエントリ1988が存在する"、<http://bgp.potaroo.net/as4637/>。
[CPOL] "CIDR Police - Please Pull Over and Show Us Your BGP", <http://www.nanog.org/mtg-0302/cidr.html>.
[CPOL] "CIDR警察は - オーバープルしてください、私達にあなたのBGPを表示"、<http://www.nanog.org/mtg-0302/cidr.html>。
[CRPT] "The CIDR Report", <http://www.cidr-report.org/>.
[CRPT] "CIDRレポート"、<http://www.cidr-report.org/>。
[IANA] "Internet Assigned Numbers Authority", <http://www.iana.org>.
[IANA] "インターネット割り当て番号機関"、<http://www.iana.org>。
[LWRD] "The Long and Winding Road", <http://rms46.vlsm.org/1/42.html>.
[LWRD] "長く曲がりくねった道"、<http://rms46.vlsm.org/1/42.html>。
[NRO] "Number Resource Organization", <http://www.nro.net>.
[NRO] "ナンバーリソース編成"、<http://www.nro.net>。
[RFC904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1 1984.
[RFC904]ミルズ、D.、 "エクステリアゲートウェイプロトコル形式仕様"、RFC 904、1984年4月1日。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RFC1058]ヘドリック、C.、 "ルーティング情報プロトコル"、RFC 1058、1988年6月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, June 1992.
[RFC1338]フラー、V.、李、T.、ゆう、J.、およびK. Varadhan、 "スーパーネッティング：アドレス割り当ておよび集約戦略"、RFC 1338、1992年6月。
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992.
[RFC1380]グロス、P.およびP. Almquist、 "IESGルーティングの審議とアドレッシング"、RFC 1380、1992年11月。
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[RFC1518] Rekhter、Y.とT.李、 "CIDRとのIPアドレスの割り当てのためのアーキテクチャ"、RFC 1518、1993年9月。
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[RFC1519]フラー、V.、李、T.、ゆう、J.、およびK. Varadhan、 "クラスレスドメイン間ルーティング（CIDR）：アドレス割り当ておよび集約戦略"、RFC 1519、1993年9月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
[RFC2317] Eidnes、H.、デ・グルート、G.、およびP.いるVixie、 "クラスレスIN-ADDR.ARPA委任"、BCP 20、RFC 2317、1998年3月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453]マルキン、G.、 "RIPバージョン2"、STD 56、RFC 2453、1998年11月。
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, December 2000.
[RFC3021] Retana、A.、ホワイト、R.、フラー、V.、および、RFC 3021、2000年12月、 "IPv4のポイントツーポイントリンク上で31ビットのプレフィックスを使用する" D.マクファーソン、。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221]ヒューストン、G.、 "インターネットにおけるドメイン間ルーティングの解説"、RFC 3221、2001年12月。
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005.
[RFC4116] Abley、J.、Lindqvist、K.、デイビス、E.、ブラック、B.、およびV.ギル、 "IPv4のマルチホーミングプラクティスと制限"、RFC 4116、2005年7月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RIPE] "RIPE Network Coordination Centre", <http://www.ripe.net>.
[RIPE] "RIPEネットワークコーディネーションセンター"、<http://www.ripe.net>。
Authors' Addresses
著者のアドレス
Vince Fuller 170 W. Tasman Drive San Jose, CA 95134 USA
ビンスフラー170 W.タスマン・ドライブサンノゼ、CA 95134 USA
EMail: vaf@cisco.com
メールアドレス：vaf@cisco.com
Tony Li 555 Del Rey Avenue Sunnyvale, CA 94085
トニー・リー555デルレイアベニューサニーベール、CA 94085
Email: tli@tropos.com
メール：tli@tropos.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。