IPv4 Packet Header

Lessons Discussion
1

This topic is to discuss the following lesson:

1 Like
2

Hello Rene,
Could you please help on below queries

How network layer decides whether a packet to be fragmented or not?
Is it possible for a admin/application to enforce a fragmentation decision on IP packet?
Is there any relation between total length field and mtu?

1 Like
3

Hi Ashok,

I wrote a post on this, I think it will answer your questions:

https://networklessons.com/ip-routing/pppoe-mtu-troubleshooting-cisco-ios/

Rene

4

Thanks a lot Rene… It was well explained there…

5

Hi Rene,

Why Header maximum length limited to 24 bytes ?

As per the theory, For 5 bit header field , maximum value is 15 so header length will be 4* 15 = 60 bytes.

Please correct me if it is limited to 24 bytes in production.

Regards,

SV

 

6

Hi SV,

Good question, some sources (for example Routing TCP/IP Volume 1) state that the maximum header length is 24 bytes so that 6 would be the maximum value. I can’t find any proof for this, it’s not in the RFC.

I just updated the lesson, with 4 bits, the highest value we can create is 15 so 15x32 = 480 bits (60 bytes)

Thanks for the input!

Rene

7

Hi Rene,

According to IPv4 Packet :-
1 - The identification field size refers to the number of files that we can transmit through one TCP connection so the max number of files = 2^16 = 65536 file.
2 - The fragment Offset filed size refers to the each file size so the maximum file size that we can transmit = 2^13 * maximum packet size = 8192 * 65536 = 536870912 bytes ( ~ 536 megabytes ).
Please correct me if what I have learned was wrong, and if it’s right what will happen if the number of files exceed 65536? and the maximum file size exceed 536870912 bytes?

Thanks in advance,
Hussein Samir

8

Hi Hussein,

The identification field is only used for fragmentation. When packets get fragmented, the fragments get the same identification field to identify which fragments belong to the same IP packet. It’s only used for identification, it doesn’t have anything to do with the number of files. Take a look at this capture:

Wireshark capture fragmented ICMP traffic

The fragment offset only refers to the position of the fragment in the original IP packet.

Rene

1 Like
9

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

10

It is:

maximum size is 65.535 bytes

11

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?

12

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

13

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.

2 Likes
14

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.

9 Likes
15

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

1 Like
16

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

17

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?

18

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

3 Likes
19

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?

20

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.
4 Likes