IPv6 problems

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

IPv6 problems

Greg Troxel

I'm not sure if I should file a ticket, or report this here, so I'll
start here.

I have been running JOSM for a long time, on a Mac, currently at OSX
10.7.  I have functional IPv6, but my tunnel is from OCCAID, and
occasionally some places are unreachable - currently
api.openstreetmap.org is one of them.

josm starts up and proclaims:

  INFO: Detected useable IPv6 network, prefering IPv6 over IPv4.

which is fine, but then when downloading data (simple pushing of
download icon, letting area be, and then pushing the download button in
the popup) normally, I get an API error.  I can ping
api.openstreetmap.org on v4, but not v6, where I get a network
unreachable in New York.  If I had a 2-minute delay and then a download,
there would be a more subtle happy eyeballs issue, but I totally failed
to download data a few hours ago.

Just now, I was able to download data.

So it seems that there is some notion of only trying one address family,
vs. trying all addresses in all familes in some sort order, and only
failing if all fail.

OSX itself has some version of Happy Eyeballs which uses RTT on v4 and
v6 to the address (prefix?) to decide which to try first, I think via
sorting getaddrinfo results.  I am totally unclear on how this interacts
with Java.

This can likely be reproduced by configuring nonworking IPv6.

Greg (osm user gdt)

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev

signature.asc (186 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Dirk Stöcker
On Wed, 30 Dec 2015, Greg Troxel wrote:

> I have been running JOSM for a long time, on a Mac, currently at OSX
> 10.7.  I have functional IPv6, but my tunnel is from OCCAID, and
> occasionally some places are unreachable - currently
> api.openstreetmap.org is one of them.
>
> josm starts up and proclaims:
>
>  INFO: Detected useable IPv6 network, prefering IPv6 over IPv4.

If you have a version older than 8706 you should update. If you have a
newer one read the description below.

> which is fine, but then when downloading data (simple pushing of
> download icon, letting area be, and then pushing the download button in
> the popup) normally, I get an API error.  I can ping
> api.openstreetmap.org on v4, but not v6, where I get a network
> unreachable in New York.  If I had a 2-minute delay and then a download,
> there would be a more subtle happy eyeballs issue, but I totally failed
> to download data a few hours ago.
>
> Just now, I was able to download data.
>
> So it seems that there is some notion of only trying one address family,
> vs. trying all addresses in all familes in some sort order, and only
> failing if all fail.
>
> OSX itself has some version of Happy Eyeballs which uses RTT on v4 and
> v6 to the address (prefix?) to decide which to try first, I think via
> sorting getaddrinfo results.  I am totally unclear on how this interacts
> with Java.

JOSM and Java do not try different protocols. If you (and the remote
server) have IPv6 it uses IPv6, if not IPv4.

It seems you have a broken IPv6 connection which sometimes works and
sometimes not. You should fix it.

Trying multiple connections can hide such broken connections, but most
applications don't do this. Web browsers are the main exception. JOSM not.

> This can likely be reproduced by configuring nonworking IPv6.

No. JOSM verifies if IPv6 works by testing one IPv6 connection (to JOSM
server). Thus it can detect whether IPv6 works or not.

But it cannot detect a partially broken connection and I also don't plan
to do something about this. This must be fixed on user side.

To get JOSM working with your setup set expert option "prefer.ipv6" to
"false". That simply disables IPv6.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Florian Lohoff-2
On Thu, Dec 31, 2015 at 02:44:59PM +0100, Dirk Stöcker wrote:
> JOSM and Java do not try different protocols. If you (and the remote
> server) have IPv6 it uses IPv6, if not IPv4.
>
> It seems you have a broken IPv6 connection which sometimes works and
> sometimes not. You should fix it.
t
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.

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 ...

> 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.

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

I used to work in the ISP Business for 15 years and applications
like JOSM are the main hinderance for ipv6 acceptance.

"It does not work when i enable ipv6" is the customer complaint
so ipv6 is kept turned off.

Flo
--
Florian Lohoff                                                 [hidden email]
      We need to self-defend - GnuPG/PGP enable your email today!

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Greg Troxel
In reply to this post by Dirk Stöcker

I should clarify: My IPv6 setup is working fine.  The problem is that my
upstream ISP has routes to most parts of the v6 world but is missing a
few, I'm guessing due to a peering dispute.  This is the same sort of
thing that can happen in v4, although I think it is less common.  So
this is a "internet connectivity problem in the core", not setup issues
on my end.





_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev

signature.asc (186 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Dirk Stöcker
In reply to this post by Florian Lohoff-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Dirk Stöcker
In reply to this post by Greg Troxel
On Thu, 31 Dec 2015, Greg Troxel wrote:

> I should clarify: My IPv6 setup is working fine.  The problem is that my
> upstream ISP has routes to most parts of the v6 world but is missing a
> few, I'm guessing due to a peering dispute.  This is the same sort of
> thing that can happen in v4, although I think it is less common.  So
> this is a "internet connectivity problem in the core", not setup issues
> on my end.

Actually that's what I would call a broken IPv6. If that happens for IPv4
you would switch to another provider. For IPv6 you assume the application
should fix it. JOSM does not offer that feature due to the missing support
for this in main Java and not enough reasons to reimplement that
ourselves.

Another solution compared to disabling IPv6 totally would be to add the
IPv4 addresses of the non-working servers to your /etc/hosts (path correct
for Mac?). This changes the resolvers answers, so JOSM will not know that
these serves have IPv6 and also not try it for these, but for all the
others.

Anyway the correct solution would be to get your provider to fix the
routing or change provider.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Florian Lohoff-2
In reply to this post by Dirk Stöcker
On Thu, Dec 31, 2015 at 11:09:24PM +0100, Dirk Stöcker wrote:
> >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.

But this is simply a broken advise - We want ipv6 and all RFCs
have been written with transition in mind. You are now telling
here is this app called JOSM and whenever you are on ipv6 turn
it off because it might cause problems.

This is exactly what the authors of all the RFCs tried to prevent.
You are now causing a bad reputation on ipv6 although
the application is simply not constructed with the Best Common
Practices.

> 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.

> 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.

> 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.

Happy Eyeballs is the continuation of fallback logic refinement.

> 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.

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.

Just as one of the examples

http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.de/110207

So please - either fix ipv6 in JOSM by implementing the BCPs or
drop the ipv6 support completely - Currently you are breaking tons
of user setups and you actively blame ipv6 for it.

> For me the main problem are ISP's which provide broken or no IPv6
> connectivity.

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 i suspend, drive to work, resume and my setup is broken because
i dont have ipv6 at work but josm caches it knowledge which it shouldnt.

JOSM tries to be very clever and tries to detect if it has
IPv6 connectivity and caches the knowledge. THIS IS BROKEN ALREADY.
EVERY single connection needs the fallback logic for itself without
cached prior knowledge of the environment.

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.

This is 80ies - "You have moved your mouse - please reboot"

Flo
--
Florian Lohoff                                                 [hidden email]
      We need to self-defend - GnuPG/PGP enable your email today!

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Simon Legner
Hi!

On Fri, Jan 1, 2016 at 12:47 AM, Florian Lohoff <[hidden email]> wrote:
> 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.

> So please - either fix ipv6 in JOSM by implementing the BCPs or
> drop the ipv6 support completely - Currently you are breaking tons
> of user setups and you actively blame ipv6 for it.

I tried to find some reference implementations for the RFC6555 / Happy
Eyeballs in Java – without success. None of the popular HTTP client
libraries [1, 2, 3] seem to have any support for this algorithm.
Instead, they seem to attempt connections sequentially to the resolved
addresses [4, 5].

On GitHub I could only find two Java demo projects on the
java.net.Socket level [6, 7].

Best regards,
Simon

[1] https://github.com/apache/httpclient
[2] https://github.com/eclipse/jetty.project
[3] https://github.com/square/okhttp/issues/506
[4] https://github.com/apache/httpclient/blob/be46d7fd93c7e3e576d739bb3ef40f4d2cf5e491/httpclient/src/main/java/org/apache/http/impl/conn/DefaultHttpClientConnectionOperator.java#L97-L171
[5] https://github.com/eclipse/jetty.project/blob/915a905df4dc19234938111095ea659b5deae5ce/jetty-client/src/main/java/org/eclipse/jetty/client/HttpClient.java#L538-L580
[6] https://github.com/ecki/IPv6Con/blob/master/src/main/java/net/eckenfels/ipv6con/SampleHappyEyeballs.java
[7] https://github.com/guinamen/Java-Happy-Eyeballs

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Dirk Stöcker
In reply to this post by Florian Lohoff-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Florian Lohoff-2
In reply to this post by Simon Legner
On Fri, Jan 01, 2016 at 01:09:30PM +0100, Simon Legner wrote:

> Hi!
>
> On Fri, Jan 1, 2016 at 12:47 AM, Florian Lohoff <[hidden email]> wrote:
> > So please - either fix ipv6 in JOSM by implementing the BCPs or
> > drop the ipv6 support completely - Currently you are breaking tons
> > of user setups and you actively blame ipv6 for it.
>
> I tried to find some reference implementations for the RFC6555 / Happy
> Eyeballs in Java – without success. None of the popular HTTP client
> libraries [1, 2, 3] seem to have any support for this algorithm.
> Instead, they seem to attempt connections sequentially to the resolved
> addresses [4, 5].
>
> On GitHub I could only find two Java demo projects on the
> java.net.Socket level [6, 7].
Its not about Happy Eyeballs as the real and only solution. Best Common
Practice is whenever you isse a connection and you get AAAA and A
records you try AAAA first and if they fail you fall back to A records
e.g. IPv6 first. This is the fundamental principle of IPv6 introduction
and transition. You NEED people to first try v6 as you want the traffic
to transition to the new protocol. IPv4 is DEAD - No RIR has v4 adresses
anymore so there will be no new Companys with v4 connectivity. Get
over it.

Currently josm tries to be clever and either does v6 or v4 and tries
to detect whether the host is v6 enabled. This is broken by design.
You cant detect whether you will be able to issue v6 connections
until you try. There are v6 blackholes in the internet, there is
intermittet connectivity, there are ULA prefixes which is just an v6
island whathever. Its the INTERNET - Everything is built on a "best
effort" base. It may work - it may also not. IPv6 put the responsibility
for the user experience in the hands of application writers by making
strong recommendations on how to write your applications. If it fails
because the application is broken people turn off ipv6 and will never
ever turn it back on because of bad reputation. This will hurt
IPv6 adoption and in the end will hurt us all.


I had all sorts of tricks in my josm startup scripts in the past years to
tell josm to ignore v6 - to always enable ipv6 etc. First versions of
josm even thought they would be ipv6 enabled if there were a ::1 on
the lo interface. So the josm startup script included a

        "ifdown lo; josm &; sleep 30; ifup lo"

That got fixed - now i have the issue that i need to restart josm when i
move to a different network. Need to run tcpproxy in the background
to let josm connect to the tracer server because it does not do a ipv4
fallback etc..

There are even more broken assumptions in josm. I live in the rural
outback and i have 348kbit/s - Sometimes on josm startup it fails to
fetch the motd or mappaint styles or whetever it tries to do on startup.
Some requests on startup timeout because my line is congested. This
causes josm to refuse to do ANY network interaction afterwards. You cant
download data etc etc. Sometimes i need to start josm 3-4 times until it
actually is willing to play with me. This never happens on a VDSL
50MBit/s connection etc.

I really ask myself how the HOT people work around those issues. Network
connectivity isnt even perfect in Germany, and is most likely even more
flaky in HOT areas. Is josm actually usable without internet
connectivity - editing offline files?

Flo
--
Florian Lohoff                                                 [hidden email]
      We need to self-defend - GnuPG/PGP enable your email today!

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Dirk Stöcker
In reply to this post by Simon Legner
On Fri, 1 Jan 2016, Simon Legner wrote:

> I tried to find some reference implementations for the RFC6555 / Happy
> Eyeballs in Java – without success. None of the popular HTTP client
> libraries [1, 2, 3] seem to have any support for this algorithm.
> Instead, they seem to attempt connections sequentially to the resolved
> addresses [4, 5].

Beside browsers nearly no software uses Happy Eyeballs as far as I know.
Most software only does a single connect for a single IP. Some rotate the
IP's, so each attempt tries another one. Some try one after another and so
on.

All of these multi-connect mechanisms are workarounds. E.g. what do you do
when you have a bad setup, where IPv6 connection is fine, but goes to the
wrong destination. When do you decide that IPv4 must be used in this case.

That was a scenario I did see some often years ago with umanaged IPv6
setups and service moving to another server without changing also the IPv6
address.

Opening a TCP connection can become extremely complex when you want to
care for all the possible misconfigurations.

We did not add multi-connect attempts for IPv4 only networks, why should
we do it now? All IPv6 cases we had until now have been clearly broken
connectivity. We can spend a lot of time to hide these errors, but what's
the result? Will the users fix their setup? No.

I know these issues from 8 years ago when I started support for IPv6.
Broken setups, providers not monitoring outages of IPv6, broken routes,
... It's 8 years later now! You can buy working IPv6 connectivity. I don't
see such IPv6 specific errors anymore today. Hiding the errors which
occur with other providers wont help in my eyes - only fixing them is
right.

BTW the stats say: Google has 10% IPv6 now. We have about 2%. I'd say it
works when I compare this to other HTTP based services which I run which
are in the 0.x% range still.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Dirk Stöcker
In reply to this post by Florian Lohoff-2
On Fri, 1 Jan 2016, Florian Lohoff wrote:

> Currently josm tries to be clever and either does v6 or v4 and tries
> to detect whether the host is v6 enabled. This is broken by design.
> You cant detect whether you will be able to issue v6 connections
> until you try. There are v6 blackholes in the internet, there is
> intermittet connectivity, there are ULA prefixes which is just an v6
> island whathever. Its the INTERNET - Everything is built on a "best
> effort" base. It may work - it may also not. IPv6 put the responsibility

That's nonsense. If you extend the meaning of "best effort" to "it may
work or not" then it's ok when a provider only delivers data to half of
the world? Well, why pay money for devlivery the other half?

A network access which has permanent connectivity issues is broken!

If you go into the future you will have IPv6 only. No IPv4 fallback. And
it has to work. Yes - we currently have a chance to try again with IPv4
and JOSM doesn't use that chance. Well, JOSM doesn't do many other things
as well.

But telling me that it's JOSM's fault that providers are incapable to do
their work properly is nonsense.

> for the user experience in the hands of application writers by making
> strong recommendations on how to write your applications. If it fails
> because the application is broken people turn off ipv6 and will never
> ever turn it back on because of bad reputation. This will hurt
> IPv6 adoption and in the end will hurt us all.

As said. If it does not work, then it's a providers fault. I see that
someone coming from an ISP doesn't want to hear that, but providing a
broken connectivity is not an application issue.

> There are even more broken assumptions in josm. I live in the rural
> outback and i have 348kbit/s - Sometimes on josm startup it fails to
> fetch the motd or mappaint styles or whetever it tries to do on startup.
> Some requests on startup timeout because my line is congested. This
> causes josm to refuse to do ANY network interaction afterwards. You cant
> download data etc etc. Sometimes i need to start josm 3-4 times until it
> actually is willing to play with me. This never happens on a VDSL
> 50MBit/s connection etc.

I don't remember a report about such behaviour. Please tell me the ticket
number.

I also don't believe that's a JOSM issue, as JOSM does not remember any
states between connections. Maybe your connection is simply to slow and
you need to increase the timeouts so it works for your system. JOSM uses
reasonable timeouts for modern connections of half a minute. That should
be enough also for a 348kbit/s connection.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Philip Homburg-5
> may work or not" then it's ok when a provider only delivers data
> to half of the world? Well, why pay money for devlivery the other
> half?
>
> A network access which has permanent connectivity issues is broken!
>
> If you go into the future you will have IPv6 only. No IPv4 fallback.
> And it has to work. Yes - we currently have a chance to try again
> with IPv4 and JOSM doesn't use that chance. Well, JOSM doesn't do
> many other things as well.
>
> But telling me that it's JOSM's fault that providers are incapable
> to do their work properly is nonsense.

As an IPv6 hacker and JOSM user (I don't know about the internals of JOSM):
- If a network has a permanent problem to reach a particular destination,
  then that's network problem not the application's. In IPv6 land, there is
  the unfortunate Cogent/Hurricane Electric issue. The only option is to
  connect to both. However, transient errors may still occur.
- Ideally, operating systems should ship with a happy eyeballs implementation
  in the C library. I don't know any that does. It is not such a great idea
  for applications to roll their own. Mostly because you may want knobs to
  configure things system wide.
- All applications should loop over all addresses returned by getaddrinfo.
  There is simply no excuse not to. If java makes it impossible to iterate
  over all addresses that it is java that is horribly broken.

Just my few cents.


_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Dirk Stöcker
On Fri, 1 Jan 2016, Philip Homburg wrote:

> - Ideally, operating systems should ship with a happy eyeballs implementation
>  in the C library. I don't know any that does. It is not such a great idea
>  for applications to roll their own. Mostly because you may want knobs to
>  configure things system wide.

For C there probably are libraries.

> - All applications should loop over all addresses returned by getaddrinfo.
>  There is simply no excuse not to. If java makes it impossible to iterate
>  over all addresses that it is java that is horribly broken.

I disagree here. ATM most services only have one IPv4 address. In the
transition time between protocols many will have IPv4 AND IPv6 but in the
near future (let's say 5-10 years) most will either have IPv4 OR IPv6 and
dual stack will slowly fade out.

And it's not so easy to handle multiple connects. You can either optimize
for speed (open multiple connections parallel) or for load (open one after
the other) or ignore it (single connect) or randomly choose an address
(e.g. what postfix does). All of these methods have advantages and
disadvantages and depend on the application.

And it's not so easy to decide when a connection works or not, as it can
fail on multiple levels and so on and so on. Many programs are extremely
simple and implementing a full featured we-try-all network access is total
overkill. So also in the future the majority of tools will only open one
connection and try once. It's wishful thinking to assume otherwise.

For our company applications it took me a lot of time and experience to
create a non-blocking non-threading portable C network library to cope
with the many existing issues. I know how much work that involves both in
the application and the libraries.

Thus the main question here is if parallel connects are important
enough, so that JOSM needs to support that feature or not. Currently I
think not.

We have a number of network issues with the Java network code beside the
rather ugly IPv6 handling and maybe in the future we'll replace it with
another library and maybe that will include algorithms for multiple
connects. The question already came up in a recent ticket. But that's a
lot of work and also does not magically solve all the problems.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Philip Homburg-5
> > - Ideally, operating systems should ship with a happy eyeballs implementati
> on
> >  in the C library. I don't know any that does. It is not such a great idea
> >  for applications to roll their own. Mostly because you may want knobs to
> >  configure things system wide.
>
> For C there probably are libraries.

Yes, but if they are non-standard it is unlikely that java will pick them up.
And it should be a standard library for the OS. Having multiple libraries
increases the pain if you need to configure something.

> > - All applications should loop over all addresses returned by getaddrinfo.
> >  There is simply no excuse not to. If java makes it impossible to iterate
> >  over all addresses that it is java that is horribly broken.
>
> And it's not so easy to handle multiple connects. You can either
> optimize for speed (open multiple connections parallel) or for load
> (open one after the other) or ignore it (single connect) or randomly
> choose an address (e.g. what postfix does). All of these methods
> have advantages and disadvantages and depend on the application.

It is really simple. An application should do nothing more than trying each
address in turn in the order returned by getaddrinfo. Either connect(2)
succeeds and you are done or there is a failure and you try the next address.

Trying to open connections in parallel enters happy eyeballs teritory.
Experience shows that it is hard to get right, so it is better to leave that
to a system library.

Note that happy eyeballs is only required if the first address causes a
timeout most of the time. Otherwise, it is much better have have to sit
through the occasional timeout than the have an application that gives up
after trying just the first address.

Trying only one address has been bad practice since before IPv6 was even
invented.

Of course, tweaking /etc/gai.conf to prefer IPv4 over IPv6 is also an option.
(Assuming java uses getaddrinfo under the hood)

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Dirk Stöcker
On Fri, 1 Jan 2016, Philip Homburg wrote:

> It is really simple. An application should do nothing more than trying each
> address in turn in the order returned by getaddrinfo. Either connect(2)
> succeeds and you are done or there is a failure and you try the next address.

That does cause large timeouts in todays internet where packets are often
dropped and not rejected. This is no option for JOSM in that easy
configuration. To get it working an implementation must be more complex.

> Trying only one address has been bad practice since before IPv6 was even
> invented.

I disagree.

> Of course, tweaking /etc/gai.conf to prefer IPv4 over IPv6 is also an option.
> (Assuming java uses getaddrinfo under the hood)

Sadly Java does not follow this, but only has an option to say in advance
whether IPv6 or IPv4 addresses should be preferred. And then it follows
that rule ignoring the OS and the fact whether it works or not. And you
cannot change this without a restart of the tool.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Florian Lohoff-2
In reply to this post by Dirk Stöcker
On Fri, Jan 01, 2016 at 09:12:50PM +0100, Dirk Stöcker wrote:

> On Fri, 1 Jan 2016, Philip Homburg wrote:
>
> >- Ideally, operating systems should ship with a happy eyeballs implementation
> > in the C library. I don't know any that does. It is not such a great idea
> > for applications to roll their own. Mostly because you may want knobs to
> > configure things system wide.
>
> For C there probably are libraries.
>
> >- All applications should loop over all addresses returned by getaddrinfo.
> > There is simply no excuse not to. If java makes it impossible to iterate
> > over all addresses that it is java that is horribly broken.
>
> I disagree here. ATM most services only have one IPv4 address. In
> the transition time between protocols many will have IPv4 AND IPv6
> but in the near future (let's say 5-10 years) most will either have
> IPv4 OR IPv6 and dual stack will slowly fade out.
Thats 30 years timeframe - And Multi A or AAAA record is a common
usage for load balancing. Just in case you havent seen it:

flo@p3:~$ host api.openstreetmap.org
api.openstreetmap.org has address 193.63.75.99
api.openstreetmap.org has address 193.63.75.100
api.openstreetmap.org has address 193.63.75.103
api.openstreetmap.org has IPv6 address 2001:630:12:500:219:bbff:fe39:8aba
api.openstreetmap.org has IPv6 address 2001:630:12:500:21a:4bff:fea5:fd2a
api.openstreetmap.org has IPv6 address 2001:630:12:500:219:bbff:fe39:3d9e

> And it's not so easy to handle multiple connects. You can either
> optimize for speed (open multiple connections parallel) or for load
> (open one after the other) or ignore it (single connect) or randomly
> choose an address (e.g. what postfix does). All of these methods
> have advantages and disadvantages and depend on the application.

Okay - When you ask your DNS the DNS is rotating the results for you.
Thats been best common practice for nearly as long as there is DNS.

flo@p3:~$ dig +short -t ANY api.openstreetmap.org @a.ns.bytemark.co.uk.
193.63.75.99
193.63.75.103
193.63.75.100
2001:630:12:500:21a:4bff:fea5:fd2a
2001:630:12:500:219:bbff:fe39:3d9e
2001:630:12:500:219:bbff:fe39:8aba
flo@p3:~$ dig +short -t ANY api.openstreetmap.org @a.ns.bytemark.co.uk.
193.63.75.100
193.63.75.103
193.63.75.99
2001:630:12:500:219:bbff:fe39:3d9e
2001:630:12:500:21a:4bff:fea5:fd2a
2001:630:12:500:219:bbff:fe39:8aba

As the application author you are supposed to  try the ipv6 and then the ipv4
in order of appearance. If you do so everything is fine. If you try to be clever
hell breaks loose with all sorts of problems.

This is what i had when one of the APIs went dodo some weeks ago. I wasnt able
to upload my changes with JOSM. So i used dig to find a working address
and hardcoded it in the /etc/hosts because josm refused to try a different
address.

> And it's not so easy to decide when a connection works or not, as it
> can fail on multiple levels and so on and so on. Many programs are

Its easy - does a connect work? Its as easy as that.

> extremely simple and implementing a full featured we-try-all network
> access is total overkill. So also in the future the majority of
> tools will only open one connection and try once. It's wishful
> thinking to assume otherwise.

Under most circumstances the very first connect will work and you are
done. All others may take some seconds but still work. Right now
the 1% fails - and fails in a way intransparent for users and undebuggable.

> Thus the main question here is if parallel connects are important
> enough, so that JOSM needs to support that feature or not. Currently
> I think not.

Its not about parallel connections - its about trying the other adresses
you are told to use.

Flo
--
Florian Lohoff                                                 [hidden email]
      We need to self-defend - GnuPG/PGP enable your email today!

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Florian Lohoff-2
In reply to this post by Dirk Stöcker
On Fri, Jan 01, 2016 at 02:03:57PM +0100, Dirk Stöcker wrote:

> On Fri, 1 Jan 2016, Florian Lohoff wrote:
>
> >Currently josm tries to be clever and either does v6 or v4 and tries
> >to detect whether the host is v6 enabled. This is broken by design.
> >You cant detect whether you will be able to issue v6 connections
> >until you try. There are v6 blackholes in the internet, there is
> >intermittet connectivity, there are ULA prefixes which is just an v6
> >island whathever. Its the INTERNET - Everything is built on a "best
> >effort" base. It may work - it may also not. IPv6 put the responsibility
>
> That's nonsense. If you extend the meaning of "best effort" to "it
> may work or not" then it's ok when a provider only delivers data to
> half of the world? Well, why pay money for devlivery the other half?
Welcome to my world. I have been dealing with issues like that
for 20 Years ... Upstream providers depeering other Tier 1s because
of business issues and the regional ISPs looking for alternative paths.

> A network access which has permanent connectivity issues is broken!

As a residential customer this might be the case. Not in the ISP
world. There are legions of people worldwide trying their
best to keep the net working. Tuning paths that the residential
customer paying 9.95€ does not see the packet loss occuring
on the opposite site of the world.

This was always in the commercial ages of the internet for like
decades. When i started my own ISP Business in the very early 90ies
we had the issues with DFN and all others. It went that far
that XLink had its last hop toward dfn added a PTR

        1.2.3.4 IN PTR ab.hier.wirds.langsam.weil.dfn.de

> If you go into the future you will have IPv6 only. No IPv4 fallback.
> And it has to work. Yes - we currently have a chance to try again
> with IPv4 and JOSM doesn't use that chance. Well, JOSM doesn't do
> many other things as well.

IPv4 will not go away. It will stay with us for at least 30 years.
Remember that there are billions of devices deployed world wide
which dont have the flash codespace to support ipv6.

The access technology will change. Today we have Dualstack. Cable
operators have switched to DS Light tunneling ipv4 via ipv6 (Kabel
Deutschland). Most likely the Cell providers will do DS Light
aswell as their pricing/capacity is build around the number of
datapipes and v4 and v6 are seperated.

Flo
--
Florian Lohoff                                                 [hidden email]
      We need to self-defend - GnuPG/PGP enable your email today!

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

DNS timeout/fail on startup Was: IPv6 problems

Florian Lohoff-2
In reply to this post by Dirk Stöcker
On Fri, Jan 01, 2016 at 02:03:57PM +0100, Dirk Stöcker wrote:
> I also don't believe that's a JOSM issue, as JOSM does not remember
> any states between connections. Maybe your connection is simply to
> slow and you need to increase the timeouts so it works for your
> system. JOSM uses reasonable timeouts for modern connections of half
> a minute. That should be enough also for a 348kbit/s connection.

I just tried to reproduce:

Just let the very first DNS request for josm.openstreetmap.org
fail/timeout - You get a popup "Network errors occured"
and "Change proxy setting". This is abolute nonesense. I dont
use any proxy - A simple DNS query failed - Thats life. I might
even be offline - that would be perfectly allright.

I could use josm afterwards pressing cancel on the "Change proxy
settings" but i have situation where this does not work and
i cant up-/download data.

Flo
--
Florian Lohoff                                                 [hidden email]
      We need to self-defend - GnuPG/PGP enable your email today!

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 problems

Dirk Stöcker
In reply to this post by Florian Lohoff-2
On Sat, 2 Jan 2016, Florian Lohoff wrote:

>> If you go into the future you will have IPv6 only. No IPv4 fallback.
>> And it has to work. Yes - we currently have a chance to try again
>> with IPv4 and JOSM doesn't use that chance. Well, JOSM doesn't do
>> many other things as well.
>
> IPv4 will not go away. It will stay with us for at least 30 years.
> Remember that there are billions of devices deployed world wide
> which dont have the flash codespace to support ipv6.

Somewhen in the near future you either will have an address translation
between IPv4 and IPv6 or you wont be able to access many newer servers and
services from your IPv4 devices. Dual stack is a lot of additional work
and as soon as the percentage of IPv6 adoption goes over a certain level
you will get more and more IPv6 only services.

In 10 years timeframe nobody cares about most of todays devices. A lot of
them will be thrown away in 3 years already. They simply don't count.

The question is not whether IPv4 will remain or not, but if an IPv4 only
network access will be able to reach a majority of targets. And I doubt
that will be the case in 10 years looking at the IPv6 adoption rates
in the last years. I'm personally already deploying IPv6 only services
today.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

_______________________________________________
josm-dev mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/josm-dev
12