How to Use the IPv6 DHCP Relay
If you have more than a handful of devices that need IP addresses in a hurry — and you don't use Dynamic Host Configuration Protocol (DHCP) — you're wasting time. DHCP is the only way to make sure you don't waste hours and risk huge errors by configuring every single device on your network.
But what about when you scale upward and have a handful of subnets that need IP addresses for all of their devices? In IPv6, DHCP makes that possible with DHCP Relay, and in this post, we'll show you how easy it is to configure DHCP Relay in IPv6.
What is Dynamic Host Configuration Protocol (DHCP)?
Quick Definition: DHCP is a protocol used in network management that's for managing a network's IP addresses and other TCP/IP settings from one central location. Rather than do all the IP address configuration by hand at each device, with DHCP it's possible to administer settings like DNS, default gateways, and IP addresses across an entire network.
What is a DHCP Server?
Quick Definition: A DHCP server is a necessary component to implementing DHCP across a network. A DHCP server is the central location that controls the dynamic addresses and configurations on a network. DHCP clients (devices on a network) make requests to the DHCP server and receive IP addresses, default gateways and other network parameters automatically from the DHCP server.
What is a DHCP Relay?
Quick Definition: A DHCP relay, or DHCP relay agent, is a device on a network that forwards DHCP-related communications to and from DHCP clients and DHCP servers. DHCP relays are necessary on larger networks with multiple subnets because of the nature of DHCP requests. DHCP relay agents pass along DHCP packets between clients and servers to expand the size and scale of a DHCP-enabled network.
When Would You Need a IPv6 DHCP Relay?
A DHCP relay can help you communicate DHCP requests and responses between clients and servers when they're not on the same physical subnet. A DHCP relay in IPv6 is fast and easy to configure. To understand this, let's take a look at just what a DHCP Relay looks like in IPv6. We'll spend some time identifying why we need them and how they work. Last, we'll actually take a look at just how easy it is to configure a DHCP relay in IPv6 and verify that it's working.
So here's our scenario: let's say that we have 100 subnets. We won't imagine that entire network, but to start, imagine a subnet that we'll call #1. It's at 2001:db8:1::/64 behind router R1. Our DNS Server is on subnet #2 at 2001:db8:2::/64 behind router R2. Both R1 and R2's G1/0 interfaces are connected via 2001:db8:12::/64.
These are a small number of our 100 subnets, but we want to use DHCP functionality on all of them. How are we going to apply DHCP functionality to all of those subnets?
One option is kind of painful. You can make every router that's supporting those subnets a DHCP server. But if you've got 100 subnets and maybe 20 or 30 routers, you don't really want to configure DHCP services on 20 to 30 routers. It's not very manageable. It doesn't scale very well.
To fix that, what we might do is consolidate and just use one DHCP server and set up relays to it from each subnet. We say only one DHCP server – and that's effectively how many we'd need. But in a production environment, you'd more than likely want to have several of them for fault-tolerance purposes.
An Overview of IPv6 DHCP Relay [Video]
In this video, Keith Barker covers why you need IPv6 DHCP relays when clients aren't on the same Layer 2 domains as a DHCP server. This comprehensive overview will explain what this function does, how it works, how to configure it, and wraps up with an overview of verification steps.
What Does A DHCP Relay Do?
Once we've got a single DHCP server set up, we can turn to each router supporting a subnet and tell it that it's now responsible for listening for a very particular sort of packet. On top of everything else that a router does in supporting a subnet, it can also keep an ear open for any of its clients making a DHCP request. If it sees a DHCP request, we tell it to wrap the request up and send it via unicast over to the DHCP server.
By doing that, our Host Subnet (#1) and our DNS Server subnet (#2), and all the other 98 subnets, can be supported by one, or a handful, if need be, DHCP server. Doing that means that we have the scopes or appropriate pools for the various subnets all defined on our DHCP server.
This is a win-win for a network administrator, because the routers are already supporting the subnets, and now they're acting as a proxy between the DHCP client and a centralized DHCP server. DHCP Relay is the magic that allows our R1 G2/0 interface — who's looking at Subnet 1 — to pay attention to those DHCP requests and forward them over to the DHCP server.
Why is DHCP Relay Even Necessary?
The reason why DHCP relay is necessary is that by default, clients are making link-local in scope FF02-based multicast requests for 1:2 (more specifically, FF02::1:2). Link-local multicasts like these simply can't make it off the network segment in question. If we didn't have the DHCP relay, the client would never get a response to their DHCP requests because the DHCP server would never even receive them.
But with the DHCP relay set up as we described, R1 takes those requests and forwards them to the DHCP server.
Is it Difficult to Configure DHCP Relays?
DHCP relay configuration is easy. The process for configuring DHCP relays on a router essentially comes down to entering interface configuration mode for the interface in question and instructing it, "You're now a DHCP relay agent. Oh, and here's the address for the DHCP server you're forwarding to." That's really almost all there is to it.
One other thing you might do while you're in interface configuration mode has to do with managed configuration bits and router advertisements (RA). While you're in interface configuration mode, you can instruct the router to set the m-bit (the managed configuration bit) to "On" when sending out router advertisements. This is a way of telling any hosts who are paying attention for that bit to know that they should go ahead and use a DHCP server.
This second part is a somewhat optional step because if you have statically configured clients who are being instructed to use DHCP no matter what, it doesn't particularly matter what the m-bit says on a router advertisement. Nevertheless, if you're planning to practice this setup in a lab or on a live network, knowing how to configure the m-bit is important, so we'll also walk through setting up the m-bit on RAs.
How Do You Configure DHCP Relays?
We're going to go through the actual steps for setting up and configuring DHCP relay. We're assuming you already have a practice environment or a simulated network to configure. We'll walk you through the specific commands to use.
Remember that we're assuming our network as a Host subnet (#1) behind R1. We're also assuming that the DHCP server is already up and running and that its pools are already defined. For this post, all we need to do is set up the DHCP relay agent on a subnet's router.
Pull up the console for your R1 equivalent and enter configuration mode by typing:
Before we do anything, we're going to do some verification. That way we'll know what's changed. To start, we'll show the details for interface gig 2/0:
do show ipv6 int g 2/0
That's the interface where the DHCP client is sitting. On that interface, let's go ahead and enable DHCP relay:
ipv6 dhcp relay destination 2001:db8:12::2 g1/0
This command essentially translates to "enable DHCP with the IPv6 address destination of the DHCP server.
You may have noticed a small addition at the end of that last command: "g1/0". We added that to demonstrate another aspect of this DHCP relay process. "g1/0" is the egress interface, or the source IP address of what we're using when we forward that DHCP request to the DHCP server. It should be noted that if you're using the global address, you don't have to put the egress interface there.
That said, if you use a link-local address like FE80::2. In other words, if you're right next door to that DHCP server then you actually do need to specify the egress interface. That's because with link-local addresses, you need to tell it which interface to source from. It could have several different networks to choose from.
The bottom line is simply that while you're in the interface configuration mode, this line of code is how you enable DHCP relay functionality:
ipv6 dhcp relay destination 2001:db8:12::2
Now that we've set it up, we'll take a moment and look earlier in our config. After we looked at gig 2/0's details, we were given a table of group addresses it had joined. It joined FF02::1, which is all hosts. FF02::2 is the IPv6 unicast routers. And FF02::1:FF00:1 is a solicited node multicast group.
But once we've issued the above command, R1 has also now joined a DHCP multicast group. We can inspect the changes by comparing our above details of gig 2/0 to a new table of details:
do show ipv6 int g 2/0
If your details looked like ours, you would see that there's a solicited node multicast group now present: FF02::1:2. R1 is in that group because it's now important for it to be listening and paying attention there. Anything coming in there will be from clients looking for a DHCP server.
Like we mentioned above, while we're in that config mode, we can also specify that for router advertisements, we want this router to put the m-bit (for managed configuration) set to "1".
ipv6 nd managed-config-flag
With that line of code, we've instructed the router to, when speaking with clients, prompt them about DHCP. Clients who pay attention to that will automatically register their need and make a DHCP request.
After that, you can type:
How to Verify Your DHCP Relay Configuration
Verifying that you've configured a DHCP relay correctly is as easy as going to a client that's trying to gain internet access. In our case, we went and got a Windows 8 machine running. To start the verification, we'll have that client's interface disabled.
What you'll need to do is set up a packet capture between R1 and R2. For our example, we simply configured R2 as a DHCP server and have R1 doing DHCP relay over to R2.
In that packet capture, we shouldn't see anything more exciting than some router advertisements coming in periodically. It's best if you can see the client's network connections and the packet capture simultaneously because once the client interface gets brought online, you should see DHCP relay activity between R1 and R2.
Enabling the interface is easy: navigate to Windows Network Connections, right-click the disabled interface and enable it. After doing so, watch the packet capture between R1 and R2.
The addressing on the packet you're looking for will show that it was sent from R1's address to R2's address. Inside the very first packet of the DHCP relay is a Solicit message.
If you're not familiar with the DHCPv6 Solicit message, it's more or less the DHCP version of the IPv4 DISCOVER. It's specifying the link address. Translated into English, it basically says, "Hello, I heard this request for a DHCP server on my interface 2001:db8:1::1."
And with that, we can see the DHCP server leap into action. Based on this solicit message, the DHCP server knows from which pool of addresses it should give the requester an advertisement. If you're more familiar with IPv4, you may recognize this as an OFFER.
Inspecting the second packet shows that offer coming back, called an Advertise message in IPv6. If you navigate into the DHCP portion of the packet, you'll see that it specifies the address the DCHP server is offering. A DNS server with a given address is also offered for name resolution.
The third packet is a request from the client saying that it'll take the offered address. And the fourth and final packet is a reply to that which is similar to an ACKNOWLEDGEMENT in IPv4 — it's a final receipt of the interaction.
That's how you can see that the process worked as it was supposed to. On top of that, you can type:
Doing so should show you that IP address as one of the IPv6 addresses that this Windows box is using. From there, if you were to do a ping, you'd get a successful ping — assuming that the DNS name you used was in the DNS server and you had connectivity to that resolved IP address.
DHCP in IPv6 is a powerful way to get tons of devices across lots of subnets onto your network with IP addresses without manually configuring each piece of machinery along the way. Plan ahead, and you could minimize not just the work you need to do on each box, but the number of DHCP servers you need to maintain overall. At the heart of it all is DHCP relays, which IPv6 makes simple and easy to configure and verify.
This is only the tip of the iceberg of everything that's possible with IPv6. If you enjoyed this post, you'll love mastering Border Gateway Protocol (BGP), Intermediate System to Intermediate System (IS-IS), and Hot Standby Router Protocol (HSRP).