idnits 2.17.1 draft-azinger-cidrv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 ([RFC1518], [RFC1887], [RFC1519], [RFC4632]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC1887, but the abstract doesn't seem to directly say this. It does mention RFC1887 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1887, updated by this document, for RFC5378 checks: 1995-12-01) -- 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 29, 2010) is 5049 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) ** Downref: Normative reference to an Informational RFC: RFC 1887 -- Obsolete informational reference (is this intentional?): RFC 1519 (Obsoleted by RFC 4632) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Azinger 3 Internet-Draft Frontier Communications 4 Updates: 1887 (if approved) Corporation 5 Intended status: Standards Track T. Li 6 Expires: December 31, 2010 Cisco Systems 7 J. Weil 8 Cox Communications 9 June 29, 2010 11 CIDR for IPv6: Address Aggregation, Allocation, and Assignment Strategy 12 draft-azinger-cidrv6-00 14 Abstract 16 This document discusses strategies for assigning and aggregating IPv6 17 address space. While CIDR was created to help alleviate this problem 18 in regards to IPv4 addresses with the original [RFC1519] (and updated 19 in [RFC4632]) we are now in need of a similar document to give 20 direction for IPv6 addressing policies. Similarly, [RFC1518] 21 discussed how to use CIDR to allocate address space for IPv4, and 22 [RFC1887] discusses the subject for IPv6. The objective here is to 23 update these documents and provide the best current guidance on how 24 to manage address space in conjunction with managing the growth of 25 routing tables in an IPv6 world. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 31, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Contributing factors to the problem . . . . . . . . . . . . . . 3 63 3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Allocation plan . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Current Statistics and Projections . . . . . . . . . . . . . . 6 66 5.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Projections . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.3. Impact of CIDR . . . . . . . . . . . . . . . . . . . . . . 8 69 6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7. Rules for Route Advertisements . . . . . . . . . . . . . . . . 8 71 8. Responsibility of configuration and aggregation . . . . . . . . 8 72 9. Procedural Changes . . . . . . . . . . . . . . . . . . . . . . 9 73 10. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 9 74 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 77 12.2. Informative References . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 The Internet has continued to evolve and the demands placed on its 82 infrastructure continue to grow at an increasing rate. While there 83 are a number of contributing factors there are a few key elements 84 that have led to a concerning escalation in routing table growth and 85 have made scalability an area of serious concern for network 86 operators. Effort must be put forward to minimize the impact of IPv6 87 deployment to the routing system. Two key aspects of this system 88 include routing table churn composed of routing advertisements and 89 withdrawals and the routing table size as measured by the number of 90 entries in the DFZ, the Default-Free zone. While retaining current 91 Internet practices, this document addresses the problem of routing 92 table size by examining steps to minimize the impact of Multi-homing 93 and Traffic Engineering, two widely implemented features that provide 94 enhanced network resiliency and traffic path control. 96 2. Contributing factors to the problem 98 There are several factors that work against routing table 99 scalability. A full description of the contributing factors and 100 views can be read in [I-D.narten-radir-problem-statement]. The 101 exhaustion of the unassigned IPv4 address space is the principal 102 motivator resulting in two of the key growth drivers. The first 103 driver is the presence of increasingly longer prefixes in the DFZ 104 Over the years the longest prefix generally accepted globally has 105 increased from a relatively small number of classful prefixes to a 106 preponderance of classless /24 CIDR prefixes. As IPv4 address 107 availability diminishes, more Internet users are and will continue to 108 push their providers to route even longer prefixes externally that in 109 the past were filtered. This is something that we must look to 110 minimize and find ways to deter as much as possible. 112 The second driver resulting from IPv4 address exhaustion is the rapid 113 uptake in IPv6 deployment by providers and end users. This adoption, 114 while clearly in the best interest for the long term viability of the 115 Internet, contributes a unique set of challenges that must be 116 addressed to promote efficient routing table growth. Some of these 117 challenges visible today are the liberal assignment of Provider 118 Independent (PI) space to end users, micro-allocations, and critical 119 network infrastructure allocations by the various RIRs. 121 These drivers have increased the need for more guidance on routing 122 policy in order to limit the number of unnecessary entries in the 123 global routing table. The future impact of this increased pressure 124 on routing table growth is an area of immediate concern. 126 3. Aggregation 128 The common method for reducing state on both internal and external 129 routing tables is through aggregation of information. Borrowing from 130 experience gained in operating IPv4 networks, in order for CIDR to 131 succeed in reducing the global routing system growth rate, the IPv6 132 address assignment process needs to make aggregation of routing 133 information along topological lines. In general, the topology of the 134 network has not changed since IPv4 CIDR and even with IPv6 the 135 topology of the network is still determined by the service providers 136 who have built it. . Topologically significant address assignments 137 are necessarily service-provider oriented. 139 Start of Excerpt from [RFC4632] 140 The assignment of prefixes is intended to roughly follow the 141 underlying Internet topology so that aggregation can be used to 142 facilitate scaling of the global routing system. One implication 143 of this strategy is that prefix assignment and aggregation is 144 generally done according to provider-subscriber relationships, 145 since that is how the Internet topology is determined. 146 Aggregation is simple for an end site that is connected to one 147 service provider: it uses address space assigned by its service 148 provider, and that address space is a small piece of a larger 149 block allocated to the service provider. No explicit route is 150 needed for the end site; the service provider advertises a single 151 aggregate route for the larger block. This advertisement provides 152 reachability and routeability for all the customers numbered in 153 the block. 154 There are two, more complex, situations that reduce the 155 effectiveness of aggregation: 156 * An organization that is multi-homed. Because a multi-homed 157 organization must be advertised into the system by each of its 158 service providers, it is often not feasible to aggregate its 159 routing information into the address space of any one of those 160 providers. Note that the organization still may receive its 161 address assignment out of a service provider's address space 162 (which has other advantages), but that a route to the 163 organization's prefix is, in the most general case, explicitly 164 advertised by all of its service providers. For this reason, 165 the global routing cost for a multi-homed organization is 166 generally the same as it was prior to the adoption of CIDR. A 167 more detailed consideration of multi-homing practices can be 168 found in [RFC4116]. 169 * An organization that changes service provider but does not 170 renumber. This has the effect of "punching a hole" in one of 171 the original service provider's aggregated route 172 advertisements. CIDR handles this situation by requiring that 173 the newer service provider to advertise a specific 174 advertisement for the re-homed organization; this advertisement 175 is preferred over provider aggregates because it is a longer 176 match. To maintain efficiency of aggregation, it is 177 recommended that an organization that changes service providers 178 plan eventually to migrate its network into a an prefix 179 assigned from its new provider's address space. To this end, 180 it is recommended that mechanisms to facilitate such migration, 181 such as dynamic host address assignment that uses [RFC2131]), 182 be deployed wherever possible, and that additional protocol 183 work be done to develop improved technology for renumbering. 184 End of Excerpt from [RFC4632] 186 It is important to recognize that some efficiency can still be gained 187 with multi-homed sites (and in general, for any site composed of 188 multiple, logical IPv6 networks). 190 Start of Excerpt from [RFC4632] 191 By allocating a contiguous power-of-two block address space to the 192 site (as opposed to multiple, independent prefixes), the site's 193 routing information may be aggregated into a single prefix. Also, 194 since the routing cost associated with assigning a multi-homed 195 site out of a service provider's address space is no greater than 196 the old method of sequential number assignment by a central 197 authority, it makes sense to assign all end-site address space out 198 of blocks allocated to service providers. 199 It is also worthwhile to mention that since aggregation may occur 200 at multiple levels in the system, it may still be possible to 201 aggregate these anomalous routes at higher levels of whatever 202 hierarchy may be present. For example, if a site is multi-homed 203 to two relatively small providers that both obtain connectivity 204 and address space from the same large provider, then aggregation 205 by the large provider of routes from the smaller networks will 206 include all routes to the multi-homed site. The feasibility of 207 this sort of second-level aggregation depends on whether 208 topological hierarchy exists among a site, its directly-connected 209 providers, and other providers to which they are connected; it may 210 be practical in some regions of the global Internet but not in 211 others. 212 End of Excerpt from [RFC4632] 214 4. Allocation plan 216 Allocations of /32 or shorter prefixes are best provided to network 217 service providers from their regional registries. RIR initial and 218 subsequent allocation policy to service providers should allow for a 219 minimum of 2 years worth of usage based on historical or business 220 plan projections. Organizations should be assigned appropriate 221 subnets from their network service providers larger aggregate 222 allocations that are in turn appropriately sized, such as /48 for 223 organizations wishing to multi-home. 225 Start of Excerpt from [RFC4632] 226 Hierarchical delegation of addresses in this manner implies that 227 sites with addresses assigned out of a given service provider are, 228 for routing purposes, part of that service provider and will be 229 routed via its infrastructure. This implies that routing 230 information about multi-homed organizations (i.e., organizations 231 connected to more than one network service provider) will still 232 need to be known by higher levels in the hierarchy. 233 A historical perspective on these issues is described in 234 [RFC1518]. Additional discussion may also be found in [RFC3221]. 235 End of Excerpt from [RFC4632] 237 Similarly to the days of classful routing, IPv6 is following the same 238 historical path of giving PI assignments. It is in the interests of 239 the network infrastructure to document a best practice for obtaining 240 IPv6 addresses, and it is recommended that most, if not all, network 241 numbers be distributed through service providers. Using the process 242 proposed in this document will support this from becoming a growing 243 problem and will also reduce the scalability concerns core engineers 244 face and the workload for Regional Registries. 246 5. Current Statistics and Projections 248 The good news is that IPv6 has started growing at a significant rate. 249 The bad news is that IPv6 has started growing at a significant rate. 250 Table 1 shows the observed growth for 2009. 252 +----------------+---------+---------+--------+ 253 | | Jan '09 | Dec '09 | Growth | 254 +----------------+---------+---------+--------+ 255 | Prefix count | 1,600 | 2,460 | 54% | 256 | Roots | 1,310 | 1,970 | 50% | 257 | More Specifics | 290 | 490 | 69% | 258 | AS Count | 1,220 | 1,830 | 50% | 259 | Transit | 300 | 390 | 30% | 260 | Stub | 920 | 1,440 | 56% | 261 +----------------+---------+---------+--------+ 263 Table 1: IPv6 Routing Table Statistics for 2009 [Huston]. 265 There are several salient points that should be extracted from this 266 table. The first, and foremost, is that the routing table is now 267 growing rapidly. At 54% growth, this is faster than Moore's law 268 would accommodate. The roots are prefixes that have no 'less 269 specifics' in the routing table. Even at 50% growth per year, this 270 number exceeds Moore's law. More specifics are typically injected to 271 support traffic engineering or multi-homing. 273 The AS count growth shows the number of new organizations 274 participating in BGP. Transit ASes are routing domains that have 275 multiple peer ASes. Stub ASes are routing domains that have only a 276 single peer AS. 278 5.1. Analysis 280 These numbers show that 610 new organizations have joined IPv6 281 routing. Of these new organizations, 85% are stub ASes. The new 282 organizations are injecting 860 new prefixes. Of these, 76% are root 283 prefixes. Since any new AS must inject at least one prefix into 284 routing to be counted, there would appear to be a very high 285 correlation between new stub ASes and new root prefixes. From this, 286 it seems reasonable to conclude that the bulk of the new root 287 prefixes are injected by stub ASes. Further, since it seems unlikely 288 that most of these stub ASes will turn into transit ASes in the 289 future, it also seems reasonable to conclude that these organizations 290 are actually end-user organizations who are injecting routes based on 291 their PI address assignments. 293 Thus, the bulk of the routing table growth appears to be due to PI 294 prefix injection. 296 5.2. Projections 298 Given the high state of flux in the deployment of IPv6, it seems 299 difficult to conclude that the statistics from 2009 will be 300 representative of future routing table growth. Thanks to the influx 301 of new users who are being forced onto IPv6 by the impending IPv4 302 runout, there are plausible arguments that would suggest that growth 303 could accelerate. There are also plausible arguments that suggest 304 that as IPv6 deployment reaches ubiquity, that the growth might 305 curtail in a logistic S-curve. Lacking more data, it is difficult to 306 clearly argue that either of these results is inevitable. 308 It is possible, however, to look at the implications of the current 309 growth rate, if it is sustained at the 2009 rate of 54%. Table 2 310 shows this growth rate: 312 +------+---------------+ 313 | Year | Size | 314 +------+---------------+ 315 | 2009 | 2,460 | 316 | 2010 | 3,788 | 317 | 2011 | 5,834 | 318 | 2012 | 8,985 | 319 | 2013 | 13,836 | 320 | 2014 | 21,308 | 321 | 2015 | 32,814 | 322 | 2020 | 284,225 | 323 | 2025 | 2,461,879 | 324 | 2040 | 1,599,843,323 | 325 +------+---------------+ 327 Table 2: 54% growth rate, extrapolated 329 5.3. Impact of CIDR 331 With the adoption of the plan outlined here, growth of the routing 332 table in a default-free router is greatly reduced since most new 333 address assignments will come from one of the large blocks allocated 334 to the service providers. This plan recognizes the continued need 335 for multi-homing and the requirement to offer multi-homing via IPv6. 336 Due to this requirement multi-homing will be the main reason for the 337 continued growth of the routing table size but not because of 338 independent subnet statements based solely on the desire for 339 independence. 341 6. Protocol 343 This document requires that all parties implement routing protocols 344 for IPv6 as previously published for IPv4 in [RFC4632]. 346 7. Rules for Route Advertisements 348 This document requires that all parties follow the rules for route 349 advertisements for IPv6 as previously published for IPv4 in 350 [RFC4632]. 352 8. Responsibility of configuration and aggregation 354 This document requires that all parties take responsibility of 355 configuration or aggregation for IPv6 as previously published for 356 IPv4 in [RFC4632]. 358 9. Procedural Changes 360 It is possible that some organizations will need to alter their 361 filters to follow the guidance of this document. This is minimal and 362 should not be considered an issue. 364 10. Recommendations 366 Internet Registries should begin to hand out IPv6 blocks of /32 or 367 shorter to network service providers in order to accommodate both 368 their growth and their customers' growth. In addition Internet 369 Registries should severely limit or eliminate the amount of PI 370 assignments in order to help facilitate the decrease in routing table 371 growth. Service providers will allocate /48's to their customer 372 organizations with multi-home requirements. Implementation and 373 deployment of these modifications should occur immediately. 375 11. Acknowledgements 377 The authors would like to extend their thanks to the authors of 378 [RFC4632] (and by extension, to the authors of [RFC1519]). Much of 379 that work has been incorporated directly into this document as it is 380 conceptually identical and simply translated to IPv6 herein. 382 12. References 384 12.1. Normative References 386 [RFC1887] Rekhter, Y. and T. Li, "An 387 Architecture for IPv6 Unicast 388 Address Allocation", RFC 1887, 389 December 1995. 391 [RFC4632] Fuller, V. and T. Li, 392 "Classless Inter-domain Routing 393 (CIDR): The Internet Address 394 Assignment and Aggregation 395 Plan", BCP 122, RFC 4632, 396 August 2006. 398 12.2. Informative References 400 [RFC1518] Rekhter, Y. and T. Li, "An 401 Architecture for IP Address 402 Allocation with CIDR", 403 RFC 1518, September 1993. 405 [RFC1519] Fuller, V., Li, T., Yu, J., and 406 K. Varadhan, "Classless Inter- 407 Domain Routing (CIDR): an 408 Address Assignment and 409 Aggregation Strategy", 410 RFC 1519, September 1993. 412 [RFC2131] Droms, R., "Dynamic Host 413 Configuration Protocol", 414 RFC 2131, March 1997. 416 [RFC3221] Huston, G., "Commentary on 417 Inter-Domain Routing in the 418 Internet", RFC 3221, 419 December 2001. 421 [RFC4116] Abley, J., Lindqvist, K., 422 Davies, E., Black, B., and V. 423 Gill, "IPv4 Multihoming 424 Practices and Limitations", 425 RFC 4116, July 2005. 427 [I-D.narten-radir-problem-statement] Narten, T., "On the Scalability 428 of Internet Routing", draft- 429 narten-radir-problem-statement- 430 05 (work in progress), 431 February 2010. 433 [Huston] Huston, G., "BGP in 2009", . 438 Authors' Addresses 440 Marla Azinger 441 Frontier Communications Corporation 442 Vancouver, WA 443 USA 445 EMail: marla.azinger@frontiercorp.com 446 URI: http://www.frontiercorp.com/ 447 Tony Li 448 Cisco Systems 449 170 West Tasman Dr. 450 San Jose, CA 95134 451 USA 453 Phone: +1 408 853 9317 454 EMail: tony.li@tony.li 456 Jason Weil 457 Cox Communications 458 1400 Lake Hearn Dr. 459 Atlanta, GA 95134 460 USA 462 Phone: +1 404 269 6809 463 EMail: jason.weil@cox.com