>>> Other daemons, including those mentioned, can only listen on
>>> INADDR_ANY.  [...]
>> Surely the right place to address this is the offending daemons, not
>> by having the OS trying to hide some interfaces from them!
> Which is the same as saying daemons should never use INADDR_ANY, no?

Not quite: just that they shouldn't use it unless configured to (or
perhaps unless not configured not to, since it's a reasonable default).

> At any rate, it seems unlikely that every daemon in tree is going to
> support this anytime soon, never mind every daemon in pkgsrc.

Right.  There is no good fix at the moment.  What you really want is
address classes of some sort, with a way for the sysadmin to describe
addresses as belonging to one or more classes, and a way for
applications to specify "any address in class <foo>".  Unfortunately
neither part of that exists (in or out of NetBSD), at least as far as I
know, and probably won't for the foreseeable future - except for the
class of "all of this host's address", with the name INADDR_ANY.

So it's a question of whether you'd rather use ipf or change INADDR_ANY
to really mean what ought to be called something more like
INADDR_DEFAULT_SET, meaning "all addresses not belonging to interfaces
marked `special'" - and lose the ability to have any name for the class
previously named by INADDR_ANY.

I would very much prefer to make this not an address (or interface)
flag per se but rather an address (or interface) class ID number, and
then have a per-process inherited sysctl that specifies a class number
that INADDR_ANY names, for that process.  (Actually, either addresses
or processes should have a list of classes, not just one, or there
should be a mapping table between them to get equivalent
functionality.)  This isn't Right, but the IPv4 API is too cast in
stone to get anything Right now, and I think this is as close as we're
likely to get.

Not that this means there's anything wrong with doing the flag you
initially suggested for your own use.  But NetBSD is supposed to be
about doing things right, and I don't see that flag as `doing things
right' in this case.  (Not that I'd be the one to make that decision,
of course.)

Random thought: this is unpleasantly IPv4-specific.  Countering
thought: the sysctl could be proc.$$.ipv4.<foo>.

> It may indeed be better to make this per ifalias, not just per
> interface.  I'm not clear if this would be easier or harder.

Come to think of it, it might be best to have a per-interface setting,
with a per-address setting which is by default taken from the address's
interface's setting.

>> IOW, while it may be a good enough fix for your environment, and as
>> such may be a right thing for you, I would argue it is not generally
>> enough Right to go into the tree.
> It's not clear to me that it's less Right than using ipf to block
> access to things which should never have been listening in the first
> place, which is the only solution thing currently in tree...

It is to me.  Or rather, let me put it this way.  I think that solving
this problem with ipf is a Wrong Thing, and I think that solving it
with an interface (or address) flag is a Wrong Thing.  Hence, I don't
think either of those should go into the tree for that reason.
However, ipf is a much more general tool with many other uses to
justify its presence; an "exclude from INADDR_ANY" flag isn't.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B