Useless IPv6 addresses pile up

nobrowser · December 3, 2025, 7:27pm

I have a mostly harmless (I think) but annoying issue with IPv6. My OpenWRT router may not be responsible for it, but I hope it can be used for a workaround.

IPv6 RAs come from my upstream "router" which is an Inseego M3000:

https://inseego.com/products/mobile-hotspot-routers/mifi-x-pro/

I have the OpenWRT One behind it, running 24.10.4, up to date. The One handles IPv6 in pass-through mode (this is necessary because there's no public prefix). The issue occurs on my "always-on" Raspberry Pi computer. It looks like it never drops any of the IPv6 addresses it acquires, and it acquires a new one each time the Inseego reboots or even just disconnects and reconnects to upstream.

Right now, the Inseego says it is something like (obvious alterations):

2607:fb90:dead:beef:e185:f22f:5bac:b3a3

and on the RPi I see:

pop-os:~# g raspberrypi.lan ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2607:fb90:dead:beef:ba27:ebff:fef9:205f/64 scope global mngtmpaddr noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2607:fb90:dead:beea:ba27:ebff:fef9:205f/64 scope global mngtmpaddr noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2607:fb90:dead:beeb:ba27:ebff:fef9:205f/64 scope global mngtmpaddr noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2607:fb90:dead:beec:ba27:ebff:fef9:205f/64 scope global mngtmpaddr noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fef9:205f/64 scope link
       valid_lft forever preferred_lft forever

Over the course of a few weeks, there'll be maybe dozens of these stale addresses as the Inseego changes its /64 prefix. How can I remove them when they become unrouteable, or at least time them out? I definitely don't want to reboot the RPi, and preferably not reset its interface, at least the IPv4 side.

_bernd · December 3, 2025, 9:08pm

How does your /etc/config/network looks? And the net conf of the pi too please.

Edit. And of course etc config dhcp

nobrowser · December 4, 2025, 1:17am

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd85:9dff:b742::/48'
	option packet_steering '1'
	option steering_flows '128'

config interface 'wwan'
	option proto 'dhcp'
	option peerdns '0'
	option dns_metric '5'
	list dns '8.8.8.8'
	list dns '8.8.4.4'

config interface 'lan2g'
	option proto 'static'
	option device 'eth0'
	option ipaddr '10.10.10.1'
	option netmask '255.255.255.0'
	option ip6assign '64'
	option defaultroute '0'
	option force_link '0'

config interface 'wwan6'
	option proto 'dhcpv6'
	option device 'phy0-sta0'
	option reqaddress 'try'
	option reqprefix 'auto'
	option norelease '1'
	option peerdns '0'
	list dns '2001:4860:4860::8888'
	list dns '2001:4860:4860::8844'

root@OpenWrt:~# cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option localservice '1'
	option ednspacket_max '1232'
	option logdhcp '1'
	option logfacility 'DAEMON'
	option min_cache_ttl '1800'
	option strictorder '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'
	option piofolder '/tmp/odhcpd-piofolder'

config dhcp 'lan2g'
	option interface 'lan2g'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option ra 'relay'
	option dhcpv6 'relay'
	option ndp 'relay'
	option ra_useleasetime '1'

config dhcp 'wwan'
	option interface 'wwan'
	option ignore '1'

config host
	list mac 'D4:93:90:1F:05:B9'
	option ip '10.10.10.128'
	option name 'pop-os'

config host
	option name 'raspberrypi'
	list mac 'B8:27:EB:F9:20:5F'
	option ip '10.10.10.174'

config host
	option name 'rock64'
	option ip '10.10.10.244'
	list mac '9A:0A:CA:61:83:46'

config dhcp 'wwan6'
	option interface 'wwan6'
	option ignore '1'
	option master '1'
	option ra 'relay'
	option dhcpv6 'relay'
	option ndp 'relay'

raspberrypi:~# cat /etc/systemd/network/80-ethernet.network
# SPDX-License-Identifier: MIT-0
#
# This example config file is installed as part of systemd.
# It may be freely copied and edited (following the MIT No Attribution license).
#
# To use the file, one of the following methods may be used:
# 1. add a symlink from /etc/systemd/network to the current location of this file,
# 2. copy the file into /etc/systemd/network or one of the other paths checked
#    by systemd-networkd and edit it there.
# This file should not be edited in place, because it'll be overwritten on upgrades.

# Enable DHCPv4 and DHCPv6 on all ethernet links
[Match]
Type=ether

[Network]
DHCP=yes

(the RPi config is copied verbatim from the systemd-network examples dir)

brada4 · December 4, 2025, 1:22am

it means somebody else runs ip6 lan config for you.
No problem with OpenWrt as it is not involved in making temp addresses perpetual.

nobrowser · December 4, 2025, 1:25am

Yes, I understand. My question is: can I tweak this "relay mode" on OpenWRT somehow to work around this?

brada4 · December 4, 2025, 2:46am

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):

Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:

