In the next couple of years at most, the IPV4 address space is going to be running out. The networking powers that be have developed IPV6 as a solution to that and ISPs have slowly started incorporating it in their hardware.

I know that IVP6's implementation is preliminary right now in the networking world in general. However, since the internet is going to be running IPV4 and V6 in the foreseeable future, I believe it would make sense to start implementing IPV6 now to avoid obvious future connectivity problems.

Still doesn't change the fact that it's still hard to find a fixed line ipv6 connection. I was surprised to find out that my uncle has ipv6 since the Internet service there is otherwise pretty lackluster.

I believe IPv6 has advanced to the point of necessitating a reexamination of this issue in greater depth. IPv6 in certain regions has gone from being a new commodity to a potential necessity for server hosting applications on both PC and home consoles.

Many years ago, I was able to run a home Zandronum server just fine on my PC (I had to go through the port forwarding routine, but whatever). I switched location and ISP. I'm currently on mobile Wi-Fi internet, which as I'm reading up on is very unfriendly towards server hosting.
I used the same identical port forwarding and Zand settings, etc. Servers just don't show up.https://zandronum.com/forum/viewtopic.php?t=5191#p70743 [^] The sv_showlauncherqueries test also shows no pings or traffic.

The default response to these topic is inevitably "forward you ports". The latter topic is particularly notable for this answer bandwagon-ing. This answer works most of the time... but in some situations isn't enough.

https://www.reddit.com/r/verizon/comments/62iz3b/verizon_jetpack_with_ps4_nat_issue/ [^] A more general and thorough scope of the NAT issue. Basically, that IPv4 addresses, particularly with 4G services like the VZW Jetpack and ATT mobile hotspots, are NATed several times over (at least through three different routers according to one source), while IPv6 compatible devices get a clean IPv6 address and connection on the network. This is necessary because IPv4 address are now being used in tandem with IPv6 on the internet because there basically aren't any IPv4 address left.

There are umpteen support topics like this stemming from the NAT issue, both on community websites like Reddit (and Zandronum), as well as official posts from the ISPs own admins at their tech support boards. Notably, both device and game need to be IPv6 compatible. PS4 isn't, and neither is Xbox 360. Xbox One is, but the story doesn't end there. A lot of PCs, e.g. Windows 7, are IPv6 compatible, but the games necessarily aren't programmed to communicate that way (Zandronum being the game in this case). This isn't usually an issue establishing a connection with a server, but it very much is if you try to run a server--or try to turn your PC into one, which is essentially what you do when you run the Zandronum client.

https://m.zandronum.com/forum/viewtopic.php?f=39&t=8828 [^] There doesn't seem to be much of a need to add more advanced IPv6 compatibility into Zandronum seen ("waste time" was said a few years ago in this tracker). However, IPv6 has come quite aways since then, and it appears it might also be the solution for those that are stuck with ISPs that don't have open NATs. I would label this a fairly major issue if it's preventing people from using the Zandronum client, particularly for people going even a few years back where they couldn't (and still can't) host Zand games.

tl;dr: IPv6 could be the answer for Zand users dealing with unopened NATs that can't host servers no matter what they do or what ports they forward, where the NAT at the networks end itself converts their private IPv4 address they give to you into IPv6. If this isn't the most technically accurate explanation, the gist of it is there, and the sources are there to look up at your leisure, both researched and official. The common threads here are NAT firewalls, NAT processes that convert IPv4 to IPv6, and a lack of IPv6 compatibility amongst affected devices on these problematic ISPs. A IPv6 connection straight from the software on the computer to the ISP would get the NAT process less involved in whatever melting process it does to IPv4 connections.

FYI, I started looking into this. Some of the refactoring you may have noticed recently was meant to facilitate IPv6.

Quote from "Bill Buchanan"

The code itself appears lost, unfortunately, but the research materials are there to examine.

I still have his old code and ported it to the latest Zandronum version. Unfortunately, it was far from finished. It just generalized a few functions to work with IPv4 and IPv6. It didn't add anything yet to actually use IPv6.

Quote from "Filystea"So you can't run a server on ipv6 from your crappy home computer. Not an issue.

If you read what I posted, and follow the links, you'll find out that the computer has absolutely nothing to do with causing the issue. Windows 7 is IPv6 compatible (I tested IPv6 myself by disabling IPv4). The issue is trying to get Zandronum to communicate with the ISP and the internet as a whole, not the computer (unless you're trying to run a server with Windows 95, which is certainly far from the case here).

I'm uncertain where you read that my computer was the issue here, especially when I've already stipulated it's ran a Zand server successfully in the past.

The facts are, some ISPs aren't very forgiving towards IPv4 server hosting applications. Is that an ISP or Zand issue? Whether it is or isn't, it doesn't change the fact that IPv6 implementation on Zand's end would resolve the issue for me and others who can't host Zand. If that's true, does some semantic argument of 'who's to blame' (ISP or Zand) really matter?

The reality is the internet is advancing to the point of being a IPv6 realm. IPv4-only applications (Zandronum being one such example in this case for me and many others) are starting to become incompatible with certain IPv6 ISPs. Those users are affected, and the percentages might well slowly flip around over the coming years until it's only the people on older, backwater IPv4 ISPs that are able to host Zand. As it stands, we're already at the point of a lack of built-in IPv6 causing connectivity issues.

Quote from "Torr Samaho"Some of the refactoring you may have noticed recently was meant to facilitate IPv6.

I still have his old code and ported it to the latest Zandronum version. Unfortunately, it was far from finished. It just generalized a few functions to work with IPv4 and IPv6. It didn't add anything yet to actually use IPv6."

If a test or alpha build comes out, I could do a 1-on-1 test since I know I'm an affected user. Another person (HexaDoken) chimed in on #Zandronum, with Marcaek, that also reported to be affected by this.

I do not know exactly where in their respective source codes the ipv6-related code is, but I'm sure you guys will find it without much trouble. Ioquake 3's might be under the master/code/server folder. Not sure about Dxx-rebirth's though.

I tried hosting a server, and I was able to find my server in the list (checked by hosting with IDE, disabling LAN, and checking the list in Doomseeker). Naturally, it had an IPv4 address because what else is Zandronum going to communicate with? The server showed up as one of those <NO RESPONSE> servers, the ones where you can see it but not any details (WADs, players, etc.). Of course it might have just showed up because it was able to see locally sent traffic on my network, but eh. The curious part is that the port was :3862, which is definitely not what I specified (the same port also happened when I launched and searched with Doomseeker).

Zandronum goes through my ISP with this IP address, which the ISP gets, then apparently converts to IPv6 at their end. Part of this conversion process is apparently handing port warding at their end, i.e. the bogus 3862--this all matches the symptoms outlined in my sources, particularly the Reddit link.

This may have been a mere feature suggestion in 2010, back when Skulltag was still a thing, but this is eight years later--a lack of IPv6 support is causing real issues, now rendering some incapable of hosting servers because their ISPs have advanced past that point and now have to go out of their way to make IPv4 connections, i.e. the crazy CGR routing.

Again, like I said, I'd be game for testing out a IPv6 build if such a thing happens to see more into what's going on.

"
If you read what I posted, and follow the links, you'll find out that the computer has absolutely nothing to do with causing the issue. Windows 7 is IPv6 compatible (I tested IPv6 myself by disabling IPv4). The issue is trying to get Zandronum to communicate with the ISP and the internet as a whole, not the computer (unless you're trying to run a server with Windows 95, which is certainly far from the case here)."

I called it crap because I could. You have ipv6. You can not host. Well not an issue for me. Just buy a server with ipv4.

For unix I could possibly write those few more lines for you (assuming you are dual stack - which should be nearly everything out there ). But I won't since I do not have ipv6, so I can't test this. And don't want to listen to crap like "you fucked up Fily".

Also there would be an outburst not to touch code that went out of my hands hue hue. But that, <pause> is another story.

You may have misunderstood what I meant by "server". If you look at the picture I attached, I'm referring to the server/client program included with Zandronum. I'm not looking to compete with TSGP or FunCrusher and run a server cluster--just run a server on my home computer, one which has A: run a server successfully in the past, and B: is both IPv6 (which the uploaded picture proves) and IPv4 compatible (so the purchase of a IPv4 server will make zero difference here--no amount of different server, computer or OS will change the situation on my end. The problem is no more or less complicated than the fact that my and other's ISP has advanced past IPv4 to IPv6, and what was once a nice feature suggestion is now mandatory for many to be able to use server part of the program).

If you're serious here, then I can take your offer up to test an IPv6 build of Zand on Linux at my end since I know I've got a IPv6 ISP that Zandronum is insufficiently coded to work with. I've never compiled anything on Linux before, so I'm not sure how this would work, but I'd take the task on to advance this issue. You did say it was a "piece of cake", after all. (:

Freenode/a group on Freenode recently launched a pretty violent spambot attack on irc.zandronum.net, so I'm skiddish of joining Freenode and exposing myself there. At its peak, bots were joining channels once every two minutes and bombing it with links to YouTube channels, Freenode networks, and very suspicious-looking JavaScript links that lead to who knows where.

Is there a reason you can't be on the proper #Zandronum at irc.zandronum.net? I can't see you there (that or I'm missing you).

(for right now, we're trying to hobble together some IPv6 Linux build, which is on-topic, but I'd like to avoid getting to conversation-y here. This is a bug tracker, after all...)

FYI, I fully agree that the time to support IPv6 has come. So there is no need to argue whether IPv4 support is sufficient.

Quote from "Bill Buchanan"

If a test or alpha build comes out, I could do a 1-on-1 test since I know I'm an affected user. Another person (HexaDoken) chimed in on #Zandronum, with Marcaek, that also reported to be affected by this.

I'll post here, if I have something ready to test. I didn't have much time lately though, so there is nothing ready to be tested yet.

There isn't really an argument here at this point, and the last message was about two weeks ago, anyway. Since that time, Filystea and I have been trying to hobble something together. I'll leave it to Filystea to fill in the blanks on what it's like from his side of what's happened so far.

In another test, I started a standard Zandronum server on my computer. Like before and in the picture, it showed up as <NO RESPONSE>, but I had someone go looking for it, and as it turns out he was able to actually see the server. Of course, since he found it in <NO RESPONSE> land, he wasn't able to see any WAD information or connect. Also like before, the Zand port specified by me (10666) was ignored in favour of a different one. Also, any time I closed the server down and immediately restarted it with the 'fake' port I saw (e.g., 4121), the re-launched server would show up on master with a different port (e.g., 4111, so the world-wide port adapts to always be different from what I specify in Doomseeker); but if I close the server down and relaunch without changing the port to match (don't chase down 4111 but keep it at 4121), the re-launched server will have the same 'fake' 4111 port.

Not that it's necessary, but I happened upon another discussion on the subject, this one from someone trying to set up a Linode server service.https://irclogs.thegrebs.com/linode/2017/06/14 [^] Of particular relevance is the part from 05:12 to 05:15 (again, I'm not making an argument, just providing any relevant technical information I can find about this issue that may be of help towards understanding and development).

