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.
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.
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). 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:
• 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.
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.
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
