Subject: RE: DHCPNAK for DHCPv6?

From: "Thirumalesh Bhat" <[email-masked]>
Date: Fri, 13 Jul 2001 10:11:39 -0700

You point is correct as far as DHCP is concerned in a V4 network. In a
V6 network, I don't see that there is as strong a reason to have NAK
implementation. Also, we are not addressing every state the client can
be in -examples are client gets a media connect/disconnect event, client
going to standby or hibernation. 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. 

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. 

thx
-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, July 13, 2001 9:42 AM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6? 

> I think not having NAK is fine. It caused a lot of grief in V4 to get
> the NAK part right.=20

That had more to do with figuring out what state the client is in than
it did with anything else.   We don't have the problem of figuring out
the client state, so this is a non-issue.

More to the point, DHCPNAK *does* something.   We can't just leave it
out.

> In the absence of a NAK - the client can directly go to the INIT state
> with its DUID on changing networks.  It can get the same set of
> addresses or a different set of addresses depending on the DHCP Server
> it is now talking to.

That's not what the specification says right now.  According to the
spec as it stands, we would have to wait for the timeout.  When I
change networks, I want a new address immediately, not after some long
tiemout period has expired.   But moving straight to sending a Solicit
isn't right either.   When the client detects a "link change", it may
not actually have moved - it just suspects that it *may* have moved.
So I want to keep my old IA if I can.   So using Confirm is correct.
The problem isn't that.   The problem is that the spec doesn't say
what the server should do when I send a Confirm while I'm on the wrong
network, or what the client should do when it gets a Reply saying
"you're on the wrong network."

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Jul 2001 11:04:38 -0700

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

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