Windows sometimes lets temporary IPv6 addresses expire without renewing

[fireballiso at yahoo.com (fireballiso)]

Hi! I'm experiencing an IPv6 issue with Windows that I wanted to ask if
others are seeing, and get an idea of how widespread it might be.

For background, 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, 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. The Valid Life 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.

Output of "netsh int ipv6 show addr", formatted to fit and for privacy:

Addr Type   DAD State     Valid Life     Pref. Life   Address
---------Â  Â ----------- Â  -----------Â Â Â  ----------   -------
Public      Preferred     23h58m22s      3h58m22s     2001:470:X:X:X:X:X:7a20
Temporary   Deprecated    23h58m22s         0s        2001:470:X:X:bc72:8f4:7d98:3445
Public      Preferred     23h58m22s      3h58m22s     fd00:X::X:X:X:7a20
Temporary   Deprecated    23h58m22s         0s        fd00:X::bc72:8f4:7d98:3445
Other       Preferred     infinite       infinite     fe80::X:X:X:7a20%13

In this state, the Public addresses usually work, but these addresses don't
change, so some privacy is lost. Occasionally, even the Public addresses
stop working, (though the Valid and Pref Life values still have time left), 
which requires me to disable/enable the interface to regain any IPv6
connectivity to the internet.

I've noticed some bug reports stating that the temporary address stops working
after a while, but none I've found show the Pref Life staying on 0.

Has anyone else seen this bug? Any idea whether there's a fix or
workaround, other than an interface disable/re-enable?

-- 

-Indy
fireballiso at yahoo.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181111/045fb517/attachment.html>