How are you doing DHCPv6 ?

Randy Carpenter rcarpen at
Sat Jan 21 02:22:23 UTC 2012

----- Original Message -----
> On Tue, Jan 17, 2012 at 4:04 PM, Randy Carpenter <
> rcarpen at > wrote:
> We have a requirement for it to be a redundant server that is
> centrally located. DHCPv6 will be relayed from each customer access
> segment.
> We have been looking at using ISC dhcpd, as that is what we use for
> v4. However, it currently does not support any redundancy.
> [snip]
> When you say you require redundant DHCPD, what do you mean by that?
> The DHCP protocol is mostly stateless, aside from offers made, which
> are stored persistently in a database.
> Therefore, you can cluster the DHCPD daemon, without modifications to
> software.

DHCP is certainly not stateless, which is why there is a concept of leases, which are stored in a file. You can't have 2 servers answering for the same subnet without some sort of coordination, or you would have a potential for duplicate addresses being assigned.

> There is no shortage of cluster management software that is up to the
> task of keeping a service active on an active node, and keeping the
> service inactive on a standby (or failed) node.
> Achieving redundancy against DHCPD failure is mostly a design and
> configuration question,
> not a matter of "finding a DHCPD implementation" that has redundancy.
> If by redundancy you mean active/active pair of servers, for load
> balancing rather than failover, that implies DHCP servers with
> non-overlapping pools to assign from, and is generally a much more
> complicated objective to achieve with DHCP whether v4 or v6.

I mean for failover, not load balancing.

The other issue we are encountering with IPv6 is that ISC DHCPD does not log very much at all for DHCPv6.

Also, we have yet to find something reliable to identify a particular client. It looks the only thing that is sent is the link local address, which is randomized on windows machines. The MAC address does not appear to ever be sent. This makes it impossible to apply any policies based on client.


More information about the NANOG mailing list