IPv6 mngtmpaddr flapping on interface configured for SLAAC

dmtucker · 30. Juni 2023

I've been using SLAAC for a long time, but I recently got a new router (Google Nest Wifi Pro).

Since then, I've been frequently losing my primary IPv6 address, despite its valid_lft not expiring and the advertised prefix not changing.

It will disappear for a few minutes then come back. This appears to be a reaction to router advertisements that do not include a prefix (only a route).

I'm able to tell that by running 2 terminal sessions:

sudo radvdump | ts
This will show timestamped router advertisements as they arrive.
while sleep 1; do echo; date -Isec; ip -6 address show scope global primary; done
This shows the mngtmpaddr every second.

We start off looking good:

1:

Code

Jun 29 20:10:18 #
Jun 29 20:10:18 # radvd configuration generated by radvdump 2.18
Jun 29 20:10:18 # based on Router Advertisement from fe80::<redacted>
Jun 29 20:10:18 # received by interface eno1
Jun 29 20:10:18 #
Jun 29 20:10:18 
Jun 29 20:10:18 interface eno1
Jun 29 20:10:18 {
Jun 29 20:10:18     AdvSendAdvert on;
Jun 29 20:10:18     # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
Jun 29 20:10:18     AdvManagedFlag off;
Jun 29 20:10:18     AdvOtherConfigFlag on;
Jun 29 20:10:18     AdvReachableTime 0;
Jun 29 20:10:18     AdvRetransTimer 0;
Jun 29 20:10:18     AdvCurHopLimit 64;
Jun 29 20:10:18     AdvDefaultLifetime 3600;
Jun 29 20:10:18     AdvHomeAgentFlag off;
Jun 29 20:10:18     AdvDefaultPreference medium;
Jun 29 20:10:18     AdvLinkMTU 1500;
Jun 29 20:10:18     AdvSourceLLAddress on;
Jun 29 20:10:18 
Jun 29 20:10:18     prefix 2601:646:a001:7b3::/64
Jun 29 20:10:18     {
Jun 29 20:10:18         AdvValidLifetime 6396;
Jun 29 20:10:18         AdvPreferredLifetime 6396;
Jun 29 20:10:18         AdvOnLink on;
Jun 29 20:10:18         AdvAutonomous on;
Jun 29 20:10:18         AdvRouterAddr off;
Jun 29 20:10:18     }; # End of prefix definition
Jun 29 20:10:18 
Jun 29 20:10:18 
Jun 29 20:10:18     RDNSS 2601:646:a001:7b3:<redacted>
Jun 29 20:10:18     {
Jun 29 20:10:18         AdvRDNSSLifetime infinity; # (0xffffffff)
Jun 29 20:10:18     }; # End of RDNSS definition
Jun 29 20:10:18 
Jun 29 20:10:18 }; # End of interface definition

Alles anzeigen

2:

Code

2023-06-29T20:10:19-07:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2601:646:a001:7b3:<redacted>/64 scope global tentative dynamic mngtmpaddr noprefixroute 
       valid_lft 6396sec preferred_lft 6396sec

2023-06-29T20:10:20-07:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2601:646:a001:7b3:<redacted>/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 6395sec preferred_lft 6395sec

...

Alles anzeigen

Then, a few minutes later, another RA comes in with only a route (no prefix), and the IPv6 address goes away:

1:

Code

