IP Fragmentation

Different MTU Values Along a Packet Path

An IP packet crosses links with different properties. Each link sets a maximum size for a unit it can carry without further division. A path from a computer in Texas to a web server in New York can include a local network, provider links, and tunnels, so the limit may differ between successive links. The source or an intermediate IPv4 router must account for the smallest applicable limit on the forwarding path, including tunnel overhead.

The limit for a particular link (such as Ethernet, Wi-Fi, or a long-distance fiber connection) is called the Maximum Transmission Unit (MTU). The MTU defines the largest packet, in bytes, that can cross that link. A common Ethernet value is 1500 bytes. The MTU includes the headers and data carried by the link unit, so an application cannot use all 1500 bytes for user data when IPv4 and transport headers are also present.

A problem arises when a packet prepared for a larger MTU must cross a link with a smaller MTU. If the sender or a router does not reduce the unit size, forwarding fails. One option is to split the datagram into smaller pieces that fit the limit. This process is known as IP Fragmentation. In IPv4, fragmentation can be performed by the source or by an intermediate router when DF is clear, while reassembly is performed at the destination.

IPv4 Fragmentation Fields in the Header

To split a datagram and reconstruct it at the destination, IPv4 uses specific header fields. These fields let the receiver identify fragments from one datagram and place their data at the correct positions.

As covered in the IPv4 Header topic, three fields work together during fragmentation. The IPv4 total-length field limits a datagram to 65,535 bytes, including its header.

• Identification (16 bits): To identify which original packet a fragment belongs to.
• Flags (3 bits): To control the fragmentation process and mark the last fragment.
• Fragment Offset (13 bits):To specify the exact position of the fragment's data within the original packet.

Meaning of the Fragmentation Control Fields

Each of these three fields has a distinct role in datagram fragmentation and reassembly.

Identification (ID) Field

The Identificationfield acts as a fragment-group number. A router copies the same value into every fragment of a datagram, allowing the destination to distinguish it from other datagrams in transit. An example value is "Shipment #12345."

In networking, when a router fragments an IP datagram, it copies the Identification value from the original datagram into the header of every single fragment. The destination host will then use this common ID to group together all the received fragments that belong to the same original packet before it can begin reassembly. This 16-bit field allows for $2^{16} = 65,536$ unique identifiers before the numbers need to be reused. Reassembly also considers the source address, destination address, and protocol field, so the ID is not the only grouping criterion.

Flags Field

This 3-bit field contains control signals for fragmentation and reassembly. Bit 0 is reserved and must remain zero; the DF and MF bits carry the operational flags.

• Bit 0: Reserved. This bit is always set to 0.
• Bit 1: Don't Fragment (DF) Flag. When this bit is set to 1, a router may not fragment the datagram. If the datagram exceeds the MTU of the next link, the router discards it and typically sends the source an ICMP "Fragmentation Needed and DF set" error. The DF flag forms the basis of Path MTU Discovery (PMTUD).
• Bit 2: More Fragments (MF) Flag. This flag tells the destination whether additional fragments follow the current one.
  • If the MF flag is set to 1, further fragments follow this one.
  • If the MF flag is set to 0, the datagram was unfragmented or this is its last fragment. The destination can then identify the end of the fragment range.

Fragment Offset Field

The field gives the position of a fragment's data within the datagram payload. An illustrative model may describe parts from 0cm to 100cm or from 100cm to 200cm; the header expresses the position in eight-byte units.

The Fragment Offset field tells the destination host exactly wherein the original datagram's data payload the data in this particular fragment belongs. This allows the host to reassemble the data in the correct order, even if the fragments arrive out of sequence.

Example: A 4000-Byte Datagram with a 1500-Byte MTU

Consider the complete process. A source host sends an IP datagram that a router must split on a link with an MTU of 1500 bytes.

• Original Datagram Size: 4000 bytes
• Header Size: 20 bytes
• Payload (Data) Size: $4000 - 20 = 3980$ bytes
• Network MTU: 1500 bytes

Step 1: Calculate Fragment Size

A router receives the 4000-byte packet. The next link has an MTU of 1500 bytes, so the total size of each fragment (header and data) cannot exceed that value.
Maximum data per fragment = MTU - Header Size = $1500 - 20 = 1480$ bytes.
Fragment data must also follow the 8-byte offset rule. The value 1480 is divisible by 8, as shown by $1480 / 8 = 185$. We can therefore use 1480 bytes of data for the first fragments.

