its been a year now and i'm still stuck with this issue. if anyone has a workaround, please suggest.
problem - ISP assigns a ipv6 prefix which is promptly assigned to each interface and then configured to devices on each interface. ipv6 connectivity works fine.
now either isp pushes in a new prefix or you restart the wan/pppoe interface, the new prefix gets assigned to each interface but the devices connected continue using the old prefix and there by breaking connectivity until you restart the router or restart the device network interface.
L-13: If the delegated prefix changes, i.e., the current prefix is replaced with a new prefix without any overlapping time period, then the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of either a) zero or b) the lower of the current Valid Lifetime and two hours (which must be decremented in real time) in a Router Advertisement message as described in Section 5.5.3, (e) of [RFC4862].
But this doesn't seem to work as intended, at least in my case. @dedeckeh does this require any specific configuration?
I just realized that the mentioned commit isn't included in openwrt-22.03, yet. I'll cherry-pick commit 73c6d8fd046298face0e8aea8e52cc0faca67324 into my build and report back, if this helps.
If so, this commit should be included before the final 22.03 release, I guess.
Within that timeframe after a WAN reconnect all my clients mark the old addresses as deprecated and get addresses within the new prefix.
@dedeckeh or @jow can commit 73c6d8fd046298face0e8aea8e52cc0faca67324 be cherry-picked for openwrt-22.03?
Since a lot of home users have to live with dynamic prefixes, this will improve their IPv6 experience.
i captured the ra, rs messages on one linux box for 2 hours until the valid lifetime flag is set to 0 and invalid prefix entry removed. this test machine never removed the expired prefix even after the expired prefix entry was removed from RA messages. it neither picked up the valid prefix.
inet6 24xx:xxxx:xxxx:ff9d::xxxx/128 scope global dynamic noprefixroute
valid_lft 28118sec preferred_lft 28118sec
they seem to follow own validity timers as shown above. its happening on ipad as well. do i need to set any config at the dhcp client?
Hmm, since you can see the correct RA messages this might indeed be a problem on the client side.
There are a few things I don't understand in your config, however (but I don't know if they are related to your issue):
Is there a specific reason why you use hybrid as RA and DCHPv6? If you receive a valid prefix you should use server
Why do you have NDP-relaying enabled?
You should remove option ip6assign '64' from WAN6 - that's the interface you're getting the prefix from. I don't have a manually configured WAN6 at all
Here are my relevant config sections for reference:
sorry i forgot to revert those values. i was testing with 'hybrid' option with ndp-relay enabled. it didnt make any difference though. by default, i use 'server' for RA and DHCP with ndp relay disabled.
i guess, if we disable slaac and use only managed config, clients would treat the prefix also static until expiry. thats the reason why there is no impact on the changes announced in RA messages. correct me pls.
now, once i enabled slaac, the expired prefixes were marked deprecated as below and new prefixes were added to the interface.
exactly, i ll look into the RFC once as to what happens wrt managed config. it was mentioned somewhere that preferred lifetime flag value corresponds to slaac when i searched for the difference between two flags.
since preferred lifetime flag is set to zero on expiry, slaac mode works fine i guess. where as valid lifetime flag is set to 2hr or less and not zero.
It's been a awhile but when I researched on DHCP reconf I found no hints that DHCP server nor DHCP clients implements this because "nah, it's complicated" and I have found nothing regarding DHCPv6. Which sucks.
The commit I linked above indicates that odhcpd supports reconfiguration.
I don't know C, so I have a hard time understanding what odhcpd is doing.
I inserted a few debug statements and after a prefix change I can see that the function handle_addrlist_change() in dhcpv6-ia.c gets called for every interface that has prefix delegation enabled.
So far, so good, but this function doesn't seem to do anything - the reassign list seems to stay empty and therefore no reconfigure messages get sent.
I also did some research on DHCP clients and indeed - the only one I found so far that supports the Reconfigure Accept option is dhcpcd.
Most desktop Linux users probably use the implementation of systemd-networkd (which is also used by NetworkManager). At this point it doesn't seem to support DHCPv6 Reconfigure.
All in all it seems that people with dynamic IPv6 prefixes should stick to the default and keep SLAAC enabled. That way the chances to get new addresses after a prefix change seem to be highest.