IPv6 and game servers: where it helps and where it bites

Run both stacks or run IPv4. A server reachable only over IPv6 is unreachable for a large share of players who will never work out why, and a server with an AAAA record and nothing listening behind it is worse than one with no AAAA record at all, because it converts "cannot connect" into "connects sometimes, for some people, from some networks".

That is the whole recommendation. Everything below is the detail: what IPv6 actually changes, which parts of the games industry have caught up, the three configuration mistakes that produce intermittent failures, and the handful of situations where IPv6 is not optional at all.

What IPv6 changes, and what it does not#

IPv6 is the same internet with a bigger address field. Routing, TCP, UDP, DNS and every game protocol on top work identically. What changes is worth knowing precisely, because half the folklore around it is wrong.

• Addresses are 128 bits instead of 32. The shortage is over. A single home connection is typically delegated a /56 or /48, which is more addresses than the entire IPv4 internet.
• There is normally no NAT. Every device gets a globally routable address, which means the firewall is the only thing between it and the internet. On IPv4 a home router's NAT was accidentally doing that job. On IPv6 nothing is doing it accidentally.
• ARP is gone, replaced by Neighbour Discovery, which runs over ICMPv6. This is why blocking ICMPv6 breaks things that blocking ICMP on IPv4 never did.
• Routers do not fragment. On IPv4 an intermediate router could chop an oversized packet up. On IPv6 it sends back a Packet Too Big message and the sender is expected to act on it. If that message is filtered, large packets vanish and small ones do not.
• The minimum MTU is 1280 bytes, against 576 on IPv4.

What does not change: latency, throughput, jitter or the distance to your players. IPv6 packets travel the same fibre at the same speed. If anybody tells you IPv6 is faster, they are describing a path that happened to be better peered, not a property of the protocol. The three numbers that actually decide how a game feels are in latency, jitter and packet loss.

Reading and typing an IPv6 address#

Eight groups of four hex digits, separated by colons, with two shorthands: leading zeros in a group can be dropped, and one run of all-zero groups can be replaced by ::, once per address.

2001:0db8:0000:0000:0000:0000:0000:0010   full form2001:db8::10                              the same address, written sanely

The prefixes you will actually meet:

The syntax detail that breaks configuration files: when an address appears next to a port, it goes in square brackets. [2001:db8::10]:25565 is the server, 2001:db8::10:25565 is a different address entirely and probably a typo you will stare at for ten minutes. The same bracket rule applies in URLs, in most bind directives and in connection strings.

One more: a /64 is the standard size of a single network segment. Everything a customer connects from usually lives inside one /64, and that single fact drives the whole of the bans and logging section below.

Which side actually supports it#

Support is not one question, it is four: does the server binary listen on IPv6, does the client dial it, does the master server list or matchmaking accept it, and does your tooling understand it. All four have to be yes, and the failures are silent.

The Minecraft Java case has one specific trap worth naming. A socket bound to :: will accept IPv4 connections as well on Linux, because the net.ipv6.bindv6only sysctl defaults to 0 and IPv4 clients arrive as IPv4-mapped addresses. But a JVM started with -Djava.net.preferIPv4Stack=true will not create IPv6 sockets at all, so the server is IPv4-only no matter what the rest of the machine is doing. That flag appears in a lot of copied-and-pasted start scripts. If you are running with a flag list you did not write, check it before you conclude the game does not support IPv6.

Dual-stack properly: bind, record, firewall#

Three things must be true at once, and people usually do one or two.

1. The service listens on IPv6. Check with ss, not with hope. An address of 0.0.0.0:25565 is IPv4 only. [::]:25565 is both, on a default Linux kernel.
2. DNS publishes it. An AAAA record for the same name that carries the A record. DNS records explained covers the record types, and subdomains for servers covers keeping the address in one place so that adding a second record is not adding a second thing to forget.
3. The firewall allows it. IPv6 rules are a separate rule set in iptables and ip6tables, and the classic outcome is a service that works perfectly over IPv4 and is silently dropped over IPv6.

$ ss -ltnp | grep 25565LISTEN 0 128 *:25565 *:*$ dig +short AAAA play.example.com @1.1.1.12001:db8::10$ ip6tables -L INPUT -n --line-numbers

On ufw, IPv6 handling is controlled by one line in /etc/default/ufw, and a rule you add applies to both stacks only when it is on:

IPV6=yes

If you use nftables instead, the inet family covers both protocols in one rule set, which removes this entire category of mistake. The firewall rules that actually matter has the full rule set in both syntaxes, and the ufw guide is the longer walk through the tool.

Containers are the other common gap. Docker has historically shipped with IPv6 off, so a container with a published port answers on IPv4 and not on IPv6 even when the host is fully dual-stacked. Turning it on means "ipv6": true and a fixed-cidr-v6 in /etc/docker/daemon.json, plus a restart of the daemon - see Docker on a VDS for the surrounding setup.

ICMPv6 and MTU: the failure that looks like packet loss#

This is the one that wastes days. On IPv4 you can block all ICMP, annoy your network engineers and mostly get away with it. On IPv6 you cannot, because the protocol depends on it.

Neighbour Discovery, which finds the link-layer address of the next hop, is ICMPv6. Router Advertisements, which is how most hosts get an address at all, are ICMPv6. And Packet Too Big, type 2, is how a sender learns to reduce its packet size, because no IPv6 router will fragment on its behalf.

Block ICMPv6 type 2 anywhere on the path and you get a very specific symptom: small packets work, handshakes complete, the connection establishes, and then anything that needs a full-size packet disappears. A game will connect and then freeze on the first large state update. A web page will return headers and hang on the body. It looks exactly like packet loss and it is not - see the section on separating loss from other problems in latency, jitter and packet loss, because the diagnosis is the same and the cure is not.

The rule to keep is simple: allow ICMPv6 inbound, rate-limited if you like, and never blanket-drop it. Tunnelled IPv6 connections, which some home ISPs still hand out, reduce the usable MTU below 1500 and make this failure far more likely for exactly the players least able to diagnose it.

Bans, allow-lists and logs: the /64 rule#

An IPv4 ban lands on one address and usually one household. An IPv6 ban on a single /128 lands on one address that the client may well rotate within the hour, because privacy extensions give hosts temporary addresses inside their own prefix by design.

The practical rule: the unit of identity on IPv6 is the /64, not the address.

• Ban the `/64`. 2001:db8:1234:5678::/64 is what a single customer connection looks like. Banning 2001:db8:1234:5678::a1b2 bans one interface identifier until it rotates.
• Allow-list the `/64` too, or the admin you allowed in this morning will be a stranger this afternoon.
• Log the prefix. Storing full addresses and grouping by them produces useless statistics; group by the first 64 bits.
• Check your tools take a prefix at all. A surprising number of ban systems written for IPv4 accept only a bare address, which means IPv6 bans do not work and nobody notices for months.
• Do not go coarser than `/64` casually. A /48 can be a whole ISP region, and a /32 is often an entire ISP.

The same applies to rate limits, which are the actual defence against application-level abuse - counting per address is meaningless when an attacker has 18 quintillion of them in one subnet. Rate limits and abuse covers the shape of limits that work, and what we do about attacks is honest about which parts of the problem filtering does and does not solve.

Testing it, and what "works" means#

Testing from a dual-stack machine proves almost nothing, because it will quietly fall back to IPv4 the moment IPv6 fails. Most clients try both and prefer IPv6 with a short head start, so a broken IPv6 path shows up as a fraction of a second of delay rather than an error. That is excellent for users and terrible for testing.

Force the protocol:

$ ping6 play.example.com$ curl -6 -sI https://api.example.com$ mtr -6 play.example.com$ dig AAAA play.example.com @2606:4700:4700::1111

For a game, the only real test is a client on an IPv6-capable network with IPv4 disabled, or a mobile connection on a carrier that runs IPv6-only with NAT64. If that client connects and stays connected through a map change and a large state sync, the path works. If it connects and freezes, go back and read the ICMPv6 section.

There is one more test that catches a very common failure: certificates. If a name has an AAAA record, the certificate authority's validator may try the IPv6 address, and a record pointing at an address with nothing listening is a classic cause of issuance failing for a name that looks perfectly configured over IPv4. If a certificate will not issue and the A record is right, check the AAAA record next - pointing a domain at your server covers the rest of the issuance path.

Where IPv6 genuinely earns its place#

Most of this post is warnings, so here is the other side. There are three situations where IPv6 is the better answer and one where it is the only one.

Hosting from home behind CGNAT. If your ISP puts you behind carrier-grade NAT, you have no public IPv4 address to forward a port to, and no amount of router configuration will create one. Many of those same connections hand out a real, routable IPv6 prefix. An IPv6-only home server is not viable for a general audience, but it is a genuine option for a private group who all have IPv6. Self-hosting at home versus renting weighs that against the other costs of running a server on your own line.

Being allow-listed by somebody else. If an API, a payment provider or a corporate firewall needs to allow your server, IPv6 gives you a stable prefix without the scarcity pricing attached to IPv4 addresses. Static addresses, and whether you need one is the wider question of when a dedicated address is worth paying for.

Anything that is plain HTTP or a database connection. Web, API and database traffic over IPv6 is unremarkable and has been for years. If your app talks to a service that publishes AAAA records, it is probably already using IPv6 and you have never noticed. That is the goal state.

Reaching players on IPv6-only mobile networks. Some carriers run IPv6-only with NAT64 translation at the edge. Those players reach IPv4 servers through the translator, which works for TCP and for most UDP, and adds a hop plus a translation state table that occasionally drops idle sessions. Publishing an AAAA record removes the translator from the path for those players specifically.

On RE:NODE, every server is published with an IPv4 address and a port, and that is what goes in your DNS records. IPv6 is not something we advertise as standard, so if your project genuinely depends on it, ask before you design around it rather than after. Support is a ticket from the panel or Discord, and the answer will be a straight yes or no rather than a maybe.

FAQ#

Should I publish an AAAA record for my game server?

Only if you have connected to the server over IPv6 yourself, with IPv4 disabled on the client. An AAAA record with nothing listening behind it causes intermittent failures for exactly the players whose networks prefer IPv6, and those failures are very hard to report usefully.

Can I run a game server on IPv6 only?

Technically for some games, practically for none with a public audience. A meaningful share of players have no IPv6 at all, their routers have it switched off, or their game client will not use it. Dual-stack or IPv4-only are the two real choices.

Does IPv6 make my server faster?

No. It is the same path at the same speed. The only measurable difference is at connection time, and only for clients that would otherwise have been translated through a carrier NAT64 gateway.

How do I ban an IPv6 player properly?

Ban the /64, not the single address. Clients rotate the last 64 bits of their address by design, so a /128 ban expires on its own. Check first that your ban tooling accepts a prefix at all, because plenty written for IPv4 does not.

Why does my server work over IPv4 but not IPv6?

Three usual causes, in order: the process is bound to 0.0.0.0 rather than ::, the IPv6 firewall rule set does not have the rule you added for IPv4, or the container runtime has IPv6 disabled. ss -ltnp answers the first in one line.