IPv6 Support

[matthiasklein]

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?

[icraggs]

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?

[matthiasklein]

I have created an issue for the SSL hostname: #1402

[icraggs]

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.

[matthiasklein]

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.

[jumoog]

maybe its time for c-ares

[cwardcode]

Hi @jumoog, @icraggs - Just wanted to follow up and see if IPv6 support has gained any traction? I'm experiencing issues connecting to an IPv6-only broker as well, just as Matthias has described above.

[icraggs]

@jumoog I thought c-ares was for DNS, and wouldn't help here?

@cwardcode I'm tempted to investigate the "happy eyballs" approach and if I can not make it complicated ... it would have to apply only the TCP connect, not the MQTT connect as well though I think

[jumoog]

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.

I can't remember why I wrote this, but after some research c-areas wouldn't help. All we need to do is set the AI_ADDRCONFIG flag when using getaddrinfo . It works for Linux and Windows (Vista and newer).

[cwardcode]

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.

I can't remember why I wrote this, but after some research c-areas wouldn't help. All we need to do is set the AI_ADDRCONFIG flag when using getaddrinfo . It works for Linux and Windows (Vista and newer).

I was able to build a local copy of paho.mqtt.c using this flag and everything started working as intended. I've created #1578 to address this issue and welcome any feedback!

[icraggs]

I presume setting AI_ADDRCONFIG will not fix every case? I guess the easiest way is to release it and see how many people still need the extra functionality of "happy eyeballs".

[cwardcode]

The "happy eyeballs" approach may be useful in certain situations for failback purposes, so i do believe that approach in the future may be warranted to make the client as resilient as possible. However, at the moment, without AI_ADDRCONFIG, the client will not allow any connections for the case where a device is not configured with an IPv4 address, so I do feel like this is a correct step forward towards full IPv6 support.