Re: How IPv6 host gets DNS address

[JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp>]

>>>>> On Wed, 5 Nov 2003 08:19:28 -0800 (PST), 
>>>>> Ralph Droms <rdroms@cisco.com> said:

> Please see draft-ietf-dhc-.txt, which is
> in IETF last call.  It gives the subset of DHCPv6 that must be implemented
> for host configuration without address assignment.

> "another process on the server side" is an implementation detail.  Because
> the DHCPv6 function for host configuration maintains no dynamic per-client
> state, the code can, in fact, be implemented as code that is executed in
> the same way as router solicitation code.  I strongly believe, based on
> implementation experience, that the implementation complexity of DHCPv6
> for host configuration is *not* prohibitive.

> Another way to phrase the quesion about consensus is "do we have consensus
> about a specific function or functions that DHCPv6 does not meet for host
> configuration such as DNS?"  I think this problem is solved RFC 3315 and
> draft-ietf-dhc-dhcpv6-stateless-01.txt.  There are multiple independent
> implementations that have demonstrated interoperability at TAHI,
> Connectathon and the DHCPv6 interop tests run by NEC in Vienna.

I basically agree with Ralph here.

Regarding complexity: I often feel people tend to say a particular
technology is complicated when they do not like (or do not support)
the technology.  But if something is complicated is often more or less
subjective.  It is the fact that RFC3315 (DHCPv6) is a specification
of about 100 pages, and I agree that a thick specification can often
be "complicated".  However, I don't think it's fair to say the
specification is complicated (or too complicated to take it as a
method for the DNS recursing server discovery) just because of the
number of pages.  It may just be a result of trying to be clear.  I
also do not think this argument is fair, since the RA-based discovery
has not become an RFC, while DHCPv6 has.  How can we be so sure that
the (future) RFC of the RA-based method won't be a specification of
200+ pages?  (I admit I don't actually expect such a huge document for
this, but my point is that it's not fair to compare the complexity of
a published document to that of an unpublished one by their thickness)

Besides, if the DHCPv6 specification is that complicated, why have we
seen more than 5 implementations (I'm trying to be moderate here.  I'm
quite sure there are more than 5) that are interoperable?  Again, I
agree with Ralph on his point.

I tend to agree that the things would be much easier if the stateless
part of the DHCPv6 specification was clearly more separated from its
stateful part *from the beginning*.  However, I'm convinced that the
attempt of clarification by dhcpv6-stateless-01 is a reasonable
compromise.  I don't think the fact the current shape of the
specification is not ideal (IMO) can be a reason to take DHCPv6 as
"the" method for DNS recursing sever discovery.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.