There have been some questions around initiatives to add more public IPv4 addresses to the Grid, such as requiring 5 per node in Gold Certified farms. IPv4 addresses are hard to come by and that’s more so the case all the time. So, what’s the deal with a forward looking project intending to evolve the internet encouraging farmers to invest in supporting an outgoing technology?
IPv6… any day now
The short story is that architects of the internet massively underestimated how many devices would eventually be connected to it, and the IPv4 address format just doesn’t have enough address to go around. Therefore, most devices in the world use a private IPv4 address assigned by a router, while the router is responsible for communication with the public internet. This works well enough for many cases, but it can be rather annoying if you want to accept inbound connections to your device for any reason.
When it comes to servers, it’s rather important to be able to accept incoming connections from the public internet. Furthermore, peer to peer applications depend on peers being able to communicate with one another, ideally in a direct manner. Things become quite a bit simpler when each device has its own unique address, and that’s one major advancement found in IPv6—there are plenty of addresses to go around.
ThreeFold technology was built with IPv6 support in mind from the start. The Planetary Network, based on Yggdrasil, allows any device to get an IPv6 address, even if the network it’s connected to doesn’t have native IPv6 support. The reality though, is that adoption of the new standard is slow, and we can’t expect everyone using the Grid to use the Planetary Network. If we want to present a highly accessible and compatible alternative to existing internet infrastructure, we need support for IPv4.
Web gateways and overlay networks
Some good news here is that the Grid comes with a few features which enable those deploying on the Grid to stack functionality on a single public IPv4. When an address is assigned to a node directly, that node becomes a gateway. These gateway nodes can map URLs to individual workloads and also allow access into private overlay networks. Using these features can allow a single node to act as a gateway for many other nodes and workloads running on them.
Most deployment architectures should be adaptable to this paradigm, and there are some nice security benefits to using web gateways too. That said, this doesn’t cover every use case on the internet today.
Assignable IPv4s
The bulk of available public IPv4 addresses on the Grid are the kind that’s assignable to an individual workload. These provide the greatest flexibility to the deployer, and are the most familiar when comparing to traditional cloud environments. Many cloud providers assign each virtual private server a public IPv4 by default.
Having a public IP assigned directly to a workload gives architects of complex deployments the greatest control over they handle public traffic. It’s also a basic expectation of workloads like blockchain nodes, that they have a dedicated public IP on which to receive traffic, if they are to accept incoming connections.
Looking forward
One day, we’ll have broad adoption of IPv6 and we’ll be able to laugh about the days when anyone paid extra to have a public address on the internet. For now, supporting many protocols and applications still requires offering dedicated public IPv4 addresses for rent, and providing as many addresses as we can will help with scaling utilization on the Grid.
As a final note, while I wanted to keep this post mostly about the why, rather than the how, we also have some ongoing discussion about how to provide proper incentives for farmers who bring public IPs to the grid, beyond requiring them for Gold or Silver farming. Moving to a proof of capacity model for public IPs, rather than only rewarding them during utilization, is one possibility. Boosters for public IPs are another. If you have thoughts on how this could look, feel free to add them in the replies.