@Knowledge seems you didn’t understand the very basic. This is not a question about “customers are/aren’t asking”. Any product now a days that goes out without IPv6 has a bug in it, regardless of how many are asking for it. This is the default Internet Protocol and not just some ‘nice extra feature to have’. That´s not me saying but Internet Governing bodies.
Telling people to use VPN for this scenario is such an absurd that I am still thinking how to explain it.
Ignoring IPv6 from the day zero of the project with the justification that “people didn’t ask for it” says much about the team intentions about it. Resource allocation are for features, for things that are optional, not for things that are expected. If you don’t communicate in IPv6 now a days you are not in full Internet, just in part of it. Why keep building a product that only works in part of the internet ?
It’s not mandatory. Sure, it would be nice, if people had already started switching a decade ago.
However, as with many things in life, society is hard to coordinate and it happens very often, that large groups in society don’t really care about stuff and problems until things actually become a problem. Just like climate change is under-addressed until it’ll get even more worse - IPv6 is also neglected until companies will be seriously hidered in their operations due to lack of IP addresses. And even with the many limitations today, it’s (unfortunately) easier to kick the ball down further with NAT rather than fchanging your infrastructure from the bottom up to support IPv6.
It is optional for those, after 25 years who still couldn’t care to understand the protocol properly so keep resisting to it and also to all the current number about adoption by a significant amount of the Internet. To avoid it it is just simpler to keep repeating “It is not important. It doesn’t have enough interest yet. Nobody uses it. etc”
If someone who is a developer starts a new project that runs on the Internet without IPv6 in mind, considering something cosmetic or unimportant it just show a careless job and will to deliver only the basic with minimal effort, sends a clear message about the ability to be in touch with technical evolution and adapt to things.
This is not an ideological discussion but just fact based on numbers and real scenarios in place for quiet a while.
By the way, majority of most important big tech companies responsible for majority of Internet traffic now a days have all deployed IPv6 fully in their infrastructure for a long time. Do you really believe they did it just for fun because they had a bunch of idle Engineers there, decided to do on their free time and could have done something more interesting with those resources ? Oh dear !
Lol. How is that relevant for the present discussion? If it was so easy to switch to ipv6 aeveryone would have aldready done so. It takes 25 years and still counting precisely due to reasons discussed above in the thread.
Most consumers do not need ipv6, nor public ip addresses. If you want to interoperable with a real world — you need to support IPv4. That’s where most customers are. So yes, ipv6 is nice to have.
Why is it absurd? If you want to host an IPv4 service behind NAT that’s one way to do it. It’s a solution that works.
It says that people being this business make decisions that are rooted in the real world and not idealistic delusions. Kudos to them.
If you only support IPV6 you only reaching a tiny bit of the internet. Why build a product that can reach a smaller part of the internet?
Why not use both? Read above why. It was very well explained.
Side node: large cloud compute providers like Oracle and google just very recently started supporting ipv6. And storj project predates that in the first place.
In other words, ipv6 is way low down the priorities list for everyone, as it should be
Bingo. This means you need to store way more shards on way more nodes, making everyone pay the price and making the service more expensive. Benefits? None. Drawbacks? Plenty.
A mitigation would be to implement proxy suggestion discussed above, which, again, requires nontrivial development time investment taking precious resources from more important tasks, and when implemented, makes the network operate just like it already does today, but also tickle ipv6 aficionado’s ego.
Aka lot of work for no benefits.
In other words people will switch to ipv6 when they have to. Today there is no need.
It get list of online IPs.
FQDNs puts too much load on the customer’s DNS and the transfer often fail (we passed FQDNs in the past, now we fixed this issue).
@andredias our project supports IPv6 since day one, but it doesn’t matter when the remained part of the network is not.
As I explained earlier all nodes must support either only one protocol or dual stack to allow the customers to use these nodes. The best is dual stack or at least IPv4. There is no good solution for the nodes with IPv6-only support without affecting customers.
I would imagine to use such nodes only for Gateway services and separate audit and repair workers with IPv6 only support, but it sounds like a split of the network. Perhaps it would be better to setup a satellite with IPv6-only support, but usage would be
When IPv6 will be added to Satellite Servers and they moved our of Google Cloud which seems to have been the reason for them to not have it now a days ? If Google Cloud doesn’t support what you need yet what are the barriers to just move to another cloud that does ?
I still don’t see dual-stack mandatory to nodes. The point here is some different way to see I mentioned in a early message and that you just pointed in a different way: the fear of network split. Why would that be a bad thing at all and not just something workable ?
If there is a possibility for IPv6-only nodes there will be much more availability of resources that now a days are unable to exist in the network because of those many who wanted to share them but don’t have a Public IPv4 address. With more resources available you can take into account what is the current percentage of nodes with Public IPv4 + IPv6 and those with IPv6-only in order to update numbers of necessary amount of nodes you need to keep redundancy in a healthy and safe way. This tends to change overtime and can updated dynamically as times goes by and as IPv4 + IPv6 and IPv6-only node amounts change.
Yes using such nodes for Gateway services is indeed a good start, and those can still be a great source of traffic.
The idea that both protocols must exist and work at the same time needs to go away otherwise there will never be a solution worked out for IPv6-only nodes which is not a surprise for them to keep growing overtime given the numbers we are seeing worldwide on the biggest Internet players. This above is just an idea that can be tried in order to find the right numbers.
In time: if you ever work out to try this scenario one thing to have in mind for the node code is to use PCP (Port Control Protocol - RFC 6887) to make requests to the local firewall/CPE in order to allow incoming traffic through it towards the node IPv6 address similar to what UPnP does for IPv4 Port Forward.
Because it does not solve anything, but doubles amount of support, maintenance, and customer confusion: having different data available depending on how do you connect is bad. This is why dual stack is the only solution.
“Much more”? Please provide justification for this claim.
Those with non public address who want to host the node can use NAT from the cloud hosted instance, or provider port forwarding, etc. this is never a dealbreaker. I don’t believe people who are capable of running a node would not be capable of understanding how to configure connectivity.
No, it does not. Full redundancy must be guaranteed for ipv4-only clients, so all pieces must exist on ipv4 accessible nodes. The same
is true for ipv6. And if someone uploaded data over ipv6 they should be able to download the same data over IPv4. This is doubling amount of data on the network right there. The only way to avoid doubling is if all nodes support dual stack.
So choice here is: force all node operators to dual stack not to break the network, or force a few those that are not even a part of the network yet to lean about NAT.
This choice is not really the choice.
No, thanks. Any half-competent admin would turn this garbage off immediately. There is no reason for this to be relied upon for hosting storage nodes. Adding a firewall rule takes 5 seconds, punching holes through a firewall shall never be allowed without proper authentication.
Perhaps I’m a bit naive, but wouldn’t it be possible with much less hussle and stress if Storj-satellites also ran a VPN-server for those not able to expose a public IP. Those VPN’s could run on the satellites for example. With the restriction, they only are able to forward traffic to satellites. Would even save STORJ hopefully some people trying to evade the /24-rule.
And besides, it’s quite easy to run your own VPN server on free Oracle Cloud forwarding all traffic. See for example the script @arrogantrabbit wrote on GitHub. The hussle of installing wireguard could be saved a little bit by using the wireguard installer from angristan on GitHub too.
In the end, I actually don’t see the point from people with GC-NAT or IPv6 only, not being able to contribute; having to use the latter option myself too, without a problem for several months now.
This would mean all traffic will run through satellites, twice, and it’s very expensive. Today satellites only do management, all data exchange happens between nodes and clients.
This will also introduce double delays for the unnecessary roundtrip — so these nodes will end up serving less paid requests.
This problem is — those are inevitably slow: if for every file client will need to do do all that NAT traversal dance with multiple nodes it will be too slow and those nodes will be always losing races. Those techniques are useful when you establish a connection once and then pump a lot of data through it.
This would mean running a second independent storj network to benefit tiny minority of users and adding a lot of confusion — why my files are available only via IPV6? People may need to access data from multiple devices, so you would end up needing to build ipv4 gateways, etc.
Looking form the customer perspective: everyone can connect to ipv4 servers. Not everyone has support for ipv6 in the first place. Hence, storj runs on IPv4. Suffering of node operators behind NAT is not customers concern, operators will figure it out. They are paid to do so.
If it was easy to flick a switch and add ipv6 support — sure, why not. But it isn’t, so we don’t.
Folks, stop given much attention to what this folk says as the topic is to get full IPv6 support to Storj and what he/she seems to enjoy doing is to fight against it. Any solution proposed for it to work there will be a problem found. Seems he/she only wants attention but not to resolve the issue.
And the worst is that doesn’t seem to know any proper numbers and status of the internet to bring into discussion and affirms a “tiny minority” just out of nowhere. Not even PCP he/she understands where it fits.
Those who are interested in finding a solution to be implemented please keep contribute. Those who want to fight against IPv6 maybe because wants to throw all their frustrations of after 25 years not have bothered to understand it properly open a new topic to discuss why Storj should never have full IPv6 support as it seems what they wish.
I’m pretty sure you are referring to me, but you are replying to a wrong person.
This is so bizarre. There is no “issue to resolve”. Everything works fine. You just want ipv6 for the heck of it, because it’s cool or recent or whatever. It was explained many times why adding ipv6 is not viable today with the present network architecture. In 30 years – maybe. But not now.
What is the problem with STORJ today, that can only be solved by adding support for ipv6 across the board, let alone justifying making massive infrastructure changes?
You on the other hand claim that lack of ipv6 support is somehow a problem… Today all internet connected customers have ipv4 connection. Otherwise they’ll have more than half of the internet inaccessible. ipv4 is here to stay for a very long time. I only said “tiny minority” to avoid saying “nobody” categorically.
But if you want to keep reiterating the same thing over and over, while the justification has been explained to you many times – go ahead. The problem is not that it’s not possible to make work; it’s that it is not worth the efforts, engineering time can be spend on something else with much better outcome, and highly pointless in the first place.
Guys,
Why waste your time with this company? If a company can’t understand the need for IPv6 deployment and doesn’t have a vision for their business, then just let them die with time. They will be one more company that died and remained in the past, that did not become modern and that decided to go against something that there is no way to go against. It’s like wanting to turn water into wine and thinking that at some point a savior will appear and multiply IPv4 for them. Unfortunately this only happened in the Bible and it was with Jesus and not with the Internet.
Fact: IPv4 is dying out in many places around the world. I work for a large operator in Brazil and I say that our IPv4 is running out and that is why, out of respect for our more than 500,000 customers, we deliver IPv4 and IPv6. New ISPs are no longer having IPv4 to deliver to their customers, leaving them with IPv6 only.
Your company’s mentality is not one of growth and evolution and that is why other companies will emerge operating in the same market as you but with intelligence and improved to meet an evolutionary Internet, an Internet of Things and not an Internet of the past, patched and full of problems.
Let this company break down and keep our comments for them to read when they fail and see that we warned them and died because they chose to die.
“It is not the strongest of the species that survive , nor the most intelligent, but the one more responsive to change.” ~ Charles Darwin.
We implemented support of IPv6 since day one. But we understand, that not all customers uses IPv6. We understand also, that if the part of the data will not be available to the customers - we lost customers, their trust and company at the end.
The network is a decentralized storage - data from the customers directly flow to the nodes and read back, it doesn’t go through satellites, so both points must use the same protocol. Since there is not so much customers with IPv6-only support, we cannot lean on IPv6-only nodes.
So decision for now to support always available IPv4 protocol and request from Node Operators to have it too. Our Edge services (linksharing, Gateway-MT) are available via IPv6, so customer who have IPv6 support may use them. These services may also use IPv6 connections to the nodes.
The best option, if the Operators can use a dual stack.
Currently there is no option to allow IPv6-only nodes join the network, they should use IPv6-IPv4 tunneling, IPv6-IPv4 proxies or VPN, otherwise customers without IPv6 support cannot use them.