idnits 2.17.1 draft-ietf-grow-rfc1519bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1247. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1224. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1237. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC1519]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 564: '... default route and MUST be accepted by...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 91 has weird spacing: '...classes of ne...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1, 2005) is 6934 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3021' is defined on line 1172, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1338 (Obsoleted by RFC 1519) -- Obsolete informational reference (is this intentional?): RFC 1519 (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 2178 (Obsoleted by RFC 2328) -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 GROW V. Fuller 2 Internet-Draft T. Li 3 Expires: November 2, 2005 Cisco Systems 4 May 1, 2005 6 Classless Inter-Domain Routing (CIDR): The Internet Address Assignment 7 and Aggregation Plan 8 draft-ietf-grow-rfc1519bis-01 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 2, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This memo discusses the strategy for address assignment of the 44 existing 32-bit IPv4 address space with a view toward conserving the 45 address space and limiting the growth rate of global routing state. 46 This document obsoletes the original CIDR spec [RFC1519], with 47 changes made both to clarify the concepts it introduced and, after 48 more than twelve years, to update the Internet community on the 49 results of deploying the technology described. 51 Table of Contents 53 1. History and Problem Description . . . . . . . . . . . . . . 3 54 1.1 Status updates to CIDR documents . . . . . . . . . . . . . 4 55 2. Classless addressing as a solution . . . . . . . . . . . . . 6 56 2.1 Basic concept and prefix notation . . . . . . . . . . . . 6 57 3. Address assignment and routing aggregation . . . . . . . . . 9 58 3.1 Aggregation efficiency and limitations . . . . . . . . . . 9 59 3.2 Distributed assignment of address space . . . . . . . . . 10 60 4. Routing implementation considerations . . . . . . . . . . . 11 61 4.1 Rules for route advertisement . . . . . . . . . . . . . . 12 62 4.2 How the rules work . . . . . . . . . . . . . . . . . . . . 13 63 4.3 A note on prefix filter formats . . . . . . . . . . . . . 13 64 4.4 Responsibility for and configuration of aggregation . . . 14 65 4.5 Route propagation and routing protocol considerations . . 15 66 5. Example of new address assignments and routing . . . . . . . 16 67 5.1 Address delegation . . . . . . . . . . . . . . . . . . . . 16 68 5.2 Routing advertisements . . . . . . . . . . . . . . . . . . 18 69 6. Domain Name Service considerations . . . . . . . . . . . . . 19 70 7. Transition to a long term solution . . . . . . . . . . . . . 21 71 8. Analysis of CIDR's effect on global routing state . . . . . 21 72 9. Conclusions and Recommendations . . . . . . . . . . . . . . 23 73 10. Security Considerations . . . . . . . . . . . . . . . . . . 23 74 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 76 12.1 Normative References . . . . . . . . . . . . . . . . . . 25 77 12.2 Informative References . . . . . . . . . . . . . . . . . 25 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 79 Intellectual Property and Copyright Statements . . . . . . . 28 81 1. History and Problem Description 83 What is now known as the Internet started as a research project in 84 the 1970s to design and develop a set of protocols that could be used 85 with many different network technologies to provide a seamless, end- 86 to-end facility for interconnecting a diverse set of end systems. 87 When determining how the 32-bit address space would be used, certain 88 assumptions were made about the number of organizations to be 89 connected, the number of end systems per organization, and total 90 number of end systems on the network. The end result was the 91 establishment (see [RFC791]) of three classes of networks: class A 92 (most significant address bits '00'), with 128 possible networks each 93 with 16777216 end systems (minus special bit values reserved for 94 network/broadcast addresses); class B (MSB '10'), with 16384 possible 95 networks each with 65536 end systems (less reserved values); and 96 class C (MSB '110'), with 2097152 possible networks each with 254 end 97 systems (256 bit combinations minus the reserved all-zeros and all- 98 ones patterns). The set of addresses with MSB '111' was reserved for 99 future use; parts of this were eventually defined (MSB '1110') for 100 use with IPv4 multicast and parts are still reserved as of the 101 writing of this document. 103 In the late 1980s, the expansion and commercialization of the former 104 research network resulted in the connection of many new organizations 105 to the rapidly-growing Internet and each new organization required an 106 address assignment according to the class A/B/C addressing plan. As 107 demand for new network numbers, particularly in the class B space 108 started to take on what appeared to be an exponential growth rate, 109 some members of the operations and engineering community started to 110 have concerns over the long-term scaling properties of the class 111 A/B/C system and began thinking about how to modify network number 112 assignment policy and routing protocols to better accommodate the 113 growth. In November, 1991, the IETF created the ROAD (Routing and 114 Addressing) group to examine the situation. This group met in 115 January, 1992 and identified three major problems: 117 1. Exhaustion of the class B network address space. One fundamental 118 cause of this problem is the lack of a network class of a size 119 which is appropriate for mid-sized organization; class C, with a 120 maximum of 254 host addresses, is too small, while class B, which 121 allows up to 65534 host addresses, is too large for most 122 organizations but was the best fit available for use with 123 subnetting. 125 2. Growth of routing tables in Internet routers beyond the ability 126 of current software, hardware, and people to effectively manage. 128 3. Eventual exhaustion of the 32-bit IPv4 address space. 130 It was clear that then-current rates of Internet growth would cause 131 the first two problems to become critical some time between 1993 and 132 1995. Work already in progress on topological assignment of 133 addressing for CLNS, which was presented to the community at the 134 Boulder IETF in December of 1990, led to thoughts on how to re- 135 structure the 32-bit IPv4 address space to increase its lifespan. 136 Work in the ROAD group followed and eventually resulted in the 137 publication of [RFC1338] and later [RFC1519]. 139 The design and deployment of CIDR was intended to solve these 140 problems by providing a mechanism to slow the growth of global 141 routing tables and to reduce the rate of consumption of IPv4 address 142 space. It did not and does not attempt to solve the third problem, 143 which is of a more long-term nature, but instead endeavors to ease 144 enough of the short to mid-term difficulties to allow the Internet to 145 continue to function efficiently while progress is made on a longer- 146 term solution. 148 More historical background on this effort and on the ROAD group may 149 be found in [RFC1380] and at [LWRD]. 151 1.1 Status updates to CIDR documents 153 This memo renders obsolete and requests re-classification as Historic 154 the following RFCs describing CIDR usage and deployment: 156 o RFC 1467: Status of CIDR Deployment in the Internet 158 This Informational RFC described the status of CIDR deployment in 159 1993. As of 2005, CIDR has been thoroughly deployed, so this 160 status note only provides a historical data point. 162 o RFC 1481: IAB Recommendation for an Intermediate Strategy to 163 Address the Issue of Scaling 165 This very short Informational RFC described the IAB's endorsement 166 of the use of CIDR to address scaling issues. Because the goal of 167 RFC 1481 has been achieved, it is now only of historical value. 169 o RFC 1482: Aggregation Support in the NSFNET Policy-Based Routing 170 Database 172 This Informational RFC describes plans for support of route 173 aggregation, as specified by CIDR, on the NSFNET. Because the 174 NSFNET has long since ceased to exist and CIDR has been been 175 ubiquitously deployed, RFC 1482 now only has historical relevance. 177 o RFC 1517: Applicability Statement for the Implementation of 178 Classless Inter-Domain Routing (CIDR) 180 This Standards Track RFC described where CIDR was expected to be 181 required and where it was expected to be (strongly) recommended. 182 With the full deployment of CIDR on the Internet, situations where 183 CIDR is not required are of only historical interest. 185 o RFC 1520: Exchanging Routing Information Across Provider 186 Boundaries in the CIDR Environment 188 This Informational RFC described transition scenarios where CIDR 189 was not fully supported for exchanging route information between 190 providers. With the full deployment of CIDR on the Internet, such 191 scenarios are no longer operationally relevant. 193 o RFC 1817: CIDR and Classful Routing 195 This Informational RFC described the implications of CIDR 196 deployment in 1995; it notes that formerly-classful addresses were 197 to be allocated using CIDR mechanisms and describes the use of a 198 default route for non-CIDR-aware sites. With the full deployment 199 of CIDR on the Internet, such scenarios are no longer 200 operationally relevant. 202 o RFC 1878: Variable Length Subnet Table For IPv4 204 This Informational RFC provided a table of pre-calculated subnet 205 masks and address counts for each subnet size. With the 206 incorporation of a similar table into this document (see 207 Section 2.1), it is no longer necessary to document it in a 208 separate RFC. 210 o RFC 2036: Observations on the use of Components of the Class A 211 Address Space within the Internet 213 This Informational RFC described several operational issues 214 associated with the allocation of classless prefixes from 215 previously-classful address space. With the full deployment of 216 CIDR on the Internet and more than half a dozen years of 217 experience making classless prefix allocations out of historical 218 "class A" address space, this RFC now has only historical value. 220 o RFC 1518: An Architecture for IP Address Allocation with CIDR 222 This Standards Track RFC discussed routing and address aggregation 223 considerations at some length. Some of these issues are 224 summarized in this document in section Section 2.1. Because 225 address assignment policies and procedures now reside mainly with 226 the RIRs, it is not appropriate to try to document those practices 227 in a Standards Track RFC. In addition, [RFC3221] also describes 228 many of the same issues from point of view of the routing system. 230 2. Classless addressing as a solution 232 The solution that the community created was to deprecate the Class 233 A/B/C network address assignment system in favor of using 234 "classless", hierarchical blocks of IP addresses (referred to as 235 prefixes). The assignment of prefixes is intended to roughly follow 236 the underlying Internet topology so that aggregation can be used to 237 facilitate scaling of the global routing system. One implication of 238 this strategy is that prefix assignment and aggregation is generally 239 done according to provider-subscriber relationships, since that is 240 how the Internet topology is determined. 242 When originally proposed in [RFC1338] and [RFC1519], this addressing 243 plan was intended to be a relatively short-term response, lasting 244 approximately three to five years during which a more permanent 245 addressing and routing architecture would be designed and 246 implemented. As can be inferred from the dates on the original 247 documents, CIDR has far outlasted its anticipated lifespan and has 248 become the mid-term solution to the problems described above. 250 Coupled with address management strategies implemented by the 251 Regional Internet Registries (see [NRO] for details), the deployment 252 of CIDR-style addressing has also reduced the rate at which IPv4 253 address space has been consumed, thus providing short-to-medium-term 254 relief to problem #3 described above. 256 Note that, as defined, this plan neither requires nor assumes the re- 257 assignment of those parts of the legacy "class C" space that are not 258 amenable to aggregation (sometimes called "the swamp"). Doing so 259 would somewhat reduce routing table sizes (current estimate is that 260 "the swamp" contains approximately 15,000 entries) though at a 261 significant renumbering cost. Similarly, there is no hard 262 requirement that any end site renumber when changing transit service 263 provider but end sites are encouraged do so to eliminate the need for 264 explicit advertisement of their prefixes into the global routing 265 system. 267 2.1 Basic concept and prefix notation 269 In the simplest sense, the change from Class A/B/C network numbers to 270 classless prefixes is to make explicit which bits in a 32-bit IPv4 271 address are interpreted as the network number (or prefix) associated 272 with a site and which are the used to number individual end systems 273 within the site. In CIDR notation, a prefix is shown as a 4-octet 274 quantity, just like a traditional IPv4 address or network number, 275 followed by the "/" (slash) character, followed by a decimal value 276 between 0 and 32 that describes the number of significant bits. 278 For example, the legacy "class B" network 172.16.0.0, with an implied 279 network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16, 280 the "/16" indicating that the mask to extract the network portion of 281 the prefix is a 32-bit value where the most significant 16 bits are 282 ones and the least significant 16 bits are zeros. Similarly, the 283 legacy "class C" network number 192.168.99.0 is defined as the prefix 284 192.168.99.0/24 - the most significant 24 bits are ones and the least 285 significant 8 bits are zeros. 287 Using classless prefixes with explicit prefix lengths allows much 288 more flexible matching of address space blocks to actual need. Where 289 formerly only three network sizes were available, prefixes may be 290 defined to describe any power-of-two-sized block of between one and 291 2^32 end system addresses. In practice, the unallocated pool of 292 addresses is administered by the Internet Assigned Numbers Authority 293 ([IANA]). The IANA makes allocations from this pool to Regional 294 Internet Registries, as required. These allocations are made in 295 contiguous bit-aligned blocks of 2^24 addresses (a.k.a. /8 prefixes). 296 The RIRs, in turn, allocate or assign smaller address blocks to Local 297 Internet Registries (LIRs) or Internet Service Providers (ISPs). 298 These entities may make direct use of the assignment (as would 299 commonly be the case for an ISP) or may make further sub-allocations 300 of addresses to their customers. These RIR address assignments vary 301 according to the needs of each ISP or LIR. For example, a large ISP 302 might be allocated an address block of 2^17 addresses (a /15 prefix) 303 while a smaller ISP may be allocated an address block of 2^11 304 addresses (a /21 prefix). 306 Note that the terms "allocate" and "assign" have specific meaning in 307 the Internet address registry system; "allocate" refers to the 308 delegation of a block of address space to an organization which is 309 expected to perform further sub-delegations while "assign" is used 310 for sites that directly use (i.e. number individual hosts) the block 311 of addresses received. 313 The following table provides a convenient short-cut to all of the 314 CIDR prefix sizes, showing the number of addresses possible in each 315 prefix and the number of prefixes of that size that may be numbered 316 in the 32-bit IPv4 address space: 318 notation addrs/block # blocks 319 -------- ----------- ---------- 320 n.n.n.n/32 1 4294967296 "host route" 321 n.n.n.x/31 2 2147483648 "[RFC3021] p2p link" 322 n.n.n.x/30 4 1073741824 323 n.n.n.x/29 8 536870912 324 n.n.n.x/28 16 268435456 325 n.n.n.x/27 32 134217728 326 n.n.n.x/26 64 67108864 327 n.n.n.x/25 128 33554432 328 n.n.n.0/24 256 16777216 legacy "class C" 329 n.n.x.0/23 512 8388608 330 n.n.x.0/22 1024 4194304 331 n.n.x.0/21 2048 2097152 332 n.n.x.0/20 4096 1048576 333 n.n.x.0/19 8192 524288 334 n.n.x.0/18 16384 262144 335 n.n.x.0/17 32768 131072 336 n.n.0.0/16 65536 65536 legacy "class B" 337 n.x.0.0/15 131072 32768 338 n.x.0.0/14 262144 16384 339 n.x.0.0/13 524288 8192 340 n.x.0.0/12 1048576 4096 341 n.x.0.0/11 2097152 2048 342 n.x.0.0/10 4194304 1024 343 n.x.0.0/9 8388608 512 344 n.0.0.0/8 16777216 256 legacy "class A" 345 x.0.0.0/7 33554432 128 346 x.0.0.0/6 67108864 64 347 x.0.0.0/5 134217728 32 348 x.0.0.0/4 268435456 16 349 x.0.0.0/3 536870912 8 350 x.0.0.0/2 1073741824 4 351 x.0.0.0/1 2147483648 2 352 0.0.0.0/0 4294967296 1 "default route" 354 n is an 8-bit, decimal octet value. 356 x is a 1 to 7 bit value, base on the prefix length, shifted into the 357 most significant bits of the octet and converted into decimal form; 358 the least significant bits of the octet are zero. 360 In practice, prefixes of length shorter than 8 are not allocated or 361 assigned though routes to such short prefixes may exist in routing 362 tables if or when aggressive aggregation is performed. As of the 363 writing of this document, no such routes are seen in the global 364 routing system but operator error and other events have caused some 365 of them (i.e. 128.0.0.0/1 and 192.0.0.0/2) to be observed in some 366 networks at some times in the past. 368 3. Address assignment and routing aggregation 370 Classless addressing and routing was initially developed primarily to 371 improve the scaling properties of routing on the global Internet. 372 Because the scaling of routing is very tightly coupled to the way 373 that addresses are used, deployment of CIDR had implications for the 374 way in which addresses were assigned. 376 3.1 Aggregation efficiency and limitations 378 The only commonly-understood method for reducing routing state on a 379 packet-switched network is through aggregation of information. For 380 CIDR to succeed in reducing the size and growth rate of the global 381 routing system, the IPv4 address assignment process needed to be 382 changed to make possible the aggregation of routing information along 383 topological lines. Since, in general, the topology of the network is 384 determined by the service providers who have built it, topologically- 385 significant address assignments are necessarily service-provider 386 oriented. 388 Aggregation is simple for an end site which is connected to one 389 service provider: it uses address space assigned by its service 390 provider and that address space is a small piece of a larger block 391 allocated to the service provider. No explicit route is needed for 392 the end site - the service provider advertises a single aggregate 393 route for the larger block; this advertisement provides reachability 394 and routeability for all of the customers numbered in the block. 396 There are two, more complex, situations that reduce the effectiveness 397 of aggregation: 399 o An organization which is multi-homed. Because a multi-homed 400 organization must be advertised into the system by each of its 401 service providers, it is often not feasible to aggregate its 402 routing information into the address space of any one of those 403 providers. Note that the organization still may receive its 404 address assignment out of a service provider's address space 405 (which has other advantages), but a route to the organization's 406 prefix must still be explicitly advertised by all of its service 407 providers. For this reason, the global routing cost for a multi- 408 homed organization is generally the same as it was prior to the 409 adoption of CIDR. 411 o An organization which changes service provider but does not 412 renumber. This has the effect of "punching a hole" in one of the 413 original service provider's aggregated route advertisements. CIDR 414 handles this situation by requiring the newer service provider to 415 advertise a specific advertisement for the re-homed organization; 416 this advertisement is preferred over provider aggregates because 417 it is a longer match. To maintain efficiency of aggregation, it 418 is recommended that an organization which changes service 419 providers plan to eventually migrate its network into a an prefix 420 assigned from its new provider's address space. To this end, it 421 is recommended that mechanisms to facilitate such migration, such 422 as dynamic host address assignment using [RFC2131]) be deployed 423 wherever possible, and that additional protocol work be done to 424 develop improved technology for renumbering. 426 Note that some aggregation efficiency gain can still be had for 427 multi-homed sites (and, in general, for any site composed of 428 multiple, logical IPv4 networks) - by allocating a contiguous power- 429 of-two block address space to the site (as opposed to multiple, 430 independent prefixes) the site's routing information may be 431 aggregated into a single prefix. Also, since the routing cost 432 associated with assigning a multi-homed site out of a service 433 provider's address space is no greater than the old method of 434 sequential number assignment by a central authority, it makes sense 435 to assign all end-site address space out of blocks allocated to 436 service providers. 438 It is also worthwhile to mention that since aggregation may occur at 439 multiple levels in the system, it may still be possible to aggregate 440 these anomalous routes at higher levels of whatever hierarchy may be 441 present. For example, if a site is multi-homed to two relatively 442 small providers that both obtain connectivity and address space from 443 the same large provider, then aggregation by the large provider of 444 routes from the smaller networks will include all routes to the 445 multi-homed site. The feasibility of this sort of second-level 446 aggregation depends on whether topological hierarchy exists between a 447 site, its directly-connected providers, and other providers to which 448 they are connected; it may be practical in some regions of the global 449 Internet but not in others. 451 Note: in the discussion and examples which follow, prefix notation is 452 used to represent routing destinations. This is used for 453 illustration only and does not require that routing protocols use 454 this representation in their updates. 456 3.2 Distributed assignment of address space 458 In the early days of the Internet, IPv4 address space assignment was 459 performed by the central Network Information Center (NIC). Class 460 A/B/C network numbers were assigned in essentially arbitrary order, 461 roughly according to the size of the organizations that requested 462 them. All assignments were recorded centrally and no attempt was 463 made to assign network numbers in a manner that would allow routing 464 aggregation. 466 When CIDR was originally deployed, the central assignment authority 467 continued to exist but changed its procedures to assign large blocks 468 of "Class C" network numbers to each service provider. Each service 469 provider, in turn, assigned bitmask-oriented subsets of the 470 provider's address space to each customer. This worked reasonably 471 well as long as the number of service providers was relatively small 472 and relatively constant but did not scale well as the number of 473 service providers grew at a rapid rate. 475 As the Internet started to expand rapidly in the 1990s, it became 476 clear that a single, centralized address assignment authority was 477 problematic. This function began being de-centralized when address 478 space assignment for European Internet sites was delegated in bit- 479 aligned blocks of 16777216 addresses (what CIDR would later define as 480 a /8) to the RIPE NCC ([RIPE]), effectively making it the first of 481 the RIRs. Since then, address assignment has been formally 482 distributed as a hierarchical function with IANA, the RIRs, and the 483 service providers. Removing the bottleneck of a single organization 484 having responsibility for the global Internet address space greatly 485 improved the efficiency and response time for new assignments. 487 Hierarchical delegation of addresses in this manner implies that 488 sites with addresses assigned out of a given service provider are, 489 for routing purposes, part of that service provider and will be 490 routed via its infrastructure. This implies that routing information 491 about multi-homed organizations, i.e., organizations connected to 492 more than one network service provider, will still need to be known 493 by higher levels in the hierarchy. 495 A historical perspective on these issues is described in [RFC1518]. 496 Additional discussion may also be found in [RFC3221]. 498 4. Routing implementation considerations 500 With the change from classful network numbers to classless prefixes, 501 it is not possible to infer the network mask from the initial bit 502 pattern of an IPv4 address. This has implications for how routing 503 information is stored and propagated. Network masks or prefix 504 lengths must be explicitly carried in routing protocols. Interior 505 routing protocols such as OSPF [RFC2178], IS-IS [RFC1195], RIPv2 506 [RFC2453], and Cisco EIGRP, and the BGP4 exterior routing protocol 507 [RFC1771] all support this functionality, having been developed or 508 modified as part of the deployment of classless inter-domain routing 509 during the 1990s. 511 Older interior routing protocols, such as RIP [RFC1058], HELLO, and 512 Cisco IGRP, and older exterior routing protocols, such as EGP 513 [RFC904], do not support explicit carriage of prefix length/mask and 514 thus cannot be effectively used on the Internet in other than very 515 limited, stub configurations. While their use may be appropriate in 516 simple, legacy end-site configurations, they are considered obsolete 517 and should NOT be used in transit networks connected to the global 518 Internet. 520 Similarly, routing and forwarding tables in layer-3 network equipment 521 must be organized to store both prefix and prefix length or mask. 522 Equipment which organizes its routing/forwarding information 523 according to legacy class A/B/C network/subnet conventions cannot be 524 expected to work correctly on networks connected to the global 525 Internet; use of such equipment is not recommended. Fortunately, 526 very little such equipment is in use today. 528 4.1 Rules for route advertisement 530 1. Routing to all destinations must be done on a longest-match basis 531 only. This implies that destinations which are multi-homed 532 relative to a routing domain must always be explicitly announced 533 into that routing domain - they cannot be summarized (this makes 534 intuitive sense - if a network is multi-homed, all of its paths 535 into a routing domain which is "higher" in the hierarchy of 536 networks must be known to the "higher" network). 538 2. A router which generates an aggregate route for multiple, more- 539 specific routes must discard packets which match the aggregate 540 route but not any of the more-specific routes. In other words, 541 the "next hop" for the aggregate route should be the null 542 destination. This is necessary to prevent forwarding loops when 543 some addresses covered by the aggregate are not reachable. 545 Note that during failures, partial routing of traffic to a site which 546 takes its address space from one service provider but which is 547 actually reachable only through another (i.e., the case of a site 548 which has changed service providers) may occur because such traffic 549 will be forwarded along the path advertised by the aggregated route. 550 Rule #2 will prevent packet mis-delivery by causing such traffic to 551 be discarded by the advertiser of the aggregated route, but the 552 output of "traceroute" and other similar tools will suggest that a 553 problem exists within that network rather than in the network which 554 is no longer advertising the more-specific prefix. This may be 555 confusing to those trying to diagnose connectivity problems; see the 556 example in Section 5.2 for details. A solution to this perceived 557 "problem" is beyond the scope of this document - it lies with better 558 education of the user/operator community, not in routing technology. 560 An implementation following these rules should also be generalized, 561 so that an arbitrary network number and mask are accepted for all 562 routing destinations. The only outstanding constraint is that the 563 mask must be left contiguous. Note that the degenerate route to 564 prefix 0.0.0.0/0 is used as a default route and MUST be accepted by 565 all implementations. Further, to protect against accidental 566 advertisements of this route via the inter-domain protocol, this 567 route should only be advertised when a router is explicitly 568 configured to do so - never as a non-configured, "default" option. 570 4.2 How the rules work 572 Rule #1 guarantees that the routing algorithm used is consistent 573 across implementations and consistent with other routing protocols, 574 such as OSPF. Multi-homed networks are always explicitly advertised 575 by every service provider through which they are routed even if they 576 are a specific subset of one service provider's aggregate (if they 577 are not, they clearly must be explicitly advertised). It may seem as 578 if the "primary" service provider could advertise the multi-homed 579 site implicitly as part of its aggregate, but the assumption that 580 longest-match routing is always done causes this not to work. 582 Rule #2 guarantees that no routing loops form due to aggregation. 583 Consider a site that has been assigned 192.168.64/19 by its "parent" 584 provider that has 192.168.0.0/16. The "parent" network will 585 advertise 192.168.0.0/16 to the "child" network. If the "child" 586 network were to lose internal connectivity to 192.168.65.0/24 (which 587 is part of its aggregate), traffic from the "parent" to the to the 588 "child" destined for 192.168.65.1 will follow the "child's" 589 advertised route. When that traffic gets to the "child", however, 590 the mid-level *must not* follow the route 192.168.0.0/16 back up to 591 the "parent", since that would result in a forwarding loop. Rule #2 592 says that the "child" may not follow a less-specific route for a 593 destination which matches one of its own aggregated routes 594 (typically, this is implemented by installing a "discard" or "null" 595 route for all aggregated prefixes which one network advertises to 596 another). Note that handling of the "default" route (0.0.0.0/0) is a 597 special case of this rule - a network must not follow the default to 598 destinations which are part of one of it's aggregated advertisements. 600 4.3 A note on prefix filter formats 602 Systems which process route announcements must be able to verify that 603 information which they receive is acceptable according to policy 604 rules. Implementations which filter route advertisements must allow 605 masks or prefix lengths in filter elements. Thus, filter elements 606 which formerly were specified as: 608 accept 172.16.0.0 609 accept 172.25.120.0.0 610 accept 172.31.0.0 611 deny 10.2.0.0 612 accept 10.0.0.0 614 now look something like: 616 accept 172.16.0.0/16 617 accept 172.25.0.0/16 618 accept 172.31.0.0/16 619 deny 10.2.0.0/16 620 accept 10.0.0.0/8 622 This is merely making explicit the network mask which was implied by 623 the class A/B/C classification of network numbers. It is also useful 624 to enhance filtering capability to allow the match of a prefix and 625 all more-specific prefixes with the same bit pattern; fortunately, 626 this functionality has been implemented by most vendors of equipment 627 used on the Internet. 629 4.4 Responsibility for and configuration of aggregation 631 Under normal circumstances, a routing domain (or "Autonomous System") 632 which has been allocated or assigned a set of prefixes has sole 633 responsibility for aggregation of those prefixes. In the usual case, 634 the AS will install configuration in one or more of its routers to 635 generate aggregate routes based on more-specific routes known to its 636 internal routing system; these aggregate routes are advertised into 637 the global routing system by the border routers for the routing 638 domain. The more-specific internal routes which overlap with the 639 aggregate routes should not be advertised globally. In some cases, 640 an AS may wish to delegate aggregation responsibility to another AS 641 (for example, a customer may wish for its service provider to 642 generate aggregated routing information on its behalf); in such 643 cases, aggregation is performed by a router in the second AS based on 644 the routes that it receives from the first combined with configured 645 policy information describing how those routes should be aggregated. 647 It should be mentioned that one provider may choose to perform 648 aggregation on the routes it receives from another without explicit 649 agreement; this is termed "proxy aggregation". This can be a useful 650 tool for reducing the amount of routing state that an AS must carry 651 and propagate to its customers and neighbors, proxy aggregation can 652 also create inconsistencies in global routing state. Consider what 653 happens if both AS 2 and 3 receive routes from AS 1 but AS 2 performs 654 proxy aggregation while AS 3 does not. Other AS's which receive 655 transit routing information from both AS 2 and AS 3 will see an 656 inconsistent view of the routing information originated by AS 1. 657 This may cause an unexpected shift of traffic toward AS 1 through AS 658 3 for AS 3's customers and any others receiving transit routes from 659 AS 3. Because proxy aggregation can cause unanticipated consequences 660 for parts of the Internet that have no relationship with either the 661 source of the aggregated routes or the party providing aggregation, 662 it should be used with extreme caution. 664 Configuration of the routes to be combined into aggregates is an 665 implementation of routing policy and does require some manually- 666 maintained information. As an addition to the information that must 667 be maintained for a set of routeable prefixes, aggregation 668 configuration is typically just a line or two defining the range of 669 the block of IPv4 addresses to aggregate. A site performing its own 670 aggregation is doing so for address blocks that it has been assigned; 671 a site performing aggregation on behalf of another knows this 672 information based on an agreement to delegate aggregation. Assuming 673 a best common practice for network administrators to exchange lists 674 of prefixes to accept from one and other, configuration of 675 aggregation information does not introduce significant additional 676 administrative overhead. 678 The generation of an aggregate route is usually specified either 679 statically or in response to learning an active dynamic route for a 680 prefix contained within the aggregate route. If such dynamic 681 aggregate route advertisement is done, care should be taken that 682 routes are not excessively added or withdrawn (known as "route 683 flapping"); in general, a dynamic aggregate route advertisement is 684 added when at least one component of the aggregate becomes reachable 685 and it is withdrawn only when all components become unreachable. 686 Properly configured, aggregated routes are more stable than non- 687 aggregated routes and thus improve global routing stability. 689 Implementation note: aggregation of the "Class D" (multicast) address 690 space is beyond the scope of this document. 692 4.5 Route propagation and routing protocol considerations 694 Prior to the original deployment of CIDR, common practice was to 695 propagate routes learned via exterior routing protocols (i.e. EGP or 696 BGP) through a site's interior routing protocol (typically, OSPF, 697 IS-IS, or RIP). This was done to ensure that consistent and correct 698 exit points were chosen for traffic destined to a destination learned 699 through those protocols. Four evolutionary effects -- the advent of 700 CIDR, explosive growth of global routing state, widespread adoption 701 of BGP4, and a requirement to propagate full path information -- have 702 combined to deprecate that practice. To ensure proper path 703 propagation and prevent inter-AS routing inconsistency (BGP4's loop 704 detection/prevention mechanism requires full path propagation), 705 transit networks must use internal BGP (iBGP) for carrying routes 706 learned from other providers both within and through their networks. 708 5. Example of new address assignments and routing 710 5.1 Address delegation 712 Consider the block of 524288 (2^19) addresses beginning with 713 10.24.0.0 and ending with 10.31.255.255 allocated to a single network 714 provider, "PA". This is equivalent in size to a block of 2048 legacy 715 "class C" network numbers (or /24s). A classless route to this block 716 would be described as 10.24.0.0 with mask of 255.248.0.0 the prefix 717 10.24.0.0/13. 719 Assume this service provider connects six sites in the following 720 order (significant because it demonstrates how temporary "holes" may 721 form in the service provider's address space): 723 o "C1" requiring fewer than 2048 addresses (/21 or 8 x /24) 725 o "C2" requiring fewer than 4096 addresses (/20 or 16 x /24) 727 o "C3" requiring fewer than 1024 addresses (/22 or 4 x /24) 729 o "C4" requiring fewer than 1024 addresses (/22 or 4 x /24) 731 o "C5" requiring fewer than 512 addresses (/23 or 2 x /24) 733 o "C6" requiring fewer than 512 addresses (/23 or 2 x /24) 735 In all cases, the number of IPv4 addresses "required" by each site is 736 assumed to allow for significant growth. The service provider 737 delegates its address space as follows: 739 o C1: assign 10.24.0 through 10.24.7. This block of networks is 740 described by the route 10.24.0.0/21 (mask 255.255.248.0) 742 o C2: assign 10.24.16 through 10.24.31. This block is described by 743 the route 10.24.16.0/20 (mask 255.255.240.0) 745 o C3: assign 10.24.8 through 10.24.11. This block is described by 746 the route 10.24.8.0/22 (mask 255.255.252.0) 748 o C4: assign 10.24.12 through 10.24.15. This block is described by 749 the route 10.24.12.0/22 (mask 255.255.252.0) 751 o C5: assign 10.24.32 and 10.24.33. This block is described by the 752 route 10.24.32.0/23 (mask 255.255.254.0) 754 o C6: assign 10.24.34 and 10.24.35. This block is described by the 755 route 10.24.34.0/23 (mask 255.255.254.0) 757 These six sites should be represented as six prefixes of varying size 758 within the provider IGP. If, for some reason, the provider were to 759 use an obsolete IGP that doesn't support classless routing or 760 variable-length subnets, then then explicit routes all /24s will have 761 to be carried. 763 To make this example more realistic, assume that C4 and C5 are multi- 764 homed through some other service provider, "PB". Further assume the 765 existence of a site "C7" which was originally connected to "RB" but 766 has moved to "PA". For this reason, it has a block of network 767 numbers which are assigned out "PB"'s block of (the next) 2048 x /24. 769 o C7: assign 10.32.0 through 10.32.15. This block is described by 770 the route 10.32.0.0/20 (mask 255.255.240.0) 772 For the multi-homed sites, assume that C4 is advertised as primary 773 via "RA" and secondary via "RB"; C5 is primary via "RB" and secondary 774 via "RA". In addition, assume that "RA" and "RB" are both connected 775 to the same transit service provider "BB". 777 Graphically, this topology looks something like this: 779 10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0 780 C1: 10.24.0.0/21 \ / C7: 10.32.0.0/20 781 \ / 782 +----+ +----+ 783 10.24.16.0 - 10.24.31.0_ | | | | 784 C2: 10.24.16.0/20 \ | | _10.24.12.0 - 10.24.15.0__ | | 785 \| | / C4: 10.24.12.0/20 \ | | 786 | |/ \| | 787 10.24.8.0 - 10.24.11.0___/| PA |\ | PB | 788 C3: 10.24.8.0/22 | | \__10.24.32.0 - 10.24.33.0___| | 789 | | C5: 10.24.32.0/23 | | 790 | | | | 791 10.24.34.0 - 10.24.35.0__/| | | | 792 C6: 10.24.34.0/23 | | | | 793 +----+ +----+ 794 || || 795 routing advertisements: || || 796 || || 797 10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) || 798 10.32.0.0/20 (C7) || 10.24.32.0/23 (C5) || 799 10.24.0.0/13 (PA) || 10.32.0.0/13 (PB) || 800 || || 801 VV VV 802 +---------- BACKBONE NETWORK BB ----------+ 804 5.2 Routing advertisements 806 To follow rule #1, PA will need to advertise the block of addresses 807 that it was given and C7. Since C4 is multi-homed and primary 808 through PA, it must also be advertised. C5 is multi-homed and 809 primary through PB. In principal (and in the example above), it need 810 not be advertised since longest match by PB will automatically select 811 PB as primary and the advertisement of PA's aggregate will be used as 812 a secondary. In actual practice, C5 will normally be advertised via 813 both providers. 815 Advertisements from "PA" to "BB" will be: 817 10.24.12.0/22 primary (advertises C4) 818 10.32.0.0/20 primary (advertises C7) 819 10.24.0.0/13 primary (advertises remainder of PA) 821 For PB, the advertisements must also include C4 and C5 as well as 822 it's block of addresses. 824 Advertisements from "PB" to "BB" will be: 826 10.24.12.0/22 secondary (advertises C4) 827 10.24.32.0/23 primary (advertises C5) 828 10.32.0.0/13 primary (advertises remainder of RB) 830 To illustrate the problem diagnosis issue mentioned in Section 4.1, 831 consider what happens if PA loses connectivity to C7 (the site which 832 is assigned out of PB's space). In a stateful protocol, PA will 833 announce to BB that 10.32.0.0/20 has become unreachable. Now, when 834 BB flushes this information out of its routing table, any future 835 traffic sent through it for this destination will be forwarded to PB 836 (where it will be dropped according to Rule #2) by virtue of PB's 837 less specific match 10.32.0.0/13. While this does not cause an 838 operational problem (C7 is unreachable in any case), it does create 839 some extra traffic across "BB" (and may also prove confusing to 840 someone trying to debug the outage with "traceroute"). A mechanism 841 to cache such unreachable state might be nice but is beyond the scope 842 of this document. 844 6. Domain Name Service considerations 846 One aspect of Internet services which was notably affected by the 847 move to CIDR was the mechanism used for address-to-name translation: 848 the IN-ADDR.ARPA zone of the domain system. Because this zone is 849 delegated on octet boundaries only, the move to an address assignment 850 plan which uses bitmask-oriented addressing caused some increase in 851 work for those who maintain parts of the IN-ADDR.ARPA zone. 853 As described above, the IN-ADDR.ARPA zone is necessarily organized 854 along octet boundaries. Prior to the adoption of CIDR, IN-ADDR.ARPA 855 was also constrained such that delegations were only permitted along 856 legacy, class A/B/C network number boundaries. This created a 857 difficult situation for more flexible, CIDR prefixes. Consider a 858 hypothetical large network provider named "BigNet" which has been 859 allocated the block 10.4.0.0 through 10.7.255.0 (the CIDR prefix 860 10.4.0.0/14). Under the old delegation policies, the top-level IN- 861 ADDR.ARPA domain servers would need to have 1024 entries of the form: 863 0.4.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. 865 1.4.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. 867 .... 869 255.7.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. 871 By revising the policy as described above, this was reduced to four 872 delegation records: 874 4.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. 876 5.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. 878 6.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. 880 7.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. 882 The provider then maintains further delegations of naming authority 883 for each individual /24 which it assigns, rather than having each 884 registered separately. Note that due to the way the DNS is designed, 885 it is still possible for the top-level IN-ADDR.ARPA name servers to 886 maintain the delegation information for individual networks for which 887 the provider is unwilling or unable to do so. The example above 888 illustrates only the records for a single name server. In the normal 889 case, there are usually several name servers for each domain, thus 890 the size of the examples will double or triple in the common cases. 892 For BIG.NET to assign a blocks smaller than /24 to its customers, it 893 can similarly delegate DNS authority for those addresses. For 894 example, if it were to assign 10.4.99.64/26 to its customer 895 CUSTONE.COM and 10.4.99.128/27 to its customer CUSTTWO.COM, it could 896 add the following records to delegate DNS for the addresses to those 897 customers: 899 64.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTONE.COM. 901 65.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTONE.COM. 903 .... 905 127.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTONE.COM 907 128.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTTWO.COM 909 129.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTTWO.COM 911 .... 913 159.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTTWO.COM 915 And if BIG.NET also assigned 10.4.99.160/30 to CUSTTHREE.COM but this 916 customer did not want to run its own DNS, BIG.NET could provide that 917 service for the customer by installing the appropriate PTR records: 919 160.99.4.10.IN-ADDR.ARPA. IN PTR NET.CUSTTHREE.COM. 921 161.99.4.10.IN-ADDR.ARPA. IN PTR HOST1.CUSTTHREE.COM. 923 162.99.4.10.IN-ADDR.ARPA. IN PTR HOST2.CUSTTHREE.COM. 925 163.99.4.10.IN-ADDR.ARPA. IN PTR BCAST.CUSTTHREE.COM. 927 See [RFC2317] for a much more detailed discussion of DNS delegation 928 with classless addressing. 930 7. Transition to a long term solution 932 CIDR was designed to be a short-term solution to the problems of 933 routing state and address depletion on the IPv4 Internet. It does 934 not change the fundamental Internet routing or addressing 935 architectures. It is not expected to affect any plans for transition 936 to a more long-term solution except, perhaps, by delaying the urgency 937 of developing such a solution. 939 8. Analysis of CIDR's effect on global routing state 941 When CIDR was first proposed in the early 1990s, the original authors 942 made some observations about the growth rate of global routing state 943 and offered projections on how CIDR deployment would, hopefully, 944 reduce what appeared to be exponential growth to a more sustainable 945 rate. Since that deployment, an ongoing effort, called "The CIDR 946 Report" [CRPT] has attempted to quantify and track that growth rate. 947 What follows is a brief summary of the CIDR report as of March, 2005, 948 with an attempt to explain the various patterns of and change in 949 growth rate that have occurred since measurements of the size of 950 global routing state began in 1988. 952 Examining the graph of "Active BGP Table Entries" [CBGP] there appear 953 to be several different growth trends with distinct inflection points 954 reflecting changes in policy and practice. The trends and events 955 which are believed to have caused them were: 957 1. Exponential growth at the far left of the graph. This represents 958 the period of early expansion and commercialization of the former 959 research network, from the late 1980s through approximately 1994. 960 The major driver for this growth was a lack of aggregation 961 capability for transit providers, and the widespread use of 962 legacy Class C allocations for end sites. Each time a new site 963 was connected to the global Internet, one or more new routing 964 entries were generated. 966 2. Acceleration of the exponential trend in late 1993 and early 1994 967 as CIDR supernet" blocks were first assigned by the NIC and 968 routed as separate legacy class-C networks by service provider. 970 3. A sharp drop in 1994 as BGP4 deployment by providers allowed 971 aggregation of the "supernet" blocks. Note that the periods of 972 largest declines in the number of routing table entries typically 973 correspond to the weeks following each meeting of the IETF CIDR 974 Deployment Working Group. 976 4. Roughly linear growth from mid-1994 to early 1999 as CIDR-based 977 address assignments were made and aggregated routes added 978 throughout the network. 980 5. A new period of exponential growth again from early 1999 until 981 2001 as the "high-tech bubble" fueled both rapid expansion of 982 Internet as well as a large increase in more-specific route 983 advertisements for multi-homing and traffic engineering. 985 6. Flattening of growth through 2001 caused by a combination of the 986 "dot-com bust", which caused many organizations to cease 987 operations, and the "CIDR police" [CPOL] work aimed at improving 988 aggregation efficiency. 990 7. Roughly linear growth through 2002 and 2003. This most likely 991 represents a resumption of the "normal" growth rate observed 992 before the "bubble" as well as an end to the "CIDR Police" 993 effort. 995 8. A more recent trend of exponential growth beginning in 2004. The 996 best explanation would seem to be an improvement of the global 997 economy driving increased expansion of the Internet and the 998 continued absence of the "CIDR Police" effort, which previously 999 served as an educational tool for new providers to improve 1000 aggregation efficiency. There have also been some cases where 1001 service providers have deliberately de-aggregated prefixes in an 1002 attempt to mitigate security problems caused by conflicting route 1003 advertisements (see Section 10). While this behavior may solve 1004 the short-term problems seen by such providers, it is 1005 fundamentally non-scalable and quite detrimental to the community 1006 as a whole. In addition, there appear to be many providers 1007 advertising both their allocated prefixes and all of the /24 1008 components of them, probably due to a lack of consistent current 1009 information about recommended routing configuration. 1011 9. Conclusions and Recommendations 1013 In 1992, when CIDR was first developed, there were serious problems 1014 facing the continued growth of the Internet. Growth in routing state 1015 complexity, and the rapid increase in consumption of address space 1016 made it appear that one or both problems would preclude continued 1017 growth of the Internet within a few short years. 1019 Deployment of CIDR, in combination with BGP4's support for carrying 1020 classless prefix routes, alleviated the short-term crisis. It was 1021 only through a concerted effort by both the equipment manufacturers 1022 and the provider community that this was achieved. The threat (and, 1023 perhaps in some cases, actual implementation of) charging networks 1024 for advertising prefixes may have offered an additional incentive to 1025 share the address space, and hence the associated costs of 1026 advertising routes to service providers. 1028 The IPv4 routing system architecture carries topology information 1029 based on aggregate address advertisements and a collection of more- 1030 specific advertisements that are associated with traffic engineering, 1031 multi-homing and local configuration. As of March, 2005, the base 1032 aggregate address load in the routing system has some 75,000 entries. 1033 Approximately 85,000 additional entries are more specific entries of 1034 this base "root" collection. There is reason to believe that many of 1035 these additional entries are exist to solve problems of regional or 1036 even local scope and should not need to be globally propagated. 1038 An obvious question to ask is whether CIDR can continue to be a 1039 viable approach to keeping global routing state growth and address 1040 space depletion at sustainable rates. Recent measurements indicate 1041 that exponential growth has resumed but further analysis suggests 1042 that this trend can be mitigated by a more active effort to educate 1043 service providers on efficient aggregation strategies and proper 1044 equipment configuration. Looking farther forward, there is a clear 1045 need for better multi-homing technology that does not require global 1046 routing state for each site and for methods of performing traffic 1047 load balancing that do not require adding even more state. Without 1048 such developments and in the absence of major architectural change, 1049 aggregation is the only tool available for making routing scale in 1050 the global Internet. 1052 10. Security Considerations 1054 The introduction of routing protocols which support classless 1055 prefixes and a move to a forwarding model that mandates that more- 1056 specific (longest-match) routes be preferred when they overlap with 1057 routes to less-specific prefixes introduces at least two security 1058 concerns: 1060 Traffic can be hijacked by advertising a prefix for a given 1061 destination that is more specific than the aggregate that is 1062 normally advertised for that destination. For example, assume a 1063 popular end system with address 192.168.17.100 that is connected 1064 to a service provider that advertises 192.168.16.0/20. A 1065 malicious network operator interested in intercepting traffic for 1066 this site might advertise, or at least attempt to advertise, 1067 192.168.17.0/24 into the global routing system. Because this 1068 prefix is more-specific than the "normal" prefix, traffic will be 1069 diverted away from the legitimate end system and to the network 1070 owned by the malicious operator. Prior to the advent of CIDR, it 1071 was possible to induce traffic from some parts of the network to 1072 follow a false advertisement that exactly matched a particular 1073 network number; CIDR makes this problem somewhat worse, since 1074 longest-match routing generally causes all traffic to prefer more- 1075 specific routes over less-specific routes. The remedy for the 1076 CIDR-based attack, though, is the same as for a pre-CIDR-based 1077 attack: establishment of trust relationships between providers, 1078 coupled with and strong route policy filters at provider borders. 1079 Unfortunately, the implementation of such filters is difficult in 1080 the highly de-centralized Internet. As a workaround, many 1081 providers do implement generic filters that set upper bounds, 1082 derived from RIR guidelines for the sizes of blocks that they 1083 allocate, on the lengths of prefixes that are accepted from other 1084 providers. It is worth noting that "spammers" have been observed 1085 using this sort of attack to temporarily hijack address space in 1086 order to hide the origin of the traffic ("spam" email messages) 1087 that they generate. 1089 Denial-of-service attacks can be launched against many parts of 1090 the Internet infrastructure by advertising a large number of 1091 routes into the system. Such an attack is intended to cause 1092 router failures by overflowing routing and forwarding tables. A 1093 good example of a non-malicious incident which caused this sort of 1094 failure was the infamous "AS 7007" event [7007] where a router 1095 mis-configuration by an operator caused a huge number of invalid 1096 routes to be propagated through the global routing system. Again, 1097 this sort of attack is not really new with CIDR; using legacy 1098 class A/B/C routes, it was possible to advertise a maximum of 1099 16843008 unique network numbers into the global routing system, a 1100 number which is sufficient to cause problems for even the most 1101 modern routing equipment made in 2005. What is different is that 1102 the moderate complexity of correctly configuring routers in the 1103 presence of CIDR does tend to make accidental "attacks" of this 1104 sort more likely. Measures to prevent this sort of attack are 1105 much the same as those described above for the hijacking, with the 1106 addition that best common practice is to also configure a 1107 reasonable maximum number of prefixes that a border router will 1108 accept from its neighbors. 1110 Note that this is not intended to be an exhaustive analysis of the 1111 sorts of attacks that CIDR makes easier; a more comprehensive 1112 analysis of security vulnerabilities in the global routing system 1113 is beyond the scope of this document. 1115 11. Acknowledgments 1117 The authors wish to express appreciation to the other original 1118 authors of RFC1519 (Kannan Varadhan, Jessica Yu), to the ROAD group 1119 with whom many of the ideas behind CIDR were inspired and developed, 1120 and to the early reviewers of this re-spun version of the document 1121 (Barry Greene, Geoff Huston, Danny McPherson, Dave Meyer, Eliot Lear, 1122 Bill Norton, Ted Seely, Philip Smith, Pekka Savola) whose comments, 1123 corrections, and suggestions were invaluable. 1125 12. References 1127 12.1 Normative References 1129 [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. 1131 12.2 Informative References 1133 [RFC1338] Fuller, V., Li, T., Varadhan, K., and J. Yu, 1134 "Supernetting: an Address Assignment and Aggregation 1135 Strategy", RFC 1338, June 1992. 1137 [RFC1519] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Classless 1138 Inter-Domain Routing: an Address Assignment and 1139 Aggregation Strategy", RFC 1519, September 1993. 1141 [IANA] "Internet Assigned Numbers Authority", 1142 . 1144 [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the 1145 Internet", RFC 3221, December 2001. 1147 [NRO] "Number Resource Organization", . 1149 [RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing 1150 and Addressing", RFC 1380, November 1992. 1152 [LWRD] "The Long and Winding Road", 1153 . 1155 [RFC2178] Moy, J., "The OSPF Specification Version 2", RFC 2178, 1156 July 1997. 1158 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1159 dual environments", RFC 1195, December 1990. 1161 [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998. 1163 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 1164 (BGP-4)", RFC 1771, March 1995. 1166 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 1167 June 1988. 1169 [RFC904] Mills, D., "Exterior Gateway Protocol formal 1170 specification", RFC 904, April 1984. 1172 [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, 1173 "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", 1174 RFC 3021, December 2000. 1176 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1177 RFC 2131, March 1997. 1179 [RIPE] "RIPE Network Coordination Centre", . 1181 [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address 1182 Allocation with CIDR", RFC 1518, September 1993. 1184 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 1185 ADDR.ARPA delegation", RFC 2317, March 1998. 1187 [CRPT] "The CIDR Report", . 1189 [CBGP] "Graph: Active BGP Table Entries, 1988 to Present", 1190 . 1192 [CPOL] "CIDR Police - Please Pull Over and Show Us Your BGP", 1193 . 1195 [7007] "NANOG mailing list discussion of the "AS 7007" incident", 1196 . 1199 Authors' Addresses 1201 Vince Fuller 1202 170 W. Tasman Drive 1203 San Jose, CA 95134 1204 USA 1206 Email: vaf@cisco.com 1208 Tony Li 1209 170 W. Tasman Drive 1210 San Jose, CA 95134 1211 USA 1213 Email: tli@cisco.com 1215 Intellectual Property Statement 1217 The IETF takes no position regarding the validity or scope of any 1218 Intellectual Property Rights or other rights that might be claimed to 1219 pertain to the implementation or use of the technology described in 1220 this document or the extent to which any license under such rights 1221 might or might not be available; nor does it represent that it has 1222 made any independent effort to identify any such rights. Information 1223 on the procedures with respect to rights in RFC documents can be 1224 found in BCP 78 and BCP 79. 1226 Copies of IPR disclosures made to the IETF Secretariat and any 1227 assurances of licenses to be made available, or the result of an 1228 attempt made to obtain a general license or permission for the use of 1229 such proprietary rights by implementers or users of this 1230 specification can be obtained from the IETF on-line IPR repository at 1231 http://www.ietf.org/ipr. 1233 The IETF invites any interested party to bring to its attention any 1234 copyrights, patents or patent applications, or other proprietary 1235 rights that may cover technology that may be required to implement 1236 this standard. Please address the information to the IETF at 1237 ietf-ipr@ietf.org. 1239 Disclaimer of Validity 1241 This document and the information contained herein are provided on an 1242 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1243 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1244 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1245 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1246 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1247 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1249 Copyright Statement 1251 Copyright (C) The Internet Society (2005). This document is subject 1252 to the rights, licenses and restrictions contained in BCP 78, and 1253 except as set forth therein, the authors retain all their rights. 1255 Acknowledgment 1257 Funding for the RFC Editor function is currently provided by the 1258 Internet Society.