Open Stack

Robert,

Thanks for your comments! See my replies inline.


On Thu, Feb 27, 2014 at 9:56 PM, Robert Li (baoli) <baoli at cisco.com> wrote:

>  Hi Xuhan,
>
>  Thank you for your summary. see comments inline.
>
>  --Robert
>
>   On 2/27/14 12:49 AM, "Xuhan Peng" <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.
>
> [Xuhan]  I agree there is no need to create another LLA for gateway port
in this case since one is automatically created. We can probably use the
calculation method introduced by this patch (
https://review.openstack.org/#/c/56184/) to accomplish this, and create a
RA rule based on this address.

As you pointed out in my code review, the ICMPv6 type filter is not
supported by current security group. We will need a new blueprint to enable
this. I will try to create one soon.

>
>  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.
>

[Xuhan]  This is a problem that we may not be able to solve in Icehouse
considering the time left. However, I think the gateway port is not created
until we attach the subnet on the router. Therefore, for a workaround in
Icehouse, we can allow LLA as the gateway IP passed to subnet creation, so
RA from the provider network gateway LLA can also be allowed. The logic to
create RA rule can looks like this:

1. if gateway ip of a subnet is GUA (when dnsmasq or a service VM is
sending RA):
          calculate the gateway port's LLA based on port's MAC address,
          then allow RA from this LLA.

2. if gateway ip of a subnet is LLA (for provider network existing gateway)
          allow RA from this LLA.

In next release, we can evaluate how to allow RA from existing gateway in a
better way.

Thoughts?


>  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/
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140228/13bdf082/attachment.html>