Subject: DHCPREQUEST Question

From: Kevin Benevides <[email-masked]>
Date: Thu, 20 May 1999 13:45:32 -0400 (EDT)

I have a question with regards to a DHCPREQUEST generated during
the RENEWING state. Does the server always return a DHCPACK
even though it isn't extending the lease? If so, how does the
client know the lease isn't being renewed? 

In RFC 2131, in section 4.3.2, DHCPREQUEST message generated when 
the client is in the RENEWING state, it states the following:

      A client MAY choose to renew or extend its lease prior 
      to T1.  The server may choose not to extend the lease 
      (as a policy decision by the network administrator), but 
      should return a DHCPACK message regardless.

The state transition diagram for DHCP clients (figure 5), 
contradicts that statement. It shows that the client could recieve 
either a DHCPACK or DHCPNAK from the server, in response to a 
DHCPREQUEST, when the client is in the RENEWING state. I also
looked at the obsoleted RFC 1541 and it also states that the client
can recieve either a DHCPACK or DHCPNAK from the server when
renewing or extending it's lease. 

Kevin Benevides
Motorola

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 20 May 1999 14:38:49 -0400 (EDT)

At 01:48 PM 5/20/99 -0400, Kevin Benevides wrote:
>DHCPREQUEST, when the client is in the RENEWING state.
	
	True, but I don't see that as a contradiction.

	If the server doesn't want to extend the lease, it should
	return the same expiration time it gave to the client 
	last time in a DHCPACK.  Of course, the server doesn't 
	actually return an expiration time, but the duration of 
	time remaining on the lease, and so it would return a 
	shorter "remaining duration" than it returned last time, 
	but the absolute time of expiration could be identical.

	Note that a client in the RENEWING state MUST have time
	to run on the lease.  Even if the lease isn't
	"renewed", there is still time to run on the existing
	lease, or the client wouldn't be in the RENEWING state.

	The use of the DHCPNAK isn't to say that the server
	doesn't want to extend the lease, but rather for the
	server to tell the client that the client should
	stop using the IP address.  That is why the state 
	transition diagram indicates that the client MUST
	move into the INIT state on recepit of a DHCPNAK.

	Despite having sent a DHCPNAK to a client, a server 
	cannot assume that the client has ceased to use the
	IP address until the client send a DHCPDISCOVER to
	the server (indicating that the client has entered
	the INIT state).

	Cheers -- Kim

> I also

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 May 1999 14:36:53 -0400 (EDT)

My understanding of "not extend the lease" is that it will send a
DHCPACK with a lease duration that's just the time left on the
original lease.   Whether or not the client is supposed to do anything
differently if the returned interval is similar to the time remaining
on its lease is another question.   The ISC server doesn't actually
implement this - there's no way to give out a lease but never renew
it.

As to the state diagram, I think a lot of client vendors have
implemented to this.  I am pretty sure that the Microsoft DHCP client,
just to pick a completely random example, will always do the right
thing if it receives a DHCPNAK while renewing.   Anyway, I've seen it
work for some Microsoft DHCP clients.   It definitely works for the
ISC DHCP client.   And the ISC DHCP server will shamelessly send
DHCPNAK packets to clients that are in the RENEWING state.   I've
never gotten a bug report indicating that this has caused a problem.

I'd be interested to know the history of the paragraph you're
quoting.   Note that it talks about the client renewing *before* T1.
Should the server's behaviour be different on a renew prior to T1 than
to a renew after T1?

			       _MelloN_