Reason: https://reviews.freebsd.org/D20468

Source: https://github.com/hmatyschok/if_vether

Btw., therefore: https://github.com/hmatyschok/if_vether

So, I've submitted recent changes, upstream - see "P520" entiteled with "if_vether(4), further developement". Well, I've replaced ether_gen_addr(9) by vether_ifaddr_init(9) for init. randomized lla. by utilizing arc4rand(9). Further, netisr(4) component / facility still used for softint. maps-to bridge_output(9), still operates as Service Access Point (SAP) for broadcasting frames by running instance-of if_bridge(4)-component. Btw. namespace for primitives over ioctl(2)-requests.

I have changed som details from present implementation, e. g. replaced subr. for ransomized lla (ether_addr{}, ifaddr{}) and softintr (netisr(9) for broadcasting frames via running instance of if_bridge(4).

In D20468#496182, @donner wrote:

It look like duplicate work compared to ng_eiface and ng_bridge.
What are the benefits of this interface over the ng ones?

I have no commit privs. Yes, the way you are suggesting is the best way.

arge_rxfilter(9) implements handling of promiscuous / multicast flags. The initialization of MAC Address by hints mechanism and by reading EEPROM during runtime of arge_attach(4) was externalized. Finally, I've replaced some magic numbers by descriptive constants.