IP Fragmentation and Reassembly
Asked Answered
I

4

25

I am currently going through my networking slides and was wondering if someone could help me with the concept of fragmentation and reassembly.

enter image description here

I understand how it works, namely how datagrams are split into smaller chunks because network links have a MTU. However the example in the picture is confusing me.

So the first two sections show a length of 1500, because this is the MSU, but shouldn't this mean that the last one should have 1000 (for a total of 4000 bytes) and not 1040? Where did these extra 40 bytes come from? My guess is that because the previous two fragments both had a header of 20 bytes, this extra 40 bytes of data needed to go somewhere, so it will arrive in the last fragment?

Fragflag essentially means that there is another fragment, so all of them will have a Fragflag of 1 except the last fragment which will be at zero. However I don't understand what offset is or how it is calculated. Why is the first offset at zero? Why did we divide the bytes in the datafield (1480) by 8 to get the second offset? Where did this 8 come from? Aside from that, I am assuming that each fragments offset will just increase by this value?

For example, the first fragment will have a offset of 0, the second 185, the third 370 and the fourth 555? (370+185)

Thanks for any help!

Irruption answered 14/4, 2013 at 13:43 Comment(0)
M
21

There is a 20 byte header in each packet. So the original packet contains 3,980 bytes of data. The fragments contain 1480, 1480, and 1020 bytes of data. 1480 + 1480 + 1020 = 3980

Every bit in the header is precious. Dividing the offset by 8 allows it to fit in 13 bits instead of 16. This means every packet but the last must contain a number of data bytes that is a multiple of 8, which isn't a problem.

Mephistopheles answered 14/4, 2013 at 14:11 Comment(3)
Thanks! That answered the first part of my question clearly, but as for the second part, why are we dividing 1480 by 8 to get the offset?Irruption
Great thanks a lot, that answers everything! I'm just wondering though, do we ALWAYS divide by 8? Are there any circumstances that would cause us to divide by a different number?Irruption
@JimmyK: If we were trying to comply with some standard other than IPv4.Mephistopheles
I
17

The fragmentation and Reassembly has been exclusively explained in the RFC 791. Do go through the Internet Protocol Specification RFC. The RFC has various sections explaining the sample fragmentation and reassembly. All your doubts and questions are well catered in it.

Ans 1: Regarding the lengths of the packet: The original Packet contains 4000 Bytes. This packet is a fully IP packet and hence contains the IP header as well . Thus the payload length is actually 4000 - ( IP Header Length i. e. 20 ).

Actual Payload Length = 4000 - 20 = 3980

Now the packet is fragmented owing to the fact that the length is greater than the MTU ( 1500 Bytes).

Thus the 1st packet contains 1500 Bytes which includes IP header + Payload Fraction.

1500 = 20 ( IP header ) + 1480 ( Data Payload )

Similarly for the other packet.

The third packet shall contain remaining left over data ( 3980 - 1480 -1480 ) = 1020

Thus length of the packet is 20 ( IP Header ) + 1020 ( payload ) = 1040

Ans 2: The offset is the address or the locator from where the data starts with reference to the original data payload. For IP the data payload comprises all the data thats after the IP header and Options header. Thus the system/router takes the payload and divides it into smaller parts and keeps the track of the offset with reference to the original packet so that reassembly can be done.

As given in the RFC Page 12.

"The fragment offset field tells the receiver the position of a fragment in the original datagram. The fragment offset and length determine the portion of the original datagram covered by this fragment. The more-fragments flag indicates (by being reset) the last fragment. These fields provide sufficient information to reassemble datagrams. "

The fragment offset is measured in Units of 8 bytes each. It has 13 bit field in the IP header. As said in the RFC page 17

"This field indicates where in the datagram this fragment belongs.The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero."

Thus as you asked in the question where did this 8 come from, its the standard thats been defined for IP protocol specification, where 8 octets are taken as one value. This also helps us to transmit large packets via this.

Page 28 of the RFC writes: *Fragments are counted in units of 8 octets. The fragmentation strategy is designed so than an unfragmented datagram has all zero fragmentation information (MF = 0, fragment offset = 0). If an internet datagram is fragmented, its data portion must be broken on 8 octet boundaries. This format allows 2**13 = 8192 fragments of 8 octets each for a total of 65,536 octets. Note that this is consistent with the the datagram total length field (of course, the header is counted in the total length and not in the fragments).*

Intitule answered 22/7, 2014 at 6:32 Comment(0)
J
2

the offset size is 13 bits in the IP header but we need 16 bits as in worst case. So we use a scaling factor of 8 i.e. (2^16/2^13).

Justen answered 23/4, 2013 at 15:42 Comment(0)
T
0

those are not extra bits but the total length of last fragment. as 1500 is MTU this means there can be 1500 byte of data in one fragment including header. Header is appended with every fragment. this means in fragment we are capable of sending 1500-20 =1480 byte of data. it is given there is 4000B datagram .datagram is nothing but a packet encapsulation of data at network layer.so the total data we have to send is 4000-20=3980 . then it is fragmented into 3parts (ceil(3980/1480)) each of length 1480,1480,1020 respectively . hence when 20B header is appended to last fragment its length becomes 1020+20=1040 .

Taxpayer answered 27/4, 2017 at 8:41 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.