Subject: [v6ops] Temporary IPv6 addresses expiring and not renewed - Windows 10

From: fireballiso <[email-masked]>
Date: Tue, 13 Nov 2018 20:55:48 -0500

I've seen strange behavior on Windows 10 (version 1803, build 17134.345)
for a while now: after the preferred lifetime of IPv6 temporary
addresses count down to zero, the network interface starts using the
non-temporary address for communications. The valid lifetime of both the
temporary and non-temporary addresses are  still large, but the
preferred lifetime of the temporary addresses is not reset, and no new
temporary addresses are generated.

Showing output of "netsh int ipv6 show addr":

Addr Type  DAD State   Valid Life Pref. Life Address
---------  ----------- ---------- ---------- ------------------------
Public     Preferred    23h58m44s   3h58m44s 2001:470:X:X:X:X:X:7a20

Temporary  Deprecated   23h58m44s         0s
2001:470:X:X:fdca:b4d8:c23a:3371

Public     Preferred    23h58m44s   3h58m44s fd00:X:X:X:X:X:X:7a20

Temporary  Deprecated   23h58m44s         0s fd00:X:X:X:fdca:b4d8:c23a:3371

Other      Preferred     infinite   infinite fe80:X:X:X:X:X:X:7a20%13

I found a similar issue in the archives of this list, and someone from
Microsoft replied back on Thu, 14 September 2017 05:57 UTC to say that
they were working on a fix for it. I don't know if the fix was
implemented, but another similar issue was reported as fixed "sometime
between build 16299 and 17127"; however, I'm hoping there are still
people at Microsoft on this list, since this problem is currently
happening in the above version several times a day. The only way to get
the temporary addresses working again is to disable and enable the
interface. (Disabling the privacy addresses with "netsh interface ipv6
set privacy state=disabled", then enabling them again, does nothing.)

Unfortunately, this is impeding IPv6 use on Windows, due to the privacy
issue. Any ideas what might cause this, and whether there is a
workaround or updated fix in the works?

-- 

-Indy
[email-masked]

---

From: Mark Smith <[email-masked]>
Date: Wed, 14 Nov 2018 15:39:55 +1100

On Wed., 14 Nov. 2018, 12:57 fireballiso <fireballiso=
[email-masked] wrote:

> for a while now: after the preferred lifetime of IPv6 temporary addresses
> count down to zero, the network interface starts using the non-temporary
> address for communications. The valid lifetime of both the temporary and
> non-temporary addresses are  still large, but the preferred lifetime of the
> temporary addresses is not reset, and no new temporary addresses are
> generated.
>

It's not because RAs aren't being sent often enough to refresh the address
lifetimes?

> they were working on a fix for it. I don't know if the fix was implemented,
> but another similar issue was reported as fixed "sometime between build
> 16299 and 17127"; however, I'm hoping there are still people at Microsoft
> on this list, since this problem is currently happening in the above
> version several times a day. The only way to get the temporary addresses
> working again is to disable and enable the interface. (Disabling the
> privacy addresses with "netsh interface ipv6 set privacy state=disabled",
> then enabling them again, does nothing.)
>

That would solicit an RA, and that RA would cause address lifetimes to be
refreshed.

Regards,
Mark.

> issue. Any ideas what might cause this, and whether there is a workaround
> or updated fix in the works?
>
> --
>
> [email-masked]
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lencse Gábor <[email-masked]>
Date: Wed, 14 Nov 2018 09:24:43 +0100

And what prevents Windows 10 from soliciting an RA, when information is 
needed for generating a new temporary IPv6 address?

Gábor

2018.11.14. 5:39 keltezéssel, Mark Smith írta:
>
>
> On Wed., 14 Nov. 2018, 12:57 fireballiso 
> <fireballiso=[email-masked] 
> <mailto:[email-masked]> wrote:
>
>     I've seen strange behavior on Windows 10 (version 1803, build
>     17134.345) for a while now: after the preferred lifetime of IPv6
>     temporary addresses count down to zero, the network interface
>     starts using the non-temporary address for communications. The
>     valid lifetime of both the temporary and non-temporary addresses
>     are  still large, but the preferred lifetime of the temporary
>     addresses is not reset, and no new temporary addresses are generated.
>
>
> It's not because RAs aren't being sent often enough to refresh the 
> address lifetimes?
>
>     fd00:X:X:X:fdca:b4d8:c23a:3371
>
>     I found a similar issue in the archives of this list, and someone
>     from Microsoft replied back on Thu, 14 September 2017 05:57 UTC to
>     say that they were working on a fix for it. I don't know if the
>     fix was implemented, but another similar issue was reported as
>     fixed "sometime between build 16299 and 17127"; however, I'm
>     hoping there are still people at Microsoft on this list, since
>     this problem is currently happening in the above version several
>     times a day. The only way to get the temporary addresses working
>     again is to disable and enable the interface. (Disabling the
>     privacy addresses with "netsh interface ipv6 set privacy
>     state=disabled", then enabling them again, does nothing.)
>
>
> That would solicit an RA, and that RA would cause address lifetimes to 
> be refreshed.
>
> Regards,
> Mark.
>
>
>     Unfortunately, this is impeding IPv6 use on Windows, due to the
>     privacy issue. Any ideas what might cause this, and whether there
>     is a workaround or updated fix in the works?
>
>     -- 
>
>     -Indy
>     [email-masked]  <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Wed, 14 Nov 2018 19:36:43 +1100

> needed for generating a new temporary IPv6 address?
IPv6 not working that way ...?

RAs are sent periodically by the router automatically. They need to be sent
more often than the preferred and valid prefix lifetime values ...
otherwise addresses will expire.

Gábor
> v6ops mailing [email-masked]://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Nov 2018 12:01:36 -0800

On Nov 14, 2018, at 12:36 AM, Mark Smith <[email-masked]> wrote:
>> And what prevents Windows 10 from soliciting an RA, when information is needed for generating a new temporary IPv6 address?
> 
> RAs are sent periodically by the router automatically. They need to be sent more often than the preferred and valid prefix lifetime values ... otherwise addresses will expire.

True. But Gábor's point is valid; if the host wishes the router would send it an RA, it can ask for one and get one unicast. The down side of that is that if the router is sending them too infrequently, one could imagine each of the hosts soliciting them, which means that something that could be multicast is sent many times unicast.

In any event, it sounds like there are issues both in the router and the host in this case. The router needs to periodically send them, and do so frequently enough that hosts don't expire their addresses, and if the host has a specific use for temporary addresses (which are not required in the architecture; there is no *architectural* reason it can't use its permanent address), it should do what it needs to in order to maintain one.

