DHCPv6 - Dynamic Host Configuration Protocol for IPv6

DHCPv6 was specified in RFC 3315, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", July 2003. This is still current. There have been several updates to this.

Unlike DNS, DHCPv4 could not support IPv6 with just a few minor changes, because DHCPv4 is very dependent on broadcast, which does not exist in IPv6. Also, most IPv6 nodes get their default gateway via SLAAC, so do not need to get it from DHCP. Soon, nodes will also get the IPv6 addresses of DNS via SLAAC (RFC 6106), so there will be even less need for DHCPv6. If you look at the protocols, you can see that DHCPv6 was based on DHCPv4, but using multicast instead of broadcast, and there is no way to configure or provide the default gateway. If DHCPv6 included the ability to provide the default gateway, it would be easier to do configuration without SLAAC.

Like DHCPv4, DHCPv6 is a link-local protocol (broadcast in DHCPv4 does not cross routers and the multicast address used in DHCPv6 is link-local). So, in both cases, each subnet must have either a server or a relay agent to send and receive the link-local connections to and from clients, while using higher scope unicast for the relay agent to communicate with the real server in another subnet.

Since DHCPv6 cannot provide the default gateway or prefix information, it is not possible for an IPv6 node to completely configure its networking using only DHCPv6. You must use SLAAC or manual configuration for these items. If you enable SLAAC the node will also configure one or more global addresses using SLAAC, assuming the Router Advertisement messages contain at least one Prefix Information option. If you manually configure the default gateway your node could obtain a single managed IPv6 global address and the IPv6 addresses of DNS. One option would be to provide a source of Router Advertisements, but to not include any Prefix Information options. That way a node could do Router Discovery, but would not configure any additional global unicast addresses. DHCPv6 was designed as an "addon" mechanism on top of SLAAC.

Normally, an IPv6 compliant node will not attempt to obtain information from DHCPv6 unless it first does SLAAC, and finds that the M and/or O flags are set in the Router Advertisement message. If the M flag is set, it can get stateless information (e.g. addresses of DNS) AND a global unicast address. If the M flag is clear, but the O flag is set, it can only get the stateless information. Windows 7 has an option to tell a node to use DHCPv6,

In Windows 7, you can enable or disable Router Discovery on a node (whether or not to process Router Advertisement messages), and Managed Addresses (whether or not to obtain addresses of DNS and a global address from DHCPv6):

netsh int ipv6 set int "Local Area Connection" routerdiscovery=enable|disable

If Router Discovery is enabled, the node will process Router Advertisement messages as usual: obtain the default gateway, and if there is at least one prefix information option, configure global addresses based on advertised prefixes.

If Router Discovery is disabled, the node will ignore Router Advertisement messages. It will not obtain the default gateway automatically (you must manually configure one), and it will not generate any global addresses during SLAAC, regardless of whether or not the router is sending Router Advertisement messages with Prefix Information options.

netsh int ipv6 set int "Local Area Connection" managedaddress=enable|disable

This setting has no effect if routerdiscovery is enabled (in that case, it is controlled by the M flag in Router Advertisement messages).

If Managed Address is enabled, the node will obtain stateless information (e.g. DNS address) and stateful information (a managed global unicast IPv6 address) from DHCPv6. It will access DHCPv6 using the "all DHCPv6 servers and relay agents in subnet" multicast address (ff02::1:2).

If Managed Address is disabled, the node will not use DHCPv6.

There is no configuration where the node will obtain the default gateway automatically via Router Discovery, but not also configure one or more global unicast addresses (unless you do not include any Prefix Information options in your Router Advertisement messages).

If there is no source of Router Advertisement messages, you must manually configure at least the default gateway, but you can obtain a managed global unicast address and the IPv6 addresses of DNS servers from DHCPv6 (by disabling Router Discovery, and enabling Managed Address option with netsh).

So, to configure a node using only DHCPv6 (and not obtain any global addresses from SLAAC) you would need to do the following:

  • Deploy a DHCPv6 server (or DHCPv6 relay agent) in the subnet
  • Configure a valid IPv6 address pool on the DHCPv6 server, and IPv6 addresses of DNS
  • Enable Router Discovery on the node (to obtain default gateway automatically)
  • Provide Router Advertisements in the subnet with the M flag set, but without any Prefix Information option (this will affect all nodes in the subnet)

