RFC 6555 - Happy Eyeballs #156

New Issue

2026-10-05T04:01:37+02:00

adam commented

2026-10-05 04:01:37 +02:00

It would be nice to have it implemented, e.g. for case when bindhost is not set.

http://tools.ietf.org/html/rfc6555

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1308-rfc-6555-happy-eyeballs?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).

It would be nice to have it implemented, e.g. for case when bindhost is not set. http://tools.ietf.org/html/rfc6555 ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1308-rfc-6555-happy-eyeballs?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam commented

2026-10-05 04:01:38 +02:00

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

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

adam commented

2026-10-05 04:01:39 +02:00

RFC 6555 is not about connecting to random host.

2015-06-10 10:23 GMT+01:00 Mikaela Suomalainen notifications@github.com:

I am not sure what is meant with this issue as #133
https://github.com/znc/znc/issues/133 is already fixed with the
connecting to random host.

—
Reply to this email directly or view it on GitHub
https://github.com/znc/znc/issues/241#issuecomment-110667828.

RFC 6555 is not about connecting to random host. 2015-06-10 10:23 GMT+01:00 Mikaela Suomalainen notifications@github.com: > I am not sure what is meant with this issue as #133 > https://github.com/znc/znc/issues/133 is already fixed with the > connecting to random host. > > — > Reply to this email directly or view it on GitHub > https://github.com/znc/znc/issues/241#issuecomment-110667828.

adam commented

2026-10-05 04:01:40 +02:00

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

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

adam commented

2026-10-05 04:01:40 +02:00

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 notifications@github.com:

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

—
Reply to this email directly or view it on GitHub
https://github.com/znc/znc/issues/241#issuecomment-110701693.

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 notifications@github.com: > So this issue is between client and ZNC, not ZNC and server? > > — > Reply to this email directly or view it on GitHub > https://github.com/znc/znc/issues/241#issuecomment-110701693.

adam commented

2026-10-05 04:01:41 +02:00

I see.

I see.

adam commented

2026-10-05 04:01:42 +02:00

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.

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._

adam commented

2026-10-05 04:01:42 +02:00

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.

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.

adam commented

2026-10-05 04:01:43 +02:00

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 notifications@github.com:

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
https://github.com/znc/znc/issues/241#issuecomment-157998441.

> 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 notifications@github.com: > 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 > https://github.com/znc/znc/issues/241#issuecomment-157998441.

adam commented

2026-10-05 04:01:44 +02:00

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!

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!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#156