# Calculating Fragmentation offset doubt

Suppose we have a data of 4500 bytes which passes through 2 routers of MTU 2600 and 1400 respectively. What will be the resulting fragments at the 2nd router (1400 MTU one)?

The 4 fragments at 2nd router will be

`<1380,20>` `<1196,20>` `<1380,20>` `<544,20>`

Here each pair is `<IP data, IP header size>` and MTU size is `1400`.

We have to make all fragment sizes as multiple of eight and not necessarily the last one.

Now do we remove the 4 bits from the first fragment and add it to 2nd fragment immediately and make it <1200,20> or do we keep on removing 4 bits from each of the fragments and add it to the last fragment making the second fragment as <1192,20>?

Which one is correct?

Also, I don't understand when to pad bits and when to remove bits to make it a multiple of eight.

By default, should we try to pad bits first or remove bits first?

Edit:

Since you completely changed the question (very bad form), I will attempt to answer the new question.

You are still very confused about how fragmentation works. With an original payload of `4500` octets passing through a router to a network with an MTU of `2600` you would get:

1. `20` octet IPv4 header and `2576` octet payload
2. `20` octet IPv4 header and `1924` octet payload

When those fragments pass through another router to a network with an MTU of `1400`, you would get:

1. `20` octet IPv4 header and `1376` octet payload
2. `20` octet IPv4 header and `1200` octet payload
3. `20` octet IPv4 header and `1376` octet payload
4. `20` octet IPv4 header and `548` octet payload

As I wrote before, you do not move anything between fragments, nor do you add any padding.

A fragment on a network with an MTU of `1400` cannot have a payload of `1380` octets because that is not divisible by eight. The largest fragment could be `1376` octets.

Original:

You seem to be very confused about fragmentation. Your packet will not end up with fragments the way you have depicted.

If, in your example, those are four separate packets, then they all meet the MTU of `1400`, and no fragmentation will occur.

Assuming all the data bytes you have for the four fragments were originally a packet with a `4451` octet payload, and the MTU is `1400`, it would be fragmented into four packets at a router where the MTU drops to `1400`:

1. `20` octet IPv4 header and `1376` octet payload
2. `20` octet IPv4 header and `1376` octet payload
3. `20` octet IPv4 header and `1376` octet payload
4. `20` octet IPv4 header and `323` octet payload

You do not move octets from one fragment to another, nor do you add any padding.

RFC 791, Internet Protocol has a complete description and example of fragmentation:

Fragmentation

Fragmentation of an internet datagram is necessary when it originates in a local net that allows a large packet size and must traverse a local net that limits packets to a smaller size to reach its destination.

An internet datagram can be marked "don't fragment." Any internet datagram so marked is not to be internet fragmented under any circumstances. If internet datagram marked don't fragment cannot be delivered to its destination without fragmenting it, it is to be discarded instead.

Fragmentation, transmission and reassembly across a local network which is invisible to the internet protocol module is called intranet fragmentation and may be used [6].

The internet fragmentation and reassembly procedure needs to be able to break a datagram into an almost arbitrary number of pieces that can be later reassembled. The receiver of the fragments uses the identification field to ensure that fragments of different datagrams are not mixed. 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 identification field is used to distinguish the fragments of one datagram from those of another. The originating protocol module of an internet datagram sets the identification field to a value that must be unique for that source-destination pair and protocol for the time the datagram will be active in the internet system. The originating protocol module of a complete datagram sets the more-fragments flag to zero and the fragment offset to zero.

To fragment a long internet datagram, an internet protocol module (for example, in a gateway), creates two new internet datagrams and copies the contents of the internet header fields from the long datagram into both new internet headers. The data of the long datagram is divided into two portions on a 8 octet (64 bit) boundary (the second portion might not be an integral multiple of 8 octets, but the first must be). Call the number of 8 octet blocks in the first portion NFB (for Number of Fragment Blocks). The first portion of the data is placed in the first new internet datagram, and the total length field is set to the length of the first datagram. The more-fragments flag is set to one. The second portion of the data is placed in the second new internet datagram, and the total length field is set to the length of the second datagram. The more-fragments flag carries the same value as the long datagram. The fragment offset field of the second new internet datagram is set to the value of that field in the long datagram plus NFB.

This procedure can be generalized for an n-way split, rather than the two-way split described.

To assemble the fragments of an internet datagram, an internet protocol module (for example at a destination host) combines internet datagrams that all have the same value for the four fields: identification, source, destination, and protocol. The combination is done by placing the data portion of each fragment in the relative position indicated by the fragment offset in that fragment's internet header. The first fragment will have the fragment offset zero, and the last fragment will have the more-fragments flag reset to zero.

The reason that the fragments must be divisible by eight is that the fragment offset field (`13` bits) is three bits smaller than the total length field (`16` bits). That means to have an offset large enough, you must account for those three bits (`2^3=8`). By requiring each fragment to be a multiple of eight, then the offset (multiplied by eight) can be as large as the total length.

• Yous fragments don't have payloads divisible by eight. `1380` is not divisible by eight. On a `1400` octet MTU, the largest payload can be `1376` for a fragment. Commented Oct 21, 2017 at 13:42
• The last fragment doesn't need to be evenly divisible by eight. I have no idea why you are concentrating on bits. The eight is octets (bytes or eight bits). You do not move or pad anything (bits or octets). Commented Oct 21, 2017 at 14:15
• I have no idea where you get that fragment. It is not a valid fragment, and it would never exist in your example. That is my point, what you have simply is wrong. Look at the edit to my answer, and it will explain how to fragment, and then fragment again. Commented Oct 21, 2017 at 14:41
• @Zephyr, your premise of "The 4 fragments at 2nd router will be <1380,20> <1196,20> <1380,20> <544,20>" is incorrect. It would never be that. Commented Oct 21, 2017 at 14:43
• The packet with a payload of `2576` octets will first be fragmented to a packet with a payload of `1376` octets (the largest you can have on an MTU of `1400`). That leaves a payload of `1200` octets (`2576-1376=1200`), which fits into a second fragment without further fragmentation, so the original packet with a `2576` octet payload would be fragmented into the two packets with payloads of `1376` and `1200`. The router treats (routes, fragments, etc.) packets individually, without regard to what came before, and it doesn't even expect anything to come after. Commented Oct 22, 2017 at 1:49

I don't disagree for a second with the description in previous answer, but as I assumed the 4500 packet was the whole length -- as that is what is compared to the MTU -- my arithmetic gives different answers for the final fragments B2 and C4 below.

Assuming 20-byte headers throughout, a 2600-byte MTU will make maximum packets of 2596-bytes and a 1400-byte MTU will make maximum packets of 1396.

``````    Packet A1: 4500 = (20 + 4480)
Fragmented through MTU = 2600 will give
Packet B1: 2596 = (20 + 2576)
Packet B2: 1924 = (20 + 1904)

B1 fragments through MTU 1400 into
Packet C1: 1396 = (20 + 1376)
Packet C2: 1220 = (20 + 1200)

B2 fragments through MTU 1400 into
Packet C3: 1396 = (20 + 1376)
Packet C4:  548 = (20 + 528)
``````

Kind regards,

Jonathan

• <1376,20>, <1192,20> , <1376,20>, <556,20> from <1380,20>, <1196,20>,<1380,20> and <544,20> . Why is above sequence of fragmentation incorrect. Just tell me that and everything will be clear. Why are you removing 4 from first fragment (1380-4) and adding it to second fragment and not last fragment(4th one). Commented Oct 21, 2017 at 16:38
• When second router receives packet B1 its length 2596 is greater than MTU 1400. So it fragments it. It doesn't buffer and wait for any possible successive fragments. That's the job of the recipient. You can't have fragments of payload length 1380 it's not a multiple of 8. The fragment is thus 20 + 1376 = 1396. Packet C2 gets the remainder because it fits. Packet B2 might not yet exist if router 1 is slow. Commented Oct 21, 2017 at 16:52
• ... and indeed, depending on router 1, packet B2 might have been routed a different way to a completely different router. Our router 2 with MTU 1400 might never see it. Hence it must deal with packet B2 on its own. Commented Oct 21, 2017 at 17:10
• I think where we differ is that you are assuming the entire original packet is `4500` octets, but the question actually says, "Suppose we have a data of 4500 bytes..." I believe that means the payload (data) of the packet is `4500` octets. Commented Oct 21, 2017 at 17:13
• @Zephyr there is nothing removed from the first fragment because it would never be fragmented as `1380`. It will be fragmented as `1376` to start with. You do not remove or add anything when fragmenting. A packet fragment is a packet itself, and packets are processed individually. When B1 (`2576`) is received, it is fragmented to the largest possible fragment (`1376`). What is left over simply fits into another packet without need for fragmentation. Nothing is added subtracted, shifted, or padded. Commented Oct 21, 2017 at 17:18