Thanks all for your comments! Do you guys think we can have a summit session to
discuss the next steps? I can prepare a spec if needed.
Thanks,
Xuhan
—
Xu Han Peng (xuhanp)
On Sat, Mar 8, 2014 at 3:19 AM, 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 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