Comment 5 for bug 1463911

I agree that the best solution would be to have this merged into the linux kernel. Also, I am unaware of a method to prevent reassembly while still using conntrack. Probably the only way to prevent the re-assembly would be to disable conntrack, but then that would break stateful firewalling, and that wouldn't be consistent with OpenStack security groups. So not only is the kernel update the "best" solution, I think its probably the only complete / consistent one.

As far as kernel patches go, I did want to point out that the current behavior for the IPv4 iptables re-assembly / re-fragmentation is to create entirely new fragments. For linux bridges, in both IPv4 and IPv6, I think that the more desirable behavior is to transmit the original fragments instead of re-fragmenting. The reason this behavior would be preferred is that re-fragmentation now introduces the MTU of the bridge into the picture. If the MTU of the bridge is larger or smaller than the MTU of the VM or gateway this can cause problems. Note that with OpenStack Juno the MTU of the bridges used by the OVSHybridIptablesFirewallDriver is a global value, so if you are using differ MTU for provider and internal networks, you can NOT use OVSHybridIptablesFirewallDriver for IPv4 either. In OpenStack Kilo, per network MTU is a supported feature, so I assume this is not a problem for Kilo (we are using Juno, so I cannot confirm this).

However, I should mention that an advantage of re-fragmentation is that you are guaranteed that the packet that is passed by iptables really matches what iptables thinks it does. I know there are some security attacks that take advantage of fact that ip fragment overlaps are handled differently by different operating systems. So iptables might interpret the packet as having one meaning and the end system might interpret it as something else. Doing re-fragmentation solves this issue. However, I would suggest ip fragment overlaps are really bad behavior, and the packet should probably just be dropped rather than trying to fix this by re-fragmenting.

This MTU issue is sort of secondardy to the IPv6 fragmentation patch BUT if someone is looking here to figure out the patch they should submit, I would like them to have this extra info in case they want to improve the patch.