3

Is it mentioned in any RFC's that when one is splitting a Datagram into fragments, the bytes in the first fragment should be "the closest multiple of 8" or is it just a standard implementation.
Like for Example: if there whose payload is 10,000 bytes and header is 20 bytes, and going into another link whose MTU is 4000 bytes, then why should the payload be split as 3976, 3976, 2048? Why can't someone split it as lets say 3880, 3880, 2240? (no of fragments is the same)

(Closest Multiple of 8 - If 3980 was supposed to be split then closest multiple of 8 would be 3976.... Similarly it for 4000 it would be 4000 itself)

2 Answers 2

6

The Fragment Offset field is three bits smaller than the Total Length field.

2^3 = 8

That means that you must use a multiple of eight. Typically you will use the largest multiple of eight that fits into the new MTU in order to minimize the number of packet fragments that are required to send the packet through the smaller MTU.

Fragmentation is resource intensive, and a router is not going to have an algorithm that looks to see if you can shrink the size of the fragments and still have the same number of packets. That would be even more resource intensive to no end. The purpose of a router is to route packets as fast as possible, not spend cycles trying to find a more even fragment size.

IPv6 has eliminated in-path packet fragmentation as a bad idea, instead requiring PMTUD (which can also be used with IPv4).

5
  • 1
    Expanding on this a bit, there’s near zero benefit to evening out the packet sizes. It might have an impact on latency of other flows while the fragments are being sent, but if it does the actual impact should be so small as to be barely measurable unless the MTU is very high relative to the effective layer 2 bandwidth. So outside of pathological situations that shouldn’t happen in real life, this would be extra resource usage for a purely aesthetic benefit. Commented May 7 at 19:12
  • @Ron Maupin so is the "using the largest of multiple of 8" a strict requirement? or is it left upto the implementation? Commented May 8 at 11:58
  • It is certainly up to the implementation, but there are no implementations that do something so foolish as to waste cycles and time to do that. Doing that detracts from the primary purpose of a router, which is to route packets between networks as fast as possible. Fragmentation is becoming rare as most companies now drop packet fragments in order to prevent fragmentation attacks. PMTUD is becoming more common on IPv4, and it is a requirement for IPv6.
    – Ron Maupin
    Commented May 8 at 12:12
  • What i thought was maybe the router could just generate a random number which is a multiple of 8 (which may or maynot be faster than finding the closest multiple of 8) Commented May 11 at 12:11
  • You can write your own routing code, but the vendors that make enterprise-grade routers (what is on-topic here) will use the largest multiple of eight that fits into the new MTU in order to minimize the number of packet fragments that are required to send the packet through the smaller MTU. Anything else is going to be in an off-topic device, such as custom router code running in a server, and it would be off-topic here.
    – Ron Maupin
    Commented May 11 at 13:57
2

For IPv4, see RFC 791:

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).

When more than two fragments are created, all but the very last one need to have an octet size divisible by eight.

Technically, there is no way to specify a more granular fragment offset, as detailed in Ron's answer.

Is it mentioned in any RFCs that when one is splitting a Datagram into fragments, the bytes in the first fragment should be "the closest multiple of 8" or is it just a standard implementation.

No. "The closest multiple of 8" is an incorrect interpretation by a third party. As Ron has indicated, the largest multiple of 8 that fits the MTU is the most reasonable choice. The "closest" multiple may be larger than the MTU which isn't possible.

For completeness, for IPv6 the (end-to-end) fragmentation header isn't standard but an option. RFC 2460 defines for the field

Fragment Offset

13-bit unsigned integer. The offset, in 8-octet units, of the data following this header, relative to the start of the Fragmentable Part of the original packet.

So it's the exact same situation.

7
  • The point of the question is whether closest is required, not whether it needs to be a multiple of 8.
    – Barmar
    Commented May 8 at 15:22
  • I have quoted the relevant RFC for you above and it doesn't say "the closest multiple of 8" anywhere.
    – Zac67
    Commented May 8 at 17:06
  • Right. That's the OP's question: is there any such requirement. Requirements can be spread out among many different RFCs. E.g. many clarifications were added in RFC 1122.
    – Barmar
    Commented May 8 at 17:39
  • Of course, the only way to prove this has never been specified would be to check all RFCs.
    – Barmar
    Commented May 8 at 17:40
  • Fortunately, the IETF does that job for us. RFC 791 says it's been updated by RFCs 1349, 2474, 6864, and none of them define anything else regarding fragment size.
    – Zac67
    Commented May 8 at 20:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.