[josm-dev] IPv6 problems

[Dirk Stöcker]

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)