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