Editing IPv4 (section)

==Fragmentation and reassembly==
{{Main|IP fragmentation}}
The Internet Protocol enables traffic between networks. The design accommodates networks of diverse physical nature; it is independent of the underlying transmission technology used in the link layer. Networks with different hardware usually vary not only in transmission speed, but also in the [[maximum transmission unit]] (MTU). When one network wants to transmit datagrams to a network with a smaller MTU, it may [[IP fragmentation|fragment]] its datagrams. In IPv4, this function was placed at the [[Internet Layer]] and is performed in IPv4 routers limiting exposure to these issues by hosts.

In contrast, [[IPv6]], the next generation of the Internet Protocol, does not allow routers to perform fragmentation; hosts must perform [[Path MTU Discovery]] before sending datagrams.

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

===Reassembly===
A receiver knows that a packet is a fragment, if at least one of the following conditions is true:
*The flag ''more fragments'' is set, which is true for all fragments except the last.
*The field ''fragment offset'' is nonzero, which is true for all fragments except the first.

The receiver identifies matching fragments using the source and destination addresses, the protocol ID, and the identification field. The receiver reassembles the data from fragments with the same ID using both the fragment offset and the more fragments flag. When the receiver receives the last fragment, which has the ''more fragments'' flag set to 0, it can calculate the size of the original data payload, by multiplying the last fragment's offset by eight and adding the last fragment's data size. In the given example, this calculation was <math>495 \times 8+540=4{,}500</math> bytes. When the receiver has all fragments, they can be reassembled in the correct sequence according to the offsets to form the original datagram.