IPv4 Packet Header

Hello Muhammad

An IPv4 header is designed to have a variable header length. That is, it can have many options that come after the source and destination IP addresses. If you look at the diagram of the IP header in the lesson, you will see an options field. Now that options field is not often used. Actually, it is very rarely used. The header length field is used to indicate if there are any options in the header. Specifically, the value in the header length field is multiplied by 32 to indicate the size of the header in bits. So, a value of 5 indicates 5X32 = 160 bits or 20 bytes. This is the minimum size of the IP header, and is indeed the default size, without options. When no options are used, the header length value is 5.

Having said all that, for the vast majority of applications, the header length is 5 due to the fact that no options are implemented.

Now the total length field is a value that states the total size of the packet including both header and payload. This value is used along with the fragment offset to be able to reassemble fragmented packets.

The IP flags are used when fragmenting IP packets. Fragmentation of an IP packet occurs during encapsulation. When a host is encapsulating data down the OSI stack, when it comes to encapsulating the packet into a frame, there are often restrictions as to how big of a packet can fit in a frame. Such restrictions are due to the Maximum Transmission Unit (MTU) allowed on a particular Ethernet link. If the packet is too large, it will be broken into two and placed into two frames. If the DF bit is set to 1, then fragmentation is not allowed, thus the packet is dropped. If it is set to 0, fragmentation is allowed and the MF bit is set to 1, indicating that the part of the packet in the particular frame has MORE FRAGMENTS coming after it that are carrying part of the same packet. The final frame carrying the final fragment of the same packet will have MF set to 0 indicating that it is the last one. The Fragment Offset is used to keep track of what part of the fragmented packet this frame is part of. The MF along with the Fragment Offset are used to successfully reassemble a fragmented packet when it reaches its destination.

For more information about fragmentation, take a look at this lesson:

I hope this has been helpful!

Laz

1 Like

Hello Lazaros

Thank you very much you are great Lazaros, very clear explanation.

Hello,everyone.

Can someone explain to me what the 0x02 (don’t fragment) in the flag field in the wireshark capture indicates? Also, on the third bit is says that the MF bit is set on all fragmented packets except the last one. Why is it not set on the last fragmented packet. What happens to it?

Hello Bion

The Flags field is made up of three bits. The first bit is currently unused, while the second bit is the Don’t Fragment (DF) bit, and the third is the More fragments (MF) bit. Now the 0x02 in hexadecimal simply indicates that the three bits in the flag field are 010 which is equivalent to 0x02 in hex.

Now when you have the DF bit set, this means that this packet should never be broken down into two parts and placed into two or more different frames during encapsulation. For example, if you have an IP packet of 1500 bytes and it is being encapsulated into a frame, but the frame has an MTU of 1496 (click here for more info about the MTU) then the packet must be broken down into two parts, and sent in two separate frames. If the DF bit is set, then the packet will simply be dropped, because fragmentation is not allowed.

Now if the DF bit is not set, and fragmentation IS allowed, then there must be some way to keep track of the fragments of the IP packet. Let’s say for argument’s sake that you have an IP packet that is 1500 bytes in size, but the maximum size (MTU) that the underlying Ethernet network can handle is 510 bytes. This means the IP packet must be split into three parts of 510, 510, and 480 bytes respectively. Now each of these fragments, before being encapsulated into the frames, will have its own IP header. The MF flag in the first of the three will be set to 1, indicating that this is part of a fragmented packet, and more packets are expected to arrive. The MF flag in the second one will also be set to 1 because it is a member of a fragmented packet, but more packets are expected to come. Finally, the last fragment comes in, but the MF is set to 0. This simply states that there are no more fragments of this packet to be expected. This indicates to the host receiving the packet fragments that all have arrived, and reassembly can take place during de-encapsulation.

I hope this has been helpful!

Laz

1 Like

Hello, Lazaros.

Thank you, for the reply. it has been most helpful. If I am understanding correctly 0x02 is the three bits in the flag field translated into hex. So, if we have a packet that is allowed to be fragmented, we would have 0x01 for hexadecimal and the bits would be set as 001 on all fragmented packets except the last fragmented packet. The last fragmented packet has the third bit(MF) set to zero or off to indicate that there is no more fragments to expect and the the packet can be reassembled as a whole packet during de-encapsulation at the receiving host. Is that correct? Would the last packet be 0x00 or zeros on all three bits in the flag field?

Hello Bion

Yes you’ve got it! That is correct!

Glad to be of help!

Laz

Hi,
What would be the size of an ip packet , how is calculated .
What is the relation of ip packet size and MTU
Thanks

Hello Sims

The size of an IP packet depends directly on the size of the frame it encapsulates. An IPv4 packet size is indicated by the Total Length field in the header, which is a 16-bit field that defines the entire packet size in bytes, including header and data. The minimum size is 20 bytes (header without data) and the maximum is (theoretically) 65,535 bytes.

Even though these sizes are possible, the underlying layer 2 protocol always plays a vital role in the size of IP packets. Specifically for Ethernet, it is the MTU that plays this role, as you correctly stated.

Typically, the size of an Ethernet frame is 1500 bytes + 14 bytes for the header = 1514 bytes. Add to that the 20 bytes of the IP header and you get 1534 bytes. But this can vary, depending on the actual payload, and the limitations of the MTU. The payload of voice packets for example are very small, typically between 30 and 160 bytes in length, while HTTP, FTP, or email protocols may have varying sizes. The relationship between the IP packet size and the underlying MTU can be seen very clearly in this lesson:

I hope this has been helpful!

Laz

Why is there a Protocol field in the IP header? Why does Layer 3 need to know about what Layer 4 protocol is being used?

Hello Jashan

It does seem strange that the IP header should include information about what is contained in its payload. It seems to go against the “separation of roles” that the OSI model advocates. However, it is important for a host that receives an IP packet to know how to interpret the payload as the process of decapsulation takes place. This is necessary because on the wire, the data is nothing but a string of 1’s and 0’s. The receiving endpoint must have a way of interpreting what the next bits of the payload refer to.

Similarly, the Ethertype field in the Ethernet frame header is used to indicate the protocol carried in its payload for the same purpose.

I hope this has been helpful!

Laz

Dears!
Good time,
I didn’t understand the the Header Length -field of IPV4 pakcet header, that how those bits like, 20 bytes, 15 bit and 60 bytes been calculated.
I thank you and appreciate in advance from your help in this regard.

Regards

Ajmal" Ahmadi

New member from Afghanistan

Hello Ajmal

The Header Length field is a field of 4 bits that tells us how big the IPv4 header is. The length is indicated in the number of 32 bit pieces. In order to get the header length in bytes, the value in this field must be multiplied by 4. In order to get the header length in bits, we must multiply by 32. So…

  • For a value of 5, the header length is 5 * 4 = 20 bytes or 5 * 32 = 160 bits
  • For a value of 6, the header length is 6 * 4 = 24 bytes or 6 * 32 = 192 bits
  • For a value of 7, the header length is 7 * 4 = 28 bytes or 7 * 32 = 224 bits
  • For a value of 10, the header length is 10 * 4 = 40 bytes or 10 * 32 = 360 bits

The minimum size of an IPv4 header is 20, so the header length field will have a minimum value of 5, or 0101 in binary.

I hope this has been helpful!

Laz

Hello lagapides,
It’s about header length. The IHL field has only 4 bits so it can hold only 15 numbers as maximum value. I don’t understand where does the 32 bit increment come from? And why can’t we use 1,2,4 as minimum value for multiplying with 32 bits?

Hello Rajaram

The header length field is used to measure the size of the header of the IP packet. But it doesn’t measure it in bits, but in 32-bit blocks. Take a look at the following diagram of an IPv4 header:

