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.

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.