[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 1900

IAB                                                         B. Carpenter
Internet Draft                                                Y. Rekhter
October 1995



                         Renumbering Needs Work



                                 Abstract

                          draft-iab-renum-02.txt


   Renumbering, i.e. changes in the IP addressing information of various
   network components, is 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......................................4
      Acknowledgements................................................5
      Authors' Addresses..............................................5












Carpenter & Rekhter       Expires April 1996                    [Page 1]


Internet Draft          Renumbering Needs Work              October 1995


1. Motivation
   Hosts in an IP network are identified by IP addresses, and the IP
   address prefixes of subnets are advertised by routing protocols.  A
   change in such IP addressing information associated with a host or
   subnet 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.
   Unless and until viable alternatives are developed, 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 consequences depend on the exact policy of the
   service provider. They may include 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 normally 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 usually related


Carpenter & Rekhter       Expires April 1996                    [Page 2]


Internet Draft          Renumbering Needs Work              October 1995


   to the ownership and function of the hosts, not to the mechanisms of
   addressing and routing.  A change in DNS name may be a sign of a real
   change in function or ownership, whereas a change in IP address is a
   purely technical event.

   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. Domain Names for enterprises, and Fully Qualified
   Domain Names (FQDNs, see RFC 1594) for servers and many user systems,
   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 FQDNs (rather than IP
   addresses) also localizes to the DNS the changes needed to deal with
   changing addressing information due to renumbering.

   In some cases, both the addresses and FQDNs of desk top or portable
   systems are allocated dynamically. It is only a highly responsive
   dynamic DNS update mechanism that can cope with this.



3. Recommendations

   To make renumbering more feasible, 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.

   There are times when legacy applications which require configuration
   files with IP addresses rather than Domain Names cannot be upgraded
   to meet these recommendations. In those cases, it is recommended that
   the configuration files be generated automatically from another file
   which uses Domain Names, with the substitution of addresses being
   done by lookup in the DNS.

   The development and deployment of a toolkit to facilitate and
   automate host renumbering is essential.  The Dynamic Host
   Configuration Protocol (DHCP) is clearly an essential part of such a
   toolkit.  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 encourages sharing of experience with renumbering


Carpenter & Rekhter       Expires April 1996                    [Page 3]


Internet Draft          Renumbering Needs Work              October 1995


   and documenting this sharing within the Internet community.  The IAB
   suggests that the IETF (and specifically its Operational Requirements
   Area) may be the most appropriate place to develop such
   documentation.  The IAB welcomes the recent proposal to create a PIER
   (Procedures for Internet and Enterprise Renumbering) working group.



4. Security considerations

   Renumbering is believed to be compatible with the Internet security
   architecture, as long as addresses do not change during the lifetime
   of a security association.












































Carpenter & Rekhter       Expires April 1996                    [Page 4]


Internet Draft          Renumbering Needs Work              October 1995


Acknowledgements

   This document is a collective product of the Internet Architecture
   Board.

   Useful comments were received from several people, especially Michael
   Patton and Steve Bellovin.



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 April 1996                    [Page 5]


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