I mean, for example, will be two different “SAFE Networks”? One on top of IPv4-Only Internet and another one, on top of IPv6-Only Internet?
And about deploying my farming, on top of the Hyperboria (an IPv6-Only global network)? It doesn’t depends on the Internet to work…
Will those 2 or 3 “SAFE Networks” be just 1? If yes, how they will “find” each other? I mean, IPv6 can’t directly reach IPv4 nodes (same for Hyperboria, which is a different, non-routable, IPv6-Only network)…
Hmm good question, it is related also to NAT traversal and how nodes choose to connect. The crust lib will support ip4 and 6, however the connection (utp or tcp) will require to connect to at least a majority (called quorum) number of nodes in your group. So if your machine is set to ip6 only then it will have to find a group that will accept ip6 connections (at least quorum number of them).
Not all groups will be able to help so you may not get a good connection and your node will relocate (join again) until it can.
Hopefully many nodes will be dual stack (we try and get all if addresses available and send the ones we can listen on to other nodes to try and connect to us, so you may get tcp udt (reliable udp) and I suppose ip6 and ip4 (need to confirm with the crust guys though). If not ip6 capable right not it’s not a big issue as the rust networking libs do support ip6 and as we are multi protocol then there should be little issue.
Sorry if this sounds a bit vague, I am stuck in another part right now. Maybe some of the guys will pick this up (crust guys that is). If not please ask on the crust github issue tracker as many of the devs focus there in this period of launching.
I have a better view of how it should work now, specially “seed nodes”, crust lib and “nodes in a group”… However, I’m still researching a lot about it…
Personally, I have much more IPv6-Only nodes, than IPv4 or DualStacked… I am disabling IPv4 because it is useless for me (and I hate NAT). So, janitor, now you know an user that disables IPv4…
Right now, I have a “maidsafe” Ubuntu VM, running “./launcher_cli-mock-linux”, it have 3 IPs:
I can run any tests you guys might bring up to the table, specially related to mixing up different networks and for trying it for Farming too (BTW, no idea how to start farming on testnet yet).
This looks like an interesting problem, as the library has no means to know that your hyperboria IPv6 is “special” and should be used only under some network interfaces.
We encapsulate endpoint representation, so we could easily reserve some string to identify an endpoint as being “hyperboria-only” (Probably Andrew has more to say about than I).
But the problem about informing crust that some connections should be reserved to some network interfaces remain (I’m assuming hyperboria will create a virtual network interface).
I find mesh networks interesting, so maybe I’ll reserve some time to research the problem properly and write a RFC. Of course this isn’t a priority and while the network isn’t launched I think the team should focus on launching the network.
I just remembered something about Bitcoin Daemon (bitcoind), it have the following option:
“-bind=[::]:8333”, like this:
bitcoind -bind=[::]:8333
That makes it work on both IP versions… So, this way, I can see by running “netstat -natup”, that the bitcoind have established connections on both IPv4 and IPv6 networks (i.e., it is DualStacked) (including on Hyperboria, I forced it on Hyperboria by running another Hyperboria-Only Bitcoind Node (by using addnode on bitcoin.conf), just for fun).
Yes, Hyperboria IPv6 address is a different interface (usually, tun0). It is very, very interesting!
So, when talking about the SAFE Network, what is the equivalent of “-bind=[::]:8333”? To make it DualStacked…
The problem with this approach is it ignores PEX (peer exchange). We really need to encode network (e.g. is it hyperboria or the usual internet?) information. But I said earlier that we can take this by granted.
So… even if add a --bind=[::]:8333, this won’t be enough, because it won’t tell us that this interface is hyperboria-restricted. This is also solveable because we can put something like --bind-hyperboria, but there is the problem of not being handled transparently at crust level and having to involve guys from other layers of the SAFE network.
Anyway, there is still one problem here. Suppose we instantiate one application to listen on a hyperboria-restrict interface. Through PEX, this endpoint will be shared to SAFE nodes that might very well be running on a machine that has both enabled (“normal internet” and hyperboria), but is only listening on “normal internet”. How does this safe node that just received a “hyperboria endpoint” connects to it if the application doesn’t know one of the network interfaces is hyperboria-enabled?
What are the most popular communication channels hyperboria guys use? Maybe I can have a chat with them.
Well, a simple way to get around the IPv6-only thing may be to create a IPv4<=>IPv6 mapping either on the firewall or on the boxes themselves. I would check iptables, but also there’s this: http://www.dest-unreach.org/socat/doc/socat.html
There is no need for something like “–bind-hyperboria”… It is a plain IPv6 network, so, if “socat” supports IPv6, then it is “hyperboria-ready”.
With Bitcoin Daemon, we can run it by passing “–bind=[::]:8333”, it already works as expected on top of IPv4 and on IPv6, including Hyperboria (because it is just an extra IPv6 subnet, nothing special about it).
So, I think that the SAFE Network can locate itself (its nodes / UDP local beacons?) on top of a Dual-Stack Network (IPv4 + IPv6) plus Hyperboria…
Think about Hyperboria as an IPv6 LAN (but it is global), and it doesn’t even have a gateway! So, it is literally a “Global IPv6 LAN”, that’s it!
I have lots of combinations to try… I think that I’ll need to wait for testnet for that, am I right?
Well, you can’t share addresses of local LAN nodes with the “global nodes”. There is special treatment for nodes on local LAN (peer exchange). There would be special treatment for Hyperboria too.
I’m pretty sure that everything that applies to an IPv6 subnet (be it Global / routable to Internet or a LAN), is valid for Hyperboria IPv6 but, I agree with you, Hyperboria might not propagate UDP broadcasts all over its mesh network, so, yes, it might need a special treatment (i.e., doesn’t support auto-discovery)…
I’m waiting for testnet to create a small HowTo about those ideas…
