Internet DRAFT - draft-nesser-appeal
draft-nesser-appeal
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 10:27:31 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 18 May 1995 22:00:00 GMT
ETag: "361c96-3515-2fbbc360"
Accept-Ranges: bytes
Content-Length: 13589
Connection: close
Content-Type: text/plain
An Appeal to the Internet Community to Return
Unused IP Networks(Prefixes) to the IANA
<draft-nesser-appeal-00.txt>
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
