On Mon, Feb 26, 2007 at 04:09:58PM +0000, Mark McLoughlin wrote: I think its fine to let the ordering be done based on network name. eg if the user wants an explicit ordering, then they can name their network '00default', rather than us munging the names. Hmm, in guests more explicit dependancy info 'web1' requires 'db1', except that this is pretty much an impossible problem to solve. eg, you can start 'db1' first, but how do you know how long it takes for db1 to boot up & start accepting connections. So I think ordering is prety much an impossible problem to solve in a generally useful case. Picking a range like that is fine, if its easy for the admin to change it in a config file - just need to make sure if the admin changes it (or say wants to disable it entirely), it doesn't get reverted / renable during an RPM upgrade. The former can be dealt with by marking %config, but not sure how we'd prevent deletion of the default network being reverted upon update. Thats really just moving the problem elsewhere - we'd just need another config option somewhere else to spec what the 'auto' range mapped to. Generate it in %post and write it into the config file ? That's the approach DBus uses for its auto-generated UUID Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

On Fri, 2007-03-02 at 17:15 +0000, Daniel P. Berrange wrote: Right, whatever that entails :-) So, we had two primary motivations for creating virtual networks: 1) Offline support - i.e. support inter-domain communication even when offline 2) Network switching - e.g. switching your laptop between different wireless networks However, with IPv6, the combination of link-local addresses, address auto-configuration and network renumbering should largely eliminate these problems. The conclusion then is that you mostly do want bridging with IPv6 - i.e. you want to bridge all guests onto your physical network whereby they will auto-configure using router advertisements on the physical link. One could imagine us allowing IPv6 virtual networks, where Dom0 acts as a proper IPv6 router advertising a delegated prefix to guest domains, but I'm not sure why that would be useful to people. The question, though, is how to make IPv6 available to guests which are connected to a virtual network out of a need for e.g. offline support. You still want NAT etc. for IPv4, but what to do about IPv6? The analogy, I think, is what would happen if your DSL provider statically allocated an IPv6 prefix to you while still also dynamically allocating an IPv4 address to you. You want to NAT IPv4 traffic using the IPv4 address, but you want your IPv6 traffic to be bridged to the IPv6 over PPP link in order to e.g. get router advertisements from the ISP end. That leads to the rather ugly conclusion that we should bridge IPv6 traffic from the virtual network to the physical interface, while still forwarding IPv4 traffic using NAT. In order to do that, we're going to need a) "shared physical interface" configuration i.e. a per-interface flag that determines whether other interfaces are allowed to bridge to it, b) an ipv6-only loopback interface for connecting the virtual network's bridge to the shared physical interface's bridge and c) a way for libvirtd to automatically switch the the virtual network's bridge to the currently active physical interface. That's all pretty far out stuff. In the mean time, I think all we can do is add an "ipv6 enabled" flag which would just ensure that the virtual networks interface in Dom0 has a link-local address. Any thoughts on all this are most welcome. Cheers, Mark.

On Wed, 2007-03-07 at 18:15 +0000, Daniel P. Berrange wrote: My understanding is fairly limited, newly acquired and all pretty theoretical, so beware :-) link-local addresses are only valid on the local link, so e.g. a router won't forward such packets. So, my point is that link-local addresses gives you offline support, since domains can reach one another. How useful in practice that is, I don't know. You don't go typing in IPv6 addresses, so I guess it's only really useful if you can look up the guest's address in DNS or mDNS even when offline. It's not clear to me how e.g. netgear would implement that in their routers. The obvious, but lame way to do it would be for your machines to only have link-local addresses and outgoing traffic gets NATed. That would suck, and you can't even do NAT with IPv6 apparently. Another way you could imagine would be for the your router to act as an IPv6 router for a delegated prefix, but I'm not sure how the ISP would communicate what that prefix should be to the router. Same with our situation, I'm not sure how a Dom0 acting as an IPv6 router would figure out what prefix has been delegated to it for its guests. The final way is that the DSL router just blindly bridges all IPv6 traffic onto the PPP link and, so, machines on your network are talking directly to an IPv6 router on the ISP's side which knows what prefix you have been delegated. Looking at rfc2472, IPv6 over PPP, I think that's the way it's supposed to work. That's fine, except it's really funky when you consider that your DSL router is still NAT-ing your IPv4 traffic. So, it's acting as a IP level router for your IPv4 traffic and a link-level bridge for your IPv6 traffic. That's doable, but it sounds bizarre to me. I guess it's no more bizarre than the fact that iptables works on a linux bridge, though. Oh, yeah - the firewall issue. Your firewall on a DSL router falls naturally out of the fact that it's doing NAT, but it'd need to actual IP filtering as it's bridging your IPv6 traffic for you to have the same firewall rules for IPv6. Uggh. Cheers, Mark.

Daniel P. Berrange wrote: IPv6 has a way that hosts can choose a (semi-)random upper 64 bits as well. Unfortunately as far as I can see it's deprecated :-( Anyhow, you can read more about it here: http://www.faqs.org/rfcs/rfc3513.html (section 2.5.6) http://www.faqs.org/rfcs/rfc3879.html You might also consider using link-local addresses (which are not deprecated), since the guests are supposed to be directly connected to each other. I'm not sure of the implications of that though ...? Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)