DHCP in IPv6

Update 2015-04-03: I rewrote major parts of this post and published it as version 2 here.

I’m currently in the process of studying for CCNP:SP Adv. Route and this post will attempt to cover the following topic on the exam blueprint:

3.1   Describe DNS and DHCP operation in IPv6

1. Introduction

To understand DHCPv6 we first need to understand that IPv6 has significant differences from IPv4 in how it handles assigning an address to an interface. As you probably know, IPv4 supports manual configuration and addressing via (stateful) DHCP. IPv6 keeps these methods but adds two additional ones in the form of stateless autoconfiguration and stateless DHCP. That brings us to a total of four distinct methods of assigning addresses (and additional information such as DNS servers) to hosts:

• Stateless Address Autoconfiguration (SLAAC)
• Stateful DHCPv6
• Stateless DHCPv6
• Manual configuration

These methods rely on a set of ICMPv6 messages that will be covered in the next section.

2. Neighbor Discovery Protocol

Neighbor Discovery Protocol (NDP) is an umbrella term for a series of link local functions performed by five different ICMP messages. These messages do a number of things such as:

• Automatically assign addresses to interfaces without using DHCP.
• Verify that assigned addresses are unique on the link.
• Map between IP and MAC addresses.
• Inform that a DHCP server should be used instead of autoconfiguration.

The five messages performing these functions are:

• Router Advertisement (RA)
• Router Solicitation (RS)
• Neighbor Advertisement (NA)
• Neighbor Solicitation (NS)
• Redirect

The RA and RS are the most relevant ones to the discussion about DHCPv6 so for the sake of brevity, there will be no further mention of the NA and NS, or redirects.

3. Router Advertisement and Router Solicitation

These two messages are sent between routers and hosts. The RS is the simpler of the two and is sent by a host when one of its interfaces wakes up and it wants to acquire an IP address (and other information contained in the RA). The source address of the RS is typically a link local address belonging to the host and the destination is the “all routers” multicast address FF02::2. The RS also contains the sender’s MAC address.

The RA is sent by routers to the all nodes multicast address FF02::1, either when triggered by receiving an RS, or periodically based on a configurable timer. The RA’s purpose is to provide a host with information such as what global unicast prefix is used on the link, what default gateway to use and whether SLAAC or DHCPv6 should be used by the host. The RA also contains information about how long an autoconfigured address is valid.

4. The Router Advertisement “M” and “O” flags 

The RA contains two 1 bit fields called M (managed) and O (other) that are used to inform a host of what method should be used for address assignment. The default in Cisco IOS is that both of these bits are zero which means that a host shouldn’t assume that a DHCPv6 server is available. If the M flag is 1 however, addressing information could be received from a DHCP server instead of through autoconfiguration, and the host should initiate that process. The O flag  can be used when the M flag is zero to give a host that uses autoconfiguration additional (“other”) information such as DNS servers via DHCP. In other words, we have two different styles of DHCPv6:

• Stateful DHCPv6 – M flag is 1 -> use DHCP for all information.
• Stateless DHCPv6 – M flag is 0, but O flag is 1 -> use SLAAC for addresses, but get additional information from DHCP.

(The book I’m using as the main source for this post, IPv6 Fundamentals, doesn’t mention what purpose the O flag serves when the M flag is 1. The book implies that if the M flag is 1, it doesn’t matter what the O flag is because the host should get all of its information from DHCP anyway due to M flag = 1. Additional research tells me that it’s not that simple. It feasible that the client could decide to not ask for the “other” information if M flag = 1 and O flag = 0. Therefore, it seems safer to set M flag = 1 and O flag = 1 if you want a host to get all information from DHCP. I’ve seen conflicting information on this on the Internet and it warrants additional reading.)

5. RA Flags and Misbehaving Clients

Once the host has determined that it should use DHCP instead of SLAAC, an exchange of DHCP messages should start. Note however that this is dependent on the host’s behavior. Technically, the host could ignore the flags in the RA and simply use SLAAC to configure itself using the parameters found in the received RA. What does this mean? It means that if your reason for using stateful DHCPv6 is to keep track of clients, a host could potentially just use SLAAC anyway and go into “stealth” mode.

I’m not a big Linux guy, but I did some basic tests with a fresh Debian install and in its default state, that box didn’t even seem to have a DHCPv6 client running with the result that it used SLAAC regardless of what the RAs said. Installing a DHCPv6 client resulted in SLAAC being used for the IP address while DHCP was used for DNS (stateless DHCPv6). Presumably, the client can be configured for stateful DHCP, but the point is that you can’t expect all clients to go stateful just because the M-flag is set.

