IPv6 + IPv4 Co-existing together

Development & Technical discussion about Timekoin.
Forum rules
Bug Collecting Database is Click Here
GitHub Account is Click Here
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

IPv6 + IPv4 Co-existing together

Post by KnightMB »

This topic needs to be started to get some discussion going. :)

First thing, IPv4 and IPv6 are not compatible with each other in the raw sense. Meaning, I can't access a IPv4 address from a native IPv6 address and vice-versa. Without getting into all the details about 4to6 and 6to4 tunnels and services to make them work together, I wanted to get some ideas or feedback from everyone here.

The first thing that comes to mind is multi-homed servers. I am in the process of getting a linux VPS setup (very minimal specs of course) that is multi-homed with both a static IPv4 address and a small range of IPv6 address (65,535 IPs is small for them, LOL). This test server will be able to access any IP on either network (IPv4 or IPv6) because it has both network layers setup on it. I've already noticed some IPv6 address that are starting to appear in the peer list, so I believe those people are running servers already in the IPv6 range and probably using a 6to4 tunnel to access the other peers, etc. Timekoin already has the correct space set in the database for IPv6 address, so it does work in a native environment already (for those just running IPv6 address), but unfortunately, the process for peer election and currency generation does not work for those people in the IPv6 network because the native IPv4 peers have no way to access them.

So the question is, how do you allow peers in the IPv6 network get elected and create currency just like the peers in the IPv4 network? The same question was asked years ago among the early Timekoin team members and I hope my solution still seems valid. ;)

To start, multi-homed peers (those that can access both the IPv4 & IPv6 network) would act as gateways between the two networks. So on the transaction level for example, if I send a transaction to be processed to this special server, it can broadcast it back out to both the IPv4 peers and IPv6 peers at the same time to make sure everyone is building a consistent transaction history. That part is simple enough, does not even require any special code changes as the current Timekoin server can already do this.

The tricky part is, what if I want to allow servers in the IPv6 network to get elected, create currency, etc. How do all the peers in the IPv4 network contact anyone in the IPv6 network if they can't do this natively. How do you prevent someone in the IPv6 network from just getting 1,000,000 IPs and trying to get a unique key elected for each one?

One solution that I came up with a few years ago involved was simply not allowing more than small amount of IPs from the IPv6 to get elected anyway. The problem was is how do you figure out a good number? A few per day, a few per election cycle, a static cap amount (say only 100 IPv6 period). Those are tough to debate because of what would be considered fair or what would be considered safe from potential abuse in the future.

Another solution was to limit any IPv6 address to the actual block size of the range. So if you owned a block of 65,535 address, only one of those in that block could get elected. The logic being that in the future, you can get a large block of static IPv6 address for free, but not an unlimited amount. So an ISP won't give you a million IPs just because you want them, you might have to pay high cost like you do now if you want a large block of IPv4 address.

Another more interesting solution was to allow there to be separate elections for each network IPv4 does its own, IPv6 does a separate system of elections and the two do not need to meet anywhere as long as they both process the transactions properly.

One final solution was just don't allow any peers from the IPv6 network to create currency and just keep it to the IPv4 network only. Keep the gateways so transaction processing can take place like normal between the two networks, but all the currency creation comes from the IPv4 network only.

Ideas and feedback are certainly welcome. :mrgreen:
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: IPv6 + IPv4 Co-existing together

Post by KnightMB »

I've setup a multi-homed server via a VPS host (gigatux.com) if anyone has a IPv6 setup already, you can manually input the peer to test that it responds properly, etc. At the moment, I don't have any other IPv6 timekoin servers out in the wild to test with. :?
Anyone got their own server I can connect with? :)

Multi-homed DNS: timekoin.for-our.info
IPv6: [2607:f128:40:1702::]
Subfolder: timekoin
Port: 1528

Multi-homed DNS: timekoin.for-our.info
IPv4: 216.86.154.214
Subfolder: timekoin
Port: 1528
warmach
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Re: IPv6 + IPv4 Co-existing together

Post by warmach »

I see two problems...

1. IPv4 two way communication with IPv6
2. The ease of attaining and abundance of IPv6 addresses.

Here are my questions and thoughts. Sorry, just kind of a brain dump...

1. How is will all the large ISPs and internet backbone companies going to handle it? It will need to be handled and soon. Do we need a short term or long term solution. If we provide the gateway, we risk a fork if all gateways shutdown at same time or large worldwide internet attack.

