On Thu, 31 Dec 2015, Florian Lohoff wrote:
I disagree on that. The fallback to v4 should be per CONNECTION and
not per application restart. The RFCs are pretty clear on this
and further behaviour improvements on intermitted ipv6 connectivity.
We had the same discussion already here. Most of the arguments are there
already.
https://josm.openstreetmap.de/ticket/11208
JOSM is a pain in the ass concerning ipv6. I typically roam with my
notebook between dualstack and ipv4 only locations with suspend/resume
and most of the time i need to save session restart josm etc.
Its not even deterministic what the error looks like it just
complains on some random network access ...
If you switch between such networks disable IPv6 with "prefer.ipv6" set
to "false" or use a start script to set correct settings.
There are too few users with that specific issue to care for them right
now with an automatic approach.
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.
Trying multiple connections can hide such broken connections, but
most applications don't do this. Web browsers are the main
exception. JOSM not.
So you are clearly not adhearing to BCPs for dual stack application
development. There has to be a fallback to ipv4 for every single
connection attempt not just once we restart the application.
We also do not fallback to secondary IPV4 addresses and so on and so on.
Happy Eyeballs is a feature and we don't have that feature.
Just one of the most recent RFCs making this very clear that
intermitted ipv6 connectivity is a common case and needs to be
worked around in the application:
https://tools.ietf.org/html/rfc6555
Don't know where you find the statement in the RFC above. Problems in
section 3 of the document still have to be fixed, the document itself
provides only a workaround to "enjoy nearly identical performance" even
without fixing the problems. Time advanced since 1994 where the first
statement from section 3 comes and also since 2012 where the RFC was
written. I see no sense in spending lots of work on fixing broken user
setups. If you can convince Java to support IPv6 better and switching
during runtime, we'll use it. Otherwise we expect users to use proper
networks settings.
I used to work in the ISP Business for 15 years and applications
like JOSM are the main hinderance for ipv6 acceptance.
For me the main problem are ISP's which provide broken or no IPv6
connectivity.
If a provider has broken IPv4 connectivity and does not route to certain
parts of the internet users will switch to another provider very soon.
That's a provider issue.
Same is true for IPv6 - only that here the application should be the
problem?
"It does not work when i enable ipv6" is the customer complaint
so ipv6 is kept turned off.
Correct answer would be "so I use another provider where it works".
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
_______________________________________________
josm-dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/josm-dev
