What is MTU Black Hole?

An MTU black hole is a network failure where packets larger than the Path MTU are dropped, but the sender does not receive the ICMP feedback it needs to reduce packet size. The connection can appear healthy because small packets still pass, yet larger transfers stall, time out or repeatedly retransmit. The key distinction is that the problem is not simply packet loss. It is packet loss combined with failed Path MTU discovery.

To understand the underlying limit first, read What is Path MTU (Maximum Transmission Unit)?.

How does an MTU black hole happen?

A sender normally tries to use packets that fit the complete network path. In classical IPv4 Path MTU Discovery, described by RFC 1191, the sender can set the Don't Fragment flag. If a router cannot forward a packet because the next link has a smaller MTU, it should discard the packet and return ICMP feedback identifying that fragmentation is needed. The sender can then lower its assumed Path MTU.

The black hole appears when the oversized packet is discarded but the relevant ICMP message is filtered, lost, generated incorrectly or otherwise never reaches the sender. RFC 2923 documents this long standing PMTUD failure mode and notes that small pings and some interactive TCP traffic may still work while bulk transfers fail when the first large packet is sent.

Why can a connection work and still have an MTU black hole?

Connection setup often uses relatively small packets. Those packets can fit through a constrained path even when larger packets cannot. This creates one of the most confusing symptoms in networking: DNS may resolve, a TCP connection may establish, small requests may work, and then a larger web page, file transfer, VPN session or other data flow appears to freeze.

That behaviour is why an MTU black hole should not be diagnosed from a single ping result. It is an end to end packet sizing problem. Packet loss is the visible symptom, while failed PMTUD is the mechanism that prevents the sender from adapting.

A worked MTU black hole example

Techie Broadband practical example: assume a sender starts with a 1500 byte IP packet size, but a tunnel somewhere on the route can carry only 1420 byte IP packets. The difference is 80 bytes. A 1500 byte packet therefore cannot cross that part of the path intact under the assumed conditions.

1. Sender transmits a 1500 byte packet.

2. The path reaches a link or encapsulated segment whose effective MTU is 1420 bytes.

3. The oversized packet is discarded.

4. The router or tunnel endpoint generates the appropriate ICMP feedback, or should do so.

5. A firewall or other network behaviour prevents that feedback reaching the sender.

6. The sender does not learn that it should reduce packet size and continues trying packets that are too large.

7. Small packets can continue to work while larger data transfers stall or repeatedly retransmit.

What causes MTU black holes?

There is no single cause. The common factor is that packet size and feedback behaviour become inconsistent somewhere along the end to end path.

• Overly broad firewall rules that block ICMP or ICMPv6 messages needed for Path MTU Discovery.

• VPNs, tunnels or other encapsulation that reduce the effective MTU without packet sizing being handled correctly.

• A router, firewall, tunnel endpoint or middlebox that does not generate or forward the required feedback correctly.

• Network paths that change and introduce a smaller MTU than the sender previously learned.

• Incorrect interface MTU configuration.

• Complex nested encapsulation where additional headers reduce the space available to the original IP packet.

MTU black holes and IPv4

For IPv4, classical PMTUD uses the Don't Fragment flag and ICMP Destination Unreachable, Fragmentation Needed feedback. RFC 2923 describes the failure when the sender does not receive that feedback and therefore continues sending packets that cannot cross the constrained hop.

IPv4 fragmentation itself is not the definition of an MTU black hole. A black hole is specifically about packets disappearing while the sender fails to learn the usable packet size. Whether fragmentation is possible, prevented or undesirable depends on the packet and path behaviour.

MTU black holes and IPv6

IPv6 makes the distinction especially important because routers do not fragment IPv6 packets in transit. RFC 8201 defines IPv6 Path MTU Discovery and relies on ICMPv6 Packet Too Big feedback when a packet is too large for the path. It explicitly describes the possibility of a connection completing the TCP three way handshake and then hanging when data is transferred if ICMPv6 messages are blocked or not transmitted.

The IPv6 specification, RFC 8200, defines 1280 octets as the IPv6 minimum link MTU. Restricting packet size to 1280 can avoid depending on discovery of a larger PMTU, but it can also leave useful packet capacity unused on paths that support more.

Why blocking all ICMP is a bad idea

ICMP is not merely a ping mechanism. Some ICMP messages carry operational information that IP hosts need. Blocking every ICMP message without understanding its function can therefore break normal network behaviour, including Path MTU Discovery.

A sensible security policy is more precise: allow the ICMP and ICMPv6 messages required for correct network operation while applying appropriate validation and rate controls, rather than assuming every ICMP message should be discarded.

What is Packetization Layer Path MTU Discovery?

Packetization Layer Path MTU Discovery provides a more robust approach that does not depend solely on ICMP feedback. RFC 4821 specifies PLPMTUD, while RFC 8899 defines Datagram PLPMTUD for datagram transports. The packetization layer probes the path and uses successful delivery or loss behaviour to determine a usable packet size.

This matters for black holes because a sender can detect that larger probes are not succeeding and reduce its effective packet size even when useful ICMP feedback is unavailable.

MTU black hole versus ordinary packet loss

Ordinary packet loss can arise from congestion, faulty links, radio interference, overloaded equipment and many other causes. An MTU black hole has a size dependent pattern: packets below the limiting size can pass while packets above it disappear and the sender fails to adapt.

