User Tools

Site Tools


dardan:f5:101_exam:ip_fragmentation
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.
dardan/f5/101_exam/ip_fragmentation.txt · Last modified: 2019/03/01 14:02 by dardan

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki