Subject: DHCPNAK for DHCPv6?

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2001 22:03:03 -0700

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.

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

			       _MelloN_

---

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

> changes networks it has to wait for its lease to expire before it can

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

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: Ted Lemon <[email-masked]>
Date: Mon, 16 Jul 2001 23:13:21 -0700

> The consensus is to get a minimum spec out.

The consensus in which I participated was to get a minimum
workable spec out.   That is all I am trying to make sure of.   It has
to work.   We can't afford do do release a spec that doesn't work,
because if this spec is worth anything at all, people are going to
implement it, and then we won't be able to fix our mistakes.   I am
not arguing for excessive caution, but if we identify a real problem,
we should definitely fix it, right?   :'}

			       _MelloN_

---

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

ack yes yes ...sorry if I came off any other way... just want to be sure
ralph and I are heading towards last call too...

/jim