Netplan renderer incorrectly mixes DHCPv6 and SLAAC

Start in cloudinit/net/netplan.py at the IPV6_DYNAMIC_TYPES branch and inspect the existing accept-ra plumbing around line 201. Compare the ipv6_slaac handling with cloudinit/net/eni.py, cloudinit/net/sysconfig.py, and cloudinit/net/network_manager.py; done means the netplan output enables router advertisements without enabling DHCPv6 for ipv6_slaac.

Bug report

The netplan renderer treats ipv6_slaac subnet type identically to dhcp6, generating dhcp6: true in the netplan config. This causes VMs to acquire DHCPv6 addresses in addition to SLAAC addresses, which is not the expected behavior for ipv6_slaac.

The root cause is in cloudinit/net/netplan.py. All IPV6_DYNAMIC_TYPES (which includes ipv6_slaac, dhcp6, ipv6_dhcpv6-stateless, and ipv6_dhcpv6-stateful) are handled by a single code path that sets dhcp6: True:

elif sn_type in IPV6_DYNAMIC_TYPES:
    entry.update({"dhcp6": True})

The other renderers handle ipv6_slaac distinctly:

• eni (cloudinit/net/eni.py:538): has a dedicated elif subnet["type"] == "ipv6_slaac" branch that sets accept_ra without enabling DHCPv6
• sysconfig (cloudinit/net/sysconfig.py:467): has a dedicated elif subnet_type == "ipv6_slaac" branch
• NetworkManager (cloudinit/net/network_manager.py:141): maps ipv6_slaac to auto, which is distinct from DHCPv6

The netplan renderer should generate accept-ra: true (which it already has plumbing for at line 201) and dhcp6: false when the subnet type is ipv6_slaac, rather than setting dhcp6: true.

Steps to reproduce the problem

1. On Proxmox VE, create a VM with cloud-init and set IPv6 to SLAAC:

qm set <vmid> --ipconfig0 ip=10.0.0.100/16,gw=10.0.254.253,ip6=auto

2. Regenerate the cloud-init image and inspect it. Proxmox generates the correct v1 network config on the cloud-init ISO:

version: 1
config:
    - type: physical
      name: eth0
      mac_address: 'bc:24:11:34:de:85'
      subnets:
      - type: static
        address: '10.0.0.100'
        netmask: '255.255.0.0'
        gateway: '10.0.254.253'
      - type: ipv6_slaac
    - type: nameserver
      address:
      - '10.0.0.1'

Note type: ipv6_slaac -- this is correct.

3. Boot the VM (Ubuntu 24.04 with netplan renderer) and inspect the generated netplan config:

cat /etc/netplan/*.yaml

Expected: accept-ra: true and either dhcp6: false or no dhcp6 key.

Actual: dhcp6: true, which causes the VM to solicit DHCPv6 addresses in addition to SLAAC addresses.

$ cat /etc/netplan/50-cloud-init.yaml
network:
  version: 2
  ethernets:
    eth0:
      match:
        macaddress: "bc:24:11:34:de:85"
      addresses:
      - "10.0.0.100/16"
      nameservers:
        addresses:
        - 10.0.0.1
        search: []
      dhcp6: true        # <-- should be accept-ra: true, dhcp6: false
      set-name: "eth0"
      routes:
      - to: "default"
        via: "10.0.254.253"

On a network with both SLAAC RAs and a DHCPv6 server, this results in the VM acquiring unexpected DHCPv6 addresses. In our case, SSSD's dyndns_update then registers these extra addresses in DNS, causing intermittent connectivity issues as clients resolve to the wrong IPv6 address.

Environment details

• Cloud-init version: 25.3-0ubuntu1~24.04.1
• Operating System Distribution: Ubuntu 24.04 (Noble)
• Cloud provider, platform or installer type: Proxmox VE 8.x (NoCloud datasource)

cloud-init logs

The relevant output is the generated netplan config. No crash or error occurs; the issue is silent incorrect behavior. The cloud-init input (from the NoCloud ISO mounted at /dev/sr0) and the netplan output are shown in the reproduction steps above.