DEV Community

IPYE
IPYE

Posted on AI-assisted

Dual-Stack Hygiene: Happy Eyeballs, MTU and Path MTU Discovery, and the ICMPv6 You Must Not Filter

#ipv6 #networking #devops #tutorial

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

Dual-stack service, where a host answers on both IPv4 and IPv6, usually works because clients are forgiving. That forgiveness can hide faults, such as an IPv6 path that silently drops large packets. This article covers three things that often go wrong: how clients choose between address families, how packet size is negotiated, and which ICMPv6 messages a firewall has to let through. Examples use documentation addresses: 2001:db8::/32 and 192.0.2.0/24.

Happy Eyeballs: why clients usually cope

When a client resolves a name with both A and AAAA records, default address selection (RFC 6724) generally prefers IPv6. Happy Eyeballs (RFC 6555, updated by version 2 in RFC 8305) stops a broken IPv6 path from making users wait for a full TCP timeout. In outline, RFC 8305 describes:

  • Sending the AAAA and A queries together, and giving the AAAA answer a short head start, the Resolution Delay, recommended at 50 ms.
  • Starting connection attempts in turn rather than all at once, with a Connection Attempt Delay recommended at 250 ms, with a minimum of 100 ms and a maximum of 2 seconds.
  • Using whichever attempt completes first and cancelling the rest.

Implementations differ, and some simpler clients fall back slowly or not at all. The lesson for a server operator: Happy Eyeballs makes IPv6 faults less visible, not absent. A user on a bad IPv6 path may see a delay on every new connection and never report it.

Operator habits that follow from this:

  1. Publish AAAA only for services you run and test on IPv6. Do not remove the AAAA record to "fix" a problem you have not diagnosed; fix the path.
  2. Test and monitor each family on its own. curl -4 https://example.com/ and curl -6 https://example.com/ isolate the problem.

MTU and path MTU discovery

The link MTU is the largest packet a link can carry. Ethernet is typically 1500 bytes. The two IP versions handle oversize packets differently:

  • IPv4: a router may fragment a packet unless the Don't Fragment (DF) bit is set. Most modern TCP stacks set DF and rely on Path MTU Discovery (RFC 1191): a router that cannot forward a DF packet returns ICMP type 3, code 4 ("Fragmentation Needed").
  • IPv6: routers never fragment. Only the source can, and every link must support at least 1280 bytes (RFC 8200). A router that cannot forward a packet sends ICMPv6 type 2, "Packet Too Big", carrying the next-hop MTU (RFC 8201).

So IPv6 depends on Packet Too Big messages even more than IPv4 depends on its equivalent, because there is no router-side fragmentation to fall back on. If a firewall drops those messages, the sender never learns the real limit. Small packets (the TCP handshake, a short HTTP request) work; larger ones vanish. The symptom is a connection that stalls after the handshake or hangs during a TLS exchange or a large download. This is a PMTUD black hole. RFC 4821 describes packetization-layer discovery as a mitigation, but it is slower and no substitute for letting the errors through.

Common sources of a smaller MTU

Path element Typical effect
PPPoE 8 bytes overhead, so 1492
6in4 tunnel (protocol 41) 20 bytes over IPv4, so 1480
GRE over IPv4 24 bytes, so 1476
WireGuard 60 bytes over IPv4 or 80 over IPv6; default interface MTU of 1420 covers the larger case

MSS clamping

TCP's Maximum Segment Size excludes the IP and TCP headers. For a 1500-byte MTU the MSS is 1460 over IPv4 (1500 minus 20 minus 20) and 1440 over IPv6 (1500 minus 40 minus 20). On a router in front of a tunnel or PPPoE link, clamping the MSS in the SYN packets avoids the problem for TCP even if ICMP is lost. On Linux with nftables, tcp option maxseg size set rt mtu in a forward chain does this. It is a safety net, not a reason to filter ICMP, and it does nothing for UDP.

ICMPv6 you must not filter

Neighbor discovery, the IPv6 replacement for ARP, runs on ICMPv6, so blanket ICMP filtering breaks more than diagnostics. RFC 4890 gives filtering recommendations; the essentials:

  • Type 1, Destination Unreachable (all codes), type 2, Packet Too Big, type 3, Time Exceeded, and type 4, Parameter Problem: these are the error messages. Dropping them causes black holes and slow failures.
  • Types 133 to 137, Router Solicitation and Advertisement, Neighbor Solicitation and Advertisement, Redirect: required on the local link. Without neighbor solicitation and advertisement, hosts cannot resolve each other's addresses. Discard ND packets with a hop limit other than 255, which proves they did not cross a router.
  • Types 128 and 129, Echo Request and Reply: RFC 4890 recommends permitting these to your servers, optionally rate-limited.

A host firewall sketch in nftables, placed in a table inet filter input chain with a default drop policy:

ct state established,related accept
meta l4proto ipv6-icmp icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, echo-request, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept
meta l4proto icmp icmp type { destination-unreachable, time-exceeded, echo-request } accept
Enter fullscreen mode Exit fullscreen mode

A router's forward chain needs the error types too. Connection tracking usually marks matching ICMP errors related, but an explicit rule is clearer.

Verification

  • Probe with DF set: ping -6 -M do -s 1452 2001:db8::10 sends a 1500-byte packet (1452 data plus 8 ICMPv6 and 40 IPv6 header bytes). For IPv4, use -s 1472 with 192.0.2.10. Lower the size until it succeeds.
  • tracepath -6 reports the path MTU it finds hop by hop, and ip route get 2001:db8::10 shows a cached MTU after a Packet Too Big arrives.
  • Capture: run tcpdump -ni eth0 icmp6 during a stall. If Packet Too Big never arrives, something upstream is dropping it.
  • Compare families: if curl -4 works and curl -6 stalls on large responses, suspect MTU first.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space. A /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled for you. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

Top comments (0)