Subject: RE: DHCPNAK for DHCPv6?

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 15 Jul 2001 22:36:37 -0500

Regarding the 2nd point (relays configured to forward) ... don't forget that this is normal for DHCPv6 anyway because it is multicasting - therefore, if you have two servers on the link, they'll both receive the messages.

Again, that's exactly why I wanted the servers to be able to send an indication that the prefix is correct for the client but the server can NOT verify the accuracy of the addresses OTHER than for the prefix. This would allow the client to know if it is on the correct link quickly because *ANY* server can answer this request. Of course, if the server has the client's bindings, it should indicate the full status to the client.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, July 13, 2001 2:05 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6? 

> The main reason is that DHCP won't be as critical in a V6 network
> for address distribution as it is in a V4 network. DHCP will be more
> useful in handing out options in a V6 network.

So you are arguing that because DHCP isn't critical, it doesn't have
to work?   I think this is a bad basis upon which to implement a
protocol specification - either we shouldn't do it at all, or we
should take out the parts that aren't needed, or we should do it
right.   The feature set that is in the specification is the one we
agreed to.   I don't think the WG would agree that we should take out
the address assignment part - I certainly don't.   So we should
specify it in a way that will work.

> Secondly, what happens if the relay is configured to forward the DHCP
> messages to more than one server? (a common config in V4 network ) In
> this case - the faster server can NAK the client causing it to go to the
> INIT state unnecessarily. 

This is true of V4 as well, and this doesn't happen if the DHCP
servers are configured properly.   If they are not configured
properly, that is hardly the protocol's fault.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Mon, 16 Jul 2001 22:09:58 -0400 (EDT)

yes we lost this behavior which we had in older versions of the spec by
catching the prefix per Mike Carney awhile ago.  We can do this by looking
at the relay address.  Simple fix.

thanks

/jim