IAB B. Carpenter
Internet Draft Y. Rekhter
August 1995
Renumbering considered unavoidable
Abstract
draft-iab-renum-00.txt
Changes to addressing information (renumbering) associated with various
network components are likely to become more and more widespread and
common, and in many cases unavoidable. The IAB would like to stress
the need to develop and deploy solutions that would facilitate such
changes.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``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 ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Table of Contents:
Status of this Memo.............................................1
1. Motivation...................................................2
2. DNS versus IP Addresses......................................2
3. Recommendations..............................................3
4. Security considerations......................................3
Acknowledgements................................................4
Authors' Addresses..............................................4
Carpenter & Rekhter Expires February 1996 [Page 1]
Internet Draft Renumbering considered unavoidable August 1995
1. Motivation
A need to change IP addressing information associated with various
network components is known as "renumbering". Voluntary renumbering
may occur for a variety of reasons. For example, moving an IP host
from one subnet to another requires changing the host's IP address.
Physically splitting a subnet due to traffic overload may also
require renumbering. A third example where renumbering may happen is
when an organization changes its addressing plan. Such changes imply
changing not only hosts' addresses, but subnet numbers as well.
These are just three examples that illustrate possible scenarios
where voluntary renumbering could occur.
Increasingly, renumbering will be unavoidable and involuntary.
Extended deployment of Classless Inter-Domain Routing (CIDR) is vital
to keep the Internet routing system alive and to maintain continuous
uninterrupted growth of the Internet. With current IP technology,
this requires the vast majority of Internet hosts and subnets to have
addresses belonging to a single large block of address space that has
been allocated to their current service provider. To contain the
growth of routing information, whenever a subscriber changes to a new
service provider, the subscriber's addresses will have to change.
Occasionally, service providers themselves may have to change to a
new and larger block of address space. In either of these cases, to
contain the growth of routing information the subscribers concerned
must renumber their subnet(s) and host(s). If the subscriber does
not renumber, the subscriber may be faced with either (a) limited
(less than Internet-wide) IP connectivity, or (b) extra cost to
offset the overhead associated with the subscriber's routing
information that Internet Services Providers have to maintain, or
both.
Currently, renumbering is usually a costly, tedious and error-prone
process. It usually requires the services of experts in the area and
considerable advance planning. Tools to facilitate renumbering are
few, not widely available, and not widely deployed. While a variety
of ad hoc approaches to renumbering have been developed and used, the
overall situation is far from satisfactory. There is little or no
documentation that describes renumbering procedures. While
renumbering occurs in various parts of the Internet, there is little
or no documented experience sharing.
2. DNS versus IP Addresses
Within the Internet architecture an individual host can be identified
by the IP address(es) assigned to the network interface(s) on that
host. The Domain Name System (DNS) provides a convenient way to
associate legible names with IP addresses. The DNS name space is
independent of the IP address space. DNS names are related to the
ownership and function of the hosts, not to the mechanisms of
addressing and routing. A change in DNS name is generally a sign of
a real change in function, whereas a change in IP address is a purely
technical event.
Carpenter & Rekhter Expires February 1996 [Page 2]
Internet Draft Renumbering considered unavoidable August 1995
Expressing the information in terms of Domain Names allows one to
defer binding between a particular network entity and its IP address
until run time. Since Domain Names names are expected to be fairly
long-lived, and more stable than IP addresses, deferring the binding
avoids the risk of changed mapping between IP addresses and specific
network entities (due to changing addressing information). Moreover,
reliance on Fully Qualified Domain Names (rather than IP addresses)
also localizes to the DNS the changes needed to deal with changing
addressing information due to renumbering.
3. Recommendations
The development and deployment of a toolkit that could facilitate and
automate host renumbering is essential. The Dynamic Host
Configuration Protocol (DHCP) is clearly an essential part of such a
tool kit. The IAB strongly encourages implementation and wide-scale
deployment of DHCP. Support for dynamic update capabilities to the
Domain Name System (DNS) that could be done with sufficient
authentication would further facilitate host renumbering. The IAB
strongly encourages progression of work in this area towards
standardization within the IETF, with the goal of integrating DHCP
and dynamic update capabilities to provide truly autoconfigurable
TCP/IP hosts.
The IAB strongly recommends that all designs and implementations
should minimise the cases in which IP addresses are stored in non-
volatile storage maintained by humans, such as configuration files.
Configuration information used by TCP/IP protocols should be
expressed, whenever possible, in terms of Fully Qualified Domain
Names, rather than IP addresses. Hardcoding IP addresses into
applications should be deprecated. Files containing lists of name to
address mappings, other than that used as part of DNS configuration,
should be deprecated, and avoided wherever possible.
The IAB strongly encourages sharing of experience with renumbering
and documenting this sharing within the Internet community. The IAB
suggests that the IETF (and specifically its Operational Area) may be
the most appropriate place to develop such documentation. The IAB
welcomes the decision of the CIDRD working group to document existing
methods of renumbering.
4. Security considerations
Renumbering is compatible with the Internet security architecture.
Carpenter & Rekhter Expires February 1996 [Page 3]
Internet Draft Renumbering considered unavoidable August 1995
Acknowledgements
This document is a collective product of the Internet Architecture
Board.
Authors' Addresses
Brian E. Carpenter
Group Leader, Communications Systems Phone: +41 22 767-4967
Computing and Networks Division Fax: +41 22 767-7155
CERN Telex: 419000 cer ch
European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch
1211 Geneva 23, Switzerland
Yakov Rekhter
cisco Systems
170 West Tasman Drive
San Jose, CA 95134
Phone: (914) 528-0090
EMail: yakov@cisco.com
Carpenter & Rekhter Expires February 1996 [Page 4]