Comment # 17 on bug 986395 from Marius Tomaschewski

(In reply to Neil Brown from comment #12)
> Always requesting a public address is certainly possible but seems to go
> explicitly against the configuration choice to use temporary private
> addresses for outgoing connections.

But is the right way to use in nfs client case IMO.

While RFC3484 defined, that a public address is preferred over a temporary,
RFC 6724 changes the default is to prefer temporary address (-> #section-5
and changes summary in appendix-B), but it is completely fine and _correct_
when the application does not use the defaults due to it's requirements,
e.g.:

https://tools.ietf.org/html/rfc6724#section-5

   Implementations MUST provide a mechanism allowing an application to
   reverse the sense of this preference and prefer public addresses over
   temporary addresses (e.g., via appropriate API extensions such as
   [RFC5014]).  Use of the mechanism MUST only affect the selection
   rules for the invoking application.

Even the Privacy Extensions RFC 4941 considers this, e.g.
section-3.6:

   The use of temporary addresses may cause unexpected difficulties 
   with some applications. [...] In addition, some applications may 
   not behave robustly if temporary addresses are used and an address 
   expires before the application has terminated, or if it opens 
   multiple sessions, but expects them to all use the same addresses.

section-6:
   The determination as to whether to use public versus temporary
   addresses can in some cases only be made by an application.

(In reply to Neil Brown from comment #15)
> A couple of minutes later it says:
> 
>        valid_lft 155sec preferred_lft 0sec
> so it jumped to 0 (and became 'deprecated') rather quickly.
...
> OK, more weirdness..
> My temp address became
>   valid_lft 0sec preferred_lft 14100sec

preferred_lft 0 is deprecated and should not be used for new connections;
the kernel is even permitted to remove it _when_ there are no connections
using it (. If valid_lft reaches 0 the address is not valid any more and
prefered_lft > valid_lft is invalid lifetime.

When something (e.g. router RA) contains a valid_lft 0, it is request to
remove things (e.g. a prefix not valid any more). Sending prefered_lft 0
is kind of "scheduled removal".

Your "valid_lft 0sec preferred_lft 14100sec" could be even be related to
all this, but some cleanup code is not implemented properly.

> I think I want to say "temporary addresses are obviously buggy, they
> shouldn't be used.."

:-) There were many changes in this area in 4.2/4.4 kernel.