<span id="mailbox-conversation">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.<div><br></div>

<div>Thanks,</div>

<div>Xuhan</div></span><div class="mailbox_signature">—<br>Xu Han Peng (xuhanp)</div>

<br><br><div class="gmail_quote"><p>On Sat, Mar 8, 2014 at 3:19 AM, Akihiro Motoki <span dir="ltr"><<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>></span> wrote:<br></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>Hi Robert,

Thanks for the clarification. I understand the motivation.

<br><br>I think the problem can be split into two categories:

<br>(a) user configurable rules vs infra enforced rule, and

<br>(b) DHCP/RA service exists inside or outside of Neutron

<br><br>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.

<br>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.

<br><br>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.

<br>It is true that the current Neutron cannot works with dhcp server

outside of neutron.

<br><br>I agree that adding a security group rule to allow RA is reasonable as

a workaround.

<br>However, for a long time solution, it is better to explore a way to configure

infra-required rules.

<br><br>Thanks,

<br>Akihiro

<br><br><br>On Sat, Mar 8, 2014 at 12:50 AM, Robert Li (baoli) <baoli@cisco.com> wrote:

<br>> Hi Akihiro,

<br>>

<br>> In the case of IPv6 RA, its source IP is a Link Local Address from the

<br>> router's RA advertising interface. This LLA address is automatically

<br>> generated and not saved in the neutron port DB. We are exploring the idea

<br>> of retrieving this LLA if a native openstack RA service is running on the

<br>> subnet.

<br>>

<br>> Would SG be needed with a provider net in which the RA service is running

> external to openstack?

<br>>

<br>> In the case of IPv4 DHCP, the dhcp port is created by the dhcp service,

<br>> and the dhcp server ip address is retrieved from this dhcp port. If the

<br>> dhcp server is running outside of openstack, and if we'd only allow dhcp

> packets from this server, how is it done now?

<br>>

<br>> thanks,

<br>> Robert

<br>>

<br>> On 3/7/14 12:00 AM, "Akihiro Motoki" <amotoki@gmail.com> wrote:

<br>>

>>I wonder why RA needs to be exposed by security group API.

<br>>>Does a user need to configure security group to allow IPv6 RA? or

>>should it be allowed in infra side?

<br>>>

<br>>>In the current implementation DHCP packets are allowed by provider

>>rule (which is hardcoded in neutron code now).

<br>>>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?

<br>>>

<br>>>Thanks,

<br>>>Akihiro

<br>>>

<br>>>On Mon, Mar 3, 2014 at 10:39 PM, Xuhan Peng <pengxuhan@gmail.com> wrote:

<br>>>> I created a new blueprint [1] which is triggered by the requirement to

<br>>>>allow

<br>>>> IPv6 Router Advertisement security group rule on compute node in my

<br>>>>on-going

<br>>>> code review [2].

<br>>>>

<br>>>> Currently, only security group rule direction, protocol, ethertype and

<br>>>>port

<br>>>> range are supported by neutron security group rule data structure. To

<br>>>>allow

<br>>>> Router Advertisement coming from network node or provider network to VM

<br>>>>on

<br>>>> compute node, we need to specify ICMP type to only allow RA from known

<br>>>>hosts

>>> (network node dnsmasq binded IP or known provider gateway).

<br>>>>

<br>>>> To implement this and make the implementation extensible, maybe we can

<br>>>>add

<br>>>> an additional table name "SecurityGroupRuleData" with Key, Value and ID

<br>>>>in

<br>>>> it. For ICMP type RA filter, we can add key="icmp-type" value="134", and

<br>>>> security group rule to the table. When other ICMP type filters are

<br>>>>needed,

<br>>>> similar records can be stored. This table can also be used for other

>>> firewall rule key values.

>>> API change is also needed.

<br>>>>

>>> Please let me know your comments about this blueprint.

<br>>>>

<br>>>> [1]

<br>>>>

<br>>>>https://blueprints.launchpad.net/neutron/+spec/security-group-icmp-type-f

<br>>>>ilter

<br>>>> [2] https://review.openstack.org/#/c/72252/

<br>>>>

<br>>>> Thank you!

<br>>>> Xuhan Peng

<br>>>>

<br>>>> _______________________________________________

<br>>>> OpenStack-dev mailing list

<br>>>> OpenStack-dev@lists.openstack.org

<br>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

<br>>>>

<br>>>

<br>>>_______________________________________________

<br>>>OpenStack-dev mailing list

<br>>>OpenStack-dev@lists.openstack.org

<br>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

<br>>

<br>>

<br>> _______________________________________________

<br>> OpenStack-dev mailing list

<br>> OpenStack-dev@lists.openstack.org

<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

<br><br>_______________________________________________

<br>OpenStack-dev mailing list

<br>OpenStack-dev@lists.openstack.org

<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

<br></p></blockquote></div><br>