Is there a solution to this problem? Yes, and no. The RA has a Prefix Information option that contains the “A flag” (autonomous address-configuration flag). This flag is what determines if the host is allowed to use SLAAC, not the M-flag itself. The M-flag is only signaling that the host could use DHCP. In other words, if SLAAC shouldn’t be allowed, the A flag should be cleared. However, in my test on Debian, clearing the A-flag resulted in the client interface not getting any addressing at all; the lack of the A flag caused this particular client (I used wide-dhcpv6-client) to not do SLAAC, but it didn’t do stateful DHCP either with its default configuration. This lets us draw the important conclusion that if you haven’t verified that all of your clients support stateful DHCPv6, disabling the A flag is a very bad idea. Additionally, it’s an issue that seems somewhat difficult to troubleshoot unless you know what you are looking for.

(You remove the A flag with router(config-if)#ipv6 nd prefix default valid-lifetime preferred-lifetime no-autoconfig)

Let’s say that you remove the A-flag and expect that no client will use SLAAC. However, technically, this still doesn’t prevent a host from using SLAAC – removing the A flag only says that hosts shouldn’t use SLAAC; you are still sending RAs that could be interpreted by the client however it wishes. Additionally, you need to send RAs because that’s where hosts get their default gateway, not from DHCPv6. If stateful DHCP is very important to you, you may now go looking for other ways to prevent SLAAC from happening.

A plausible way to solve the problem would be to remove prefix information from the RA and only use it to receive the default gateway. Is this possible? Yes, Cisco IOS has commands that lets you do this. The idea would be to hide the prefix from the RA and then only use prefix information from the DHCP. If the RA doesn’t contain the prefix, the client can’t do SLAAC, right? Should you do this? I don’t know.

6. The DHCPv6 Exchange

Let’s now move on and assume that the host has agreed to use DHCP. Just like with DHCP for IPv4, a series of messages are sent back and forth between the client and the server with the goal being to agree on what address the client should use. There are 13 messages in total, but only four of these are involved in the initial exchange. UDP port 546 and 547 are used to transport the messages. This process is used for stateful DHCPv6:

1. Solicit. This message is sent by the clients to the “all DHCP servers and relays on the link” address at FF02::1:2 in order to find a DHCPv6 server.
2. Advertise. The server has received the solicit message and is now making itself known to the client.
3. Request. The client is requesting an address from one of the servers that has sent it an advertise message. If multiple advertisements are received, one of them is picked according to a formula found in some RFC somewhere.
4. Reply. The server responds to the request with a reply that assigns an address and other information.

If stateless DHCPv6 is used, the request message is replaced with one called information-request.

In addition to these four main messages, there are a whole slew of messages involved in the maintenance of assigned addresses, like renew and release messages.

7. Rapid Commit

Instead of using the normal four message exchange it’s possible to reduce it to just solicit and reply. This functionality needs to be supported by both the client and the server and is initiated by the client setting the rapid commit option in the solicit message. Upon receiving this rapid commit solicitation, the server immediately sends a reply (also with the rapid commit option set) with an address. One problem with this brought up in IPv6 Fundamentals is that by removing the request part of the exchange, several servers might respond with rapid commit replies with addresses as a response to the solicit. The servers cannot know which of these addresses are actually picked by the client and must potentially maintain state for addresses that aren’t used.

8. Relay Agent

By default, DHCPv6 is constrained to the local link due to the solicit messages being sent to a multicast address with link local scope (FF02::1:2). This is similar to how DHCP in IPv4 cannot get off the local network due to the reliance on broadcasting. In an environment with a centralized DHCP service, we must configure a DHCPv6 relay agent on each host facing router interface.

The feature operates pretty much exactly like you would expect. The router receives DHCP messages from clients and because it has the relay agent configured, the router knows that the DHCP messages must be sent off link. The messages are encapsulated in a another message called RELAY-FORWARD and are either unicast to a particular DHCP server, or multicast to FF05::1:3 (a site local address used by DHCPv6 servers). This is manually configured.

The server receives the encapsulated messages and uses that information to encapsulate its replies in such a way that they get back to the correct relay agent. The relay agent then decapsulates and sends the messages back to the client.

9. DNS

I’m including DNS in this post since it’s mentioned on the same line as DHCP on the exam blueprint. DNS in IPv6 works pretty much like it does in IPv4. The main difference that the book bring up are that the A record (mapping from a name to an IP address) is now called an AAAA record. The reverse mapping is done in a similar way to IPv4 except that the dots are put between each nibble (4 bits) instead of every byte. Another, fairly obvious, factor to take into consideration is that the DNS servers need to be reachable via IPv6 in order to serve IPv6 only hosts.