Does One Need DHCP(v6)?

I’ve covered DHCPv6 quite a bit in the past, e.g. in these two ‘A Deep Dive into DHCPv6’ blogposts, this one on RFC 6939, a few other contributions discussing it in some way (1, 2, 3) and a talk on ‘Secure & Reliable DHCPv6’ at the Troopers #TR15 IPv6 Security Summit (slides & video).

I also had a number of Twitter exchanges on DHCPv6, and one of the communication partners recently reached out to me with an interesting question. That person asked: “we consider avoiding DHCPv6 in our campus networks, but the security team insists on using it to be able to properly identify systems which act in a malicious way. what’s your opinion?” – In this post I’ll try to give a response.

Before I start with a technical discussion myself let me further add that several IPv6 deployment case studies mention all types of issues with DHCPv6, like this one from CERN, this one from Microsoft and this one from Deutsche Telekom. You might think about this for a second… (if this wasn’t clear, let me rephrase: in general DHCPv6 might be a piece of crap whose use should be carefully considered from a production [-readiness] perspective).

In ancient IPv4 times, in enterprise networks usually DHCP served one or several of the following functions:

  • 1a) provisioning of dynamic addresses (in a more or less centralized manner).
  • 1b) provisioning of other IP-related parameters/properties needed by clients (default gateway, DNS resolvers, NTP servers, others e.g. place to find firmware/boot image etc.)
  • 2) simple access control (like ‘only MAC addresses registered in CMDB get an IP address from DHCP’, which is supposed to prevent unauthorized network access. I’ve once seen this in a large automotive ICS environment).
  • 3) contribute to DFIR activities by providing mapping of MAC addresses to IP addresses found in log files, PCAPs etc.

Now let’s look at those from an IPv6 perspective.

  • 1) For address provisioning DHCPv6 is no longer needed (hosts can do that on their own, via SLAAC), for the default gateway it can’t be used, and the vast majority of systems can get their DNS resolvers via RAs (option 25/RDNSS as of RFC 8106; see also Chrispost when Windows 10 eventually had it). That leaves distributing NTP servers which in turn some operating systems take into their own hands anyway (e.g. Windows).
  • 2) That ‘simple access control’ approach could be considered a curiosity for specific environments, and some of you might be reminded of those times when a printer’s test page (containing a MAC address) was sufficient to get access to enterprise networks running complex & expensive ‘NAC’ solutions…

That leaves us with the ‘we need DHCP(v6) for DFIR contributions’ thing, which was at the core of the initial question. To evaluate (the need for) this we should keep in mind that during a host’s lifecycle on a network a lot of properties can potentially be observed at various points. These include

  • the MAC address(es)
  • IPv6 address(es)
  • IPv4 address(es)
  • FQDN
  • mDNS-related information or similar (NetBIOS names)
  • username, e.g. in authentication context
  • X.509 certs (machine-/user-based) and namely the wealth of data they contain
  • RADIUS-related information

The correlation of the first two ones (MAC address to IPv6 addresses) or, maybe even better, to a username might hence be easily inferable from other information which is observable/can-be-logged at some point of a host’s lifecycle, e.g. X.509 cert based info in the context of Wireless EAP protocol (EAP-TLS or PEAP in most enterprise networks).
Read: you might not need DHCPv6 logs for that but just have a look at other sources available anyway (Bryan ‘The Packet Master’ Fite once coined the term ‘latent capabilities’ for this approach). In the following I’ll provide some examples.

Probably the best known of such capabilities is the ‘ipv6 neighbor binding logging’ command from Cisco’s IP Snooping framework which is available on most of their (physical) enterprise level switches (please note that I’ve never been a big fan of most features of that tool set, due to it’s complexity and immaturity in [test] deployments I’ve seen, but that logging capability is definitely helpful).

Another example would be the ‘NDP Monitoring‘ feature on Palo Alto devices which I learned about from Johannes Weber:

Finally here’s a very nice example which my friend Eric Vyncke showed in his session on IPv6 security at last year’s Cisco Live Europe:

tl;dr: instead of using DHCPv6 (bringing its own complexities and troubles) to solve that security requirement it might be a much better idea to analyze which data bits one might have available in an environment anyway and how to correlate them.
Assuming that some of you readers are still in the early stages of the IPv6 deployment in your organization you might even be able to file respective feature requests (e.g. ‘logging of IPv6 address(es) and MAC address of a client directly after its association in a wireless network’) to the vendor of your network gear.

Published by Enno

Old-school networking guy with a certain focus on network security. This blog is a private blog and it contains private musings, even though I have a day job around the Internet Protocol. I leave it to the valued reader to guess which version of it ;-). Some tweets on related topics at

4 thoughts on “Does One Need DHCP(v6)?

  1. Thank you for these interesting posts! I wanted to add that some Fortigate devices (maybe all?) have a useful feature called Device Detection on an interface (physical or VLAN), one can just switch it on. If SLAAC is in use in dual-stack network and one needs to find the device based on its IPv6 address (seen in logs) then the list of detected devices allows to find one quickly and in that list also the MAC-address and IPv4 address are visible to better identify the device. This list has a certain time to keep history (fixed or configurable? I don’t know) so when I checked an IPv6 address that I had used yesterday and which was not in the network anymore, it was still in the list. This list even showed the IPv6 addresses that were used by the clients in their own networks (usually phones)! But I’ve seen in the past that the OS detection / classification is not 100% reliable.


    1. Thanks for the great article. for the Forti you can use


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: