IPv6 for game servers: mostly irrelevant, occasionally essential

IPv6 has been the future of networking for longer than most game servers have existed. For game hosting specifically it remains close to irrelevant, and understanding why is more useful than another explanation of address exhaustion.

The state of it

Roughly forty percent of traffic to major services now arrives over IPv6. Home connections in many countries default to it. Mobile networks are heavily IPv6, often IPv6-only with translation for legacy destinations.

And almost no game server runs on it.

The reason is not that the protocol is unsuitable. It is that game networking is a stack of client code, server binaries, query protocols and third-party tooling, all of which have to support it before any of it is usable — and the weakest link in that chain is usually a query protocol written in 2004.

Where it breaks

Query protocols assume 32-bit addresses. Several encode the address as four bytes because that was the only kind of address there was. A protocol that cannot express your address cannot list your server, and rewriting it breaks every client that speaks the old version.

Server browsers are often IPv4-only. Even where the game supports v6 connections, the in-game list may not, which produces a server that works for anyone with the address and appears nowhere.

Directories are IPv4-shaped. Most listing infrastructure, this site included, stores and queries addresses in a form inherited from the same era. A v6-only server is a server most directories cannot check on.

Server binaries vary. Some bind to v6 happily, some bind but do not advertise correctly, some do not bind at all. It is per-game and rarely documented, which means finding out costs an afternoon.

Where it genuinely helps

Two situations, both real.

Carrier-grade NAT. An increasing number of connections have no public IPv4 address at all — the ISP shares one among many customers. Port forwarding is impossible on such a connection, which makes home hosting a non-starter unless the ISP will provide a public address.

Those same connections almost always have a public IPv6 address, with no NAT. So for a home server behind CGNAT, IPv6 is not an optimisation; it is the only way to be reachable at all. The catch is that your players need IPv6 too, and enough of them will not have it that a v6-only server excludes a real share of your audience.

Cost. IPv4 addresses are a purchased scarce resource, and hosts increasingly bill for additional ones. If you want several servers on separate addresses, v6 addresses are effectively free while v4 ones are a line item.

Dual stack is the only sane answer

Not "move to IPv6". Run both.

A dual-stacked server binds to a v4 and a v6 address simultaneously. Players with either can connect, directories query the v4 address as they always have, and nothing about the existing ecosystem breaks. Clients on CGNAT reach you over v6; everyone else carries on as before.

The practical caveat is that you must advertise the v4 address. The address in a listing, a Discord pin or a hostname is what people copy, and it needs to work for the maximum number of them. Publish the v4 address; let v6 be the thing that quietly works for the people who need it.

What to check if you want it

Does the game support it? Not the marketing page — the actual server binary. Test by binding and connecting.

Does your host route it? Many provide a v6 allocation and do not route it by default, or route it only after a support ticket.

Does the firewall handle it separately? This is the most common self-inflicted problem. iptables and ip6tables are different rule sets, and a firewall carefully configured for v4 is frequently wide open on v6 because nobody wrote the second set of rules. That is a security problem rather than a connectivity one, and it is created by enabling IPv6 without finishing the job.

Is the query port open on both? Same trap as the game port and query port, doubled. A server reachable on v6 whose query port is only open on v4 is the invisible-server failure again.

None of it changes the hardware question either — single-thread performance still decides the tick, and an address family has no opinion about that.

What this means for players

Almost nothing, today. Every major game server you will connect to is reachable over IPv4, and your connection has one whether or not you know it.

The exception is if you are on a mobile or IPv6-only connection and cannot reach a server everyone else can. That is rare on desktop and it is not something you can fix from your side beyond using a VPN or asking your ISP for a public v4 address.

The honest forecast

Game hosting will move last, because the cost of moving is high and the benefit is close to zero for the operator. The protocols that would need updating are stable, widely deployed and maintained by nobody in several cases, and the ecosystem of tooling around them assumes v4 at every layer.

What will change it is not enthusiasm. It is IPv4 addresses becoming expensive enough that hosts stop including one by default — and at that point the query protocols become the blocking problem, and something will have to give.

Until then: dual stack if it is free and easy, ignore it otherwise, and be aware that it is the answer if you are stuck behind carrier-grade NAT with no other route to being reachable. The rest of the hosting decision is covered in what you are actually paying for.

The short version

Widely deployed everywhere except game servers, because the query protocols and directories are older than it is. Dual stack costs nothing and helps the minority who need it; v6-only makes you unlistable and unreachable for most players.

The one case where it genuinely matters is carrier-grade NAT, where it is the difference between a home server that can be reached and one that cannot.