The IPv6 Prefix Delegation (PD) mechanism (described in RFC3769  and RFC3633 ) provides a way of automatically configuring IPv6 prefixes and addresses on routers and hosts. This mechanism can be used in Neutron to automate the selection of IPv6 prefixes for tenants.
With prefix delegation, a prefix delegating router (referred to as a prefix delegation server, or PD server in this document) is configured with a set of prefixes. The prefix delegation process begins when a router acting as a prefix delegation requester (referred to as a prefix delegation client, or PD client in this document) requests configuration information through DHCP messages. When the PD server receives the request, it selects an available prefix or prefixes for delegation to the PD client.
It should be noted that the prefixes that are delegated by the PD server are routable, that is, the PD server provides a downstream route to the prefixes that have been delegated.
This blueprint proposes using IPv6 Prefix Delegation to support automatic assignment of IPv6 prefixes to tenants/subnets, using an external (outside of the OpenStack cloud) router to delegate prefixes from a pre-configured pool of routable prefixes.
Note that it would be possible to have a PD server application that is managed by Neutron that is running within a Neutron router namespace, and that is configured using the IPAM Subnet Allocation API . This support is out the scope of this blueprint, and will be covered in a separate blueprint.
In the current Neutron implementation, tenants must supply a prefix when creating subnets. This is not a big deal for IPv4 private subnets, since IP addresses on the private subnets can overlap. For IPv6 subnets that use Global Unicast Address (GUA) format, addresses are globally routable (unlike IPv6 Unique Local Addresses, or ULAs), so care needs to be taken to ensure that prefixes chosen by one tenant do not overlap with prefixes chosen by another tenant.
An OpenStack administrator may want to simplify the process of subnet prefix selection for the tenants by automatically supplying prefixes for IPv6 subnets from one or more large pools of pre-configured IPv6 prefixes. This would also eliminate any potential conflicts in prefix selection.
The IPv6 Prefix Delegation mechanism provides a way of automatically configuring IPv6 prefixes and addresses on routers and hosts, and can be used in Neutron to automate the selection of IPv6 prefixes for tenants. Prefix Delegation would also provide a pathway for adding IPv6 automatic renumbering for IPv6 addresses in an OpenStack cloud as a future enhancement.
This blueprint proposes using IPv6 Prefix Delegation to support automatic assignment of IPv6 prefixes to tenants/subnets, using an external router to delegate prefixes from a pre-configured pool of routable prefixes.
The prefix delegation topology being proposed in the blueprint is displayed in the following diagram:
+-------+-------+ | PD Server | | (Running on | | external | | router) | +-------+-------+ | | +-------------+--------------+ | | +------+-------+ +------+-------+ |Neutron Router| |Neutron Router| | (Running PD | | (Running PD | | Client and | | Client and | | RADVD) | | RADVD) | +------+-------+ +------+-------+ Router Port | Router Port | | /64 Prefix #1 | /64 Prefix #2 | | +------+------+ +-----+-------+ | | | | +----+-----+ +-----+----+ +----+-----+ +-----+----+ | Tenant A | | Tenant A | | Tenant B | | Tenant B | | VM | | VM | | VM | | VM | +----------+ +----------+ +----------+ +----------+
Note that in this topology, since the PD server is an entity outside of the OpenStack cloud, the PD client needs to be authenticated by the PD server (in order to prevent a rogue requester from depleting available prefixes), and the identity of the PD server needs to be authenticated by the PD requesters. This is described in Section 3.6 of RFC3769 .
The PD Client functionality could be provided by one of several open-source utilities that support PD client, for example:
For the initial implementation we have chosen to use dibbler, as it has some important features missing in other clients which make it suitable for this use case. A plugin framework will be included to allow the addition of other client options in the future.
A new dibbler-client will be started in the Neutron router namespace whenever a subnet attached to that router requires prefix delegation.
OpenStack/Neutron needs to be aware of prefix allocations as they occur. For example, Neutron needs to update the IP allocation database with the gateway IP address that has just been assigned to the internal router port when the prefix delegation client is allocated a prefix.
Dibbler supports the configuration of a custom script that gets executed whenever a prefix allocation has been made. Such a custom script can provide the necessary hook.
As described in the Subnet Pool Allocation specification , the subnet create API will need to allow for the absence of both subnet prefix and subnet pool ID. Normally, this indicates to Neutron (and the subnet pool allocation infrastructure) that the prefix for this subnet should be allocated from a default allocation pool configured for that IP family. When prefix delegation is configured (see “Initial Setup” above), however, it is understood that the allocation of IPv6 prefixes in this case should be done through prefix delegation. In this case, the subnet pool ID is populated with special constant to mark subnets as requiring prefix delegation.
As described in the “Allocation of a Prefix” section, the prefix allocation process will then get triggered after a subnet that is marked for prefix delegation (i.e. subnet pool ID is populated with the special prefix delegation constant) is attached to a router.
While the subnet is awaiting assignment of a prefix via prefix delegation, the response for the subnet-list and subnet-show API/CLI will list the cidr and allocation_pools for the subnet using a temporary ::/64 prefix.
When the PD server is an entity outside of the OpenStack cloud (e.g. an ISP edge router), then the PD client needs to be authenticated by the PD server (in order to prevent a rogue requester from depleting available prefixes), and the identity of the PD server needs to be authenticated by the PD requesters. This is described in Section 3.6 of RFC3769 .
Limits on the number of prefixes that each tenant is allowed to use at any time will be maintained using OpenStack/Neutron subnet quota.
Horizon will need to be updated to support this feature for subnet creation. This Horizon work can be done as part of the changes being made to support subnet allocation pools.
If the PD client does not provide for either asynchronous notification for the allocation of each prefix, or the configuration of a custom script that is called upon allocation of prefixes, then a polling script will need to be spawned whenever a subnet is created that requires prefix delegation. The extent that these polling scripts have on performance would depend on the scale of subnets that are being created at any point in time, but it shouldn’t be too significant if the polling interval is a few seconds or more.
Yes, this change will modify the Neutron IPv6 implementation.
Deployers wishing to use prefix delegation would need to configure an external router to act as a PD server, and will need to configure a pool of available IPv6 prefixes.
It may be worth considering adding a mechanism to the pluggable IPAM infrastructure that would allow for a feature such as prefix delegation to report prefixes that have been delegated. This would mainly be for informational purposes, e.g. for displaying what prefixes have been delegated through prefix delegation.
This feature is complementary to the IPAM Subnet Allocation feature . This implementation could be expanded in the future to support an internal (Neutron-managed) PD server, and thereby used as part of the underlying implementation for the IPv6 portion of the IPAM Subnet Allocation.
Instead of using the default_ipv6_subnet_pool Neutron configuration to indicate that prefix delegation should be used whenever a subnet create request is made with neither a subnet prefix nor subnet pool ID, a boolean attribute could be added to the subnet create API to indicate that prefix delegation should be used for this subnet. The advantage to such an API change would be that the user would be able to select between prefix delegation and a default allocation pool on a per-subnet basis. However, this benefit probably doesn’t outweigh the cost of adding yet another attribute to the API.
The change in behavior for the subnet create API described in this proposal will need to build off changes in that API that will be made for IPAM Subnet Allocation .
In order to test functionality with an external router serving as the PD server, a third party CI system will be needed that incorporates a router that supports prefix delegation. The Tempest test to run on this third party CI system would be:
Since this feature depends upon a PD server that is running outside of OpenStack, this feature will require a functional test that runs an open-source PD server application in a neutron namespace, configured with a pool of IPv6 prefixes. After the PD server application is running, the test sequence would be similar to the sequence described in the previous section.
PD server applications that can be considered for this testing include:
This feature will require an API test for testing subnet create API with neither prefix nor allocation pool ID specified.
Minor document changes will be required to reflect the configuration of the default IPv6 subnet pool for prefix delegation.
Specify any User Documentation which needs to be changed. Reference the guides which need updating due to this change.
The Neutron API docs will need updating to reflect API behavior changes for subnet create.
|||(1, 2, 3) RFC 3769: Requirements for IPv6 Prefix Delegation|
|||RFC 3633: IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6|
|||RFC 4862: IPv6 Stateless Address Autoconfiguration|
|||(1, 2, 3, 4, 5, 6) Neutron Blueprint: Add support for subnet allocation|
|||RFC 4862: IPv6 Stateless Address Autoconfiguration|
|||RFC 4861: Neighbor Discovery for IP version 6 (IPv6)|
|||RFC 4291: IP Version 6 Addressing Architecture|