Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion]

[Craig Metz <cmetz@inner.net>]

In message <Pine.LNX.4.44.0211271804020.954-100000@netcore.fi>, you write:
>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..

  Last time I checked, AI_MAPPED was not a valid req.ai_flags argument to
getaddrinfo(), only to the IPv6-specific API getnodeinfo(). That was a
reasonable way to do things -- protocol independent APIs are protocol
independent, and protocol-specific features are available through protocol
specific APIs.

  Admittedly, the last time I checked was a long time ago, so I should check
to see whether there has been devolution in this way in the mean time.
 
>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.

  Raising awareness is fine. But that twenty, thirty, forty emails on this
mailing list on this topic don't actually cause the changes to happen. A
polite email to your implementation's authors ("vendor") pointing out this
problem, pointing out how it was solved years ago, and pointing out where the
code might be freely available (I don't know that it is for certain, that's
a slightly informed speculation), would do far more good towards getting your
implementation to fix the problem.

  Now, I don't know whether there are security implications with this solution,
and expect that there are, but that they're problems we know how to deal with.

									-Craig