Add RADVD to router namespaces to serve ipv6 RAs when required
Add RADVD to router namespaces to serve ipv6 RAs when required
Blueprint information
- Status:
- Complete
- Approver:
- Kyle Mestery
- Priority:
- Medium
- Drafter:
- Baodong (Robert) Li
- Direction:
- Approved
- Assignee:
- Baodong (Robert) Li
- Definition:
- Approved
- Series goal:
- Accepted for juno
- Implementation:
-
Implemented
- Milestone target:
-
2014.2
- Started by
- Kyle Mestery
- Completed by
- Kyle Mestery
Related branches
Related bugs
Sprints
Whiteboard
1-July (mestery): Targeting Juno-2 now that the spec is approved.
12-June (mestery): Removing Juno target for now until the specification is approved.
I would suggest that this be used for all 3 modes: SLAAC, Stateful and Stateless. An RA is required for all 3 modes to operate on most systems. It's potentially also useful for static (cloud-init injection) allocations (A=0, M=0, O=1) -- aveiga
Yup. I think the only reason you might turn it off is if you like the security group firewalling or the address allocation but for whatever reason RAs annoy you and you're lovingly configuring your VMs entirely by hand or config-disk. It's just an option, it's probably not going to be the default option or a very useful option.
Stateful and stateless are, I hope, independent to this, relying on a complementary DHCPv6 setup - which I would like to deal with using a separate proposal once we've got this working, so in this BP that's a 'no comment'. -- ijw-ubuntu
Why would we introduce another tool rather than utilize dnsmasq which can support RA for all cases, RFC6106 for RDNSS & DNSSL, DHCPv6, and potentially DHCP Relay (not yet proven). With the work already done in our POC, we know dnsmasq works in the qrouter namespace. See also:
https:/
https:/
https:/
https:/
https:/
- rantuttl
I can see a few advantages of implementing DHCPv6 and RA separately within openstack:
-- with IPv4, a dhcp port is created within the dhcp namespace. A dnsmasq instance is bound to the interface and provides VMs with ipv4 addresses and interface parameters if any. The same instance can be used to serve VMs with ipv6 addresses and interface parameters if any. The dnsmasq instance serves all the subnets under the same neutron network. Therefore, separating DHCPv6 and RA fits in the existing architecture pretty well. In the same time, keep the openstack dhcp implementation simple.
-- There will be a scalability issue if running dnsmasq per IPv6 subnet within the router namespaces. In addition, given the current implementation of openstack subnets, all of the them are under the same broadcast domain of the network they belong to. An unintended side effect of running one dnsmasq per subnet is that all the VMs in the same network will get prefixes from all of the network's IPv6 subnets. So what's point of running one instance per subnet?
-- The current dnsmasq instance uses static mode and always runs with a dhcp-optsfile option. The opts file can be empty if no dhcp options are provided with the subnet or with the ports that belong to the network. This strategy can be adopted for IPv6 as well. That means, there is no need for complex logic to determine the dnsmasq command line options.
-- RA supports unicast router advertisement. From dnsmasq manpage, it doesn't seem to support this feature. However, this feature is pretty useful. For example, the admin may choose to use ULA address, and assign a few hosts to have internet accesses.
-- finally, it would lead to simplified API design. Essentially, it boils down to the following choices:
- enable dhcp or not
- enable RA or not, with SLAAC or not
I understand that I kind of late joining the discussion. But I think the above points are worth consideration.
-- Robert
Gerrit topic: https:/
Addressed by: https:/
Support Router Advertisement Daemon (radvd) for IPv6
Addressed by: https:/
Support Router Advertisement Daemon (radvd) for IPv6
Work Items
Dependency tree
* Blueprints in grey have been implemented.
