Client IPv6 temporary addresses not regenerating after some time

[OPNenthu]

I got an interesting new lead from ChatGPT.  It suggested that Windows (I presume maybe some others as well?) follows a strict interpretation of RFC 4941 which states:

3.4.  Expiration of Temporary Addresses

  When a temporary address becomes deprecated, a new one MUST be
  generated.  This is done by repeating the actions described in
  Section 3.3, starting at step 3).  Note that, except for the
  transient period when a temporary address is being regenerated, in
  normal operation at most one temporary address per prefix should be
  in a non-deprecated state at any given time on a given interface.
  Note that if a temporary address becomes deprecated as result of
  processing a Prefix Information Option with a zero Preferred
  Lifetime, then a new temporary address MUST NOT be generated.
  ...

According to GPT's interpretation, Windows will never again generate temporary addresses for any prefix that is deprecated in this way in the RA message.

Such a message is sent by RADVD due to the default "DeprecatePrefix on" option in radvd.conf, which is required to properly invalidate stale prefixes on e.g. router shutdown.

Code Select Expand

# Generated RADVD config for manual assignment on opt3
interface vlan0.30 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvLinkMTU 1500;
        AdvDefaultPreference medium;
        prefix 2601:<redacted>::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
        };
        prefix fdf8:<redacted>::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
        };
        RDNSS 2601:<redacted> {
        };
        DNSSL h1.home.arpa {
        };
};

While watching with Wireshark I observe that RAs with PreferedLifetime=0 can be sent on OPNsense config changes, or at least on Router Advertisement service reload.  This is not 100% though.

If ChatGPT is correct about the Windows behavior, then a possible theory for the issue may be due to config changes in OPNsense.  Does anyone know all of the conditions under which such an RA is sent?  The ones I am aware of:

- IPv6 prefix change on an interface
- Router shutdown
- Config change and/or RADVD service reload (not 100%)

It'll take some time to test it since I am presently working through some big changes in setup, but wanted to get this out in the meantime.  I haven't given up on this.

[meyergru]

If that was the case, then a problem could occur if the 0 lifetime RA was given and after that, the next advertised prefix does not change from the previous, which indeed would occur when RADVD was restarted for configuration changes.

The original intent of sending such an "invalidation" RA was to make clients aware of the fact that the old prefix is deprecated and should npt be used any more. This must be used when the RA changes, which is the case for dynamic prefixes.

So, iff this is really Windows' behavior, then there are two cases than could be problematic:

1. If there are restarts of RADVD that issue these RAs without actually anything changing on the WAN interface.
2. Probably, also prolonging leases of WAN prefixes, if they also issue these RAs when the prefix does not change.

You should observe what happens when these 0 lifetime RAs are issued: If the prefix changes, they are O.K. / expected and/or needed, if it does not, they are probably not O.K. to be issued.

BTW: We discussed these issues back in 2022: https://forum.opnsense.org/index.php?topic=26832.30

[meyergru]

One more tidbit: You can actually control if DeprecatedPrefix should be on or off by setting "AdvDeprecatedPrefix" in RADVD's advanced settings.

When I monitored with radvdump, I saw 0 lifetime RAs on neither restart of the radvd daemon (which seems only to do a reload, since the PID does not change) nor on parameter changes. I saw it when I really stopped the daemon.

I am pretty sure that when the WAN IPv6 does not actually change, a prolongation does not incur a 0 lifetime RA, either. I cannot say what happens when the IP changes, as it does not for me... but even when it actually does, it would be correct to send a 0 lifetime RA.

[OPNenthu]

What appears to be reproducible is either an OPNsense shutdown or reboot (the 0-lifetime RA comes twice: once at shutdown and once again at startup), or the RA daemon is stopped as you also saw.  I'm not sure what kinds of configuration changes might also trigger it because I'm not able to reproduce that on demand now.

I do tend to make a lot of changes and even reboots as I'm still learning and experimenting, so that could be it.  As a quick comparison I looked at a remote Windows PC that is running at my parents' house, where network changes are not happening and the client is undisturbed, and that one seems to be rotating the addresses:

