[music]
Okay, welcome back. We're going to keep going here with
the second part of our introduction. We're going to
go over IPv6 solicited-node multicast. This all comes
down to a basis of the problem that we don't have
broadcast. Earlier in this lesson, I mentioned how that was
a good thing and yes it is. However, as much of a good thing
as it is, it does bring certain problems to the table.
The biggest one, of course, is since there's no broadcast,
there's no ARP. With IPv4, typically what you're going
to have is machine comes online you need to get
your address from DHCP. That's going to be a whole
'nother discussion, but that's also part of this whole
thing. I need to get an address from DHCP, or it's statically
set - doesn't matter. You get an address, and if
you need to get off your own segment, that means you're
going to get a default gateway as well. And the next
thing you're going to have to do is you're going to
have to find out the Layer 2 address of your default gateway.
So on IPv4 we use, of course, ARP, Address Resolution
Protocol. For that to work, you send out a broadcast saying,
Hey, who has this IP address? I need to talk to this IP
address. And, of course, the router will answer.
That's great, except for that stupid little word I used in
there. Oh yeah, broadcast. See, problem. IPv6 does
not support broadcast. There's no ARP.
This brings up the next problem. Instead of ARP, since we don't
have it, we have to use something called Neighbor
Discovery. You could pretty much look at neighbor
discovery as the new ARP. Now a couple of
fundamental differences to be aware of though - and
we'll talk more about these as we go through different lessons
and such - is ARP was technically a separate
protocol. It was not part of IP. It ran outside of it.
In fact, we're just talking about protocol identifiers.
This would have been the Layer 2 header. It had a
different protocol identifier for IPv4 versus ARP.
With neighbor discovery, neighbor discovery is actually
part of ICMP version 6 now. Is ICMP still used for pings and
traces and all that? Yes, but it's used used for a
whole lot more now. I always like to make the joke that
ICMPv6 is all grown up now. It has so much more functionality
than we had in IPv4 and one of those things
is neighbor discovery. Now for the actual communication,
this is where this whole solicited-node multicast
address comes in. Since we don't have broadcasts and I
don't know who you are, then clearly, we need some other
way to communicate initially and that's what this is all about.
How do we start that initial communication between two
devices when I don't know your layer 2 address,
you don't know my layer 2 address, all I know
is your layer 3 address but I can't broadcast. That's the
dilemma. That's what this is all about. To solve
that, we have the solicited-node multicast address in this
format. Now we'll get into multicast a little bit later.
I'll just go ahead and bring up this next point because it
specifies what I'm about to tell you. FF, as I already
told you, means multicast in IPv6. So that's the first bite.
The first bite all-ones FF multicast. The zero is
four bits of flag bits and they indicate various things.
They indicate whether this packet contains rendezvous point
information, whether it contains prefix information.
There's four flags of course that can go into that field.
The last bite there, the two is the scope. Two means link local.
One is like a multicast loopback and never leaves the device.
And we can talk more about scopes later, but the
fact of the matter is the 2 there simply means do not go
to-- don't leave this segment. If you're familiar with
IPv4 multicast it's the equivalent of 2.24.0.0/24,
so it's link-local multicast non-routable. Now as far as
the rest of it goes back up on the first bullet point there the
colon, colon in that case represents four fields of zeros.
You can tell this because our other fields are shown and
there's eight fields total so the colon, colon obviously is
four fields of zeros. This is then followed by 1:ff00:0 /104.
Now if you do a little bit of math on that one,
since you know we have 128 bits and I'm specifying 104 here,
that means there's 24 bits that are not covered at the end of
this address. Now those bits are in fact the last two zeros
from the FF field. Remember that that represents
eight bits right there and then the last field is 16.
Between all of the last digits, remember that those three zeros
at the end technically represent actually six eights and at
four bits each, then that's of course our 24 bits.
Now here's what we do. The first part of that is given
and it's assigned by [?], that's not adjustable, okay?
And by the way, there's two quick things here.
This also is used for duplicate address detection, or DAD,
which I'm going to talk about here in just a minute,
okay? And this is the part that I just said, the format
leaves the last 24 bits of the address that are going
to be unique, per-host. Now, what does that mean?
What do we do with it? It doesn't all fit on one slide.
So here's what that means, okay? It means that if your host gets
an IP address, IPV6 address, as shown here, so I'm not
going to read that whole thing to you, that is an example
of an address, sort of based off a Mac address, we'll
talk more about that later. That means that it's going to
have the solicited note address of FF02::1:ff. Now all that
part, all of that is from the definition that we just
looked at a second ago. Then, what we do is we take the
last 24 bits of our real address so the 28:9c5a, we take that and
we put it on the end of our solicited-node address. That's
how you form the solicited-node address.
Now with that said, how does all this actually work,
what's it for, what are we actually doing here?
This is used for a couple of things. First, your machine
you are just booting up and you have an IPv6 address.
I don't care how you got it. That's coming up next.
We have a lot of ways to get an address. I don't care
how you got it. That's your address so the first thing
you do is you take the solicited-node address and
you form off of your address what your
unique solicited-node multicast address should be.
Now a lot of people look at this and go, but you're only
using the last 24 bits of the IPv6 address. Well,
agreed, but 24 bits is still 2 to the 24th.
That's still, what, 2.4 million possible combinations roughly?
I don't think you're going to have two machines on the same
segment with the same last 24 bits. See, they used the
24 least significant bits out of the address to
try to make sure that they would, in fact, be unique.
For a lot of devices, the last 24 bits are going to be
based off of the unique portion of the MAC address.
Now man, could we start getting into a whole lot of discussion
on this whole topic right here. How does a host get his host
portion? I'm going to talk about that on the next slide.
But a lot of devices left on their own such as Mac so OS X,
Linux, Cisco routers, a lot of these devices left to their own
device by default, we'll pull that based on the MAC address.
Now if we allow them to do that that means that the last 24 bits
of the MAC address are supposed to be the unique portion of the
address. But here's the problem, it's only unique per
individual manufacturer. In other words, if you have a
3Com NIC and a Broadcom NIC, they could very easily have
the same last 24 bits because the OUI portion of the
MAC address is owned by 3Com or Broadcom or Intel
or whoever. The fact of the matter is, you got to be really,
really careful, but it's okay because this is going to check
for us anyway and that's where I'm headed with the second
part of this. So you form this solicited-node address off
of the last 24 bits of your address. By the way, a quick
side note. If you notice in that list I gave you there,
one thing I did not mention was Windows. If you're actually
sitting on a Windows machine right now, if you
have not actually turned it off IPv6 is enabled by
default on all of your latest versions of Windows and if you
just do an IP config and you look at your IPv6 address,
it'll have created one of those link local addresses I was
talking about a minute ago, the FE80, and if you look at it
you'll notice that's it not based off your MAC address.
It's referred to as an IPv6 privacy address, at least
most places I've seen it listed. Basically, Microsoft
doesn't use the MAC address directly. I think it actually
still uses it as a C or something like that.
I'm not 100% sure how they do it internally inside the OS but the
fact of the matter is, it's not based on the MAC address and
that's why I was a little bit hesitant to say,
oh we could have a whole big discussion. Different OSs
can do it different ways and just to let you know the
reason, there's a little bit of concern in the IPv6 field that
if you're going to base the host portion of a MAC address the
MAC's way too track-able. Somebody could track your laptop
as you travel around the world, you were there and you
were and you logged in over here. Because your host portion
is your MAC address. So I can see everywhere that the host
portion was coming from and see everywhere you went, trace
that down to your MAC address, down to who that was sold to,
what laptop, who owns the laptop. Again, little bit
of concern over privacy. And this is why like I said
Windows doesn't even base it on the MAC address. And like
for all my personal devices and stuff if I have
IPv6 turned on I'd just hard code the addresses.
I don't let the host make up its own so and that's easy to do.
I'll show you all this when we get to config and we'll talk
more about it but right now I just want to focus
on this so again, so back to the last 24 bits. What if you did
have two network cards or whatever that had the same
last 24 bits just out of your incredibly-- I don't know if
that would be considered incredibly bad luck or
incredibly good look. I don't know if I should tell
you that if that happens to you that you should run out
and play the lottery immediately that night, or
if I should tell you to never ever play the lottery again ever
because you have the worst luck in the world. I'm not
really sure which way to go with that for you.
But joking aside though, the odds are so incredibly against
it. I don't think you have to lose any sleep tonight over
this. But if it were to happen, the next thing your device
is going to do is, it is actually going to send out a
packet with a destination of the solicited-node address and
it actually sends out what's called a neighbor
discovery message. It's the equivalent of an ARP request
because I did say I would equate this to IPv4 as we went through.
Yeah, it's the equivalent of what we would have called an ARP
request but of course it's not. It's a neighbor discovery
message. What we're hoping for - the cross-your-fingers-and-hope
- is nobody answers. That's the address we intend to use.
Therefore, nobody else should be using it. Therefore,
nobody should answer. This process is what we referred to
on the previous slide there as duplicate address
detection or DAD. That's that whole process. If it does
get an answer, it means somebody else is already using
the address and he will just create another one.
How? It depends on operating system. I'm not going
to sit and try and answer for every operating system
out there but he will try to create another address for
himself then. It's pseudo-random anyway, so
it really doesn't matter, he'll just pick another address
based on the operating system. Now, let's go the other way,
let's assume that DAD pathed so he did not have a duplicate
address and he goes ahead and then assigns that IPv6 address
to his interface. So that's now his interface, he's done
duplicate address detection on it, and everything we've
just discussed the solicited-node multicast
address has accomplished job number one. That's
DAD and joining that group. So the two things
that this host will do after he does DAD is assigns
this IPv6 address to his interface, and he joins the
solicited node multicast group on that interface.
So then, instead of sending traffic to that address,
he starts listening on the FFO2::1:FF28:9C5A.
He listens to that address. What's he listening for?
Neighbor discovery messages. He's listening for somebody else
to ask. Ask what? One or two things.
He's looking for the other person to say,
Hey, does anybody have this? Because I want to use it.
And so he can basically say no. Now again, that's not
exactly how that works. I'm using a little bit
of poetic license there. Again, basically the other guy
is going to send a solicited node neighbor discovery
message for our address and we're going to
answer and he's going to do the Dad part. He's going to
go somebody else is already listening to that group.
Oh, darn. He'll have to pick another address.
This would be-- once we join this is us doing the other side
of the Dad. We're supplying the answer. Of course, the
other part of that goes hand in hand with it and once
we've joined this group we honestly don't know or care
which one we're doing. It's the same message to us.
That would be the main purpose we went this whole discussion.
Remember we're trying to deal with the fact that we don't have
ARP anymore. That was to do Layer 3 to Layer
2 address resolution. Again, somebody maybe on the
default gateway, maybe this doesn't happen very often
anymore, but maybe this is host to hosts traffic on the
same segment. Maybe more on your data center with
multi-tiered applications than it happens out on the
client side these days. In any case, maybe this is just
peer-to-peer traffic on the same segment not even going through
the router. Doesn't matter who it is, they all do the same
thing. I need to find out what your MAC address is
if I'm going to talk to you on an Ethernet segment.
Since I know the IPv6 address I'm trying to talk to,
I then take the IPv6 address that is my default gateway,
the guy I'm trying to talk to, whoever it is-- I take his IPv6
address and again form the solicited-node multicast address
out of that going through this exact same method.
Then I send my neighbor discovery solicitation message
to that address. Here's the cool part. Depending on how good
your switch is - and I sort of mentioned this earlier -
you may or may not have a switch that can handle
this. This is link local multicast. It's not going to
have IGMP joins and such for it. Therefore, IGMP snooping
on your switch is not going to help here. There's a pretty
good chance that this is going to actually get flooded
by the switch to every single node on that switch - every
single node on that VLAN. Now that's okay, though, because
if you go back to our discussion a little bit earlier, what I
said was let's say your switch does in fact flood this.
The problem with broadcast is when that traffic gets to your
network card, your network card looks at that and goes
it's a broadcast, it's for me, process it and sends it
up to the [OS?]. The problem is if it's not
really for you, that just wasted your CPU.
Here's what's cool about this. This is not a broadcast.
Let's say this in fact does get flooded by your switch to every
single node on the segment. When the traffic comes in,
you've got to remember - and maybe I need to bring this
up because maybe some of you are not aware of
this - every multicast address, be it IPv4 or IPv6,
gets mapped to an IP-- sorry, to a Layer 2 multicast MAC address.
When your machine joins this solicited-node multicast group,
he creates the corresponding multicast MAC address and
installs that onto his network card so that when this frame
shows up on the wire, you know, just bits
coming in on the wire, he looks at the destination address,
he sees the FF02::1:FF, he sees this solicited-node
multicast address, he looks at the multicast group and
he looks at his network card and the MAC
addresses on the network card and he goes, this isn't for
me, throw it away. Right there in hardware. Right there
on the network card. Never hits the CPU or the
device. Never hits the operating system. Why? Because that
network card doesn't own the corresponding multicast
MAC address. So he's going to have his unicast MAC address and
his solicited-node multicast MAC address but he will
not have somebody else's multicast MAC address for
their solicited node. It means that everybody on the
segment is going to have joined and have a unique - that's
the key - multicast MAC address added to their [nick?]. When
that frame comes in and I look at that MAC address,
right there in hardware I go, This is not for me.
This is not my MAC address. Throw it away. Of course,
the guy who I am trying to contact, of course the opposite
happens, right? He goes-- he looks at that. He is
joined to that multicast MAC address. He looks
at it and goes, Yup, this is for my MAC address.
Bring it in. Send it on up. He sends it up to the CPU.
The operating system, they of course look at it and see that
this is a neighbor discovery solicitation message and go,
Somebody is trying to get our info and he will send a neighbor
discovery response and he will then answer.
Whoever was trying to talk to me, now has my MAC address.
And of course, just like ARP, his MAC address was included in
the original communication to me. There you go.
We'll see all this work as we start getting
in the configuration and setting this all up.
Not to worry. Like I said, this first lesson, I want to get
all the theory out of the way and we'll see it as we
go. It never hurts to see things twice anyway. This is
all our theory and I'll show you all of the stuff working
as we go. That's how solicited-node multicast
works. So yeah, you're not going to be going to
your devices and looking at ARP anymore, now you're going
to be looking at neighbor discovery. That's the new ARP.
[music]