DEMO: Wireshark, NDP - Neighbors

Neighbor discovery protocol

I have my demo laptop and my demo Pi, and I'm going to generate some traffic between those and then look at the headers of the neighbor solicitation and neighbor advertisement packets that go back and forth between the two machines.

What that neighbor discovery protocol is doing is finding out the MAC address of the demo Pi machine, so that way it knows how to communicate with it. Remember, layer 2 has to use MAC addresses, so it needs to find out the MAC address that's associated with the IP version 6 address that we're going to use. When we're talking about IPv4, it uses a process called ARP: it will send out a broadcast to all machines on the network, and then all machines will get that, and the one that has the IP address will reply with the associated MAC address. Well, we don't have broadcast with IPv6, so instead it needs to be a multicast, and so we're going to look at that process for neighbor discovery protocol.

Checking and clearing the neighbor table

First of all, the neighbor discovery protocol is not going to work if the neighbor already shows up in its neighbor table. What I mean by that is, the first thing that your computer is going to do when it communicates out to a device is look up in its neighbor table and see if it already has the answer. So let's see if this machine, this demo laptop, already has the answer.

I'm going to bring up a command prompt. In case I need to delete the neighbor table — clear out the cache of this neighbor table — I'm going to need to make sure I'm in elevated permissions to do that, so I'm going to right click on this and say run as administrator so I can get in here with elevated permission. The command I'm going to use for this is netsh interface ipv6, and we just want to show neighbors.

We're going to see a big long list, because there's quite a few interfaces that are associated on this machine. We scroll up, and in fact this is the address that belongs to the demo Pi, fc00:1::3, and this is the MAC address associated with it.

These interchanges of neighbor discovery protocol might not be exactly what we're looking for, so what we're going to do is clear out this table. To clear out the table, what I'll do is change this show to delete, and then that clears out that table.

Capturing the traffic

Next, we'll generate some traffic and then capture it with Wireshark. I'm going to open up Wireshark, and I'm going to monitor the Ethernet interface, so now it's already starting to collect some data that's coming in from the switch. I'll open up a browser and I'm going to open up the IP address that I'm trying to get to. We see that it generates a lot of traffic back and forth. I can stop my capture at this point in time.

Now, for these two devices to communicate, we see that we have some TCP and HTTP, but for that all to happen, it needs to happen across MAC addresses. So how does it get that MAC address?

The neighbor solicitation

Let's start by first looking at the neighbor solicitation, so I'm going to click the neighbor solicitation. I'll minimize some of this because we'll look at specific aspects here one at a time.

The first thing that I'll do is take a look at this ICMP section right here. We see that this is a type 135, so that measures up with what we know.

Let's look at the source, the source layer 3 and layer 2. If I look at the source layer 3, the source layer 3 is fc00:1::14. That's the static IP that's associated with the demo laptop. That makes sense — it's coming from that demo laptop, it knows its own IP address, so that makes sense there. We look at the layer 2 IP address, and once again it's coming from the layer 2 address of the demo laptop, so that makes sense as well. No surprises there: it knows its own MAC address, so why would it not put it in there? So that all makes sense.

Now let's take a look at the destination. The destination is where we see a little bit of difference, maybe a little bit of a surprise here, and that is that it's using this ff02::1:ff. Anytime we see that, that's the beginning of that solicited node multicast address, and 00:3 is the associated solicited node multicast address that's associated with the fc00:1::3 that we have, the statically assigned IP address, the one that we generated traffic to.

So what essentially has happened is that machine figured out what the solicited node multicast address is, and then told the switch, "I want to be part of this multicast group." And then this machine, the demo laptop, said, "I'm trying to find out the MAC address of this IP address, so I'm going to send a multicast out to the switch to find out what the MAC address is." And the switch knows, okay, I'm going to forward this on to the Pi. So now the Pi receives this. It's a multicast group of just one device, and so this is how we get around — in the case with ARP, where it sends out to all of the devices for IPv4 saying, "Hey, who belongs to this IP address?" Now we've got a mechanism with this neighbor discovery protocol to find the MAC address of a single machine and just send traffic to that single machine.

And then we take a look at the layer 2 address, and this is the 3333ff. So once again, that's the MAC address that's associated with this solicited node multicast address, and then it's 000003. So that is just the layer 2 multicast MAC address that's associated with the layer 3 multicast address.

So that is where we find the solicited node multicast address. This is just sending out, who belongs to this?

The neighbor advertisement

Then what we can do is look at what the response is, so we click on the neighbor advertisement. Here again, I'm going to start by closing all these sections up. Let's just take a look at the ICMP. The ICMP is 136, so that's pretty straightforward, and it gives the MAC address of the Pi. So there's the answer, that's replying with the answer.

But we really also see, with the answer, when it comes to the layer 3 and layer 2 — so here in the layer 3, the source address is of the Pi, the statically assigned address that we assigned to the Pi, and the destination address is the statically assigned address of the demo laptop. And the same thing if we look at the layer 2: it's the MAC address of the laptop and the MAC address of the demo Pi. All of those make sense, because it's just sending a unicast back at this point in time. It sends a multicast out — the neighbor solicitation is a multicast, and it's a multicast with just one member in it — and then what it's getting back is a unicast back for an answer.

Now this device, the demo laptop, knows the MAC address that's associated with the IP address that we have. So we can go back to this table and do the same command that we did before to show all of the interfaces, and we see the fc0:1::3, and it now has the MAC address that's associated with it.

So now that sets the stage. It has the layer 2 address, now it can start requesting to get the rest of the information and send the web page request out to this device. We've successfully made the connection now, and a critical part of all of this was that neighbor discovery protocol, with neighbor solicitation and neighbor advertisements.