idnits 2.17.1 draft-ietf-ipngwg-unicst-addr-allo-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 1995) is 10660 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 - 1 - 4 Network Working Group Y. Rekhter 5 INTERNET DRAFT T.J. Watson Research Center, IBM Corp. 6 T.Li 7 cisco Systems 8 Editors 9 February 1995 11 An Architecture for IPv6 Unicast Address Allocation 12 14 Status of this Memo 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a 25 ``working draft'' or ``work in progress.'' 27 Please check the 1id-abstracts.txt listing contained in the 28 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 29 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 30 current status of any Internet Draft. 32 1 Introduction 34 This document provides an architecture for allocating IPv6 unicast 35 addresses in the Internet. This document does not go into the details 36 of an addressing plan. 38 2 Scope 40 The global internet can be modeled as a collection of hosts 41 interconnected via transmission and switching facilities. Control 42 over the collection of hosts and the transmission and switching 43 facilities that compose the networking resources of the global 44 internet is not homogeneous, but is distributed among multiple 45 administrative authorities. Resources under control of a single 46 administration within a contiguous segment of network topology form a 47 - 2 - 49 domain. For the rest of this paper, `domain' and `routing domain' 50 will be used interchangeably. 52 Domains that share their resources with other domains are called 53 network service providers (or just providers). Domains that utilize 54 other domain's resources are called network service subscribers (or 55 just subscribers). A given domain may act as a provider and a 56 subscriber simultaneously. 58 There are two aspects of interest when discussing IPv6 unicast 59 address allocation within the Internet. The first is the set of 60 administrative requirements for obtaining and allocating IPv6 61 addresses; the second is the technical aspect of such assignments, 62 having largely to do with routing, both within a routing domain 63 (intra-domain routing) and between routing domains (inter-domain 64 routing). This paper focuses on the technical issues. 66 In the current Internet many routing domains (such as corporate and 67 campus networks) attach to transit networks (such as regionals) in 68 only one or a small number of carefully controlled access points. 69 The former act as subscribers, while the latter act as providers. 71 Addressing solutions which require substantial changes or constraints 72 on the current topology are not considered. 74 The architecture and recommendations in this paper are oriented 75 primarily toward the large-scale division of IPv6 address allocation 76 in the Internet. Topics covered include: 78 - Benefits of encoding some topological information in IPv6 79 addresses to significantly reduce routing protocol overhead; 81 - The anticipated need for additional levels of hierarchy in 82 Internet addressing to support network growth; 84 - The recommended mapping between Internet topological entities 85 (i.e., service providers, and service subscribers) and IPv6 86 addressing and routing components; 88 - The recommended division of IPv6 address assignment among 89 service providers (e.g. backbones, regionals), and service 90 subscribers (e.g. sites); 92 - Allocation of the IPv6 addresses by the Internet Registry; 93 - 3 - 95 - Choice of the high-order portion of the IPv6 addresses in leaf 96 routing domains that are connected to more than one service 97 provider (e.g. backbone or a regional network). 99 It is noted that there are other aspects of IPv6 address allocation, 100 both technical and administrative, that are not covered in this 101 paper. Topics not covered or mentioned only superficially include: 103 - A specific plan for address assignment; 105 - Embedding address spaces from other network layer protocols 106 (including IPv4) in the IPv6 address space and the addressing 107 architecture for such embedded addresses; 109 - Multicast addressing; 111 - Address allocation for mobile hosts; 113 - Identification of specific administrative domains in the 114 Internet; 116 - Policy or mechanisms for making registered information known to 117 third parties (such as the entity to which a specific IPv6 118 address or a potion of the IPv6 address space has been 119 allocated); 121 - How a routing domain (especially a site) should organize its 122 internal topology or allocate portions of its IPv6 address 123 space; the relationship between topology and addresses is 124 discussed, but the method of deciding on a particular topology 125 or internal addressing plan is not; and, 127 - Procedures for assigning host IPv6 addresses. 129 3 Background 131 Some background information is provided in this section that is 132 helpful in understanding the issues involved in IPv6 address 133 allocation. A brief discussion of IPv6 routing is provided. 135 IPv6 partitions the routing problem into three parts: 137 - routing exchanges between end systems and routers, 139 - routing exchanges between routers in the same routing domain, 140 and, 142 - routing among routing domains. 144 - 4 - 146 4 IPv6 Addresses and Routing 148 For the purposes of this paper, an IPv6 address prefix is defined as 149 an IPv6 address and some indication of the leftmost contiguous 150 significant bits within this address portion. Throughout this paper 151 IPv6 address prefixes will be represented as X/Y, where X is a prefix 152 of an IPv6 address in length greater than or equal to that specified 153 by Y and Y is the (decimal) number of the leftmost contiguous 154 significant bits within this address. In the notation, X, the prefix 155 of an IPv6 address [1] will have trailing insignificant digits 156 removed. Thus, an IPv6 prefix might appear to be 43DC:0A21:76/40. 158 When determining an administrative policy for IPv6 address 159 assignment, it is important to understand the technical consequences. 160 The objective behind the use of hierarchical routing is to achieve 161 some level of routing data abstraction, or summarization, to reduce 162 the cpu, memory, and transmission bandwidth consumed in support of 163 routing. 165 While the notion of routing data abstraction may be applied to 166 various types of routing information, this paper focuses on one 167 particular type, namely reachability information. Reachability 168 information describes the set of reachable destinations. Abstraction 169 of reachability information dictates that IPv6 addresses be assigned 170 according to topological routing structures. However in practice 171 administrative assignment falls along organizational or political 172 boundaries. These may not be congruent to topological boundaries and 173 therefore the requirements of the two may collide. It is necessary to 174 find a balance between these two needs. 176 Reachability information abstraction occurs at the boundary between 177 hierarchically arranged topological routing structures. An element 178 lower in the hierarchy reports summary reachability information to 179 its parent(s). 181 At routing domain boundaries, IPv6 address information is exchanged 182 (statically or dynamically) with other routing domains. If IPv6 183 addresses within a routing domain are all drawn from non-contiguous 184 IPv6 address spaces (allowing no abstraction), then the address 185 information exchanged at the boundary consists of an enumerated list 186 of all the IPv6 addresses. 188 Alternatively, should the routing domain draw IPv6 addresses for all 189 the hosts within the domain from a single IPv6 address prefix, 190 boundary routing information can be summarized into the single IPv6 191 address prefix. This permits substantial data reduction and allows 192 better scaling (as compared to the uncoordinated addressing discussed 193 in the previous paragraph). 195 - 5 - 197 If routing domains are interconnected in a more-or-less random (i.e., 198 non-hierarchical) scheme, it is quite likely that no further 199 abstraction of routing data can occur. Since routing domains would 200 have no defined hierarchical relationship, administrators would not 201 be able to assign IPv6 addresses within the domains out of some 202 common prefix for the purpose of data abstraction. The result would 203 be flat inter-domain routing; all routing domains would need explicit 204 knowledge of all other routing domains that they route to. This can 205 work well in small and medium sized internets. However, this does 206 not scale to very large internets. For example, we expect IPv6 to 207 grow to hundreds of thousands of routing domains in North America 208 alone. This requires a greater degree of the reachability 209 information abstraction beyond that which can be achieved at the 210 `routing domain' level. 212 In the Internet, it should be possible to significantly constrain the 213 volume and the complexity of routing information by taking advantage 214 of the existing hierarchical interconnectivity. This is discussed 215 further in Section 5. Thus, there is the opportunity for a group of 216 routing domains each to be assigned an address prefix from a shorter 217 prefix assigned to another routing domain whose function is to 218 interconnect the group of routing domains. Each member of the group 219 of routing domains now has its (somewhat longer) prefix, from which 220 it assigns its addresses. 222 The most straightforward case of this occurs when there is a set of 223 routing domains which are all attached to a single service provider 224 domain (e.g. regional network), and which use that provider for all 225 external (inter-domain) traffic. A short prefix may be given to the 226 provider, which then gives slightly longer prefixes (based on the 227 provider's prefix) to each of the routing domains that it 228 interconnects. This allows the provider, when informing other routing 229 domains of the addresses that it can reach, to abstract the 230 reachability information for a large number of routing domains into a 231 single prefix. This approach therefore can allow a great deal of 232 reduction of routing information, and thereby can greatly improve the 233 scalability of inter-domain routing. 235 Clearly, this approach is recursive and can be carried through 236 several iterations. Routing domains at any `level' in the hierarchy 237 may use their prefix as the basis for subsequent suballocations, 238 assuming that the IPv6 addresses remain within the overall length and 239 structure constraints. 241 At this point, we observe that the number of nodes at each lower 242 level of a hierarchy tends to grow exponentially. Thus the greatest 243 gains in the reachability information abstraction (for the benefit of 244 all higher levels of the hierarchy) occur when the reachability 245 information aggregation occurs near the leaves of the hierarchy; the 246 gains drop significantly at each higher level. Therefore, the law of 247 diminishing returns suggests that at some point data abstraction 248 - 6 - 250 ceases to produce significant benefits. Determination of the point 251 at which data abstraction ceases to be of benefit requires a careful 252 consideration of the number of routing domains that are expected to 253 occur at each level of the hierarchy (over a given period of time), 254 compared to the number of routing domains and address prefixes that 255 can conveniently and efficiently be handled via dynamic inter-domain 256 routing protocols. 258 4.1 Efficiency versus Decentralized Control. 260 If the Internet plans to support a decentralized address 261 administration, then there is a balance that must be sought between 262 the requirements on IPv6 addresses for efficient routing and the need 263 for decentralized address administration. A coherent addressing plan 264 at any level within the Internet must take the alternatives into 265 careful consideration. 267 As an example of administrative decentralization, suppose the IPv6 268 address prefix 43/8 identifies part of the IPv6 address space 269 allocated for North America. All addresses within this prefix may be 270 allocated along topological boundaries in support of increased data 271 abstraction. Within this prefix, addresses may be allocated on a 272 per-provider bases, based on geography or some other topologically 273 significant criteria. For the purposes of this example, suppose that 274 this prefix is allocated on a per-provider basis. Subscribers within 275 North America use parts of the IPv6 address space that is underneath 276 the IPv6 address space of their service providers. Within a routing 277 domain addresses for subnetworks and hosts are allocated from the 278 unique IPv6 prefix assigned to the domain according to the addressing 279 plan for that domain. 281 5 IPv6 Address Administration and Routing in the Internet 283 Internet routing components -- service providers (e.g. backbones, 284 regional networks), and service subscribers (e.g. sites or campuses) 285 -- are arranged hierarchically for the most part. A natural mapping 286 from these components to IPv6 routing components is for providers and 287 subscribers to act as routing domains. 289 Alternatively, a subscriber (e.g. a site) may choose to operate as a 290 part of a domain formed by a service provider. We assume that some, 291 if not most, sites will prefer to operate as part of their provider's 292 routing domain, exchanging routing information directly with the 293 provider. The site is still allocated a prefix from the provider's 294 address space, and the provider will advertise its own prefix into 295 inter-domain routing. 297 - 7 - 299 Given such a mapping, where should address administration and 300 allocation be performed to satisfy both administrative 301 decentralization and data abstraction? The following possibilities 302 are considered: 304 1. at some part within a routing domain, 306 2. at the leaf routing domain, 308 3. at the transit routing domain (TRD), and 310 4. at some other, more general boundaries, such as at the 311 continental boundary. 313 A part within a routing domain corresponds to any arbitrary connected 314 set of subnetworks. If a domain is composed of multiple subnetworks, 315 they are interconnected via routers. Leaf routing domains correspond 316 to sites, where the primary purpose is to provide intra-domain 317 routing services. Transit routing domains are deployed to carry 318 transit (i.e., inter-domain) traffic; backbones and providers are 319 TRDs. More general boundaries can be seen as topologically 320 significant collections of TRDs. 322 The greatest burden in transmitting and operating on reachability 323 information is at the top of the routing hierarchy, where 324 reachability information tends to accumulate. In the Internet, for 325 example, providers must manage reachability information for all 326 subscribers directly connected to the provider. Traffic destined for 327 other providers is generally routed to the backbones (which act as 328 providers as well). The backbones, however, must be cognizant of the 329 reachability information for all attached providers and their 330 associated subscribers. 332 In general, the advantage of abstracting routing information at a 333 given level of the routing hierarchy is greater at the higher levels 334 of the hierarchy. There is relatively little direct benefit to the 335 administration that performs the abstraction, since it must maintain 336 routing information individually on each attached topological routing 337 structure. 339 For example, suppose that a given site is trying to decide whether to 340 obtain an IPv6 address prefix directly from the IPv6 address space 341 allocated for North America, or from the IPv6 address space allocated 342 to its service provider. If considering only their own self-interest, 343 the site itself and the attached provider have little reason to 344 choose one approach or the other. The site must use one prefix or 345 another; the source of the prefix has little effect on routing 346 efficiency within the site. The provider must maintain information 347 about each attached site in order to route, regardless of any 348 commonality in the prefixes of the sites. 350 - 8 - 352 However, there is a difference when the provider distributes routing 353 information to other providers (e.g. backbones or TRDs). In the 354 first case, the provider cannot aggregate the site's address into its 355 own prefix; the address must be explicitly listed in routing 356 exchanges, resulting in an additional burden to other providers which 357 must exchange and maintain this information. 359 In the second case, each other provider (e.g. backbone or TRD) sees a 360 single address prefix for the provider, which encompasses the new 361 site. This avoids the exchange of additional routing information to 362 identify the new site's address prefix. Thus, the advantages 363 primarily accrue to other providers which maintain routing 364 information about this site and provider. 366 One might apply a supplier/consumer model to this problem: the higher 367 level (e.g., a backbone) is a supplier of routing services, while the 368 lower level (e.g., a TRD) is the consumer of these services. The 369 price charged for services is based upon the cost of providing them. 370 The overhead of managing a large table of addresses for routing to an 371 attached topological entity contributes to this cost. 373 At present the Internet, however, is not a market economy. Rather, 374 efficient operation is based on cooperation. The recommendations 375 discussed below describe simple and tractable ways of managing the 376 IPv6 address space that benefit the entire community. 378 5.1 Administration of IPv6 addresses within a domain. 380 If individual hosts take their IPv6 addresses from a myriad of 381 unrelated IPv6 address spaces, there will be effectively no data 382 abstraction beyond what is built into existing intra-domain routing 383 protocols. For example, assume that within a routing domain uses 384 three independent prefixes assigned from three different IPv6 address 385 spaces associated with three different attached providers. 387 This has a negative effect on inter-domain routing, particularly on 388 those other domains which need to maintain routes to this domain. 389 There is no common prefix that can be used to represent these IPv6 390 addresses and therefore no summarization can take place at the 391 routing domain boundary. When addresses are advertised by this 392 routing domain to other routing domains, an enumerated list of the 393 three individual prefixes must be used. 395 The number of IPv6 prefixes that leaf routing domains would advertise 396 is on the order of the number of prefixes assigned to the domain; the 397 number of prefixes a provider's routing domain would advertise is 398 approximately the number of prefixes attached to the client leaf 399 routing domains; and for a backbone this would be summed across all 400 - 9 - 402 attached providers. This situation is just barely acceptable in the 403 current Internet, and is intractable for the IPv6 Internet. A 404 greater degree of hierarchical information reduction is necessary to 405 allow continued growth in the Internet. 407 5.2 Administration at the Leaf Routing Domain 409 As mentioned previously, the greatest degree of data abstraction 410 comes at the lowest levels of the hierarchy. Providing each leaf 411 routing domain (that is, site) with a contiguous block of addresses 412 from its provider's address block results in the biggest single 413 increase in abstraction. From outside the leaf routing domain, the 414 set of all addresses reachable in the domain can then be represented 415 by a single prefix. Further, all destinations reachable within the 416 provider's prefix can be represented by a single prefix. 418 For example, consider a single campus which is a leaf routing domain 419 which would currently require 4 different IPv6 prefixes. Instead, 420 they may be given a single prefix which provides the same number of 421 destination addresses. Further, since the prefix is a subset of the 422 provider's prefix, they impose no additional burden on the higher 423 levels of the routing hierarchy. 425 There is a close relationship between hosts and routing domains. The 426 routing domain represents the only path between a host and the rest 427 of the internetwork. It is reasonable that this relationship also 428 extend to include a common IPv6 addressing space. Thus, the hosts 429 within the leaf routing domain should take their IPv6 addresses from 430 the prefix assigned to the leaf routing domain. 432 5.3 Administration at the Transit Routing Domain 434 Two kinds of transit routing domains are considered, direct providers 435 and indirect providers. Most of the subscribers of a direct provider 436 are domains that act solely as service subscribers (they carry no 437 transit traffic). Most of the subscribers of an indirect provider are 438 domains that, themselves, act as service providers. In present 439 terminology a backbone is an indirect provider, while an NSFnet 440 regional is an example of a direct provider. Each case is discussed 441 separately below. 443 5.3.1 Direct Service Providers 445 In a provider-based addressing plan, direct service providers should 446 - 10 - 448 use their IPv6 address space for assigning IPv6 addresses from a 449 unique prefix to the leaf routing domains that they serve. The 450 benefits derived from data abstraction are greater than in the case 451 of leaf routing domains, and the additional degree of data 452 abstraction provided by this may be necessary in the short term. 454 As an illustration consider an example of a direct provider that 455 serves 100 clients. If each client takes its addresses from 4 456 independent address spaces then the total number of entries that are 457 needed to handle routing to these clients is 400 (100 clients times 4 458 providers). If each client takes its addresses from a single address 459 space then the total number of entries would be only 100. Finally, if 460 all the clients take their addresses from the same address space then 461 the total number of entries would be only 1. 463 We expect that in the near term the number of routing domains in the 464 Internet will grow to the point that it will be infeasible to route 465 on the basis of a flat field of routing domains. It will therefore be 466 essential to provide a greater degree of information abstraction with 467 IPv6. 469 Direct providers may give part of their address space (prefixes) to 470 leaf domains, based on an address prefix given to the provider. This 471 results in direct providers advertising to other providers a small 472 fraction of the number of address prefixes that would be necessary if 473 they enumerated the individual prefixes of the leaf routing domains. 474 This represents a significant savings given the expected scale of 475 global internetworking. 477 The efficiencies gained in inter-domain routing clearly warrant the 478 adoption of IPv6 address prefixes derived from the IPv6 address space 479 of the providers. 481 The mechanics of this scenario are straightforward. Each direct 482 provider is given a unique small set of IPv6 address prefixes, from 483 which its attached leaf routing domains can allocate slightly longer 484 IPv6 address prefixes. For example assume that NIST is a leaf 485 routing domain whose inter-domain link is via SURANet. If SURANet is 486 assigned an unique IPv6 address prefix 43DC:0A21/32, NIST could use a 487 unique IPv6 prefix of 43DC:0A21:7652:34/56. 489 If a direct service provider is connected to another provider(s) 490 (either direct or indirect) via multiple attachment points, then in 491 certain cases it may be advantageous to the direct provider to exert 492 a certain degree of control over the coupling between the attachment 493 points and flow of the traffic destined to a particular subscriber. 494 Such control can be facilitated by first partitioning all the 495 subscribers into groups, such that traffic destined to all the 496 subscribers within a group should flow through a particular 497 attachment point. Once the partitioning is done, the address space of 498 - 11 - 500 the provider is subdivided along the group boundaries. A leaf routing 501 domain that is willing to accept prefixes derived from its direct 502 provider gets a prefix from the provider's address space subdivision 503 associated with the group the domain belongs to. 505 At the attachment point (between the direct and indirect providers) 506 the direct provider advertises both an address prefix that 507 corresponds to the address space of the provider, and one or more 508 address prefixes that correspond to the address space associated with 509 each subdivision. The latter prefixes match the former prefix, but 510 are longer than the former prefix. Use of the "longest match" 511 forwarding algorithm by the recipients of these prefixes (e.g. a 512 router within the indirect provider) results in forcing the flow of 513 the traffic to destinations depicted by the longer address prefixes 514 through the attachment point where these prefixes are advertised to 515 the indirect provider. 517 For example, assume that SURANet is connected to another regional 518 provider, NEARNet, at two attachment points, A1 and A2. SURANet is 519 assigned a unique IPv6 address prefix 43DC:0A21/32. To exert control 520 over the traffic flow destined to a particular subscriber within 521 SURANet, SURANet may subdivide the address space assigned to it into 522 two groups, 43DC:0A21:8/34 and 43DC:0A21:C/34. The former group may 523 be used for sites attached to SURANet that are closer (as determined 524 by the topology within SURANet) to A1, while the latter group may be 525 used for sites that are closer to A2. The SURANet router at A1 526 advertises both 43DC:0A21/32 and 43DC:0A21:8/34 address prefixes to 527 the router in NEARNet. Likewise, the SURANet router at A2 advertises 528 both 43DC:0A21/32 and 43DC:0A21:C/34 address prefixes to the router 529 in NEARNet. Traffic that flows through NEARNet to destinations that 530 match 43DC:0A21:8/34 address prefix would enter SURANet at A1, while 531 traffic to destinations that match 43DC:0A21:C/34 address prefix 532 would enter SURANet at A2. 534 Note that the advertisement by the direct provider of the routing 535 information associated with each subdivision must be done with care 536 to ensure that such an advertisement would not result in a global 537 distribution of separate reachability information associated with 538 each subdivision, unless such distribution is warranted for some 539 other purposes (e.g. supporting certain aspects of policy-based 540 routing). 542 5.3.2 Indirect Providers (Backbones) 544 There does not at present appear to be a strong case for direct 545 providers to take their address spaces from the the IPv6 space of an 546 indirect provider (e.g. backbone). The benefit in routing data 547 abstraction is relatively small. The number of direct providers today 548 is in the tens and an order of magnitude increase would not cause an 549 - 12 - 551 undue burden on the backbones. Also, it may be expected that as time 552 goes by there will be increased direct interconnection of the direct 553 providers, leaf routing domains directly attached to the backbones, 554 and international links directly attached to the providers. Under 555 these circumstances, the distinction between direct and indirect 556 providers may become blurred. 558 An additional factor that discourages allocation of IPv6 addresses 559 from a backbone prefix is that the backbones and their attached 560 providers are perceived as being independent. Providers may take 561 their long-haul service from one or more backbones, or may switch 562 backbones should a more cost-effective service be provided elsewhere. 563 Having IPv6 addresses derived from a backbone is inconsistent with 564 the nature of the relationship. 566 5.4 Multi-homed Routing Domains 568 The discussions in Section 5.3 suggest methods for allocating IPv6 569 addresses based on direct or indirect provider connectivity. This 570 allows a great deal of information reduction to be achieved for those 571 routing domains which are attached to a single TRD. In particular, 572 such routing domains may select their IPv6 addresses from a space 573 delegated to them by the direct provider. This allows the provider, 574 when announcing the addresses that it can reach to other providers, 575 to use a single address prefix to describe a large number of IPv6 576 addresses corresponding to multiple routing domains. 578 However, there are additional considerations for routing domains 579 which are attached to multiple providers. Such `multi-homed' routing 580 domains may, for example, consist of single-site campuses and 581 companies which are attached to multiple backbones, large 582 organizations which are attached to different providers at different 583 locations in the same country, or multi-national organizations which 584 are attached to backbones in a variety of countries worldwide. There 585 are a number of possible ways to deal with these multi-homed routing 586 domains. 588 5.4.1 Solution 1 590 One possible solution is for each multi-homed organization to obtain 591 its IPv6 address space independently of the providers to which it is 592 attached. This allows each multi-homed organization to base its IPv6 593 assignments on a single prefix, and to thereby summarize the set of 594 all IPv6 addresses reachable within that organization via a single 595 prefix. The disadvantage of this approach is that since the IPv6 596 address for that organization has no relationship to the addresses of 597 any particular TRD, the TRDs to which this organization is attached 598 - 13 - 600 will need to advertise the prefix for this organization to other 601 providers. Other providers (potentially worldwide) will need to 602 maintain an explicit entry for that organization in their routing 603 tables. 605 For example, suppose that a very large North American company `Mega 606 Big International Incorporated' (MBII) has a fully interconnected 607 internal network and is assigned a single prefix as part of the North 608 American prefix. It is likely that outside of North America, a 609 single entry may be maintained in routing tables for all North 610 American Destinations. However, within North America, every provider 611 will need to maintain a separate address entry for MBII. If MBII is 612 in fact an international corporation, then it may be necessary for 613 every provider worldwide to maintain a separate entry for MBII 614 (including backbones to which MBII is not attached). Clearly this may 615 be acceptable if there are a small number of such multi-homed routing 616 domains, but would place an unacceptable load on routers within 617 backbones if all organizations were to choose such address 618 assignments. This solution may not scale to internets where there 619 are many hundreds of thousands of multi-homed organizations. 621 5.4.2 Solution 2 623 A second possible approach would be for multi-homed organizations to 624 be assigned a separate IPv6 address space for each connection to a 625 TRD, and to assign a single prefix to some subset of its domain(s) 626 based on the closest interconnection point. For example, if MBII had 627 connections to two providers in the U.S. (one east coast, and one 628 west coast), as well as three connections to national backbones in 629 Europe, and one in the far east, then MBII may make use of six 630 different address prefixes. Each part of MBII would be assigned a 631 single address prefix based on the nearest connection. 633 For purposes of external routing of traffic from outside MBII to a 634 destination inside of MBII, this approach works similarly to treating 635 MBII as six separate organizations. For purposes of internal routing, 636 or for routing traffic from inside of MBII to a destination outside 637 of MBII, this approach works the same as the first solution. 639 If we assume that incoming traffic (coming from outside of MBII, with 640 a destination within MBII) is always to enter via the nearest point 641 to the destination, then each TRD which has a connection to MBII 642 needs to announce to other TRDs the ability to reach only those parts 643 of MBII whose address is taken from its own address space. This 644 implies that no additional routing information needs to be exchanged 645 between TRDs, resulting in a smaller load on the inter-domain routing 646 tables maintained by TRDs when compared to the first solution. This 647 solution therefore scales better to extremely large internets 648 containing very large numbers of multi-homed organizations. 650 - 14 - 652 One problem with the second solution is that backup routes to multi- 653 homed organizations are not automatically maintained. With the first 654 solution, each TRD, in announcing the ability to reach MBII, 655 specifies that it is able to reach all of the hosts within MBII. With 656 the second solution, each TRD announces that it can reach all of the 657 hosts based on its own address prefix, which only includes some of 658 the hosts within MBII. If the connection between MBII and one 659 particular TRD were severed, then the hosts within MBII with 660 addresses based on that TRD would become unreachable via inter-domain 661 routing. The impact of this problem can be reduced somewhat by 662 maintenance of additional information within routing tables, but this 663 reduces the scaling advantage of the second approach. 665 The second solution also requires that when external connectivity 666 changes, internal addresses also change. 668 Also note that this and the previous approach will tend to cause 669 packets to take different routes. With the first approach, packets 670 from outside of MBII destined for within MBII will tend to enter via 671 the point which is closest to the source (which will therefore tend 672 to maximize the load on the networks internal to MBII). With the 673 second solution, packets from outside destined for within MBII will 674 tend to enter via the point which is closest to the destination 675 (which will tend to minimize the load on the networks within MBII, 676 and maximize the load on the TRDs). 678 These solutions also have different effects on policies. For example, 679 suppose that country `X' has a law that traffic from a source within 680 country X to a destination within country X must at all times stay 681 entirely within the country. With the first solution, it is not 682 possible to determine from the destination address whether or not the 683 destination is within the country. With the second solution, a 684 separate address may be assigned to those hosts which are within 685 country X, thereby allowing routing policies to be followed. 686 Similarly, suppose that `Little Small Company' (LSC) has a policy 687 that its packets may never be sent to a destination that is within 688 MBII. With either solution, the routers within LSC may be configured 689 to discard any traffic that has a destination within MBII's address 690 space. However, with the first solution this requires one entry; with 691 the second it requires many entries and may be impossible as a 692 practical matter. 694 5.4.3 Solution 3 696 There are other possible solutions as well. A third approach is to 697 assign each multi-homed organization a single address prefix, based 698 on one of its connections to a TRD. Other TRDs to which the multi- 699 homed organization are attached maintain a routing table entry for 700 the organization, but are extremely selective in terms of which other 701 - 15 - 703 TRDs are told of this route. This approach will produce a single 704 `default' routing entry which all TRDs will know how to reach (since 705 presumably all TRDs will maintain routes to each other), while 706 providing more direct routing in some cases. 708 There is at least one situation in which this third approach is 709 particularly appropriate. Suppose that a special interest group of 710 organizations have deployed their own provider. For example, lets 711 suppose that the U.S. National Widget Manufacturers and Researchers 712 have set up a U.S.-wide provider, which is used by corporations who 713 manufacture widgets, and certain universities which are known for 714 their widget research efforts. We can expect that the various 715 organizations which are in the widget group will run their internal 716 networks as separate routing domains, and most of them will also be 717 attached to other TRDs (since most of the organizations involved in 718 widget manufacture and research will also be involved in other 719 activities). We can therefore expect that many or most of the 720 organizations in the widget group are dual-homed, with one attachment 721 for widget-associated communications and the other attachment for 722 other types of communications. Let's also assume that the total 723 number of organizations involved in the widget group is small enough 724 that it is reasonable to maintain a routing table containing one 725 entry per organization, but that they are distributed throughout a 726 larger internet with many millions of (mostly not widget-associated) 727 routing domains. 729 With the third approach, each multi-homed organization in the widget 730 group would make use of an address assignment based on its other 731 attachment(s) to TRDs (the attachments not associated with the widget 732 group). The widget provider would need to maintain routes to the 733 routing domains associated with the various member organizations. 734 Similarly, all members of the widget group would need to maintain a 735 table of routes to the other members via the widget provider. 736 However, since the widget provider does not inform other general 737 worldwide TRDs of what addresses it can reach (since the provider is 738 not intended for use by other outside organizations), the relatively 739 large set of routing prefixes needs to be maintained only in a 740 limited number of places. The addresses assigned to the various 741 organizations which are members of the widget group would provide a 742 `default route' via each members other attachments to TRDs, while 743 allowing communications within the widget group to use the preferred 744 path. 746 5.4.4 Solution 4 748 A fourth solution involves assignment of a particular address prefix 749 for routing domains which are attached to precisely two (or more) 750 specific routing domains. For example, suppose that there are two 751 providers `SouthNorthNet' and `NorthSouthNet' which have a very large 752 - 16 - 754 number of customers in common (i.e., there are a large number of 755 routing domains which are attached to both). Rather than getting two 756 address prefixes these organizations could obtain three prefixes. 757 Those routing domains which are attached to NorthSouthNet but not 758 attached to SouthNorthNet obtain an address assignment based on one 759 of the prefixes. Those routing domains which are attached to 760 SouthNorthNet but not to NorthSouthNet would obtain an address based 761 on the second prefix. Finally, those routing domains which are 762 multi-homed to both of these networks would obtain an address based 763 on the third prefix. Each of these two TRDs would then advertise two 764 prefixes to other TRDs, one prefix for leaf routing domains attached 765 to it only, and one prefix for leaf routing domains attached to both. 767 This fourth solution is likely to be important when use of public 768 data networks becomes more common. In particular, it is likely that 769 at some point in the future a substantial percentage of all routing 770 domains will be attached to public data networks. In this case, 771 nearly all government-sponsored networks (such as some current 772 regionals) may have a set of customers which overlaps substantially 773 with the public networks. 775 5.4.5 Summary 777 There are therefore a number of possible solutions to the problem of 778 assigning IPv6 addresses to multi-homed routing domains. Each of 779 these solutions has very different advantages and disadvantages. 780 Each solution places a different real (i.e., financial) cost on the 781 multi-homed organizations, and on the TRDs (including those to which 782 the multi-homed organizations are not attached). 784 In addition, most of the solutions described also highlight the need 785 for each TRD to develop a policy on whether and under what conditions 786 to accept addresses that are not based on its own address prefix, and 787 how such non-local addresses will be treated. For example, a somewhat 788 conservative policy might be that non-local IPv6 address prefixes 789 will be accepted from any attached leaf routing domain, but not 790 advertised to other TRDs. In a less conservative policy, a TRD might 791 accept such non-local prefixes and agree to exchange them with a 792 defined set of other TRDs (this set could be an a priori group of 793 TRDs that have something in common such as geographical location, or 794 the result of an agreement specific to the requesting leaf routing 795 domain). Various policies involve real costs to TRDs, which may be 796 reflected in those policies. 798 5.5 Private Links 800 The discussion up to this point concentrates on the relationship 801 - 17 - 803 between IPv6 addresses and routing between various routing domains 804 over transit routing domains, where each transit routing domain 805 interconnects a large number of routing domains and offers a more- 806 or-less public service. 808 However, there may also exist a number of links which interconnect 809 two routing domains in such a way, that usage of these links may be 810 limited to carrying traffic only between the two routing domains. 811 We'll refer to such links as "private". 813 For example, let's suppose that the XYZ corporation does a lot of 814 business with MBII. In this case, XYZ and MBII may contract with a 815 carrier to provide a private link between the two corporations, where 816 this link may only be used for packets whose source is within one of 817 the two corporations, and whose destination is within the other of 818 the two corporations. Finally, suppose that the point-to-point link 819 is connected between a single router (router X) within XYZ 820 corporation and a single router (router M) within MBII. It is 821 therefore necessary to configure router X to know which addresses can 822 be reached over this link (specifically, all addresses reachable in 823 MBII). Similarly, it is necessary to configure router M to know which 824 addresses can be reached over this link (specifically, all addresses 825 reachable in XYZ Corporation). 827 The important observation to be made here is that the additional 828 connectivity due to such private links may be ignored for the purpose 829 of IPv6 address allocation, and do not pose a problem for routing on 830 a larger scale. This is because the routing information associated 831 with such connectivity is not propagated throughout the internet, and 832 therefore does not need to be collapsed into a TRD's prefix. 834 In our example, let's suppose that the XYZ corporation has a single 835 connection to a regional, and has therefore uses the IPv6 address 836 space from the space given to that regional. Similarly, let's 837 suppose that MBII, as an international corporation with connections 838 to six different providers, has chosen the second solution from 839 Section 5.4, and therefore has obtained six different address 840 allocations. In this case, all addresses reachable in the XYZ 841 Corporation can be described by a single address prefix (implying 842 that router M only needs to be configured with a single address 843 prefix to represent the addresses reachable over this link). All 844 addresses reachable in MBII can be described by six address prefixes 845 (implying that router X needs to be configured with six address 846 prefixes to represent the addresses reachable over the link). 848 In some cases, such private links may be permitted to forward traffic 849 for a small number of other routing domains, such as closely 850 affiliated organizations. This will increase the configuration 851 requirements slightly. However, provided that the number of 852 organizations using the link is relatively small, then this still 853 does not represent a significant problem. 855 - 18 - 857 Note that the relationship between routing and IPv6 addressing 858 described in other sections of this paper is concerned with problems 859 in scaling caused by large, essentially public transit routing 860 domains which interconnect a large number of routing domains. 861 However, for the purpose of IPv6 address allocation, private links 862 which interconnect only a small number of private routing domains do 863 not pose a problem, and may be ignored. For example, this implies 864 that a single leaf routing domain which has a single connection to a 865 `public' provider (e.g., the Alternet), plus a number of private 866 links to other leaf routing domains, can be treated as if it were 867 single-homed to the provider for the purpose of IPv6 address 868 allocation. We expect that this is also another way of dealing with 869 multi-homed domains. 871 5.6 Zero-Homed Routing Domains 873 Currently, a very large number of organizations have internal 874 communications networks which are not connected to any service 875 providers. Such organizations may, however, have a number of private 876 links that they use for communications with other organizations. Such 877 organizations do not participate in global routing, but are satisfied 878 with reachability to those organizations with which they have 879 established private links. These are referred to as zero-homed 880 routing domains. 882 Zero-homed routing domains can be considered as the degenerate case 883 of routing domains with private links, as discussed in the previous 884 section, and do not pose a problem for inter-domain routing. As 885 above, the routing information exchanged across the private links 886 sees very limited distribution, usually only to the routing domain at 887 the other end of the link. Thus, there are no address abstraction 888 requirements beyond those inherent in the address prefixes exchanged 889 across the private link. 891 However, it is important that zero-homed routing domains use valid 892 globally unique IPv6 addresses. Suppose that the zero-homed routing 893 domain is connected through a private link to a routing domain. 894 Further, this routing domain participates in an internet that 895 subscribes to the global IPv6 addressing plan. This domain must be 896 able to distinguish between the zero-homed routing domain's IPv6 897 addresses and any other IPv6 addresses that it may need to route to. 898 The only way this can be guaranteed is if the zero-homed routing 899 domain uses globally unique IPv6 addresses. 901 Whereas globally unique addresses are necessary to differentiate 902 between destinations in the Internet, globally unique addresses may 903 not be sufficient to guarantee global connectivity. If a zero-homed 904 routing domain gets connected to the Internet, the block of addresses 905 used within the domain may not be related to the block of addresses 906 - 19 - 908 allocated to the domain's direct provider. In order to maintain the 909 gains given by hierarchical routing and address assignment the zero- 910 homed domain should under such circumstances change addresses 911 assigned to the systems within the domain. 913 5.7 Continental aggregation 915 Another level of hierarchy may also be used in this addressing scheme 916 to further reduce the amount of routing information necessary for 917 global routing. Continental aggregation is useful because 918 continental boundaries provide natural barriers to topological 919 connection and administrative boundaries. Thus, it presents a 920 natural boundary for another level of aggregation of inter-domain 921 routing information. To make use of this, it is necessary that each 922 continent be assigned an appropriate contiguous block of addresses. 923 Providers (both direct and indirect) within that continent would 924 allocate their addresses from this space. Note that there are 925 numerous exceptions to this, in which a service provider (either 926 direct or indirect) spans a continental division. These exceptions 927 can be handled similarly to multi-homed routing domains, as discussed 928 above. 930 The benefit of continental aggregation is that it helps to absorb the 931 entropy introduced within continental routing caused by the cases 932 where an organization must use an address prefix which must be 933 advertised beyond its direct provider. In such cases, if the address 934 is taken from the continental prefix, the additional cost of the 935 route is not propagated past the point where continental aggregation 936 takes place. 938 Note that, in contrast to the case of providers, the aggregation of 939 continental routing information may not be done on the continent to 940 which the prefix is allocated. The cost of inter-continental links 941 (and especially trans-oceanic links) is very high. If aggregation is 942 performed on the `near' side of the link, then routing information 943 about unreachable destinations within that continent can only reside 944 on that continent. Alternatively, if continental aggregation is done 945 on the `far' side of an inter-continental link, the `far' end can 946 perform the aggregation and inject it into continental routing. This 947 means that destinations which are part of the continental 948 aggregation, but for which there is not a corresponding more specific 949 prefix can be rejected before leaving the continent on which they 950 originated. 952 For example, suppose that Europe is assigned a prefix of 46/8, such 953 that European routing also contains the longer prefixes 46DC:0A01/32 954 and 46DC:0A02/32 . All of the longer European prefixes may be 955 advertised across a trans-Atlantic link to North America. The router 956 - 20 - 958 in North America would then aggregate these routes, and only 959 advertise the prefix 46/8 into North American routing. Packets which 960 are destined for 46DC:0A01:1234:5678:ABCD:8765:4321:AABB would 961 traverse North American routing, but would encounter the North 962 American router which performed the European aggregation. If the 963 prefix 46DC:0A01/32 is unreachable, the router would drop the packet 964 and send an unreachable message without using the trans-Atlantic 965 link. 967 5.8 Private (Local Use) Addresses 969 Many domains will have hosts which, for one reason or another, will 970 not require globally unique IPv6 addresses. A domain which decides 971 to use IPv6 addresses out of the private address space is able to do 972 so without address allocation from any authority. Conversely, the 973 private address prefix need not be advertised throughout the public 974 portion of the Internet. 976 In order to use private address space, a domain needs to determine 977 which hosts do not need to have network layer connectivity outside 978 the domain in the foreseeable future. Such hosts will be called 979 private hosts, and may use the private addresses described above if 980 it is topologically convenient. Private hosts can communicate with 981 all other hosts inside the domain, both public and private. However, 982 they cannot have IPv6 connectivity to any external host. While not 983 having external network layer connectivity, a private host can still 984 have access to external services via application layer relays. 985 Public hosts do not have connectivity to private hosts outside of 986 their own domain. 988 Because private addresses have no global meaning, reachability 989 information associated with the private address space shall not be 990 propagated on inter-domain links, and packets with private source or 991 destination addresses should not be forwarded across such links. 992 Routers in domains not using private address space, especially those 993 of Internet service providers, are expected to be configured to 994 reject (filter out) routing information that carries reachability 995 information associated with private addresses. If such a router 996 receives such information the rejection shall not be treated as a 997 routing protocol error. 999 In addition, indirect references to private addresses should be 1000 contained within the enterprise that uses these addresses. Prominent 1001 example of such references are DNS Resource Records. A possible 1002 approach to avoid leaking of DNS RRs is to run two nameservers, one 1003 external server authoritative for all globally unique IP addresses of 1004 the enterprise and one internal nameserver authoritative for all IP 1005 addresses of the enterprise, both public and private. In order to 1006 ensure consistency both these servers should be configured from the 1007 - 21 - 1009 same data of which the external nameserver only receives a filtered 1010 version. The resolvers on all internal hosts, both public and 1011 private, query only the internal nameserver. The external server 1012 resolves queries from resolvers outside the enterprise and is linked 1013 into the global DNS. The internal server forwards all queries for 1014 information outside the enterprise to the external nameserver, so all 1015 internal hosts can access the global DNS. This ensures that 1016 information about private hosts does not reach resolvers and 1017 nameservers outside the enterprise. 1019 5.9 Interaction with Policy Routing 1021 We assume that any inter-domain routing protocol will have difficulty 1022 trying to aggregate multiple destinations with dissimilar policies. 1023 At the same time, the ability to aggregate routing information while 1024 not violating routing policies is essential. Therefore, we suggest 1025 that address allocation authorities attempt to allocate addresses so 1026 that aggregates of destinations with similar policies can be easily 1027 formed. 1029 6 Recommendations 1031 We anticipate that the current exponential growth of the Internet 1032 will continue or accelerate for the foreseeable future. In addition, 1033 we anticipate a rapid internationalization of the Internet. The 1034 ability of routing to scale is dependent upon the use of data 1035 abstraction based on hierarchical IPv6 addresses. It is therefore 1036 essential to choose a hierarchical structure for IPv6 addresses with 1037 great care. 1039 Great attention must be paid to the definition of addressing 1040 structures to balance the conflicting goals of: 1042 - route optimality 1044 - routing algorithm efficiency 1046 - ease and administrative efficiency of address registration 1048 - considerations for what addresses are assigned by what 1049 addressing authority 1050 - 22 - 1052 It is in the best interests of the internetworking community that the 1053 cost of operations be kept to a minimum where possible. In the case 1054 of IPv6 address allocation, this again means that routing data 1055 abstraction must be encouraged. 1057 In order for data abstraction to be possible, the assignment of IPv6 1058 addresses must be accomplished in a manner which is consistent with 1059 the actual physical topology of the Internet. For example, in those 1060 cases where organizational and administrative boundaries are not 1061 related to actual network topology, address assignment based on such 1062 organization boundaries is not recommended. 1064 The intra-domain routing protocols allow for information abstraction 1065 to be maintained within a domain. For zero-homed and single-homed 1066 routing domains (which are expected to remain zero-homed or single- 1067 homed), we recommend that the IPv6 addresses assigned within a single 1068 routing domain use a single address prefix assigned to that domain. 1069 Specifically, this allows the set of all IPv6 addresses reachable 1070 within a single domain to be fully described via a single prefix. 1072 We anticipate that the total number of routing domains existing on a 1073 worldwide Internet to be great enough that additional levels of 1074 hierarchical data abstraction beyond the routing domain level will be 1075 necessary. 1077 In most cases, network topology will have a close relationship with 1078 national boundaries. For example, the degree of network connectivity 1079 will often be greater within a single country than between countries. 1080 It is therefore appropriate to make specific recommendations based on 1081 national boundaries, with the understanding that there may be 1082 specific situations where these general recommendations need to be 1083 modified. 1085 Further, from experience with IPv4, we feel that continental 1086 aggregation is beneficial and should be supported where possible as a 1087 means of limiting the unwarranted spread of routing exceptions. 1089 6.1 Recommendations for an address allocation plan 1091 We anticipate that public interconnectivity between private routing 1092 domains will be provided by a diverse set of TRDs, including (but not 1093 necessarily limited to): 1095 - backbone networks; 1097 - a number of regional or national networks; and, 1099 - a number of commercial Public Data Networks. 1101 - 23 - 1103 These networks will not be interconnected in a strictly hierarchical 1104 manner (for example, there is expected to be direct connectivity 1105 between regionals, and all of these types of networks may have direct 1106 international connections). These TRDs will be used to interconnect 1107 a wide variety of routing domains, each of which may comprise a 1108 single corporation, part of a corporation, a university campus, a 1109 government agency, or other organizational unit. 1111 In addition, some private corporations may be expected to make use of 1112 dedicated private TRDs for communication within their own 1113 corporation. 1115 We anticipate that the great majority of routing domains will be 1116 attached to only one of the TRDs. This will permit hierarchical 1117 address aggregation based on TRD. We therefore strongly recommend 1118 that addresses be assigned hierarchically, based on address prefixes 1119 assigned to individual TRDs. 1121 To support continental aggregation of routes, we recommend that all 1122 addresses for TRDs which are wholly within a continent be taken from 1123 the continental prefix. 1125 For the proposed address allocation scheme, this implies that 1126 portions of IPv6 address space should be assigned to each TRD 1127 (explicitly including the backbones and regionals). For those leaf 1128 routing domains which are connected to a single TRD, they should be 1129 assigned a prefix value from the address space assigned to that TRD. 1131 For routing domains which are not attached to any publically 1132 available TRD, there is not the same urgent need for hierarchical 1133 address aggregation. We do not, therefore, make any additional 1134 recommendations for such `isolated' routing domains. Where such 1135 domains are connected to other domains by private point-to-point 1136 links, and where such links are used solely for routing between the 1137 two domains that they interconnect, again no additional technical 1138 problems relating to address abbreviation is caused by such a link, 1139 and no specific additional recommendations are necessary. We do 1140 recommend that since such domains may wish to use a private address 1141 space, that the addressing plan specify a specific prefix for private 1142 addressing. 1144 Further, in order to allow aggregation of IPv6 addresses at national 1145 and continental boundaries into as few prefixes as possible, we 1146 further recommend that IPv6 addresses allocated to routing domains 1147 should be assigned based on each routing domain's connectivity to 1148 national and continental Internet backbones. 1150 - 24 - 1152 6.2 Recommendations for Multi-Homed Routing Domains 1154 Some routing domains will be attached to multiple TRDs within the 1155 same country, or to TRDs within multiple different countries. We 1156 refer to these as `multi-homed' routing domains. Clearly the strict 1157 hierarchical model discussed above does not neatly handle such 1158 routing domains. 1160 There are several possible ways that these multi-homed routing 1161 domains may be handled, as described in Section 5.4. Each of these 1162 methods vary with respect to the amount of information that must be 1163 maintained for inter-domain routing and also with respect to the 1164 inter-domain routes. In addition, the organization that will bear the 1165 brunt of this cost varies with the possible solutions. For example, 1166 the solutions vary with respect to: 1168 - resources used within routers within the TRDs; 1170 - administrative cost on TRD personnel; and, 1172 - difficulty of configuration of policy-based inter-domain 1173 routing information within leaf routing domains. 1175 Also, the solution used may affect the actual routes which packets 1176 follow, and may effect the availability of backup routes when the 1177 primary route fails. 1179 For these reasons it is not possible to mandate a single solution for 1180 all situations. Rather, economic considerations will require a 1181 variety of solutions for different routing domains, service 1182 providers, and backbones. 1184 7 Security Considerations 1186 Security issues are not discussed in this document. 1188 8 Acknowledgments 1190 This document is largely based on RFC1518. The section on Private 1191 Addresses borrowed heavily from RFC1597. 1193 We'd like to thank Havard Eidnes, Bill Manning, Roger Fajman for 1194 their review and constructive comments. 1196 - 25 - 1198 9 Authors' Addresses 1200 Yakov Rekhter 1201 T.J. Watson Research Center, IBM Corporation 1202 30 Saw Mill River Road, 1203 Hawthorne, NY 10532 1204 Phone: (914) 784-7361 1205 email: yakov@watson.ibm.com 1207 Tony Li 1208 cisco Systems, Inc. 1209 1525 O'Brien Drive 1210 Menlo Park, CA 94025 1211 Phone: (408) 526-8186 1212 email: tli@cisco.com 1214 10 References 1216 [1] Francis, P., Deering, S., Hinden, B., Govindan, R., `Simple 1217 Internet Protocol Plus (SIPP): Addressing Architecture' Internet 1218 Draft, July 1994