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

[Fernando Gont <[e-mail]>]

On 1/11/19 05:50, Ted Lemon wrote:
> On Oct 31, 2019, at 10:27 PM, Fernando Gont <[e-mail]
> <mailto:[e-mail]>> wrote:
>>>>
>>>> Did happy eyeballs encourage broken IPv6 connectivity, or did it
>>>> actually help IPv6 deployment?
>>>
>>> Don’t get me wrong—I’m not saying we shouldn’t do things to improve the
>>> situation.   I am saying that we should be strategic about it.
>>
>> For the home network case, the situation right now is that there are
>> deployments that break, and ISPs meaning to deploy IPv6 that can't do
>> stable prefixes. Certainly, that's a very bad strategy on our side.
>>
>> That said, and as noted, the home network case is just *one* scenario
>> where this problem may be faced. And a subset of the mitigations for
>> this scenarios are useful for the general case.
> 
> You mention later that if it takes more than ten seconds for the
> connection to resume, the user will be on the phone to the ISP.  It
> sounds, then, like they already have an incentive to configure their
> networks so that this doesn’t happen. 

In the presence of Happy Eyeballs, the problem will be masqueraded.


> So why aren’t they doing that?   What’s the obstacle?

Are you referring to the CPE case, or to the rest?


[....]
> 
>>>> That's not correct. Neither the Valid Lifetime nor the Preferred
>>>> Lifetime affect address selection.
>>>
>>> Okay, there’s something to fix.  Why would these not affect source
>>> address selection?
>>
>> For many reasons: one of them: two different routers might be using
>> different values for these timers, in an un-coordinated manner. And
>> there's not reason for which the smaller or larger lifetimes should
>> imply an address is preferred.
>>
>> OTOH, you might thing about preferring "the last advertised prefix". BUt
>> that would mean that src address would flap, which is bad for
>> trouble-shooting.
> 
> On what /actual/ network would this scenario occur, though, in a way
> that would actually cause the problem you anticipate?  I know you can
> set this up in the lab.   But in practice, I never have two competing
> routers advertising different and incompatible lifetimes for the same
> prefix on my home network.  So if you want to break things in other ways
> in order to be able to adapt to this situation, it should be likely.
>  When and where is it likely?

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.



> 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?




>>>>> If you Really Really want to be able to have the routers send out RAs
>>>>> that deprecate the default route, and, as Mark is saying here, to
>>>>> upgrade millions or perhaps billions of hosts, why not ask for
>>>>> something that’s a real improvement?
>>>>
>>>> Every piece helps.
>>>
>>> Right, but if the effort involved in two different options differs by
>>> epsilon, you should always choose the option that produces the better
>>> outcome, shouldn’t you?
>>
>> Is there any of the proposed fixes that we shouldn't be doing, already,
>> anyway?
> 
>    o  CPE routers SHOULD NOT automatically send DHCPv6-PD RELEASE
>       messages upon reboot events.
> 
> 
> We should definitely be doing this, but it might be worth pointing out
> that a very simple fix for this problem would be to have the server
> acknowledge the release but ignore it.

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



>  The server is allowed to give
> out the same prefix again even when it’s received a release, so the
> release is not a “change my prefix” signal, and perhaps we should
> explicitly advise that it not be treated that way.   This would be an
> easy tweak in a DHCP server, much easier than updating a billion CPEs.
> 
>    o  A CPE router sending RAs that advertise dynamically-learned
>       prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on
>       stable storage, the list of prefixes being advertised on each
>       network segment.
> 
> 
> Okay.   However, if an ISP makes the change I suggest above, this is no
> longer necessary, although I think it’s still good advice.
> 
> Your other proposed changes seem fine to me; my main focus here is
> really on whether there are other things we could be doing that would
> improve things even more.

I'm all for that.



>>>> What's the practical difference between that, an a network that supports
>>>> RA-Guard?
>>>
>>> On a network that supports RA guard, there probably is no difference,
>>> but RA guard on some networks, as we’ve discussed in the past, will
>>> actually make the network not work.   RA guard requires an active
>>> administrator.   So the CPE case we’re talking about isn’t relevant.
>>
>> The point is: in a network where you do not employ RA-Guard, you are
>> already trusting the router. Actually, it's worse: you trust all local
>> systems.
> 
> That’s why I’m suggesting that there might be a way to allow us to trust
> less and verify more, rather than having an entity on the wire that has
> no basis for knowing which devices are trustworthy and which are not,
> making that decision for us (NKB).

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).


> 
>>>>> When another RA arrives, see if it was signed with the same key.   If
>>>>> so, it came from the same router, and can be trusted to update
>>>>> whatever information that router sent, including flash-deprecating a
>>>>> prefix.   If not, ignore it.
>>>>
>>>> In the non-SEND trust model, you do trust the local router. Why did you
>>>> trust the local router to configure your network, but not for
>>>> deprecating the prefix?
>>>
>>> In the non-SEND trust model, you trust the local network.   You
>>> /hope/ that the RA you get “from the router” is actually from the router.
>>
>> Exactly: that's the point: you already trust the local network. What's
>> the rationale for trusting one of the RAs, but not the others?
> 
> 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?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492