DHCP In IPV6
DHCP is a network admin’s best friend. It’s one of the most useful protocols around, and it’s a major part of IPv6. It’s so major that we have two kinds of DHCP in IPv6 – stateful and stateless. Stateful DHCP works a lot like the DHCP you and I have come to know and love in our IPv4 networks. This should sound familiar:
A host sends a DHCP message (initial DHP message), hoping to hear back from a DHCP server. The server gives the host a little bit of initial information, and after another exchange of packets, the host is good to go with the IP address it accepted from the server. The address is good for the duration of the lease, as defined by the server.
There are four overall messages in the entire DHCP process, two sent by the client and two by the server.
The client also receives the location of DNS servers.
The DHCP server keeps a database of information on clients that accept the IP addresses that it offers.
That all describes DHCPv4 and stateful DHCPv6!
As you’d expect, there are some differences, including the names of three of the DHCP packets.
Another major difference: DHCPv6 does not send default router information to the client as DHCPv4 does. The host gets its default router information via NDP.
Note: When I say Dak DHCPv4 or DHCPv6, that is not referring to the actual version number of DHCP! This is the commonly accepted way to write DHCP for IPv4 and DHCP for IPv6, and on your exam if a DHCP version is not mentioned, they’re talking about DHCP for IPv4.)
While stateful DHCP (also known as stateful autoconfiguration) has a lot in common with DHCPv4, stateless DHCP is a brand-new world. When stateless DHCP is in effect, we have hosts that create their own IP version 6 addresses. This is called SLAAC.
This stateless autoconfiguration (SLAAC) begins with some of the information the host received from the router as a result of the router solicitation(RS) and router acknowledgement(RA) messages (that we looked at earlier) and some of that information in the RA includes the prefix and the prefix length. It’s that information that allows the host to create its own IPv6 address.
The host just needs to add its 64-bit interface identifier onto the back of the 64-bit prefix, and that’s that – the host has 128 bit valid and unique IPv6 address.
Well we think it’s unique. Hmm let’s look a bit again. Valid and unique.
We’re assuming it’s unique but it would be a really good idea to have somebody check and actually dad’s going to check that for us!!
Smart Stuff DAD Says
Before the host starts using the IPv6 address it assigned itself, the host should make sure nobody else is already using that same address. The Duplicate Address Detention (DAD) procedure is a quick verification of this self-assigned IPV6’s address uniqueness. DAD is really just the host trying to talk to itself; should this attempt succeed, we have a problem.
To perform Dad, the host sends a Neighbor Solicitation message to its own address. (The destination of that NS, is the address it just gave itself. It’s trying to talk to itself, and is sending a message destined for the address it wants to use but it’s not in use yet.)
The Source address of this NS is what we call IPV6 unspecified address, represented by a double-colon and nothing else. (Literally it’s 128 zeros)
The host can’t use its self-assigned IPv6 address yet as the source, because Dad hasn’t given the OK for that yet.
So this is where the host is going to start SLAACing.
If the host receives a Neighbor Advertisement in response, that means another host is already using that self-assigned address, so the host running DAD cannot use it.
The destination address for this NA is FF02::1, the all IPv6 nodes address. This multicast response insures the original host sees that the address it wants to use is already in use.
If the Neighbor Solicitation is sent out and nothing is heard back then it’s all good.
DAD doesn’t only run when there’s a self-assigned address. The DAD procedure actually runs when an interface is about to use IPV6 unicast address for the first time, or when an IPV6-enabled interface is brought down and then back up. It’s a handy little verification check (very quick uniqueness check) that can save us big headaches.
The IPV6 Routing Table
(Important for Exam)
We’ll use the following network for all the static and default routing labs that follow. Note that R2’s Fast 0/0 interface address has changed from previous labs.
R2’s address has changed slightly and it’s sharing the 2001:2222:3333:1 subnet with R3’s Fast ethernet 0/0 interface, and R3 & R4 are sharing a subnet (they’re sharing 2001:3333:4444:1 subnet) and you can see that I gave each router a host number(two, three or four) and just left it at that.
So let’s take a look at R2 to begin with and see what we see.
I have enabled version 6 unicast routing on all three routers (IPv6 unicast-routing)
So let’s just see what’s on the routers before we even start configuring any kind of routes.
The only thing I’ve done again is put those IPv6 addresses on, open the interface, and everything’s good.
So let’s take a look at our routing table
and we don’t see anything!! I should at least see a connected router right?
And it’s version 6 so maybe I’ll see more routes, but I definitely shouldn’t be seeing less.
So what’s going on here? The reason I’m not seeing my version 6 routes is that I ran my version 4 command (show IP route). You got to run ‘show ipv6 route’…
Now you might be surprised to see three different entries here (the only thing that we’ve done so far on R2 is configure an IP address off camera, opened it and that was it. So R2 really knows of only one route right now)
Why do we have three entries and what’s the deal with this L entry?
Well let’s go from top to bottom here…
The first line at the end, is going to tell you how many entries you have, and obviously you can count them yourself here but that comes in handy once in a while.
Now as far as the codes go, the only codes we’re looking at right now are C, L and S (very first three) which are “Connected”, “Local” and “Static”.
C is our connected route and we see pretty much what we expect to see. We see the subnet number there, and there’s the mask via Fast Ethernet 0/0 directly connected and it’s all good.
What about these two L’s (these local routes)?
You’ll find a local route in the routing table for each ipv6 address entry on the -wait for it- local router !
This behavior was built into Version 6. But for those of you new to networking I want to tell you they were not built in the IPv4. Basically it’s a host route. It’s a route that points to only one host. And we can identify those in version 6 by that “/128”… As soon as you see that you’re dealing with some kind of host route (a route that only points to one host).
SO again, these host routes match only that one address and will have /128 mask. The local entry for FF00::/8 represents the multicast prefix.
Well what is the host that it’s pointing to here? the local router (2001:2222:3333:1::2)
So by putting IPv6 address command on an interface, and opening it, you’re really creating two entries. You should see it connected for the subnet that that interface is on, and then a local entry which is actually a host route and it’s pointing at the IPv6 address that you configured on that interface.
Now what about the second L? This one is for multicasting purposes. That’s our multicasting prefix FF00::/8 … (we’ll go into a little more detail with that later)
Just for fun, I put an extra IPv6 address on R3 ‘s Fast0/0 interface, Why? Well, first to illustrate that you can do that in the first place! Multiple IPv6 addresses on a single interface are perfectly acceptable.
We should now see four local routers in R3’s routing table… One for each interface address and the expected FF00::/8 entry.
Let’s go over to R3 and have a look around:
You probably noticed global unicast address (es) and joined global address (es) which means I can have more than one, but you may be surprised to learn that a single physical interface can have multiple global unicast addresses and they can be on multiple subnets. (white area)
Note: We’re not using 2001:1111:2222:1::3 in the lab. I strictly did this to show you that you can have more than one unicast address on a given interface.
So let’s check Fast Ethernet 0/1:
Everything looks pretty normal here. We see the unicast address here (red circle). You see that (es) here too, and I wanted to show you that. You can have more than one on a given interface… And I noticed this is /63 at the end of the subnet.
We should probably fix that before we go any further, so we’ll do a fix on that and make that a 64… that’s why you run the show commands.
And let’s go ahead and run our local routes here
Yeah we definitely want to fix that /63 and we’ll just fix it to /64 and you can see that we see four local routes, one for each global unicast address that we configured on an open interface, and then the one from multicasting there at the end. You can already see this gets a little clunky to read, because you got all this stuff squeezed together and your version 6 addresses are longer anyway and they’re not all the same length.
That’s why I strongly suggest you get used to using your filters here with ‘show IPv6 route’ (if you wanted to look strictly at the local routes, just put local on the end)
Notice the number of entries that it refers to… It’s really easy to run ‘show IPv6 route local’ or ‘connected’ or ‘static’ or whatever filter you put on the end… and you’ve got four routes but it says “7 entries” !! Why?
You have seven entries in the IPv6 routing table as a whole… That’s what it’s referring to there. It’s referring to the full number of routes in the full table not the ones that you chose to display ( which in this case is local ones).
So I am going to fix /63 entry and make it /64 in the next chapter…
Leave feedback about this