Is it possible to use a static IPv6 address in the ADDRESS part of the docker command instead of using an actual domain name? I have a domain at no-ip but despite setting up the DUC2 thing, it doesn’t keep itself active. I have to obsessively check my email for a notice from no-ip around the middle of every month to make sure the address is still active.
IPv6 is not supported.
IPV6 does not work.
I recommend duckdns.org, no need to renew it.
If you are on linux, just create a curl cron job.
Use ipv4 and have inadyn update your DNS record. Don’t use those no-ips and other duckdnses, use a large reliable provider like cloudflare.
In my opinion, No-IP is reliable, if not more reliable than cloudflare.
No-IP also has the big advantage of being pretty much available even on shitty ISP routers.
I would recommend you use whatever provider your router supports instead of messing with DUC2 or other DynDNS programs.
1 Like
The IPv6 is supported and can work, but disabled until all customers will use IPv6 too.
At the moment their amount is negligible, so if we would enable it, this will split the network (the customers who uploaded via IPv6 wouldn’t be able to access their data via IPv4 and vice versa), so having a public IPv4 is a mandatory requirement, but you may also enable IPv6 and use a domain name and update it with both IPv4 and IPv6 to be ready for IPv6 traffic too (our Gateways are able to use IPv6, but not in all countries due to conflicts between exchange traffic providers in some countries).
Please don’t give too much ears to those who tell you to not use IPv6 because some just didn’t take the time to understand it properly and prefer to stay in the past of technology with the easy saying that nobody uses it (which is not true anymore for a while).
If you run a storagenode it does support it for traffic and can work so it does for the gateways. I have on mine.
Where it doesn’t work is for the Satellite servers and that’s mainly for two reasons:
- The Storj staff refuses to move to another platform that supports IPv6 fully for Satellite needs, and 2) It seems there is no will to find a balanced solution to start having IPv6 on Storj along with IPv4 nodes so it has been easier to say that is is all of nothing instead of build up a solution that could work with both type of users who have dual-stack and IPv4-only without compromising the data redundancy of the network.
This discussion has been rehashed quite a few times in this forum and there are very good reasons for non-availability of IPv6 at the moment.
It’s not unwillingness from Storj to run the satellites or other infrastructure on IPv6, it’s more that support is still very random with SNOs and clients.
3 Likes
As a reminder, I would redirect you to this post on a thread you started about IPv6 where a Storj engineer explains the limitations and decisions made.
3 Likes
I have no skin in this game: but I wonder if SLC could switch to dual-stack IPv4+IPv6… and then nodes that also supported IPv6 could perhaps partake in extra test data? So you’re giving SNOs an incentive to get-their-IPv6-ducks-in-a-row, and some time to test… before the production satellites also added support?
Like if I was told running dual-stack could maybe get me 2x the amount of upcoming capacity-reservation data… I’d find a way to make it happen!
1 Like
I followed that topic and I still stand that there is lack of will to find out a solution. There must be one and I am not saying that is simple of trivial thing, but if no effort is put on that because there other more interesting things on the line no solution will be ever found.
When they put the need for all nodes to have IPv6 support in order to enable it they are basically saying this will never happen and that can’t be acceptable and even reasonable.
Just to mention one of the approaches, Dual-stack and IPv4-only customers still can communicate fine (look, we are not talking about IPv6-only nodes yet) and for those cases where a IPv4 nodes can’t communicate to a IPv6 node can be accounted for the data redundancy as it already is for node that go offline or unavailable.
Nobody expects suddenly a high number of IPv6 nodes and it is expected that can grow overtime, so then find a formula that can adjust it smoothly overtime.
For Gateways is it easier to have Dual-Stack enable and guarantee that it will be able to communicate to any IPv4 or Dual-Stack node.
Lastly what is the barrier for Satellites to have a full knowledge of node support for IPv4-only or Dual-Stack and direct things accordingly ?
The Storj post that ACarneiro linked contained this:
“…because most of the people who want to ditch IPv4 are node operators, not users of the Storj service…”
So, Storj’s paying customers aren’t showing a strong demand for IPv6. Why would you think there’s a “lack of will to find out a solution” to something the people-with-the-money don’t think is a problem?
3 Likes
I am used to hear this type of justifications for not doing something up to the current technology for years. As if most customers understood about these details, but it easier to hide behind it for keep having a reason not to do.
When we are discussing technology and the improvements technology brings and someone comes with an argument kind of “I pay for it and I want that old and legacy way” it voids completely the technology part of the discussion.
While I understand that Storj may be a company that doesn’t have spare resources for doing anything that sounds interesting or good, some things in my view are not optional now a days as having IPv6 support for any new product. It exists for decades and should already be present on any product from day zero if developers understood it properly. When a product doesn’t have full IPv6 support it sends a bad message to the market specially for those who understand what may be causing the team to not have understood it yet in the context of Internet.
Other nice to have feature may be desirable but still not able to able due to the amount of necessary resources to develop it, but IPv6 is certainly not one of them. It is in the basics.
Above all, it is important to mention that if the justification is because there are not enough resources to find a solution right now or even that “customers are not asking” it may be understandable, but saying that it requires all nodes to have IPv6 support as the only solution it is basically saying it will never be done and no solution will be ever sought.
I’m fine with Storj waiting for paying customers to request IPv6, before they add official support. That is a type of justification that I am used to hearing: and is quite common from companies that wish to remain solvent 
But maybe it’s still something that SNOs could move forward? There may be no money in it, but the technology is interesting, and good, and has been around for decades.
1 Like
For those who only cares about the financial point of view, technology details doesn’t really matter to look good, I get that.
But still it can’t be said that there is not solution if it was never sought, nor it can be put as a blocker that absolutely all nodes must support IPv6 as a justification for not even try.
Perhaps new minds come into the company and the project and manage to balance the technology and financial sides properly that doesn’t leave important things like IPv6 behind for so many year still.
There is no problem to enable IPv6, there is a problem with splitting the network
this is the main and the final limitation. As soon as there would be no customers with IPv4 or all nodes will support both (no one with IPv4 only or IPv6 only support), we can enable IPv6, otherwise for the customer it would look like their files are lost, if they uploaded via IPv6, but now are trying to access using IPv4.
In summary:
- either all customers would use only IPv6
- or all nodes shall support both protocols (dual stack) - and this is will be a mandatory requirement
- or all nodes shall support at least IPv4 as a mandatory requirement and IPv6 as optional one (the current state)
You may use a dual stack for nodes, but IPv4 is a mandatory for now. IPv6-only nodes cannot be used, because they likely could work only with Gateways, which are dual stack. We shouldn’t advertise them to the customers even if they have IPv6, because if they would like to download their files back using IPv4, they will miss all pieces on IPv6-only nodes, this is why all nodes in the network must have either a dual stack or at least IPv4.
If all nodes become to be a dual stack, then we can safely enable the dual stack for satellites too, to advertise both addresses to the customers and they would select what’s the network they would like to use, and if they fallback, they will still have access to their data.
Yes, they do. But here we meet another problem - traffic exchange companies blocks IPv6 traffic of each other (they didn’t come to the agreement, so they just makes it impossible to use)…
Doesn’t help, because this will split the network to three segments:
- IPv4 only nodes
- IPv4 and IPv6 nodes
- IPv6 only nodes
Only nodes from the group 2 can be fully useful if we would have a dual stack, group 1 and group 3 must be banned, because we doesn’t control what the network the customer would use to upload and download their data. We cannot allow the split of the network, otherwise part of pieces will be not available. The last one is an equivalent of lost pieces for the customer and likely lost files.
2 Likes
Hi
At a first stage and in order to make it happen I think IPv6-only doesn’t need to be a hard requirement. That can be worked out later. As long developers have will to find a solution for Dual-Stack and IPv4-only customers to co-exist that is already something positive.
The access to gather data from nodes (for example when using the uplink-cli or from a Gateway) can always be done pointing peers to use node FQDNs so if a node has dual-stack support its FQDN will have A and AAAA records and if the peer accessing it has IPv6 it will automatically happen over IPv6. If the client accessing has IPv4-only then access will continue to happen normally over IPv4.
Again making a requirement that all nodes have IPv6 support doesn’t make much sense as there are alternatives to deal with it besides puts a stone on it saying it will never happen and a solution will never be sought.
I don’t understand the point about “traffic exchange companies blocks IPv6 traffic”. Working in the Internet Infraerstructure industry for a while I have saw such thing.
It is normally the contrary. Where there is dual-stack support there may be IPv4 filters but often IPv6 has much less or no filters and if one thinks about there are no much reasons to filter anything.
Still one thing that nowadays is basic about IPv6 is that if a content that supposed to be available on IPv6 for some reason is not, all moden Operating Systems fallback to IPv4 automatically and things keep working as expected thanks to RFC 6555 - Happy Eyeballs: Success with Dual-Stack Hosts
As you see there are alternatives and possibilities to overcome any complexities and make it happen if there is will to understand this protocol which is there for decades and get things to work for both IPv4-only and Dual-stack nodes
Yes, but why bother? Just because ipv6 is “better”, “newer”, “future proof”? Why?
What problem is there with IPv4 with respect to storj that you want to solve with ipv6?
If there is no problem — I don’t see a point in spending 1 minute of anyone’s time enabling it.
As many have already pointed out - when 99% of customers and 99% of nodes have dual stack — then maaaaaybe it would make sense to enable it. Maybe. If it will provide additional benefits. IPv4 is not going anywhere.
1 Like
Not worth discussing with those who didn’t bother to take the time and learn about the topic before commenting, prefer to stat in the past hidden in a cave because that’s what one was able to learn so far and refuses to learn and improve technology.
Seems most of your posts in this forum are to put out your anger towards people, maybe to be in evidence and get some attention. I am not going to solve someone else’s emotional issues.