IPv4 Packet Header

Hi Jon/Laz,

Many Thanks. Could you please make me clear on some issue …

  1. Since Datalink layer has Many Encapsulation except Ethernet like HDLC,PPP,Frame Relay. So what is the role/Job of HDLC/PPP header FCS ?? It will check Integrity like ETHERNET FCS do ??

  2. Suppose A packet travelling from Source To Destination with diffrent L2 link(Ethernet, Serial Link) on different segment so what problem will raise ??

Appreciate your quick response here .Thanks


Hello Mohammad

Concerning your first question, the FCS for all layer two protocols plays the same role whether Ethernet, PPP or HDLC. It checks for integrity of the frame.

Concerning your second question, a packet that travels over multiple L2 protocols does not present any problems. This is because the FCS that is created for each hop of the trip is created and stripped off during that hop.

For example, a frame leaves a PC and hits a router’s interface. As it is being encapsulated at the PC’s NIC, an FCS is created and added at the end. When the router receives it, the Ethernet header is removed and the FCS is checked. If it passes, then the packet is prepared for routing.

Let’s say the second hop of the trip is over a serial link using HDLC. The packet is RE-ENCAPSULATED with a NEW HDLC header and a NEW FCS. This new frame is placed on the serial link. When it is received by the router on the other end of the HDLC link, the HDLC header is stripped and the FCS is checked. If it passes, the packet is then prepared for further routing.

So you see that the FCS at layer two has only local significance. That is, it is only used for the specific hop. Once the hop is over, the FCS is discarded and is not used again. A new FCS is created for the next hop of the journey.

I hope this has been helpful!


Hi Rene,
**I want to know from you** regarding my first question “Why each layer Checksum is essential whereas Ethernet FCS ensuring Header & Payload ok or not” . I am facing some confusion on it . My understanding is …

  1. No need IP Header Checksum and TCP/UDP Checksum since Ethernet FCS ensuring the Header and payload is ok or not .
  2. I think IP Header Checksum and TCP/UDP Checksum has used for further layer checking .There is LOGICAL issue behind this .
  3. The only reason could be “Layer 4 and Layer 3 don’t trust lower layer”

**Suppose Only Ethernet FCS exist on header and there is no checksum on L3 and L4 header. So what will happen . It will raise any issue ??**

Correct me in your clear text if i an wrong . Need your assistant badly .Thx


Hi @Zaman.rubd,

It’s great to see you wanting to get so deep in the understanding here. I think it’s important to consider two points:

First we must accept, checksums exists at multiple layers. They exist by design and normally we should not be concerned about them; we simply let them do their job :slight_smile:

Secondly, let’s imagine a hypothetical scenario where we send an IP packet from one city to another using an IP satellite link and only Ethernet FCS is used; no other FCS is allowed.

  1. We place the packet on our local Ethernet LAN and create an Ethernet FCS.
  2. When the IP packet arrives at the satellite terminal (e.g. VSAT), the Ethernet is removed and the Ethernet FCS is lost.
  3. The packet is now sent on the satellite link and becomes corrupted. There is no Ethernet FCS on this link so this corruption can not be detected.
  4. When the packet arrives at the destination it is then placed onto the Ethernet LAN and a new Ethernet FCS is created.
  5. The packet is received by another host who believes the Ethernet FCS is correct but does not understand why the data appears to be corrupted.

Of course this hypothetical situation produces an unacceptable outcome so it makes life much simpler if each OSI layer manages its own FCS. In this way we are sure that there is always at least one FCS. If there is more than one, we have duplication but we can consider it acceptable.

In summary, we are making a trade-off : simplicity + reliability vs. efficiency

I hope this helps. Kind regards,

Hi Rene,

Can you please explain the Time to Live, exactly how it works in real time.


Hello Praveen

The TTL field in the IP header is a field that contains a value that is decremented every time a packet is relayed by a router. For example, imagine a network with three routers:


PC1 sends a packet to PC2. The packet has an initial TTL value of 64 (this is the default value in most cases, although this can be changed). When the packet reaches

* R1, it will be routed, and the TTL will be decremented, so TTL =63
* at R2, the packet will be routed and TTL will now be TTL= 62
* at R3 the packet will be routed and the TTL will now be TTL = 61

The purpose of this is to prevent incorrectly routed IP packets from remaining in a network forever. If there is a routing loop, packets will be routed continuously between routers until TTL equals 0. When a router receives an IP packet with TTL = 1, it will decrement the vlaue to 0 and discard the packet.

I hope this has been helpful!


Thanks alot Lazaros, Now i understood clearly.

Hi Rene,

Can you explain me the below mentioned topics in IPv4 header in detailed.I am having lot of confusing between bit and bytes in this ipv4 header topic and how they are calculated

