On 20-sep-2007, at 14:52, Keith Moore wrote:
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. :-)
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.
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.
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.
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.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf