Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:

>   So, you are adding ethernet aliases, in a manner similar to how we do
> IP aliases - as a list of addresses on an interface. (As opposed to how
> Linux and some other OSes do IP aliases, with unique, virtual interfaces
> per alias). I say this because it might be that multiple ethernet addresses
> would be better handled with vlan-like interfaces.

    Yes, like ip aliases.  I'm not so sure the "whole other ifnet"
approach will work for what I have in mind; there are a bunch of
ambiguity cases that arise.  It doesn't strike me as terribly
dis-similar to using two physical ethernet cards attached to the same
link layer.

    The big issues seem to revolve around routing; how and why do I
pick one interface over the other?

    This would be a big problem for ??rp implementations; typically,
the system has a management ip address/burned in mac, and advertises
services attached to a service ip address on the same network, but
with a virtual link layer name associated with that service ip
address.  The ??rp implementation only transmits a select few frames
using the virtual address; namely arp replies and ??rp announcements
for the sake of programming learning bridge mac tables.


    Disregarding that issue, I see no reason why a seperate ifnet
isn't tractible.  It's probably even doable to have both; the ifnet
based version seems to have similar requisites to having them within
one.  I'll certainly keep the approach in mind.

>   I'd say you delete them.
>   That's what happens when I ifconfig an interface down, or remove the
> cardbus adapter.

    In a proper implementation, gc may be more difficult than I think;
why does the ethernet layer know about all of these random protocol's
neighbor discovery mechanics?  I'll see what my actual issues are soon
when I start trying to make arp handle what I need better.

>   Some cards have multiple MAC address filters, and on others, you can
> use the multicast filters to do the right thing.

    As I've seen; the exact mechanics strike me as a detail that can
be hidden by the driver layer (although I'm thinking that questions
like the perfectness of the filter will be handled stupidly, that is,
assume you must always check dest addresses).

>   I'd say that new ethernet addresses should *be* a kind of bridge :-)
>   You bridge the frames to the new device.

    You're thinking of a second ethernet address as a full first class
citizen it seems.  I'm not (at least not until you suggested it); it
isn't needed for ??rp.

>   Yes.
>   One reason to have multiple interfaces might so that one can run dhclient
> on some, but not all of the interfaces. 

    There are ways in which that brings up ambiguity questions again,
but depending on what you're actually trying to do, I can dimly
imagine ways in which the capability may be handy.  I just hope I
don't run into the real world situation;  I'm rarely amused when that
happens.