2. Right now, the only requirement to elect is having a live computer at an IP address. With 65K IP addresses, you could have one computer serving them all but generate 65K each cycle. How do we fix this?

How about some proof of work? :roll: Just hear me out. What if we add another requirement to the election process. Solve a problem before you can be elected.

At the start of the election cycle, a random "answer hash" is generated (like how a key is elected now). The server must then solve the problem with trial and error... PubKey + unknown = answerHash The server tries different things for the "unknown" until it solves the problem.

Once the problem is solved, it can respond to peer polling with this "unknown" as its hash code. The polling server could then compute the compute the equation to verify it is right. Only then can the key be elected for generation. It would have a 5 minute window during the election cycle to solve the problem. If it can't it doesn't get elected.

How does this stop large amounts of IPv6 IPs from getting elected? As each key tied to a IP would have a different problem, the server would need to solve 65K of these in a 5 minute window. This would require more server resources and it would cost more money, there by reducing return. It would also having the effect of small computers, i.e. Raspberry PI, not being elected right away even if it is the only one trying.

I would also suggest that generating peers do this same calculation but being polled at random to verify all is still good.

I am not as familiar with encryption algorithms as others, so I don't know if there is one that might fit this idea. Maybe all this rambling gave someone another idea that will work.
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: IPv6 + IPv4 Co-existing together

Post by KnightMB »

warmach wrote:I see two problems...

1. IPv4 two way communication with IPv6
2. The ease of attaining and abundance of IPv6 addresses.

Here are my questions and thoughts. Sorry, just kind of a brain dump...

1. How is will all the large ISPs and internet backbone companies going to handle it? It will need to be handled and soon. Do we need a short term or long term solution. If we provide the gateway, we risk a fork if all gateways shutdown at same time or large worldwide internet attack.
I do wish the designers of IPv6 though that maybe some backwards compatibility would be nice, but it you can't go either way with IPv4 or IPv6. Either you have a mutli-homed system (doing IPv4 and IPv6 at the same time) or you use tunnel servers 4to6, 6to4, etc. so that an IPv6 address is wrapped in IPv4 packets, etc. All of which are temporary really. For regular users, facebook works the same on a IPv4 network and IPv6 network because the DNS name "facebook.com" handles all the IP resolution. So if you are a IPv4 network, you automatically get IPv4 address. On a IPv6 network, it resolves to a IPv6 address. Regular users won't know much difference really.

More technical users do of course. If you were on an ISP that was IPv6 only, most big sites (facebook, msn, google, yahoo, etc) would work just fine. It is not until you went to custom-domain.com that runs on a IPv4 only server would the site not come up.
The plan for most ISP is just to keep using IPv4 and dual-stack everyone over to IPv6 and eventually people will want to setup sites on IPv6 because getting the IP is cheaper and the IPv4 address will become very valuable for old devices (like really old) that can't be upgraded to work with IPv6.
2. Right now, the only requirement to elect is having a live computer at an IP address. With 65K IP addresses, you could have one computer serving them all but generate 65K each cycle. How do we fix this?

How about some proof of work? :roll: Just hear me out. What if we add another requirement to the election process. Solve a problem before you can be elected.

At the start of the election cycle, a random "answer hash" is generated (like how a key is elected now). The server must then solve the problem with trial and error... PubKey + unknown = answerHash The server tries different things for the "unknown" until it solves the problem.

Once the problem is solved, it can respond to peer polling with this "unknown" as its hash code. The polling server could then compute the compute the equation to verify it is right. Only then can the key be elected for generation. It would have a 5 minute window during the election cycle to solve the problem. If it can't it doesn't get elected.

How does this stop large amounts of IPv6 IPs from getting elected? As each key tied to a IP would have a different problem, the server would need to solve 65K of these in a 5 minute window. This would require more server resources and it would cost more money, there by reducing return. It would also having the effect of small computers, i.e. Raspberry PI, not being elected right away even if it is the only one trying.

I would also suggest that generating peers do this same calculation but being polled at random to verify all is still good.

I am not as familiar with encryption algorithms as others, so I don't know if there is one that might fit this idea. Maybe all this rambling gave someone another idea that will work.
I know Timekoin is kind of "anti-proof-of-work" in a way, but only as ongoing or unnecessary process :D

