Add RADVD to router namespaces to serve ipv6 RAs when required

Registered by Ian Wells on 2013-12-19

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:
milestone icon 2014.2
Started by
Kyle Mestery on 2014-07-01
Completed by
Kyle Mestery on 2014-07-21

Related branches

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://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-relay
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac

 - 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://review.openstack.org/#q,topic:bp/neutron-ipv6-radvd-ra,n,z

Addressed by: https://review.openstack.org/101306
    Support Router Advertisement Daemon (radvd) for IPv6

Addressed by: https://review.openstack.org/102648
    Support Router Advertisement Daemon (radvd) for IPv6

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.