IPv4 fragments in transit; IPv6 sends Packet Too Big instead

IPv6 failures get blamed on the protocol far more often than on the packet size that caused them. The two families genuinely handle an oversized packet differently, and a tunnel is what makes the difference matter. IPv4 routers may fragment a packet when the rules allow it, while IPv6 routers must not fragment in transit at all. IPv6 tells the sender instead, and the sender is expected to react. Everything that goes wrong afterwards follows from whether that message arrives.

What each family does

The table is the mechanism in four lines, and one row explains most of the confusion.

IPv6 has no in-transit fragmentation and no DF flag to clear, so there is nothing to fall back to when a packet is too large. The sender has to be told, and the sender has to believe it.

The tunnel shrinks the path quietly

A VPN adds outer headers, and in the encrypted case integrity data too, before the packet leaves the host. The inner packet can fit the interface MTU it sees while the outer packet exceeds the next link's limit, which is why a tunnel is where this surfaces first. Lower the tunnel interface MTU deliberately, or clamp TCP MSS on the path, and write down the number you chose and why.

ESP overhead depends on mode and algorithms, so the right tunnel MTU is a calculation rather than a convention. Whatever you pick has to leave room for a full 1280-byte inner IPv6 packet, because every IPv6 link is required to carry that much. A tunnel that cannot carry 1280 bytes of IPv6 is not a tuning problem; it is a broken path for that family. That constraint is what disappears when an MTU value is copied from an IPv4-only deployment.

Why the symptom is a hang

The failure is not a clean error, which is why it gets misdiagnosed. A TCP handshake completes, small responses arrive, and the connection stalls as soon as a large response or a bulk upload starts, because those are the first packets large enough to be dropped. SSH connects and then hangs on the first large output, and a page's header loads while the body never finishes.

If the ICMPv6 Packet Too Big messages are filtered, the sender never learns and keeps retrying the same size. That is a black hole rather than a slow path, and its signature is a repeatable size boundary rather than random loss. Keeping the relevant control traffic permitted is part of a working IPv6 deployment, not a courtesy.

Do not disable the messages your own path depends on and then describe the result as an IPv6 fault. The same argument applies to IPv4's Fragmentation Needed messages, which are equally unpopular with firewall authors and equally necessary.

Measure the boundary, then fix the layer

Probe rather than guess: use the don't-fragment flag on IPv4 and fixed payload sizes on IPv6, and record where replies stop. ping -M do -s 1472 and ping -6 -s 1400 are enough to establish the shape of the problem, and tracepath reports the discovered path MTU along the way.

Then fix the layer that owns the number: the tunnel interface MTU, the MSS clamp for TCP, or the path itself. RFC 8200 is the reference for the IPv6 rule, and it is a shorter read than the incident it prevents.

Test the family the application actually uses, because a dual-stack name can answer on one family and not the other, and an application may switch after a network change. Record the address you tested, since a result against the A record says nothing about the AAAA record.

Treat the size boundary as evidence

A repeatable size boundary is one of the few network faults that reproduces exactly, at the same byte count, from the same source, every time. That makes it a gift rather than a mystery, and it also means a fix can be verified instead of hoped for.

Write the discovered MTU, the tunnel MTU you configured and the test that proved the difference into the ticket. The next person will meet the same arithmetic on a different link.