I don't have a good feel for the numbers involved here. Things like this always report: "We are out!... only 4,000,000 or so addressed remaining!" Four million sounds like a lot to me. Some number of the IP addresses that are counted as gone are also still unused.
Can someone give me some idea of the situation with numbers that are easier to understand? Can we still limp through for a few years, or is this actually the crisis point?
It does seem a bit anti-climactic. "We're out! We only have a /10 remaining, and we'll only be handing out /24 - /22 allocations!". Which does seem an awful lot like "flowing freely" (I'd be happy with just a personal /27 myself) until you put it in context with those early non-aggregable /24 allocations in 192/8 being generally viewed as a mistake for router memory, and the subsequent move to only give out portable allocations to larger service providers.
IMHO all of the IPv4 exhaustion articles are basically scaremongering attempting drive adoption ahead of the real pressing need. Which isn't the worst goal, as it encourages people to become familiar (have YOU setup a tunnel from he.net, sixxs, or with 6to4/miredo and started playing around?). But I suspect we'll be hearing variations on the same "we're out! (but not really out)" story for the next 5 years at least.
But besides a larger address space, v6 doesn't really give new features (besides plausible deniability of what constitutes a host address) and just adds to packet overhead. So the only compelling reason will be the ever growing number of endpoints that are v6 only, and behind NAT (from businesses who decide that providing v4 addresses to new customers by default is too expensive). Other businesses wanting to better serve/track those customers (avoiding NAT64 etc) will then finally have a real reason to treat IPv6 as a first class concern.
Experience and familiarity, mainly. When Linode enabled native v6, setting it up was a no-brainer. I'd also be comfortable getting a v6-only server if it fit my need.
Also it's a nice backup link for NATted WAN machines in case tinc/autossh/etc accidentally goes down.
> Since it began operating in 2002, the organization has assigned more than 182 million IPv4 addresses throughout Latin America and the Caribbean.
182 million addresses in 12 years is roughly 15 million addresses per year, or 1.25 million addresses per month. At that rate 4 million addresses would last maybe 3 months.
Yes, but they could have issued 30m each to 5 different ISPs that are only half way through their allotment. If I want a fixed IP at my house or my school I don't get it from the internet address registry, I get it from Boston University or RCN.
I wonder what will happen when the pool nears exhaustion globally, not just in Latin America and the Caribbean. A few scenarios come to mind, would love to hear more scenarios/insights:
1. The governments of the world push IPv6 legislation. Everyone invests the resources needed to migrate in a few years, overall everyone's pretty OK with this.
2. Carrier-grade NAT becomes much more widespread. People who need a public IP (mostly p2p users, I guess) pay more for that. Again, overall everyone's pretty happy.
3. Gradual, failover-friendly solutions are deployed. The network becomes fragmented, this plays out like IE6. After a few years, most of the people who matter get tired of this, pull support for IPv4.
The US is at 8% IPv6, I think that's enough of a base of early adopters that I could believe as soon as there was some actual pain involved with v4 we'd see some fast changeover.
In other words, I believe the limiting factor on v6 adoption is no longer technical or interop, instead it's lack of problems with v4.
I have an IPv6 enabled home internet connection, and can connect to IPv6 enabled websites with it, and there's no 6-to-4 conversion or having an OS level tunnel to Hurricane Electric.
What are the practical consumer-level implications of this? My understanding is that every internet-enabled device needs a unique IP address. If there are no more unique addresses, can no more devices connect to the internet in this region?
Excuse me if I'm being dense, but why does every internet enabled device need a unique IP? I thought the service providers had unique IPs and we just made our requests through them.
This is where many people can share one IP. But NAT has problems - you can make connections, but you can't accept connections from elsewhere. And it sometimes breaks particular applications.
The only real solution is widespread IPv6 adoption, which seems depressingly unlikely right now.
> The only real solution is widespread IPv6 adoption, which seems depressingly unlikely right now
Slow maybe, but unlikely? No, not really. IPv6 internet has grown fairly steadily (and afaik at a growing pace) since its inception and I don't see any reason why that trend would slow down or stop. There hasn't been any real opposition or alternatives for IPv6, mostly just indifference and ignorance. More and more new gear supporting IPv6 natively out of the box is being deployed on the field, reasons for not enabling it are dwindling. XP just got deprecated, most end-user stuff probably already supports IPv6. Old network engineers retire someday, and new generation is well aware of the issue at hand.
> Most homes and even many businesses probably don't need a unique IP.
The answer is then not IP but port scarcity. Depending on home activity, I have 100~400 sessions open on my router. This means as an ISP you can only have so much customers (10~50?) behind a single IP and assume reliable operation. With the growth in number of devices and online services, this is only bound to grow and is thus not a viable solution, even short term.
Yes but those sessions can all share a single source port, assuming they are all to different destination IPs/ports. (TCP session identity is determined by both the source and destination ports and IPs.)
IIRC most web browsers do not open more than 2-4 simultaneous connections to a given server. So an allocation of ports an order of magnitude larger than that should suffice for a typical home user.
As in what is (unfortunately) actually being used. ISP's have taken so long to even begin to look at moving to IPv6 that stopgaps like CGN have to be put in place. Then, of course, why break what is working so IPv6 is put off even further.
CGN has a real cost. ISPs like T-Mobile and Time Warner have found that IPv6+CGN (either DS-Lite or 464) is cheaper than CGN alone because 50% of traffic can bypass the CGN.
That's actually exactly what this is. Currently coal is the cheapest electricity you can get. However, as the price of coal, oil, and natural gas goes up, and as the price of cleaner alternatives (through research, scale, etc.) goes down, we will eventually arrive at using much cleaner energy. The big problem with this is that those two prices aren't moving fast enough to avoid a global climate disaster we will be facing within several decades.
That's why the current incarnation of Capitalism (finance-based, quarterly-results oriented) is broken beyond repair. Kicking the can down the road sound like a hell of an option if you can be relatively sure there will be a different guy doing all the eventual cleanup.
Sort of. IPv6 adoption is a matter of supply/demand economics. The supply of IPv4 is quickly approaching zero, while the demand is rising fast. At the same time the supply if IPv6 is effectively unlimited, but the demand is not there. At some point, the supply of IPv4 will go so low that its cost will suddenly jump. The cost of IPv6 deployment is still too high (mostly in human labor to set it up, and somewhat in equipment costs since some large legacy networks are not IPv6-ready). However, that jump in the IPv4 cost will price IPv6 deployment at a point much cheaper than alternatives (IPv4 large scale NAT or other workarounds). That's when we'll see a huge jump in IPv6 deployment.
I think the next big step for ISP's is to provide IPv6-only native service to their clients, and add IPv6-to-IPv4 gateways to allow access to IPv4-only internet.
> I think the next big step for ISP's is to provide IPv6-only native service to their clients, and add IPv6-to-IPv4 gateways to allow access to IPv4-only internet
Edit: for my money, NAT64 + DNS64 would get us 90% of the way there. OS support for pseudo-IPv4 would really fix this 100%: if the application wants to talk IPv4, the OS would transparently translate it into an IPv6 address in the 64:ff9b::/96 address prefix.
Take a look at https://github.com/ayourtch/nat46 - I've coded it primarily for OpenWRT (so it requires forwarding), but the core portion is usable in userland as well - so I have this crude hack (https://github.com/ayourtch/example-nat46/) to get something-of-a-CLAT running on OS X with zero changes to the nat46-core.[ch] code - I literally sync them between the two repos periodically.
Why can't the handset itself do the DS-lite IPv4 NAT/encapsulation, or why is 464XLAT easier to do on handset than DS-lite?
Yeah, I've made exactly the same argument. As you found, there's a lot of history here. As I remember it, T-Mobile was originally pitching NAT64 because it required no support on the phone at all and DS-Lite would require the phone to do encapsulation. People pointed out that DS-Lite supports v4-only apps and NAT64 does not, but it seems like T-Mobile chose not to hear that argument. Then, having already committed to the NAT64 route, they added a stateless NAT46 agent on the phone to fix v4-only apps.
I think that agreeing on a standard is more valuable than continually iterating towards perfection, so I wish the industry had just declared DS-Lite "good enough" and stopped, but now we have this menagerie of transition schemes.
