[bug] DataSourceOracle enables DHCPv6 causing IPv6 /128 conflict with IMDS /64

[goldberl]

Bug Report

OCI instances using DataSourceOracle intermittently exhibit IPv6 instability due to conflicting IPv6 configuration sources between IMDS and DHCPv6.

What appears to be happening

• IMDS provides a static IPv6 /64 via DataSourceOracle
• cloud-init also enables DHCPv6 on the same interface
• systemd-networkd then assigns a DHCPv6 /128 address
• systemd-networkd rejects/ignores the /128 due to conflict with the existing /64
• the IPv6 /64 lease eventually expires, resulting in temporary loss of IPv6 connectivity
• DHCPv6 later retries and successfully applies the /128, restoring connectivity

On affected instances, systemd-networkd logs show repeated DHCPv6 conflicts:

May 04 14:18:11 kajgm-3-00435091 systemd-networkd[4964]: ens300np0: Ignoring DHCPv6 address 2603:c020:401b:4200:0:faa8:95f6:c005/128 (valid for 1d 59min 59s, preferred for 23h 59min 59s) which conflicts with 2603:c020:401b:4200:0:faa8:95f6:c005/64.

Steps to reproduce the problem

1. Launch an OCI instance
2. Observe IPv6 configuration on primary NIC and note the /64 address.

ubuntu@kajgm-3-00435091:~$ ip -6 addr show dev ens300np0
2: ens300np0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    altname enp97s0np0
    inet6 2603:c020:401b:4200:0:faa8:95f6:c005/64 scope global dynamic noprefixroute 
       valid_lft 82247sec preferred_lft 78647sec
    inet6 fe80::625e:65ff:fed6:44ee/64 scope link 
       valid_lft forever preferred_lft forever

3. And observe the conflicts in the journal logs.

ubuntu@kajgm-3-00435091:~$ journalctl -u systemd-networkd | grep -i dhcp
May 04 14:18:11 kajgm-3-00435091 systemd-networkd[4964]: ens300np0: Ignoring DHCPv6 address 2603:c020:401b:4200:0:faa8:95f6:c005/128 (valid for 1d 59min 59s, preferred for 23h 59min 59s) which conflicts with 2603:c020:401b:4200:0:faa8:95f6:c005/64.

4. Wait for the /64 address valid_lft to expire.
5. The VM will lose connectivity for a few hours until DHCPv6 retries.
6. Once the VM regains connectivity, SSH back in and observe the primary NIC again - note the /128 address

ubuntu@kajgm-3-00435091:~$ ip -6 addr show dev ens300np0
2: ens300np0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    altname enp97s0np0
    inet6 2603:c020:401b:4200:0:faa8:95f6:c005/128 scope global dynamic noprefixroute 
       valid_lft 88681sec preferred_lft 85081sec
    inet6 fe80::625e:65ff:fed6:44ee/64 scope link 
       valid_lft forever preferred_lft forever

Environment details

• Cloud-init version: 25.3-0ubuntu1~24.04.1
• Operating System Distribution: Ubuntu 24.04
• Cloud provider, platform or installer type: Oracle Cloud Infrastructure (OCI)

cloud-init logs

Unfortunately, collecting full cloud-init logs may not be possible, as the system appears to have a read-only filesystem preventing writes to /home.

ubuntu@kajgm-3-00435091:~$ sudo cloud-init collect-logs --redact-sensitive
Unexpected error while running command.
Command: ['tar', 'czf', '/home/ubuntu/cloud-init.tar.gz', '-C', '/run/cloud-init/tmpy37qtgui', 'cloud-init-logs-2026-05-06']
Exit code: 2
Reason: -
Stdout: 
Stderr: tar (child): /home/ubuntu/cloud-init.tar.gz: Cannot open: Read-only file system
        tar (child): Error is not recoverable: exiting now
        tar: /home/ubuntu/cloud-init.tar.gz: Cannot write: Broken pipe
        tar: Child returned status 2
        tar: Error is not recoverable: exiting now

[goldberl]

Since the file system was write only and the journal file was massive, I manually collected logs in the /run directory and bundled them up using these commands:

sudo mkdir -p /run/cloud-init-debug

# collect logs
sudo cp -a /var/log/cloud-init* /run/cloud-init-debug/ 2>/dev/null || true
sudo cp -a /run/cloud-init /run/cloud-init-debug/ 2>/dev/null || true
sudo cp -a /etc/netplan /run/cloud-init-debug/ 2>/dev/null || true
sudo cp -a /etc/cloud /run/cloud-init-debug/ 2>/dev/null || true

# all current boot journal logs
sudo journalctl -b 0 | sudo tee /run/cloud-init-debug/journalctl-b0.log > /dev/null

# just networkd and cloud-init units from current boot journal logs
sudo journalctl -b 0 -u systemd-networkd -u cloud-init | sudo tee /run/cloud-init-debug/journalctl-b0-units-networkd-cloudinit.log > /dev/null

# bundle up into tar
sudo tar -czvf /run/cloud-init-debug-bundle.tar.gz -C /run cloud-init-debug

I stopped journalctl-b0.log because it was taking a very long time and also just collected journalctl-b0-units-networkd-cloudinit.log

cloud-init-debug-bundle.tar.gz