Add IPv6 connectivity to Signal server

[freswa]

As described in #2327 the servers reachable with the fqdn textsecure-service.whispersystems.org only have A records so they are not available from IPv6 only networks.
As #2327 got closed I'd like to fill this as a request for enhancement to make these server available via IPv6.
Thanks

[ogelpre]

It is even worse: Signal Desktop does not work in ipv6only environments with NAT64. This has to be fixed.

[motp]

I am just attending the RIPE78 meeting and could test in an IPv6-only environment with NAT64:
The bug is still present in the current Version v1.24.1of signal-desktop, if no local CLAT is running.
With CLAT, signal works like expected.

A tcpdump reveals connections to 34.196.194.172, which was the first match to textsecure-service.whispersystems.org at that time, on the clat interface.

This is what probably happens: Although the Sourcecode only mentions textsecure-service.whispersystems.org, the actual socket is opened to the first IPv4 Address of
this DNS RR.

This means:
a) You are only trying to open an IPv4-only Socket and the syntethic DNS64 answer is ignored (bad)
b) You are trying to connect to a literal IPv4 Address (very bad)

Please fix this. It breaks anything else than IPv4-only networking.

[ogelpre]

I am attending the RIPE78 meeting, too. Same issue here.

[mdavids]

#2327 (comment)

[iLennart21]

Just to warm this Feature Request up: Here in Germany (and probably some other countries) some major ISPs only provide DS-Lite (Native v6, tunneled+nated v4) connectivity to their customers. This means all IPv4 traffic has to be relayed through a Gateway which adds some Latency. Usually the impact isn't too big but Google's statistics show that often v6 connections benefit from lower latency. Both Googles and Facebook's stats show worldwide v6 adoption is at roughly 30%. In some Countries it is as high as 60%.

It looks like the textsecure-service endpoint is hosted on AWS EC2. Even though v6 configuration requires some effort it should be possible by now to run a v6 capable service including load balancing.

[treysis]

Yes, please enable IPv6 on the textsecure endpoint and also add AAAA records to the DNS, please!

[hslabbert]

It looks like the nodejs issue that @mdavids referred to above is closed. The trail there is:

• original nodejs issue for arbitrary reordering of DNS results, preferring IPv4: order of getaddrinfo results not respected nodejs/node#6307
• nodejs issue re: Happy Eyeballs implementation: Happy Eyeballs node-fetch/node-fetch#1297
• nodejs commit to remove explicit DNS result reordering and honour resolver ordering: nodejs/node@1b2749e

So, there may be hope?

[treysis]

Yes, there MAY be hope. Looks like the commit is already part of NodeJS v16.10, released yesterday. As soon as Electron/Signal updates to this release, it should put IPv6 first, as long as devs of Electron/Signal don't override the new default setting.

However, it looks like Signal Desktop is still on NodeJS v14.x, so this will probably take some time.

[zwhitchcox]

Just saw this issue linked on the issue I made.

Correct ordering of of IP addresses is good, but there are situations where networks can hand out IPv6 addresses, even when IPv6 connectivity support is dropped.

The solution is happy eyeballs.

I've implemented the algorithm for my company in a node-compatible way. It is open source, so if anyone wants to take it and adapt it for their needs, please feel free:

https://github.com/balena-io-modules/fetch

[hslabbert]

This is a bug. Signal desktop uses a version of a dependency (nodejs) that had implemented incorrect behaviour that resulted in broken connectivity on the current Internet Protocol. That bug has been addressed in the dependency, but Signal is still currently using the broken version of the dependency.

This can be fixed by moving to the fixed version of the nodejs dependency, without needing to implement any new features in Signal Desktop or in adding any new infrastructure or service network configuration.

If this problem is added into a new issue filed as a bug report following repo issue templates, would it then be considered a proper bug to be addressed?

[maurice-w]

This issue originally was about adding IPv6 connectivity to the servers so that clients could connect even without DNS64 / NAT64. It seems legit to consider this a feature request (an important one nonetheless).

#4121 is about the nodejs issue. It's labeled as a bug and is still open.

[hslabbert]

Gotcha, thanks. I wasn't aware of the status of . #4121. I'll sub there, thx.

[Mynacol]

The long-term solution is to deploy IPv6 connectivity for all signal services.

• This anecdotally helps with connectivity both in IPv6-only networks and in networks with CGNAT, but insufficient NAT gateways. These issues only get bigger over time, and it's easier to start early.

• People which don't use Google's Firebase Cloud Messaging for push messages would profit by reducing the amount of pings required to hold an open and working connection to Signal's servers, conserving battery.

• For registering with a telephone number you would have a better picture regarding misuse. With IPv4 and CGNAT, hundreds of people can connect behind one public IPv4. Either your policy is lenient, which might allow for malicious mass-registers, or too strict, blocking legitimate users.
  With IPv6 only a moderate number of people will be reachable behind a /64 subnet, as every household gets at least one /64.

• And I believe you can save costs (especially on AWS) by reducing NAT traffic fees.

To avoid issues (with wrongly configured networks etc.) you should implement Happy Eyeballs on every client if possible.

IPv6 support for public-facing servers:

Domain	AAAA available?	Hoster
signal.org	✅	Cloudfront (AWS)
www.signal.org	❌	Cloudfront (AWS)
chat.signal.org	❌	AWS
ud-chat.signal.org	❌	AWS
textsecure-service.whispersystems.org	➡	See chat.signal.org
storage.signal.org	✅	Google
cdn.signal.org	✅	Cloudfront (AWS)
cdn2.signal.org	✅	Cloudflare
api.directory.signal.org	❌	Azure
cdsi.signal.org	❌	AWS
contentproxy.signal.org	❌	AWS
uptime.signal.org	❔	(resolves to 127.0.0.1)
api.backup.signal.org	❌	AWS
sfu.voip.signal.org	✅	AWS
turn2.voip.signal.org	✅	AWS
turn3.voip.signal.org	❌	Google
updates.signal.org	✅	Cloudflare
updates2.signal.org	✅	Cloudflare
signalcaptchas.org	❌	AWS

[Mynacol]

And some public staging servers:

Domain	AAAA available?	Hoster
chat.staging.signal.org	❌	AWS
storage-staging.signal.org	✅	Google
cdsi.staging.signal.org	❌	AWS
cdn-staging.signal.org	✅	Cloudfront (AWS)
cdn2-staging.signal.org	✅	Cloudflare
api-staging.directory.signal.org	❌	AWS
api-staging.backup.signal.org	❌	AWS
sfu.staging.voip.signal.org	✅	AWS

Maybe you can start with them to catch problems early.