This KB describes a scenario when a dual-stack subscriber is not able to obtain DHCPv6 address after it reconnects.
If the following conditions are met:
If CPE reconnects using DHCPv4 (by sending DHCP release and initiating DORA again), it's able to connect again. But because dual-stack-group and protocol-master inet knobs are configured, DHCPv6 binding gets deleted if DHCPv4 binding is deleted. If in this scenario CPE believes that its DHCPv6 binding is still valid, it will try to renew it by sending DHCPv6 Renew, and MX may ignore all CPE attempts to extend its DHCPv6 lease.
This behavior is reported for some TP-Link home routers.
For example, the following configuration could be used:
system { services { dhcp-local-server { dhcpv6 { group dhcp6-ls { overrides { delegated-pool PREFIX-DELEGATION; delete-binding-on-renegotiation; dual-stack dhcp-ds; } interface demux0.0; } server-duid-type { duid_ll; } } group dhcp-ls { overrides { client-discover-match incoming-interface; dual-stack dhcp-ds; } interface demux0.0; } dual-stack-group dhcp-ds { dynamic-profile l3-profile; on-demand-address-allocation; classification-key { mac-address; } protocol-master inet; } } }}
According to RFC8415, DHCPv6 Renew for a non-existing binding should be responded with DHCPv6 Reply with status code 3 ("no binding"), and this behavior is correct in releases with the fix for PR1843596. Receipt of such DHCPv6 Reply packet will trigger new SARR cycle and CPE will be able to connect using DHCPv6 immediately. In releases without the fix MX will not respond to DHCPv6 packets from CPE until CPE starts a new SARR cycle which should happen when the old lease expires.