1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc1900.txt b/doc/rfc/rfc1900.txt
new file mode 100644
index 0000000..d1edca1
--- /dev/null
+++ b/doc/rfc/rfc1900.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                       B. Carpenter
+Request for Comments: 1900                                    Y. Rekhter
+Category: Informational                                              IAB
+                                                           February 1996
+
+
+                         Renumbering Needs Work
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   Renumbering, i.e., changes in the IP addressing information of
+   various network components, is likely to become more and more
+   widespread and common. The Internet Architecture Board (IAB) would
+   like to stress the need to develop and deploy solutions that would
+   facilitate such changes.
+
+Table of Contents
+
+   1. Motivation................................................... 1
+   2. DNS versus IP Addresses...................................... 2
+   3. Recommendations.............................................. 3
+   4. Security Considerations...................................... 4
+   Acknowledgements................................................ 4
+   Authors' Addresses.............................................. 4
+
+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".
+
+   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 renumbering could occur.
+
+
+
+
+
+Carpenter & Rekhter          Informational                      [Page 1]
+
+RFC 1900                 Renumbering Needs Work            February 1996
+
+
+   Increasingly, renumbering will be needed for organizations that
+   require Internet-wide IP connectivity, but do not themselves provide
+   a sufficient degree of address information aggregation.  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 such
+   organizations to use addresses belonging to a single large block of
+   address space, allocated to their current service provider which acts
+   as an aggregator for these addresses.  To contain the growth of
+   routing information, whenever such an organization changes to a new
+   service provider, the organization'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 organizations
+   concerned would need to renumber their subnet(s) and host(s). If the
+   organization does not renumber, then some of the potential
+   consequences may include (a) limited (less than Internet-wide) IP
+   connectivity, or (b) extra cost to offset the overhead associated
+   with the organization's routing information that Internet Service
+   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
+   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
+
+
+
+Carpenter & Rekhter          Informational                      [Page 2]
+
+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.
+
+
+
+
+Carpenter & Rekhter          Informational                      [Page 3]
+
+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
+   CERN
+   European Laboratory for Particle Physics
+   1211 Geneva 23, Switzerland
+
+   Phone:  +41 22 767-4967
+   Fax:    +41 22 767-7155
+   Telex:  419000 cer ch
+   EMail: brian@dxcoms.cern.ch
+
+
+   Yakov Rekhter
+   cisco Systems
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   Phone: (914) 528-0090
+   EMail: yakov@cisco.com
+
+
+
+
+
+
+
+
+Carpenter & Rekhter          Informational                      [Page 4]
+