WEBVTT 0:00:02.660000 --> 0:00:06.800000 Hello and welcome to this video titled the dynamic host configuration 0:00:06.800000 --> 0:00:13.760000 protocol DHCP. In this video I'm going to talk about how IP information 0:00:13.760000 --> 0:00:19.820000 is obtained. I'm going to introduce you to DHCP and how it works, specifically 0:00:19.820000 --> 0:00:22.240000 with relationship to DORA. 0:00:22.240000 --> 0:00:23.940000 That's the IPv4 equivalent. 0:00:23.940000 --> 0:00:29.360000 We all will also briefly look at the IPv6 steps for DHCP. 0:00:29.360000 --> 0:00:33.180000 We'll talk about some other types of DHCP packets that you don't see as 0:00:33.180000 --> 0:00:36.980000 often, but you should be familiar with their names and their operation. 0:00:36.980000 --> 0:00:42.680000 The necessity of the Internet protocol. 0:00:42.680000 --> 0:00:48.380000 We know that pretty much every network these days is an IP-based network. 0:00:48.380000 --> 0:00:51.980000 In other words, if you want to gain the services or data or information 0:00:51.980000 --> 0:00:56.660000 from a remote device, you need to know that device's IP address. 0:00:56.660000 --> 0:01:01.400000 You need to have an IP address so you can create IP packets that traverse 0:01:01.400000 --> 0:01:06.000000 the network to go to and from you and that remote destination. 0:01:06.000000 --> 0:01:10.760000 Clearly, your system, whether it be a smartphone, tablet, laptop, needs 0:01:10.760000 --> 0:01:15.080000 to have an IP address, and some other fundamental IP-related information 0:01:15.080000 --> 0:01:18.960000 so you can make use of that IP-based network. 0:01:18.960000 --> 0:01:23.860000 What is the minimum necessary information you would have to have in order 0:01:23.860000 --> 0:01:25.740000 to do basic networking? 0:01:25.740000 --> 0:01:28.080000 Well, number one, you have to have an IP address. 0:01:28.080000 --> 0:01:30.540000 Without that, you're dead in the water. 0:01:30.540000 --> 0:01:34.300000 Number two, you have to have a subnet mask that goes along with that IP 0:01:34.300000 --> 0:01:39.820000 address. Number three, you have to know how long is that IP address and 0:01:39.820000 --> 0:01:44.220000 mask good for? Is it good forever for the next hour, for the next day? 0:01:44.220000 --> 0:01:46.840000 That's called a lease time. 0:01:46.840000 --> 0:01:51.100000 You need the IP address of a router that's on the same subnet as you, 0:01:51.100000 --> 0:01:55.980000 what we call a default gateway because 99% of the time the packets that 0:01:55.980000 --> 0:02:02.220000 you create will not be destined for somebody on your network but for somebody 0:02:02.220000 --> 0:02:04.480000 on a remote network. 0:02:04.480000 --> 0:02:07.320000 And your laptop doesn't know how to get to remote networks, so you need 0:02:07.320000 --> 0:02:11.340000 a router that's sitting in the same room as you in the same subnet as 0:02:11.340000 --> 0:02:14.740000 you that can get your packets there. 0:02:14.740000 --> 0:02:18.920000 And we're also going to need the IP address of a DNS server so that when 0:02:18.920000 --> 0:02:23.740000 you open up Google Chrome or Firefox or Microsoft Edge, you can type in 0:02:23.740000 --> 0:02:30.360000 www.ine.com and DNS will resolve that in the background to a functional 0:02:30.360000 --> 0:02:34.960000 IP address so you can create a packet going to that web server. 0:02:34.960000 --> 0:02:38.360000 So the real question is, where do you get all this information? 0:02:38.360000 --> 0:02:42.580000 Well, at a real high level, there's two basic places you could get it. 0:02:42.580000 --> 0:02:44.760000 You could statically configure it. 0:02:44.760000 --> 0:02:50.380000 Now if we were talking about, for example, a server or a router that sits 0:02:50.380000 --> 0:02:54.480000 in place, does not move around, it's sort of static in the network, well, 0:02:54.480000 --> 0:02:57.520000 that would probably be appropriate to statically configure all that information 0:02:57.520000 --> 0:02:59.940000 on that device itself. 0:02:59.940000 --> 0:03:03.620000 But for devices that are mobile, that move from room to room, building 0:03:03.620000 --> 0:03:07.300000 to building, and they come and they join and they leave a variety of IP 0:03:07.300000 --> 0:03:11.180000 networks, it's more appropriate that those devices obtain their information 0:03:11.180000 --> 0:03:16.580000 dynamically. And that's what this presentation, this video is all about. 0:03:16.580000 --> 0:03:21.000000 So how do we get a dynamic IP address and those other four or five things 0:03:21.000000 --> 0:03:22.120000 we see up there? 0:03:22.120000 --> 0:03:28.560000 Well, in the world of IP version four, the primary way is via DHCP, which 0:03:28.560000 --> 0:03:32.300000 stands for the dynamic host configuration protocol. 0:03:32.300000 --> 0:03:37.300000 So host is a term for your laptop, your PC. 0:03:37.300000 --> 0:03:41.560000 We need to configure it with IP related information that we just saw in 0:03:41.560000 --> 0:03:45.740000 the last slide. So we're going to dynamically do it with this protocol. 0:03:45.740000 --> 0:03:50.860000 So if you're familiar with the seven layers of the OSI model, DHCP operates 0:03:50.860000 --> 0:03:53.140000 in the application layer. 0:03:53.140000 --> 0:03:59.600000 And as I mentioned, its primary job is to give you IP information and 0:03:59.600000 --> 0:04:04.360000 address, a mask, and all that other stuff we saw in the previous slide. 0:04:04.360000 --> 0:04:10.580000 Now in the world of IP version four, DHCP is carried by the user datagram 0:04:10.580000 --> 0:04:12.460000 protocol by UDP. 0:04:12.460000 --> 0:04:15.420000 And you can see here, these are the ports that are reserved for that port 0:04:15.420000 --> 0:04:21.020000 67 and 68. And just a moment, I'll show you an animation of how everything 0:04:21.020000 --> 0:04:25.260000 takes place with DHCP, so where you can see where these ports line up. 0:04:25.260000 --> 0:04:30.640000 Now there is a version of DHCP also available for IP version six, which 0:04:30.640000 --> 0:04:34.120000 we call DHCP V six. 0:04:34.120000 --> 0:04:37.620000 That also is carried by UDP, but they have different port numbers for 0:04:37.620000 --> 0:04:41.920000 that. That's 546 and 547. 0:04:41.920000 --> 0:04:48.260000 Now the original DHCP, so IPV4 DHCP was actually an enhancement to a much 0:04:48.260000 --> 0:04:53.620000 older protocol, which is called the boot protocol, or to simply boot P. 0:04:53.620000 --> 0:04:56.800000 So if you ever do a wire shark sniffer capture, and I'll show you one 0:04:56.800000 --> 0:05:00.760000 of those in a subsequent video, your wire shark sniffer capture, or whatever 0:05:00.760000 --> 0:05:05.460000 other sniffer device you're using to capture packets and see them in real 0:05:05.460000 --> 0:05:09.000000 time, might not display as DHCP. 0:05:09.000000 --> 0:05:11.620000 It might call them as boot P. 0:05:11.620000 --> 0:05:15.720000 Or a lot of times what I've seen is it might show you as DHCP. 0:05:15.720000 --> 0:05:17.060000 Oh, here's a DHCP packet. 0:05:17.060000 --> 0:05:17.920000 Here's another one. 0:05:17.920000 --> 0:05:21.700000 But then when you expand it to see the various fields inside of it, you'll 0:05:21.700000 --> 0:05:24.960000 see the fields will frequently reference boot P. 0:05:24.960000 --> 0:05:29.080000 So if you see that, now you know boot P was a much older protocol, not 0:05:29.080000 --> 0:05:34.180000 used anymore, but DHCP was built on top of that and enhanced it. 0:05:34.180000 --> 0:05:40.960000 Okay, so let's talk about the steps that DHCP uses to give you that IP 0:05:40.960000 --> 0:05:44.260000 information. And those steps, there's four of them. 0:05:44.260000 --> 0:05:48.340000 So you've got the DHCP client, which is you, that's your laptop, that's 0:05:48.340000 --> 0:05:52.000000 your tablet, and you've got the DHCP server, which ultimately is going 0:05:52.000000 --> 0:05:55.860000 to give you the information you need so that you can be represented as 0:05:55.860000 --> 0:05:58.960000 a unique entity on the IP network. 0:05:58.960000 --> 0:06:01.460000 And we're going to have four steps involved for this. 0:06:01.460000 --> 0:06:05.480000 Those four steps can be remembered using the new monic or the acronym 0:06:05.480000 --> 0:06:08.000000 DORA. So let's take a look at those. 0:06:08.000000 --> 0:06:12.760000 So step number one, your PC boots up, or maybe it was already running, 0:06:12.760000 --> 0:06:16.220000 but it just discovered that it has joined a new network. 0:06:16.220000 --> 0:06:20.520000 Maybe you move to a new wireless network, maybe you sat down at a conference 0:06:20.520000 --> 0:06:22.660000 table and you plugged in an ethernet cable. 0:06:22.660000 --> 0:06:28.080000 Either way, your client says aha, my network interface card is active, 0:06:28.080000 --> 0:06:32.260000 it's relieved, it's doing electrical energy or whatever, I know I'm part 0:06:32.260000 --> 0:06:36.240000 of a network. I need to get IP information so I can do something on this 0:06:36.240000 --> 0:06:40.380000 network. So the first thing your client generates is what's called a DHCP 0:06:40.380000 --> 0:06:42.780000 discover packet. 0:06:42.780000 --> 0:06:46.500000 Now let's look at a couple of very important fields inside here. 0:06:46.500000 --> 0:06:52.680000 So notice that at layer three, the destination is a broadcast. 0:06:52.680000 --> 0:06:56.120000 You see, when you first send out a DHCP discover, your primary purpose 0:06:56.120000 --> 0:07:01.180000 is to say, hey, I need to discover a server out there, a DHCP server, 0:07:01.180000 --> 0:07:05.860000 do you exist? And because you don't know if a server exists or not, you 0:07:05.860000 --> 0:07:13.640000 have to put something in the IP so everybody on your subnet is going to 0:07:13.640000 --> 0:07:17.660000 hear this and hopefully someone on your subnet will be a server and be 0:07:17.660000 --> 0:07:18.980000 able to respond to it. 0:07:18.980000 --> 0:07:24.320000 Now the layer three source address that you use is going to be all zeros 0:07:24.320000 --> 0:07:27.040000 because this is what you're trying to obtain. 0:07:27.040000 --> 0:07:30.160000 You don't have a source address yet, but once again, you got to put something 0:07:30.160000 --> 0:07:34.940000 into that field in the IP packet header so you'll just zero it out. 0:07:34.940000 --> 0:07:42.560000 So whenever you're talking to the server, you're talking to his port 67. 0:07:42.560000 --> 0:07:47.600000 So the server is listening on UDP port 67. 0:07:47.600000 --> 0:07:49.920000 That is his DHCP port. 0:07:49.920000 --> 0:07:54.040000 You are talking from port 68. 0:07:54.040000 --> 0:07:57.660000 So I think you can gather before I even show you the next animation that 0:07:57.660000 --> 0:08:01.600000 when the server responds back to you, he's going to be talking to you 0:08:01.600000 --> 0:08:06.680000 on UDP port 68. And that's what we're going to see here in the next animation. 0:08:06.680000 --> 0:08:09.740000 So the server responds back with an offer. 0:08:09.740000 --> 0:08:16.480000 So the server here has one or more what we call pools of IP addresses. 0:08:16.480000 --> 0:08:21.040000 So for each DHCP pool, he has a range of IP addresses that are available 0:08:21.040000 --> 0:08:22.700000 that he can pick from. 0:08:22.700000 --> 0:08:26.700000 He has an IP address of a router or a default gateway that's appropriate 0:08:26.700000 --> 0:08:29.280000 for all the people in that pool. 0:08:29.280000 --> 0:08:32.840000 He has a lease. So when he gives you an address, he says, hey, this address 0:08:32.840000 --> 0:08:37.520000 is good for a day or an hour or whatever it has been configured for. 0:08:37.520000 --> 0:08:41.500000 That pool also have, for example, the IP address of a DNS server, maybe 0:08:41.500000 --> 0:08:45.480000 owned by CloudFlare or Google or somebody that you can use. 0:08:45.480000 --> 0:08:48.660000 And there's a very good chance that pool might have other optional things 0:08:48.660000 --> 0:08:54.160000 as well. You see, when DHCP gives you an offer, there's all sorts of things 0:08:54.160000 --> 0:08:55.060000 that could be in there. 0:08:55.060000 --> 0:08:59.700000 A couple of slides ago, we saw like the four or five bare minimum things 0:08:59.700000 --> 0:09:03.300000 that you needed, like an address, a subnet mass, DNS server, so on and 0:09:03.300000 --> 0:09:08.740000 so forth. But DHCP has dozens of different options that could hand you 0:09:08.740000 --> 0:09:12.300000 as information. And it's really just up to the network administrator who's 0:09:12.300000 --> 0:09:16.600000 controlling that server, what options they want to present you when they 0:09:16.600000 --> 0:09:19.920000 give the DHCP offer. 0:09:19.920000 --> 0:09:22.160000 Now, a couple of things here and notice about this offer. 0:09:22.160000 --> 0:09:25.800000 Number one. He's offering you this address. 0:09:25.800000 --> 0:09:28.680000 So that address is an available address. 0:09:28.680000 --> 0:09:32.120000 Nobody else has it right now and he's picking it from that pool. 0:09:32.120000 --> 0:09:37.140000 And notice that the layer three destination is that address. 0:09:37.140000 --> 0:09:39.460000 Now, you might be thinking, well, wait a second. 0:09:39.460000 --> 0:09:44.380000 My DHCP client at this point in time doesn't have any address. 0:09:44.380000 --> 0:09:49.800000 So if a packet comes in going to this, how would he know that it's actually 0:09:49.800000 --> 0:09:55.600000 for him? Because he's not listening to 777.51 yet. 0:09:55.600000 --> 0:10:01.260000 Well, the DHCP client recognizes that this is for him not based on the 0:10:01.260000 --> 0:10:05.400000 layer three address, but based on the layer two information. 0:10:05.400000 --> 0:10:09.680000 Remember, this is most likely carried in a layer two ethernet header, 0:10:09.680000 --> 0:10:18.140000 which is going to have a source Mac and a destination Mac. 0:10:18.140000 --> 0:10:21.080000 This guy's Nick card has some sort of a Mac address. 0:10:21.080000 --> 0:10:24.680000 Let's say it's a something like that. 0:10:24.680000 --> 0:10:28.320000 So the destination Mac address will be for this client. 0:10:28.320000 --> 0:10:31.900000 So this client is expecting a DHCP offer. 0:10:31.900000 --> 0:10:34.180000 After all, he sent a DHCP discover. 0:10:34.180000 --> 0:10:39.220000 So when a DHCP offer comes in specifically going to his Mac address, he 0:10:39.220000 --> 0:10:41.840000 knows that must be for me. 0:10:41.840000 --> 0:10:45.700000 And knows here that the port numbers have been reversed, which would make 0:10:45.700000 --> 0:10:51.400000 sense. Now, you might think, oh, we're done then. 0:10:51.400000 --> 0:10:53.120000 I sent out a discover. 0:10:53.120000 --> 0:10:54.520000 I got an offer back. 0:10:54.520000 --> 0:10:58.560000 We're good. Well, not quite, because let's think about this here from 0:10:58.560000 --> 0:11:00.400000 the server's perspective. 0:11:00.400000 --> 0:11:05.120000 The server has a pool of available addresses and he just picked one and 0:11:05.120000 --> 0:11:09.380000 gave it to you. If you don't send anything back to him, how's he going 0:11:09.380000 --> 0:11:12.120000 to know if you accepted that or not? 0:11:12.120000 --> 0:11:16.720000 The server has to have some sort of confirmation that yes, you like what 0:11:16.720000 --> 0:11:20.980000 he gave you and he's now going to reserve that for you and not give it 0:11:20.980000 --> 0:11:24.320000 for somebody else who comes in with a DHCP discover a few seconds or a 0:11:24.320000 --> 0:11:25.660000 few minutes later. 0:11:25.660000 --> 0:11:29.540000 So that's why we need the third step in this process, which is where the 0:11:29.540000 --> 0:11:32.300000 client now sends a DHCP request. 0:11:32.300000 --> 0:11:36.040000 He says, hey, server, that information just offered me. 0:11:36.040000 --> 0:11:40.900000 I'd like to request that it be formally reserved for me and nobody else. 0:11:40.900000 --> 0:11:45.300000 Now, there's another secondary reason behind sending this request. 0:11:45.300000 --> 0:11:51.340000 Remember that the DHCP discover packet that we first saw was a broadcast. 0:11:51.340000 --> 0:11:56.840000 Now, in a lot of sizable networks today, there's more than one DHCP server. 0:11:56.840000 --> 0:12:00.740000 If we just had one and that server failed, that would be very bad. 0:12:00.740000 --> 0:12:03.680000 Now, people wouldn't be able to get on the network at all because they 0:12:03.680000 --> 0:12:05.460000 wouldn't get any IP addresses. 0:12:05.460000 --> 0:12:08.420000 So a lot of networks today, even smaller sized networks, will at least 0:12:08.420000 --> 0:12:11.380000 have two DHCP servers. 0:12:11.380000 --> 0:12:15.680000 So if I send out as the client a DHCP discover, there's a good possibility 0:12:15.680000 --> 0:12:19.660000 I might get more than one offer back. 0:12:19.660000 --> 0:12:23.960000 So every operating system I know of, the way they work is they will accept 0:12:23.960000 --> 0:12:26.160000 the very first offer they get. 0:12:26.160000 --> 0:12:31.520000 But of those two servers out there, they don't know which one you picked. 0:12:31.520000 --> 0:12:33.880000 So that's another reason why you send out a request. 0:12:33.880000 --> 0:12:37.780000 And notice that the DHCP request that we see here, it is also a broadcast 0:12:37.780000 --> 0:12:41.560000 message just like the DHCP discover. 0:12:41.560000 --> 0:12:47.020000 So if there was another DHCP server or a third or a fourth one, they would 0:12:47.020000 --> 0:12:49.220000 all see this DHCP request. 0:12:49.220000 --> 0:12:54.200000 And although we don't see it in this animation, in the body of the DHCP 0:12:54.200000 --> 0:12:58.060000 request, it says, Hey, server 7777. 0:12:58.060000 --> 0:13:00.740000 I like your offer. 0:13:00.740000 --> 0:13:03.040000 I will take your information. 0:13:03.040000 --> 0:13:07.300000 And because this is a broadcast, any other DHCP servers will say, Oh, 0:13:07.300000 --> 0:13:12.520000 well, I'm not 7777, so clearly he didn't like my offer. 0:13:12.520000 --> 0:13:15.920000 I'll put my information back in the pool and make it available for the 0:13:15.920000 --> 0:13:18.340000 next person that comes around. 0:13:18.340000 --> 0:13:23.040000 And then lastly, the DHCP server will send a DHCP acknowledgement saying, 0:13:23.040000 --> 0:13:24.520000 OK, we're good to go. 0:13:24.520000 --> 0:13:28.460000 That information is now reserved for you for the duration of whatever 0:13:28.460000 --> 0:13:30.840000 the lease is that was set up. 0:13:30.840000 --> 0:13:35.900000 So hence we can see here why the acronym DORA discover offer request acknowledgement 0:13:35.900000 --> 0:13:40.440000 can help you to remember the steps here involved in DHCP. 0:13:40.440000 --> 0:13:44.260000 Now what I've just displayed right here is DHCP for the world of IP version 0:13:44.260000 --> 0:13:47.760000 4. What about for the world of IP version 6? 0:13:47.760000 --> 0:13:49.740000 Well, it's very, very similar. 0:13:49.740000 --> 0:13:54.760000 It's still four steps between the V6 client and the V6 server. 0:13:54.760000 --> 0:13:57.640000 It's just the names of those steps have changed. 0:13:57.640000 --> 0:14:01.840000 Their functionality, their purpose is exactly the same. 0:14:01.840000 --> 0:14:04.440000 Don't ask me why they didn't just stick with DORA. 0:14:04.440000 --> 0:14:05.480000 That would have been nice. 0:14:05.480000 --> 0:14:07.580000 So we could have just carried that over to V6. 0:14:07.580000 --> 0:14:11.460000 But no, the engineers in their infinite wisdom had to change the names 0:14:11.460000 --> 0:14:12.060000 of the messages. 0:14:12.060000 --> 0:14:14.660000 So now we've got SAR. 0:14:14.660000 --> 0:14:16.280000 OK, you're going to have to remember that. 0:14:16.280000 --> 0:14:19.800000 So how is this? Well, this is a DHCP solicit. 0:14:19.800000 --> 0:14:22.500000 And just a couple of things to know here. 0:14:22.500000 --> 0:14:25.060000 Remember I said back towards the beginning of this presentation that for 0:14:25.060000 --> 0:14:28.060000 IPV6 we've got different port numbers. 0:14:28.060000 --> 0:14:32.820000 So now we're using port 546, which is the port number that the client 0:14:32.820000 --> 0:14:38.880000 uses, and port 547, which is the port number when talking to the server. 0:14:38.880000 --> 0:14:41.540000 Notice also the addresses are a little bit different because we're talking 0:14:41.540000 --> 0:14:49.280000 about IPV6. So in the world of IPV6, an IPV6 NIC card, whether it be a 0:14:49.280000 --> 0:14:54.240000 Wi-Fi NIC card or a wired NIC card, will always create what's called a 0:14:54.240000 --> 0:14:56.500000 link local address. 0:14:56.500000 --> 0:14:58.800000 A link local address. 0:14:58.800000 --> 0:15:04.220000 And a link local address always starts out with a common pattern of FE80 0:15:04.220000 --> 0:15:06.920000 and then a bunch of stuff after that. 0:15:06.920000 --> 0:15:11.320000 So I've just made up some fake link local addresses right here. 0:15:11.320000 --> 0:15:19.380000 So DHCPV6 is not used to dynamically obtain your link local address. 0:15:19.380000 --> 0:15:24.020000 Any device, even if it's a refrigerator that's running IPV6, knows how 0:15:24.020000 --> 0:15:26.780000 to come up with its link local address by itself. 0:15:26.780000 --> 0:15:27.940000 That's just part of the protocol. 0:15:27.940000 --> 0:15:33.700000 So we can see here in the world of IPV6, this client will actually use 0:15:33.700000 --> 0:15:37.000000 his link local address as the source. 0:15:37.000000 --> 0:15:39.160000 Now what's this right here? 0:15:39.160000 --> 0:15:43.740000 Well, in the world of IPV6, there's no such thing as broadcasts. 0:15:43.740000 --> 0:15:45.420000 Broadcast don't exist. 0:15:45.420000 --> 0:15:47.380000 But we do have multicasts. 0:15:47.380000 --> 0:15:56.140000 So in IPV6, any IPV6 address beginning with FF is a multicast address. 0:15:56.140000 --> 0:16:02.640000 This one right here, FF02 colon colon one colon two, that is reserved 0:16:02.640000 --> 0:16:10.500000 for DHCPV6. So any DHCPV6 servers are listening to that address. 0:16:10.500000 --> 0:16:13.980000 Other than that, the process is pretty much the same. 0:16:13.980000 --> 0:16:17.280000 It's just that the names have been changed to protect the innocent. 0:16:17.280000 --> 0:16:20.000000 So here we have the DHCP solicit. 0:16:20.000000 --> 0:16:22.440000 Now we have the DHCP advertised. 0:16:22.440000 --> 0:16:24.540000 So that's in place of the offer. 0:16:24.540000 --> 0:16:28.320000 So now we're getting a global IPV6 address, something we could actually 0:16:28.320000 --> 0:16:30.380000 route through the Internet. 0:16:30.380000 --> 0:16:32.500000 Then we send a DHCP request. 0:16:32.500000 --> 0:16:34.800000 Ah, this is the one thing that did not change. 0:16:34.800000 --> 0:16:37.660000 So of the four messages, we still have the request here. 0:16:37.660000 --> 0:16:40.740000 And then we have the DHCP reply. 0:16:40.740000 --> 0:16:43.260000 Hence the acronym SAR. 0:16:43.260000 --> 0:16:48.400000 Now these are the most common types of DHCP messages. 0:16:48.400000 --> 0:16:52.240000 Let's go back to IPV4, because this is probably what you're more used 0:16:52.240000 --> 0:16:54.220000 to right here. Dora. 0:16:54.220000 --> 0:17:00.680000 But there are some other types of IP of DHCP messages that you might see 0:17:00.680000 --> 0:17:04.140000 that you should probably be familiar with what they are and what they 0:17:04.140000 --> 0:17:07.800000 do. So let's just talk about those for a moment. 0:17:07.800000 --> 0:17:13.200000 So DHCP release, as it says right here. 0:17:13.200000 --> 0:17:15.440000 Now this is an optional message. 0:17:15.440000 --> 0:17:20.140000 But if you're about to leave a network, for example, if you were shutting 0:17:20.140000 --> 0:17:25.340000 down your laptop or your PC, well, then it is gracefully leaving the network 0:17:25.340000 --> 0:17:28.120000 because you're shutting it down as part of the shutdown process. 0:17:28.120000 --> 0:17:32.800000 Your laptop or PC should send out a DHCP release message, which tells 0:17:32.800000 --> 0:17:36.620000 the server, hey, this IP address, I'm giving it back to you. 0:17:36.620000 --> 0:17:39.180000 You can give it to the next available person who needs it. 0:17:39.180000 --> 0:17:42.140000 Now however, that doesn't always happen. 0:17:42.140000 --> 0:17:45.800000 For example, if you just yank out your Ethernet cable from your laptop 0:17:45.800000 --> 0:17:50.420000 or PC, it's not going to have a chance to send a DHCP release. 0:17:50.420000 --> 0:17:56.020000 So in that particular case, the DHCP server would just time out that address. 0:17:56.020000 --> 0:17:59.440000 Or maybe when you move to a new network, you might send it a message, 0:17:59.440000 --> 0:18:02.260000 but chances are pretty good that the server just wouldn't know. 0:18:02.260000 --> 0:18:05.780000 And it would just hold on to that address until the lease timer expired, 0:18:05.780000 --> 0:18:10.420000 never knowing that you had left that network minutes or hours ago. 0:18:10.420000 --> 0:18:12.900000 But a release is optional. 0:18:12.900000 --> 0:18:16.720000 A DHCP NAC message stands for negative acknowledgment. 0:18:16.720000 --> 0:18:20.140000 You're not going to see this very often, but it is in the specification, 0:18:20.140000 --> 0:18:22.320000 so I just wanted to tell you what it is. 0:18:22.320000 --> 0:18:23.780000 It says right here. 0:18:23.780000 --> 0:18:30.860000 So a DHCP client, when your client is already up and running, for example, 0:18:30.860000 --> 0:18:35.080000 let's say that you were on a Wi-Fi network right now, and you had obtained 0:18:35.080000 --> 0:18:37.440000 an IP address via DHCP. 0:18:37.440000 --> 0:18:40.440000 Now let's say you go to your Wi-Fi net card and you disable it, like via 0:18:40.440000 --> 0:18:43.480000 the graphical user interface in Windows or something. 0:18:43.480000 --> 0:18:48.480000 And then a few minutes later, you enable your Wi-Fi net card again. 0:18:48.480000 --> 0:18:51.480000 Well, your operating system has been running the whole time. 0:18:51.480000 --> 0:18:55.960000 Your operating system remembers what the IP address was that you had previously 0:18:55.960000 --> 0:18:58.260000 when you were on that network. 0:18:58.260000 --> 0:19:02.200000 So the way most operating systems work is that when you rejoin a network, 0:19:02.200000 --> 0:19:04.920000 they will actually, they won't send out a discover packet. 0:19:04.920000 --> 0:19:10.400000 The very first thing they'll send out is actually a request saying, hey, 0:19:10.400000 --> 0:19:12.740000 this is the IP address I used to have. 0:19:12.740000 --> 0:19:15.860000 I'm requesting that I be able to get this one again. 0:19:15.860000 --> 0:19:20.320000 Now, in this particular situation, what if somebody else already got that 0:19:20.320000 --> 0:19:25.360000 IP address? What if, for example, you turned off your Wi-Fi net card as 0:19:25.360000 --> 0:19:28.600000 an example and you walked away for a couple of hours or you just left 0:19:28.600000 --> 0:19:29.640000 it there for a couple of hours. 0:19:29.640000 --> 0:19:34.720000 During that time, the lease ran out. 0:19:34.720000 --> 0:19:37.860000 So the DHCP server said, well, I haven't heard from Keith in a while, 0:19:37.860000 --> 0:19:42.180000 but his lease ran out, so I'm going to put his IP address back in my pool, 0:19:42.180000 --> 0:19:44.740000 and now somebody else asks for an address. 0:19:44.740000 --> 0:19:46.880000 Somebody else sends a DHCP discover. 0:19:46.880000 --> 0:19:50.260000 Now the DHCP service is, oh, okay, well, I'll give you Keith's address. 0:19:50.260000 --> 0:19:52.180000 The address that was formerly known as Keith. 0:19:52.180000 --> 0:19:53.540000 Okay, I'll give it to you, John. 0:19:53.540000 --> 0:19:54.860000 You can have it now. 0:19:54.860000 --> 0:19:59.480000 Now, Keith comes back and Keith sends a DHCP requesting, hey, I'd like 0:19:59.480000 --> 0:20:01.660000 to reuse that same address again. 0:20:01.660000 --> 0:20:04.260000 This is where a DHCP NAC would come into play. 0:20:04.260000 --> 0:20:09.040000 The server would send a DHCP NAC back saying, I'm sorry, negative acknowledgement. 0:20:09.040000 --> 0:20:11.940000 I can't give you that address because it's already gone. 0:20:11.940000 --> 0:20:13.780000 Somebody else is already using it. 0:20:13.780000 --> 0:20:17.080000 So now, Keith, or whoever you are, you'd have to start the whole door 0:20:17.080000 --> 0:20:19.060000 of process all over again. 0:20:19.060000 --> 0:20:24.200000 We also have a DHCP inform. 0:20:24.200000 --> 0:20:27.660000 This is another message that you're not going to see very often. 0:20:27.660000 --> 0:20:33.020000 This is used by a client who already has an IP address but wants to obtain 0:20:33.020000 --> 0:20:36.640000 other information via DHCP. 0:20:36.640000 --> 0:20:39.480000 Here's actually a way I was able to replicate this on a Mac. 0:20:39.480000 --> 0:20:42.240000 You might be able to do the same thing on a Windows-based machine, but 0:20:42.240000 --> 0:20:46.180000 in a Mac, you can go into your network settings. 0:20:46.180000 --> 0:20:51.700000 You can go into your NIT card, and as far as addressing options, use DHCP 0:20:51.700000 --> 0:20:54.260000 as one, and that's typically the default. 0:20:54.260000 --> 0:20:57.440000 There's also use a static IP address, which means I'm not going to use 0:20:57.440000 --> 0:21:01.620000 DHCP at all, but then in a Macs, there's also an option where it says 0:21:01.620000 --> 0:21:08.220000 use DHCP with manual address, where you can type in your IP address, and 0:21:08.220000 --> 0:21:13.360000 then what will happen is your laptop, your Mac, will send out a DHCP inform. 0:21:13.360000 --> 0:21:16.580000 It'll say, hey, server, I've already got an IP address. 0:21:16.580000 --> 0:21:18.780000 Here it is, but I need other stuff. 0:21:18.780000 --> 0:21:22.420000 I need the mask that goes along with this IP address. 0:21:22.420000 --> 0:21:24.980000 I need the gateway that goes along with this subnet. 0:21:24.980000 --> 0:21:30.040000 I need the DNS server, so you use an inform for that. 0:21:30.040000 --> 0:21:33.100000 And then there's the DHCP decline. 0:21:33.100000 --> 0:21:37.560000 I don't really know how to replicate this in a lab environment, but this 0:21:37.560000 --> 0:21:42.560000 will be a situation where you get a DHCP offer from the server, and something 0:21:42.560000 --> 0:21:44.940000 about that offer you don't like. 0:21:44.940000 --> 0:21:48.120000 Like I said, I don't know how you would make this happen, but in that 0:21:48.120000 --> 0:21:53.740000 case you would send a DHCP decline back to that server, saying that, okay, 0:21:53.740000 --> 0:21:56.820000 we got to start over because what you offered me is no good. 0:21:56.820000 --> 0:22:03.140000 So that concludes this presentation on an introduction to DHCP. 0:22:03.140000 --> 0:22:03.860000 Thank you for watching.