RFC 1900

RFC 1900: Renumbering Needs Work 🎀

okay bestie, quick tea on the paperwork first ✨ this is RFC 1900, titled "Renumbering Needs Work." It's by B. Carpenter and Y. Rekhter, with IAB listed as the author affiliation. The category is Informational and the date is February 1996. It's filed under the Network Working Group 📮 It doesn't list any RFCs it obsoletes or updates 💅 The authors' contact details are down at the bottom 🫶

---

Status of This Memo

bestie, this memo is just info for the Internet community 📚 It does not specify an Internet standard of any kind 🙅 and distribution is unlimited 🦋

Abstract

so renumbering (aka changes to the IP addressing info of various network components) is giving "more and more widespread and common" vibes 📈 The Internet Architecture Board (IAB) really wants everyone to focus on building and shipping solutions that make these changes easier 🔥

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 💖

okay so hosts on an IP network are identified by their IP addresses, and the IP address prefixes of subnets get advertised by routing protocols 🛰️ When that IP addressing info changes for a host or subnet, that's called "renumbering" ✨

renumbering can happen for lots of reasons 🌸 For example, moving an IP host from one subnet to another means the host's IP address has to change. Physically splitting a subnet because of traffic overload may also require renumbering 🚦 A third example is when an organization changes its addressing plan, which means changing not only the hosts' addresses but the subnet numbers as well 🧩 These are just three examples of scenarios where renumbering could occur.

it's giving more and more necessary 😭 Organizations that need Internet-wide IP connectivity, but don't provide a big enough degree of address information aggregation themselves, are going to need renumbering more and more. Until viable alternatives exist, extended deployment of Classless Inter-Domain Routing (CIDR) is vital to keep the Internet routing system alive and to keep the Internet growing without interruption 🌈 With current IP technology, these organizations have to use addresses from a single large block of address space, allocated by their current service provider, which acts as an aggregator for those addresses. To keep the growth of routing information in check, whenever such an organization switches to a new service provider, its addresses will have to change. Sometimes service providers have to move to a new and larger block of address space too 💅 In either case, to keep routing info from blowing up, the organizations involved would need to renumber their subnet(s) and host(s). If the organization doesn't renumber, some possible consequences include (a) limited (less than Internet-wide) IP connectivity, or (b) extra cost to offset the overhead of the organization's routing information that Internet Service Providers have to maintain, or both 💀

renumbering is currently a costly, tedious and error-prone process 😩 It normally needs experts in the area and a lot of advance planning. Tools to make renumbering easier are few, not widely available, and not widely deployed. There have been plenty of ad hoc approaches to renumbering, and people have used them, but the overall situation is far from satisfactory 🙈 There is little or no documentation describing renumbering procedures. Renumbering happens all over the Internet, but 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 its network interface(s) 🖥️ The Domain Name System (DNS) gives us a convenient way to link readable names with IP addresses. The DNS name space is independent of the IP address space. DNS names are usually tied to who owns a host and what it does, not to the mechanics of addressing and routing 🧠 A change in DNS name might mean a real change in function or ownership, whereas a change in IP address is a purely technical event 🤓

using domain names lets you defer binding a particular network entity to 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 a changed mapping between IP addresses and specific network entities (because the addressing info changed). Also, relying on FQDNs (rather than IP addresses) keeps the changes needed to handle renumbering localized to the DNS 🎀

in some cases, both the addresses and FQDNs of desktop or portable systems are allocated dynamically. Only a highly responsive dynamic DNS update mechanism can keep up with that 🏃‍♀️💨

3. Recommendations 🌟

okay this is the part where the IAB gives its advice, and it's a whole vibe 🫶 To make renumbering more feasible, the IAB strongly recommends that all designs and implementations minimise the cases where IP addresses are stored in non-volatile storage maintained by humans, like configuration files 📝 Configuration info 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 the one used as part of DNS configuration) should be deprecated too, and avoided wherever possible 🚫

sometimes legacy applications need configuration files with IP addresses instead of domain names, and they can't be upgraded to meet these recommendations 🙃 In those cases, it is recommended that the configuration files be generated automatically from another file that uses domain names, with the addresses substituted by a lookup in the DNS 🪄

⚠️ bestie, using licensing technology based on a host's IP address makes renumbering quite difficult. So the use of that tech should be strongly discouraged 🙅‍♀️

the development and deployment of a toolkit that makes host renumbering easier and automated is essential 🧰 The Dynamic Host Configuration Protocol (DHCP) is clearly an essential part of that toolkit 💖 The IAB strongly encourages implementing and deploying DHCP at wide scale. Dynamic router discovery (RFC 1256) and service location (work in progress in the IETF) also belong in this toolkit ✨ Support for dynamic update capabilities in the Domain Name System (DNS), if it can be done with sufficient authentication, would help host renumbering even more 🔐 The IAB strongly encourages progress on this work toward standardization within the IETF, with the goal of integrating DHCP and dynamic DNS update capabilities to get truly autoconfigurable TCP/IP hosts 🤖👑

the IAB also strongly encourages sharing experience with renumbering and documenting it within the Internet community 📖 The IAB suggests that the IETF (and specifically its Operational Requirements Area) may be the most appropriate place to develop that 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 don't change during the lifetime of a security association 🛡️ it's giving "don't touch the addresses mid-association" 😤

Acknowledgements 🫶

this document is a collective product of the Internet Architecture Board 🌸

useful comments came in from several people, especially Michael Patton, Steve Bellovin, Jeff Schiller, and Bill Simpson. Thank you, besties 💜

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