IPv4 Packet Header

Hello Rene,
As this is my first post, I would like to thank you for sharing all this knowledge and thank you for your efforts and explanations.

I am having a hard time understanding the "Header length " section. The entire section starting with:

Header Length: this 4 bit field tells us the length of the IP header in 32 bit increments.

Thank you in advance for your response.

Hi Romani,
Welcome to the forums!

The key to understand the necessity of Header Length is to realize that with IPv4 the size of the header is not fixed (like it is in IPv6). The size of the IPv4 header must be at least 20 bytes, but it can be bigger, too. What makes it bigger are the additions of “options.” To learn more about options go here

Since the size of the IPv4 header is variable, the purpose of the Header Length is to specify just how big it actually is, but there are rules as to what sizes are allowed. As mentioned earlier, the minimum is 20 bytes, and the maximum is 60 bytes, but in-between those values, the size is only allowed to increase in increments of 4 bytes (since 8 bits = 1 byte, 32 bits = 4 bytes). So, for example, the possible sizes (in bytes) are 20, 24, 28, 32, … 60.

The actual value of the “Header Length” field is a binary number that represents how many sets of 4 byte “blocks” there are (or how many sets of 32 bit “blocks” there are–its the same thing). Remember, we said a minimum value was 20 bytes? How many “4 byte blocks” are there in 20 bytes? 5, right? So 5 would be the minimum value for Header Length. In the case of the maximum header length, it would be 15.

Finally, remember that actual value in the Header Length is a binary number–specifically with 4 bits. That means the largest possible value is “1 1 1 1” which in decimal = 15. This is also the limit of the maximum header size–60 bytes.

3 Likes

Thank you Andrew! Yes, you explanation made it clear.

1 Like

Im Totaly confused about the byte , bit calculations in header length & total length , Would you be able to simplify that?

my second question , I read in web the below.

"Fragment offset provides fragmentation and reassembly if the packet is too large to put in a frame and allows maximum transmission unit of the internet:

does it mean the fragment offset will help to allow if the packet size is greater than MTU?

Hello Ajay.

The Header Length is a 4 bit field. That means that it can represent numbers from 0 to 15. The minimum number that the field can have however is 5. The resulting header length is calculated with the following formula:

Length = Header Length * 32 bits

If the value of the Header Length field is the minimum, that is 5, then:

Length = 5 * 32 bits = 160 bits = 20 bytes

If the value of the header length field is the maximum, that is 15, then:

Length = 15 * 32 bits = 480 bits = 60 bytes

The total length is the length of the whole packet. This is a 16 bit field, so it can have numbers between 0 and 65535. These numbers represent bytes directly. The minimum size you can have is 20 bytes and the maximum (theoretically) is 65535 bytes.

Finally, concerning your question about fragmentation, the fragment offset indicates where the fragmentation took place in the frame. This is used to help reassemble fragmented frames. In essence, you are correct in your statement.

The MF flag is also used to aid in reassembly of the fragmented frame. If set to 1, it indicates that additional fragments of the frame will follow. The DF flag indicates that the frame should NOT be fragmented. If the MTU is too small, the frame is just dropped.

I hope this has been helpful!

Laz

1 Like

Thanks Laz , Great information However im a bit confused even after this.Let me point out below & bear with me if im being naive.

In your statement “The total length is the length of the whole packet. This is a 16 bit field, so it can have numbers between 0 and 65535. These numbers represent bytes directly. The minimum size you can have is 20 bytes and the maximum (theoretically) is 65535 bytes.”

Question 1 : If its a 16bit field , it should be 2 the power of 16 = 65535 bIts not bytes as you mentioned , Correct me if im wrong.

Question 1: If we receive a packet the size of 9000 & my MTU set as 2000 (In a storage network , suppose im dealing with Netapp) what is the case of DF bit here , If the DF bit set to 0 then the packet will be fragmented with out any issue. If then why this is causing performance issues & latency in network?

Ajay,
The Total Length field represents the size in bytes. A 16 bit field has a maximum numeric (decimal) value of 65,535, but that value is just a number. The meaning of that number is “how large is this packet in BYTES.”

If you receive a packet of 9000 and receiving MTU is less than that, you MUST have DF=0 otherwise the packet will be dropped. As you correctly point out, with DF=0, the packet will be fragmented, but that doesn’t mean it won’t be “without issue.” In this case a performance hit would be expected for two reasons:

  1. The act of fragmenting consumes resources and increases the amount of packets being sent between sender and receiver
  2. In your example, the highest possible MTU available is 2000. This results in a much smaller amount of data (less than 25%) being carried per packet as opposed to a 9000 MTU. All of these extra packets take both time and require overhead resources to process.
3 Likes

Thanks Andrew , Now its clear…

1 Like

19 posts were merged into an existing topic: IPv4 Packet Header

Hlw Rene,

Thanks a lot, you are amazing :slight_smile:
It is very basic question still curious to understand with your plain examaple .
I want to know about the TCP Checksum/UDP Checksum/ IP Header Checksum and Ethernet FCS .
1.TCP Checksum= It will ensure TCP Header and Data is ok or not ??
2.UDP Checksum= It will ensure UDP Header and Data is ok or not ??
3.IP Header Checksum= It only ensure the IP Header is ok or not ?? It will not ensure upper layer TCP Segment or UDP Datagram is ok or not ??
4. Ethernet FCS= It will ensure all is ok or not ? Here “all” means Ethernet Header + IP Header+TCP/UDP Header + Data. Also why we dont see the FCS field when capture.

