SLAAC suddenly enabled in Jammy with kernel 5.15.0-56-generic #62-Ubuntu

Last night, my Ubuntu-based VPS updated itself to Linux smtp 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux and since then, SLAAC seems to be unconditionally enabled.

For weird reasons, the provider decided to have static IPv6 configuration, and set up the VPS with

net.ipv6.conf.net0.accept_ra = 0
net.ipv6.conf.net0.autoconf = 0

As I understand it, this should disable SLAAC addresses.

However, since the recent update, I do see SLAAC addresses on my net0 interface. That would by itself not be a problem, but it somehow breaks IPv6 connectivity from some but not all sources.

In my log files, I can see successful IPv6 connections to the smtp service before the reboot, but not after.

I tried removing the addresses manually, but they come back after some time.

rhialto@smtp:/var/log$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: net0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:26:48 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    altname ens3
    inet xxx.xxx.xxx.129/24 brd xxx.xxx.xxx.255 scope global dynamic net0
       valid_lft 60541sec preferred_lft 60541sec
    inet6 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:2648/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2591895sec preferred_lft 604695sec
    inet6 2a02:xxxx:xxxx:xxxx:yyyy:xxxx:xxxx:2648/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2591895sec preferred_lft 604695sec
    inet6 2a02:zzzz:zzzz:zzzz::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxx:xxxx:xxxx:2648/64 scope link 
       valid_lft forever preferred_lft forever

The desired address is near the bottom: 2a02:zzzz:zzzz:zzzz::1/64

Also it causes tools like traceroute6 to choose the wrong source address, and outgoing IPv6 connections use the wrong source address:

rhialto@smtp:$ ip -6 route get 2a00:1450:400e:810::2004
2a00:1450:400e:810::2004 from :: via fe80::wwww:wwww:wwww:f03d dev net0 proto ra src 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:2648 metric 1024 pref high

Are the Ubuntu people already aware of this issue and when will it be fixed?

Addendum: when I rebooted back to the previous version, all was well again, for a few minutes. That was Linux smtp 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:53:30 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux. Then the SLAAC addresses came back. So maybe the problem exists for longer than I thought.

I think I can answer my own question. The culprits are netplan and its accomplice system-networkd. Someone exceedingly clever has decided that apparently they should totally ignore the sysctl settings accept_ra=0 and autoconf=0, even though pretty much all documentation I found claims that these sysctls are there for this purpose.

Instead, they have their own, different, way to set accept_ra=0 and not even a way to set autoconf=0.

This makes netplan an annoying abstraction with fewer features over systemd-networkd. And that one is an annoying abstraction, with fewer features, over ifconfig and route. Whatever it was that handled /etc/network/interfaces.d/net0.cfg worked fine but apparently has been thrown under the bus. That file nicely described the config that worked, but it seems that Ubuntu doesn't use it any more.

So I solved it by adding a file /etc/netplan/60-static.yaml which adds config to the 50-cloud-init.yaml file that is generated by cloud-init. Helpfully, while creating and testing this file, netplan-get accepted my earlier attempts while netplan-try totally disagreed and sternly rejected them. Very helpful.

Can you tell that I am a huuuge fan of these packages?

network:
    version: 2
    ethernets:
        net0:
            addresses:
            - "2a02:..../64"
            routes:
                - to: ::/0
                  via: "2a02:..."
                  on-link: true
            accept-ra: false