On Wednesday 29 October 2003 08:26, Pekka Savola wrote: > On Wed, 29 Oct 2003 [EMAIL PROTECTED] wrote: > [...] > > > >Remember, the most important thing we should care about is that > > > dual-stack deployments can get more common without causing problems for > > > *IPv4* or services in general. AI_ADDRCONFIG is one step in that > > > direction. > > > > for your story to be effective it has to be host-wide configuration > > knob, not a parameter to library function. (we cannot change every > > program we use to have AI_ADDRCONFIG) > > Yep, or the apps writing guidelines could recommend to turn it on. The > basic API spec already defines "AI_DEFAULT" even though it doesn't (AFAIR) > specify that it should be the default :-) > > > and we (*BSD groups) ship programs without AI_ADDRCONFIG, and they > > work just fine... > > Yep, to the extent they're used. Stig already mentioned that some apps > are moving to some custom address lookup hacks from getaddrinfo() due to > these problems. The use of AI_ADDRCONFIG should help in the majority of > cases, i.e., deploying v6-capable apps on nodes which don't have v6 > connectivity yet.
I agree with Pekka because it might help to new deployed/ported applications to improve their response times of DNS queries. On the other hand, I think that applications which query the DNS shouldn't be real-time applications, so I see this feature is not very useful. If I understood Stig well, he said that people was turning off IPv6 because of delaying issues. Doing that is not an option if you want to allow your app. to run over "IPv6 AND IPv4". If you can not cope with such delays, maybe you shouldn't be using the DNS at all. The problem here is that most of the times this feature will fail back to the worst case, which is the normal getaddrinfo behaviour, because it's not as easy as checking for global IPv6 configured address, as Itojun has already said. We might come up with a lot of scenarios where this option might fail to improve the response time (e.g: only link-local addresses, global addresses but no default route, proper link local IPv6 configuration but some black-hole on outer routers.....). So...why do we bother ? Thinking about a feature that most of the times will do nothing special is not worthy be implemented. We (*BSD users) feel that applications work just fine without this. -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
