Levandor

macOS "slow internet" at Telephely — Broken IPv6 Advertised on a v6-Dead Link

4 min read

The user’s Mac browsing at the Telephely site felt “absolutely ass” intermittently, while the wired box and raw bandwidth were fine. Root cause: telep-router was advertising a global + ULA IPv6 prefix to the LAN over a link that has NO working IPv6 upstream, so macOS kept trying the dead v6 path first (RFC 6724 / Happy Eyeballs) and stalling 2–7 s per dual-stack site before falling back to IPv4. Fixed by disabling RA/DHCPv6/NDP and wan6 on the router — Mac connect times dropped from 2–7 s to 0.02–0.06 s. See also SESSION-HANDOVER, IPv6 disabled on the LAN (2026-07-28).

For Agents

Verdict: the LAN was handed IPv6 addresses (global 2a00:1110:210:7653::/64 + ULA fd83:5e9d:98ca::/64) via RA/DHCPv6, but the WAN carries no working IPv6 (fixed-wireless + double-NAT). macOS prefers v6 → tries the dead path first → per-site 2–7 s stall → IPv4 fallback. Fix (applied + verified): on the router disable dhcp.lan.ra/dhcpv6/ndp and network.wan6, so the LAN is IPv4-only and the Mac never attempts v6. Reversible; backups exist.

Symptoms

  • Mac web browsing intermittently “absolutely ass” — pages hang for a few seconds, then load.
  • Wired box + raw bandwidth were fine: 300 Mbit down / 38–48 up, 18–20 ms RTT, 0% loss. So this was not a bandwidth or loss problem.
  • Mac-specific — macOS is the most aggressive OS about preferring IPv6.
  • Intermittent — the v6 addresses flapped active ↔ deprecated, so the stall came and went.

Diagnostic signature (the reusable part)

curl -w splits DNS from connect; -4 vs -6 proves which stack is dead

The tell was in curl -w’s timing breakdown: time_namelookup was instant but time_connect was 2–7 s — the delay is in the TCP connect, not DNS. Then:

  • curl -4 <dual-stack-site> → instant (IPv4 path healthy).
  • curl -6 <dual-stack-site> → timed out (IPv6 path dead).
  • ping6 <internet> → 100% loss; curl -6 → timeout.

DNS instant + connect slow + -4 fast + -6 dead = the host is trying a dead IP family first. On a Mac that is almost always IPv6 preference over a broken v6 upstream.

Root cause

The router advertised working-looking IPv6 to the LAN over a link with no v6 route out:

  • The router sent RA + DHCPv6 offering a global prefix 2a00:1110:210:7653::/64 and a ULA fd83:5e9d:98ca::/64 to LAN clients.
  • But IPv6 had NO working upstream — ping6 to the internet was 100% loss, curl -6 timed out.
  • macOS follows RFC 6724 address selection + Happy Eyeballs, which prefer IPv6. It tried the advertised v6 path first, stalled 2–7 s per dual-stack site, then fell back to IPv4. That per-site stall is the “slow internet”.
  • Contributing topology: the WAN is a TP-Link NE200 outdoor fixed-wireless unit, and the router is double-NAT’d behind it (router WAN got 192.168.254.2 from the NE200 at 192.168.254.1). Fixed-wireless + double-NAT almost never carries working IPv6 — so advertising a v6 prefix to the LAN was pure downside.

Fix (applied + verified on telep-router)

Disable IPv6 advertisement to the LAN and the WAN6 client:

uci set dhcp.lan.ra='disabled'
uci set dhcp.lan.dhcpv6='disabled'
uci set dhcp.lan.ndp='disabled'
uci set network.wan6.disabled='1'
uci commit
/etc/init.d/odhcpd restart
/etc/init.d/network reload

Result: Mac connect times dropped from 2–7 s to 0.02–0.06 s. The LAN is now IPv4-only; the Mac never attempts the dead v6 path.

  • Backups: /etc/config/dhcp.bak-ipv6fix, /etc/config/network.bak-ipv6fix.
  • Reversible — restore the backups and re-run the reload commands to re-enable v6 if the upstream ever gains real IPv6.

Related / follow-ups

The double-NAT itself is a separate issue worth undoing

The root topology problem (fixed-wireless WAN + double-NAT behind the NE200) still stands. Bridging / DMZ-ing the NE200 so the router holds the upstream address directly would remove the double-NAT and could restore genuine IPv6 — a separate task, not part of this fix. See Double-NAT.

Graph View

Backlinks