I'm trying to understand why multicast is handled asymmetrically with
IPv4. Specifically, as part of bringing each ipif up, we go through
ipif_up_done() -> ipif_multicast_up() which eventually leads to a
DL_ENABMULTI_REQ being sent to the driver to enable reception of multicast
traffic. As one would expect, it also creates ILM (ill multicast entry)
for 224.0.0.1.
However, for IPv4, ipif_down() does not call ipif_multicast_down(). As a
result, it seems we keep multicast reception enabled, even when there are
no up ipifs. I cannot find an explanation for this, though the oddity
requires special handling in a few places, such as in ipif_free_tail()
(which has the sole call to ilm_free(), which seems to exist solely to
delete the IPv4 ILMs), and here in ill_down_ipifs():
ipif_down_tail(ipif);
/*
* We don't do ipif_multicast_down for IPv4 in
* ipif_down. We need to set this so that
* ipif_multicast_up will join the
* ALLHOSTS_GROUP on to_ill.
*/
ipif->ipif_multicast_up = B_FALSE;
... and here, in ilm_move_v4():
/*
* We joined this in ipif_multicast_up
* and we never did an ipif_multicast_down
* for IPv4. If nobody else from the userland
* has reference, we free the ilm, and later
* when this ipif comes up on the new ill,
* we will join this again.
*/
if (--ilm->ilm_refcnt == 0)
goto delete_ilm;
I'm guessing that the need for all of this is tied to ARP (which is passed
an AR_ENTRY_SQUERY during ipif_multicast_up() through some "twisted coding
magic" (as per the comments) in ip_ll_send_enabmulti_req()), or perhaps
with the fact that ILMs are associated with ipifs in IPv4 and ills in
IPv6. But I'm having a hard time putting all the pieces together.
Anyone have clues?
--
meem
_______________________________________________
networking-discuss mailing list
[email protected]
