Hi Akihiro, See inline for a question Š.
Thanks, Robert On 3/7/14 2:02 PM, "Akihiro Motoki" <amot...@gmail.com> wrote: >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'd appreciate it if you can explain the above in more detail? I'd like to understand what has caused the limitation. thanks. > >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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
