Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!weretis.net!feeder8.news.weretis.net!news1.tnib.de!feed.news.tnib.de!news.tnib.de!.POSTED.torres.zugschlus.de!not-for-mail
From: Marc Haber <mh+usenetspam1118@zugschl.us>
Newsgroups: comp.os.linux.misc
Subject: Re: Anybody Using IPv6?
Date: Wed, 21 May 2025 21:18:15 +0200
Organization: private site, see http://www.zugschlus.de/ for details
Message-ID: <100l8to$80oi$1@news1.tnib.de>
References: <100hijb$25ta5$5@dont-email.me> <100hl34$3of0i$1@news1.tnib.de> <m935taF8pgbU4@mid.individual.net> <100i89e$19k3$1@news1.tnib.de> <100i92h$2a8rb$3@dont-email.me> <m93p9bF8pgcU12@mid.individual.net> <100ieve$1o3d$1@news1.tnib.de> <m93tqqF8pgcU15@mid.individual.net> <100irbu$2j9c$1@news1.tnib.de> <m94pk5F8pgbU11@mid.individual.net> <100jqfp$4o04$1@news1.tnib.de> <100k1v0$2o6n2$1@dont-email.me> <100kcnb$649q$1@news1.tnib.de> <wwv5xhtj51m.fsf@LkoBDZeT.terraraq.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 21 May 2025 19:18:16 -0000 (UTC)
Injection-Info: news1.tnib.de; posting-host="torres.zugschlus.de:81.169.166.32";
	logging-data="262930"; mail-complaints-to="abuse@tnib.de"
X-Newsreader: Forte Agent 6.00/32.1186

Richard Kettlewell <invalid@invalid.invalid> wrote:
>Marc Haber <mh+usenetspam1118@zugschl.us> writes:
>> We are talking about how a system with both IPv4 and IPv6 enabled
>> behaves on an IPv4-only network. Such a system will not have IPv6
>> routes going further than the automatically established link-local
>> networks and thus any attempts to use IPv6 will immediately result in
>> the network stack returning a "no route to host" error message.
>>
>> A well behaved application is then expected to try the next IP address
>> it might know for the desired communications partner. This applies to
>> both IPv4 and IPv6. Sadly I don't know at the moment whether this
>> functionality is implemented in the network stack of whether the
>> application is expected to implement the necessary logic.
>
>Destination addresses are selected in userland. getaddrinfo() is the
>standard implementation, returning an ordered list of destination
>addresses corresponding to the requested name. The application is
>expected to work through them in order.

So it is actually a well behaved application that should do that.
Thanks for the correction. I don't develop enough software to know
that (and I do sincerely hope that there is a python module that
solves this issue for me should I ever need it).

>> When I am talking about gai.conf here, I actually mean the in-kernel
>> address label table that is maintained by virtue of the ip addrlabel
>> command. Most modern Linux distributions only have gai.conf as kind of
>> a legacy interface that is not necessarily connected at all to the
>> in-kernel table that the kernel actually uses. I don't know if and
>> which distributions have code that reads gai.conf and uses the
>> contents to initialize the in-kernel table at startup time, since my
>> systems directly interface with ip addrlabel (often via
>> systemd-networkd).
>
>AFAICS for destination address selection getaddrinfo() follows gai.conf
>(and ignores ip-addrlabel). So I think you have conflated source and
>destination address selection here.

Also that might be correct. I usually fight with source address
selection since I have a dynamic and a static prefix in my home
network and wish that certain programs (ssh, for example) use the
static prefix while others use the dynamic one (for privacy and
performance reasons¹). I happen to be happy with the default for the
destination address and wish IPv6 to be preferred.

Greetings
Marc

¹ the static prefix goes through a tunnel and therefore is some 10 ms
slower in latency than the dynamic prefix
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402