Subject: RE: DHCPNAK for DHCPv6?

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 17 Jul 2001 08:27:41 -0500

Jim:

I agree that the prefix handling should avoid the need for the NACK. There is still an issue of non-address configurations and perhaps a general "DHCP Error" option (in a Reply) that can be used to communicate problems might be useful. But, it is also something that perhaps can be added later (though existing clients would of course ignore that option).

- Bernie

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Monday, July 16, 2001 10:57 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6?

> One thing I just noticed about the latest draft is that there is no
> equivalent of a DHCPNAK sent in response to a request to renew an
> address when the client has moved to a different network link.  This
> behaviour is extremely important - without it, whenever the client
> changes networks it has to wait for its lease to expire before it can
> get a new IP address.

It is my recollection we do not have consensus on this issue.  When a
client leaves the network it should release its addresses. As backup we
should add prefix check from relay for the client bindings on confirm.
Then a prefix no match can be sent back to the client. 

> Am I correct in thinking that this is missing, or is it I who am
> missing something?

Its not that it is missing it was not applied.  The consensus is to get a
minimum spec out.  We imply to use the release at the client for this now.
I agree thats not quite enough for the node that just gets shutdown and
placed elsewhere on a wired net (I shut my laptop off and plug it on
another network).  Our current release will work for any mobile nodes with
code to detect movement but we need to address the non mobile client
moving too.  Good catch.

I think the prefix discussion will work and appease others on the mail
list who don't want a specific dhcpv6nak.

Others ?????????????

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 17 Jul 2001 10:16:06 -0400 (EDT)

ack...

/jim

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Jul 2001 13:17:52 -0700

> I agree that the prefix handling should avoid the need for the
> NACK. There is still an issue of non-address configurations and
> perhaps a general "DHCP Error" option (in a Reply) that can be used
> to communicate problems might be useful. But, it is also something
> that perhaps can be added later (though existing clients would of
> course ignore that option).

I think this is fine (don't see the new for a new option, unless it's
a text error message), but I think it would be good to have some
verbiage that just says "if the client gets a Wrong Prefix message, it
SHOULD by default give up its existing IAs and go back to the DHCP
Solicit phase, but SHOULD be configurable not to, or something like
that."  I am not sure how this situation could come about, as long as
the client is listening to router advertisements, but it worries me,
and I'd like to see it covered.   I guess this is something that could
wait for some implementation experience after last call, though.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Tue, 17 Jul 2001 22:33:51 -0400 (EDT)

I thing this is a good idea ....

/jim