OpenNebula

Hi Laurent

First, thanks for your detailed feedback! Let see if we can improve IPv6 ;)

Laurent Grawet wrote:

Hi,

We are currently testing OpenNebula IPv6 implementation. Here is a non exhaustive list of problems we are currently facing:

1. In IPv4/6 networks, IPv6 context variables are not pushed to the VM (IP6, GATEWAY6...)

I cannot reproduce this, it is getting all the defined context variables see below

1. Context variables are pushed if we force IPv6 address in vm template. But there is no IP6_ULA variable in vm templates, only IP6_GLOBAL. If we use it for ULA address, the vm instance shows two times the same IPv6 (in ULA and GLOBAL fields)

These are the current context variables:

const char*  VirtualMachine::NETWORK6_CONTEXT[][2] = {                                                                                               
        {"IP6", "IP6_GLOBAL"},                                                                                                                        
        {"GATEWAY6", "GATEWAY6"},                                                                                                                      
        {"CONTEXT_FORCE_IPV4", "CONTEXT_FORCE_IPV4"}
};   

i.e. NIC[IP6_GLOBAL] ---> CONTEXT[ETH0_IP6]

What else would you like to see here?

1. We receive IP assignments from our network team, but we can't choose IPv6 addresses because we are forced to use SLAAC addresses. We don't want to use SLAAC on virtual servers and it is not a good practice to configure theses addresses statically.

This is not our experience (but I've also seen very different approaches, see for example GATEWAY6 which is not really needed by an IPv6 network), IPv6 network should be managed using SLAAC or a combination of neighbor discovery for the prefix + DHCP6 for the rest of parameters (e.g. DNS) I agree that forcing EUI64 for the host ID may be not assumed for all institutions and we could implement other algorithms like random or static and update context to configure the host for this. Note however that link-local addresses may be a problem...

I propose to open a backlog feature to expose other host-id generation algorithms including random or static.

I think that as a work around that you can generate 1 leases AR's setting the MAC according the IPv6 leases given by your team. This should be fairly ease to automate till we clear the host-id part...

1. We can force any IPv6 address on the VM if there is no IPv6 range defined in virtual network. It is not coherent with IPv4 behavior.

OK, Verified. I'll open a separate issue for this.

1. There is no way to convert IPv4 network to dual stack and this is a real problem!

You can use IP4/6 Address Range it was designed for dual stack hosts. For example, this a NIC with IPv4 + IPv6 addresses:

NIC    
AR_ID    0
BRIDGE    vbr0
IP    10.0.0.3
IP6_GLOBAL    2002::400:aff:fe00:0
IP6_LINK    fe80::400:aff:fe00:0
IP6_ULA    fd00::2:400:aff:fe00:0
MAC    02:00:0a:00:00:00
NETWORK    Dual Stack
NETWORK_ID    1
NETWORK_UNAME    ruben
NIC_ID    0
SECURITY_GROUPS    0
VLAN    NO

1. So we tried to configure an IPv6 address range in addition to the IPv4 one in a virtual network. The IPv6 leases are never used when we force IPv4 and IPv6 addresses in vm network interface but the IPv6 address is assigned to the VM! If we configure in vm template a dedicated IPv6 network interface with only one (forced) IPv6 address (and no IPv4) OpenNebula will also pick the next available IPv4 address.

The Dual stack IP+IPv6 address range is the preferred option, as shown above.

Best regards,

Laurent

Hi Ruben,

The problem only shows up with virtual networks with IPv6 ULA address range defined (no IPv6 Global range). The VM instance isn't getting the ETHx_IP6 and ETHx_GATEWAY6 context variables.

• Public IPV4/6 network with Global IPv6 range : context variables are pushed to vm instance
• Private IPV4/6 network with ULA IPv6 range : context variables are NOT pushed to vm instance

Those variables are pushed if we force the IPv6 ULA address with the IP6_GLOBAL= vm template variable. But in this case, the nic is getting the same IP twice : one in IPv6 ULA field and one in IPv6 GLobal field. It looks like there is no way to force IPv6 ULA in VM template, only IPv6 GLobal. Also, I don't really understand the need to differentiate IPv6 Global and ULA addresses treatment inside OpenNebula.

The last point is how to convert an IP4 address range to IP4/6 address range ? All our virtual networks have a full IP4 range defined so there is no room left for a new IP4/6 range.

Thank you very much,

Laurent

Hi Ruben,

Can we expect to see some improvement about this matter in 5.0 ?

Thank you,

Laurent