RFC 5887 is a rare beast: an Informational RFC whose title is essentially a lament. Twenty-five years after the IETF first promised that IPv6 would make renumbering "easy," Brian Carpenter and his co-authors sat down and admitted, in polite RFC-ese, that it still wasn't. The document catalogs, honestly and exhaustively, why swapping one prefix for another in a real production network is a nightmare — and why that nightmare has architectural roots we've never truly fixed.

The original promise. When IPv6 was designed in the 1990s, one of its selling points was "provider-independent" behavior via renumbering. If your ISP changed, or you wanted to switch providers, you'd just deprecate the old prefix, advertise the new one via Router Advertisements, and hosts would gracefully transition using SLAAC's preferred/deprecated lifetime machinery (RFC 4862). Combined with DNS, this was supposed to eliminate the need for provider-independent address space and the routing-table bloat it causes. Renumbering was going to be a feature.

What actually happens. RFC 5887 walks through the reality. Renumbering touches almost every layer of a real deployment:

• Hard-coded addresses. Firewall ACLs, VPN endpoint configurations, RADIUS clients, SNMP trap destinations, NTP peers, syslog collectors, monitoring probes, license servers — all frequently contain literal IP addresses rather than names.
• DNS asymmetry. Forward DNS is usually managed centrally, but reverse DNS (ip6.arpa) is delegated by the address holder — the ISP. Renumbering means re-delegating, which needs ISP cooperation and coordinated TTL management that rarely happens cleanly.
• Long-lived sessions. TCP connections, IPsec SAs, and application sessions are bound to specific address pairs. Deprecating a prefix breaks them; there is no in-protocol mechanism to migrate them.
• Configuration sprawl. DHCPv6 pools, PIM RPs, OSPF area configs, BGP peer statements, MPLS LSPs, and split-horizon DNS views all reference addresses directly.
• Certificates. X.509 certs with iPAddress SANs (common for management interfaces and some VPNs) need reissuing.
• Logs and forensics. Historical logs suddenly refer to addresses that mean something completely different, or nothing at all.

The architectural point. The authors argue the real culprit is the identifier/locator overload in IP: an address is simultaneously "who you are" and "where you are." Every subsystem that treats an address as identity — ACLs, certs, session state, logs — breaks when the locator changes. Protocols like HIP (RFC 4423, already covered in this series) and LISP were attempts to fix this at the architecture level, but neither has seen mass deployment.

Why it matters in 2026. Almost everything RFC 5887 warned about is still true. Cloud migrations, IPv6 rollouts, mergers/acquisitions, and the ongoing move to zero-trust networking all trip over these issues. The rise of service meshes and overlay networks (Tailscale, WireGuard mesh, Kubernetes CNI) is partly an acknowledgment that we've given up on renumbering the underlay — we just build a stable identifier plane on top of it. Modern SRE playbooks around "cattle not pets" and immutable infrastructure are, in a sense, a workaround: don't renumber servers, just destroy and recreate them.

The quirky footnote. The RFC is refreshingly candid — it explicitly notes that the IETF's earlier claim that "IPv6 renumbering is easy" was overstated. It's one of the more honest pieces of self-criticism in the RFC series, sitting alongside RFC 1958 ("Architectural Principles") as required reading for anyone who wants to understand why the internet's foundations still have load-bearing cracks.