home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1917 < prev    next >
Text File  |  1996-02-26  |  24KB  |  564 lines

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