home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1900s / rfc1900.txt next >
Text File  |  1996-02-21  |  10KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       B. Carpenter
  8. Request for Comments: 1900                                    Y. Rekhter
  9. Category: Informational                                              IAB
  10.                                                            February 1996
  11.  
  12.  
  13.                          Renumbering Needs Work
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    Renumbering, i.e., changes in the IP addressing information of
  24.    various network components, is likely to become more and more
  25.    widespread and common. The Internet Architecture Board (IAB) would
  26.    like to stress the need to develop and deploy solutions that would
  27.    facilitate such changes.
  28.  
  29. Table of Contents
  30.  
  31.    1. Motivation................................................... 1
  32.    2. DNS versus IP Addresses...................................... 2
  33.    3. Recommendations.............................................. 3
  34.    4. Security Considerations...................................... 4
  35.    Acknowledgements................................................ 4
  36.    Authors' Addresses.............................................. 4
  37.  
  38. 1. Motivation
  39.  
  40.    Hosts in an IP network are identified by IP addresses, and the IP
  41.    address prefixes of subnets are advertised by routing protocols.  A
  42.    change in such IP addressing information associated with a host or
  43.    subnet is known as "renumbering".
  44.  
  45.    Renumbering may occur for a variety of reasons.  For example, moving
  46.    an IP host from one subnet to another requires changing the host's IP
  47.    address.  Physically splitting a subnet due to traffic overload may
  48.    also require renumbering.  A third example where renumbering may
  49.    happen is when an organization changes its addressing plan.  Such
  50.    changes imply changing not only hosts' addresses, but subnet numbers
  51.    as well.  These are just three examples that illustrate possible
  52.    scenarios where renumbering could occur.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Carpenter & Rekhter          Informational                      [Page 1]
  59.  
  60. RFC 1900                 Renumbering Needs Work            February 1996
  61.  
  62.  
  63.    Increasingly, renumbering will be needed for organizations that
  64.    require Internet-wide IP connectivity, but do not themselves provide
  65.    a sufficient degree of address information aggregation.  Unless and
  66.    until viable alternatives are developed, extended deployment of
  67.    Classless Inter-Domain Routing (CIDR) is vital to keep the Internet
  68.    routing system alive and to maintain continuous uninterrupted growth
  69.    of the Internet.  With current IP technology, this requires such
  70.    organizations to use addresses belonging to a single large block of
  71.    address space, allocated to their current service provider which acts
  72.    as an aggregator for these addresses.  To contain the growth of
  73.    routing information, whenever such an organization changes to a new
  74.    service provider, the organization's addresses will have to change.
  75.    Occasionally, service providers themselves may have to change to a
  76.    new and larger block of address space. In either of these cases, to
  77.    contain the growth of routing information, the organizations
  78.    concerned would need to renumber their subnet(s) and host(s). If the
  79.    organization does not renumber, then some of the potential
  80.    consequences may include (a) limited (less than Internet-wide) IP
  81.    connectivity, or (b) extra cost to offset the overhead associated
  82.    with the organization's routing information that Internet Service
  83.    Providers have to maintain, or both.
  84.  
  85.    Currently, renumbering is usually a costly, tedious and error-prone
  86.    process.  It normally requires the services of experts in the area
  87.    and considerable advance planning.  Tools to facilitate renumbering
  88.    are few, not widely available, and not widely deployed. While a
  89.    variety of ad hoc approaches to renumbering have been developed and
  90.    used, the overall situation is far from satisfactory.  There is
  91.    little or no documentation that describes renumbering procedures.
  92.    While renumbering occurs in various parts of the Internet, there is
  93.    little or no documented experience sharing.
  94.  
  95. 2. DNS versus IP Addresses
  96.  
  97.    Within the Internet architecture an individual host can be identified
  98.    by the IP address(es) assigned to the network interface(s) on that
  99.    host.  The Domain Name System (DNS) provides a convenient way to
  100.    associate legible names with IP addresses.  The DNS name space is
  101.    independent of the IP address space.  DNS names are usually related
  102.    to the ownership and function of the hosts, not to the mechanisms of
  103.    addressing and routing.  A change in DNS name may be a sign of a real
  104.    change in function or ownership, whereas a change in IP address is a
  105.    purely technical event.
  106.  
  107.    Expressing information in terms of Domain Names allows one to defer
  108.    binding between a particular network entity and its IP address until
  109.    run time. Domain Names for enterprises, and Fully Qualified Domain
  110.    Names (FQDNs, see RFC 1594) for servers and many user systems, are
  111.  
  112.  
  113.  
  114. Carpenter & Rekhter          Informational                      [Page 2]
  115.  
  116. RFC 1900                 Renumbering Needs Work            February 1996
  117.  
  118.  
  119.    expected to be fairly long-lived, and more stable than IP addresses.
  120.    Deferring the binding avoids the risk of changed mapping between IP
  121.    addresses and specific network entities (due to changing addressing
  122.    information).  Moreover, reliance on FQDNs (rather than IP addresses)
  123.    also localizes to the DNS the changes needed to deal with changing
  124.    addressing information due to renumbering.
  125.  
  126.    In some cases, both the addresses and FQDNs of desk top or portable
  127.    systems are allocated dynamically. It is only a highly responsive
  128.    dynamic DNS update mechanism that can cope with this.
  129.  
  130. 3. Recommendations
  131.  
  132.    To make renumbering more feasible, the IAB strongly recommends that
  133.    all designs and implementations should minimise the cases in which IP
  134.    addresses are stored in non-volatile storage maintained by humans,
  135.    such as configuration files.  Configuration information used by
  136.    TCP/IP protocols should be expressed, whenever possible, in terms of
  137.    Fully Qualified Domain Names, rather than IP addresses. Hardcoding IP
  138.    addresses into applications should be deprecated.  Files containing
  139.    lists of name to address mappings, other than that used as part of
  140.    DNS configuration, should be deprecated, and avoided wherever
  141.    possible.
  142.  
  143.    There are times when legacy applications which require configuration
  144.    files with IP addresses rather than Domain Names cannot be upgraded
  145.    to meet these recommendations. In those cases, it is recommended that
  146.    the configuration files be generated automatically from another file
  147.    which uses Domain Names, with the substitution of addresses being
  148.    done by lookup in the DNS.
  149.  
  150.    Use of licensing technology that is based upon the IP address of a
  151.    host system makes renumbering quite difficult. Therefore, the use of
  152.    such technology should be strongly discouraged.
  153.  
  154.    The development and deployment of a toolkit to facilitate and
  155.    automate host renumbering is essential.  The Dynamic Host
  156.    Configuration Protocol (DHCP) is clearly an essential part of such a
  157.    toolkit.  The IAB strongly encourages implementation and wide-scale
  158.    deployment of DHCP.  Dynamic router discovery (RFC 1256) and service
  159.    location (work in progress in the IETF) also belong in this toolkit.
  160.    Support for dynamic update capabilities to the Domain Name System
  161.    (DNS) that could be done with sufficient authentication would further
  162.    facilitate host renumbering.  The IAB strongly encourages progression
  163.    of work in this area towards standardization within the IETF, with
  164.    the goal of integrating DHCP and dynamic update capabilities to
  165.    provide truly autoconfigurable TCP/IP hosts.
  166.  
  167.  
  168.  
  169.  
  170. Carpenter & Rekhter          Informational                      [Page 3]
  171.  
  172. RFC 1900                 Renumbering Needs Work            February 1996
  173.  
  174.  
  175.    The IAB strongly encourages sharing of experience with renumbering
  176.    and documenting this sharing within the Internet community.  The IAB
  177.    suggests that the IETF (and specifically its Operational Requirements
  178.    Area) may be the most appropriate place to develop such
  179.    documentation.  The IAB welcomes the creation of the PIER (Procedures
  180.    for Internet and Enterprise Renumbering) working group.
  181.  
  182. 4. Security Considerations
  183.  
  184.    Renumbering is believed to be compatible with the Internet security
  185.    architecture, as long as addresses do not change during the lifetime
  186.    of a security association.
  187.  
  188. Acknowledgements
  189.  
  190.    This document is a collective product of the Internet Architecture
  191.    Board.
  192.  
  193.    Useful comments were received from several people, especially Michael
  194.    Patton, Steve Bellovin, Jeff Schiller, and Bill Simpson.
  195.  
  196. Authors' Addresses
  197.  
  198.    Brian E. Carpenter
  199.    Group Leader, Communications Systems
  200.    Computing and Networks Division
  201.    CERN
  202.    European Laboratory for Particle Physics
  203.    1211 Geneva 23, Switzerland
  204.  
  205.    Phone:  +41 22 767-4967
  206.    Fax:    +41 22 767-7155
  207.    Telex:  419000 cer ch
  208.    EMail: brian@dxcoms.cern.ch
  209.  
  210.  
  211.    Yakov Rekhter
  212.    cisco Systems
  213.    170 West Tasman Drive
  214.    San Jose, CA 95134
  215.  
  216.    Phone: (914) 528-0090
  217.    EMail: yakov@cisco.com
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Carpenter & Rekhter          Informational                      [Page 4]
  227.  
  228.