Each row of this depiction represents 32 bits of information. Now if we assume that the specific IP packet doesn’t have any IP option information, then the value found within the header length field should be 0101 which is 5 in decimal. This is because the header length is 5 blocks of 32-bits, and you can see these are labeled to the right of the diagram above. Note that all five 32 bit blocks contain header fields that are absolutely necessary, so you will never have a header size less than 5 blocks in size so you will never have a header length field with a value smaller than 5.

Now if the IP option field is not empty, then the header length will increase. But remember, the IP option section only increases by increments of 32 bits. You will never have an IP Option section with a size of say 67 or 84 bits. It will always be 32, 64, 96, 128 and so on. This way, the header length field always measures the number of blocks in the header.

I hope this has been helpful!

Laz

2 Likes

Lazaros,
Thank you, it is clear now.

1 Like

in IP header length we have 4 bit or 5 bit ??.

if i am not wrong,

After fragmentation of an IP packet . The identifier field value remain same for all fragmented packet .and the fragment off set value changes for each fragmented packet …is not it ??

Hello Narad

The header length field of the IPv4 packet is always 4 bits. That means it can have a value between 0 and 15. But remember, it signifies the number of 32-bit blocks that the header contains. When there are no options fields, the actual lowest value that you can have for this field is 5 in decimal or 0101 in binary. This is because that’s the smallest IPv4 header you can have.

The Identification field is used to aid in the reassembly of fragmented IP packets. But it’s not quite as simple as that. This value must be the same for:

  • a given source address
  • a given destination address
  • a given protocol
  • for the duration of the maximum datagram lifetime (MDL) which is typically 120 seconds

The fragments of any fragmented IP packet will have the same source and destination addresses, and of course the same protocol, and must also all be sent within the limit of the MDL. If those criteria are matched, then the ID will indeed be the same for all fragments of the IP packet. What changes is the offset value.

More information bout this can be found at the following links:

I hope this has been helpful!

Laz

It says that TTL value will be decremented by one when every time it passes a L3 node and this is the loop prevention mechanism traditionally in IP header. My questions below,

  1. By default when an IP packet is originated, its TTL is 64 or 255 etc depending on the OS. This means that a packet must travel 64 nodes before its dropped? Is that efficient in internet?
  2. All routing protocols like BGP, OSPF etc have its own loop prevention mechanism, theoretically they sounds much scalable method than TTL . So my assumption is that, TTL in ip header will never be used because routing protocol will take care of loop prevention even before 64hops.
  3. Static route may need to use this TTL for loop prevention. Is there other case scenarios where TTL is in use that you can think of?

Hello Don

The TTL is used as a last resort to ensure that IP packets do not continuously roam the network forever if there is some misconfiguration or network fault. Since it is a last resort, it is rare that it is ever needed to get rid of such packets. In most cases, packets will either reach their destination, will be dropped due to lack of a route, or be dropped due to other loop prevention mechanisms such as those of routing protocols as you mentioned in your post.

The reason the default TTL is set so high is that, first, it is generally accepted that you should be able to reach any destination on the Internet within 30 hops under normal circumstances. But you may have situations when there is a routing problem on the internet that may cause this number to increase. So setting this value to 64 or even 255 ensures that you’re not prematurely dropping packets that would have eventually reached their destination, albeit after an unusually high number of hops. Any packets that do exceed 64 hops are likely not going to reach their destinations, so they are dropped outright.

So it is not considered inefficient, because only a very small number of packets actually get dropped due to TTL reaching zero. Secondly, your assumption that TTL will never be used is almost right in the sense that it is rarely used, because of all the other prevention mechanisms in place.

TTL is definitely needed if you have only static routing in your network, because there are no other mechanisms to prevent loops. So if you create a routing loop with your static routes, then only the TTL will be able to get rid of eternally routed packets.

TTL is extensively used in various other mechanisms including the following:

I hope this has been helpful!

Laz

Thanks Lazaros… This was helpful

1 Like