An Appeal to the Internet Community to Return Unused IP Networks(Prefixes) to the IANA Expires in six months Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to the Internet Address Naming Authority (IANA) or any of the delegated registries, for reapportionment. Similarly an appeal is issued to providors to return unused prefixes which fall outside their customary address blocks to the IANA for reapportionment. 1. Introduction The explosion of the Internet has caused significant effort to be directed towards solving the problems of exponential growth. Two of the underlying technical problems in dealing with this growth are management of the overall address space (currently limited to 2^32 possible addresses, assuming maximum utilization), and the management of address utilization (which is directly proportional to the size of the global routing tables). Efforts have been made to extend the life of IPv4 as long as possible in order to keep the current Internet as operationally robust and continuously growing. Some efforts have been policy based, RFC 1466, and other efforts have been technically based, RFCs 1518 and 1519. RFC 1797 is an technical experiment designed to test the problems with allocating the currently reserved Class A network space. This RFC is a policy based effort to extend the lifetime of the address space. Since 1993 the concept of classless (the "C" in CIDR) addresses has been introduced to the Internet community. Addresses are increasingly thought of as bitwise contiguous blocks of the entire address space, rather than a class {A,B,C} address space. For example, the address chunk formerly known as a Class A network, would be refered to as a network with a /8 prefix, meaning the first 8 bits of the address define the network portion of the address. Sometimes the /8 will be expressed as a mask of 255.0.0.0 (in the same way an 16 bit subnet mask will be written as 255.255.0.0). This scheme allows "supernetting" of addresses together into a blocks which can be advertised as a single routing entry. The practical purpose of this effort is to allow service providers and address registries to delegate realistic address spaces to organizations and be unfettered by the traditional network classes, which were usually inappropriately sized for most organizations. For example the block of 2048 class C network numbers beginning with 192.24.0.0 and ending with 192.31.255.0 can be referenced as 192.24/19, or 192.24.0.0 with a mask of 255.248.0.0 (ie 2^19 in dotted decimal notation). The concept of "supernetting" allows the remaining Class A space to be allocated in smaller blocks, thus allowing more networks and better efficiency. For a much more detailed discussion refer to RFC 1518. 2. History The IANA has historically managed the assignment of addresses to Internet sites. During the earliest days of the IANA, given a vast address space, the requirements for assignments of network address space were much less stringent than those required today. Organizations were essentially assigned networks based on their requests. 2.1 Class A Networks (/8 Prefixes) The upper half of the Class A address space (64.0.0.0 - 127.0.0.0) has been reserved by the IANA for growth within the IPv4 address space. Of the lower half of the address space, 22 were assigned pre-1982, 6 were assigned between 1982 and 1987, 26 were assigned between 1988 and 1992, and 2 were assigned between 1993 and 1995. In May of 1995 four Class A networks previously assigned have been returned to the IANA. All remaining Class A addresses have also been reserved for growth within the IPv4 address space. 100% of the Class A address space is currently allocated, although 62% is reserved by the IANA and unused. The Class A address space is 50% of the total IPv4 address space. 2.2 Class B Networks (/16 prefixes) >From 1989 until 1993 approximately 80% of the currently assigned Class B IP networks were assigned or allocated. Allocations dropped dramatically in 1994 and 1995. 61.65% of the Class B address space is currently allocated. The class B address space is 25% of the total IPv4 address space. 2.3 Class C Networks (/24 Prefixes) With the introduction of CIDR and RFC 1466 the allocation of Class C address space has skyrocketed since 1993. 27.82% of the Class C address space is currently allocated. The class C address space is 12.5% of the total IPv4 address space. 2.4 Totals The weighted total shows that 65.74% (34.74% actually allocated to organizations and 31% reserved for future growth) of the total IPv4 address space has been allocated. It should be noted that careful extrapolations of the current trends suggest that the address space will be exhausted early in the next century. However, the situation is already serious. 3. Address Assignment Efficiency The network class system of IPv4 leads to large inefficiencies in utilization of addresses per network assignment. For any Class A or Class B network there is a high probability that the organization is sparsely populating their network space. A typical Class B site will have upwards of several thousand connected components. With a theoretical maximum of 65536 possible connection (neglecting end effects of subnetting, etc.) the address utilization is well under 5%. Even a site with 10,000 computers is using only 15% of their maximum. Current IANA guidelines request 10% utilization for the granting of a block of addresses. The lack of assignment efficiency is only exacerbated in the case of Class A networks. 4. Problem The problem is there is not enough IPv4 address space to meet the growing needs of the expanding Internet. There is significant work going into IPv6 which will alleviate the address space shortage, but any implementation is still years away from wide spread acceptance. The lack of address space is not a problem which will stop the Internet today, but will have serious impact on the next few years growth as new site need connectivity. Current Internet sites have received their address assignments in various ways and steps. Some sites through a little (or in some cases no) work could donate unused IP nets back to the IANA Many organizations have requested addresses based on their need to run TCP/IP on internal machines which have no interest in connecting to the global Internet. Most vendors manuals have instructed (and provided copies of the application forms) sites to request IP addresses assignments. Some organizations have made small requests at first and received a Class C assignment, and after unexpected growth made subsequent requests and received Class B assignments. Some Internet service providers were given blocks of the Class B address space to distribute to customers. This space was often provided to clients based upon a level of service purchased rather than actual need. Many organizations have either merged or are associated with parent organizations which produce situations with large in efficiencies in address assignment. 5. Appeal To the members of the Internet community who have IP network assignments which may be currently unused, the IANA and the rest of the Internet community would like to encourage you to return those addresses to the IANA or your provider for reapportionment. Specifically those site who have Class A or B networks which are unused, since they represent a majority of the total address space, although Class C returns are encouraged as well. Similarly to those sites who are using a small percentage of their address space and who could relatively easily remove networks assignments from active use, the Internet community encourages such efforts. To those sites who have networks which will never need to connect to the global Internet, or for security reasons will always be isolated, consider returning the address assignments to the IANA or your providor and utilizing prefixes recommended in RFC 1597. 5.1 Suggestions to Providers Many providers are currently advertising Non-CIDR routes which encompase a large block of addresses, ie any Class A (0/2) or Class B (128/2) space. Some customers who are only using a percentage of their address space (assuming they are subnetting using contiguous bits) may be willing to allow usage of the upper portion of their assigned address space by the providers other customers. This scheme requires certain elements be installed or already in place to get the routing correct, but has the potential to gain the use of a large number of small networks without growth of the global routing tables. This would require additional measures of cooperation between providers and their customers but could prove to have both economic advantages, as well as good Internet citizen standing. For example, large organization FOO has been assigned the class A block of addresses 68.0.0.0. and is currently using provider BOB for their connection to the global Internet. BOB is already advertising the route for 68.0.0.0 to the global Internet. FOO has been allocating its internal networks using a left to right bit incrementing model. BOB and FOO could agree that FOO will allow some /18 (for example) prefixes to be made available for BOB's other customers. This would impose no hardships whatsoever on FOO, presuming his router can speak BGP, and allow BOB to attach a huge number of small customers without the need to advertise more routes or request additional address blocks from the IANA or their upstream provider. The current Net 39 experiment as outlined in RFC 1797 should provide practical data on the implementation of the suggested schemes. Additionally, providers are encouraged to release all unused networks which fall outside of their normal address blocks back to the IANA. New customers, particularly those who may have changed providers who have small networks which are not part of CIDR`ized blocks should be encouraged to renumber and release their previous addresses back to the provider or the IANA. 5.2 Suggestions to the IANA and Address Registries In cases where addresses are returned to the IANA, or any other address registry, which fits into another registry or providers block, the addresses should be turned over to the appropriate authority. This will help maximize the availability of addresses and minimize routing table loads. 5.3 How to Return a Block of Address Space to the IANA Send the following form to Hostmaster@internic.net & iana@isi.edu, changing the $NET_PREFIX to the network being returned. ---------------------------------------------------------------------------- Please update the contact information on the following net as follows: Netname: RESERVED Netnumber: $NET_PREFIX Coordinator: Reynolds, Joyce K. (JKR1) JKRey@ISI.EDU (310) 822-1511 Alternate Contact: Postel, Jon (JBP) POSTEL@ISI.EDU (310) 822-1511 --------------------------------------------------------------------------- 5.4 How to Return a Block of Address Space to another Address Registry Each registry will have its own forms and addresses. Please contact the approppriate registry directly. 6. Conclusion This system has already produced very favorable results when applied on a small scale. As of this writing 4 Class A networks have been returned to the IANA. This may not seem significant but those 4 networks represent over 1.5% of the total IPv4 address capacity. 7. References 1. E. Gerich, Guidelines for Management of the IP Address Space, RFC 1466, May 1993. 2. C. Topolcic, Status of CIDR Deployment in the Internet, RFC 1467, August 1993. 3. Y. Rekhter, T. Li, An Architecture for IP Address Allocation with CIDR, RFC 1518, September 1993. 4. V. Fuller, T. Li, J. Yu, K. Varadhan, Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy, RFC 1519, September 1993. 5. Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, Address Allocation for Private Internets, RFC 1597, March 1994. 6. E. Lear, E. Fair, D. Crocker, T. Kessler, Network 10 Considered Harmful (Some Practices Shouldn't be Codified), RFC 1627, July 1994. 7. C. Huitema, The H Ratio for Address Assignment Efficiency, RFC 1715, November 1994. 8. IANA, Class A Subnet Experiment, RFC 1797, April 1995. 8. Security Consideration Security issues are not discussed in this memo. 9. Authors Address Philip J. Nesser Olin Aerospace Company 15825 Willows Road N.E. Redmond, WA 98052 Phone: (206) 885-5000, extension 5477 EMail: pjnesser@rocket.com