Our software supports IPv6 from day one, but our infra provider for satellites - doesn’t. Our edge services are fully IPv6 enabled, but most of the customers uses IPv4 anyway.
So, even if your node would be available for both, it likely be used via IPv6 only by edge services (for S3-compatible protocol), not directly from the customers.
So at the moment you need to have a dual stack anyway.
1 Like
But it would be good and even needed to have opportunity for adding additional connection option, that node can make both ipv4 and ipv6. at one point it will be critical to have it and then storj will be redy for it, this function is not a one day work.
You can do it already: you need to have a DDNS hostname, which supports both protocols and use it instead of IP in your node’s configuration, configure a firewall on your PC to allow connections through IPv6 and configure IPv6 on your router to pass it thru to your PC, your PC also need to be configured to have IPv6 as well.
4 Likes
then it can use both at same time?
Yes. If the client get an IPv6 of your node and contact it - it will use IPv6, otherwise IPv4 only.
A little more complicated on a docker container but have IPv6 working on the containers now with Linux doing a little routing. As I have two containers on the one host I have had to set up two DNS records for the two seperate IPv6 addresses. Learnt more about Ipv6 subnetting than is healthy.
1 Like
I had now several discussions on this forum about ipv6.
And now I say I am done. I had to close my node because i lost my public ipv4. Now i will close my Storj storage because for me as ipv6 only network operator it is no viable option for storing data if there is only partial ipv6 support.
The idea of decentralized storage is nice. I like it. But the complaint of lacking ipv6 is now so old that i see no future for this Project.
Now a fact: The centralized internet cannot grow with ipv6 not even speaking of a decentralized one with actual peer to peer communication.
Imagine of a growing number of nodes left behind nodes with high-speed broadband internet connection, because one day to another all the small node operator get DSlite/CG-NAT and have their node suspended Because they didn’t recognize that in time. (Which happened to me).
If you won’t address those, let’s call them by name, critical issue for a decentralized storage network, i won’t come back. My node will be the present half of the internet, the v6 internet.
And for years we get the same responses:
- There will be less traffic…
- Our satellites don’t support it
- Companys don’t use it…
I don’t want to play IPv6-Bullshit-Bingo anymore IPv6 Excuse Bingo (ipv6bingo.com)
If your cloud provider can’t provide you the features many want, maybe it is not a viable cloud provider.
My I tell you that Facebook and Microsoft both run IPv6 only networks, that those companies with their centralized networks realised early on that growth is not possible with legacy IP.
Also, Storj is one of the few CDNs which cannot provide popper IPv6 because the content is only delivered via IPv4 only nodes as this is the most used install method.
- Akamai: Excellent IPv6 support
- Amazon Cloudfront: IPv6 support
- Azure CDN: IPv6 enabled by default
- Cloudflare: IPv6 by default
- Fastly: IPv6
- Storj: In theory, but in practice not. I cannot operate a node without public v4 because it cannot be observed by a satellite via v6. And the node cannot contact the satellite if it is IPv6 native without transition technology between it.
Even your website and forum are v4 only. that is not good for your loading times…
We see us again, either as Node Operator, as Storj customer or both, when Storj fully supports the Internet Protocol of the Present and not only embracing the legacy internet protocol. Until then I am neither supplier nor consumer for you anymore.
I know that this comment sounds harsh in some passages, but I hope you see the frustration of me as user. You can also see from my profile that I already asked for this in October 21. I had to discuss with IPv4 advocates that don’t know how to design networks and searching for a workaround to the IPv4 depletion because they didn’t want to accept that IPv6 is the solution and NAT as well as multi-layer NAT is the true devil of networking.
To all of you, I wish you a lovely day.
3 Likes
I can definitely agree that the situation is frustrating. It’s also frustrating for a lot of us who are engineers on the project. We designed the system from the beginning to support IPv6; there wouldn’t be any need to rewrite software to enable it. Some satellites have had IPv6 endpoints already.
I expect you’ve already heard this before, but for the sake of someone else reading the thread: the main thing stopping us from moving to another cloud provider and enabling IPv6 everywhere is that we would need to make it a requirement for all nodes. All nodes would need to handle both IPv6 and IPv4 requests, because the nodes are part of the server side of the service, not the client side. The client side can have the benefit of choice- whichever protocol works better for their own setup. But the server side has to support both. Look through your list of providers: Akamai, Cloudfront, Azure, Cloudflare, Fastly. All of them support both IPv6 and IPv4 on the server side, because they would lose over half of their traffic and revenues if they went IPv6-only. No one expects them to go IPv6-only at this point.
Now imagine that a third of Storj nodes supported only IPv4, one-third supported only IPv6, and the other third supported both. A Storj client using IPv6 comes along and asks for an object. It gets a list of pieces and the addresses where they can be fetched, but it can only retrieve 2/3 of them. Is that enough? It would be sometimes, but not all the time. We’d have to retune the redundancy parameters in order to guarantee that 2/3 of online pieces is good enough 99.999% of the time–and more redundancy would mean lower payouts for node operators. A Storj client using IPv4 would have the same problem. To make it worse, we likely wouldn’t end up with a nice balance between IPv6-enabled and IPv4-enabled nodes, so we’d have to support some fraction smaller than 2/3, for whichever side ends up smaller.
But! Say we did that work, and required all nodes to support both protocols. Is everyone happier? No, because most of the people who want to ditch IPv4 are node operators, not users of the Storj service. We’ve ended up making things strictly harder for node operators.
We are in full agreement that this is an unfortunate and frustrating situation. If our failure to support v6 has driven you away, I’m sad to see you go but I can respect the decision.
10 Likes
Thanks for your report @MaZe very lucid and clear
I keep saying that many of justifications given to not have full IPv6 support could perhaps already been done or at least something being tried if there was will for that.
To start with the justification given that satellites could not support IPv6 because something in Google Cloud that didn’t have support so far. Well, simply move away from it ! What stops it ? Why is that so difficult or impossible ?
Glad that you mentioned the important point that a decentralized system with peer to peer communication cannot grow sustainably without IPv6. Those who believe in 2023 you must still have a Public IPv4 in order to operate a node in my view are simply resisting while possible in order to not have to give more thought and work to a definitive solution that involves IPv6 which IS the default Internet Protocol.
I have been saying that it is growing faster than many think, the number of broadband connections without a Public IPv4 (therefore with CGNAT), but still with native IPv6 available, but still many still think IPv6 is minor or something cosmetic that can be left for later. It is cannot for quiet a while.
Well pointed that as Storj´s main website and forum are not IPv6 hosted sends a clear and negative message about the commitment about it. Such small things matters to send a message when you are really fully committed.
To finish with I want to also comment @thepaul comment about that the main thing the stops from moving to another cloud provider and enable IPv6 everything is that would be a requirement for all nodes.
I respectfully disagree strongly on this. This should not and cannot be a requirement. As mentioned when there is will to find a solution there are multiple possibilities and alternatives that I am not entirely sure have even been properly evaluated and tested. Just to mentioned some:
- with regards IPv6-only nodes this can be taken into account dynamically in order to calculate the necessary number for redundancy proposes and always be adjusted as more and more clients have IPv6 support.
- consider also that if it can be forced that gateways that can fully communicate to nodes in full IPv6 are responsible for a fair a mount of traffic you can cover and guarantee a pretty good usage from IPv6-only nodes
- for those cases of nodes hosted behind a CGNAT+IPv6 connections, if something may still be necessary to communicate via IPv4 there are certain techniques that can be explored like rendezvous servers and/or NAT punch hole that many applications are taking advantage now a days.
Although there may still not exist a definitive solution and nobody can be sure what is the best solution it has to start somewhere and has to be will to make it happen someway, experiment, find the right and balanced numbers between Nodes and Users using IPv4-only, Dual-Stack or IPv6-only and dynamically adjust the necessary data redundancy numbers to always have the network healthy and with great performance.
Consider that if you don’t have any more obstacles for IPv6 nodes there will be even more storage offer that can be used for increased redundancy proposes. Consider also that those still with IPv4-only node would be left behind and less rewarded when compared to those running Dual-stack nodes.
You missed the main point:
In more simple words - when the customer requests list of the nodes, it will get IPs. If the customer wouldn’t be able to connect to IPv6 addresses, it now would request another batch of nodes, to have enough pieces stored.
The same when they want to download, but now only from 80 nodes who stores their pieces of data. If more than 51 nodes would not be accessible for them - they cannot retrieve an object.
In best case it will slow down the transfer because of retries, in worst - it will fail. And what’s worse - it will look like a data loss, even if not!
And the audit worker will not see a problem, since it can audit the node on any of both protocols…
This is why all nodes must support both or only one protocols, not the mix, otherwise the customer will have an access only to the part of the network.
And this, to say it in extreme words, makes Storj as a project failing. Because we now have the problem that storj wanted to do better than every other cloud storage provider. “A decentralized cloud storage by everyone for everyone”(by interpretation of the project so far) evolved to “a shrinking elite within the IPv4 world storing data for people with IPv4 internet access”.
Posts requesting IPv6 are now nearly 4 years old. like this one IPv6 does not work?
In my opinion, it could be done, but you would have to do something along the lines of what we did with v2 when nodes couldn’t get a static IP. They would chain to a node that could, and run traffic through that node as a proxy. You could do the same here. An IPv4 node that couldn’t talk to an IPv6 network (Or vice versa) could proxy through a node that speaks to both. This is a back-of-a-napkin idea and it would take more thought and development time, but it could be done this way. Like I mentioned, we did something similar previously with v2.
Edit: Remembering now that it wasn’t the static IP that was the reason for the proxy, but rather nodes that couldn’t open their ports to the outside. They would proxy their traffic through another node to get around this problem. Either way, using another node as a proxy would be one solution to the problem.
1 Like
What is the plan then? Keep it ipv4 only untill there are more ipv6 only clients, and then switch to v6 only network?
According to Test your IPv6.
there are currently ~ 45% ipv4 only clients but only 0.4% ipv6 only, the rest are dual stack.
Well, remember that Storj is a small company with limited resources. If our sales departments were talking to customers that required IPv6, I am sure there would be significant interest to get a solution in place faster than what it is now. Unfortunately for node operators behind IPv6, there isn’t currently demand for IPv6 from our customers. Instead, they have requested other features/integrations and so our limited developer resources are working towards giving them that.
So, when there are free resources to work on an IPv6 solution, as mentioned above by thepaul, it is not going to be something simple and would require a significant amount of resources. And again, this is work that is not going to bring us any immediate income like other work that is currently being focused on.
Node operators behind IPv6 only networks can utilize a VPN solution to stay within a IPv4 network until such time that Storj has an IPv6 solution, as one option if they want to continue as a SNO. Probably could also use a VPS as another option.
In the long run, we’ll have a solution before too long. We’re not in business to ignore half the Internet. But for the time being, resources are allocated where we can derive more immediate income. Long term, we’ll have a solution to bring in future income from IPv6 networks.
6 Likes
Q: How valid are the stats?
They do not represent the average web consumer. Visitors to this site are self-selecting. The intent of this site is to not provide stats, but instead to inform the user the level of readiness for the world to move to IPv6 (with or without’em!). As such, stats found here will be completely different from an average content provider.
Source - Test your IPv6.
Sure, those who know ipv6 and want to test it may be more likely to visit this site. The statistics from google look very similar and go even more in the direction of ipv4 and that should correspond more to the “average web cumstomer”.
So are you telling me that you think it looks very different?
Yes, very different. All the ipv6 websites mention ‘adoption’, i.e. the mere possibility ipv6 traffic would even work. This is far removed from how much ipv6 is actually used and how widely it’s used, without even trying to compare it to the amount of ipv4 traffic/usage.
The most recent figures I could find from a large institution is this:
On the Internet exchanges, the observed percentages of IPv6 to total traffic are even lower. For June 2022 AMS-IX observes an average of 4.1%.
Source - IPv6 10 Years Out: An Analysis in Users, Tables, and Traffic | RIPE Labs
The big clients use ipv4 or dual stack. Only some home users have only ipv6. Why stressing about it right now?
To serve ipv4 clients you need IPv4 nodes. It’s increasingly harder to get a public IPv4 address so hosting IPv4 nodes is also getting increasingly harder. That’s the gist of it.
1 Like
@Alexey when the customer requests list of nodes does it get list of IPs or FQDNs ? Instead of IPs if he can get a list of FQDNs it will be up to the customers to choose what protocol to communicate (considering the node has both). If the node has IPv6-only and customer IPv4-only then there could be a mechanism to identify that and not even send that address in the list to the customer.