IPv6 Does Not Work

WORKAROUND: It's the launcher that creates the problem !!
Use MagicLauncher_1.0.0 or the old Minecraft.exe launcher (unknown
version, but downloaded the first quarter of year 2012)

After launching 1.5 or 1.5.1 there is no problems entering IPv6 addresses
of any form (including [2001::6]:25565 ) and connecting to the server

BTW: I'm running windows 7 - 32bit

Good to see confirmation regarding the launcher.

Speaking of which, I had a chance to do a cursory look over its classes and the problem is with LauncherFrame.class. It sets the "java.net.preferIPv4Stack" property to true and the "java.net.preferIPv6Addresses" property to false, which prohibits the use of IPv6 on systems configured as we've described.

Apologies for the lack of updates lately.

I've just had a chance to test out the last few versions to see if there was any change. As before, the problem lies with the launcher. I've updated the summary to point out my previous comment regarding its cause.

1.6.4 also impacted. Has it really taken a year to continue to ask "if it breaks on $CURRENT version?" This is incredibly easy to reproduce for the devs:

1. Run minecraft server. Note that the output of `netstat -a -n -o -p TCPv6` shows java listening on [::]:25565 (wildcard address on the traditional port)
2. Launch the minecraft launcher for any of the current launchers, including the latest as of today.
3. Direct connect to the IPv6 IP of the localhost, which is as follows: ::1
4. The message "Failed to connect to the server java.net.SocketException: Protocol family unavailable" occurs.

Please note that this breaks IPv6 for all but power-users, and more and more ISPs are providing IPv6 access. Additionally, this is a huge problem for users behind CGN (RFC6598) or native-IPv6 with 6to4 transition mechanisms as their IPv4 addresses are NOT globally accessible.

Is there a reason this has taken a year to troubleshoot? Even if global IPv6 access isn't on a developer's machine, surely they have access to >=Vista that has built-in IPv6 support...

Minecreaft Launcher 1.3.6 bootstrap 5 still has the problem "protocol family unavailable"
(Game version 1.7.2)

Is this still a concern in the latest Minecraft version 14w08a? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

I can't find a way to update the affected versions for this bug, so I'm stating it in a comment instead: bug is still present in Minecraft 14w10c.

Side note: The bug will not magically fix itself. Mojang needs to remove the hardcoded disabling of IPv6. To keep asking if the "bug is still present" is pretty useless.

Also see the discussion in MC-15525.

Please update the summary; the problem is not minecraft.exe, as this issue is present on GNU/Linux with minecraft.jar. The first sentance of this issue indicates the contray.

Also, "Local Network" isn't the only thing affected. Playing online does not work either. Maybe the summary should be updated to include this issue as well?

In MC-15525, Grum indicates that Mojang made the decision to set java.net.preferIPv4Stack to true (java.net.preferIPv6Addresses is false by default). According to the Java documentation, setting java.net.preferIPv4Stack to true completely prohibits the use of IPv6. This decision will have to be reversed (or at least an IPv6 non-disabled client needs to be made available) in order to fix this issue (I hereby confirm it still exists in 1.7.9—java.net.SocketException: protocol family unavailable—, and that the presence of IPv6 internet, which I have, is irrelevant).

I've not had the time to test (or inspect the bytecode) of versions past 1.6.4 myself. As of those tests, I can for certain state that (at least on Windows) the problem definitely is the launcher (whether that be .exe or .jar). Given you (Hugo) state that Linux appears to suffer a similar problem, I'd bet the same for it. Try running the game from a 3rd party launcher (IPv6 worked with both MultiMC and MagicLauncher last I checked).

At this point, given Grum's statement (as pointed out by Omar) I don't feel the need to keep updating this report, since the bug will remain by design. Perhaps they'll fix it when IPv6 becomes more prevalent. At the very least it wouldn't hurt to add an IPv6 option (with an appropriate warning) to the launcher. In the meantime, to use IPv6 we're forced to use a 3rd party launcher or a modified version of the official one.

I'll update the topic version (to 1.7.9) and modify the summary to clarify that the launcher's extension is irrelevant and that this affects Linux users as well.

I can confirm that it affects Macs.

