Subject: Question about RFC2131 and address renewal

From: Juan-Antonio Ibanez <[email-masked]>
Date: Mon, 03 Apr 2000 14:18:19 +0200

Hi,

I would like to get some clarification about something not clearly sated
in RFC 2131 concerning the address renewal process.

Is it possible that in RENEWING or REBINDING state a client receives a
different IP address than its current one? I.e. the server decides not
to extend the current lease but instead allocates a different address to
the client.

In RFC 2131, page 32, there is a confusing sentence: "The server may
choose not to extend the lease (as a policy decision by the network
administrator), but should return a DHCPACK message regardless." If the
server does not extend the lease, shouldn't it rather send a DHCPNAK?

Thanks in advance,
Juan

---

From: Ted Lemon <[email-masked]>
Date: Mon, 03 Apr 2000 12:24:18 -0700

> server does not extend the lease, shouldn't it rather send a DHCPNAK?

It can send a DHCPACK that doesn't extend the lease.   A DHCPNAK would
force the client to give the address up immediately, which would be
wrong if there were still time left on the lease.

			       _MelloN_

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 5 Apr 2000 11:12:19 -0700

In the development of failover and load balancing protocols,
we have learned that there are many ways that a given service
can fail. In the most extreme case, this can include catastrophic
hardware failures that take down the entire machine. However,
services can also fail in more subtle ways. For example, a
process or thread may fail, leaving other processes or
threads intact. Or the process or thread may remain intact,
but respond incorrectly to queries. Or a hardware subsystem
may fail, leaving others intact. 

In the example of a DHCP server running the DHCP failover
protocol, the detection of DHCP failure is tied to the
inability to respond to DHCP failover protocol messages.
This means that the failover mechanism is not in itself
tied to the operation of the DHCP server. This introduces
a number of potential problems, including:

a. The possibility that the thread or process handling
   DHCP failover will fail, but not the actual DHCP
   server process or thread. I believe that the DHCP
   failover protocol is immune to problems resulting from
   this. 

b. The possibility that the DHCP server process or thread
   will die but not that the DHCP failover thread or
   process. In this case, failure will not be detected.

c. The possibility that the DHCP server will have a failure
   that may cause it to send out invalid DHCP packets,
   while the DHCP failover process or thread remains
   intact. 

d. The possibility that a partial hardware failure may 
   cripple the DHCP server, while still allowing it to
   respond to DHCP failover messages. For example, a
   multi-homed DHCP server could lose a NIC, disabling
   DHCP service for one or more subnets, without being
   detected by DHCP failover. 

The cases described above, plus others that may be imagined,
lead me to believe that the DHCP failover mechanism alone
cannot provide a reliable mechanism for the true determination
of DHCP server health. 

To provide such a determination it is necessary to use a variety
of health monitoring mechanisms, including examination of data
from the DHCP server MIB, external monitoring involving submission
of "test" DHCPDISCOVER packets, etc. 

Through these mechanisms, it may be determined that a DHCP server
is malfunctioning even though it (and the DHCP Failover protocol)
believe it is doing just fine. 

In this case, it would appear to me that a mechanism may be needed
in the DHCP failover protocol for a secondary to indicate to the
primary "you're malfunctioning" so that the secondary can take over,
even though the primary may think it's operating just fine.