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.
Don't block multicast traffic for IPv6! Basic functions like Neighbor Discovery (ARP in the IPv4 world) is multicast and Router Discovery is multicast. Is you block that your IPv6 connection will not work correctly.
Having clustering traffic for servers on the same vlan as client access traffic does not sound like a good idea to me. I'd think separating the cluster control/state traffic from access traffic would be the constructive solution. Maybe the servers have multiple network interfaces making this simple (and cheaper than managed switches).
If your switch (or more accurately the client's switch) is capable of filtering the multicast packets by address (blocking the multicast prefix) that would be my first suggestion.
Barring that you can put a simple filter device (firewall) between the WAP and the main network that just drops any packets to/from the multicast address range...
It sounds like your customers are bridging the Ethernet and WiFi traffic. The multicast stuff might work better if they used a WiFi router or used what device they have in a router mode instead.
Of course then the link-local stuff will not work. It will have to change to be using a routable multicast address.