Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

[Pekka Savola <pekkas@netcore.fi>]

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