[josm-dev] IPv6 problems
openstreetmap at dstoecker.de
Fri Jan 1 12:42:31 UTC 2016
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
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
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
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.
http://www.dstoecker.eu/ (PGP key available)
More information about the josm-dev