deprecated ipv6 address causes 'registering withdrawing address record' message to flood journal every few seconds

[cmurf]

Summary: When ipv6.ip6-privacy 2 (enabled, prefer temporary IP) is set, eventually preferred_lft reaches 0 seconds and that address becomes deprecated at which point avahi-daemon goes crazy and starts to flood the journal every three seconds. Fully 80% of the journal is full of these messages.

Jan 25 10:50:20 f23m.localdomain avahi-daemon[15925]: Registering new address record for 2601:282:702:b65c:3c32:c570:6607:a8c on enp2s0f0.. Jan 25 10:50:20 f23m.localdomain avahi-daemon[15925]: Withdrawing address record for 2601:282:702:b65c:3c32:c570:6607:a8c on enp2s0f0. Jan 25 10:50:23 f23m.localdomain avahi-daemon[15925]: Registering new address record for 2601:282:702:b65c:3c32:c570:6607:a8c on enp2s0f0.. Jan 25 10:50:23 f23m.localdomain avahi-daemon[15925]: Withdrawing address record for 2601:282:702:b65c:3c32:c570:6607:a8c on enp2s0f0. Jan 25 10:50:26 f23m.localdomain avahi-daemon[15925]: Registering new address record for 2601:282:702:b65c:3c32:c570:6607:a8c on enp2s0f0.*. Jan 25 10:50:26 f23m.localdomain avahi-daemon[15925]: Withdrawing address record for 2601:282:702:b65c:3c32:c570:6607:a8c on enp2s0f0.

ipv6 privacy extension RFC4941 behavior was default in Fedora 22 but due to a bug (listed below) it's not default in Fedora 23, otherwise this avahi behavior would be significantly more widespread.

Reproduced on two systems with following configurations: Fedora 23 Server on Intel NUC kernel 4.4.0-1.fc24.x86_64 avahi-0.6.31-43.fc23.x86_64 ##default avahi-daemon.conf

Fedora 23 Workstation on Macbook Pro kernel 4.4.0-1.fc24.x86_64 avahi-0.6.32-0.4.rc.fc23.x86_64

Red Hat BZ version of this report: avahi-daemon permanently registers and withdraws address record https://bugzilla.redhat.com/show_bug.cgi?id=1221676

NM generated IPv6 addresses leak your MAC address to the world https://bugzilla.redhat.com/show_bug.cgi?id=1279242

[zman0900]

This isn't just limited to Fedora. I can reproduce it on Arch too. Running NetworkManager 1.0.10-2 with ip6-privacy=2, avahi 0.6.32-2, and linux 4.4.5.

I also have the following set in sysctl (br0 is my main connection): net.ipv6.conf.all.use_tempaddr = 2 net.ipv6.conf.default.use_tempaddr = 2 net.ipv6.conf.br0.use_tempaddr = 2

[lorenz]

Happens on Ubuntu 17.04 too, Linux 4.10.0, Avahi 0.6.32-1ubuntu1, temporary addresses configured on NetworkManager.

[lathiat]

Incorrect commit message, re-opening

[chrisbainbridge]

I see this log spam every few minutes on Debian (buster), "Withdrawing address record", "Leaving mDNS multicast group on interface", "Joining mDNS multicast group on interface".

This is a new, default install with no config changes related to avahi.

I ran tcpdump on the interface and the withdrawal messages appear to be caused by the router sending an IPv6 router advertisement. I confirmed that it is disabled with:

ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -j DROP

Is this expected? The router advertisements don't seem to do anything other than filling up the logs, the addresses remain the same.

[chrisbainbridge]

Like the Launchpad bug reporter, I've also noticed that Chrome occasionally interrupts the loading of a page and tells me that the network changed. I hadn't really associated it with the avahi log oddness until I came across the launchpad bug and saw the mention of the same issue in Chrome. Is that what is happening here - every time the router sends an IPv6 router advertisement, avahi removes all the addresses from the interface (to be replaced with the same addresses), which takes down all active Chrome requests?

[cweiske]

Same issue on Debian 11 with avahi-daemon 0.8-5. Temporary addresses are not enabled in sysctl. It seems to have to do with router advertisements here, too - the span between "Withdrawing" and the next "Registering" is ~8 minutes. The advertisements come from the same machine and are sent by dnsmasq:

