[josm-dev] IPv6 problems

Florian Lohoff f at zz.de
Sat Jan 2 13:12:38 UTC 2016


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 at 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 at 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 at 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                                                 f at zz.de
      We need to self-defend - GnuPG/PGP enable your email today!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.openstreetmap.org/pipermail/josm-dev/attachments/20160102/5a2d1084/attachment.sig>


More information about the josm-dev mailing list