Home › Routing › IPv6 › Understanding IPv6: A Sniffer Full Of 3s (Part 3 of 7)

Understanding IPv6: A Sniffer Full Of 3s (Part 3 of 7)

By Denise "Fish" Fishburne on February 19, 2018 • ( 8 )

“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 not resolve 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?

Checking in with RFC4291

RFC 4291 section 2.4 lists the varying IPv6 address types. As we noticed in one of my previous blogs, FF00::/8 is of type multicast. In fact, FF02::5 and FF02::6 are OSPF, if you recall.

Getting some ideas now about what those 33:33 are?

Back to Wireshark

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:

Reviewing What We Are Seeing

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

Let’s go look at what some of the RFCs have to say about all this.

Checking in with RFC 7042

RFC 7042 section 2.3.1 states the following:

All MAC-48 multicast identifiers prefixed “33-33” (that is, the 2**32 multicast MAC identifiers in the range from 33-33-00-00-00-00 to 33-33-FF-FF-FF-FF) are used as specified in [RFC2464] for IPv6 multicast. In all of these identifiers, the Group bit (the bottom bit of the first octet) is on, as is required to work properly with existing hardware as a multicast identifier. They also have the Local bit on and are used for this purpose in IPv6 networks.

OK, so 33-33-00-00-00-00 to 33-33-FF-FF-FF-FF are reserved as the destination MAC address for IPv6 multicast. But how did FF02::5 become IPv6mcast_00:00:00:00:05?

What RFC 2464 Says

RFC 2464 section 7 covers multicast address mapping:

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 last four octets of DST.

Is this Really Vastly Different than IPv4?

Does all of this reveal something hugely new and different about IPv6 that IPv4 did not do? Nope. IPv4 just used MAC address numbers I was more familiar with. Admittedly, the IPv4 addresses seemed to “blend in” more with other MAC addresses (01:00:5e for IPv4 versus 33:33 for IPv6).

Let’s look at the unresolved view first:

It’s similar to the pattern we saw with IPv6. Again, the destination MAC addresses that start with “01:00:5e” seem to only appear as destination MAC addresses, and only when the destination IPv4 address is a multicast address 224/8.

Now let’s look at the resolved view:

I’ve gotten used to the FE80. My mind translates those well now. The FF02:: also. The 33:33 in the destination MAC address? That might still take awhile. But you know… two out of three ain’t bad. 🙂