[ntp:questions] ntpd IPv6 support on Windows?

Dave Hart davehart at gmail.com
Sun Jan 11 05:33:37 UTC 2009


On Jan 10, 7:02 pm, ma... at ntp.isc.org (Danny Mayer) wrote:
> Dave Hart wrote:
> > On Jan 10, 7:03 am, ma... at ntp.isc.org (Danny Mayer) wrote:
>
> >> We want to use the API's where they are available but use the emulations
> >> where they are not. You can't do that with Microsoft's source code, you
> >> would only get that emulation. We build once and deploy many and you
> >> want to take advantage of the API in the MS DLL's where available.
>
> > I am pretty sure you misunderstand.  The whole point of the header
> > file machinations I quoted earlier is to solve exactly the problem ntp
> > has, which is to use the system getaddrinfo and friends when available
> > while allowing the binaries to load and run successfully on older
> > versions of Windows lacking those new-for-IPv6 system APIs.  I can
> > find no information to indicate Microsoft's getaddrinfo inline code
> > emulation would be used when there is an OS getaddrinfo available.
>
> > Please read this quote carefully:
>
> > ----------- begin MSDN quote
> > When the
> > Wspiapi.h include file is added, the getaddrinfo function is defined
> > to the WspiapiGetAddrInfo inline function in the Wspiapi.h file. At
> > runtime, the WspiapiGetAddrInfo function is implemented in such a way
> > that if the Ws2_32.dll or the Wship6.dll (the file containing
> > getaddrinfo in the IPv6 Technology Preview for Windows 2000) does not
> > include getaddrinfo, then a version of getaddrinfo is implemented
> > inline based on code in the Wspiapi.h header file. This inline code
> > will be used on older Windows platforms that do not natively support
> > the getaddrinfo function.
> > ----------- end MSDN quote
>
> >http://msdn.microsoft.com/en-us/library/ms738520(VS.85).aspx
>
> I'm very careful to avoid the WSP* functions. I don't think many people
> know about the WSP* functions but I am very careful to avoid them as far
> as possible especially as there are potential security implications.
> Otherwise I would be using WSP* functions everywhere and avoid the extra
> overhead of the WSA* functions.
>
> Let's not go there.

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.

Please elaborate on the potential security implications of using
Microsoft's recommended late-binding of getaddrinfo and friends.

Please accept my apologies for going there, no offense intended.  I am
just failing to see why bloating ntp source code with Win32-specific
code that accomplishes exactly what Microsoft's header's already do
for you is beneficial given the counterarguments I'm hearing so far.

Cheers,
Dave Hart




More information about the questions mailing list