Why does fragmentation occur?
  
  Fragmentation happens when a large IP datagram has to travel through a network with a maximum
  transmission unit (MTU) that is smaller than the size of the IP datagram. If an IP datagram that is bigger than
  1500 bytes (typical MTU size) is sent on an Ethernet network, the datagram needs to be fragmented prior to
  being placed on the network. The network packets are then assembled at the receiving host. Fragmentation
  can happen at either at the originating host or at an intermediate router.
  IP fragmentation can cause excessive retransmissions when fragments encounter packet loss and reliable
  protocols such as TCP must retransmit all of the fragments in order to recover from the loss of a single
  fragment.[4] Thus, senders typically use two approaches to decide the size of IP datagrams to send over the
  network. The first is for the sending host to send an IP datagram of size equal to the MTU of the first hop of
  the source destination pair. The second is to run the path MTU discovery algorithm,[5] described in RFC 1191,
  to determine the path MTU between two IP hosts, so that IP fragmentation can be avoided.
  
    Understanding IP Fragmentation
  
  How are the packets reassembled?
  Note that with IP fragmentation, packets are not reassembled until they reach the final destination. It is
  reassembled at the IP layer at the receiving end. This is make fragmentation and reassembly transparent to
  the protocol layer (TCP and UDP). If one of the packets is lost, the whole packets need to be transmitted
  again. Packets are reassembled at the receiving host by associating each fragment with an identical fragment
  identification number, or frag id for short. The frag ID is actually a copy of the ID field (IP identification number)
  in the IP header. Besides that, each fragment must carry its “position” or “offset” in the original unfragmented
  packet. Thus the first fragment will have an offset of 0, since its seat is at the front row and counting starts
  from 0. Each fragment must also tell the length of data that it carries. This is like the compartments in a train.
  And finally, each fragment must flag the MF (more fragments) bit if it is not the last fragment.
  
  Fragmenting a Packet
  
  Here is a hypothetical example. Suppose that we want to send a 110 bytes ICMP packet on a network with
  MTU of 40 (well that’s damn small, but this is for illustration purposes). This is a diagram of the original packet:
  IP ICMP Data
  Header Header
  20 8 82 (bytes)
  The packet will be fragmented as shown below.
  +----------------+----------+-----------+
  Packet 1 | IP header (20) | ICMP (8) | Data (12) | ID=88, Len=20, Off=0, MF=1
  +----------------+----------+-----------+
  Packet 2 | IP header (20) | Data (20) | ID=88, Len=20, Off=20, MF=1
  +---------------------------------------+
  Packet 3 | IP header (20) | Data (20) | ID=88, Len=20, Off=40, MF=1
  +---------------------------------------+
  Packet 4 | IP header (20) | Data (20) | ID=88, Len=20, Off=60, MF=1
  +----------------------------+----------+
  Packet 5 | IP header (20) | Data (10) | ID=88, Len=10, Off=80, MF=0
  +----------------------------+
  ID - IP identification number
  Len - Data Length (data length does not include IP header)
  Off - Offset
  MF - More Fragment
  Notice that the second packet and subsequent packets contains IP header that is copied from the original
  packet. There are no ICMP headers, except in the first packet. In a nutshell, the 110 ICMP packet is broke into
  5 packet, with total lengths of 40, 40, 40, 40 and 30 bytes each. The ICMP data is broken into lengths of 12,
  20, 20, 20, and 10 bytes each.