Packet Fragmentation

TCP/IP is designed for use with many different kinds of networks. Unfortunately, network designers do not agree about how big packets can be. The MTU or Maximum Transmission Unit size is the maximum size of the data field for the underlying physical network. Different network types have different MTU sizes:

Network Type MTU (bytes)
Ethernet 1500
IEEE 802.3 1492
Token Ring 4440 to 17940
PPP 1500, negotiable
ARPANET via DDN X.25 1007

At first, you might think that IP should simply settle on the smallest possible size. Unfortunately, this would cause serious performance problems. When transferring large files, big packets are far more efficient than small ones. So we want to be able to use the largest packet size possible. But we also want to be able to handle networks with small limits. There are two provisions for this:

  1. TCP has the ability to negotiate about datagram size. When a TCP connection first opens, both ends can send the maximum datagram size they can handle. The smaller of these numbers is used for the rest of the connection. This allows two implementations that can handle big datagrams to use them, but also lets them talk to implementations that can't handle them. However this doesn't completely solve the problem. The most serious problem is that the two ends don't necessarily know about all of the steps in between. For example, when sending data between two computers both connected to an ethernet LAN, it is likely that they will both be prepared to handle 1500-byte datagrams. However the connection will at some point end up going over the Arpanet. It can't handle packets of that size.
  2. For this reason, there are provisions to split datagrams up into pieces. This is referred to as fragmentation. The IP header contains fields indicating the a datagram has been split, and enough information to let the pieces be put back together. If a gateway connects an Ethernet to the Arpanet, it must be prepared to take 1500-byte Ethernet packets and split them into pieces that will fit on the Arpanet. Furthermore, every host implementation of TCP/IP must be prepared to accept pieces and put them back together. This is referred to as reassembly.

When an IP datagram is fragmented, each fragment becomes its own packet, with its own IP header, and is routed independently of any other packets. This makes it possible for the fragments of a datagram to arrive at the final destination out of order. There is enough information in the IP header to allow the receiver to reassemble the fragments correctly. Let's see what happens if we want to transmit 1473 bytes of data, using UDP:

Two packets travel across the network, the first containing the UDP-header + 1472 bytes of data. Together with the IP-header the packet is 1500 bytes long, the Ethernet MTU. The second packet contains an IP-header + 1 byte of data, 21 bytes in total.

Recalling the IP header, the following fields are used in fragmentation. The identification field contains a unique value for each IP datagram that the sender transmits. This number is copied into each fragment of a particular datagram. (We now see the use for this field.) The flags field uses one bit as the "more fragments" bit. This bit is turned on for each fragment comprising a datagram except the final fragment. The fragment offset field contains the offset of this fragment from the beginning of the original datagram. Also, when a datagram is fragmented the total length field of each fragment is changed to be the size of that fragment.

Finally, notice that the original UDP-header, containing the source and destination port numbers, occurs only in the first fragment. In fact, any transport layer header appears only in the first fragment. This can be quite cumbersome when dealing with firewall-strategies, often based on information about protocol application type or port numbers.