IPv6 static address assignment should not disable router advertisement
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Expired
|
Medium
|
Unassigned |
Bug Description
This is a bug affecting RHEL and derivatives that use cloud-init.
Back in 2020, the PR https:/
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:/
"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:/
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://
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:
- 2a00:1098:
search: mythic-beasts.com
type: nameserver
version: 1
Results in sysconfig network:
BOOTPROTO=none
DEVICE=eth0
HWADDR=
IPV6ADDR=
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6_FORCE_
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_
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: +++++++
[ 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:
[ 17.142110] cloud-init[940]: ci-info: | eth0 | True | fe80::5054:
[ 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: +++++++
[ 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: +++++++
[ 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: +++++++
[ 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:
[ 12.160742] cloud-init[402]: ci-info: | eth0 | True | fe80::5054:
[ 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: +++++++
[ 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: +++++++
[ 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:
[ 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: +------
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?