Re: Broadcast traffic on vlans leaks into the parent interface on NetBSD-5.1

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 29 Nov, 2012, at 22:54 , Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
>> I'm also trying hard, but failing, to ignore the issue which revealed
>> the current problem, that being having an application as important as
>> a DHCP client needing to use BPF to send and receive UDP packets
>> rather than using the host's own UDP/IP code for that.
> 
> I'm not sure I'd call that an issue, because...
> 
>> I believe every use of BPF by an application to send and receive
>> protocol traffic is a signal that something is missing in the host's
>> network implementation, so its use by as important an application as
>> a DHCP client seems like a sign that what is missing in this case is
>> quite important.
> 
> ...in general, I agree, but in the case of DHCP, I'm not so sure.  It
> needs to send and receive packets to and from unusual IPs (0.0.0.0, I
> think it is), if nothing else.

I really should have ignored that in the first place, but after reading
your response several times only the general argument I can find in there
seems to be of the form:

- The application has a legitimate need to do X.

- The network stack has no way to do X for it.

- Therefore, the answer is BPF (or some equally big hammer workaround?).

The reason I'm not fond of this argument is that the root cause of the
inability to do 'X' is seldom an issue solely effecting this one
application, most especially when the application is an implementation
of a standard protocol.  In the case of a DHCP client I believe that
there are pretty good arguments that the basic missing functions, or
disfunction, that make the DHCP client a BPF user are essentially
the same things that cause UDP sevice implementations like ntpd or
bind to fail on machines with sufficiently large interface
configurations (even though TCP services run fine), that make it
impossible to use point-to-point interfaces without addresses
configured even if you have no way to know what addresses to configure,
that cause (caused?) IPv6 to auto configure itself on every interface
in the box with no apparent way to tell it where you don't want it to
run, or which make the implementation of certain routing protocols, like
RSVP or PIM, impossible without kernel modification.

If you needed to make some other application, which wasn't a DHCP client
but which was effected by one of those issues, work with a NetBSD
kernel it seems like you'd have three choices: (i) find a workaround
a la BPF, (ii) find the minimal patch to the kernel networking which
allows your particular application work, or (iii) figure out the
fundamental, root cause of the kernel's inability to do what you
need, and the classes of other applications which are going to have
difficulty with this, and spend the effort developing a solution
which resolves this for as many applications (including your's)
as possible.  I've done all of these at various times, I can't say
that (i) or (ii) are wrong if you just need to get your work done,
but to me (iii) is the very definition of good design; (iii) makes
your kernel better while (i) and (ii), if anything, tend to do the
opposite.

I think this remains true even when the application in question
is a DHCP client.

Dennis Ferguson