A Device Vanishes From the Router IPv6 List: What Changed?

A media player drops off the router's IPv6 client list while its streams keep working, and the natural conclusion is that something broke. More often the list changed its mind about what it was showing. A router status page may display a DHCPv6 lease, a wireless association, a neighbour entry, or a merged view, and each answers a different question.

The page shows one kind of record, not an inventory

IPv6 hosts commonly hold several addresses at once: a link-local address, one or more global addresses, and temporary privacy addresses that rotate. Neighbour Discovery keeps a cache of recently used neighbours on the local link, with reachability states that expire. A device can be perfectly reachable while its cached entry ages out, and it can appear in a lease table while its traffic takes a different path. None of those sources is a registry of every address a device has ever had.

So the first question is not why the device vanished, but which data source the page draws from.

Three host views answer three different questions

On an authorized Linux host, read the three objects separately. The address list shows what is configured, the route table shows where traffic would go, and the neighbour table shows what the host has recently talked to on-link. Conflating them produces confident wrong answers, because a missing neighbour entry looks exactly like a missing address.

ip -6 address show
ip -6 route show
ip -6 neighbour show

Run these inside the actual network namespace that carries the traffic. Inside a container the interface list can differ from the one the host sees, and a VPN client may live in either.

Compare the same three outputs before and after the VPN transition, and note timestamps. A neighbour entry that disappears while addresses and routes stay put describes cache aging, not a configuration change.

Separate a display change from a connectivity change

Then test what actually matters: reachability of the IPv6 resource the device needs. If the service answers over IPv6 through the approved path, a row missing from a dashboard is a monitoring defect. If it fails, the display change may be a symptom, and the next step is the route and firewall path rather than the list itself. A routed VPN does not normally move the host's LAN interface onto the remote link, so keep LAN addresses and tunnel addresses in separate columns of your thinking.

One interface can carry several addresses, and a status page may render only one of them. That is why a device can appear to change address after a reconnect without anything being wrong. Privacy extensions make this more visible, since temporary addresses rotate on a schedule the page does not show.

Verify the resource, then leave the tables alone

If host state and connectivity both look right, investigate the list's data source and refresh behaviour before touching the network. Look for a lease duration, a cache timeout, or a display filter that hides addresses the page does not classify.

Do not flush neighbour tables, disable IPv6, or reassign addresses to make a dashboard row reappear. Those actions interrupt working traffic and usually restore the row only until the next cache expiry. ip -6 neigh flush dev br-lan is a diagnostic at best and a self-inflicted outage at worst.

Record which source the page uses, and the question of whether the device works stops depending on a row in a table.