Why the ip fragments must be in multiples of 8 bytes
Every fragment except the last must contain a multiple of 8 bytes of data.
Fragment Offset can hold 8192 (2^13) units but the datagram can't have 8192 * 8 = 65536 bytes of data because "Total Length" field of IP header records the total size including the header and data.
An IP header is at least 20 bytes long, so the maximum value for "Fragment Offset" is restricted to 8189, which leaves room for 3 bytes in the last fragment.
Hope this helps.
Note that Fragment Offset field is expressed in 8-byte units, not in bytes. This is the reason why the payload size inside each of the fragment, except the last fragment, must be multiple of 8 bytes.
As the Fragment Offset is coded on 13bits, it results that its range is between 0 and 8191 units of 8 bytes. However, because the Total Length takes into account also the IP Header, the Fragment Offset maximum limit is in fact 8189 units, not 8191 units, see below:
Total Length being coded on 16 bits it means it is limited to 65535 bytes. Then, as the IP header is at least 20 bytes it results that the Payload is limited to maximum 65535 bytes - 20 bytes = 65515 bytes. Dividing these 65515 bytes in 8-byte units it results that there could be maximum 8189 units, hence Fragmentation Offset is limited to maximum 8189 units.
An IP fragment having the Fragment Offset value set to this maximum value of 8189, could have a payload of maximum 3 bytes:
Maximum 65535 bytes - minimum 20 bytes - (8189 units * 8 bytes per unit) = maximum 3 bytes
Rurre
I did not gain much of a benefit from other answers here. They seem to brush on the real issue only in passing, while trying to explain another issue they see, so here is the real answer:
The number of bits in the message length field is different from the number of bits in the fragment field.
[ Length ] <-- 16 bits
[ Flag ][ Fragment ] <-- 3 bits + 13 bits
Message Length field measures the whole message, across all fragments of that message
When sending a large packet, it gets broken into multiple fragments, so you need to label the fragment and keep track of the portion of the message in that fragment, and put it back into order when all the fragments arrive. You get 13 bits to describe the sequence of fragments. Length is a 16-bit integer, so its capacity (16 bits) is 2^16 - 1 = 65536-1 = 65535. That gives you 65535 different bytes, so an IP message can be at most 65535 bytes long.
Fragment offset is a measure of bytes, but can't fit the # of bytes in the message
Ideally we'd like to measure fragments in the same unit as Length, which is bytes.
But we only have 13 bits for Fragment!
They wanted to keep the measure of Fragment offset in bytes, so they had to think of a way to fit 16 bits into 13 bits. They invented a weird bit mapping to do this for them:
Weird bit mapping
They realized that for every 1 less bit a number has for representing its maximum number (for example, going from 16 bits down to 15 bits by taking away one bit, for example), the number of unique indices you can have is divided by 2. 15 bits can only represent 2^15 - 1 = 32768-1 = 32767 unique locations. 14 bits --> divide by 2 again; 13 bits --> divide by 2 again. In order to be able to keep track of the same total number of bytes, it has to skip some bytes and index only every 2^n bytes, where n is the number of bits taken away from the Fragment offset value. Since Fragment offset is required to use 13, it takes away 3 bits, so it can only index every 8th (2^3) byte, so the indices were for 8-byte chunks. THUS the 8 * Fragment Offset to calculate the actual byte-offset of each fragment.
Considerations
The Fragment value is an offset from the first fragment's first byte. For some odd reason, they decided to measure the offset in bytes, instead of number of fragments--even though bytes requires more data than an index. It might be more intelligent to simply make the Fragment offset an index value (fragment number)--but they did not do it this way!