1

I'm rolling off my own TCP/IP stack for DOS and I have a question on IPV4 packets.

Assuming that a client sends multiple IPV4 fragments, I would predict the MF flag would be set for every fragment except the last fragment.

I have it set up where I have a 64KB memory space so fragments can arrive in any order.

Is it a requirement for clients of any type to send the fragments in sequential order from first set of bytes to last set of bytes? or can clients send any fragment in any order (like for example, last fragment first, and first fragment last) and even skip some fragment offsets (for example, sending a 1000 byte fragment at offset 0 then sending another 1000 byte fragment at offset 3000 and no fragment at an offset in-between)?

Improve this question
1
  • Did any answer help you? if so, you should accept the answer so that the question does not keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin ♦
    Dec 23, 2021 at 16:43

2 Answers 2

Reset to default
2

I have it set up where I have a 64KB memory space so fragments can arrive in any order.

A 64K buffer is actually a mistake because it leads to a particular fragment attack where the bad guys can send packets that add up to more than 64K, causing a buffer overflow.

Is it a requirement for clients of any type to send the fragments in sequential order from first set of bytes to last set of bytes?

Packets are fragmented by the routers in a path when the MTU shrinks from one network to the next, and the packet is too large to fit the new MTU. The fragments are sent in order, but there is no guarantee that they will arrive in order, and out of order packet reception can happen at any time. Packets can, and do, go missing all the time, and you need to drop a packet with missing fragments.

Improve this answer
0

Is it a requirement for clients of any type to send the fragments in sequential order from first set of bytes to last set of bytes?

They are sent that way (naturally, not required) but they might not be received in that order.

Fragments might even get lost which requires you to drop the rest of the packet after some timeout.

Beware of malicious or faulty fragments breaking the 2^16 byte limit, trying to cause a buffer overflow.

Fragmentation and reassembly are detailed in RFC 791.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.