Re: Disabling temporary addresses by default?

[Michael Richardson <[e-mail]>]

Fernando Gont <[e-mail]> wrote:
    > In this respect, we have a few knobs to play with:

    > 1) Valid Lifetime and Temporary Lifetime timers

Agreed, and this is an important knob.

    > 2) Whether ongoing sessions should be allowed to continue using invalid
    > addresses

I was initially surprised that the old addresses were called invalid.
Non-temporary addresses do not go invalid at the end of the lifetime, as long
as the host receives another RA.

Clearly the host made them up, as long as it continues to defend them, it
seems like it is wrong to call them invalid.

I think that N=1 is the right value, but that hosts should be told how many
concurrent temporary addresses the network will tolerate.  We can, if you
like, define the counter to be X+1, so a value of "0" means the host can use
one temporary address, and you can't specify zero :-)

    > Option #2: Reduce the N ratio, but allow ongoing sessions to use invalid
    > addresses. This could be worse than legacy RFC4941 (if long lived sessions
    > last more than a week), since now temporary addresses would not have a
    > limited lifetime (the lifetime would only be limited wrt the ability to
    > employ them for new transport protocol instances)

That was, btw, always my historical understanding.  It turns to be wrong.

    > If I had to choose, I'd go for #1 or #3 above. If apps hint the network layer
    > about the addresses to use (e.g. stable addresses if they mean to use
    > long-lived connections), #1 is fine. OTOH, #3, the status quo, is more
    > concervative in this respect.

Maybe we suggest that OSes provide a knob to determine what kind of address
is provided to an application that expresses no preference, I could live with
this.


-- 
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-