[ipv6hackers] Windows 10 has random issues with temporary IPv6 addresses staying at Pref Life 0s

fireballiso fireballiso at yahoo.com
Thu Jan 10 00:20:50 CET 2019

On 1/9/2019 12:37 PM, Fernando Gont wrote:
> On 2/11/18 00:10, fireballiso wrote:
>> Hi! I've been using a /64 tunnel from Hurricane for a few years to test
>> IPv6 connectivity until my ISP offers native service.
>> Linux works well with IPv6. However, recently I've isolated a problem in
>> Windows 10 (version 1803, build 17134.345) where the Preferred Lifetime
>> of *temporary* IPv6 addresses don't seem to be renewed properly
>> sometimes. When the Valid Life reaches 0, it will start counting down
>> again from 24 hours, but the Pref Life will stay at 0s; in this
>> condition, the temporary addresses don't work on that interface until I
>> disable and then re-enable it.
> Just doublecheking:
> In your scenario, Valid Lifetime > Prefered Lifetime.
> Eventually:
> 1) Prefered becomes 0
> 2) Then eventually, Valid becomes 0.
> 3) Then Preferred stays at 0, but valid starts counting down from 24 hs?
Hi Fernando,

When things are working as they should, Valid Lifetime for the temporary
addresses stay close to 24 hours, and Preferred Lifetimes stay close to
4 hours; in other words, they stay in sync with the Public addresses.
Both times decrement at the same rate, and when the host receives a
Router Advertisement (RA) every 1-3 minutes, both times are reset to
their maximums.

Eventually, the Preferred Lifetimes for the temporary addresses don't
reset to the maximum after an RA, but continue to count down; the Valid
time is always reset after an RA.

> How did you let the Preferred/Valid lifetimes expire? Just have the
> local router stop sending RAs? Or did you craft an RA packet and sent it
> on the network? -- If so, how did your packet look like?
I didn't do anything to cause the Preferred Lifetime to eventually count
down to zero; it does it on its own. Sometimes it's within a few hours
of a reboot or interface reset, and other times it will not happen for
days. It would be an interesting, perhaps subtle attack, if I could
cause it to happen deliberately, since the temporary addresses will not
work after the Preferred Lifetime gets to zero, and it leak the Public
address(es). Maybe it's a good thing that I usually have trouble
weaponizing my weird bugs. :-)

>> output of "netsh int ipv6 show addr":
>> Addr Type      DAD State       Valid Life         Pref. Life     Address
>> ---------          -----------             ---------- -        ---------
>>         ------------------------
>> Public             Preferred        23h58m22s   3h58m22s
>> 2001:470:XXXX:XXXX:XXXX:53c0:9af2:7a20
>> Temporary      Deprecated   23h58m22s         0s        
>> 2001:470:XXXX:XXXX:bc72:8f4:7d98:3445
>> Public             Preferred        23h58m22s   3h58m22s
>> fd00:XXXX::XXXX:53c0:9af2:7a20
>> Temporary      Deprecated   23h58m22s         0s        
>> fd00:XXXX::bc72:8f4:7d98:3445
>> Other             Preferred          infinite           infinite     
>> fe80::XXXX:53c0:9af2:7a20%13
>> Sometimes this problem doesn't happen, and as expected, after Pref Life
>> reaches 0 it is reset to start counting down from 4 hours again.
> That's not what should happen:
> FOr temporary addresses, both timers should eventually expire. WHen
> "Preferred Lifetime" expires, the address in question should not be
> employed for new connections. Additionally, Windows should configure
> another temporary address. When "Valid Lifetime" expires, the address
> should be removed.
Sorry, I neglected to mention that, after the temporary Pref Life
reached 0, the interface would also get new temporary addresses in
addition to starting the countdown again.

>> Has anyone else seen this bug? Any idea whether there's a fix or
>> workaround, other than an interface disable/re-enable?
> Please let me know the above. I'd like to reproduce it and try to help.
> Thanks,

Thanks for looking into this!

As a workaround (and to investigate it), I wrote a simple script to
monitor the temporary addresses; when the timer gets close to zero, it
runs the command "netsh interface ipv6 set global
randomizeidentifiers=disabled", and then the same command with
"enabled", which I discovered gives the interface new temporary
addresses without the disruption of disabling/re-enabling the interface.
However, the expired temporary addresses don't go away, but are still
listed for the interface. If I run my system for perhaps a week without
rebooting, the interface can get lots of invalid temporary addresses.


fireballiso at yahoo.com

More information about the Ipv6hackers mailing list