Subject: [dhcwg] DHCP Failover

From: VithalPrasad Gaitonde <[email-masked]>
Date: Tue, 2 Feb 2010 14:20:35 +0530

Hi,

Are there any plans to take the DHCP failover draft (
http://tools.ietf.org/html/draft-ietf-dhc-failover-12) forward under the
working group charter.
If not, is there any other specification being pursued for addressing high
availability of DHCP server.
I did not see anything listed under the charter at ietf.org.

Thanks,
Prasad

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 9 Feb 2010 10:59:51 -0800

> http://tools.ietf.org/html/draft-ietf-dhc-failover-12) forward under the

One problem with an IETF standard failover mechanism is that many DHCP
servers implement client identification differently, and each believes
their interpretation is correct (certainly, they all comply with the
RFC 2131 normative language, but as they say the devil is in the
details).

So it is a problem to "identically configure" two DHCP servers that
are of different manufacture, and nearly impossible to get two such
servers to give similar results to the same client pool.  Upon
reflection, operators weren't really intending on pairing DHCP servers
of different manufacture, but rather were intending on having two of
one kind of server.

Basically for this and other reasons stalling the progress of the
draft, the last plan I heard for the draft was to advance it more
under a banner of "if you wanted to implement a failover protocol,
this is a set of good ideas you might use" rather than a true IETF
inter-operating protocol.

A peer-reviewed implementation guide is maybe a fair way to
characterize the intent.

That last push basically stalled under its own weight, the oncoming
recession making us all very (or much less) busy, and the various
"More Pressing Matters" (tm).  I don't know if the authors still seek
to publish as RFC, but I'm still interested.

In the meantime, if you have any questions or discussion about it, I
and I'm sure others would be more than happy to hear your comments. :)

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/