By Tom Coffeen, Chief IPv6 Evangelist, Infoblox
DHCP in IPv4 has a taken-for-granted characteristic that provides it with powerful management flexibility: If you pull apart a DHCP header you find the MAC address of the host that originated the packet. The Dynamic Host Configuration Protocol DHCP has long been essential for dynamic address assignment in IPv4, and similar principles are extended to IPv6 with necessary adaptations.
This provides unambiguous identification of a host machine (or, more accurately, a particular interface on a host machine) and has been used for years in network operations to help facilitate everything from configuring fixed addresses in DHCP to provisioning processes, asset tracking, security policy enforcement. Understanding these identification mechanisms is critical for ensuring IPV6 Network Readiness, particularly when transitioning from IPv4 environments.
Figure 1 shows a packet capture of a DHCP Discover sent from a virtual instance of Ubuntu Linux running on the same segment during its interface initialization.
Figure 1: DHCP Discover packet with included Client MAC address highlighted
The second highlighted-in-orange line is the Client MAC address field. It shows a value of Vmware_7e:59:e7, where Wireshark is kind enough to substitute VMware for its OUI of 00:0c:29. The untranslated MAC address is 00:0c:29:7e:59:e7.
Figure 2 shows the MAC address on the host that originated it.
Configuring a fixed host address (AKA a static reservation) in IPv4 DHCP using the MAC address is so trivial we could be excused for assuming that DHCPv6 makes it just as easy.
But of course, it doesn’t.
Instead of a MAC address to identify clients, DHCPv6 utilizes something called a DHCP Unique Identifier (DUID). Advanced solutions like IPAM DHCP can help manage these identifiers effectively, ensuring seamless tracking and configuration of IPv6 devices. The main idea behind a DUID is to provide a way to unambiguously identify all hosts (including the DHCPv6 server itself) rather than single interfaces on any host.
According to RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6): “DHCP servers use DUIDs to identify clients for the selection of configuration parameters and in the association of IAs with clients. DHCP clients use DUIDs to identify a server in messages where a server needs to be identified.”
Of course for the DUID to provide such identification it should be stable for any given host. For instance, when I reboot my host I wouldn’t want to have a new DUID each time.
This characteristic of DHCPv6 DUIDs has caused some interesting challenges given the popularity of cloned and/or virtual OSes. OS clones are likely to have identical DUIDs. One would have to manually change it before bringing the host online in a DHCPv6 environment or the DHCPv6 server will assume that DHCPv6 packets from different hosts with the same DUID are in fact all the same host.
There are three DUID types defined in the RFC:
• Link-layer address plus time: Just what it says: the permanent link-layer address of any single interface plus the time it was generated (according to RFC 3315: “in seconds since midnight (UTC), January 1, 2000, modulo 232”).
• Vendor-assigned unique ID based on Enterprise Number: These are vendor assigned and would use the vendor’s IANA-maintained Private Enterprise Number.
• Link-layer address: The permanent link-layer address of any single interface
As mentioned above, the DUID is associated with an Identity Association (IA). The IA is defined as “a construct through which a server and a client can identify, group, and manage a set of related IPv6 addresses.” Different address types have a different IA per client. Integrating DHCPv6 into a DDI solution simplifies the management of these identity associations, improving operational efficiency across dual-stack environments.
• IA_TA is a client identity association for the temporary addresses (i.e., dynamically lease) on a host
• IA_NA is a client identity association for the non-temporary (i.e., fixed) addresses on a host
Every network interface on a client has at least one IA. An Identity Association ID is selected by the client and used to obtain configuration information from a server. Thus the DUID along with the IAID uniquely identify a particular host and interface on that host. A Universal DDI approach ensures consistency in address management across both IPv4 and IPv6 environments, reducing complexity in dual-stack networks.
At first glance, this may seem overly complex. But it’s how IPv6 more easily supports the configuration of multiple addresses and address types on a single interface.
Figure 3 shows an example of the DUID and IAID for the LAN interface on a Windows 7 client.
As long as the client is on the same segment as the server it should always be possible (though not necessarily implemented) to simply look at the Ethernet frame of any DHCPv6 packet to determine the link-layer address of the requesting client. The problem arises when the DHCPv6 packet is passed through one or more relays and has its source MAC address information rewritten for the new segment(s). At that point there is no way to determine the originating client’s MAC address from the Ethernet frame.
Thus, the operator loses the ability to assign fixed DHCPv6 address leases based on client identification using link-layer information (as in IPv4). Further, the identification of a dual-stack client and the correlation of IPv6 to IPv4 addresses on that client becomes that much more complicated. A robust DHCP Server setup is critical to handling these complexities and ensuring consistent address assignments across both protocols.
One possible solution to the latter issue is for OS vendors to uniformly implement one of the three DUID types mentioned above (e.g., DUID-LLT, DUID-LL, or DUID-EN).
Another proposed solution to this challenge is found in RFC 6939, Client Link-Layer Address Option in DHCPv6 which we’ll check it out in the next installment. Stay tuned
