yahoo-eng-team team mailing list archive

[Vladimir Eremin <veremin@xxxxxxxxxxxx>]

Public bug reported:

For now, when end user is creating IPv6-enabled tenant network and
attaching it to the virtual router, there is only way to set up external
infrastructure to put traffic back to the router is using DHCPv6 PD[1],
unfortunately, it’s not working at all[2]. Other methods like
implementing BGP is still in development.

BTW, in IPv6 Router Advertisements we have an option called Route
Information Option, RA-RIO[3] 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.

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 RA-RIO prefixes in router namespaces allows
routers communicate by themselves.

For preventing user from advertising subnets that makes no sense for
outside infrastructure, Address Scopes[4] 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://bugs.launchpad.net/neutron/+bug/1505316
[3]: https://tools.ietf.org/html/rfc4191
[4]: https://blueprints.launchpad.net/neutron/+spec/address-scopes

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: rfe

** Summary changed:

- Advertise tenant prefixes from router to outside
+ [RFE] [ipv6] Advertise tenant prefixes from router to outside

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1530331

Title:
  [RFE] [ipv6] Advertise tenant prefixes from router to outside

Status in neutron:
  New

Bug description:
  For now, when end user is creating IPv6-enabled tenant network and
  attaching it to the virtual router, there is only way to set up
  external infrastructure to put traffic back to the router is using
  DHCPv6 PD[1], unfortunately, it’s not working at all[2]. Other methods
  like implementing BGP is still in development.

  BTW, in IPv6 Router Advertisements we have an option called Route
  Information Option, RA-RIO[3] 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.

  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 RA-RIO prefixes in router namespaces
  allows routers communicate by themselves.

  For preventing user from advertising subnets that makes no sense for
  outside infrastructure, Address Scopes[4] 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://bugs.launchpad.net/neutron/+bug/1505316
  [3]: https://tools.ietf.org/html/rfc4191
  [4]: https://blueprints.launchpad.net/neutron/+spec/address-scopes

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1530331/+subscriptions