Hi,

While catching up on my RFCs and stuff, I was playing a bit with
ifconfigs and ndp in order to precisely understand how things work in
practice. I believe while doing this I found a bug in
NetBSD-1.5-{ALPHA2|BETA} for machines configured as IPv6 routers. It
may also be just that I haven't finished re-reading the NDP-RFC yet,
but I don't think so.

I tried stealing another machines IPv6 address and watch how DAD
prevents me from doing so. I manually, using ifconfig, added the
address (with ifconfig ... alias) of another machine and watched what
happened with tcpdump, and checked the result with ifconfig and ndp.

When the IP-address I try to steal is from another (autoconfigure) host 
(not router), everything goes as expected. DAD is executed, and the
host that already uses the address I try to steal tells the `thief'.
ifconfig -a, shows the address afterwards, with the `duplicated' tag
as expected.

But, when the IP-address I try to steal is from a machine that is
configured as an IPv6 router, the host does send out a neighbour
solicitation for that address (to the solicited-nodes multicast
address; i.e. :: > ff02::1:ff00:2: icmp6: neighbor sol: who has...),
but the router never replies that it actually uses that address. This
results in (semi-)successful theft of the address, in that the thief 
configures the address to its interface (without the duplicated tag).
`semi' because normally the neighbour discovery cache still has the
entry for the real owner (the router), whcih does not get overwritten.

It looks to me that this is because the router doesn't listen to the
Solicited-Node Multicast, however it does reply to pings to that
address.

Another thing that seems not quite right to me, is that when I delete
an IPv6 address from an interface, it's corrosponding (permanent)
entry in the neighbour discovery cache is not deleted. I need to use
ndp -d to get rid of it. Shouldn't the kernel or ifconfig take care of
this? (This is both on NetBSD-current and 1.5).

Feico.