[Centos] IPV6_AUTOCONF=no when using dhcp6

Also dealing with this bug. Working around it by manually editing /etc/sysconfig/network with bootcmd or manually setting the default route.

Thanks for filing the bug. We've another issue related here since the AUTOCONF controls ipv6 router advertisements. the V1 network-config doesn't allow one to express whether you want to opt-in or out of router advertisements which may be desired with either static6 or dhcp6.

In netplan (network-config version=2) one can provide:

accept-ra: true|false

Which in sysconfig rendering could be used to toggle IPV6_AUTOCONF.

There is a flag IPV6_FORCE_ACCEPT_RA[1] that can be set on an interface to accept_ra's while keeping autoconf (slaac) disabled. I wonder if that's what should be enabled for dhcp interfaces not IPV6_AUTOCONF which also set the autocnf sysctl.

accept_ra - INTEGER
 Accept Router Advertisements; autoconfigure using them.

 It also determines whether or not to transmit Router
 Solicitations. If and only if the functional setting is to
 accept Router Advertisements, Router Solicitations will be
 transmitted.

 Possible values are:
  0 Do not accept Router Advertisements.
  1 Accept Router Advertisements if forwarding is disabled.
  2 Overrule forwarding behaviour. Accept Router Advertisements
    even if forwarding is enabled.

 Functional default: enabled if local forwarding is disabled.
       disabled if local forwarding is enabled.

autoconf - BOOLEAN
 Autoconfigure addresses using Prefix Information in Router
 Advertisements.

 Functional default: enabled if accept_ra_pinfo is enabled.
       disabled if accept_ra_pinfo is disabled.

[1] https://github.com/fedora-sysv/initscripts/commit/28745ca8101b47b8a33213cfc524a4ada742721b

I did some testing, using an openstack instance with radvd running on a router in a flat provider network.

radvd was set up with the following config on the provider network:
interface eth1 {
  AdvSendAdvert on;
  AdvManagedFlag on;
  AdvOtherConfigFlag on;
  AdvRASolicitedUnicast on;
  AdvLinkMTU 1450;
  prefix fd12:3456:789a:1::/64 {
    AdvAutonomous on;
    AdvOnLink on;
  };
};

Setting IPV6_FORCE_ACCEPT_RA=yes in the interface configuration seem to fix this problem without also enabling autoconf which I belive would be the preffered configuration.

Question:
   Would it based on this result make sense to make the "accept-ra: true|false" in netplan (network-config version=2) control IPV6_FORCE_ACCEPT_RA in sysconf? And for cloudinit/sources/helpers/openstack.py enable it for network['type'] == dhcpv6-stateful?

Actual results:
---------------

instance metadata - network_data.json:
{
    "services": [
        {
            "type": "dns",
            "address": "fd12:3456:789a:1::1"
        }
    ],
    "networks": [
        {
            "network_id": "0e5c86ca-4f61-4e8d-a356-84c8001a297b",
            "type": "ipv6_dhcpv6-stateful",
            "services": [
                {
                    "type": "dns",
                    "address": "fd12:3456:789a:1::1"
                }
            ],
            "netmask": "ffff:ffff:ffff:ffff::",
            "link": "tapecbf57bf-c0",
            "routes": [
                {
                    "netmask": "::",
                    "network": "::",
                    "gateway": "fd12:3456:789a:1::fffe"
                }
            ],
            "ip_address": "fd12:3456:789a:1::1:14e",
            "id": "network0"
        }
    ],
    "links": [
        {
            "vif_id": "ecbf57bf-c0ff-4104-b5bf-5c310cc32d96",
            "type": "phy",
            "ethernet_mac_address": "fa:16:3e:26:da:7e",
            "id": "tapecbf57bf-c0",
            "mtu": 1450
        }
    ]
}

file: /etc/sysconfig/network
NOZEROCONF=yes

# Created by cloud-init on instance boot automatically, do not edit.
#
NETWORKING=yes
NETWORKING_IPV6=yes
IPV6_AUTOCONF=no

file: /etc/sysconfig/network-scripts/ifcfg-eth0
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEFROUTE=yes
DEVICE=eth0
DHCPV6C=yes
HWADDR=fa:16:3e:26:da:7e
IPV6INIT=yes
IPV6_DEFAULTGW=fd12:3456:789a:1::fffe
MTU=1450
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

$ sysctl net.ipv6.conf.eth0
net.ipv6.conf.eth0.accept_dad = 1
net.ipv6.conf.eth0.accept_ra = 0 <- RA is disabled
net.ipv6.conf.eth0.accept_ra_defrtr = 1
net.ipv6.conf.eth0.accept_ra_pinfo = 1
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen = 0
net.ipv6.conf.eth0.accept_ra_rtr_pref = 1
net.ipv6.conf.eth0.accept_redirects = 0
net.ipv6.conf.eth0.accept_source_route = 0
net.ipv6.conf.eth0.autoconf = 0 <- Autoconf is disabled
net.ipv6.conf.eth0.dad_transmits = 1
net.ipv6.conf.eth0.disable_ipv6 = 0
net.ipv6.conf.eth0.enhanced_dad = 1
net.ipv6.conf.eth0.force_mld_version = 0
net.ipv6.conf.eth0.force_tllao = 0
net.ipv6.conf.eth0.forwarding = 0
net.ipv6.conf.eth0.hop_limit = 64
net.ipv6.conf.eth0.keep_addr_on_down = 0
net.ipv6.conf.eth0.max_a...

Merge Proposal migrated to github:

https://github.com/canonical/cloud-init/pull/51

https://github.com/canonical/cloud-init/commit/62bbc262c3c7f633eac1d09ec78c055eef05166a

This bug is believed to be fixed in cloud-init in version 19.4. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3289