Build the Next-Generation Data Center
6 week online course starting in spring 2017

IPv6 Renumbering – Mission Impossible?

In one of the discussions on v6ops mailing list Matthew Petach wrote:

The probability of us figuring out how to scale the routing table to handle 40 billion prefixes is orders of magnitude more likely than solving the headaches associated with dynamic host renumbering. That ship has done gone and sailed, hit the proverbial iceberg, and is gathering barnacles at the bottom of the ocean.

Is it really that bad? Is simple renumbering in IPv6 world just another myth? It depends.

Renumbering is trivial in most residential environments: get a new delegated prefix from the old or new ISP using IA_PD, slice-and-dice it, assign it to local LANs, and use SLAAC to renumber the hosts. You should be able to automate the whole process on router operating systems that were built by people who actually understand IPv6 (Cisco IOS comes close, but didn’t have configurable LAN-side prefix lifetime for delegated prefixes the last time I checked its behavior).

Also, the IETF Homenet working group is making sure the incredibly complex home environments built by über-geeks could be seamlessly patched together, operated and renumbered using an incredibly complex set of protocols.

Enterprise environment is a totally different beast – renumbering the network is the least of your problems; there are DNS zones, firewalls, ACLs, application configuration files, static IP addresses required for whatever odd reason (see RFC 6866 for more details), and IP addresses embedded in source code. Most people (who care enough about their enterprise networks to think about the impact of IPv6) consider it Mission Impossible and go for PI address space or even become a Local Internet Registry (LIR) to get their own chunk of IPv6 universe.

Some people within IETF tried to find reasonable solutions that wouldn’t explode the global BGP table the way ubiquitous IPv6 PI space will (even though some vocal IPv6 gurus still live in denial and claim nothing will go wrong with the global BGP table), resulting in RFC 6879, which recommends:

  • Enterprise-wide IA_PD-based prefix delegation. Good recommendation, but it makes the whole enterprise addressing dynamic and dependent on proper operation of DHCPv6 – something many enterprise network architects would be extremely reluctant to do.
  • Usage of FQDN. Good luck with this one. Anyone who has to argue with application owners who claim they need live vMotion across the continent because they cannot possibly understand how to use DNS knows how hopeless this is.
  • Use of parametrized address configuration. Yeah, sure. Cisco IOS ipv6 prefix configuration command is the only one I’m aware of (please fix my ignorance by writing a comment explaining how other vendors do it – and I don’t consider Junos configuration-search-and-replace to be a solution). The only way to solve this might be to use an Ansible-like tool to generate network device configurations.
  • Use of ULA addresses. Another good recommendation (until you encounter ULA-haters).
  • Reduce DNS and RA timers. Definitely a good one – but you might need network automation tool (or automatic configuration deployment) to ensure you get all the instances of RA timers (and hope that they’re configurable on all L3 devices in your network).

For an even gloomier picture, read RFC 7010 which has a long list of missing functionality that would make IPv6 renumbering in an enterprise network as easy as it is in residential environment.

More IPv6?

Check out IPv6 resources on ipSpace net (including numerous IPv6 webinars), enjoy the IPv6 presentations on content site, or watch IPv6-Only Data Centers webinar (one of many free webinars available on


  1. A set of tools to prepare configuration to ease renumebering has been proposed in
    Unfortunately, I'm not aware of any vendor/operator who has adopted this kind of solutions

  2. I do second the view "DNS is the way to go", though there are a few obstacles, which do require careful software engineering.

    For client applications, software infrastructure often gives poor defaults to developers. E.g. when using a security manager, Java defaults to an infinite DNS-cache-timeout: changed DNS-records won't be recognized by a running application. One answer: reconfigure Java's cache-timeout to a few seconds, add a DNS resolver on loopback and let this resolver implement handling of DNS-TTLs correctly. If your DNS server can handle up to a thousandfold of requests (when moving from 24h-TTLs to sub-minute-TTLs), you may also avoid the loopback resolver.

    For server applications, the situation isn't that shiny as well; if a software is asked to listen on the IP address of some FQDN, it will most likely resolve this record on startup only, bind to ip/port and drop (root) privileges. If the DNS-record changes, it may sound reasonable to temporarily listen on both old and new IP - but doing so requires the application to listen to multiple IPs at the same time (not everybody can do this) or requires just those dropped privileges, and depending on the actual implementation and reason for the DNS change, this could result in inconsistent behaviour to clients or similar issues. It is still doable (proxies, port forwarders, specific application code, ...), though this is a lot harder than "just change DNS".


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.