Addressing Happy Eyeballs limitations in Bedrock (connection issues) via the ITZG Docker container

[poeggi]

This is not a itzg docker-minecraft-bedrock-server issue per-se, but a proposal to use the project to work around an issue.

Currently, the Bedrock clients do not support the "Happy Eyeballs" approach (see RFC 8305) when a DNS entry resolves to both an A (IPv4) and an AAAA (IPv6) record. Happy Eyeballs is meant to improve the user experience in dual-stack environments.
It proposes initiating a connection attempt over IPv6 first, and then shortly after over IPv4 in parallel, without waiting for the IPv6 attempt to fail. The client continues with whichever connection succeeds first, minimizing delays caused by unreachable or misconfigured networks or servers.

In the Bedrock cliebt however, when you enter a DNS name for a server, it uses only the first address returned, using the requested port.
Unfortunately, the Bedrock server has another limitation, so that IPv4 and IPv6 cannot use the same port (arguably one of the more questionable design choices in Bedrock).

Combining these two limitations, when using a DNS name that resolves to both IPv4 and IPv6, and with a fixed port for connections (which can only be valid for either IPv4 or IPv6), you effectively have a 50:50 chance of success.

As a result, you can find various forum entries and some bug reports recommending "fixes" such as disabling IPv6 or using a direct IP address instead of a hostname to avoid intermittent "cannot connect" errors.

I would like to propose a potential workaround which could be implemented at the container level. I.e., inbound requests on port 19133 over IPv4 could be mapped to port 19132 on IPv4, and vice versa, using e.g. iptables (to also allow using host network mode).

Before preparing a test or proposing a patch, feedback on this approach would be helpful.

Admittedly, this is a workaround implemented at the container level. However, given the lack of progress on the underlying issues in Bedrock (client and server) over several years, and with increasing adoption of dual-stack networking, the ITZG Bedrock server Docker container could address a problem that many users may not even be aware of proactively.

[itzg]

I don't understand why you're reporting this issue against my image. Port mappings is a container time setting that is in your control. The image only declares default ports to expose.

[poeggi]

You're right that port mappings are the user's responsibility - so let me try to be clearer about actually what I am proposing.

The proposed idea is to add e.g. an opt-in port mapping inside the container (could be controlled e.g. via a setting like ENABLE_DUAL_STACK_WORKAROUND=true). We could potentially redirect UDP traffic hitting the "wrong" port (e.g. redirect IPv4 arriving on 19133 to 19132), make the solution part of this container.

This could live inside the image because the redirect should to happen at the network level inside the container, after Docker has delivered the packet. A host-side port mapping may be more intrusive.

The problem it potentially solves: If using server hostname in Bedrock clients, with servers whose DNS publish two addresses, the client only use the first IP address returned by DNS, and the Bedrock server cannot share a port between IPv4 and IPv6.

It would be a feature, helping users IRL, the container could absorb that failure by listening on a second port and redirecting internally, something server admins cannot easily implement themselves (if using pre-build containers).

Happy to dig into feasibility or put together a proof-of-concept if that is of interest.

I haven't been diving into this to much yet - so I am not sure it will actually work - but wanted to understand if it would be interesting at all before going down the rabbit hole.

[itzg]

You can use nsenter for that

https://share.google/aimode/MdNTFPK2yOR6drVT8

but I do appreciate how it would be easier to let the container handle that.

Submit a PR and we can go from there.

[poeggi]

Thanks for the pointer. Actually iptables based is what I tried first - but it seems in Host network mode (which I also want to support because it is what I am using it), this would require NET_ADMIN, which I would really like to avoid because of security but also convenience considerations (not enabled on vanilla by default).

So right now I am preparing an experiment in my fork [1] with a LD_PRELOAD shim, a completely different approach that could allow the BDS to actually use the same port for IPv4 and IPv6 (TBC!). Will open a PR as soon as Ii feel its ready.

Kindly advise if we should close of keep this issue open for documentation.

[1]
https://github.com/poeggi/docker-minecraft-bedrock-server

[itzg]

I would need the shim code itself to be maintained and built separate from the repo, as in not mine. Also double check that it will work on arm64 via the box64 emulation layer included with the image. Or better yet, provide a built binary for each architecture.

[poeggi]

Will do... then proceed with testing hopefully tomorrow.

[poeggi]

Initial shim tests looking good:

Connect test with real bedrock client looking good also.

So using the shim, putting both IPv6 and IPv4 on the same port is possible - which should fix at least the inevitable part of the lacking happy eyeballs implementation of the client. (Notably, it is not as good as a real client-side implementation as it does not fix actually bogus IPv6 setups).

[poeggi]

Workaround verified to be working. Singled out into a separate repo bds-ipv6fix.

Opened PR for inclusion.

Close this issue.