Hi Yuhan Sorry I am slow to respond, but I was catching up on some emails and found this one from you. Regarding your comments on the RA from the router gateway port...
I disagree that the LLA for the qg-xxxx interface is (or should be) the gateway for the tenant's subnet. On the contrary, it should be the LLA of the qr-yyyy to which the dnsmasq binds [2]. Using [1] as a starting point, packets arriving on the qr-xxxx interface are routed across (via linux) in the qrouter-namespace, taking the default route (gateway-ip) as specified in [1] to unknown destinations. In a future release, we may need to consider implementing support for accepting RA from service providers' upstream routers on the qg-xxxx interface, but whether we allow a SLAAC address on the external gateway port needs further discussion (perhaps a topic for the IPv6 sub-team IRC). SLAAC requires a /64 subnet which might be considered a bit of overkill for what's typically a point-to-point connection. Let's see about adding it to the topics to discuss. Cheers, Randy [1] https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port [2] https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace On Thu, Feb 27, 2014 at 12:49 AM, Xuhan Peng <pengxu...@gmail.com> wrote: > As the follow up action of IPv6 sub-team meeting [1], I created a new > blueprint [2] to store both IPv6 LLA and GUA address on router interface > port. > > Here is what it's about: > > Based on the two modes (ipv6-ra-mode and ipv6-address-mode) design[3], RA > can be sent from both openstack controlled dnsmasq or existing devices. > > RA From dnsmasq: gateway ip that dnsmasq binds into should be link local > address (LLA) according to [4]. This means we need to pass the LLA of the > created router internal port (i.e. qr-xxxx) to dnsmasq spawned by openstack > dhcp agent. In the mean while, we need to assign an GUA to the created > router port so that the traffic from external network can be routed back > using the GUA of the router port as the next hop into the internal subnet. > Therefore, we will need some change to the current logic to leverage both > LLA and GUA on router port. > > RA from existing device on the same link which is not controlled by > openstack: dnsmasq will not send RA in this case. RA is sending from > subnet's gateway address which should also be LLA according to [4]. > Allowing subnet's gateway IP to be LLA is enough in this case. Current code > works when force_gateway_on_subnet = False. > > RA from router gateway port (i.e. qg-xxxx): the LLA of the gateway port > (qg-xxxx) should be set as the gateway of tenant subnet to get the RA from > that. This could be potentially calculated by [5] or by other methods in > the future considering privacy extension. However, this will make the > tenant network gateway port qr-xxxx useless. Therefore, we also need code > change to current router interface attach logic. > If you have any comments on this, please let me know. > > [1] > http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-02-25-14.02.html > [2] > https://blueprints.launchpad.net/neutron/+spec/ipv6-lla-gua-router-interface > [3] https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes > [4] http://tools.ietf.org/html/rfc4861 > [5] https://review.openstack.org/#/c/56184/ > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev