IPv6 static address assignment should not disable router advertisement

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #2019021

Launchpad details

affected_projects = []
assignee = None
assignee_name = None
date_closed = None
date_created = 2023-05-09T17:45:38.640796+00:00
date_fix_committed = None
date_fix_released = None
id = 2019021
importance = medium
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/2019021
milestone = None
owner = notbencc
owner_name = Ben Charlton
private = False
status = triaged
submitter = notbencc
submitter_name = Ben Charlton
tags = ['ipv6']
duplicates = []

Launchpad user Ben Charlton(notbencc) wrote on 2023-05-09T17:45:38.640796+00:00

This is a bug affecting RHEL and derivatives that use cloud-init.

Back in 2020, the PR #634 was accepted that disables listening for IPv6 router advertisement when a static / static6 address is defined on RHEL and derivatives - see https://github.com/canonical/cloud-init/blob/main/cloudinit/net/sysconfig.py#L523

I'm not sure why this was proposed as the solution for what seems like a platform-specific problem, but the original author stated "It is safe to assume that if the interface is manually configured to use static ipv6 address, there's no need to wait for router advertisements."

This is incorrect, there are a number of reasons why you might define a static address but still want RA on that interface. Most obviously that it permits you to have multiple routers without needing to worry about IP address failover. This is explicitly mentioned in RFC 4861: https://www.rfc-editor.org/rfc/rfc4861#section-3.1

"Unlike in IPv4 Router Discovery, the Router Advertisement messages
do not contain a preference field. The preference field is not
needed to handle routers of different "stability"; the Neighbor
Unreachability Detection will detect dead routers and switch to a
working one."

It's perfectly valid to generate router advertisements that don't result in the generation of SLAAC addresses, or enable the M or O flags (for DHCPv6), but are simply used to advertise that one or more routers are available for a given prefix. A definitive statement for this can be found in RFC4861: https://www.rfc-editor.org/rfc/rfc4861#section-6: "Router Discovery is used to locate neighboring routers as well as learn prefixes and configuration parameters related to stateless address autoconfiguration."

Address allocation is separate from router advertisement. RA enables the use of stateless address configuration, but it is not only used for that.

Provider: Mythic Beasts
VM is Rocky Linux 8 - their latest GenericCloud image from http://dl.rockylinux.org/pub/rocky/8/images/x86_64/

network-config:

config:

• mac_address: 52:54:00:bc:1f:7f
  name: eth0
  subnets:
  • address: 2a00:1098:82::7:48
    netmask: 112
    type: static
    type: physical
• address:
  • 2a00:1098:0:82:1000:3b:0:1
  • 2a00:1098:0:80:1000:3b:0:1
    search: mythic-beasts.com
    type: nameserver
    version: 1

Results in sysconfig network:
BOOTPROTO=none
DEVICE=eth0
HWADDR=52:54:00:bc:1f:7f
IPV6ADDR=2a00:1098:82::7:48/64
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6_FORCE_ACCEPT_RA=no
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

This VM has a static address but relies on RA for routes, and the presence of IPV6_AUTOCONF=no / IPV6_FORCE_ACCEPT_RA=no means no default route, so no working DNS, and no phone home.

I can't easily get the full set of logs out as this has no working networking and is only half configured, but console output shows:

[ 17.065634] cloud-init[940]: Cloud-init v. 22.1-5.el8.0.1 running 'init' at Tue, 09 May 2023 16:03:08 +0000. Up 15.69 seconds.
[ 17.076141] cloud-init[940]: ci-info: ++++++++++++++++++++++++++++++++++++++Net device info++++++++++++++++++++++++++++++++++++++
[ 17.087098] cloud-init[940]: ci-info: +--------+------+----------------------------+---------------+--------+-------------------+
[ 17.098070] cloud-init[940]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address |
[ 17.109070] cloud-init[940]: ci-info: +--------+------+----------------------------+---------------+--------+-------------------+
[ 17.120087] cloud-init[940]: ci-info: | eth0 | True | 10.23.42.80 | 255.255.255.0 | global | 52:54:00:04:b6:ac |
[ 17.131874] cloud-init[940]: ci-info: | eth0 | True | 2a00:1098:82::7:73/64 | . | global | 52:54:00:04:b6:ac |
[ 17.142110] cloud-init[940]: ci-info: | eth0 | True | fe80::5054:ff:fe04:b6ac/64 | . | link | 52:54:00:04:b6:ac |
[ 17.153082] cloud-init[940]: ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . |
[ 17.164085] cloud-init[940]: ci-info: | lo | True | ::1/128 | . | host | . |
[ 17.175083] cloud-init[940]: ci-info: +--------+------+----------------------------+---------------+--------+-------------------+
[ 17.186072] cloud-init[940]: ci-info: ++++++++++++++++++++++++++++Route IPv4 info+++++++++++++++++++++++++++++
[ 17.198076] cloud-init[940]: ci-info: +-------+-------------+------------+---------------+-----------+-------+
[ 17.209090] cloud-init[940]: ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags |
[ 17.220074] cloud-init[940]: ci-info: +-------+-------------+------------+---------------+-----------+-------+
[ 17.231073] cloud-init[940]: ci-info: | 0 | 0.0.0.0 | 10.23.42.1 | 0.0.0.0 | eth0 | UG |
[ 17.242071] cloud-init[940]: ci-info: | 1 | 10.23.42.0 | 0.0.0.0 | 255.255.255.0 | eth0 | U |
[ 17.253082] cloud-init[940]: ci-info: +-------+-------------+------------+---------------+-----------+-------+
[ 17.263084] cloud-init[940]: ci-info: ++++++++++++++++++++++Route IPv6 info++++++++++++++++++++++
[ 17.274073] cloud-init[940]: ci-info: +-------+-------------------+---------+-----------+-------+
[ 17.285071] cloud-init[940]: ci-info: | Route | Destination | Gateway | Interface | Flags |
[ 17.295415] cloud-init[940]: ci-info: +-------+-------------------+---------+-----------+-------+
[ 17.306072] cloud-init[940]: ci-info: | 1 | 2a00:1098:82::/64 | :: | eth0 | U |
[ 17.317156] cloud-init[940]: ci-info: | 2 | fe80::/64 | :: | eth0 | U |
[ 17.328075] cloud-init[940]: ci-info: | 4 | multicast | :: | eth0 | U |
[ 17.339078] cloud-init[940]: ci-info: +-------+-------------------+---------+-----------+-------+