Alternatively, you could do the following (if you want to allow other nodes to configure global unicast addresses with SLAAC, which would require including Prefix Information options in the Router Advertisement messages):

  • Deploy a DHCPv6 server (or DHCPv6 relay agent) in the subnet
  • Configure a valid IPv6 address pool on the DHCPv6 server, and IPv6 addresses of DNS
  • Disable Router Discovery on the node
  • Manually configure the default gateway address on the node (either link-local or global unicast will work, link-local is preferred - never configure both)
  • Enable Managed Address on the node

The GUI tools that come with Windows 7 will not allow you to specify a default gateway without also configuring at least one global IPv6 unicast address. You can specify a default gateway without specifying even a single global unicast address with netsh or NetConf. NetConf also allows you to easily enable or disable Router Discovery and Managed Address options with GUI controls.

In NetConf, go to the IPv6 Settings tab. Set the Router Discovery option to Disabled. Set the Managed Address option to Enabled. Right click in the Gateway Addresses ListView and select Add Address. Enter your subnet default gateway address (ideally link-local, but global unicast will work). You should now have a default gateway, an automatically generated link-local address, a managed global unicast address from DHCPv6 and the IPv6 addresses of DNS from DHCPv6. There should be no SLAAC generated global unicast addresses or manually configured IPv6 global addresses. If there are any manually assigned addresses, you can delete them with NetConf - go to the IPv6 Unicast tab, right click on each manually assigned address found and select Delete Address. If you do this and surf to v6address.com, it will always show you the managed IPv6 address from DHCPv6, because that is the only global unicast IPv6 address on your node.

Note that some simple IPv6 nodes (sensors, consumer electronics devices, etc) may only be able to obtain a global IPv6 address via SLAAC. In this case, providing Router Advertisement messages with no Prefix Information option would prevent these nodes from obtaining IPv6 global addresses (they would still generate link-local addresses). Some functionality may not work without a global IPv6 unicast address.

 

DHCPv6 Options

As with DHCPv4, there are a number of options that you can specify in DHCPv6. These will be sent to the node doing DHCPv6 configuration along with the IP address. These options can be specified at the Server, Scope or Reservation level. There are nowhere as many options as exist for DHCPv4, but perhaps someday more will be added. These options are:

SIP Server Domain Name List
SIP Server IPv6 Address List
DNS Recursive Name Server IPv6 Address List
Domain Search List
NIS IPv6 Address List
NIS+ IPv6 Address List
NIS Domain List
NIS+ Domain Name List
SNTP Servers IPv6 Address List
Information Refresh Time
 

What is a DUID?

DUID stands for "DHCP Unique Identifier". It is used only with DHCPv6. Each client and server that supports DHCPv6 has a DUID. It is basically the Link Layer address of the node, plus some additional stuff. There are several types of DUID, based on what "other stuff" is added. There are three DUID types defined in RFC 3315 (DHCPv6 specification), but others may be defined in the future. The three existing types are:

1 - DUID-LLT - Link Layer address plus timestamp
2 - Vendor assigned unique ID based on Enterprise Number
3 - Link Layer address
 
Type 1 DUIDs (DUID-LLT) contain a 16-bit field with the DUID type (1), a 16 bit hardware type field (1 for Ethernet), a 32 bit timestamp field, and a variable length Link Layer address field (length based on hardware type). All Windows nodes appear to use Type 1 DUIDs. The DUID on my Lawrence-PC node is 00-01-00-01-18-BA-30-56-50-46-5D-6B-7A-54. The last 6 fields are that node's MAC address.
 
The hardware type is one of the codes from RFC 826. Ethernet is type 1.
 
The timestamp is supposed to be the time that the DUID was generated, in seconds since midight UTC, January 1, 2000, modulo 232. In practice, many of the DUIDs I've seen have some unusual values. For example, my ws3 server (WS2008R2) uses the timestamp Jun 30, 2042, 16:44:02. My ws4 server (also WS2008R2) uses the timestamp Jun 10, 2042, 16:00:04. My Lawrence-PC node (Windows 7) uses the timestamp Feb 22, 2013, 21:34:14 (this might have been when I installed the OS, I'm not sure). I'm fairly certain the timestamps on the WS2008R2 boxes are bogus (although its possible they might be valid if you subtract 30 years). Regardless, it appears that no one depends on these timestamps being accurate. This may have been an idea that seemed really good at the time the specification was written, but isn't actually used in practice.
 
Type 2 DUIDs (DUID-EN) have a 32 bit enterprise number (registered with IANA) identifying the enterprise that created the DUID, followed by a variable length identifier issued by the enterprise. I have never seen a Type 2 DUID in practice.
 
Type 3 DUIDs (DUID-LL) contain a 16-bit field with DUID type (3), a 16 bit field with hardware type (Ethernet = 1) and a variable length field containing the device's Link Layer address (the length depends on the hardware type). This type is recommended for devices that have a permanently connected network interface with a Link Layer address, and do not have any nonvolatile writable, stable storage. It must not be used by DHCP clients or servers that cannot tell whether or not a network interface is permanently attached to the device. I have never seen a Type 3 DUID in practice.
 
The client's DUID must be specified for an Address Reservation in DHCPv6.
 
 

What is an IAID?

IAID stands for "Identity Association Identifier". An "identity association" (IA) is a construct through which a server and a client and identify, group and manage a set of related IPv6 addresses. Each IA consists of an IAID and associated configuration information.
 
A client must associate at least one distinct IA with each of its network interface fro which it is to request the assignment of IPv6 addresses from a DHCPv6 server. The client uses the IAs assigned to an interface to obtain configuration information from a server for that interface. Each IA must be associated with exactly one interface.
 
The IAID uniquely identifies the IA and must be chosen to be unique among the IAIDs on the client. The IAID is chosen by the client. For any given use of an IA by the client, the IAID for that IA must be consistent across restarts of the DHCP client. 
 
The IAID uniquely identifies the IA and must be chosen to be unique among the IAIDs on the client. The IAID is chosen by the client. For any given use of an IA by the client, the IAID for that IA MUST be consistent across restarts of the DHCP client.
 
For example, the IAID on my Lawrence-PC node is 218628135.
 
The IAID must be supplied for an Address Reservation in DHCPv6.
 

Address Reservation with DHCPv6

Just like with DHCPv4, you can create an "address reservation" in DHCPv6. It is a bit more difficult in DHCPv6 because you don't link it to a node's MAC address, but to the node's DUID and IAID (see above). The easy way to create an address reservation with the Microsoft DHCPv6 server is to elevate an existing address assignment to a reservation. To elevate an existing address assignment, find the one you want to elevate under Address Leases (in the Microsoft DHCP management tool), right click, and select "Add to Reservation". No additional information is required (the address assignment already contains the DUID and IAID). If you do this, the new reservation should appear under Reservations. In the future, any time that node requests an IPv6 address from DHCPv6, it should get the reserved address.

To create a reservation manually (as opposed to elevating an existing assignment), you will need an unused IPv6 global unicast address and the DUID and IAID of the node you want to make a reservation for. You can find the DUID and IAID values for any Microsoft node with "ipconfig", under DHCPv6 IAID and DHCPv6 Client DUID. These appear in ipconfig only if Managed Address is enabled (either from Router Advertisement M flag, or manual setting of Managed Address option with netsh or NetConf).

Right click on Reservations (under IPv6 / Scope) and select "New Reservation". In the resulting dialog box, enter the nodename after "Reservation", supply the address suffix of the address to be reserved (the prefix is already supplied, based on the scope information); the DUID; and the IAID. All reserved addresses are automatically removed from the available address pool.

 

What is DNS Autoregistration?

DNS can allow other applications to register nodename and address information via "DNS Dynamic Registration". By default, all windows nodes will try to autoregister all of the IPv4 and IPv6 addresses in DNS. By default, Microsoft DNS will allow autoregistering from any node in the subnet. This leads to security issues and a very cluttered DNS. It is best to configure your DNS to reject autoregistration from most nodes.

Since letting just anyone register information automatically in your DNS server is not a good idea, you can restrict what IP addresses your DNS server will accept such registrations from. You may want to restrict this to only those nodes running DHCPv4 and DHCPv6. Most DHCPv6 servers have the ability to register assigned addresses automatically with DNS using this.

Since hackers can spoof addresses, even that may not be sufficient. DNS has a cryptographic authentication mechanism called TSIG that can allows any node doing dynamic registration to do cryptographic authentication before it is allowed to register any information.

