Subject: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

From: Pekka Savola <[email-masked]>
Date: Tue, 28 Oct 2003 14:30:05 +0200 (EET)

Hi,

(Cc:'ed to [email-masked] as well, because this seems to have significant 
impact with the IPv6 APIs as well..)

When revising my "transarch" document, I noticed another issue v6
on-by-default might cause.

If v6 is enabled by default, all the implementations I know generate the
link-local addresses for all the interfaces automatically, unless
explicitly configured otherwise (some don't have this knob).

This seems to cause an unintended consequence with getaddrinfo and its
AI_ADDRCONFIG hint (as specified in the basic socket API RFC).

That is, AI_ADDRCONFIG hint causes AAAA DNS queries to be made only if an
IPv6 address is configured on the node (similar with v4).  Loopback
addresses are excluded from this.  However, these typically autoconfigured
link-local addresses are *not* excluded.  In consequence, AI_ADDRCONFIG
seems to be of less utility than at least I had hoped.

The only reason I could think of for AI_ADDRCONFIG *not* excluding the
link-locals as well could be that if a node is expected to be able to 
communicate using regular, getaddrinfo() -using apps, using the link-local 
addresses (this would eliminate this possibility).

IMHO, using link-local addresses for anything except well-specified 
purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really 
counter-productive -- as you'll have to make those apps be able to 
distinguish the zone identifiers as well, and that's probably something we 
DON'T want to do.  But your mileage may vary.

So, I'll conclude by a few questions to give food for thought:

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

 - is getaddrinfo() + link-local addresses something we should support?

 - 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

Note: if we go select any of these (especially the latter two), it might
make sense to bring this discussion up in the relevant API forums like
POSIX as well, because the IETF API documents are just Informational RFCs.

-- 
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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 29 Oct 2003 10:57:37 +0900 (JST)

>    c) specifying a new hint which would perform this

	d) obsolete AI_ADDRCONFIG.  AI_ADDRCONFIG semantics is too vague, and
	way too difficult to specify (for instance, if you have IPv6 global
	unicast address and no route, is it configured?).  also, even without
	AI_ADDRCONFIG programs work just fine (socket(2) or connect(2) will
	issue the right error).

itojun

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 28 Oct 2003 21:41:32 -0800

Pekka Savola wrote:
> ...
> counter-productive

in your limited world this is undoubtedly true, but there is a wider world
out there.

> -- as you'll have to make those apps be able to

It is not a problem if you follow addr selection rules and prefer matching
scopes. This will cause IPv4 to be used if there is only a LL, trying to
talk to a AAAA global.

>  - is getaddrinfo() + link-local addresses something we should support?

Absolutely in the standard. In your specific network, you can turn this off
if it causes you to loose sleep at night.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 08:08:39 +0200 (EET)

On Tue, 28 Oct 2003, Tony Hain wrote:
[...]
> It is not a problem if you follow addr selection rules and prefer
> matching scopes. This will cause IPv4 to be used if there is only a LL,
> trying to talk to a AAAA global.

Uhh, I don't think Default Address Selection helps at all here.  The 
question is NOT how you prefer the addresses after you've queried them, 
it's whether you query them *at all*.  

I.e., the point of the AI_ADDRCONFIG as it seems to me is to avoid an
unnecessary query of IPv6 addresses in the first place.

For example, the app wants to look up www.example.com.  Prior to making
that lookup, it must know which addresses are configured on the node if
AI_ADDRCONFIG is used.  It doesn't know about scopes of www.example.com at
this point.  

If there are no IPv6 addresses (including link-locals) configured, it'll
query only A records and then perform default address selection as you
say, naturally ending up with IPv4 as there are no alternatives.  

If there are IPv6 addresses (including link-locals), it'll query both A
and AAAA records and perform default address selection, probably also
resulting in IPv4 if no global IPv6 addresses were configured.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 08:13:38 +0200 (EET)

