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

[Lorenzo Colitti <[e-mail]>]

On Mon, Jan 13, 2014 at 4:27 PM, Matthew Petach <[e-mail]>wrote:

> I realize this setup isn't typical; but it's there, and I find it
> odd that the reaction from the community seems to be
> "people should stop trying to stretch the lifespan of
> IPv4 and just move to IPv6" at the same time saying
> "you should stop doing things the v4 way, and change
> your mindset and topology to match the v6 way".
>
> The more impediments and roadblocks there
> are to seamlessly converting from v4 to v6 there
> are, the less incentive there is to move away from
> v4, and the longer it is we'll continue to have v4-only
> sites on the internet...which will continue to ensure
> that the v6-only internet can never become reality.
>
> As long as we're OK with v6 being a cute side project,
> and not a fully functional replacement for v4, that's
> a fine mindset to have.  But if we're serious about
> wanting to move the Internet wholesale to v6, we
> need to ease up a bit on this whole "If you won't
> convert to the One True V6 Way, you should just
> stay on v4" mantra.  I get that what we're doing in
> the v4 world can't currently be done in the v6 world.
> What I don't understand is why there's so much
> resistance to making it possible to do it in the v6 world?
>

Because making IPv6 look like IPv4 in every way will inevitably mean that
we'll lose the advantages that IPv6 has over IPv4. I'm not talking about
"QoS" or "security", which were trumpeted as advantages of IPv6 ten years
ago. I'm talking about the real advantages, like network statelessness, the
freedom from on-link address scarcity, dynamic renumbering, etc.

At the end of the day, it's a trade-off. Do you make IPv6 look more like
IPv4, in the hope that it will get deployed more quickly? Or do we stick to
the design and accept some temporary migration pain for a better end
result? I'm for the latter, because this thing's going to be with us for
thirty years - and because making it IPv6 more like IPv4 will *not* get
IPv6 deployed faster, because that's a business decision, not a technical
decision.

Many have said, "Where's the harm? So let's define standards to put routing
in DHCP. There's no harm in making the semantics compatible with IPv4, as
long as we maintain the routing in RA compatibility as well". I think these
people are either underestimating the network effect or the realities of
operations, "modern corporate IT staffing" (as Owen puts it), and the code
and process bugs that invariably crop up when you try to do something a
little different. Using the IPv4-lookalike way will always be the path of
least resistance, and at the end, there will only be one way to do
communicate configuration parameters to general-purpose hosts. Everything
else is simply too operationally expensive.

In your specific case, I'd argue that - as Ole has said - what you want to
do should be 100% solved - and with better load-sharing properties than
your current IPv4 design - by simply having the hosts ECMP to the four
routers. If your hosts don't support that, then I would see that as an
excellent use of your "as a multibillion dollar company, we can afford to
pay for the features we need" cachet.

Regards,
Lorenzo