Subject: RE: How IPv6 host gets DNS address

From: <[email-masked]>
Date: Thu, 6 Nov 2003 08:21:29 -0000

> -----Original Message-----
> From: Bob Hinden [mailto:[email-masked]] 
> Sent: 06 November 2003 01:32

> >FWIW I agree with Ralph and Jinmei here. I have not seen any 
> sensible 
> >argument as to why DHCPv6 is not the solution here.
> 
> 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.

Hi Bob,

From my perspective DHCPv6 has to be the only solution because multiple
solutions equals more complexity. I don't see any benefit to the
operator community from multiple solutions to this problem. 

Mat

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Tim Chown <[email-masked]>
Date: Thu, 6 Nov 2003 09:02:23 +0000

> operator community from multiple solutions to this problem. 

It's possible the RA-based approach might be better suited to environments 
where there isn't an "operator" managing a DHCPv6 server, where basic 
connectivity and the requirement for a DNS resolver is all that is needed?
But I agree at present it is not clear that we can justify two methods until
specific cases where the RA approach is advntageous are identified, from
operational experience.
 
So I agree we should press ahead and get operational experience with DHCPv6
in real deployments.   If there are clear gaps, then we can work on the RA
(or an alternative) method.   Well-known site locals are now off the table.

Tim

---

From: Daniel Senie <[email-masked]>
Date: Thu, 06 Nov 2003 08:49:45 -0500

>connectivity and the requirement for a DNS resolver is all that is needed?

So either DHCPv6 is horribly more difficult for the unskilled end user to 
handle than DHCP in IPv4, or I'm missing something here. Today one can get 
a $50 box that does DHCP for IPv4 along with other functions. Such boxes 
are so simple to make function that millions of them have been sold.

Today we have small sites using DHCP by using appliance boxes that take 
care of the details, and we've got larger sites that manage DHCP services 
using real servers, proxies, and so forth.

So for which group is DHCPv6 perceived as too difficult?

Adding additional methods increases complexity, as others noted. I agree 
with the sentiment below that any need for additional complexity should be 
the result of studying operational experience.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 06 Nov 2003 23:04:53 +0900

Tim;

> (or an alternative) method.   Well-known site locals are now off the table.

Wrong. It's ND which is off the table.

> specific cases where the RA approach is advntageous are identified, from

It is clear.

							Masataka Ohta

---

From: Tim Chown <[email-masked]>
Date: Thu, 6 Nov 2003 14:30:27 +0000

> are so simple to make function that millions of them have been sold.

If only someone would add "simple IPv6 functionality" for these and still
charge $50 - that would be one IPv6 barrier removed :)
 
> So for which group is DHCPv6 perceived as too difficult?

I agree that at this stage we suck DHCPv6 and see.  But I have a feeling
some environments, where only DNS resolver info is needed for operation,
may be better suited to an RA-like method, perhaps very large subnets where
multicast RA is much more efficient, or ad-hoc networks or other networks
that are currently in a minority but likely to grow.
 
> the result of studying operational experience.

I don't see any issue with progressing DHCPv6 or DHCPv6 Lite.  But I wouldn't
like to see an alternative (complementary) solution ruled out at this stage
until we get that operational experience.

Tim

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 07 Nov 2003 02:23:38 +0900

>>>>> On Thu, 6 Nov 2003 09:02:23 +0000, 
>>>>> Tim Chown <[email-masked]> said:

> (or an alternative) method.

I basically agree with this.

As the bottom line, I don't think it a good idea to have two (or more)
approaches as equally applicable methods for DNS recursing server
discovery.  If we have both, we'll need to implement both since we may
have an environment where only one of them is available.  So, even if
we allow alternatives, I believe only a single approach must be the
primary and mandatory one.

As the primary approach, I support stateless DHCPv6.  I don't yet have
a particular objection to the RA-based approach per se, but

- the standardization status is much more matured for DHCPv6: the base
  specification is now an RFC, the DHCPv6 options for the DNS
  recursing server discovery are at the final stage of the
  standardization, the option types were officially allocated by IANA,
  and the stateless guide for DHCPv6 was already sent to the IESG.

- there are several implementations that are interoperable.  (e.g., if
  you configure your IPv6 network with BSD-based PC routers and BSD PC
  client hosts, you can use DHCPv6 for this purpose today.  I believe
  you can also Linux routers/hosts in this network)

- I don't see significant difference on operational cost between
  DHCPv6 and the RA-based method: server/router operators must
  configure the DNS recursing server addresses by hand anyway (it may
  be done automatically in some environments, but it should be the case
  for both).  Host users would not care about which approach runs as
  long as it can provide correct information automatically (and either
  approach can).

- (I admit this is quite a subjective opinion but) I don't see much
  advantage in the RA-based method to adopt it as the primary
  approach.  For example, one obvious advantage of the RA-based method
  is that it can multicast the information and can reduce the network
  traffic for this.  But I don't need the advantage today.  At least I
  don't think the advantage is so great that it can continue this
  almost-endless discussion and delay the real deployment.  I don't
  stop others pursuing the RA-based approach or DHCPv6-lite for the
  additional advantage for future extensions, but I strongly believe
  we should stop the discussion (on DHCPv6 vs RA vs others) now, adopt
  DHCPv6 as the "primary and mandatory" approach, and start running.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Doug Barton <[email-masked]>
Date: Fri, 07 Nov 2003 00:59:04 -0800

Daniel Senie wrote:

> with the sentiment below that any need for additional complexity should 
> be the result of studying operational experience.

I've made basically the same point in the past as well, but it bears 
repeating. As a client implementor, additional complexity should have a 
really good reason for existence. I haven't seen one articulated yet for 
RA dns discovery, and I've seen (and advanced) several good arguments 
against.

Also, in answer to the question of whether someone has published 
stateless dhcpv6 implementation help, it seems the answer is yes:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-01.txt

Doug