IPv6 node no longer working

So, I configure an IPv6 node and previously would just fine. The was practically no data stored but it was always online. After recent updates it simply refused to get back te the online state.

tempts": 8, “error”: “ping satellite error: rpccompat: dial tcp 78.94.240.189:7777: connect: connection refused”, “errorVerbose”: “ping satellite error: rpccompat: dial tcp 78.94.240.189:7777: connect: connection refused\n\tstorj.io/common/rpc.Dialer.dialTransport:211\n\tstorj.io/common/rpc.Dialer.dial:188\n\tstorj.io/common/rpc.Dialer.DialNodeURL:148\n\tstorj.io/storj/storagenode/contact.(*Service).pingSatelliteOnce:124\n\tstorj.io/storj/storagenode/contact.(*Service).pingSatellite:95\n\tstorj.io/storj/storagenode/contact.(*Chore).updateCycles.func1:87\n\tstorj.io/common/sync2.(*Cycle).Run:152\n\tstorj.io/common/sync2.(*Cycle).Start.func1:71\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57”}
2020-10-09T12:06:20.619930620Z 2020-10-09T12:06:20.619Z ERROR contact:service ping satellite failed {“Satellite ID”: “118UWpMCHzs6CvSgWd9BfFVjw5K9pZbJjkfZJexMtSkmKxvvAW”, “attempts”: 9, “error”: “ping satellite error: rpccompat: dial tcp 78.94.240.189:7777: connect: connection refused”, “errorVerbose”: “ping satellite error: rpccompat: dial tcp 78.94.240.189:7777: connect: connection refused\n\tstorj.io/common/rpc.Dialer.dialTransport:211\n\tstorj.io/common/rpc.Dialer.dial:188\n\tstorj.io/common/rpc.Dialer.DialNodeURL:148\n\tstorj.io/storj/storagenode/contact.(*Service).pingSatelliteOnce:124\n\tstorj.io/storj/storagenode/contact.(*Service).pingSatellite:95\n\tstorj.io/storj/storagenode/contact.(*Chore).updateCycles.func1:87\n\tstorj.io/common/sync2.(*Cycle).Run:152\n\tstorj.io/common/sync2.(*Cycle).Start.func1:71\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57”}

I would not have expected an IPv6 node to rely on IPv4 satellites but this is what appears to be happening.

Any ideas?

1 Like

The stefanbenten satellite used to be the only satellite to support IPv6, that has since been shut down. At this point you can only get data over IPv4.

The storagenode still can get traffic via IPv6, if the client use a dual-stack connection, since data transfer is performed between client and storagenode directly.
But the storagenode should have a dual-stack too to communicate with remained satellites

It does not need to.
At some point IPv6 needs to take over as we run out of IPv4 addresses.

Also the DDNS address has to advertise both IPv4 and IPv6, which most providers do not.

Thx, guess I’ll need to allocate some time to figure out why my IPv6 node suddenly stopped working. I kinda did not expect an IPv6 node to refer to IPv4 satellites. I can’t come up with any valid reasons for such a design. Can you guys share any insight on this?

I don’t quite understand your question.
My satellite was indeed the only Satellite at this stage being capable of speaking IPv6.

As this satellite is shutdown now, you are correct in assumption, that your node is unlikely to be able to participate in the network currently. The biggest problem here are audit and uptime checks failing for the IPv4 only satellites.

I already brought this issue up
Internally months ago and reiterated on it Friday to find a way forward.

1 Like

I did not realize that your node was the only one speaking IPv6 currently.
Sorry for the noise and thanks again.

So there is still no fix? The network is only working on ipv4? With my ISP I only have an IPv6 address. So my node only doese repsonse to ipv6 communication. Will there be ipv6 support in the near future? In the very near future? I mean we have 2021. Cant’t belive that this whole network is based on ipv4 and does not support ipv6…

It’s support IPv6. But Google Cloud is not. Yes, Google. Yes 2021. But no IPv6 either. Most of our satellites are hosted in Google Cloud.
The second problem - there are not a lot of customers uses only IPv6 (all data transfers are happens between customer and nodes).
So you need to have a dual stack (IPv4 and IPv6) still.

Ok wow. Sry did not know that this problem is based on google…
The Problem ist that my ISP does not give me a dedicated IPv4 address. I have to share it with others in a pool and my ipv4 connection is tunneld through my ipv6. So in this case it is not possible to track me from outside (internet) through my given ipv4 address. Soooo am I right that in this case it is not possible for me to participate in this network?

Actually it can, if you use the DDNS hostname. But it depends on how is IPv4 tunneling configured.
So, try to check your port on https://www.yougetsignal.com/tools/open-ports/, if it’s open (the storagenode should be running), you can try to configure a DDNS hostname and use it instead of IP in node’s configuration.

Also, you can try to forward IPv4 traffic to your IPv6 PC/Mac, if you have a device with IPv4 and IPv6:

If you are referring to a CGNAT then DDNS wouldn’t be enough. If this is the case, try calling your ISP and asking for a public IP. Tell them that static isn’t necessary (that’s usually reserved for business connections and would cost you money). If they ask what you need it for, tell them it’s for an IP camera so you can avoid having to explain Storj to them.

Most ISPs will help you out. Honestly, I’ve only read success stories on this forum when people have tried.

Ok thanks for the replys! I have DS-Lite configured.


Dual-Stack Lite (DS-Lite) is a technology that allows applications that use the Internet Protocol v4 (IPv4) to access the internet via Internet Protocol v6 (IPv6). DS-Lite is used by internet providers that do not have sufficient public IPv4 addresses for their customers and therefore set up IPv6 internet connections with DS-Lite for them.

So there is no way to access any device in my home network from outside through ipv4. I just called my ISP and tried to convience them to give me an ipv4 address because of my “ip camera”. They are able to upgrade my contract and give me a seperate ipv4, but this will cost me 3€ per month… Actually I dont want to pay 3€ per month for an ipv4 address in 2021…
As I asked if there is any other solution for my problem, of course they replied with: VPN. And normally this would fix the problem with the ip camera, but not the problem with the storj network. I really hope that google cloud would fix it soon. Do you guys have any information about that issue? When will google configure ipv6 finally??

While I agree that it would be nice if Google Cloud adds support, it would still mean you will likely get less traffic than others. A VPN will work with Storj as well as long as you have one that supports port forwarding. May I ask which ISP this is? This is the first time I heard any of them mention additional charges, so just curious.

The cleanest way would still be to go for the charge or switch to an ISP who can provide a public IPv4. But otherwise VPN is an option too.

Its Vodafone…

Switching ISP is not an option for me… sadly.

Does OpenVPN will work with port forwarding and in combination with storj?

Vodafone Cable in Germany?

If so, I switched their cable modem to bridge mode and hooked up my own fritzbox behind it and made it support only ipv4. Works perfectly and I got a stable ipv4 adress.

Other than that you should call them and ask about an ipv4 for your ip-camera or work vpn. That might work.

If you have a control on other side (server), then you can make a port forwarding manually.
The portmap.io is offering such a functionality and makes port forwarding for you.

Ok I just solved it now with a public cloud server. I configured on the public cloud server ipv4 and ipv6. The docker container is running on the public cloud server and I shared my storage through nfs. I did not know that the docker client from storj is using that less cpu power, that it will actually run well on a publid cloud server so that idea came up very late…

Public Cloud server costs 3,60€ where i do get a static ipv4 while ISP would charge me 3€ for aan ipv4 address which will change every day… Vodafone…

You should know that NFS is not a supported protocol for network storage. Eventually this setup will corrupt your databases. The only supported network storage protocol is iSCSI. My suggestion would be to use the public cloud server as a network tunnel, and keep your node running on your local machine.

2 Likes