--- /dev/null
+===== Top Down Use Case and Gap Analysis =====\r
+\r
+Here are some top down use cases of VIM-agnostic IPv6 functionality, including\r
+infrastructure layer and VNF (VM) layer, and its gap analysis with Neutron\r
+in Juno release:\r
+\r
+(1) Use Case / Requirement 1: All topologies work in a multi-tenant environment\r
+Supported in Neutron, Kilo Release: Yes\r
+Notes: The IPv6 design is following the Neutron tenant networks model; dnsmasq\r
+is being used inside DHCP network namespaces, while radvd is being used inside\r
+Neutron routers namespaces to provide full isolation between tenants.\r
+Tenant isolation can be based on VLANs, GRE, or VXLAN encapsulation. In case of\r
+overlays, the transport network (and VTEPs) must be IPv4 based as of today.\r
+\r
+(2) Use Case / Requirement 2: IPv6 VM to VM only\r
+Supported in Neutron, Kilo Release: Yes\r
+Notes: It is possible to assign IPv6-only addresses to VMs. Both switching\r
+(within VMs on the same tenant network) as well as east/west routing (between\r
+different networks of the same tenant) are supported. \r
+\r
+(3) Use Case / Requirement 3: IPv6 external L2 VLAN directly attached to a VM\r
+Supported in Neutron, Kilo Release: Yes\r
+Notes: IPv6 provider network model; RA messages from upstream (external) router\r
+are forwarded into the VMs.\r
+\r
+(4) Use Case / Requirement 4: IPv6 subnet routed via L3 agent to an external\r
+IPv6 network\r
+(a) Both VLAN and overlay (e.g. GRE, VXLAN) subnet attached to VMs;\r
+(b) Must be able to support multiple L3 agents for a given external network to\r
+support scaling (neutron scheduler to assign vRouters to the L3 agents)\r
+Supported in Neutron, Kilo Release: (a) Yes (b) Yes\r
+Notes: Configuration is enhanced in Kilo to allow easier setup of the upstream\r
+gateway, without the user forced to create an IPv6 subnet for the external network.\r
+\r
+(5) Use Case / Requirement 5: Ability for a NIC to support both IPv4 and IPv6\r
+(dual stack) address;\r
+(a) VM with a single interface associated with a network, which is then\r
+associated with two subnets.\r
+(b) VM with two different interfaces associated with two different networks\r
+and two different subnets.\r
+Supported in Neutron, Kilo Release: (a) Yes (b) Yes\r
+Notes: Dual-stack is supported in Neutron with the addition of "Multiple IPv6\r
+Prefixes" Blueprint\r
+(https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes)\r
+\r
+(6) Use Case / Requirement 6: Support IPv6 Address assignment modes.\r
+(a) SLAAC\r
+(b) DHCPv6 Stateless\r
+(c) DHCPv6 Stateful \r
+Supported in Neutron, Kilo Release: (a) Yes (b) Yes (c) Yes\r
+\r
+(7) Use Case / Requirement 7: Ability to create a port on an IPv6 DHCPv6\r
+Stateful subnet and assign a specific IPv6 address to the port and have it\r
+taken out of the DHCP address pool. \r
+Supported in Neutron, Kilo Release: Yes\r
+\r
+(8) Use Case / Requirement 8: Ability to create a port with fixed_ip for a\r
+SLAAC/DHCPv6-Stateless Subnet. \r
+Supported in Neutron, Kilo Release: No\r
+Notes: The following patch disables this operation:\r
+https://review.openstack.org/#/c/129144/\r
+\r
+(9) Use Case / Requirement 9: Support for private IPv6 to external IPv6\r
+floating IP; Ability to specify floating IPs via Neutron API (REST and CLI)\r
+as well as via Horizon, including combination of IPv6/IPv4 and IPv4/IPv6\r
+floating IPs if implemented. \r
+Supported in Neutron, Kilo Release: Rejected\r
+Notes: Blueprint proposed in upstream and got rejected. General expectation is\r
+to avoid NAT with IPv6 by assigning GUA to tenant VMs. See\r
+https://review.openstack.org/#/c/139731/ for discussion\r
+\r
+(10) Use Case / Requirement 10: Provide IPv6/IPv4 feature parity in support for\r
+pass-through capabilities (e.g., SR-IOV). \r
+Supported in Neutron, Kilo Release: Roadmap\r
+Notes: The L3 configuration should be transparent for the SR-IOV implementation.\r
+SR-IOV networking support introduced in Juno based on the sriovnicswitch ML2\r
+driver is expected to work with IPv4 and IPv6 enabled VMs.\r
+\r
+(11) Use Case / Requirement 11: Additional IPv6 extensions, for example: IPSEC,\r
+IPv6 Anycast, Multicast\r
+Supported in Neutron, Kilo Release: No\r
+Notes: It doesn't appear to be considered yet (lack of clear requirements)\r
+\r
+(12) Use Case / Requirement 12: VM access to the meta-data server to obtain\r
+user data, SSH keys, etc. using cloud-init with IPv6 only interfaces. \r
+Supported in Neutron, Kilo Release: No\r
+Notes: This is currently not supported. Config-drive or dual-stack IPv4/IPv6\r
+can be used as a workaround (so that the IPv4 network is used to obtain\r
+connectivity with the metadata service). See email discussion thread\r
+(http://openstack.10931.n7.nabble.com/Neutron-cloud-init-IPv6-support-td45386.html)\r
+\r
+(13) Use Case / Requirement 13: Full support for IPv6 matching (i.e. IPv6,\r
+ICMPv6, TCP, UDP) in security groups. Ability to control and manage all IPv6\r
+security group capabilities via Neutron/Nova API (REST and CLI) as well as via\r
+Horizon.\r
+Supported in Neutron, Kilo Release: Yes\r
+\r
+(14) Use Case / Requirement 14: During network/subnet/router create, there\r
+should be an option to allow user to specify the type of address management\r
+they would like. This includes all options including those low priority if\r
+implemented (e.g., toggle on/off router and address prefix advertisements);\r
+It must be supported via Neutron API (REST and CLI) as well as via Horizon.\r
+Supported in Neutron, Kilo Release: Yes\r
+Notes: Two new Subnet attributes were introduced to control IPv6 address\r
+assignment options:\r
+(a) "ipv6-ra-mode" - to determine who sends Router Advertisements, and\r
+(b) "ipv6-address-mode" - to determine how VM obtains IPv6 address, default\r
+gateway, and/or optional information.\r
+\r
+(15) Use Case / Requirement 15: Security groups anti-spoofing: Prevent VM from\r
+using a source IPv6/MAC address which is not assigned to the VM.\r
+Supported in Neutron, Kilo Release: Yes\r
+\r
+(16) Use Case / Requirement 16: Protect tenant and provider network from rough RAs\r
+Supported in Neutron, Kilo Release: Yes\r
+Notes: When using a tenant network, Neutron is going to automatically handle the\r
+filter rules to allow connectivity of RAs to the VMs only from the Neutron\r
+router port; with provider networks, users are required to specify the LLA of\r
+the upstream router during the subnet creation, or otherwise manually edit the\r
+security-groups rules to allow incoming traffic from this specific address.\r
+\r
+(17) Use Case / Requirement 17: Support the ability to assign multiple IPv6\r
+addresses to an interface; both for Neutron router interfaces and VM interfaces.\r
+Supported in Neutron, Kilo Release: Yes\r
+\r
+(18) Use Case / Requirement 18: Ability for a VM to support a mix of multiple\r
+IPv4 and IPv6 networks, including multiples of the same type.\r
+Supported in Neutron, Kilo Release: Yes\r
+\r
+(19) Use Case / Requirement 19: Support for IPv6 Prefix Delegation.\r
+Supported in Neutron, Kilo Release: Roadmap\r
+Notes: Planned for Liberty\r
+\r
+(20) Use Case / Requirement 20: Distributed Virtual Routing (DVR) support for IPv6\r
+Supported in Neutron, Kilo Release: No\r
+Notes: Blueprint proposed upstream, pending discussion. \r
+\r
+(21) Use Case / Requirement 21: IPv6 First-Hop Security, IPv6 ND spoofing.\r
+Supported in Neutron, Kilo Release: Roadmap\r
+Notes: Blueprint proposed upstream. Some patches are under review.\r
+\r
Code Review / ipv6.git / commitdiff