Not Just Addresses

The auto-configuration mechanisms built into IPv6 mean you don't necessarily need a DHCP server in order to avoid the cumbersome task of manual address configuration. However, modern DHCP servers don't just hand out addresses. Unless you're using some special extensions or add-on services, the native auto-configuration features of IPv6 won't configure important settings such as the DNS server, so, in practical terms, a DHCP server is still required for larger networks.

RFC 3315 [1], which appeared in July 2013, defines the DHCPv6 protocol. As you can imagine, the long IPv6 addresses and other changes to the protocol, such as the preference for multicast versus broadcast addresses, result in significant changes to the DHCP service. Even the DHCP ports are different with IPv6 (UDP 546 with the client; 547 with the server).

Several options are available for DHCP in IPv6, including Dibbler [2], Internet Systems Consortium (ISC) DHCPv6 [3], and WIDE-DHCPv6 [4], and each has a slightly different approach to a very perplexing problem.

What completely messes up the existing concept of IP address allocation is a parameter called the DHCP Unique Identifier (DUID), which all DHCPv6 clients compute during the first call and then store in a file. According to Paragraph 9 of RFC 3315, the DUID is the only characteristic by which a server can recognize its clients – and vice versa. The RFC even says in the RFC that: "Clients and servers MAY NOT interpret DUIDs in any other way."

The DUID can be generated three ways:

• A timestamp plus link layer (the MAC address with Ethernet).
• An enterprise ID plus a variable part.
• Just the link layer address.

The link layer address might sound like a MAC address, but it isn't. According to the RFC, "This type of DUID consists of two octets containing the DUID type 3, a two-octet network hardware type code, followed by the link layer address of any one network interface that is permanently connected to the client or server device." In other words, the DUID refers to a device and is not (solely and uniquely) a feature of a network card's MAC address (Figure 1).

Figure 1: To form an IPv6 address ID from the MAC address, FFFE is inserted and the second bit is flipped in the first byte.

The Layer 3 ICMPv6 protocol discovers the hardware address information in the IPv6 world, a task assigned to the Layer 2 Address Resolution Protocol (ARP) in IPv4. The process of discovering devices in IPv6 is known as the Neighbor Discovery Protocol (NDP) [5]. The formal approach without the static link to the MAC address might appear clever at first because it means that a device on the network is equally identifiable on all interfaces. However, the approach used in IPv6 leads to problems in a virtualized world as soon as the administrator clones a device. All copies of the master have the same address when you clone a virtual machine because the DHCPv6 server thinks they are the same machine. On a positive note, administrators don't have to make any changes to the DHCP configuration after replacing a network card.

Non-Compliant

The Institute for Solid State and Materials Research in Dresden, Germany, had a network management tool based on unique allocation of MAC addresses to IP addresses. The first experiments with IPv6 in 2009 made Henri Wahl, who worked at the Institute, realize that automatic configuration via the distributed prefixes was not enough. Wahl started to develop dhcpy6d. As the name indicates, the tool is written in Python. After a few years of work at the Institute, Wahl released the software in 2012 [6]. You can download the source code from GitHub or obtain it from the project's home page [7].

Dhcpy6d intentionally violates the requirements of RFC 3315. Other tools, such as the ISC DHCP daemon, now support the option of extracting the MAC address from the client's DUID in order to allow a configuration based on the MAC address. Dhcpy6d takes the opposite approach. If a new MAC address but the old DUID are used after a change of hardware, everything will still work and the connection between the MAC and IP is lifted. In addition to identifying by MAC address, dhcpy6d also allows identification via the DUID, as intended by the RFC.

Dhcpy6d Sorting Logic

Dhcpy6d assigns configurations based on classes, address ranges, and clients. A class determines parameters that apply to a group of clients; for example, the name server and the default router. Whether or not a client belongs to a class is defined explicitly in the client configuration or else by filtering by hostnames, MAC addresses, or DUIDs (with Python regular expressions).

As a final parameter for organizing clients in classes, dhcpy6d uses the interface as follows: All requests that arrive via network card 1 are Class A, and all of those that arrive via NIC 2 belong to Class B. This approach assumes dhcpy6d has a foothold in each relevant network. Dhcpy6d does not provide a means for allocating network ranges via a DHCPv6 relay.

A client describes a single device; administrators can assign the client a hostname and an explicit address. What is important is that the client's definition states the class to which the client belongs. All clients that are not explicitly listed are put in the default class, and the parameters that dhcpy6d uses for this class automatically apply.

The address range contains the template the DHCP server uses to allocate IPv6 addresses for a class. For the address range 2001:db8::$mac$, for example, it simply appends the client's MAC address to the 2001:db8::/64 prefix. Mappings between class and address range are one to many – members of a class can be allocated addresses from multiple address ranges.

For each address range, dhcpy6d defines how long the mapping should apply, whether the system will receive DNS updates, and in which zones the client is registered.

Installation and Setup

Dhcpy6d runs on Linux, FreeBSD, NetBSD, OpenBSD, and Apple OS X. I used the version from the Git repository on Gentoo Linux for this article. The dhcpy6d website [7] offers downloadable packages for RPM- and Deb-based distributions. Version 2.6 of the software (2.7 is better) requires Python and the dnspython package for updating the name server, as well as the Python MySQL module if MySQL is used as the database. If SQLite is used instead, you need to install the corresponding package and Python support.

You'll also need a few external script files containing modules. After running git clone, you can run the software directly in the directory. Use the python2.7 binary to make sure you're really using Python 2.7.

Dhcpy6d saves the leases in a SQLite or MySQL database. A supplied SQL file is used to initialize the tables. The command

sqllite volatile.db < doc/volatile.sql

generates the SQLite database. The project website describes how to install both the MySQL databases and client lists.