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