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