Network Fundamental Addresses and identity
Multicast — an address that refers to no machine at all
The machine you are on has already joined several multicast groups without being told, and the address mapping throws five bits away
· Part 1 · Addresses and identity · 6 min read
The MAC address article says a frame-level address points at one card. The collision domains article says a broadcast address points at everyone on the segment.
Multicast is the gap between them — it points at "whoever is interested", which makes it an address that refers to no machine at all.
If you have never looked, start here
Your machine has already joined some of these.
$ netstat -gOn the machine this was written on, the frame-level addresses come out as
1:0:5e:0:0:1
1:0:5e:0:0:fb
33:33:0:0:0:1
33:33:0:0:0:fbThe first two begin the same way, and so do the last two. That is not a coincidence, and it is what this article is about.
The mapping rule — an IP address stuffed into a MAC address
RFC 1112, of 1989, writes the rule in one sentence.
"An IP host group address is mapped to an Ethernet multicast address by placing the low-order 23-bits of the IP address into the low-order 23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex)."
I ran the rule.
224.0.0.1 -> 01:00:5e:00:00:01
224.0.0.251 -> 01:00:5e:00:00:fbThose two match what netstat -g prints on the real machine exactly. A rule written in 1989, computed today, gives the value the machine reports.
The five bits that go missing
An IPv4 group address has 28 bits identifying the group, and the rule carries only 23 of them.
bits that identify the group 28
bits carried into the MAC 23
bits discarded 5Those five missing bits mean different IP groups land on the same MAC address. How many follows directly.
2^5 = 32 groups share one MACI computed some that collide.
224.0.0.1 01:00:5e:00:00:01
224.128.0.1 01:00:5e:00:00:01
225.0.0.1 01:00:5e:00:00:01
239.128.0.1 01:00:5e:00:00:01Four unrelated groups, one frame-level address. The card therefore accepts frames for groups it has no interest in, and the operating system is left to discard them.
IPv6 fixes this by allowing more room
RFC 2464 gives the IPv6 rule.
"An IPv6 packet with a multicast destination address DST, consisting of the sixteen octets DST[1] through DST[16], is transmitted to the Ethernet multicast address whose first two octets are the value 3333 hexadecimal and whose last four octets are the"
IPv4 01:00:5e + 23 bits
IPv6 33:33 + 32 bitsThirty-two bits instead of twenty-three, which is why the lines beginning 33:33 on my machine carry longer tails.
In theory an IPv6 address is 128 bits, so collisions remain possible. In practice the last 32 bits rarely repeat, so it hardly arises.
Every machine must join one group, always
RFC 1112 requires it.
"every level 2 host must join the 'all-hosts' group (address 224.0.0.1) on each network interface at initialization time and must remain a member for as long as the host is active."
That is where 1:0:5e:0:0:1 on my machine comes from. Nobody configured it; the standard demands it.
And 1:0:5e:0:0:fb comes from 224.0.0.251, the group machines use to find services on the same segment without a central server.
So what does a switch do with it
A multicast address belongs to no machine, so a switch cannot learn it the way it learns ordinary addresses — no frame ever carries one as its source.
The collision domains article established that a frame whose destination the switch does not know is flooded out of every port. Which means that by default, multicast behaves exactly like broadcast.
RFC 4541 states the result.
"Packets will be flooded into network segments where no node has any interest in receiving the packet."
And notes that the cost is not mainly the wasted processing.
"While nodes will rarely incur any processing overhead to filter packets addressed to unrequested group addresses, they are unable to transmit new packets onto the shared media for the period of time that the multicast packet is flooded."
Uninterested machines lose little processing, and lose the chance to send — the same airtime logic as the Wi-Fi article.
IGMP snooping — and an unusually blunt warning
The fix is for the switch to listen in on the messages machines use to announce which groups they have joined, and forward only to those ports.
But RFC 4541 contains a sentence standards documents rarely write.
"Many switch datasheets state support for IGMP snooping, but no recommendations for this exist today."
The document is saying vendors claim a feature that has no specification of what it must do — and that document is itself the attempt to write one.
Which means "IGMP snooping" on two vendors' datasheets need not describe the same behaviour.
When it lies
"Multicast is always cheaper than broadcast." Only where the switch actually filters. Where it does not, it is broadcast under another name.
"A multicast address is the address of a set of machines." It is the address of a group, not of machines. Nobody owns it, and it never appears as a source address.
"My machine does not use multicast." netstat -g says otherwise, and one of those groups is required by RFC 1112.
"A multicast MAC identifies the group." Not fully. Five bits are lost in the mapping, so 32 IP groups share one MAC.
"IGMP snooping works the same on every brand." RFC 4541 says itself that no recommendations existed before it.
Real cases from real work
Case 1 — see which groups your machine is in
Command
$ netstat -gHow to read it Addresses beginning 1:0:5e are IPv4 groups, 33:33 are IPv6. An unexpected group is worth tracing back to whichever program joined it.
What this does not prove The list says what the interface intends to receive, not that any traffic for that group is flowing.
Case 2 — multicast traffic floods the segment
Situation A system uses multicast and unrelated machines slow down too.
How to read it Check whether the switch filters or floods. If it floods, every machine in the broadcast domain loses transmit opportunities, as RFC 4541 describes.
What this does not prove Enabling snooping usually helps, but the actual behaviour varies by vendor, which the standard itself concedes.
Case 3 — two unrelated groups interfere
Situation A new group is configured and machines listening to another one receive what they should not.
How to read it Compute both groups' MAC addresses with the 23-bit rule. If they match, that is the collision described above. The fix is choosing group addresses whose last 23 bits differ.
What this does not prove A MAC-level collision makes the card accept the frame, but the operating system should still discard it. The visible symptom may have another cause.
What this kind of address teaches
Unicast answers "who do I send this to". Broadcast answers "send it to everyone".
Multicast answers the harder question — "send it to whoever is interested", which requires somebody to know who is interested, and that is not in the address.
Which is why multicast needs an extra protocol whose whole job is announcing who has joined what, and why it works well or badly depending on whether the equipment in between is listening to those announcements.
References
Standards
- RFC 1112, August 1989, Host Extensions for IP Multicasting — the 23-bit mapping rule, and the requirement that every host join 224.0.0.1
- RFC 2464, December 1998, Transmission of IPv6 Packets over Ethernet Networks — the IPv6 33:33 rule
- RFC 4541, May 2006, Considerations for IGMP and MLD Snooping Switches — the cost of flooding, and the sentence about datasheets quoted here
Measured on the machine this was written on
netstat -glisting the groups the interfaces have actually joined, both the1:0:5eand the33:33families
Computed here
- The IP-to-MAC mapping by RFC 1112's 23-bit rule, and the count of how many IP groups share one MAC, derived from the number of bits discarded