I work on a product that consists of a number of headless Linux boxes that work together as a cluster.
These boxes synchronize their state with each other by sending proprietary-format link-local IPv6 multicast packets (to
ff12::xxxx%en0). These packets can take up a non-trivial amount of bandwidth when the system state is changing quickly, but that's okay because the Linux boxes are running over a Gigabit Ethernet LAN and there is plenty of bandwidth to spare.
The problem happens when a customer decides he'd like to use his laptop (or iPad) as a client to the system while roaming the building, and so the customer adds a WiFi access point to the LAN and sets up his laptop to communicate (via unicast) with one of the Linux boxes over the WiFi.
This typically "sort of" works, but the problem is that all the multicast synchronization packets sent by the Linux boxes are now being sent over WiFi, even though the client(s) don't need them or use them. As a result, WiFi bandwidth is often impacted, sometimes to an unusable state, and the customer complains that our system isn't working properly.
We could, of course, just tell the customer "don't do that", but WiFi is very useful and I'd like to find a more constructive solution to this problem than just forbidding WiFi. Is there some (reasonably simple) way to configure a WiFi access point to filter out these synchronization multicast-packets? Simply getting the WiFi access point to not handle IPv6 packets would be sufficient for our purposes, since the client software can run over IPv4 if necessary, but some more nuanced filtering that doesn't preclude all IPv6 traffic would be nicer.
Note that the most common access point installed by our customers is Apple's Airport, but if there is another (more configurable) WiFi access point product that would work better, replacing the access point with a different model is an option.