@stgraber Retested this on Incus 7.3 (Zabbly stable, Ubuntu 26.04, Zabbly kernel, nftables driver). Still reproducible, and the behavior is very clean to observe with a short lease:
incus network set br-test ipv6.dhcp.stateful=true ipv6.dhcp.expiry=3m
Container NIC has security.ipv6_filtering=true, address assigned from the stateful range at boot (fd42:100::d000:0:0:1). Then valid_lft just counts down to zero, not a single renewal gets through:
14:19:38 inet6 fd42:100::d000:0:0:1/128 … valid_lft 163sec
14:20:23 inet6 fd42:100::d000:0:0:1/128 … valid_lft 118sec
14:21:08 inet6 fd42:100::d000:0:0:1/128 … valid_lft 72sec
14:21:53 inet6 fd42:100::d000:0:0:1/128 … valid_lft 27sec
14:22:38 (address gone, gateway unreachable)
Restarting the container brings the address back immediately, which matches the rule analysis from this thread: the filtering accept rule only matches DHCPv6 to the multicast address (ip6 daddr ff02::1:2 udp dport 547), so the initial multicast SOLICIT works while the unicast RENEW to the server is dropped before dnsmasq ever sees it.
So on 7.3 the practical options are still the same: ipv6.dhcp.expiry=87600h on the bridge, or static ipv6.address on the NIC device (which is what pins the filtering anyway). Would extending the accept rule to also match unicast DHCPv6 from fe80::/10 to the bridge’s own address on port 547 be an acceptable relaxation? That would keep the source restriction while letting renewals reach dnsmasq.