Header Length

Total Length


IP Flags

Fragment Offset

Hi Ganesh,

The header length can be a bit confusing. It specified the length of the IP header but we only have 4 bits. With 4 bits, you can create values between 0 and 15, that’s it.

How it works is that each bit represents a 32-bit increment. An IP header has a minimum length, which is 20 bytes.

1 byte = 8 bits so:

20 bytes = 160 bits

160 bits / 32-bit increments = 5

So by setting the header length to 5, we know that the length of the IP header is 20 bytes.

The total length and Identification are simple, these are both 16 bits so we can store values from 0 - 65535 here.

Let me explain the total length, identification, ip flags, and fragment offset with an example.

Let’s say this is our original IP packet:

Sequence Identifier Total Length Don’t Fragment More Fragments Fragment Offset
0 321 5140 0 0 0

This packet is 5140 bytes but that includes a 20 byte IP header. The data portion is 5120 bytes. This packet gets fragmented. Here are our fragments:

Sequence Identifier Total Length Don’t Fragment More Fragments Fragment Offset
0-0 321 1500 0 1 0
0-1 321 1500 0 1 185
0-2 321 1500 0 1 370
0-3 321 700 0 0 555

How did we come up with these values?

The identifier remains the same in all fragments. The first three fragments have the “more fragments” switch enabled.

* The first fragment is 1500 bytes but that includes 20 bytes for the IP header so the “data portion” is 1480 bytes.
* The second fragment is also 1500 bytes and the offset is 185:

  • 185 x 8 = 1480
  • This means the data portion of this fragment starts 1480 bytes into the original IP packet.
    * The third fragment is also 1500 bytes and the offset is 370:
  • 370 x 8 = 2960
  • This means the data portion of this fragment starts 2960 bytes into the original IP packet.
    * The fourth (last) fragments is 700 bytes and the offset is 555:
  • 555 x 8 = 4440
  • This means the data portion of this fragment starts 4440 bytes into the original IP packet.

Once we receive the last fragment, we can tell what the size of the original IP packet is. The offset is 555 which means we start 4440 bytes into the original IP packet.

Now take the data bytes from the last fragment: 700 bytes - 20 bytes for the IP header = 680 bytes.

4440 + 680 = 5120 bytes. That’s the length of the data portion of the original IP packet.

I hope this helps!


1 Like

Thanks Rene for your reply.Please dont mistake me as i asking some of basic questions

I can understand the length of the IP header is 4 bits.but I am having a lot of confusion between bits and bytes calculation.

1bit==can be either 0 (or) 1

if its 4 bits then it should either 0101 if i convert that number from binary to decimal i get 5.

I am not sure whether my understanding is correct or not.please guide me Rene

IP header:

Here as you said 4bits and with that you can create value between 0 and 15. I want to know how these value are determined?

You say each bit represent a 32 bit increment

Total Length:

total length are 16 bits so we can store values from 0 - 65535 here.I want to know how these value are determined?

Fragment offset:

How fragment offset value 185,370,555 was determined?

Hello Ganesh,

1 byte is 8 bits.

With 4 bytes, we have the following possible options:

* 0000 = 0
* 0001 = 1
* 0010 = 2
* 0011 = 3
* 0100 = 4
* 0101 = 5
* 0110 = 6
* 0111 = 7
* 1000 = 8
* 1001 = 9
* 1010 = 10
* 1011 = 11
* 1100 = 12
* 1101 = 13
* 1110 = 14
* 1111 = 15

From 0 to 15, that’s 16 different values. Keep in mind we count from 0…not from 1.

For whatever reason, they decided to only use 4 bits for the header length so if you want to fit a value like “160” in those 4 bits, it’s impossible. That’s why they use a “multiplier” of 32.

So if you have a header that is 20 bytes, you first calculate it to bits: 20 * 8 = 160 bits.

Then you divide 160 / 32 (the multiplier) and you have a value of 5. We set the value of 5 in those 4 bits and that’s it.

With 16 bits, you have 65536 different values…starting at 0, ending with 65535. Because we have enough bits, you don’t need to use a multiplier here. You can just set the value you want and that’s it.

Fragmentation is done on an 8-byte boundary so what we do, is we take the “data portion” of the packet and divide it by 8. For the first fragment, that is:

1480 / 8 = 185

Does this help?


Continuing the discussion from [IPv4 Packet
As it is my first post i would like to thanks networklessons.com team, and i have a question regarding what is the difference between Ipv4 packet header, header length (as you mentioned the maximum number we can get is 60 bytes so where does the total length come from), total length, and i am totally confused what is IP flags (what do DF and MF mean), Fragment Offset and IP options.

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!


Hello Lazaros

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


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!


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!


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

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!