Subject: Manipulating link address on Ethernet interfaces
To: None <email@example.com>
From: Quentin Garnier <firstname.lastname@example.org>
Date: 03/24/2006 10:42:50
Content-Type: text/plain; charset=us-ascii
I don't think that subject has come up recently, and it's probably time
to raise it again, maybe we'll end up with something this time.
AFAIR, the latest patch that was sent to add a support for that which
doesn't involve patching a driver's source was that one, sent by
While the patch itself had a number of issues, one which is probably the
most relevant is that it used a fictive SIOCSLIFADDR. itojun argued
that this ioctl was never defined because KAME wanted Add/Delete
semantics for address manipulations (for any family) and not a Set one.
Please refer to the thread itself to see what were the other issues with
In any case, I think it's worth discussing it again, and I'll give my
view of the problem now.
- I prefer the Add/Delete semantics. Having several addresses on an
interface would be useful in some situations. And AFAIK, quite a
few chips support listining for a small list of addresses instead
of going promiscuous right away.
- Also, note David Young's idea of restoring the orginal address of
the interface upon deletion of the last address. I like it.
- I'd rather see this implemented through the AF_LINK family. I.e.,
to change the adress one would open an AF_LINK socket and perform
ioctls on it. I don't quite like how ioctls and address families
are abused all through the system. Then you'd do
ifconfig link 00:01:02:aa:bb:cc
ifconfig link alias 00:01:02:aa:bb:dd
ifconfig link -alias 00:01:02:aa:bb:ee
as you would for other address families.
All of this implies more work than a Set interface would have needed,
though, and it's high time someone does something about that, because
it is a feature other systems have had for quite some time, and we've
all needed it one time or another. Yes, using tap(4) and bridge(4)
for that purpose is possible; yes, grossly hacking a kernel for it is
very easy. But still not quite the real thing.
Quickly thinking about the implied changes, I assume one would have to
change ether_input, and also make sure that userland tools such as
dhclient (and probably all the users of bpf) behave correctly. And the
said behaviour might have to be defined; for example dhclient would
have to be taught which address should be used, as pointed out by Joerg
I'd really like if we could end up with a sane proposal, so that it'd
be very easy to get someone to work on the code.
Quentin Garnier - email@example.com - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
-----END PGP SIGNATURE-----