Multicast IP addresses fall within the range 184.108.40.206 - 220.127.116.11. In the pre-CIDR world, they would have been called Class D addresses (although nowadays it is not considered polite to use such vulgar terminology !). For the honours students, they are distinguished by the most significant four bits being "1110".
In the Ethernet world, a multicast MAC address is distinguished by a binary '1' in the least significant bit of the first byte. For IP multicast specifically, the Ethernet prefix "01-00-5e" is reserved.
Mapping from IP to Ethernet
Since it is obviously infeasible to have an equivalent of ARP when transmitting multicast traffic, we would ideally like a one-to-one mapping between multicast IP addresses and multicast MAC addresses. If we ignore the four most significant bits of the multicast IP address (which, as noted earlier, will always be "1110"), that leaves 28 bits of IP address information which needs to be mapped to a MAC address.
The astute reader may have noticed a problem by now: There are only 24 bits (the least significant three bytes of the MAC address) available into which to encode the IP address. Actually, it is even worse than this...only the lower 23 bits are available for use (for non-technical reasons which need not detain us here). To get around this, the most significant 9 bits of the multicast IP address are quite simply ignored and the remaining 23 bits are copied into the lowest 23 bits of the MAC address.
As a consequence of this, 5 bits of "useful" IP address information being scrapped, there is not a one-to-one mapping between multicast IP address and multicast MAC addresses. Rather, each multicast MAC address will be shared by 32 IP addresses.
This has implications for multicast application design. Typically, modern LAN switches have the intelligence to "filter" multicasts. Users will only "see" multicast traffic they have actually asked for, so that (for example) a high-bandwidth software download (using Ghost or something similar) will not affect network performance for all users. However, LAN switches are not IP-aware and will do their multicast filtering based on MAC addresses. This means that if the high-bandwidth software download is being transmitted on multicast IP address 18.104.22.168 and you are subscribed to a streaming video feed on multicast IP address 22.214.171.124 (which maps to the same MAC address), you are going to be swamped with the download traffic as well as your video feed.
You can use the tool below to convert multicast IP address to MAC address and back again. Enter either a multicast IP address or a multicast MAC address into the appropriate field and click the button
Reserved Multicast Addresses
TODO: Write a more full description here.
In the IPv6 world, the mapping between IPv6 addresses (16 bytes) and MAC addresses is defined by RFC2464. It is pretty simple. To quote section 7 of this RFC in its entirety...
An IPv6 packet with a multicast destination address DST, consisting of the sixteen octets DST through DST, is transmitted to the Ethernet multicast address whose first two octets are the value 3333 hexadecimal and whose last four octets are the last four octets of DST.
The amount of IPv6 address which gets "lost" this way isn't as much as first appears. An IPv6 multicast address has a most significant byte of 0xff. The next byte contains the flags and the scope identifier (defining the locality of the address). Bits 16-95 inclusive must be zero and bits 96-127 (the least significant 32 bits) are the multicast group ID. So there is really only 32 bits of usable multicast address space (oh no...we will be limited to 4,294,967,296 TV channels !!). This produces a one-to-one mapping between IPv6 multicast group IDs and Ethernet multicast addresses. It does not produce a one-to-one mapping between IPv6 multicast addresses and Ethernet multicast MAC addresses, though: the same group ID used with different scope identifiers or prefix-based multicast addresses (see RFC3306) will all map to the same Ethernet MAC address