> 	AI_ADDRCONFIG programs work just fine (socket(2) or connect(2) will

Agreed, that might be one option.

Without the on-link assumption, the default route case should be rather
simple, though.  You'd only have to look at the addresses.

IMHO, without the on-link assumption, AI_ADDRCONFIG could help a lot in
dual-stack deployments where IPv6 connectivity is not yet enabled.  

Of course, properly written apps would most probably also work there, but
some apps are not properly written, but:

 - there are really misbehaving DNS servers out there, which jeopardize 
your IPv4 service if you query for AAAA's, and
 - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA 
queries
 - maybe other considerations we haven't figured out / thought out yet.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 29 Oct 2003 07:53:24 +0100

>  - maybe other considerations we haven't figured out / thought out yet.

And I've seen cases where you never get a reply to the AAAA query, which
means that the application will wait for quite some time. Probably too
clever firewalls or broken DNS server software.

So I've seen people turn off IPv6 in apps using getaddrinfo() looping
through the addresses the normal way, due to this.

I don't like the idea of changing getaddrinfo() because of this, one
should rather attack the real problem. However that is much harder...

Stig

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 09:08:15 +0200 (EET)

Two points to clarify..

On Wed, 29 Oct 2003 [email-masked] wrote:
> 	could you clarify what you meant by "dual-stack deployment"? [...]
> 	if it means "dual-stack host in IPv4-only network", it can live fine
> 	without AI_ADDRCONFIG.

Yes, I mean the above.  AI_ADDRCONFIG makes one avoid completely 
unnecessary AAAA DNS lookups in the case that the addresses are not useful 
in any case.

> 	this is a separate problem (this is not what AI_ADDRCONFIG cares
> about).

Yes, this is a separate problem .. but one that AI_ADDRCONFIG works around
for the vast majority of nodes which could be dual-stack, but without IPv6
connectivity.  So, in that sense, IMHO AI_ADDRCONFIG helps the situation
*a lot*, but of course we still have to fix the problem for those 
dual-stack nodes that do, in fact, have IPv6 connectivity.

Remember, the most important thing we should care about is that dual-stack 
deployments can get more common without causing problems for *IPv4* or 
services in general.  AI_ADDRCONFIG is one step in that direction.

---

From: [email-masked]
Date: Wed, 29 Oct 2003 16:11:17 +0900

>services in general.  AI_ADDRCONFIG is one step in that direction.

	for your story to be effective it has to be host-wide configuration
	knob, not a parameter to library function.  (we cannot change every
	program we use to have AI_ADDRCONFIG)

	and we (*BSD groups) ship programs without AI_ADDRCONFIG, and they
	work just fine...

itojun

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 09:26:50 +0200 (EET)

> 	program we use to have AI_ADDRCONFIG)

Yep, or the apps writing guidelines could recommend to turn it on.  The 
basic API spec already defines "AI_DEFAULT" even though it doesn't (AFAIR) 
specify that it should be the default :-)
 
> 	and we (*BSD groups) ship programs without AI_ADDRCONFIG, and they

Yep, to the extent they're used.  Stig already mentioned that some apps
are moving to some custom address lookup hacks from getaddrinfo() due to
these problems.  The use of AI_ADDRCONFIG should help in the majority of
cases, i.e., deploying v6-capable apps on nodes which don't have v6
connectivity yet.

---

From: [email-masked]
Date: Wed, 29 Oct 2003 15:57:10 +0900

>dual-stack deployments where IPv6 connectivity is not yet enabled.  

	could you clarify what you meant by "dual-stack deployment"?  if it
	means "RA is sent by routers even though there's no glbal IPv6
	connectivity", that is a misconfiguration (outside of the issue w/
	AI_ADDRCONFIG).
	if it means "dual-stack host in IPv4-only network", it can live fine
	without AI_ADDRCONFIG.

>your IPv4 service if you query for AAAA's, and

	this is a separate problem (this is not what AI_ADDRCONFIG cares about).

> - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA 

	this is a sane reason for keeping AI_ADDRCONFIG, but i doubt the
	roundtrip makes that much of difference.

> - maybe other considerations we haven't figured out / thought out yet.

	:-)

itojun

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Wed, 29 Oct 2003 14:10:31 +0100

On Wednesday 29 October 2003 08:26, Pekka Savola wrote:
> > >Remember, the most important thing we should care about is that
> > > dual-stack deployments can get more common without causing problems for
> > > *IPv4* or services in general.  AI_ADDRCONFIG is one step in that
> > > direction.
> >

