DHCPv6 failover protocol?

[David W. Hankins]

On Thu, Mar 05, 2009 at 08:55:39PM -0500, Frank Sweetser wrote:
> Something like hashing based off of the DUID or IAID.  It would have to be 
> prepared to deal with hash collisions, of course, but I would imagine that 
> the checks to see if an address is already in use should probably cover 
> that.

One technique someone told me was to test the hash algorithm for
uniqueness (or "uniqueness for the network(s) it will be on") when the
device was placed in the asset tracking system.

Otherwise, you'd either decide that the statistical probability of
a collision was so unlikely to just go with it and let collisions
happen, or you'd rely upon the client's ability to perform duplicate
address detection and Decline, making some temporary record to run
certain clients through the hash twice.  No permanent disk state
required, nor its negotiation.

Maybe you wouldn't use this on an airplane, or in surgical equipment,
but it would be dead simple.

> At that point, it should act the same as if the two servers had both been 
> configured with the same fixed address.  Plus, not only would that mean you 
> don't have to worry about server state synchronization issues, you could 
> easily have more than two servers.  Nice.

Yes!  Very good analogy.  If you write a script to produce your
dhcpd.conf fixed-addresses, you can maybe write a runtime script just
as well, and only carry the exceptions in config rather than a giant
map of everything.

> I'd be curious to see how clients deal with two different overlapping 
> leases from two different servers, both offering the same IP address.

ISC's doesn't do DAD.  Yet.  Unless you wrote it into dhclient-script.
We never did with DHCPv4 either, and actually are just starting to
notice we could have done it recently ('arping').

So far, I think all the other implementations do DAD.

> Ah, I see the catch now - the server is required to discard Renew messages 
> which have a mismatched server identifier, while Rebind messages can have 
> any server id in them.

Rebind messages can have NO server-id in them.

   Servers MUST discard any received Rebind messages that do not include
   a Client Identifier option or that do include a Server Identifier
   option.

You mean to say that "Request and Renew messages are queries for a
single server, whereas Rebind messages are queries for any server."

> I wonder if anybody's drawn up a state diagram for DHCPv6 yet...

Nope.  Reverse engineering it from the specificiation is quite an
excercise.

I think it is easiest to think of a DHCPv6 client as having a very
simple boolean state object:  "Am I configured or not?"  We would call
that INIT vs BOUND in DHCPv4, and it comes down to how little or
how much configuration the client needs before it considers itself
off-net (likely: valid addresses), and therefore needing to put a
config in place, or to strip an old config out.  That's the only
action this boolean value governs.

From here, you attach a "message state", just a type of message and
the timers that govern its retransmission (literally, retransmission
state), and you get "where am I and where am I going?"

Your IA is BOUND, you want to stay BOUND, and t1 has expired, so you
are "BOUND/Renewing."  If T2 expires and you're still doing that,
well now you're "BOUND/Rebinding."

You were BOUND, but your link state fluctuated, so now you're
"BOUND/Confirming."

So on.


But of course, I just used the same enum for DHCPv6 as we did for
DHCPv4.  The simplification of segregating lease state from message
state didn't ocurr to me until after I was done. :(

-- 
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/20090305/8325d4e1/attachment.bin>