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) <ba...@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" <amot...@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 <pengxu...@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@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 > > > _______________________________________________ > 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
