DHCPv6 failover protocol?

Frank Sweetser fs at WPI.EDU
Fri Mar 6 01:55:39 UTC 2009


David W. Hankins wrote:
> On Thu, Mar 05, 2009 at 05:12:24PM -0500, Frank Sweetser wrote:
>> While poring over RFC3315, I was curious how the validation section for 
>> Renew and Rebind messages interacts with failover.  The RFC states that for 
>> Renew messages:
> 
> I'm wondering if we're going to need actual "failover" with DHCPv6.
> 
> With DHCPv4, we needed a failover protocol so two servers could act
> nearly like one because of the IPv4 address shortage.
> 
> With DHCPv6, for static leases you just configure the servers
> consistently, but for dynamic leases you can just configure two (or
> more!) huge pools, and clients will migrate (they get new addresses
> /before/ their old ones expire, and are allowed to keep the old
> addresses until the valid lifetime expires).
> 
> So we might need a failover protocol with IPv6, but I'm not convinced
> yet.  I want to see how people build their systems.

Okay, so as things stand right now, dynamic clients would get a new IP, but 
because IPv6 has much better support for multiple IPs per interface, this 
won't be the wrenching change that an IP change is in IPv4.

> It's also quite possible we will have something very different; a
> stateless server algorithm so that (n+1) servers can answer
> consistently without needing to update each other.

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.

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.

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

>>    Servers MUST discard any received Renew message that meets any of the
>>    following conditions:
> 
> Note that DHCPv4 had the same admonishment, the only reason the ISC
> server never paid attention to the server-identifier is because it
> wasn't sure what server identifier(s) it might have used until after
> the client was being configured...it isn't expressly required for
> failover (and actually makes our failover implementation weirder).
> 
> Of course we don't have the same excuse with the DHCPv6 server-id.
> 
>> So if you have two servers, A and B, and server A goes down, how will 
>> server B react?  Is it permitted to start answering messages with the DUID 
>> of A, or does it have to wait for the clients to give up and send out a new 
>> Solicit message?
> 
> They Rebind long before they Solicit. :)
> 
> The server will reply with new addresses it can give the client.  The
> client's old addresses are still valid (unless they are on the wrong
> link, then the server includes them with zero lifetimes), but may not
> be "preferred".
> 
> So in theory the client gradually migrates sessions between the
> addresses.
> 
> 
> Note that if both servers had the same host statement, this is the same
> as failover, and they would both deliver the same address(es) still on
> Rebind.

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.

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

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
     GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC



More information about the dhcp-users mailing list