@IsThisOn I agree on the advantages. As you said, everything comes with a catch.
Your uplink wants to upload a file. It contacts the satellite, the satellite goes through its list of online nodes, applies the /24 rule and gives out a list of X nodes for the uplink to connect to. We’ll go with the scenario that the nodes run dual stack. The satellite needs to resolve the FQDNs for each node and then apply the /24 rule. We don’t have a /24 equivalent rule for IPv6, so it doesn’t know what to filter out. Let’s even go with a /48 for IPv6. Alternatively the satellite just hands out the FQDN to the client. This comes with its own problems, ie what two FQDNs belong to the same physical location?
The uplink client got its list and starts the uploading process. Since all modern OSs (even that abomination that people still religiously insist on using) prioritize IPv6 over IPv4, it starts connecting to the IPv6 nodes first. One slight issue though. The client doesn’t have IPv6 enabled. In this case it needs to wait for an unreachable message for each IP, then fail-over to the IPv4 address (in the case it got the FQDNs) or ask the satellite for more nodes in the case that every node it originally got was on IPv6.
As you can see this isn’t as simple as hosting a webserver on dual stack. As Alexey has said many times, the /24 and /24-IPv6-equivalent rules should be implemented in protocol, so the satellite can just give the client/nodes-trying-to-repair a FQDN to work with. But even that comes with its own problems.
The alternative I see is the client maintains a list of online nodes and does its own profiling/filtering. Perhaps using a DHT of some sort (like torrent clients do).
There are simpler stop-gap solutions of course: if the client is contacting the satellite on IPv6, then assume that it is capable of IPv6 and send it IPv6 lists, otherwise if it contacts it on IPv4 then most likely it doesn’t have a working IPv6 stack so it needs IPv4 only addresses. The satellite will still have to resolve all node FQDNs periodically (how soon is too soon?).
Do the pros outweigh the cons? In this particular case, no they do not. The time spent for the client trying to figure out where to upload could be spend actually uploading data, which brings us back to the whole “it’s not requested by clients” argument.
EDIT: forgot the nowadays mandatory disclaimer: Warning! This reply may contain fictitious examples. They are used to better explain certain scenarios and any implied connection to reality is purely coincidental. Reader discretion is advised.
My ISPs primarily offer cheaper alternative to the big ISP. That’s pretty much the point - offer similar speed for lower price compared to the big ISP. The connection may not be as reliable as the big ISP (though the difference isn’t much), but people like the price.
If the big ISP started offering IPv6 and started advertising the fact, people would likely start asking for it (even if they do not understand what it is, only browse the net and not run any servers). If the big ISP started offering IPv6 but was quiet about it, very few people would notice.
By the way, none of my ISPs use CGNAT. Everyone gets a semi-static public IP. Though, when I worked with an ISP that did use CGNAT very few people asked for a public IP.
Yes, I’m going to pay more for the same connection to be able to use a protocol I don’t really care about. Honestly, IPv4 is good enough for me. Sure, if there were lots of IPv6-only sites I would have a problem, but right now there is no problem.
Similar with Storj - do you want to fragment the network? There would be three types of nodes:
IPv4-only
IPv6-only
Dual stack
A customer uploading a file using IPv6 would get some dual-stack nodes and some single-stack nodes. Now, if said customer tries to download the file using IPv4 he has to pray that enough dual-stack nodes have the pieces. So, and if the customer was dual stack in one location and IPv4-only in another, that would suck.
By how much? I seem to be able to get about 1gbps on my 1gbps connection.
The consumer routers seem to work fine and get 1gbps from 1gbps connetion on IPv4, even if the cheap ones fail in other different ways (even better if a cheap router fails starts flooding IPv6 packets to the uplink - good thing that switches are configured to drop them).
Until the government forces ISPs to use IPv6 or until they run out of IPv4 addresses, I don’t think anything would change. Most people do not know what IPv6 is, they don’t really know how to forward a port or what a “router” is.
It is supported. The current requirement is to have a public IPv4. This will not change any time soon, because most of customers uses IPv4. But you may also advertise IPv6 as well, the dual stack nodes are welcome.
IPv6 only nodes will not be supported any time soon, because it will split the network. I explained it many, many times.
You have had opened the same threads many times: Search results for 'ipv6 @FREDY order:latest' - Storj Community Forum (official)
I would like to do not repeat the whole last your thread again.
There is nothing to discuss. IPv6 is fully supported, but not required by the customers. IPv6 only nodes will not be allowed to join any time soon (it’s required to have at least all customers uses a dual stack, which is far away from the reality).
See also: Search results for 'ipv6 order:latest' - Storj Community Forum (official)
The whole point is, that all our software supports IPv6 from the day zero. And from the day zero it was clear, that allowing to join IPv6 only nodes will split the network. So, IPv6 is nice to have, but your node must have a public IPv4. Thus - only a dual stack or at least IPv4 nodes can join the network.
They can. But we do not want to split the network:
We have.
The satellites will provide IPs to the customer, because we have had issues when the DNS server of the client was overloaded and they were not able to upload sometimes. So this burden is on the satellites now, they would resolve the last FQDN and cache it for some short time (up to several hours, if that one become a very popular choice of the customer). Sometimes it could not get an IP, if it was changed recently, this will immediately invalidate the cache (especially after implementing of the “choice of n” rule lately), so, it will be resolved when the node would check-in on the satellite the next time.