Failover vs. DHCPv6 vs. Prefix Delegation

Shawn Routhier sar at isc.org
Fri Jan 13 18:06:25 UTC 2012


There is work underway in the IETF to produce a failover protocol for IPv6.

The work has been split into three pieces in order to try and make the results
(documents for the most part) easier to read and use.

The first part is a requirements document which is in the IETF draft stage.

The second part is a general design which is being worked on.

The third and last would be an actual protocol.  The DHC working group
hasn't agreed to take this last on yet, but the hope is that if the second phase
goes well it would be adopted.

**

In addition to the PD case there is also the case that you might want to
continue using the same IP addresses even after one of your server's dies.
The typical V6 argument of having multiple DHCP servers that server disjoint
sets of addresses would not work in that case.

Shawn

On Jan 13, 2012, at 9:26 AM, perl-list wrote:

> Greetings!
> 
> Is failover still not considered to be needed in conjunction with DHCPv6?  What about in the case of Prefix Delegation?
> 
> I was reading an old thread (seemed to be the only thread I could find regarding failover and DHCPv6) from 2009.  It sounded like the conventional wisdom was that failover was not needed as one could assign two huge ranges (one to each server) or use static assignments via host {} statements or both.  A sample config with a split of range6 and prefix6 might look something like this:
> 
> Server 1:
> 
> ddns-update-style none;
> ping-check false;
> allow leasequery;
> 
> option time-offset 0;
> option domain-name "example.com";
> option dhcp6.name-servers fe80:0:2e50::94, fe80:0:2e50::95;
> authoritative;
> 
> shared-network network1 {
> 	subnet6 fe80:0:2E50:E8::/64 {
> 		range6 fe80:0:2E50:E8:1::1 fe80:0:2E50:E8:1::ffff;
> 		#prefix6 low-address high-address / bits;
> 		#fe80:0:3e::/40
> 		prefix6  fe80:0:3e:: fe80:0:3eff:: /56;
> 		default-lease-time 600;
> 		max-lease-time 600;
> 		min-lease-time 600;
> 	}
> }
> 
> 
> Server 2:
> 
> ddns-update-style none;
> ping-check false;
> allow leasequery;
> 
> option time-offset 0;
> option domain-name "example.com";
> option dhcp6.name-servers fe80:0:2e50::94, fe80:0:2e50::95;
> authoritative;
> 
> shared-network network1 {
> 	subnet6 fe80:0:2E50:E8::/64 {
> 		range6 fe80:0:2E50:E8:2::1 fe80:0:2E50:E8:2::ffff;
> 		#prefix6 low-address high-address / bits;
>                 #fe80:0:4e::/40
>                 prefix6  fe80:0:4e:: fe80:0:4eff:: /56;
> 		default-lease-time 600;
>                 max-lease-time 600;
>                 min-lease-time 600;
> 	}
> }
> * Please ignore any stupidity in my sample config above as relates to address representation.  The /bits is the part I find important as pertains to this post.
> 
> This seems to work fine for merely assigning addresses to a PC or Router on the local net.  Mostly because 
> 
> range6 fe80:0:2E50:E8:1::1 fe80:0:2E50:E8:1::ffff;  = 65536 IP Addresses
> range6 fe80:0:2E50:E8:2::1 fe80:0:2E50:E8:2::ffff;  = 65536 IP Addresses
> 
> If one is to do prefix delegation, it would seem wise to match the number of prefixes to the number IPs that one might hand out (in this case 65536*2).  To do 65536 prefix for delegation, we would need 2^16 prefix.  If we hand out the originally recommended /56  then we need to assign one /40 to the interface.  This is probably reasonable. However, if we want to split up the prefix available across the servers we suddenly need to have two /40s per interface.  This may be harder to come up with at some/most ISPs.  For this reason alone, I suggest that failover should be implemented in some way such that a single /40 for prefix delegation could be shared between the two servers.
> 
> Am I all wet here?  Does this seem to be a legitimate problem?
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20120113/4d42eeb0/attachment.html>


More information about the dhcp-users mailing list