Eelco Chaudron <[email protected]> writes: > On 4 Apr 2022, at 23:54, Paolo Valerio wrote: > >> Aaron Conole <[email protected]> writes: >> >>> Paolo Valerio <[email protected]> writes: >>> >>>> The next header contained in the last extension header of the IPv6 >>>> later frags still contain the information of the upper layer protocol >>>> number. >>>> >>>> Similarly to what OvS does for IPv4, allow L4 matches for later IPv6 >>>> frags as well by processing later frags and storing the nw_proto >>>> information. >>>> >>>> Signed-off-by: Paolo Valerio <[email protected]> >>>> --- >>> >>> Digging in, I could never find a reason why ipv6 was treated differently >>> in this manner, but I guess there could be cases where the header layout >>> could cause problems (see the top of the while() block). I don't know >>> that it's a practical concern (other values are probably less common), >>> but it was the only thing I could come up with for why the match might >>> behave this way. I haven't done enough mailing list archeology to have >>> a good idea. >> >> Guess this may probably be due to (rfc8200 section-4.5): >> >> "The subsequent fragment packets are composed of: >> >> [...] >> >> (2) A Fragment header containing: >> >> The Next Header value that identifies the first header >> after the Per-Fragment headers of the original packet. >> >> [...]" >> >> where the "first header" in the original packet could be another >> extension header or an upper-layer header, while the Fragment header is >> the last EH for later fragments (according to section 4.5).
Thanks for digging in and finding this. >> If I'm not missing something, it makes sense to drop the patch. >> It's probably a good thing if we document the different behavior between >> IPv4 and IPv6 for later frags, though. > > Alternatively, we could check if the next header is a non-extension header > and if so, mark it as such. > > The only problem might be the case where packets do have extension > headers after the fragmentation header, and they might be dropped > (handled differently). I think it might be best to keep the system as-is. If we add this "feature," users will still need to do matches like: table=X,ip6,ct_state=-trk actions=ct(...) They can try to optimize the flow table looks by doing individual selections, but it will be confusing to flow writers (and take an extra bit of time to debug) when they get missed packets. Even if we try to make things convenient, there can be edge cases we miss - and today systems like OVN already accommodate the nuance of v4 vs v6. I'm in favor of a documentation patch instead that spells it out for flow writers to clearly understand. That way we don't have a custom state machine to try and work around this limitation. > Anyhow, whatever we decide, we should document it in both the documentation > and code. > > //Eelco _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
