IPv6 Troubleshooting — Fedora behind Orbi + Proximus BBx

A diagnostic and resolution guide for broken IPv6 causing perceived slow browsing (a “spinner” effect lasting several seconds before any page renders).

Notation: replace <interface_wifi> with your interface (e.g. wlp0s20f3) and <nom_connexion> with the name of your NetworkManager profile (e.g. elma).

Symptoms

Chrome and Firefox take several seconds before displaying any site
DNS is fast when tested from the CLI (DNS is quickly ruled out)
Identical behavior regardless of the site
The effect is noticeably less pronounced with curl on the command line
Access to local resources is nominal

Typical root cause

Inconsistent IPv6 configuration: DNS returns AAAA records but outbound IPv6 routing does not work. Browsers implement Happy Eyeballs (RFC 8305): they try IPv6 and IPv4 in parallel, but with an IPv6 preference delay (~250 ms per destination) before definitively switching. On a modern page with 30+ third-party resources, the cumulative delay can reach several seconds.

Cascading diagnosis

1. Rule out DNS

time dig google.com
resolvectl status
nmcli dev show | grep -i dns

If dig responds in under 50 ms, DNS is not the cause. Key indicator: Query time in the dig output.

2. Test outbound IPv6 vs IPv4

curl -6 -v https://www.google.com -o /dev/null --max-time 5
curl -4 -v https://www.google.com -o /dev/null --max-time 5

Typical diagnosis of broken IPv6: -6 returns Network is unreachable (immediate failure or timeout), -4 is fast. The asymmetry confirms it.

3. Inspect IPv6 routes

ip -6 addr show <interface_wifi>
ip -6 route

Key indicators:

Global address present: 2a02:… prefix on Proximus, not fe80:: (link-local) or 2002:… (obsolete 6to4)
default via … route: indispensable. Its absence = no IPv6 connectivity, even if an address is assigned.

Temporary workaround — disable IPv6 per profile

Immediately fixes the browser slowdown without touching other profiles (mobile, other SSIDs):

nmcli -t -f NAME,DEVICE con show --active
nmcli con mod <nom_connexion> ipv6.method disabled
nmcli con down <nom_connexion> && nmcli con up <nom_connexion>

Verification:

nmcli con show <nom_connexion> | grep ipv6.method
ip -6 addr show <interface_wifi>

The interface should no longer have an IPv6 address and ip -6 route should no longer contain an entry for this interface.

Structural fix — Orbi in IPv6 pass-through

Typical cause for Orbi users behind a Proximus BBx: the Orbi is configured by default or by accident in IPv6 6to4 Tunnel mode. This is a mechanism deprecated by RFC 7526 (2015), whose public relays have long been shut down, and which in any case cannot work behind an IPv4 NAT (it requires a public IPv4 on the router).

Characteristic symptom: LAN IPv6 address in the 2002:…::/16 range (RFC 3056) in the Orbi admin.

Remediation steps

Orbi admin: http://orbilogin.com (or the Orbi’s local IP)
Advanced → Advanced → IPv6
Internet Connection Type → Auto Detect
Apply

The Orbi detects what the BBx offers upstream and switches automatically, typically to Pass Through. In this mode, the BBx handles IPv6 routing natively and the Orbi simply relays.

Re-enabling IPv6 on Fedora after the Orbi fix

nmcli con mod <nom_connexion> ipv6.method auto
nmcli con down <nom_connexion> && nmcli con up <nom_connexion>
sleep 5
ip -6 addr show <interface_wifi>
ip -6 route

Final validation

Indicators of a healthy IPv6 assignment:

Global IPv6 address (2a02:… prefix on Proximus)
default via fe80::… route pointing to the router
Delegated /56 prefix visible in the routes if the BBx propagates it

External tests:

ping6 -c 3 ipv6.google.com
curl -6 -s https://ifconfig.co

Visit https://test-ipv6.com — a 10/10 score is expected.

IPv6 MTU diagnosis (if throughput degraded after the fix)

If IPv6 works but throughput is degraded, suspect a PMTUD black hole: an intermediate hop with MTU < 1500 whose ICMPv6 “Packet Too Big” messages are filtered, causing silent dropping of large packets.

Detection

ping6 -M do -s 1452 -c 3 ipv6.google.com
ping6 -M do -s 1432 -c 3 ipv6.google.com
ping6 -M do -s 1300 -c 3 ipv6.google.com

Calculation: payload size + 8 (ICMP header) + 40 (IPv6 header) = total packet size. -s 1452 tests a 1500-byte packet.

If -s 1452 returns “Message too long” but -s 1432 passes → PMTU < 1500. Refine by bisection if needed.

Temporary fix

sudo ip link set <interface_wifi> mtu 1480

Permanent fix

nmcli con mod <nom_connexion> 802-11-wireless.mtu 1480
nmcli con down <nom_connexion> && nmcli con up <nom_connexion>
ip link show <interface_wifi> | grep mtu

As a bonus, check whether the BBx advertises an MTU in its Router Advertisements:

sudo dnf install -y ndisc6
sudo rdisc6 <interface_wifi> | grep -i mtu

Proximus-specific notes

Assigned prefix: 2a02:xxxx::/32 (Proximus range, formerly Belgacom)
Typical delegation: /56 to the BBx via DHCPv6-PD
WAN mode: native IPv6 (neither 6rd nor DS-Lite)
Proximus DNS: have IPv6 even if the customer line does not (can be misleading — an IPv6 test of the DNS is not enough to confirm IPv6 connectivity of the line)
If IPv6 is disabled in the BBx admin despite an option being present → contact Proximus support to enable the IPv6 profile on the provisioning side

Long-term recommendation

The BBx → Orbi double NAT is messy and adds problems (IPv6 firewall, ICMP filtering, performance). Clean options:

Orbi in AP Mode (Router/AP Mode in the Orbi admin) — the BBx routes everything, the Orbi only does mesh wifi. The most reliable solution.
BBx in bridge mode — the Orbi does everything. Rarely available on Proximus residential subscriptions, to be confirmed depending on the plan.

Option 1 is generally preferable: fewer Orbi features (QoS, parental control) but a consistent network stack and native IPv6 without tinkering.

Quick reference

time dig google.com
curl -6 --max-time 5 -o /dev/null https://www.google.com
ip -6 route
nmcli con mod <nom_connexion> ipv6.method disabled
nmcli con down <nom_connexion> && nmcli con up <nom_connexion>