It all started with a seemingly simple problem. My home network, centered around a Xiaomi AX6000 router running its stock firmware, was supposed to support IPv6. I had enabled it, and indeed, the router’s WAN port proudly displayed a public IPv6 address. Yet, none of my devices – my computers, my phone, my game consoles – could get one. Accessing IPv6-only websites was impossible.

Diving Deep into IPv6 and Network Structure

After some initial head-scratching, research pointed towards a concept called Prefix Delegation (PD). In simple terms, my ISP assigns a block (prefix) of IPv6 addresses to my router, and the router is then responsible for distributing individual addresses from that block to my devices. The symptom – WAN gets an address, LAN doesn’t – strongly suggested PD was failing.

Why? The prime suspect became my ISP’s modem (Optical Network Terminal or ONT). Was it running in router mode instead of bridge mode? If the modem itself was acting as a router and didn’t properly support delegating the prefix downstream, my AX6000 would never receive the necessary block.

I confirmed my network topology: ONT (in router mode) -> Switch -> Multiple Routers (including the AX6000). Unfortunately, due to other devices directly connected to the ONT via the switch, simply switching the ONT to bridge mode wasn’t feasible without restructuring everything.

As a temporary workaround, I enabled NAT6 on the AX6000. Success! My devices could now access IPv6 websites. However, I knew this wasn’t true end-to-end IPv6. NAT6 essentially translates internal IPv6 addresses, similar to how traditional NAT works for IPv4. It solved the immediate browsing issue but didn’t address the underlying PD failure and wouldn’t help with services requiring direct public IPv6 reachability.

Enter the Double NAT Monster

Around the same time, my Xbox started complaining: “Double NAT detected.” This made perfect sense. My network traffic was going through two layers of Network Address Translation: first at the AX6000, and then again at the ISP’s ONT (which was also acting as a router). This configuration is notorious for causing issues with online gaming, peer-to-peer connections, and services requiring open ports.

We discussed potential mitigations like UPnP, manual port forwarding, and placing the AX6000 in the ONT’s DMZ, but none felt like a clean solution.

The CGNAT Revelation

The real blow came when investigating the Double NAT further. By comparing the WAN IP address shown on my ONT’s status page with the public IP address reported by websites like “whatismyip.com”, I confirmed a dreaded reality: I was behind Carrier-Grade NAT (CGNAT). My ISP wasn’t assigning my ONT a unique, public IPv4 address. Instead, I was sharing one with potentially hundreds of other customers.

[Placeholder: Add a screenshot here showing the discrepancy between your ONT’s WAN IP (likely a private 10.x or 100.x address) and your public IP, confirming CGNAT.]

This revelation made two things crystal clear:

  1. Solving the Xbox NAT issue reliably via IPv4 was going to be nearly impossible without resorting to complex (and often unreliable) tunneling solutions.
  2. Getting native, public IPv6 working correctly was no longer just desirable; it was essential for any kind of future-proof home networking or self-hosting.

Back to the IPv6 Root: The Faulty ONT

With renewed focus, the investigation circled back to the ONT. I confirmed the ONT itself was receiving a /64 or similar public IPv6 prefix starting with 240e:. The problem was solely its inability to delegate this prefix downstream.

Analyzing the ONT’s configuration page revealed a peculiar “Port Binding” setting. Initially, only LAN1 was bound for internet services.

I modified the settings to bind all LAN ports. Hope surged… but was quickly dashed. Even after ensuring all ports were bound, testing with the AX6000 and other routers on different ports yielded the same result: no PD, no LAN-side public IPv6.

The conclusion was unavoidable: the ONT’s Prefix Delegation functionality was faulty, likely due to a hardware limitation or firmware bug. Relying on it was a dead end.

I needed a router powerful and flexible enough to potentially work around the ONT’s limitations, or perhaps even replace its routing functions altogether. This led me to revisit an old piece of hardware sitting in my closet… a supposedly bricked Netgear R8000 running OpenWrt. Could it be resurrected?