IPv6 support for Temporal

Community Support
1

Hi team looks like Temporal by default does not support IPv6. Is there any guidelines for the same?

2

Hi which server version are you running? I think this was enabled some time back, see here

3

We are on version 1.18.1

4

I see, think 1.18.1 was released before this change: Release v1.18.1 · temporalio/temporal · GitHub

5

Yeah looks like it. So the code was merged around Oct 26th, 2022. I have been looking at releases after that but don’t see the IPv6 comment in any. Looked Release v1.18.3 · temporalio/temporal · GitHub onwards. I am assuming there would be a comment on the release ?

6

Also found this open issue from Nov 19 2022 which seem to say it is not supported
[temporalio/auto-setup] bindOnIP does not work with ipv6 · Issue #3629 · temporalio/temporal · GitHub @tihomir

7

Besides also found this https://github.com/temporalio/temporal/pull/1472 but the above issue is still open on this one. Also am not sure why don’t I see the commits in release am I missing something?

8

Actually found the previous commit I mentioned in Release v1.9.0 · temporalio/temporal · GitHub

9

Based on my understanding the v1.9.0 had the support added [not sure about the SQL part as mentioned in the pull request]. And the later one is fixing the entry point issue. Fix entrypoint when running in IPv6 by PenguinToast · Pull Request #68 · temporalio/docker-builds · GitHub . I suppose even if I don’t upgrade the server and just add the bind IP change it should make it Ipv6 compatible. However, will further look on what release is the last commit part of. i think that is just on the docker build. @tihomir thoughts?

10

Hi @Anshumali_Prasad - I’m actively looking into ipv6 support and I’ll update here with what I find.

Any information you’re able to provide on the environment temporal is running in and the deployment method would be helpful.

11

to update this thread - temporal does fully support ipv6 provided config specifies ipv6 addresses. this can be challenging right now in dual stack environments if your active cluster rpc address / public client address is a domain name that serves both A and AAAA records as as the default dns resolution in golang favors ipv4 addresses.

suggested ways to try to work around this:

  • specify a well known ipv6 as the cluster rpc / public client addresses
  • if well known ipv6 isn’t an option, specify only AAAA in cluster DNS entries
  • to support dual stack clients, create a second DNS entry to serve A and AAAA for clients and one that only serves AAAA for the cluster rpc address / public client address for server config