RFC4632 日本語訳
4632 Classless Inter-domain Routing (CIDR): The Internet AddressAssignment and Aggregation Plan. V. Fuller, T. Li. August 2006. (Format: TXT=66944 bytes) (Obsoletes RFC1519) (Also BCP0122) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
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
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
Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan
Status of This Memo
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.
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 Notice
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
Abstract
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.
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.
Fuller & Li Best Current Practice [Page 1] RFC 4632 CIDR Address Strategy August 2006
Fuller & Li Best Current Practice [Page 1] RFC 4632 CIDR Address Strategy August 2006
Table of Contents
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
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
Fuller & Li Best Current Practice [Page 2] RFC 4632 CIDR Address Strategy August 2006
Fuller & Li Best Current Practice [Page 2] RFC 4632 CIDR Address Strategy August 2006
1. Introduction
1. Introduction
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.
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.
2. History and Problem Description
2. History and Problem Description
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.
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.
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:
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:
Fuller & Li Best Current Practice [Page 3] RFC 4632 CIDR Address Strategy August 2006
Fuller & Li Best Current Practice [Page 3] RFC 4632 CIDR Address Strategy August 2006
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.
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.
2. Growth of routing tables in Internet routers beyond the ability
of current software, hardware, and people to effectively manage.
2. Growth of routing tables in Internet routers beyond the ability of current software, hardware, and people to effectively manage.
3. Eventual exhaustion of the 32-bit IPv4 address space.
3. Eventual exhaustion of the 32-bit IPv4 address space.
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].
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.
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.
More historical background on this effort and on the ROAD group
may be found in [RFC1380] and at [LWRD].
More historical background on this effort and on the ROAD group may be found in [RFC1380] and at [LWRD].
3. Classless Addressing as a Solution
3. Classless Addressing as a Solution
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.
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.
Fuller & Li Best Current Practice [Page 4] RFC 4632 CIDR Address Strategy August 2006
Fuller & Li Best Current Practice [Page 4] RFC 4632 CIDR Address Strategy August 2006
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.
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.
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.
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.
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.
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.
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.
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.
3.1. Basic Concept and Prefix Notation
3.1. Basic Concept and Prefix Notation
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.
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.
Fuller & Li Best Current Practice [Page 5] RFC 4632 CIDR Address Strategy August 2006
Fuller & Li Best Current Practice [Page 5] RFC 4632 CIDR Address Strategy August 2006
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.
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.
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).
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.
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:
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:
Fuller & Li Best Current Practice [Page 6] RFC 4632 CIDR Address Strategy August 2006
Fuller & Li Best Current Practice [Page 6] RFC 4632 CIDR Address Strategy August 2006
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"
記法addrs/ブロック#ブロック-------- ----------- ---------- 1n.n.n.n/32 4294967296「ホストルート」n.n.n.x/31 2、2147483648「p2pリンク」n.n.n.x/30 4 1073741824n.n.n.x/29 8 536870912n.n.n.x/28 16 268435456n.n.n.x/27 32 134217728n.n.n.x/26 64 67108864n.n.n.x/25 128 33554432n.n.n.0/24 256 16777216、遺産「クラスC」n.n.x.0/23 512 8388608n.n.x.0/22 1024 4194304n.n.x.0/21 2048 2097152n.n.x.0/20 4096 1048576n.n.x.0/19 8192 524288n.n.x.0/18 16384 262144n.n.x.0/17 32768 131072n.n.0; 0/16 65536 65536遺産「クラスB」n.x.0.0/15 131072 32768n.x.0.0/14 262144 16384n.x.0.0/13 524288 8192n.x.0.0/12 1048576 4096n.x.0.0/11 2097152 2048n.x.0.0/10 4194304 1024n.x.0.0/9 8388608 512 n.0.0.0/8 16777216 256遺産、「クラス、」 x.0.0.0/7 33554432 128x.0.0.0/6 67108864 64x.0.0.0/5 134217728 32x.0.0.0/4 268435456 16x.0.0.0/3 536870912 8x.0.0.0/2 1073741824 4x.0.0.0/1 2147483648 2 0.0.0.0/0 4294967296 1「デフォルトルート」
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は接頭語の長さに基づいて八重奏の最も重要なビットに移行して、小数に変換された7ビットの値への1フォームです。 八重奏の最下位ビットはゼロです。
Fuller & Li Best Current Practice [Page 7] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[7ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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) 中の過去の数回のときにいくつかのネットワークで観測されるために。
4. Address Assignment and Routing Aggregation
4. アドレス課題とルート設定集合
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の展開には、アドレスが割り当てられた方法のための意味がありました。
4.1. Aggregation Efficiency and Limitations
4.1. 集合効率と制限
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.
1つのサービスプロバイダーにつなげられる端のサイトに、集合は簡単です: それはサービスプロバイダーによって割り当てられたアドレス空間を使用します、そして、そのアドレス空間はサービスプロバイダーに割り当てられたより大きいブロックの小さい断片です。 どんな明白なルートも端のサイトに必要ではありません。 サービスプロバイダーはただ一つの集合ルートの、より大きいブロックに広告を出します。 この広告はブロックで付番されたすべての顧客に可到達性とrouteabilityを提供します。
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
o 組織、マルチ、家へ帰り マルチ、家へ帰り、それぞれのサービスプロバイダーはシステムに組織の広告を出さなければならなくて、それらのプロバイダーのどれかのアドレス空間へのルーティング情報に集めるのはしばしば可能であるというわけではありません。 組織がサービスプロバイダーのアドレス空間(他の利点を持っている)からアドレス課題をまだ受け取っているかもしれませんが、組織の接頭語へのルートがサービスプロバイダーのすべてで最も一般的な場合で明らかに広告を出すことに注意してください。 これに関しては、推論してください。
Fuller & Li Best Current Practice [Page 8] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[8ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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].
一般に、組織はCIDRの採用の前に、それがあったのと同じです。グローバルなルーティングがaにかかった、マルチ、家へ帰り、[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がこの状況を扱う、特定の広告の広告を出すそれを必要とするのによる、より新しいサービスプロバイダー、再家へ帰る、組織。 それがプロバイダー集合より長いマッチであるので、この広告は好まれます。 集合の効率を維持するために、サービスプロバイダーを変える組織が、結局移動するのを計画しているのは、お勧めです。aへの接頭語が新しいプロバイダーのアドレス空間から割り当てたネットワーク。 このために、[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の隣接のパワーブロックアドレス空間を割り当てることによって、サイトのルーティング情報はただ一つの接頭語に集められるかもしれません。 また、ルーティング費用がaを割り当てると交際した、マルチ、家へ帰り、サービスプロバイダーのアドレス空間からのサイトが主要な権威による連番課題の古いより方法以下である、それはサービスプロバイダーに割り当てられたブロックからすべての端サイトアドレス空間を割り当てる意味になります。
It is also worthwhile to mention that since aggregation may occur at multiple levels in the system, it may still be possible to aggregate these anomalous routes at higher levels of whatever hierarchy may be present. For example, if a site is multi-homed to two 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レベル集合に関する実現の可能性は位相的な階層構造がサイト、直接接続されたプロバイダー、およびそれらが関連している他のプロバイダーの中に存在しているかどうかによります。 それは、世界的なインターネットのいくつかの領域で実用的ですが、他のもので実用的であるかもしれないというわけではありません。
Fuller & Li Best Current Practice [Page 9] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[9ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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.
以下に注意してください。 従う議論と例では、前置表記法は、ルーティングの目的地を表すのに使用されます。 これは、イラストだけに使用されて、ルーティング・プロトコルが彼らのアップデートにおけるこの表現を使用するのを必要としません。
4.2. Distributed Assignment of Address Space
4.2. アドレス空間の分配された課題
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アドレス空間課題は中央のNetworkインフォメーション・センター(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のアドレス(CIDRが後で/8と定義すること)のビット並べられたブロックでRIPE NCC([RIPE])へヨーロッパのインターネット・サイトへのアドレス空間課題を代表として派遣したとき、この機能は分散し始めました、事実上それをRIRsの1番目にして。 それ以来、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.
アドレスの階層的な代表団は、アドレスが与えられたサービスプロバイダーから割り当てられているサイトがルーティング目的のためのそのサービスプロバイダーの一部であり、インフラストラクチャで発送されるのをこの様に含意します。 これがそのルーティング情報を含意する、マルチ、家へ帰り、それでも、組織(すなわち、1つ以上のネットワークサービスプロバイダーに接続された組織)は、階層構造で、より高いレベルによって知られている必要があるでしょう。
A historical perspective on these issues is described in [RFC1518]. Additional discussion may also be found in [RFC3221].
これらの問題に関する歴史観は[RFC1518]で説明されます。 また、追加議論は[RFC3221]で見つけられるかもしれません。
Fuller & Li Best Current Practice [Page 10] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[10ページ]RFC4632CIDRは2006年8月に戦略を記述します。
5. Routing Implementation Considerations
5. ルート設定実現問題
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.
classfulネットワーク・ナンバーから階級のない接頭語までの変化では、IPv4アドレスの初期のビット・パターンからネットワークマスクを推論するのは可能ではありません。 これには、ルーティング情報がどう格納されて、伝播されるか意味があります。 ルーティング・プロトコルで明らかにネットワークマスクか接頭語の長さを運ばなければなりません。 OSPF[RFC2328]、Intermediate SystemへのIntermediate Systemなどの内部のルーティング・プロトコル、(-、)、[RFC1195](RIPv2[RFC2453]、シスコEnhanced Interiorゲートウェイルート設定プロトコル(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.
リップなどの、より古い内部のルーティング・プロトコル[RFC1058](ExteriorゲートウェイプロトコルなどのHELLO、シスコInteriorゲートウェイルート設定プロトコル(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ネットワーク装置のテーブルを組織化しなければならない推進は、ともに長さかマスクを前に置いて、前に置きます。 遺産Class A/B/Cネットワーク/サブネットコンベンションによると、ルーティング/推進情報を組織化する設備が正しく世界的なインターネットに接続されたネットワークに働くことを期待できません。 そのような設備の使用は推薦されません。 幸い、そのような設備があるわずか、が今日を使用します。
5.1. Rules for Route Advertisement
5.1. ルート広告のための規則
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. 倍数のために集合ルートを発生させるルータ、より多くの特定のルートが集合ルートを合わせますが、いくらか合わせるというわけではないより特定のルートのパケットを捨てなければなりません。 言い換えれば、集合ルートへの「次のホップ」はヌル目的地であるべきです。 これが、集合でカバーされたいくつかのアドレスが届いていないとき、輪を進めるのを防ぐのに必要です。
Fuller & Li Best Current Practice [Page 11] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[11ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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をデフォルトルートとして使用されて、すべての実現で認めなければなりません。 そうするために明らかにルータを構成するときだけ、さらに、相互ドメインプロトコルでこのルートの偶然の広告から守るために、別の経路ドメインにこのルートの広告を出すべきです、決してどんな非構成された「デフォルト」オプションとしても、そうしません。
5.2. How the Rules Work
5.2. 規則はどう利くか。
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
規則#2は、ルーティング輪が全く集合のため形成されないのを保証します。 .64/19は、「親」プロバイダーで192.168に割り当てられたaサイトであると考えます。(それは、192.168に.0/16に.0を持っています)。 「親」ネットワークは192.168に「子供」への.0/16がネットワークでつなぐ.0の広告を出すでしょう。 「子供」ネットワークが内部の接続性を192.168に失うつもりであった、.65、「親」からの.0/24(集合の一部である)、交通、「子供」に、.1が望んでいる.65が192.168に「に子供続くので、」 広告を出しているルートは運命づけられていました。 *それは推進輪をもたらすでしょう、したがって、しかしながら、その交通が「子供」に子供を得るとき、*はルート192.168.0.0/16後部に「親」まで続いてはいけませんか? 規則#2は言います。
Fuller & Li Best Current Practice [Page 12] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[12ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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.
「子供」がそれ自身の1つに合っている目的地へのそれほど特定でないルートに従わないかもしれないのはルートに集められました(通常、これは1つのネットワークが別のものに広告を出すすべての集められた接頭語のために「破棄」か「ヌル」のルートをインストールすることによって、実行されます)。 「デフォルト」ルートのその取り扱いに注意してください、(0.0 .0 .0/0) この規則の特別なケースです。 ネットワークは集められた広告の1つの一部である目的地にデフォルトに従ってはいけません。
5.3. A Note on Prefix Filter Formats
5.3. 接頭語フィルタ形式に関する注
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が172.25に受け入れる.0を受け入れてください、.120、.0、.0が172.31に.0が10.2に、.0が10.0に受け入れる.0を否定する.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/16が172.25に受け入れる.0を受け入れてください、.0、.0/16が172.31に.0/16が10.2に、.0/16が10.0に受け入れる.0を否定する.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.
これで、ネットワーク・ナンバーのClass A/B/C分類で含意されたネットワークマスクは単に明白になっています。 また、それも高めるために同じビット・パターンで接頭語のマッチとすべての、より特定の接頭語を許容する能力をフィルターにかけながら、役に立ちます。 幸い、この機能性はインターネットで使用される設備のほとんどの業者によって実行されました。
5.4. Responsibility for and Configuration of Aggregation
5.4. 集合の責任と構成
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,
通常の状況下で、1セットの接頭語を割り当てるか、または割り当てた経路ドメイン(または、「自律システム」)はそれらの接頭語の集合への唯一の責任を持っています。 普通の場合では、ASは、内部のルーティングシステムに知られているより特定のルートに基づく集合ルートを発生させるようにルータの1つ以上に構成をインストールするでしょう。 境界ルータは経路ドメインのためにグローバルなルーティングシステムにこれらの集合ルートの広告を出します。 グローバルに集合ルートに重なるより特定の内部のルートの広告を出すべきではありません。 いくつかの場合
Fuller & Li Best Current Practice [Page 13] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[13ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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は集合責任を別のASへ代表として派遣したがっているかもしれません(例えば、顧客は、サービスプロバイダーにそのに代わって集められたルーティング情報を発生させて欲しいかもしれません)。 そのような場合、それがそれらのルートがどう集められるべきであるかを説明する構成された方針情報に結合された1日から受けるルートによると、集合は第2ASのルータによって実行されます。
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がその顧客と隣人に運んで、伝播しなければならないルーティング状態の量を減少させるための有益な手段であるかもしれません。 しかしながら、また、プロキシ集合は交通工学の予期せぬ結果を作成できます。 AS3が起こりませんが、両方のAS2と3がAS1からルートを受けますが、AS2がプロキシ集合を実行するなら何が起こるか考えてください。 AS2とAS3の両方からトランジットルーティング情報を受け取る他のASesは、ルーティング情報の首尾一貫しない視点がAS1によって溯源されるのを見るでしょう。 これはAS3の顧客とAS3から公共輸送路を受け取るどんな他のもののためにもAS3を通してAS1に向かって交通の予期していなかったシフトを引き起こすかもしれません。 プロキシ集合が集合を提供する集められたルートの源かパーティーのどちらかとの関係を全く持っていないインターネットの地域に思いがけない結果を引き起こす場合があるので、それは細心の注意を払って使用されるべきです。
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.
集合に結合するべきルートの構成は、ルーティング方針の実現であり、何らかの手動で維持された情報を必要とします。 1セットの「ルート-可能」接頭語のために保守しなければならない情報への追加として、通常、集合構成は、ただ集められるためにIPv4アドレスのブロックの範囲を定義する1か2つの線です。 それ自身の集合を実行するサイトはそれを割り当ててある何あて先ブロックもそうしています。 別のものを代表して集合を実行するサイトは集合を代表として派遣する協定でこの情報を知っています。 ネットワーク管理者にとって、最も良い一般的な習慣が互いから受け入れるために接頭語のリストを交換することになっていると仮定して、集合情報の構成は重要な追加管理オーバーヘッドを導入しません。
Fuller & Li Best Current Practice [Page 14] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[14ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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」(マルチキャスト)アドレス空間の集合はこのドキュメントの範囲を超えています。
5.5. Route Propagation and Routing Protocol Considerations
5.5. ルート伝播とルーティング・プロトコル問題
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、-、RIP、) 一貫して正しいエキジットポイントがそれらのプロトコルを通して学習された目的地に交通を送るために選ばれたのを保証するためにこれをしました。 4つの進化論の効果(CIDRの到来、グローバルなルーティング状態の爆発的成長、BGP4の広範囲の採用、およびフルパス情報を伝播するという要件)が結合して、その習慣を非難しました。 適切な経路伝播を確実にして、相互ASルーティング矛盾を防ぐ(BGP4の輪の検出/防止メカニズムはフルパス伝播を必要とする)ために、輸送網はネットワーク以内とそれらのネットワークを通して他のプロバイダーから学習されたルートを運ぶのに、内部のBGP(iBGP)を使用しなければなりません。
6. Example of New Address Assignments and Routing
6. 新しいアドレス課題とルート設定に関する例
6.1. Address Delegation
6.1. アドレス代表団
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.31.255.255「PA」と共にただ一つのネットワーク内の提供者に割り当てて、10.24で.0の.0と結末を始めて。 これはサイズで1ブロックの2048遺産「クラスC」ネットワーク・ナンバー(または、/24年代)に同等です。 階級のないルートがこのブロックに10.24と説明されるだろう、.0、255.248のマスクがある.0、.0、.0と接頭語10.24.0.0/13
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):
このサービスプロバイダーが以下のオーダー(一時的な「穴」がサービスプロバイダーのアドレス空間でどう形成されるかもしれないかを示すので重要な)における6つのサイトをつなげると仮定してください:
Fuller & Li Best Current Practice [Page 15] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[15ページ]RFC4632CIDRは2006年8月に戦略を記述します。
o "C1", requiring fewer than 2048 addresses (/21 or 8 x /24)
o 「2048未満のアドレスを必要とするC1"」(/21か8x/24)
o "C2", requiring fewer than 4096 addresses (/20 or 16 x /24)
o 「4096未満のアドレスを必要とするC2"」(/20か16x/24)
o "C3", requiring fewer than 1024 addresses (/22 or 4 x /24)
o 「1024未満のアドレスを必要とするC3"」(/22か4x/24)
o "C4", requiring fewer than 1024 addresses (/22 or 4 x /24)
o 「1024未満のアドレスを必要とするC4"」(/22か4x/24)
o "C5", requiring fewer than 512 addresses (/23 or 2 x /24)
o 「512未満のアドレスを必要とするC5"」(/23か2x/24)
o "C6", requiring fewer than 512 addresses (/23 or 2 x /24)
o 「512未満のアドレスを必要とするC6"」(/23か2x/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.0〜10.24に.7に10.24を割り当ててください。 ネットワークのこのブロックがルート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。 .16〜10.24に.31に10.24を割り当ててください。 255.255にマスクをかけてください。このブロックがルート10.24.16.0/によって説明される、20、(.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。 .8〜10.24に.11に10.24を割り当ててください。 255.255にマスクをかけてください。このブロックがルート10.24.8.0/によって説明される、22、(.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。 .12〜10.24に.15に10.24を割り当ててください。 255.255にマスクをかけてください。このブロックがルート10.24.12.0/によって説明される、22、(.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に.33に.32と10.24を割り当ててください。 255.255にマスクをかけてください。このブロックがルート10.24.32.0/によって説明される、23、(.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に.35に.34と10.24を割り当ててください。 255.255にマスクをかけてください。このブロックがルート10.24.34.0/によって説明される、23、(.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つのサイトが異なったサイズの6つの接頭語としてプロバイダーのIGPの中に表されるべきです。 プロバイダーがある理由で階級のないルーティングを支持しない時代遅れの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」を通して。 「C7"、元々、"RB"に接続されましたが、それは「PA」に動きました。」とサイトの存在をさらに仮定してください。 この理由で、それには、PBの(次)2048x/24のブロックから割り当てられる1ブロックのネットワーク・ナンバーがあります。
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。 .0〜10.32に.15に10.32を割り当ててください。 255.255にマスクをかけてください。このブロックがルート10.32.0.0/によって説明される、20、(.240 .0)。
Fuller & Li Best Current Practice [Page 16] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[16ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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"がともに同じトランジットサービスプロバイダー、「掲示板」に接続されると仮定してください。
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 ----------+
10.24.0.0 -- 10.24 .7 .0__ __、10.32 .0 .0--10.32 .15 .0C1: 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 | | | | +----+ +----+ || || ルーティング広告: || || || || 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+---------- 背骨ネットワーク掲示板----------+
6.2. Routing Advertisements
6.2. ルート設定広告
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の集合の広告が2番目として使用されるので。 実際行なわれているところでは、通常、両方のプロバイダーでC5の広告を出すでしょう。
Advertisements from "PA" to "BB" will be
「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)
10.24.12.0/22(C4の広告を出します)第一の10.32.0.0/20予備選挙(C7の広告を出す)10.24.0.0/13予備選挙(PAの残りの広告を出します)
Fuller & Li Best Current Practice [Page 17] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[17ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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」から「掲示板」までの広告はそうでしょう。
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のスペースから割り当てられるサイト)に接続性を失うなら何が起こるか考えてください。 statefulプロトコルで、PAはそれを掲示板に発表するでしょう。10.32 .0 .0/20は手が届かなくなりました。 掲示板が現在経路指定テーブルからこの情報を洗い流すとき、それを通してこの目的地に送られたどんな将来の交通もPBのそれほど特定でないマッチ、10.32によってPBに送られた(Rule#2に応じてそれが落とされるところ).0.0/にな13るでしょう。 これは運転上の問題を引き起こしませんが(どのような場合でも、C7は手が届きません)、それは「掲示板」(そして、また、「トレースルート」で供給停止をデバッグしようとしながら、だれかにとって紛らわしいと判明するかもしれない)の向こう側に何らかの余分な交通を引き起こします。 そのような手の届かない状態をキャッシュするメカニズムは良いかもしれませんが、それはこのドキュメントの範囲を超えています。
7. Domain Name Service Considerations
7. ドメイン名サービス問題
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ゾーン。 八重奏境界だけでこのゾーンを代表として派遣するので、ビットマスク指向のアドレシングを使用するアドレス課題プランへの移動は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].
それを妨げる時と中古のアドレスが居住しないIN-ADDR.ARPAゾーンに居住するテクニックの記述は八重奏境界に並びます。[RFC2317]では、説明されます。
8. Transition to a Long-Term Solution
8. 長期的な解決法への変遷
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インターネットにおけるルーティング状態とアドレス減少の問題の短期的な解決になるように設計されました。 それは基本的なインターネット・ルーティングかアドレッシング体系を変えません。 それが恐らく延着するのによるそのような解決策を見いだす緊急以外のより長期の解決策への変遷のためのどんなプランにも影響しないと予想されます。
Fuller & Li Best Current Practice [Page 18] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[18ページ]RFC4632CIDRは2006年8月に戦略を記述します。
9. Analysis of CIDR's Effect on Global Routing State
9. グローバルなルート設定状態におけるCIDRの効果の分析
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:
「活発な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年頃まで。 この成長のための主要なドライバーは、トランジットプロバイダーのための集合能力の不足と、端のサイトのための遺産Class 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"supernet"ブロックとしての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年の急落は"supernet"ブロックの集合を許容しました。 経路指定テーブルエントリーの数の最も大きい衰退の一区切りがIETF CIDR Deployment作業部会の各ミーティングに続く週に通常対応することに注意してください。
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年までの急激な増加はマルチホーミングと交通工学のために、より特定のルート広告における、インターネットの急速拡大と大きい増加の両方をあおりました。
Fuller & Li Best Current Practice [Page 19] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[19ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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.
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コンポーネントの両方の広告を出しながら、あるように見えます、たぶんお勧めのルーティング設定に関する一貫した現行情報の不足のため。
10. Conclusions and Recommendations
10. 結論と推薦
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はその時、最初に、開発されました)。 ルーティング州の複雑さにおける成長とアドレス空間の消費の増加が急速であったので、それは、ものか問題の両方が短い数年の以内にインターネットの継続成長を排除するのを現れさせました。
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.
BGP4の階級のない接頭語ルートを運ぶサポートと組み合わせて、CIDRの展開は短期的な危機を軽減しました。 単に設備メーカーとプロバイダー共同体の両方による協力で、これは達成されました。 脅威、(恐らくいくつかの場合実際の実現、)、広告接頭語のためにネットワークを請求すると、サービスプロバイダーとアドレス空間を共有して、その結果広告ルートの関連コストを共有する追加誘因は提供されたかもしれません。
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月現在、ルーティングシステムのベースの集合アドレス荷重には、およそ7万5000のエントリーがあります。
Fuller & Li Best Current Practice [Page 20] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[20ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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.
およそ8万5000の追加エントリーがこのベース「根」収集の、より特定のエントリーです。 これらの追加エントリーの多くが地方の、または、地方の範囲のさえ問題を解決するために存在して、グローバルに伝播される必要はないはずであると信じる理由があります。
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がずっと実行可能なアプローチするかもしれないかどうかということです。 最近の測定値は、急激な増加が再開したのを示しますが、さらなる分析は、効率的な集合戦略とまともな道具構成に関してサービスプロバイダーを教育するための、より活発な努力でこの傾向を緩和できるのを示します。 前方では、より遠く見えて、グローバルなルーティング状態を各サイトに必要としないより良いマルチホーミング技術とさらに多くの状態を加えるのを必要としない交通ロードバランシングを実行する方法の明確な必要があります。 そのような開発なしで主要な建築変化がないとき、集合はルーティングに世界的なインターネットを計量させるのに利用可能な唯一のツールです。
11. Status Updates to CIDR Documents
11. 状態はドキュメントをCIDRにアップデートします。
This memo renders obsolete and requests re-classification as Historic the following RFCs describing CIDR usage and deployment:
このメモが時代遅れであることへレンダリングする、Historicとしての要求再分類がCIDR用法と展開について説明する以下のRFCsをそうする、:
o RFC 1467: Status of CIDR Deployment in the Internet
o RFC1467: インターネットでの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.
このInformational RFCは1993年にCIDR展開の状態について説明しました。 2005年現在CIDRが徹底的に配備されたので、この状態注意は史料ポイントを提供するだけです。
o RFC 1481: IAB Recommendation for an Intermediate Strategy to
Address the Issue of Scaling
o RFC1481: 中間的戦略がスケーリングの問題を記述するという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.
この非常に短いInformational RFCは、スケーリング問題を記述するためにIABのCIDRの使用の裏書きについて説明しました。 RFC1481の目標が達成されたので、それには、現在、歴史的な価値しかありません。
o RFC 1482: Aggregation Support in the NSFNET Policy-Based Routing
Database
o RFC1482: 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によって指定されるようにこのInformational RFCはルート集合のサポートのためのプランについて説明します。 NSFNETが以来、長い間消滅していて、CIDRが遍在して配備されたので、RFC1482には、現在、歴史的な関連性があるだけです。
o RFC 1517: Applicability Statement for the Implementation of
Classless Inter-Domain Routing (CIDR)
o RFC1517: 階級のない相互ドメインルート設定の実現のための適用性証明(CIDR)
Fuller & Li Best Current Practice [Page 21] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[21ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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.
このStandards Track RFCはどこでCIDRが必要であると予想されたか、そして、どこで(強く)推薦されると予想されたかを説明しました。 CIDRの完全な展開がインターネットにある状態で、CIDRは必要でない状況が歴史的におもしろいだけです。
o RFC 1518: An Architecture for IP Address Allocation with CIDR
o RFC1518: 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.
このStandards Track RFCは何らかの長さで掘るのを議論して、集合問題を記述します。 これらの問題のいくつかが本書ではセクションセクション3.1にまとめられます。 アドレス課題方針と手順が現在主にRIRsと共にあるので、それらの習慣をStandards Track RFCに記録しようとするのは適切ではありません。 また、さらに、[RFC3221]はルーティングシステムの観点からの同じ問題の多くについて説明します。
o RFC 1520: Exchanging Routing Information Across Provider
Boundaries in the CIDR Environment
o RFC1520: 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.
このInformational RFCはCIDRがプロバイダーの間で経由地案内を交換するために完全に支持されたというわけではない変遷シナリオについて説明しました。 CIDRの完全な展開がインターネットにある状態で、そのようなシナリオはもう操作上関連していません。
o RFC 1817: CIDR and Classful Routing
o RFC1817: CIDRとClassfulルート設定
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.
このInformational RFCは1995年にCIDR展開の含意について説明しました。 以前classfulなアドレスがCIDRメカニズムを使用することで割り当てられることであったことに注意して、デフォルトルートの使用について説明する、非CIDR意識する、サイト。 CIDRの完全な展開がインターネットにある状態で、そのようなシナリオはもう操作上関連していません。
o RFC 1878: Variable Length Subnet Table For IPv4
o RFC1878: 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.
このInformational RFCはそれぞれのサブネットサイズのためのあらかじめ計算されたサブネットマスクとアドレスカウントのテーブルを提供しました。 このドキュメント(セクション3.1を見る)への同様のテーブルの編入によって、別々のRFCにそれを記録するのはもう必要ではありません。
o RFC 2036: Observations on the use of Components of the Class A
Address Space within the Internet
o RFC2036: インターネットの中のClass A Address SpaceのComponentsの使用の観測
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.
このInformational RFCは以前にclassfulなアドレス空間から階級のない接頭語の配分に関連しているいくつかの操作上の問題について説明しました。 CIDRの完全な展開がインターネットにあって、半ダース年間の経験が歴史的な「クラスA」アドレス空間から階級のない接頭語配分を作っていて、このRFCには、現在、歴史的な価値しかありません。
Fuller & Li Best Current Practice [Page 22] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[22ページ]RFC4632CIDRは2006年8月に戦略を記述します。
12. Security Considerations
12. セキュリティ問題
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. 通常、その目的地に広告に掲載されている集合より特定の与えられた目的地に接頭語の広告を出すことによって、交通をハイジャックできます。 例えば、アドレスがあるそのaポピュラーなエンドシステムを仮定してください、192.168、.17、.100、192.168に.0/20に.16の広告を出すサービスプロバイダーに関連づけられます。 このサイトのための交通を妨害したがっていた悪意があるネットワーク・オペレータが広告を出すかもしれませんか、または広告を出すのを少なくとも試みてください、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
2. システムへのルートの広告多くでインターネット基盤の多くの部分に対してサービス不能攻撃に着手できます。 そのような攻撃は、ルーティングからはみ出すことによってルータ失敗を引き起こすことを意図して、テーブルを進めています。 この種類の失敗を引き起こした非悪意がある事件の好例は「7007」悪名高い出来事[7007]でした、グローバルなルーティングシステムを通してオペレータで誤構成しているルータで巨大な数の無効のルートを伝播したところで。 一方、この種類の攻撃は本当にCIDRと共に新しくはありません。 遺産Class A/B/Cルートを使用して、最大16843008のユニークなネットワーク・ナンバーのグローバルなルーティングシステムに広告を出すのは可能でした、問題を引き起こすのさえ十分な数
Fuller & Li Best Current Practice [Page 23] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[23ページ]RFC4632CIDRは2006年8月に戦略を記述します。
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.
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が、より簡単にする攻撃の種類の徹底的な分析であることを意図しないことに注意してください。 グローバルなルーティングシステムにおける、セキュリティの脆弱性の、より包括的な分析はこのドキュメントの範囲を超えています。
13. Acknowledgements
13. 承認
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.
作者はRFC1519(Kannan Varadhan、ジェシカ・ユー)の他の原作者に感謝を申し上げたがっています。 ROADグループに(CIDRの後ろの考えの多くが、それと共に心に抱いて、開発されました)。 そして、ドキュメント(Barryグリーン、ダニーMcPherson、デーヴ・マイヤー、エリオットリア、ビルノートン、テッド・シーリ、フィリップ・スミス、ペッカSavola)のこの再回転しているバージョンの初期の評論家にとって、だれのコメント、修正、および提案は非常に貴重でしたか? 貢献について履行請求を超えてジェフ・ヒューストンに特によく感謝申し上げます。
Fuller & Li Best Current Practice [Page 24] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[24ページ]RFC4632CIDRは2006年8月に戦略を記述します。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
14.2. Informative References
14.2. 有益な参照
[7007] "NANOG mailing list discussion of the "AS 7007" incident",
<http://www.merit.edu/mail.archives/nanog/1997-04/
msg00340.html>.
[7007] 「「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] 工場、D.、「外のゲートウェイプロトコル形式仕様」、RFC904、1984年4月1日。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[RFC1058] ヘドリック、C.、「ルーティング情報プロトコル」、RFC1058、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存在、」、RFC1195、12月1990日
[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、「スーパーネッティング:」 「アドレス課題と集合戦略」、RFC1338、6月1992日
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing
and Addressing", RFC 1380, November 1992.
[RFC1380] グロスとP.とP.Almquist、「ルート設定とアドレシングにおけるIESG熟考」、RFC1380、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アドレス配分のための構造」、RFC1518、1993年9月。
Fuller & Li Best Current Practice [Page 25] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[25ページ]RFC4632CIDRは2006年8月に戦略を記述します。
[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)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、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グルート、G.、およびP.Vixie、「階級のないIN ADDR.ARPA代表団」、BCP20、RFC2317、1998年3月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
1998.
[RFC2453] マルキン、G.は「1998年11月にバージョン2インチ、STD56、RFC2453を裂きます」。
[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] レタナ、A.、ホワイト、R.、フラー、V.、およびD.マクファーソン、「IPv4ポイントツーポイント接続の上で31ビットの接頭語を使用する」RFC3021(2000年12月)。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001.
[RFC3221]ヒューストン、G.、「インターネットの相互ドメインルート設定の論評」、RFC3221、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.、リンクヴィスト、K.、デイヴィース、E.、黒、B.、およびRFC4116、2005年7月対「IPv4マルチホーミング習慣と制限」
[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)」、RFC4271 2006年1月。
[RIPE] "RIPE Network Coordination Centre", <http://www.ripe.net>.
[熟す]の「熟しているネットワークコーディネートセンター」、<http://www.ripe.net>。
Authors' Addresses
作者のアドレス
Vince Fuller 170 W. Tasman Drive San Jose, CA 95134 USA
ビンス縮絨工170w.タスマン・Driveカリフォルニア95134サンノゼ(米国)
EMail: vaf@cisco.com
メール: vaf@cisco.com
Tony Li 555 Del Rey Avenue Sunnyvale, CA 94085
トニー・李555デル・レイAvenueサニーベル、カリフォルニア 94085
Email: tli@tropos.com
メール: tli@tropos.com
Fuller & Li Best Current Practice [Page 26] RFC 4632 CIDR Address Strategy August 2006
フラーと李最も良い現在の習慣[26ページ]RFC4632CIDRは2006年8月に戦略を記述します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Fuller & Li Best Current Practice [Page 27]
よりふくよかで李Best現在の習慣[27ページ]
一覧
スポンサーリンク
