Re: Comments on addr-select-sol

[Arifumi Matsumoto <arifumi@nttv6.net>]

Thank you for your comment.
This is the 1st comment I received on list for this draft :)

Rémi Denis-Courmont wrote:
> 	Hello,
>
> Been reviewing the draft, and I am a bit puzzled as to why the 
> implementability and compatibility with RFC3493 falls in the "other issues" 
> category.
> Most IPv6-enabled applications are currently relying on getaddrinfo then 
> connect/sendto APIs, or variants thereof. getaddrinfo() queries DNS or 
> whatever, and gives an ordered list of possible destination address, then 
> connect() or sendto() decide which source address to use to reach a given 
> destination. It might be worth noting that sendto() is non-blocking, so 
> essentially any exchange with the network has to be done in getaddrinfo().
> Now, that still leaves a lot of room for doing lots of fancy and advanced 
> stuff in getaddrinfo(), along the DNS query. But I think it is worth looking 
> deeper at. I do think we should avoid deprecating RFC3493 unless there is 
> really a very very compelling reason to do so.
Good point.
I had no idea how to set-up a requirement item that covers "other 
issues". "compability with RFC3493" looks like a good requirement item.
> I am a bit suspicious as to whether the "trial-and-error" approach can 
> actually work with these considerations in mind.
IMO, trial-and-error approach can work with RFC3493.
You may suppose that the kernel changes the source address of the
existing connections, but it doesn't. The kernel just stores cache
for successful/unworkable address selection and utilize it for the
next address selection.

Rather, I am suspicious about "question-and-answer" approach about
this point. How can we implement that in getaddrinfo() without
changing the APIs ?