11 ms·
Whatever happened to the IPv4 address crisis?
- gtirloni 13y agoI have noticed a change in approach, even if unconscious. Instead of predicting doom, they have started to celebrate small victories (like Google IPv6 traffic passing 3%). I think that's natural when the size of this undertaking is so great. Unfortunately IPv6 adoption is not a matter of just providing access lanes to this wonderful new technology. IP permeates too much of the infrastructure, tooling, etc. How could it not? Some companies might find the cost/ROI of working around IPv4 limited address space to be less than migrating to IPv6.
- einhverfr 13y agoThere are also tons of little things. Here in Indonesia, I know my ISP (FirstMedia) runs IPv6 internally on some things. Their web sites are available over IPv6. But I can't connect from home over IPv6. Supposedly the consumer hardware on my side supports IPv6 but it doesn't do so very well and I haven't bothered trying directly through the cable modem yet.
- agwa 13y agoThis is an extremely US-centric article. ARIN was never in as dire straits as the other RIRs. In Europe and Asia the situation is much worse. For example, lack of IPv4 addresses delayed DigitalOcean's growth in Amsterdam, and carrier-grade NAT is already being used by some consumer ISPs in Europe and Asia.
- sp332 13y agoThe article also ignores the fact that running dual-stack (like Comcast) requires just as many IPv4 addresses as before. Even after ISPs get IPv6 working flawlessly, their customers still need to access IPv4 websites, and that means CGNAT or some messy kind of tunneling will still be necessary.
- IgorPartola 13y agoThen don't run dual stack. Run native IPv6 and NAT64/DNS64. Or in DO's case make IPv4 access optional for smaller droplets and charge $1/month extra for it. In reality things like DB servers or backend app servers don't need public IPv4 addresses, and this would speed up IPv6 adoption considerably.
- peterwwillis 13y agoCustomer applications which require IPv4 and haven't been upgraded to support IPv6 still need a v4 address, and customers probably have to support their own clients that only use v4. You still have to ship the customer both L3 protocols. So the carrier would at least need to ship a NAT'd v4 address; v6-only would basically frustrate/anger/alienate a whole lot of customers, which is dumb from a making-money-with-my-company perspective. In reality you can't just decide for your customers that they do or don't need something - you have to ask them what they need (if you want to continue having customers). Nobody's going to re-engineer all their shit to support your wonky network if they can just go to another company that provides them what they need.
- IgorPartola 13y agoNo. You provide the best service to your customers for the best price. For DO's case, default to IPv6 and charge extra for each IPv4 address used. Currently, they charge $5/month for their cheapest droplet. Change that to $4/month and charge an extra $1/month for an IPv4 address. This way if my setup is more complex than a single droplet running everything, I can save some money on VPS's that don't need public IPv4 addresses (the database servers, application servers, etc.) For Comcast and the like, once again give me the option to either do NAT64 or a full dual stack. As a regular consumer I probably won't care. As a gamer or a developer I might. The IPv6 transition is going to happen sooner or later. Either you are going to make it painless for your customers by providing IPv6 early and using strategies to make the transition to IPv6-only smoother or you are going to make your customers suffer.
- 13y ago
- diminoten 13y agoARIN requires the demonstration of need before it allocates space. RIPE does not, it's just first come, first serve. I'm not sure about APNIC or LACNIC, and since AFRINIC is modeled heavily off of ARIN, I think they require need too, but things are so fucked over there I have no idea if that policy transferred.
- neals 13y agoA peak into the future of peak-oil. Let's see how this plays out and learn from it.
- Zikes 13y agoIf I could NAT my gas tank the world would be a very different place.
- kbutler 13y agoIf only the available IPv4 address space were growing as rapidly as the available oil... 1960s: Peak oil 1995 @12.5 billion barrels/year. Today: Peak oil 2035, current production is over 2.5X the previously predicted peak. There's also an increasing expectation that rather than "peak oil" being a supply-side constraint, it will be a demand-side constraint as more efficient use and alternative energy sources become available - that is, we will never "run out". http://www.sciencedaily.com/releases/2013/07/130710114436.htm http://www.sciencedaily.com/releases/2013/07/130710114436.ht...
- baq 13y agopeak oil is really about EROI; we'll never run out, but there are reservoirs that aren't going to be produced because it doesn't make economic/energetic sense to do so.
- angersock 13y agoWhat...I don't even...what does that even mean? Don't be silly.
- chimeracoder 13y agoThis article is focused on the US, a country which was never really going to feel the brunt of the IPv4 crunch. For an example of a real victim, look at Qatar, a country which only has a single IP address for the entire country (everyone sits behind a NAT): https://en.wikinews.org/wiki/Qatari_proxy_IP_address_temporarily_blocked_on_Wikipedia https://en.wikinews.org/wiki/Qatari_proxy_IP_address_tempora... [0] Whenever someone from Qatar decides to vandalize Wikipedia, Wikipedia is forced (temporarily) to block the entire country from accessing Wikipedia. This has an adverse impact on the rest of the country. Non-Qatari Wikipedia users also suffer, because Wikipedia makes those blocks very temporary (since they are effectively shutting off an entire country), which makes it easy for those vandals to regain access to Wikipedia quickly. [0] This sad state of affairs is not solely due to IPv4 (incompetent/apathetic network administrators are also at fault), but it's a contributing factor.
- deleted 13y ago[deleted]
- shawabawa3 13y ago> Whenever someone from Qatar decides to vandalize Wikipedia, Wikipedia is forced (temporarily) to block the entire country from accessing Wikipedia Can't they just block IPs from editing? Seems like that would solve the problem
- insertnickname 13y agoThat's what they do. But this still prevents everyone in Qatar (who does not have an IP ban exception) from editing.
- Jach 13y agoHow many of Qatar's 2 million people use the internet, and how many of them pay for a VPN service? (https://www.bestvpn.com/blog/6715/5-best-vpns-for-qatar/ https://www.bestvpn.com/blog/6715/5-best-vpns-for-qatar/ indicates there are a lot of internet cafes whose owners are using VPNs and passing on the access to customers.) It sounds to me like a person from Qatar wouldn't have a problem editing wiki if they wanted to, nor a vandal from vandalizing if they wanted to...
- 72deluxe 13y agoNot a comment on the article, but IPv6 adoption relies on significant upgrades of existing hardware. Think of the size of the lookup table that a new bit of hardware has to be able to look up against and store compared to IPv4. Significantly more processing power is required, particularly if the hardware is a device that does inspection of some sort, even if basic! It isn't just a case of switching end machines to use IPv6.
- huxley 13y agoIs that really that significant a problem? Moore's Law should have dealt with memory and processing power issues severalfold in the time since IPv6 rollout was called for. It strikes me that it's more likely a lack of strategic investment in infrastructure.
- jauer 13y agoGenerally speaking even now you can't do route lookups fast enough to handle provider traffic volume with current general-purpose CPUs (although it seems to be on the edge of possible). Instead routes are loaded into special ASICs (TCAM: http://en.wikipedia.org/wiki/Content-addressable_memory http://en.wikipedia.org/wiki/Content-addressable_memory) that seem to not follow Moore's Law, be it due to low volume or other limitations (perhaps not technical). Routers using TCAM seem to max out between 1-2M routes (divided across v4, v6, MPLS, etc). More recent routers are using slightly more flexible processors so there's some hope but the router product cycle is fairly lethargic.
- lmm 13y agoIPv6 makes the global routing table much smaller (because there's enough space for the subnets to be logical parts of the network, rather than squeezing as many addresses in as possible), so the core routers for the IPv6 internet ought to need less hardware than the IPv4 ones.
- 72deluxe 13y agoAh thanks! Does this mean that the end routers can be simpler too, or do they still need significant processing power?
- spindritf 13y agoIt's here. IP addresses are costing more and providers are less generous with them. It used to be common to get a handful with a dedicated server, now you get one or two. I have a friend who runs a small low-cost minecraft hosting. He stopped giving his customers dedicated IPs at all. They get a range of ports and a hostname with appropriate srv records added. That's the other result, technical work-arounds. You can point to a particular service on a particular port with an srv record, host multiple websites on one IP, even SSL-enabled ones with SNI, etc.
- davidw 13y agoThis is basically how it should work. Prices rise until alternatives become worth thinking about.
- baq 13y agothat's the economic way of thinking. the engineering way would be to fix the artificial scarcity by implementing a technically superior solution.
- davidw 13y agoBut the 'superior solution' is... well, 'sort of', from the economic point of view in this case: it has costs that are, for some people, higher than those of the alternative.
- adventured 13y agoThere is always an endless line of other things to deal with in both the economic and engineering realms. Squeaky wheels tend to get the attention in both. When the IP situation causes enough discomfort, there will be an avalanche transition, and probably not a moment sooner.
- baq 13y agoi agree completely, to my great distaste.
- jfasi 13y ago> The day of reckoning still looms – it’s just been pushed out as the major Internet players have developed ingenious ways to stretch those available numbers. To me, this indicates something either broken about IPv6 or a lessened severity of the IPv4 problem: If it's better to apply bandaids to IPv4 than to roll out IPv6, then either IPv6 is not easy and flexible enough to be a viable alternative, or the problems faced by IPv4 are not as intractable as was suggested.
- rqebmm 13y agoIt's both. IPv6 is not an easy migration, and people already have decades of experience squeezing the most they can out of IPv4, so the short-term solutions have just been to just squeeze IPv4 a little harder until everyone working on IPv6 gets it fully operational.
- sschueller 13y agoDoesn't the US defence department hold a ridiculous amount of the address space? What would it take for them to give some of that up?
- thematt 13y agoWhy bother? The switch needs to be made eventually, so why kick the can down the road?
- sschueller 13y agoBecause places like Qatar are suffering as a result of the US and others dragging their feet.
- diminoten 13y agohttp://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks http://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addres... Looks like they've got more than one /8. ARIN has been trying to get the holders of legacy space to sign new SLAs and to get them to give over some of the space, but considering the IP address market, why not just sell the space instead?
- lmm 13y agoThe growth in internet-connected devices is exponential. By the time the last blocks were issued they were going out at 1 class A (i.e. 1/256 of the entire IPv4 address space) every month. So it's not worth the effort to recover existing addresses.
- nnieiss 13y agonat
- jokoon 13y agostill wonder how much of the internet is not IPV6 compatible.
- einhverfr 13y agoQuite a bit actually. Our experience at Efficito may be interesting. We previously had backups located in Denver and production servers located in Europe, both through the same hosting provider (FDC). We never could get IPv6 working flawlessly (high packet loss, etc) intercontinentally and the problems weren't on our side. We moved to Hetzner and have our systems spread throughout their datacenters (backups, and some backend systems on one side, customer data on the other) and have had absolutely no problems with ipv6. What this tells me is that somewhere between the Czech Republic and Colorado there are routers which although they sort of support ipv6 don't do so in a usable way.
- MichaelGG 13y agoWere they using HE as an ISP? I ask because HE makes a big deal of IPv6, and we regularly get packet loss between LA and Denver on IPv4. Way overloaded. FDC says they use Cogent -- Cogent used to be not-so-great (they're better nowadays).
- einhverfr 13y agoWe didn't look into it too closely. mtr would have told us but we didn't go into it. They did tell us that if we upgraded our servers and switched data centers, we would get better peering. But we opted at that point to move off and go with Hetzner instead because we weren't at a point at the time when their higher end servers would have made sense.
- js2 13y agohttp://cr.yp.to/djbdns/ipv6mess.html http://cr.yp.to/djbdns/ipv6mess.html (circa 2003)
- gtirloni 13y agoThanks, very interesting read. While reading his argument about all the extensions that need to be done everywhere, I thought about this: since many protocols/etc have to be reworked, will that lead to consolidations (since some protocols will be left behind)? Can we say that currently the IPv6 Internet is a place (almost) free of legacy stuff?
- FedRegister 13y agoThat was always a question I had in the back of my mind. We have this huge address space. Why not reserve a single prefix that means "look at the lower 32-bits of this address and use it as an IPv4 address"?
- Consultant32452 13y agoMore than likely the people in charge will not act pre-emptively by upgrading to IPv6 during the normal upgrade/replacement cycle of their network hardware. Instead, they will wait until there's a real crisis so they can ask the government to fund their next hardware upgrade.
- walshemj 13y agoThe main problem the 20 years ago with the take off of the internet as a mass networking standard it was blindingly obvious that ipv6 was deeply flawed - IPv6 should have been taken out behind the woodshed back then and ipv7 or 8 done properly. When I looked at it 19 or the 20 involved in the RFC for ipv6 where from academia plus one guy from bell labs. Migration and Interpenetration should have been the highest priority in the design on a replacement for ip4
- dasil003 13y agoMaybe. Or maybe we will suffer tremendous amount of pain for some period of years after which we will have a much brighter future as opposed to an ipv7 that made too many concessions and left us with a mess that would be politically impossible to ever fix.
- walshemj 13y agomm yes or maybe know when to let a flawed standard die when it is over taken by events. Even 20 years ago the Internet was obviously not going to be able go on as before where you could make major changes over a long weekend during the summer at the few core university's that where the the internet. That is why ipv6 should have been replaced.
- amaranth 13y agoReplaced with what? IPv6 has problems, sure, but the main problem is that IPv4 and IPv6 aren't compatible with each other. You're going to have that problem with any other replacement for IPv4 as well.
- walshemj 13y agoBecause they designed ipv6 as a alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
- sopooneo 13y ago
- damm 13y agoThe problem is the majority of the companies who are stalling the IPv6 upgrade are in the US; which as chimeracoder stated is not going to feel the crunch as bad as other countries. People are very short sighted for one; and for two are afraid of 'breaking' what works. I have even setup organizations with native IPv6 addresses (no tunnel) to watch them fear and lament it. There's a thousand excuses and people need to look upon this as an opportunity; to up their skill set and mentor a new generation.
- trout 13y agoHere's a report you can see the current projects with a bit of history: http://www.potaroo.net/tools/ipv4/index.html http://www.potaroo.net/tools/ipv4/index.html The potaroo site by Geoff Huston has been running for over a decade tracking address consumption. Some history for ARIN consumption predictions: Feb 2014 predicts Mar 2015. Oct 2013 predicts Jan 2015 [0]. Apr 2013 predicts Apr 2014 [1]. Nov 2012 predicts Sept 2013 [2]. Sep 2012 - RIPE out of addresses. Apr 2011 - APNIC out of addresses. Feb 2011 - IANA out of addresses. Dec 2011 predicts July 2013 [3]. July 2011 predicts Nov 2013 [4]. Prior to this it's simply about IANA calculations, though with some algebra some dates could be extracted. As well, here's a Cisco article from 2005 describing some of the painful parts of trying to predict the address consumption (where they guess 2016 in 2005): http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.html http://www.cisco.com/web/about/ac123/ac147/archived_issues/i... [0] http://web.archive.org/web/20111227105916/http://www.potaroo.net/tools/ipv4/index.html http://web.archive.org/web/20111227105916/http://www.potaroo... [1] http://web.archive.org/web/20111227105916/http://www.potaroo.net/tools/ipv4/index.html http://web.archive.org/web/20111227105916/http://www.potaroo... [2] http://web.archive.org/web/20121122120407/http://www.potaroo.net/tools/ipv4/index.html http://web.archive.org/web/20121122120407/http://www.potaroo... [3] http://web.archive.org/web/20111227105916/http://www.potaroo.net/tools/ipv4/index.html http://web.archive.org/web/20111227105916/http://www.potaroo... [4] http://web.archive.org/web/20110709090704/http://www.potaroo.net/tools/ipv4/index.html http://web.archive.org/web/20110709090704/http://www.potaroo...
- einhverfr 13y agoTrying to plot this it means that the crunch will probably really hit increasingly hard from about 2015 through 2016. You go from predicting two years out to one year out (two years later). These aren't brick walls but the shortage is already being felt. I know that at Efficito, one of the reasons we switched hosting providers was that we couldn't get ipv6 connections working flawlessly to our backup connections before (meaning more ipv4 space required). I don't think we will ever hit exhaustion per se.
- todd8 13y agoThis is an interesting article, but it contains some rather surprising innumeracy in its cavalier comparison of 2^128 to the number of grains of sand in the earths crust. 2^128 is an enormous number, roughly 3.4e38: 2**128 = 3.4 * 10**38 grains of sand to one mile down [1] = 5.1 * 10**26 stars in the observable universe [2] = 7.0 * 10**22 estimated grains of sand [2] = 7.5 * 10**18 This means that every star can have 100 planets (equals 7e24 planets) each with 50 trillion IPv6 addresses. [1] [http://www.teracomtraining.com/tutorials/teracom-tutorial-IPv6.htm http://www.teracomtraining.com/tutorials/teracom-tutorial-IP...] [2] [http://www.npr.org/blogs/krulwich/2012/09/17/161096233/which-is-greater-the-number-of-sand-grains-on-earth-or-stars-in-the-sky http://www.npr.org/blogs/krulwich/2012/09/17/161096233/which...]
- exabrial 13y agoTruth is NAT works just fine for the vast majority of cases, and makes a layered (IE not-eggs-all-in-one-basket) approach to security much simpler. The real problem is routing table size with BGP. As we continue to divide the internet into smaller routable blocks, this is requiring an exponential amount of memory in BGP routers. Currently, the global BGP table requires around 256mb of RAM. IPv6 makes this problem 4 times worse. IPv6 is a failure, we don't actually _need_ everything to have a publicly routable address. There were only two real problems with IPv4: wasted space on legacy headers nobody uses, and NAT traversal. IETF thumbed their noses as NAT (not-invented-here syndrome) and instead of solving real problems using a pave-the-cowpaths-approach, they opted to design something that nobody has a real use for. Anyway, I'm hoping a set of brilliant engineers comes forward to invent IPv5, where we still use 32 bit public address to be backward compatible with today's routing equipment, but uses some brilliant hack re-using unused IPv4 headers to allow direct address through a NAT. Flame away.
- elric1v 13y agoNo need to flame, we will just let yoau re-read this in a few years...
- trout 13y agoNot a flame - your perspective is very typical for people that don't have a lot of experience with networking past the host or server level. (Very little experience with networking in the core, provider, or putting together network services architecture). 1. In theory the routing table with IPv6 can be smaller. The address design should be hierarchical, which means you should be able to have much fewer routes. It's too early to tell if this is actually true or not, but the addresses themselves are 4x larger - which isn't going to be the determining factor in routing table size. 2. Not everything needs to be publically routable, true. IPv6 has the idea of link local and autonomous system local addressing which IPv4 doesn't have. The RFC 1918 block was used instead. But think for a second - there's only 4 billion addresses (less when you count bogons and multicast ranges), and it's only a matter of time until those are taken up. So we can choose to do it now, 2 years from now, or 5 years from now, but devices are growing faster than ever and it's only a function of time. 3. NAT is not a security feature, is not good for the internet, and the sunk costs spent building an ALG for every protocol to work around it is a significant development sinkhole. It's a workaround often masqueraded as security, and does cause many application problems. It's just not normally the application developers that have to fix those problems - it's the network and security teams. 4. IPv6 was created in the late 90's. People have been waiting for brilliance to supercede IPv6 for a while. I'll admit it's not the easiest, but there are a certain set of problems you have when you expand the address space. 5. I'm familiar with all the IPv4 headers, and nearly all of them are used. ID is used for packet identification, particularly through network services, DSCP is used heavily, DF and other flags are used - they're just obscure. If you look at IPv6 those same headers are basically recreated, though with slightly different names. The ones that aren't included are addressable through the extension headers. So, yeah. That's another perspective that may help you understand why IPv6 is a bit of a quagmire. The faster people understand this, the sooner we get to a place where the chicken-egg problem fades away.
- deleted 13y ago[deleted]