The internet is slowly, stubbornly moving toward IPv6. Server operators are increasingly comfortable deploying services on IPv6-only infrastructure, but there’s a catch. Many clients still live in IPv4-only environments, especially those served by legacy ISPs or locked into older hardware. This creates a frustrating asymmetry. Any website going IPv6-only will risk cutting off a portion of their audience.
We’ve been here before. Windows XP did not support SNI and website operators had to dedicate a full IPv4 address to each secure domain. Until XP faded out, many sites avoided HTTPS entirely. IPv6 faces a similar hesitation. Operators won’t go IPv6-only while legacy clients remain stranded.
IPv6 was meant to free us from the confines of IPv4, yet ISPs happy to maintain the status quo are holding everyone back.
Sixgate is a proposal to change that.
Before we dig deeper, I am painfully aware that the idea seems a little obvious. I can’t help the feeling that this must have been thought of already but there’s some problem which is why I can’t find any discussion of it. Maybe I am the first to think of this. I humbly await comments telling me exactly how wrong I am.
🌉 What Is Sixgate?
Sixgate is a lightweight mechanism that allows IPv4-only clients to reach IPv6-only servers without requiring IPv4 infrastructure. It works by letting clients automatically discover and use a gateway operated by the server network to tunnel IPv6 packets over IPv4.
Here’s how Sixgate bridges the gap:
- The client attempts to connect to a website and receives only an IPv6 address from DNS. The client knows that it cannot connect, either due to a missing IPv6 configuration or a previously failed attempt.
- The client performs a second DNS query, asking for a special SRV record associated with the IPv6 address, published in the same zone as reverse DNS for that IP address.
- The SRV record returns an IPv4-accessible gateway, operated by the website’s network.
- The client wraps its IPv6 packet in a UDP envelope and sends it to the gateway.
- The gateway unwraps the packet, rewrites the source address to its own IPv6 identity and forwards it to the server.
- Responses follow the same path in reverse, allowing the IPv4-only client to communicate seamlessly with the IPv6-only service.
🛠 Practical Realities
Even an IPv6-only cluster will need a single IPv4 address to operate the gateway. That’s a small concession. Far less costly than maintaining IPv4 across all services. The gateway becomes a focused point of compatibility, not a sprawling legacy burden. The gateway itself need not be part of the server farm it supports, but should be close to the same network path that normal IPv6 traffic takes.
Additionally, DNS itself must remain reachable over IPv4, at least for the foreseeable future. Clients need to resolve both the original IPv6 address and the SRV record for the gateway. Fortunately, DNS infrastructure is already deeply entrenched in IPv4, and this proposal doesn’t require any changes to that foundation.
🚀 Why Sixgate Matters
The beauty of Sixgate is that it shifts the burden away from ISPs and toward software. Updating an operating system or browser to support this fall-back logic is vastly easier than convincing hundreds of ISPs to overhaul their networks. Software updates can be rolled out in weeks. ISP transitions take years — sometimes decades.
By giving server operators a graceful way to drop IPv4, we accelerate the transition without leaving legacy clients behind. It’s a bridge, not a wall.
🔭 What Comes Next?
This is a sketch — but it’s one that could be prototyped quickly. A browser extension, a client library, or even a reference implementation could demonstrate its viability. From there, it could be standardized, adopted, and quietly become part of the internet’s connective tissue.
If you’re a server operator dreaming of an IPv6-only future, this might be your missing piece. And if you’re a protocol designer or systems thinker, I’d love to hear your thoughts.
Let’s build the bridge — and let IPv6 finally stand on its own.
For those curious about how Sixgate works under the hood — from SRV record discovery to stateless response routing — the technical overview is now live: read the full breakdown here.
Credits:
📸 “Snow Scot” by Peeja. (With permission.)
🤖 Microsoft Copilot for rubber-ducking and help refining my text.