On Wednesday 29 October 2003 21:36, Pekka Savola wrote: > On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: > > I just say that this option is not *very* useful, having > > into account the problems that it has with link-local > > addresses and so on... if you fix these problems, it's > > a matter of choice, if you want to use it, just do it. > > Which problems are you referring to? I still don't understand :-(
I'm talking about the problems you've found out. 1. The problem that this option is not useful if we allow to make AAAA queries using link-local addresses. 2. The problem with the on-link assuption. 3. The problem that we are defining something that applications don't really need to have. Although I accept that it might be useulf sometimes, so this isn't a drawback. 4. The problem that if we keep the option as a flag, already deployed applications won't use it. If we fix those, I will be happy with this option. If we can not fix them, this options shouldn't be defined. > > > > 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. > > > > > > Then what? Distributed hosts file? ;-) ? > > > > ^--^ ...(after a while)... pouting (grrrr). > > > > Then what ? it's not my problem, > > Sorry for my remark, I just could not resist. What you seemed to suggest > was, "don't use DNS" without giving any reasonable alternative. That > isn't really productive either :-) That wasn't my purpose. I wanted to show that the process of initiating a connection is not as fast as turning on the telly. We have to have in mind that this flag only minimize the worst case of this process, that's all in my opinion. > > I haven't switched to IPv4 because > > the IPv6 resolver took a couple of extra roundtrip times. > > The extra roundtrip times are just the tip of the iceberg. Consider > broken DNS servers, load balancers etc. out there -- which may eat your > AAAA query for e.g. 10 seconds, causing a lot more delay than a couple of > roundtrips. That's ok, my concern is that you want to fix the issues this flag has killing the on-link assuption. That's not very constructive either. > > I see another way of fixing: > > > > If this option is problematic, don't use it. This has been proved to > > work, as a lot of applications don't use it already. > > As for AI_ADDRCONFIG, it's maybe not used because it hasn't really been > implemented that much, maybe because it has been specified in a rather > useless way (and it requires a proprietary interface between the glibc and > kernel to get the addresses, such as the getaddrinfo destination address > ordering as well; dst addr ordering hasn't been implemented that much > either).. > > > You will have to give me other arguments to kill the on-link assuption. > > Let's keep that subject to a separate thread, (the next message). Good idea. ^--^ -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
