Re: How IPv6 host gets DNS address

["Eric A. Hall" <ehall@ehsco.com>]

Alain Durand wrote:

> On Nov 5, 2003, at 5:31 PM, Bob Hinden wrote:

>> I think the question might be better stated as why does DHCPv6 have
>> to be the only solution to this problem.  It's clear that DHCPv6 is a
>> solution.  The debate seems to be can there be other solutions as
>> well (e.g., a Router Advertisement solution).  From what I see, there
>> are a significant number of people who would like to see other
>> solutions in addition to DHCPv6.
> 
> From a network administrator point of view, having two solutions to do 
> the same thing is not a good think.

That is true for specific networks, but what that black-and-white
statement overlooks is that each network has its own requirements and
metrics. In other words, having two solutions will be necessary to two
different networks, regardless of the solution that either of those
networks choose to deploy. Restricting the technology to a particular
target environment would just mean that the other environments are shafted
by default.

The right "default" is one that has zero operational cost, one that is
self-configurable, and operates within the capabilities and confines of
the service in question. Automated configuration services should never
require extra-management, and should never break the service in the
absence of that extra-management [this is why my proposal is to simply put
the DNS auto-discovery capability into DNS itself, and that all autoconf
stuff should work within its own service/layer wherever possible]. Beyond
the baseline default, people who are willing to invest in additional
management in order to achieve some additional reward should certainly
have those options available to them (this is true whether people think
the best approach for them is DHCP, or DNS-SRV, or ACAP, or whatever).

> From an implementor point of view,
> having two solutions to do the same thing is not a good think.

I certainly understand this argument, okay. However, I think it's
extremely dangerous to put this kind of cost-benefit ahead of end-user
cost-benefit. In management terms (which is what you're talking about,
whether you like it or not), this is known as favoring internal (staff)
criteria over external (customer) criteria. It's almost always a bad idea
to favor staff over customers, since your competitors can always favor
customers and get an immediate advantage. While standards-bodies are
mostly monopolistic and don't usually have to worry about formal
competition within their space, there are plenty of examples of informal
competition that can keep people from adopting the specification. Staying
with the old stuff (avoiding v6, in this case) is the usual way in which
informal competition is demonstrably favored here. Using non-standard
technologies is another common exhibition.

So while I agree that it can be difficult for vendors to manage multiple
technologies, we also need to recognize the potential in choosing to
pursue a single technology, especially one that has the potential to cause
significant damage in the default case.

> Also, I haven't seen so far a clear, concise problem statement 
> explaining what the _current_ (DHCPv6-lite) solution does not address.

My issues with using DHCP as the default is that it has a high management
burden, and things break when the necessary management is not recognized
and performed. In the default case, it would be all cost and little
reward. DHCP certainly has a measurable benefit that exceeds the (equally)
measurable cost of having to manage service-configuration data, and if I'm
willing to recognize that there is a relatively trivial amount of cost in
managing the configuration data, then I can justify the time and effort
and software costs necessary to achieve a payoff. OTOH, if I don't make
that recognition and investement, the breakage and headaches which
accompany poor management just ramp up cost, with little to no measurable
benefit. I spend all my time fixing stuff that got broke by some
peripheral service that adds no value to the network in question. DHCP's
value comes from its voluntary and willful deployment, while its mandatory
(default) usage would just be an unnecessary expense in the common case if
a lack-of-management breaks things by default.

[For the record, again, I use DHCP wherever possible and will continue to
do so, and my argument here is that my situation is unique rather than the
norm, not that DHCP* is incapable of providing extra value.]

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.