I think the best short-term solution would be a command line option to enable IPv6 support. Little chance of someone without a functioning IPv6 stack accidentally enabling it and receiving the errors that prompted Mojang to disable IPv6 in the launcher.

Regarding the launcher

At the very least it wouldn't hurt to add an IPv6 option (with an appropriate warning) to the launcher. In the meantime, to use IPv6 we're forced to use a 3rd party launcher or a modified version of the official one.

I agree that adding an option (even if it's just a CLI one) would be an acceptable solution (not the best, IMHO, but it'd be enough to keep me happy).

MagicLauncher does not work: http://sprunge.us/XgFB
MultiMC works half way: The launcher work, but the game still has IPv6 disabled (both LAN and online). So the game can be run, but single player only.

Since the launcher itself is rather simple and small, and does not actually contain game code or anything secret, would you consider open sourcing it so we can at least fix the issues for ourselves? I'd much rather mantain a patched version for myself than use a third party launcher.
Otherwise, why not provide an IPv6 minecraft.jar on your website? It's basically the same code with two lines commented out, I don't think it's much of a hastle.

Regarding the game

Are there any know workaround? I've managed to install it, but I'm still limited to single player only.

Also, have you actually considered the implications of this issue? Many, MANY paying customers cannot play the game, and will not be able to for an undefined future, just because some people out there have broken networks. You guy basically took my money and are unwilling to give me a working game in return.

If there's no workaround, can I get a refund? I mean, I either want a game that runs, or my money, you can't expect me to settle for none of both choices.

This comment describes a bit why IPv6 is completely disabled:

It's unfortunate that "preferring" IPv4 in actuality means "disabling IPv6", but that's on Java. The preferIPv4Stack setting is only checked when the VM starts, which is why it must be set by the bootstrap. Given that, it's not clear to me why someone starting the jar file directly, without the bootstrap, would have a problem, or why the launcher jar would need to set this property.

I belive he meant the preferIPv6Addresses, but the rest still applies.

So I installed eclipse and got to hacking some code:

A wrapper
This tiny piece of code wraps around the launcher and enables IPv6 before the launcher can disable it. I'm leaving this here as a solution for users who are interested in downloading the game and this is not mean to be mainstream.

For some reason though, the game itself still won't have any network capabilities. I'm not sure if the laucher spawns a new VM, of the game has something else hardcoded to disabled IPv4.

A solution
This sample code re-enables IPv6 only AFTER having tested that it works properly. If it fails, it will bail and to nothing.
If you can review this and integrate this into minecraft, we can finally fix (and not simply "resolve") this issue.

If (or rather, hopefully, when) you include this into minecraft, the result would be:

• IPv4-only users with proper network configurations would see no change (maybe < 50ms extra to startup time, heh!)

• IPv4-only users with broken network configuraions would have to wait for a very small timeout upon launch and only upon launch (this is a few seconds and might be noticable. But hey, their network is broken, remember?).

