OpenNebula

Could you elaborate a little the features you would like to see in OpenNebula to support IPv6?

Hi Ruben,

it should be able to create ipv6 networks through onevnet in template files with RANGED support (or maybe the radvd ?).

best regards,
aNj

Hi, yes, being able to assign IPv6 addresses to new instances would be great, getting IPv4 public addresses for many virtual hosts will get more and more difficult and makes also little sense.
AFAIK from the KVM side there should be no issues.

Will Sunstone already support v6?
How about the other daemons?
It seems to all only listen on v4 sockets.
...
tcp 0 0 0.0.0.0:9869 0.0.0.0:* LISTEN

Hi,

For the OpenNebula core (oned), I'm proposing the following, reusing most of the OpenNebula internals (ie. no database changes, no changes to MAC address derived from IP address, etc.).

Instead of managing IP addresses directly (as for IPv4), for IPv6 OpenNebula would be managing 64-bit prefixes.

In oned.conf we would add an IPV6_MAC_PREFIX option: The IPv6 16-bit MAC address prefix. The prefix should probably be different than the IPv4 MAC_PREFIX (however MAC colisions would be very unlikely for a single site, using the same PREFIX would be possible).

OpenNebula would use 64-bit suffix length for each VM. This is the minimum size for each Vnet assignations. I have found 64-bit to be quite common, and seems to be the recommanded minimum allocation size by the IETF, RFC 4291, etc (calling for other OpenNebula users if you have experience with IPv6 deployment...)

Internally OpenNebula would always use the 32 least significant bits from the 64-bit IPv6 prefix as the prefix lease assignment. No DB changes to network_pool or leases tables required. For IPv6, the network_pool template would have a NETWORK_MASK of 0.0.0.0. When OpenNebula sees a 0.0.0.0 mask it would know it's an IPv6 Vnet. When a lease is requested, OpenNebula assigns a 64-bit prefix from the Vnet pool, and insert the 32-bits least significant bits of the prefix in the leases tables as it would normally do for an IPv4 address.

Scenario A: a small organization (Organization A) gets a /56 prefix from its ISP. It will be using the entire /56 for their OpenNebula Cloud, using IPv4 for other internal purposes, and creates an IPv6 Vnet with the /56. This scenario makes 256 possible leases assignments (256 IPv6 VMs / NIC).

Effective 64-bit IPv6 prefix (as seen by the VM and shown in OpenNebula interfaces):
[56-bit suffix provided by ISP][8-bit OpenNebula lease]

Scenario B: A medium organization (Organization B) gets a /48 prefix from a RIR or its ISP. Typically this would allow this organization to have 65536 64-bit prefixes / subnets. But it decides to split their prefix in 4 /50 of 16384 64-bit prefixes each, uses a 2 for internal purposes, and adds the 2 remaining /50 to an OpenNebula IPv6 Vnet. This scenario makes 32768 possible leases assignments (32768 IPv6 VMs / NIC).

Effective 64-bit IPv6 prefix (as seen by the VM and shown in OpenNebula interfaces):
[48-bit suffix provided by ISP][2-bit local /50][14-bit OpenNebula lease]

For both scenarios :

No changes to the OpenNebula leases table:

Effective 32-bit (OpenNebula leases table compatible):
[least significant 32-bits from the effective IPv6 prefix]

No changes to the MAC address generation. The resulting 48-bit OpenNebula generated MAC address, based on the 32-bits lease, would look like this:

Effective 48-bit MAC address
[16-bit IPV6_MAC_PREFIX][least significant 32-bits from the effective IPv6 prefix, as for the leases table]

Any OpenNebula users here familiar with IPv6 deployment? What do you think of limiting OpenNebula leases assigments to 64-bits?

I'm also proposing to help with the development of IPv6 leases/Vnet support in OpenNebula.

Thanks

Simon

Hi Simon,

Our initial thoughts is assuming that people interested in IPv6 will either use the modified EUI-64 format to generate the host ID based on the MAC or a DHCPv6 for this. This is done by at the guest level.

So, basically I think we have to keep the MAC generation process and lease management (currently based on the IP, that will also be useful for IPv4 mapped addresses) and let the guest generate the IPv6 address based on that. We've tested this and it seems to work.

I like the idea of having two different prefixes. And probably we need to have aliases for people using IPv6 that will only set MACs. Something like MAC_START instead of IP_START. But this are aliases, keeping the same internal logic.

What do you think?

Ruben

Hi Ruban,

I was initially trying to find an implementation that would require a minimum of amount of work to the OpenNebula core. But if I get you right, your proposition makes a lot more sense and is much more practical.

From what I understand, you are proposing that, contrary to OpenNebula IPv4 Vnets, in IPv6 Vnets OpenNebula would manages MAC address leases instead of managing IP leases. In an OpenNebula V6 Vnet, the actual IPv6 address would be determined FROM the MAC address, not the other way around (in OpenNebula V4 Vnets, the IP address dictates the MAC address).

I am not sure to get your MAC_START suggestion.

OpenNebula would need a way to generate the MAC addresses that are to be assigned from that Vnet.

For example, MAC addresses for V6 Vnets could be generated like this :

<16-bit IPV6_MAC_PREFIX><16-bit OpenNebula Vnet ID><16-bit lease ID>

That would allow a total maximum of 65536 Vnets and a maximum of 65536 IPv6 addresses per Vnet, which seems fair.

From the MAC address, the VM would get to use the following IPv6 addresses for each IPv6 NIC it has :

<fe80>:<modified RFC3513 EUI-64> => IPv6 Link Local address
<OpenNebula V6 Vnet prefix, may be smaller but no larger than /64>:<modified RFC3513 EUI-64> => IPv6 Global address

The Global address could be set with autoconfigure (if configured on the NIC bridge), or DHCPv6 or using VM template CONTEXT. We could hide the Link local address from OpenNebula and have only the VNM know that.

Example:

You get a /64 IPv6 prefix (subnet) from your upstream
You create a V6 Vnet in OpenNebula with the /64 prefix
OpenNebula gets the next Vnet OID available from the DB, ex. 16 (which would be 0x0010 in hex for our 16-bit Vnet ID)

The Vnet would have an effective MAC prefix of :
<16-bit IPV6_MAC_PREFIX>:00:10

The first lease from that Vnet would get :
<16-bit IPV6_MAC_PREFIX>:00:10:00:00

The second lease:
<16-bit IPV6_MAC_PREFIX>:00:10:00:01

and so forth. The resulting MAC address look a bit strange, but it works.

Please contact me if you would like to discuss this further, perhaps it would be easier to have a chat on IRC.

Simon

Hi

Yes basically this is my proposal, but I see no difference between the MAC generation for IPv4 and IPv6. I think that the best way to get the Global address is to include an IPv6 router in the network, maybe the site address can be set from context.

I basically see an IPv6 exactly the same as IPv4 (from the OPenNebula point of view). Probably with additional attributes to make it easy its definition. For example, now we have IP_START - IP_END to define a custom range of IPv4's (and MAC's for the matter of fact). I was thinking of adding support for MAC_START - MAC_END to define directly the range of MACs without the need of relying in an IPv4 address.

As part of the network definition we can define the site prefix and/or subnets, but this is just a "dumb" tag that can be passed through the context. It should not have any impact in the leases procedure (finding a free MAC address).

Does it make sense?

Ruben

Simon Boulet wrote:

Hi Ruban,

I was initially trying to find an implementation that would require a minimum of amount of work to the OpenNebula core. But if I get you right, your proposition makes a lot more sense and is much more practical.

From what I understand, you are proposing that, contrary to OpenNebula IPv4 Vnets, in IPv6 Vnets OpenNebula would manages MAC address leases instead of managing IP leases. In an OpenNebula V6 Vnet, the actual IPv6 address would be determined FROM the MAC address, not the other way around (in OpenNebula V4 Vnets, the IP address dictates the MAC address).

I am not sure to get your MAC_START suggestion.

OpenNebula would need a way to generate the MAC addresses that are to be assigned from that Vnet.

For example, MAC addresses for V6 Vnets could be generated like this :

<16-bit IPV6_MAC_PREFIX><16-bit OpenNebula Vnet ID><16-bit lease ID>

That would allow a total maximum of 65536 Vnets and a maximum of 65536 IPv6 addresses per Vnet, which seems fair.

