Re: How to check if machine has network connectivity using libcurl api reliably?

From: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 23 Nov 2022 23:59:46 +0000

> In my experience it's been more common recently to see it the other way
> round — IPv6 works fine, while Legacy IP is not working.

Unfortunately, my experience is different.
My "population" is 62M+ clients (with very large variety of ISPs/routers) and ~3% of the population showed significant dual-stack regressions (mostly in DNS+connection phase) vs IPv4 only mode.

So, if some application using dual-stack libcurl wants to perform the best way, it needs to explicitly check if dual-stack has issues and use IPv4 only mode if this is the case.

> You shouldn't need to do that for yourself. If a target host has
> multiple IP addresses, libraries like curl should automatically try
> them *all* in order of preference without the *application* code having to get involved.

That works only if dual-stack in user setup doesn't have problems. Then libcurl will do everything for you.
But if, for example, some DNS server doesn't reply on AAAA queries (or slow to reply) then dual-stack connection in libcurl will have a regression at least one DNS timeout (5s typically)
 or more if secondary and next DNS servers also don't reply on AAAA queries.

And if IPv6 traffic goes throw a slow IPv4 tunnel, then clients may also hit dual-stack connection regressions equal to the Happy Eyeball time interval.
In such cases, IPv4 single-stack "legacy" mode will work much faster than the dual-stack mode.

If Happy Eyeballs 2 were implemented in libcurl, then the switch to IPv4 would be much faster and more efficient in the dual-stack mode in case of IPv6-related problems, but we are not there yet.
And even HEB 2 may incur connection time regressions caused by HEB timeout, which may not be acceptable for some applications.

So, this is something that performance critical application should be aware of, do dual-stack probing in "connectivity tests" and tell libcurl to use the mode which suits best for user-specific network setup.

> Don't go out of your way to *break* that.

I didn't suggest any kind of *break* from IPv6.
But as I keep seeing a lot of IPv6-related problems even in 2022, I suggest being aware of them, do dual-stack "out-of-band" probing and use dual-stack mode in libcurl only if it doesn't show any visible problems compared to IPv4 only mode.

I had several discussions with Daniel Stenberg in this group about how to integrate the "out-of-band" dual-stack probing (which may be very application/system specific) with libcurl
to avoid setting the desired mode explicitly in every transfer in some application (which may have transfers from some "3rd party" closed code), so we can have some kind of "system" layer in the application,
which would allow to control settings for each transfer including the IPv4/IPv6 modes, but we are not there yet either.

So, until the "system" layer controlling transfer settings is added, applications will have to set correctly working IP mode explicitly for each transfer based on results of app-specific "connectivity" test
to avoid dual-stack-related problems.

Thanks,
Dmitry Karpov

-----Original Message-----
From: David Woodhouse <dwmw2_at_infradead.org>
Sent: Wednesday, November 23, 2022 3:10 AM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: [EXTERNAL] Re: How to check if machine has network connectivity using libcurl api reliably?

On Tue, 2022-11-22 at 20:32 +0000, Dmitry Karpov via curl-library wrote:
> If your use dual-stack libcurl, then you probably will need to run
> two "connectivity" tests - one for "IPv4 only" mode and the other for
> dual-stack "IPv6/IPv4".
> That's because you may have issues with IPv6 when IPv4 is working
> well.
>

In my experience it's been more common recently to see it the other way
round — IPv6 works fine, while Legacy IP is not working. You definitely
need to allow for both scenarios. Don't be one of those applications
which fails when Legacy IP is down, while everything else just
continues to work over IPv6.

> In this case, you have only "IPv4 connectivity" and thus need to make
> your dual-stack applications use "IPv4 only" mode.

You shouldn't need to do that for yourself. If a target host has
multiple IP addresses, libraries like curl should automatically try
them *all* in order of preference without the *application* code having
to get involved.

> (Of course, if you decide that your applications always use IPv4,
> then you need to run only "IPv4 connectivity" tests and explicitly
> set "IPv4 only" mode in your apps).

I'd definitely not recommend that.

Even if your server is stuck in the 20th century and only supports
Legacy IP, you may find that client devices are on IPv6-only networks
using NAT64. So a successful connection might be seen by the *server*
as running over Legacy IP, while the client believes it's using IPv6.

If I tether to my mobile phone over a USB cable, that's precisely the
connectivity mode I get.

So especially don't limit *clients* to Legacy IP, if they're mobile
applications or even devices.

I have devices in my collection which Just Work over NAT64 despite the
actual creators of those devices having no idea that they're living in
the 21st century. They didn't think about IPv6 at all, but the
underlying OS and libraries all just do the right thing, and
connectivity to their Legacy-IP-only service just works anyway.

Don't go out of your way to *break* that.

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2022-11-24