Editing IPv4 (section)

===Fragmentation===
When a router receives a packet, it examines the destination address and determines the outgoing interface to use and that interface's MTU. If the packet size is bigger than the MTU, and the Do not Fragment (DF) bit in the packet's header is set to 0, then the router may fragment the packet.

The router divides the packet into fragments. The maximum size of each fragment is the outgoing MTU minus the IP header size (20 bytes minimum; 60 bytes maximum). The router puts each fragment into its own packet, each fragment packet having the following changes:
*The ''total length'' field is the fragment size.
*The ''more fragments'' (MF) flag is set for all fragments except the last one, which is set to 0.
*The ''fragment offset'' field is set, based on the offset of the fragment in the original data payload. This is measured in units of 8-byte blocks.
*The ''header checksum'' field is recomputed.

For example, for an MTU of 1,500 bytes and a header size of 20 bytes, the fragment offsets would be multiples of <math>\frac{1{,}500-20}{8}=185</math> (0, 185, 370, 555, 740, etc.).

It is possible that a packet is fragmented at one router, and that the fragments are further fragmented at another router. For example, a packet of 4,520 bytes, including a 20 bytes IP header is fragmented to two packets on a link with an MTU of 2,500 bytes:

{|class=wikitable style=text-align:center
|-
!Fragment
!Size<br><small>(bytes)</small>
!Header size<br><small>(bytes)</small>
!Data size<br><small>(bytes)</small>
!Flag<br>''More fragments''
!Fragment offset<br><small>(8-byte blocks)</small>
|-
|1
|2,500
|20
|2,480
|1
|0
|-
|2
|2,040
|20
|2,020
|0
|310
|}

The total data size is preserved: 2,480 bytes + 2,020 bytes = 4,500 bytes. The offsets are <math>0</math> and <math>\frac{0+2{,}480}{8}=310</math>.

When forwarded to a link with an MTU of 1,500 bytes, each fragment is fragmented into two fragments:

{|class=wikitable style=text-align:center
|-
!Fragment
!Size<br><small>(bytes)</small>
!Header size<br><small>(bytes)</small>
!Data size<br><small>(bytes)</small>
!Flag<br>''More fragments''
!Fragment offset<br><small>(8-byte blocks)</small>
|-
|1
|1,500
|20
|1,480
|1
|0
|-
|2
|1,020
|20
|1,000
|1
|185
|-
|3
|1,500
|20
|1,480
|1
|310
|-
|4
|560
|20
|540
|0
|495
|}

Again, the data size is preserved: 1,480 + 1,000 = 2,480, and 1,480 + 540 = 2,020.

Also in this case, the ''More Fragments'' bit remains 1 for all the fragments that came with 1 in them and for the last fragment that arrives, it works as usual, that is the MF bit is set to 0 only in the last one. And of course, the Identification field continues to have the same value in all re-fragmented fragments. This way, even if fragments are re-fragmented, the receiver knows they have initially all started from the same packet.

The last offset and last data size are used to calculate the total data size: <math>495 \times 8+540=3{,}960+540=4{,}500</math>.