Re: [PATCH net v2] ipv6: Apply max_dst_opts_cnt to ip6_tnl_parse_tlv_enc_lim

[Daniel Borkmann <daniel@iogearbox.net>]

On 4/20/26 8:55 PM, Justin Iurman wrote:
> On 4/19/26 16:31, Ido Schimmel wrote:
>> On Sun, Apr 19, 2026 at 12:37:35AM +0200, Justin Iurman wrote:
>>> Nope. But if it happens, users would be confused as max_dst_opts_cnt would
>>> not have the same meaning in two different code paths. OTOH, I agree that
>>> such situation would look suspicious. I guess it's fine to keep your patch
>>> as is and to not over-complicate things unnecessarily.
>>
>> I agree that it's weird to reuse max_dst_opts_cnt here:
>>
>> 1. The meaning is different from the Rx path.
>>
>> 2. We only enforce max_dst_opts_cnt, but not max_dst_opts_len.
>>
>> 3. The default is derived from the initial netns, unlike in the Rx path.
>>
>> Given the above and that:
>>
>> 1. We believe that 8 options until the tunnel encapsulation limit option
>> is liberal enough.
>>
>> 2. We don't want to over-complicate things.
>>
>> Can we go with an hard coded 8 and see if anyone complains? In the
>> unlikely case that someone complains we can at least gain some insight
>> into how this option is actually used with tunnels.
> 
> In general, I'm not a big fan of hard-coded values, but I also think that in this context it would make sense to do so. This is not a strong +1, let's say it's more a "not against it".

Makes sense, I'll update it in a v3.