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.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
