Storj would then be added to the same list of S3 storage providers like Amazon / Backblaze / Cloudflare that already supports IPv6 native.
I would start uploading 200 - 300 TB of data again using IPv6, if that option shown above would be available.
I’d even start uploading using IPv6, if tests are needed
And as a SNO, I would be fine with earning less on data coming in using IPv6 to help the v6 protocol being used more.
I don’t know how every ISP in the world are handling native IPv6 internally, but would that not be the same issues as for the current IPv4 protocol?
Most of the times we are having Internet issues, both IPv4 and IPv6 are down at the same time.
I take it that Storj already have uptime data on IPv4 nodes, so maybe they could also track uptime for IPv6 nodes and compare uptime for both protocols over a period of time, to see how much difference there is.
If the difference are small, then IPv6 should be fine for further testing.
IPv6 is unstable due to conflicts between ISPs and IXPs, while IPv4 can function normally. ISPs typically provide good connections to YouTube, Netflix, and other major content providers, while other content providers are served on a residual basis.
Therefore, it’s entirely possible for a client to lose IPv6 connectivity to an IPv6-only node while IPv4 is functioning normally. If there aren’t enough IPv4 nodes with the client’s data pieces, the client may lose access to it due to insufficient pieces to restore the file.
However, if the client is willing to accept the potential loss of access, then your offer may be justified.
I’m not entirely sure how this would fit within our SLA, but the idea is interesting.
There’s also the issue of operators - will they agree to receive less for their services if their node only supports IPv6? I can imagine that there might be fewer clients, and thus less data, because it will be a partially isolated subnet of Storj Global Network.
!