IPv6 Support
Opened this issue · 5 comments
We have a local MQTT broker which is only accessible via IPv6 link local, where the name resolution happens via mDNS/Avavi.
I debugged into the Socket_new() function and found that getaddrinfo() returns both an IPv4 and an IPv6 entry.
The "prefer ip4 addresses" section ensures that only IPv4 is tried, which fails completely. No connection possible.
Basically the same I see on an IPv6-only host, which also gets an IPv4 address during name resolution. The "prefer ip4 addresses" section again ensures that no connection is possible.
Other tools like mosquitto_pub or libcurl work fine in these environments.
From libcurl I know that it uses a "happy eyeballs" implementation: https://en.wikipedia.org/wiki/Happy_Eyeballs I.e. parallel connects with IPv4 and IPv6 ...
I think the manual preselection of IPv6 via a callback is not useful, because the client does not know when to preselect IPv6. In my opinion we should try to realize a "happy eyeballs" implementation. Or at least try all getaddrinfo() entries one after the other. Then at least a connection would be established at some point.
Assuming you would do the name resolution outside of the Paho library, and only pass an IP. Is it possible to pass an additional host name for the SSL check?
When is the release of version 1.4.0 with the IPv6 prefix callback planned?
The application would know at least as well as the library whether to prioritize IPv4 or IPv6, no? "Not useful" means the client library does it rather than the application. Multiple simultaneous connections feels like a lot of work, relatively. I'll think about it. I don't have a particular date for the 1.4 release but obviously adding more items will extend the schedule. Having said that, this implementation wouldn't change externals so could be added to 1.3.x. I could then remove the IPV4/IPV5 callback implementation.
Adding an additional (any number?) of hostnames for the SSL hostname check - another issue for that?
I have created an issue for the SSL hostname: #1402
I checked the happy eyeballs method and that doesn't look like a good option to me. The winner of the connection is the one that connects first - which is entirely random. In the case of MQTT, the TCP connection could work but maybe the broker is only accepting MQTT connections on one version, so we would have to issue MQTT connects and see if those work. In parallel that would be quite complicated and open to surprising behaviour.
I think the current method in version 1.4, with the callback, is a good option.
Also, I did some checking on libmosquitto, and I found this description: https://forum.cedalo.com/t/support-for-ipv6-to-ipv4-fallback/580/2. Going with the first one in the list by default, but allowing this to be overridden by the callback seems like a good way forward to me.
I understand your concerns.
What do you think about giving preference to IPv6 as described in RFC3484?
My original problem (#1030) is that I am faced with modern environments where the name resolution returns an IPv4 and IPv6 address, but the network interface is configured for IPv6 only. In that case the PAHO library always fails, but libmosquitto works fine.