Hey guys!
I am wondering if it is profitable to set up a stack of nodes (~75 nodes / 2tb) only with ipv6 connectivity.
I have seen that the nodes can use dual stack connectivity.
I look forward to your comments
Thanks a lot
Currently it would not be as profitable running IPv6 only nodes, compared to IPv4 only or dual stack.
I’m interested in testing this as well, profits aside.
Currently my nodes are ipv4 only, but I have dual stack on the computers themselves so it just comes down to me creating a dns entry.
I’m assuming that going ipv6 only will result in some problems, but it would be good for the longevity of the storj project to iron these out if possible.
Considering availability of pieces for ipv4 only clients is a tough one though. It would mean keeping separate repair thresholds for ipv4 and ipv6, I’d imagine.
Thats what i wonder too, on IpPv4 its one node per /24 Subnet, what is the approach for IPv6? Also are the satellites now capable of handling IPv6 Traffic (which i think is a requirement that IPv6 only nodes work)?
was to evaluate possibilities
thanks for the comment
I believe there are still lots of things to tackle before IPv6 can usefully be supported across the network. For example, the satellites resolve the domains nodes use and default to returning IPv4 if available. So IPv6 only uplinks are currently impossible to begin with (that said, since uplinks always initiate the connection IPv6 to IPv4 bridging is relatively simple to work around this. So uplinks don’t require a public IPv4 address to function). But IPv4 only uplinks work just fine right now… however, what if a lot of nodes become IPv6 only? The chances of not enough pieces being available on IPv4 could kill functionality of IPv4 only uplinks.
The only real way around it is to track availability of pieces per protocol and let the customer set the availability requirements to IPv4, IPv6 or both. And then adjust the repair process to take this into account. However, this will likely also lead to more repair and more data storage used on nodes.
Then the uplink must communicate protocol availability when requesting a download or upload from a satellite and basically any interaction that would require contacting nodes. As far as I’m aware, none of this is in place. And the only reason it works now, is because all nodes (or at least almost all nodes) support IPv4.
So yeah, technically the entire software stack CAN use IPv6. But in practice it only really works if all or most of the participants in the network support the same protocol. A completely mixed scenario wouldn’t work right now as far as I’m aware.
I wonder. Gateways already act kinda as proxies to storage nodes, by translating HTTP/S3 to Storj native protocol and back. Maybe they could also act as proxies translating IPv4/v6 to whatever a node supports, even when the customer uses libuplink.
Uplink provides decentralisation of traffic by directly communicating with nodes. It’d be a bad idea to go around that and create a bottleneck and single point of failure inbetween.
Applying the same argument you could claim that gateways as they’re now are a bad idea as well.
It depends on the use case. There are two options now. Your suggestion would take the option of decentralized traffic off the table.
1 Like
Just in case for now are no IPv6 records for:
So for now storj infrastructure is not ready for IPv6.
It’s ready, but limited to IPv4 for the native integration to do not split the network.
We have had IPv6 for Gateway-MT and linksharing service, but as turned out, there are big problems with IPv6 routing between some big providers in the USA and Europe (Germany in particular), they cannot negotiate with each others, and this affects customers, so now IPv4 only.
However, it’s still better to have a dual stack on your node, if possible, but having IPv4 is a minimum requirement.