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?
draft-ietf-pier-renum-ovrvw-00.txt
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).
Abstract
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
so.
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
tools.
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-
portable.
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
[3] Work in Progress; ``INTERNET REGISTRY IP ALLOCATION GUIDELINES'',
K. Hubbard, J. Postel, M. Kosters, D. Conrad, D. Karrenberg;
draft-hubbard-registry-guidelines-01.txt
[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]