• Dual-stack users would be able to use both stacks, hence, being able to connect to IPv6 servers (though I belive those aren't common).

• IPv6-only users can finally play the game. Other specific IPv6 scenarios may require further work, but those issues will arise later (see below for an example).

In short, nothing breaks, not even for people with broken configurations, which I think is what's most important here.

—

As for future issues (though not quite related), here's an example:

I'm pretty sure the "Open to LAN" only has an IPv4 multicast literal for announcing/listening, so that would require further changes on behalf of the devs to work. However, that would be a completely new issue once these changes get integrated into the game.

I'd appreciate some feedback for this. 🙂

The launcher isn't obfuscated like the game is.

The fact that it's not obfuscated doesn't make it legal to alter it or provide modified versions to third parties. Also, source is easier to edit than decompiled classes.

The java.net.preferIPv4Stack setting relates to the local software (the "stack") used to communicate over the network device. The java.net.preferIPv6Addresses setting controls whether IPv6 or IPv4 addresses are returned by functions, such as when performing a DNS lookup. Which of the two are relevant depends on whether you or the host you're connecting to is running IPv6. It's possible that java.net.preferIPv6Addresses=true forces java.net.preferIPv4Stack=false, but the documentation doesn't say so.

Have you tried adding "-Djava.net.preferIPv4Stack=false" to the JVM arguments field in the profile editor in the launcher? Setting that to false either in your wrapper code or the profile settings should work, depending on whether the launcher and game run in the same VM or separate ones. If it doesn't, then there's either a deeper issue than that one setting, or it should be something trivial to fix.

@Torabi:
Ok, using my wrapper, nope, there's something else going on, and I'm not sure what it is: "java.net.SocketException: Protocol family unavailable".

• My wrapper basically runs minecraft.jar, which I belive downloads and runs launcher.jar (correct me if I'm wrong).

• launcher.jar logs me in fine, so it's using IPv6. I guess all these are on the same VM, right?

• The game itself does not seem to have any IPv6 connectivity.

This is curious:

[22:44:43 INFO]: Client> [22:44:43] [MCO Availability Checker #1/ERROR]: Couldn't connect to Realms: Realms (500) Server not available!

It's not a network or routing error, it's a 500 error that came from the server, so the game used IPv6 up to when it reaches the menu...

22:45:43 INFO]: Client> [22:45:43] [Client thread/WARN]: Unable to start LAN server detection: No such device

That's understandable, the game is probably using an IPv4 literal for that, and it's not working.

However, when connecting to a server:

[22:46:55 INFO]: Client> [22:46:55] [Client thread/INFO]: Connecting to ::1, 25565
[22:46:55 INFO]: Client> [22:46:55] [Server Connector #1/ERROR]: Couldn't connect to server
[22:46:55 INFO]: Client> java.net.SocketException: Protocol family unavailable
[22:46:55 INFO]: Client>        at sun.nio.ch.Net.connect0(Native Method) ~[?:1.7.0_60]
[22:46:55 INFO]: Client>        at sun.nio.ch.Net.connect(Net.java:465) ~[?:1.7.0_60]
[22:46:55 INFO]: Client>        at sun.nio.ch.Net.connect(Net.java:457) ~[?:1.7.0_60]
[22:46:55 INFO]: Client>        at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:670) ~[?:1.7.0_60]
[22:46:55 INFO]: Client>        at io.netty.channel.socket.nio.NioSocketChannel.doConnect(NioSocketChannel.java:176) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.connect(AbstractNioChannel.java:169) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.DefaultChannelPipeline$HeadHandler.connect(DefaultChannelPipeline.java:1008) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.DefaultChannelHandlerContext.invokeConnect(DefaultChannelHandlerContext.java:494) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:479) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.ChannelOutboundHandlerAdapter.connect(ChannelOutboundHandlerAdapter.java:47) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.DefaultChannelHandlerContext.invokeConnect(DefaultChannelHandlerContext.java:494) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:479) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.ChannelOutboundHandlerAdapter.connect(ChannelOutboundHandlerAdapter.java:47) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.DefaultChannelHandlerContext.invokeConnect(DefaultChannelHandlerContext.java:494) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:479) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:464) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.DefaultChannelPipeline.connect(DefaultChannelPipeline.java:847) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.AbstractChannel.connect(AbstractChannel.java:198) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.bootstrap.Bootstrap$2.run(Bootstrap.java:165) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:354) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:348) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client>        at java.lang.Thread.run(Thread.java:745) ~[?:1.7.0_60]

Looks like the game itself isn't using IPv6. Maybe a new VM is started? I'm really confused. 😞

In any case, can you forward the sample code I linked above to the devs? It fixes the issue (at least for minecraft.jar and the launcher) while not affecting any current user negatively (or, if you're one of the dev, can you give me some feedback for that?). Thanks!

As far as I can tell, "java.net.SocketException: Protocol family unavailable" means that it's trying to bind an IPv4 socket to an IPv6 address (and obviously failing). The "BindException" errors @unknown mentioned appear to be what happens when an IPv6 socket attempts to bind to an IPv4 address, and fails (among other things).

The underlying problem may be Java. An IPv6 socket is supposed to be able to communicate with both IPv4 and IPv6 peers, but it may be OS- and implementation-dependent.

Minecraft.exe/Minecraft.dmg/Minecraft.jar are all the "bootstrap". The first two are native code for the relevant OS, and the last is platform-independent Java. They're intended to be updated very infrequently, preferably never, because it's apparently difficult to make them auto-update due to security/permissions/sandboxing or something. All the bootstrap does is download and run launcher.jar, which is how they are able to automatically update the launcher.

You'll get an error like "[MCO Availability Checker #1/ERROR]: Couldn't connect to Realms" when using any version that's not realms compatible, such as snapshots. It is interesting, however, that it's coming from the client, and yet you later receive a "Protocol family unavailable" error. It looks like you're trying to connect to a local IPv6 address (::1). What happens if you try to connect to a remote IPv4 address?

I would have hoped that all of this would have been cleaned up when the networking code was switched to netty, rather than IPv6 support being broken in the process. I'll have to see if I can get one of the devs to take a look at it.

As far as I can tell, "java.net.SocketException: Protocol family unavailable" means that it's trying to bind an IPv4 socket to an IPv6 address (and obviously failing).

Not exactly. It means that it tried to bind an IPv4 socket, and IPv4 is unavailable on that interface.

The underlying problem may be Java. An IPv6 socket is supposed to be able to communicate with both IPv4 and IPv6 peers, but it may be OS- and implementation-dependent.

Indeed the issue is java. On an IPv6-only system, it tried to use IPv4 by default until I set the preferIPv6Addresses property to true. Regrettably, java is well know for it's poor network IPv6 compatibility. 😞
(I don't blame you for that though!)

All the bootstrap does is download and run launcher.jar, which is how they are able to automatically update the launcher.

That's why it's so very important to fix launcher.jar first. Without fixing it, the game can't even be downloaded. Once launcher.jar works, further issues can be addressed. Have you considered integrating the sample code I provided above? (I just updated it a bit). It will only alter the value of preferIPv6Addresses and preferIPv4Stack after having succesfully tested and made sure IPv6 works correctly and not affect any other scenario, which is what you care about. It shouldn't take more than five minutes to review and integrate it. There'll be no regressions, even for broken network setups.

You'll get an error like "MCO Availability Checker #1/ERROR: Couldn't connect to Realms" when using any version that's not realms compatible, such as snapshots.

Nope, running 1.7.9 on a clean install performed yesterday (I could not install minecraft on my desktop before I wrope the crappy wrapper mentioned above).

I'll try the same client on a network with IPv4 tomorrow (my university has IPv4 so I'll use that oportunity to test it) and confirm if the realms issue is or isn't a client issue.

It is interesting, however, that it's coming from the client, and yet you later receive a "Protocol family unavailable" error. It looks like you're trying to connect to a local IPv6 address (::1). [...]

Yes, I am. Any other IPv6 literal gives the same issue.

I would have hoped that all of this would have been cleaned up when the networking code was switched to netty, rather than IPv6 support being broken in the process. I'll have to see if I can get one of the devs to take a look at it.

Indeed, it is interesting (and confusing) that realms connects and Multiplayer does not. They're inconsistent, but, AFAIK, the same VM. However, now that you've mentioned netty, I can't avoid thinking that it may have a different setting for disabling IPv6, and that's the issue.

Also, notice how it uses sun.nio.ch.Net, instead of java.net, which again, makes me think it uses a different setting, which has also been hardcoded. (I've failed to find further details on this though).

[quoted out of order just to make replying tidier]
What happens if you try to connect to a remote IPv4 address?

It fails, as expected, with the expected error message:

java.net.SocketException: Network is unreachable.

Or course, this will happen for any address != 127.0.0.1, since there are no IPv4 addreses or routes.

@Torabi: Any updates on this?

When I last asked @unknown about it, they were all neck-deep in merging about 3 months worth of code from several members of the Minecraft team for snapshot 14w25a. They've been a bit busy since dealing with the large number of resulting bugs. I'll bring it to his attention again when things cool off a little. Any testing or research we can do in the meantime will help.

One of the obstacles is that the bootstrap (minecraft.jar) needs IPv6 support – as MCL-2627 shows, you can't even download the launcher (launcher.jar) if you don't have IPv4 connectivity. And the bootstrap can't be updated automatically, so they're reluctant to make any changes to it. There are three different versions of the bootstrap: a native Windows binary, a native Mac binary, and a Java version as a catch-all for anything else. It's possible that the Windows and Mac versions of the bootstrap don't have this problem, though they may also deliberately disable IPv6. I think they might just package up the Java version and run it, and are just there for people who have trouble launching jars directly.

Unless this documentation is wrong, your sample code isn't going to accomplish anything. java.net.preferIPv4Stack is only read at VM startup time, so setting it using System.setProperty() is pointless, because the VM is already running. I guess it might be inherited by a child VM. Or maybe the documentation is flat-out wrong. It seems like it's wrong on what the preferIPv6Addresses setting actually does.

It looks to me like the launcher and the game run in separate VMs. I vaguely remember reading somewhere that the launcher passes "-Djava.net.preferIPv4Stack=true" in the command that runs the game, which might be why setting it to false in the JVM argument box wouldn't work. I also don't know how or if those settings affect Netty, though I suspect that there's more to it than that, since reportedly the client did work on IPv6 before the switch to Netty. I would guess that the realms checker doesn't use Netty, which is why it works(ish) with your wrapper. So most likely the network code in the client is written to explicitly use IPv4, and thus doesn't respect the system properties.

> Unless this documentation is wrong, your sample code isn't going to accomplish anything. java.net.preferIPv4Stack is only read at VM startup time, so setting it using System.setProperty() is pointless, because the VM is already running..

Using preferIPv6Address is enough to determine if java uses IPv4 or IPv6:

• Having preferIPv4Stack=false and preferIPv6Address=false will make java prefer IPv4 anyway.

• Having preferIPv4Stack=false and preferIPv6Address=true will make java prefer IPv6.

My sample code uses reflection to overwrite the the value of preferIPv6Address after is has been read, hence overcoming the limitation of it being read only once. Here's how it works:

• Attempt to establish an IPv6 connection. (at this point preferIPv4Stack and preferIPv6Address have their default values).

• If it failed, set preferIPv6Address to false, via reflection. This will affect all future connections (they will not use IPv6).

• If it succeeded, set preferIPv6Address to true, via reflection. This will affect all future connections.

Hence, IPv6 will only be used if it has been proven to work.

I would advise against using he preferIPv4Stack flag since:

• It cannot be altered by reflection. I've failed to find where it's read by grepping through java's src.zip, so I assume that it must by read by the JVM itself via some native code. (I'm just guessing though).

• preferIPv6Address is enough to control which protocol is used.

> Or maybe the documentation is flat-out wrong.

This would not surprise me coming from Oracle.

—

While I understand that there are some other issues pending, I would appreciate if this issue is given a higher priority. As the game is right now, it cannot be played in any form of multiplayer (eg: Open-to-LAN, Online, Realms, or with a dedicated VPS running a server) by users with no native-IPv4.
In other words, it's a critical issue, which prevents users with a properly working PC and network from playing the game, with absolutely no workaround. Considering that it's a product we pay for, I think I have a right to complain if there is absolutely no way for me to use it.

Using preferIPv6Address is enough to determine if java uses IPv4 or IPv6:
Having preferIPv4Stack=false and preferIPv6Address=false will make java prefer IPv4 anyway.
Having preferIPv4Stack=false and preferIPv6Address=true will make java prefer IPv6.

If that were all true, then Mojang never would have set preferIPv4Stack=true, this ticket would have never been filed, and we wouldn't be having this conversation. So something's amiss.

I would advise against using he preferIPv4Stack flag since:
It cannot be altered by reflection. I've failed to find where it's read by grepping through java's src.zip, so I assume that it must by read by the JVM itself via some native code. (I'm just guessing though).
preferIPv6Address is enough to control which protocol is used.

And if these are both true, then passing "-Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Address=true" when starting Minecraft.jar should solve your problem, at least for the launcher and downloading the game. Setting those properties in the JVM arguments field in the launcher profile should also solve it for the game, though as discussed, the network code may assume / be forcing IPv4 somewhere else in the client.

I've also just realized that we've been conflating preferIPv6Address and preferIPv6Address*es*. I'm only aware of the latter, and that would some of the confusion. preferIPv6Address may indeed have the behavior you ascribe to it, though it doesn't appear to be documented anywhere. Does it default to true or false?

If that were all true, then Mojang never would have set preferIPv4Stack=true, this ticket would have never been filed, and we wouldn't be having this conversation. So something's amiss.

preferIPv4Stack alters preferIPv6Address, which causes this issue. Setting preferIPv6Address is enough to achieve the behaviour you want, and setting preferIPv4Stack cannot be undone programatically. preferIPv4Stack, by transitivity also achieves the behaviour you want, but cannot be alterned, even through reflection.

And if these are both true, then passing "-Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Address=true" when starting Minecraft.jar should solve your problem, at least for the launcher and downloading the game. Setting those properties in the JVM arguments field in the launcher profile should also solve it for the game, though as discussed, the network code may assume / be forcing IPv4 somewhere else in the client.

It does not. As we discussed before, the game seems to alter this setting programatically. There's still the Protocol family unavailable error.

I've also just realized that we've been conflating preferIPv6Address and preferIPv6Address*es*. I'm only aware of the latter, and that would some of the confusion. preferIPv6Address may indeed have the behavior you ascribe to it, though it doesn't appear to be documented anywhere. Does it default to true or false?

preferIPv6Addresses is the name of the java property, preferIPv6Address is the name of the variable where the setting is stored internally. We're still talking about the same thing here. From java.net.InetAddress:

static {
         preferIPv6Address = java.security.AccessController.doPrivileged(
             new GetBooleanAction("java.net.preferIPv6Addresses")).booleanValue();
         AccessController.doPrivileged(new LoadLibraryAction("net"));
         init();
     }

Sorry about the confusion on this one.

Again, if the source for bootstrap were made available, I'm sure I could submit a proper patch for this. I see no reason for you not to release it, since it doesn't actually contain game code or any other secrets (AFAIK).

Any News on this?
I would really like this solved because i want to host a server for my friends, but I can currently not do so. The problem is that i only have a unique IPv6 adress and a shared IPv4 Address.

Unlike the above commentor, I have no IPv4 addresses or routes. I've been completely unable to play a game (which I payed for, btw), for several months now.

Any idea on when this critical and fatal issue will be fixed? I kinda passes on all my holidays being completely unable to play at all.

Hugo, while I know this isn't a complete workaround, you can get it set up and then play in offline mode. At what stage in the launching process are you? (Note: I'm asking because you say you haven't been able to play. Single player is better than no player 😉

I would love to see IPv6 work, too. The plan would be to access a server on my home LAN via OpenVPN with a straightforward IPv6 route instead of having to take care of NAT or RFC1918 addressing conflicts when on the road.

Can we please at least allow Minecraft to dual stack? We do not have a local IPv4 address which makes me unable to play over LAN. Minecraft should first try to connect to IPv6 and then fallback to IPv4 if that doesn't work.

I would strongly support that as it seems to be the best choice.

I ran into this issue recently when attempting to set up a server on my home network that I could connect to from my workplace. My home is assigned an IPv6 from Comcast, so I have no workaround that I have discovered yet to connect to it.

Is there any update on this?

It's been over half a year since I, like many other users can't play multiplayer (after having paid, btw!) - and the situation only gets worse as more and more ISPs transition to IPv6. This is getting completely ridiculous, I wanted to play during the holidays with my friends, the holidays started and ended, and we could not because of code that explicitly breaks support for non-broken networks!

i have the same problem..i cant connect to any server and nothing changes at this issue!

I run a private cloud that only uses native IPv6. This seems like a large oversight to disable a fundamental networking protocol in this day and age.

> I run a private cloud that only uses native IPv6. This seems like a large oversight to disable a fundamental networking protocol in this day and age.

Indeed, this issue meant the end of minecraft (forever) for those of us where our desktops and laptops only have native IPv6.

IPv6 on Minecraft seems to work for me on Linux, but not on Windows.

Seems like a two line fix, why is this being put off?

@@unknown: Because the problem is more complicated than it appears (read the comments on this issue, and MC-15525), and fixing it (at least the way suggested) might very well break it for an even larger chunk of users. That isn't a non-issue for Mojang, no matter whether it's right or wrong. IPv6 support in Java was not great, though perhaps it has improved in Java 8.

