Comment 9 for bug 720605

Thank you for testing! What I am trying to achieve here is a balance between usability and protection, erring on the side of protection with an eye towards consistency. If someone enables the firewall, they expect a certain level of protection.
 * We allow pings in general, so I think allowing the multicast ping reply is ok here.
 * We allow service discoverability via mDNS, but not actually the service being protected. On the one hand, this causes a usability issue because the user can see the service, but can't connect to it, but on the other hand, the point of a default deny firewall (ie, how ufw is configured by default once enabled) is to block. Allowing mDNS provides enough information for an administrator (who has opted into the firewall protection in the first place) via the logs, to simply allow the port that mDNS is advertising (eg for DAAP music sharing)
 * We don't want to allow all multicast traffic in general, as mDNS is really the only one that is known to be useful for bastion hosts (eg file or music servers), desktops, laptops and the like. People who need the other can add them, as those are specialized environments anyway. I filed bug #740256 for restricting multicast more.

That said, I would like to err on the side of caution and be more restrictive, but am open to allowing other IPV6 multicast traffic if there is a common need for it (like you suggested).