For now, when end user is creating IPv6-enabled tenant network and attaching it to the virtual router, there are two ways to set up external infrastructure to put traffic back to the router. One is using DHCPv6 PD[1]. BGP is a new option available in Mitaka. Both require configuration of extra external systems (PD server, BGP routers).
In IPv6 Router Advertisements we have an option called Route Information Option[2] to advertise more specific routes from gateway. We could easily append a section like next one to advertise tenant prefix 2001:db8:1::/64 to public network. And if provider network router outside OpenStack will be configured to accept these. This might be considered a lighter weight alternative to PD and BGP for announcing tenant networks. Neighboring routers just need to accept and honor the announcement. Externally accessible addresses would still need to be routed to any border routers manually.
interface qg- {
AdvDefaultLifetime 0;
route 2001:db8:1::/64 {
};
};
Cisco accepts it by default AFAIK, linux needs a sysctl net.ipv6.conf.*.accept_ra_rt_info_max_plen set to 64.
Moreover, enabling receiving prefixes in router namespaces allows routers communicate by themselves.
For preventing user from advertising subnets that makes no sense for outside infrastructure, Address Scopes[3] mechanism should be used:
1. Administrator creates an address scope and associate an IPv6 subnet pool with it.
2. Administrator creates Public shared network’s subnet from this subnet pool.
3. Tenant user creates tenant network from this subnet pool and connect it to Public shared network with router
4. OpenStack advertises prefix to the external interface of the router.
[1]: http://specs.openstack.org/openstack/neutron-specs/specs/kilo/ipv6-prefix-delegation.html
[2]: https://tools.ietf.org/html/rfc4191
[3]: https://blueprints.launchpad.net/neutron/+spec/address-scopes
I have some concerns about this RFE - mostly around the fact that we
should fix the linked bug so we can continue to use prefix
delegation.
I may not be reading the RFC correctly, but the topologies they
describe, where a host has multiple routers for multiple prefixes
and we wish to specify more specific routes, does not quite match what
at least this bug discusses, when we are talking about having routers
"communicate by themselves" - so we may need to flesh out exactly
what you are proposing, and what use case this is for.
--
Sean M. Collins