Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 21:05:32 +0200 (EET)

On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote:
> 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. 

How do you see people browsing the web get to the websites then, if not 
using DNS?  That's enough realtime in my book -- the user waits while the 
request(s) is being processed.

I really don't understand what you're trying to say..

> 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? ;-) ?

> 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.....). 

I fail to see the point here:

 - if only link local addresses: fixed AI_ADDRCONFIG would fix

 - if global but no default route:
    a) without the on-link assumption: automatic immediate no route 
       message and fallback to the next address
    b) with (current) on-link assumption: problematic (which is why the 
       assumption must be killed :-)

 - if global, default route, but blackhole somewhere:
      silently discarding packets is evil practice anyway and nothing can 
      be done about that, whether in case of v4 or v6.

 - if global, default route, everything works, but some DNS server munges
      the AAAA queries: can't help with that, but because v6 would be 
      used, that has to be fixed by fixing the servers anyway.

.. so my perception is that this would fix all the problems related to
partial IPv6 deployment I could think of w/ the elimination of the on-link
assumption pretty well.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 22:36:38 +0200 (EET)

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 :-(

> > > 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.
> >
>  ^--^ ...(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 :-)

> 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.

> 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).

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Oct 2003 19:33:49 +0200 (EET)

On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote:
> I'm talking about the problems you've found out.

I still don't understand what you're talking about, but I'll respond to 
two points below..

Perhaps it'd be useful to try to characterize these issues as problems
without presupposing the solutions *).  I'd encourage you to try if you
want to find alternative solutions.

*) for example:

When a dual-stack node whose IPv6 stack has been enabled is deployed on a
link where there is no IPv6 connectivity (no IPv6 router, no tunneling
mechanism), trying to connect to a global IPv6 address, obtained either
manually or from the DNS, results significant delays, due to the on-link
assumption.  How to fix this?

When an application has been configured to try both IPv4 and IPv6 
("AF_UNSPEC") when performing a connection and DNS lookups, a number of 
useless lookups are made when an IPv4-only nodes query for IPv6 DNS 
records, or IPv6 nodes without connectivity (see above) similarly query 
for IPv6 records.  How to best determine which records don't need to be 
queried?

> 1. The problem that this option is not useful if we allow to 
> make AAAA queries using link-local addresses.

Perhaps you miswrote, but that's very far from from the problem.  The 
problem is that a node asks for AAAA and A records with an app 
configured "AF_UNSPEC" even if it has only IPv6 loopback and link-local 
addresses.  The resulting AAAA records will be pretty much useless unless 
one assumes it's OK to return link-local addresses from the DNS (or 
similar other naming service), and the general purpose apps to use them.

> 4. The problem that if we keep the option as a flag, already
> deployed applications won't use it.

So what?  Applications are updated regularly.  This would actually be a
good reason to issue a minor update: a performance+ robustness enhancement
for those which don't have full v6 connectivity.

> 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 think the analogue is entirely different.  The people expect the 
connections to form immediately, without waiting.  On the other hand, 
turning on a telly takes a while (the screen is dark, but gets lighter, 
and is OK in 10-15 seconds; the same with monitors).

We can do better than that.  And as connections are established dozens, 
hundreds or thousands of times a day, the time savings are singificant.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Oct 2003 22:02:25 +0200 (EET)

Note: at the end of the message, there is also a description of an another 
problem, partially described in draft-ietf-v6ops-v6onbydefault-00.txt.

On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote:
> On Thursday 30 October 2003 18:33, Pekka Savola wrote:
> (I wonder why onlink assumption was included in the spec, but that's
> another story....)
> 
> Ok, so if we get rid of the onlink-assumption, there won't be such 
> delay, is this right ?. 

Yep, the delay is eliminated (as far as I can see).

> if the host answers with "no route to destination" or something like that,
> (we don't have onlink assuption any more, remember), 
> this is fixed, the penalty for those extra IPv6 connection attempts will be as 
> tiny as my wage.

This is a separate problem.  What I was worried in above is eliminating
the unnecessary DNS lookups.

Your problem may be something like:

When an application has been configured to try both IPv4 and IPv6
("AF_UNSPEC"), the results of the query are tried in some order, typically
IPv6 first.  When the destination is unreachable, an error should be
returned.  How to make falling back to the next address robust?

.. straying to the solutions side, you may want to consider e.g.:

 a) avoiding such connection attempts in the first place, i.e., with
minimal complexity there is only minimal chance of someone misbehaving and
something getting broken!
 b) ensuring somehow that you always get the ICMP message and the 
connect() (or similar code) reacts to it, that is, you get a feedback 
signal back from the system when the attempt fails.  This is actually a 
big potential problem.  Consider firewalls which discard (instead of send 
ICMP unreachable) packets.  This could trigger a TCP timeout.. (see more 
at the end)
 c) ....

> This is my major concern now, so I would be glad to hear your opinion 
> about this.

See above.  This is also a major potential problem (it isn't now, because 
IPv6 is only deployed by mostly clueful folks, but if the masses do it and 
use e.g. firewalls w/ silent discard, we could end up in a loooooot of 
trouble..)

[snip -- to a description of a different issue]

> I've also experienced a problem which I think doesn't have a
> solution (at least a solution the host could implement). For example:
> 
> I'm using the latest web browser, which it's already using this flag
> because the developers are really smart and they are use to 
> trying more than one destination address (this still doesn't happen
> on my Konqueror 3.1.4).
> 
> I try to connect to "www.6bone.net", I receive both AAAA and A.
> 
> My network is IPv6/IPv4, so I have no connectivity problems, and
> my web tries to connect to IPv6 in the first place.
> 
> "www.6bone.net" has just moved to IPv6, and its provider is having
> a lot of problems with that, so they don't have outer IPv6 connectivity.
> 
> (www.6bone.net is just an example, haven't occured to me on this website)

I'm not sure what you mean by "outer IPv6 connectivity".  Do you mean that 
either:
 - the IPv6 connectivity doesn't exist (you get back ICMP destination 
unreachable),
 - the IPv6 connectivity exists, but the packets get blackholed somewhere 
(you get nothing back, results in TCP timeout)
 - something else?

In the former case, have a look at draft-ietf-v6ops-v6onbydefault-00.txt 
section 2.3; this is discussed there.  TCP connection should not abort 
from an ICMP soft error such as destination unreachable.  However, some 
implementations do this, and it may make most sense for quick recovery.

In the latter case, there is no real fix that I'm aware of.  Could be 
worth thinking about a bit, or writing down as a potential problem.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Oct 2003 00:15:27 +0200 (EET)

[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..