--tyhzcnTYDIcSS9Td
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi folks,

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
Dheeraj Reddy:

http://mail-index.netbsd.org/current-users/2003/08/08/0004.html

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
the patch.

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
Sonnenberger.

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.

Comments?

--=20
Quentin Garnier - cube@cubidou.net - 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.

--tyhzcnTYDIcSS9Td
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBRCO/GtgoQloHrPnoAQJ3rggAuTk8EYz55lvrdv+VSM7k+FfYaZeg8Sbo
qsaRU1mut2PrJByGFkfsFrPVtd2cMiw/GWHLuylTEM42Nalm7oOV2sAzw16IxDfg
CEV5cTX/2S1pWd4tim3gzxeVW3JI6lMv6rzr0sNMjX6vu18wFaxExSWuXa7pkpMr
TXkNn7zBVkWu+xMXG1goTk+46yDlNYeieS1T9Dsks4aC7n2nc635pcXnZR37YGJW
OwWsEjQ3F2czxohP2Vyxn2nDJYysjUEseU7U1U9jw8P4Q9c4ujlJLL9PBm5fZwhE
YaxwYA9FzOKLu9gMXSrWCxfzerDpqxQpAsp0GaHo4F/1TQIfbISNmw==
=ZAZK
-----END PGP SIGNATURE-----

--tyhzcnTYDIcSS9Td--