I have been involved in Dynamic Host Configuration Protocol (DHCP) software development for 17 years.
It all started in 2003 when I wrote my master’s thesis — an experimental DHCPv6 implementation for Linux. Back in the day, IPv6 was a novelty. The IETF RFC documents that defined it were a bit over four years old. Geeks experimented with it, but production deployments were almost non-existent. When I learned about IPv6, I was instantly on-board with the idea. I was thinking about the best way to help the cause and the thesis was a perfect fit.
A short history of Dibbler
The design goals were simple: the new DHCP software should be easy to use, not be restricted by licensing, and help popularize IPv6. That’s how the Dibbler project came to be.
One of the core assumptions was to support IPv6 only. The reason was obvious — speed up the transition to IPv6, while making sure there were no strings attached. And it really worked! The software doesn’t have any ability to do anything with IPv4. It was a bit naive and idealistic, but it was a student project, so there was nobody to do a reality check for me….
Somewhere around 2006, an email came that invited me to what became the first of a series of DHCPv6 ‘bake-off’ meetings. The idea was to bring in DHCPv6 developers from different companies to meet in one place, do interoperability tests, and discuss the issues discovered. I was flabbergasted and terrified at the same time.
Back then, I was a recent university graduate and some guy from the US invited me to fly to Amsterdam to test my software. The other engineers participating were coming from organizations such as Cisco, Microsoft, Sun, and ISC. Suddenly, the whole experiment became much more serious. I still remember the angst and doubts — how could an essentially overgrown student project possibly keep pace with giants like Cisco or Microsoft?
Surprisingly, the interoperability tests were a lot of fun and my code definitely wasn’t the worst, for two reasons. First, I really embraced the IPv6 concept, so, for example, doing DNS updates over IPv6 was not a problem. In fact, using IPv6 was the only option available. Also, since the goal was to make IPv6 more popular, I wasn’t picky about the features. If there was an RFC or a draft, I wanted to implement it fully. I didn’t have roadmaps or large customers that expected certain features and ignored others.
A good example that I still remember is support for relays. RFC 3315, which describes DHCPv6, copied the relay agent concept from DHCPv4 but defined it slightly differently. Each relay adds an extra encapsulation layer to each client packet being passed towards the server.
The RFC says it’s possible to have up to 32 relays in a chain. Nobody sane would ever do that, and in most networks the DHCP traffic passes through exactly one relay. People who had more practical experience knew that, so they often made the code simpler by explicitly handling only one relay.
Surprisingly, back then, not many implementations could handle the scenario of three relays in a daisy chain. The bake-off was a great event where I met many like-minded networking geeks, and after so many years, some of us still keep in touch.
For many years, Dibbler was very popular, for two specific reasons:
- It was portable. It ran everywhere, including on Linux, Windows, macOS, FreeBSD, NetBSD and OpenBSD.
- It was very easy to use. Most things worked out of the box, while others could be enabled with a single line change in the config file.
I kept developing it for almost 15 years and finally gave up around 2017.
Dibbler is still being used in many deployments; a particularly large one has it deployed on 14 million CPE devices. While you can easily find it on GitHub and in most Linux distros, I discourage people from using it, as it is no longer maintained.
Getting serious
Another effect of the Amsterdam meeting was me getting involved in the Internet Engineering Task Force (IETF).
Being a DHCP guy, it was natural for me to get into DHCP drafts. My first RFC was RFC 6334, which defined a DS-Lite option.
Dual-Stack Lite is a nice transition technology that lets you deploy IPv6 in an IPv4 network reasonably easily. The architecture consists of two elements: a CPE device, operating in an IPv4 access network, which must establish an IPv6 tunnel to a central CGN service; and a CPE function, with a Basic Bridging BroadBand (B4) element and Address Family Transition Router (AFTR) for CGN translation. However, one element was missing. To be able to deploy DS-Lite, there had to be an automated mechanism to inform the CPE device where it should establish its tunnel to. The answer obviously was DHCPv6.
Other standardization work followed after that. The topics covered various aspects of the DHCP protocol, but most of them revolve around making DHCPv6 better and IPv6 easier to deploy. A couple of examples are privacy considerations for DHCPv4 and DHCPv6 (RFC 7819, RFC 7824, and RFC 7844), and a guideline for creating new DHCP options (RFC 7227). Probably the most notable one is RFC 8415, an updated DHCPv6 specification that was refined and published in 2018.
While the bulk of the DHCPv6 protocol is now well-defined, implemented, and deployed, there are some extensions that are still being discussed in the IETF. More on that a bit later.
ISC DHCP
One of the fortunate effects of bake-offs and my IETF work was a job offer from the Internet Systems Consortium (ISC), which I accepted in 2011. Somewhat shockingly, I was told that people did still use IPv4 and we cannot ignore it. The last remnants of my idealistic bubble burst.
ISC DHCP took a completely different route than Dibbler. As one of the earliest DHCP implementations (started in 1995), it was a DHCPv4-only implementation for a long time.
On the flip side, this implementation had a lot of flexibility — the configuration syntax was almost a programming language, with expressions, variables, conditional expressions, and more. When it was first developed, it was fine-tuned for a mid-90s reality: little RAM, small networks, no concept of mobility, no need for a database and so forth.
IPv6 support was added in 2007 with version 4.0.0. Internally, this was coded as a separate source file, although externally it was the same binary that could be switched to work in IPv6 mode.
A serious problem with ISC DHCP was its partial failover support. It was based on an expired IETF draft that was DHCPv4-only. There was no failover or any redundancy for DHCPv6.
ISC DHCP used very complex C code with its own custom memory allocation and OMAPI interface to internally manage most data structures. That was hard to maintain, difficult to extend, and next to impossible to integrate with modern solutions, such as SQL databases and NETCONF, or to adapt to use multiple cores.
Kea — the way forward
During my first week at ISC, I was introduced to the long-term maintenance problems of ISC DHCP and the idea of writing a new DHCP server from scratch. Needless to say, I jumped on it right away. That’s how the Kea server came to be.
Kea is a new, modern DHCP server that has been developed by ISC. It provided DHCPv6 support from day one. Actually, that’s not entirely correct. Having a lot of experience with DHCPv6 and much less with DHCPv4, I implemented the IPv6 support first and the DHCPv4 came up second, at least in the early days.
Read: Getting started with Kea DHCP for IPv4 / IPv6
Over the years, the development team has grown substantially, so we are usually able to offer IPv4 and IPv6 support at the same time. Nevertheless, the solution is much more modular, compared to ISC DHCP.
The kea-dhcp4 and kea-dhcp6 daemons are two independent modules that users can run independently. This gives users much better flexibility now and in the future, when demand for IPv4 will be decreasing. Admins will simply stop running the kea-dhcp4 process when the time comes.
Kea vs ISC DHCP and Dibbler
Kea offers a number of substantial benefits over ISC DHCP and Dibbler.
First, it offers the capability to store leases and host reservations in a memfile (essentially a local CSV file) if you want to keep it fast and simple, but also lets you keep the data in MySQL, PostgreSQL, or even Cassandra if you want to embrace the advantages of SQL or CQL databases.
It’s highly extensible with a hooks mechanism that allows you to load additional hooks that provide extra functionality. There are more than a dozen hooks provided by ISC, as well as a C++ API interface to write your own. This is popular among people who want to deploy their own special flavour of DHCP, such as integration with their own customer databases, extra logging, or complex access control policies.
Another great benefit of Kea is its REST API. As of today, there are over 150 commands that allow you to dynamically alter about every aspect of the DHCP server operation. You can inspect, insert, update, or delete leases, reservations, subnets, options, networks, option definitions, client classes, and much more. This mechanism is fully supported for DHCPv6, too.
Kea provides a High Availability mechanism that supports both DHCPv4 and DHCPv6. And the development version (1.7.7) provides experimental support for multi-threaded mode, which gives a substantial boost to performance. We are still experimenting with various knobs, but our early experiments showed that being able to provision up to 37,000 devices per second is a possibility.
Read: Advanced Kea DHCP features
It’s the same as IPv4, but longer, right?
People often ask how tricky it is to deploy DHCPv6. They expect it to be the same as IPv4 and are surprised when life proves them wrong.
Yes, one of the fundamental differences in IPv6 is its longer 128-bit address. But there are many other aspects that you should be aware of when deploying DHCPv6.
The most common concern of any DHCPv4 administrator is to make sure to not run out of addresses. That particular problem is almost non-existent in DHCPv6, but it’s still possible to underprovision your DHCP server in the IPv6 world. You can run out of disk space, your database can get clogged, and if you deploy your HA poorly, the lag between partners can grind your server’s performance to a halt.
Fortunately, it’s now easy to monitor Kea servers with the recently released open-source Stork dashboard. For more information, watch ISC’s recent webinar on that topic below (slides).
And then there’s the false notion of one address per device. This is a pretty common assumption, coming out of address scarcity in the IPv4 world: the end-user can always run a Network Address Translation (NAT).
This is radically different in IPv6; when you boot any IPv6-capable device, you will quickly discover that it has multiple addresses on each interface. The whole concept of having multiple addresses is deeply embedded into the IPv6 design. This is something network operators should embrace rather than try to fight.
The DHCPv6 protocol allows a device to ask for multiple addresses and some devices do that. But there’s also another mechanism that changed the rules completely.
Prefix Delegation helps devices manage multiple addresses
PD or Prefix Delegation allows a device to request not a single or handful of addresses, but a whole prefix. The most notable example is a home gateway that retrieves an IPv6 address for itself but also requests a /64 or even /56 prefix to be used on its LAN-facing interfaces. This has a number of profound implications.
First, your customers can eat through your address space much faster — billions of times faster, actually. For example, if you have a /48 prefix and want to provide it to your customers, you can split it into 256 unique prefixes of /56. Note that the absolute minimum delegated prefix length is /64, so at most this can be used to provision 64K customers. Make sure you plan your network appropriately.
Second, PD allows connectivity to all IPv6-capable devices in your customers’ homes or offices. This restores the property that was long lost in the IPv4 world, due to omnipresent NATs — end-to-end connectivity. Think about all the Application Level Gateways (ALGs), port forwarding, and other tricks you had to pull off to make it somewhat work in IPv4. Those problems are non-existent in IPv6, thanks to end-to-end connectivity.
On the flip side, some people treated NAT as a ‘poor man’s firewall’. That’s also gone in IPv6. Make sure you have an appropriate firewall solution.
Kea technically has a piece of code that can return the NoAddrsAvail or NoPrefixAvail error status code. It probably is one of the least frequently used pieces of DHCPv6 code, but it’s there. Please do your best not to force Kea to use it.
Where’s my MAC?
And then there’s the clever idea people in the IETF DHC working group had in the early 2000s.
In the late ‘90s, hardware was not very reliable and people were concerned with network cards failing. When they were replaced, the MAC address changed, which meant suddenly the DHCPv4 server thought it was a new device and provided a new address. If the network used host reservations or DNS updates, those had to be updated as well. So the concept of the DHCP unique identifier (DUID) came to be.
The idea was that upon first boot, a device-generated its own unique identifier and continued to use it forever, even if its hardware changed. This had some benefits: the regular, bare-metal devices were easier to identify, even when using multiple interfaces. The idea looked nice and was adopted in DHCPv6 as the core identifier; it replaced MAC in that function.
The DHC working group made many wise decisions that stood the test of time, but this was not one of them.
DUID solved a problem that was not bothering anyone (when was the last time you swapped your failed NIC?) and brought many new ones. Dual-boot devices often use different DUIDs in each operating system; PXE devices often use different DUIDs in each stage of booting. Finally, it’s impossible to say what DUID a new device will get until it’s booted for the first time. This is especially undesirable in IT departments that want to preconfigure new laptops.
Fortunately, there’s a solution that alleviates many of those problems. Although the MAC address is not present in the DHCPv6 packet, Kea is able to deduce it using several different methods.
If your relay supports RFC 6939, it can insert the device’s MAC address as a relay option and Kea can understand that. Older relays can insert the MAC address in subscriber-id or circuit-id. In some access technologies, such as DOCSIS, the CMTS acting as a relay can insert DOCSIS options and Kea can understand that as well.
Finally, if your device uses link-layer (LL) or link-layer+time (LLT) types of DUIDs, Kea can peek inside and figure out what the MAC address is. None of those methods are 100% reliable in all deployments, but at least you have some fighting chance to figure it out.
It’s 2020. Is it done yet?
It’s 2020 already. Are the DHCP protocols complete now? Almost.
There are still new ideas popping up in the DHC working group in the IETF. Two of them are worth noting.
The first attempts to address the noise problem of IPv6 networks. Many devices, such as Android phones, are dual-stack capable but can operate in IPv6-only mode if need be. But they don’t have any way to conclusively determine that a network is IPv6-only, and they keep trying to configure an IPv4 stack even if IPv6 is perfectly functional.
There’s a work in progress to define an IPv6-Only-Preferred Option that, oddly enough, would itself be a DHCPv4 option. The idea is to configure a very basic DHCPv4 server that would essentially tell everyone “there’s no IPv4 here anymore; stop trying”. Since two major authors of this work are from Google, we can expect Android phones to get this capability pretty soon.
Another new work in progress is an ability to assign MAC addresses in a similar way to IP addresses. Yes, that’s not a typo.
There are two interesting use cases where devices are able to communicate over IPv6, yet they need to get MAC addresses.
The first is in the world of the Internet of Things (IoT): there are only 16 million MAC addresses in single organizationally unique identifier (OUI) address space and there are vendors who produce a lot of small, disposable devices these days. There are many new classes of devices that are essentially one-time use or that require only local connectivity, such as various smart sensors and thermometers. Although the MAC address space is reasonably large, it is not infinite.
Another use case is hypervisors in data centres. Modern hypervisors simply randomize MAC addresses when cloning or creating new virtual machines. Due to the birthday paradox, this may sometimes produce conflicts. Also, some administrators prefer to have control over the MAC addresses, for example, to introduce some structure into currently random assignments. To learn more about this, please take a look at this IETF 101 presentation.
A toast to IPv6!
IPv6 has been in development for over 25 years, and after all these years, it is being deployed. Let me borrow a toast that is frequent in some IETF gatherings: Here’s to the universal deployment of IPv6!
Tomek Mrugalski is the Director of DHCP Engineering at Internet Systems Consortium (ISC) and one of the original authors of Kea DHCP.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.