User Tools

Site Tools

Top Down Use Case and Gap Analysis with OpenStack Kilo

Here are some top down use cases of VIM-agnostic IPv6 functionality, including infrastructure layer and VNF (VM) layer, and its gap analysis with Neutron in Kilo Release:

Use Case / Requirement

Supported in Kilo Neutron?

Notes

All topologies work in a multi-tenant environment

Yes

The IPv6 design is following the Neutron tenant networks model; dnsmasq is being used inside DHCP network namespaces, while radvd is being used inside Neutron routers namespaces to provide full isolation between tenants.
Tenant isolation can be based on VLANs, GRE, or VXLAN encapsulation. In case of overlays, the transport network (and VTEPs) must be IPv4 based as of today.

IPv6 VM to VM only

Yes

It is possible to assign IPv6-only addresses to VMs. Both switching (within VMs on the same tenant network) as well as east/west routing (between different networks of the same tenant) are supported.

IPv6 subnet routed via L3 agent to an external IPv6 network
1. Both VLAN and overlay (e.g. GRE, VXLAN) subnet attached to VMs;
2. Must be able to support multiple L3 agents for a given external network to support scaling (neutron scheduler to assign vRouters to the L3 agents)

1. Yes
2. Yes

Configuration is enhanced in Kilo to allow easier setup of the upstream gateway, without the user forced to create an IPv6 subnet for the external network.

Ability for a NIC to support both IPv4 and IPv6 (dual stack) address;
1. VM with a single interface associated with a network, which is then associated with two subnets.
2. VM with two different interfaces associated with two different networks and two different subnets.

Support for private IPv6 to external IPv6 floating IP; Ability to specify floating IPs via Neutron API (REST and CLI) as well as via Horizon, including combination of IPv6/IPv4 and IPv4/IPv6 floating IPs if implemented.

The L3 configuration should be transparent for the SR-IOV implementation. SR-IOV networking support introduced in Juno based on the sriovnicswitch ML2 driver is expected to work with IPv4 and IPv6 enabled VMs.

VM access to the meta-data server to obtain user data, SSH keys, etc. using cloud-init with IPv6 only interfaces.

No

This is currently not supported. Config-drive or dual-stack IPv4/IPv6 can be used as a workaround (so that the IPv4 network is used to obtain connectivity with the metadata service)
Ref:email-thread

Full support for IPv6 matching (i.e., IPv6, ICMPv6, TCP, UDP) in security groups. Ability to control and manage all IPv6 security group capabilities via Neutron/Nova API (REST and CLI) as well as via Horizon.

Yes

During network/subnet/router create, there should be an option to allow user to specify the type of address management they would like. This includes all options including those low priority if implemented (e.g., toggle on/off router and address prefix advertisements); It must be supported via Neutron API (REST and CLI) as well as via Horizon

Security groups anti-spoofing: Prevent VM from using a source IPv6/MAC address which is not assigned to the VM

Yes

Protect tenant and provider network from rough RAs

Yes

When using a tenant network, Neutron is going to automatically handle the filter rules to allow connectivity of RAs to the VMs only from the Neutron router port; with provider networks, users are required to specify the LLA of the upstream router during the subnet creation, or otherwise manually edit the security-groups rules to allow incoming traffic from this specific address.

Support the ability to assign multiple IPv6 addresses to an interface; both for Neutron router interfaces and VM interfaces.

Yes

Ability for a VM to support a mix of multiple IPv4 and IPv6 networks, including multiples of the same type.