>> On Wed., 14 Nov. 2018, 12:57 fireballiso <fireballiso=[email-masked] wrote:
>> I've seen strange behavior on Windows 10 (version 1803, build 17134.345) for a while now: after the preferred lifetime of IPv6 temporary addresses count down to zero, the network interface starts using the non-temporary address for communications. The valid lifetime of both the temporary and non-temporary addresses are  still large, but the preferred lifetime of the temporary addresses is not reset, and no new temporary addresses are generated.
>> 
>> It's not because RAs aren't being sent often enough to refresh the address lifetimes?
>> Temporary  Deprecated   23h58m44s         0s 2001:470:X:X:fdca:b4d8:c23a:3371
>> 
>> I found a similar issue in the archives of this list, and someone from Microsoft replied back on Thu, 14 September 2017 05:57 UTC to say that they were working on a fix for it. I don't know if the fix was implemented, but another similar issue was reported as fixed "sometime between build 16299 and 17127"; however, I'm hoping there are still people at Microsoft on this list, since this problem is currently happening in the above version several times a day. The only way to get the temporary addresses working again is to disable and enable the interface. (Disabling the privacy addresses with "netsh interface ipv6 set privacy state=disabled", then enabling them again, does nothing.)
>> 
>> 
>> That would solicit an RA, and that RA would cause address lifetimes to be refreshed.
>> 
>> Regards,
>> Mark.
>> 
>> 
>> 
>> Unfortunately, this is impeding IPv6 use on Windows, due to the privacy issue. Any ideas what might cause this, and whether there is a workaround or updated fix in the works?
>> 
>> --
>> 
>> -Indy
>> 
>> [email-masked]

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Jen Linkova <[email-masked]>
Date: Thu, 15 Nov 2018 08:29:51 +1100

> It's not because RAs aren't being sent often enough to refresh the address lifetimes?

