IP Datagram Fragmentation with Example
Not all link-layer protocols can carry network-layer packets of the same size. Some protocols can carry big datagrams, whereas other protocols can carry only little packets.
For example, Ethernet frames can carry upto 1,500 bytes of data, whereas frames for some wide-area links can carry no more than 576 bytes.
The maximum amount of data that a link-layer frame can carry is called the maximum transmission unit (MTU). Because each IP datagram is encapsulated within the link-layer frame for transport from one router to the next router, the MTU of the link-layer protocol places a hard limit on the length of an IP datagram.
Having a hard limit on the size of an IP datagram is not much of a problem. What is a problem is that each of the links along the router between sender and destination can use different link-layer protocols, and each of these protocols can have different MTUs.
IP Datagram Fragmentation
To understand the forwarding issue better, imagine that you are a router that interconnects several links, each running different link-layer protocols with different MTUs. Suppose you receive an IP datagram from one link. You check your forwarding table to determine the outgoing link, and this outgoing link has an MTU that is smaller than the length of the IP datagram. Time to panic – how are you going to squeeze this oversized IP datagram into the payload field of the link-layer frame?
The solution is to fragment the data in the IP datagram into two or more smaller IP datagrams, encapsulate each of these smaller IP datagram in a separate link-layer frame; and send these frames over the outgoing link. Each of these smaller datagrams is referred to as a fragment .
Fragments need to be reassembled before they reach the transport layer at the destination. Indeed, both TCP and UDP are expecting to receive complete, unfragmented segments from the network layer. The designers of IPv4 felt that reassembling datagram in the routers would introduce significant complication into the protocol and put a damper on router performance. (if you were a router, would you want to be reassembling fragments on top of everything else you had to do?). Sticking to the principle of keeping the network core simple, the designers of IPv4 decided to put the job of datagram reassembly in the end system rather than in network routers.
When a destination host receives a series of datagrams from the same source, it needs to determine whether any of these datagrams are fragments of some original larger datagram.
If some datagrams are fragments, it must further determine when it has received the last fragment and how the fragments it has received should he pieced back together to form the original datagram.
To allow the destination host to perform these reassembly tasks, the designers of IP (version 4) put identification flag, and fragmentation offset fields in the IP datagram header.
When a datagram is created, the sending host stamps the datagram with an identification number as well as source and destination address. Typically, the sending host increments the identification number for each datagram it sends. When a router needs to fragment a datagram, each resulting datagram (that is, fragment) is stamped with the source address, destination address, and identification number of the original datagram.
When the destination receives a series of datagrams from the same sending host, it can examine the identification numbers of the datagrams to determine which of the datagrams are actually fragments of the same larger datagram.
Because IP is an unreliable service, one or more of the fragments may never arrive at the destination. For this reason, in order for the destination host to be absolutely sure it has received the last fragment of the original datagram , the last fragment has a flag bit set to 0, whereas all the other fragments have flag bit set to 1. Also, in order for the destination host to determine whether a fragment is missing ( and also to be able to reassemble the fragments in their proper order), the offset field is used to specify where the fragment fits within the original IP datagram.
IP Datagram Fragmentation Example
The figure below shows an IP datagram fragmentation example .
A datagram of 4,000 bytes (20 bytes of IP header plus 3,980 bytes of IP payload) arrives at a router and must be forwarded to a link with an MTU of 1,500 bytes.
This implies that the 3,980 data bytes in the original datagram must be allocated to three separate fragments (each of which is also an IP datagram).
Suppose that the original datagram is stamped with an identification number of 777.The characteristics of three fragments are shown in the table below.
The values in the above table reflect the requirement that the amount of original payload data in all but the last fragment be a multiple of 8 bytes, and that the offset value be specified in units of 8-byte chunks.
At the destination, the payload of the datagram is passed to the transport layer only after the IP layer has fully reconstructed the IP datagram. If one or more of the fragments does not arrive at the destination, the incomplete datagram is discarded and not passed to the transport layer.
But, we know that if TCP is being used at the transport layer, then TCP will recover from this loss by having the source retransmit the data in the original datagram.
We have just learned that IP fragmentation plays an important role in gluing together the many disparate link-layer technologies. But fragmentation also has its costs:
- First it complicates routers and end systems, which need to be designed to accommodate datagram fragmentation and reassembly.
- Secondly, fragmentation can be used to create lethal DoS attacks, whereby the attacker sends a series of bizarre and unexpected fragments. A classic example is the Jolt2 attack, where the attacker sends a stream of small fragments to the target host, none of which has an offset of zero. The target can collapse as it attempts to rebuild datagrams out of the degenerate packets. Another class of exploits sends overlapping IP fragments, that is, fragments whose offset values are set so that the fragments do not align properly. Vulnerable operating systems, not knowing what to do with overlapping fragments can crash.
Hence, a new version of Internet Protocol, IPv6, does away with fragmentation altogether, thereby streamlining IP packet processing and making IP less vulnerable to attack.