You may have IPv6 package disabled, but everything else nowadays has IPv6 enabled by default. Well, “everything else” is slight overstatement and wishful thinking on my part. But the fact is that e.g. Windows have IPv6 enabled by default since Vista, so for more than 10 years now. And once something has IPv6, it tries to use it. Addresses from fe80::/16 are so called link-local addresses and they are used only in local network segment. In a typical unmanaged network, quite a lot may be going over IPv6, even without the owner knowing about it.
If it makes trouble for you, find what causes it. Start with more details in Torch (check Port and Protocol), it may give you some clue. It would be also useful to get MAC address of that device, to help you locate it (you could use MAC to find what IPv4 address it has and it would probably help you find it). I’m just not sure how to easily do it without IPv6 package enabled. So maybe enable it (it doesn’t do anything bad) and then you should find it in IPv6->Neighbours (ping the fe80::… address first if it’s not there).
Doesn’t really look like broadcast though as the destination is not a broadcast address. Perhaps include the port so you get an idea what the traffic is.
Actually IPv6 package is not enabled in my MikroTik. So, pointed command line may not executed. Please note that, I have enabled VPN on reported location.
fe80::3490:8df5:7efd:361e translates to 36:90:8d:fd:36:1e
fe80::201:7aff:fef2:c7bc translates to 00:01:7a:f2:c7:bc
If that helps you track the device down by MAC. It’s not a guarantee.
What was the “jam” you observed? IPv6 can exist especially in a link-local capacity without any issue. The exception would be if someone has set themselves up as a router and is MiTM’ing traffic. I’d expect to see them issuing a global prefix though.
Unfortunately, that’s not relible. Take any Windows machine, compare its MAC and IPv6 link-local addresses and you’ll see they don’t translate like this.
In the above example, the 2nd translation is likely valid and the first one isn’t.
Those statically mapped addresses have ff:fe in the middle, which is what you remove to get the MAC address (and also flip the 02 bit on the first octet).
When the ff:fe is not there, it is a dynamically mapped address (“privacy”) and this translation won’t be possible.
That second MAC address is allocated to:
00:01:7A Chengdu Maipu Electric Industrial
Maybe the poster knows what device like that he has.