Summary

  • RFC 1900 separated the authority to change an IP address from the ability to discover and update every system that referred to it. Provider aggregation could require renumbering, but the resulting work extended far beyond the allocation record.
  • Domain names reduced the number of embedded addresses by postponing the name-to-address binding until use. They did not prove that caches expired, applications resolved again, ACLs changed, reverse DNS followed or another administrator updated a dependent system.
  • Later renumbering RFCs turned the warning into an inventory problem spanning routers, DNS, DHCP, security associations, management tools, application APIs and scattered configuration. Completion therefore required joined operational evidence, not a new prefix alone.

A change order could not see its own dependencies

RFC 1900 began with ordinary reasons for an address to move. A host could change subnets. An overloaded subnet could be split. An organisation could redesign its addressing plan. The more consequential case came from the public routing system. CIDR aggregation allowed a provider to advertise one large block instead of many customer routes. If a customer left that provider, retaining a more-specific piece of the old aggregate could impose routing state on the wider Internet. Renumbering traded local work for global aggregation.

That trade did not give the provider a command capable of completing the move. It could allocate a new prefix and stop carrying the old one. The customer could change interface addresses and routes. Neither actor automatically knew that an engineer had typed the old address into a firewall rule, a monitoring target, a printer profile, a licence file or a partner's allowlist years earlier.

This is the control surface hidden inside the word renumbering. The decision is compact; the dependency graph is not. An allocation record says which number may be used. A route says where a prefix is advertised. A device configuration says what one system will do. An application result says whether a particular exchange worked. These records are related, but none contains the others.

RFC 1900 described the contemporary process as costly, tedious and error-prone. It also said tools and documented experience were scarce. That was not merely a complaint about immature software. It identified a knowledge problem: operators could not update a reference they could not find, and no address authority possessed a complete index of references created by independent systems.

DNS moved a binding; it did not move every believer

The document's most durable proposal was to distinguish a name from an address. The DNS namespace was independent of the address space. A name usually followed a host's function or organisational identity; an address located an interface within an addressing and routing structure. If configuration stored the name, resolution could bind that name to the current address at run time. A mapping change could then be concentrated in DNS instead of copied into every file.

That was a reduction in coupling, not the abolition of state. The DNS operator controlled the authoritative record. A recursive resolver controlled cached answers until their applicable lifetimes ended. An application decided whether to resolve again or retain yesterday's answer. Reverse DNS could belong to a provider. A security product could turn the result into an ACL that needed its own staged update. A partner could have copied the resolved address into a system the renumbering organisation could not inspect.

RFC 1900 itself preserved this boundary. Dynamically allocated names and addresses required responsive dynamic DNS updates. Authenticated update work was still developing. Legacy software that accepted only address literals could not be made name-aware by declaration, so the RFC recommended generating its address-bearing file automatically from a name-based source. The authoritative input would contain a name; a controlled lookup would produce the unavoidable literal.

The recommendation against IP-bound licensing exposed the same issue in commercial form. A licence that treated an address as machine identity converted a routing coordinate into a lock. The address authority could change the coordinate, but only the licensor could change the acceptance rule. Technical renumbering and permission to keep using the software became separate transactions.

The later guides turned one number into an inventory

RFC 2071, published the following year, made the work visible. Renumbering could touch PCs, workstations, printers, file servers, terminal servers and routers. It could require changes to DNS-server settings, SNMP management stations and access-control lists. Old and new addresses might coexist during a provider-granted grace period, but coexistence did not identify what had been missed.

RFC 2072 expanded the router side into a planning discipline. Address structure reached default and static routes, interior routing, BGP, tunnels, filters, management systems, name services, accounting and security controls. The breadth matters more than any one command. A route-policy owner, a DNS administrator and an application operator could each complete their part while the service still failed at the boundary between them.

IPv6 later supplied a cleaner overlap procedure. RFC 4192 described adding a new prefix, allowing both prefixes to operate, shifting use and then removing the old one. It coordinated interface changes with DNS and used TTLs to manage propagation. Yet the RFC still found work that resisted automation across administrative domains, particularly DNS configuration and reverse-zone trust. It warned that an occasionally used device might escape notice until after the old prefix disappeared.

The overlap is useful because it creates an observation period. It is not proof of completeness. A silent device, a monthly job or an external allowlist may not exercise its dependency while both prefixes work. The later removal is the test, but discovering the missing reference only through failure is not the same as controlling the migration.

Fourteen years later, the title acquired one extra word

RFC 5887 was called Renumbering Still Needs Work. By 2010, DHCP, IPv6 autoconfiguration, DNS tooling and management practice had advanced. The remaining failures nevertheless followed RFC 1900's original boundary.

A site with strong asset management could regenerate DHCP and DNS inputs from a controlled database. A site with weak asset management could edit them by hand and wait through confusion. One fixed, manually configured host could defeat complete automation. An embedded system might hold its address in read-only memory or even physical switches.

Applications added a less visible class of state. RFC 5887 cited a review that found explicit address dependencies in 34 of 257 Standards-Track or Experimental application-protocol RFCs. That count described the specifications examined, not all software. The more difficult point was that specification review could not reveal whether an implementation cached an address indefinitely, wrote it to private storage or bound a licence, URL, cookie or proxy setting to it.

Even using a domain name was insufficient when an application resolved it once at startup and never respected the DNS lifetime. Socket interfaces encouraged programs to receive and manipulate lower-layer addresses without an accompanying validity period. Some applications retried, repeated lookups or used alternatives correctly; others did not. Security could deliberately complicate the cure: DNS pinning limited address changes to resist browser attacks, preserving stale bindings for a protective reason.

RFC 6879 recommended FQDNs, service discovery, parameterised configuration and systematic DNS procedures. RFC 7010 divided automation into prefix management, address configuration, updates to address-relevant entries and event coordination. It still found no one-stop mechanism able to update every subsystem and external database. It noted that log collectors might treat a new source address as a new device unless they received the old-to-new mapping. An address had become an accidental identifier in yet another system.

A completed renumbering is a joined claim

The allocation decision proves that a new coordinate is available. Interface and routing records prove that particular systems can use it. DNS evidence proves that specified forward or reverse mappings changed. Configuration evidence proves that a known reference was replaced. Application tests prove chosen transactions at chosen times. External confirmations prove that named counterparties updated their own controls. Withdrawal observations prove that the old route or address is no longer serving an intended path.

No single receipt proves the set is complete. The practical standard is an inventory with owners, timestamps and negative evidence: searches that find no remaining literal in controlled repositories; telemetry that shows no required traffic using the old address during a justified observation window; tests from independent paths; and explicit treatment of systems that are normally silent.

This does not make the old address permanent. Nor does the cost of leaving convert a provider-dependent prefix into an unconditional right to keep it. It means the authority to require a move and the capacity to execute it belong to different actors. A resilient system exposes that split before a provider change, merger or topology decision turns it into an emergency.

RFC 1900's lasting insight was not that names are good and numbers are bad. It was that a coordinate becomes dangerous when software, policy and memory quietly promote it into identity. Changing the number is an administrative act. Finding everything that believed the number is what makes renumbering engineering.

Sources