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
无类域间路由（CIDR）：Internet地址分配和聚合计划
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described.
本备忘录讨论了现有32位IPv4地址空间的地址分配策略，旨在节约地址空间并限制全局路由状态的增长率。本文件废除了RFC 1519中最初的无类域间路由（CIDR）规范，并对其进行了更改，以澄清其引入的概念，并在12年多之后，根据所述技术的部署结果更新互联网社区。
Table of Contents
目录
1. Introduction ....................................................3
2. History and Problem Description .................................3
3. Classless Addressing as a Solution ..............................4
3.1. Basic Concept and Prefix Notation ..........................5
4. Address Assignment and Routing Aggregation ......................8
4.1. Aggregation Efficiency and Limitations .....................8
4.2. Distributed Assignment of Address Space ...................10
5. Routing Implementation Considerations ..........................11
5.1. Rules for Route Advertisement .............................11
5.2. How the Rules Work ........................................12
5.3. A Note on Prefix Filter Formats ...........................13
5.4. Responsibility for and Configuration of Aggregation .......13
5.5. Route Propagation and Routing Protocol Considerations .....15
6. Example of New Address Assignments and Routing .................15
6.1. Address Delegation ........................................15
6.2. Routing Advertisements ....................................17
7. Domain Name Service Considerations .............................18
8. Transition to a Long-Term Solution .............................18
9. Analysis of CIDR's Effect on Global Routing State ..............19
10. Conclusions and Recommendations ...............................20
11. Status Updates to CIDR Documents ..............................21
12. Security Considerations .......................................23
13. Acknowledgements ..............................................24
14. References ....................................................25
14.1. Normative References .....................................25
14.2. Informative References ...................................25
1. Introduction ....................................................3
2. History and Problem Description .................................3
3. Classless Addressing as a Solution ..............................4
3.1. Basic Concept and Prefix Notation ..........................5
4. Address Assignment and Routing Aggregation ......................8
4.1. Aggregation Efficiency and Limitations .....................8
4.2. Distributed Assignment of Address Space ...................10
5. Routing Implementation Considerations ..........................11
5.1. Rules for Route Advertisement .............................11
5.2. How the Rules Work ........................................12
5.3. A Note on Prefix Filter Formats ...........................13
5.4. Responsibility for and Configuration of Aggregation .......13
5.5. Route Propagation and Routing Protocol Considerations .....15
6. Example of New Address Assignments and Routing .................15
6.1. Address Delegation ........................................15
6.2. Routing Advertisements ....................................17
7. Domain Name Service Considerations .............................18
8. Transition to a Long-Term Solution .............................18
9. Analysis of CIDR's Effect on Global Routing State ..............19
10. Conclusions and Recommendations ...............................20
11. Status Updates to CIDR Documents ..............................21
12. Security Considerations .......................................23
13. Acknowledgements ..............................................24
14. References ....................................................25
14.1. Normative References .....................................25
14.2. Informative References ...................................25
This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original CIDR spec [RFC1519], with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described.
本备忘录讨论了现有32位IPv4地址空间的地址分配策略，旨在节约地址空间并限制全局路由状态的增长率。本文件废除了原始CIDR规范[RFC1519]，对其进行了更改，以澄清其引入的概念，并在12年多之后，更新互联网社区对所述技术部署结果的了解。
What is now known as the Internet started as a research project in the 1970s to design and develop a set of protocols that could be used with many different network technologies to provide a seamless, end-to-end facility for interconnecting a diverse set of end systems. When it was determined how the 32-bit address space would be used, certain assumptions were made about the number of organizations to be connected, the number of end systems per organization, and total number of end systems on the network. The end result was the establishment (see [RFC791]) of three classes of networks: Class A (most significant address bits '00'), with 128 possible networks each and 16777216 end systems (minus special bit values reserved for network/broadcast addresses); Class B (MSB '10'), with 16384 possible networks each with 65536 end systems (less reserved values); and Class C (MSB '110'), and 2097152 possible networks each and 254 end systems (256 bit combinations minus the reserved all-zeros and all-ones patterns). The set of addresses with MSB '111' was reserved for future use; parts of this were eventually defined (MSB '1110') for use with IPv4 multicast and parts are still reserved as of the writing of this document.
现在所称的互联网始于20世纪70年代，是一个研究项目，旨在设计和开发一套可与多种不同网络技术结合使用的协议，以提供无缝的端到端设施，用于互连不同的端系统。在确定如何使用32位地址空间时，对要连接的组织数量、每个组织的终端系统数量以及网络上的终端系统总数进行了某些假设。最终结果是建立了三类网络（见[RFC791]）：A类（最高有效地址位'00'），每个网络有128个可能的网络和16777216个终端系统（减去为网络/广播地址保留的特殊位值）；B类（MSB“10”），具有16384个可能的网络，每个网络具有65536个终端系统（较少的保留值）；C类（MSB“110”）和2097152个可能的网络以及254个终端系统（256位组合减去保留的全零和全一模式）。MSB为“111”的地址集已保留供将来使用；部分内容最终被定义（MSB“1110”）用于IPv4多播，部分内容在撰写本文档时仍保留。
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:
在20世纪80年代末，前研究网络的扩展和商业化导致许多新组织连接到快速增长的互联网，每个新组织都需要根据A类/B类/C类寻址计划分配地址。随着对新网络号码（尤其是B类空间）的需求呈指数级增长，运营和工程界的一些成员开始关注A/B/C级系统的长期扩展特性，并开始考虑如何修改网络编号分配策略和路由协议以适应增长。1991年11月，互联网工程任务组（IETF）成立了道路（路由和寻址）小组，以检查情况。该小组于1992年1月开会，确定了三个主要问题：
1. Exhaustion of the Class B network address space. One fundamental cause of this problem is the lack of a network class of a size that is appropriate for mid-sized organization. Class C, with a maximum of 254 host addresses, is too small, whereas Class B, which allows up to 65534 host addresses, is too large for most organizations but was the best fit available for use with subnetting.
1. B类网络地址空间耗尽。这个问题的一个根本原因是缺少适合中型组织的网络类。C类（最多254个主机地址）太小，而B类（最多允许65534个主机地址）对大多数组织来说太大，但最适合用于子网。
2. Growth of routing tables in Internet routers beyond the ability of current software, hardware, and people to effectively manage.
2. Internet路由器中路由表的增长超出了当前软件、硬件和人员有效管理的能力。
3. Eventual exhaustion of the 32-bit IPv4 address space.
3. 最终耗尽32位IPv4地址空间。
It was clear that then-current rates of Internet growth would cause the first two problems to become critical sometime between 1993 and 1995. Work already in progress on topological assignment of addressing for Connectionless Network Service (CLNS), which was presented to the community at the Boulder IETF in December of 1990, led to thoughts on how to re-structure the 32-bit IPv4 address space to increase its lifespan. Work in the ROAD group followed and eventually resulted in the publication of [RFC1338], and later, [RFC1519].
很明显，当时互联网的增长速度将导致前两个问题在1993年至1995年期间变得至关重要。1990年12月在博尔德IETF上向社区介绍的无连接网络服务（CLNS）寻址拓扑分配的工作已经在进行中，引发了如何重新构造32位IPv4地址空间以延长其使用寿命的思考。随后，ROAD集团的工作最终出版了[RFC1338]，后来又出版了[RFC1519]。
The design and deployment of CIDR was intended to solve these problems by providing a mechanism to slow the growth of global routing tables and to reduce the rate of consumption of IPv4 address space. It did not and does not attempt to solve the third problem, which is of a more long-term nature; instead, it endeavors to ease enough of the short- to mid-term difficulties to allow the Internet to continue to function efficiently while progress is made on a longer-term solution.
CIDR的设计和部署旨在通过提供一种机制来减缓全局路由表的增长并降低IPv4地址空间的消耗率，从而解决这些问题。它没有也没有试图解决第三个问题，这是一个更长期的问题；相反，它努力缓解短期到中期的困难，让互联网在长期解决方案取得进展的同时继续有效运行。
More historical background on this effort and on the ROAD group may be found in [RFC1380] and at [LWRD].
[RFC1380]和[LWRD]中可以找到关于这项工作和道路组的更多历史背景。
The solution that the community created was to deprecate the Class A/B/C network address assignment system in favor of using "classless", hierarchical blocks of IP addresses (referred to as prefixes). The assignment of prefixes is intended to roughly follow the underlying Internet topology so that aggregation can be used to facilitate scaling of the global routing system. One implication of this strategy is that prefix assignment and aggregation is generally done according to provider-subscriber relationships, since that is how the Internet topology is determined.
社区创建的解决方案是不赞成A/B/C类网络地址分配系统，而赞成使用“无类”、分层的IP地址块（称为前缀）。前缀的分配旨在大致遵循基础Internet拓扑结构，以便可以使用聚合来促进全局路由系统的扩展。该策略的一个含义是前缀分配和聚合通常根据提供商-订户关系进行，因为这是确定Internet拓扑的方式。
When originally proposed in [RFC1338] and [RFC1519], this addressing plan was intended to be a relatively short-term response, lasting approximately three to five years, during which a more permanent addressing and routing architecture would be designed and implemented. As can be inferred from the dates on the original documents, CIDR has far outlasted its anticipated lifespan and has become the mid-term solution to the problems described above.
最初在[RFC1338]和[RFC1519]中提出时，该寻址计划旨在作为一个相对短期的响应，持续大约三到五年，在此期间将设计和实施一个更永久的寻址和路由架构。从原始文件上的日期可以推断，CIDR已远远超过其预期寿命，并已成为上述问题的中期解决方案。
Note that in the following text we describe the current policies and procedures that have been put in place to implement the allocation architecture discussed here. This description is not intended to be interpreted as direction to IANA.
请注意，在下面的文本中，我们描述了为实现此处讨论的分配体系结构而实施的当前策略和过程。本说明不打算解释为对IANA的指示。
Coupled with address management strategies implemented by the Regional Internet Registries (see [NRO] for details), the deployment of CIDR-style addressing has also reduced the rate at which IPv4 address space has been consumed, thus providing short- to medium-term relief to problem #3, described above.
加上区域互联网注册中心实施的地址管理策略（详见[NRO]），CIDR式寻址的部署也降低了IPv4地址空间的消耗率，从而为上述问题3提供了中短期缓解。
Note that, as defined, this plan neither requires nor assumes the re-assignment of those parts of the legacy "Class C" space that are not amenable to aggregation (sometimes called "the swamp"). Doing so would somewhat reduce routing table sizes (current estimate is that "the swamp" contains approximately 15,000 entries), though at a significant renumbering cost. Similarly, there is no hard requirement that any end site renumber when changing transit service provider, but end sites are encouraged do so to eliminate the need for explicit advertisement of their prefixes into the global routing system.
请注意，根据定义，本计划既不要求也不假设重新分配不适合聚合的遗留“C类”空间部分（有时称为“沼泽”）。这样做会在一定程度上减少路由表的大小（目前的估计是“沼泽”包含大约15000个条目），尽管重新编号的成本很大。同样，没有硬性要求任何终端站点在更换公交服务提供商时重新编号，但鼓励终端站点这样做，以消除在全球路由系统中明确公布其前缀的需要。
In the simplest sense, the change from Class A/B/C network numbers to classless prefixes is to make explicit which bits in a 32-bit IPv4 address are interpreted as the network number (or prefix) associated with a site and which are the used to number individual end systems within the site. In CIDR notation, a prefix is shown as a 4-octet quantity, just like a traditional IPv4 address or network number, followed by the "/" (slash) character, followed by a decimal value between 0 and 32 that describes the number of significant bits.
从最简单的意义上讲，从A/B/C类网络号到无类前缀的变化是为了明确说明32位IPv4地址中的哪些位被解释为与站点相关联的网络号（或前缀），哪些位被用来对站点内的各个终端系统进行编号。在CIDR表示法中，前缀显示为4个八位组的数量，就像传统的IPv4地址或网络号一样，后跟“/”（斜杠）字符，后跟0到32之间的十进制值，用于描述有效位的数量。
For example, the legacy "Class B" network 172.16.0.0, with an implied network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16, the "/16" indicating that the mask to extract the network portion of the prefix is a 32-bit value where the most significant 16 bits are ones and the least significant 16 bits are zeros. Similarly, the legacy "Class C" network number 192.168.99.0 is defined as the prefix 192.168.99.0/24; the most significant 24 bits are ones and the least significant 8 bits are zeros.
例如，隐含网络掩码为255.255.0.0的传统“B类”网络172.16.0.0被定义为前缀172.16.0.0/16，“/16”表示提取前缀的网络部分的掩码是32位值，其中最高有效16位为1，最低有效16位为0。类似地，传统的“C类”网络号192.168.99.0被定义为前缀192.168.99.0/24；最高有效24位为1，最低有效8位为0。
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).
使用具有显式前缀长度的无类前缀，可以根据实际需要更灵活地匹配地址空间块。在以前只有三种网络大小可用的情况下，可以定义前缀来描述一个和2^32终端系统地址之间的两个大小的块的任意幂。实际上，未分配的地址池由Internet分配号码管理局（[IANA]）管理。IANA根据需要从该池向区域互联网注册中心进行分配。这些分配是在2^24个地址（也称为/8个前缀）的连续位对齐块中进行的。区域互联网注册中心（RIR）依次向本地互联网注册中心（LIR）或互联网服务提供商（ISP）分配或分配较小的地址块。这些实体可以直接使用分配（ISP通常是这样），或者可以向其客户进一步分配地址。这些RIR地址分配根据每个ISP或LIR的需要而变化。例如，大型ISP可能会被分配一个2^17地址的地址块（a/15前缀），而小型ISP可能会被分配一个2^11地址的地址块（a/21前缀）。
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:
下表提供了所有CIDR前缀大小的便捷快捷方式，显示了每个前缀中可能的地址数以及32位IPv4地址空间中可能编号的该大小的前缀数：
notation addrs/block # blocks
-------- ----------- ----------
n.n.n.n/32 1 4294967296 "host route"
n.n.n.x/31 2 2147483648 "p2p link"
n.n.n.x/30 4 1073741824
n.n.n.x/29 8 536870912
n.n.n.x/28 16 268435456
n.n.n.x/27 32 134217728
n.n.n.x/26 64 67108864
n.n.n.x/25 128 33554432
n.n.n.0/24 256 16777216 legacy "Class C"
n.n.x.0/23 512 8388608
n.n.x.0/22 1024 4194304
n.n.x.0/21 2048 2097152
n.n.x.0/20 4096 1048576
n.n.x.0/19 8192 524288
n.n.x.0/18 16384 262144
n.n.x.0/17 32768 131072
n.n.0.0/16 65536 65536 legacy "Class B"
n.x.0.0/15 131072 32768
n.x.0.0/14 262144 16384
n.x.0.0/13 524288 8192
n.x.0.0/12 1048576 4096
n.x.0.0/11 2097152 2048
n.x.0.0/10 4194304 1024
n.x.0.0/9 8388608 512
n.0.0.0/8 16777216 256 legacy "Class A"
x.0.0.0/7 33554432 128
x.0.0.0/6 67108864 64
x.0.0.0/5 134217728 32
x.0.0.0/4 268435456 16
x.0.0.0/3 536870912 8
x.0.0.0/2 1073741824 4
x.0.0.0/1 2147483648 2
0.0.0.0/0 4294967296 1 "default route"
notation addrs/block # blocks
-------- ----------- ----------
n.n.n.n/32 1 4294967296 "host route"
n.n.n.x/31 2 2147483648 "p2p link"
n.n.n.x/30 4 1073741824
n.n.n.x/29 8 536870912
n.n.n.x/28 16 268435456
n.n.n.x/27 32 134217728
n.n.n.x/26 64 67108864
n.n.n.x/25 128 33554432
n.n.n.0/24 256 16777216 legacy "Class C"
n.n.x.0/23 512 8388608
n.n.x.0/22 1024 4194304
n.n.x.0/21 2048 2097152
n.n.x.0/20 4096 1048576
n.n.x.0/19 8192 524288
n.n.x.0/18 16384 262144
n.n.x.0/17 32768 131072
n.n.0.0/16 65536 65536 legacy "Class B"
n.x.0.0/15 131072 32768
n.x.0.0/14 262144 16384
n.x.0.0/13 524288 8192
n.x.0.0/12 1048576 4096
n.x.0.0/11 2097152 2048
n.x.0.0/10 4194304 1024
n.x.0.0/9 8388608 512
n.0.0.0/8 16777216 256 legacy "Class A"
x.0.0.0/7 33554432 128
x.0.0.0/6 67108864 64
x.0.0.0/5 134217728 32
x.0.0.0/4 268435456 16
x.0.0.0/3 536870912 8
x.0.0.0/2 1073741824 4
x.0.0.0/1 2147483648 2
0.0.0.0/0 4294967296 1 "default route"
n is an 8-bit decimal octet value. Point-to-point links are discussed in more detail in [RFC3021].
n是8位十进制八位字节值。[RFC3021]中详细讨论了点到点链路。
x is a 1- to 7-bit value, based on the prefix length, shifted into the most significant bits of the octet and converted into decimal form; the least significant bits of the octet are zero.
x是一个1到7位的值，基于前缀长度，移位为八位字节的最高有效位，并转换为十进制形式；八位字节的最低有效位为零。
In practice, prefixes of length shorter than 8 have not been allocated or assigned to date, although routes to such short prefixes may exist in routing tables if or when aggressive aggregation is performed. As of the writing of this document, no such routes are seen in the global routing system, but operator error and other events have caused some of them (i.e., 128.0.0.0/1 and 192.0.0.0/2) to be observed in some networks at some times in the past.
实际上，长度小于8的前缀尚未分配或分配到date，尽管在执行主动聚合时，路由表中可能存在指向这些短前缀的路由。截至本文件编写之时，全球路由系统中未发现此类路由，但运营商错误和其他事件已导致其中一些路由（即128.0.0.0/1和192.0.0.0/2）在过去的某些时间在某些网络中被观察到。
Classless addressing and routing was initially developed primarily to improve the scaling properties of routing on the global Internet. Because the scaling of routing is very tightly coupled to the way that addresses are used, deployment of CIDR had implications for the way in which addresses were assigned.
无类别寻址和路由最初的开发主要是为了改善全球互联网上路由的可伸缩性。因为路由的扩展与地址的使用方式紧密耦合，所以CIDR的部署对地址的分配方式有影响。
The only commonly understood method for reducing routing state on a packet-switched network is through aggregation of information. For CIDR to succeed in reducing the size and growth rate of the global routing system, the IPv4 address assignment process needed to be changed to make possible the aggregation of routing information along topological lines. Since, in general, the topology of the network is determined by the service providers who have built it, topologically significant address assignments are necessarily service-provider oriented.
降低分组交换网络上路由状态的唯一普遍理解的方法是通过信息聚合。为了使CIDR能够成功地减小全局路由系统的规模和增长率，需要更改IPv4地址分配过程，以便能够沿拓扑线聚合路由信息。由于一般来说，网络的拓扑由构建它的服务提供商决定，因此拓扑上重要的地址分配必然是面向服务提供商的。
Aggregation is simple for an end site that is connected to one service provider: it uses address space assigned by its service provider, and that address space is a small piece of a larger block allocated to the service provider. No explicit route is needed for the end site; the service provider advertises a single aggregate route for the larger block. This advertisement provides reachability and routeability for all the customers numbered in the block.
聚合对于连接到一个服务提供商的终端站点来说很简单：它使用由其服务提供商分配的地址空间，而该地址空间是分配给服务提供商的较大块中的一小块。终点不需要明确的路线；服务提供商为较大的块播发单个聚合路由。此广告为区块中编号的所有客户提供可达性和路由性。
There are two, more complex, situations that reduce the effectiveness of aggregation:
有两种更复杂的情况会降低聚合的有效性：
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 多总部的组织。由于多宿组织必须由其每个服务提供商在系统中发布广告，因此将其路由信息聚合到其中任何一个提供商的地址空间通常是不可行的。请注意，组织仍然可以从服务提供商的地址空间接收其地址分配（这有其他优势），但在最一般的情况下，到组织前缀的路由由其所有服务提供商显式公布。由于这个原因
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之前相同。[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 更改服务提供商但不重新编号的组织。这会在原始服务提供商的一个聚合路由广告中产生“打孔”的效果。CIDR通过要求较新的服务提供商为重新安置的组织发布特定广告来处理这种情况；此播发优先于提供商聚合，因为它是一个较长的匹配项。为了保持聚合效率，建议更改服务提供商的组织最终计划将其网络迁移到从其新提供商的地址空间分配的前缀中。为此，建议尽可能部署促进此类迁移的机制，如使用[RFC2131]的动态主机地址分配，并开展额外的协议工作，以开发改进的重新编号技术。
Note that some aggregation efficiency gain can still be had for multi-homed sites (and, in general, for any site composed of multiple, logical IPv4 networks); by allocating a contiguous power-of-two block address space to the site (as opposed to multiple, independent prefixes), the site's routing information may be aggregated into a single prefix. Also, since the routing cost associated with assigning a multi-homed site out of a service provider's address space is no greater than the old method of sequential number assignment by a central authority, it makes sense to assign all end-site address space out of blocks allocated to service providers.
请注意，对于多主站点（通常，对于由多个逻辑IPv4网络组成的任何站点），仍然可以获得一些聚合效率增益；通过向站点分配两个块地址空间的连续幂（与多个独立前缀相反），站点的路由信息可以聚合为单个前缀。此外，由于与从服务提供商的地址空间分配多址站点相关的路由成本不大于由中央机构分配序列号的旧方法，因此从分配给服务提供商的块中分配所有终端站点地址空间是有意义的。
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.
还值得一提的是，由于聚合可能发生在系统中的多个级别，因此仍有可能将这些异常路由聚合到可能存在的任何层次的更高级别。例如，如果一个站点由两个相对较小的提供商多宿，且这两个提供商都从同一个大型提供商获得连接和地址空间，则大型提供商对来自较小网络的路由的聚合将包括到多宿站点的所有路由。这种二级聚合的可行性取决于站点、其直接连接的提供者以及它们所连接的其他提供者之间是否存在拓扑层次结构；它在全球互联网的某些地区可能是可行的，但在其他地区却不可行。
Note: In the discussion and examples that follow, prefix notation is used to represent routing destinations. This is used for illustration only and does not require that routing protocols use this representation in their updates.
注意：在下面的讨论和示例中，前缀符号用于表示路由目的地。这仅用于说明，不要求路由协议在其更新中使用此表示。
In the early days of the Internet, IPv4 address space assignment was performed by the central Network Information Center (NIC). Class A/B/C network numbers were assigned in essentially arbitrary order, roughly according to the size of the organizations that requested them. All assignments were recorded centrally, and no attempt was made to assign network numbers in a manner that would allow routing aggregation.
在互联网的早期，IPv4地址空间分配由中央网络信息中心（NIC）执行。A/B/C类网络编号基本上是按任意顺序分配的，大致取决于请求它们的组织的大小。所有分配都集中记录，未尝试以允许路由聚合的方式分配网络号。
When CIDR was originally deployed, the central assignment authority continued to exist but changed its procedures to assign large blocks of "Class C" network numbers to each service provider. Each service provider, in turn, assigned bitmask-oriented subsets of the provider's address space to each customer. This worked reasonably well, as long as the number of service providers was relatively small and relatively constant, but it did not scale well, as the number of service providers grew at a rapid rate.
最初部署CIDR时，中央分配机构仍然存在，但改变了其程序，将大量“C类”网络号分配给每个服务提供商。每个服务提供商依次将面向位掩码的提供商地址空间子集分配给每个客户。只要服务提供商的数量相对较少且相对稳定，这种做法就相当有效，但由于服务提供商的数量快速增长，其规模不太大。
As the Internet started to expand rapidly in the 1990s, it became clear that a single, centralized address assignment authority was problematic. This function began being de-centralized when address space assignment for European Internet sites was delegated in bit-aligned blocks of 16777216 addresses (what CIDR would later define as a /8) to the RIPE NCC ([RIPE]), effectively making it the first of the RIRs. Since then, address assignment has been formally distributed as a hierarchical function with IANA, the RIRs, and the service providers. Removing the bottleneck of a single organization having responsibility for the global Internet address space greatly improved the efficiency and response time for new assignments.
随着互联网在20世纪90年代开始迅速发展，一个单一的、集中的地址分配机构显然存在问题。当欧洲互联网站点的地址空间分配在16777216个地址（CIDR后来将其定义为a/8）的位对齐块中委托给成熟的NCC（[RIME]）时，该功能开始去中心化，有效地使其成为第一个RIR。从那时起，地址分配已正式作为一种分层功能与IANA、RIR和服务提供商一起分发。消除了单一组织负责全球互联网地址空间的瓶颈，大大提高了新任务的效率和响应时间。
Hierarchical delegation of addresses in this manner implies that sites with addresses assigned out of a given service provider are, for routing purposes, part of that service provider and will be routed via its infrastructure. This implies that routing information about multi-homed organizations (i.e., organizations connected to more than one network service provider) will still need to be known by higher levels in the hierarchy.
以这种方式进行的地址分层委托意味着，出于路由目的，从给定服务提供商分配地址的站点是该服务提供商的一部分，并将通过其基础设施进行路由。这意味着有关多宿组织（即，连接到多个网络服务提供商的组织）的路由信息仍需要由层次结构中的更高级别知道。
A historical perspective on these issues is described in [RFC1518]. Additional discussion may also be found in [RFC3221].
[RFC1518]中描述了这些问题的历史观点。更多讨论也可参见[RFC3221]。
With the change from classful network numbers to classless prefixes, it is not possible to infer the network mask from the initial bit pattern of an IPv4 address. This has implications for how routing information is stored and propagated. Network masks or prefix lengths must be explicitly carried in routing protocols. Interior routing protocols, such as OSPF [RFC2328], Intermediate System to Intermediate System (IS-IS) [RFC1195], RIPv2 [RFC2453], and Cisco Enhanced Interior Gateway Routing Protocol (EIGRP), and the BGP4 exterior routing protocol [RFC4271], all support this functionality, having been developed or modified as part of the deployment of classless inter-domain routing during the 1990s.
随着从有类网络号到无类前缀的更改，无法从IPv4地址的初始位模式推断网络掩码。这意味着路由信息的存储和传播方式。路由协议中必须显式地携带网络掩码或前缀长度。例如，Cisco的内部路由协议是[RFC2453]、Cisco的内部路由协议[RFC2453]、Cisco的内部路由协议[RFC2453]、Cisco的内部路由协议[RFC2453]、Cisco的内部路由协议[RFP43]、Cisco的内部路由协议[RFC2453]、Cisco的内部路由协议和内部路由协议，在20世纪90年代，作为无类域间路由部署的一部分进行了开发或修改。
Older interior routing protocols, such as RIP [RFC1058], HELLO, and Cisco Interior Gateway Routing Protocol (IGRP), and older exterior routing protocols, such as Exterior Gateway Protocol (EGP) [RFC904], do not support explicit carriage of prefix length/mask and thus cannot be effectively used on the Internet other than in very limited stub configurations. Although their use may be appropriate in simple legacy end-site configurations, they are considered obsolete and should NOT be used in transit networks connected to the global Internet.
旧的内部路由协议，如RIP[RFC1058]、HELLO和Cisco内部网关路由协议（IGRP），以及旧的外部路由协议，如外部网关协议（EGP）[RFC904]，不支持前缀长度/掩码的显式传输，因此除了在非常有限的存根配置中，不能在Internet上有效使用。虽然它们的使用可能适合于简单的传统终端站点配置，但它们被认为是过时的，不应在连接到全球互联网的运输网络中使用。
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.
类似地，第三层网络设备中的路由和转发表必须组织为存储前缀和前缀长度或掩码。根据传统的A/B/C类网络/子网约定组织其路由/转发信息的设备无法在连接到全球互联网的网络上正常工作；不建议使用此类设备。幸运的是，目前使用的此类设备很少。
1. Forwarding in the Internet is done on a longest-match basis. This implies that destinations that are multi-homed relative to a routing domain must always be explicitly announced into that routing domain (i.e., they cannot be summarized). If a network is multi-homed, all of its paths into a routing domain that is "higher" in the hierarchy of networks must be known to the "higher" network).
1. Internet中的转发是在最长匹配的基础上进行的。这意味着相对于路由域的多宿目的地必须始终显式地通知到该路由域中（即，不能对其进行汇总）。如果一个网络是多宿网络，则其进入网络层次结构中“较高”的路由域的所有路径必须为“较高”网络所知。
2. A router that generates an aggregate route for multiple, more-specific routes must discard packets that match the aggregate route, but not any of the more-specific routes. In other words, the "next hop" for the aggregate route should be the null destination. This is necessary to prevent forwarding loops when some addresses covered by the aggregate are not reachable.
2. 为多个更具体的路由生成聚合路由的路由器必须丢弃与聚合路由匹配的数据包，但不能丢弃任何更具体的路由。换句话说，聚合路由的“下一跳”应该是空目的地。当无法访问聚合所覆盖的某些地址时，这是防止转发循环所必需的。
Note that during failures, partial routing of traffic to a site that takes its address space from one service provider but that is actually reachable only through another (i.e., the case of a site that has changed service providers) may occur because such traffic will be forwarded along the path advertised by the aggregated route. Rule #2 will prevent packet misdelivery by causing such traffic to be discarded by the advertiser of the aggregated route, but the output of "traceroute" and other similar tools will suggest that a problem exists within that network rather than in the network that is no longer advertising the more-specific prefix. This may be confusing to those trying to diagnose connectivity problems; see the example in Section 6.2 for details. A solution to this perceived "problem" is beyond the scope of this document; it lies with better education of the user/operator community, not in routing technology.
注意，在这种情况下，从一个站点到另一个站点的流量实际上是可以通过一个站点的路由空间进行转发的，但在这种情况下，该站点的流量实际上是可以通过另一个站点的路由空间进行转发的。规则#2将通过导致聚合路由的广告商丢弃此类流量来防止数据包误发，但“traceroute”和其他类似工具的输出将表明该网络中存在问题，而不是不再宣传更具体前缀的网络中存在问题。这可能会让那些试图诊断连接问题的人感到困惑；有关详细信息，请参见第6.2节中的示例。该“问题”的解决方案超出了本文件的范围；这取决于更好地教育用户/运营商社区，而不是路由技术。
An implementation following these rules should also be generalized, so that an arbitrary network number and mask are accepted for all routing destinations. The only outstanding constraint is that the mask must be left contiguous. Note that the degenerate route to prefix 0.0.0.0/0 is used as a default route and MUST be accepted by all implementations. Further, to protect against accidental advertisements of this route via the inter-domain protocol, this route should only be advertised to another routing domain when a router is explicitly configured to do so, never as a non-configured, "default" option.
还应推广遵循这些规则的实现，以便为所有路由目的地接受任意网络号和掩码。唯一突出的约束是掩码必须保持连续。请注意，到前缀0.0.0.0/0的退化路由用作默认路由，并且必须为所有实现所接受。此外，为了防止通过域间协议意外播发该路由，只有当路由器被明确配置为这样做时，才应该将该路由播发到另一个路由域，而不是作为未配置的“默认”选项。
Rule #1 guarantees that the forwarding algorithm used is consistent across routing protocols and implementations. Multi-homed networks are always explicitly advertised by every service provider through which they are routed, even if they are a specific subset of one service provider's aggregate (if they are not, they clearly must be explicitly advertised). It may seem as if the "primary" service provider could advertise the multi-homed site implicitly as part of its aggregate, but longest-match forwarding causes this not to work. More details are provided in [RFC4116].
规则#1保证所使用的转发算法在路由协议和实现之间是一致的。多宿网络始终由路由它们的每个服务提供商显式公布，即使它们是一个服务提供商集合的特定子集（如果不是，则显然必须显式公布）。似乎“主要”服务提供商可以隐式地将多宿主站点作为其聚合的一部分进行广告宣传，但最长匹配转发会导致此功能无法工作。更多详细信息请参见[RFC4116]。
Rule #2 guarantees that no routing loops form due to aggregation. Consider a site that has been assigned 192.168.64/19 by its "parent" provider, which has 192.168.0.0/16. The "parent" network will advertise 192.168.0.0/16 to the "child" network. If the "child" network were to lose internal connectivity to 192.168.65.0/24 (which is part of its aggregate), traffic from the "parent" to the to the "child" destined for 192.168.65.1 will follow the "child's" advertised route. When that traffic gets to the "child", however, the child *must not* follow the route 192.168.0.0/16 back up to the "parent", since that would result in a forwarding loop. Rule #2 says
规则#2保证不会由于聚合而形成路由循环。考虑一个被其“父”提供者分配192.1686/19的站点，该站点具有192.1680.0/16。“父”网络将向“子”网络公布192.168.0.0/16。如果“子”网络失去到192.168.65.0/24的内部连接（这是其聚合的一部分），则从“父”到“子”到192.168.65.1的流量将遵循“子”公布的路由。但是，由于子循环中的“168.0”将不会返回到子循环中的“168.0”，因此该子循环将不会返回到“168.0”。规则2说
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.
对于与其自身聚合路由之一相匹配的目的地，“子”不能遵循不太特定的路由（通常，这是通过为一个网络向另一个网络播发的所有聚合前缀安装“丢弃”或“空”路由来实现的）。注意，“默认”路由（0.0.0.0/0）的处理是本规则的特例；网络不得遵循作为其聚合广告一部分的目标的默认设置。
Systems that process route announcements must be able to verify that information that they receive is acceptable according to policy rules. Implementations that filter route advertisements must allow masks or prefix lengths in filter elements. Thus, filter elements that formerly were specified as
处理路线公告的系统必须能够根据策略规则验证其接收的信息是否可接受。筛选路由播发的实现必须允许筛选元素中的掩码或前缀长度。因此，以前指定为
accept 172.16.0.0 accept 172.25.120.0.0 accept 172.31.0.0 deny 10.2.0.0 accept 10.0.0.0
接受172.16.0.0接受172.25.120.0.0接受172.31.0.0拒绝10.2.0.0接受10.0.0.0
now look something like this:
现在看起来像这样：
accept 172.16.0.0/16 accept 172.25.0.0/16 accept 172.31.0.0/16 deny 10.2.0.0/16 accept 10.0.0.0/8
接受172.16.0.0/16接受172.25.0.0/16接受172.31.0.0/16拒绝10.2.0.0/16接受10.0.0.0/8
This is merely making explicit the network mask that was implied by the Class A/B/C classification of network numbers. It is also useful to enhance filtering capability to allow the match of a prefix and all more-specific prefixes with the same bit pattern; fortunately, this functionality has been implemented by most vendors of equipment used on the Internet.
这仅仅是明确表示网络编号的A/B/C类分类所隐含的网络掩码。增强过滤能力以允许前缀与具有相同比特模式的所有更具体前缀的匹配也是有用的；幸运的是，互联网上使用的大多数设备供应商都实现了这一功能。
Under normal circumstances, a routing domain (or "Autonomous System") that has been allocated or assigned a set of prefixes has sole responsibility for aggregation of those prefixes. In the usual case, the AS will install configuration in one or more of its routers to generate aggregate routes based on more-specific routes known to its internal routing system. These aggregate routes are advertised into the global routing system by the border routers for the routing domain. The more-specific internal routes that overlap with the aggregate routes should not be advertised globally. In some cases,
在正常情况下，已分配或分配一组前缀的路由域（或“自治系统”）全权负责这些前缀的聚合。在通常情况下，AS将在其一个或多个路由器中安装配置，以基于其内部路由系统已知的更具体路由生成聚合路由。这些聚合路由由路由域的边界路由器发布到全局路由系统中。与聚合路由重叠的更具体的内部路由不应在全球范围内发布。在某些情况下，
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（例如，客户可能希望其服务提供商代表其生成聚合路由信息）；在这种情况下，第二个路由器根据从第一个路由器接收到的路由，结合描述这些路由应如何聚合的配置策略信息，执行聚合。
Note that one provider may choose to perform aggregation on the routes it receives from another without explicit agreement; this is termed "proxy aggregation". This can be a useful tool for reducing the amount of routing state that an AS must carry and propagate to its customers and neighbors. However, proxy aggregation can also create unintended consequences in traffic engineering. Consider what happens if both AS 2 and 3 receive routes from AS 1 but AS 2 performs proxy aggregation while AS 3 does not. Other ASes that receive transit routing information from both AS 2 and AS 3 will see an inconsistent view of the routing information originated by AS 1. This may cause an unexpected shift of traffic toward AS 1 through AS 3 for AS 3's customers and any others receiving transit routes from AS 3. Because proxy aggregation can cause unanticipated consequences for parts of the Internet that have no relationship with either the source of the aggregated routes or the party providing aggregation, it should be used with extreme caution.
请注意，一个提供商可以选择在未经明确同意的情况下对其从另一个提供商接收的路由执行聚合；这被称为“代理聚合”。这是一个有用的工具，可以减少AS必须携带并传播给其客户和邻居的路由状态量。然而，代理聚合也会在流量工程中产生意外后果。考虑如果两个AS 2和3从As 1接收路由，但是当2执行代理聚合而3不接收时会发生什么。从AS 2和AS 3接收中转路由信息的其他ASE将看到由AS 1生成的路由信息视图不一致。这可能会导致AS 3的客户和从AS 3接收中转路线的任何其他客户的交通意外转向AS 1到AS 3。由于代理聚合可能会对与聚合路由的来源或提供聚合的一方没有任何关系的Internet部分造成意外后果，因此应极其小心地使用代理聚合。
Configuration of the routes to be combined into aggregates is an implementation of routing policy and requires some manually maintained information. As an addition to the information that must be maintained for a set of routeable prefixes, aggregation configuration is typically just a line or two defining the range of the block of IPv4 addresses to be aggregated. A site performing its own aggregation is doing so for address blocks that it has been assigned; a site performing aggregation on behalf of another knows this information because of an agreement to delegate aggregation. Assuming that the best common practice for network administrators is to exchange lists of prefixes to accept from each other, configuration of aggregation information does not introduce significant additional administrative overhead.
要组合到聚合中的路由的配置是路由策略的实现，需要一些手动维护的信息。作为一组可路由前缀必须维护的信息的补充，聚合配置通常只是定义要聚合的IPv4地址块范围的一两行。执行自身聚合的站点正在为其分配的地址块执行聚合；代表另一个站点执行聚合的站点知道此信息，因为有委托聚合的协议。假设网络管理员的最佳常见做法是交换前缀列表以相互接受，则聚合信息的配置不会带来显著的额外管理开销。
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.
聚合路由的生成通常是静态指定的，或者是响应于学习聚合路由中包含的前缀的活动动态路由。如果进行了此类动态聚合路线广告，则应注意不要过度添加或删除路线（称为“路线摆动”）。通常，当聚合的至少一个组件变得可访问时，添加动态聚合路由播发，并且仅当所有组件变得不可访问时，才撤回动态聚合路由播发。正确配置后，聚合路由比非聚合路由更稳定，从而提高全局路由稳定性。
Implementation note: Aggregation of the "Class D" (multicast) address space is beyond the scope of this document.
实施说明：“D类”（多播）地址空间的聚合超出了本文档的范围。
Prior to the original deployment of CIDR, common practice was to propagate routes learned via exterior routing protocols (i.e., EGP or BGP) through a site's interior routing protocol (typically, OSPF, IS-IS, or RIP). This was done to ensure that consistent and correct exit points were chosen for traffic to be sent to a destination learned through those protocols. Four evolutionary effects -- the advent of CIDR, explosive growth of global routing state, widespread adoption of BGP4, and a requirement to propagate full path information -- have combined to deprecate that practice. To ensure proper path propagation and prevent inter-AS routing inconsistency (BGP4's loop detection/prevention mechanism requires full path propagation), transit networks must use internal BGP (iBGP) for carrying routes learned from other providers both within and through their networks.
在最初部署CIDR之前，通常的做法是通过站点的内部路由协议（通常为OSPF、IS-IS或RIP）传播通过外部路由协议（即EGP或BGP）学习的路由。这样做是为了确保选择一致且正确的出口点，以便将流量发送到通过这些协议了解的目的地。四种进化效应——CIDR的出现、全局路由状态的爆炸性增长、BGP4的广泛采用以及传播完整路径信息的要求——共同反对了这种做法。为确保正确的路径传播并防止AS间路由不一致（BGP4的环路检测/预防机制要求完整的路径传播），公交网络必须使用内部BGP（iBGP）来承载从其网络内和通过其网络的其他提供商处获知的路由。
Consider the block of 524288 (2^19) addresses, beginning with 10.24.0.0 and ending with 10.31.255.255, allocated to a single network provider, "PA". This is equivalent in size to a block of 2048 legacy "Class C" network numbers (or /24s). A classless route to this block would be described as 10.24.0.0 with a mask of 255.248.0.0 and the prefix 10.24.0.0/13.
考虑524288个（2 ^ 19）地址的块，从1024.0.0开始，以1031.255.255结尾，分配给一个单一的网络提供者“PA”。这在大小上相当于2048个传统“C类”网络号（或/24）的块。到该区块的无类别路由将被描述为10.24.0.0，掩码为255.248.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):
假设此服务提供商按以下顺序连接六个站点（这很重要，因为它演示了如何在服务提供商的地址空间中形成临时“漏洞”）：
o "C1", requiring fewer than 2048 addresses (/21 or 8 x /24)
o “C1”，要求少于2048个地址（/21或8 x/24）
o "C2", requiring fewer than 4096 addresses (/20 or 16 x /24)
o “C2”，要求少于4096个地址（/20或16 x/24）
o "C3", requiring fewer than 1024 addresses (/22 or 4 x /24)
o “C3”，需要少于1024个地址（/22或4 x/24）
o "C4", requiring fewer than 1024 addresses (/22 or 4 x /24)
o “C4”，需要少于1024个地址（/22或4 x/24）
o "C5", requiring fewer than 512 addresses (/23 or 2 x /24)
o “C5”，要求少于512个地址（/23或2x/24）
o "C6", requiring fewer than 512 addresses (/23 or 2 x /24)
o “C6”，要求少于512个地址（/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。分配10.24.0至10.24.7。该网络块由路由10.24.0.0/21（掩码255.255.248.0）描述。
o C2. Assign 10.24.16 through 10.24.31. This block is described by the route 10.24.16.0/20 (mask 255.255.240.0).
o C2。分配10.24.16至10.24.31。该区块由路线10.24.16.0/20（掩码255.255.240.0）描述。
o C3. Assign 10.24.8 through 10.24.11. This block is described by the route 10.24.8.0/22 (mask 255.255.252.0).
o C3。分配10.24.8至10.24.11。该区块由路线10.24.8.0/22（掩码255.255.252.0）描述。
o C4. Assign 10.24.12 through 10.24.15. This block is described by the route 10.24.12.0/22 (mask 255.255.252.0).
o 补体第四成份。分配10.24.12至10.24.15。该区块由路线10.24.12.0/22（掩码255.255.252.0）描述。
o C5. Assign 10.24.32 and 10.24.33. This block is described by the route 10.24.32.0/23 (mask 255.255.254.0).
o C5。分配10.24.32和10.24.33。该区块由路线10.24.32.0/23（掩码255.255.254.0）描述。
o C6. Assign 10.24.34 and 10.24.35. This block is described by the route 10.24.34.0/23 (mask 255.255.254.0).
o C6。分配10.24.34和10.24.35。该区块由路线10.24.34.0/23（掩码255.255.254.0）描述。
These six sites should be represented as six prefixes of varying size within the provider's IGP. If, for some reason, the provider uses an obsolete IGP that doesn't support classless routing or variable-length subnets, then explicit routes for all /24s will have to be carried.
这六个站点应表示为提供商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的（下一个）2048 x/24块。
o C7. Assign 10.32.0 through 10.32.15. This block is described by the route 10.32.0.0/20 (mask 255.255.240.0).
o C7。分配10.32.0到10.32.15。该区块由管线10.32.0.0/20（掩码255.255.240.0）描述。
For the multi-homed sites, assume that C4 is advertised as primary via "RA" and secondary via "RB"; and that C5 is primary via "RB" and secondary via "RA". In addition, assume that "RA" and "RB" are both connected to the same transit service provider, "BB".
对于多主站点，假设C4通过“RA”作为主站点，通过“RB”作为辅助站点；C5是通过“RB”的初级通道，通过“RA”的次级通道。此外，假设“RA”和“RB”都连接到同一个公交服务提供商“BB”。
Graphically, this topology looks something like this:
从图形上看，此拓扑结构如下所示：
10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0
C1: 10.24.0.0/21 \ / C7: 10.32.0.0/20
\ /
+----+ +----+
10.24.16.0 - 10.24.31.0_ | | | |
C2: 10.24.16.0/20 \ | | _10.24.12.0 - 10.24.15.0__ | |
\| | / C4: 10.24.12.0/20 \ | |
| |/ \| |
10.24.8.0 - 10.24.11.0___/| PA |\ | PB |
C3: 10.24.8.0/22 | | \__10.24.32.0 - 10.24.33.0___| |
| | C5: 10.24.32.0/23 | |
| | | |
10.24.34.0 - 10.24.35.0__/| | | |
C6: 10.24.34.0/23 | | | |
+----+ +----+
|| ||
routing advertisements: || ||
|| ||
10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) ||
10.32.0.0/20 (C7) || 10.24.32.0/23 (C5) ||
10.24.0.0/13 (PA) || 10.32.0.0/13 (PB) ||
|| ||
VV VV
+---------- BACKBONE NETWORK BB ----------+
10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0
C1: 10.24.0.0/21 \ / C7: 10.32.0.0/20
\ /
+----+ +----+
10.24.16.0 - 10.24.31.0_ | | | |
C2: 10.24.16.0/20 \ | | _10.24.12.0 - 10.24.15.0__ | |
\| | / C4: 10.24.12.0/20 \ | |
| |/ \| |
10.24.8.0 - 10.24.11.0___/| PA |\ | PB |
C3: 10.24.8.0/22 | | \__10.24.32.0 - 10.24.33.0___| |
| | C5: 10.24.32.0/23 | |
| | | |
10.24.34.0 - 10.24.35.0__/| | | |
C6: 10.24.34.0/23 | | | |
+----+ +----+
|| ||
routing advertisements: || ||
|| ||
10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) ||
10.32.0.0/20 (C7) || 10.24.32.0/23 (C5) ||
10.24.0.0/13 (PA) || 10.32.0.0/13 (PB) ||
|| ||
VV VV
+---------- BACKBONE NETWORK BB ----------+
To follow rule #1, PA will need to advertise the block of addresses that it was given and C7. Since C4 is multi-homed and primary through PA, it must also be advertised. C5 is multi-homed and primary through PB. In principle (and in the example above), it need not be advertised, since longest match by PB will automatically select PB as primary and the advertisement of PA's aggregate will be used as a secondary. In actual practice, C5 will normally be advertised via both providers.
为了遵循规则#1，PA需要公布它所给出的地址块和C7。由于C4是通过PA的多宿主和主节点，因此也必须对其进行宣传。C5是多宿的，主要通过PB。原则上（以及在上面的示例中），不需要公布，因为PB的最长匹配将自动选择PB作为主要匹配，PA的聚合的公布将用作次要匹配。在实际操作中，C5通常会通过两家供应商进行广告宣传。
Advertisements from "PA" to "BB" will be
从“PA”到“BB”的广告将被删除
10.24.12.0/22 primary (advertises C4) 10.32.0.0/20 primary (advertises C7) 10.24.0.0/13 primary (advertises remainder of PA)
10.24.12.0/22主要（广告C4）10.32.0.0/20主要（广告C7）10.24.0.0/13主要（广告PA的剩余部分）
For PB, the advertisements must also include C4 and C5, as well as its block of addresses.
对于PB，广告还必须包括C4和C5及其地址块。
Advertisements from "PB" to "BB" will be
从“PB”到“BB”的广告将被删除
10.24.12.0/22 secondary (advertises C4) 10.24.32.0/23 primary (advertises C5) 10.32.0.0/13 primary (advertises remainder of RB)
10.24.12.0/22中学（广告C4）10.24.32.0/23小学（广告C5）10.32.0.0/13小学（广告剩余RB）
To illustrate the problem diagnosis issue mentioned in Section 5.1, consider what happens if PA loses connectivity to C7 (the site that is assigned out of PB's space). In a stateful protocol, PA will announce to BB that 10.32.0.0/20 has become unreachable. Now, when BB flushes this information out of its routing table, any future traffic sent through it for this destination will be forwarded to PB (where it will be dropped according to Rule #2) by virtue of PB's less-specific match, 10.32.0.0/13. Although this does not cause an operational problem (C7 is unreachable in any case), it does create some extra traffic across "BB" (and may also prove confusing to someone trying to debug the outage with "traceroute"). A mechanism to cache such unreachable state might be nice, but it is beyond the scope of this document.
为了说明在第5.1节中提到的问题诊断问题，考虑如果PA失去连接到C7（由PB的空间分配的站点）会发生什么。在有状态协议中，PA将向BB宣布10.32.0.0/20已无法访问。现在，当BB从其路由表中刷新此信息时，任何通过它发送到此目的地的未来流量都将根据PB的不太具体的匹配10.32.0.0/13转发到PB（根据规则#2将在PB中丢弃）。尽管这不会导致操作问题（C7在任何情况下都无法访问），但它确实会在“BB”上产生一些额外的通信量（并且可能会让试图使用“跟踪路由”调试中断的人感到困惑）。缓存这种不可访问状态的机制可能不错，但它超出了本文的范围。
One aspect of Internet services that was notably affected by the move to CIDR was the mechanism used for address-to-name translation: the IN-ADDR.ARPA zone of the domain system. Because this zone is delegated on octet boundaries only, the move to an address assignment plan that uses bitmask-oriented addressing caused some increase in work for those who maintain parts of the IN-ADDR.ARPA zone.
互联网服务的一个明显受CIDR影响的方面是用于地址到名称转换的机制：域系统的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].
[RFC2317]中描述了在使用不与八位字节边界对齐的块地址时填充IN-ADDR.ARPA区域的技术说明。
CIDR was designed to be a short-term solution to the problems of routing state and address depletion on the IPv4 Internet. It does not change the fundamental Internet routing or addressing architectures. It is not expected to affect any plans for transition to a more long-term solution except, perhaps, by delaying the urgency of developing such a solution.
CIDR被设计为IPv4互联网上路由状态和地址耗尽问题的短期解决方案。它不会改变基本的Internet路由或寻址体系结构。预计这不会影响任何向更长期解决方案过渡的计划，除非推迟制定这种解决方案的紧迫性。
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在20世纪90年代初首次提出时，最初的作者对全局路由状态的增长率进行了一些观察，并预测了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年。这一增长的主要驱动力是公交供应商缺乏聚合能力，以及终端站点广泛使用传统的C类分配。每次新站点连接到全球Internet时，都会生成一个或多个新路由条目。
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. 1993年末和1994年初，随着CIDR“supernet”块首先由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. 1994年，由于供应商部署BGP4，允许聚合“超级网”块，因此BGP4的数量急剧下降。请注意，路由表条目数量最大下降的时期通常对应于IETF CIDR部署工作组每次会议后的几周。
4. Roughly linear growth from mid-1994 to early 1999 as CIDR-based address assignments were made and aggregated routes added throughout the network.
4. 从1994年年中到1999年初，随着基于CIDR的地址分配和整个网络中的聚合路由的增加，大致呈线性增长。
5. A new period of exponential growth again from early 1999 until 2001 as the "high-tech bubble" fueled both rapid expansion of the Internet, as well as a large increase in more-specific route advertisements for multi-homing and traffic engineering.
5. 从1999年初到2001年，又是一个指数增长的新时期，因为“高科技泡沫”推动了互联网的快速扩张，以及多主机和流量工程的更具体路线广告的大幅增加。
6. Flattening of growth through 2001 caused by a combination of the "dot-com bust", which caused many organizations to cease operations, and the "CIDR police" [CPOL] work aimed at improving aggregation efficiency.
6. 由于“网络泡沫破裂”（导致许多组织停止运营）和“CIDR警察”（CPOL）旨在提高聚合效率的工作的结合，2001年的增长趋于平缓。
7. Roughly linear growth through 2002 and 2003. This most likely represents a resumption of the "normal" growth rate observed before the "bubble", as well as an end to the "CIDR Police" effort.
7. 2002年和2003年大致呈线性增长。这很可能代表着“泡沫”之前观察到的“正常”增长率的恢复，以及“苹果酒警察”努力的结束。
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警察”工作的持续缺失，而“CIDR警察”曾是新供应商提高聚合效率的教育工具。也有一些情况下，服务提供商故意取消前缀聚合，试图缓解冲突路由公告引起的安全问题（见第12节）。尽管这种行为可以解决这些提供商所看到的短期问题，但它从根本上来说是不可扩展的，并且对整个社区非常有害。此外，似乎有许多提供商同时宣传其分配的前缀及其所有/24组件，这可能是由于缺乏关于推荐路由配置的一致的当前信息。
In 1992, when CIDR was first developed, there were serious problems facing the continued growth of the Internet. Growth in routing state complexity and the rapid increase in consumption of address space made it appear that one or both problems would preclude continued growth of the Internet within a few short years.
1992年，当CIDR首次开发时，互联网的持续发展面临着严重的问题。路由状态复杂性的增长和地址空间消耗的快速增加使得一个或两个问题可能会阻碍互联网在短短几年内的持续增长。
Deployment of CIDR, in combination with BGP4's support for carrying classless prefix routes, alleviated the short-term crisis. It was only through a concerted effort by both the equipment manufacturers and the provider community that this was achieved. The threat (and, perhaps in some cases, actual implementation of) charging networks for advertising prefixes may have offered an additional incentive to share the address space, and thus the associated costs of advertising routes to service providers.
CIDR的部署，加上BGP4对承载无类前缀路由的支持，缓解了短期危机。只有通过设备制造商和供应商社区的共同努力，才能实现这一目标。广告前缀收费网络的威胁（在某些情况下，可能是实际实施）可能为共享地址空间提供了额外的激励，从而为服务提供商提供了广告路线的相关成本。
The IPv4 routing system architecture carries topology information based on aggregate address advertisements and a collection of more-specific advertisements that are associated with traffic engineering, multi-homing, and local configuration. As of March 2005, the base aggregate address load in the routing system has some 75,000 entries.
IPv4路由系统体系结构承载基于聚合地址播发和与流量工程、多归属和本地配置相关的更具体播发的集合的拓扑信息。截至2005年3月，路由系统中的基本聚合地址负载大约有75000个条目。
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.
大约85000个额外条目是此基本“根”集合中更具体的条目。有理由相信，这些额外的条目中有许多是为了解决区域甚至地方范围的问题而存在的，不需要在全球范围内传播。
An obvious question to ask is whether CIDR can continue to be a viable approach to keeping global routing state growth and address space depletion at sustainable rates. Recent measurements indicate that exponential growth has resumed, but further analysis suggests that this trend can be mitigated by a more active effort to educate service providers as to efficient aggregation strategies and proper equipment configuration. Looking farther forward, there is a clear need for better multi-homing technology that does not require global routing state for each site and for methods of performing traffic load balancing that do not require adding even more state. Without such developments and in the absence of major architectural change, aggregation is the only tool available for making routing scale in the global Internet.
一个显而易见的问题是，CIDR是否能够继续成为保持全局路由状态增长并以可持续速度解决空间消耗问题的可行方法。最近的测量表明，指数增长已经恢复，但进一步的分析表明，可以通过更积极地教育服务提供商有效的聚合策略和适当的设备配置来缓解这一趋势。展望未来，显然需要更好的多主技术，它不需要每个站点的全局路由状态，也需要执行流量负载平衡的方法，它不需要添加更多的状态。如果没有这样的发展，也没有重大的架构变化，聚合是在全球互联网上实现路由规模的唯一工具。
This memo renders obsolete and requests re-classification as Historic the following RFCs describing CIDR usage and deployment:
本备忘录对描述CIDR使用和部署的以下RFC进行了过时处理，并要求将其重新分类为历史记录：
o RFC 1467: Status of CIDR Deployment in the Internet
o RFC 1467：互联网上CIDR部署的状态
This Informational RFC described the status of CIDR deployment in 1993. As of 2005, CIDR has been thoroughly deployed, so this status note only provides a historical data point.
该信息RFC描述了1993年CIDR部署的状态。截至2005年，CIDR已全面部署，因此本状态说明仅提供历史数据点。
o RFC 1481: IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling
o RFC 1481:IAB关于解决扩展问题的中间策略的建议
This very short Informational RFC described the IAB's endorsement of the use of CIDR to address scaling issues. Because the goal of RFC 1481 has been achieved, it is now only of historical value.
这篇简短的信息RFC描述了IAB对使用CIDR解决缩放问题的认可。因为RFC 1481的目标已经实现，所以它现在只具有历史价值。
o RFC 1482: Aggregation Support in the NSFNET Policy-Based Routing Database
o 基于策略的数据库聚合中的路由支持：FNC
This Informational RFC describes plans for support of route aggregation, as specified by CIDR, on the NSFNET. Because the NSFNET has long since ceased to exist and CIDR has been ubiquitously deployed, RFC 1482 now only has historical relevance.
此信息RFC描述了支持NSFNET上CIDR指定的路由聚合的计划。由于NSFNET早已不复存在，且CIDR已广泛部署，RFC 1482现在仅具有历史意义。
o RFC 1517: Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)
o RFC 1517：实现无类域间路由（CIDR）的适用性声明
This Standards Track RFC described where CIDR was expected to be required and where it was expected to be (strongly) recommended. With the full deployment of CIDR on the Internet, situations where CIDR is not required are of only historical interest.
本标准跟踪RFC，描述了预计需要CIDR的地方以及预计（强烈）推荐CIDR的地方。随着CIDR在互联网上的全面部署，不需要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.
本标准详细介绍了RFC讨论的路由和地址聚合注意事项。本文件第3.1节对其中一些问题进行了总结。因为地址分配政策和程序现在主要存在于RIR中，所以不适合尝试在标准跟踪RFC中记录这些实践。此外，[RFC3221]还从路由系统的角度描述了许多相同的问题。
o RFC 1520: Exchanging Routing Information Across Provider Boundaries in the CIDR Environment
o RFC 1520:在CIDR环境中跨提供商边界交换路由信息
This Informational RFC described transition scenarios where CIDR was not fully supported for exchanging route information between providers. With the full deployment of CIDR on the Internet, such scenarios are no longer operationally relevant.
此信息RFC描述了过渡场景，其中CIDR不完全支持在提供者之间交换路由信息。随着CIDR在互联网上的全面部署，此类场景不再具有操作相关性。
o RFC 1817: CIDR and Classful Routing
o RFC1817：CIDR和类路由
This Informational RFC described the implications of CIDR deployment in 1995; it notes that formerly-classful addresses were to be allocated using CIDR mechanisms and describes the use of a default route for non-CIDR-aware sites. With the full deployment of CIDR on the Internet, such scenarios are no longer operationally relevant.
该信息RFC描述了1995年CIDR部署的影响；它注意到以前的类地址是使用CIDR机制分配的，并描述了对不了解CIDR的站点使用默认路由的情况。随着CIDR在互联网上的全面部署，此类场景不再具有操作相关性。
o RFC 1878: Variable Length Subnet Table For IPv4
o RFC 1878:IPv4的可变长度子网表
This Informational RFC provided a table of pre-calculated subnet masks and address counts for each subnet size. With the incorporation of a similar table into this document (see Section 3.1), it is no longer necessary to document it in a separate RFC.
此信息RFC提供了一个预先计算的子网掩码和每个子网大小的地址计数表。随着类似表格并入本文件（见第3.1节），不再需要在单独的RFC中记录。
o RFC 2036: Observations on the use of Components of the Class A Address Space within the Internet
o RFC 2036：互联网内A类地址空间组件使用情况观察
This Informational RFC described several operational issues associated with the allocation of classless prefixes from previously-classful address space. With the full deployment of CIDR on the Internet and more than half a dozen years of experience making classless prefix allocations out of historical "Class A" address space, this RFC now has only historical value.
此信息RFC描述了与从以前的类地址空间分配无类前缀相关的几个操作问题。随着CIDR在互联网上的全面部署，以及六年多利用历史“a类”地址空间进行无类前缀分配的经验，此RFC现在只有历史价值。
The introduction of routing protocols that support classless prefixes and a move to a forwarding model that mandates that more-specific (longest-match) routes be preferred when they overlap with routes to less-specific prefixes introduces at least two security concerns:
引入支持无类别前缀的路由协议，以及转向转发模型，该模型要求更特定（最长匹配）的路由在与指向不太特定前缀的路由重叠时优先使用，这至少带来了两个安全问题：
1. Traffic can be hijacked by advertising a prefix for a given destination that is more specific than the aggregate that is normally advertised for that destination. For example, assume that a popular end system with the address 192.168.17.100 is connected to a service provider that advertises 192.168.16.0/20. A malicious network operator interested in intercepting traffic for this site might advertise, or at least attempt to advertise, 192.168.17.0/24 into the global routing system. Because this prefix is more specific than the "normal" prefix, traffic will be diverted away from the legitimate end system and to the network owned by the malicious operator. Prior to the advent of CIDR, it was possible to induce traffic from some parts of the network to follow a false advertisement that exactly matched a particular network number; CIDR makes this problem somewhat worse, since longest-match routing generally causes all traffic to prefer more-specific routes over less-specific routes. The remedy for the CIDR-based attack, though, is the same as for a pre-CIDR-based attack: establishment of trust relationships between providers, coupled with and strong route policy filters at provider borders. Unfortunately, the implementation of such filters is difficult in the highly de-centralized Internet. As a workaround, many providers do implement generic filters that set upper bounds, derived from RIR guidelines for the sizes of blocks that they allocate, on the lengths of prefixes that are accepted from other providers. Note that "spammers" have been observed using this sort of attack to hijack address space temporarily in order to hide the origin of the traffic ("spam" email messages) that they generate.
1. 通过为给定目的地播发前缀，可以劫持流量，该前缀比通常为该目的地播发的聚合更具体。例如，假设地址为192.168.17.100的流行终端系统连接到广告为192.168.16.0/20的服务提供商。有意拦截此站点流量的恶意网络运营商可能会向全局路由系统播发192.168.17.0/24，或至少尝试向全局路由系统播发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. 通过向系统中发布大量路由广告，可以对互联网基础设施的许多部分发起拒绝服务攻击。此类攻击旨在通过溢出路由和转发表来导致路由器故障。导致此类故障的非恶意事件的一个很好的例子是臭名昭著的“AS 7007”事件[7007]，在该事件中，运营商的路由器错误配置导致大量无效路由通过全局路由系统传播。同样，这种攻击对于CIDR来说并不新鲜；使用传统的A类/B类/C类路由，可以在全局路由系统中公布最多16843008个唯一的网络号码，该号码足以导致偶数用户出现问题
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使攻击变得更容易的种类进行详尽的分析；对全球路由系统中的安全漏洞进行更全面的分析超出了本文档的范围。
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，Jessica Yu）表示感谢；致ROAD集团，CIDR背后的许多想法都是与他们一起启发和发展的；以及这份重新编制的文件的早期评审员（巴里·格林、丹尼·麦克弗森、戴夫·迈耶、艾略特·李尔、比尔·诺顿、特德·希利、菲利普·史密斯、佩卡·萨沃拉），他们的评论、更正和建议是无价的。我们要特别感谢杰夫·休斯顿所作的远远超出职责范围的贡献。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[7007] "NANOG mailing list discussion of the "AS 7007" incident", <http://www.merit.edu/mail.archives/nanog/1997-04/ msg00340.html>.
[7007]“关于AS 7007事件的NANOG邮件列表讨论”<http://www.merit.edu/mail.archives/nanog/1997-04/ msg00340.html>。
[CBGP] "Graph: Active BGP Table Entries, 1988 to Present", <http://bgp.potaroo.net/as4637/>.
[CBGP]“图表：活动BGP表格条目，1988年至今”<http://bgp.potaroo.net/as4637/>.
[CPOL] "CIDR Police - Please Pull Over and Show Us Your BGP", <http://www.nanog.org/mtg-0302/cidr.html>.
[CPOL]“CIDR警察-请靠边停车，让我们看看你的BGP”<http://www.nanog.org/mtg-0302/cidr.html>.
[CRPT] "The CIDR Report", <http://www.cidr-report.org/>.
[CRPT]“CIDR报告”<http://www.cidr-report.org/>.
[IANA] "Internet Assigned Numbers Authority", <http://www.iana.org>.
[IANA]“互联网分配号码管理局”<http://www.iana.org>.
[LWRD] "The Long and Winding Road", <http://rms46.vlsm.org/1/42.html>.
[LWRD]“漫长而曲折的道路”<http://rms46.vlsm.org/1/42.html>.
[NRO] "Number Resource Organization", <http://www.nro.net>.
[NRO]“编号资源组织”<http://www.nro.net>.
[RFC904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1 1984.
[RFC904]Mills，D.，“外部网关协议正式规范”，RFC 904，1984年4月1日。
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RFC1058]Hedrick，C.，“路由信息协议”，RFC10581988年6月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, June 1992.
[RFC1338]Fuller，V.，Li，T.，Yu，J.，和K.Varadhan，“超级网络：地址分配和聚合策略”，RFC 13381992年6月。
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992.
[RFC1380]Gross，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.Li，“使用CIDR的IP地址分配架构”，RFC 1518，1993年9月。
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[RFC1519]Fuller，V.，Li，T.，Yu，J.，和K.Varadhan，“无类域间路由（CIDR）：地址分配和聚合策略”，RFC 1519，1993年9月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
[RFC2317]Eidnes，H.，de Groot，G.，和P.Vixie，“无类别地址ARPA委托”，BCP 20，RFC 2317，1998年3月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453]Malkin，G.，“RIP版本2”，STD 56，RFC 2453，1998年11月。
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, December 2000.
[RFC3021]Retana，A.，White，R.，Fuller，V.，和D.McPherson，“在IPv4点到点链路上使用31位前缀”，RFC 30212000年12月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221]Huston，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.，Lindqvist，K.，Davies，E.，Black，B.，和V.Gill，“IPv4多宿主实践和限制”，RFC 41162005年7月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年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
文斯·富勒美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134
EMail: vaf@cisco.com
EMail: vaf@cisco.com
Tony Li 555 Del Rey Avenue Sunnyvale, CA 94085
Tony Li加利福尼亚州桑尼维尔市德雷大道555号，邮编94085
Email: tli@tropos.com
Email: tli@tropos.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。