Understanding IP Fragmentation

Can you imagine eating a whole steak in one bite? Probably not. You have to cut it in pieces and take it little at a time. How about a big project? You can't successfully complete it unless you split it up into multiple little projects and have deadlines for each one. Same goes for TCP segments. When Layer 4 TCP sends a big segment the Network Layer (Layer 3) Fra - gme - nts (fragments) the segments into smaller packets dictated by the MTU (Maximum Transmission Unit) of the outgoing interface. This brings up an interesting issue, how does the receiver know that the packets being received are a smaller chunk of a bigger datagram? How does the receiver know where to place these fragments? What happens if the fragments arrive out of order? Well in this blogtorial we will try and answer all of these questions and take a look at the fragmentation process and how the receiver puts it all together.

Consider this simple topology and let's get started.

The MTU of R1 Fast 1/0 is 1500 bytes and R1 sends a 5920 byte segment. Before we can tackle the fragmentation, first let's take a look at the IP Header and understand the FLAGS and other fields that are pertinent to fragmentation.

Side note - Cisco IOS does not take into consideration the 14byte Layer 2 header so in reality the length of the actual packet will be 1514 bytes which will be passed through the interface with a 1500 byte MTU setting.

The main fields that we are concerned about are the Fragmentation ID, FLAGS and the FRAGMENT OFFSET Field.

Fragmentation ID - This will be the set to the same value for a set of fragments in a datagram.

DF = Don't Fragment Bit -- If this is set to 0, then the packet can be fragmented into smaller chunks. If it is set to 1 and the outgoing interface MTU is smaller than the packet size then the packet should not be fragmented, but discarded and an ICMP Fragmentation Needed Type 3, Code 4 message must be sent back (This is how PATH MTU DISCOVERY works).

MF = More Fragment Bit -- If this is set to 0 then there are no more fragments. If this is set to 1 then there are more fragments in flight.

Fragment Offset -- This states where the packet should be placed. We'll see more on this below.

So let's go back to the segment with a data size of 5,920 bytes and see how it would be fragmented. Here is what it would look like.

By knowing the last packet's length and the offset you could calculate the entire fragment datagram size. For example, 1480 (last packet's data length) + 555 (last packet's fragmentation offset) * 8 = 5,920.

So let's say that packet 3 is received before packet 2 then how does the receiver know to reorder packet 3 and where to place it in the stream? This is where fragment offset comes in -- fragment offset of packet 3 is 370 so the receiver takes 370 * 8  = 2960 and the packet 3 will be placed after 2960 (packet 1 with 1480 data length + packet 2 with 1480 data length) so packet 3 will be placed after packet 2.

First packet of a fragment will always have the MF Bit set to 1 and the fragment offset set to 0. The last packet of a fragment will always have the MF Bit set to 0.

Notice that the fragment offset is 13 bits so 2 ^ 13 = for a maximum offset of 8192. 8192 / 185 = answer * 1480 (packet size before the IP header 20 bytes is added) = 65536 (the maximum allowed in an IP Packet Payload).

Many more articles to come so stay tuned.

Please reshare/subscribe/comment/+1 if you like my posts as it keeps me motivated to write more and spread the knowledge.