Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

[Ted Lemon <[e-mail]>]

On Nov 1, 2019, at 5:45 AM, Fernando Gont <[e-mail]> wrote:
>> So why aren’t they doing that?   What’s the obstacle?
> 
> Are you referring to the CPE case, or to the rest?

I’m specifically referring to the ISP case, although I think referring to it as “the CPE case” is limiting your options! :)

> If you assume all routers employ the same values for the valid/preferred
> lifetimes, then what you propose is the equivalent to "prefer the last
> advertised prefix". In which case, in the presence of multiple RAs the
> src address of new sessions will deterministically flap. That doesn't
> seem nice from a troubleshooting perspective.

No, I’m saying that if you have two prefixes, one with a preferred lifetime of zero, and another with a preferred lifetime that is not zero, you should choose the second one.   Can you explain in a little more detail when this would cause a “deterministic flap”?

>> As for previous comments about source address selection, I think that if
>> you have two prefixes that are otherwise equivalent (a tie), and one has
>> a preferred lifetime of zero, while the other has a preferred lifetime
>> of not-zero, it would be dysfunctional to choose the one with the
>> preferred lifetime of zero.  What on earth is the purpose of preferred
>> and valid lifetimes if SAS isn’t taking them into account?
> 
> The timers are only supposed to be of use if they go off. Given the
> default values the use (one month, and one week), they never go off.
> 
> The valid lifetime would trigger garbage collection for stale prefixes.
> The preferred lifetime would keep a fresh and working address as the
> preferred address for new flows. -- if only they went of in a timelier
> manner.
> 
> So, I'd rather ask the question: what on earth is the purpose of setting
> a timer that will never go off in a meaningful situation and period of time?

Possibly we are talking past each other.   A prefix with a preferred lifetime of zero always has a preferred lifetime of zero.   There’s no timer to go off.   How the preferred lifetime got to be zero is of course an important question, and there I think that what you are getting at is important: a 30 day expiry time is way too long.

What if the user does want to release the prefix, e.g. for privacy reasons?

> Not that I oppose to that. But I just note that there's no reason for ot
> trusting a router that advertises PIO,VL=0, because your trust model is
> that you do trust the router (if not your whole local network).
> 
>> If I get an RA that’s not signed by the same key as a route in my
>> routing table that’s working, I don’t let it override what is currently
>> in my routing table and working.
> 
> But that's not the current deployed reality. IN current deployments, RAs
> are not signed. So why wuld you be skeptical to PIO, VL=0?

Right, we have a problem there.   SEND didn’t solve it.   I don’t think RA Guard solves it for the home case.   So, there is work to do… :)