CW568-4 Computer Networks for Aircraft March 2020

Internet Protocol (IP) version 4.0 Fragmentation and Reassembly

http://www.wildpackets.com/resources/compendium/tcp_ip/ip_fragmentation

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 than 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 different 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
4 Mb Token Ring 4464
16 Mb Token Ring 17914
FDDI 4352
X.25 576

There are two principle situations in which MTU becomes important:

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.
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 Bytes) that was connected to
another 16Mb Token Ring network (MTU = 17914 Bytes) via an Ethernet network (MTU =
1500 Bytes).
Regardless of which situation occurs, the rules that IP Fragmentation follows remain the
same and will be discussed later.

Keith Smyth Page 1 of 6

CW568-4 Computer Networks for Aircraft March 2020

IP version 4 Fragmentation Fields

Type of
Versio Header
Service or Total Length
n Length
Diffserv
Identifier X D M Fragment Offset

Time to Live Protocol Header Checksum

Source Address

Destination Address

Options Padding

IPv4 Header

The three fields concerned with IP Fragmentation are:

RFC 791 Field Name Size Other Reference Names
Identification 16 bit Identification Field
Flags 3 bit Fragmentation Flags
Fragmentation Offset 13 bit Fragment Offset

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 from 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.

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 Fragments

Keith Smyth Page 2 of 6

CW568-4 Computer Networks for Aircraft March 2020

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.

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 IP Fragmentation Reassembly Procedure

IP Fragmentation
Regardless of what situation occurs that requires IP Fragmentation, the procedure followed
by the device performing the fragmentation must be as follows:
 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.
 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.
 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.
 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."
 The Fragment Offset will be set for each packet to record the relative position of the
data contained within that packet.
 The packets will then be transmitted according to the rules for that network
architecture.

Keith Smyth Page 3 of 6

CW568-4 Computer Networks for Aircraft March 2020

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:
 The device receiving the data detects the Flag Field set to "More Fragments."
 It will then examine all incoming packets for the same Identification number
contained in the packet.
 It will store all of these identified fragments in a buffer in the sequence specified by
the Fragment Offset Field.
 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.
 If reassembly is successful, the packet is then sent to the ULP in accordance with the
rules for that device.
 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.
 The transmitting device will then 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.

Keith Smyth Page 4 of 6

CW568-4 Computer Networks for Aircraft March 2020

Example 1.

In the diagram below a PC is uploading a file to a server over a WAN connection. Assume
that the PC has a 1400 byte segment to send to the server.
The table attached shows the packet before and after fragmentation. Complete the highlighted
fields in the packets after fragmentation.

Keith Smyth Page 5 of 6

CW568-4 Computer Networks for Aircraft March 2020

Before fragmentation
Start of Header
Identifier = Z x 0 0 Offset = 0
Rest of Header
1400 bytes

After fragmentation
Packet 1
Start of Header
Identifier = x     Offset =
Rest of Header
_____ bytes

Packet 2
Start of Header
Identifier = x     Offset =
Rest of Header
_____ bytes

Packet 3
Start of Header
Identifier = x     Offset =
Rest of Header
______ bytes

Packet 4
Start of Header
Identifier = x     Offset =
Rest of Header
______ bytes

Keith Smyth Page 6 of 6