Open Stack

Hi Xuhan,

Thank you for your summary. see comments inline.

--Robert

On 2/27/14 12:49 AM, "Xuhan Peng" <pengxuhan at gmail.com<mailto:pengxuhan at 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.

[Robert]: in this case, a LLA address is automatically created based on the gateway port's MAC address (EUI64 format). If it's determined that the gateway port is enabled with IPv6 (due to the two modes), then an RA rule can be installed based on the gateway port's automatic LLA.
if a service VM is running on the same subnet that supports IPv6 (either by RA or DHCPv6), then the service VM is attached to a neutron port on the same subnet (the gateway port). In this case, the automatic LLA on that port can be used to install the RA Rule. This is actually the same as in the dnsmasq case: use the gateway port's automatic LLA.


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.

[Robert]
if it's a provider network, the gateway already exists. I believe that the behavior of the —gateway option in the subnet API is to indicate the gateway's true IP address and install default route. In the IPv6 case, however, due to the existence of RA, the gateway doesn't have to be provided. In this case, a neutron gateway port doesn't have to be created, either. Installing a RA rule to prevent RA from malicious source should be done explicitly. A couple of methods may be considered. For example, an option such as —alow-ra <LLA> can be introduced in the subnet API, or the security group rule can be enhanced to allow specification of message type so that a RA rule can be incorporated.

In any case, I don't believe that the gateway behavior should be modified. In addition, I don't think that this functionality (IPv6 RA rule) has to be provided right now, but can be introduced when it's completely sorted out.

The above is just my two cents.

thanks.





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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140227/b10f5baa/attachment.html>