Interesting, however, that you report IPv6 as working on Linux. Has anyone tested this with the new, native launcher / bootstrap? One of the barriers to getting this fixed was Mojang's hesitation to push out a new bootstrap, because they couldn't update it automatically, and it must be downloaded manually. However, they released a native installer for Windows in December/January, and are planning on doing the same for Macs in the future.

I've tested on Linux, I can connect to IPv6, but it requires me to add the address to my hosts file and than use the name rather than the address. Not ideal.

> @Daniel L: Because the problem is more complicated than it appears (read the comments on this issue, and MC-15525), and fixing it (at least the way suggested) might very well break it for an even larger chunk of users. That isn't a non-issue for Mojang, no matter whether it's right or wrong. IPv6 support in Java was not great, though perhaps it has improved in Java 8.

No, not problem is not complicated as it appear. Is main issue here, is that you did a workaround to fix this for people who had broken network settings, while breaking the game for people with their network properly set-up (in other words: I can't use a product I paid for because you prefer to satisfy people who have broken configurations!). The solution is simple, fix IPv6 and:

• It works for people with their network properly set up, either inet4 or inet6.

• People with broken network settings should fix that. Either do it themselves, ring their ISP, or hire a technitian. Configuring their own network is their own responsability.

> Interesting, however, that you report IPv6 as working on Linux. Has anyone tested this with the new, native launcher / bootstrap? One of the barriers to getting this fixed was Mojang's hesitation to push out a new bootstrap, because they couldn't update it automatically, and it must be downloaded manually. However, they released a native installer for Windows in December/January, and are planning on doing the same for Macs in the future.

Where can I find this? The one at https://minecraft.net/download has the same sha512 as eight months ago, so there's been no change there.

> I've tested on Linux, I can connect to IPv6, but it requires me to add the address to my hosts file and than use the name rather than the address. Not ideal.

Can you elaborate further? Did you add the IPv6 of the remote game server to /etc/hosts? Minecraft completely ignores IPv6 AFAIK, what else did you do to get it to connect?

I added it go the /etc/hosts and I believed I passed an argument for it to prefer IPv6.

> I added it go the /etc/hosts and I believed I passed an argument for it to prefer IPv6.

What argument did you pass to the game for it to do this? AFAIK, it completely disables IPv6 on startup. Or are you just talking about the bootstrap?

You can set flags to be passed to the game in the launcher. I'm unsure if this is required though - it's been a while since I touched Minecraft.

Any update on this? IPv6 on Minecraft still works (partly) on Linux but not Windows.

How is this issue not confirmed yet? There is 45 comments, and the issue is easy to reproduce.

22% of Internet users in the USA is on IPv6. This is a large group of people that you would be affecting by disabling the IPv6 Stack.

> 22% of Internet users in the USA is on IPv6. This is a large group of people that you would be affecting by disabling the IPv6 Stack.

It would seem Mojang simply does not care. For two years, many of us have been completely incapable of playing online, at all, even though we paid the full price for the game.

Note that this bug is not accidental, but deliberate, as a workaround for people with broken network configurations (while breaking for other people, with no workaround possible). It would seem that not logical reasoning will make this go away soon, or ever.

Just get used to not-playing minecraft: it seems to be the only choice.

How is this issue not confirmed yet? There is 45 comments, and the issue is easy to reproduce.

How would you go about reproducing it, unless you have an IPv6-only internet connection? As far as I'm aware, most of the world has IPv4 access, some also have IPv6, and very few only have IPv6. Disabling the IPv6 stack has no effect on people who also have IPv4 access, and resolved an issue for a substantial number of customers.

I've had an interest in IPv6 for about a decade. Over the years, I've watched it struggle for adoption and tried various tunnel providers. Earlier this year I found that my service provider now claimed to provide IPv6 addresses, and I eagerly changed the settings on my router to try it out. It seemed to work fine, but I could no longer access some sites, such as Wikipedia, which is actually accessible over IPv6. I didn't feel like messing with it at the time, and just changed the settings back. Maybe I did it wrong, maybe my hardware just doesn't support it, maybe it was my service provider, or maybe IPv6 still had some adoption issues. I'm reasonably tech-savvy, but at the time, I just wanted my internet to work.

IPv6 support in Java is flaky. For years disabling it was the solution that everyone passed around whenever there was a connection problem. I believe it has improved in Java 8, and I'm starting to see a shift in how developers handle those problems. Disabling it is no longer the common wisdom. However, Mojang has been reluctant to require more recent versions of Java, for reasons unknown to me. Probably Mac support. The recent native launcher they've pushed out, which provides its own version of Java, may resolve their hesitance to rely on features provided by newer versions of Java.

I've brought this ticket to the attention of several of the developers at Mojang. Most of the responses I've gotten back are along the lines of "I wasn't aware there was a problem". But the reality is that regardless of the number of people with IPv6 access, very few of them don't also have IPv4 access. Mojang made the decision to disable IPv6 based on a substantial volume of complaints and support requests that Minecraft no longer worked. They're unlikely to reverse that decision until a similar number of complaints and support requests make it clear that it's in their best interest to do so.

Reproducing this problem is easy on modern windows systems by turning of the ipv4 stack and leaving ipv6 on, this way your pc will only use your native IPv6 connection, if ipv6 doesn't work correctly in your home/city/country, it doesn't mmean its broken for us al,even more, some ONLY have ipv6 access and they NEED to tunnel their ipv4 over their IPv6 connection. Because minecraft turns IPv6 completly of, they also BREAK the way the OS can tunnel data over an IPV6 only network to the IPv4 part of the world, breaking something what worked for them in the past.

IPv6 has worked for Minecraft in the past and mojangs decision to disable ipv6 broke for many ipv6 only networking users with the proper transition techniques in place.

For your information, the method to connect to IPv4 address from IPv6 only areas is called NAT64 (rfc6146), this works by translating the IPv4 address from the target to IPv6 addresses representing the same address, this way the IPv6 host only sees connectivity on the IPv6 network and CANNOT use IPv4 sockets to the outside world, even though he can connect to IPv4 host fine thanks to the NAT64. Minecraft CANNOT use this with the setting of disable IPv6, something mojang didn't see coming when they disabled it

> How would you go about reproducing it, unless you have an IPv6-only internet connection?

It's quite simple to reproduce: with a dual-stack connection, disable IPv4.

You can optionally enable something like NAT64, or another transition mechanism if your server is running on IPv4-only, but since these are really transparent, they're not necessary for the purpose of analysing this ticket.

> Disabling the IPv6 stack has no effect on people who also have IPv4 access, and resolved an issue for a substantial number of customers.

From what has been described, the root cause of these issues, were misconfigured networks. Properly configuring those networks is the proper solution, and could have satisfied everyone.

Personally, I've IPv6-only, with NAT64. I don't have issues reaching hosts (except less than a dozen misconfigured servers - during a period of >2 years).

> Mojang made the decision to disable IPv6 based on a substantial volume of complaints and support requests that Minecraft no longer worked.

"volume of complaints" should not be the only factor involved. Relevancy of the complaint should be a factor too. If the root cause of a complaint is a misconfigued network (as mentioned several times around IPv6-related issues), then those issues should not be relevant to Mojang or the developers. Tell the users how to configure their network, don't break the game for others.

I paid for the game. And I can't play. Reason: Mojang prioritizes people with broken setups. This isn't an aggressive complaint, I'm trying to get a message across: I paid, and now you're saying you don't care about the fact that I cannot play the game.

How hard can it be to implement a "use IPv6" checkbox in the launcher and some command line argument for the client?

There are plenty of options in the launcher that can seriously damage your game files and world saves. IPv6 wouldn't be one of them.

Use MultiMC if you want connect over IPv6
Atleast it worked for me 🙂

Probably Mac support.

They resolved this a few weeks ago, Macs now use the latest Java.

The bug still exists inside minecraft 15w42a, the reason Mojang decided may be related to the java multicast problem of settings the TTL to zero without it, http://stackoverflow.com/q/139909/1542723, however Mojang can use ipv6 multicast addresses to fix the real problem instead of turning the ipv6 stack of

Time to try this again.

Yay! Welcome to 2015, Minecraft 🙂