JOSM never falls back to IPv4 if IPv6 stack available

[osm@…]

If there is a IPv6 stack available: Since r5892/josm does not fall back to a IPv4 connection on IPv6 connection failure.

On a connections with faulty IPv6 connectivity (very common) JOSM will always timeout without fallback.

Test Case on Linux:

sudo ip6tables -I OUTPUT -d spike-01.osm.org -p tcp --dport 80 -j DROP
sudo ip6tables -I OUTPUT -d spike-02.osm.org -p tcp --dport 80 -j DROP
sudo ip6tables -I OUTPUT -d spike-03.osm.org -p tcp --dport 80 -j DROP
JOSM pref prefer.ipv6=true : JOSM fails
JOSM pref prefer.ipv6=false : JOSM OK

To clear ip6tables:

sudo ip6tables -D OUTPUT -d spike-01.osm.org -p tcp --dport 80 -j DROP
...

PS: java.net.preferIPv6Addresses=true likely better than java.net.preferIPv6Stack=true
PPS: As a sysadmin, I would really prefer that JOSM didn't override java's IP stack preference.

/ Grant aka Firefishy

[iandees]

As I mentioned in #8562, this affects me, rendering the latest JOSM unusable on my machine. My router gives me an IPV6 address but it's not routable.

[apmon]

It looks like you don't even need "faulty IPv6", as it seems to happen even on a more or less IPv4 only host.

With java.net.preferIPv6Addresses=true it looks like Java will prefer the IPv6 address, even if there is only a link local IPv6 address, which will then immediately fail with Network unreachable. Therefore pretty much any IPv4 only system that doesn't have IPv6 explicitly disabled (if even that helps) looks to break with that setting.

As nearly all Windows systems have teredo enabled by default, you will probably not see direct failures of this behaviour on Windows, but it will potentially significantly degrade performance. For example I have been seeing nearly 40% packet loss to osm.org when using teredo.

One could possibly argue that this is a broken behaviour of the jvm, and it might differ from system to system, but as much as I am in favour of IPv6 and would like to see people getting forced to fix their broken IPv6 connectivity, breaking all IPv4 only systems does not look like a viable option.

[stoecker]

In 5900/josm:

Java IPv6 is so broekn, it can't be enabled by default (fix #8627, see 8562)

[stoecker]

I didn't think that Java has such a crappy IPV6 implementation. Seems they have only a switch that says use AAAA address when setting is on. No wonder this is disabled by default, as that will not work. Minimum is that for connection attempts all available addresses are tried in order of their importance. For a broken IPV6 setup that would mean a delay, but no failure.

As it is now it is unusable.

[Don-vip]

Ticket #8629 has been marked as a duplicate of this ticket.

[anonymous]

It is bit strange that this is still a problem today.
I am using dual stack on my PC. Both ipv4 and ipv6 {over tunnel} working OK.

When starting JOSM I can see this message:

2019-05-09 11:12:03.703 INFO: Log level is at INFO (INFO, 800)
2019-05-09 11:12:04.165 INFO: Detected useable IPv6 network, preferring IPv6 over IPv4.
Warning: Nashorn engine is planned to be removed from a future JDK release
2019-05-09 11:12:07.178 INFO: GET ​https://api.openstreetmap.org/api/capabilities -> !!!
2019-05-09 11:12:07.179 WARNING: java.net.SocketTimeoutException: connect timed out

So I am opening settings and expert mode, finding prefer.ipv6 is set to "auto".
Changing that to "false" and restarting JOSM, working OK.