[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: getaddrinfo address ordering [Re: IPv6 transition architecture discussion]
Pekka Savola [mailto:pekkas@netcore.fi] 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)
> - "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.
> 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. if the resolver doesn't support preferring they should
push their resolver coder to upgrade it. If people don't upgrade
reguraly they won't have IPv6 support anyways on most platforms
> 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).
As been said getaddrinfo is for AF independence if you depend on
something
request specifically that type of protocol.
Greets,
Jeroen