Really bad form to have posted a question that I can now
answer myself, but I figured the archives deserve an answer.  :)

From what I gather, ipv4-mapped addresses are now disabled by
default in NetBSD, for security reasons.  (I'm still a little vague
on what those security reasons are, but they come from folks I trust
to know what they're talking about)  The old behaviour can
be reenabled by setting net.inet6.ip6.v6only to 0 with sysctl.

Just as a followup question, is the "correct" way to support both
ipv4 and ipv6 in a case like this to loop over the return
from getaddrinfo() and bind a listening fd to both :: and 0.0.0.0 ?
That is, always handle all protocols explicitly?

Thanks,
+j

On Tue, May 11, 2004 at 11:43:55PM -0700, Jeff Rizzo wrote:
> I've been using distcc from pkgsrc, compiled with the --enable-rfc2553
> flag, and I'm trying to figure out whether the way distccd is trying
> to listen for both v4 and v6 connections is correct for NetBSD or
> not; the code seems aimed primarily at a Linux audience, though
> the author is quite helpful in accomodating other systems.
> 
> The code in question uses getaddrinfo() and sets the hints for an
> ai_socktype of SOCK_STREAM and ai_flags to AI_PASSIVE.  It takes
> the first sockaddr returned (which in this case is ::, the v6
> wildcard), and *only* the first sockaddr returned, calls socket(),
> bind() and listen() on it.  The author seems to think this should
> (and I assume under Linux, does, though I have no way of verifying it
> at the moment) be able to accept either v4 or v6 connections, but
> I can only connect on the v6 addresses of the box. netstat confirms
> that tcp6 is listening on *.3632, and tcp is _not_.
> 
> The only other code I've used recently that listens to both v4 and v6,
> thttpd, seems to treat them completely separately, with a different
> listen_fd for each protocol.   Can someone with a little more
> network-code savvy enlighten me as to how it's *supposed* to work?
> It wouldn't be too hard for me to add separate support for each
> protocol, but I'd like someone more knowledgeable than I to tell
> me that's the correct approach before I dive in...

-- 
Jeff Rizzo                                         http://boogers.sf.ca.us/~riz