DHCPv6

First off, an apology! FireBrick and A&A have been pioneers in making IPv6 work in practice in the UK. The current FireBrick operating system has been designed with IPv6 from the start, and not as an afterthought. This means that at every stage the notion of an IP address comes with the notion of "which sort of IP address". We are proud of that. But we have been lax in one notable area - DHCPv6. Sorry.

The problem is that IPv6 has a mechanism, SLAAC, which assigns an IP address on Ethernet. It is very simple, and works. The router sends out some details (which can include DNS servers, etc, as well), and allows devices to pick an address. With 64 bits of local address, this is easy to do in a way that avoids any collisions. Indeed, devices often pick lots of addresses, cycling them quickly, to hide how many devices you have on a subnet, etc. (privacy addressing). It works well, and in the UK it was pretty much the only thing being used.

DHCPv6 is a "stateful" way to manage addresses, and like DHCP (for IPv4) it has a lot of options. Thankfully IPv4 DCHP has been around a long time, and the sane options to implement are clear. The FireBrick IPv4 DHCP server is actually pretty flexible and powerful and works well.

But DHPCv6 is newer, and has a lot of options. One of the big ones is "prefix delegation" - telling a device it has one or more blocks of IP addresses to use on its interfaces to give out to devices it has connected. This is just one of the complications for a DHCPv6 server on Ethernet - it has to consider not only allocating and tracking an IP address, but a block of IP addresses and routing. As a client we also have to consider if we want to ask for a block of IP addresses and what interfaces we can use to assign those IP addresses.

We do this already, but we only do it for the LNS/PPPoE (broadband) side of things. We work as a server when operating as an LNS, linking to RADIUS and routing. We work as a client when PPPoE, allocating a dynamic block of prefix delegated IPs to the LAN interface. So we have a lot of the tools already.

Until now we did have an option on our router announcements on IPv6 over Ethernet to allow a DHCPv6 server, and even an option for that to be the FireBrick itself. The idea was the FireBrick would issue an address the same as SLAAC. This was specifically to allow for devices that only worked using DHCPv6. But we really did not find any such devices. Devices (like the FireBrick itself) that only handle SLAAC are actually more common from what we can see.

But the time has come for DHCPv6. And there will be several alpha releases around this. We need to take careful steps to integrate the code which currently only works for LNS and PPPoE to be used for Ethernet. We need to decide on the config for this, and the options we offer. This will not be simple.

So, watch this space. It will take a while as we are working hard on the new 10G FB9000 router right now, but we are starting. We already have an alpha which does a consistent simple IPv6 address allocation over DHCPv6 on Ethernet (a hash based address to avoid giving out the MAC). We hope next to have DHCPv6 client over Ethernet and then DHCPv6 client prefix delegation. The server side will be a lot more work considering the config, and how much we link with IPv4 config, so bear with us.