In message <20050430141629.0F90B1F42@fnord.ir.bbn.com>,
Greg Troxel writes:

>  How in the world did we go from unbound sending to 10.0.0.6 to having a
>  multicast (239.255.255.253) address as our source!
>
>I think you are converged, but this sort of follows from binding to a
>multicast address.
>
>You might file a PR that the bind-to-multicast succeeded, although
>reading in_pcbbind() it seems that it is intended to do something
>useful.  Perhaps the intent is to get only packets for that group, and
>not to affect the outgoing source address process.  But it really
>seems like something is broken in the kernel.

I concur. From Bill's description of what the Linux code does, I can
construct a similar guess at the intended behaviour. 
But I'd argue that:

a) sending packets with a multicast source address is absolutely
verboten: for IPv4, see rfc-1112, sec 6.2.

b) The semantics of bind(2) are clearly specified as binding a
   source address; not some side-effect for multicast, as Greg
   and I are imagining.

So I conclude that --- unless there's some well-defined reason (e.g.,
an RFC specifying socket API for multicast which specifies this
side-effect for bind(2)?) --- that bind(2) with a multicast address
SHOULD return an error: EADDRINUSE, or maybe EACCESS (whatever meets
SPEC 1170 and SUS.)

Even if we do that, bind(2) with a multicast address probably
needs to be Linux-specific, if our (Greg and my) guesses about intended
behaviour are correct, and Linux does something particular (e.g.,
default-address?)  for bind(2) with a multicast address.

(In which case, that behaviour needs to be documented somehwere.)

Bletcherous.