What is IPv6 PreFix Delegation?
If you've ever wondered how service providers do the amazing thing they do, you should learn about Prefix Delegation. Internet service providers operate by taking blocks of addresses and handing them out to customers. Some customers only need one address, but some of the most challenging customers need entire networks.
When service providers need to parcel out networks that can support subnets, one of the ways to go about doing it is with a fancy thing called IPv6 Prefix Delegation.
What is IPv6 Prefix Delegation?
Quick Definition: Prefix delegation, also known as PD, is one of the methods available in IPv6 for communicating information to a device about what networks are available for subnetting. Service providers can assign customers a prefix to be used on their own internal networks. Prefix delegation is the method by which those customers understand what networks they have available.
An Overview of IPv6 Prefix Delegation [VIDEO]
In this video, Keith Barker covers why IPv6 Prefix Delegation is useful. In addition to assigning individual IP addresses, ISPs can assign entire networks to customers. Keith walks through all of the steps to configure it effectively, as well as verify that it's working correctly.
Why is Prefix Delegation Important?
Prefix delegation is important because it's one of the ways that internet service providers can provide enterprise customers with networks of their own. In turn, that allows for individual users to have uninterrupted access to the Internet and their network services.
If you think about it, service providers do something pretty incredible for a living: they provide service. Internet service providers even more so. For just a moment, put yourself in the position of an internet service provider.
Say you've been assigned a block of addresses: 2001:db8:2::/48. You know that you can take from that blockspace a number of addresses for your customers to use. And not only can you hand out individual IP addresses, but you could even hand out entire networks to your customers.
To start, imagine you have a customer that needs 100 subnets. One solution that prefix delegation allows for is to just hand over a network to them and tell them "Here's a block of addresses, you carve them up however you want them."
Normally with IPv6, there's going to be a 64-bit prefix and a 64-bit interface ID or Host ID. So to hand a network to your client, you'd give them a 56-bit network and allow them 8 bits to decide what to do with — up to the 64-bit boundary.
So, after planning on what IP addresses we're going to hand out, Prefix Delegation is one of the methods, but not the only one, of actually delivering the information about what networks that customer can actually use.
What Happens During Prefix Delegation?
Prefix Delegation sometimes feels like magic, but the process of it goes something like this: we make the customer's router (the same router that is the customer edge to our own provider edge) a DHCP client. But that's not so that he can provide IP addresses for himself. That edge router will make a prefix delegation request.
When that request hits our provider's edge, that router assuming we've configured it correctly will reply with the network we've set aside for the customer. Our provider hands over information about the prefix they'll have, and then the customer router can take that prefix that he's been delegated and use it on his internal networks. With Prefix Delegation, we could even do further delegation inward on a larger network.
How is Prefix Delegation Configured?
To run through the process of Prefix Delegation, let's imagine a hypothetical example. If you have access to a virtualized network, we strongly recommend that you practice IPv6 Prefix Delegation, and these commands should help you understand what's being done to each device on our virtual network.
We'll start by assuming that the customer edge is a router called R10. We're assuming that R10 wants to receive one network: a /56, and then take it and divide it among two or more internal interfaces.
When that's what a customer needs, Prefix Delegation is one great solution. What we'll end up doing is quite simple. First, we have to train our own DHCP server, in this case a Prefix Delegation DHCP Server, on what addresses it should hand out. We also need to train R10 to ask for an address, then use the address it receives on its internal interfaces.
To make that work, we'll have to identify the pools of addresses that we want to use. Then, we'll need to configure those pools as a part of a DHCP plan to allocate those to our customer. At the customer's site, they'll have to tell the internal interfaces to go ahead and use the address that was received. For our example, we'll be doing all that ourselves.
How to Configure IPv6 Prefix Delegation on a Service Provider Server
To start, we're going to refer to our, internal, DHCP server as R4. On the interface which goes off to the customer edge, there is not much configuration that will be needed. We'll still do a couple of things. First, we create a local pool that identifies the range of addresses that we want to hand out:
ipv6 local pool cust-pool1 2001:db8:2:8000::/49 56 ipv6 dhcp pool ISP-Pool
Basically, this is saying that from the /49, I want to hand out 56-bit network spaces out to clients. Pay careful attention to that tag in the second line; we're going to call on that pool in just a moment.
Then, we need to create a DHCP pool. With this, we're essentially instructing our DHCP server that, "Do prefix delegation referring to the local pool, and lease this out forever."
$gation pool cust-pool1 lifetime infinite infinite end
Next, we head into interface configuration mode for gig2/0
conf t int g2/0
While it's optional, at this point you may want to assign a MAC address here. Some people like to do this for packet captures. This makes verifying who a device is a lot easier later on:
mac address 0000.4444.4444
Here we'll also specify an IPv6 global address:
ipv6 address 2001:2b8:2:410::4/64
Although a link-local address will get configured automatically, if you don't like the EUI64 configuration, you can hardcode one yourself:
ipv6 address fe80::4 link-local
Those are the optional parts, but what's next is not. We need to instruct this interface that it should pay attention to DHCP requests and link those requests to the pool that we just created:
ipv6 dhcp server ISP-Pool
We should also bring up the interface itself with a series of commands:
no shutdown exit do show ipv6 local pool
This will output a small table. What it says is that we have 128 networks available from the /49 prefix. We should take a moment and think about how that worked out.
We're seeing this because of one of our inputs from earlier. The device knows that we have 2001:db8:2:8000/49, and we'll be handing out 56-bit networks. Doing the math shows that there are 7 extra bits for the client to play with. And 2 to the power of 7: 128 possible networks.
This table will also show that currently, we have no DHCP clients that have asked for prefix delegation. But we're going to change that by going to R10 and telling R10 to be a DHCP client asking for prefix delegation services.
How to Configure IPv6 Prefix Delegation From the Client's End
On the client, R10, that's acting as a DHCP client for prefix delegation, we start by going into configuration mode:
In our case, interface gig 1/0 is the interface facing our service provider. We need to access it:
Enable IPv6 on it:
Specify that the interface will be getting an IP address to autoconfig:
ipv6 address autoconfig default
And the most important part for Prefix Delegation: be sure to instruct the device that it will be a client for Prefix Delegation:
ipv6 dhcp client pd FROM-ISP
Now, note that label. Our example, "FROM-ISP" is made up. This label will be on the local router itself. It doesn't have any significance other than what's inside the mind of R10. So, any networks we do receive through Prefix Delegation, we're going to associate with this local label of "FROM-ISP".
If you have been following along on a virtualized network of your own, you might be wondering right now if all this work should be resulting in output on your screen. No, no news is good news at this point. But how do you verify that you even got a prefix from the router (R4) who's acting as a DHCP Delegation Prefix server? One easy way to verify is to use the "show IPv6 DHCP interface command":
do show ipv6 dhcp interface
This command outputs prefixes that have been currently assigned to us. In that output you should see a familiar prefix: 2001:DB8:2:8000::/56. What we learn from this is we can use that /56 and further subdivide it and use it deeper inside our own network.
How to Configure IPv6 Delegated Prefixes On Other Inside Interfaces
The next question is how to take the prefix we've learned and associate it with other inside interfaces. To uncover that simple answer, we head to the other interfaces, for instance, gig 2/0:
First, we need to enable ipv6 on that inside interface:
After that, we tell that inside interface what label we want it to use. Because we know what prefix we want to use and what label is associated with it, we instruct it to use "FROM-ISP". Remember that this label means our /56 prefix from earlier.
ipv6 address FROM-ISP ::0:0:0:0:1/64
To understand why this is what we assign, let's remember some details about addressing. In the step above, we told our interface to use FROM-ISP, but that wasn't a complete address. We went on to tell it that from where it stopped, go ahead and use the remaining digits available.
In binary, the "0:0:0:1" is 64 bits. But the "0" that precedes it in our assignment is really 16 bits (8 of those 16 bits are being used to fill in the gaps). So, in assigning this, what we're actually dealing with is 56 bits from the prefix we got delegated to us, and the next 8 bits are represented by the first "0" in the address, and that brings us up to 64.
That can be confusing, so we can take a moment to verify that we actually have a working IP address on that interface:
do show ipv6 interface brief
Remembering that we're on gig 2/0, we can look at the output to find where that interface is now assigned. In our case, our 64-bit network is 2001:DB8:2:8000. The Host ID is a whole bunch of 0s and a 1. Remember: because we have those 8 bits to play with, the last 8 bits of the prefix, we could actually create 255 more possible subnets out of it. This could be the first of many.
To see that, let's imagine doing one more with interface gig 3/0. We'll go on a short road trip over to gig 3/0 and on that interface, we'll say we want IPv6 enabled:
int g3/0 ipv6 enable
Then the key part: we're going to use that same tag ("FROM-ISP") for the delegated prefixes. Except this time, we're going to put a 1 at the front:
ipv6 address FROM-ISP ::1:0:0:0:1/64
This means that the last 8 bits we're filling out are going to be 0000 0001 — because that's what the leading 1 represents on ::1:0:0:0:1.
If you've been able to follow along, you now have two inside interfaces. One is a subnet of 8000, one is a subnet of 8001. And the particularly cool thing is that when the service provider assigned the /56, he put it on a static route.
To see that, you can go all the way back to your virtualized service provider (R4) and show IPv6 routes:
If your internal static route reflects ours, what it translates to is that our edge router is ready to send anyone looking for the block of addresses 2001:DB8:2:8000/56, which includes all the new subnets that customer R10 is going to create under that space through gig 2/0, which goes in the direction of R10.
Believe it or not, Prefix Delegation is actually a relatively easy concept to wrap your head around and it's entirely possible to learn how to configure it quickly and easily. If you're looking for help with topics like this one, consider our TCP/IP IPv6 course. The 54 videos and 24 hours of training will take your network administration skills to the next level — and have you configuring Prefix Delegation on your own.
delivered to your inbox.