A host can know the maximum transmission unit of its own network interface without knowing the smallest limit farther along a route. Ethernet might accept one packet size while a tunnel, access link, or other intermediate network accepts less.
Path MTU Discovery, commonly shortened to PMTUD, lets an endpoint adapt to that route-level limit. The mechanism matters because an IP packet that fits the sender’s local link can still be too large for a later hop.
The path limit comes from its smallest link
Every link technology has a maximum IP packet size it can carry without link-specific fragmentation or another form of adaptation. The effective path MTU is the smallest such limit across the route between endpoints.
That value is not necessarily permanent. Routing can change, tunnels can be inserted or removed, and traffic in opposite directions can follow different paths. An endpoint therefore cannot safely treat its local interface MTU as a universal property of the connection.
For transport protocols such as TCP, the path limit affects the useful segment size. TCP accounts for IP and TCP headers when deciding how much stream data to place into a packet. Options and encapsulation can further reduce the payload available inside a given MTU.
IPv4 and IPv6 handle oversized forwarding differently
Classic IPv4 permits a router to fragment a packet when the packet is too large for the next link, unless the packet indicates that fragmentation must not occur. PMTUD for IPv4 traditionally sends packets with the Don’t Fragment flag set. A router that cannot forward one intact drops it and returns an ICMP Destination Unreachable message with the fragmentation-needed indication and relevant MTU information when available.
The sender can then reduce its packet size and try again.
IPv6 takes a different approach. Routers do not fragment IPv6 packets in transit. When a packet exceeds the next-hop limit, the router drops it and sends an ICMPv6 Packet Too Big message containing the supported MTU. Fragmentation, when required, is performed by the source rather than an intermediate router.
Both cases make feedback from the network important to efficient packet sizing.
Missing ICMP feedback can create a black hole
Some firewalls and middleboxes discard ICMP traffic too broadly. That policy can interfere with PMTUD when an oversized packet is dropped but the corresponding size error never reaches the sender.
The resulting connection can look unusual. Small packets may pass normally, so a TCP handshake or short request succeeds. Larger packets can then disappear repeatedly once application traffic reaches a size that exceeds a hidden path limit.
Retransmission alone does not solve the mismatch if each retry uses an equally oversized packet. The sender needs either valid path-size feedback or another method for detecting that smaller packets are required.
This failure mode is often called a PMTU black hole. It is one reason blanket filtering of ICMP and ICMPv6 can damage ordinary network operation rather than simply remove diagnostic traffic.
Packetization Layer PMTUD tests sizes without ICMP dependence
Packetization Layer Path MTU Discovery moves more of the probing logic into a transport or other packetization layer. Instead of relying solely on ICMP errors, an endpoint can send probes of selected sizes and use transport-level delivery signals to determine whether those probes succeed.
This approach can operate even when useful ICMP feedback is unavailable. It also requires careful handling because packet loss can have causes unrelated to MTU. A failed probe must not automatically be treated as proof that every packet of that size exceeds the path limit.
Transport protocols can combine probing, acknowledgments, retransmission state, and conservative fallback sizes to make that distinction more robust.
TCP MSS and path MTU solve related but separate problems
During TCP connection setup, each endpoint can advertise a Maximum Segment Size, or MSS. The value describes the largest TCP payload that endpoint is prepared to receive in a segment under the assumptions used to calculate that advertisement.
MSS does not reveal every smaller MTU that may exist somewhere between the hosts. A tunnel or constrained intermediate link can still impose a lower path limit after the endpoints exchange their MSS values.
Network devices sometimes apply MSS clamping to TCP SYN packets, reducing the advertised value so later TCP segments fit a known constrained path. This can be useful around tunnels and similar deployments, but it is a targeted TCP workaround rather than a replacement for correct IP-layer MTU behavior across all protocols.
Encapsulation consumes part of the available packet budget
VPNs, overlay networks, and other tunnels add headers around traffic. Those extra bytes must fit on the underlying network, so a tunnel often exposes a smaller MTU to the traffic carried inside it.
If the inner packet size is chosen without accounting for encapsulation overhead, the outer packet can exceed the physical path limit. A well-configured tunnel selects an appropriate interface MTU and preserves the control traffic needed for path-size discovery.
Nested encapsulation can make the margin smaller still. Operators troubleshooting size-sensitive failures should therefore consider the complete packet stack rather than only the MTU displayed on an application host’s physical interface.
Route changes can invalidate an earlier packet size
A size that worked at connection startup can become too large after routing changes. Robust implementations allow stored path-MTU information to age, react to fresh feedback, and probe for a larger usable size when appropriate.
Keeping the estimate forever can leave a connection stuck at an unnecessarily small packet size after a temporary constraint disappears. Raising it too aggressively can recreate loss on a route that still has the lower limit.
PMTUD is therefore a continuing estimate of a path property, not merely a one-time calculation from the sender’s network card.
Correct size feedback keeps packet delivery predictable
Path MTU Discovery aligns packet construction with the narrowest link along a route. In IPv4 it can avoid router fragmentation by using fragmentation restrictions and ICMP feedback. In IPv6, Packet Too Big feedback supports the source-controlled packet sizing required by the protocol.
When that feedback is blocked, connections can pass small traffic while failing on larger transfers. Packetization-layer probing provides another route to a usable size, while sensible tunnel MTUs and selective ICMP handling prevent many failures before probing becomes necessary.
The practical effect is straightforward: packet size is constrained by the complete route, not just by either endpoint’s local network.