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

[Nick Hilliard <[e-mail]>]

On 19/12/2013 20:19, Mark ZZZ Smith wrote:
> I agree with this. Removing RAs and replacing them with DHCPv6 from a
> network might appear to be reducing complexity, but it is only really
> shifting it and creating more. Host and router implementations become
> more complex because they'd be expected to support both; during a
> transition period both methods need to be enabled and supported; network
> design decisions become more complex because a choice will usually have
> to be made as to which method to support, perhaps involving a survey of
> host capabilities; and troubleshooting becomes more complex because
> there is a chance of disagreement when both RAs and DHCPv6 are run
> concurrently.

Yes, it shifts some complexity, reduces a pile more in the long term, but
doesn't create a significant quantity of new complexity because it's not
that difficult to create an arbitration mechanism to handle how things
should be handled on the host side.  The state diagram for this is not very
large, tbh.  Have you drawn it out?

> I'd also question the criteria of "one protocol" being a goal. If RAs
> are to be shifted into DHCPv6 to achieve this goal, why isn't ND and MLD
> also proposed to be moved into DHCPv6?

This is a straw man argument and a rather poor one.  ND is concerned with
l3 address to mac layer address mapping and is a separate problem domain.
I don't know why you think that MLD is similar enough in function to DHCP
that you're mentioning them in the same sentence as potential candidates
for functionality merging.

RAs and dhcpv6 are both concerned with host auto-configuration.  We have a
single protocol in ipv4 which provides a superset of the equivalent
functionality of dhcpv6 and enough of the functionality of RAs to reliably
provide network connectivity and many people consider this a good thing.
Also...

> If the problems are different
> enough, different protocols are created. If the problems are similar
> enough, they're solved with a single protocol.

... this is my point: DHCPv6 is exactly two options away from being
independent of RAs to the point that it would be entirely usable in many
situations.  This is because problem domains are substantially the same, as
indicated by the fact that dhcpv4 covers all one, the intersection between
the two and a chunk of what RAs add.

> I consider RAs to be solving the problem of link specific layer 3
> configuration, and DHCPv6 to be solving the problem of layer 4 and more
> often higher application oriented configuration.

And I consider having two protocols to handle the job of one to be poor
quality protocol design, regardless of the best intentions of the people
who designed it like this.

Now we have a deployment / operational mess on our hands which people have
been complaining about for years and will continue to complain about until
it's fixed.  Maybe you don't consider it to be a mess, but I do and a lot
of other people do - people who have complained loudly about it over the
years and whose positions were, well, ignored.  Whether you like it or not,
it is a problem which will not go away by pretending it doesn't exist.

> A very good reason
> (perhaps the primary?) to create two protocols is so that one can be
> replaced without impacting the other (which is why I think DNS in RAs
> and IPv6 addressing in DHCPv6 are mistakes). If an alternate application
> configuration protocol is developed, DHCPv6 can be replaced without
> disrupting layer 3 configuration.

This is actually a complete non-argument.

Nick