ubus call system board

nobrowser · December 4, 2025, 6:27am

root@OpenWrt:~# ubus call system board
{
	"kernel": "6.6.110",
	"hostname": "OpenWrt",
	"system": "ARMv8 Processor rev 4",
	"model": "OpenWrt One",
	"board_name": "openwrt,one",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "24.10.4",
		"revision": "r28959-29397011cc",
		"target": "mediatek/filogic",
		"description": "OpenWrt 24.10.4 r28959-29397011cc",
		"builddate": "1760891865"
	}
}

brada4 · December 4, 2025, 10:21am

Good version. The ip6 autoconf relay does act as a straight pipe, not a l7 application and caching proxy.

You can run dhcp6 on a non-gateway too. But the chicken + egg you need a bridge firewall to acquire IP6 yourself, suppress their autoconfig and present yours to users.

nobrowser · December 5, 2025, 3:28am

Chickens! Don't get me started, I had an invasion from a neighbor recently

Ok, so seriously, I'm thinking of just disabling IPv6 on the ISP router (it's T-Mobile US, btw, and also IPv4 is clearly behind CGNAT) and setting up a wireguard tunnel to my Linode from OpenWRT as a means of IPv6 access. Do you see anything completely wrong with that?

moeller0 · December 5, 2025, 5:55am

My guess is the lifetimes are fubar'd these should not be forever... if you capture these on your OpenWrt router, does TMUS really configure unlimited lifetime?
BTW, is this via mobile or via fibre?

brada4 · December 5, 2025, 9:32am

You are absolutely right, temp addresses should not be forever. Probably worth having a word with provider saying raspberry supports safety videos 24x7 and accumulates temp addresses for no good.
Check

sysctl net.ipv6.conf.default.max_addresses

Upstream and OpenWrt default is 16 though no idea how infinite temporary addresses are expected to behave,,,,

mk24 · December 5, 2025, 12:35pm

What does ifstatus wwan6 show as the upstream lease time? On my T-Mobile connection it is 24 hours, not infinite. The prefix doesn't change unless the signal drops. On a Linux endpoint PC I have several deprecated temporary IPs all in the same /64 with valid_lft 86000 seconds and preferred_lft of zero.

T-Mobile native IPv6 works very well for me. Their network is v6 only, the v4 connection you have is handled by 464 inside the modem.

nobrowser · December 6, 2025, 1:39am

BTW, is this via mobile or via fibre?

Mobile 5G.

The prefix doesn't change unless the signal drops.

Not only does the signal drop, the "router" reboots sometimes for unknown reasons. I suspect it has to do with the alerts it insists on showing when the charge reaches 100% and when it switches to battery preservation mode (after the charge has been at 100% for a day or so).

Their network is v6 only

That is really funny, because there's a checkbox Enable IPv6 which was off by default IIRC. And when I turn that off, not only is IPv6 gone on the LAN (as I'd of course expect) but also the status page shows no external IPv6 address.

I am pursuing the tunnel route (ahem, sorry) now. Making some progress, but hitting some firewall problem that stops forwarding of IPv6 from the LAN into wireguard. I have some hope that log from the firewall will help.

Update: more progress. The firewall problem was that for some reason, when I added the wireguard interface via Luci, a firewall zone was created for it but restricted to IPv4. I don't know why it would do this, is it known?

I fixed that, and now the tunnel has both link-local addresses on both ends, and addresses in the ULA block conjured by OpenWRT on both ends, and I can ping6 both ways with either kind of address, including from another host on the LAN.

The last step now is adding global addresses from my Linode block in a similar way. I am now confident it will work.

nobrowser · December 10, 2025, 6:24am

So, I did manage to get it working via wireguard. There were 2 minor remaining sticking points:

The seems to be no way to assign a static IPv6 address to the LAN interface via Luci. Even if I set the "protocol" option to "Static address" that only shows a field for an IPv4 address. Why? It is trivial to do it via uci set or editing /etc/config/network.
More important was an "interesting" configuration issue on the Linode that holds the other end of the tunnel. This Stack Exchange discussion was crucial for me to understand what was going on:

So, I had to do:

sysctl net.ipv6.conf.all.forwarding=1
sysctl net.ipv6.conf.eth0.forwarding=0

to allow forwarding between "the Internet" and wireguard, but OTOH to not look like a router to other hosts in the Linode neighborhood.

Thanks for all the help.

mk24 · December 10, 2025, 2:23pm

If this is the only purpose of the Linode VPS, you could run OpenWrt there and use the now-familiar OpenWrt firewall.

nobrowser · December 11, 2025, 4:04am

No, that is quite a busy system, running my vintage mail server among other things.

I created firewall rules on the OpenWRT router for the new wireguard interface that look the same as those for the wan interface, with the requisite substitutions. So if I'm doomed now I was already doomed before