>> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf