ISC Dhcp Failover behavior for INIT-REBOOT scenario

[ravi kumar]

I would like to know the behavior of Dhcp Failover implementation in
INIT-REBOOT scenario. Is the following highlighted part taken care of in
Failover implementation ?
Also, would like to know if anyone has come across any Client, that behaves
in below specified manner : Request is sent during INIT-REBOOT, though
Client doesnot have valid lease.

<Copy-Paste from Dhcp Failover draft
[*draft-ietf-dhc-failover-12.txt*<http://tools.ietf.org/html/draft-ietf-dhc-failover-12.txt>
]>

One troublesome issue is that of the DHCP client responsibility when
   sending in DHCPREQUEST/INIT-REBOOT requests.  While the original DHCP
   RFC was written to require a DHCP client to have time left to run on
   the lease for an IP address if the client is sending an INIT-REBOOT
   request, it was sufficiently unclear that some client vendors didn't
   realize this until recently.  Since the INIT-REBOOT request was sent
   with the IP address in the dhcp-requested-address option and not in
   the ciaddr (for perfectly good reasons), the similarity to the RENEW
   and REBINDING case was lost on many people.

   At present, the failover protocol does not assume that a client send-
   ing in an INIT-REBOOT request necessarily has a valid lease on the IP
   address appearing in the dhcp-requested-address option in the INIT-
   REBOOT request.

   The implications of this are as follows: Assume that there is a DHCP
   client that gets a lease from one server while that server is unable
   to communicate with its failover partner.  Then, assume that after
   that client reboots it is able only to communicate with the other
   failover server.  If the failover servers have not been able to com-
   municate with each other during this process, then the DHCP client
   will get a new IP address instead of being able to continue to use
   its existing IP address. This will affect no applications on the DHCP
   client, since it is rebooting.  However, it will use up an additional
   IP address in this marginal case.
regards
Ravi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100520/b9a1202b/attachment.html>