idnits 2.17.1 draft-ietf-cidrd-appeal-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-25) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 505 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 24 instances of lines with control characters in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1995) is 10420 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CIDRD Working Group Philip J. Nesser II 2 Internet Draft Nesser & Nesser Consulting 3 October 1995 5 An Appeal to the Internet Community to Return 6 Unused IP Networks(Prefixes) to the IANA 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 Areas, and its Working Groups. Note that other groups may also 14 distribute working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted 18 by other documents at any time. It is not appropriate to use 19 Internet Drafts as reference material or to cite them other than 20 as a ``working draft'' or ``work in progress.'' 22 Please check the 1id-abstracts.txt listing contained in the 23 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 24 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 25 current status of any Internet Draft. 27 This draft expires in April 1996. 29 Abstract 31 This document is an appeal to the Internet community to return 32 unused address space, i.e. any block of consecutive IP prefixes, 33 to the Internet Assigned Numbers Authority (IANA) or any of the 34 delegated registries, for reapportionment. Similarly an appeal 35 is issued to providers to return unused prefixes which fall 36 outside their customary address blocks to the IANA for 37 reapportionment. 39 1. Background 41 The Internet of today is a dramatically different network than 42 the original designers ever envisioned. It is the largest 43 public data network in the world, and continues to grow at an 44 exponential rate which doubles all major operational parameters 45 every nine months. A common metaphor in engineering is that 46 every time a problem increases in size by an order of magnitude, 47 it becomes a new problem. This adage has been true over the 48 lifetime of the Internet. 50 The Internet is currently faced with two major operational 51 problems (amoung others). The first is the eventual exhaustion 52 of the IPv4 address space and the second is the ability to route 53 packets between the large number of individual networks that 54 make up the Internet. The first problem is simply one of 55 supply. There are only 2^32 IPv4 addresses available. The 56 lifetime of that space is proportional to the efficiency of its 57 allocation and utilization. The second problem is mainly a 58 capacity problem. If the number of routes exceeds the current 59 capacity of the core Internet routers, some routes will be 60 dropped and sections of the Internet will no longer be able to 61 communicate with each other. The two problems are coupled and 62 the dominant one has, and will, change over time. 64 The initial design of IP had all addresses the same, eight bits 65 of network number and twenty four bits of host number. The 66 expectation was of a few, large, global networks. During the 67 first spurts of growth, especially with the invention of LAN 68 technologies, it became obvious that this assumption was wrong 69 and the separation of the address space into three classes 70 (Class A for a few huge networks; Class B for more, smaller 71 networks; and Class C for those really small LANs, with lots of 72 network numbers) was implemented. Soon subnets were added so 73 sites with many small LANs could appear as a single network to 74 others, the first step at limiting routing table size. And 75 finally, CIDR was introduced to the network, to add even more 76 flexibility to the addressing, extending the split from three 77 classes to potentially thirty different classes. 79 Subnets were introduced to provide a mechanism for sites to 80 divide a single network number (Class A, B, or C) into pieces, 81 allowing a higher utilization of address space, and thus 82 promoting conservation of the IPv4 address space. Because of 83 the built-in notion of classful addresses, subnetting 84 automatically induced a reduction in the routing requirements on 85 the Internet. Instead of using two (or more) class C networks, 86 a site could subnet a single class B into two (or more) subnets. 87 Both the allocation and the advertisement of a route to the 88 second and succeeding class C's are saved. 90 Since 1993, the concept of classless (the "C" in CIDR) addresses 91 have been introduced to the Internet community. Addresses are 92 increasingly thought of as bitwise contiguous blocks of the 93 entire address space, rather than a class A,B,C network. For 94 example, the address block formerly known as a Class A network, 95 would be referred to as a network with a /8 prefix, meaning the 96 first 8 bits of the address define the network portion of the 97 address. Sometimes the /8 will be expressed as a mask of 98 255.0.0.0 (in the same way a 16 bit subnet mask will be written 99 as 255.255.0.0). 101 This scheme allows "supernetting" of addresses together into 102 blocks which can be advertised as a single routing entry. The 103 practical purpose of this effort is to allow service providers 104 and address registries to delegate realistic address spaces to 105 organizations and be unfettered by the traditional network 106 classes, which were inappropriately sized for most 107 organizations. For example the block of 2048 class C network 108 numbers beginning with 192.24.0.0 and ending with 192.31.255.0 109 can be referenced as 192.24/19, or 192.24.0.0 with a mask of 110 255.248.0.0 (i.e. similar to a 19 bit subnet mask written in 111 dotted decimal notation). The concept of "supernetting" allows 112 the remaining Internet address space to be allocated in smaller 113 blocks, thus allowing more networks and better efficiency. For 114 a more detailed discussion refer to RFC 1518. 116 Like subnetting, CIDR also helps address the reduction of 117 routing requirements, but it is not as automatic as the case of 118 subnets. CIDR blocks are allocated in a way which promotes 119 hierarchical routing. A provider is typically given a large 120 block of addresses to redistribute to their customers. For 121 example, if the provider P has been given the CIDR block 122 192.168/16, a block of 255 contiguous class C networks, they can 123 provide one class C network to each of 255 customers (who may in 124 turn subnet those class C networks into smaller pieces) yet 125 still only advertise the single route 192.168/16. Thus CIDR 126 only helps reduce the routing problem if blocks are assigned and 127 maintained in a hierarchical manner. 129 RFC 1797 is a technical experiment designed to test the 130 problems with allocating the currently reserved Class A network 131 space. This effort would allow "supersubnetting" of a Class A 132 network into numerous (even millions) of smaller networks. 134 The dominating portion of the problem facing the Internet today 135 is routing requirements. The following statements constitute a 136 first order approximation based on current growth, a simple 137 model of router resources, etc. Current routing technology can 138 handle approximately twice the number of routes which are 139 currently advertised on "core" Internet routers. Router 140 capacity is doubling every 18 months, while routing tables are 141 doubling every 9 months. If routes continue to be introduced at 142 the current rate, the Internet will cease to function as a 143 reliable infrastructure in approximately 2 to 3 years. 145 The good news is that CIDR is working. Address blocks are being 146 allocated and assigned in a hierarchical manner, and the 147 CIDR'ization of large portions of the address space which were 148 assigned according to the guidelines of RFC 1466 resulted in a 149 significant drop of advertised routes. However, recent growth 150 trends show that the number of routes is once again growing at 151 an exponential rate, and that the reduction with the 152 introduction of CIDR was simply a sawtooth in the rate. 154 The growth in the number of routes can logically come from only 155 two places, the extra routes generated with the breakup of CIDR 156 blocks, and previously allocated and unannounced networks being 157 connected. (Registries are still allocating a few addresses not 158 within CIDR blocks, so a small third source does exist.) With 159 increasing popularity there is increasing competition between 160 providers. If a site changes provider and retains the use of 161 their CIDR block addresses, holes appear in the blocks and 162 specific routes are added to the routing structure to 163 accommodate these cases. Thus over time, CIDR will improve 164 address utilization efficiency yet not help the routing 165 requirements unless providers can keep their CIDR blocks intact. 167 The second source for new route introduction is sites who had 168 previously operated a private IP network, which had been 169 registered and assigned a network number (or numerous networks), 170 but have only recently connected to the global Internet. This 171 RFC is a policy based attempt to help preserve the operation of 172 the current Internet by addressing the issues of previously 173 registered but unannounced IP networks. 175 An additional area of route introduction comes from 176 non-aggregating router configurations. Aggregation is not 177 automatic on most routers, and providers who may have intact 178 CIDR blocks are, in many cases, advertising individual routes 179 instead of an aggregate block without realizing. 181 In the context of this document, the phrase "Global Internet" 182 refers to the mesh of interconnected public networks (Autonomous 183 Systems) which has its origins in the U.S. National Science 184 Foundation (NSF) backbone, other national networks, and 185 commercial enterprises. Similarly, the phrase or any references 186 to the "Core Routers" refer to the set of routers which carry 187 the full set of route advertisements and act as interconnect 188 points for the public networks making up the "Global Internet." 190 2. History 192 The IANA has historically managed the assignment of addresses to 193 Internet sites. During the earliest days of the IANA, given a 194 vast address space, the requirements for assignments of network 195 address space were much less stringent than those required 196 today. Organizations were essentially assigned networks based 197 on their requests. 199 2.1 Class A Networks (/8 Prefixes) 201 The upper half of the Class A address space (64.0.0.0 - 202 126.0.0.0) (127.0.0.0 has traditionally been used by the Unix 203 operating system as the "loopback" network, and is thus 204 unavailable) has been reserved by the IANA for growth within the 205 IPv4 address space. Of the lower half of the address space, 22 206 were assigned pre-1982, 6 were assigned between 1982 and 1987, 207 26 were assigned between 1988 and 1992, and 2 were assigned 208 between 1993 and 1995. In May of 1995 four Class A networks 209 previously assigned have been returned to the IANA. All 210 remaining Class A addresses have also been reserved for growth 211 within the IPv4 address space. The Class A address space is 50% 212 of the total IPv4 address space. 214 2.2 Class B Networks (/16 prefixes) 216 From 1989 until 1993 approximately 80% of the currently assigned 217 Class B IP networks were assigned or allocated. Allocations 218 dropped dramatically in 1994 and 1995 due to the adoption of 219 policies outlined in RFC 1466. 61.65% of the Class B address 220 space is currently allocated. The class B address space is 25% 221 of the total IPv4 address space. 223 2.3 Class C Networks (/24 Prefixes) 225 With the introduction of CIDR and RFC 1466 the allocation of 226 Class C address space has skyrocketed since 1993. 27.82% of the 227 Class C address space is currently allocated. The class C 228 address space is 12.5% of the total IPv4 address space. 230 2.4 Class "D" and Beyond 232 Of the remaing 12.5% of the address space, the upper 6.25% is 233 allocated for multicast applications (mbone, OSPF, etc.) and the 234 lower half is reserved for future applications. 236 2.4 Totals 238 The weighted total shows that 40.99% of the total IPv4 address 239 space is allocated and the remainder is reserved for future 240 growth. It should be noted that careful extrapolations of the 241 current trends suggest that the address space will be exhausted 242 early in the next century. 244 4. Problem 246 Before the introduction of RFC 1466 and of CIDR, some 50,000 247 networks were assigned by the IANA, yet only a small percentage 248 (30-40%) of the sites actually had connections to the global 249 Internet and advertised those networks. As the popularity of 250 the Internet is growing, a growing number of those sites are 251 being connected, and increasing the size of the routing tables. 253 Current Internet sites have received their address assignments 254 in various ways and steps. Some sites, through a little (or in 255 some cases no) work, could donate unused IP nets back to the 256 IANA. 258 Some organizations have made small requests at first and 259 received a Class C assignment (or multiple Class C assignments), 260 and after unexpected growth made subsequent requests and 261 received Class B assignments. 263 Several Internet service providers were given blocks of the 264 Class B address space to distribute to customers. This space 265 was often provided to clients based upon a level of service 266 purchased rather than actual need. 268 Many organizations have either merged or are associated with 269 parent organizations which produce situations with large 270 inefficiencies in address assignment. 272 Many organizations have requested addresses based on their need 273 to run TCP/IP on internal machines which have no interest in 274 connecting to the global Internet. Most vendors manuals have 275 instructed (and provided copies of the application forms), sites 276 to request IP address assignments. 278 Other organizations have large internal IP networks, and are 279 connected to the Internet through application layer gateways or 280 network address translators, and will never announce their 281 internal networks. 283 5. Appeal 285 To the members of the Internet community who have IP network 286 assignments which may be currently unused, the Internet 287 community would like to encourage you to return those addresses 288 to the IANA or your provider for reapportionment. 290 Specifically those sites who have networks which are unused are 291 encouraged to return those addresses. Similarly to those sites 292 who are using a small percentage of their address space and who 293 could relatively easily remove network assignments from active 294 use, the Internet community encourages such efforts. 296 To those sites who have networks which will never need to 297 connect to the global Internet, or for security reasons will 298 always be isolated, consider returning the address assignments 299 to the IANA or your provider and utilizing prefixes recommended 300 in RFC 1597. 302 In those cases where renumbering is required, sites are 303 encouraged to put into place a plan to renumber machines, 304 as is reasonably convenient, and work towards minimizing the 305 number of routes advertised to their providers. 307 5.1 Suggestions to Providers 309 Many providers are currently advertising non-CIDR routes which 310 encompass a large block of addresses, ie any Class A (0/1) or 311 Class B (128/2) space. Some customers who are only using a 312 percentage of their address space (assuming they are subnetting 313 using contiguous bits) may be willing to allow usage of the 314 upper portion of their assigned address space by their providers 315 other customers. 317 This scheme requires certain elements be installed or already in 318 place to get the routing correct, but has the potential to gain 319 the use of a large number of small networks without growth of 320 the global routing tables. This would require additional 321 measures of cooperation between providers and their customers 322 but could prove to have both economic advantages, as well as 323 good Internet citizen standing. 325 For example, large organization S has been assigned the class A 326 block of addresses 10.0.0.0. and is currently using provider P 327 for their connection to the global Internet. P is already 328 advertising the route for 10.0.0.0 to the global Internet. S 329 has been allocating its internal networks using a right to left 330 bit incrementing model. P and S could agree that S will allow 331 some /18 (for example) prefixes to be made available for P's 332 other customers. This would impose no hardships whatsoever on 333 S, presuming his router can speak BGP, and allow P to attach a 334 huge number of small customers without the need to advertise 335 more routes or request additional address blocks from the IANA 336 or their upstream provider. 338 The current Net 39 experiment as outlined in RFC 1797 should 339 provide practical data on the implementation of the suggested 340 schemes. 342 Additionally, providers are encouraged to release all unused 343 networks which fall outside of their normal address blocks back 344 to the IANA or the appropriate registry. 346 New customers, particularly those who may have recently changed 347 providers, and who have small networks which are not part of 348 CIDR'ized blocks, should be encouraged to renumber and release 349 their previous addresses back to the provider or the IANA. 351 Since the first introduction of CIDR in April of 1994, many 352 providers have aggresively pursued the concepts of aggregation. 353 Some providers actively persuaded their customers to renumber, 354 while others pursued peering arrangements with other providers, 355 and others did both. Providers should continue to actively and 356 routinely pursue both methods to streamline routing table 357 growth. Cooperation between providers is absolutely essential 358 to short (and long) term management of routing requirements. 360 Providers should regularly verify the routes they are 361 advertising to their upstream provider(s) to validate their 362 router configurations and confirm correct aggregation is 363 occuring. 365 5.2 Suggestions to the IANA and Address Registries 367 In cases where addresses are returned to the IANA, or any other 368 address registry, which fits into another registry or providers 369 block, the addresses should be turned over to the appropriate 370 authority. This will help maximize the availability of 371 addresses and minimize routing table loads. 373 5.3 How to Return a Block of Address Space to the IANA 375 Send the following form to Hostmaster@internic.net & 376 iana@isi.edu, changing the $NET_PREFIX to the network being 377 returned. 379 ---------------------------------------------------------------- 381 Please update the contact information on the following net as 382 follows: 384 Netname: RESERVED 385 Netnumber: $NET_PREFIX 387 Coordinator: 388 Reynolds, Joyce K. (JKR1) JKRey@ISI.EDU 389 (310) 822-1511 390 Alternate Contact: 391 Postel, Jon (JBP) POSTEL@ISI.EDU 392 (310) 822-1511 394 ---------------------------------------------------------------- 396 5.4 How to Return a Block of Address Space to another Address 397 Registry 399 Each registry will have its own forms and addresses. Please 400 contact the appropriate registry directly. 402 6. Conclusion 404 Rationalizing the global addressing hierarchy is a goal which 405 should be supported by any organization which is currently 406 connected or plans to connect to the Internet. If (and possibly 407 when) the situation ever reaches a critical point, the core 408 service providers whose routers are failing and losing routes 409 will be forced to make one of two choices, both painful to the 410 user community. 412 They could begin blocking routes to their customers who are 413 advertising too many disjoint routes, where "too many" will be 414 set at the level necessary to keep their routers functioning 415 properly. This is a domino effect since the next level of 416 providers will be forced to make the same effort, until 417 individual organizations are forced to only advertise routes to 418 portions of their networks. 420 The second option the core providers have is to charge for 421 advertised routes. The price level will be set at a point which 422 reduces the number of routes to a level which will keep their 423 routers functioning properly. Once again a domino effect will 424 take place until the price increases will effect individual 425 organizations. 427 Some planning and efforts by organizations and providers now 428 while there is a some time available can help delay or prevent 429 either or the two scenarios from occurring. 431 This system has already produced very favorable results when 432 applied on a small scale. As of this writing 4 Class A networks 433 have been returned to the IANA. This may not seem significant 434 but those 4 networks represent over 1.5% of the total IPv4 435 address capacity. 437 7. References 439 1. E. Gerich, Guidelines for Management of the IP 440 Address Space, RFC 1466, May 1993. 442 2. C. Topolcic, Status of CIDR Deployment in the 443 Internet, RFC 1467, August 1993. 445 3. Y. Rekhter, T. Li, An Architecture for IP Address 446 Allocation with CIDR, RFC 1518, September 1993. 448 4. V. Fuller, T. Li, J. Yu, K. Varadhan, Classless 449 Inter-Domain Routing (CIDR): an Address Assignment 450 and Aggregation Strategy, RFC 1519, September 1993. 452 5. Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de 453 Groot, Address Allocation for Private Internets, RFC 454 1597, March 1994. 456 6. E. Lear, E. Fair, D. Crocker, T. Kessler, Network 10 457 Considered Harmful (Some Practices Shouldn't be 458 Codified), RFC 1627, July 1994. 460 7. C. Huitema, The H Ratio for Address Assignment 461 Efficiency, RFC 1715, November 1994. 463 8. IANA, Class A Subnet Experiment, RFC 1797, April 464 1995. 466 8. Security Consideration 468 Security issues are not discussed in this memo. 470 9. Acknowledgements 472 I would like to thank the members of the CIDRD mailing list and 473 working groups for their suggestion and comments on this 474 document. Specific thanks should go to Michael Patton, Tony Li, 475 Noel Chiappa, and Dale Higgs for detailed comments and 476 suggestions. 478 10. Authors Address 480 Philip J. Nesser II 481 Nesser & Nesser Consulting 482 16015 84th Avenue N.E. 483 Bothell, WA 98011-4451 484 Phone: (206)488-6268 485 Fax: (206)488-6268 486 EMail: pjnesser@martigny.ai.mit.edu