MTU, MSS & Fragmentation
Every link a packet crosses has a maximum frame size it will carry. That single per-link limit ripples all the way up the stack - it shapes how IP handles oversized packets and how TCP picks a segment size before the first byte of data is ever sent.
MTU - the per-link ceiling
The MTU (Maximum Transmission Unit) is the largest IP packet a given link can carry in one frame. It is a property of the link, not the path - Ethernet's default MTU is 1500 bytes, but other links differ:
| Link | Typical MTU |
|---|---|
| Ethernet | 1500 bytes |
| Wi-Fi (802.11) | 2304 bytes (usually capped at 1500 to match Ethernet) |
| PPPoE (many DSL/fiber ISPs) | 1492 bytes |
| Jumbo frames (data center NICs) | 9000 bytes |
| Classic dial-up / some tunnels | 576 bytes or less |
A packet's route usually crosses several links with different MTUs, so the router in the earlier Forwarding & Routing discussion has to decide what happens when a packet arrives that is bigger than the MTU of the outgoing link.
Fragmentation - splitting an oversized packet
When a router must forward a packet onto a link whose MTU is smaller than the packet, IP can fragment it: split the payload into multiple smaller IP packets, each with its own IP header, marked so the destination host can put them back together. Every fragment carries the same identification number, an offset recording where its data belongs in the original payload, and a "more fragments" flag - cleared only on the last piece.
Reassembly happens once, at the final destination host, not at intermediate routers. That is exactly why fragmentation is expensive in practice:
Reassembly requires every fragment to arrive. If even one fragment is lost, the entire original packet is undeliverable and must be retransmitted in full - the network already spent bandwidth carrying the fragments that did arrive, and that work is wasted. Fragmentation also adds per-fragment header overhead and CPU work on both the sending router and the receiving host. For these reasons, production networks are engineered to avoid fragmentation entirely rather than rely on it.
The DF bit and PMTUD
Instead of fragmenting, a sending host can set the DF (Don't Fragment) bit in the IP header. A router that cannot forward the packet without fragmenting it - and sees DF set - drops the packet instead, and sends back an ICMP "Destination Unreachable - Fragmentation Needed" message that includes the MTU of the link that couldn't take it.
Path MTU Discovery (PMTUD) uses exactly this signal. A sending host starts by assuming a large MTU, sets DF on its packets, and shrinks its packet size each time it gets back a "fragmentation needed" ICMP message - until packets stop being rejected. The result is the smallest MTU anywhere along the path, the path MTU, discovered without any fragmentation ever occurring.
PMTUD depends entirely on that ICMP message getting back to the sender. Many firewalls and security groups block ICMP by default, treating it as unnecessary noise. When that happens, the router with the smaller MTU silently drops the oversized packet and the ICMP reply never arrives - the sending host has no idea anything went wrong. It keeps sending large packets, they keep getting dropped, and the connection simply hangs or times out with no error. This is the classic PMTUD black hole: everything works for small transfers (which never hit the MTU limit) and mysteriously stalls on larger ones, often only over specific paths or specific tunnels. The fix is to make sure ICMP "fragmentation needed" is allowed through, or to avoid the problem entirely by clamping MSS (below).
MSS - TCP's answer to MTU
TCP does not want to rely on IP fragmentation at all, so it tries to never send a segment bigger than the path can carry unfragmented. The MSS (Maximum Segment Size) is the largest amount of TCP payload data a segment will carry, and each side advertises its own value as a TCP option in the SYN packets during the handshake described in the transport-layer material.
Each host computes its MSS from its own outgoing interface's MTU: MSS is typically MTU minus 40 bytes (20 bytes for the IP header, 20 for the TCP header). For standard Ethernet with a 1500-byte MTU, that gives an MSS of 1460 bytes. The two hosts exchange their MSS values in the SYN and SYN-ACK, and each then sends data no larger than the smaller of the two advertised values - so the resulting segment size respects whichever end has the more constrained link.
MSS negotiation only accounts for the two endpoints' own interfaces, though - it knows nothing about a smaller MTU somewhere in the middle of the path. That gap is exactly what PMTUD exists to close, and exactly what breaks when PMTUD is black-holed.
Tunnels shrink the effective MTU
Encapsulating a packet inside another protocol - a VPN, a GRE tunnel, VXLAN, or IPsec - wraps the original packet in an extra header, which eats into the 1500-byte budget without the endpoints necessarily knowing it:
| Encapsulation | Typical overhead |
|---|---|
| GRE | 24 bytes |
| IPsec (ESP, tunnel mode) | ~50-73 bytes depending on cipher |
| VXLAN | 50 bytes |
| Typical VPN (e.g. WireGuard, OpenVPN) | ~40-60 bytes |
A host on either end of the tunnel still advertises an MSS based on its physical interface's 1500-byte MTU, with no idea that 50 of those bytes are about to be consumed by a tunnel header somewhere in the middle of the path. The packet becomes too big for the tunnel's effective MTU, DF is typically set (as it is by default on most modern stacks), and the tunnel endpoint has to drop it and rely on PMTUD - which, per the black-hole scenario above, frequently doesn't make it back to the sender.
The standard fix, applied on the tunnel or VPN gateway itself, is MSS clamping: the gateway rewrites the MSS option in transiting SYN packets down to a value that already accounts for the tunnel overhead (for example, 1460 becomes 1400 for a 50-byte-overhead tunnel). Since MSS is negotiated once at connection setup, this makes every subsequent segment on that connection small enough to survive encapsulation - no fragmentation, no dependence on ICMP making it back through a firewall, and no silent stalls. It's the reason "some sites work over the VPN and others hang forever" is almost always an MSS clamping bug.