IPv6 address selection uses wrong source addresses

[Pentium4User]

Hello! Please provide the following information

libtorrent version (or branch): libtorrent-rasterbar2.0t64:amd64 2.0.10-1.1+b1

platform/architecture: Debian 13 amd64

compiler and compiler version: dunno, I use the official Debian packages

If I don't bind it explicitly to a global (2000::/3) IPv6 address, it sometimes uses link-local or ULA (if available) for connections to global addresses. To connect to GUA (2000::/3), it must use a GUA source address. Is it maybe possible to use the /etc/gai.conf that already serves that purpose for other stuff in the system?

This has already been discusses at qbittorrent and it seems this is handled by libtorrent. https://github.com/qbittorrent/qBittorrent/issues/19618

To reproduce, just let it bind to all addresses or to a specific interface and then use a sniffer and see that outgoing packages to the internet sometimes have link-local source addresses.

[ssiloti]

Are these packets TCP or UDP? What is the output of ip addr?

[Pentium4User]

Am 22.06.2024 um 09:54:23 Uhr schrieb Steven Siloti:

Are these packets TCP or UDP?

Some are TCP and some are UDP, the vast majority was UDP in the test.

What is the output of ip addr?

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:0d:0f:90 brd ff:ff:ff:ff:ff:ff inet 172.17.1.20/16 brd 172.17.255.255 scope global dynamic noprefixroute enp0s3 valid_lft 85313sec preferred_lft 85313sec inet6 fd00:abd::123/64 scope global valid_lft forever preferred_lft forever inet6 2a01:170:xyz:xyz:a00:27ff:fe0d:f90/64 scope global dynamic noprefixroute valid_lft 2591989sec preferred_lft 604789sec inet6 fe80::a00:27ff:fe0d:f90/64 scope link noprefixroute valid_lft forever preferred_lft forever @.*** ~]$

I only see that when ULA is being assigned additional to a GUA. I haven't seen link-local as src in my test.

If you need more info, I can give you the pcapng file.

-- kind regards Marco

[ssiloti]

This was introduced by #4339. Prior to that change ULA addresses were explicitly excluded from being considered routable. We should probably re-add the exclusion of ULA (and other known non-global IPv6 ranges) from being considered routable.

[ValeZAA]

What happens if you send such ULA source IPv6 packet? Does router do NAT66? Or just says it is a wrong packet in ICMPv6?

[Pentium4User]

Am 04.09.2024 um 10:18:25 Uhr schrieb ValeZAA:

What happens if you send such ULA source IPv6 packet? Does router do NAT66? Or just says it is a wrong packet in ICMPv6?

I don't do NAT66, so the packet goes out as-is and some ISPs allow such outgoing packets, the receiver can't use it anyway. Other ISPs block it.

Even when NAT66 is seldom, this case could exist and should be handled. Maybe use a connectivity test. If a server can be reached with the ULA address, the address can be used for outgoing connections.

But it should be used as last resort and GUA should be preferred in any case.

-- Gruß Marco

Send unsolicited bulk mail to @.***