On Thursday 30 October 2003 21:02, Pekka Savola wrote:
> 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:
> > > 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 ?.
>
> Yep, the delay is eliminated (as far as I can see).
>
> > > 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 a separate problem. What I was worried in above is eliminating
> the unnecessary DNS lookups.
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 ?
>
> 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?
Ahhh that's exactly what I was trying to tell you on the "www.6bone.net"
example. I sent the mail before finishing the example, sorry :)
I was telling that in this case, you have to wait for the TCP timeout
to be able to go on trying with the IPv4 destination addr.
> .. 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..)
Yes it is a problem indeed.
> [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.
I was talking about the latter case.
--
JFRH
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
