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

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 27 Nov 2002, Craig Metz wrote:
> In message <Pine.LNX.4.44.0211270915100.28193-100000@netcore.fi>, you write:
> >Do I sense this as a voice for support to modify or at least explore the 
> >current de-facto standard ordering?
> 
>   There is no specified standard, deliberately. This is an implementation
> issue. Not all implementations have this problem, but many people on this list
> don't seem to understand that and instead blame getaddrinfo() or blame IPv6.

Yes, this is implementation specific.  But most do have this _operational_ 
_deployment_ _problem_.  And sitting on our thumbs does little to help 
with getting v6 out there.  I'd like to see it one day :-)
 
> >These help quite a bit, but I guess adding some getaddrinfo hint like
> >AI_PREFERV4 or AI_PREFERV6 could be added in the case that DNS lookup
> >returns both addresses, you use AF_UNSPEC and you want to influence the
> >default DNS record ordering.
> 
>   NO! NO! NO!
> 
>   getaddrinfo is a PROTOCOL INDEPENDENT API. It is NEVER appropriate to cruft
> ANY protocol-specific options into getaddrinfo. Protocol-specific hacks belong
> in protocol-specific APIs. If the protocol-independent APIs do not give you
> the features you want, then use the protocol-dependent APIs instead, which
> will give you more specific controls.

I'm sorry to wake you up from the wonderland, but getaddrinfo has already
been encumbered with protocol-specific options (think AI_MAPPED..).

Whether anything can or should be salvaged is another issue..
 
>   If an application wants to have getaddrinfo() return things in a particular
> order, it should call getaddrinfo() multiple times in the order it wants, i.e.,
> call it first for req.ai_addr=AF_INET, second for req.ai_addr=AF_INET6, etc.
> HOWEVER, this behavior would be TOTALLY BROKEN as it first defeats protocol
> independence (the whole point; if you're not using getaddrinfo in a protocol
> independent way, why are you using it at all?), and second because it limits
> you to IPv4 and IPv6.

Right. (I prefer some deliberate ordering for AF_UNSPEC of course.)
 
>   BSDI did this right. BSD/OS had a configurable resolver return order, I
> believe through a file and an environment variable. Didn't like the system
> default? Users can request things be done in a different order. Problem solved.

That's nice, but as more folks haven't done it -- it helps little in this 
operational problem.

This is probably caused by the fact that most many not have considered
this problem serious at all, worth spending time on -- and there are many
strategies how v6 could be deployed, some of which aren't affected by the
lack of the option.  I believe it's our job to raise awareness on 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