On Mar 2, 12:30pm, gdt@ir.bbn.com (Greg Troxel) wrote:
-- Subject: Re: stray ifnet pointers in mcast membership records & cloning ->

|   Ok, I understand. Is it a feature to be able to join a v4 multicast group
|   without having a v4 address? Are there cases where this is useful? Like
|   for a DHCP like protocol?
| 
| I would say that it is a bug from a security point of view, since
| there is an expectation that an interface without a v4 address will
| not be able to send or receive v4 packets ("ifconfig foo0 up; tcpdump
| -i foo0" is thought by some not to open one up to network attacks from
| foo0 other than tcpdump overflows).  But if the addr has come and gone
| this is less of an issue.
| 
| dhclient configures 0.0.0.0 for use with the socket method, and then
| can either use sockets or bpf (at least earlier code could use either,
| and the 0.0.0.0 still happens.

Ok, that makes sense.

|   | One could argue that having a v4 multicast group joined on an
|   | interface with no v4 addrs should be illegal, and I'd be sympathetic
|   | to that.  But one would have to delete all memberships from an
|   | interface when the last address is removed.
| 
|   Well, if there are cases where having a multicast group joined without
|   having a v4 address make sense, it probably does not make sense to
|   remove the memberships when the last address is removed, but only on
|   interface deletion.
| 
| Sure.  My real concern is that interface deletion is not safe.  Given
| that these invariants are becoming kind of hairy, I think the only
| safe thing to do (from a software maintenance viewpoint) is to have
| interface destruction always scan all data structures that might have
| ifnbet pointers.

I definitely agree with that.

christos