Well, a start would be a "connectbyname()" API call that takes care of
name-to-address mapping and trying different addresses until one works.
Most IPv6-capable apps seem to implement that logic now. And in my
experience, it sucks. Really hard. The app can take a very long time
to establish a very poor connection.
If you're going to establish a poor connection, at least do it fast. :-)
And then wait for it to timeout.
The specific reason tends to be
that the destination and source both have IPv4 and IPv6 addresses, and
the IPv4 address works better than the IPv6 address (maybe because of
6to4 relay routers or whatnot), even though the v6 address is chosen
first.
We can generalize this into: when you have a choice, you're going to
make the wrong choice some of the time.
Downloading over IPv6 is still almost always slower than over IPv4,
but for day-to-day stuff the performance difference isn't an issue
with native IPv6 connectivity (for me). 6to4 is a crapshoot, it can be
reasonable or it can completely fail, with everything in between. But
it's never going to be better than native IPv4, obviously.
No, not obviously - because if the application has a need to do address
referral then there are conditions in which the 6to4 address will work
better.
But this is just an instance of the general case that some
source-destination address pairs work better than others. Address
selection heuristics don't do a good job solving this problem - to solve
this problem the network actually needs to tell the host which
source-destination address pairs will work well. (and that's pretty
ugly)
I agree that this is an important issue, but I fail to see how this
relates to applications knowing about addresses, unless applications
are going to do their own performance testing, which I don't recommend.
p2p applications are doing this already. Sure it's ugly, but they still
do it, because they have to. Applications writers would rather not
bother with it. But until the network again does a good job at
providing good performance while hiding the complexity of routing from
applications, the applications will be forced to bother with it. (The
old idea that the network provided "best effort" packet delivery service
meant that the applications really didn't have a way to improve on what
the network was doing, so they didn't bother. But in the new world of
lots of source and destination addresses, and arbitrary filtering (from
the application's view) the network is effectively no longer responsible
for providing "best effort" service. As a result, the layering breaks
down.)
So what you seem to be doing is asking application writers to accept
degraded performance and reliability in order to conform to some
arbitrary notion of purity. I don't see it happening.
Multiple addresses are a reality, not just because the IPv6 specs say
so, but also because lots of hosts are going to have at least one IPv4
address and at least one IPv6 address. Has nothing to do with purity.
Yep, and there are lots of other reasons why multiple addresses will be
there - mobility, multiple active network interfaces, encrypted tunnels,
etc. So there's going to continue to be a need for some applications
to deal with this explicitly.
The notion of purity I was referring to was the one that applications
should only deal with names and not with addresses.
On the other hand, if you make it such that application writers can get
good performance and reliability without messing with addresses, most
won't see a need to bother with the complexity. But there will still be
corner cases that will.
As I said, a good start would be that API because once applications
use it, people working on better address selection etc have a place to
insert their stuff and improve performance of real applications
without having to rewrite the application.
I spent a fair amount of time trying to come up with an API that would
let applications push this decision-making to a lower layer while
allowing that lower layer to make those decisions effectively based on
the needs of that particular application. That API ended up looking
fairly complex. There are lots of factors that influence address selection.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf