I don't work in IT, and I'm a bit biased on this topic, but my understanding is that these protocols are chatty and can flood the network on large deployments (e.g. an entire campus that shares the same subnet). They also tie up WiFi airtime. So they're usually explicitly blocked, along with anything else multicast related.
Also, Enterprise IT is often averse to anything that's not centrally managed, and Bonjour is the anthesis of centralization (it's all peer-to-peer). Some networks turn on client isolation so that peers can't talk to each other at all, often in the name of security.
That said, there are ways to get this stuff to work right in an enterprise setting. It requires careful network design to keep broadcast domains small, ideally with an mDNS Reflector running somewhere. All the major WLAN vendors have custom options for supporting it, with varying levels of customizability:
Admittedly, it's hard to get right, the apps that need it are not usually business critical, and there's not many apps to test with... so most IT shops just turn it off and avoid the additional headache. Which is unfortunate, because it effectively kills off any peer-to-peer functionality on the LAN.
Disclaimer: I work at Google, but not on any of the teams mentioned in the article. I am a big fan of mDNS, but that's my personal opinion.
In my experience, it's multicast restrictions. In our case (~8 years ago), the default setup from Cisco was to restrict multicast to within a VLAN. Outside of that, I've seen strict multicast rules that only allowed known services.
It used to be rare for IT to have any real practical UDP/multicast/broadcast experience, mostly because general support was so bad.
I'm no expert, but I think most enterprise & university networks enable client isolation in the routers.
If I know the IP of a friend on the LAN, I can connect to him directly, as normal - the connection will not be blocked by the router. But other than that, the router shows my device a view of the world in which it is the only thing connected to the LAN.
Enumerating the private IP space and trying to connect to all of the possible addresses might reveal the actual stuff though? But the multicast protocols I assume use a smarter and more efficient approach which gets blocked by client isolation.
Client isolation is just wireless clients on the same AP. PIM routing acts like a proxy, and the multicast address for whatever service your routing will be proxied to the clients local multicast address.
Ruckus calls it bonjour fencing, and has pretty good support for creating useful policy.
Client Isolation mode is layer 2 -- its done at the Wireless AP. It should prevent enumeration of the private network space (if the other peers are on the Wireless AP). Neither Multicast nor unicast will work for traffic between clients.
Besides security policy, mDNS uses a link-local multicast address, so routers will not forward it to other network segments. Many operators utilize a number of VLANs on their wireless networks, so this creates an issue when devices in separate VLANs attempt to discover each other over mDNS.
This is usually solved through some sort of mDNS proxy, but you don't really want to proxy everything. If your phone discovered all of the apple tvs and chromecasts across campus, then it wouldn't make for a good user experience for anybody.
My home network consisted of two subnets, and even in such a simple configuration I was never able to get Chromecast working, which also uses mdns.
Mdns proxy would have been the solution, but I was never able to get it to work. It seemed to me that no one actually managed to get it to work, based on my Google searches at the time.
Of course, getting it to work on the corporate network was even less likely.
A subnet or VLAN = broadcast ___domain. Usually broadcast ___domain = multicast ___domain.
Any standard firewall contains tools for PIM (protocol independent multicast) routing. PIM router as the GW for both subnets / VLANs does the trick fine, and is easy-ish to setup. Using this for mDNS printer discovery on a guest network to an internal printer network.
This article is right in that multicast is stupid to use for this, but wrong in that the purpose of a net admin is to NET ADMIN. Make it work and quit whining, multicast is not a new or difficult problem.
Just blocking everything between clients is an easy and strong security policy.
Wireless and wired networks commonly are in different network segments, vs Bonjour etc. generally assuming devices are in the same and using only local multicast - so the network explicitly has to provide a proxy bridging that traffic between segments, not having rules forbidding traffic between them (which also would be normal to have) isn't even enough.
> Just blocking everything between clients is an easy and strong security policy
Or a weak one from the perspective that security must address usability since otherwise users will route around the “secured” system for functions which should be performed within that system.
Multicast on Wi-Fi is quite costly so it tends to be restricted. It is possible to restrict it properly using igmp snooping but there are a lot of rules you have to follow to make it work, it’s easy to make a mistake and typically it isn’t really tested.
Also protocols like Bonjour by default only work on the local network which at home might well be all there is while at work might be one of many.
Deliberate network policies to not forward multicast. So you can only see multicast advertisement on your local segment, and it always seems the device you want to see is on another network segment.
because peer to peer -- ie client to client comms is blocked by the AP for security. Smarter wireless controllers allow selective protocol to pass, so you might be able to allow just mDNS (bonjour). Now this is just for wireless peers, it will allow mDNS to work with other wired clients not using that AP. Its a setting that can be modified.
