ipv6 routing disabled but default route provided

I’ve got a VM that acts as a firewall and behind that another VM (debian).
the VM “debian” may only connect to the internet through the firewall VM.
This is working fine.
For performance reason, I added another interface to another bridge to allow the debian-vm to talk directly to the host using a bridge named “sync”. That bridge must not do NAT or routing, but I’ve configured incus to do DHCP to provide the ip addresses automatically. Bridge config is below.
This works just fine for IPv4.
My problem is that I get an unwanted ipv6 default route from that bridge on my VM, effectively breaking ipv6 connection to that VM.
I’m not sure where that default route is coming from, as I’ve set ipv6.routing and nat to false.

name: sync
type: bridge
config:
  ipv4.routing: 'false'
  ipv6.routing: 'false'
  dns.mode: none
  ipv4.address: 10.228.162.1/24
  ipv4.nat: 'false'
  ipv6.address: fd42:304a:20c0:6742::1/64
  ipv6.nat: 'false'

Maybe try setting ipv6.dhcp.stateful: true to force the use of DHCPv6 rather than standard router advertisements?

It seems, debian by default only uses ipv6 auto configuration.
Effectively, the link-only ipv6 addresses ( fe80:: ) I get automatically are good enough for me. So ipv6 should be fine, even with ipv6.dhcp: false

But another problem with IPv4 turned up. For IPv4 it’s basically a race which interface gets the first DHCP reply and wins the default route.
In my previous tests this happened to be the regular network, not the sync network.
I’ve temporarily disabled dhcp on the regular network and now the sync network reliably gets a default route for IPv4 set, which is exactly the thing that must not happen.
So I’ve set ipv4.dhcp: false and configure the ip addresses manually.
I’m not sure if it’s dnsmasq incorrectly assuming the default route or incus not configuring dnsmasq correctly.

Looking at the logic, ipv4.routing and ipv6.routing only control whether the host will route the traffic (ip_forward=1 or forwarding=1) and associated firewall rules. It doesn’t affect the dnsmasq config at all, which would explain what you’re seeing.

Yes, dnsmasq not being affected by the NAT or routing setting explains what I see.
So the only option for me is to set ipv4/ipv6.dhcp: false and do everything manually.