In this example, we will configure a Windows XP SP2 DHCPv6 client and a Unix DHCPv6 server. The client software is Dibbler (also available for Linux), and the server software is WIDE-DHCPv6 (formerly KAME).

First, download and install Dibbler. You may wish to install only the client to minimize confusion. Find the "Dibbler" folder under [Start Menu] -> [Programs] and run "Client Install as service". Edit the client configuration file (shortcut in same folder as service installer). Set up an interface declaration as follows:

iface "Local Area Connection" {
  ia
  option dns-server
  option domain
}

(Your interface name may differ and can be found with the ipconfig command or from the Network Connections control panel.) If necessary, create an exception in the host's firewall settings to allow the dibbler-client program to communicate with any host. (Use the full path, C:\dibbler\dibbler-client.exe by default.) Bring up the system services list ("Administrative Tools" control panel), locate the Dibbler service, and start it. Now locate the Dibbler installation directory and examine the contents of the file client-duid. This will contain the client identifier used in the DHCP request. The file is not generated until the service starts.

Next, download and install WIDE-DHCPv6. Locate the installed configuration file (which may be a sample that needs to be copied to the correct filename) and tailor it to your needs, using the following example as a guide:

# DNS server search list, v6 addresses only
#option domain-name-servers 2001:48a8:x:x::x;
option domain-name-servers 2001:48a8:3:14::1e;

# DNS suffix search list
option domain-name "tc.mtu.edu";
option domain-name "mtu.edu";

interface em0 {
	# interface parameters go here
};

host some-pc {
	# the contents of Dibbler's client-duid file
	# (or any other client DUID)
        duid 00:01:00:06:46:e2:f8:c2:00:08:74:da:ab:64;

	# host's address with preferred and valid lifetimes in seconds
	address 2001:48a8:0:2::1:c8 1800 7200;
};

Note: the second, uncommented DNS server above is dns2.mtu.edu. If you have an IPv6-capable DNS server in your department, please list it in place of the commented-out entry above the dns2.mtu.edu entry. You are not required to list IPv6 nameservers or domain suffixes, so you may wish to omit these parameters entirely, in which case the host should use IPv4 nameservers and already-configured domain suffixes. Nameservers will return IPv6 addresses in response to queries if such addresses are available, regardless of which protocol version was used for the query; it is up to the host and its applications to decide what is appropriate.

Start dhcp6s with a command line such as:

dhcp6s -c /usr/local/etc/dhcp6s.conf em0

You may wish to restart the Dibbler service on the PC at this time, as it has likely decreased the frequency of its requests by now. If your DHCPv6 attempt is successful, you can edit the Dibbler service properties to ensure automatic start-up.

Note: Dibbler's support for client-server authentication is "experimental" as of v0.7.1.

By default, the type of DUID generated by Dibbler is "llt", meaning "link-layer plus time", indicated by the leading 00:01 in the above host entry—it is the link type (ethernet, 00:06) followed by the time at which the file was created (46:e2:f8:c2, or 1189279938, or 2007-09-08 15:32:18 EDT) followed by the MAC address. The presence of a timestamp in the DUID could be problematic if a machine were reinstalled and the client-duid file were not preserved or identically recreated.

With a duid-type of simply "ll", the four bytes for the timestamp would be eliminated. It is supposedly possible to add the line "duid-type ll" to Dibbler's client.conf to force it to generate an ll-type DUID; however, I have not been able to get this to work. But it is possible to create (by some means other than Dibbler) a client-duid file with an "ll"-type DUID and use it without the duid-type configuration directive. If you wish to hand-craft an "ll"-type DUID, it should be of the format 00:03:00:06:[MAC address], where 00:03 is the "link layer" DUID type, the 00:06 is the link type for ethernet (as above), and the MAC address is 6 colon-separated bytes. See RFC 3315, section 9.

To use WIDE-DHCPv6's dhcp6c on a Unix client to be served by the above WIDE-DHCPv6 server (or, most likely, any other DHCPv6 server), create a dhcp6c.conf in the appropriate location based on the following example:

id-assoc na 0 { };

interface eth0 {
  send ia-na 0;
  request domain-name-servers;  # optional
  request domain-name;          # optional
};

Next, create a dhcp6c_duid file. WIDE-DHCPv6 uses binary DUID files, and to further complicate matters on little-endian hosts, the first two bytes (DUID length) are in network byte order, while the actual DUID is in host byte order. If you wish to use a link-layer DUID or specify a timestamp for a link-layer-plus-time DUID, download this perl script and run it with a command-line parameter of your interface name to generate a dhcp6c_duid file appropriate for the interface. This has been tested under FreeBSD 6 (little-endian 32-/64-bit) and Fedora 7 Linux (little-endian 32-bit). The script also appears to work on a big-endian, 64-bit host, but the resulting file has not been tested.

For cases where the script cannot parse your host's ifconfig output, omit the interface name and and instead use the "-m" switch to specify the interface's correct MAC address.

In either case, place the resulting dhcp6c_duid file in the directory where dhcp6c expects to find it (/var/db by default).

To generate an LLT DUID, use the "-t" switch, which expects an integer timestamp or the word "now". dhcp6c will also generate an LLT DUID file with the current time if no file exists at startup.

If you've generated your own DUID, verify it with the od command:

LL DUID:

# od -x dhcp6c_duid
0000000 000a 0300 0600 MMMM MMMM MMMM
0000014

LLT DUID:

# od -x dhcp6c_duid
0000000 000e 0100 0600 TTTT TTTT MMMM MMMM MMMM
0000020

"000a" represents the LL DUID length of 10 in hexadecimal and network byte order; "000e" represents the LLT DUID length of 14 in hexadecimal and network byte order; "M" represents the MAC address in host byte order; "T" represents the specified hexadecimal time value in host byte order. The "0300", "0600", and "0100" would be represented as "0003", "0006", and "0001" on big-endian architectures. You may retrieve/reconstruct an auto-generated LLT DUID with such an od command (adjusting for host byte order on little-endian hosts), though it is probably easier to use "-t now" with the above script, as the entire DUID will be printed as hexadecimal bytes on script completion.

Current versions of WIDE-DHCPv6 support client-server authentication. Implementing it is left as an exercise for the reader, though assistance from Telcom is available upon request. It should be noted that the WIDE-DHCPv6 server fails to authenticate some or all relayed requests. Whether the problem lies in dhcp6-relay, dhcp6s, or my understanding of authentication configuration is unknown at this time.

A DHCPv6 client is bundled with Fedora 7. It appears in some ways to be the WIDE-DHCPv6 client but is not. It does not support authentication, and some other configuration directives are absent or slightly different. The dhcp6c_duid file appears to be of the same format as WIDE-DHCPv6's. I've not been able to make it send an actual DHCPv6 SOLICIT, only an information request (stateless configuration, requesting only DNS settings).

• DHCPv6 does not currently permit specification of a prefix length or gateway, as periodic advertisements from the router will inform all v6-capable hosts as to what the proper mask length and gateway address are.
• Unfortunately, DHCPv6 relay between subnets is not available on the campus routers at this time. Multi-subnet departments will be responsible for their own relaying until our routers support relaying.
• WIDE-DHCPv6 will assign only global unicast addresses. In fact, it exits with an error if a host's specified address or prefix matches the site-local (fec0::/10) or link-local (fe80::/10) network prefixes or any other non-global or non-unicast prefix. It may be possible to edit the source to permit site-local addresses, but doing so for link-local addresses, while possible, is not advisable or probably even particularly useful.