I think the question to ask is which came first, the meat-eaters or the plant-eaters? And how many times have meat-eaters evolved into plant-eaters, and vice versa? Maybe humans have ancestors even further back which were also plant-eaters? Could it be that most of the DNA required was already there and just needed a small mutation to become useful again? (There is some discussion as to how much of the DNA is really historical parts that could become active again, and how much is actually responsible for who what we are today.)
These systems probably don't have network access, otherwise they would just read a token and then authenticate against a server, so all you have is log files.
If you are doing it systematically, you are probably travelling through the same place more than once. Each device could remember the most recent transaction number for recently seen cards. If it ever see a card with transaction number repeating or going backwards, it activates whatever alarm mechanism it has.
Card ID and transaction number could be two 64 bit numbers. I guess 1GB of flash storage is probably cheap compared to the price of such a device. With that you could store the 64 million cards most recently seen by the device. Maybe cut that in half due to data structures for efficient access to the data. Even if the device was used once per second, it would still be sufficient storage to cover an entire year.
How are you going to collect the data from presumably non-networked devices in a timely enough manner that you can use that data for card authentication?
How about a sneakernet? Each card could contain space for the accounting data plus additional space for an encrypted version of a dozen of unrelated transactions. Now just get network to a few of the devices for collection.
As you travel around the system you are unknowingly carrying encrypted transaction data from the devices with no network connection to the few devices that do have. As well as carrying receipt acknowledgements back to the devices without network connection. It won't help to wipe these off the card, because you will be wiping somebody else's transactions. Your own forged transactions will be carried back to the network by some random other person using the same device at a later time.
If you want to reduce pollution, focus on your primary energy source, not the backup. A data center probably uses 100 times more energy from the primary source than from the backup.
Once collapsed the particle will no longer interfere with itself if you pass it through e.g. a double slit.
That phenomena is not dependent on entanglement. The self interference requires only a single particle. It doesn't matter if it is or ever was entangled with another particle. AFAIK the self interference requires the particle to be in a superposition of passing through both slits at the same time.
Entanglement is more complicated than just a particle being in a superposition. In fact entanglement is also more complicated than having two particles, which are both in a superposition. If you have two particles each of which are in a superposition, then they can collapse independently to any combination of single states.
Entanglement means the probability distribution of the collapsed states is one that cannot be expressed as just the product of the distributions of each of the particles. The two frequently given examples are either that they are guaranteed to collapse to identical states or that they are guaranteed to collapse to opposite states. But there are other ways they could be entangled.
If we just take the guaranteed to collapse to identical states example, then particle one may have 50% probability of collapsing to state A and 50% for state B. Similarly particle two has 50/50% probability. If you simply multiply, you get 25% for each of the four outcomes. That would be true if they were independently in superpositions. But since the actual probability distribution across those four outcomes is not 25% for each, then they are not entangled. The actual probability distribution would be 50% for A,A 0% for A,B 0% for B,A 50% for B,B.
Entanglement is more than just a probability distribution. But the details about such entanglement beyond the probability distributions is more complicated than what I am able to explain, and some of it, I don't even remember.
Otherwise you'd be claiming the entangled particle is not yet collapsed but you'd know what it will collapse to, which is an impossibility
It is correct that it is impossible to know what the state will collapse to, before it collapses. And that's not what I was saying. The tricky part is how the quantummechanics interacts with relativity.
As either end measures their particle from the pair, the wave function will collapse. But if both do it "at the same time" then it is not well defined, who measured it first. Who was first depends on the inertial system of the observer. One observer will see A measure first causing a collapse and B measuring an already collapsed particle. Another observer will see B measuring first causing a collapse and A measuring an already collapsed particle. But all observers will see A and B performing consistent measurements.
So either party can measure their particle and know that after they have measured, the collapse has happened. But if they don't measure, there is no way of knowing, if the collapse has happened.
If there was a way to find out if the collapse had happened, it would break causality. Instead of both measuring "at the same time" they could do something else "at the same time". A could either measure or not measure, and B could try to find out if A already did measure. But from one observers viewpoint, B would do that before A measured, so B would definitely find that the particle had not yet been measured. But from another observers viewpoint, A would measure before B tried to find out, if the particle had been measured.
The only reason that doesn't violate causality is because you cannot find out if the particle was measured. A having measured knows the collapse has happened, and what B would get if B actually did measure. But A doesn't know if B measured. B has a particle and having not measured doesn't know what the outcome would be. By the time A could communicate the outcome to B, the collapse would definitely have happened.
I am not sure whether the coded message created in step 3. is entangled with Bobs particles, or whether step 3. breaks the entanglement.
It depends on how you do it. It could come out either way. However the only point in using the second method you describe is, that you can achieve entanglement at that point. I just don't know of any application of that, since usually the data you eventually want to transfer securely, are classical bits.
If you just want to protect classical bits, then the more complicated and more fragile method you describe doesn't offer any benefits. An ordinary quantum key exchange will in the end produce the same key at both ends, and that key will consist of classical bits, that can easily be stored by the two parties, until they need to communicate.
Doesn't entanglement also imply faster-than-light communications between the two quantum nodes?
No. It's true that you can have entangled particles far apart and measure the state of both of them at the same time. That does mean you instantaneously know what the other end would read. But that does not imply communication, since you don't have any control over what value comes out. And you can't even find out if the other end was measured or not. In such a situation it doesn't really matter which of the two particles is measured first. Measure particle one first, then the other collapses to a state consistent with the measurement of the first. Measure particle two first, then the first collapses to a state consistent with the measurement of the second. Which of the two happened depends on the viewpoint of the observer.
And actually quantum key exchange does not need entangled particles at all. There are certain optimizations, that could make use of entangled particles. But in plain quantum key exchange, you send a stream of independent particles where the sender knows the state of each particle he sends. The receiver doesn't know the state of the particles as they are received, but may learn something about the state, depending on how they are measured.
I have read of some implementations, that produce a particle in a known state by first producing an entangled pair of particles, and then measuring one of them. By the time the other particle leaves the sender it is no longer part of any entanglement. And the fact that it ever was part of an entanglement is just a minor implementation detail, that doesn't actually impact the protocol.
Either way, it's a matter of months, not years, until ARIN is down to the last/8.
It could end up being more than one year. Two years or more sounds unlikely, unless the IPv6 transition is speeding up a lot. RIPE running out of IPv4 addresses does have the potential to speed up the transition, also in other parts of the world. It doesn't matter if people in Canada can still get IPv4 addresses, if they need to communicate with people in Europe, who cannot.
I am still guessing that ARIN will run out. But three out of five RIRs running out might just be enough to get IPv6 going fast enough that IPv4 usage peaks before LACNIC runs out.
True, you need a special NAT for the ISP end of ds-lite but you don't need to manage private v4 addresses in your acess network. This avoids the risk of address collision with your users private IP addresses
So that means larger entries in the connection table in the NAT? It would need to remember both the client's IPv4 address and the IPv6 address of the client's tunnel endpoint. And it would need to have the NAT tightly integrated with the DS-lite endpoint, as the information that needs to travel between them is more than what fits in an IPv4 header.
Everything taken into account, it still sounds better than two layers of NAT.
I'd be happy if I got an IPv6 address with 81:68:00:81:35 somewhere in it.
You can get one today. Just get a/48 through a tunnel provider. Then if your tunnel prefix was for example 2001:db8:dead::/48, then you can use 2001:db8:dead:81:68:00:81:35 however you like.
Yes, that first graph predicts that ARIN (North America) will be down to the last/8 sometime during the first quarter of 2013
That might actually be a mistake in the graph. Compare the graph of actual consumption and the extrapolation (the fat curve, and the thin line of same colour). I find the extrapolation to match fairly well with data between 2008 and 2011, but not matching all that well in 2012. And the date predicted at the top of the page doesn't say first quarter, rather it says 24th of August 2013.
most of the unadvertised addresses are in legacy allocations with unclear legal status
Unadvertised does not even have to mean unused. It can be in use on internal networks with computers that need access to both the internal addresses and the Internet. Thus you cannot reclaim them without introducing conflicts. And you cannot expect those networks to renumber into RFC1918 addresses, as that can introduce other conflicts. There is a reason why IPv6 did not blindly copy the principles from RFC1918. If you look at RFC 4193 you'll find it actually takes measures to avoid collisions. Achieving the same with IPv4 is just not feasible. Even if you wanted to use some of the reclaimed addresses to introduce new RFC1918-like addresses, you'd increase the consumption while the renumbering is in progress. But that's not going to work either, because you'd have to have such renumbering completed before IANA ran out.
2013 will either be the year the big networks start to put their users behind NAT or it will be the year of IPv6 entering the mainstream.
One does not rule out the other. If any ISP was to deploy CGN without native IPv6, they deserve to go out of business as users migrate to a serious Internet provider.
One final thought: an Internet where every single IPv4 address does not go to waste is probably difficult to achieve for technical reasons.
That's what the HD-ratio is all about. The HD-ratio is a measurement of what percentage of the bits in the address you can efficiently use. It turns out in practice that things tend to go well if the HD-ratio is less than 80%, between 80% and 90% is where you plan how to extent the address space, and if you go above 90% it means your plan failed.
Which reminds me, whatever happened to IPv1, IPv2 and IPv3?
They are mostly forgotten. It is possible to find the version 2 specification on the web. It does differ en some important ways. For example back then the separation between IP and TCP had not yet happened. So the specification is actually called TCP version 2. The IP and TCP fields were not as clearly separated, and the version number was not even the first field in the packet. It is a bit tricky to find out what the version number is when its location depend on the version number. That is probably also the reason it isn't officially allocated in the registry.
I predict, that if there is ever going to be a successor to IPv6, there will be a worry that the version numbers will run out. Thus it will be decided to introduce a variable length version number field to ensure that never runs out. An agreement will only be reached after a heated discussion. The problem is, that people have an aversion against variable length fields in the IP header. And that aversion people have for a good reason. It is OK to change the length of fields between version. And some people will have a hard time understanding, that this means the version field itself can be variable length without problems, because within each version it is a fixed value and thus fixed length.
That's still going to require NAT if they want to use less than one public IPv4 address per user. There may still be use cases for it, but I am not convinced.
I think 4rd sounds more promising. The concept of moving state to the CPE device certainly eliminates a lot of the new problems the other NAT solutions would introduce. I do think the packet conversion that 4rd does is ugly, stupid, pointless, and probably going to cause compatibility problems. Using IPv4 over IPv6 would have been much simpler. But the standard is not finalized, so maybe that can still be fixed. The major problem with 4rd is whether any CPE device will actually support it, by the time it is needed.
You can run a local IPv4 intranet for the legacy systems and only connect to the public internet on IPv6. Of course this requires every web facing server to have IPv6, which still needs a lot of work.
I have a sort of NAT solution that could be put between the LAN and the IPv6 Internet to help during the migration.
And yeah I know what you mean about legacy code in companies...that's a big issue that everyone will have to deal with.
For the past year I have been working on a solution for that. Sort of like NAT, but with a few improvements. With that I can run a network which is IPv4 only or dual stack on the LAN and dual stack or IPv6 only on the WAN side.
And it took us years to sort of work around the problems with NAT in all the protocols, so that things now mostly work behind a NAT...
And it was not a complete success. Look at the large Skype outage a couple of years back. That's the sort of things that happen due to NAT. Also look at some of the IPv6 transitioning mechanisms. 6in4 through a NAT is unreliable in most cases. Even Teredo, which was designed to work through NATs, is probably the least reliable way to do IPv6 tunnels. And then there are all those people suffering from the Stockholm Syndrome and thus thinking NAT is a good idea, and IPv4 is better than IPv6 because with IPv4 you can get NAT.
If we had not had NAT available for IPv4, the transition to IPv6 would have been smoother. And the faster consumption it would have caused, would not have been a problem. It would simply have made companies start earlier and as a result it would have been less work, because the network was smaller and simpler.
There are still people who believe, there are addresses to be reclaimed? Try to extrapolate the consumption in Asia from before IANA ran out. They'd need like 10/8s right now. Who has been hoarding lots of addresses? According to Wikipedia it is the US department of defence. They have 11/8s. I'm sure you think they could do with just one. So reclaiming 10/8s from USDOD and handing them over to APNIC, would be the first step. If you don't think that would fly, then forget about reclaiming.
Besides, reclaiming is not solving the problem. The problem is that the majority of companies didn't want to spend any resources on the upgrade until it was very very urgent. Most have done nothing for the last 10 years. Even if they were able to do nothing for another 10 years, that isn't a long term solution. In retrospect, the invention of NAT is a part of the problem, even if it seemed like a good idea at the time.
And since I'm running a small webserver from home, which I presume will remain IP4 indefinitely, what's the easiest way to tell if somebody with an IP6 address can access it?
If you don't know the answer to that question, then the answer is no. You need to actually update your DNS records for the domain to include an AAAA record with your IPv6 address. Without that record an IPv6 only client will have no way of even trying to reach your domain. So, you need to get an IPv6 address, and then put that IPv6 record in DNS. If your Internet provider doesn't provide IPv6, then you have three options. Use a tunnel (tunnelbroker.net is the one I have the best experience with), switch to a better Internet provider, or wait for your current Internet provider to catch up.
Users who have both IPv4 and IPv6 will be able to reach your website, even if your website only has IPv4. The users, which will experience problems, are those who have only IPv6. There is still a couple of ways ISPs can make those users reach your site, but they involve NAT, which will reduce the reliability. Those NAT solutions come in two flavours. There are the CGN solutions, which are just doing IPv4 and work similar to the typical NAT people have at home, just at a larger scale. The other option is NAT64, where the NAT translates between IPv6 and IPv4.
100% efficiency is unrealistic. Once the HD-ratio reaches 80-90% the administrative overhead and routing overhead becomes problematic. I think IPv4 by now has been pushed over 90%, and the problems are showing. With 32 bit addresses an HD ratio of 90% means we can effectively use about 29 bits. In terms of addresses, IPv4 has about 3.7 billion addresses (once you take into account, that some are reserved). Now raise that to the power of 0.9 to find out how many you can use at a 90% HD ratio. 3700000000^0.9=408678275. So just over 400 million devices at 90% efficiency.
There may be people who tell you, that 90% efficiency would mean 3700000000*0.9. Those who says that, do not understand the problems they are talking about. HD ratio indicates how efficiently the bits in the addresses are used and not the number of addresses themselves. And the HD ratio turns out to be a much better measure to predict what is feasible.
you'd assume that such a preexisting backdoor would've already been found and actively exploited in the wild
Just because you can find a backdoor doesn't mean you can use it. It as not hard to make a backdoor, that requires authentication. The only thing that is hard is to make a backdoor that is both secure and does not look like it was made deliberately.
Slashdot Mirror
I think the question to ask is which came first, the meat-eaters or the plant-eaters? And how many times have meat-eaters evolved into plant-eaters, and vice versa? Maybe humans have ancestors even further back which were also plant-eaters? Could it be that most of the DNA required was already there and just needed a small mutation to become useful again? (There is some discussion as to how much of the DNA is really historical parts that could become active again, and how much is actually responsible for who what we are today.)
If you are doing it systematically, you are probably travelling through the same place more than once. Each device could remember the most recent transaction number for recently seen cards. If it ever see a card with transaction number repeating or going backwards, it activates whatever alarm mechanism it has.
Card ID and transaction number could be two 64 bit numbers. I guess 1GB of flash storage is probably cheap compared to the price of such a device. With that you could store the 64 million cards most recently seen by the device. Maybe cut that in half due to data structures for efficient access to the data. Even if the device was used once per second, it would still be sufficient storage to cover an entire year.
How about a sneakernet? Each card could contain space for the accounting data plus additional space for an encrypted version of a dozen of unrelated transactions. Now just get network to a few of the devices for collection.
As you travel around the system you are unknowingly carrying encrypted transaction data from the devices with no network connection to the few devices that do have. As well as carrying receipt acknowledgements back to the devices without network connection. It won't help to wipe these off the card, because you will be wiping somebody else's transactions. Your own forged transactions will be carried back to the network by some random other person using the same device at a later time.
If you want to reduce pollution, focus on your primary energy source, not the backup. A data center probably uses 100 times more energy from the primary source than from the backup.
Yes.
That phenomena is not dependent on entanglement. The self interference requires only a single particle. It doesn't matter if it is or ever was entangled with another particle. AFAIK the self interference requires the particle to be in a superposition of passing through both slits at the same time.
Entanglement is more complicated than just a particle being in a superposition. In fact entanglement is also more complicated than having two particles, which are both in a superposition. If you have two particles each of which are in a superposition, then they can collapse independently to any combination of single states.
Entanglement means the probability distribution of the collapsed states is one that cannot be expressed as just the product of the distributions of each of the particles. The two frequently given examples are either that they are guaranteed to collapse to identical states or that they are guaranteed to collapse to opposite states. But there are other ways they could be entangled.
If we just take the guaranteed to collapse to identical states example, then particle one may have 50% probability of collapsing to state A and 50% for state B. Similarly particle two has 50/50% probability. If you simply multiply, you get 25% for each of the four outcomes. That would be true if they were independently in superpositions. But since the actual probability distribution across those four outcomes is not 25% for each, then they are not entangled. The actual probability distribution would be 50% for A,A 0% for A,B 0% for B,A 50% for B,B.
Entanglement is more than just a probability distribution. But the details about such entanglement beyond the probability distributions is more complicated than what I am able to explain, and some of it, I don't even remember.
It is correct that it is impossible to know what the state will collapse to, before it collapses. And that's not what I was saying. The tricky part is how the quantummechanics interacts with relativity.
As either end measures their particle from the pair, the wave function will collapse. But if both do it "at the same time" then it is not well defined, who measured it first. Who was first depends on the inertial system of the observer. One observer will see A measure first causing a collapse and B measuring an already collapsed particle. Another observer will see B measuring first causing a collapse and A measuring an already collapsed particle. But all observers will see A and B performing consistent measurements.
So either party can measure their particle and know that after they have measured, the collapse has happened. But if they don't measure, there is no way of knowing, if the collapse has happened.
If there was a way to find out if the collapse had happened, it would break causality. Instead of both measuring "at the same time" they could do something else "at the same time". A could either measure or not measure, and B could try to find out if A already did measure. But from one observers viewpoint, B would do that before A measured, so B would definitely find that the particle had not yet been measured. But from another observers viewpoint, A would measure before B tried to find out, if the particle had been measured.
The only reason that doesn't violate causality is because you cannot find out if the particle was measured. A having measured knows the collapse has happened, and what B would get if B actually did measure. But A doesn't know if B measured. B has a particle and having not measured doesn't know what the outcome would be. By the time A could communicate the outcome to B, the collapse would definitely have happened.
It depends on how you do it. It could come out either way. However the only point in using the second method you describe is, that you can achieve entanglement at that point. I just don't know of any application of that, since usually the data you eventually want to transfer securely, are classical bits.
If you just want to protect classical bits, then the more complicated and more fragile method you describe doesn't offer any benefits. An ordinary quantum key exchange will in the end produce the same key at both ends, and that key will consist of classical bits, that can easily be stored by the two parties, until they need to communicate.
No. It's true that you can have entangled particles far apart and measure the state of both of them at the same time. That does mean you instantaneously know what the other end would read. But that does not imply communication, since you don't have any control over what value comes out. And you can't even find out if the other end was measured or not. In such a situation it doesn't really matter which of the two particles is measured first. Measure particle one first, then the other collapses to a state consistent with the measurement of the first. Measure particle two first, then the first collapses to a state consistent with the measurement of the second. Which of the two happened depends on the viewpoint of the observer.
And actually quantum key exchange does not need entangled particles at all. There are certain optimizations, that could make use of entangled particles. But in plain quantum key exchange, you send a stream of independent particles where the sender knows the state of each particle he sends. The receiver doesn't know the state of the particles as they are received, but may learn something about the state, depending on how they are measured.
I have read of some implementations, that produce a particle in a known state by first producing an entangled pair of particles, and then measuring one of them. By the time the other particle leaves the sender it is no longer part of any entanglement. And the fact that it ever was part of an entanglement is just a minor implementation detail, that doesn't actually impact the protocol.
Interesting proposal. Could it be funded through cutting down the military budget?
It could end up being more than one year. Two years or more sounds unlikely, unless the IPv6 transition is speeding up a lot. RIPE running out of IPv4 addresses does have the potential to speed up the transition, also in other parts of the world. It doesn't matter if people in Canada can still get IPv4 addresses, if they need to communicate with people in Europe, who cannot.
I am still guessing that ARIN will run out. But three out of five RIRs running out might just be enough to get IPv6 going fast enough that IPv4 usage peaks before LACNIC runs out.
So that means larger entries in the connection table in the NAT? It would need to remember both the client's IPv4 address and the IPv6 address of the client's tunnel endpoint. And it would need to have the NAT tightly integrated with the DS-lite endpoint, as the information that needs to travel between them is more than what fits in an IPv4 header.
Everything taken into account, it still sounds better than two layers of NAT.
You can get one today. Just get a /48 through a tunnel provider. Then if your tunnel prefix was for example 2001:db8:dead::/48, then you can use 2001:db8:dead:81:68:00:81:35 however you like.
That might actually be a mistake in the graph. Compare the graph of actual consumption and the extrapolation (the fat curve, and the thin line of same colour). I find the extrapolation to match fairly well with data between 2008 and 2011, but not matching all that well in 2012. And the date predicted at the top of the page doesn't say first quarter, rather it says 24th of August 2013.
Unadvertised does not even have to mean unused. It can be in use on internal networks with computers that need access to both the internal addresses and the Internet. Thus you cannot reclaim them without introducing conflicts. And you cannot expect those networks to renumber into RFC1918 addresses, as that can introduce other conflicts. There is a reason why IPv6 did not blindly copy the principles from RFC1918. If you look at RFC 4193 you'll find it actually takes measures to avoid collisions. Achieving the same with IPv4 is just not feasible. Even if you wanted to use some of the reclaimed addresses to introduce new RFC1918-like addresses, you'd increase the consumption while the renumbering is in progress. But that's not going to work either, because you'd have to have such renumbering completed before IANA ran out.
One does not rule out the other. If any ISP was to deploy CGN without native IPv6, they deserve to go out of business as users migrate to a serious Internet provider.
That's what the HD-ratio is all about. The HD-ratio is a measurement of what percentage of the bits in the address you can efficiently use. It turns out in practice that things tend to go well if the HD-ratio is less than 80%, between 80% and 90% is where you plan how to extent the address space, and if you go above 90% it means your plan failed.
They are mostly forgotten. It is possible to find the version 2 specification on the web. It does differ en some important ways. For example back then the separation between IP and TCP had not yet happened. So the specification is actually called TCP version 2. The IP and TCP fields were not as clearly separated, and the version number was not even the first field in the packet. It is a bit tricky to find out what the version number is when its location depend on the version number. That is probably also the reason it isn't officially allocated in the registry.
I predict, that if there is ever going to be a successor to IPv6, there will be a worry that the version numbers will run out. Thus it will be decided to introduce a variable length version number field to ensure that never runs out. An agreement will only be reached after a heated discussion. The problem is, that people have an aversion against variable length fields in the IP header. And that aversion people have for a good reason. It is OK to change the length of fields between version. And some people will have a hard time understanding, that this means the version field itself can be variable length without problems, because within each version it is a fixed value and thus fixed length.
In reality version number 9 is actually assigned to the TUBA protocol.
That's still going to require NAT if they want to use less than one public IPv4 address per user. There may still be use cases for it, but I am not convinced.
I think 4rd sounds more promising. The concept of moving state to the CPE device certainly eliminates a lot of the new problems the other NAT solutions would introduce. I do think the packet conversion that 4rd does is ugly, stupid, pointless, and probably going to cause compatibility problems. Using IPv4 over IPv6 would have been much simpler. But the standard is not finalized, so maybe that can still be fixed. The major problem with 4rd is whether any CPE device will actually support it, by the time it is needed.
I have a sort of NAT solution that could be put between the LAN and the IPv6 Internet to help during the migration.
For the past year I have been working on a solution for that. Sort of like NAT, but with a few improvements. With that I can run a network which is IPv4 only or dual stack on the LAN and dual stack or IPv6 only on the WAN side.
And it was not a complete success. Look at the large Skype outage a couple of years back. That's the sort of things that happen due to NAT. Also look at some of the IPv6 transitioning mechanisms. 6in4 through a NAT is unreliable in most cases. Even Teredo, which was designed to work through NATs, is probably the least reliable way to do IPv6 tunnels. And then there are all those people suffering from the Stockholm Syndrome and thus thinking NAT is a good idea, and IPv4 is better than IPv6 because with IPv4 you can get NAT.
If we had not had NAT available for IPv4, the transition to IPv6 would have been smoother. And the faster consumption it would have caused, would not have been a problem. It would simply have made companies start earlier and as a result it would have been less work, because the network was smaller and simpler.
There are still people who believe, there are addresses to be reclaimed? Try to extrapolate the consumption in Asia from before IANA ran out. They'd need like 10 /8s right now. Who has been hoarding lots of addresses? According to Wikipedia it is the US department of defence. They have 11 /8s. I'm sure you think they could do with just one. So reclaiming 10 /8s from USDOD and handing them over to APNIC, would be the first step. If you don't think that would fly, then forget about reclaiming.
Besides, reclaiming is not solving the problem. The problem is that the majority of companies didn't want to spend any resources on the upgrade until it was very very urgent. Most have done nothing for the last 10 years. Even if they were able to do nothing for another 10 years, that isn't a long term solution. In retrospect, the invention of NAT is a part of the problem, even if it seemed like a good idea at the time.
If you don't know the answer to that question, then the answer is no. You need to actually update your DNS records for the domain to include an AAAA record with your IPv6 address. Without that record an IPv6 only client will have no way of even trying to reach your domain. So, you need to get an IPv6 address, and then put that IPv6 record in DNS. If your Internet provider doesn't provide IPv6, then you have three options. Use a tunnel (tunnelbroker.net is the one I have the best experience with), switch to a better Internet provider, or wait for your current Internet provider to catch up.
Users who have both IPv4 and IPv6 will be able to reach your website, even if your website only has IPv4. The users, which will experience problems, are those who have only IPv6. There is still a couple of ways ISPs can make those users reach your site, but they involve NAT, which will reduce the reliability. Those NAT solutions come in two flavours. There are the CGN solutions, which are just doing IPv4 and work similar to the typical NAT people have at home, just at a larger scale. The other option is NAT64, where the NAT translates between IPv6 and IPv4.
100% efficiency is unrealistic. Once the HD-ratio reaches 80-90% the administrative overhead and routing overhead becomes problematic. I think IPv4 by now has been pushed over 90%, and the problems are showing. With 32 bit addresses an HD ratio of 90% means we can effectively use about 29 bits. In terms of addresses, IPv4 has about 3.7 billion addresses (once you take into account, that some are reserved). Now raise that to the power of 0.9 to find out how many you can use at a 90% HD ratio. 3700000000^0.9=408678275. So just over 400 million devices at 90% efficiency.
There may be people who tell you, that 90% efficiency would mean 3700000000*0.9. Those who says that, do not understand the problems they are talking about. HD ratio indicates how efficiently the bits in the addresses are used and not the number of addresses themselves. And the HD ratio turns out to be a much better measure to predict what is feasible.
They switched to measure the width of the image instead of the height? Did they think 3k didn't sound impressive enough and then named it 4k instead?
Just because you can find a backdoor doesn't mean you can use it. It as not hard to make a backdoor, that requires authentication. The only thing that is hard is to make a backdoor that is both secure and does not look like it was made deliberately.
But then they have incentives to ramp up production.