Peter Memishian wrote:
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.
[...]
>
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.
The issue is asynchrony in the IP/ARP/driver interaction. Due to ARP
being a separate module the DL_DISABMULTI_REQ which is embedded in the
AR_ENTRY_SQUERY is an asynchronous operation. The response comes back to
IP which then sends the DL_DISABMULTI req to the driver.
Since we can't send that to the driver after the
DL_UNBIND_REQ/DL_DETACH_REQ, the code instead assumes that the
DL_UNBIND_REQ implicitly cleans up the multicast registrations in the
driver.
Note that if we knew that we wouldn't bring down the whole ill i.e. that
we are not going to send a DL_UNBIND_REQ, then we could to the DISABMULTI.
Also, with ARP merged into IP the asynch issue goes away and life
becomes much simpler.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
