On Thursday 30 October 2003 18:33, Pekka Savola wrote:
[snipped]
> 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?
(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 ?.
> 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?
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 my major concern now, so I would be glad to hear your opinion
about this.
What follows in the rest of the email are little answers to your questions
and an issue which is not related to the AI_ADDRCONFIG discussion
but I think is good to have a glimse at.
> > 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.
No I didn't miswrite, I was thinking about the problem in the wrong way :)
I see the point now.
[final Pekka's explanations cut out, though I agree with him]
To sum the thing up,
I extract the following from your first email on this thread:
Pekka gave us food for thought, like this:
>
[extracted]
>
> - does this seem like a problem, that is, should getaddrinfo() +
> AI_ADDRCONFIG perform AAAA DNS queries etc. if
> the node only has v6 link-local/loopback addresses?
Provided we get rid of the onlink assumtion, as I've said above, there
won't be any difference.
> - is getaddrinfo() + link-local addresses something we should support?
I don't think so. It's better to do things better :)
> - should this be fixed by e.g.:
> a) recommending that the implementations filter out link-locals as well
> when doing AI_ADDRCONFIG (a BCP/Info document)
> b) specifying additional semantics for AI_ADDRCONFIG
> c) specifying a new hint which would perform this
>
I dunno.
The following has nothing to do with AI_ADDRCONFIG:
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)
--
JFRH
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
