IPv6 fragmented packets are being reassembled as they pass through the linux qbr bridge in Red Hat OpenStack Platform

Issue

IPv6 fragmented packets are being reassembled as they pass through the linux qbr bridge in Red Hat OpenStack Platform. Note that this behavior creates problems in OpenStack, where we have:

Host A on external network with MTU 1500
<blackbox network with MTU 1500>
Hypervisor with all external interfaces set to MTU 9000 and all bridges and tap interfaces to MTU 9000
Instance on this hypervisor with MTU 1500

As a detailed view:

qvb (veth MTU 9000) <-> qbr (Linux bridge MTU 9000) <-> tap ( tap interface MTU 9000) <-> instance (MTU 1500)

The issue seems to be related to the backport of this upstream commit https://github.com/torvalds/linux/commit/efb6de9b4ba0092b2c55f6a52d16294a8a698edd
Referred by OpenStack upstream bug: https://bugs.launchpad.net/neutron/+bug/1463911

The upstream bugfix was backported into the RHEL 7.3 kernel

The following was fixed and already backported into the kernel in question:
https://bugs.launchpad.net/neutron/+bug/1463911

These were fixed here:

[root@rhospbl-1 ~]# rpm -q kernel --changelog | grep 1265259 | grep -i v6
- [net] netfilter: bridge: Use __in6_dev_get rather than in6_dev_get in br_validate_ipv6 (Paolo Abeni) [1265259]
- [net] netfilter: bridge: split ipv6 code into separated file (Paolo Abeni) [1265259]
- [net] netfilter: bridge: forward IPv6 fragmented packets (Paolo Abeni) [1265259]
- [net] netfilter: bridge: re-order br_nf_pre_routing_finish_ipv6() (Paolo Abeni) [1265259]
- [net] netfilter: nf_tables_bridge: set the pktinfo for IPv4/IPv6 traffic (Paolo Abeni) [1265259]

https://bugzilla.redhat.com/show_bug.cgi?id=1265259
https://bugzilla.redhat.com/show_bug.cgi?id=1253154

It seems that https://github.com/torvalds/linux/commit/efb6de9b4ba0092b2c55f6a52d16294a8a698edd resolved an issue with packet drops, but introduced a problem with unwanted packet reassembly on the network. So, now, instead of dropping fragments, these are reassembled, although this behavior may be undesired,

At host A with an MTU of 1500 one is fragmenting 3.5K Bytes in 2x1.5K + 0.5K
At point these packets are recombined to 3.5K Bytes, because the next leg is having 9K Bytes MTU.
At host B with an MTU of 1500 the 3.5K packets arrive, but are refused due to the 1500 Byte MTU.

The instance is configured with MTU 1500, and therefore refuses the packets.

[user@wks-user 01805825]$ tshark -nn -r tap4130202d-c5.pcap sip | head -n2
198  15.026115 0.000000 e8:f7:24:9c:e7:26 → fa:16:3e:19:bf:3a 2607:f160:10:230d:ce:104:0:5 → 2607:f160:10:24ff::8 5090 5060 SIP/SDP 3234  Request: INVITE sip:16692481053@vzimstest.com | 
199  15.026337 0.000222 fa:16:3e:19:bf:3a → e8:f7:24:9c:e7:26 2607:f160:10:24fd::47 → 2607:f160:10:230d:ce:104:0:5 5090 5060 ICMPv6 1294  Packet Too Big
[user@wks-user 01805825]$ tshark -nn -r tap4130202d-c5.pcap -V frame.number == 199  | grep -i MTU -C5
    [Destination GeoIP: Unknown]
Internet Control Message Protocol v6
    Type: Packet Too Big (2)
    Code: 0
    Checksum: 0x50bf [correct]
    MTU: 1500
    Internet Protocol Version 6, Src: 2607:f160:10:230d:ce:104:0:5, Dst: 2607:f160:10:24ff::8
        0110 .... = Version: 6
        .... 1000 0000 .... .... .... .... .... = Traffic class: 0x80 (DSCP: CS4, ECN: Not-ECT)
            .... 1000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 4 (32)
            .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)