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]
Message-ID: <1fb36101-5a3c-4c81-8271-4002768fa0bd@gmail.com>
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.)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