TTR Networks

Intermediate · IPv6 on the Debian router · section 5 of 7

When the prefix changes

✓ Lab-tested 5 November 2026 on Debian 13.7, systemd 257, nftables 1.1.3, Kea 2.6.3

Many ISPs give out a new prefix when the router reconnects. With a delegated prefix, that renumbers the whole office, and the router copes with it automatically, mostly.

In the lab, the ISP's server is switched to a different pool, and the router reconnects with networkctl reconfigure eth0. Within seconds:

  • The router gets 2001:db8:cd00::/56, and every VLAN moves to its new /64 (2001:db8:cd00:10::1 for staff).
  • The router announces the new prefix, and the staff PC builds a new address from it. New connections use it: the web server logs the new address.

But the old address is still there, still valid for about an hour and still preferred. The router stopped announcing the old prefix, but didn't tell the devices to stop using it. Until it expires, a device may choose the old address for a new connection, and if the ISP no longer routes the old prefix, that connection fails. This is known as flash renumbering, and it's a real annoyance with IPv6 ISPs that change prefixes.

What helps:

  • Ask the ISP for a static prefix. Many business services include one, and it's also what you want for anything with a fixed address (servers, firewall rules, DNS records).
  • Keep lifetimes short, so stale addresses expire quickly.
  • Don't hard-code delegated addresses anywhere: use DNS names, and firewall rules by interface (as this router does), not by address.
A new prefix from the ISP (real output)
root@router:~# networkctl reconfigure eth0 && sleep 5 && journalctl -u systemd-networkd --no-pager -o cat | grep "delegated prefix" | tail -2; ip -6 -br addr show staff
eth0: DHCP: received delegated prefix 2001:db8:ab00:500::/56
eth0: DHCP: received delegated prefix 2001:db8:cd00::/56
staff@eth1       UP             2001:db8:cd00:10::1/64 metric 256 fe80::ff:fe00:101/64 

root@staff:~# ip -6 addr show dev eth0.10 scope global | grep -E "inet6|lft"
    inet6 2001:db8:cd00:10:0:ff:fe00:1020/64 scope global dynamic mngtmpaddr proto kernel_ra 
       valid_lft 3594sec preferred_lft 1794sec
    inet6 2001:db8:ab00:510:0:ff:fe00:1020/64 scope global dynamic mngtmpaddr proto kernel_ra 
       valid_lft 3561sec preferred_lft 1761sec

root@staff:~# curl -6 -s -o /dev/null -w "%{http_code}\n" -m 2 "http://[2001:db8:e::10]/"
200

root@web:~# tail -1 /tmp/web.log
2001:db8:cd00:10:0:ff:fe00:1020 - - [04/Nov/2026 22:16:10] "GET / HTTP/1.1" 200 -
  • Lines 2–3: The old prefix, then the new one after the reconnect.
  • Line 4: Staff's VLAN moved to the new /64 straight away.
  • Lines 7–8: The PC's new address…
  • Lines 9–10: …and its old one, still valid and still preferred.
  • Lines 12–16: New connections use the new address.

Check your understanding

After the prefix changed, the staff PC still had its old address as preferred. Why is that a problem?

  • It may use the old address for new connections, which fail if the ISP no longer routes that prefix.
  • Two addresses on one interface aren't allowed in IPv6.
  • It stops the PC getting the new address.
  • The router will drop all its traffic.