JIRA:IPVSIX-29

Change-Id: Ie9d1b6d1f4dc71af75b4e0d7859133f7e38846ed
Signed-off-by: Bin Hu <bh526r@att.com>

2 files changed, 0 insertions, 284 deletions

diff --git a/requirements/Requirement-Analysis-Kilo.txt b/requirements/Requirement-Analysis-Kilo.txt
deleted file mode 100644
index d6e5f45..0000000
--- a/requirements/Requirement-Analysis-Kilo.txt
+++ /dev/null
@@ -1,141 +0,0 @@
-===== Top Down Use Case and Gap Analysis =====

-

-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 Juno release:

-

-(1) Use Case / Requirement 1: All topologies work in a multi-tenant environment

-Supported in Neutron, Kilo Release: Yes

-Notes: 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.

-

-(2) Use Case / Requirement 2: IPv6 VM to VM only

-Supported in Neutron, Kilo Release: Yes

-Notes: 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. 

-

-(3) Use Case / Requirement 3: IPv6 external L2 VLAN directly attached to a VM

-Supported in Neutron, Kilo Release: Yes

-Notes: IPv6 provider network model; RA messages from upstream (external) router

-are forwarded into the VMs.

-

-(4) Use Case / Requirement 4: IPv6 subnet routed via L3 agent to an external

-IPv6 network

-(a) Both VLAN and overlay (e.g. GRE, VXLAN) subnet attached to VMs;

-(b) 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)

-Supported in Neutron, Kilo Release: (a) Yes (b) Yes

-Notes: 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.

-

-(5) Use Case / Requirement 5: Ability for a NIC to support both IPv4 and IPv6

-(dual stack) address;

-(a) VM with a single interface associated with a network, which is then

-associated with two subnets.

-(b) VM with two different interfaces associated with two different networks

-and two different subnets.

-Supported in Neutron, Kilo Release: (a) Yes (b) Yes

-Notes: Dual-stack is supported in Neutron with the addition of "Multiple IPv6

-Prefixes" Blueprint

-(https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes)

-

-(6) Use Case / Requirement 6: Support IPv6 Address assignment modes.

-(a) SLAAC

-(b) DHCPv6 Stateless

-(c) DHCPv6 Stateful 

-Supported in Neutron, Kilo Release: (a) Yes (b) Yes (c) Yes

-

-(7) Use Case / Requirement 7: Ability to create a port on an IPv6 DHCPv6

-Stateful subnet and assign a specific IPv6 address to the port and have it

-taken out of the DHCP address pool. 

-Supported in Neutron, Kilo Release: Yes

-

-(8) Use Case / Requirement 8: Ability to create a port with fixed_ip for a

-SLAAC/DHCPv6-Stateless Subnet. 

-Supported in Neutron, Kilo Release: No

-Notes: The following patch disables this operation:

-https://review.openstack.org/#/c/129144/

-

-(9) Use Case / Requirement 9: 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. 

-Supported in Neutron, Kilo Release: Rejected

-Notes: Blueprint proposed in upstream and got rejected. General expectation is

-to avoid NAT with IPv6 by assigning GUA to tenant VMs. See

-https://review.openstack.org/#/c/139731/ for discussion

-

-(10) Use Case / Requirement 10: Provide IPv6/IPv4 feature parity in support for

-pass-through capabilities (e.g., SR-IOV). 

-Supported in Neutron, Kilo Release: Roadmap

-Notes: 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.

-

-(11) Use Case / Requirement 11: Additional IPv6 extensions, for example: IPSEC,

-IPv6 Anycast, Multicast

-Supported in Neutron, Kilo Release: No

-Notes: It doesn't appear to be considered yet (lack of clear requirements)

-

-(12) Use Case / Requirement 12: VM access to the meta-data server to obtain

-user data, SSH keys, etc. using cloud-init with IPv6 only interfaces. 

-Supported in Neutron, Kilo Release: No

-Notes: 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). See email discussion thread

