Thanks Stefan. Now, It make sense. So: 1.- Added a new issue for the address generation: http://dev.opennebula.org/issues/2740
2.- Extended the description of #1818 to include the "alias" functionality: http://dev.opennebula.org/issues/1818 THANKS! Ruben On Mon, Feb 17, 2014 at 11:36 AM, Stefan Kooman <ste...@bit.nl> wrote: > Quoting Ruben S. Montero (rsmont...@opennebula.org): > > Hi Stefan > > > > The IPv6 design in OpenNebula is basically designed to work with the > > auto-configuration features of IPv6. An IPv6 capable host will always > > have link-local addresses for all their interfaces. AFAIK you cannot > > disable IPv6 stack per interface. > In linux you can do so quite easily: > > echo 1 > /proc/sys/net/ipv6/conf/$interface_name/disable_ipv6 > > >So it really does not make sense to have one interface for IPv4 and > >other for IPv6, as the IPv4 will also have the link local addreses > >(plus the host multi-cast address). > I agree with you that having seperate IPv4 and IPv6 interfaces > (normally) doesn't make much sense. Quoting myself here: > > "3) two different interfaces, one for IPv4 and one for IPv6." > > I didn't make myself clear on that point. Just like you I would like to > avoid having seperate IPv4 / IPv6 interfaces. But at present the only > way to provision a (contextualized) vm with or without IPv6 is to give > it an interface in a "IPv4 only" network or a "IPv6" network. If you > would like to combine "IPv4 and IPv6" in one vnet (dual-stack) and > ENFORCE_IPV4, a vm will always get an IPv6 address. There's currently no > way to disable that. The thing I would like to propose is the defintion > of a "dual-stack" network with the following attributes: ENABLE_IP, > ENABLE_IP6, ENABLE_DUALSTACK, actually funtioning as "switches". > > > > About the generation of the host-id (the 64 lower bits) can be > > generated: following the modified EUI-64, based on the IP, or by any > > other means (usually random generation is accepted as a more secure > > option). But I see this as part of the guest configuration and > > probably not for context (although you could generate this through a > > context variable or using the IPv4 address...) > > Yeah, this whole IPv4 / IPv6 enable/disable thing can also be handled > through contextualization. We could change the behaviour based on some > template attributes and fix networking at startup. > > > > So the ideal setup is to have a router in your virtual network > > advertising the IPv6 network prefix (e.g. radvd or zebra) and then let > > the ICMPv6 protocol autoconfigure the interface. The addresses shown > > in OpenNebula are supposed to match those obtained by the previous > > procedure (as long as the prefix advertised is the one configured in > > the vnet). > > The downside of having RA's in your network is that vm's that only > need/want IPv4 (for whatever reason) have to be adjusted beforehand not > to do anything with IPv6 autoconfiguration. On the other hand, if your > using VRRPV6, because of network redundancy, routers are obliged to sent > them (RA's) and also have to respond to RS requests (RFC 5798) [1]. > > > > Currently, the only way to add more IP addresses is to add more > > network interfaces to the VM. Probably a nice feature could be a NIC > > of type "alias" or "virtual" so you get the lease from the vnet, but > > not an additional nic. The context script can simple "ip addr add" the > > IP from the virtual NIC through context. > > Exactly, having a "alias" possibility would be nice. Escpecially if you > would like to have all ip administration consistent in OpenNebula. You > wouldb able to can query the template for IP info and match that to > other ip administration (i.e. reverse dns entries) for consistency > checks. This "alias" feature might overlap / complement [2]. > > > > > Probably, I am not fully getting your proposal... > Does it make more sense now? > > Gr. Stefan > > [1]: http://tools.ietf.org/search/rfc5798#section-6.4.3 > [2]: http://dev.opennebula.org/issues/1818 > > -- > | BIT BV http://www.bit.nl/ Kamer van Koophandel 09090351 > | GPG: 0xD14839C6 +31 318 648 688 / i...@bit.nl > -- -- Ruben S. Montero, PhD Project co-Lead and Chief Architect OpenNebula - Flexible Enterprise Cloud Made Simple www.OpenNebula.org | rsmont...@opennebula.org | @OpenNebula
_______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
