Bridge network ipv6.dhcp.ranges ignored?

I’m just starting out with Incus and setting up some toy containers to try to get familiar with various parts of it. I’m having an issue with setting a DHCP range for IPv6 on a bridge network, and wondering if I’m missing something in my config, or have stumbled on a bug.

The problem I see is that Incus seems to be ignoring the range I’ve given it, and is assigning IPv6 addresses from outside that range.

I’m doing all this inside a VM (Parallels) running Debian Bullseye on a Mac, if that matters.

My configs:

% sudo incus config show
config: {}

% sudo incus network show incusbr0
config:
  ipv4.address: 172.17.0.1/24
  ipv4.dhcp.ranges: 172.17.0.100-172.17.0.200
  ipv4.nat: "true"
  ipv6.address: FD40:0A2C:0001::1/64
  ipv6.dhcp.ranges: fd40:0a2c:0001::100-fd40:0a2c:0001::200
  ipv6.nat: "true"
description: ""
name: incusbr0
type: bridge
used_by:
- /1.0/instances/mainweb
- /1.0/profiles/default
managed: true
status: Created
locations:
- none

% sudo incus list
+---------+---------+---------------------+----------------------------------------+-----------+-----------+
|  NAME   |  STATE  |        IPV4         |                  IPV6                  |   TYPE    | SNAPSHOTS |
+---------+---------+---------------------+----------------------------------------+-----------+-----------+
| mainweb | RUNNING | 172.17.0.133 (eth0) | fd40:a2c:1:0:216:3eff:feb2:7390 (eth0) | CONTAINER | 0         |
+---------+---------+---------------------+----------------------------------------+-----------+-----------+

I have also tried specifying the ipv6.dhcp.ranges value without the :: shortform, explicitly including all the zeros, but that had no effect.

Is there something I’m not doing correctly here?

Did you set ipv6.dhcp.stateful=true ?

With IPv6, the default is to use SLAAC and stateless DHCPv6, SLAAC uses router advertisements to inform the instances of the subnet at which point they compute their own address from their MAC resulting in an IPv6 address like the one you’re showing. DHCPv6 in that scenario is only used to provide additional information like additional routes, DNS servers, domain, … (though SLAAC provides some of that information too).

When enabled, stateful DHCPv6 works similarly to normal DHCP on IPv4 where the client has to actively reach out and get a IP lease.

Ah! Yes, that’ll be it. I didn’t spot mention of SLAAC, and for some reason it didn’t occur to me to go looking either.