Correct Failover / DHCPOFFER functionality

[David W. Hankins]

On Thu, Jul 02, 2009 at 01:19:36PM +1000, Glenn Satchell wrote:
> You should see DHCPDISCOVER brosdcast to all dhcp servers. Each server
> should reply with DHCPOFFER. Client then chooses one of the offers and
> does DHCPREQUEST to the chosen server. That server then replies with
> DHCPACK.

In "SELECTING" state the DHCPREQUEST message is transmitted to
broadcast (because the client is not yet configured with an IP
address nor a default route), and the packet is also broadcast during
INIT-REBOOT although the client may or may not be configured (the idea
is to ensure the reception of a NAK if the client has moved networks)
depending on which restart-optimization was implemented (although
usually the client is not configured as mobility is the safer
assumption).

It's after passing through BOUND that the RENEWING state DHCPREQUEST
messages are unicast.  REBINDING state DHCPREQUEST messages are again
broadcast so that other servers may be reached.

In all of these, the only message where a client includes a server
identifier option, to indicate which server it is selecting, is when
it is in the SELECTING state.

RFC 2131 is pretty mealy-mouthed on the subject of the server
identifier option.  It reinforces that a server 'MUST be prepared to
to accept any of its network addresses as identifying that server in a
DHCP message', but never indicates a server is to drop messages if
there is a server-identifier option that does /not/ match any of its
network addresses.  So accepting all packets irrespective of server
identifier fulfills this MUST, and doesn't go against any language
normative or otherwise.

So, many DHCP servers ignore the server-identifier field supplied by
the client, including ISC's, and instead reply based upon whether or
not the server is able to provide for the client's request; which
depends greatly upon the current state of leases that may or may not
be actively assigned to the client in question.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090702/894bcbfc/attachment.bin>