I am grateful to “Lenny S” for making a comment on part two of this series, as it has revealed that I really need to make it clearer exactly what the point of Sixgate is. IPv6-over-IPv4 tunnels have existed for decades but I’m trying to solve a different problem.
(If you’ve no idea what any this is about, maybe start at part one you dingus.)
- Part 1 – Introduction
- Part 1½ – Why not tunnel services?
- Part 2 – The Technical Details
The Server’s Problem
Technologies like CGNAT have made IPv4 “good enough” for ISPs. Moving to IPv6 would require a whole bunch of new equipment and no-one other than a few nerds are actually asking for it. This has been the status quo for decades and we realistically expect large chunks of the Internet to not be able to receive incoming connections.
As a server operator, I might want to deploy new services on IPv6‑only infrastructure. There’s no good equivalent of CGNAT on the server side and IPv4 addresses are scarce, expensive and require careful planning. I want to stop burning through them just to keep compatibility alive, but I can’t do that while many of my customers are still behind IPv4‑only ISPs.
From the user’s perspective, their internet connection “just works”. They don’t know what IPv4 or IPv6 is and they shouldn’t have to. If they try to connect to my service and it fails, they won’t start thinking they should sign up for a tunnel, they’ll think, quite reasonably, that my website is broken.
Tunnels put the burden on the least‑equipped party: the end‑user.
- They require sign‑ups, configuration, and sometimes payment.
- They assume technical knowledge that most customers simply don’t have.
- They create friction at exactly the wrong place: the moment a customer is deciding whether my service is trustworthy.
Telling a potential customer to “go fix your internet” is not a viable business model.
The Sixgate Approach
This is where Sixgate changes the equation. Instead of asking customers to fix their connectivity, make the gateway discoverable through DNS.
- The SRV record tells the client where the gateway is.
- The client software (browser, OS, or library) can then use the gateway invisibly.
From the customer’s perspective, nothing changes. They click a link and it works. The SRV lookup adds a moment’s pause, but that’s the price of invisibility. No sign‑ups, no extra services, no confusion.
The SRV record is the keystone of Sixgate’s design. Without it, the bridge collapses into a pile of disconnected ideas. With that SRV record retrieved, the client doesn’t need to sign up for an account or perform a pre-connection ceremony. The remote network has provided the gateway and they want you to be able to connect to them with as little fuss as possible. Everything else rests on that stone. Place it firmly, and the whole arch of compatibility stands.
The Tipping Point
Over time, as more clients can connect to IPv6 servers either natively or through Sixgate, we reach a tipping point. Enough of the world can reach IPv6 that new data centres can seriously consider not deploying IPv4 at all.
That’s the goal. As long as server networks still need IPv4, we’re still going to have the problems of IPv4. If we can work around the ISPs who won’t update their equipment then IPv6 might finally stand on its own.
In Part Two, we’ll explore how Sixgate works under the hood. The SRV lookup, the encapsulation, the stateless routing, and the embedded IPv4 identity that makes it all possible.
Credits
📸 “DSC08463 – El Galeón” by Dennis Jarvis. (Creative Commons)
🤖 With thanks to Echoquill, my robotic assistant, for helping shape this interlude — from the keystone to the tipping point and liberal use of em-dashes.