-(http://openstack.10931.n7.nabble.com/Neutron-cloud-init-IPv6-support-td45386.html)

-

-(13) Use Case / Requirement 13: 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.

-Supported in Neutron, Kilo Release: Yes

-

-(14) Use Case / Requirement 14: 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.

-Supported in Neutron, Kilo Release: Yes

-Notes: Two new Subnet attributes were introduced to control IPv6 address

-assignment options:

-(a) "ipv6-ra-mode" - to determine who sends Router Advertisements, and

-(b) "ipv6-address-mode" - to determine how VM obtains IPv6 address, default

-gateway, and/or optional information.

-

-(15) Use Case / Requirement 15: Security groups anti-spoofing: Prevent VM from

-using a source IPv6/MAC address which is not assigned to the VM.

-Supported in Neutron, Kilo Release: Yes

-

-(16) Use Case / Requirement 16: Protect tenant and provider network from rough RAs

-Supported in Neutron, Kilo Release: Yes

-Notes: 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.

-

-(17) Use Case / Requirement 17: Support the ability to assign multiple IPv6

-addresses to an interface; both for Neutron router interfaces and VM interfaces.

-Supported in Neutron, Kilo Release: Yes

-

-(18) Use Case / Requirement 18: Ability for a VM to support a mix of multiple

-IPv4 and IPv6 networks, including multiples of the same type.

-Supported in Neutron, Kilo Release: Yes

-

-(19) Use Case / Requirement 19: Support for IPv6 Prefix Delegation.

-Supported in Neutron, Kilo Release: Roadmap

-Notes: Planned for Liberty

-

-(20) Use Case / Requirement 20: Distributed Virtual Routing (DVR) support for IPv6

-Supported in Neutron, Kilo Release: No

-Notes: Blueprint proposed upstream, pending discussion. 

-

-(21) Use Case / Requirement 21: IPv6 First-Hop Security, IPv6 ND spoofing.

-Supported in Neutron, Kilo Release: Roadmap

-Notes: Blueprint proposed upstream. Some patches are under review.

-

diff --git a/requirements/Requirement-Analysis.txt b/requirements/Requirement-Analysis.txt
deleted file mode 100644
index 8350eb8..0000000
--- a/requirements/Requirement-Analysis.txt
+++ /dev/null
@@ -1,143 +0,0 @@
-===== Top Down Use Case and Gap Analysis =====

-

-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 Juno release:

-

-(1) Use Case / Requirement 1: All topologies work in a multi-tenant environment

-Supported in Neutron, Juno Release: Yes

-Notes: The tenant's subnets are based on Neutron, with ML2 plugin and Single

-Flat Network topology, dual-stacked. See "DHCPv6" BP

-(https://review.openstack.org/#/c/102411) and "IPv6 SLAAC" BP

-(http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-radvd-ra.html)

-

-(2) Use Case / Requirement 2: IPv6 VM to VM only

-Supported in Neutron, Juno Release: Yes

-Notes: Configuration and IPv6 address assignment

-

-(3) Use Case / Requirement 3: IPv6 external L2 VLAN directly attached to a VM

-Supported in Neutron, Juno Release: Yes

-Notes: Via Neutron and external router / border gateway. See "UPStream Provider

-Network" BP

-(http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-provider-nets-slaac.html)

-To-Do: Verify

-

-(4) Use Case / Requirement 4: IPv6 subnet routed via L3 agent to an external

-IPv6 network

-(a) Both VLAN and overlay (e.g. GRE, VXLAN) subnet attached to VMs;

-(b) 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)

-Supported in Neutron, Juno Release: (a) Roadmap (b) Yes

-Notes: The IPv6 support in Neutron L3 router isn't ready yet. Watch Kilo BPs

-"IPv6 Router BP" (https://review.openstack.org/#/c/142224/) and

-"Multiple Ipv6 Prefixes BP" (https://review.openstack.org/#/c/98217).

-(b) is supported for scalability. Patches for HA are under review.

-

-(5) Use Case / Requirement 5: Ability for a VM to support a mix of multiple

-IPv4 and IPv6 networks, i.e. across the mix of all the above topologies

-including multiples of the same type.

-Supported in Neutron, Juno Release: Yes for dual-stack and Roadmap for multiple

-IPv4 and IPv6 subnets

-Notes: Dual-stack is supported via Single Flat Network topology. Refer to Kilo

-Blueprint "Multiple IPv6 Prefixes"

-(https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes)

-for support of multiple IPv4 and IPv6 networks

-To-Do: Verify

-

-(6) Use Case / Requirement 6: Support DHCPv6 stateful

-(a) Including the ability for a user to create a port on an IPv6 subnet and

-assign a specific IPv6 address to the port and have it taken out of the DHCP

-address pool;

-(b) Support the ability to assign multiple IPv6 address to an interface

-Supported in Neutron, Juno Release: (a) Yes and (b) Work-in-Progress

-Notes: Work-in-progress and expected in Juno release. All the IPv6

-configuration modes such as SLAAC, DHCPv6 Stateless and DHCPv6 Stateful are

-expected in Juno release. For (a), see

-Patch 1 (https://bugs.launchpad.net/neutron/+bug/1367500) and

-Patch 2 (https://bugs.launchpad.net/neutron/juno/+bug/1377843).

-This is verified by Sridhar. For (b), see BP in Kilo

-(https://review.openstack.org/#/c/98217/14).

-

-(7) Use Case / Requirement 7: Should not prevent the ability to support

-non-DHCP statically assigned IPv6 addresses in the same fashion as is supported

-for IPv4

-Supported in Neutron, Juno Release: No

-Notes: The following patch disables this operation: (https://review.openstack.org/#/c/129144/)

-

-(8) Use Case / Requirement 8: Support for private IPv6 to external IPv6

-Floating IP

-Supported in Neutron, Juno Release: Rejected (No)

-Notes: See https://review.openstack.org/#/c/139731/ for discussion

-

-(9) Use Case / Requirement 9: Provide IPv6/IPv4 feature parity in support for

-pass-through capabilities (e.g. SR-IOV support in OpenStack) as these features

-are provided in OpenStack

-Supported in Neutron, Juno Release: Roadmap

-Notes:

-(a) Blueprint "Managing InfiniBand SR-IOV"

-(https://blueprints.launchpad.net/neutron/+spec/manage-sriov-ib-net-config) is

-pending approval,

-(b) Blueprint "Traffic Rate Support for SR-IOV NIC"

-(https://blueprints.launchpad.net/neutron/+spec/ml2-sriov-rate-limit-extension)

-is being drafted,

-(c) Blueprint "HA SR-IOV Ports"

-(https://blueprints.launchpad.net/neutron/+spec/high-availability-sriov-ports)

-has not started yet.

-

-(10) Use Case / Requirement 10: Additional IPv6 extensions, for example: IPSEC,

-IPv6 Anycast, Multicast

-Supported in Neutron, Juno Release: No

-Notes: It doesn't appear to be considered yet

-

-(11) Use Case / Requirement 11: Access to the meta-data server to obtain user

-data and ssh keys etc

-Supported in Neutron, Juno Release: No

-Notes: Metadata (and GRE / VXLAN subnet) still requires IPv4. An alternate

-mechanism is to use config-drive. See email thread

-(http://openstack.10931.n7.nabble.com/Neutron-cloud-init-IPv6-support-td45386.html)

-

-(12) Use Case / Requirement 12: Full support for IPv6 tcp/udp/icmp IPv6

-security groups (same as we see for IPv4)

-Supported in Neutron, Juno Release: Yes

-Notes:

-(a) Blueprint "Support ICMP type filter by security group"

-(https://blueprints.launchpad.net/neutron/+spec/security-group-icmp-type-filter)

-has not started yet.

-(b) Blueprint "Security group rule for IPv6 RA guard and IPv6 Snooping"

-(https://blueprints.launchpad.net/neutron/+spec/security-group-ipv6-ra-guard)

-has not started. Whiteboard responses to BP (a) indicates that it is already

-supported.

-To-Do: for BP(b), the author was looking at the "IPv6 First-Hop Security"

-feature

-

-(13) Use Case / Requirement 13: During network/subnet/router create, there

-should be an option to allow user to specify the type of address management

-they would like. (a) this includes all options including those low priority if

-implemented (e.g. toggle on/off router and address prefix advertisements);

-(b) It must be supported via Neutron API (restful and CLI) as well as via

-Horizon

-Supported in Neutron, Juno Release: Yes for various types of IPv6 subnet and

-Roadmap for multiple subnets

-Notes: The ability to create various types of IPv6 subnets (i.e., SLAAC / DHCPv6

-Stateless / Stateful) is supported both using Neutron router and external

-router. Refer to "various combinations and how to configure Neutron subnets"

-(http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-radvd-ra.html#rest-api-impact).

-Refer to Blueprints "IPv6 Prefix Delegation"

-(https://blueprints.launchpad.net/neutron/+spec/ipv6-prefix-delegation) and

-"Multiple IPv6 Prefixes"

-(https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes) for

-support of multiple IPv4 and IPv6 networks

-

-(14) Use Case / Requirement 14: Ability to specify Floating IPs via Neutron API

-(restful and CLI) as well as via Horizon, including combination of IPv6/IPv4

-and IPv4/IPv6 Floating IPs if implemented

-Supported in Neutron, Juno Release: No

-Notes: IPv6 Floating IPs will not be supported in Kilo. See BP

-(https://review.openstack.org/#/c/139731/). Refer to previous item of floating

-IPv6 functionality being rejected.

-

-(15) Use Case / Requirement 15: Ability to control and manage all IPv6 security

-group capabilities via Neutron/Nova API (restful and CLI) as well as via Horizon

-Supported in Neutron, Juno Release: Yes

-Notes: Refer to previous item of IPv6 security group

-