I'm not sure it's the case.
Looking at https://tools.ietf.org/html/rfc4941#section-3.4 and
https://tools.ietf.org/html/rfc4941#section-3.3
I got an impression that the host SHOULD start generating new temp.
address 5 seconds before the old address expires.
The preferred lifetime for the new address is the lower of the
Preferred Lifetime of the public address (4 hrs based on the output
provided in the original email) or TEMP_PREFERRED_LIFETIME -
DESYNC_FACTOR. Based on the output TEMP_PREFERRED_LIFETIME seems to be
20hrs (as the address got deprecated 4 hrs before the stable one), and
the upper bound on DESYNC_FACTOR is 10 mins.

So theoretically the host should be generating a new address with
preferred lifetime of 4 hrs.

But I agree, it's a bit weird that the system has not received any RAs
for 20hrs...

-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Thu, 15 Nov 2018 08:32:48 +1100

> Addr Type  DAD State   Valid Life Pref. Life Address

This output indicates that your system has not received an RA with a
PIO with non-zero preferred life for 20hrs.
In theory the system still should be able to generate an new privacy
address. In real life it looks like very weird network setup.
How often does your router send unsolicited RAs?

---

From: fireballiso <[email-masked]>
Date: Wed, 14 Nov 2018 20:01:22 -0500

> How often does your router send unsolicited RAs?
RAs are sent every 60-120 seconds, which is much less than the preferred
and valid lifetimes. I verified the RAs are reaching hosts, and prefix
information options for the two prefixes are included, so I don't
believe it's an RA problem.

Sorry, I'm not following how you determined that the system hadn't
received an RA with the prefix information for 20 hours. The preferred
lifetime counter starts counting down from 4 hours, and is reset to 4
hours with every RA received; when it's working correctly, the preferred
lifetimes of both the temporary and non-temporary addresses are the same
values. However, something cause the preferred lifetime values for the
temporary addresses to stop getting reset to 4 hours.

Since the Linux hosts/servers don't have a problem, I'm still thinking
the issue is in Windows.

-- 

-Indy
[email-masked]

---

From: Jen Linkova <[email-masked]>
Date: Thu, 15 Nov 2018 12:31:30 +1100

On Thu, Nov 15, 2018 at 12:01 PM fireballiso <[email-masked]> wrote:
> hours with every RA received; when it's working correctly,

Yeah, you are right. Sorry, should not be sending any emails before
the first coffee of the day ;)
I misread the output.

>the preferred
> values.
>However, something cause the preferred lifetime values for the

It looks like two issues to me:
- RAs do not extend the lifetime of the temp. address
- the new temp.address is not getting created in advance (RFC4941 says MUST).

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Nov 2018 14:39:35 +1300

On 2018-11-15 14:01, fireballiso wrote:
...
> Since the Linux hosts/servers don't have a problem, I'm still thinking

If so, it's not generic. Most people don't have this problem. Really.
I see this sort of thing:

Addr Type  DAD State   Valid Life Pref. Life Address
---------  ----------- ---------- ---------- ------------------------
Public     Preferred     1h59m28s     59m28s 2406:xxxx:xxxx:xxxx:c105:5ed7:59e6:xxxx
Temporary  Preferred     1h59m28s     59m28s 2406:xxxx:xxxx:xxxx:e5ad:37bb:c4ff:xxxx
Other      Preferred     infinite   infinite fe80::c105:5ed7:59e6:xxxx%21

   Brian

---

From: fireballiso <[email-masked]>
Date: Wed, 14 Nov 2018 22:39:27 -0500

> - the new temp.address is not getting created in advance (RFC4941 says MUST).
Seems right. FYI - with the new Windows 10 update (now version 1803,
build 17134.407), the problem persists; the preferred lifetime of the 
temp and non-temp addresses are in sync and reset to 4 hours after each
RA, but after a while, the preferred lifetime of all temp addresses
stops resetting and just counts down. After getting to 0s, I expect it
will stop working, and the non-temp addresses will be used for global
traffic again.

Addr Type  DAD State   Valid Life Pref. Life Address
---------  ----------- ---------- ---------- ------------------------
Public     Preferred     23h59m1s    3h59m1s 2001:470:X:X:X:X:X:7a20
Temporary  Preferred     23h59m1s   1h43m38s
2001:470:X:X:e9c9:11ae:1b31:4d1b
Public     Preferred     23h59m1s    3h59m1s fd00:X:X:X:X:X:X:7a20
Temporary  Preferred     23h59m1s   1h43m38s fd00:X:X:X:e9c9:11ae:1b31:4d1b
Other      Preferred     infinite   infinite fe80:X:X:X:X:X:X:7a20%13

-- 

-Indy
[email-masked]