I think the idea that some kind of work be done to be elected (which would only need to be done once and not to continue a process forever unnecessarily) is certainly welcome to discussion. The key is to put the burden of work on the peer to be elected and not all the network peers.

The easiest way that comes to mind is using the same encryption we already use. Right now, Timekoin uses 1,536 bit encryption. Every wonder why that was chosen years ago? It was the lowest "high" number we could use and still work "fast" on low end machines. It is still way above the level used by websites, documents, etc. So it was a number like "wow that is insanely high, but why not, it works".

The higher level of bits used creates a lot of work when you scale it up. So for example, a person has an IP address and wants to get elected.

The formula could work like this.

Currently:
I have a server at an IP somewhere on the Internet. Normally, the election request sent out simply says "find me at this IP address and to prove I am there, I have data that can only be unlocked with the public key I sent with this request. When you unlock the data, it is simply my own public key". This way I can't send peers on a wild goose chase to IPs that don't exist or I don't really have a server at. Next, the peer after verifying the reverse crypt string does a random hash poll of both a single foundation hash and a single transaction hash. If all of those are met, the peer is added to the election queue where the normal election process of random selection can take over at the right time.

New Way:
I have a server at an IP somewhere on the Internet (be it IPv4 or IPv6) My election request still says "find me at this IP address" but now the peer can do a different kind of polling. It will think of a random number (say between 0 and 9999999999) and then feed this to the peer that wants to be elected. The peer will take this number and generate both a private key and public key, but on the order some really high bit value. Let's use 4048 for example. The peer that wants to be elected sends back the new public key and uses the new generated 4048 bit private key to generate it's own "original" public key into a 4048 bit encrypted transaction. It gives this data back to the original requesting peer. The peer can quickly and easily plug in that 4048 bit public key, unlock the transaction data inside and see if the original public key is there. If all that matches, the peer is good to queue up for election.

So where is the bottleneck? It is the key generation + plus encryption. The peer that wants to be elected has to burn some CPU time to generate the keys and then encrypt a transaction with them. All the calling peer needs to do is simply decrypt one large transaction set and make sure public key original matches public key it just got, but only once. The "want to be elected" peer would have to keep doing this over and over for every peer that wants to poll it for verification and thus puts all the burden of work for a few minutes on that peer that wants to be elected. So if someone had one server answering 65k IPs, it would require some beefed up specs to deal out hundreds or thousands of peers feeding random numbers to generate one-time-only transaction data for proof and the effect is multiplied as more and more IP try to answer from a single machine. The IP itself could be part of the random number seeding in the beginning so it would not be possible for someone to "cache" responses from a previous IP address. Why can't someone just pre-generate all these keys ahead of time? Well the random number that the peer picks is not known to your server, so unless you want to generate all possible billion-million-trillion key combinations and store them somewhere for reference, it would not work.

A lot of servers do have some optimizations for generating RSA keys quickly, but usually for the low end of it (like 128bit, 256bit, etc). So we can do some testing to see what is a sane value to try. Sure we could ramp it up to 100k bit keys :lol:, but we should probably find a "low" end of the values first to see what performance is like on a Pi vs a modern PC for example.

I also think that IPv4 elections and IPv6 elections should be separate. That way neither is overwhelmed with data that is not useful (IPv4 peer won't care about the election data for IPv6 because it can't even verify it properly and vice-versa) The two election systems can still feed one generation list because everyone is still using 1,536 bit public keys and transactions. The IP fields can still be copied from peer to peer without issues also.
jambo58
Posts: 109
Joined: Mon Mar 18, 2013 4:53 am

Re: IPv6 + IPv4 Co-existing together

Post by jambo58 »

now warmach is right with the point about abundance...

ISPs that ARE offering IPv6 are happy to hand out 20-50 per customer for the price of 1 IPv4 address... So in retrospect if someone had the resources to 1000 IPv6 addresses once these cheap hosting companies start wholesailing them (not too unrealistic) they could easily create a 51% TK takeover just from the one Internet link...


....and i just read your idea about restricting to a block range.. it would be hard to police though as one block may be shared down the same street / suburb for 100s of ISP customers so all of them miss out just because little johhny got in first
warmach
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Re: IPv6 + IPv4 Co-existing together

Post by warmach »

