Is IPv6 Working for bridges created by Incus?

Incus
, ,
3

Ah, then that sounds like you’re not using an incus-managed bridge, but you’re bridging containers directly onto the upstream network. In that case, automatic address allocation will come from whatever the upstream network provides; incus cannot interfere with that.

incus will only assign addresses via DHCP if it is managing its own network, where incus itself is acting as the gateway. Here’s one that works for me.

config:
  dns.domain: nmm.internal
  ipv4.address: 192.0.2.254/24
  ipv4.dhcp.ranges: 192.0.2.200-192.0.2.250
  ipv4.nat: "true"
  ipv6.address: fdfd::254/64
  ipv6.dhcp.ranges: fdfd::1000-fdfd::1fff
  ipv6.dhcp.stateful: "true"
  ipv6.nat: "true"
description: ""
name: bridge0
type: bridge
managed: true
status: Created
locations:
- none
project: default

incus starts a dnsmasq process to provide the DHCP service on this network:

$ ps auxwww | grep bridge0
incus       3643  0.0  0.0  13196  4644 ?        Ss   Apr29   0:00 dnsmasq --keep-in-foreground --strict-order --bind-interfaces --except-interface=lo --pid-file= --no-ping --interface=bridge0 --dhcp-rapid-commit --no-negcache --quiet-dhcp --quiet-dhcp6 --quiet-ra --listen-address=192.0.2.254 --dhcp-no-override --dhcp-authoritative --dhcp-leasefile=/var/lib/incus/networks/bridge0/dnsmasq.leases --dhcp-hostsfile=/var/lib/incus/networks/bridge0/dnsmasq.hosts --dhcp-range 192.0.2.200,192.0.2.250,1h --listen-address=fdfd::254 --enable-ra --dhcp-range fdfd::1000,fdfd::1fff,64,1h -s nmm.internal --interface-name _gateway.nmm.internal,bridge0 -S /nmm.internal/ --conf-file=/var/lib/incus/networks/bridge0/dnsmasq.raw -u incus -g incus

and it puts the assigned IP for each host in /var/lib/incus/networks/bridge0/dnsmasq.hosts/<proejct>_<container>.<interface>, e.g.

$ incus config show --project nsrc-builder nfsen
...
devices:
  eth0:
    ipv4.address: 192.0.2.3
    ipv6.address: fdfd::3
    name: eth0
    network: bridge0
    type: nic
...

$ cat /var/lib/incus/networks/bridge0/dnsmasq.hosts/nsrc-builder_nfsen.eth0
00:16:3e:32:81:15,192.0.2.3,[fdfd::3],nfsen

If you can’t run this way, then you’re better off assigning statics to each container as you do today. This can be scripted using cloud-init when you create the container (assuming your OS supports cloud-init; I don’t know if Void Linux does). Example in this thread.