[openstack-dev] [neutron][networking-odl][qa] What's the recommended behavior for SG Rules with ethertype='IPv6' and protocol='icmp' ?

Sridhar Gaddam sgaddam at redhat.com
Sun Mar 26 12:31:08 UTC 2017

On Fri, Mar 24, 2017 at 7:27 PM, Brian Haley <haleyb.dev at gmail.com> wrote:

> On 03/24/2017 06:41 AM, Ghanshyam Mann wrote:
>> Hi All,
>> Tempest is testing SG rule creation and pinging scenario tests with
>> ethertype='IPv6' and protocol='icmp' [0].
>> In case of ethertype='IPv6', currently neutron accept protocol type
>> as 'icmp', 'icmpv6' and 'ipv6-icmp' which again seems like duplication
>> of SG rules bug on neutron side but not sure [1]
>> But it seems like some driver does not work with 'icmp' on IPv6, at
>> least ODL as mentioned in bug [2]. Where few others like ML2/OVS
>> iptables driver convert 'icmp' to 'icmpv6' when ethertype='IPv6' and had
>> no issue with 'icmp'.
>> IMO neutron should keep accepting 'icmp' for IPv6 for backward
>> compatibility and legacy usage and tempest should test 'icmp' also along
>> with other protocol type.
>> But we need more feedback on that what is right way (as per backward
>> compatibility pov) and recommended way for having best behaviour for SG
>> rules on IPv6. What best can work for all plugins also?
> Thanks for raising this issue.  Let me just restate it a little so it's
> clear.
> 1. One can create an IPv6 rule using protocol value "icmp" today, and the
> base security group code does the right thing changing the rule to be
> correct for the underlying implementation, for example, "ipv6-icmp" for
> iptables.  It doesn't look like all other drivers handle this properly.
> ​Well, let the Neutron API accept multiple values like
"icmp/icmpv6/ipv6-icmp", but IMO it should store a single Security Group
rule in the DB and raise "Duplicate error when similar rule is configured
once again".
Currently, Neutron treats each of them as a different Security Group rule
and stores them as separate entries in the DB.
However, IPtables Firewall driver in Neutron is converting[1] the
"ethertype=IPv6 and protocol=icmp" as a request to ICMPv6 and applying the
necessary ip-table rule.

Since this is not a documented behavior, other firewall drivers (which I
guess could be an issue even with OVS firewall driver) may be missing this

> 2. The neutron API will accept multiple values - "icmp", "ipv6-icmp" and
> "icmpv6" for an IPv6 rule, but it will create unique database entries for
> each (I just verified that).  While that shouldn't create multiple entries
> in the base iptables code, it will probably generate a warning in the logs
> about a duplicate being suppressed.
> So there are a few things that could be done:
> 1. Drivers need to accept "icmp" in order to be backwards-compatible with
> the current code.
> 2. Duplicates should be detected and generate 409 (?) errors.
> 3. We should add a migration (IMO) where any duplicates are squashed.
> ​Agree with your points.

> The open question is, do we want to change the DB to have a different
> value here, like "icmpv6" ?  We could obviously add a migration where we
> update the value.  The problem is that flag day could pose a problem if
> out-of-tree drivers don't support the new value.  I think we should leave
> it "icmp" for that reason, thoughts from others?
> IMO, the out-of-tree drivers should be supporting the icmpv6 protocol​
rule properly. There is a possibility that they may hit this issue[
https://bugs.launchpad.net/tempest/+bug/1671366] for not being aware that a
request for "Ethertype=IPv6 and protocol=icmp" should be treated as ICMPv6
SG rule.

Please see the DB entries for the two SG rules -

> -Brian
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170326/95298212/attachment.html>

More information about the OpenStack-dev mailing list