Re: Simplify bridge(4)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> tap(4) is a direct interface between userland and the network.

Well, where "the network" refers to the Ethernet stack and higher
layers within the kernel, not to any real networking medium.

> vether(4) would not be (although you could use BPF, etc.).  It would
> be an ethernet device that represents the host.

I'm not even sure what that could mean.

> If you know how to configure Cisco devices, think BVI.

I did not know the term; from what little I found in a few minutes'
searching, it sounds like something that exists solely to be a bridge
member, to make up for their bridges' inability to have an address or
otherwise be a destination for IP-layer (or, more generally,
above-Ethernet-layer) routes.

> The problem with bridge(4) is that you put addresses on one of the
> interfaces included in the bridge.

Why is that a problem?

> The addresses belong to the host as a whole, not to the particular
> part represented by an interface to part of the outside world.

Sounds to me as though the most sensible way to model that would be to
give the address to the bridge interface itself.

I don't think I've tried that.  If it does not work, is there any
particular reason to add vether(4) rather than making it work?  If it
does work, what functionality would vether(4) provide over it?

> A bridge is really network infrastructure, not part of a host.

Normally true, but it can of course be implemented on a host.  Indeed,
I would say that bridge should not, conceptually, be a network
interface at all; I suspect it was done as a network interface simply
because that got a lot of infrastructure for free - and, if it works to
put an address on the bridge interface itself, because that part of it
_should_ be a network interface.

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