Category: Sixgate

Posted on

Sixgate: Technical Overview of the IPv4-to-IPv6 Gateway Mechanism

Last time…

We introduced Sixgate as a simple way for IPv4-only clients to automatically reach IPv6-only servers. The idea is to let server operators drop IPv4 entirely — except for a single gateway — while still remaining accessible to legacy clients. It’s a bridge, not a wall.

This post explains how Sixgate works in practice: how clients discover the gateway, how packets are encapsulated, and how responses are routed — all without requiring session state.

This page as published is version 0.1. If I make a substantive edit I will update the version.

🔧 Core Components

Sixgate relies on four key elements:

  1. SRV Records in Reverse DNS Zones
  2. UDP-Based IPv6 Packet Encapsulation
  3. Gateway Forwarding with Embedded IPv4 Identity
  4. Stateless Response Routing

1. Gateway Discovery via SRV Records

When a client receives an IPv6 address from DNS but cannot connect due to lack of IPv6 support, it performs a fallback SRV query to discover a gateway.

SRV Query Format

The query uses the reverse-nibble format of the IPv6 address, similar to ip6.arpa, but requests a service record:

_sixgate._udp.<addr>.ip6.arpa

For example, for IPv6 address 2001:db8::1, the query becomes:

_sixgate._udp.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

The SRV record returns:

  • Target: IPv4-accessible hostname of the gateway (for example, gw.example.com)
  • Port: The UDP port listening for Sixgate packets on that IPv4 host.

The client then performs an A record lookup to resolve the IPv4 address of the gateway.

2. UDP Encapsulation of IPv6 Packets

The client constructs a standard IPv6 packet as if it had native connectivity. It then wraps this packet in a UDP payload and sends it to the gateway’s IPv4 address and designated port.

  • Outer Layer: IPv4 + UDP
  • Payload: Raw IPv6 packet (including headers and data)

This is similar to Teredo’s encapsulation model but reversed in direction and purpose.

3. Gateway Forwarding with Embedded IPv4 Identity

Upon receiving the UDP packet, the gateway:

  • Extracts the IPv6 packet from the payload.
  • Rewrites the source IPv6 address to one of its own — embedding the client’s IPv4 address and UDP port into the lower 48 bits.
  • Forwards the packet to the target IPv6-only server.

This rewriting is necessary because the original client has no routable IPv6 address. By embedding the client’s identity into the source address, the gateway enables stateless response routing and preserves visibility for server-side analysis.

Encoding Format

Assuming the gateway controls a /48 prefix (e.g., 2001:db8:abcd::/48), it constructs:

2001:db8:abcd:xxxx:yyyy:zzzz

Where:

  • xxxx:yyyy encodes the client’s IPv4 address (e.g., 192.0.2.1 → c000:0201)
  • zzzz encodes the client’s UDP port (e.g., decimal 2820 → 0b04 in hex)

This allows the server to:

  • See a unique IPv6 source address per client
  • Optionally extract the embedded IPv4 identity for logging, rate limiting, or application-layer logic

And it allows the gateway to:

  • Reconstruct the client’s IPv4 address and port from the destination address of the server’s response
  • Encapsulate the response in UDP and send it back — without maintaining a session table

This stateless design is the default behavior for Sixgate. It simplifies implementation, improves scalability, and ensures that the server can still perform meaningful analysis of client identity.

🧱 Deployment Realities

  • IPv4 Address Requirement: Each IPv6-only cluster must maintain a single IPv4 address for the gateway. This is far lighter than full dual-stack hosting.
  • DNS Availability: DNS must remain reachable over IPv4 to resolve both the original AAAA record and the SRV fallback.
  • Firewall Traversal: Clients must be able to send outbound UDP packets to arbitrary destinations and receive UDP responses from the gateway.

🧪 Prototype and Standardization

Sixgate can be prototyped as:

  • A browser extension or OS-level library
  • A reference gateway daemon
  • An experimental IETF draft defining SRV usage and encapsulation format

🌉 Summary

Sixgate offers a practical, decentralized way to let IPv6 stand alone — without leaving anyone behind. By shifting compatibility to the edge and leveraging DNS for discovery, it enables graceful IPv6-only deployments while preserving access for legacy clients.

If you’re interested in implementing or extending Sixgate, I’d love to collaborate. Let’s build the bridge — and let IPv6 finally stand on its own.

Coming soon: A follow-up post will explore Sixgate’s security considerations — including abuse prevention, spoofing risks, and how gateway operators can balance openness with protection. If Sixgate is to be deployed in the wild, it must be safe as well as simple.

Credits
🦉 Written and published by me, Bill P. Godfrey.
✍️ Editorial assistance from Echoquill, my robotic assistant.

Posted on

Sixgate – IPv6 Without Leaving Anyone Behind

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:

  1. 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.
  2. 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.
  3. The SRV record returns an IPv4-accessible gateway, operated by the website’s network.
  4. The client wraps its IPv6 packet in a UDP envelope and sends it to the gateway.
  5. The gateway unwraps the packet, rewrites the source address to its own IPv6 identity and forwards it to the server.
  6. 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.

“Ulysses, Ulysses, soaring through all the galaxies. In search of Earth, flying into the night.”

🚀 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.