Using the Internet without IPv4 connectivity

Original Article ↗ Hacker News Discussion ↗

As more networks become IPv6-only or put IPv4 behind carrier-grade NAT, users are resorting to workarounds like SSH SOCKS proxies, DNS64+NAT64 gateways, and VPNs via IPv6-capable VPSes to reach legacy IPv4-only services such as GitHub and Steam. Commenters highlight that while major sites and mobile carriers now work well over IPv6, the partial and inconsistent adoption across ISPs, enterprise networks, and large platforms makes failures harder to diagnose and leaves many reluctant to invest in full IPv6 support. The exchange underscores both the practical techniques for surviving in mixed v4/v6 environments and the broader frustration that, decades on, lack of incentives and perceived complexity still impede a clean transition away from IPv4.

Workarounds and simpler approaches

  • Many commenters say the problem can often be solved more simply than in the article, e.g.:
    • ssh -D <port> user@host as a quick SOCKS5 proxy, then point the browser at localhost:<port>.
    • Using a VPN provider, WARP in SOCKS mode, Tailscale/Headscale exit nodes, or SSH -R reverse tunnels.
  • These are seen as fast, practical fixes, especially on public Wi‑Fi or during temporary IPv4 outages.

What the article is really doing

  • Several note the setup is essentially “IPv4 over IPv6 via a VPS” (4-in-6 tunneling), not truly “Internet without IPv4”.
  • This is considered neat engineering, but overkill for short-term issues.

IPv4 vs IPv6 failure modes

  • ISPs report: breaking IPv4 usually gives a clear “down” state; breaking IPv6 causes weird partial failures and timeouts.
  • Some people now barely notice IPv4 failures because major sites (Google, Facebook, Apple, Cloudflare-hosted) work over IPv6.
  • Others highlight long-tail gaps: GitHub, Steam, many games, some CDNs, email infrastructure, POSIX bug tracker, and some VR/PC game ecosystems still require IPv4.

NAT64/DNS64, tunnels, and IPv6-only tricks

  • Multiple comments describe using public DNS64+NAT64 gateways (lists at nat64.net / nat64.xyz) to reach IPv4 from IPv6-only by just changing DNS.
  • Mobile networks commonly use IPv6-only cores with DNS64+NAT64 behind the scenes.
  • Hurricane Electric’s free 6in4 tunnels are recommended for users whose ISPs offer only IPv4.

Operational challenges with IPv6-only setups

  • Issues cited:
    • Some OSes need IPv6-capable DNS resolvers or won’t query AAAA records for VPN-only names.
    • Need to run DNS inside VPNs and cleanly restore DNS on disconnect.
    • Reliance on upstream DNS64; if it breaks, IPv4 reachability dies.
    • Datacenter/VPS IPs (used as gateways) often trigger CAPTCHAs, blocks, or streaming geo/anti‑VPN filters.

State of IPv6 adoption

  • Experiences vary widely:
    • Many home and mobile ISPs in developed regions now provide IPv6 by default; some new customers get CGNAT-only IPv4.
    • Others still lack any IPv6, or allegedly disable it to avoid customer confusion from broken AAAA records.
    • Some report HE-style tunnels increasingly being treated as “VPN/abuse” by services.

Debate over necessity and design

  • Some home and enterprise admins see no compelling reason to deploy IPv6: NAT works, address space is sufficient internally, and transition complexity feels high.
  • Others argue:
    • IPv6 simplifies routing and removes fragile stateful NAT boxes.
    • It makes 6→4 translation easier than 4→6.
    • Apple’s “must work on IPv6-only (with NAT64)” rule and government mandates are slowly forcing ecosystem readiness.
  • There is a meta‑debate over whether IPv6 is an “academic” overcomplication vs a cleaner redesign, and whether lack of incentives, training, and leadership—not technical merit—is the main blocker.