[one-users] IP(v6) network enhancements

[Ruben S. Montero]

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 <stefan at bit.nl> wrote:

> 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
>



-- 
-- 
Ruben S. Montero, PhD
Project co-Lead and Chief Architect
OpenNebula - Flexible Enterprise Cloud Made Simple
www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20140220/2265082b/attachment-0002.htm>