I agree with Pekka because it might help to new deployed/ported 
applications to improve their response times of DNS queries.

On the other hand, I think that applications which 
query the DNS shouldn't be real-time applications, so I see this 
feature is not very useful. If I understood Stig well, he said that people was 
turning off IPv6 because of delaying issues. Doing that is not an option if 
you want to allow your app. to run over "IPv6 AND IPv4". If you can not cope 
with such delays, maybe you shouldn't be using the DNS at all.

The problem here is that most of the times this feature will fail back
to the worst case, which is the normal getaddrinfo behaviour, because
it's not as easy as checking for global IPv6 configured address, as Itojun
has already said. We might come up with a lot of scenarios where this
option might fail to improve the response time (e.g: only link-local 
addresses, global addresses but no default route, proper link local IPv6 
configuration but some black-hole on outer routers.....). 

So...why do we bother ? Thinking about a feature that most of the times
will do nothing special is not worthy be implemented. 

We (*BSD users) feel that applications work just fine without this.

-- 
JFRH

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 08:08:39 +0200 (EET)

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 28 Oct 2003 21:41:32 -0800

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 08:13:38 +0200 (EET)

---

From: Stig Venaas <[email-masked]>
Date: Wed, 29 Oct 2003 07:53:24 +0100

Stig

---

From: Alain Durand <[email-masked]>
Date: Wed, 29 Oct 2003 10:13:35 -0800

On Oct 28, 2003, at 9:41 PM, Tony Hain wrote:

> matching

Not always. read our 2 drafts, this is clearly explained. If you have a 
case where
IPv6 src= LL, IPv6 dst = GL
IPv4 src= SL (rfc1918), IPv4 DST = GL
(This is a typical case of a host behind a NAT box)
Default address selection will choose the impossible v6 path.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 21:05:32 +0200 (EET)

On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote:
> feature is not very useful. 

How do you see people browsing the web get to the websites then, if not 
using DNS?  That's enough realtime in my book -- the user waits while the 
request(s) is being processed.

I really don't understand what you're trying to say..

> If I understood Stig well, he said that people was 

Then what?  Distributed hosts file? ;-) ?

> configuration but some black-hole on outer routers.....). 

I fail to see the point here:

 - if only link local addresses: fixed AI_ADDRCONFIG would fix

 - if global but no default route:
    a) without the on-link assumption: automatic immediate no route 
       message and fallback to the next address
    b) with (current) on-link assumption: problematic (which is why the 
       assumption must be killed :-)

 - if global, default route, but blackhole somewhere:
      silently discarding packets is evil practice anyway and nothing can 
      be done about that, whether in case of v4 or v6.

 - if global, default route, everything works, but some DNS server munges
      the AAAA queries: can't help with that, but because v6 would be 
      used, that has to be fixed by fixing the servers anyway.

.. so my perception is that this would fix all the problems related to
partial IPv6 deployment I could think of w/ the elimination of the on-link
assumption pretty well.

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Oct 2003 14:41:31 -0500

> in your limited world this is undoubtedly true, but there is a wider
> world out there.

Yes, there is a wider world out there.  And in that wider world, what
people do on their private networks - including inappropriate use of
link-local addresses - really can harm the ability of the global
Internet to support applications.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 09:26:50 +0200 (EET)

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Wed, 29 Oct 2003 21:23:44 +0100

> I really don't understand what you're trying to say..

Hello Pekka!

I will try to explain it better....

I just say that this option is not *very* useful, having
into account the problems that it has with link-local
addresses and so on... if you fix these problems, it's
a matter of choice, if you want to use it, just do it.

> > turning off IPv6 because of delaying issues. Doing that is not an option
> > if you want to allow your app. to run over "IPv6 AND IPv4". If you can
> > not cope with such delays, maybe you shouldn't be using the DNS at all.
>

 ^--^ ...(after a while)... pouting (grrrr).

Then what ? it's not my problem, I haven't switched to IPv4 because
the IPv6 resolver took a couple of extra roundtrip times.

I'm happy with a lot of IPv6 applications that don't
use this feature at all.