For best security, you should both restrict the IP addresses allowed to do dynamic registration (e.g. to only those servers running DHCP) and use TSIG authentication. Configuring TSIG varies quite a bit from one DNS server to another, and from one DHCP server to another, so this is not covered here. Your DNS and DHCP servers should contain information on how to use TSIG.

 

Protocol Capture

There are two DHCPv6 servers in this subnet (both running on Windows Server 2008 R2). Both have the following options:

DNS Recursive Name Servers: 2001:470:3d:3000::13 and 2001:470:3d:3000::12

Domain Search List: hughesnet.local

 

Server ws3.hughesnet.local (at 2001:470:3d:3000::13)

The address pool is:

2001:470:3d:3000::1 to 2001:470:3d:3000:ffff:ffff:ffff:ffff

excluding the ranges:

2001:470:3d:3000:: to 2001:470:3d:3000::3:ffff

2001:470:3d:3000::5:0 to 2001:470:3d:3000:ffff:ffff:ffff:ffff

In other words, the pool is:

2001:470:3d:3000::4:0 to 2001:470:3d:3000::4:ffff

 

Server ws4.hughesnet.local (at 2001:470:3d:3000::14)

The address pool is:

2001:470:3d:3000::1 to 2001:470:3d:3000:ffff:ffff:ffff:ffff

excluding the ranges:

2001:470:3d:3000:: to 2001:470:3d:3000::4:ffff

2001:470:3d:3000::6:0 to 2001:470:3d:3000:ffff:ffff:ffff:ffff

In other words, the pool is:

2001:470:3d:3000::5:0 to 2001:470:3d:3000::5:ffff

 

There are four messages exchanged in each DHCPv6 transaction (Solicit, Advertise, Request and Reply). In this case, there are actually two DHCPv6 Advertise offers (one from the DHCPv6 server on ws3.hughesnet.local and one from the DHCPv6 server on ws4.hughesnet.local), so a total of five packet captures are shown.

The source address for all messages from a client is the client's link local address. The destination address for the messages from a client is ff02::1:2 (all dhcpv6 servers or relay agents in subnet multicast address). The client sends and receives on port 546 (dhcpv6-client).

The source address for messages from a server is one of its IPv6 addresses, usually a global unicast address. The destination address for messages from a server is the link local address from the client's Solicit or Request message. The server sends and receives on port 547 (dhcpv6-server).

The client node requests TCP/IP configuration by sending a DHCPv6 Solicit message (comparable to DHCPv4 Discover message).

dhcpv6 solicit

The DHCPv6 server on ws4.hughesnet.local sends a DHCPv6 Advertise message (comparable to the DHCPv4 Offer message), saying "Would you like address 2001:470:3d:3000::4:57db?"

dhcpv6 advertise1

The DHCPv6 server on ws3.hughesnet.local sends a DHCPv6 Advertise message (comparable to the DHCPv4 Offer message), saying "Would you like address 2001:470:3d:3000::5:3fd2?"

dhcpv6 advertise2

The client accepts the offer for address 2001:470:3d:3000::4:57db, and responds with a DHCPv6 Request message (comparable to the DHCPv4 Request message) saying "OK, I choose the offer from the server with Server Identifier 000100004fd454041c6f65d26f43." This is the DHCPv6 server on ws4.hughesnet.local.

dhcpv6 request

On seeing the DHCPv6 Request message, the DHCPv6 server on ws3.hughesnet.local says "OK, no problem", returns address 2001:470:3d:3000::5:3fd2 to its pool, and goes back to sleep.

The DHCPv6 server on ws4.hughesnet.local reserves address 2001:470:3d:3000::4:57db for this client node, and sends a DHCPv6 Reply message (comparable to DHCP Ack message) with the official TCP/IP configuration information. If you check the DHCPv6 server on ws4.hughesnet.local, it will now show the address 2001:470:3d:3000::4:57db assigned to node Lawrence-PC.hughesnet.local, with an expiration date and time of 8/5/2013, 4:35:18 PM 21, 12 days from this transaction).

dhcpv6 reply

On receiving the DHCPv6 Reply message, the client node actually configures TCP/IP with the configuration information in that message (in this case, two IPv6 addresses of DNS and another global unicast node address).

 

Deploy the ISC DHCPv6 Server in FreeBSD 9.1

You can install and configure the ISC DHCPv6 server in FreeBSD 9.1 by doing this project: Create A Virtual Dual Stack Router using FreeBSD 9.1.