Comment # 16 on bug 986395 from Jiri Bohac

(In reply to Neil Brown from comment #15)
> Other things are weird though.
> 
> It seems fairly easy to trigger the 
> 
> IPv6: ipv6_create_tempaddr: regeneration time exceeded - disabled temporary
> address support
> 
> message, which seems like it should be nearly impossible on a network with
> half a dozen hosts.
> And "ip -6 addr" reports e.g.
> 
>     inet6 2406:3400:c:15:7036:9572:6256:d431/64 scope global temporary
> dynamic
>        valid_lft 277sec preferred_lft 14177sec

ha! thanks for finding this; it's caused by 
net.ipv6.conf.*.max_desync_factor being larger than
net.ipv6.conf.*temp_prefered_lft
It results in an uderflow, it's a bug, I'll create a patch to fix this.
For now, please set max_desync_factor to 0 when doing these experiments with a
low temp_prefered_lft.

> but now establishing an IPv6 connection doesn't create a new temp address,
> but just uses the permanent one.

The address is never created by making a connection. It should be created
asynchronously by a timer. But the whole privacy extensions got disabled at the
moment the "ipv6_create_tempaddr: regeneration time exceeded - disabled
temporary address support" warning 

> OK, more weirdness..
> My temp address became
>    valid_lft 0sec preferred_lft 14100sec

not sure, but this is hopefully still the same problem with the
max_desync_factor.