Quote

05:14 <Pep> although i'm a bit confused about how t-mobile US is going to handle it...
05:14 <Pep> basically they switched to a ipv6 only stack
05:14 -!- lgv is now known as skule
05:14 <Pep> if the phone resolves an ipv4 only domain, it resolves as a nat'd address on their nat64gw
05:15 <Pep> so directing to my dns it will resolve ipv4 only or a mapped ipv4 address which a t-mobile phone won't be able to route :/

Definitely think it's about time for IPv6 support. Thought it was there already, but I was incorrect. A friend of mine just recently got a new modem from comcast, and they don't even support port forwarding anymore, but it does support IPv6, which would allow him to host again.

I had to modify a few lines to get it to compile on Linux: I got errors about IN6_ADDR being undefined and being unable to convert to sockaddr_in6* to sockaddr*. That was easily fixed though, I just #defined IN6_ADDR to in6_addr and modified it to explicitly cast to sockaddr*. After that, some quick testing on localhost worked fine. I'll see if I can do some testing with some other people soon.

"There isn't really an argument here at this point, and the last message was about two weeks ago, anyway. Since that time, Filystea and I have been trying to hobble something together. I'll leave it to Filystea to fill in the blanks on what it's like from his side of what's happened so far.
"

I was away for 1,5 week so I kind of droped the contact but got nearly all the three files swaped to support ipv6 ( only ). And ofc only for unix. Did not compile and check if it even works since did not finish. Was too busy.

Nice to see the developers moved their ass.

Main job is to go to src and grep -nR sin .
Seems all are in three files. net.cpp network.cpp and networkshared.cpp alse some little in sv_master.
Than you look for INET and sockaddr_in. That's all. Than fix the functions that do job on them and replace only ipv4 functions with those who can handle ipv6

Not all systems support dual stack ( most do thou ). Either check IPV6_V6ONLY socket option and set it *edit* false if you want dual stack or it might be not supported and you need to go with two servers one running on ipv6 one on ipv4.

should now allow the server to accept both IPv4 and IPv6 connections as long as the OS supports the IPv4-mapped address feature. Let's see if all operating systems used for hosting Zandronum servers support this. If not, I'll have to implement two sockets, one or IPv4 and one of IPv6.

I can't download the current build due to some technical issues (unrelated to the above). If I could download the whole thing wholesale (like DownThemAll) and not through a Linux terminal, I could probably get away with it, but eh. I'll wait it out until the issue is resolved on my end. One way or another, I should have it within two weeks.

As for the build itself, I'll test it at that point, and see if I can find someone in a similar ISP situation to me, or someone that already has IPv6 support, to see if this fixes these woes for good.

A Doomseeker update with IPv6 support will, unfortunately, likely end my use of Doomseeker 0.12.2b and its nice "Refresh All" button (yes, the latest version was used for the above tests and screenshots in case someone wants to run with that).

Tribeam and I did some testing earlier (played the entirety of Doom2), worked well. I connected from IPv4 (albeit on LAN), he connected from IPv6, everything worked. We had some issues at the beginning where it appeared I couldn't send packets to Tribeam, but that was probably just an issue with his router.
I'll need to test on Linux, too, but on Windows it works fine.

Question: When hosting using IPv6 in Zandronum on Windows (7,8,10, etc), do you guys use the Temporary IPv6 address or IPv6 address? I remember reading that Windows uses privacy extensions for IPv6, thus creating a separate Temporary IPv6 address(es) from the original one assigned to an network interface.

I ask because I can see that becoming a potential source of confusion for future Zandronum users.