Support IPv6 in control plane
IPv6 control plane support is a community goal for the Train cycle [1].
Kolla ansible does not yet support IPv6 for control plane access.
This blueprint is aiming to change this.
LATE EDIT: It turned out the goal is not for deployment projects.
[1] https:/
Blueprint information
- Status:
- Complete
- Approver:
- Jeffrey Zhang
- Priority:
- Medium
- Drafter:
- Radosław Piliszek
- Direction:
- Approved
- Assignee:
- Radosław Piliszek
- Definition:
- Approved
- Series goal:
- Accepted for train
- Implementation:
-
Implemented
- Milestone target:
-
9.0.0
- Started by
- Radosław Piliszek
- Completed by
- Radosław Piliszek
Whiteboard
Addressed by: https:/
WIP When IPv4 address is not available, return IPv6
Gerrit topic: https:/
Loose thought: Whatever support is added should be consistent between OpenStack projects and ideally other deployment tools (e.g. OSA, Tripleo).
WIP yoctozepto ideas:
Multiple addresses
The main difference from IPv4 (in ansible and k-a context) is that it is normal for IPv6 to have several addresses per interface. The main reason is that for normal operation IPv6 establishes a link-local address. In case of unicast, link-local and global are the only available scopes so the only scopes we care about. This invalidates our approach of using the first address.
Link-local is a fine candidate for unroutable networks because it frees the network designer from subnetting, yet it introduces an obstacle for networked apps because they are forced to specify the output interface as there is no routing involved.
DONE: check whether OpenStack services can work with link-local addresses at all
Services seem to support the addr%interface notation when binding and targetting servers. I wonder whether all but that will come out during proper tests. Interesting to see whether CI (Zuul) will like addresses like this or will they be filtered out.
The other scope addresses, global addresses, behave like "normal" unicast IPv4 addresses, they are routable using analogical roules. Again, an interface may have multiple global addresses, unlike in IPv4 where it is less common and "the other" addresses are referred to as secondary (in IPv6 they are all "equals"). Still, they might be used for whatever purpose (e.g. testing subnetting without VLAN support).
To better accommodate both existing IPv4 and upcoming IPv6 support, it might be wise to support choice of subnet address along with interface name. This way we could also provision relevant sanity checks (incl. for subnet length).
Co-existence with IPv4
We should ideally support three modes of operation:
- IPv4 only
- IPv6 only
- dual-stack
possibly elasticly enough so that a deployment may use a mix of these modes.
Hence network type should be declared (possibly implicitly but explicitly allows for sounder sanity checks).
Proposed solution uses explicit version specification so that IPv6 support works like IPv4 support (first global address is considered there) when choosing IPv6 (IPv4 remains default). It applies address contexts (raw, url, memcache) where applicable.
Addressed by: https:/
subjectAltName using DNS for IPv6
Addressed by: https:/
Implement IPv6 support in the control plane
Addressed by: https:/
CI: Use VXLAN overlay network
Addressed by: https:/
Refactor NSS database var
Addressed by: https:/
Fix OpenSSL template
Addressed by: https:/
Add IPv6 control plane feature release note
Addressed by: https:/
Docs: Add IPv6 control plane (address families)
Work Items
Work items:
Configurable IP version = support IPv6 the way we support IPv4 (take first address): DONE
Format IPv6 address according to its context (raw/url/memcache): DONE
