[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Tim Chown <tjc@ecs.soton.ac.uk>
Cc: dnsop@cafax.se
From: JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp>
Date: Fri, 07 Nov 2003 02:23:38 +0900
In-Reply-To: <20031106090223.GC2795@login.ecs.soton.ac.uk>
Sender: owner-dnsop@cafax.se
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
Subject: Re: How IPv6 host gets DNS address

>>>>> On Thu, 6 Nov 2003 09:02:23 +0000, 
>>>>> Tim Chown <tjc@ecs.soton.ac.uk> said:

>> 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. 

> 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.

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.
					jinmei@isl.rdc.toshiba.co.jp
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.

Home | Date list | Subject list