Almost this entire page may be a large result of various copy-and-paste from internal notes made earlier. Much of this may still need a decent amount of verification to be considered useful/reliable.

(Perhaps some phrases to Router Advertisements should be changed to the more generalized term of Router Discovery Messages.) [#dhcp6cli]:

DHCPv6 clients

[#iscdhc6c]: ISC DHCP (version number at least 4)
Path notes

These instructions are designed for use with OpenBSD. With OpenBSD, at the time of this writing, there is a built-in variation of ISC DHCP. (According to Kliment Andreev's blog of ISC DHCP server on OpenBSD 4.2, “The original DHCP server that is provided with OpenBSD is a custom build based on ISC DHCP v2.”) Adding ISC DHCP to the already-existing DHCP/IPv4 software can work fine: they can co-exist and even be running at the same time (with ISC DHCP version 4 handling DHCPv6 and the OpenBSD variation supporting DHCP/IPv4). However, one thing to keep in mind:

Be careful with the paths!

By default, the package's manual pages may be used, while by default, the built-in executables may be used. (This means that the manual pages will, by default, not match the executable file.)

These instructions help to take care of the issue for OpenBSD. However, the paths shown in these instructions will probably not work with other operating systems. In many cases, other operating systems might come with ISC DHCP built-in, and so paths for executable files and man pages might be completely unnecessary.

Similar path notes, and with more detail, are provided in the section about DHCPv6 servers in the section about ISC DHCP. That section discusses the manual pages and executable files for the DHCPv6; the directories are the same for the files related to the DHCP/IPv4 client (and for DHCRelay).

Installing the client

Details will vary based on package management software, which generally varies between fairly different operating systems. See: software installation. The following shows an example commands that may work okay with OpenBSD (if the software installation process has been configured in a way that works with this exact command):

sudo -i -u root -ivv isc-dhcp-client

The following example commands continue to be designed for OpenBSD. Once again, other operating systems will vary and so users of other platforms may wish to check out the software installation page.

View files:

pkg_info -L isc-dhcp-client

In OpenBSD particularly, check out where the software got installed to.

pkg_info -L isc-dhcp-client | grep dhclient
Running the client

For this example, have the PAGER variable set. The following works well with sh.

echo ${PAGER}
[ "X${PAGER}" = "X" ] && export PAGER=less

Try running the software:

echo ${PAGER}
[ "X${PAGER}" = "X" ] && export PAGER=more
echo ${PAGER}
time sudo /usr/local/sbin/dhclient -6 -q -v 2>&1 | ${PAGER}

Like what you see? Take off the -v the next time the software is run, and it will show far less output. That will probably be preferred by most people when the system is booting up (because most background processes end up being fairly silent when they work successfully).

For more log info, see /var/log/daemon (on the system running the client software; though the same filename is also used by the server if the server is running ISC DHCP 4, and may very likely be used by other DHCPv6 servers as well.) Note that the log may show communication occurring over link-local addresses (from FE80::/10), so figuring out the computer's link-local address may be helpful in understanding the log. (See: available NICs, obtaining current network addresses.

Potential problem(s) mailing list post discussing command line parameters shows that -D might not be accepted by some versions of the software, and that it might not use an approach recommended by RFCs even if it is functional.

Determining a DHCPv6 DUID with ISC DHCP 4 client

(This may still need confirmation yet...)

Upon getting a lease of some sort, the DUID should be visible in the /var/db/dhclient6.leases file. The first line may say default-duid but the actual DUID is in the line that says “option dhcp6.client-id(speculation)


It is interesting that the leases file for DHCPv6 does not seem to match how the DHCP/v4 is handled. /var/db/dhclient.leases.* contains a reference to the network adapter's name, and seems to have no permissions provided (“----------”, so the permissions settings exist but no permissions are granted) while /var/db/dhclient6.leases is writable by the “user” and readable by everyone. (This might have been due to mixing OpenBSD's variation of DHCP client software for DHCP/v4, and ISC DHCP for DHCPv6.)

[#wdhcp6c]: WIDE-DHCPv6 dhcp6c
Support/compatibility info
Notes about Debian

Wayback Machine @ archive of “Native PPP IPv6 in Debian” blog entry is about PPP and includes information about WIDE. Of particular note: “When you install the WIDE DHCPv6 client it starts automatically, with an” (sic) “non-useful config.” Be sure to stop that software if the only desire is to be running the server.

After setting up /etc/wide-dhcpv6/dhcp6c.conf, the recommendation provided by that site is to restart WIDE-DHCP with “ invoke-rc.d wide-dhcpv6-client restart” and then see if a better address is obtained.

It seems like some debugging information may be increased when using the debugging options and when the program is run in foreground mode. (Some testing seemed to indicate that when the program is not run into foreground mode, it may not be as prone to output its DUID.) So, here is an example to run the program with lots of debugging:

sudo dhcp6c -dDfip /var/run/ if0 2>&1 | tee -a /tmp/dhcp6c.log

Customize the name of the interface (from if0) as needed.

[#wdhc6uid]: Getting the DHCPv6 UID used by a WIDE-DHCPv6's DHCPv6 client.

Determine where the DUID file needs to be. One way is to check documentation: another way may be to use the included software to create a DUID (even if that DUID gets replaced afterwards).

A way to have a known DUID is to download a PERL script (if the source can be trusted: of course standard precautions dictate that this script should be trusted before being run on a machine) and then use that script to generate a new, known DUID. The problem with the included software is just that there may not be quite so easy of a way to know what the DUID is.

Using included software to make a DUID

Upon installing the software, the client might not have a DUID yet. Running the client will create one. For instance:

sudo dhcp6c -dDfp /var/run/ /dev/null | tee -a ~/dhcp6c.log

The first part of the example output may look something like:

Mon/DD/YYYY hh:mm:ss: gethwid: found an interface if0 for DUID
Mon/DD/YYYY hh:mm:ss: get_duid: generated a new DUID: 00:01:00:01:16:fe:dc:ba:98:76:54:32
Mon/DD/YYYY hh:mm:ss: get_duid: saved generated DUID to /var/db/dhcp6c_duid

The remaining output may contain some errors, at least one of which was rather intentionally created. None of these errors really matter (at least at this early part of the process).

Mon/DD/YYYY hh:mm:ss: dhcp6_ctl_authinit: failed to open /etc/dhcp6cctlkey: No such file or directory
Mon/DD/YYYY hh:mm:ss: client6_init: failed initialize control message authentication
Mon/DD/YYYY hh:mm:ss: client6_init: skip opening control port Mon/DD/YYYY hh:mm:ss: ifreset: invalid interface(/dev/null): Device not configured
Mon/DD/YYYY hh:mm:ss: main: failed to initialize /dev/null

(If so, then the dhcp6c command may return a non-zero error code, although the above example may not show that since the tee command may return zero as an error level.

Re-running this may show some different output in the beginning. Instead of three lines about creating a DUID, the result may look like:

Mon/DD/YYYY hh:mm:ss: get_duid: extracted an existing DUID from /var/db/dhcp6c_duid: 00:01:00:01:16:fe:dc:ba:98:76:54:32
Creating a DHCPv6 UID with a downloaded PERL script

This approach requires PERL. (Before shuddering about the insane amount of work needed to install PERL, see if it is pre-installed.)

Note: This involves downloading a file form the public Internet, and that file does show a (C)Copyright notice. At the time of this writing, it hadn't been established if legal terms are intended to allow outsiders to be using this file. It seems likely that this was meant for the general public, so this guide's text does show how to do this, but determining the file's intended distribution should be determined, rather than assumed, before relying on using the file.

RJ Systems: Linux System Administration: DHCPv6 stateful autoconfiguration: section 7 “Client DUID file replacement” goes on to say, “The only problem is that we don't know what the value is of the automatically created DUID, so the easiest solution is to create a new DUID of which we will know the value.” The page goes on to provide a solution, namely to use Jeffrey F. Blank's program available at Michigan Technological Univerisity's web page.

We have Michigan Tech DHCPv6 example to thank for this. (According to RJ Systems: Linux System Administration: DHCPv6 stateful autoconfiguration: section 7 “Client DUID file replacement”, it seems that the author of this text at Michigan University is Jeffrey F. Blank. That name does show up in the PERL file.)

Michigan Tech DHCPv6 example says, “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 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.”

curl -LRo ~/
cpytobak ~/
sudo cp ~/ /usr/local/bin/.
sudo chmod ugo+x /usr/local/bin/ -t now if0 | tee -a dhcp6c_known_duid.txt

In the above, customize the interface name on the last line. Note that some operating systems may use a different directory structure: the only thing special about the /usr/local/bin/ directory (shown in the above example) is that it was a directory in the path.

If the output is...

/usr/local/bin/ cannot decipher 'ifconfig' output

... then help it out. Find the link-local address, and then provide it with the appropriate parameter. -t now -m 01:23:45:67:89:ab | tee -a dhcp6c_known_duid.txt

This should create a file in the local directory.

successfully created /home/somename/dhcp6c_duid
successfully created 00:01:00:01:16:fe:dc:ba:98:76:54:68:ac:e2

If the created file looks good, then place it in the central location (overwriting any file that may have previously been there).

if destination file exists, back it up Also back up the new files. (cpytobak may be used.)

sudo cp ~/dhcp6c_duid /var/db/.
cat ~/dhcp6c_known_duid.txt
Create a configuration file

The filename may be customized. The client may check for /etc/dhcp6c.conf by default, although this may be customized. (Some later documentation may use an example filename that is named after an individual NIC, e.g. /etc/dhc6cif0.conf if the NIC's name is if0.)

Some possible resources: the man page (run “ man dhcp6c.conf ”) and/or the sample configuration file (e.g. included at /usr/local/share/examples/wide-dhcpv6/dhcp6c.conf.sample on a system with OpenBSD's package installed).

Here is an example file.

interface if0 {
send ia-na 0;
send rapid-commit;
send domain-name-servers;
request domain-name-servers;

id-assoc na {

The part of that example which is the most important to be customizing is the name of the NIC (on the line that starts with the word interface).

Not a lot of information is here, at this time, about creating a more elaborate configuration file. (For now, to understand these lines, check the manual pages that came with the program.)

The phrase “ia” refers to “identity association”, as defined by RFC 3315 (DHCPv6) Page 11 (in section 4: Terminology) and continuing onto the next page of the RFC. Some of the other terms (e.g. IA_NA) may help when creating a configuration file (e.g. describes what WIDE-DHCPv6's id-assoc na may stand for).

Use the configuration file
Getting an IPv6 address

Note: the DHCPv6 client software may need a link-local IPv6 address to already be set. (This can be done with router advertisements.) Presumably the DHCPv6 client software is capable of communicating directly with the server (which is different than IPv4). This shows how to assign an additional address (which will probably(/certainly?) not be link-local).

sudo dhcp6c -c /etc/dhc6cif0.cfg -p /var/run/ if0 2>&1 | tee -a /tmp/dhc6cif0-getip6.log

Note that the configuration file must exist. The above command line has four references to the name of the NIC (using if0 as an example) so be sure to appropriately customize all such references as appropriate.

That will run the software in the background. To see what it is doing (but cause the software to not automatically return a command prompt, until the software is aborted with Ctrl-C), replace the -p with -dDfp so (extra) debugging information gets put into the foreground window. (After the program is sleeping, either check results from antoher terminal, or quit the program.) To make the program just grab some information and exit (and make fewer/no changes), add an i so the command line parameter says -dDfip before the PID's filename.

Getting the IPv6 DNS servers
sudo dhcp6c -c /etc/dhc6cif0.cfg -ip /var/run/ if0 2>&1 | tee -a /tmp/dhc6cif0-getip6.log
echo $( cut -d " " -f 2 /tmp/dhc6cif0-getip6.log )
Using the IPv6 DNS servers

The client configuration file may support a line such as:

script "/somepath"

From various documentation on the Internet, it looks like the Ubuntu package of WIDE-DHCPv6 may include a script that does this. The package that comes with OpenBSD does not seem to support this. (A key trick to creating such a script is to not wastefully put the nameserver into /etc/resolv.conf if the nameserver is already listed in that file.)

(February 2012 update: Upon further research, it appears that OpenBSD -current packages may be using ISC DHCP 4, so further research on this software is being put on hold. Perhaps ISC DHCP 4 will come pre-bundled with some more convenient handling.)

What success should look like

(The following may be some old info from before configuration files were being properly used.)

The beginning may look like:

Mon/DD/YYYY hh:mm:ss: get_duid: extracted an existing DUID from /var/db/dhcp6c_duid: 00:01:00:01:16:fe:dc:ba:98:76:54:68:ac:e2
Mon/DD/YYYY hh:mm:ss: dhcp6_ctl_authinit: failed to open /etc/dhcp6cctlkey: No such file or directory
Mon/DD/YYYY hh:mm:ss: client6_init: failed initialize control message authentication
Mon/DD/YYYY hh:mm:ss: client6_init: skip opening control port
Mon/DD/YYYY hh:mm:ss: dhcp6_reset_timer: reset a timer on if0, state=INIT, timeo=0, retrans=383
Mon/DD/YYYY hh:mm:ss: client6_send: a new XID (48bf26) is generated
Mon/DD/YYYY hh:mm:ss: copy_option: set client ID (len 14)
Mon/DD/YYYY hh:mm:ss: copy_option: set elapsed time (len 2)

Some of those lines that look like they may be error messages are just caused by the program trying to use some features that haven't been set up yet. Such error messages may be harmless for basic initial testing.

Then, if all goes well, the rest might look something like:

Mon/DD/YYYY hh:mm:ss: client6_send: send information request to ff02::1:2%if0
Mon/DD/YYYY hh:mm:ss: dhcp6_reset_timer: reset a timer on if0, state=INFOREQ, timeo=0, retrans=988
Mon/DD/YYYY hh:mm:ss: client6_recv: receive reply from fe80::5054:ff:fe12:501%if0 on if0
Mon/DD/YYYY hh:mm:ss: dhcp6_get_options: get DHCP option client ID, len 14
Mon/DD/YYYY hh:mm:ss:   DUID: 00:01:00:01:16:fe:dc:ba:98:76:54:68:ac:e2
Mon/DD/YYYY hh:mm:ss: dhcp6_get_options: get DHCP option server ID, len 14
Mon/DD/YYYY hh:mm:ss:   DUID: 00:01:00:01:16:24:68:ac:e0:12:34:56:78:9a
Mon/DD/YYYY hh:mm:ss: dhcp6_get_options: get DHCP option DNS, len 16
Mon/DD/YYYY hh:mm:ss: info_printf: nameserver[0] 2001:db8::35
Mon/DD/YYYY hh:mm:ss: dhcp6_remote_event: removing an event on if0, state=INFOREQ
Mon/DD/YYYY hh:mm:ss: client6_recvreply: got an expected reply, sleeping.
Mon/DD/YYYY hh:mm:ss: check_exit: exiting
nameserver[0] 2001:db8::35


The following has been witnessed, after copy_option lines:

Mon/DD/YYYY hh:mm:ss: client6_send: transmit failed: Can't assign requested address

The program would then show a dhcp6_reset_timer line (using retrans=988), and then it would show the two copy_option lines again. It would then repeat those four lines for a long time. (Too long for the person witnessing it; perhaps infinitely.)

It was found that the NIC did not have an IPv6 address: not even a link-local address within fe80::/16. Setting that address then caused DHCP to work (assigning a previously reserved address, as was intended).

If the results look good, drop the “dDfi” from that example (and either don't redirect the output, or put the resulting file in a more secure location for long term use).

Microsoft Windows
Finding a DHCP UID

To find a DHCP UID, run:

IPConfig /ALL

With Windows Vista, some of the output may look like:

   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-23-45-67-ab-cd-ef-01-23-45-67
Getting a new IPv6 address

To obtain an new IPv6 address, try:

IPConfig /Renew6 "Local Area Connection"

For DNS, TechNet article: Using Windows Tools to Obtain IPv6 Configuration Info points to using a manually-defined server, or using the FEC0:0:0:ffff::/126: “Well-known” (site-local) DNS servers. It is interesting that the document does not mention supporting configuration from DHCPv6. Perhaps that is not currently supported?

Setting DNS settings

To manually add the information about which DNS servers to use, consider doing something like:

netsh interface ipv6 add dns "Local Area Connection" 2001:4860:4860::8888
netsh interface ipv6 add dns "Local Area Connection" 2001:4860:4860::8844
More info

MS KB 961433: How to configure a Windows (Vista) client to obtain an IPv6 DHCP address indicates that Router Discovery needs to be disabled, and that it is enabled by default.

The first step recommended by that KB article is to open an “elevated command prompt”. Basically, that just means running a command prompt with UAC recognizing that this is being run in Administrator mode. If UAC is actually disabled, then any command prompt may be considered “elevated” (as far as these specific directions are concerned). Further details on handling this are in the section about UAC.

The next step is basically to identify available NICs.

Once the index (or, presumably, the name) is identified, a syntax like this was proivded by the KB article:

netsh int ipv6 set int [index] routerdiscovery=disabled

Presumably (but untested), this could be made a bit more generic:

netsh int ipv6 set int interfaceNameOrIndex routerdiscovery=disabled
Enabling DHCPv6

Once Router Discovery is disabled, DHCPv6 can be enabled by enabling either “Managed Address Configuration” or “Other Stateful Configuration”. Basically, “Managed” will set the IPv6 address (while “Other” may just set other information, like DNS servers or routing details). The details are discussed at NDP M and O configuring flags.

“Managed Address”

The KB article seems to recommend removing any pre-existing static IPv6 address. (Details on how to delete the address will be provided after the command to enable the Managed Address.)

netsh int ipv6 set int interfaceNameOrIndex managedaddress=enabled

What the article does not do is give a clear pointer (near those instructions) on how to locate that address. See: finding address(es) used by a NIC for details on how to do that.

netsh int ipv6 delete address interfaceNameOrIndex 2001:db8::abcd
ipconfig /renew6 interfaceNameOrIndex
Other Stateful
netsh int ipv6 set int interfaceNameOrIndex managedaddress=enabled
ipconfig /renew6 interfaceNameOrIndex
netsh int ipv6 add address interfaceNameOrIndex 2001:db8::abcd

Regardless of whether Managed or Other flag is being utilized, the following should show some information:

netsh int ipv6 show int interfaceNameOrIndex

Look for the line labeled “Router Discovery” followed by the line that says “Managed Address Configuration” followed by the line that says Other Stateful Configuration”. Each of those should say “enabled” or “disabled”.

Also, check the section about finding address(es) used by a NIC (to verify that interface has desired address(es)).