Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote:
> > Which problems are you referring to?  I still don't understand :-(
> 
> 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.

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