The current template has an overly optimistic logic for sla-len calculation, relying on an assumption that a server always provides a prefix with the exact length requested by the client. This is incorrect. According to RFC8415 and RFC7084, the prefix length in a request is only a hint for the server, which may decide to provide a different prefix size.
The big issue here is that wide-dhcpv6-client uses the sla-len value from the configuration regardless of the received prefix size. This seems to be the known issue.
An example of a configuration that works unexpectedly is as follows:
Server Configuration:
set interfaces ethernet eth1 address 'fc00:0:0:1::1/64' set service dhcpv6-server shared-network-name dhcpv6-1 subnet fc00:0:0:1::/64 address-range start fc00:0:0:1::100 stop 'fc00:0:0:1::200' set service dhcpv6-server shared-network-name dhcpv6-1 subnet fc00:0:0:1::/64 lease-time default '120' set service dhcpv6-server shared-network-name dhcpv6-1 subnet fc00:0:0:1::/64 prefix-delegation start fc00:0:2:: prefix-length '56' set service dhcpv6-server shared-network-name dhcpv6-1 subnet fc00:0:0:1::/64 prefix-delegation start fc00:0:2:: stop 'fc00:0:2:ff00::'
Client Configuration:
set interfaces ethernet eth1 address 'dhcpv6' set interfaces ethernet eth1 dhcpv6-options pd 1 interface eth2 address '1' set interfaces ethernet eth1 dhcpv6-options pd 1 interface eth2 sla-id '0' set interfaces ethernet eth1 dhcpv6-options pd 1 interface eth3 address '1' set interfaces ethernet eth1 dhcpv6-options pd 1 interface eth3 sla-id '1' set interfaces ethernet eth1 dhcpv6-options pd 1 interface eth4 address '1' set interfaces ethernet eth1 dhcpv6-options pd 1 interface eth4 sla-id '2' set interfaces ethernet eth1 dhcpv6-options pd 1 length '60'
The server can assign only /56, and the customer requested /60. Due to the calculation in the template, on the customer side, and wide-dhcpv6-client behavior, the actual subnet assigned to every interface will be the same /60.
vyos@vyos# run show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address MAC VRF MTU S/L Description
----------- ------------------- ----------------- ------- ----- ----- -------------
eth0 - 0c:67:94:67:00:00 default 1500 u/D
eth1 fc00:0:0:1::200/128 0c:67:94:67:00:01 default 1500 u/u
eth2 fc00:0:2:ff00::1/60 0c:67:94:67:00:02 default 1500 u/u
eth3 fc00:0:2:ff01::1/60 0c:67:94:67:00:03 default 1500 u/u
eth4 fc00:0:2:ff02::1/60 0c:67:94:67:00:04 default 1500 u/u
eth5 - 0c:67:94:67:00:05 default 1500 u/D
eth6 - 0c:67:94:67:00:06 default 1500 u/D
eth7 - 0c:67:94:67:00:07 default 1500 u/D
eth8 - 0c:67:94:67:00:08 default 1500 u/D
eth9 - 0c:67:94:67:00:09 default 1500 u/D
lo 127.0.0.1/8 00:00:00:00:00:00 default 65536 u/u
::1/128
[edit]
vyos@vyos# run show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
C>* fc00:0:0:1::200/128 is directly connected, eth1, 00:02:58
C * fc00:0:2:ff00::/60 is directly connected, eth4, 00:02:58
C * fc00:0:2:ff00::/60 is directly connected, eth3, 00:02:58
C>* fc00:0:2:ff00::/60 is directly connected, eth2, 00:02:58
C * fe80::/64 is directly connected, eth4, 00:48:41
C * fe80::/64 is directly connected, eth3, 00:48:41
C * fe80::/64 is directly connected, eth1, 00:48:41
C * fe80::/64 is directly connected, eth2, 00:48:42
C>* fe80::/64 is directly connected, lo, 00:48:46The good news is that we have already inherited a patch from Debian to mitigate the issue: https://salsa.debian.org/debian/wide-dhcpv6/-/blob/debian/20080615-23/debian/patches/0021-Make-sla-len-config-optional.patch
It accomplishes exactly what we are doing in the configuration template, but with the advantage of using the actual prefix length from the received prefix, rather than the one configured in the configuration file.
If we simply remove sla-len from the template, everything appears to function normally.
vyos@vyos:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address MAC VRF MTU S/L Description
----------- ------------------- ----------------- ------- ----- ----- -------------
eth0 - 0c:67:94:67:00:00 default 1500 u/D
eth1 fc00:0:0:1::200/128 0c:67:94:67:00:01 default 1500 u/u
eth2 fc00:0:2:ff00::1/64 0c:67:94:67:00:02 default 1500 u/u
eth3 fc00:0:2:ff01::1/64 0c:67:94:67:00:03 default 1500 u/u
eth4 fc00:0:2:ff02::1/64 0c:67:94:67:00:04 default 1500 u/u
eth5 - 0c:67:94:67:00:05 default 1500 u/D
eth6 - 0c:67:94:67:00:06 default 1500 u/D
eth7 - 0c:67:94:67:00:07 default 1500 u/D
eth8 - 0c:67:94:67:00:08 default 1500 u/D
eth9 - 0c:67:94:67:00:09 default 1500 u/D
lo 127.0.0.1/8 00:00:00:00:00:00 default 65536 u/u
::1/128
vyos@vyos:~$ show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
C>* fc00:0:0:1::200/128 is directly connected, eth1, 00:10:25
C>* fc00:0:2:ff00::/64 is directly connected, eth2, 00:10:24
C>* fc00:0:2:ff01::/64 is directly connected, eth3, 00:10:24
C>* fc00:0:2:ff02::/64 is directly connected, eth4, 00:10:25
C * fe80::/64 is directly connected, eth3, 00:10:42
C * fe80::/64 is directly connected, eth1, 00:10:42
C * fe80::/64 is directly connected, eth4, 00:10:42
C * fe80::/64 is directly connected, eth2, 00:10:44
C>* fe80::/64 is directly connected, lo, 00:10:46Therefore, it seems we need to clean up the template to resolve the issue.