Welcome to Jeremy’s IT Lab. This is a free, complete course for the CCNA. If you like these videos, please subscribe to follow along with the series. Also, please like and leave a comment, and share the video to help spread this free series of videos. Thanks for your help. Also, remember to download and use the Anki flashcards with the link in the description, which will help you very much in remembering what you have learned. Let’s get started. In this video, we’re going to take a look at the Internet Protocol version 4, known as IPv4 header. This is used at Layer 3, to help send data between devices on separate networks, even on other sides of the world over the Internet. This is known as routing. Originally, I planned this video to be a general introduction to routing, but in the end I decided to split it up into separate parts. Let’s take a look at what we’ll cover in this video. We’ll cover the IPv4 packet structure, or more accurately, the IPv4 header which is used to encapsulate a TCP or UDP segment. Specifically, we will cover the fields of the IPv4 header. We already looked in detail at two fields of the header, the source and destination IP address fields, but there are quite a few more fields to look at. And that’s all for this video! As I said, I originally planned to make this a long, introduction to routing video. However, I don’t want to make these videos too long, already the shortest videos are at least 30 minutes which is quite long I think. So, I decided to split up routing into more videos. This prevents the videos from getting too long, but also lets me go more in depth on each topic. So, this video will focus exclusively on the fields in the IPv4 header, and then future videos will will get more practical, with hands-on configuration in the CLI. Since we’re going to look at the IPv4 header, let’s review its position in a complete frame. So, the upper layers of the OSI model prepare some data to be sent to another device. It is encapsulated in a layer 4 header, typically using the TCP or UDP protocols, which we’ll talk about in a future lesson. This combination of data plus layer 4 header is called a segment. The segment is encapsulated with a Layer 3 header, usually using the internet protocol, IP. This combination of data, layer 4 header, and layer 3 header, is called a packet. Then, the layer 2 header and trailer are added, and this is called a frame. These units are called protocol data units, or PDUs. For example, the layer 3 PDU is a packet, and the layer 2 PDU is a frame. For this lesson, we’ll focus on this Layer 3 header, as it contains the information that is needed to route this packet to its destination. Note that, since we’ll be focusing on Layer 3 here, I’ll usually be using the term ‘packet’, talking about ‘routing packets’, rather than frames. So, thanks to Wikipedia for this chart of the IPv4 header structure. As you can see, it’s a bit more complicated than the Ethernet header. To be honest, I doubt that it will be necessary for you to memorize the exact structure of the header, the size of each field, etc, for the CCNA test, but I can’t make any guarantees, I didn’t make the test. What I recommend is just getting to know the purpose of each field of the header, which we’ll cover now. By the way, if you’re wondering how to read this chart, it’s read left to right, top to bottom, so this is the first bit of the header, and this is the last bit of the header. So, let’s quickly go through each field of the header so you’re familiar with its purpose. First up is the ‘Version’ field of the header. It’s length is 4 bits, half of one octet. It’s purpose is straight forward. It identifies the version of IP used. Now, there are only two versions of IP in use, IPv4, which is simply identified with a value of 4 in this field, or 0 1 0 0 in binary. The other version is Ipv6, which is identified with a value of 6, or 0 1 1 0 in binary. Now you may wonder what happened to IPv5? Well there was an experimental protocol called Internet Stream Protocol which uses an Internet Protocol value of 5, but it was never publically used. So, you could say that’s the lost IPv5. Now, we’re focusing on the IPv4 header, so this field of the header will always have a value of 4. The IPv6 header has a different structure than the IPv4 header, so if the value of this field is 6 the rest of the header will have a different structure. Next up is the Internet Header Length, or IHL, field. It’s also 4 bits in length, half of one octet. The final field of the IPv4 header (Options) is variable in length, so this field is necessary to indicate the total length of the header. Here’s an important part to remember: This field specifies the length of the header IN 4-BYTE INCREMENTS. For example, if the value in this field is 5, 5 times 4-bytes is 20, so that means that length of the header is 20 bytes. The minimum value in this field is 5, which as I just said is equal to 20 bytes. That’s the length of the IP packet WITHOUT any IP options at the end, so an empty options field. The maximum value is 15, which is the maximum value of 4 bits, As you can see here, the values of the 4 bits are 1, 2, 4, and 8, adding them up results in 15. So, 15 x 4 bytes is equal to 60 bytes. That means the maximum length of the IP options field is 40 bytes. So, an IPv4 header with no options field is 20 bytes in length, and that’s the minimum length of an IPv4 header. And, an IPv4 with a maximum length options field, 40 bytes, has a length of 60 bytes, and that’s the maximum length of an IPv4 header. Okay, that’s the IHL field of the IPv4 header. Next is the DSCP field. DSCP stand for differentiated services code point, and the field’s length is 6 bits. This field is used for QoS, quality of service. Basic QoS is a topic on the CCNA so I will make a dedicated video about it later. Essentially, it is used to prioritize delay-sensitive data, such as streaming voice and video. If you’re loading a web page and the Internet is a little slow, it’s not a big deal. However, if you’re having a skype call and there’s terrible delay, or the audio and video keep freezing, it can totally ruin the experience. This field is used to identify which traffic should receive priority treatment. Next up is the ECN field, which stands for explicit congestion notification and has a length of 2 bits. It provides end-to-end notification of network congestion WITHOUT DROPPING PACKETS. Normally in a network, if the network is super busy, if there is congestion, this is signalled by dropping packets. The ECN field provides a way to signal a congested network without dropping packets. However, this is an optional field that requires both endpoints, as well as the underlying network infrastructure, to support it. Next up is the Total Length field, and its length is 16 bits, or 2 octets, 2 bytes. It indicates the total length of the packet, including the IPv4 header and the encapsulated Layer 4 segment, which includes both the layer 4 header and the data. This is different than the IHL field, which indicates only the length of the IPv4 header itself. This field indicates the length in bytes, NOT IN 4-BYTE INCREMENTS LIKE THE IHL HEADER. So, a value of 20 in this field simply means 20 bytes. The minimum value in this field is 20, meaning 20 bytes, which is equal a minimum-sized IPv4 header with no encapsulated data. The maximum value is 65,535, which is the maximum value of 16 binary bits, all set to 1. Let me just show you that calculation. Here are 16 bits, two octets, all set to 1. The first bit is equal to 1, then 2, then 4...8...16...32...64...128. This is as far as we went when looking at a single octet in an IPv4 address. If you extend beyond 8 bits, the value keeps doubling. Next is 256...512...1024...2048...4096...8192...16,384...and then the 16th bit is 32,768. Add those all up, and you get 65535, the maximum length of an IPv4 packet. Next up is the Identification field, which is also 16 bits in length. If a packet is fragmented due to being too large, this field is used to identify which packet the fragment belongs to, so it can be reassembled again to make the original packet. All fragments of the same packet will have their own IPv4 header with the same value in this field., so they can be reassembled later. Packets are fragmented if larger than the MTU, which stands for Maximum Transmission Unit. The MTU is usually 1500 bytes. Remember the maximum size of an Ethernet frame? I mentioned that the maximum payload size of an Ethernet frame is 1500 bytes, so these are related. And one last point, fragments are reassembled by the receiving host. Next is the Flags field, which is 3 bits in length. It is used to control and identify fragments. There are 3 bits, and they function like this. The first bit, bit 0, is reserved and always set to 0. Bit 1 is the don’t fragment bit, or DF bit. If it is set to 1, it means that the packet should not be fragmented. Bit 2 is the more fragments, or MF bit. It is set to 1 if there are more fragments in the packet, and then set to 0 for the last fragment. Also, if the packet is a whole, unfragmented packet, the MF bit is set to 0, since there are no fragments. Next we have one more field related to packet fragmentation, that is the fragment offset field, which is 13 bits in length. This field is used to indicate the position of the fragment within the original, unfragmented IP packet. This allows fragmented packets to be reassembled even if the fragments arrive out of order, since this field lets the receiver know the original order of the fragments. Next up is the Time to Live Field, which is 8 bits in length. A router will drop a packet with a TTL of 0. So, this field is used to prevent infinite loops. If a poor routing configuration causes a packet to be continually sent around in a loop, never reaching its intended destination, if enough traffic like that accumulates, it could causes network congestion, and eventually failure. This feature prevents that by happening, causing looped traffic to be dropped when the TTL reaches 0. This field was originally designed to indicate the packet’s maximum lifetime in seconds, in practice, however, this actually indicates a ‘hop count’. Each time the packet arrives at a router on the way to its destination, the router decreases the TTL by 1, until the packet reaches its destination, or the TTL reaches 0 and the packet is dropped. The current recommended default TTL is 64. Next up is the Protocol field, which is also 8 bits in length. It indicates the protocol of the encapsulated Layer 4 PDU. Typically, this will be one of the following: TCP, which is indicated by a value of 6, or UDP, which is indicated by a value of 17. I haven’t talked about TCP and UDP yet, but that I will make a dedicated video about them later. For now, try to remember their protocol numbers of 6 for TCP and 17 for UDP. You might also see a value of 1, which is used for ICMP, the protocol ping uses. Another one to remember is 89, which is OSPF, which stands for Open Shortest Path First. OSPF is a dynamic routing protocol which allows routers to learn routes to destinations from their neighbors, without us having to manually configure the routes. We will cover OSPF in depth in this course, so for now just try to remember the protocol number of 89. If you’re curious, you can check a list of protocol numbers at this page on wikipedia. Don’t worry about memorizing any others, but try to remember these four. The included flashcards are extremely useful for remembering little facts like these. Next is the header checksum field, which is 16 bits in length. It is a calculated checksum used to check for errors in the Ipv4 header. When a router receives a packet, it calculates the checksum of the header and compares it to the one in this field of the header. If the newly calculated checksum and the checksum in the IPv4 header do not match, it means that an error has occurred in transmission, so the router drops the packet. Note that this is only used to check for errors in the IPv4 header, not in the encapsulated data. IP relies on the encapsulated protocol to do that. Both UDP and TCP, the two Layer 4 protocols most likely to be encapsulated, have checksum fields to check for errors in the encapsulated data. Okay, next up are the Source and Destination IP Address fields, which I covered in detail already. As you already know, they are 32 bits in length each, as that is the length of an IPv4 address. The source IP address field indicates the IPv4 address of the sender of the packet. The destination IP address field indicates the IPv4 address of the intended receiver of the packet. Finally, the options field, which is optional and can be 0 bits in length if not used, or up to 320 bits, 40 bytes, in length. This field is rarely used, however if the IHL, Internet header length, field is greater than 5, is means that options are present. Here is a chart from Wikipedia showing the structure of the Options field, you can check it out or read more online if you’re interested, but for the purposes of CCNA studies I don’t think you need to worry about it. Okay, now we’ve covered all of the fields of the IPv4 header. It’s a bit more complicated than the simple Ethernet header and trailer we already learned about, but hopefully you understand the purpose of each field now. For the purpose of the CCNA, I think the information presented in this video is sufficient, but of course feel free to read more, a simple Google search will give you many good resources. Also don’t forget to use the Anki flashcards to help you remember everything. Now let’s go in depth and analyze a packet capture from Wireshark. I showed you Wireshark before, and its an extremely useful tool both for learning, and also in the real world to troubleshoot problems. This isn’t a wireshark course, but I will show you wireshark at various points in this course, and if you have a lab with real Cisco equipment, or a virtual lab using GNS3, I highly recommend you use Wireshark to examine network traffic like this, it will really help you in your studies. But in either case, I will show you Wireshark packet captures in this course, so don’t worry if you aren’t able to use it yourself. So, I sent a ping between two routers, notice under the INFO column it says echo (ping) request. I have selected the frame here, meaning the entire frame and you can see down here that the entire frame is highlighted. These digits are a hexadecimal representation of the frame. Now I highlighted the Ethernet header, and down at the bottom you can see only the Ethernet header section of the frame is highlighted. Then I highlight the IP header, and at the bottom only the IP header section of the frame is highlighted. Then I highlight the packet’s payload, which is Internet Control Message Protocol, or ICMP, the protocol used by ping, and you can see the payload highlighted at the bottom. In this video we’re focusing on the IPv4 header, so let’s expand the Internet Protocol Version 4 information. Okay, so I’ve expanded the IPv4 header section and zoomed up a bit, and here you can see all of the fields we looked at in this video, except Options. As I said, options are rarely used, and they aren’t in this packet. First up, the Version field, and V you can see the binary bits 0100 on the left, and it shows you that means version 4. Next is the header length which is the IHL field. It has a binary value of 0101, which equals 5. Remember, this field indicates the length in units of 4 bytes, so this value of 5 means a header length of 20 bytes. That is the minimum header length, and it is the length of an IPv4 header with no options field. Next up is the differentiated services field, and as you can see Wireshark categorizes both the DSCP, differentiated services codepoint, and ECN, explicit congestion notification, fields under this section. Both are set to 0, as they are not being used. Next up is the total length. This represent the total length of the IP packet in bytes, including both the header and the ICMP data it encapsulates. So, this 100 means that the total length is 100 bytes. Next is the identification field. This packet has an identification field of 5. It’s not fragmented, but if it were fragmented, the other fragments belonging to this packet would also have a value of 5 here. Next up is the flags field. Notice that Wireshark also includes the fragment offset field under this section. The reserved bit is always 0. That’s what ‘not set’ means by the way. I sometimes say ‘set to 0’ or ‘set to 1’, but another way of saying it is ‘not set’, which means 0, or ‘set’, which means 1. The don’t fragment bit isn’t set, so this packet can be fragmented, if necessary. The more fragments bit also isn’t set, which is expected as the packet isn’t fragmented. The fragment offset field is also 0, which is also expected in a packet that isn’t fragmented. Next is the Time to Live field, which is set to 255, the maximum. Remember, the time to live field is 8 bits in length, and 255 is the maximum 8-bit value. The protocol is ICMP, because I used ping. Notice the protocol value of 1 which indicates this. You can see the header checksum here. Remember it’s a 16-bit value. 0X indicates hexadecimal, and then each hexadecimal digit is equal to 4 bits, so 4 times 4 is 16, 16 bits. Here’s the source IP address, and finally the destination IP address. The standard PING command on a Cisco router will send 100-byte pings, which is why the ping I showed you wasn’t fragmented. But, I pinged once more, using this command ping 192.168.1.2 SIZE 10000, which will send 10,000 byte pings, much larger than the 1500 bytes MTU. So, this will cause fragmentation. As you can see here, there are a bunch of IP fragments. They all say ‘reassembled in #13’. What is #13? Well, it’s this ICMP echo request right here. Now, let’s take a look at some of the IPv4 header fields in these fragments. Okay, so these are the details of just the first two fragments. First off, notice the total length of 1500 bytes, so this 10,000 byte ping was divided up into 1500 byte fragments, which is equal to the MTU size. Then, notice the identification field of 1. This is different than the last packet I showed you, but notice that the value is the same for these two fragments. Then take a look at the flags. Each of them has the more fragments bit set, because neither of these is the last fragment in the packet. Also, notice that each of them has a different fragment offset value, however, and that the first fragment has an offset of 0. Just one more thing, this time I sent a ping and set the don’t fragment bit by adding the ‘df-bit’ option to the ping command. As you can see here, now the don’t fragment bit is set. Because I didn’t set the size, the default ping size of 100 bytes was used, so it was no problem that these packets weren’t allowed to be fragmented. However, if I send pings that are larger than the MTU, AND set the DF-bit, you can see the pings fail. They were too large to be sent unfragmented, but also not allowed to be fragmented. Before moving on to today’s quiz let’s review what we studied. We looked at the structure of an IPv4 packet, more specifically the fields of the IPv4 header. That’s it. It doesn’t look like a lot when you list it like this, but I’m sure you agree that was a lot of information. In the next video we’ll get more practical and hands-on, getting into the CLI to see how to configure routes. Okay let’s move on to today’s quiz. In addition to the quiz, make sure to download and use the Anki flashcards to help you remember all of the details you learned in this video. Let’s get started with question 1. What is the fixed binary value of the first field of an IPv4 header? A, 0010. B, 0110. C, 0001. D, 0100. Pause the video to think about your answer. The answer is D, 0100. The first field of the IPv4 header is the version field. Because the question is about an IPv4, or Internet Protocol VERSION 4 header, the version field is always set to 4, or 0100 in binary. let’s go to question 2. Which field will cause the packet to be dropped if it has a value of 0? A, TTL. B, DSCP. C, IHL. D, ECN. Pause the video to think about your answer. The answer is A, TTL. TTL stands for Time To Live. It is reduced by 1 at each router the packet passes through. If it reaches 0, the packet is dropped. Let's go to question 3. How are errors in an IPv4 packet’s encapsulated data detected? A, the IPv4 header checksum field checks for errors. B, the encapsulated protocol, for example TCP or UDP, checks for errors. C, Errors in the encapsulated data cannot be detected. Pause the video to think about your answer. The answer is B, the encapsulated protocol checks for errors. The IPv4 Header Checksum field only checks for errors in the IPv4 header itself. However, Layer 4 protocols like TCP or UDP can use their checksum to check for errors in the encapsulated data. Let’s go to question 4. Which field of an Ipv4 header is variable in length? A, options. B, header checksum. C, total length. D, IHL. Pause the video to think about your answer. The answer is A, Options. The Options field can vary in length from 0 bits to 320 bits. The other fields are fixed-length. Although the Total Length and IHL fields are used to represent the variable length of the IPv4 header and packet, the fields themselves are fixed in length. Let’s go to question 5. Which bit will be set to 1 on all IPv4 packet fragments except the last fragment? A, fragment offset bit. B, more fragments bit. C, dont fragment bit. D, packet fragment bit. Pause the video to think about your answer. The answer is B, more fragments bits. The More Fragments bit, part of the Flags field of the IPv4 header, is used to indicate that the current fragment is not the last fragment of a fragmented packet. It is set to 1 on all fragments except the last, which will set it to 0. A, fragment offset, is a 13-bit field in the header, not a single bit. C, Don’t fragment bit, is used to prevent a packet from being fragmented. And D, packet fragment bit, is not a real bit in the IPv4 header. Okay, that’s all for the quiz. Remember to use the supplementary materials to help you remember what you’ve studied. There will be Anki flashcards to help you review what you’ve studied. For a video like this, I think the flashcards are particularly important, so remember to download and use them. There will be a packet tracer lab for routing, but not after this video. Wait until after day 11’s video to get some hands-on practice configuring routing on a Cisco router. Good luck with your studies. Thank you for watching. Please subscribe to the channel, like the video, leave a comment, and share the video with anyone else studying for the CCNA. If you want to leave a tip, check the links in the description. I'm also a Brave verified publisher and accept BAT, or Basic Attention Token, tips via the Brave browser. That's all for now.