Calculating Fragmentation offset doubt

Question

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?

Answer 1

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.

Answer 2

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