The current template has an [overly optimistic logic](https://github.com/vyos/vyos-1x/blob/eff4470d5cd6a099c42875df6f3a9cea9e9a1b3e/data/templates/dhcp-client/ipv6.j2#L42) for `sla-len` calculation, relying on two assumptions that are not always true: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 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,The big issue here is that `wide-dhcpv6-client` uses the `sla-len` value from the configuration regardless of the received prefix size. which may decide to provide a different prefix size.
- A customer always wants to assign `/64` networks locally from the received prefixThis 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, the actual subnet assigned to every interface will be the same `/60`.and `wide-dhcpv6-client` behavior, This is because the SLA length will be setthe actual subnet assigned to `4`: `sla_len = 64 - pd_config.length`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:46
```
While we cannot control what the server will assign, we still need to provide the ability to split the assigned network between interfaces properly. A reasonable way to do this seems to be **providing the user with a capability to set `sla-len`** via CLI. There are still no guarantees that the final subnet size on interfaces will be as expected, but at least the customer will retain control over how the network is split between interfacesThe 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:46
```
Therefore, it seems we need to clean up the template to resolve the issue.