Updated 10 hours ago
Every packet you send into the Internet is a guess. Will it fit through that VPN tunnel? That old DSL link? That submarine cable? You don't know until you try.
Path MTU Discovery (PMTUD) is how your device learns the shape of the pipe. It sends packets, watches what breaks, and adjusts. When it works, you never notice it. When it fails, connections freeze in ways that make you question your sanity.
The Problem PMTUD Solves
The Internet is a patchwork. Ethernet links typically handle 1500-byte packets. PPPoE connections squeeze that down to 1492. VPN tunnels steal more bytes for encapsulation. Some ancient link in the middle of your path might only handle 1400.
You could play it safe and send tiny packets everywhere. IPv6's minimum MTU is 1280 bytes—that would always fit. But small packets waste bandwidth. Headers eat a larger percentage of each packet. More packets mean more processing. Efficiency suffers.
PMTUD finds the sweet spot: the largest packet that can traverse the entire path without being chopped up. Maximum efficiency, no fragmentation.
How Classical PMTUD Works
The mechanism is elegant. Your device sends a packet with the "Don't Fragment" flag set. This flag tells routers: if this packet is too big for the next hop, don't fragment it—drop it and tell me why.
When a router receives an oversized packet with DF set, it drops the packet and sends back an ICMP message: "Fragmentation Needed." Modern routers include a crucial detail in this message—the MTU of the link that couldn't handle the packet.
Your device receives this ICMP message, shrinks its packets to fit, and continues. Discovery complete.
The process starts optimistically. Your device tries its local MTU (usually 1500 bytes for Ethernet) and backs off only when forced to. This finds the largest working size without manual configuration.
TCP and PMTUD
TCP uses PMTUD to set its Maximum Segment Size (MSS)—the largest chunk of data it will stuff into a single packet. During the connection handshake, both sides announce their MSS based on local MTU. During data transfer, PMTUD refines this downward if needed.
Smart TCP implementations also probe upward periodically. Network paths change. That restrictive link might be gone. Why stay small if you don't have to?
The Black Hole Problem
Here's where it breaks. Classical PMTUD depends entirely on ICMP messages reaching the sender. Many firewalls block ICMP.
The result is a black hole. Your device sends packets. They're too big. Routers drop them. The ICMP messages explaining why get blocked. Your device never learns. It keeps sending packets that disappear. The connection freezes.
From your perspective: the connection established fine, then nothing. Large file transfers hang. Small ones work. The browser spins forever. You restart things. Sometimes that helps. Usually it doesn't.
The tragedy is that network administrators block ICMP "for security" without understanding they've broken the mechanism that keeps connections alive. The user stares at a frozen screen while somewhere a router dutifully drops packets into silence, forbidden from explaining why.
Packetization Layer PMTUD
PLPMTUD (RFC 4821) solves the black hole problem by ignoring ICMP entirely. Instead of waiting for routers to report problems, it probes actively.
The sender tries different packet sizes and watches what gets acknowledged. If a 1400-byte packet gets an ACK, the path MTU is at least 1400. If a 1500-byte packet times out repeatedly, it's probably too big.
This works even when ICMP is completely blocked. The transport layer already knows which packets succeeded. PLPMTUD just uses that information to infer MTU.
The algorithm is careful to distinguish MTU problems from congestion. Congestion drops packets randomly; MTU limits drop packets above a consistent threshold. PLPMTUD probes conservatively to avoid making congestion worse.
IPv6 Makes It Mandatory
IPv6 routers cannot fragment packets. Period. If a packet is too big, the only option is dropping it and sending ICMPv6 "Packet Too Big."
This makes PMTUD effectively mandatory for IPv6. Send packets larger than 1280 bytes, and you're betting on PMTUD working. If ICMPv6 gets blocked, IPv6 breaks harder than IPv4 ever did—there's no fallback fragmentation to save you.
Networks that block all ICMPv6 traffic break IPv6. It's that simple.
Real-World Workarounds
Because PMTUD fails often enough to matter, networks deploy workarounds:
MSS clamping: Routers rewrite the TCP MSS option during connection setup, forcing endpoints to use smaller segments. Common on PPPoE terminators where encapsulation steals bytes from every packet.
Conservative defaults: VPN clients often default to 1400-byte MTU or smaller, accepting some inefficiency to avoid discovery failures.
ICMP whitelisting: Smarter firewalls block most ICMP but allow "Fragmentation Needed" and "Packet Too Big" through. Security without breaking PMTUD.
Application-layer fragmentation: QUIC and HTTP/2 handle packet sizing above the IP layer, reducing dependence on PMTUD.
When Paths Change
Network paths change. Routing updates, failover events, mobile devices switching from WiFi to cellular—any of these can alter the MTU constraints.
Good TCP implementations periodically probe for larger MTUs. Cached path MTU information ages out. Long-lived connections rediscover their constraints.
This is why connections sometimes stall briefly when you switch networks. Your device is relearning the shape of the new pipe.
Debugging PMTUD Issues
The symptoms are distinctive: connections establish, then freeze during data transfer. Small transfers work; large ones don't.
Test with ping:
If large pings fail while small ones succeed, you've found an MTU limit. Binary search to find the exact threshold.
Traceroute with specific sizes can locate where the limitation occurs:
Packet captures reveal whether ICMP messages are being sent and received. Look for ICMP Type 3 Code 4 (IPv4) or ICMPv6 Type 2 (IPv6).
Test from different networks to isolate the problem: your network, their network, or somewhere in between.
Tuning
Most systems handle PMTUD automatically. But when you control the environment:
- Set interface MTU manually when you know the constraints
- Enable PLPMTUD if your stack supports it
- Configure MSS clamping at known bottlenecks
- Audit firewalls for ICMP filtering
- Test jumbo frames thoroughly before deployment in data centers
The Future
Newer protocols push MTU handling up the stack. QUIC implements DPLPMTUD above IP. Multipath TCP discovers MTU per-path. SDN could eventually provide explicit path MTU information, eliminating discovery entirely.
But for now, PMTUD remains how most traffic learns to fit through the Internet's pipes. When it works, packets flow efficiently. When it fails, connections freeze and users blame their ISP.
The fix is almost always the same: stop blocking ICMP.
Frequently Asked Questions About Path MTU Discovery
Was this page helpful?