I am not sure what is meant with this issue as #133 is already fixed with the connecting to random host.

RFC 6555 is not about connecting to random host.

2015-06-10 10:23 GMT+01:00 Mikaela Suomalainen [email protected]:

I am not sure what is meant with this issue as #133
#133 is already fixed with the
connecting to random host.

—
Reply to this email directly or view it on GitHub
#241 (comment).

So this issue is between client and ZNC, not ZNC and server?

RFC 6555 says to connect via IPv4 and IPv6 at the same time, and use the
connection which happened faster.

For ZNC→server side, #133 is fixed by connecting to random host, which is
not the same.
For client→ZNC side, it's client's job to define how client connects to
ZNC. However, due to #593, web browsers can have problems accessing ZNC.

This issue is about ZNC→server.

2015-06-10 12:09 GMT+01:00 Mikaela Suomalainen [email protected]:

So this issue is between client and ZNC, not ZNC and server?

—
Reply to this email directly or view it on GitHub
#241 (comment).

I see.

I was sure I had read somewhere that Happy Eyeballs is supposed to be biased towards IPv6 and now I finally accidentally found the source!

• https://www.ietf.org/mail-archive/web/v6ops/current/msg22455.html - [v6ops] Apple and IPv6 - Happy Eyeballs

While our previous implementation from four years ago was designed to select the connection with lowest latency no matter what, we agree that the Internet has changed since then and reports indicate that biasing towards IPv6 is now beneficial for our customers: IPv6 is now mainstream instead of being an exception, there are less broken IPv6 tunnels, IPv4 carrier-grade NATs are increasing in numbers, and throughput may even be better on average over IPv6.

Fixed formatting on 2015-09-20 & added title for the link.

This would be important as ZNC is still choosing IPv6 which doesn't always work for one reason or another and the solution is always /msg *status setuserbindhost 0.0.0.0. With Happy Eyeballs in case of failure v4 would be used transparently without it being enforced for all connections and at some point it would just work.

The most recent case where I saw this was the day before yesterday and then the user had misconfigured ip6tables or something and I meant to comment at that time, but IRL prevented it.

the solution is always /msg *status setuserbindhost 0.0.0.0

No, it's not.
Just wait several more connection attempts, it will eventually choose IPv4,
if both server host and bind host don't resolve to IPv6-only.

2015-11-19 9:23 GMT+00:00 Mikaela Suomalainen [email protected]:

This would be important as ZNC is still choosing IPv6 which doesn't always
work for one reason or another and the solution is always /msg *status
setuserbindhost 0.0.0.0. With Happy Eyeballs in case of failure v4 would
be used transparently without it being enforced for all connections and at
some point it would just work.

The most recent case where I saw this was the day before yesterday and
then the user had misconfigured ip6tables or something and I meant to
comment at that time, but IRL prevented it.

—
Reply to this email directly or view it on GitHub
#241 (comment).

I was having an issue where znc would fail connecting to mibbit irc 2/3 times. Per mikaelas advice I set the bind host to 0.0.0.0 and now I have 4/4 successful connects so far. Thank you!