idnits 2.17.1 draft-azinger-scalable-addressing-01.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 draft header indicates that this document updates RFC1887, but the abstract doesn't seem to mention this, which it should. 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 (October 18, 2010) is 4937 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 1519 (Obsoleted by RFC 4632) Summary: 0 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: BCP T. Li 6 Expires: April 21, 2011 Cisco Systems 7 J. Weil 8 Cox Communications 9 October 18, 2010 11 A Scalable Addressing Allocation Architecture for IPv6 12 draft-azinger-scalable-addressing-01 14 Abstract 16 This document presents a scalable architecture for assigning and 17 aggregating IPv6 address space. The current IPv4 assignment and 18 addressing architecture has been successful in helping to scale the 19 IPv4 routing architecture. This same architecture, when carried 20 forward to IPv6, will help to ensure that the IPv6 routing 21 architecture is sustainable. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 21, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Organizational, technical, and policy issues . . . . . . . . . 3 59 2.1. Delegation to IANA . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Delegation to NRO . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Technical issues vs. policy issues . . . . . . . . . . . . 4 62 3. Contributing factors to the scalability problem . . . . . . . 5 63 4. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Allocation plan . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Current Statistics and Projections . . . . . . . . . . . . . . 9 66 6.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.2. Projections . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.3. Impact of Scalable Addressing . . . . . . . . . . . . . . 10 69 7. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. Rules for Route Advertisements . . . . . . . . . . . . . . . . 11 71 9. Responsibility of configuration and aggregation . . . . . . . 11 72 10. Procedural Changes . . . . . . . . . . . . . . . . . . . . . . 11 73 11. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11 74 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 15.1. Normative References . . . . . . . . . . . . . . . . . . . 12 79 15.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 This document presents a scalable architecture for assigning and 84 aggregating IPv6 address space. The current IPv4 addressing 85 aggregation strategy was defined in [RFC1519] (and updated in 86 [RFC4632]) and the IPv4 address allocation architecture was defined 87 in [RFC1518]. A similar address allocation architecture was proposed 88 for IPv6 in [RFC1887]. The objective of this document is to update 89 the previous documents and provide the best current guidance on an 90 address allocation architecture to help manage the growth of routing 91 tables in IPv6. 93 The Internet has continued to evolve and the demands placed on its 94 infrastructure continue to grow at an increasing rate. While there 95 are a number of contributing factors, there are a few key elements 96 that have led to a concerning escalation in routing table growth and 97 have made scalability an area of serious concern for network 98 operators. Effort must be put forward to minimize the impact of IPv6 99 deployment to the routing subsystem. Two key aspects of this system 100 include routing table churn composed of routing advertisements and 101 withdrawals and the routing table size as measured by the number of 102 entries in the DFZ, the Default-Free zone. While retaining current 103 Internet practices, this document addresses the problem of routing 104 table size by examining steps to minimize the impact of Multi-homing 105 and Traffic Engineering, two widely implemented features that provide 106 enhanced network resiliency and traffic path control. 108 2. Organizational, technical, and policy issues 110 2.1. Delegation to IANA 112 [RFC2860] is a Memorandum of Understanding (MoU) between IETF and 113 ICANN that delegates the technical work of assignment and allocation 114 of addresses to IANA (a function of ICANN) on behalf of the IETF and 115 IRTF (see sections 1 and 4.3). The MoU directs IANA to comply with 116 "the criteria and procedures specified in RFCs, including Proposed, 117 Draft, and full Internet Standards and Best Current Practice 118 documents" (section 4.1). 120 Technical disputes in this agreement are first directed to the IESG, 121 and if not resolved, arbitrated by the IAB (sections 4.1, R 4.2). 123 The document specifically stipulates that policy issues around IP 124 addressing are outside of the scope of the MoU (section 4.4). 126 2.2. Delegation to NRO 128 ICANN in turn delegates block allocation to the Number Resource 129 Organization (NRO) [ASOMoU]. The NRO is composed of the Regional 130 Internet Registries (RIRs) [NROMoU]. 132 2.3. Technical issues vs. policy issues 134 The documents cited above make it clear that policy issues are 135 delegated from the IETF through ICANN and IANA to the RIRs. The same 136 documents make it equally clear that the IETF is still responsible 137 for technical matters and procedures. 139 The routing subsystem is a key component of the Internet. Without 140 routing, no packets are delivered. The routing subsystem consists of 141 multiple routing protocols as well as the procedures for utilizing 142 these protocols to provide coherent and timely routing services. The 143 procedures for deploying and operating the routing subsystem are 144 characterized in the routing architecture. Specifying the routing 145 architecture is a technical issue. 147 A key issue in the routing architecture is the scalability of the 148 architecture. If the architecture fails to scale, then the routing 149 subsystem can fail, either in its basic functionality, from a 150 performance perspective, or from a cost perspective. For the routing 151 architecture to scale, the amount of data propagated within the 152 routing subsystem must be limited, as the routing subsystem must 153 ultimately have a hardware instantiation, and unlimited hardware 154 simply does not exist. 156 As technology progresses over time, the intrinsic capabilities of 157 hardware improves. There are multiple dimensions for improvement, 158 each with their own trend lines and projections. Based on these 159 trends, we can reasonably expect that hardware scalability will 160 improve over time, tracking these trends. As a result, for the 161 routing architecture to scale, it must operate within the growth 162 rates of these trends. Thus, ensuring that the routing subsystem 163 scales at no more than an appropriate rate of growth is a technical 164 issue. 166 The scalability of the routing subsystem is wholly dependent on the 167 addressing architecture for the network. Routing views the network 168 as a graph composed of nodes and edges between those nodes. Carrying 169 information about each node and edge of the graph does not scale, so 170 routing works by creating abstractions of entire subgraphs. The most 171 productive abstractions happen when the subgraph is closely 172 topologically related, such as when all of the nodes in the subgraph 173 are interconnected by the edges in the subgraph. We can further 174 create hierarchies of abstractions to get further scalability. 176 Poorly chosen abstractions that do not align with the topology of the 177 network result in abstractions that do not reduce the data burden on 178 routing, as additional data is needed for path computation. Thus, 179 the correct procedures for creating abstractions in the topology are 180 also a technical issue. 182 To manipulate data about the network in a convenient manner, we give 183 names to nodes in the network, where each name is an address. If 184 names are assigned in a manner that is consistent with the hierarchy 185 of abstractions, then a single name can also be used to represent a 186 subgraph of the network, such as a single site. These types of names 187 are known as prefixes or aggregates and the overall procedure for 188 assigning addresses to nodes and aggregates to subgraphs is the 189 addressing architecture for the network. Clearly, the correct 190 application and operation of the addressing architecture is central 191 to the operation and ongoing scalability of the routing architecture. 193 The operation of the addressing architecture involves both technical 194 issues and policy issues. Procedures for determining subgraph 195 boundaries and subsequent prefix allocations are clearly driven by 196 the technical requirements of the architecture. From a technical 197 perspective, the graph is composed of many different types of nodes. 198 These include leaf nodes, multiply connected nodes with a minimal 199 number of edges, and densely connected nodes. Determining the 200 current connectivity of a site is clearly a technical issue. Judging 201 how that site might evolve in the future and thus the role that the 202 site should play in the addressing architecture is a matter of 203 policy. 205 These issues are simply examples. There are likely to be many more, 206 some of which may be contentious. Completely separating the 207 technical issues from the policy issues is decidedly non-trivial and 208 is most likely an inefficient exercise. In reality and for pragmatic 209 purposes, it is necessary that all issues be resolved in a consistent 210 and compatible manner. The end goal is clearly shared: the 211 successful operation of a scalable routing and addressing 212 architecture. 214 This document deals with the technical aspects of the addressing 215 architecture. 217 3. Contributing factors to the scalability problem 219 There are several factors that work against routing table 220 scalability. A full description of the contributing factors and 221 views can be read in [I-D.narten-radir-problem-statement]. The 222 exhaustion of the unassigned IPv4 address space is the principal 223 motivator resulting in two of the key growth drivers. The first 224 driver is the presence of increasingly longer prefixes in the DFZ. 225 Over the years the longest prefix generally accepted globally has 226 increased from a relatively small number of classful prefixes to a 227 preponderance of classless /24 CIDR prefixes. As IPv4 address 228 availability diminishes, more Internet users are and will continue to 229 push their providers to route even longer prefixes externally that in 230 the past were filtered. This is something that we must look to 231 minimize and find ways to deter as much as possible for IPv6. 233 The second driver resulting from IPv4 address exhaustion is the rapid 234 uptake in IPv6 deployment by providers and end users. This adoption, 235 while clearly in the best interest for the long term viability of the 236 Internet, contributes a unique set of challenges that must be 237 addressed to promote efficient routing table growth. Some of these 238 challenges visible today are the liberal assignment of Provider 239 Independent (PI) space to end users, micro-allocations, and critical 240 network infrastructure allocations by the various RIRs. 242 These drivers have increased the need for more guidance on the 243 addressing architecture in order to limit the number of unnecessary 244 entries in the global routing table. The future impact of this 245 increased pressure on routing table growth is an area of immediate 246 concern. 248 4. Aggregation 250 The common method for reducing state on both internal and external 251 routing tables is through aggregation of information. Borrowing from 252 experience gained in operating IPv4 networks, in order for 253 aggregation to succeed in reducing the global routing system growth 254 rate, the IPv6 address assignment process needs to make aggregation 255 of routing information along topological lines. In general, the 256 topology of the network has not changed since IPv4 CIDR and even with 257 IPv6 the topology of the network is still determined by the service 258 providers who have built it. Topologically significant address 259 assignments are necessarily service-provider oriented. 261 Start of Excerpt from [RFC4632] 262 The assignment of prefixes is intended to roughly follow the 263 underlying Internet topology so that aggregation can be used to 264 facilitate scaling of the global routing system. One implication 265 of this strategy is that prefix assignment and aggregation is 266 generally done according to provider-subscriber relationships, 267 since that is how the Internet topology is determined. [Section 268 3] 269 Aggregation is simple for an end site that is connected to one 270 service provider: it uses address space assigned by its service 271 provider, and that address space is a small piece of a larger 272 block allocated to the service provider. No explicit route is 273 needed for the end site; the service provider advertises a single 274 aggregate route for the larger block. This advertisement provides 275 reachability and routeability for all the customers numbered in 276 the block. 277 There are two, more complex, situations that reduce the 278 effectiveness of aggregation: 279 * An organization that is multi-homed. Because a multi-homed 280 organization must be advertised into the system by each of its 281 service providers, it is often not feasible to aggregate its 282 routing information into the address space of any one of those 283 providers. Note that the organization still may receive its 284 address assignment out of a service provider's address space 285 (which has other advantages), but that a route to the 286 organization's prefix is, in the most general case, explicitly 287 advertised by all of its service providers. For this reason, 288 the global routing cost for a multi-homed organization is 289 generally the same as it was prior to the adoption of CIDR. A 290 more detailed consideration of multi-homing practices can be 291 found in [RFC4116]. 292 * An organization that changes service provider but does not 293 renumber. This has the effect of "punching a hole" in one of 294 the original service provider's aggregated route 295 advertisements. CIDR handles this situation by requiring that 296 the newer service provider to advertise a specific 297 advertisement for the re-homed organization; this advertisement 298 is preferred over provider aggregates because it is a longer 299 match. To maintain efficiency of aggregation, it is 300 recommended that an organization that changes service providers 301 plan eventually to migrate its network into a prefix assigned 302 from its new provider's address space. To this end, it is 303 recommended that mechanisms to facilitate such migration, such 304 as dynamic host address assignment that uses [RFC2131]), be 305 deployed wherever possible, and that additional protocol work 306 be done to develop improved technology for renumbering. 307 [Section 4.1] 308 End of Excerpt from [RFC4632] 310 It is important to recognize that some efficiency can still be gained 311 with multi-homed sites (and in general, for any site composed of 312 multiple, logical IPv6 networks). 314 Start of Excerpt from [RFC4632] 315 By allocating a contiguous power-of-two block address space to the 316 site (as opposed to multiple, independent prefixes), the site's 317 routing information may be aggregated into a single prefix. Also, 318 since the routing cost associated with assigning a multi-homed 319 site out of a service provider's address space is no greater than 320 the old method of sequential number assignment by a central 321 authority, it makes sense to assign all end-site address space out 322 of blocks allocated to service providers. 323 It is also worthwhile to mention that since aggregation may occur 324 at multiple levels in the system, it may still be possible to 325 aggregate these anomalous routes at higher levels of whatever 326 hierarchy may be present. For example, if a site is multi-homed 327 to two relatively small providers that both obtain connectivity 328 and address space from the same large provider, then aggregation 329 by the large provider of routes from the smaller networks will 330 include all routes to the multi-homed site. The feasibility of 331 this sort of second-level aggregation depends on whether 332 topological hierarchy exists among a site, its directly-connected 333 providers, and other providers to which they are connected; it may 334 be practical in some regions of the global Internet but not in 335 others. [Section 4.1] 336 End of Excerpt from [RFC4632] 338 5. Allocation plan 340 Allocations of shorter prefixes are best provided to network service 341 providers from their regional registries. RIR initial and subsequent 342 allocation policy to service providers should allow for a minimum of 343 2 years worth of usage based on historical or business plan 344 projections. Organizations should be assigned appropriate subnets 345 from their network service providers larger aggregate allocations 346 that are in turn appropriately sized for organizations wishing to 347 multi-home. 349 Start of Excerpt from [RFC4632] 350 Hierarchical delegation of addresses in this manner implies that 351 sites with addresses assigned out of a given service provider are, 352 for routing purposes, part of that service provider and will be 353 routed via its infrastructure. This implies that routing 354 information about multi-homed organizations (i.e., organizations 355 connected to more than one network service provider) will still 356 need to be known by higher levels in the hierarchy. 357 A historical perspective on these issues is described in 358 [RFC1518]. Additional discussion may also be found in [RFC3221]. 359 [Section 4.2] 360 End of Excerpt from [RFC4632] 362 Similarly to the days of classful routing, IPv6 is following the same 363 historical path of giving PI assignments. It is in the interests of 364 the network infrastructure to document a best practice for obtaining 365 IPv6 addresses, and it is recommended that most, if not all, network 366 numbers be distributed through service providers. Using the process 367 proposed in this document will support this from becoming a growing 368 problem and will also reduce the scalability concerns core engineers 369 face and the workload for Regional Registries. 371 6. Current Statistics and Projections 373 The good news is that IPv6 has started growing at a significant rate. 374 The bad news is that IPv6 has started growing at a significant rate. 375 Table 1 shows the observed growth for 2009. 377 +----------------+---------+---------+--------+ 378 | | Jan '09 | Dec '09 | Growth | 379 +----------------+---------+---------+--------+ 380 | Prefix count | 1,600 | 2,460 | 54% | 381 | Roots | 1,310 | 1,970 | 50% | 382 | More Specifics | 290 | 490 | 69% | 383 | AS Count | 1,220 | 1,830 | 50% | 384 | Transit | 300 | 390 | 30% | 385 | Stub | 920 | 1,440 | 56% | 386 +----------------+---------+---------+--------+ 388 Table 1: IPv6 Routing Table Statistics for 2009 [Huston]. 390 There are several salient points that should be extracted from this 391 table. The first, and foremost, is that the routing table is now 392 growing rapidly. At 54% growth, this is faster than Moore's law 393 would accommodate. The roots are prefixes that have no 'less 394 specifics' in the routing table. Even at 50% growth per year, this 395 number exceeds Moore's law. More specifics are typically injected to 396 support traffic engineering or multi-homing. 398 The AS count growth shows the number of new organizations 399 participating in BGP. Transit ASes are routing domains that have 400 multiple peer ASes. Stub ASes are routing domains that have only a 401 single peer AS. 403 6.1. Analysis 405 These numbers show that 610 new organizations have joined IPv6 406 routing. Of these new organizations, 85% are stub ASes. The new 407 organizations are injecting 860 new prefixes. Of these, 76% are root 408 prefixes. Since any new AS must inject at least one prefix into 409 routing to be counted, there would appear to be a very high 410 correlation between new stub ASes and new root prefixes. From this, 411 it seems reasonable to conclude that the bulk of the new root 412 prefixes are injected by stub ASes. Further, since it seems unlikely 413 that most of these stub ASes will turn into transit ASes in the 414 future, it also seems reasonable to conclude that these organizations 415 are actually end-user organizations who are injecting routes based on 416 their PI address assignments. 418 Thus, the bulk of the routing table growth appears to be due to PI 419 prefix injection. 421 6.2. Projections 423 Given the high state of flux in the deployment of IPv6, it seems 424 difficult to conclude that the statistics from 2009 will be 425 representative of future routing table growth. Thanks to the influx 426 of new users who are being forced onto IPv6 by the impending IPv4 427 runout, there are plausible arguments that would suggest that growth 428 could accelerate. There are also plausible arguments that suggest 429 that as IPv6 deployment reaches ubiquity, that the growth might 430 curtail in a logistic S-curve. Lacking more data, it is difficult to 431 clearly argue that either of these results is inevitable. 433 It is possible, however, to look at the implications of the current 434 growth rate, if it is sustained at the 2009 rate of 54%. Table 2 435 shows this growth rate: 437 +------+---------------+ 438 | Year | Size | 439 +------+---------------+ 440 | 2009 | 2,460 | 441 | 2010 | 3,788 | 442 | 2011 | 5,834 | 443 | 2012 | 8,985 | 444 | 2013 | 13,836 | 445 | 2014 | 21,308 | 446 | 2015 | 32,814 | 447 | 2020 | 284,225 | 448 | 2025 | 2,461,879 | 449 | 2040 | 1,599,843,323 | 450 +------+---------------+ 452 Table 2: 54% growth rate, extrapolated 454 6.3. Impact of Scalable Addressing 456 With the adoption of the plan outlined here, growth of the routing 457 table in a default-free router is greatly reduced since most new 458 address assignments will come from one of the large blocks allocated 459 to the service providers. This plan recognizes the continued need 460 for multi-homing and the requirement to offer multi-homing via IPv6. 461 Due to this requirement multi-homing will be the main reason for the 462 continued growth of the routing table size but not because of 463 independent subnet statements based solely on the desire for 464 independence. 466 7. Protocol 468 This document requires that all parties implement routing protocols 469 for IPv6 as previously published for IPv4 in [RFC4632]. 471 8. Rules for Route Advertisements 473 This document requires that all parties follow the rules for route 474 advertisements for IPv6 as previously published in [RFC1887] and as 475 similarly published for IPv4 in [RFC4632]. 477 9. Responsibility of configuration and aggregation 479 This document requires that all parties take responsibility of 480 configuration or aggregation for IPv6 as previously published 481 [RFC1887] and as similarly published for IPv4 in [RFC4632]. 483 10. Procedural Changes 485 It is possible that some organizations will need to alter their 486 filters to follow the guidance of this document. This is minimal and 487 should not be considered an issue. 489 11. Recommendations 491 Internet Registries should begin to hand out large IPv6 blocks to 492 network service providers in order to accommodate both their growth 493 and their customers' growth. In addition Internet Registries should 494 severely limit or eliminate the amount of PI assignments in order to 495 help facilitate the decrease in routing table growth. Service 496 providers will allocate address blocks from their aggregates to their 497 customer organizations with multi-homing requirements. 498 Implementation and deployment of these modifications should occur 499 immediately. 501 12. Security Considerations 503 The recommendations in this document create no new security concerns. 505 13. IANA Considerations 507 This document makes no requests to IANA. 509 14. Acknowledgements 511 The authors would like to extend their thanks to the authors of 512 [RFC1887] and [RFC4632] (and by extension, to the authors of 513 [RFC1519]). Much of that work has been incorporated directly into 514 this document as it is conceptually identical and simply translated 515 to IPv6 herein. 517 15. References 519 15.1. Normative References 521 [RFC4632] Fuller, V. and T. Li, 522 "Classless Inter-domain Routing 523 (CIDR): The Internet Address 524 Assignment and Aggregation 525 Plan", BCP 122, RFC 4632, 526 August 2006. 528 15.2. Informative References 530 [RFC1518] Rekhter, Y. and T. Li, "An 531 Architecture for IP Address 532 Allocation with CIDR", 533 RFC 1518, September 1993. 535 [RFC1519] Fuller, V., Li, T., Yu, J., and 536 K. Varadhan, "Classless Inter- 537 Domain Routing (CIDR): an 538 Address Assignment and 539 Aggregation Strategy", 540 RFC 1519, September 1993. 542 [RFC1887] Rekhter, Y. and T. Li, "An 543 Architecture for IPv6 Unicast 544 Address Allocation", RFC 1887, 545 December 1995. 547 [RFC2131] Droms, R., "Dynamic Host 548 Configuration Protocol", 549 RFC 2131, March 1997. 551 [RFC2860] Carpenter, B., Baker, F., and 552 M. Roberts, "Memorandum of 553 Understanding Concerning the 554 Technical Work of the Internet 555 Assigned Numbers Authority", 556 RFC 2860, June 2000. 558 [RFC3221] Huston, G., "Commentary on 559 Inter-Domain Routing in the 560 Internet", RFC 3221, 561 December 2001. 563 [RFC4116] Abley, J., Lindqvist, K., 564 Davies, E., Black, B., and V. 565 Gill, "IPv4 Multihoming 566 Practices and Limitations", 567 RFC 4116, July 2005. 569 [I-D.narten-radir-problem-statement] Narten, T., "On the Scalability 570 of Internet Routing", draft- 571 narten-radir-problem-statement- 572 05 (work in progress), 573 February 2010. 575 [Huston] Huston, G., "BGP in 2009", . 580 [ASOMoU] "ICANN Address Supporting 581 Organization (ASO) MoU", . 585 [NROMoU] "NRO Memorandum of 586 Understanding", . 590 Authors' Addresses 592 Marla Azinger 593 Frontier Communications Corporation 594 Vancouver, WA 595 USA 597 EMail: marla.azinger@frontiercorp.com 598 URI: http://www.frontiercorp.com/ 599 Tony Li 600 Cisco Systems 601 170 West Tasman Dr. 602 San Jose, CA 95134 603 USA 605 Phone: +1 408 853 9317 606 EMail: tony.li@tony.li 608 Jason Weil 609 Cox Communications 610 1400 Lake Hearn Dr. 611 Atlanta, GA 95134 612 USA 614 Phone: +1 404 269 6809 615 EMail: jason.weil@cox.com