Jun 29 20:14:38 #
Jun 29 20:14:38 # radvd configuration generated by radvdump 2.18
Jun 29 20:14:38 # based on Router Advertisement from fe80::<redacted>
Jun 29 20:14:38 # received by interface eno1
Jun 29 20:14:38 #
Jun 29 20:14:38 
Jun 29 20:14:38 interface eno1
Jun 29 20:14:38 {
Jun 29 20:14:38     AdvSendAdvert on;
Jun 29 20:14:38     # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
Jun 29 20:14:38     AdvManagedFlag off;
Jun 29 20:14:38     AdvOtherConfigFlag on;
Jun 29 20:14:38     AdvReachableTime 0;
Jun 29 20:14:38     AdvRetransTimer 0;
Jun 29 20:14:38     AdvCurHopLimit 64;
Jun 29 20:14:38     AdvDefaultLifetime 3600;
Jun 29 20:14:38     AdvHomeAgentFlag off;
Jun 29 20:14:38     AdvDefaultPreference medium;
Jun 29 20:14:38 
Jun 29 20:14:38     route fd45:d984:d7e3:1::/64
Jun 29 20:14:38     {
Jun 29 20:14:38         AdvRoutePreference low;
Jun 29 20:14:38         AdvRouteLifetime 1800;
Jun 29 20:14:38     }; # End of route definition
Jun 29 20:14:38 
Jun 29 20:14:38 }; # End of interface definition

Alles anzeigen

2:

Code

2023-06-29T20:14:38-07:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2601:646:a001:7b3:<redacted>/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 6137sec preferred_lft 6137sec

2023-06-29T20:14:39-07:00

2023-06-29T20:14:40-07:00

2023-06-29T20:14:41-07:00

2023-06-29T20:14:42-07:00

2023-06-29T20:14:43-07:00

...

Alles anzeigen

Then, the original RA comes through again, and we're back to good:

1:

Code

Jun 29 20:15:58 #
Jun 29 20:15:58 # radvd configuration generated by radvdump 2.18
Jun 29 20:15:58 # based on Router Advertisement from fe80::<redacted>
Jun 29 20:15:58 # received by interface eno1
Jun 29 20:15:58 #
Jun 29 20:15:58 
Jun 29 20:15:58 interface eno1
Jun 29 20:15:58 {
Jun 29 20:15:58     AdvSendAdvert on;
Jun 29 20:15:58     # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
Jun 29 20:15:58     AdvManagedFlag off;
Jun 29 20:15:58     AdvOtherConfigFlag on;
Jun 29 20:15:58     AdvReachableTime 0;
Jun 29 20:15:58     AdvRetransTimer 0;
Jun 29 20:15:58     AdvCurHopLimit 64;
Jun 29 20:15:58     AdvDefaultLifetime 3600;
Jun 29 20:15:58     AdvHomeAgentFlag off;
Jun 29 20:15:58     AdvDefaultPreference medium;
Jun 29 20:15:58     AdvLinkMTU 1500;
Jun 29 20:15:58     AdvSourceLLAddress on;
Jun 29 20:15:58 
Jun 29 20:15:58     prefix 2601:646:a001:7b3::/64
Jun 29 20:15:58     {
Jun 29 20:15:58         AdvValidLifetime 6056;
Jun 29 20:15:58         AdvPreferredLifetime 6056;
Jun 29 20:15:58         AdvOnLink on;
Jun 29 20:15:58         AdvAutonomous on;
Jun 29 20:15:58         AdvRouterAddr off;
Jun 29 20:15:58     }; # End of prefix definition
Jun 29 20:15:58 
Jun 29 20:15:58 
Jun 29 20:15:58     RDNSS 2601:646:a001:7b3:<redacted>
Jun 29 20:15:58     {
Jun 29 20:15:58         AdvRDNSSLifetime infinity; # (0xffffffff)
Jun 29 20:15:58     }; # End of RDNSS definition
Jun 29 20:15:58 
Jun 29 20:15:58 }; # End of interface definition

Alles anzeigen

2:

Code

2023-06-29T20:15:58-07:00

2023-06-29T20:15:59-07:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2601:646:a001:7b3:<redacted>/64 scope global tentative dynamic mngtmpaddr noprefixroute 
       valid_lft 6056sec preferred_lft 6056sec

2023-06-29T20:16:00-07:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2601:646:a001:7b3:<redacted>/64 scope global tentative dynamic mngtmpaddr noprefixroute 
       valid_lft 6055sec preferred_lft 6055sec

...

Alles anzeigen

Note that the *_lft values resume where they were.

What's causing this behavior?

