[openstack-dev] [Neutron][IPv6][Security Group] BP: Support ICMP type filter by security group

Akihiro Motoki amotoki at gmail.com
Fri Mar 7 19:02:52 UTC 2014

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.


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?
>>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
>>> IPv6 Router Advertisement security group rule on compute node in my
>>> code review [2].
>>> Currently, only security group rule direction, protocol, ethertype and
>>> range are supported by neutron security group rule data structure. To
>>> Router Advertisement coming from network node or provider network to VM
>>> compute node, we need to specify ICMP type to only allow RA from known
>>> (network node dnsmasq binded IP or known provider gateway).
>>> To implement this and make the implementation extensible, maybe we can
>>> an additional table name "SecurityGroupRuleData" with Key, Value and ID
>>> 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
>>> 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]
>>> [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
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list