Table of Contents
Understanding MTU
The Maximum Transmission Unit, or MTU, is the largest amount of payload data that a particular network link is willing to carry in a single layer 3 packet. In IPv4 networks this usually means the largest IP packet size, including the IP header and transport header, that can be sent without needing to break it into smaller pieces.
Every link type has its own typical MTU value. For example, standard Ethernet often uses an MTU of 1500 bytes for IP traffic. Some technologies allow smaller or larger MTUs. MTU is always a property of a link, not of the entire path, so each hop along the way can impose its own maximum.
It is important to distinguish between frame size at layer 2 and MTU at layer 3. The frame can be a bit larger because it also carries layer 2 headers and trailers in addition to the IP packet. When we talk about MTU in the context of IP and fragmentation, we care about the maximum IP packet size that fits inside that frame.
Key statement:
MTU is the maximum IP packet size that can be transmitted over a link without fragmentation.
Path MTU
While MTU belongs to a single link, an end to end connection usually crosses many links with different MTUs. The effective maximum that can be used between two endpoints is called the path MTU. It is the smallest MTU among all links along the route from source to destination.
If a source device sends packets that are larger than the path MTU, some router along the way will face a packet that does not fit on its outgoing link. At that point either the router fragments the packet, or if fragmentation is not allowed, the router must drop the packet and report the problem using ICMP. How this decision happens depends on IPv4 flags that control fragmentation and on the operating system behavior.
In more advanced setups, devices can try to discover the path MTU dynamically. That is handled through a specific mechanism that uses ICMP messages, and belongs to a more detailed treatment of ICMP, not to this chapter.
IPv4 Fragmentation Basics
IPv4 supports fragmentation on routers. When a router receives a packet that is larger than the MTU of the next hop interface, and if the packet is allowed to be fragmented, the router splits it into multiple smaller packets called fragments. Each fragment is then forwarded separately. The destination host later reassembles all fragments back into the original packet.
Each fragment is itself a valid IPv4 packet. All fragments share the same Identification field so that the receiving host knows which fragments belong together. Some bits in the IPv4 header mark which fragment is the last and what the offset of each fragment is within the original packet.
Important rule:
A router may fragment an IPv4 packet if it is too large for the outgoing interface MTU and fragmentation is permitted. All reassembly of fragments happens only at the final destination in IPv4.
Routers do not reassemble fragments in normal forwarding. They only break packets apart. The end host at the destination collects all fragments that share the same Identification value, source IP, destination IP, and protocol, and when it has all of them, it rebuilds the original payload for delivery to the upper layer.
If any fragment is lost, the full original packet cannot be reconstructed, and the destination discards all remaining fragments for that packet. Recovery, if any, is handled by the transport protocol, for example TCP will retransmit.
IPv4 Fragmentation Fields
IPv4 is covered in detail elsewhere, but here we focus on the header fields that are specific to fragmentation. The important ones are:
| Field | Role in fragmentation |
|---|---|
| Identification | Same value for all fragments of one original packet |
| Flags | Control fragmentation and mark whether more fragments follow |
| Fragment Offset | Indicates where the fragment belongs within the original payload |
| Total Length | Size of this fragment, header plus data |
The Flags field has three bits. One is reserved and unused for fragmentation, and two are relevant here:
| Bit name | Meaning when set to 1 |
|---|---|
| DF | Do Not Fragment, router must not fragment this packet |
| MF | More Fragments, there are more fragments after this one |
The very last fragment of a packet has MF set to 0. All previous fragments have MF set to 1. The first fragment has an offset of 0, later fragments have an offset that tells the receiver where this fragment’s data begins in the original payload. The offset is measured in units of 8 bytes, not in single bytes, which has a direct effect on how routers calculate fragment sizes.
Fragment alignment rule:
IPv4 fragment data sizes, except possibly the last fragment, must be a multiple of 8 bytes because the Fragment Offset is counted in 8 byte units.
Fragmentation Example on a Link with Lower MTU
Consider a host that sends an IPv4 packet of total length 2000 bytes. This includes the IPv4 header. The packet arrives at a router that must forward it out an interface with an MTU of 1500 bytes. The router must fragment the packet so that each fragment fits into 1500 bytes.
We need to choose a data size per fragment that, when we add the IPv4 header, is less than or equal to 1500 and is a multiple of 8. If the IPv4 header is 20 bytes long, the maximum data payload inside the MTU is:
$$
\text{Max data per fragment} = \text{MTU} - \text{IP header size} = 1500 - 20 = 1480 \text{ bytes}
$$
1480 is divisible by 8, so it is valid. The original 2000 byte packet has 1980 bytes of data after subtracting the 20 byte header.
We split 1980 bytes of data into pieces that are at most 1480 bytes each. There will be two fragments:
First fragment: 1480 bytes of data, 20 bytes header, total 1500 bytes.
Second fragment: remaining 500 bytes of data, 20 bytes header, total 520 bytes.
Check the offsets:
First fragment: offset is 0. MF is 1 because more fragments follow.
Second fragment: offset is $1480 / 8 = 185$. MF is 0 because this is the last fragment.
Both fragments have the same Identification value. At the destination, IP reassembly will:
- Collect all fragments with that Identification and the same source and destination.
- Use the offset values to put the data in correct order.
- Use the MF bit to detect the last fragment.
- Verify that the reconstructed total length matches what is expected.
If a fragment never arrives, the receiver times out and discards all collected fragments for that packet.
Do Not Fragment and Packet Loss
The DF flag in IPv4 can forbid routers from fragmenting a packet. When DF is set to 1, a router that encounters a packet larger than its outgoing MTU is not allowed to fragment it. Instead, it drops the packet and sends back an ICMP message indicating that fragmentation was needed but DF was set.
This behavior is essential to several mechanisms that try to discover the path MTU. Applications or operating systems send packets with DF set and then use ICMP feedback from routers to learn that a packet is too large somewhere along the path.
From a troubleshooting perspective, this also means that large packets with DF set can silently fail if intermediate firewalls block the ICMP messages that should return. The source then knows only that communication is not working, not why.
Performance Impact of Fragmentation
Fragmentation is usually undesirable from a performance perspective. While it allows packets to cross links with smaller MTUs without involving the sender, it has several negative effects.
Each fragment needs its own IP header, so fragmentation increases overhead compared to a single packet of the same total payload. Router CPU and memory usage can increase because routers must perform the fragmentation work. At the destination, reassembly consumes resources and can fail if any fragment is lost.
If any single fragment of a given packet is dropped, the whole original packet must be considered lost by the receiving host. For reliable protocols, this leads to retransmissions of the entire original packet, not only the missing fragment, which wastes bandwidth.
Because of these factors, network designers often try to avoid fragmentation by setting MTUs consistently, by adjusting application or tunnel settings, or by using path MTU discovery techniques.
Design guideline:
Avoid unnecessary fragmentation. Use consistent MTUs where possible and allow mechanisms that discover the effective path MTU.
IPv6 and Fragmentation
IPv6 handles fragmentation differently from IPv4. Routers in IPv6 do not fragment transit packets. Only the source node is allowed to create fragments, and it does so using a special extension header. If an IPv6 router receives a packet that is too large for its outgoing interface, it must drop the packet and send an ICMPv6 error back to the sender.
This difference means that path MTU discovery is even more important with IPv6. The sender has to choose a packet size that can traverse the entire path without fragmentation by routers. How IPv6 expresses fragmentation details in its headers and how it interacts with ICMPv6 belongs to the dedicated IPv6 and ICMP topics.
MTU and Tunnels
Whenever a network uses tunnels, such as VPNs or overlays, extra headers are added to encapsulate the original packet. These extra headers consume some of the available MTU. If nothing is adjusted, a packet that was fine on a normal path may become too large once encapsulated.
One way to handle this is to reduce the effective MTU for the endpoints that send traffic into the tunnel, so that once encapsulation headers are added, the resulting packet still fits inside the physical link MTU. Another way is to rely on path MTU discovery and fragmentation, but this can hurt performance, especially if multiple layers of encapsulation exist.
This interaction between tunneling overhead and MTU planning is an important design consideration when building VPNs or more complex overlay networks. The exact settings are specific to the tunneling technology and are handled in their own chapters.
Practical MTU Considerations
In practice, common Ethernet networks often use an MTU of 1500 bytes for IP. However, some environments enable so called jumbo frames, which are frames that carry much larger MTUs, often 9000 bytes or more. Jumbo MTUs can reduce overhead for high throughput applications, but they require very careful, end to end configuration. If a path contains a single link that cannot support the larger MTU, fragmentation or drops will occur.
Applications that send large packets, like file transfers or video streams, usually rely on the underlying operating system to set reasonable packet sizes. Engineers sometimes adjust MTU or a related parameter called MSS at the transport layer to control how big packets can become. The exact tuning of these values depends on the protocols in use and on the network path characteristics.
Understanding MTU and fragmentation gives you the foundation to diagnose problems where some kinds of traffic work while larger payloads fail, to reason about the impact of tunnels on packet size, and to interpret ICMP messages that report fragmentation issues.