It doesn't happen with my Pop!_OS (Ubuntu) laptop via WiFi, my old MacBook Pro (wired or WiFi), or any other device I have AFAICT

dmtucker · 1. Juli 2023

This problem persists if I replace OMV's wired connection with a wireless one.

dmtucker · 2. Juli 2023

More data points:

The issue does NOT reproduce on a Raspberry Pi (wired).
Kernel versions:
- OMV server: Linux 6.1.0-0.deb11.7-amd64 x86_64
- Raspberry Pi: Linux 6.1.21+ armv6l (does NOT repro)
- Pop!_OS laptop: Linux 6.2.6-76060206-generic x86_64 (does NOT repro)
The issue still happens with addr_gen_mode=3 set on the interface.
(addr_gen_mode=1 seems to prevent IPv6 from working altogether, and addr_gen_mode=2 gives "Invalid argument".)
This may be related to Thread/Matter support:
https://www.reddit.com/r/ipv6/…tm_medium=web2x&context=3

dmtucker · 3. Juli 2023

This appears to be due to a bug in systemd: https://github.com/systemd/systemd/pull/24898

Zitat

At least one consumer router in production today, the Google Nest Wifi, often sends RAs that omit its global IPv6 prefix. When current versions of systemd-networkd receive those RAs, they immediately delete the interface's global IPv6 address, which breaks IPv6 connectivity

crashtest · 3. Juli 2023

As it seems, the real issue is with the Google Nest router. If it wasn't sending malformed RA's, there wouldn't be an issue.

Despite the fact that IPV6 has been in use for awhile, a good number of OMV users disable IPV6 for reasons like this. (I'm one of them.) I suspect that implementation issues, with IPV6, will be shaking out for years to come.

With IPV4, the scope of addresses available for private networks, is more than enough for home use.

dmtucker · 3. Juli 2023

This isn't the router's fault. systemd is not conforming to the RFCs:

Zitat

Currently, when we receive an RA from a router, we delete any addresses, routes, etc. that originated from that router's previous RAs unless they're also present as options in the new RA.

That behavior is a violation of RFC 4861.

I have no interest in disabling IPv6.

crashtest · 3. Juli 2023

Zitat von dmtucker

This isn't the router's fault. systemd is not conforming to the RFCs:

We could split hairs on this but it's worth noting that, to quote you ; "I've been using SLAAC for a long time, but I recently got a new router (Google Nest Wifi Pro)." As you stated it, in times prior, all was fine. Then, with the installation of a new router that sends malformed RA's, the issue began.

Have you detailed this issue on the Google Nest support -> forum?
This particular support forum services issues and answers questions regarding Openmediavault. RFC issues with Debian's systemd are, decidedly, upstream from here.

dmtucker · 3. Juli 2023

Zitat

Then, with the installation of a new router that sends malformed RA's, the issue began.

They aren't malformed, though... I believe they are part of Thread/Matter integration, which is a new technology that my old router did not support.

Zitat

This particular support forum services issues and answers questions regarding Openmediavault. RFC issues with Debian's systemd are, decidedly, upstream from here.

That's true; however, OMV 6 is still on oldstable, and this issue is likely fixed in the stable branch.

votdev · 3. Juli 2023

Zitat von dmtucker

They aren't malformed, though... I believe they are part of Thread/Matter integration, which is a new technology that my old router did not support.
That's true; however, OMV 6 is still on oldstable, and this issue is likely fixed in the stable branch.

You could open a bug report for Debian. If you point the maintainers to the systemd commit that fixes the issue they will happily backport it to oldstable.

BTW, oldstable does not mean outdated.

dmtucker · 3. Juli 2023

Actually, a newer version which contains the fix is already available in bullseye-backports, which OMV is already configured for.

Installing that version seems to have fixed the issue:

Code

sudo apt install -t bullseye-backports systemd

IPv6 mngtmpaddr flapping on interface configured for SLAAC

votdev 1. Juli 2023

Jetzt mitmachen!