IPv4 Packet Header

Looks like Typo in Total length field for max. Size , should be 65535 bytes

It is:

maximum size is 65.535 bytes

Hi Rene,

What is the maximum packet size that can be sent out to internet without fragmenting? According to what you have explained above, an IP header can hold up to 65535 bytes. So can we change the MTU of Ethernet to support this value?

Hi Rakesh,

It really depends on your connection and ISP but as a rule of thumb, it’s best to stick to a MTU of 1500. Decrease it if you use anything that adds additional overhead like IPsec, PPPoE, etc.

Ethernet supports a MTU of 1500 by default, if it supports Jumbo frames then you can go up to MTU of 9000.

Rene

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