RE: getaddrinfo address ordering [Re: IPv6 transition architecturediscussion]

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 27 Nov 2002, Jeroen Massar wrote:
> > On Wed, 27 Nov 2002, Stig Venaas wrote:
> > > > Programs should _never_ have a preference, if they do they
> > > > should ask for an AF_INET or AF_INET6 that's enough 
> > preference already
> > > > :)
> > > > I am against having the AI_PREFER4/6 as this would be too program
> > > > specific and one needs to recompile to get it out.
> > > 
> > > I agree, we really should avoid this. I think adding even more
> > > complexity to getaddrinfo() is a bad idea. And not only does it
> > > take time to deploy, but it might also be hard to change the
> > > applications later. This is really something the sysadmin should
> > > be able to choose, there is no default that fits all.
> > 
> > There are more layers than that, e.g.
> > 
> >  - "if I have an app and install it anywhere at all, I have no way of 
> > knowing whether the system has implemented A,AAA preferation 
> > method -- so 
> > I'll just ship it with AF_UNSPEC + AI_PREFERV4, so people can 
> > run it with 
> > 'app v6host', 'app -6 v46host' or 'app v46host' without 
> > problems, it'll 
> > always fall back to v4 if it doesn't know better"
> 
> It will currently always fall back to v4 if one wrote it correctly:
>  - tries AAAA (if dns returned it)
>  - tries A (if dns returned it)

Sure.. but in this case www.google.com will not have AAAA records in,
well, about 5-10 years.  They have no incentive to do so, _at all_ --
quite the contrary -- as their v4-enabled users would get worse service.

Or many more such sites.

If try A first would be the option, www.google.com (etc.) folks would have 
_no_ reason not to put the AAAA record in www.google.com in a year or two.

But this is just v6 deployment strategy.  Both ways could work.. but it 
seems to me that we must go and take 1).

> >  - "my app is special and is really only usable in v6 
> > context; I'd prefer 
> > it to use v6 even though whatever's configured in A,AAAA preferation 
> > method. AF_UNSPEC + AI_PREFERV6 could handle that"
> 
> One should use AF_INET6 for that. And this is what currently happens.
> But indeed if the resolver reorders A's in front of AAAA this doesn't
> work anymore.
> Then again the application can request a getaddrinfo() for AF_INET6 and
> if those didn't connect go for the AF_INET addresses.
> I don't think that there are many, even better name me 1, application
> that would want to do it. Even though it could be a quite plausible
> example one day. I don't think it will happen.

This is a bit dubious case, I agree -- but e.g. future peer-to-peer, 
end-to-end applications could profit from trying v6 first, then falling 
back to v4 if necessary.
 
> > Ie. I'd like the app writers to be able to write "v6-safe" 
> > code.  Code 
> > that, when run or compiled on nearly any system, would 
> > produce code that's 
> > safe to be used in v4-preferring environments _regardless of_ 
> > whether the 
> > app user's box even has any A,AAAA preferation method.
> 
> Ofcourse this should be true. And currently it nicely falls back
> to v4. 

You're missing the point.

> if the resolver doesn't support preferring they should
> push their resolver coder to upgrade it. 

A lot of pushing is needed, it seems.
 
> > But I can very well like with stuff like AI_PREFER* -- we 
> > just need the toggle to change the ordering of A,AAAA records when
> using 
> > AF_UNSPEC ASAP, if not yesterday.
> > If we could manage to get that deployed fast enough, 
> > and v4 preferred widely enough, perhaps in 1-2 years people 
> > could start shipping v6-enabled apps, waiting for the site admins 
> > decision to prefer v6 instead when they're confident enough to do so.
> 
> IMHO the toggle should go into the resolver and NOT in the application.
> If the application is specific enough to always request eg IPv6 then it
> should do getaddrinfo(AF_INET6) and then fallback to
> getaddrinfo(AF_INET).

I kinda agree with this.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords