[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 RFC 2071

PIER Working Group                                   P. Ferguson
Internet Draft                                       cisco Systems, Inc.
June 1996
Expires in six months

                    Network Renumbering Overview:
              Why would I want it and what is it anyway?

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.''

    To learn the current status of any Internet-Draft, please check the
    ``1id-abstracts.txt'' listing contained in the Internet-Drafts
    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
    ftp.isi.edu (US West Coast).


   The PIER [Procedures for Internet/Enterprise Renumbering] working
   group is compiling a series of documents to assist and instruct
   organizations in their efforts to renumber.  However, it is becoming
   apparent that, with the increasing number of new Internet Service
   Providers (ISP's) and organizations getting connected to the
   Internet for the first time, the concept of network renumbering
   needs to be further defined.  This document attempts to clearly
   define the concept of network renumbering and discuss some of the
   more pertinent reasons why an organization would have a need to do

draft-ietf-pier-renum-ovrvw-00.txt                              [Page 1]

INTERNET-DRAFT        Network Renumbering Overview             June 1996

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.   Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.   Network Renumbering Defined. . . . . . . . . . . . . . . . . 3
   4.   Reasons for Renumbering. . . . . . . . . . . . . . . . . . . 3
   5.   Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.   Security Considerations  . . . . . . . . . . . . . . . . . . 5
   7.   Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 6
   8.   References . . . . . . . . . . . . . . . . . . . . . . . . . 6
   9.   Author's Address . . . . . . . . . . . . . . . . . . . . . . 7

1. Introduction

   The popularity of connecting to the global Internet over the course
   of the past several years has spawned new problems; what most people
   casually refer to as ``growing pains'' can be attributed to more
   basic problems in understanding the requirements for Internet
   connectivity.  However, the reasons why organizations may need to
   renumber their networks can greatly vary. We'll discuss these issues
   in some amount of detail below.  It is not within the intended scope
   of this document to discuss renumbering methodologies, techniques, or

2. Background

   The ability for any network or interconnected devices, such as
   desktop PCs or workstations, to obtain connectivity to any potential
   destination in the global Internet is reliant upon the possession of
   unique IP host addresses [1].  A duplicate host address that is
   being used elsewhere in the Internet could best be described as
   problematic, since the presence of duplicate addresses would cause
   one of the destinations to be unreachable from some origins in the
   Internet.  It should be noted, however, that globally unique IP
   addresses are not always necessary, and is dependent on the
   connectivity requirements [2].

   However, the recent popularity in obtaining Internet connectivity
   has made these types of connectivity dependencies unpredictable,
   and conventional wisdom in the Internet community dictates that
   the various address allocation registries, such as the interNIC,
   as well as the ISP's, become more prudent in their address
   allocation strategies.  In that vein, the interNIC has defined
   address allocation policies [3] wherein the majority of address
   allocations for end-user networks are accommodated by their
   upstream ISP, except in cases where dual- or multihoming and
   very large blocks of addresses are required.  With this allocation
   policy becoming standard current practice, it presents unique
   problems regarding the portability of addresses from one provider
   to another.

   Also, in many instances, organizations who have never connected to

draft-ietf-pier-renum-ovrvw-00.txt                              [Page 2]

INTERNET-DRAFT        Network Renumbering Overview             June 1996

   the Internet, yet have been using arbitrary blocks of addresses since
   their construction, have different and unique challenges.

3. Network Renumbering Defined

   In the simplest of definitions, the exercise of renumbering a
   network consists of changing the IP host addresses, and perhaps
   the network mask, of each device within the network that has an
   address associated with it. This activity may or may not consist
   of all networks within a particular domain, such as FOO.EDU, or
   networks which comprise an entire autonomous system.

   Devices which may need to be renumbered, for example, are networked
   PC's, workstations, printers, file servers, terminal servers, and
   routers.  While this is not an all-inclusive list, the PIER working
   group is making efforts to compile documentation to identify these
   devices in a more detailed fashion.

   Network renumbering need not be sudden activity, either; in most
   instances, an organization's upstream service provider(s) will
   allow a grace period where both the ``old'' addresses and the ``new''
   addresses may be used in parallel.

4. Reasons for Renumbering

   The following sections discuss particular reasons which may
   precipitate network renumbering, and are not presented in any
   particular order of precedence.

   A. Initial connectivity and usage of non-unique addresses

   As recently as two years ago, many organizations had no intention
   of connecting to the Internet, and constructed their corporate or
   organizational network(s) using unregistered, non-unique network
   addresses.  Obviously, as most problems evolve, these same
   organizations determined that Internet connectivity had become
   a valuable asset, and subsequently discovered that they could no
   longer use the same unregistered, non-unique network addresses
   that were previously deployed throughout their organization.
   Thus, the labor of renumbering to valid network addresses is
   now upon them, as they move to connect to the global Internet.

   While obtaining valid, unique addresses are certainly required
   to obtain full Internet connectivity in most circumstances, the
   number of unique addresses required can be significantly reduced
   by the implementation of Network Address Translation (NAT) devices
   [4] and the use of private address space, as specified in [5].
   NAT reduces not only the number of required unique addresses, but
   also localizes the changes required by renumbering.

   It should also be noted that NAT technology may not always be
   a viable option, depending upon scale of addressing, performance
   or topological constraints.

draft-ietf-pier-renum-ovrvw-00.txt                              [Page 3]

INTERNET-DRAFT        Network Renumbering Overview             June 1996

   B. Change in organizational structure or network topology

   As companies grow, through mergers, acquisitions and reorganizations,
   the need may arise for realignment and modification of the various
   organizational network architectures.  The connectivity of disparate
   corporate networks present unique challenges in the realm of
   renumbering, since one or more individual networks may have to be
   blended into a much larger architecture consisting a different IP
   address prefix altogether.  Also, when a site or company makes major
   changes in it's internal network topology, for whatever reason,
   partial or complete renumbering may be necessary even if the network
   prefix does not change.

   C. Change of Internet Service Provider

   As mentioned previously in Section 2, it is increasingly becoming
   current practice for organizations to have their IP addresses
   allocated by their upstream ISP.  Also, with the advent of Classless
   Inter Domain Routing (CIDR) [6], and the considerable growth in the
   size of the global Internet table, Internet Service Providers
   are becoming more and more reluctant to allow customers to continue
   using addresses which were allocated by the ISP, when the customer
   terminates service and moves to another ISP.  The prevailing
   reason is that the ISP was previously issued a CIDR block of
   contiguous address space, which can be announced to the remainder of
   the Internet community as a single prefix. (A prefix is what is
   referred to in classless terms as a contiguous block of IP
   addresses.)  If a non-customer advertises a specific component
   of the CIDR block, then this adds an additional routing entry to
   the global Internet routing table.  This is what is commonly
   referred to as ``punching holes'' in a CIDR block. Consequently,
   there are usually no routing anomalies in doing this since a specific
   prefix is always preferred over an aggregate route.  However, if
   this practice were to happen on a large scale, the growth of the
   global routing table would become much larger, and perhaps too
   large for current backbone routers to accommodate in an acceptable
   fashion with regards to performance of recalculating routing
   information and sheer size of the routing table itself.  For obvious
   reasons, this practice is highly discouraged by ISP's with CIDR
   blocks, and some ISP's are making this a contractual issue, so that
   customers understand that addresses allocated by the ISP are non-

   It is noteworthy to mention that the likelihood of being forced to
   renumber in this situation is inversely proportional to the size of
   the customer's address space.  For example, an organization with a
   /16 allocation may be allowed to consider the address space
   ``portable'', while an organization with multiple non-contiguous
   /24 allocations may not.  While the scenarios may be vastly different
   in scope, it becomes an issue to be decided at the discretion of the
   initial allocating entity, and the ISP's involved; the major deciding
   factor being whether or not the change will fragment an existing CIDR
   block and whether it will significantly contribute to the overall
   growth of the global Internet routing tables.

draft-ietf-pier-renum-ovrvw-00.txt                              [Page 4]

INTERNET-DRAFT        Network Renumbering Overview             June 1996

   It should also be noted that (contrary to opinions sometimes voiced)
   this form of renumbering is a technically necessary consequence of
   changing ISP's, rather than a commercial or political mandate.

   D. Returning segregate prefixes for an aggregate

   It is not unusual for organizational networks to grow sporadically,
   obtaining an address prefix here and there, in a non-contiguous
   fashion.  Depending on the number of prefixes that an organization
   acquires over time, it may become increasingly unmanageable or demand
   higher levels of maintenance and administration when individual
   prefixes are acquired in this way.  In many instances, an
   organization can return their current, non-contiguous prefix
   allocations for a contiguous block of address space of equal or
   greater size, which can be accommodated with CIDR.  Also, many
   organizations have begun to deploy classless interior routing
   protocols within their domains that make use of route summarization
   and other optimized routing features, effectively reducing the total
   number of routes being propagated within their internal network(s),
   and making it much easier to administer and maintain.  This is also
   a highly encouraged method to help in reducing the size of the global
   routing table.

   E. Transitioning to IP version 6

   Of course, when IPv6 [7] deployment is set in motion, and as
   methodologies are developed to transition to IPv6, renumbering will
   also be necessary, but perhaps not immediately mandatory.  To aid
   in the transition to IPv6, mechanisms to deploy dual- IPv4/IPv6
   stacks on network hosts should also become available.  It is also
   envisioned that Network Address Translation (NAT) devices will be
   developed to assist in the IPv4 to IPv6 transition, or perhaps
   supplant the need to renumber the majority of interior networks
   altogether, but that is beyond the scope of this document.  At the
   very least, DNS hosts will need to be reconfigured to resolve new
   host names and addresses, and routers will need to be reconfigured
   to advertize new prefixes.

   IPv6 address allocation will be managed by the Internet Assigned
   Numbers Authority (IANA) as set forth in [8].

   F. Legacy address allocation

   There are also several instances where organizations were originally
   allocated very large amounts of address space, such as traditional
   ``Class A'' or ``Class B'' allocations, while the actual address
   requirements are much less than the total amount of address space
   originally allocated.  In many cases, these organizations could
   suffice with a smaller CIDR allocation, and utilize the allocated
   address space in a more efficient manner.  As allocation requirements
   become more stringent, mechanisms to review how these organizations
   are utilizing their address space could, quite possibly, result in
   a request to return the original allocation to a particular registry
   and renumber with a more appropriately sized address block.

draft-ietf-pier-renum-ovrvw-00.txt                              [Page 5]

INTERNET-DRAFT        Network Renumbering Overview             June 1996

5. Summary

   As indicated by the Internet Architecture Board (IAB) in [9],
   the task of renumbering networks is becoming more widespread
   and commonplace.  Although there are numerous reasons why an
   organization would desire, or be required to renumber, there are
   equally as many reasons why address allocation should be done with
   great care and forethought at the onset, in order to minimize the
   impact that renumbering would have on the organization.  Even
   with the most forethought and vision, however, an organization
   cannot foresee the possibility for renumbering. The best advice,
   in this case, is to be prepared, and get ready for renumbering.

6. Security Considerations

   Although no obvious security issues are discussed in this
   document, it stands to reason that renumbering certain devices
   can defeat security systems designed and based on static IP host
   addresses.  Care should be exercised by the renumbering entity
   to ensure that all security systems deployed with the network(s)
   which may need to be renumbered be given special consideration
   and significant forethought to provide continued functionality
   and adequate security.

7. Acknowledgments

   Special acknowledgments to Yakov Rekhter [cisco Systems, Inc.],
   Tony Bates [cisco Systems, Inc.] and Brian Carpenter [CERN] for
   their contributions and editorial critique.

8. References

 [1] RFC-1814, ``Unique Addresses are Good''; E. Gerich; IAB; June 1995

 [2] RFC-1775, ``To Be `On' the Internet''; D. Crocker, March 1995

     K. Hubbard, J. Postel, M. Kosters, D. Conrad, D. Karrenberg;

 [4] RFC-1631, ``The IP Network Address Translator (NAT)''; K. Egevang,
     P. Francis; May 1994

 [5] RFC-1918, ``Address Allocation for Private Internets''; Y. Rekhter,
     R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear;  February 1996

 [6] RFC-1519, ``Classless Inter-Domain Routing (CIDR): an Address
     Assignment and Aggregation Strategy''; V. Fuller, T. Li, J. Yu,
     K. Varadhan; October 1993

 [7] RFC-1883, ``Internet Protocol, Version 6 (IPv6) Specification'';
     S. Deering, R. Hinden; December 1995

draft-ietf-pier-renum-ovrvw-00.txt                              [Page 6]

INTERNET-DRAFT        Network Renumbering Overview             June 1996

 [8] RFC-1881, ``IPv6 Address Allocation Management''; IAB + IESG;
     December 1995

 [9] RFC-1900, ``Renumbering Needs Work''; B. Carpenter, Y. Rekhter;
     IAB; February 1996

9. Author's Address

   Paul Ferguson
   cisco Systems, Inc.
   1875 Campus Commons Road
   Suite 210
   Reston, VA 22091

   Phone: (703) 716-9538
   Fax: (703) 716-9599
   EMail: pferguso@cisco.com

draft-ietf-pier-renum-ovrvw-00.txt                               [Page 7]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/