Subject: link layer aliases (on ethernet, at least)
To: None <tech-net@netbsd.org>
From: Daniel Hagerty <hag@linnaean.org>
List: tech-net
Date: 07/28/2003 21:52:26
    I've been twiddling with getting my netbsd box to listen on more
than one ethernet address.  Doing this seems requisite to a reasonable
vrrp or hsrp implementation.

    I've got a roughly functioning first draft, but I'm running into
some questions of what the user interface for it all should look like.

    Is there any interest in me getting this code to a reasonable
state?  In that case, there are API and probably some implementation
questions to work out.



    I'll also note that someone was asking questions about setting
ethernet addresses from userland, which has some overlap with the code
I'm presently smashing on.

    In the first pass, I used SIOC{A,D}LIFADDR for pushing sockaddr_dl
between the kernel and userland through a socket(AF_LINK,SOCK_RAW),
which seems to be a reasonable semantic match my needs.  I also
implemented a quick SIOCGLIFADDR as a generic get link layer addr
operation.  However, there doesn't seem to be a SIOCSLIFADDR however,
which seems what would be needed for the set operation.  Am I missing
something?  There's SIOCSLIFPHYADDR, but that doesn't seem correct
given the physical it's talking about.


    More open ended questions revolve around the interactions with
neighbor discovery protocols like arp and v6nd; I have no clue what
the API should look like ("my UI is the debugger" was easy enough).
There's also a garbage collection issue hiding in here; what's the
preferred behavior when the user does something like deleting a link
layer alias that a neighbor discovery protocol is holding a reference
to?  Saying no, or deleting these for the user?


    The draft code assumes that promiscuous mode is required to do
this; this isn't actually true on all cards.  I have the vague idea of
something like ETHERCAP_UNICAST_RXFILTER or some such but haven't
actually gotten here yet.

    This code will doubtless have some interactions with at least vlan
and bridging code; probably more.  I don't see any outrageous issues,
but I haven't done much looking inside yet.


    Some pieces of userland will raise their eyebrows at the idea of
more than one AF_LINK address being returned from things like
SIOCGIFCONF.  dhclient brought itself to my attention pretty rapidly.