A Unix expert told me that ip-multicast uses Ethernet multicast (depends on MAC address to spread) instead of IPv4 multicast.
Is this true? Does it depend on the kernel or version?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
I believe there is a confusion of terms at work here. In fact, both the IP layer and the link layer work together to make multicasting work.
For both IPv4 and IPv6, multicast IP addresses are mapped to link-layer multicast MAC addresses. There are dedicated, multicast-only MAC addresses. For IPv4, the MAC address has the form
01:00:5e:xx:yy:zz and for IPv6 the MAC address has the form
Frames addressed to those MAC addresses are by default flooded to all ports in the vlan by ethernet switches, but as an optimization switches can implement IGMP snooping in order to limit which ports receive the frames based on which ports have actually subscribed to the multicast group.
When a host begins listening on a multicast group, its ethernet MAC layer is programmed to let through frames addressed to the appropriate MAC address. Otherwise the ethernet hardware will drop those frames unless it is in promiscuous mode.
Once the host receives a multicast frame because the ethernet switch has forwarded it and because the MAC layer has let it in, the IP layer looks at the IP address and directs the packet to the appropriate socket.
Using different MAC addresses for different multicast addresses allows a host to easily receive only the ethernet frames associated with the multicast groups to which the host is subscribed (meaning there is at least one active socket on the host subscribed to that group). The others will be efficiently discarded in hardware, either by the hosts's own ethernet chip, or by an ethernet switch on the network.
There are more multicast groups than there are dedicated MAC addresses, so actually many IP multicast addresses map to the same MAC address. This means that the above-mentioned filtering is not perfect: when the hardware is configured to permit one MAC address, this actually allows in packets addressed to a bunch of IP multicast addresses. Even so, the hardware does most of the filtering job so it's efficient enough.
For IPv4 there are 268435456 IP multicast addresses and only 8388608 MAC addresses so the mapping is 32-to-1 (1 MAC address per 32 IP addresses). See RFC 1112 section 6.4.
For IPv6 there are a gazillion IP multicast addresses and only 4294967296 MAC addresses so the mapping is lots-to-1. See RFC 2464 section 7. It would have been nice to make this mapping at least a little bit closer to 1-to-1, but the sheer size of the IPv6 address space makes it impossible. I verbally heard a story many years ago that even reserving 32 bits' worth of MAC addresses was already pushing it. The story goes that in terms of the IEEE's MAC address allocation scheme (IEEE is responsible for the assignment of MAC addresses), that number of MAC addresses corresponds to 256 OUI assignments and the IEEE would have demanded 256 times the monetary fee for allocating an OUI; it was out of the question for the IETF to pay such a sum of money to the IEEE so the IETF instead selected an apparently unused block of the right size and alignment and squatted it.