fix(ec2): Do not enable dhcp6 on EC2

[major]

Proposed Commit Message

fix(ec2): Do not enable dhcp6 on EC2

When cloud-init finds any ipv6 information in the instance metadata, it
automatically enables dhcp6 for the network interface. However, this
brings up the instance with a broken IPv6 configuration because SLAAC
should be used for almost all situations on EC2.

Red Hat BZ: https://bugzilla.redhat.com/show_bug.cgi?id=2092459
Fedora Pagure: https://pagure.io/cloud-sig/issue/382
Upstream: https://bugs.launchpad.net/cloud-init/+bug/1976526

Fixes: canonical/cloud-init#3980

Signed-off-by: Major Hayden <major@redhat.com>

Additional Context

• Red Hat BZ: https://bugzilla.redhat.com/show_bug.cgi?id=2092459
• Fedora Pagure: https://pagure.io/cloud-sig/issue/382

Test Steps

1. Deploy an instance on AWS with a VPC attached that has IPv6 subnets
2. The instance should come online with an IPv6 address configured

Checklist

• My code follows the process laid out in the documentation
• I have updated or added any unit tests accordingly
• I have updated or added any documentation accordingly

Merge type

• Squash merge using "Proposed Commit Message"
• Rebase and merge unique commits. Requires commit messages per-commit each referencing the pull request number (#<PR_NUM>)

[holmanb]

Thanks for filing this PR @major. I just tested this on Ubuntu and noticed that IPv6 works correctly both before and after this change. On networkd directly and on networkd with netplan, both the current code and your PR work correctly. This PR does result in changes to the configuration for networkd, however since networkd accepts RA regardless of the [Network]'s DHCP= setting, and LinkLocalAddressing is enabled by default, this "just works" on networkd.

[holmanb]

This fixes NetworkManager and doesn't seem to break other networking backends. Thanks for upstreaming this @major!

[major]

@holmanb Thanks for taking a look at that. 👏

[xiachen-rh]

@major and @holmanb , I think the issue has already been fixed by this commit. 5d12b43, can you please help to review please?

[xiachen-rh]

Hi @major and @holmanb,
I reproduced the issue with cloud-init-22.2-4.fc37.noarch on AWS, and I also tested cloud-init-23.1.1-1.fc38.noarch which contains the commit 5d12b43, it does not have the issue. so I confirm that the commit has already fixed the issue.

cloud-init-22.2-4.fc37.noarch
[fedora@ip-10-116-1-185 ~]$ sudo cat /etc/NetworkManager/system-connections/cloud-init-eth0.nmconnection

[connection]
id=cloud-init eth0
uuid=1dd9a779-d327-56e1-8454-c65e2556c12c
type=ethernet

[user]
org.freedesktop.NetworkManager.origin=cloud-init

[ethernet]
mac-address=0A:5E:05:EB:01:87

[ipv4]
method=auto
may-fail=false

[ipv6]
method=dhcp
may-fail=false
addr-gen-mode=stable-privacy

cloud-init-23.1.1-1.fc38.noarch
[fedora@ip-10-116-1-131 ~]$ sudo cat /etc/NetworkManager/system-connections/cloud-init-eth0.nmconnection

[connection]
id=cloud-init eth0
uuid=1dd9a779-d327-56e1-8454-c65e2556c12c
type=ethernet

[user]
org.freedesktop.NetworkManager.origin=cloud-init

[ethernet]
mac-address=0A:2E:97:FE:47:E9

[ipv4]
method=auto
may-fail=false

[ipv6]
method=auto
may-fail=false

I also tested cloud-init-23.2.1-1.fc39.noarch which contains major's commit, the nmconnection file does not contain ipv6 configuration, ipv6 could work due to NetworkManager default settings. Although this commit does not break anything, in my mind, as the issue has already been fixed, we don't need this change, do you agree with me?

cloud-init-23.2.1-1.fc39.noarch
[root@ip-10-116-1-57 cloudinit]# sudo cat /etc/NetworkManager/system-connections/cloud-init-eth0.nmconnection

[connection]
id=cloud-init eth0
uuid=1dd9a779-d327-56e1-8454-c65e2556c12c
autoconnect-priority=120
type=ethernet

[user]
org.freedesktop.NetworkManager.origin=cloud-init

[ethernet]
mac-address=0A:08:7B:6A:42:81

[ipv4]
method=auto
may-fail=false

[major]

@xiachen-rh Ah, this might be a situation where it was fixed upstream but the fix was missing in Fedora, hence the patch I wrote. Maybe we don't need this patch from this PR after all? I'll see if I can do some more testing today without this PR applied and see if the issue is there.