Subject: Re: link layer aliases (on ethernet, at least)
To: None <tech-net@NetBSD.org>
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
List: tech-net
Date: 07/29/2003 11:06:33
-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Daniel" == Daniel Hagerty <hag@linnaean.org> writes:
    Daniel> I've been twiddling with getting my netbsd box to listen on more
    Daniel> than one ethernet address.  Doing this seems requisite to a
    Daniel> reasonable vrrp or hsrp implementation.

  Sure.

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

  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.

    Daniel> deleting a link layer alias that a neighbor discovery protocol is
    Daniel> holding a reference to?  Saying no, or deleting these for the
    Daniel> user?

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

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

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

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

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

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

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

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBPyaNeIqHRg3pndX9AQEPwgP/brZlM9/CulQD7dlvUKe8Bcj0QiEWq1Ci
wlhk8R/jL239fWV4bfyVW3zx2q29kH/qW2Q9/WBtuCS8T+Ccizgce2gTvZsySv27
7eId+NeFR9/WVF7NG0CoQDbloloQZsycJq9tPEvPMcQEW+uDGzdkeZ37fQXDygKf
qf6r8s1FzPM=
=qIsz
-----END PGP SIGNATURE-----