Re: DHCPv6lite, RA and WKA

[Tim Chown <tjc@ecs.soton.ac.uk>]

On Wed, Nov 19, 2003 at 06:27:42AM -0500, Ralph Droms wrote:
> 
> This issue has never been found to be a problem DHCPv4.  The appropriate
> timers will be added DHCPv6 to provide the same function in
> stateless DHCPv6 (as you point out, those timers exist when DHCPv6 is used
> for address assignment).

Right, adding a life-time for the non-address options (DNS, NTP, search
path,...) would allow clients to send periodic information requests to
the stateless server at a frequency determined by the site admin (who may
know about impending renumbering events or the addition, movement or removal 
of a DNS or NTP server).

But here I'm drifting from the "how do you convey DNS info to the client"
to the "how do you tell the client this info has changed" discussion.
There is some overlap.

> "DHCP storm" has never been an issue for DHCPv4, where the problem is
> potentially more serious because DHCPv4 is usually used for address
> assignment.  What evidence do we have the "DHCP storm" will suddenly become
> a problem in DHCPv6?

Presumably that enterprise networks will tend to have more IP(v6)-enabled
devices...?
 
> I think we should reserve judgment on the additional operational complexity
> associated with stateless DHCPv6 until we actually have some operational
> experience.   Based on the existing implementations of stateless DHCPv6, I
> don't see where the additional operational complexity will come from.

It seems we should push ahead and try DHCPv6 Light until we see specific 
problems where (for example) piggybacking DNS info on RAs would be better.
It's for that reason that I started thinking out the renumbering issue (or
situations where non-address configuration settings like DNS or NTP server
change). 

> Summarizing from below, I agree that we can specify the use of the 'O' bit
> to control the use of stateless DHCPv6 just as the 'M' bit controls the use
> of DHCPv6 for address assignment.  I still disagree that the supposed
> shortcomings to stateless DHCPv6 given in the first paragraph are sufficient
> to warrant the use of well known addresses or the development of an
> extension to RAs.

If we do find a need for multiple solutions, we really need
a) a baseline solution for all cases as Mat suggested (is this possible?)
b) to know that each method will interoperate 

These are both complexities in the multiple solution approach that we should
have a convincing answer to.

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