Understanding IP Fragmentation
Fragmentation occurs when an IP datagram traverses a network which has a maximum transmission unit (MTU) that is smaller than the size of the datagram. Take for example a standard Ethernet datagram of 1500 bytes. If a larger size datagram was to traverse an Ethernet network, it would require fragmentation to prevent it being discarded somewhere along the path. Fragments continue to their destination where the receiving host re-assembles them into the original datagram.
So what kind of information does the destination host require in order to re-assemble these fragments?
1. Fragment ID — An identifier from the IP header which associates all fragments to the same datagram.
2. Place & Offset — To identify the fragments position within the original datagram.
3. Length — Each fragment must tell the length of data carried.
4. MF flag — Used to determine if more fragments are to follow.
Let’s take a look at an ICMP datagram which is 4000 bytes in size comprising of 20 bytes IP header, 8 bytes protocol header and 3972 bytes of data.
Now let’s take a look at how this datagram would be fragmented in order to traverse a standard Ethernet network. Fragment number 1 is 1500 bytes in size comprising 20 byte IP header, 8 byte protocol header and 1472 bytes of data. Fragment number 2 is 1500 bytes in size comprising 20 byte IP header and 1480 bytes of data. The final fragment number 3 is 1040 bytes in size comprising 20 bytes IP header and 1020 bytes of data. Notice that only the initial fragment contains the protocol header but all fragments contain a copy of the IP header.
Truncated TCPdump output:
client.com > server.com: icmp: echo request (frag 21233 : 1472@0+)
client.com > server.com: icmp: echo request (frag 21233 : 1480@1472+)
client.com > server.com: icmp: echo request (frag 21233 : 1020@2952)
As you can see from the above TCPdump output, the critical information we referred to earlier has been provided so the receiving host can successfully reassemble into the original datagram:
1. Fragment ID — indicates that the fragment ID is 21233 (frag 21233 : 1472@0+).
2. Place & Offset — indicates 1480 bytes of data should be placed after 1472 bytes(frag 21233 : 1480@1472+).
3. Length — indicates data length of 1020 bytes (frag 21233 : 1020@2952).
4. MF Flag — The + value is used to show additional fragments are required, the final fragment will not have this flag set (frag 21233 : 1480@1472+).
Dynamically Avoiding Fragmentation
Path MTU discovery is a technique used to identify the end-end MTU to prevent the need for fragmentation. This works by sending an ICMP packet to the required destination with the don’t fragment bit (DF) set. When this flag is set and the packet traverses a network where fragmentation is required, a layer 3 device will discard the packet and send an ICMP message back to the originating host. This message contains the smaller MTU value which is then dynamically used by the originating host to prevent fragmentation. Firewalls and packet filtering devices can stop Path MTU discovery from working if ICMP is blocked.
Another way to dynamically avoid fragmentation for TCP traffic is to set the MSS (maximum segment size). With this TCP option enabled, devices inspect inbound TCP SYN packets and set the MTU value accordingly so fragmentation is not required end-end.
Although IP fragmentation is a normal event, it can cause performance related issues as dropped fragments will cause the entire datagram to be resent. Fragmented traffic can also be crafted to evade security devices such as IDS/IPS and leveraged for malicious use.