Step 2: Create the First Fragment

The router creates the first fragment containing the beginning of the original data.

• Data: The first 1480 bytes of the original 3980-byte payload (Bytes 0-1479).
• Total Length: $1480 \text{ (data)} + 20 \text{ (header)} = 1500$ bytes.
• Identification: Copied from the original packet (let's say it's 1234).
• Flags: DF is 0. Since there is more data to come, MF is set to 1.
• Fragment Offset: This fragment starts at byte 0 of the original payload. The offset value is $0 / 8 = 0$.

Step 3: Create the Second Fragment

After the first fragment, $3980 - 1480 = 2500$ bytes of data remain. The router creates the second fragment.

• Data: The next 1480 bytes of the original payload (Bytes 1480-2959).
• Total Length: $1480 + 20 = 1500$ bytes.
• Identification: 1234 (must be the same).
• Flags: DF is 0. There is still more data to come, so MF is still 1.
• Fragment Offset: This fragment's data starts at byte 1480 of the original payload. The offset value is $1480 / 8 = 185$.

Step 4: Create the Final Fragment

After the second fragment, $2500 - 1480 = 1020$ bytes of data remain. The router creates the third and final fragment.

• Data: The last 1020 bytes of the original payload (Bytes 2960-3979).
• Total Length: $1020 + 20 = 1040$ bytes.
• Identification: 1234 (must be the same).
• Flags: DF is 0. This is the last piece of the original packet, so MF is set to 0. This signals the end to the receiver.
• Fragment Offset: This fragment's data starts at byte 2960 of the original payload. The offset value is $2960 / 8 = 370$.

The 4000-byte datagram is split into three fragments (1500, 1500, and 1040 bytes), each with its own header. The destination uses the identical ID, offsets 0, 185, and 370, and the final MF=0 flag to restore the data in its original order. Each fragment carries its own 20-byte header, so the split adds two extra headers to the total overhead and requires reassembly state at the destination.

IPv6 Fragmentation: Source-Host Responsibility

In IPv6, intermediate routers do not fragment packets. If a packet is too large for a link, the source chooses a suitable size using PMTUD or includes a Fragment header. In the IPv6 model:

• Routers do not fragment: Intermediate IPv6 routers discard an oversized packet and send a Packet Too Big message.
• Path MTU Discovery (PMTUD): The source host determines the smallest MTU along the path. It sends packets and responds to "Packet Too Big" errors from a router that cannot forward them. The host then adjusts packet size before the next transmission.
• Fragment Extension Header: If a source host must send a packet larger than the Path MTU, it can fragment the packet itself and include a Fragment header. The header contains a 32-bit identification value, a 13-bit offset in eight-byte units, and the M flag. It is processed by the destination host; intermediate routers do not modify it.

Costs and Problems of Fragmentation

IPv4 fragmentation can be needed when MTU values differ, but it adds processing cost and complicates traffic handling. Path MTU Discovery and suitable packet sizing often reduce its use. Technical guidance also describes problems involving partial loss, filtering, and differences in fragment handling between devices. Only the first IPv4 fragment carries the transport header, so middleboxes may need fragment state to apply port-based policies consistently.

• Performance Overhead: Fragmentation increases the workload for both the router that performs the fragmentation (it must create multiple new headers) and the destination host that must reassemble the pieces, consuming CPU and memory.
• Higher Risk of Incomplete Delivery: Losing one fragment prevents the destination from reassembling the datagram. After a reassembly timeout, the destination discards the fragments it has received. A higher-layer protocol such as TCP may request retransmission, so IP does not automatically resend the entire datagram. This can increase delay and consume additional bandwidth.
• Security Vulnerabilities: Packet fragmentation has been exploited in various network attacks. For example, firewalls and intrusion detection systems can have difficulty inspecting fragmented traffic, as the complete data context is spread across multiple packets.
• Complications with NAT/Firewalls: Many firewalls and NAT devices operate based on port numbers found in the transport layer (TCP/UDP) header. However, in a fragmented IPv4 packet, only the first fragment contains this header. Subsequent fragments do not. This makes it difficult or impossible for the device to correctly filter or translate these subsequent fragments, often causing it to block them.