Code Select Expand

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : h2.home.arpa
   Description . . . . . . . . . . . : Realtek PCIe GbE Family Controller
   Physical Address. . . . . . . . . : xx-xx-xx-xx-xx-xx
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2600:<redacted>:4213(Preferred)
   IPv6 Address. . . . . . . . . . . : fdf8:<redacted>:1280(Preferred)
   Temporary IPv6 Address. . . . . . : 2600:<redacted>:48cc(Deprecated)
   Temporary IPv6 Address. . . . . . : 2600:<redacted>:e3e2(Preferred)
   Temporary IPv6 Address. . . . . . : 2600:<redacted>:ee2(Deprecated)
   Temporary IPv6 Address. . . . . . : 2600:<redacted>:1760(Deprecated)
   Temporary IPv6 Address. . . . . . : 2600:<redacted>:624(Deprecated)
   Temporary IPv6 Address. . . . . . : fdf8:<redacted>:48cc(Deprecated)
   Temporary IPv6 Address. . . . . . : fdf8:<redacted>:e3e2(Preferred)
   Temporary IPv6 Address. . . . . . : fdf8:<redacted>:ee2(Deprecated)
   Temporary IPv6 Address. . . . . . : fdf8:<redacted>:1760(Deprecated)
   Temporary IPv6 Address. . . . . . : fdf8:<redacted>:624(Deprecated)
   Link-local IPv6 Address . . . . . : fe80::<redacted>(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.130.3(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, May 26, 2025 6:20:04 PM
   Lease Expires . . . . . . . . . . : Friday, May 30, 2025 10:20:29 PM
   Default Gateway . . . . . . . . . : fe80::<redacted>
                                       192.168.130.1
   DHCP Server . . . . . . . . . . . : 192.168.130.1
   DHCPv6 IAID . . . . . . . . . . . : <redacted>
   DHCPv6 Client DUID. . . . . . . . : <redacted>
   DNS Servers . . . . . . . . . . . : 192.168.130.1
                                       2600:<redacted>:e049
   NetBIOS over Tcpip. . . . . . . . : Enabled
   Connection-specific DNS Suffix Search List :
                                       h2.home.arpa

My own IP address has not changed in over a month now, so the leases from the ISP seem to be long lived.  In that case those RAs would be problematic for the privacy extensions.  If I disable AdvDeprecatedPrefix then I risk instability when the prefixes do actually change, at least until the old ones expire.

Interestingly, it seems Dnsmasq doesn't rely on those RA types (if GPT is to be believed) and instead relies on short lifetimes to manage invalidated addresses.  It'll be interesting to compare the daemons in practice.

Thanks for the thread also.  I can say with some confidence that I'm not having an issue with lease prolongation because my modem also gets rebooted by the ISP at least weekly for maintenance.  The public IPs remain stable across reboots.

--
EDIT:  I'm currently playing with Kea and going back-and-forth between ISC/Dnsmasq/Kea  (I'm also toying with BIND and Unbound, learning about zones and record type management) as I'm trying to decide where I want to stay longer-term.  To quote Neo in The Matrix: "Choice.  The problem is choice."   

Once that settles down a bit I'll then leave things undisturbed for some time and see if the temporary address changes stabilize.

[OPNenthu]

Minor update:

I reproduced the RA with PreferredLifetime=0 on a config change, but specific to the RA system.  I made a small adjustment to include the VLAN-specific internal domain in the DNS search list and then when I clicked 'Save' it sent the problematic RA first before finally sending the updated RA.

You cannot view this attachment.

Code Select Expand

Frame 630998: 198 bytes on wire (1584 bits), 198 bytes captured (1584 bits) on interface \Device\NPF_{42A788CA-BA2E-4C03-8301-C6DB59536A38}, id 0
Ethernet II, Src: Protectli_f:xx:xx (<redacted>), Dst: IPv6mcast_01 (33:33:00:00:00:01)
Internet Protocol Version 6, Src: fe80::<redacted>, Dst: ff02::1
Internet Control Message Protocol v6
    Type: Router Advertisement (134)
    Code: 0
    Checksum: 0x5c90 [correct]
    [Checksum Status: Good]
    Cur hop limit: 64
    Flags: 0x00, Prf (Default Router Preference): Medium
    Router lifetime (s): 0
    Reachable time (ms): 0
    Retrans timer (ms): 0
    ICMPv6 Option (Prefix information : 2601:<redacted>::/64)
        Type: Prefix information (3)
        Length: 4 (32 bytes)
        Prefix Length: 64
        Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A)
        Valid Lifetime: 7200 (2 hours)
        Preferred Lifetime: 0 (0 seconds)
        Reserved
        Prefix: 2601:45:4000:6db3::
    ICMPv6 Option (Prefix information : fdf8:<redacted>::/64)
        Type: Prefix information (3)
        Length: 4 (32 bytes)
        Prefix Length: 64
        Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A)
        Valid Lifetime: 7200 (2 hours)
        Preferred Lifetime: 0 (0 seconds)
        Reserved
        Prefix: fdf8:fb25:3a87:1030::
    ICMPv6 Option (Recursive DNS Server 2601:<redacted>)
        Type: Recursive DNS Server (25)
        Length: 3 (24 bytes)
        Reserved
        Lifetime: RDNSS address MUST no longer be used (0) (0 seconds)
        Recursive DNS Servers: 2601:<redacted>
    ICMPv6 Option (DNS Search List Option h1.home.arpa)
        Type: DNS Search List Option (31)
        Length: 3 (24 bytes)
        Reserved
        Lifetime: DNSSL domain name MUST no longer be used (0) (0 seconds)
        Domain Names: h1.home.arpa
        Padding
    ICMPv6 Option (MTU : 1500)
        Type: MTU (5)
        Length: 1 (8 bytes)
        Reserved
        MTU: 1500
    ICMPv6 Option (Source link-layer address : <redacted>)
        Type: Source link-layer address (1)
        Length: 1 (8 bytes)
        Link-layer address: Protectli_f:xx:xx (<redacted>)

