[one-users] IP(v6) network enhancements

[Stefan Kooman]

Quoting Ruben S. Montero (rsmontero at 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 / info at bit.nl