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

Message-ID: <ab9737bc-cc91-6ccd-e104-4a94899e69e8@iam.tj>
Date: Thu, 14 Sep 2023 14:51:23 +0100
From: Tj <linux@....tj>
To: netdev@...r.kernel.org, Guillaume Nault <gnault@...hat.com>,
 David Ahern <dsahern@...nel.org>
Subject: Re: IPv6 address scope not set to operator-configured value

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.