[DHCPv6 stateful] W10 client has ULA but not GUA - bug?

Installing and Using OpenWrt Network and Wireless Configuration
1
  • odhcpd version 2019-12-15 with option ra_management '2'
  • client W10 Pro x_64 v1909 b18363.592

Whilst the client gets an ULA it does not however get a GUA from the ISP.

Dis/Re- connecting or rebooting the client does not remedy the issue, neither ipconfig /release6 & ipconfig /renew6.

Since the setting works for the ULA it would be expected too for the GUA, thus wondering whether this is some of bug?

changing the setting to option ra_management '1' and restarting odhcpd the client gets a GUA instantaneously.

2

RA management mode
0: no M-Flag but A-Flag
1: both M and A
2: M but not A

  • A-Flag : tell client to use auto-configuration i.e. SLAAC
  • M-Flag : notify client that DHCPv6 server is available

What is the output of uci export network; uci export dhcp ?

1 Like
3

I was aware of the flags, just not whether there is a difference in the emphasises of tell and notify; whether both amount to the same - announcing the the availability of both or either?

relevant network conf sections 
config interface 'wan'
	option proto 'pppoe'
	option layer '1'
	option peerdns '0'
	option keepalive '6 10'
	option ifname 'eth2'
	option ipv6 'auto

config interface 'lan'
	option type 'bridge'
	option bridge_empty '1'
	option stp '1'
	option layer '2'
	option proto 'static'
	option ipaddr '192.168.84.23'
	option netmask '255.255.255.0'
	option multicast_querier '1'
	option ip6assign '64'
	option ip6hint '9a9b'
	option ip6ifaceid 'random'
	option ifname 'lan0 lan1 lan2'
relevant dhcpd conf sections 
config odhcpd 'odhcpd'
	option maindhcp '1'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config dhcp 'ignore'
	list interface 'wan'
	list interface 'wan_6'
	list interface 'wan_6_4'
	list interface 'eth2'
	option ignore '1'

config dhcp 'lan'
	option interface 'lan'
	option start '193'
	option limit '40'
	option leasetime '2h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option dhcpv6_assignall '0'
	option ra 'server'
	option ra_management '1'
	option ra_preference 'high'
	option ra_offlink '1'
4

It seems that option dhcpv6_assignall '0' is causing the issue

Assign all viable DHCPv6 addresses in statefull mode; if disabled only the DHCPv6 address having the longest preferred lifetime is assigned

The question thus is whether the lifetime of the ULA is competing with the lifetime for GUA despite each covering a different address space?

Since the preferred lifetime is being set per interface and not per address space the set value applies to the interface where both, ULA and GUA, are present.

Should there not be a distinction in considering the address space, ULA <-> GUA, if the longest preferred lifetime is the deciding factor for this setting, else it would seem to be a race condition.

5

By the looks of it, it seems that only the longest lifetime address is assigned regardless of the address space. And it complies with the description.

6

Sure, but it does not state whether the race condition between ULA and GUA is intended by design or being an unintended consequence?

It does not seem to make sense that ULA and GUA are becoming mutually exclusive with the preferred lifetime correlating to an interface.