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