To:
SHIRASAKI Yasuhiro <yasuhiro@nttv6.jp>
Cc:
dnsop@cafax.se, dhcwg@ietf.org
From:
Tim Chown <tjc@ecs.soton.ac.uk>
Date:
Thu, 13 Nov 2003 20:59:31 +0000
Content-Disposition:
inline
In-Reply-To:
<20031114.051205.48455194.yasuhiro@nttv6.jp>
Mail-Followup-To:
SHIRASAKI Yasuhiro <yasuhiro@nttv6.jp>, dnsop@cafax.se,dhcwg@ietf.org
Sender:
owner-dnsop@cafax.se
User-Agent:
Mutt/1.4i
Subject:
Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug?
> Both setting the trigger of re-request on renumbering of prefix in RA,
> and a multicast Reconfigure message might cause all nodes to rush on
> the single DHCPv6-lite server for information-request reply exchange.
> It could work with small number of clients though.
I guess you could add some random delays, but you should also scale your
DHCPv6 server provision to have multiple servers?
I guess we can say that:
(1) Automatic renumbering is broken if people hard-code data in clients
(2) If a secure environment for reconfigure is needed, a multicast message
adds some complexity
(3) The Reconfigure message is really designed for a fully stateful DHCPv6
environment, not a purely stateless one providing options info (?)
(4) Periodic polling of the DHCPv6 server by clients allows renumbering
but is not a full solution for more rapid (unplanned) renumbering.
(5) There isn't really a ethod now for a client to be informed of a
renumbering event of a stateless DHCPv6 option (DNS, NTP)
(6) We don't want to use RA method because that would also mean an NTP
extension for RA (?)
(7) If the network renumbers, statelessly configuring hosts should/could
use the new prefix seen on an RA as a hint to re-request DHCPv6
options if the O bit is set.
So is something overlooked, or do we not feel we need a solution to (5),
given we could use (7)? Not sure how explicit (7) is...
Tim
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.