IPv6 enet support

[fcxSanya]

IPv6 adoption is rising, some ISPs already provide IPv6 addresses only, so we eventually will have to support it in the network layer.

pyrogenesis uses ​ENet which currently isn't IPv6 compatible, the best place to track ENet IPv6 status is probably this pull request: ​https://github.com/lsalzman/enet/pull/21.

[fcxSanya]

IPv6 support topic was raised on IRC a number of times, so I decided it would be useful to gather all the information in a ticket, so it would be possible to easily find the current status and track possible updates

[echotangoecho]

Also take note of this issue from another project wanting to get ipv6 support using enet: ​https://github.com/godotengine/godot/issues/6992. We should try to fix this before next release as this is important to have (not having it denies an increasing number of people the ability to play multiplayer).

[elexis]

I didn't come across a single bug report yet about missing ipv6.

Currently we support enet 1.3 or older, (see wiki:BuildInstructions) and even the most recent enet version doesn't include ipv6. The latest commit in ​https://github.com/lsalzman/enet was in june, while the link you provided shows pull requests from october. So it seems out of reach for now.

Also this didn't discuss lobby / XMPP support yet, which would be mandatory for allowing seamless IPv6 support.

[elexis]

I didn't come across a single bug report yet about missing ipv6.

Recent ejabberd uses IPv6 by default and needs to be configured to only listen on IPv4. (Otherwise hosting will work with STUN enabled but not without it.)

There are different pull requests for enet ipv6 support and we must consider patching enet locally if not getting it merged upstream.

[Stan]

Might be interesting to use Godot sockets for IPV6 support https://github.com/godotengine/godot/pull/7985

[elexis]

Lefo has mentioned on the lobby that he has successfully compiled 0ad with an ipv6 patched enet. The difficulty will be to deploy it on the lobby in conjunction with ejabberd ipv4 or ipv6 addresses and not having some clients who only speak ipv4 or clients who only speak ipv6 be locked out from some of the games (or even the entire lobby).

[Lefo]

Patch uploaded here: ​https://code.wildfiregames.com/D1676

[elexis]

refs #5498 for macOS gloox IPv6 support

[Stan]

I couldn't get any consensus so I'm pushing it to A25.

It seems Godot worked around the issue by using their own sockets (See the PR by fcx sanya) Maybe that would be more acceptable.

[wraitii]

Did a deeper dive on this following ​Phab:D3944. What I think:

• We ought to remove un-necessary dependency on Enet for address-to-human code and STUN in general. This seems easy enough since *nix and Win32 share mostly compatible APIs, and in the future we can hope C++ will standardise something.
  • The opposite was done in ​Phab:D1676, but it can be used for reference.
• Then we ought to look into using a fork of Enet that supports IPV6, unless by that point it looks like Enet itself got updated.

In terms of 'status update', there is one new PR that got more enthusiastic comments : ​https://github.com/lsalzman/enet/pull/109 . On a superficial level, this seems quite simple, which is good. Indeed, as noted by the Godot guys at ​https://github.com/godotengine/godot/pull/7985/, the only struct that's really problematic is ENetAddress. If that is changed, everything else mostly falls into place (with some changes in the platform-specific code, of course). Godot's PR provides an example of how to provide a custom socket implementation, which I don't think is really what we want to do.

In terms of fork, I am wary of ZPL-C's fork used as the basis for D1676 - they did a rather larger number of changes, and I'm not sure about the philosophy of the maintainers. A much lighter fork is maintained at ​https://github.com/mman/enet, but we would obviously need to check a few things. Still, the risk of using such a "light" for shouldn't be too high, because it doesn't affect enet-specific code, only the sockets, which are platform-specific and likely to fail in non-subtle ways.

I haven't really found another stable, up-to-date fork.

[wraitii]

So I did another deep dive, pulling out D3952. In fact, the AF_INET6 socket & sockets in general using IPV6 are fully compatible with IPV4, so that's great, it's _actually_ protocol-independent.

The only problem is that Enet doesn't use AF_INET6 sockets, so things won't work. But that single change is necessary, the rest of the code should be completely agnostic.

[Stan]

In r25453:

StunClient code cleanup: use enet functions, endianness

Instead of using platform-specific sockets, use enet_socket* functions (which ends up doing the same). Clean up some confusing APIs, removing the distinction between finding the public IP for the host/join.

Fix endianness support & use simpler code.

Refs ​Phab:D364 / ​Phab:rP19703 (and some subsequent fixing diffs).

Differential Revision: ​https://code.wildfiregames.com/D3970

[Stan]

​Phab:D3952 was abandonned, Enet still doesn't support IPV6

[Stan]

Unlikely to get done for A26

[Freagarach]

Pushing back.

[Dunedan]

Replying to elexis:

Also this didn't discuss lobby / XMPP support yet, which would be mandatory for allowing seamless IPv6 support.

Running ejabberd dual-stack listing on IPv4 and IPv6 is no big deal, so we can easily support connections to the lobby for all players, no matter if they use IPv4 or IPv6.

The big question I see is how we can support players with IPv4-only internet connections playing together with players with IPv6-only internet connections, as they need to be able to exchange UDP-packets directly. That'd require at least the player hosting the game to have a dual-stack internet connection, unless we host the games on our own dual-stack enabled infrastructure. Another option would be to mark games explicitly as IPv4 and/or IPv6 depending on what the host supports, however that would split the player base into two, which IMO isn't a good idea.

In any case I believe there is some hidden complexity beyond just IPv6 support for enet.