That can reduce throughput and goodput, but low throughput alone does not prove an MTU problem.

Where can this appear on UK broadband?

The access technology itself does not automatically create an MTU black hole. FTTP, FTTC, cable and other UK broadband services can all carry traffic successfully when packet sizing is handled correctly. Problems are more likely to appear where the end to end path introduces a smaller effective MTU or loses the feedback needed to discover it.

Practical places to investigate include the customer router WAN configuration, PPP or other access encapsulation where applicable, VPN clients and gateways, business firewalls, site to site tunnels, cloud networking, IPv6 firewall policies and any equipment that changes or encapsulates packets.

How to diagnose a suspected MTU black hole

Diagnosis should look for size dependent failure rather than assuming every stalled connection is an MTU problem.

1. Confirm the problem affects more than one application or destination where possible.

2. Compare small requests with larger transfers. A repeatable size dependent failure is more meaningful than general slowness.

3. Test over wired Ethernet to remove WiFi instability from the diagnosis.

4. Temporarily remove VPNs or tunnels where practical and retest.

5. Inspect router, firewall and tunnel MTU settings rather than changing values blindly.

6. Check whether required ICMP or ICMPv6 feedback is being filtered.

7. Capture packets if you have the tools and knowledge. Look for repeated retransmissions, ICMP Fragmentation Needed messages, ICMPv6 Packet Too Big messages and packets that disappear above a repeatable size.

8. Test packet sizes carefully. Ping based tests can help, but their syntax and behaviour differ by operating system and they do not reproduce every transport or tunnel condition.

9. If the path crosses infrastructure you do not control, compare destinations and routes before concluding that your local router is responsible.

Use traceroute to understand the apparent route, but do not treat it as an MTU detector. Routers may respond differently to traceroute probes, and the hop shown before a failure is not automatically the device causing the MTU problem. Read more about routing when interpreting changing paths.

Should you simply lower the MTU?

Lowering an endpoint or tunnel MTU can be a useful diagnostic test and sometimes an appropriate configuration fix, but choosing an arbitrarily small value is not a good general solution. It can hide the underlying fault and increases packet overhead because the same application data may need more packets.

The better objective is to identify the real limiting path, configure encapsulation correctly, preserve the necessary feedback and use a packet size that is appropriate for the actual network path.

MTU black holes and TCP MSS

TCP Maximum Segment Size and Path MTU are related but not identical. MTU limits the IP packet size. TCP MSS describes the maximum TCP payload an endpoint advertises for a TCP segment. IP and TCP headers consume part of the MTU, and additional headers or options can reduce the available payload further.

MSS clamping is sometimes used at routers or tunnel boundaries to keep TCP segments small enough for a constrained path. It can be useful in specific deployments, but it is not a universal replacement for correct PMTUD and does not solve every non TCP packet sizing problem.

Common MTU black hole misconceptions

• A successful ping proves the MTU is fine. False. Small probes may fit while larger packets fail.

• Every slow connection is an MTU black hole. False. Congestion, WiFi, server limits, routing and many other factors can reduce performance.

• The broadband line speed determines MTU. False. Mbps or Gbps describes a rate, while MTU describes packet size.

• IPv6 routers can fragment an oversized packet on the way. False. IPv6 routers do not perform transit fragmentation.

• The smallest MTU value is always best. False. Unnecessarily small packets increase overhead and can reduce efficiency.

• Blocking ICMP always improves security. False. Indiscriminate filtering can break required network control behaviour.

MTU black hole FAQs

What is an MTU black hole in simple terms?

It is a failure where packets that are too large for part of a network path are dropped, while the sender does not receive the feedback needed to make the packets smaller.

What are the symptoms of an MTU black hole?

Typical clues include connections that establish but stall during larger transfers, websites that partly load, VPN traffic that behaves inconsistently, repeated retransmissions and small packets succeeding while larger packets fail.

Can an MTU black hole affect only some websites or services?

Yes. Different destinations can use different routes, tunnels, protocols and packet sizes, so one path can fail while another works normally.

Can a VPN cause an MTU black hole?

A VPN can contribute because encapsulation adds headers and can reduce the effective packet size available to the original traffic. Correct tunnel MTU, MSS handling and feedback behaviour matter.

Does an MTU black hole affect IPv6?

Yes. IPv6 Path MTU Discovery relies on ICMPv6 Packet Too Big feedback for paths using packets above the supported PMTU. Blocking that feedback can produce black hole connectivity.

Is MTU the same as TCP MSS?

No. MTU limits the IP packet size. TCP MSS limits the TCP payload advertised by an endpoint. Header overhead links the two values, but they describe different things.

Will lowering MTU always fix the problem?

Not always. A lower value can avoid a particular bottleneck, but the correct fix depends on where the packet sizing or feedback failure occurs.

Can traceroute identify an MTU black hole?

Not reliably by itself. Traceroute helps reveal an apparent route, but MTU diagnosis needs packet size testing, feedback inspection and often packet capture or controlled comparison.

The key point

An MTU black hole is not simply a connection that drops packets. It is a failure of adaptation: a path cannot carry packets of the size being sent, those packets disappear, and the sender does not receive or successfully use the information needed to reduce them. That is why the connection can look normal at first and then fail precisely when meaningful data begins to flow.

To explore the related technical concepts used in this MTU Black Hole guide, visit our broadband terminology guide.