What should we do if the number of bytes to be transferred are not in multiples of eight in ipv4? [duplicate]

Question

(it is take from book called special edition tcp ip, pic taken for better formatting and ease to read)

Theory that I am trying to understand-:

So i found a question that is relevant to this-: ->a total of 1440 bytes that is routed through an interface with MTU of 576 bytes. Calculate flag, fragmented offset, total length and data transmitted in each packet after fragmentation. Assume IP header to be 20 bytes.

Solution-:

1440=20+1420

MTU is 576. Number of fragments=1420/576=3

So let’s call 3 packets P1,P2,P3.

P1=>20+556 P2=>20+556 P3=>20+308

So I am trying to understand what the above picture is trying to say.

There are 2 cases-:

-> Is it trying to say that total length of P1 should be divisible by 8?

-> Is it trying to say that “only data” part should be divisible by 8?

I have even further questions about it.

->Say, the total length of P1 should be divisible by 8. What will we do if it is not?

->(I believe) Say the “only data” part should be divisible by 8, then what should we do as neither 556 nor 308 is divided by 8.

So say I reiterate and do this arrangement(I believe this is correct way)-: P1->20+552 P2>20+552 P3->20+316

Still 316 isn’t divisible by 8, what should I do now?

i don't understand how that solution that was written in that book image i put above can be used in our case? please guide me step by step solution of how you would implement the solution written in that book.

IRRESPECTIVE OF WHATEVER I WROTE,if you want,YOU CAN EXPLAIN LIKE I AM BEGINNER TO ALL THESE

Answer 1

The number of octets in an IPv4 packet need not be a multiple of eight. You are confusing a couple of things. The data size can be anywhere from 0 to 65,535 - <packet header size>. IPv4 has the Total Packet Size field that is a 16-bit number (maximum 65,536) that include the IPv4 header (20 to 60 octets) and payload (data).

When an IPv4 packet must be fragmented, the data must be divided on a multiple of eight octets. That is because the Fragment Offset field is three bits smaller than the Total Packet Length field, and 2^3 = 8. The last fragment does not need to be a multiple of eight.

RFC 791, Internet Protocol explains 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.

---

For what it is worth, packet fragmentation is on the endangered species list. Many companies will drop incoming packet fragments to prevent fragmentation attacks. Also, IPv6 has eliminated the in-path packet fragmentation that IPv4 has. It is very resource intensive for a router to fragment packets, and for the destination to reassemble the fragment into a packet. We have PMTUD so that the minimum MTU in the path can be determined prior to sending packets so that the packets can be properly sized prior to sending.

Answer 2

I think you've got a slight misunderstanding how fragmentation works.

With an MTU of 576, the first fragment can carry 576 bytes of the original packet (that's a multiple of 8, all is well). Each additional fragment needs to add a new header, so the effective fragment size is reduced to at most 556 - which isn't divisible by 8, so intermediate fragments are reduced to 552 bytes.

Accordingly, your fragments of 1440 octets original packet size are in [original] bytes

1. [576]
2. [552] + 20 = 572
3. [312] + 20 = 332

Note that the last fragment doesn't need to be a multiple of 8 since there's no next fragment that requires such an offset.