Dec  8 15:12:26 dojo dnsmasq-dhcp[833]: RTR-ADVERT(eth0) fdc3:e153::
Dec  8 15:12:26 dojo avahi-daemon[666]: Registering new address record for fdc3:e153::d250:99ff:fe2c:f8c8 on eth0.*.
Dec  8 15:12:26 dojo avahi-daemon[666]: Withdrawing address record for fdc3:e153::d250:99ff:fe2c:f8c8 on eth0.

[mvduin]

It seems to be caused by the "preferred lifetime" of the prefix expiring, i.e. the router is sending router advertisements with a preferred lifetime which is shorter than the interval of the advertisements. This will create more problems than just log spam from avahi since the kernel will not use a prefix for new connections once its preferred lifetime has expired.

[mvduin]

(i.e. the only role avahi has in this issue is that it's making the issue more visible by logging about it.)

You should be able to confirm this with ip -6 addr: the affected address will have a preferred_lft that drops down to zero at which point the deprecated flag appears on the address and avahi withdraws the address, until the next router advertisement resets the preferred_lft to a non-zero value again which causes the deprecated flag to disappear and avahi to register the address again.

[cweiske]

I indeed have a faulty dnsmasq configuration:

dhcp-range=fdc3:e153::,ra-only,64,deprecated

For IPv6 ranges, the lease time maybe "deprecated"; this sets the preferred lifetime sent in a DHCP lease or router advertisement to zero, which causes clients to use other addresses, if available, for new connections as a prelude to renumbering.

I have no idea why I set this "deprecated" lease time. Probably copied it from some example :(

[mvduin]

Also, getting the address periodically withdrawn because it keeps expiring in between router advertisements (which is a router bug, not an avahi bug) is not actually related to this bug report, which is about avahi apparently flooding these messages when using IPv6 privacy enhancement (under specific conditions I assume, or there'd be way more people yelling about it).

[evverx]

Could anyone try https://github.com/avahi/avahi/pull/589 to see if it works?

[gschintgen]

I know this probably isn't very helpful since I don't have time right now to dig further, but I recently observed avahi often having high cpu usage (~30%!) and the log is spammed with the following:

May 04 16:40:20 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:40:22 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:40:26 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:40:27 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:40:27 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:40:28 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:40:28 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:40:29 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:40:29 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:40:30 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:40:30 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:40:31 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:40:35 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:40:36 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:40:36 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:40:37 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:40:55 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:40:56 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:40:56 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:40:57 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:40:57 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:40:58 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:41:02 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:41:03 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:41:03 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:41:04 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:41:04 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:41:05 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.
May 04 16:41:05 desktop avahi-daemon[984]: Registering new address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.*.
May 04 16:41:06 desktop avahi-daemon[984]: Withdrawing address record for fdxx::xxxx:xxxx:xxxx:4c17 on enp6s0.

My network setup is unfortunately rather complex: I have one fdxx prefix configured for local usage, a second one for a wireguard vpn. But this issue of having high cpu usage is rather recent. It could be related to me recently starting to use incus also on that system (my desktop PC). I added its .incus local domain to resolvectl as per the instructions. I'm currently also doing quite a bit of experimentation with Sunshine development and packaging. AFAIK Sunshine is also announcing "stuff" on the network via avahi. This could also be related.

[evverx]

avahi often having high cpu usage (~30%!)

It looks like https://github.com/avahi/avahi/issues/210 (It would be great if you could bump avahi to v0.9-rc1 just to rule out https://github.com/avahi/avahi/pull/366 though).

Could you also collect packets to see how often router advertisements are received and what they look like (or whether they are received at all)?

[gschintgen]

Thanks for the quick return with all those useful pointers! I'll be on the lookout to add anything useful I can find. (It depends on how confident I am to be able to 100% revert installing avahi from source before the upcoming upgrade of Ubuntu 22.04 to Ubuntu 24.04...)

[gschintgen]

Could you also collect packets to see how often router advertisements are received and what they look like (or whether they are received at all)?

I'm optimistic that I found the culprit ~~and eliminated it~~. Here are the details in case it proves useful, either for the dev team or for other users:

Quite some time ago I had my (consumer) router advertise a ULA of fd00::. (This ULA is an invitation for collisions and I changed it later on.) It was this prefix that was still showing up in the redacted journalctl output I posted previously. (It didn't click immediately that this range should not appear at all. I configured all of this a few years ago.)

Anyway this old prefix must have stuck in the router's config somehow. Using sudo tcpdump -vvvv -ttt -i enp6s0 icmp6 and 'ip6[40] = 134' (in order to show all RAs) I noticed that it was still announced very frequently: My router still announced it as a deprecated address:

00:00:00.673401 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 168) _gateway > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 168
	hop limit 255, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
	  prefix info option (3), length 32 (4): 2axx:xx:xx::/64, Flags [onlink, auto], valid time 7200s, pref. time 3600s
(...)
	  prefix info option (3), length 32 (4): fd00::/64, Flags [onlink, auto], valid time 0s, pref. time 0s
	    0x0000:  40c0 0000 0000 0000 0000 0000 0000 fd00
	    0x0010:  0000 0000 0000 0000 0000 0000 0000

This prefix was then also picked up by a local dnsmasq instance that has (among others) the following config directives:

dhcp-range=::,constructor:eth0,ra-names
ra-param=eth0,low,0,0

(I set this up a long time ago. The intent was to detect the ULA names and use them for answering local DNS queries. I'm not sure this setup is totally correct, but it's working.) Unfortunately dnsmasq was itself sending out its own RAs (with disabled routes, the last 0 in the ra-param above) rather frequently and those RAs also included that completely unwanted and outdated fd00:: prefix.

In essence I had a lot of RAs announcing a bogus deprecated prefix (valid=0s, pref. time 0s) and each one triggered avahi's machinery...

~~The solution was to change back the router's config from my current prefix to the old fd00 prefix, save, revert it back to the current prefix, save. Then reboot it. This got the config "unstuck". After also restarting dnsmasq and avahi on my desktop there is now no longer any trace of the fd00 prefix on my network. And the log spam is history...~~ Just as I'm done writing it up, I'm noticing that the stubborn fd00 prefix is back :-( I might have to factory reset the router. It will be such a pain if I have to redo it all manually in order to avoid restoring from a possibly problematic config backup.

Anyway, I'm not sure that avahi should do its whole register and withdraw dance for a deprecated prefix. As far as I can tell there are only valid=0s RAs.

[gschintgen]

Just as I'm done writing it up, I'm noticing that the stubborn fd00 prefix is back :-(

It's back in the router's RAs, but there is no longer the avahi log spam. I probably wasn't careful enough in reading the tcpdump output: The RAs sent out by the router have a validity of 0 seconds. But the prefix still ended up on the interface dnsmasq (on another host) was using to construct DNS entries. It then sent out RAs of its own and those indeed had a non-zero validity!

Since the reboot, dnsmasq no longer picks up the fd00 prefix. That's why the log spam ended.

To sum up: probably admin error (for having a weird and complex setup when it comes to RAs/DNS/DHCPv6) combined with a router that stubbornly refuses to forget that custom prefix ever existed. The remaining unwanted RAs for fd00 all have validity of 0 seconds and avahi does the right thing: nothing.

[jpetazzo]

I'm seeing a similar problem on a Debian machine, and it led me to that issue.

First of all, I acknowledge (as others have pointed out above) that this is not a problem with avahi; avahi just happens to provide useful logs that indicate that something is wrong. And the reason why I'm adding this message here, is because this seems to be the corner of the internet with the highest density of folks who (1) experience this problem too, (2) seem smart enough to contribute to a resolution :)

Symptoms:

• "network configuration has changed" messages in browser (Chrome)
• random network disruption (webpages load partially, some actions don't work...)
• DNS resolution seems fine; speedtest shows solid 100 Mb/s connection; other machines on the same LAN are fine
• the machine can be fine for a few hours, and then suddenly the problem starts, and seems to continue for a few hours, then goes away

While the problem is happening, in the logs, we see this, repeating forever:

May 28 14:56:49 zagreb avahi-daemon[725109]: Registering new address record for x:x:x:x:yyyy:adff:fe54:yyyy on enp0s31f6.*.
May 28 14:56:49 zagreb avahi-daemon[725109]: Registering new address record for x:x:x:x:zzzz:9076:738e:zzzz on enp0s31f6.*.
May 28 14:56:50 zagreb avahi-daemon[725109]: Withdrawing address record for x:x:x:x:yyyy:adff:fe54:yyyy on enp0s31f6.
May 28 14:56:50 zagreb avahi-daemon[725109]: Withdrawing address record for x:x:x:x:zzzz:9076:738e:zzzz on enp0s31f6.
May 28 14:56:52 zagreb avahi-daemon[725109]: Registering new address record for x:x:x:x:yyyy:adff:fe54:yyyy on enp0s31f6.*.
May 28 14:56:52 zagreb avahi-daemon[725109]: Registering new address record for x:x:x:x:zzzz:9076:738e:zzzz on enp0s31f6.*.
May 28 14:56:53 zagreb avahi-daemon[725109]: Withdrawing address record for x:x:x:x:yyyy:adff:fe54:yyyy on enp0s31f6.
May 28 14:56:53 zagreb avahi-daemon[725109]: Withdrawing address record for x:x:x:x:zzzz:9076:738e:zzzz on enp0s31f6.

→ It looks like every 3 seconds, an address is added, stays 1 second, and is removed.

The IP addresses on that machine look like this:

ip addr show dev enp0s31f6
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether yy:yy:ad:54:yy:yy brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.22/24 brd 10.0.0.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 64679sec preferred_lft 64679sec
    inet6 x:x:x:x::f123/128 scope global dynamic noprefixroute
       valid_lft 41976sec preferred_lft 41976sec
    inet6 x:x:x:x:zzzz:9076:738e:zzzz/64 scope global temporary deprecated dynamic
       valid_lft 3903sec preferred_lft 0sec
    inet6 x:x:x:x:yyyy:adff:fe54:yyyy/64 scope global deprecated dynamic mngtmpaddr noprefixroute
       valid_lft 3903sec preferred_lft 0sec
    inet6 fe80::yyyy:adff:fe54:yyyy/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

→ We can see that the addresses being added/removed show up with a preferred_lft 0sec.

If we look at the simultaneous output of ip mon and tcpdump, we see this, which repeats forever:

14:49:12.799931 2c:58:4f:7c:4f:10 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 158: fe80::2e58:4fff:fe7c:4f10 > ff02::1: ICMP6, router advertisement, length 104
2: enp0s31f6    inet6 x:x:x:x:yyyy:adff:fe54:yyyy/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 4580sec preferred_lft 1sec
2: enp0s31f6    inet6 x:x:x:x:zzzz:9076:738e:zzzz/64 scope global temporary dynamic
       valid_lft 4580sec preferred_lft 1sec
[1 second pause]
2: enp0s31f6    inet6 x:x:x:x:yyyy:adff:fe54:yyyy/64 scope global deprecated dynamic mngtmpaddr noprefixroute
       valid_lft 4579sec preferred_lft 0sec
2: enp0s31f6    inet6 x:x:x:x:zzzz:9076:738e:zzzz/64 scope global temporary deprecated dynamic
       valid_lft 4579sec preferred_lft 0sec
[2 seconds pause]

→ Every 3 seconds, we receive a router advertisement; this adds both addresses with a preferred_lft of 1sec, and then they get removed 1 second later?

Checking the router advertisement gives this:

$ rdisc6 -1 eno2 | sed -E 's/[0-9a-fA-F]+:/x:/g'
Soliciting x::2 (x::2) on eno2...

Hop limit                 :           64 (      0x40)
Stateful address conf.    :          Yes
Stateful other conf.      :          Yes
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :      3600000 (0x0036ee80) milliseconds
Retransmit time           :  unspecified (0x00000000)
 Recursive DNS server     : x:x:x:x:x:x:x:4f10
  DNS server lifetime     :          300 (0x0000012c) seconds
 Prefix                   : x:x:x:x::/64
  On-link                 :          Yes
  Autonomous address conf.:          Yes
  Valid time              :            0 (0x00000000) seconds
  Pref. time              :            0 (0x00000000) seconds
 Route                    : ::/0
  Route preference        :       medium
  Route lifetime          :         1800 (0x00000708) seconds
 Source link-layer address: x:x:x:x:x:10
 from x::x:x:x:4f10

→ It looks like the Valid time and Pref. time are zero, which might(?) be incorrect.

The machine is connected to a Netgear R6400. This is a rather old router (2017ish?) and the software is probably not great, so perhaps it's generating invalid router advertisements. This router is itself chained behind the ISP router. In the coming days I'll try to compare router advertisement packets sent by the other router; and I want to understand what would be the meaning of a the zero valid time and pref time; and how to make the machine ignore that if it's invalid. Perhaps disabling privacy extensions addresses is the way. 🤷🏻

[evverx]

what would be the meaning of a the zero valid time and pref time

Zero valid lifetimes are correct. According to https://datatracker.ietf.org/doc/html/rfc4861#section-6.3.4 - If the prefix is already present in the host's Prefix List as the result of a previously received advertisement, reset its invalidation timer to the Valid Lifetime value in the Prefix Information option. If the new Lifetime value is zero, time-out the prefix immediately (see Section 6.3.5). - If the Prefix Information option's Valid Lifetime field is zero, and the prefix is not present in the host's Prefix List, silently ignore the option.

Though it is undesirable to continue advertising that prefix with a zero lifetime forever :-)

If the prefix is the same it should be ignored by whatever manages network interfaces (and it shouldn't reach avahi). As far as I can remember there was a bug in systemd-networkd where it didn't ignore zero valid lifetimes in scenarios like that but it was fixed at some point (unreleased) v256 should pass the IPv6 compliance test I think.

[evverx]

Before I forget I launched a Debian Testing container and started sending RAs with zero valid/preferred lifetimes repeatedly. When the interfaces were managed by systemd-networkd avahi didn't complain repeatedly. When I disabled it and switched to the kernel I got

May 28 18:17:49 system avahi-daemon[398]: Registering new address record for f302::a865:3aff:fe4b:dd5d on host0.*.
May 28 18:17:49 system avahi-daemon[398]: Withdrawing address record for f302::a865:3aff:fe4b:dd5d on host0.
May 28 18:17:50 system avahi-daemon[398]: Registering new address record for f302::a865:3aff:fe4b:dd5d on host0.*.
May 28 18:17:50 system avahi-daemon[398]: Withdrawing address record for f302::a865:3aff:fe4b:dd5d on host0.
May 28 18:17:51 system avahi-daemon[398]: Registering new address record for f302::a865:3aff:fe4b:dd5d on host0.*.
May 28 18:17:51 system avahi-daemon[398]: Withdrawing address record for f302::a865:3aff:fe4b:dd5d on host0.
May 28 18:17:52 system avahi-daemon[398]: Registering new address record for f302::a865:3aff:fe4b:dd5d on host0.*.
May 28 18:17:52 system avahi-daemon[398]: Withdrawing address record for f302::a865:3aff:fe4b:dd5d on host0.
May 28 18:17:53 system avahi-daemon[398]: Registering new address record for f302::a865:3aff:fe4b:dd5d on host0.*.
May 28 18:17:53 system avahi-daemon[398]: Withdrawing address record for f302::a865:3aff:fe4b:dd5d on host0.
May 28 18:17:54 system avahi-daemon[398]: Registering new address record for f302::a865:3aff:fe4b:dd5d on host0.*.
May 28 18:17:54 system avahi-daemon[398]: Withdrawing address record for f302::a865:3aff:fe4b:dd5d on host0.
May 28 18:17:55 system avahi-daemon[398]: Registering new address record for f302::a865:3aff:fe4b:dd5d on host0.*.
May 28 18:17:55 system avahi-daemon[398]: Withdrawing address record for f302::a865:3aff:fe4b:dd5d on host0.
May 28 18:17:56 system avahi-daemon[398]: Registering new address record for f302::a865:3aff:fe4b:dd5d on host0.*.
May 28 18:17:56 system avahi-daemon[398]: Withdrawing address record for f302::a865:3aff:fe4b:dd5d on host0.
May 28 18:17:57 system avahi-daemon[398]: Registering new address record for f302::a865:3aff:fe4b:dd5d on host0.*.
May 28 18:17:57 system avahi-daemon[398]: Withdrawing address record for f302::a865:3aff:fe4b:dd5d on host0.

[evverx]

Based on my experiments with NetworkManager RAs with zero valid lifetimes sent repeatedly don't trigger all those avahi log messages either so it seems to only happen when those RAs are sent repeatedly very often and they are handled by the kernel directly.