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