NDP allows an IPv6 host to dynamically discover its neighbors, but the process of discovering neighboring routers is slightly different than that of discovering other hosts.
(good for exam)
The router discovery process begins with the host multicasting(sending out) what we call a Router Solicitation message (RS) on its local link. What’s the destination for this? It’s a multicast, so it’s not a unicast and it’s not going to one particular host. It’s not a broadcast because we don’t have those in v6 anyway. This is a multicast and the destination is FF02::2 and this is the All-IPv6-Routers address. Every router you enable v6 on, and then do so on the interface, is going to be listening to this address for messages.
That sounds kind of familiar… FF02::2… Here it is :
During the break, I took the EUI-64 address off the interface and I put the original global unicast address back on as you can see, and your big hint is that you do not see EUI-64 at here next to the global unicast address information.
When we configured IPv6, we never joined a group manually, but all of a sudden we had these four groups show up, and we’re going to see what’s going on with all four of these groups here in the next few minutes… and the first one here that we know about (FF02::2) is the All-IPv6 Routers multicast address.
When our host sends a router solicitation (an RS) to FF02::2 then it’s going to hope a router answers that.
Any router on that link that hears that message will respond with a Router Advertisement (RA)
Notice we have a question mark there for destination because the destination of the R.A. actually depends on whether or not our host has a version 6 address yet.
There are two possibilities for the RA destination address:
If the querying host has an IPv6 address, that would have been in the original router solicitation (RS), and the router will unicast its RA back to that same address.
If the querying host does not yet have an IPv6 address, the source address of the router solicitation (RS) would be all zeros, and the router will then multicast the RA to FF02::1, the “All-IPV6-Nodes” address.
That one sounds a little bit familiar as well and as you can see our interface there has also joined that group FF02::1
So that’s our all-IPV6 host address and the one below it (::2) is the all-IPV6 routers multicast address.
In addition to sending an RS when specifically requested to by an RA, IPv6 routers multicast an RA to FF02::1 every 200 seconds.
So it’s a little faster for the host to just go ahead and explicitly request one rather than waiting for that multicast, but again our version 6 router will multicast a router advertisement every 200 seconds to the all-IPV6 host address.
Using NTP To Discover IPV6 Hosts
The NDP neighbor solicitation and neighbor advertisement replace ARP in IPv6, with the NS serving as the rough equivalent to IPv4’s ARP Request. The main difference? An ARP Request asks for the MAC address of the device at a particular IP address (i.e 172 1 1 1)
We know that the neighbor solicitation message is similar but the destination address is a little different… It’s a little odd !!
An IPv6 NS destined for what we call the solicited-node multicast address (the SNMA) of the host whose MAC address is being requested.
What the heck is a “solicited-node multicast address”?
A multicast destined for the solicited node multicast address (It’s actually kind of a built-in range) goes to some hosts on the local link, but not all of them -just the ones that have the same last six hex values as the IPv6 address of the host whose MAC address is being requested.
(when you look at that you think: ” what are the odds that multiple hosts on the same link are going to have the same last six hex values as the v6 address of the host who’s MAC address was just requested?”
Well the more hosts you have the bigger the chance ! but with a few hosts, the chances are pretty low!
We also want to know how to calculate the SNMA? Where it came from? and also where to find them on the router?
We’ve actually seen one SNMA to this point! But we just didn’t know it yet. Two of them, actually!! and again if we go back to show IP interface fast 0/0, I bet you can guess which two addresses here are actually SNMAs.
That’s these two addresses :
also the end of one of those might look a little familiar if you look elsewhere, we’ve got a 990 up there at the end of our link local address.
And by the way the reason that we saw two SNMAs there is that one is for the global unicast address and the other is for the link-local address.
To calculate the SNMA…
The SNMA always begins with FF02::1:FF. In uncompressed format(which is not necessary for you to do that), that’s FF01:0000:0000:0000:0000:0001:FF. That’s most of the SNMA right there.
Take the last six values of the global unicast address or the link-local address and tack them on to the end of FF02::1:FF, and you’re done!
The only thing you got to watch here is:
You can’t just take the last six hex characters of the compressed version of the global unicast address or the link-local address. You have to uncompress them and get the last six characters.
So let’s do a little practice here.
What are the last six hex characters of our global routing address when it’s uncompressed?
2001:1111:2222:1::1
Uncompressed: 2001:1111:2222:0001:0000:0000:0000:0001
These are the six characters you need to add to the end of the SNMA prefix
Put “00:0001” on the end of FF02::1:FF, and you get FF02::1:FF00:1 (with leading zero compression applied to the last block).
Does that match one of our group addresses? It Sure does.
So the theory holds up perfectly and we know that is the SNMA for our global unicast address.
What are the last 6 hex characters of our link-local address?
FE80::21B:D4EF:FEC2:990
Uncompressed: FE80:0000:0000:0000:021B:D4FF:FEC2:0990
Add C2:0990 onto the end of FF02::1:FF, and you get FF02::1:FFC2:990.
(Leading zero compression applied to final block)
Does that match the remaining group on our router? Yes
Hey, we need to finish our NS / NA swap!
The Neighbor Advertisement that is going to be sent in reply to the NS, and it’s going to be a unicast. It’s sent directly to the host that originated the NS.
So what happens here is that one host will answer the other host’s neighbor solicitation with a neighbor advertisement.
Here, Host B answers Host A’s NS with an NA, containing Host B’s MAC address. Host A pops that address into its Neighbor Discovery Protocol neighbor table (the equivalent of IPV4’s ARP cache, and we are done!
Leave feedback about this