# Understanding how IP Reassembly Process works

I'm trying to understand IP fragmentation and reassembly processes well. I found this example on the Internet that I guess would be useful to understand the topic.

Suppose a certain computer recieves the following sequence of datagrams (the columns in English would be: Source IP address, ID, MF, DF, Offset, Total Length, Protocol):

I believe 5 original un-fragmented datagrams were sent:

1. ID 454, IP 48.143.25.12 (entries 1, 2, 7)
2. ID 630, IP 245.36.22.141 (entries 6, 11, 13)
3. ID 43, IP 212.203.92.105 (entries 3, 4, 5, 8)
4. ID 44, IP 212.203.92.105 (entries 10, 12)
5. ID 43, IP 93.46.25.4 (entry 9)

My analysis has been the following:

1. I think the second fragment of this datagram was lost, so it will be discarded (the fragment with the least offset has an offset of 368*8 = 2944 bytes, but the first fragment has only 1472 bytes of data, so something in the middle was lost).
2. This datagram is reassembled correctly, as all three fragments were recieved and the offsets assort. The complete datagram would be reassembled using fragments 6, 11 and 13, in that order.
3. This datagram is also discarded, because at least two fragments were lost (there is no fragment with MF = 0 and there is no fragment with offset = 184, so the second one was also lost).
4. This one is correctly reassembled, using fragments 10 and 12, in that order.
5. Only a single fragment is recieved, and it has offset, so the first fragment was lost and the datagram will be discarded.

So I have three questions:

• Is the analysis made above correct? Is there any mistake you can spot?
• I noticed that in the 5th fragment recieved, the total lenght is less than for the rest (and is not the last fragment), so I believe that fragmentation took place in the middle of the path. How would the reassembly process work in this case? I'm not sure what the offset field would be, as now there would be sub-fragmented datagrams, and that confuses me big time.
• IP level of the computer would pass the information recieved to the UDP level. In those cases in which fragments are lost, is the IP level the one responsible for discarding the fragments related to the same uncomplete datagram, or does it pass this informaton to the UDP level and this is the one that discards them?

You have them all correct.

5th fragment: remember that the routers can change their settings at any time, and the fragmentation limit can change from one packet to the next. When you fragment already fragmented packets, you normally see something like this:

• original sends (say) 4001 byte packet
• through something which fragments it into three: 2000, 2000, 1.
• through something which fragments it into 5: 1600, 400, 1600, 400, 1.

This big-small-big-small is characteristic of fragmented fragments. Normally reassembly is only done at the final host, or a host doing security or NAT. (Note that the fragements can overwrite other fragments, which has had some security implications. I believe most current IP stacks will discard such funny-fragment packets.)

The IP layer discards the bad packet, perhaps sending ICMP problem report. It never gets to the UDP-handling layer.

I do recommend reading RFC 791 on fragmentation and reassembly. https://tools.ietf.org/html/rfc791