(it invalidated not only the active prefixes but also the RDNSS and DNSSL options in this scenario.)

I can do two things:

1. Since my PC was recently rebooted before receiving this RA, I can now check it after 24 hours to confirm that the privacy address will not be generated.  The theory is it will not since the active prefix was invalidated but not actually changed.

2. (Longer term test) I can reset the network connection and set 'AdvDeprecatedPrefix=off', then I can:
- confirm that the PreferredLifetime=0 is no longer being sent
- observe for several days to confirm temporary address generation working correctly

[OPNenthu]

Just posting the 24-hour result since the RA with PreferredLifetime=0 was received.

The temporaries remained active for the duration of their valid lifetime and then became deprecated.  No new ones were generated.

Code Select Expand

Addr Type  DAD State   Valid Life Pref. Life Address
---------  ----------- ---------- ---------- ------------------------
Public     Preferred     23h58m3s    3h58m3s 2601:<redacted>:f69
Temporary  Deprecated    23h58m3s         0s 2601:<redacted>:a322
Public     Preferred     23h58m3s    3h58m3s fdf8:<redacted>:3a21
Temporary  Deprecated    23h58m3s         0s fdf8:<redacted>:a322
Other      Preferred     infinite   infinite fe80::<redacted>

The theory is holding up so far.  The next part of the test should confirm it.

[meyergru]

I reckon that using AdvDeprecatedPrefix=off with a relatively short normal prefix lifetime would be the better option for you, then.

That 0 RA lifetime is used just to shorten the span of still using an old, invalid prefix. If that breaks temporary address generation for you, the better live with a short IPv6 interruption on prefix changes. I am at a loss however, why this is so, because it looks more like a client problem.
Windows was never actually good at implementing network connectivity. It has changes much over the years and there are still quite some possibilities to influence it via registry settings - many of those reported on the internet are outdated now, though.

In that context, it would be interesting to check on other OSes, but I guess that this is handled differently.

[OPNenthu]

In that context, it would be interesting to check on other OSes

This was affecting my linux clients as well (one Raspberry Pi OS - wired, one Debian 12 - WiFi), so I will test the theory there also.  I think my discussion with ChatGPT was focused only on Windows due to the prompts, so it was giving client-specific advice, but this is probably a wider issue due to the RFC.

If I can successfully reproduce I may raise an issue with RADVD to at least get their thoughts on it, although they might also just recommend to disable it.

[OPNenthu]

I observed for several days without making significant changes in OPNsense and I can confirm that when the network is undisturbed there is no issue; the temporary IPs are generating once daily as expected in both Windows and Debian, at least for a time.  Inevitably something happens to break them, because...

...I also learned that what qualifies as a 'disturbance' has been expanded to include not only radvd service shutdown or restarts due to configuration changes or router reboots, but also WAN DHCP renew / rebind events as per https://github.com/opnsense/core/issues/6522.  There's a similarly themed upstream thread at https://github.com/radvd-project/radvd/issues/85. 

In my case the IPv6 prefix rarely changes, but my ISP likes to reboot my modem at least weekly.  It happened once while I was capturing and I noticed that when the modem came back online there was indeed a prefix deprecation RA in Wireshark.  So this a bug; actually a non-stater for anyone using privacy extensions** with radvd because, based on my understanding of the linked GitHub issues, the DeprecatePrefix=on setting is required by OPNsense for reliable prefix propagation.  It was explicitly coded to restart radvd and send this RA message on DHCP events since OPNsense 23.1.9.

It would seem then that disabling the setting is also not an option, for the sake of IPv6 functioning in OPNsense.

So this leaves me with two questions:

1) How is this handled by OPNsense when Dnsmasq is used for RAs instead of radvd?  Is there a similar RA type as the radvd one that deprecates the current prefix?  If not, then is the original issue in https://github.com/opnsense/core/issues/6522 again present under Dnsmasq?

2) What current viable option do OPNsense users have for IPv6 privacy extensions?



** unless the client network link is re-established often, which masks the issue, or prefixes change frequently.