Connecting to a dual-stack (ipv4 & ipv6 available) endpoint can return EADDRNOTAVAIL

[mikekap]

Version
tokio v1.41.1 (but master is affected too)

Platform
Linux meeting-data 6.8.0-1029-aws #31~22.04.1-Ubuntu SMP Thu Apr 24 21:16:18 UTC 2025 x86_64 GNU/Linux

Description
The issue is TcpStream::connect may sometimes return EADDRNOTAVAIL (errno 99) hiding the actual error that occurred in an ipv4 connection.

When running in an ipv4-only environment (i.e. no external ipv6), getaddrinfo will happily return ipv6 addresses as well. The problem is that the code

tokio/tokio/src/net/tcp/stream.rs

Lines 116 to 132 in 5efb1c3

	let addrs = to_socket_addrs(addr).await?;
	let mut last_err = None;
	for addr in addrs {
	match TcpStream::connect_addr(addr).await {
	Ok(stream) => return Ok(stream),
	Err(e) => last_err = Some(e),
	}
	}
	Err(last_err.unwrap_or_else(|| {
	io::Error::new(
	io::ErrorKind::InvalidInput,
	"could not resolve to any address",
	)
	}))

returns the LAST error encountered. So to trigger EADDRNOTAVAIL, you need:

• getaddrinfo returns [IPV4, IPv6] in that order
• Attempt to connect to IPV4 yields an actual network error (e.g. timeout, connection refused)
• The code attempts an IPV6 connection.
• The IPV6 connection fails with EADDRNOTAVAIL since the host doesn't have external IPv6 support enabled.
• The last error wins, so instead of a "connection refused" message, you get a "cannot assign requested address"

For reference for others, one fix for this is to disable returning ipv6 addresses - add options no-aaaa to /etc/resolv.conf.

[ADD-SP]

It looks like std::net::TcpStream::connect has the similar behavior. I think the error message should be improved, but I’m not sure how to do it.

// https://doc.rust-lang.org/1.90.0/src/std/net/tcp.rs.html#169-171
pub fn connect<A: ToSocketAddrs>(addr: A) -> io::Result<TcpStream> {
    super::each_addr(addr, net_imp::TcpStream::connect).map(TcpStream)
}

// https://doc.rust-lang.org/1.90.0/src/std/net/mod.rs.html#71-89
fn each_addr<A: ToSocketAddrs, F, T>(addr: A, mut f: F) -> io::Result<T>
where
    F: FnMut(io::Result<&SocketAddr>) -> io::Result<T>,
{
    let addrs = match addr.to_socket_addrs() {
        Ok(addrs) => addrs,
        Err(e) => return f(Err(e)),
    };
    let mut last_err = None;
    for addr in addrs {
        match f(Ok(&addr)) {
            Ok(l) => return Ok(l),
            Err(e) => last_err = Some(e),
        }
    }
    Err(last_err.unwrap_or_else(|| {
        io::const_error!(ErrorKind::InvalidInput, "could not resolve to any addresses")
    }))
}

[seakerOner]

But what if the provided address list contained multiple entries (100 for example) and all of them failed for different reasons?
It could be nice to accumulate all the errors along with their corresponding addresses instead of returning just the last one.

[seakerOner]

maybe as an optional feature to avoid some kind of overhead :D

[ADD-SP]

It could be nice to accumulate all the errors along with their corresponding addresses instead of returning just the last one.

This is a breaking change unless we add a dedicated interface. However, we usually only mirror the interfaces of the std::net::TcpStream in the tokio::net::TcpStream.

But what if the provided address list contained multiple entries (100 for example) and all of them failed for different reasons?

Umm, this looks like an extreme case, which means that most of the addresses returned by getaddrinfo are not usable. It makes more sense for application to resolve the domain manually before invoking tokio::net::TcpStream::connect in such a case.

[mikekap]

Fwiw Go’s answer here is to respect getaddrinfo ordering (which is configured in gai.conf) - it will try to connect to all endpoints but in case of failure it returns the first error.

[seakerOner]

This is a breaking change unless we add a dedicated interface. However, we usually only mirror the interfaces of the std::net::TcpStream in the tokio::net::TcpStream.

That makes sense, so adding something like TcpStream::connect_verbose() would probably go against Tokio's philosophy, right?

Umm, this looks like an extreme case, which means that most of the addresses returned by getaddrinfo are not usable. It makes more sense for application to resolve the domain manually before invoking tokio::net::TcpStream::connect in such a case.

Sorry but could you clarify this part? I might be misunderstanding what you meant. Are you referring to DNS resolving? Getting the DNS Record types A/AAAA (IPv4, IPv6) from a DNS Name Server with lookup_host() doesn't guarantee which ones will succeed or what specific errors they'll produce when passed to TcpStream::connect.

[Darksonn]

Yeah, this seems out of scope. You may resolve the address yourself and call TcpStream::connect in a loop if you wish to understand what error comes from each possible address.