From the MAC address, the VM would get to use the following IPv6 addresses for each IPv6 NIC it has :

<fe80>:<modified RFC3513 EUI-64> => IPv6 Link Local address
<OpenNebula V6 Vnet prefix, may be smaller but no larger than /64>:<modified RFC3513 EUI-64> => IPv6 Global address

The Global address could be set with autoconfigure (if configured on the NIC bridge), or DHCPv6 or using VM template CONTEXT. We could hide the Link local address from OpenNebula and have only the VNM know that.

Example:

You get a /64 IPv6 prefix (subnet) from your upstream
You create a V6 Vnet in OpenNebula with the /64 prefix
OpenNebula gets the next Vnet OID available from the DB, ex. 16 (which would be 0x0010 in hex for our 16-bit Vnet ID)

The Vnet would have an effective MAC prefix of :
<16-bit IPV6_MAC_PREFIX>:00:10

The first lease from that Vnet would get :
<16-bit IPV6_MAC_PREFIX>:00:10:00:00

The second lease:
<16-bit IPV6_MAC_PREFIX>:00:10:00:01

and so forth. The resulting MAC address look a bit strange, but it works.

Please contact me if you would like to discuss this further, perhaps it would be easier to have a chat on IRC.

Simon

It's great to have OpenNebula actually manage the network leases / IP addresses. I'd love to be able to manage and see IPv6 addresses along side IPv4 addresses in OpenNebula. I'm not sure I like the idea of having the prefix / subnet a "dumb" tag.

Simon

Yes, the main issue here I think is to present the data as IPv6 addresses. Let us come back with an specific proposal for the Network definition...

Design Goals¶

Getting ready this for 4.0. Draft design is as follows.

• Preserve OpenNebula's net address space assignment, i.e. we prepare the hosts to have unique addresses that are set externally (e.g. virtual routers or DHCP servers) or internally (e.g. through context or fixed in the VM)

• This model currently supports IPv6. VMs can use IPv6 addresses.

• This feature will add additional information to the network for: (i) easily define IPv6 networks; (ii) query IPv6 assigments and (iii) provide support for contextualization.

IPv6 Address Definition¶

There are 3 types that should be supported:

• Link local, in the form of FE80::/64 + HOST_ID/64

• Universal Local Address, in the form of fd00::/8 + SITE_ID/40 + SUBNET_ID/16 + HOST_ID/64

• Global Unicast Address, in the form GLOBAL_ROUTING_PREFIX/48 + SUBNET_ID/16 + HOST_ID/64

For each of the above addresses the HOST_ID is auto-configured and derived directly from the MAC (e.g. MAC=08:00:20:B5:41:37/48 ---> HOST_ID=0A00:20FF:FEB5:4137/64).

Therefore and IPv6 network can be defined (ranged)
MAC_START = <MAC address for the first host>
NETWORK_SIZE = <Number of hosts in the network>
ULA_PREFIX = <upper 64 block of the IPv6 for ULA address>
GLOBAL_PREFIX = <upper 64 block of the IPv6 for Global unicast address>

Example¶

The following will define an IPv6 network:

MAC_START = 08:00:20:B5:41:37
NETWORK_SIZE = 64
ULA_PREFIX = FD12:33A:DF64:1
GLOBAL_PREFIX = 2004:A128::32

This will generate HOST_IDs starting from 08:00:20:B5:41:37, 08:00:20:B5:41:38, 08:00:20:B5:41:39, 08:00:20:B5:41:3A....

A lease then will be:

LEASE=[ IP=32.181.65.55, IP6="FE08::0A:20FF:FEB5:4137,FD12:33A:DF64:1:0A:20FF:FEB5:4137,2004:A128::32:0A:20FF:FEB5:4137 MAC=08:00:20:B5:41:37, USED=1, VID=-1 ]

The new IP6 field will be added to the NIC attribute of the VM. Note that if ULA_FEFIX or GLOBAL_PREFIX are missing then associated address will not be generated. IPv4 networks will then have only link local addresses (FE08::/64)

If the network is fixed, adding the IPv6 prefixes will generate the corresponding addresses. As always each lease of the fixed network can be defined by its IP, MAC or both. The MAC address will be used to generate the IPv6 host identifier block.