On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote: [snip] > > Sorry but I don't catch this point. Maybe we are talking either > about different things or the same things, I'm not sure. > I will try to set up an specific example, talking about the right > behaviour we should expect of this stuff. > > If you make a getaddrinfo() call with AF_UNSPEC and AI_ADDRCONFIG on a > machine with dual-stack support, full IPv4 connectivity and only IPv6 link > local addresses, this should run as follows: > > 1. Interacting with the DNS over IPv4, but it will ask only for A r.records. > 2. Connecting using IPv4, no problem. > > If you've got the same scenario, but you don't use AI_ADDRCONFIG: > > 1. Interacting with the DNS over IPv4, it will return AAAA and A records. > 2. Trying to connect with an IPv6 global address. This should fail > inmediately (we don't have the delay that onlink assuption causes...) > with "no-route-to-host". > 3. A well-programmed app. would try with the IPv4 address, end up with > a conexion. > > Where are the "unnecesary DNS lookups" you are talking about ? > I think that you receive both AAAA and A records on the same unique query, > don't you ?
Look at the details of item "1." in each case. There are multiple when queries multiple records are asked/responded. (On the other hand, with properly augmented AI_ADDRCONFIG, you could omit everything relating to AAAA records, causing optimization.) For example, this roughly what happens when you do try look up "psg.com" with getaddrinfo using PF_UNSPEC: 23:48:31.909344 80.186.150.55.1836 > 193.229.0.40.53: [udp sum ok] 1651+ AAAA? psg.com. (25) (ttl 64, id 27243, len 53) 23:48:31.920410 193.229.0.40.53 > 80.186.150.55.1836: [udp sum ok] 1651 q: AAAA? psg.com. 1/0/0 psg.com. AAAA 2001:418:1::62 (53) (DF) (ttl 251, id 17061, len 81) 23:48:31.920892 80.186.150.55.1837 > 193.229.0.40.53: [udp sum ok] 1652+ A? psg.com. (25) (ttl 64, id 27244, len 53) 23:48:31.930985 193.229.0.40.53 > 80.186.150.55.1837: [udp sum ok] 1652 q: A? psg.com. 1/0/0 psg.com. A 147.28.0.62 (41) (DF) (ttl 251, id 46142, len 69) Two roundtrips. Three if you do A6 as well :-), and even more if you have to look up the delegation paths as well. Note: I'm using a forwarding nameserver here -- in practice, the roundtrips would take much longer if nothing would be cached (the DNS server I'm pointing my resolver to already has everything about psg.com cached.). I did a test: tried to do a TCP connect to www.6bone.net. From the first DNS query packet sent out, it took 1.528 _seconds_ for the fist TCP packet to go out! The first AAAA record arrived after 0.915 seconds (a lot in itself). That gives a measure of how much (at least) it would be faster with IPv4-only. Over 50% additional delay, and it could be worse if the delegation path DNS servers have AAAA records which are not cached. Only after all the responses have been received, the TCP connection is established. After all, you have to run the default address selection on all the results. This feature of DNS lookups certainly should be spelled out if/when we add AI_ADDRCONFIG considerations to the v6onbydefault document, as it clearly isn't apparent.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
