idnits 2.17.1 draft-rekhter-ipaddress-guide-03.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-19) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. ** Expected the document's filename to be given on the first page, but didn't find any ** 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 24 longer pages, the longest (page 1) being 62 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 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (September 1992) is 11539 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' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Rekhter 3 Request for Comments: DRAFT T.J. Watson Research Center, IBM Corp. 4 T.Li 5 cisco Systems 6 Editors 7 September 1992 9 Guidelines for IP Address Allocation 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a 22 ``working draft'' or ``work in progress.'' 24 Please check the 1id-abstracts.txt listing contained in the 25 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 26 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 27 current status of any Internet Draft. 29 1 Introduction 31 This paper provides guidelines for allocating IP addresses in the 32 Internet. These guidelines are intended to play an important role in 33 steering the Internet towards the Address Assignment and Aggregating 34 Strategy outlined in [1]. 36 2 Scope 38 The global internet can be modeled as a collection of hosts 39 interconnected via transmission and switching facilities. Control 40 over the collection of hosts and the transmission and switching 41 facilities that compose the networking resources of the global 42 internet is not homogeneous, but is distributed among multiple 43 administrative authorities. Resources under control of a single 44 administration form a domain. For the rest of this paper, `domain' 45 and `routing domain' will be used interchangeably. 47 Domains that share their resources with other domains are called 48 service providers (or just providers). Domains that utilize other 49 domain's resources are called service subscribers (or just 51 RFC DRAFT September 1992 53 subscribers). A given domain may act as a provider and a subscriber 54 simultaneously. 56 There are two aspects of interest when discussing IP address 57 allocation within the Internet. The first is the set of 58 administrative requirements for obtaining and allocating IP 59 addresses; the second is the technical aspect of such assignments, 60 having largely to do with routing, both within a routing domain 61 (intra-domain routing) and between routing domains (inter-domain 62 routing). This paper focuses on the technical issues. 64 The technical issues in IP address allocation are mainly related to 65 routing. 67 In the current Internet many routing domains (such as corporate and 68 campus networks) attach to transit networks (such as NSFNET 69 regionals) in only one or a small number of carefully controlled 70 access points. The former act as subscribers, while the latter act 71 as providers. 73 The guidelines provided in this paper are intended for immediate 74 deployment. This paper specifically does not address long-term 75 research issues, such as complex policy-based routing requirements. 77 Addressing solutions which require substantial changes or constraints 78 on the current topology are not considered. 80 The guidelines in this paper are oriented primarily toward the 81 large-scale division of IP address allocation in the Internet. Topics 82 covered include: 84 Benefits of encoding some topological information in IP addresses to 85 reduce routing protocol overhead; 87 The anticipated need for additional levels of hierarchy in Internet 88 addressing to support network growth; 90 The recommended mapping between Internet topological entities (i.e., 91 service providers, and service subscribers) and IP addressing and 92 routing components; 94 The recommended division of IP address assignment authority among 95 service providers (e.g. backbones, regionals), and service 96 subscribers (e.g. sites); Background information on administrative 97 procedures for registration of administrative authorities immediately 98 below the national level; and, Choice of the high-order portion of 99 the IP addresses in leaf routing domains that are connected to more 100 than one service provider (e.g. backbone or a regional network). 102 It is noted that there are other aspects of IP address allocation, 103 both technical and administrative, that are not covered in this 104 paper. Topics not covered or mentioned only superficially include: 106 Identification of specific administrative domains in the Internet; 108 RFC DRAFT September 1992 110 Policy or mechanisms for making registered information known to third 111 parties (such as the entity to which a specific IP address or a 112 potion of the IP address space has been allocated); How a routing 113 domain (especially a site) should organize its internal topology or 114 allocate portions of its IP address space; the relationship between 115 topology and addresses is discussed, but the method of deciding on a 116 particular topology or internal addressing plan is not; and, 117 Procedures for assigning the host IP addresses. 119 3 Background 121 Some background information is provided in this section that is 122 helpful in understanding the issues involved in IP address 123 allocation. A brief discussion of IP routing is provided. 125 IP partitions the routing problem into three parts: 127 routing exchanges between end systems and routers (ARP), routing 128 exchanges between routers in the same routing domain (interior 129 routing), and, 131 routing among routing domains (exterior routing). 133 4 IP Addresses and Routing 135 For the purposes of this paper, an IP prefix is an IP address and 136 some indication of the leftmost contiguous significant bits within 137 this address. Throughout this paper IP address prefixes will be 138 expressed as tuples, such that a bitwise logical 139 AND operation on the IP-address and IP-mask components of a tuple 140 yields the sequence of leftmost contiguous significant bits that form 141 the IP address prefix. For example a tuple with the value <193.1.0.0 142 255.255.0.0> denotes an IP address prefix with 16 leftmost contiguous 143 significant bits. 145 When determining an administrative policy for IP address assignment, 146 it is important to understand the technical consequences. The 147 objective behind the use of hierarchical routing is to achieve some 148 level of routing data abstraction, or summarization, to reduce the 149 cpu, memory, and transmission bandwidth consumed in support of 150 routing. 152 While the notion of routing data abstraction may be applied to 153 various types of routing information, this paper focuses on one 154 particular type, namely reachability information. Reachability 155 information describes the set of reachable destinations. Abstraction 156 of reachability information dictates that IP addresses be assigned 157 according to topological routing structures. However, administrative 158 assignment falls along organizational or political boundaries. These 159 may not be congruent to topological boundaries and therefore the 161 RFC DRAFT September 1992 163 requirements of the two may collide. It is necessary to find a 164 balance between these two needs. 166 Routing data abstraction occurs at the boundary between 167 hierarchically arranged topological routing structures. An element 168 lower in the hierarchy reports summary routing information to its 169 parent(s). 171 At routing domain boundaries, IP address information is exchanged 172 (statically or dynamically) with other routing domains. If IP 173 addresses within a routing domain are all drawn from distinct IP 174 address assignment authorities (allowing no abstraction), then the 175 boundary information consists of an enumerated list of all the IP 176 addresses. 178 Alternatively, should the routing domain draw IP addresses for all 179 the hosts within the domain from a single IP address assignment 180 authority, boundary routing information can be summarized into the 181 single IP address prefix. This permits substantial data reduction 182 and allows better scaling (as compared to the uncoordinated 183 addressing discussed in the previous paragraph). 185 If routing domains are interconnected in a more-or-less random (i.e., 186 non-hierarchical) scheme, it is quite likely that no further 187 abstraction of routing data can occur. Since routing domains would 188 have no defined hierarchical relationship, administrators would not 189 be able to assign IP addresses within the domains out of some common 190 prefix for the purpose of data abstraction. The result would be flat 191 inter-domain routing; all routing domains would need explicit 192 knowledge of all other routing domains that they route to. This can 193 work well in small and medium sized internets, up to a size somewhat 194 larger than the current Internet. However, this does not scale to 195 very large internets. For example, we expect growth in the future to 196 an Internet which has tens or hundreds of thousands of routing 197 domains in North America alone. This requires a greater degree of 198 the reachability information abstraction beyond that which can be 199 achieved at the `routing domain' level. 201 In the Internet, however, it should be possible to exploit the 202 existing hierarchical routing structure interconnections, as 203 discussed in Section 5. Thus, there is the opportunity for a group of 204 routing domains each to be assigned an address prefix from a shorter 205 prefix assigned to another routing domain whose function is to 206 interconnect the group of routing domains. Each member of the group 207 of routing domains now `owns' its (somewhat longer) prefix, from 208 which it assigns its addresses. 210 The most straightforward case of this occurs when there is a set of 211 routing domains which are all attached only to a single service 212 provider domain (e.g. regional network), and which use that provider 213 for all external (inter-domain) traffic. A small prefix may be 214 assigned to the provider, which then assigns slightly longer prefixes 215 (based on the provider's prefix) to each of the routing domains that 216 it interconnects. This allows the provider, when informing other 218 RFC DRAFT September 1992 220 routing domains of the addresses that it can reach, to abbreviate the 221 reachability information for a large number of routing domains as a 222 single prefix. This approach therefore can allow a great deal of 223 hierarchical abbreviation of routing information, and thereby can 224 greatly improve the scalability of inter-domain routing. 226 Clearly, this approach is recursive and can be carried through 227 several iterations. Routing domains at any `level' in the hierarchy 228 may use their prefix as the basis for subsequent suballocations, 229 assuming that the IP addresses remain within the overall length and 230 structure constraints. 232 At this point, we observe that the number of nodes at each lower 233 level of a hierarchy tends to grow exponentially. Thus the greatest 234 gains in the reachability information abstraction occur at the leaves 235 and the gains drop significantly at each higher level. Therefore, the 236 law of diminishing returns suggests that at some point data 237 abstraction ceases to produce significant benefits. Determination of 238 the point at which data abstraction ceases to be of benefit requires 239 a careful consideration of the number of routing domains that are 240 expected to occur at each level of the hierarchy (over a given period 241 of time), compared to the number of routing domains and address 242 prefixes that can conveniently and efficiently be handled via dynamic 243 inter-domain routing protocols. 245 4.1 Efficiency versus Decentralized Control. 247 There is a balance that must be sought between the requirements on IP 248 addresses for efficient routing and the need for decentralized 249 address administration. A proposal described in section 6.3 offers an 250 example of how these two needs might be met. 252 The IP address prefix <216.0.0.0 248.0.0.0> provides for 253 administrative decentralization. This prefix identifies the address 254 allocation authority for North America. The lower order part of that 255 prefix allows allocation of IP addresses along topological boundaries 256 in support of increased data abstraction. Regionals within North 257 America assign IP address prefixes for their clients underneath their 258 unique address prefixes. Within a routing domain addresses for 259 subnetworks and hosts are allocated from the unique IP prefix 260 assigned to the domain. 262 5 IP Address Administration and Routing in the Internet 264 Internet routing components---service providers (e.g. backbones, 265 regional networks), and service subscribers (e.g. sites or campuses- 266 --are arranged hierarchically for the most part. A natural mapping 267 from these components to IP routing components is that providers and 268 subscribers act as routing domains. 270 RFC DRAFT September 1992 272 Alternatively, a subscriber (e.g. a site) may choose to operate as a 273 part of a domain formed by a service provider. We assume that some, 274 if not most, sites will prefer to operate as part of their provider's 275 routing domain. Such sites can exchange routing information with 276 their provider via interior routing protocol route leaking or via an 277 exterior routing protocol. For the purposes of this discussion, the 278 choice is not significant. The site is still allocated a prefix from 279 the provider's address space, and the provider will advertise its own 280 prefix into inter-domain routing. 282 Given such a mapping, where should address administration and 283 allocation be performed to satisfy both administrative 284 decentralization and data abstraction? Three possibilities are 285 considered: 287 at some part within a routing domain, at the leaf routing domain, 288 and, at the transit routing domain (TRD). 290 A part within a routing domain corresponds to a subnetwork. If a 291 domain is composed of multiple subnetworks, they are interconnected 292 via routers. Leaf routing domains correspond to sites, where the 293 primary purpose is to provide intra-domain routing services. Transit 294 routing domains are deployed to carry transit (i.e., inter-domain) 295 traffic; backbones and providers are TRDs. 297 The greatest burden in transmitting and operating on routing 298 information is at the top of the routing hierarchy, where routing 299 information tends to accumulate. In the Internet, for example, 300 providers must manage the set of network numbers for all networks 301 reachable through the provider. Traffic destined for other providers 302 is generally routed to the backbones (which act as providers as 303 well). The backbones, however, must be cognizant of the network 304 numbers for all attached providers and their associated networks. 306 In general, the advantage of abstracting routing information at a 307 given level of the routing hierarchy is greater at the higher levels 308 of the hierarchy. There is relatively little direct benefit to the 309 administration that performs the abstraction, since it must maintain 310 routing information individually on each attached topological routing 311 structure. 313 For example, suppose that a given site is trying to decide whether to 314 obtain an IP address prefix directly from the North America address 315 allocation authority, or from its service provider. If considering 316 only their own self-interest, the site itself and the attached 317 provider have little reason to choose one approach or the other. The 318 site must use one prefix or another; the source of the prefix has 319 little effect on routing efficiency within the site. The provider 320 must maintain information about each attached site in order to route, 321 regardless of any commonality in the prefixes of the sites. 323 However, there is a difference when the provider distributes routing 324 information to other providers (e.g. backbones or TRDs). In the 325 first case, the provider cannot aggregate the site's address into its 327 RFC DRAFT September 1992 329 own prefix; the address must be explicitly listed in routing 330 exchanges, resulting in an additional burden to other providers which 331 must exchange and maintain this information. 333 In the second case, each other provider (e.g. backbone or TRD) sees a 334 single address prefix for the provider, which encompasses the new 335 site. This avoids the exchange of additional routing information to 336 identify the new site's address prefix. Thus, the advantages 337 primarily accrue to other providers which maintain routing 338 information about this site and provider. 340 One might apply a supplier/consumer model to this problem: the higher 341 level (e.g., a backbone) is a supplier of routing services, while the 342 lower level (e.g., a TRD) is the consumer of these services. The 343 price charged for services is based upon the cost of providing them. 344 The overhead of managing a large table of addresses for routing to an 345 attached topological entity contributes to this cost. 347 The Internet, however, is not a market economy. Rather, efficient 348 operation is based on cooperation. The guidelines discussed below 349 describe reasonable ways of managing the IP address space that 350 benefit the entire community. 352 5.1 Administration of IP addresses within a domain. 354 If individual subnetworks take their IP addresses from a myriad of 355 unrelated IP allocation authorities, there will be effectively no 356 data abstraction beyond what is built into existing intra-domain 357 routing protocols. For example, assume that within a routing domain 358 uses three independent prefixes assigned from three different 359 attached providers. 361 This does have a negative effect on inter-domain routing, 362 particularly on those other domains which need to maintain routes to 363 this domain. There is no common prefix that can be used to represent 364 these IP addresses and therefore no summarization can take place at 365 the routing domain boundary. When addresses are advertised by this 366 routing domain to other routing domains, an enumerated list must be 367 used consisting of the three network addresses. 369 This situation is roughly analogous to the present dissemination of 370 routing information in the Internet, where each domain may have non- 371 contiguous network numbers assigned to it. The result of allowing 372 subnetworks within a routing domain to take their IP addresses from 373 unrelated authorities is flat routing at the A/B/C class network 374 level. The number of IP prefixes that leaf routing domains would 375 advertise is on the order of the number of attached network numbers; 376 the number of prefixes a provider's routing domain would advertise is 377 approximately the number of network numbers attached to the client 378 leaf routing domains; and for a backbone this would be summed across 379 all attached providers. Although this situation is just barely 380 acceptable in the current Internet, as the Internet grows this will 382 RFC DRAFT September 1992 384 quickly become intractable. A greater degree of hierarchical 385 information reduction is necessary to allow continued growth in the 386 Internet. 388 5.2 Administration at the Leaf Routing Domain 390 As mentioned previously, the greatest degree of data abstraction 391 comes at the lowest levels of the hierarchy. Providing each leaf 392 routing domain (that is, site) with a prefix from its provider's 393 prefix results in the biggest single increase in abstraction. From 394 outside the leaf routing domain, the set of all addresses reachable 395 in the domain can then be represented by a single prefix. Further, 396 all destinations reachable within the provider's prefix can be 397 represented by a single prefix. 399 For example, consider a single campus which is a leaf routing domain 400 which would currently require 4 different IP networks. Under the new 401 allocation scheme, they might instead be given a single prefix which 402 provides the same number of destination addresses. Further, since 403 the prefix is a subset of the provider's prefix, they impose no 404 additional burden on the higher levels of the routing hierarchy. 406 There is a close relationship between subnetworks and routing domains 407 implicit in the fact that they operate a common routing protocol and 408 are under the control of a single administration. The routing domain 409 administration subdivides the domain into subnetworks. The routing 410 domain represents the only path between a subnetwork and the rest of 411 the internetwork. It is reasonable that this relationship also extend 412 to include a common IP addressing authority. Thus, the subnetworks 413 within the leaf RD should take their IP addresses from the prefix 414 assigned to the leaf RD. 416 5.3 Administration at the Transit Routing Domain 418 Two kinds of transit routing domains are considered, direct providers 419 and indirect providers. Most of the subscribers of a direct provider 420 are domains that act solely as service subscribers (they carry no 421 transit traffic). Most of the subscribers of an indirect provider are 422 domains that, themselves, act as service providers. In present 423 terminology a backbone is an indirect provider, while a TRD is a 424 direct provider. Each case is discussed separately below. 426 5.3.1 Direct Service Providers 428 It is interesting to consider whether direct service providers' 429 routing domains should be the common authority for assigning IP 430 addresses from a unique prefix to the leaf routing domains that they 431 serve. The benefits derived from data abstraction are greater than in 433 RFC DRAFT September 1992 435 the case of leaf routing domains, and the additional degree of data 436 abstraction provided by this may be necessary in the short term. 438 As an illustration consider an example of a direct provider that 439 serves 100 clients. If each client takes its addresses from 4 440 independent address assignment authorities then the total number of 441 entries that are needed to handle routing to these clients is 100 442 clients times 4 providers = 400. If each client takes its addresses 443 from a single address assignment authority then the total number of 444 entries would be only 100. Finally, if all the clients take their 445 addresses from the same address assignment authority then the total 446 number of entries would be only 1. 448 We expect that in the near term the number of routing domains in the 449 Internet will grow to the point that it will be infeasible to route 450 on the basis of a flat field of routing domains. It will therefore be 451 essential to provide a greater degree of information abstraction. 453 Direct providers may assign prefixes to leaf domains, based on a 454 single (shorter length) address prefix assigned to the provider. For 455 example, following the proposal suggested in section 6.3, a direct 456 provider may act as an address assignment authority and routing 457 domain values may be assigned by the direct provider to each attached 458 leaf routing domain. This results in direct providers advertising to 459 backbones a small fraction of the number of address prefixes that 460 would be necessary if they enumerated the individual prefixes of the 461 leaf routing domains. This represents a significant savings given 462 the expected scale of global internetworking. 464 Are leaf routing domains willing to accept prefixes derived from the 465 direct providers? In the supplier/consumer model, the direct provider 466 is offering connectivity as the service, priced according to its 467 costs of operation. This includes the `price' of obtaining service 468 from one or more indirect providers (e.g. backbones). In general, 469 indirect providers will want to handle as few address prefixes as 470 possible to keep costs low. In the Internet environment, which does 471 not operate as a typical marketplace, leaf routing domains must be 472 sensitive to the resource constraints of the providers (both direct 473 and indirect). The efficiencies gained in routing clearly warrant the 474 adoption of IP address administration by the providers. 476 The mechanics of this scenario are straightforward. Each direct 477 provider is assigned a unique small set of IP address prefixes, from 478 which it allocates slightly longer routing domain prefixes for its 479 attached leaf routing domains. For example assume that NIST is a 480 leaf routing domain whose sole inter-domain link is via SURANet. If 481 SURANet is assigned an unique IP address prefix <193.1.0.0 482 255.255.0.0>, NIST could be assigned a unique IP prefix of <193.1.0.0 483 255.255.240.0>. 485 RFC DRAFT September 1992 487 5.3.2 Indirect Providers (Backbones) 489 There does not appear to be a strong case for direct providers to 490 take their address spaces from the the IP space of an indirect 491 provider (e.g. backbone). The benefit in routing data abstraction is 492 relatively small. The number of direct providers today is in the tens 493 and an order of magnitude increase would not cause an undue burden on 494 the backbones. Also, it may be expected that as time goes by there 495 will be increased direct interconnection of the direct providers, 496 leaf routing domains directly attached to the backbones, and 497 international links directly attached to the providers. Under these 498 circumstances, the distinction between direct and indirect providers 499 may become blurred. 501 An additional factor that discourages allocation of IP addresses from 502 a backbone prefix is that the backbones and their attached providers 503 are perceived as being independent. providers may take their long- 504 haul service from one or more backbones, or may switch backbones 505 should a more cost-effective service be provided elsewhere. Having IP 506 addresses derived from a backbone is inconsistent with the nature of 507 the relationship. 509 5.3.3 Continental aggregation 511 Another level of hierarchy may also be used in this addressing scheme 512 to further reduce the amount of routing information necessary for 513 inter-continental routing. Continental aggregation is useful because 514 continental boundaries provide natural barriers to topological 515 connection and administrative boundaries. Thus, it presents a 516 natural boundary for another level of aggregation. To make use of 517 this, it is necessary that each continent be assigned an addressing 518 authority and an appropriate subset of the address space. Providers 519 (both direct and indirect) within that continent would allocate their 520 addresses from this space. Note that there are numerous exceptions 521 to this, in which a service provider (either direct or indirect) 522 spans a continental division. These exceptions can be handled 523 similarly to multi-home routing domains, as discussed below. 525 Note that, in contrast to the case of providers, the aggregation of 526 continental routing information may not be done on the continent 527 which `owns' the prefix. The cost of inter-continental links (and 528 especially trans-oceanic links) is very high. If aggregation is 529 performed on the `near' side of the link, then routing information 530 about unreachable destinations within that continent can only reside 531 on that continent. Alternatively, if continental aggregation is done 532 on the `far' side of an inter-continental link, the `far' end can 533 perform the aggregation and inject it into continental routing. This 534 means that destinations which are part of the continental 535 aggregation, but for which there is not a corresponding more specific 536 prefix can be rejected before leaving the continent on which they 537 originated. 539 RFC DRAFT September 1992 541 For example, suppose that Europe is assigned a prefix of <193.0.0.0 542 255.0.0.0>, and that European routing also contains the longer 543 prefixes <193.1.0.0 255.255.0.0> and <193.2.0.0 255.255.0.0>. All of 544 the longer European prefixes may be advertised across a trans- 545 Atlantic link to North America. The router in North America would 546 then aggregate these routes, and only advertise the prefix <193.0.0.0 547 255.0.0.0> into North American routing. Packets which are destined 548 for 193.1.1.1 would traverse North American routing, but would 549 encounter the North American router which performed the European 550 aggregation. If the prefix <193.1.0.0 255.255.0.0> is unreachable, 551 the router would drop the packet and send an ICMP Unreachable without 552 using the trans-Atlantic link. 554 5.4 Multi-homed Routing Domains 556 The discussions in Section 5.3 suggest methods for allocating IP 557 addresses based on direct or indirect provider connectivity. This 558 allows a great deal of information reduction to be achieved for those 559 routing domains which are attached to a single TRD. In particular, 560 such routing domains may select their IP addresses from a space 561 allocated to them by the direct provider. This allows the provider, 562 when announcing the addresses that it can reach to other providers, 563 to use a single address prefix to describe a large number of IP 564 addresses corresponding to multiple routing domains. 566 However, there are additional considerations for routing domains 567 which are attached to multiple providers. Such `multi-homed' routing 568 domains may, for example, consist of single-site campuses and 569 companies which are attached to multiple backbones, large 570 organizations which are attached to different providers at different 571 locations in the same country, or multi-national organizations which 572 are attached to backbones in a variety of countries worldwide. There 573 are a number of possible ways to deal with these multi-homed routing 574 domains. 576 One possible solution is to assign addresses to each multi-homed 577 organization independently from the providers to which it is 578 attached. This allows each multi-homed organization to base its IP 579 assignments on a single prefix, and to thereby summarize the set of 580 all IP addresses reachable within that organization via a single 581 prefix. The disadvantage of this approach is that since the IP 582 address for that organization has no relationship to the addresses of 583 any particular TRD, the TRDs to which this organization is attached 584 will need to advertise the prefix for this organization to other 585 providers. Other providers (potentially worldwide) will need to 586 maintain an explicit entry for that organization in their routing 587 tables. 589 For example, suppose that a very large North American company `Mega 590 Big International Incorporated' (MBII) has a fully interconnected 591 internal network and is assigned a single prefix as part of the North 592 American prefix. It is likely that outside of North America, a 594 RFC DRAFT September 1992 596 single entry may be maintained in routing tables for all North 597 American Destinations. However, within North America, every provider 598 will need to maintain a separate address entry for MBII. If MBII is 599 in fact an international corporation, then it may be necessary for 600 every provider worldwide to maintain a separate entry for MBII 601 (including backbones to which MBII is not attached). Clearly this may 602 be acceptable if there are a small number of such multi-homed routing 603 domains, but would place an unacceptable load on routers within 604 backbones if all organizations were to choose such address 605 assignments. This solution may not scale to internets where there 606 are many hundreds of thousands of multi-homed organizations. 608 A second possible approach would be for multi-homed organizations to 609 be assigned a separate IP address space for each connection to a TRD, 610 and to assign a single prefix to some subset of its domain(s) based 611 on the closest interconnection point. For example, if MBII had 612 connections to two providers in the U.S. (one east coast, and one 613 west coast), as well as three connections to national backbones in 614 Europe, and one in the far east, then MBII may make use of six 615 different address prefixes. Each part of MBII would be assigned a 616 single address prefix based on the nearest connection. 618 For purposes of external routing of traffic from outside MBII to a 619 destination inside of MBII, this approach works similarly to treating 620 MBII as six separate organizations. For purposes of internal routing, 621 or for routing traffic from inside of MBII to a destination outside 622 of MBII, this approach works the same as the first solution. 624 If we assume that incoming traffic (coming from outside of MBII, with 625 a destination within MBII) is always to enter via the nearest point 626 to the destination, then each TRD which has a connection to MBII 627 needs to announce to other TRDs the ability to reach only those parts 628 of MBII whose address is taken from its own address space. This 629 implies that no additional routing information needs to be exchanged 630 between TRDs, resulting in a smaller load on the inter-domain routing 631 tables maintained by TRDs when compared to the first solution. This 632 solution therefore scales better to extremely large internets 633 containing very large numbers of multi-homed organizations. 635 One problem with the second solution is that backup routes to multi- 636 homed organizations are not automatically maintained. With the first 637 solution, each TRD, in announcing the ability to reach MBII, 638 specifies that it is able to reach all of the hosts within MBII. With 639 the second solution, each TRD announces that it can reach all of the 640 hosts based on its own address prefix, which only includes some of 641 the hosts within MBII. If the connection between MBII and one 642 particular TRD were severed, then the hosts within MBII with 643 addresses based on that TRD would become unreachable via inter-domain 644 routing. The impact of this problem can be reduced somewhat by 645 maintenance of additional information within routing tables, but this 646 reduces the scaling advantage of the second approach. 648 The second solution also requires that when external connectivity 649 changes, internal addresses also change. 651 RFC DRAFT September 1992 653 Also note that this and the previous approach will tend to cause 654 packets to take different routes. With the first approach, packets 655 from outside of MBII destined for within MBII will tend to enter via 656 the point which is closest to the source (which will therefore tend 657 to maximize the load on the networks internal to MBII). With the 658 second solution, packets from outside destined for within MBII will 659 tend to enter via the point which is closest to the destination 660 (which will tend to minimize the load on the networks within MBII, 661 and maximize the load on the TRDs). 663 These solutions also have different effects on policies. For example, 664 suppose that country `X' has a law that traffic from a source within 665 country X to a destination within country X must at all times stay 666 entirely within the country. With the first solution, it is not 667 possible to determine from the destination address whether or not the 668 destination is within the country. With the second solution, a 669 separate address may be assigned to those hosts which are within 670 country X, thereby allowing routing policies to be followed. 671 Similarly, suppose that `Little Small Company' (LSC) has a policy 672 that its packets may never be sent to a destination that is within 673 MBII. With either solution, the routers within LSC may be configured 674 to discard any traffic that has a destination within MBII's address 675 space. However, with the first solution this requires one entry; with 676 the second it requires many entries and may be impossible as a 677 practical matter. 679 There are other possible solutions as well. A third approach is to 680 assign each multi-homed organization a single address prefix, based 681 on one of its connections to a TRD. Other TRDs to which the multi- 682 homed organization are attached maintain a routing table entry for 683 the organization, but are extremely selective in terms of which other 684 TRDs are told of this route. This approach will produce a single 685 `default' routing entry which all TRDs will know how to reach (since 686 presumably all TRDs will maintain routes to each other), while 687 providing more direct routing in some cases. 689 There is at least one situation in which this third approach is 690 particularly appropriate. Suppose that a special interest group of 691 organizations have deployed their own backbone. For example, lets 692 suppose that the U.S. National Widget Manufacturers and Researchers 693 have set up a U.S.-wide backbone, which is used by corporations who 694 manufacture widgets, and certain universities which are known for 695 their widget research efforts. We can expect that the various 696 organizations which are in the widget group will run their internal 697 networks as separate routing domains, and most of them will also be 698 attached to other TRDs (since most of the organizations involved in 699 widget manufacture and research will also be involved in other 700 activities). We can therefore expect that many or most of the 701 organizations in the widget group are dual-homed, with one attachment 702 for widget-associated communications and the other attachment for 703 other types of communications. Let's also assume that the total 704 number of organizations involved in the widget group is small enough 705 that it is reasonable to maintain a routing table containing one 706 entry per organization, but that they are distributed throughout a 708 RFC DRAFT September 1992 710 larger internet with many millions of (mostly not widget-associated) 711 routing domains. 713 With the third approach, each multi-homed organization in the widget 714 group would make use of an address assignment based on its other 715 attachment(s) to TRDs (the attachments not associated with the widget 716 group). The widget backbone would need to maintain routes to the 717 routing domains associated with the various member organizations. 718 Similarly, all members of the widget group would need to maintain a 719 table of routes to the other members via the widget backbone. 720 However, since the widget backbone does not inform other general 721 worldwide TRDs of what addresses it can reach (since the backbone is 722 not intended for use by other outside organizations), the relatively 723 large set of routing prefixes needs to be maintained only in a 724 limited number of places. The addresses assigned to the various 725 organizations which are members of the widget group would provide a 726 `default route' via each members other attachments to TRDs, while 727 allowing communications within the widget group to use the preferred 728 path. 730 A fourth solution involves assignment of a particular address prefix 731 for routing domains which are attached to precisely two (or more) 732 specific routing domains. For example, suppose that there are two 733 providers `SouthNorthNet' and `NorthSouthNet' which have a very large 734 number of customers in common (i.e., there are a large number of 735 routing domains which are attached to both). Rather than getting two 736 address prefixes these organizations could obtain three prefixes. 737 Those routing domains which are attached to NorthSouthNet but not 738 attached to SouthNorthNet obtain an address assignment based on one 739 of the prefixes. Those routing domains which are attached to 740 SouthNorthNet but not to NorthSouthNet would obtain an address based 741 on the second prefix. Finally, those routing domains which are 742 multi-homed to both of these networks would obtain an address based 743 on the third prefix. Each of these two TRDs would then advertise two 744 prefixes to other TRDs, one prefix for leaf routing domains attached 745 to it only, and one prefix for leaf routing domains attached to both. 747 This fourth solution is likely to be important when use of public 748 data networks becomes more common. In particular, it is likely that 749 at some point in the future a substantial percentage of all routing 750 domains will be attached to public data networks. In this case, 751 nearly all government-sponsored networks (such as some current NSFNET 752 regionals) may have a set of customers which overlaps substantially 753 with the public networks. 755 There are therefore a number of possible solutions to the problem of 756 assigning IP addresses to multi-homed routing domains. Each of these 757 solutions has very different advantages and disadvantages. Each 758 solution places a different real (i.e., financial) cost on the 759 multi-homed organizations, and on the TRDs (including those to which 760 the multi-homed organizations are not attached). 762 In addition, most of the solutions described also highlight the need 763 for each TRD to develop policy on whether and under what conditions 765 RFC DRAFT September 1992 767 to accept addresses that are not based on its own address prefix, and 768 how such non-local addresses will be treated. For example, a somewhat 769 conservative policy might be that non-local IP address prefixes will 770 be accepted from any attached leaf RD, but not advertised to other 771 TRDs. In a less conservative policy, a TRD might accept such non- 772 local prefixes and agree to exchange them with a defined set of other 773 TRDs (this set could be an a priori group of TRDs that have something 774 in common such as geographical location, or the result of an 775 agreement specific to the requesting leaf RD). Various policies 776 involve real costs to TRDs, which may be reflected in those policies. 778 5.5 Private Links 780 The discussion up to this point concentrates on the relationship 781 between IP addresses and routing between various routing domains over 782 transit routing domains, where each transit routing domain 783 interconnects a large number of routing domains and offers a more- 784 or-less public service. 786 However, there may also exist a large number of private point-to- 787 point links which interconnect two private routing domains. In many 788 cases such private point-to-point links may be limited to forwarding 789 packets directly between the two private routing domains. 791 For example, let's suppose that the XYZ corporation does a lot of 792 business with MBII. In this case, XYZ and MBII may contract with a 793 carrier to provide a private link between the two corporations, where 794 this link may only be used for packets whose source is within one of 795 the two corporations, and whose destination is within the other of 796 the two corporations. Finally, suppose that the point-to-point link 797 is connected between a single router (router X) within XYZ 798 corporation and a single router (router M) within MBII. It is 799 therefore necessary to configure router X to know which addresses can 800 be reached over this link (specifically, all addresses reachable in 801 MBII). Similarly, it is necessary to configure router M to know which 802 addresses can be reached over this link (specifically, all addresses 803 reachable in XYZ Corporation). 805 The important observation to be made here is that such private links 806 may be ignored for the purpose of IP address allocation, and do not 807 pose a problem for routing. This is because the routing information 808 associated with private links is not propagated throughout the 809 internet, and therefore does not need to be collapsed into a TRD's 810 prefix. 812 In our example, let's suppose that the XYZ corporation has a single 813 connection to an NSFNET regional, and has therefore received an 814 address allocation from the space administered by that regional. 815 Similarly, let's suppose that MBII, as an international corporation 816 with connections to six different providers, has chosen the second 817 solution from Section 5.4, and therefore has obtained six different 818 address allocations. In this case, all addresses reachable in the XYZ 820 RFC DRAFT September 1992 822 Corporation can be described by a single address prefix (implying 823 that router M only needs to be configured with a single address 824 prefix to represent the addresses reachable over this point-to-point 825 link). All addresses reachable in MBII can be described by six 826 address prefixes (implying that router X needs to be configured with 827 six address prefixes to represent the addresses reachable over the 828 point-to-point link). 830 In some cases, such private point-to-point links may be permitted to 831 forward traffic for a small number of other routing domains, such as 832 closely affiliated organizations. This will increase the 833 configuration requirements slightly. However, provided that the 834 number of organizations using the link is relatively small, then this 835 still does not represent a significant problem. 837 Note that the relationship between routing and IP addressing 838 described in other sections of this paper is concerned with problems 839 in scaling caused by large, essentially public transit routing 840 domains which interconnect a large number of routing domains. 841 However, for the purpose of IP address allocation, private point-to- 842 point links which interconnect only a small number of private routing 843 domains do not pose a problem, and may be ignored. For example, this 844 implies that a single leaf routing domain which has a single 845 connection to a `public' backbone (e.g., the NSFNET), plus a number 846 of private point-to-point links to other leaf routing domains, can be 847 treated as if it were single-homed to the backbone for the purpose of 848 IP address allocation. We expect that this is also another way of 849 dealing with multi-homed domains. 851 5.6 Zero-Homed Routing Domains 853 Currently, a very large number of organizations have internal 854 communications networks which are not connected to any external 855 network. Such organizations may, however, have a number of private 856 point-to-point links that they use for communications with other 857 organizations. Such organizations do not participate in global 858 routing, but are satisfied with reachability to those organizations 859 with which they have established private links. These are referred to 860 as zero-homed routing domains. 862 Zero-homed routing domains can be considered as the degenerate case 863 of routing domains with private links, as discussed in the previous 864 section, and do not pose a problem for inter-domain routing. As 865 above, the routing information exchanged across the private links 866 sees very limited distribution, usually only to the RD at the other 867 end of the link. Thus, there are no address abstraction requirements 868 beyond those inherent in the address prefixes exchanged across the 869 private link. 871 However, it is important that zero-homed routing domains use valid 872 globally unique IP addresses. Suppose that the zero-homed routing 873 domain is connected through a private link to an RD. Further, this RD 875 RFC DRAFT September 1992 877 participates in an internet that subscribes to the global IP 878 addressing plan. This RD must be able to distinguish between the 879 zero-homed routing domain's IP addresses and any other IP addresses 880 that it may need to route to. The only way this can be guaranteed is 881 if the zero-homed routing domain uses globally unique IP addresses. 883 5.7 Transition Issues 885 Allocation of IP addresses based on connectivity to TRDs is important 886 to allow scaling of inter-domain routing to an internet containing 887 millions of routing domains. However, such address allocation based 888 on topology also implies that a change in topology may result in a 889 change of address. 891 Note that an address change need not happen immediately. A domain 892 which has changed service providers may still advertise its prefix 893 through its new service provider. Since upper levels in the routing 894 hierarchy will perform routing based on the longest prefix, 895 reachability is preserved, although the aggregation and scalability 896 of the routing information has greatly diminished. Thus, a domain 897 which does change its topology should change addresses as soon as 898 convenient. The timing and mechanics of such changes must be the 899 result of a multilateral agreement between the old service provider, 900 the new provider, and the domain. 902 This need to allow for change in addresses is a natural, inevitable 903 consequence of routing data abstraction. The basic notion of routing 904 data abstraction is that there is some correspondence between the 905 address and where a system (i.e., a routing domain, subnetwork, or 906 end system) is located. Thus if the system moves, in some cases the 907 address will have to change. If it were possible to change the 908 connectivity between routing domains without changing the addresses, 909 then it would clearly be necessary to keep track of the location of 910 that routing domain on an individual basis. 912 In the short term, due to the rapid growth and increased 913 commercialization of the Internet, it is possible that the topology 914 may be relatively volatile. This implies that planning for address 915 transition is very important. Fortunately, there are a number of 916 steps which can be taken to help ease the effort required for address 917 transition. A complete description of address transition issues is 918 outside of the scope of this paper. However, a very brief outline of 919 some transition issues is contained in this section. 921 Also note that the possible requirement to transition addresses based 922 on changes in topology imply that it is valuable to anticipate the 923 future topology changes before finalizing a plan for address 924 allocation. For example, in the case of a routing domain which is 925 initially single-homed, but which is expecting to become multi-homed 926 in the future, it may be advantageous to assign IP addresses based on 927 the anticipated future topology. 929 RFC DRAFT September 1992 931 In general, it will not be practical to transition the IP addresses 932 assigned to a routing domain in an instantaneous `change the address 933 at midnight' manner. Instead, a gradual transition is required in 934 which both the old and the new addresses will remain valid for a 935 limited period of time. During the transition period, both the old 936 and new addresses are accepted by the end systems in the routing 937 domain, and both old and new addresses must result in correct routing 938 of packets to the destination. 940 During the transition period, it is important that packets using the 941 old address be forwarded correctly, even when the topology has 942 changed. This is facilitated by the use of `longest match' inter- 943 domain routing. 945 For example, suppose that the XYZ Corporation was previously 946 connected only to the NorthSouthNet NSFNET regional. The XYZ 947 Corporation therefore went off to the NorthSouthNet administration 948 and got an IP address prefix assignment based on the IP address 949 prefix value assigned to the NorthSouthNet regional. However, for a 950 variety of reasons, the XYZ Corporation decided to terminate its 951 association with the NorthSouthNet, and instead connect directly to 952 the NewCommercialNet public data network. Thus the XYZ Corporation 953 now has a new address assignment under the IP address prefix assigned 954 to the NewCommercialNet. The old address for the XYZ Corporation 955 would seem to imply that traffic for the XYZ Corporation should be 956 routed to the NorthSouthNet, which no longer has any direct 957 connection with XYZ Corporation. 959 If the old TRD (NorthSouthNet) and the new TRD (NewCommercialNet) are 960 adjacent and cooperative, then this transition is easy to accomplish. 961 In this case, packets routed to the XYZ Corporation using the old 962 address assignment could be routed to the NorthSouthNet, which would 963 directly forward them to the NewCommercialNet, which would in turn 964 forward them to XYZ Corporation. In this case only NorthSouthNet and 965 NewCommercialNet need be aware of the fact that the old address 966 refers to a destination which is no longer directly attached to 967 NorthSouthNet. 969 If the old TRD and the new TRD are not adjacent, then the situation 970 is a bit more complex, but there are still several possible ways to 971 forward traffic correctly. 973 If the old TRD and the new TRD are themselves connected by other 974 cooperative transit routing domains, then these intermediate domains 975 may agree to forward traffic for XYZ correctly. For example, suppose 976 that NorthSouthNet and NewCommercialNet are not directly connected, 977 but that they are both directly connected to the NSFNET backbone. In 978 this case, all three of NorthSouthNet, NewCommercialNet, and the 979 NSFNET backbone would need to maintain a special entry for XYZ 980 corporation so that traffic to XYZ using the old address allocation 981 would be forwarded via NewCommercialNet. However, other routing 982 domains would not need to be aware of the new location for XYZ 983 Corporation. 985 RFC DRAFT September 1992 987 Suppose that the old TRD and the new TRD are separated by a non- 988 cooperative routing domain, or by a long path of routing domains. In 989 this case, the old TRD could encapsulate traffic to XYZ Corporation 990 in order to deliver such packets to the correct backbone. 992 Also, those locations which do a significant amount of business with 993 XYZ Corporation could have a specific entry in their routing tables 994 added to ensure optimal routing of packets to XYZ. For example, 995 suppose that another commercial backbone ``OldCommercialNet'' has a 996 large number of customers which exchange traffic with XYZ 997 Corporation, and that this third TRD is directly connected to both 998 NorthSouthNet and NewCommercialNet. In this case OldCommercialNet 999 will continue to have a single entry in its routing tables for other 1000 traffic destined for NorthSouthNet, but may choose to add one 1001 additional (more specific) entry to ensure that packets sent to XYZ 1002 Corporation's old address are routed correctly. 1004 Whichever method is used to ease address transition, the goal is that 1005 knowledge relating XYZ to its old address that is held throughout the 1006 global internet would eventually be replaced with the new 1007 information. It is reasonable to expect this to take weeks or months 1008 and will be accomplished through the distributed directory system. 1009 Discussion of the directory, along with other address transition 1010 techniques such as automatically informing the source of a changed 1011 address, are outside the scope of this paper. 1013 Another significant transition difficulty is the establishment of 1014 appropriate addressing authorities. In order not to delay the 1015 deployment of this addressing scheme, if no authority has been 1016 created at an appropriate level, a higher level authority may 1017 allocated addresses instead of the lower level authority. For 1018 example, suppose that the continental authority has been allocated a 1019 portion of the address space and that the service providers present 1020 on that continent are clear, but have not yet established their 1021 addressing authority. The continental authority may foresee 1022 (possibly with information from the provider) that the provider will 1023 eventually create an authority. The continental authority may then 1024 act on behalf of that provider until the provider is prepared to 1025 assume its addressing authority duties. 1027 5.8 Interaction with Policy Routing 1029 We assume that any inter-domain routing protocol will have difficulty 1030 trying to aggregate multiple destinations with dissimilar policies. 1031 At the same time, the ability to aggregate routing information while 1032 not violating routing policies is essential. Therefore, we suggest 1033 that address allocation authorities attempt to allocate addresses so 1034 that aggregates of destinations with similar policies can be easily 1035 formed. 1037 RFC DRAFT September 1992 1039 6 Recommendations 1041 We anticipate that the current exponential growth of the Internet 1042 will continue or accelerate for the foreseeable future. In addition, 1043 we anticipate a rapid internationalization of the Internet. The 1044 ability of routing to scale is dependent upon the use of data 1045 abstraction based on hierarchical IP addresses. As CIDR [1] is 1046 introduced in the Internet, it is therefore essential to choose a 1047 hierarchical structure for IP addresses with great care. 1049 It is in the best interests of the internetworking community that the 1050 cost of operations be kept to a minimum where possible. In the case 1051 of IP address allocation, this again means that routing data 1052 abstraction must be encouraged. 1054 In order for data abstraction to be possible, the assignment of IP 1055 addresses must be accomplished in a manner which is consistent with 1056 the actual physical topology of the Internet. For example, in those 1057 cases where organizational and administrative boundaries are not 1058 related to actual network topology, address assignment based on such 1059 organization boundaries is not recommended. 1061 The intra-domain routing protocols allow for information abstraction 1062 to be maintained within a domain. For zero-homed and single-homed 1063 routing domains (which are expected to remain zero-homed or single- 1064 homed), we recommend that the IP addresses assigned within a single 1065 routing domain use a single address prefix assigned to that domain. 1066 Specifically, this allows the set of all IP addresses reachable 1067 within a single domain to be fully described via a single prefix. 1069 We anticipate that the total number of routing domains existing on a 1070 worldwide Internet to be great enough that additional levels of 1071 hierarchical data abstraction beyond the routing domain level will be 1072 necessary. 1074 In most cases, network topology will have a close relationship with 1075 national boundaries. For example, the degree of network connectivity 1076 will often be greater within a single country than between countries. 1077 It is therefore appropriate to make specific recommendations based on 1078 national boundaries, with the understanding that there may be 1079 specific situations where these general recommendations need to be 1080 modified. 1082 6.1 Recommendations for an address allocation plan 1084 We anticipate that public interconnectivity between private routing 1085 domains will be provided by a diverse set of TRDs, including (but not 1086 necessarily limited to): 1088 backbone networks (NSFNET, ANSnet, CIX, PSI, SprintLink, Ebone); a 1090 RFC DRAFT September 1992 1092 number of regional or national networks; and, a number of commercial 1093 Public Data Networks. 1095 It is also expected that these networks will not be interconnected in 1096 a strictly hierarchical manner (for example, there is expected to be 1097 direct connectivity between NSFNET regionals, and all four of these 1098 types of networks may have direct international connections). 1099 However, the total number of such TRDs is expected to remain (for the 1100 foreseeable future) small enough to allow addressing of this set of 1101 TRDs via a flat address space. These TRDs will be used to 1102 interconnect a wide variety of routing domains, each of which may 1103 comprise a single corporation, part of a corporation, a university 1104 campus, a government agency, or other organizational unit. 1106 In addition, some private corporations may be expected to make use of 1107 dedicated private TRDs for communication within their own 1108 corporation. 1110 We anticipate that the great majority of routing domains will be 1111 attached to only one of the TRDs. This will permit hierarchical 1112 address aggregation based on TRD. We therefore strongly recommend 1113 that addresses be assigned hierarchically, based on address prefixes 1114 assigned to individual TRDs. 1116 To support continental aggregation of routes, we recommend that all 1117 addresses for TRDs which are wholly within a continent be taken from 1118 the continental prefix. 1120 For the proposed address allocation scheme, this implies that 1121 administrative authority for some prefix should be assigned to all 1122 TRDs (explicitly including the backbones and NSFNET regionals). For 1123 those leaf routing domains which are connected to a single TRD, they 1124 should be assigned a prefix value from the address space assigned to 1125 that TRD. 1127 We recommend that all TRDs explicitly be involved in the task of 1128 address administration for those leaf routing domains which are 1129 single-homed to them. This will offer a valuable service to their 1130 customers, and will also greatly reduce the resources (including 1131 human and network resources) necessary for that TRD to take part in 1132 inter-domain routing. 1134 Each TRD should develop policy on whether and under what conditions 1135 to accept addresses that are not based on its own address prefix, and 1136 how such non-local addresses will be treated. Policies should reflect 1137 the issue of cost associated with implementing such policies. 1139 For routing domains which are not attached to any publically 1140 available TRD, there is not the same urgent need for hierarchical 1141 address abbreviation. We do not, therefore, make any additional 1142 recommendations for such `isolated' routing domains. Where such 1143 domains are connected to other domains by private point-to-point 1144 links, and where such links are used solely for routing between the 1145 two domains that they interconnect, again no additional technical 1147 RFC DRAFT September 1992 1149 problems relating to address abbreviation is caused by such a link, 1150 and no specific additional recommendations are necessary. 1152 Further, in order to allow aggregation of IP addresses at national 1153 and continental boundaries into as few prefixes as possible, we 1154 further recommend that IP addresses allocated to routing domains 1155 should be assigned based on each routing domain's connectivity to 1156 national and continental Internet backbones. 1158 6.2 Recommendations for Multi-Homed Routing Domains 1160 Some routing domains will be attached to multiple TRDs within the 1161 same country, or to TRDs within multiple different countries. We 1162 refer to these as `multi-homed' routing domains. Clearly the strict 1163 hierarchical model discussed above does not neatly handle such 1164 routing domains. 1166 There are several possible ways that these multi-homed routing 1167 domains may be handled. Each of these methods vary with respect to 1168 the amount of information that must be maintained for inter-domain 1169 routing and also with respect to the inter-domain routes. In 1170 addition, the organization that will bear the brunt of this cost 1171 varies with the possible solutions. For example, the solutions vary 1172 with respect to: 1174 resources used within routers within the TRDs; administrative cost on 1175 TRD personnel; and, difficulty of configuration of policy-based 1176 inter-domain routing information within leaf routing domains. 1178 Also, the solution used may affect the actual routes which packets 1179 follow, and may effect the availability of backup routes when the 1180 primary route fails. 1182 For these reasons it is not possible to mandate a single solution for 1183 all situations. Rather, economic considerations will require a 1184 variety of solutions for different routing domains, service 1185 providers, and backbones. 1187 6.3 Recommendations for the Administration of IP addresses. 1189 We recommend that there be a single 'root' address allocation 1190 authority. This addressing authority shall delegate a prefix and 1191 authority over that prefix to continental authorities. Each 1192 continental authority shall delegate a prefix and authority over that 1193 prefix for each TRD. This prefix should be sufficient to provide for 1194 the TRD's addressing needs for approximately two years. Once this is 1195 exhausted, additional address space should be allocated based on the 1196 projected growth rate of the TRD. We recommend that the root and the 1197 continental address allocation authorities operate based on the 1198 algorithm found in CIDR [1]. 1200 RFC DRAFT September 1992 1202 Within North America we suggest IP addresses be administered 1203 according to the following scheme. From the IP address space 1204 allocated for Class C addresses, the 'root' address allocation 1205 authority will reserve an IP prefix with the value <198.0.0.0 1206 254.0.0.0> for North America. This is a block of 7 high order bits, 1207 allowing 17 bits of network number. This is 131,072 Class C networks. 1208 For comparison, as of this writing, approximately 47000 Class C 1209 addresses have been assigned. The proposed allocation is roughly 6% 1210 of the unallocated address space. 1212 We recommend that a portion of this address space be used for TRDs 1213 and that another portion be reserved for multi-homed domains which 1214 will exist within the continent. It is important that allocation 1215 within this address space also be done efficiently. There are 1216 multiple strategies which can be used to do this but the essential 1217 goal is to minimize fragmentation of the address space. One possible 1218 algorithm for doing this is given in [1]. It has the advantage that 1219 it makes maximum use of the available address space with minimum 1220 fragmentation. An alternative algorithm is to allocate from the top 1221 of the address space down for multi-homed domains and from the bottom 1222 of the space up with TRDs. Within each of these two parts of the 1223 address space, continue to use the algorithm for [1]. This is 1224 somewhat less optimal in that, in the worst case, it leads to twice 1225 the fragmentation of the address space compared to the previous 1226 algorithm. 1228 We further recommend that there be a single address allocation 1229 authority for Europe. We recommend that Europe be given an amount of 1230 address space similar to North America, with a reserved prefix of 1231 <194.0.0.0 254.0.0.0>. Again, this is a block of 131,072 networks. 1233 We recommend that the root address allocation authority reserve all 1234 remaining Class A addresses for large public data networks that span 1235 multiple national and/or continental boundaries. 1237 There is already a serious shortage of Class B addresses. We 1238 recommend that no Class B addresses be allocated to continental 1239 authorities and that they be reserved instead for large multi-homed 1240 international organizations, similar to MBII (see section 5.4). 1242 Allocation of Class A and Class B addresses should be handled solely 1243 by the root address allocation authority. 1245 We recommend that an address allocation authority make publicly 1246 available information about addresses allocated, to that authority, 1247 but not yet assigned. Further, we recommend that an address 1248 allocation authority surrender all addresses allocated by not 1249 assigned, when requested by a higher address allocation authority. 1251 7 Security Considerations 1253 Security issues are not discussed in this memo. 1255 RFC DRAFT September 1992 1257 8 Acknowledgments 1259 The authors would like to acknowledge the substantial contributions 1260 made by the authors of RFC 1237 [2], Richard Colella, Ella Gardner, 1261 and Ross Callon. The significant concepts (and most of the text) in 1262 this memo are taken directly from their work. We would also like to 1263 thank Kannan Varadhan (OARnet), Elise Gerich (NSFNET/MERIT), Jon 1264 Postel (ISI), Bernhard Stockman (NORDUNET/SUNET), Claudio Topologic 1265 (BBN), Barry Leiner (ADS), and Peter Ford (Los Alamos National 1266 Laboratory) for their review and constructive comments. 1268 9 Authors' Addresses 1270 Yakov Rekhter 1271 T.J. Watson Research Center IBM Corporation 1272 P.O. Box 218 1273 Yorktown Heights, NY 10598 1274 Phone: (914) 945-3896 1275 email: yakov@watson.ibm.com 1277 Tony Li 1278 cisco Systems, Inc. 1279 1525 O'Brien Drive 1280 Menlo Park, CA 94025 1281 email: tli@cisco.com 1283 10 References 1285 [1] Fuller, V., Li, T., Yu, J., and Varadhan, K., `Supernetting: an 1286 Address Assignment and Aggregation Strategy', to appear as an 1287 Internet Draft, April 9, 1992. 1289 [2] Colella, R., Gardner, E, and Callon, R., `Guidelines for OSI NSAP 1290 Allocation in the Internet'