netdev - Re: [PATCH iproute2] vxlan: add support for flowlab inherit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 23 Jan 2024 09:19:00 -0700
From: David Ahern <dsahern@...il.com>
To: Vincent Bernat <vincent@...nat.ch>, Ido Schimmel <idosch@...sch.org>,
 Alce Lafranque <alce@...ranque.net>
Cc: netdev@...r.kernel.org, stephen@...workplumber.org
Subject: Re: [PATCH iproute2] vxlan: add support for flowlab inherit

On 1/23/24 12:58 AM, Vincent Bernat wrote:
> On 2024-01-23 01:41, David Ahern wrote:
>>> My personal
>>> preference would be to add a new keyword for the new attribute:
>>>
>>> # ip link set dev vx0 type vxlan flowlabel_policy inherit
>>> # ip link set dev vx0 type vxlan flowlabel_policy fixed flowlabel 10
>>>
>>> But let's see what David thinks.
>>>
>>
>> A new keyword for the new attribute seems like the most robust.
>>
>> That said, inherit is already used in several ip commands for dscp, ttl
>> and flowlabel for example; I do not see a separate keyword - e.g.,
>> ip6tunnel.c.
> 
> The implementation for flowlabel was modeled along ttl. We did diverge
> for kernel, we can diverge for iproute2 as well. However, I am unsure if
> you say we should go for option A (new attribute) or option B (do like
> for dscp/ttl).

A divergent kernel API does not mean the command line for iproute2 needs
to be divergent. Consistent syntax across ip commands is best from a
user perspective. What are the downsides to making 'inherit' for
flowlabel work for vxlan like it does for ip6tunnel, ip6tnl and gre6?
Presumably inherit is relevant for geneve? (We really need to stop
making these tweaks on a single protocol basis.)