Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

[Nick Hilliard <[e-mail]>]

On 19/12/2013 13:40, Lorenzo Colitti wrote:
> But what you propose is not simple. In fact, far from it. What you propose
> requires a DHCPv6 server that's always up and perpetually maintains state,
> and it requires that you run VRRP between the routers because DHCPv6.

Probably I'm not alone in considering dhcp servers to be critical to a
functional DHCP based network.  But as I said, I need DHCPv6 anyway and
things will break if it's not available.

Re: FHRPs, they have very predictable and stable failover characteristics
and in the many years that I've been using them, they've performed
incredibly well.  As I said, if you want to use gateway deprecation on your
networks, I'm happy for you, but I don't want to use this feature because
its technical characteristics are not as consistent as FHRPs, nor as fast
for handling failover.

> If you were designing a system from the ground up I'd wager you'd never
> design it like that. So why do it like that, then?

Can we stick to technical discussion?

> Because "we already
> run DHCPv6 for other reasons, so let's just use it"? Isn't that a bit of
> a sunk cost fallacy?

It's a sunk cost reason, not a sunk cost fallacy, and it's only one reason
out of several I don't want RAs on my network.  Please let's stick to
technical discussion rather than advocacy.

> Oh, it is viable. We know it works - after all, we do it in IPv4. It works
> well, because in IPv4 we have VRRP, things don't change often, and we have
> NAT. But many people feel that this time around we can do better than that.

I have looked at RA/SLAAC and its technical characteristics do not suit my
use cases.  Can you accept this and that I actually understand the
differences between SLAAC, stateful configuration via dhcp and what each
brings to the table, and that I still do not want SLAAC anywhere because it
doesn't work for me?

I'm ok about the fact that it may work very nicely for you.

Nick