[要約] RFC 4632はCIDR（Classless Inter-domain Routing）に関する規格であり、インターネットアドレスの割り当てと集約計画を定めています。このRFCの目的は、効率的なアドレス割り当てとルーティングの実現を促進することです。
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
クラスレスインタードメインルーティング（CIDR）：インターネットアドレスの割り当てと集約計画
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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アドレス空間のアドレス割り当ての戦略について説明します。このドキュメントは、RFC 1519の元のクラスレスドメイン間ルーティング（CIDR）仕様を廃止し、導入された概念を明確にするための変更と、12年以上後、記述された技術の展開結果についてインターネットコミュニティを更新するために変更されました。
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アドレス空間のアドレス割り当ての戦略について説明します。このドキュメントは、元のCIDR仕様[RFC1519]を廃止し、導入された概念を明確にするための変更と、12年以上後、記述された技術の展開結果についてインターネットコミュニティを更新する両方の変更が行われました。
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（最も重要なアドレスビット '00'）、それぞれ128の可能なネットワークと1677216エンドシステム（ネットワーク/ブロードキャストアドレス用に予約された特別なビット値を差し引いたもの）;クラスB（MSB '10'）、16384の可能性のあるネットワークはそれぞれ65536エンドシステム（予約値が少ない）を備えています。クラス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: 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.
1980年代後半、以前の研究ネットワークの拡大と商業化により、急速に成長するインターネットに多くの新しい組織が関連付けられ、新しい組織ごとにクラスA/B/Cアドレス指定計画に従って住所の割り当てが必要でした。新しいネットワーク番号の需要（特にクラスBスペース）が指数関数的な成長率と思われるものを取得したため、運用およびエンジニアリングコミュニティの一部のメンバーは、クラスA/B/の長期的なスケーリング特性について懸念を抱き始めました。Cシステムと、成長に対応するためにネットワーク番号の割り当てポリシーとルーティングプロトコルを変更する方法について考え始めました。1991年11月、インターネットエンジニアリングタスクフォース（IETF）は、状況を調べるために道路（ルーティングとアドレス指定）グループを作成しました。このグループは1992年1月に会い、次の3つの主要な問題を特定しました。1。クラスBネットワークアドレス空間の消耗。この問題の根本的な原因の1つは、中規模の組織に適したサイズのネットワーククラスの欠如です。最大254のホストアドレスを持つクラスCは小さすぎますが、最大65534のホストアドレスを許可するクラスBは、ほとんどの組織では大きすぎますが、サブネットで使用できる最適なフィットでした。
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 IPv4 address space.
3. 32ビットIPv4アドレス空間の最終的な消耗。
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].
当時のインターネット成長率は、1993年から1995年の間に最初の2つの問題が重要になることは明らかでした。1990年12月のボルダーIETFは、32ビットのIPv4アドレススペースを再構築して寿命を延ばす方法について考えました。道路群での作業が続き、最終的には[RFC1338]の公開が発表され、後に[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アドレス空間の消費率を減らすメカニズムを提供することにより、これらの問題を解決することを目的としていました。それは、より長期的な性質の3番目の問題を解決しようとせず、試みませんでした。代わりに、長期的なソリューションで進行中にインターネットが効率的に機能し続けるために、短期的から中期的な困難を十分に緩和するよう努めています。
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ネットワークアドレスの割り当てシステムを非難することでした。接頭辞の割り当ては、グローバルルーティングシステムのスケーリングを容易にするために集約を使用できるように、基礎となるインターネットトポロジを大まかに追跡することを目的としています。この戦略の意味の1つは、インターネットトポロジの決定方法であるため、プレフィックスの割り当てと集約が一般にプロバイダーサブスクリバーの関係に従って行われることです。
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」スペースの部分の再割り当てを必要とせず、想定していないことに注意してください（「沼地」と呼ばれることもあります）。そうすることで、ルーティングテーブルのサイズがいくらか削減されます（現在の推定では、「The Swamp」には約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表記では、従来のIPv4アドレスまたはネットワーク番号のように、4オクテット数量としてプレフィックスが表示され、その後に「/」（スラッシュ）文字が続き、その後に0〜32の小数値が続きます。重要なビット。
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」として定義されます。接頭辞は32ビット値で、最も重要な16ビットは1つであり、最も重要な16ビットはゼロです。同様に、レガシー「クラスC」ネットワーク番号192.168.99.0は、プレフィックス192.168.99.0/24として定義されています。最も重要な24ビットは1つであり、最も重要な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).
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.
「割り当て」と「割り当て」という用語は、インターネットアドレスレジストリシステムに特定の意味を持つことに注意してください。「Allocate」とは、アドレススペースのブロックの委任を、さらにサブディレージゼーションを実行することが期待される組織への委任を指し、「割り当て」は、受け取ったアドレスのブロックを直接使用する（つまり、個々のホストを数）使用するサイトに使用されます。
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:
次の表は、すべてのCIDRプレフィックスサイズの便利なショートカットを示します。各プレフィックスで可能なアドレスの数と、32ビットIPv4アドレス空間で番号が付けられる可能性のあるそのサイズのプレフィックス数を示します。
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がグローバルルーティングシステムのサイズと成長率を削減することに成功するためには、Topological Lineに沿ったルーティング情報の集約を可能にするために、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.
集約は、1つのサービスプロバイダーに接続されているエンドサイトの場合は簡単です。サービスプロバイダーによって割り当てられたアドレススペースを使用し、アドレススペースはサービスプロバイダーに割り当てられたより大きなブロックの小さな部分です。エンドサイトには明示的なルートは必要ありません。サービスプロバイダーは、より大きなブロック用の単一の集計ルートを宣伝しています。この広告は、ブロック内に番号が付けられたすべての顧客に到達可能性と範囲を提供します。
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つの比較的小さなプロバイダーにマルチホームされている場合、小規模なネットワークからのルートの大規模なプロバイダーによる集約には、マルチホームサイトへのすべてのルートが含まれます。。この種の第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年代にインターネットが急速に拡大し始めたため、単一の集中住所の割り当て機関に問題があることが明らかになりました。この機能は、ヨーロッパのインターネットサイトの住所スペースの割り当てが16777216アドレス（後にA /8として定義するもの）のビットアライメントブロック（[熟した]）（[熟した））のビットアライメントブロックに委任され、効果的にそれを委任されたときに分離され始めました。最初のRIRS。それ以来、アドレスの割り当ては、IANA、RIRS、およびサービスプロバイダーとの階層機能として正式に分散されています。グローバルなインターネットアドレススペースに責任を負う単一の組織のボトルネックを削除すると、新しい割り当ての効率と応答時間が大幅に改善されました。
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 Enhanced Interior Gateway Protocol（EIGRP）、およびBGP4 Exterior Routing Reading Rearting Reading Protocol [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]、Hello、Cisco Interior Gateway Routing Protocol（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. 複数のより特異的なルートの集約ルートを生成するルーターは、集計ルートに一致するパケットを破棄する必要がありますが、より固有のルートはありません。言い換えれば、集約ルートの「次のホップ」はヌルの宛先でなければなりません。これは、骨材でカバーされているいくつかのアドレスが到達できない場合に転送ループを防ぐために必要です。
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.
障害中、あるサービスプロバイダーからアドレススペースを取得するサイトへのトラフィックの部分的なルーティングは、実際には別のサービスプロバイダー（つまり、サービスプロバイダーを変更したサイトの場合）を介してのみ到達できます。集約されたルートによって宣伝されたパスに沿って転送されます。ルール＃2は、そのようなトラフィックを集計ルートの広告主によって廃棄することによりパケットの誤配信を防ぎますが、「traceroute」およびその他の同様のツールの出力は、NOのネットワークではなくそのネットワーク内に問題が存在することを示唆します。より固有のプレフィックスをより長く宣伝します。これは、接続性の問題を診断しようとしている人と混乱する可能性があります。詳細については、セクション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は、使用される転送アルゴリズムがルーティングプロトコルと実装間で一貫していることを保証します。マルチホームネットワークは、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つに一致する目的地のより固有のルートに従うことはできないと述べています（通常、これは、すべての集計された接頭辞の「廃棄」または「null」ルートをインストールすることによって実装されます。あるネットワークは別のネットワークに宣伝します）。「デフォルト」ルート（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.16.0.0 Accept 172.25.120.0.0 Accept 172.31.0.0拒否10.2.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 Accept 172.25.0.0/16 Accept 172.31.0.0/16拒否10.2.0.0/16
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は集約責任を別の人に委任したいと思うかもしれません（たとえば、顧客は、サービスプロバイダーが集計されたルーティング情報をその代わりに生成することを望む場合があります）。そのような場合、集約は、最初から受け取るルートに従って、それらのルートを集約する方法を説明する構成されたポリシー情報と組み合わせるため、2番目のルーターによって実行されます。
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.
あるプロバイダーは、明示的な合意なしに他のルートから受け取ったルートで集約を実行することを選択できることに注意してください。これは「プロキシ集約」と呼ばれます。これは、ASが顧客や隣人に持ち運び、伝播しなければならないルーティング状態の量を減らすための便利なツールになります。ただし、プロキシ集約は、交通工学に意図しない結果をもたらす可能性もあります。AS 2と3の両方がAS 1からルートを受け取るが、2がプロキシ集約を実行する場合、3が3がない場合に何が起こるかを考えてください。AS 2と3の両方からトランジットルーティング情報を受け取る他のASは、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アドレスのブロックの範囲を定義する1つまたは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の元の展開の前に、一般的な慣行は、外部ルーティングプロトコル（EGPまたはBGP）を介して学習したルートをサイトのインテリアルーティングプロトコル（通常、OSPF、IS-IS、またはRIP）を介して伝播することでした。これは、これらのプロトコルを介して学習した宛先にトラフィックを送信するために、一貫した正しい出口ポイントが選択されたことを保証するために行われました。4つの進化効果 - CIDRの出現、グローバルルーティング状態の爆発的な成長、BGP4の広範な採用、およびフルパス情報を伝播するための要件 - は、その実践を非難するために組み合わされています。適切なパスの伝播を確保し、ルーティング間の矛盾を防ぐため（BGP4のループ検出メカニズムにはフルパス伝播が必要です）、トランジットネットワークは、ネットワーク内とネットワーク内の両方で他のプロバイダーから学習したルートを運ぶために内部BGP（IBGP）を使用する必要があります。
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.
10.24.0.0で始まり、10.31.255.255で終了する524288（2^19）アドレスのブロックを考えてください。単一のネットワークプロバイダー「PA」に割り当てられます。これは、2048年のレガシー「クラスC」ネットワーク番号（または /24）のブロックに相当するサイズです。このブロックへのクラスレスルートは、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)
このサービスプロバイダーは、6つのサイトを次の順序で接続していると仮定します（サービスプロバイダーのアドレススペースで一時的な「穴」がどのように形成されるかを示すため、重要です）：o "c1"は2048年未満のアドレス（ /21または8 x /24を必要とします））
o "C2", requiring fewer than 4096 addresses (/20 or 16 x /24)
o 「C2」、4096未満のアドレス（ /20または16 x /24）が必要です
o "C3", requiring fewer than 1024 addresses (/22 or 4 x /24)
o 「C3」、1024未満のアドレス（ /22または4 x /24）が必要です
o "C4", requiring fewer than 1024 addresses (/22 or 4 x /24)
o 「C4」、1024未満のアドレス（ /22または4 x /24）が必要です
o "C5", requiring fewer than 512 addresses (/23 or 2 x /24)
o 「C5」、512未満のアドレス（ /23または2 x /24）が必要です
o "C6", requiring fewer than 512 addresses (/23 or 2 x /24)
o 「C6」、512未満のアドレス（ /23または2 x /24）が必要です
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).
o C1。10.24.0から10.24.7を割り当てます。ネットワークのこのブロックは、ルート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).
o C2。10.24.16から10.24.31を割り当てます。このブロックは、ルート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).
o C3。10.24.8から10.24.11を割り当てます。このブロックは、ルート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).
o C4。10.24.12から10.24.15を割り当てます。このブロックは、ルート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).
o C5。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).
o C6。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を使用する場合、すべて /24の明示的なルートを運ぶ必要があります。
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.
この例をより現実的にするために、C4とC5が他のいくつかのサービスプロバイダー「PB」を通じてマルチホームされていると仮定します。さらに、「RB」に接続されていたが、「PA」に移動したサイト「C7」の存在をさらに仮定します。このため、（次の）2048 X /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).
o C7。10.32.0から10.32.15を割り当てます。このブロックは、ルート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が「RA」と「RB」を介して二次的にプライマリとして宣伝されていると仮定します。そして、そのC5は「RB」を介してプライマリであり、「RA」を介してセカンダリです。さらに、「RA」と「RB」が両方とも同じトランジットサービスプロバイダー「BB」に接続されていると仮定します。
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
「PA」から「BB」までの広告は
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)
10.24.12.0/22プライマリ（広告C4）10.32.0.0/20プライマリ（広告C7）10.24.0.0/13プライマリ（PAの残りの残りを宣伝）
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
「PB」から「BB」から「
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)
10.24.12.0/22セカンダリ（広告C4）10.24.32.0/23プライマリ（広告C5）10.32.0.0/13プライマリ（RBの残りの残りを宣伝）
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の特異性の低い一致のためにPB（ルール＃2に従ってドロップされます）に転送されます。0.0/13。これは運用上の問題を引き起こすことはありません（C7はいずれにもしても到達できません）、「BB」全体に余分なトラフィックを作成します（また、「Traceroute」で停止をデバッグしようとする人と混同することも証明されます）。このような到達不能な状態をキャッシュするメカニズムは良いかもしれませんが、このドキュメントの範囲を超えています。
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.
CIDRへの移行によって特に影響を受けたインターネットサービスの1つの側面は、アドレス間翻訳に使用されるメカニズムであるドメインシステムのIn-Addr.Arpaゾーンです。このゾーンはOctetの境界のみに委任されているため、ビットマスク指向のアドレス指定を使用するアドレス割り当て計画への移動により、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].
Octetの境界に沿っていないブロックが[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]と呼ばれる継続的な努力は、その成長率を定量化して追跡しようとしました。以下は、2005年3月現在のCIDRレポートの簡単な要約であり、1988年にグローバルルーティング状態の規模の測定が開始されて以来発生した成長率のさまざまなパターンと変化を説明しようとしました。
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:
「Active 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. グラフの左端にある指数関数的な成長。これは、1980年代後半から1994年の約1994年までの以前の研究ネットワークの早期拡大と商業化の期間を表しています。この成長の主な要因は、輸送プロバイダーにとっての集約能力の欠如であり、終了のためのレガシークラスC割り当ての広範な使用を表しています。サイト。新しいサイトがグローバルインターネットに接続されるたびに、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.
2. CIDR「スーパーネット」ブロックとしての1993年後半から1994年初頭の指数トレンドの加速は、最初にNICによって割り当てられ、サービスプロバイダーによって個別のレガシークラスCネットワークとしてルーティングされました。
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.
4. CIDRベースのアドレスの割り当てが行われ、ネットワーク全体に集約されたルートが追加されたため、1994年半ばから1999年初頭までのほぼ線形成長が行われました。
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. 多くの組織が事業を停止した「ドットコムバスト」の組み合わせと、集約効率の向上を目的とした「CIDR警察」[CPOL]作業によって引き起こされた2001年までの成長の平坦化。
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.
7. これは、2002年と2003年までのほぼ直線的な成長を表している可能性が最も高く、「バブル」の前に観察された「通常の」成長率の再開と、「CIDR警察」の努力の終わりを表しています。
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. 2004年に始まる指数関数的成長のより最近の傾向。最良の説明は、インターネットの拡大を促進する世界経済の改善と「CIDR警察」の努力の継続的な不在であると思われます。集約効率を改善するための新しいプロバイダー。また、競合するルート広告によって引き起こされるセキュリティの問題を軽減するために、サービスプロバイダーが意図的に凝集したプレフィックスを装備している場合もあります（セクション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.
1992年、CIDRが最初に開発されたとき、インターネットの継続的な成長に直面している深刻な問題がありました。ルーティング状態の複雑さの成長と住所スペースの消費の急速な増加により、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の追加エントリは、このベースの「ルート」コレクションのより具体的なエントリです。これらの追加のエントリの多くが、地域または地域の範囲の問題を解決するために存在し、グローバルに伝播する必要はないと信じる理由があります。
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は、1993年のCIDR展開のステータスを説明しました。2005年現在、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.
この情報RFCは、NSFNETでCIDRによって指定されているルート集約のサポートの計画について説明しています。NSFNETは長い間存在しなくなり、CIDRは遍在的に展開されてきたため、RFC 1482には歴史的な関連性しかありません。
o RFC 1517: Applicability Statement for the Implementation of Classless Inter-Domain Routing (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.
o RFC 1517：クラスレス間ドメインルーティング（CIDR）の実装のための適用可能性声明この標準トラック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.
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：インターネット内のクラスAアドレス空間のコンポーネントの使用に関する観察
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. システムへの多数のルートを宣伝することにより、インターネットインフラストラクチャの多くの部分に対してサービス拒否攻撃を開始できます。このような攻撃は、ルーティングと転送のテーブルをオーバーフローすることにより、ルーターの故障を引き起こすことを目的としています。この種の障害を引き起こした非悪意のある事件の良い例は、悪名高い「As 7007」イベント[7007]でした。ここでは、オペレーターによるルーターの誤った構成により、グローバルルーティングを通じて膨大な数の無効なルートが伝播されました。システム。繰り返しますが、この種の攻撃はCIDRではまったく新しいものではありません。レガシークラスA/B/Cルートを使用して、最大16843008の一意のネットワーク番号をグローバルルーティングシステムに宣伝することができました。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、Jessica Yu）の他の元の著者に感謝を表明したいと考えています。CIDRの背後にある多くのアイデアがインスピレーションと発展した道路グループに。そして、この再スパンバージョンの文書（バリー・グリーン、ダニー・マクファーソン、デイブ・マイヤー、エリオット・リア、ビル・ノートン、テッド・シーリー、フィリップ・スミス、ペッカ・サヴォラ）の初期のレビュアーに、そのコメント、修正、提案は非常に貴重でした。Call of Dutyをはるかに超えた貢献について、Geoff Hustonに感謝したいと思います。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、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 7007」インシデントの「nanogメーリングリストのディスカッション」、<http://www.merit.edu/mail.archives/nanog/1997-04/ msg00340.html>。
[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] Mills、D。、「Exterior Gateway Protocol正式な仕様」、RFC 904、1984年4月1日。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RFC1058] Hedrick、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。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, June 1992.
[RFC1338] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「スーパーネッティング：住所の割り当てと集約戦略」、RFC 1338、1992年6月。
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992.
[RFC1380] Gross、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. Li、「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] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「クラスレスインタードメインルーティング（CIDR）：住所割り当てと集約戦略」、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] Moy、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.、de Groot、G。、およびP. Vixie、「クラスレスIn-Addr.Arpa Delogation」、BCP 20、RFC 2317、1998年3月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[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.、White、R.、Fuller、V。、およびD. McPherson、「IPv4ポイントツーポイントリンクで31ビットプレフィックスを使用」、RFC 3021、2000年12月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221] Huston、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] Eabley、J.、Lindqvist、K.、Davies、E.、Black、B。、およびV. Gill、「IPv4 Multihoming Practices and Limations」、RFC 4116、2005年7月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RIPE] "RIPE Network Coordination Centre", <http://www.ripe.net>.
[RIPE]「Ripe Network Corution Center」、<http://www.ripe.net>。
Authors' Addresses
著者のアドレス
Vince Fuller 170 W. Tasman Drive San Jose, CA 95134 USA
ヴィンス・フラー170 W.タスマンドライブサンノゼ、カリフォルニア95134 USA
EMail: vaf@cisco.com
Tony Li 555 Del Rey Avenue Sunnyvale, CA 94085
Tony Li 555 Del Rey Avenue Sunnyvale、CA 94085
Email: tli@tropos.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
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）によって提供されます。