On Wed, May 18, 2011 at 01:34:33AM -0700, David Stevens wrote: > Daniel Veillard <veillard@xxxxxxxxxx> wrote on 05/17/2011 08:47:11 PM: > > > Like Dan I'm worried by removing this functionality. As far as I > > know most switches learn IP from their clients using ARP snooping, > > this is I think more resilient and minimize disruption in case of > > port switching. > > Daniel, > Although I don't agree, I plan to add the option. I was hoping > to make DHCP snooping the default, at least. I understand your viewpoint, and once everything is ready then yes we can make it the default, but at this point this just breaks migration, so we just can't . > What concerns me is that the existing mechanism can be almost > trivially subverted, so it may create a false sense of security. It > really is not spoof protection in general -- but that is the point > of the filtering. If you believe the VM when it tells you it can > use an IP address, filtering just means he has to reboot in between > hijacking multiple addresses he wants to spoof. > There should be no reason why DHCP wouldn't work on a migrated > VM as well (the expectation being that the address, and therefore subnet > and DHCP server) would continue to work in the new location. for that the IP need to be sent along with the domain to be able to rebuild the rules on the target node, and that's not currently the case unless I'm mistaken. > Static addresses (or a set of possible IP addresses, with > the other patches I plan) can be used if you need to avoid DHCP, > of course. Then an admin could give a list of allowed addresses > and the VM could use any (or all) of that set, configured through > any mechanism. > I'm pressed for time at the moment, so it may be a few weeks > before I have the revisions to resubmit. But my plan is to incorporate > all of the comments I've seen so far in that revision. Okay, understood ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list