1 hour ago, androidi wrote
Lets say you have 2 people using a laptop with both having connections to two ISP's. Now you want to create a multi-homed load-balanced peer to peer connection between those 2 people. (assume they are using some arcane protocol that only supports ipv4 and no DNS at all)
For that there are exist some solutions already but they don't support the load balancing. Not just VPN but also things to support old network protocols for games and then there's IPv6 tunnel providers like sixxs etc. Add some customized gateway to handle the load balancing and that should do it.
However I need stuff that doesn't require installing stuff on the server, while having the load-balancing for the client such that the server doesn't lose state if one of my ISP drops connection.
Now maybe if the server supports ipv6 connections you could get load-balancing through sixxs but in their current configuration I don't think that's supported.
There's an elegant solution of how to do this using just IPv4 and no DNS:
Since you have IPv4, you can send TCP and UDP packets around the Internet (you can send other IPv4 packet types, but they get throttled on the backbone), so what you really want is a protocol that allows you to tunnel some way of resolving a computer address to you. Obviously there might be more than one person using the protocol, so let's assign each person an identifier (an "address" if you will) and we need to build a protocol over IPv4 that allows a person that knows that "address" to reach one of your load-balanced servers.
This is a really simple protocol, so although we could use TCP, let's use UDP for argument's sake.
The only real way here is that "Computer A" needs to find "Computer B" over the cloud, so we'll need a fixed server that can relay the location information, say "Computer N" with some globally fixed IPv4 address. We can have a bunch of fail-overs to avoid introducing a global point of failure into the network.
Now in our protocol, we can send a UDP packet from "Computer A" to "Computer N" asking for the "Address" of "Computer B". So far so good. But let's make it scale.
To do this, let's have a mesh of "Computer N"s, each in the cloud and geographically distributed. They'll use some protocol for ensuring they keep their records in sync, and we'll dynamically choose which "Computer N" to reach out to based on the local address of "Computer A". We'll do this by having a secondary bootstrap protocol when your computer boots so that your ISP or router tells you where the nearest "Computer N" is.
If we're managing a bunch of "Computer B"s - let's say some in Europe and some in North America for arguments' sake - we can geobalance the connections too. "Computer B"s advertise as the resolving end-point for the unique identifier for Computer N's in Europe, and Computer B's in North America advertise as the resolving end-point for the unique identifier for Computer Ns in North America.
Although you asked mainly about IPv4, we could even extend the protocol (bearing in mind that UDP/IPv6 looks quite different to UDP/IPv4). To do this, we say that when Computer A requests the address of Computer B from Computer N, Computer N returns a bunch of addresses, and some of those addresses can be IPv6 addresses. If the client on Computer A can handle IPv6, it can resolve the unique address to an IPv6 address; otherwise it will resolve to an IPv4 address.
This gets us almost all of the way there. We've got ISP-independence, so if one ISP goes down you don't care. We've got load-balancing (hell, even geo-balancing) of servers, and the client doesn't need to know the address of the server. We don't even need to know of the address of the N-servers either, so long as we build this "initial bootstrap protocol" and get ISPs to use it. The bootstrap protocol could even be used to trivially implement gateways and proxies for users behind corporate networks.
The only major question left is which port to use for the UDP packets, bearing in mind we need to be really careful because we need to avoid firewalls blocking our new protocol and killing it. I did a couple of tests, and it turns out firewalls seem to let UDP port 53 through, and since we're not using it for DNS, it's a good choice of port for tunneling "name -> address" information through. To avoid confusing routers, we can even "smuggle" the data inside real DNS packets so that the data doesn't get dropped by deep-packet-inspection routers or firewalls.
To recap: we need to send UDP over port 53 to some server whose IPv4 address we got from some bootstrap protocol, over which we can resolve a globally unique "name" into one or more IPv4 and IPv6 addresses that we can use to connect to the servers in order to avoid a single-point-of-failure. If we have geo-disparate servers, we can get geo-local results from the "name server" by publishing local servers first on the "name server", and getting clients to resolve requests via their nearest "name server" (and hence resolve to the closest server address).
Huzzah! We solved the problem without even using DNS! \o/