Now we move on to our DHCPv6 demo.
In this demo,
we're going to examine a DHCPv6 transaction just like we did for DHCPv4.
This will be both a stateless and stateful transaction,
and for the stateful we will show you both with one with
Rapid Commit and one without Rapid Commit.
Of course,
all of these packet captures are available for download if you decide that
you want to play along with your own home copy of the game.
We'll then configure DHCPv6 on a Windows server,
and we will examine the existing configuration on a Cisco router,
and look at the DHCP relay agent on the Cisco router.
The reason I opted to do this rather than configure it from scratch is that
it looks pretty much exactly like a DHCPv4 configuration,
and quite honestly you probably don't want to sit and watch me type all of that
again because I am a notoriously slow typer for some reason.
It kind of bugs me.
I do this all day, every day, and yet I can't type under pressure.
Regardless, let's jump right in to the packet captures.
So we will start off with a stateless DHCPv6 transaction,
and just as we promised it is 2 packets.
There is the Information-request and there is the Reply packet.
You'll notice that as we discussed,
the source of both of the packets are the link-local
addresses for the DHCP server and the client,
and you'll notice that the destination of the information
request is sent to that multicast address,
ff02::1:2.
You'll see that it is indeed a UDP packet on 546 and 547, just as we discussed.
And if we crack open the DHCPv6 portion of the packet,
we can look at the client identifier.
There is the DUID or the DHCP unique identifier.
You'll see that it's a link-layer address,
or a Type 3 DUID, and the hardware type is Ethernet.
So if you notice that the DUID is 0003 for a Type 3 DUID,
0001 for an Ethernet hardware type,
and then there is the actual MAC address for the Ethernet interface.
Going further down,
if we open up the Option Request we see that it's
requesting the DNS recursive name server,
the Domain Search List, and the Lifetime,
and that's all its requesting,
and of course that will be all that it receives back.
And there is the actual text of the DNS Domain Search List, globomantics.
local.
There is the DNS server address up above it,
I probably should have done that to begin with,
but you'll notice that the DNS server address is not the link-local address,
it's the actual global address so that it can be
located elsewhere off this local subnet.
The particular DHCP implementation that I had configured did
not have a lifetime defined on the server,
and so that's why that value was not returned even though it was requested.
And so now we move on to the stateful DHCPv6 non-rapid commit.
This is the one where you get all four of the UDP packets,
and again,
one of the things you'll notice right off the bat is that the
source addresses are all link-local addresses,
and you'll also notice that all the traffic coming from the
client is going to that multicast destination,
that ff02::1:2,
whereas the traffic from the server back to the client is
destined for the client's unicast IPv6 address.
If we crack open the Solicit packet, we see that Rapid Commit is set,
it says Length 0.
The Option Request is DNS recursive name server,
Domain Search List,
and here is the Identity Association for a Non-temporary Address,
meaning the DUID and Ethernet type there that you saw
in the previous packet capture, because again,
it's the same hardware that I captured it on.
If we go to the Advertise, and we scroll down to some of the other options,
there's the T1 and the T2 times.
Since this is stateful DHCP I went ahead and configured a lifetime.
We have the Identity Association address,
which is used for stateful DHCP to construct a valid address.
There's the DNS recursive name servers, and the Domain Search List,
and if we expand this one down there's the FQDN for the DNS Domain Search List,
so this is an actual offer packet.
In the IPv6 world it is an advertise packet.
And again,
we have the same thing from the client that's requesting this exact
information from the DHCP server that responded,
and here's the reply saying yes, you can actually go ahead and assign this.
It's all identical to the advertise packet.
Now if we scroll back up here a little bit,
you'll notice that the traffic from the server does not contain the Rapid
Commit header that we saw on the one from the client.
And again, that's because if you'll recall,
Rapid Commit has to be defined and available on both the client and the server.
You can't enable it on one without enabling on the other.
They both have to agree to use this particular protocol,
and when I set this up I actually just broke it on the server side and
so that's why you see that header in the client side,
but not on the server side.
And here is the exact same stateful DHCPv6 transaction,
but with Rapid Commit turned on,
and you'll notice there's two packets just as we said,
Solicit and Reply.
This is what I saw the first time I did the packet capture not realizing
exactly what Rapid Commit did to be perfectly honest,
and you can imagine my confusion when I looked at this and
saw I've only got half the packets here.
So, again if we'll look at these they look almost identical,
but we will notice that Rapid Commit is on on the client side,
and if we look on the server we should see the same field on this end.
Yes, there it is, Rapid Commit, option 14, Length 0.
So, just the presence of the Rapid Commit option,
which is option 14 from looking at this,
signifies to the client and the server that they can both support Rapid Commit.
We won't take the time to look at all the other options because
it's exactly like the previous packet capture. And that concludes our review of the DHCPv6 packet traces.