KnightMB wrote: I also think that IPv4 elections and IPv6 elections should be separate. That way neither is overwhelmed with data that is not useful (IPv4 peer won't care about the election data for IPv6 because it can't even verify it properly and vice-versa) The two election systems can still feed one generation list because everyone is still using 1,536 bit public keys and transactions. The IP fields can still be copied from peer to peer without issues also.
The problem with this is that you still need several peers that act as gateways between the v4 and v6 networks transferring transactions, generation requests, etc. Without them, no info will pass between TK nodes on v6 and v6. Either way, there needs to be peers that stand between v4 and v6 to shuttle information.

I would create a new node type, gateway peer. This peer type would have limited "transactional" involvement like super peers. Its primary role would be to route data connections to and from the v4 and v6 networks. I say it routes all traffic. v4 nodes would know the request goes to v6 so it instead connects to a gateway peer and waits for a response. Gateway contacts the v6 and passes response to v4. This would require higher bandwidth and server resources presumably. Along with the crucial role in the entire network, I say their generation be doubled. With it being a higher incentive to run, more should be running which maintains the glue between v4 and v6
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: IPv6 + IPv4 Co-existing together

Post by KnightMB »

I've created a crypto benchmark plugin for the server, you need only download, rename that text file by taking the .txt off the end. Install like any other plugin.

What it can do is let the user set the bits (256, 1024, 4048, etc) and some text to encrypt. When it is run, it will benchmark how long it took to create a key pair, encrypt your string, then decrypt your string again.

This way, it is useful to see how fast systems compare to each other. :geek:
Attachments
cryptobenchmark.php.txt
(4.01 KiB) Downloaded 135 times
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: IPv6 + IPv4 Co-existing together

Post by KnightMB »

jambo58 wrote:now warmach is right with the point about abundance...

ISPs that ARE offering IPv6 are happy to hand out 20-50 per customer for the price of 1 IPv4 address... So in retrospect if someone had the resources to 1000 IPv6 addresses once these cheap hosting companies start wholesailing them (not too unrealistic) they could easily create a 51% TK takeover just from the one Internet link...


....and i just read your idea about restricting to a block range.. it would be hard to police though as one block may be shared down the same street / suburb for 100s of ISP customers so all of them miss out just because little johhny got in first
Good point, so block range restriction would probably not be fair because there is no way to predict how any ISP will allocate them.
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: IPv6 + IPv4 Co-existing together

Post by KnightMB »

warmach wrote:
KnightMB wrote: I also think that IPv4 elections and IPv6 elections should be separate. That way neither is overwhelmed with data that is not useful (IPv4 peer won't care about the election data for IPv6 because it can't even verify it properly and vice-versa) The two election systems can still feed one generation list because everyone is still using 1,536 bit public keys and transactions. The IP fields can still be copied from peer to peer without issues also.
The problem with this is that you still need several peers that act as gateways between the v4 and v6 networks transferring transactions, generation requests, etc. Without them, no info will pass between TK nodes on v4 and v6. Either way, there needs to be peers that stand between v4 and v6 to shuttle information.

I would create a new node type, gateway peer. This peer type would have limited "transactional" involvement like super peers. Its primary role would be to route data connections to and from the v4 and v6 networks. I say it routes all traffic. v4 nodes would know the request goes to v6 so it instead connects to a gateway peer and waits for a response. Gateway contacts the v6 and passes response to v4. This would require higher bandwidth and server resources presumably. Along with the crucial role in the entire network, I say their generation be doubled. With it being a higher incentive to run, more should be running which maintains the glue between v4 and v6
I believe this type of new peer should be able to create more as well, like you said, it is doing double duty between the two networks.

How would you verify that the new gateway peer is actually doing it's job? Perhaps some type of 2 way test, where v4 peer sends a request to a v6 peer and only that v6 can respond. So if the gateway peer returns nothing or the wrong response, one would assume that gateway peer is only pretending, not really doing anything (perhaps to get the double gen bonus for example)
warmach
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Re: IPv6 + IPv4 Co-existing together

Post by warmach »

KnightMB wrote: I believe this type of new peer should be able to create more as well, like you said, it is doing double duty between the two networks.

How would you verify that the new gateway peer is actually doing it's job? Perhaps some type of 2 way test, where v4 peer sends a request to a v6 peer and only that v6 can respond. So if the gateway peer returns nothing or the wrong response, one would assume that gateway peer is only pretending, not really doing anything (perhaps to get the double gen bonus for example)
Makes sense, the v4 already knows that it is routing through the gateway. It would know to check for verification from the v6 that it was received.
Post Reply