[ntp:questions] ntpd IPv6 support on Windows?

Dave Hart davehart at gmail.com
Mon Jan 12 02:59:59 UTC 2009


On Jan 11, 6:04 pm, ma... at ntp.isc.org (Danny Mayer) wrote:
> Dave Hart wrote:
> > I am not suggesting you to go referencing Wsp* functions willy-nilly
> > to avoid some perceived (and insignificant) overhead of using
> > published APIs.  I'm suggesting you use the published API names like
> > getaddrinfo and let Microsoft's runtime binding implementation do what
> > it is designed to do.  That it involves macros to inline functions
> > with names like WspiapiGetAddrInfo is an implementation detail
> > invisible to everyone not using a symbolic debugger against ntp
> > binaries on Windows.
>
> That is not correct. These are not macros. The SPI layer is a layer
> between Winsock2 and the base layer and there can be multiple SPI layers
> and in fact you can specify the order. All of this gets very tricky and
> it's one of the reasons why I don't want to go there. Just because
> Microsoft provides something doesn't mean that we should use it.

You are mistaken.  I'm getting sick of you speaking without checking
on the accuracy of your claims.  Wspiapi.h and the Wspiapi-prefixed
inline functions and macros have nothing to do with Winsock's Service
Provider Interface (SPI).  Rather, they are part of the pedestrian
client application socket API.  Please take a few minutes and read the
header file, since you are so stubbornly unwilling to believe the
documentation I've referred you to repeatedly.

http://pf.itd.nrl.navy.mil/mdp/dox/html/wspiapi_8h-source.html

You don't even need to have a set of Windows header files handy, the
US Navy has kindly published the entire header file at the URL above.
You said "these are not macros."  The source code disagrees:

00027 #define getaddrinfo             WspiapiGetAddrInfo

If you scroll down to line 941 you can find the inline function
implementation WspiapiGetAddrInfo, which is terribly boring because
all it does is call through a function pointer, which is either
initialized to the system API address for getaddrinfo in ws2_32.dll/
wship6.dll or if running on a system lacking IPv6, left pointing to
the IPv4-only WspiapiLegacyGetAddrInfo implemented in that header file
on line 439.

I've read through the entire Wspiapi.h file and assert it is obvious
to anyone skilled in the art that all it does is provide getaddrinfo,
getnameinfo, and freeaddrinfo implementations for IPv4-only Windows
systems and the plumbing to runtime-bind those three functions and use
the OS versions where available and the inline WspiapiLegacyXxx
versions where not.  It has nothing to do with Winsock SPI.  Not every
Windows sockets function that begins with Wsp is related to SPI, as it
turns out.  If you do not believe me, please read Wspiapi.h for
yourself.

I realize ntp already has its own code related to deciding whether to
use getaddrinfo and friends or v4-only DNS APIs.  I see no reason that
code should be brought to bear on the issue of IPv6 support on
Windows.  Microsoft has already invented the wheel, so to speak.  I
bet Win32 NTP could simply always use getaddrinfo, getnameinfo, and
freeaddrinfo via the Wspiapi.h magic and avail itself of IPv6 on
systems which support it without preventing compatibility with older
versions of NT lacking IPv6.  Even if there is good reason for NTP on
Windows to decide at runtime whether to use old name resoloution
services or new, I would suggest Wspiapi.h is still the best way to
runtime-bind the new routines.  It would be easy to peek under the
covers to decide if the routines are mapped to the system or to the
WspiapiLegacyXxx inline emulation.

>
> > Please elaborate on the potential security implications of using
> > Microsoft's recommended late-binding of getaddrinfo and friends.
>
> The SPI layer is a whole other set of layers that I don't have time to
> go into.

Since I'm not talking about SPI layer interfaces, it sounds like the
potential security implications are moot.  Once again, the Wspiapi
prefix is used by the windows sockets platform independent API, which
is solely at the Winsock API level and has nothing to do with Winsock
SPI or the WspXxx interfaces used by SPI.

Dave Hart




More information about the questions mailing list