1 00:00:03,070 --> 00:00:06,506 [music] 2 00:00:09,309 --> 00:00:13,580 Okay, welcome back. We're going to keep going here with 3 00:00:13,580 --> 00:00:17,184 the second part of our introduction. We're going to 4 00:00:17,184 --> 00:00:24,024 go over IPv6 solicited-node multicast. This all comes 5 00:00:24,024 --> 00:00:30,731 down to a basis of the problem that we don't have 6 00:00:30,731 --> 00:00:35,202 broadcast. Earlier in this lesson, I mentioned how that was 7 00:00:35,202 --> 00:00:40,274 a good thing and yes it is. However, as much of a good thing 8 00:00:40,274 --> 00:00:46,013 as it is, it does bring certain problems to the table. 9 00:00:46,013 --> 00:00:49,516 The biggest one, of course, is since there's no broadcast, 10 00:00:49,516 --> 00:00:55,989 there's no ARP. With IPv4, typically what you're going 11 00:00:55,989 --> 00:01:01,929 to have is machine comes online you need to get 12 00:01:01,929 --> 00:01:05,465 your address from DHCP. That's going to be a whole 13 00:01:05,465 --> 00:01:07,834 'nother discussion, but that's also part of this whole 14 00:01:07,834 --> 00:01:14,408 thing. I need to get an address from DHCP, or it's statically 15 00:01:14,408 --> 00:01:18,145 set - doesn't matter. You get an address, and if 16 00:01:18,145 --> 00:01:20,347 you need to get off your own segment, that means you're 17 00:01:20,347 --> 00:01:23,050 going to get a default gateway as well. And the next 18 00:01:23,050 --> 00:01:25,519 thing you're going to have to do is you're going to 19 00:01:25,519 --> 00:01:31,558 have to find out the Layer 2 address of your default gateway. 20 00:01:31,558 --> 00:01:35,062 So on IPv4 we use, of course, ARP, Address Resolution 21 00:01:35,062 --> 00:01:40,067 Protocol. For that to work, you send out a broadcast saying, 22 00:01:40,067 --> 00:01:44,371 Hey, who has this IP address? I need to talk to this IP 23 00:01:44,371 --> 00:01:48,742 address. And, of course, the router will answer. 24 00:01:48,742 --> 00:01:51,478 That's great, except for that stupid little word I used in 25 00:01:51,478 --> 00:01:58,618 there. Oh yeah, broadcast. See, problem. IPv6 does 26 00:01:58,618 --> 00:02:04,391 not support broadcast. There's no ARP. 27 00:02:04,391 --> 00:02:08,295 This brings up the next problem. Instead of ARP, since we don't 28 00:02:08,295 --> 00:02:10,197 have it, we have to use something called Neighbor 29 00:02:10,197 --> 00:02:13,500 Discovery. You could pretty much look at neighbor 30 00:02:13,500 --> 00:02:18,238 discovery as the new ARP. Now a couple of 31 00:02:18,238 --> 00:02:20,874 fundamental differences to be aware of though - and 32 00:02:20,874 --> 00:02:23,810 we'll talk more about these as we go through different lessons 33 00:02:23,810 --> 00:02:28,515 and such - is ARP was technically a separate 34 00:02:28,515 --> 00:02:32,619 protocol. It was not part of IP. It ran outside of it. 35 00:02:32,619 --> 00:02:37,424 In fact, we're just talking about protocol identifiers. 36 00:02:37,424 --> 00:02:41,028 This would have been the Layer 2 header. It had a 37 00:02:41,028 --> 00:02:47,367 different protocol identifier for IPv4 versus ARP. 38 00:02:47,367 --> 00:02:50,570 With neighbor discovery, neighbor discovery is actually 39 00:02:50,570 --> 00:02:57,110 part of ICMP version 6 now. Is ICMP still used for pings and 40 00:02:57,110 --> 00:03:00,914 traces and all that? Yes, but it's used used for a 41 00:03:00,914 --> 00:03:03,450 whole lot more now. I always like to make the joke that 42 00:03:03,450 --> 00:03:10,924 ICMPv6 is all grown up now. It has so much more functionality 43 00:03:10,924 --> 00:03:15,028 than we had in IPv4 and one of those things 44 00:03:15,028 --> 00:03:20,667 is neighbor discovery. Now for the actual communication, 45 00:03:20,667 --> 00:03:23,303 this is where this whole solicited-node multicast 46 00:03:23,303 --> 00:03:27,441 address comes in. Since we don't have broadcasts and I 47 00:03:27,441 --> 00:03:31,511 don't know who you are, then clearly, we need some other 48 00:03:31,511 --> 00:03:36,149 way to communicate initially and that's what this is all about. 49 00:03:36,149 --> 00:03:38,618 How do we start that initial communication between two 50 00:03:38,618 --> 00:03:42,422 devices when I don't know your layer 2 address, 51 00:03:42,422 --> 00:03:45,559 you don't know my layer 2 address, all I know 52 00:03:45,559 --> 00:03:50,464 is your layer 3 address but I can't broadcast. That's the 53 00:03:50,464 --> 00:03:54,301 dilemma. That's what this is all about. To solve 54 00:03:54,301 --> 00:03:59,005 that, we have the solicited-node multicast address in this 55 00:03:59,005 --> 00:04:03,410 format. Now we'll get into multicast a little bit later. 56 00:04:03,410 --> 00:04:07,247 I'll just go ahead and bring up this next point because it 57 00:04:07,247 --> 00:04:11,485 specifies what I'm about to tell you. FF, as I already 58 00:04:11,485 --> 00:04:18,592 told you, means multicast in IPv6. So that's the first bite. 59 00:04:18,592 --> 00:04:25,832 The first bite all-ones FF multicast. The zero is 60 00:04:25,832 --> 00:04:33,373 four bits of flag bits and they indicate various things. 61 00:04:33,373 --> 00:04:37,043 They indicate whether this packet contains rendezvous point 62 00:04:37,043 --> 00:04:41,248 information, whether it contains prefix information. 63 00:04:41,248 --> 00:04:46,386 There's four flags of course that can go into that field. 64 00:04:46,386 --> 00:04:57,731 The last bite there, the two is the scope. Two means link local. 65 00:04:57,731 --> 00:05:03,570 One is like a multicast loopback and never leaves the device. 66 00:05:03,570 --> 00:05:06,106 And we can talk more about scopes later, but the 67 00:05:06,106 --> 00:05:13,113 fact of the matter is the 2 there simply means do not go 68 00:05:13,113 --> 00:05:18,819 to-- don't leave this segment. If you're familiar with 69 00:05:18,819 --> 00:05:27,227 IPv4 multicast it's the equivalent of 2.24.0.0/24, 70 00:05:27,227 --> 00:05:32,232 so it's link-local multicast non-routable. Now as far as 71 00:05:32,232 --> 00:05:38,705 the rest of it goes back up on the first bullet point there the 72 00:05:38,705 --> 00:05:44,811 colon, colon in that case represents four fields of zeros. 73 00:05:44,811 --> 00:05:47,881 You can tell this because our other fields are shown and 74 00:05:47,881 --> 00:05:51,418 there's eight fields total so the colon, colon obviously is 75 00:05:51,418 --> 00:06:03,663 four fields of zeros. This is then followed by 1:ff00:0 /104. 76 00:06:03,663 --> 00:06:06,900 Now if you do a little bit of math on that one, 77 00:06:06,900 --> 00:06:13,273 since you know we have 128 bits and I'm specifying 104 here, 78 00:06:13,273 --> 00:06:17,677 that means there's 24 bits that are not covered at the end of 79 00:06:17,677 --> 00:06:25,318 this address. Now those bits are in fact the last two zeros 80 00:06:25,318 --> 00:06:28,922 from the FF field. Remember that that represents 81 00:06:28,922 --> 00:06:39,432 eight bits right there and then the last field is 16. 82 00:06:39,432 --> 00:06:45,272 Between all of the last digits, remember that those three zeros 83 00:06:45,272 --> 00:06:51,211 at the end technically represent actually six eights and at 84 00:06:51,211 --> 00:06:56,616 four bits each, then that's of course our 24 bits. 85 00:06:56,616 --> 00:07:00,520 Now here's what we do. The first part of that is given 86 00:07:00,520 --> 00:07:07,127 and it's assigned by [?], that's not adjustable, okay? 87 00:07:07,127 --> 00:07:09,629 And by the way, there's two quick things here. 88 00:07:09,629 --> 00:07:13,500 This also is used for duplicate address detection, or DAD, 89 00:07:13,500 --> 00:07:16,303 which I'm going to talk about here in just a minute, 90 00:07:16,303 --> 00:07:19,739 okay? And this is the part that I just said, the format 91 00:07:19,739 --> 00:07:23,009 leaves the last 24 bits of the address that are going 92 00:07:23,009 --> 00:07:28,214 to be unique, per-host. Now, what does that mean? 93 00:07:28,214 --> 00:07:32,352 What do we do with it? It doesn't all fit on one slide. 94 00:07:32,352 --> 00:07:38,692 So here's what that means, okay? It means that if your host gets 95 00:07:38,692 --> 00:07:43,763 an IP address, IPV6 address, as shown here, so I'm not 96 00:07:43,763 --> 00:07:47,367 going to read that whole thing to you, that is an example 97 00:07:47,367 --> 00:07:50,537 of an address, sort of based off a Mac address, we'll 98 00:07:50,537 --> 00:07:54,240 talk more about that later. That means that it's going to 99 00:07:54,240 --> 00:08:03,149 have the solicited note address of FF02::1:ff. Now all that 100 00:08:03,149 --> 00:08:08,254 part, all of that is from the definition that we just 101 00:08:08,254 --> 00:08:11,758 looked at a second ago. Then, what we do is we take the 102 00:08:11,758 --> 00:08:19,899 last 24 bits of our real address so the 28:9c5a, we take that and 103 00:08:19,899 --> 00:08:25,338 we put it on the end of our solicited-node address. That's 104 00:08:25,338 --> 00:08:29,142 how you form the solicited-node address. 105 00:08:29,142 --> 00:08:34,114 Now with that said, how does all this actually work, 106 00:08:34,114 --> 00:08:38,885 what's it for, what are we actually doing here? 107 00:08:38,885 --> 00:08:45,558 This is used for a couple of things. First, your machine 108 00:08:45,558 --> 00:08:51,297 you are just booting up and you have an IPv6 address. 109 00:08:51,297 --> 00:08:55,368 I don't care how you got it. That's coming up next. 110 00:08:55,368 --> 00:08:58,972 We have a lot of ways to get an address. I don't care 111 00:08:58,972 --> 00:09:02,242 how you got it. That's your address so the first thing 112 00:09:02,242 --> 00:09:07,947 you do is you take the solicited-node address and 113 00:09:07,947 --> 00:09:12,452 you form off of your address what your 114 00:09:12,452 --> 00:09:16,523 unique solicited-node multicast address should be. 115 00:09:16,523 --> 00:09:18,358 Now a lot of people look at this and go, but you're only 116 00:09:18,358 --> 00:09:23,329 using the last 24 bits of the IPv6 address. Well, 117 00:09:23,329 --> 00:09:31,004 agreed, but 24 bits is still 2 to the 24th. 118 00:09:31,004 --> 00:09:37,544 That's still, what, 2.4 million possible combinations roughly? 119 00:09:37,544 --> 00:09:41,047 I don't think you're going to have two machines on the same 120 00:09:41,047 --> 00:09:47,954 segment with the same last 24 bits. See, they used the 121 00:09:47,954 --> 00:09:52,725 24 least significant bits out of the address to 122 00:09:52,725 --> 00:09:57,464 try to make sure that they would, in fact, be unique. 123 00:09:57,464 --> 00:10:02,068 For a lot of devices, the last 24 bits are going to be 124 00:10:02,068 --> 00:10:06,973 based off of the unique portion of the MAC address. 125 00:10:06,973 --> 00:10:10,109 Now man, could we start getting into a whole lot of discussion 126 00:10:10,109 --> 00:10:15,615 on this whole topic right here. How does a host get his host 127 00:10:15,615 --> 00:10:19,819 portion? I'm going to talk about that on the next slide. 128 00:10:19,819 --> 00:10:29,896 But a lot of devices left on their own such as Mac so OS X, 129 00:10:29,896 --> 00:10:37,070 Linux, Cisco routers, a lot of these devices left to their own 130 00:10:37,070 --> 00:10:43,943 device by default, we'll pull that based on the MAC address. 131 00:10:43,943 --> 00:10:50,116 Now if we allow them to do that that means that the last 24 bits 132 00:10:50,116 --> 00:10:56,122 of the MAC address are supposed to be the unique portion of the 133 00:10:56,122 --> 00:11:01,427 address. But here's the problem, it's only unique per 134 00:11:01,427 --> 00:11:04,964 individual manufacturer. In other words, if you have a 135 00:11:04,964 --> 00:11:10,837 3Com NIC and a Broadcom NIC, they could very easily have 136 00:11:10,837 --> 00:11:17,410 the same last 24 bits because the OUI portion of the 137 00:11:17,410 --> 00:11:23,116 MAC address is owned by 3Com or Broadcom or Intel 138 00:11:23,116 --> 00:11:26,519 or whoever. The fact of the matter is, you got to be really, 139 00:11:26,519 --> 00:11:30,857 really careful, but it's okay because this is going to check 140 00:11:30,857 --> 00:11:33,493 for us anyway and that's where I'm headed with the second 141 00:11:33,493 --> 00:11:38,498 part of this. So you form this solicited-node address off 142 00:11:38,498 --> 00:11:44,771 of the last 24 bits of your address. By the way, a quick 143 00:11:44,771 --> 00:11:49,008 side note. If you notice in that list I gave you there, 144 00:11:49,008 --> 00:11:53,313 one thing I did not mention was Windows. If you're actually 145 00:11:53,313 --> 00:11:56,316 sitting on a Windows machine right now, if you 146 00:11:56,316 --> 00:12:01,588 have not actually turned it off IPv6 is enabled by 147 00:12:01,588 --> 00:12:05,058 default on all of your latest versions of Windows and if you 148 00:12:05,058 --> 00:12:09,562 just do an IP config and you look at your IPv6 address, 149 00:12:09,562 --> 00:12:11,764 it'll have created one of those link local addresses I was 150 00:12:11,764 --> 00:12:15,702 talking about a minute ago, the FE80, and if you look at it 151 00:12:15,702 --> 00:12:20,573 you'll notice that's it not based off your MAC address. 152 00:12:20,573 --> 00:12:23,643 It's referred to as an IPv6 privacy address, at least 153 00:12:23,643 --> 00:12:28,081 most places I've seen it listed. Basically, Microsoft 154 00:12:28,081 --> 00:12:32,819 doesn't use the MAC address directly. I think it actually 155 00:12:32,819 --> 00:12:36,856 still uses it as a C or something like that. 156 00:12:36,856 --> 00:12:42,295 I'm not 100% sure how they do it internally inside the OS but the 157 00:12:42,295 --> 00:12:45,765 fact of the matter is, it's not based on the MAC address and 158 00:12:45,765 --> 00:12:47,467 that's why I was a little bit hesitant to say, 159 00:12:47,467 --> 00:12:51,838 oh we could have a whole big discussion. Different OSs 160 00:12:51,838 --> 00:12:55,041 can do it different ways and just to let you know the 161 00:12:55,041 --> 00:13:00,480 reason, there's a little bit of concern in the IPv6 field that 162 00:13:00,480 --> 00:13:04,917 if you're going to base the host portion of a MAC address the 163 00:13:04,917 --> 00:13:09,989 MAC's way too track-able. Somebody could track your laptop 164 00:13:09,989 --> 00:13:12,358 as you travel around the world, you were there and you 165 00:13:12,358 --> 00:13:16,029 were and you logged in over here. Because your host portion 166 00:13:16,029 --> 00:13:20,366 is your MAC address. So I can see everywhere that the host 167 00:13:20,366 --> 00:13:24,003 portion was coming from and see everywhere you went, trace 168 00:13:24,003 --> 00:13:27,774 that down to your MAC address, down to who that was sold to, 169 00:13:27,774 --> 00:13:32,045 what laptop, who owns the laptop. Again, little bit 170 00:13:32,045 --> 00:13:36,315 of concern over privacy. And this is why like I said 171 00:13:36,315 --> 00:13:40,253 Windows doesn't even base it on the MAC address. And like 172 00:13:40,253 --> 00:13:42,622 for all my personal devices and stuff if I have 173 00:13:42,622 --> 00:13:46,693 IPv6 turned on I'd just hard code the addresses. 174 00:13:46,693 --> 00:13:52,365 I don't let the host make up its own so and that's easy to do. 175 00:13:52,365 --> 00:13:55,268 I'll show you all this when we get to config and we'll talk 176 00:13:55,268 --> 00:13:58,504 more about it but right now I just want to focus 177 00:13:58,504 --> 00:14:04,410 on this so again, so back to the last 24 bits. What if you did 178 00:14:04,410 --> 00:14:08,681 have two network cards or whatever that had the same 179 00:14:08,681 --> 00:14:13,686 last 24 bits just out of your incredibly-- I don't know if 180 00:14:13,686 --> 00:14:15,755 that would be considered incredibly bad luck or 181 00:14:15,755 --> 00:14:18,157 incredibly good look. I don't know if I should tell 182 00:14:18,157 --> 00:14:20,259 you that if that happens to you that you should run out 183 00:14:20,259 --> 00:14:23,196 and play the lottery immediately that night, or 184 00:14:23,196 --> 00:14:26,666 if I should tell you to never ever play the lottery again ever 185 00:14:26,666 --> 00:14:28,234 because you have the worst luck in the world. I'm not 186 00:14:28,234 --> 00:14:31,804 really sure which way to go with that for you. 187 00:14:31,804 --> 00:14:37,543 But joking aside though, the odds are so incredibly against 188 00:14:37,543 --> 00:14:40,480 it. I don't think you have to lose any sleep tonight over 189 00:14:40,480 --> 00:14:46,185 this. But if it were to happen, the next thing your device 190 00:14:46,185 --> 00:14:50,523 is going to do is, it is actually going to send out a 191 00:14:50,523 --> 00:14:57,163 packet with a destination of the solicited-node address and 192 00:14:57,163 --> 00:14:59,098 it actually sends out what's called a neighbor 193 00:14:59,098 --> 00:15:04,270 discovery message. It's the equivalent of an ARP request 194 00:15:04,270 --> 00:15:08,775 because I did say I would equate this to IPv4 as we went through. 195 00:15:08,775 --> 00:15:13,312 Yeah, it's the equivalent of what we would have called an ARP 196 00:15:13,312 --> 00:15:16,883 request but of course it's not. It's a neighbor discovery 197 00:15:16,883 --> 00:15:25,158 message. What we're hoping for - the cross-your-fingers-and-hope 198 00:15:25,158 --> 00:15:34,267 - is nobody answers. That's the address we intend to use. 199 00:15:34,267 --> 00:15:38,104 Therefore, nobody else should be using it. Therefore, 200 00:15:38,104 --> 00:15:43,676 nobody should answer. This process is what we referred to 201 00:15:43,676 --> 00:15:46,946 on the previous slide there as duplicate address 202 00:15:46,946 --> 00:15:51,751 detection or DAD. That's that whole process. If it does 203 00:15:51,751 --> 00:15:54,954 get an answer, it means somebody else is already using 204 00:15:54,954 --> 00:15:58,724 the address and he will just create another one. 205 00:15:58,724 --> 00:16:02,528 How? It depends on operating system. I'm not going 206 00:16:02,528 --> 00:16:05,198 to sit and try and answer for every operating system 207 00:16:05,198 --> 00:16:09,569 out there but he will try to create another address for 208 00:16:09,569 --> 00:16:14,540 himself then. It's pseudo-random anyway, so 209 00:16:14,540 --> 00:16:17,610 it really doesn't matter, he'll just pick another address 210 00:16:17,610 --> 00:16:22,515 based on the operating system. Now, let's go the other way, 211 00:16:22,515 --> 00:16:28,154 let's assume that DAD pathed so he did not have a duplicate 212 00:16:28,154 --> 00:16:35,561 address and he goes ahead and then assigns that IPv6 address 213 00:16:35,561 --> 00:16:39,498 to his interface. So that's now his interface, he's done 214 00:16:39,498 --> 00:16:43,436 duplicate address detection on it, and everything we've 215 00:16:43,436 --> 00:16:46,105 just discussed the solicited-node multicast 216 00:16:46,105 --> 00:16:51,277 address has accomplished job number one. That's 217 00:16:51,277 --> 00:16:56,015 DAD and joining that group. So the two things 218 00:16:56,015 --> 00:17:01,053 that this host will do after he does DAD is assigns 219 00:17:01,053 --> 00:17:09,161 this IPv6 address to his interface, and he joins the 220 00:17:09,161 --> 00:17:14,033 solicited node multicast group on that interface. 221 00:17:14,033 --> 00:17:18,070 So then, instead of sending traffic to that address, 222 00:17:18,070 --> 00:17:26,178 he starts listening on the FFO2::1:FF28:9C5A. 223 00:17:26,178 --> 00:17:30,449 He listens to that address. What's he listening for? 224 00:17:30,449 --> 00:17:34,587 Neighbor discovery messages. He's listening for somebody else 225 00:17:34,587 --> 00:17:39,258 to ask. Ask what? One or two things. 226 00:17:39,258 --> 00:17:41,761 He's looking for the other person to say, 227 00:17:41,761 --> 00:17:44,463 Hey, does anybody have this? Because I want to use it. 228 00:17:44,463 --> 00:17:47,567 And so he can basically say no. Now again, that's not 229 00:17:47,567 --> 00:17:50,236 exactly how that works. I'm using a little bit 230 00:17:50,236 --> 00:17:54,607 of poetic license there. Again, basically the other guy 231 00:17:54,607 --> 00:17:58,311 is going to send a solicited node neighbor discovery 232 00:17:58,311 --> 00:18:00,980 message for our address and we're going to 233 00:18:00,980 --> 00:18:04,750 answer and he's going to do the Dad part. He's going to 234 00:18:04,750 --> 00:18:08,454 go somebody else is already listening to that group. 235 00:18:08,454 --> 00:18:12,258 Oh, darn. He'll have to pick another address. 236 00:18:12,258 --> 00:18:17,897 This would be-- once we join this is us doing the other side 237 00:18:17,897 --> 00:18:23,603 of the Dad. We're supplying the answer. Of course, the 238 00:18:23,603 --> 00:18:26,539 other part of that goes hand in hand with it and once 239 00:18:26,539 --> 00:18:30,376 we've joined this group we honestly don't know or care 240 00:18:30,376 --> 00:18:33,679 which one we're doing. It's the same message to us. 241 00:18:33,679 --> 00:18:37,984 That would be the main purpose we went this whole discussion. 242 00:18:37,984 --> 00:18:40,686 Remember we're trying to deal with the fact that we don't have 243 00:18:40,686 --> 00:18:45,891 ARP anymore. That was to do Layer 3 to Layer 244 00:18:45,891 --> 00:18:50,429 2 address resolution. Again, somebody maybe on the 245 00:18:50,429 --> 00:18:55,301 default gateway, maybe this doesn't happen very often 246 00:18:55,301 --> 00:18:59,672 anymore, but maybe this is host to hosts traffic on the 247 00:18:59,672 --> 00:19:02,575 same segment. Maybe more on your data center with 248 00:19:02,575 --> 00:19:05,544 multi-tiered applications than it happens out on the 249 00:19:05,544 --> 00:19:09,715 client side these days. In any case, maybe this is just 250 00:19:09,715 --> 00:19:13,819 peer-to-peer traffic on the same segment not even going through 251 00:19:13,819 --> 00:19:16,956 the router. Doesn't matter who it is, they all do the same 252 00:19:16,956 --> 00:19:20,393 thing. I need to find out what your MAC address is 253 00:19:20,393 --> 00:19:24,664 if I'm going to talk to you on an Ethernet segment. 254 00:19:24,664 --> 00:19:30,169 Since I know the IPv6 address I'm trying to talk to, 255 00:19:30,169 --> 00:19:36,442 I then take the IPv6 address that is my default gateway, 256 00:19:36,442 --> 00:19:40,746 the guy I'm trying to talk to, whoever it is-- I take his IPv6 257 00:19:40,746 --> 00:19:46,385 address and again form the solicited-node multicast address 258 00:19:46,385 --> 00:19:50,189 out of that going through this exact same method. 259 00:19:50,189 --> 00:19:55,461 Then I send my neighbor discovery solicitation message 260 00:19:55,461 --> 00:20:02,702 to that address. Here's the cool part. Depending on how good 261 00:20:02,702 --> 00:20:06,672 your switch is - and I sort of mentioned this earlier - 262 00:20:06,672 --> 00:20:09,175 you may or may not have a switch that can handle 263 00:20:09,175 --> 00:20:14,513 this. This is link local multicast. It's not going to 264 00:20:14,513 --> 00:20:19,919 have IGMP joins and such for it. Therefore, IGMP snooping 265 00:20:19,919 --> 00:20:23,689 on your switch is not going to help here. There's a pretty 266 00:20:23,689 --> 00:20:27,693 good chance that this is going to actually get flooded 267 00:20:27,693 --> 00:20:31,564 by the switch to every single node on that switch - every 268 00:20:31,564 --> 00:20:36,869 single node on that VLAN. Now that's okay, though, because 269 00:20:36,869 --> 00:20:40,206 if you go back to our discussion a little bit earlier, what I 270 00:20:40,206 --> 00:20:46,011 said was let's say your switch does in fact flood this. 271 00:20:46,011 --> 00:20:50,950 The problem with broadcast is when that traffic gets to your 272 00:20:50,950 --> 00:20:54,320 network card, your network card looks at that and goes 273 00:20:54,320 --> 00:20:59,959 it's a broadcast, it's for me, process it and sends it 274 00:20:59,959 --> 00:21:06,632 up to the [OS?]. The problem is if it's not 275 00:21:06,632 --> 00:21:10,569 really for you, that just wasted your CPU. 276 00:21:10,569 --> 00:21:14,540 Here's what's cool about this. This is not a broadcast. 277 00:21:14,540 --> 00:21:19,712 Let's say this in fact does get flooded by your switch to every 278 00:21:19,712 --> 00:21:24,517 single node on the segment. When the traffic comes in, 279 00:21:24,517 --> 00:21:27,119 you've got to remember - and maybe I need to bring this 280 00:21:27,119 --> 00:21:28,721 up because maybe some of you are not aware of 281 00:21:28,721 --> 00:21:35,628 this - every multicast address, be it IPv4 or IPv6, 282 00:21:35,628 --> 00:21:44,203 gets mapped to an IP-- sorry, to a Layer 2 multicast MAC address. 283 00:21:44,203 --> 00:21:49,308 When your machine joins this solicited-node multicast group, 284 00:21:49,308 --> 00:21:55,114 he creates the corresponding multicast MAC address and 285 00:21:55,114 --> 00:22:00,419 installs that onto his network card so that when this frame 286 00:22:00,419 --> 00:22:03,055 shows up on the wire, you know, just bits 287 00:22:03,055 --> 00:22:07,159 coming in on the wire, he looks at the destination address, 288 00:22:07,159 --> 00:22:12,865 he sees the FF02::1:FF, he sees this solicited-node 289 00:22:12,865 --> 00:22:17,736 multicast address, he looks at the multicast group and 290 00:22:17,736 --> 00:22:20,506 he looks at his network card and the MAC 291 00:22:20,506 --> 00:22:24,577 addresses on the network card and he goes, this isn't for 292 00:22:24,577 --> 00:22:29,882 me, throw it away. Right there in hardware. Right there 293 00:22:29,882 --> 00:22:33,085 on the network card. Never hits the CPU or the 294 00:22:33,085 --> 00:22:37,423 device. Never hits the operating system. Why? Because that 295 00:22:37,423 --> 00:22:43,662 network card doesn't own the corresponding multicast 296 00:22:43,662 --> 00:22:50,236 MAC address. So he's going to have his unicast MAC address and 297 00:22:50,236 --> 00:22:56,942 his solicited-node multicast MAC address but he will 298 00:22:56,942 --> 00:23:03,816 not have somebody else's multicast MAC address for 299 00:23:03,816 --> 00:23:07,987 their solicited node. It means that everybody on the 300 00:23:07,987 --> 00:23:13,158 segment is going to have joined and have a unique - that's 301 00:23:13,158 --> 00:23:21,166 the key - multicast MAC address added to their [nick?]. When 302 00:23:21,166 --> 00:23:24,536 that frame comes in and I look at that MAC address, 303 00:23:24,536 --> 00:23:29,074 right there in hardware I go, This is not for me. 304 00:23:29,074 --> 00:23:33,312 This is not my MAC address. Throw it away. Of course, 305 00:23:33,312 --> 00:23:37,283 the guy who I am trying to contact, of course the opposite 306 00:23:37,283 --> 00:23:40,719 happens, right? He goes-- he looks at that. He is 307 00:23:40,719 --> 00:23:45,424 joined to that multicast MAC address. He looks 308 00:23:45,424 --> 00:23:47,726 at it and goes, Yup, this is for my MAC address. 309 00:23:47,726 --> 00:23:52,731 Bring it in. Send it on up. He sends it up to the CPU. 310 00:23:52,731 --> 00:23:56,835 The operating system, they of course look at it and see that 311 00:23:56,835 --> 00:24:00,773 this is a neighbor discovery solicitation message and go, 312 00:24:00,773 --> 00:24:05,010 Somebody is trying to get our info and he will send a neighbor 313 00:24:05,010 --> 00:24:09,848 discovery response and he will then answer. 314 00:24:09,848 --> 00:24:15,888 Whoever was trying to talk to me, now has my MAC address. 315 00:24:15,888 --> 00:24:20,659 And of course, just like ARP, his MAC address was included in 316 00:24:20,659 --> 00:24:26,432 the original communication to me. There you go. 317 00:24:26,432 --> 00:24:29,134 We'll see all this work as we start getting 318 00:24:29,134 --> 00:24:31,704 in the configuration and setting this all up. 319 00:24:31,704 --> 00:24:34,707 Not to worry. Like I said, this first lesson, I want to get 320 00:24:34,707 --> 00:24:38,010 all the theory out of the way and we'll see it as we 321 00:24:38,010 --> 00:24:41,313 go. It never hurts to see things twice anyway. This is 322 00:24:41,313 --> 00:24:45,117 all our theory and I'll show you all of the stuff working 323 00:24:45,117 --> 00:24:49,021 as we go. That's how solicited-node multicast 324 00:24:49,021 --> 00:24:52,891 works. So yeah, you're not going to be going to 325 00:24:52,891 --> 00:24:56,028 your devices and looking at ARP anymore, now you're going 326 00:24:56,028 --> 00:24:59,465 to be looking at neighbor discovery. That's the new ARP. 327 00:24:59,465 --> 00:25:01,400 [music]