WEBVTT 0:00:02.880000 --> 0:00:08.280000 Hello and welcome to this video titled IP version 4 header fields. 0:00:08.280000 --> 0:00:12.740000 In this video we're going to talk about just like the title slide refers 0:00:12.740000 --> 0:00:17.260000 to, we're going to look at the header that IPv4 adds to the front of every 0:00:17.260000 --> 0:00:21.720000 packet and we're going to inspect all the different fields in that IPv4 0:00:21.720000 --> 0:00:26.060000 header to determine what the field is and what its purpose is. 0:00:26.060000 --> 0:00:28.820000 So let's just go right into it. 0:00:28.820000 --> 0:00:35.460000 So when data is passed down from TCP or UDP or something else and it's 0:00:35.460000 --> 0:00:39.880000 passed down to the networking layer of the OSI model, if IP version 4 0:00:39.880000 --> 0:00:43.520000 lives there, then IPv4 is going to take everything that was passed down 0:00:43.520000 --> 0:00:48.120000 to it and add its own unique header to the front of that data. 0:00:48.120000 --> 0:00:53.580000 That header is what turns this entire thing into what we call an IP packet. 0:00:53.580000 --> 0:00:57.080000 That header contains some address fields as well as a whole bunch of other 0:00:57.080000 --> 0:01:01.180000 things that allow that pack to be routed through a routed network. 0:01:01.180000 --> 0:01:03.940000 So let's take a look at that header and inspect each one of those fields. 0:01:03.940000 --> 0:01:07.540000 So this box here is going to represent the header. 0:01:07.540000 --> 0:01:10.660000 So starting with the version field. 0:01:10.660000 --> 0:01:14.660000 So the version field is either going to be the number 4 or the number 0:01:14.660000 --> 0:01:18.440000 6. So IP version 4 has been around for decades. 0:01:18.440000 --> 0:01:22.800000 There's more and more IP version 6 being seen these days, but you'll typically 0:01:22.800000 --> 0:01:24.720000 see the number 4 right here. 0:01:24.720000 --> 0:01:28.500000 Now as I go through this, I'm also going to go back and forth with a wire 0:01:28.500000 --> 0:01:31.560000 shark sniffer trace so we can actually see this in real life. 0:01:31.560000 --> 0:01:34.140000 So let's go right to that right now. 0:01:34.140000 --> 0:01:37.280000 So in the event that you're not familiar with this, this tool is called 0:01:37.280000 --> 0:01:41.040000 wire shark and it's a free tool that you can download. 0:01:41.040000 --> 0:01:45.860000 Just go to www.wire shark.org and you can download it. 0:01:45.860000 --> 0:01:49.740000 And when you start up wire shark, it's going to ask you which of the network 0:01:49.740000 --> 0:01:54.860000 interface cards on your laptop per PC you want to use to capture information. 0:01:54.860000 --> 0:02:00.660000 So in my case, I use my Wi-Fi net card and it captures every single frame, 0:02:00.660000 --> 0:02:04.140000 whether it's carrying an IP packet or not, that's captured across the 0:02:04.140000 --> 0:02:08.060000 Wi-Fi. So here we see a whole bunch of stuff that has IP packets. 0:02:08.060000 --> 0:02:13.320000 So for example, if we click on any one of these, here we see right there. 0:02:13.320000 --> 0:02:19.580000 There is our version field right there and we can see that in binary it 0:02:19.580000 --> 0:02:21.360000 does indeed have the number 4. 0:02:21.360000 --> 0:02:24.200000 So this is IP version 4. 0:02:24.200000 --> 0:02:26.700000 Actually, while we're just looking, let's just go through the sniffer 0:02:26.700000 --> 0:02:29.920000 trace and look at all the other fields here and then we won't really need 0:02:29.920000 --> 0:02:31.200000 to use the slide for anything. 0:02:31.200000 --> 0:02:38.380000 So the next thing is the header length which tells the receiver this packet 0:02:38.380000 --> 0:02:45.340000 where the IP header ends and the next header like the TCP or UDP header 0:02:45.340000 --> 0:02:49.540000 begins. Now you might be wondering why do we even need this field? 0:02:49.540000 --> 0:02:53.220000 I mean, isn't the IP header the exactly the same size? 0:02:53.220000 --> 0:02:57.460000 Well most of the time it is, most of the time it is, but actually to explain 0:02:57.460000 --> 0:03:01.260000 that, let me go back to the slide for a minute and show you something. 0:03:01.260000 --> 0:03:07.600000 So if we go through all the fields here, so these are all the standard 0:03:07.600000 --> 0:03:11.980000 fields in an IP version 4 header and in every single IP version 4 packet 0:03:11.980000 --> 0:03:15.520000 you will see every single one of these fields. 0:03:15.520000 --> 0:03:20.840000 But there is one field that may or may not be here which is the IP options 0:03:20.840000 --> 0:03:25.320000 field. So we're not in this video because it's sort of an introduction 0:03:25.320000 --> 0:03:29.160000 to IP before. I'm not going to go into options and what they are and all 0:03:29.160000 --> 0:03:33.920000 the different options you may see, but I will tell you this, 99% of all 0:03:33.920000 --> 0:03:38.460000 IP packets, if not more, do not have an options. 0:03:38.460000 --> 0:03:41.680000 So the options field is very rare that you would ever see it. 0:03:41.680000 --> 0:03:44.080000 As a matter of fact, most of the time if there is an options field in 0:03:44.080000 --> 0:03:46.600000 there, it means somebody is trying to do something bad. 0:03:46.600000 --> 0:03:49.800000 They're trying to sneak around and do something that they're not supposed 0:03:49.800000 --> 0:03:53.840000 to be doing because the vast majority of IP packets do not have an options 0:03:53.840000 --> 0:03:59.140000 field. But because it could be there and if it is there, it's a variable 0:03:59.140000 --> 0:04:02.800000 sized field. It could have one option and it could have more than one 0:04:02.800000 --> 0:04:05.560000 option. There's all sorts of IP options. 0:04:05.560000 --> 0:04:10.800000 That means that the IP header itself is variable in size because the options 0:04:10.800000 --> 0:04:12.820000 field may or may not be there. 0:04:12.820000 --> 0:04:17.340000 So the receiver has to know, okay, where's the IP header end? 0:04:17.340000 --> 0:04:19.420000 Is there an options field or not? 0:04:19.420000 --> 0:04:23.700000 And so that's why we have the IP header length which explicitly tells 0:04:23.700000 --> 0:04:27.380000 us how big the header is. 0:04:27.380000 --> 0:04:30.560000 By the way, notice here you might be saying, but Keith, something looks 0:04:30.560000 --> 0:04:35.820000 kind of weird about this because this field in binary only is the number 0:04:35.820000 --> 0:04:40.400000 five. The four bit and the one bit are turned on and yet is decoding to 0:04:40.400000 --> 0:04:44.580000 being 20 bytes. And yes, the standard IPV4 header you're going to see 0:04:44.580000 --> 0:04:47.680000 99% of the time is 20 bytes in size. 0:04:47.680000 --> 0:04:49.880000 So why is it say five and it says 20 bytes? 0:04:49.880000 --> 0:04:50.900000 Well, here's the reason. 0:04:50.900000 --> 0:04:55.320000 Notice this field, the IP header length field is very small. 0:04:55.320000 --> 0:04:57.840000 It's only a four bit field. 0:04:57.840000 --> 0:05:02.780000 Each one of these bits does not represent a byte. 0:05:02.780000 --> 0:05:10.220000 As a matter of fact, what this represents is how many 32 bit words are 0:05:10.220000 --> 0:05:14.540000 in the header? A 32 bit word. 0:05:14.540000 --> 0:05:17.880000 So in other words, if there was just the number one here, which you'll 0:05:17.880000 --> 0:05:22.580000 never see, then that would mean that the IP header is 32 bits. 0:05:22.580000 --> 0:05:23.820000 It's a 32 bit word. 0:05:23.820000 --> 0:05:29.980000 Now we know the 32 bit word is actually four bytes, right? 0:05:29.980000 --> 0:05:32.580000 Because each byte is eight bits long. 0:05:32.580000 --> 0:05:38.060000 So that means if I have the number one here, if I have one 32 bit word 0:05:38.060000 --> 0:05:41.880000 that actually translates to four bytes. 0:05:41.880000 --> 0:05:46.800000 But in this case, I've got five 32 bit words. 0:05:46.800000 --> 0:05:52.040000 Now remember, a 32 bit word is four bytes long. 0:05:52.040000 --> 0:05:54.280000 So five times four bytes. 0:05:54.280000 --> 0:05:56.900000 This is my 32 bit word right here. 0:05:56.900000 --> 0:06:05.400000 That gives me my value of 20 bytes, which is indeed the size of your typical 0:06:05.400000 --> 0:06:07.340000 IP version four header. 0:06:07.340000 --> 0:06:12.840000 Now the next field, depending on the document you're reading or anything 0:06:12.840000 --> 0:06:19.120000 here in Wireshark, it translates to the different shades services field. 0:06:19.120000 --> 0:06:25.100000 A lot of times you'll see that also referenced as the toss or type of 0:06:25.100000 --> 0:06:33.260000 service field. This represents the relative priority of the packet as 0:06:33.260000 --> 0:06:36.060000 opposed to other packets that might be seen. 0:06:36.060000 --> 0:06:42.500000 By default, whenever data leaves your laptop, by default, if we open this 0:06:42.500000 --> 0:06:46.960000 up here a little bit, it's all zeros. 0:06:46.960000 --> 0:06:50.840000 And this is the lowest priority of packet you could possibly have, all 0:06:50.840000 --> 0:06:55.060000 zeros. Now if this packet was coming from an IP phone or something like 0:06:55.060000 --> 0:06:57.480000 that, it would have a non-zero field. 0:06:57.480000 --> 0:06:59.340000 It would have some number in there that's not zero. 0:06:59.340000 --> 0:07:02.820000 And the higher the number, the more important the higher the priority 0:07:02.820000 --> 0:07:07.540000 of this packet. So in computer networks that have something called quality 0:07:07.540000 --> 0:07:11.580000 of service turned on, where they can differentiate between packets based 0:07:11.580000 --> 0:07:15.460000 on this field, they can treat packets differently if they have a higher 0:07:15.460000 --> 0:07:18.940000 or lower value. So this gives the priority of the packet. 0:07:18.940000 --> 0:07:22.960000 Once again, it's called the type of service or toss field, or sometimes 0:07:22.960000 --> 0:07:26.480000 it's called the differentiates services field. 0:07:26.480000 --> 0:07:28.460000 Then we have the total length. 0:07:28.460000 --> 0:07:31.640000 Okay, now this is the total length of the entire IP packet, the header 0:07:31.640000 --> 0:07:34.940000 and everything that's behind it as well. 0:07:34.940000 --> 0:07:37.200000 Then we have an identification. 0:07:37.200000 --> 0:07:41.480000 So what this is, this is just a random number that was given to this specific 0:07:41.480000 --> 0:07:46.900000 packet. So when my laptop is creating IP packets, whether it's five packets 0:07:46.900000 --> 0:07:51.640000 per second or 5,000 packets per second, every single one of them will 0:07:51.640000 --> 0:07:54.560000 have a unique identification number. 0:07:54.560000 --> 0:07:58.960000 And that number doesn't mean a lot unless the packet goes through something 0:07:58.960000 --> 0:08:00.640000 called fragmentation. 0:08:00.640000 --> 0:08:03.480000 And I'll circle back to that for just a second. 0:08:03.480000 --> 0:08:07.140000 So for that reason, I'm going to ignore the flags field for just a minute. 0:08:07.140000 --> 0:08:13.080000 We'll come back to that because flags and identification are interlinked, 0:08:13.080000 --> 0:08:14.280000 they're tied together. 0:08:14.280000 --> 0:08:20.260000 Time to live. Okay, so when an application, let's just say an application 0:08:20.260000 --> 0:08:25.260000 on your laptop or PC creates a packet to begin with, whatever it is, a 0:08:25.260000 --> 0:08:29.200000 web browsing packet, tell net, whatever it is, that application and whatever 0:08:29.200000 --> 0:08:33.880000 the software is running that application will populate this time to live 0:08:33.880000 --> 0:08:36.360000 field with some non-zero number. 0:08:36.360000 --> 0:08:40.080000 Now you as a human being, you have no control over this number, you have 0:08:40.080000 --> 0:08:43.180000 no idea what it's going to pick, whoever created the software in the first 0:08:43.180000 --> 0:08:46.900000 place, they had to decide what they wanted to use as a default time to 0:08:46.900000 --> 0:08:49.060000 live. Now what does it do? 0:08:49.060000 --> 0:08:52.360000 Well, think of that word, time to live. 0:08:52.360000 --> 0:08:55.180000 How long can this packet be alive? 0:08:55.180000 --> 0:08:56.620000 What does that mean exactly? 0:08:56.620000 --> 0:08:59.980000 Well, we're going to put some non-default number in here like you can 0:08:59.980000 --> 0:09:03.140000 see, this one had a pretty big number, 255. 0:09:03.140000 --> 0:09:07.920000 This field, if we go over here, is only 8 bits long, so that's the maximum 0:09:07.920000 --> 0:09:11.040000 number that could be in there, is 255. 0:09:11.040000 --> 0:09:15.400000 And the way this is interpreted is, if this packet left my laptop, left 0:09:15.400000 --> 0:09:20.920000 my PC, the very first router it hits, which is my default gateway, as 0:09:20.920000 --> 0:09:24.140000 it takes that packet, we'll see the time to live and it will decrement 0:09:24.140000 --> 0:09:26.340000 it or reduce it by one. 0:09:26.340000 --> 0:09:30.560000 So if this was leaving my PC right now with the time to live of 255, as 0:09:30.560000 --> 0:09:34.440000 it went through my default gateway and popped out the other side, it would 0:09:34.440000 --> 0:09:37.680000 have a time to live of 254. 0:09:37.680000 --> 0:09:42.740000 So the way you can interpret this is, how many routers can this packet 0:09:42.740000 --> 0:09:47.980000 hop through before it's time to live is over? 0:09:47.980000 --> 0:09:53.300000 Now even to send a packet all the way around the world would not take 0:09:53.300000 --> 0:09:57.100000 255 routers, you could actually get a packet all the way around the world 0:09:57.100000 --> 0:09:59.360000 and back with far less than this. 0:09:59.360000 --> 0:10:06.980000 But let's say hypothetically, this packet reached router number 255, okay, 0:10:06.980000 --> 0:10:09.940000 or maybe router 256 somewhere around there. 0:10:09.940000 --> 0:10:13.200000 Basically what's going to happen is eventually, this time to live is going 0:10:13.200000 --> 0:10:15.680000 to reduce and reduce and reduce and eventually there's going to be some 0:10:15.680000 --> 0:10:20.280000 router out there that receives this packet in and when it comes in, the 0:10:20.280000 --> 0:10:22.520000 time to live will be one. 0:10:22.520000 --> 0:10:25.720000 Now that router will say, okay, I need to decrement it. 0:10:25.720000 --> 0:10:28.000000 The router will decrement it to zero. 0:10:28.000000 --> 0:10:32.420000 Ah, okay, at that point, after the time to live has been decremented to 0:10:32.420000 --> 0:10:35.600000 zero, that means this packet has to be killed. 0:10:35.600000 --> 0:10:39.980000 It's time to live is over and the router will throw it away. 0:10:39.980000 --> 0:10:45.340000 So the only time that would actually happen is if a packet entered what's 0:10:45.340000 --> 0:10:46.820000 called a routing loop. 0:10:46.820000 --> 0:10:49.740000 If the packet entered a network where there was something wrong in the 0:10:49.740000 --> 0:10:53.720000 network and the packet was just circling among routers, never actually 0:10:53.720000 --> 0:10:57.180000 reaching its destination at all, just bouncing back between maybe the 0:10:57.180000 --> 0:11:01.900000 same two routers or a circle of routers, in that situation, this field 0:11:01.900000 --> 0:11:07.340000 is very useful because it would prevent the packet from circling forever. 0:11:07.340000 --> 0:11:10.400000 Eventually some router would get the packet with a TTL of one, it would 0:11:10.400000 --> 0:11:14.960000 decrement it to zero, throw the packet away and now the packet's lifetime 0:11:14.960000 --> 0:11:16.720000 would be finished. 0:11:16.720000 --> 0:11:19.600000 So that's what the time to live is used for. 0:11:19.600000 --> 0:11:24.380000 Right after the time to live field is a protocol field and this will be 0:11:24.380000 --> 0:11:29.200000 populated with some standard registered number that tells the receiver 0:11:29.200000 --> 0:11:33.040000 what protocol is this IP packet carrying. 0:11:33.040000 --> 0:11:37.640000 Like we can see here, protocol number 17 is reserved for UDP. 0:11:37.640000 --> 0:11:41.840000 So this tells the receiver, hey, this IP packet that you've got, start 0:11:41.840000 --> 0:11:45.140000 up your UDP process because you're going to have to redirect after you 0:11:45.140000 --> 0:11:50.480000 strip off the IP header, what's going to be next is a UDP header. 0:11:50.480000 --> 0:11:54.180000 And there are many, many numbers that can go into that field. 0:11:54.180000 --> 0:11:57.140000 For example, ICMP is number one. 0:11:57.140000 --> 0:12:00.740000 Protocol number one is ICMP when you're pinging something. 0:12:00.740000 --> 0:12:05.440000 Protocol number two is IGMP for when you're doing multicasting and there's 0:12:05.440000 --> 0:12:07.980000 lots of other protocols that could be in here. 0:12:07.980000 --> 0:12:15.480000 Then we have the header checksum and what this is is if my laptop created 0:12:15.480000 --> 0:12:20.420000 this IP header to begin with, then what my laptop would do is after creating 0:12:20.420000 --> 0:12:25.360000 the header, it would run all the bits of all these fields, the total length, 0:12:25.360000 --> 0:12:30.280000 flags, protocol, all those bits through a formula and that formula would 0:12:30.280000 --> 0:12:35.520000 spit out some number like 04639 as the number. 0:12:35.520000 --> 0:12:40.220000 Now if I give this packet to you, let's say you are the destination, guess 0:12:40.220000 --> 0:12:40.980000 what you're going to do? 0:12:40.980000 --> 0:12:45.200000 You're going to take the exact same fields in the IP header, run them 0:12:45.200000 --> 0:12:51.500000 through the exact same formula and hopefully you will also get 0x4639 0:12:51.500000 --> 0:12:56.540000 which tells you that nothing was changed or modified in this packet. 0:12:56.540000 --> 0:12:59.300000 This packet has integrity. 0:12:59.300000 --> 0:13:02.700000 Now if you got this packet and you ran the header through the same formula 0:13:02.700000 --> 0:13:09.180000 but you got something like 0xA123, now you say uh oh, okay, some of the 0:13:09.180000 --> 0:13:13.440000 bits somewhere in this header are different than what they were when they 0:13:13.440000 --> 0:13:15.140000 popped out of the source. 0:13:15.140000 --> 0:13:18.500000 There's no way to tell what changed or where it changed, you can't correct 0:13:18.500000 --> 0:13:22.620000 it or fix it. All you would know at that point is I can't trust this packet 0:13:22.620000 --> 0:13:26.060000 because the header somehow got modified in transit. 0:13:26.060000 --> 0:13:29.940000 So that would be an error and you wouldn't want to see that. 0:13:29.940000 --> 0:13:33.940000 After that we have the source address of where the packet came from and 0:13:33.940000 --> 0:13:37.780000 the destination address of where it's going to and you can see in this 0:13:37.780000 --> 0:13:41.360000 particular packet there's no options field, that's it. 0:13:41.360000 --> 0:13:43.660000 That's the end of the IPV4 header. 0:13:43.660000 --> 0:13:47.560000 Now let's circle back around for just a moment because I skipped flags 0:13:47.560000 --> 0:13:49.880000 and identification. 0:13:49.880000 --> 0:13:52.400000 So let's talk about that for a second. 0:13:52.400000 --> 0:13:56.860000 Now my, let's just assume that this packet is being created by my laptop 0:13:56.860000 --> 0:14:01.820000 or my PC. My laptop or PC is connected to some sort of network like in 0:14:01.820000 --> 0:14:05.880000 this case I'm connected to a Wi-Fi network and the rules of that particular 0:14:05.880000 --> 0:14:11.560000 kind of network say that when data is put on that network it can only 0:14:11.560000 --> 0:14:14.540000 be so big and then it has to stop. 0:14:14.540000 --> 0:14:18.700000 We call that the maximum transmission unit the MTU. 0:14:18.700000 --> 0:14:24.100000 So on most ethernet networks like if I was connected to a wired ethernet 0:14:24.100000 --> 0:14:36.100000 network the typical MTU is 1518 bytes as the maximum transmission unit. 0:14:36.100000 --> 0:14:40.340000 So which equals because I've done this math often enough I think that's 0:14:40.340000 --> 0:14:44.580000 about 9,600 bits. 0:14:44.580000 --> 0:14:49.460000 Somewhere around there it's very close to that if you do 1518 times 8 0:14:49.460000 --> 0:14:52.620000 you'll come up with something really close to that number. 0:14:52.620000 --> 0:14:54.560000 So the exact number is irrelevant. 0:14:54.560000 --> 0:14:59.020000 What's relevant here is that my laptop if I was connected to a wired ethernet 0:14:59.020000 --> 0:15:02.800000 cable and I was to start putting bits on that cable put an ethernet frame 0:15:02.800000 --> 0:15:09.040000 on that cable the maximum size of that ethernet frame is 9,600 bits. 0:15:09.040000 --> 0:15:11.160000 Then I have to let it go. 0:15:11.160000 --> 0:15:14.360000 I have to be quiet give somebody else a chance to speak on the cable before 0:15:14.360000 --> 0:15:16.600000 I put my next frame on the cable. 0:15:16.600000 --> 0:15:21.580000 Now the ethernet frame doesn't have to be 9,600 bits it's completely up 0:15:21.580000 --> 0:15:25.020000 to whatever applications creating that data as far as whether it wants 0:15:25.020000 --> 0:15:29.240000 to create a really small ethernet frame or the maximum size ethernet frame. 0:15:29.240000 --> 0:15:31.880000 Well what the heck does that have to do with this? 0:15:31.880000 --> 0:15:36.580000 Well every type of network out there whether it be wired ethernet, Wi 0:15:36.580000 --> 0:15:41.260000 -Fi or a variety of other things they all have this maximum transmission 0:15:41.260000 --> 0:15:46.340000 unit. Now they're not all the same. 0:15:46.340000 --> 0:15:49.720000 There's 15, 18 bytes but others might have a thousand bytes. 0:15:49.720000 --> 0:15:52.000000 Others might have 3,000 bytes. 0:15:52.000000 --> 0:15:56.060000 Now the only thing my laptop knows is the network I'm actually connected 0:15:56.060000 --> 0:15:59.800000 to right now. That's the only MTU I'm aware of. 0:15:59.800000 --> 0:16:07.100000 So let's say for the purposes of argument that I sent out, so let's say 0:16:07.100000 --> 0:16:15.000000 this is me right here and I send out this way a packet I should say a 0:16:15.000000 --> 0:16:18.600000 frame because now this is not only the IP packet but it's also the ethernet 0:16:18.600000 --> 0:16:22.560000 headers that is 1500 bytes. 0:16:22.560000 --> 0:16:24.880000 I was able to create the largest thing. 0:16:24.880000 --> 0:16:26.880000 Alright now that gets to my router. 0:16:26.880000 --> 0:16:31.920000 Now let's say my router decides oh he needs to send it out this direction. 0:16:31.920000 --> 0:16:33.300000 But here's a problem. 0:16:33.300000 --> 0:16:37.220000 This particular interface is a different kind of network we're just making 0:16:37.220000 --> 0:16:40.320000 this up here but it could be a different kind of network and whatever 0:16:40.320000 --> 0:16:45.080000 that network is it doesn't support 1500 bytes. 0:16:45.080000 --> 0:16:49.620000 The MTU on there let's come up with some number like 500 bytes. 0:16:49.620000 --> 0:16:53.900000 Alright well what's this router going to do because he can't take this 0:16:53.900000 --> 0:16:58.600000 thing right here that's 1500 bytes long and put it on that outgoing cable 0:16:58.600000 --> 0:17:04.240000 it's too big. Well the designers of IPB4 came up with a solution for that. 0:17:04.240000 --> 0:17:08.720000 They said okay let's take that packet and fragment it. 0:17:08.720000 --> 0:17:12.440000 Let's cut it up into little pieces with each piece that will fit on that 0:17:12.440000 --> 0:17:19.000000 wire. So here are our fragments in this case each fragment could be 500 0:17:19.000000 --> 0:17:25.180000 bytes long. Alright now how are we going to create these things because 0:17:25.180000 --> 0:17:29.980000 after all when it finally gets to the receiver wherever the receiver is 0:17:29.980000 --> 0:17:33.220000 that receives these he's going to need to know a couple of things. 0:17:33.220000 --> 0:17:36.960000 Number one he's going to need to know that all of these are actually fragments 0:17:36.960000 --> 0:17:38.780000 of one big packet. 0:17:38.780000 --> 0:17:42.640000 So he's going to need to be able to have some way of recombining them 0:17:42.640000 --> 0:17:45.860000 back into the original IP packet. 0:17:45.860000 --> 0:17:50.700000 Not only that but when it comes to packet forwarding in a packet network 0:17:50.700000 --> 0:17:56.340000 every IP packet is routed uniquely and independently which means that 0:17:56.340000 --> 0:17:59.600000 if I'm a router let's say a bunch of packets hits me on the back of the 0:17:59.600000 --> 0:18:01.960000 head all going to the same destination. 0:18:01.960000 --> 0:18:06.000000 I just get a bam bam bam bam a whole bunch of packets all going to 1.1 0:18:06.000000 --> 0:18:11.240000 .1.1. Well maybe right now at this moment I say oh this is the interface 0:18:11.240000 --> 0:18:13.300000 I'm going to use to get to 1111. 0:18:13.300000 --> 0:18:15.540000 So I start sending packets out this way. 0:18:15.540000 --> 0:18:18.900000 All of a sudden maybe that interface goes down or my routing table changes 0:18:18.900000 --> 0:18:22.400000 I say oh now 111 is reachable via this way. 0:18:22.400000 --> 0:18:23.840000 Now I'm going to send my packets this way. 0:18:23.840000 --> 0:18:28.980000 The point is as packets go through routed network they might not always 0:18:28.980000 --> 0:18:33.060000 take the exact same path from source to destination. 0:18:33.060000 --> 0:18:36.740000 They could take different paths which means they might be sent out of 0:18:36.740000 --> 0:18:41.700000 order. Just because I as a source send them as packet 1, 2, 3, 4, 5. 0:18:41.700000 --> 0:18:44.980000 If they're taking different orders through the network you as a receiver 0:18:44.980000 --> 0:18:48.820000 might get them as ordered 35142. 0:18:48.820000 --> 0:18:51.180000 That could happen here with these fragments. 0:18:51.180000 --> 0:18:54.740000 These fragments might be arriving out of order so the receiver would also 0:18:54.740000 --> 0:18:59.340000 have to know how do I put them back into the original order again. 0:18:59.340000 --> 0:19:01.800000 So here's where these fields come into play. 0:19:01.800000 --> 0:19:06.140000 Remember how we saw there was an identification field inside the IP header. 0:19:06.140000 --> 0:19:10.380000 So this original packet is going to have some identification some random 0:19:10.380000 --> 0:19:14.240000 number. Let's just say ID 1, 2, 3. 0:19:14.240000 --> 0:19:19.280000 Okay well when the router decides he's got a fragment this each one of 0:19:19.280000 --> 0:19:23.440000 these fragments is going to be given its own unique IP header. 0:19:23.440000 --> 0:19:27.640000 Sort of running out of room here but you get the idea. 0:19:27.640000 --> 0:19:28.920000 Let's start right here. 0:19:28.920000 --> 0:19:31.760000 So these are IP headers. 0:19:31.760000 --> 0:19:38.860000 So each one of these is going to look like its own standalone packet but 0:19:38.860000 --> 0:19:41.300000 it's not. How can we tell it's not? 0:19:41.300000 --> 0:19:46.540000 Well number 1 in the IP headers normally if these were all unique independent 0:19:46.540000 --> 0:19:49.940000 packets they would all have different identifications. 0:19:49.940000 --> 0:19:51.660000 Their ID numbers would be unique. 0:19:51.660000 --> 0:19:53.160000 That's not going to be the case. 0:19:53.160000 --> 0:19:58.720000 In this case each one of them is going to have an ID of 1, 2, 3. 0:19:58.720000 --> 0:20:02.440000 So whatever the ID was of the original packet before it was fragmented 0:20:02.440000 --> 0:20:05.420000 is going to be put into those headers. 0:20:05.420000 --> 0:20:09.920000 So that's one way that the receiver is going to know that oh these aren't 0:20:09.920000 --> 0:20:12.360000 independent these are all part of original packet because they all have 0:20:12.360000 --> 0:20:14.140000 the exact same ID. 0:20:14.140000 --> 0:20:17.100000 Now the receiver could make an assumption. 0:20:17.100000 --> 0:20:20.520000 He could say oh I'm getting duplicate packets. 0:20:20.520000 --> 0:20:22.240000 Sometimes that happens. 0:20:22.240000 --> 0:20:26.360000 Sometimes for whatever reason a packet as it goes into a network will 0:20:26.360000 --> 0:20:31.820000 be copied and you might get duplicates of the exact same thing which would 0:20:31.820000 --> 0:20:33.760000 be bad. You'd say I don't need all these. 0:20:33.760000 --> 0:20:35.240000 I only need one of these. 0:20:35.240000 --> 0:20:39.040000 So the receiver now he could be thinking oh these are duplicate packets 0:20:39.040000 --> 0:20:42.080000 so we need something else to tell him no no no. 0:20:42.080000 --> 0:20:43.240000 No these are not duplicates. 0:20:43.240000 --> 0:20:44.080000 These are parts. 0:20:44.080000 --> 0:20:45.860000 These are fragments of a whole. 0:20:45.860000 --> 0:20:48.480000 So let's go back to the wire shark here and take a look at how the receiver 0:20:48.480000 --> 0:20:50.440000 answers that question. 0:20:50.440000 --> 0:20:57.660000 So right here we can see in wire shark when I open up the flags field 0:20:57.660000 --> 0:21:01.220000 we have something about fragments. 0:21:01.220000 --> 0:21:03.380000 So here's how this would work. 0:21:03.380000 --> 0:21:07.120000 If I take a packet, so let's say this is my original packet right here 0:21:07.120000 --> 0:21:10.180000 and I cut it up into fragments. 0:21:10.180000 --> 0:21:14.000000 Let's say this is fragment number one so let's say it was going this way 0:21:14.000000 --> 0:21:16.240000 okay. This is fragment number one. 0:21:16.240000 --> 0:21:19.980000 This is fragment number two and this is fragment number three. 0:21:19.980000 --> 0:21:25.400000 Fragments one and two will have this bit set. 0:21:25.400000 --> 0:21:26.940000 The more fragments. 0:21:26.940000 --> 0:21:27.840000 I'll just put that in here. 0:21:27.840000 --> 0:21:30.780000 More fragments. More fragments. 0:21:30.780000 --> 0:21:39.980000 That's basically saying hey if you get this this is number one. 0:21:39.980000 --> 0:21:42.420000 And it's saying guess what there's more to come. 0:21:42.420000 --> 0:21:43.700000 I'm not the only fragment. 0:21:43.700000 --> 0:21:47.240000 There's more. Now notice this last one here number three. 0:21:47.240000 --> 0:21:49.700000 He's not going to have the more fragments bit set. 0:21:49.700000 --> 0:21:52.640000 So all of these will have the same ID one two three. 0:21:52.640000 --> 0:21:56.560000 You know that's just the random number of the original packet and now 0:21:56.560000 --> 0:22:00.680000 we can see the first two will have more fragments the third one won't. 0:22:00.680000 --> 0:22:06.780000 So if we got them in this order one two three we could very easily reconstruct 0:22:06.780000 --> 0:22:11.400000 it. But what if they don't come in that order. 0:22:11.400000 --> 0:22:15.560000 So let's say we get them in this order. 0:22:15.560000 --> 0:22:19.520000 I'll just say R O for received order. 0:22:19.520000 --> 0:22:21.180000 Let's say this one. 0:22:21.180000 --> 0:22:24.880000 It's going to be kind of complicated if I do that so let's not worry about 0:22:24.880000 --> 0:22:32.060000 that. Let's say that this one came first. 0:22:32.060000 --> 0:22:36.640000 This one came second. 0:22:36.640000 --> 0:22:42.940000 So this is what you're receiving now and then you receive this one third. 0:22:42.940000 --> 0:22:45.920000 How would you put them back together in the correct order. 0:22:45.920000 --> 0:22:50.640000 All right. So let's take a look at the first one you got. 0:22:50.640000 --> 0:22:53.600000 All right the first one you got you know it's a fragment because the more 0:22:53.600000 --> 0:22:55.780000 fragments bit is set you're good to go. 0:22:55.780000 --> 0:22:59.860000 Now where in the scheme is it is this the very first fragment is it the 0:22:59.860000 --> 0:23:03.820000 19th fragment you know where is this thing well. 0:23:03.820000 --> 0:23:12.700000 There's another field in here called fragment offset fragment offset. 0:23:12.700000 --> 0:23:20.660000 So if the fragment offset like this says zero that means this is the beginning 0:23:20.660000 --> 0:23:22.860000 of the packet there's nothing in front of me. 0:23:22.860000 --> 0:23:29.160000 So for example this third one that you got his fragment offset will be 0:23:29.160000 --> 0:23:36.520000 zero. What we mean by offset here is how far away from the front of the 0:23:36.520000 --> 0:23:40.020000 original packet is this fragment. 0:23:40.020000 --> 0:23:43.820000 Well this fragment is the front of the original packet there's nothing 0:23:43.820000 --> 0:23:46.740000 in front of him so the fragment offset here is zero. 0:23:46.740000 --> 0:23:51.900000 Now the next one here number two the fragment offset is actually representation 0:23:51.900000 --> 0:23:56.580000 as far as how far away are you from from this point right here. 0:23:56.580000 --> 0:24:00.280000 All right so that's the front of the packet so if we go backwards how 0:24:00.280000 --> 0:24:04.920000 many bytes away from that backwards are you. 0:24:04.920000 --> 0:24:10.180000 So let's say this guy was five hundred and one bytes away. 0:24:10.180000 --> 0:24:13.580000 All right so the first fragment was bites one through five hundred this 0:24:13.580000 --> 0:24:18.580000 guy is bite five hundred and one that's where he starts so his fragment 0:24:18.580000 --> 0:24:21.440000 offset would be five hundred and one. 0:24:21.440000 --> 0:24:25.460000 So remember this is the this one here in the middle that's the one we 0:24:25.460000 --> 0:24:29.140000 got first so if you're the receiver now you know a bunch of things you 0:24:29.140000 --> 0:24:33.060000 know number one that's a fragment because it got it has the more fragments 0:24:33.060000 --> 0:24:38.440000 bit set and you know that's not the very first one because otherwise the 0:24:38.440000 --> 0:24:41.840000 fragment offset would be zero and this is a non-zero number so this is 0:24:41.840000 --> 0:24:43.080000 somewhere in the middle. 0:24:43.080000 --> 0:24:48.800000 You also know this is not the last one because the last fragment will 0:24:48.800000 --> 0:24:52.580000 not have the more fragments bit set. 0:24:52.580000 --> 0:24:55.540000 All right now we get this number two. 0:24:55.540000 --> 0:25:02.060000 Aha okay it's got the exact same ID one two three it's got some fragment 0:25:02.060000 --> 0:25:07.060000 offset of you know whatever let's say one thousand but what's important 0:25:07.060000 --> 0:25:13.700000 here is that the more fragments bit is not set it's zeroed out which means 0:25:13.700000 --> 0:25:18.040000 that's our indicator that that is the last fragment. 0:25:18.040000 --> 0:25:21.960000 And then lastly oh now we get this third one right here okay well it's 0:25:21.960000 --> 0:25:25.360000 part of the previous fragments we just received because it has the exact 0:25:25.360000 --> 0:25:29.280000 same identification number that's this right here so in this case it's 0:25:29.280000 --> 0:25:33.860000 one two three it's got the more fragments turned on and the fragment offset 0:25:33.860000 --> 0:25:40.340000 is zero so now we know this is at the very beginning of the fragment. 0:25:40.340000 --> 0:25:44.900000 So that's why you know I had to skip the identification for a little bit 0:25:44.900000 --> 0:25:51.900000 so these here identification flags and fragment offset all of that is 0:25:51.900000 --> 0:25:56.220000 only used when a packet is fragmented and it's really for the benefit 0:25:56.220000 --> 0:26:01.380000 of the receiver so the receiver will know when he gets it how to reorder 0:26:01.380000 --> 0:26:06.980000 everything and reconstruct the original packet as it was. 0:26:06.980000 --> 0:26:13.200000 So that concludes this video on the IP version 4 header fields I hope 0:26:13.200000 --> 0:26:13.960000 you found it useful.