On Fri, 1 Jan 2016, Florian Lohoff wrote:
There are too few users with that specific issue to care for them
right now with an automatic approach.
Germany - Bigges Community - Largest ISP Telekom is switching all
DSL contracts to Dualstack. Kabel Deutschland is already handing
out IPv6 be default with DS Light. So within a very short timeframe
you'll see a lot more people complaining.
No. Because only a minority will walk between IPv6-enabled and IPv4-only
networks.
Java does not support on-the-fly detection, but this setting must be
done before first network usage and cannot be changed later. We
can't change that behaviour. Feel free to submit a Java bug report.
There is no such thing as a on-the-fly detection. You as the application
author need to write the detection. You need robust "connect" logic
which tries ipv6 and falls back to ipv4 when the connect does not
work. The latest RFCs gives even more advice on how to work around
long delays induced by servers advertising ipv6 and not responding
to it or intermitted ipv6 problems e.g. packet loss in the v6 path. This
is the daily business for an ISP - You path are different for v4 than
for v6 so you have different latencys, paths, packet loss probabilities
etc.
As said: We don't provide Happy Eyeballs. WHY should JOSM try to resolve
the issues of the ISP? Loss on the path, delays, ... are all ISP issues
and have to be solved by the ISP. Happy eyeballs only hides them.
The only valid argument ATM is that JOSM needs one additional start when
you switch from an IPv6 enabled network to a non-enabled network. That's a
known bug. And as said the reason is that Java does not allow us to change
behaviour after we did a first network connection. I'll check if we can at
least auto-restart it in this case.
My user setup is continously broken and i work around it. YOU refuse
to even implement 20 year old Best Common Practices written in RFCs
for a good reason.
It's not my problem that you have a constantly broken setup. I have not.
I use IPv6 for years now at home and in my company and all our internal
traffic goes over IPv6 and I have no reasons for workarounds.
When I had IPv6 trouble then I contacted the ISP and they fixed it which
in the end resulted in better monitoring on their side and less trouble.
http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.de/110207
Also this is a typical setup error. If someone accesses "localhost", then
the tool also must listen on localhost which nowadays means IPv4 and IPv6
otherwise the address must be 127.0.0.1 which is the IPv4 address for
localhost.
Sorry - NO - I have a perfectly working ipv6 setup with German Telekom
at home. Even there i need workarounds with josm not falling back
to ipv4 with the tracer plugin.
Then contact the tracer author and tell him to fix his software and not
to try to access illegal address. Either the tracer plugin must use
127.0.0.1 only or the tracer tool itself must listen also on ::1.
EVERY single connection needs the fallback logic for itself without
cached prior knowledge of the environment.
No. It does not need this. No software does this for IPv4. Why should we
do this for IPv6? To make IPv4/IPv6 transition smoother some people
thought that IPv6 errors should be silently ignored. And what's the result
- people like you assume that having errors is ok. IT IS NOT OK.
With mobility my ipv4 only connection can change to dualstack to dslight
to a pure ipv6 with 6to4 NAT back to ipv4. If my services are reachable
Dualstack there should be service everywhere. With JOSM the first
change in network environment needs an application restart.
As told multiple times this has technical reasons. Java does not allow to
switch the handling of IPv6 after I did a single network access. I would
be happy to have it like for all other tools which follow the OS
preference, but that's not possible ATM. If you can't live with it,
disable it. I don't rewrite the whole Java network stack only to satisfy
your need for perfection.
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
_______________________________________________
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev
