This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Host name from IPv6 address

0

I am having a problem with a multicast blaster on my network. When the problem occurs, hundreds of thousand entries are recorded via Wireshark. It seems to happen randomly; two or three times a day. Both the source and destination recorded are IPv6. IPv6 is not configured on the network but that is not to say it is not enabled (most devices that support it these days have it enabled as default.) When I say not configured, I am referring to DHCP/DNS, and customizing anything on the network for IPv6.

Per Wireshark, one of the two sources is : fe80::fe4d:d4ff:fef5:e9b. The destination are the same ff02::1:ffb8:6ed3. I am new to IPv6 but I understand that fe80 is local network and ff02::1 is a local-node multicast.

What I need help with is trying to find what machine/device on the network has these IP addresses. With IPv4, I can use ping -a, but that does not seem to work with these. I believe our router does not have IPv6 enabled.

Any help will be appreciated. Thank you.

asked 15 Sep '14, 12:39

Jeff%20H's gravatar image

Jeff H
6112
accept rate: 0%

edited 15 Sep '14, 22:25

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196


One Answer:

0

What you're looking at are probably neighbor discovery packets, which are sent to a special multicast address called "solicited node multicast". It's basically the replacement mechanism for ARP, which is not used for IPv6 anymore.

Usually, if you need to find out where something is coming from you should try to determine the MAC address of the source, and then log in to your switches to find the port where that MAC address is connected. There should be a command that will show you the MAC address table of the switch. If you can find a port where only the MAC address in question is listed you need to follow the cable from that port to the device. If you have more than one MAC address listed for a port it is usually a connection to another switch. In that case you need to log in to the switch it connects to and repeat your search.

answered 15 Sep '14, 12:47

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Thanks for your response, Jasper. How do I go about determining the MAC address? Other than servers, IPv4 IPs are all DHCP and I can often find the MAC Address there. Not having DHCP for IPv6, I cannot find it the same way.

(15 Sep '14, 13:05) Jeff H

You do have the capture, right? The MAC address is easily found in the decode of the Ethernet layer.

(15 Sep '14, 13:06) Jasper ♦♦

Would this be the correct line item?

Ethernet II, Src: fc:4d:d4:f5:0e:9b (fc:4d:d4:f5:0e:9b), Dst: IPv6mcast_ff:b8:6e:d3 (33:33:ff:b8:6e:d3)

I was originally looking for the 33:33:ff:b8:6e:d3. I am guessing I should have been looking for the fc:4d:d4:f5:0e:9b.

I also had the following:

Source SA MAC: fc:4d:d4:f5:0e:9b (fc:4d:d4:f5:0e:9b)

(15 Sep '14, 13:13) Jeff H

the 33:33:ff:b8:6e:d3 is the destination address - it's sometimes a bit confusing that with Ethernet, destination is the first and source the second address.

Yes, you need to look for that Source MAC fc:4d:d4:f5:0e:9b

(15 Sep '14, 13:16) Jasper ♦♦

I have a feeling I know the next answer. Two of my switches are Cisco SG300, which provides a MAC table. The other two switches are Dell PowerConnect 2724, do not. Guess which switches do not list this MAC addresses... :/ Any other way to determine where these devices are?

(15 Sep '14, 13:31) Jeff H

Ok, maybe not as bad I thought. Both of these MACs are in DHCP (W2012). But what is odd, neither machine has the source IPv6 address. I am using ipconfig and looking at the link-local IPv6 address line.

(15 Sep '14, 13:35) Jeff H

well, not really. I would try to connect to the fe80 address using SSH and Windows RDP to see if I can get a prompt and determine what the device is.

The other thing you could do is filter for the source MAC to see if you can find an IPv4 packet from that same address - you probably know which IPv4 address belongs to which system. The filter would be "eth.src==fc:4d:d4:f5:0e:9b"

(15 Sep '14, 13:36) Jasper ♦♦

SSH would not connect (firewall on the client, I suppose), but using the eth.src was able to provide me with a host name. Both of the two are Windows 7 clients that were recently deployed. I do not see any viruses, malware (or at least per Symantec and Spybot). Any thoughts on what else would cause both machines (at the exact same time) to blast the network?

(15 Sep '14, 13:50) Jeff H

usually neighbor discoveries are performed when a host tries to connect to another host via IPv6 - so it must know (or at least believe) that there is a IPv6 enabled device it may be able to connect to. In most cases a DNS query for a quad A record returned an address.

If you want to get rid of that IPv6 traffic you can just uncheck the IPv6 protocol binding from all network cards for the affected hosts.

(15 Sep '14, 13:53) Jasper ♦♦

Yeah, for the time being I am going to disable the IPv6 binding. Now that I know the source; is it possible to determine the destination? I looked for the 33:33:ff:b8:6e:d3 using eth.dst, but only the same results came up.

Here is the full Ethernet II portion data:

Ethernet II, Src: fc:4d:d4:f5:0e:9b (fc:4d:d4:f5:0e:9b), Dst: IPv6mcast_ff:b8:6e:d3 (33:33:ff:b8:6e:d3) Destination: IPv6mcast_ff:b8:6e:d3 (33:33:ff:b8:6e:d3) Address: IPv6mcast_ff:b8:6e:d3 (33:33:ff:b8:6e:d3) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)

(15 Sep '14, 14:35) Jeff H

Found what appears to be the source of this headache.

http://social.technet.microsoft.com/Forums/windows/en-US/945125a7-035f-4f33-a9d2-c274717d7706/icmpv6-multicast-listener-report-messages-are-flooding-the-local-network?forum=w7itpronetworking

Much appreciate all of your help. You made it easier to understand the problem and hopefully identify the issue.

(15 Sep '14, 15:01) Jeff H

Well, that multicast address is specifically mapped to the IPv6 multicast address, so it's no surprised that only the same results come up. Compare the last 3 bytes of the solicited node multicast to the Ethernet multicast address and you'll see that they match - that's the mapping ;-)

Good to know that I could help.

(15 Sep '14, 15:28) Jasper ♦♦
showing 5 of 12 show 7 more comments