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

[Owen DeLong <[e-mail]>]

> On Nov 1, 2019, at 3:11 AM, Ted Lemon <[e-mail]> wrote:
> 
> On Nov 1, 2019, at 5:45 AM, Fernando Gont <[e-mail] <mailto:[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”?

What we’re talking about is the case where you have two routers advertising the same PIO with the same VL. Let’s assume you are using a VL=3600 in your PIOs on both routers and that the routers started up 1800 seconds apart.

At T=0, you get RA from router A with prefix 2001:db8:4000:5000::/64 PL=3600
You start a bunch of flows using that address.
At T=1800, you get RA from router B with prefix 2001:db8:b000:c000::/64 PL=3600.
Your record for 2001:db8:4000:5000::/64 has PL=1800 remaining.
Therefore, you now start (under your proposal) using 2001:db8:b000:c000::/64 as your source
prefix for all new flows.
At T=3600, you get RA from router A refreshing prefix 2001:db8:4000:5000::/64 PL=3600
which resets the PL timer for that prefix to 3600 while the PL timer for …:b000:c000::/64
has now counted down to 1800. Under your proposal, we flap back to 2001:db8:4000:5000::/64.

Lather, rinse, repeat this change in source address every 1800 seconds.

Obviously, real world scenarios will be more complicated and the randomness of RA refresh will come into play making it slightly less deterministic as to when these flaps occur.

> 
>>> 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… :)

Why can’t RA Guard solve it for the home case?

Owen