Android (SLAAC) have only ULA adress after a while

100% agree

1 Like

My interim conclusion:
IPV6 and I, we won't be friends...
IPV6 is to complex (for me)

Just so you do not feel alone:

IMNSHO, IPV6 is is like fusion: just 20 years away form working.

I think it may depend on client implementation. My Chromecast runs for days but I'm still able to find it via ip -6 neigh show. My network config is nothing special (my ISP delegates /56 prefix):

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 'ula_prefix'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1'
	list ports 'eth2'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.254'
	option netmask '255.255.255.0'
	option ip6assign '64'
	option ip6hint '10'

config interface 'wan'
	option proto 'pppoe'
	option device 'eth0'
	option username 'username'
	option password 'password'
	option ipv6 '1'

config interface 'wan6'
	option proto 'dhcpv6'
	option device '@wan'
	option reqaddress 'try'
	option reqprefix 'auto'

For background recommend reading:
https://issuetracker.google.com/issues/149630944
https://issuetracker.google.com/issues/241959699
https://issuetracker.google.com/issues/290008647

But, in general:

  • decrease unsolicited multicast RA frequency/interval (10 min is good)
  • increase any and all lifetimes in the RA, so they're >15x higher than RA frequency/interval (3h is good)
  • increase wifi AP dtim_interval (aka dtim_period) to 5

Also worth mentioning: if Android detects default route timing out (because of failure to receive RAs to refresh it, because of multicast being unreliable) it will simply disable 'accept_ra' and only a wifi reconnect will reset this.

This is done to prevent ipv6 connectivity from constantly cycling up and down as RA arrive, routes get created, then routes time out, etc... as this makes apps very unhappy.

My ISP provider renews the IPV6 prefix every night at 2:30 a.m.

In this case the above might not help (but still try it, it just might...)
if it doesn't... maybe file a bug?

I'm not sure if this would be a bug on the phone side, or on the router side wrt. RAs it's sending out... Technically I think it needs to send out info about the new prefix before it retracts the old one for things to be healthy... But maybe this is something that could be fixed...

https://issuetracker.google.com/issues/236641895 might be relevant

The issue has been open since round about 2 years ..
Maybe i should try a snapshot ..
I still believe it's a misconfiguration ..

Installing DHCPv6 client app could be another option. I remember it worked when I tried it.

After I increased the dtim_interval for the radios to 5 (Thanks @maze), today is the first morning with a global address for my cell phones.
Hopefully it stays that way, I'll get back to you

Sorry, I have to give up. Somehow it all didn't work. I've now decided to take a pragmatic approach, I'll disconnect my cell phones for a moment via cron every night:

0 4 * * * * ubus call hostapd.phy0-ap0 del_client "{'addr':'E4:26:D5:BF:BF:19', 'reason':5, 'deauth':true, 'ban_time':5000}"
0 4 * * * * ubus call hostapd.phy0-ap1 del_client "{'addr':'E4:26:D5:BF:BF:19', 'reason':5, 'deauth':true, 'ban_time':5000}"

With a little bit of luck, everything will work again with a Openwrt release 24.0x... then I'll delete the cron lines again..

Many thanks to everyone who tried to help