@benjojo Mikrotik has *two* MAC protocols, a single-hop "MAC-Telnet" (IP broadcasts) and multi-hop "RoMON" (ethertype 88bf).

So it would be interesting to know if you've specifically seen the latter on IXPs, as RoMON has its own internal routing – unlike leaving MAC-Winbox/MAC-Telnet open which merely exposes the single router, leaving RoMON open on an IXP (and not setting a HMAC secret) would allow other members to reach pretty deep into one's internal network... (like all the way to some office router with a default password).

@grawity @benjojo ok wow I did not now this about MAC telnet. Any ideas as to *why* it’s implemented as broadcast? To support ip-only clients I guess?

@karppinen @benjojo I believe that's just a workaround for socket API limitations:

1. the primary use case for MAC-Winbox or MAC-Telnet is to connect to devices which might have misconfigured IP, e.g. might not even *have* a working IP address, thus the client cannot rely on IP & ARP to send unicast frames to that device

(e.g. to configure a freshly reset router that *didn't* have the 192.168.88.1/24 defconf applied to it)

(it might be possible to unicast to IPv6 link-local address, but RouterOS used to have the ipv6 package disabled by default for a long time, etc, etc. – sure it would be possible to use them *now* but not 10 years ago)

2. but the client also cannot "manually" send unicast frames to a specific MAC address either, as that needs raw sockets (root privileges) on Linux, and I believe requires a whole Winpcap/Npcap driver on Windows

so the easy remaining option is to send UDP broadcasts, which always go to the broadcast MAC address and therefore definitely reach the target device.

From what I recall, the third-party Linux CLI mactelnet client explicitly says in its readme that it is insecure if you don't make the binary setuid (as then it can't use raw ether sockets and has to UDP-broadcast). Might be misremembering though

Note this is primarily in the "PC → router" direction. AFAIK the target device will *reply* to you using unicast, since its mactelnet service is privileged and can properly do unicast ethernet frames – and I *think* that ROS-to-ROS /tool/mac-telnet connections might not need to rely on broadcasts at all, as ROS itself would of course have a properly privileged client that can do unicast.

RoMON on the other hand does not have this problem, in part because there *is* no "direct" desktop client for it – you always have to gateway through a local Mtik device – and in part because it doesn't carry cleartext Telnet, only SSH and Winbox.

(It has a completely different security problem due to being routable – fortunately not IP-based but acting as its own network layer – but still, if someone's router at an IXP has RoMON open, and if their internal core is also Mikrotik-based with RoMON, then you could just do /tool/romon/discover on your router and see *through* that IXP router and all the way through their core.)

@grawity @benjojo right, yeah. I was assuming that IP broadcast required root too, so I didn't really see a point of that workaround vs sending the raw frames to the destination MAC

@karppinen @benjojo yeah, it doesn't require root, but also Winbox was Windows/Wine-only until like 2024 so it's probably the only universal option they had

@benjojo nice writeup

@benjojo Any correcctions or additions for this list?

I wasn't able to find anything special for ES-IS.
Would you suggest to filter all 0xff addresses for VRRP?

# DEC-MOP
ab:00:00:02:00:00

# RoMON
6c:3b:6b:48:0e:8b

# STP
01:80:c2:00:00:00 IEEE 802 standard Bridge Group Address
01:00:0c:cc:cc:cd Cisco proprietary Per-VLAN Spanning Tree address
03:04:08:00:07:00 Extreme Networks address

# CDP
01:00:0c:cc:cc:cc

@benjojo

# IS-IS
01:80:c20:0:00:14 All L1 IS devices
01:80:c2:00:00:15 All L2 IS devices
09:00:2b:00:00:05 All IS devices
09:00:2b:00:00:05 IS-IS Hello

# ES-IS
?

# LLDP
01:80:c2:00:00:0e
01:80:c2:00:00:03
01:80:c2:00:00:00

# VRRP
00:00:5E:00:01:XX

# OSPF
01:00:5E:00:00:05 All OSPF routers on a network segment
01:00:5E:00:00:06 Designated routers on a network segment.

# IPv6 RA
33:33:00:00:00:01