Does a host re-order fragmented IP packets received out of order?

2

1

Host A sends a 1400 byte IP packet to Host B over an Ethernet and PPP link. The PPP link has an MTU of 532 bytes, which means that the IP packet will be fragmented into 3 smaller packets.

Fragment 1 is received first. It has a unique ident and the M bit flag is set, indicating there are more fragments to come. However, fragment 3 is received next, due to some re-ordering in the network. This fragment has the same ident as fragment 1, but the M bit is not set, because it's the last fragment. Fragment 2 is received shortly after.

What will the receiving host do?

  1. Will the receiving host know that the offset and packet length do not match up, and assume an intermediate packet has been either dropped or re-ordered in the network, and wait for it?

  2. Will the receiving host reassemble the packet (both the header checksums match) and pass it to the higher layer (where it will fail an IP checkum over the data if using UDP/TCP).

  3. Will the receiving host drop all fragments for this ident.

user376151

Posted 2015-04-09T13:19:43.747

Reputation:

Answers

2

The receiving host knows that there are lost fragments and waits until a reassembly timeout expires. Unless the lost fragments arrive, the fragments are dropped.

RFC 791 in section 3.2 defines that :

If the timer runs out, the all reassembly resources for this buffer identifier are released. The initial setting of the timer is a lower bound on the reassembly waiting time. This is because the waiting time will be increased if the Time to Live in the arriving fragment is greater than the current timer value but will not be decreased if it is less. The maximum this timer value could reach is the maximum time to live (approximately 4.25 minutes). The current recommendation for the initial timer setting is 15 seconds.

This reassembly timeout for IPv4 and IPv6 on Linux is 30 seconds and for Windows (Vista, 2008, 7 and 2008 R2) is 60 seconds according to section 4.5 of RFC 2460:

If insufficient fragments are received to complete reassembly of a packet within 60 seconds of the reception of the first-arriving fragment of that packet, reassembly of that packet must be abandoned and all the fragments that have been received for that packet must be discarded.

jcbermu

Posted 2015-04-09T13:19:43.747

Reputation: 15 868

You do realize that RFC 2460 defines IPv6, right? In normal usage, IP == IPv4. IPv6 is different. – a CVn – 2015-04-09T14:00:07.367

@MichaelKjörling a packet in TCP will timeout long before then, would it be correct to think that the reassembly timeout must be preceded by high layer protocols? – None – 2015-04-09T14:03:51.743

@GeorgeRobinson, if I'm understanding your question correctly, yes, the higher the timeout is in the protocol stack, the shorter the timeout must be, because if a lower layer timeout occurs first, the higher layer will never get the opportunity to handle it. I had a webservice which accesses a database and absolutely MUST return false if any failure occurs, but due to issues on the hoster end, during times of high usage, the DB connection would time out. I had to arrange the timeouts such that the DB timeout was assumed before the SOAP timeout window occured so that the caller would get False – Frank Thomas – 2015-04-09T14:08:58.730