From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1900.txt | 227 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc1900.txt (limited to 'doc/rfc/rfc1900.txt') 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] + -- cgit v1.2.3