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

On Fri, 1 Nov 2019, 06:34 Ted Lemon, <mellon@fugue.com> wrote:

> On Oct 31, 2019, at 3:21 PM, Fernando Gont <fgont@si6networks.com> 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.
>

You've got no more than 10 seconds unless you want end users to actively
try to do something to recover, which can include calling their ISP's
helpdesk.

A short presentation on some user experience factors for network engineers.

"A bit of UX for NEs"
https://www.slideshare.net/markzzzsmith/ausnog-2019-lightning-talk-a-bit-of-ux-for-nes

>
> 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.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>