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

[Ted Lemon <[e-mail]>]

On Oct 31, 2019, at 3:21 PM, Fernando Gont <[e-mail]> wrote:
> On 27/10/19 09:02, Ted Lemon wrote:
>> Indeed, this would also not actually solve the problem.   At present,
>> the ISPs are doing something that is out of spec and causes problems.
>> If we “fix” this by accommodating what they do, does that help, or
>> does it just encourage them to continue doing it?
> 
> 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.

>> What should be happening on the host with a prefix that’s deprecated
>> is that TCP connections should be timing out.   This doesn’t take
>> very long.  
> 
> ~9 minutes, IIRC.

Should be 90 seconds.


>> And if there is a new prefix being advertised on the
>> link, that address should have a valid lifetime newer than the old
>> prefix, meaning that the next TCP connection should come from that
>> new prefix, not the old one.
> 
> 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?

>> I think Fernando’s plan to shorten some timers makes sense, but
>> shortening the minimum really doesn’t—it just opens up an opportunity
>> for an easy DoS, since I can now just send out death packets to the
>> local network and break everything all at once.
> 
> The reality with ND attacks are (modulo sanity checks on the packets):
> you enforce FHS, or you don't.

What is “FHS”?

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

>> Second, fix RA so that it’s
>> non-repudiable by a device that doesn’t have the secret key.
>> 
>> SEND does this, sort of.  Nobody uses SEND because it tries to solve
>> a too-big problem and does it using obsolete technology.   But the
>> basic idea is good: include a public key in every RA that can be used
>> to validate that the RA was signed with the corresponding private
>> key.
> 
> 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.


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