Re: [libvirt] [PATCH 2/2] bridge driver: don't masquerade local subnet broadcast/multicast packets

I'm not sure if everyone that needs to see this discussion are subscribed to RH bugzilla bug #709418 so I will repeat my comments from comment #12 on that bug here: On 13-05-27 10:34 PM, Laszlo Ersek wrote: Multicast is much wider than just 224.0.0.0/24. Per my patch in attachment 526549 [details], it's in fact 224.0.0.0/4. All multicast needs to be exempt from NAT. Quoting from Wikipedia article http://en.wikipedia.org/wiki/Multicast_address: IPv4 multicast addresses are defined by the leading address bits of 1110, originating from the classful network design of the early Internet when this group of addresses was designated as Class D. The Classless Inter-Domain Routing (CIDR) prefix of this group is 224.0.0.0/4. Indeed, Wikipedia is not authoritative, but it does provide a good starting point to finding authoritative information if you want. I suppose the authoritative doc is at http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml or somesuch. It does not explicitly say 224.0.0.0/4 but it certainly implies it in discussing the entire space from 224.0.0.0 through 239.255.255.255. This should be /8, not /24. There are many multicast protocols that operate outside of that 224.0.0.0/24 network. In fact they all must. 224.0.0.0/24 is reserved and assignment must be made from IANA. Let me give you a scenario where your 224.0.0.0/24 fails to correct the problem: Imagine you have a cluster of VMs all with a network address of 192.168.122.[2-10]/24 and 192.168.122.1 is your VM "server". Now imagine those VMs are using a multicast address of 226.1.2.3 (just for argument's sake). Each node will be listening on 226.1.2.3 for other "members" of the group to build a list of members. But once the packet from (say) 192.168.122.2->226.1.2.3 goes through the "VM host"'s NAT it will look to the other group members to be from host 192.168.122.1, so they all add 192.168.122.1 to their member list. Then 192.168.122.3 sends it's packet to 226.1.2.3, it goes through NAT also and all of the group members notice they already have 192.168.122.1 in their group and just ignore it. That goes on for all of the [2-10] nodes and none of them get added to the group list. That's because NAT broke the protocol. Further, to your arguments in comment #13 in BZ #709418 about needing to map ports > 1023 for security: The source port mapping goal has some specific parameters to it. It's trying to avoid a VM from masquerading as it's host and leveraging it's host's permission in the network. But that's only a problem because the VM is masquerading as the host. When you exempt multicast from masquerading you no longer have the problem of the VM being mistaken for the host and therefore you don't need the "quasi-security" of not allowing the VM to use ports < 1024. Put another way, mapping the source port numbers is only a requirement because the VM is borrowing the identity of the host. Once you eliminate the identity borrowing you can eliminate the need for the safety guards that that lending is putting in place. Cheers, b.