Internet Protocol (IP) version 4.0 Fragmentation and Reassembly

The following is an explanation of the IP Fragmentation and Reassembly process used by IP version 4.0. It will examine the purpose of IP Fragmentation, the relevant fields contained within the IP Header and the role of Maximum Transmission Unit (MTU) in determining when IP Fragmentation will be used.

As specified in RFC 791 (Internet Protocol - DARPA Internet Program Protocol Specification, Sept. 1981), the IP Fragmentation and Reassembly process occurs at the IP layer and is transparent to the Upper Layer Protocols (ULP). As a block of data is prepared for transmission, the sending or forwarding device examines the MTU for the network the data is to be sent or forwarded across. If the size of the block of data is less then the MTU for that Network, the data is transmitted in accordance with the rules for that particular network. But what happens when the amount of data is greater than the MTU for the network? It is at this point that one of the functions of the IP Layer, commonly referred to as Fragmentation and Reassembly, will come into play.

Maximum Transmission Unit (MTU)

There are a number of deferring network transmission architectures, with each having a physical limit of the number of data bytes that may be contained within a given frame. This physical limit is described in numerous specifications and is referred to as the Maximum Transmission Unit or MTU of the network. An example of such an MTU would be IEEE 802.3 Ethernet; according to the specifications, the maximum number of data bytes that can be contained within a frame is 1500. The following table lists the MTU of several common network types (from RFC 1191 - MTU Path Discovery, Nov 1990):

Network Architecture	MTU in Bytes
802.3 Ethernet	1500 B
4 Mb Token Ring	4464 B
16 Mb Token Ring	17914 B
FDDI	4352 B
X.25	576 B

There are two principle situations in which MTU becomes important:

1. The first is when the size of the block of data being transmitted is greater than the MTU. An example of this would be when data is being read using Sun's Network File System (NFS) which reads data in 8-kilobyte blocks.
2. The second situation would arise when data must traverse across multiple network architectures, each with a different MTU. Just such an example would be if the data originated on a 16Mb Token Ring network (MTU = 17914 B) that was connected to another 16Mb Token Ring network (MTU = 17914 B) via an Ethernet network (MTU = 1500B).

Regardless of which situation occurs, the rules that IP Fragmentation follows remain the same and will be discussed later. (See "An example of IP Fragmentation" below)

IP version 4 Fragmentation Fields

Contained within the IP Header, there are three fields that are of concern when discussing IP Fragmentation. (See the sample IP Header diagram below):

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Sample Internet Protocol Header (RFC 791)

*Note - each tick mark represents one bit position.

The three fields concerned with IP Fragmentation are:

RFC 791 Field Name	Offset Location	Size	Other Reference Names
Identification	18-19	16b	Identification Field
Flags	20	3b	Fragmentation Flags
Fragmentation Offset	20-21	13b	Fragment Offset

(1) Identification - This 16-bit field contains a unique number used to identify the frame and any associated fragments for reassembly.

Given the increasing complexity of networks, it is theoretically possible that fragments from multiple blocks of data might travel along different paths to the destination, possibly arriving out of sequence in relation to one another. That is, it is possible a fragment form block number one might arrive intermixed with the data stream for block number 2 or vice versa. While the function of the Fragment Offset Field is to identify the relative position of each fragment, it is the Identification Field that serves to allow the receiving device to sort out which fragments comprise what block of data. Each fragment from a particular data stream will have the same Identification Field, thus uniquely identifying which block it belongs to. If one or more fragments are lost, the buffer of the device performing the reassembly process will time out and discard all of the fragments. In the event of such a time out, the data will then have to be retransmitted by the sending device.

(2) Flags - This 3-bit field contains the flags that specify the function of the frame in terms of whether fragmentation has been employed, additional fragments are coming, or this is the final fragment.

Bit Indicator	RFC 791 Definition
0xx	Reserved
x0x	May Fragment
x1x	Do Not Fragment
xx0	Last Fragment
xx1	More Fragmenets

When a receiving station processes each frame, one of the operations it performs is to review the Flags field. Depending on the value indicated by this field, several possible actions are then initiated, including:

(xx1) More Fragments - Indicates that there are additional IP Fragments that comprise the data associated with that specific Identification Field. The receiving device will allocate buffer resources for reassembly and pass all frames containing that unique Identification Field to the buffer.

(xx0) Last Fragment - Indicates that this fragment is the final frame for the data block identified by the Identification Field. The receiving device will now attempt to reassemble the fragments in the order specified by the Fragment Offset field.

(3) Fragment Offset - This 13-bit field indicates the position of a particular fragment's data in relation to the first byte of data (offset 0).

Because it is entirely possible that the fragments that comprise a block of data might travel along different paths to the destination, it is possible they might arrive out of sequence. While the Identification Field serve to mark which IP fragments belong to which block of data, it is the Fragment Offset Field, sometimes referred to as the Fragmentation Offset Field, that tells the receiving device which order to reassemble them in.

During the IP Fragmentation Reassembly process, if a particular fragment is found to be missing, as indicated by the Fragmentation Offset count, the buffer will enter a wait state until either the missing piece(s) are received or a time out occurs. In the event of such a time out, the buffer simply discards the fragments.

IP Fragmentation and Reassembly by Forwarding Devices

So far, the procedure for IP Fragmentation and Reassembly within a specific network has been discussed. However, there is another situation in which these processes may be utilized to pass frames between dissimilar network physical architectures. Return to the previously mentioned example of a block of data originating on a 16Mb Token Ring network (MTU = 17914B) that is connected to another 16Mb Token Ring network (MTU = 17914B) via an Ethernet network (MTU = 1500B).

Token Ring		Ethernet		Token Ring
	Router 1		Router 2

At the time of transmission, the data block met the MTU restriction for a 16Mb Token Ring Network, however the Router connecting the Token Ring to the Ethernet Network is faced with having to forward this large block onto a network with a smaller MTU. So how does Router #1 handle this situation of Path MTU? The answer is both simple and elegant in that it will simply follow the rules for IP Fragmentation as if was transmitting the frame itself. The only deviation form the process previously discussed is that the Identification Field will be that of the original frame.

Once the data reaches Router #2, it will then perform reassembly of the fragments exactly as previously described and pass the reassembled block of data onto the network with the new MTU.

Sequence examples of IP Fragmentation and IP Fragmentation Reassembly

IP Fragmentation

Regardless of what situation occurs that requires IP Fragmentation, the procedure followed by the device performing the fragmentation must be as follows:

1. The device attempting to transmit the block of data will first examine the Flag field to see if the field is set to the value of (x0x or x1x). If the value is equal to (x1x) this indicates that the data may not be fragmented, forcing the transmitting device to discard that data. Depending on the specific configuration of the device, an Internet Control Message Protocol (ICMP) Destination Unreachable -> Fragmentation required and Do Not Fragment Bit Set message may be generated.
2. Assuming the flag field is set to (x0x), the device computes the number of fragments required to transmit the amount of data in by dividing the amount of data by the MTU. This will result in "X" number of frames with all but the final frame being equal to the MTU for that network.
3. It will then create the required number of IP packets and copies the IP header into each of these packets so that each packet will have the same identifying information, including the Identification Field.
4. The Flag field in the first packet, and all subsequent packets except the final packet, will be set to "More Fragments." The final packets Flag Field will instead be set to "Last Fragment."
5. The Fragment Offset will be set for each packet to record the relative position of the data contained within that packet.
6. The packets will then be transmitted according to the rules for that network architecture.

IP Fragment Reassembly

If a receiving device detects that IP Fragmentation has been employed, the procedure followed by the device performing the Reassembly must be as follows:

1. The device receiving the data detects the Flag Field set to "More Fragments."
2. It will then examine all incoming packets for the same Identification number contained in the packet.
3. It will store all of these identified fragments in a buffer in the sequence specified by the Fragment Offset Field.
4. Once the final fragment, as indicated by the Flag Field, is set to "Last Fragment," the device will attempt to reassemble that data in offset order.
5. If reassembly is successful, the packet is then sent to the ULP in accordance with the rules for that device.
6. If reassembly is unsuccessful, perhaps due to one or more lost fragments, the device will eventually time out and all of the fragments will be discarded.
7. The transmitting device will than have to attempt to retransmit the data in accordance with its own procedures.

Security and IP Fragments

The IP version 4 Fragmentation and Reassembly process suffers from a particular weakness that can be utilized to trigger a Denial of Service Attack (DOS). The receiving device will attempt reassembly following receipt of a frame containing a Flag field set to (xx1), indicating more fragments to follow. Recall that receipt of such a frame causes the receiving device to allocate buffer resources for reassembly.

So what happens if a device is flooded with separate frames, each with the Flag field set to (xx1), but each has the Identification Field set to a different value? According to the rules for IP version 4 Fragmentation and Reassembly, the device would attempt to allocate resources to each separate fragment in preparation for reassembly. However, given a flood of such fragments, the receiving device would quickly exhaust its available resources while waiting for buffer time-outs to occur. The result, of course, would be that possible valid fragments would be lost or encounter insufficient resources to support reassembly. The common term for this type of artificially induced shortage of resources is "Denial of Service Attack".

To defend against just such DOS attempts, many network security features now include specific rules implemented at the Firewall that change the time-out value for how long they will hold incoming fragments before discarding them.