independent of the IP address space.  DNS names are usually related
   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 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




 
RFC 1900                 Renumbering Needs Work            February 1996


   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.

   Use of licensing technology that is based upon the IP address of a
   host system makes renumbering quite difficult. Therefore, the use of
   such technology should be strongly discouraged.

   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.  Dynamic router discovery (RFC 1256) and service
   location (work in progress in the IETF) also belong in this toolkit.
   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.





 
RFC 1900                 Renumbering Needs Work            February 1996


   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 Requirements
   Area) may be the most appropriate place to develop such
   documentation.  The IAB welcomes the creation of the 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.

Acknowledgements

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

   Useful comments were received from several people, especially Michael
   Patton, Steve Bellovin, Jeff Schiller, and Bill Simpson.

Authors' Addresses

   Brian E. Carpenter
   Group Leader, Communications Systems
   Computing and Networks Division