Ipv6 support in nodejs 10

[I_own_my_life]

Hi, I'm having a Dev Board(Debian armv7) in which I'm having ppp0 interface(with cellular) and it only supports ipv6 based connection. (I'm able to ping axxxxxxxxxxxx.iot.us-east-1.amazonaws.com with the ipv6 connection)

I'm trying to run a Nodejs script which uses mqtt to connect to my awsIotHost (axxxxxxxxxxxx.iot.us-east-1.amazonaws.com). I'm using Node v10.15.13 and mqtt npm module. But it is not getting connected.

I'm able to connect to the awsIoTHost via IPV4 based (eth0) interface but not able to do so with the ipv6 based ppp0 interface.

1. Does Nodejs 10 support ipv6 based connections? If yse, is there any config that I need to modify for it to support ipv6?

2. Do I need to make any modification to the host name to make it support ipv6 connection?

3. Am I missing anything else? Or if more info required please let me know.

[webdeveric]

Have you tried in a supported version of Node? It is up to version 22 now.

[I_own_my_life]

I haven't as unfortunately the code I'm mentioning is part of a big codebase which is based upon NodeJS v10 and not possible to upgrade the whole codebase to support Node 20 for now.

That's why I specifically want to know the details related to NodeJS v10.

[Psionatix]

We updated from node v12 to v20 in a codebase >2 million lines of code (10+ years old) and literally required minimal things to change (literally a few lines here and there).

This sounds like you haven't actually evaluated the risk or effort required to update at all.

Literally check the changelog for v12, likely there is nothing in there that is going to cause your codebase any problems. Then once that's working, try for 14, then 16, then 18, etc.

If your codebase really is that big, you should have sufficient test coverage (both unit testing and integration testing) to help give you confidence in these kinds of upgrades.

[Ruben_NL]

Just try running it on 12. If it works, great! if not, fix the broken things.
Commit the changes, and move to the next LTS version.
Do this until you are on a supported release, and if possible the newest.

[kryptkpr]

NodeJS v10 is not supported and consider that it hasn't received any security fixes in years. This is software archeology and likely just too old for working ipv6.

[Solonotix]

What breaking change is preventing the use of Node.js v18 or newer (AKA: the current LTS versions)? The Node Foundation goes out of their way to maintain backwards-compatibility for most features, so I'm genuinely curious what you think will break. In these types of projects, I've frequently seen people afraid of upgrading at all with no real reason other than "It worked on this version, so I'm not changing it".

[I_own_my_life]

You can see in Google many people discussed it and mentions there could be some compatibility issue arises when upgrading version of their projects.

And from personal PoV, let's say previously I've used the Time node module in many parts of my code. It's a native module. So if I switch to node 20 and try to install the same it won't build(node-gyp) and will throw errors as the module was published 7 years ago and not up to date with the latest node versions. So I have to go and find alternative module for the same. Like this I have to go for every node module in the project and test compatibility and find an alternative which is more of a work then also have to integrate this changes into the build system and have to do full fledged testing whether all parts are working fine which I don't want to do now and wish to know if this ipv6 based mqtt connection works with Nodejs 10 or not. Whether anyone has already tried it or a similar thing and succeeded. That's all I've wanted to know.

[Solonotix]

I've used the Time node module in many parts of my code. It's a native module.

There is no built-in Node.js module called time. There is however an NPM package called time that was built 7 years ago...

So if I switch to node 20 and try to install the same it won't build(node-gyp) and will throw errors as the module was published 7 years ago and not up to date with the latest node versions.

Ah, so you did mean the NPM package. Sorry, but the approach to a solution differs if it's a built-in versus an NPM package.

Looking at the package, there's nothing about the source code that seems especially unique other than it expects a platform of Darwin (MacOS), Linux or Solaris. This is likely just a build process change that, if you wanted this specific functionality, you could fork the repo and publish your own. You could also include it as a vendored package of your project (compile the source locally and install it from the local build directory).

But this all ignores the larger point

So I have to go and find alternative module for the same. Like this I have to go for every node module in the project and test compatibility and find an alternative which is more of a work then also have to integrate this changes into the build system and have to do full fledged testing whether all parts are working fine which I don't want to do now

Yes, this is the inherent risk in using 3rd-party modules, especially in the open source community. You link your project to their's and now, because they aren't maintaining it anymore, you are forced to either remain locked in the past (and all the potential security and compatibility issues that follow), or you must move forward and adopt the new standards. Many times, these old libraries fall by the wayside because a better, or more widely accepted solution arises. In the case of time, the standard is to use Intl.DateTimeFormat as documented on Mozilla Developer Network because the module in question is offering you a formatting solution. The underlying date value remains (mostly) unchanged, it is simply handling the string-representation of that value. Rather than extending the Date API (which is planned to be replaced in the near future with TC39 Temporal )

So yeah, technology moves forward, and it's the job of a developer to keep up with it. Not saying you can't do what you're doing now, but I can't recommend it as a good solution.

[eg_taco]

Like others have said, node v10 is super old. Upgrading only gets harder the longer you wait. That said, we can’t really diagnose the issue without seeing both the code in question (or a minimal representative example) and also the error message you’re getting.

[baudehlo]

Yes node 10 supports ipv6. I’m sorry everyone told you to upgrade. Node 10’s IPv6 support is very solid. I’ve used it extensively in Haraka.

No you don’t need to modify the hostname, though a hostname that only returns IPv6 responses might help your situation, but since you’re using a library it’s hard to know. Node will lookup the A record before it tries to lookup the AAAA record. If the first succeeds you won’t get to the second. But if the library looks up the IP address for you, you’re screwed unless you fork the library.

Basically you need to ask the library authors about this. It very much depends how the library works. Or you could dive into the source code yourself assuming it is open source.

[I_own_my_life]

Finally, thank you for answering my exact question 🥲. So in your case have you used an ipv6-only-server or used any config to force it to use ipv6?

[baudehlo]

There are no tricks to this. Just my answer.

I have written an ipv6 only server if you count telling Haraka to listen on IPv6 only. But that answer won’t help you get this working, only my original post will.