As you can see, there's no IPv6 default route.

Compare this with a Debian VM where the same config works as expected:

[ 12.127521] cloud-init[402]: Cloud-init v. 22.4.2 running 'init' at Tue, 09 May 2023 17:44:28 +0000. Up 12.11 seconds.
[ 12.148515] cloud-init[402]: ci-info: +++++++++++++++++++++++++++++++++++++Net device info++++++++++++++++++++++++++++++++++++++
[ 12.150615] cloud-init[402]: ci-info: +--------+------+---------------------------+---------------+--------+-------------------+
[ 12.152672] cloud-init[402]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address |
[ 12.154723] cloud-init[402]: ci-info: +--------+------+---------------------------+---------------+--------+-------------------+
[ 12.156766] cloud-init[402]: ci-info: | eth0 | True | 10.23.42.18 | 255.255.255.0 | global | 52:54:00:e1:0a:2d |
[ 12.158789] cloud-init[402]: ci-info: | eth0 | True | 2a00:1098:82::7:34/64 | . | global | 52:54:00:e1:0a:2d |
[ 12.160742] cloud-init[402]: ci-info: | eth0 | True | fe80::5054:ff:fee1:a2d/64 | . | link | 52:54:00:e1:0a:2d |
[ 12.162715] cloud-init[402]: ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . |
[ 12.164678] cloud-init[402]: ci-info: | lo | True | ::1/128 | . | host | . |
[ 12.166633] cloud-init[402]: ci-info: +--------+------+---------------------------+---------------+--------+-------------------+
[ 12.168592] cloud-init[402]: ci-info: ++++++++++++++++++++++++++++Route IPv4 info+++++++++++++++++++++++++++++
[ 12.170335] cloud-init[402]: ci-info: +-------+-------------+------------+---------------+-----------+-------+
[ 12.172075] cloud-init[402]: ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags |
[ 12.173811] cloud-init[402]: ci-info: +-------+-------------+------------+---------------+-----------+-------+
[ 12.175551] cloud-init[402]: ci-info: | 0 | 0.0.0.0 | 10.23.42.1 | 0.0.0.0 | eth0 | UG |
[ 12.177293] cloud-init[402]: ci-info: | 1 | 10.23.42.0 | 0.0.0.0 | 255.255.255.0 | eth0 | U |
[ 12.179043] cloud-init[402]: ci-info: +-------+-------------+------------+---------------+-----------+-------+
[ 12.181101] cloud-init[402]: ci-info: ++++++++++++++++++++++++++++++Route IPv6 info+++++++++++++++++++++++++++++++
[ 12.183200] cloud-init[402]: ci-info: +-------+-------------------+--------------------------+-----------+-------+
[ 12.185253] cloud-init[402]: ci-info: | Route | Destination | Gateway | Interface | Flags |
[ 12.187282] cloud-init[402]: ci-info: +-------+-------------------+--------------------------+-----------+-------+
[ 12.189276] cloud-init[402]: ci-info: | 1 | 2a00:1098:82::/64 | :: | eth0 | U |
[ 12.191261] cloud-init[402]: ci-info: | 2 | fe80::/64 | :: | eth0 | U |
[ 12.193189] cloud-init[402]: ci-info: | 3 | ::/0 | fe80::4de:15ff:fe2f:9d3d | eth0 | UGe |
[ 12.195133] cloud-init[402]: ci-info: | 5 | local | :: | eth0 | U |
[ 12.197041] cloud-init[402]: ci-info: | 6 | local | :: | eth0 | U |
[ 12.198882] cloud-init[402]: ci-info: | 7 | multicast | :: | eth0 | U |
[ 12.200641] cloud-init[402]: ci-info: +-------+-------------------+--------------------------+-----------+-------+

[ubuntu-server-builder]

Launchpad user James Falcon(falcojr) wrote on 2023-05-09T18:51:07.952615+00:00

Thanks for the thorough bug report. The fix itself looks like it'll be fairly simple, but there may need to be some additional discussion/testing to figure out why the initial change was deemed necessary and if undoing would break any other use cases, but that can probably be worked out in PR review.

Since you have already identified the problematic code, are you also interested in putting up the PR?

[ubuntu-server-builder]

Launchpad user Ben Charlton(notbencc) wrote on 2023-05-10T09:50:12.396568+00:00

Yes, happy to do so. I'll check if I can repro in fedora this morning (I expect so) then log a bug with RH - then hopefully get a clear answer on what they were trying to solve.

[bcc]

Following up on this here - sorry for the delay doing so. I can repro on Fedora, but it turns out that's driving NetworkManager directly, which also has this issue. We still think this is broken behaviour but realise it's a niche issue.

A proper solution would require some quite significant changes to the way NM handles ipv6.method and ipv6.ignore-auto-dns, and as such a fix for this issue in cloud-init sysconfig for RHEL derivatives isn't a complete fix and may be short lived.

We're going to start supplying a link-local default gateway instead, which resolves the problem for both OS images, and means a more timely fix on our side.