> > it's not as easy as checking for global IPv6 configured address, as
> > Itojun has already said. We might come up with a lot of scenarios where
> > this option might fail to improve the response time (e.g: only link-local

Uhm I thought that IPv6 was a piece of cake, but it might be problematic
sometimes....Ops, I've got the solution, just kill IPv6 ! ;-)

> partial IPv6 deployment I could think of w/ the elimination of the on-link

I see another way of fixing:

If this option is problematic, don't use it. This has been proved to work,
as a lot of applications don't use it already.

You will have to give me other arguments to kill the on-link assuption.

-- 
JFRH

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 22:36:38 +0200 (EET)

> a matter of choice, if you want to use it, just do it.

Which problems are you referring to?  I still don't understand :-(

> Then what ? it's not my problem, 

Sorry for my remark, I just could not resist.  What you seemed to suggest 
was, "don't use DNS" without giving any reasonable alternative.  That 
isn't really productive either :-)

> I haven't switched to IPv4 because

The extra roundtrip times are just the tip of the iceberg.  Consider 
broken DNS servers, load balancers etc. out there -- which may eat your 
AAAA query for e.g. 10 seconds, causing a lot more delay than a couple of 
roundtrips.

> as a lot of applications don't use it already.

As for AI_ADDRCONFIG, it's maybe not used because it hasn't really been 
implemented that much, maybe because it has been specified in a rather 
useless way (and it requires a proprietary interface between the glibc and 
kernel to get the addresses, such as the getaddrinfo destination address 
ordering as well; dst addr ordering hasn't been implemented that much 
either)..

> You will have to give me other arguments to kill the on-link assuption.

Let's keep that subject to a separate thread, (the next message).

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 29 Oct 2003 22:09:54 -0800

> resulting in IPv4 if no global IPv6 addresses were configured.

So you want to standardize an implementation & optimization issue ... This
is an optimization that you may want to use in any implementation you do,
but it is not an issue we need to standardize. In particular, it precludes
use of IPv6 if a local network has a name service intelligent enough to
provide LL information to the right place. Please stop assuming that the
world will not evolve beyond where we are, and trying to prevent it from
doing so. Yes we do not want LL addresses to show up in the global name
space, and the current DNS is too lame to prevent that, but that is no
reason to specify that nobody can ever use it.

Tony

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Oct 2003 08:25:01 +0200 (EET)

On Wed, 29 Oct 2003, Tony Hain wrote:
> but it is not an issue we need to standardize. 

Did you notice that the APIs are Informational documents? :-)

The key point here is raise the awareness of implementors by first 
discussiing, then writing a draft, and last publishing it.  Whether it 
says "do this, ignore that" or "you might want to do this, but be aware of 
foo" is pretty irrelevant to me.

> In particular, it precludes
> provide LL information to the right place. 

Right, there are tradeoffs here.  Unless there is concensus about that 
this is a generally desirable thing, one way forward could be publishing a 
tradeoffs document which would just bring up both sides of the argument, 
why you would or would not want to do it, and let the implementor decide 
what they feel is more important for them.

> Please stop assuming that the
> doing so. 

I'm not sure if I'd classify the widespread use of link-local addresses 
as "evolving"..

> Yes we do not want LL addresses to show up in the global name

My personal point is that LL addresses are highly problematic for apps, 
because they'll have to then (at least) parse the zone identifier as well, 
because e.g. if you are a host and have one physical interface and one 
tunnel interface, you cannot use link local addresses without additional 
disambiguation.  The only way to ensure that link-locals work seems to be 
restricting them to the special applications which know how to deal with 
them.

But it's no use trying to debate this argument over here.  If sufficiently
many folks think link-locals are a good thing, then we'd probably need a
tradeoffs document instead of a recommendation/specification document.

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Thu, 30 Oct 2003 11:19:33 +0100

> Which problems are you referring to?  I still don't understand :-(

I'm talking about the problems you've found out.

1. The problem that this option is not useful if we allow to 
make AAAA queries using link-local addresses.

2. The problem with the on-link assuption.

3. The problem that we are defining something that
applications don't really need to have. Although I accept
that it might be useulf sometimes, so this isn't a drawback.

