[Centos] IPV6_AUTOCONF=no when using dhcp6

Bug #1806014 reported by Herbert Buurman
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
Harald Jensås

Bug Description

When instructing cloud-init to use `type: dhcp6` for the subnet of a physical network interface, the end-result is that `/etc/sysconfig/network` contains `IPV6_AUTOCONF=no`. This causes router advertisements to be ignored and no default route set up.

This configures `network.use_ipv6 = True`, which is fine.

This configures `IPV6_AUTOCONF=no` to be written whenever `network.use_ipv6` is `True`.
However, in the use-case where dhcp6 is used, `IPV6_AUTOCONF` should be set to `yes`.

Proposed fix:
Distinguish between IPv6 being configured statically or using DHCP when writing the sysconfig file.

Cloud-provider: AWS EC2.
Guest OS: CentOS Linux release 7.5.1804 (Core)
EC2 user-data provided with cloud-init config:
package_upgrade: true
- path: /etc/cloud/cloud.cfg.d/99-custom-networking.cfg
  owner: root:root
  permissions: 0600
  content: |
      version: 1
      - type: physical
        name: eth0
          - type: dhcp
          - type: dhcp6
  mode: reboot
  delay: now
  message: Rebooting post-config
  timeout: 30
  condition: True

Tags: centos dhcp6 ipv6

Related branches

Revision history for this message
Herbert Buurman (the-neighbour) wrote :
description: updated
Revision history for this message
Nick Adams (h-nick-n) wrote :

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

Revision history for this message
Ryan Harper (raharper) wrote :

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.

Changed in cloud-init:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Harald Jensås (harald-jensas) wrote :

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

 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

 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

Revision history for this message
Harald Jensås (harald-jensas) wrote :
Download full text (9.5 KiB)

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.

   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

# Created by cloud-init on instance boot automatically, do not edit.

file: /etc/sysconfig/network-scripts/ifcfg-eth0
# Created by cloud-init on instance boot automatically, do not edit.

$ 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


Ryan Harper (raharper)
Changed in cloud-init:
assignee: nobody → Harald Jensås (harald-jensas)
status: Triaged → In Progress
Revision history for this message
Ryan Harper (raharper) wrote :

Merge Proposal migrated to github:


Revision history for this message
Ryan Harper (raharper) wrote :
Changed in cloud-init:
status: In Progress → Fix Committed
Revision history for this message
Chad Smith (chad.smith) wrote : Fixed in cloud-init version 19.4.

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.

Changed in cloud-init:
status: Fix Committed → Fix Released
Revision history for this message
James Falcon (falcojr) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.