If you can find a good way to let hosts and network stacks sort out
those addressing issues, then fewer applications will bother to manage
those addresses themselves. But absent such a way to do that (and
trial-and-error is not a good way, nor is IPv6 "address selection") then
more applications will be forced to manage those addresses in order to
provide decent service to users.
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. 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. 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)
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.
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.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf