Why IPv6 Keeps Changing Your Devices' Addresses - and the Fix

If your home network runs on IPv6, you may have run into this. Everything works. You can reach the laptop, the storage box, the printer. Then one morning nothing answers, and when you look, every device has a different address than it had last week. Nothing was touched. Nothing is misconfigured. The addresses simply changed.

The usual conclusion is that IPv6 is unpredictable and you should go back to pretending it does not exist. That conclusion is wrong, and it is worth correcting, because the problem is fixable and the fix is not complicated.

Every device on your network has two kinds of address, and only one of them is supposed to be permanent. The job is knowing which one, and stopping your internet provider from moving the other.

Every device has two addresses

Start with the vocabulary, because the jargon is the reason this topic looks harder than it is.

IPv6 is the current version of the addressing system that the internet uses to find devices. SLAAC (Stateless Address Autoconfiguration) is how a device builds its own address without being told what to use. Your router sends out an announcement called a router advertisement, containing the first half of an address, called a prefix. The device supplies the second half itself. Put the two together and you have a working address.

That second half is where the confusion lives, because a modern device does not keep just one.

It keeps a stable address, and it also generates temporary addresses that rotate on a timer. Temporary addresses exist for privacy: when your device starts an outgoing connection, it uses a temporary address, so a website cannot easily recognize the same visitor twice.

This is the part that trips people up. The rotating address is not the one you connect to. The internet standards say this explicitly. As RFC 8981 puts it, a host needs “a stable address associated with the name, which is used to accept incoming connection requests from other hosts, and a temporary address used to shield the identity of the client when it initiates communication.”

Read that again, because it answers the whole question. Temporary addresses are for traffic going out. The stable address is for traffic coming in. If you want to reach a device, you want the stable one, and it does not rotate.

You can see both on any Linux machine. Run ip -6 addr and you will get two kinds of entry: the temporary ones are marked with a short lifetime, and there is a longer-lived one that is not. That longer-lived one (marked ‘forever’ on my machine) is your doorstep.

The address that is moving is not the private one

The next thing worth clearing up is why the stable address sometimes changes anyway.

The second half of the address can be built in a few different ways, and the modern default is called stable privacy (RFC 7217). It is deliberately not derived from the device’s hardware address, so nobody can work out your hardware from your address. What matters here is the word stable: an address built this way stays the same for as long as the prefix does.

So the second half is not the problem. The prefix is the problem. Which means the real culprit is what your internet provider does with your prefix, and that has a name too.

Why the prefix moves: delegation

Your internet provider does not hand you one address. It hands you a whole block, and lets your router carve it up and dole it out. That is called prefix delegation, and it is what makes a proper home IPv6 network possible in the first place.

It is also what breaks it, because the block is not necessarily yours forever. It comes with a lease. When the lease renews, or the provider’s equipment reboots, or the provider simply reorganizes its network, you can be handed a different block. Everything on your network then has to renumber itself, because every address was built from the old prefix.

Your devices are behaving correctly. They are rebuilding their addresses from the prefix you were just given. This is why the problem looks intermittent and mysterious: nothing is broken, your numbering has simply moved, and it can move again next month.

There is also an entirely avoidable version of this. If you wrote your old prefix into a configuration file somewhere, that file is now wrong, and your network will not come back until you update it by hand.

Fix one: give yourself a block the provider cannot touch

If the problem is that someone else controls your prefix, the answer is to have a second prefix that nobody else controls.

The standards provide exactly this. It is called a unique local address range, or ULA (RFC 4193), and it looks like an address beginning fd. It is not reachable from the internet, cannot be routed there, and is not meant to be. It is yours to assign inside your own walls, and it never changes, whatever your provider does with its own block.

The practical setup is small, and it needs no special hardware. Any router that lets you choose what it announces will do. If you are buying a router, that is the setting to check for.

1. Pick a ULA prefix, for example fd12:3456:789a::/64.
2. Announce it in your router advertisements alongside the address block your provider gave you.
3. Your devices pick up both, and quietly end up with a permanent address that never moves.

Then you connect to the ULA address, and you stop caring what your provider does. RFC 4193 has a section titled “Renumbering and Site Merging”, which is a formal way of saying this is precisely the problem it was written to solve.

Fix two: stop using addresses at all

The ULA fix works, but asking yourself to remember a string like fd12:3456:789a::5 is not a good long-term plan. Names are better than numbers, and there are two standard ways to get them.

The first is to tell your router to hand out a name server in its announcements. Rather than typing name servers into every device by hand, the router advertisement itself carries the address of your local name server. This is called RDNSS (RFC 8106), and it exists so that devices which configure themselves automatically still end up able to look names up.

The second is mDNS, the system behind every address ending in .local. Install Avahi on a Linux machine and it will answer to its own name across the network with no configuration at all. Your router does not need to know anything. If you would like to reach a device by name and you have not set up a local DNS server, start here.

Between the two, you stop depending on knowing any address. That is the end state worth aiming for.

Android, and the setting that breaks it

If you have Android devices, there is one trap that will cost you an evening if you do not know about it.

Android does not support the stateful version of DHCPv6. Not as an oversight, and not as something that was fixed later: Google made this a deliberate design decision, and it is still true. Android gets its addresses by SLAAC, which as we said means building its own from a router advertisement.

Most routers can run in two IPv6 modes, and the names are misleading. In managed mode, the router tells devices to get their addresses through DHCPv6. That is the mode that gives you tidy, centrally recorded, predictable addresses, which is why it is tempting. It is also the mode that leaves your Android devices with nothing but a link-local address, which means they cannot talk to anything beyond the local cable and appear to have no internet.

In assisted mode, devices configure themselves by SLAAC and use DHCPv6 only for the extras, such as name servers. That is the mode you want if Android devices are on your network. If you are not sure which modes your router offers, our guide to how a home network fits together is the place to start.

One recent development is worth knowing about so you are not misled by it. Google added DHCPv6 prefix delegation support to Android 11 and later toward the end of 2025. That lets an Android device request a block of addresses to hand out to devices tethered to it. It does not make Android a DHCPv6 address client, so it does not solve this problem. Android still builds its own address from a router advertisement.

It worked, and then it stopped

The last piece is the one that explains the disappearing act, because IPv6 on a home-built router fails in one specific, repeatable way.

If you are running Linux as your router, the machine forwards traffic between your network and the internet. That forwarding is what makes it a router. Here is the trap: the moment forwarding is switched on, the Linux kernel stops accepting router advertisements, unless you explicitly tell it otherwise. The setting is accept_ra, and on the interface facing your provider it needs to be 2. The kernel’s own default is to accept router advertisements only when forwarding is off, so a freshly forwarded machine quietly goes deaf.

That alone would be a one-time puzzle. What makes it a recurring one is that other software turns forwarding on for you. Install Docker, or Podman, or the virtualization tools, and they enable forwarding so their internal networks can route. They do not set accept_ra to 2. If that happens to your router, it stops hearing your provider, and your whole network loses its numbering at the next reboot.

That is the classic shape of this failure: nothing about IPv6 changed, you installed something unrelated, and the addresses went away.

Two more things to check while you are looking:

• Do not let the provider’s block get written into a configuration file. Whatever generates your router advertisements should read the current prefix and use it, not a prefix typed in months ago.
• Do not filter ICMPv6. The neighbour-discovery messages that make IPv6 work are ICMPv6, and blocking them breaks the network in ways that look random rather than blocked.

What to do now

Work through these in order. The early steps are quick and they tell you where the problem actually is.

1. Check whether you have a provider-assigned address at all. On each device, run ip -6 addr if it is Linux, or look at the network details on the device itself. An address starting fd is yours. An address in the 2000 range came from your provider. An address starting fe80 is link-local and, on its own, means the device never heard a router advertisement.
2. Confirm your router is still hearing your provider. On the router, check net.ipv6.conf.all.forwarding and net.ipv6.conf.<provider-interface>.accept_ra. Forwarding will be 1. If accept_ra is not 2, that is your fault already found.
3. Set up a ULA prefix and announce it alongside the provider block. This is the change that makes addresses stop moving. It takes one line in most router software.
4. Turn on RDNSS so devices get names. With that and mDNS you can retire the address book.
5. If Android devices are dropping off, switch the router from managed to assisted mode. If they came back within seconds, that was the cause.
6. Write down what you changed in a file that is not on the router. Not because you will need to undo it, but because “I had this working once and wrote it down” is how this article started.

How we wrote this

One honest note about the standing of this advice.

This comes from the internet standards and from other people’s documented fixes, not from a lab bench. We have not run every step on our own network, and the exact names of settings differ between router software, so treat it as a map rather than a set of keystrokes to type blind. Where a step above is theory rather than something widely reported to work, we have said so.

The underlying point is not in doubt. If your devices keep changing address, something is renumbering your prefix, and the fix is to stop depending on that prefix. Everything else is detail.

We publish one plain-English guide a week. Normally, they are less advanced than this one but, if this was useful, sign up for the free guide.