Your ISP keeps moving your IPv6 prefix. Your network pays for it.
IPv6 was designed on the assumption that a site receives a prefix and keeps it. A growing number of residential and small-business ISPs break that assumption: they hand out a dynamic prefix delegation (PD) and rotate it — sometimes every few hours. Each rotation renumbers everything downstream of it.
If your internal addressing is built on the delegated prefix, every rotation ripples through the whole network: router advertisements, firewall rules that reference internal prefixes, DNS records, inter-VLAN ACLs, static service addresses, monitoring. You either build machinery to cascade every renumber through every layer, or you fix it by hand — repeatedly, forever.
The goal
A stable, first-class internal address plan that does not move when the ISP’s prefix does — without giving up native IPv6 address selection, and without the operational tax of a renumber cascade.
There are three ways to approach this. Two are the usual answers, and each carries a cost that is easy to miss until you are living with it. The third spends a resource IPv6 made abundant — address space — to buy back the stability the ISP took away. The next tab lays out all three, honestly, including where each one is the right call.
This site documents a technique and offers one worked example of it. It is free, and the example block is available to anyone whether or not they ever contact the author. Nothing here is a product or a service.
Three ways to hold a stable internal plan
None of these is “wrong.” They trade different things. Read the one that fits your situation — and if your ISP gives you a stable prefix, you may not need any of them.
1 · Propagate the PD through IPv6 tooling
Take the delegated prefix natively and let DHCPv6-PD, prefix hints, and dynamic reconfiguration cascade each renumber through your hierarchy. This is the “do it the way IPv6 intended” answer.
The cost: your entire internal plan is numbered out of a moving prefix, so every rotation touches RAs, DNS, ACLs, and static services. It works best when the prefix rotates rarely; it becomes a treadmill when it rotates often.
2 · Use ULA for the internal plan
Number your internal network out of a Unique Local Address block (fc00::/7). It is stable by definition
and never depends on the ISP. This is the textbook answer to prefix instability.
The cost: RFC 6724 ranks ULA below IPv4 in default address selection. On a dual-stack host, ULA source/destination selection quietly prefers IPv4 — a second-class-citizen penalty you pay silently, per host, unless you maintain a policy-table override everywhere.
3 · Use non-routed GUA behind NPTv6
Number your internal network out of global unicast (GUA) space that is deliberately never routed, and translate it to the ISP’s prefix at your boundary with NPTv6 (RFC 6296, stateless 1:1 prefix translation). Internally you get first-class, stable addressing; the ISP’s churn is contained at a single translation boundary instead of flooding the whole hierarchy.
The catch: you need GUA space you control that is assuredly never routed. Most people don’t have their own allocation to draw from — which is what this site’s worked example is for. See The Block.
A safe, assuredly-dark GUA block you can use
To make approach 3 available to people without their own allocation, one /48 of provider-independent GUA space is set aside and held permanently unrouted. You may number your internal network out of it, translate at your boundary with NPTv6, and get the benefits of GUA-shaped addressing without owning an allocation.
What you get
- First-class address selection. GUA-shaped space sits above IPv4 in RFC 6724, so dual-stack hosts don’t suffer ULA’s silent IPv4 preference — no per-host policy override needed.
- Stable internal plan. Your addressing never moves when the ISP’s prefix rotates. The churn is absorbed at one NPTv6 boundary, not across your whole hierarchy.
- Fails safe. An AS0 ROA plus origin blackhole mean an accidental leak of this prefix is dropped by RPKI-validating networks rather than carried — insurance over your own NPTv6 discipline.
- Nothing to apply for. The block is a published fact. Use it or don’t; no registration, no account, no permission.
What you must know
- Translate at your boundary. This space must never leave your network un-translated. Always NPTv6 it at the edge; never route it to your ISP.
- “Assuredly dark” has an edge. The AS0 ROA makes this prefix invalid on any RPKI-validating path, and the global return table plus the origin blackhole cover the rest. The one gap is traffic that both starts and ends inside a single non-validating network — a gap that exists for all address space, not just this block. Your NPTv6 discipline is the backstop; keep it.
- It is single-homed to one maintainer. The block stays dark as long as it is maintained that way. Deploy so that if it ever stopped being maintained, you would lose insurance, not connectivity: because you translate at the boundary and never route it, its disappearance costs you the safety net, not your working internal plan.
- Best-effort, not guaranteed. This is offered in good faith as a resource to share, not as a service or a warranty. Read the full method for the complete deployment and its limits.
If it helped
This convention is free, and it always will be. The block above works whether or not you ever send a cent — payment gates nothing and grants nothing. If it saved you a headache and you’d like to say thanks, that’s the only thing these are for:
Gratitude only. Not a subscription for access, not a fee for the space, not owed by anyone.