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
- 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
- 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.
- Boot the VM (Ubuntu 24.04 with netplan renderer) and inspect the generated netplan config:
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.
Bug report
The netplan renderer treats
ipv6_slaacsubnet type identically todhcp6, generatingdhcp6: truein the netplan config. This causes VMs to acquire DHCPv6 addresses in addition to SLAAC addresses, which is not the expected behavior foripv6_slaac.The root cause is in
cloudinit/net/netplan.py. AllIPV6_DYNAMIC_TYPES(which includesipv6_slaac,dhcp6,ipv6_dhcpv6-stateless, andipv6_dhcpv6-stateful) are handled by a single code path that setsdhcp6: True:The other renderers handle
ipv6_slaacdistinctly:cloudinit/net/eni.py:538): has a dedicatedelif subnet["type"] == "ipv6_slaac"branch that setsaccept_rawithout enabling DHCPv6cloudinit/net/sysconfig.py:467): has a dedicatedelif subnet_type == "ipv6_slaac"branchcloudinit/net/network_manager.py:141): mapsipv6_slaactoauto, which is distinct from DHCPv6The netplan renderer should generate
accept-ra: true(which it already has plumbing for at line 201) anddhcp6: falsewhen the subnet type isipv6_slaac, rather than settingdhcp6: true.Steps to reproduce the problem
Note
type: ipv6_slaac-- this is correct.cat /etc/netplan/*.yamlExpected:
accept-ra: trueand eitherdhcp6: falseor nodhcp6key.Actual:
dhcp6: true, which causes the VM to solicit DHCPv6 addresses in addition to SLAAC addresses.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_updatethen registers these extra addresses in DNS, causing intermittent connectivity issues as clients resolve to the wrong IPv6 address.Environment details
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.