Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add IPv6 connectivity to Signal server #2709

Closed
freswa opened this issue Sep 1, 2018 · 14 comments
Closed

Add IPv6 connectivity to Signal server #2709

freswa opened this issue Sep 1, 2018 · 14 comments

Comments

@freswa
Copy link

freswa commented Sep 1, 2018

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
Copy link

ogelpre commented Oct 18, 2018

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

@motp
Copy link

motp commented May 20, 2019

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
Copy link

ogelpre commented May 21, 2019

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

@mdavids
Copy link

mdavids commented Dec 13, 2019

#2327 (comment)

@iLennart21
Copy link

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
Copy link

treysis commented Mar 16, 2021

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

@hslabbert
Copy link

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

So, there may be hope?

@treysis
Copy link

treysis commented Sep 22, 2021

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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

@Mynacol
Copy link

Mynacol commented Sep 26, 2022

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
Copy link

Mynacol commented Sep 26, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests