Open Stack

Hi Robert,

Thanks for the clarification. I understand the motivation.

I think the problem can be split into two categories:
(a) user configurable rules vs infra enforced rule, and
(b) DHCP/RA service exists inside or outside of Neutron

Regarding (a), I believe DHCP or RA related rules is better to be handled
by the infra side because it is required to ensure DHCP/RA works well.
I don't think it is a good idea to delegate users to configure rule to
allow them.
It works as long as DHCP/RA service works inside OpenStack.
This is the main motivation of my previous question.

On the other hand, there is no way to cooperate with DHCP/RA
services outside of OpenStack at now. This blocks the usecase in your mind.
It is true that the current Neutron cannot works with dhcp server
outside of neutron.

I agree that adding a security group rule to allow RA is reasonable as
a workaround.
However, for a long time solution, it is better to explore a way to configure
infra-required rules.

Thanks,
Akihiro


On Sat, Mar 8, 2014 at 12:50 AM, Robert Li (baoli) <baoli at cisco.com> wrote:
> Hi Akihiro,
>
> In the case of IPv6 RA, its source IP is a Link Local Address from the
> router's RA advertising interface. This LLA address is automatically
> generated and not saved in the neutron port DB. We are exploring the idea
> of retrieving this LLA if a native openstack RA service is running on the
> subnet.
>
> Would SG be needed with a provider net in which the RA service is running
> external to openstack?
>
> In the case of IPv4 DHCP, the dhcp port is created by the dhcp service,
> and the dhcp server ip address is retrieved from this dhcp port. If the
> dhcp server is running outside of openstack, and if we'd only allow dhcp
> packets from this server, how is it done now?
>
> thanks,
> Robert
>
> On 3/7/14 12:00 AM, "Akihiro Motoki" <amotoki at gmail.com> wrote:
>
>>I wonder why RA needs to be exposed by security group API.
>>Does a user need to configure security group to allow IPv6 RA? or
>>should it be allowed in infra side?
>>
>>In the current implementation DHCP packets are allowed by provider
>>rule (which is hardcoded in neutron code now).
>>I think the role of IPv6 RA is similar to DHCP in IPv4. If so, we
>>don't need to expose RA in security group API.
>>Am I missing something?
>>
>>Thanks,
>>Akihiro
>>
>>On Mon, Mar 3, 2014 at 10:39 PM, Xuhan Peng <pengxuhan at gmail.com> wrote:
>>> I created a new blueprint [1] which is triggered by the requirement to
>>>allow
>>> IPv6 Router Advertisement security group rule on compute node in my
>>>on-going
>>> code review [2].
>>>
>>> Currently, only security group rule direction, protocol, ethertype and
>>>port
>>> range are supported by neutron security group rule data structure. To
>>>allow
>>> Router Advertisement coming from network node or provider network to VM
>>>on
>>> compute node, we need to specify ICMP type to only allow RA from known
>>>hosts
>>> (network node dnsmasq binded IP or known provider gateway).
>>>
>>> To implement this and make the implementation extensible, maybe we can
>>>add
>>> an additional table name "SecurityGroupRuleData" with Key, Value and ID
>>>in
>>> it. For ICMP type RA filter, we can add key="icmp-type" value="134", and
>>> security group rule to the table. When other ICMP type filters are
>>>needed,
>>> similar records can be stored. This table can also be used for other
>>> firewall rule key values.
>>> API change is also needed.
>>>
>>> Please let me know your comments about this blueprint.
>>>
>>> [1]
>>>
>>>https://blueprints.launchpad.net/neutron/+spec/security-group-icmp-type-f
>>>ilter
>>> [2] https://review.openstack.org/#/c/72252/
>>>
>>> Thank you!
>>> Xuhan Peng
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>_______________________________________________
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev