I'm using the ISC dhcp server version 4.1 for DHCPv6 prefix delegation on a network. When the server allocates a prefix to a client, the server does not create a route for that prefix to the client that requested the prefix. Here is a feature request for pfsense that describes what I'm trying to accomplish. Short of customizing and rebuilding isc-dhcp (which is an option I'm considering), I haven't been able to determine a method for creating these routes automatically.

I also considered writing a script (perhaps a cron job) to parse the lease file and create routes. The file does not contain sufficient information to create the routes either; it lacks the link-local address or mac address that the prefix was assigned to. This is an excerpt from the lease file. The first 3 and last 3 bytes of the IA-PD appear to be the last three bytes from the requester's mac address encoded in octal.

ia-pd "\236\250\366'\000\001\000\001\031[D\275\010\000'\366\250\236" {
  cltt 1 2013/06/24 18:32:37;
  iaprefix 4001:1234:5678:dff0::/60 {
    binding state active;
    preferred-life 7200;
    max-life 604800;
    ends 1 2013/07/01 18:32:37;

Is there an accepted way to create routes from prefix delegation requests? Or, is there another way to obtain the link-local address for a lease?

Other references:

2 Answers 2


It turns out that the answer to "does the API provide sufficient information to work?" is, as of ISC DHCP 4.3.1, "no, it does not". However, I've just spent a chunk of time putting together a patch set to extend the server to provide (just) enough information to add and remove routes. My changes are available at https://github.com/mpalmer/isc-dhcp, in the client-address-data-expression branch. There's a script in contrib that demonstrates how it can be used.

  • I had another (unreliable) solution that kept me from looking at this for a while, but I finally got back around to it today. I rebased your work onto the 4.3.3 version of dhcpd and got everything to work. Thanks for your patches! Dec 29, 2015 at 17:53

You mention that you're using dhcpd for prefix delegation, so that's apparently running on a *ix box of some sort, which usually isn't acting as a router. The usual setup would be to have the client running OSPFv3 or another routing protocol. It would receive the prefix delegation, assign appropriate link prefixes to its attached interfaces, and then advertise those routes to the other routers in the network. If for some reason you are running routing on a Linux/BSD machine and don't want to or can't move it, then I recommend running Quagga1 to insert the appropriate routes into the server's routing table.

  • I'm attempting to replicate the environment that an ISP would create for delivering service to home users. In this case, the use of dynamic routing protocols are explicitly prohibited: tools.ietf.org/html/rfc6204#page-10 (see WPD-8) Jul 30, 2013 at 19:07
  • 1
    Have you looked at the feasibility of using an on commit hook? If that's not practical, depending on how detailed the rest of the DHCP server needs to be, it might be easier simply to write a simple DHCPv6 server in Ruby or Python. Jul 30, 2013 at 20:02
  • The on commit hook does sound promising. I'll investigate that further to see if the API provides sufficient information to work. Jul 30, 2013 at 21:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .