Dynamic IPV6 prefix

starhunter · August 5, 2022, 2:33pm

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.

ref - dynamic ipv6 prefix

trendy · August 5, 2022, 3:59pm

You can try to lower the ra_mininterval , ra_lifetime , ra_useleasetime (it's boolean) to force more short lease times.

sebastian_de · August 5, 2022, 4:17pm

I feel your pain. My ISP fortunately doesn't do forced disconnects, but I too get a new prefix on every reconnect and my clients (mostly Linux) don't update their IPv6-addresses.

This commit for odhcpd seems to implement the desired behaviour mentioned in RFC7084 L-13:

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?

sebastian_de · August 5, 2022, 7:12pm

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.

sebastian_de · August 5, 2022, 8:22pm

The patch seems to work as expected!
I've set

dhcp.lan.ra_maxinterval='300'
dhcp.lan.ra_mininterval='120'

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.

starhunter · August 6, 2022, 1:41pm

This is excellent, thanks a ton. i m already using the latest snapshot build and the icmp messages were getting triggered immediately as expected.

however, none of the clients were picking up the new prefix. i have disabled slaac, would that be an issue? below is my config

/etc/config/network

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	list ipaddr '192.168.158.1/24'
	option ip6assign '64'
	option ip6hint '11'
	option ip6ifaceid 'random'
	option ip6weight '10'
	list ip6class 'wan6'
	list ip6class 'local'
	list dns 'xxxxx'
	list dns 'xxxxx'
	list dns 'xxxxx'

config interface 'wan'
	option device 'eth0.2'
	option proto 'pppoe'
	option username 'xxxx'
	option password 'xxxx'
	option peerdns '0'
	option ipv6 '1'

config interface 'wan6'
	option proto 'dhcpv6'
	option reqaddress 'force'
	option reqprefix '60'
	option peerdns '0'
	option ip6assign '64'
	list ip6class 'wan6'
	option device '@wan'

/etc/config/dhcp

config dhcp 'lan'
	option interface 'lan'
	option leasetime '12h'
	option dhcpv4 'server'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'
	option start '10'
	option limit '50'
	option force '1'
	list dhcp_option '6,xxxxxx'
	option ra_slaac '0'
	option ra_mininterval '120'
	option ra_maxinterval '300'
	option ndp 'relay'
	list dns 'xxxx:xxxx:xxxx:xxxx::xxxx'
	option ra 'hybrid'
	option dhcpv6 'hybrid'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

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

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?

sebastian_de · August 6, 2022, 4:37pm

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:

/etc/config/network

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '64'
        option ip6ifaceid '::1'
        option ip6hint '0'

config interface 'wan'
        option proto 'pppoe'
        option ipv6 'auto'
        option password 'xxx'
        option username 'xxx'
        option device 'eth0.7'
        option peerdns '0'

/etc/config/dhcp

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'
        list dns 'fda8:a260:6eda::80'
        list dhcp_option '6,192.168.1.80'
        option ra_maxinterval '300'
        option ra_mininterval '120'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

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

starhunter · August 6, 2022, 5:38pm

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.

inet6 24xx:xxxx:xxxx:71c7:7c70:1451:8f6b:113a/64 scope global deprecated dynamic noprefixroute 
       valid_lft 6984sec preferred_lft 0sec

ok, removed the alias/manual config completely and set to aautomatic now. the virtual wan6 interface spawned now seem to work the same way.

starhunter · August 6, 2022, 5:51pm

looks like enabling slaac is the only option to get the connectivity going when the prefix gets refreshed.

the negative side to this, we will have 4 ipv6 addresses for each interface. 2 each for ula and gua.

wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether a4:34:d9:67:d6:94 brd ff:ff:ff:ff:ff:ff
    inet 192.168.158.102/24 brd 192.168.158.255 scope global dynamic noprefixroute wlp1s0
       valid_lft 42680sec preferred_lft 42680sec
    inet6 fd85:4312:a8c0:c53d::xxxx/128 scope global dynamic noprefixroute 
       valid_lft 42681sec preferred_lft 42681sec
    inet6 24xx:xxxx:xxxx:1cbd::xxxx/128 scope global dynamic noprefixroute 
       valid_lft 42681sec preferred_lft 42681sec
    inet6 24xx:xxxx:xxxx:1cbd:xxxx:xxxx:xxxx:816c/64 scope global deprecated dynamic noprefixroute 
       valid_lft 6984sec preferred_lft 0sec
    inet6 fd85:4312:a8c0:c53d:xxxx:xxxx:xxxx:f531/64 scope global deprecated dynamic noprefixroute 
       valid_lft 5253sec preferred_lft 0sec
    inet6 24xx:xxxx:xxxx:1cbd:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic noprefixroute 
       valid_lft 86185sec preferred_lft 86185sec
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

sebastian_de · August 6, 2022, 5:57pm

I'm not an expert, but I think SLAAC shouldn't be required for this to work. So this could indeed be a bug.

starhunter · August 6, 2022, 6:01pm

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.

sebastian_de · August 7, 2022, 9:10am

I dug into this again.
RFC 4862 section 5.5.3 states:

a) If the Autonomous flag is not set, silently ignore the Prefix Information option.

That explains why clients not using SLAAC don't update their addresses. RFC7084 doesn't seem to specify what should happen on a prefix change when DHCPv6 is used.

But clients using DHCPv6 update their addresses, if they get a reconfigure message. There's a odhcpd commit that seems to be exactly what is needed:

If not consistent anymore a reconfigure is triggered for the assignment and a best effort is made to assign a new IA_PD prefix.

However I don't see DHCPv6 reconfigure messages after a WAN reconnect, so maybe that code doesn't work as intended.

_bernd · August 7, 2022, 9:55am

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.

sebastian_de · August 7, 2022, 2:53pm

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.

sebastian_de · August 8, 2022, 11:44am

clients
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.
odhcpd
I did some testing with dhcpcd and odhcpd and was able to receive Reconfigure messages drom odhcpd, but only if I remove the condition !(c->flags & OAF_DHCPV6_PD) from line 785 in src/dhcpv6-ia.c.
This condition got introduced with commit 2520c48 (dhcpv6-ia: introduce DHCPv6 pd and ia assignments flags). @dedeckeh if you read this, can you comment if this condition is needed/valid?
Summary
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.

_bernd · August 8, 2022, 11:55am

Cool. Thanks for taking such a deep dive. Did you by any chance had a look at kea because isc-dhcpd is considered legacy and new deployments should use kea instead...
Thanks again!

sebastian_de · August 8, 2022, 12:12pm

Doesn't look like it supports it, yet: https://gitlab.isc.org/isc-projects/kea/-/issues/199

isc-dhcpd (dhclient on Debian) doesn't support Reconfige either and since you say it's legacy I guess it never will...

edit: I just saw that kea seems to be only a DHCP(v6) server anyway.

system · August 18, 2022, 12:12pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.