Monthly Archives: June 2017

IPv6 Part 5: Stateful DHCPv6

Posted on by
1

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.

IPv6 Part 4: SLAAC history

Posted on by
Reply

As I explained in the last post, IPv6 SLAAC addressing derives the host portion of the routeable address from the interface MAC address, and discovers the network portion from the network itself. Those of you who have been in the IT business long enough will find this familiar: it’s similar to the way that Novell’s IPX protocol worked. In fact, IPX was based on Xerox’s XNS protocol, which goes back to the late 1970s. In both cases, the host portion of the address was 48 bits long, the length of the MAC address: MAC addresses are globally unique, thus ensuring no local address clashes.

Novell introduced the Service Advertising Protocol (SAP), whereby servers advertised their services via broadcasts to routers. By querying their local router, clients could then choose which service to connect to from a dynamically compiled list. Thus service discovery was decentralised, in a way that was consistent with the decentralised way that clients obtained their addresses. When NetWare 5 moved to running over TCP/IP, Novell migrated to the open Service Location Protocol. Microsoft’s networking had similar distributed methods of advertising resources.

DHCP was already in existence when SLAAC was developed. SLAAC’s big advantage over DHCP was its simplicity: it didn’t require the administrative overhead of DHCP. SLAAC as originally conceived did one job and it did it very well: it assigned an address in a simple, scalable way. However what if you weren’t using a network protocol like NetWare or Microsoft that advertised the available resources? Specifically, how did clients configure their DNS servers and DNS search domains? The answer was to use a combination of SLAAC for address assignment and (stateless) DHCP for the other parameters. So you still needed to set up DHCP servers; however the configuration information that they distributed was relatively static.

So you couldn’t avoid DHCP completely. However, it’s difficult to manage addresses from DHCP servers in a way that’s scalable and resilient. Microsoft’s DHCP server was (and is) probably the most widely used DHCP server for IPv4, and to provide load-balancing and redundancy the typical method was to configure “split scopes” on multiple DHCP servers. Each server would assign addresses from a different chunk of the same subnet’s address range. Clients would receive their address from whichever DHCP server responded first. Clients would continue to renew their address leases from the same server, until or unless it became unavailable; they would take a while to realise that a server was unavailable, and wouldn’t use it again once recovered until they were forced to release their addresses and begin the whole address assignment process again.

Things got really messy if you used DHCP address reservations. There was no automatic replication of reservations across the servers, so each reservation had to be copied from server to server manually. Inevitably this was error-prone: if you needed specific hosts to always get the same address, for example for firewall rules, then things could often get broken.

Microsoft’s DHCP implementation has gradually improved. Windows Server 2012 introduced DHCP failover for IPv4, with dynamic replication of DHCP address state. However, this won’t manage IPv6 addresses: the assumption is that you will use SLAAC for that. In addition, DNS, DHCP and IP Address Management (DDI) systems like Infoblox and Efficient IP have emerged that dynamically replicate DHCP address state, for IPv6 as well as IPv4, in an effective and resilient way. The DDI systems come with a price tag however, as opposed to Microsoft DHCP which comes bundled with Windows Server. So why would you use DHCP to manage IPv6 addresses? In the next post, I’ll take a look at why you might want to.