4. The problem that if we keep the option as a flag, already
deployed applications won't use it.

If we fix those, I will be happy with this option. If we can not
fix them, this options shouldn't be defined.

> > > > turning off IPv6 because of delaying issues. Doing that is not an
> > > > option if you want to allow your app. to run over "IPv6 AND IPv4". If
> > > > you can not cope with such delays, maybe you shouldn't be using the
> > > > DNS at all.
> > >

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.

> AAAA query for e.g. 10 seconds, causing a lot more delay than a couple of

That's ok, my concern is that you want to fix the issues this flag has
killing the on-link assuption. That's not very constructive either.

> > If this option is problematic, don't use it. This has been proved to
> > work, as a lot of applications don't use it already.
>

Good idea.

^--^

-- 
JFRH

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Oct 2003 19:33:49 +0200 (EET)

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

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

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

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Thu, 30 Oct 2003 20:31:47 +0100

On Thursday 30 October 2003 18:33, Pekka Savola wrote:

[snipped]

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

> for IPv6 records.  How to best determine which records don't need to be

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.

> 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]
>   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 :)

>   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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Oct 2003 22:02:25 +0200 (EET)

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.

> Ok, so if we get rid of the onlink-assumption, there won't be such 

Yep, the delay is eliminated (as far as I can see).

> this is fixed, the penalty for those extra IPv6 connection attempts will be as 

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 

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]

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

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Thu, 30 Oct 2003 21:39:50 +0100

On Thursday 30 October 2003 21:02, 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?
> >
> > 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.
>

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 ?

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

> use e.g. firewalls w/ silent discard, we could end up in a loooooot of

Yes it is a problem indeed.

> worth thinking about a bit, or writing down as a potential problem.

I was talking about the latter case.

-- 
JFRH

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Oct 2003 00:15:27 +0200 (EET)

[snip]
> I think that you receive both AAAA and A records on the same unique query,

Look at the details of item "1." in each case.  There are multiple when
queries multiple records are asked/responded. (On the other hand, with
properly augmented AI_ADDRCONFIG, you could omit everything relating to
AAAA records, causing optimization.)

For example, this roughly what happens when you do try look up "psg.com" 
with getaddrinfo using PF_UNSPEC:

23:48:31.909344 80.186.150.55.1836 > 193.229.0.40.53: [udp sum ok]  1651+ 
AAAA? psg.com. (25) (ttl 64, id 27243, len 53)

23:48:31.920410 193.229.0.40.53 > 80.186.150.55.1836: [udp sum ok]  1651 
q: AAAA? psg.com. 1/0/0 psg.com. AAAA 2001:418:1::62 (53) (DF) (ttl 251, 
id 17061, len 81)

23:48:31.920892 80.186.150.55.1837 > 193.229.0.40.53: [udp sum ok]  1652+ 
A? psg.com. (25) (ttl 64, id 27244, len 53)

23:48:31.930985 193.229.0.40.53 > 80.186.150.55.1837: [udp sum ok]  1652 
q: A? psg.com. 1/0/0 psg.com. A 147.28.0.62 (41) (DF) (ttl 251, id 46142, 
len 69)

Two roundtrips.  Three if you do A6 as well :-), and even more if you have
to look up the delegation paths as well.  Note: I'm using a forwarding
nameserver here -- in practice, the roundtrips would take much longer if
nothing would be cached (the DNS server I'm pointing my resolver to 
already has everything about psg.com cached.).

I did a test: tried to do a TCP connect to www.6bone.net.  From the first
DNS query packet sent out, it took 1.528 _seconds_ for the fist TCP packet
to go out!  The first AAAA record arrived after 0.915 seconds (a lot in
itself).  That gives a measure of how much (at least) it would be faster
with IPv4-only.  Over 50% additional delay, and it could be worse if the
delegation path DNS servers have AAAA records which are not cached.

Only after all the responses have been received, the TCP connection is 
established.  After all, you have to run the default address selection on 
all the results.

This feature of DNS lookups certainly should be spelled out if/when we add 
AI_ADDRCONFIG considerations to the v6onbydefault document, as it clearly 
isn't apparent..