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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
