Using DHCP to manage IPv6 addresses is known as stateful DHCPv6, because the DHCP server maintains the state of IP address leases centrally. In the last post we looked at its limitations, as opposed to SLAAC. Why would you use DHCPv6 to manage IPv6 addresses? Well the main reason is accountability. One of the most important aspects of this is host DNS registration: having your hosts registered in DNS and available for reverse DNS lookup is the most basic way of tracking them. If you use DHCPv6 for address assignment then the DHCP server will register the host with DNS (typically the two services run on the same server). If you are using SLAAC then hosts themselves are responsible for registering themselves in DNS : this is inherently less reliable.

In fact DHCPv6 has made DNS registration more robust than under IPv4. With IPv4, it’s a simple model: each MAC address is a separate entity, and each interface makes its own independent registration in DHCP. This can cause problems with DNS registration when a host has multiple interfaces, as is increasingly the case where laptops are connected both to the office wired LAN and to a wireless network. If the host is registered in DNS under one interface, then depending on how things are configured the second interface may not be registered in DNS at all. Alternatively the second interface may supersede the DNS registration of the first interface.

DHCPv6 introduces the concept of the DHCP Unique Identifier (DUID). The DUID is a persistent identifier of the host rather than any specific interface. IP addresses are actually assigned to Interface Associations (IAs) which identify the individual interfaces. Thus DHCPv6 understands that hosts can have multiple interfaces and DNS hostname registrations can be done according to the DUID rather than the IA.

Another reason that you might want to use DHCP to manage addresses is to make it easier to find out an interface’s MAC address from its IP address. Take the example of a security alert you receive from your intrusion prevention system or DNS firewall: an IP address is trying to contact a known botnet command and control (C2) server. You want to disconnect that IP address from the network as quickly as possible, preferably automatically. Under DHCPv4 it’s possible by looking up the IP address in the DHCP server and extracting the MAC address, and then using whatever tools your network may provide to track down the specific network port that that MAC address is connected to. You can then disable the port.

Sadly, the way that DHCPv6 works makes this much harder. Although the DUID of a host usually contains a MAC address, it is typically generated at install time from the MAC address of any interface on the system. That interface can in fact be removed from the host after the DUID has been generated and the DUID will stay the same. The Interface Association Identifier (IAID) is generated in an arbitrary way by the host, and may have no relation to the physical MAC address of the interface. If the DHCP server is not on the same subnet as the client, and is receiving the DHCP request via a relay, then the server has no visibility of the client’s MAC address. Thus there can be no way of building a centralised mapping of IP addresses to MAC addresses. RFC 6939 does provide a mechanism for DHCP relays to forward the client’s MAC address to the DHCPv6 server, but this is quite a recent proposal. So, one step forward, one step back.

Next post I’ll summarise the SLAAC vs stateful DHCPv6 debate.