Appreciate your plain example as always .Many Thanks

br//
zaman

Hello Mohammad

I will attempt to answer your question below:

Yes, youa re correct. It is however considered a relatively weak error detection method by modern standards, but is sufficient in combination with additional error checking functionalities both below and above the transport layer.

You are also correct concerning the checksum of the UDP checksum. The only difference is that in IPv4 this field is optional for UDP while in IPv6 it is mandatory. It functions in exactly the same way as the TCP checksum.

Correct. It only checks the integrity of the IP header and not the payload. It plays no role in ensuring upper layer segments or datagrams.

The Ethernet frame FCS will ensure the integrity of the whole frame including header and payload. It doesn’t check the individual headers of each of the upper layers because it doesn’t discern them as such, but it just sees them all together as the payload.

As for the FCS on Wireshark, Ethernet NIC cards often filter the preamble and the FCS so they don’t pass on that information to Wireshark. Some interfaces may have the capability of being configured to send this info, however, in most cases you won’t see it.

I hope this has been helpful!

Laz

Many Thanks Laz, I have another question regarding .why checksum has added at each layer. If Ethernet Checksum OK then we can say everything is OK , right ? Because it indicate all header and payload .so why header and payload will be check at each layer.Pls help me to understand it .Appreciate your reply as always.Thanks

Hello again Mohammad.

When any communication is initiated from source to destination, the contents of some network layers change for every hop and some do not change. So, you need some sort of integrity check at different layers to account for that. Let’s look at the following example:

Your PC with IP address 10.10.10.10 is sending an email to the email server with an IP address of 10.10.20.20. The encapsulation takes place like this:

Layer 4 TCP checksum checks the header and payload
Layer 3 IP header checksum checks only the IP header integrity
Layer 2 Ethernet FCS checks header and payload
Layer 1 Placed on the medium

Now because the destination is in another subnet, the PDU must be sent to the default gateway. The default gateway does some decapsulation as well:

Decapsulation:
Layer 2 Check Ethernet FCS and if approved, decapsulate further
Layer 3 Check IP header checksum and if approved, check destination IP addresses and determine routing

The PDU must now be reencapsulated
Layer 2 Create a new Ethernet Header with new Source and Destination MAC addresses and a new FCS
Layer 1 Place on the medium

Now the PDU has reached the subnet in which the email server is, so when it reaches the destination, decapsulation takes place again:

Layer 2 Check Ethernet FCS and if approved, decapsulate further
Layer 3 Check IP header checksum, and if approved, check IP destination address and confirm packet is for me
Layer 4 Check TCP checksum and confirm integrity of segment
Further decapsulate to the application layer.

So you should see from the above that the layer 2 FCS is necessary for EVERY hop that takes place, and it is actually recalculated every time!! The Layer 3 IP header checksum is checked every hop to confirm that the header is correct so that the destination IP address can be read and routing is determined. The Layer 4 TCP checksum is only checked at the destination to make sure the payload has no errors.

So once again, layer 2 changes every hop, layer 3 does not change but must be checked for correct routing, and layer 4 is checked only at the destination. So that’s why we need different integrity checks for different layers of the OSI.

I hope this has been helpful!

Laz

1 Like

Hi Laz/Rene,

Thanks for your valuable reply.:+1:
One more question , If FCS ok then we can say everything (Ethernet Header + IP Header+TCP/UDP Header + Data ) is ok, right ?? or Is there any possibility that FCS approved/ok but IP Header Checksum or TCP/UDP checksum not ok ??? . If so then I think Different layer Checksum is mandatory otherwise not Mandatory. Just imagine , only FCS exist on ethernet and no other checksum(IP/TCP/UDP Checksum) on upper layer then what will happend on Intermediate device , They will face any issue ?? lets give an example source host(A) sending data with his computed TCP checksum, IP checksum and CRC value, consider there is problem in physical medium so there is chance to corrupt . now receiving device either transit router or final destination host unwarp / looking the Layer 2 information and compute CRC algorithm for validate to payload since my data is corrupted its dropped it there itself so no need to go to next level.

if there is any flip in TCP layer - > L2 CRC can able to identify while computing in L2 level , so why need each layer Checksum ??
Again,
like if there is any flip in IP layer - > CRC can able to identify while computing in Layer 2 level , so why need each layer checksum whereas L2 CRC can identify everything. I really appreciate your more clarification again.Thanks

br//zaman

Hi @Zaman.rubd

If FCS ok then we can say everything (Ethernet Header + IP Header+TCP/UDP Header + Data ) is ok, right ?? or Is there any possibility that FCS approved/ok but IP Header Checksum or TCP/UDP checksum not ok ?

The answer is Yes and also No.

The FCS is based on a hashing function so there is an extremely small possibility that the Ethernet FCS could be correct but the payload has been corrupted. However the probability of this is so small that we can safely ignore it.

In most cases a damaged frame would be damaged during transmission or in transit. Since a very high percentage of interfaces and links currently use Ethernet, the Ethernet FCS is an efficient way to detect corruption.

However, Ethernet is not used on every link and on every interface. At some point the TCP segment or IP packet may be passed over a different (non-Ethernet) L2 link so we must have a method to check integrity in those situations also.

Best regards,
Jon

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

br//zaman

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!

Laz

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

br//zaman

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,
Jon