IPv6: Ping Works but HTTPS Stalls — Is MTU the Problem?

A successful IPv6 ping does not prove that a web application is reliably reachable. If small requests work but HTTPS stalls during connection setup or larger responses, packet sizes are worth investigating. An MTU problem is one possible cause, not a diagnosis: DNS, TLS, packet loss and the application also need to be narrowed down. The useful starting point is a reproducible comparison against the same destination.

What changes between a ping and a large response

The path MTU is the smallest IP MTU along a transmission path. If an IPv6 packet is too large for the next link, a forwarding router does not fragment it. It drops the packet and informs the sender through an ICMPv6 Packet Too Big message. The sender can then adjust its packet size. Without that feedback, the TCP connection may be established successfully while subsequent data transfer stalls. RFC 8200 and RFC 8201 describe this behaviour.

A deliberately simplified example

The following is an illustrative calculation, not a measurement of the AS51202 network: a server sends through an interface with a 1,500-byte IP MTU. A tunnel along the path has an effective inner IP MTU of 1,400 bytes. A small test packet fits. A 1,500-byte IPv6 packet does not fit there. The correct response is appropriate feedback to the sending endpoint; without it, the user may see only a timeout.

The 1,400-byte value is an assumption here. Tunnel types, additional headers and outer MTUs differ. Do not copy this value into a configuration without checking it. IPv6 generally requires a link MTU of at least 1,280 bytes; smaller underlying transmission units must be handled below IPv6. An arbitrarily low IPv6 MTU is not a universal repair.

A six-step diagnostic workflow

1. 1Record the destination and failure: hostname, actual IPv6 address, timestamp with time zone, source network and affected operation. Compare the same service over IPv4 and IPv6. Different CDN endpoints or backends make that comparison less conclusive.
2. 2Locate the failure phase: does name resolution, TCP setup, the TLS handshake or only the response fail? Test a known small resource and a larger one. A TLS error alone does not establish an MTU fault.
3. 3Vary packet sizes in a controlled test: use appropriate diagnostic tools between endpoints you own or are authorised to test. Distinguish the test payload from the total IP packet size. Protocol headers count too; fragmented test packets must not be compared as if they were unfragmented.
4. 4Capture at the same time: observe the sending host and, where accessible, both sides of a suspected bottleneck. Look for matching ICMPv6 Packet Too Big messages, the reported MTU and retransmitted data. A message missing at one observation point does not prove which device lost it.
5. 5Test directions and paths separately: uploads and downloads swap the sender's role. Repeat against the same destination and record the path used. A different source host, tunnel or upstream can produce a different result.
6. 6Validate one targeted change: record the previous state, correct only the demonstrated fault and repeat the same application test. Also check larger transfers, new connections and the reverse direction. This makes it possible to identify which change helped.

ICMPv6 is more than ping

Echo Request and Echo Reply are different message types from Packet Too Big. A rule allowing ping is therefore insufficient. RFC 4890 lists Packet Too Big (Type 2) among essential error messages that should not be dropped. Check the router ACLs, firewalls and host filters actually applied along the return path to the sender. The message may originate from an intermediate router, not only the destination server.

For stateful filters, reading a rule label such as “related” is not enough: the specific test must demonstrate that matching feedback reaches the sender. Also check whether local rate limits affect your observations. The remedy is an appropriate ICMPv6 policy with a verified effect, rather than a blanket allowance for every message type.

Treat tunnels and UDP separately

With a tunnel, feedback may initially reach its ingress. The tunnel implementation must process it correctly and convey the necessary information to the original sender. RFC 8899 describes these failure modes and Datagram Packetization Layer Path MTU Discovery: suitable transports can discover usable packet sizes through acknowledged probes without relying exclusively on ICMP feedback. Support in your particular application must be checked.

TCP MSS adjustment can be a limited workaround for TCP. It replaces neither a correct MTU configuration nor testing UDP-based services such as QUIC. Document any workaround explicitly and test all affected protocols, rather than treating one successful browser request as proof that the fault has been fully resolved.

What information helps your network operator

• Source and destination addresses, direction, protocol and an exact test window.
• Interface and tunnel MTUs, packet sizes from successful and failed attempts, and known encapsulations.
• A bounded capture shared with data minimisation in mind, including matching Packet Too Big messages and observed retransmissions.
• Results before and after the change, and whether alternative paths are affected.

When planning an IP transit connection, include MTU alongside VLAN and handoff details in the technical discussion. Add bidirectional IPv6 application tests to acceptance testing. For an AS51202 enquiry, provide your location, required bandwidth and existing tunnels so that the handoff and test scope can be discussed concretely. The linked articles cover requirements, multihoming and site connectivity in more detail.