Open blackhelicoptersdotnet opened 2 weeks ago
I've got a PR pending in cloud-init
to fix the issue there, but it might not be backported to images that are presently in the wild, and so the docs may continue to cause some confusion.
Hi @blackhelicoptersdotnet,
Yes, this is most definitely a bug in cloud-init not recognizing how we designate address auto configuration.
One thing about your cloud-init PR, in SmartOS addrconf
means either stateless (i.e., SLAAC), or stateful (DHCPv6) configuration. I notice that you set subnet = {"type": "dhcp6"}
. If cloud-init has a distinction for SLAAC, that should be accounted for. Otherwise, that PR looks good from my perspective.
@bahamat I was thinking the same thing. It turns out that dhcp6
in cloud-init
is imprecisely named; in practice it results in SmartOS addrconf
style behaviour on most/all distros.
There are other options, such as ipv6_dhcpv6-stateful
to force specific behaviour.
@blackhelicoptersdotnet Ok, great. Sounds good.
The procedure for configuring IPv6 set out in docs/blob/master/docs/setting-up-ipv6-in-a-zone.md does not work for Linux in Bhyve or KVM zones.
The
addrconf
value gets passed tocloud-init
as an IP address butcloud-init
has no idea what to do with it, and so it throws an error./var/lib/cloud/instances/c3cfc40e-9b68-4330-bbd1-5f36f4439815/network-config.json