Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

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

On Wed, 29 Oct 2003 [email-masked] 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.
> 
> 	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)

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
> 	work just fine...

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.

-- 
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: Juan Rodriguez Hervella <[email-masked]>
Date: Wed, 29 Oct 2003 21:23:44 +0100

On Wednesday 29 October 2003 20:05, Pekka Savola wrote:
> On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote:
> > 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.
>
> 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..

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.

> > 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.
>
> Then what?  Distributed hosts file? ;-) ?

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

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

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 ! ;-)

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

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