Hi, I noticed that Storj doesn’t have full IPv6 support yet and it seems to be lacking on Satellite and Gateways and was wondering why.
Have read some old posts in the forum and some people from Storj which mention that Google Cloud doesn’t support it but that is not true anymore for a while. Google completed the deployment of IPv6 on everything they lacked on its Cloud solutions. In fact it was not a total lack of IPv6, but on some products, but now it is not the case anymore.
Furthermore people with broadband connection with CGNAT + IPv6 connections can also start to contribute with their storage despite the fact that traffic flowing via IPv6 gets improved performance due to avoid having to pass on bottlenecked CGNAT equipment and better dealing with TCP Window.
So please add IPv6 where it lacks, specially on all gateways that don’t have and make it possible that storage nodes can communicate with Satellites in IPv6-only networks so they can also contribute with storage.
This problem has two parts - nodes and customers. Actually even three - also our satellites and Gateways.
To be able to run IPv6-only nodes and have any income, all three should use IPv6.
As you know, data is transferred directly between the customer and nodes if the client uses a native integration. If they uses an S3 integration, then data transferred between the customer and the Gateway and between the Gateway and nodes.
Most of the customers still uses IPv4, especially corporate ones (where you actually have most of the data). So it’s not enough to have only satellites with IPv6, you need customers who uses IPv6 too!
So at the moment you need to have a dual stack anyway, otherwise IPv6-only node will have much less traffic, in some regions even zero and can hope only for traffic comes through our Gateways.
Without special configurations to wrap it to IPv6 and back to IPv4 (on customer’s side) - no.
However, these wrappers should be enabled on most modern OSes, but there is also edge hardware (especially corporate ones), it must support such translation too.
Usually corporate networks are configured to do not use or allow IPv6 for internal networks for security reasons, it’s slowly changes, but it will take time.
You could transform the test sats in ipv6 data sats, and request every side to support ipv6 for those. I’m sure that there will be SNOs that will jump right in to offer space for those, but I’m note sure about custommers. Maybe now there is no demand, so dosen’t make sense to implement it.
Satellites to have IPv6 support would mainly allow them to check IPv6-only storage nodes.
Gateways having IPv6 perhaps would be the easiest part as they make the bridge between the peer to peer network and the end-users so there are not issue in someone consuming data in IPv6 and the gateway accessing the peer to peer network in IPv4 and IPv6
Storage Nodes - that is the part to have more attention maybe. What needs to be taken into consideration here first is that anyone with spare resources but with a CGNAT + IPv6 would be able to participate and share resources. Without it they simply cannot exist therefore it is not a loss to Storj because as it stands now they don’t exist.
Having IPv6 and capacity to communicate with Satellites they can be checked and carry on.
Maybe the trickiest part is that for customers on the peer to peer network and gateways that have IPv4-only they will not be able to consume data from these storage nodes and this needs to be taken into consideration somehow.
But waiting for 100% of users to have IPv6 then it will never happen and IPv6 will never be available despite there is a fair amount of IPv6 traffic now a days given that most major content providers (Google, Facebook, Netflix, Akamai, Cloudflare, etc) have 100% IPv6 support, therefore it is not something just ‘nice to have’ but something widely used and that brings certain performance and flexibility when compared with IPv4.
One idea to start with and sort out this point with storage nodes is maybe try to use STUN servers and NAT Hole punching techniques so customers behind a CGNAT could still serve data to gateways and other peer to peer customers with IPv4-only connections.
Another would be to calculate the average of node with IPv6-only connections and take that into account for data redundancy proposes. Given that these extra nodes don’t exist at the moment there are not much losses.
Please note that the first suggestion doesn’t mean an IPv6-only customer, but a CGNAT(IPv4) + IPv6 while the second yes. So to start with something can be thought with the main objective to have 1) customers with CGNAT+IPv6 to be able to share their resources 2) to have more traffic on the top of IPv6 which will improve performance further.
I dont understand why cant implement dual stack.
So default all working on IPv4 and if some nodes have also ipv6 then turn it on as additional connection.
So those who can deliver this possibilities can get more traffic.
so why need to chose IPv4 or IPv6 just do booth if you can.
I think for Satellite and Gateways there are no much concerns.
For Storage Nodes perhaps the idea to use some NAT Hole Punch technique can be the answer for these nodes with CGNAT + IPv6 to be able to share their resources as well.
There is a fast growing rate of broadband services with CGNAT + IPv6 globally so things get ready for these amount of connections to not be left out of being able to share their resources.
The biggest issue is that there is no commitment for storagenodes to stay on their connectivity advertised/used. Assume you upload to a set of nodes that advertise both v4 and v6 addresses. In this case you locally only have a IPv4 deployed.
Quickly after your upload has finished, the majority of nodes removes their IPv4, rendering your file offline effectively for you. Of course, via the S3 gateway it will be retrievable, but if you want client side encryption that is not an option or may not fit into your workload/app design.
There a quite a few obstacles to talk about and what shortcomings each has.
@stefanbenten how would that happen that majority of these nodes would remove their IPv4 ? IPv4 is essential for proper Internet browsing being it a Public IPv4 or a CGNAT one. If there is a solution for the CGNAT cases using that technique mentioned as some applications have been using recently that will not be a problem anymore.
While that doesn’t exist then a storagenode with CGNAT + IPv6 would have only IPv6 to receive and send data from the beginning.
I don’t see that many obstacles really. There are some but only with more concern which serving data from behind CGNAT connections for IPv4-only peers. If that can be sorted out then it is a big step forward.
For Satelite and Gateways it doesn’t seem to have much bigger concerns. If anyone see any please share here so we can discuss and find a solution for it.
For your S3 Gateways do you have both A and AAAA records created when you brought them up ?
The CGNAT issue is a very common problem and reason why more and more nodes would disappear from the IPv4 public space. Even if its not instant, its a decay and longer term potentially expensive (if you envision repair taking care of rebalancing the node availability on both protocols.
While hole punching and STUN requires servers on the other end doing the work. They also remain rather unpredictable in terms of stability.
Our satellites currently remain IPv4 only (on the one hand due to restrictions by the GCP regions used and on the other since we have metrics that show that the current track keeping measures arent sufficient for the distinction between IPv4 and IPv6 based on previous satellites).
I myself run a satellite with Dual Stack on the test network (to actually fully implement all IPv6 details and note all necessary gotcha’s down).
Feel free to hookup an IPv6 only node to that network and we can see how it does.
The Gateways have been built out from the first minute using full dual stack:
What sort of issuea do you see with hole punching and STUN ? I have been seen a number of applications implementing it and they seem to have been working fine from the user perspective.
For the Satellites and the issue with GCP is it related to load-balancing ? There was some restriction around it sometime ago but more recently Google has resolved those pendencies and updated they documentation.
For the metrics these are always something tricky. If it is related to geolocation there are already good IPv6 Databases that can make that smoother.
I think that rather than try a IPv6-only node it would be more interesting to evaluate something around NAT Hole punching and STUN, if feasible, because it would have less restrictions and concerns to operate. A IPv6-only would have the complexity to find out what to do with data stored in nodes with IPv6-only and which needs to be served to IPv4-only peers, how to find the right balance or when data needs to be rebalanced, etc.
Regarding the teste Satellite server it can be interesting to find out more about with a IPv6-only test storagenode in order to help to make it happen.
I agree with @FREDY , this post reminds me of one I did a while ago when I changed my internet operator and I ran out of IPv4 by default to the famous CGNAT -IPv6 oder IPv6Lite
Luckily this operator did let me contract IPv4 paying extra, but I know people who were not allowed to do so and had to put an intermediate proxy in order to bypass that limitation.
It is very likely that many people make a proxy to bypass IPv6 through IPv4, and that is bad for the StorJ network because it increases latency by putting one more point.
Many programs use NAT Hole punching and STUN, even some VPN and blockchain nodes, it would be a good option if StorJ supports that or if there are satellites that forward the traffic (perhaps for free or for commission) to other nodes.
Another point to take into account with the Relays is that if we combine them with UPnP, it would no longer be necessary to open ports in the Router, this could be very helpful for Nodes where they do not have access to the router configuration. I have also seen many posts about people failing to open ports correctly and many end up abandoning the project.
It is easy to justify that most Internet traffic is still IPv4, although the IPv6 portion is pretty significant already (in some countries over 40% already).
As with Storj we are talking about a project that rely on people being able to share their resources vastly on their homes the full IPv6 support should be something that need to be under way to be worked out as majority of broadband providers worldwide are fast growing their CGNAT deployments.
I agree taht working with NAT punch hole and STUN may not be the easiest thing but somehow has to be done, otherwise the other only option is to stay forever relying on IPv4-only for people to share their resources.
As mentioned while this technique is not still possible there are already alternatives as for example to allow IPv6-only storagenodes and find the right number to rebalance copies whenever necessary.
But for that to work Satellite servers must support IPv6 and blaming Google for that isn’t the best thing as there are other platforms that support it fully. So keeping relying on GCP is a choice the project remains doing, so either it supports it soon or simply change the platform to another one that does what should already have been done.
And not less important is to update the documentation, specially the storagenode deployment documentation in order to encourage people to host their services with IPv6.
One big concern contrary to that is the vast reliance on docker to hosts storagenode which unfortunately as something too tighten with NAT and may need extra steps in order to work with IPv6. My storage node I refused to use docker, installed from the repository and has IPv6 support from beginning. Also update the documentation to get gateways also to support it, so it can talk to storagenodes directly as well.
@stefanbenten I have brought up a separated test storage node with IPv6-Only in order to connect with your test satellite server and sent you private message in order to get it setup correctly. Awaiting your reply in order to contribute with this investigation.
If there is a business case in here anywhere for IPv6 I can’t see it. Don’t get me wrong I would like it, just no overwhelming benefit for the work required.
It was mentioned several times that with people being able to share their resources with IPv6-only, a lot of people who currently only have access to a CGNAT+IPv6 Broadband connection could also share their resources, make more space available which in turn brings more resilience to the ecosystem e makes it cheaper in terms of storage and bandwidth.
The wrong thing is to believe that in order to have full IPv6 support it needs s business cases. Any software that comes out without IPv6 support from day zero has a problems that needs to be fixed. And that is not me saying but Internet Architecture Board already considers it the default internet protocol, but unfortunately there is still plenty of people who believe that it needs any business cases to exist on any software or platform.
