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