WEBVTT 0:00:03.300000 --> 0:00:08.240000 All right, welcome back to an overview of IPv4, UDP, and TCP. 0:00:08.240000 --> 0:00:09.860000 This is part two. 0:00:09.860000 --> 0:00:11.760000 Let's keep going with where we left off. 0:00:11.760000 --> 0:00:14.540000 So let's talk about DHCP. 0:00:14.540000 --> 0:00:19.640000 So you know that with IPv4, a fundamental component of IPv4 is you need 0:00:19.640000 --> 0:00:23.220000 an IP address. You need some basic things just to get on a network. 0:00:23.220000 --> 0:00:24.420000 You need an IP address. 0:00:24.420000 --> 0:00:25.960000 You need a subnet mask. 0:00:25.960000 --> 0:00:29.640000 You need the IP address of a default router, or what they call a default 0:00:29.640000 --> 0:00:33.520000 gateway. And most likely you need a DNS server. 0:00:33.520000 --> 0:00:36.140000 You need the IP address of a DNS server because most of what we do these 0:00:36.140000 --> 0:00:41.400000 days involves a browser where you type in a URL like google.com or iini 0:00:41.400000 --> 0:00:45.180000 .com and that has to be resolved to an IP address. 0:00:45.180000 --> 0:00:49.120000 So you can send an IP address or you can send an IP packet to that destination. 0:00:49.120000 --> 0:00:51.000000 And it's a DNS server that does that resolution. 0:00:51.000000 --> 0:00:56.820000 Well, how does your tablet, your smartphone, your laptop get all that 0:00:56.820000 --> 0:00:58.920000 basic IP information? 0:00:58.920000 --> 0:01:03.200000 Most likely you get it this way, be it the dynamic host configuration 0:01:03.200000 --> 0:01:07.860000 protocol. Most IP devices, even things that are like internet of things 0:01:07.860000 --> 0:01:13.000000 devices like sensors and refrigerators and, you know, IP video cameras 0:01:13.000000 --> 0:01:17.020000 are by default configured for DHCP. 0:01:17.020000 --> 0:01:22.340000 Now DHCP is a client server application, which means the client is the 0:01:22.340000 --> 0:01:27.100000 device that needs the IP information, like your laptop, your smartphone, 0:01:27.100000 --> 0:01:31.420000 your tablet. And then it reaches out to a DHCP server and the DHCP server 0:01:31.420000 --> 0:01:34.100000 gives you the IP information. 0:01:34.100000 --> 0:01:37.260000 Now this is based on an older protocol called BootP. 0:01:37.260000 --> 0:01:42.680000 So if you capture DHCP transactions in like wire shark or something, a 0:01:42.680000 --> 0:01:47.480000 lot of times those wire shark packet captures will display as BootP instead 0:01:47.480000 --> 0:01:50.340000 of DHCP. So don't be alarmed by that. 0:01:50.340000 --> 0:01:55.040000 If you're trying to capture DHCP and it says BootP in your packet capture. 0:01:55.040000 --> 0:02:00.900000 Now DHCP does utilize UDP on port 67 and 68. 0:02:00.900000 --> 0:02:02.420000 So you want to be familiar with that. 0:02:02.420000 --> 0:02:05.320000 And this is a quick review of the way DHCP works. 0:02:05.320000 --> 0:02:07.700000 It's a four step process. 0:02:07.700000 --> 0:02:11.900000 So this is my DHCP client right here, which is my laptop. 0:02:11.900000 --> 0:02:14.060000 And this is my DHCP server. 0:02:14.060000 --> 0:02:18.680000 The first thing the client sends is a broadcast because after all, we 0:02:18.680000 --> 0:02:21.400000 don't even know if a DHCP server exists. 0:02:21.400000 --> 0:02:23.380000 We don't have any IP information. 0:02:23.380000 --> 0:02:29.580000 And we send what's called a DHCP discover packet. 0:02:29.580000 --> 0:02:33.020000 And this is where the client basically says, hey, I need information. 0:02:33.020000 --> 0:02:35.000000 Is there a server out there? 0:02:35.000000 --> 0:02:39.720000 Now, if there is a DHCP server, he will respond back. 0:02:39.720000 --> 0:02:41.620000 Get rid of that. 0:02:41.620000 --> 0:02:52.080000 He'll respond back as a unicast directly to you with a DHCP offer packet. 0:02:52.080000 --> 0:02:54.900000 All right. So first we had discover. 0:02:54.900000 --> 0:02:58.400000 Now we have an offer. 0:02:58.400000 --> 0:03:02.340000 And this is where he'll say, hey, here I am. 0:03:02.340000 --> 0:03:03.460000 Let me tell you about myself. 0:03:03.460000 --> 0:03:04.740000 Here's my IP address. 0:03:04.740000 --> 0:03:06.920000 Here's the information I'd like to give to you. 0:03:06.920000 --> 0:03:08.900000 Here's your client IP address. 0:03:08.900000 --> 0:03:10.740000 Here's your client subnet mask. 0:03:10.740000 --> 0:03:13.840000 Here's the IP address of a default gateway and a few other things. 0:03:13.840000 --> 0:03:17.680000 Here's the timer, the lease time of how good this IP address is good for. 0:03:17.680000 --> 0:03:19.740000 It's good for 12 hours or 24 hours. 0:03:19.740000 --> 0:03:21.640000 That's the lease. 0:03:21.640000 --> 0:03:27.060000 All right. Now at that point, the client has the option to accept or not 0:03:27.060000 --> 0:03:28.700000 accept that offer. 0:03:28.700000 --> 0:03:32.620000 In many cases, especially in larger environments like larger campus or 0:03:32.620000 --> 0:03:36.140000 enterprise networks, there's a very good chance that there might be more 0:03:36.140000 --> 0:03:38.520000 than one DHCP server out there. 0:03:38.520000 --> 0:03:40.800000 So you might receive multiple offers. 0:03:40.800000 --> 0:03:45.500000 The way that every operating system I've ever seen works is operating 0:03:45.500000 --> 0:03:49.440000 systems typically will latch on to the very first offer they get and sort 0:03:49.440000 --> 0:03:51.200000 of ignore the other ones. 0:03:51.200000 --> 0:03:52.820000 So let's assume that's the case. 0:03:52.820000 --> 0:03:56.540000 Let's assume that I as a client have received three offers or four offers 0:03:56.540000 --> 0:04:00.000000 and I want to accept the parameters that are in the first one. 0:04:00.000000 --> 0:04:03.640000 Now I need to tell that server I like your offer. 0:04:03.640000 --> 0:04:07.820000 I'd like you to reserve that stuff for me and implicitly I want to tell 0:04:07.820000 --> 0:04:10.600000 all the other servers, I don't need your offer. 0:04:10.600000 --> 0:04:13.840000 So that IP address that you guys gave me, you can put it back in your 0:04:13.840000 --> 0:04:17.440000 DHCP pool, give it to the next available person. 0:04:17.440000 --> 0:04:21.440000 So the way we do that is after we get the offer, we have to send a message 0:04:21.440000 --> 0:04:29.640000 back to the server, which is called a DHCP request. 0:04:29.640000 --> 0:04:31.860000 Now why is it called a request? 0:04:31.860000 --> 0:04:38.780000 Because even though the DHCP server has offered this to us, he has not 0:04:38.780000 --> 0:04:41.980000 formally allocated it to us. 0:04:41.980000 --> 0:04:45.120000 In other words, the DHCP server saying, hmm, I wonder if that guy got 0:04:45.120000 --> 0:04:47.980000 it. I wonder if that guy wants that information. 0:04:47.980000 --> 0:04:53.360000 And if another discover packet came in, that DHCP server could theoretically 0:04:53.360000 --> 0:04:56.000000 give that same information to somebody else. 0:04:56.000000 --> 0:04:59.480000 So the DHCP server needs to know, oh, you like it? 0:04:59.480000 --> 0:05:01.520000 Okay, I'll reserve it for you. 0:05:01.520000 --> 0:05:05.100000 I won't give that IP address and that other stuff to anybody else, it's 0:05:05.100000 --> 0:05:08.240000 yours. And so now we're sending a request saying, hey, can you please 0:05:08.240000 --> 0:05:09.500000 reserve that for me? 0:05:09.500000 --> 0:05:13.160000 I like the stuff that you gave me in your offer. 0:05:13.160000 --> 0:05:15.940000 So here we have our request. 0:05:15.940000 --> 0:05:20.480000 Another request is also a broadcast. 0:05:20.480000 --> 0:05:25.400000 So if there's any other DHCP servers out there that also sent us their 0:05:25.400000 --> 0:05:30.540000 offers, they will see this request and in this request, let's say the 0:05:30.540000 --> 0:05:33.200000 server is 1.2.3.4. 0:05:33.200000 --> 0:05:35.060000 Let's say that's the IP address of the server. 0:05:35.060000 --> 0:05:41.900000 The request will actually say something like DHCP server 1.2.3.4. 0:05:41.900000 --> 0:05:44.780000 It'll be in the body of it, in the body of the request. 0:05:44.780000 --> 0:05:49.080000 So because that's a broadcast, any other DHCP server out there will see 0:05:49.080000 --> 0:05:52.520000 that and they'll say, oh, that client is actually requesting the information 0:05:52.520000 --> 0:05:58.440000 that server 1.2.3.4 offered, not the information I offered. 0:05:58.440000 --> 0:06:03.020000 Therefore, I will put my offer back in the pool, give it to somebody else. 0:06:03.020000 --> 0:06:07.120000 And then the last step in this process is the server now has to formally 0:06:07.120000 --> 0:06:09.640000 acknowledge that, yes, that is yours. 0:06:09.640000 --> 0:06:12.380000 I will not give it to anybody else. 0:06:12.380000 --> 0:06:15.560000 And that's with a DHCP acknowledgement. 0:06:15.560000 --> 0:06:20.980000 A lot of people memorize that with the acronym of DORA for discover, offer, 0:06:20.980000 --> 0:06:22.980000 request, acknowledgement. 0:06:22.980000 --> 0:06:26.240000 Those are the four steps of DHCP. 0:06:26.240000 --> 0:06:32.680000 For IPv4. Now, once again, as a contrast with IPv6, there is something 0:06:32.680000 --> 0:06:38.620000 called DHCP V6. It also uses four steps, just like this. 0:06:38.620000 --> 0:06:42.460000 But the names of a couple of those steps are a little bit different. 0:06:42.460000 --> 0:06:46.520000 And we'll look at that more when we get to IPv6. 0:06:46.520000 --> 0:06:50.600000 Okay, so I've received my DHCP information. 0:06:50.600000 --> 0:06:53.620000 I now know that, oh, on my network, there's a router because I just got 0:06:53.620000 --> 0:06:57.200000 his default gateway IP address for my server. 0:06:57.200000 --> 0:07:01.760000 Next thing is, I need to resolve my router's MAC address. 0:07:01.760000 --> 0:07:05.740000 Because after all, as a quick review here, if this is a network, let's 0:07:05.740000 --> 0:07:09.260000 just say we have a basic network here where we have a switch. 0:07:09.260000 --> 0:07:14.920000 And we have a couple of laptops or PCs connected to that switch. 0:07:14.920000 --> 0:07:16.860000 We have a router. 0:07:16.860000 --> 0:07:21.180000 And then the rest of the network is behind that, the rest of the cloud. 0:07:21.180000 --> 0:07:27.300000 Okay. And on this network, the network administrator has decided that 0:07:27.300000 --> 0:07:32.240000 every network interface card that connects to the network is going to 0:07:32.240000 --> 0:07:37.180000 be in the, let's say, the 2.2.2.x network. 0:07:37.180000 --> 0:07:40.720000 All right, so maybe this guy here, the router will be 2.221. 0:07:40.720000 --> 0:07:43.380000 And that's a static IP address. 0:07:43.380000 --> 0:07:44.580000 That's not DHCP. 0:07:44.580000 --> 0:07:48.340000 We've configured that on the router as a static IP address, which you 0:07:48.340000 --> 0:07:49.540000 can also do on devices. 0:07:49.540000 --> 0:07:51.520000 You could go onto your smartphone. 0:07:51.520000 --> 0:07:55.240000 You could go on your tablet and manually give it an IP address. 0:07:55.240000 --> 0:07:59.000000 But because those devices are mobile and they go from one network to the 0:07:59.000000 --> 0:08:01.720000 next, doesn't really make sense to do that. 0:08:01.720000 --> 0:08:06.000000 That's why we typically rely on DHCP on those devices to dynamically obtain 0:08:06.000000 --> 0:08:10.040000 an IP address as they enter a network. 0:08:10.040000 --> 0:08:14.480000 So maybe this guy is 2222 and this guy is 2223. 0:08:14.480000 --> 0:08:19.000000 All right. Now, both those laptops PCs have learned that their default 0:08:19.000000 --> 0:08:20.500000 gateway is 2221. 0:08:20.500000 --> 0:08:24.560000 Now, this is all layer three we're talking about. 0:08:24.560000 --> 0:08:27.720000 Remember, at the OSI model, we also have the data link layer at layer 0:08:27.720000 --> 0:08:31.440000 two. And the data link layer governs things like the rules and protocols 0:08:31.440000 --> 0:08:34.540000 about how do we actually access the wire? 0:08:34.540000 --> 0:08:36.380000 One is it my time to speak? 0:08:36.380000 --> 0:08:37.980000 One is it my time to listen? 0:08:37.980000 --> 0:08:40.360000 When something, when I'm hearing something on the wire, how do I determine 0:08:40.360000 --> 0:08:43.000000 if it's for me or for somebody else? 0:08:43.000000 --> 0:08:47.160000 Layer two of the data link layer answers all those questions. 0:08:47.160000 --> 0:08:50.040000 How do I access the data, the data link? 0:08:50.040000 --> 0:08:54.740000 So most likely, the protocol running at the data link layer is probably 0:08:54.740000 --> 0:08:56.240000 going to be Ethernet. 0:08:56.240000 --> 0:09:02.680000 That's pretty much the ubiquitous protocol that you'll find in all layer 0:09:02.680000 --> 0:09:04.960000 two networks these days, which is Ethernet. 0:09:04.960000 --> 0:09:10.860000 Well, just like IP has addresses to identify different devices, Ethernet 0:09:10.860000 --> 0:09:15.160000 has addresses at layer two, and we call those MAC addresses. 0:09:15.160000 --> 0:09:17.480000 So let's write that right here. 0:09:17.480000 --> 0:09:22.460000 So every interface card comes with a MAC address. 0:09:22.460000 --> 0:09:25.340000 Now, the MAC address is not something you learn. 0:09:25.340000 --> 0:09:27.700000 The MAC address is actually burned into the card. 0:09:27.700000 --> 0:09:32.080000 When the manufacturer made that card, they pre-programmed it with a MAC 0:09:32.080000 --> 0:09:34.200000 address. And that MAC address never changes. 0:09:34.200000 --> 0:09:38.400000 So whether you are in Saudi Arabia or whether in your network in Boise, 0:09:38.400000 --> 0:09:42.140000 Idaho, or sitting in a network in the conference room in Boston, your 0:09:42.140000 --> 0:09:44.800000 MAC address of your laptop is unchangeable. 0:09:44.800000 --> 0:09:47.280000 It's always the exact same thing. 0:09:47.280000 --> 0:09:52.540000 So when an Ethernet frame is being put on an Ethernet cable, just like 0:09:52.540000 --> 0:09:56.500000 at layer three, we have a source and destination IP address at layer two, 0:09:56.500000 --> 0:10:00.800000 that IP packet is now wrapped inside of an Ethernet frame. 0:10:00.800000 --> 0:10:05.720000 And just like we took our data and we added all these IP fields to it 0:10:05.720000 --> 0:10:09.460000 that comprised our IP header, now we're going to take that whole thing, 0:10:09.460000 --> 0:10:14.100000 send it down to layer two, and add a bunch of fields that Ethernet uses. 0:10:14.100000 --> 0:10:17.340000 And just like IP had a source and destination IP address as part of the 0:10:17.340000 --> 0:10:22.780000 fields at layer two, we have a source and destination MAC address to talk 0:10:22.780000 --> 0:10:29.740000 on the network. So my laptop has just learned via DHCP that he is 2.2 0:10:29.740000 --> 0:10:32.580000 .2.2. That's me right now. 0:10:32.580000 --> 0:10:35.780000 Well, if I'm going to send an Ethernet frame to the router, because ultimately 0:10:35.780000 --> 0:10:39.520000 I need to get out here, this is where I'm trying to get some website or 0:10:39.520000 --> 0:10:42.320000 something. So I need to go through my router to do that. 0:10:42.320000 --> 0:10:45.240000 Well, then that means I need to send an Ethernet frame to my router, which 0:10:45.240000 --> 0:10:49.920000 means I need to know my router's MAC address to be able to get frames 0:10:49.920000 --> 0:10:52.300000 to him so he knows how to pick them up. 0:10:52.300000 --> 0:10:53.520000 How do I do that? 0:10:53.520000 --> 0:10:57.480000 After all, I learned via DHCP that he is 2.2.1. 0:10:57.480000 --> 0:10:59.140000 So I've got that layer three. 0:10:59.140000 --> 0:11:00.800000 How do I get his layer two? 0:11:00.800000 --> 0:11:05.840000 Now we need some other dynamic protocol that can basically discover that. 0:11:05.840000 --> 0:11:11.180000 And that dynamic protocol is the address resolution protocol or ARP. 0:11:11.180000 --> 0:11:12.740000 That's what it's used for. 0:11:12.740000 --> 0:11:17.500000 So my particular case, my laptop was sent out what's called an ARP request, 0:11:17.500000 --> 0:11:20.540000 which is once again a broadcast on my wire. 0:11:20.540000 --> 0:11:22.860000 Everybody on my wire would see that. 0:11:22.860000 --> 0:11:27.680000 And inside the body of the ARP request would say, Hey, I am 2.2.2.2. 0:11:27.680000 --> 0:11:29.660000 I'm looking for 2.2.1. 0:11:29.660000 --> 0:11:33.020000 If you're out there, I need to know your MAC address. 0:11:33.020000 --> 0:11:37.820000 And then the router who is out there would send an ARP reply back to me, 0:11:37.820000 --> 0:11:40.780000 not as a broadcast, but as a unicast just to me. 0:11:40.780000 --> 0:11:45.760000 So everybody on my LAN and my local area network will see ARP requests, 0:11:45.760000 --> 0:11:50.100000 but only the originator of the ARP request actually sees their return. 0:11:50.100000 --> 0:11:54.480000 ARP reply. And that's when the router can say, Hey, I'm 2.2.1 and here's 0:11:54.480000 --> 0:11:58.220000 my MAC address. So that's how ARP works. 0:11:58.220000 --> 0:12:01.440000 Proxy are probably not going to see this a whole lot. 0:12:01.440000 --> 0:12:03.580000 And it's not really a good thing. 0:12:03.580000 --> 0:12:10.780000 Proxy ARP is like a fix to a design flaw, which is something like this. 0:12:10.780000 --> 0:12:13.720000 Let's say, let me just draw it like this. 0:12:13.720000 --> 0:12:21.520000 Let's say here that we had a PC connected to a switch that has some other 0:12:21.520000 --> 0:12:25.200000 devices on it, which is connected to a router. 0:12:25.200000 --> 0:12:29.760000 All right. And then down here, he's connected to another switch, which 0:12:29.760000 --> 0:12:31.340000 has got some devices on it. 0:12:31.340000 --> 0:12:36.000000 Now the router, we know his IP addresses are statically configured. 0:12:36.000000 --> 0:12:41.620000 So he says, OK, on this link, the network I'm connected to is the 2.2 0:12:41.620000 --> 0:12:43.240000 .x network, right? 0:12:43.240000 --> 0:12:45.480000 That's the network slash 24. 0:12:45.480000 --> 0:12:47.020000 That's a subnet mask. 0:12:47.020000 --> 0:12:54.040000 And on this link right here, the network I'm connected to is the 2.2.3 0:12:54.040000 --> 0:12:58.600000 .x network. That's the network I'm connected to right there. 0:12:58.600000 --> 0:13:00.000000 So he knows that. 0:13:00.000000 --> 0:13:05.460000 Now the person on this laptop right here, they decide to get smart, build 0:13:05.460000 --> 0:13:08.980000 it funny, and they statically configure their IP address instead of relying 0:13:08.980000 --> 0:13:12.100000 on IP on instead of relying on DHCP. 0:13:12.100000 --> 0:13:14.300000 But they did it wrong. 0:13:14.300000 --> 0:13:18.480000 You see, they gave themselves the address of, let's say, 2.2.2. 0:13:18.480000 --> 0:13:23.000000 maybe 7. And maybe this guy right here is 2.2.1. 0:13:23.000000 --> 0:13:24.180000 That's the router. 0:13:24.180000 --> 0:13:25.560000 But here's where they made the mistake. 0:13:25.560000 --> 0:13:30.440000 They should have given themselves a subnet mask of a slash 24, which we 0:13:30.440000 --> 0:13:36.360000 know in dotted decimal is 255.255.0. 0:13:36.360000 --> 0:13:38.220000 That is equal to a slash 24. 0:13:38.220000 --> 0:13:39.720000 But they made a mistake. 0:13:39.720000 --> 0:13:55.380000 And they gave themselves this subnet mask, 255.0.0.0. 0:13:55.380000 --> 0:13:59.820000 Which means he thinks anytime I need to send a packet to anything beginning 0:13:59.820000 --> 0:14:03.220000 with 2, that is on my wire. 0:14:03.220000 --> 0:14:05.260000 I don't need to go the router for that. 0:14:05.260000 --> 0:14:08.660000 I can just arc for that guy directly and speak to him directly because 0:14:08.660000 --> 0:14:11.560000 he's on this side of the router with me. 0:14:11.560000 --> 0:14:13.420000 But that's not necessarily true. 0:14:13.420000 --> 0:14:18.360000 So what if this guy right here who's 2, 2, 2, 7 tries to talk to this 0:14:18.360000 --> 0:14:24.140000 guy down here in the lower right hand corner who is 2.2.3.10? 0:14:24.140000 --> 0:14:29.120000 Well, that guy's on a completely different network because in reality, 0:14:29.120000 --> 0:14:32.880000 on the left side, this is 2, 2, 2. 0:14:32.880000 --> 0:14:36.080000 On the right side, this is 2, 2, 3. 0:14:36.080000 --> 0:14:38.040000 But my laptop doesn't know that. 0:14:38.040000 --> 0:14:39.980000 He thinks everything on his network starts with 2. 0:14:39.980000 --> 0:14:41.120000 So guess what he's going to do? 0:14:41.120000 --> 0:14:43.520000 He's going to sound on an ARP request. 0:14:43.520000 --> 0:14:49.780000 An ARP request for 2, 2, 3.10. 0:14:49.780000 --> 0:14:51.920000 Because he says, hey, that's on my network. 0:14:51.920000 --> 0:14:52.880000 I can arc for him. 0:14:52.880000 --> 0:15:10.760000 Which by the way, that's a key thing to remember about ARP. 0:15:10.760000 --> 0:15:13.780000 I don't know where you are, but there's one thing I do know. 0:15:13.780000 --> 0:15:15.500000 You're not on my local land. 0:15:15.500000 --> 0:15:18.620000 You're not here in Kerry, North Carolina with me in the INE office. 0:15:18.620000 --> 0:15:20.060000 You're somewhere else. 0:15:20.060000 --> 0:15:22.420000 So if I'm going to send a packet to you that's wrapped in an Ethernet 0:15:22.420000 --> 0:15:26.320000 header, I'm not going to be sending it to your MAC address. 0:15:26.320000 --> 0:15:28.840000 Because the only MAC addresses I put in my Ethernet header are MAC addresses 0:15:28.840000 --> 0:15:29.820000 on my local land. 0:15:29.820000 --> 0:15:32.600000 So I'm going to send to the MAC address of my router. 0:15:32.600000 --> 0:15:36.300000 And then my router will replace that MAC address with a MAC address of 0:15:36.300000 --> 0:15:40.600000 the next router and the next router until ultimately that packet gets 0:15:40.600000 --> 0:15:44.600000 to you. But because you're not on my land, I don't even care what your 0:15:44.600000 --> 0:15:49.020000 MAC address is. But the only time you ARP for something is when you know 0:15:49.020000 --> 0:15:53.940000 that the destination you're trying to reach is on your local area network. 0:15:53.940000 --> 0:15:57.320000 If you know, if you say, hey, here's my IP address, here's the IP address 0:15:57.320000 --> 0:15:58.680000 I'm trying to get to. 0:15:58.680000 --> 0:16:01.060000 We're not the same, different network. 0:16:01.060000 --> 0:16:03.200000 Then you say, I'm not going to ARP for this guy because he's not on my 0:16:03.200000 --> 0:16:05.400000 land. I'll just go through my router. 0:16:05.400000 --> 0:16:12.740000 Well, here my laptop at 2227, because he thinks that 2223 is on his network, 0:16:12.740000 --> 0:16:15.620000 anything beginning with 2, he's going to ARP for him. 0:16:15.620000 --> 0:16:17.780000 Now, normally this would fail, right? 0:16:17.780000 --> 0:16:19.520000 Because an ARP is a broadcast. 0:16:19.520000 --> 0:16:22.060000 And when routers get broadcast, they go, bloop, kill it. 0:16:22.060000 --> 0:16:27.480000 It's done. So that ARP request would never get a response unless proxy 0:16:27.480000 --> 0:16:30.840000 ARP is turned on on the router. 0:16:30.840000 --> 0:16:34.440000 So if this router is configured for proxy ARP, which I believe it's not 0:16:34.440000 --> 0:16:40.080000 on by default, I believe the way you do that is if the global configuration 0:16:40.080000 --> 0:16:48.280000 lovely to say IP proxy-ARP. 0:16:48.280000 --> 0:16:50.020000 Well, what's that going to do? 0:16:50.020000 --> 0:16:55.920000 Now, when the router gets an ARP request, instead of saying, oh, this 0:16:55.920000 --> 0:17:00.080000 isn't for me, this person is not ARPing for me directly, it'll say, oh, 0:17:00.080000 --> 0:17:04.120000 well, it's not for me, but do I know how to reach this destination? 0:17:04.120000 --> 0:17:05.920000 It'll go into his routing table. 0:17:05.920000 --> 0:17:09.340000 It'll say, do I have a route for the destination this person's ARPing 0:17:09.340000 --> 0:17:11.340000 for? And in this case, it'll say, oh, yeah, I do. 0:17:11.340000 --> 0:17:15.160000 Actually, I'm directly connected to the 223 network. 0:17:15.160000 --> 0:17:18.820000 So now the router will actually send an ARP reply. 0:17:18.820000 --> 0:17:23.960000 Notice we're not actually forwarding that ARP request onto another segment. 0:17:23.960000 --> 0:17:25.300000 We can't do that. 0:17:25.300000 --> 0:17:30.460000 But the router will say, hey, my MAC address is AABB. 0:17:30.460000 --> 0:17:33.800000 I'll just put that in the ARP reply. 0:17:33.800000 --> 0:17:38.500000 I will pretend like I am 22310, even though that's not really me. 0:17:38.500000 --> 0:17:40.440000 And I'll reply on behalf. 0:17:40.440000 --> 0:17:42.760000 I will proxy that guy. 0:17:42.760000 --> 0:17:48.340000 So now this laptop over here on the left, in his ARP table, he will believe 0:17:48.340000 --> 0:17:58.540000 that 22310 is equal to the MAC address of AABB, which in reality is the 0:17:58.540000 --> 0:17:59.900000 router's MAC address. 0:17:59.900000 --> 0:18:05.160000 And so now when that laptop sends his data to 22310, he'll use a destination 0:18:05.160000 --> 0:18:10.460000 MAC address of AABB, which is what he should have been using all along. 0:18:10.460000 --> 0:18:12.160000 That's his router's MAC address. 0:18:12.160000 --> 0:18:14.860000 So that's what proxy ARP does. 0:18:14.860000 --> 0:18:17.920000 And like I said, this is a design flaw, right? 0:18:17.920000 --> 0:18:20.660000 That guy on the left should never have been statically configured with 0:18:20.660000 --> 0:18:25.380000 an IP address. And if he was, he should have been given the correct mask. 0:18:25.380000 --> 0:18:28.780000 But because he didn't have the correct subnet mask, we had to rely on 0:18:28.780000 --> 0:18:32.980000 proxy ARP to fill in the information that the laptop did not know. 0:18:32.980000 --> 0:18:35.180000 He didn't know he was on the wrong network. 0:18:35.180000 --> 0:18:36.720000 Well, not the wrong network. 0:18:36.720000 --> 0:18:43.480000 He just, he wasn't able to identify the correct network that he was on. 0:18:43.480000 --> 0:18:46.920000 And we talked a little bit about DNS. 0:18:46.920000 --> 0:18:53.140000 DNS is how your laptop or tablet or smartphone resolves a name to an IP 0:18:53.140000 --> 0:18:58.100000 address. So when you bring up a web browser and you type Google.com, you're 0:18:58.100000 --> 0:19:03.600000 sending out a UDP packet to destination port 53 to a DNS server. 0:19:03.600000 --> 0:19:07.680000 You have learned about that DNS server via DHCP. 0:19:07.680000 --> 0:19:10.460000 That's how you know where the DNS server is. 0:19:10.460000 --> 0:19:12.060000 And then you see that DNS server. 0:19:12.060000 --> 0:19:16.100000 Hey, can you tell me what the IP address is of Google.com? 0:19:16.100000 --> 0:19:18.780000 And then the DNS server will respond back saying, Hey, here it is. 0:19:18.780000 --> 0:19:19.960000 Here's the IP address. 0:19:19.960000 --> 0:19:23.300000 And now you can actually send your real IP packet to the destination because 0:19:23.300000 --> 0:19:26.900000 you've learned what his IP address is. 0:19:26.900000 --> 0:19:32.660000 So in IP before you as the host are sending out an A record query, A record 0:19:32.660000 --> 0:19:33.860000 meaning address record. 0:19:33.860000 --> 0:19:35.640000 I'm trying to find the address. 0:19:35.640000 --> 0:19:45.740000 And you get an A record query response back, hopefully from the DNS server. 0:19:45.740000 --> 0:19:49.460000 All right, so let's go on here. 0:19:49.460000 --> 0:19:53.380000 So we're sort of like bouncing up and down the OSI stack at this point. 0:19:53.380000 --> 0:19:55.320000 So we start out at layer three. 0:19:55.320000 --> 0:19:58.700000 We went down to layer two temporarily to talk about MAC addresses and 0:19:58.700000 --> 0:20:02.560000 ARP. Now we're going to go back up the stack to layer for the transport 0:20:02.560000 --> 0:20:06.560000 layer. And now we're going to look at the two most common protocols of 0:20:06.560000 --> 0:20:10.500000 the transport layer that are used to transport your data. 0:20:10.500000 --> 0:20:16.200000 First one is UDP, which stands for the user datagram protocol. 0:20:16.200000 --> 0:20:18.280000 The next one is TCP. 0:20:18.280000 --> 0:20:26.220000 Now between UDP and TCP, TCP is by far used more often than UDP. 0:20:26.220000 --> 0:20:29.760000 Why is that? Well, because of this one reason right here. 0:20:29.760000 --> 0:20:33.660000 UDP is connectionless, just like IP, right? 0:20:33.660000 --> 0:20:38.480000 We define that connectionless protocol is defined as a protocol that number 0:20:38.480000 --> 0:20:43.380000 one does not check to see if the destination is alive. 0:20:43.380000 --> 0:20:46.940000 It just assumes the destination is there and ready to go. 0:20:46.940000 --> 0:20:50.560000 And number two, when it sends data that destination, it doesn't check 0:20:50.560000 --> 0:20:52.820000 to see if that data actually got there. 0:20:52.820000 --> 0:20:55.100000 It just assumes the data got there. 0:20:55.100000 --> 0:20:58.260000 That's the characteristics of a connectionless protocol. 0:20:58.260000 --> 0:21:02.340000 And both IP and above it, UDP are like that. 0:21:02.340000 --> 0:21:04.160000 So what does UDP do? 0:21:04.160000 --> 0:21:09.420000 Well, UDP basically just allows you to do multiplexing by adding UDP source 0:21:09.420000 --> 0:21:11.680000 and destination port numbers. 0:21:11.680000 --> 0:21:16.260000 So there's lots of protocols that can use UDP. 0:21:16.260000 --> 0:21:22.960000 So ones that you should probably know are TFTP, trivial file transport 0:21:22.960000 --> 0:21:26.720000 protocol. And of course, we just learned about one just a moment ago, 0:21:26.720000 --> 0:21:32.860000 DNS. So if I have an IP packet, let's say I have two IP packets. 0:21:32.860000 --> 0:21:35.700000 Here's one. And here's two. 0:21:35.700000 --> 0:21:38.600000 All right. And here's my IP header. 0:21:38.600000 --> 0:21:40.940000 And we've learned about that. 0:21:40.940000 --> 0:21:43.600000 And so here is my data. 0:21:43.600000 --> 0:21:47.020000 There's my data. 0:21:47.020000 --> 0:21:53.260000 Now, the one on the right is the data in here is DNS. 0:21:53.260000 --> 0:21:59.580000 And the one on the left, the data is TFTP. 0:21:59.580000 --> 0:22:06.740000 Okay. Now, let's say that both of these packets are destined for the same 0:22:06.740000 --> 0:22:10.180000 guy. Here's a server right here. 0:22:10.180000 --> 0:22:15.880000 And that physical server is actually providing both DNS services as well 0:22:15.880000 --> 0:22:18.200000 as TFTP services. 0:22:18.200000 --> 0:22:21.540000 Okay. Well, here it comes in two IP packets. 0:22:21.540000 --> 0:22:27.460000 How, how can we tell his CPU, hey, this packet is meant for your DNS process. 0:22:27.460000 --> 0:22:30.360000 This packet is meant for your TFTP process. 0:22:30.360000 --> 0:22:35.180000 Well, because both these packets are using UDP and the UDP header, we 0:22:35.180000 --> 0:22:37.900000 have a destination port number. 0:22:37.900000 --> 0:22:46.380000 So our UDP destination in this one would have a destination of 53. 0:22:46.380000 --> 0:22:49.900000 That's what DNS uses. 0:22:49.900000 --> 0:22:57.760000 And our UDP destination port number in this one would be 69. 0:22:57.760000 --> 0:23:01.880000 Sort of running out of room here, but 69 because that's the reserve port 0:23:01.880000 --> 0:23:03.960000 number for TFTP. 0:23:03.960000 --> 0:23:14.440000 So all these well known protocols, you know, HTTP, SSL, TLS, you know, 0:23:14.440000 --> 0:23:19.900000 TFTP, FTP, they all have well known reserve port numbers. 0:23:19.900000 --> 0:23:25.660000 So that the layer four header can identify what protocol is actually carrying. 0:23:25.660000 --> 0:23:29.060000 And that's basically all that UDP does is it provides a placeholder for 0:23:29.060000 --> 0:23:31.060000 our source and destination port numbers. 0:23:31.060000 --> 0:23:34.820000 The source number is usually what's called an ephemeral port number, a 0:23:34.820000 --> 0:23:37.680000 port number that's dynamically derived. 0:23:37.680000 --> 0:23:40.620000 You can't really predict it in advance. 0:23:40.620000 --> 0:23:47.920000 So where you would typically find UDP, the most common applications would 0:23:47.920000 --> 0:23:50.780000 be voiced over IP. 0:23:50.780000 --> 0:23:56.160000 That uses UDP. That's the most common application for UDP. 0:23:56.160000 --> 0:24:00.580000 We also know that DNS uses it. 0:24:00.580000 --> 0:24:02.860000 And some file transfer protocols. 0:24:02.860000 --> 0:24:03.860000 But here's the deal. 0:24:03.860000 --> 0:24:06.940000 When you're transferring files from a client to a server, like a client 0:24:06.940000 --> 0:24:11.140000 is pushing up a file to a server or downloading a file from a server, 0:24:11.140000 --> 0:24:13.480000 you have two options to do that. 0:24:13.480000 --> 0:24:18.080000 You could use UDP and you could use, for example, something like TFTP, 0:24:18.080000 --> 0:24:26.380000 which uses UDP. Or you could use something like FTP, the file transfer 0:24:26.380000 --> 0:24:29.860000 protocol, which uses TCP. 0:24:29.860000 --> 0:24:34.060000 As we're going to see here in just the next slide, most people prefer 0:24:34.060000 --> 0:24:39.620000 FTP because TCP is connection oriented. 0:24:39.620000 --> 0:24:43.500000 It does verify that the destination exists before it does anything. 0:24:43.500000 --> 0:24:46.860000 When it sends data to that destination, it acknowledges it and makes sure 0:24:46.860000 --> 0:24:48.320000 the data actually got there. 0:24:48.320000 --> 0:24:54.180000 So because TCP is much more reliable than UDP, although you do have options 0:24:54.180000 --> 0:24:58.500000 for file transfer with either one of them, most people would probably 0:24:58.500000 --> 0:25:03.160000 choose the TCP option because they want the reliability that TCP has. 0:25:03.160000 --> 0:25:09.600000 All right, so let's talk real briefly here about TCP. 0:25:09.600000 --> 0:25:13.520000 This is also at the layer for the OSI model. 0:25:13.520000 --> 0:25:18.180000 Like UDP, like IP, it adds a bunch of headers to stuff and let's go through 0:25:18.180000 --> 0:25:19.860000 those headers real quickly. 0:25:19.860000 --> 0:25:22.620000 So it provides a source and destination port number. 0:25:22.620000 --> 0:25:26.020000 Once again, the source port number from the client is usually in a femoral 0:25:26.020000 --> 0:25:29.520000 port number, not always, but 90% of the time it is. 0:25:29.520000 --> 0:25:30.860000 So you can't predict what it is. 0:25:30.860000 --> 0:25:33.700000 It's just a random number that's generated. 0:25:33.700000 --> 0:25:37.820000 We also have a sequence number and an acknowledgement number. 0:25:37.820000 --> 0:25:40.300000 This is how TCP is connection oriented. 0:25:40.300000 --> 0:25:43.640000 Remember, I said that connection oriented means that not only do I verify 0:25:43.640000 --> 0:25:46.860000 that the destination exists before I send anything. 0:25:46.860000 --> 0:25:51.520000 Once I start sending data, I need verification that the data got there. 0:25:51.520000 --> 0:25:55.060000 And so we use sequence numbers and acknowledgement numbers to do that. 0:25:55.060000 --> 0:25:59.320000 We also have a header length, some reserve bits, control flags. 0:25:59.320000 --> 0:26:03.940000 So the control flags are what we use to verify that the destination actually 0:26:03.940000 --> 0:26:04.840000 exists ahead of time. 0:26:04.840000 --> 0:26:08.020000 And this is one thing about TCP you should be familiar with. 0:26:08.020000 --> 0:26:13.920000 All of TCP transactions, any protocol, any protocol that uses TCP as this 0:26:13.920000 --> 0:26:18.200000 underlying transport mechanism has to start out with something called 0:26:18.200000 --> 0:26:22.660000 the TCP three way handshake. 0:26:22.660000 --> 0:26:32.540000 Okay, and he uses the control flags to do this. 0:26:32.540000 --> 0:26:35.540000 So just a real high level overview of this because we've gone into more 0:26:35.540000 --> 0:26:37.520000 details and other videos about this. 0:26:37.520000 --> 0:26:42.460000 The way this works is if I'm a laptop and I've got some data to send to, 0:26:42.460000 --> 0:26:44.020000 let's say, a website. 0:26:44.020000 --> 0:26:46.320000 Okay, maybe my data is just a request. 0:26:46.320000 --> 0:26:48.060000 Hey, give me your home page. 0:26:48.060000 --> 0:26:53.380000 Right. So I've built this HTTP request saying get I need calm. 0:26:53.380000 --> 0:26:54.460000 I need I need calm. 0:26:54.460000 --> 0:26:58.360000 Well, before I even send that, once I resolve the IP address of I need 0:26:58.360000 --> 0:27:03.460000 calm. I will create a TCP header where there's basically nothing in the 0:27:03.460000 --> 0:27:05.580000 data and the TCP header. 0:27:05.580000 --> 0:27:07.340000 I will use a control flag. 0:27:07.340000 --> 0:27:12.700000 Called the sin control flag, which means I want to synchronize with you. 0:27:12.700000 --> 0:27:13.860000 Are you actually there? 0:27:13.860000 --> 0:27:18.680000 Do you exist? So I'll send a TCP sin message. 0:27:18.680000 --> 0:27:23.640000 And because this is TCP will be some sequence number in it. 0:27:23.640000 --> 0:27:26.680000 Like sequence number, let's say one. 0:27:26.680000 --> 0:27:31.200000 If that device is actually alive, he will send me. 0:27:31.200000 --> 0:27:34.680000 Well, first of all, there'll be an act in here. 0:27:34.680000 --> 0:27:38.760000 So he'll say, okay, I acknowledge your one actually he'll acknowledge 0:27:38.760000 --> 0:27:42.200000 like to he'll say, hey, I got your one. 0:27:42.200000 --> 0:27:43.840000 I'm expecting to next. 0:27:43.840000 --> 0:27:45.520000 That's how the act works. 0:27:45.520000 --> 0:27:48.920000 And he'll say, oh, I'm also doing a sin. 0:27:48.920000 --> 0:27:50.840000 This is called a sin plus act. 0:27:50.840000 --> 0:27:52.900000 I'd like to synchronize with you. 0:27:52.900000 --> 0:27:58.720000 And when I talk to you, maybe I'll start out with sequence number seven. 0:27:58.720000 --> 0:28:01.540000 So the first message was a sin. 0:28:01.540000 --> 0:28:05.880000 Next one had a sin plus act. 0:28:05.880000 --> 0:28:11.580000 And now the third message in that handshake is where we send an act back. 0:28:11.580000 --> 0:28:14.380000 We said, okay, you start out with seven. 0:28:14.380000 --> 0:28:17.620000 So I'm acknowledging eight, meaning I got your seven. 0:28:17.620000 --> 0:28:19.920000 I'm expecting eight next. 0:28:19.920000 --> 0:28:22.900000 So that's what we call the TCP three way handshake. 0:28:22.900000 --> 0:28:27.440000 First message that goes out just the sin control flag is set. 0:28:27.440000 --> 0:28:30.120000 Then we get a sin plus act back. 0:28:30.120000 --> 0:28:32.020000 Followed by an act. 0:28:32.020000 --> 0:28:33.520000 And now we know several things. 0:28:33.520000 --> 0:28:35.440000 We know the destinations alive. 0:28:35.440000 --> 0:28:36.600000 We're communicating. 0:28:36.600000 --> 0:28:39.780000 And we've set up our initial sequence numbers and a few other initial 0:28:39.780000 --> 0:28:44.480000 things that see the TCP needs in order to make that transaction connection 0:28:44.480000 --> 0:28:49.520000 oriented. All that uses the control flags. 0:28:49.520000 --> 0:28:52.320000 In addition, we've got the window size. 0:28:52.320000 --> 0:28:56.400000 This is how we negotiate while we're talking during our conversation of, 0:28:56.400000 --> 0:28:59.600000 you know, a thousand or a million packets that we're going to exchange. 0:28:59.600000 --> 0:29:03.440000 We're also constantly updating each other saying, Hey, this is the most 0:29:03.440000 --> 0:29:06.680000 amount of TCP segments I can receive at one time. 0:29:06.680000 --> 0:29:12.000000 And that can grow or shrink depending on how many other TCP transactions 0:29:12.000000 --> 0:29:15.780000 I also have going on simultaneously. 0:29:15.780000 --> 0:29:18.260000 So the window size indicates that. 0:29:18.260000 --> 0:29:23.260000 Then we also have a checksum and urgent pointer and then some TCP options, 0:29:23.260000 --> 0:29:27.860000 if any, followed by our payload. 0:29:27.860000 --> 0:29:31.520000 All right, another very common protocol you're going to see, and this 0:29:31.520000 --> 0:29:35.360000 is primarily used for troubleshooting is the Internet control message 0:29:35.360000 --> 0:29:37.740000 protocol or ICMP. 0:29:37.740000 --> 0:29:39.620000 Let's talk about this. 0:29:39.620000 --> 0:29:45.180000 So this was originally defined in RFC 777. 0:29:45.180000 --> 0:29:48.680000 Now a lot of people, when they think of ICMP, the first thing that comes 0:29:48.680000 --> 0:29:49.640000 to their mind is ping. 0:29:49.640000 --> 0:29:55.180000 And that is primarily the primary use of ICMP, but ICMP can do a lot more 0:29:55.180000 --> 0:29:59.500000 than that. You see an ICP message, if we actually broke it down an ICP 0:29:59.500000 --> 0:30:03.340000 message, we would see that within the ICMP header. 0:30:03.340000 --> 0:30:08.580000 So we got our IP header right behind the IP header is the ICMP header. 0:30:08.580000 --> 0:30:10.720000 So ICMP is its own separate thing. 0:30:10.720000 --> 0:30:15.680000 It doesn't rely on TCP or UDP is its own separate protocol sitting right 0:30:15.680000 --> 0:30:17.520000 behind the IP header. 0:30:17.520000 --> 0:30:22.400000 So in the ICMP header, there's a type value, which says, Hey, let me tell 0:30:22.400000 --> 0:30:25.780000 you what I'm doing because ICMP can do all sorts of things like we see 0:30:25.780000 --> 0:30:30.460000 here. A ping when you typically ping something. 0:30:30.460000 --> 0:30:34.720000 If I, for example, ping like 777 because I want to see if that device 0:30:34.720000 --> 0:30:35.620000 is actually alive. 0:30:35.620000 --> 0:30:41.640000 Is it there when I type in ping 777, what I'm actually sending out is 0:30:41.640000 --> 0:30:47.120000 an ICMP echo request, which is a specific type of ICMP. 0:30:47.120000 --> 0:30:49.280000 I don't know what that type number is. 0:30:49.280000 --> 0:30:52.800000 You'll never have to memorize it, but just know there's a type code for 0:30:52.800000 --> 0:30:58.320000 echo request. If that guy is alive and if he's enabled for ICMP, he will 0:30:58.320000 --> 0:31:03.180000 send me back an echo reply, which is a different type of type number. 0:31:03.180000 --> 0:31:05.040000 That's how I know he's there. 0:31:05.040000 --> 0:31:06.460000 But there's other stuff as well. 0:31:06.460000 --> 0:31:09.900000 For example, there's an ICMP redirect. 0:31:09.900000 --> 0:31:13.280000 Let's say, for example, this type of thing. 0:31:13.280000 --> 0:31:16.720000 Let's say that. Back to here. 0:31:16.720000 --> 0:31:17.900000 Come on. There we are. 0:31:17.900000 --> 0:31:20.200000 All right. So let's say this is me. 0:31:20.200000 --> 0:31:25.000000 And I'm 1111 connected to my switch. 0:31:25.000000 --> 0:31:31.440000 Here's my default gateway, which is 1112. 0:31:31.440000 --> 0:31:35.820000 And let's say connected the same switch is another router. 0:31:35.820000 --> 0:31:37.120000 He's not my default gateway. 0:31:37.120000 --> 0:31:41.360000 I might not even know he exists. 0:31:41.360000 --> 0:31:47.960000 He's 1113. Now, both of these routers are connected to some networks. 0:31:47.960000 --> 0:31:51.540000 All right. And let's say they're actually, they're talking. 0:31:51.540000 --> 0:31:54.740000 All right. So these two routers know what each other knows. 0:31:54.740000 --> 0:31:57.760000 They're running some sort of routing protocol like rip or OSPF. 0:31:57.760000 --> 0:32:00.440000 And let's just say this guy on the top is router one. 0:32:00.440000 --> 0:32:02.960000 And this guy is default gateway number two. 0:32:02.960000 --> 0:32:11.540000 So router one has learned about the four, four, four, zero network. 0:32:11.540000 --> 0:32:16.100000 And default gateway number two, he's learned that the four, four, four, 0:32:16.100000 --> 0:32:22.300000 zero network is reachable via router one. 0:32:22.300000 --> 0:32:26.600000 Okay. So if the default gateway ever gets a packet going to four, four, 0:32:26.600000 --> 0:32:29.460000 four, anything, he's going to forward that packet to router one. 0:32:29.460000 --> 0:32:31.680000 Now here I am on my laptop. 0:32:31.680000 --> 0:32:37.420000 All of a sudden I start sending some packets to my default gateway. 0:32:37.420000 --> 0:32:43.580000 And their destination is four, four, four dot 99. 0:32:43.580000 --> 0:32:47.680000 Well, my default gateway can handle that. 0:32:47.680000 --> 0:32:50.100000 He knows where that is, but he says, Hey, you know what? 0:32:50.100000 --> 0:32:53.880000 There's actually another router on your exact same network that can get 0:32:53.880000 --> 0:32:54.680000 there better than me. 0:32:54.680000 --> 0:32:57.260000 As a matter of fact, this router, when he gets it, he's just going to 0:32:57.260000 --> 0:32:59.680000 relay those packets to router one. 0:32:59.680000 --> 0:33:04.040000 So what that route, what the default gateway is going to do is he'll actually 0:33:04.040000 --> 0:33:05.840000 send back to me. 0:33:05.840000 --> 0:33:10.700000 An ICMP redirect message. 0:33:10.700000 --> 0:33:15.900000 And say, Hey, in the future, if you need to get to the four, four, four, 0:33:15.900000 --> 0:33:19.300000 four, 99 address, you should go. 0:33:19.300000 --> 0:33:24.560000 To one one one three, you should use him, not me, because he's a better 0:33:24.560000 --> 0:33:29.160000 path. Then I am to get to that same network. 0:33:29.160000 --> 0:33:31.100000 That's another thing ICMP can do. 0:33:31.100000 --> 0:33:34.360000 It can redirect you to another router who's on the same network as you 0:33:34.360000 --> 0:33:37.920000 who's got a better path to that destination. 0:33:37.920000 --> 0:33:47.780000 There's also ICMP host unreachable. 0:33:47.780000 --> 0:33:52.880000 If, uh, if you're trying to send packs through a network and let's say 0:33:52.880000 --> 0:33:58.680000 that some device in that network, um, has some sort of restrictions like 0:33:58.680000 --> 0:34:02.520000 an access list or some sort of filter that's blocking you from getting 0:34:02.520000 --> 0:34:04.180000 to that destination. 0:34:04.180000 --> 0:34:06.760000 Well, that device, that firewall or whatever it is in the middle of the 0:34:06.760000 --> 0:34:08.820000 network might drop your packets. 0:34:08.820000 --> 0:34:13.520000 And as a courtesy, he might send an ICMP host unreachable message back 0:34:13.520000 --> 0:34:16.040000 to you saying, sorry, can't get there. 0:34:16.040000 --> 0:34:22.200000 So you can see here that ICMP can be used for all sorts of different things. 0:34:22.200000 --> 0:34:28.380000 So that concludes this particular video on TCP, UDP and a couple of other 0:34:28.380000 --> 0:34:31.120000 IP related services that we've just looked at.