netdev - Re: IPv6 address scope not set to operator-configured value

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] [day] [month] [year] [list]

Message-ID: <c737bd4c-7cd4-11f0-3906-3a9018170888@kernel.org>
Date: Thu, 14 Sep 2023 08:43:09 -0600
From: David Ahern <dsahern@...nel.org>
To: Tj <linux@....tj>, netdev@...r.kernel.org,
 Guillaume Nault <gnault@...hat.com>
Subject: Re: IPv6 address scope not set to operator-configured value

On 9/14/23 7:51 AM, Tj wrote:
> Apologies if this doesn't thread - I've had to manually add the
> In-Reply-To header because I did not receive Guillaume's reply and only
> discovered it via the email archive.
> 
> Not being able to set the scope causes a problem. The scenario in which
> I need to use it is interfaces with multiple global and ULA addresses
> where a multicast-DNS responder needs to choose the correct address to
> send in reply to queries. This affects both avahi and systemd-resolved
> which currently seem to chose almost - but not quite - at random; but
> enough so that it often breaks.
> 
> E.g: if the query originates from a ULA address the response should give
> a ULA address; if the query originates from a global then a global
> address, etc. In fact, being able to simply set scopes and enable the
> responder to be configured to use a specific scope would be helpful.
> It'd certainly avoid having to hard-code logic to determine what address
> ranges represent a particular logical zone.

We cannot change the behavior of an existing API. We have tried that
many times in the past, and inevitably most changes are reverted.