This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• IPv6 support for SDL_net (SDL_net-r2633-ipv6.patch, text/plain, 2006-07-18 18:20:39 +0000, 38236 bytes)
• Updated ipv6 patch (sdl-net-1.2.7-ipv6.patch, text/plain, 2011-07-02 12:33:09 +0000, 37729 bytes)
• New version of ipv6 patch (sdl-net-1.2.7-ipv6-new.patch, text/plain, 2011-07-09 02:53:46 +0000, 37622 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-07-18 18:19:26 +0000, Alexandre Hamelin wrote:

I've adapted Simon Howard's IPv6 patch to be used on the latest code base of SDL_net, namely r2633 as of now. Please feel free to review the changes. His original patch is located on http://www.soulsphere.org/projects/ipv6/.

Be aware that, as describe on his page, the API changes a bit so some functions are rendered incompatible with the previous version of SDL_net.

Preliminary tests with a patched PrBoom for IPv6 are positive in that the server and the client can communicate. (I sent that patch to the PrBoom devel mailing list already.)

On 2006-07-18 18:20:39 +0000, Alexandre Hamelin wrote:

Created attachment 149
IPv6 support for SDL_net

On 2011-07-02 12:33:09 +0000, Pinkbyte wrote:

Created attachment 643
Updated ipv6 patch

This is updated version of ipv6 patch for sdl-net 1.2.7

On 2011-07-09 02:53:46 +0000, Pinkbyte wrote:

Created attachment 645
New version of ipv6 patch

This version does not broke backward compatibility with ipv6 tcp clients. Other thing are the same as in previous versions

On 2012-01-02 22:10:58 +0000, Sam Lantinga wrote:

I'll include this in the next major revision which can break API compatibility.
Thanks!

On 2013-10-03 08:21:10 +0000, Sam Lantinga wrote:

Comments from Robert Anderson:
My first glance at the source-code gave me these thoughts:

1. Cosmetic: Do not use code like
   fprintf(stderr,
   "Cant resolve %s:%i\n",
   hostname, port);
   Which would return output like 2001:2::1:2500 which is an illegal IPv6 address (which I can gruntingly understand)
   but 2001:2::1:22 is ambiguous and I can't get if 22 is a port or part of the address.
   Please use the style [2001:2::1]:22 which is not mentioned (or forbidden) in the RFC, but used in URI's
   https://en.wikipedia.org/wiki/IPv6_address#Literal_IPv6_addresses_in_network_resource_identifiers

---

2. Stability: +int SDLNet_ResolveHost_new(SDLNet_AddrType type, IPaddress *address,

•                  const char *host, Uint16 port)
  

Since you can DNS resolve IPv6 addresses over IPv4; getting a DNS answer does not necessarily mean that you have IPv6-connectivity
(Sadly, most PC today have an IPv6-address and can resolve AAAA-records, but does not have IPv6-internet-connectivity
[the developers of Minecraft still does not get this (:-( ] )

Both my windows PC and my Lubuntu laptop has an icon showing if you have (IPv6?) connectivity. This should be checked
before choosing to return the IPv4 or IPv6 address. (I think machine local check is better then doing an internet IPv6 connectivity test)

Thirdly you have the odd setup of a local LAN game, including a local DNS-server; all running native IPv6 (no IPv4) with no
internet IPv6-internet-connectivity. Then my suggestion would not work. (dual-stack would work, but it would always return the
fallback IPv4 address - even if IPv6 is preferred)
Local LAN games would work if IPv6 numerical addresses are use, no DNS lookups there (:-)

Summary: Don't return an IPv6 address if you don't have access to the IPv6-internet

On 2015-07-22 19:24:35 +0000, Philipp Wiesemann wrote:

Bug 2959 also has a patch for IPv6.