"What the heck?" Yup, that pretty much summed up my confusion the first time I saw it. A sniffer trace full of threes.
The first thing it reminded me of was my days with Token Ring and locally administered addresses (LAAs). This was for two reasons:
- I could only see these MAC addresses being used as destination MACs, not as source MACs. This was the same with my experience with LAAs in token ring
- The MAC addresses seemed so pretty and clean, like the Token Ring LAA typically used for a 3745 IBM front-end process -- 4000.3745.0001. Just look at them. Four threes, followed by a bunch of zeros, and then just one little number.
Help from Wireshark
I hope you are familiar with Wireshark; I use it all the time. It shows "reality" on the wire, which is crucial if you are a network detective trying to solve a whodunit.
If you are familiar with Wireshark then you might know that I can configure how the MAC addresses are displayed in the columns via the Wireshark preferences. As you can see below, I have set the preferences to notresolve the MAC addresses for me, but to keep them unresolved.
The above Wireshark preference settings result in the below display, where all the MAC addresses are left unresolved.
Before we move on, let me ask you a question. Do you notice any pattern where the 33:33 destination MAC addresses are used? Look closely.
What's with that FF02:: stuff?
Getting some ideas now about what those 33:33 are?
Let's get Wireshark to help us here. We will modify the preferences to request that Wireshark actually resolves the MAC addresses when it displays its results.
And here are the new results:
Okay, now what do you see? Here's what I see:
- Wireshark changed the "33:33" to "IPv6mcast"
- "IPv6mcast" only shows up in the destination MAC if the destination IPv6 address is a multicast address (ff02)
- Destination IPv6 address FF02::5 became IPv6mcast_00:00:00:00:05
- Destination IPv6 address FF02::6 became IPv6mcast_00:00:00:00:06
Next page: Off to the RFCs!